(Original issue 46 created by cdesai on 2014-12-04T17:41:01.291186+00:00)

Copy paste from https://bitbucket.org/haikuports/haikuports/pull-request/259/do-not-merge-update-cdrtools-to-301-a25/diff#comment-4158357

The problem with that archive (upstream source for cdrtools) has is that it contains hard links, which aren't supported by BFS.

The 'tar' utility has an option for that,

-Q, --replace-hardlinks replace hard links with corresponding symlink when extracting

but I wasn't able to find something like that for the haikuporter python implementation which uses tarfile.

The archive that I created replaces those hard links with symbolic links.

(Original issue 4 created by scottmc on 2013-10-17T19:06:08.130403+00:00)

Haikuporter spits out the useless error message saying that a package is broken, but not info on what is broken with it. A more verbose error message would be helpful, such as the line number where the .recipe seems to be first broken on, or which commands are failing because they aren't known (such as a typo).

(Original issue 5 created by kallisti5 on 2013-10-18T02:08:08.402305+00:00)

$appsDir doesn't act like the other variables such as $libDir. You need to mkdir -p $appsDir before installing to it within the package.

I think $appsDir isn't created by default to avoid excess empty directories, but we likely should be stripping away any empty base level directories anyway.

(Original issue 42 created by pulkomandy on 2014-11-28T12:52:53.239869+00:00)

This was introduced in the last set of changes pushed yesterday. I reverted part of it otherwise it is not possible to build anything.

Running haikuporter from Haiku.

(Original issue 2 created by AdrianArroyoCalle on 2013-09-23T18:55:39.568455+00:00)

I'm trying to build libSDL but when the package was created good I mount the package and I see that the main development lib (libSDL.so) is a link broken with the lib pointing in the same dir.

(Original issue 48 created by ciand on 2014-12-04T21:07:19.480720+00:00)

Haikuporter is telling me it cannot resolve cmd:cmake on a gcc2h system, however running "haikuporter cmake" is building cmake. This seems to be an issue relating to secondary architectures as far as I can tell

(Original issue 24 created by kallisti5 on 2014-01-21T18:45:17.578936+00:00)

Checking for changes in patch files in addition to recipies would be nice. Not sure if it would create any conflicts but if you update a patch you have to do a clean manually. Maybe haikuporter could detect changes to patches (change of modification epoch?) and trigger a clean before a build?

(Original issue 36 created by kallisti5 on 2014-08-04T20:59:57.824162+00:00)

If you place x86 into TARGET_ARCHITECTURE and SECONDARY_TARGET_ARCHITECTURE, haikuporter refuses to work and locks up.

Valid and works:

TARGET_ARCHITECTURE="x86"
SECONDARY_TARGET_ARCHITECTURE="x86_gcc2"

Invalid, haikuporter locks up:

TARGET_ARCHITECTURE="x86"
SECONDARY_TARGET_ARCHITECTURE="x86"

Invalid, haikuporter errors out:
"'NoneType' object has no attribute named 'replace' error."

TARGET_ARCHITECTURE="x86"
SECONDARY_TARGET_ARCHITECTURE="x86 x86_gcc2"

haikuporter should present the user with a meaningful error.

(Original issue 20 created by anevilyak on 2013-11-29T23:32:13.925609+00:00)

If a port specifies its source as a remote git repository, it would be nice if we could depth limit the checkout, as some repos might have quite large/extensive history, and for the purposes of building a port that tends to be irrelevant. This would especially be the case for things like webkit where the full repo is around 7GiB with history.

(Original issue 35 created by dnivra on 2014-07-21T15:30:10.361531+00:00)

I get the following error when bootstrap building the ARM port. Using haikuporter at commit f540faa works fine.

