Latest Bugs & Tasks

Syndicate content Haiku
Trac Timeline
Updated: 50 min 29 sec ago

Ticket #11832 (Find out if Drupal 6 can run on PHP-5.6) created

Thu, 2015-02-05 20:34

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.

Categories: Development

Ticket #3105 ([Deskbar] empty menu in Deskbar) closed

Thu, 2015-02-05 20:30

Resolved in hrev48776.

Categories: Development

Ticket #11831 (Form an opinion if we should switch from MySQL to MariaDB on vmweb) created

Thu, 2015-02-05 20:26

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.

Categories: Development

Ticket #11830 (Provide testing installations for code review tools) created

Thu, 2015-02-05 20:19

Haiku is in need of a code review infrastructure.

In order to let developers/contributors evaluate the different tools available, it would be best to provide test installations.

Here's a (possibly incomplete) list of the potential candidates:

  • gerrit
  • gitlab
  • phabricator

I had started to look into providing those by means of docker images, but that turned out to be somewhat more complicated than I expected. In order to avoid having to install and run docker on baron, I have set up docker on my own server, but so far have only managed to get an instance of phabricator running.
Additional docker images for gerrit and gitlab would be nice. Once we have working images for those, I could host them on my server for evaluation purposes (if needed).

Categories: Development

Ticket #11829 (Form an opinion if/which services running on baron directly should better ...) created

Thu, 2015-02-05 19:39

Currently, a couple of services run on baron directly:

  • buildbot master
  • rsync daemon feeding our mirrors

From a security perspective, this isn't very nice, as baron is the hypervisor, which means that any break-in via a service running on it could provide access to all VMs, too. Having those services run in a (maybe additional) VM would limit the risk of an intrusion at least to some extent.

Some of these services (most notable: and the mirror feed) have been put onto baron for a reason: they place considerable demands on network bandwidth and disk space, so moving them to a VM isn't straightforward.

Categories: Development

Ticket #11828 (Look into using one-time-passwords as secondary authentication method for ...) created

Thu, 2015-02-05 19:25

During last BeGeistert, Jonathan Schleifer suggested to use OTP as secondary authentication method on baron, such that people logging in via ssh would have to produce the appropriate one-time-password, too.

While this kind of two-factor-authentication seems to much of a hassle on things like, I think it makes a lot of sense for baron itself (i.e. the hypervisor machine), maybe even for vmdev and vmweb.

One way of implementing this would be to install and configure ​the oath toolkit on whatever server we'd like to experiment with first. The respective SUSE-packages are pam_oath and oath-toolkit, provided by the security-repository.

Of course, for this to work, all admins would need to have some compatible client app running on their smartphone, as otherwise they could no longer log in. One of these apps is FreeOTP, but I think Google Authenticator should work, too.

I have no idea whether to use the time-base (TOTP) or event-based (HOTP) algorithm, so the pros/cons of these require some more research.

This link could be useful: ​, this is describing a setup for RHEL/CentOS, but it shouldn't be too difficult to transfer to openSUSE.

Categories: Development

Ticket #11827 (Upgrade baron and all VMs to openSUSE-13.2) created

Thu, 2015-02-05 18:52

Baron and the VMs are currently running openSUSE-13.1, but 13.2 has been published three months ago. I have used 13.2 on several of my own systems without much problems, so I reckon it's safe to upgrade our infrastructure to it.

As usual, one interesting topic could be the upgrading of Postgresql (as newer versions of Postgresql are unable to read older DB formats, so an explicit dump/restore might be necessay). In order to simplify this, openSUSE has started to provide different versions of Postgresql as packages, so hopefully this will be easier this time around.

Another point of interest is that 13.1 introduced a problem with ssh logins using PAM being unbearably slow, which caused me to deactivate PAM for ssh logins. If 13.2 fixes the slowness (and my experience with my own server seems to suggest it does) it would be good to activate PAM again, as otherwise alternative/additional authentication methods like OTP wouldn't be possible to implement.

Categories: Development

Ticket #11826 (Try to reduce memory pressure for Trac instance) created

Thu, 2015-02-05 18:40

Our Trac instance has a tendency to use a lot of memory when there's load on it.

This is partly due to Apache's mpm_prefork module being in use. We should investigate if it can be replaced by mpm_worker or mpm_event.

Additionally, a considerable part of the memory is used by the Postgresql processes serving the DB-connections. As Postgresql apparently doesn't seem to provide a threaded server model, we should investigate if the number of Postgres processes can be reduced without much impact on the performance.

When high load leads to memory pressure, the VM becomes unresponsive rather quickly, so I guess living with a DB using only few processes is better than leaving things like they are now ...

Categories: Development

Ticket #11825 (IPv6 connectivity problems on baron) created

Thu, 2015-02-05 18:26

Some of our buildbot slaves fail when they use IPv6 to do a git clone from The error message is something along the lines of "network unreachable", i.e. indicating a routing problem.

The same buildslaves are able to connect to the buildbot master running on baron fine, most likely using IPv6, too, which leads me to think that only the VMs "behind" baron are affected by the problem.

A likely cause for the routing problems is that we are doing something wrong in our IPv6 setup with respect to router advertisements. AFAICS, baron needs to advertise all IPv6 hosts (i.e. the VMs) in its internal network to the router sitting directly in front of baron.

