freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] Bintray integration / git force-push needed

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

On 24 February 2018 at 11:27, Thorsten Otto <ad...@th...> wrote:


> >git history has to be totally rewritten, so if you have a branch/fork of
> your
> >own, you have to do a hard reset + rebase/cherry-pick
>
> I wouldn't do that if it can be avoided.

I wouldn't if it could be avoid as well. :) The biggest pain is that now
the repo contains EmuTOS, TeraDesk, fVDI etc. So it prolongs git clone for
everybody and serves no purpose.

All these forks will be affected by this, too, and of course every repo
> that someone has cloned locally. That will be at least as much work that
> you did, for everybody who is affected, maybe even worse
>
Actually, it's not that bad. One just has to fetch from the upstream
origin, reset his local master (or any other branch) to upstream and force
push to his own github repository. That will make the fork in sync again.
The only issue is dev branches, i.e. one has to manually go branch by
branch and rebase/cherry-pick on the top of the new commit ID.

I'm of course prepared to offer advice/assistance -- trust me, I'm no git
expert at all and I could manage quite easily. One just has to be careful
to push to the right remote. ;-)


> >otherwise I'll do the git force-push sometime on Sunday.
>
> I would wait a few days more. SF still seems to have problems with their
> mailing lists, maybe the complaints just don't make it to the list.
>
Fair enough, there's no rush.

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

Re: [Freemint-discuss] Bintray integration / git force-push needed

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

On Freitag, 23. Februar 2018 23:45:02 CET Miro Kropáček wrote:
> no more abusing of https://github.com/freemint/travis-pr and
> https://github.com/freemint/freemint.github.io

That was absolutely necessary, especially for freemint.github.io where the 
snapshots are pushed to, and which has already grown to more than 600MB when 
you clone it. The *.io areas are limited to 1GB IIRC.

> The final burst of motivation was adding Bintray support to Travis

Oh. I didn't notice yet.

>The final burst of motivation was adding Bintray support to Travis, so  
>instead of this dark magic (hats off, Thorsten!) I could do just this.

It was still a good experience ;) And it's still a bit more flexible, since  
the same script can be used for snapshots and releases. Also, it looks that 
this kind of REST API that bintray uses is quite common, so it can easily be 
adapted for other providers or tasks.

>git history has to be totally rewritten, so if you have a branch/fork of your 
>own, you have to do a hard reset + rebase/cherry-pick

I wouldn't do that if it can be avoided. Might be a bit annoying to have the 
Travis commits in the log, but better than resetting it to a completely new 
repo. If you look at the link at the top, you will see that is has already 
been forked 9 times. All these forks will be affected by this, too, and of 
course every repo that someone has cloned locally. That will be at least as 
much work that you did, for everybody who is affected, maybe even worse (eg. i 
will have to clean up at least 2 repos, the cloned originally freemint repo, 
and the clone of my fork). And not everybody might know what he is doing there 
(remember my first attempts with the PRs  *cough*). Also, to be honest, i 
rather spend my time  with developing than with managing the repos.

>otherwise I'll do the git force-push sometime on Sunday.

I would wait a few days more. SF still seems to have problems with their 
mailing lists, maybe the complaints just don't make it to the list.

[Freemint-discuss] Bintray integration / git force-push needed

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

Hi guys,

I had a few free afternoons so I finally looked into
https://github.com/freemint/freemint/issues/79. Encouraged by Vincent's and
Thorsten's deployment experiments I've decided to try something new and
exciting too. :)

