Hi Erich; Am Mittwoch, 11. März 2015, 14:50:52 schrieb Erich Titl: > Yves > > Am 11.03.2015 um 12:22 schrieb Yves Blusseau: > >> Le 11 mars 2015 à 09:39, Erich Titl <erich.t...@think.ch> a écrit : > >> > >> Hi Yves > >> > >> Am 11.03.2015 um 08:56 schrieb Yves Blusseau: > >> > >> ... > >> > >>>> I guess with your tool we somehow duplicate a git repository to another > >>>> filepath without actually duplicating the data and we should be able to > >>>> point to this partial tree. Is that it? > >>> > >>> With this we can manage all the packages in a git repository, and only > >>> download the files we need. > >>> > >>> For your web site you can use the git store get (without filename) to > >>> download/update all the packages in your document root. So it will > >>> always up2date. If someone generate a new package he only need to push > >>> the new file to the git repository.>> > >> So this tool synchronizes a git repository to a tree. How does it update > >> the tree from git without intervention? How could we use this to build > >> and populate the tree on SF? I don't know if we store kernel, initrd and > >> packages in a git repository on SF. > > > > You can update the tree with a cron for example. > > I don't know how the files are put on SF. If we have ftp or sftp access we > > can mirror a local tree to SF. With git store we can upload all binaries > > you want. > > I don't really want to upload anything (maybe I do). I was under the > impression everything was on sourceforge anyway, just in different > locations and maybe packed. I would rather this to be done on > sourceforge without having to download, reformat, repack, you name it.
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. > There is no kernel, modules, firmware nor initrd/mod available on SF, > just stuffed in tarballs or iso images. We shoud make that selectable too. initrd, initmod and moddb are available, kernel should be added as well as the firmware. Note that the flavours are part of the filename (*-i686,-*-geode), but I hope your script can deal with that one. And if you like, a file .version could be maintained in the stable repo. so the stable repo could look like stable/.version stable/i386/*.lrp (plus kernel-i686, kernel-geode etc) stable/x86_64/*.lrp ... stable/rpi/... You can it access with https as described in other mails. > I tried to get shell access to the account, but it appears I don't have > sufficient privilege to access the packages tree. While you should have shell access, you don't need it IMHO. I haven't used it for years. 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
