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#893392: apparmor: Identify what part of the Apertis delta we could merge into Debian/Ubuntu

[Andrew Shadura]

On 23/03/18 12:09, intrigeri wrote:
> Andrew Shadura:
>> Actually, the Git history I have synthesized for Apertis was supposed to
>> be the shared history of all distros, and I was going to upload it to
>> Alioth… but that never happened :) It had a minor benefit over the
>> original history in that it had the whole source tree in the debian
>> branches, not just the debian/ directory. (I've actually spent quite a
>> lot of time to complete that.)
> 
> AFAIK we've always tracked the full source tree in bzr. But before the
> switch to Git we did not use --upstream-vcs-tag so the upstream
> detailed history was merged into the packaging branch as a single
> big commit such as b81a810. I guess that's what you're referring to.

Right, that's possible, I don't remember full details :)

>> And then in 2.12-1 you migrated to Git yourself, in a different way. Oh
>> well :)
> 
> Yeah, I've learned about your Git tree after I had completed this
> work. Too bad we did not communicate earlier. Perhaps some of you
> could subscribe to the pkg-apparmor-team list? :)

I think so :)

-- 
Cheers,
  Andrew

Bug#893392: apparmor: Identify what part of the Apertis delta we could merge into Debian/Ubuntu

[Andrew Shadura]

On 18/03/18 15:37, intrig...@debian.org wrote:
> Source: apparmor
> Version: 2.12-3
> Severity: minor
> X-Debbugs-Cc: andrew.shad...@collabora.co.uk, ajq...@debian.org, 
> s...@collabora.com
> 
> Hi!
> 
> https://git.apertis.org/cgit/packaging/apparmor.git/ has a few bits
> that might be interesting for Debian/Ubuntu. After a very quick look
> I've noticed a couple things I'd like to look at more closely such as:
> 
>  - split aa-status binary package to drop the Python dependency in
>the apparmor binary package
>  - some systemd integration that looks more elaborate than what we
>have (but might be very ad-hoc to their use case)
> 
> There's probably more.
> 
> Let's discuss if there's ground for increased collaboration and how we
> can move forward on this!
> 
> Ideally Apertis would migrate their Git repo to share the history of
> the Vcs-Git that Debian and Ubuntu now share, which might smooth
> collaboration :)

Actually, the Git history I have synthesized for Apertis was supposed to
be the shared history of all distros, and I was going to upload it to
Alioth… but that never happened :) It had a minor benefit over the
original history in that it had the whole source tree in the debian
branches, not just the debian/ directory. (I've actually spent quite a
lot of time to complete that.)

And then in 2.12-1 you migrated to Git yourself, in a different way. Oh
well :)

-- 
Cheers,
  Andrew

Bug#893392: [pkg-apparmor] Bug#893392: apparmor: Identify what part of the Apertis delta we could merge into Debian/Ubuntu

[Andrew Shadura]

On Mon, 19 Mar 2018 09:58:55 -0500 Jamie Strandboge
 wrote:
> On Sun, 2018-03-18 at 15:37 +0100, intrig...@debian.org wrote:
> 
> >  - split aa-status binary package to drop the Python dependency in
> >the apparmor binary package
> 
> aa-status IMO really needs to be with the apparmor package, not in
> apparmor-utils and not in a separate apparmor-status pacakge. It is
> used in a lot of documentation and probably within a lot of scripts. I
> recently noticed that it uses python3, which may be what apertis
> objected to, but aa-status actually runs just fine with python2, so
> maybe a better collaboration point would be around Makefile changes on
> this point.

In fact, the reason we have split out aa-status was that we needed to
use AppArmor in a minimal Apertis container, and apparently no other
tools we had in that container used any Python runtime (2 or 3), which
is a dependency with quite a large footprint.

-- 
Cheers,
  Andrew

Bug#887809: RFP: borgmatic -- A wrapper script for Borg backup software that creates and prunes backups

[Andrew Shadura]

Control: retitle -1 ITP: borgmatic -- A wrapper script for Borg backup

On Fri, 19 Jan 2018 23:34:36 -0500 Johan Fleury  wrote:
> Package: wnpp
> Severity: wishlist
> 
>   Package name: borgmatic
>   Version : 1.1.9
>   Upstream Author : Dan Helfman (witten)
>   URL : http://www.example.org/
>   License : GPLv3
>   Programming Lang: Python
>   Description : A wrapper script for Borg backup software that
> creates and prunes backups
> 
> Hi
> 
> Most of the time, borg (that is package under the name borgbackup) is
> used with wrappers that manages archives creation and deletion in a more
> convenient way.
> 
> One of the most popular borg wrapper is borgmatic, a Python script that
> can be configured using YAML files.
> 
> borgmatic is available on PyPI and all its dependencies except
> pykwalify, a YAML/JSON validator [1], can be found in Debian
> repositories.
> 
> It would be nice to have it packaged along borg.
> 
> Thanks in advance.

I'll take a look at it now.

-- 
Cheers,
  Andrew

Bug#890227: ITP: dump1090 -- Mode S decoder specifically designed for RTLSDR devices

[Andrew Shadura]

On 12 February 2018 at 11:17, Jonathan Carter  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jonathan Carter 
>
> * Package name: dump1090
>   Version : unreleased (git)
>   Upstream Author : Salvatore Sanfilippo 
> * URL : https://github.com/antirez/dump1090
> * License : BSD
>   Programming Lang: C
>   Description : Mode S decoder specifically designed for RTLSDR devices
>
>
> Main features:
>  - Robust decoding of weak messages, with mode1090 many users observed
>improved range compared to other popular decoders.
>  - Network support: TCP30003 stream (MSG5...), Raw packets, HTTP.
>  - Embedded HTTP server that displays the currently detected aircrafts on
>Google Maps.
>  - Single bit errors correction using the 24 bit CRC.
>  - Ability to decode DF11, DF17 messages.
>  - Ability to decode DF formats like DF0, DF4, DF5, DF16, DF20 and DF21 where
>the checksum is xored with the ICAO address by brute forcing the checksum
>field using recently seen ICAO addresses.
>  - Decode raw IQ samples from file (using --ifile command line switch).
>  - Interactive command-line-interfae mode where aircrafts currently detected
>are shown as a list refreshing as more data arrives.
>  - CPR coordinates decoding and track calculation from velocity.
>  - TCP server streaming and receiving raw data to/from connected clients
>(using --net).
>
>
> For now, I intend to maintain this myself under my salsa namespace. In the
> future this will likely be moved to a team who might share interest with
> this package.

I planned to maintain it too myself, but unfortunately my laptop was
stolen, so all of my work is likely gone. But you may want to check at
Alioth, there may be a backup. Feel free to maintain it yourself
though :)


-- 
Cheers,
  Andrew

Bug#871004: hyde: should hyde be removed from unstable?

[Andrew Shadura]

On Sun, 06 Aug 2017 09:50:12 -0400 Lucas Nussbaum  wrote:
> Source: hyde
> User: debian...@lists.debian.org
> Usertags: qa-removals-post-stretch
> 
> Hi,
> 
> Following a discussion[1] on the debian-qa@ mailing list on packages that
> missed both jessie and stretch, I am proposing the removal of this package 
> from
> unstable, because:
> 
>   it was in unstable at the time of the stretch freeze
> but wasn't part of stretch
> AND
>   it was in unstable at the time of the jessie freeze
> but it wasn't part of jessie
> AND
>   it is still not in testing
> AND
>   it was not uploaded since the beginning of 2017.
> 
> If you disagree and think that this package should remain in unstable, feel
> free to just close this bug.
> 
> If this bug is still open one month from now (on 2017-09-06), it will be 
> turned
> into a removal request, using:
> 
>   reassign -1 ftp.debian.org
>   retitle -1 RM: hyde -- RoQA; missed both jessie and stretch
>   thanks
> 
> - Lucas, for the QA team.

Oh, I missed this one. I was preparing a new upstream version, there
were a few things to fix left… and I see this :/

-- 
Cheers,
  Andrew

Bug#888106: initramfs-tools: mkinitramfs should fail when ldd fails in copy_exec

[Andrew Shadura]

Package: initramfs-tools
Version: 0.130
Severity: minor

Dear Maintainer,

We're working on a minimalist build of a Debian derivative which doesn't
include bash, and we ran into an situation in which due to a human error
the system didn't have a working ldd. This wasn't detected during an
image build process as mkinitramfs happily ignored ldd not working
(while being present and being an executable), and proceeded creating
a broken initramfs. In hook-functions, copy_exec does the following:

# Copy the dependant libraries
for x in $(ldd "${src}" 2>/dev/null | sed -e …)
do
done

The return code of ldd is not handled at all. Should ldd fail for any
reason, this failure will be ignored.

I tried to write a patch, but I couldn't come up with an elegant
solution which would cover cases other than just a wrong hashbang in
ldd :)

Maybe something like https://www.spinics.net/lists/dash/msg00165.html
can be used, but it's up to you to introduce hacks like that into the
code.

Thanks in advance.

-- 
Cheers,
  Andrew

Bug#886927: ITP: tlog -- Terminal I/O recording and playback package.

[Andrew Shadura]

On 11 January 2018 at 21:41, Adam Borowski  wrote:
> On Thu, Jan 11, 2018 at 11:26:23PM +1100, Will Rouesnel wrote:
>> * Package name: tlog
>>   Upstream Author : Nikolai Kondrashov 
>> * URL : http://scribery.github.io/tlog/
>>   Description : Terminal I/O recording and playback package.
>>
>>  tlog is a terminal I/O recording and playback package suitable for
>>  implementing centralized user session recording. At the moment it is not 
>> ready
>>  for production and is to be considered development preview quality.
>>
>>  Whereas most other similar packages write the recorded data to a file in 
>> their
>>  own format, or upload it to a custom server, tlog sends it to a logging
>>  service. The standard syslog interface is supported already, with journald
>>  possibly to come. The recorded data is encoded in JSON in a way which keeps 
>> it
>>  human-readable and searchable as much as possible.
>
> Yay, yet another incompatible format.
>
> For example, my termrec can convert between ttyrec, nh-recorder,
> dosrecorder, RealLogs -- and I bothered to implement only formats that see
> some use in the wild (which excludes eg. script -t, whose two-file
> unhandiness means no one uses it despite coming in an essential package).
> I haven't looked if Asciinema grown a local format when I wasn't looking,
> either.

Asciinema does, indeed, have a local format, JSON-based:

{
  "command": null,
  "height": 22,
  "title": "demo",
  "duration": 37.608602,
  "stdout": [
[
  0.061412,
  "\u001b]0;\u0007$ "
],
…
]
  ],
  "version": 1,
  "width": 80,
  "env": {
"SHELL": "/bin/bash",
"TERM": "xterm-256color"
  }
}

-- 
Cheers,
  Andrew

Bug#876681: RFH: rst2pdf -- ReportLab-based reStructuredText to PDF renderer

[Andrew Shadura]

On Mon, 8 Jan 2018 09:56:41 +0100 Elena ``of Valhalla''
<valhall...@trueelena.org> wrote:
> On 2018-01-07 at 16:31:58 +0100, Andrew Shadura wrote:
> > On 7 January 2018 at 16:13, Elena ``of Valhalla''
> > <valhall...@trueelena.org> wrote:
> > > On 2017-09-25 at 07:31:29 +0200, Andrew Shadura wrote:
> > >> I think I can have a look at it :) I'll let you know later today if
> > >> I'm really interested.
> > >
> > > Can I assume that you're not interested?
> > >
> > > rst2pdf is going to be autoremoved from testing because of #866477, and
> > > right now I'm more likely to just let it be removed rather than working
> > > on it only to have the package removed a little later because of a lack
> > > of py3 support (unless somebody else is interested in the package, of
> > > course).
> > 
> > Sorry, I completely forgot about this. I will *indeed* jave a look later 
> > today.

> Update 1: thanks to Andrew I realized that #866477 wasn't rightfully
> release critical and brought it back to normal (so the package shouldn't
> get autoremoved.
> 
> Update 2: upstream is currently working, apparently on tests
> https://github.com/rst2pdf/rst2pdf/commits/master and they seem to have
> a release planned https://github.com/rst2pdf/rst2pdf/milestones
> so maybe the only thing that is needed is to ping them a bit on python3
> support https://github.com/rst2pdf/rst2pdf/issues/537 where activity
> seems stalled (and it's not in any release milestone).
> 
> I believe that having working automated tests is considered necessary
> for the port, but I don't know what's the current status of them.

Right. So now, having seen the code and the state of the project, I can
confirm this is too large a task for me, and I'm probably not that much
interested to work on it upstream. I'm not sure about Debian packaging
either, as it heavily depends on upstream's decisions on how to proceed
with Python 3 migration.

-- 
Cheers,
  Andrew

Bug#876681: RFH: rst2pdf -- ReportLab-based reStructuredText to PDF renderer

[Andrew Shadura]

On 7 January 2018 at 16:13, Elena ``of Valhalla''
<valhall...@trueelena.org> wrote:
> On 2017-09-25 at 07:31:29 +0200, Andrew Shadura wrote:
>> I think I can have a look at it :) I'll let you know later today if
>> I'm really interested.
>
> Can I assume that you're not interested?
>
> rst2pdf is going to be autoremoved from testing because of #866477, and
> right now I'm more likely to just let it be removed rather than working
> on it only to have the package removed a little later because of a lack
> of py3 support (unless somebody else is interested in the package, of
> course).

Sorry, I completely forgot about this. I will *indeed* jave a look later today.

-- 
Cheers,
  Andrew

Bug#886238: Please introduce official nosystemd build profile

[Andrew Shadura]

Hi,

On 3 January 2018 at 13:12, Hleb Valoshka <375...@gmail.com> wrote:
> Package: general
> Severity: wishlist
>
> Please introduce official nosystemd build profile so downstream
> distributions can send patches to package maintainers with
> systemd-less build instead of keep them in home.

Do we really need systemd-less builds? I'm not convinced this is
something relevant to Debian.

-- 
Cheers,
  Andrew

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Andrew Shadura]

Hi,

On 30 December 2017 at 11:53, Herbert Fortes  wrote:
>
>>>
>>> But I do not understand. It seems to me that an alias
>>> solves the issue. And the user can set anything he
>>> wants. Base on that, the use of 'Conflicts' seems too
>>> much. It changes a lot of things. What am I not seem ?
>>>  I learned that a NMU is when the package has a maintainer
>>> but the maintainer does not take care the package, the
>>> maintainer does not shows some activity for some time.
>>
>> An alias is something the user would need to manually set up. Some users
>> might not know aliases exist, others might not want to set up an alias.
>> Why make the life of a user more inconvenient, when you as a maintainer
>> can fix that on your side?

> Alias is really simple. And fix the issue.

It is one more thing the user has to do. You could do something to
free the user from this one extra action.

> Change the way package is because one does
> not want to press tab and upload a NMU is
> awfull.

Could you please explain why are you so against changing the package
to make it a bit easier to use?

-- 
Cheers,
  Andrew

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Andrew Shadura]

On 29/12/17 22:05, Herbert Fortes wrote:
> Hi Andrew Shadura and Jonathan Dowland,
> 
> 
> First, let's not make big noise about this.
> 
> But I do not understand. It seems to me that an alias 
> solves the issue. And the user can set anything he 
> wants. Base on that, the use of 'Conflicts' seems too 
> much. It changes a lot of things. What am I not seem ?
>  I learned that a NMU is when the package has a maintainer 
> but the maintainer does not take care the package, the 
> maintainer does not shows some activity for some time.

