freemint-discuss — The official FreeMiNT Mailing List

[Freemint-discuss] Timezone and timestamp

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

Myself and others have reported timezone issues especially with
the change to summertime.


Android has a bug that means files sent over samba have their
timestamps set to the sysdate. So I use touch -t to reset the
times based on the filename. I have hacked up a perl script to
do this.


I do the mp4 files individually:

touch -t 201712101030 /tmp/20171210_103049.mp4

but in Thing they are shown with a time of 1 hour ahead.
I am using BST (GMT +1)

In this example the file is shown as 11:30 when I have stamped it 10:30



In bash the file time is correct:

bash-4.3# ls -l /tmp/
total 10460
-rw-r--r--    1 root     root     10692187 Dec 10 10:30 20171210_103049.mp4


Peter

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

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

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

I've now replaced the old MiNT's specific macros by the generic ones.
I've left untouched the M680x0 macros (without underscores) that are
defined during the compile's time (see KERNELDEFS).
Those seems to have some extra purpose, for example the macro M68040
is defined when compiling the ColdFire kernel.

Still there are some defines that mix both macros types (like this one
 "#if !(defined(M68000) || defined(__mcoldfire__))")
https://github.com/freemint/freemint/blob/1196c6f665b6eed314b419ce560f445ebaeae5a1/sys/arch/intr.S#L749
If this is not on purpose we could replace them too for code consistency.

Re: [Freemint-discuss] New driver binary

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

Hi David,

On 22 March 2018 at 06:41, David Gálvez <dga...@gm...> wrote:

> I've just pushed a commit for generating a new RTL8012 driver version
> for machines with the 060 CPU, the new driver name is rtl8012ct60.xif.
> I guess the new driver path should be added somewhere for the binary
> snapshots (Hi Miro ;-) )
>

I followed your painful testing experience on AF so this is the least I can
do. :) Actually it's not that much work, don't be afraid to do it by
yourself in the future:

   - Alan's build ("trunk") is automatically adjusted as it uses *.xif mask
   to copy
   - My preconfigured images needed only one small change
   <https://github.com/freemint/travis-scripts/commit/a05a95dab2040c5c51fb974b748540f5c5b5bb3f>
in
   'travis-scripts' repository and build restart in Travis

So now everyone can download <https://freemint.github.io/#snapshots> the
image with new driver as usual (naturally, present only in the 020 archive
in ct60 mchdir).

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

[Freemint-discuss] New driver binary

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

I've just pushed a commit for generating a new RTL8012 driver version
for machines with the 060 CPU, the new driver name is rtl8012ct60.xif.
I guess the new driver path should be added somewhere for the binary
snapshots (Hi Miro ;-) )

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

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

On 20/03/2018 at 21:22, Miro Kropáček wrote:
>     The solution is simple: use *rebase* to integrate pull requests,
>     instead of *merge*.
>
> However this doesn't solve the problem of useless/reworked commits, does
> it? You just get them in a linear fashion.

The contributor can be asked to rework its contribution (by adding new 
commits to his local branch) until the squashed commit is acceptable.
Finally, there will be a single clean commit for the contribution in 
official sources.

Of course, this applies only to relatively small changes.
In case of big feature branches (which are not so common), of course a 
classic merge is preferable.

-- 
Vincent Rivière

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

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

>
> That gives importance to what *really* happened on the contributor's fork:
> when it has been forked, when commits have really been done, or even
> reworked... And usually, that's completely useless.
>
[...]

> The solution is simple: use *rebase* to integrate pull requests, instead
> of *merge*.
>
However this doesn't solve the problem of useless/reworked commits, does
it? You just get them in a linear fashion.

Of course, we could still *merge* the Pull Requests some times, when it
> makes sense, but IMHO this should not be the general solution.

As discussed here: https://github.com/freemint/freemint/issues/26 I'm more
in favour to have a default policy (say, rebase) and if it differs, let the
author to specify how he proposes to include his work. Sometimes the
history is not worth it at all (i.e. squash / classic patch would work
best), sometimes history is worth having as a separate branch.

