Re: [bug#67261] [PATCH 3/3] images: Add orangepi-r1-plus-lts image.
On 2023-12-03, Efraim Flashner wrote: > On Fri, Dec 01, 2023 at 11:58:57AM -0800, Vagrant Cascadian wrote: >> On 2023-11-18, Herman Rimm wrote: >> > * gnu/local.mk: Register image. >> > * gnu/system/images/orangepi-r1-plus-lts-rk3328.scm: New file. >> > * gnu/system/install.scm (orangepi-r1-plus-lts-rk3328-installation-os): >> > New variable. >> >> I guess this opens in my mind a larger question of how many images do we >> want to build out-of-the-box? >> >> Building images for every (ARM) board variant possibly supported in guix >> might not be sustainable in the long term... this could easily become >> hundreds of images. How big is each image? >> >> On the other hand, most of the images for a given architecture will >> share much of the work between them, as most of the individual packages >> used to build each image are the same. >> >> Not having CI build each and every image is one approach... although >> then you might not notice when an individual image breaks. > > Do we normally build all the images in (gnu system images)? There seems > to be a large number of different file-system offsets needed for > different boards. I suppose we could standardize on a larger size that > would take care of most of them, but until something is setup to make it > possible I'm not sure it's possible to support them for Guix System > without also adding an OS config for the offsets for the root file > system. From a quick look, ci.guix.gnu.org builds pinebook-pro-barebones-raw-image, pine64-barebones-raw-image, novena-barebones-raw-image ... but I could not find an image for rock64 ... so I am not sure what is built by CI out of the box. live well, vagrant signature.asc Description: PGP signature
Re: Mixing GPL and non-copyleft code in source files
Hi Wojtek, On Fri, Dec 22 2023, Wojtek Kosior wrote: > I'm not sure how an "appropriate note" would look like. Where do you > imagine it? I would offer a chronological list of my downloadable contributions to Guix and place the following wording on top of the page: "I disagree with the licensing model embraced by GNU Guix and hereby release my contributions there under the CC-0 license. For convenience, you can also use the patches below." The hurdle is that as a Guix maintainer, I would not accept your dual-licensing statements into my project. > I believe we have ... different attitude to making use of legal force You are probably right. I'm a complete pushover, especially in the wintertime. Kind regards Felix
Re: [bug#62153] Merging guix pack changes for Docker containers packaging
Hi Oleg, Apologies for not replying earlier. I occasionally get reminded of the fact that building single-layer images is a problem, but only now did I take the time to look more closely at the latest version of these patches. Oleg Pykhalov skribis: > I would like to merge 62153. After 64173 will be merge, merging 62153 > is not possible without conflict resolving with Git. > > 64173 introduces ‘%docker-format-options’ variable. With this variable > it's possible in 62153 to replace ‘--image-type=docker-layered’ with > ‘--docker-layers=N’ option, where: > > if ‘N’ is zero, then use current non layered format > if ‘N’ is bigger than zero, then use layered format OK we should do that. However, the original submitter of #64173 apparently dropped the ball as we were approaching the final version. Would you like to adopt it and submit/push a version that incorporates the latest comments? Alternatively, we could do the opposite: merge the Docker layer patches first, and then rebase the ‘%docker-format-options’ patch, after which we could add the ‘--docker-layers’ option. What’s your preference? > Number of layers specification is nice to have, because Docker layers > are limited. So if user would like to modify a Docker image by adding > more layers on top, then hacks like squashing layers are not required. > Also, it will be possible to delete code which builds non layered Docker > image without deprecating command line options. Agreed. Anyway, apart from the stylistic issues I reported, v4 of this patch set looks great to me. (For clarity I’d have preferred three patches, one for (guix docker), one for ‘guix pack’, and one for ‘guix system’; but it’s really a detail, let’s not block this patch series any longer.) Thanks, Ludo’.
Re: Mixing GPL and non-copyleft code in source files
Thanks for the response > Could you publish your diffs elsewhere with an appropriate note that > they are also available under CC-0 from there? Well, that's more or less what I am already doing with a public git repo for my fork — except I'm not sure how an "appropriate note" would look like. Where do you imagine it? In a commit message? Elsewhere? > > I'd like the lines of code I authored to be dual-licensed under > > GPL-3.0-or-later and CC0-1.0. This is purely for personal reasons (as > > having a mere few dozens of lines in a project under CC0 causes no > > practical change to the project). > > As someone who grew up under Microshaft's dominance of the PC market, > I'm not sure I agree with that characterization. Someone who choses the > GPL for a project is probably opposed to CC-0 for that project. I see. I believe we have similar experiences and similar moral rating of Microsoft's actions — and just different attitude to making use of legal force :) "no practical change" was meant to mean that it would still be impossible to integrate said project into a proprietary product. One would need to obtain a non-copyleft license from other ~1071 contributors. Or slightly fewer but still… Best Wojtek -- (sig_start) website: https://koszko.org/koszko.html fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A follow me on Fediverse: https://friendica.me/profile/koszko/profile ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end) On Fri, 22 Dec 2023 10:00:32 -0800 Felix Lechner wrote: > > I'd like the lines of code I authored to be dual-licensed under > > GPL-3.0-or-later and CC0-1.0. This is purely for personal reasons (as > > having a mere few dozens of lines in a project under CC0 causes no > > practical change to the project). > > As someone who grew up under Microshaft's dominance of the PC market, > I'm not sure I agree with that characterization. Someone who choses the > GPL for a project is probably opposed to CC-0 for that project. > > Could you publish your diffs elsewhere with an appropriate note that > they are also available under CC-0 from there? pgpwDySGz8WK_.pgp Description: OpenPGP digital signature
Re: A basic Shepherd bug?
> I added the service below to my operating-system, and 'herd status' > prints nothing but hangs. Is that a bug? > > Same on reboot. Thanks! this has probably been fixed in: https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=9be0b7e6fbe3c2e743b5626f4dff7c7bf9becc16 but it hasn't reached guix yet. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- An economist is a person who spends half his life telling us what will happen and the other half explaining why it didn't.
status of (future of) Guix QA
Curious of the status of the future of Guix QA as package definition contributors rely on it for updating packages (sending patches to get accepted/committed) in guix...
Re: Mixing GPL and non-copyleft code in source files
Hi Wojtek, On Fri, Dec 22 2023, Wojtek Kosior via "Development of GNU Guix and the GNU System distribution." wrote: > I'd like the lines of code I authored to be dual-licensed under > GPL-3.0-or-later and CC0-1.0. This is purely for personal reasons (as > having a mere few dozens of lines in a project under CC0 causes no > practical change to the project). As someone who grew up under Microshaft's dominance of the PC market, I'm not sure I agree with that characterization. Someone who choses the GPL for a project is probably opposed to CC-0 for that project. Could you publish your diffs elsewhere with an appropriate note that they are also available under CC-0 from there? Kind regards Felix
Re: Some files in Guix lack in-file license notice, does that make them GPL-3.0-only?
Am Freitag, dem 22.12.2023 um 17:20 +0100 schrieb Wojtek Kosior via Development of GNU Guix and the GNU System distribution.: > Hi > > at least the following files from Guix source tree > > dir-locals.el > configure.ac > config-daemon.ac > bootstrap > README > > have neither copyright nor license information in them. I believe it > prevents people from assuming that GPL v3 **or later** applies to > those files. I don't think it prevents people from assuming anything, but it may lead people to assume that these files are not GPL'd, which may or may not be the truth. (There is a debate to be had to which extent you can copyright, e.g. a dir-locals file in the first place.) > What should be done to fix this? Would it be welcome if I or someone > else reached out to the authors of those files to get a permission to > also use them under hypothetical later GPL versions? As you point out, the proper fix would be to explicitly license them. This doesn't have to be the GPL, however. For example, the FSF recommends more permissive licenses for small amounts of text, e.g. as typically found in READMEs. Cheers
Mixing GPL and non-copyleft code in source files
Hi I have some changes in my personal Guix fork that I'd like to contribute. I'd like the lines of code I authored to be dual-licensed under GPL-3.0-or-later and CC0-1.0. This is purely for personal reasons (as having a mere few dozens of lines in a project under CC0 causes no practical change to the project). How can I indicate such licensing? In one patch I sent 5 months ago (a still unreviewed one, unfortunately) I added a line like ;;; Copyright © 2023 Wojtek Kosior while keeping the rest of the license notice intact. Yup, this happens to be an existing email address that also conveys a message. However, I am worried this might be too ambigious. Are there better ways? How about introducing an SPDX license identifier + explaining the licensing situation in the commit message? Btw, is there anything that from technical side should be corrected in the linked patch? I mean, besides my failure to use `list` with gexps for the `arguments` field (I already realized that shortcoming myself) Wojtek [1] https://issues.guix.gnu.org/64869 -- (sig_start) website: https://koszko.org/koszko.html fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A follow me on Fediverse: https://friendica.me/profile/koszko/profile ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end) pgpBqdzEidad1.pgp Description: OpenPGP digital signature
Some files in Guix lack in-file license notice, does that make them GPL-3.0-only?
Hi at least the following files from Guix source tree dir-locals.el configure.ac config-daemon.ac bootstrap README have neither copyright nor license information in them. I believe it prevents people from assuming that GPL v3 **or later** applies to those files. You know, the COPYING file in the source tree has just the text of GPLv3. The permission to use a later GPL version only ever appears in the source files themselves. But in case of the files listed above, such extra permission is absent. As a result, all a receiver of the source code can assume is that the terms from the COPYING file apply here. What should be done to fix this? Would it be welcome if I or someone else reached out to the authors of those files to get a permission to also use them under hypothetical later GPL versions? Libre software projects are in general prone to this kind of licensing ambiguities and FSFE's REUSE[1] specification seems like a good fix for that. Would a patch that makes Guix repo REUSE-compliant be welcome? Wojtek [1] https://reuse.software/ -- (sig_start) website: https://koszko.org/koszko.html fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A follow me on Fediverse: https://friendica.me/profile/koszko/profile ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end) pgp0TPjOTYxHY.pgp Description: OpenPGP digital signature
A basic Shepherd bug?
Hi, I added the service below to my operating-system, and 'herd status' prints nothing but hangs. Is that a bug? Same on reboot. Thanks! Kind regards Felix * * * (service fcgiwrap-service-type (fcgiwrap-configuration (socket "tcp:localhost:3012")))
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
TL;DR it's probably due to some cmake mess. and i gave up on compiling this; if i really want to, i'll do it in a debian chroot. > > i tried with your gcc … but it errors out with: > > > > $ make > > [ 1%] Linking ASM executable bs2_default.elf > > arm-none-eabi-gcc: error: nosys.specs: No such file or directory > > > That file is located here: > /gnu/store/…-newlib-arm-none-eabi-4.3.0/arm-none-eabi/lib/nosys.specs that didn't help: ~/workspace/guix/guix/pre-inst-env guix shell gcc-toolchain cmake make pkg-config -e '(@ (gnu packages embedded2) gcc12-cross-newlib-arm-none-eabi-toolchain)' cd ~/workspace/bios/pico-serprog cmake . COMPILER_PATH=/gnu/store/i9kpjzbagdlpm8bs10gxmm21b271s056-newlib-3.0.0-0.3ccfb40/arm-none-eabi/lib/ LDFLAGS=-B/gnu/store/i9kpjzbagdlpm8bs10gxmm21b271s056-newlib-3.0.0-0.3ccfb40/arm-none-eabi/lib/ make it leads to the same problem. but then i tried to compile the pico-sdk subproject as a standalone project, and then it succeeds (but fails with a different error later). therefore i think it's due to some cmake mess that i don't want to get deeper into. so, the rest is just FYI: git clone https://github.com/raspberrypi/pico-sdk ~/workspace/guix/guix/pre-inst-env guix shell gcc-toolchain cmake make pkg-config -e '(@ (gnu packages embedded2) gcc12-cross-newlib-arm-none-eabi-toolchain)' cmake . make $ make [ 0%] Building ASM object src/rp2_common/boot_stage2/CMakeFiles/bs2_default.dir/compile_time_choice.S.obj [ 0%] Linking ASM executable bs2_default.elf [ 0%] Built target bs2_default [ 0%] Creating directories for 'ELF2UF2Build' [ 0%] No download step for 'ELF2UF2Build' [ 0%] No update step for 'ELF2UF2Build' [ 0%] No patch step for 'ELF2UF2Build' [ 0%] Performing configure step for 'ELF2UF2Build' -- The C compiler identification is unknown -- The CXX compiler identification is unknown -- Detecting C compiler ABI info -- Detecting C compiler ABI info - failed -- Check for working C compiler: /gnu/store/3yqw7js9slid5q3d1f5bpbk92vann109-profile/bin/gcc -- Check for working C compiler: /gnu/store/3yqw7js9slid5q3d1f5bpbk92vann109-profile/bin/gcc - broken CMake Error at /gnu/store/4bn07jsqk6lxp0qdxv7kkc3krz3afnna-cmake-3.25.1/share/cmake-3.25/Modules/CMakeTestCCompiler.cmake:70 (message): The C compiler "/gnu/store/3yqw7js9slid5q3d1f5bpbk92vann109-profile/bin/gcc" is not able to compile a simple test program. It fails with the following output: Change Dir: /home/alendvai/workspace/bios/pico-sdk/elf2uf2/CMakeFiles/CMakeScratch/TryCompile-fg3QLY Run Build Command(s):/gnu/store/3yqw7js9slid5q3d1f5bpbk92vann109-profile/bin/make -f Makefile cmTC_12bac/fast && make[3]: Entering directory '/home/alendvai/workspace/bios/pico-sdk/elf2uf2/CMakeFiles/CMakeScratch/TryCompile-fg3QLY' /gnu/store/3yqw7js9slid5q3d1f5bpbk92vann109-profile/bin/make -f CMakeFiles/cmTC_12bac.dir/build.make CMakeFiles/cmTC_12bac.dir/build make[4]: Entering directory '/home/alendvai/workspace/bios/pico-sdk/elf2uf2/CMakeFiles/CMakeScratch/TryCompile-fg3QLY' Building C object CMakeFiles/cmTC_12bac.dir/testCCompiler.c.o /gnu/store/3yqw7js9slid5q3d1f5bpbk92vann109-profile/bin/gcc-o CMakeFiles/cmTC_12bac.dir/testCCompiler.c.o -c /home/alendvai/workspace/bios/pico-sdk/elf2uf2/CMakeFiles/CMakeScratch/TryCompile-fg3QLY/testCCompiler.c as: unrecognized option '--64' make[4]: *** [CMakeFiles/cmTC_12bac.dir/build.make:78: CMakeFiles/cmTC_12bac.dir/testCCompiler.c.o] Error 1 make[4]: Leaving directory '/home/alendvai/workspace/bios/pico-sdk/elf2uf2/CMakeFiles/CMakeScratch/TryCompile-fg3QLY' make[3]: *** [Makefile:127: cmTC_12bac/fast] Error 2 make[3]: Leaving directory '/home/alendvai/workspace/bios/pico-sdk/elf2uf2/CMakeFiles/CMakeScratch/TryCompile-fg3QLY' the root cause of the messy error message above is the following: as: unrecognized option '--64' this happens with the host gcc (or due to some misconfiguration the host gcc is used wrongly). $ file src/rp2_common/boot_stage2/bs2_default.elf src/rp2_common/boot_stage2/bs2_default.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” — Antoine de Saint-Exupery (1900–1944)
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
Hi Jean-Pierre! The arm-none-eabi target is not finished yet since I'm running into some issues when building Axoloti which depends on the (gnu packages embedded) toolchains and I'm trying to migrate it to use `cross-gcc-toolchain` but it is proving a bit difficult due to search paths but I'm trying to solve it anyway. These include path problems where exactly the problems which I solved with that gcc12 and gcc12-cross packages. Let's say that they are a proof-of-concept for a better way to build GCC, not relying on environment variables for standard include paths. My gut feeling is that the whole GCC version chain starting in (gnu packages commencement) should be build this way, and in the end also the cross-gcc-toolchain would not have these issues. However, I think that would be an enormous effort – a bit like rewriting the bootstrapping of Guix – and I have no clue how to start myself with it. Bye Stefan
Re: A different way to build GCC to overcome issues, especially with C++ for embedded systems
Hi Attila! i tried with your gcc … but it errors out with: $ make [ 1%] Linking ASM executable bs2_default.elf arm-none-eabi-gcc: error: nosys.specs: No such file or directory That file is located here: /gnu/store/…-newlib-arm-none-eabi-4.3.0/arm-none-eabi/lib/nosys.specs Hm, it might be necessary to add that path per default to COMPILER_PATH as well with a -B option. This path currently only appears under LIBRARY_PATH, which seems to not be searched for spec files. $ arm-none-eabi-g++ -v -E -xc++ - < /dev/null Using built-in specs. COLLECT_GCC=/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-toolchain-12.2.0/bin/arm-none-eabi-g++ Target: arm-none-eabi Configured with: Thread model: single Supported LTO compression algorithms: zlib gcc version 12.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-E' '-mcpu=arm7tdmi' '-mfloat-abi=soft' '-marm' '-mlibarch=armv4t' '-march=armv4t' /gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0/libexec/gcc/arm-none-eabi/12.2.0/cc1plus -E -quiet -v -D__USES_INITFINI__ - -mcpu=arm7tdmi -mfloat-abi=soft -marm -mlibarch=armv4t -march=armv4t -dumpbase - ignoring nonexistent directory "/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0-lib/lib/gcc/arm-none-eabi/12.2.0/../../../../../../../arm-none-eabi/include" #include "..." search starts here: #include <...> search starts here: /gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0/include-c++ /gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0/include-c++/arm-none-eabi /gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0/include-c++/backward /gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0-lib/lib/gcc/arm-none-eabi/12.2.0/include /gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0-lib/include /gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0-lib/lib/gcc/arm-none-eabi/12.2.0/include-fixed /gnu/store/…-newlib-arm-none-eabi-4.3.0/arm-none-eabi/include End of search list. # 0 "" # 0 "" # 0 "" # 1 "" COMPILER_PATH=/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0/libexec/gcc/arm-none-eabi/12.2.0/:/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0/libexec/gcc/arm-none-eabi/12.2.0/:/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0/libexec/gcc/arm-none-eabi/:/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0-lib/lib/gcc/arm-none-eabi/12.2.0/:/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0-lib/lib/gcc/arm-none-eabi/ LIBRARY_PATH=/gnu/store/…-gcc12-cross-newlib-arm-none-eabi-12.2.0-lib/lib/gcc/arm-none-eabi/12.2.0/:/gnu/store/…-newlib-arm-none-eabi-4.3.0/arm-none-eabi/lib/ COLLECT_GCC_OPTIONS='-v' '-E' '-mcpu=arm7tdmi' '-mfloat-abi=soft' '-marm' '-mlibarch=armv4t' '-march=armv4t' You may want to try to add -B /gnu/store/…-newlib-arm-none-eabi-4.3.0/arm-none-eabi/lib to the linker options or to add COMPILER_PATH=/gnu/store/…-newlib-arm-none-eabi-4.3.0/arm-none-eabi/lib in front of your command. Tell me about your results. I'm about to update to GCC 13. There is some issue to work around (which smells like a similar one in Gentoo¹), I’ll see if I can add the newlib path to the COMPILER_PATH as well. Bye Stefan ¹ https://bugs.gentoo.org/905118
