freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] Strange behavior with "git add"

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

>
> Remember that we have also usb*.km modules
>
Oops, you're right. Feel free to change .gitignore to match that too. First
I wanted to do something more elegant (which would include *.km files but
not directories) but since that requires two lines per pattern, I've chosen
the easier way.

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

Re: [Freemint-discuss] Strange behavior with "git add"

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

Hi Miro

2018-02-09 10:22 GMT+01:00 Miro Kropáček <mir...@gm...>:
> Hi David,
>
>> The following paths are ignored by one of your .gitignore files:
>> sys/usb/src.km/ucd
>> sys/usb/src.km/udd
>> Use -f if you really want to add them.
>> fatal: no files added
>>
>> I don't see those paths in .gitignore
>
> Actually this is a bug introduced by git migration. The issue here is this
> entry in .gitignore:
>
> *.km
>
> The intention is clear, it is supposed to ignore xaaes*.km files. Too bad it
> ignores also *.km directories. :)
>
> I've pushed the fix, thanks for spotting this!
>

Remember that we have also usb*.km modules

Re: [Freemint-discuss] Strange behavior with "git add"

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

Hi David,

The following paths are ignored by one of your .gitignore files:
> sys/usb/src.km/ucd
> sys/usb/src.km/udd
> Use -f if you really want to add them.
> fatal: no files added
>
> I don't see those paths in .gitignore

Actually this is a bug introduced by git migration. The issue here is this
entry in .gitignore:

*.km

The intention is clear, it is supposed to ignore xaaes*.km files. Too bad
it ignores also *.km *directories*. :)

I've pushed the fix, thanks for spotting this!

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

[Freemint-discuss] Strange behavior with "git add"

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

Hi!

I got this answer while entering this git command:

$ git add usb/src.km/global.h usb/src.km/hub.c
usb/src.km/ucd/unicorn/sl811-hcd.c
usb/src.km/udd/storage/usb_storage.c usb/src.km/usb.c
The following paths are ignored by one of your .gitignore files:
sys/usb/src.km/ucd
sys/usb/src.km/udd
Use -f if you really want to add them.
fatal: no files added

I don't see those paths in .gitignore, I don't have any other
.gitignore in the repository beside the one at the root directory, and
any .gitignore_global either at my local home directory. Using the
"-f" option as suggested let me add the files but I find the behavior
strange.

Re: [Freemint-discuss] Debugging

[Markus F. <mf...@mu...>]

Am 06.02.2018 um 06:38 schrieb Mark Duckworth:
> I didn't think to try with Emutos which might make all the difference.
> I was using Tos 2.06.  The issue is that reads/writes don't really work
> properly.  I am able to get it to mostly boot to XaAES with the old fast
> fs but when I use newfatfs I get some RWABS error whose specific code I
> can't remember.  I believe it was "attempt to read past end of
> partition".  Which kind of disk mode are you using.  Are you using an
> ACSI or are you using the hybrid SD mode?
I'm using an ACSI image on SD. Can try TOS2.06 when I'm at my MiST next
time (but this might take a while).

Re: [Freemint-discuss] Debugging

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

I didn't think to try with Emutos which might make all the difference.
I was using Tos 2.06.  The issue is that reads/writes don't really work
properly.  I am able to get it to mostly boot to XaAES with the old fast
fs but when I use newfatfs I get some RWABS error whose specific code I
can't remember.  I believe it was "attempt to read past end of
partition".  Which kind of disk mode are you using.  Are you using an
ACSI or are you using the hybrid SD mode?

Thanks,
Mark


On 02/06/2018 12:08 AM, Markus Fröschle wrote:
> I'm wondering what Rwabs() issue we might have on MiST?
> 
> Works for me (EmuTOS 0.9.9 + FreeMiNT latest), mainly. Some issues with
> warm resets (such that 'reboot' doesn't work reliably, but hangs with
> scrambled screen most of the time) but other than that, it's working
> fine, fast (faster than a real Falcon) and pretty stable.
> 
> I'd assume the reboot failure is caused by the MiST core's handling of
> the asynchronous reset and not a FreeMiNT code issue.
> 

Re: [Freemint-discuss] Debugging

[Markus F. <mf...@mu...>]

