Bug#957643: Proposed fix

[Paul Fertser]

http://openocd.zylin.com/#/c/5592/

Bug#810470: libusb: superseded by libusb-1.0

[Paul Fertser]

Hi,

On Fri, Aug 18, 2017 at 12:07:13PM +0100, Steven Chamberlain wrote:
> openocd/0.10.0-1 gained a new dependency on libusb-dev (libusb 0.1);
> but the latter is destined for removal from the archive.

OpenOCD can use libusb-compat instead. That said, I do not think I've
seen any reports from users who still need those 3 old drivers anyway.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

Bug#859066: linux-image-*: recommend firmware-ath9k-htc

[Paul Fertser]

On Thu, Mar 30, 2017 at 10:04:24PM +0100, Ben Hutchings wrote:
> On Thu, 2017-03-30 at 09:22 +0800, Paul Wise wrote:
> > Source: linux
> > Version: 4.10~rc6-1~exp1
> > Severity: wishlist
> > X-Debbugs-CC: open-ath9k-htc-firmw...@packages.debian.org
> > 
> > Now that open-ath9k-htc-firmware has been accepted into Debian
> > unstable, please add "Recommends: firmware-ath9k-htc" to the
> > metadata for the linux-image-* packages in Debian experimental.

Not many linux-image-* users have ath9k-htc hardware so I do not see
how this recommendation can make sense here.

The package should have provided appropriate AppStream metainformation
so Debian should be able to suggest installing it when the device is
plugged in for the first time.

> As this firmware has gone through at least one ABI bump, I think we
> need to plan for a future ABI bump.

So far the idea was to upload a package named firmware-ath9k-htc-1.5.0
after the next ABI bump. There's no reason why
firmware-ath9k-htc-1.5.0 shouldn't be able to co-exist on the same
system with e.g. firmware-ath9k-htc-1.6.0, as the user should be able
to choose different kernel versions on boot, and hence different
firmware versions will be appropriate.

> Therefore:
> - You should not name the files as simply '1.dev.0' versions, but by
>   the implemented ABI version (as the driver expects by default).

The code that's currently packaged is definitely not 1.4.0 code, it
got some non-trivial changes (not affecting ABI though) after the
1.4.0 was released. So naming an intermediate version in any way other
than 1.dev.0 would only add to the confusion IMHO.

Probably it would make sense to have the minor number indicate a
subversion of same-ABI firmwares, but for some reasons the kernel
driver maintainers decided against that.

I hope Oleksij will correct me if I'm missing something here.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

Bug#751339: RFP: ath9k-htc-firmware -- free firmware for Atheros AR7010/AR9271 wireless adapters

[Paul Fertser]

Hello,

On Wed, Feb 01, 2017 at 10:29:11PM +0100, Francesco Poli wrote:
> Is there any progress in properly packaging these two DFSG-free
> firmware files for inclusion in Debian main?

It's sitting in the NEW queue for 2 months already.

https://ftp-master.debian.org/new/open-ath9k-htc-firmware_1.4.0-81-gf206e56+dfsg-1.html

Bug#849825: openocd: fails to program Intel flash on MIPS target

[Paul Fertser]

Hello,

Thank you for the report.

Regarding the first issue, it was fixed in v0.9.0-94-g27a1125 , that's
included in 0.10.0-rc1. The second was fixed with v0.9.0-227-g144f96c
and it's present in the current release candidate as well.

Please feel free to contribute your board config file (along with an
approriate entry to tcl/tools/firmware-recovery.tcl) upstream, see
HACKING for the reference.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

Bug#840515: Copyright status of debian/cross-toolchain.mk

[Paul Fertser]

Hi,

On Fri, Nov 04, 2016 at 06:06:14PM +0100, Aurelien Jarno wrote:
> > When trying to prepare proper packaging for the ath9k-htc QCA firmware
> > we found it reasonable to reuse (with minor modifications)
> > cross-toolchain.mk from the openbios packaging.
> 
> Good to know it's useful.

It was extremely useful indeed, big thanks for that!

> > Can you please clarify on the copyright and licensing status of this
> > code?
> 
> I have written the code, so the copyright is mine. I haven't specified
> any copyright for this file. Would GPLv2 or later fine for you? I can
> also choose another license if you prefer.

That would be just fine, thank you in advance.

> When we agree, I'll add a header with this copyright in our git
> repository over the week-end. I don't think you need an upload for
> that?

Yes, an upload is not necessary.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

Bug#840515: Copyright status of debian/cross-toolchain.mk

[Paul Fertser]

Hello Aurélien,

When trying to prepare proper packaging for the ath9k-htc QCA firmware
we found it reasonable to reuse (with minor modifications)
cross-toolchain.mk from the openbios packaging.

Can you please clarify on the copyright and licensing status of this
code?

Thank you in advance.
-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

Bug#840515: RFS: open-ath9k-htc-firmware/1.4.0-25-gf6af791-1 ITP #751339

