<lfam>Well, you could restart the service and try winning the `ps` race ;) <lfam>I don't know how to find this information is a better way, but I'm sure there is one <reepca>well, I ran herd enable ntpd and then herd start ntpd and I'm not seeing any new respawn messages in shepherd.log <reepca>Still can't get into the GUI though, it seems to be frozen. Maybe if I restart and try one other than xmonad? <ng0>we have tlsdate.. but i don't know if this is functional enough on guix (service?).. if ntpd is the problem <reepca>okay, now I've restarted and tried starting a session with i3-wm and there's some red text in the bottom-right that says "Error: status_command not found or is missing a library dependency (exit 127)". There's a cursor I can move around and stuff but nothing there. <reepca>okay so the problem with ntpd *does* happen when starting it directly via herd. Will try starting manually now. <lfam>reepca: In i3, there is always nothing there. Try win+t for a terminal emulator or win+d for dmenu. I wish I had another name for that key ;) <reepca>I've heard it called "super" before <lfam>There *should* be a status bar on the bottom but I guess that's why you see an error message <lfam>I wonder what the problem is <reepca>it asked me some configuration stuff before, and I told it to use alt as the modifier <reepca>but with both win key or alt + t it doesn't do anything <lfam>I guess you have to install i3status yourself, <ng0>it's been years since i3, can't help very much. sorry <lfam>I'm using i3 right now. You should see the status bar if you install i3status and log out and in <lfam>You can exit i3 with super+shift+e <lfam>Hm... maybe super+enter for the terminal? <reepca>alt+d changed the cursor to what I think is supposed to be a clock? <lfam>That clock is synonymous with the hourglass <lfam>I think that i3 needs both i3status and dmenu installed alongside it <lfam>Considering that neither 3rd party component worked for you :) <reepca>why aren't those in the dependencies? <lfam>We should add them to the lightweight desktop example so that new users have a better experience <lfam>Because nobody put them there yet :) <lfam>I don't think they should be dependencies of the i3 packages. But they should be in the lightweight desktop example <lfam>You might also have to install a graphical terminal emulator if you want one, I'm not sure. <lfam>Well, you'll have to install all the end-user applications that you want to use. I just consider the terminal emulator a very crucial one <reepca>or i3 could show a list of the hotkeys that seem to be the primary mode of operation during configuration. <reepca>so wait, are any of the programs that come preinstalled accessible to normal users, or just to root? <reepca>I just remembered last night that I tried logging in as a normal user and it said it couldn't find ls... <reepca>but I tried it now and it works? <lfam>Last night, how did you log in as a normal user? <reepca>ctrl+alt+f2, enter username and password. <lfam>Very strange, ls should always be available <lfam>Some people try logging in in ways that set up the environment incorrectly, but logging in at the console should work fine unless you have written a broken shell initialization script and broken $PATH <reepca>I don't remember doing any of that <lfam>Anyways, if you aren't familiar with i3, it's a tiling window manager <reepca>on the bright side, I just managed to use alt+enter to open xterm <reepca>so something must finally be going right <lfam>I guess that super+t is something I did on my own and forgot about <lfam>In general, on GuixSD, *most packages* are installed per-user. <lfam>There is a set of base packages that are available to all users, defined in (gnu system) aka 'gnu/system.scm' in our Git repo. <lfam>And finally, the administrator can make packages available globally by cons-ing packages onto %base-packages in the system configuration file (typically config.scm) <lfam>Are you still having trouble with ntpd? I'm wondering if it restarts if it has network problems <lfam>Since your connection seemed unstable earlier... <reepca>I think both of the connections go to the same switch, so if my laptop was having troubles I'd expect the desktop to as well <lfam>Well, your desktop might have a better-configured ntpd service ;) <lfam>If it's a more established distro, I'd say it's even probable! <lfam>On that subject, I think we have some great dog food! But we are definitely eating a lot of it ;) <reepca>oh man... tried running guix pull to get newer icecat for my user (just realized that the guix versions for root and users aren't linked) and got complaints about 2016-10-12 being in the future. I should really find out what's happening with ntpd. <lfam>I know that ntpd won't work normally if your date is very wrong <lfam>I think you'll need to use ntpdate to force a clock update <reepca>manually running ntpd the way it was listed by ps seems to cause it to print some stuff and then exit <lfam>It's an old daemon so it might try to background itself. I'm not sure <reepca>if so it's dying immediately on doing that, ps doesn't show it <ng0>if I wouldn't have to prefix it with emacs-, my next commit would be to add evil :) <lfam>reepca: What architecture is your system? <lfam>And what is the output of `date`? <reepca>uname -a => "Linux GReepca-Potato 4.8.1-gnu #1 SMP 1 x86_64 GNU/Linux" <lfam>And also the output of `hwlock` <reepca>hwclock => "Wed 12 Oct 2016 12:56:33 PM CDT .699844 seconds" <reepca>I love it how date reports in american ordering and hwclock in european <lfam>Can you run ntpd with `-d` to increase the verbosity? <lfam>date can do very complex formatting, fwiw <ng0> /me has finished evil. may it serve other masters in guix <reepca>I'm continually amazed by how many channels there are on freenode <ng0>I wonder if I worked before on neovim.. or if that was just neomutt. <lfam>reepca: If setting -g works for you, I'll propose the change <reepca>date => "Wed Oct 12 18:06:45 CDT 2016" <reepca>synced with my desktop to within under a second :D <lfam>Okay, thanks for sticking with it :) <reepca>now I just need to figure out how to properly modify the system to use that flag when starting the service <reepca>and figure out how to apply that wifi patch <reepca>or, heaven forbid, manually go to each file and add the stuff? <lfam>reepca: You can apply that patch like this: `patch -p1 < path-to-the-patch-file` <lfam>You have to run that from the root of the Git repo <lfam>So that the paths in the first line match up <lfam>I'm making a patch for the ntpd issue. <ng0>to build the vim plugin for notmuch we need vim with ruby support. why is vim build without ruby? <ng0>I'll send patches, maybe it just hd no use so far. <lfam>There's another patch you can test :) <lfam>That one can be downloaded and applied with `git am path-to-the-patch-file` <ng0>I have never seen the vim test suite.. weird thign <lfam>You can also use `patch` as above <reepca>oh, I thought "patch file" meant "file to be patched" <lfam>Git or `patch` will know which file to apply the patch to <lfam>diff --git a/gnu/services/networking.scm b/gnu/services/networking.scm <lfam>Says to apply it to gnu/services/networking.scm <reepca>so I clone the guix repository, apply the patch, and then...? <lfam>And then! You can refer to sections 8.1 Building from Git and 8.2 Running Guix Before It Is Installed. <lfam>You will build Guix from source, and then can use the Guix you have built to reconfigure your system with these patches applied <reepca>I'm gonna have to come back to this, got band in half an hour and need to fit in supper <lfam>There's a cycle involving gtk+@3 on core-updates <reepca>This is depressing. I'm watching information about the disk (in this case flash drive) usage scroll down as another terminal uses guix to install stuff. Rarely over 4KB/s, sometimes as high as 1 or 2 megabytes per second. It's just... saddening. I mean at least the flash drive works, unlike the 3 16GB ones I bought (all defective). Why do I have such rotten luck with flash drives? <reepca>Silicon Power 64GB are the ones I'm using now, the defective ones were from Adata <reepca>I'm open to suggestions for the future. <Drakonis>And are there alternate repos to the defaults yet? <lfam>The master branch should always be stable. We are working on a new release version now <lfam>Although you might want to clarify what you mean by "stable". <lfam>What I mean is that the master branch should always give you a working system <Drakonis>Given the libre linux derivation was throwing a error last i tried <lfam>Do you remember what the error said? <Drakonis>Look at the logs around the first week of october <lfam>I rebuilt and booted linux-libre yesterday. <lfam>Please send that report if it's still not working <Drakonis>Arent unofficial derivative repositories yet? <lfam>Do you mean package definitions or build servers? The former, yes. The latter, I haven't heard of any public ones but there are some private institutional build servers. <reepca>so now that I've got the git repository patched and built I should run ./pre-inst-env guix system reconfigure /etc/config.scm ? <lfam>reepca: Yes. When you built Guix, did you make sure to pass --localstatedir=/var <reepca>er wait I guess I haven't finished building yet <lfam>If you are on GuixSD, you should pass that option to ./configure if you want to share store objects between `guix` and `./pre-inst-env guix` <reepca>make isn't even mentioned in the manual in 8.1 except make check. It's just assumed that the reader would know to run make after ./configure <lfam>If you didn't run `make`, `make check` will do the building before it checks <lfam>That's our way of persuading people to run the test suite :) <reepca>I'll be happy when I can get back to running icecat, had to use my other crappy flash drive to transfer the patch paste text. And I had to read up on the documentation for mount. Which you'd think I wouldn't need to do after using linux for over 2 years, but I guess Ubuntu spoils me. <reepca>ahaha... with the patches, ntpd is still immediately shutting down and then getting started by shepherd. But the funny part is that I know why: "unable to bind to wildcard address :: - another process may be running - EXITING". I left my manually-started one on by accident lol <reepca>terminated it, ntpd seems to be working fine now <lfam>I wasn't sure if we'd yet taught shepherd to reload a changed ntpd service without rebooting. I'm glad it's working. <reepca>now will I have to restart to see if the b43 firmware package helps? <lfam>I wonder if bavier is still around... <reepca>hm, do I have to change my config.scm to use the b43 firmware stuff? I thought it might be something that was automatically added when I did ./pre-inst-env guix system init /etc/config.scm <reepca>ah, I should probably change the firmware option, shouldn't I... <reepca>That would be consing what now on to %base-firmware? <reepca>uh oh, now I've got an error message about ntpd: ntpd[327]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized. Not sure what the deal with that is. <reepca>hm, apparently openfwwf-firmware is unbound. It's defined with define-public in the patch... what exactly does define-public do (coming from a common lisp background here)? <reepca>I'll just rebuild it and log the build this time. Oh, and run make check. Probably should have done that the first time. <reepca>and now I'm getting "perf: Interrupt took too long (<some number in the thousands> > <some other number in the thousands>), lowering kernel.perf_event_max_sample_rate to <some number in the ten thousands> <reepca>arg, should have run make clean first. It didn't try rebuilding so I could see if anything went wrong there, just ran tests... <reepca>getting quite a few ";;; ERROR: missing interface for module (charting)" messages <reepca>okay, one of the tests failed: "FAIL: tests/syscalls.scm" <reepca>ACTION goes to sleep now, class in the morning, look forward to working on this further ***tschwing_ is now known as tschwinge
***MatthewAllan93_ is now known as MatthewAllan93
<ng0>guix can put breaks to this like it already does for zip bombs etc. <jmd>Do you mean breaks? Or do you mean brakes? <ng0>both would have the same effect in the end, to stop it. <rekado>ng0: re vim and ruby: Because vim can be built with Ruby and Python and possibly other languages. That’s optional and adds quite a lot to the package closure. <ng0>well like I wrote in the patch, the notmuch vim needs it. <ng0>so create a vim-minimal if that's too much for you <ng0>as far as I understood the current limitations of our way to package, the way to go is to add all the optional things which are possible. current vim is more like a minimalist vim <efraim>i've played around a bit with larger vim packages, I think it makes more sense to keep a minimal and a "maximal" build if we go the multiple vim route <efraim>it took me about 20 minutes to build a recent vim with all the addons I could find on my netbook, so not too bad as far as it goes for having a custom one <ng0>so I guess you already have a package which you could easily push for patch to master? <wingo>so how are we doing on core-updates <wingo>is it close to building things? should i use it? <wingo>also janneke what is the mingw guile status? i guess with 2.0.13 things should be even better (support for system*, for example) <civodul>wingo: seems to be doing okay, though Hydra's web interface is reporting inaccurate info for reasons yet to be elucidated <civodul>i suppose you could try building what you're interested in there and see what happens <wingo>just wondering if i should do cups-services things now or wait <wingo>i suppose i could just get a build going in the background <wingo>good job finding that mkdir / threads bug btw <wingo>civodul: i guess i can just commit the cups-service patch on top of core-updates; wdyt? <wingo>we can iterate on it in-tree <wingo>factoring the configuration stuff for example <wingo>i suppose ideally we'd have a test for cups, too... <civodul>i think rekado had commented on the latest patch already? <wingo>they were somewhat incomplete, and i forgot to address the samp/code concern <wingo>but i did get the line length / comment concerns <wingo>i believe i addressed those comments <civodul>perfect, so we could install it on core-updates and work from there <wingo>except the duplicate line thing <civodul>and eventually also factorize code as Clément suggested <wingo>i will poke those two and then apply directly <civodul>an OS that is capable of printing stuff! \\o/ <wingo>tho i can get my home printer to work but not the one in this coworking space, garrr :) <civodul>oh, it seemed to be easier though, printers advertised over DNS-SD seem to work out of the box <wingo>all of the partners of guix hackers will breathe a sigh of relief to not have to be involved in printing :P <wingo>i know you have mentioned that but i never understood it <wingo>maybe because there was no IPP server on my network <civodul>you could check what "avahi-browse _ipp._tcp" returns <wingo>whereas you had someone in your house with an ipp server <wingo>i wonder why you were able to do that and not me <wingo>does one need cups installed in the profile or something <wingo>i certainly see the printer locally <civodul>could be, i do have cups in my profile <civodul>i don't recall why, but that might have been the reason <civodul>though i think commit 37cb3a69acbe062438fa30aa0db8680af66ea40b last year is what enable the GTK+ dialog box to show printers <wingo>maybe the gtk cups backend ends up exexvpe'ing some cups helper <wingo>i did a quick grep and didn't find anything fwiw <wingo>ok, i pop cups off the stack for the moment tho <ng0>grml... where did nickserv go to? was it renamed? <ng0>I wanted to update my sasl cert, all i get is 'no such nick' <ng0>can#t even authenticate right now because of this. <ng0>if only sasl wouldn't be too much for ii.. back to this client. <efraim>i remember what it was, i wanted gvim <efraim>i just started chucking flags and inputs at it <ng0>I wonder what happened with neomutt.. been a while since someone told me my patch is working, but no patch got back to the list <ng0>mutt is one of the many things where gentoo is not sticking to upstream.. you can create mutt, but the default is a frankenstein creation of mutt+neomutt+some+more+sources, which was actually very nice <ng0>but if you start to believe this is mutt, you get irritated by the real mutt and its missing functions <ng0>efraim, are you okay with me using this in an update to the vim.scm in master and if you aren't already named in the header adding your name there? <efraim>ng0: sure, but it should be pared down a bit. In particular I don't think python2 and python3 can both be in at the same time <efraim>I don't remember what some of the options mean ***tschwing_ is now known as tschwinge
<wingo>gpg fails to build on core-updates due to a patch that does not apply <ng0>repeated questions like these should also tell us that the website is not good enpigh in pointing out the differences and unique points of guix <rekado>kmicu: I don't have a reddit account (and don't want one), but one thing I really enjoy about Guix is that it's a Scheme library and I can use Scheme for everything. <rekado>ng0: not necessarily. Not everyone will read through the documentation or watch the videos to get their question answered. <rekado>this question is not answered quickly. <rekado>Also, I don't think the website should have a section on differences to NixOS. <kmicu>rekado: I’m not the one asking the question :) I just saw it in my Elfeed’s feeds and it’s an opportunity to (honestly) promote Guix(SD). <ng0>documentation.. I said website. what's visible at first view. "Why Guix?" from a developers and from a users perspective .. and separated (like taler does it) <rekado>and "Why Guix?" is a very different question from "What are the differences between Guix and Nix?" <rekado>(I count videos and talks as documentation.) <ng0>website is something people consider reading before they go to documentation.. <wingo>civodul: incidentally re: cups -- seems to me that there should be no need for the cups package to symlink things from cups-filters to its dir, given the union dirs from the cups service <wingo>it might be also that cups might not need to depend on cups-filters <rekado>back when I packaged it this was the easiest way to get around a dependency problem. <wingo>in which case we could probably remove the difference between cups and cups-minimal <rekado>but I don't remember the details. <wingo>i think guix vs nix could be a nice blog post if it were done thoroughly & with sympathy to both <wingo>would be nice to have something everyone was happy to link to <wingo>as the question isn't going away any time soon :) <rekado>maybe someone using both Nix and Guix could write it...? <wingo>i hope someone beats me to it <civodul>technically i'd be in a good position to write such a thing, but i prefer if someone else does :-) <civodul>i did touch this topic specifically on several occasions, like CUFP this year and ELS at the time <rekado>that's a new one for me: guix build: error: build failed: querying path in database: database disk image is malformed. <rekado>I have no idea what this means and what I've done to deserve it. <rekado>I guess this means that the sqlite db is corrupt :( <civodul>rekado: sounds like it, i've never seen it before <civodul>did you upgrade sqlite or something? <rekado>I switched branches and wanted to build a new package <civodul>can you run "sqlite3 /var/guix/db/db.sqlite"? <civodul>well, that's going to be a lot of output <rekado>there's a file big-lock in the db directory <civodul>is the file empty? does "cat db.sqlite > /dev/null" work? <janneke>wingo: re mingw, i'm waiting for the v10 patch set to be merged; possibly by mark_weaver? <rekado>I don't have sqlite3 installed so I just searched for it in the store and used the latest version available. <civodul>are you using the sqlite that guix-daemon is linked against? <rekado>it's not a big deal. I should move around partitions anyway, which means reinstalling GuixSD. <rekado>(luckily this didn't happen at work) <civodul>would be good to see if there's anything else at play <civodul>like "dmesg | tail" showing that the disk is failing or something <civodul>but it's true we don't really have a recovery plan if the db is corrupt <rekado>strace doesn't tell me much. Just that it tries to open /var/guix/db/db.sqlite-wal, which doesn't exist. <jmd>Is there a programmatic way to find out in which module a package or service is defined? <davexunit>yes, the guix CLI can even print such information <davexunit>take a look at the source code for the procedures used <rekado>civodul: it's fine after reboot and fsck. So it was just normal fs corruption. <civodul>"normal fs corruption", i like it ;-) <wingo>guix environment -C is pretty fun, there's not even any "ls" :) <janneke[cm]2>wingo: cool, well...I've asked if there's anything I could do.... <wingo>janneke[cm]2: for me it was ready for merging, dunno <civodul>yeah i said i'd look at it and apply if mark_weaver didn't show up <jmd>davexunit: If the CLI can do it, shouldn't it be documented ? <davexunit>jmd: you can obtain source info from any object in guile <davexunit>it is documented, but I haven't looked it up for you <civodul>jmd: also package objects have a 'location' field <jmd>davexunit: Please spare me this patronising crap. Just because something is obvious to you, does not mean it is for everyone. <civodul>wait, calm down gentlefolks, this is a bit harsh! <davexunit>jmd: I can't spoon feed everything to you. I told what I knew off the top of my head, and gave you a direction to head in to learn more. <fps>jmd: ideally the guix cli should be self documenting :) <ZombieChicken>"self documenting" doesn't help if people have a hard time finding the help 'feature'. And telling someone "Go sort out the Scheme code to learn how to use our software" is a really, really bad answer <davexunit>ZombieChicken: that is not what the question was about <davexunit>I pointed out the CLI as a place in which a particular Guile procedure was used <fps>here's the original question for everyone: 16:10 < jmd> Is there a programmatic way to find out in which module a package or service is defined? <davexunit>apparently "I don't know exactly, but here's a place to look" is not an acceptable answer <jmd>davexunit: It is when "here" is so general as to be useless. YEs. <jmd>But what is more unacceptable is that the answer you gave in this instance was not intended to help. It was intended to frustrate and annoy. <ZombieChicken>jmd: Packages are, iirc, defined under the gnu directory in the guix source <rekado>jmd: please assume good intentions. <davexunit>I was giving an honest answer in an attempt to point you in the right direction <rekado>jmd: there's no reason why anyone here would like to purposefully annoy and frustrate people asking questions. <ZombieChicken>rekado: You are aware that people have reponded to questions in here with "When did you stop beating your wife?", right? <jmd>rekado: It is difficult to assume good intentions from judgemental comments such as "you decided to ignore my advice" <rekado>I have to go now but please look at the order of comments again. It would be good to avoid needless escalation like that in the future. <davexunit>jmd: you responded to me with a complaint about it not being documented. it *is* documented but I just don't know the name of the procedure so I can't point out where in the guile docs it is! <davexunit>anyway, civodul gave a more thorough answer. packages have a 'location' field that I had completely forgotten about. <davexunit>that would be the best thing to use in this case. <davexunit>'package-location' is the name of the procedure, most likely. <jmd>ZombieChicken: I know where the sources are. My question was is there a programmatic way to find the module which exports them. <jmd>(for packages and services) <bavier>*not judgemental, just helps to know* <jmd>bavier: I want to autogenerate a config file. <bavier>jmd: have you considered using specification->package ? <ZombieChicken>davexunit: Does Guix(SD) have core devs? It feels a lot like a bunch of random people contributing without anyone really guiding anything <davexunit>ZombieChicken: the core developers are the people with commit access <jmd>bavier: That will certainly help in the case of packages, but not for services. <davexunit>different people know different parts of the codebase better than others <jmd>A GuixSD system config <reepca>um... okay, so that was interesting. I had a separate ntpd running and killed it so that I could run the service one with herd, and thought I'd try out some command-line syntax to see if it worked, so I typed "herd enable ntpd start ntpd". And then I got a kernel panic and everything stopped. <reepca>I don't think that's supposed to happen? <reepca>I mean yes I should have looked at the man page first, but a kernel panic over invalid command-line syntax seems like disproportionate retribution, right? <mark_weaver>it's certainly not supposed to happen. my first guess is that shepherd (our PID 1) died while trying to respond to the request from 'herd'. can you email bug-guix@gnu.org about it? <reepca>sure, where should I look for the panic message? <reepca>(not very used to doing this kind of stuff) <mark_weaver>unless you have a serial console, typically kernel panics are only visible on the screen, unless the kernel was able to recover. <reepca>I suppose that makes sense. So I should just say what I did to produce the error? <mark_weaver>but it seems highly likely that PID 1 died, in which case the kernel panic message details are not important. <ng0>wauza. thanks for discovering this <ng0>do you know if we need a small service for tldate? <ng0>there's also this network time sync hidden-service based software TAILS uses, but they use some applications to ease their own building process so I'm working on that.. well, only debugging, packaging part is done. <reepca>alright, sent it. Anyone wanna try crashing their system to reproduce? <ng0>I have a system to crash. <ng0>I take a look to reproduce <reepca>when ntpd is disabled, run "herd enable ntpd start ntpd" <ng0>alright.. needs to boot <ng0>could be that this is the system where ntpd dies for me <ng0>so I just wait until it is done respawning <reepca>that might be the same problem I ran into yesterday, running it manually with the -g flag worked <ng0>this is an experimental, you are allowed to crash, system I use for system services I work on :) <ng0>ah, ntp works now it seems .. although with an offset of 8 minutes <ng0>i'll try to crash it <ng0>no idea how to save it, shall i take a picture? <reepca>ah man, rebooted and was greeted by "error: ELF header smaller than expected. Entering rescue mode... " <reepca>Maybe testing kernel panics is just too hardcore for this flash drive <ng0>well it's good that you found this, really :) <ng0>phone upload.. hurgh.. mediagoblin had instances where you don't need to signup? I don't want to ssh into the phone <reepca>anyone have any suggestions as to what I can do from grub rescue to try to save my flash drive system? <ng0>though I would not mind signing up <mark_weaver>reepca: in GuixSD, you should be able to select an older generation of the system to boot into. <reepca>I think GRUB itself, it didn't get to the menu, it got as far as "GRUB loading. Welcome to GRUB!" and then dropped me into rescue mode <mark_weaver>I'm sorry, I don't have time to help you debug that now <reepca>that's okay, should I just reinstall guixsd on it? <ng0>screenshot is uploading <ng0>i think it's the size of image where you can zoom in and see the dust and dirt on my monitor :D too big <ng0>ah, quitter.se reduced it to 1000x something <ng0>previously it was 3800x something <reepca>I'll give the other flash drive a shot, hopefully it'll be faster than this one was. <ng0>for context, the git commit the system i just crashed is: <ng0>well need to reboot for that <ng0>it's not that far behind master <ng0>commit which added the workaround of vigra, ending with 12b94f6e958 <ng0>info attached to your bug report. thanks <reepca>huh, I seem to have used the wrong email address on accident. Oh well. <ng0>i must say, the supercollider community is very information and meetup rich :) <ng0>i asked about meetups in germany other than berlin, and got pointers to düsseldorf and invitations to mannheim region <rekado>just finished the FSFE meeting about all things free audio software. Very well received and Guix helped me show cool, fresh software. <ng0>i don't know how ruby packaging is supposed to work... <ng0>can we document this? <ng0>or is it obvious to ruby-people <ng0>in case of software gitlab needs, or like mastodon <reepca>So in the process of system init'ing another flash drive I've noticed that a lot of time is spent with little disk activity happening (according to iostat) and little cpu usage. I don't think my system could be considered heavily loaded, so I'm wondering what it's doing during that time? <reepca>Doesn't it usually say "Substitutes: updating list of substitutes" or something like that, or am I thinking of the wrong thing? <rekado>ng0: there’s nothing special about ruby packaging. It’s very much like packaging python stuff. <reepca>Right now it's just saying "copying /gnu/store/asdbasdfkjalsjdf-package..." and there's rather little disk activity happening. Maybe it's my accursed luck with flash drives at it again. But I tested this one, and it went at a pretty steady 27MB/s (not great, but definitely good enough). <mark_weaver>reepca: I'm not sure if messages of consistently printed during network activity. <detrout>reepca: I thought there was a phase where the store manager found duplicate files and hard linked them? <detrout>that could generate a lot of disk io? <reepca>it did a bunch of downloading from hydra, then it said "initializing operating system under 'media/reepca/GuixFlash/'", and now all it says is that it's copying stuff, but there's rather little disk io happening and it's taking quite awhile <mark_weaver>reepca: if you tested disk activity with some simple file write before, it may be that the I/O patterns used during install are handled much less efficiently by the flash device. <mark_weaver>the underlying flash hardware is not able to do random writes, so it requires a rather elaborate translation layer. <reepca>so wait, flash hardware has variable latency? <reepca>but still, it can go 8 seconds at a time with nothing being written to it according to iostat. Those would have to be some *really* weird i/o patterns <ng0>can someone show me a bug/thread link where using the /gnu/store on a separate, dedicated partition lead to problems and was solved during that thread? the gentoo problem is just that. but we're discussing off list about that, which is not so good to make it publicly visible for progress <ng0>or some 'do this, do that, done' line I could link to in the gnunet.org chat log <ng0>rekado: there's this [https://github.com/Gargron/mastodon] which looks like a easy job but is in beginning stages.. already functional, but I want to see the password bug I just reported to be solved before I start with it <ng0>all procrastination to slow me down with debugging services :/ <catern>hey #guix, besides grafting, are there any alternative ideas for mutating dependencies without rebuilding dependent packages? <catern>that is a really useful ability for development <catern>but grafting is (probably) way too slow to use for development <catern>where "development" means I rebuild Z and now A, B, C are using the new version of Z and I test A, B, C <catern>without having to rebuild A, B, C. like, I mean, maybe point A/B/C at some kind of "mutable" package directory? <mark_weaver>catern: guix is based on the assumption that all items in /gnu/store are immutable. violate that assumption that lots of stuff will break badly. <rekado>if Z is a library you could use LD_PRELOAD(?) or LD_LIBRARY_PATH to override the library <rekado>for quick development iterations this might be useful. <rekado>I wouldn’t always commit things to the store when developing. <rekado>When I develop things with Guix I mainly use “guix environment”, not “guix build” <catern>rekado: right, if I'm developing a leaf package, it's fine to use guix environment <catern>but if I'm developing a library, then I want to see how packages behave when I change the library <catern>this doesn't have to involve committing things to the store, necessarily, maybe there's a way that doesn't involve store commits on each rebuild? <catern>the other issue with adding build artifacts to the store is, then I can't just mutate them in-place which is something else I might want to do while developing <mark_weaver>catern: would rekado's suggestion to use "LD_PRELOAD(?) or LD_LIBRARY_PATH" work? <catern>LD_LIBRARY_PATH certainly works for the specific case of C libraries <ng0>afaik no.. when I do changes in gnunet and rebuild it with the guix file, it builds into the store <catern>but I kind of want a more generic approach <ng0>minimal changes, but still everything builds into the store. don't know how it would not <mark_weaver>that sounds like a great goal, but I don't see an easy way to do it. <catern>I would accept a solution that requires you rebuild everything up front to point at a mutable package location <catern>like: I rebuild A/B/C to point at /gnu/store/00000000000000000000000-Z/ <rekado>that’s actually one of the few cases where LD_LIBRARY_PATH is the right solution. It almost never is, but that’s what it was made for. <catern>then 0000000000000000000-Z gets pointed at different versions <rekado>With it you can temporarily override the lib used by the dynamic linker. <rekado>other systems use a library cache whereas we use RUNPATH to embed references. <catern>rekado: yeah, definitely LD_LIBRARY_PATH is exactly what I'm looking for in the C library case <rekado>for Python stuff there would be PYTHONPATH to prepend to. <rekado>not sure about Haskell (maybe GHC_PACKAGE_PATH). <mark_weaver>would our wrappers effectively undo the attempt to use PYTHONPATH in this way? <rekado>I think it’s best not to mess with the store and its consistency. <rekado>mark_weaver: they might, but you can run scripts without the wrappers. <bavier>our wrappers typically prepend to any existing value <rekado>I shudder at violating the invariant that all references map to items in the store. <mark_weaver>rekado: in the general case, you may run a program that runs subprograms, each of which is wrapped <catern>well okay so putting what we want to do in Guix terms, one way to achieve this would be, if we had a GUIX_PACKAGE_PATH which things (magically) looked up packages in first before actually looking at the baked-in hash <mark_weaver>but maybe that doesn't happen often in practice, dunno. <catern>oh! actually there is one Linux kernel extension that would allow that kind of approach (which sad to say didn't actually get comitted) <rekado>(we have GUIX_PACKAGE_PATH, but it means something else ;)) <catern>(didn't even realize what I was typing haha) <rekado>re wrappers: you could just wrap again, no? <catern>but they aren't actually in the kernel <rekado>ACTION goes to bed, brain fried, yummy! <catern>variant symlinks are kind of ugly anyway <mark_weaver>catern: the deep problem here is that we've written a great deal of code that's heavily based on the assumption of an immutable store. most commonly, when we want to do a logical "copy" operation, we don't bother actually copying the data but only the reference. <mark_weaver>to be more concrete, guix users have occasionally mutated something in there store, and then run into bizarre problems where they ask guix to build a new package, and the new package is bad because it aliased the part of the store they mutated. <catern>I definitely think the store should stay immutable <catern>which indeed makes this a bit tricky but I don't think insurmontable <mark_weaver>anyway, this is a discussion for guix-devel, not irc. <mark_weaver>I'm sure civodul will have strong opinions on this matter, and he's not here now. <catern>will civodul's opinions be for or against this concept? :) <mark_weaver>catern: however, I can make a hacky suggestion for now: <mark_weaver>as a placeholder for the library-to-be-developed, create a guix package with some version of that library, to be used to compile the packages based on it. <mark_weaver>and include a random hash in its name, to give it a unique identity, such that no other package will be unintentionally shared with it. <mark_weaver>and then use Linux bind mounts to mount your mutable directory on top of it's directory in /gnu/store/ <mark_weaver>the random hash could also go in the version number. that's probably better <mark_weaver>(the random hash could actually go anywhere in the package definition that ends up in the resulting derivation) <catern>yeah, that's one approach I was thinking about (though I didn't realize you'd need the random hash, thanks for pointing that out)