An alias is something the user would need to manually set up. Some users
might not know aliases exist, others might not want to set up an alias.
Why make the life of a user more inconvenient, when you as a maintainer
can fix that on your side?

If you think Conflicts is too strong, you can provide alternatives, an
option Jonathan has suggested. That would allow the user to co-install
two packages if they want, but if you make the X11 version of the
package provide an alternative with a higher priority, it will be used
by default when both packages are installed.

-- 
Cheers,
  Andrew

Bug#885404: Acknowledgement (duc-nox: please provide bin/duc in duc-nox package)

[Andrew Shadura]

Hi,

On Fri, 29 Dec 2017 19:46:38 + Jonathan Dowland  wrote:
> On Thu, Dec 28, 2017 at 09:18:32PM -0200, Herbert Fortes wrote:
> >Please, do not be so fast.
> 
> That's why I uploaded to DELAYED-7 -- so it wasn't fast.
> 
> >Does all that work really necessary ? There is no complain
> >until this week
> 
> It's been bugging me for a while but I've only just had time to file the
> bug (and work on the fix).
> 
> > and there are others packages with the same situation.
> 
> I haven't personally been affected by other packages in this situation,
> but if I was, I might try to fix them too.
> 
> On Thu, Dec 28, 2017 at 09:21:27PM -0200, Herbert Fortes wrote:
> >You already did the upload.
> >
> >I will cancel it.
> 
> On Thu, Dec 28, 2017 at 09:36:03PM -0200, Herbert Fortes wrote:
> >I will really appreciate if you cancel the NMU.
> 
> I think you already have? I can no longer see it in the DELAYED queue.
> 
> Now that you are engaging here I'd love to hear your opinion on your
> preferred approach going forward. I was actually about to cancel my
> upload because the Conflicts: in the duc binary needs to be versioned
> for smooth upgrades in the situation where someone has both installed
> already (work I have completed this evening).
> 
> Looking forward to hearing from you (and thanks for packaging duc in the
> first place)

I would like to say I agree here with Jonathan, there's no reason not to
have both packages provide the same binary. It's not difficult to
implement, and makes it is easier for our users to run — and users are
our priority in Debian.

If I were the maintainer, I would give this a second thought.

-- 
Cheers,
  Andrew

Bug#884732: ITP: pypostal -- Python bindings to libpostal for fast international address parsing/normalisation