[Paul Fertser]

Hey Paul,

Many thanks for your review, please see some answers below.

On Thu, Oct 13, 2016 at 11:55:29AM +0800, Paul Wise wrote:
> > Cc: Oleksij Rempel 
> 
> Please use the X-Debbugs-CC pseudo-header when submitting bugs instead

Noted. Nice feature.

> > I am looking for a sponsor for my package "open-ath9k-htc-firmware"
> 
> Correct me if I'm wrong but IIRC either yourself or Oleksij have
> commit/release access upstream?

Well, basically Oleksij co-maintains the upstream repository with
Adrian Chadd (former QCA employee).

I have commit rights for the packaging branch in Oleksij's personal
repo.

> The comments for the overrides for lintian tag source-is-missing
> should indicate which file is the source for each prebuilt file. I
> would have one comment per instance of the tag.

In this particular case it's unclear if the source is really missing
or not. If you say the upstream sources absolutely MUST be repackaged
if they include binaries that we can't get the sources for even if the
said binaries are removed automatically before building and are not
needed for the process anyhow, well, I'll try to investigate the
details and will come back with the answer.

> Just one comment saying they are removed at build time is enough for
> all of the overrides for lintian tag
> source-contains-prebuilt-binary.

OK.

> Personally, I would suggest removing all of these files from the
> upstream git repository and always building them from source. If you
> need to keep them, put them in tarballs in the github releases.

Not practical, please see below.

