freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

On Samstag, 11. November 2017 11:02:54 CET Thorsten Otto wrote:
> I think i have to find out what really gets written to the disk there

Ok, did that now. Created a plain FAT image (with mkdosfs), and mounted that 
with -t msdos to /mnt. Result:

$ touch -d "2017-07-15 13:00:00" /mnt/bla
$ ls -l --full-time /mnt/bla
-rwxr-xr-x 1 root root 0 2017-07-15 13:00:00.000000000 +0200 /mnt/bla

$ touch -d "2017-11-05 13:00:00" /mnt/bla 
$ ls -l --full-time /mnt/bla
-rwxr-xr-x 1 root root 0 2017-11-05 13:00:00.000000000 +0100 /mnt/bla

(+0200 was the daylight saving time in effect in July here, +0100 is the
 current timezone offset).

On disk, i get:

00005800: 42 4C 41 20  20 20 20 20  20 20 20 20  00 00 00 00   "BLA 
        ...." 
00005810: 00 00 00 00  00 00 00 60  EF 4A 00 00  00 00 00 00 
  ".......`.J......"

for the first, which is 2017-07-15 12:00:00 when i convert the stamp without 
applying any offset, and

00005800: 42 4C 41 20  20 20 20 20  20 20 20 20  00 00 00 00   "BLA 
        ...." 
00005810: 00 00 00 00  00 00 00 68  65 4B 00 00  00 00 00 00 
  ".......heK......"


for the 2nd, which is 2017-11-05 13:00:00. So it seems linux has the same 
problems, the stamp for the first file (on disk) is off by 1 hour. What 
happens is that:

- touch converts the time i specified to an UTC time, subtracting the offset 
of +0200 that was in effect at that time.
- the kernel adds the current time offset before writing the stamp, because 
for FAT a local time should be stored.

Not very pleasing. That means, if i wait half a year, and daylight savings 
time is in effect again, ls -l will suddenly report a different time.

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

On Samstag, 11. November 2017 10:21:12 CET Helmut Karlowski wrote:

>So if you send the image to someone in China he will see your local times,  
>but for a TOS-FS there might be no other way.

Yes, that's just the design flaw of FAT filesystem to store local times.
The linux kernel has a workaround for this, by allowing to specify a specific 
timezone offset for FAT to use, rather than the current one. Strangly, beside 
this extra option, it otherwise seems to behave the same, just adding/
subtracting that offset. I still have to figure out why it obviously works 
there, maybe glibc does some magic i havn't found yet. Or the kernel is just 
lying. I think i have to find out what really gets written to the disk there.

> That would mean that MiNT always tries to returns local time?

That depends on the function call, and thats the problem. The ability to 
return UTC timestamps was added later (maybe in version 1.15.4, when Fstat64() 
was implemented). By returning UTC times, the burden to convert that to a 
local time is left to the application, which (by using mintlib) has no problem 
with that. Unfortunately, there where already existing interfaces that are 
expected to return a local time. That includes Fxattr (with was previously 
used to implement the stat() function in mintlib), and Dxreaddir, which 
returns the same structure. Dxreaddir has no direct counterpart in mintlib, 
but some applications (most likely desktops), still use it to avoid a separate 
stat() call for every file to display (although that shouldn't make much 
difference, since the kernel internally does the same, you only save the extra 
roundtrip to gemdos).

>So it should be like this:
>TOS-FS: file-times are local-time
>Others: file-times are utc.

Yes, but even for filesystems that already implement it (i think all but TOS-
FS), there are calls that convert to/from local time (like fcntl(FUTIME)). 
Also a plain Fdatime() call is interpreted as specifying a local time.

Re: [Freemint-discuss] Mint handling of file timestamps

[Helmut K. <hel...@is...>]

Am 11.11.2017, 09:21 Uhr, schrieb Helmut Karlowski:

> I see on getstat64,xfs_xdd.c:
>
>      /* no native UTC extension
>       * -> convert to unix UTC
>       */
>      stat->atime.high_time = 0;
>      stat->atime.time = unixtime (xattr.atime, xattr.adate) + timezone;
>      stat->atime.nanoseconds = 0;
>
> That would mean that MiNT always tries to returns local time? And  
> timezone is a constant not taking account of the time-offset of the  
> actual time?