I'm wondering what Rwabs() issue we might have on MiST?

Works for me (EmuTOS 0.9.9 + FreeMiNT latest), mainly. Some issues with
warm resets (such that 'reboot' doesn't work reliably, but hangs with
scrambled screen most of the time) but other than that, it's working
fine, fast (faster than a real Falcon) and pretty stable.

I'd assume the reboot failure is caused by the MiST core's handling of
the asynchronous reset and not a FreeMiNT code issue.


Am 06.02.2018 um 01:04 schrieb Mark Duckworth:
> Hello all,
>
> I was considering working on the freemint kernel, specifically the RWABS
> issue on MiST.  I was wondering what your preferred way is to debug
> problems... serial console/debugging, turning up the console output
> error level, or what.  And what way do you have to upload new kernelot
> builds quickly.  How would you go about debugging an io issue that
> prevents the filesystem from working (broad strokes here, I'm just
> looking for something to start with).  Is there a way to step debug the
> kernel and view memory?  I guess not as you would need something like a
> BDM cable.
>
> 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

Re: [Freemint-discuss] Debugging

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

On Dienstag, 6. Februar 2018 01:28:00 CET Miro Kropáček wrote:
> I rely mostly on Aranym's /dev/nfstderr device, so in a way, the serial
> console, yes.

When running under Aranym, i prefer the direct output via nf_call(NF_STDERR , 
...) calls. That has the big advantage that the output goes to the terminal 
where you started it, and does not mess up the atari screen in any way.

However, i think that does not help in his case, as he is running MiNT on real 
hardware (even if it is a clone)

Re: [Freemint-discuss] Debugging

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

Hi,

I was wondering what your preferred way is to debug problems...

I rely mostly on Aranym's /dev/nfstderr device, so in a way, the serial
console, yes. Many parts of the kernel offer additional detailed debugging
via #if 0's if needed. So I just usually collect a few MBs of data, look
what's happening, add / remove some outputs and fix the issue if possible.
If you can get to the desktop, it's nicer for real hardware as you can use
TosWin2 for debugging (/dev/xconout2 device).

Oh and often I just let the kernel crash, some kind of really strong
assert. ;-)

This has been usually enough for debugging even such fine grained issues as
this one:
https://github.com/freemint/freemint/issues/40#issuecomment-304434775

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

[Freemint-discuss] Debugging

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

Hello all,

I was considering working on the freemint kernel, specifically the RWABS
issue on MiST.  I was wondering what your preferred way is to debug
problems... serial console/debugging, turning up the console output
error level, or what.  And what way do you have to upload new kernel
builds quickly.  How would you go about debugging an io issue that
prevents the filesystem from working (broad strokes here, I'm just
looking for something to start with).  Is there a way to step debug the
kernel and view memory?  I guess not as you would need something like a
BDM cable.

Thanks,
Mark

Re: [Freemint-discuss] list address in README.md

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

On 28 January 2018 at 22:01, Vincent Rivière <vin...@fr...>
wrote:

> On 28/01/2018 at 06:32, Miro Kropáček wrote:
>
>> That's exactly why it's on github: fork -> edit -> pull request. 100% web
>> gui operations.
>>
>
> In any foreign project, in the File view, look on the right (see
> screenshot).
> There is even a "pen" button to automate the whole "fork / pull request"
> process.

I'll be damned, I had no idea you can do that directly. Thanks!

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

Re: [Freemint-discuss] RPMint

[Jean-François L. <jfl...@sk...>]

On Saturday, 27 January 2018 15:46:49 CET Mark Duckworth wrote:

> or the author of easymint will be able to
> create a new easymint distribution based on rpmint. 

EasyMint is an abandonded project.

Cheers,
JFL
-- 
Jean-François Lemaire

Re: [Freemint-discuss] list address in README.md

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

On 28/01/2018 at 06:32, Miro Kropáček wrote:
> That's exactly why it's on github: fork -> edit -> pull request. 100% web
> gui operations.

In any foreign project, in the File view, look on the right (see screenshot).
There is even a "pen" button to automate the whole "fork / pull request" 
process.

-- 
Vincent Rivière

Re: [Freemint-discuss] list address in README.md

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

