Latest Bugs & Tasks

I know gutenprint supports Epson. I know we used to have Epson drivers. Tried to use my TX110 last night and it's not recognised.

The preferred wifi dongle for Raspberry Pi, a driver will be needed for the ARM port.

Comes in two varieties:

Micro dongle, ~ $3.50
Mini dongle, ~ $7.95 inc. external antenna.

Capable of being used as a router - one outgoing and six incoming interfaces.

Description says it all. I got this reading a raspbian image on a microSD card attached to USB if that helps.

As of hrev49293, my PC can no longer configure the network. Enabling tracing in add-ons/kernel/network/stack/interfaces.cpp, it appears that at the very least, configuring of the local interface is somewhat iffy, and for some reason, ethernet device never gets configured at all.

syslog before changes:

KERN: net: Interface 0xd7dd2680: new "/dev/net/ipro1000/0", device interface 0xd8576c88
KERN: net: InterfaceAddress 0xd85617c0: init interface 0xd7dd2688, domain 0xd7e52b00
KERN: net: Interface 0xd7dd2680: create domain datalink for domain 0xd7e52b00
KERN: net: InterfaceAddress 0xd8534104: init interface 0x00000000, domain 0x00000000
KERN: net: Interface 0xd7dd2680: flags changed from 0 to 1
KERN: net: Interface 0xd7dd2480: new "loop", device interface 0x82b7a860
KERN: net: InterfaceAddress 0xd89cd6c0: init interface 0xd7dd2488, domain 0xd7e52b00
KERN: net: Interface 0xd7dd2480: create domain datalink for domain 0xd7e52b00
KERN: net: InterfaceAddress 0xd89b1834: init interface 0x00000000, domain 0x00000000
KERN: net: update_interface_address(address 0xd89cd6c0, option 8902, oldAddress <none>, newAddress 127.0.0.1)
KERN: net: Interface 0xd7dd2480: flags changed from 0 to 9
KERN: net: Interface 0xd7dd2480: create domain datalink for domain 0xd8553640
KERN: net: InterfaceAddress 0xd89b1b94: init interface 0x00000000, domain 0x00000000
KERN: net: InterfaceAddress 0xd89cd570: init interface 0xd7dd2488, domain 0xd8553640
KERN: net: update_interface_address(address 0xd89cd570, option 8902, oldAddress <none>, newAddress ::1)
KERN: net: Interface 0xd7dd2680: flags changed from 1 to 4001
-- DHCP Discover
KERN: net:   /dev/net/ipro1000/0 matches
-- DHCP Offer received
-- DHCP Request
KERN: net:   /dev/net/ipro1000/0 matches
-- DHCP Acknowledged
KERN: net: update_interface_address(address 0xd85617c0, option 8902, oldAddress <none>, newAddress 10.20.30.10)
KERN: net: update_interface_address(address 0xd85617c0, option 8915, oldAddress 255.0.0.0, newAddress 255.255.255.0)
KERN: net: Interface 0xd7dd2680: flags changed from 4001 to 2001

syslog after changes:

KERN: net: Interface 0xd7dd1600: new "/dev/net/ipro1000/0", device interface 0x82bc5b78
KERN: net: InterfaceAddress 0xd8558670: init interface 0xd7dd1608, domain 0xd7e5b080
KERN: net: Interface 0xd7dd1600: create domain datalink for domain 0xd7e5b080
KERN: net: InterfaceAddress 0xd8550524: init interface 0x00000000, domain 0x00000000
KERN: net: Interface 0xd7dd1600: flags changed from 0 to 1
KERN: net: Interface 0xd7dd1000: new "loop", device interface 0x82b73998
KERN: net: InterfaceAddress 0xd873c750: init interface 0xd7dd1008, domain 0xd7e5b080
KERN: net: Interface 0xd7dd1000: create domain datalink for domain 0xd7e5b080
KERN: net: InterfaceAddress 0xd8549b2c: init interface 0x00000000, domain 0x00000000
KERN: net: update_interface_address(address 0xd873c750, option 8902, oldAddress <none>, newAddress 127.0.0.1)
KERN: net: Interface 0xd7dd1000: flags changed from 0 to 9
KERN: net: update_interface_address(address 0xd873c750, option 8902, oldAddress 127.0.0.1, newAddress <none>)
KERN: net: address is NULL! option is set addr
KERN: net: Interface 0xd7dd1600: flags changed from 1 to 4001
-- DHCP Discover
KERN: net:   /dev/net/ipro1000/0 matches
-- DHCP Offer received
-- DHCP Requests sent repeatedly, as interface is never updated

In the second syslog, notice that a second datalink domain is not created for IPv6, and the second update ends up unsetting the IPv4 local address. You can also see here the errant "fix" for a NULL address introduced in ​https://cgit.haiku-os.org/haiku/commit/?id=dd0ea64b. This fix should be reverted, as it is clearly hiding a bug rather than fixing a genuine issue.

The ethernet device never receives any calls to update the interface at all.

​​http://www.calgarysun.com/
Reading articles on the above website triggered a simultaneous debug report for Webpositive and debugger.
hrev49292 x86_64
debugger debug report attached

​http://www.calgarysun.com/
Reading articles on the above website triggered a simultaneous debug report for Webpositive and debugger.
hrev49292 x86_64
HaikuWebKit 1.4.9
WebKit 601.1.19

Not listed there:

• buildbot.haiku-os.org
• i18n.haiku-os.org
• hg.haiku-os.org

It would be a good idea to have these tracked as well?

Fixed in hrev49293.

There is a memory leak.

That's not a memory leak. Also, do you realize you're literally calling free(NULL) there?

Please see attached patch.

I'm running across programs that expect speeds of 921600 baud. As it stands termios.h only defines as high as B230400

If this is a bug, it's not one in Haiku. Please report the problem to HaikuPorts.

Fixed in hrev49288.

The columns are properly sorted if the user selects the sorting order after the BColumnListView is populated.

Updated to hrev49286 x86_64. When rebooting the system hangs on the rocket icon. Waited several minutes before second boot attempt, then booted normally.
Syslog attached.

Just got this error whilst compiling speex_x86:

resolve symbol "_ZTVN3icu13UnicodeStringE" returned: -2147478780

This is not the first time I've had symbols missing from the ICU_x86 libraries, so I consider it unusable as it stands.

If there's another explanation I'd be happy to hear it.