> Personally, I would recommend the generated files docs/*.png be
> removed from the upstream git repo and rendered at build time from
> their source SVG files if they are needed.

Noted. Probably not anything to worry about if we'll have to repack
upstream sources anyway due to proprietary objects, the *.png will be
removed along the way.

> I think you should also remove the prebuilt files before
> dh_auto_configure so that they can never get used by a build, even a
> manual one where `debian/rules clean` is not run.
...
> I would use a debian/clean file instead of override_dh_clean.

Noted.

> What is the reason for removing the docs/ and sboot/ directories in
> override_dh_clean? AFAICS both of these contain source files. IMO you
> should just remove the generated files.

Since neither are needed for building the actual firmware, it's easier
to remove them completely rather than mess with individual files.

The device hardware includes not only the microcontroller but also
some RAM and ROM. The tricky part here is that ROM is a mask ROM one,
that is, truly read-only. During the development a set of generic
useful functions was identified and QCA produced a batch of ICs with
those functions present in the mask ROM memory. The main firmware is
stored on a host device and is loaded dynamically to target's RAM. To
cut down on the amount of RAM needed, it makes use of those generic
functions stored in ROM. sboot/ directory contains (probably partial,
will have to investigate this further, if absolutely needed; probably
repacking the upstream tarball would be easier though) sources for the
said ROM as well as the binaries that are supposed to be identical to
the ROM's contents. During the build some header files and linker
scripts are used to provide external linkage to the generic functions,
the said headers and scripts are placed in the target_firmware/
directory, so sboot/ can be removed completely. For some debugging
purposes it might be beneficial to inspect the sources of the
mentioned functions and sometimes even the resulting binaries. So
sboot/ should probably stay in the upstream repository for the
reference purposes. Making upstream package it separately sounds like
additional hassle for no practical gain (except for the Debian
packaging purposes probably), it's way easier to have a single git
repository contain everything useful for development and debugging.

> The cmake part of the build process does not print compiler
> invocation. Debian requires full compiler flags/output in build logs.
> For cmake usually debhelper automatically passes
> -DCMAKE_VERBOSE_MAKEFILE=ON but it doesn't seem to be working here?

Will investigate.

> The debian/watch file needs adjusting for the new source package name:
> s/firmware-ath9k-htc/open-ath9k-htc-firmware/
> 
> Personally I would leave "debian uupdate" out of the watch file
> because it can be annoying for people who just want to download.

Indeed. I'm new to this, so just copied the example from the uscan
manpage.

> Please get the FSF address corrected in the upstream copyright info.

This one makes me wonder if it'd be the correct way to go. I assume
only the copyright holder can do this, and spending time contacting
eCos developers (and probably lawyers) just to get it right for some
really old code seems impractical. I'd consider this to be an upstream
issue unrelated to Debian 

Bug#840515: RFS: open-ath9k-htc-firmware/1.4.0-25-gf6af791-1 ITP #751339

[Paul Fertser]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "open-ath9k-htc-firmware"

* Package name: open-ath9k-htc-firmware
  Version : 1.4.0-25-gf6af791-1
  Upstream Author : QCA
* URL : https://github.com/qca/open-ath9k-htc-firmware
* License : BSD-3-clause
  Section : misc

It builds those binary packages:

  firmware-ath9k-htc - QCA ath9k-htc Firmware
  firmware-ath9k-htc-dbgsym - QCA ath9k-htc Firmware ELF file

To access further information about this package, please visit the following 
URL:

https://mentors.debian.net/package/open-ath9k-htc-firmware


Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/o/open-ath9k-htc-firmware/open-ath9k-htc-firmware_1.4.0-25-gf6af791-1.dsc

Regards,
  Oleksij Rempel
  Paul Fertser

Bug#837989: openocd: can no longer use SheevaPlug JTAGKey FT2232D (regression)

[Paul Fertser]

On Fri, Sep 16, 2016 at 11:59:59PM +0200, David Madore wrote:
> Open On-Chip Debugger 0.5.0 (2016-09-16-09:33)
...
> Error: 217 472 core.c:945 jtag_examine_chain_check(): JTAG scan chain 
> interrogation failed: all zeroes
> Error: 218 472 core.c:946 jtag_examine_chain_check(): Check JTAG interface, 
> timings, target power, etc.
...
> Error: 230 476 feroceon.c:671 feroceon_examine(): unexpected Feroceon EICE 
> version signature

Hm, can't see anything good about it...

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

Bug#837989: openocd: can no longer use SheevaPlug JTAGKey FT2232D (regression)

[Paul Fertser]

On Fri, Sep 16, 2016 at 12:22:12PM +0200, David Madore wrote:
> > The error you report seems to be fixed post-0.8.0, but before 0.9.0,
> > in v0.8.0-142-geab9af1 . So it looks as if you're trying to use 0.9.0
> > with scripts from 0.8.0.
> 
> Ah, indeed, PEBCK for that part, I forgot to pass a -s option when
> using openocd from a compilation tree.  But still, as noted above,
> neither 0.8.0 nor 0.9.0 seem to be able to use the device, they just
> get stuck.

In this case it would help to see -d3 output.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

Bug#837989: openocd: can no longer use SheevaPlug JTAGKey FT2232D (regression)

[Paul Fertser]

Hello,

On Fri, Sep 16, 2016 at 09:55:21AM +0200, David Madore wrote:
> A SheevaPlug JTAGKey FT2232D (USB identifiers 9e88:9e8f) being

Please also provide lsusb -vvv data for this device.

> worked fine with it:
...
> Error: JTAG scan chain interrogation failed: all zeroes

No, this doesn't look fine to me.

> Open On-Chip Debugger 0.8.0 (2016-09-16-09:45)
...
> Error: unable to open ftdi device with vid 9e88, pid 9e8f, description 
> 'SheevaPlug JTAGKey FT2232D' and serial '*'

You might want to try to comment out ftdi_device_desc command from
interface/ftdi/sheevaplug.cfg to workaround this issue.

> The error message is almost identical with openocd 0.9.0:
...
> Error: unable to open ftdi device with vid 9e88, pid 9e8f,
> description 'SheevaPlug JTAGKey FT2232D' and serial '*'

The error you report seems to be fixed post-0.8.0, but before 0.9.0,
in v0.8.0-142-geab9af1 . So it looks as if you're trying to use 0.9.0
with scripts from 0.8.0.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

Bug#810672: firmware-free should include the ath9k_htc firmware binaries

[Paul Fertser]

Package: firmware-free
Version: 3.4
Severity: wishlist

Hello,

According to the upstream commit[1] ath9k_htc version 1.4.0 is free
software (and the future versions will be free software as well,
obviously).

Please add it to this package (and remove from firmware-atheros).

There's one important thing to consider though: location of the
firmware files.

If you add the binaries just as they're located in linux-firmware they
will be seen and used only by the kernel versions that include [2]. If
you copy them to the old place then the older kernels will work with
1.4.0 too (it's backwards-compatible to 1.3.0). Please see [2] for
more rationale and details regarding this.

The maintainer of the open ath9k_htc firmware is in Cc.

[1] 
https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=3f3aa3a12d5e5d34bda87a691cf7176baef95bf3
[2] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e904cf6fe23022cde4e0ea9d41601411a315a3dc

Bug#810387: openocd: please switch to libftdi1

[Paul Fertser]

Hello,

> If openocd supports the new libftdi1 library, please consider switching
> the build-depends from libfdti-dev to libftdi1-dev.

OpenOCD supports the new library, so the transition should be
painless.

Bug#808114: avr-libc in Debian testing is incompatible with gcc-avr, linking fails

[Paul Fertser]

Hello, thank you for the prompt reply.

On Wed, Dec 16, 2015 at 09:05:19AM +0100, Hakan Ardo wrote:
> Thanks, this is fixed in unstable.

It is, but users of Debian testing right now receive confusing
messages and are not able to build anything. I might be
misunderstanding something but this seems important to me.

Also, do you think it's worth considering to use more stricter
dependencies between avr-libc and gcc-avr (exact version match)?

Bug#808114: avr-libc in Debian testing is incompatible with gcc-avr, linking fails

[Paul Fertser]

Package: avr-libc
Version: 1:1.8.0+Atmel3.4.5-1
Severity: grave

This current version depends on gcc-avr (>= 1:4.8.1+Atmel3.4.5), and
testing already ships 1:4.9.2+Atmel3.5.0-1 which formally fulfills the
dependency, however, the resulting combination is unusable as the
specs files supplied with gcc-avr 1:4.9.2+Atmel3.5.0-1 list startup
files like "crtatmega128.o", and this specific avr-libc version
provides "crtm128.o". There's also no device-specific lib present so
upon linking an example demo project these errors are produced:

$ make
avr-gcc -g -Wall -O2 -mmcu=atmega8-c -o demo.o demo.c
avr-gcc -g -Wall -O2 -mmcu=atmega8  -Wl,-Map,demo.map -o demo.elf demo.o
/usr/lib/gcc/avr/4.9.2/../../../avr/bin/ld: cannot find crtatmega8.o: No such 
file or directory
/usr/lib/gcc/avr/4.9.2/../../../avr/bin/ld: cannot find -latmega8
collect2: error: ld returned 1 exit status
Makefile:75: recipe for target 'demo.elf' failed
make: *** [demo.elf] Error 1

Thank you in advance.

Bug#801145: openocd: interface script uses ft2232 (obsolete) not ftdi

[Paul Fertser]

Hello,

On Tue, Oct 06, 2015 at 10:51:09AM -0700, Frank Miles wrote:
>* What led up to the situation?
>   Attempted connection between Olimex ARM-USB-OCD / LPC-microcontroller 
> and 'jessie' host
>   for programming/debugging.

Please provide the exact command line you used.

>* What was the outcome of this action?
>   Various error messages, logs, etc., all indicating that the connection 
> between the linux host
>   and the target embedded system was not established.

Please provide full logs for the failure case.

Feel free to discuss the issue on the OpenWrt devel mailing list on
#openocd at freenode.net IRC channel, that way you'll likely to get
support faster.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

Bug#776471: openocd: Regression FTBFS on sh4 due to redifinition of registers defined in glibc sources

[Paul Fertser]

Hello,

On Wed, Jan 28, 2015 at 01:19:37PM +0100, John Paul Adrian Glaubitz wrote:
 In file included from /usr/include/signal.h:352:0,
  from /usr/include/sh4-linux-gnu/sys/param.h:28,
from ../../../src/helper/system.h:77,
from ../../../config.h:345,
from aice_usb.c:21:
../../../src/target/nds32_reg.h:27:2: error: redeclaration of 
 enumerator 'R0'
R0 = 0, /* general registers */
^
/usr/include/sh4-linux-gnu/sys/ucontext.h:43:3: note: previous 
 definition of 'R0' was here
