Latest Bugs & Tasks
A great addition to pkgman would be to have a get-url function which would only display the url for a package, and not install said package.
One use-case for this is in HaikuPorter, where we need to download pre-built packages but do not want them installed in /system/packages. By having the URL, we could then download the packages ourselves into a different directory of our choosing.
This is a patch to solve a TODO in src/kits/app/ServerMemoryAllocator.cpp
I couldn't test it, but i post it for review here. Don't hesitate to comment !!
When working on the recipe for NFD with a GCI student, I noticed the Zlib license we provide contains the whole header block with the C comments and also the copyright.
/* zlib.h -- interface of the 'zlib' general purpose compression library version 1.2.3, July 18th, 2005 Copyright (C) 1995-2005 Jean-loup Gailly and Mark Adler This software is provided 'as-is', without any express or implied … 3. This notice may not be removed or altered from any source distribution. Jean-loup Gailly Mark Adler email@example.com firstname.lastname@example.org The data format used by the zlib library is described by RFCs (Request for Comments) 1950 to 1952 in the files http://www.ietf.org/rfc/rfc1950.txt (zlib format), rfc1951.txt (deflate format) and rfc1952.txt (gzip format). */
It makes it unsuitable to use with other Zlib-licensed software (I made the student add a "Zlib-generic" license file for NFD, but we shouldn't need that).
Originally filled at https://github.com/HaikuArchives/PecoRename/issues/5
PecoRename starts using a lot of cpu after changing Panel background color in Appearances preflet.
It also reproduces a bug in app_server when it fails to update foreground window when moving one above PecoRename.
BSD library headers exist in several places, most notably /headers/compatibility/bsd/ and /src/libs/compat/freebsd_network/compat. The latter is a significantly more complete version, but it is unavailable to normal apps outside the tree. Making these headers available is crucial for being able to port applications which natively run on BSD to Haiku.
I have attached a WIP of merging the sys/ and machine/ folders of compatibility and freebsd_network to compatibility, where they would be available to all apps which want to use them.
As you can see, this change is quite involved. In particular, the freebsd_network headers will depend on the compatibility/bsd headers, which means that all instances in the tree that use the freebsd_network headers need to have their Jamfile modified. I did that for a handful of instances where this comes up, but before I continued doing this change, I wanted to ask for comments whether this change is desirable in general.
I noticed when entering the depot in a search box, which are all available apps displayed. However, I expect the Apps with A, not all. It would be better if you were since the characters * for all app.
Mail crashes when I try to build anything with haikuporter. Possibly when it sets up chroot.
Actually, this is duplicate of #12247 ;-)
Setting IPv6 addresses to BNetworkAddress fail.
no longer crashes as of hrev50047. Setting the IPv6 address static or disabled results in an instant transition to "automatic" and settings are lost... but at least it doesn't crash :-).
Open any map in Google Maps
Zoom in/out or move map
Eventually Webpositive crashes or even locks up the system
Debug report and syslog attached
Fixed in hrev50053.
Applied (the second one) in hrev50052.
Apparently Jua forgot to mark this one as "duplicate", and the duplicated ticket is now closed.
The app_server is currently handling overlay capability of videocards quite buggy.
As fas as I saw upto now (while working on the VIA overlay engine) the app_server just once asks the driver if overlay is supported (directly after system boot). That's wrong.
Furthermore, the app_server asks this question even before the first mode was set. Also wrong. The target mode should be set, and then (only then!) the app_server should request the overlay hooks. If a new mode is set, the hooks need to be requested again.
Please have a look at the code for the overlay hook exports in the VIA driver for instance and you'll recognize why it should be as I just described (and also how Be did it!)
One important item is RAM bandwidth: this is especially an item on higher res modes, with high colorspace, on shared RAM solutions (cheaper videocards, some laptops..):
So, if the total RAM bandwidth used for the mode itself leaves not enough bandwidth for next to that fetching overlay images.. the hooks will, for these modes, not be exported.
There are more restrictions depending on hardware..
Granted, for newer cards there will be less restrictions than for older cards... Still, the way Be did it is the only theoretically correct way. (check restrictions per mode)
Since no mode is set before the hooks are requested, chances are some cards drivers don't export their hooks, as no set mode is not supported by definition. Even if they do export the hooks, overlay is not guaranteed to work correctly since the driver does not know if the mode will violate it's hardware properties.
At least the VIA driver blocks the hooks (which is correct) because of this.
Pushed as hrev50050, thanks!
Playing MPEG-4 part 2/XVID movies with MPlayer show the video at dual speed
VLC 0.8.6i can't show the movie at all
Mplayer only report:
Video: MPEG-4 part 2
VLC 0.8.6i reports:
main decoder : looking for decoder module: 21 candidates
main decoder : cannot load module `/packages/vlc-0.8.6i-1/.self/lib/vlc/codec/libflacdec_plugin.so'
main decoder : cannot load module `/packages/vlc-0.8.6i-1/.self/lib/vlc/codec/libfaad_plugin.so'
main decoder : no suitable decoder module for fourcc `XVID'.
VLC probably does not support this sound or video format.
main decoder : killing decoder fourcc `XVID', 0 PES in FIFO
VLC 0.8.6d is able to play the file without any problems and reports:
main decoder : looking for decoder module: 21 candidates
ffmpeg decoder : libavcodec initialized (interface 3349504 )
ffmpeg decoder : postprocessing disabled
ffmpeg decoder : using direct rendering
ffmpeg decoder : ffmpeg codec (MPEG-4 Video) started
main decoder : using decoder module "ffmpeg"
Here is two sample movies i found that generates this error:
ffprobe: Video: mpeg4 (Advanced Simple Profile) (XVID / 0x44495658), yuv420p
ffprobe: Video: mpeg4 (XVID / 0x44495658), yuv420p
Info about the file:
Some info about MPEG4 part 2
Modified screeninfo so that it also prints the color space and whether overlay is supported.
As in title. BeCasso translator attached, it's a good example of this.
/bin/mail is now included in the Haiku image (thanks!) but doesn't work when piping the message text via standard input (the BeOS one does work that way too).
Needs an end-of-file detection as well as the manual period on a line test. If you want to get fancy, only use the "." end of message marker when reading from a terminal. gets() returns NULL at end of file, should test for that and break out of the line reading loop at that time. Example user level usage to test it (make sure the last line of the listing gets through too):
ls | mail -s Testing me@…