Fixed typo on previous commit of expat.
Note that this moves the location of openssl, so other packages that
make use of openssl may or may not require rebuilding as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41458 a95241bf-73f2-0310-859d-f6bbb57e9c96
* add boot item support to radeon hd driver
* add edid storage to shared info
* add pull of active monitor VESA EDID to radeon hd driver (until AtomBios complete)
* EDID pulled in driver now passed to create_display_modes
* move registers to external stock xorg radeon hd register headers (lic. allows it)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41411 a95241bf-73f2-0310-859d-f6bbb57e9c96
* GS, KY and PN all share the same flag, because I'm too lazy to add their
specific code of arms, which one wouldn't recognize in the small flag
anyway... At least every country is now listed in CountryFlags.rdef, so
anyone can improve flags and simply replace the rdef data there.
* Added newly generated CountryFlags.rdef
* Added little script to create CountryFlags.rdef to build/scripts/ just in
case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41292 a95241bf-73f2-0310-859d-f6bbb57e9c96
extracts the files, even when the specified target directory exists.
Fixes#7425. Thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41211 a95241bf-73f2-0310-859d-f6bbb57e9c96
cleaned up if this 5.0.1 gcc4 built package tests out ok on a gcc2 system.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40982 a95241bf-73f2-0310-859d-f6bbb57e9c96
Updated m4 to 1.4.16.
Also updated the builds of sed and yasm.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40957 a95241bf-73f2-0310-859d-f6bbb57e9c96
There should be separate gcc 2 and gcc 4 packages instead.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40827 a95241bf-73f2-0310-859d-f6bbb57e9c96
This allows WebPositive to run on LiveCD (ISO) images again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40824 a95241bf-73f2-0310-859d-f6bbb57e9c96
Moved various packages to haiku-files.org.
Minor whitespace cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40773 a95241bf-73f2-0310-859d-f6bbb57e9c96
updated working packages are available. Should fix Pe and Web+ problems.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40725 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added ecj in DevelopmentJava: I wrote a simple script around the ecj jar.
* added symlinks for jar and a few commands, mainly because classpath was cross built.
Enables to build natively Gnu classpath.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40702 a95241bf-73f2-0310-859d-f6bbb57e9c96
Updated git to 1.7.3.5
Updated libevent to 2.0.10
Updated pcre to 8.12
Updated p7zip to 9.13
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40681 a95241bf-73f2-0310-859d-f6bbb57e9c96
Add some more info to the self made query, not perfect yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40572 a95241bf-73f2-0310-859d-f6bbb57e9c96
Tested with a network capable little application, no gui classes available.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40478 a95241bf-73f2-0310-859d-f6bbb57e9c96
Accounts are now stored in a separate file. Previously they where somehow magically assembled from the chain ids. Now its possible to remove a account temporary by removing the account file form the account folder.
Each account could have an inbound protocol, an outbound protocol and some filters.
Mails are now associated with an account and not with a chain. This required to replace the chain id attribute by an account attribute.
Replace BMailFilter and BMailChain by a less general approach. Basically the chain had a list of filters and call the ProcessMailMessage for each filter. This made it sometime difficult to understand what is going on, e.g. sometimes a filter used information gathered by another filters. The new MailProtocol and MailFilter classes are calling more dedicated hook functions, e.g. HeaderFetched or MessageReadyToSend.
As before all MailProtocol's (plus their filters) are running in their own thread.
Cleaned up the error and status window a bit. Abstracted the interface to these windows. Should be easy to write a BNotification api back-end now.
Parsing of mail headers is much faster now. Fetching the headers of a large mailbox takes ~min and not ~hour now! Initial checkout time is in the same order like Opera. The problem was the massive use of fgets in parse_header (mail_util.cpp) now the complete header is read in one go. Furthermore, only interesting fields are extracted.
Remove some unused files, BeOS relicts... Feel free to translate the mail server and remove the own language system (headers/private/mail/MDRLanguage.h).
Sorry for the remaining old (and new) coding style issues, sometime just ignore them, to many :(
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40397 a95241bf-73f2-0310-859d-f6bbb57e9c96
was rewritten to Haiku MultiAudio API.
This changeset replaces both old version of the same driver written for
BeOS R3 Sound API and ali5451 driver that handles the same audio hardware.
The driver was tested with SiS 7018 and ALi M5451 cards. Trident DX/NX
support still should be tested.
Some parts, related to ALi M5451 support were inspired by original ali5451
code so the copyright (c) 2009 by Krzysztof Äwiertnia was added in the source.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40273 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The team and thread kernel structures have been renamed to Team and Thread
respectively and moved into the new BKernel namespace.
* Several (kernel add-on) sources have been converted from C to C++ since
private kernel headers are included that are no longer C compatible.
Changes after merging:
* Fixed gcc 2 build (warnings mainly in the scary firewire bus manager).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40196 a95241bf-73f2-0310-859d-f6bbb57e9c96
So we need a little work-around to open both ends in the shell process to
avoid blocking. Apparently Haiku's FIFO implementation isn't quite conforming
yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40100 a95241bf-73f2-0310-859d-f6bbb57e9c96
including also Haiku) using FIFOs instead of Unix sockets. Advantages:
* Multiple FS shells can run concurrently, since they no longer need a unique
address.
* Killing/aborting the build_haiku_image script will automatically tear down
the FS shell as well, so there shouldn't be any stray FS shell processes
anymore. Hopefully also fixes#5498.
So far only tested under Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40097 a95241bf-73f2-0310-859d-f6bbb57e9c96
Note that the reference to GCC4 Vorbis Tools is also broken but I did not fix
it as there is no GCC4 vorbis Tools package available where all the other
optional packages are.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40043 a95241bf-73f2-0310-859d-f6bbb57e9c96
Updated curl to 7.21.3
Updated build of SDL to include off by 1 resolution fix by GCI student Daniel Marth,
and the OpenGL fix by Urias McCullough
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39940 a95241bf-73f2-0310-859d-f6bbb57e9c96
and moved it from folder bin to servers.
The print_server uses print_addon_server now to
execute printer driver add-ons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39357 a95241bf-73f2-0310-859d-f6bbb57e9c96
by the print_server to run a printer driver add-on.
This makes the print_server
1) resistant to add-on crashes
2) and memory leaks in add-ons
3) license of an add-on cannot influence the
license of the print_server since it does not
directly load the add-on anymore; might be
an issue with GPL printer drivers like Gutenprint
Transport add-ons directly loaded by the print_server
should be moved outside the print_server too.
Right now I am not aware that the transport add-ons
in the repository have any of the issues.
The Gutenprint driver has 2 + 3 that was the main
motivation to implement that now.
Disabled for now until the launch issue is resolved.
BRoster does not find the application by its
signature until it is opened in Tracker once.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39346 a95241bf-73f2-0310-859d-f6bbb57e9c96
* This is still work in progress:
Printing should work with the following restrictions:
- Color printing is untested.
- Some configuration options provided by Gutenprint are missing.
- Error reporting is missing.
- The page margins should at least to increased to 1 cm
or 0.4 Inch.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39216 a95241bf-73f2-0310-859d-f6bbb57e9c96
TODO: Create fresh gcc4 packages for several libs which are currently #'d out in the version.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39194 a95241bf-73f2-0310-859d-f6bbb57e9c96
Note we aren't yet at the point where jam can make you a floppy image due to broken vm stuff.
It might be interesting to also switch the extension used on the image, amiga emulators prefer .adf for ex.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39165 a95241bf-73f2-0310-859d-f6bbb57e9c96
which builds just the en.catkeys inside HAIKU_OUTPUT_DIR/objects/catalogs
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39130 a95241bf-73f2-0310-859d-f6bbb57e9c96
* removed the catkeys pseudo-target
* created catalogs pseudo-target, which builds all catalogs & en.catkeys(.pre)
* created LocalizedTargets pseudo-target, which builds all targets that have
been localized.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39114 a95241bf-73f2-0310-859d-f6bbb57e9c96
directory. Introduced a new variable HAIKU_MULTIPLE_LOCALIZED_TARGETS, which
gets set in any Jamfiles that contain multiple DoCatalogs invocations. This
removes the need to supply folder parameter to DoCatalogs.
* Add the DoCatalogs invocation for filepanel.
* Relocated the catkeys for Screenshot and screenshot into their respective
directories.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39112 a95241bf-73f2-0310-859d-f6bbb57e9c96
not based on the automatic path-based grist. This (in conjunction with passing
a value for the 'folder' parameter) allows multiple targets within the same
source directory to have their own catalog files.
Fixes#6741.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39109 a95241bf-73f2-0310-859d-f6bbb57e9c96
applications. The eventual goal is to have jam package a catkeys.zip,
which can be provided to the application translation websites.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39090 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use layout API in preview printer add-on.
* Use layout API in some dialogs in PDF Writer.
* Removed unused class PrinterSetupWindow from PDF Writer.
* Improved layout in print_server configuration dialog.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38986 a95241bf-73f2-0310-859d-f6bbb57e9c96
another crash at exit bug for which there is
even a ticket.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38968 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The GUI has been reworked to fix a lot of issues
and to be more efficient (for example no backbuffered
views are necessary on Haiku).
* Mouse wheel zooming in the video preview uses the mouse
position as anchor.
* Several crashing at exit bugs have been fixed.
* Rendering of audio/video happens interleaved now.
* The annoying prompt to save the project when nothing
changed is fixed.
* The quick intro documentation has been updated as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38966 a95241bf-73f2-0310-859d-f6bbb57e9c96
when the user attempts to build an incorrectly configured hybrid.
For example a GCC 2 + GCC 2 system.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38949 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Reverted part of r38901 to create the symlink
develop/abi/x86/gcc4/headers/cpp -> ../tools/current/include/g++
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38905 a95241bf-73f2-0310-859d-f6bbb57e9c96
* libstdc++.so, libsupc++.so were being created in gcc-4.3.3-haiku-100425/lib
* updated the target directory for the headers (from g++/ to c++/)
May help with #6701 -- at least #6701#comment:2
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38901 a95241bf-73f2-0310-859d-f6bbb57e9c96
generation/collection. Thanks RISC for pointing this out!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38894 a95241bf-73f2-0310-859d-f6bbb57e9c96
on it.
* This also fixes a broken build, as libalm currently does not compile.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38882 a95241bf-73f2-0310-859d-f6bbb57e9c96
a directory structure that reflects the catalogs in the repository. DoCatalogs
accepts an optional folder parameter, which allows one to specify an additional
subfolder to glob *.catkeys from. For example dstcheck in src/bin.
Improves upon r38819 and should address the concerns in
http://www.freelists.org/post/haiku/BOM-providing-catkeyszip-and-catkeyszipmd5-again,1
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38873 a95241bf-73f2-0310-859d-f6bbb57e9c96
are stored in signature-based subdirectories. This improves upon r37871 and
should allow BOM to properly harvest catkeys for online translation tools.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38819 a95241bf-73f2-0310-859d-f6bbb57e9c96
FFmpeg. It's a bit sad, but this obsoletes pretty much all other decoder
and reader plugins. Some of them were built on external libraries as well
(AC3 (not part of default image anyway, since it's GPL), APE, MusePack),
so it's not really a big difference to using FFmpeg as external library.
The format matching is greatly simplified by using B_MISC_FORMAT_FAMILY
for everything but raw audio, and the actual FFmpeg CodecID as codec tag.
The downside of this is that the AVFormatReader can no longer be used with
other decoder plugins, but it would be easy to add special cases for native
decoders we wish to support. Obviously the out of the box support for file
formats and decoders has greatly increased with this change, so there has
to be a pretty good reason now for writing a "native" decoder or reader.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38786 a95241bf-73f2-0310-859d-f6bbb57e9c96
Added BurnItNow, both a gcc2 and gcc4 build.
Added Bazaar, both a gcc2 and gcc4 build.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38665 a95241bf-73f2-0310-859d-f6bbb57e9c96
of support for these codecs and demuxer in the FFmpeg plugin. The
ogg test streams I downloaded play fine now. For example, Big Buck Bunny
would play without video before and ogg files natively encoded with the
FFmpeg plugin wouldn't play at all. Since the removed plugins were not
maintained and were based on external libs themselves, I didn't see the
point in keeping them.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38646 a95241bf-73f2-0310-859d-f6bbb57e9c96
on PPC and it was pointless to give the PPC developers trouble while
there isn't even a desktop on PPC yet. Sorry about that!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38611 a95241bf-73f2-0310-859d-f6bbb57e9c96
the build depending on the target architecture.
* Add the folder for media plugins to home/config/add-ons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38559 a95241bf-73f2-0310-859d-f6bbb57e9c96
FFmpeg plugin, which now works for much more files
in my testings.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38556 a95241bf-73f2-0310-859d-f6bbb57e9c96
Matroska support in the FFmpeg plugin. I have a few streams
to test with, most didn't play right with the Matroska reader,
many simply crash. With the FFmpeg matroska support, most files
do play fine. Seeking the audio stream is a problem, in that
the FFmpeg code does not build the index for the audio stream,
and so seeking always falls back to regions of the file that
have already played. The audio will catch up eventually and
playback will be fine again. A minority of files I could test
with don't work right, those seem all to be older files.
Overall, the support for Matroska files has much improved
with this commit. I am still investigating why FFplay has
no trouble seeking in mkv files, while the FFmpeg plugin only
seeks perfectly in video streams. It may be a problem that
the FFmpeg plugin uses completely separate AVFormatContexts
for each stream, which on the other hand allows to seek BMediaTracks
independently from each other and resolves concurrency issues.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38541 a95241bf-73f2-0310-859d-f6bbb57e9c96
man files from /boot/common/man to B_COMMON_DOCUMENTATION_DIRECTORY/man.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38495 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed the mp3_reader and mp3_decoder from the image and from
the source tree even. The mpeg123lib based decoder was crashy,
since the lib didn't cope with bad input data too well, whatever
the reason, but bad input can also be a specially crafted file.
I didn't see the value in keeping two decoders around that use
a third party library as backend. While reading in the mp3_decoder
code, I even saw that it used global variables in the mpeg123 lib
to figure out framerate and channel count, after decoding a bit of
input. Obviously this has concurrency issues.
* Removed the mp4_reader from the image. It is native code, and should
perhaps be preferred over imported code, but I don't have the
resources to look into it, and David doesn't seem to have the time
either. There are basically three types of problems with the
native mp4 reader: 1) It is way too CPU intensive. I have many HD
files that don't play at all, since there is not enough time left
for actual decoding. 2) Seeking leaves a lot of visual artifacts
(with the very same decoder plug-in), since there seems something
wrong either with finding true keyframes, or with flushing buffers
correctly. And 3) very often audio stops working at all after
seeking. Sometimes a keyframe is returned for audio which is very
far away from the wanted frame, which currently triggers bad
behavior in the audio producer node in MediaPlayer and can even
crash the media_addon_server. With the ffmpeg based mp4 reader,
none of these problems exist: Seeking is perfect, no artifacts,
CPU load is low enough for pretty much all HD clips I tested with,
and audio always works and is always in perfect sync with the video
after seeking.
If there are regressions after this commit at all (I tested a lot of
files), then I anticipate only that the ffmpeg plugin does not advertise
support for files it could actually handle (i.e. easily fixable). In
those cases hopefully a test stream can be made available. If the
native mp4 reader is improved to the point that it works as well as
the ffmpeg mp4 demuxer, we can easily switch it back, but for now, users
will prefer reliable playback.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38403 a95241bf-73f2-0310-859d-f6bbb57e9c96