R0 = 0,
^

Are you sure it's fine for system headers (that get included even with
a regular signal.h) to declare an R0 enumerator? This name sounds
too generic and clashes like the one you report are not surprising.

What is your proposed solution?

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com


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

Bug#754678: openocd: FTBFS on kfreebsd-*: configure: error: libusb-1.x is required for the MPSSE mode of FTDI based devices

[Paul Fertser]

Hi,

On Sun, Oct 19, 2014 at 10:45:17PM +0100, Steven Chamberlain wrote:
 If you want something equivalent to Linux libusb 1.0 API, I think you
 need to Build-Depend on libusb2-dev [kfreebsd-any] rather than libusb-dev.

Right, libusb-0.1 API is still needed for some older drivers, but it
is provided by libusb2-dev on kfreebsd, libusb-dev shouldn't be used
there.

 Dropping libftdi-dev from Build-Depends on kfreebsd-amd64, I actually
 get a successful build;  how does that work?  Does MPSSE mode not need
 ftdi.h any more?  If so, libftdi-dev can be dropped from Build-Depends
 on linux, too.  But I have no way of testing openocd.

MPSSE mode depends only on libusb-1, however, there're three other
drivers (USB Blaster, ASIX Presto, OpenJTAG; USB Blaster being really
important here) plus legacy ft2232 implementation that need
libftdi-dev.


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

Bug#754678: openocd: FTBFS on kfreebsd-*: configure: error: libusb-1.x is required for the MPSSE mode of FTDI based devices

[Paul Fertser]

On Mon, Oct 20, 2014 at 01:45:15PM +0200, Luca Bruno wrote:
  MPSSE mode depends only on libusb-1, however, there're three other
  drivers (USB Blaster, ASIX Presto, OpenJTAG; USB Blaster being really
  important here) plus legacy ft2232 implementation that need
  libftdi-dev.
 
 If I'm not wrong:
  * usb-blaster support is autodetected

