Re: [E-devel] Quality of bugs on phab
On Sun, Jul 29, 2018 at 2:22 AM Carsten Haitzler wrote: > > On Sat, 28 Jul 2018 09:03:11 + jaquil...@eagleeyet.net said: > > > Hi Guys, > > > > I think a good place for me to start as I fight with getting things > > built on fedora from git is that of traging of bugs that have had no > > activity for an extended period of time. I am posting a comment on them > > to see if I get any feedback and if there is no feed back I will mark a > > note on it for those subscribed to reopen the ticket if its still valid. > > > > Also I am seeing alot of bug reports of very low quality. In the sense > > there isnt any detail as to what the issue is. Is there a work flow that > > we can setup to ensure a standard of bug reports is met in the sense > > what steps we can take to try and reproduce as well as maybe hardware > > specs. > > > > I am sending this more to open up a discussion on this as i feel like > > phab should be used to help us report issues that developers can then > > try to reproduce and if replicated fixed. > > well TBH there isn't much you can do about what reporters will report. you ask > questions. often it's hard to get the information (people are unable to > provide > it - too complicated to get a backtrace for example - packages with no debug > symbols etc.). sometimes the backtrace is useless. (dies inside libc malloc > sanity checks - bug happened elsewhere and would need valgrind to know more). > sp it's often a conversation digging out more information. if that > conversation > stops (without a resolution or a "this needs to be handled later" from > developers), the bug basically becomes useless. : ( Some software such as fastlane (ios/android automation in ruby) provide crash-reports in Markdown-template almost ready to be pasted into the ticket. Includes things such as: - backtrace (harder in C/efl, but still manageable in some cases) - OS version (ie: /etc/os-release) - version of some libs (we could use the path to libs linked into crashed process, usually they include the minor soname, which helps) and of course some kind of questions: - what were you doing when the crash happened? - can you reproduce the crash? If yes, please list steps I don't remember if it was fastlane, but some software I've used even did a REST call to search for similar issues (issues with similar backtrace, not sure how they implemented that). BR, -- Gustavo Sverzut Barbieri -- Mobile: +55 (16) 99354-9890 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Licenses & Linking
Hi all, I also remember the eina lgpl being intentional, one of the reasons is that it might be possible to argue that to the rest of the efl libraries, eina / efl (also lgpl) are more then just libraries that the rest of efl uses and therefore the rest of the efl libraries should be treated as derivative works. This will likely get slightly more complex when we as upstream start merging libraries. Probably the safest way legally would be to treat all of the efl as lgpl and provide objects in such a way that you can relink any part of the efl. But I am not a lawyer and its probably one of those ambiguities where without it going to court we will never actually know so most companies legal teams will advise them to take the safest possible interpretation atleast in my experience. On 30/07/18 05:56, Andrew Williams wrote: > Hi Stephen, > > I was probably over-simplifying but in the context where static-linking is > required then the LGPL forces certain behaviours which the BSD does not. > My understanding is that this applies to anyone linking statically to any > part of EFL as they (mostly) all depend on Eina? > > Reading from https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic If > I write a framework which is statically linked which includes the Eina > static link then the application developer must ship alternative object for > for re-linking. Additionally the app publishers would need to provide the > source code of Eina that was linked to to comply with LGPL. > > Do others have a different understanding of the situation? > Thanks, > Andrew > > On Thu, 26 Jul 2018 at 13:56 Stephen Houston wrote: > >> This was a huge argument when Eina came into EFL. IIRC the profusion guys >> that wrote Eina were adamant on it being LGPL and even looked into the >> possibility of trying to make the rest of EFL LGPL. Of course getting all >> the author permissions to do so would be impossible so that was nixed. So >> the state of things license wise is what it is today. As far as the >> implications of that, I haven't studied it much. Can you provide the exact >> language that makes you believe this to be true? >> >> On Thu, Jul 26, 2018, 6:58 AM Andrew Williams >> wrote: >> >>> Hi, >>> >>> I was checking out the situation regarding licensing and read the current >>> state in https://github.com/Enlightenment/efl/blob/master/README. As far >>> as >>> I can tell the library at the bottom of our dependency tree, Eina, is >> LGPL >>> whereas most others are BSD - which includes the main Efl library. >>> >>> As far as I can see this means that the BSD Efl lib will restrict to LGPL >>> automatically if statically linked. >>> Is that the intention? >>> >>> I was hoping to use static linking for a project but I don't want to pass >>> this restriction up stream. Is there anything I can do and/or have I >>> misunderstood the situation at all? >>> >>> Thanks, >>> Andrew >>> -- >>> http://andywilliams.me >>> http://ajwillia.ms >>> >>> >> -- >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> ___ >>> enlightenment-devel mailing list >>> enlightenment-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Licenses & Linking
Hi Stephen, I was probably over-simplifying but in the context where static-linking is required then the LGPL forces certain behaviours which the BSD does not. My understanding is that this applies to anyone linking statically to any part of EFL as they (mostly) all depend on Eina? Reading from https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic If I write a framework which is statically linked which includes the Eina static link then the application developer must ship alternative object for for re-linking. Additionally the app publishers would need to provide the source code of Eina that was linked to to comply with LGPL. Do others have a different understanding of the situation? Thanks, Andrew On Thu, 26 Jul 2018 at 13:56 Stephen Houston wrote: > This was a huge argument when Eina came into EFL. IIRC the profusion guys > that wrote Eina were adamant on it being LGPL and even looked into the > possibility of trying to make the rest of EFL LGPL. Of course getting all > the author permissions to do so would be impossible so that was nixed. So > the state of things license wise is what it is today. As far as the > implications of that, I haven't studied it much. Can you provide the exact > language that makes you believe this to be true? > > On Thu, Jul 26, 2018, 6:58 AM Andrew Williams > wrote: > > > Hi, > > > > I was checking out the situation regarding licensing and read the current > > state in https://github.com/Enlightenment/efl/blob/master/README. As far > > as > > I can tell the library at the bottom of our dependency tree, Eina, is > LGPL > > whereas most others are BSD - which includes the main Efl library. > > > > As far as I can see this means that the BSD Efl lib will restrict to LGPL > > automatically if statically linked. > > Is that the intention? > > > > I was hoping to use static linking for a project but I don't want to pass > > this restriction up stream. Is there anything I can do and/or have I > > misunderstood the situation at all? > > > > Thanks, > > Andrew > > -- > > http://andywilliams.me > > http://ajwillia.ms > > > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- http://andywilliams.me http://ajwillia.ms -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
