freemint-discuss — The official FreeMiNT Mailing List

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

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

On Dienstag, 13. März 2018 02:18:03 CET Miro Kropáček wrote:
> If you bump into some strange troubles, just post it here, I'll try to help.

Not really trouble, but some strangeness: when looking at commit

https://github.com/freemint/freemint/commit/
6794f46ceef4c45ae79c6d306c388f8fece03b74#diff-3240fd2b36343a7f8e388f163731ea06

i read now: th-otto committed on...

However, i only committed that to my fork, and the PR was later merged. So the 
information, that this commit was caused by merging that PR seems to be lost.

Re: [Freemint-discuss] Mint update 976

[Paul W. <pau...@gm...>]

remember that you can both interupt mint boot an change mint.ini (or
is it mint.cfg) both should allow log file

Paul

On 2/17/18, Peter Slegg <p....@sc...> wrote:
> 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 :)
>> >
>>
>>
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>

Re: [Freemint-discuss] TOSWIN colours

[Paul W. <pau...@gm...>]

with the BeePi build I tried all sorts to get that working, in the end
I gave up.

I forgot about LS_COLORS at the time

Paul

On 2/20/18, Miro Kropáček <mir...@gm...> wrote:
> 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] Bintray integration / git force-push needed

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

2018-03-13 22:36 GMT+01:00 Miro Kropáček <mir...@gm...>:
> Hi David,
>
> On 14 March 2018 at 06:13, David Gálvez <dga...@gm...> wrote:
>>
>> I've observed something weird after the repository's clean up:
>>
>> Look the history of the file sys/mint/arch/delay.h
>>
>> https://github.com/freemint/freemint/commits/master/sys/mint/arch/delay.h
>>
>> the commit from Jun 26 2014 "Merge from Trunk"
>>
>> This commit seems from some Alan's branch not the trunk
>
>
> This is OK -- one of the changes I've made is to make Alan's "usbtos" branch
> a real git branch. That means that you can follow the initial fork, its
> separate commits and then merge back to master. In CVS/former git repository
> it was really messed up and while it has very little meaning I did it as a
> nice git exercise (yes, I regretted it later ;)).
>
> Content-wise it should be the same, i.e. there shouldn't be any differences
> against the commit after the old CVS "merge" point.
>

OK. Perhaps not very important but some differentiate commits now are
together with others in one big commit.

For example this PCI-BIOS differentiate commit:
https://github.com/DavidGZ/freemint/commit/9d0a0b5701f3421bc9cc61eb352c6cedbfaf9d50#diff-ae395915bb2dac4ca2ce7c3217a8d1ab

Now is mixed with some other commits with no relation:
https://github.com/freemint/freemint/commit/72818b654b732896deaa31d9a686a3951b96f71a#diff-ae395915bb2dac4ca2ce7c3217a8d1ab

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

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

Hi David,

On 14 March 2018 at 06:13, David Gálvez <dga...@gm...> wrote:
>
> I've observed something weird after the repository's clean up:
>
> Look the history of the file sys/mint/arch/delay.h
>
> https://github.com/freemint/freemint/commits/master/sys/mint/arch/delay.h
>
> the commit from Jun 26 2014 "Merge from Trunk"
>
> This commit seems from some Alan's branch not the trunk


This is OK -- one of the changes I've made is to make Alan's "usbtos"
branch a real git branch. That means that you can follow the initial fork,
its separate commits and then merge back to master. In CVS/former git
repository it was really messed up and while it has very little meaning I
did it as a nice git exercise (yes, I regretted it later ;)).

Content-wise it should be the same, i.e. there shouldn't be any differences
against the commit after the old CVS "merge" point.

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

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

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

Hi Miro,

I've observed something weird after the repository's clean up:

Look the history of the file sys/mint/arch/delay.h

https://github.com/freemint/freemint/commits/master/sys/mint/arch/delay.h

the commit from Jun 26 2014 "Merge from Trunk"

This commit seems from some Alan's branch not the trunk

This is the file's history in the trunk:
(only the latest commits)

commit 834cde6e3a92edce1793facd47b84ab2cbe17592
Author: David Gálvez <dga...@gm...>
Date:   Fri Feb 16 19:04:41 2018 +0100

    Delete CVS's keyword $Id$ from a bunch of files

    This keyword is unused since the migration to Git.

commit 9eedecd51c2dcbe2b69ccda512ade3737689c59f
Author: David Gálvez <dga...@gm...>
Date:   Mon Feb 12 19:38:50 2018 +0100

    Remove unused declaration of function udelay()

    This declaration seems to have been slipped in through
    Linux-m68k and from Linux-arm where the delays functions
    aren't inlined but in a library.