You can see the result here: https://github.com/mikrosk/freemint, namely:

   - (supposedly) faster boot times; I didn't have to use 'sudo' (thanks to
   Vincent's launchpad repository + the apt plugin) therefore Travis uses a
   Docker image instead of a full VM
   - 99% travis-clean git history; only one commit is present (adding
   .travis.yml)
   - 99% guarantee that the history will stay travis-clean in the future;
   if you look into .travis.yml you'll see it's basically just a stub,
   everything is downloaded and applied automatically
   - no more dilemmas with improving build scripts -- in fact, you can
   deploy new stuff on the same source base again and again, just using Travis
   "restart build" functionality (so the new build script would be downloaded
   but the version etc would be kept)
   - no more abusing of https://github.com/freemint/travis-pr and
   https://github.com/freemint/freemint.github.io
   <https://github.com/freemint/freemint.github.io> for build outputs,
   everything goes to bintray: https://bintray.com/freemint/freemint
   - fancy download icons ;), nice download statistics, ...

The final burst of motivation was adding Bintray support to Travis, so
instead of this dark magic
<https://github.com/aranym/aranym/blob/master/.travis/deploy.sh> (hats off,
Thorsten!) I could do just this
<https://github.com/mikrosk/travis-scripts/blob/freemint-master/travis-freemint-master/bintray.desc>
.

It comes, however, with a price:

   - git history has to be totally rewritten, so if you have a branch/fork
   of your own, you have to do a hard reset + rebase/cherry-pick
   - we lost the nice links in pull requests, the PR author has to manually
   post the link back to bintray if someone request the build...

It's still not 100% finished (for instance pull requests) but you get the
idea. I have also taken the liberty to clean up a few things in the git
tree like doing a real git merge of the branch "usbtos" (way harder than I
had thought...) or removing/squashing few similar/non-source commits
(.cvsignore -> .gitignore for instance).

I'm writing this in advance to give you time to stop me -- otherwise I'll
do the git force-push sometime on Sunday.

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

Re: [Freemint-discuss] Chroot Troubles

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

On Dienstag, 20. Februar 2018 19:29:06 CET Adam Klobukowski wrote:
> It used to be true a long time ago it seems

I don't think so. If you look at git log -p unix/chroot.c, the last change 
there is from 2001. And even that patch didn't change much, there is nothing 
that indicates that mintlib manages the root directory itself. Wouldn't make 
much sense anyway, since every program would still be able to get out of the 
jail by using the GEMDOS calls directly.

>It also seems that Dchroot() seems to be very incomplete.

Thats more likely the problem. For example, when chrooted, pathnames with 
drive letters shouldn't be allowed (except maybe u:).


PS.: pls send discussions to the list, otherwise ppl. wonder what we are 
talking about ;)

Re: [Freemint-discuss] Chroot Troubles

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

On Montag, 19. Februar 2018 18:57:52 CET Mark Duckworth wrote:
> IIRC chroot is done in MiNTlib, without kernel involvement. So, it

> > depends on how each binary was compiled.

That's not true. The only thing mintlib does is to implement the chroot() 
posix function, by directing it to the Dchroot() MiNT call.

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

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

On 20/02/2018 at 00:46, Thorsten Otto wrote:
> Yes i think so. Those lowercase versions have always been there for all m68k
> platforms, with and without underscores (if you don't use -ansi), while the
> uppercase versions have only been patched in by the mint patch, for
> compatibility with some very old ports. Also, there is no uppercase equivalent
> for -m68030 or better, they all define only __M68020__. So, although that is
> fixed now, the code should check for __mc68020__ instead.

I agree with you. From the top of my head, I went to the same conclusion 
long ago. Of course, we should use new official GCC defines.

-- 
Vincent Rivière

Re: [Freemint-discuss] GCC 7.3 / binutils 2.30

[Mark D. <mdu...@at...>]

Thanks for continuing this!

On 02/19/2018 09:23 PM, Thorsten Otto wrote:
>
> Hi
>
>  
>
> i have just uploaded updated packages, available as separate packages
> or all-in-one. There is now also a cross-compiler available for MinGW
> (plain windows executables). The packages are available here
> <http://tho-otto.de/crossmint.php> .
>
>  
>
> There was also a small bug fixed in GCC which did not set the
> compatibility macro __M68020__ any more (as discussed on github and
> also here). Other than that, there were no new mint specific patches
> (a lot of the new commits are only for using MinGW as a host for a
> cross-compiler, what a mess).
>
>
>

[Freemint-discuss] GCC 7.3 / binutils 2.30

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

Hi

i have just uploaded updated packages, available as separate packages or all-
in-one. There is now also a cross-compiler available for MinGW (plain windows 
executables). The packages are available here .

There was also a small bug fixed in GCC which did not set the compatibility 
macro __M68020__ any more (as discussed on github and also here). Other than 
that, there were no new mint specific patches (a lot of the new commits are 
only for using MinGW as a host for a cross-compiler, what a mess).

Re: [Freemint-discuss] TOSWIN colours

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

Come on, I've been using it for ages, works wonderfully. As you say, it's
just matter of making an alias for ls, grep and find. :)

