Latest Bugs & Tasks
WebPositive crashes in recent build (hrev48786).
Attach debug report.
As of 2015-02-09 there is 924 GB worth of old nightlies at download.haiku-os.org (and 374 GB of haiku-repositories).
In order to free up some space, it has been suggested that we drop old raw and vmdk nightly images, keeping only ISOs and anyboots.
A raw can be created from an anyboot by running:
dd if=haiku-anyboot.image of=haiku.image bs=1M skip=$(expr $(od -j 454 -N 4 -i -A n haiku-anyboot.image) / 2048) dd if=/dev/zero of=haiku.image bs=1 seek=506 count=4 conv=notrunc
A vmdk can be created from a raw using VirtualBox:
VBoxManage convertfromraw haiku.image haiku.vmdk --format VMDK
qemu-img convert -O vmdk haiku.image haiku.vmdk
An algorithm was also mentioned, for possible future use: http://jekor.com/log2rotate
docs/welcome/*/bugreports.html points the user to haiku-files.org for downloading nightly image files.
Links in UserGuide currently point to haiku-files.org
ReadMe and ReadMe.IntroductionToHaiku both contain outdated references to haiku-files.org
The last remaining files still hosted at haiku-files.org needed for a current build seem to be the wifi firmwares, http://www.haiku-files.org/files/wifi-firmwares/
The files affected are:
In an "input" form element, a "keypress" event is not being fired for the "return" key being pressed. The expected outcome is that pressing the "return" key in such a field will cause this event to be fired and that the "keyCode" attribute of the event object will be 0x0d.
This can be seen on the home page of the Haiku Depot Server system at http://depot.haiku.org. On Firefox or Chrome, you can enter a search term in the search field (yellow bar) and press return to initiate a search. With Web+, the pressing of return has no effect.
This is hrev48784.
I've noticed that something flashes on screen after Haiku boots. I've investigated it and it turned out that it was actually mail_daemon's log window. It is reproducible by starting /system/servers/mail_daemon from Terminal.
No stack trace has been provided. It has been probably fixed in the meanwhile.
Tracker used to remember the sorting order for each folder in list mode. It doesn't anymore, and revert to reverse alphabetic, which is rather annoying. It should at the very least use forward alphabetic.
In Tracker in list mode, it used to be possible to scroll up or down by about one page using pageup/pagedown or clicking in the empty areas of the scrollbar. Now this scrolls only by 3 items, which is much less useful and makes it inconvenient to quickly navigate in the file list.
Added in hrev48781. Thanks!
Even for simple changes like this it would be nice to wrap them in a git patch (using git format-patch). This makes sure you get proper credit for your changes, and also allows you to include a commit message describing the changes made.
BeOS and Linux both detect dead network connections, while Haiku doesn't.
This is most annoying when running a BeShare server (Atrus is one, see http://haikuware.com/directory/view-details/internet-network/chat-irc/atrus plus you need the Muscle library too and the muscled daemon). Every time a connection is lost (client turned off their computer without shutting down (often because of a crash), or router was rebooted and didn't close the TCP stream) the result is a dead connection. The BeShare server and Atrus both still see the dead connection as existing, resulting in that user being logged in multiple times. With BeOS/Linux, the dead connection is noticed and disconnected after about a minute.
Maybe something to do with implementing keep-alive packets?
This happens as of hrev48788.
Steps to Reproduce:
- Boot Haiku OS hrev48788
- Launch Webpositive
- Notice that it crashes with a SEG fault
Baron grants sudoable rsync access to the backup user via ssh. This is used for pull-style filesystem syncs initiated from an external server.
In order to restrict the possible damage should an intruder ever get in possession of the private ssh key granting that access on baron, the process should be reviewed and improved.
- The authorized_keys file should be adjusted to limit access only to orange.hirschkaefer.de (and any other backup servers that we might want to use)
- The authorized_keys file should be adjusted to specify the exact command to use for the backup process (possibly a shell script residing on baron containing the exact rsync invocation).
- Instead of sudoing rsync directly, the backup process should sudo a shell script owned by root - this way an intruder can't bend the rsync cmdline to copy out interesting files.
- The rotated backups are currently push-style, i.e. they are being pushed from baron onto the external backup server using another ssh key. From a security perspective, having both push- and pull-style backups to/from the same backup server isn't nice, as a successful attacker on baron could use the push-style backup path to gain access to the backup server, too. Would the rotated backups to be pull-style, too, we could close the access path from baron to the backup server.
vmweb is still running Drupal 6 to provide our main website.
The problem is that Drupal 6 is outdated and doesn't play along with newer PHP versions - PHP fills the logs with lots of warnings about deprecated constructs and it isn't clear if these warning cause actual problems or not.
The sheer amount of modules used by our website make it difficult to maintain, so we should either upgrade to Drupal 7 or even move away from Drupal and rebuild our website by other means.
waddlesplash and puckipedia have shown interest to try and migrate our Drupal 6 installation to the current version of Drupal. Once any of them makes progress with that, we will know whether or not upgrading Drupal is a feasible option at all (it might not be, due to some of the modules we use no longer being available in current Drupal versions).
Upgrading vmweb to openSUSE-13.2 would change php from version 5.4 to 5.6.
As our Drupal6 instance is already exhibiting problems with php-5.4 (it fills the logs with messages about deprecated constructs), it could be that it causes more problems or even complete failure with php-5.6.
So we need to find out if Drupal6 can run on php-5.6 and if/how any related problems can be circumvented.
Resolved in hrev48776.
Our Drupal site running on vmweb is currently using MySQL. In the meantime, openSUSE has switched to MariaDB as default. While this does not have to be bad news, it opens a risk of MySQL not getting the same attention as MariaDB by SUSE.
I suppose it might be advisable to switch to MariaDB, but the work involved is unclear. Maybe it is just a matter of installing the mariadb packages and everything will go smoothly, but before we try, we should read up on the migration process.