commit 249e0c32b3afc4f572b4378095c514cc0cc6207c
Author: David Gálvez <dga...@gm...>
Date:   Mon Feb 12 18:06:23 2018 +0100

    Use loops calculation formula for 68000 builds

    Builds for the 68000 were using a very simple delay mechanism,
    just looping as many times as the microseconds requested. Now
    we use the formula that was added for the ColdFire, which lacks
    of the mulul instruction too.

commit fa63267501d06df20f219921dc7cf3796ce73560
Author: Alan Hourihane <al...@fa...>
Date:   Wed Jul 16 16:31:33 2014 +0000

    Merge usbtos branch to the trunk.

    This brings in lots of updates, fixes and new features.

    - USB stack now available for TOS only (requires the usb ACCessory)
    - New USB mouse driver
    - SCSIDRV available for TOS only (possibly for FreeMiNT later)
    - Unicorn USB adapter driver available for TOS only. Others need porting.

    Thanks to Roger Burrows for his work on bringing some of the USB code
    out of assembly language and into C too !

commit a6b6e1abb753bb5f3f2b1bb0e31f9c3db84f4438
Author: Alan Hourihane <al...@fa...>
Date:   Sun Apr 27 14:45:25 2014 +0000

    Update the udelay timer. Brought from the m68k-nommu tree.
    Contributed by David Galvez

commit dd3d8d8f3136e616a8ff39b5bbddab2cb7dc35c0
Author: Alan Hourihane <al...@fa...>
Date:   Sat May 7 04:19:57 2011 +0000

    Re-enable USB support and rename to XHDI_MASS_STORAGE_SUPPORT


2018-03-13 2:18 GMT+01:00 Miro Kropáček <mir...@gm...>:
> Following the rule "no answer = go ahead" :) I've done it -- so all branches
> and tags are rebased, history cleaned etc. I still need to do a few things
> (bintray seems to hate me today) so most likely another commit will follow
> but that should be it.
>
> The easiest way to cope with the change (if you don't have any local commit
> in your github fork's master) just pull from the upstream repo, reset your
> master to the new head and force push to your github remote master.
>
> After that you can either rebase or cherry pick your local branches. I find
> cherry-pick the easiest way as there's virtually no code change in the
> changed history at all, just removed files, so there shouldn't be any
> conflicts.
>
> If you bump into some strange troubles, just post it here, I'll try to help.
>
> On 8 March 2018 at 10:51, Miro Kropáček <mir...@gm...> wrote:
>>
>> Hi guys,
>>
>> just resending this email as had been sent just in the middle of the
>> SourceForge crisis so it's possible it didn't reach everyone. I have last
>> few days of my time available to do this so it would be nice if we reach
>> some agreement here, especially from Alan. IMO it's worth the small
>> annoyance (as we gain a smaller repository, non-polluted history, ...).
>>
>> On 24 February 2018 at 09:45, Miro Kropáček <mir...@gm...>
>> wrote:
>>>
>>> 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 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 (hats off, Thorsten!) I could do just this.
>>>
>>> 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
>>
>>
>>
>>
>> --
>> MiKRO / Mystic Bytes
>> http://mikro.atari.org
>
>
>
>
> --
> MiKRO / Mystic Bytes
> http://mikro.atari.org
>
> ------------------------------------------------------------------------------
> 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
>

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

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

Following the rule "no answer = go ahead" :) I've done it -- so all
branches and tags are rebased, history cleaned etc. I still need to do a
few things (bintray seems to hate me today) so most likely another commit
will follow but that should be it.

