Development mailing list

Syndicate content
Archive of posts for haiku-development at FreeLists
Updated: 47 sec ago

[haiku-development] Re: FFmpeg and licensing (Jérôme Duval)

Wed, 2014-07-23 23:45
2014-07-13 16:21 GMT+02:00 Augustin Cavalier waddlesplash@xxxxxxxxx: Currently, we build FFmpeg with none of their licensing options [1]. A lot of their codecs are under the LGPL or GPL. I understand that since Haiku has proprietary software using our media libraries (e.g. TuneTracker), we shouldn't enable GPL'd code. However, does anyone see a reason why we can't enable LGPL'd code? As Cian explained, it's enabled by default. See (first item of License Compliance Checklist). ...
Categories: Development

[haiku-development] Re: FFmpeg and licensing (Cian Duffy)

Tue, 2014-07-22 23:45
On 13 July 2014 15:21, Augustin Cavalier waddlesplash@xxxxxxxxx wrote: Currently, we build FFmpeg with none of their licensing options [1]. A lot of their codecs are under the LGPL or GPL. I understand that since Haiku has proprietary software using our media libraries (e.g. TuneTracker), we shouldn't enable GPL'd code. However, does anyone see a reason why we can't enable LGPL'd code? I was under the impression that ffmpeg itself *is* LGPL licenced, along with all the codecs that we have enabled - and only the GPL code is disabled ...
Categories: Development

[haiku-development] Aw: FFmpeg and licensing (Stephan Assmus)

Tue, 2014-07-22 23:45
Hi Augustin, Augustin Cavalier waddlesplash@xxxxxxxxx Currently, we build FFmpeg with none of their licensing options [1]. A lot of their codecs are under the LGPL or GPL. I understand that since Haiku has proprietary software using our media libraries (e.g. TuneTracker), we shouldn't enable GPL'd code. However, does anyone see a reason why we can't enable LGPL'd code? I don't see any reason not to change the ffmpeg receipe to include GPL and LGPL ...
Categories: Development

[haiku-development] FFmpeg and licensing (Augustin Cavalier)

Tue, 2014-07-22 15:45
Currently, we build FFmpeg with none of their licensing options [1]. A lot of their codecs are under the LGPL or GPL. I understand that since Haiku has proprietary software using our media libraries (e.g. TuneTracker), we shouldn't enable GPL'd code. However, does anyone see a reason why we can't enable LGPL'd code? -Augustin [1] ...
Categories: Development

[haiku-development] Re: Symbol resolution problem with add-ons, userlandfs (Julian Harnath)

Tue, 2014-07-22 13:45
Ingo Weinhold ingo_weinhold@xxxxxx schrieb: * libroot shouldn't leak private symbols. We should always use some kind of namespace. For C++ that's usually the BPrivate::* or B* one, for C symbols there's only __*. The latter should be used, possibly in combination with macros, so that we don't have to touch all users. This seems like the best solution to me, I'll try and go with it. Thanks! ...
Categories: Development

[haiku-development] Re: Symbol resolution problem with add-ons, userlandfs (Ingo Weinhold)

Tue, 2014-07-22 07:45
On 07/13/2014 01:30 AM, Julian Harnath wrote: while working with userlandfs I ran into a problem related to mutexes and the runtime loader. My FS-addon uses kernel mutexes, so when compiling for userlandfs it should use the implementation from kernelland_emu (libuserlandfs_haiku_kernel.so). There is a problem with mutex_init() though: libroot also has a function by the same name. So when userlandfs_server loads my FS-add- ...
Categories: Development

[haiku-development] Symbol resolution problem with add-ons, userlandfs (Julian Harnath)

Tue, 2014-07-22 07:45
Hello, while working with userlandfs I ran into a problem related to mutexes and the runtime loader. My FS-addon uses kernel mutexes, so when compiling for userlandfs it should use the implementation from kernelland_emu (libuserlandfs_haiku_kernel.so). There is a problem with mutex_init() though: libroot also has a function by the same name. So when userlandfs_server loads my FS-add- on, the runtime loader chooses the mutex_init symbol from libroot and ...
Categories: Development

[haiku-development] Booting Haiku on a MacBook Pro (Akshay Jaggi)

Tue, 2014-07-22 07:45
Hello Everyone! Booting up Haiku on a MacBook, I see that our XHCI driver is unable to find/start the appropriate PCI device, even though it is present. An issue mentioned in the FreeBSD sources is what I guess is behind this issue. Quoting - * On MacBooks, we need to disallow the legacy USB circuit to * generate an SMI# because this can cause several problems, ...
Categories: Development

[haiku-development] Re: LibreSSL (Joe Prostko)

Tue, 2014-07-22 07:45
On Fri, Jul 11, 2014 at 5:31 PM, Augustin Cavalier waddlesplash@xxxxxxxxx wrote: OpenBSD has released the first portable version of their SSL library [1]. Some developers had previously discussed migrating to it, do we still want to do that? Note that this breaks binary compatibility with OpenSSL, so doing it before the next release seems like a good idea. I'd definitely like to see a recipe for it. I just tried to compile it with GCC4 without changes, but it complains about not finding machine/endian.h, and then once you address that, it complains about ...
Categories: Development