No, it's currently not.

  * presto and openjtag should be explicitely enabled (currently aren't)
  * we don't currently explicitly enable any legacy ft2232

Right.

 So the above patch should be ok.

USB Blaster support would be nice to have...

 I'm just slightly confused about usb-blaster on kfreebsd, which seems to have 
 been autoenabled even though libftdi-dev was missing.

How do you tell it was?


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

Bug#754678: openocd: FTBFS on kfreebsd-*: configure: error: libusb-1.x is required for the MPSSE mode of FTDI based devices

[Paul Fertser]

On Mon, Oct 20, 2014 at 02:24:36PM +0100, Steven Chamberlain wrote:
 On 20/10/14 13:01, Paul Fertser wrote:
  On Mon, Oct 20, 2014 at 01:45:15PM +0200, Luca Bruno wrote:
  I'm just slightly confused about usb-blaster on kfreebsd, which seems to 
  have 
  been autoenabled even though libftdi-dev was missing.
  
  How do you tell it was?
 
 In the build log I attached (with libftdi-dev not installed) :
 
 https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=22;filename=openocd.log.gz;att=1;bug=754678
 
 | Altera USB-Blaster II Compatibleyes (auto)

I see the source of the confusion now. There're two versions of USB
Blaster, the first one is still widely available (and requires
libftdi), the second (depends onl libusb) is slowly gaining popularity
(clk frequency control is yet to be implemented, currently it might be
too high for many targets).

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com


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

Bug#754678: openocd: FTBFS on kfreebsd-*: configure: error: libusb-1.x is required for the MPSSE mode of FTDI based devices

[Paul Fertser]

On Mon, Oct 20, 2014 at 03:43:43PM +0200, Luca Bruno wrote:
 On Monday 20 October 2014 17:31:48 Paul Fertser wrote:
 I see. So in the end, let's keep:
  * libusb autodetection for kfreebsd
  * --enable-usb_blaster_libftdi for linux

My proposal is to have libusb autodetection and usb_blaster_libftdi
for all the supported systems. What exactly does kfreebsd lack that's
necessary for libftdi? OpenOCD works with both libftdi-0 and
libftdi-1, and kfreebsd supports both libusb-0.1 and libusb-1 APIs
equally well libusb2-dev package. 


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

Bug#764068: gnupg-agent: use standard socket by default

[Paul Fertser]

Package: gnupg2
Version: 2.0.26-3
Severity: wishlist

Hello,

GnuPG2 currently offers two different schemes of using gpg-agent, the key
management daemon. The first method is the one extensively described in the
man page and elsewhere, suggesting specific way of starting gpg-agent on
user session's startup and exporting some appropriate environment
variables. When gpg2 is trying to contact the daemon but it's not
available, it starts it automatically for a one-shot operation (with the
--server option), and gpg-agent exits after performing the desired
operation, no key caching takes place, so all the corresponding TTL options
are ignored.  This is the default in the current Debian package. The second
method is to use a standard gpg-agent socket location; in this case gpg2
starts the agent on demand (as in the previous case) but leaves it running
in daemon mode, and so it continues to serve requests from all the
applications via the standard socket location, in a transparent and
automatic manner, without requiring user to set any environment variables.
This second method can be forced with the current package by adding
use-standard-socket option to ~/.gnupg/gpg-agent.conf.

My proposal is to add --enable-standard-socket to the configure flags to
make the second method default.

Rationale:

The second method is considerably more user-friendly as it doesn't require
any explicit configuration, works universally (no difference between an X
session and the usual console session), and so always produces the expected
results. It's also the way the upstream is heading as the configure-time
option --enable-standard-socket was made default in
002b30e75c623d15e89708a27442836bdf038ebc (gnupg-2.0.13-178-g002b30e, it's
in the 2.1 dev branch forked shortly after v2.0.13 thus not present in any
of 2.0.x versions; first found in gnupg-2.1-base~20) and was completely
removed in 9c380384dafb213334f8834178c5ceb0bf33db6e
(gnupg-2.1.0-beta834-22-g9c38038) in favour of always using the standard
socket (so the Debian users will have to migrate to this new method sooner
or later anyway).

TIA


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

Bug#751372: closed by Luca Bruno lu...@debian.org (Bug#751372: fixed in openocd 0.8.0-2)

[Paul Fertser]

On Tue, Aug 19, 2014 at 11:23:07PM +0200, Andreas Schneider wrote:
 Error: unable to open ftdi device with vid 9e88, pid 9e8f, description
 'SheevaPlug JTAGKey FT2232D' and serial '*'

Please see if http://openocd.zylin.com/2265 (trivial config change)
helps. Sorry about the breakage.


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

Bug#751372: closed by Luca Bruno lu...@debian.org (Bug#751372: fixed in openocd 0.8.0-2)

[Paul Fertser]

Hi,

On Wed, Aug 20, 2014 at 09:21:11AM +0200, Andreas Schneider wrote:
 $ openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg -s
 /usr/share/openocd/scripts

In fact running openocd is much easier:

openocd -f board/sheevaplug.cfg

(no need for full path and -s). You should be able to get it running
with
openocd -f board/sheevaplug.cfg -c adapter_khz 100

If you have a reasonable explanation of what the default adapter freq
should be, I can add it to the config.

HTH


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

Bug#751372: closed by Luca Bruno lu...@debian.org (Bug#751372: fixed in openocd 0.8.0-2)

[Paul Fertser]

On Wed, Aug 20, 2014 at 09:51:37AM +0200, Andreas Schneider wrote:
 so 2000 kHz is probably what should go into the config.
 
Ok, done, http://openocd.zylin.com/2266 . Thank you for reporting and
testing, have a nice day!


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

Bug#751372: openocd: connecting to SheevaPlug broken in 0.8

[Paul Fertser]

Hi Andreas,

Thank you for reporting the bug. Please see if
http://openocd.zylin.com/2230 fixes the issue.


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

Bug#726184: libofx4 can't process utf-8 encoded files

[Paul Fertser]

In fact, 0.9.6 has a very serious bug concerning line endings (fixed
in cb775f44013bd48c9a8c6e86d09dc405a799a4f2), so using it is highly
discouraged.

From git log it looks like the current 0.9.9 would be the most
suitable version to upgrade to.


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

Bug#726184: libofx4 can't process utf-8 encoded files

[Paul Fertser]

Package: libofx4
Version: 1:0.9.4-2.1
Tags: fixed-upstream

This version of libofx is not able to properly input XML OFX files
encoded with utf-8 which seriously complicates importing them in
e.g. GnuCash. Please upgrade to at least 0.9.6 upstream release.

The corresponding upstream bug report is at
http://sourceforge.net/p/libofx/bugs/34/ .

The first released version with the fix committed is 0.9.6 (Mar 30
2013) but unfortunately it's not ABI-compatible, so GnuCash dependency
needs to be bumped as well.

TIA
-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com


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

Bug#707260: chrony initscript uses netstat but lacks a dependency on net-tools, results in failure to go online

[Paul Fertser]

Package: chrony
Version: 1.26-3

On a system debootstrapped with minbase I installed chrony and noticed
it doesn't go online on boot. The reason is that its initscript is
using netstat (which was not installed) to determine presence of a
default route.

This particular wheezy system was installed from
http://archive.raspbian.org/raspbian with --arch=armhf but afaict the
bug is present in upstream Debian packaging too.

HTH :)


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