On 20 February 2018 at 11:32, Thorsten Otto <ad...@th...> wrote:

> In theory, yes, because that is not done by the shell, but by the tools
> like
> ls. However the color capabilities of a vt52 (or even a vt100) that are
> supported by toswin2 are rather limited.
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>



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

Re: [Freemint-discuss] TOSWIN colours

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

In theory, yes, because that is not done by the shell, but by the tools like 
ls. However the color capabilities of a vt52 (or even a vt100) that are 
supported by toswin2 are rather limited.

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

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

Edit: in the mint kernel, things might be different. Some macros like M68000 
are explicitly defined in cdefs.h, which is generated by the Makefile. But you 
are right, there all still a few places that check for __M68020__ instead. 
maybe that is because of this strangeness:

ifeq ($(kernel),020)
MINT = mint020.prg
CPU  = 020
KERNELDEFS = -DM68000
kernel_nocflags = -DWITH_MMU_SUPPORT
endif

Note that only M68000 is defined there, not M68020.

If you are going to use the compiler generated symbols instead, keep in mind 
that switches like -m68020-60 will define *all* macros from __mc68020 to 
__mc68060, but the compiler will generate code that still runs on 68020.

Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

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

On Montag, 19. Februar 2018 09:45:07 CET David Gálvez wrote:
> but it's still no clear to me what is state of these macros in
> gcc 7. Can use them safely?

