Re: [leaf-devel] LEAF rebase/merge
Hi Erich, the best is to merge the new-initrd branch into the maint or master. In either case (merge or rebase) you need to resolve the conflicts. There are no other alternative. Yves > Le 14 janv. 2016 à 08:10, Erich Titl a écrit : > > Hi Yves > > KP has asked me to port my stuff from new-initrd to master. I would like > to do that with a minimum of manual intervention, but I am a bit stuck > with the way the LEAF project is built within the git repository. > > The branch new-initrd is branched off tag 5.2.2. In the meantime maint > and master have progressed. Now to me it would be logical to rebase > new-initrd to maint before trying to either merge it to master or > cherrypick the few changes. The thing that puzzles me most is the fact > that some configuration files have changed names in the meantime, which > will make a clean merge impossible. > > I also read that rebasing a published branch is frowned upon. > > What would you suggest to overcome all this? > > Thanks > > Erich -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Kernel patches in openembedded/yocto
Hi all, i'm working on a project that use openembedded/yocto project. It's really great to create a full linux distribution and boot images for any type of processor/architecture. Just for the informations this is how the configs and patches for the kernel are managed: There a directory that correspond to specific patches/configs we want to apply. Example: https://github.com/openembedded/oe-core/tree/master/meta-skeleton/recipes-kernel/linux/linux-yocto-custom First a .config file is create from defconfig if it doesn't exists: https://github.com/openembedded/oe-core/blob/master/meta/classes/kernel.bbclass#L310 Then all the cfg file (from the custom directory) are append to the .config and the patch (also in custom directory) are applied to the source. With this, it use a "default" config file and apply a number of configs/patches for each features needed by specific processor/architecture/board. Regards, Yves -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF upgrade / package repository
Sorry for my intrusion but why don't you use a git clone working dir for the document root of the http server. With that we can change the tree easily, we need only one branch that represent all the versions of the packages that can be download. Also with this the same file in different paths are only download only once. Yves Le 28 mars 2015 à 12:54, Mega a écrit : > > > Am 27.03.2015 um 19:34 schrieb kp kirchdoerfer: >> Am Freitag, 27. März 2015, 17:54:43 schrieb Erich Titl: >>> Am 27.03.2015 um 16:43 schrieb kp kirchdoerfer: Am Freitag, 27. März 2015, 16:22:40 schrieb Erich Titl: > Am 27.03.2015 um 15:53 schrieb kp kirchdoerfer: >> Am Freitag, 27. März 2015, 09:12:04 schrieb Erich Titl: > ... > >> Yes it's effcient with branches.But it's not really efficient with >> binaries, though as discussed that's a workaround for the missing >> ftp/whatever-space. > > To git a file is a file is a file and if a file differs it needs to > somehow record the differences. This is difficult with binary files, as > you cannot really record the differences, but afaik git does not do that > anyway. Yes. I have not yet written this back to sourceforge, as I would like to have some feedback on this aproach. >> >> Just play with it and let's know about your findings. >> Esp stable is a playground, but I hope we can shrink the other repos as >> well later. > > We won't unless we delete old versions. We cannot just store differences > between binaries, that is why we should be restrictive with releases. > > If I look at the packages page with releases > > 3_1 4_0 4_1 4_2 4_3 5_0 5_1 > > then I would think we could easily just keep 4_3 and remove the other > releases from the master branch, as the tarballs keep the same data > anyway. Ok. >>> Would anyone comment on this please. Does anyone have experience with >>> the html interface of git? >> >> Why do you need a html interface? > > Because wget needs it for fetching something using https :-( > That is what the packages page presents. AFAIK https is a feature of the git server. > I will try to see what happens if I make 'stable' a remote branch. Is it > typically immediately accessible? One has to track the branch, but it will make no difference for http access. We now have three branches - master, 5.1.3 and stable see https://sourceforge.net/p/leaf/packages/ci/master/tree/ What's the benefit compared to have a stable directory in master? >>> >>> For the moment just 'gut feeling' . >> >> Argument accepted :)) > > Better one, I can play around without disturbing the existing structure :-) > >> >> >>> I believe it is cleaner to manage a branch, but YMMD. >>> I believe to have different branches for 5.1.3/geode and 5.1.3/i486 >>> would be very efficient to store the corresponding binaries, as they >>> would be shared between the branches. >>> >>> I have a small problem detecting the i386 in an installed release. With >>> the above model we could probably drop this directory. >>> >>> Else could we somehow make all parts ot a running release detectable? >>> >>> I can get the release from initrd.version >>> SALT# cat initrd.version >>> 5.1.3 Rev 1 uClibc 0.9.33.2 >>> >>> I can get a specific release from uname >>> SALT# uname -r >>> 3.10.69-geode >> >>> This is confusing as it is a ALIX >>> SALT# uname -m >>> i586 >>> >>> and this is a WRAP >>> SALT# uname -m >>> i586 >> >>> I cannot detect the i386 anywhere and I have no clue how to find rpi or >>> X86_64 in the running release. I could probably map somehow the >>> processor model to those, but that is not really satisfactory. >> >> The upgrade script has "to know" about our choices. > > Yes I know, but the script is just dumb. It needs to be told and I assume the > user is not knowledgeable either. I want to avoid user intervention to a > maximum. Just buy a stupid Access Point and it knows where to get the latest > version and how to install it. In our case this is a little bit more difficult > >> >> i386/x86_64/arm are the supported architectures (make ARCH=x, when running >> config for the kernel) > > Where can I find this in a running environment? We need an agreement where > the info gets included in a running system so it can be retrieved by software. > >> >> i686/geode/i486/bcmrpi/x86_86 are the kernel archs we choose and name in our >> toolchains - e.g naming the kernel for the raspberry pi 3.10.69-bcmrpi has >> been choosed by myself when building armv6 based support for the rpi. > > OK, so > > geode maps to i386 > i486 maps to i386 > i686 maps to i386 > bcmrpi maps to rpi > X86-64 maps to ? > > Is it really true it has to be that incongruent? > >> >> You can distinguish by uname -r, but we have to
Re: [leaf-devel] how to shrink a repository
Le 26 mars 2015 à 16:32, kp kirchdoerfer a écrit : > Am Dienstag, 24. März 2015, 12:20:35 schrieb Yves Blusseau: >>> Le 23 mars 2015 à 18:36, kp kirchdoerfer a >>> écrit : >>> >>> Hello Yves; >>> >>> Am Montag, 23. März 2015, 18:05:13 schrieb Yves Blusseau: >>>>> Le 23 mars 2015 à 16:35, kp kirchdoerfer >>>>> a >>>>> écrit : >>>>> >>>>> Hi; >>>>> >>>>> Am Montag, 23. März 2015, 12:07:35 schrieb Yves Blusseau: >>>>>>> Le 23 mars 2015 à 09:25, Erich Titl a écrit : >>>>>>> >>>>>>> Hi Yves >>>>>>> >>>>>>> Am 23.03.2015 um 08:56 schrieb Yves Blusseau: >>>>>>> >>>>>>> ... >>>>>>> >>>>>>>> The feature is to clone a repository without downloading all the >>>>>>>> history >>>>>>>> (several GB)> >>>>>>> >>>>>>> OK so you basically remove the history from a git repository. >>>>>> >>>>>> No the history stay intact. Only the binaries are replace with >>>>>> symlinks. >>>>>> >>>>>>>>>> Now with the git-store command you can retrieve any packages you >>>>>>>>>> want >>>>>>>>>> using the transport protocol that was used to clone the >>>>>>>>>> repository.>>> >>>>>>>>> >>>>>>>>> That is all fine, but there is no git-store on the leaf boxes (and I >>>>>>>>> doubt there will ever be). >>>>>>>> >>>>>>>> git-store is only a bash script. The question is: is it good to >>>>>>>> install >>>>>>>> git command on a Leaf platform ?> >>>>>>> >>>>>>> I don't think so, but it is nice to have a repository without the >>>>>>> cruft. >>>>> >>>>> AFAIR git-store requires git? >>>> >>>> Yes >>>> >>>>> Generating a git package should be possible, git seems to have no/few >>>>> requirements, and maybe I'll try to build one in the future. >>>>> >>>>> But for just doing upgrades Erichs idea to use wget should be fine for >>>>> the >>>>> time being. >>>> >>>> Yes. But git-store can be use to maintain the http docroot of the server >>>> that provide the packages. >>>> >>>>>>>>>> See the Readme.txt file for information >>>>>>>>>> (https://sourceforge.net/p/leaf/packages-store/ci/master/tree/Readm >>>>>>>>>> e. >>>>>>>>>> t >>>>>>>>>> xt)>>> >>>>>>>>> >>>>>>>>> Great. What does it do? Is this an interface to git? What is the >>>>>>>>> difference between a git repository and this git-store built >>>>>>>>> repository >>>>>>>>> and why does git not provide the same functionality? >>>>>>>> >>>>>>>> Because git is for storing source file not binaries files. >>>>>>> >>>>>>> Aahhh I always thought so and was surprised there was a git >>>>>>> repository to hold our binary packages. Is this arrangement with >>>>>>> sourceforge by accident? >>>>>> >>>>>> No because it was historic. >>>>> >>>>> And because we have no other place AFAIK. SF does not provide http space >>>>> other than the FRS, which IMHO is worse for storing packages than a gt >>>>> repo. >>>>> >>>>> Anyway; I've dowloaded git-store but I do not understand how to use it. >>>>> I've been able to clone the symlinked repo, but then my understanding >>>>> stopped. >>>> >>>> Just install the git-store command in the path. The best is to clone my >>>> git-store repository on github and do a make install to install the >>>> command >>>> in /usr/bin. >>> >>> Done. >>> >>>>> How do I use it to g
Re: [leaf-devel] how to shrink a repository
> Le 23 mars 2015 à 18:36, kp kirchdoerfer a > écrit : > > Hello Yves; > > Am Montag, 23. März 2015, 18:05:13 schrieb Yves Blusseau: >>> Le 23 mars 2015 à 16:35, kp kirchdoerfer a >>> écrit : >>> >>> Hi; >>> >>> Am Montag, 23. März 2015, 12:07:35 schrieb Yves Blusseau: >>>>> Le 23 mars 2015 à 09:25, Erich Titl a écrit : >>>>> >>>>> Hi Yves >>>>> >>>>> Am 23.03.2015 um 08:56 schrieb Yves Blusseau: >>>>> >>>>> ... >>>>> >>>>>> The feature is to clone a repository without downloading all the >>>>>> history >>>>>> (several GB)> >>>>> >>>>> OK so you basically remove the history from a git repository. >>>> >>>> No the history stay intact. Only the binaries are replace with symlinks. >>>> >>>>>>>> Now with the git-store command you can retrieve any packages you want >>>>>>>> using the transport protocol that was used to clone the >>>>>>>> repository.>>> >>>>>>> >>>>>>> That is all fine, but there is no git-store on the leaf boxes (and I >>>>>>> doubt there will ever be). >>>>>> >>>>>> git-store is only a bash script. The question is: is it good to install >>>>>> git command on a Leaf platform ?> >>>>> >>>>> I don't think so, but it is nice to have a repository without the cruft. >>> >>> AFAIR git-store requires git? >> >> Yes >> >>> Generating a git package should be possible, git seems to have no/few >>> requirements, and maybe I'll try to build one in the future. >>> >>> But for just doing upgrades Erichs idea to use wget should be fine for the >>> time being. >> >> Yes. But git-store can be use to maintain the http docroot of the server >> that provide the packages. >>>>>>>> See the Readme.txt file for information >>>>>>>> (https://sourceforge.net/p/leaf/packages-store/ci/master/tree/Readme. >>>>>>>> t >>>>>>>> xt)>>> >>>>>>> >>>>>>> Great. What does it do? Is this an interface to git? What is the >>>>>>> difference between a git repository and this git-store built >>>>>>> repository >>>>>>> and why does git not provide the same functionality? >>>>>> >>>>>> Because git is for storing source file not binaries files. >>>>> >>>>> Aahhh I always thought so and was surprised there was a git >>>>> repository to hold our binary packages. Is this arrangement with >>>>> sourceforge by accident? >>>> >>>> No because it was historic. >>> >>> And because we have no other place AFAIK. SF does not provide http space >>> other than the FRS, which IMHO is worse for storing packages than a gt >>> repo. >>> >>> Anyway; I've dowloaded git-store but I do not understand how to use it. >>> I've been able to clone the symlinked repo, but then my understanding >>> stopped. >> Just install the git-store command in the path. The best is to clone my >> git-store repository on github and do a make install to install the command >> in /usr/bin. > > Done. > >>> How do I use it to get a package from it, and more important, how can I >>> update a package in the repo, build new directories?? >> >> Go into the directory containing the symlinks and use the command "git store >> get" to retrieve one package. > > I don't get it :( > > leaf-packages-store/stable/i386$ git store get atmtools.lrp > Downloading stable/i386/atmtools.lrp from origin... > > /leaf-packages-store/stable/i386$ ls -al atmtools.lrp > lrwxrwxrwx 1 kapeka kapeka 62 Mär 18 16:23 atmtools.lrp -> ../../.git- > store/data/332dbe80950b69d1b140c4507681ce22396570d3 > > Not what I've expected; what's wrong?? It's OK, the file has been downloaded and the link point now to the true file. > > kp > > >> To add a new file or update one use the "git >> store add" command. >> To push the binaries to the repository use the "git store push&
Re: [leaf-devel] how to shrink a repository
> Le 23 mars 2015 à 16:35, kp kirchdoerfer a > écrit : > > Hi; > > Am Montag, 23. März 2015, 12:07:35 schrieb Yves Blusseau: >>> Le 23 mars 2015 à 09:25, Erich Titl a écrit : >>> >>> Hi Yves >>> >>> Am 23.03.2015 um 08:56 schrieb Yves Blusseau: >>> >>> ... >>> >>>> The feature is to clone a repository without downloading all the history >>>> (several GB)> >>> OK so you basically remove the history from a git repository. >> >> No the history stay intact. Only the binaries are replace with symlinks. >> >>>>>> Now with the git-store command you can retrieve any packages you want >>>>>> using the transport protocol that was used to clone the repository.>>> >>>>> That is all fine, but there is no git-store on the leaf boxes (and I >>>>> doubt there will ever be). >>>> >>>> git-store is only a bash script. The question is: is it good to install >>>> git command on a Leaf platform ?> >>> I don't think so, but it is nice to have a repository without the cruft. > > AFAIR git-store requires git? Yes > > Generating a git package should be possible, git seems to have no/few > requirements, and maybe I'll try to build one in the future. > > But for just doing upgrades Erichs idea to use wget should be fine for the > time > being. Yes. But git-store can be use to maintain the http docroot of the server that provide the packages. >>>>>> See the Readme.txt file for information >>>>>> (https://sourceforge.net/p/leaf/packages-store/ci/master/tree/Readme.t >>>>>> xt)>>> >>>>> Great. What does it do? Is this an interface to git? What is the >>>>> difference between a git repository and this git-store built repository >>>>> and why does git not provide the same functionality? >>>> >>>> Because git is for storing source file not binaries files. >>> >>> Aahhh I always thought so and was surprised there was a git >>> repository to hold our binary packages. Is this arrangement with >>> sourceforge by accident? >> >> No because it was historic. > > And because we have no other place AFAIK. SF does not provide http space > other > than the FRS, which IMHO is worse for storing packages than a gt repo. > > Anyway; I've dowloaded git-store but I do not understand how to use it. > I've been able to clone the symlinked repo, but then my understanding stopped. Just install the git-store command in the path. The best is to clone my git-store repository on github and do a make install to install the command in /usr/bin. > > How do I use it to get a package from it, and more important, how can I > update > a package in the repo, build new directories?? Go into the directory containing the symlinks and use the command "git store get" to retrieve one package. To add a new file or update one use the "git store add" command. To push the binaries to the repository use the "git store push" command. > And finally - it seems not help me to shrink the existing repository on SF. > As I said, I don't bother about history etc. I just want to > a) delete remote directories completly (freeing space) > b) want to shrink the repositories to the bare necessary files aka the latest > versions) > c) looking for a recipe for the future to keep the repository as small as > possible With git store it's easy to see what files are accessible or not in a branch. And with one git command we can remove definitively an old binary from the repository. Regards, Yves -- 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
Re: [leaf-devel] how to shrink a repository
> Le 23 mars 2015 à 09:25, Erich Titl a écrit : > > Hi Yves > > Am 23.03.2015 um 08:56 schrieb Yves Blusseau: >> > ... >> >> The feature is to clone a repository without downloading all the history >> (several GB) > > OK so you basically remove the history from a git repository. No the history stay intact. Only the binaries are replace with symlinks. > >>> >>>> >>>> Now with the git-store command you can retrieve any packages you want >>>> using the transport protocol that was used to clone the repository. >>> >>> That is all fine, but there is no git-store on the leaf boxes (and I >>> doubt there will ever be). >> git-store is only a bash script. The question is: is it good to install git >> command on a Leaf platform ? > > I don't think so, but it is nice to have a repository without the cruft. > >> >>> >>>> See the Readme.txt file for information >>>> (https://sourceforge.net/p/leaf/packages-store/ci/master/tree/Readme.txt) >>> >>> Great. What does it do? Is this an interface to git? What is the >>> difference between a git repository and this git-store built repository >>> and why does git not provide the same functionality? >> Because git is for storing source file not binaries files. > > Aahhh I always thought so and was surprised there was a git > repository to hold our binary packages. Is this arrangement with > sourceforge by accident? No because it was historic. Yves. -- 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
Re: [leaf-devel] how to shrink a repository
> Le 23 mars 2015 à 01:11, Erich Titl a écrit : > > Hi Yves > > Am 18.03.2015 um 14:32 schrieb Yves Blusseau: >> >>> Le 14 mars 2015 à 20:12, kp kirchdoerfer a >>> écrit : >>> >>> Hi Yves; >>> > ... > >> >> i have answer the question in the LEAF upgrade thread :D. >> The best for me, (and it is what i use at work) is to use my git-store >> command to manage the package repository. >> With this you have the profit of versioning the packages and group the >> packages by version/architecture using branches without needed to retrieve >> all the binaries. >> >> I have "transform" your git repository >> https://sourceforge.net/p/leaf/packages/ci/master/tree/ to a "git-store >> repository": https://sourceforge.net/p/leaf/packages-store/ci/master/tree/ >> so you can see the difference between the two. >> >> use git clone git://git.code.sf.net/p/leaf/packages-store >> leaf-packages-store and you will retrieve the tree without the binaries. > > What is this for? What can one do without the content? The feature is to clone a repository without downloading all the history (several GB) > >> >> Now with the git-store command you can retrieve any packages you want using >> the transport protocol that was used to clone the repository. > > That is all fine, but there is no git-store on the leaf boxes (and I > doubt there will ever be). git-store is only a bash script. The question is: is it good to install git command on a Leaf platform ? > >> See the Readme.txt file for information >> (https://sourceforge.net/p/leaf/packages-store/ci/master/tree/Readme.txt) > > Great. What does it do? Is this an interface to git? What is the > difference between a git repository and this git-store built repository > and why does git not provide the same functionality? Because git is for storing source file not binaries files. Regards, Yves -- 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
Re: [leaf-devel] how to shrink a repository
> Le 14 mars 2015 à 20:12, kp kirchdoerfer a > écrit : > > Hi Yves; > > you may have followed the threads about LEAF upgrade... > > Today we do have a package repository with for packages > > https://sourceforge.net/p/leaf/packages/ci/master/tree/ > > The summed packages size is about 300MB; but .git/objects is about 5,6GB. > > I have an idea how I (mis)managed it. > > First question, how can we bring down the repository to a reasonable size? > I don't need any history, previous commits, whatelse - just the latest > commits. > Even those can be removed if you have a better idea how to work with > packages... > Which leads to the second question - how can we provide a repository with > latest/stable/versionx packages and avoid to have it grow that much? > > thx kp Hi KP, i have answer the question in the LEAF upgrade thread :D. The best for me, (and it is what i use at work) is to use my git-store command to manage the package repository. With this you have the profit of versioning the packages and group the packages by version/architecture using branches without needed to retrieve all the binaries. I have "transform" your git repository https://sourceforge.net/p/leaf/packages/ci/master/tree/ to a "git-store repository": https://sourceforge.net/p/leaf/packages-store/ci/master/tree/ so you can see the difference between the two. use git clone git://git.code.sf.net/p/leaf/packages-store leaf-packages-store and you will retrieve the tree without the binaries. Now with the git-store command you can retrieve any packages you want using the transport protocol that was used to clone the repository. See the Readme.txt file for information (https://sourceforge.net/p/leaf/packages-store/ci/master/tree/Readme.txt) Regards, Yves -- 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
Re: [leaf-devel] LEAF Upgrade
Using git to store the packages and using branch to group the packages by version/architecture is really a good thing and it's not dependent to how and where the files are host. But using http to get the packages is a bad thing for me because is dependent of how the http server expose the files/trees. For me it's much better to use git to retrieve the files because it's independent to the host provider and we can use a lot of different transport protocols to retrieve the files (ssh, http, https, rsync, etc...). The problem when using git as a repository for binaries is that if you clone the repository you will download all the files (and all the history) which can be very very huge. Also replacing a package with a new one will not delete the previous files in the repository and it will always become bigger and bigger. This is why i wrote git-store that store only symlinks and not the binaries in commits. So cloning the repository is instantaneous. But the best thing is that the binaries are store in the git repository and the files can be retrieve (using the git command) on demand. Regards, Yves -- 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
Re: [leaf-devel] LEAF Upgrade
> Le 11 mars 2015 à 09:39, Erich Titl 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. Regards, Yves -- 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
Re: [leaf-devel] LEAF Upgrade
> Le 9 mars 2015 à 23:00, Erich Titl a écrit : > > Hi Yves > > please bear with me, I don't get it > > Am 09.03.2015 um 13:03 schrieb Yves Blusseau: >> > ..> >> An example using a local repository (it’s the same for a remote repository) >> >> # Create the repository >> cd /tmp >> git init --bare myrepo.git > > So I just create a new repository > >> git clone /tmp/myrepo.git mycheckout > > and then I clone this repository > >> >> # Clone the repository and commit a text file and a binary >> cd mycheckout >> echo "Nothing" > Readme.txt >> git add Readme.txt > > then I go into the mycheckout...whatever directory and create a file > which I finally add to the files to be tracked. > >> >> mkdir -p 5.1.3/x86_64 > > OK > >> dd if=/dev/urandom of=5.1.3/x86_64/pkg1.lrp bs=1024 count=1024 >> git store add 5.1.3/x86_64/pkg1.lrp > > now what _exactly does this? It's to create a fake package in binary form just for the test. > >> git store push >> >> git commit -a -m "First release" >> git push >> >> # Checkout the repository in another directory >> cd /tmp >> git clone /tmp/myrepo.git mycheckout2 >> cd mycheckout2 >> git store get 5.1.3/x86_64/pkg1.lrp > > That is fine, but what I am looking for is WEB access to the files maybe > held in a git repository, or maybe just symbolic links in a http root > which point to files in a git repository. Right now git is hiding all > versioning information in its internal database, each branch or tag just > looks the same, there is no distinct information outside of git about > versions, releases, branches or whatnot. PLeas take a look at the page > at leaf.think.ch. It is all primitive and it does not point to a git > repository, but basically all is there to access a certain file. > > 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. Yves -- 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
Re: [leaf-devel] LEAF Upgrade
>> Hi all, >> >> just for your information, i have develop a script to store big binaries in >> git repository. >> With this we can have a full filesystem with all the versions like this: >> >> 4.1 >> ├── 4.1/i386 >> │ └── 4.1/i386/pkg2.lrp >> └── 4.1/x86_64 >> ├── 4.1/x86_64/pkg1.lrp >> └── 4.1/x86_64/pkg3.lrp >> 5.1.2 >> ├── 5.1.2/i386 >> └── 5.1.2/x86_64 >> └── 5.1.2/x86_64/pkg5.lrp >> 5.1.3 >> ├── 5.1.3/i386 >> │ ├── 5.1.3/i386/pkg2.lrp >> │ └── 5.1.3/i386/pkg5.lrp >> └── 5.1.3/x86_64 >> └── 5.1.3/x86_64/pkg6.lrp >> >> With just one command we can create the full filesystem locally (git clone >> x) but all the files are only symlinks. So the download is really fast >> and don't require space. >> After that you can download the file you need by just on command. >> As the system use git, if a package is use in different places only one copy >> are store in the repository. > > How would you fetch from such a repository? > >> >> The repository of my script: https://github.com/JrCs/git-store > > A bit complex without comments, what can we achieve with this? An example using a local repository (it’s the same for a remote repository) # Create the repository cd /tmp git init --bare myrepo.git git clone /tmp/myrepo.git mycheckout # Clone the repository and commit a text file and a binary cd mycheckout echo "Nothing" > Readme.txt git add Readme.txt mkdir -p 5.1.3/x86_64 dd if=/dev/urandom of=5.1.3/x86_64/pkg1.lrp bs=1024 count=1024 git store add 5.1.3/x86_64/pkg1.lrp git store push git commit -a -m "First release" git push # Checkout the repository in another directory cd /tmp git clone /tmp/myrepo.git mycheckout2 cd mycheckout2 git store get 5.1.3/x86_64/pkg1.lrp Regards, Yves -- 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
Re: [leaf-devel] LEAF Upgrade
Hi all, just for your information, i have develop a script to store big binaries in git repository. With this we can have a full filesystem with all the versions like this: 4.1 ├── 4.1/i386 │ └── 4.1/i386/pkg2.lrp └── 4.1/x86_64 ├── 4.1/x86_64/pkg1.lrp └── 4.1/x86_64/pkg3.lrp 5.1.2 ├── 5.1.2/i386 └── 5.1.2/x86_64 └── 5.1.2/x86_64/pkg5.lrp 5.1.3 ├── 5.1.3/i386 │ ├── 5.1.3/i386/pkg2.lrp │ └── 5.1.3/i386/pkg5.lrp └── 5.1.3/x86_64 └── 5.1.3/x86_64/pkg6.lrp With just one command we can create the full filesystem locally (git clone x) but all the files are only symlinks. So the download is really fast and don't require space. After that you can download the file you need by just on command. As the system use git, if a package is use in different places only one copy are store in the repository. The repository of my script: https://github.com/JrCs/git-store Regards, Yves -- 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
Re: [leaf-devel] Git rebasing
> Hi Yves > Hi Erich, > I have a question regarding my commit branch which I sync to the repository. > > I would like to rebase this branch to tag 5.1.3 to be able to work with > this release. > > I read about rebase --onto, but to me this does not make sense, since I > did not branch off a tag, but another branch. A branch and a tag are "identical": they point to a specific commit. So you can rebase onto a branch, a tag or a commit. Yves -- 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
Re: [leaf-devel] LEAF Upgrade
> You may have a look into > leaf.zetam.org > > I worked with Yves recently to provide a new and working Packages page there, > > no further decisions made about mocing webpages permamently - any input will > be welcome. > > With the exception of kernels and lwp Packages, Packages are downloadable > from > SF git packages repository. Could be improved if it fits your needs. Perhaps it will be clearer to split i386/x86_64 into 2 distinct pages ? Regards, Yves -- 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
Re: [leaf-devel] wpasupplicant
> Le 8 janv. 2015 à 11:53, Erich Titl a écrit : > > Am 08.01.2015 um 10:57 schrieb Yves Blusseau: >> >>> Le 8 janv. 2015 à 09:53, Erich Titl a écrit : >>> >>> Salut Yves >>> >>> Am 08.01.2015 um 08:46 schrieb Yves Blusseau: >>>> One more thing, was is the branch ‘config’ for ? >>>> If it’s a feature branch it need to be more descriptive. If it’s a branch >>>> that is own by someone else it’s better to name it name-branch. >>> >>> I don't like the fact that leaf has only this old fashoned way of being >>> configured. I created the config branch to to adress a few things not >>> everybody saw necessary to be tackled. Like for any project some small >>> profit always emerges as a side effect. >>> >>> Renaming config IMHO is about as meaningful as renaming master or maint, >>> both these names are as arbitrary as any other, but again, opinions may >>> differ. If there is a way to give config a meaningful name without too >>> much trouble I could not care less. >> >> Ok erich, no problem about the name of the ‘config’ branch. So now what is >> your problem with git ? > > Not really a problem, we are looking for the easiest way to port two > changes to maint, namely > > commit 3ab39e8b8c7fc5635563010f29dd7b9e9ef9cbde > Author: Erich Titl > Date: Tue Dec 9 12:24:44 2014 +0100 > >added libnl3 to wpasuppicant dependencies > > commit f65c46f40394e23fc00c8d36d6cb37831706efc0 > Author: Erich Titl > Date: Mon Dec 8 20:59:28 2014 +0100 > >Added NL80211 driver to wpasupplicant > > I don't know how to move these from the commit branch to maint branch > without messing it up. I could, of course, just redo them in maint. > The best is to create another (temporary) branch that is a copy of the ‘config’ branch: git checkout -b tmp config Then do a rebase and trash all the commits that you doesn’t want to merge: git rebase -i maint Then merge the commit into ‘maint’: git checkout maint git pull —rebase git merge tmp You can then trash the tmp branch: git branch -d tmp You can then rebase the ‘config’ branch from maint so the commits that has been merge into maint will be automatically remove: git checkout config git rebase maint > BTW. what is the best practice to keep a branch in sync, rebase locally > first, then push? Yes, for a topic branch a rebase is often better. So a git pull —rebase is often the right command. Regards, Yves -- 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
Re: [leaf-devel] wpasupplicant
One more thing, was is the branch ‘config’ for ? If it’s a feature branch it need to be more descriptive. If it’s a branch that is own by someone else it’s better to name it name-branch. Regards, Yves -- 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
Re: [leaf-devel] wpasupplicant
Hello all, and happy new year. Cherry picking is not a good solution. If you want to commit only some changes from one branch to another you can use git add -p for example to select the portion of « code » you want to add. You can alse use rebase -i to create specific commits in a branch and only merges that ones into another branch. If you describe exactly the problem i can think about what can be the « best solution ». Regards, Yves > Le 6 janv. 2015 à 18:05, kp kirchdoerfer a > écrit : > > Am Sonntag, 4. Januar 2015, 00:00:57 schrieb Erich Titl: >> Hi >> >> I made a commit to include the nl80211 in the config branch. I don't >> really want to merga all that stuff there into maint as it is not yet >> ready, but having nl80211 instead of wext only in wpasupplicant would be >> fine. >> >> Should I just apply the same to maint or is there a way to include this >> commit >> >> commit f65c46f40394e23fc00c8d36d6cb37831706efc0 >> Author: Erich Titl >> Date: Mon Dec 8 20:59:28 2014 +0100 >> >>Added NL80211 driver to wpasupplicant >> >> into maint? >> >> cheers >> >> Erich > > Hi Erich; > > I hoped Yves will respond with much more experience about git than I have. > > Don't know if it breaks git history etc, but IMHO just commit the change to > maint. > > Looking at your git commits in config branch I'm curious if works as > expected. > AFAIK it's wrong to merge from maint to config and to merge back into maint. > So > we may see problems when merging config as a whole... > > > 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 -- 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
Re: [leaf-devel] commits for 5.1.3
Yes thanks a lot david for the documentation you havec made in the wiki. Regards, Yves Le 27 déc. 2014 à 00:24, kp kirchdoerfer a écrit : > Hi David - nice to see you! > > If you want to see your commits in 5.13, and I bet you will, you have to > commit to the maint branch instead of the master branch. > > maint is for 5.1. > master for 5.2 - based on a new kernel and so on > > kp > btw. interesting reading your new wiki additions -- 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
[leaf-devel] Wifi 802ac card
Hi all, i'm looking for a 802ac wifi card in mini pcie format that was compatible with our leaf kernel. Do you have see something that works ? Regards, Yves -- 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
Re: [leaf-devel] GIT
> mega@leafbuilder:~/leaf/devel/bering-uclibc$ git pull > Password: > remote: Counting objects: 84, done. > remote: Compressing objects: 100% (55/55), done. > remote: Total 55 (delta 34), reused 0 (delta 0) > Unpacking objects: 100% (55/55), done. > Von ssh://git.code.sf.net/p/leaf/bering-uclibc > 693104c..a28abaf maint -> origin/maint > 0fa3dd4..729eff1 master -> origin/master > * [neues Tag] v5.1.2 -> v5.1.2 > > > automatischer Merge von repo/webconf/var/webconf/www/interfaces.css > automatischer Merge von repo/webconf/var/webconf/www/interfaces.cgi > KONFLIKT (Inhalt): Merge-Konflikt in > repo/webconf/var/webconf/www/interfaces.cgi > automatischer Merge von repo/webconf/var/webconf/www/interfaces.blurb > KONFLIKT (Inhalt): Merge-Konflikt in > repo/webconf/var/webconf/www/interfaces.blurb > Automatischer Merge fehlgeschlagen; beheben Sie die Konflikte und > committen Sie dann das Ergebnis. > > Now the big question is, how to handle the conflicts and what the hell > are they? I think the conflicts are because the files are changed in the repository and are not in sync with your local versions. Use git diff to see the differences and resolve the conflicts. Then readd the conflicts files before pushing them. Regards, Yves -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] [leaf:bering-uclibc] [2bdcfd] - Jorge Contreras: Backup symlinks, empty dirs and other improvements
> Le 5 nov. 2014 à 10:56, Erich Titl a écrit : > > HI Yves > > Am 05.11.2014 um 09:48 schrieb Yves Blusseau: >> >>> Le 4 nov. 2014 à 00:26, Erich Titl a écrit : >>> > ... > >> >> Hi all, i don’t know if it can help you but i have write some functions to >> retrieve abspath or relative path from a path. >> You can see the functions in the utils.lib file: >> https://github.com/LEAF-Bering-uClibc/bering-uclibc/blob/master/tools/utils.lib > > I had a look at your library and it appears you had the same idea. > Could you elaborate in your file what the exact functionality of those > helpers are and where they could and should be used. For abspath it’s simple, you pass a path at first argument and on optional frompath. the pass in the first argument can be an absolute path or a relative path (from the frompath argument (pwd if not set)). The result will be an absolute path without .. or . in it and no duplicate / For relpath you pass 2 arguments: a path and a base path of the relative path you want. The result wiil be a relative path from the base path without .. or . in it and no duplicate / Regards, Yves -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] [leaf:bering-uclibc] [2bdcfd] - Jorge Contreras: Backup symlinks, empty dirs and other improvements
> Le 4 nov. 2014 à 00:26, Erich Titl a écrit :
>
> HI Jorge
>
> Am 03.11.2014 um 21:50 schrieb cpu memhd:
>> Hey Erich,
>>
>> Your expand path properly handles the './', and also, another thing I
>> discovered is that with my modified expandpath, it will not always get rid
>> of redundant slashes:
>>
>> my modified expandpath():
>>
>> //foo/bar = /foo/bar
>>
>> but then:
>>
>> /foo = //foo
>>
>> !?
>>
>> Your expandpath seems to do what it's supposed to, but the only exception is
>> that it doesn't retain the slash when $1 is just a slash:
>>
>> `expandpath2 /` = ""
>>
>>
>> Nothing. But you're also saying that my expandpath does that too? I haven't
>> been able to replicate that.
>>
>> Anyhow, if you can keep the slash when just '/' is passed, then that's all
>> that's needed.
>
> That is pretty easy
>
> either
>
> expandpath () {
>case $1 in
>/*) echo $1 | sed 's!//*!/!g' ;;
>*) echo `pwd`/`echo $1 | sed 's!//*!/!g; s!^\./*!!g'`;;
>esac
> }
>
> which always retains a trailing slash
>
> or
>
> expandpath () {
>case $1 in
>/) echo $1 | sed 's!//*!/!g' ;;
>/*) echo $1 | sed 's!//*!/!g; s!/$!!' ;;
>*) echo `pwd`/`echo $1 | sed 's!//*!/!g;
> s!^\./*!!g'` | sed 's!/$!!' ;;
>esac
> }
>
> which only retains it in the case of a single slash.
Hi all, i don’t know if it can help you but i have write some functions to
retrieve abspath or relative path from a path.
You can see the functions in the utils.lib file:
https://github.com/LEAF-Bering-uClibc/bering-uclibc/blob/master/tools/utils.lib
Regards,
Yves
--
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] uboot disturbs the build process
Le 15 oct. 2014 à 22:25, Erich Titl a écrit : > Hi KP > > on 15.10.2014 20:07, kp kirchdoerfer wrote: >> Hi Erich; >> > ... > >> >> I'm pretty shure you can merge, without forcing others to follow your pathes >> - >> otherwise git would be a desaster. > > Igitt Igitt :-) > >> >> Pls show us where your merge fails and I'm shure we can help. > > ath-regdomain is branched off maint > > mega@leafbuilder:~/leaf/devel/bering-uclibc$ git branch > * ath-regdomain > maint > master > > mega@leafbuilder:~/leaf/devel/bering-uclibc$ git status > # On branch ath-regdomain > # Changes not staged for commit: > # (use "git add/rm ..." to update what will be committed) > # (use "git checkout -- ..." to discard changes in working > directory) > # > # deleted:conf/sources.d/uboot.cfg > # > # Untracked files: > # (use "git add ..." to include in what will be committed) > # > # conf/sources.d/uboot.cfg.disabled > no changes added to commit (use "git add" and/or "git commit -a") > > Now that I have deleted conf/sources.d/uboot.cfg what happens to maint. > This change is not committed so does it affect the merge? Use for example the git stash command to temporary "remove" the local change. You can also use 2 branches, the one wirh the modification you made in the code and another one to test the compilation (with uboot disable). When you want to test the compilation merge (or rebase) the other branch into the "compilation branch". > >> >> See also >> "merging maint into master " from 15.01.2013 on leaf-devel to get an idea.. > > Mhhh looked it up, looks even worse than my scenario :-( > > Actually my git repository is error free, I am a bit reluctant to use > Ive's commands as I have no idea what state the repository will be in if > anything fails. > > It would be helpful to know _why_ we need this sequence > > ~/buc5 (master % u=) $ git fetch --all To retrieve all the datas from the remote repository into your local repository > ~/buc5 (master % u=) $ git checkout master ... OK somehow reasonable To change the working branch > ~/buc5 (master % u=) $ git pull --rebase ?? To rebase your local branch from the remote repository (be in sync). Regards, Yves -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] A great project
Le 23 août 2014 à 12:39, Yves Blusseau a écrit : > Hi all, > > if you don't know Yocto (https://www.yoctoproject.org/about) it's a great > project to build custom Linux-based systems for embedded products that > already support a lot of BSP (Board Support Package > : specific board packages). > > Perhaps we can take a lot of informations to build custom kernel for other > architecture like mipsel. > And a good introduction to the yocto project: http://vimeo.com/36450321 Regards, Yves -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] A great project
Hi all, if you don't know Yocto (https://www.yoctoproject.org/about) it's a great project to build custom Linux-based systems for embedded products that already support a lot of BSP (Board Support Package : specific board packages). Perhaps we can take a lot of informations to build custom kernel for other architecture like mipsel. Regards, Yves -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] annex pb after updating distro
Le 17 août 2014 à 15:49, kp kirchdoerfer a écrit : > Hi Yves; > > I've tried to get into annex etc again today. > > As you may have seen I have updated my build host to ubuntu 14.04 and it > seems > something has changed, which breaks annex. > > Running > > annex status > > I get the error: > /opt/leafgit/bering-uclibc/tools/utils.lib: Zeile 174: outp (is not set). > (text translated) I’m trying to fix the issue. Can you try with new version ? Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] moving git branches
Le 10 août 2014 à 12:02, kp kirchdoerfer a écrit : > Hi Yves; > Hi all; > > I remember I failed last time, so I'd like to ask you to do the job :) > > As you may have seen I've added the final 5.1 images to the SF FRS. > > Now that we do have a new major stable release (5.1) - we may move > > maint to maint-5.0 (for evt further fixes) > master to maint - to maintain 5.1 > > New master shall become 5.2 with at least a new longterm kernel and other > changes not backwards compatible with 5.1. > > Yves can you attend that task? Hi, task done: maint -> maint-5.0 master -> maint new master branch with kernel-3.14 merge in it next merge from master Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Git Repository without binaries
Le 10 août 2014 à 11:55, kp kirchdoerfer a écrit : > Hi Yves; > > Am Sonntag, 10. August 2014, 10:21:08 schrieb Yves Blusseau: >> Hi all, >> >> i have clone our leaf repository to github without any binaries in it. So >> the repository has a size of 7MB. You can checkout it with: >> git clone g...@github.com:LEAF-Bering-uClibc/bering-uclibc.git > >> The purpose of this repository is to check and test the tools that is use to >> manage this repository. It's a demo repository so you can made all that you >> want on it. To manage this repository i have create a new tool: >> tools/annex. It's mimic git and it is use to store and retrieve binary >> files from another git repository (without getting all the history). >> >> The best to use the buildtool scripts is like before: >> source the contrib/buildtool-completion.bash script >> source the contrib/tools-wrappers script >> >> The best is to add lines like this in your $HOME/.bashrc file: >> >> source leaf_workingdir/contrib/buildtool-completion.bash >> source leaf_workingdir/contrib/tools-wrappers >> >> with leaf_workingdir is your working directory. >> >> With that you have bash completion in buildtool commands (buildtool, >> buildpacket, buildimage, annex). Also you can call the scripts anywhere >> without specifying the path, and you don't have to add sudo/fakeroot in >> front of script like buildpacket. >> >> The "alias" for the commands are: >> buildtool for buildtool.pl >> buildpacket for buildpacket.pl >> buildimage for buildimage.pl >> annex for tools/annex > > Except running from the working dir I see > > #:/opt/buildtool-annex$ annex > No tools/annex script in this worktree ! > > #:/opt/buildtool-annex$ buildtool > No buildtool script in this worktree ! > > and so on. > > Is that expected? > Yes if you are not in a working directory that is a clone of the github repository. > >> About the annex tool you can see a little introduction in the wiki: >> https://github.com/LEAF-Bering-uClibc/bering-uclibc/wiki/Annex-tool >> >> About the migration from old symlink files and the new system is really >> easy: just change the Server key in buildtool.cfg files from localrepo to >> leaf-storage. Example: >>Server = localrepo >>Directory = toolchain >>envname = GCC_SOURCE >> >> >> become >> >> >>Server = leaf-storage >>Directory = toolchain >>envname = GCC_SOURCE >> >> >> The binary files are retrieve directly in the repo/package directory like >> where they are before. Also a symlink is create between the source >> directory and the package repo directory during the buildtool source phase >> like before. > > I branched the repo and started building the toolchain. > Downloading gcc etc went fine. > > > I've read through the REAME for annex. > > So the workflow to add a new version of foo.lrp will be: > > change repo/foo/buildtool.* > eventually add /repo/foo/somepatch.file > add new source foo.2.gz > > build and run test - if everything is ok: > > git commit repo/foo/buildtool.* > git add | commit repo/foo/somepatch.file > You need to commit the local storage "database" file with the annex command before commiting with git because the .annex and .gitignore files must be commited too. > git merge branch with master | next > > annex rm repo/foo.1.gz > annex add repo/foo.2.gz > annex commit > annex push Yes but use this commands before commiting in git > > Can I access the remote storage directly? > No because there are no commit in the remote repository. Only blob. But you can see waht the remote storage contain with the command: annex ls --remote > And last question - any idea how to create the complete Bering- > uClibc_X.x_nn_src.tgz? Easy, do: annex cleanup annex get --all Then do exactly what you do before for creating the uClibc_X.x_nn_src.tgz file > > Is there a local cache? Yes of course, the file is download once. If you don't use the git gc command (garbage collector) the file will stay in cache. > When prepapring a release I run builds for every toolchain from scratch. > Downloading all sources from remote storage will for shure increase build > time. Try and you see you'll never download a file twice. > >> To finish, can you play with it so we can switch to a clean repository >> without binaries if everyone is okay. > > I'll shurely will test it... > building toolchain and a few packages went fine in the meantime :) > :) > >> To have write access to the github repository can you create a github >> account and give me your logging so i can add you to the project. > > I assume, I do have write access right now? Yes you are already an admin. Regards, Yves -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Git Repository without binaries
Hi all, i have clone our leaf repository to github without any binaries in it. So the repository has a size of 7MB. You can checkout it with: git clone g...@github.com:LEAF-Bering-uClibc/bering-uclibc.git The purpose of this repository is to check and test the tools that is use to manage this repository. It's a demo repository so you can made all that you want on it. To manage this repository i have create a new tool: tools/annex. It's mimic git and it is use to store and retrieve binary files from another git repository (without getting all the history). The best to use the buildtool scripts is like before: source the contrib/buildtool-completion.bash script source the contrib/tools-wrappers script The best is to add lines like this in your $HOME/.bashrc file: source leaf_workingdir/contrib/buildtool-completion.bash source leaf_workingdir/contrib/tools-wrappers with leaf_workingdir is your working directory. With that you have bash completion in buildtool commands (buildtool, buildpacket, buildimage, annex). Also you can call the scripts anywhere without specifying the path, and you don't have to add sudo/fakeroot in front of script like buildpacket. The "alias" for the commands are: buildtool for buildtool.pl buildpacket for buildpacket.pl buildimage for buildimage.pl annex for tools/annex About the annex tool you can see a little introduction in the wiki: https://github.com/LEAF-Bering-uClibc/bering-uclibc/wiki/Annex-tool About the migration from old symlink files and the new system is really easy: just change the Server key in buildtool.cfg files from localrepo to leaf-storage. Example: Server = localrepo Directory = toolchain envname = GCC_SOURCE become Server = leaf-storage Directory = toolchain envname = GCC_SOURCE The binary files are retrieve directly in the repo/package directory like where they are before. Also a symlink is create between the source directory and the package repo directory during the buildtool source phase like before. To finish, can you play with it so we can switch to a clean repository without binaries if everyone is okay. To have write access to the github repository can you create a github account and give me your logging so i can add you to the project. Regards, Yves -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Misused of next branch
Le 5 août 2014 à 17:13, kp kirchdoerfer a écrit : > Am Mittwoch, 30. Juli 2014, 23:47:16 schrieb Yves Blusseau: >> Le 30 juil. 2014 à 17:48, kp kirchdoerfer a > écrit : >>> Am Dienstag, 29. Juli 2014, 18:17:56 schrieb Yves Blusseau: >>>> Hi all, >>>> >>>> i think you are misusing the next branch. >>>> The next branch is not use to be the next branch for the next release. As >>>> the git workflow guide said (http://goo.gl/BOzkap) the next branch is >>>> intended as a testing branch for topics being tested for stability for >>>> master. So the next branch is used to test topic/features branch for the >>>> next release. >>>> >>>> In our case i see this commits that are in next but not in master: >>>> $ git log origin/master..origin/next --no-merges >>>> commit 01bd68d1c78dd3695bf841449e9876932e6d5c84 >>>> Author: Andrew Denisenko >>>> Date: Tue Jul 29 10:40:55 2014 >>>> >>>> linux: disable RPI patch >>>> >>>> it fails on 3.14.13 >>>> >>>> commit 78cd8b09fdc563366d36aa5aff962c6d0bc655fb >>>> Author: Andrew Denisenko >>>> Date: Tue Jul 29 10:40:24 2014 >>>> >>>> linux: update connmark patch >>>> >>>> commit ec13e4f0fdba26b9ef5a7bbda339b689fdd26b49 >>>> Author: Andrew Denisenko >>>> Date: Tue Jul 29 10:35:07 2014 >>>> >>>> iptables: fix ipt_netflow >>>> >>>> commit e17d2ee03de21a945f3d8b47a5df85f854752572 >>>> Author: Andrew Denisenko >>>> Date: Mon Jul 28 22:04:18 2014 >>>> >>>> Revert "iptables remove ipt_netflow" >>>> >>>> This reverts commit 0e53bbadb540bf3a00a73524b4d48d64c977446b. >>>> >>>> commit 0e53bbadb540bf3a00a73524b4d48d64c977446b >>>> Author: kapeka >>>> Date: Mon Jul 28 20:53:06 2014 >>>> >>>> iptables remove ipt_netflow >>>> >>>> - it fails to compile and therefor iptables does not build, and >>>> >>>> consequently kmodules will not packaged. - the latest sources on SF >>>> claims >>>> that it is only supported until kernel 3.11 >>>> >>>> So remove it for now. >>>> >>>> commit 140ee0a0bcb280b1a07d98460125cd1523a603ba >>>> Author: kapeka >>>> Date: Mon Jul 28 20:47:19 2014 >>>> >>>> update kernel to 3.14.13 >>>> >>>> kernel 3.14 is the latest longtermn stable kernel, so it might be a >>>> good >>>> >>>> base for 5.2 >>>> >>>> - PLEASE review the kernel configs! >>>> >>>> Note: only the i486, i686 and geode kernel has been updated, x86_64 >>>> and >>>> >>>> arm* toolchain will fail because the patches are still on 3.10. >>>> >>>> Anyway I have up and running a 3.14.13 router (geode) for a while, so >>>> >>>> those updated seems looking fine. >>>> >>>> commit 27cafd2bbefef872a730d5321664d417be5beb19 >>>> Author: kapeka >>>> Date: Sun Jul 27 18:36:48 2014 >>>> >>>> toolchain add modified buildfiles >>>> >>>> commit 2c1e59762c62396e9a7f22c54e39c15e71abcac7 >>>> Author: kapeka >>>> Date: Sun Jul 27 18:30:35 2014 >>>> >>>> clean toolchain from unnesseray patches >>>> >>>> add linux-headers in xz format to save some space >>>> >>>> Note: this are the headers from kernel 3.14.13 >>>> >>>> commit 0db9f10fda5c357e168f9ce06d86447011a5b4af >>>> Author: kapeka >>>> Date: Sat Aug 3 14:53:30 2013 >>>> >>>> copy uuid/uuid.h into staging >>>> >>>> Most of this commits are for the new kernel 3.14.13. >>>> So i think we must create a new topic branch: kernel-3.14.13 (rewriting >>>> history to squash the commits about the ipt_netflow) For the commit >>>> 0db9f10fda5c357e168f9ce06d86447011a5b4af perhaps it can be cherry-pick on >>>> master ? >>>> >>>> Is it's ok for you i can made the job. >>> >>> Hi Yves, hi all, >>> >>> it was me who started the confusion... >>> >>> After Andrews revert a
Re: [leaf-devel] Another router
But for network performance the Ubiquiti EdgeRouter Lite is much better. Regards, Yves Le 3 août 2014 à 12:43, Andrew a écrit : > Hi. > > It seems to be a bit expensive. There are cheaper TPLink > TL-WDR3500/TL-WDR3600 routers, with 128M RAM and 8M flash + USB, IMHO > enough powerful routers, and there are a lot of cheap routers with USB > like DLink DIR-320/NRU and TPLink TL-MR3220 (usually 4M flash/32M ROM). > All of them has OpenWRT support, so it's not so hard to run LEAF on them. > > But for running we need to have some mods to intrd logic. It'll be good > to move all basic system (etc.lrp, modules.lrp and so on - they are > changed non-frequently) into ramdisk, make ramdisk as squashfs for > embedded platforms, and use mounted squashfs + tmpfs over it (merged > with unionfs/aufs) as r/w root. This can help to save some MBs of > valuable RAM (especially on cheap platforms with 32M RAM). Rest of flash > will remain as JFFS2 r/w filesystem for configs/packages/modules. > > 03.08.2014 13:18, Yves Blusseau ?: >> Hi all, >> >> i have found this router: http://www.ubnt.com/edgemax/edgerouter-lite >> * >> http://www.smallnetbuilder.com/lanwan/lanwan-reviews/32012-first-look-ubiquiti-edgerouter-lite >> >> It's seems we can put a freebsd or linux on it: >> - http://rtfm.net/FreeBSD/ERL/ >> - http://wiki.gentoo.org/wiki/MIPS/ERLite-3 >> >> It can be a great plateform for bering-uClibc. The disadvantages is it has a >> mips CPU and need a specific toolchain to build >> >> Regards, >> Yves >> >> >> -- >> Want fast and easy access to all the code in your enterprise? Index and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight - the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> >> >> ___ >> leaf-devel mailing list >> leaf-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/leaf-devel > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > > ___ > leaf-devel mailing list > leaf-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-devel -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Another router
Hi all, i have found this router: http://www.ubnt.com/edgemax/edgerouter-lite * http://www.smallnetbuilder.com/lanwan/lanwan-reviews/32012-first-look-ubiquiti-edgerouter-lite It's seems we can put a freebsd or linux on it: - http://rtfm.net/FreeBSD/ERL/ - http://wiki.gentoo.org/wiki/MIPS/ERLite-3 It can be a great plateform for bering-uClibc. The disadvantages is it has a mips CPU and need a specific toolchain to build Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Master not fully merge with maint
Le 2 août 2014 à 19:02, Yves Blusseau a écrit : > Hi all, > > it's seems that commits from maint has not be fully merge into master: > > Performing inexact rename detection: 100% (14352/14352), done. > Auto-merging repo/linux/buildtool.cfg > CONFLICT (content): Merge conflict in repo/linux/buildtool.cfg > CONFLICT (rename/delete): repo/linux/Bering-3.4.101.config-x86_64.patch > deleted in HEAD and renamed in maint. Version maint of > repo/linux/Bering-3.4.101.config-x86_64.patch left in tree. > CONFLICT (rename/delete): repo/linux/Bering-3.4.101.config-i686.patch deleted > in HEAD and renamed in maint. Version maint of > repo/linux/Bering-3.4.101.config-i686.patch left in tree. > CONFLICT (rename/delete): repo/linux/Bering-3.4.101.config-i486.patch deleted > in HEAD and renamed in maint. Version maint of > repo/linux/Bering-3.4.101.config-i486.patch left in tree. > CONFLICT (rename/delete): repo/linux/Bering-3.4.101.config-geode.patch > deleted in HEAD and renamed in maint. Version maint of > repo/linux/Bering-3.4.101.config-geode.patch left in tree. > CONFLICT (rename/rename): Rename > "repo/linux/Bering-3.4.100.config-versatile.patch"->"repo/linux/Bering-3.10.49.config-versatile.patch" > in branch "HEAD" rename > "repo/linux/Bering-3.4.100.config-versatile.patch"->"repo/linux/Bering-3.4.101.config-versatile.patch" > in "maint" > CONFLICT (rename/rename): Rename > "repo/linux/Bering-3.4.100.config"->"repo/linux/Bering-3.10.49.config" in > branch "HEAD" rename > "repo/linux/Bering-3.4.100.config"->"repo/linux/Bering-3.4.101.config" in > "maint" > Recorded preimage for 'repo/linux/buildtool.cfg' > Automatic merge failed; fix conflicts and then commit the result. > > KP it's seems that is you that update the kernel in maint to 3.4.101. So can > you merge the change into master ? I have done the merge. Regards, Yves -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Master not fully merge with maint
Hi all, it's seems that commits from maint has not be fully merge into master: Performing inexact rename detection: 100% (14352/14352), done. Auto-merging repo/linux/buildtool.cfg CONFLICT (content): Merge conflict in repo/linux/buildtool.cfg CONFLICT (rename/delete): repo/linux/Bering-3.4.101.config-x86_64.patch deleted in HEAD and renamed in maint. Version maint of repo/linux/Bering-3.4.101.config-x86_64.patch left in tree. CONFLICT (rename/delete): repo/linux/Bering-3.4.101.config-i686.patch deleted in HEAD and renamed in maint. Version maint of repo/linux/Bering-3.4.101.config-i686.patch left in tree. CONFLICT (rename/delete): repo/linux/Bering-3.4.101.config-i486.patch deleted in HEAD and renamed in maint. Version maint of repo/linux/Bering-3.4.101.config-i486.patch left in tree. CONFLICT (rename/delete): repo/linux/Bering-3.4.101.config-geode.patch deleted in HEAD and renamed in maint. Version maint of repo/linux/Bering-3.4.101.config-geode.patch left in tree. CONFLICT (rename/rename): Rename "repo/linux/Bering-3.4.100.config-versatile.patch"->"repo/linux/Bering-3.10.49.config-versatile.patch" in branch "HEAD" rename "repo/linux/Bering-3.4.100.config-versatile.patch"->"repo/linux/Bering-3.4.101.config-versatile.patch" in "maint" CONFLICT (rename/rename): Rename "repo/linux/Bering-3.4.100.config"->"repo/linux/Bering-3.10.49.config" in branch "HEAD" rename "repo/linux/Bering-3.4.100.config"->"repo/linux/Bering-3.4.101.config" in "maint" Recorded preimage for 'repo/linux/buildtool.cfg' Automatic merge failed; fix conflicts and then commit the result. KP it's seems that is you that update the kernel in maint to 3.4.101. So can you merge the change into master ? Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] buildpacket in branch maint
Le 2 août 2014 à 16:14, kp kirchdoerfer a écrit : > Am Samstag, 2. August 2014, 15:12:46 schrieb Yves Blusseau: >> Le 1 août 2014 à 17:11, kp kirchdoerfer a > écrit : >>> Hi Yves; >>> >>> can you pls check your latest commit of buildpackert.pl in branch maint. >>> >>> I ran buildall and generated images, butthey fail to start with a kernel >>> panic (no init found) - replacing builpacket.pl from the tagged >>> v5.0.5-rc1 cures the problem. >>> I beleive something went wrong. >> >> Don't see where the problem can be. I only force ownership and permission on >> .lrp files. Is the initrd file correctly built ? >> We need to find why the kernel panic with no init found… > > > It's a permssion problem: > > -rw-rw-r-- var/lib/lrpkg/root.linuxrc > > root.linuxrc must be executable. Humm, very strange. I don't see this bug because i'm running buildpacket.pl with fakeroot (and you must be using sudo instead of fakeroot), and with fakeroot the permission of files are not changed. I don't know why … > Although buildpacket uses the permisson settings found in buildtool.cfg (755) > it seems it's overwritten later with 664. > > I noted that > > Generating lrpkg files > Generating package conf file > Generating package help > Generating package version file > Generating package local file > Generating package local file > > is run after setting the permissions, instead before as before your change I have commit a fix that change permission only for .help, .version, .modules, .local, .license, .deplrp files. Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] buildpacket in branch maint
Le 1 août 2014 à 17:11, kp kirchdoerfer a écrit : > Hi Yves; > > can you pls check your latest commit of buildpackert.pl in branch maint. > > I ran buildall and generated images, butthey fail to start with a kernel > panic > (no init found) - replacing builpacket.pl from the tagged v5.0.5-rc1 cures > the > problem. > I beleive something went wrong. Don't see where the problem can be. I only force ownership and permission on .lrp files. Is the initrd file correctly built ? We need to find why the kernel panic with no init found… Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Git cleanup
Hi all, are you ok to remove old prelease tags like: v4.2.1-beta1, v5.0-alpha, v5.0.2-rc3, …. ? keeping only stable release tags. Regards, Yves -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Misused of next branch
Le 30 juil. 2014 à 17:48, kp kirchdoerfer a écrit : > Am Dienstag, 29. Juli 2014, 18:17:56 schrieb Yves Blusseau: >> Hi all, >> >> i think you are misusing the next branch. >> The next branch is not use to be the next branch for the next release. As >> the git workflow guide said (http://goo.gl/BOzkap) the next branch is >> intended as a testing branch for topics being tested for stability for >> master. So the next branch is used to test topic/features branch for the >> next release. >> >> In our case i see this commits that are in next but not in master: >> $ git log origin/master..origin/next --no-merges >> commit 01bd68d1c78dd3695bf841449e9876932e6d5c84 >> Author: Andrew Denisenko >> Date: Tue Jul 29 10:40:55 2014 >> >>linux: disable RPI patch >> >>it fails on 3.14.13 >> >> commit 78cd8b09fdc563366d36aa5aff962c6d0bc655fb >> Author: Andrew Denisenko >> Date: Tue Jul 29 10:40:24 2014 >> >>linux: update connmark patch >> >> commit ec13e4f0fdba26b9ef5a7bbda339b689fdd26b49 >> Author: Andrew Denisenko >> Date: Tue Jul 29 10:35:07 2014 >> >>iptables: fix ipt_netflow >> >> commit e17d2ee03de21a945f3d8b47a5df85f854752572 >> Author: Andrew Denisenko >> Date: Mon Jul 28 22:04:18 2014 >> >>Revert "iptables remove ipt_netflow" >> >>This reverts commit 0e53bbadb540bf3a00a73524b4d48d64c977446b. >> >> commit 0e53bbadb540bf3a00a73524b4d48d64c977446b >> Author: kapeka >> Date: Mon Jul 28 20:53:06 2014 >> >>iptables remove ipt_netflow >> >>- it fails to compile and therefor iptables does not build, and >> consequently kmodules will not packaged. - the latest sources on SF claims >> that it is only supported until kernel 3.11 >> >>So remove it for now. >> >> commit 140ee0a0bcb280b1a07d98460125cd1523a603ba >> Author: kapeka >> Date: Mon Jul 28 20:47:19 2014 >> >>update kernel to 3.14.13 >> >>kernel 3.14 is the latest longtermn stable kernel, so it might be a good >> base for 5.2 >> >>- PLEASE review the kernel configs! >> >>Note: only the i486, i686 and geode kernel has been updated, x86_64 and >> arm* toolchain will fail because the patches are still on 3.10. >>Anyway I have up and running a 3.14.13 router (geode) for a while, so >> those updated seems looking fine. >> >> commit 27cafd2bbefef872a730d5321664d417be5beb19 >> Author: kapeka >> Date: Sun Jul 27 18:36:48 2014 >> >>toolchain add modified buildfiles >> >> commit 2c1e59762c62396e9a7f22c54e39c15e71abcac7 >> Author: kapeka >> Date: Sun Jul 27 18:30:35 2014 >> >>clean toolchain from unnesseray patches >> >>add linux-headers in xz format to save some space >> >>Note: this are the headers from kernel 3.14.13 >> >> commit 0db9f10fda5c357e168f9ce06d86447011a5b4af >> Author: kapeka >> Date: Sat Aug 3 14:53:30 2013 >> >>copy uuid/uuid.h into staging >> >> Most of this commits are for the new kernel 3.14.13. >> So i think we must create a new topic branch: kernel-3.14.13 (rewriting >> history to squash the commits about the ipt_netflow) For the commit >> 0db9f10fda5c357e168f9ce06d86447011a5b4af perhaps it can be cherry-pick on >> master ? >> >> Is it's ok for you i can made the job. > > Hi Yves, hi all, > > it was me who started the confusion... > > After Andrews revert and running > `git reset --hard origin/next` on next branch > > > I still have a "mixed setup" - next still has a 3.14 kernel > So if you can clean it up for me, pls do! > > Anyway, I have been misleaded by the workflow description: > > " maint tracks the commits that should go into the next "maintenance > release", i.e., update of the last released stable version; > > master tracks the commits that should go into the next release; > > next is intended as a testing branch for topics being tested for stability > for > master." > > - "maint tracks the commits that should go into the next "maintenance > release", i.e., update of the last released stable version;" > > This one seems clear to me - it's where we maintain last stable release, the > one we've put in maintenance mode until master becomes stable > > - "master tracks the commits that should go into the next release;" > > Again clear to me - stuff w
Re: [leaf-devel] Misused of next branch
Le 29 juil. 2014 à 21:35, Andrew a écrit : > Fixed. I've cherry-picked significant commits into kernel-3.14, and > forced next branch to point at current master branch. > > For all, you need to do `git reset --hard origin/next` on next branch, > if it is in your local repo. Thanks andrew. In the kernel-3.14 branch you remove the commit 0db9f10f of kapeka: commit 0db9f10fda5c357e168f9ce06d86447011a5b4af Author: kapeka Date: Sat Aug 3 14:53:30 2013 copy uuid/uuid.h into staging Is this commit needed ? If yes perhaps it can be include in the current master branch ? About other branch, is the kernel34-branch still valid ? Regards, Yves -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Misused of next branch
Le 29 juil. 2014 à 20:21, Erich Titl a écrit : > Hi Yves > > at 29.07.2014 18:17, Yves Blusseau wrote: >> Hi all, >> >> i think you are misusing the next branch. >> The next branch is not use to be the next branch for the next release. As >> the git workflow guide said (http://goo.gl/BOzkap) the next branch is >> intended as a testing branch for topics being tested for stability for >> master. >> So the next branch is used to test topic/features branch for the next >> release. > > Why not just commit new stuff to master and branch away every major > release instead? Is that against some GIT convention? It's our convention (that is in our git workflow guide). It's not good to commit directly to master for big changes that can add a regression. The master branch must be stable. So to add new features, fork a topic branch from master (or maint, …) and develop in it. Then to test merge your branch into next to see if it work with all other topic branches. The next branch is an unstable branch (like pu branch). Regards, Yves -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Misused of next branch
Hi all, i think you are misusing the next branch. The next branch is not use to be the next branch for the next release. As the git workflow guide said (http://goo.gl/BOzkap) the next branch is intended as a testing branch for topics being tested for stability for master. So the next branch is used to test topic/features branch for the next release. In our case i see this commits that are in next but not in master: $ git log origin/master..origin/next --no-merges commit 01bd68d1c78dd3695bf841449e9876932e6d5c84 Author: Andrew Denisenko Date: Tue Jul 29 10:40:55 2014 linux: disable RPI patch it fails on 3.14.13 commit 78cd8b09fdc563366d36aa5aff962c6d0bc655fb Author: Andrew Denisenko Date: Tue Jul 29 10:40:24 2014 linux: update connmark patch commit ec13e4f0fdba26b9ef5a7bbda339b689fdd26b49 Author: Andrew Denisenko Date: Tue Jul 29 10:35:07 2014 iptables: fix ipt_netflow commit e17d2ee03de21a945f3d8b47a5df85f854752572 Author: Andrew Denisenko Date: Mon Jul 28 22:04:18 2014 Revert "iptables remove ipt_netflow" This reverts commit 0e53bbadb540bf3a00a73524b4d48d64c977446b. commit 0e53bbadb540bf3a00a73524b4d48d64c977446b Author: kapeka Date: Mon Jul 28 20:53:06 2014 iptables remove ipt_netflow - it fails to compile and therefor iptables does not build, and consequently kmodules will not packaged. - the latest sources on SF claims that it is only supported until kernel 3.11 So remove it for now. commit 140ee0a0bcb280b1a07d98460125cd1523a603ba Author: kapeka Date: Mon Jul 28 20:47:19 2014 update kernel to 3.14.13 kernel 3.14 is the latest longtermn stable kernel, so it might be a good base for 5.2 - PLEASE review the kernel configs! Note: only the i486, i686 and geode kernel has been updated, x86_64 and arm* toolchain will fail because the patches are still on 3.10. Anyway I have up and running a 3.14.13 router (geode) for a while, so those updated seems looking fine. commit 27cafd2bbefef872a730d5321664d417be5beb19 Author: kapeka Date: Sun Jul 27 18:36:48 2014 toolchain add modified buildfiles commit 2c1e59762c62396e9a7f22c54e39c15e71abcac7 Author: kapeka Date: Sun Jul 27 18:30:35 2014 clean toolchain from unnesseray patches add linux-headers in xz format to save some space Note: this are the headers from kernel 3.14.13 commit 0db9f10fda5c357e168f9ce06d86447011a5b4af Author: kapeka Date: Sat Aug 3 14:53:30 2013 copy uuid/uuid.h into staging Most of this commits are for the new kernel 3.14.13. So i think we must create a new topic branch: kernel-3.14.13 (rewriting history to squash the commits about the ipt_netflow) For the commit 0db9f10fda5c357e168f9ce06d86447011a5b4af perhaps it can be cherry-pick on master ? Is it's ok for you i can made the job. Regards, Yves -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] new leaf-storage repository
Hi all, i have create a new repository (leaf-storage) to test a new tool that i’m currently working on that store big/binaries files on a remote repository. This repository will never contain any commits or trees, only blobs. So it’s normal you don’t see anything with the gib web interface. Other informations will come soon…. Regards, Yves -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Git - Submodules
Le 22 juil. 2014 à 14:08, Mike Noyes a écrit : > On 07/22/2014 04:41 AM, Yves Blusseau wrote: >> Le 22 juil. 2014 à 11:47, Per Sjoholm a écrit >> : >> >>> Can git submodules be of help in reducing size >>> http://git-scm.com/book/en/Git-Tools-Submodules >>> >>> Github also has feutures . >> No as each git repositories contain all the history. > > Yves, > I concur with KP and Andrew that our current repository works, and meets > SF requirements for source code. If you want to try something different, > SF supports multiple git repositories. > >SourceForge: Git >http://sourceforge.net/p/forge/documentation/Git/#features > >• Multiple repositories are supported. Yes, actually we are using 3 git repositories on SF. Yves smime.p7s Description: S/MIME cryptographic signature -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] git_archive_download tool
Hi all, i have create a small tool to download file(s) or directory directly from sourceforge repository by using git-archive command. It is at least 3x faster to download with git-archive than using the http transport. I have put the tools currently on a personal branch (yves/git_archive_download). Can you make a test and see if it works on your system: git fetch -a git checkout -b git_archive_download origin/yves/git_archive_download and try for example to retrieve the gcc source tar file from the bering-uclibc repository: tools/git_archive_download --url=git://git.code.sf.net/p/leaf/bering-uclibc --basedir=repo/toolchain -C /tmp gcc-4.8.2.tar.bz2 and see if you have the gcc-4.8.2.tar.bz2 file under /tmp Regards, Yves -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Git - Submodules
Le 22 juil. 2014 à 11:47, Per Sjoholm a écrit : > Can git submodules be of help in reducing size > http://git-scm.com/book/en/Git-Tools-Submodules > > Github also has feutures . No as each git repositories contain all the history. Regards, Yves -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Reducing the size of the Bering-uClibc repository
Le 21 juil. 2014 à 19:14, kp kirchdoerfer a écrit : > Am Montag, 21. Juli 2014, 13:36:51 schrieb Yves Blusseau: >> Le 21 juil. 2014 à 11:17, kp kirchdoerfer a > écrit : >>> Hi Gents; >>> >>> Am Montag, 21. Juli 2014, 10:22:55 schrieb Yves Blusseau: >>>> Le 21 juil. 2014 à 09:51, Andrew a écrit : >>>>> 21.07.2014 09:48, Yves Blusseau пишет: >>>>>> Le 20 juil. 2014 à 21:42, Andrew a écrit : >>>>>>> 20.07.2014 21:12, Yves Blusseau ?: >>>>>>>> Le 20 juil. 2014 à 19:39, kp kirchdoerfer >>> >>> a écrit : >>>>>>>>> Am Sonntag, 20. Juli 2014, 19:22:18 schrieb Yves Blusseau: >>>>>>>>>> Le 20 juil. 2014 à 19:04, kp kirchdoerfer >>>>>>>>>> a >>>>>>>>> >>>>>>>>> écrit : >>>>>>>>>>> Am Sonntag, 20. Juli 2014, 18:40:15 schrieb Yves Blusseau: >>>>>>>>>>>> Le 20 juil. 2014 à 18:22, kp kirchdoerfer >>>>>>>>>>>> >>>>>>>>>>>> a >>>>>>>>>>> >>>>>>>>>>> écrit : >>>>>>>>>>>>> Hi Yves; >>>>>>>>>>>>> >>>>>>>>>>>>> Am Sonntag, 20. Juli 2014, 18:09:00 schrieb Yves Blusseau: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> actually the size of the git repository (i'm speaking of the >>>>>>>>>>>>>> "database" >>>>>>>>>>>>>> not >>>>>>>>>>>>>> the checkout) is about 3.5GB. It's really too big. The problem >>>>>>>>>>>>>> is >>>>>>>>>>>>>> that >>>>>>>>>>>>>> the >>>>>>>>>>>>>> "database" contain ALL the versions of "tar source files". So >>>>>>>>>>>>>> if >>>>>>>>>>>>>> someone >>>>>>>>>>>>>> need to clone our repository, he need to download at least >>>>>>>>>>>>>> 3.5GB >>>>>>>>>>>>>> of >>>>>>>>>>>>>> data. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What i propose is to remove all the external source tar files >>>>>>>>>>>>>> from the >>>>>>>>>>>>>> history and put them (at least the last one) in another git >>>>>>>>>>>>>> repository >>>>>>>>>>>>>> on >>>>>>>>>>>>>> SF. The source tar files will be download (if needed) from this >>>>>>>>>>>>>> new git >>>>>>>>>>>>>> repository (using the http protocol). With this, the >>>>>>>>>>>>>> bering-uclibc will >>>>>>>>>>>>>> contain only textfiles and some patch, and i think it will take >>>>>>>>>>>>>> only >>>>>>>>>>>>>> some >>>>>>>>>>>>>> MB. We will continue to create a sources.tgz file when we >>>>>>>>>>>>>> release >>>>>>>>>>>>>> a new >>>>>>>>>>>>>> version to meet the requirements of SF. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What do you think about this idea ? If you are ok, i can made >>>>>>>>>>>>>> the >>>>>>>>>>>>>> process >>>>>>>>>>>>>> to "clean" the repository and update the buildtool.cfg files to >>>>>>>>>>>>>> change >>>>>>>>>>>>>> the repo from local to SF. >>>>>>>>>>>>> >>>>>>>>>>>>> The wa
Re: [leaf-devel] Reducing the size of the Bering-uClibc repository
Le 21 juil. 2014 à 11:17, kp kirchdoerfer a écrit : > Hi Gents; > > Am Montag, 21. Juli 2014, 10:22:55 schrieb Yves Blusseau: >> Le 21 juil. 2014 à 09:51, Andrew a écrit : >>> 21.07.2014 09:48, Yves Blusseau пишет: >>>> Le 20 juil. 2014 à 21:42, Andrew a écrit : >>>>> 20.07.2014 21:12, Yves Blusseau ?: >>>>>> Le 20 juil. 2014 à 19:39, kp kirchdoerfer > a écrit : >>>>>>> Am Sonntag, 20. Juli 2014, 19:22:18 schrieb Yves Blusseau: >>>>>>>> Le 20 juil. 2014 à 19:04, kp kirchdoerfer >>>>>>>> a >>>>>>> >>>>>>> écrit : >>>>>>>>> Am Sonntag, 20. Juli 2014, 18:40:15 schrieb Yves Blusseau: >>>>>>>>>> Le 20 juil. 2014 à 18:22, kp kirchdoerfer >>>>>>>>>> >>>>>>>>>> a >>>>>>>>> >>>>>>>>> écrit : >>>>>>>>>>> Hi Yves; >>>>>>>>>>> >>>>>>>>>>> Am Sonntag, 20. Juli 2014, 18:09:00 schrieb Yves Blusseau: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> actually the size of the git repository (i'm speaking of the >>>>>>>>>>>> "database" >>>>>>>>>>>> not >>>>>>>>>>>> the checkout) is about 3.5GB. It's really too big. The problem is >>>>>>>>>>>> that >>>>>>>>>>>> the >>>>>>>>>>>> "database" contain ALL the versions of "tar source files". So if >>>>>>>>>>>> someone >>>>>>>>>>>> need to clone our repository, he need to download at least 3.5GB >>>>>>>>>>>> of >>>>>>>>>>>> data. >>>>>>>>>>>> >>>>>>>>>>>> What i propose is to remove all the external source tar files >>>>>>>>>>>> from the >>>>>>>>>>>> history and put them (at least the last one) in another git >>>>>>>>>>>> repository >>>>>>>>>>>> on >>>>>>>>>>>> SF. The source tar files will be download (if needed) from this >>>>>>>>>>>> new git >>>>>>>>>>>> repository (using the http protocol). With this, the >>>>>>>>>>>> bering-uclibc will >>>>>>>>>>>> contain only textfiles and some patch, and i think it will take >>>>>>>>>>>> only >>>>>>>>>>>> some >>>>>>>>>>>> MB. We will continue to create a sources.tgz file when we release >>>>>>>>>>>> a new >>>>>>>>>>>> version to meet the requirements of SF. >>>>>>>>>>>> >>>>>>>>>>>> What do you think about this idea ? If you are ok, i can made the >>>>>>>>>>>> process >>>>>>>>>>>> to "clean" the repository and update the buildtool.cfg files to >>>>>>>>>>>> change >>>>>>>>>>>> the repo from local to SF. >>>>>>>>>>> >>>>>>>>>>> The way I work is to copy the current repo to a local directory >>>>>>>>>>> and use >>>>>>>>>>> as main server >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Type = filesymlnk >>>>>>>>>>> Serverpath = repo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Whatever I do in the local directory it won't clash with changes >>>>>>>>>>> in git >>>>>>>>>>> vice versa I will not crash git :) >>>>>>>>>>> >>>>>>>>>&
Re: [leaf-devel] Reducing the size of the Bering-uClibc repository
Le 21 juil. 2014 à 09:51, Andrew a écrit : > 21.07.2014 09:48, Yves Blusseau пишет: >> Le 20 juil. 2014 à 21:42, Andrew a écrit : >> >>> 20.07.2014 21:12, Yves Blusseau ?: >>>> Le 20 juil. 2014 à 19:39, kp kirchdoerfer a >>>> écrit : >>>> >>>>> Am Sonntag, 20. Juli 2014, 19:22:18 schrieb Yves Blusseau: >>>>>> Le 20 juil. 2014 à 19:04, kp kirchdoerfer >>>>>> a >>>>> écrit : >>>>>>> Am Sonntag, 20. Juli 2014, 18:40:15 schrieb Yves Blusseau: >>>>>>>> Le 20 juil. 2014 à 18:22, kp kirchdoerfer >>>>>>>> >>>>>>>> a >>>>>>> écrit : >>>>>>>>> Hi Yves; >>>>>>>>> >>>>>>>>> Am Sonntag, 20. Juli 2014, 18:09:00 schrieb Yves Blusseau: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> actually the size of the git repository (i'm speaking of the >>>>>>>>>> "database" >>>>>>>>>> not >>>>>>>>>> the checkout) is about 3.5GB. It's really too big. The problem is >>>>>>>>>> that >>>>>>>>>> the >>>>>>>>>> "database" contain ALL the versions of "tar source files". So if >>>>>>>>>> someone >>>>>>>>>> need to clone our repository, he need to download at least 3.5GB of >>>>>>>>>> data. >>>>>>>>>> >>>>>>>>>> What i propose is to remove all the external source tar files from >>>>>>>>>> the >>>>>>>>>> history and put them (at least the last one) in another git >>>>>>>>>> repository >>>>>>>>>> on >>>>>>>>>> SF. The source tar files will be download (if needed) from this new >>>>>>>>>> git >>>>>>>>>> repository (using the http protocol). With this, the bering-uclibc >>>>>>>>>> will >>>>>>>>>> contain only textfiles and some patch, and i think it will take only >>>>>>>>>> some >>>>>>>>>> MB. We will continue to create a sources.tgz file when we release a >>>>>>>>>> new >>>>>>>>>> version to meet the requirements of SF. >>>>>>>>>> >>>>>>>>>> What do you think about this idea ? If you are ok, i can made the >>>>>>>>>> process >>>>>>>>>> to "clean" the repository and update the buildtool.cfg files to >>>>>>>>>> change >>>>>>>>>> the repo from local to SF. >>>>>>>>> The way I work is to copy the current repo to a local directory and >>>>>>>>> use >>>>>>>>> as main server >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Type = filesymlnk >>>>>>>>> Serverpath = repo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Whatever I do in the local directory it won't clash with changes in >>>>>>>>> git >>>>>>>>> vice versa I will not crash git :) >>>>>>>>> >>>>>>>>> So if we do have two repos (one for the sources, one for the >>>>>>>>> buildtool.* >>>>>>>>> and patches etc) I prefer that buildtool will be able to still use >>>>>>>>> local >>>>>>>>> directories (in the first place) and only download from SF if sources >>>>>>>>> are >>>>>>>>> missing. >>>>>>>> The simplest is to declare where to get the tar files with something >>>>>>>> like: >>>>>>>> >>>>>>>> >>>>>>>>type = http >>>>>
Re: [leaf-devel] Reducing the size of the Bering-uClibc repository
Le 20 juil. 2014 à 21:42, Andrew a écrit : > 20.07.2014 21:12, Yves Blusseau ?: >> Le 20 juil. 2014 à 19:39, kp kirchdoerfer a >> écrit : >> >>> Am Sonntag, 20. Juli 2014, 19:22:18 schrieb Yves Blusseau: >>>> Le 20 juil. 2014 à 19:04, kp kirchdoerfer a >>> écrit : >>>>> Am Sonntag, 20. Juli 2014, 18:40:15 schrieb Yves Blusseau: >>>>>> Le 20 juil. 2014 à 18:22, kp kirchdoerfer >>>>>> a >>>>> écrit : >>>>>>> Hi Yves; >>>>>>> >>>>>>> Am Sonntag, 20. Juli 2014, 18:09:00 schrieb Yves Blusseau: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> actually the size of the git repository (i'm speaking of the "database" >>>>>>>> not >>>>>>>> the checkout) is about 3.5GB. It's really too big. The problem is that >>>>>>>> the >>>>>>>> "database" contain ALL the versions of "tar source files". So if >>>>>>>> someone >>>>>>>> need to clone our repository, he need to download at least 3.5GB of >>>>>>>> data. >>>>>>>> >>>>>>>> What i propose is to remove all the external source tar files from the >>>>>>>> history and put them (at least the last one) in another git repository >>>>>>>> on >>>>>>>> SF. The source tar files will be download (if needed) from this new git >>>>>>>> repository (using the http protocol). With this, the bering-uclibc will >>>>>>>> contain only textfiles and some patch, and i think it will take only >>>>>>>> some >>>>>>>> MB. We will continue to create a sources.tgz file when we release a new >>>>>>>> version to meet the requirements of SF. >>>>>>>> >>>>>>>> What do you think about this idea ? If you are ok, i can made the >>>>>>>> process >>>>>>>> to "clean" the repository and update the buildtool.cfg files to change >>>>>>>> the repo from local to SF. >>>>>>> The way I work is to copy the current repo to a local directory and use >>>>>>> as main server >>>>>>> >>>>>>> >>>>>>> >>>>>>> Type = filesymlnk >>>>>>> Serverpath = repo >>>>>>> >>>>>>> >>>>>>> >>>>>>> Whatever I do in the local directory it won't clash with changes in git >>>>>>> vice versa I will not crash git :) >>>>>>> >>>>>>> So if we do have two repos (one for the sources, one for the buildtool.* >>>>>>> and patches etc) I prefer that buildtool will be able to still use local >>>>>>> directories (in the first place) and only download from SF if sources >>>>>>> are >>>>>>> missing. >>>>>> The simplest is to declare where to get the tar files with something >>>>>> like: >>>>>> >>>>>> >>>>>> type = http >>>>>> Serverpath= >>>>>> >>>>>> >>>>>> And the buildtool will download the file only if it's not already >>>>>> download >>>>>> in the repo directory. So if the tar files are already in the repo >>>>>> directory you can build all the lrp offline. >>>>> That sounds good. >>>>> >>>>>> For the source.tgz you only >>>>>> have to change the definition of Server sourceforge to >>>>> sourceforge> >>>>>> >>>>>> Type = filesymlnk >>>>>> Serverpath = repo >>>>>> >>>>>> >>>>>> because all the files are already in the sources.tgz >>>>> Just to understand: >>>>> >>>>> Is "sources.tgz" meant as example like "linux-3.10.47.tar.gz" or do you >>>>> refer to a tgz file that conatins *all* sources in one file? >>>> About "sources.tgz" i refer to a tgz file that contain "all" sources in one >>>> file. >>> And how do we maintain the file, if we only upgrade one source like the >>> kernel? >>> Repackage sources.tgz and upload a huge file? >> Yes if it is a requirement for SF > Uploading 600+MB on every minor change is ugly IMHO... And it'll cause a > headache to make changes for multiple branches. It’s the case actually (we are speaking about the big tgz file that must be proposed on the files area to meet the SF requirements) About the repo tar files, i think it will be better to download them directly from the original sites, as now, all the big sites are redundant and support many mirror. So we don’t have to commit them in the SF repository. Only the files that is difficult to find or download can be put to the SF repository. Regards, Yves -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Reducing the size of the Bering-uClibc repository
Le 20 juil. 2014 à 19:39, kp kirchdoerfer a écrit : > Am Sonntag, 20. Juli 2014, 19:22:18 schrieb Yves Blusseau: >> Le 20 juil. 2014 à 19:04, kp kirchdoerfer a > écrit : >>> Am Sonntag, 20. Juli 2014, 18:40:15 schrieb Yves Blusseau: >>>> Le 20 juil. 2014 à 18:22, kp kirchdoerfer >>>> a >>> >>> écrit : >>>>> Hi Yves; >>>>> >>>>> Am Sonntag, 20. Juli 2014, 18:09:00 schrieb Yves Blusseau: >>>>>> Hi all, >>>>>> >>>>>> actually the size of the git repository (i'm speaking of the "database" >>>>>> not >>>>>> the checkout) is about 3.5GB. It's really too big. The problem is that >>>>>> the >>>>>> "database" contain ALL the versions of "tar source files". So if >>>>>> someone >>>>>> need to clone our repository, he need to download at least 3.5GB of >>>>>> data. >>>>>> >>>>>> What i propose is to remove all the external source tar files from the >>>>>> history and put them (at least the last one) in another git repository >>>>>> on >>>>>> SF. The source tar files will be download (if needed) from this new git >>>>>> repository (using the http protocol). With this, the bering-uclibc will >>>>>> contain only textfiles and some patch, and i think it will take only >>>>>> some >>>>>> MB. We will continue to create a sources.tgz file when we release a new >>>>>> version to meet the requirements of SF. >>>>>> >>>>>> What do you think about this idea ? If you are ok, i can made the >>>>>> process >>>>>> to "clean" the repository and update the buildtool.cfg files to change >>>>>> the repo from local to SF. >>>>> >>>>> The way I work is to copy the current repo to a local directory and use >>>>> as main server >>>>> >>>>> >>>>> >>>>> Type = filesymlnk >>>>> Serverpath = repo >>>>> >>>>> >>>>> >>>>> Whatever I do in the local directory it won't clash with changes in git >>>>> vice versa I will not crash git :) >>>>> >>>>> So if we do have two repos (one for the sources, one for the buildtool.* >>>>> and patches etc) I prefer that buildtool will be able to still use local >>>>> directories (in the first place) and only download from SF if sources >>>>> are >>>>> missing. >>>> >>>> The simplest is to declare where to get the tar files with something >>>> like: >>>> >>>> >>>>type = http >>>>Serverpath= >>>> >>>> >>>> And the buildtool will download the file only if it's not already >>>> download >>>> in the repo directory. So if the tar files are already in the repo >>>> directory you can build all the lrp offline. >>> >>> That sounds good. >>> >>>> For the source.tgz you only >>>> have to change the definition of Server sourceforge to >>> sourceforge> >>>> >>>> Type = filesymlnk >>>> Serverpath = repo >>>> >>>> >>>> because all the files are already in the sources.tgz >>> >>> Just to understand: >>> >>> Is "sources.tgz" meant as example like "linux-3.10.47.tar.gz" or do you >>> refer to a tgz file that conatins *all* sources in one file? >> >> About "sources.tgz" i refer to a tgz file that contain "all" sources in one >> file. > > And how do we maintain the file, if we only upgrade one source like the > kernel? > Repackage sources.tgz and upload a huge file? Yes if it is a requirement for SF > I understood your proposal that we maintain the sources in a seperate git > repo > and use this to package all into one to fit SF requirements. >> From this repo we download sources, if they are not in the local directory, > otherwise we can build from a local directory/repo. > I think about a buildtool logic that checks, if the source is available > otherwise it will download from the git repo. Yes perhaps buildtool must be upgrade a little. It will be great also to have a checksum to be sure that the file has been correctly downloaded. This is what all builders use (openembedded, macports, etc…) Just for info, i have remove on my local git clone all the "source tar files" and the git "database" size go from 3.5G to 11MB and i think it can be reduce :D Yves smime.p7s Description: S/MIME cryptographic signature -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Reducing the size of the Bering-uClibc repository
Le 20 juil. 2014 à 19:04, kp kirchdoerfer a écrit : > Am Sonntag, 20. Juli 2014, 18:40:15 schrieb Yves Blusseau: >> Le 20 juil. 2014 à 18:22, kp kirchdoerfer a > écrit : >>> Hi Yves; >>> >>> Am Sonntag, 20. Juli 2014, 18:09:00 schrieb Yves Blusseau: >>>> Hi all, >>>> >>>> actually the size of the git repository (i'm speaking of the "database" >>>> not >>>> the checkout) is about 3.5GB. It's really too big. The problem is that >>>> the >>>> "database" contain ALL the versions of "tar source files". So if someone >>>> need to clone our repository, he need to download at least 3.5GB of data. >>>> >>>> What i propose is to remove all the external source tar files from the >>>> history and put them (at least the last one) in another git repository on >>>> SF. The source tar files will be download (if needed) from this new git >>>> repository (using the http protocol). With this, the bering-uclibc will >>>> contain only textfiles and some patch, and i think it will take only some >>>> MB. We will continue to create a sources.tgz file when we release a new >>>> version to meet the requirements of SF. >>>> >>>> What do you think about this idea ? If you are ok, i can made the process >>>> to "clean" the repository and update the buildtool.cfg files to change >>>> the repo from local to SF. >>> >>> The way I work is to copy the current repo to a local directory and use >>> as main server >>> >>> >>> >>> Type = filesymlnk >>> Serverpath = repo >>> >>> >>> >>> Whatever I do in the local directory it won't clash with changes in git >>> vice versa I will not crash git :) >>> >>> So if we do have two repos (one for the sources, one for the buildtool.* >>> and patches etc) I prefer that buildtool will be able to still use local >>> directories (in the first place) and only download from SF if sources are >>> missing. >> >> The simplest is to declare where to get the tar files with something like: >> >> type = http >> Serverpath= >> >> And the buildtool will download the file only if it's not already download >> in the repo directory. So if the tar files are already in the repo >> directory you can build all the lrp offline. > > That sounds good. > >> For the source.tgz you only >> have to change the definition of Server sourceforge to >> Type = filesymlnk >> Serverpath = repo >> >> because all the files are already in the sources.tgz > > Just to understand: > > Is "sources.tgz" meant as example like "linux-3.10.47.tar.gz" or do you refer > to a tgz file that conatins *all* sources in one file? About "sources.tgz" i refer to a tgz file that contain "all" sources in one file. Regards, Yves -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Reducing the size of the Bering-uClibc repository
Le 20 juil. 2014 à 18:22, kp kirchdoerfer a écrit : > Hi Yves; > > Am Sonntag, 20. Juli 2014, 18:09:00 schrieb Yves Blusseau: >> Hi all, >> >> actually the size of the git repository (i'm speaking of the "database" not >> the checkout) is about 3.5GB. It's really too big. The problem is that the >> "database" contain ALL the versions of "tar source files". So if someone >> need to clone our repository, he need to download at least 3.5GB of data. >> >> What i propose is to remove all the external source tar files from the >> history and put them (at least the last one) in another git repository on >> SF. The source tar files will be download (if needed) from this new git >> repository (using the http protocol). With this, the bering-uclibc will >> contain only textfiles and some patch, and i think it will take only some >> MB. We will continue to create a sources.tgz file when we release a new >> version to meet the requirements of SF. >> >> What do you think about this idea ? If you are ok, i can made the process to >> "clean" the repository and update the buildtool.cfg files to change the >> repo from local to SF. > > > The way I work is to copy the current repo to a local directory and use > as main server > > > >Type = filesymlnk > >Serverpath = repo > > > > Whatever I do in the local directory it won't clash with changes in git vice > versa I will not crash git :) > > So if we do have two repos (one for the sources, one for the buildtool.* and > patches etc) I prefer that buildtool will be able to still use local > directories (in the first place) and only download from SF if sources are > missing. The simplest is to declare where to get the tar files with something like: type = http Serverpath= And the buildtool will download the file only if it's not already download in the repo directory. So if the tar files are already in the repo directory you can build all the lrp offline. For the source.tgz you only have to change the definition of Server sourceforge to Type = filesymlnk Serverpath = repo because all the files are already in the sources.tgz Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Reducing the size of the Bering-uClibc repository
Hi all, actually the size of the git repository (i'm speaking of the "database" not the checkout) is about 3.5GB. It's really too big. The problem is that the "database" contain ALL the versions of "tar source files". So if someone need to clone our repository, he need to download at least 3.5GB of data. What i propose is to remove all the external source tar files from the history and put them (at least the last one) in another git repository on SF. The source tar files will be download (if needed) from this new git repository (using the http protocol). With this, the bering-uclibc will contain only textfiles and some patch, and i think it will take only some MB. We will continue to create a sources.tgz file when we release a new version to meet the requirements of SF. What do you think about this idea ? If you are ok, i can made the process to "clean" the repository and update the buildtool.cfg files to change the repo from local to SF. Regards, Yves -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Leaf website import
Hi all, i have, as a proof of concept, import some pages from the leat website (phpwebsite) into gihub web pages (jekyll). With this, we don't need a backend or a database. All the posts and web pages can be made/change directly by using the github site or by commiting the files to github. That is extremly easy to manage. The site: http://leaf.zetam.org/ The repository: https://github.com/LEAF-Bering-uClibc/website I have made a little documentation to explain how to start the jekyll engine locally to test and modify the site locally: https://github.com/LEAF-Bering-uClibc/website/blob/master/README.md A number of pages need to be import, but it will be easier when i'll have an XML export of the current phpwebsite. Regards, Yves PS: if you have a github account can you send me (by email) your login so i can add you to the https://github.com/LEAF-Bering-uClibc organisation. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering-uClibc web site
Le 15 juil. 2014 à 16:28, Mike Noyes a écrit : > On 07/15/2014 12:22 AM, Yves Blusseau wrote: >> Hi all, >> Mike, is it possible to access directly to the files of the website >> (http://leaf.sourceforge.net/) ? >> >> The idea is to replace all the links that start with >> http://sourceforge.net/apps/mediawiki/leaf/index.php?title= >> to >> http://bering-uclibc.zetam.org/w/index.php?title= > > Yves, > I'm going to mysqldump our content out of phpWebsite, and convert it to > html. Our content may then be incorporated into Mediawiki and/or input > into Drupal. > >old projectweb (phpWebsite) export >http://sourceforge.net/p/leaf/code/ci/master/tree/projectweb/ Thanks Mike, it's great. I was looking for creating a static web site with the jekyll engine (github engine) as a proof of concept, and i was need the post of bering-uClibc. Tell me when the dump is done. Regards, Yves -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Bering-uClibc web site
Hi all, Mike, is it possible to access directly to the files of the website (http://leaf.sourceforge.net/) ? The idea is to replace all the links that start with http://sourceforge.net/apps/mediawiki/leaf/index.php?title= to http://bering-uclibc.zetam.org/w/index.php?title= Regards, Yves -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Wiki migration
Le 14 juil. 2014 à 14:49, Mike Noyes a écrit : >> So Mike as the rights (as before) to change the users rights of other users. >> Actually, the wiki is "closed" so no new user can register a new account >> (but Mike can create one :D). >> Is it good or do we need to open the registration ? > > Yves, > It was setup that way on purpose. The wiki was setup for project members > to create documentation. Thanks Mike for the information. Regards, Yves -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck® Code Sight™ - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Wiki migration
More informations about the migration: I was using the same database as before, so your login, password and rights are the same as the wiki on SF. So Mike as the rights (as before) to change the users rights of other users. Actually, the wiki is "closed" so no new user can register a new account (but Mike can create one :D). Is it good or do we need to open the registration ? Regards, Yves PS: as usual, sorry for my bad english. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck® Code Sight™ - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Wiki migration
Le 13 juil. 2014 à 17:12, Yves Blusseau a écrit : > Hi all, > > Thanks to KP who give me the dump of the old wikimedia. > > The export is online at this url: http://bering-uclibc.zetam.org I miss to told you that the wiki have the SyntaxHighlight_GeSHi extension: http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi. So in page(s) we can use something like: echo "Hello World" to colorize code. Regards, Yves -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Wiki migration
Hi all, Thanks to KP who give me the dump of the old wikimedia. The export is online at this url: http://bering-uclibc.zetam.org Regards, Yves -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] nut package
Hi all, is it normal that the nut package have specific group 84 ? Files = 0:84 Directories = 0:84 Regards, Yves -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Elvis package
Le 10 juil. 2014 à 01:35, Erich Titl a écrit : > at 08.07.2014 09:06, Yves Blusseau wrote: >>> >>> Before 4.x we had a pretty usable vi, with probably all the bugs one can >>> think of. The busybox stuff may be nice but is typically just a meager >>> replacement for the REAL thing. I am under the impression that for the >>> sake of new platforms and kernel features we are loosing some of the >>> stability and usability of former releases. >> >> busybox/vi work well and can do the major thing we can do with vi. > > It cannot handle big files and I am not talking about real big files. > the logfiles on a small leaf box are sufficient. > >> e3vi work very well too (but can’t be compiled on non x86 platform). > > IMHO horrible thing. > >> elvis-tiny is known to have some bug (see: >> http://packages.ubuntu.com/fr/lucid/editors/elvis-tiny) : You should install >> another vi-editor (such as « vim", "elvis" or "nvi") if you want a vi editor >> that is full featured and has no bugs. >> vim has full fetaures, and can be compiled on the major platform. > > I am using elvis and it has similar limitations. I do not recall having > seen this on 'real old releases', but then, I am getting older and my > memory may have lapses. Try vim package (if you have memory to handle the package size) and you will have all you want :D Regards, Yves -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF pages/wiki/trac
Le 8 juil. 2014 à 20:01, Mike Noyes a écrit : > On another subject, I nominate Yves for promotion to project admin. > Thoughts? Thanks. Regards, Yves -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Elvis package
> > Before 4.x we had a pretty usable vi, with probably all the bugs one can > think of. The busybox stuff may be nice but is typically just a meager > replacement for the REAL thing. I am under the impression that for the > sake of new platforms and kernel features we are loosing some of the > stability and usability of former releases. busybox/vi work well and can do the major thing we can do with vi. e3vi work very well too (but can’t be compiled on non x86 platform). elvis-tiny is known to have some bug (see: http://packages.ubuntu.com/fr/lucid/editors/elvis-tiny) : You should install another vi-editor (such as « vim", "elvis" or "nvi") if you want a vi editor that is full featured and has no bugs. vim has full fetaures, and can be compiled on the major platform. So the only problem is elvis-tiny that segfault sometimes according to arch, compilation options, etc… Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Elvis package
Le 6 juil. 2014 à 19:48, l...@davidmbrooke.co.uk a écrit : > My vote would be: > - Include the busybox vi for all images by default > - Continue to package elvis-tiny for users who like the compromise of size > and functionality > - Add a "better" vi clone for people who want full functionality and don't > mind the size Agree with you david. I will make a full features vim package to replace the current tiny one. For elvis-tiny, i have commit the latest upstream 1.4-23 but it also segfault sometimes. Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Elvis package
Le 6 juil. 2014 à 15:57, kp kirchdoerfer a écrit : >> >> If we ALWAYS build busybox with the vi applet we don't need to build >> separate initrd. > > True, but it consumes some more kb, which arent't useful for most of the > users. > Keep in mind - if we want to support MIPS-based routers we need to be small > as > possible, usually they don't have a lot of RAM (32 to 64 MB AFAIK). > True but i made a test with or without vi applet: busybox without vi: 371140 busybox with vi: 388248 so the difference is only of 17k. For me it's better to always compile busybox with vi (so there an editor in ALL platform in initrd), than to have a mechanism to enable/disable vi applet depending on the platform architecture (just to gain 17k). The simple way is always the best ? Yves -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Elvis package
Le 6 juil. 2014 à 15:12, kp kirchdoerfer a écrit : > Am Sonntag, 6. Juli 2014, 15:02:54 schrieb Yves Blusseau: >> Le 6 juil. 2014 à 14:39, Yves Blusseau a écrit : >>>> AFAIK unfortunately busybox-vi is not just a replacement, one needs to >>>> build it with a proper toolchain, and replace initrd… >>> >>> Can you explain ? >>> We can choose now which editor to use with the Platform_Editor buildtool >>> variable. If it is set to vi, busybox applet vi will be built. If the >>> value is different the applet will not be built. >> After looking at sources i see what you mean. e3 can't be build on arm arch >> like rasberry-pi. What i proposed is to always build busybox vi applet so >> in any platform we will have an editor in initrd. Then the packager can >> choose which editor to use by default for the platform. >> >> What do you think about this ? > > I've been to slow sending my mail :) > > It will be an improvement, anyway it will require to build a seperate initrd > version, since busybox is loaded with initrd, and IMHO it's too much to > provide seperate versions of initrd just to change the editor. If we ALWAYS build busybox with the vi applet we don't need to build separate initrd. > Coming back to the topic: > I think if a user wants vi instead of e3ne, he can choose between e3vi, vim(- > tiny? Are those seperate version?) and maybe we can even fix elvis-tiny to > have > something smaller than vim, but more useful than e3vi? Yes, the packager choose a default editor (which will set the profile EDITOR variable). The final user can then change the EDITOR variable value to use another editor. Actually there only a vim-tiny version (550Ko), I can make a full feature vim version (2Mo) for users like me that use vim intensively and use an elvis/elvis-tiny for other users. The problem is that actually the elvis-tiny (1.4-22 or 1.4-23) segfault on my platform. So perhaps it's better to use a "true" version of elvis (not tiny) that is more stable (but larger) ? Yves smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Elvis package
Le 6 juil. 2014 à 14:39, Yves Blusseau a écrit : >> AFAIK unfortunately busybox-vi is not just a replacement, one needs to build >> it with a proper toolchain, and replace initrd… > > > Can you explain ? > We can choose now which editor to use with the Platform_Editor buildtool > variable. > If it is set to vi, busybox applet vi will be built. If the value is > different the applet will not be built. After looking at sources i see what you mean. e3 can't be build on arm arch like rasberry-pi. What i proposed is to always build busybox vi applet so in any platform we will have an editor in initrd. Then the packager can choose which editor to use by default for the platform. What do you think about this ? Yves -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] busybox build failure
Le 6 juil. 2014 à 14:40, Yves Blusseau a écrit : > > Le 6 juil. 2014 à 14:35, kp kirchdoerfer a > écrit : > >> Hi Yves; >> >> busybox fails to build after your latest commit: >> >> cp busybox.config /opt/buildtool-master/source/i486-unknown-linux- >> uclibc/busybox/busybox-1.22.1/.config >> >> >> [ -f "busybox.config-e3ne.patch" ] && \ >> patch -d "/opt/buildtool-master/source/i486-unknown-linux- >> uclibc/busybox/busybox-1.22.1" < "busybox.config-e3ne.patch" >> make: *** [/opt/buildtool-master/source/i486-unknown-linux- >> uclibc/busybox/busybox-1.22.1/.source] Fehler 1 >> >> busybox.config-e3ne.patch seems to be wrong. >> >> kp > > There must be no busybox.config-e3ne.patch so the patch must not apply …. > > I wiil try to see what was the prb. Fix commited. Regards, Yves -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] busybox build failure
Le 6 juil. 2014 à 14:35, kp kirchdoerfer a écrit : > Hi Yves; > > busybox fails to build after your latest commit: > > cp busybox.config /opt/buildtool-master/source/i486-unknown-linux- > uclibc/busybox/busybox-1.22.1/.config > > > [ -f "busybox.config-e3ne.patch" ] && \ > patch -d "/opt/buildtool-master/source/i486-unknown-linux- > uclibc/busybox/busybox-1.22.1" < "busybox.config-e3ne.patch" > make: *** [/opt/buildtool-master/source/i486-unknown-linux- > uclibc/busybox/busybox-1.22.1/.source] Fehler 1 > > busybox.config-e3ne.patch seems to be wrong. > > kp There must be no busybox.config-e3ne.patch so the patch must not apply …. I wiil try to see what was the prb. Yves smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Elvis package
> AFAIK unfortunately busybox-vi is not just a replacement, one needs to build > it with a proper toolchain, and replace initrd… Can you explain ? We can choose now which editor to use with the Platform_Editor buildtool variable. If it is set to vi, busybox applet vi will be built. If the value is different the applet will not be built. Yves smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] kmodules not building
Le 6 juil. 2014 à 13:26, kp kirchdoerfer a écrit : > Hi Yves, > > in your update of e1000e you added a kmodules buildtool.cfg, which adds > specific.net6501 > > + > + Server = localrepo > + Revision = HEAD > + Directory = kmodules > + > + > > Is that intended? If so, I think the file is msissing and kmodules fails to > build. Sorry it's a file for my specific platform (net6501) that i have commit by mistake. I will commit a patch to add support for this platform (like you do for geode) in the futur. I have commit the fix. Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Elvis package
Hi all, elvis-tiny (1.4-22) binary segfault on my platform for "big" file. Ex if i try to open /var/log/kern.log (62ko) and do 2 x CTRL-F it segfault I have compiled a 1.4-23 version, it's a little better but segfault also. It is known that elvis-tiny have a lot of bug. I have compiled also an elvis (not tiny) 2.2 version and it works without segfaulting but it's bigger than tiny version: elvis-tiny: 67Ko elvis: 542Ko I have also compiled a tiny version of vim that work great and is a little bigger than elvis: vim: 559Ko So my questions are: * Is elvis-tiny segfault also on your platform (Bering 5.1 alpha1) ? * if yes perhaps it's better to replace elvis-tiny with elvis ? We can propose all sort of editors. For the vi compatible editor i propose to have that: * e3vi: for very little embedded system where the size is the main concern * busybox vi: likewise e3vi * elvis (not tiny): for a mix between e3vi/busybox and vim * a full features vim (2Mo): for a complete vi editor Why do you think of this ? Regards, Yves -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] vlan package
Hi all, it seems that the vlan package doesn't exist in 5.x branch. Is it normal? if yes, what is the package that contain the vconfig (or other) command to configure the 802.1q vlans on network devices ? Regards, Yves -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Error with pert utility
Hi all, i use pef top -a command to see how my system is running. It works well the first time i launch it but when i try to relaunch it i have this error: ~ # perf top -a Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (cycles). /bin/dmesg may provide additional information. No CONFIG_PERF_EVENTS=y kernel support configured? I have nothing in dmesg and of course the kernel was built with CONFIG_PERF_EVENTS=y Do you have some hints ? Regards, Yves -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Can't expand variable $uClibc_loader_link
Le 2 juil. 2014 à 06:34, Yves Blusseau a écrit : > Hi all, > > i'm trying to create a new initrd.lrp package but the buildpacket.pl return > the error: > > sudo ./buildpacket.pl --package=initrd > Error: can't expand variable $uClibc_loader_link > > Where this variable must be defined and with what value ? > After cleaning some directories the variable is now set by the buildtool.mk of initrd. Regards, Yves -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Can't expand variable $uClibc_loader_link
Hi all, i'm trying to create a new initrd.lrp package but the buildpacket.pl return the error: sudo ./buildpacket.pl --package=initrd Error: can't expand variable $uClibc_loader_link Where this variable must be defined and with what value ? Regards, Yves -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF pages/wiki/trac
Le 29 juin 2014 à 18:28, Yves Blusseau a écrit : >> Mike, your help and insights are appreciated, and I guess none of us will, >> or >> would have complained (maybe a little bit as usual :)), if you move on to >> based on your experience about hosting issues for LEAF. >> >> As you can read in my other mail, I've asked Yves for help to host mediawiki >> until you install it on project web. Do you have a timeframe for this task? > > Mike can you export the MediaWiki database ? > It will be great if you can give me the version of MediaWiki that we used. No news ? Regards, Yves -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF pages/wiki/trac
> Mike, your help and insights are appreciated, and I guess none of us will, or > would have complained (maybe a little bit as usual :)), if you move on to > based on your experience about hosting issues for LEAF. > > As you can read in my other mail, I've asked Yves for help to host mediawiki > until you install it on project web. Do you have a timeframe for this task? Mike can you export the MediaWiki database ? It will be great if you can give me the version of MediaWiki that we used. Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF pages/wiki/trac
Hi all, i also prefer the documentation that was done with Mediawiki. If we need time to restore the Mediawiki on SF i can host the documentation on my own hosts. I will then be enable to reexport the wiki to import it on SF when it will be ready. So don’t hesitate if you need some help to host the documentation. Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF pages/wiki/trac
Le 25 juin 2014 à 15:45, Mike Noyes a écrit : > On 06/25/2014 12:40 AM, Yves Blusseau wrote: >> Le 23 juin 2014 à 16:30, Mike Noyes a écrit : >> >>> On 06/23/2014 06:35 AM, Mike Noyes wrote: >>> >>> Everyone, >>> Non-destructive Mediawiki import to SF Allura platform done. >>> >>> https://sourceforge.net/p/leaf/wiki/Main_Page/ >> Hi all, >> >> we have lost the internal anchors and some highlights colors for example in >> the http://sourceforge.net/p/leaf/wiki/Developer_Guide_-_Git_Workflows/. >> >> Don't know if we can restore them. >> >> Mike can you export the old Mediawiki somewhere else, so i can retrieve it >> and put online on my mediawiki to see the differences ? > > Yves, > Do you have the ability to setup Mediawiki locally? We have a backup > available in our shell space on SourceForge. I can archive that, and > send it to you. Yes i have several virtual machines with the latest version of mediawiki. So if we can send me the archive i can restore the mediawiki. Afterwards, what do you want to do ? We can use it and export to a different format and import it on sourceforge. I have also a gollum wiki (the github wiki) if we want to use other wiki language like markdown, … All suggestions are welcome. Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF pages/wiki/trac
Le 23 juin 2014 à 16:30, Mike Noyes a écrit : > On 06/23/2014 06:35 AM, Mike Noyes wrote: > > Everyone, > Non-destructive Mediawiki import to SF Allura platform done. > >https://sourceforge.net/p/leaf/wiki/Main_Page/ Hi all, we have lost the internal anchors and some highlights colors for example in the http://sourceforge.net/p/leaf/wiki/Developer_Guide_-_Git_Workflows/. Don't know if we can restore them. Mike can you export the old Mediawiki somewhere else, so i can retrieve it and put online on my mediawiki to see the differences ? Regards, Yves -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] wpa-supplicant on bering 5.01
Le 12 févr. 2014 à 11:33, Erich Titl a écrit : > Hi Yves > > on 12.02.2014 09:41, Yves Blusseau wrote: >> >> Le 11 févr. 2014 à 21:24, Erich Titl a écrit : > ...> >> Don ’t know how you have so much conflict. > > I _believe_ I know the reason. > > For some unfathomable reason the root directory of the whole tree has > changed from > > bering-uclibc to bering-uclibc-master The name of the working directory is not important. The better is that you sync your local repository to the remote one with commands like: git fetch —all git co master git reset —hard origin/master Be careful the last command will erase all your local modifications that was not committed. After that look in your stash for the changes and try to apply them on the master branch. Also don’t forget to drop all stash that are too old. Yves -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] wpa-supplicant on bering 5.01
Le 12 févr. 2014 à 10:02, Erich Titl a écrit : > > > Looking at the files I see that my changes have disappered, rather > unfortunate, but not that bad. I still remember what I did. I was of the > opinion this should never happen. Changes doesn’t disapperred, they are in your stash stask. Use git stash show -p to see your modifications Yves -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] wpa-supplicant on bering 5.01
Le 11 févr. 2014 à 21:24, Erich Titl a écrit : >> >> Hi Erich, >> you can stash your changes. After that fetch the branch master from the repo >> and rebase your work on it: >> >> git stash >> git pull >> git stash pop > > Did that, now tons of conflicts arose, at least it did not abort. > > git status shows now > > # On branch master > # Changes to be committed: > # (use "git reset HEAD ..." to unstage) > # > # modified: Changes > # modified: buildimage.pl > # modified: buildlwp.sh > # modified: buildtool/Clean.pm > . > and so on for another 800 lines. Don ’t know how you have so much conflict. Check if you have the stash save (if conflicts the stash must not be drop). Check with git stash list to see if your stash was save. If saved you can do a git reset —hard because the HEAD was’nt moved. Now you must find what files you need to change to apply your patch …. Regards, Yves -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] wpa-supplicant on bering 5.01
Le 11 févr. 2014 à 16:07, Erich Titl a écrit : > Hi Folks > > it looks like wpa-supplicant is out of date on 5.01 (possibly later too) > > I have successfully built the latest wpasupplicant on my (slightly > invalid) buildenv and would like to contribute it. > > Questions > > - How can I find out where I stand relative to the repo? Do I need to > know at all? > > Here is my git status (not really much info) > > bash-4.2# git status > # On branch master > # Untracked files: > # (use "git add ..." to include in what will be committed) > # > # repo/initrd/files.wrap > # repo/wpasupplicant/wpa_supplicant-2.1.tar.gz > nothing added to commit but untracked files present (use "git add" to track) Hi Erich, you can stash your changes. After that fetch the branch master from the repo and rebase your work on it: git stash git pull git stash pop Regards, Yves -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Git workflow questions
Le 10 févr. 2014 à 21:00, David M Brooke a écrit : >>> I also have a new Package (vnstat) which I'd like to add. That's not a >>> bug-fix, so should I create my feature branch off "master" rather than >>> "maint"? >> Fork off the new feature branch from maint if you want to add the new package into old version then merge « upward » to add the package to the master branch. The best is to always fork off from the « oldest » branch that you want to add the functionality. Hope that i have answer to your questions (and sorry for my bad english). Regards, Yves -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Git workflow questions
Le 7 févr. 2014 à 22:09, David M Brooke a écrit : > Hi leaf-devel, > Hi David ! > What I did was: > - Created a new local branch (called "trac#93") based on "maint" > - Committed the code change against that new branch > - Merged the bugfix branch back into « maint" (with "--no-ff") You must firstly git checkout maint git pull —ff-only To be sure that your maint branch is uptodate, then git merge trac#93 git push This will merge your bug-fix into maint and push it to the repo. Then you can delete your local trac#93 branch After that you must not forget to report your bug-fix to « upset » branches like master with a: git checkout master git pull --ff-only git merge —no-commit maint Resolve the conflicts then commit the merge: git commit then push the new master branch to the repo: git push Regards, Yves -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Le 8 janv. 2014 à 15:37, KP Kirchdörfer a écrit : > Am Mittwoch, 8. Januar 2014, 13:05:59 schrieb Yves Blusseau: >> Le 7 janv. 2014 à 16:01, KP Kirchdörfer a > écrit : >>>> If you think it’s obscur for you i can do it. >>> >>> I prefer you do, that's too obscur for me :) >> >> Ok i will do it but you have already merge maint-4.x into master in a wrong >> manner. I will move all correctly but i need to know the commit to use as >> the base for the new maint branch. Last change of the version are ‘update >> version to 5.0.3-beta1’. >> Is that version is the new master or the new maint ? > > The last commit should be cf3698c9697532554e50929c3d7057977d9efd92 (openssl > updated to 1.10.1f) - this shall be the base for new maint > If that is done I'll intend to merge the rpi branch to master, which will > feature-wise move master to 5.1 with new longtime kernel 3.10 and rpi support. > > > Is that inline with the git workflow? Yes. I have update the maint branch so now it’s the same as master. You can merge the rpi branch to master but it seems there are a number of conflicts to resolve. Regards, Yves -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Rewrite history of master
Hi all, i was forced to rewrite history of the last commits in the master branch. So you need to update your local master branch. You must check that you are no local changes pending in your master branch (use git log) If you have somes changes copy your master branch to another name like master-new with the command: git branch master-new master The really work to sync your local master branch with the central repository is git checkout master git fetch —all git reset —hard master origin/master Now if you have create a master-new branch (describe above) because you have some uncommit change that you « save » in master-new branch try to rebase with the new master branch: git checkout master-new git rebase origin/master and then check that all the new commits are needed (you can use the command git log master..master-new) You can use the rebase -i origin/master command if you want to delete or squash some commits. When you think it’s good to move your uncommit changes to master: git checkout master git pull —rebase git merge —ff-only master-new and you can then delete the master.new branch: git branch -d master.new Creating the master.new branch it’s ONLY necessary if you have uncommit changes in your branch. Regards, Yves -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Le 7 janv. 2014 à 16:01, KP Kirchdörfer a écrit : >> If you think it’s obscur for you i can do it. > > I prefer you do, that's too obscur for me :) Ok i will do it but you have already merge maint-4.x into master in a wrong manner. I will move all correctly but i need to know the commit to use as the base for the new maint branch. Last change of the version are ‘update version to 5.0.3-beta1’. Is that version is the new master or the new maint ? Regards, Yves -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Le 6 janv. 2014 à 19:09, KP Kirchdörfer a écrit : > Locally I do have maint-4.x, how to proceed? > >>> btw: how can we fix the wrong rename/move of maint to maint-4.x? >> >> Yes easy :D >> remove local and remote branches with the commands: >> git checkout master >> git branch -d maint-4.x >> git push origin :maint-4.x > > Really? master is at 5.0. What I'm looking for is to have move back maint-4.x > to maint, then do it right to move maint to maint-4x and from then to create > a > new maint from master. > Yes you need to delete maint-4.x locally and remotely then « create » a new maint and a new master. If you think it’s obscur for you i can do it. Regards, Yves -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Le 6 janv. 2014 à 17:31, KP Kirchdörfer a écrit : > Hi Yves; > > I knew I made something wrong :) > Because of that I started only with the "old" maint branch, which I hoped > wouldn’t be that harmful, and didn't touch anything else. > It hard to break (not recoverable) in git. > The main idea was that maint until now has had fixes for 4.x, where mainly > master was for version 5. I now want to move 5.0.x to maint, which receive > further maintenance for shure, while preserving a way to maintain also 4.x if > necessary, though I do expect very few changes. > > And the idea also is to merge the rpi branch into master, that means master > will be moved feature-wise to a 3.10 kernel etc and the main development > branch and base for the next major version (5.1). > >> In any case we only do fast-forward for integration branch !! >> >> I have update the Git Workflow guide to explain how to manage the maint >> branch after a new release: http://goo.gl/dAxfQ2 > > I've read that, but I do not understand, sorry. > > Given that we only had maint branch, and that the command I know to create a > new branch is > > git branch current-branch new branch > No the command is git branch new-branch start-point so to copy the old maint branch to maint-4.x do: git branch maint-4.x maint > > the command in the docs, looks to me the other way round. I would have > expected > > git branch maint maint-X.(Y-1) No it’s git branch maint-X.(Y-1) maint >> After that we need to fast forward the maint branch to master so the master >> branch become the new maint branch: git checkout maint >> git merge —ff-only master >> >> After that we can work on master like before and tag the new releases. >> >> Sorry for the time to reply but i don’t see your message during christmas >> holidays. > > No pb, thx for responding and patience. > > I learned a lot the last year about working with git, and I hope at the end > of > the year I’ll be able to doing basic tasks error-free :) I have try rapidly do ff the old maint to master and it’s not working because you have forget to merge a commit in maint in master. Do: git log master..maint commit 9dff17faf09948a1232324a41715e1a5f06d5cb7 (origin/maint, maint) Author: kapeka Date: Sun Jun 23 15:35:57 2013 remove outdated entries This commit (9dff17fa) must be merge into master even if it cannot apply at all in master. Remember to always merge commit upwards along integration branches. So first merge (and resolv the conflict) the commit in master using the command describe here: http://bit.ly/JYvUbZ I can do it for you if you have a difficulty to resolv the conflict. Then you can fast-forward the maint to master (so the maint branch will be at the current master position). > btw: how can we fix the wrong rename/move of maint to maint-4.x? Yes easy :D remove local and remote branches with the commands: git checkout master git branch -d maint-4.x git push origin :maint-4.x Now you can follow the instructions above to copy maint to maint-4.x and master to maint Regards, Yves smime.p7s Description: S/MIME cryptographic signature -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Le 6 janv. 2014 à 16:33, Erich Titl a écrit : > If the central repository gets changed structurally, what needs to be > done to the peripheral copies, are they just magically modified? > If we only fast-forward central repository branches nothing specific things is needed to be done locally. Only fetch or pull to be in sync with the central repository. Regards, Yves -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Le 6 janv. 2014 à 11:07, Erich Titl a écrit : > Hi Yves > Hi Erich > All this sounds fine for the central repository, would you mind to > elaborate this for the distributed (workspace) repositories? What is the > canonical way distribute the new repository structure? > I don’t understand, you checkout the central repository into local. Can you explain me your problem exactly, because (sorry) i don’t understand your problematic ? Regards, Yves -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Hi kp, no « renaming » branch is not the right thing to do. Also removing integration branches on the repository is not a good idea :D It seems there a problem has my local maint branch is now not « attach » to a remote maint branch (do you remove or change the maint branch) ? In any case we only do fast-forward for integration branch !! I have update the Git Workflow guide to explain how to manage the maint branch after a new release: http://goo.gl/dAxfQ2 so in our case we need to COPY the old maint branch to another name: maint-4.x if we want to continue to maintain it or v4.x if the branch will not get updates: git branch maint-4.x maint or git branch v4.x maint After that we need to fast forward the maint branch to master so the master branch become the new maint branch: git checkout maint git merge —ff-only master After that we can work on master like before and tag the new releases. Sorry for the time to reply but i don’t see your message during christmas holidays. Regards, Yves Le 4 janv. 2014 à 20:19, KP Kirchdörfer a écrit : > Hi; > > I've recently updated my router to run with a kernel 3.10.25 and it works - > as you when reading this mail :). > > > I've also get a raspberry pi up and running with the same kernel and build > from the rpi branch. > > So I think it's time, as proposed a few days ago, to move master to maint, > and > to merge the rpi branch into master as new master. > > First I merged rpi and master locally, and with Yves hints given earlier how > to resolve issues shown with "git status" I've build a new local branch, from > which I've build the above mentioned versions runing on my router and the > raspberry. So this part went well. > > Renaming remote branches is another task. I've googled around and found the > easiest way to accomplish this task with the commands: > > > git branch -m old_branch new_branch # Rename branch locally > git push origin :old_branch # Delete the old branch > git push --set-upstream origin new_branch # Push the new branch, set local > branch to track the new remote > > I did that to test with the "maint" branch (movng to maint-4.x), seeming > uncritical to me. > While it worked locally, I'm unshure if other team memeber tracking the > branch > "maint" will be moved automatically to "maint-4.x". > I've added a new file in the new branch for testing " TEST_GIT_MOVING". > > > Is that the correct approach to rename remote repository? > > Does work others as well as on my side? > > If not, what has to be done on other users client tracking the remote branch? > > kp > > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > > ___ > leaf-devel mailing list > leaf-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-devel -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git branches
Le 28 juil. 2013 à 19:28, KP Kirchdoerfer a écrit : > > Yes, sounds easier and more towards how we do releases. > I'm keen to tag versions when doing a new release, so that won't be a > problem. > > A question, possibly asked before, how do we keep branches like next in > sync with master/maint? > Like you do to merge maint into master: merge master into next: git checkout next git pull --ff-only git merge origin/master > E.g. I'd like to publish my work on new boot menu into something else > than master so it's available for testing, but don't harm master if > something is wrong. > To do that use a topic branch (fork from master) > Branch "next" would be a good place, but I assume it's that outdated > that doing a test within this branch may not give results I expect; the > same is true for pu, and will happen with other branches. > merge your topic branch into next 'next' branch "must" contain all the features in development so other users can test the new features before they are merge into master when they are stable. NEVER merge 'next' branch into master. Only merge stable topic branch into master. > In the wiki docs you've written that updating branches like next > "habitually" is not recommended. > > So whats the recommended way to keep branches in sync? > Only merge integration branches (maint, master) upwards "NEVER" downwards. So merge maint INTO master NEVER master INTO maint. Merge master INTO next or pu "NEVER" next INTO master Fork topic branches from master (or maint) and merge to integration branches when topic branch is stable. Merge topic branches into next so other users can test all new features that will be released into master. Yves -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git branches
Le 27 juil. 2013 à 20:08, KP Kirchdoerfer a écrit : > Am 27.07.2013 19:31, schrieb Yves Blusseau: >> >> Le 27 juil. 2013 à 11:11, KP Kirchdoerfer a >> écrit : >> >>> Well, seems a problem is that we have developed two different concepts >>> and naming schemes over time, which are not in sync. >>> See: >>> http://leaf.sourceforge.net/bering-uclibc/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=8&MMN_position=8:8 >>> >> Not really a problem. We must have a branch for the next release (it's the >> master branch). >> The old branch has been released so only bugfix must be done in it. > > You're right. > >> So in our case 5.0.0 is release, it's now a maintenance branch. So we must >> release only bug fix in it). >> The 5.0.1 or 5.1.0 or 6.0.0 is the new master branch that will be the next >> release. >> >>> Also where do we draw the line between feature and maintenance? Moving >>> from libnl to libnl3 is rather a feature than a bugfix. But what about >>> package updates, like shorewall, dnsmasq etc where fixes are provided as >>> well as new features? >> This must be in the master branch. >> For example updating shorewall must be made between 5.0.1 and 5.0.2. >> 5.0.1 is the master branch. We update it with shore wall update. When 5.0.2 >> is released, 5.0.2 will be the new master branch and 5.0.1 the new >> maintenance branch. > > You mean when 5.0.*1* is released? > Yes sorry >> Everything you update is for the NEXT release, so it must be done in the >> master branch. >> The maint branch is only to correct bug for people using the last released >> version. But maint branch must not be update with new version of package, >> etc… only if it fix a big bug. > > (so as a consequence, IF we'd have a real bug in 5.0.0 we'll be able to > create 5.0.0.1. If so the page linked above should note that.) Yes it's that. What we can do also is that the master stay in the major release and "rename" master branch only on new major release (change in one of the first two digits). So 5.0.1 stay master and 4.0.3 stay as maint When 5.1 or 6.0 will be released 5.1 we will change the master branch to the next version. 5.0.1 is only a minor release so we don't need to maintain 5.0 branch. Perhaps it's more easier like this. We only have to tag version in git when we release the tarball. Yves -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
