<civodul>efraim: uh? if there's a backtrace, it goes to standard error, no? <civodul>and hopefully bug-guix@gnu.org too ;-) <rekado>I’m about to begin packaging propgcc, a GCC adaptation to build binaries that run on the GPL’d propeller chip. Any advice? <rekado>should I use cross-gcc and try to override the sources or is this approach doomed? <rekado>the tarball contains the sources of binutils, gcc, and a lot more. <jmd>ZombieChicken: shepherd <jmd>I dunno why we call it shepherd. Since when do shepherds tend GNUs ? <rekado>the shepherd tends a herd of daemons. <jmd>Then it should have been called deamonherd <rekado>ZombieChicken: to what environment? <rekado>ZombieChicken: you don’t need to use Emacs to use GuixSD. <ZombieChicken>rekado: GuixSD. It apparently warrented an entire chapter in the User Guide <rekado>ZombieChicken: there’s a very convenient user interface for Emacs. <rekado>ZombieChicken: lots of commands that make packaging and profile management a lot easier. <rekado>ZombieChicken: it’s completely optional. <ZombieChicken>sadly I don't have 12 fingers and a master pianist reach to use it effectivly <rekado>ZombieChicken: me too. The third time it stuck around. <ZombieChicken>rekado: I'm far too comfortable with my modal editing with vim to switch. Even evil and viper don't really do it for me <rekado>ZombieChicken: there’s spacemacs for people who prefer vim, and there’s god-mode (and others) that allow you to do without chording. <rekado>Emacs is more than just an editor, so it doesn’t really compare to vim. <ZombieChicken>rekado: Yeah. I'm fairly sure I could come up with a few jokes along those lines <kete>ZombieChicken, I would prefer you learn about GuixSD than Emacs. <ZombieChicken>Not even trying to learn Common Lisp got me into using Emacs <kete>didn't set up ssh this morning <kete>I don't understand what you're saying about learning CL and getting into Emacs. <janneke>ACTION notes took me 3 summers to switch to emacs <kete>and typed something to insert a timestamp on a blog <brendyn>ZombieChicken: I think it's very important not to require Emacs. I'd like to eventually integrate guix with GUI update managers or build something new <brendyn>For Emacs, I think you need to ensure you are typing "correctly", i.e., touch typing, and aren't slumped over with your wrists bent, so that using the ctrl key isn't a pain. <brendyn>There are certainly lots of bindings, but it's amazing how much time people can waste by try to do everything point-and-grunt style <brendyn>Well nano is going to be included regardless <brendyn>I just think you should use things like paredit.el and automatic indenting etc <ZombieChicken>I've made attempts to use emacs. I just vastly prefer vim and modal editing to a monolithic userland-and-editor combo <ZombieChicken>that requires a pile of cheatsheets and finger acrobatics to do simple things <brendyn>Well, when I say "Emacs", I'm generally just talking about "editors that actually do stuff" <jmd>If you're happy with vi stick to it. If you prefer emacs, use that. <ZombieChicken>brendyn: Your phrasing could use a bit of work if that is what you meant <brendyn>Guix repo comes with many files that Emacs recognises to affect it's behaviour. I think vim does similar things. Maybe a vim user can submit vim equivalents into the repo? <rekado>brendyn: we would be happy to add files that help vim users to work on Guix. <rekado>ZombieChicken: yes, I contribute code and review some of the patches. <jmd>How can I append some text to a file as part of the build process? <rekado>jmd: You can open the file in append mode and then use (display "the text" port) <jmd>rekado: I wonder if our with-atomic-file-replacement might not be better <brendyn>So my first patch has been accepted into Guix. I'm proud. <brendyn>Now I'm trying to figure out how to pull from upstream, deleting my own git history for that file <rekado>brendyn: you don’t need to do that. <rekado>if you want to reset to upstream (losing all your changes) do this: <brendyn>I don't want to delete everything, because I have changes that will probably not be accepted for a long time <brendyn>But I'd like to do a 'hard reset' for a single file <brendyn>I also have to keep a 1 line change in local.mk <brendyn>Basically, I want to do all my own edits, but now that my change has been accepted for image.scm, I'd like to discard my own changes to image.scm in favour of upstream <rekado>for a single file it’s ‘git checkout -- the-file’ <brendyn>But without deleting linguistics.scm and taking away my edit of local.mk <rekado>in magit you can go to the hunk and press ‘k’ to drop it <rekado>I suggest working on different feature branches <brendyn>I was told I should learn to use the cli git :P <rekado>like this: git checkout master; git checkout -b wip-something <rekado>this creates a new branch ‘wip-something’ that is the same as ‘master’ <rekado>brendyn: I know the abyssmal command-line interface of git, and I prefer magit. <brendyn>Hmm ok. I feel like I basically just need to constantly have "master + a few changes" <rekado>that’s what feature branches are <rekado>you can easily rebase your few changes on top of latest master, before submitting your patches. <rekado>(I only have intermittent connectivity today, because I’m at a conference) <brendyn>I think I've ended up accidently editing lots of other files while screwing around in Emacs haha <jmd>Is hydra down or what? <rekado>jmd: hydra appears to be online (the website loads for me) <jmd>Yep seems to be alright now. <brendyn>More importantly how do I find out why guix is trying to download texlive when I don't even have it installed? <efraim>Likely its a dependency of something else you're building or upgrading <brendyn>It says to add --fallback to build it myself, but when I add --fallback nothing happens <efraim>If its 'guix package -u' then you need '-u . --fallback' or '--fallback -u' <brendyn>Ok why can't I do guix package -u --fallback <efraim>-u takes 0 or more arguments so it tries to upgrade the package --fallback <brendyn>Right, normally single letter flags don't do that, and -- indicates a flag <brendyn>Is there a way to list upgrades? or find out why this package is needed? <ng0>darcs depends on multiple version numbers of some dependencies... how am I supposed to solve that? <ng0>i can build 195/230 steps, then it fails because of this. <ng0>maybe some are just for tests.. who knows. I'm trying to figure out by packaging the versions now. <kete>Bash scripts seem to require the output of 'which bash' at the #! <ng0>or just /bin/sh if your script is posix conform <brendyn>That's what the patch-shebang phase is for <ng0>i assumed this was not in packaging. <ng0>otherwise brendyn is right <ng0>my 'short' packaging of darcs is not so short... i'm at 41 commits now :D <brendyn>ng0: I realised I made a typo in the commit is now in master, but that type actually corrected the another mistake which I'd made <ng0>great, there are more multiple version dependencies earlier in the darcs dependecy tree... it's not fatal but I think haskell is something I don't want to deal with regulary <ng0>my solution is to package old versions which inherit from the newer versions.. but haskell why are you so weird..... <rekado>brendyn: the substitute for texlive-texmf has been disabled in hydra. <brendyn>Why is that? Still I'd like to figure out what requires it. Guix does not seem to have a "list upgrades" feature <ng0>texlive is just very huge ***kelsoo1 is now known as kelsoo
<ng0>it's just a common asked question <ng0>oh, wrong person. sorry <kete>updating libreboot isn't working as root: operation not permitted <ng0>afaik you will run into problems with one tool.. you must reconfigure the system, last month I was told about this in some thread.. can't recall the software name <efraim>It turns out my onionshare patch set depends on nose2, which currently doesn't work as I've built it, so its not ready to submit to the list yet <ng0>does someone deal with haskell on their dayjob or possible with guix here? how do you handle multiple version dependencies? <ng0>i have 3 different versions of ghc-directory I'd need to add .. that's doable, but maybe I can avoid it? <ng0>i'll work on this patchset and i will feel very sorry and thankful for the reviewer.. by the list of versions I need to add it will grow from 41 commits to about 50 i think <efraim>these are declared versiioned dependancies or will it work with a later version? <ng0>the packages themselves build. only darcs pointed this out that $package depends on $package-version etc.. and darcs gave me a build error i do not understand, so i started to fix the dependencies. <ng0>that is not the error darcs build gave me, but before build start i get multiple occurences of information output in this style: package graphviz-2999.18.1.2 requires directory-1.2.2.0 <ng0>i can leave it like that and post the patchset, andthe final error output so someone with more haskell debugging knowledge could tell me what's going on <ng0>okay i read the error again.. the specific versions are really required. <ng0>or maybe I need to version bump ghc-transformers-* ... i'll see <ng0>it's more likely that I need to version bump <ng0>nope.. okay, I'll send the updated patchset <wingo>so how do people print with guix? <wingo>there does not appear to be a cups-service <wingo>ah i see one from Danny Milosavljevic <ng0>uploading the build-environment directory takes time.. will be up soon <ng0>efraim, i commented on the patchseries with a link to the full build environment and log file <brendyn>Do we intend to package things like Firefox extensions or is that something that's better left to the browser? <efraim>We package emacs stuff but not vim stuff <brendyn>efraim: Do you know how to find out what a particular package is required by? <brendyn>I haven't installed anything new but this update is requiring me to wait several hours to download texlive <jmd>brendyn: Are you downloading with substitutes? <brendyn>Yes but the hydra substitute is disabled <brendyn>What I want to know is why I'm even downloading texlive in the first place <jmd>Only you can answer that. <brendyn>And why does the download timer seem to be counting upwards instead of estimating time do completing like would be normal? <jmd>Well you're in Tasmania. Everything is backward there. <brendyn>Oh, I just noticed I'm downloading texlive for the second time now <brendyn>It downloaded it, decompression failed so it started again <jmd>Do a source download and build locally. That is much faster. <brendyn> rekado | brendyn: the substitute for texlive-texmf has been disabled in hydra. <brendyn>I see, it appears it is a .xz file but it was decompressed with bzip2 <ng0>2016-09-04 17:21 <brendyn> Do we intend to package things like Firefox extensions or is that something that's better left to the browser? that would be an interesting thought I had this year too, but currently there's just icecat. <jmd>brendyn: Iceweasel is no more. <jmd>It was nothing but a rebadged firefox. <brendyn>Oh, I must be using a patched version from Parabola <darkpsi>hey i am currently install guix and i need to remove a package from %base-packages what is the best way to do that thanks <jmd>There won't be much left if you remove those. <wingo>probably (delq foo %base-packages) <wingo>where foo is the package you want to remove <lfam>Hm, why _did_ I revert the wrap-python3 changes? I can't find the relevant discussion now <lfam>I seem to remember it caused some problem and I was asked to handle reverting it <jmd>lfam: Yes. That is why I am very unhappy, with our current practise of putting in the commit message just what can easily be determined by running "git diff". <darkpsi>@wingo so the package i want to remove is xlockmore and it says refrence to undefined vairlbe when i try to do (delq xlockmore %base-packages) <jmd>What we should be putting there is the reason *why* we made a change. <wingo>darkpsi: you have to have imported the package into your environment <paroneayea>wingo: if you get any sort of cups service to work, let me know :) <wingo>like in the os-definition (i assume this is in a context of guixsd) <wingo>(use-package-modules xdisorg) <wingo>paroneayea: yeah i am doing that too, it's the worst :P <wingo>not going to be able to fix it within the next couple weeks tho, too much to do <lfam>jmd: I don't know the context of "why you are unhappy". Did we discuss this previously? <jmd>I do remember discussing it with someone. <lfam>Indeed, I think we should add more information about non-obvious changes <jmd>Your previous comment would seem to have vindicated my point of view. <lfam>In general, I think another problem is that, sometimes, patch submitters don't pay close enough attention to the result of their submissions <lfam>In this case, the change was not noticed for two months <darkpsi>@wingo thanks for you help and being willing to answer my dumb questions <brendyn>What's the difference between [regexp] and [pattern] ? <lfam>Too bad there are no IRC logs for those days. I will try looking in my backups <jmd>lfam: Just this week, in another project, I was about to delete a line of code, which didn't make any sense to me at all. But I did a quick "git blame" to find the commit which added it, and then a "git show" and luckily the commit message told me exactly why it had been added. Removing it would have caused problems. <rekado>brendyn: texlive is needed by some packages that build documentation. <rekado>it will be downloaded when one of these packages needs to be built from source. <rekado>it would be great if we could split up texlive, but from what I understand that’s not trivial. <brendyn>Well the source seems to fail to download: ftp://tug.org/historic/systems/texlive/2016/texlive-20160523b-texmf.tar.xz <brendyn>If I try download it with wget it tells me my login is incorrect <brendyn>How can I list multiple sources for a package? <lfam>You could try finding another location from which to download it, for example the Debian archives <lfam>I think the solution to our texlive problem is "get faster servers with more bandwidth" ;) <lfam>So far, we have not eliminated the steady stream of complaints about it :) <jmd>If we could persuade upstream to split it, that would be good. <brendyn>I think we need to ultimately drop the current method of getting sources. It requires several thousand different servers to be working in at a given time <brendyn>For example I think ng0 was working on gnunet-fs support <brendyn>IPFS would sorta work but it has the same privacy problems as torrents <lfam>brendyn: We know use content-addressed mirrors hosted by ourselves and the Nix project <ng0>fundamental big projects take time <lfam>brendyn: No, but you will see the feature in action if a source tarball cannot be found at the "canonical" URL <lfam>brendyn: Try searching guix-devel for something like "content addressed mirror" for more info ***lumidify_ is now known as lumidify
<brendyn>ng0: What is the current status of that project? <brendyn>ng0: Well gnunet-fs work sorta like torrents? <jmd>At the end of the day, if it is a bandwith problem then no method is going to improve things. <lfam>I actually don't think we are bandwith-limited, yet. At least, I haven't heard of that being a problem. <brendyn>IPFS/torrent type solutions allow downloading from multiple sources at once <ng0>no, it is different brendyn. on status: stage 0 nearing completion.. which means: almost working basic gnunet-service (assumed to be working, i need to test it), working with upstream on debugging gnunet new release. <lfam>Previously, hydra.gnu.org was hosted on a very resource-constrained VM with abysmal I/O performance <brendyn>Personally my entire country has cray bandwidth <lfam>Something about that system made it basically impossible for us to serve the source and substitutes of texlive-texmf, which are each several gigabytes <jmd>brendyn: BS. Australia has a crappy network. <lfam>Now, hydra.gnu.org is improved, but we still feel that it would be detrimental to serve this package <rekado>brendyn: have you tried ‘--fallback’ already? <rekado>you shouldn’t need to download with wget <brendyn>rekado: Yes, it spend 2-3 hours downloading and then failed and started again <jmd>And anyway, if your local network is saturated, which it probably is, then no torrent /SCTP / IPFS is going to help. <jmd>brendyn: Texlive takes about 14 mins to download here. <ng0>brendyn, i need to move my work in progress to something people can checkout.. currently it is spread across several repositories ***lumidify_ is now known as lumidify
<brendyn>I think people who haven't lived with shitty internet just don't understand this so well. Crappy internet doesn't obey normal logic. If I download the same file from 10 different sources at once, often it will go faster <ng0>jmd, texlive download here takes 2-3 hours usually <brendyn>What I'd also like is, for example If I have a computer lab with 30 computers, they can share files with each other like everything was on IPFS <jmd>ng0: source or build ? <brendyn>And bandwith problems are worse with distance. For exmaple I get about 30KiB/s from Russia. <lfam>I keep a link to the current texlive source tarball in /var/guix/gcroots, so I only have to download it once. <jmd>bandwidth is independent of distance. See chapter 5. of Tannenbaum's Computer Networks. <brendyn>jmd: You have a decent internet connection right? <lfam>You can set up a machine to run `guix publish` and add it to --substitute-urls for the guix-daemons. Simple but effective <ng0>development on gnunet-fs could move faster if I wasn't working on 4 different projects between 30 - 70 hours per week.. eta is still before summer 2017.. ideally much faster <jmd>How big is the source of Texlive? <brendyn>independent of distance? Are you serious? <jmd>brendyn: Of course. I think you are confusing bandwidth with latency. <brendyn>This is why I say people that have decent internet don't understand. No amount of theory over rules observation <ng0>civodul, does translation happen at an external translation project? there's a direct patch on the list for translation of a .po file <ng0>this does not seem to be clear in the files, if you do not look at the git log, for the person who commited the patch. can we make it more clear (file headers?)? <civodul>not sure; this is the "normal" workflow with the TP <civodul>we commit .po files as-is, unchanged <jmd>ng0: On a 8Mibps connection that should take about 40 mins then. <jmd>I didn't think I had to wait that long. <ng0>i don't have that here. everything tel. companies sell are marketing lies here <ng0>bad wires in the over 100 years old house, bad routers in the street, etc.. <ng0>upgrading would be pointless <ng0>i have started packaging 0ad, regardless of license checking etc.. something to work on every now and then. i rarely have time for games but this one was always fun to play with others <jmd>ng0: Yeah. A lot of ISPs do bandwith choking without telling their customers. <ng0>no , this one does not. the tech just sucks <rekado>ng0: huh, I never got 0ad to work well. <ng0>i used it on gentoo and archlinux <brendyn>jmd: I pay like 60 dollars a month for a 25Mbit/s connection and in reality I get about 3Mbitb/s. <jmd>Yeah. Unfortunately that is not an uncommon story. <lfam>How much do they charge for a nominally 3Mbit/s connection? ;) <brendyn>Lets see. My University is about 100m down the road and I'm on fibre optic. Downloading a Fedora iso via ssh from the University's super computer gets me ~800KiB/s = 6.4Mib/s. That's the best I can do. <snape>is it possible that git send-email is not packaged for guix ? <snape>how do you guys send your patches? <jmd>brendyn: How did you test that? <brendyn>jmd: rsync -avP -e 'ssh -i .ssh/ssh-key.pem' debian@144.6.228.195:'~/Fedora-Workstation-Live-x86_64-25_Alpha-2.iso' Desktop/ <lfam>brendyn: No, complaining always ruins my mood :) <jmd>And how large is that iso? <brendyn>100MiB. (Actually it's an incomplete file since I stopped the download to the University server) <lfam>snape: You can see what outputs the Git package has with `guix package --show=git` <jmd>brendyn: How much of it did you get? <snape>I was doing guix package -A send-email <lfam>snape: You can install git-send-email with `guix package -i git:send-email` <lfam>That package:output construction is how you refer to outputs <brendyn>sent 43 bytes received 117,602,424 bytes 867,914.89 bytes/sec <jmd>and what is the ping time to that server? <lfam>snape: I think you will need to have a working SMTP client to use git-send-email <brendyn>tbh I think maybe it's ended up in melbourne 0.o <lfam>snape: Cool, looking forward to some patch series sent with git-send-email :) <snape>I did put git:send-email in my manifest.scm <snape>but it does not seem to work <snape>probably it is not the same syntax <snape>I use map specification->package+output <lfam>Hm, unfortunately I don't have much experience using package manifests <lfam>It's probably worth it to have an example of this in the manual, if there isn't one there already <snape>specification->package is in the manual <jmd>brendyn: Yep, then either their end was saturated or yours was. <snape>but specification->package+output is not <snape>lfam, patch sent, feedback welcome :) <alezost>snape: do you use "guix package --manifest"? If so then why do you need 'specification->package{+output}'; you can just use 'packages->manifest' (it supports outputs) <snape>I'll try without +output then <alezost>snape: I didn't mean 'specification->packages' supports outputs; I meant 'packages->manifest' supports, like this: (packages->manifest (list emacs git (list git "send-email"))) <snape>You are right, I did not read well what you wrote <snape>but I like when things look nice <snape>and... it looked nicer with everything in strings <snape>without having to specify the modules <snape>thats why I tried to use the +output thing <snape>I thought it worked because it shows no error <snape>so yeah I'll get back to the "variable" way <alezost>ah ok, you may choose what you like of course (I prefer to use the real packages instead of strings) <snape>I do not like code repetition <snape>and I find that writing twice (almost) the same thing for every 80 packages <snape>is very close to code repetition <alezost>snape: what do you mean 'specification->package+output' does not work? It works as expected, what's your code? <alezost>snape: can you show how you use it? (I mean the code) <alezost>definitely not genious :-) it just converts values (returned by 'specification->package+output') to a list (accepted by 'packages->manifest') <jmd>How can I refer to the source package in a build phase? <snape>alezost: I understand, well, that made my day <alezost>jmd: do you mean the source of a package? <alezost>'inputs' should be a phase keyword: (lambda* (#:key inputs outputs #:allow-other-keys) ...) <jmd>alezost: And how does that help? <alezost>jmd: I don't understand this question; isn't that what you asked? <jmd>No. I want the source of the package itself. Not an input to it. <demotri>alezost: Because you mentioned it: Yesterday I wondered where lambda* is defined. It's not in Guile. So it must be somewhere in Guix. Do you have an idea? <alezost>demotri: see (info "(guile) lambda* and define*") <demotri>alezost: Ah, there it is! Thank you.