Stephen Warren wrote:
I noticed that the concordance app is statically linked (even to libc,
let alone libconcord). I assume this wasn't intentional?
[EMAIL PROTECTED] concordance]$ ldd ./concordance
not a dynamic executable
Never mind; Some wierd libtool/autoconf thing. The real
Stephen Warren wrote:
See attached...
I also just validated (with a clean CVS checkout/build) that starting
with a working remote, forcing it into safe-mode, and updating with
--direct -F file causes the same problem:-(
I also captured the USB logs in Windows updating to the latest
Phil Dibowitz wrote:
Stephen - here's what I need, if you don't mind: upgrade to the latest
firmware using the official software, then dump the firmware using our
software (CVS latest, please), and send that file to me. Let me see the
magic bits there, compared to the file, and I can compare
Stephen Warren wrote:
The 85FB value is bytes 1 and 2 (0-based) of the firmware dump.
Oops. Make that bytes 0 and 1; I guess I got confused!
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R
On Fri, March 14, 2008 11:09 am, Phil Dibowitz wrote:
Stephen Warren wrote:
On Fri, March 14, 2008 2:23 am, Phil Dibowitz wrote:
That said, it appears that variables declared not at the top was in
fact
not
part of the c89 spec. But there was definitely pre-ANSI C.
I'm annoyed that gcc
The following is extracted purely from firmware files and USB logs, from
both Kevin's zip and my upgrade attempts:
remote, arch, fw version, d/l pattern, write pattern
550 9 2.2.3 8xFF 3a8d4847
628 7 3.04xFF 234d4847
659 7 4.14xFF ad8d4847
670 7 4.14xFF b4de4847
That was easy - I'd just accidentally included the hunk that fixed the
C++ v.s. C comment at the end of libharmony.h, which you already
committed separately, which caused the conflict.
So, here's the updated version, attached.
? libconcord/.libconcord.h.swp
Index: concordance/concordance.c
On Wed, March 26, 2008 11:55 pm, Phil Dibowitz wrote:
As I mentioned, I'd like the for(;;)s to be while(1)s.
Here you go; attached.
Index: concordance/concordance.c
===
RCS file:
On Thu, March 27, 2008 11:03 pm, Phil Dibowitz wrote:
Stephen Warren wrote:
On Wed, March 26, 2008 11:55 pm, Phil Dibowitz wrote:
Stephen Warren wrote:
That was easy - I'd just accidentally included the hunk that fixed the
C++ v.s. C comment at the end of libharmony.h, which you already
Stephen Warren wrote:
I'll commit to adding a size parameter to the firmware APIs too, within
a day (probably less) of this being in CVS to diff against.
Never mind; I have it done already. I'll follow up with the patch and
comments/explanations in a few moment.s
Phil Dibowitz wrote:
Stephen Warren wrote:
Phil Dibowitz wrote:
One comment on ** vs *. The code tends to use * in any non-public API, and
** only for public functions since C requires that. You converted various
private APIs to **, and I prefer to leave them * to be consistent
Is it possible to add a --with-libconcord=/path/to/it option to
concordance's configure script?
The reason is that I typically build, but don't install, libconcord,
then build concordance against it, using a configure command like this:
CFLAGS=-ggdb -I../libconcord LDFLAGS=-L../libconcord/.libs
Under Fedora 8 at least (and I'm sure others), compiling concordance.c
gives this warning:
concordance.c: In function ‘parse_options’:
concordance.c:589: warning: implicit declaration of function 'strdup'
Theoretically, strdup is prototyped by the include of string.h.
However, since concordance
Phil Dibowitz wrote:
Stephen Warren wrote:
Is it possible to add a --with-libconcord=/path/to/it option to
concordance's configure script?
I'd be happy to. I gotta remember how to do that with autoconf, shouldn't be
hard.
Keep in mind that you won't be able to do --with-libconcord
GetTag has an issue because it checks whether found is NULL before
assigning to it, but now it's a reference, so that check doesn't make
sense, and this renders the found value invalid, which breaks a lot of
things. The attached patch fixes this.
? concordance/.concordance.c.swp
?
I built libconcord under Windows in preparation for testing congruity
there, and found some issues. Attached are the fixes:
1) When I changed libconcord.h, I didn't update the Windows .def file.
The attached concordance-win-def.patch does this.
2) Marco should comment on this:
Both
Phil Dibowitz wrote:
Stephen Warren wrote:
I've sent the logs to you directly off-list, due to size.
Thanks. A few questions - your tarball had log2 and log3 (with 3 being
empty), but no log1 - was that on purpose? Also, is this writing a config,
or firmware? It looks like config. Seems
Phil Dibowitz wrote:
Stephen Warren wrote:
Both libconcord_winhid and concordance (and possibly other Window
projects I didn't build) attempt to link against odbc32.lib and
odbccp32.lib. I don't have either of these in Visual C++ Express 2005.
No apply:
Hunk #1 FAILED at 1.
Hunk #2
Stephen Warren wrote:
Phil Dibowitz wrote:
Stephen Warren wrote:
Both libconcord_winhid and concordance (and possibly other Window
projects I didn't build) attempt to link against odbc32.lib and
odbccp32.lib. I don't have either of these in Visual C++ Express 2005.
No apply:
It looks like
Latest libconcord.h contains:
static inline void debug(const char *str) {}
This causes a build failure because inline isn't a valid keyword in
standard ANSI C. Simply removing inline seems to fix the problem.
-
Check out
Phil Dibowitz wrote:
Stephen Warren wrote:
Latest libconcord.h contains:
static inline void debug(const char *str) {}
This causes a build failure because inline isn't a valid keyword in
standard ANSI C. Simply removing inline seems to fix the problem.
Already fixed...
I still get
Stephen Warren wrote:
Phil Dibowitz wrote:
Stephen Warren wrote:
Latest libconcord.h contains:
static inline void debug(const char *str) {}
This causes a build failure because inline isn't a valid keyword in
standard ANSI C. Simply removing inline seems to fix the problem.
Already fixed
Stephen Warren wrote:
I propose we replace -ansi -pedantic-errors with -std=c99.
Sorry, just remove -ansi -pedantic-errors and don't add -std=c99;
the variadic macro works with -std=c99, but the strdup prototype still
isn't present unless we just remove all the standard-selection options
.)
# This code NOT copyright Stephen Warren [EMAIL PROTECTED]
# This code is released into the public domain.
from ctypes import *
import platform
import sys
# Internal DLL handle
if platform.system() == 'Windows':
_dll = cdll.LoadLibrary('libconcord.dll')
else:
_dll = cdll.LoadLibrary
Phil Dibowitz wrote:
Stephen Warren wrote:
Stephen Warren wrote:
I propose we replace -ansi -pedantic-errors with -std=c99.
Sorry, just remove -ansi -pedantic-errors and don't add -std=c99;
the variadic macro works with -std=c99, but the strdup prototype still
isn't present unless we just
On Sun, March 30, 2008 11:41 pm, Phil Dibowitz wrote:
And again, you missed what I said about declarations not at the top. This
is why we use -ansi -pedantic-errors:
[EMAIL PROTECTED] tmp]$ gcc -std=c99 foo.c
[EMAIL PROTECTED] tmp]$ gcc -std=c99 -pedantic-errors foo.c
[EMAIL PROTECTED] tmp]$
I'm writing some code to identify what to do with EZHex/EZUp files
downloaded from the Logitech website.
I just realized I've never seen a learn IR command file (I have
connectivity, config update, and firmware all working).
Does anyone have any learn IR files for various remotes they could
mail
On Wed, April 2, 2008 2:22 am, Phil Dibowitz wrote:
Stephen Warren wrote:
Phil Dibowitz wrote:
Stephen Warren wrote:
Attached is a patch that adds the following line to the end of all
This doesn't seem to actually work for me. The weird thing is I've been
playing with it for a while and I
On Wed, April 2, 2008 2:36 am, Phil Dibowitz wrote:
Stephen Warren wrote:
In congruity, I have some code to identify the action to take for a
specific EzHex/EZUp file, without relying on any facet of the filename.
I'm curious as to what you use to figure it out... there are some tells
like
Phil Dibowitz wrote:
...
So I plan to switch this. Everywhere a USB message is constructed I'll NOT
include the extra 0-byte and then I'll ADD a 0-byte in the Windows code.
Does anyone have any objections to this or concerns?
Sounds like a great idea to me - I was a little confused by the
Stephen Warren wrote:
On Wed, April 2, 2008 2:36 am, Phil Dibowitz wrote:
Stephen Warren wrote:
In congruity, I have some code to identify the action to take for a
specific EzHex/EZUp file, without relying on any facet of the filename.
I'm curious as to what you use to figure it out
Phil Dibowitz wrote:
What about passing around a void* like I suggested with the size and all
hidden inside of but an export_blob() API that dumps it to something easy -
such as our uint8_t* with a size, and of course an import_blob() to go with?
Initially this will be kinda of silly because
Phil Dibowitz wrote:
Stephen Warren wrote:
OK. Here's a complete version, with concordance.c integration. It works
for all the files in harmony_usb_logs, and a file of each type that I
got from the Website.
I applied it, but with a few changes - see the CVS list for the actual diff
Here's an updated version of the USB patch that works with WinHID on
Windows. I had to fix:
HID_WriteReport: MS compiler won't allow creation of a variable-sized
array on the stack, so I made the code new/delete it instead.
HID_ReadReport: tmp wasn't being allocated, and assigning to data
On Fri, April 4, 2008 3:19 am, Phil Dibowitz wrote:
Stephen Warren wrote:
Here's an updated version of the USB patch that works with WinHID on
Windows. I had to fix:
HID_WriteReport: MS compiler won't allow creation of a variable-sized
array on the stack, so I made the code new/delete
Attached is the latest libconcord.py file, to match recent libconcord.h
changes.
Also included is a setup.py file, to go in the same directory. This is
essentially an install script; a standard thing to include when
distributing any Python module.
# This code NOT copyright Stephen Warren [EMAIL
of the existing
proprietary GUI application.
The download is available from:
http://www.wwwdotorg.org/downloads/congruity/congruity-5.tar.bz2
NOTE: congruity relies on libconcord from the latest CVS.
The changes are as follows:
* 2008-04-07 Stephen Warren [EMAIL PROTECTED] - congruity-5
On Thu, April 10, 2008 1:25 pm, Phil Dibowitz wrote:
Michael Frase wrote:
Hi Phil,
thanks for your quick replies and changes in cvs. I'm back again and
tested latest cvs with my harmony 555.
...
Here's whats REALLY odd. I massaged the LatestUpdate.EZUp to be in the
format we write out fw
Phil Dibowitz wrote:
Anyone else have anything they think needs to be in 0.20?
Well, since I've been using Doxygen a lot at work, I was contemplating
writing a bunch of Doxygen comments in libconcord.h, so we could
generate pretty looking doc pages etc., now that the API seems
reasonably stable
Phil Dibowitz wrote:
Stephen Warren wrote:
There is one cosmetic bug, in that print CTRL-H doesn't do a backspace
on Windows, so the percentage progress messages looks like turd. I'll
see if that's easy to fix...
Eh, what? That should never happen on windows:
#ifdef WIN32
On Fri, April 11, 2008 1:28 am, Phil Dibowitz wrote:
Oh, another thing I was thinking about for the release:
I was thinking of EITHER:
A. Splitting the changelog and having one in libconcord/ and one in
concord/ -- all the history would go in one (probably libconcord),
but starting with
Phil Dibowitz wrote:
Stephen Warren wrote:
Version 6 of congruity is released.
congruity is a Python/wxPython-based GUI for libconcord. It is intended
to handle downloads from the Harmony website, program the remote, and
communicate results back to the website - i.e. provide an open-source
Phil Dibowitz wrote:
Stephen Warren wrote:
As you may have noticed, congruity does this already at the application
level. This whole process obviously takes some time, and could even fail
(e.g. if user unplugs the remote.) This change probably requires
reset_remote having a callback
of the existing
proprietary GUI application.
The download is available from:
http://www.wwwdotorg.org/downloads/congruity/congruity-7.tar.bz2
NOTE: This release of congruity depends on libconcord release 0.20.
The changes are as follows:
* 2008-04-14 Stephen Warren [EMAIL PROTECTED] - congruity
Stephen Warren wrote:
Phil Dibowitz wrote:
FYI: I get the feeling that unistd.h may not be available on Windows - so
someone may want to test that and let me know...
Well, the attached patch fixes the compile failure.
However, it seems like there are some pretty serious issues
On Tue, April 15, 2008 9:35 am, Michael Frase wrote:
Any Suggestions? Is it possible to log the usb transfer (firmware
upgrade) in windows (like usbmon in linux)?
Yes. Use SnoopyPro, available from:
http://sourceforge.net/project/showfiles.php?group_id=34567
Once you have the captures in the
On Tue, April 15, 2008 12:18 am, Phil Dibowitz wrote:
Stephen Warren wrote:
This raises the question though: What happens if the current initial 5
second wait isn't long enough?
What do you mean? If my 5 second sleep isn't enough, I sleep for
another 5. And then another 5. And then 5 more. 5
On Wed, April 23, 2008 2:56 pm, Phil Dibowitz wrote:
On Wed, Apr 23, 2008 at 01:40:10PM -0400, Douglas E. Warner wrote:
I'm trying to get concordance/libconcord 0.20 packaged for Fedora
and am having some problems getting the perl bindings tests running;
I'm getting the following error (after
Just as an FYI, I'm going to be on vacation from this Monday through May
19th, probably without any email access.
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event.
Phil Dibowitz wrote:
Yeah, I figure I'll probably sign up for a sourceforge project for the
next release, or something like that, and use their web-space for that.=
That works as well, but even a small index.html in the directory you
have the downloads in works.
Here it is:
Andreas Schulz wrote:
Next, here comes the latest version of my IR learning patch for
libconcord.
A few comments on the API:
+ * pulse_count : total number of pulse and space durations in pulses
+ * pulses should start with a pulse and end with a space duration,
+ * hence pulse_count
On Mon, June 23, 2008 3:11 pm, Andreas Schulz wrote:
On Sunday 22 June 2008, Stephen Warren wrote:
In the documentation for get_key_name, it may be worth mentioning
that valid index values start at 1
anything wrong with index starting at 1 for '1'st entry?
Probably not, but it's sufficiently
On Mon, June 23, 2008 3:28 pm, Phil Dibowitz wrote:
Andreas Schulz wrote:
Well, concordance could do that as well, so what about:
char **get_keynames(uint8_t *data, uint32_t size);
void destroy_keynames(char **names);
and be done with the XML data in one call?
I don't think we need the
On Tue, June 24, 2008 1:04 am, Andreas Schulz wrote:
So, maybe we can agree on the following interface:
That should work. Just a few mostly small comments:
In the delete_* functions, I'd use a more descriptive name for the
parameter than garbage, e.g.:
void delete_key_names(char **key_names);
Phil Dibowitz wrote:
Koen Erens wrote:
hi,
is there any progress on the 525 firmware update?
i get the -110 error while trying to update from 2.1 to 2.6
Not at the moment sorry. I've finally started having time to work through
the backlog of patches while I was moving, and have gotten
I just used the IR learning feature in congruity/libconcord to learn the
home button of the original Roku Netflix player, and the Harmony
website recognized the signal as a pre-existing key it knew about. So,
the whole chain works!
Some feedback on error handling in the libconcord API:
Phil Dibowitz wrote:
Stephen - you have a patch waiting in the wings - can you send that in now?
Sorry to make you wait so long.
No problem; updated patch attached.
I have validated congruity against the resultant modified libconcord.py,
but using a previous version of Andreas's patch for the
Phil Dibowitz wrote:
Stephen - I know you've been keeping Congruity in step with Andreas patches,
but now that his patches are actually applied, you may want to make sure it
works with CVS head.
Yup, congruity (irlearn branch) works fine with libconcord CVS,
including for IR learning.
FYI, I've implemented IR learning support in congruity (either from the
Harmony or from a Pronto hex file). This support is now in the trunk of
SVN. Have at it!
-
This SF.Net email is sponsored by the Moblin Your Move
Phil,
I'd like to propose the attached patch, which adds callback parameters
to learn_from_remote.
Whilst it's not that useful in the current implementation (the progress
values aren't that meaningful), I'd argue it makes sense to make this
change before the next libconcord release, so that we
Steffen Sieg wrote:
I have another problem: while setting up my remote, there came up a file
named LearnIr.EZTut. And congruity does not recognize this. It was to
learn some instructions from an original remote control.
The most recent actual release of congruity doesn't support IR learning.
Phil Dibowitz wrote:
Stephen,
Have you been looking at any of the firmware-on-525 stuff? I've poured over
it several times and sent several debug patches to folks and looked through
the dumps a lot...
I haven't looked at it at all. I thought the thing you were missing was
answered by Kevin
See attached.
Index: libconcord/INSTALL.linux
===
RCS file: /cvsroot/concordance/concordance/libconcord/INSTALL.linux,v
retrieving revision 1.9
diff -u -p -r1.9 INSTALL.linux
--- libconcord/INSTALL.linux 4 Mar 2009 00:20:07 - 1.9
Phil Dibowitz wrote:
Stephen,
I went to go look at bug 2786023 about congruity getting undefined symbols,
but I didn't get very far. It looks like with the wx module changed, or you
made a typo:
It looks like I've mostly run congruity using wxGTK-2.8.xx; it worked on
Fedora 10 last time I
Marc Williams wrote:
Thanks, but neither the install_policykit nor the install udev worked (I
didn't try the 3rd one). What did work though was this:
echo 'SYSFS{idVendor}==046d, SYSFS{idProduct}==c111, MODE=666'
|sudo tee /etc/udev/rules.d/custom-concordance.rules
That's essentially
Marc Williams wrote:
Thanks, but neither the install_policykit nor the install udev worked (I
didn't try the 3rd one). What did work though was this:
echo 'SYSFS{idVendor}==046d, SYSFS{idProduct}==c111, MODE=666'
|sudo tee /etc/udev/rules.d/custom-concordance.rules
That's essentially
Andreas Schulz wrote:
Stephen,
After some time, I now had reason to check the Pronto code
conversion of congruity, just to discover an error in the code:
Thanks for the patch. I guess I missed that bit when I was reading the
spec! I've checked in the fix to congruity SVN.
You just copy the
Mathieu Trudel wrote:
Le dimanche 11 octobre 2009 à 23:56 -0600, Stephen Warren a écrit :
However, I'm quite open to replacing the image in congruity, if anyone
has any image that has a better license, and looks good...
Stephen,
Attached is a picture I took of my own Harmony 670 today
Phil Dibowitz wrote:
On Fri, Nov 20, 2009 at 01:31:32PM -0500, Mathieu Trudel-Lapierre wrote:
Note, it's a -dfsg upload because I replaced the remote.png image with
one I took of my own Harmony 670, scaled and cropped to a similar
size, to be able to upload with no license issues. Perhaps the
Mathieu Trudel-Lapierre wrote:
Stephen,
I think in principle I agreed, but was still waiting on a higher-res or
modified image or something?
That's very possible, I'm kind of bad at following up...
And looking back at the thread, it's indeed what the issue was.
I've attached the
Phil Dibowitz wrote:
For those following along at home...
I had a small bit of time to look into this this week.
The 700's response to GET_IDENTITY is completely different. And honestly, I
don't have the time to pull it apart, at least for the next couple of weeks.
The short of it is,
So, I've taken a look at the Harmony 700 logs, and overall it looks
basically similar to other remotes. However, there are definitely some
differences that will take some work.
To decode some more, it'd be useful if we could capture a complete trace
of the HTTP traffic between Logitech's software
On 03/30/2010 09:02 PM, Stephen Warren wrote:
So, I've taken a look at the Harmony 700 logs, and overall it looks
basically similar to other remotes. However, there are definitely some
differences that will take some work.
I got a 700 today via eBay. By correlating some stuff against the HTTP
On 06/06/2010 04:55 AM, Phil Dibowitz wrote:
On 06/05/2010 09:44 PM, SourceForge.net wrote:
Here's the status:
Thanks for updating the bug, and for all the work, Stephen.
I'm responding to the list and not the bug since this is just discussion and
note an update.
A few thoughts:
1. Have
While testing out Harmony 770 support, I found a bug in the Python
bindings' error checking of a couple functions that return something
other than a libconcord return code.
Signed-Off-By: Stephen Warren swar...@wwwdotorg.org
Index: bindings/python/libconcord.py
Attached is a patch to support the Harmony 700.
Signed-Off-By: Stephen Warren swar...@wwwdotorg.org
Note: The new prep_config/finish_config functions are technically
required to match the Windows software. However, during my testing, I
forgot to update congruity to call those functions
On 07/23/2010 12:40 PM, Phil Dibowitz wrote:
On Thu, Jul 22, 2010 at 07:18:50PM -0600, Stephen Warren wrote:
Oh, and I added the new functions to the Python bindings too, which I
forgot before.
Cool. Can you either (1) do the same for the perl bindings or (2) create a bug
(and assign
On 07/24/2010 12:50 AM, Phil Dibowitz wrote:
On Fri, Jul 23, 2010 at 09:41:14PM -0600, Stephen Warren wrote:
On 07/23/2010 12:40 PM, Phil Dibowitz wrote:
On Thu, Jul 22, 2010 at 07:18:50PM -0600, Stephen Warren wrote:
Oh, and I added the new functions to the Python bindings too, which I
On 07/26/2010 01:04 PM, Phil Dibowitz wrote:
On Sat, Jul 24, 2010 at 07:58:27PM -0600, Stephen Warren wrote:
OK. I added the prep_config/finish_config to test.pl and validated that
this works on the 700. Updated version is attached.
Thanks!
I did a more thorough look through the code
On 07/27/2010 01:44 PM, Phil Dibowitz wrote:
I've also updated the website's supported-models page to list the arch of
the 700, link to the bug, and say it's supported in CVS.
Out of curiosity, have you looked into firmware support at all?
I did a little. From the protocol side, I think there
On 07/29/2010 02:35 PM, Phil Dibowitz wrote:
All,
As I'm starting to code up 89x support I realize I'm likely going to have to
make more significant breakages to the API than the 700 made...
So my plan at this point is to prep an 0.22 release, and get that out,
hopefully this weekend, and
On 07/29/2010 05:14 PM, Stephen Warren wrote:
On 07/29/2010 02:35 PM, Phil Dibowitz wrote:
All,
As I'm starting to code up 89x support I realize I'm likely going to have to
make more significant breakages to the API than the 700 made...
So my plan at this point is to prep an 0.22 release
On 07/31/2010 08:01 AM, Phil Dibowitz wrote:
Stephen,
You're 700 patch breaks config dumps - at least for the 880, but I would
guess for all remotes.
...
#8 0xb7e1917d in operator new[](unsigned int) () from /usr/lib/libstdc++.so.6
#9 0xb7fbdb52 in read_config_from_remote (out=0xbc00,
On 07/31/2010 08:35 PM, Stephen Warren wrote:
On 07/31/2010 08:01 AM, Phil Dibowitz wrote:
Stephen,
You're 700 patch breaks config dumps - at least for the 880, but I would
guess for all remotes.
...
#8 0xb7e1917d in operator new[](unsigned int) () from /usr/lib/libstdc++.so.6
#9 0xb7fbdb52
On 08/01/2010 08:37 AM, Phil Dibowitz wrote:
On 08/01/2010 05:39 AM, Stephen Warren wrote:
Attached is a patch to fix this. I must have confused a couple different
lines when reformatting the ArchList... It's a good thing this happened
on a remote we have for testing!
Yeah. One of the things
Phil Dibowitz wrote:
On 08/01/2010 08:44 PM, Stephen Warren wrote:
On 08/01/2010 08:38 AM, Phil Dibowitz wrote:
On 08/01/2010 04:27 AM, Stephen Warren wrote:
Oh, perhaps we should add a note in the libconcord README re: needing a
kernel patch to get the 700 working?
Have we tested
* 2010-08-01 Stephen Warren s-t-concorda...@wwwdotorg.org
- congruity-15 is released
- Call new APIs in libconcord-0.22, for Harmony 700 support.
- Tweak WrappedStaticText.UpdateText again, so it shows all text and
doesn't wrap it strangely, at least with Lucids's wxpython
2.8.10.1-0ubuntu1
Stephen Warren wrote:
Well, there's a small build problem on Windows, since I forgot to add
the new APIs to the DLL export file; see attached patch. (Hopefully this
applies OK, since I generated it using Cygwin; perhaps the line-endings
are broken, but it should be obvious-enough to apply
On 08/12/2010 10:16 AM, Phil Dibowitz wrote:
On Thu, Aug 12, 2010 at 04:55:25PM +0100, Chris Mayo wrote:
In 0.22 libconcord.py sets: ABI_VERSION = 2
causing it to look for libconcord.so.2
Crap. That should have gone 0 - 1, not 0 - 2.
I have to release a 0.23 this weekend anyway, I'll fix
Sorry for top-posting, but I'm making a general response rather than to
individual points.
So, I don't think it'd be that hard for congruity to support any of the
API designs below, including different paths for different remote
architectures all determined at run-time.
However, I'd prefer a
On 08/31/2010 02:26 PM, Phil Dibowitz wrote:
On 08/31/2010 06:08 AM, Stephen Warren wrote:
So, perhaps:
// Returns TLOConnectivity, TLOUpdateConfiguration, TLOUpdateFirmware
TopLevelOperation *gen_op_from_website_file(remote, filename);
// Always returns TLOBackupFirwmare
TopLevelOperation
On 10/31/2010 06:01 AM, David Sheldon wrote:
It seems that the config flash size detection doesn't work well on my 525,
see the output of concordance -v -i next.
This may be another fallout from my reformatting of the remote
information table. Does the following patch solve your issue?
diff
On 01/08/2011 11:02 AM, Fredrik Sjögren wrote:
Hi!
If I buy this one, will I be able to use it using Linux?
In the support matrix is says that firmware updates is not working. Do I
need that?
It's fairly unlikely you'll need firmware upgrade.
In my uuntu 0.21 is the current version but
On 01/09/2011 12:52 PM, Damian wrote:
Hi.
When will the support for Harmony 900 be available?
I don't think there is a specific time-scale; it all depends on when
people have the time to work on it.
The original software is really crap for customizing.
concordance/congruity don't replace
On 02/19/2011 06:06 PM, Phil Dibowitz wrote:
On 10/15/2010 08:37 AM, Marc Williams wrote:
Using stock Ubuntu 10.04 I tried building concord .23/congruity 15 for
my 880. It works well up to a point.
Everything is recognized and the remote update proceeds normally through
Verify Upgrade
On 06/06/2011 09:57 PM, Stephen Warren wrote:
On 06/04/2011 08:59 PM, Mathieu Trudel-Lapierre wrote:
Hi,
Here I'm reporting an issue I got from the Debian bugs for congruity.
For reference, that's http://bugs.debian.org/584896.
Apparently congruity tries to do the Reconnect to Remote task
On 07/23/2011 01:19 AM, Phil Dibowitz wrote:
On 03/08/2011 09:09 AM, Phil Dibowitz wrote:
Stephen -
Any comments on this? I'd like to prepare to merge this to HEAD, but you're
the primary consumer (other than me), so I'd like any input you have...
Stephen, you still alive?
I'd like to get
On 07/15/2012 08:53 AM, Scott Talbert wrote:
Hi Stephen,
I have been contributing to Concordance lately, and I have written a
patch for Congruity to port it to the new libconcord API. If you have
some time, I would greatly appreciate it if you could review the patch,
which I have attached.
On 07/26/2012 07:29 PM, Scott Talbert wrote:
On Mon, 23 Jul 2012, Stephen Warren wrote:
...
If you want, perhaps I can hand off congruity maintenance to you since
you've obviously got some interest in it; I assume that Sourceforge will
let me set up other committers/admins. Let me know if you
On 10/24/2012 05:19 PM, Curtis Walker wrote:
Hello! My first email to the list.
I finally got sick of booting into Windows just to update my Harmony
525. It's about the only thing I still use Windows for, so finding
concordance and congruity was most welcome.
Anyway, I have successfully
1 - 100 of 103 matches
Mail list logo