Actually the other way: It tries to convert the local time from the file  
to utc, but it's still not right. At least for Non-TOS-FS it should not  
change anything.

--

Re: [Freemint-discuss] Mint handling of file timestamps

[Helmut K. <hel...@is...>]

Am 10.11.2017, 03:58 Uhr, schrieb Thorsten Otto:

>> Shall the file-time be stored in utc or local time on disk?
>
> Since it is a plain tos/msdos filesystem (no vfat), it can only be  
> stored in
> local time.

So if you send the image to someone in China he will see your local times,  
but for a TOS-FS there might be no other way.

>
> I think the only possible solution is to add some flag to Dopendir, to  
> tell
> Dxreaddir that it should return the timestamps as UTC so the application  
> can
> do the calculation. Of course, that would also require changes to the
> applications using it directly (like teradesk), and mintlib for all  
> others.
> For other cases, like stat() and Fdatime(), there are already  
> alternatives
> that should work, like Fstat64() and fcntl(FUTIME_UTC).

Yes, store the times in UTC. Maybe mintlib can set a flag to tell the  
kernel about it's preference, and old apps would still work as before.

As far as I see, tools like ls expect utc and call localtime to get the  
tm-content in local-time representation.

So it should be like this:

TOS-FS: file-times are local-time
Others: file-times are utc.

I see on getstat64,xfs_xdd.c:

     /* no native UTC extension
      * -> convert to unix UTC
      */
     stat->atime.high_time = 0;
     stat->atime.time = unixtime (xattr.atime, xattr.adate) + timezone;
     stat->atime.nanoseconds = 0;

That would mean that MiNT always tries to returns local time? And timezone  
is a constant not taking account of the time-offset of the actual time?

Re: [Freemint-discuss] Yet another approach to compiling Atari binaries using gcc

[Matthias A. <ma...@as...>]

Am Thu, 9 Nov 2017 17:27:41 +0100
schrieb Matthias Arndt <ma...@as...>:

> Am Thu, 09 Nov 2017 10:34:28 +0100
> schrieb Thorsten Otto <ad...@th...>:
> 
> 
> > 
> > PS2.: is that simonsunnyboy from the forum?  
> 
> No, it's not me. I am using mfro's work on using the existing gcc
> without the Mintlib, esp. his startup code as base and linker flags.

For completeness of the record, my starting point some years back back
then was this:

http://forum.atari-home.de/index.php?topic=10475.0

A lot of my subsequent work is on GitHub:

https://github.com/simonsunnyboy/stlibs4gcc

This includes a lot of former GFABASIC accessible INLINEs and AHCC
stuff ported for GCC use.

It is mainly of interest for game and demo coding, not for clean
applications.

Regards,
Matthias

-- 
http://final-memory.org/

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

On Donnerstag, 9. November 2017 22:57:41 CET Helmut Karlowski via Freemint-
discuss wrote:
> That is the same symptom that can be observed when accessing files on
> host-fs.

Not really. The image is a tos filesystem, so the hostfs is not involved at 
all. You will see that from the flags, FS_EXT_3 is not set there (unfortunately 
the xfs name is not easily accessible there).

>Shall the file-time be stored in utc or local time on disk?

Since it is a plain tos/msdos filesystem (no vfat), it can only be stored in 
local time.

I think the only possible solution is to add some flag to Dopendir, to tell 
Dxreaddir that it should return the timestamps as UTC so the application can 
do the calculation. Of course, that would also require changes to the 
applications using it directly (like teradesk), and mintlib for all others. 
For other cases, like stat() and Fdatime(), there are already alternatives 
that should work, like Fstat64() and fcntl(FUTIME_UTC). 

Re: [Freemint-discuss] Mint handling of file timestamps

[Helmut K. <hel...@is...>]

Am 09.11.2017, 21:38 Uhr, schrieb Thorsten Otto:

