[Pkg-electronics-devel] Bug#852856: collaborate

[Jonathan McDowell]

On Wed, Mar 14, 2018 at 04:07:54PM +0100, Geert Stappers wrote:
> On Mon, Mar 12, 2018 at 10:37:28PM +0000, Jonathan McDowell wrote:
> > If you want to work together you have to have a discussion. I appreciate
> > the bug has been languishing without a response but it pre-dates my
> > involvement with the OpenOCD package and it's not been as high priority
> > as getting the package up to date with upstream or dealing with security
> > issues.
> 
> Yes, I'm here for working together, for having a discussion.
> 
> For creating concence.

I don't understand. Can you rephrase?

> > On Mon, Mar 12, 2018 at 11:13:26PM +0100, Geert Stappers wrote:
> > > On Mon, Mar 12, 2018 at 09:39:29AM +0000, Jonathan McDowell wrote:
> > > > Is there a direct 1:1 mapping of devices that OpenOCD and urjtag
> > > > support, or is one a subset of the other?
> > > 
> > > Seen the question, but I don't see where it fits in the discussion
> > > about a openocd file moving into seperate package.
> > 
> > If one program is a strict subset of the other in terms of supported
> > adaptors then it may make sense for the program with the larger support
> > matrix to split a file out so that the other can take advantage of it.
> > If the 2 programs support different adaptors then I'm not sure of the
> > benefit; it becomes extra work on both parts to maintain the overlapping
> > list?
> 
> The list will contain always more adapters then an user of openocd
> or urjtag has. So there is always that kind of "overlap".
> 
> A JTAG adapter is hardware with JTAG electronics on one side
> and other at the other side. Example given: USB
> 
> Both openocd and urjtag drive / control / manage JTAG adapters.
> That is the reason for an udev package that both packages can use.
> 
> We are talking about a file with lines like
> ATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6001", MODE="660", GROUP="plugdev", TAG+="uaccess"
> 
> The VID and PID varies
> 
> 
> Now some odd text, I still don't get the set question. 
> With 1:1 set for openocd and urjtag:  all fine.
> Openocd set larger:  urjtag is missing functionality
> Urjtag set larger:  openocd is missing functionality

I'm trying to understand what the point of this bug is.

Originally I thought it was that urjtag has no adapter list and wants
some udev rules for access and wanted to piggy back on OpenOCD's list.

Subsequently it sounds that while this might be part of the reason it is
additionally desired to just have a "list of JTAG adapter udev rules"
that do not correspond to either OpenOCD or urjtag but include aspects
of both.

I still don't understand why each package can't manage the pieces of
hardware that they support, instead of having a new very small package
that ultimately will require work on both sides to ensure it stays valid
for all adapters (rather than, say, just being able to be a copy of the
OpenOCD upstream list, if urjtag had been a strict subset). There's no
issue with multiple udev rules files covering the same rule - the last
one will win and I'm assuming both packages will be adding them as
plugdev anyway so they'll be the same. In the same was as there is a
/lib/udev/rules.d/60-openocd.rules there can be a
/lib/udev/rules.d/60-urjtag.rules?

J.

-- 
   "Could I have an 'E', please,   |  .''`.  Debian GNU/Linux Developer
       Bob?"  (Blockbusters)       | : :' :  Happy to accept PGP signed
                                   | `. `'   or encrypted mail - RSA
                                   |   `-    key on the keyservers.