2018-01-28 6:32 GMT+01:00 Miro Kropáček <mir...@gm...>:
> That's exactly why it's on github: fork -> edit -> pull request. 100% web
> gui operations.
>
> On 28 January 2018 at 16:30, Paul Wratt <pau...@gm...> wrote:
>>
>> needs updateing
>>

OK, I've just updated it.

Thanks

Re: [Freemint-discuss] list address in README.md

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

That's exactly why it's on github: fork -> edit -> pull request. 100% web
gui operations.

On 28 January 2018 at 16:30, Paul Wratt <pau...@gm...> wrote:

> needs updateing
>
> ------------------------------------------------------------
> ------------------
> 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] list address in README.md

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

needs updateing

Re: [Freemint-discuss] RPMint

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

I'm really glad there is so much positive feedback.  I really thought
people must still be using easymint based systems.

I do not intend to provide any tools for updating kernel or xaaes.  This
is a problem that is common and identical to all mint users whether they
are running an ext2 partition with unix software or not.  Plus there are
so many different potential ways people want to do this that I would
rather not speak to "how" it should be done.

Sparemint/easymint historically will run the same whether you are
running an older or a newer kernel.  So it doesn't make a meaningful
difference to me.  If your unix dir symlinks are populated right, that
is all rpmint really needs.  (/usr, /var, /etc).

Indeed this distro will not provide a mint kernel package at all.  The
booting and boot scripts will handle the unix software portion only (and
can run xaaes or login prompt at the end).

Existing users will be able to install rpmint on top of an existing
sparemint/easymint system, or the author of easymint will be able to
create a new easymint distribution based on rpmint.  Or if time passes
and I am really productive, I will look into the problem.  I think my
goals as they sit now are lofty for the time I generally have available.

I think the need is there for a system boot management application.  It
would show a list of available uniformly built mint kernel/xaaes/driver
packages on the internet (by the ci server for instance) for download
and which ones are installed.  When you choose a different one it would
provision the mint folder, copy the auto prg and make whatever other
changes are required for that config.  It would also copy any custom
xfs/xif and in general tailor the new kernel install to your specific
tastes (cfg's, etc).  A very modest scripting language just to set
everything up.  GEM assist may already be a good candidate for this.  To
me this should be a GEM only app and to me this is complimentary to the
work I'm doing but not part of it.

Thanks,
Mark





On 01/27/2018 02:21 AM, Jean-François Lemaire wrote:

> Speaking of this project, I think it's a great idea and I hope it will reach 
> completion. One query I have is how do you plan on interfacing the RPM distro 
> with the FreeMiNT kernel/AES? EasyMint made things overly complex in that 
> respect and I would hate to have to edit scripts and/or config files just 
> because I'm booting another kernel.
> 
> Cheers,
> JFL
> 

Re: [Freemint-discuss] RPMint

[Jean-François L. <jfl...@sk...>]

On Friday, 26 January 2018 22:52:37 CET Mark Duckworth wrote:
> I actually already created an updater for sparemint called sum.  I think
> this was in C and Windom.  I think that would be a valid basis for
> future tools though it's a very simple interface.  I'll check out
> GEMassist but my worries are the network communications and working with
> the package database, though this could all just be done with other cli
> tools.

I remember using SUM a couple of times back in the day and it worked. Here's 
an announcement you made to refresh your memory ;-)

https://mikro.naprvyraz.sk/mint/200508/msg00044.html

Speaking of this project, I think it's a great idea and I hope it will reach 
completion. One query I have is how do you plan on interfacing the RPM distro 
with the FreeMiNT kernel/AES? EasyMint made things overly complex in that 
respect and I would hate to have to edit scripts and/or config files just 
because I'm booting another kernel.

Cheers,
JFL
-- 
Jean-François Lemaire

Re: [Freemint-discuss] RPMint

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

This sounds great, and nice to see previous work has not gone to waste

Having spec's and patches on github would be a bonus too, and for your
project (server) you could keep a local repo so updates are not bulk
downloads, but you can also pull raw files too

I would ask to find a location on the net to provide alternate/backup
for finalized SRPM/RPM, a location that is going to be around for
years to come, in case for some reason you net/server/app is not
available in the future. This also supports installs not having to do
a  dist-upgrade just to get a usable SRPM/RPM for that install. And it
would support distro mirror in the southern hemisphere (and/or
european mirrors) (mostly for speed)

