IRC channel logs


back to list of logs

*jgrant probably should have used that minimal config to "system init" this partition... he forgot how big his regular system config is.
<davexunit>personally, I like to keep the core system config very small, and save stuff like emacs for my user profile
<jgrant>davexunit: What I'm hoping is that eventually we will get a proper "guix user" module, to do per-user configs like system configs. :^P
<jgrant>I don't really mind it as is (my config), it's just taking a /long/ time for something I fear will not even boot.
<jgrant>Moment of truth. Hopefully I'll brb ... o/
<jgrant>Done & done! :^)
<jgrant>DusXMT: Thank you for the obvious solution, I happened to overlook.
<jgrant>Okay, now to figure out how set my wifi-device up.
<jgrant>Everything seems to be working! :^)
<jgrant>There's a weird issue with ACPI, that keeps on being dumped into my tty -- but sans that, wireless working and I"m in my graphical session.
<jgrant>Maybe see if I can cheat Nix and get stumpwm going through there, in the meantime...
<jgrant>Hm, my "use-package-modules" and similar are "unbound variables".
<davexunit>jgrant: guix pull
<jgrant>davexunit: Well yeah, did that.
<jgrant>I'd still be an oddity, seeing I build from Git too.
<davexunit>oh, well you are running 'guix system reconfigure' or whatever as root, so root needs the new guix.
<jgrant>Again, it is.
<davexunit>then there should be no issue.
<jgrant>Could it be that my os-config is in my /home/jgrant/.guix.d/ ? ... Wouldn't think that could be the case.
<davexunit>no, the location doesn't matter.
<davexunit>check 'guix --version'
<jgrant>0.9 as both root and user.
<jgrant>So weird...
<jgrant>It seems to work as a user, but not as root. They are both pulled to latest though...
<davexunit>they must be different.
*jgrant tries to pull again as root.
<jgrant>Is there a way to easily check if hydra is being tasked heavily?
<jgrant>Brb, going off wifi and onto eth0.
<civodul>Hello Guix!
<jgrant>civodul: o/
*jgrant installed GSD on his main box. :^)
<civodul>starting from 0.8 or master?
<jgrant>civodul: Master.
<civodul>excellent :-)
<civodul>did you encounter any problems?
<civodul>or rather, which problems did you encounter? ;-)
<jgrant>Yeah, actually. It has a weird issue where it's not picking up my patch via root (the use-whatever-modules), but will as a typical user -- when rebuilding my config. ACPI complains about missing a package, ocassionally in my ttys.
<jgrant>Those are the big two.
<jgrant>Might find more, when I play more seriously with it tomorrow.
*jgrant is currently on his old standby system.
<civodul>right, your use-whatever-modules patch is not in the Guix snapshot that's packaged, that's the reason
<civodul>what's the ACPI message?
<jgrant>civodul: Uh, give me a few minutes so I can downstairs to that box and write it down.
<jgrant>"[1453.043621] ACPI Warning \\_SB_.PCIG.PEGP._DSM #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140926/nsarguments-95)" && "[1453.043741] ACPI: \\._SB_.PCJ0.PEG0.PEGP: Failed to evaluate _DSM"
<jgrant>civodul: ^
<jgrant>civodul: Regarding the snapshot, I would get that if I didn't pull the latest ... but should it still not be found if I "guix pull" as root?
<jgrant>civodul: I have school later, so I'm going to attempt to nap for a pfew. o/
<civodul>dunno what these ACPI messages are about
<iyzsong>hi, I have make a meta-package for Xfce (sended to ML). Install it, and write 'exec startxfce4' in your .xsession should work. Comments please :)
<civodul>iyzsong: neat!
<civodul>i had almost given up, because there were issues with the session bus
<civodul>namely, it wouldn't find the .service files for Xfce
<iyzsong>what's the services for and from? I haven't consider it
<civodul>the .service files are for dbus
<civodul>they are what makes 'dbus-launche org.xfce.Xfconf' work
<iyzsong>um, I think XDG_DATA_DIRS should handle it, I have pushed a commit to set it in /etc/profile.
<civodul>oh right
<jcca>Hi, Can anyone explain this error?
<mark_weaver>jcca: blocks tor users. could you use a different paste service? is one optoin
<jcca>one minute
<mark_weaver>jcca: I think we don't support cross-building a system like that. civodul could give a more definitive answer.
<mark_weaver>we support cross-compiling packages with the --target option, but probably not whole systems.
<jcca>so I need build guix on arm directly
<mark_weaver>yes, I believe so
<jcca>ok, thanks I will try it.
<mark_weaver>you'll need a fairly powerful ARM box to do it though.
<mark_weaver>you could use qemu to emulate an ARM box, perhaps.
<jcca>I know it... I'll try to get one A8 arm
<mark_weaver>I haven't tried to build guix on a machine with less than 1 GB of RAM.
<mark_weaver>we really need at least one ARM build slave for
<jcca>so I am compile on emulate ARM, great idea!
<mark_weaver>until we have that, there are no substitutes, and you'll have to bootstrap the entire system from the bootstrap binaries. be warned, it may take days.
<mark_weaver>I've tested it on a Novena, with 4 GB of RAM and a SATA hard disk.
<civodul>jcca: the "-s" option is for native builds, not for cross-compilation
<mark_weaver>civodul: do we support cross-compilation of entire systems (guix system build) ?
<civodul>so it only works if your system is an ARM, or if there's an ARM build machine connected to it (see "offload" in the manual)
<civodul>ah, good question
<mark_weaver>not that I recommend it
<jcca>mark_weaver: I can wait, because I want install Guix System on AllWinner A10
<civodul>'guix system' would need a --target option, which it doesn't have
<jcca>mark_weaver: Thanks a lot.
<civodul>then in theory, it might work
<civodul>but it's definitely untested
<civodul>and yes, there would be other issues to deal with, like the bootloader etc.
<mark_weaver>GNU autotools can't really work properly when cross-compiling, so at best there may be little issues here and there, and for many packages cross-compilation will be more or less broken.
<mark_weaver>jcca: right, that's the other thing: 'guix system' won't do anything sensible on an arm box yet.
<mark_weaver>well, the bootloader and kernel at the main issues, I guess.
<jcca>mark_weaver: One quiestion more. Can I share my /gnu/store. I mean compile some packages for ARM and share
<mark_weaver>GSD is only supported on i686 and x86_64 so far. currently, on mips64el and armhf you are limited to using Guix as a package manager within another distro.
<mark_weaver>jcca: I have a rather large /gnu/store already that I could share, but I don't really know how to do it.
<civodul>jcca: you mean sharing among machines?
<mark_weaver>that may simply be my own ignorance
<mark_weaver>the problem is that the sqlite database has to be in sync with /gnu/store
<civodul>so if you share over NFS, you need to make sure only one machine actually writes to the store
<jcca>compile ARM packages on x86_64-linux and share it ARM machine.
<jcca>go it
<civodul>but you could compile them and then use 'guix archive' to send them to the ARM machine
<civodul>and the ARM machine will need to have Guix installed
<jcca>I'll try it
<jcca>Thanks a lot.
<mark_weaver>doing a native compile within qemu would be more reliable, but slower.
<mark_weaver>s/be more reliable/have better results/
<rekado_>The texi files in doc/ still refer to "the GNU distribution" (and sometimes to "GNU system" but afaics with a generic meaning), which probably should be changed.
<davexunit>rekado_: fix the ones you see and send a patch?
<civodul>except for the node name, for instance
<rekado_>what is the meaning of "GNU Distribution" in the node name?
<civodul>it means the set of packages that come with Guix, plus GSD
<civodul>so strictly speaker, it's broader than GSD
<civodul>and it means "a distribution of/by GNU"
<civodul>if you have a better idea, we can still change it though
<rekado_>apparently, providing Xvfb to the IcedTea tests is not enough; it also needs a wrapper script xvfb-run, which is included in Red Hat and Debian but not upstream.
<rekado_>Since 4 hotspot and 10 langtools tests fail (with 161 and 1445 passing, respectively) anyway, I'll leave off the Xvfb requirement for now and disable the tests.
<civodul>makes sense
<civodul>hmm, do USB hubs require a specific module?
<civodul>i'm trying an install on a non-laptop machine and the initrd seems to lack some modules
<civodul>wtf, anyone knows Aurélien DESBRIÈRES?
<taylanub>ISTR something related to Parabola but not sure
<davexunit>the person that said we were being malicious with our distro name?
<civodul>they insist
<taylanub>I probably think that because there's an aurelien in #parabola, but I don't remember their English being that bad...
<davexunit>no idea.
<davexunit>ah, new posts from them?
<taylanub>apparently it's aurelien on Freenode/#parabola indeed (just asked em)
<taylanub>hmm .. I gotta check my logs for something
<atheia>Yeah, I saw that email and was pretty annoyed, but then I checked the page and it has the Guix logo, wihch underneath says "The GNU System".
<atheia>So I wondered whether Aurelien simply hadn't visited the page before and concluded that that logo is a consequence of the discussions, rather than a relic of before…
<atheia>Could be error ignorance rather than malice, perhaps?
<atheia>But it's a pretty aggressively phrased email either way, which is not great…
*davexunit catches up on reading
<Soft>Does anybody here happen to be knowledgeable about dmd?
<Soft>I was planning on using it for managing my user session and it seems to ready enough for that
<Soft>However, the docs and examples keep referring to make-actions procedure but it is not exported by the service.scm
<civodul>atheia: yeah, the logo...
<civodul>well, we could/should remove that baseline
<civodul>Soft: i use it for my user session
<civodul>to launch stuff like mcron
*davexunit recently learned that mcron is pure guile
<civodul>i don't use make-actions though
<civodul>yeah let's export it
<Soft>Yeah, I was planning using it for emacs-daemon, mpd, redshift and some other stuff
<davexunit>oooh an mpd service :)
<davexunit>been meaning to write one for guix
<davexunit>(along with many other things)
<davexunit>(sorry I've been so inactive lately)
<civodul>oh, didn't know redshift, seems useful
<Soft>well I can just work around the make-actions problem for now
<taylanub>do we have RMS's sanction on having "The GNU System" in the logo? (we might just go on and ignore Aurelien, I'm just siding with the pedantic side when asking this...)
<civodul>i don't think rms specifically mentioned the logo, but perhaps we could remove it anyway
<jxself>Or say that it's okay because Guix itself is still part of the gnu system even if the distro you get from it somehow isn't?
<civodul>i would say it's OK, dunno
<civodul>i think an external observer would find it incredible that we even stay within GNU after all that ;-)
*davexunit snickers
<taylanub>I think RMS tends to have good points. I'm convinced that calling the distro just GNU would have been, in a way, downplaying what GNU is, because it's much more than one OS distribution...
<jxself>It was started to make an OS, you know. :)
<taylanub>yeah, but I guess it became something much larger than that :)
<davexunit>but GSD is the unification of all the parts of GNU into a full system.
<civodul>warning! troll ahead! :-)
<rekado_>I'm in favour of removing "The GNU System" from the logo. Patch to the ML with updated graphics?
<davexunit>sort of like how evolution is the unifying theory of biology.
<taylanub>rekado_: that's surprising; I thought you were one of those pushing hardest for calling GSD just GNU? :P
<taylanub>(am I confusing?)
<rekado_>huh? No, I was annoyed by the discussion on gnu-system-discuss (especially when GSD was deemed a "confusing" abbreviation). I only suggested a different interpretation of the abbreviation. Other than that my participation in the discussion was completely passive.
<taylanub>ah ok, I think I confused you with another
<jxself>"i think an external observer would find it incredible that we even stay within GNU after all that ;-)"
<jxself>Good point.
*jxself ponders available domain names...
<taylanub>hey, at least it's not emacs-devel :P
<civodul>rekado_: yes, i would happily apply the patch!
<civodul>actually you can apply it too
<taylanub>oh, we're removing the "The GNU System" subtitle?
<taylanub>I'm just asking -- no opinion
<taylanub>(just surprised at the quick action)
<rekado_>applied and pushed.
<civodul>thanks, rekado_
<civodul>taylanub: it's not that quick considering how look we've been discussing it...
<rekado_>ouch, just noticed that a last minute change to my icedtea package causes a late build failure. Just needed to comment out another line.
*civodul attempts installation on a Dell Precision T3600
<mark_weaver>good morning guix!
<davexunit>hey mark_weaver
*mark_weaver thinks that we should be clearing /tmp and /run on startup
<taylanub>some systems use ram filesystems for those; not sure if desirable
<mark_weaver>programs put things in there when they don't want to be bothered with handling their own auto-cleanup of temp files.
<civodul>yeah we should do something
<civodul>it seems there's no consensus on which approach to take
<mark_weaver>taylanub: I think that's for historical reasons. long ago it was more efficient to do so. now I think it doesn't matter much efficiency-wise, but using a ramdisk is a major lose when you try to put a lot of stuff in /tmp (as we do)
<mark_weaver>if we don't clean up /tmp, then users will have to do it manually. seems bad to me.
<taylanub>I agree we should clean it up (not sure if there's systems that don't do that at all)
<civodul>we just need a pseudo-service whose 'start' procedure does just that
<mark_weaver>if we want to preserve it after a reboot, then this would be my suggestion: on every boot, clean /tmp-old and move everything from /tmp to /tmp-old
<mark_weaver>(pick your preferred name for /tmp-old)
<ams>civodul: hey
<taylanub>(FYI: <aurelien> taylanub: my tone is friendly, imagine me laughing with a beer in the hand in front of you ...)
<mark_weaver>as it is, after a crash, dbus, nscd and x11 sometimes don't start up because of stale files lying in /run and /tmp
<taylanub>(so I think we're largely just having a language/culture barrier with Aurelien)
<mark_weaver>I have no idea what Aurelien is smoking, but I doubt that many people are taking his over-the-top accusations seriously, so I wouldn't worry about it.
<ams>what is needed to get a nfs client working?
<mark_weaver>it's fairly obvious that he's so biased toward his favored distro that he's trying to shoot the competition. it's sad.
<civodul>hey, ams
<civodul>ams: i think you could use the in-kernel thing, no?
<civodul>"mount -t nfs", etc.
<ams>doesn't work
<civodul>how does it fail?
<ams>wrong fs type ..
<civodul>oh, weird
<ams>mount /mnt
<ams>mount -t nfs /mnt
<ams>all give the same ..
<civodul>i haven't tried but i would expect it to "just work"
<civodul>does some module need to be manually loaded or something?
<ams>normally you need to have portmap and some stuff running i think ..
<ams>but i dunno ..
<ams>all systems i've used it is just a mount command away
<civodul>yeah but this system is so special ;-)
<civodul>i just tried "mount -t nfs foo bar", and i see "RPC: Registered tcp NFSv4.1 backchannel transport module." in dmesg
<civodul>so the thing is being loaded as one would expect
<ams>mm... i get nutting ..
<civodul>do you get something like that in dmesg?
<ams>should be noted that this is a clean install, no packages installed other than base
<ams>civodul: mm... dmesg says it loads ..
<ams>(the laptop is under the table, hard time looking at it ..)
<ams>doing a pull atm ... and such .. getting emacs ..
<ams>can one use xdm for x11?
<civodul>there is "SLiM" instead
<civodul>we could/should add xdm
*civodul looks at "cryptsetup luksFormat" sitting there forever
<civodul>is it supposed to last this long?
<ams>civodul: seems complicated to have added slim ... and not xdm which is part of x11
<ams>but anyway ..
<ams>do you have a mount.nfs?
<ams>maybe something is missing ...
<civodul>i don't have mount.nfs, no
<jxself>cat /proc/sys/kernel/random/entropy_avail may be useful.
<ams>civodul: btw, have a nice time at fosdem, say hi to the crew
<civodul>sure, i think it'll be nice :-)
<civodul>so you're not coming?
<ams>no, sadly not :(
<civodul>jxself: i'm not sure what it's telling me though
<jxself>The number of bits of entropy available.
<jxself>Once the kernel runs out /dev/random blocks until more is available which can make things slow.
<ams>civodul: one of the bad things about not working .. no money coming to the bank account
<jxself>Unless you have enough, in which case that's not the reason it's slow.
<taylanub>I don't know what the topic is but use urandom when you can except seconds after boot maybe, where we should seed it
<jxself>If it is returning less thatn 100-200 that is the reason why.
<taylanub>the cetion "Not everything is perfect" would be of interest to us, in case we don't have that implemented yet
<civodul>jxself: it oscillates between 400 and 600
<civodul>but i mean, it's been running for like 20mn
<civodul>is that supposed to happen?
<taylanub>to my understanding /dev/random can always run out, which is why urandom should be used
<ams>they are equivalent
<jxself>Okay, so a lack of entropy is probably not the reason then.
<mark_weaver>jxself: btw, my X60 running your kernel often freezes for times on the order of 1-2 seconds. I've generally not experienced this on Debian or other systems. I wonder if it's due to your kernel config or just that it's a much newer kernel than I run in Debian systems. any ideas?
<ams>one should use urandom under all circumstances
<mark_weaver>jxself: I notice that you use the deadline schedulers, whereas I seem to recall debian using CFQ. maybe related?
<jxself>taylanub: Although urandom produces lower quality random numbers.
<mark_weaver>has anyone else noticed such freezes?
<jxself>But yeah, doesn't block.
<taylanub>jxself: as explained on that page, that's wrong
<ams>the only diff between random and urandom is that urandom doesn't block -- crypto wise they are equally strong.
<jxself>/dev/random is a "true" random number generator
<jxself>Hahah :)
<jxself>mark_weaver: Possibly. I've not experienced problems myself.
<ams>jxself: it isn't...
<ams>nor is urandom a false RNG .. the two are exactly the same
<taylanub>the only time Linux's urandom device gives lower quality randomness is right after boot and if init scripts haven't seeded it with randomness stored from the previous shutdown (note implications on first ever installation of a system :P)
<ams>taylanub: false.
<taylanub>ams: oh?
<jxself>ams: I'm quoting from that page.
<taylanub>jxself: I guess the "scare quotes" were part of the quote then?
<jxself>taylanub: Yes, it is written that way on the page.
<mark_weaver>my hard drive spins up and down a lot. I wonder if that's the issue.
<mark_weaver>people with SSDs wouldn't notice this issue.
<jxself>I don't have an SSD myself.
<jxself>It would be interesting to know what else is going on at the time.
<Soft>Does anybody have an idea how I could create a service for setting up dbus desktop session, I mean It would probably have to call dbus-launch, capture the environment variables it outputs and then inject them to all the other services that depend on it
<jxself>I don't use Debian though.
<Soft>I was just wondering if anyone had done something like this
<mark_weaver>I guess I should package 'hdparm' so I can adjust those settings, but on other systems the defaults have been more sane.
<pecg>'The Emacs of Distros', this got a smile out of me.
<jxself>It might be interesting to try with a different scheduler I suppose. Then again, Debian also applies lots of other patches that I don't know one of them may make the diffeence.
<mark_weaver>jxself: the CFQ scheduler was written by the same person who wrote the Deadline scheduler, he wrote CFQ a year later, and CFQ seems to be more popular.
<mark_weaver>having said that, I haven't researched the issue
<civodul>pecg: is it positive? :-)
<ams>hmph ...
*jgrant is trying to figure out how to set up GSD on his Linode instance the easiest way possible -- and was thinking he might just emulate what he did yesterday, with bootstraping via Parabola. NixOS has a relatively simple method though, via
<ams>having issues dowloading linux-libre ..
<rekado_>huh, even though I disabled tests with #:tests? #f, the check phase is still run. Is this because I alist-replace'd the check phase?
<ams>how does one do a successfull guix pull?
<mark_weaver>rekado_: quite likely, yes. #:tests? is checked for in the default 'check' phase.
<mark_weaver>#:tests? does not magically inhibit any phase named 'check' :)
<jgrant>ams: "guix pull"? What's your issue?
<rekado_>mark_weaver: oh, too bad. I was hoping for magic.
<pecg>civodul: Of course.
<mark_weaver>rekado_: not all magic is good, heh :)
<mark_weaver>I would argue that this would be bad magic
<pecg>civodul: Emacs is one of the most well engineering programs ever written.
<ams>jgrant: linux libre not being downloaded .. just sits there
<ams>pecg: bollocks
<pecg>You could just anything inside of emacs, it is freedom at its best.
<pecg>ams: ?
<ams>emacs is immensly ill desgined
<pecg>*engineered programs
<ams>it is also immensly badly engineeried
<jgrant>ams: Like, it shows say like "12345 KB" downloaded and just stays there for awhile?
<pecg>ams: Why do you say that?
<ams>jgrant: no, like nothing after starting download of ...
<ams>pecg: because it is the truth?
<jgrant>ams: Can you give an excerpt of the actual message, to illustrate this?
<ams>pecg: we can first start of with the issue that emacs was crippled for microcomputers when it was initially written, the desgin since that day has changed little
<mark_weaver>ams: if you can't explain yourself, how can you expect to be taken seriously?
<pecg>ams: Explain for me, please.
<pecg>mark_weaver: Exactly my point.
<ams>jgrant: starting download of /gnu/store/...-linux-libre ... from
<ams>jgrant: nothing after that
<ams>18:19 /ignore mark_weaver
<jgrant>Emacs is /great/, but also has 30+ years of legacy cruft and it came out before a strandard for CL & Scheme was standardized, right?
<rekado_>ams, pecg: on the issue of "design" in Emacs, see the Emacs paper: Maybe you just disagree on the term.
<jgrant>I could be really wrong on that history.
<jgrant>Emacs is like a decade older than me.
<mark_weaver>I don't know how I will go on living with ams ignoring me.
<pecg>ams: Your point has no argument at all, onyl your vague opinion of saying 'because it is the truth'.
<ams>pecg: you clearly have not looked at what Emacs initiall was capable of, and how it worked.
<jxself>mark_weaver: Yeah, I'm sure it'll be hard but I'm sure you'll manage. :)
<civodul>pecg: indeed, perhaps the title sounds a bit presumptuous
<ams>pecg: you might want to look at Zmacs or any of the Emacses for Lisp Machines, GNU emacs is a poor copy of a wonderful concept, and done badly at that
<mark_weaver>I'm not sure I would call emacs "well engineered" exactly, but it works very well in practice.
<mark_weaver>it's a tremendously successful program
<pecg>mark_weaver: Please don't kill yourself, there is a lot of things to do with your life, whatever you decide is welcome except writting proprietary software, and other kind of slavery
<jxself>How'd we get on this topic anyway? Is today "Bash on emacs day"?
<ams>jxself: it started with the absurd claim that emacs was one of the most well engineered programs ever written :-)
<jxself>Ah. That is probably a matter of protracted discussion for any program.
<jgrant>jxself: My assumption was in-reference to the name of Ludo's FOSDEM talk.
<jgrant>I can't find anything else prior to this direction to Ludo, that may have sparked it.
<ams>alot of design mistakes exist in GNU emacs... worked around haphazardly
<pecg>ams: I guess you could write a better replacement for it. AmsEmacs, maybe?
<ams>pecg: that is a silly way to have a dicussion
<rekado_>rms says in the paper: "The development of EMACS followed a path that most authorities would say is a direct route to disaster." and "While there was no overall goal, each small change had a specific purpose in terms of improving the text editor in general use, and each step had to be individually well designed and reliable."
<pecg>ams: I guess it is, that's because I replied with the 'because it is the truth' argument.
<jgrant>Like the technical design of Emacs or not, it's more so about the general design philosphies rather than the actual implementation, that Guix and other projects like it should adopt. :^P
<ams>alas, all those small steps amount to lots of bad decisions ... like single threads, a quite crappy lisp for over 30 years, and what not
<jgrant>This is getting offtopic, with only a tangential conenction at best though to Guix.
<ams>nod ..
<ams>still not downloading ..
<jgrant>ams: I mean, this is the same device you are using to talk right?
<davexunit>hydra could be under a lot of load
<davexunit>which happens often
<pecg>jgrant: The philosophy oriented decisions of powering users is what makes GNU Emacs great.
<ams>davexunit: it is downloading from
<ams>or trying to ..
<civodul>ams: of course, i couldn't agree more as a schemer ;-), but still, the basic idea of helping people "get involved" is what i'm interested in
<jgrant>ams: I mean, have you checked your ping?
<ams>jgrant: obviously
<ams>jgrant: it downloaded lots of other cruft
<pecg>civodul: I read some where that there are plans to rewrite emacs in guile. That would be awesome.
<ams>pecg: no, there are no such plans, the plan is to make emacs _run_ on guile
<civodul>there's even code
<civodul>but progress is slow
<taylanub>pecg: not rewrite:
<ams>rewriting several millions lines of code is out of the question
<jgrant>ams: So, to understand you -- you are pulling from Guix and it's trying to download the *.tar.gz of Linux-libre?
<ams>jgrant: yup
<mark_weaver>pecg: in guile-emacs, guile provides its own implementation of emacs lisp, in place of the current interpreter in emacs. it's not a rewrite.
<ams>and it is now sitting at the message: starting download of /gnu/store/...-linux-libre... from
<jgrant>ams: Hm, I'm not sure why it would do that in the first place. Have you disable substitutes?
<civodul>sounds like it
<ams>i wouldn't even know how
<mark_weaver>I don't know if this is relevant, but keep in mind that the Boston area, where the FSF and Guix servers are located, is under about 15 inches of snow right now.
<ams>the config is the simple example from the manual ..
<jgrant>ams: Wait, are you using 0.8 or from git master?
<jgrant>ams: Ah, have you --authorize'd hydra?
<davexunit>mark_weaver: yeah, that's possible.
<ams>no, why would i? nothing of that sort was mentioned in the manual ...
<pecg>mark_weaver: It could be an issue.
<ams>i think ..
<jgrant>ams: It's in there, just not obviously.
<jgrant>ams: guix archive --authorize <
<jgrant>That *.pub, should be in the top directory of /guix
<jgrant>well, guix/
*ams crawls under the table ..
<ams>where is that? i don't have a /guix ... or anything of that name in /
<ams>jxself: short network cable :-)
<jgrant>ams: I meant "guix/", as in the directory you were installing from.
<jxself>AH ha.
<jgrant>So, ~/guix or wherever.
<davexunit>you could also run 'find /gnu/store -name'
<jgrant>davexunit: Ah, true.
<ams>ah, found it .. thnkx
<mark_weaver>15 inches == about 40 cm, for those of you who use a sane set of units.
<ams>lets try again ..
<jgrant>Isn't it now enabled by default in Git Master?
<jgrant>Hydra, being it.
<mark_weaver>jgrant: it's enabled by default in GSD, but when you have to do it manually when installing on top of another distro I believe.
<ams>something is happening ..
*ams goes makes coffee.
<jgrant>mark_weaver: Sounds reasonable.
<jgrant>Yeah, tomorrow I'm going to bugger about with getting GSD on my Linode via some means. All I really need is Nginx and Emacs right now, and the former doens't even need a service really for right now.
<ams>no sbcl package :/
<jgrant>ams: Or Clisp.
<ams>gcl is there ..
<ams>which is .. good enough to bootstrap i think
<jgrant>ams: I've asked, people in #lisp were not convienced.
<ams>oh, no .. gcl isn't fully compliant :/
<jgrant>I've been looking into getting Clisp in, but have some issue with libffcall.
<ams>clisp .. then we have sbcl .. then we can rewrite guix in CL!
<ams>world dominiation ..
<jxself>In lisp? Haha.
<jgrant>ams: Also, SBCL itself I thought was dependent on boostraping itself?
<ams>jgrant: well, it can use any sufficiently compliant Cl compiler to bootstrap
<ams>jgrant: it then does the same dance as gcc ...
<jgrant>ams: Okay, I'll take your word for it. I tried building from source on my non-GSD install before (Fedora) and even though I had Clisp, it yapped at me about not having SBCL.
<ams>jgrant: you need to specify the CL implementation binary
<jxself>I'm reminded of the Free Pascal compiler which is itself written in Pascal and so needs an already-working Pascal compiler to get going...
<jgrant>What would be a better way to build SBCL then? Via a bootstrap of itself, or using someo other implementation?
<civodul> is damn slow
<civodul>much slower than, even
<jxself>Is the weather to blame, as mark_weaver suggested?
<ams>civodul: it has been overloaded ..
<jgrant>civodul: Wasn't sure if that was my local machine, but have noticed that earlier when trying to pull the lastest.
<jxself>Winter Storm Juno
<jxself>Blizzard conditions and all that.
<ams>civodul: load tends to spike to 20 on
*jgrant is afraid after the FOSDEM talk, all of Hydra is going to down -- due to interested 3rd parties.
<jgrant>How big is an audience, typically at FOSDEM?
<ams>jgrant: lots. :-)
<jxself>Create a queue for interested parties so that they work on it sequentially.
<ams>jgrant: it is gratis, and the auditoriums tend to fill up full ..
<civodul>jgrant: that room has ~100 seats IIRC
<civodul>then there's also the very big amphitheater
<civodul>with ~1000 seats or so?
<civodul>for later ;-)
<jxself>Where's Stallman's talk going to be? There?
<jxself>The amphitheater?
<ams>jgrant: sh --xc-host='lisp -batch -noinit'
<jxself>This doesn't seem too specific.
<jgrant>I mean, it's very hard to estimate pepole's interest to a point where they will install/try such a thing on their old box -- but I assume that there is currently like what, 50 semi-frequent Guix users overall (again, all conjecture too -- but "feels in the ballpark").
<ams>rms isn't going to be at fosdem
<jxself>But somewhere within the city.
<jxself>And even at Vrije Universiteit Brussel it says.
<ams>yeah .. but he isn't one of the fosdem speakers ..
<ams>not sure what his plan says ..
<jgrant>jxself: Well, RMS rarely has a new talk nowadays (at least from what I've seen) -- so I'd assume it's along the same motif and shouldn't be that shocked.
<civodul>i don't see rms on the schedule at
<jgrant>I was /very/ shocked to see RMS give a Ted X talk though.
<ams>jgrant: didn't you hear? he will be announcing that the FSF has become part of apple
<davexunit>RMS's talk is around the same time as FOSDEM, but is not part of FOSDEM.
<jgrant>Very different from the way he usually tries to sell Free Software; I guess just because it was a less technical crowd he was trying to market to.
<civodul>jxself: the 30th is on Friday, which means before FOSDEM
<civodul>dunno if it's a typo or no
<davexunit>that's correct.
<jgrant>ams: *BSD
<civodul>ah ok
<davexunit>ams: don't leak the big surprise
<jgrant>davexunit: "One more thing."
<davexunit>I expect y'all to keep quiet or Mr. Cook will be mighty upset.
<jgrant>ams: Everything chugging along?
*jgrant has to head to class in a few.
<ams>jgrant: yup .. git pull done ..
<ams>doing a reconfigure so i can get emacs
<ams>why isn't emacs included by default?
<ams>neither zile or nano can indent code, they lack even the most basic paren matching .. it is annoying when you write a config file
<jxself>Wait, didn't you not like emacs?
<ams>no, who said that i didn't like emacs? i only run emacs, and been doign so for 20 odd years
<jxself>Wasn't there an earlier discussion of the design?
<ams>correct ..
<jxself>Seemed like you didn't like it.
<ams>i know emacs in and out, emacs' design is crap :-)
<bavier`>ams has a vested interest in emacs' development ;)
<ams>jxself: i can't use a computer without emacs!
<jxself>The reverse is also true.
<ams>is there some reason why guix pull downloads a tarball instead of doing git pull or equivalent?
<ams>hmph .. bummer .. some hash mismatch for apr-utils ..
<phant0mas>just noticed as well
<phant0mas>I think I srewed something yesterday :P
<ams>fix it .. otherwise i can't install guix!
<phant0mas>sending patch
<phant0mas>but I am sure I added the correct hash yesterday...
<ams>any simple way for me to work around that ..
<ams>also, list-runtime-roots or whatever requires lsof from the console ...
<phant0mas>just change the hash in apr.scm (apr-tools)
<ams>no clue where that is ..
<jgrant>Just saw this, apr-util has the wrong hash.
<jgrant>Did a "guix system reconfigure os-config.scm" and pooped that out.
<ams>phant0mas: i thought it is inadvisable to change things in /gnu/store ..
*jgrant has to head out to class. o/
<phant0mas>jgrant: just checked the tarball I downloaded yestarday
<phant0mas>has the same hash I added
<jgrant>phant0mas: Very weird.
<phant0mas>but today if you download the same file, the hash has changed
<jgrant>Okay, I'll keep my pointer at here in my irc buffer to see where this goes. Need to head out, for real. :^)
<ams>is there no way to force the issue by ignoring the hash check?
<ams>cause right now i can't install anything
<phant0mas>you should change the source and rebuild
<ams>what source
<ams>i don't have any source .. i just have a config.scm
<ams>and did guix pull, guix system reconfigure config.scm
<jgrant>ams: ~/guix/gnu/packages/*.scm
<ams>i have nothing of that sort
<jgrant>Eval that and changes.
<ams>shouldn't you be at class ...
<jgrant>I'm sorry, someone can take over. I do have to head out, or yeah, I will be late.
<ams>there really should be something like, guix package edit emacs or something ...
*ams ponders how to fix things ...
<phant0mas>ams: I added by mistake the wrong hash
<phant0mas>sending patch
<ams>no worries, more interested in how to continue installing emacs ...
<phant0mas>but I don't have commit access so you must wait for someone else to push it
<ams>that seems like a immensly grave fault in how things work ..
<ams>cause now i'm stuck ..
<ams>i can't use the system, let alone install anything
<phant0mas>ams how did you install guix?
<ams>guix 0.8 image
<ams>then guix pull, which failed due to some madness with keys or what not ... edited my config, by adding emacs, then guix system reconfigure on that, and now stuck with the apr-utils thingie
<mark_weaver>phant0mas: what has the wrong hash?
<phant0mas>nothing I added by mistake the tar.gz hash
<phant0mas>It was late..:P
<mark_weaver>phant0mas: it's okay, but what needs to be fixed now?
<phant0mas>just change the hash
<phant0mas>and push
<mark_weaver>of what package?
<phant0mas>I sent a patch
<ams>you people are immensly cryptic ...
*mark_weaver looks
<phant0mas>thanks mark_weaver
<phant0mas>ams wait :P
<ams>if it is this hard for someone not to dumb to install guix, i can't see guix being used by anyone for a very long time ..
<jxself>It is still getting started, you know. :)
<ams>shurg, if a single commit can cause this much havoc, it has ltitle to getting started i think
<mark_weaver>phant0mas: I was confused by your commit summaries, which should have started with "gnu: apr-util: " instead of "gnu: apr: "
<ams>let alone answers like "just use the source" ... when i don't have any source
<mark_weaver>phant0mas, ams: I just pushed the fix.
<mark_weaver>but maybe ams won't see my message :)
<ams>it also means that guix 0.8 is so borked that nobody can use it
<phant0mas>mark_weaver, ams: sorry for the inconvenience.
<mark_weaver>phant0mas: I edited your commit message a bit
<mark_weaver>("apr" -> "apr-util" and "update" -> "correct")
<davexunit>ams: you realize that this is alpha software, right?
<phant0mas>okay :-)
<ams>davexunit: is that somehow an excuse?
<ams>"it is alpha software" is a lame copout.
<mark_weaver>go away
<ams>it shifts the blame on the person trying to use it
<davexunit>it means you should expect rough edges
<ams>davexunit: yes, and "not being able to install it period" is not a rough edge, more like a clif without a bottom
<ams>sorry, these types of excuses are not useful, or productive.
<davexunit>it's not an excuse.
<mark_weaver>wow, did ams really ignore me for saying "if you can't explain yourself, how can you expect to be taken seriously?" ?
<davexunit>"not being able to install it period" is a total lie. many of us here have machines that run on guix successfully.
<davexunit>it *could* be easier, it *should* be easier, but we have a lot of work to do and need *help*
<ams>davexunit: following the instructions one cannot install guix unless resorting to some magic incantations
<mark_weaver>I thought he was joking
<ams>davexunit: that is not a lie
<ams>davexunit: claiming that it is you AGAIN put the blame on the user, that is disrespectul
<mark_weaver>we're all volunteers, and Guix is a gift. if you don't like it, go somewhere else.
<davexunit>I'm not blaming users.
<ams>davexunit: you just did, twice.
<ams>19:46 /ignore davexunit
<ams>it isn't productive to talk to you
<davexunit>oh well.
<mark_weaver>how long before he's ignored all the core devs?
<davexunit>can't win 'em all, can you?
<mark_weaver>sense of entitlement, anyone?
*davexunit sings "if I only had an op..."
<bavier`>o, the blame game...
<ams>there should be a known issues list, the guix archive --authorize is totally non-obvious
<ams>no clue what the talk was about substitutions ..
*mark_weaver has ops, but for now would prefer to just ignore him (but not using /ignore)
<davexunit>heh, that's not a "known issue"
<ams>"just edit the source" is also totally non-obvious answer, maybe something like guix package edit PACKAGE would be a useful adition to make it easy and a bit more sane
<sneek>So noted.
<bavier`>ams: the guix archive --authorize is documented in the manual
<mark_weaver>sneek: forget "just edit the source"
<sneek>Consider it forgotten.
<ams>bavier`: no, it isn't.
<mark_weaver>silly bot
<davexunit>lol sneek
<ams>not in any shape or form for a person installing guix for the first time
<davexunit>sneek: botsnack because for what I interpret as a subtle joke
<bavier`>ams: under the "Substitutes" section.
<ams>bavier`: so it isn't documented, good, we agree.
<davexunit>that was word salad, but you get the idea.
<ams>lets read it as well,
<ams>If you installed Guix from source, make sure you checked the GPG signature of guix-0.8.tar.gz, which contains this public key file. Then, you can run something like this:
<ams>i didn't install guix from source
<mark_weaver>bavier`: you too can become part of the ams /ignore club :)
<ams>why on earth would that apply to me?
<davexunit>btw everyone, new CVE for glibc
<ams>i don't want to substitute anything, i just wanna install emacs
<ams>so no, it isn't documented, claiming that it is is disillusional
*mark_weaver considers using ops on ams.
<bavier`>ams: you don't need to substitute anything, if you're fine with building from source ;)
<davexunit>"IT'S A SOURCE BASED PACKAGE MANAGER" he screams into the void
<ams>i'm not building anything from source
<mark_weaver>it would be one thing if I could actually talk to him. I would much prefer to do that.
<ams>clearly there is some communication error somewhere
<bavier`>under "substitutes" in the manual: "To allow Guix to download substitutes from, you must add its public key to the access control list (ACL) of archive imports, using the guix archive command"
<ams>i installed guix 0.8 on a usb stick, ran the noted commands, and cannot install emacs because of various reasons
<ams>bavier`: yes, and why the fuck should i need to know that to install a package? are you really suggesting that every user has to plough through the whole manual, understand every single sentence to install guix?
<ams>chirst, this is fucking hilarious
*mark_weaver looks up how to silence ams
<davexunit>"because we don't want to opt you into trusting a third party" he said to the trees
<bavier`>ams: I'm not suggesting that. It sounds like you might know what could be added to the documentation to help.
<ams>bavier`: i just did, scroll up, if this --authorize cruft is needed from the start it should either be default, or mentioned in a known issues document or whatever
<ams>the "substitutes" is not documentation of any sort in this regard
<ams>there is more about facebook in the manual than about how to actually use guix
<mark_weaver> /kick ams
<mark_weaver>hi nully!
<davexunit>hey nully
<nully>no comment
<nully>;) mew hope everyone is doing okay
<mark_weaver>that's the first time I've ever done that.
<nully>eh, Ops happens.
<mark_weaver>nully: how are you enjoying the snow?
<mark_weaver>ams: still ignoring me?
<ams>seems that some guix maintainers are also unable to behave
<ams>go figure
<mark_weaver>I can tolerate dissent, but I won't tolerate you /ignore'ing us one by one while you continue to complain loudly about bugs without us even being able to respond to you.
<ams>system installation to system configuration, nothing about --archive cruft
<mark_weaver>ams: can you see my messages, or not?
<mark_weaver>(lack of response will be interpreted as "no")
<nully>snowed in
<ams>nully: in NYC?
<nully>FSF HQ
<ams>nully: bummer ..
<nully>lol its not too bad
<jxself>ams: You may wish to uningore mark_weaver...
<nully>stuck at home isnt *aways* terrible
<ams>jxself: not really
<davexunit>kick + ban
<jxself>ams: Okay, at least you had fair warning. :)
<ams>nully: eggtoddy, and some hacking time =)
<mark_weaver>that may be the next step, but I'd really prefer not to
<ams>jxself: warning for what?
<nully>ams: pretty much
<mark_weaver>nully: if you're curious to see the context that led to me kicking ams, see
<jxself>ams: I'd rather not become a go-between.
<mark_weaver>and then he proceeded to /ignore davexunit
<ams>anyway .. back to hacking lisp stuff .. guix is spitting out output, i suppose that is good ..
<mhw`>ams: if you do not unignore me and davexunit, I am inclined to ban you from this channel.
<nully>i didnt think
<nully>there was a copy of librelinux on
<mhw`>amd: this will be your last warning
<jxself>nully: Yeah, because lxo likes to delete old versions from from the site due to disk space constraints.
<jxself>And it creates challenges for guix as I recall.
<nully>i thought we had the space
<jxself>I don't know. lxo probably knows more about that than I.
<ams>nully: we don't .. even ran out of space recently if i remeber
<ams>ah, no .. frontend for savannah ..
<nully>ya space there is tight right now
<nully>we can probably extend that volume, no biggie
<rekado>ams: you do not *need* to use substitutes, but you can enable them. So you don't have to "plough through the whole manual, understand every single sentence to install guix".
<jxself>Although not compiling everything from source is probably faster. ;)
<ams>rekado: sighs, look .. following the instructions, from installing system to system configuration, there is nothing about substitutes, zilch, zero, nil and null. i don't even have a clue what they are after having read the chapter on them, but that is a different topic. the point is that the manual is lacking severly in how to install guix, how to even install a single package without ripping your hair out, it is
<ams> even to the point factually incorrect
<ams>nully: 23rd jan, karl reported it
<rekado>jxself: depends on your network connection...
<ams>nully: you a fsf sysadmin?
<jxself>And processor speed and such.
<nully>ams: Yes.
<jxself>She is *THE* sysadmin. :)
<nully>c'est moi
<jxself>NOt "A" :)
<nully>there is another one now
<jxself>They can be "a" sysadmin :)
<nully>well thanks then
<ams>nully: you on savannah-hackers-private?
<ams>i know you peeps don't get paid to work on savannah .. but might be useful to be on that list at least
<rekado>ams: well, yes, because you don't actually need substitutes to install the system (it'll just be a source install then). They are nice to have, though, so they are prominently featured in the manual.
<rekado>ams: doing package management also has its own section in the manual. It doesn't belong in the System Installation section.
<nully>ams: i read the archive
<nully>i should probaby just subscribe to it
<ams>rekado: clearly you do, since i couldn't install guix without doing that
<ams>nully: you should i think ...
<ams>just to keep tabs if anything
<jxself>Sometimes it works better without them though because sometimes Hydra has problems...
<ams>nully: read anything from karl .. :-)
<rekado>Hydra = the build farm
<nully>ams: i know, i work with karl a lot
<rekado>ams: GSD without substitutes is a source distribution.
<nully>i'm sure he put in a request, we are backed up on requests.
<jxself>I met him once for lunch when he was in Seattle. He seems to be a nice guy.
<ams>rekado: sorry, i don't care. "i want to install emacs" is all i care about, how that is done is irrelevant
*davexunit facepalms
<ams>according to the manual, it should be just adding a line in the config, doing reconfigure .. but that does not work.
<ams>i've explained this now four times, and will give up on it, seeing that nobody is really interested in improving the situation
<jxself>Yes, we know Guix is not ready for primetime right now. Perhaps it's not a good fit for you at the moment.
<serhart>ams, maybe pre-released software isn't for you
<ams>oh lovley, more random excuses ..
<ams>right now i wish i never let guix use dmd
<ams>that is about my level of anger right now
<rekado>ams: what is the current problem you see?
<rekado>(i.e. what did you do, what did you expect to happen, what happened instead?)
<ams>sgihs, i already explained it to you
<ams>if there was something unclear, please specify where i was unclear instead of asking me to explain it from the start
<davexunit>(maybe if you stopped ignoring the devs...)
<jxself>Yes. Some have tried to reply but since they were /ignored...
<rekado>ams: Since I don't know what messages you have seen and which you haven't I don't think I should continue.
<rekado>(how's that for an excuse...? :))
<ams>rekado: a fair enough excuse :-)
<rekado>ams: I really think you should stop ignoring mark_weaver and davexunit (I consider ignoring them to be very rude); mark_weaver has already applied the patch by phant0mas, so pulling should be okay.
<rekado>ams: on the subject of substitutes again: when enabled you can download pre-built packages instead of having guix compile them for you. They are enabled by default in GNU GSD from 0.8.1 onwards.
<ams>i consider their behaviour to have been far ruder than putting them on ignore, i might do it tomorrow. maybe. now, some knitting ...
<svetlana>ouch i am sorry to hear that, i hope they start being less evil-looking with time :p
*phant0mas laughing with what I am reading
<svetlana>don't laugh, it is a challenging situation for some ;)
<ams>is there some way to download all sources? using this laptop mostly off-line ..
<svetlana>afaik the installer needs internet at this time but once it's done you can use the distro offline. for a specific package there should also be a way to get sources but i do not know it yet.
<rekado>I'm not sure I understand the question. All sources of what? Guix automatically downloads either sources (to build everything) or tarballs of binary substitutes (if enabled).
<jxself>I suspect all source for every defined package?
<svetlana>i think the question is mainly about offline installer.
<ams>i wish to download all source code tarballs for every defined package
<ams>so i don't have to use a ethernet cable ..
<davexunit>there was a discussion on the list some time ago about pre-fetching source code
<jxself>Tired of sitting under your desk, ams? :)
<bavier`>rekado: someone else, I think a_e, looked at this before; to download all sources needed to build a particular package, including dependencies.
<davexunit>I don't know the status, but someone that isn't ignored could look into it
<ams>jxself: a bit .. yes :-)
<bavier`>as far as I know, it hasn't progressed beyond the idea.
<jxself>Yes. Too bad ams has davexunit ignored and can't see the reply to their question.
<svetlana>probably set up a mirror. should be doable for a repo. and point guix to a loca repo.
<ams>svetlana: no way to just download all source to the store, or whatever happens during "guix build"?
<jxself>davexunit answered your question already, ams. :)
<jxself>Issue solved.
<ams>jxself: yes, and he is on ignore, and you are being snarky.
<svetlana>i am not a good person to ask, i do not have guix yet. i am just making a guess that a mirror could work.
<jxself>I'm just sayin' is all.
<ams>jxself: maybe instead of being snarky, you could tell me what he suggested
<ams>seems far more useful way to spend your time
<bavier`>ams: not an implemented feature, yet.
<svetlana>davexunit just said someone could look into it, and bavier` said he only has an idea but no progress about it yet.
*rekado reconsiders: it's not only rude but ineffective and childish to ignore. Proceeds to ignore, including the irony.
<jxself>Nah, I don't need to be a go-between. Just mentioning that you may want not to ignore those people.
<svetlana>having an idea how to do it is a good start already.
<jxself>svetlana: There's no need to help in these cases and relay messages.
<ams>jxself: and according to svetlana he did not suggest anything of use, so there we go.. more snarkyness from you
<jxself>svetlana: If ams wants to /ignore people, he can also go without the answers that those people provide.
<svetlana>let's drop these people things. sorry.
<nully>hey svetlana
<ams>there, solved ... a bit of awk ... maybe jxself should spend more time coding and less time being snarky
<svetlana>share the awk? i would be a bit curious what you did there.
<svetlana>it is one of the things i did not learn to use properly during the years.
<ams>svetlana: tomorrow, laptop under the desk .. a pain in the as to do anthing with it atm ...
<svetlana>okay. :)
<davexunit>don't use awk, use guile...
<jxself>Ideally, but he can't see you. :)
<ams>svetlana: or rather, we shall see .. it is just iterating over "guix package -A", and doing a guix build -S on each thing .. i think that should work ..
<ams>if i understand the manual correctly ..
<bavier`>ams: just make sure you have a snack ready for downloading texlive.
<davexunit>(map origin->derivation (filter-map package-source (fold-packages cons '())))
<davexunit>then you just have to build the drvs, but I've gotta remember how to use the store monad.
<jxself>And then ta da. :)
<jxself>And our fearless leader returns. Ahoy there sir.
<civodul>fearless leader... :-)
<bavier`>ams: your method may not work. I don't think it'll download source that's declared as a package input. E.g. texlive has the texlive-texmf-src input, which will not be fetched with `guix build -S ...`
<svetlana>sorry, i was adding noise. i will return later.
<davexunit>civodul: have you seen the new glibc CVE?
<civodul>davexunit: my understanding is that 2.20 is not affected
<davexunit>oh okay
<davexunit>cool :)
<civodul>"In particular, we discovered that it was fixed on May 21, 2013 (between the releases of glibc-2.17 and glibc-2.18)."
<davexunit>I hadn't given it a thorough read
<davexunit>just saw it and thought I should spread the word
<civodul>indeed, i tried GHOST.c from the email above and it says we're fine
<bavier`>related to the source-prefetching idea: would it make sense to have the package-source procedure return all origins for a package, i.e. including any that might be in the package's inputs?
<bavier`>or, for that matter, allow multiple origins in a package's source field.
<civodul>i think there can be only one "source"
<civodul>i'm not sure what it would mean to have multiple different sources
<civodul>but yeah, the hypothetical 'guix prefetch' should fetch all the origins
<bavier`>i'm thinking of texlive e.g.
<davexunit>civodul: I tried to write a quick and dirty "download all the sources" script, but I got hung up on monads again.
<davexunit>(map origin->derivation (filter-map package-source (fold-packages cons '())))
<davexunit>this will make derivations of all the sources as a list of monadic values
<bavier`>davexunit: we're racing on an implementation it seems ;0
<davexunit>bavier`: I will yield to you :)
*civodul needs 'guix prefetch' before getting on the train this Friday, hint hint ;-)
<bavier`>I was thinking of extending the semantics of `guix build -S`
<bavier`>so that it would take an optional argument
<davexunit>'guix build -S *' :P
<bavier`>one of "package", "all", or "transitive"
<davexunit>do origins get substituted?
<davexunit>I'm guessing "yes"
<bavier`>davexunit: yes, if they're patched.
<davexunit>oh only then?
<bavier`>not sure, just from my observations
<davexunit>my assumption would be that since it's in the store, it's substitutable, but I know that we can mark things as not substitutable.
<civodul>rekado: BTW, thanks for dealing with our "fellow hackers" on g-s-d
<ams>i've been pondering of closing that list
<jgrant>Wow, that was an insane and inane backlog.
<jgrant>ams: It's important to specify that this is alpha software, because things may not work out of no-where. I installed GSD on my main box yesterday, and had no issue with the bootstrap, then pulling that fell after.
<jgrant>Someone made a patch in the time between then and now that had the wrong hash, and made pull fail. It was identifed, patched, and is soon to be fixed.
<ams>please stop repeating the same excuses
<jgrant>It's frustrating, but getting into conversations (bickering matches) like these are harmful for everyone.
<jgrant>ams: What excuse? It's being fixed.
<ams>jgrant: the hash issue was not the main problem
<jgrant>Well, it is fixed. It needs to be accepted to master, if it not already (haven't checked).
<ams>but it also shows a underlying problem with how guix works
<ams>a commit can make it outright impossible for someone to perform any kind of work
<civodul>ams: please assume good faith and be courteous, thank you
<jgrant>ams: Not at all, it's alpha software. Once we hit stable, we can easily branch a stable directly that has stricter packing specifications/reviews.
<jxself>civodul: You should see the backlock.
<ams>civodul: and you please assume good faith, i've been accused as a liar
<civodul>ams: certainly not, because nobody behaves this way on this channel
<jgrant>I don't see the point of having an "Stable" branch as is, right now since it *is* Alpha Software and all assumed users are to have a certain level of technical skill to be able to debug such trivialites.
<ams>civodul: uhm, yeah i have.
<jgrant>right now*
<ams>civodul: so maybe YOU should assume good faith, i have been more than courtes
<civodul>courtes is me
<jgrant>civodul: It was fairly hostile on both ends, reading the backlog. Someone was in more of the wrong certainly (ams) but, the way it could have been handeled could have been more difused.
<ams>jgrant: maybe not a stable branch, that seems a bit heavy, stable tag?
<jxself>Perhaps once guix gets to the point where it is stable. Seems not there yet. :)
<davexunit>call me biased, but I saw only one person who was hostile.
<jgrant>ams: My point is, there's no design flaw -- it's easily fixed, just probably not worth the effort to maintain, until such a thing hit "stable".
<jxself>+1 to that, davexunit. :)
<jgrant>davexunit: Maybe hostile has a bit too strong of a conitation tied to it; I'll retract that and say "heated".
<ams>jgrant: i think it is a design flaw, sure it can be solved, but it is almost impossible to continue an installation as it is now if the master repo is not "ok"
<ams>jgrant: heck, git pull DATE would work possibly
<jgrant>Also, I need to figure out why spellcheck doesn't work on my GSD install.
<davexunit>jgrant: sure, I can accept that. :)
<jxself>ams: Imagine Debian unstable. It breaks sometimes. People don't necessarily consider that a design flaw.
<civodul>jgrant: there's a trick hidden in aspell.scm :-)
*jgrant just got back from 2 hours of math and 30 minutes standing in line at a bookstore, he's probably not too tactful in his language right now.
<jgrant>civodul: Like in comments?
<ams>jxself: debian as such is a design flaw
<jxself>It's essentially what you're using.
<jgrant>ams: I want to be clear, it's not a design flaw -- it's a lack of implementation to resolve an issue due to not enough desire by said community to maintain a solution as of current. A design flaw denotes there is a fundemental issue with the structural and/or actual design in which the program was made. I don't want to argue this, I can't see a future where GSD won't get a Stable branch -- it's just not something as Alpha software, that
<jgrant>people care about en massse.
<davexunit>tl;dr - we're iterating a lot right now. things change and break. :)
<ams>jgrant: currrently there is a fundamental issue with it, so yes, it is a design flaw, however easily fixesd
<davexunit>now we're in pedantry territory. best to drop it.
<jgrant>ams: It's important to be civil in these conversations when possile and it's hard to stay as such when someone is making assertions that is abusing the common speak as people are used to hearing. This could have gone a whole hell of a lot better, of you phrased this better and more clear. I have this issue often, I was called out for it the other day -- live and learn.
<jgrant>It's also a hard skill to build up, obviously, too.
<ams>jgrant: i phrased things quite clearly, maybe people here should be more civil.
<jgrant>But again, yeah, might as well move past it.
<ams>jgrant: and your accusatory tone is not welcome
<civodul>ams: again, your own tone is not welcome
<jgrant>ams: You included. This was recpricole.
<civodul>don't keep repeating the same mistakes, please
<ams>i dropped the issue already multiple times
<ams>jgrant has been pulling it up several times now
<ams>and continues to attack
<jgrant>ams: I'm not attacking at all; I said I was shocked by the backlog I was skimming. And that I think Alpha is a fair label to not assume perfection. But again, I'm done -- if you want to feel attacked, it's within your rights to do so.
*jgrant goes to checkout aspell.scm
<ams>sounds like a far more useful thing to do ..
<jgrant>Oh, very cool! We have xinit now.
<jgrant>Does this mean that we can boot a graphical session from a tty, or is there more groundwork that needs to be done?
<jgrant>ams: Fyi, just checked the cgit instance (don't know if you know) -- the hash appears to be fixed. So if you pull, it should work.
<jgrant>I need to look into writing a dmd module for wpa_supplicant.
<ams>jgrant: box is downloading all tarballs currently .. will look tomorrow
<jgrant>ams: Tarballs, or subsitutes?
<ams>source tarballs, wahtever you call 'em
<jgrant>ams: Did you not enable hydra?
<ams>no, didn't see anything about needing to do that in the manual
<jxself>ams wanted the source of every defined package.
<ams>yes, doesn't make much sense to me
<jgrant>What doesn't?
<ams>the whole chapter
<ams>it assumes to much pre-knowledge about guix
<jxself>People with such pre-knowledge are probably the ideal Guix users at this time.
<jgrant>Authorizing a *.pub?
<jgrant>jxself: Yeah, hence the alpha title.
<ams>in either case, i need sources or substitues or whatever they are called since i'm working offline on the laptop for the ntext two weeks
<jgrant>ams: "Tarballs" is the plain source, "Subsitutes" are precompiled binaries.
<ams>jgrant: the manual seems to disagree with you
<ams>jgrant: is it wrong?
<jgrant>It's not just binaries, but it's mostly binaries. It's a package resulting from anything of a derivation build.
<ams>ok, so what the manual says
<jgrant>The manual is a solid authority, I am not.
<jgrant>I know just enough to get me in trouble, ask mark_weaver; And I been working on appending clarifiers to state that I'll give one advice but I am /not/ an authority on the matter(s).
<jgrant>Anyways; I'm going to grab some late-lunch-early-dinner, relax for about an hour, then try to get some more stuff set up on my GSD install.
<jgrant>Peace for now, people. o/
<civodul>rekado: i updated the web page, and the "offending baseline" vanished from
<civodul>let's see what the next step is ;-)
<jxself>Ah, sad. :(
<mark_weaver>civodul: what vanished?
<mark_weaver>nevermind, now I know
*civodul -> zZz
<civodul>good night/day!
<davexunit>later civodul
<jgrant`>Well, I pulled the latest and was able to build a new configuration for my system ... but, said thing fails to boot now.
<jgrant`>I'm not sure what to even do to debug this, the only thing I see before the Guile prompt spew, is that there is a mysterious missing symlink.
<mark_weaver>what missing symlink?
<mark_weaver>details would be helpful
*jgrant` isn't sure, probably need to reboot this box and snap a picture. My question is, is there a way I can somehow write this bootup phase to a file?
<mark_weaver>no, it's probably before the root partition is even mounted
<jgrant`>Well, reboot it is. I'll snap a pic and see what I can gather from this little excerpt.
<jgrant`>Well, maybe this is more helpful than I think ... but all it says (right before it tries to open a guile prompt), is "ERROR: In procedure symlink: " followed by "ERROR: In procedure symlink: File exists".
<mark_weaver>any sign of a filename?
<mark_weaver>or a backtrace?
<jgrant`>File name of what, where the syslink supposed to point?
<mark_weaver>any filename that might be associated with that symlink attempt would be helpful
<jgrant`>Also, yeah -- there are a bunch of backtraces. You know, it might be because of that usb module that was just added. Looking at this screenshot, all backtraces are related to Usb something or another...
<mark_weaver>sounds quite plausible
<jgrant`>I pulled the latest right before I built this new config, so.
<mark_weaver>do you use "guix pull" or are you building out of a git repo ("git pull") ?
<mark_weaver>if using git, you could just revert that commit in your local repo until we fix it upstream.
<jgrant`>Guix pull.
<mark_weaver>guix pull is rather inflexible I'm afraid
*mark_weaver has never used "guix pull", not even once :)
<jgrant`>It's via initd, so could I define dmd not to load this in my config?
<mark_weaver>no, this is before dmd is even run
<mark_weaver>this is in the initrd
<jgrant`>Ah, well ... can I clone into guix, remove the changes, eval the changes as root but under the ./pre-inst-env?
<jgrant`>I mean, I want to know if this is just me -- but there isn't a huge install ase of native installs yet, obviously.
<mark_weaver>well, I use GSD, but I haven't updated my system since that commit was added.
<mark_weaver>and I don't have time to do it right now
*jgrant` just installed on his main box yesterday and is planning today and tommorow, to get a majority of his stack on here.
<jgrant`>So, I'll likely reconfig a few times.
*jgrant` will brbish.