> On Mittwoch, 8. November 2017 23:52:09 CET Helmut Karlowski via Freemint-
> discuss wrote:
>> Do you have a testcase that demonstrates the problem without any
>> aranym-interaction?
>
> Although also running under Aranym, i just did a test with a freshly  
> created
> tos filesystem image, so the hostfs is not involved here. By inserting  
> debug
> printfs, i get following output from what is returned by Dxreaddir:
>
> pid  13 (desktop): getxattr 67E: 2017/06/04 13:23:30
> pid  13 (desktop): getxattr 67E: 2017/11/08 05:12:30
>
> The 67E are the filesystem flags. The same two files, mounted on linux:
>
> $ ls -l /mnt
>
> -rwxr-xr-x 1 root root 37146  4. Jun 14:23 emucicn.rsc
> -rwxr-xr-x 1 root root  1209  8. Nov 05:12 newdesk.inf

That is the same symptom that can be observed when accessing files on  
host-fs.

> So something is definitely wrong there.

Shall the file-time be stored in utc or local time on disk?

--

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

On Mittwoch, 8. November 2017 23:52:09 CET Helmut Karlowski via Freemint-
discuss wrote:
> Do you have a testcase that demonstrates the problem without any
> aranym-interaction?

Although also running under Aranym, i just did a test with a freshly created 
tos filesystem image, so the hostfs is not involved here. By inserting debug 
printfs, i get following output from what is returned by Dxreaddir:

pid  13 (desktop): getxattr 67E: 2017/06/04 13:23:30 
pid  13 (desktop): getxattr 67E: 2017/11/08 05:12:30

The 67E are the filesystem flags. The same two files, mounted on linux:

$ ls -l /mnt

-rwxr-xr-x 1 root root 37146  4. Jun 14:23 emucicn.rsc 
-rwxr-xr-x 1 root root  1209  8. Nov 05:12 newdesk.inf

So something is definitely wrong there.

Re: [Freemint-discuss] Yet another approach to compiling Atari binaries using gcc

[Matthias A. <ma...@as...>]

Am Thu, 09 Nov 2017 10:34:28 +0100
schrieb Thorsten Otto <ad...@th...>:


> 
> PS2.: is that simonsunnyboy from the forum?

No, it's not me. I am using mfro's work on using the existing gcc
without the Mintlib, esp. his startup code as base and linker flags.

Regards,
Matthias

-- 
http://final-memory.org/

Re: [Freemint-discuss] Yet another approach to compiling Atari binaries using gcc

[Vincent R. <vin...@fr...>]

On 09/11/2017 at 09:54, Miro Kropáček wrote:
> thanks to user Simon Krix, known as Smonson on AF/Exxos forum I have
> discovered his project and using plain ELF m68k gcc for producing Atari
> binaries: https://github.com/smonson78/ataricc/blob/master/Makefile

Good to see such alternatives.
This really helps to better understand potential GCC solutions.

-- 
Vincent Rivière

Re: [Freemint-discuss] Yet another approach to compiling Atari binaries using gcc

[Thorsten O. <ad...@th...>]

On Donnerstag, 9. November 2017 09:54:11 CET Miro Kropáček wrote:
> Basically he takes plain m68k gcc, compiles everything and links using a
> special ld script and then just converts into an atari binary using vlink.

Thats a bit simpler than the browngcc attempt, but still needs an additional 
step in linking. And you still need libraries compiled for this target.

Also, if you look at the flags (-ffreestanding, -fno-rtti etc.) that means gcc 
does not do any optimizations to builtin function, you can't compile most c++ 
programs and similar quirks. I think he will get the same problems as me with 
global constructors for example: the elf compiler will not generate a call to 
___main(), so they don't get executed. And if i understand it right, he is 
using the libc from vbcc, which is good enough for most tos programs, but 
certainly not for gnu packages (or is he using his own version? not sure)

The main purpose why i attempted on building my port was to be able to just do 
a "./configure target=m68k-atari-mintelf; make; make install". And if you look 
at the scripts, this is actually almost everything that is done there. The 
only hassle is to build the different libraries for different cpus.

>One can produce lto'ed binaries, too.

Yes, thats the point, building them. Having to write the scripts is one thing, 
but having to patch all configure scripts of the packages to get them compiled 
with an unknown target, and adding special flags, and additional steps to 
produce binaries (lots of libraries like iconv, bzip etc also build 
executables), is another.