Bug#656585: iproute: ip l fails with RTNETLINK message

[Paul Fertser]

Hi,

Andreas, i do not understand the reasoning for l2tp to be higher in
the list than the link command. I think it's quite common for the more
experienced ip users to use the l abbreviation instead of the full
link command.

Can you please explain why l2tp should be added before link and not
after so the users of the more popular and older link command
wouldn't have to reteach themselves to type more to avoid hitting the
rarely needed l2tp command?

So my suggestion is to swap the lines to make link prioritised to
retain the old behaviour.



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

Bug#656850: MPlayer recommends libbluray1 which in turn recommends libbluray-bdj which requires JRE so the default mplayer install brings java bloat to the system

[Paul Fertser]

Package: mplayer
Version: 2:1.0~rc4.dfsg1+svn34540-1
Severity: minor

Trying to install mplayer on a system with default apt configuration
results in installing all the recommended packages as well which
necessarily brings in some headless Java variant as libbluray-bdj
dependency which is recommended by libbluray1 to the system which
might be highly undesired and confusing.

Imho it would be nice if mplayer only suggested libbluray1.

Package: libbluray1
Version: 1:0.2.1+git20111208.63e308d-1

Debian wheezy/sid armhf



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

Bug#656814: Severe sound distortion on armel/armhf

[Paul Fertser]

Package: libmad0
Version: 0.15.1b-6

Misdecoding due to incorrect code in
debian/patches/Provide-Thumb-2-alternative-code-for-MAD_F_MLN.diff

This is also reported at Ubuntu bugtracker at
https://bugs.launchpad.net/ubuntu/+source/libmad/+bug/587632

The proposed fix is at
http://bazaar.launchpad.net/~dave-martin-arm/ubuntu/maverick/libmad/fix-thumb2-MAD_F_MLN/download/dave.martin%40linaro.org-20100915140323-t681n45mgxc6j1k6/providethumb2alterna-20100319222415-dm2ft1kirrvbct5g-2/Provide-Thumb-2-alternative-code-for-MAD_F_MLN.diff
and it solves the issue here.

Debian GNU/Linux wheezy/sid armhf on a Tegra2 platform (Toshiba ac100).



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

Bug#536502: [PATCH] Implement runtime loading of RSA public keys

[Paul Fertser]

This patch allows crda to load and use additional keys from a
pre-configured location for the database signature verification. This
provides a convenient way for distro maintainers and card manufacturers to
supply a custom regulatory database along with their public keys, without
the need to recompile crda.

Implemented for USE_OPENSSL=1 case only because libgcrypt lacks PEM parser.