To that end, github allows binary package releases (placed on a
seperate repo obviously), and sourceforge has php and "project web
space". There is no reason why both GH & SF could not be employed to
support redundancy and assist web frontends.

I support adding cross-build at a later date, at least to the point
where your app is working 100% for native builds, at least then
someone else can work on the cross-build as well (if need be)

To help support native builds and possibly improve speed and resource
use, I have asked on the ARAnyM list re:CLI (non-gui) version of
ARAnyM. I hope that will produce some results too, as it has the
potential to affect gui versions for possible (input) scripting later
on

With this project, someone else would be able to supply a "distro
image" as well, which would be useful for Native AtariST, not just
ARAnyM (esp. on RPi)

Cheers, looking forward to the results

Paul


On 1/26/18, Mark Duckworth <mdu...@at...> wrote:
> In principle I agree with this but in practice I wonder how it would
> work with RPM's opinionated ways.  To generate an SRPM file which is the
> theoretical input to such a project, RPM basically demands the source
> files, patches, and a spec file and the whole thing has to build
> successfully.   If it does, it will create the SRPM along with the final
> package.  The utility there, at least for me, is that if you manage to
> get an SRPM file you've probably assembled it all properly.   Someone
> would upload an SRPM file which contains everything and the autobuilder
> would take it from there.  No doubt we will have libraries that will
> break other packages taht depend on it, so we'll have to have some trial
> mechanism that demands a successful build of dependent packages before
> the new one replaces anything.
>
> It wouldn't be the end of the world to forgo that and instead trust the
> specs that people upload are well tested.  And lets be realistic here,
> there will be very few people actually contributing.  The problem there
> is that there would be a ton of binary content on github.  You know the
> .tar.gz source files for packages.  Not a well advised idea and a git
> pull would slowly get insanely huge.  I think this is what is going on
> with cocoapods which can take a long time to sync.
>
> Alternatively, you could store only patches and specs github and source
> code on rpmint ftp.  The spec could reference the source url on the
> rpmint server (I would insist on having a local copy as we tend to get
> far behind other systems in versions).  This isn't an awful idea as in
> theory the source archive should be the same (and should validate with
> md5 or sha1 sum).  It looks like there are tools that will download
> source from an input spec file.
>
> https://stackoverflow.com/questions/33177450/how-do-i-get-rpmbuild-to-download-all-of-the-sources-for-a-particular-spec
>
> So I can use github to the extent that patches and specs are stored
> there.  The question is, is the purpose of the autobuilder to vet
> people's raw source changes (autobuild on hook from spec/patch commit),
> or is the purpose to submit a well vetted prebuilt SRPM and get back out
> optimized versions for coldfire, 68020 and 68000.  I think the latter is
> for me.
>
>
> On 01/25/2018 05:13 PM, Miro Kropáček wrote:
>>
>>
>
>> What I would recommend here is to open a github repository which would
>> contain package sources and setup git hooks to your server -- that way
>> it's super easy to contribute/fix packages and you can focus solely on
>> the building part & GUI for downloading/searching etc. In fact, this
>> (the need to have an own server if you want to track build dependencies)
>> is the only reason why we already don't have this in FreeMiNT (so you
>> can't push a change to, say, gemlib and get freemint's tools rebuilt).
>
> ------------------------------------------------------------------------------
> 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] RPMint

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

I had originally intended to use my GEMasist to create a quick rpm installer
and updater.

Peter



On Fri, 26 Jan 2018 02:24:45 , Thorsten Otto <ad...@th...> wrote:
> This is a multi-part message in MIME format.
>

On Donnerstag, 25. Januar 2018 18:55:44 CET Mark Duckworth wrote:
> I bought rpmint.com and wanted to announce that I wanted to
> fork/continue on with sparemint as a new name, RPMint.
That sounds great.
> GEM/CLI package installer/updater
cli shouldn't be that difficult, but gem would be very ambitioned.
>Build farm is an M5484LITE board for coldfire, and two aranym instances
>for 68000 and 68020-60.
Uh. Even with aranym-jit, gcc on mint is still quite slow. I prefer to cross-
compile such packages on a linux box.
I'm not sure ether you are aware of it, but i already updated some packages
and made them available on http://tho-otto.de/crossmint.php This are just tar
archives however, not RPMs

