IRC channel logs
2016-07-23.log
back to list of logs
<rekado>lfam: I’m currently working on this. <rekado>when “(which "gs")” fails I wonder if “gs” might no longer be installed in the correct path. <lfam>I'm reading the icecat build log <lfam>I think the problem with icecat is this: <lfam>../../../dist/include/mozilla/Telemetry.h:25:37: fatal error: TelemetryHistogramEnums.h: No such file or directory <lfam>mark_weaver: Have you seen that icecat build error before? ^ <rekado>confirmed: ghostscript doesn’t have a “gs” executable. <rekado>there’s a commit by Ludo: “Do not build the statically-linked 'gs' binary.” <lfam>rekado: Andreas sent a message about this to guix-devel <rekado>okay. (haven’t received it yet.) <lfam>On master, we added #:hide (openssl) to the license module import. On core-updates, we added #:select (some licenses) <lfam>For gnu/packages/scheme.scm, that is <lfam>Okay, the #:select seems sufficient <rekado>I don’t like #:select for licenses. I much prefer importing all of them with a prefix. <lfam>Yes, the #:select list grows until the prefix is required. <ng0>haven't checked for trademarks, i just found this <lfam>It would be interesting to know who was first <ng0>they provide no date <ng0>at least from first sight <ng0>maybe archive.org knows <lfam>From their "News" page, the first hit for "Guix" is in April 2014 <lfam>But, that's not an exhaustive investigation :) <ng0>I'd say it's a different product, confusion does not apply <lfam>One would hope... but some organizations are very litigious. And both are related to computing. <ng0>someone in 2014 noticed this too on the list <ng0>association Guix Europe does not yet cover any copyright/tm things, right? I don't know muhc about the laws in france, i would not even know about the kulturverein/association laws in germany <lfam>In the USA, my understanding is that copyright and trademark are "de facto". Registration only makes it more convenient to defend your claims. But, I'm not an expert on this <ng0>internationally it is very different. i think in europe it could be that if you have no copyright on your work, the creators copyright still applies in some basic assumed form <lfam>For copyright, that is base of free software licenses. There are *no* redistribution rights unless they are specified in a license <ng0>i just saw the core-updates messages.. building vlc now to see if i can fix it <lfam>ng0: I just merged master into core-updates, so be sure to `git pull` to get the latest <ng0>today was annoying, to find out about the elitism and arrogance of gentoo. i try to not look at it as wasted time but i learned a thing or two about debugging and it's still useful for people what i did and still is useful. <lfam>ng0: Do you want to give any more details? Similar things were said about Guix recently, so I'm interested to hear your experience with another organization. But I understand if you'd rather let it go <ng0>I wanted to give more positive outlet on the most recent thread on the mailing list <ng0>i'll be away for some minutes, then i can give some quick details <lfam>Okay, that's a good idea. Negativity breeds more negativity. <Acou_Bass>lfam: youve heard that guix has elitism/arrogance in its community? ive never seen that, not in this IRC room anyway <lfam>Acou_Bass: It was surprising to me, too. I don't think was about IRC, but rather about asking too much of people who send us patches. <ng0>we have a problem with organization caused by number of people regulary involved (around ~32 atm in Guix).. that's all i see <lfam>Whether or not I agree with the criticism, there's always room for improvement. And I'd hate to drive away contributors. <ng0>the problems with Gentoo are actually what one can learn on how not to do it <rekado>FWIW, I’m playing with mu-guile because I want to see if it would be easy to set up a patch tracker with email control features. <rekado>I’m unhappy with the situation we have and I understand that some people are frustrated by this. <lfam>I would like a hybrid mailing list / web page. The problem with GitHub, GitLab, etc is there is no place for discussion. Everything is either a patch or a bug <lfam>Plus the fact that it's on a web page <rekado>I disagree with the claims of “elitism” or “aloft standards” or “nitpicking”, but it’s hard to defend the mailing list workflow when we cannot effectively keep track of patches. <rekado>lfam: yes, there should be a web page representation of the queue. <ng0>I was not 'in' it, I never applied for official developer or proxy, but recently an overlay I am involved in for ~1 year now collaboratively was added to the official list, so I'm sort of in the position of providing software which I wanted to push into portage but backed down because of different reasons. One, there's #355355 bugs.gentoo.org bug which was the ultimate reason to cease communitication with the <rekado>maybe that’s what github users are looking for. <ng0>project completely. then they have 2 models for developers (well 3 since they are on github too, but there applies the proxied maintainer as well i think): 1 is applying for developer through a procedure which one can read into on their website, and 2 is as proxied maintainer. this still puts the pressure on 1 person to be responsible for this package alone. In my case I just had the packages i wanted to push <ng0>to portage in an 99% finished state and they needed some QA done. guix being more accessible to develop for I eventually made gentoo less of a priority and more of a maintenance status thing (gnunet,guix,dependencies.. that's all where i am heading and merging all my ebuilds into guix master since i started in november). the problem is on how you communicate, how you approach people, how you do your "PR". you <ng0>can not compare guix and gentoo at all at this point because they are over 12 years apart in age. i just find the collaborative way easier to deal with discussion then if you had a strict authority.. gentoo has the council, and I am mind-working on similar possibilities for guix (and in general for projects) which would enable some sort of base democracy with failure switches - gentoo at this point is a <ng0>reallife state of pretend-democracy states. <ng0>there's more to it, but that's what i can tell now <rekado>it’s not just about *us* dropping patches but also about submitters who can no longer find the relevant discussions, I think. <rekado>I know I’ve been in that position a few times before. <ng0>lfam: in gentoo, everything is a bug on bugzilla. every new feature, every upgrade, every change. <lfam>rekado: Can we not keep track? Is it a problem of email, or of people simply ignoring things. If the latter, I bet we can ignore a web page pretty well :) <lfam>Bugs are bugs but discussions are not bugs <ng0>right.. that's what bugs me about github discussions <rekado>I’m great at ignoring web pages. <lfam>Also, I think that there are some different people with different complaints. I don't want to lump them all together <rekado>I ignore some stuff because I know I can’t handle it all. <ng0>the interface needs to be good. then it does not matter what it is, mail, website, cli... <lfam>I keep mail in my Guix mailbox until I or someone else replies to it <rekado>yeah, I was thinking about just providing some API, so we can have an Emacs interface. <lfam>On the other hand, we *are* growing. We added ~20 contributors in the last release. Of course it's hard to make a judgement based on a single release. <rekado>lfam: I only keep those emails to which I’m sure I’ll reply. <ng0>my inbox went down from 26000 to 6000 or something. i tick what i need, i do not expire patches and bugs until they are resolved <lfam>Since I am less skilled, I try to "mop up" with suggestions and pointers to previous discussion if nobody else has replied <rekado>and I don’t like to wave patches through without giving them enough time. <lfam>No, we can't merge patches without review. That's out of the question. What distro does that? <ng0>I'm involved with another project which is attached to archlinux.. i could ask how they handled it in the very beginning and moved to something managable <rekado>sometimes a patch looks good to me, but I’d like to test it and see if an input is really needed… <lfam>Some people are arguing that we merge as soon as `guix build` exits successfully :/ <ng0>because that's where we are.. a handfull of people <rekado>in those cases I have come to not reply because in the past it looked like I’d hold up the patch. <lfam>Things like extra inputs are sub-optimal, but not really dangerous. <rekado>true, but I don’t like to get them past my reviews. <lfam>Indeed. I don't like to let them past either <lfam>I might just handle it myself <lfam>The real problems are buried in the code. An old bundled copy of OpenSSL, for example <ng0>one thing i liked about gentoo, which could be applied but improved, is the work in certain groups <ng0>of course atm it does not make much sense <lfam>ng0: I think we could grow into have groups that specialize in certain areas <ng0>and recently they restructured because they found herds no longer make sense <ng0>so they keep certain core groups around as far as i followed the new gles publishings <ng0>for example the security team and the hardened team <lfam>It makes sense to have people focused on those things <lfam>I wish we had more people doing that <ng0>groups or rotating groups.. where it's not mandatory but people can learn and be free to do what they like to do <ng0>and one thing i learned at archlinux-women is that outreach programs are good :) <ng0>but that requires time from us devs, so that's something which needs to be planed <rekado>I think these structures evolve. <rekado>when I see a patch for an R package I usually take a look at it immediately. <lfam>Yes, I let you and Roel handle those :) <lfam>Sometimes they seem trivial and I can say "okay" <ng0>before guix i already focused on certain packages, and moved this on <ng0>like the whole gnunet thing for example <lfam>Yes, that seems like a difficult project! <lfam>Going back, I would be really disturbed if there were women who felt uncomfortable in our community. I hope that's not the case, and if it is, I hope we can change it. <ng0>outreach is not about that though :) <ng0>it's about mentoring for example <rekado>With the patches Jookia submitted I just thought: “I cannot say anything about this. That’s for someone with deeper insight to be decided.” Usually this means: Ludo. <rekado>makes me feel bad to leave up so many things for Ludo. <lfam>ng0: I've wished for closer mentoring, for myself and that I can pass on to others <rekado>that’s a massive load of intellectually challenging email for one person to read and respond to. <lfam>I figured that somebody would grow into writing patches like that, but I didn't know any Scheme before showing up here, so my perspective is more limited. <lfam>It's too bad things became sour <ng0>there's this one retired gnupg dev i never came back to in one local hackerspace who was interested in guix started with nix at the same time.. but i lack the time to prepare a talk for an upcoming annual convetion there <lfam>ng0: What sort of convention is it? <ng0>asorted talks/workshops, called "Labortage" <ng0>germany, NRW, bochum <lfam>Hopefully, next month's GNU hackers meeting will produce an illuminating overview of Guix and GuixSD internals, recorded on video :) <ng0>it sounds great.. and made me realize my financial situation once more <lfam>Yeah... I wanted to go to France for the GNU hackers meeting... <lfam>catonano: It's harder than it sounds ;) <lfam>If you thought software was unreliable, try some audio / visual hardware! <ng0>i think i will talk to meskarune and others, get some more info on the mentors thing as i wasn't so involved in that so far. they also have classroom project (teach a topic in irc channel occassionally) and will continue to think about a fix for the current situation. more attention specifically aimed at people who are willing to review would be good. <ng0>unrelated sentences of course. <catonano>lfam: what can I say ? I'm really grateful. I can't be there and I'd LOVE a reasoned introduction to the Guix internals <lfam>catonano: I can't be there either. I was just saying that I'd also LOVE that. <lfam>It was discussed a little bit on the mailing list a month or two ago <catonano>lfam: yes, I remember. In fact I think I suggested to try to record some video in that discussion <lfam>Everybody should record it on their smartphones, if they have one. Strength in numbers :) <ng0>there's an email i wrote adressing partial problems I see/got pointed out outside of our official channels.. maybe the persons which could respond need some time, but everybody else could give their 2cts :) <ng0>maybe it makes sense to split up emails like patches.. do not fill too many related things into one message. <Acou_Bass>hmm... im not sure if this is a normal error, but ive never seen it i dont think... when i ran guix package -u it did its usual but then stopped on 'stow' package with <Acou_Bass>guix substitute: error: download from *hydra url for stow* failed: 410, "Gone" <lfam>Acou_Bass: You may need to add --fallback <Acou_Bass>ahh, thatll cause it to build it from source using the .scm wont it? <ng0>was libepoxy on core-updates something which needs to be worked on too? <ng0>it just failed, in the graph for building vlc <lfam>Acou_Bass: It will only build stow from source. The rest will be done normally <Acou_Bass>thats what i meant hehe, ill give it a go thanks :D <lfam>By "normally" I mean, other things may build from source. But --fallback will overcome the 410 <lfam>ng0: Probably, libepoxy is the reason that vlc failed <ng0>okay, i did not see that, just a failed test <ng0>well it fails when building vlc, so it is another reason why vlc fails <ng0>vlc itself fails for another reason <lfam>I don't think we have access to the source code of perl-capture-tiny anymore. The FTP connection just hangs open <ng0>libepoxy is outdated, I'll update and see if it fixes itself. <ng0>I should directly checkout core-updates for that and work on the files, and not master and then a rebase <lfam>ng0: What I would do is try updating it on top of master. If that works, I'd cherry-pick it to core-updates, and send that patch. <lfam>It would take me too long to build core-updates <lfam>And I think it's okay to let Hydra test the core-updates build <ng0>i have yet to read, understand and apply how chery-picking works. <lfam>Cherry-picking tries to copy a commit from one branch to another <ng0>looks like it succeeded <ng0>10 rounds produce the same output <ng0>Hi. How can I pass arguments specifically to our perl-build-system whic hwill resemble the command "perl Makile.PL PANELS MENUS FORS" and not override the rest of the build system? <ng0>ACTION builds vlc on core <ng0>the one thing is fixed <ng0>let's see how far it goes this time :) <ng0>could I try to update xorg-server to 1.18.4? I don't know how much depends on it. there's an issues with xorg-server in core-updates build graph of vlc <ng0>which is weird for 1.18.1 i get repeatedly the same hash <ng0>and nothing similar to what's expected or happens in the build <ng0>or could it be just the binary substitute missing from hydra? <ng0>hash is the same as in core-updates. i assume this is just because it lacks a binary substitute atm? <ng0>how does one solve use-module problems? I need to use something which is in web.scm in perl.scm but web.scm references perl.scm <ng0>any commit number / title i could look at? <mthl>ng0: this "use-module problem" is a circular dependency. <ng0>i just forgot the name :) <ng0>do i move packages around to solve that? <mthl>This is painful I know :) <ng0>what I package is a hybrid of perl libs and various applications, i do not really know where to <ng0>messaging.scm would be too general <ng0>to start a psyc.scm (I am sitting on other psyc related tools) would be too early <mthl>what is the dependency in web.scm? <mthl>the alternative to moving perlpsyc is to move this dependency. <ng0>i think moving perlpsyc is what I'll do now <ng0>regarding vlc on core-updates: <ng0>libvlc/media.c:63:2: warning: #warning libvlc_media_get_tracks_info is a broken function. [-Wcpp] <ng0> #warning libvlc_media_get_tracks_info is a broken function. <ng0>the equalizer test still fails, so myupdates changed nothing <ng0>can wrap-program transport any environment values i need, more than 1? <ng0>i need to have PSYCIONLIB exported and i think about not using substitute <ng0>alternatively: could I advise users to export this in a local file and point to their guix-profile path location? I'l try later if this works <ng0>yes i can. now how do I actually point this out, like in the pythonpath and perlpath thing one is advised to export? <Acou_Bass>does anyone else use lilypond in guixSD? im trying to update/build it but the build keeps failing ;( <lfam>Acou_Bass: We know it fails on the core-updates branch, but on master too? What goes wrong? <Acou_Bass>well it buids for a very long time s presumably somewhere towards the end... the last thing says command failed then child was terminated by signal 11 <Acou_Bass>presumably thats why its building for me instead of just binary-installing, because theres no working binary from the latest build? <lfam>Acou_Bass: Can you paste the end of the build output to paste.lisp.org? <Acou_Bass>cool to see theres a paste service i can use that doesnt use so much JS by the way ;D <jlicht>rebasing a local branch on recently pulled master, I keep getting 'Argument 1 out of range: 10' errors <jlicht>make clean-go does not seem to fix it :/ <ng0>is native-search-paths what gives the "you have to set blabla for foo" with applications like python? <mark_weaver>jlicht: fwiw, my local branch, rebased on current master, succeeds to build. is that when the error happens, during "make" ? <jlicht>mark_weaver: yes, in the course of make <mark_weaver>can you try building current master without your local patches, to rule out the possibility that it's one of your patches, or a bad rebase? <mark_weaver>if that works, you could use "git bisect" to narrow it down to a specific patch <lfam>I just got that error while rebasing an old branch on master. I cleaned-go and am rebuilding now. Will report my results <lfam>ng0: I'm not sure, I've never investigated. Try looking at the package definition of a package that prints that message <frerbst>Hi! So installing GuixSD on my old computer finally worked yesterday, it's pretty nice. Thanks again for your help! <ng0>why is this producing errors: (system* "perldoc" "-oman" "lib/perl5/Net/PSYC.pm" ">" (string-append man3 "/Net::PSYC.3")) <ng0>is the string-append wrong inside system? <mark_weaver>ng0: ">" is a shell meta character, but you are trying to pass it as an argument to the program <lfam>frerbst: Please report bugs :) <mark_weaver>ng0: what you did there is equivalent to if you quoted the ">" in the shell <ng0>i am fixing up a Makefile, i have not talked with the developer about makefile improvements. the makefile is unusable for us. <mark_weaver>ng0: I recommend you use the -d option to perldoc, which sets the destination file. that will be easier. <ng0>oh. okay, i'm new to perldoc <mark_weaver>ng0: I just looked at the perldoc man page. never used it :) <ng0>did you mean (system* "perldoc" "-oman" "lib/perl5/Net/PSYC.pm" "-d" (string-append man3 "/Net::PSYC.3")) ? because this seems to be wrong again <lfam>mark_weaver, jlicht: `make clean-go && make` worked for me <mark_weaver>ng0: it might be that the "lib/perl5/Net/PSYC.pm" needs to go at the end, dunno. what you wrote about should be equivalent to the following command at the shell: perldoc -oman lib/perl5/Net/PSYC.pm -d <man3>/Net::PSYC.3 <ng0>i'll look at perldoc man once more <mark_weaver>ng0: the 'No documentation found for "-d".' error sounds like the options need to precede the non-option arguments. <ng0>i might be just lacking inputs of Pod:: <frerbst>Now, could somebody explain me how to sign commits in git? I don't want to start pushing (or submitting) anything immediatly, but I want to do it the right way from the beginning, so that I don't need to fix anything later. <mark_weaver>ng0: so you probably need to move "lib/perl5/Net/PSYC.pm" to the end <frerbst>According to what I've herd here you have to sign your commits using gpg, right? <ng0>this is illogical to me, but i'll try <mark_weaver>ng0: also, the "no nroffer!?" might indicate that you need to add 'groff' to the native-inputs <lfam>frerbst: Signed commits are only required for people who can push to the central repo in Savannah. They don't affect patches sent to the mailing list. For that case, signing the email can help authenticate you. Apologies if you have commit access and I didn't realize it :) <lfam>In general, to sign commits, you need a PGP key and GnuPG installed. Then, use `git commit --gpg-sign` <mark_weaver>ng0: out of curiosity, why is the upstream makefile unusable for us? <jlicht>lfram, mark_weaver: it worked out after using guix environment with --pure and --container <lfam>Commit signatures can be inspected with `git log --show-signature` and `git verify-commit` <jlicht>so it probably had something to do with some contamination <koosha>I used my Debian's sshd config file for my sshd in guix but it doesn't work . <lfam>Got to clean up that .bashrc! <ng0>I need to fix it, for us the gentoo ebuild has more priority than the makefile, the author recently started to update the makefile. <frerbst>lfam: No, of course I don't have commit access, thanks for the info. ;) <ng0>*us = a gentoo related project <lfam>If you do sign your emails, please upload your public key to the key servers. Otherwise, my mail client spends ~5 seconds looking for the key each time I open your messages. Annoying :) <ng0>the makefile currently makes assumptions and leaves some things out i would need to add in <ng0>so the guix package is more flexible <mark_weaver>ng0: are you aware that it's easy to override any variable in the makefile? <frerbst>lfam: Because I don't have any experiences with GPG (Actually I don't even know what it's for in detail) I maybe won't do that for now. <ng0>you might want to clone it and look at the makefile <ng0>or wait there's a webview <lfam>frerbst: People complain about how complicated it is to learn, but it's not *that* bad. I mean... I learned it ;) <frerbst>I mean signing my emails, not making you wait for 5 seconds each time ;) <ng0>no there is no webview with the makefile. <ng0>torify git clone git://cheettyiapsyciew.onion/perlpsyc <ng0> or git clone git://git.psyced.org/git/perlpsyc <lfam>Especially the latest GnuPG release series, 2.1. It automatically handles a lot of things for you. It requires very little configuation <mark_weaver>ng0: got it, thanks. so, what's the problem? it's easy to override the variables M and D <ng0>when i started the guix package it was worse. but this is no perl makefile anymore.. so i would have to use bot build systems. not a problem, but for example /lib/psyc/ion is still left out <ng0>that only makes the guix package 6 lines smaller or so <lfam>koosha: Are you on GuixSD? <ng0>mark_weaver: I advised the developer to make a new tarball version release once we have fixed together the problem where the application breaks perl <Acou_Bass>erm, slightly dumb question, as guixSD uses LSH instead of openSSH, is there a way to make git clone using lsh instead of the ssh command? XD <lfam>koosha: You probably cannot use your sshd configuration file from Debian on GuixSD. Debian's sshd defaults to OpenSSH, while ours defaults to LSH. <lfam>Currently, we also have a service for the Dropbear SSH implementation. <lfam>I think we all want an OpenSSH service, but nobody has made one yet <lfam>In particular, I would like to be able to put "forced commands" in authorized_keys, and I didn't find that capability in the LSH documentation. <Acou_Bass>i dont use the LSH server (mostly because my guixsd machne is a laptop that i usually SSH INTO things rather than into *it*) XD <ng0>mark_weaver: but i will try the makefile before i set on this method. As i work together with the dev for a while now I'm sure a pull of an improved makefile with minor fixes will work out. <lfam>koosha: Yes, or Dropbear. Or help make an OpenSSH service :) <Acou_Bass>does the openSSH *client* definition at least work? id be happy with that :P <ng0>i use openssh.. it does work. <ng0>if that's what you mean <ng0>i can not rely on lsh for technical reasons. <Acou_Bass>well currently im trying to do git over SSH using the normal ssh://git.mygit.com <lfam>Yes, OpenSSH works find on GuixSD. But, we don't have a GuixSD system service for it <Acou_Bass>suppose i can just install openSSH purely for that :D <ng0>i use the client config of openssh i used on all other systems.. for the one lsh server i have i exclude it from the rest of the config due to the special nature of lsh. <Acou_Bass>th LSH command works great for me for shelling into my remote machines, it took a bit of messing about but it works... just wish i could make git use it to save me installing both <lfam>Acou_Bass: I use git with a GuixSD server. I think it "just worked" <Acou_Bass>git pull ssh://myserversurl/repo just throws up and tells me theres no SSH command :P <lfam>SSH implementations should be interoperable. I think that should work <Acou_Bass>i think its purely because git is expecting to give the 'ssh' command which doesnt exist <ng0>there are some incompabilities. <ng0>but when you have no special config it should have none such <koosha>lfam: I tryed to use lsh-make-see but I got some errors . <ng0>Ciphers+MACs are limited, you do not have the UseRoaming setting, and you do not have (or i did exclude it for annoyance and quick start with lsh) the ability to set KexAlgorithms .. on the client side. <ng0>and ed25519 keys do not work <ng0>i do not know enough about lsh to care to set it up. <mark_weaver>ng0: the main reason why it's preferable to use the upstream makefile than to duplicate it in our own scheme code is that when upstream changes the makefile, we won't need to update our scheme code to match. ideally, updates should not require that kind of work. <ng0>i know and understand that. when i started the package it was a broken, 10 years old Makefile.PL <koosha>lfam: It says that i can't lock file '/var/spool/lsh/yarrow-seed-file.lock' (error = 13): Permission denied . Failed to lock file '/var/spool/lsh/yarrow-seed-file' <lfam>koosha: Did you do it as root? <lfam>Also, the seed should be initialized by default. Did you disable it in your OS configuration? <mark_weaver>in my experience on hydra.gnu.org, yarrow-seed-file is in ~/.lsh/ for each user account <ng0>oh. Example: "perldoc -oLaTeX -dtextwrapdocs.tex Text::Wrap" <mark_weaver>maybe it uses /var/spool/lsh/yarrow-seed-file for the lsh server, dunno <ng0>so different from what i had. <mark_weaver>ng0: oh, does the filename need to be part of the same argument as the "-d", with no space in between? <mark_weaver>if so, you can use (string-append "-d" man3 "/Net::PSYC.3") <ng0>i think so, i tried this possibility now <koosha>lfam: It's not in my configuration file . <lfam>koosha: Did you check the man page for lsh-make-seed? It allows you specify an output file <lfam>But, I don't remember having to do this when I started using LSH <lfam>On my GuixSD, the seed file is in /var/spool/lsh <koosha>lfam: I ran the lshd and it said to me to run this instruction : 'lsh-make-seed /var/spool/lsh/yarrow-seed-file' <lfam>koosha: I recommend using the Guix LSH service instead of running lshd "by hand" <mark_weaver>koosha: if you want to run lshd, I suggest you use our 'lsh-service' instead of initializing and running it manually <ng0>oh. does (system) not create directories when needed? <koosha>Okay , but I read in the guix manuall that I should run the lshd . <koosha>So how should I use the lsh-service ? <mark_weaver>ng0: 'system' and 'system*' just runs a program. it certainly doesn't create any directories before running that program. how would it even know what directories to create? <lfam>koosha: In our Git repo, the file 'doc/os-config-bare-bones.texi' has an example. You can probably omit the #:port-number part unless you want that <lfam>The part of the manual that says "Run the lshd daemon ..." is describing the lsh-service. It's not telling you what to do <lfam>I see know how that imperative language could be confusing <ng0>does it read like you should do what you did? then we should fix it <lfam>I think it's normal to document some code with imperative language. "Copy foo. Check foo's bar. Run foo." <lfam>Easy to find with a search engine :) <lfam>Now you can pass it on to the next person that asks :) <mark_weaver>goes gnome-maps work for anyone? I just launched it for the first time, and I just get a bunch of tiles that say "As of July 11, 2016, direct tile access has been discontinued." :-( <ng0>there was a news on that. <ng0>tl;dr the problem is on GNOMEs side and they should have contacted their tile service. <ng0>it will get fixed eventually. <mark_weaver>I'm surprised they were using mapquest and not openstreetmaps <ng0>well tile servers are not for free <lfam>mark_weaver: Yes, it's a disappointing hiccup. I subscribe to their mailing list and they are working with other tile vendors to create a real solution, with a formal agreement. <lfam>Apparently, even openstreetmap does not provide tiles freely <ng0>they, like everybody else, got the notice in advance for the plan change <lfam>I don't think it's just about the bandwidth, but I'm not sure <mark_weaver>although I'd be happiest with something that renders the tiles locally, to prevent leaking which tiles I'm looking at <ng0>the osm wiki tells you more :) <lfam>mark_weaver: Yes, if that technology existed, it would be ideal. I don't know whether or not it exists <mark_weaver>lfam: the technology certainly exists. there are free offline renderers for openstreetmap data <lfam>I wonder what OsmAND does. That is a very good Android mapping and navigation tool based on openstreetmaps <lfam>Before gnome-maps agreement with mapquest fell apart, I got stuck when GNOME became unusably slow on my machine. It made it really hard to test the package update <mark_weaver>lfam: strange. did you ever discover the cause of the slowdown? <lfam>It's a Thinkpad x200s. GNOME was always a bit sluggish, but at some point it became glacial. <koosha>lfam: After I edited the system config file , what shoud be done ? <lfam>koosha: Then, as root, `guix system reconfigure path/to/config` <lfam>`guix archive --export --recursive foo | pv | ssh server guix archive --import` <-- That is just great! Every time I use it I love it. <jlicht>lfam: it looks like it deploys something from the local store to a remote machine running guix (with a nice progress bar :D). Is that correct? <koosha>lfam: I did it but the lsh-service is not added . <lfam>Yeah, although the progress bar is just extra. The export / import over SSH part is what I love. So great <lfam>koosha: If the reconfigure exited without any errors, you might have to reboot <lfam>koosha: What does `herd status lsh` <lfam>koosha: Actually, it's `herd status ssh-daemon` <koosha>lfam: When I executed the command guix system a lot of lines of strings got printed . <koosha>It's the part for services : (services (cons* (%desktop-services) <koosha>(lsh-service #:port-number 2222))) <lfam>Yes, did it finish successfully, or did it fail? <lfam>It will tell you if it fails, you don't have to check $? <koosha>I didn't attention to that . let me run it again . <lfam>At the end, it will tell you if it worked or not <lfam>If it worked, but there is no SSH service, then I think you should reboot. The system still needs to be rebooted for some changes <lfam>Does what need root access? <lfam>That's because it affects the entire system, and all the users <lfam>At least, `guix system build` and `guix system reconfigure`. Some of the other sub-commands don't need root <koosha>I can't find out it was successful or not . Just some weird strings . <lfam>Actually, I don't know whether or not `guix system build` needs root. But reconfigure does need root. <lfam>Can you paste the messages? <koosha>lfam: How can I do that with CLI ? <lfam>I don't know... It sounds like something is wrong with your configuration file. Can you rsync it to another machine and paste that? <mark_weaver>I'm actually in the habit of running "guix system build" as my normal user, and only later running "guix system reconfigure" as root, so it has much less work to do <lfam>It's a good idea to minimize the exposure of the root user <lfam>koosha: I saw above that you pasted the (services ...) section. I think it's backwards. Try this: <lfam>(services (cons* (lsh-service #:port-number 2222) (%desktop-services))) <lfam>No, my example is wrong. Just copy the example from os-config-bare-bones.texi <koosha>Is it differend ? :D I don't know Scheme . <lfam>But, replace %base-services with %desktop-services <koosha>It says : Unbound varible: lsh-service <lfam>koosha: Do you see in os-config-bare-bones.texi the line '(use-service-modules networking ssh)'? <lfam>You need to import the ssh service module using a line like that <koosha>Oh , god . Yes , I missed that . Sorry . <lfam>Please share your configuration file <koosha>lfam: ;; This is an operating system configuration template <koosha>;; for a "desktop" setup without full-blown desktop <koosha>(use-modules (gnu) (gnu system nss)) <koosha>(use-service-modules desktop networking ssh) <koosha>(use-package-modules gnustep certs) <koosha> ;; Assuming /dev/sdX is the target hard disk, and "my-root" <koosha> ;; is the label of the target root file system. <koosha> (bootloader (grub-configuration (device "/dev/sda"))) <koosha> (file-systems (cons (file-system <koosha> (supplementary-groups '("wheel" "netdev" <koosha> (home-directory "/home/koosha")) <koosha> ;; Add a bunch of window managers; we can choose one at <lfam>koosha: I meant, put it on a paste site <koosha> (packages (cons* windowmaker ;window managers <koosha> ;; Use the "desktop" services, which include the X11 <koosha> ;; log-in service, networking with Wicd, and more. <koosha> (services (cons* (lsh-service #:port-number 2222) <koosha> ;; Allow resolution of '.local' host names with mDNS. <koosha> (name-service-switch %mdns-host-lookup-nss)) <koosha>I just wanted to paste the addrees . <koosha>lfam: Yes , I just made a mistake and pasted the wrong case . <lfam>koosha: Please send a message to help-guix@gnu.org. I think that will be easier <koosha>lfam: I sent the address that I pasted . <koosha>Thank you for your help , It was exhuasting . <lfam>koosha: I think the only thing you need to change is to change '(%desktop-services)' to '%deskstop-services'. <lfam>I made a spelling mistake in %deskstop-services. Careful not to repeat it <koosha>lfam: I think it was because of that I didn't run the guix pull . Now I thing It's working . It's not finished yet . <koosha>lfam: Thank you so much , you spent so much time . <efraim>it looks like offlineimap bundles libimap2 <lfam>koosha: Is it working now? <lfam>efraim: Does anything else use libimap2? <lfam>I can hardly find anything about libimap2 online <efraim>according to debian offlineimap is the only program that uses it <lfam>Okay, fingers crossed! Otherwise, to help-guix@gnu.org :) <koosha>lfam: Okay , but what's wrong with here ? <lfam>koosha: When a problem looks like it's going to take a while, it's easier to do over email. For me, anyways <ng0> https://ptpb.pw/L06U.scm i think since i did set this system up i made changes which weren't moved into version control.. i do not get why this fails with some error at swap-devices