Default location for public keys in PEM format is
/etc/wireless-regdb/pubkeys and can be changed by specifying
RUNTIME_PUBKEY_DIR at the make command line.

Signed-off-by: Paul Fertser fercer...@gmail.com
---
 Makefile |3 ++-
 reglib.c |   20 
 2 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 3cc61c2..b8bc7d3 100644
--- a/Makefile
+++ b/Makefile
@@ -21,6 +21,7 @@ UDEV_RULE_DIR?=/lib/udev/rules.d/
 # keys are put when building. For example you can run
 # with make PUBKEY_DIR=/usr/lib/crda/pubkeys
 PUBKEY_DIR?=pubkeys
+RUNTIME_PUBKEY_DIR?=/etc/wireless-regdb/pubkeys
 
 CFLAGS += -Wall -g
 
@@ -29,7 +30,7 @@ all: all_noverify verify
 all_noverify: crda intersect regdbdump
 
 ifeq ($(USE_OPENSSL),1)
-CFLAGS += -DUSE_OPENSSL `pkg-config --cflags openssl`
+CFLAGS += -DUSE_OPENSSL -DPUBKEY_DIR=\$(RUNTIME_PUBKEY_DIR)\ `pkg-config 
--cflags openssl`
 LDLIBS += `pkg-config --libs openssl`
 
 reglib.o: keys-ssl.c
diff --git a/reglib.c b/reglib.c
index 6aeadcb..d199e13 100644
--- a/reglib.c
+++ b/reglib.c
@@ -1,12 +1,15 @@
 #include errno.h
 #include stdio.h
 #include arpa/inet.h
+#include sys/types.h
+#include dirent.h
 #include reglib.h
 
 #ifdef USE_OPENSSL
 #include openssl/objects.h
 #include openssl/rsa.h
 #include openssl/sha.h
+#include openssl/pem.h
 #endif
 
 #ifdef USE_GCRYPT
@@ -48,6 +51,9 @@ int crda_verify_db_signature(__u8 *db, int dblen, int siglen)
__u8 hash[SHA_DIGEST_LENGTH];
unsigned int i;
int ok = 0;
+   DIR *pubkey_dir;
+   struct dirent *nextfile;
+   FILE *keyfile;
 
if (SHA1(db, dblen, hash) != hash) {
fprintf(stderr, Failed to calculate SHA1 sum.\n);
@@ -71,6 +77,20 @@ int crda_verify_db_signature(__u8 *db, int dblen, int siglen)
rsa-n = NULL;
RSA_free(rsa);
}
+   if (!ok  (pubkey_dir = opendir(PUBKEY_DIR))) {
+   while (!ok  (nextfile = readdir(pubkey_dir))) {
+   if ((keyfile = fopen(nextfile-d_name, rb))) {
+   rsa = PEM_read_RSA_PUBKEY(keyfile,
+   NULL, NULL, NULL);
+   if (rsa) 
+   ok = RSA_verify(NID_sha1, hash, 
SHA_DIGEST_LENGTH,
+   db + dblen, siglen, rsa) == 1;
+   RSA_free(rsa);
+   fclose(keyfile);
+   }
+   }
+   closedir(pubkey_dir);
+   }
 #endif
 
 #ifdef USE_GCRYPT
-- 
1.6.4.4




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

Bug#536502: [PATCH] Implement runtime loading of RSA public keys

[Paul Fertser]

