Re: create a symlink
Hi Rene, On Fri, 08 Mar 2019 15:13:13 -0600 Rene wrote: > Danny Milosavljevic writes: > > > > > What is supposed to load the "/hurd" that would be created ? > > > > After starting GNU Mach microkernel, the hurd translators are required to > start > the operating system. > > At the moment all components like gnumach, hurd servers point to /hurd. > > Maybe there is a way to avoid links? I see. I ask because usually the part that loads that can be adapted and is also a better place to do the adaption in the first place--instead of hard-coding "/hurd". After all, we want eventually to have the ability to roll back the system by selecting a previous generation in the bootloader menu again. That doesn't work all that well with the "/hurd" link. But as far as I understand, you boot Debian/Hurd or something and then it loads Guix, right? In that case, we can understand the GNU Mach microkernel as a bootloader (from our vantage point) and thus emit the /hurd link in the "bootloader" configuration. It's not that clean, but it works (sans rollback, though). Cleaner would be to also boot Guix's gnumach microkernel. It seems that https://www.gnu.org/software/hurd/grub.html documents how to get grub to boot mach and then hurd--and it seems that there, the paths are specified. It should be easy to adapt gnu/bootloader/grub.scm's grub-configuration-file to emit those and then reconfigure. (Later, we could add "multiboot" and "modules" to in gnu/bootloader.scm) However, it's a dangerous part to modify since this part cannot be rolled back easily. So don't make a typo ;) pgpOjPX07H0ar.pgp Description: OpenPGP digital signature
Re: 01/01: gnu: Add hyperledger-fabric.
Hello! A couple of minor issues: guix-comm...@gnu.org skribis: > commit 983550692dbf5a41afef1b1cae53fece42b3d4bf > Author: Pierre Neidhardt > Date: Thu Feb 21 19:07:09 2019 +0100 > > gnu: Add hyperledger-fabric. > > * gnu/local.mk (hyperledger): New variable. Really? :-) > + (replace 'build > + (lambda _ > + ;; Only linux-amd64 and linux-ppc64le seem to be supported at > the moment. > + (invoke "make" "-C" "src/github.com/hyperledger/fabric" > + "release/linux-amd64"))) I don’t know how much of a difference it makes in this case but it might be worth considering passing “-j” (number->string (parallel-job-count)). > + (copy-recursively > + "release/linux-amd64/bin" Is this really limited to x86_64-linux? If so, please add a ‘supported-systems’ field. Then again, this “linux-amd64” thing looks worrying: can you confirm the checkout doesn’t contain pre-built binaries? > +(synopsis "Platform for distributed ledger solutions") > +(description "A platform for distributed ledger solutions, underpinned by > +a modular architecture delivering high degrees of confidentiality, > resiliency, > +flexibility and scalability.") Please turn the description into a sentence, and ideally something less marketing-ish. :-) Thanks, Ludo’.
Re: Guix system cross-compile
Thanks everyone for the help! So it seems for armhf, I should be using "--target" unless I am trying to get the bootstrap seeds. Mathieu Othacehe writes: > Hi Alex, > > This subject is explained in "Package Transformation Options" section of > the documentation. In short: > > --system means try to build natively for the specified architecture. It > is possible on the arch that support multiple personalities (i686 and > x86 for instance), or using QEMU binfmt_misc mechanism. The argument > is an arch name like "x86_64-linux", "armhf-linux" or "aarch64-linux". > > --target means cross-compile for the specified architecture. The > argument is a GNU triplet such as "mips64el-linux-gnu". > > Mathieu signature.asc Description: PGP signature
ffmpeg: error while loading shared libraries: (...): file too short
Hello guix,
Does anyone has the same problem with ffmpeg from latest master? I've
got the following error:
alexvong1995@debian:~$ ffmpeg --help
ffmpeg: error while loading shared libraries:
/gnu/store/4hcr7ygdhaxws6q5dj806cbvq0dkfgkw-ffmpeg-4.1.1/lib/libavdevice.so.58:
file too short
The following command shows that most of the shared libraries built are
empty:
alexvong1995@debian:~$ LC_ALL=C find "$(guix build ffmpeg)/lib" -type f
-execdir ls -hl '{}' ';'
-r-xr-xr-x 26 root root 0 Jan 1 1970 ./libavformat.so.58.20.100
-r-xr-xr-x 26 root root 0 Jan 1 1970 ./libavutil.so.56.22.100
-r--r--r-- 6785 root root 0 Jan 1 1970 ./libavfilter.pc
-r--r--r-- 6785 root root 0 Jan 1 1970 ./libavutil.pc
-r--r--r-- 6785 root root 0 Jan 1 1970 ./libavresample.pc
-r--r--r-- 6785 root root 0 Jan 1 1970 ./libpostproc.pc
-r--r--r-- 6785 root root 0 Jan 1 1970 ./libswresample.pc
-r--r--r-- 6785 root root 0 Jan 1 1970 ./libavcodec.pc
-r--r--r-- 6785 root root 0 Jan 1 1970 ./libavformat.pc
-r--r--r-- 6785 root root 0 Jan 1 1970 ./libswscale.pc
-r--r--r-- 6785 root root 0 Jan 1 1970 ./libavdevice.pc
-r-xr-xr-x 26 root root 0 Jan 1 1970 ./libavdevice.so.58.5.100
-r-xr-xr-x 26 root root 0 Jan 1 1970 ./libavfilter.so.7.40.101
-r-xr-xr-x 26 root root 0 Jan 1 1970 ./libavresample.so.4.0.0
-r-xr-xr-x 26 root root 0 Jan 1 1970 ./libswresample.so.3.3.100
-r-xr-xr-x 26 root root 0 Jan 1 1970 ./libpostproc.so.55.3.100
-r-xr-xr-x 26 root root 0 Jan 1 1970 ./libswscale.so.5.3.100
-r-xr-xr-x 2 root root 14M Jan 1 1970 ./libavcodec.so.58.35.100
I'm CC'ing guix-devel since ffmpeg is essential to many audio/video
packages (e.g. mpv, vlc).
Cheers,
Alex
signature.asc
Description: PGP signature
Re: ffmpeg: error while loading shared libraries: (...): file too short
Alex, Something is amiss on your box. Alex Vong wrote: Does anyone has the same problem with ffmpeg from latest master? I've got the following error: alexvong1995@debian:~$ ffmpeg --help ffmpeg: error while loading shared libraries: /gnu/store/4hcr7ygdhaxws6q5dj806cbvq0dkfgkw-ffmpeg-4.1.1/lib/libavdevice.so.58: file too short --8<---cut here---start->8--- λ file -L /gnu/store/4hcr7ygdhaxws6q5dj806cbvq0dkfgkw-ffmpeg-4.1.1/lib/libavdevice.so.58 /gnu/store/4hcr7ygdhaxws6q5dj806cbvq0dkfgkw-ffmpeg-4.1.1/lib/libavdevice.so.58: ELF 64-bit LSB pie executable x86-64, version 1 (SYSV), dynamically linked, stripped λ ls -lh /gnu/store/4hcr7ygdhaxws6q5dj806cbvq0dkfgkw-ffmpeg-4.1.1/lib/libavdevice.so.58.5.100 -r-xr-xr-x 2 root root 152K Jan 1 1970 /gnu/store/4hcr7ygdhaxws6q5dj806cbvq0dkfgkw-ffmpeg-4.1.1/lib/libavdevice.so.58.5.100 --8<---cut here---end--->8--- Have you fsck'd your file system lately? T G-R
Re: 01/01: gnu: Add hyperledger-fabric.
Ludovic Courtès writes: >> commit 983550692dbf5a41afef1b1cae53fece42b3d4bf >> Author: Pierre Neidhardt >> Date: Thu Feb 21 19:07:09 2019 +0100 >> >> gnu: Add hyperledger-fabric. >> >> * gnu/local.mk (hyperledger): New variable. > > Really? :-) This is a common error when using the “add” yasnippet :) It’s worth checking the produced commit message, because it often gets it wrong when more than one file is altered. -- Ricardo
building "guix deploy"
Hello everyone!
Chris Webber and I spent the morning chatting about how we want to
approach making "guix deploy" a reality and then started hacking on it
in the afternoon. Although we weren't able to complete a working
prototype by the end of the day, we were able to get pretty close. We
created a 'guix deploy' CLI to build derivations for any number of
remote systems on a local workstation and initiate the transfer to the
remote systems, but we encountered a difficult to debug SSH error that
blocked our progress:
sending 85 store items (0 MiB) to 'test.activitypub.rocks'...
exporting path
`/gnu/store/ylcdmrj3vf00ixdcjvkl3mbs8f5i9w8l-git-minimal-2.20.1.drv'
;;; [2019/03/09 17:32:48.792589, 0] write_to_channel_port: [GSSH
ERROR] Remote channel is closed: #
Backtrace:
10 (apply-smob/1 #)
In ice-9/boot-9.scm:
705:2 9 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 8 (_ #(#(#)))
In guix/ui.scm:
1654:12 7 (run-guix-command _ . _)
In guix/scripts/deploy.scm:
72:8 6 (guix-deploy . _)
In srfi/srfi-1.scm:
640:9 5 (for-each # …)
In guix/scripts/deploy.scm:
74:20 4 (_ _)
In gnu/machine.scm:
58:22 3 (_ _ _ _)
In guix/ssh.scm:
313:4 2 (send-files # _ _ # _ # …)
In guix/store.scm:
1504:7 1 (export-paths # _ # …)
In unknown file:
0 (put-bytevector # …)
ERROR: In procedure put-bytevector:
Throw to key `guile-ssh-error' with args `("write_to_channel_port"
"Remote channel is closed" #
#f)'.
If anyone knows what might be going on here and how we could resolve
it, your input would be much appreciated! We verified via the sshd
logs that we were indeed successfully establishing a connection.
Once we're past this blocking issue and are able to transfer OS
closures to remote systems, we plan to write a modified version of
switch-to-system that uses guile-ssh to switch remote symlinks for the
active system and run the activation script. We'll save
upgrade-shepherd-services for later, as it is quite a bit more
complex.
There's not a lot of code yet, but you can check it out in the
wip-deploy2 branch. Currently, the only supported use-case is running
the equivalent of 'guix system reconfigure' on machines already
running GuixSD that have an OpenSSH daemon running, but the basic
design allows for additional use-cases to be supported in the future.
Thanks to Ricardo for his install-berlin.scm script that provided a
basis for most of our code, and to Ludovic for the (guix ssh) module
that I wish I had when I attempted to write 'guix deploy' all those
years ago.
Until next time...
- Dave
New German PO file for 'guix-manual' (version 0.16.0.1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix-manual' has been submitted by the German team of translators. The file is available at: https://translationproject.org/latest/guix-manual/de.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/guix-manual/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/guix-manual.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: Packaging FreeCAD
Hi guix, Just a quick update. I have little to report on freecad. I am still stuck packaging pyside2. I have looked over the debian packaging rules but I am unfamiliar with their packaging process. I did some research and it looks as though they are using the normal pybuild process with some alterations to some paths afterward. The package completely fails to compile for me and I am no expert on python build tooling. Here's what I have tried so far and the error: https://paste.debian.net/1072533. Any help would be very appreciated. Thanks, John On Fri, Feb 15, 2019 at 6:33 PM John Soo wrote: > Thanks so much Paul! This is really helpful! > > > On Feb 15, 2019, at 9:20 AM, Paul Garlick < > pgarl...@tourbillion-technology.com> wrote: > > > > Hi John, > > > >> I have been getting a little stuck building the pyside2 dependencies > > > > There has been an effort to package pyside2 for Debian. This has been > > completed in the last six months. > > > > A good place to look for information is > > https://tracker.debian.org/pkg/pyside2 > > > > You can browse the source code and follow the links to the 'debian' > > directory, which contains the files that govern the packaging process. > > In general for Debian packages, the 'rules' file is worth reading and > > the 'patches' directory has the changes to the upstream code. > > > > One element that could be important in Guix is an update of patchelf to > > a recent commit (see 'update-patchelf.patch' in the patches directory). > > > > Best regards, > > > > Paul. > > >
Re: Guix on the ASUS C201PA
On 2019-03-06, Timothy Sample wrote:
> Vagrant Cascadian writes:
>> On 2019-03-06, Timothy Sample wrote:
>>> I was able to get Guix to boot on an ASUS Chromebook C201PA.
So, I've gotten the kernel to load, but the version of coreboot and/or
depthcharge I have installed seems to ignore the presence of the initrd
(which you had mentioned in your initial mail). I guess I should try
libreboot again, maybe it fixed some other things too...
I did manage to get the rockchip.usb_uart with a hacked up USB cable to
produce a serial console for debugging and actually seeing the kernel
logs rather than them scrolling pass the screen only to give a kernel
panic.
(kernel-arguments '("console=ttyS2,115200" "rockchip.usb_uart"))
Anyone had any luck booting GuixSD without an initrd? I sort of thought
about dumping the initramfs to a partition and trying to work around it
that way...
I've also got patches to pull in u-boot 2019.04-rc3 with a
chromebook_speedy target for installing directly to flash, as well as
one to load from depthcharge. Unfortunately, I still get no
video. Someone's working on porting rockchip.usb_uart to u-boot to make
it easier to see what's going on. Mostly hoping to just get u-boot
support working and forget about depthcharge.
>> I have two big technical frustrations with Depthcharge:
>>
>> It's really hard to debug or select alternate kernels when boot is
>> failing.
>>
>> The kernel+initrd is limited to ~16MB. linux-libre on armhf is about
>> 5MB, and the initrd around 11MB... so it's running pretty close to that
>> limit (Debian initrd's are even larger these days). I even increased the
>> size of the partition to 32MB to see if it would work, but it refused to
>> boot from anything larger than 16MB.
>
> I didn’t know about the image size limit. Guix (with the very spartan
> PrawnOS kernel build) is only 14M, so I guess I was just lucky here.
This may have just been the older libreboot build I once had; I notice
that prawn-os and gentoo seem to work fine with 32MB/64MB kernel boot
partitions. Or maybe some other misunderstanding on my part about why
depthcharge refused to boot it... just now starting to grasp all those
"cgpt" partitioning flags.
live well,
vagrant
signature.asc
Description: PGP signature
Re: Typo on Savannah project page.
Just checked again and it looks good now.
Re: Packaging FreeCAD
On Sun, Mar 10, 2019 at 02:14:15AM +, John Soo wrote: > Hi guix, > > Just a quick update. I have little to report on freecad. I am still stuck > packaging pyside2. I have looked over the debian packaging rules but I am > unfamiliar with their packaging process. I did some research and it looks > as though they are using the normal pybuild process with some alterations > to some paths afterward. The package completely fails to compile for me > and I am no expert on python build tooling. Here's what I have tried so far > and the error: https://paste.debian.net/1072533. Any help would be very > appreciated. > > Thanks, > > John > > On Fri, Feb 15, 2019 at 6:33 PM John Soo wrote: > > > Thanks so much Paul! This is really helpful! > > > > > On Feb 15, 2019, at 9:20 AM, Paul Garlick < > > pgarl...@tourbillion-technology.com> wrote: > > > > > > Hi John, > > > > > >> I have been getting a little stuck building the pyside2 dependencies > > > > > > There has been an effort to package pyside2 for Debian. This has been > > > completed in the last six months. > > > > > > A good place to look for information is > > > https://tracker.debian.org/pkg/pyside2 > > > > > > You can browse the source code and follow the links to the 'debian' > > > directory, which contains the files that govern the packaging process. > > > In general for Debian packages, the 'rules' file is worth reading and > > > the 'patches' directory has the changes to the upstream code. > > > > > > One element that could be important in Guix is an update of patchelf to > > > a recent commit (see 'update-patchelf.patch' in the patches directory). > > > > > > Best regards, > > > > > > Paul. > > > > > I haven't tried building it myself yet, but two things come to mind: Try using qtbase instead of qt, it has a much smaller footprint and will likely be requested when it's time to include the package in Guix. You're using version 5.12.1, and in Guix we have qt 5.11.3. It's likely the errors you're getting are because the version of Qt is different. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
