Latest Bugs & Tasks
Applied in hrev49468.
This is hrev49292.
I have manually set primary and secondary DNS servers on Windows. The primary one is not available depending on where I am, but falling back to the secondary one is usually no problem. VirtualBox correctly communicates those settings to Haiku, so my /boot/system/settings/network/resolv.conf looks something like this:
nameserver 10.0.0.101 nameserver 188.8.131.52 domain fritz.box
Now, attempting to build Haiku results in all targets of type DownloadLocatedFile1 failing, which means that it is not possible to build Haiku (I guess it can be bootstrapped, I have not tried that). The reason for this is simple: wget is called with the argument --timeout 10. That this is the problem is easily verified:
~> wget --timeout 10 google.com --2015-07-28 13:09:21-- http://google.com/ Resolving google.com... failed: Operation timed out. wget: unable to resolve host address ‘google.com’ ~> wget --timeout 10.1 google.com --2015-07-28 13:09:35-- http://google.com/ Resolving google.com... 2a00:1450:4001:803::1007, 184.108.40.206, 220.127.116.11, ... Connecting to google.com|2a00:1450:4001:803::1007|:80... failed: Network is unreachable. Connecting to google.com|18.104.22.168|:80... connected. HTTP request sent, awaiting response... 302 Found
Compare this to the values that can be found in /boot/system/develop/headers/posix/resolv.h:
130 #define MAXNS 3 /* max # name servers we'll track */ ... 134 #define RES_TIMEOUT 5 /* min. seconds between retries */ ... 139 #define RES_DFLRETRY 2 /* Default #/tries. */
It appears the requests at 0 and 5 seconds go to the first DNS server, and at 10 seconds, the second DNS server would be tried, but when building Haiku, the timeout is already reached and the target fails.
So, either the timeout when building Haiku needs to be increased or the order in which DNS servers are queried needs to be modified.
Regarding the latter idea:
I tested the same on Debian (with /etc/resolv.conf and /usr/include/resolv.h exactly matching) and wget succeeds with a timeout of 10, fails with a timeout of 5, but succeeds again with a timeout of 5.1. I assume that Debian recognizes that the request to the first DNS server was unsuccessful and tries the other DNS servers before retrying the first one. An advantage of that is that all other DNS requests (for instance when browsing the web) are delayed by "only" 5 seconds rather than the 10 seconds observed on Haiku when having to fall back to a secondary DNS server.
I tried searching for docs on how to work with our unit tests, but didn't find any good info.
What I'd hope to find is where they are (src/tests?), how to build them and how to run them.
To me it looks like you add the tests you want to the image and run them in the build. Any better way? Perhaps to run them on the host platform?
Fixed in hrev49465.
BNetworkAddress v4AddressA("192.168.1.100"); BNetworkAddress v4AddressB("192.168.1.100"); BNetworkAddress v6AddressA("feed::dead:beef"); BNetworkAddress v6AddressB("feed::dead:beef"); ASSERT_TRUE(v4AddressA.Equals(v4AddressB)); // PASS ASSERT_TRUE(v6AddressA.Equals(v6AddressB)); // FAIL
BNetworkAddress v4Address("127.0.0.1"); BNetworkAddress v6Address("::1"); ASSERT_TRUE(v4Address.IsLocal()); // PASS ASSERT_TRUE(v6Address.IsLocal()); // FAIL
BNetworkAddress address; ASSERT_TRUE(address.IsEmpty()); address.SetTo("::1"); ASSERT_FALSE(address.IsEmpty()); // Test unit fail
Implemented in hrev49464.
Newer versions of GCC produces this warning at this line
error: the compiler can assume that the address of 'service' will never be NULL
This probably means that the compiler knows that delete checks for NULL pointers, whereas it also knows that the address of 'service' cannot be NULL. The delete check might then be pointless.
To fix this, I'd move 'service' to a pointer and adjust all callers.
Probably settings file of fs corruption. Pleas reopen if you can still reproduce it.
DataTranslations window width jumps when walking through the list of translators which is not that nice.
The same problem with Tracker's settings and Network preflet (in some locales)
After clicking Test button (and before screensaver is started) it can be seen that config view becomes empty and preview is changed to No preview available.
It would be nice to be able to press Alt+I to get Tracker's info window regarding currently displayed image.
Restarting media services fails if Media preflet is closed before this process is finished.
Horizontal resize is currently not possible.
Still unable to save there, probably because Screenshot doesn't create B_USER_NONPACKAGED_DATA_DIRECTORY folder on save.
Deskbar crashed during shutdown
The fix was not 100% correct, the apect ratio was maintained, but when previewing a very large window and then switching back to previewing the whole screen, the preview was unnecessarily small. I attached another patch to fix the fix, so to speak.