The easiest way to cope with the change (if you don't have any local commit
in your github fork's master) just pull from the upstream repo, reset your
master to the new head and force push to your github remote master.

After that you can either rebase or cherry pick your local branches. I find
cherry-pick the easiest way as there's virtually no code change in the
changed history at all, just removed files, so there shouldn't be any
conflicts.

If you bump into some strange troubles, just post it here, I'll try to help.

On 8 March 2018 at 10:51, Miro Kropáček <mir...@gm...> wrote:

> Hi guys,
>
> just resending this email as had been sent just in the middle of the
> SourceForge crisis so it's possible it didn't reach everyone. I have last
> few days of my time available to do this so it would be nice if we reach
> some agreement here, especially from Alan. IMO it's worth the small
> annoyance (as we gain a smaller repository, non-polluted history, ...).
>
> On 24 February 2018 at 09:45, Miro Kropáček <mir...@gm...>
> wrote:
>
>> 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
>>
>
>
>
> --
> MiKRO / Mystic Bytes
> http://mikro.atari.org
>



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

Re: [Freemint-discuss] Bug report and patch

[Roger B. <an...@xp...>]

On 12 Mar 2018 at 17:03, David Gálvez wrote:

> 2018-03-11 20:00 GMT+01:00 Roger Burrows <an...@xp...>:
> > On 11 Mar 2018 at 19:22, David Gálvez wrote:
> >
> >> 2018-03-11 18:46 GMT+01:00 Roger Burrows <an...@xp...>:
> >> > On 7 Mar 2018 at 18:08, Roger Burrows wrote:
> >> >
> >> >> The attached patch fixes a bug in the TOSONLY code in usb_storage.c.
> >> >
> 
> Pushed!
> 
Thanks!

Roger

Re: [Freemint-discuss] Bug report and patch

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

2018-03-11 20:00 GMT+01:00 Roger Burrows <an...@xp...>:
> On 11 Mar 2018 at 19:22, David Gálvez wrote:
>
>> 2018-03-11 18:46 GMT+01:00 Roger Burrows <an...@xp...>:
>> > On 7 Mar 2018 at 18:08, Roger Burrows wrote:
>> >
>> >> The attached patch fixes a bug in the TOSONLY code in usb_storage.c.
>> >
>> > No response to this at all.  I don't have access to the FreeMiNT repository,
>> so
>> > can't apply the patch myself.  Can someone look at this please?
>> >
>>
>> Hi Roger, I can apply the patch, but I didn't do it because I wasn't
>> sure if it's the maintainer who must review and commit the patches
>> submitted to the list.
>> I didn't want to give myself those "rights" ;-). As Alan seems to be
>> very busy and if nobody complains I'll commit it.
>>
> Thanks, David.  I was a bit concerned that the message hadn't made it to the
> list (SF was very flaky for a couple of weeks), so that in part prompted my
> followup.
>
> Like you, I don't know the protocol for patch submission, so if it's best that
> Alan does the commit, I'm happy to wait.  The patch in fact *should* only
> affect users of Alan's TOS4USB code, which is at the moment limited to Unicorn
> users I think.  So if you would rather wait for a Alan, I guess that's another
> reason, although I also get the impression that he doesn't have much time ATM.
>
> For general interest, a friend of mine is currently working on getting the
> NetUSB hardware to work with the same code, which is how I ran into this bug.
>
>> Don't you prefer to generate the patch with "git format-patch" so it
>> will be have your Github user information added?
>>
> Since I don't normally have a requirement for the latest version of FreeMiNT, I
> just downloaded the tarball for the sources and patched that, so git wouldn't
> have worked.
>

Pushed!

Re: [Freemint-discuss] Bug report and patch

[Roger B. <an...@xp...>]

On 11 Mar 2018 at 19:22, David Gálvez wrote:

> 2018-03-11 18:46 GMT+01:00 Roger Burrows <an...@xp...>:
> > On 7 Mar 2018 at 18:08, Roger Burrows wrote:
> >
> >> The attached patch fixes a bug in the TOSONLY code in usb_storage.c.
> >
> > No response to this at all.  I don't have access to the FreeMiNT repository,
> so
> > can't apply the patch myself.  Can someone look at this please?
> >
> 
> Hi Roger, I can apply the patch, but I didn't do it because I wasn't
> sure if it's the maintainer who must review and commit the patches
> submitted to the list.
> I didn't want to give myself those "rights" ;-). As Alan seems to be
> very busy and if nobody complains I'll commit it.
> 
Thanks, David.  I was a bit concerned that the message hadn't made it to the 
list (SF was very flaky for a couple of weeks), so that in part prompted my 
followup.

Like you, I don't know the protocol for patch submission, so if it's best that 
Alan does the commit, I'm happy to wait.  The patch in fact *should* only 
affect users of Alan's TOS4USB code, which is at the moment limited to Unicorn 
users I think.  So if you would rather wait for a Alan, I guess that's another 
reason, although I also get the impression that he doesn't have much time ATM.

For general interest, a friend of mine is currently working on getting the 
NetUSB hardware to work with the same code, which is how I ran into this bug.

> Don't you prefer to generate the patch with "git format-patch" so it
> will be have your Github user information added?
> 
Since I don't normally have a requirement for the latest version of FreeMiNT, I 
just downloaded the tarball for the sources and patched that, so git wouldn't 
have worked.

Roger

Re: [Freemint-discuss] Bug report and patch

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

2018-03-11 19:36 GMT+01:00 Thorsten Otto <ad...@th...>:
> On Sonntag, 11. März 2018 19:22:34 CET David Gálvez wrote:
>
>>
>
>> Don't you prefer to generate the patch with "git format-patch" so it
>
>> will be have your Github user information added?
>
>
>
> You can also do that on his behalf:
>
>
>
> git commit -m "some commit message" --author "Roger Burrows
> <ano...@us...>"
>

OK! Thanks for the tip!
I'll do it ASAP

Re: [Freemint-discuss] Bug report and patch

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

On Sonntag, 11. März 2018 19:22:34 CET David Gálvez wrote:
> 
> Don't you prefer to generate the patch with "git format-patch" so it
> will be have your Github user information added?

You can also do that on his behalf:

git commit -m "some commit message" --author "Roger Burrows 
<ano...@us...>"

Re: [Freemint-discuss] Bug report and patch

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

2018-03-11 18:46 GMT+01:00 Roger Burrows <an...@xp...>:
> On 7 Mar 2018 at 18:08, Roger Burrows wrote:
>
>> The attached patch fixes a bug in the TOSONLY code in usb_storage.c.
>
> No response to this at all.  I don't have access to the FreeMiNT repository, so
> can't apply the patch myself.  Can someone look at this please?
>

Hi Roger, I can apply the patch, but I didn't do it because I wasn't
sure if it's the maintainer who must review and commit the patches
submitted to the list.
I didn't want to give myself those "rights" ;-). As Alan seems to be
very busy and if nobody complains I'll commit it.

Don't you prefer to generate the patch with "git format-patch" so it
will be have your Github user information added?

Re: [Freemint-discuss] Bug report and patch

[Roger B. <an...@xp...>]

On 7 Mar 2018 at 18:08, Roger Burrows wrote:

> The attached patch fixes a bug in the TOSONLY code in usb_storage.c. 

No response to this at all.  I don't have access to the FreeMiNT repository, so 
can't apply the patch myself.  Can someone look at this please?

Roger

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

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

Hi guys,

just resending this email as had been sent just in the middle of the
SourceForge crisis so it's possible it didn't reach everyone. I have last
few days of my time available to do this so it would be nice if we reach
some agreement here, especially from Alan. IMO it's worth the small
annoyance (as we gain a smaller repository, non-polluted history, ...).

On 24 February 2018 at 09:45, Miro Kropáček <mir...@gm...> wrote:

> 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
>



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

[Freemint-discuss] Bug report and patch

[Roger B. <an...@xp...>]

The attached patch fixes a bug in the TOSONLY code in usb_storage.c.  It does 
not affect FreeMiNT, but it does affect the STORAGE.PRG that is used in support 
of USB sticks on plain TOS (and EmuTOS), and the code is in the FreeMiNT 
sources, so I am submitting the patch here.

Problem description:
During STORAGE.PRG startup, if the current max_sect_siz in the AHDI structure 
is not the same as the maximum logical sector size obtained from XHDI, the 
program installs a new AHDI structure and a new set of cache buffers.  It then 
copies the data from the old buffers to the new ones.  However, it only copies 
the first 512 bytes of each buffer; the rest of the buffer was zeroed after 
being malloc'ed and remains that way.

As a result, if max_sect_siz is not the same as the XHDI size, and max_sect_siz 
is greater than 512, the in-memory copy of sectors will be corrupt after 
STORAGE.PRG has run.  If the cached sectors are from directories, then files or 
folders will temporarily disappear; if those sectors are subsequently written 
to, the bad data will be flushed to disk, causing filesystem corruption.

Fix:
The fix merely sets the copy length correctly.

Roger Burrows

Re: [Freemint-discuss] Chroot Troubles

[Adam K. <ada...@gm...>]

2018-02-20 17:20 GMT+01:00 Thorsten Otto <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.
>
>
It used to be true a long time ago it seems. It also seems that Dchroot()
seems to be very incomplete.

-- 
Semper Fidelis

Adam Klobukowski
ada...@gm...

Re: [Freemint-discuss] Mailing list problems

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

That message if you don't know is from spamassassin.  It'd be good to
know if sourceforge's mail server added it or your sending mail server. 
Regardless, 4.1 is pretty spammy ;)

