How to report a problem with a build from SVN?

[fam]

To get around the iscsi regression, I successfully built 3.0 from SVN (3.0.51_OSEr21206) and it worked albeit with other problems said to be "fixed in SVN". However the very latest SVN (At revision 21410) doesn't seem to be able to create any VMs at all, at least on Fedora C10. There doesn't seem to be a suitable forum or mailing list to report this kind of problem (for instance it compiles quite cleanly so it isn't a compile problem per se). Short of falling back to 2.2.4, there doesn't seem to be any way forward. Any suggestions much appreciated!

[Perryg]

You should search the VBox bugtracker (located at the the bottom of my post in my Sig.) If you do not find your issue you should report it there.

[Sasquatch]

Keep in mind that SVN revisions are still in development. It's possible that the revision you grabbed just didn't have the correct VM code yet. I don't know how the devs use the SVN exactly, but if the OSE tarball you can get from the download page doesn't work, then you have to check the revision notes. Reporting it in the Bugtracker can always help though.

[fam]

Did try submitting a bug report. It looked like it worked because it prompted foe files to upload. But it never showed up. I thought maybe somewone behind the scenes was vetting the bug reports and disallowed this one because it referred to an SVN build, hence the question here. I'll try again.

The current OSE tarball has an iscsi regression that make it unusable for me. As noted, 3.0.51_OSEr21206 did work, but there were a number of problems that were reported as "fixed on SVN", but no subsequent SVN update has worked at all - the Gnome Bug Buddy pops up as soon as I try to start any VM. I don't know if there is a way to undo SVN updates, but if there isn't, it seems like the only solution is to go back to 2.2.4. Thanks for your help. If I continue to have problems submitting bugs I'll report back here.

[fam]

This time the bug report did show up in the bug index - for a while. Then it quietly vanished. As it turns out, the problem was a highly reproducible problem in the build system, and not a new VB bug, so deleting it was justifiable, although it might have been nice to at least have gotten an email explaining why. However I do understand how busy you all are.

Doing an svn up, followed by a kmk all didn't actually build a new executable, although there didn't appear to be any errors during the build.

A kmk clean followed by a kmk all did build a new executable, but it left some libraries out, which apparently is what caused Bug Buddy to fire up.

Deleting the whole mess and starting from scratch resulted in a successful build and working VMs. This cycle is repeatable on this platform (AMD64, Fedora C10, buiding on an NFS mounted ZFS vdev), and the only workaround seems to be to build a new release from scratch every time.

So my original question really remains unanswered. This forum doesn't seem like a suitable place to discuss problems with the build system, and it seems like filing bugs against it in the public Bugzilla isn't appropriate either, judging by what happened. Any suggestions about a suitable forum to discuss problems like this would be much appreciated.

[Sasquatch]

You can try the mail thing, I forgot the name. It's on the front page, where you can subscribe to it too.

[fam]

Thanks. Yeah. Tried that, too. I guess the developers don't want to be disturbed . If they are interested in researching the build problem they can find me. Otherwise I'll just keep building from scratch...

[fam]

3.0.2 seems to be working very nicely (Fedora C10 host, OpenSolaris snv177 guest). I am impressed at how quickly the defects are being addressed. Great work! So now I have a couple of SVN questions.

Apart from the obvious redirection, is there a way to capture the build log?

The build sources are on a ZFS vdev via an NFS mount. As it builds there are a couple of "file time is in the future" messages which might account for the problem with building after an svn up that not everything gets rebuilt.

The guest additions "CD" is consistently not being updated. Perhaps this is another effect of the file timestamp problem, or is there some configuration parameter that causes Virtualbox to get it from an earlier source (this even happened after a rebuild from scratch)?

If this was a generic problem undoubtedly it would have been fixed by now. Are there any SVN experts in this list who could shine some light on this?

Thanks

[baf]

Make sure that both computers have the same time. use ntp or something to sync them.
This is a normal problem for make and possibly also svn. Or put the source on a local disk.

[fam]

Yes, they are synched hourly with rdate, although I've never seen them differ by more than a few seconds. Upon doing some more Googling, it seems this is a known problem with SVN and out of scope for this forum. Thanks for trying to help though.

However, for some reason it seems like a regular "kmk all" isn't building VBoxGuestAdditions.iso at all, so the one from whatever release was last installed is the one that the VM sees. Should it be building VBoxGuestAdditions.iso? If so, any idea why it isn't? And if not, how to build it?

Thanks

[MKhaos7]

Hey fam!
SVN bugs are NOT suposed to be reported to the bugtracker. If you are usign SVN (like i do) you should post your doubts at the vbox-dev mailing list (that can be found at http://www.virtualbox.org/wiki/Mailing_lists). Also, the devs are very participant on the mailing list and provide, usually, prompt feedback on the issues presented and are always very helpful.

Also, FWIK, the iso it not build by default when compiling from source. Simply because the OSE version doesn't provides ways to package the additions (create install scripts/.exe). Because of this I always keep using the latest PUEL additions (3.0.2 at this time).

Hope these are of some help for you.

[fam]

Thanks MKhaos7!

SVN bugs are NOT suposed to be reported to the bugtracker

.
I thought as much. That's why I posted here originally. I did try subscribing to the vbox_dev mailing list but I never got a confirmation. Maybe I should try again...

Also, FWIK, the iso it not build by default when compiling from source.. Simply because the OSE version doesn't provides ways to package the additions (create install scripts/.exe). Because of this I always keep using the latest PUEL additions (3.0.2 at this time).

Again, thought as much. But since manually copying the iso wouldn't be difficult, it would be nice if there was a way to build it with the OSE version - it seems that getting the OSE version from svn includes the source of the additions, so all that would presumably be required would be suitable make files. Oh well - they must have their reasons

Hope these are of some help for you.

Sure were. Thanks again.

[MKhaos7]

Again, thought as much. But since manually copying the iso wouldn't be difficult, it would be nice if there was a way to build it with the OSE version - it seems that getting the OSE version from svn includes the source of the additions, so all that would presumably be required would be suitable make files. Oh well - they must have their reasons

Hey fam, actually the additions code does come with the OSE and it does get build when you are building VirtualBox (linux additions when building on linux and windows additions when building on windows). The problem is that they (the devs) doesn't provide a installer for neither of them.
Linux install shouldn't be so hard (specially because many distros already package linux additions). The major problem is with the windows build. There is a guy (http://code.google.com/p/virtual-box-wi ... installer/) that does offer an installer for VBox Windows additions, but they aren't 100% yet. Also, he is still working on getting 3.0 OSE additions to build correctly (you will se some of hist posts on vbox-dev ML).

[fam]

Doh! Unless you have all kinds of cross platform toolchains set up, of course you have to build the additions on the target platforms. What was I thinking? Clearly creating the iso itself is no simple matter.

Thanks again for clearing this up.