Yes i think so. Those lowercase versions have always been there for all m68k 
platforms, with and without underscores (if you don't use -ansi), while the 
uppercase versions have only been patched in by the mint patch, for 
compatibility with some very old ports. Also, there is no uppercase equivalent 
for -m68030 or better, they all define only __M68020__. So, although that is 
fixed now, the code should check for __mc68020__ instead.

Re: [Freemint-discuss] Chroot Troubles

[Mark D. <mdu...@at...>]

Thank you sir, that explains everything.

Thanks,
Mark


On 02/19/2018 06:08 AM, Adam Klobukowski wrote:
> IIRC chroot is done in MiNTlib, without kernel involvement. So, it
> depends on how each binary was compiled.
> 
> AdamK
> 
> 
> 
> -- 
> Semper Fidelis
> 
> Adam Klobukowski
> ada...@gm... <mailto:ada...@gm...>

[Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

[David G. <dga...@gm...>]

Move this discussion from github to the list.

So if I understand correctly __M680x0__ (with uppercase) is MiNT's
specific and it's deprecated, I've seen 7 use instances in the
kernel's code, by coincidence 4 in files I'm working with right now,
then the alternative is the compiler general  __mc680x0__ (with lower
case), but it's still no clear to me what is state of these macros in
gcc 7. Can use them safely?


----------------------------------------------
th-otto commented 9 hours ago •

Do you know if gcc 7 still creates a M68020 macro for them?

what i usually do to check things like that:

echo "" | m68k-atari-mint-gcc -dM -E - | grep -i m680

(adding switches you want to test)

And mirko is right, gcc 7 does not define m68020 (or the uppercase
version) anymore. Thats bad. Even worse, when using m68020-60, m68020
is defined, but not m68000 (the latter should be defined for any m68k
target).

I don't think its the fault of our port, but i will check that.

edit: ok the test with -dM did not work in this case. The reason is
that this only prints the symbols that are generated by the code, but
M68020 etc. are generated by entries in the spec file (you can see it
by using gcc -dumpspecs). So for the compiled code, these symbols are
still visible.

Owner

mikrosk commented 9 hours ago

M68020 etc. are generated by entries in the spec file (you can see it
by using gcc -dumpspecs). So for the compiled code, these symbols are
still visible.

@th-otto are you sure? I've tested #ifdef __M68020__ directly with a C
source file and wasn't defined for anything but -m68020-40 and
-m68020-60. Or did I misunderstand your comment?

Contributor

th-otto commented 9 hours ago

@Mikro no i'm not sure :) that said, i haven't tested to compile a
program. But it is defined in the spec file, and it has been like also
for gcc 4.6.4, so i assumed they behave the same in that manner.

Contributor

th-otto commented 6 hours ago

Hm there is definitely something wrong with the definitions coming
from the spec file, but i coudn't figure out yet what. It has been the
same definition for ages (CPP_SPEC in config/m68k/mint.h). However
there is a simple solution: just test for mc68020 instead. The
uppercase versions are old relicts anyway.

Edit: i just saw that the definition of asm_cpu_spec is different
between 4.6.4 and 7.2. That definition wasn't touched by our mint
patch, so i guess it has changed for m68k in general, and seems to
cause different behaviour now.



2018-02-18 23:58 GMT+01:00 Miro Kropáček <mir...@gm...>:
> Hi David,
>
> if the interpretation you've mentioned in
> https://github.com/freemint/freemint/issues/70 holds for all drivers (i.e.
> that the delay is supposed to wait at least X microseconds) there shouldn't
> be any regressions IMHO -- the new formula must definitely take longer than
> the previous stub.
>
> As for your question about "__M68020__": gcc 7.2 emits them only for
> -m68020-40 and -m68020-60 (no, not even -m68020!). It definitely seems like
> some kind of deprecated macro kept only for the minimal backward
> compatibility.
>

Re: [Freemint-discuss] [Freemint-list] Broken udelay() for m68000

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

Hi David,

if the interpretation you've mentioned in https://github.com/
freemint/freemint/issues/70 holds for all drivers (i.e. that the delay is
supposed to wait *at least* X microseconds) there shouldn't be any
regressions IMHO -- the new formula must definitely take longer than the
previous stub.

As for your question
<https://github.com/freemint/freemint/issues/70#issuecomment-366506935> about
"__M68020__": gcc 7.2 emits them only for -m68020-40 and -m68020-60 (no,
not even -m68020!). It definitely seems like some kind of deprecated macro
kept only for the minimal backward compatibility.

On 19 February 2018 at 02:32, David Gálvez <dga...@gm...> wrote:

> Yesterday I sent the email below to the list address at atari-forge, I
> didn't watch that the email I was answering was sent to the the old
> list address.
> Today it bounced so I send it again to the right address.
>
> 2018-02-17 10:04 GMT+01:00 David Gálvez <dga...@gm...>:
> > 2017-10-16 3:57 GMT+02:00 Miro Kropáček <mir...@gm...>:
> >> After some study, it seems it isn't that bad (I think most of you were
> aware
> >> of it): the delay functions are calibrated, quite precisely actually.
> That
> >> loops_per_sec variable is actually a result of such calibration.
> >>
> >> So the problem is that m68000 code ignores it. I think David is right,
> the
> >> magic formula used in the linux kernel is supposed to work on all
> m68ks, not
> >> only ColdFire (see the comment, "simpler m68k").
> >>
> >> On m68000, the code is quite chatty:
> >>
> >>      3a4:       206a 001c       moveal %a2@(28),%a0
> >>      3a8:       4878 00c8       pea c8 <oldSR-0x1c>
> >>      3ac:       2f10            movel %a0@,%sp@-
> >>      3ae:       4e93            jsr %a3@
> >>      3b0:       508f            addql #8,%sp
> >>      3b2:       720b            moveq #11,%d1
> >>      3b4:       e2a8            lsrl %d1,%d0
> >>      3b6:       2200            movel %d0,%d1
> >>      3b8:       d280            addl %d0,%d1
> >>      3ba:       d280            addl %d0,%d1
> >>      3bc:       2801            movel %d1,%d4
> >>      3be:       e98c            lsll #4,%d4
> >>      3c0:       d284            addl %d4,%d1
> >>      3c2:       2801            movel %d1,%d4
> >>      3c4:       e18c            lsll #8,%d4
> >>      3c6:       d284            addl %d4,%d1
> >>      3c8:       e789            lsll #3,%d1
> >>      3ca:       d081            addl %d1,%d0
> >>      3cc:       ec88            lsrl #6,%d0
> >>
> >> (a3 points to ___udivsi3)
> >>
> >> However we should use this code also for 68060 and not only for CF as
> mul
> >> ea,dr:dq is not implemented on 060 (leading to a huge performance
> bottleneck
> >> I imagine).
> >>
> >
> > I've just pushed a commit to make 68000 builds to use "real" delays
> > and fix this situation.
> >
> > Some drivers that were adjusted to the old delay method could break,
> > For what I could see they're usb.km, storage.udd and asix.xif or the
> > TOS variant of them (only 68000 builds).
> > I've asked in AF for testers but I didn't get too much feedback, I
> > decided to push anyway I don't want the commits to end dying in my
> > hard drive as already has happened to me in the past.
> > If you read users complaining about these drivers malfunction with
> > recent kernel versions keep in mind this commit could be a reason.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>



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