======================================================================
sys-devel::libtool_cross_generic-2.4
======================================================================
requires "cmd:xres" of package "/home/arvind/gsoc/haiku/arm/generated.arm/objects/haiku/arm/packaging/repositories/HaikuPortsCross-build/sys-devel/libtool_cross_generic/work-2.4/repository/libtool_cross_generic_source-2.4.PackageInfo" could not be resolved
Error: unable to resolve prerequired ports for libtool_cross_generic-2.4
Error:  package-infos:
Error:          /home/arvind/gsoc/haiku/arm/generated.arm/objects/haiku/arm/packaging/repositories/HaikuPortsCross-build/sys-devel/libtool_cross_generic/work-2.4/repository/libtool_cross_generic-2.4.PackageInfo
Error:          /home/arvind/gsoc/haiku/arm/generated.arm/objects/haiku/arm/packaging/repositories/HaikuPortsCross-build/sys-devel/libtool_cross_generic/work-2.4/repository/libtool_cross_generic_source-2.4.PackageInfo
Error:  repositories:
Error:          /home/arvind/gsoc/haiku/arm/generated.arm/objects/haiku/arm/packaging/repositories/HaikuPortsCross-build/packages
Error:          /home/arvind/gsoc/haiku/arm/generated.arm/objects/haiku/arm/packaging/repositories/HaikuPortsCross-build/sys-devel/libtool_cross_generic/work-2.4/repository
Error: 

(Original issue 43 created by humdinger on 2014-11-30T07:26:39.873498+00:00)

If I understand the --location option correctly, it shouldn't print:

~/> haikuporter -o quicklaunch

/HiQ-Data/sources/haikuports/quicklaunch

/HiQ-Data/sources/haikuports/quicklaunch_x86

but

~/> haikuporter -o quicklaunch

/HiQ-Data/sources/haikuports/haiku-apps/quicklaunch

/HiQ-Data/sources/haikuports/haiku-apps/quicklaunch_x86

(Original issue 15 created by weinhold on 2013-11-08T13:08:20.449795+00:00)

haikuporter's command line interface has options for actions and options that just modify the behavior. It would be nice to reorganize the interface such that the actions become non-options and the first parameter. E.g. "haikuporter patch foo", "haikuporter package -j8 foo", etc. This would make the interface easier to understand.

(Original issue 1 created by kallisti5 on 2013-09-03T02:28:07.617690+00:00)

running a clean build (-c) with the PM haikuporter script results in the following error:

#!python

------ Package Info -------------
.blah.
.blah.
---------------------------------
Building ...
/bin/bash: line 576: /port.recipe: No such file or directory
Traceback (most recent call last):
  File "/boot/home/haikuporter/HaikuPorter/Port.py", line 742, in build
  File "/boot/home/haikuporter/HaikuPorter/Port.py", line 1055, in _executeBuild
  .
  .

Rebuilding the port without the "-c" resolves the issue

(Original issue 3 created by cpr on 2013-10-14T23:32:34.053231+00:00)

