<bavier>has anyone successfully used our clang package to build anything? <civodul>bavier: yes, i've used it for CI stuff at work <civodul>there was one ld-wrapper bug that was causing problems, though <bavier>civodul: I've had trouble with clang++ not finding header files <paroneayea>davexunit: do you know what the state of luks encryption is in guix? <davexunit>don't quote me on this, but I think you can use it on non-root partitions easily enough <davexunit>but there's some limitation around booting an encrypted root or something. I can never remember and mark or someone has to correct me most of the time. :) <paroneayea>davexunit: maybe I need to bust out the olllld luks tutorials I used to follow back in the day <paroneayea>before debian had a builtin installer option and life was easy ;) <paroneayea>I'm even planning "which oldschool WM do I want to run again when I switch to guixsd if I put it on my laptop?" and getting excited about it :) <davexunit>GuixSD will feel more like a "real" distro soon enough once we have GNOME 3 <aeva>so with regards to luks, is the thing to do with guix is not bother for now? :P <davexunit>c'mon, I thought guixsd was for the brave! :) <paroneayea>I'm guessing it should at least be possible to encrypt /home/ ? <aeva>davexunit for the brave, yes, but maybe not for the clueless? :) <iyzsong>paroneayea: yes, I have to enter password in grub and initrd twice. I never use it on other distros, is this common? <iyzsong>gnome-shell launched, with problems of missing icons, wallpaper can't be changed, reboot/shutdow don't work, etc.. :o <davexunit>sending ludo a "let me google that for you" link <Luke-Jr>besides the new reproducable builds stuff, I mean <Luke-Jr>(I'm mostly interested in what I'd lose to switch.) <foreverska>Will there be releases? Or just a pick and choose menage of versions? <fps>Luke-Jr: what you lose by switching from portage to guix? <fps>probably quite a few packages <fps>foreverska: there are releases sometimes <wingo>wow, gmp maintainer scoring very well in the asshole olympics :) <fps>hey hey, trigger warn me please before using rude language [kidding ;)] <rekado>JACK2 is a reimplementation of the same idea and the only thing it offers over JACK1 is dbus autostart. <rekado>in Guix we use JACK1 as input to all packages that need JACK. Users can choose to install JACK2 into their profiles, but I'm not sure how the dbus autostart thing would work as I have no use for it. <rekado>We don't have qjackctl (I use jackd on the command line and patchage for managing connections). <rekado>I'm using JACK1 regularly on a GuixSD machine together with Ardour and patchage. <magnetophon>rekado: Thanks. Did you see the issue I linked? The problem is that jack1 programs aren't finding the libs <rekado>magnetophon: I didn't encounter this problem. All our JACK-needing packages are built with jack1 and I haven't seen any problems with them at all. <rekado>I also didn't need any LD_LIBRARY_PATH hackery to make it work. <rekado>no, I haven't. I don't need it for my projects. <rekado>I don't know if jack2 actually works in Guix. Maybe some other people use jack2 and could let you know if there are any issues. <rekado>I could give it a try over the weekend and see if jack1-clients can connect to a jack2 server. <magnetophon>rekado: that would be great, especially if you could report back on the github issue. <fps>rekado: jack2 offers another nifty little feature <fps>1] smp support, so you can use more than once core for the jack process cycle graph <fps>2] a mode with one extra buffer of latency that can protect you from crackles if a process doesn't meet its deadline <fps>it's unfortunate that the two projects diverged, but the maintainers are both too stubborn to fix that :) <rekado>hmm, ruby-unf-ext fails on all architectures. <davexunit>I've noticed a few times now that people have criticized the use of Guile in Guix because it doesn't force functional purity like the Nix language does. <civodul>yeah, Bash and Perl are very good at forcing functional purity, too <civodul>(sorry for the tone, i'm still thinking over that message from Torbjörn) <civodul>davexunit: so do you think there are concrete concerns reported, regarding lack of "functional purity"? <davexunit>Haskell people think that a single paradigm has to be forced for everything, Lisp lets you use whichever paradigm you find best or invent new ones. <davexunit>so sure, Guile cannot guarantee that someone couldn't accidentally slip impure code into the Guix codebase <davexunit>but I don't find it to be a compelling argument. <rekado>new Haskell converts maybe; the language allows for impurity. It's just ugly. <civodul>i've seen comments from Nixers like "oh but Scheme is not lazy" <civodul>but that's really an over simplification <civodul>it doesn't mean much whether Scheme is lazy or not <civodul>what matters here is that package objects are lazily compiled to derivations <fps>btw: i'm trying my hands on using emacs to work on this android job i scored.. <fps>since all IDEs crashed and burned within minutes of me starting them.. <davexunit>because the whole world revolves around eclipse <fps>eclipse didn't manage to update the screen without missing regions ;) <fps>androidstuio was nice enough to set me up a gradle based build. so my M-x compile is now: cd ~/AndroidStudioProjects/SymmediaSP1/ && JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ ./gradlew installDebug <fps>davexunit: i worked with eclipse on android projects previously. sure it's nice to get symbol completion out of the box, etc.. <fps>but those are really optional :) <fps>um, package a c64 emu and install an image editor there? ;) <fps>or an amiga emu.. :) <rekado>davexunit: we have synfigstudio which can be used for character animation. <fps>davexunit: is it nonfree software? <kmicu>davexunit: could you provide sources of “noticed a few times now that people have criticized the use of Guile in Guix because it doesn't force functional purity like the Nix language”? <fps>oh right, i missed the github link <davexunit>it's generally in random comments on various sites <davexunit>kmicu: I'm not here to prove things to you. I just brought up something I've noticed from time to time. <rekado>(I think it would only count as FUD if the direction was inverted; in this direction it's just anecdotal.) <kmicu>You are claiming something ‘noticed from time to time’ I call for proves/sources and nothing more. Is that a wrong thing to do? <rekado>kmicu: I just think it's unrealistic to ask for sources for random comments on various sites (e.g. by random people on HN, in chat, etc). <rekado>there's little to gain from that. <taylan>kmicu: it's a bit strange to ask a Guix developer/contributor for proof, when they say they noticed people say bad things about Guix <davexunit>I feel like I should be able to bring up an anecdote to discuss without someone accusing me of spreading FUD <taylan>if it were someone random strolling into the channel and saying things like that, then asking them to be more precise would make sense... <davexunit>I'm going to drag any lakes looking for other examples <kmicu>Thank you for the link. I wanted to check if the source is a Nix(OS) contributor, but it is a ‘random person’ cargo–culting a programming language. Not sure whether such *anecdotes* are worth *antagonizing* communities — not only Guix/Nix but also others with a language like ‘Haskell people think…’. <davexunit>civodul: I've seen that mentioned a few times before, too <davexunit>that NixOS only uses free software unless you opt-in to nonfree stuff <civodul>but yeah, it's a frequent kind of comment, if i dare say so ;-) <davexunit>civodul: why is not true? I've never used Nix. is there no such opt-in mechanism? <kmicu>civodul: how could a user install nonfree software w/o ‘allowUnfree = true’? <rekado>I am (or used to be) a Haskell person. I still like Haskell even though I don't use it anymore. <rekado>I agree that "Haskell people think..." is a bit inflammatory wording. <kmicu>(Nonfree packages do not show up in nix-env’s search results unless you enable ‘allowUnfree = true’.) <civodul>kmicu: my point is that most packages have no license field at all <civodul>historically there has been a missed opportunity, which largely justifies Guix <kmicu>*Most* packages do no have license field *today*‽ Let me check the numbers, b/c if that’s true nixpkgs has a bug which should be fixed. <civodul>that being said, i'm not trying to point fingers or antagonize the projects :-) <kmicu>Nothing agonizing with stating *facts*, but if they are not facts then that’s another story. <civodul>kmicu: it's not a bug; there's never been any policy in that regard <rekado>kmicu: searching for "unrar" I see that the license is shown as "unknown", but the recipe contains a license declaration. <kmicu>civodul: Missing license field is a bug IMO. <civodul>in your opinion, sure; but NixOS is a large project now <rekado>erm, not "unknown", but "Not specified". <civodul>in 2009 i failed to convince people for a change <kmicu>(But don’t confuse what web UI shows with what is in nixpkgs repo, b/c web ui is ‘pretty lame’ and inaccurate.) <rekado>kmicu: I just thought I'd mention it, because this might confuse people here. <civodul>anyway, i'm happy with the similarities and differences between NixOS and Guix <civodul>we can understand each other and yet see there's room for the two projects :-) <kmicu>Don’t get me wrong. I’m very thankful that we have *GNU* Guix package manager and *GNU* GuixSD distro and all of that is *lisp* flavored. I just don’t understand narrative of ‘war’, ‘X people thinks…’ rhetoric and discussions not based on facts. I have hardware with Guix *and* Nix and it’s disappointing to see antagonism if both projects have *some* common goals. <davexunit>you've misunderstood. we're not antagonistic with the Nix project. <davexunit>both projects share things with each other on a regular basis. <davexunit>the Nix devs I've talked to so far are nice and supportive. <davexunit>my "Haskell people" comment earlier was about a more meta software design philosophy topic. The Haskell methodology vs. the Lisp methodology. <davexunit>but, I'm excited to see that the free GPU driver needed for the Novena may be available in the mainline kernel soon. <davexunit>really, I think the main issue with autotools is the programming API. give users a better language (guile, of course) and we'd be in good shape. <rekado>"Why does it look like gorilla spit?" <civodul>davexunit: that's why i think we need a Scheme → shell compiler :-) <bavier>civodul: I was just going to make some retort about the portability of shell, but such a compiler would give the best of both worlds <davexunit>rekado: thanks for the link. seems like a good read. <bavier>and then add guile extension capability to autoconf <davexunit>anyone want to quickly look over my sdl2 patches? they are quite simple. <davexunit>my email setup has been pretty broken for months which makes it not convenient :( <rekado>davexunit: I'll try to remember to look over the sdl2 patches when I get home. <piyo>hello do you recommend "notmuch" for email? <rekado>piyo: davexunit uses notmuch afair; I used it before switching to mu4e. They are both nice. <piyo>Good for reviewing patches? <davexunit>for some reason offlineimap hasn't been able to sync my IMAP account in *months* <davexunit>I'd just use my gnu.org address, but they don't do IMAP!! <rekado>notmuch just provides you with a way to index and search mail. To compose emails or read plain text mail the appropriate Emacs modes are used. <davexunit>my complete setup is OfflineIMAP + Notmuch + Emacs <piyo>my use case is just to read root's mail. <rekado>piyo: do you mean these automatic emails that crond sends to root's mailbox? <rekado>piyo: for those I usually don't even use a mail client. <piyo>? sudo $PAGER /var/mail/root ??? <davexunit>jenkins is a big java application... that will take awhile <rekado>on most systems I had "heirloom mailx". <rekado>looks like we don't have it in guix. <piyo>oh "jenkins" was a joke, there was a "Can we use jenkins for that" on HN and I heard some people use jenkins as a replacement for cron-like... <piyo>man I must be addicted to HN <davexunit>I want to use OBS in January so I can stream my desktop while I write a game for the Lisp Game Jam <davexunit>but I guess I can just use ffmpeg directly instead <davexunit>efraim: the problem with it that I saw is that it bundles all deps <davexunit>but it makes the packaging work a little harder <davexunit>actually, it looks like it doesn't let you use non-bundled things, as far as I can see <rekado>I'm fighting with a piece of software that doesn't care if you have compiled dependencies already; it wants to download them all from github and build them. Little shell snippets scattered all over the CMakeLists.txt. <bavier>ugh, running the boost tests filled up my tmp partition <davexunit>turns out that OBS doesn't actually bundle much <davexunit>because I guess mark has been out of contact for a bit <davexunit>OBS is weird, went it boots it makes me accept the terms of the GPL <bavier>davexunit: I've seen a few other programs do that <bavier>like a "hey, just so you know, you have all these freedoms. have a nice day!" <davexunit>surprisingly better put together than I thought <davexunit>used external libraries for everything AFAICT <efraim>deleted the failing test from subversion and now rebuilding <efraim>"test depreciated access content api" <efraim>also had to convert it to modify-phases, too many (alist-cons-after in #:phases <efraim>sometimes text fields are just so much fun: "SVN_I_LOVE_CORRUPTED_WORKING_COPIES_SO_DISABLE_SLEEP_FOR_TIMESTAMPS" <efraim>mark_weaver: I see you took the obvious subversion fix :) 1.8.15 makes *much* more sense than my trying to update to 1.9.3 <mark_weaver>efraim: yeah, for security updates, I think it's usually best to be conservative and minimize the chance of new problems being introduced. <efraim>I relied on debian-security a bit too much, they backported the fix to 1.8.10 <mark_weaver>well, thank you for helping with the security updates. it's a great relief to have your help :) <mark_weaver>in cases where there's no prompt upstream point release to fix security problems, I also often rely on Debian and Fedora for fixes. <mark_weaver>davexunit: I'm not a good person to do GRUB updates since I'm literally unable to test them. I have no machines that use a copy of GRUB on the hard disk :) <mark_weaver>well, except for my currently-non-functional YeeLoong, using a very different version a GRUB. <bavier>the CVE mentioned that the attack can be recreated in a VM, if that helps at all <mark_weaver>a broken GRUB is worse than anything else, since a broken GRUB can lead to an unbootable system with no ability to boot into an older generation of the system <mark_weaver>so, I really think that someone with the ability to test this on real hardware would be best <mark_weaver>and I'm looking to offload some of the security-updates work to others anyway :) <wwood>I'm not volunteering for helping with securuty updates, but I do have a hopefully easy query to solve <wwood>I just installed 0.9.0, and now get this error: guix package: error: build failed: some substitutes for the outputs of derivation `/gnu/store/prxvnskxpvpbkqj9x5nl01pvrlnpp22r-attr-2.4.46.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source <wwood>is there a way to verify it is a networking issue? <wwood>so it seems some packages download fine <efraim>hydra is slow, this is unfortunately a known issue that we're working on <wwood>I'm pulling 100+ kb from hydra though <mark_weaver>hydra is not overloaded at the moment, so maybe this is a different problem. <wwood>so it is ok and then goes slow quickly? Seems odd given attr download is only 87kb <mark_weaver>wwood: I just downloaded the outputs of that derivation successfully. it was quick. <wwood>so seems it is a networking issue then <wwood>do you mind if I ask how you verified the derivation? <mark_weaver>I typed "guix build /gnu/store/prxvnskxpvpbkqj9x5nl01pvrlnpp22r-attr-2.4.46.drv" <mark_weaver>(that command only works if I have that .drv file already present, and I did) <fhmgufs>When I installed GuixSD in a VM that error occurred several times, but after about five attempts it worked. <wwood>I originally came across that error running "guix pull" <wwood>and --fallback is not an option for that, by the way <AndChat404481>failed to install grub, any suggestion for me ? $grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. <AndChat404481>grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. <wwood>thanks for the help peoples. <mark_weaver>AndChat404481: if you use GPT, then there needs to be a BIOS Boot Partition <wwood>oh, actually think I might have figured my issue out. /gnu is mounted over nfs3, where on the file system serving that nfs mount it is /guix/gnu <AndChat404481>Sorr im copy it from other source. The real problem is happened when init-ing the system. Error msg: $ grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. <mark_weaver>wwood: some operations of guix-daemon, e.g. garbage collection, will perform very poorly over NFS, and there may be other issues as well <mark_weaver>wwood: rekado would be a good person to consult with about this <mark_weaver>wwood: also, be aware that guix does not support multiple machines having write access to the same store. there can only be one guix-daemon running on a given /gnu/store <mark_weaver>so, the only option for sharing a store is for only one machine to have write access to the store, and all other machines can only read from it. <wwood>mark_weaver: I've been following his blog post on the topic <wwood>I didn't realise it wasn't good enough to have only 1 machine with the store mounted rw <wwood>I'll ask for more details. Thanks. <mark_weaver>AndChat404481: but the reason "Embedding is not possible" is because your GPT disk apparently lacks a BIOS boot partition <AndChat404481>Oh, so can I enlarge it without destroying my partition data ? <mark_weaver>AndChat404481: enlarge what? I don't have enough context here. <fhmgufs>That must be a funny internet connection! <tsyesika>hey, I've written a package declaration and i'm wanting to test it out before i submit it, what's the best way to do that, the docs refer to "once a package definition is in place" I'm able to use guix build but it doesn't specify where it should go <fhmgufs>Clone the git repository and place the package at gnu/packages/. <tsyesika>i didn't, using guix build -i causes some guile traceback explosion heh <paroneayea>tsyesika: could you pastebin your traceback explosion? <fhmgufs>You must add the name of the package to build at the last line to use guix build. <fhmgufs>Remove it if you are ready with the package and tested the building. <fhmgufs>Just make a new line at the ending with the package name and try again. <efraim>at some point we're going to have to up our libinput to 1.x <aeva`>@paroneayea I saw something while looking through the gentoo luks tutorial last night, which was that they used a key file instead of a password for luks <aeva`>maybe it could be set up such that it lives on an SD card or the likes, instead of using a typed password? I'm not sure if that is a good idea or not <aeva`>I think "a thing that you know" is generally better than "a thing that you have" for this stuff ***aeva` is now known as aeva
<paroneayea>I'm gonna try to install both guixsd and debian on my new-as-in-refurbished laptop tonight <paroneayea>I wonder how I should split things up partition wise