Re: [Freemint-discuss] [Freemint-list] Broken udelay() for m68000

[David G. <dga...@gm...>]

Yesterday I sent the email below to the list address at atari-forge, I
didn't watch that the email I was answering was sent to the the old
list address.
Today it bounced so I send it again to the right address.

2018-02-17 10:04 GMT+01:00 David Gálvez <dga...@gm...>:
> 2017-10-16 3:57 GMT+02:00 Miro Kropáček <mir...@gm...>:
>> After some study, it seems it isn't that bad (I think most of you were aware
>> of it): the delay functions are calibrated, quite precisely actually. That
>> loops_per_sec variable is actually a result of such calibration.
>>
>> So the problem is that m68000 code ignores it. I think David is right, the
>> magic formula used in the linux kernel is supposed to work on all m68ks, not
>> only ColdFire (see the comment, "simpler m68k").
>>
>> On m68000, the code is quite chatty:
>>
>>      3a4:       206a 001c       moveal %a2@(28),%a0
>>      3a8:       4878 00c8       pea c8 <oldSR-0x1c>
>>      3ac:       2f10            movel %a0@,%sp@-
>>      3ae:       4e93            jsr %a3@
>>      3b0:       508f            addql #8,%sp
>>      3b2:       720b            moveq #11,%d1
>>      3b4:       e2a8            lsrl %d1,%d0
>>      3b6:       2200            movel %d0,%d1
>>      3b8:       d280            addl %d0,%d1
>>      3ba:       d280            addl %d0,%d1
>>      3bc:       2801            movel %d1,%d4
>>      3be:       e98c            lsll #4,%d4
>>      3c0:       d284            addl %d4,%d1
>>      3c2:       2801            movel %d1,%d4
>>      3c4:       e18c            lsll #8,%d4
>>      3c6:       d284            addl %d4,%d1
>>      3c8:       e789            lsll #3,%d1
>>      3ca:       d081            addl %d1,%d0
>>      3cc:       ec88            lsrl #6,%d0
>>
>> (a3 points to ___udivsi3)
>>
>> However we should use this code also for 68060 and not only for CF as mul
>> ea,dr:dq is not implemented on 060 (leading to a huge performance bottleneck
>> I imagine).
>>
>
> I've just pushed a commit to make 68000 builds to use "real" delays
> and fix this situation.
>
> Some drivers that were adjusted to the old delay method could break,
> For what I could see they're usb.km, storage.udd and asix.xif or the
> TOS variant of them (only 68000 builds).
> I've asked in AF for testers but I didn't get too much feedback, I
> decided to push anyway I don't want the commits to end dying in my
> hard drive as already has happened to me in the past.
> If you read users complaining about these drivers malfunction with
> recent kernel versions keep in mind this commit could be a reason.