However Alan seems to be quite in favour of the classic merge commits. And
with him being not so active it's hard to discuss matters like this and
take action. :-/


> Use *rebase* in most case. Otherwise, don't complain about messy history.

Well, in this case (a feature USB branch) the merge issue would stay as one
would certainly prefer to use classic merge.

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

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

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

On 20/03/2018 at 06:47, Miro Kropáček wrote:
> Maybe someone with better git knowledge can explain the finer details?

The following command gives the best view of actual log:

git log --oneline --decorate --graph

You can see all the commits correctly sorted, as well as merged branches 
with ASCII-art. This is the closer view of the reality of the history.

That being said, FreeMiNT history is a mess. This is because Pull 
Requests are *merged*. That gives importance to what *really* happened 
on the contributor's fork: when it has been forked, when commits have 
really been done, or even reworked... And usually, that's completely 
useless.

What is really important, is to take the contributors's patches, and 
include them into official sources (and history). Exactly like when the 
patches were contributed to the mailing list. The solution is simple: 
use *rebase* to integrate pull requests, instead of *merge*. I already 
have advocated that solution to keep a linear history, as before, and 
for clarity. I have applied that to EmuTOS contributions, and it worked 
fine.

Of course, we could still *merge* the Pull Requests some times, when it 
makes sense, but IMHO this should not be the general solution. Use 
*rebase* in most case. Otherwise, don't complain about messy history.

-- 
Vincent Rivière

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

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

Hi David,

But I still don't understand why git sometime shows me Alan's branch
> history and sometimes main branch history.
>
To be completely honest, I don't know the rules either. What I do know is
that if I'm interested in a file's history the way you are and I can't use
my favourite UI tool, I use "git log --first-parent --no-merges" command.
That way I usually get satisfactory results without all that parent/merge
commit crap. If you try it on your two files you'll see it makes much more
sense now.

Maybe someone with better git knowledge can explain the finer details?

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

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

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

Hi Miro, thanks for tanking the time to explain me this so I can understand it.


2018-03-18 6:21 GMT+01:00 Miro Kropáček <mir...@gm...>:
> Hi David,
>
> On 14 March 2018 at 10:32, David Gálvez <dga...@gm...> wrote:
>>
>> 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
>
> That would suck a lot, wouldn't it? Fortunately, that's not the case. The
> commit you're looking for is from Alan's branch. The one you have in mind is
> of course in the main, master, branch all along:
> https://github.com/freemint/freemint/commit/1340007b#diff-dce566b7
>
> Basically it looks like this:
>
> commit1 -> commit2 -> commit3 (master) * -> commit 4 (still in master, your
> changes) -> ... -> merge back from Alan's branch -> ...
>                                                                      ->
> Alan's branch -> Alan's commit 4 -> ... -> Alan's merge from trunk (master,
> "lots of api changes") -> ... -> merge back to master
>
> So you don't care what kind of merges happened in Alan's branch, he can do
> whatever he likes there, only the end result (merging usbtos back to master)
> matters.

But I still don't understand why git sometime shows me Alan's branch
history and sometimes main branch history.

For example for "git log sys/kentry.c" git shows me "commit
1340007b4dd3cd98ee98f2a231df416fcbc6a1e2" from main branch:

commit d1759b9c15f0253ffdbb70ad646d568563fb9e62
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 b86bf7b52f5c8b456654e8c7145d9a98eeb0d80c
Author: Alan Hourihane <al...@fa...>
Date:   Sun Apr 26 16:16:04 2015 +0000

    Export SCSIDRV interface to kentry.
    Contributed by David Galvez.

commit f165a8f240d228cd21396ee149576f59c055aea2
Author: Alan Hourihane <al...@fa...>
Date:   Fri Apr 17 17:04:52 2015 +0000

    Add XHDI driver to kentry structure.
    Contributed by David Gálvez.

