tux-droid-user Mailing List for Tux Droid CE (Page 16)
Status: Beta
Brought to you by:
ks156
Menu
▾
▴
tux-droid-user — tuxdroid-user
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
(129) |
Apr
(96) |
May
(38) |
Jun
(70) |
Jul
(7) |
Aug
(27) |
Sep
(10) |
Oct
|
Nov
(2) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(9) |
Feb
(7) |
Mar
|
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Henrik G. B. <hg...@if...> - 2007-03-19 11:31:54
|
Hi. I've been testing my nice tuxdroid this weekend, and in that process I've been restarting tuxdaemon quite a lot. I think that's due to port 5000 (or whatever it was) being in use. A SO_REUSEADDR fixes it for me, at least. Here's a patch, if you're interested. |
|
From: David B. <da...@ja...> - 2007-03-18 22:57:27
|
On Sun, 18 Mar 2007 18:28:49 +0100, Kiffin Gish <kif...@pl...> wrote: > When reprogramming my tuxdroid with new firmware is the command 'tuxup > --main path/to/hex/folder/' sufficient or do I have do use the --all > flag? > > The reason I am asking is because --main works fine but --all results in > errors for some reason after a couple hex files because it cannot find > udev/uhub0.5 anymore. > Right now there's only an update of the USB CPU (tuxusb) so to reprogram it, simply do 'tuxup tuxusb.hex'. --main is not appropriate here as it doesn't reprogram the USB, --all is fine and as the USB is reprogrammed first, you don't have to care if anything goes wrong afterwards. But so your udev problem is still there. Do you get the same when using the daemon? What distro do you use? |
|
From: David B. <da...@ja...> - 2007-03-18 22:41:49
|
On Sun, 18 Mar 2007 19:39:47 +0100, Philippe Teuwen <ph...@te...> wrote: > Décidément... > > I tried to append some info to > http://www.tuxisalive.com/issue-trackers/tux-daemon/3 > several times but no way, when posting the form nothing happens and the > browser timeouts :-( > > That was my comment on the 100% CPU bug: > > I experienced the same on version 0.2.0-alpha2 > Note that tuxdaemon -d -v works properly, only tuxdaemon -d eats the CPU > Your comment is there (2 times, I deleted one ;-) but indeed there are problems when posting an issue, the complete server freezes for a while. We reported that a few weeks ago to the administrator but nothing has been done yet it seems. Otherwise it works, you just have to wait for one minute after you post it... :/ |
|
From: David B. <da...@ja...> - 2007-03-18 22:35:26
|
On Sun, 18 Mar 2007 16:00:45 +0100, Kiffin Gish <kif...@pl...> wrote: > I'm having a problem with upgrading the firmware and reported it on the > forum. > > So what you're saying is that I should rather report it via the issue > tracker? If you're not sure it's a bug, it's better to report it here or on the forum first as you're more likely to get feedback quickly. I've seen it's fixed and I prefer it that way as I had no idea what was going wrong with udev on your system :-) david |
|
From: David B. <da...@ja...> - 2007-03-18 22:20:41
|
Hi Philippe, Thank for the feedback, it's now fixed. As I told you, changing the order in the sources is not the good way to solve thatvdefinitely but this is indeed a bug of the firmware and the title describes it perfectly so please go ahaead and file the bug. I would add it on the firmware bugtracker though, I added a 'General' category as this is not specific to any firmware like you explained. Thanks, david On Sun, 18 Mar 2007 19:29:08 +0100, Philippe Teuwen <ph...@te...> wrote: > I tried to post my patch on > http://www.tuxisalive.com/issue-trackers/tuxup > but there is no zone defined and the tool complains about mandatory > selection of a zone: > > Zone (Requis) > Sélectionnez une zone ou ce ticket est approprié. > Zone is required, please correct. > > > Here's a copy of what I planned to post on the tracker (just to avoid > loosing it): > > TITLE: Wrong order in version-revision-author structs, tuxup fails > > DETAILS: > This is actually a firmware bug, not a tuxup bug but it concerns > differents parts of the firmware so I think it is better to explain it > here than in the various sub-sections of firmware tracker. > When compiling the firmware files and trying to upload them, I get the > error > tuxup tuxaudio.hex > [FAIL] Programming of 'tuxaudio.hex' failed, this file is not a correct > hex file for that CPU > or tuxup tuxcore.hex > [FAIL] Programming of 'tuxcore.hex' failed, this file is not a correct > hex file for that CPU > To fix those problems I changed: > firmware/tuxaudio/trunk/main.c invert lines 42 and 44 > firmware/tuxcore/trunk/global.c invert lines 53 and 55 > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > tux-droid-user mailing list > tux...@li... > https://lists.sourceforge.net/lists/listinfo/tux-droid-user |
|
From: David B. <da...@ja...> - 2007-03-18 22:03:11
|
On Sun, 18 Mar 2007 17:39:07 +0100, Philippe Teuwen <ph...@te...> =
wrote:
> Hi David,
>> If you recompile the firmware, you have to upload both hex and eep
>> files otherwise the standalone behavior looks very strange. Different=
>> versions of GCC will reorganize data differently.
> Ok thanks! That works better now!
>> And that's also probably the reason why you had that such problems
>> with the version structure of your hex file.
>> At 0x1DF0 (just before the bootloader) I placed 3 structures to get
>> the version number (which also includes the CPU number), the revision=
>> number and an ID for the author. I use the CPU number and version
>> number to validate the hex file in tuxup and know which CPU to =
>> reprogram.
> No I don't think so because the order is wrong *in the hex file* and
> tuxup complains about it so eep file has nothing to do with that point=
I
> think.
>
>
> So now I can mangle the firmware :-) but still with this change in =
> global.c:
>>> const version_t tag_version __attribute__((section(".version"))) =3D=
>>> {VERSION_CMD, CPU_NUMBER, VER_MAJOR, VER_MINOR, VER_UPDATE};
>>> const revision_t vn_revision __attribute__((section(".version"))) =3D=
>>> {REVISION_CMD, SVN_REV, SVN_STATUS};
>>> const author_t author __attribute__((section(".version"))) =3D
>>> {AUTHOR_CMD, AUTHOR_ID, 0};
> which sounds reasonible as this is the expected order in the hex file.=
What I meant is that the version of GCC you use when compiling the =
firmware can freely arrange the order of 3the structures in the .versio=
n =
section. GCC is not due to follow any specification when arranging parts=
=
of a section, or bytes of a structure or bits of a bitfield. With my =
version of GCC that works just fine with the order actually in the =
firmware. So changing the order like you did is OK for your version but =
is =
not the good solution for everybody.
>
> My first personalized firmware has the following behaviour:
> Eyes closed when no rf link and opened when rf link is established.
> Note that it would be easier if there was a CLOSE_EYES_CMD
> I solved it by using
> #define RF_DISCONN_E_SEQ {\
> 0, OPEN_EYES_CMD, BLINK_EYES_CMD, 1, 0,
>
> Note that for such personalization, only eep file is required so actua=
lly
> you don't have to fix global.c if you don't plan to use the hex file.
Close eyes will be added if it's still not there. That's just because th=
e =
switch that detects when the eyes are closed has only been working =
correctly very late in production.
The idea of storing all these sequences and configurations in eeprom is =
to =
be able to update them from your application without the need to bootloa=
d. =
That's still not possible now but there isn't much to do to finish it.
Great to see the first custom firmware btw :-)
Cheers,
david
|
|
From: Philippe T. <ph...@te...> - 2007-03-18 18:39:54
|
Décidément... I tried to append some info to http://www.tuxisalive.com/issue-trackers/tux-daemon/3 several times but no way, when posting the form nothing happens and the browser timeouts :-( That was my comment on the 100% CPU bug: I experienced the same on version 0.2.0-alpha2 Note that tuxdaemon -d -v works properly, only tuxdaemon -d eats the CPU Phil |
|
From: Philippe T. <ph...@te...> - 2007-03-18 18:29:27
|
I tried to post my patch on http://www.tuxisalive.com/issue-trackers/tuxup but there is no zone defined and the tool complains about mandatory selection of a zone: Zone (Requis) Sélectionnez une zone ou ce ticket est approprié. Zone is required, please correct. Here's a copy of what I planned to post on the tracker (just to avoid loosing it): TITLE: Wrong order in version-revision-author structs, tuxup fails DETAILS: This is actually a firmware bug, not a tuxup bug but it concerns differents parts of the firmware so I think it is better to explain it here than in the various sub-sections of firmware tracker. When compiling the firmware files and trying to upload them, I get the error tuxup tuxaudio.hex [FAIL] Programming of 'tuxaudio.hex' failed, this file is not a correct hex file for that CPU or tuxup tuxcore.hex [FAIL] Programming of 'tuxcore.hex' failed, this file is not a correct hex file for that CPU To fix those problems I changed: firmware/tuxaudio/trunk/main.c invert lines 42 and 44 firmware/tuxcore/trunk/global.c invert lines 53 and 55 |
|
From: Kiffin G. <kif...@pl...> - 2007-03-18 17:28:45
|
When reprogramming my tuxdroid with new firmware is the command 'tuxup --main path/to/hex/folder/' sufficient or do I have do use the --all flag? The reason I am asking is because --main works fine but --all results in errors for some reason after a couple hex files because it cannot find udev/uhub0.5 anymore. -- Kiffin Gish <kif...@pl...> |
|
From: Philippe T. <ph...@te...> - 2007-03-18 16:39:20
|
Hi David,
> If you recompile the firmware, you have to upload both hex and eep
> files otherwise the standalone behavior looks very strange. Different
> versions of GCC will reorganize data differently.
Ok thanks! That works better now!
> And that's also probably the reason why you had that such problems
> with the version structure of your hex file.
> At 0x1DF0 (just before the bootloader) I placed 3 structures to get
> the version number (which also includes the CPU number), the revision
> number and an ID for the author. I use the CPU number and version
> number to validate the hex file in tuxup and know which CPU to reprogram.
No I don't think so because the order is wrong *in the hex file* and
tuxup complains about it so eep file has nothing to do with that point I
think.
So now I can mangle the firmware :-) but still with this change in global.c:
>> const version_t tag_version __attribute__((section(".version"))) =
>> {VERSION_CMD, CPU_NUMBER, VER_MAJOR, VER_MINOR, VER_UPDATE};
>> const revision_t vn_revision __attribute__((section(".version"))) =
>> {REVISION_CMD, SVN_REV, SVN_STATUS};
>> const author_t author __attribute__((section(".version"))) =
>> {AUTHOR_CMD, AUTHOR_ID, 0};
which sounds reasonible as this is the expected order in the hex file.
My first personalized firmware has the following behaviour:
Eyes closed when no rf link and opened when rf link is established.
Note that it would be easier if there was a CLOSE_EYES_CMD
I solved it by using
#define RF_DISCONN_E_SEQ {\
0, OPEN_EYES_CMD, BLINK_EYES_CMD, 1, 0,
Note that for such personalization, only eep file is required so actually
you don't have to fix global.c if you don't plan to use the hex file.
Phil
|
|
From: Kiffin G. <kif...@pl...> - 2007-03-18 15:00:43
|
I'm having a problem with upgrading the firmware and reported it on the forum. So what you're saying is that I should rather report it via the issue tracker? On Sun, 2007-03-18 at 15:29 +0100, David Bourgeois wrote: > On Sat, 17 Mar 2007 14:46:16 +0100, Kiffin Gish <kif...@pl...> > wrote: > > > Is there a Tux bug-tracking system somewhere in order to report bugs > > found while installing etc? > > > > Sure, you'll find links in the developer corner. If you go the the daemon > project, there's a 'Issue tracker' link. > The python API also has one. If you have problems with the firmware or > hardware, use the issue tracker of the firmware. If that's a bug in a > small python application, I though an issue tracker was a bit overkill for > each app so use contact address instead. > > Direct links: > daemon http://www.tuxisalive.com/issue-trackers/tux-daemon/ > firmware/harware http://www.tuxisalive.com/issue-trackers/firmware > API http://www.tuxisalive.com/issue-trackers/api > bootloader http://www.tuxisalive.com/issue-trackers/tuxup > > david > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ tux-droid-user mailing list tux...@li... https://lists.sourceforge.net/lists/listinfo/tux-droid-use |
|
From: David B. <da...@ja...> - 2007-03-18 14:45:03
|
On Sun, 18 Mar 2007 12:30:24 +0100, Philippe Teuwen <ph...@te...> =
wrote:
>
>> Original firmware:
>> :0C1DF000C8000300C9D10100CA000000B7^
>> =3D> version command =3D C8, version =3D 0.3.0
>>
>> My firmware:
>> :0C1DF000CA000000C9640000C800030025^
>> =3D> version command =3D CA, version =3D 0.0.0 ??
>>
> Actually apparently the order of version, revision and author fields w=
as
> wrong
> I tried to change global.c to reorder them:
>
> const version_t tag_version __attribute__((section(".version"))) =3D
> {VERSION_CMD, CPU_NUMBER, VER_MAJOR, VER_MINOR, VER_UPDATE};
> const revision_t vn_revision __attribute__((section(".version"))) =3D
> {REVISION_CMD, SVN_REV, SVN_STATUS};
> const author_t author __attribute__((section(".version"))) =3D
> {AUTHOR_CMD, AUTHOR_ID, 0};
>
> Now the file is accepted by tuxup and I could flash the tux but then i=
ts
> behaviour is not correct so there are still other problems and my file=
> is still 20077-byte large instead of 20550.
>
> Someone has some suggestions?
Hi Philippe,
The original firmware was still done with winavr 2006 which uses GCC 3.4=
.6 =
iirc. I didn't want to move to a new version at the end of development.
I now completely moved to linux but didn't work much on the firmware sin=
ce =
then. I once compiled the firmware under Linux with GCC4.1 and that work=
ed =
fine. That's normal that the file sizes don't match as you probably didn=
't =
use the same version as me.
If you recompile the firmware, you have to upload both hex and eep files=
=
otherwise the standalone behavior looks very strange. Different versions=
=
of GCC will reorganize data differently.
And that's also probably the reason why you had that such problems with =
=
the version structure of your hex file.
At 0x1DF0 (just before the bootloader) I placed 3 structures to get the =
=
version number (which also includes the CPU number), the revision number=
=
and an ID for the author. I use the CPU number and version number to =
validate the hex file in tuxup and know which CPU to reprogram.
GCC is free to organize data inside structures in any way so setting the=
=
order manually like I did is not the correct way to go but I didn't find=
=
better. It seems here GCC reordered the 3 strcutures sequence in the =
.version section and also the byte order inside the structures and also =
=
the bit order inside bitfields.
If it works for you like this, it's fine for now but we'll have to find =
=
the solution for this soon.
btw, glad to see someone is interested in the firmware :-)
david
|
|
From: David B. <da...@ja...> - 2007-03-18 14:29:27
|
On Sat, 17 Mar 2007 14:46:16 +0100, Kiffin Gish <kif...@pl...> wrote: > Is there a Tux bug-tracking system somewhere in order to report bugs > found while installing etc? > Sure, you'll find links in the developer corner. If you go the the daemon project, there's a 'Issue tracker' link. The python API also has one. If you have problems with the firmware or hardware, use the issue tracker of the firmware. If that's a bug in a small python application, I though an issue tracker was a bit overkill for each app so use contact address instead. Direct links: daemon http://www.tuxisalive.com/issue-trackers/tux-daemon/ firmware/harware http://www.tuxisalive.com/issue-trackers/firmware API http://www.tuxisalive.com/issue-trackers/api bootloader http://www.tuxisalive.com/issue-trackers/tuxup david |
|
From: Philippe T. <ph...@te...> - 2007-03-18 11:30:37
|
> Original firmware:
> :0C1DF000C8000300C9D10100CA000000B7^
> => version command = C8, version = 0.3.0
>
> My firmware:
> :0C1DF000CA000000C9640000C800030025^
> => version command = CA, version = 0.0.0 ??
>
Actually apparently the order of version, revision and author fields was
wrong
I tried to change global.c to reorder them:
const version_t tag_version __attribute__((section(".version"))) =
{VERSION_CMD, CPU_NUMBER, VER_MAJOR, VER_MINOR, VER_UPDATE};
const revision_t svn_revision __attribute__((section(".version"))) =
{REVISION_CMD, SVN_REV, SVN_STATUS};
const author_t author __attribute__((section(".version"))) =
{AUTHOR_CMD, AUTHOR_ID, 0};
Now the file is accepted by tuxup and I could flash the tux but then its
behaviour is not correct so there are still other problems and my file
is still 20077-byte large instead of 20550.
Someone has some suggestions?
Phil
|
|
From: Philippe T. <ph...@te...> - 2007-03-18 10:50:54
|
> $ tuxup tuxcore.hex > [FAIL] Programming of 'tuxcore.hex' failed, this file is not a correct > hex file for that CPU > I looked at check_hex_file in tuxup, here are the interesting bits of my invalid firmware: Original firmware: :0C1DF000C8000300C9D10100CA000000B7^ => version command = C8, version = 0.3.0 My firmware: :0C1DF000CA000000C9640000C800030025^ => version command = CA, version = 0.0.0 ?? |
|
From: Philippe T. <ph...@te...> - 2007-03-18 10:18:09
|
Hello, I tried to setup the toolchain to recompile the firmware but tuxup tells me the hex file has a wrong format. I'm using Debian Etch apt-get install gcc-avr avr-libc gdb-avr libsvn-dev Edit svncrev-0.1/config.mk: APR_INCLUDE=/usr/include/apr-1.0 Make svncrev and cp to /usr/local/bin Then on tuxcore: $ make clean rm -rf main.o sensors.o motors.o global.o led.o communication.o i2c.o fifo.o ir.o parser.o config.o standalone.o svnrev.h tuxcore.elf dep/* tuxcore.hex tuxcore.eep tuxcore.lss tuxcore.map bootloader.o tuxcore_bl.hex tuxcore_bl.lss tuxcore_bl.map tuxcore_bl.elf svnrev.h dep $ make svnwcrev . svnrev.tmpl.h svnrev.h Last committed at revision 100 Updated to revision 175 avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT main.o -MF dep/main.o.d -c main.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT sensors.o -MF dep/sensors.o.d -c sensors.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT motors.o -MF dep/motors.o.d -c motors.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT global.o -MF dep/global.o.d -c global.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT led.o -MF dep/led.o.d -c led.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT communication.o -MF dep/communication.o.d -c communication.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT i2c.o -MF dep/i2c.o.d -c i2c.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT fifo.o -MF dep/fifo.o.d -c fifo.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT ir.o -MF dep/ir.o.d -c ir.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT parser.o -MF dep/parser.o.d -c parser.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT config.o -MF dep/config.o.d -c config.c avr-gcc -mmcu=atmega88 -g -DF_CPU=8000000UL -Os -Wall -Wstrict-prototypes -std=gnu99 -MD -MP -MT standalone.o -MF dep/standalone.o.d -c standalone.c avr-gcc -mmcu=atmega88 -Wl,--section-start=.version=0x1DF0 -Wl,-Map=tuxcore.map main.o sensors.o motors.o global.o led.o communication.o i2c.o fifo.o ir.o parser.o config.o standalone.o -o tuxcore.elf avr-objcopy -O ihex -R .eeprom tuxcore.elf tuxcore.hex avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex tuxcore.elf tuxcore.eep avr-objdump -h -S tuxcore.elf > tuxcore.lss text data bss dec hex filename 7022 280 164 7466 1d2a tuxcore.elf $ tuxup tuxcore.hex [FAIL] Programming of 'tuxcore.hex' failed, this file is not a correct hex file for that CPU Time elapsed: 0 seconds. I did not modify the firmware sources but tuxcore.hex I compiled is only 20027 bytes while the one in firmware/hex is 20550 Note that the 20550-byte tuxcore.hex is accepted by tuxup so the problem is really when compiling it from sources. Any idea what's going wrong here? Phil |
|
From: Kiffin G. <kif...@pl...> - 2007-03-17 13:46:21
|
Is there a Tux bug-tracking system somewhere in order to report bugs found while installing etc? -- Kiffin Gish <kif...@pl...> |
|
From: Srikanta P. <sri...@gm...> - 2007-03-16 10:06:18
|
On 3/16/07, David Bourgeois <da...@ja...> wrote: > > On Fri, 16 Mar 2007 10:41:11 +0100, Srikanta Prasanna > <sri...@gm...> wrote: > > > anywhere which points to the sourceforge archive. So, maybe, thats why > it > > has > > not yet been archived by google? > > There are links there, but I have no idea if they're the correct links: > http://www.tuxisalive.com/getting-started > > Can use this for gmane: http://www.google.com/addurl/ But I'm not sure how effective it is. Neither is Google ;-) |
|
From: David B. <da...@ja...> - 2007-03-16 09:53:41
|
On Fri, 16 Mar 2007 10:41:11 +0100, Srikanta Prasanna <sri...@gm...> wrote: > Correct me if I'm wrong. Google (or any search engine) needs a starting > point/link, > which links to the webpage which we want to be crawled. As I see, there > is > no link > anywhere which points to the sourceforge archive. So, maybe, thats why it > has > not yet been archived by google? There are links there, but I have no idea if they're the correct links: http://www.tuxisalive.com/getting-started |
|
From: Srikanta P. <sri...@gm...> - 2007-03-16 09:41:12
|
On 3/16/07, David Bourgeois <da...@ja...> wrote: > > On Fri, 16 Mar 2007 09:54:41 +0100, Srikanta Prasanna > <sri...@gm...> wrote: > > > On 3/16/07, Olivier Grisel <oli...@en...> wrote: > >> > >> Henrik Grindal Bakken a =E9crit : > >> > Hi. I was just wondering if it would be possible to get gmane > >> > (http://www.gmane.org/) to carry this list. For those of you not > >> > familiar with gmane, it's a mail-to-news (and back again) > gateway. It > >> > makes it possible to read mailing lists with a news reader. > >> > > >> > I can contact gmane to get them to carry the list if there are no > >> > objections. > >> > >> +1 > >> > > > > Same here. > > And I observed that Tuxdroid SF archive is not yet crawled by google > (?). > > Do we need to do something for google? > Correct me if I'm wrong. Google (or any search engine) needs a starting point/link, which links to the webpage which we want to be crawled. As I see, there is no link anywhere which points to the sourceforge archive. So, maybe, thats why it has not yet been archived by google? |
|
From: David B. <da...@ja...> - 2007-03-16 09:36:50
|
On Fri, 16 Mar 2007 09:54:41 +0100, Srikanta Prasanna <sri...@gm...> wrote: > On 3/16/07, Olivier Grisel <oli...@en...> wrote: >> >> Henrik Grindal Bakken a écrit : >> > Hi. I was just wondering if it would be possible to get gmane >> > (http://www.gmane.org/) to carry this list. For those of you not >> > familiar with gmane, it's a mail-to-news (and back again) gateway. It >> > makes it possible to read mailing lists with a news reader. >> > >> > I can contact gmane to get them to carry the list if there are no >> > objections. >> >> +1 >> > > Same here. > And I observed that Tuxdroid SF archive is not yet crawled by google (?). +1 :-) I always use gmane whenever it's possible. I looked at this one year ago but was not sure the ML will stay at the same place. Now that it is fixed, that's a good idea to suscribe it. I just subscribed it, waiting for the confirmation now. I'll then ask them to import the archives. Do we need to do something for google? |
|
From: Srikanta P. <sri...@gm...> - 2007-03-16 08:54:42
|
On 3/16/07, Olivier Grisel <oli...@en...> wrote: > > Henrik Grindal Bakken a =E9crit : > > Hi. I was just wondering if it would be possible to get gmane > > (http://www.gmane.org/) to carry this list. For those of you not > > familiar with gmane, it's a mail-to-news (and back again) gateway. It > > makes it possible to read mailing lists with a news reader. > > > > I can contact gmane to get them to carry the list if there are no > > objections. > > +1 > Same here. And I observed that Tuxdroid SF archive is not yet crawled by google (?). |
|
From: Olivier G. <oli...@en...> - 2007-03-16 07:59:42
|
Henrik Grindal Bakken a écrit : > Hi. I was just wondering if it would be possible to get gmane > (http://www.gmane.org/) to carry this list. For those of you not > familiar with gmane, it's a mail-to-news (and back again) gateway. It > makes it possible to read mailing lists with a news reader. > > I can contact gmane to get them to carry the list if there are no > objections. +1 -- Olivier |
|
From: Henrik G. B. <hg...@if...> - 2007-03-16 07:23:19
|
Hi. I was just wondering if it would be possible to get gmane (http://www.gmane.org/) to carry this list. For those of you not familiar with gmane, it's a mail-to-news (and back again) gateway. It makes it possible to read mailing lists with a news reader. I can contact gmane to get them to carry the list if there are no objections. -- Henrik Grindal Bakken <hg...@if...> PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 |
|
From: David B. <da...@ja...> - 2007-03-16 06:54:08
|
Strangely the 2 emails I sent 3 or 2 days ago didn't reach the mailing list. I resent them from home just now and they appeared immediately. Srikanta told me it may come from sourceforge, I'll see how it goes in the future. If you experience such things, drop me a mail privatey. Thanks |
1 message has been excluded from this view by a project administrator.
