<brendyn>Basically everything to be honest. Even listing all the correct dependencies as packages have different names compared to other distros sometimes, or two separate packages in guix might actually be a single package in guix
<erudition>yeah, that seems pretty trivial. A dataase with the corresponding package names would need to be created, and the importer would look it up.
<brendyn>The most complex part is the build it's self. have a look at some examples of (arguments ...) fields in the repository. you will see a large % of packages have all sorts of hacks to get them to work.
<erudition>hmm. perhaps it could work for the rest of them, then?
<erudition>the existing build scripts have to be useful somehow
<brendyn>It's best that you simply try package a few programs and you will start to see how difficult it is. Even font packages are more complicated than I imagined before I made one, and all they have to do is place some files in a directory
<brendyn>I'm confused about the role of xdg-mime-database. it seems to be generated when shared-mime-info is in the profile, but conflicts with it. on other stateful distros, there is just a shared-mime-info package and it runs update-mime-database
<brendyn>but on guix that dynamically created xdg-mime-database package does the update-mime-database bit. so for a package that requires shared-mime-info im not quite sure what to do.
<brendyn>i hate it when i get stuck confused over some small thing and it burns up a lot of time. im just going to post some patches now
<brendyn>turns it its simply because other distros tweak their mime data
<brendyn>there's all these different directories and files that are checked in a certain order to decide which program to open. I'd like to have sensible defaults. Pdf's should open in a pdf reader before an image editor
<efraim>back to yesterday's discussion about openbsd 'devving' with libressl in place of openssl, openntpd has support for libressl functions that aren't in openssl or gnutls
<brendyn>btw, are 'collisions' only file collisions with different hashes, or will two identical overlapping files from different packages get reported as a collision too?
<ng0>efraim: are there reasons for libressl? I only see it as necessary where projects decide that it's madatorx to build against libressl
<brendyn>civodul: You gave me some tips about packaging goldendict before. Can you spot why this patch causes a segfault when processing then env variable? gdb pointed to the line 'out' variable. I think there is something wrong with how it's defined
<m-o>efraim: yes, the command line we are using for grub contains deprected options, not working with -m virt target.
<m-o>efraim: no, everything went ok for the disk-image.
<efraim>Mine complained about a raw disk image and not wanting to write to the first sectors
<m-o>hmm, strange. i had thousand of issues but not this one. The main problem with this whole thing is that producing copying and registering files in qemu virt machine takes hours even on real arm hw.
<vagrantc>a reasonably recent u-boot ought to work with grub-efi
<m-o>vagrantc: oh ok, it will be a good follow-up.
<vagrantc>though, to be honest, i've had mixed results when i tested last year and haven't tested since
<vagrantc>lot of commits in upstream u-boot about it since, though
<CharlieBrown>How difficult is it to put get GuixSD on ARM? Just recompile the bootstrap binaries and build everything from there?
<lfam>efraim: I pushed a commit to build OpenNTPD with LibreSSL, enabling the use of TLS time constraints. Thanks for the tip!
<efraim>thanks, i'll keep on working on the service
<lfam>CharlieBrown: We already can build packages for armhf (32-bit). The tricky bit is figuring out the bootloader / kernel, which is handled differently from x86_64 and i686. But, someone booted it on one particular armhf board earlier today!
<lfam>The run-time graph is actually bigger. p11-kit uses libtasn1 and libffi
<lfam>And somehow it refers to bash-static and bash-minimal
<efraim>openntpd service looks like its working in the VM, minus the ipv6 constraint, which is expected since my ISP is ipv6 deficient
<rekado>I can reproduce the Emacs startup crash on i686
<ng0>I think I've been able to reproduce the error someone reported on Kodi for many weeks or months before it was reported. I just did not think it was a bug, because I assumed my hardware is failing
<roptat>rekado: I tried to use build.xml from groovy 2.0 to build a more recent one, but they have moved groovy-ant away which creates a dependency loop between groovy-ant and groovy-template (because groovy-template is written in groovy)
<roptat>so I think what would work would be groovy 2.0 -> gradle 1.7 -> groovy 2.2 (or something) -> gradle 2.3 -> groovy 2.4.12 -> gradle 2.14.1 -> groovy 2.4.13 (maybe we can build groovy 2.4.13 with gradle 2.3?) -> gradle 4.3.1
<rekado>do newer versions of groovy no longer include the pure Java bootstrap that is built in groovy 2.0.0beta3?
<roptat>rekado: it does, but build.xml requires groovy-ant
<roptat>but we could probably just build groovy with our ant-build-system by adding the bootstrapping phases ourself