IRC channel logs


back to list of logs

<ng0>hm.. what was this new option ludovic added last month? sysadmin or something? I can#t find it
<Drakonis>i got the usb image to work
<Drakonis>except it only works with 0.10.0
<Drakonis>0.11.0 doesn't work
<Drakonis>time to get to town
<Drakonis>which file systems are recommended right now?
<Drakonis>is btrfs recommended?
<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.)
<civodul>Hello Guix!
***[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?
<janneke>_myglc2: possibly, why?
<civodul>somehow Gnus now hangs on many messages written by you htgoebel
<civodul>but not all
<civodul>not sure why
<civodul>does anyone else experience this?
<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>dvc: okay, your call!
<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
<avoine>_myglc2: this is a great start:
<_myglc2>avoine: Many thanks. no django. Just trying to get 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
<htgoebel>_myglc2: You may want to have a look at the upcoming Pyhton packaging tipps:
***[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: So you may be interested in
<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 ;-)
<htgoebel>_myglc2: Since you called yourself a "python noob", I recommend reading about pip and virtualenv, e.g. at
<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
<davexunit>batteries included is good!
<_myglc2>amz3: np, i'm notmally myglc2
<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>amz3: sorry about the misdirect
<_myglc2>rekado: Thats why I am trying to find a minimal set w/in Guix. Unfortunately scrapy seems like a hairball.
<_myglc2>htgoebel: np, I'm normally myglc2
<_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"."?
<_myglc2>amz3: Thanks!
<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
<davexunit>don't we already have a cups package
<wingo>i think you need a service
<wingo>ACTION was speaking sloppily :)
<wingo>service, not package.
<davexunit>ah okay!
<davexunit>makes sense now :)
<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
<ZombieChicken>for some uses cases, anyways
<wingo>ACTION wishes he understood encrypted disk things
<ZombieChicken>What don't you understand?
<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 ;)
<ZombieChicken>wingo: Ah, ok
<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.
<ZombieChicken>on the topic of Intel systems:
<wingo>yeah :/
<wingo>the whole situation with intel and the ME is distressing
<ZombieChicken>and on a somewhat related note;
<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>s/POWER8 (OpenPower)/POWER8\\/OpenPower
<ZombieChicken>I think I kind of hate Scheme/Guile atm. The code is a bit hard to understand
<ZombieChicken>Waking up and getting right into it doesn't help, either
<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
<ZombieChicken>yes, it's ARM
<ZombieChicken>and yes, it's expensive
<ZombieChicken>550 for just the mobo
<ZombieChicken>ng0: Who told you that?
<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
<ZombieChicken>that wasn't outdated hardware
<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
<ZombieChicken>or ARM9. I'd have to look
<ng0>so different from cortex-a17
<ZombieChicken>Freescale iMX6 CPU
<ZombieChicken>Quad-core Cortex A9 CPU with NEON FPU @ 1.2 GHz
<ZombieChicken>^ That is what novenu uses
<ng0> so i read this as 'works for me.. wont fix' and if it is, we should drop lispf4 as it is permanently broken and no upstream support will happen. the word to stress right now is *if*
<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 :)
<ng0>ah, thanks
<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
<rekado>have you tried that?
<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
<rekado>to fix this you may have to patch this line:
<ng0>the standrd output is thrwoing all in $out/bin
<rekado>no, I’m saying at *runtime*
<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'")
<rekado>but that’s untested.
<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.
<Digit>siesta'd my way through leaving mpv playing guixsd youtube search, and thnx to conversations and searches before my siesta, i awake wondering... guix on phone? :) someday... someday... ;)
<rekado>first check if it works after cd’ing into the $out/bin directory
<mechanical>Fingers crossed, and all of that.
<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
<ZombieChicken>I'm just waiting for an open cellphone to pop up
<ZombieChicken>which I'm expecting sometime after Hell freezes over
<ng0>next 10 - 30 years.
<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
<mechanical>I don't know how to do this, ng0.
<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
<ng0>didn't i do that?
<rekado>mechanical: then you should get a copy of the Guix source tree first :)
<mechanical>Are you certain?
<mechanical>Alright, rekado.
<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>oh, okay
<rekado>I can guide you.
<mechanical>Also, I'm wanting to package StumpWM, ng0.
<rekado>mechanical: I think StumpWM has actually just been packaged. I saw patches on the ML.
<rekado>mechanical: let’s start here:
<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>the link goes here:
<rekado>there it says that you can get a copy of the sources by running this command: “git clone 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”
<mechanical>I already have git.
<mechanical>Well, now I'll wait for that to finish.
<rekado>git can be very confusing, but usually you don’t have to know much about it to use it.
<mechanical>Isn't that one reason it's called git?
<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: after that you can run your development version of Guix:
<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>mechanical: correct
<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>oh, that’s possible too.
<rekado>I assumed you want your package definition to become part of Guix upstream.
<mechanical>Well, I suppose.
<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.
<ng0>like in this soon to be removed repository here:
<rekado>the basics are the same
<ng0>yep :)
<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.
<mechanical>That's what I'd missed, apparently.
<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
<mechanical>Thank you for your help, rekado.
<ng0>and if it is in my/awesome/package.scm it is (my awesome package) :)
<rekado>mechanical: no problem!
<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/
<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>but we also had this
<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.
<ng0>or fixed it..
<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)
<rekado>the fortran code is much more readable:
<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 :(