Development

262 MB

263 MB

264 MB

On 16/04/2015 10:11 PM, Dane Scott - TuneTracker Systems tunetrackersystems@xxxxxxxxx wrote: Hey there, For a feature request (as opposed to a bug report), what’s the best place dev.haiku-os.org is the right place. A ticket can be tagged as an enhancement. ...

Hey there, For a feature request (as opposed to a bug report), what’s the best place to post it? Here, at dev.haiku-os.org, or some other location? I want to see if it’s possible to add a feature to SoundRecorder so that it remembers its save-as location from one session to the next. Currently, it’s hard-wired to insist on /home (requiring browsing every time, to save elsewhere unless you do a drag and drop save). ...

On 15/04/2015 19:16, Jérôme Duval wrote: 1) Remove this from the default include path, and let applications needing it manually pass the required -I options to the compiler. 2) Protect all the extensions with a define (such as BSD_SOURCE) and require applications to define that. This is what is done in glibc (using features.h to control what is or is not included), so it would be a more usual solution, possibly saving us some work in configure scripts ...

On Wed, Apr 15, 2015 at 07:12:26PM +0200, Jérôme Duval wrote: useable. For the nightlies this is not a problem, as we can update the repos with new packages as problems are found. For the releases, there is a different maintenance plan where only the haikuports packages can be updated (not the core haiku ones). And even there, we must take care of not breaking anything (for example our current unzip package is broken and will crash on some files). We should also make sure there are ...

2015-04-14 19:03 GMT+02:00 Adrien Destugues pulkomandy@xxxxxxxxx: 1) Remove this from the default include path, and let applications needing it manually pass the required -I options to the compiler. 2) Protect all the extensions with a define (such as BSD_SOURCE) and require applications to define that. This is what is done in glibc (using features.h to control what is or is not included), so it would be a more usual solution, possibly saving us some work in configure scripts looking for these extensions. Leave the headers in the standard include ...

2015-04-14 7:15 GMT+02:00 Adrien Destugues pulkomandy@xxxxxxxxx: useable. For the nightlies this is not a problem, as we can update the repos with new packages as problems are found. For the releases, there is a different maintenance plan where only the haikuports packages can be updated (not the core haiku ones). And even there, we must take care of not breaking anything (for example our current unzip package is broken and will crash on some files). We should also make sure there are ...

fixed:

Implemented by Hamish in hrev49143.

* Allows use of either CLOCK_REALTIME or CLOCK_MONOTONIC as the time base for pthread_cond_timedwait(). * Allows use of either CLOCK_REALTIME or CLOCK_MONOTONIC as the time base for pthread_cond_timedwait().

Hi, I am working with the cdrecord developer to get it working on Haiku again. We found that /system/develop/headers/compatibility/bsd is in the compiler default include search path. This is a bit annoying, because the purpose of this folder is to hold non-standard functions we copied from the *BSD. This means the function names are not reserver and possibly a standard C application could redefine them (and use the same names for something completely different). ...

On Tue, Apr 14, 2015 at 4:28 PM, Axel Dörfler axeld@xxxxxxxxxxxxxxxx wrote: releases and snapshot releases. Snapshots are taken at a point in time when code is more stableish. ...

Am 14/04/2015 um 16:04 schrieb kallisti5: Any thoughts on going the Cyanogenmod route? Cyanogenmod has nightly releases and snapshot releases. Snapshots are taken at a point in time when code is more stableish. I think that sounds like a somewhat neat solution to our immediate lack of a release. ...

On 2015-04-14 08:52, kallisti5 wrote: On 2015-04-14 08:38, Adrien Destugues wrote: As for alpha / beta release repositories... Lets just set them to current by default and be done with it. ...

Am 14/04/2015 um 15:25 schrieb kallisti5: I still don't understand what is so horribly known broken. (trac also confirms 0 blockers that are PM related). Our packages do need rebuilt and refreshed, but given you can install a nightly from a year ago and continuously update the same installation through today... that's pretty stable for nightly software :-) ...

On 02/01/2015 06:54 AM, Chris Hanson wrote: On Jan 30, 2015, at 11:22 PM, Humdinger humdingerb@xxxxxxxxxxxxxx wrote: I have to admit that I haven't had to roll back yet, but I image that I wouldn't roll back farther than to one of the last few states. Therefore, I'd be comfortable to manually delete all state-folders but the last few newest ones every few months (if I ...

On 2015-04-14 00:15, Adrien Destugues wrote: On Mon, Apr 13, 2015 at 08:42:04PM -0400, Andrew Hudson wrote: I also think we should now revisit whether the next release is Alpha or Beta. It's been quite a long time since our last serious release discussion, and since that time it is not clear to me that we have made any substantial progress towards resolving the package management issues. ...

Am 14/04/2015 um 14:47 schrieb kallisti5: I already did this quite some time ago. We could add a warning that the last release is already quite outdated, and does not reflect the status quo. ...

On Jan 30, 2015, at 11:22 PM, Humdinger humdingerb@xxxxxxxxxxxxxx wrote: I have to admit that I haven't had to roll back yet, but I image that I wouldn't roll back farther than to one of the last few states. Therefore, I'd be comfortable to manually delete all state-folders but the last few newest ones every few months (if I need space). Excellent, I haven’t had to roll back either (I’m just using VMware and take a snapshot before I update) but the state folders didn’t all have exactly the same set of packages so I was initially wary. Things seem just fine having ...