[Andrew Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrew Shadura <andre...@debian.org>

* Package name: pypostal
  Version : 1.0
  Upstream Author : openvenues, MapZen
* URL : https://github.com/openvenues/pypostal/
* License : MIT
  Programming Lang: C
  Description : Python bindings to libpostal for fast international address 
parsing/normalisation

Official Python bindings to https://github.com/openvenues/libpostal,
a fast statistical parser/normaliser for street addresses anywhere in
the world.

Bug#884731: ITP: libpostal -- parse and normalise street addresses around the world

[Andrew Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrew Shadura <andre...@debian.org>

* Package name: libpostal
  Version : 1.0.0
  Upstream Author : openvenues, Mapzen
* URL : https://github.com/openvenues/libpostal
* License : MIT
  Programming Lang: C
  Description : parse and normalise street addresses around the world

libpostal is a C library for parsing/normalizing street addresses around
the world using statistical NLP and open data. The goal of this project
is to understand location-based strings in every language, everywhere.

libpostal's international address parser uses machine learning
(Conditional Random Fields) and is trained on over 1 billion addresses
in every inhabited country on Earth. It uses use OpenStreetMap and
OpenAddresses as sources of structured addresses, and the OpenCage
address format templates to construct the training data, supplementing
with containing polygons, and generating sub-building components like
apartment/floor numbers and PO boxes.

-- 
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#883659: [pkg-wpa-devel] Bug#883659: wpasupplicant: 2:2.6-12 does not fallback to default interface config

[Andrew Shadura]

Hi,

On 6 December 2017 at 10:36, Julian Wollrath  wrote:
> wpasupplicant from unstable (2:2.6-12): Logical iface is not set
> correctly, not fallback to default and hence dhclient is not started:
> wpa_action[30471]: WPA_IFACE=wlp3s0 WPA_ACTION=CONNECTED
> wpa_action[30472]: WPA_ID=0 WPA_ID_STR=foobar WPA_CTRL_DIR=/run/wpa_supplicant
> wpa_action[30477]: ifup wlp3s0=foobar
>
> wpasupplicant from testing (2:2.4-1.1): Fallback to default as
> expected, hence dhclient is started:
> wpa_action[30806]: WPA_IFACE=wlp3s0 WPA_ACTION=CONNECTED
> wpa_action[30807]: WPA_ID=0 WPA_ID_STR=foobar WPA_CTRL_DIR=/run/wpa_supplicant
> wpa_action[30810]: network settings not defined for foobar in 
> /etc/network/interfaces
> wpa_action[30811]: ifup wlp3s0=default

Thanks for you report. Before we proceed with anything else, could you
please fix a typo in /etc/wpa_supplicant/functions.sh:

if ! /sbin/ifquery "${WPA_LOGICAL_IFACE}" > /dev/null 2/&1; then

should be

if ! /sbin/ifquery "${WPA_LOGICAL_IFACE}" > /dev/null 2>&1; then

Please let me know if that fixes the issue for you. If not, we'll look
into other things which could go wrong.

-- 
Cheers,
  Andrew

Bug#883658: bts: please document tags in the manpage

[Andrew Shadura]

Package: devscripts
Version: 2.16.8
Severity: wishlist

Dear Maintainer,

Due to the way the bug tracking system's documentation is structured, it
always takes some time for me to find the list of the tags and their
meanings. It would be great if the latest known list of tags was
included in the bts manpage, along with short explanations on their
usage.

Thanks.

-- 
Cheers,
  Andrew

Bug#883614: [pkg-wpa-devel] Bug#883614: wpasupplicant fails to connect in v2.6

[Andrew Shadura]

Hi Philip,

From the logs you attached it appears that the connection attempt succeeded. 
Could you please inspect the exact state wpa-supplicant and the interfaces are 
left in at that point?

Thanks!
-- 
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#883465: ITP: appmenu-gtk-module -- GtkMenuShell to GMenuModel parser

[Andrew Shadura]

Hello Mike,

On 4 December 2017 11:53:02 CET, Mike Gabriel 
 wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Mike Gabriel 
>
>* Package name: appmenu-gtk-module
>  Version : 0.5.5
>  Upstream Author : Konstantin (https://github.com/rilian-la-te)
>* URL :
>https://github.com/rilian-la-te/vala-panel-appmenu/tree/master/unity-gtk-module
>* License : LGPL-3
>  Programming Lang: C
>  Description : GtkMenuShell to GMenuModel parser
>
> GTK+ module for exporting old-style menus as GMenuModels.
> .
>Many applications implement menus as GtkMenuShells and GtkMenuItems and
> aren't looking to migrate to the newer GMenuModel API.
> .
>The AppMenu GTK+ module watches for these types of menus and exports
>the
> appropriate GMenuModel implementation.
> .
> The (new) upstream author has started continuing and improving the
> unity-gtk-module as found in Ubuntu needed for the Unity Desktop
> Environment.
> .
>Recommendation will be send to the community team continuing support
>for
> Unity 7 to switch over to this AppMenu module rather than continuing
> unity-gtk-module. (Share workload, reducing list of to-be-maintained
> packages).
> .
> In Debian, this package will be needed to have vala-panel with
> vala-panel-appmenu packaged.
> .
> The packaging will be done by joint team efforts (Ayatana Packagers,
> MATE Packaging Team).

I just wanted to thank you for your work.

-- 
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#883207: matrix-synapse: [INTL:ru] Russian translation of debconf template

[Andrew Shadura]

On 30 November 2017 at 18:10, Lev Lamberov  wrote:
> Package: matrix-synapse
> Severity: wishlist
> Tags: l10n patch
>
> Dear Maintainer,
>
> please find attached the Russian debconf translation for matrix-synapse.

Thanks.

> федеративные связи

hmm…

> но это позволяет

позволяя?

> делать Matrix успешным проектом

сделать Matrix успешнее?

-- 
Cheers,
  Andrew

Bug#882740: hostapd installation error

[Andrew Shadura]

On 29 November 2017 at 13:57, RjY <r...@users.sourceforge.net> wrote:
> Andrew Shadura wrote:
>>On 28 November 2017 at 10:24, RjY <r...@users.sourceforge.net> wrote:
>>> I'm still observing this on upgrade from 2:2.4-1.1 to 2:2.6-8.
> [...]
>>> As workaround I did "sudo update-rc.d hostapd disable" (Wasn't sure what
>>> the systemctl equivalent is) then "sudo dpkg --configure hostapd"
>>> unbroke dpkg. Apparently the call to "systemctl mask hostapd.service" in
>>> postinst had no effect? (or was not performed)
>>Well, that was something I haven't thought about carefully. Probably I
>>need to mask the unit every time when (during upgrades or
>>reinstallation) we find out /etc/defaults/hostapd is unconfigured
>>*and* hostapd isn't already running.
>
> I think unfortunately it needs to be more than just "hostapd isn't
> running" - in my case hostapd *was* already running, started via
> ifupdown:
>
> iface netw inet static
> hostapd /etc/hostapd/hostapd.conf
> address xxx.xxx.xxx.xxx
> network xxx.xxx.xxx.xxx
> netmask xxx.xxx.xxx.xxx
> broadcast xxx.xxx.xxx.xxx
> up start-stop-daemon -S -o -p /run/udhcpd.pid -x /bin/busybox -- 
> udhcpd -S /etc/hostapd/udhcpd.conf
> down start-stop-daemon --signal KILL -K -o -p /run/udhcpd.pid -x 
> /bin/busybox
>
> (which is probably a bit strange, but works well enough for me, so I've
> yet to attempt to port it to a systemd unit)
>
> So I guess it needs to be "mask the unit if /etc/defaults/hostapd isn't
> configured and hostapd isn't already started by a sysv init script or
> systemd unit". Or just simply "mask the unit if /etc/defaults/hostapd
> isn't configured" - does it matter if it is already running or not?

By 'running' I meant running in terms of systemd, that is the unit is
somehow started already. Why this matters: the user might have edited
the unit file or written one of their own, which potentially uses a
different configuration file from a different location. If we just
mask it, the user may say, hey, why do you mess up with my config, I
want it this way.

Please have a look at the latest hostapd package version and let me
know if that works for you.

-- 
Cheers,
  Andrew

Bug#882740: hostapd installation error

[Andrew Shadura]

Hi,

On 28 November 2017 at 10:24, RjY  wrote:
> I'm still observing this on upgrade from 2:2.4-1.1 to 2:2.6-8.
>
> rjy@vile /tmp % systemctl status hostapd
> ● hostapd.service - Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP 
> Authenticator
>Loaded: loaded (/lib/systemd/system/hostapd.service; enabled; vendor 
> preset: enabled)
>Active: failed (Result: exit-code) since Tue 2017-11-28 09:17:50 GMT; 
> 28min ago
> Tasks: 0 (limit: 4915)
>CGroup: /system.slice/hostapd.service
>
> Nov 28 09:17:50 vile systemd[1]: Starting Advanced IEEE 802.11 AP and 
> IEEE 802.1X/WPA/WPA2/EAP Authenticator...
> Nov 28 09:17:50 vile hostapd[3728]: Configuration file:
> Nov 28 09:17:50 vile hostapd[3728]: Could not open configuration file '' 
> for reading.
> Nov 28 09:17:50 vile hostapd[3728]: Failed to set up interface with
> Nov 28 09:17:50 vile hostapd[3728]: Failed to initialize interface
> Nov 28 09:17:50 vile systemd[1]: hostapd.service: Control process exited, 
> code=exited status=1
> Nov 28 09:17:50 vile systemd[1]: hostapd.service: Failed with result 
> 'exit-code'.
> Nov 28 09:17:50 vile systemd[1]: Failed to start Advanced IEEE 802.11 AP 
> and IEEE 802.1X/WPA/WPA2/EAP Authenticator.
>
> As workaround I did "sudo update-rc.d hostapd disable" (Wasn't sure what
> the systemctl equivalent is) then "sudo dpkg --configure hostapd"
> unbroke dpkg. Apparently the call to "systemctl mask hostapd.service" in
> postinst had no effect? (or was not performed)

Well, that was something I haven't thought about carefully. Probably I
need to mask the unit every time when (during upgrades or
reinstallation) we find out /etc/defaults/hostapd is unconfigured
*and* hostapd isn't already running.

-- 
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#838713: python-xlib: please make the build reproducible

[Andrew Shadura]

Hi,

On 27 November 2017 at 01:00, Jeremy Bicha  wrote:
> Chris, there is a good chance that the person doing uploads never saw
> your proposed patch because he isn't listed in the Maintainer field
> and therefore doesn't automatically receive bug mail.
>
> Andrew, I encourage you to consider subscribing to this package at
> https://tracker.debian.org/pkg/python-xlib
>
> For reference, here's the bug and patch:
> https://bugs.debian.org/838713

I have updated the package to not use texi2html at all, but I cannot
figure out whether the patch Chris proposed is needed or not, as
makeinfo lacks the option used in the patch, and I'm not sure it does
the right thing without any options at all.

-- 
Cheers,
  Andrew

Bug#882716: [pkg-wpa-devel] Bug#882716: 2.6-7 does not fallback the default interface config, only id_str plus explicit interface config works

[Andrew Shadura]

On 26/11/17 11:51, manul wrote:
> Package: wpasupplicant
> Followup-For: Bug #882716
> 
> Dear Maintainer,
> 
> Thanks for the quick reply.
> 
> As you suggested, I am currently running the version 2:2.6-5 from 
> snapshots.debian.org experimental:
> 
> root@hpsiddie:/home/manul# apt-cache policy wpasupplicant
> wpasupplicant:
>   Installed: 2:2.6-5
>   Candidate: 2:2.6-7
>   Version table:
>  2:2.6-7 500
> 500 http://ftp.us.debian.org/debian sid/main amd64 Packages
>  *** 2:2.6-5 100
> 100 /var/lib/dpkg/status
> 
> 
> There is no bug in this version, it correctly falls back to default interface 
> in /etc/network/interfaces, and initiates dhclient automatically.
> 
> 
> Here are the current stanzas (no id_str in wpasupplicant config, and only 
> default interface configured in /etc/network/interfaces)
> 
> /etc/network/interfaces:
> 
> iface wlan0 inet manual
> wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
> wpa-roam-default-iface default
> 
> iface default inet dhcp
> 
> 
> /etc/wpa_supplicant/wpa_supplicant.conf:
> 
> network={
> ssid="sid5G"
> psk="*"
> priority=32
> }
> 
> 
> So all is ok here with the previous version 2:2.6-5 from snapshots.debian.org 
> experimental.

Right, okay, makes sense. Please try a patched version from:
https://people.debian.org/~andrewsh/UNRELEASED/


-- 
Cheers,
  Andrew

Bug#882716: [pkg-wpa-devel] Bug#882716: wpasupplicant: 2.6-7 does not fallback the default interface config, only id_str plus explicit interface config works

[Andrew Shadura]

On 25/11/17 23:47, manul wrote:
> Package: wpasupplicant
> Version: 2:2.6-7
> Severity: important
> 
> Dear Maintainer,
> 
> Since the last upgrade of wpasupplicant, it does not anymore honor the 
> 'default' interface config in /etc/network/interfaces (it is supposed to 
> fallback to it 
> as stated in wpasupplicant documentation).
> So dhclient is not called, and IP is not configured.
> 
> I have the following stanza in /etc/default/interfaces:
> ---
> auto wlan0
> 
> iface wlan0 inet manual
> wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
> wpa-roam-default-iface default
> 
> iface default inet dhcp
> ---
> 
> And the following stanza in /etc/wpa_supplicant/wpa_supplicant.conf
> ---
> network={
> ssid="sid5G"
> psk="*"
> priority=32
> }
> ---
> 
> Before latest update to 2.6-7, it properly resorted to 'iface default inet 
> dhcp' in /etc/netwpork/interfaces in the following cases:
> a) have no id_str option in /etc/wpa_supplicant/wpa_supplicant.conf (as 
> stated above)
> b) have id_str option in /etc/wpa_supplicant/wpa_supplicant.conf, but the 
> corresponding 'iface XXX inet dhcp' is missing from /etc/default/interfaces
> 
> And it matched the documented behaviour.
> 
> Now after the upgrade with version 2.6-7, the ONLY way to make wpasupplicant 
> to automatically invoke dhclient, is using the id_str option for each the 
> network config AND having 
> the corresponding iface XXX inet dhcp' stanza in /etc/default/interfaces .
> 
> So for example, this is what ONLY now works:
>  
> stanza in /etc/default/interfaces:
> ---
> auto wlan0
> 
> iface wlan0 inet manual
> wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
> wpa-roam-default-iface default
> 
> iface default inet dhcp
> iface one-of-my-networks inet dhcp
> ---
> 
> plus the following stanza in /etc/wpa_supplicant/wpa_supplicant.conf
> ---
> network={
> ssid="sid5G"
> psk="*"
>   id_str="one-of-my-networks"
> priority=32
> }
> ---
> 
> But providing separate id_str for all possible networks in 
> /etc/wpa_supplicant/wpa_supplicant.conf and their corresponding "iface XXX 
> inet dhcp" entries in /etc/network/interfaces
> is too clumsy to do with each known network (and unnecessarily clogs with 
> extra entries both the interfaces and wpa_supplicant.conf files).
> And also does not anymore follow the roaming mode documented behaviour in 
> /usr/share/doc/wpa_supplicant/README.modes.gz

Thanks for your report. Could you please download from
snapshots.debian.org and test a previous version from experimental,
2:2.6-5? That'd help to possibly rule out patches I applied since 2.6
has last been in unstable.


-- 
Cheers,
  Andrew

Bug#882661: ITP: nplan -- YAML-based network configuration tool

[Andrew Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrew Shadura <andre...@debian.org>

* Package name: nplan
  Version : 0.32
  Upstream Author : Canonical Ltd.
* URL : https://launchpad.net/netplan
* License : GPL-3
  Programming Lang: C
  Description : YAML-based network configuration tool

netplan is a YAML network configuration abstraction for various backends
(NetworkManager, networkd).

netplan reads network configuration from /etc/nplan/*.yaml which are
written by administrators, installers, cloud image instantiations,
or other OS deployments. During early boot it then generates backend
specific configuration files in /run to hand off control of devices to
a particular networking daemon.

Currently supported backends are networkd and NetworkManager.

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#882220: webkit2gtk: please apply the patch with NetworkStateNotifier implementation

[Andrew Shadura]

Source: webkit2gtk
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainers,

Gustavo Noronha Silva has written an submitted a short patch to WebKit2
to implement NetworkStateNotifier, which solves issues with websockets
timing out and online/offline state not working ([0], [1]).

Please consider applying the patch, it should be pretty straighforward
to do ([2], [3])

Thanks!

[0]: https://blog.kov.eti.br/2017/10/who-knew-we-still-had-low-hanging-fruits/
[1]: https://bugs.webkit.org/show_bug.cgi?id=177741
[2]: https://bugs.webkit.org/attachment.cgi?id=322383=prettypatch
[3]: http://trac.webkit.org/changeset/222723/webkit

- -- 
Cheers,
  Andrew

-BEGIN PGP SIGNATURE-

iQI8BAEBCAAmBQJaErqqHxxhbmRyZXcuc2hhZHVyYUBjb2xsYWJvcmEuY28udWsA
CgkQQWcbs0qEk4H8fw/+MTd24WO8QiNfBPu7Bbwcnli/P6w2CMDPWSQph5AVcYnU
gimrJGUcAyr7W/DnWekbx/qNDzTWtnP87lz4leuYIK/SwVxid+jzyP/nig1kIOec
pkPt72TJQNFpOl2u8AVQbeAKGDCxF1tr9BSTEk18ta2rJPKbCp3dr5x08pmM7CZN
l9/wKCJ9iK4Ok+7Cd9a3HS7vIxkrybahLpARIU5nuhwoGbhhLvPpnqd9sHGNzBnV
YuhJaJ6j8HClzuEWLrCkHBNR5Pavq54//8z+HSImf8A3WYRjyNND9GFCH8LYRhPt
1TCIUMVcIcTuDr99gewPgyA6igV2/L8bezrQrbG/WrSAtViD9jPbMvUfGUhbCI1H
rAyVXIhGGM393GQYZdaCGSuHQqr5rsbrM2XXj4P3wMw7Cn5X5LonefAAQ1akR+kQ
2NW5SbK0MiuC422TMq0arUiO1JMVdYO0/OrowRlOr45CZ2mbGmEhNTosvxD3ePSr
R9Dcm8MMx1nqEilKmcP9t8ITF00sqSy4EJ6Va7c3LISt/iGoQsv4IwKbpp+QOX+s
GOJwRB6xkGol2893koEBDn9dGqN/VaRRfaYJaTh2WC7mLGvXxb2LEQlnEZebr2a+
jAgnbPytDV0ZSCcyKfPJ3x+n+lNG3fBo5YzPrf7KUEMi0ebNjMvY7+sl1n1jTh8=
=n6hr
-END PGP SIGNATURE-

Bug#882050: "service hostapd restart" *kills* hostapd

[Andrew Shadura]

Hi Joey,

On Sat, 18 Nov 2017 00:46:36 -0400 Joey Hess  wrote:
> Package: hostapd
> Version: 2:2.4-1.1
> Severity: normal
> 
> Not sure why; /etc/init.d/hostapd restart restarts it successfully.
> 
> Saw this on an armhf system running testing.
> /etc/default/hostapd contains DAEMON_CONF=/etc/hostapd/hostapd.conf

Does your system run systemd or sysvinit? If systemd, what does
systemctl status hostapd say when after hostapd is killed?

-- 
Cheers,
  Andrew

Bug#875233: [pkg-wpa-devel] Bug#875233: [wpa] Future Qt4 removal from Buster

[Andrew Shadura]

On 10 November 2017 at 17:24, Reiner Herrmann  wrote:
> Control: tags -1 + patch
>
> The attached patch against 2:2.6-5 builds wpa_gui with Qt5.

Ack! Thanks, will apply ~soon.

-- 
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#879208: [pkg-wpa-devel] Bug#879208: wpasupplicant: Build wpa_supplicant with interface matching support

[Andrew Shadura]

Control: notfound -1 2:2.4-1.1

On 20 October 2017 at 14:33, Roy Marples  wrote:
> Dear Maintainer,
>
> Plese build wpa_supplicant with interface matching support:
> CONFIG_MATCH_IFACE=y
>
> This allows the administrator to configure named interfaces to run
> wpa_supplicant on which may not exist at boot time.
> This allows USB network sticks to be easily pluggable when not
> using Network Manager or similar.

Hi, I don't think this option exists in wpa-supplicant 2.4, but I will
look into this for 2.6.

-- 
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#878122: opensc: please enable npa-tool

[Andrew Shadura]

Package: opensc
Version: 0.17.0-1
Severity: wishlist

Dear Maintainer,

Please enable npa-tool recently added to OpenSC:

https://github.com/OpenSC/OpenSC/pull/831/commits/089c472d8f87145ee0e2f66df087615fc4af1e3d#diff-67e997bcfdac55191033d57a16d1408aR869

Thanks!

-- 
Cheers,
  Andrew

Bug#878059: ITP: golang-github-emicklei-go-restful-swagger12 -- Swagger extension to the go-restful package

[Andrew Shadura]

On 9 October 2017 at 12:36, Dmitry Smirnov <only...@debian.org> wrote:
> On Monday, 9 October 2017 12:16:35 PM AEDT Andrew Shadura wrote:
>> It is already in NEW…
>
> There is something seriously wrong about it as nigher there is ITP nor there
> is a public repository in the team space...

I don't see it as seriously wrong. I created the repo in collab-maint
as I was not a member of the team yet back then.

> Did you packaged it by just throwing it into NEW?

Yes. I think it is okay for a micropackage like this.

> We have to follow procedures to avoid burning each others time...
> ITP is not an optional thing...

So is checking NEW before packaging.

> Besides collab-maint is not the best place for Go microlibraries...

Why?

-- 
Cheers,
  Andrew

Bug#878059: ITP: golang-github-emicklei-go-restful-swagger12 -- Swagger extension to the go-restful package

[Andrew Shadura]

On 9 October 2017 at 11:12, Dmitry Smirnov  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Dmitry Smirnov 
> X-Debbugs-CC: debian-de...@lists.debian.org, 
> pkg-go-maintain...@lists.alioth.debian.org
> Control: block 871078 by -1
>
>   Package name: golang-github-emicklei-go-restful-swagger12
> Version: 1.0.1
> Upstream Author: Ernest Micklei
> License: Expat
>   URL: 
> https://github.com/emicklei/go-restful-swagger12
>   Vcs-Browser: 
> https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-emicklei-go-restful-swagger12.git
> Description: Swagger extension to the go-restful package
>  Swagger 1.2 extension to the "golang-github-emicklei-go-restful-dev"
>  package.
>
> ---
>
> This library has been split from "golang-github-emicklei-go-restful-dev"
> that no longer provides "swagger" since 2.4.0 causing FTBFS of at least
> one package...

It is already in NEW…

-- 
Cheers,
  Andrew

Bug#827606: RM: omegat -- ROM; out of date; request of upstream

[Andrew Shadura]

clone 827606 -1
retitle -1 ITP: omegat -- Computer Assisted Translation (CAT) tool
archive 827606
kthxbye

Hi,

I think I might attempt to reintroduce a recent version of OmegaT in Debian.

-- 
Cheers,
  Andrew

Bug#782654: ITP: bazel, but it builds against its earlier version.

[Andrew Shadura]

Hi,

Is there any update on bazel? It is needed to build recent Kubernetes.

-- 
Cheers,
  Andrew



signature.asc
Description: OpenPGP digital signature

Bug#877056: ITP: fr24feed -- Flightradar24 Decoder & Feeder

[Andrew Shadura]

Hi,

On 29 September 2017 at 17:32, Viacheslav Kalmykov  wrote:
> We have considered open source however it's not suitable for this particular
> project, since our decoding algorithms are valuable intellectual property
> that our business rivals might gain an advantage from and we would therefore
> not want to offer that for free. Rather our purpose with including this
> software in your repo is more to make it widely available and easily
> installed from a trusted source.

I'm not sure it is fair to use infrastructure of a free software
project such as Debian as a platform to distribute your non-free
software, especially considering you base it on free software packages
such as librtlsdr and dump1090. We'd welcome it as if it were free
software, but I see no benefit to Debian or Debian users from it as it
is now.

If anything, I'd vote against inclusion of such software even into non-free.

-- 
Cheers,
  Andrew

Bug#877056: ITP: fr24feed -- Flightradar24 Decoder & Feeder

[Andrew Shadura]

Hi,

On 28 September 2017 at 10:13, Viacheslav Kalmykov  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Viacheslav Kalmykov 
>
> * Package name: fr24feed
>   Version : 1.0.19-2
>   Upstream Author : Flightradar24 
> * URL : https://www.flightradar24.com/
> * License : http://repo.feed.flightradar24.com/LICENSE.fr24feed.txt
>   Programming Lang: C++, shell
>   Description : Flightradar24 Decoder & Feeder lets you effortlessly 
> share ADS-B data with Flightradar24. It supports multiple receivers, the 
> DVB-T stick, and makes the entire feeding process as smooth as possible.
>
> We at Flightradar24.com offer our feeders software for x86 / ARM Linux 
> platforms which we currently package as .deb packages through our own APT 
> repository.
> As our userbase grows, we thought that it might be better for our users to 
> skip manual step of adding yet another repository to their system.
> Therefore we ask if it would be possible to include our feeder package to the 
> non free part of Debian repository.
>
> Majority of our users run the software on Raspbian OS on Raspberry Pi. 
> However, we aim to support any Debian-based OS, including Debian itself and 
> Ubuntu.
>
> We plan to maintain and support the package ourselves as a company.

Have you considered making it free software? Is there any reason really not to?

-- 
Cheers,
  Andrew

Bug#876681: RFH: rst2pdf -- ReportLab-based reStructuredText to PDF renderer

[Andrew Shadura]

Hi,

On 24 September 2017 at 22:07, Elena ``of Valhalla''
 wrote:
> Package: wnpp
> Severity: normal
>
> I request assistance with maintaining the rst2pdf package.
>
> The package description is:
>  The usual way of creating PDF files from reStructuredText is by going through
>  LaTeX. This tool provides an alternative by producing PDF directly using the
>  ReportLab library.
>
> rst2pdf currently only supports python2 (#826908); there was an effort
> from upstream to resume developement and an issue to track supporting
> python3, but apparently they have stopped again in 2016.
>
> Since sooner or later python2 will be dropped from Debian, rst2pdf will
> have to follow, unless somebody cares about it enought to solve the
> situation.
>
> I believe that rst2pdf is currently being used as a build-dependency by
> the following packages, whose maintainers I'm cc-ing:
>
> * apcupsd
> * davical
> * pdal
>
> Right now, I'm not really using this package, so in case there is a need
> for an upstream fork I'm not the right person do do it, but if upstream
> resumes working or there is a new upstream I would be glad to continue
> maintaining the package.

I think I can have a look at it :) I'll let you know later today if
I'm really interested.

-- 
Cheers,
  Andrew

Bug#875667: ITA: tclxml -- Tcl library for XML parsing

[Andrew Shadura]

Hi,

On Sat, 16 Sep 2017 14:09:32 +0200 Ole Streicher  wrote:
> I am the Debian maintainer of saods9, the only reverse dependency of
> tclxml, and I intend to adopt the Debian package of tclxml.

Great!

> The upstream author of saods9 (William Joye, in cc, to get him informed)
> now also maintains (among the other requirements of saods9) tclxml:
> 
> https://github.com/wjoye/tclxml
> 
> Although the version number there is lower than the one in Debian, I
> would suspect that his package is more current, and therefore use this
> for a new version.

Hmm, from a first glance it doesn't seem so. Mostly the changes are
updates to tclconfig, and there's a change you probably should discuss
as I'm not sure it's not breaking the reverse dependencies (including
those outside Debian):

https://github.com/wjoye/tclxml/commit/d5e1189ddcc1c92df8c1d56011c3ca1f555e537c

> Other changes I am going to do:
> 
> * put under team maintenance (Tcl/Tk team)
> * convert the packaging to git and git-buildpackage
> * update debian/files to latest standards (d/copyright & Co.)

That'd be good, thanks!

-- 
Cheers,
  Andrew

Bug#875667: O: tclxml

[Andrew Shadura]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

As the upstream is dead, and I never found time (or interest really) to
take it over, I think it's time for me to orphan this package. It is
in a more or less good shape, and unless something happens (security
issues or compiler incompatibility), there's not much to be done with
it.

- -- 
Cheers,
  Andrew

-BEGIN PGP SIGNATURE-

iQExBAEBCAAbBQJZuP7TFBxhbmRyZXdzaEBkZWJpYW4ub3JnAAoJEJ1bI/kYT6UU
RR0IAIjQsrQ7kvhRsfmQ6mY+/Vilv9k4vDEZibosp07T39NW0aMkXegqISAaePPa
hSXX7YS6sOeY9oTBgFduv4WnioYAp7GknFaDnF1NJcHaB/GYXyBcIAWXrat0Y0fW
1HKNdkI5lFGxMkq63RUNrB2TQpiHu4dsOcrGAs1uMB06Iq40OJ5Mcej8/5ZrdakY
R8hgaQLYzuoREhLUWC7aVsYekKuwkU7xkMpU4JEr640SQGAJ8USB4Su3juEvygig
prHJKX9NvqLsVdal7Pha2KJJJCKQxI4n8A/TqujVym2iWPZtgS5xRphoTluIan9Z
FgA2mXOTmnMFTF4jTSjY92T68q0=
=0LoL
-END PGP SIGNATURE-

Bug#868286: plantuml: New version available

[Andrew Shadura]

On 5 September 2017 at 08:18, Christopher Hoskin  wrote:
> Package: plantuml
> Version: 8039-1
> Followup-For: Bug #868286
>
> Dear Andrew,
>
> Because it wasn't specified in the Vcs-* fields in debian/control, so I 
> wasn't aware that there was an existing Git repo.
>
> Thanks for letting me know. I'll switch to using that.

Right, well, makes sense :) Thanks for taking care of the package anyway :)

-- 
Cheers,
  Andrew

Bug#868286: plantuml: New version available

[Andrew Shadura]

On 5 September 2017 at 08:22, Andrew Shadura <and...@shadura.me> wrote:
> On 5 September 2017 at 08:18, Christopher Hoskin <mans0...@debian.org> wrote:
>> Package: plantuml
>> Version: 8039-1
>> Followup-For: Bug #868286
>>
>> Dear Andrew,
>>
>> Because it wasn't specified in the Vcs-* fields in debian/control, so I 
>> wasn't aware that there was an existing Git repo.
>>
>> Thanks for letting me know. I'll switch to using that.
>
> Right, well, makes sense :) Thanks for taking care of the package anyway :)

Oh, I forgot to say. Back then dgit only supported patches-applied
workflow, so I used that, but I don't actually have a preference for
it.

-- 
Cheers,
  Andrew

Bug#868286: Pending fixes for bugs in the plantuml package

[Andrew Shadura]

On 5 September 2017 at 04:03,
 wrote:
> tag 868286 + pending
> thanks
>
> Some bugs in the plantuml package are closed in revision
> 051493f7d785dbaad8070ec9896f8cd1c62ed447 in branch 'master' by
> Christopher Hoskin
>
> The full diff can be seen at
> https://anonscm.debian.org/cgit/pkg-java/plantuml.git/commit/?id=051493f
>
> Commit message:
>
> Fix "New version available" package upstream release (1.2017.15), new 
> epoch (Closes: #868286)

Hi, why haven't you used the existing Git repo?

https://anonscm.debian.org/cgit/collab-maint/plantuml.git/log/

It'd also be cool if you used dgit:

https://browse.dgit.debian.org/plantuml.git/

-- 
Cheers,
  Andrew

Bug#868286: plantuml: New version available

[Andrew Shadura]

Hi,

On 4 September 2017 at 22:07, Christopher Hoskin  wrote:
> Package: plantuml
> Version: 8039-1
> Followup-For: Bug #868286
>
> Dear Andrew,
>
> Would you be interested in an NMU to fix this bug? Or perhaps maintaining 
> this package within the pkg-java team?
>
> I've found that the recent versions of plantuml have an issue with v1.8 of 
> batik (URI is not hierarchical exception) so I uploaded v1.9 this morning 
> which appears to solve this problem.

Sure, either NUM or pkg-java team mainenance or both are fine, go for it :)

-- 
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#870961: gpointing-device-settings: should gpointing-device-settings be removed from unstable?

[Andrew Shadura]

reassign -1 ftp.debian.org
retitle -1 RM: gpointing-device-settings -- RoQA; unmaintained and dead
upstream
thanks

On 6 August 2017 at 09:50, Lucas Nussbaum  wrote:
> Source: gpointing-device-settings
> User: debian...@lists.debian.org
> Usertags: qa-removals-post-stretch
>
> Hi,
>
> Following a discussion[1] on the debian-qa@ mailing list on packages that
> missed both jessie and stretch, I am proposing the removal of this package 
> from
> unstable, because:
>
>   it was in unstable at the time of the stretch freeze
> but wasn't part of stretch
> AND
>   it was in unstable at the time of the jessie freeze
> but it wasn't part of jessie
> AND
>   it is still not in testing
> AND
>   it was not uploaded since the beginning of 2017.
>
> If you disagree and think that this package should remain in unstable, feel
> free to just close this bug.
>
> If this bug is still open one month from now (on 2017-09-06), it will be 
> turned
> into a removal request, using:
>
>   reassign -1 ftp.debian.org
>   retitle -1 RM: gpointing-device-settings -- RoQA; missed both jessie and 
> stretch
>   thanks

I agree, but let's do it now!

-- 
Cheers,
  Andrew



signature.asc
Description: OpenPGP digital signature

Bug#852377: RFS: tikzit/1.0-1 [ITP]

[Andrew Shadura]

On 24/07/17 20:10, Andrey Rahmatullin wrote:
> Control: owner -1 !
> 
> Please bump Standards-Version to the current version and I'll upload it.

Actually, I have already uploaded it:

https://ftp-master.debian.org/new/tikzit_1.0+ds-1.html

-- 
Cheers,
  Andrew

Bug#865290: RM: get-iplayer -- ROM; unsuitable for stable releases

[Andrew Shadura]

On Tue, 20 Jun 2017 11:36:06 +0100 Jonathan Wiltshire 
wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Hi,
> 
> get-iplayer has had to be pulled from wheezy, and pulled from jessie
> during that freeze. It wasn't in stretch.
> 
> Changes upstream are frequent and invasive enough (because of the
> every-shifting service get-iplayer tries to work with) that I have come
> to the conclusion it is never going to be in stable.
> 
> There's therefore little point it being in sid, either.

Well, I still find it useful in sid.

-- 
Cheers,
  Andrew

Bug#863487: Fwd: TAG: durruter -- NAT/PAT routing helper

[Andrew Shadura]

Control: retitle -1 RFP: durruter -- NAT/PAT routing helper

On 28/05/17 13:14, Andrew Shadura wrote:
> On 27/05/17 22:24, Narcis Garcia wrote:
>> Dear mentors,
>> I am looking for a sponsor for my package "durruter"
>>
>> Durruter is a command-line wizard to manage iptables entries like in a
>> hardware router web interface. Forward ports and ranges from multiple
>> interfaces, allow internet traffic from multiple nets to multiple
>> network interfaces.
>>
>> Works with Debian GNU/Linux since 3.1 upto 9.0
>>
>> Complete information and personal sources & packages repository:
>> https://www.actiu.net/durruter/
>>
>> Thanks for your consideration.
> 
> I think you slightly misunderstood what the sponsorship is about. You're
> supposed to present a near-ready source package you think is ready to be
> uploaded to Debian unstable. Then your package goes through a review
> process, you improve it if needed, and then the sponsor uploads it when
> you both agree no further improvement is needed at the moment.

So far this doesn't look like a sponsorship request, but a request for
packaging. I’m thus retitling the bug to match that.

Should you be interested in going through the process I have described
above, change this bug into an ITP (Intent to Package), prepare the
package and file another bug, a request for sponsorship (RFS) so that
your packaging is reviewed and potentially uploaded.

-- 
Cheers,
  Andrew

Bug#863487: Fwd: TAG: durruter -- NAT/PAT routing helper

[Andrew Shadura]

On 27/05/17 22:24, Narcis Garcia wrote:
> Dear mentors,
> I am looking for a sponsor for my package "durruter"
> 
> Durruter is a command-line wizard to manage iptables entries like in a
> hardware router web interface. Forward ports and ranges from multiple
> interfaces, allow internet traffic from multiple nets to multiple
> network interfaces.
> 
> Works with Debian GNU/Linux since 3.1 upto 9.0
> 
> Complete information and personal sources & packages repository:
> https://www.actiu.net/durruter/
> 
> Thanks for your consideration.

I think you slightly misunderstood what the sponsorship is about. You're
supposed to present a near-ready source package you think is ready to be
uploaded to Debian unstable. Then your package goes through a review
process, you improve it if needed, and then the sponsor uploads it when
you both agree no further improvement is needed at the moment.

-- 
Cheers,
  Andrew

Bug#861236: portaudio19 should build-depend on pkg-config

[Andrew Shadura]

Control: severity -1 minor

On 27 April 2017 at 10:50, Bernhard Schmidt <be...@birkenwald.de> wrote:
> On 26.04.2017 13:37, Andrew Shadura wrote:
>
> Hi Andrew,
>
>> Source: portaudio19
>> Version: 19+svn20140130-1
>> Severity: important
>> Control: found -1 19.6.0-1
>>
>> Dear Maintainer,
>>
>> Since portaudio19 package uses autoreconf, it should build-depend on
>> pkg-config package. Without that dependency, it fails to reconfigure
>> itself:
>>
>> ./configure: line 16045: syntax error near unexpected token `JACK,'
>> ./configure: line 16045: `PKG_CHECK_MODULES(JACK, jack, have_jack=yes, 
>> have_jack=no)'
>> "tail -v -n +0 config.log"
>>

> Hrm, I'm a bit unsure why you would need this, as it is already pulled
> in. portaudio19 build-depends on libjack-dev, and libjack-dev depends on
> pkg-config, so it should already be there. Also the buildd logs show
> that it is getting installed.

Right, we’re building it without JACK, that’s why. In any case, an
explicit dependency is better than an implicit.

-- 
Cheers,
  Andrew

Bug#861236: portaudio19 should build-depend on pkg-config

[Andrew Shadura]

Source: portaudio19
Version: 19+svn20140130-1
Severity: important
Control: found -1 19.6.0-1

Dear Maintainer,

Since portaudio19 package uses autoreconf, it should build-depend on
pkg-config package. Without that dependency, it fails to reconfigure
itself:

./configure: line 16045: syntax error near unexpected token `JACK,'
./configure: line 16045: `PKG_CHECK_MODULES(JACK, jack, have_jack=yes, 
have_jack=no)'
"tail -v -n +0 config.log"

-- 
Cheers,
  Andrew

Bug#861183: [PATCH] redact the build directory out of the glibc-source tarball paths

[Andrew Shadura]

Package: glibc-source
Version: 2.24-10
Severity: important
Tags: patch
Control: affects -1 cross-toolchain-base
X-Debbugs-Cc: Aurelien Jarno <aurel...@aurel32.net>

Hi,

We’re building a downstream distribution based on Debian using OBS, and
it unpacks packages differently than Debian buildds do.

When the tarball for glibc-source package is being created, the
directory name where the package is unpacked may be captured by tar and
embedded into the tarball paths. On its own it may cause further
inconvenience when unpacking the tarball, but quite a practical downside
of that is that one of the Debian packages in affected by
this: cross-toolchain-base fails to unpack glibc tarball, or more
precisely, unpacks it into a different directory compared to what it
expects, and the build fails.

This patch mitigates this issue, replacing the glibc-source tarball path
prefix with glibc-$(GLIBC_VERSION) using tar’s --xform option.


-- 
Cheers,
  Andrew
From 66d1d2d072055613fc3ce83820dea1733377b401 Mon Sep 17 00:00:00 2001
From: Andrew Shadura <andrew.shad...@collabora.co.uk>
Date: Tue, 25 Apr 2017 15:33:45 +0200
Subject: [PATCH] debian/rules.d/build.mk: redact the build directory out of
 the tarball paths

When the tarball for glibc-source package is being created, the
directory name where the package is unpacked may be captured by tar
and embedded into the tarball paths. This may cause further inconvenience
when unpacking the tarball. One of the Debian packages in affected by
this: cross-toolchain-base fails to unpack glibc tarball.

To mitigate the issue, replace the glibc-source tarball path prefix with
glibc-$(GLIBC_VERSION).

Signed-off-by: Andrew Shadura <andrew.shad...@collabora.co.uk>
---
 debian/rules.d/build.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules.d/build.mk b/debian/rules.d/build.mk
index 1e9174e5..792d27c2 100644
--- a/debian/rules.d/build.mk
+++ b/debian/rules.d/build.mk
@@ -324,6 +324,7 @@ $(stamp)source: $(stamp)patch
 			--mode=go=rX,u+rw,a-s \
 			--clamp-mtime --mtime "@$(SOURCE_DATE_EPOCH)" \
 			--owner=root --group=root --numeric-owner \
+			--xform='s=^[^/]*\/=glibc-$(GLIBC_VERSION)/=' \
 			-f $(CURDIR)/$(build-tree)/glibc-$(GLIBC_VERSION).tar.xz
 	mkdir -p debian/glibc-source/usr/src/glibc
 	tar cf - --files-from debian/glibc-source.filelist \
-- 
2.11.0



signature.asc
Description: OpenPGP digital signature

Bug#859441: [pkg-wpa-devel] Bug#859441: wpasupplicant: apply patches to favour througput estimate over snr/strength

[Andrew Shadura]

On 03/04/17 16:47, Jan De Luyck wrote:
> Package: wpasupplicant
> Version: 2:2.4-1
> Severity: normal
> 
> Dear Maintainer,
> 
> There are patches available upstream that change the way wpasupplicant
> picks the network to connect to, in case you have both 5ghz and 2.4ghz
> networks with the same SSID. It'll check throughput, instead of just
> plain SNR/signal strength.
> 
> The following patches on top of wpasupplicant should make this work:
> 
> http://w1.fi/cgit/hostap/commit/?id=b4d56efb1a237e4ed91de97b1615747082de7fd3
> http://w1.fi/cgit/hostap/commit/?id=14204148781cf8e64827eae12dffacc869586073
> 
> Please consider including these.

Ivo, what would you say on this? Is this important enough to have it in
stretch?

Jan, as much as I would like to include them, I've been running
wpa-supplicant without those on a dual-band AP for quite some time, and
it was, well, bearable, so I'm not sure whether we need this on not.

OTOH the patch is about three lines long, modifying two thresholds, so
it shouldn't be a big deal to have.

-- 
Cheers,
  Andrew



signature.asc
Description: OpenPGP digital signature

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

[Andrew Shadura]

I have uploaded the fix to DELAYED/3.

-- 
Cheers,
  Andrew
diff -Nru xfonts-base-1.0.4+nmu1/debian/changelog 
xfonts-base-1.0.4+nmu2/debian/changelog
--- xfonts-base-1.0.4+nmu1/debian/changelog 2015-07-08 18:30:56.0 
+0200
+++ xfonts-base-1.0.4+nmu2/debian/changelog 2017-02-27 13:03:18.0 
+0100
@@ -1,3 +1,10 @@
+xfonts-base (1:1.0.4+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install config.sub/config.guess from autotools-dev (Closes: #856271).
+
+ -- Andrew Shadura <andre...@debian.org>  Mon, 27 Feb 2017 13:03:18 +0100
+
 xfonts-base (1:1.0.4+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru xfonts-base-1.0.4+nmu1/debian/control 
xfonts-base-1.0.4+nmu2/debian/control
--- xfonts-base-1.0.4+nmu1/debian/control   2015-07-08 05:10:51.0 
+0200
+++ xfonts-base-1.0.4+nmu2/debian/control   2017-02-27 12:51:38.0 
+0100
@@ -4,6 +4,7 @@
 Maintainer: Debian X Strike Force <debia...@lists.debian.org>
 Build-Depends:
  debhelper (>= 7),
+ autotools-dev,
 Build-Depends-Indep:
  pkg-config,
  xfonts-utils (>= 1:7.5),
diff -Nru xfonts-base-1.0.4+nmu1/debian/rules 
xfonts-base-1.0.4+nmu2/debian/rules
--- xfonts-base-1.0.4+nmu1/debian/rules 2015-02-01 11:36:32.0 +0100
+++ xfonts-base-1.0.4+nmu2/debian/rules 2017-02-27 12:55:32.0 +0100
@@ -49,6 +49,8 @@
mkdir -p $(STAMP_DIR)
mkdir -p $*-build
cd $*-build && \
+   cp -f /usr/share/misc/config.sub ../$*/config.sub && \
+   cp -f /usr/share/misc/config.guess ../$*/config.guess && \
../$*/configure \
--prefix=/usr \
--mandir=\$${prefix}/share/man \


signature.asc
Description: OpenPGP digital signature

Bug#856281: unblock: xfonts-base/1.0.4+nmu2

[Andrew Shadura]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please unblock package xfonts-base

As reported in #856271, xfonts-base FTBFS on arm64. A tiny patch
fixes that break. I uploaded the fixed package to DELAYED/3.

unblock xfonts-base/1.0.4+nmu2

- -- 
Cheers,
  Andrew

-BEGIN PGP SIGNATURE-

iQExBAEBCAAbBQJYtCYXFBxhbmRyZXdzaEBkZWJpYW4ub3JnAAoJEJ1bI/kYT6UU
1lQH/0AXVoFgK0riaICZcN3D1weoiwVnDge2TswSzomgAJJ7DNTnib2vU/ORF3rl
zojNxeqQ5RZ5exaKXbsJK50nPuo39jZyIVeqZqy/IbnE0MQKjWpvHhUrH+5g6nbn
jxrupDKSS/kyCR5m7xgzfHp9oMdUMzUZz2CmqmddVAM+WPMVv1tXtExQ7euvuHzc
OkavNKLzpSQU8L579bayEgP4ke16CJbG76w67kFCyKy6YajkKBIppfnYz8BNSlGK
gCF+sPwwtoFlJjc8DF6Vzvygp4Ulq/HhKUreGzhTKqxMp4/l45FoH8LsXwJcVjRH
uWAcM+IOgOvh91WcLAQ0phDAeQo=
=HVZB
-END PGP SIGNATURE-
diff -Nru xfonts-base-1.0.4+nmu1/debian/changelog 
xfonts-base-1.0.4+nmu2/debian/changelog
--- xfonts-base-1.0.4+nmu1/debian/changelog 2015-07-08 18:30:56.0 
+0200
+++ xfonts-base-1.0.4+nmu2/debian/changelog 2017-02-27 13:03:18.0 
+0100
@@ -1,3 +1,10 @@
+xfonts-base (1:1.0.4+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install config.sub/config.guess from autotools-dev (Closes: #856271).
+
+ -- Andrew Shadura <andre...@debian.org>  Mon, 27 Feb 2017 13:03:18 +0100
+
 xfonts-base (1:1.0.4+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru xfonts-base-1.0.4+nmu1/debian/control 
xfonts-base-1.0.4+nmu2/debian/control
--- xfonts-base-1.0.4+nmu1/debian/control   2015-07-08 05:10:51.0 
+0200
+++ xfonts-base-1.0.4+nmu2/debian/control   2017-02-27 12:51:38.0 
+0100
@@ -4,6 +4,7 @@
 Maintainer: Debian X Strike Force <debia...@lists.debian.org>
 Build-Depends:
  debhelper (>= 7),
+ autotools-dev,
 Build-Depends-Indep:
  pkg-config,
  xfonts-utils (>= 1:7.5),
diff -Nru xfonts-base-1.0.4+nmu1/debian/rules 
xfonts-base-1.0.4+nmu2/debian/rules
--- xfonts-base-1.0.4+nmu1/debian/rules 2015-02-01 11:36:32.0 +0100
+++ xfonts-base-1.0.4+nmu2/debian/rules 2017-02-27 12:55:32.0 +0100
@@ -49,6 +49,8 @@
mkdir -p $(STAMP_DIR)
mkdir -p $*-build
cd $*-build && \
+   cp -f /usr/share/misc/config.sub ../$*/config.sub && \
+   cp -f /usr/share/misc/config.guess ../$*/config.guess && \
../$*/configure \
--prefix=/usr \
--mandir=\$${prefix}/share/man \

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#856050: unblock: pkgconf/0.9.12-3

[Andrew Shadura]

Control: retitle -1 unblock: pkgconf/0.9.12-4

On 26/02/17 11:19, Niels Thykier wrote:
> Andrew Shadura:
>> Right, I thought that apt replacing one package by the other is a
>> sufficient condition to consider the package correct.
>>
>> Niels, Helmut, how about the diff I attached?

> Ok with me.

I forgot one bit, which is renaming /usr/lib/pkg-config.multiarch to
/usr/lib/pkgconf.multiarch.

The diff is attached.

unblock pkgconf/0.9.12-4

-- 
Cheers,
  Andrew
diff --git a/debian/changelog b/debian/changelog
index e4ffced..e804b68 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pkgconf (0.9.12-4) unstable; urgency=medium
+
+  * Store pkg-config architecture in /usr/lib/pkgconf.multiarch, not
+    pkg-config.multiarch.
+
+ -- Andrew Shadura <andre...@debian.org>  Sun, 26 Feb 2017 13:37:28 +0100
+
 pkgconf (0.9.12-3) unstable; urgency=medium
 
   * Upload to unstable.
diff --git a/debian/pkg-config-crosswrapper b/debian/pkg-config-crosswrapper
index f658fab..0bd6276 100755
--- a/debian/pkg-config-crosswrapper
+++ b/debian/pkg-config-crosswrapper
@@ -12,7 +12,7 @@ if [ x"${PKG_CONFIG_LIBDIR+set}" = x ]; then
   # Normalized multiarch path if any, e.g. i386-linux-gnu for i386
   multiarch="`dpkg-architecture -t"${triplet}" -qDEB_HOST_MULTIARCH 2>/dev/null`"
   # Native multiarch path
-  native_multiarch="$(cat /usr/lib/pkg-config.multiarch)"
+  native_multiarch="$(cat /usr/lib/pkgconf.multiarch)"
 
   # This can be used for native builds as well, in that case, just exec pkg-config "$@" directly.
   if [ "$native_multiarch" = "$multiarch" ]; then
diff --git a/debian/rules b/debian/rules
index d8ae50b..2cfbfeb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -35,6 +35,6 @@ endif
 override_dh_auto_install:
 	dh_auto_install
 	chmod +x debian/pkg-config-crosswrapper debian/pkgconf-dpkghook
-	echo $(DEB_HOST_MULTIARCH) > debian/pkgconf/usr/lib/pkg-config.multiarch
+	echo $(DEB_HOST_MULTIARCH) > debian/pkgconf/usr/lib/pkgconf.multiarch
 
 .PHONY: override_dh_auto_configure override_dh_auto_install


signature.asc
Description: OpenPGP digital signature

Bug#856050: unblock: pkgconf/0.9.12-3

[Andrew Shadura]

On 26/02/17 08:32, Helmut Grohne wrote:
> Looking at the experimental binary package however, I note that I fail
> to find a diversion for pkg-config-dpkghook and its hook-config. Thus
> the experimental package would actually need a conflicts relation now.

> So I consider the experimental package rc buggy and propose either
> renaming the conflicting files or adding a conflicts relation. Since
> neither /usr/share/pkg-config-crosswrapper nor
> /etc/dpkg/dpkg.cfg.d/pkg-config-hook-config are part of the pkg-config
> API, I'd just rename both to avoid the need for diversions here. Even
> when using conflicts, conffiles will not go away and reusing the
> hook-config file from pkg-config can result in a mess of its own. So I
> actually recommend doing the renaming (s/pkg-config/pkgconf/) in any
> case (even when adding conflicts). If you end up using conflicts, all
> the other diversions can go away as well.

Right, I thought that apt replacing one package by the other is a
sufficient condition to consider the package correct.

Niels, Helmut, how about the diff I attached?

-- 
Cheers,
  Andrew
diff --git a/debian/changelog b/debian/changelog
index 17621ae..e4ffced 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pkgconf (0.9.12-3) unstable; urgency=medium
+
+  * Upload to unstable.
+  * Rename dpkg hook and its config to not conflict with pkg-config.
+
+ -- Andrew Shadura <andre...@debian.org>  Sun, 26 Feb 2017 10:57:06 +0100
+
 pkgconf (0.9.12-2) experimental; urgency=medium
 
   * Provide pkg-config-compatible cross-building interface:
diff --git a/debian/pkg-config-dpkghook b/debian/pkgconf-dpkghook
similarity index 100%
rename from debian/pkg-config-dpkghook
rename to debian/pkgconf-dpkghook
diff --git a/debian/pkg-config-hook-config b/debian/pkgconf-hook-config
similarity index 62%
rename from debian/pkg-config-hook-config
rename to debian/pkgconf-hook-config
index b230b27..a0b1a6f 100644
--- a/debian/pkg-config-hook-config
+++ b/debian/pkgconf-hook-config
@@ -1 +1 @@
-post-invoke=if { test "$DPKG_HOOK_ACTION" = add-architecture || test "$DPKG_HOOK_ACTION" = remove-architecture; } && test -x /usr/share/pkg-config-dpkghook; then /usr/share/pkg-config-dpkghook update; fi
+post-invoke=if { test "$DPKG_HOOK_ACTION" = add-architecture || test "$DPKG_HOOK_ACTION" = remove-architecture; } && test -x /usr/share/pkgconf-dpkghook; then /usr/share/pkgconf-dpkghook update; fi
diff --git a/debian/pkgconf.install b/debian/pkgconf.install
index ddbdbcf..b8a30d3 100644
--- a/debian/pkgconf.install
+++ b/debian/pkgconf.install
@@ -1,3 +1,3 @@
 debian/pkg-config-crosswrapper usr/share
-debian/pkg-config-dpkghook usr/share
-debian/pkg-config-hook-config etc/dpkg/dpkg.cfg.d/
+debian/pkgconf-dpkghook usr/share
+debian/pkgconf-hook-config etc/dpkg/dpkg.cfg.d/
diff --git a/debian/postinst b/debian/postinst
index 66fd489..1df5b58 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -5,5 +5,5 @@ set -e
 #DEBHELPER#
 
 if test "$1" = configure; then
-/usr/share/pkg-config-dpkghook update
+/usr/share/pkgconf-dpkghook update
 fi
diff --git a/debian/prerm b/debian/prerm
index 853dacb..ea53003 100644
--- a/debian/prerm
+++ b/debian/prerm
@@ -5,5 +5,5 @@ set -e
 #DEBHELPER#
 
 if test "$1" = remove; then
-/usr/share/pkg-config-dpkghook remove
+/usr/share/pkgconf-dpkghook remove
 fi
diff --git a/debian/rules b/debian/rules
index 582fca5..d8ae50b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,7 +34,7 @@ endif
 
 override_dh_auto_install:
 	dh_auto_install
-	chmod +x debian/pkg-config-crosswrapper debian/pkg-config-dpkghook
+	chmod +x debian/pkg-config-crosswrapper debian/pkgconf-dpkghook
 	echo $(DEB_HOST_MULTIARCH) > debian/pkgconf/usr/lib/pkg-config.multiarch
 
 .PHONY: override_dh_auto_configure override_dh_auto_install

Bug#856050: unblock: pkgconf/0.9.12-3

[Andrew Shadura]

On 25/02/17 08:35, Niels Thykier wrote:
> Control: tags -1 moreinfo
> 
> Andrew Shadura:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>>
>> Please unblock package pkgconf.
>>
>> Since pkg-config (= 0.29-1), pkg-config package provides
>> /usr/bin/$DEB_HOST_GNU_TYPE-pkg-config symlinks as explained in #842529.
>> Build tools already expect those symlinks in place, which causes random build
>> failures when pkgconf is pulled instead of pkg-config.
>>
>> This upload fixes the issue by syncing cross-wrapper from pkg-config,
>> adopting dpkg hook from pkg-config and preventing pkg-config from being
>> co-installed with pkgconf:
>>
>> [...]
>>
>> Thanks.
>>
>> unblock pkgconf/0.9.12-3

> Thanks for providing this fix.
> 
> I got one question about the "Breaks".  Why Breaks and why a versioned
> breaks rather than an unconditional Conflicts?  AFAICT, pkgconf attempts
> to be an "mutually exclusive alternative" to pkg-config (a la exim vs.
> postfix).

Hmm, honestly, I'm not sure what's better in this case. In #842529,
Helmut mentioned Breaks, so I just went with that. As it is now, pkgconf
is still co-installable with earlier versions of pkg-config (diversions
are still in place), but the symlinks make it not possible to have both
pkg-config 0.29-1 and pkgconf installed (and that's not really needed
anymore as I added the versioned Provides).

If you think Conflicts is more appropriate, I may add change that in the
upload to unstable.

Helmut, what's your opinion, by the way?

-- 
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#855836: decopy attempts to parse Python 2 sources with Python 3 and fails

[Andrew Shadura]

Package: decopy
Version: 0.2-1
Severity: important

Dear Maintainer,

I'm trying to use decopy on a Python 2 package, and it fails, as it seems it 
attempts
to parse its Python code with Python 3 parser:

$ decopy 
Traceback (most recent call last):
  File "/usr/bin/decopy", line 11, in 
load_entry_point('Decopy==0.1', 'console_scripts', 'decopy')()
  File "/usr/lib/python3/dist-packages/decopy/decopy.py", line 62, in main
filetree.process(options)
  File "/usr/lib/python3/dist-packages/decopy/tree.py", line 369, in process
item.process_licenses(self.root, options)
  File "/usr/lib/python3/dist-packages/decopy/tree.py", line 175, in 
process_licenses
copyrights, licenses = parse_file(fullpath, options)
  File "/usr/lib/python3/dist-packages/decopy/parsers.py", line 155, in 
parse_file
copyrights, licenses = parser(fullname)
  File "/usr/lib/python3/dist-packages/decopy/parsers.py", line 62, in 
python_parser
for token in tokenize.tokenize(f.readline):
  File "/usr/lib/python3.5/tokenize.py", line 580, in _tokenize
("", lnum, pos, line))
  File "", line 176
print "SSRC spammer started"
^
IndentationError: Missing parentheses in call to 'print'

-- System Information:

Versions of packages decopy depends on:
ii  bzip2   1.0.6-8build1
ii  exiv2   0.25-3
ii  python3-debian  0.1.29
ii  python3-xdg 0.25-4
pn  python3:any 
ii  xz-utils5.1.1alpha+20120614-2

Bug#830601: Interested to assist in packaging matrix-synapse

[Andrew Shadura]

Hi Rahul and Sunil,

On 20 February 2017 at 07:38, Rahul De  wrote:
> Thank you for taking up packaging of matrix-synapse.  Dependencies for
> matrix-synapse seems to be mostly packaged by you. Sunil and I,
> contributors to the FreedomBox, are interested in helping out with the
> packaging effort of matrix-synapse server.  Could you please let know
> if you have source repository for the Debian packaging work you are
> doing? We could help by testing and submitting patches. So far, we
> found out-of-debian packaging effort to have progressed significantly:
> https://github.com/matrix-org/package-synapse-debian

Thanks for your offer. I have pulled your changes and incorporated most
of them into my packaging repo, which will be soon available at the
following URL:

https://anonscm.debian.org/cgit/collab-maint/matrix-synapse.git/

I have also uploaded matrix-synapse to NEW, I hope it gets approved soon.

-- 
Cheers,
  Andrew



signature.asc
Description: OpenPGP digital signature

Bug#855605: rtkit uses dbus_message_new_error_printf unsafely

[Andrew Shadura]

On 21/02/17 04:03, Felipe Sateler wrote:
> On Mon, Feb 20, 2017 at 3:28 PM, Andrew Shadura
> <andrew.shad...@collabora.co.uk> wrote:
>> rtkit uses dbus_message_new_error_printf in an unsafe way, which also causes
>> it to FTBFS when it builds against a newer dbus version (e.g. 1.11.8 and
>> newer, available in experimental):

> Do you consider this something that should be fixed in stretch? I just
> realized I have a pile of pending changes that are not appropriate for
> the freeze, so I'd have to prepare an upload for this.

It's up to you. We fixed this in the downstream package, whether this
warrants an update for stretch or not is something you and release team
to decide.

> In any case I applied your patch to the git repo.

Thanks!

-- 
Cheers,
  Andrew



signature.asc
Description: OpenPGP digital signature

Bug#855605: rtkit uses dbus_message_new_error_printf unsafely

[Andrew Shadura]

Package: rtkit
Version: 0.11-4
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

rtkit uses dbus_message_new_error_printf in an unsafe way, which also causes
it to FTBFS when it builds against a newer dbus version (e.g. 1.11.8 and
newer, available in experimental):

/usr/src/packages/BUILD/rtkit-0.11/./rtkit-daemon.c: In function 'dbus_handler':
/usr/src/packages/BUILD/rtkit-0.11/./rtkit-daemon.c:1336:25: error: format not 
a string literal and no format arguments [-Werror=format-security]
 assert_se(r = dbus_message_new_error_printf(m, 
translate_error_forward(ret), strerror(-ret)));
 ^
/usr/src/packages/BUILD/rtkit-0.11/./rtkit-daemon.c:1361:25: error: format not 
a string literal and no format arguments [-Werror=format-security]
 assert_se(r = dbus_message_new_error_printf(m, 
translate_error_forward(ret), strerror(-ret)));
 ^
/usr/src/packages/BUILD/rtkit-0.11/./rtkit-daemon.c:1366:25: error: format not 
a string literal and no format arguments [-Werror=format-security]
 assert_se(r = dbus_message_new_error_printf(m, 
translate_error_forward(ret), strerror(-ret)));
 ^
/usr/src/packages/BUILD/rtkit-0.11/./rtkit-daemon.c:1371:25: error: format not 
a string literal and no format arguments [-Werror=format-security]
 assert_se(r = dbus_message_new_error_printf(m, 
translate_error_forward(ret), strerror(-ret)));
 ^
/usr/src/packages/BUILD/rtkit-0.11/./rtkit-daemon.c:1388:25: error: format not 
a string literal and no format arguments [-Werror=format-security]
 assert_se(r = dbus_message_new_error_printf(m, 
translate_error_forward(ret), strerror(-ret)));
 ^
/usr/src/packages/BUILD/rtkit-0.11/./rtkit-daemon.c:1413:25: error: format not 
a string literal and no format arguments [-Werror=format-security]
 assert_se(r = dbus_message_new_error_printf(m, 
translate_error_forward(ret), strerror(-ret)));
 ^
/usr/src/packages/BUILD/rtkit-0.11/./rtkit-daemon.c:1418:25: error: format not 
a string literal and no format arguments [-Werror=format-security]
 assert_se(r = dbus_message_new_error_printf(m, 
translate_error_forward(ret), strerror(-ret)));
 ^
/usr/src/packages/BUILD/rtkit-0.11/./rtkit-daemon.c:1423:25: error: format not 
a string literal and no format arguments [-Werror=format-security]
 assert_se(r = dbus_message_new_error_printf(m, 
translate_error_forward(ret), strerror(-ret)));
 ^

Please find an attached patch to fix it.

- -- 
Cheers,
  Andrew

-BEGIN PGP SIGNATURE-

iQI8BAEBCAAmBQJYqzVrHxxhbmRyZXcuc2hhZHVyYUBjb2xsYWJvcmEuY28udWsA
CgkQQWcbs0qEk4G3FhAAzXBp0ljgzhQ6c5rsUsYzLMHU0fumzp3PNX0Ta6OkUOe0
6DShV8EEI81ejLiViaVnvyoJ5ThwpbcYojRYXws0lDCn7xmqdRspB3zCrgnmWc34
naI1UyP/Nvk1QqVGWP91ZKh31BHjp2UHGeknLwA2e87ausZvAqAdH/5b81J3moRs
0FtEGj3qT+IUnYPqdaS1rMsqUeTP9ePuI8r8qbnjYxJ9pomcIspCBcNculJThO/1
MQnGcLnLjCxtJl7vQ8EDajLgpmv+zn+oD33FEMxMdl4aB25jU/YolFe/g3ijK9jP
4Mj6AIB7yIWsL8p+wDi/BfRkKHoXQNzMb+Lwe1WuTTcBjVcggpYe6IsTF9Ux9MA/
hSilxWiuj3ahIi/qboWvmZHGG3+F68Vcr0AC/7VxtDiKMgf45lkRLp4xF+S3WMFW
y871BCOz21LqUi1jXZK+ab6IYN6FoqwSPhsxrvCv8PzC56pLU5+tgp68ADrTkhZo
6w4luPWjkYu7otxsQ95vI2BeVVXdpGBSrkSciTI1KFOdzgnfxFCHFAT9p+FQlmS2
1lQe4O3x4JAtAfrZ4zB/JDPdRYUWSb0FK25F03jZ361DOnfnSbvSvDmIi05CscM3
82xjg8gjfP8QGjLDb/EYMaFzhOD3cVPXyL4OefXMcoFHDeNFoXVAdDUY3G4yVAs=
=RfGv
-END PGP SIGNATURE-
diff -Nru rtkit-0.11/debian/changelog rtkit-0.11/debian/changelog
--- rtkit-0.11/debian/changelog	2015-10-24 23:44:21.0 +0200
+++ rtkit-0.11/debian/changelog	2017-02-20 19:15:34.0 +0100
@@ -1,3 +1,11 @@
+rtkit (0.11-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add a format string to dbus_message_new_error_printf (fixes an FTBFS due to
+-Werror=format-security).
+
+ -- Andrew Shadura <andre...@debian.org>  Mon, 20 Feb 2017 19:15:34 +0100
+
 rtkit (0.11-4) unstable; urgency=medium
 
   * Remove stale ubuntu.series file.
diff -Nru rtkit-0.11/debian/patches/0006-fix-format-strings.patch rtkit-0.11/debian/patches/0006-fix-format-strings.patch
--- rtkit-0.11/debian/patches/0006-fix-format-strings.patch	1970-01-01 01:00:00.0 +0100
+++ rtkit-0.11/debian/patches/0006-fix-format-strings.patch	2017-02-20 19:15:34.0 +0100
@@ -0,0 +1,68 @@
+From: Andrew Shadura <andrew.shad...@collabora.co.uk>
+Date: Mon, 20 Feb 2017 19:17:18 +0100
+Subject: Add a format string to dbus_message_new_error_printf (fixes an FTBFS
+ due to -Werror=format-security).
+Forwarded: no
+
+--- a/rtkit-daemon.c
 b/rtkit-daemon.c
+@@ -1333,7 +1333,7 @@
+ int ret;
+ 
+ if ((ret = verify_canary_refusal()) < 0) {
+-

Bug#855143: unblock: wpa/2.5-2+v2.4-4stretch1

[Andrew Shadura]

On 20/02/17 08:18, Andrew Shadura wrote:
>> Please upload a targeted fix to unstable.

I have thought about this a bit more. Even though I don't really like
the epoch idea, it's an opportunity to clean up the package version a
bit (1:2.4-1 instead of 2.5-2+v2.4-4stretch1, or even 2:2.4-1 to
accommodate an existing epoch in hostapd package). How about this debdiff?

-- 
Cheers,
  Andrew
diff -Nru wpa-2.5-2+v2.4/debian/changelog wpa-2.4/debian/changelog
--- wpa-2.5-2+v2.4/debian/changelog 2016-09-14 11:11:05.0 +0200
+++ wpa-2.4/debian/changelog2017-02-20 11:55:12.0 +0100
@@ -1,3 +1,21 @@
+wpa (2:2.4-1) unstable; urgency=medium
+
+  [ Vincent Danjean ]
+  * Build with libssl1.0-dev (Closes: #828601).
+  * Add an upstream patch to fix hostapd in SMPS mode (Closes: #854719).
+
+  [ Andrew Shadura ]
+  * Don't install debian/system-sleep/wpasupplicant (originally introduced
+to fix LP: #1422143), it doesn't improve the state of the things,
+introduces regressions in some cases, and at all isn't supposed to
+work with how wpa-supplicant is started these days (Closes: #835648).
+  * Bump the epoch to 2:, so that we can set the upstream version to
+what we really mean. It also has to be higher than 2.6 in unstable
+and 1:2.6 (what hostapd binary package in unstable has).
+  * Drop the binary package epoch override.
+
+ -- Andrew Shadura <andre...@debian.org>  Mon, 20 Feb 2017 11:55:11 +0100
+
 wpa (2.5-2+v2.4-3) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru wpa-2.5-2+v2.4/debian/control wpa-2.4/debian/control
--- wpa-2.5-2+v2.4/debian/control   2016-08-05 20:43:38.0 +0200
+++ wpa-2.4/debian/control  2017-02-14 17:02:28.0 +0100
@@ -8,7 +8,7 @@
 Priority: optional
 Build-Depends: debhelper (>> 9.20120115),
  libdbus-1-dev,
- libssl-dev,
+ libssl1.0-dev,
  libqt4-dev,
  libncurses5-dev,
  libpcsclite-dev,
diff -Nru 
wpa-2.5-2+v2.4/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch 
wpa-2.4/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch
--- wpa-2.5-2+v2.4/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch 
1970-01-01 01:00:00.0 +0100
+++ wpa-2.4/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch
2017-02-14 17:07:16.0 +0100
@@ -0,0 +1,56 @@
+From: Jouni Malinen <jo...@qca.qualcomm.com>
+Date: Fri Mar 18 16:16:40 2016 +0200
+Subject: nl80211: Do not add NL80211_ATTR_SMPS_MODE attribute if HT is disabled
+
+SMPS mode is applicable only for HT and including an attribute to
+configure it when HT is disabled could result in the AP start operation
+failing. Fix this by adding the attribute only in cases where HT is
+enabled.
+
+Upstream commit ee298f1b1f7efd7eb5fd510f36b25ff88208017c
+--- a/src/drivers/driver_nl80211.c
 b/src/drivers/driver_nl80211.c
+@@ -3419,24 +3419,26 @@
+   nla_put_u32(msg, NL80211_ATTR_CIPHER_SUITE_GROUP, suite))
+   goto fail;
+ 
+-  switch (params->smps_mode) {
+-  case HT_CAP_INFO_SMPS_DYNAMIC:
+-  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - dynamic");
+-  smps_mode = NL80211_SMPS_DYNAMIC;
+-  break;
+-  case HT_CAP_INFO_SMPS_STATIC:
+-  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - static");
+-  smps_mode = NL80211_SMPS_STATIC;
+-  break;
+-  default:
+-  /* invalid - fallback to smps off */
+-  case HT_CAP_INFO_SMPS_DISABLED:
+-  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - off");
+-  smps_mode = NL80211_SMPS_OFF;
+-  break;
++  if (params->ht_opmode != -1) {
++  switch (params->smps_mode) {
++  case HT_CAP_INFO_SMPS_DYNAMIC:
++  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - dynamic");
++  smps_mode = NL80211_SMPS_DYNAMIC;
++  break;
++  case HT_CAP_INFO_SMPS_STATIC:
++  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - static");
++  smps_mode = NL80211_SMPS_STATIC;
++  break;
++  default:
++  /* invalid - fallback to smps off */
++  case HT_CAP_INFO_SMPS_DISABLED:
++  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - off");
++  smps_mode = NL80211_SMPS_OFF;
++  break;
++  }
++  if (nla_put_u32(msg, NL80211_ATTR_SMPS_MODE, smps_mode))
++  goto fail;
+   }
+-  if (nla_put_u32(msg, NL80211_ATTR_SMPS_MODE, smps_mode))
+-  goto fail;
+ 
+   if (params->beacon_ies) {
+   wpa_hexdump_buf(MSG_DEBUG, "nl80211: beacon_ies",
diff -Nru wpa-2.5-2+v2.4/debian/patches/series wpa-2.4/debian/patches/series
--- wpa-2.5-2+v2.4/debian/patches/series2016-08-09 20:48:10.0

Bug#855143: unblock: wpa/2.5-2+v2.4-4stretch1

[Andrew Shadura]

On 20/02/17 00:08, Ivo De Decker wrote:
> We really, really want to avoid going through t-p-u if at all possible. In
> this case, there doesn't seem to be a real issue with doing a revert in
> unstable. There isn't really any point in having a version in unstable that
> isn't meant for testing. The 2.6 version can go to experimental.

It was meant for testing, but unfortunately the issues with it turned
out to be more serious than I thought, which is why I decided to stick
with an older version for now.

> As for the confusion, this can be avoided by using an epoch instead
> of the version you're using now (but that is really your call).

It was already in experimental, and it went to unstable at the point
when it seemed it had enough of testing, but it turned out it didn't. As
for the epoch, I'm not sure it's a good idea, as the package already
uses it in a bit inconsistent way (for one of the binary packages only).

On the other hand, all fixes I'm including are backports of fixes
included in the version currently in unstable.

> Please upload a targeted fix to unstable.

-- 
Cheers,
  Andrew

Bug#855534: unblock: multiple packages, didn't make it to testing due to openssl1.1

[Andrew Shadura]

Hi,

On 19 February 2017 at 22:25, Sebastian Andrzej Siewior
 wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: unblock
> Severity: normal
>
> I hope it is okay, to open one bug instead of three:
> - libdigidoc
>   removed from testing [0] not sure why. Adrian Bunk NMUed it to to
>   build with libssl1.0-dev

Please no. If you read the bug tracker, you would know it was
intentional. This package is a part of a set of packages I intended to
package but never finished, and having it in Debian may make it more
difficult for the upstream to provide their own third party repository.
That is why I decided to remove it from testing for now. Please don't
revert that.

-- 
Cheers,
  Andrew

Bug#855143: unblock: wpa/2.5-2+v2.4-4stretch1

[Andrew Shadura]

On 19 Feb 2017 23:15, "Ivo De Decker" <iv...@debian.org> wrote:

Control: tags -1 moreinfo

Hi Andrew,

On Tue, Feb 14, 2017 at 05:25:42PM +0100, Andrew Shadura wrote:
> Please unblock package wpa.

> This fix has to go through testing-proposed-updates.

Why? Is there any reason you can't just revert the version in unstable? That
way we don't have to push a new untested upload to stretch. If this upload
goes through unstable, there is a higher change that issues are detected
(and
fixed).


Because the version in unstable is a new upstream version, and the version
in testing is already a revert of a newer upstream version. I don't want to
confuse things even more.

The changes I propose are quite minimal, and the version we have in testing
has been there for quite some time already. I don't think there's a high
risk of introducing a regression with a bug fix.

-- 
Cheers,
Andrew

Bug#855143: unblock: wpa/2.5-2+v2.4-4stretch1

[Andrew Shadura]

On 14/02/17 17:25, Andrew Shadura wrote:
> This fix has to go through testing-proposed-updates.
> 
> Thanks for considering.
> 
> unblock wpa/2.5-2+v2.4-4stretch1

Sorry, the debdiff I attached was made against a never released version
of the package (differing only in the version number). Attaching the
correct one.

-- 
Cheers,
  Andrew
diff -Nru wpa-2.5-2+v2.4/debian/changelog wpa-2.5-2+v2.4/debian/changelog
--- wpa-2.5-2+v2.4/debian/changelog 2016-09-14 11:11:05.0 +0200
+++ wpa-2.5-2+v2.4/debian/changelog 2017-02-14 17:10:53.0 +0100
@@ -1,3 +1,17 @@
+wpa (2.5-2+v2.4-4stretch1) testing; urgency=medium
+
+  [ Vincent Danjean ]
+  * Build with libssl1.0-dev (Closes: #828601).
+  * Add an upstream patch to fix hostapd in SMPS mode (Closes: #854719).
+
+  [ Andrew Shadura ]
+  * Don't install debian/system-sleep/wpasupplicant (originally introduced
+to fix LP: #1422143), it doesn't improve the state of the things,
+introduces regressions in some cases, and at all isn't supposed to
+work with how wpa-supplicant is started these days (Closes: #835648).
+
+ -- Andrew Shadura <andre...@debian.org>  Tue, 14 Feb 2017 17:10:53 +0100
+
 wpa (2.5-2+v2.4-3) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru wpa-2.5-2+v2.4/debian/control wpa-2.5-2+v2.4/debian/control
--- wpa-2.5-2+v2.4/debian/control   2016-08-05 20:43:38.0 +0200
+++ wpa-2.5-2+v2.4/debian/control   2017-02-14 17:02:28.0 +0100
@@ -8,7 +8,7 @@
 Priority: optional
 Build-Depends: debhelper (>> 9.20120115),
  libdbus-1-dev,
- libssl-dev,
+ libssl1.0-dev,
  libqt4-dev,
  libncurses5-dev,
  libpcsclite-dev,
diff -Nru 
wpa-2.5-2+v2.4/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch 
wpa-2.5-2+v2.4/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch
--- wpa-2.5-2+v2.4/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch 
1970-01-01 01:00:00.0 +0100
+++ wpa-2.5-2+v2.4/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch 
2017-02-14 17:07:16.0 +0100
@@ -0,0 +1,56 @@
+From: Jouni Malinen <jo...@qca.qualcomm.com>
+Date: Fri Mar 18 16:16:40 2016 +0200
+Subject: nl80211: Do not add NL80211_ATTR_SMPS_MODE attribute if HT is disabled
+
+SMPS mode is applicable only for HT and including an attribute to
+configure it when HT is disabled could result in the AP start operation
+failing. Fix this by adding the attribute only in cases where HT is
+enabled.
+
+Upstream commit ee298f1b1f7efd7eb5fd510f36b25ff88208017c
+--- a/src/drivers/driver_nl80211.c
 b/src/drivers/driver_nl80211.c
+@@ -3419,24 +3419,26 @@
+   nla_put_u32(msg, NL80211_ATTR_CIPHER_SUITE_GROUP, suite))
+   goto fail;
+ 
+-  switch (params->smps_mode) {
+-  case HT_CAP_INFO_SMPS_DYNAMIC:
+-  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - dynamic");
+-  smps_mode = NL80211_SMPS_DYNAMIC;
+-  break;
+-  case HT_CAP_INFO_SMPS_STATIC:
+-  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - static");
+-  smps_mode = NL80211_SMPS_STATIC;
+-  break;
+-  default:
+-  /* invalid - fallback to smps off */
+-  case HT_CAP_INFO_SMPS_DISABLED:
+-  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - off");
+-  smps_mode = NL80211_SMPS_OFF;
+-  break;
++  if (params->ht_opmode != -1) {
++  switch (params->smps_mode) {
++  case HT_CAP_INFO_SMPS_DYNAMIC:
++  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - dynamic");
++  smps_mode = NL80211_SMPS_DYNAMIC;
++  break;
++  case HT_CAP_INFO_SMPS_STATIC:
++  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - static");
++  smps_mode = NL80211_SMPS_STATIC;
++  break;
++  default:
++  /* invalid - fallback to smps off */
++  case HT_CAP_INFO_SMPS_DISABLED:
++  wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - off");
++  smps_mode = NL80211_SMPS_OFF;
++  break;
++  }
++  if (nla_put_u32(msg, NL80211_ATTR_SMPS_MODE, smps_mode))
++  goto fail;
+   }
+-  if (nla_put_u32(msg, NL80211_ATTR_SMPS_MODE, smps_mode))
+-  goto fail;
+ 
+   if (params->beacon_ies) {
+   wpa_hexdump_buf(MSG_DEBUG, "nl80211: beacon_ies",
diff -Nru wpa-2.5-2+v2.4/debian/patches/lowercase-mschapv2.patch 
wpa-2.5-2+v2.4/debian/patches/lowercase-mschapv2.patch
--- wpa-2.5-2+v2.4/debian/patches/lowercase-mschapv2.patch  1970-01-01 
01:00:00.0 +0100
+++ wpa-2.5-2+v2.4/debian/patches/lowercase-mschapv2.patch  2017-01-20 
21:32:38.0 +0100
@@ -0,0 +1,19 @@
+From: Andrew Shadura <andre...@debian.org>
+Subj

Bug#855143: unblock: wpa/2.5-2+v2.4-4stretch1

[Andrew Shadura]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please unblock package wpa.

wpa-supplicant 2.6 brought some regressions making it unfit for stretch,
so I decided to keep 2.4 in testing. However, two minor fixes didn't
make it into 2.4 package, and later a grave bug was found in 2.4
compared to 2.3 jessie ships. Because of this I'm asking to unblock a
version that fixes these bugs:

  * Build with libssl1.0-dev (Closes: #828601).

Without this fix, it wouldn't be possible to build the following
fix.

  * Add an upstream patch to fix hostapd in SMPS mode (Closes: #854719).

This is a grave bug which breaks hostapd presumably for many users.

  * Don't install debian/system-sleep/wpasupplicant (originally introduced
to fix LP: #1422143), it doesn't improve the state of the things,
introduces regressions in some cases, and at all isn't supposed to
work with how wpa-supplicant is started these days (Closes: #835648).

This bug slows down shutdown for many users, and as the fix is just
not installing a single file, I don't see a reason to not ship it.

This fix has to go through testing-proposed-updates.

Thanks for considering.

unblock wpa/2.5-2+v2.4-4stretch1

- -- 
Cheers,
  Andrew

-BEGIN PGP SIGNATURE-

iQExBAEBCAAbBQJYoy+GFBxhbmRyZXdzaEBkZWJpYW4ub3JnAAoJEJ1bI/kYT6UU
1tYH/3h8eaMFB386jUQtIXvAZbruzSm29FlDlXslMgaSX1SaBqbIYS2frxJ6RfvT
lU5A5gtaNMqA+TjFeump0sHPjLiwDhNnyDJFgZx9XNqDdedBpaEDRQf6ffv02j1P
WyY7AZFT+Kw7gijwujx4Bb35oeFUgDUWQ7MvDB10gbhPmRVM2kT2YryVNIwkyGhR
mflwqXw7AsK3dcVo0BCGPrxIMy9Jl4oKxTUVLeQwtOQr5jy2HlOSyt6Vz396bkFq
aerMYFkk0m2SEITddDbwMybYD+Xv0tiLyAfOeL4HFswmCiMW26BEk2HzI5OREOdK
vtDHQ7P1mSS5BTUKbn8LNwqn2lc=
=CZE0
-END PGP SIGNATURE-
diff -Nru wpa-2.5-2+v2.4/debian/changelog wpa-2.5-2+v2.4/debian/changelog
--- wpa-2.5-2+v2.4/debian/changelog	2016-09-14 11:08:29.0 +0200
+++ wpa-2.5-2+v2.4/debian/changelog	2017-02-14 17:10:53.0 +0100
@@ -1,4 +1,18 @@
-wpa (2.5-2+v2.4-4) unstable; urgency=medium
+wpa (2.5-2+v2.4-4stretch1) testing; urgency=medium
+
+  [ Vincent Danjean ]
+  * Build with libssl1.0-dev (Closes: #828601).
+  * Add an upstream patch to fix hostapd in SMPS mode (Closes: #854719).
+
+  [ Andrew Shadura ]
+  * Don't install debian/system-sleep/wpasupplicant (originally introduced
+to fix LP: #1422143), it doesn't improve the state of the things,
+introduces regressions in some cases, and at all isn't supposed to
+work with how wpa-supplicant is started these days (Closes: #835648).
+
+ -- Andrew Shadura <andre...@debian.org>  Tue, 14 Feb 2017 17:10:53 +0100
+
+wpa (2.5-2+v2.4-3) unstable; urgency=medium
 
   [ Helmut Grohne ]
   * Address FTCBFS: Set PKG_CONFIG (Closes: #836074).
@@ -7,7 +21,7 @@
   * Don't run wpa_cli suspend/resume if /run/wpa_supplicant isn't around
 (Closes: #835648).
 
- -- Andrew Shadura <andre...@debian.org>  Wed, 14 Sep 2016 11:08:27 +0200
+ -- Andrew Shadura <andre...@debian.org>  Wed, 14 Sep 2016 11:11:01 +0200
 
 wpa (2.5-2+v2.4-2) unstable; urgency=medium
 
diff -Nru wpa-2.5-2+v2.4/debian/control wpa-2.5-2+v2.4/debian/control
--- wpa-2.5-2+v2.4/debian/control	2016-08-05 20:43:38.0 +0200
+++ wpa-2.5-2+v2.4/debian/control	2017-02-14 17:02:28.0 +0100
@@ -8,7 +8,7 @@
 Priority: optional
 Build-Depends: debhelper (>> 9.20120115),
  libdbus-1-dev,
- libssl-dev,
+ libssl1.0-dev,
  libqt4-dev,
  libncurses5-dev,
  libpcsclite-dev,
diff -Nru wpa-2.5-2+v2.4/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch wpa-2.5-2+v2.4/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch
--- wpa-2.5-2+v2.4/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch	1970-01-01 01:00:00.0 +0100
+++ wpa-2.5-2+v2.4/debian/patches/from-upstream-hostapd-fix-SMPS-mode.patch	2017-02-14 17:07:16.0 +0100
@@ -0,0 +1,56 @@
+From: Jouni Malinen <jo...@qca.qualcomm.com>
+Date: Fri Mar 18 16:16:40 2016 +0200
+Subject: nl80211: Do not add NL80211_ATTR_SMPS_MODE attribute if HT is disabled
+
+SMPS mode is applicable only for HT and including an attribute to
+configure it when HT is disabled could result in the AP start operation
+failing. Fix this by adding the attribute only in cases where HT is
+enabled.
+
+Upstream commit ee298f1b1f7efd7eb5fd510f36b25ff88208017c
+--- a/src/drivers/driver_nl80211.c
 b/src/drivers/driver_nl80211.c
+@@ -3419,24 +3419,26 @@
+ 	nla_put_u32(msg, NL80211_ATTR_CIPHER_SUITE_GROUP, suite))
+ 		goto fail;
+ 
+-	switch (params->smps_mode) {
+-	case HT_CAP_INFO_SMPS_DYNAMIC:
+-		wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - dynamic");
+-		smps_mode = NL80211_SMPS_DYNAMIC;
+-		break;
+-	case HT_CAP_INFO_SMPS_STATIC:
+-		wpa_printf(MSG_DEBUG, "nl80211: SMPS mode - static");
+-		smps_mode = NL80211_SMPS_STATIC;
+-		break;
+-	default:
+-		/* invalid - fallback to smps off */
+-	case HT_CAP_INFO_SM

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#830601: Processed: RFP: matrix-synapse -- reference homeserver for Matrix real-time communication standard

[Andrew Shadura]

Control: owner -1 !

On 8 February 2017 at 17:21, Debian Bug Tracking System
 wrote:
> Processing commands for cont...@bugs.debian.org:
>
>> noowner 830601

Bart, could you please explain yourself?

-- 
Cheers,
  Andrew

Bug#830601: RFP: matrix-synapse -- reference homeserver for Matrix real-time communication standard

[Andrew Shadura]

Control: owner -1 !

On Sat, 09 Jul 2016 14:37:36 -0400 James Valleroy 
wrote:
> Package: wnpp
> Severity: wishlist
>
> * Package name: matrix-synapse
>   Version : 0.16.1-r1
>   Upstream Author : Erik Johnston  and others
> * URL : https://matrix.org/
> * License : Apache 2.0
>   Programming Lang: Python
>   Description : reference homeserver for Matrix real-time
communication
> standard
>
> Matrix is an open standard for interoperable, decentralised, real-time
> communication over IP. It can be used to power Instant Messaging,
VoIP/WebRTC
> signalling, Internet of Things communication - or anywhere you need a
standard
> HTTP API for publishing and subscribing to data whilst tracking the
> conversation history.
>
> Synapse is a reference “homeserver†implementation of Matrix from the
core
> development team at matrix.org, written in Python 2/Twisted. It is
intended to
> showcase the concept of Matrix and let folks see the spec in the context
of a
> codebase and let you run your own homeserver and generally help bootstrap
the
> ecosystem.
>
> There is already some deb packaging available at:
> https://github.com/matrix-org/package-synapse-debian/tree/debian

I think I'll give it a go.

-- 
Cheers,
  Andrew

Bug#854181: RFH: busybox -- Tiny utilities for small and embedded systems

[Andrew Shadura]

Hi,

On 4 Feb 2017 19:16, "Cyril Brulebois"  wrote:

Package: wnpp
Severity: normal

Hi,

We're entering the deep freeze in a few hours, and this mail should have
been sent a while ago, but let's not delay this any further: the Debian
Installer team requests assistance with maintaining the busybox package.
[ So please make sure to include debian-b...@lists.debian.org in copy
if you're replying to this message. ]


I think I could help. I'll have a look when I'm home from FOSDEM.

-- 
Cheers.

Bug#852669: general: The sound isn't working .. This is a permenant OS

[Andrew Shadura]

Control: tag -1 moreinfo

It seems you have forgotten to fill out the template below. Please add
more information about your failure, otherwise we can't help you.

On 26 January 2017 at 10:24, ETH_15Q  wrote:
> Package: general
> Severity: minor
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation? From the beginning the situation was prese
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? I tried installing alsa utilities
>* What was the outcome of this action? Nothing
>* What outcome did you expect instead? Working of the sound
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information: Distributor ID:  Kali Description:   Kali
> GNU/Linux Rolling Release:  kali-rolling Codename:  kali-rolling
> Architecture: x86_64
>
> Kernel: Linux 4.6.0-kali1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>



-- 
Cheers,
  Andrew

Bug#849511: Fwd: Bug#849511: general: java and javac can't run , it said "java: error while loading shared libraries: libjli.so",

[Andrew Shadura]

Please don't email me personally. I asked you to provide more
information, but that doesn't necessarily mean I'm the person who will
be able to help you.

One thing I can tell you is that Debian doesn't ship Oracle JDK, and
we can't provide support for it. And why do you use it when Debian
already ships Java?

-- Forwarded message --
From: Jason Yu <katcom...@gmail.com>
Date: 26 January 2017 at 09:53
Subject: Re: Bug#849511: general: java and javac can't run , it said
"java: error while loading shared libraries: libjli.so",
To: Andrew Shadura <and...@shadura.me>


hey , oracle jdk in my debian is not working.This is some details.I
have try many way to solve by google.But still vain.I am a beginner.

ls /usr/lib/jvm/
   default-java  java-1.7.0-openjdk-amd64  java-7-openjdk-amd64  jdk8

katcom@Bluish:~$ ls /usr/lib/jvm/jdk8
   binjavafx-src.zip  man  THIRDPARTYLICENSEREADME-JAVAFX.txt
   COPYRIGHT  jre README.html  THIRDPARTYLICENSEREADME.txt
   db lib release
   includeLICENSE src.zip

sudo update-alternatives --config java
There are 2 choices for the alternative java (providing /usr/bin/java).

  SelectionPathPriority   Status

  0/usr/lib/jvm/jdk8/bin/java   1800
   auto mode
  1/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java   1071
   manual mode
* 2/usr/lib/jvm/jdk8/bin/java   1800
   manual mode

katcom@Bluish:~$ java
java: error while loading shared libraries: libjli.so: cannot open
shared object file: No such file or directory

This is my ~./bashrc

#java configure
export JAVA_HOME=/usr/lib/jvm/jdk8
export JRE_HOME=${JAVA_HOME}/jre
export CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib
export PATH=${JAVA_HOME}/bin:$PATH

I have not modified the /etc/profile.

please help me.Otherwise i have to get back to windows : ).




2016-12-28 21:20 GMT+08:00 Andrew Shadura <and...@shadura.me>:
>
> Control: tags -1 moreinfo
>
> On 28 December 2016 at 02:14, Jason.katcom <katcom...@gmail.com> wrote:
> > Package: general
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > *** Reporter, please consider answering these questions, where appropriate 
> > ***
> >
> >* What led up to the situation?
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >* What was the outcome of this action?
> >* What outcome did you expect instead?
> >
> > *** End of the template - remove these template lines ***
>
> Any more details please?
>
> --
> Cheers,
>   Andrew




-- 
Cheers,
  Andrew

Bug#852032: libjavascriptcoregtk-4.0-18: Segmentation fault in LLIntAssembly.h:2610 on powerpc64

[Andrew Shadura]

On 20/01/17 23:28, Andrew Shadura wrote:
> On 20/01/17 22:24, Andrew Shadura wrote:
>> To reproduce, I built seed-webkit2 on ppc64, installed 
>> libjavascriptcoregtk-4.0-18-dbgsym and ran in the directory with unpacked 
>> package source:
>>
>> $ export LD_LIBRARY_PATH=$(pwd)/libseed/.libs:
>> $ cd doc/modules/readline
>> $ gdb ../../../src/seed
> 
> Obviously, I meant this:
> 
> $ gdb ../../../src/.libs/seed
> 
>> (gdb) set args ../../../doc/modules/make-functions.js 
>> ../../../doc/modules/readline/readline.js
>> (gdb) run

By the way, nearly exactly the same error happens on mips:

> Thread 1 "seed" received signal SIGBUS, Bus error.
> JSC::LLInt::CLoop::execute () at 
> ./obj-mips-linux-gnu/DerivedSources/JavaScriptCore/LLIntAssembly.h:4182
> 4182./obj-mips-linux-gnu/DerivedSources/JavaScriptCore/LLIntAssembly.h: 
> No such file or directory.
> (gdb) bt
> #0  JSC::LLInt::CLoop::execute () at 
> ./obj-mips-linux-gnu/DerivedSources/JavaScriptCore/LLIntAssembly.h:4182
> #1  0x776fc68c in vmEntryToJavaScript () at 
> ./Source/JavaScriptCore/llint/LLIntThunks.cpp:104
> #2  0x776e7c48 in JSC::JITCode::execute () at 
> ./Source/JavaScriptCore/jit/JITCode.cpp:80
> #3  0x776dcc20 in JSC::Interpreter::execute () at 
> ./Source/JavaScriptCore/interpreter/Interpreter.cpp:899
> #4  0x7784a6ec in JSC::evaluate () at 
> ./Source/JavaScriptCore/runtime/Completion.cpp:106
> #5  0x7784aa4c in JSC::profiledEvaluate () at 
> ./Source/JavaScriptCore/runtime/Completion.cpp:121
> #6  0x77576f24 in JSEvaluateScript () at 
> ./Source/JavaScriptCore/API/JSBase.cpp:68
> #7  0x77e52b18 in seed_include (ctx=0x739fff68, function=, 
> this_object=, argumentCount=, 
> arguments=0x7fff59bc, 
> exception=0x7fff5994) at seed-builtins.c:104
> #8  0x775790dc in JSC::APICallbackFunction::call () 
> at ./Source/JavaScriptCore/API/APICallbackFunction.h:63
> #9  0x776e8e04 in handleHostCall () at 
> ./Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1231
> #10 0x776f51a4 in JSC::LLInt::genericCall () at 
> ./Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1340
> #11 llint_slow_path_call () at 
> ./Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1347
> #12 0x776ffec8 in JSC::LLInt::CLoop::execute () at 
> ./obj-mips-linux-gnu/DerivedSources/JavaScriptCore/LLIntAssembly.h:6864
> #13 0x776fc68c in vmEntryToJavaScript () at 
> ./Source/JavaScriptCore/llint/LLIntThunks.cpp:104
> #14 0x776e7c48 in JSC::JITCode::execute () at 
> ./Source/JavaScriptCore/jit/JITCode.cpp:80
> #15 0x776dcc20 in JSC::Interpreter::execute () at 
> ./Source/JavaScriptCore/interpreter/Interpreter.cpp:899
> #16 0x7784a6ec in JSC::evaluate () at 
> ./Source/JavaScriptCore/runtime/Completion.cpp:106
> #17 0x7784aa4c in JSC::profiledEvaluate () at 
> ./Source/JavaScriptCore/runtime/Completion.cpp:121
> #18 0x77576f24 in JSEvaluateScript () at 
> ./Source/JavaScriptCore/API/JSBase.cpp:68
> #19 0x77e58334 in seed_init_with_context_and_group (argc=0x7fff64d0, 
> argv=0x7fff64ac, context=, group=) at 
> seed-engine.c:1914
> #20 0x0e60 in main (argc=, argv=) at 
> main.c:142


-- 
Cheers,
  Andrew



signature.asc
Description: OpenPGP digital signature

Bug#852032: libjavascriptcoregtk-4.0-18: Segmentation fault in LLIntAssembly.h:2610 on powerpc64

[Andrew Shadura]

On 20/01/17 22:24, Andrew Shadura wrote:
> To reproduce, I built seed-webkit2 on ppc64, installed 
> libjavascriptcoregtk-4.0-18-dbgsym and ran in the directory with unpacked 
> package source:
> 
> $ export LD_LIBRARY_PATH=$(pwd)/libseed/.libs:
> $ cd doc/modules/readline
> $ gdb ../../../src/seed

Obviously, I meant this:

$ gdb ../../../src/.libs/seed

> (gdb) set args ../../../doc/modules/make-functions.js 
> ../../../doc/modules/readline/readline.js
> (gdb) run

-- 
Cheers,
  Andrew



signature.asc
Description: OpenPGP digital signature

Bug#852032: libjavascriptcoregtk-4.0-18: Segmentation fault in LLIntAssembly.h:2610 on powerpc64

[Andrew Shadura]

Package: libjavascriptcoregtk-4.0-18
Version: 2.14.2-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

Segmentation fault in libjavascriptcoregtk-4.0.so.18 causes seed-webkit2
FTBFS on powerpc64.

Here's the stacktrace I retrieved on a porterbox:

Thread 1 "seed" received signal SIGSEGV, Segmentation fault.
JSC::LLInt::CLoop::execute (entryOpcodeID=3019375176, executableAddress=0x0, 
vm=0x3fffb3fc, protoCallFrame=0x3fff, isInitializationPass=false)
at 
./obj-powerpc64-linux-gnu/DerivedSources/JavaScriptCore/LLIntAssembly.h:2610
2610
./obj-powerpc64-linux-gnu/DerivedSources/JavaScriptCore/LLIntAssembly.h: No 
such file or directory.
(gdb) bt
#0  JSC::LLInt::CLoop::execute (entryOpcodeID=3019375176, 
executableAddress=0x0, vm=0x3fffb3fc, protoCallFrame=0x3fff, 
isInitializationPass=false)
at 
./obj-powerpc64-linux-gnu/DerivedSources/JavaScriptCore/LLIntAssembly.h:2610
#1  0x3fffb74b8e24 in JSC::vmEntryToJavaScript 
(executableAddress=, vm=, 
protoCallFrame=)
at ./Source/JavaScriptCore/llint/LLIntThunks.cpp:104
#2  0x3fffb74a2f18 in JSC::JITCode::execute (this=, 
vm=0x3fffb3fc, protoCallFrame=0x3fffdff8)
at ./Source/JavaScriptCore/jit/JITCode.cpp:80
#3  0x3fffb7497820 in JSC::Interpreter::execute (this=, 
program=0x3fffb2f63e80, callFrame=, thisObj=0x3fffb2f6c6c0)
at ./Source/JavaScriptCore/interpreter/Interpreter.cpp:899
#4  0x3fffb760b7bc in JSC::evaluate (exec=0x3fffb33d80e0, source=..., 
thisValue=..., returnedException=...)
at ./Source/JavaScriptCore/runtime/Completion.cpp:106
#5  0x3fffb760b9e8 in JSC::profiledEvaluate (exec=0x3fffb33d80e0, 
reason=, source=..., thisValue=..., returnedException=...)
at ./Source/JavaScriptCore/runtime/Completion.cpp:121
#6  0x3fffb730f7d4 in JSEvaluateScript (ctx=, 
script=, thisObject=0x0, sourceURL=0x0, 
startingLineNumber=,
exception=0x0) at ./Source/JavaScriptCore/API/JSBase.cpp:68
#7  0x3fffb7d9138c in seed_simple_evaluate (ctx=0x3fffb33d80e0, 
source=, exception=0x0) at seed-api.c:308
#8  0x3fffb7d97938 in seed_init_constrained_with_context_and_group 
(argc=0x3010, argv=0x3fffefa8, context=0x3fffb33d80e0, 
group=0x3fffb3fc)
at seed-engine.c:1840
#9  0x3fffb7d97c54 in seed_init_with_context_and_group (argc=, argv=, context=, group=)
at seed-engine.c:1905
#10 0x3fffb7d97d78 in seed_init_with_context_group (argc=0x3010, 
argv=0x3fffefa8, group=0x3fffb3fc) at seed-engine.c:1939
#11 0x3fffb7d97df0 in seed_init (argc=0x3010, argv=) 
at seed-engine.c:1962
#12 0x1fc0 in main (argc=, argv=) at 
main.c:142

To reproduce, I built seed-webkit2 on ppc64, installed 
libjavascriptcoregtk-4.0-18-dbgsym and ran in the directory with unpacked 
package source:

$ export LD_LIBRARY_PATH=$(pwd)/libseed/.libs:
$ cd doc/modules/readline
$ gdb ../../../src/seed
(gdb) set args ../../../doc/modules/make-functions.js 
../../../doc/modules/readline/readline.js
(gdb) run

Please have a look at this.

- -- 
Cheers,
  Andrew

-BEGIN PGP SIGNATURE-

iQExBAEBCAAbBQJYgn/0FBxhbmRyZXdzaEBkZWJpYW4ub3JnAAoJEJ1bI/kYT6UU
LkoH/iThKO73KvLO3qPnmeEcwhKVe3GPCDgSrcE5U4w9ml9fNqJcxK1j3gjUzGc3
3HjGdjyau1so4ZELAaZ3PcxUU8NpdwC04YlSSfkTz0woY+ddZI8tuSHEZdIWb/8G
QXFo31VQD5XtRaCvT/tCpy7mzLdJyHY1IARrEgpgGSIE6iC/ADBXPGQ9P/y12Y+W
h2A2K7droG0ScKXMmYzhnkPPV1UPWGQy+mcSHPo6m65ZyeaITH6vRARwUH3gRnHf
/kalXkOMR6/6voVc07z+EOjJ1apXRVbPBQa7io4a9DEo9ekkyuwG8KNr2pmYWzRM
eqNsHskL2zS+60MhJyAbvKoLc6E=
=yTDu
-END PGP SIGNATURE-

Bug#851660: Please update Phabricator to include PHP7 compatibility

[Andrew Shadura]

On 17/01/17 12:00, Kai Wasserbäch wrote:
> Source: phabricator
> Version: 0~git20160726-3
> Severity: normal
> Tags: upstream, fixed-upstream
> 
> Dear maintainers,
> upstream added PHP7 compatibility a couple of days ago, see
>  for more details and the relevant
> commits.
> 
> Please consider updating the package with either those commits
> cherry-picked or by packaging a later revision. Otherwise the
> phabricator package will be pretty pointless in Stretch. For this reason
> I was actually tempted to raise the priority further, but for now
> "normal" should be enough. ;-)

I'm afraid I can't do that, as we aren't going to ship PHP 7.1 in
Stretch, and Phabricator won't support PHP 7.0.

-- 
Cheers,
  Andrew



signature.asc
Description: OpenPGP digital signature

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#848982: [pkg-wpa-devel] Bug#848982: wpasupplicant fails to connect to WPA Enterprise network with 2.6-2

[Andrew Shadura]

On 12 January 2017 at 20:25, Axel Beckert  wrote:
>> Dec 21 15:33:42 green wpa_supplicant[696]: EAP-MSCHAPV2: workaround, ignore 
>> invalid ms_len 46 (len 50)
>> Dec 21 15:33:42 green wpa_supplicant[696]: EAP-MSCHAPV2: Authentication 
>> succeeded
>
> In the old log, there's mentioning of MSCHAPV2, but in the new log,
> there's no more mentioning of MSCHAPV2.
>
> Could this be related to https://bugs.launchpad.net/wicd/+bug/1656061
> in wicd where someone said that
>
>   phase2="auth=MSCHAPv2"
>
> no more works and that the correct syntax is
>
>   phase2="auth=MSCHAPV2"
>
> with a capital "V".
>
> Can you check if you have a lower-case "v" in your WPA configuration,
> too?

I wonder, if it's that problem indeed, could we have it patched to
accept the old syntax temporarily while issuing a warning?

-- 
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