Development

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

* With the HDRGRIST change the headers must now be generated for each architecture. * With the HDRGRIST change the headers must now be generated for each architecture.

* By setting HDRGRIST to match SOURCE_GRIST in MultiArchDirSetup, the include scanning in Jam will work properly: the generated header will have the same grist as what the include scan looks for. * Remove the now unneeded workaround from netresolv Jamfile. * By setting HDRGRIST to match SOURCE_GRIST in MultiArchDirSetup, the include scanning in Jam will work properly: the generated header will have the same grist as what the include scan looks for. * Remove the now unneeded workaround from netresolv Jamfile.

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.

duplicate

Am 24/04/2015 um 22:45 schrieb Michael Mounteney: Building from git master ends with: I recently had a similar problem building Haiku when a package got downgraded. The solution was to delete the problematic packages (or just all of them for simplicity), and build again. Could help you as well -- at least the build bots don't seem to have a ...

On Apr 25, 2015, at 3:52 PM, François Revol revol@xxxxxxx wrote: Does Haiku maintain binary compatibility with BeOS R5 for PowerPC CPUs, or just Intel CPUs? Some cursory searches haven’t provided a direct answer. I’m mostly interested because it would also mean it should be possible to cross-compile… (Compiling anything on a 66 MHz BeBox feels pretty slow these days.) ...

The grist for nsparser.h doesn't include the architecture despite using MultiArchSubDirSetup, so we need to explicitly include the correctly gristed header. The grist for nsparser.h doesn't include the architecture despite using MultiArchSubDirSetup, so we need to explicitly include the correctly gristed header.

* This problem was present for the fonts with total height greater than 19 and smaller than 20. * Reduce distance between row with big fonts. * Fixes #11615. * This problem was present for the fonts with total height greater than 19 and smaller than 20. * Reduce distance between row with big fonts. * Fixes #11615.

​​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?

* The HTA website is no more and we switched to pootle with a different way to commit the translations. * Git has no properties so the propset script can't be used anymore. * The HTA website is no more and we switched to pootle with a different way to commit the translations. * Git has no properties so the propset script can't be used anymore.

* Not used directly by the build system or even included in jamfiles * Was mostly untouched (save for an OpenBeOS to Haiku rename) since the migration from CVS. * Get it from upstream if you need it: https://github.com/mjradwin/stubgen * Not used directly by the build system or even included in jamfiles * Was mostly untouched (save for an OpenBeOS to Haiku rename) since the migration from CVS. * Get it from upstream if you need it: https://github.com/mjradwin/stubgen

* Maybe fixes the dependency detection? * Maybe fixes the dependency detection?

duplicate

fixed:

Fixed in hrev49293.