Re: [Freemint-discuss] RPMint

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

I'm going to target building on native hardware for now.  I've had a lot
of fun adapting packages to cross building and I know some of them just
don't take well to it at all.  Obviously I know for the most part this
stuff is solved with things like bitbake so I know it's all possible. 
If someone wants to take my work and add cross building, I will support
it and work with it but for now my main interest is building under
aranym (as it's extremely fast for me on my xeon servers).

Thanks,

Mark



On 01/26/2018 09:34 AM, Thorsten Otto wrote:
> On Freitag, 26. Januar 2018 03:27:43 CET Mark Duckworth wrote:
>> RPM does not really support cross compiling in any meaningful way.  At
>> least not the older version we are using.
> I'm not sure which rpm version you intend to use, but in most cases it is just 
> a matter of choosing a different compiler, and adding the corresponding flags 
> to the configure arguments. Both can be done in the spec file, so i don't see 
> a reason why this shouldn't be supported.
>
> For example, attached is a spec file for bzip2. It needs the same patches  i 
> used in my custom build scripts (http://tho-otto.de/download/mint/bzip2-1.0.6-mint.tar.xz)

Re: [Freemint-discuss] RPMint

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

On Freitag, 26. Januar 2018 03:27:43 CET Mark Duckworth wrote:
> RPM does not really support cross compiling in any meaningful way.  At
> least not the older version we are using.

I'm not sure which rpm version you intend to use, but in most cases it is just 
a matter of choosing a different compiler, and adding the corresponding flags 
to the configure arguments. Both can be done in the spec file, so i don't see 
a reason why this shouldn't be supported.

For example, attached is a spec file for bzip2. It needs the same patches  i 
used in my custom build scripts (http://tho-otto.de/download/mint/bzip2-1.0.6-mint.tar.xz)

Re: [Freemint-discuss] RPMint

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

RPM does not really support cross compiling in any meaningful way.  At
least not the older version we are using.

Thanks,
Mark


On 01/25/2018 08:24 PM, Thorsten Otto wrote:
> On Donnerstag, 25. Januar 2018 18:55:44 CET Mark Duckworth wrote:
> 
>> I bought rpmint.com and wanted to announce that I wanted to
> 
>> fork/continue on with sparemint as a new name, RPMint.
> 
>  
> 
> That sounds great.
> 
>  
> 
>> GEM/CLI package installer/updater
> 
>  
> 
> cli shouldn't be that difficult, but gem would be very ambitioned.
> 
>  
> 
>>Build farm is an M5484LITE board for coldfire, and two aranym instances
> 
>>for 68000 and 68020-60.
> 
>  
> 
> Uh. Even with aranym-jit, gcc on mint is still quite slow. I prefer to
> cross-compile such packages on a linux box.
> 
>  
> 
> I'm not sure ether you are aware of it, but i already updated some
> packages and made them available on http://tho-otto.de/crossmint.php
> This are just tar archives however, not RPMs
> 
> 
> 
> ------------------------------------------------------------------------------
> 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] RPMint

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

On Donnerstag, 25. Januar 2018 18:55:44 CET Mark Duckworth wrote:
> I bought rpmint.com and wanted to announce that I wanted to
> fork/continue on with sparemint as a new name, RPMint.

That sounds great.

> GEM/CLI package installer/updater

cli shouldn't be that difficult, but gem would be very ambitioned.

>Build farm is an M5484LITE board for coldfire, and two aranym instances
>for 68000 and 68020-60.

Uh. Even with aranym-jit, gcc on mint is still quite slow. I prefer to cross-
compile such packages on a linux box.

I'm not sure ether you are aware of it, but i already updated some packages 
and made them available on http://tho-otto.de/crossmint.php This are just tar 
archives however, not RPMs

Re: [Freemint-discuss] RPMint

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

On 25/01/2018 at 18:55, Mark Duckworth wrote:
> I bought rpmint.com and wanted to announce that I wanted to fork/continue
> on with sparemint as a new name, RPMint.

Nice project!
Go ahead.

-- 
Vincent Rivière