commit 1340007b4dd3cd98ee98f2a231df416fcbc6a1e2
Author: Alan Hourihane <al...@fa...>
Date:   Wed Mar 26 21:59:14 2014 +0000

    Add PCI-BIOS functions to kentry.
    Contributed by David Galvez.

commit dce566b718dd03990b378664e5f58bd341a6b198
Author: Alan Hourihane <al...@fa...>
Date:   Wed Mar 26 10:16:36 2014 +0000

    Remove XHDI_MASS_STORAGE_SUPPORT define.
    Contributed by David Galvez.





But for "git log sys/libkern/kernel_module.h" git shows me "commit
72818b654b732896deaa31d9a686a3951b96f71a" from Alan's branch and not
the commit I mentioned above where the file was originally changed in
the main branch:

commit d1759b9c15f0253ffdbb70ad646d568563fb9e62
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 b86bf7b52f5c8b456654e8c7145d9a98eeb0d80c
Author: Alan Hourihane <al...@fa...>
Date:   Sun Apr 26 16:16:04 2015 +0000

    Export SCSIDRV interface to kentry.
    Contributed by David Galvez.

commit 080a0ae516eeb6908e9789a7be5f7a3d068add3c
Author: Alan Hourihane <al...@fa...>
Date:   Sat Apr 18 11:07:18 2015 +0000

    Fix typo in structure's name,
    Contributed by David Gálvez.

commit f165a8f240d228cd21396ee149576f59c055aea2
Author: Alan Hourihane <al...@fa...>
Date:   Fri Apr 17 17:04:52 2015 +0000

    Add XHDI driver to kentry structure.
    Contributed by David Gálvez.

commit 72818b654b732896deaa31d9a686a3951b96f71a
Author: Alan Hourihane <al...@fa...>
Date:   Tue Apr 8 18:33:42 2014 +0000

    Lots of API updates.
    Lots of TOSONLY updates.
    Add USB mouse driver.
    Merge from trunk.

commit c54e4dc1b355d3c81e678b810773a8e214e96ad8
Author: Alan Hourihane <al...@fa...>
Date:   Thu Mar 27 18:38:58 2014 +0000

    Add c_conout

commit e01e106894b1618a49748bf06a9a578f037cc323
Author: Alan Hourihane <al...@fa...>
Date:   Mon Feb 18 23:35:32 2013 +0000

    Add machine dependent module paths.
    Contributed by Miro Kropacek.

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

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

Hi Thorsten,

On 16 March 2018 at 15:50, Thorsten Otto <ad...@th...> wrote:

> Not really trouble, but some strangeness: when looking at commit
>
> https://github.com/freemint/freemint/commit/6794f46ceef4c45ae79c6d306c388f
> 8fece03b74#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.
>

But 6794f46c really is your commit. The merge commit is 147bece9, committed
by Alan:




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

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

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

Hi David,

On 14 March 2018 at 10:32, David Gálvez <dga...@gm...> wrote:

> 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/9d0a0b5701f3421bc9cc61eb352c6c
> edbfaf9d50#diff-ae395915bb2dac4ca2ce7c3217a8d1ab
>
> Now is mixed with some other commits with no relation:
> https://github.com/freemint/freemint/commit/72818b654b732896deaa31d9a686a3
> 951b96f71a#diff-ae395915bb2dac4ca2ce7c3217a8d1ab

That would suck a lot, wouldn't it? Fortunately, that's not the case. The
commit you're looking for is from Alan's branch. The one you have in mind
is of course in the main, master, branch all along:
https://github.com/freemint/freemint/commit/1340007b#diff-dce566b7

Basically it looks like this:

commit1 -> commit2 -> commit3 (master) * -> commit 4 (still in master, your
changes) -> ... -> merge back from Alan's branch -> ...
                                                                     ->
Alan's branch -> Alan's commit 4 -> ... -> Alan's merge from trunk (master,
"lots of api changes") -> ... -> merge back to master

So you don't care what kind of merges happened in Alan's branch, he can do
whatever he likes there, only the end result (merging usbtos back to
master) matters.

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

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