I remember having had problems when I set up the IPv6 support initially, which had the effect that none of the outside IPv6 traffic targetting any of the VMs was reaching baron (i.e. Hetzner's router must have filtered them out). When I asked Hetzner about it, they told me that they would switch their router to "automatic" mode. I can only assume that this means that the router now passes on all IPv6 traffic targetting our /64 network to baron. Maybe this isn't reliable and the routing stops to work when the VMs haven't produced any IPv6 traffic for some time?

Categories: Development

Ticket #11824 (Integrate an IP blacklist filter into firewall on baron) created

Thu, 2015-02-05 18:03

Our services receive quite a lot of unwanted traffic, most notably SPAM-waves hitting our Trac and Drupal instances. Additionally, there are a number of misbehaving web crawlers which produce unnecessary load on our http servers.

Supplementary to fighting the problem for each service individually (by using spamfilters and/or apache redirect rules), it seems like a good idea to try and get rid of at least part of that traffic by applying an IP blacklist filter at baron's firewall. This should reduce the bad traffic reaching baron and all of the VMs running on it.

​ipset-blacklist looks like a promising candidate for the job.

We need to investigate how that could be integrated with the SuSEfirwall configuration script, such that the IP blacklist filter persists across reboots.

Categories: Development

Ticket #11823 (Power Saver - Persistent between reboots.) created

Thu, 2015-02-05 03:16

I am running Haiku on my laptop. I use "Power Save" over "Low Latency" but when ever I reboot my laptop the setting is lost. I would like to to be persistent between reboots.

Categories: Development

Ticket #11822 (Implement B_UNDERSCORE_FACE) created

Wed, 2015-02-04 16:56

B_UNDERSCORE_FACE has to be implemented to be used as a font face.

Categories: Development

Ticket #11821 (Confusion due to changing speed unit) closed

Wed, 2015-02-04 07:27

In hrev48768 I changed the code to switch to Mbps only when it reaches 10000 Kbps. It will still not show any decimals, but this leads to a maximal error of 10%, rather than 50% as it was before. the downside is there can be up to 4 digits used to show the speed.

Categories: Development

Ticket #11821 (Confusion due to changing speed unit) created

Tue, 2015-02-03 14:31

This is hrev48742.

With hrev48660 ActivityMonitor was altered to dynamically change network speed units. As it is now, I find that confusing, largely because the huge rounding errors when you get to 1 Mbps. You get Kbps until 999 Kbps, and then it just displays a rounded 1 Mbps and you don't know if your actual speed is 1.1 or 1.9 Mbps.

As my actual downlink speed often oscilates between a max of 1.6 Mbps and below 1 Mbps, the display changes between informative e.g. 637 Kbps and 1 Mbps.

Maybe the Mbps and upwards (do people already get Gbps?) could show a 1/1000 precision, so there's a smooth transition between e.g. 965 Kbps to 1.287 Mbps.

Or maybe there's a better solution...

Categories: Development

Ticket #11820 ([Shortcuts] crashes in BStringField::String) created

Tue, 2015-02-03 07:30

This is hrev48760.

Double clicking shortcuts can crash Shortcuts.

To reproduce:

  • copy attached shortcuts_settings to ~/config/settings
  • double click the first empty shortcut
Categories: Development

Ticket #11819 (Cannot open a new folder from a file panel.) created

Mon, 2015-02-02 20:12

hrev 46742

Open StyledEdit

Select Save

Right-click and select New folder

Nothing happens. No New folder is created.

Categories: Development

Ticket #11818 (Posix __USE_GNU vs _GNU_SOURCE) created

Mon, 2015-02-02 16:26

we seem to be all over the map on our GNU posix extension macros...

/Builds/haiku/headers/posix> grep -R __USE_GNU *
regex.h:#ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
regex.h:# ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
regex.h:#ifdef __USE_GNU
signal.h:#ifdef __USE_GNU
/Builds/haiku/headers/posix> grep -R __USE_GNU *^C
/Builds/haiku/headers/posix> grep -R "_GNU_SOURCE" *
stdio.h:#ifdef _GNU_SOURCE
stdio.h:#endif /*_GNU_SOURCE*/
string.h:#ifdef _GNU_SOURCE
string.h:#ifdef _GNU_SOURCE
wchar.h:#ifdef _GNU_SOURCE
wchar.h:#ifdef _GNU_SOURCE

Our libroot tests also reflect the confusion as they were mixed and some broken.

I think _GNU_SOURCE is the correct way to go... not sure however so I'm opening this for someone smarter than me :-)

Categories: Development

Ticket #11816 (pthread pthread_attr_setdetachstate crash) created

Mon, 2015-02-02 15:07


  • gcc -I./include ./conformance/interfaces/pthread_attr_setdetachstate/2-1.c -g
  • ./a.out
KERN: 30030: DEBUGGER: _numBlocks > 0
KERN: debug_server: Thread 30030 entered the debugger: Debugger call: `_numBlocks > 0'
KERN: stack trace, current PC 0x1d3a70d4fc9  _kern_debugger + 0x9:
KERN:   (0x7f1f9b181360)  0x1d3a7178f5e  _ZN8BPrivate11processHeap4freeEPv + 0x18e
KERN:   (0x7f1f9b1813a0)  0x1d3a7179aa0  free + 0x40
KERN:   (0x7f1f9b1813c0)  0x1d3a70e2598  pthread_join + 0x88
KERN:   (0x7f1f9b181400)  0x13d1368dc42  main + 0x9d
KERN:   (0x7f1f9b181430)  0x13d1368dac1  _start + 0x51
KERN:   (0x7f1f9b181460)  0x7977d707e3  runtime_loader + 0xf3
KERN: debug_server: Killing team 30030 (./a.out)
KERN: debug_server: TeamDebugHandler::Init(): Failed to get info for team 30030: Operation on invalid team
KERN: debug_server: KillTeam(): Error getting info for team 30030: Operation on invalid team
KERN: debug_server: Killing team 30030 ()
KERN: 30049: DEBUGGER: _numBlocks > 0
Categories: Development