Latest Bugs & Tasks
This is rev:48882
Tried with haikudepot & CL, unless i'm mistaking we've moved a while ago to version 2.7.9?
here is the msg from CL
problem 1: nothing provides cmd:python>=2.6.8 needed by libxml2_python-2.9.1-1
- do not install "providing libxml2_python"
Please select a solution, skip the problem for now or quit.
This "bug" report is in a gray area between bug report and suggestion. The latest nightly I've tested (hrev 48882) allows the use of 40 bit ciphers. These are generally considered very bad to use, and easily broken. Many out-of-the-box distros disallow them completely (Linux, etc). However; it's a sticky issue because some sites that require these antiquated cipher suites may break if the browser/ssllib/network substrate doesn't allow them.
This "bug/not-bug" is therefore something that requires a judgement to be made, rather than just pointing to a particular coding problem. I'm not the expert here, but I can look at other distros that have tackled it differently. For instance, GNUtls on FreeBSD, by default, doesn't allow anything less than 128 bits. Whether this is a problem to be handled at a low level (libs) or a high level (apps) is also a matter of judgement.
IMO this should be looked at prior to R1, maybe beta, and should include scores of other security related issues, including protocol, cert, security vulnerability, and cipher issues. Maybe this is solved (or not) by a simple upgrade of the affected library versions, but I'm sure my opinion of this is not as good as the official Haiku security-dev gurus. :-)
To see the ciphersuite list currently provided by the Haiku software stack, use Webpositive and go to https://www.ssllabs.com/ssltest/viewMyClient.html
Fixed in hrev48920.
Replying to dac324:
To me it looks like the app causes a segment violation in /boot/system/lib/x86/libnetwork.so . This does not exacltly look like a third-party program issue but rather to a system-related problem.
That's absolutely not the case. If a third party program passes an invalid buffer pointer to a system function, that system function will crash. This is equally true on any other OS you can name, and in no way implies that the OS itself is at fault. As I said, please take this up with the people maintaining the Thinkfree port for Haiku. If they can determine that it's not a problem on their end, and provide a reproducible test case, then all well and good, file a ticket here. I should also note, the JVM side of things is very much a work in progress as far as the Haiku port goes, so it's not entirely improbable that it could be a bug there too.
resolve symbol "_get_system_info" returned: -2147478780
As far as this is concerned, the programs in question are built with gcc4.x. We currently don't guarantee binary compatibility on that front, and won't until R1 is out the door. As such, if it was compiled against a random older nightly, it's entirely possible for things like this to occur, especially if gcc was upgraded to a newer revision in the meantime.
This bug tracker is only for the OS itself, not third party apps. As such, a crash in thinkfree should first be reported to whoever maintains it. Only if it's determined that the crash in question is a result of a bug in the OS should a ticket be filed here.
recently, I wanted to try Thinkfree Office (using the installer from Haikuware.ru.
But unfortunately, none of the apps (writer, calc, ...) could be started. They immediately crash.
Attached is the debug log.
P.S.: The component drop down menu does not seem to have an entry for Thinkfree Office, therefore I had to use General.
I've been using an HREV47259 VM inside VMware on a Windows 7 (64-bit) laptop as my main e-mail machine (via BEAM) since late May of 2014. Starting March 6, 2015 sending mail refused to work with the message "535 5.7.8 Error: authentication failed:". POP still works fine with the same user/password combination. (Plain password, unencrypted)
This reminded me that I had installed HREV48786 inside VirtualBox on a different computer in mid-January, and it had this same problem right from the start. In this case it was a 32-bit version of Windows Vista acting as the host. (I filed it under "figure this out when I find time," and it never made it back up to the top of my To Do list.)
In my trouble shooting, I did a fresh install of HREV48871 on two more machines inside VirtualBox: one a Win7-64 machine, the other a Manjaro Linux host. They both refuse to send mail in their Haiku VMs with the same error. SMTP works on both these machines both in the host OSes and in Linux-based virtual machines.
I've played around with all the settings that might have anything to do with networking, with no success. I'm stumped.
Between the last successful e-mail send and when SMTP gave up, I don't think I made any changes in to the host OS or VMware on the machine that used to work but stopped. I believe I did change the account password in that time period, but the old password was the one that refused to work in the first place on the Vista machine, so that seems unlikely to be the culprit. Even if it was, say, the special characters in the password, I tested it out with a dictionary word + a single number password...no dice. Also, I'd tried sending on both port 25 and 587, so that's not it. And it doesn't seem like it's a problem with the mail server or mail account in question, because I tried it out with more than one account and mail server. Plus, why would it work for POP, but not SMTP? Sigh.
I took one stab at trying to use Mail to send, but it died silently--as Mail is wont to do--and I don't think I ever got it to work even last year when BEAM worked without porblems, so I don't know if this is specific to the application.
recently, I encountered the following problem:
Backed up an installation directory for a Haiku app to a NTFS partition. When copying the files back to a newly created BeFS partition, the binary file of the app cannot be started any more (The file cannot be opened with Tracker("Invalid argument")).
Expected behavior: The restored app should start without any errors.
Apparently, some meta-information gets lost if a binary file is copied to a NTFS partition.
for my network connection here, I have to configure a proxy for HTTP and HTTPS.
Unfortunately, only HTTP pages load properly, HTTPS pages do not. WebPositive is then stuck at "Request sent..." and nothing else happens.
Haiku has made it into the news on German Heise Newsticker.
Having already read about the OS and its history before, I decided to give it a try. Downloaded the latest Anyboot image and wrote it on an empty USB stick.
The stick first failed to boot ("could not find a bootable partition") but that could be fixed by attaching the USB stick directly to the PC and not via USB hub.
But the second attempt to boot Haiku was not successful either.
unhandled page fault in kernel space at 0x0, ip0x816592f3
I have no clue how to remedy this. The PC is a Dell Latitude E7440 laptop with an Intel Core i7-4600 and 8 GB RAM (which should be fairly enough in my opinion for a modern OS).
Seems that this was it for Haiku here, what a pity. I was indeed curious.