Latest Bugs & Tasks
While you're at it... :)
Hopefully fixed in hrev47109. I can at least say that the build wasn't broken here when building "haiku-image" or "scsi_periph"... No clue yet.
Sometimes while building packages using haikuporter job runner thread of pacake_daemon starts to consume a lot of cpu without ever stopping.
I debugged the thread in question and it looks like it stucks comparing something in BString::eq
Restarting package_daemin makes this problem go away.
Thanks Urias, but I'm afraid that's only half of the story. We also need to update our certificates, as they may have been compromised.
Updated vmweb, vmdev, vmrepo, and baron - you can verify with:
FYI, I noticed that dev.haiku-os.org and haiku-os.org are both vulnerable to the HeartBleed vulnerability.
It can be tested with: http://filippo.io/Heartbleed/
More info on openssl vulnerability: http://heartbleed.com/
Is it possible to make zip and rar running like window and linux?
- Running programs out of a zip/rar file
- Storing Date in a exisiting zip/rar file
- Set a password to a zip/rar file
- Open a zip/rar file with password
as of hrev47102, the issue has returned.
With hrev47102, the clipping issue is back.
This is hrev47102.
Opening Sounds (or any other app which uses BColumnListView) and middle clicking column separator crashes the app.
state: Exception (Segment violation) Frame IP Function Name ----------------------------------------------- 0x795c30d0 0x9494be BColumn::MinWidth(BColumn) + 0x6 Disassembly: BColumn::MinWidth(BColumn): 0x009494b8: 55 push %ebp 0x009494b9: 89e5 mov %esp, %ebp 0x009494bb: 8b4508 mov 0x8(%ebp), %eax 0x009494be: d94004 fld 0x4(%eax) <-- Frame memory: [0x795c30c8] .1\yQ... a8 31 5c 79 51 e2 94 00 0x795c31b0 0x94e24c BPrivate::TitleView::ResizeSelectedColumn(BPoint, bool) + 0x28 0x795c3260 0x9500a2 BPrivate::TitleView::MouseDown(BPoint) + 0x55a 0x795c3460 0x7d1bfd BWindow::DispatchMessage(BMessage*, BHandler*) + 0xf49 0x795c3490 0x947cb4 HWindow::DispatchMessage(BMessage*, BHandler*) + 0x38 0x795c34f0 0x7d6a4a BWindow::task_looper() + 0x28e 0x795c3520 0x6f36bd BLooper::_task0_(void*) + 0x3d 0x795c3548 0x1afc621 thread_entry + 0x21 00000000 0x604cc250 commpage_thread_exit + 0
Closing as fixed.
Currently Haiku Depot installs user installed apps to '/boot/system/packages'. Before Package Management was merged, the user could install Haiku over the previous install and only the 'System' directory was a fresh install. Now that all the apps are installed to '/boot/system/packages', user installed apps get wiped when Haiku is re-installed!
There is a need for a separation between the system packages and the user installed packages! I propose that all user installed apps be installed to '/boot/home/config/packages' and virtually extracted to '/boot/home/apps'. Then Haiku Depot could create symlinks of the installed apps to /boot/system/apps.
If Linux or BSD's distos do not have user apps installed to '/bin', or '/sbin' for good reasons, then why would Haiku (which is a single user OS by the way) install apps into the system directory? Never mind the extra work that the user now must go through to reinstall their apps (which can take a long time on slow dsl or dial-up): another concern that I have is potential flaws and bugs in PM and Haiku Depot that can pose great risk to the integrity and security of the system!