Thanks,

Mark



On 02/27/2018 04:25 PM, Miro Kropáček wrote:
> On the other hand I don't see your (or mine for that matter) email in
> the archives, hm.
>
> On 28 February 2018 at 08:22, Miro Kropáček <mir...@gm...
> <mailto:mir...@gm...>> wrote:
>
>     Yup, arrived sound & safe. :)
>
>     On 28 February 2018 at 03:29, Thorsten Otto <ad...@th...
>     <mailto:ad...@th...>> wrote:
>
>         Just a test, because some of my recent mails were bounced with
>
>         <fre...@li...
>         <mailto:fre...@li...>>: host
>         mx.sourceforge.net <http://mx.sourceforge.net>[216.105.38.6]
>             said: 550 This message scored 4.1 points. Congratulations!
>         (in reply to
>         end
>             of DATA command)
>
>         Sorry for the noise
>
>
>
>         ------------------------------------------------------------------------------
>         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...
>         <mailto:Fre...@li...>
>         https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>         <https://lists.sourceforge.net/lists/listinfo/freemint-discuss>
>
>
>
>
>     -- 
>     MiKRO / Mystic Bytes
>     http://mikro.atari.org
>
>

Re: [Freemint-discuss] Chroot Troubles

[Adam K. <ada...@gm...>]