[haiku-development] Re: LibreSSL (Augustin Cavalier)

Tue, 2014-07-22 07:45
On Fri, Jul 11, 2014 at 5:46 PM, scottmc scottmc2@xxxxxxxxx wrote: It's probably too risky to make the change this close to a release. Yeah, true. I'd hold off for now. Also would you trust anyone who uses comic sans font on their website? ...
Categories: Development

[haiku-development] Re: LibreSSL (Jérôme Duval)

Tue, 2014-07-22 01:45
2014-07-11 23:31 GMT+02:00 Augustin Cavalier waddlesplash@xxxxxxxxx: OpenBSD has released the first portable version of their SSL library [1]. Some developers had previously discussed migrating to it, do we still want to do that? Note that this breaks binary compatibility with OpenSSL, so doing it before the next release seems like a good idea. We don't even have a recipe yet. I would let others OS migrate first anyway, no need to hurry. Bye, ...
Categories: Development

[haiku-development] Re: LibreSSL (Julian Harnath)

Mon, 2014-07-21 19:45
scottmc scottmc2@xxxxxxxxx schrieb: Also would you trust anyone who uses comic sans font on their website? Read the fine print at the bottom of the site ;-) -- So long, jua ...
Categories: Development

[haiku-development] Re: LibreSSL (scottmc)

Mon, 2014-07-21 17:45
On Fri, Jul 11, 2014 at 2:31 PM, Augustin Cavalier waddlesplash@xxxxxxxxx wrote: OpenBSD has released the first portable version of their SSL library [1]. Some developers had previously discussed migrating to it, do we still want to do that? Note that this breaks binary compatibility with OpenSSL, so doing it before the next release seems like a good idea. -Augustin [1]: ...
Categories: Development

[haiku-development] LibreSSL (Augustin Cavalier)

Mon, 2014-07-21 17:45
OpenBSD has released the first portable version of their SSL library [1]. Some developers had previously discussed migrating to it, do we still want to do that? Note that this breaks binary compatibility with OpenSSL, so doing it before the next release seems like a good idea. -Augustin [1]: ...
Categories: Development

[haiku-development] Re: Media plugin support - to message or not to message (Colin Günther)

Mon, 2014-07-21 17:45
Hi Axel, Am 08.07.2014 21:09, schrieb Axel Dörfler: On 07/08/2014 07:15 PM, Colin Günther wrote: @Axel: Are you still leaning more towards the server side implementation or did your opinion shift towards the application side in the mean time? ...
Categories: Development

[haiku-development] Re: Media plugin support - to message or not to message (Barrett)

Mon, 2014-07-21 15:45
Having a media player crash might not matter much, but having a video editing software crash might cause the loss of your precious work. Since codecs are not controllable from within applications, it should be the system's duty to run them in a safe environment. Having your application not crash is just one way less someone could take over ...
Categories: Development

[haiku-development] Re: Media plugin support - to message or not to message (Augustin Cavalier)

Mon, 2014-07-21 09:45
On 07/09/2014 08:28 AM, Axel Dörfler wrote: Having a media player crash might not matter much, but having a video editing software crash might cause the loss of your precious work. Since codecs are not controllable from within applications, it should be the system's duty to run them in a safe environment. Having your application not crash is just one way less someone could take over your system. That sounds like a better solution than we currently have; however, we ...
Categories: Development

[haiku-development] Re: Media plugin support - to message or not to message (Axel Dörfler)

Mon, 2014-07-21 03:45
On July 9, 2014 at 2:15 PM Augustin Cavalier waddlesplash@xxxxxxxxx wrote: False. The design of one (or two) centric servers is flawed because what if one crashes? I've experienced this myself and it's not easy to restart it at all (end users would not be able to do it). Meanwhile, if an application crashes, you can just restart it easily. That's not entirely correct. In order to prevent crashes, it would be best to launch an extra server for each media node, and for all codecs. The media_server supervising them should always be smart enough to restart the add-on servers when needed. ...
Categories: Development

[haiku-development] Re: Media plugin support - to message or not to message (Augustin Cavalier)

Mon, 2014-07-21 01:45
On 07/09/2014 03:52 AM, pulkomandy wrote: Moving the addon handling to applications removes the need for running an extra server, which would only be used for the rare case when an add-on is installed. The only gained feature is the ability to use the newly installed add-on without having to restart the application where you want to use it. The debate is wether the cost of the extra server and additional complexity in plugins handling is worth it. False. The design of one (or two) centric servers is flawed because what ...
Categories: Development

[haiku-development] Re: Media plugin support - to message or not to message (pulkomandy)

Sun, 2014-07-20 23:45
@Adrien: Which app was the reason for moving the media plugin handling to the application side and which feature was enabled by this move? The discussion threads mention several times that by moving the AddOnManager to the application side a very important feature was rendered possible. = Your answer will help me to better understand the move to the application side and to look out for a server side way of enabling that feature. Hi, I made this change while adding HTML video support to WebPositive. On a gcc2hybrid system, Web+ as a gcc4 app would receive a gcc2 plugin and, ...
Categories: Development