Ticket #1976 (new bug)

Opened 9 months ago

Last modified 9 months ago

Installing Development package failes

Reported by: plfiorini Owned by: bonefish
Priority: normal Milestone: R1
Component: Build System Version: R1 development
Cc: Blocked By:
Platform: x86 Blocking:

Description

Haiku rev24633, buildtools rev24633. Here's my UserBuildConfig: ######################## # Install Haiku on device /dev/sda57. Be sure you know what you're doing! HAIKU_IMAGE_DIR = /dev ; HAIKU_IMAGE_NAME = hda2 ; #HAIKU_DONT_CLEAR_IMAGE = 1 ;

# Add symlink/file (timezone and keymap settings) to the image. AddSymlinkToHaikuImage home config settings

: /boot/beos/etc/timezones/Europe/Rome : timezone ;

AddFilesToHaikuImage home config settings : <keymap>Italian

: Key_map ;

AddOptionalHaikuImagePackages Development ; ########################

Haiku was built using gcc 2.95.3. After a successful build I added the last line to my UserBuildConfig in order to install the Development package into the image, but I got the output I'm attaching to this report.

Attachments

output.txt (35.2 KB) - added by plfiorini 9 months ago.
jam -q -j2 haiku-image output

Change History

Changed 9 months ago by plfiorini

jam -q -j2 haiku-image output

  Changed 9 months ago by bonefish

Can you reproduce this or did it happen only once?

  Changed 9 months ago by plfiorini

That was my first build with gcc 2.95.3, so I've changed the UserBuildConfig in order to get the Development package installed and ran jam -q -j2 haiku-image. If now I create the haiku-image the error doesn't happen, last lines of the output:

AddUnzipFileToContainerUnzipFilesScript <HaikuImage>haiku.image-unzip-files-dummy-home/config/bin-<download>jam-haiku-gcc2-2008-03-27.zip AddUnzipFileToContainerUnzipFilesScript <HaikuImage>haiku.image-unzip-files-dummy-develop/tools-<download>gcc-2.95.3-haiku-080323.zip AddUnzipFileToContainerUnzipFilesScript <HaikuImage>haiku.image-unzip-files-dummy-home-<download>autoconf-2.61-gcc2-2008-03-24.zip AddUnzipFileToContainerUnzipFilesScript <HaikuImage>haiku.image-unzip-files-dummy-home-<download>automake-1.10.1-gcc2-2008-03-24.zip AddUnzipFileToContainerUnzipFilesScript <HaikuImage>haiku.image-unzip-files-dummy-home-<download>bison-2.3-gcc2-2008-03-28.zip AddUnzipFileToContainerUnzipFilesScript <HaikuImage>haiku.image-unzip-files-dummy-home-<download>flex-2.5.35-gcc2-2008-03-28.zip AddUnzipFileToContainerUnzipFilesScript <HaikuImage>haiku.image-unzip-files-dummy-home-<download>libtool-1.5.26-gcc2-2008-03-24.zip AddUnzipFileToContainerUnzipFilesScript <HaikuImage>haiku.image-unzip-files-dummy-home-<download>texinfo-4.11-gcc2-2008-03-24.zip AddUnzipFileToContainerUnzipFilesScript <HaikuImage>haiku.image-unzip-files-dummy-home-<download>perl-5.10.0-gcc2-2008-03-24.zip AppendToContainerCopyFilesScript <HaikuImage>haiku.image-copy-files-dummy-beos/system/lib BuildHaikuImage1 /dev/hda2

Creating image ... 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 7,18794 seconds, 14,6 MB/s Partition::SetTo(): active: 0 Partition::SetTo(): active: 0 Partition::SetTo(): active: 0 Partition::SetTo(): active: 0 Writing boot code to "/dev/hda2" (partition offset: 399974400 bytes) ... Populating image ... Unzipping generated/download/jam-haiku-gcc2-2008-03-27.zip ... Unzipping generated/download/gcc-2.95.3-haiku-080323.zip ... Unzipping generated/download/autoconf-2.61-gcc2-2008-03-24.zip ... Unzipping generated/download/automake-1.10.1-gcc2-2008-03-24.zip ... Unzipping generated/download/bison-2.3-gcc2-2008-03-28.zip ... Unzipping generated/download/flex-2.5.35-gcc2-2008-03-28.zip ... Unzipping generated/download/libtool-1.5.26-gcc2-2008-03-24.zip ... Unzipping generated/download/texinfo-4.11-gcc2-2008-03-24.zip ... Unzipping generated/download/perl-5.10.0-gcc2-2008-03-24.zip ... Deleting old MIME database ... Installing MIME database ... Unmounting ... ...updated 246 target(s)...

  Changed 9 months ago by plfiorini

As you may already be aware by looking at my UserBuildConfig, I'm compiling from Linux (Debian 4.0 on VMWare).

  Changed 9 months ago by bonefish

Occasionally (seldom actually) I also get an error when building the image. This is pretty hard to debug, since it always works when building the next time, and it is always an error that theoretically can't happen (like in your case: copying the attributes always happens after creating the directory, so this error shouldn't be possible). I guess I'll have to add some logging to build_haiku_image and the bfs_shell.

I'll leave this ticket open for the time being.

follow-ups: ↓ 6 ↓ 7   Changed 9 months ago by umccullough

Possibly related to the use of -j2 ?

in reply to: ↑ 5   Changed 9 months ago by bonefish

Replying to umccullough:

Possibly related to the use of -j2 ?

Maybe. I think I recall having seen it also with the default "-j1", but I might be wrong.

in reply to: ↑ 5   Changed 9 months ago by plfiorini

Replying to umccullough:

Possibly related to the use of -j2 ?

Yes it is, because yesterday I completely rebuilt the Haiku image (with a simple jam -q haiku-image) without this error.

follow-up: ↓ 9   Changed 9 months ago by korli

Can this bug be closed ?

in reply to: ↑ 8 ; follow-up: ↓ 10   Changed 9 months ago by bonefish

Replying to plfiorini:

Replying to umccullough:

Possibly related to the use of -j2 ?

Yes it is, because yesterday I completely rebuilt the Haiku image (with a simple jam -q haiku-image) without this error.

Well, that's not exactly a stringent conclusion. Most of the time my -j2 build works perfectly well. There are only rare cases when it fails. I'm not even sure I've never seen the problem with -j1.

Replying to korli:

Can this bug be closed ?

The bug still exists. Why close it?

in reply to: ↑ 9 ; follow-up: ↓ 11   Changed 9 months ago by korli

Replying to bonefish:

The bug still exists. Why close it?

In my experience, using -j2 leads to problems (see bug #1116). Just my opinion, it's another not well defined issue with this flag (hence it could stay opened for a long time).

in reply to: ↑ 10   Changed 9 months ago by bonefish

Replying to korli:

In my experience, using -j2 leads to problems (see bug #1116). Just my opinion, it's another not well defined issue with this flag (hence it could stay opened for a long time).

I'm OK with leaving it open for a long time. Besides, I'd love to see it happen under Haiku. Kernel tracing should provide a nice leverage on this one.

Note: See TracTickets for help on using tickets.