Re: [Freemint-discuss] $Id$ CVS keyword

[David G. <dga...@gm...>]

Done!

2018-02-16 9:51 GMT+01:00 Miro Kropáček <mir...@gm...>:
> Hi David,
>
>> If nobody has any objection I'm going to delete them.
>
> I have been thinking about the same for some months. I think there's no
> benefit in those ids, so go ahead.
>
> --
> MiKRO / Mystic Bytes
> http://mikro.atari.org

[Freemint-discuss] Chroot Troubles

[Mark D. <mdu...@at...>]

Hello all,

Once upon a time I was told that chroot in mint works fine.  I decided
to try it and on the surface it looks good but when I dig deeper there
is issues.  Here it is demonstrated.  Current kernel, coreutils chroot
binary.

Create a bootstrap under /root/bootstrap  Not much under there, just
coreutils, rpm and a few other things.

root@bf3:/root>chroot /root/bootstrap /bin/bash
bash-2.05a# pwd
/e/root/bootstrap
bash-2.05a# ls
bin  etc  sbin  usr  var
bash-2.05a#

Ok so bash doesn't find anything which means bash is respecting the
chroot.  We did change directories but pwd can see it is not in a new root.

bash-2.05a# ls
bin  etc  sbin  usr  var
bash-2.05a# pwd
/
bash-2.05a#

Ok but we can go to / and the chroot is adhered to.  Maybe we can
proceed.  What is under /var

bash-2.05a# ls
adm  catman  log
bash-2.05a#

Ok so proceed.

bash-2.05a# rpm -qa
automake-1.11.1-1 
info-4.0-2             
cpio-2.4.2-3      
procps-ng-3.3.2-1    
bzip2-1.0.2-1

....

and so on.  The rpm database is the one from outside the chroot.  Any ideas?

Thanks,

Mark

[Freemint-discuss] TOSWIN colours

[Peter S. <p....@sc...>]

Is there any way to make the toswin2 shell to display diffent colours
for files and directories like the shell in linux ?

Peter

Re: [Freemint-discuss] Mint update 976

[Peter S. <p....@sc...>]

The errors look like they are happening as it processes /etc/fstab

They look like

nfs_root(nn) -> ENXIO

followed by a warning about mounting unchecked filesystem.



Regards,



