<civodul>gzochi is in, but Sly isn't, muaaahaha <codemac>yo - trying to package cscope -- running into a problem with -lncurses not being found? <codemac>Has anyone run into that before with gnu-build-system + ncurses? I set it as an `input`.. should it be a `native-input` as well? <codemac>hm, that didn't help (I didn't think it would). Gonna try some make flags as well <codemac>the guix package for ncurses doesn't symlink curses -> ncurses <codemac>is ncurses supposed to symlink libcurses.so -> libncurses.so? Archlinux does this <codemac>hm.. it looks like ncurses is *supposed* to have those links... <mark_weaver>"supposed to"? says who? apparently the ncurses developers didn't think so, or else they'd have make the symlink when we run "make install" <codemac>mark_weaver: ok.. didn't mean to offend. My arch system has it and it seemed like a few pieces of software expect it to be there. We go to similar paints for ncursesw.so, didn't see why curses.so would be so different. <mark_weaver>ah, sorry, I guess my comment above conveyed a different tone than I intended. I wasn't offended, just asking for clarification. <codemac>well yeah, so we do the symlink hack for ncursesw.so, so wondering if I should patch cscope's build or edit the ncurses package definition for libcurses.so <codemac>And it looked like we have symlinks in there for libncursesw <codemac>though it also checks for libcurses.so (which ironically doesn't exist because ncurses doesn't package itself that ways) <mark_weaver>so far, I'm not sure that we have any other packages that fail to find ncurses. I think in this case we should help cscope to find it rather than modify ncurses. <mark_weaver>the other problem with modifying ncurses is that it will probably entail rebuilding most of our packages, which I'd rather avoid :) <mark_weaver>we normally try to avoid modifying upstream packages unless there is a compelling reason, and in this case the number of packages that fail to find ncurses seems to be very small. <mark_weaver>what do you think? if you disagree, feel free to raise the issue on the ML <codemac>probably. If there are tons that need this we can revisit, as modifying cscope is the conservative step. <codemac>oh not a biggie to me, just trying to get as much of the "guix way" under my fingers :) I'm still a systemd nerd but maybe you guys will win me over in enough time with this "hack the init system" excellence :) <mark_weaver>heh, yeah, I admit that dmd is inferior to systemd at the moment, but I have confidence that in the long run it will pay off to have an init system based on scheme. <LordShadowWing>How Long should ~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild take fo finish ***anthk_ is now known as anthk
<codemac>mark_weaver: !! --with-ncurses=/gnu/store/...-ncruses-6.0 == WIN on cscope! just had to poke in configure a bit better :) <codemac>mark_weaver: I already posted the patch to guix-devel :) Yeah, was glad to see it was a simple option and i didn't have to over engineer something so silly. <codemac>yeah, loving the heck out of gnu-build-system <codemac>I still only have a really ugly package for go <rekado>neither M-x guix nor M-x guix-all-available-packages work for me. <rekado>I'm using Emacs 24.5.1 on GuixSD. <rekado>All I see is a message that the Guix REPL is being started, but it never succeeds. <rekado>It blocks with "Starting Guix REPL..." <rekado>hmm, maybe I just need to run "make" again to speed this up. <jogo_>Hey, I just installed GuixSD into a virtual machine, setup and booting seem to work fine, but I am not able to find out how to start x / xfce. I found some slim service, but do not know where/how I can add that to startup. I am using the desktop config as default. <jogo_>Can maybe anybody please point me in the right direction? <iyzsong>jogo_: make sure xfce is in the 'packages' field, and enable slim-service (contained by %desktop-services), you should see a 'Xfce session' entry when login using SLiM. <iyzsong>jogo_: the default desktop config template doesn't start Xfce for you? <jogo_>It justs boots me into a tty. <jogo_>xfce is in the packages, and (services %desktop-services) supposedly (?) enables slim-service. <iyzsong>yes, but something goes wrong. does 'deco status dmd' (run as rooT) mention xorg-server? <iyzsong>jogo_: you can restart it by 'deco restart xorg-server', and look at /var/log/Xorg.0.log and /var/log/slim.log. <jogo_>deco restart xorg-server gives that on the console: file /var/run/slim.auth does not exist <jogo_>error while loading shared libraries .../libpciaccess.sp.0: file too short <iyzsong>jogo_: oops, maybe you have download a broken libpciaccess, I think it's what 'Xorg' report. honstly, I don't know how to repair this, but you can try something 'guix gc --verify'. <iyzsong>jogo_: how's the '/gnu/store/*libpciaccess*/lib/libpciaccess.so.0' file look? If it's broken, could you send a report email to 'bugs-guix@gnu.org' <iyzsong>jogo_: ah, it's 'bug-guix@gnu.org'. sorry for me not be helpful. <civodul>rekado: did you/your users upgrade to the libc-2.22 Guix? <mark_weaver>civodul: btw, the workaround I suggested on the ML for running Guix on top of another system is to leave LOCPATH unset and make /run/current-system/locale a symlink to glibc-2.22 locales. <mark_weaver>obviously not ideal, but maybe the best we can do before we recompile everything again. <rekado>I updated only my private machine. <davexunit>rekado: meh, disable tests if that's the case. <davexunit>oops, accidentally published blog posts when I added a page for Shroud on my website. <mark_weaver>ACTION struggles with the new magit for the first time. <davexunit>I've mostly been able to do everything that I'm used to doing <mark_weaver>M-x magit-log asks for more input, and the key binding for interactive rebase seems to have changed from E to r e <mark_weaver>(and those are pretty much the only things I use magit for lately) <mark_weaver>(I had mostly switched to emacs' built-in vc stuff, except for interactive rebase) <davexunit>magit-blame-mode is another thing I use a lot. <mthl>*magit-blame with the new magit ;) <mark_weaver>I use C-x v g (vc-annotate). not sure off-hand how magit-blame differs <mark_weaver>I switched to using vc mode partly because its vastly faster than magit (the old magit, at least) for many operations, and also because the mode that magit uses for displaying diffs is missing some standard keys that I prefer in standard emacs diff mode, most notably C-c C-c to go to the source code corresponding to a given hunk. <mark_weaver>although maybe magit's diff mode has similar features under different keybindings; I confess I didn't bother looking because it was easier to just use vc mode. <mark_weaver>also, on the occasions that I need to use a different version control system, it's nice to be able to use the same commands I'm familiar with. <mark_weaver>(e.g. when grovelling through a project's repo to extract patches for security updates) <bavier>mark_weaver: and we all appreciate your skill at doing that :) <mark_weaver>I'd love it if someone else wanted to help with security updates from time to time :) <mark_weaver>speaking of security updates, I wonder how much longer we should wait for GNU IceCat 38.x. it's terrible, but I'm considering proposing that we should remove GNU IceCat 31.x from Guix, since it contains critical security flaws that are beyond my skills to backport fixes for. <mark_weaver>I've raised the issue several times on the bug-gnuzilla list, starting the day after the problem arose (August 12) <bavier>is that when you suggested others consider using epiphany for a time? <mark_weaver>I don't remember how long I waited before making that suggestion <civodul>mark_weaver: yes, that's a good idea <civodul>though i'll think we'll have to go for GUIX_LOCPATH <civodul>mark_weaver: so what would you suggest to do if we remove it? <mark_weaver>civodul: I like the GUIX_LOCPATH idea, but since we'll be introducing a new variable anyway, I think it should work like this: the locales are in $GUIX_LOCPATH/<LIBC_VERSION>/ <mark_weaver>and that way, we can avoid the problems when switching libc versions <mark_weaver>although I guess more is needed, to ensure that all of the <LIBC_VERSION> subdirectories are populated. <civodul>mark_weaver: i was thinking of versioning /run/current-system/locale/ <civodul>so we would have /run/current-system/locale/2.22 <mark_weaver>civodul: regarding IceCat, I don't know. it's just a terrible situation. <civodul>but i'm not sure we need that for GUIX_LOCPATH <civodul>since GUIX_LOCPATH is specific to Guix's libc anyway <mark_weaver>civodul: well, there's still a problem when you have a Guix system where profiles contain a mixture of packages linked to Libc 2.21 and 2.22 <mark_weaver>and that will be the case on a multiuser system when not all the users have updated their profiles yet. <civodul>upstream libc should probably be using lib/locale/X.Y by default, too <davexunit>mark_weaver: seems like removing icecat is the only reasonable option we have to prevent users from installing software that we *know* is vulnerable. <civodul>it seems the mailing list has problems <davexunit>and mail that I expect was sent by others hasn't shown up either <davexunit>like the response to the gzochi patch saying that it's been merged. <mark_weaver>civodul: the last time this happened, nully said it was because the FSF mail servers were receiving a huge influx of spam and so things got backed up <davexunit>they have a serious spam problem. I wish they dedicated more time to dealing with it. <mark_weaver>iirc, everything eventually got through but there were long delays (more than a day) <mark_weaver>civodul: I don't know precisely, but I guess that the relevant systems were overloaded <mark_weaver>davexunit: spam is a very hard problem, and the usual solutions have serious downsides such as allowing spammers to manipulate the spam system to effectively censor legitimate mail. <mark_weaver>I'm actually amazed at how well the FSF spam filtering works. <davexunit>I get a lot of spam to my gnu.org address, though. <civodul>yeah but it's true that spam on mailing list is incredibly well filtered out <davexunit>civodul: yes, true. I should look on the bright side. :) <civodul>i sent a message with subject "Buck collection" <civodul>i thought that that's the reason why it got filtered out <paroneayea>gave a test run of my talk last night and it went over really well. <davexunit>paroneayea: great! how long until the "real deal"? <paroneayea>davexunit: happens at the red hat office tonight <paroneayea>davexunit: I gave a demo run to my brother last night, he thought I explained all the concepts really clearly, and said he was "sold" on Guix <paroneayea>looks like there'll be about 30 people there, which isn't huge, but is pretty cool because that's the maxiumum <mark_weaver>I think in practice the word "hear" has become generalized to any kind of communication <paroneayea>one of my friends got waitlisted (but got in thankfully) <davexunit>paroneayea: that's a pretty nice litle crowd. <davexunit>especially if they are actively interested in Guix <paroneayea>well it's at the red hat offices, I'm sure people there will have opinions on packaging / distros :) <paroneayea>hopefully I don't get burned at the stake for my heresy <davexunit>invoke davexunit's tenth rule if things get tough and they bring up project atomic. <paroneayea>"oh yeah and we don't use systemd and don't conform to the FSD" <paroneayea>later on there's also a word of warning that we'd better not get too smug about it though :) <paroneayea>every deployment system eventually includes an incomplete and buggy implementation of guix <paroneayea>well, I'll modify to be based on the proper greenspun version :) <davexunit>mark_weaver: all the new package management/deployment tools seem to contain an ad hoc, informally-specified, bug-ridden, slow implementation of half of GNU Guix. <davexunit>I originally said this in response to my work with Chef, a config management tool written in Ruby <davexunit>in which I was manually attempting to code assurances that Guix has automatically by the structure of the system. <davexunit>in this case, determining when to rebuild nginx on a server. <davexunit>an informal dependency graph, roughly speaking. <efraim>i lined up my parenthesis and variables with alist-cons-after !! <efraim>now to see if i successfully split off share/graphviz/doc <davexunit>efraim: 'modify-phases' is the preferred way to manipulate an alist of build phases <davexunit>it's syntactic sugar for all that alist-cons-{before,after} stuff <efraim>i actually used curl's modify-phases as an example for what to do, and converted it to alist-cons-after :) <efraim>one patch to change the version and a second to split off the documentation, or all in one patch? <lfam>I know about `guix build --with-source`, but how do I build and install a local tarball into a profile? <bavier>lfam: I think you can use '--with-source' with `guix package -i' <lfam>bavier: nope, it's an unrecognized option <efraim>lfam: do you mean you downloaded the tarball and you want to use that as the source? <efraim>in that case you can do `guix download file:///path/to/file` or there should be a mirror option <mark_weaver>lfam: you can do "guix package -i /gnu/store/..." where the latter was already built using "guix build --with-source" <efraim>`guix package -i --with-source=file` <mark_weaver>there are some disadvantages to that approach though <lfam>mark_weaver: what are the disadvantages to that method? ***davi_ is now known as Guest22197
<mark_weaver>lfam: when you do it that way, guix doesn't know anything about the package, not even its name or version number. things like upgrades don't work properly, and if you install the same package later the old raw /gnu/store/... one will stick around until you explicitly remove it, etc. <lfam>So, is efraim's method better? <efraim>guix package inherits from guix build, so build options are supposed to work on package <mark_weaver>it's the same thing that bavier suggested, and you said it didn't work. <lfam>Well, maybe you cannot do `guix package -i package --with-source...` but you can do `guix package -i --with-source..." as efraim suggested. Unfortunately I will have to save this work for later <mark_weaver>"guix package -i package --with-source..." is definitely not right. <mark_weaver>it should be "guix package -i <PACKAGE_NAME> --with-source=<URL> <efraim>mark_weaver: yeah, I should've spelled it out like that <efraim>i sometimes do `wget <url>`; `guix download file://path/to/file`; `guix build <PACKAGE_NAME>` <mark_weaver>--with-source is not in %standard-build-options. it's supported only by "guix build" <paroneayea>davexunit: the sicp wizard bit will have more clarity said out loud with a "I love wizards", before you think I'm hating on the sicp wizard or sicp :) <paroneayea>davexunit: also, I'm watching the sussman talk you posted while cleaning this up <davexunit>"if you know the name of the spirit then you have power over it" <paroneayea>GOOD-ENOUGH? is my favorite function name of all time <davexunit>paroneayea: in the "functional programming strategy" part, I think it would be nice to mention that the "dirty" part is used as scaffolding for the "clean" part. <davexunit>that state is pushed to the fringes of the program <davexunit>paroneayea: and also, maybe mention in the Guile section that one can view Guix as a library. <paroneayea>davexunit: with the scaffolding part, that also means that you can treat the state as passing in as arguments from the fringe and passing out as the result evaluation, right? <davexunit>there's an input and output port from which things flow into the functional system from the imperative system <davexunit>and back out from the functional system to the imperative system <davexunit>separating the description of processes from their side-effects <paroneayea>so, if I start a guixsd system, where's the "system profile" again <paroneayea>is /etc/ built out of /run/current-system/profile/etc ?