PS.: oh i just saw, he is using his own version of crt startup, executing the 
constructors manually.

PS2.: is that simonsunnyboy from the forum?

[Freemint-discuss] Yet another approach to compiling Atari binaries using gcc

[Miro K. <mir...@gm...>]

Hi,

thanks to user Simon Krix, known as Smonson on AF/Exxos forum I have
discovered his project and using plain ELF m68k gcc for producing Atari
binaries: https://github.com/smonson78/ataricc/blob/master/Makefile

Basically he takes plain m68k gcc, compiles everything and links using a
special ld script and then just converts into an atari binary using vlink.

So it's something like The Brown Guys used, just simpler and more
straightforward. One can produce lto'ed binaries, too.

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

On Mittwoch, 8. November 2017 23:52:09 CET Helmut Karlowski via Freemint-
discuss wrote:

>Do you have a testcase that demonstrates the problem without any  
>aranym-interaction?

No, unfortunately not, i don't have any real hardware anymore. 

Its a bit difficult to follow what happens, but i think the problem should be 
clear. When using functions like Fdatime() to modify the filetime, and that 
time has to be converted to UTC, mint uses only the global timezone variable, 
which is only valid for the current local time. It does not try to compute the 
timezone offset that was in effect at the time that should be set. Hence the 
UTC time written to disk is *not* correct.

I think that should be visible when copying files from fat to ext2fs, having 
times that are from a different timezone offset than the current, like in my 
example. Then use "ls -l" in the console to view their modification times. 
Don't use teradesk or some desktop for this; if it is using Dxreaddir() it 
will report the correct time, but only because the same offset is just applied 
again. ls from the coreutils however should be able to calculate the timezone 
offset of the time, using the tz package from mintlib. Compare that time to 
the modification time of the original file.

Re: [Freemint-discuss] Mint handling of file timestamps

[Helmut K. <hel...@is...>]

Am 08.11.2017, 04:19 Uhr, schrieb Thorsten Otto:

> - If you think thats a bug in Teradesk, or Aranym: thats not quite true
> either. That inconsistency will also occur when using only ext2fs  
> filesystems.

On an ext2-fs inside MiNT (no host-fs, only ext2) the times of files  
created in summertime are correct. At least if the program is using  
mintlib (TZ=Europe/Berlin).

I only observe discrepancies between host-fs-file-time and MiNT-file-time  
- for example st_mtime differs, using the ancient version of mintlib I use  
with pure-c. I once tried to fix it in hostfs.cpp in my private  
aranym-version (something with tm_gmtoff) but that is still not 100% it  
seems.

> The problem here is that functions like Fstat64() report UTC timestamps  
> (if
> the filesystem supports it, but most do, except tosfs), while eg.  
> Dxreaddir()
> returns the extended information in the old xattr structure, where the
> timestamps are converted to local time, using the global timezone  
> variable.

Do you have a testcase that demonstrates the problem without any  
aranym-interaction?

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

Some 2 more notes on this:

- if you think you can fix this by calling tzinit with --localtime, or --utc, 
you are wrong: that only affects functions like Tgetdate() and 
Tgettimeofday(). Same for the gmtime config setting in Aranym.

- If you think thats a bug in Teradesk, or Aranym: thats not quite true 
either. That inconsistency will also occur when using only ext2fs filesystems. 
The problem here is that functions like Fstat64() report UTC timestamps (if 
the filesystem supports it, but most do, except tosfs), while eg. Dxreaddir() 
returns the extended information in the old xattr structure, where the 
timestamps are converted to local time, using the global timezone variable.

