<ng0>i like how atom and therefore apm builds with npm and the gentoo ebuild (not in portage) just lets it build like it would, without solving npm somehow, just letting npm be. <ng0>or maybe it's doing something i don't see, but there's an endless list of "installing" scrolling by <ng0>normally it's just an endless list of compiling in gentoo <lfam>Now that I have a real GNOME system, I can pick up GNOME Maps again <lfam>Wish I could use it already — I need directions to the place I am going tonight! <rain1>lfam, oh someone was asking for gnome maps! <rain1>I think it will be a much appreciated package <ng0>there's also gnome worldclock module for activities/calendar i've seen in recent debian <lfam>I'm going to let it build for a few hours. The result will probably not work, but then I will ask for help on the mailing list <ng0>npm has what emerge does not have (at least build in), progress bars. <lfam>paroneayea: Did you have to do anything to make the GRUB menu usable on your x200? It's scrambled on my x200s <ng0>ACTION just building apm and npm and atom to build N1 to prove or disprove a point on a mailinglist. <lfam>Oof. Starting the Maps build. Downloading bison, cmake, etc... <anthk_>lfam I tought all Gnome packages were built in a simillar way since they are official <lfam>anthk_: Could be, this is my introduction to GNOME. <lfam>Our packaging of the GNOME world is still a work in progress (although it seems to be progressing very quickly!) <anthk_>I wonder if sysprof could work with GuixSD <lfam>anthk_: That looks like a good thing to package for Guix! <ng0>npm deprecation module messages are good sometimes.. "please use $thatotherthing. It is much better." <ng0>oh. i just stumbled into npm hell with trying to build N1 :/ <efraim>sneek: later tell rain1 you can access freenode through tor at irc://frxleqtzgvwkv7oz.onion <jmarciano>is there a GuixSD based repository of sources for binaries? <efraim>the sources are cached on the substitute server and the mirrors, but otherwise they are pulled from upstream <jmarciano>so, the principles of distribution in GuixSD do not yet comply to the GPL 2, as example. <jmarciano>as each respective license shall be aligned with GuixSD type of distributing the software <jmarciano>no, distro shall be aligned to licenses, shall conform to licenses <lfam>jmarciano: You can download the source used to build each package with `guix build --source foo` <jmarciano>from where it is downloaded? I guess from the original server of source code, not from GuixSD, right? <efraim>jmarciano: from GuixSD it'll try from the substitute server, and if it doesn't have the source cached there then it'll download it from upstream <efraim>in this situation you mean that we provide the source and the binary <efraim>if you have binary substitutes set up and you download the binary we should have the source. but if for some reason we don't have the source (ie low disk space) then it'll fall back to downloading from upstream <jmarciano>I only mean that as such, distributing GPL2 packages is not in conformance. Other licenses I did not check <efraim>if you don't have subsitutes set up then guix provides neither the source nor the binaries <jmarciano>they are provided from multiple servers right, corresponding sources shall also be provided. <jmarciano>or - the written offer for 3 years, which means, that there must be corresponding sources for each of versions compiled <jmarciano>further, patches... patching is modification, it shall be done also in conformance to GPL2 for GPL2 software <civodul>Guix & Nix are the only systems that really provide the Corresponding Source <civodul>also, Guix distributes neither source nor binaries; instead it distributes executable recipes to fetch these <jmarciano>I understand what you mean. But substitute is binary? <jmarciano>so, these substitutes do not conform to GPL2, because, there must be corresponding source to them. <civodul>by definition, with Guix, if you can fetch the substitute (which has an unguessable URL), then you can also fetch the exact corresponding source <jmarciano>I see, the definitions construct the sources, but those are not sources. <jmarciano>with 3 years offer, GuixSD would need to provide for server storage to keep all the sources (not necessarily to offer them for download) <jmarciano>There must be new functions to be made in GuixSD, such as "storing sources somewhere" or "providing for for download", or "providing written offer" <jmarciano>GuixSD distribution was designed more for non copyleft licenses. But violates copyleft licenses. <civodul>jmarciano: i respectfully think this is wrong <civodul>you should carry strong accusations like this <jmarciano>that you think it is wrong, I know. That is why I bring up important issue on GPL violation <jmarciano>Specifically GPL 2, while GPL3 I did not fully review <jmarciano>the problem would not be there, of course, if each user would build from sources. Then only binaries from GuixSD would need to be provided as sources depending of their licenses. <df_>if whenever the binary substitute is available, the source is also, guixsd would appear to be covered by section 3a <jmarciano>that was my first question, where is it? Maybe I don't understand it. <df_>if I understand efraim correctly the substitutes server caches sources for the binaries it builds <jmarciano>df_: do you know GPL2? Maybe you should first see it. <df_>I have it open in front of me <jmarciano>OK, so hydra and other servers distribute software, right? <jmarciano>while GPL3 does allow to point to third party servers, GPL2 does not. <df_>yes, both source and binaries <civodul>again, Guix satisfies section 3a *by construction* <df_>I just ran guix build --source hello and it downloaded the source from hydra <jmarciano>yes, I see "by construction", I am sure that people can construct the source. Only that such construction is now allowed for certain license like GPL 2, it has to be accompanied with the complete corresponding source code" <df_>ok I'm gonna try once more <df_>there is a tarball on hydra containing the complete corresponding source <df_>like I say, I tried hello, but I assume for any package that hydra builds <df_>I have just done exactly the same for linux-libre <jmarciano>what is exactly cached and offered for download? The original source code? <jmarciano>like the one with has in the package definition? <civodul>more generally, derivation outputs are cached <jmarciano>I have just got it downloaded from mirror.hydra.gnu.org <jmarciano>where can I download the corresponding source code for aria2? This is very nice example. <lfam>If you run the command `guix build -S aria2`, you will get the source code that was used to build the binary you just downloaded <lfam>It will be downloaded onto your computer <jmarciano>I got aria2 package downloaded. It has the same hash like from the original location of the source code. <jmarciano>so it is cached version of the original source code. <jmarciano>if there are any patches to such packages (which I don't know, I was just reading definitions), those are modifications. <jmarciano>and then the substitutes are distributed without corresponding source code. <jmarciano>Which can be constructed, but is not in conformance with GPL2 <lfam>If there are patches, they will be applied to the source code that is downloaded. <jmarciano>sure, but that is not in conformance to GPL 2 <jmarciano>if patches were applied to generate substitute, then the corresponding source code is not offered <lfam>I don't know the terminology. My interpretation is that the patched code was used to build the binary, and thus corresponds to it. <civodul>right, derivations are the corresonding source in the strictest sense of the word <civodul>i realize we probably don't have good introductory material about this <jmarciano>so, when patches are applied on hydra, there is source code containing such modifications, available to download? <lfam>Yes, and it is used to build the binary substitute <jmarciano>Let me see, where do patches come from? From source code? Or from where? <jmarciano>btw. in case of aria2 package, not even the license is given, could not find it anywhere <lfam>jmarciano: It's in aria2's man page <jmarciano>well sure, but then you have to really understand section 1. as section 3. (substitute) ask for section 1 "conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program" <jmarciano>in this example, I got substitute, but not the copy of the license. Reference in the man page is not a copy of the license. <jmarciano>lfam: when patches modify the original source code, I get substitute, but where is then the corresponding source code to accompany the substitute in accordance with GPL 2? I hope you understand this and you will read GPL 2. Of course I do understand that I can "construct" - very nice, but it is not in conformance to license. <lfam>I think you should send a message to the mailing list <jmarciano>actually I hoped this was solved, I was rather questioning <rekado>jmarciano: the patch sources are part of Guix. <rekado>when you use "guix build -S" you get a tarball with the patches already applied <jmarciano>I am not asking for myself. I know where can I get sources, or that I can construct them. That is however "description" how to ge corresponding source on his own computer. It is not "accompany with the corresponding source". So it violates GPL2 <jmarciano>I asked to give me example, so you can give me example, where is the source code for substitute which was patched? <civodul>patches are just one aspect of what goes into the corresponding source <civodul>Guix captures everything, including build scripts, dependencies, etc. <civodul>there are 3000+ examples in the distro :-) <jmarciano>it should be simple to give the link to corresponding source, of the modified software (like patched one), under GPL2. <civodul>as people already told you, "guix build --source foo" gives that <civodul>"guix build -d foo" gives the super-complete corresponding source <jmarciano>so there is distribution of substitute without accompanying source code, which is against GPL 2. It should be solved. <rekado>jmarciano: it seems we are miscommunicating. What do you expect? Why do you consider "guix build --source foo" to be a violation of the GPL 2? <jmarciano>Section 2, (a), source code is not distributed under (a), (b) there is no written offer, (c) there is no offer. <jmarciano>I just say, if there is derivation, which I understand as modified from original, or patched, such derivation shall accompany the object/binary or substitute. <jmarciano>of course REGARDLESS if one uses GuixSD or guix package manager. <civodul>i think Guix satisfies the requirement, more than any other distro in fact <jmarciano>if you think so, give me a link on hydra to derivation. <civodul>if you'd like to pursue this discussion, make sure to read more about derivations and substitutes <jmarciano>you gave me example of derivation. I did not check the example. I assumed it is true. So if derivation is modified, patched source code, or original source code, it shall accompany the binary. <df_>ooh, I didn't know there was a paper <civodul>and/or rephrase your answer to rekado <civodul>because here it goes "why do you think it's violating GPL2? - because it's violating section 2" <jmarciano>rekadod did not tell me, not to understand it <jmarciano>when source is patched, after that substitute is compiled and offered for distribution on Hydra. I cannot find source code for that. <rekado>jmarciano: you get the patched sources via "guix build -S foo". <jmarciano>or simply, let me know the link to 6mwfwrcmy62v02p911dyywhslqayama5-pulseaudio-8.0.tar.xz on Hydra? <jmarciano>guix build -S pulseaudio gives me the link on /gnu/store/6mwfwrcmy62v02p911dyywhslqayama5-pulseaudio-8.0.tar.xz <jmarciano>but where is link on Hydra? I did not get binary from my computer. I got it from Hydra. <jmarciano>I am not a pope. I just wish to have perfect distro! <jmarciano>df_: you speak of building, I speak of distributing. <df_>10:59 < jmarciano> or simply, let me know the link to 6mwfwrcmy62v02p911dyywhslqayama5-pulseaudio-8.0.tar.xz on Hydra? <jmarciano>do I get the source code that is modified in that manner? <rekado>jmarciano: do you mean that the binary substitutes for GPL2 software should also include the tarball of the sources? <rekado>jmarciano: yes, the sources you get from hydra are the patched sources. <sneek>Welcome back rain1, you have 1 message. <sneek>rain1, efraim says: you can access freenode through tor at irc://frxleqtzgvwkv7oz.onion <jmarciano>if I remove nvi patches, to other place, guix build --source fails with: guix build: error: nvi-assume-preserve-path.patch: patch not found -- so I can still assume that the modified sources are not distributed and not accompanied with the object/executable form distributed by hydra <jmarciano>second one is produced by: guix build --source nvi <ng0>i have doubts about the .onion .. but if it works, why not. I have found my ways to work around freenode. <rekado>jmarciano: you cannot remove patches by deleting them from gnu/packages/patches. That's not how this works. <rekado>the patches are referenced in other places. That's why you get the error. <rekado>I'm just telling you what the error means <ng0>jmarciano: what exactly are you trying to understand <jmarciano>OK, let us forget patches. Did you understand the test that I have done after that? <jmarciano>so that experiment with patch removal is not correct, but on the other hand, I could wget the package and compare to the one that I get with --source, so they are not the same -- source code is not accompanying the object code. <jmarciano>Source code can be built, created, but that is not a distribution. <rain1>I've been finding the 'union' after i install or remove a package is taking a really really long time these days <rain1>I've done gc and even deleted all my old revisions <rain1>anything i can do to speed it up? <jmarciano>can it be that file ends with .xz but is bzip compressed? <rekado>rain1: union takes long when you have a lot of files in the profile. I found that having libreoffice in the profile makes the union step unbearably slow (amplified by NFS) <rain1>I don't have libreoffice but I'll have a good look for anything related to remove <rekado>jmarciano: the two may differ when you are using a different version of Guix. The hash depends on that. <rekado>when you do "guix build -S" you get the URL of the cached sources. <rekado>it doesn't matter how you download the archive. <rain1>wow jmarciano what are you doing dude <rain1>your post on gnu-linux-libre <rain1>"Violations of GPL in GuixSD" <ng0>how long did this take ? did you even read the paper civodul pointed you to? <ng0>(rethoric question, i don't have the time to engage in discussion) <ng0>rain1: look on the bright side, guix is getting that popular that people like jm. get here. <suitsmeveryfine>Hi! I'm trying to (for the first time) package a game but I've run into some difficulties. <rain1>if you called the package that <ng0>if it's in the sourcetree: ./pre-inst-env guix build openttd <ng0>suitsmeveryfine: where did you locate you package? <ng0>in a selfcontained file or in git-checkout of guix? ***Basstard1 is now known as Basstard`
<ng0>you ran make clean-recursive ; ./configure --localstatedir=/var ; make ? <ng0>then you should have the pre-inst-env in the root of the checkout <ng0>this is described on one of the manual pages, let me get the link <ng0>chapter 8, contributing <suitsmeveryfine>I'm already building my system from a git checkout so that's already set up <ng0>then i don't know, it's not how i do it <ng0>this is just how i do it, i work from a git checkout which is not connected to my system <rain1>oh i think that's similar to a git commit id <rain1>I think version should just be 1.6.0 - you might wan to look for a release tarball instead of using SVN though <rekado>rain1: bleh, that email is all over the place... so many assertions. <ng0>suitsmeveryfine: it has release tarballs <ng0>linux generic binaries gzip archive on the download page <ng0>not better but prefered unless there's a reason for not to use the tarball <ng0>let me download it to look at it <rain1>Iis there a way to 'profile' the union to see which packages are making it take so long? <ng0>suitsmeveryfine: i am not 100% sure, but i think you want to build it from svn in this case <ng0>the tar.gz doesn't look like it provides a way to build it <ng0>but please check it yourself again <df_>out of interest, why are release tarballs preferred? I'd have thought that using revision control would make it easier to get hold of the latest version to hack on <ng0>i can't really tell, i prefer that too, but i guess something about stability. <ng0>github is incredible slow today.. building and installing opendungeons takes hours <df_>they had an outage yesterday, maybe someone is ddosing them again <ng0>extreme centralization of a good to decentralize programm <suitsmeveryfine>ice-9/eval.scm:387:11: Throw to key `srfi-34' with args `(#<condition &invalid-base32-character [character: #\\o string: "5qbx6oqoadjzslfs7bug4vp3plutidnwkg5pv2mz5cmmixlnfgoa"] 90f1b40>)' <rekado>suitsmeveryfine: this means that this is not a good hash. <ng0>suitsmeveryfine: can you paste the package somewhere or send a patch to the list I can look at? <rekado>suitsmeveryfine: how did you create the hash? <ng0>for svn it is likely that the same as for git applies, checkout, remove something like .git/ folder and then guix hash -r folderofcheckout( <rekado>I never had to set "--format". I usually just download tarballs with guix download. <rekado>when you have some SVN checkout I recommend first downloading it with svn. <rekado>you could also just take an invalid hash and then let guix build tell you that it's wrong. <rekado>but you'd have to use a hash that is in the correct format. Any hash from any other package should be fine. <ng0>version needs something appended i think. like (version "0.0.6.svn$revision" <ng0>that's all i see. for svn and hash, i would just try and see if using git to interact with svn works, like clone it through git svn (of course onlsy the revision you want (entire project gnunet svn is 14 years of code for example, took me 1 day I think) and then delete .git/ <suitsmeveryfine>"To help people who want to manage their own patches we also provide a git and Mercurial (hg) repository" <ng0>the checkout for shallow clone of svn with git would be long <ng0>i just need to wait until it finished <ng0>takes to long. so this was it: git svn clone -s -rNUMBER:HEAD URL -t 1.6.0 where NUMBER is revisionnumber and URL is https://svn.openttd.org <ng0>of course you need guix package -i git:svn <ng0>or git with svn build on any other system <htgoebel>Hi. I'm tying to start a vm using the example coming with guix: `guix system vm gnu/system/examples/lightweight-desktop.tmpl`. <htgoebel>The vm is build and started, but after mounting the file-system and initialization of random, nothing happens. Then after 30 seconds, the machine shuts down. <htgoebel>I also tried desktop.tmpl and bare-bone.tmpl with the same results. <htgoebel>Any hints what may go wrong here? (It's the very first time I'm using qemu or kvm) <civodul>htgoebel: is this what happens when running the "run-vm.sh" script returned by 'guix system vm'? <civodul>who wants to reply to jmarciano on gnu-linux-libre? rekado? mark_weaver? <ng0>theoretically: cd to svn.openttd.org/ , then rm -rf .git/ , cd .. , guix hash -r svn.openttd.org/ <ng0>you should get 0nbn2m8il74jwiymq15z6z68q1mrqmafvzr2id4ajphcdhcvhyw7 as a hash <rain1>is there any need to even reply <htgoebel>civodul: Where should this script reside? When running `gui system vm ...` the vm is directly started. <civodul>htgoebel: 'guix system vm' builds the VM image, but to do so it needs to build a VM, indeed <civodul>htgoebel: could you paste the output of 'guix system vm gnu/system/examples/lightweight-desktop.tmpl'? <ng0>that is what the svn in package is doing <ng0>i only adopted it to git svn <htgoebel>civodul: Curious: On a second (or third) run it only prints /gnu/store/9psiacd2izbzhkd44jhglw8qwl8dc0ww-run-vm.sh <suitsmeveryfine>ng0: I tried just to enter the hash you provided and ran `make clean-recursive ; ./configure --localstatedir=/var ; make` <civodul>htgoebel: so everything is fine :-) what you saw was the build log leading to that run-vm.sh script <civodul>now you should start run-vm.sh to actually get the VM you asked for <htgoebel>Wow and now, when running this script, the vm opens up a gui and boots there <civodul>i see why this is confusing though :-) <ng0>civodul: rain1: yes someone should comment on this, as people are already answering to jm's assumptions. <htgoebel>civodul: I'll add this to my wishlist: After buildnt the VM terhe should be a *big* message stating that you need to run the script :-) <htgoebel>civodul: Thanks so long :-). I'm going back to my main job now. <ng0>suitsmeveryfine: haven't looked at the paste yet, but don't run the commands if you don't know if your way to work is equal to mine. it might work, but it works for me. currently I can't run my system from git checkout. <civodul>bah, my emacs gets stuck in x_get_foreign_selection for several seconds when i try to paste stuff <ng0>suitsmeveryfine: there might be a problem with the package. i'll look at it <ng0>suitsmeveryfine: are there versions other than 1.6.0 or why do you point to /tag/1.6.0/ ? <ng0>i'll see what happens without 1.6 <suitsmeveryfine>ng0: yes, there are others but this is the lastest stable version. I thought I should refer to this rather than just the current master. <ng0>can you clone it again and tell me what the git log message is you see? <ng0>date and time is enough <rain1>I tried th package and this happens <ng0>okay, try that suitsmeveryfine <suitsmeveryfine>I still get a lot of errors when I try to run ` make clean-recursive ; ./configure --localstatedir=/var ; make` <suitsmeveryfine>I'll remove the openttd definition entirely and see if it might be due to something else <ng0>suitsmeveryfine: did you build packages before without this? I repeat, this is the way which works for me on my system, it might not work for you <ng0>just do what you do to rebuild your checkout but have the package included in it <suitsmeveryfine>I've always run either `guix package -i packagename` or `sudo ./pre-inst-env guix system reconfigure /etc/config.scm` from the git checkout <ng0>you might ask someone who is running it from a checkout then, i don't <suitsmeveryfine>I think I might have messed up the games.scm file somehow because I still a lot of errors even after removing openttd <ng0>alezost: is it? have you looked inside? <ng0>for me it looked pre-compiled <alezost>ng0: on the download page there is a list where you choose "source" <ng0>on gentoo, equery g --depth=200 kde-plasma/plasma-meta-5.6.1 gives a nice view on how tough packaging kde plasma might be on guix <ng0>forgot some switches <ng0>but the graph is long <civodul>this is really a DoS attack against us, and it works! <rain1>yeah sometimes you gotta ignore trolling... <mog>davexunit, what are you making? <davexunit>ACTION not sure what this refers to, can think of many things he is making <mog>davexunit, with the ps2 controller <mog>i stalk you on twitter <davexunit>I am converting a PS2 controller is a USB HID joystick <mog>using a mcu or just a straight usb hid controlller? <davexunit>replacing the microcontroller with an AVR running free firmware that I'm writing. <mog>yup i am familiar with the part <davexunit>prototyping with an arduino leonardo, will use a different board for the real thing. <mog>ya 32u4 is pretty big part for a controller <mog>but always good to start big then go small <mog>ya but i mean an 8u4 would probably work as well <davexunit>but being able to flash via USB is very valuable to me <mog>ahh id figure you were making a whole board <mog>i agree usb is where its at <mog>8uf is same chip just smaller memory on the die <rekado>davexunit: is the avr gcc toolchain working for you? <rekado>(I have one of these AVR serial programmers, never flashed via USB) <mog>rekado, its so easy especially with lufa stack <mog>but i often still just use icsp as im lazy and its standard across all avrs <davexunit>currently using my Novena that runs Debian to do the development <davexunit>rekado: you might have missed this, but on Monday I was able to build avr-gcc in a guix environment and it compiled correctly! <davexunit>however, the problem persists with guix build <davexunit>something is different about the environment there and I'm not sure what it is. <davexunit>the version I built in a guix environment container had 16 variants for libgcc.a <davexunit>mog: yeah, I am learning to use LUFA for the firmware. it's great. <davexunit>rekado: phant0mas and I inspected the config.log from each environment and they are more-or-less identical <mog>davexunit, guix needs the cross compile stuff debian has <rekado>I don't know what LUFA is. I only ever wrote plain assembly to program the AVRs. <davexunit>makes it very easy to write things like a USB joystick <mog>most fun thing i did was a fake storage device <mog>something very silly about an avr being a drive ***boegel|quassel is now known as boegel
<phant0mas>davexunit: awesome hack with the ps2 controller :-) <phant0mas>rekado: we have to study how gcc decides what to build when targeting avr <mog>davexunit, if you port guix to novena i will run guix at my house. <davexunit>mog: I installed the Guix ARM port on top of my Debian system <mog>hmm i guess thats good enough for me <mog>i currently just have debian on mine <mog>running a file server and some other home services <davexunit>I'm currently frustrated by the Novena because more things require using FPGA blobs than I originally knew about <mog>just the fpga needs blobs? <davexunit>it's really frustrating that the general-purpose breakout board needs an FPGA blob, so I haven't used it. <davexunit>mog: the expansion slot is managed by the fpga <mog>the blob is freesoftware its just the compiler that isnt <davexunit>and FPGA reverse-engineering is beyond my abilities <mog>i still need to play with icestorm stuff <mog>get something cool running on it <mog>but i have little to no practical need for fpga niftyness in my real life <davexunit>but I did manage to translate some tables in a PDF document into C code for the pin out. <davexunit>but as far as producing bitstreams... no idea. <mog>i played with that too, but couldnt get it to work on my part <mog>i had a x9 and not hte 45 he used or something i cant remember <mog>but couldnt ever get my flip flops to work <mog>ended up getting evil chain working on a server that i sent code to and got blob back from <mog>made me feel less dirty <davexunit>phant0mas: I need to take another dive back into the avr-gcc build sometime soon. <davexunit>if you look at it before I do, please report back. :) <Jookia>o/ I'm packaging Doom stuff for Guix <Jookia>So far it's been fun dealing with wxwidgets, cmake, sdl <Jookia>protip: if your project has its own -config program, stop <rekado>so much time lost on custom configure scripts <rekado>(this keyboard has unreliable key switches) <Jookia>chocolate-doom uses sdl-config to find SDL's libs and cflags, checks if sdl-mixer, sdl-net can be linked, then promptly fails because neither of the latter are in SDL's cflags <Jookia>not as bad as wxwidget's cmake calling 'sh /gnu/store/...-wxwidgetsorsomething/bin/wx-config' <Jookia>and failing in my build env because sh isn't in my path <Jookia>why would it call sh just to load an executable i dont understand, no other cmake scripts do that <Jookia>its also fantastic seeing that chocolate doom has a --penis-extension flag to 'enable counterproductive compiler optimisations' <Jookia>thats exactly the kind of joke that belongs in software <rain1>haha, is this a new feauter in chocolate doom <rekado>Jookia: well, I guess it's good that children write software. <davexunit>we made that package specifically for this sdl-config case <civodul>efraim: did you try building stuff on core-updates after the Binutils upgrade? :-) <Jookia>Is there a way to specify packages in --ad-hoc using guile expressions? <civodul>Jookia: yes, using -e, as in: guix environment --ad-hoc -e '(@ (gnu packages foo) bar)' <Jookia>can i have multiple -e s and mix it with non-e stuff? <civodul>efraim: i'm asking because ld seems to be failing in strange ways <efraim>i just checked it out and i told it to build out to offlineimap, which should get us full base and both(?) pythons <davexunit>"binutils 2.26 should've never had happened." <davexunit>there's probably some nix issues or something hanging around somewhere <civodul>the error i have is that it fails while building GCC, exiting with code 1, but not printing any error message <davexunit>the binutils folks should use guix to integration test new releases! <civodul>domenkozar: ↑ do you have more details on what failed for you with Binutils 2.26? :-) <rain1>what is the problem with binutils? <rain1>upgrade breaking things is a tough problem <rain1>I could not resolve the problem with upgrading python <rain1>I think it has to wait for python developers to fix the code <efraim>any suggestion with the error "gtk_clipboard_get_for_display: assertion 'display != NULL' failed" from a test suite? <quiliro>this is my 3rd attemp to install guixsd <quiliro>i have an error but installation continues this time <quiliro>it says... failed to create path for auto-compiled file "/*gnu/store/....bin/guild" wrote on /gnu/packages/....go <Jookia>hmm, sdl-union's sdl-config doesn't really help <Jookia>davexunit: is it meant to make sdl-config output a different include path? <davexunit>Jookia: yeah, well, it makes it so that all of the header files are in a single directory together <davexunit>rather than spread out amongst many store items <davexunit>and that satisfies things that build with sdl <Jookia>ah, well chocolate-doom uses sdl-config to find sdl and assumes sdl-mixer is in that location <Jookia>so ill have to patch chocolate-doom <davexunit>Jookia: I don't follow. sdl-union makes that so. <Jookia>sdl-config --cflags points to just sdl's include dir <quiliro>the other times i tried to install guixsd with "guix system init /mnt/etc/desktop.scm /mnt" but it didn't work...i did not have time to stay where there is internet so i didn't even copy the error even to <quiliro>and i thought the download would be recorded to the disk <quiliro>is there a way i can make an offline installation? <davexunit>Jookia: are you including other sdl packages as inputs or just the union? <davexunit>maybe this is a case that the union doesn't work for, but it's solved every other sdl problem so I'm skeptical <davexunit>I can't really help you dig too deep right now (working on bugs at work) <davexunit>but if it's not working, just try patching it as you were going to do <davexunit>maybe we can find something to change about sdl-union <Jookia>davexunit: Looks like sdl-config is a shell script with a variable I can substitute. Shall do <ng0>interesting, gentoo is planning to remove /usr , discussions going on for almost a year now <quiliro>i had a prvious fatal error with desktop.scm....is it working? i understood there is no gnome in guixsd <rekado>quiliro: unfortunately, I don't know how to fix your problem <phant0mas>davexunit: I found that there is a list for avr-gcc avr-gcc-list@nongnu.org <rekado>is it part of the output when running "guix system reconfigure" or "guix system init"? <davexunit>phant0mas: is there some build logs that would be useful to them that we could send? <phant0mas>davexunit: we can send them the config log of the two builds and explain them what is the problem :-) <phant0mas>"Hey there we have these two near identical gcc config logs, the one doesn't build the rest of the avr libs, everything is the same, any ideas?" :-) <quiliro>rekado: "guix system init /mnt/etc/light-desktop.scm /mnt" <quiliro>failed to create path for auto-compiled file "/*gnu/store/....bin/guild" wrote on /gnu/packages/....go <quiliro>it is a repetitive error with different files <anthk_>an easy introduction to guile/scheme, not being SICP nor GNU info docs? <df_>the guile manual is very good imo though <rekado>anthk_: the Guile manual is actually really nice. <rekado>but since you wrote "nor GNU info docs"... <rekado>maybe the little schemer, but that's pretty basic and somewhat repetitive. <ijp>also not free as in cool free ringtones <rekado>I know it get's more interesting, but I find it a bit frustrating. <davexunit>rekado: it's definitely not written for more experienced programmers <davexunit>maybe The Seasoned Schemer would be more up your alley <ijp>maybe we are getting to the stage where there needs to be a "basic guile for guix" tutorial <ng0>somebody would have to write that though.. <davexunit>yeah I think that tutorial would be very nice <ijp>I wonder what the "peak experience" for writing tutorials is? <ng0>now we only have asorted info all over the internet about guix <ng0>definitive a chapter for advanced knowledge/time: write good system services. <rain1>all over the internet? we could collect it all into one location <ng0>i try to revise come next december and see what I learned and where I made notes, where beginners problems are, but that would be from the perspective of someone not completely new to the syntax and definitely not new to packaging in general. a beginners guide in our sense would have to pick up people whee they are, giving also the option to pick them up at 0 <df_>I have found it quite hard to grok various guixy concepts, but not particularly to do with guile/scheme <rain1>it's good if everyone takes notes on what they learn and merge it into a document <df_>sounds like a job for a wiki <davexunit>a wiki could be used as a place to draft something, but all official documentation belongs in the manual <rain1>df_, yeah i put up a wiki for this <davexunit>I recommend just using the libreplanet.org wiki <Jookia>I have forgotten the command to patch shebangs from a terminal <Jookia>guile -e '(@@ (guix build gnu-build-system) patch-source-shebangs) #:source ".")' seems to kinda work <rekado>davexunit: yeah, the other Schemer books are on my list; wanted to go through them once I'm done with SICP, but first I'll have to finish a couple of bioinfo books. <ijp>SICP is nice, but for people who want to just learn scheme, it's really inefficient <Jookia>i have sdl-union fixed and now i have chocolate doom running in guix! <rekado>the stuff on syntax in "the land of lisp" (I think) was not so bad. But I didn't enjoy the book that much. Too much imperative programming, too much Common Lisp. <davexunit>I flipped through realm of racket in a bookstore recently, it was pretty neat looking. <davexunit>I don't know if anything can beat "Grand Theft Wumpus" in Land of Lisp, though <rekado>maybe I'm just boring, but I didn't really like that. <Jookia>one advantage with guix is that we could package old versions of WADs and use 'guix environment freedom@0.9' then run your favourite doom client with an old wad <rain1>Jookia, that would be so cool! <Jookia>'guix environment --ad-hoc odamex freedom@0.10 freedom@0.9' would allow for playing older versions online however there's the caveat that you can't really select which version with any of the GUIs i've tried <rekado>unless we used a functional reactive programming framework. <rekado>oh, wait. That's even more atypical. <Jookia>so in that case it'd default to 0.10 unless you joined at online game <davexunit>games are good when you want to dive into asynchronous programming problems <davexunit>I liked the variety of problem spaces explored in SICP <df_>some of them annoy me, I didn't really want to have to remember calculus <davexunit>right, it has a lot of calculus stuff. an introductory book not made for MIT students would have less or none of that ;) <rekado>so, who wants to co-author Galaxy of Guile? <df_>that said, getting a working symbolic maths manipulation system (albeit a rudimentary one) working was quite a buzz in the end <davexunit>I seriously think that such a book would be wonderful <rekado>I don't think one needs to touch calculus in a programming book. <davexunit>df_: Sussman is coming out with a new book about the subject <df_>it was just an example problem space, I think <rekado>for FRP it's enough to make the mental shift from discrete values to continuous values or "signals". <rekado>anthk_: I'd also drop that and focus on "the shape" of a process as in SICP. <davexunit>rekado: yeah for FRP you really need to just understand a DAG <ijp>rekado: it's not even really necessary for a CS degree, although it can occasionally be useful <df_>I also think SICP does some things deliberately 'wrong', in order to make a point <ijp>except for streams, there was no point in doing that one wrong <df_>like the non-deterministic evaluator teaches you about continuations but I don't think it's anything like how I'd approach such a problem in real life <anthk_>SICP's curve is like... first code with pen and paper, and then pass it to Geiser <Jookia>crispy doom is running which is a lot nicer <Jookia>Different source ports, only some of them are free. I only have a few more to test <jmd>To me, the documentation for challenge does not make clear how I should know if the challenge was succesfull. <civodul>jmd: yeah it just prints nothing upon success <civodul>and maybe the doc itself should clarify that <bavier>I think printing nothing is fine; just clarifying that in the doc <jmd>For me it printed something. <jmd>Does that mean it failed? <bavier>jmd: no, that's just output from the substituter <jmd>Also, would it not be a good idea for it to return non-zero on failure? <civodul>jmd: it returns non-zero upon failure <jmd>Well I have a counter-example. <bavier>civodul: a #t/#f return doesn't dictate the guile exit code I suppose <civodul>bavier: yes, that's what i was looking at <civodul>so we just need an explicit 'exit' here <civodul>bavier: ideally we'd change scripts/guix.in to do (exit (run-guix-main)) <bavier>civodul: that's what I was thinking too, yes <ng0>i have many fonts from kreative korp on my drive. I am pretty sure we can't distribute the ones which have their "personal use license" (I will check that again), but the ones covered by their "free use license" should be okay to distribute: http://www.kreativekorp.com/software/fonts/FreeLicense.txt , there's even one under a familar license (open font license) on <jmd>That license is not free. <ng0>is it close enough to free font licenses that I could contact them and ask them to relicense? <bavier>ng0: you can always ask for a relicense, whether or not the current is close <ng0>but I assume they are more welcome towards something which is only slightly different <anthk_>Jookia, gloome should be free now <Jookia>not sure if it's worth packaging? <ng0>have you forgotten about the unwritten goal, gnu/worlddomination? <bavier>ng0: items 1 and 2 seem to be the issues in that license <davexunit>Jookia: if you want to use it, and it's free, then it's worth packaging :) <jmd>The GPL has a similar clause. <Jookia>davexunit: I shall package all I can then ;) <davexunit>I've been a little concerned lately about people on the gnu-linux-libre list trying to make judgements about what's "worth" packaging. <davexunit>if it's free, and someone wants to do the work to package, then why try to stop them by saying it's not "worth it"? <Jookia>Right now I'm messing with Timidity <jmd>Right. What is not worth it for one person, may well be for another. <ng0>and even if you will stop it, somebody will do it. like some people might not see why some nonfree software is not available, they will package it and it will be available to people outside of the master <Jookia>I didn't mean to stir up trouble with that statement- from what I understand in the Doom engines there's only a few 'big' ones that have distinguishing features <bavier>concern over efficient use of volunteer efforts, which can be self-defeating <efraim>the only real argument I could see against inclusion would be against spending compile time on hydra <davexunit>Jookia: you're not stirring up trouble, but you triggered a feeling I've had the past few days. <davexunit>which is unrelated to your particular doom packaging stuff. :) <efraim>pygame has been kicking my butt the past few days <ng0>is it worth following? I stopped after 10 messages <davexunit>I just don't think it's good for us to say that a free program is or is not useful. <davexunit>the matter is resolved once josh gay from the fsf chimes in. <Jookia>It's definitely not worth saying that something's useful or not, though I think there needs to be explicit packaging criteria, even if it's just 'if it's of use to someone, it can be added and might be removed if not maintained' <civodul>yes, jgay's analysis was very thoughtful and valuable <ng0>useful in one persons dictionary might not be useful in another persons. <rain1>for some reason nobody replied to me on gnu-linux-libre <davexunit>Jookia: the criteria is basically: 1) is it free? 2) does it build? <Jookia>I'm going to package everything that interests me then :P <bavier>efraim: I started on gcompris a while ago; I'm not sure how far I got. <rain1>davexunit, I felt the same way, it's a bit sad that people are not appreciating what the MAME developers have done more <davexunit>I can see us removing things that have been broken for a long time with no one stepping up to fix them. <efraim>i started too, I have incomplete patches for gcompris and gcompris-qt <civodul>davexunit: free + the other criteria of the FSDG, such as not recommending non-free software <davexunit>on a formal list, I'd add notes about bundling and stuff <Jookia>That reminds me: Is mentioning nonfree software a problem? Not sure if it's worth patching all the doom ports to not refer to Doom95 or DOS <bavier>efraim: gamine is fun, looks similar to bambam <efraim>i'll look at it, but my 15 monther loves smashing the keyboard <ng0>wild. sometimes guix or coreboot or whatever assumes that I switched to a tv and the screen goes black for a second <efraim>i got abiword up to 3.0.1 but I had to disable tests due to issues with accessing the screen from the build environment <jmd>efraim: What do you mean "accessing the screen" ? <efraim>Gtk-CRITICAL **: gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed <jmd>Oh you mean it needs an X server <efraim>and GLib-GObject-CRITICAL **: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed <efraim>i tried copying the xserver stuff from other packages but couldn't get it to work <efraim>but I would be happier with the tests on <jmd>Have a look at gtksourceview-2 <efraim>i tried using the xserver phase from libbonoboui <efraim>i'll try with gtksourceview-2's phase <bavier>efraim: not specifically lambda*, but just if the body itself doesn't return a boolean or throw an error <davexunit>but a build phase procedure must return #t if it was successful <efraim>if I add a phase during the build process that's a substitution* <davexunit>which is why we ask people to return #t explicitly in that case <davexunit>it turns out that returning an unspecified value is not considered false, so this is a style guideline more than a strict necessity. <davexunit>but since its unspecified, guile could decided tomorrow that to change an implementation detail that would break the assumption that unspecified is "truthy" ***Basstard1 is now known as Basstard`
<efraim>I'm reading the part i'm substituting out more closely, the arguments get left behind if there's no valgrind and they cause libtool to fail <efraim>we don't actually use valgrind for that much <jmarciano>ng0: I have written what I have written. I am respecting everyone here, so please don't be disrespectful and call me "people like jm". I was pointing out to GPL violations such as "GPL license missing" in the object package. That is very valid argument. People like me are people who know what GPL means for future. <ng0>i only said "like jm" because i did not want your attention through highlighting your name <jmarciano>I am fine, I hope you are fine too, if you speak on public channel you get public attention. <jmarciano>I am somebody who likes 4 freedoms, that is all. I value the principles of copyleft. Actually, I got it in a dream yesterday, woke up, checked it, could not find it, so I wish first to be wrong. I don't like this kind of teaching. <lfam>jmarciano: This was very rude and I would also call it inaccurate: "it seems it was by design forgotten to comply to the GPL 2 license." <Jookia>it's very hard to comply with the GPL so violations are often unintentional <lfam>Of the packaging systems I have used, Guix (and Nix) are the best at providing the corresponding source of a given binary. <jmarciano>I have done my first distribution back in 2003. I have provided to other people full source code. It was not so hard. 3 diskettes and few diskettes of source code. <lfam>I think you should not start by accusing people of intentional wrongdoing <jmarciano>There must be function that injects the corresponding license into the object package. <rain1>ACTION reminder about DOS attacks <jmarciano>I am not sure where I used word "intentional". <jmarciano>How do I know who intended what, I don't know where are people located and I don't care. <lfam>In the part I quoted above, the meaning is equivalent in English <Jookia>you should care about their intentions <lfam>I do think we should resolve this issue, whether it is a miscommunication or a real problem. <jmarciano>it should be easy for certain licenses that have to be distributed with binary object code, to provide a function that injects the appropriate license or copies it into the binary package (substitute) <Jookia>not sure how thats related to their location <Jookia>jmarciano: you should build that <rain1>* Trolling or insulting/derogatory comments <rain1>* Public or private harassment <rain1>requesting an op to help deal with this <davexunit>let's get back on track here. no more of these accusations. <jmarciano>absolutely no personal attacks from my side. I am sorry if anyone thinks that. I see that as advanced distribution and I value people who makes it. <rain1>"All complaints will be reviewed and investigated" <davexunit>I really don't even know what we are talking about <lfam>I think that there is a language barrier. I wish we could communicate in our native languages (mine is English). <jmarciano>rain1: if you make a complaint, you stop referring please to me as DOS. I am not a child, I am adult. <jmarciano>just come back to subject, like "how to handle inclusion of licenses" <davexunit>I also suspect there to be a language barrier here <Jookia>what licenses aren't being included? <jmarciano>give me assignment like something to do, that is on my level and I will do. <davexunit>is there a package in guix that has problematic licensing? <jmarciano>davexunit: please first tell me, do you know the GPL2? <lfam>This is really making this channel useless. Over and over the same discussion with no communication or resolution <lfam>It's worse than /usr/bin/env <jmarciano>I understand that some people cannot confront it. <davexunit>jmarciano: are you trying to say that Guix is somehow violating the GPL? <jmarciano>and in general, not just like package, but multiple packages. <jmarciano>GuixSD uses hydra and other mirrors for distribution of object or executable packages. <davexunit>the GPL does *not* apply to the source code of the things we package. <rain1>yeah davexunit please move this to PM <rain1>this is denial of service on the IRC channel <Jookia>i'm kinda interested in this discussion <rain1>It would also be appreciated not to dismiss my complaint and try to 'move on' <jmarciano>Section 3: You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided <davexunit>I'm lost in all of this. I feel like I'm missing a lot of context. <jmarciano>So under the section 1. "and give any other recipients of the Program a copy of this License along with the Program" <jmarciano>at those who make binary packages of Guix that are distributed from Hydra and other mirrors (official) <davexunit>jmarciano: the complete and corresponding source code for guix is provided in our git repository and release tarballs. <jmarciano>so the object or executable package when distributed must include the license of the GPL <jmarciano>davexunit: did I mention a word "source" to you? No. <davexunit>jmarciano: and the complete and corresponding source code for the binaries we distribute via hydra.gnu.org are also available. <davexunit>on hydra itself. *including* the patched tarballs. <Jookia>rain1: FWIW after this i'll be discusing how to deal with MIDI synthesizers if you're interested <jmarciano>I have searched in all directories, did not find a license. Where it is? <rain1>I don't know anything abotu midi sorry <davexunit>open question: Does Debian ship a full copy of the GPL in every .deb for which the GPL applies? <jmarciano>davexunit: one cannot compare himself to those who don't value free software, like Debian group of people. <Jookia>rain1: There's to MIDI systems, timidity and fluidsynth- i have them kind of running but they both require messing about with global state <Jookia>rain1: Oh, how'd you configure it? <rain1>I mean as a standalone program, not related to doom <davexunit>jmarciano: you may have a point that there is something to fix here, I can't say for sure, but I am feeling a good deal of hostility from you about this and that I do not appreciate. <rain1>do you have a package for this? I could look at it <Jookia>rain1: i don't yet, i haven't package anything aside from manually building <davexunit>jmarciano: perhaps it's a language thing, but I'm not the only one that feels that this is a hostile situation. <jmarciano>that kind of explanation does not help with putting licenses in object packages. <ng0>jmarciano: you could have first tried to resolve the problem in length here other than trying for some moments and than go to a mailinglist not connected to guix <ng0>if it's a problem, we can fix it <Jookia>Complying with the GPL is very difficult in some cases <Jookia>Going down the track for literal GPL complying can be a difficult thing <jmarciano>ng0: thanks, that is how you would do, I do like I think it is more right. As it discusses free software distributions (including GuixSD) <davexunit>jmarciano: I don't understand why you posted to the gnu-linux-libre mailing list first instead of filing a bug with us. <jmarciano>to complay with GPL 2, to copy License into the binary distribution is easy matter. But sorry I cannot do that, I don't know how yes. <jmarciano>as there is by my understanding discussion of free software distributions <jmarciano>and it is matter of design, not only a bug in single package, so far I am yet to find a package where there is a license inside <Jookia>some more open questions: does video game art require license information to be placed on the images/models? how do we go about giving source code to serverside addons in a way that complies with the GPL? <davexunit>jmarciano: can you please file a bug report that there *may* be a problem here, so we can keep track of it and look into it? this might be a matter than ludovic will sort out with the help of other GNU people. <Jookia>can free javascript comply with the letter of the law of the GPL? :P <jmarciano>he knows about it, no need to be bureaucrat on my side <ng0>jmarciano: do I understand you right that you think every software which passes the way from external build farm to system running guix should include a physical copy of the licenses in the file or attached rather than having the collected licenses linked? <davexunit>jmarciano: there, right there, do you see why people get a negative impression? <Jookia>actually on topic: should patched software link to the guix source code as corresponding source? <davexunit>you will write an essay to gnu-linux-libre, but you won't put a bug in our bug tracker. <jmarciano>ng0: if there is package on a server (substitute), and if licenses requires that license is distributed with object or executable code, and if license is not there, question is why and how it has to be remedied. <davexunit>we're a distribution commited to the GNU FSDG, please assume good faith. <jmarciano>davexunit: sure, if I don't assume, I would not be talking here at all. <davexunit>even if we know about an issue, we need a way to manage issues, and that's what the bug tracker is for. <davexunit>that makes sure that it's not forgotten about, and that the problem and resolution are documented and archive for future reference <ng0>jmarciano: everything which is not intended as is, is a bug <jmd>jmarciano: Then report it to the copyright holder. <davexunit>jmarciano: please give us some time to look into what you've reported and see what we need to do to resolve it, if anything. <jmarciano>sure, I know, I would not even answer here if I was not called "people like jm" or "Denial of Service Attack" <ng0>and your level of language and behavior wasn't nice either. as I told you in the direct message you did sent, I had no intentions to "call names" <jmarciano>people can also propose to me: we are here to comply to the GPL inclusion of license, the fee would be that much, is there a donation available, and I will think about it. <ng0>I won't apologize because I don't appreciate how you get to solving problems. that's just me personally. <jmarciano>ng0: I am fine, you are fine too I hope. thanks I am sorry for your feelings <jmarciano>I would solve it myself, but I am not the boss <Jookia>something nice about free software is that you can be your own boss and make your own guix <jmarciano>if I need to rewrite something for all packages, I will do <jmarciano>Jookia: sure I will think about that. Until then I wish that people in GuixSD know what they are doing in regards to respecting the GPL license. <kyamashita>Does anyone have USB auto-mount working in Thunar? <kyamashita> thunar-volman: Unsupported USB device type "usb". <jackdaniel>erm, anyone is proficient in guix (package manager) and wants to have a presentation on pkgsrc conf in krakow about it? (1st june) (sorry for multipost if someone sits on #scheme and #guile too, my bad) <Jookia>kyamashita: hmm, can't say i've seen that error before <kyamashita> thunar-volman: Unsupported USB device type "usb-storage". <kyamashita> thunar-volman: Unknown block device type "disk". <lfam>jackdaniel: Cool! I'm on the wrong continent, but hopefully somebody can do it. Or, you could learn Guix and give the presentation yourself ;) <lfam>You could also email guix-devel@gnu.org if you get no volunteers on IRC <davexunit>jackdaniel: thanks. we have a number of European hackers here, including our maintainer, so perhaps we can send someone there!@ <davexunit>jackdaniel: is there a website or anything to register to be a speaker? <jackdaniel>great :) I was invited to do the presentation about managing packages in Common Lisp word and I thought about you <jackdaniel>and the organiser told me, that he'd love to invite someone from guix, but don't know anyone <Jookia>i wonder if i'm going overboard ith wanting things to be easy/out of the box in guix <lfam>They should be as easy as we make them ;) <Jookia>kyamashita: I want to be able to do "guix environment --ad-hoc freepats timidity++ freedoom prboom+" and have freedoom load up on my machine ithout configuring WAD paths or MIDI soundfont paths <Jookia>unfortunately it means patching to add search paths and configuration generators i think, though i don't know if profiles can generate config files? <kyamashita>Hm. That doesn't seem like you're going overboard, Jookia. <ng0>and the folder listed there in /usr/ holds copies of all licenses <Jookia>kyamashita: Maybe not so, but it's a little odd compared to imperative distros like Arch where you install and configure things systemide <Jookia>kyamashita: If i wanted to use a different sound font or freedoom version i'd just need to change environments for example <Jookia>it'd also work on other distros which is nice :) <Jookia>at this point i've kinda given up on packaging/configuring other distros <ng0>it gets frustrating. <kyamashita>GuixSD has been the easiest for me to configure and get the same thing each time. <ng0>yesterday and today I ran into npm issues on gentoo and had another long list of packages to add to my own overlay <ng0>where the long term sideproject guix on gentoo is much quicker <lfam>kyamashita: I'm looking at your wmcpuload package definition. I don't understand what "current usage" in the description refers to. Is it literally the electrical current? <ng0>language package managers create problems. I *can* use cargo, but I would prefer to install for example panopticon through emerge, and not cargo <kyamashita>lfam: It was supposed to say "current CPU usage". It was taken from the home page slightly out of context. <lfam>Okay, I'm going to apply the patch with that change, and a few other minor changes to the syntax and description (style and spelling changes) <lfam>I mean, the synopsis and description <kyamashita>Alright. I should read more of those for practice. Thanks for the review! <kyamashita>No problem! I'm just packaging applications that I use as I get time. <kyamashita>Does anyone know how CUPS service support is going? <paroneayea>my convenient guix + debian co-existence setup seems to have stopped working! <paroneayea>I had a guixsd + debian co-existence setup running for some time :) <paroneayea>things still run, though the guix command does not. Oh well. <lfam>paroneayea: The video is all scrambled. I can't see anything. It's similar to what I'd see when I tried to watch cable channels I wasn't paying for when I was a kid (not sure if that technology still exists) <lfam>Okay, I'll dig into the grub configuration <lfam>I'm not using libreboot on this machine <lfam>Do you think they'd still have good advice? <lfam>I guess I should look into how libreboot configures its grub. I'm sure it's a video setting problem. The resolution is configured very low when the booting text shows after the grub menu times out. It only gets set sensibly once the kernel starts its framebuffer <df_>in case this didn't get answered (and sorry to dredge it up again): every debian package ships with a copyright file that explains the details of the licensing - generally one of more copyright headers that refer the user to the text of the licenses in /usr/share/common-licenses/ <ng0>df_: comparable to gentoo <df_>it would be good for guixsd to have a simalar common-licenses package if it doesn't already <ng0>only that debian adds a little extra <df_>this "shipping with the license" argument is entirely orthogonal to the "corresponding source" one however, which fuels my suspicion that the originator is a troll out looking for problems <efraim>I first saw him on IRC this morning my time, about 14 hours ago <df_>which gets installed in /usr/share/doc/libmad0/ <jmd>What is guix environment supposed to be useful for? <rekado>for the record: I sent an email to rain1 re CoC complaint. <df_>efraim: me too, and I'm really disappointed in the collective amount of time that has been wasted since <kyamashita>The purpose of guix environment is to assist hackers in creating reproducible development environments without polluting their package profile. The guix environment tool takes one or more packages, builds all of their inputs, and creates a shell environment to use them. <kyamashita>So you can develop for certain packages w/o having to constantly install and remove stuff to keep a clean environment. <efraim>it's also good to run a program as a "one off" without installing it, like 'guix environment --ad-hoc abcde -- abcde' will add abcde to your path, run abcde, and then exit the environment <efraim>also `guix environment guix -- make` for the git repo <lfam>And that is important in a month, when you need to run the garbage collector ;) Otherwise, all your in-progress packages that are in the history of your profiles will not be garbage collected unless you remove each offending profile, which is tedious <lfam>--ad-hoc is amazing. I use it all the time <lfam>Especially useful in conjunction with a fast caching mirror. I used it recently for libreoffice! <rekado>Jookia: what do you think needs to be configured with Timidity? <rekado>it's already preconfigured to use freepats. <rekado>we install a default config file that points to the freepats config <rekado>see the "install-config" phase of the timidity++ package <jmd>So I have a package which works perfectly under "guix environment" but fails under "guix environment --pure". how do I find out what the difference is? <lfam>The plain `guix environment` inherits your existing environment, whereas --pure unsets the existing environment. <Jookia>rekado: Hmm- Doesn't work on my machine. What was this tested with? <lfam>jmd: So, you could run `env` in each case, and then diff the results. At least, that's what I would do. There's probably a better method. <rekado>Jookia: I tested it with plain timidity++ and a MIDI filie. <rekado>I'm using it pretty often like that <Jookia>rekado: Oh, so not timidity as a library? <rekado>didn't know it can be used as a library <jmd>lfam: I really need to examine the difference in the results. env wont tell me much. <Jookia>Well, all Doom ports I've tried use timidity++ to play MIDI tracks look in /etc/timidity.conf <rekado>do they specifically pass this file name as an argument? <mck>anyone been having trouble getting the texlive-texmf-2015 substitute? I always get a 503 <mck>building texlive from source... so slow <rekado>we configure timidity to use its store directory's etc directory by default. <rekado>mck: yeah, unfortunately there's no good way around this. <Jookia>rekado: They don't from what I know <rekado>mck: building from source is actually not so bad, it's mostly copying around stuff. <rekado>Jookia: then it should use the default, which is the config file we provide in the "install-config" phase. <kyamashita>mck: I've always gotten it when a substitute was available. <mck>rekado: what do you mean by copying stuff around? is there some way around having guix download the tarball? because I can't ever seem to get that download to complete <rekado>Jookia: do you see that it actually tries to access "/etc/timidity.conf"? <Jookia>rekado: Yes, in the stderr of whatever ports <Jookia>rekado: Adding an /etc/timidity.cfg fixes it <Jookia>I also have the relevant code that handles loading reference /etc/timidity.cfg <rekado>Jookia: is that path used somewhere in the Doom sources? <rekado>mck: no, I actually meant disabling substitutes for texlive-texmf-2015. <lfam>jdm: In that case I would use the 'diffoscope' program. <Jookia>I'm surprised timidity is even working with this setup actually <lfam>jmd: The likely issue is that your program is referring to something that isn't accounted for by Guix. For example, a library in /usr <lfam>jmd: That would explain why it works with `guix environment` and not with --pure <rekado>anthk_: they are provided by freepats. <rekado>it's not full gm coverage, though. <Jookia>I was wrong, I can't actually find where it defines /etc/timidity.cfg <mck>rekado: It should be able to invoke guix download on the tarball from a different, closer host, and be able to build texlive from source with guix build, right? I'm trying that now, anyway <rekado>mck: currently we only have one build farm frontend: hydra.gnu.org. And a single mirror: mirror.guixsd.org. <jmd>lfam: Yes, that is my presumption too. But it doesn't help me much. <rekado>with the latest release the default is to check mirror.guixsd.org and then hydra.gnu.org IIRC. <lfam>jmd: Sometimes I also run programs under strace to figure out these issues <Jookia>uhoh, i have a sinking feeling i know whats happening <Jookia>despite all being different source ports, they use timidity through sdl-mixer <ng0>mirror.guixsd.org was gnunet ev sponsored, right? I am curious in the monthly stats of the server, inbound/outbound.. but maybe since 0.10 is not out that long I should ask in 2 weeks <Jookia>Well that's a lot more horrible than I expected <Jookia>rekado: sdl_mixer bundles timidity <davexunit>Jookia: damn it. it should allow for using a shared version <Jookia>"[This version of timidity has been stripped for simplicity in porting to SDL] <ng0>that's the best fork, the older it is, the finer the fork <efraim>"from back in the day when it was good, not like today's version" <ng0>i forked THING before everybody else. <davexunit>rekado: in fairness, SDL 1.x is pretty damn old <rekado>AFAIR there was a period in which timidity didn't see any releases. <rekado>is this actually timidity or timidity++? <davexunit>also, sdl-mixer supports fluidsynth for MIDI <Jookia>It's actually timidity, not timidity++ <Jookia>davexunit: Does it bundle fluidsynth? <davexunit>Jookia: it might, but SDL_mixer lets you use shared versions <Jookia>Would people get upset at tearing timidity support out of sdl-mixer and depending on fluidsynth? <Jookia>SDL2's mixer has the same timidity code <davexunit>I recall that building with fluidsynth had some issues <davexunit>but yeah, IIRC building with fluidsynth may have some issues to solve. <davexunit>make sure that sdl2 variants also build, since they inherit from the sdl 1.x versions <Jookia>I want soundfonts to be available based on packages in a profile so I'm going to probably be patching timidity stuff and have a profile create a config, and do something like that for fluidsynth <rekado>Jookia: sounds good! For timidity I only used freepats because I couldn't find the original sources for the soundfonts I used. <efraim>starting the X server didn't help with abiword's tests <Jookia>Maybe soundfont packages should generate a config file that the profile uses and warns of collisions, meaning one soundfont per profile <rekado>e.g. FluidR3GM.sf2 doesn't seem to have a proper upstream. <rekado>Jookia: also note that it's possible to use more than one soundfont as long as they are mapped to different instruments. <rekado>not sure how to express this on the package level. <davexunit>rekado: was it you that used microscheme for something? <rekado>davexunit: yeah, I tried, but microscheme is extremely limited. <davexunit>considering that it has an FFI, I might try to write some firmware with it. <Jookia>rekado: I think that could be expressed by combining packages <rekado>davexunit: I find it easier to write assembly than to use Scheme where I have to pay attention to its implementation details. <davexunit>I've never had a project that called for programming at such a low level. <Jookia>I tried to learn but the lack of feedback made it difficult. Heh, I wonder if MAME's debugger could help <davexunit>I understand the basic idea of moving stuff around in registers, changing the instruction pointer, etc., but I don't have much real practice <Jookia>davexunit: Do you think having a 'one soundfont per profile' rule to avoid doing too much application patching would be a good idea? The limitation here is that you'd have to make a new package to combine soundfonts (which would require soundfont knowledge anyway, dunno if it could be automated) <efraim>oh, I saw in debian's repos that there's a C compiler targeting intel cpus from the 16/32 bit days <davexunit>Jookia: not sure, sounds like something that shouldn't so limited. <davexunit>or something that we shouldn't have to handle specially at all <davexunit>I don't know what the techinical limitations are with sound fonts <Jookia>Mmm, maybe someone else will come up with a better idea. Not all synthesizers can deal with multiple soundfonts so putting them all in a profile would seem like a bad idea <Jookia>Oh well, I'll patch it anyway and reconsider it later <davexunit>get it to work, and then we'll see where to go from there <lfam>I'm connected with the latest version of hexchat. Going to push the upgrade... <anthk_>it was a way to redirect all *.facebook.* domain connections to localhost, but I can't remember how <ng0>there's a service for this i mean <lfam>civodul: There was discussion of hexchat on oss-sec and I figured I should see what the status of our package was. Thankfully not affected by the issues being discussed... <davexunit>anthk_: there's a variable for facebook hosts that you can put in the hosts-file field <davexunit>ACTION not currently referencing documentation <quiliro>how can i connect to irc through the live usb? <anthk_>wasn't the USB live a low space image? <anthk_>oh, I understand. It's possible to have any sort of persistence? <anthk_>because having a tiny irc help program would be useful <anthk_>I think there is an IRC client made in bash somewhere <lfam>quiliro: How did it fail? <anthk_>I mean, as a help source for the new users, connecting them to #guix with a random username <lfam>I just downloaded the x86_64 irssi substitute without any problems. Does it give any more inforamation besides "failed to download"? <lfam>Did you run `guix pull`? <davexunit>that suggests that you aren't using binary substitutes <lfam>What about davexunit's question? <lfam>You shouldn't need to download anything from irssi.org <quiliro>davexunit: oh you mean guixsd version....no 0.8.3 i think <quiliro>but i am have spent 4 hours installing <quiliro>if i reboot i loose all that and have no internet connection in my town <davexunit>that should build the latest version of guix from source <davexunit>quiliro: 0.8.3 is very old and we no longer provide binaries for that release, so that's why you see guix trying to download source code from irssi.org. it is trying to build everything from source. <quiliro>how long will it take to reinstall everything with 0.10? <lfam>Much less time than building everything from 0.8.3 from source <lfam>But I can't tell you exactly how long it will take. That depends on what packages you need and the speed of your network connection <lfam>That will still be much faster than building the entire system from source <quiliro>3 more minutes till completionof 0.10 download <quiliro>master.tar.gz is downloading at 68KiB/s <lfam>quiliro: You mean 'downloaded'? <davexunit>lfam: quiliro hasn't yet used dd to transfer the 0.10.0 image to the usb drive <quiliro>is there a way to make an offline a full destop installation of guixsd? <quiliro>is there a way to make an offline full desktop installation of guixsd? <davexunit>quiliro: if you have guix installed on any gnu/linux system, you can generate your own disk images <lfam>Sure, you could use `guix system disk-image` to create a live image of the system. That's actually how we make the installer <quiliro>unless it has changes from ver 0.8.3 <anthk_>ok, the facebook hosts file works, this is truly awesome <lfam>quiliro: Something like this: `guix system disk-image --image-size=10000MiB desktop.scm` <lfam>quiliro: You'd want to add '--fallback' to that <lfam>Then, you can take the result and put it on a USB stick and boot from that <quiliro>a live system can be made from my installed system and that live system does not need to be online to install the same system i had on the machine that created the live system? <lfam>You can make the live system from your installed system. I'm not sure how to install that live system onto a machine, but I'm sure it's possible. <quiliro>guix system disk-image --image-size=1G gnu/system/install.scm <lfam>Fallback will build from source if the binary download doesn't work <lfam>The command line you show is how we build the GuixSD installer <lfam>That's what 'gnu/system/install.scm' is <lfam>So, you'd probably want to use a different .scm file, and probably increase the image-size <quiliro>install binary from usb not downloaded <lfam>Right, I keep forgetting you want to do it offline <lfam>In that case, it will have no effecet <quiliro>that is what i need because i will be installing in rural areas...besides i have no internet in my area <lfam>It won't matter, because you'll have all the packages already on your computer <lfam>Can you send this question to help-guix@gnu.org? I'd like to document this process, and it would be useful to have the discussion via email <lfam>And somebody there may have better advice <quiliro>lfam: it will be easier for me once it is installed on my machine <quiliro>will my old desshould i erase my /mnt? <lfam>davexunit: Do you think quiliro could `dd` the live USB desktop image to a machine in order to install it? <lfam>Whatever is left over from when you tried to install 0.8.3 is not needed anymore. <lfam>ACTION goes afk for a few minutes. will be back soon <quiliro>will someone please advise what problems i may have with guix as user? <quiliro>i noticed that it will not recognize my broadcom wifi when trisquel will do <quiliro>i have confirmed it uses free firmware <quiliro>in parabola it would not load b43-open/ucode5.fw <bavier>quiliro: if your wifi works in trisquel, there should be some way to get it working in guixsd too <bavier>quiliro: I'm no wifi expert; installing wicd might be enough <quiliro>i guess that if it does not work on the terminal, it won't on wicd either <bavier>quiliro: have you read section 7.1.4.2 in the manual? <bavier>at least during installation; wicd-service should take care of things after installation you you've included that in your configured services <quiliro>bavier: ifconfig -a does not show the wireless interface <quiliro>or with wpa_supplicant I suppose......what do you think? <quiliro>bavier: yes i reviewed that section now again <bavier>quiliro: maybe there's a different kernel module that needs to be loaded? <quiliro>bavier: good thinking! i will try b43 <lfam>Is the wifi card mentioned in dmesg? <quiliro>firmware not loaded...exactly b43-ope/ucode5.fw <bavier>quiliro: ok, so we need a firmware package for your driver <bavier>we have the ath9k_htc firmware in gnu/packages/firmware.scm, perhaps you could package the firmware for your wifi card? <quiliro>shows rev 01 works with free software <quiliro>bavier: how can i package the firmware for my wifi card? <bavier>quiliro: assuming wifi is not critical, I'd say get your base installation working <quiliro>bavier: it is not critical but i must install it before leaving this internet connection <bavier>then you can checkout the guix source and define a new package for that firmware <quiliro>but wifi is easier to link somewhere since it is a laptop <lfam>There's a new graft: pcre <lfam>The files are in the git repo under gnu/packages <lfam>You can also read them in ~/.config/guix/latest, but if you want to make a package, you should clone the git repo