Hi Erich; Am Donnerstag, 12. März 2015, 17:02:29 schrieb Erich Titl: > Hi KP > > Am 12.03.2015 um 16:17 schrieb kp kirchdoerfer: > > HI Erich; > > > > Am Mittwoch, 11. März 2015, 19:27:00 schrieb Erich Titl: > >> Am 11.03.2015 um 15:54 schrieb kp kirchdoerfer: > >>> Hi Erich; > >> > >> .. > >> > >>> It is part of the release work to put the files into the git > >>> repositories > >>> (package/5_1 etc), and it's me who does the work currently. > >>> > >>> All archs and packages are rebuild from scratch for a new release, then > >>> the > >>> tarballs will be build and a limited test with qemu is done. > >>> I then upload the tarballs via scp to SF FRS and the builded packages > >>> are > >>> committed into git repo. > >>> > >>>> There is access to the packages on SF, I found that in the meantime. > >>>> Unfortunately it does not really reflect the version as distributed, as > >>>> 5_1 is in reality 5.1.3. This is easy to understand for a human being, > >>>> as we know how to guess. A program or script is bad at guessing. > >>> > >>> Yes it was my decision to name it that way, because it was handy and > >>> worked > >>> for me. It can be changed as needed - but it should be smaller and we > >>> should have an additional repository "stable" for your upgrade script. > >> > >> I don't think so, stable should just be a link to the last stable > >> release, not a duplicate. This link is easy to adapt. > > > > Tried to find info about using symlinking git repos but nothing usable so > > far. So I thought about another idea which doesn't need to bother you. > > Instead of having multiple repos (5.0,5.1, stable) we can just have two > > (stable and latest aka beta). The latest head in stable is the latest > > stable version, the remaining can be done with tagging. As I said not > > really important for you if you just want to download the latest stable > > version for upgrade. > > Well, I don't know why everybody is so keen about gitting everything. > The current area is AFAIK not governed by git, so symlinking should be > possible from the shell access.
> We have a number of version dependent trees right now and I don't know > what relation they have with git. > > see > > http://sourceforge.net/p/leaf/packages/ci/master/tree/5_1/i386/ It seems one of us has a misconception of the SF features we can use. It is my understanding that we only have limited access/space to/on the SF shell, and it's mainly used to install a CMS, but not to use it as space to maintain directories and files like on a ftp server. I found no traces of such a thing in teh SF documentation. So IMHO we do have only the option to use git repos and FRS to make files available from SF. FRS will not fit our needs, so using git repos is a workaround. At least it offers the git server feature to access files via http (wget). Anyone may correct me if I'm wrong. I'd be happy cause I'm not that keen about using git for that purpose as it seems :) > If we could rename this to > > http://sourceforge.net/p/leaf/packages/ci/master/tree/5.1.3/i486/ > > then we would almost be there without sacrifycing anything. > > If we could create a 'stable/version' file which names the stable > release as 5.1.3 that would be sufficient to get to the correct files. > > Package files _should_not_ be processor dependent, maybe X32-X64 > dependent only. > > ... > > >>> And if you like, a file .version could be maintained in the stable repo. > > That wold be useful to name the thing 'stable' should point to. Some > kind of application specific sysmlink :-) > > > ... > > > I know, but I disagree. While I see the pro, I'd like to avoid cluttering > > the SF space and I'd like to keep the release work as simple as possible. > > Pls let's start with a basic thing - if really required it can be > > improved. > This _is_ the basic thing. It is _necessary_ because there is > insufficient space on embedded devices. The only other option I see is a > web process, which can be fed with kernel module names and builds moddb > on the fly for the target machine. You don't want to embed this in upgrade. > > ... > > >> 5.1.4beta..... > > > > I'd like to keep it as much as possible inline with the build environment > > - > > therefor I prefer the approach I proposed. > > Makes no real difference, but keep the naming schemes as in the files, > e.g. the variable parts should match, which means no 5_1 for 5.1.3. > Is it possible to rename the tree? > > >>> You can it access with https as described in other mails. > >> > >> Sure, I will install wget-ssl and see if it performs alike on http to > >> see the compatibility. > > > > Pls test also http - it may work according to SF docs. > > See above... I will first test the http compatibility, but the way I > understand wget that is what the fully blown thing can do http _and_ https. > > I cannot test with sourceforge before the prerequisites are met. I moved > my own tree to match sourceforge's as much as I can. It almost looks > identical now > > have a look at > > http://leaf.think.ch/p/leaf/packages/ci/master/tree/ > > It is almost a perfect match, does not have 5_1 though :-) > and has kernel, initrd modules anf firmware (and version and modules lists). Look for https://sourceforge.net/p/leaf/packages/ci/master/tree/stable/ does that help you? In fact it's 5.1.4-rc1 ( kernel update), but that's what we can do using SF fetaures. If that doesn't fit, we have to think once again of moving stuff away from SF to ?? kp ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