Re: [Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

To illustrate the issue:



The upper half shows 2 files in teradesk, the lower the same 2 files on the 
host. etos512k.img was created a few days ago, when we had summer time here in 
germany, and mint was running with a timezone offset of -7200. The other file i 
just touched, with summertime being over, and mint now running with a timezone 
offset of -3600. The 2nd file has the correct time, but etos512k.img is off by 
one hour.

[Freemint-discuss] Mint handling of file timestamps

[Thorsten O. <ad...@th...>]

Hi,

when tracking down what occurs to me as a bug in aranym's implementation of 
the hostfs, it turned out be a general problem in mint.

When setting/retrieving timestamps (either through Fstat64(), or Fdatime(), or 
some Fcntl(FUTIME)), at certain places the kernel timezone variable is added/
subtracted. That is totally nonsense of course, that timezone offset is only 
valid for the current local time, but not for some arbitrary time in the past. 
if works when used on just created files, but not eg. when copying files from a 
TOS partition (which is expected to use local doslike timestamps) to an 
extf2fs filesystem, or in my case to the hostfs which behaves the same in this 
manner (it has the FS_EXT_3 flag set, and uses UTC timestamps).

To fix this, Mint must be able to compute the timezone offset for some given 
local time, which basically means implementing most of the tz package as 
already used by eg. mintlib. Main problem with this is that it relies on some 
database which is stored on a filesystem... Not only that this leads to an 
chicken/egg problem, but it would also make calculating the correct offset 
awfully slow. Any ideas how to solve this?

Re: [Freemint-discuss] [MiNT] binutils-2.23.2 and gcc-4.6.4

[Thorsten O. <ad...@th...>]

On Montag, 6. November 2017 00:11:12 CET Miro Kropáček wrote:
> That's precisely the problem -- they should be but aren't.
 
Seems to be an assembler problem. When i compile a simple test program here 
with the native gcc, i get:
~ $ nm bla.o         
                U do_nothing 
0000000000000034 T main 
0000000000000000 T test 
0000000000000000 b x

When i compile the same program with the cross-compiler, i get:
$ m68k-atari-mint-nm bla.o         
00000014 t .L2 
0000000a t .L3 
0000000a t .LBB2 
00000010 t .LBE2 
00000000 t .LFBB1 
00000024 t .LFBB2 
00000024 t .Lscope1 
00000032 t .Lscope2 
00000000 t .Ltext0 
        U ___main 
        U _do_nothing 
00000024 T _main 
00000000 T _test 
00000034 b _x

So the native assembler seems to already omit those symbols from the object 
file. And m68k-atari-mint-strip does indeed not remove them (also not the one 
from binutils-2.29). So both seems to need fixing.
 
>Formerly I used '-x' instead of it and that was stripping too much.
 
Yes, that  will strip all local symbols, even the ones from static functions. 
Although i think the Hatari debugger can not cope very well with those, at 
least i get lots of warnings when the same static name is used in more than 
one place.
 

Re: [Freemint-discuss] [MiNT] binutils-2.23.2 and gcc-4.6.4

[Miro K. <mir...@gm...>]

>
> The ".L[0-9]" are compiler generated local symbols. Aren't these already
> been
> supposed to be stripped by -X?
>
That's precisely the problem -- they should be but aren't. Formerly I used
'-x' instead of it and that was stripping too much.


-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] [MiNT] binutils-2.23.2 and gcc-4.6.4

[Thorsten O. <ad...@th...>]

On Sonntag, 5. November 2017 23:52:46 CET Miro Kropáček wrote:
> > Eero's proposal ("-s" for executables, "-S -X -w -N '.L[0-9]*'" for

The ".L[0-9]" are compiler generated local symbols. Aren't these already been 
supposed to be stripped by -X?

Re: [Freemint-discuss] [MiNT] binutils-2.23.2 and gcc-4.6.4

[Miro K. <mir...@gm...>]

On 14 October 2013 at 11:47, Miro Kropáček <mir...@gm...> wrote:

>
> On Thu, Apr 18, 2013 at 7:43 PM, Eero Tamminen <oa...@he...> wrote:
>
>> > Globally, stripping saved many megabytes.
>>
>> I'm not interested in the ".L*" symbols as those have
>> no names, just numbers.  But anything that has a name for
>> a function, I would very much like to be retained in
>> the library symbol table.
>>
>> Maybe you could use the following strip arguments:
>>         -S -X -w -N '.L[0-9]*'
>> ?
>
>
> Inspired by an Atari-forum thread, I have done proper testing this time.
> Results are more than surprising. My tests were done on the complete
> gcc+binutils+mintlib+pml cross compilation installation (self made):
>
> Plain install (no stripping at all): 148 MB
> My strip ("-s" for executables, "-S -x" for libraries): 63 MB
> Eero's proposal ("-s" for executables, "-S -X -w -N '.L[0-9]*'" for
> libraries): *58 MB*
>
> Yes, with static functions like "tzload" included and still working
> (simple hello world tested). So it seems that actually Eero's "script" not
> only keeps static function names but also saves space =)
>