The hostname command fails to run while building a port(presumably because /boot/system/settings/network/hostname isn't available inside the chroot)

(Original issue 19 created by alvin_ on 2013-11-26T08:16:32.101562+00:00)

Attached is a recipe file which will fail to build.
In the recipe's INSTALL section:

    packageEntries otf \
    ${FONTDIR}/*.otf

packageEntries ttf \
    ${FONTDIR}/*.ttf

Building the recipe file like this will result in an error:

waiting for build package lato_fonts-1.105-1 to be activated waiting for build package lato_fonts_otf-1.105-1 to be activated waiting for build package lato_fonts_ttf-1.105-1 to be activated Building ... Collecting files to be packaged ... /port.recipe: line 56: /packages/lato_fonts-1.105-1/.self/data/fonts/lato_fonts/Lato-Bla.ttf: Operation not allowed Command '['/bin/bash', '-c', '. /wrapper-script']' returned non-zero exit status 1 keeping chroot folder /boot/home/haikuports/media-fonts/lato_fonts/work-1.105 intact for inspection *** Build has failed - stopping.

However, if I remove the backslashes:

packageEntries otf ${FONTDIR}/*.otf

packageEntries ttf ${FONTDIR}/*.ttf

The recipe will build fine.

(Original issue 11 created by scottmc on 2013-10-24T21:01:13.656527+00:00)

For many ports such as SDL games, they just get a default icon. It would be nice if we could put an HVIF icon into a directory called icons or whatever and then build that icon into the program as if it were a Haiku program. Perhaps via an AttachIcon() function in the recipe file?

(Original issue 40 created by scottmc on 2014-09-26T16:26:43.186174+00:00)

To prevent confusion for users trying to use haikuporter to build recipes on non-PM builds of Haiku, issue an error if it is attempted so they know that they are using a no-longer haikuporter supported version of haiku. This error should only pop up when running on an older haiku.

(Original issue 37 created by scottmc on 2014-08-19T21:06:34.132504+00:00)

For the COPYRIGHT entry, add a validation check and issue an error if "Copyright" or "(C)" are present, or the entry does not start with a year or year range.

(Original issue 41 created by charlie_x on 2014-11-04T19:49:35.085572+00:00)

This came up on IRC so I can't confirm it but apparently the recipe for digiclock causes code to be executed that shouldn't.

Looks to me like the Provides section is broken.

#!ini

PROVIDES="
    digiclock = $portVersion"
    app:digiclock = $portVersion"

Quotes look broken

I'd write a test if I could… ;-)

(Original issue 25 created by pulkomandy on 2014-06-16T11:01:46.333783+00:00)

It is not possible anymore to build a package with a custom license with haikuporter -S. It will complain that the source package does not contain the license file.

This seems to be because of the source package timing change in bac7ea3. Reverting to before that change works.

I hit this issue while building Flex on x86_64.

(Original issue 29 created by waddlesplash on 2014-06-30T13:28:30.392285+00:00)

...even if they have another extension (like "tar"). Perhaps the correct thing to do is to ignore all files without a "HPKG" extension and only fail on the ".hpkg" files that are not HPKGs?

(Original issue 44 created by scottmc on 2014-12-03T05:11:15.990460+00:00)

and add option --with-dependencies to make it build with them. Haiku is about sane defaults...

(Original issue 33 created by anevilyak on 2014-07-16T12:04:03.564160+00:00)

If one asks to enter the chroot for a target, and that target has dependencies that need to be built first, then haikuporter will enter the chroot for the first dep in question, rather than the actual target.

(Original issue 27 created by pulkomandy on 2014-06-18T07:24:08.900219+00:00)

prepareInstalledDevelLib will fail if the library has a .so file which has no soname. It could use the library file name, or it could at least print an useful error message.

(Original issue 38 created by waddlesplash on 2014-08-20T17:42:44.413059+00:00)

Ensure that the description is not just a reformatted version of the SUMMARY (e.g. trim the string and compare it) and that it's substantially longer than the SUMMARY.

Also ensure that the SUMMARY is only one sentence long.

(Original issue 47 created by ciand on 2014-12-04T21:05:42.288201+00:00)

I'm looking at an issue with libffi and wanted to build the previous version which still has a fully functional .recipe present - but the .dependencyinfo file hadn't been generated for it. On deleting the repository folder to force a full rebuild I noticed that it was skipped without giving a reason.

Other ports with multiple versions have the .dependencyinfo file generated for all recipes

(Original issue 45 created by kallisti5 on 2014-12-03T14:56:07.499590+00:00)

There are some major problems in dependency resolution in the latest version of HaikuPorter.

Here is an example:

#!shell

/Builds/haikuporter> git pull --rebase
Current branch master is up to date.
/Builds/haikuporter> ./haikuporter bash
Checking if any package-infos need to be updated ...
Looking for stale dependency-infos ...
======================================================================
app-shells::bash-4.3.30
======================================================================
The following required ports will be built first:
    sys-apps::findutils-4.4.2
    sys-devel::make-3.82
    sys-devel::m4-1.4.16
    sys-apps::diffutils-3.3
    sys-apps::texinfo-4.13a
    sys-apps::sed-4.2.1
    dev-lang::perl-5.18.2
    app-arch::tar-1.27.1
    sys-apps::help2man-1.46.3
    sys-apps::coreutils-8.22
    sys-apps::gawk-4.1.0
    sys-devel::flex-2.5.39
    sys-devel::bison-2.6.5
    sys-devel::autoconf-2.69
    sys-devel::libtool-2.4.2
    sys-devel::gcc-4.8.3_2014_07_26
    sys-devel::automake-1.13.1
    sys-devel::binutils-2.24_2014_03_19
----------------------------------------------------------------------
sys-apps::findutils-4.4.2
    /Builds/haikuports/sys-apps/findutils/findutils-4.4.2.recipe
----------------------------------------------------------------------
Skipping download of source for findutils-4.4.2.tar.gz
Skipping checksum validation of findutils-4.4.2.tar.gz
Skipping unpack of findutils-4.4.2.tar.gz
Cleaning up temporary directories ...
chroot has these packages active:
    /Builds/haikuports/packages/bash-4.3.30-1-x86_64.hpkg
    /Builds/haikuports/packages/expat-2.1.0-1-x86_64.hpkg
    /Builds/haikuports/packages/freetype-2.5.3-5-x86_64.hpkg
    /Builds/haikuports/packages/jasper-1.900.1-4-x86_64.hpkg
    /Builds/haikuports/packages/jpeg-9a-1-x86_64.hpkg
    /Builds/haikuports/packages/libicns-0.8.1-2-x86_64.hpkg
    /Builds/haikuports/packages/libpng-1.5.20-1-x86_64.hpkg
    /Builds/haikuports/packages/libpng16-1.6.15-1-x86_64.hpkg
    /Builds/haikuports/packages/libsolv-0.3.0_haiku_2013_10_01-3-x86_64.hpkg
    /Builds/haikuports/packages/ncurses-5.9-10-x86_64.hpkg
    /Builds/haikuports/packages/readline-6.3-2-x86_64.hpkg
    /boot/system/packages/binutils-2.24_2014_03_19-7-x86_64.hpkg
    /boot/system/packages/bzip2-1.0.6-5-x86_64.hpkg
    /boot/system/packages/ca_root_certificates-2014_04_08-2-any.hpkg
    /boot/system/packages/curl-7.39.0-1-x86_64.hpkg
    /boot/system/packages/gcc-4.8.3_2014_07_26-2-x86_64.hpkg
    /boot/system/packages/gcc_syslibs-4.8.3_2014_07_26-2-x86_64.hpkg
    /boot/system/packages/giflib-5.1.0-1-x86_64.hpkg
    /boot/system/packages/gutenprint-5.2.10-1-x86_64.hpkg
    /boot/system/packages/haiku-r1~alpha4_pm_hrev48368-1-x86_64.hpkg
    /boot/system/packages/haiku_devel-r1~alpha4_pm_hrev48368-1-x86_64.hpkg
    /boot/system/packages/icu-54.1-4-x86_64.hpkg
    /boot/system/packages/libwebp-0.4.1-1-x86_64.hpkg
    /boot/system/packages/make-3.82-5-x86_64.hpkg
    /boot/system/packages/openssl-1.0.0o-1-x86_64.hpkg
    /boot/system/packages/qrencode-3.3.0-2-x86_64.hpkg
    /boot/system/packages/tiff-3.9.6-2-x86_64.hpkg
    /boot/system/packages/zlib-1.2.8-4-x86_64.hpkg
----- Package Info ----------------
header size:                     80
heap size:                      863
TOC size:                        41
package attributes size:       1054
total size:                     943
-----------------------------------
----- Package Info ----------------
header size:                     80
heap size:                      884
TOC size:                        41
package attributes size:       1103
total size:                     964
-----------------------------------
waiting for build package findutils-4.4.2-1 to be activated
waiting for build package findutils_debuginfo-4.4.2-1 to be activated
Building ...
/wrapper-script: line 137: sed: command not found
./configure: line 559: sed: command not found
./configure: line 1313: sed: command not found
./configure: line 1088: sed: command not found
./configure: line 1304: sed: command not found
./configure: line 1701: sed: command not found
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
./configure: line 2268: sed: command not found
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... no
checking whether make sets $(MAKE)... ./configure: line 2376: sed: command not found
yes
configure: error: cannot run /bin/sh build-aux/config.sub
./configure: line 14: sed: command not found
./configure: line 36: sed: command not found
Command '['bash', '-c', '. /wrapper-script']' returned non-zero exit status 1
keeping chroot folder /Builds/haikuports/sys-apps/findutils/work-4.4.2 intact for inspection
Error: Build has failed - stopping.

In the log above, haikuporter states that it needs to build sed first. However, it builds findutils first.

sed is a implicitBuildHostProvides, any implicitBuildHostProvides should always be built and activated first.

(Original issue 13 created by scottmc on 2013-10-25T23:05:56.158644+00:00)

This turned up when trying to make a working .recipe for sge. The source package name is sge030809..tar.gz, but haikuporter errors out for not finding "version" string.
I'll try renaming the source package and see if that changes anything.

(Original issue 10 created by arfonzo on 2013-10-23T12:10:07.047368+00:00)

I think that haikuporter should lock and error, if a package is already being built at the same time.

For example:

• Build cherokee_x86, and build ninja_x86 at the same time.
• Both will try to build binutils_x86, and both will fail.
• If you build binutils_x86 by itself, it succeeds.

(Original issue 49 created by waddlesplash on 2014-12-12T15:01:50.534061+00:00)

This isn't a problem on most recipes, but it's currently causing the "cdrtools" build to fail.

(Original issue 23 created by waddlesplash on 2014-01-01T22:40:47.763984+00:00)

This'll make it really easy to install it :)

(Original issue 8 created by kallisti5 on 2013-10-22T00:25:25.408998+00:00)

If you attempt to build a secondary architecture package (aka ./haikuporter libxslt_x86_gcc2) and the SECONDARY_TARGET_ARCHITECTURE option isn't set in the haikuports.conf, haikuporter builds the primary target of that recipe.

We should likely error out somehow saying "provided secondary target architecture isn't valid" (or maybe we should automatically pick up on the valid secondary target architectures?)

(Original issue 39 created by ithamar on 2014-09-01T10:52:33.099284+00:00)

Since our main build system supports OS X, it would be nice for haikuporter to work as well. The main issue here is that OS X ships with bash 3, not bash 4, and we use exactly one feature from bash 4 (case conversion of variables).

My main question here is, are we accepting patches to haikuporter / haikuports{,.cross} for this?

If so, I can share my patches, they are all relatively minimal (and make the ARM bootstrap build work on OS X).

(Original issue 14 created by scottmc on 2013-11-06T20:08:45.233912+00:00)

Currently if you are missing the REVISION you just get a "recipe is broken" error. Add a check for REVISION and if missing give error message saying so.

(Original issue 50 created by waddlesplash on 2014-12-18T02:13:14.039359+00:00)

Apparently, HaikuPorter converts PROVIDES to lowercase automatically (on package creation) but does not convert REQUIRES to lowercase, resulting in recipes that can't be built.

This is causing a lot of confusion lately.

(Original issue 9 created by scottmc on 2013-10-22T15:27:28.981795+00:00)

As an example try building sdl_mixer, it should pull in a lot of dependencies. But I've had to attempt to build it, see where it failed and then go and build what it failed to find, before retrying to build sdl_mixer.

(Original issue 26 created by pulkomandy on 2014-06-16T20:38:17.689926+00:00)

gtk_doc depends on version 4.3 of docbook-xml-dtd. Haikuporter will not allow that unless version 4.5 is removed from the ports tree. This should work. Does the recipes need to be changed, or is that a problem in haikuporter?

(Original issue 16 created by kallisti5 on 2013-11-14T23:58:38.266656+00:00)

llvm-3.3 has "!x86 !x86_64" set for the architectures to flag them as broken. llvm-3.2 doesn't have these broken flags and works fine.

Mesa-10.0.0 requires "llvm >= 3.2", haikuporter attempts to build llvm-3.3 (and fails, thus causing the mesa build to fail)

haikuporter should see the "!" flag for the target architecture and see if a previous package recipe could fill the port dependencies.

(Original issue 28 created by diversys on 2014-06-29T16:33:17.308395+00:00)

/bin/clear which is part of haiku.hpkg calls /bin/tput which is part of ncurses package.

(Original issue 30 created by KapiX on 2014-07-04T09:15:36.637972+00:00)

I'm writing a recipe for nspr but I have to use cd for now.

Please remove it from recipe when fixed.

(Original issue 34 created by mmu_man on 2014-07-19T20:50:01.517184+00:00)

Patches to files that contain DOS CR-LF fail to apply during the patch phase, because git am sends them through git-mailsplit which strips CR.
One has to use git am --keep-cr instead.
We should have a flag in the recipe to allow this.

One such patch is app-emulation/simh/patches/simh-4.0.0_git.patchset

(Original issue 31 created by waddlesplash on 2014-07-10T19:26:11.534757+00:00)

It hangs on the DNS lookup.

(Original issue 17 created by kallisti5 on 2013-11-21T05:16:36.671525+00:00)

I reinstalled my x86 system to x86_gcc2, then attempted to build some ports. Something gets left in the work-* directory which causes the port builds to fail (this example was for bzip2). The failure was a missing libroot.so.

I removed all the files in work-1.0.6 and work-x86_gcc2-1.0.6 and that seemed to fix it.

(Original issue 7 created by cpr on 2013-10-20T06:24:29.654702+00:00)

Any recipes that need to do some sort of host lookup do not function inside of the chroot. This includes recipes that "git clone" some other repository as part of their build process.

Related to issue #3 since I believe it's failing to find files in /boot/system/settings/network

(Original issue 32 created by waddlesplash on 2014-07-14T18:48:39.652721+00:00)

e.g. I created a recipe called "libdbusmenu_qt" but later decided it was not needed and deleted it. Now whenever I start HaikuPorter, the following occurs:

Checking if any package-infos need to be updated ...
Looking for stale package-infos ...
u'libdbusmenu_qt_x86'

Making this a blocker since I can't do anything right now...

(Original issue 6 created by kallisti5 on 2013-10-18T04:59:01.854078+00:00)

mimesetting files for package libsdl2_source-2.0.0-1-source.hpkg ...
creating package libsdl2_source-2.0.0-1-source.hpkg ...
----- Package Info ----------------
header size:                     80
heap size:                  3745353
TOC size:                     61161
package attributes size:        556
total size:                 3745433
-----------------------------------
waiting for build package libsdl2-2.0.0-1 to be deactivated
waiting for build package libsdl2_devel-2.0.0-1 to be deactivated
waiting for build package libsdl2_source-2.0.0-1 to be deactivated
unmount: unmounting failed: Device/File/Resource busy
unmounting /Data/haikuports/media-libs/libsdl2/work-2.0.0/boot/system failed - wait 1 second and retry ...
unmount: unmounting failed: Device/File/Resource busy
unmounting /Data/haikuports/media-libs/libsdl2/work-2.0.0/boot/system failed - wait 1 second and retry ...
unmount: unmounting failed: Device/File/Resource busy
unmounting /Data/haikuports/media-libs/libsdl2/work-2.0.0/boot/system failed - wait 1 second and retry ...
unmount: unmounting failed: Device/File/Resource busy
unmounting /Data/haikuports/media-libs/libsdl2/work-2.0.0/boot/system failed - wait 1 second and retry ...
unmount: unmounting failed: Device/File/Resource busy
unmounting /Data/haikuports/media-libs/libsdl2/work-2.0.0/boot/system failed - wait 1 second and retry ...
cleaning chroot folder
rm: cannot remove `boot/system/package-links/zlib-1.2.8-4/.self': Read-only file system
rm: cannot remove `boot/system/package-links/zlib-1.2.8-4/.settings': Read-only file system
rm: cannot remove `boot/system/package-links/zlib-1.2.8-4/haiku': Read-only file system
rm: cannot remove `boot/system/package-links/glu-9.0.0-2/.self': Read-only file system
rm: cannot remove `boot/system/package-links/glu-9.0.0-2/.settings': Read-only file system
rm: cannot remove `boot/system/package-links/glu-9.0.0-2/haiku': Read-only file system
rm: cannot remove `boot/system/package-links/curl-7.26.0-5/.self': Read-only file system
rm: cannot remove `boot/system/package-links/curl-7.26.0-5/.settings': Read-only file system
rm: cannot remove `boot/system/package-links/curl-7.26.0-5/haiku': Read-only file system
rm: cannot remove `boot/system/package-links/curl-7.26.0-5/ca_root_certificates': Read-only file system
.
.
.

rm: cannot remove `boot/system/bin/lesskey': Read-only file system
rm: cannot remove `boot/system/bin/lessecho': Read-only file system
rm: cannot remove `boot/system/bin/less': Read-only file system
rm: cannot remove `boot/system/bin/kill': Read-only file system
rm: cannot remove `boot/system/bin/keystore': Read-only file system
rm: cannot remove `boot/system/bin/keymap': Read-only file system
rm: cannot remove `boot/system/bin/kernel_debugger': Read-only file system
rm: cannot remove `boot/system/bin/join': Read-only file system
rm: cannot remove `boot/system/bin/isvolume': Read-only file system
rm: cannot remove `boot/system/bin/iroster': Read-only file system
rm: cannot remove `boot/system/bin/installsound': Read-only file system
rm: cannot remove `boot/system/bin/install': Read-only file system
rm: cannot remove `boot/system/bin/ifconfig': Read-only file system
rm: cannot remove `boot/system/bin/ident': Read-only file system
rm: cannot remove `boot/system/bin/id': Read-only file system
rm: cannot remove `boot/system/bin/hostname': Read-only file system
rm: cannot remove `boot/system/bin/hey': Read-only file system
.
.
.

(Original issue 18 created by anna_gajdov on 2013-11-23T22:41:08.341423+00:00)

Haikuporter tries to unpack a file even if it is unarchived. Building fails because of "unreconized archive type".

(Original issue 12 created by scottmc on 2013-10-24T21:11:58.753867+00:00)

Sometimes an issue isn't reported until you copy the .hpkg file to /boot/system/packages and a dialog box pops open reporting an error that should have been reporting during the build stage but wasn't. Seems that some of the checks being done by the system level check can be brought over to Haikuporter's checking.

(Original issue 22 created by None on 2013-12-11T01:50:06.538684+00:00)

Lets say I want to build llvm_x86-3.2.

I run haikuporter llvm_x86-3.2. Technically there is also a 3.3 version, so llvm-3.2 gets flagged for the .obsolete directory. However, llvm_x86-3.2 requires ncurses_x86 (the latest version as there is only one). When haikuporter builds ncurses, it also gets placed into the .obsolete packages directory. (even though it is the latest version)

It seems like once that occurs, nothing can meet the ncurses dependencies, however that could be another issue.

(Original issue 21 created by kallisti5 on 2013-12-02T04:56:38.828900+00:00)

Example:

# swpipe renderer package
packageEntries swpipe \
    "$addOnsDir/opengl/Software Pipe"

Result:

scons: done building targets.
Collecting files to be packaged ...
mv: cannot stat `/packages/mesa-10.0.0-1/.self/add-ons/opengl/Software': No such file or directory
Command '['/bin/bash', '-c', '. /wrapper-script']' returned non-zero exit status 1
keeping chroot folder /boot/home/haikuports/sys-libs/mesa/work-10.0.0 intact for inspection
*** Build has failed - stopping.

Adding an escape doesn't solve the issue either:

# swpipe renderer package
packageEntries swpipe \
    "$addOnsDir/opengl/Software\ Pipe"

Result:

scons: done building targets.
Collecting files to be packaged ...
mv: cannot stat `/packages/mesa-10.0.0-1/.self/add-ons/opengl/Software\\': No such file or directory
Command '['/bin/bash', '-c', '. /wrapper-script']' returned non-zero exit status 1
keeping chroot folder /boot/home/haikuports/sys-libs/mesa/work-10.0.0 intact for inspection
*** Build has failed - stopping.