<ng0>not replaced but you can use libressl globally <lfam>paroneayea: I tried updating it to 4.5.1 and invoking the tests as `nosetests`, but the tests fail immediately with something that ultimately says "'You are trying to run the Python 2 version of Beautiful Soup under Python 3. This will not work.'<>'You need to convert the code, either by installing it (`python setup.py install`) or by running 2to3 (`2to3 -w bs4`).'" <ng0>my gnunet maintenance gentoo vm is not using libressl because well I need a vanilla one. but there are very few failures to fix in gentoo with libressl, mostly just versions <lfam>Maybe the tests must be run after install... <lfam>We upgraded python from 3.4.3 to 3.5.2 :) <lfam>I bet that has something to do with it <paroneayea>lfam: I wonder if beautifulsoup was one of the ones that "automatically" converted itself via 2to3 <paroneayea>I ran into at least one of those while doing mediagoblin packages <ng0>there's certain crypto software where differing from upstream with libressl would be problematic, but in general 99% of software should need little to no patching <ng0>well the start is not the problem considering that you did not run into problems from previous installation and followed the post-install instructions (read the manual) <ng0>actually grammar was right <ZombieChicken>Well, running /etc/init.d/guix start seems to be taking a rather long time <ng0>I was not involved in the last changes, but I tested it recently on a minimal gentoo vm and it started very quickly <ZombieChicken>heh. It seems like the initscript isn't detashing or going into the background when started from the command line <ng0>ah right. yes, that's also a current 'feature' <ng0>please fix it when you can :) <lfam>Guix is not the fastest program on my computer, but it shouldn't take more than a couple seconds on recent hardware for most operations <ng0>I'd be very happy to merge a patch into the overlay or pull from a repo <ng0>I just do the gnunet maintenance on gentoo, so I don't really deal with minor outstanding problems anymore, that's handled by other contributors <lfam>ZombieChicken: The guix-daemon just runs in the foreground. It's up to your process supervisor to handle putting it in the background somehow <lfam>ZombieChicken: Can you paste the full output onto paste.lisp.org? <lfam>It's probably a transient networking error <ng0>I wonder if I could get portage to run on guixsd so that I could kick the gentoo-vms away and just use portage-on-guixsd to do the maintenance work <ng0>I can take a look at the error later, I don't have a web browser at the moment <ng0>I only test gentoo on x86_64 hardware so far, so that's my limitation. <ng0>looks like some network failure to me or even hydra failure <ng0>nothing obvious with local permissions or such <lfam>Hm, I'm not sure what to do about that python-cryptography error. I guess I'll report a bug and hope they don't say "Please update; WONTFIX" <lfam>Trying to update python-cryptography is what led me to start the wip-python branch and to land the Python updates in core-updates <lfam>I just hope we get there before there is some critical bug in that library <lfam>ZombieChicken: That's strange. Can you send a bug report to bug-guix@gnu.org? <ng0>if it's obvious, i'd like to help fixing it if there's a bug at all. It's cool someone is actually using software packages I wrote :) the problem is debugging on gentoo, which is why I use very minimal VMs which only exists for the features they are created for. my attempt to make it easier to reproduce bugs for myself. <ZombieChicken>ng0: This doesn't look like an issue with the ebuild, but an issue with guix itself <ng0>you obviously will have gnutls with guile bindings by now, but do you also have guile-json? I don't know if this can be the problem here. I write too much and don't remember all of it without opening the ebuilds <ng0> /me sighs at libreoffice rebuild time .. really, I should run my local mirror of hydra or my own hydra <ng0>I can look at the gentoovm where I installed guix succesfully <ng0>just needs some time to boot <lfam>ng0: I think the problem with libreoffice is that it depends on almost everything <ng0>and it's really huge <lfam>I often do `guix package -u . --do-no-upgrade=libreoffice` <ng0>no matter which systems, 2 hours was the best I could get and that was on a very recent computer I sold now.. longest before was 7 - 12 hours then <lfam>Wow, 2 hours sounds great :) <ZombieChicken>I honestly don't understand how an office suite can take longer to compile than my kernel <ZombieChicken>On an unrelated note, anyone notice how the emacs community seems really sarcastic and borderline useless for newbies? <lfam>libreoffice actually depends on openexr and ilmbase, which are tools from Industrial Light and Magic that provide a high-dynamic range image format. Yes, the word processors uses Hollywood technology for HDR images. And everything else :) <ZombieChicken>ng0: btw, thanks for pointing out that overlay. I've been wanting to mess with GnuNET <ng0>should it be split off into 'gnunet-overlay'? I've discussed about this with some people.. I don't know if it would make things more obvious. <ng0>well there's a post now on gnunet.org, so maybe this appears in search results. visible enough <ZombieChicken>Oh wow. /etc/init.d/gnunet spits out literally dozens of errors <ZombieChicken>paroneayea: guix archive: error: build failed: path `/gnu/store/z5qzkar6frb6wxc2s0hmip4pl139zyl3-icecat-45.3.0-gnu1-beta.tar.xz.drv' is not valid <- that looks important <paroneayea>ZombieChicken: I don't really know what it means though or why it's not valid <ng0>idk.. works for me. could you send the 'dozens of errors' to the gnunet-help mailinglist or my personal address (found at my gnunet.org/team profile page)? <ZombieChicken>ng0: I'm going to have to work my way through the install. There are more than a few problems here I think, and I think that "dozens of errors" is just permission issues <ng0>paroneayea: hm.. icecat succeeded for me on x86_64 <ng0>lint and testing showed no errors, but you are welcome to report bugs on the gentoo packages of gnunet, I'll get them fixed as soon as I can <lfam>paroneayea: Looks like a network failure: guix offload: warning: failed while exporting files to 'chapters.gnu.org': Broken pipe <ng0>if there are more problems, try any mailinglist, email address or bugtracker I mentioned :) I'm off to bed now. good night <reepca>So after about an hour of copying files to the flash drive, guix system init has finished with "Installing for i386-pc platform". That's, um... that's great and all, but I actually wanted to install it for x86_64. How does one tell it to do that? <fps>rekado: that's just grub <fps>reepca: that's just grub <fps>i suppose the message should be clarified.. boot into it and you'll find it's x86_64 <ZombieChicken>fps: Do you have a working Guix/GuixSD install up and running? <ng0>ZombieChicken, I have to re-read your message later, but would it be okay if I CC the bug again in an reply? you usually just reply to bugnumber@debbugs.gnu.org and debbugs does the distribution of messages i think <ng0>i don't know when or who and about what read the link (uefi, debian) <ng0>strange, for a search in the log this did not appear before.. must have been somewhere else <ng0>what is a 'wiimote'? My guess is something for the Wii console which I guess can also be used on other devices. <ng0>where did qtwebkit go? ***abbe_ is now known as abbe
<iyzsong>civodul: sorry.. it seems I had commit a wrong hash, I have the '05xc' tarball in my store though. <ng0>tree tabs is really good <ng0>so underrated.. when this first came out as an extension I thought I did not need it, now it is so very good after one day of using it :) <paroneayea>civodul: maybe-naive reading of M-x guix-hydra-latest-builds <wingo>ok sent a release mail for fibers <civodul>paroneayea: ah yes, well, that's core-updates in the making :-) <ng0>so i just thought I could package sonic-pi until the qtwebkit problem is addressed, but I just spotted that sonic-pi needs supercollider.. wohoo. I'll just use my NixOS until then. <wingo>it helps to copy and paste anyway :) <davexunit>it never even occurred to me to try doing that <reepca>so question, what's up with b43 in linux-libre (my laptop uses a broadcom thingy that normally uses that driver... it's an old laptop)? I thought there was an open driver for it? At least, I don't *think* I allowed lubuntu (what's on the hard drive right now) to install a proprietary driver. <reepca>Yeah, just checked, it says no proprietary drivers in use... and yet the wireless wasn't working on the install to the flash drive. How might I remedy that? <lfam>I thought we had a b43 firmware package... perhaps it was only passed around here on IRC and never added to our repo <reepca>was I supposed to include that in my config.scm when I ran guix system init? <reepca>I guess I just sort of assumed it would ship with as much open-source wireless support as possible <ng0>there's no publicly exported b43, broadcom or even just 43 when I searched for it. <davexunit>think of guix as a library for making your own distro <rekado>I see messages like this on hydra: `/gnu/store/.links/17zyaa88vkycdkas7b0zhc17jz6cz8ixrgvnh3bbp6b2ny60a8id' has maximum number of links <civodul>lfam: istr seeing it in a bug report or something, bavier was involved <bavier>lfam, reepca: the b42 firmware hasn't made it in yet; hasn't been tested well <rekado>the state of substitutes for master on hydra is pretty bad. 930 failures is too much. <ng0>so there's someone who could test it additionally.. I could also test it, but the one b43 laptop I have doesn't even start with the i686 guixsd image <rekado>just a few days ago this was at around 800 and I restarted a few builds. <lfam>reepca: Are you interested in testing bavier's firmware package? :) <lfam>rekado: I found that the web interface is not accurately reflecting the state of core-udpates. mark_weaver mentioned this on guix-devel today. <lfam>It makes it difficult to know where to give attention <reepca>alright, I guess the only way to see what's wrong and improve it is to try it, right? And I don't think I can just replace the wireless card in my laptop. <lfam>I just started a `guix system build` of my GuixSD machine on core-updates to see where (and if) it fails <lfam>But that's not a graphical system so the test will be limited <lfam>At least last night, the web interface did not show that tcsh had been built. But I did get a tcsh substitute <reepca>noob question... how should I apply that patch? <bavier>reepca: do you have a git clone of guix? <reepca>not on the system itself, but on my desktop yeah <reepca>git clone on the system would require me to have internet access, which would require me to unplug the cord to my desktop, which I don't wanna do until I know what I should be doing <bavier>hmm, but building the packages would also require internet access <reepca>wifi drivers are always such a chicken-and-egg problem <bavier>it'd be possible to generate a new installation image that contains the firmware packages on you networked machine <reepca>oh, also, the system install is on a flash drive right now <bavier>mark_weaver: just saw your icecat patch, cool! <lfam>Hm, the regular approach to grafting does not work for dbus. I assume this is because (gnu packages glib) exports the dbus variable before defining it. <lfam>Considering that the bug in question is not considered to be critical, maybe we should just update dbus on core-updates and leave it alone on master? <reepca>so if in my config.scm I have the bootloader set to be on /dev/sdb and I later change it so that there's only one disk in the system, would guix system reconfigure fail? <reepca>Is there a way to refer to the device other than by block file thingy? So that I can say I want the bootloader on the disk named GuixFlash rather than just "the second disk you see"? <lfam>The patch 'ath9k-htc-firmware-binutils.patch' fails to apply on core-updates <bavier>seems there's no upstream bugs either <lfam>bavier: nckx reported it upstream and there is a new release on the way <lfam>Maybe there is some patch we can cherry-pick for now? <civodul>reepca: in grub-configuration, i don't think this is possible <lfam>That's the release that Dave said the fix would be in <lfam>Will you try updating it? :) <civodul>reepca: in fact, this device name is passed to 'grub-install', which says that it "is an OS device name or a GRUB device" <civodul>reepca: so you could use "(hd0,1)" or similar <lfam>I've been tracking the recent Ghostscript bugs, waiting for a new release. The whole time I didn't notice that we don't actually use Ghostscript, but instead GNU Ghostscript <lfam>I hope we are able to apply the recent upstream security patches to our Ghostscript <lfam>I suspect there will be many more changes in Ghostscript now that there is a lot of attention being paid to it. GNU Ghostscript will need to make a new release in my opinion <nckx>lfam, bavier: btrfs-progs 4.8.1 took a while to release, I just pushed it to master. <nckx>Huh... TIL the mess that is Ghostscript :-/ Thanks for the link, lfam. <nckx>ACTION always assumed it was just the GNU Postscript package. <lfam>Yeah, a real mess... I wonder what source code Debian uses <lfam>bavier, nckx: I merged master into core-updates again, so the fixed btrfs-progs is available there <nckx>Every time I think I get licencing... Why does GNU need to maintain a separate version of an AGPL project? <civodul>lfam: we might need to use upstream's Ghostscript package <lfam>Normally I prefer to use upstream sources that are the most actively maintained, but there must be some reason that GNU forked it, right? <lfam>Is there some licensing incompatibility? Where do you recommend I ask? <ng0>lfam, link from our own chatlogs about this.. one moment <ng0>no.. no information. <lfam>Oh well, thanks for looking :) <ng0>if no answer is to be found, one could always ask at the gnu operating systems whatever the name was list @ gnu.org <lfam>gnu-linux-libre@gnu.org ? <lfam>That seems out of date. The last GNU Ghostscript release was 9.14.0 <ng0>yes but there msut have been a historic change. as far as I read the links, it was a licensing one <rekado>lfam: I only packaged the original AGPL Ghostscript <rekado>but then a new release came out and it no longer built, so I abandoned it. <rekado>that’s the reason why I packaged trio, though. <lfam>The new release needed trio? <rekado>I don’t remember which of the releases does, actually. IIRC upstream bundles a lot of libs, so I packaged some of those dependencies first. <lfam>Yes, I noticed that Artifex loves to bundle <lfam>I was recently annoyed by mupdf by for that reason <reepca>bavier: So I don't think I quite understood, how should I apply the patch? Apply the git patch to the cloned repository, re-build guix, and run guix system build? Is there a way to do it without overwriting the system so far? Can I make new packages available without rebuilding guix? <bavier>reepca: you can add your own packages using the GUIX_PACKAGE_PATH environment variable <bavier>reepca: idk what the best way to get the firmware onto your unnetworked machine would be <bavier>reepca: would you mind trying a custom installer image? Our of curiosity, I made one which includes the b43 firmware <reepca>Okay, so my plan so far is to put the patched firmware.scm in a file in GUIX_PACKAGE_PATH on the laptop, switch the ethernet cord from desktop to laptop, run guix package -i b43-tools (is that the package name?) and hopefully it should just work? <reepca>If I can avoid re-installing guix I'd like to, it took over an hour to put everything on that flash drive. I'm actually a bit suspicious of the flash drive's quality. <reepca>anyway I'm gonna run to class now, will try later <bavier>reepca: for firmware, you'll need to adjust your system's configuration <lfam>reepca: You will want to do `GUIX_PACKAGE_PATH=path-to-your-packages guix system reconfigure config.scm` after having named the b43 firmware in your config.scm <lfam>It's worth trying on Hydra when it's otherwise idle <ng0>bavier, yep. it's even easier for us with hydra :) saves the headache of trying every single package one by one <lfam>Somebody should volunteer to lead this effort :) <ng0>there are issues, but because we're late to the party there's much patches in the BSDs, Gentoo, Apline and others already <lfam>Hopefully those patches are going upstream <ng0>in general it shiuld just work <lfam>I don't think that carrying a whole bunch of libressl compatibility patches is acceptable for us <ng0>I'm sceptical of crypto software... bitcoin is untested for example <lfam>Right, another reason to send the patches upstream <lfam>Let the experts evaluate them <efraim>We also have packages that are GPL+openssl exception <lfam>ng0: I mean, everything that uses OpenSSL could be called "crypto" software in the sense that it's using OpenSSL's crypto routines for something <ng0>generalizing.. i mean software which itself is ~crypto-stuffythingy~ and happens to not be tested by upstream with libressl <ng0>one of the issues you can run into is that the protocol required by the application is no longer in libressl, as new libressl dropped some <ng0>but there's also a LTS of libressl which is not in guix, and i do not understand why <ng0>as long as almost nothing uses libressl in guix, that's probably okay.. but as soon as you have more applications you could run into problems and maybe some are just solved by lts release <lfam>Probably because nobody packaged it yet. There's only one package using libressl and I don't think anybody is paying attention to it <ng0>not solved, but you can sit on it and try that it will be fixed eventually upstream <ng0>well there is this mailing daemon i packaged... <ng0>email is inefficient in the way that I do not know if people have forgotten to reply, are busy or if it is in any way on someones list. so i do not remind anymore, only in emails which carry links to unsolved patches, once a month or so. but yeah, there's more software with libressl to come :) <ng0>I would even default to libressl for new packages, but I think I would just get comments asking why not openssl <rekado>I just stumbled upon a whole stash of LV2 audio plugins, yummy! <lfam>ng0: And it would be a good question. If upstream specifically says their software depends on OpenSSL, how are we supposed to know that it's safe to use LibreSSL? <lfam>Just because it builds doesn't mean that it's working correctly <ng0>the transition to libressl should cover that.. builds okay does not mean runs okay. for that you'd have to look at other systems <lfam>And AFAIK, none of us are experts on TLS implementation <lfam>And this is one area where I am skeptical of "Debian does it", unless I see that the Debian maintainer is known to be an expert on the subject <rekado>Some of them are effects made by the Guitarix folks by simulating circuits. Pretty cool stuff. <ng0>I never look at debian for problem solving and comprison, but that's just me <lfam>Right, it's just an example of looking to other distros instead of asking upstream <lfam>For example, I know that people are using nginx with libressl, but I don't see anything about libressl on nginx.com. They specifically say they depend on openssl. <ng0>in most cases it's a 50/50 chance.. the projects I package for, at least for psyced I brought it up and lynX was like well theoretically it should work.. or something like that. it's just that practically libressl is really new. <paroneayea>rekado: cool. I'd be interested in hearing some thoughts from you on what kinds of free software audio production tools you use with music-making at some point :) <ng0>idk if this is already answered, but what's up with qtwebkit? I need it for finishing supercollider <lfam>Anyways, like I said, we can do a test build with libressl once Hydra is idle and see what happens <rekado>paroneayea: I’m giving a talk about this tomorrow, actually :) <lfam>ng0: I don't know. Did you try packaging it? <lfam>rekado: Please record the talk! <rekado>in Berlin at a music school, on our FSFE fellowship meeting <ng0>cool :) will you have slides or recording available later? <rekado>talks at our meetings are *never* recorded :) <rekado>and I still haven’t started preparing… <ng0>i am asking about qtwebkit because I know for qt4 it is dropped. but qt5? all i found is someone said it is moved. <rekado>well, packaging LV2 plugins probably counts <ng0>how am i supposed to include it now? <ng0>the threads i found left me with questions <rekado>ng0: afaik, qtwebkit doesn’t exist in qt5, but there’s qtwebengine <ng0>so that's what became of qtwebkit? <ng0>is it like the MIT-license of webkits? <ng0>supercollider writes about a qt5 qtwebkit <rekado>paroneayea: I’ll eventually write a blog post about free software and music. The whole range of things I’m working with, hardware to software, live and studio. <davexunit>rekado: I'd be very interested to read about that <lfam>I'm looking forward to that blog post <rekado>it just occurred to me that some of these LV2 plugins might be ported to the Axoloti board. So that’s analogue circuit->simulation->code->digital circuit <ng0>free software/hardware and music is probably one of the things which left to me not recording anything 6 years ago and until now. there has been development and I am looking into that.. :) <jmd>what is "free hardware" ? <davexunit>hardare that has all of the source available for producing your own or modifying <jmd>"source" refers to software. <jmd>So its more like "open" hardware. <rekado>the term is “free hardware designs” <rekado>the Axoloti board, for example, is a free hardware design. <jmd>It doesn't really sound right to me ... <rekado>and you run free software on it. <davexunit>if you buy something with a free hardware design, you get everything that the designer uses to make modifications <jmd>At any rate the FSF opinion is that "free hardware" is a phrase with little meaning. <ng0>I'm no lawyer, my expressions are sometimes simplifications of what I meant to say to spare you very long sentences. <jmd>ng0: It's not a question of lawyering. It's a question of communication. <jmd>Free software means the freedom to use, copy, modify and distribute the program. <ng0>I know, but I find irc really not suited for long sentences. otherwise I'm open to long sentences. <jmd>Only one of those actions could possibly apply to hardware, viz: modification. <jmd>It's not pedantry. As I said - it's communication. I don't understand what is meant by "free hardware" -- how can I "copy" or "distribute" a motherboard for instance? <rekado>ng0: re supercollider: Qt is optional. <ng0>qt is required for the ide <ng0>and i'd like to build that <rekado>it shouldn’t be one big package, though <rekado>supercollider is useful on its own without the IDE. <ng0>okay? i don't know, i'm just getting started with music without stringed devices <ng0>so i'll do the build without ide then.. should suceed. maybe at some point whatever-qtwebkit will be available again <rekado>ng0: if you want to play with audio synthesis and live music coding you may also want to take a look at extempore. <ng0>thanks. so far I'm still trying to understand it all, I've done music where I touched knobs, used the soundwaves of the tubeamps etc to further manipulate what I played.. but electronic due to lots of people around me in 200 meters radius is new, even just floorboard with headphones was strange. <ng0>started a drone song in milkytracker but I think I'm hitting the limitations of song length (from my beginners perspective) <davexunit>been meaning to learn how to use milkytracker <rekado>I never used trackers, but I did a lot of MIDI stuff in normal sequencers (qtractor has a sequencer) <ng0>you know.. the mailinglist is getting stressful for me. I just post.. and occasionally I read what I find interesting and tag stuff as done so that it disappears from my view. but there's a clownshoes high amount of incoming messages per week, per month <ng0>this can't be the solution.. it maybe works when you are efficient and learned to handle the load, but to learn how to handle boatloads of emails, i don't need that for all the other projects I communicate in. I try to review occasionally, some items even offlist because people seem to be no longer subswcribed. <ng0>I don't want to get frustrated because of the way communication is handeled.. if there's an end in sight for the monoculture of email or it'll be accompained by something else, that'll be okay.. but otherwise it will be painful when the number of contributors goes up. there are now 30 - 40 of us.. imagine the flood when there are 100... <ng0>midi trackers mostly just work in the connection? I've never had such devices outside of rehearsal rooms <rekado>I don’t think it’s so bad. It’s only frustrating if you see it as a job. <rekado>you’ll never get through all email. <rekado>some reviews take a long time and polishing up patches, testing them, merging them — that takes time, too. <ng0>i don't read it all, but I am still exposed to it all. I'm not 24/7 in irc.. and we have no news system like gentoo.. so important updates or discussions? email. and that's why I briefly need to read at leat the beginning of threads <rekado>you don’t need to read the patches. <rekado>important updates won’t be in [PATCH] threads. <rekado>ACTION has to prepare a talk now, waves <ng0>I think you don't understand me. communication gets inefficient. I don't see this as my job, yet the comnmunication part could be better, improved. not the way communication works, but.. I already filter. yet my filtered guix inbox has currently 8888 emails. that's 6 months or less. <ng0>so sometimes changes happen which are not clear from the (git) log, so I read the threads. you can only participate actively <ng0>if you discuss in what's of interest to you. but again the amount of emails to filter after my filter is at the point of sensory overload because I just want to separate work (patches) and discussion. <ng0>there are smarter ways than email.. yet they are difficult to change to it seems. i can't correct most of what I've written there, but well yeah the main point sensory overload and you are told <ng0>that you should just handle it somehow with your email client. <ng0>gentoo has discussion + discussion around patches separated because of bugzilla for example. the gentoo-dev list is clean. sometimes threads get long, but you see it's just discussion. I can throw all gentoo lists I'm subscribed to into one search-inbox. <lfam>Tests a patch for ath9k-htc-firmware on core-updates. Hopefully we just need an updated binutils patch from the ath9k repo <jmd>Are there any public substitution servers other than hydra.gnu.org ? <lfam>I remember somebody offering a mirror on guix-devel, but I don't believe they were building their own substitutes <civodul>lfam: at worst i'm sure we could force the use of Binutils 2.25 on this platform <civodul>if there are no applicable patches floating around <lfam>I'm cloning the GCC repo now to see the history of that 'ieee754-sf.S' file <lfam>But I'm pretty out of my depth here <civodul>the patch you show is probably doing the right thing <civodul>except that we don't use the bundled binutils <civodul>IOW you need to extract the binutils-2.27_fixup.patch part <lfam>That's the part that's actually "new" for us. The other part of my patch just removes some unneeded and conflicting context from the existing patch <civodul>so you take the part that's new and remove the first column of "+" <lfam>Well, now I have the GCC Git repo. I'll keep that around considering how long it took to clone :) <lfam>civodul: It built. Thanks for reading my broken patch :) <civodul>happy to see progress on core-updates! <tinyOwl_>i'm trying to start packaging some stuff and surprisingly it's actually not going too bad :D <tinyOwl_>but the tar step must have worked during the build at some point <tinyOwl_>as it started compiling, which is why i have so many native-inputs <tinyOwl_>btw, i'm also pretty sure that the inputs as well as the whole '(let* ...' and '(setenv "PATH" ..' block could probably be done in a nicer way <tinyOwl_>but before cleaning that up, i'd like to get it to build properly <lfam>tinyOwl_: You should be able to do (system* tar "xvf" ...) <lfam>Assuming you define tar like this: (tar (string-append (assoc-ref %build-inputs "tar") "/bin/tar")) <lfam>I copied that from the package definition of font-dejavu <efraim>I would consider starting from a different build system and deleting or overriding some of the phases <lfam>True, that approach is usually best <lfam>tinyOwl_: Yeah, I realized that I don't understand why you are getting that error <ng0>fails with SEC_ERROR_OCSP_SERVER_ERROR <bavier>tinyOwl_: there is no input named "icedtea-8", so the assoc-ref returns #f <lfam>Ah, good catch. I was looking past that <tinyOwl_>bavier: so it should be (icedtea (assoc-ref %build-inputs "jdk")) ? <lfam>ng0: ssllabs says the server does not support OCSP. I don't know why that gives an error... <lfam>It's not a required feature IIUC <ng0>loads when I reload it from the debuging console <ng0>I'm using a specific extension which should not trigger problems loading pages though. <lfam>I just shared that link in case it helped. I'm not pointing to any specific answer <ng0>to the contrary, it detects problems with pages certificates.. and said nothing about netzpolitik.org .. ok <lfam>There are some packages that will always be grafted ;) <civodul>anyone knows what "install_requires" is in a Python context? <lfam>civodul: My experience is limited to packaging, but it seems to be a list of dependencies without which the build will not continue <lfam>It doesn't specify how they are provided <lfam>Yes, usually in setup.py in my experience <lfam>I've patched those lines before while debugging, and they did have the expected effect <lfam>Ok according to whom? ;) I have no idea what the terminology is <civodul>(that may sound like silly questions, but for some reason i find myself reviewing the Python doc patch) <lfam>Does anyone how to find the PGP sigs of *old* releases on PyPi? <lfam>Thanks Petter! I just realized they are also adjacent to the tarballs in the "hashed" URL <civodul>but wait, why doesn't the pypi importer mention signatures if they're available? <lfam>Turns out not to matter, I still can't build python-cryptography :/ <civodul>i thought there were no signatures on pypi <lfam>Some packages have them, some don't <roptat>hi, I'm getting 500 errors from git.savannah.gnu.org when I try to "guix pull" <lfam>roptat: Works for me. Try again? <lfam>I assumed HTTP error 500 <lfam>I downloaded the tarball at 2.0 MiB/s, from the USA <lfam>Well, I assume that it's the right thing. Hard to say with HTTP <reepca>question... should ntpd be respawning every 2 seconds? <lfam>It might do something but it shouldn't be restarting <reepca>well it was taking awhile to load the graphical session so I hit ctrl + alt + f1 and saw that every 2 seconds it would say "respawning ntpd, service ntpd has been started..." et c <lfam>Hm, that's not expected behavior <lfam>Are you able to paste the text on paste.lisp.org? <lfam>That doesn't happen on my machine, and I see the tty often so I would notice it <lfam>ntpd does have a very verbose startup <lfam>Bah, python-cryptography is broken on master too <lfam>Oh no, I was mistaken. Thankfully! <lfam>Wishing for `guix graph --diff` ***lewo_ is now known as lewo
***Ulrar_ is now known as Ulrar
<reepca`>sorry if I missed anything since I last spoke, apparently my connection is a bit spotty <reepca`>which is weird, it really shouldn't be. <reepca>after about a minute of it (at least, after a minute of watching it) it now says "Service ntpd has been disabled. (Respawning too fast.) <reepca>not sure how. Would the text from that terminal be logged anywhere? ***reepca` is now known as reepca
<lfam>reepca`: Try looking for ntpd in /var/log/messages <reepca>how far have my messages been seen? <reepca>a lot of really weird stuff just happened <lfam>I saw you come and go a few times <lfam>Try looking for ntpd in /var/log/messages <reepca>Is there a way I could get that to paste.lisp.org from the terminal, and should I send the entire thing? <lfam>reepca: You can use another site from the command line, sprunge.us. <lfam>Apparently it's like this: <lfam>So, `echo foo`, `cat file`, whatever <reepca>then I guess I should install curl, huh <reepca>being stuck at a terminal trying to find error logs brings back bad memories of trying to revive my brother's laptop. The screen would randomly go black (backlight still on) whenever any major changes happened to the display (so for example right when you cat a file) and refuse to show anything until it rebooted. And I tried installing arch linux on it. *shudder* <reepca>turned out to be a motherboard defect, but we replaced the ram (who uses a single channel ram with a bandwidth-hungry APU?) so the warranty is void. $1k down the drain. Brother was not happy. <lfam>I wonder how I can do #:python ,python-3.4 <lfam>Just doing that gives me "patch-shebang: ./setup.py: warning: no binary for interpreter `python' found in $PATH" <reepca>and xmonad still hasn't loaded to the point where I can do anything after about 15 minutes. The flash drive is slow, but it's not *that* slow <lfam>reepca: You might have the graphics acceleration you are used to, I'm not sure <lfam>Regarding ntpd, I'm also not sure <lfam>Is your system up to date? <reepca>guix pulled last night if that's what you mean <reepca>I'm just using the example lightweight-desktop config.scm <lfam>After you did `guix pull`, did you also do `guix system reconfigure`? `guix pull` by itself won't change the software you have installed with Guix <reepca>I think I did. I know I did guix system reconfigure, and I know that I didn't do it before I did guix pull because it warned me about downgrading. <lfam>What does `pgrep ntpd` show? There should only be one process running <reepca>it isn't letting me back to the terminal with ctrl+alt+f1 <reepca>arg, I really don't want to do a cold boot... it's flash memory... <lfam>Hm, I did have that issue once. I became unable to switch TTYs <reepca>I rebooted by tapping the power button, it seemed to have time to clean up <lfam>I'm not sure what's going on with ntpd for you. If I were you, I would stop the service, and then start it manually using the same configuration file. It will probably be easier to debug that way <reepca>/var/log/messages doesn't have the messages from ntpd about respawning <reepca>where can I read about how to stop/start services? Would that be a shepherd thing or a guix thing? <lfam>It's in the Guix manual, section 7.2.7 Services. Basically `herd start foo`, `herd stop foo`, etc <lfam>And then more detailed info in the Shepherd manual <reepca>"herd start ntpd" => "Service ntpd is currently disabled. herd: failed to start service ntpd" <lfam>Right, that's what your log said. "2016-10-12 11:45:59 Service ntpd has been disabled." :) <lfam>You could try enabling it again, but I think it will be easiest to debug when started by hand <lfam>On my GuixSD system, `ps aux | grep ntpd` -> /gnu/store/1ds1kf21yd0fjv4fjv98niwcv8bvl16c-ntp-4.2.8p8/bin/ntpd -n -c /gnu/store/h52ghz4hxnz520z79szslvn6c4ln8636-ntpd.conf -u ntpd <lfam>So, I would do that as root <lfam>But, adjust for your own store paths <lfam>You won't have the same hashes as me <lfam>I actually don't know how the '-u ntpd' part will work out, but that's part of the the joy of debuggin! <reepca>but ntpd is stopped, so I can't find that from ps ¯\\_(ツ)_/¯ <reepca>I could try to search through the store maybe? <lfam>That might not give you the right binary and conf file