<sneek>alezost, you have 2 messages. <sneek>alezost, civodul says: M-x guix-licenses rocks <sneek>alezost, civodul says: would be if package-info buffers showed "coreutils 8.24" instead of "coreutils@8.24" in the heading <alezost>Sure! I was going to fix it but forgot :-) I've just sent the patch to ML. <fhmgufs>How can I get a list of all available packages in Scheme code? <sneek>Welcome back fhmgufs, you have 2 messages. <sneek>fhmgufs, alezost says: you can get a list of packages in guile with this: (fold-packages cons '()). 'fold-packages' procedure is placed in (gnu packages) module <sneek>fhmgufs, alezost says: if you want to get packages by name, then: (find-packages-by-name "emacs") <civodul>nice, the answer to your question was already recorded :-) <alezost>fhmgufs: np, you may ask if anything is not clear ***nursejunka is now known as adickpic
<Jookia>civodul: An update on my GTK patch: GTK+3's next stable release should have the XDG_DATA_DIRS scanning feature, so I think it's confirmed that it's the right thing to do <rain1>Is there a guide on how to get started editing the packages tree? <sneek>rain1, lfam says: I noticed you linked to my development mirror of Guix on your guix-wiki. That's cool! But I think it would be better if you linked to my private packages repo, which is called 'pkgs' and not 'guix' <Jookia>iyzsong: So we'll need to keep the GTK2 patches but it's fine <Jookia>rain1: Editing the packages tree? You mean guix? <rain1>let me explain te real thing <rain1>I want to package something that requires patches <rain1>I see that guix itself brings patches with it, and source can refer to them -- so I think can put patches there and it'll find there <rain1>I scanned through the manual but I don't know how to set that up <Jookia>rain1: Git clone Guix, link ~/.config/guix/latest to the repo, and edit away by adding packages to an appropriate file and looking at other packages for inspiration ***Basstard1 is now known as Basstard`
<rain1>guix package -u is using up all my memory and freezes my computer <rekado>rain1: you can also use patches with packages defined in GUIX_PACKAGE_PATH. <rekado>but in general I prefer using git. <rain1>rekado, oh that is good news, I would like to do that just for development <rain1>would i just mkdir $GUIX_PACKAGE_PATH/patches and put them there? <rain1>I suppose the guix system configure does that <rekado>I just dumped the patches in $GUIX_PACKAGE_PATH. <rain1>so there a way to put info about swap files in there? <rain1>(but also it really seems a shame that 4GB is not enough to do a upgrade...) <efraim>I wonder how hard it would be to add a torrent-fetch or magnet-fetch download method <davexunit>efraim: I don't think it would be too hard. what's a good command-line torrent client? <rain1>efraim, I tried to add a 'local file storage' method -- and then it turned out that the guix builder cant see my users files so it was a waste ... :/ <davexunit>putting local files into the store uses a different mechanism <rain1>I found out about --with-sources now so i'll try that instead <rain1>but yeah magnet fetch is a cool idea <ng_>civodul: I send an email last night with the intention to start a discussion an a patch tracking system, my impression is that we need it. Even if we don't necessarily need it now, the number of messages per day could rise, management other than a mailinglist is needed. <efraim>i like aria2 for torrents, but i bet libtorrent would be better <rain1>although is there much source code on magnets? I heard about gittorrent <davexunit>in an ideal world, we'd write our own minimal bittorrent client that can download things <efraim>there's somehow enough data in a magnet link to recreate the torrent <davexunit>but for practicality, finding a torrent client with the smallest possible dependency graph would be nice. <ng_>rtorrent is not small in dependencies? <ng_>it's the most lightweight client I can think of rn <davexunit>it's pretty easy to use 'guix graph' to compare dependency graphs <ng_>we don't have rtorrent yet i guess <davexunit>or 'guix size' to see total size and how many items are in the closure <ng_>and it has lots of deps. <rekado>rain1: if you're on GuixSD you can define swap space in the operating-system configuration. <ng_>well it's curses based interface <ng_>how can I get the size in graph? <ng_>so aria2 is small compared to rotrrent <davexunit>going down the graph, openssl is a major culprit <rain1>even swap space is not helping much <efraim>aria2 takes an hour to build on my machine, haven't checked its size <rain1>this horrible c++ thing is swamping my system so bad <davexunit>getting rid of that would make the closure much more lightweight <rekado>efraim: your GSoC proposal looks very good to me! I'd love for a bourne-shell compiler front-end to be written! <efraim>i was looking at the list and it looked the most interesting to me <efraim>also, 136.4 is much smaller than libtorrent's 321.9, which may then need a new front-end <davexunit>/lib/perl5/5.22.1/x86_64-linux/Config_heavy.pl <davexunit>any Perl people know how to deal with this? :) <rekado>I wish I could just stop doing $dayjob work for a couple of years and just hackety-hack on fun things <rain1>i cant use a swap file though? <ng_>meanwhile I try to get back to $paidjob in the next years or at least start studying and currently do studying and hackety-hack on fun things and discussions. <rain1>what I would like to find out is which packages do I have installed that depend on mysql-5.7.11 <rain1>I want to remove it completely, but i cant just -r it <rekado>rain1: you can check the referees on the mysql output <rain1>which guix command is used for that? <rain1>I guess what I had in mind was an inverse of guix graph <rekado>"guix gc" with some flags that I always forget <rekado>but as efraim wrote, qt is one of them. <rekado>if you have any qt application you will have mysql as well. <davexunit>mysql should get broken into multiple outputs <davexunit>pretty much anything that wants mysql wants just the client library <rekado>davexunit: Config_heavy.pl is generated at configure time. It's part of the Config module and is supposed to provide all information that was available at build time. <civodul>i wonder if they'd be interested in trying things with Guix <davexunit>rekado: okay, so it's not needed at runtime? <davexunit>rekado: if so, we can remove/hack that file and dramatically reduce the size of a ton of closures in Guix. <rekado>davexunit: I think that would be okay. I'd just want to make sure that there aren't any packages that would reasonably need to have the actual path to the variant of GCC that built perl. <davexunit>rekado: yeah, I know nothing about Perl so I couldn't answer that question. :) <ng_>Speaking of projects/companies interested in Guix, is there something else other than nginx to be fixed what would be needed to have Guix ready for servers, is someone tracking the state of when it might be suitable to present to hosters? <davexunit>ng_: personally I'd wait for a stable release of Guix <sneek>mark_weaver was here Mar 18 at 02:07 pm UTC, saying: kristofer: "guix package -A slock" will tell you that it's defined in gnu/packages/suckless.scm so add (use-package-modules suckless). <rekado>davexunit: "perl -V" also uses these values BTW. <ng_>davexunit: which would possibly include other things I can think of. <civodul>ACTION thinks security-updates is mergeable <civodul>mark_weaver, if you read this, your input is welcome ;-) ***adickpic is now known as junka
<davexunit>I don't think it's worth the cost to keep a GCC reference <rekado>I also wouldn't feel comfortable to use a package that depended on this knowledge. ***junka is now known as junkass
<rekado>it doesn't make much sense in Guix. <rain1>If I try guix package -u with a mirror (tried both I know of), it exits immediately without doing anything <rekado>rain1: are you using the latest version of the daemon? <rain1>I think so, I'll guix pull and try again <rain1>I guess I can't upgrade my system today <davexunit>could it be that you have nothing to upgrade? <rain1>it tried to do upgrades when I don't use a mirror <rain1>but boost wouldnn't complete so I had to try a mirror <rain1>davexunit, (if you are still interested in ring) I tried adding the gnutls patch to pjproject but it seems to not apply and errors there <davexunit>rain1: yeah there seems to be a huge number of patches to apply <rain1>I was just trying this one only first off, and even that failed <davexunit>maybe you could try dropping patches that don't apply <davexunit>and seeing if adding that ones that do apply is enough to fix the build issue <rain1>the gnutls.patch is the one i need for the compile error i got so i went with just that one as a first test <davexunit>maybe the patches have to be applied in a particular order? <rain1>oh boy ... that could be it :S <rain1>this might be not worth it.. <davexunit>they seemed to have patched a *ton* of things <rain1>yeah im not keen on that approach :[ <rain1>it would be nicer if they have their own 'clone' of the repo with apatches applies <rain1>ill give it a whirl with all those in order <rain1>same error, different line endings <davexunit>I would try only applying enough patches to make the build succeed. <davexunit>I thought endianness.patch was enough to get past the current build error <davexunit>the current version of the patch is different than the one I saw yesterday <rain1>The thing is, ring wants to build all its own dependencies and apply its own patches and stuff <rain1>I'm not so keen on that but trying to do it the other way is making things hard <davexunit>well we're certainly going to do it their way. <davexunit>if their patches don't apply, my first guess is that they build against a different version of pjproject <rain1>maybe there's 2 dowloads, one with windows line endings and one with unix <davexunit>that's their code for computing the upstream URL <ng_>got to love bugs: Domain Renewal - - 1 Year/s (01/01/1970 - 31/12/1970) €16.90 EUR ***Basstard1 is now known as Basstard`
<wingo>ACTION just learned that our ocaml package includes a binary. <rain1>oh because it bootstraps from a compiler written in ocaml? <kristofer>I'm confused, I'm running guix system reconfigure, and I wind up building an older version of the kernel than I'm currently running <rekado>fhmgufs: I wonder: do you happen to be working on a GTK GUI for Guix? <rekado>kristofer: "guix system reconfigure" is run as root. <rekado>it could be that your root user does not use the same guix as your regular user. <fhmgufs>rekado: I'm just trying out some things. <fhmgufs>But I would like to do it once I've tried out enough things... <ifur>i'm repeatedly failing to download python-2.7.10 from hydra at exactly 15.3MB downloaded <ifur>that is, the download gets killed after 15.3 MB have been downloaded... <ifur>seems to be a problem with that derivation only, python-3.4.3, any pretty much everything else works fine <rain1>I got ring demon to build now but libringclient depends on qt5 <ifur>for some reason I get EOF at 15.3 MB? <jmarciano>icecat uses firefox for synchronization, why would users trust firefox? Is there no self-hosted synchronization option? <fhmgufs>jmarciano: Maybe ask the people in #icecat <bavier>it is possible to host your own firefox sync <efraim>there are 38 packages that use qt as an input <rekado>ifur: sorry, I don't know. We've been having trouble with the substitute servers for a while now :-/ <efraim>you could add --fallback to build locally/download from upstream if it fails to download from the servers <rekado>...if you have time and a relatively powerful machine. <rekado>building python from source may take some time. <efraim>i think it took me around the same time as building perl <rekado>well, it takes too long on my samsung N148 netbook. <efraim>ah, one of the computers slower than mine :) <civodul>efraim: oh they disable Graphite altogether in the browser <civodul>sounds like the safest thing to do... <efraim>going back to our discussion about magnet-url downloads from ~2.5 hours ago, aria2 would also work for the proposed `download using wget` method <Jookia>civodul: Using Guix to build a tiny Linux distro (without Guile :( ) is going pretty well. Also, I have several people using the coreboot RFC patches happily in the wild, so I think they're stable as they are. I think the review that needs to be done is on design <efraim>for graphite in icecat, closest config flag I can see is --enable-bundled-fonts <rain1>yeah because its there but im trying epiphany too <efraim>I was thinking of trying to port iceweasel over from parabola <junkass>i mean icecat is great but late in security updates <rain1>I would like to just use regular firefox but it wasn't building easily so i didn't try hard <lfam>efraim: I'm cloning the Debian git repo for their ice* / firefox package to see what the change was <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, ng_ says: I rephrased the powwow description and send it to the -devel list. I hope this version makes more sense. <efraim>yeah, I was going to grab it from debian but they switched back to firefox <lfam>I think that the graphite removal will probably apply cleanly to icecat <lfam>The source code repo going to be over 300 megabytes :( I can't download that quickly where I am <civodul>Jookia: good, thanks for the update! <civodul>at some point i'd be interesting in seeing how we can shrink the statically-linked Guile <Jookia>civodul: Me too, from what I know most of it comes from bytecode (I wonder if that could be compressed?) But for now I'm just going with busybox. Can be changed later :) <lfam>erfraim: I can't access parabola.nu for some reason <davexunit>wingo: :/ our Chicken package also uses binaries <davexunit>I'm tempted to advocate for its removal from Guix until upstream resolves <civodul>Jookia: right; at the very least, we could remove a bunch of unused modules, which would save several MiBs <civodul>the 'guile' binary itself is almost 4 MiBs, i'm guessing we could do better <wingo>davexunit: it's a general problem, i think we have to seriously consider what it means to have a bootstrapped compiler in guix <wingo>be it chicken or ocaml or rust or whatever <rain1>I think there is a need for compilers that emit proofs relating source to binary <wingo>i can understand how these language communities get defensive tho, like ocaml is a problem for guix <Jookia>Might have to seriously consider the gruelling process of bootstrapping older versions, though this would mean avoiding a lot of bitrot <wingo>not that their project is problematic ;-) <davexunit>wingo: the rust folks got *really* defensive <civodul>it's tricky, few projects have an extra interpreter written in C, for instance <wingo>davexunit: they did! but i can understand in a way. the context is a mozilla mailing list discussion about firefox, rust, and linux distros. if they are competing and losing against chromium, <Jookia>civodul: But it'd be an extraordinary goal to have reproducible bootstrap binaries be able to build everything in Guix <wingo>i can definitely understand that they don't appreciate questions of the form "what about X?" when X isn't on the path to having a browser with good market penetration <wingo>but still, we have a problem :) <civodul>yeah, obviously the interests differ <wingo>and we will have a larger one if firefox ESR starts to have rust components. <civodul>fortunately, Guix is not alone, the reproducible builds folks in general share this concern <civodul>and i think there's growing awareness <wingo>civodul: it's funny to be in a position where we are arguing for more software to be bootstrappable from C of all languages :P <davexunit>is it in the realm of possibilities that compiler authors will do something about the bootstrapping problem? <civodul>wingo: in a way we're just shifting the problem <davexunit>we're reducing the surface area of bootstrap binaries <wingo>it would be much better if we bootstrapped from ocaml :) <davexunit>which is a shift in a way, but it's a good shift :) <civodul>Jookia: funny, Guile's vm_engine.c triggers an ICE when building with -Os <bavier>civodul: c-reduce to the rescue. <civodul>bavier: bah, i don't have the patience right now :-) <Jookia>Is bootstrapping a freedom issue, a binaries-are-bad issue, or both? <civodul>wingo: the problem is that C++ is used at the core of GNU/Linux distros nowadays <civodul>this significantly reduces the options <civodul>Jookia: i think "binaries-are-bad" is the same thing as "freedom": you want to make sure you run the software you're supposed to run <wingo>Jookia: it's a trust issue in that your build is a function not of source but of source plus binaries, and you can never really verify the binaries <wingo>there are ways to make the binaries such that you have more trust in them <davexunit>at LibrePlanet, the debian developer that gave the "beyond reproducible builds" talk said part of the goal is to change the meaning of free software. software is not free if its not reproducible. <wingo>but they are necessarily less trustworthy than source <lfam>civodul: Should I test the build of openssl on core-updates? It will take a long time! <lfam>Of course I tested it on master <davexunit>civodul: Guix got mentioned a lot during that talk, btw. <davexunit>not in great detail, but 'guix challenge' was mentioned as a tool that he wants Debian to have an equivalent of <davexunit>good confirmation that we're doing good stuff :) <davexunit>I think we slightly frustrated some Debian people with the Guix talk. <davexunit>paroneayea could explain it better because he had the actual interaction, he just told me some details afterwards. <davexunit>civodul: we used Debian analogies a bunch of times in the talk for examples of imperative package management going wrong. <davexunit>and though we mentioned that we really like Debian, it may not have come off as sincere. <lfam>I can see why they wouldn't appreciate that. Although I have had broken updates that require re-installation of the system more than once... <rain1>trashed my entire debian system <davexunit>it certainly wasn't my aim to make it seem like we're in "competition" with Debian. personally, I want to display Docker and friends, not Debian. <civodul>davexunit: yeah there's always a fine line <civodul>but yeah, i think we're very much in line with Debian in a number of ways <davexunit>love Debian socially, but think dpkg is outdated. <rain1>they said they can't make dpkg build determinstically because of tar <rain1>and that upstream ignored their tar bugs <davexunit>they are trying to get a patch into GNU tar for a new flag <rain1>and I think they should switch to a different implementation of tar thath doesn't still have support for stuff like tape drives... <davexunit>where timestamps are never older than the given timestamp <davexunit>I'm not totally sure how that helps them, since we get by without. <davexunit>(unless we are using the same patch and I don't realize ;) <davexunit>rain1: no good reason to not use gnu tar. we're going to keep using gnu tar. <lfam>People *do* still use tapes sometimes <rain1>I'm not suggesting removing tape support from GNU tar <davexunit>I've seen them with my own eyes. the tapes are rather small and can store a *ton* of data. <rain1>just that debian could use a program that implements tar and not lots of other things <lfam>Maybe we could write a GNU guile-tar :) <davexunit>I haven't registered as a mentor yet. can I still do that? <davexunit>I might be a decent mentor for this particular project, if we agree it's a good one. <efraim>I don't know if its too late already <efraim>just program and student deadlines <davexunit>oh I see, I send my application to someone in GNu <jlicht>davexunit: I just handed in that proposal ;-) <davexunit>I have some feedback that I don't have time to write up now, but I'm in support of this project. <lfam>davexunit: Regarding the size of Perl: Since Perl seems to touch everything, you could try building a VM with the change. <lfam>A rather crude test, I know ;) <rekado>found a weird problem on a friend's guix installation. <rekado>"guix package -i lilypond" insists on building lilypond locally but fails <rekado>with an error that we don't see on hydra. <lfam>Huh. I wonder what janneke thinks? <lfam>And your friend's Guix is up to date (that is, with `guix pull`)? <rekado>I just switched it to a git checkout. <rekado>I also updated the daemon and everything <rekado>there are substitutes for lilypond on hydra. <lfam>I've had test failures due to things like filesystems (btrfs) and kernel configuration <rekado>so I wonder why it insists on buliding locally <lfam>And, it's trying to build the same store path as that of hydra? <lfam>Is the hydra key in /etc/guix/acl? <rekado>it fetches substitutes for pretty much everything else. <rekado>haven't compared the store paths; should have done that. <lfam>If the store paths are the same, I would diff the build logs <jlicht>davexunit: looking forward to it. <lfam>If not, then I would diff the dependency graph <lfam>And hopefully somebody else has a better idea ;) <rekado>the configure stage fails because it doesn't detect the fontforge version properly <rekado>it includes the store hash in the version. <efraim>did you pass --localstatedir=/var in configure? <jlicht>I've been bitten by obscure npm versioning shenanigans more than once at work <lfam>Wasn't there just a change to fontforge? Has hydra rebuilt with that change? <rekado>trying to reproduce this on my machine now. <rekado>if there had been a change to fontforge would guix not try to build that first? <rekado>it jumps right into building lilypond and then fails at the end of the configure phase. <davexunit>ACTION sees someone calling us out for packaging things with blobs on twitter, like ocaml <rain1>I just looked on twiter and regret it.. <davexunit>I know it's a real drag, but maybe we should completely remove these compilers until they are fixed <rain1>is there actually a solution that would ever get them back in though? <rain1>the goal is to fix the thompson attack? like that snowden release about how they attcked xcode toolchain <davexunit>but I'm concerned that we're saying that binaries are okay for some compilers but not for others <davexunit>haskell is problematic because people have written a lot of haskell packages already <rain1>it could also be moved into a separate reposity that explains this depends on a bootstrap binary <Jookia>Could the compilers be moved to another repo but have the packages stay? <rain1>ACTION would love to learn more about this <bavier>but currently we must define some sort of threshold, because we also use gcc binaries for bootstrap <Jookia>I think it's kind of unfair to stop packaging things people use because they need to be bootstrapped <davexunit>bavier: gcc is *officially* a bootstrap binary <davexunit>but we do not include all of these compilers as bootstrap binaries <davexunit>Jookia: it's fair when the whole point of our work is invalidated by them. <Jookia>The whole point? Not just a bit, but the whole? <rain1>I don't think this is about software freedom <rain1>It's about the thompson attack isn't it? <Jookia>Is the Haskell compiler nonfree? <bavier>ghc requires bootstrapping from a recent ghc binary <bavier>bitrot quickly becomes an issue when trying to bootrap back too far <rain1>it's really hard to have a useful discussion about this without clear statemont of the goals <Jookia>I didn't know Guix would reject packages that are free but not able to be built without the bootstrap <davexunit>Jookia: well, we don't reject them currently. <Jookia>I know it's a really big problem but I think it's premature to do this <Jookia>Not because I don't agree with it but because it'd be really inconvenient <davexunit>I think we should at least get rid of Chicken <rain1>GHC is so enormous there is no way to be sure it isn't already poisoned <davexunit>I don't think anyone will really be on board with removing it. <Jookia>If it's poisoned, we're all getting poisoned equally <davexunit>maybe we need to be more explicit that Haskell has a bootstrap binary and encode that into the system better. <rain1>that sounds like a solution! <davexunit>because people think they are installing reproducible software when in fact they aren't because we're using a bunch of binaries beyond our stated bootstrap binaries <rain1>maybe there could be a list of 'trusted binaries' in the system configuration <rain1>and the ghc package could depend on it, being impossible to install without trust set <Jookia>Yes, exactly. Binary bootstraps are the worst, but having it being hidden is worse. <Jookia>It could be an interesting experiment to have packages explicitly marked as bootstrap binaries which can be slowly eliminated <bavier>perhaps those origins could be marked somehow, and any dependent packages could fail to build/install unless the user supplies some sort of flag. <rain1>Another approach that would take so much effort it isn't practical is to write interpreters for these languages in guile <bavier>like `guix package --trust-external-binaries -i idris` <bavier>rain1: that could be a longer-term solution, yes <Jookia>I don't know, that flag kind of shifts it to being a feature rather than a bug workaround? <ng_>note to self: saying that you have professional expertise is not enough for nyt and they try to explain technology to you. <bavier>Jookia: I hadn't thought of it that way, I was thinking just to make it explicit for the user. <Jookia>I imagine it'd turn in to a flag that people just pass <rain1>such a tool (being able to mark trusted binaries) leads to a path to get things like binary blobs, firmware in <rain1>which i think is not desirable <efraim>just how bad is the bootstrapping of some of the languages? <Jookia>Bootstrapping GHC isn't that hard <efraim>might fit into "punish the user" but we could mark those languages as #substitutable? #f <davexunit>the developers bootstrapped once upon a time! <davexunit>then they ditched the code instead of keeping it around for others to do. <rain1>the issue is that you need the compiler to compile the compiler <davexunit>because reproducibility isn't something that developers care about that much yet <rain1>even if compile "compiler" = compiler you don't know that its poisoned <Jookia>To humor some ideas: Where does bootstrapping begin and end? Why is GCC okay, but not Haskell? <rain1>which is exactly what the PoC i linked showed <davexunit>GCC is "okay" in the sense that it can serve as *the* bootstrap compiler <Jookia>Is C being the universal intermediate language <davexunit>C is *the* language of UNIX. it's at the core of everything. <davexunit>we can imagine a time when we have the tools to bootstrap a minimal C compiler from native assembly code that can start the bootstrapping process. <davexunit>building up a series of more sophisticated compilers, until GCC can be compiled. <Jookia>All bootstrapping has the assumption that you start from an existing set of binaries, and for Guix a few have been chosen. I suppose the issue is that languages tend not to have multiple ways to boostrap <rain1>I'm not sure I believe in the DDC solution though... <Jookia>This would be very interesting if compilers kept to standards, like GHC requiring Haskell98 and Haskell98 requiring Hugs or something <rain1>sadly GHC ran off on its own and left everyone behind <janneke>how hard can it be to build the haskell compiler with guile? <Jookia>GHC is written in GHC Haskell, not standard Haskell <rain1>janneke, really hard, you would have to do so much work reimplementing the language <janneke>Jookia: does that make it easier, or more difficult? <davexunit>janneke: one sec I just saw a human-sized rabbit hole I can go down... <Jookia>janneke: It means there's no standard language you'd be implementing <janneke>i mean, we have scheme, elisp, ecmascript (almost), ..just add haskell <Jookia>You'd have to write a full GHC-compatible Haskell compiler and at that point why even use GHC <rain1>janneke, this is possible and would work but the amount of effort to do it is too huge <davexunit>you'd need to write a compiler that can handle as much of Haskell as GHC uses <bavier>I think GHC's only commitment is to be able to bootstrap from the last official release <davexunit>speed wouldn't matter really, so you could get away with a naive implementation <Jookia>It would probably be easier to bootstrap using old versions :\\ <Jookia>Which isn't even possible on some systems (ARM) <rain1>ghc3 -> ghc4 -> ghc5 -> ghc-current <janneke>davexunit: hmm, does the haskell compiler have an intermediate language? <rain1>then you just have the problem with ghc3 <rain1>there is an IL called F* used internally I think <bavier>rain1: but then you're chasing bitrot for eternity <rain1>yeah it's not a practical approach <davexunit>that's the situation we're in with Go, I think. <davexunit>we can use gccgo to build an older Go to build a new Go <Jookia>All alternative Haskell compilers require GHC <davexunit>I think more language should do what Guile does <davexunit>write an interpreter in C that can bootstrap the compiler <Jookia>That's probably the right approach <Jookia>One wonders if this is a consequence of complex languages <rain1>I think these issues apply to every self hosted compiler <davexunit>it's good to write your compiler in the language you are compiling, but it's bad to not provide a path to bootstrap from source. <Jookia>I have a headache from all of this, can't imagine how you feel davexunit <ng_>I like the npm proposal for gsoc <adverb>I've been considering applying to guix for GSoC, but I'm a bit intimidated as I'm a novice scheme programmer. Could I still be of use in the project? <adverb>Sorry if this is the wrong place to ask this <fhmgufs>I can say that learning Scheme is not difficult :) (I'm doing it at the moment) <adverb>Yeah, I've been toying with scheme for about six months now, just scared I'd be overwhelmed <adverb>But I'm really a big fan of the project and would love to help out if I could <fhmgufs>adverb: I'd say you should ask civodul or cwebber (mentors), but they aren't here. <adverb>Okay, thanks I'll ask again when they're online <fhmgufs>Just out of curiosity: what do you want to do? <ajgrf>davexunit: not sure what you mean wrt go. even without gccgo, go 1.4 is written in c and is guaranteed by upstream to always be able to build future versions of go (which are now self-hosted) <rain1>guix archive: error: mkstemp!: Permission denied <rain1>I cant make a key for guix archive <rain1>and i can't seem to archive without one <rain1>but I spent all day compiling qt5 so I'm worried I wont be able to save a nar for this <davexunit>ajgrf: so perhaps there is no worry of bitrot! that's good! <fhmgufs>adverb: Ok. I'm not applying for GSoC, but I'm interested in writing a Gtk+ frontend. And I thought that this could be used for the wizard, too. <fhmgufs>But a ncurses installer would probably be better, I don't know. <bavier>mthl: thanks for the more complete solution to the man-page issue <adverb>Well I was thinking ncurses but a gtk+ would probably be better for new users <ajgrf>davexunit: yes, i was really impressed by the way go handled bootstrapping <davexunit>ajgrf: I don't like Go, but I appreciate the way they've handled bootstrapping. :) <efraim>I have what I believe a working gccgo->go1.4->go1.6 chain <ajgrf>also, go binaries have been reproducible since before anybody seemed to care about that kind of thing (well, except when linking to c code) <ajgrf>efraim: why does it include both gccgo *and* go1.4? <efraim>gccgo to compile go1.4, go1.4 to compile go1.6 <davexunit>ajgrf: the huge problem with Go though is that everyone bundles source code to their dependencies <davexunit>we can't fix the static linking issue, but we have to try to unbundle things. <ajgrf>i don't think it will be too hard <davexunit>it's a lot more work than many other languages, though. <ajgrf>go code always puts bundled libraries in the same vendor/ folder. and you can tell by the folder structure where to get the upstream code <davexunit>ajgrf: I imagine there's some environment variable we can set to point to the relevant code? <davexunit>we'd nuke the vendor/ directory from tarballs <davexunit>and set up some search path to point to the unbundled sources <efraim>we could either copy everything into the build dir or try chaining their paths together <davexunit>efraim: I imagine there is a GO_PATH or something <davexunit>and we'd just concatenate all of the source directories together on that path <ajgrf>the bigger problem with go is not the bundling imo, but that nobody tags releases <ajgrf>eventually the go community will probably settle on a package manager that encourages people to tag releases, but right now the `go` tool just pulls from git and uses the latest commit <rain1>I've got a slight problem packaging libringclient <rain1>it seems like you need to set its output prefix to the ring-daemon folder in the /gnu/store, but then it fails on install since of course that isn't writable <efraim>does it try to install to another folder in /gnu/store ? <rain1>there's the daemon and then the client, once I showed the client where to find the daemon it tries to install itself there too <rain1>but they need to be in their separate folders <ng_>So with the next release, I can successfully package rust for guix. This should be next month, looking at their release frequency. <rain1>Does anyone know about this? gtk-update-icon-cache: No theme index file. <rain1>trying to package gnome-icon-theme-symbolic dependency of gnome-ring <jlicht>regarding GSoC, should proposals also be sent to the GNU summer-of-code mailinglist? <rain1>I cant solve the issue with this icons pack <ng_>tg might know about GsoC procedures. <tg>no, you need to do it via the google site <tg>but if you have question before submitting the final proposal go ask the ML <jlicht>tg: I have sent a draft of my proposal to the guix-devel list, in the hopes of getting some pointers before the deadline. Once I feel confident in my proposal, I should then just hand it in via the google site, and that's that? <jlicht>I am actually really looking forward to the possibility of seeing a p2p implementation of substitutes to guix. <jlicht>When I had first heard of guix, I thought it was already one of the features <kristofer>how can I know what kernel version system reconfigure will use? <kristofer>unfortunately the --dry-run argument prints a list too long for me to scroll up and see.. I'm not sure why, but I can't | it to less either <bavier>kristofer: if you don't provide a 'kernel' field in your operating-system declaration, it will be the latest "linux-libre" version <kristofer>bavier: it's strange, but I updated guix from git this morning, did a system reonfigure, and now my kernel version went from 4.4.1 to 4.3.3 <rain1>I'm confused: glib provides /bin/glib-compile-resources <rain1>how do you select a special output in a package inputs list? ("glib:bin" ,glib:bin) doesn't work <davexunit>("glib" ,glib) is shorthand for ("glib" ,glib "out") <fhmgufs>rain1: still having the icon cache problem? <rain1>I didn't fix it but I worked around it <rain1>by editing the makefile to not require icons <rain1>for agood quality package of ring I think it does have to be solved properly <rain1>I found a relevant bugreport, no idea how to actually fix the issue <fhmgufs>Hhm, strange. The normal icon theme doesn't have this issue. <rain1>yeah I just copied their package <rain1>I deleted that package def. should I re-make it and get the error message? <fhmgufs>Wait a moment. I'll look the sources. <rain1>I think it might be fixable if we just pass -t to gtk-update-icon-cache <fhmgufs>The Makefile does exactly the same as the one from adwaita-icon-theme to install the icons. <rain1>maybe this could be an issue about determinsm <lfam>efraim: So, should I try to use your Go packaging to build a Go program? <lfam>I saw in the log that you think you have a working package ***Basstard1 is now known as Basstard`
<lfam>efraim: Cool, I'll try for Syncthing :) <lfam>If it works, then I'll be thrilled! <rekado>davexunit: "no one really uses [Chicken] yet" <-- that's because our package didn't build for a long time. <davexunit>chicken includes programmatically generated c code for bootstrapping. <rekado>I would have loved to have a working Chicken a couple of months ago when I wanted to try Ugarit. <rekado>is there a version of chicken that doesn't require it? <lfam>There *must* be a way to generate that C code ourselves. Somebody is doing it on their side, right? <rekado>could we package that version and then use it generate the bootstrapping code? <rekado>lfam: with a previous binary, probably <rekado>just like C compilers are built with C compilers. <rekado>I'd love to fix this and reduce our dependence on bootstrapping to just Guile. <davexunit>I talked to one of the chicken people on hn and they didn't understand why I thought their machine generated c code was not ideal. <rekado>but we aren't even close to that. <lfam>davexunit: Maybe rather than trying to convince them we are right, we can just convince them to explain how to generate it on our own <davexunit>chicken should have a simple interpreter that bootstraps the compiler <lfam>That way, we just seem silly to them rather than aggressive or confrontational <rekado>few people see this as a problem; we don't need to convince them; we just need to find a way to get around this. <lfam>I mean, it would be best if they agreed with us, but that seems much harder than just convincing them to share some knowledge <davexunit>it's hard to work around this problem without upstream involvement <Jookia>Isn't machine generated C code equivalent to binaries since it's not the preferred source of modification <rekado>davexunit: I found that many people on hacker news are simply not interested in discussing. <rain1>a chicken compatability library in guile scheem seems easiest <lfam>If we want to convince them to spend the time to explain to us how to generate the C code, we should do it via their preferred method of communication, and limit the question to a request for information <lfam>I'm not surprised they aren't receptive to outsiders asking them to upend their infrastructure <lfam>That's like when people ask us to add /usr/bin/env ;) <Jookia>What if their generator is written in Chicken? ;) <rain1>I don't know how to make sourceforge links <rekado>Jookia: it certainly *is* written in Chicken. <lfam>Jookia: Sure, that would be annoying. Do any of us know the details yet? <rekado>rain1: do you mean using mirror://sourceforge/...? <lfam>rain1: That's always hard for me. I don't know if there is an easy way or not <Jookia>rekado: Oh, so that doesn't seem to help the bootstrapping process if you need chicken to generate C code to bootstrap chicken <fhmgufs>rain1: The issue with the icon-theme package is a bug. <rain1>fhmgufs, did you catch my link i posted all the build log and stuff <rain1>thank you for looking into it! <rekado>I just hope we get a hold of the last version of chicken that didn't require bootstrapping with chicken (or pre-generated C code). <rekado>then we can use that to build a more recent chicken, until we can generate the C code by ourselves. <paroneayea>davexunit: here's a "serious troll" though: using a ./configure from a package is really not far off from what Chicken has done in terms of providing a lot of pregenerated source <lfam>paroneayea: Yeah, I agree <paroneayea>someone else generated that masive configure ball of who knows for you <fhmgufs>rain1: There's a script create-icon-theme.sh that should generate the icon theme from the git repository. <lfam>But I don't find it very problematic <fhmgufs>Maybe they forget to run it when they make the tarballs. <rain1>I could try to include a phase that runs that script <Jookia>paroneayea: I don't know, you can generate the configure scripts using the Guile bootstrap binaries can't you? <fhmgufs>rain1: If you use the git repository as the source. <rain1>for now I can't seem to get anywhere with this sourceforge dbus-c++ <davexunit>paroneayea: the key difference is that I can run autoreconf and produce that myself <paroneayea>davexunit: also we *don't* do that currently, and maybe we should as much as we can re: autoconf <lfam>What is the bootstrap ./configure script of our system? ;) <davexunit>no because you need chicken to generate chicken <lfam>paroneayea: So far we have actively chosen not to autoreconf <Jookia>Do you need autoreconf to generate autoreconf? <davexunit>you don't need ./configure to generate ./configure <fhmgufs>rain1: I think you just need to create the index.theme file in a new phase before installing. <davexunit>mark_weaver thinks we should do more autoreconf stuff on our own <paroneayea>I'm not actually *that* worried about this but it does seem like something to think about <paroneayea>I'm glad to hear mark_weaver is thinking about it <Jookia>davexunit: If we consider ./configure and other generated code 'binaries' then there's a little bit of the same issue, no? <lfam>For now, we treat un-configured tarballs like minor bugs <fhmgufs>But I don't know how you can easily add this file. <lfam>I'm not crazy, right? There is not equivalent to #:make-flags for the python-build-system? <rain1>huff I dn't like sourceforge <rain1>I've tried about 8 different permutations of c++ and cplusplus and none finds the mirror <lfam>Also, I'm setting up a caching mirror for personal use. I'm wondering... how could I get locally built in-development packages into the cache? Sometimes I do very expensive experiments. <rain1>it doesn't build the dring binary because dbus-c++ is not building <lfam>ozzloy: Hmm, that's not what's supposed to happen ;) You say you are following those steps. Have you completed them yet? <ozzloy>lfam, sorry, i gtg, i'll be back in like 2 hours <lfam>ozzloy: Okay. Somebody will be around. <lfam>For the record, I just did `guix pull` to test and it worked fine <rain1>$ guix build dbus-c++ --with-source=./libdbus-c++-0.9.0 <rain1>guix build: warning: transformation 'with-source' had no effect on dbus-c++-0.9.0 <rain1>Can't I use --with-source to make a local change to source code? <rain1>There is a bug in the program that I can easily fix locally <civodul>that is, you have to rename the source tree to "dbus-c++-0.9.0" <rain1>thanks but I still can't get it working with that <rain1>I also tried making that directory into a tgz and <rain1>--with-source=libdbus-c++-0.9.0.tar.gz ***Basstard1 is now known as Basstard`
<bavier>lfam: you'll want to remove the #t at the end of the lambda, so that the result of the 'and' is returned instead <bavier>also, I think the result of 'install-file' is undefined <lfam>Yes, that's my understanding <bavier>so you might need (begin (install-file ...) #t) instead <lfam>Previously, there was only one command-line, so I used (when ... ) instead <lfam>Hm, actually I'm sure that's wrong. Sorry to waste your time without testing first <lfam>mark_weaver: Nice domain :) world.peace.net <mark_weaver>lfam: I just discovered that webkitgtk-2.4.10 has been released! <lfam>Is that an update? I thought we were on 2.10.8 <bavier>lfam: adjust the indentation of the body of the 'begin' <mark_weaver>lfam: yes, but the older 2.4.x series, which some programs are still stuck on, hadn't received an update for a long time. <lfam>Ah, I see. Good thing it's still receiving updates <mark_weaver>(the API changed significantly between 2.4 and 2.10) <lfam>Do you need any help? I will go AFK soon but I could start a build <lfam>bavier: Sorry to be so dense, but can you say how it should be adjusted? Does the #t need to be moved to the right? <bavier>lfam: yeah, in line with the opening '(' of '(install-file...' <lfam>Okay, thanks a lot for helping me :) I always appreciate when people share their knowledge with me! <civodul>right in time, i was checking the status of security-updates ;-) <civodul>it's all built on x86_64, icecat & emacs included