It took only four years and Eero's comment on AF but I have finally changed
this. So now all mintlib/gemlib/cflib/gemma builds contain static symbols,
using the command line switches above.

Vincent, if you find some time, I suggest to change the switches in your
builds as well.

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

[Freemint-discuss] Old mailing list archives

[Miro K. <mir...@gm...>]

Don't worry, nothing will be lost even if atariforge.org goes down
forever. On my ML page: https://mikro.naprvyraz.sk/mint/index.html I
have archived also the atariforge.org one (can be found at the bottom,
https://mikro.naprvyraz.sk/mint/freemint-list/index.html)

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

[Freemint-discuss] Outstanding PRs

[Miro K. <mir...@gm...>]

Hi,

I went trough all the projects to see how much stuff is still pending (or
maybe even forgotten due to unreliability of the old ML).

tos.hyp:
https://github.com/freemint/tos.hyp/pull/78 ... this is more a generic
question as Gerhard had troubles to use the old ML + he isn't easy to reach
so we still don't know whether he wants to maintain tos.hyp or not.
Thorsten has tons of changes to be applied but I don't know how to proceed
here. Remove the tos.hyp project and leave it to Gerhard to decide, create
a fork/rename, apply Thorsten's patches and see what happens, ... ?

m68k-atari-mint-gcc:
https://github.com/freemint/m68k-atari-mint-gcc/pull/2 ... a small patch
for native gcc 4.6.4

mintbin:
https://github.com/freemint/mintbin/pull/1 ... I think safe to commit

(cf)lib:
https://github.com/freemint/lib/pull/1 ... I think safe to commit
https://github.com/freemint/lib/pull/2 ... needs cleanup (different things
mixed together, mainly the register prefix)
https://github.com/freemint/lib/pull/3 ... ditto
https://github.com/freemint/lib/pull/4 ... ditto

mintlib:
https://github.com/freemint/mintlib/pull/17 ... I think safe to commit
https://github.com/freemint/mintlib/pull/20 ... register prefix (% vs
motorola syntax), to be decided
https://github.com/freemint/mintlib/pull/24 ... I think safe to commit
https://github.com/freemint/mintlib/pull/25 ... I think safe to commit
https://github.com/freemint/mintlib/pull/26 ... would be nice to split into
two PRs but otherwise OK

freemint:
https://github.com/freemint/freemint/pull/72 ... needs cleanup, too much
stuff for one PR (esp. the register prefixes)
https://github.com/freemint/freemint/pull/74 ... I think safe to commit

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] Fwd: Retrocomputing devroom at FOSDEM 2018

[François R. <re...@fr...>]

Le 31/10/2017 à 13:07, François Revol a écrit :
> Hi,
> anyone for a MiNT talk?
> 
> François.
> (I'm not subscribed)


Btw, the call for stands is still open until november 4th:
https://fosdem.org/2018/news/2017-09-03-call-for-participation/


Could be nice to have a common stand with AROS for example, to show
you're still around.


(I'm from the Haiku project, last year we shared a table with ReactOS.)

François.

[Freemint-discuss] Fwd: Retrocomputing devroom at FOSDEM 2018

[François R. <re...@fr...>]

Hi,
anyone for a MiNT talk?

François.
(I'm not subscribed)


-------- Message transféré --------
Sujet : Retrocomputing devroom at FOSDEM 2018
Date : Tue, 31 Oct 2017 00:27:35 +0100
De : François Revol <re...@fr...>
Pour : ar...@go...

Hi,
I just found out someone managed to get a retrocomputing devroom
accepted at FOSDEM:

https://lists.fosdem.org/pipermail/retrocomputing-devroom/2017-October/000000.html

https://www.elpauer.org/2017/10/retrocomputing-devroom-call-for-participation/comment-page-1/

Who's going to propose a talk about ARAnyM???

François.