On Sat, Jan 23, 2010 at 02:54:14PM +0300, Paul Fertser wrote:
 + if (!ok  (pubkey_dir = opendir(PUBKEY_DIR))) {
 + while (!ok  (nextfile = readdir(pubkey_dir))) {
 + if ((keyfile = fopen(nextfile-d_name, rb))) {

Duh, of course it's wrong but i managed to have that key in the
current directory during testing :(

Amended version attached.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
From 3ad6149a22346c2f34224227a580c1424eed6b57 Mon Sep 17 00:00:00 2001
From: Paul Fertser fercer...@gmail.com
Date: Sat, 23 Jan 2010 14:34:14 +0300
Subject: [PATCH] Implement runtime loading of RSA public keys

This patch allows crda to load and use additional keys from a
pre-configured location for the database signature verification. This
provides a convenient way for distro maintainers and card manufacturers to
supply a custom regulatory database along with their public keys, without
the need to recompile crda.

Implemented for USE_OPENSSL=1 case only because libgcrypt lacks PEM parser.

Default location for public keys in PEM format is
/etc/wireless-regdb/pubkeys and can be changed by specifying
RUNTIME_PUBKEY_DIR at the make command line.

Signed-off-by: Paul Fertser fercer...@gmail.com
---
 Makefile |3 ++-
 reglib.c |   23 +++
 2 files changed, 25 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 3cc61c2..b8bc7d3 100644
--- a/Makefile
+++ b/Makefile
@@ -21,6 +21,7 @@ UDEV_RULE_DIR?=/lib/udev/rules.d/
 # keys are put when building. For example you can run
 # with make PUBKEY_DIR=/usr/lib/crda/pubkeys
 PUBKEY_DIR?=pubkeys
+RUNTIME_PUBKEY_DIR?=/etc/wireless-regdb/pubkeys
 
 CFLAGS += -Wall -g
 
@@ -29,7 +30,7 @@ all: all_noverify verify
 all_noverify: crda intersect regdbdump
 
 ifeq ($(USE_OPENSSL),1)
-CFLAGS += -DUSE_OPENSSL `pkg-config --cflags openssl`
+CFLAGS += -DUSE_OPENSSL -DPUBKEY_DIR=\$(RUNTIME_PUBKEY_DIR)\ `pkg-config 
--cflags openssl`
 LDLIBS += `pkg-config --libs openssl`
 
 reglib.o: keys-ssl.c
diff --git a/reglib.c b/reglib.c
index 6aeadcb..80ae062 100644
--- a/reglib.c
+++ b/reglib.c
@@ -1,12 +1,15 @@
 #include errno.h
 #include stdio.h
 #include arpa/inet.h
+#include sys/types.h
+#include dirent.h
 #include reglib.h
 
 #ifdef USE_OPENSSL
 #include openssl/objects.h
 #include openssl/rsa.h
 #include openssl/sha.h
+#include openssl/pem.h
 #endif
 
 #ifdef USE_GCRYPT
@@ -48,6 +51,10 @@ int crda_verify_db_signature(__u8 *db, int dblen, int siglen)
__u8 hash[SHA_DIGEST_LENGTH];
unsigned int i;
int ok = 0;
+   DIR *pubkey_dir;
+   struct dirent *nextfile;
+   FILE *keyfile;
+   char filename[PATH_MAX];
 
if (SHA1(db, dblen, hash) != hash) {
fprintf(stderr, Failed to calculate SHA1 sum.\n);
@@ -71,6 +78,22 @@ int crda_verify_db_signature(__u8 *db, int dblen, int siglen)
rsa-n = NULL;
RSA_free(rsa);
}
+   if (!ok  (pubkey_dir = opendir(PUBKEY_DIR))) {
+   while (!ok  (nextfile = readdir(pubkey_dir))) {
+   snprintf(filename, PATH_MAX, %s/%s, PUBKEY_DIR,
+   nextfile-d_name);
+   if ((keyfile = fopen(filename, rb))) {
+   rsa = PEM_read_RSA_PUBKEY(keyfile,
+   NULL, NULL, NULL);
+   if (rsa) 
+   ok = RSA_verify(NID_sha1, hash, 
SHA_DIGEST_LENGTH,
+   db + dblen, siglen, rsa) == 1;
+   RSA_free(rsa);
+   fclose(keyfile);
+   }
+   }
+   closedir(pubkey_dir);
+   }
 #endif
 
 #ifdef USE_GCRYPT
-- 
1.6.4.4

Bug#452977: buggy migw-runtime snprintf implementation

[Paul Fertser]

Hi,

Well, today i've spent probably 3 hours gdb'ing OpenOCD just to find
out i'm hitting a mingw bug that is 2 years old.

I do not understand Debian policies deep enough to judge about it but
i find the result a rather sad - i'd prefer to spend that time
sleeping or probably debugging something more cool and useful.

Attached is the patch i used to recompile mingw-runtime on Debian
testing.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
diff -ur mingw-runtime-3.13-20070825-1.old/mingwex/gdtoa/mingw_snprintf.c 
mingw-runtime-3.13-20070825-1/mingwex/gdtoa/mingw_snprintf.c
--- mingw-runtime-3.13-20070825-1.old/mingwex/gdtoa/mingw_snprintf.c
2010-01-14 16:14:08.0 +0300
+++ mingw-runtime-3.13-20070825-1/mingwex/gdtoa/mingw_snprintf.c
2010-01-14 16:14:34.0 +0300
@@ -465,7 +465,7 @@
len = LEN_LL;
  }
else
- len = LEN_LL;
+ len = LEN_L;
goto fmtloop;
case 'L':
flag_ld++;
@@ -617,6 +617,7 @@
break;
  case LEN_S:
*(short*)ip = c;
+   break;
  case LEN_LL:
*(long long*) ip = c;
break;

Bug#563136: linux-image-2.6.32-trunk-amd64: module ath5k not working (Invalid EEPROM checksum)

[Paul Fertser]

Confirmed here with AR2413 (AR5005G).

The relevant upstream bug is http://bugzilla.kernel.org/show_bug.cgi?id=14874 .

I confirm 
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commit;h=359207c687cc8f4f9845c8dadd0d6dabad44e584
 solves the issue for me.

Other wifi issues mentioned here seem to be unrelated, please report them 
separately.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com



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