On Fri, 16 Feb 2018 19:06:38 , Peter Slegg <p....@sc...> wrote:
>
> It's difficult because the errors are not logged anywere.
> Is there an AUTO prog that can capture all the boot mesages ?
>
> The messages are for all the partitions of all types (FATFS, NFS) and
> the error says either EXNIO or EXIO. Something like that.
> It's not on screen for very long.
>
> In most cases the file check doesn't actually need to examine the
> partitions so there is not progress bar. When it did need to run it
> ran ok.
>
>
> Peter
>
>
>
>
>
> On Fri, 16 Feb 2018 20:37:55 , Miro Kropá?ek wrote:
> > Hi,
> >
> >
> > > During boot it is giving an error for each partition saying that
> > > it is mounting an unchecked filesystem.
> > >
> > > # Filesystemcheck (mandatory)
> > > exec u:\c\mint\bin\sh u:\c\mint\bin\fscheck.sh
> > >
> > > I have the check in mint.cnf so I am a investigating what is going wrong.
> > >
> >
> > you should be a bit more specific if you expect some feedback. Like:
> >
> > - what kind of partitions
> > - does the check finish and if so, does it the check happen again?
> > - do you see the progress bar (
> > https://github.com/freemint/freemint/issues/73)
> >
> > And while you're at it, whether you see any improvement in your
> > https://github.com/freemint/freemint/issues/62 :)
> >
>
>

[Freemint-discuss] (no subject)

    <p....@sc...>
Cc: <fre...@li...>
From: Peter Slegg <p....@sc...>
Subject: Re: [Freemint-discuss] Mint update 976
Reply-To: Peter Slegg <p....@sc...>
X-Mailer: MyMAIL Rev:1.96.04.14145 (Atari/(STiK/STinG/GlueSTiK))
X-Hardware: Atari Milan
MIME-Version: 1.0
Date: Fri, 16 Feb 2018 19:06:38 +0000 (GMT)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Message-Id: <000...@sm...>
References: <CAN...@ma...>
In-Reply-To: CAN...@ma...


It's difficult because the errors are not logged anywere.
Is there an AUTO prog that can capture all the boot mesages ?

The messages are for all the partitions of all types (FATFS, NFS) and
the error says either EXNIO or EXIO. Something like that.
It's not on screen for very long.

In most cases the file check doesn't actually need to examine the
partitions so there is not progress bar. When it did need to run it
ran ok.


Peter





On Fri, 16 Feb 2018 20:37:55 , Miro Krop=E1?ek wrote:
> Hi,
>
>
> > During boot it is giving an error for each partition saying that
> > it is mounting an unchecked filesystem.
> >
> > # Filesystemcheck (mandatory)
> > exec u:\c\mint\bin\sh u:\c\mint\bin\fscheck.sh
> >
> > I have the check in mint.cnf so I am a investigating what is going wrong.
> >
>
> you should be a bit more specific if you expect some feedback. Like:
>
> - what kind of partitions
> - does the check finish and if so, does it the check happen again?
> - do you see the progress bar (
> https://github.com/freemint/freemint/issues/73)
>
> And while you're at it, whether you see any improvement in your
> https://github.com/freemint/freemint/issues/62 :)
>

Re: [Freemint-discuss] Mint update 976

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

Hi,


> During boot it is giving an error for each partition saying that
> it is mounting an unchecked filesystem.
>
> # Filesystemcheck (mandatory)
> exec u:\c\mint\bin\sh u:\c\mint\bin\fscheck.sh
>
> I have the check in mint.cnf so I am a investigating what is going wrong.
>

you should be a bit more specific if you expect some feedback. Like:

- what kind of partitions
- does the check finish and if so, does it the check happen again?
- do you see the progress bar (
https://github.com/freemint/freemint/issues/73)

And while you're at it, whether you see any improvement in your
https://github.com/freemint/freemint/issues/62 :)

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

[Freemint-discuss] Mint update 976

[Peter S. <p....@sc...>]

Hi,

I've just updated for the first time since last September.

During boot it is giving an error for each partition saying that
it is mounting an unchecked filesystem.

# Filesystemcheck (mandatory)
exec u:\c\mint\bin\sh u:\c\mint\bin\fscheck.sh

I have the check in mint.cnf so I am a investigating what is going wrong.


Peter

Re: [Freemint-discuss] $Id$ CVS keyword

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

Hi David,

If nobody has any objection I'm going to delete them.
>
I have been thinking about the same for some months. I think there's no
benefit in those ids, so go ahead.

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

[Freemint-discuss] $Id$ CVS keyword

[David G. <dga...@gm...>]

Hello!

Most of source files in the repository have the keyword "$Id$" from the CVS era.
This keyword expanded in some info like the file's revision, last
modification's date and modification's author. Now with git it's not
used anymore.

If nobody has any objection I'm going to delete them.