why was meta-dlna submodule history stripped out?
Looking over meta-dlna in Yocto git I see it's little more than a fork of meta-guacamayo from guacamayo-project.org -- could someone please explain to me why the git history was stripped out from this 'combo' layer?
(I am delighted Intel is finding Guacamayo useful, but the obliteration of the history makes it look as if the credit for this official Yocto layer goes to Intel; I am sure that was not intentional.)
I am also interested in knowing why the fork was deemed necessary in the first place, just in case it was for technical reasons that could be addressed at source.
Tomas
Quoted 5 lines · Tomas Frydrych
Looking over meta-dlna in Yocto git I see it's little more than a fork of meta-guacamayo from guacamayo-project.org -- could someone please explain to me why the git history was stripped out from this 'combo' layer?
My apologies, I updated the MAINTAINER and README files.
Quoted 4 lines
(I am delighted Intel is finding Guacamayo useful, but the obliteration of the history makes it look as if the credit for this official Yocto layer goes to Intel; I am sure that was not intentional.)
No this was not intentional, the combo-layer tool seems to do that. I used combo layer because we wanted to pull in the kvm changes so that this could be shown as a VM.
Quoted 4 lines
I am also interested in knowing why the fork was deemed necessary in the first place, just in case it was for technical reasons that could be addressed at source.
In the first pass, there were mostly minor changes to cut this down to what was needed for the headless media server. As I moved to 1.3 there were more changes that I have made, you can see what's going on in the 1.3wip branch of meta-dlna. If you want some of those changes in meta-guacamayo please take them.
My goal is to make the meta-dlna be more cut down and not require the
as much. If we can accomplish that directly with meta-guacamayo that would be awesome.
Right now I am fighting a dbus/rygel segfault.
Sau!
Quoted 7 lines
Tomas
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
Quoted 8 lines · On Friday 19 October 2012 11:01:09 Saul Wold wrote:
Quoted 3 lines · Tomas Frydrych
(I am delighted Intel is finding Guacamayo useful, but the obliteration of the history makes it look as if the credit for this official Yocto layer goes to Intel; I am sure that was not intentional.)
No this was not intentional, the combo-layer tool seems to do that. I used combo layer because we wanted to pull in the kvm changes so that this could be shown as a VM.
This is the default behaviour of combo-layer, on the assumption that most people don't want all the history from the very beginning. It is not clearly documented but there is a simple procedure you can follow to set up the combo repo if you do want complete history:
1) Instead of combo-layer init, run git init
2) Create conf/combo-layer.conf based on the template configuration (scripts/combo-layer.conf.example) ensuring last_revision is blank for all components
3) git add conf/combo-layer.conf, then git commit
4) Run combo-layer update
Quoted 9 lines
Quoted 3 lines
I am also interested in knowing why the fork was deemed necessary in the first place, just in case it was for technical reasons that could be addressed at source.
In the first pass, there were mostly minor changes to cut this down to what was needed for the headless media server. As I moved to 1.3 there were more changes that I have made, you can see what's going on in the 1.3wip branch of meta-dlna. If you want some of those changes in meta-guacamayo please take them.
In the same way we manage the poky repository, at least as far as the master branch is concerned I think we should be sending the fixes back upstream first and then using the combo-layer tool to pull them back down when they are merged.
Long term however I'd rather see the additional unique recipes in meta- guacamayo itself go into more official OE community layers. meta-dlna would continue to take them from there using combo-layer though I suspect. (This is the plan I have for meta-baryon.)
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 4 lines · Paul Eggleton
Long term however I'd rather see the additional unique recipes in meta- guacamayo itself go into more official OE community layers. meta-dlna would continue to take them from there using combo-layer though I suspect. (This is the plan I have for meta-baryon.)
Agreed. I've been attempting to push the obvious fixes to packages in oe-core back there, and meta-oe/meta-multimedia is an obvious home for the bulk of the rest. Guacamayo should ideally be an integration and customisation home consisting of bbappends and guacamayo-specific recipes only, IMHO.
Ross
Hi Saul
Quoted 1 line · Saul Wold
My apologies, I updated the MAINTAINER and README files.
Thanks.
Quoted 7 lines
Quoted 4 lines
(I am delighted Intel is finding Guacamayo useful, but the obliteration of the history makes it look as if the credit for this official Yocto layer goes to Intel; I am sure that was not intentional.)
No this was not intentional, the combo-layer tool seems to do that. I used combo layer because we wanted to pull in the kvm changes so that this could be shown as a VM.
Well, Poky uses the combo-layer and it maintains the commit history, even nicely injects the original hashes into the commit messages for reference. My basic gripe is that the 'Initial meta-dlna creation' commit squashes some 370+ commits, which represent somewhere in the region 500 man hours, bulk of it by sleep(5) ltd. I'd prefer if a public layer in a Linux Foundation collaborative project did not do away with that.
Quoted 2 lines
In the first pass, there were mostly minor changes to cut this down to what was needed for the headless media server.
This is the bit I don't get; it's not like oe-core contains just what is needed for poky-tiny, but I don't see you creating an oe-core fork for it. In fact this makes so little sense I doubt it was an engineering decision, perhaps someone somewhere forgot to take their NIH pills? :)
Quoted 3 lines
As I moved to 1.3 there
were more changes that I have made, you can see what's going on in the 1.3wip branch of meta-dlna.
You are already getting bitten by the fact that you are forking meta-guacamayo. Upstream master has been updated to work with 1.3 some time back. It took fair amount of work to do (more than I'd have expected; lot of work to get things to build, and then quite a bit more to get them work).
Quoted 1 line
If you want some of those changes in meta-guacamayo please take them.
Why is Intel so crap at working with upstream projects? I'll happily take any meaningful contributions (that excludes adding MACHINE_FEATURES='x86' into the layer.conf, though!), but please submit them.
Quoted 1 line
Right now I am fighting a dbus/rygel segfault.
I am pretty sure I know which one, you are welcome to update to upstream meta-guacamayo, forks really are not a cost-efficient way of doing things.
Kind regards,
Tomas
Quoted 3 lines · Paul Eggleton
On Friday 19 October 2012 11:01:09 Saul Wold wrote:
Long term however I'd rather see the additional unique recipes in meta- guacamayo itself go into more official OE community layers.
Ah, so there is an official community and an unoffical one, this community stuff is becoming rather difficult. ;-)
I don't have any objections in principle, in fact you will see that number of the recipes in meta-guacamayo consists of a generic recipe and a guacamayo-specific bbappend. The main reason for maintaining most of the recipes in meta-guacamayo is precisely so that they would be maintained and updated in timely fashion and work with the stable release of Yocto. Guacamayo aims to facilitate that.
Tomas
Quoted 7 lines · On Monday 22 October 2012 09:06:41 Tomas Frydrych wrote:
Quoted 3 lines · Paul Eggleton
On Friday 19 October 2012 11:01:09 Saul Wold wrote:
Long term however I'd rather see the additional unique recipes in meta- guacamayo itself go into more official OE community layers.Ah, so there is an official community and an unoffical one, this community stuff is becoming rather difficult. ;-)
I was referring to the meta-openembedded repository on openembedded.org. If people are looking for recipes they're going to be looking for them there first
- surely it would be better that they'd find them there rather than just assuming they haven't been written and writing new ones themselves...?
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre