Bug#497200: [Debian-eeepc-devel] Bug#497200: ITP: rt2860-source -- source for RT2860 wireless adapter kernel module
Damyan Ivanov wrote: There may be some licensing problems and this is why I CC debian-legal. All the sources are licensed under GPL-2+, except one file, include/firmware.h, which is generated from a binary blob and contains the following notice: [snip] Looks bad to me. I did not yet check if this code is actually linked in the GPL-2+ module, but have a bad feeling it it does. Would a compiled GPL source, including firmware.h be even distributable? Perhaps the module can be changed to load its firmware from external file or even not need that nasty firmware.h (there are traces of support to other hardware and that firmware may be for them). There's some code in common/rtmp_init.c that's inside #ifdef BIN_IN_FILE that tries to get the firmware from a file, and falls back to the contents of firmware.h. BIN_IN_FILE is not defined, and so it unconditionally uses firmware.h. I have had a quick try at enabling BIN_IN_FILE, and defining RTMP_FIRMWARE_FILE_NAME to point to common/rt2860.bin, and according to the debug output it worked. I can't be certain though, as it still has firmware.h compiled in as a fallback and unless you power-cycle you can't be sure that the previous download has been lost. Someone keen could probably convert it to use the proper kernel firmware loading infrastructure. The code that does this seems to be quite localised in common/rtmp_init.c. Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311597: One year later, any progress?
A year has passed since this was opened. People find Anyterm difficult to compile from source, because of the dependencies on Apache, Boost and Rote. See the Anyterm forum for unending discussions. A binary package would make life easier for these people. Is it going to happen? Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311597: anyterm build issues
Roberto C. Sanchez wrote: # From version 0.11, Anyerm needs to access data in an internal # ROTE data structure. To do so it needs to find the roteprivate.h # header file, which is in the rote source directory. Please adjust # the following line to specify the directory in which this file can # be found. ROTE_PRIVATE_DIR=/usr/local/src/rote There are only two ways to solve this for the packaging of anyterm as a Debian package: 1. Copy the roteprivate.h file from librote-dev into the source package for anyterm. 2. Put the roteprivate.h into the librote-dev package. Neither is acceptable. The only alternative I can come up with is to talk to Bruno (the ROTE) developer and see if he is willing to include the data structures that you need directly in the rote.h header. Anyterm reads the file descriptor for the pseudoterminal that ROTE creates (backend.cc, lines 107 294). This is currently in the private part of the ROTE state. It could easily be moved to the public part of the state, but it would result in binary incompatibilities: programs using ROTE would have to be recompiled. Currently there is no attempt at library version management. I do not know the best way to cope with this, so there is the current hack. At some point in the future I may need other binary-incompatible changes to ROTE. One example is support for UTF-8. Another is support for not-pseudo terminals, e.g. serial ports, another is underlining. When I come to this I will consider whether it is better to get these changes back into ROTE and deal with the library verioning problem, or include a modified version of ROTE with the Anyterm source. In the past Bruno has accepted my patches and included them in the project's CVS repository, but they have never made it into a release. My feeling is that Bruno finds the current ROTE to be quite adequate for his purposes, and while he is pleased to see it being used, he does not have much time for working on it. How you proceed is entirely up to you. A far more important consideration is how you intend to package this in a secure fashion, so that users (a) know what they are installing, and (b) are presented with a quick-and-easy way to make it as secure as it can be. apt-get install skips all the security warnings that someone installing from the online instructions would see. For example, someone has today posted a good solution to the problem of Apache log files using SetEnvIf. You certainly ought to include something like that. A couple of issues have been found in 1.1.2. There will probably be a 1.1.3 in the next couple of days. Regards, --Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311597: anyterm build issues
Including a custom version of ROTE with anyterm would probably cause the package to be rejected. .. Have you considered forking ROTE So do you think that forking a custom version is good or bad? As I said this may become an issue if / when I need to make further changes. For the time being I am happy with things as they are. I have not had any feedback from users complaining about the current arangement. There are more important things on my to-do list than solving this problem. or asking Bruno to allow you to take a more active role (like CVS commit access)? So what would I commit? If I wanted a change, I would send him a patch. But if I submit a patch that causes binary incompatibility, that will cause problems. (Or, at least, it causes issues that *I* don't properly understand. I don't know who is using ROTE and for what.) * apt-get install gets the files in place, but the module remains disabled * Document well all potential security issues and provide references for external reading (including the anyterm web pages/forums). OK, but you need to present a default configuration where users have *no excuse* for ending up with an insecure system. People will always tend to do the minimum that is necessary to get something working. --Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311597: Happy to help
Hi, I'm the author of Anyterm. I'm a Debian user and would be very happy to help with packaging in whatever way I could - though I currently have only the vaguest idea of what happens inside a .deb file. If what you really wanted was a MindTerm replacement, have a look at the comparisons page on the Anyterm website where I have listed other SSH Java applets. I think that the major issue with installing this is security. At present, people have to read the instructions and so should have some idea of what the security implications are before installing. If they can just apt-get install it, they miss that. I am really hoping that someone who has some experience with security auditing, preferably in connection with Apache, will take an interest. Regards, Phil Endecott. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
