IRC channel logs


back to list of logs

<lfam>Hm, is the mailman resting today? ;)
<lfam>My emails are a few hours late
<davexunit>I can't get IMAP access to my email it seems, urggh.
<xd1le>alezost: even nix does not have a proper way to do it:
<xd1le>... :/
<davexunit>xd1le: we need to extend 'guix download' to calculate this for us, but the manual process is easy
<davexunit>git clone foo.git
<davexunit>cd foo
<davexunit>git reset --hard commit-sha
<davexunit>rm -rf .git
<davexunit>guix hash -r .
<xd1le>ah so only need to remove .git and then it should good?
<xd1le>not so bad then, thought it was a bit more complicated then just that.
<davexunit>yes, that way the hash is deterministic.
<lfam>davexunit: Is that in the manual anywhere?
<davexunit>lfam: don't think so.
<davexunit>really, though, it ought to be just done automatically by 'guix download'
<davexunit>no one's gotten around to it yet, though.
<davexunit>the hardest part is actually not implementing this, but adjusting the 'guix download' command-line syntax to handle multiple types of download methods
<lfam>Yes, guix download
<lfam>I mean to say, Yes, guix download should handle it. And I assume that guix download uses guix hash internally? While adding the download feature?
<xd1le>davexunit: what about an option to guix hash to exclude files/subdirectories
<xd1le>in its calculation? or would that be too ugly?
<xd1le>asking because it's convenient to keep the .git
<xd1le>so to do guix hash, we'd have to copy the whole directory to make one
<xd1le>without .git in it.
<xd1le>so in that option, we'd pass ".git" to get the correct value
<xd1le>or ".hg" or whatever depending on the vcs
<davexunit>xd1le: probably a good idea
<xd1le>cool. :)
<zacts>lo guix
***jalle is now known as jockej
<rekado>We're not running the tests for GCJ. I'll add a phase to run "make check-target-libjava" later.
<rekado>GCJ seems broken on non-Intel, so it's best to figure this out in the build of GCJ rather than in Ant.
<jmd>What's the difficulty supporting LVM ?
<remi`bd>hey, still no news of the DHCP client GSoC project?
<toothbrush0>Hello Guix!
<toothbrush0>Question time: i have a configure script which expects "prefix=$outdir" instead of "--prefix=$outdir", i'm not sure how i can change that, since #:configure-flags seems to just add arguments.
<xd1le>what, that doesn't make sense... is that a typo by upstream or something?
<xd1le>or is this a convention also (albeit less popular)?
<toothbrush0>when you run `./configure --prefix=...` the script errors out; its `./configure --help` thing tells me it requires KEY=VALUE pairs, without "--"
<toothbrush0>xd1le: i guess they're just a special snowflake :P
<xd1le>yeah.. interesting. i'm not sure how to fix it either..
<toothbrush0>i've been digging around in guix/build/gnu-...scm, but it isn't clear to me if it's even possible without replacing the configure phase, which is a pity
<xd1le>yeah it is, because i have a feeling some way to support this directly in
<xd1le>guix would be the easiest solution..
<toothbrush0>i've found a package (wakelan) which gives me inspiration to do it manually, but it's a bit ugly indeed.
<xd1le>ah i see. perhaps git blame that and see who added it and ask them if
<xd1le>they've learned of any better way. or just wait for others to answer.
<ArneBab_>how can I ran guix package to create my user profile if there isn’t a user-profile yet (so I have no guix command)?
<ArneBab_>(in a guix-on-other-distro multiuser approach)
<efraim>following the install instructions /usr/local/bin/guix should be a symlink to /root/.guix-profile/bin/guix
<mark_weaver>iyzsong: on the dbus-update branch, emacs now depends on mozjs, which unfortunately doesn't build on non-intel systems. this is a problem.
<iyzsong>mark_weaver: oops, let me see.
<mark_weaver>all of xfce depends on it too.
<mark_weaver>that shows the new failures on 'dbus-update' compared with 'master'.
<mark_weaver>ah, I see. gtk+ now depends on mozjs
<mark_weaver>I guess we need to fix mozjs
<mark_weaver>before this can be merged
<mark_weaver>iyzsong: where was the dependency on mozjs introduced?
<iyzsong>mark_weaver: it's gtk+ -> colord -> polkit -> mozjs
<taylan>ACTION wonders why a policy handling kit would need mozjs
<mark_weaver>maybe it's scriptable in javascript
<iyzsong>should I remove colord from gtk+ ?
<mark_weaver>which of the above dependencies was introduced in the dbus-update branch?
<iyzsong>I add colord to the inputs of gtk+ in commit a572dca8
<mark_weaver>what functionality would be lost by removing colord from gtk+?
<taylan>looks like authorization rule files are written in JS
<mark_weaver>I wonder how hard it would be to fix mozjs on non-intel
<mark_weaver>ACTION looks into it
<iyzsong>honestly, I don't know how to use the colord stuff.
<iyzsong>I don't have any 'color devices'.
<keverets> sells an open hardware & software calibration device that I've used
<mark_weaver>hmm, we have mozjs-17, but there's also mozjs-24.2 now
<mark_weaver>I'll see if updating it helps on mips and arm.
<iyzsong>mark_weaver: polkit can only build with mozjs-17, ArchLinux have both 17 and 24 and link use 17 for polkit.
<mark_weaver>iyzsong: ah, okay. hmm
<mark_weaver>iyzsong: for now, I guess we should remove the gtk+ -> colord dependency. would you like to do that?
<iyzsong>sure :-
<mark_weaver>please leave a "TODO" comment reminding us that we'd like to put it back later.
<mark_weaver>and mention the reason why we can't have it no
<iyzsong>mark_weaver: done, thanks for your patience.
<mark_weaver>iyzsong: np, thanks for all the updates!
<bavier1>would a license clause they requires "unapproved changes [be] distributed as a new program not called <foo>" be non-free?
<keverets>sounds like the mozilla situation
<bavier1>it does
<bavier1>specifically, this is in the README of the "evilwm" window manager
<bavier1>but it has an entry at
<exio4>the code is opensource but the name isn't?
<ArneBab_>exio4: names do not have copyright, they have branding
<ArneBab_>different type of rights
<ArneBab_>after playing a bit with installation and rm -r /gnu /var/guix I get an error about guix-2.0.7 bootstrap missing
<ArneBab_>guix package -i glibc-locales
<ArneBab_>ERROR: bootstrap binary not found "guile-2.0.7.tar.xz" "x86_64-linux"
<ArneBab_>^ as user, works as root
<ArneBab_>and used to work as user
<exio4>ArneBab_: I never said they had? and yes, you can have foss code and trademarked name (simcity is another example)
<ArneBab_>so yes, the code is free software, but likely you have to rename it if you want to fork the project
<ArneBab_>this might even be true if they do not get an explicit trademak
<ArneBab_>(there’s such a thing as trademark by common use)
<ArneBab_>in my ERROR there’s no /var/guix/profiles/per-user/arne/guix-profile
<ArneBab_>and guix package does not create it
<ArneBab_>it did that when I tried it the first time, but now does not
<alezost>ArneBab_: You asked about it in September, and you were told that guile-2.0.7 was not used in guix for a long time, so it's likely that you have an old version of guix which wasn't updated for a long time. I would suggest to remove all signs of previous installations of guix, and to install it again
<ArneBab_>I tried that, but maybe I missed something…
<alezost>yeah, you probably missed something, because it shouldn't happen
<lfam>Does anyone check the guix-devel archives? I'm asking because I sent some patches yesterday while *something* was wrong with the mail server. They are in the archive but they didn't get sent back to me and davexunit said he couldn't access his GNU mail over IMAP.
<davexunit>lfam: for the record, my problem is surely unrelated.
<lfam>I just don't want to send them again if people already read them.
<davexunit>apparently you just can't fetch mail over IMAP
<davexunit>I used to get my mail from the fsf's own mail server, but that access is gone now since I left.
<lfam>What's the difference between (search-paths) and (native-search-paths)? Is (native-search-paths) just for building?
<daviid>davexunit: you left the fsf? i thought it was a fixed job...
<davexunit>daviid: what do you mean "fixed"?
<davexunit>it had a fixed salary, but it wasn't like I had a 2-year contract or something.
<daviid>i thought it was for a long time, permanent, what ever you say in english
<davexunit>it was a permanent position. I wasn't a contractor.
<davexunit>but I didn't enjoy the work, despite liking free software very much, so I left.
<daviid>oh i see
<civodul>lfam: i did receive your GHC patches
<civodul>and toothbrush0 replied
<bavier1>civodul: after 83bde59, it appears one can no longer use 'guix size' on local package builds?
<lfam>civodul: I think you are confusing me with someone else. My patches were for bash.scm and recutils.scm.
<davexunit>lfam: I've received those
<lfam>davexunit: Okay, sorry if I seem like I'm trying to rush everyone. I'm not. I know there are a ton of patches in the queue. I just don't want these to get lost.
<karhunguixi>I want to be able to lock GuixSD/Xfce computer. I've tried "slock" and "xlockmore", but both gave me serious problems. Do any of you have any tips?
<civodul>karhunguixi: you need to add them to 'setuid-programs'
<civodul>in the 'operating-system' declaration, that is
<civodul>i hope to make that automagic in the near future
<karhunguixi>xlockmore worked without root privileges
<karhunguixi>but it crashed somehow the fourth time i tried it
<karhunguixi>are you aware of any other alternatives for locking?
<civodul>i use xlockmore, but i have it setuid
<civodul>i think it's required no?
<karhunguixi>are you using any of the screen savers?
<civodul>just xlockmore
<civodul>not sure if it qualifies as a screen saver ;-)
<karhunguixi>maybe it was the matrix screen saver that crashed on me
<karhunguixi>it's random by default
<karhunguixi>and the first three times i could log back in
<karhunguixi>oh, no, root privileges is not required for xlockmore
<karhunguixi>slock requires it
<efraim>trying to run `guix lint` on this: keeps on failing with: gnu/packages/qt.scm:525:2: warning: source expression failed to match any pattern
<efraim>525 is the second line there
<efraim>no idea what is missing, been staring at that for a while now
<ArneBab_>alezost: found it. I still had a /nix directory lying around
<civodul>efraim: there are two values for the 'arguments' field
<efraim>phases and tests?
<davexunit>interesting RubyGems development:
<davexunit>partly due to a complaint I made about the state of things
<alezost>efraim: yes, it should be (arguments '(#:phases ... #:tests? #f))
<efraim>civodul, alezost: thanks
<alezost>ArneBab_: ouch, something from the past indeed :-)
<ArneBab_>alezost: that’s the price of alpha-testing :)
<efraim> is hiring
<taylan>were there any statements by Purism regarding the Intel problem?
<taylan>assuming good faith, I'm thinking they may be just naive and not malicious :-)
<efraim>last I heard they're "working on it"
<mark_weaver>Purism laptops include the Intel Management Engine, which is a separate processor running a complete proprietary OS that gives remote access to the machine, direct access to the system memory, and out-of-band access to the network, even when the computer is powered off.
<mark_weaver>if you want a machine without such back doors, stick with Libreboot laptops.
<civodul>davexunit: sounds like good news
<davexunit>civodul: yes, but the proposal will not solve anything, so I am responding with the issues.
<civodul>heheh :-)
<civodul>at least you raised awareness
<mark_weaver>the claim that they are "working on it" is false hope. as far as the coreboot experts know, there is no way to avoid running the proprietary ME on those machines, and no hope of replacing it with a free software version because the code needs to be signed with a key owned by Intel.
<taylan>ugh, their FAQ states "Purism provides the source code to ALL the software from the bootloader, kernel, operating system, and software, and does not include any binary blobs in any of them. People can safely verify every single line of code." that's pretty dishonest (although they conveniently go only down to bootloader and kernel so it might be technically true)
<taylan>I wonder if it would be worth to mail them and inquire about the matter. but I'm getting the impression they really left out the nasty bits intentionally now.
<mark_weaver>in my opinion, Purism is being deceptive.
<ArneBab_>GNU Guix in 5 minutes: ← finally have it working again after finding /nix lying around
<ArneBab_>it took me a lot more than the 5 minutes, but with that guide it would only take me 5 minutes to repeat it :)
<civodul>ArneBab_: nice!
<civodul>ArneBab_: the /nix comment at the end sounds weird though
<ArneBab_>it was pretty weird…
<ArneBab_>any chance to get that into a FAQ?
<civodul>Guix hasn't touched /nix at all for a long time already
<ArneBab_>it doesn’t really help the article
<civodul>so i would first need a rational explanation ;-)
<ArneBab_>it seems to use it if it’s there
<davexunit>yeah that doesn't make sense
<ArneBab_>I started trying guix a pretty long time ago :)
<civodul>yeah :-)
<civodul>i mean someone starting from scratch cannot have a problem related to the presence of /nix
<ArneBab_>killed off h)
<civodul>anyway, good that it works now ;-)
<davexunit>civodul: I see that you are giving a talk about guix somewhere in november.
<civodul>davexunit: right, in Rennes, France
<civodul>Christian Grothoff invited me :-)
<davexunit>awesome :)
<mthl>civodul: Yeah Rennes!
<civodul>yup :-)
<davexunit>mthl: is Rennes a cool place or something?
<davexunit>I've never been to France nor do I know its geography
<mthl>It is somewhat my home town
<mthl>I miss it sometime... ;)
<ArneBab_>civodul: yepp :)
<ArneBab_>now building guile-emacs :)
<mthl>davexunit: The “reality” is that there nothing special about this city, I am just used to it
<ArneBab_>civodul: do you by chance have a freenet running so I could give you my /nix folder confidentially to allow for reproduction.
<mthl>civodul: Will it be a talk at Inria Rennes?
<civodul>mthl: actually there'll be two talks: one at Inria, and one in the G/LUG
<civodul>i thought this wasn't official yet
<civodul>but anyway, i'm quite happy
<mthl>civodul: If this is compatible with my schedule I will try to come
<civodul>would be nice!
<civodul>mthl: that'll be on Nov. 9th/10th
<mthl>For now my school schedule tells me that I have no course between the 9th at 11' and thursday morning, so it might be compatible.
<mthl>thursday = 12th november
<civodul>good :-)
<mthl>Alala those students...
<mthl>civodul: Have you ever tried to implement an Automake test driver using SRFI-64 for Guix?
<civodul>mthl: no!
<civodul>is that possible?
<mthl>IIUC yes
<mthl>It is describe in “(automake)API for Custom Test Drivers”
<davexunit>ugh, that rubygems issue is already incredibly frustrating.
<davexunit>I think we'll have to remove rubygems usage entirely, again.
<davexunit>they aren't going to fix anything, and we'll continue to have major issues, and we won't even know that what we have is source code.
<davexunit>my points were completely misunderstood by one person, and flat-out rejected by another.
<davexunit>so angry right now. going afk.
<civodul>bah :-/