Menu
▾
▴
freemint-discuss
|
From: Mark D. <mdu...@at...> - 2018-01-25 17:55:52
|
Hello all, I bought rpmint.com and wanted to announce that I wanted to fork/continue on with sparemint as a new name, RPMint. What I am planning to do is a slight divergence from sparemint but ultimately the same. The goals are: * Auto builder which builds same packages for coldfire, 68020-60 and 68000 * Clean up rpm build dependencies so that autobuild can rebuild everything from scratch without screwing up the dependencies. The purpose being that if a static lib is updated, the entire system can be updated automatically. Backend will facilitate this and will bump up revisions prompting package updates. * Revised init scripts which run a bit faster and leaner - up for debate * Updated packages (many already completed just need to put it all together) * GEM/CLI package installer/updater * Comprehensive website (will be postgresql/c#/mvc running on mono/linux). Will allow package upload, community approval, deployment to auto build servers, searching by file, package info, historical package archive, etc. The autobuilder will also be a C# app that will monitor and control via ssh. * For experienced users or for others to build on... Primary focus on unix cli tools and ports - easymint and other products should take RPMint work and build on it. RPMint is JUST the distro, not an installer or kernel maintenance tools. Kernel will not be a package at all. RPMint is just intended to maintain what is on the ext2 partition traditionally so no xaaes, no kernel, etc. * RPMint will lift and otherwise reuse community work whenever possible. Vincent Riviere's patches, Alan's work with gentoo, etc. I did work on all this before but I lost interest due to a lack of control over sparemint and no interest from sparemint people. Now I have no excuses so we'll see what I can do with it. It's vaporware at the moment but I wanted to put this out there to allow people to comment and offer opinions on how things should go. Ultimately I do not plan to exercise a lot of control over this but just wanted a platform with which to share the ports I've done.. and I prefer RPM. Build farm is an M5484LITE board for coldfire, and two aranym instances for 68000 and 68020-60. Ssh access provided to anyone who wants to work on it, maintain or participate... Or even build their own software. 68000 is no longer really a waste of time due to MonSTer board and MiST if anyone ever figures out the block io issues on that. Thanks, Mark |
|
From: Miro K. <mir...@gm...> - 2018-01-25 22:13:42
|
On 26 January 2018 at 04:55, Mark Duckworth <mdu...@at...> wrote: * Auto builder which builds same packages for coldfire, 68020-60 and 68000 > Sounds great, Mark! > * Clean up rpm build dependencies so that autobuild can rebuild > everything from scratch without screwing up the dependencies. The > purpose being that if a static lib is updated, the entire system can be > updated automatically. Backend will facilitate this and will bump up > revisions prompting package updates. > [..] * Comprehensive website (will be postgresql/c#/mvc running on > mono/linux). Will allow package upload, community approval, deployment > to auto build servers, searching by file, package info, historical > package archive, etc. The autobuilder will also be a C# app that will > monitor and control via ssh. > 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). -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Mark D. <mdu...@at...> - 2018-01-25 22:51:03
|
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). |
|
From: Paul W. <pau...@gm...> - 2018-01-27 01:33:38
|
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 > |
|
From: Vincent R. <vin...@fr...> - 2018-01-25 23:59:25
|
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 |
|
From: Thorsten O. <ad...@th...> - 2018-01-26 01:24:54
|
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 |
|
From: Peter S. <p....@sc...> - 2018-01-26 20:59:34
|
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 |
|
From: Jean-François L. <jfl...@sk...> - 2018-01-27 07:21:44
|
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 |
|
From: Mark D. <mdu...@at...> - 2018-01-27 14:46:58
|
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 > |
|
From: Jean-François L. <jfl...@sk...> - 2018-01-28 12:57:25
|
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 |
|
From: Peter S. <p....@sc...> - 2018-04-23 19:47:23
Attachments:
sparemint_update
|
Hi, Since atariforge isn't accessible I have changed the sparemint-update script I use, for managing RPM's, to download from atari-source instead. I wanted to use github but the old version of wget (1.9.1) we have doesn't support https. Latest is wget is 1.19. Peter |
|
From: Thorsten O. <ad...@th...> - 2018-04-23 20:12:03
|
On Montag, 23. April 2018 21:47:08 CEST Peter Slegg wrote: > I wanted to use github but the old version of wget (1.9.1) we have doesn't > support https I think you should be able to use plain http with github? Another option would be to try curl instead, but i have to admit that i'm not sure whether that version already supports https |
|
From: Peter S. <p....@sc...> - 2018-04-23 20:30:47
|
On Mon, 23 Apr 2018 22:11:44 , Thorsten Otto <ad...@th...> wrote: > On Montag, 23. April 2018 21:47:08 CEST Peter Slegg wrote: >> I wanted to use github but the old version of wget (1.9.1) we have doesn't >> support https > >I think you should be able to use plain http with github? Another option would >be to try curl instead, but i have to admit that i'm not sure whether that >version already supports https I was trying to use the wget option --no-check-certificate but 1.9 doesn't support it. I just discovered wget-ssl in the Sparemint RPMs but that doesn't support the option either. Perhaps wget or wget-ssl could be re-built to the latest stable version ? Peter |
|
From: Thorsten O. <ad...@th...> - 2018-04-23 20:50:14
|
On Montag, 23. April 2018 22:30:37 CEST Peter Slegg wrote: > Perhaps wget or wget-ssl could be re-built to the latest stable version ? IIRC, i already tried, but it needs thread support. Another problem, when you really want to use https, are the crypto libraries needed to decode the stream. |
|
From: Peter S. <p....@sc...> - 2018-04-23 20:53:26
|
On Mon, 23 Apr 2018 22:49:52 , Thorsten Otto <ad...@th...> wrote: > On Montag, 23. April 2018 22:30:37 CEST Peter Slegg wrote: > > Perhaps wget or wget-ssl could be re-built to the latest stable version ? > > IIRC, i already tried, but it needs thread support. Another problem, when you > really want to use https, are the crypto libraries needed to decode the > stream. > I knew the ssl would make it tricky, I was hoping the wget-ssl would be a way in. Peter |
|
From: Mark D. <mdu...@at...> - 2018-01-26 02:27:58
|
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 > |
|
From: Thorsten O. <ad...@th...> - 2018-01-26 14:34:10
Attachments:
bzip2.spec
|
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) |
|
From: Mark D. <mdu...@at...> - 2018-01-26 16:10:22
|
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) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X