<drakonis>esp the "making things easier" department <ZombieChicken>Honestly, I think Gentoo's lack of a live system kind of works in it's favor in an odd way <ng0>Secushare needs to get 'out there' somehow when it's usable. initially i wanted to contribute code, and I still intend to, but this is much more useful currently <drakonis>it only needs to update the images to support more hardware from time to time <drakonis>as portage itself handles system updating <ZombieChicken>Someone will have to explain to me why things like Facebook even matter first <drakonis>i wonder when someone's gonna make a nix importer worth its salt <drakonis>ZombieChicken: because people like sharing their lives with everyone in the world <ng0>yes, but even more than that. it's difficult and goes very much offtopic for this channel :) if you are interested, there's a channel at the bottom of the page listed <ZombieChicken>You mean importing Nix packages into Guix? i thought there is one <drakonis>really unavoidable, but who am i to judge. <drakonis>it isn't able to deal with all the little things nix does <ng0>facebook, google, banking system, ebay, amazon, all of the current web. <ng0>it's a 20 - 30 years goal including laws etc (different project).. secushare will be usable before that though. <ng0>how to wrestle the giants and bring back democracy to the internet :) <ZombieChicken>It won't happen on any large scale without some massive social upheval or people learning about some extremely nefarious something-or-other from The Powers that Be right now <ng0>depends on your view. my view of democracy is the definition which anarcho-syndicalism holds.. but that is just me, not the project. <ng0>but as i said, this is going way offtopic :) <drakonis>i was about to say something that would completely derail it <ZombieChicken>ng0: It's helping me not bash my brains out trying to sort through Guix code <drakonis>i want to figure out how to modify the boot image <ZombieChicken>I'm hoping there is a plan to move the package tree out of the package manager and into someplace sane <drakonis>and boyyyyy it can get terrible down there <ZombieChicken>Doesn't make any sense to me to have the packages and the package manager all clumped up into one big package <ng0>why would you separate them? <ZombieChicken>ng0: So you can update the package tree without having to update a known-working package manager? <ZombieChicken>I've seen python updates break Portage and almost render a system unusable <ZombieChicken>and I've seen "only one package version in tree at a time" cause problems outside of the package manager <ng0>we have multpile versions in some places <ng0>and if you need more, there is GUIX_PACKAGE_PATH or what it was <ng0>i find this rather flexible <ng0>me is afk below the desk <ZombieChicken>drakonis: Portage sucks, blows, and all for cheap, but Gentoo has been my standard distro for a long time now. Nothing else seems as reasonable imo <drakonis>and there's exherbo, but the person who runs that is a tool <ZombieChicken>but then they started to merge breaking updates and I dropped it <ng0>gentoo is easier to maintain when you just have to worry about one or multiple VMs which hold them. <ng0>at 6+ gentoo computers i gave up after years and switched to guixsd :) <ZombieChicken>ng0: I'm looking at GuixSD myself, but right now I'm trying to figure out full disk encryption with it <adfeno>drakonis: What's the issue with the Linux-libre kernel? <drakonis>how would i find you after figuring out how to build a linux kernel and all of its firmware <ZombieChicken>guix system init doesn't like / coming from /dev/mapper/disk <adfeno>Which hardware is giving problems? <drakonis>having some trouble getting to the initial terminal <ng0>wow. old computer number 1 is still alive. hopefully the 17 years old i686 is the same <adfeno>Did you try shuting it down and using another system to inspect the logs? <drakonis>i am also unable to reach other terminals <adfeno>drakonis: You can either use a live system, or an already installed one <ng0>toshiba.. is graphics or what toshiba hardware is this? <ZombieChicken>ng0: Are you familiar enough with the Guix code to point out where guix system init is handled? <drakonis>i have a custom computer running nvidia's maxwell and intel's haswell <adfeno>drakonis: But either way, thy working system has to have access to the disk device of the failing system. <ng0>not yet. but as per command: guix/system/ <drakonis>so i can actually start the installation <adfeno>So you didn't start the installation yet? <ng0>i hope i'm able to find a PSU for this old board.. <ng0>there's everything onboard but no onboard ethernet :( .. i hope wifi will just do it, so i don't need a case for this <ng0>so i can testbuild i686 for guix soon :) <Drakonis_>it stops when it tries loading fujitsu's network drivers <Drakonis_>a important question, when's ebuilds support :V <ng0>write the portage importer ;) it's on my list circa 2019 or later xD <ng0>learning guix packages is fun and easy :) <adfeno>We have importers for almost all package types as of today. <ng0>portage is non-free so it will not happen, but it'll be cool, because of tons of packages. <ng0>but challeging, guess it'll be easier to just create from scratch. <ng0>sure, but it's not just about that. <adfeno>What isn't easy in the packaging process is figuring out how the program and instalation will or should bahave. <adfeno>↑ but that's because we replace somethings to allow Guix's main functionallity to work as expected. <adfeno>So the amount of work pays off very nicely. :) <Drakonis_>anyhow, is there a way to disable loading these drivers? <adfeno>ng0: It's the first time I'm ever hearing about Portage, so I'm a bit new to it. <ZombieChicken>Gentoo ebuilds tend to be a bit patch-happy, they tend to use sed to 'patch' things in ebuilds without actually patching anything, they use a library of shellscript functions (which aren't exactly sourced in the ebuilds) which might be a little rough to migrate about... <ng0>multiple issues. in addition to the portage issues when you do package for gentoo itself. <Drakonis_>portage was one of the earlier source package managers <ng0>EAPIs are said to be changed every 2 years, but eclasses chnage more often, other standards too, and it is just annoying to keep up with it. <ng0>etc yada bla.. i don't want to rant about my portgae feelings. <adfeno>Let's see if I get it straight... <ng0>tl;dr: don't do it unless you like pain. <adfeno>... They are "patch happy" in the sense that the source files distributed by them isn't the one distributed to the user? <ZombieChicken>It's a moving target that morphs it's shape /and/ is run by a bunch of power-hungry devs with no real care for the using classes <ZombieChicken>Drakonis_: /it all/almost all of it/ Some bins are supplied for packages like Firefox <ng0>debugging is like, let me assemble my armada of gentoo vms for this problem :) i had 20 at the end. <Drakonis_>the one thing that would be good to import from gentoo is its use flags :V <ZombieChicken>Except that makes it painful for people to be able to check each other's work <ZombieChicken>and every USE flag makes it exponentially harder to check each possible combination <ng0>that was my process while i brought the gnunet ebuilds in the 1 year to where they are now. <adfeno>I see, so it's a matter of being able to check each others work <ng0>thing X could leak into thing Y and that... and so on <ZombieChicken>That said, I'd like to see a scaled down system where a user can say "I don't want KDE installed", and nothing would pull in a KDE dep. Just enough to avoid massive dependency trees that one may not want <adfeno>ZombieChicken: You can do it with Guix, sort of, actually. <Drakonis_>many of gentoo's users seriously prop it up as a really big thing <ZombieChicken>Drakonis_: For us, it is. It's one of the reasons some of us don't use bin distros <ng0>while no one needs that unless you really build a system for redistribution or some super customized hardware. <ZombieChicken>ng0: For me it was a way to avoid pulling in libkitchensink every time I wanted to merge some small package. It's annoying as hell to merge all of Gnome because you want one package that has an optional dep on Gnome, but someone decided to require it <ng0>speaking of pain.. how are eabis or what they are called constructed on guix? I paused with uclibc-ng packaging, but this is one problem I have. I'd continue packaging it in late 2017 and very low priority while i do the other things <adfeno>drakonis Perhaps we must report bug to Linux-libre while we gather info on how to at least work around the freezing inssue. <ng0>upstream linux-libre? <drakonis>by the way, i have a big question, i suppose <ng0>fsfla has the linux-libre page.. there should be information provided. <ng0>I don't know myself. <drakonis>no, actually, i have the answer for my question <drakonis>might have to get upstream grub for efi support, but <drakonis>the question though, how do i calculate the sha hash <ng0>or what kind of hash? <ng0>guix hash -r -x for an repository checkout <ng0>otherwise no -x when there is no .svn, .git, etc <adfeno>drakonis: About udev and skipping module... <adfeno>Guix is package manager, can be installed in any GNU distro. <ng0>that's something left for others to answer <adfeno>So, about udev and skipping modules, there must be a boot option that can be passed to skip certain modules.... <adfeno>Although I'm not familiar with such level of configuration. <ng0>lfam: you started working on krita? damn.. okay. I need to check what I have in my wip branch which can be put to use.. i am working on krita as well. <adfeno>Do any of you know how to disable wireless modules loading before starting GuixSD from live media? <ng0>hours too late. i'll reply on the list <ng0>lfam: i've seen your work towards krita patch.. i'll check my krita-branch and submit the patches. <lfam>ng0: Oh cool! I didn't know anyone else was working on it <lfam>Did you build opencolorio successfully? <ng0>i think i have some works whic hcolide.. <ng0>like pixar USD, opencolorio, nvidia-texturetools, 0ad, all share dpeendencies somehow <ng0>i don't know, need to revisit <lfam>I tried to build opencolorio on my commute yesterday, but I didn't finish <ng0>hm.... i have to search the right repo <adfeno>drakonis: Do you have wireless on/off switch? <ng0>it could be that I am not working on it yet / currently, but i have some packages which were in the graph.. <lfam>The change being that we pass -ffloat-store to CFLAGS and CXXFLAGS <ng0>now to locate the local repo.. :D <adfeno>dranonis, so "atheros" is what in this context? <lfam>BTW, ng0, I think the curl / gnurl discussion is relevant to the Darcs HTTPS problem <ng0>probably,yes.. like i said, i'll make changes to gnurl with the next version release :) <ng0>drakonis: no, it's just packaging for pixar's USD <lfam>I noticed that opencolorio bundles a lot of stuff :( <adfeno>drakonis: So, it's not a wireless card... <ng0>i think opencolorio got me stukc, but i can't locate the right repo atm <ng0>I think there was nvidia-texturetools in their graph iirc... not sure.. i copied this to a temporary place. <ng0>that's the problem when you have too much work from before you focused on your own task again x.x <ng0>omg it's full of repositories and branches. <ng0>I was surprised dbacl is easy to fix. maybe uclibc-ng will be easy in a few months too.. <ng0>i have an bbs almost ready to submit.. i'm jus twaiting for the author to come back from holiday to review a problem with me. <ng0>repeats the build when you run make check.. <drakonis>i figure i should also try building the binary image from updated files <adfeno>drakonis: Which unbound variables? <ng0>i think i have not arrived at opencolirio yet.. there's some packages I need first, like the libdispatch series which is waiting for review. <adfeno>drakonis: Do you by chance, wrote down the error or part where the kernel froze? <ng0>I know I've build opencolorio at some point and moved it to a temporary file. <drakonis>In procedure module-lookup: Unbound variable: login-service <adfeno>... We'll probably need that to report but. <drakonis>i would have to write everything down again <ng0>greping 50 GB of repos for opencolorio now.. <drakonis>/home/drakonis/guix/gnu/system/install.scm:278:10: In procedure installation-services: <drakonis>/home/drakonis/guix/gnu/system/install.scm:278:10: In procedure module-lookup: Unbound variable: login-service <ng0>drakonis: that's at system init? <ng0>drakonis: it'll be easier if we see the config.scm for that.. a module might be missing <lfam>drakonis: "Unbound variable" typically means there is an error in your system configuration file. <ng0>grep told me that I said on 2016-09-15 that I am doing opencolorio oO so it has to be somewhere, lfam <drakonis>i suppose the command for it is pulling from my system, isn't it <drakonis>i can't use it to build a image from the repo using guix <ng0>in a repo you use ./pre-inst-env <lfam>drakonis: Can you be more specific? I'm not sure exactly what you mean <drakonis>alright now, so, i'm trying to build a new usb install image with the non free linux kernel, seeing how the libre kernel isn't working well here <drakonis>it isn't able to actually boot up because udevd seems to be throwing errors over a fujitsu driver for hardware i don't have <adfeno>We have two options: (a) get information on the error and freeze and report it upstream (Linux-libre); (b) Kick everything out try building non-free software (not recommended). <adfeno>As a free/libre softwar activist, I would recommend (a), with a mix of: get another free/libre distro meanwhile. <lfam>drakonis: Your hardware doesn't boot at all with linux-libre? <drakonis>it just stops at udevd's attempts at loading the fujitsu drivers <adfeno>lfam: Do you by chance know a way to make GuixSD live media be verbose on startup? <lfam>adfeno: Like, you want to see the kernel messages? <lfam>I assume there is something that can be passed to (kernel-arguments) in the OS configuration file <lfam>I don't know off-hand exactly what option to pass <ng0>lfam, i have an opencolorio patch assembled somewhere which throws out some bundles. <adfeno>drakonis: Try starting GuixSD and editing the first boot entry of GuixSD's GRUB. <adfeno>drakonis: If GRUB doesn't appear, hold Shift until it happens. <adfeno>OK, now add... (wait a sec, getting words)... <ng0>I'll search for it tomorrow or monday. I'll note this somewhere. should i CC guix-devel or email it directly to you? I don't know if i find an guix package of it somewhere, but i've seen an 'remove-most-bundled-deps.patch' <adfeno>drakonis: Do you see, when editing the boot entry, a line with "splash"? <lfam>ng0: You can send it to either place. I'll be happy to use it :) <adfeno>Drakonis_ Do you see a line starting with "linux"? <ng0>before duplicate work happens.. do we have some bored toolchain experts who is dying to package uclibc-ng? because i have small progress there too, but won't work on it focused again at least before next summer :) <adfeno>Drakonis then insert "debug" in the end. <adfeno>(in case we mess up the line somehow) <ng0>my problem is just, I have so many open patches on the list, and the only ones super relevant for me right now are the psyc.scm and gnunet.scm ones, and I fear they could 'drown' in all of the other patches. <adfeno>"renaming alx" "enps3s0 eth0" freezes... <Drakonis_>woop, i rebooted and no i have a different issue <adfeno>Drakonis_: Strangely enough, I found a similar issue in Gentoo.... <Drakonis_>every time i do this, it somehow goes further? <Drakonis_>is this patching or what, it goes further and further every reboot <Drakonis_>it gives me more lines every reboot, what the hell <lfam>Non-deterministic failure <adfeno>Drakonis_: This is the second goal of Guix and GuixSD: Fix non-determinsm. <ng0>this is linux, not linux-libre correct? would be interesting to report upstream with enough infos <ng0>same sentence applies :) <Drakonis_>i want to replace the usb install's kernel with linux <adfeno>Drakonis_: Actually, Linux-libre isn't a "kernel" but a set of scripts, so ng0 is right. <adfeno>So... Now that we know it's not a Linux-libre issue.... <adfeno>I'll look for info on the Linux project instead. <ZombieChicken>Still having problems with the kernel trying to load a module that doesn't want to load? <lfam>ng0: I'm looking at the libdispatch patches now <Drakonis_>the current state of things right now is "vanilla usb install doesn't boot correctly" <Drakonis_>i want to make it boot the linux kernel and see if i'll have some luck <ng0>I might be wrong about libdispatch, but at least nvidia-txture-tools needs it. <ng0>there's just so much on my list.. and i really only want to focus on specific things now <adfeno>Drakonis_: So, are you using vanilla GuixSD on a USB? <lfam>ng0: Why does the libdispatch package skip the tests? <ng0>but i can't just throw 40 patches or more ... oh, well i have done that already. so i can so some more :) <ng0>hm... i don't know. can you enable them and see why it fails? as far as I remember rigt now there was an expectation about bsd or osx things.. <ng0>I shouöld've commented it. I'll be to bed now <lfam>Okay, I'll try it. Please remember to leave a comment in the future :) <Drakonis_>maybe the issue is that i copied it to my usb instead of writing it to a clean disk? <adfeno>Drakonis_: OK, so we are in the same track. Now, to keep things towards the goal: Do note my request: Everytime you boot the USB, until we can fix this, remeber to edit the boot entry and add "debug" in the end of the "linux" line. <ZombieChicken>Drakonis_: nomodule Disable module load <- That sound like what you might be looking for? It may disable all module loading, however <ng0>yeah. there are some more packages i got feedback on, I'll react to that, but i'm just doing less work on those. <ZombieChicken>Drakonis_: kernal-parameters.txt in $KERNEL_SOURCE/Documentaion <lfam>Does anyone know how to pass a value to CFLAGS and CXXFLAGS in the cmake-build-system? <adfeno>lfam: I'm not a programmer, but my one-day experience tells me that this depends on the recipe. <adfeno>lfam: Reading cmake-build-system now. <lfam>You don't have to do that, adfeno :) I've not given up yet. <lfam>I was just asking in case somebody already knew the answer :) <lfam>I added "-DCFLAGS=-ffloat-store" and "-DCXXFLAGS=-ffloat-store" to #:configure-flags and I'm building now <adfeno>I'm actually not busy, although eyes are tired, I'm waiting for Drakonis_'s feedback. <lfam>It takes about ~40 minutes to reach the test that could fail :( <adfeno>lfam: Heh... You haven't seen nothing, I must always remeber to pass "-c 1" to every guix command, otherwise I might create an atommic bomb of my 5-year old friend or fry my work/college computer, which is the only one that works decently with free/libre distros. <Drakonis_>it doesn't hang, it simply stops going past a certain point <lfam>adfeno: Start the guix-daemon with '--cores=1' :) <lfam>Drakonis_: Yeah, sounds really frustrating <Drakonis_>i removed a usb and it responded with the removal messages <Drakonis_>but it stos doing anything past a certain point <Drakonis_>thus my wanting to replace the kernel with the non free version <Drakonis_>maybe the usb install kernel isn't up to snuff? <adfeno>Drakonis_: Heh, that one is most updated. <ZombieChicken>Drakonis_: Can you load the USB up somewhere and drop a copy of the Debian kernel onto it? I don't know how much that might cause breakage nor where, but that would likely support your hardware <Drakonis_>and as far as i know, the usb is just loading the kernel as it would from a regular install <lfam>Drakonis_: Do you see how 'gnu/system/install.scm' is an operating-system declaration? And operating-system takes a (kernel) argument that you can use to specify something besides the default kernel. <ZombieChicken>How would I provide you with a copy of the Debian kernel? Well, you /could/ try compiling it yourself if you have a day or two, or you could see if you could download the .deb pkg and run deb2tgz or something over it <Drakonis_>i was planning to make a scm for the purpose of compiling the kernel <adfeno>Actually I'm a blind lost in the shootout :) <Drakonis_>also i'll have to postpone this for a couple hours <Drakonis_>because my cousin's kid is here and he really really wants to play games <ZombieChicken>adfeno: I'm just trying to figure out where guix system init runs. It's suprisingly hard to find <lfam>ZombieChicken: 'guix/scripts/system.scm' <adfeno>lfam: It seens that vigra's Makefile hardcodes the CFLAGS and CXXFLAGS. <ZombieChicken>lfam: Yeah, I just found that. Why the hell is it in there?!? <lfam>adfeno: Ah, thanks for the tip <lfam>ZombieChicken: That's where all the command line tools lives <lfam>`guix package --show=linux-libre` <lfam>That will list the available linux-libre kernels. It will also tell you which file they are defined in <adfeno>lfam: However, as you pointed out, the "rules" file in "debian" directory doesn't honer Makefile (??). <Drakonis_>how many hours would it take to compile on a haswell? <lfam>The kernel? Which haswell? <adfeno>lfam: Please forget my cmake comments, it seems I don't know that much yet. <lfam>I mean, but it takes about ~2 hours <adfeno>Drakonis_: Prepare the dinner table, because you can fry eggs above the machine. :) <lfam>It shouldn't take very long <Drakonis_>by the way, does shepherd replace systemd for systemd dependent packages? <Drakonis_>or does it requires some modifications for using with these packages? <lfam>Drakonis_: We have something called elogind that allows us to run GNOME. I'm not sure what other programs require systemd <Drakonis_>i'll resume my quest to install guixsd later, for the time being <Drakonis_>because again, my main computer is occupied being a minecraft machine :V <ZombieChicken>I have to say, it's a little hard to track down what all is going on in the Guix code <adfeno>lfam: Seeing "guix/build-system/cmake.scm" shows that the builder accepts #:configure-flags and #:make-flags <lfam>Yes, I'm building now with #:configure-flags <adfeno>Also, syntax seems to be: -D[Variable name]=[Value] <adfeno>lfam: Yep, seeing "gnu/packages/bioinformatics.scm" (particularly, the recipe for "flexbar"), this should be the way to do it <adfeno>Drakonis_: I'm very sorry to inform, but I must leave. My eyes are tired and it's 21:40 here. <adfeno>Drakonis_: If you encounter an issue, please document it on a paper somewhere so we can try working on it. Also consider subscribing to bug-guix mailing list and report your findings there. <adfeno>Drakonis_: Thanks for persisting, most people who are new to Linux-libre usually give up thinking that the problem is in Linux-libre itself (that's what they think, but it's not proven) <adfeno>Well, I must be going now. Bye! :) <Drakonis_>oh, so the linux repos already have the kernel compiled <Drakonis_>there's also irc and the soon to come irc v3 <lfam>amz3`: Thanks for sharing that link. I was looking forward to seeing what he had to say <lfam>Drakonis_: The context is that some people have been advocating for us to use something besides email. <Drakonis_>the only thing that would make email more usable, would be a interface to make things more readable for the common person <lfam>What do you mean by "readable"? <Drakonis_>but yeah, let me see if i get why, it scales better than anything else <lfam>Blame your email client if it doesn't show threads :) <lfam>There are plenty of clients that handle threading well enough for me to follow guix-devel conversations <lfam>Depends on your needs ;) <lfam>I use Mutt. I recently spent a day with mu4e in Emacs (first time using Emacs "in anger). I use mu with Mutt, so mu4e seems like a logical step. <lfam>Many web-based email provider's interfaces handle threading well <lfam>I should know a GUI email client to recommend <lfam>Right, the problem is "who will maintain it?" <Drakonis_>and mozilla doesn't give a flying fuck about it <Drakonis_>so i can't recommend it to regular people because it will download their viruses <Drakonis_>i infected a computer using thunderbird's defaults <lfam>What I like about Mutt is that you can delegate every network action to another program. But that also increases the difficulty of getting started by an order of magnitude <lfam>So IMAP and SMTP are not handled by Mutt. Mutt only ever interacts with files on my local filesystem. <lfam>Which is good since Mutt is a big old C program <lfam>I wonder about the mail clients from the desktop environments. GNOME and KDE must have something, right? <Drakonis_>it may or may not be outdated, as it still refers to lotus as lotus notes <Drakonis_>mutt can handle IMAP and SMTP according to that file <Drakonis_>i am actually interested in that and may or may not actually get into submitting patches, and get good at this <lfam>Drakonis_: Yes, it can "handle" it but I wouldn't recommend it if you have lots of mail. <Drakonis_>i'm trying to figure out which protocol is the protocol that doesn't store mail on your computer <Drakonis_>but i don't actually have excessive email these days <lfam>You're thinking about IMAP I think <lfam>I guess if you don't want to keep mail locally, Mutt's IMAP might be sufficient. <Drakonis_>so i'd rather have mail on demand than anything <lfam>I prefer to mirror it all locally so I have my correspondence when I'm not in my office <Drakonis_>i don't think i have any mail worth reading yet <lfam>You should subscribe to guix-devel ;) <Drakonis_>i should also acquire a different email provider <Drakonis_>while i like gmail, i think my account has too much spam in it <lfam>Interesting. I always found Gmail to be excellent at filtering spam. Perhaps too zealous, putting legitimate messages in the spam folder <Drakonis_>i rarely get legitimate messages moved to the spam folder <lfam>Actually, my university used Gmail to provide us email, and when I left school I transferred everything to a new account. I must have triggered a bug, because Gmail gave me all the spam I had ever received, everything deleted, even messages from before the account existed. ~90% of it was not my "real" mail. They keep *everything* <lfam>That included spam that did not make it to my spam folder. Hundreds of messages per day at least <lfam>Yes, their AI is excellent. Which it should be, since we give it everything we possibly can <lfam>They never stop thinking of new types of information to keep <ZombieChicken>Stopping spam would require one to put an end to the botnets that make it <brendyn>Drakonis_: Put it in a folder of your own and set GUIX_PACKAGE_PATH=/path/ <pksadiq>which package contains tzselect (or some otherway to set timezone)? <pksadiq>why is gnome-shell on guixSD producing a little more heat than usual? It's about 60°C. Usually on other OS I get around 50°C. <janneke>pksadiq`: how do you measure the temperature of gnome-shell? <pksadiq`>janneke: Sorry, I'm measuring the temperature of my computer when running gnome shell, and it's using 'sensors' from ls-sensors package <janneke>pksadiq`: ah...you may want to consult `top' to see where your cpu cycles are spent <pksadiq`>janneke: my CPU usage is lower than usually it is (On other OS's), same for RAM (about 300 MiB). I suspect GPU issues (or something else should I check?) <janneke>pksadiq`: if you suspect your gpu, why not check that first? <pksadiq`>janneke: Sorry for my ignorence. I don't know how to do that :) <janneke>pksadiq`: me neither, try asking someone who knows such things, like google ;-) <pksadiq`>google seems not knowing better. (Actually I have searched an answer for this for my entire life, never found a convincing answer) <alezost>pksadiq`: tzselect is from glibc package ***[0xAA] is now known as Zer0pings
<rekado>I’m a little late for this but I’d like to issue a friendly reminder that on this channel we don’t provide support for non-free software. <rekado>you’re all welcome to discuss these things privatel, but on the channel we should keep things on topic. <rekado>we shouldn’t offer cut and paste recipes for how to install non-free software. For many people it may be easier to replace part of their hardware with alternatives that work without non-free software. <rekado>That said: Guix is flexible enough to allow dedicated and knowledgeable people to patch the deblobbing scripts for Linux-libre to suit their needs. This is free software, after all. But we don’t steer people towards this path by giving them instructions on how to achieve this. <jmd>How do I add new user groups to my Guix configuration? <rekado> (groups (cons* (user-group (name "rekado") (id 1000)) <jmd>rekado: Ahh. I must be using the defaults. <Petter>Do you think /etc/hosts should come with "localhost.localdomain" as well? <jmd>Petter: Actually, that is something that I have been meaning to raise on the list. <jmd>What we have currently is completely wrong. <jmd>... and it breaks some applications. <jmd>What we currently have is 127.0.0.1 localhost <canonical-name> <jmd>That must be changed to 127.0.0.1 localhost.localdomain localhost <jmd>next line: 127.0.0.2 <canonical-name>.<domain> <canonical-name> <Petter>Right. And similar for IPv6 I guess. <jmd>I guess so. But I'm not an expert in IPv6 <jmd>with the current setup "hostname -f" returns just "localhost" which breaks things. <dvc>the cargo-build-system is a pain, I'll devote myself to more fruitfull endeavors... the recursive importer imported 169 dependencies for cargo... <Petter>jmd: Let me encourage you to bring this up on the mailing list. <jmd>Petter: Yeah I've been meaning to. But I need to gather all the facts, because I can predict that it's going to rustle a few feathers ... <Petter>I can get it started with a more naive first e-mail if you'd like, to get things going. <rekado>I don’t know much about this. Consider my feathers unrustled. <jmd>Petter: I'd rather you didn't until I've done a bit of research about things first. (But I cannot stop you if you really want to :) <Petter>That's fine, I'll leave you to it :) <jmd>ok. I'll try to get around to it during next week. <Petter>I'll try to remind you if you forget. ***[0xAA] is now known as Zer0Pings
***[0xAA] is now known as Zer0Pings
<quigonjinn>Building a package, a reference to the build directory ends up in the runpath of a library, so validate-runpath fails. Is it acceptable solving the issue "manually" with the use of patchelf for example? ***[0xAA] is now known as Zer0Pings
<rekado>quigonjinn: it’s preferable to figure out why the reference gets embedded. <rekado>patchelf is a hack and it doesn’t even work on all supported platforms. <quigonjinn>older versions of the package do not produce such a reference. I may have to git bisect <dvc>would doing something like nixos does for rust packages be also an acceptable solution? Since rust binaries are compiled statically anyway, there isn't really a point spliting the source into multiple packages... <jmd>On my machine, the user "john" seems to be in the sudoers file. But I don't remember putting him there, and there is nothing in /etc/config.scm which seems to explicitly say he is. How is that determined? <civodul>jmd: maybe the user is in the "wheels" group? <civodul>dvc: not sure what you mean; are you suggesting not to have separate packages? <jmd>civodul: Ok. Wheels is it. <dvc>since my naive solution is a hack <dvc>the importer and build system would need a better understanding of cargo.toml files other than sed like manipulation <civodul>like the pypi importer does with wheels/requirements.txt, no? <dvc>I'll have to look... don't know <civodul>the pypi importer gets dependency info from the wheels and/or requirements.txt files available in the pypi repo <dvc>the crate importer imported 169 crates for cargo... <civodul>i guess that means the importer has to be rather smart from the start <dvc>I think that we'd need to implement a proper dependency constraint solver instead of using the crates.io api we're using <civodul>again, a need for the recursive importer <dvc>does it already know about semver and stuff? <dvc>or is it a naive implementation like mine? <civodul>currently the importer framework is "flat", it can import only one package <civodul>but rekado worked on allowing it to import a package's closure in its entirety <civodul>that's what i meant by "recursive importer" <dvc>ah I implemented a hack to do the same... <dvc>you didn't think I imported 169 packages by hand? =P <civodul>yes, i think there's one for the npm importer too :-) <civodul>do you have enough already to build some of these packages? <dvc>I built some simple ones but then realized that many things I've implemented to naively <rekado>yeah, the recursive importer… maybe I can look at this again tonight. Or maybe tomorrow. <dvc>there is metadata in Cargo.toml that selects dependencies based on the rustc release channel used <dvc>so one package needs a nightly rustc and a package that depends on it says it's dependency is optional and that the dependency requires cargo nightly <dvc>I just feel it's going to become an enormous hack <civodul>we should have a way to make sure the result is actually going to be usable <civodul>maybe you could ask for advice on the relevant Rust forum? <dvc>all distros are struggling... <OriansJ>Finally after a month of Development, I am pleased to annouce that the stage0/M0 Line Macro assembler is now self hosting and capable of cross assembly with only the creation of a definition file. <civodul>dvc: this task list is intimidating... <dvc>they are improving the situation, we no longer need snapshots, and there is a new cdylib crate type for creating shared libraries. but if the crate isn't a shared library or a binary then I'm not sure there is too much point in deduplicating the source into multiple packages... <davexunit>it's weird that this hasn't been a concern of theirs until recently. <davexunit>how can you just spend so much time designing a language and tools are forget about all of the operating systems that they are intended to run on? <dvc>I think they were focused on stabilizing the language for 1.0 <dvc>and performance improvements <dvc>the tooling works pretty well if you aren't trying to package it for a distro... :) <davexunit>"it's really great until you want other people to run your software" <OriansJ>civodul: The most impressive part is that all together it only is 1772 bytes in size and 441 instructions total; ironically I probably should shrink that since I haven't even done any real optimizations yet. <dvc>I think it's similar to npm. it works great for what it's intended to be used, creating a webapplication inside a docker container. If we'd build our packages locally with network access and just distribute the binaries that would be simple too... <dvc>not saying we should of course - we shouldn't <dvc>one core assumption that distro package managers make that lanugage specific package managers don't make, is that the distro package manager assumes that there is only one version of each package that works for all other packages. We do have qt-4 an qt, but that's not what I mean. npm and cargo specify complicated combinations of (small) packages that work together... <civodul>it might be that for these we should import several versions of each package <dvc>would it be possible to use something like cargo-vendor inside the importer? that would import a crate, download the package and run cargo-vendor on it to crate a tarball that includes all the source it needs. then we could have a very simple build system that would build cargo with it's dependencies <dvc>I guess I could setup a small webserver somewhere that distributes already vendored packages that are interesting for distros, most crates aren't interesting to package anyway... <civodul>dvc: sounds theoretically possible but inconvenient, no? <civodul>it's best if we don't have to host all the source ourselves <dvc>yep. One item on the list is publishing cargo source tarballs. I'm assuming that alexcrichton is planning on doing this, so at least for the most important package we'd be covered. I'm just writing to him to ask him about his plans in this regard <OriansJ>civodul: I wouldn't trust it as much if we didn't atleast have a mirror of the source code because ultimately other systems can be shutdown without us knowing about it before it happens <OriansJ>If you are worried about bandwidth, use magnet links and let people use bittorrent protocall to get the source/binary files <civodul>i'm more concerned about infra maintenance and transparency <civodul>seems like my laptop's SSD is slowly dying <OriansJ>civodul: infrastructure can be really simple, if you remember to break it up and avoid anything unessential <civodul>each individual thing is simple, but it all adds up :-) <OriansJ>that is why we write scripts and configuration files, so that we don't have to deal with the net complexity <OriansJ>I write code, so that I don't have to do things but rather let the code I wrote handle all of that crap I don't like. <dvc>quoting: == Advantages to bundling == <dvc> * Guarantees that the application is running with the same set of <dvc>code that upstream tested. (Fewer Fedora-specific bugs means less <dvc>burden on the maintainer) <dvc> * Simplifies packaging of updates. (Fedora maintainer does not need <dvc>to keep tabs on unbundling patches to keep in sync for new versions) <dvc> * Increases the available pool of software that can be packaged <dvc>substantially (many modern languages such as Ruby and Go are <dvc>realistically only functional with allowable bundling) <dvc> * Did I mention the reduction in maintainer burden yet? <dvc>civodul: I think that we could make exceptions for bundling in "modern" languages. That would include go, rust and js at least. I'm not familiar with ruby... <kmicu>dvc: If you start making exceptions then why use Guix at all if Nix already exists with plenty of exceptions ( ͡~ ͜ʖ ͡°) <dvc>kmicu: have you ever tried packaging a rust or js package? ;) <dvc>many exceptions that nix makes are questionable I guess, but I'm talking about streamlining language support of interpreted/staticlly compiled languages that are very hard to unbundle. nix does something different and hacky for each language they support... <dvc>we can automate the importer->tarball process... <dvc>the features that moved me to start using guix where it's nice cli interface, beautiful support for cross compilation, nice qemu support and no need to support windows and macosx <rekado>I think it’s going to take better arguments than the ones you quoted above to convince us that bundling is okay. <dvc>I'm giving my rust project up for the moment, I don't see how I can provide an acceptable solution without reimplementing cargo in scheme... <OriansJ>dvc: I do agree that some langauages are in such a terrible state that bundling looks attractive but We should all know what hell it could bring <dvc>patching security issues is the main problem right? <OriansJ>dvc: that is the big one that is easiest to point at but there are many others <OriansJ>bundling tends to promote poor long term planning in software development <dvc>you mean adding dependencies without much though <OriansJ>and not properly designing interfaces for shared code, etc <dvc>I just think that most non distro package managers out there either are total crap (haskel, ruby, python) or promote bundling (go, rust, js) <OriansJ>That is because they are trying to solve the wrong problem <dvc>I agree, but we have to live with it... <OriansJ>no, we can choose what code we import into our environments <OriansJ>If someone wishes to do something stupid on their own machine, it is their choice but we don't have to suffer for them too. <OriansJ>Bring in only the pieces you care about, take the time to do it right and perhaps others might like what we have done. <dvc>so maintaining 150+ packages to build cargo is doing things right? <dvc>summarizing what this means in my specific use-case <OriansJ>If you wish to allow people to use cargo, then yes. <OriansJ>Now there probably are some things that can be done to reduce that number by leveraging common libraries and programs but that is up to you or anyone else who wishes to put in the effort <dvc>well I can build cargo from source in a guix environment, that's enough for my private cargo use... <OriansJ>and until someone else is willing to put in the effort to support more than that, it is sufficient. <dvc>rustc might be nice to have in guix, but I can write a blogpost on how to use cargo in guix. my only worry with rustc is that building it without cargo might be non-optional soon and that rustc might be split into multiple crates in multiple repos (at some point in the future)... <OriansJ>dvc: there is a big difference between nice to have and essential; essential must be there regardless of required effort, nice to have will only be in there if it can be done with a reasonable/acceptable amount of effort. <OriansJ>Heck, there is about a dozen games; I think would be nice to have in guix but I don't expect them any time soon. Since 1, they are not my top priority and 2 no one else feels they need to be added yet. Maybe once my stage0 bootstrap project is done, I'll do it but until then I'm fine without them being in guix. <quigonjinn>hello dvc. did you by any chance try the openocd package i sent you? <dvc>quigonjinn: just saw it now, ended up in spam... <dvc>quigonjinn: I'll build it now. A few things I noticed was: you implemented your own git submodule fetching? Is there a reason you didn't use (git-reference ... (recursive? #t)) <quigonjinn>dvc: because the submodules need to be initialised, after the configuration phase, if I remember correctly <dvc>ok, I guess they should be separate packages anyway... <quigonjinn>dvc: is there a need to, since they are only sources? just to make clear the individual licenses? <dvc>I'm not allowed to bundle either that's all =P <quigonjinn>in tarball releases of openocd, they are included as normal in the source. I could make separate packages though. <adfeno>I think I found the cause of the bug that makes the "artanis" package to be installed incorrectly. <quigonjinn>dvc: also, i think the apply-patch phase should be done in the source definition. I couldn't do so, because I had forgot to give a file-name to the checkout. <dvc>also there's a comment missing for why the patch is needed and why it's built from git... <Vibrant>Debian has failed in it's primary purpose: security and stability. See Andrew Ayer's Blog. If what Ayer says is true, then this is a very good time to talk to people about GUIX. Constantly. To everybody. <quigonjinn>dvc: i'll add those before i post it in guix-devel. i was just in a hurry to get it to work. would you like me to mail you the reasoning? <dvc>quigonjinn: nope - just saying :) builds and works. I'm still getting a OSBDM communication error: invalid swap command reply when trying to connect to my university supplied mc board :/ but I get that with the openocd from nixos too... <quigonjinn>dvc: which mc are you trying with? does it have a debugger on board? <adfeno>Vibrant: Sorry, I just arrived now... <dvc>it's a freescale MC9S08JM60. it has a separate chip for usb serial/flashing. It just says OSBDM on the schematic... <dvc>it should support debugging <adfeno>Vibrant: Can you give me references? <adfeno>Vibrant: I'm not a security activist, but this seems to be an interesting read. <dvc>I'm new to openocd. I played around with it with a sam3x development board I bought years ago but nothing serious. I'm just running it with -f interface/osbdm.cfg - I guess there is a board and a cpu cfg missing... <quigonjinn>dvc: try adding "osbdm" in the list with the --enable flags in the package definition and rebuild <dvc>it's already there I checked before building :) <dvc>also in the documentation it says it works with the latest osbdm firware, I'm guessing I'm running an older version... <quigonjinn>dvc: so you need to find an appropriate configuration script for your board i think <dvc>that's going to be hard to impossible. I'd probably have to write my own... <dvc>it's a custom board I think... <quigonjinn>dvc: i'm not proficient in openocd myself. i abandoned trying with a board of mine, which is supported in openocd as well <quigonjinn>i have tested the package to work nonetheless, with another mcu <dvc>I belive that it works, as I said same issue with nixos's openocd... <dvc>quigonjinn: thanks for packaging openocd :) <quigonjinn>dvc: in general, i find a lack of documentation of free software toolchains for many boards, but this is not relevant to this channel :) <dvc>I found a toolchain by the way. sdcc, do you know it? aparently it's THE free toolchain for accumulator architectures (freescale, pic, etc), didn't know it before <quigonjinn>dvc: yes, i've used it with pic microcontrollers. it was recently added in guix, right? <adfeno>Artanis' Makefile is giving a maze...:( <dvc>why do you think it was added =P <dvc>going afk for a while... <jmd>match-lambda is a guix special ?? <rekado>jmd: it’s in (ice-9 match), I think <jmd>It would appear not. <rekado>jmd: in a REPL do this: ,use (ice-9 match) ((match-lambda ((a b c) a)) '(1 2 3)) <jmd>I get: ERROR: In procedure module-local-variable: Wrong type argument in position 2 (expecting symbol): (match-lambda ((a b c) a)) <adfeno>jmd: It seems the last "a" should be "'a". <adfeno>I don't know much about Guile nor Guix, but symbols are called/defined with single quotes. <adfeno>However, doing a simple string-append doesn't solve the issue. <adfeno>You might need to use a conversor. <rekado>this is a lambda that expects a list with three values that are bound to a, b, and c, respectively <rekado>then the function returns just a. <dvc>ah maybe there is a better aproach to packaging rust than I was taking: recursive importer only imports crates that contain a Cargo.lock file, if there isn't a Cargo.lock file fail. From the Cargo.lock file it can create all required package definitions. <jmd>Anyway it seems that what works for match, doesn't always work for match-lambda <adfeno>ACTION starts dancing around as he finds out that he fixed bug on Artanis package recipe. <adfeno>ACTION stops once he finds out that there was already a proposal. <adfeno>The proposal received a suggestion, but the sender of the patch didn't relply back. <adfeno>So I think, I'll follow his work instead. <adfeno>And complete it applying the suggestions. <ZombieChicken>It seems I accidentlly volunteered to sort out the LUKS problem <adfeno>It seems strange that those doing `guix refresh` and commiting-and-pushing changes in the recipes don't actually see what's the difference between versions. <adfeno>ZombieChicken: I mean: When there's a new version of a package, they are making updates in the recipes, but are failing at checking how the versions actually differ. <adfeno>They do: Something like `guix refresh` and commit-and-push changes. <adfeno>They should do: The same, but before blindly pushing changes, they should get the repository of the project and diff the versions. <lfam>I think that reading the upstream code changes is ideal, but it's not feasible in most cases. Who volunteers to read all the upstream code? <adfeno>lfam: I just did with [part of] Artanis. <lfam>Okay, but we have ~4000 packages :) <lfam>Like I said, reading the changes is ideal. But it's not realistic to expect it to happen for every package <adfeno>After I finish here'll report the issue to Artanis and suggest them to revert to the usual installation behavior, <lfam>That particular Artanis issue should have been caught :/ <lfam>ZombieChicken: I would estimate a couple dozen volunteers <ZombieChicken>So ~100+ packages per maintainer. Yeah, god luck with reading all of upstream's changes... <lfam>Honestly, I would be thrilled if package submitters all did `guix refresh && git send-email` on packages they add. Even that doesn't usually happen. <lfam>I hope that anyone who adds a package will maintain it later, but it doesn't always happen <rekado>oh, the artanis breakage … was that me? <adfeno>I do agree with all of you... This is why we must report upstream. <lfam>Yes, we should push bugs and patches upstream whenever it makes sense <adfeno>rekado: I guess not, actually, the falt isn't on Guix at all, it's on Artanis, <lfam>Otherwise Guix will get bogged down in millions of patches and workarounds <lfam>Very nice: "Commit 2d47cee25b8bb31d22e6803f1cb3e1679641e14a removes all propagation from haskell.scm." <rekado>I’m glad whenever someone updates I package I once added. This indicates that someone else is using it and I have one less to take care of. <adfeno>You know what, instead of making the fixed recipe... I'll patch Artanis itself and send it. <lfam>Another move towards keeping the package tree maintainable :) <lfam>Is our e2fsprogs package broken? Or is there something wrong in my work tree? <ZombieChicken>During the install phase, is there a way to skip having to compile everything and just pull in the packages from hydra? <lfam>ZombieChicken: The install phase of what? GuixSD? <lfam>Pulling binary substitutes from Hydra is the expected behavior <adfeno>ZombieChicken: Did you do `guix pull`. <lfam>What did you use to install GuixSD? <lfam>Don't do `guix pull` yet :) It will make debugging more difficult <ZombieChicken>I don't have the VM running atm. I used the LiveUSB image, and it was compiling GCC <lfam>Which version of GuixSD? <lfam>ZombieChicken: We should still have substitutes available for that release, since it is the most recent release. If you try again, I can help you debug <ZombieChicken>lfam: I'll have to restart the install, but that shouldn't take me too long <adfeno>lfam: derivation `/gnu/store/...-e2fsprogs-1.42.13.drv' may not be deterministic: hash mismatch in output `/gnu/store/...-e2fsprogs-1.42.13' <lfam>adfeno: That's okay. At least the build completed. I think there are some stray .go files in my work tree <lfam>It would be nice to fix that determinism issue <adfeno>Did `guix build --check "e2fsprogs"`. <jmd>alezost: and why do you suppose I am asking again? <lfam>Huh, when I try to build e2fsprogs with latest `guix pull`, it fails with "make[2]: *** No rule to make target '../lib/libss.so', needed by 'debugfs'. Stop." <lfam>It works when I set #:parallel-build? #f. I have to do this on two different machines <lfam>adfeno: Does your machine have multiple cores? <ZombieChicken>lfam: I'll have to try and sort all that out later on. I have to step away for awhile <adfeno>OK, patch done, will write email later, must go, bye! :) <rekado>I just built it on my busy machine and it succeeded right away. <rekado>Does anyone know why gegl is failing on armhf and mips64el? <civodul>at least the Shepherd's socket is only accessible by root <civodul>so if such a bug exists, only root can trigger it :-) <cehteh>civodul: what me scares there is not the bug, that happens <cehteh>but that they decided to do runtime checks (user/external input) with assert() <cehteh>that shifts my already low opinion about systemd even lower <cehteh>i havent looked what happens when one compile systemd with NDEBUG .. then posisbly even worse things happen <marusich>Is there an easy way to write ChangeLog-style messages using emacs while writing a Git commit message? Like some kind of minor mode? <rekado>marusich: I don’t know, but I’d be interested in something like that, too. <rekado>so far I’ve been using macros when I had to do a lot of commits in the same style. <marusich>i usually just copy the previous entries, wich is easy but I can only imagine will be error prone <marusich>From "(standards) Change Logs" it is clear there is some support for ChangeLog stuff in emcas, but I am not an expert in ChangeLog style or emacs itself, so I don't know how easy it would be to adapt it to use for editing Git commit messages. <civodul>from a hunk, you type "C", and it enters the beginning of the ChangeLog-style thing <civodul>it's not perfect, but it certainly helps <marusich>Hm, Neat. I've heard about Magit but never tried it. Thanks! <rekado>I only used Magit like a caveman <civodul>marusich: BTW, your patches are in my queue :-) <civodul>it's pretty crowded, i have to admit ;-) <marusich>civodul, oh! thank you for letting me know. I know you're busy, and I appreciate you taking the time to look.