<buenouanq>But I also strongly believe that a wob browser should have no say in media handling at all and through things to other programs. <qih>buenouanq: Good point <qih>Although my onboard graphics does not help. <buenouanq>You can supposedly replace things in the browser like the video player with whatever you wish (I suggest mpv) - I've just never got around to figuring this out. <qih>Good point, me either, defaults are fine but perhaps I should finesse it all a bit <qih>ACTION installs Guix, bbl I hope 8-) <qih>Whoops, wrong channel <brendyn>qih: maybe check the hash of the file? <qih>brendyn: I'll start from scratch to make sure. <qih>Verifying the .sig on the correct *.xz gives me an error, it did yesterday also <brendyn>because you do not have the public key downloaded to check it against <brendyn>there should be instructions somewhere to get it <qih>Ahh whoops, I don't know how I missed that line ... mea culpa, thanks <brendyn>paying attention to error messages is an artform <qih>gpg: Can't check signature: public key not found <= sigh <qih>brendyn: OK that fixed it, of course ... ***Digitteknohippie is now known as Digit
<apteryx>Strange. debbugs-gnu for guix is not showing bug 26833 in the list. I wonder why, as it's still opened? ***pksadiq_ is now known as pksadiq
<erudition>Hello everyone, any chance there's a Guix feature (or script) that will take some software, already packaged for another PM, and generate a Guix recipe for it? <brendyn>erudition: run `guix import --help' and you'll see a couple. <brendyn>You can make more for new package managers if you like <erudition>oh awesome! how realistic is it to get a working result with DEBs? <brendyn>hmm actually what you want is different. import takes the metadata for a package and then tries to create a package definition out of it <erudition>okay. so metadata only then, but the rest of the recipe you must write yourself? <brendyn>yeah. did you want to make a guix package, or try to run a debian binary package on guix? <brendyn>some times the package is simple enough that it will work without any edits <erudition>I don't think building it in Guix is possible in the orthodox way - but they have a deb package so I figure that means a recipe can be created <brendyn>It's tricky because the debian package will be compiled to refer to debian versions of other packages and will refer to directories like /bin/ <erudition>Hmm. I was thinking there might be a script to change such things. <erudition>But I suppose if that was the case we'd already have far more packages <brendyn>It's not in our interest to build the Guix repo based on binaries from other sources. We fully define how to build packages from source. <erudition>I've only been talking about building from source. <brendyn>oh ok i wasn't quite sure what your idea was <erudition>Sorry, I'm not yet familiar with the right terms. <erudition>Exactly, a debian importer seems like an obvious way to easily reap from the massive debian repo <brendyn>I think it's too difficult to import packages completely automatically. It kinda requires human level intelligence to solve :p <brendyn>I think it would be cool to build some kind of emulation system to run debian packages on top of guix <erudition>Oh yeah, that would help bootstrap the ecosystem <erudition>Can you give an example of something that requires a human to go from deb -> guix recipe? <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 <erudition>think there's anything Guix can do to reduce that complication? placing files in a directory shouldn't be hard <brendyn>Actually someone created a font-build-system, so maybe 75% of them can be done automatically <brendyn>except you also need to add nice descriptions for packages <erudition>Right. License isn't all tha much human work at least. The description can probably just be copied over. <brendyn>There is a little bit of formatting like @code{} and @itemize ***Digitteknohippie is now known as Digit
<civodul>we are not running gvfs-udisk2-volumne-monitor et al but i think we should <civodul>that's probably the reason why things don't get automounted in GNOME & co. <efraim>The output directories are determined before the building starts, right? <brendyn>Does anybody else also get many conflicts between shared-mime-info and xdg-mime-database ? <civodul>brendyn: probably everybody does; what are the conflicting files? <brendyn>all sorts of xml files in /share/mime/application/ <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 <civodul>it seems i never had to ask myself these questions :-) <brendyn>well i went down a rabbit hole figuring out why xdg-open opens pdf files in gimp instead of evince by default <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 <efraim>It allows for checking https headers <ng0>and that's something neither GnuTLS nor OpenSSL can do? <brendyn>it's a project to clean up openssl code base isn't it? <efraim>I tried building with each of them, they didn't have the right...something <efraim>that's how it started, they've moved past that though <ng0>too bad that OpenSSL gets more support, more check and better funding, while OpenBSD struggles with funding regulary, ignores good practices for their own dogma, etc <civodul>30087 access("MARK: nautilus finish_loading: end BEGIN_LOADING", F_OK) = -1 ENOENT (No such file or directory) <civodul>that debugging output is mistaken for a file name <ng0>maybe dogma was the wrong word, but they ignore lots of reasonable good techniques in some of their projects <ng0>I only have this information second hand from someone who digged through their code and libressl <ng0>anyway, the feature sounds nice from the very short description <brendyn>civodul: Are you trying to figure out why those system mounts are displayed? <brendyn>Cool. I tried a little bit but it was a bit over my head. <rekado>civodul: things do get automounted on my system when gvfs is in the system profile. <rekado>the volume monitor is started by dbus IIRC. <brendyn>I have gvfs in my profile but it still doesn't work for me. <civodul>also, i just tried and g_unix_mount_is_system_internal works as advertised, ie., it correctly flags "internal" mounts <rekado>brendyn: in your *system* profile? <rekado>when I say “automount” I really mean: things appear in nautilus and when I click on the disk label it mounts the disk. <brendyn>rekado: yeah. my drives dont even appear in nautilus <efraim>ng0: from openntpd's README: libtls (included with LibreSSL 2.1.4 or higher) is required for HTTPS time constraint validation. <ng0>no surprise for me, it's another OpenBSD project and they like to use what they develop. <ng0>our structure allows us to make use of libressl and openssl at the same time. what's the issue? ***pksadiq_ is now known as pksadiq
***jonsger1 is now known as jonsger
<g_bor>I've been hanging on hydra recently, and I saw that we have a task in guix called tarball which does not build. <g_bor>It seems, that convert is missing. <m-o>civodul: just succeeded in booting guixsd installer on bbb ! <civodul>are you using a Guix-provided bootloader or the one that was already there? <m-o>nope Guix bootloader installed on sd-card :) <m-o>via dd commands, like on intel targets. <efraim>I also copied some of your kernel fixes for my arm64 kernel attempt <m-o>efraim: good to know. You will also be interested in qemu patches i'm about to submit i guess. <efraim>You also had issues with -machine virt I assume <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>*qemu not grub sorry <efraim>Did you have issues with the disk-image never growing? <brendyn>My friend wrote the patch for me but it didn't work and now I'm trying t debug it :( <m-o>efraim: i used extlinux config file on top of u-boot. I don't think grub is supported on bbb. <m-o>nixos is doing about the same thing. <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! <efraim>if I run '/./$(guix system vm image.scm)' what am I missing for an internet connection inside the vm? <lfam>efraim: Something like this: <lfam>$(guix system vm image.scm) -net user -net nic,model=virtio <lfam>You might need a different NIC model depending on the host system <lfam>Apparently p11-kit can take the place of OpenSSL in doing c_rehash. Maybe it would be a better option for le-certs <lfam>efraim: They both depend on Perl ;) <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 <roptat>actually I already have a package for the pure java part <roptat>maybe I can build groovy-template from the cli, which would help getting groovy-ant and finish the build with ant <lfam>Hm, looks like the GRUB test suite will need to be adjusted for the next release of QEMU