IIRC chroot is done in MiNTlib, without kernel involvement. So, it depends
on how each binary was compiled.

AdamK

2018-02-17 4:38 GMT+01:00 Mark Duckworth <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
>
>
>
>
> ------------------------------------------------------------
> ------------------
> 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
>



-- 
Semper Fidelis

Adam Klobukowski
ada...@gm...

Re: [Freemint-discuss] Mailing list problems

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

On the other hand I don't see your (or mine for that matter) email in the
archives, hm.

On 28 February 2018 at 08:22, Miro Kropáček <mir...@gm...> wrote:

> Yup, arrived sound & safe. :)
>
> On 28 February 2018 at 03:29, Thorsten Otto <ad...@th...> wrote:
>
>> Just a test, because some of my recent mails were bounced with
>>
>> <fre...@li...>: host
>> mx.sourceforge.net[216.105.38.6]
>>     said: 550 This message scored 4.1 points. Congratulations! (in reply
>> to
>> end
>>     of DATA command)
>>
>> Sorry for the noise
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> 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
>



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

Re: [Freemint-discuss] Mailing list problems

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

Yup, arrived sound & safe. :)

On 28 February 2018 at 03:29, Thorsten Otto <ad...@th...> wrote:

> Just a test, because some of my recent mails were bounced with
>
> <fre...@li...>: host
> mx.sourceforge.net[216.105.38.6]
>     said: 550 This message scored 4.1 points. Congratulations! (in reply to
> end
>     of DATA command)
>
> Sorry for the noise
>
>
>
> ------------------------------------------------------------
> ------------------
> 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

[Freemint-discuss] Mailing list problems

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

Just a test, because some of my recent mails were bounced with

<fre...@li...>: host 
mx.sourceforge.net[216.105.38.6]
    said: 550 This message scored 4.1 points. Congratulations! (in reply to 
end
    of DATA command)

Sorry for the noise

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

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

2018-02-19 9:45 GMT+01:00 David Gálvez <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?
>
>

I have just read this in the gcc 7.3.0 manual:

"GCC defines the macros __mcarch and __mcarch__ when tuning for 680x0
architecture arch. It also defines mcarch unless either -ansi or a
non-GNU -std option is used. If GCC is tuning for a range of
architectures, as selected by -mtune=68020-40 or -mtune=68020-60, it
defines the macros for every architecture in the range."

So  in theory it's safe and nothing has been changed regarding these
macros between compiler's version.

I'm going to remove what is left of the uppercase macros and swap them
by the lowercase ones

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

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

On 24 February 2018 at 09:45, Miro Kropáček <mir...@gm...> wrote:

> It's still not 100% finished (for instance pull requests)
>
Btw Thorsten, how did you solve this? I see Aranym's deploy.sh contains a
check for BINTRAY_API_KEY however I still don't get it -- I, as a foreign
contributor, create a bintray account, setup the ENV variable in my travis
build and ... how the pull request output makes it into aranym's
pullrequests folder? Is there a hidden implication that I have to be a
member of 'aranym' bintray organisation?

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

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

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

2018-02-24 1:42 GMT+01:00 Miro Kropáček <mir...@gm...>:
> On 24 February 2018 at 11:27, Thorsten Otto <ad...@th...> wrote:
>> 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. ;-)
>

I don't have too much knowledge about this matter, so I can't give you
any valuable opinion.
The only thing I can tell you is that one of this forks is mine but I
didn't do anything with it, so it's not an issue for me the forced
history change.