<JeanLouis>how do I remove package? cannot find in help <paroneayea>mark_weaver: briefly I tried imagining how a completely root-less gnu guixsd system would work and my brain flopped around on the floor like a fish <mark_weaver>no, it just builds a new profile that's the same as the current profile but without those packages. <mark_weaver>JeanLouis: "guix gc -d" can be used to remove specific paths from the store, but it will only do that if it cannot see any references to those paths from other places in the store (or /var/guix/gcroots) <JeanLouis>I was expecting if I do -i emacs -- to get binary emacs, not the ony that was compiled without gdk-pixbuf incorrectly <mark_weaver>JeanLouis: what do you mean by "that was compiled without gdk-pixbuf incorrectly" ? <JeanLouis>(emacs-24-5:28561): Gdk-CRITICAL **: gdk_cairo_surface_create_from_pixbuf: assertion 'GDK_IS_PIXBUF (pixbuf)' failed <JeanLouis>and I cannot remove package, cannot get binary normally. <mark_weaver>JeanLouis: our 'emacs' package depends on gdk-pixbuf. it would not try to build 'emacs' until after 'gdk-pixbuf' was successfully compiled. <JeanLouis>I did not really try to build, guix did that automatically. <JeanLouis>if I try to remove it, it won't work. I am thinking in equivalent to apt-get purge package <mark_weaver>if you run "guix gc -R /gnu/store/...-emacs-24.5" it will print out all the things that it references, directly or indirectly. if gdk-pixbuf in that list? <JeanLouis>I have gdk-pixbuf. Now I got emacs-no-x at least is that one solution, that I don't need to use -nw flag <mark_weaver>anyway, if you want to delete the package from /gnu/store, you first need to delete all other references to it in the store (e.g. any profile generations that include it), and then you can run "guix gc -d /gnu/store/...-emacs-24.5" <JeanLouis>too hard to understand. I am testing guix to learn to use it for long time later. I rather not work by hand. <JeanLouis>ok going to bed, never mind... tomorrow is the next day. <mark_weaver>there are additional complications when running Guix on top of another distro. <mark_weaver>I've never heard a report of this problem on GuixSD, anyway. <mark_weaver>it might be some missing environment variable setting <mark_weaver>to debug it, you might run emacs within strace and see where it's trying to load its icons from disk. maybe something is going wrong there. <JeanLouis>when IceWm, newest PostgreSQL, and some Perl modules work, ROX Filer, Wmbiff -- I am switching. <mark_weaver>(although it's surprising that one of the icons is loaded correctly) <JeanLouis>maybe tomorrow, good bye... (remaining on channel, sleeping...) <suitsmeveryfine1>I used rain1's configuration with encrypted /home (/dev/sda2) and made this interesting observation: with a bare-bones config I can type in the LUKS password and log in normally, but with a desktop configuration the keyboard doesn't work when I'm asked for the /dev/sda2 password. <mark_weaver>suitsmeveryfine1: you might have used two different versions of guix to create those two systems <mark_weaver>it's worth noting that every version of guix includes an older version of itself <suitsmeveryfine1>yes, that seems to be the case because the newer version had an older kernel (4.4.4 (alpha). <suitsmeveryfine1>I ran `guix pull` and I'm reconfiguring again based on the same desktop definition. <mark_weaver>so, if you don't run 'guix pull' (or equivalent) as root, then every time you "update" your system with "guix system reconfigure", your version of guix will get older with each iteration. <mark_weaver>we include a cryptographic hash of the source code of every package in guix. <mark_weaver>given this, we cannot make a version of guix that includes the same version of itself, because that would require computing the hash of a tarball that includes that hash within itself. <mark_weaver>which would require solving an equation HASH = SHA256 (tarball containing HASH) <mark_weaver>I have no idea how to solve that equation, and I suspect it is not feasible to do with current computing resources. <mark_weaver>I can imagine some hacks to work around this problem, but I'm not sure it's worth it, because really you need to update your system anyway. staying in the same place is not much better than going backwards. you need to keep up-to-date because security holes are being publicized all the time. <suitsmeveryfine1>Well I thought running guix pull wouldn't be necessary since I had done it just an hour or so earlier. <Jookia>It shouldn't be unless you're in a new profile <mark_weaver>anyway, I've spent a lot of time here. time for me to try to get some real work done now. happy hacking, all! <Jookia>myglc2: Do you have adwaita-icon-theme installed <suitsmeveryfine>For the record: I was able to input the password after my second reconfiguration. <suitsmeveryfine>Now I happily run GuixSD on my desktop computer that I otherwise don't touch. <Jookia>Probably, I did a bit of a GTK patch to fix themes not working when they're in packages but I'll be redoing it to work better. I wonder if GTK would actually like it upstream? Who knows <Acou_Bass>Jookia: does this mean xfce themes will now work? i asked about this earlier i think wasnt sure if it was you who answered hehe <Jookia>Acou_Bass: Yep, works on my machine. <suitsmeveryfine>Does this mean that you can download third party theme and they will work also? <Jookia>Well they already kinda work if you put them in ~/.themes - this only applies to packaged themes <Acou_Bass>i put mine in ~/.local/share/themes and they didnt work <Jookia>suitsmeveryfine: Which theme, from where <Jookia>if it requries xfce theme engines it's possible it won't be able to find them <suitsmeveryfine>ok, well I just tried this since you said packaged themes might work already. <Jookia>But if you're on a machine that can compile things then you can test to see if a patch would help <Acou_Bass>my laptop is a bit too slow to compile BIG things reasonably but if its fairly small ill be happy to test it hehe <Jookia>Acou_Bass: For testing? Hmm, it depends. You just need to recompile GTK and an application to test to see if it fixes the issue. Though if you were to use the patch for all your desktop you'd need to recompile basically everything that relies on GTK <Jookia>I suppose you could also graft it to replace GTK <Jookia>Which would be a 'fun' test of grafting ;) <Acou_Bass>ive been on guixSD all of a week and have no idea how one goes about grafting anything manually <Jookia>Me either, I'll have to see if I can work up a new patch that does some intermediate grafting since I need people to test it <Jookia>What machine are you running it on? <Acou_Bass>probably about equivelent to a rasp pi 2 in actual horsepower <Jookia>I have a dual core thinkpad from 2009 I think that runs leaps and bounds around a raspberry pi 2 <Jookia>I know this because my main machine has the same power as an raspberry pi 2, and it takes muuuuuch longer to recompile GTK <Acou_Bass>heh well i just found my laptop on a review site dated 2008 <Acou_Bass>so i guess its not THAT old, but even then it was relatively poor, not a high-end machine :P <Jookia>I also have an eeepc but I don't compile much on it due to RAM issues <Acou_Bass>i think its one of those first-gen windoze vista machines that were crippled by vista being so much heavier than XP <Acou_Bass>works perfectly with linux-libre though so no complaints regarding compatability ;D <Acou_Bass>and is fast enough as an emacs machine which is pretty muchall i use it for <Jookia>I certainly feel like a wolf in sheep's clothing around here since I don't 'get' Emacs <Acou_Bass>theres not much to get, i type text in one end, run lilypond in the other and a pretty PDF pops up <Acou_Bass>im not one of those guys who uses emacs for EVERYTHING though ;D <Acou_Bass>can i make a query by the way (to anyone here) - how am i supposed to get the LSH client to connect to an OpenSSH server? is it possible? XD <Acou_Bass>i can get my openssh client to connect to LSH server but not the reverse <Jookia>Acou_Bass: You need to use a flag, let me find it <Acou_Bass>been banging my head on the wall trying to figure that one out *duh* <rain1>I found a nice program and I am trying to package it <Jookia>mark_weaver: Noticed you replied to my email just now on the GTK+ patches: I'm working on getting it to read XDG_DATA_DIRS in GTK+3 <davexunit>surprising that it doesn't respect XDG_DATA_DIRS to begin with. <Jookia>davexunit: Yeah, I'm thinking of submitting the patches upstream to GTK <davexunit>curious what the GTK maintainers would have to say. I fear it may be a controversial change. <Jookia>It would probably be an API-breaking change since there's ~/.themes and gtk_rc_get_theme_dir() which is one directory <rain1>just making it support a colon separated list of paths seems hard to get upset about <Jookia>So themes won't be able to get their proper path <Jookia>Might be worth breaking in GTK+3 though <Jookia>This kind of makes behaviour odd since themes won't be able to use GTK's API to find where they live anymore <Jookia>Any packaging gurus here? There's a project I'm packaging that doesn't mention license aside from a COPYING file including the GPLv3 <Acou_Bass>quite sad that i run that same theme on all my machines, i just cant find a better one :D <Jookia>I've been running clearlooks since 2009ish <Acou_Bass>and i guess theres no reason it wouldnt work with icecat hehe <Jookia>Themes can change web pages? Or is just the IceCat thing <Jookia>ajgrf: It's not in the README either, there's no mention of any licensing aside from COPYING <Acou_Bass>ohhh no it doesnt change the web page, just the browser chrome itself, which i assume the GNU icecat frontpage thing follows in some way :P <Jookia>Woo I packaged my first working Guix theme! <kristofer>has anyone successfully installed remotely? I've a box, but strangely, no keyboard or monitor handy <Jookia>kristofer: I don't see why SSH wouldn't work <Jookia>If you can run a live CD, that is <kristofer>I need it to get an ip automatically and spawn an ssh server with a known password <Jookia>Well, I'm sure there's live CDs out there that will do that <Jookia>I installed using a siducer live CD, though I had to manually start SSH :( <Acou_Bass>cant you just SSH using thehostname as opposed to an IP? (does the liveCD have a default hostname?) <Jookia>You can use any live CD to install Guix <Jookia>Or if you can resize partitions to make room, the same system you're on <paroneayea>Acou_Bass: Guix and MediaGoblin in one link! Thrilling :) <Jookia>So it looks like I have a lot more patching to do :( <Jookia>This may be a shocker but we'll need to patch Freeciv to get GTK themes to work <rekado>JeanLouis: you may have more success with epiphany. <JeanLouis> Peer attempted old style (potentially vulnerable) handshake <Jookia>rekado: I replied to the GTK patch email thoroughly <rekado>Jookia: the mail hasn't arrived yet, but I'll check again tonight <Jookia>Ah okay. Just to note, it updates to use XDG_DATA_DIRS and includes a page or so of discussion about what the fundamental issues are and how other applications handle them <Jookia>tl;dr: We'll have to patch Freeciv <JeanLouis>turned off ssl_require_safe_negotiation and now SSL works, but how safe? <efraim>t1lib doesn't seem to be downloadable from upstream, archlinux's aur points to a mirror on ibiblio.org <janneke>i would like to try a patch on guile-2.0 that world uses (incl. guix) <janneke>is there some way (grafts?) to do/hack that without rebuilding world? <Acou_Bass>paroneayea: you may be sad to hear im hosting it on a Pi 3, stupid unfree hardware drivers :( but yep i love the goblin! ***keverets_ is now known as keverets
<suitsmeveryfine>Jookia: I'm trying to apply your GTK+ patch now but I have difficulties. <Jookia>suitsmeveryfine: yo what's the problem <Jookia>if you run 'git log' do you see the commit <Jookia>suitsmeveryfine: hmm, i'll have to see what's needed to be done. if you have a whole bunch of changed files to do with gtk when you run 'git status' you may be fine <suitsmeveryfine>oh wait, these are untracked files now: gnu/packages/patches/gtk2-theme-paths.patch gnu/packages/patches/gtk3-theme-paths.patch <Jookia>yeah just try building thunar or something with that change, if you're ok with compiling. tomorrow i might do one that uses grafts so you can use it with substitutes <rain1>I found thunar crashes a lot and use pcmanfm instead <Jookia>suitsmeveryfine: did you build guix in this checkout <NiAsterisk>with the patch I did send you could ignore the individual gnunet-gtk patch and just use the large one, but things would not break if you apply both <Jookia>suitsmeveryfine: nope, run ./pre-inst-env guix package -i thunar --cores=<numcores> <Jookia>replace <numcores> with 2 or 1 or how many CPU cores you have <NiAsterisk>also, sorry for the size etc, that's the best I could do with limited time and it was all in one commit, no way for me to do this in some other way. <suitsmeveryfine>Jookia: It didn't work; selecting a different theme under Appearance doesn't change Thunar. <suitsmeveryfine>Jookia: I can apply packaged themes across the whole DE, but selecting the various built-in themes has no effect including on Thunar. <paroneayea>Acou_Bass: hardware choice could be better, but I'm still happy to hear of MediaGoblin adoption, so I'm not sad. Thank you! <mark_weaver>"I’ve been in touch with Midori, but they say they don’t have the resources to fix it, since it would require rewriting large portions of the code base in order to be able to use the fixed webkit." <rain1>I have very very little faith in the CA stuff behind HTTPS but this is interetsing nonetheless <rain1>webkitgtk/gtk+-2 is what I compile it with <mark_weaver>a number of programs are in the same situation. unfortunately, that webkitgtk hasn't had any security updates for a long time. it has lots of known vulnerabilities <mark_weaver>I would strongly recommend avoiding using anything that feeds data from the network to that old webkitgtk <rain1>shall i t be removed from the guix packages? <rain1>I brought this up in #midori <mark_weaver>unfortunately, that would mean losing some important packages, including gnucash and shotwell <mark_weaver>and it's not clear that those programs feed network data to webkitgtk. <mark_weaver>I'm not sure you're wrong. maybe we should remove the old webkitgtk and all the programs that depend on it <mark_weaver>but I would say that no one in their right might should use a web browser that's stuck on the old webkitgtk, because that's a case where the engine is being exposed to potentially hostile network data all the time. <paroneayea>mark_weaver: hm, is epiphany on th eold webkitgtk? <mark_weaver>no, epiphany is using the latest webkitgtk. it should be fine <NiAsterisk>speaking of webbrowsers: idk if I was thinking out loud about this on the weekend, but I looked into torbrowser vs icecat vs iceweasel, and I think I can do a torbrowser fitting for GuixSD, it looks easy enough but I can't guesstimate when I could be done <mark_weaver>NiAsterisk: it would need to avoid at least as many bundled libraries as our IceCat package does, and also avoid suggesting that the user install nonfree software (e.g. media codecs or plugins/extensions), to comply with the GNU FSDG. <rain1>you could make a package def. that isn't in guix itself <rain1>but can easily be used by other people <mark_weaver>I would much prefer to have something that complies with the FSDG added to Guix itself. <dmarinoj>I like mark_weavers idea, it would be nice to have it in the repo <NiAsterisk>my plan is to use torbrowser (not compatible to the version of ESR icecat uses according to what I read) and patch it in comparasion to what I find out about licenses etc. the ideal case is the essential basics don't break when I patch out the non compatible add ons <rain1>I just don't think you can expect cooperation by those people.. <rain1>as you are aware any patches you do may decrease it's anonmity <mark_weaver>in what way is it not compatible? my recollection is that torbrowser is based on Firefox ESR, just like IceCat <NiAsterisk>of course I would talk to other people with torbrowser packaging experience I know and see if my packaging is reliable <rain1>since not many people use guix this is dangerous <NiAsterisk>MPL and New BSD are the most obvious licenses used in it <mark_weaver>rain1: anything at all that's different from the official torbrowser may have that risk, so if you're paranoid about that, you should just use the official torbrowser <NiAsterisk>an open ticket in their trac is to use Nix once it is fully reproducible. <mark_weaver>rain1: but on the other hand, there's also a risk that torbrowser is based on Debian, which has a long history of things like individual developers uploading binaries compiled on their own machines <NiAsterisk>mark_weaver: which is why I said, I will check, let other people check on what I produced to not only rely on my judgement, and then include a statement in the description <rain1>I suppose the key thing to focus on is, what is the goal in packaging tor browser <NiAsterisk>current torbrowser pull firefox esr from redhat infrastrure <rain1>if you aim for anonimity then you may have to compromise on things like free software compliance <NiAsterisk>currently there's no other focus for me thern to check which parts aren't working for us if there are some <NiAsterisk>and if so, do they affect the browsers fingerprint <NiAsterisk>I'm not going into this blind and just publish :) <dmarinoj>rain1: I do not think this will be an issue, I think the only reason that torbrowser-launcher is in debian contrib is because they fech the updated package directly from the torproject website <NiAsterisk>the talk Snowden gave in the BCC in berlin had something weird.. like a floating image above people at the conference, speaking against surveillance etc all in a building constrcuted in times when Stasi used to be around in east. <paroneayea>I'm not sure I'm thinking about it in the context you are <paroneayea>but it might be true that on a sufficiently decentralized and anonymous network, something like AGPL compliance could be very hard. <rain1>I think that the people who make tor browser will not cooperate with things the guix project would like <rain1>they are very "I know the right way to do it, it gets done my way" <rain1>i've seen things like they do not provide a download link anymore <NiAsterisk>both contain ways to download it. i don't see your problem <NiAsterisk>I think a torrent distributed file with checksums is a download link <NiAsterisk>I would just like to check the browser, and if there are problems talk to the unit of torproject dealing with the browser. <NiAsterisk>and if I then get feedback after a reasonable discussion, then I can say "they don't care about compliance" <dmarinoj>NiAsterisk: Like I was saying, take a look at what debian found first because I'm pretty sure it was at least DFSG compatible <NiAsterisk>I only read through the sources of torbrowser, icecat yesterday night on the bus while driving home.. reading on debian didn't come up my sleepy mind :) <NiAsterisk>some tickets on tor's side read like getting security patches into firefox upstream is very hard and seems to be the only reason for local patches included <NiAsterisk>also what we did in gentoo (not portage) was a post-install message like: "this patched firefox build is _NOT_ recommended by Tor upstream but uses the exact same sources. Use this only if you know what you are doing!" etc etc <paroneayea>the primary ones I'm familiar with are tinyfugue and tintin++ <NiAsterisk>currently unpatched, i need to get some deriviate for patch with the patched source so it can be easier used for chat only. <NiAsterisk>and if you want more, the ones in krosos.sdf.org/static/guix/guix.org under MUD / BBS are all the MUD and BBS in the free software directory <NiAsterisk>paroneayea: I will package powwow-chat later as some kind of powwow which just changes defines.h:#define CMDSEP ";" to "§" so this could be better used for telnet only chat, just in case you are curious. <NiAsterisk>my initial description assumed that lynX did almost no changes and provided only a config for psyced.org use. <mark_weaver><rain1> if you aim for anonimity then you may have to compromise on things like free software compliance <NiAsterisk>dmarinoj: okay, looking at packages.debian.org and debians policy on "contrib" archive area, I just have to assume that it is compatible. <NiAsterisk>just want to check to be sure if I miss something. <mark_weaver>I would go further and say that using only free software is a prerequisite to having any assurance of anonymity, because it's not practical to verify what nonfree software is even doing <NiAsterisk>in case of torbrowser-launcher in contrib: *: MIT, apparmor/*: BSD-3-clause, debian/examples/*: Expat <NiAsterisk>would the torbrowser being pulled in not be compatible to contrib policies, it would not be in there <NiAsterisk><"Every package in *contrib* must comply with the DFSG"> was there a difference between DFSG and FSDG? <dmarinoj>NiAsterisk: the link has info about DFSG <mark_weaver>FSDG is more strict in some ways (e.g. by requiring that users not be steered toward nonfree software), and less strict in other ways (e.g. looser rules for non-functional data) <lfam>Were substitutes recently garbage collected? I'm getting a lot of surprising rebuilds <lfam>For example, there doesn't seem to be a substitute available for python-cryptography't <lfam>And yesterday when I generated a VM, I had to build what looked like everything <mark_weaver>lfam: yes, hydra is currently doing a garbage collection <lfam>mark_weaver: Okay, thanks for confirming <lfam>Also, for python-cryptography, looks like my local update to python-hypothesis is triggering the rebuild (it's a build-time dependency for testing). But it didn't show up with `refresh -l` so I didn't expect it. <lfam>mark_weaver: Does that mean we are really getting to the next release?! <mark_weaver>I think we don't have nearly enough disk space on hydra, and possibly also that our current methods for choosing which things to remove from the gcroots is not sufficient in a case where we haven't done a core-updates cycle in a long time, as is the case now <mark_weaver>the recent stream of security updates has caused us to postpone core-updates for an unusually long time, and I think this is exposing problems in our retirement strategies on hydra <lfam>Do you mean that we can't provide substitutes for a wide enough range of our git history? <lfam>Because I definitely have the problem locally ;) <mark_weaver>the bigger problem may be that we are retiring substitutes that haven't been built in over 60 days, and that in this case that might include some core packages that are needed by current master. <mark_weaver>historically, we've done core-updates cycles more often than every 60 days, I think. <lfam>Oh, I was thinking that we would be leaving new 0.9.0 users behind before releasing 0.9.1. But if we are GC-ing parts of current master, that's too bad <mark_weaver>but I think for the first time that I can recall, we've not done a core-updates cycle in a long time, because of all the security-updates churn <lfam>Is substitutes storage limited by our current hydra.gnu.org front-end VM, or is storage delegated to the build machines? <mark_weaver>well, I've restarted the builds on hydra, including the security-updates branch (which eliminates grafts in the hopes that 0.9.1 can be graft-free), so I guess that may end up rebuilding things that have been lost and are still needed. <mark_weaver>substitutes storage is limited by the master machine, hydra.gnu.org <lfam>Well, soon there will be a new release, and then a new machine! Things can only get better, right? :) <mark_weaver>our storage requirements have been steadily increasing over the last year, but our disk on hydra has remained fixed <mark_weaver>at this point, we're waiting for libreboot to be fixed on the KPGE-D16 motherboard <lfam>Yes, I remember seeing that mentioned in the logs recently <mark_weaver>a lot of people are waiting on that, including the FSF which just bought a bunch of KGPE-D16 machines, so I'm confident it will be fixed soon. <mark_weaver>the new hydra is fully built and literally just waiting for that <mark_weaver>(and then we need to get the hydra software installed on it) <lfam>This is a change of subject, but I think we should look into updating python-setuptools. We are at 18.3.1 and 20.2.2 is available. I wish I had thought of this a couple of weeks ago. <lfam>At least, it could go into the next core-updates cycle <lfam>I recently noticed another Python package that claimed to depend on some newer version. It seemed to build fine anyways, but we should try to keep up before it gets too painful <lfam>Most of the Python programs I've built seem relatively inexpensive, although a few do have some lengthy test suites. <efraim>built python-cython recently? :p <lfam>efraim: See, this is why I bring it up in public ;) I've never built that <Acou_Bass>can i ask a slightly dumb question? whats the 'recommended' way of updating the core system, is it just guix pull and then guix system reconfigure mything.scm? <phant0mas>can someone that runs linux on a x86_64 machine try to build avr-libc and tell me what happens? <lfam>Acou_Bass: Yes, that's the recommended way. Since each user has their own copy of Guix, you will have to run `guix pull` as root in order to reconfigure with the new changes. You'll probably also want to `guix pull` as your regular user as well. <lfam>phant0mas: avc-libc from current HEAD? <lfam>phant0mas: Sure, it's running <phant0mas>efraim: it will probably have to build avr-binutils, avr-gcc and avr-libc but with most of their options off <phant0mas>I am starting to have nightmares with the avr-toolchain <lfam>Oh no! One must share their suffering in order to overcome it in my opinion ;) <lfam>efraim: Yes, it loads for me from North America <efraim>ok, might just be blocked on tor then <lfam>:( Why would they do that <efraim>it makes me worried when sites fail to load and I'm seeing if there's an update <efraim>here's a fun question: why does grub have a dependancy on libcddb? Is there a grub theme with background music? <lfam>That's an interesting dependency! <rain1>the blog by Michael Catanzaro is excellent and eye opening <lfam>I wonder if CDDB has information about non-music CDs (i.e. distro installers) <lfam>rain1: Yes, I think it lit a fire under some distros ;) <rain1>guix package: error: build failed: build of `/gnu/store/g24hawnfg52gsxwzvk46fhmicm23lmgh-avr-libc-1.8.1.drv' failed <rain1>fatal error: gnu/stubs-32.h: No such file or directory <phant0mas>rain1: great, that's exactly what I as expecting <phant0mas>it seems avr-libc needs glibc for some header files <phant0mas>I will report back when I have something useful <efraim>good news! we already have graphite-1.3.6 <efraim>the 14(!) CVEs are 2016-1977, 2016-{2790..2802} <lfam>I want to use a custom test phase and also run it after the install phase. Is the best way to do this by deleting the check phase and adding a new phase? <janneke>lfam: you can set something like #:test-target "check-release-candidate" <janneke>ah and then you'll have to move it, i see... <lfam>Yeah, not a common use case <efraim>I think it'd be easier to delete and add a new test phase than to modify foo-build-system to move 'check to after install <lfam>efraim: Yes, I don't want to modify the build system. I'll do the delete and add-after. <lfam>I think we also need to work on updating pytest. python-hypothesis works differently with the current version of pytest. I tried the other day but it was complicated... I can try again later <suitsmeveryfine>Hi! I'm trying to package OpenTTD but I get this error when running "./configure": <suitsmeveryfine>"I couldn't detect any strip binary on your system. Please define the CC/CXX environment to where it is located" <lfam>suitsmeveryfine: Based on a quick grep of existing packages, I see that we have to provide the path to strip in the icedtea-6 package. Try adapting that to your OpenTTD package? <suitsmeveryfine>lfam. Icedtea? That sounds strange since OpenTTD is not a java program <lfam>I don't think it's Java related. Rather, the paths are hard-coded and so we tell it where to look. <lfam>For example, it might be looking in only in /usr <lfam>suitsmeveryfine: Do you see the line in the icedtea-6 package definition where the path to `strip` is provided? I'm suggesting you try something similar for OpenTTD. It has nothing to do with Java. <suitsmeveryfine>lfam: no, sorry, I can't find it, and I only see icedtea 2.6.4 and icedtea 1.13.10. <lfam>On git commit 03422bf83444f, it's line 351 of java.scm <lfam>You might have to fetch the latest from git. I pushed that commit a couple of hours ago. <lfam>No, that line is setting the variable named STRIP with the value of `which strip`. That is, with the path to `strip`. <lfam>You'll need to figure out how you can pass this value to the configure script. Maybe `./configure --help` will tell you that there is some variable. Or, you might want to augment $PATH. I'm not sure, it really depends on OpenTTD's build system. <suitsmeveryfine>Okay, but I don't believe that I have strip installed in the first place <lfam>You can also check the package definition of popt for a simpler example <suitsmeveryfine>I guess that I should do some more reading before trying to package anything <lfam>I don't know for sure, but I bet that `strip` is an implicit input. That is, it is always available in the build environment. <lfam>strip is provided by binutils <lfam>Well, you can do `guix build binutils` and then look for strip in the result of that. But in the package definition of OpenTTD, all you need is `which strip` <lfam>Assuming that I am correct that binutils is an implicit input. Otherwise, `which strip` won't work because strip won't be available. <lfam>suitsmeveryfine: Well, it sounds like strip is also required, since the build fails without it. <lfam>Upstream rarely knows the full dependency graph of their software, in my experience. <suitsmeveryfine>It's in /gnu/store/6ngzcw2s3spvn9sb2hb9i9dhpmn4nk5j-binutils-2.25.1/bin/strip <lfam>Yes. But that path will change over time. That's why you'd use `which strip` to get the path at build time. You can't put the store path in your package definition. <rain1>I have an idea for a little script for guix <rain1>just to easily search the gnu store for specific files <rekado>rain1: like "find /gnu/store -name something"? <rain1>I was thinking about basing it on that <rain1>but the gnu store changes so often <rain1>it would be hard to make a database.txt stay updated <rekado>rain1: you could wrap the guix command and make it update the database whenever things are added. <rekado>or you could use inotify to look for the creation of new files and then add those files to the db. <rain1>I wonder if it would be nice to do that, or an annoying overhead <rain1>also maybe it doesn't matter what the current users packages are -- the database.txt could be generated from all packages <rain1>but i would have to run a build server to do that I think <rain1>maybe it has to be based on the user store, because the hashes might be different <rekado>dunno. Not sure how useful that would be unless it were done by hydra or as something on top of guix publish. <rekado>JeanLouis: have you tried packaging stuff for Guix yet? <rekado>usually we just package whatever we need. <rekado>it's not very difficult to do. It's unlikely others will package just the right software you want when it's not very popular software. <JeanLouis>I packaged my-mutt, it works. But other version of mutt remained, I expected that it is deleted. <lfam>JeanLouis: You need to do this `guix package --remove mutt --install my-mutt` <JeanLouis>I am now learning Scheme and Guile, once I have enough knowledge, I will make packaging definitions. It will be my pleasure. <lfam>JeanLouis: The first time I wrote Scheme was when I made some Guix packages. A beginner's knowledge is enough for simple programs. <JeanLouis>lfam: great! I started with Guile, than rewrote some perl scripts already to Guile. I want to re-write all my stuff to it. <lfam>It sounds like you are making good progress! <lfam>JeanLouis: #guile might be a better IRC channel for questions about Guile <rekado>JeanLouis: according to that article it's using Common Lisp. <rekado>JeanLouis: to learn Scheme I recommend either the Guile info manual or The Little Schemer. <suitsmeveryfine>lfam: I managed to insert the absolute path to "strip" in the `config.lib` file and it let me go further. <lfam>Okay, good! Whenever the rest of the issues are ironed out you can generalize it. <suitsmeveryfine>Now it complains that zlib can't be find and this time I can't do the same because the code looks different. <lfam>Does `./configure --help` offer anything useful? <lfam>I would grep the source code for zlib to figure out if there is some variable you can set or patch to provide the right path. <lfam>The build process uses Make? You might have to set some #:make-flags with the paths <lfam>If I were you I read grep for #:configure-flags to get a sense for how they are commonly used. You will probably find what you are looking for <lfam>Erm, I would grep, not read grep <lfam>I think that most packaging problems have been solved in other packages by now. We just have to read :) <suitsmeveryfine>lfam: I found this configure flag for an old Ubuntu version: `--with-system-zlib=/usr` <rain1>would you like to paste your package so far? <suitsmeveryfine>rain1: I'm not writing a package definition but simply try to build the software in my home directory. <lfam>suitsmeveryfine: Okay, then you'd want to set the value of --with-system-zlib to the path to zlib, in #:configure-flags. You can look at the package definition of dvtm for an example of something similar. In that case, the value of PREFIX is being set in #:make-flags, but the mechanism is basically the same <rain1>were you using guix environment? <suitsmeveryfine>lfam: so I could simply run ./configure with a lot of flags attached for the various libraries? <rain1>try something like guix environment <similar-package> --ad-hoc zlib <lfam>I would add --pure, so that your host system's libraries don't get used <rain1>might also needautoconf automake <lfam>And then you can keep adding thing with --ad-hoc as you need them. <lfam>You can "layer" the environments in that way <suitsmeveryfine>I'm sorry but I don't understand this. I've only used the environment to set up a git checkout that I can build the system from <lfam>Yeah, without a WIP package definition for OpenTTD, `guix environment` might be hard to get started with. I always start with a package definition <lfam>You might want to read the manual on `guix environment` if you haven't <lfam>And also look at what it does to your environment (run `env` before and after), in order to really figure out how to use it. <suitsmeveryfine>I thought that I'd be able to easily build the package out of tree, but now I see that it might be easier to do it differently <lfam>Heh, I almost never build out of tree. Only when I'm desperately troubleshooting <lfam>* ARM U-Boot and EFI ports. <lfam>Hopefully those changes will help us run GuixSD on ARM! 