https://forge.codesys.com/tol/wharfie/tickets/You searched for status:closedenTue, 04 Aug 2020 14:25:50 -0000https://forge.codesys.com/tol/wharfie/tickets/16/IngoTue, 04 Aug 2020 14:25:50 -0000https://forge.codesys.com/tol/wharfie/tickets/16/https://forge.codesys.com/tol/wharfie/tickets/15/gcc for cross compilation is included in toolchain, but g++ is missing. erichspitzwegSun, 07 Apr 2019 18:56:32 -0000https://forge.codesys.com/tol/wharfie/tickets/15/https://forge.codesys.com/tol/wharfie/tickets/14/Error from apt-get E: There were unauthenticated packages and -y was used without --allow-unauthenticated missing "--allow-unauthenticated" in case of "-y" at all "apt-get install --allow-unauthenticated -y ..." erichspitzwegMon, 08 Apr 2019 12:55:15 -0000https://forge.codesys.com/tol/wharfie/tickets/14/https://forge.codesys.com/tol/wharfie/tickets/13/CXX=$${COMPILE_PREFIX}cpp in wharfie.mk should be CXX=$${COMPILE_PREFIX}g++erichspitzwegWed, 03 Apr 2019 06:40:15 -0000https://forge.codesys.com/tol/wharfie/tickets/13/https://forge.codesys.com/tol/wharfie/tickets/11/*Originally created by:* labi Currently we are facing the problem with stretch, that debootstrap doesn't want to build. Most likely its because of this error: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838388AnonymousFri, 05 Apr 2019 11:39:39 -0000https://forge.codesys.com/tol/wharfie/tickets/11/https://forge.codesys.com/tol/wharfie/tickets/10/*Originally created by:* labi *Originally owned by:* labi There are actually two errors: 1) debian_version.mk is not included in the same run as it is created Therefore an initial build fails with "can't cd to http://ftp.debian.org", while a second run (w/o clean) progresses further. 2) Then it fails with "Makefile:34: recipe for target '32323D8C.piling.tar' failed" This is most likely a problem which occurs after hardening the makerules, so that they throw an error on all commands that fail. And it is a problem which is not in the toolchain rule in wharfie.mk, but in the generated rule which combines the sysroots of the host and the target.AnonymousThu, 01 Feb 2018 23:39:07 -0000https://forge.codesys.com/tol/wharfie/tickets/10/https://forge.codesys.com/tol/wharfie/tickets/9/*Originally created by:* labi *Originally owned by:* labi CODESYS was compiled for raspbian. Sadly raspbian is incompatible with a standard debian, as it uses a different ABI. It uses the hardfloat ABI, but compatible with ARMv6. If you have a RPI Zero / 1 / ..., which is based on ARMv6, you can only use the armel ABI from debian. As those are incompatible, it causes problems with floating point calculations. The solution is to use the glibc and gcc libraries from Raspbian, but solely with codesys. This can be achieved by changing the interpreter path and the rpath to a place, where our raspbian libraries are found. We will place them under /opt/codesys/lib/AnonymousFri, 05 Jan 2018 13:46:06 -0000https://forge.codesys.com/tol/wharfie/tickets/9/https://forge.codesys.com/tol/wharfie/tickets/8/*Originally created by:* labi *Originally owned by:* labi as we are using tar, we can use the multi level backup and restore concept. It supports already differential file backups, including deletion of files. What we need is "*.snar" file, recording the changes. As the snar file will become corrupted when we rebuild older files, we need to track the state of the snar file for each layer. In practice that means, that every build target has from now on, an additional snar file as its output, as well as an additional snar file as input. The FROM target doesn't produce a snar file. So it is automatically the level-0 backup. In fact I believe that packing should not make big trouble, as we can always just check if a a snar is there. if yes, use it. If no, leave it and create a level-0 backup. The extract of the archives on the other hand is a bit more tricky. We now need the info about all archives, which are involved, starting from the level-0 backup. The safest way will be to track this transparently in the makefile generation process, as we are also managing the archives there.AnonymousTue, 21 Nov 2017 22:08:10 -0000https://forge.codesys.com/tol/wharfie/tickets/8/https://forge.codesys.com/tol/wharfie/tickets/7/*Originally created by:* labi AnonymousFri, 31 Aug 2018 23:42:00 -0000https://forge.codesys.com/tol/wharfie/tickets/7/https://forge.codesys.com/tol/wharfie/tickets/6/*Originally created by:* labi *Originally owned by:* labi Support at least http:// and ftp:// as protocols. Think about SVN / GITAnonymousSun, 19 Nov 2017 01:19:59 -0000https://forge.codesys.com/tol/wharfie/tickets/6/https://forge.codesys.com/tol/wharfie/tickets/5/*Originally created by:* labi *Originally owned by:* labi The simple regex based parser of wharfie doesn't throw an error when it doesn't recognize a command, but simply ignores it.AnonymousTue, 14 Nov 2017 21:04:35 -0000https://forge.codesys.com/tol/wharfie/tickets/5/https://forge.codesys.com/tol/wharfie/tickets/4/*Originally created by:* labi *Originally owned by:* labi Currently on errors of the host or target commands, the build doesn't fail.AnonymousTue, 14 Nov 2017 22:31:28 -0000https://forge.codesys.com/tol/wharfie/tickets/4/https://forge.codesys.com/tol/wharfie/tickets/3/*Originally created by:* labi *Originally owned by:* labi Currently the SSH key is created during installation. So it is the same for all targets where the created root filesystem will be rolled out.AnonymousFri, 05 Apr 2019 11:40:41 -0000https://forge.codesys.com/tol/wharfie/tickets/3/https://forge.codesys.com/tol/wharfie/tickets/1/*Originally created by:* labi *Originally owned by:* labi Allow building as non-root user. Currently we need root, as we are using chroot. After switching to fakechroot, we have the problem of non-native target systems. Then we are using qemu through binfmt, which simply doesn't work in combination with chroot. The way how fakechroot works is preloading a wrapper library through LD_PRELOAD. So the following scenerio sounds valid: ~~~ fakechroot chroot rootfs/ /bin/bash ~~~ /bin/bash is a target binary, executed through binfmt. chroot itself is still a host binary. fakechroot will fixly preload it's wrapper. We would need a few things: * When building a base system with debootstrap, we always need to corresponding libfakechroot.so fo the target. * In my opinion this library can be stored globally in a similar manner as debian_version.mk * When issuing the chroot, we need to switch LD_PRELOAD to the new folder Note: We need to check if the permissions on the files will remain the same after we switched from the host to the target library. Because the command is in fact a bit more complex: ~~~ fakechroot bash -c "cd ...; tar -xf ...; chroot . ./.trg.sh; ..." ~~~ So we have the files created with the host version of libchfakeroot.so and then we execute the target binaries with the target version. Not sure if we can guarantee, that they are seeing the same file permissions, as I don't know where this information is stored.AnonymousFri, 09 Mar 2018 15:40:55 -0000https://forge.codesys.com/tol/wharfie/tickets/1/