<ng0>hm.. what was this new option ludovic added last month? sysadmin or something? I can#t find it <Drakonis>which file systems are recommended right now? <Drakonis>are there any workarounds for efi support? <rekado>the number of failed packages on hydra was larger than usual because texlive had been marked as failed on armhf. I restarted it and a couple of dependent packages. Looks better now. <rekado>(we also had a couple of failed ghc-* packages, but they had actually succeeded.) ***[0xAA] is now known as Zer0Pings
***NoJoke is now known as Zer0Pings
***Digitteknohippie is now known as Digit
<_myglc2>hello guix! Any python hackers out there? <civodul>somehow Gnus now hangs on many messages written by you htgoebel <civodul>i never had problems displaying mixed HTML messages so far <_myglc2>janneke: looking for basic python/emacs/GuixSD guidance. Have python and python-pip installed. Anything else? <_myglc2>janneke: janneke: ... Any other packages you recommend for a basic emacs-centric setup? <_myglc2>janneke: trying to run basic GuixSD packaged SW as much as possible. <dvc>civodul: thanks for your feedback on the rust patches. I've made a lot of changes and it needs some redesign before I resubmit. As they stand now they probably aren't particularly useful yet. <civodul>maybe we could still get rustc-bootstrap at least <civodul>i suppose this one isn't going to change significantly? <avoine>_myglc2: that would be my list : python-flake8 python-virtualenv python-tox python-nose2 python2-jedi python-jsonrpclib <avoine>_myglc2: are you doing web with django or just python? <dvc>the version might - currently it's using beta, it should use the stable release. In my version I'm using nightly. It depends on which version of rustc makes it into master, I haven't worked on that yet. <avoine>also you need service_factory from pypi do get the anaconda-mode to work <_myglc2>avoine: Many thanks. no django. Just trying to get scrapy.org to work right now. <rekado>civodul: I have no problems displaying htgoebel's mails (with mu4e). <avoine>_myglc2: ok, this is all python3, use python2-... to get the older version <htgoebel>_myglc2: So you just need whatever scrapy requires ***[0xAA] is now known as Agent170
<_myglc2>htgoebel: Thanks. Have used GuixSD 6 mo but I am python noob. Trying to inflate basic GuixSD python space suit. <htgoebel>_myglc2: Python on GuixSD is not different then on any other Linux distribution. ***[0xAA] is now known as Agent170
***[0xAA] is now known as Agent170
<_myglc2>htgoebel: Thanks. "Python on GuixSD is not different..." is conceptually true. But given that GuixSD package "coverage" is less I want the most well-worn path for my emacs python envionment ;-) <amz3>except you need to use "pip install --user" instead of "sudo pip install" which better anyway <amz3>you don't need virtualenv if you get started <amz3>but that's a topic for #python not #guix <amz3>htgoebel: the only thing you need to know is wether you want to use python3 or python2 and install the associated pip <amz3>htgoebel: sorry I mean to highlight _myglc2 <amz3>_myglc2: but IMHO you'd rather learn Guile, Python threading model is broken and so many other things are broken ;) <htgoebel>amz: Your mileage may vary. Guile suffers "batteries included". But this is a topic for alt.religion.programminglanguages <rekado>_myglc2: I'd like to suggest to only install packages via Guix including all Python stuff. <rekado>you can avoid a lot of headache by using Guix. Then you won't even have to learn how to use virtualenv as you have "guix environment" <rekado>Python packages that are not yet in Guix are always welcome additions <_myglc2>amz3: Looked first for a guile web scraper but didn't find any thing encouraging. <_myglc2>rekado: Thats why I am trying to find a minimal set w/in Guix. Unfortunately scrapy seems like a hairball. <_myglc2>amz3: you said "... and install the associated pip". Don't understand what you mean. python.scm only has one python-pip doesn't it? <amz3>_myglc2: it's python-pip then, in debian there pip2 and pip3... <_myglc2>rekado: You said "I'd like to suggest to only install packages via Guix". Believe me I prefer this. My experience w/ Guix packages is excellent. But in this case I just want to smoke-test scrapy. I hit a problem getting it installed on Guix so I switched to a Debian server & did 'apt-get install python-scrapy' ... doesn't work there either. Arg! <_myglc2>htgoebel: what do you mean "Guile suffers "batteries included"."? <asumu>Heyo. I was considering running Guix SD on my laptop. Was just wondering if anyone else has tried it on a 4th gen thinkpad X1. Or maybe I should run guix on top of another GNU/Linux? <ZombieChicken>asumu: As long as you don't need encrypted root or LVM support, I think you're okay <wingo>i run guixsd on a 3rd gen thinkpad x1 <wingo>guixsd uses the linux-libre kernel, meaning that for wifi you will need a usb adaptor or something; i run the upstream linux kernel and install the nonfree firmware <wingo>which is unsatisfying in a way. <wingo>also i've never tried bluetooth <wingo>otherwise i have no issue besides the things that aren't yet packaged like cups, but that set is diminishing <wingo>ACTION was going to package cups today but didn't get a round tuit <wingo>ACTION was speaking sloppily :) <asumu>ZombieChicken: Ah, I see. I do usually use LVM, but honestly I probably don't need it on a laptop. And if I can encrypt /home that is probably sufficient. <ZombieChicken>wingo: There used to be a convention that had a booth that sold those. They were little grippy rubber disk with "Round Tuit" printed on blue on it <ZombieChicken>asumu: I don't know about eCryptFS support atm, and I think quota will likely work as a good (and probably better) LVM replacement <wingo>ACTION wishes he understood encrypted disk things <asumu>wingo: cool, did you just compile the upstream kernel yourself? (haven't done that since my gentoo days maybe) <wingo>ZombieChicken: how it all works ;) have to make mental space for it <wingo>asumu: yeah i have a package that derives from the linux-libre package and just replaces the source form <wingo>so when i build the system it ends up compiling the kernel, yeah ;) <asumu>Ah ok, that doesn't sound too hard. Yeah the 4th gen also has an intel wifi chip so I guess I will need to do that. <wingo>the whole situation with intel and the ME is distressing <asumu>Yeah, a RISCV laptop would be really great to get around this stuff. <ZombieChicken>I havn't messed with it myself (need the money to buy it), but it looks like a more-or-less ideal option <ZombieChicken>From what I understand, RISC-V isn't there yet. It's missing too much <ZombieChicken>POWER8 (OpenPower) and ARM are our best options at this time, I think <ZombieChicken>I think I kind of hate Scheme/Guile atm. The code is a bit hard to understand <wingo>if you manage to figure out why you feel that way and write it up, that can be useful i guess, and at least polemic and entertaining :) <ng0>I'm not sure if, but I think i was just told to not use Guix because it's beta and report a real bug (which was guix related).. I'm still waiting for further feedback though <ng0>i followed the previous discussion. novena is arm architecture, right? <ng0>currently too expensive for me to invest in <ng0>as long as I'm not sure i don't want to attract any attention to it, but it would not be hard to find my bugreports. <ng0>so it's arm, and what else? just for building there should be no difference between asus c201 or what it was and novena, right? or is it a specific version/subset of arm? <ng0>I know most of the story around novena, but what reason for someone just building software is there compared to other arms? do they construct something differently? <ZombieChicken>I just posted a link to the article pointing out Intel's ME system and Novenu as an alternative and hopefully sane option <ng0>I'm affraid it's not just post 2009.. it's at least post 2001 or somewhere waround that time. I had a discussion about this earlier this year. <ZombieChicken>Hmm. Apparently my desktop isn't affected by that little security nightmare. My old AMD system is just too old <ZombieChicken>ng0: According to a discussion I had with someone in another chat, it varies between chipsets. Post-'09 seems like the point where it was standard. Prior to that you could get a system without ME on it <ng0>i don't see how the earlier link relates to my novena question. i know about the ME problems <ng0>okay, what I meant is not just ME. bugs by production and contracts etc got opened way earlier. but for ME you are right <ZombieChicken>Nothing about Novena should be special. It's just a Freescale ARM8, i think <ng0>if I wasn't polite, I would have answered 'who the hell packages and uses lispf4 anyway?' but I am polite so I won't :) <ZombieChicken>He apparently has no userbase, so I'm wondering why you're even trying to package it <rekado>ng0: I’m sorry, I don’t understand this sentence: “i was just told to not use Guix because it's beta and report a real bug (which was guix related)..” <rekado>what does “and report a real bug (which was guix related)..” mean? <rekado>is this “i was told … to report a real bug”? <rekado>ah, parsing it like this makes sense. Never mind :) <ng0>my interpretation of frustration over trying to bring this over 7 months old conversation back to life. <ZombieChicken>Apparently the maintainer of the package doesn't care because A) The word "beta" is used, and B) It works for him <ng0>*s/my interpretation// <ng0>and i try to care for a software no other distro cares for. <ng0>just to solve this bug, improve it. <ng0>but it doesn't seem to get through <rekado>this bug looks like a search path issue. <ZombieChicken>From what I've seen, his reponse is fine, although he isn't being helpful in the least <ng0>yes.. but i can't create the patch, that language is not my field of expertise <ZombieChicken>ng0: Then drop the package, close the related a WONTFIX and move on <ZombieChicken>after saying you can't patch it yourself, and upstream doesn't care <mechanical>I'm presumably finished with writing a package definition, but I'm unable to figure out how to place it in the proper location for guix build to use. I would appreciate some guidance with this. <ng0>that's my last attempt before I do so.. in 7 months no one came forward.. but, but we have much older bugs. <ng0>however those are not packages <ZombieChicken>ng0: If a bug is unfixable, a bug is unfixable. I don't think anyone will miss his package <ng0>well i have this book where i needed interlisp :D but I think i can use it just from my users home.. <mechanical>Out of curiosity, what's the issue with this interlisp package? <rekado>ng0: looks like it would work if you ran the interpreter inside the bin directory <ng0>building in home works out okay, building the guix package i created and it does not find its SYSATOMS file <ng0>but it is in the bin directory.. or do you mean /bin ? <rekado>no, I mean: your current working directory has to be the package’s $out/bin directory <ng0>the standrd output is thrwoing all in $out/bin <rekado>this thing may be looking for sysatoms in the current directory <ng0>yeah i have looked at this back then, but ... fortran. <rekado>so to fix this you’d need to make Guix patch out NAME='SYSATOMS' <ng0>remove this in the line, that's all? <rekado>and instead do (string-append "NAME='" (assoc-ref outputs "out") "/SYSATOMS'") <ng0>oh.. i think that could work. you know when you stare too long into the abyss.. <rekado>if that fails and “OPEN” doesn’t deal with directories you’d have to change more. <ng0>thanks, i'll create a patch and test it <rekado>Can’t guarantee it will work, but that’s the kind of thing we usually do. <rekado>first check if it works after cd’ing into the $out/bin directory <ZombieChicken>Digit: Pretty sure that is doable with a touch-screen-friendly GUI <ng0>there are pieces of sailfish to pick up and improve on what they fail at. <ZombieChicken>Given how bloated Android is, I think you could almost install Window 10 on them and it would still run reasonably well <ng0>and of course hardware issues to address <rekado>does anyone here know of good software to make real phone calls on a regular computer with a cell phone modem? <ng0>hardware production is hell expensive <ng0>look at the price of neo900.. and they just add to old pieces <mechanical>So, not trying to be a bother, but I was unable to find the solution to my problem in the documentation. I've what I believe will be a working package definition, but I'm unable to attempt to build it. I'm rather stuck. <rekado>my x200s comes with a GPRS modem card and since I never use my phone anyway I put my SIM card into the modem. <ng0>mechanical: what's the problem? <rekado>can get online whereever there’s a cell signal <rekado>but I’d like to make actual phone calls from time to time. <mechanical>From the documentation: Once a package definition is in place, stored in a file in the Guix source tree, it can be tested using the guix build command <ng0>what's the application you packaged? <ng0>or first of all, you have it in the guix git checkout? <mechanical>I'm trying to package gforth. I've wanted it for quite the while, but was lazy and thought someone else would do it. <rekado>mechanical: do you have a copy of the Guix source tree? <ng0>huh? that's already packaged afaik <rekado>mechanical: then you should get a copy of the Guix source tree first :) <ng0>as far as i know i packaged gforth, and need to send in colorforth, but time rerstrains <ng0>sorry for getting in your way :/ <ng0>well, i did some work and then it was picked up <mechanical>I need to learn how to package anyways. There's a more obscure package I also want. <ng0>what's it name? I keep a large, sad collection of work-in-progress <ng0>ocassionally i email-bomb the mailinglist with it :) <rekado>mechanical: are you somewhat familiar with git? <mechanical>I'm not at all familiar with any version control system, rekado. <rekado>mechanical: I think StumpWM has actually just been packaged. I saw patches on the ML. <ng0>well actually i think the price of neo900 is reasonable if you consider fair wages etc.. even the price of the fairphone is not affordable for me, but reasonable. <mechanical>That's one part of the documentation I'd actually not read yet. <mechanical>I'll come back when I'm finished reading it. I don't want to waste your time. <ng0>there are no dumb questiosn, we all have to start somewhere :) <ng0>i mean, ask what you like or is unclear in the docs <mechanical>I suppose it's funny that I've been using GuixSD for several months and still don't know much of it. <rekado>mechanical: Under “Project Management” it says that we keep our code on Savannah. <rekado>there it says that you can get a copy of the sources by running this command: “git clone git://git.savannah.gnu.org/guix.git” <rekado>for that to work you need to have git. Since you are using GuixSD it’s easy to get it: “guix package -i git” <rekado>git can be very confusing, but usually you don’t have to know much about it to use it. <rekado>“git clone” gets you a copy of some repository <rekado>you only run this once and then update your copy of the repository <rekado>once you have the sources I suggest you follow the instructions here to build Guix: <ng0>come to think of lispf4.. i will try this, but i think the added problem is that it doesn't use the fortran sources. <rekado>mechanical: any changes you make to the sources can be tested like this <rekado>mechanical: to add a new package definition you’d edit a file in ./gnu/packages/ <rekado>each file holds one module. A module holds many variable definitions, each of which is bound to one package expression. <ng0>but i think i can apply the same to the C file. <rekado>mechanical: you would then define a new variable and bind it to your new package expression. <rekado>we use “(define-public …)” to make the variable visible outside of the scope of the module. <rekado>(with just “(define …)” the package would only be visible inside the module) <rekado>when you’re done with your changes you can select them to “record” your changes in your copy of the repository. <rekado>in git parlance selecting changes is done with “git add -p” and recording changes is done with “git commit” <rekado>the former asks you for each “hunk” whether you want to select it for the next commit. The latter prompts you for a description of your changes. <mechanical>So, what I'm doing is creating a local Guix that I can modify freely, which includes modifying the package definitions and whatnot, right? <rekado>when you’re satisfied with your changes you can format selected commits as a patch (or a series of patches). <rekado>one commit maps to one patch file. <rekado>to format the last commit as a patch you’d do “git format-patch -1” <mechanical>Is there any technical reason why one can't use guix build with arbitrary package definitions without doing this? <rekado>I assumed you want your package definition to become part of Guix upstream. <rekado>if all you want is use a private collection of package definitions that’s also possible. <mechanical>My main issue was being unable to have guix build accept what I wrote. <rekado>you have a directory containing files, each of which holds a single module. <rekado>each module contains one or more package definitions bound to variable names. <rekado>then you set the environment variable GUIX_PACKAGE_PATH to point to the root of this directory. <rekado>you may have a file “mechanical.scm”, which is located in ~/dev/custom-guix-stuff. <rekado>the module name inside “mechanical.scm” is “(mechanical)” <rekado>then GUIX_PACKAGE_PATH should point to ~/dev/custom-guix-stuff <rekado>your packages will then be available in Guix <rekado>i.e. “guix build” and “guix package” will find them by name <ng0>and if it is in my/awesome/package.scm it is (my awesome package) :) <rekado>yes, what ng0 says is important. A Guile module’s name is directly mapped to its path from a given root directory. <mechanical>It's my understanding that I should be able to contribute packages without needing the entire git repository. I should be able to create diffs of the relevant files and send those manually, or is this considered to be in poor form? <rekado>mechanical: that’s not so good for at least two reasons. <rekado>the first is that new modules also need to be registered in gnu/local.mk <rekado>your manual diffs wouldn’t include those changes. <rekado>secondly, with patches formatted via “git format-patch” we also get a little extra info like the committer name and the time of the change. It’s very convenient for us to apply patches like that. <mechanical>I'll keep all of this in mind when I contribute a package. Thanks again. Goodbye for now. <ng0>while I'm at it, should I delete the included Windows and Mac prebuild binaries directories in LISPF4? <ng0>as far as I'm concerned we don't even need the Unix one. <rekado>ng0: removing prebuilt stuff in a snippet is good. <ng0>yes, i'm at it.. but still no progress with sysatoms. <rekado>does it work when running inside of $out/bin? <ng0>I'll give it today, a couple more tries.. and if I can't fix it,I'll send a patch to drop it entirely. <ng0>It works now when run inside out/bin <ng0>i have a different error now, when patching <ng0>need to fix the deletion first <ng0>I'm afraid it would be easier to run f2c again...but i don#t know. just replacing all occurences of SYSATOMS in lispf42.c did not work (string too long etc) <ng0>lispf42.c:109:2: warning: initializer-string for array of chars is too long i know this won't work, but i have not looked at the code in a long time. <ng0>i think i also have to adjust the description.. the porting author added functionalities the original implementation did not have, it's not a straight f2c -> done thing. <rekado>you also need to change 8+1 to the length of the target bin directory + 8+1 <ng0>oh.. i assumed there was a meaning in this, but I've never went beyond hello world writing in C <ng0>our hash length is fixed, correct? <ng0>eh.. yes. sorry. stupid question <rekado>or you could ignore this and define “c_b98” <rekado>seems that it’s only used to hold the name of SYSATOMS and c_b98_st.val is used nowhere else <rekado>I must say, though, that this really *looks* like it was automatically converted. <rekado>does this really count as source code…? <ng0>well some bits here and there added.. timefunction etc <ng0>or brought from 80s land to today <rekado>yeah, but the code is hardly readable <rekado>*(unsigned char *)&ch__1[0] = iqqq[i__ - 1] % 256; <rekado>no human would write code like this <rekado>(with the exception of underhanded C contestants) <ng0>that was my first impression too. although i don't know any fortran. :D <ng0>but usually i can asume what C does.. with this... 'wat?' <ng0>I want this fixed for personal satisfactory... it is broken. i want it fixed. to close this bug, because it can't be THAT hard <ng0>hm.. okay i fix up the c_b98 the wrong way. how would you go ahead and replace parts? <rekado>I don’t understand. You could either use a build phase or write a patch. <ng0>okay, that's not what I mean. my build phase fails. It's probably best I sent the current state to the list so you can take a look <rekado>since 8c82e1c9d3b31f326a747a420282f7eedeb92100 GSL fails its tests on i686 :(