<OriansJ``>cehteh: silent protest never achieves anything, only action produces results. Software copyright is not going to change because a bunch of lazy kids didn't add a license file to an unimportant program. ***OriansJ`` is now known as OriansJ
<cehteh>OriansJ: of course, and he is only hypotzing there that people leave licenses daliberate out, which may be not the case <cehteh>still it some interesting thought <cehteh>what iff people give completely up on the current systen and ignore it. that would harm 'gpl' and free software as well <OriansJ>cehteh: Actually it would harm the GPL and the entire community far worse than Companies such as Microsoft or IBM <cehteh>dunno if its worse, and i also believe the free software movement could fix/adapt .. asking/convincing authors <OriansJ>cehteh: The entire strength behind the GPL is the weight afforded by Copyright law. Without that we have few effective measures to minimize aggressive third parties from raiding the commons <cehteh>besides only 20% of projects on github have a license says nothing. its more like only 2% of projects hosted on github are useable anyway :) <cehteh>these are are certainly among the 20% with license ***Digitteknohippie is now known as Digit
<ng0>I bet many of those without license are "my dotfiles" and similar <cehteh>what license has your .ssh/rsa ? <OriansJ>cehteh: if one is dumb enough to upload their private key material to github, they have more problems than missing license files. <OriansJ>speaking of dumb shit, I just uploaded another stage1 bootstrap program. Still not sure it is ready to be converted to hex manually yet and it certainly is missing some usability functions but it provides exactly the functionality that one would require for a minimal hex writer. Needs alot more work to qualify as a full hex editor though <OriansJ>Although I am seriously considering adding a few more useful stage1 programs, skipping making them really user friendly and just use them as one offs for making later work easier. <yoosty>I've finally written up some notes on installing and getting started with GuixSD, I'd like to massage it in to some form of newbie guide for GuixSD.. how might I start down that path? <rekado>yoosty: would you be willing to add it to the Texinfo manual? <rekado>i.e. the official Guix manual in Texinfo forma <lfam>rekado: Is there any reason for me not to push Roel's patches adding r-limma and r-edger? <yoosty>rekado: for sure! I'll have to figure out Texinfo but this is all a learning journey ;) <yoosty>so would I be looking at editing the guix/doc/guix.texi file? <alezost>ACTION thinks it's time to give commit rights to Kei Kebreau (Yamashita)? <civodul>i mean, ask him for his Savannah account <alezost>I'll send a message to guix-devel asking him about it, is it ok? <ng0>I really like debugging things on guix... gentoo is just, you have to setup at least one VM to isolate your own configuration, see why it fails, only to realize 1 month later that it is not your fault but others <ng0>corner cases.. usually it just works. but gnunet-gtk was a pain <ng0>which gcc version was guix using 1 month ago? 4.9.3? <civodul>ng0: yes, that's what current master uses <efraim>it looks like our giflib is affected by cve-2015-7555 and cve-2016-3977 <civodul>'guix lint -c cve' doesn't list the latter <efraim>it was either introduced in 5.1.2 or found in 5.1.2 <ding`>hello all! I installed GuixSD. It is working great. The problem is that my girlfriend needs to use google chrome (unfortunately, not chromium) once in a while (job purposes). So the time came, I downloaded chrome from the website and tried to execute it but it gives a bad interpreter error. Is there a way to solve this? probably it could happen with downloaded free software aswell. I'm not looking for instructions to install non free <ding`>software in the distro, I just want to understand the problem. <jlicht>ding`: could you try to run chrome from a terminal, and paste the output somewhere? e.g., paste.lisp.org <ding`>it is just: bash: ./chrome: No such file or directory <ding`>and bash: ./google-chrome: /bin/bash: bad interpreter: No such file or directory <ding`>i think the problem might be related to the fact that guixsd uses non standart locations for files <jlicht>ding`: guix does not use the standard locations indeed. If this google-chrome thing is a script, you can try modifying it yourself to refer to the correct version of bash <ding`>the google-chrome is a script. i'm fixing it now <jlicht>so something in /gnu/store/asdfasdfasdf...-bash-4.2.0/bin/bash <ding`>ok. so the problem with google-chrome script is solved <ding`> bash: ./chrome: No such file or directory <ding`>it fails to start chrome with that error message <jlicht>hmm. Not really a chrome user myself, so I can't help you with that. You could have a look inside the bash script that calls out to ./chrome to see if it makes some assumptions that do not hold on GuixSD ***kelsoo1 is now known as kelsoo
<jlicht>does anyone have experience with using separate "debug" outputs with gdb? I am getting some "permission denied" messages, as these .debug files are not executable <civodul>jlicht: yes, it works as advertised for me :-) <jlicht>civodul: I had a look at it, but it seems that just adding a "debug" output seems to generate files that I cannot use with gdb <jlicht>at least for a package I'm trying to build atm <jlicht>getting a 'cannot execute binary file: Exec format error' when trying to actually run the program <civodul>jlicht: you have to run the binary that's in "out" <civodul>the .debug files are not executable programs <civodul>they simply contain debug info that GDB will load if debug-file-directory is set appropriately <jlicht>is there any way in which to this from a binary that is the result of guix build? <jlicht>(I assume because of grafting shenanigans or something), any guix package -i now first proceeds to download ghc... at ~800mb... in a slow internet cafe :# <civodul>i guess it downloads GHC because you have stuff depending on GHC installed? <jlicht>oh ha. It does, but atm I don't want to change/do anything regarding ghc or its dependants. guix build <mypackage> just builds my package, whereas guix package -i <mypackage> starts updating ghc. For now, I'll try telling gdb about the store-path to the .debug file (as it won't be installed in my profile) <jlicht>civodul: hmm, I've tried quite some permutations of setting debug-file-directory, but nothing seems to stick. I'll just have to tought it out with the ghc download, and see if things work after I have installed the debug output in my profile <civodul>jlicht: sorry i can't tell why it's trying to download ghc without looking at your profile <civodul>maybe you check if that also happens with --no-grafts? <jlicht>civodul: okay, just finished the download using my 3g connection. Even with setting up the debug-file-directory, it seems gdb cannot find the symbols :/ <jlicht>also, if I try to use one of the existing debug outputs from glibc, gdb _is_ able to find the symbols. Is there anything besides adding a "debug" output that has to be done to enable debug symbols for a gnu-build-system based package? ***kelsoo1 is now known as kelsoo
<civodul>sneek: later tell jlicht adding a "debug" output should be enough if the package uses gnu-build-system; check what the 'strip' phase does in the build log <taylan>yay, I like the emacs-minimal change <bavier>I really need to get a gpg key, so I can start signing commits like so many others <taylan>Emacsite: a new, very minimal emacs package in Guix that will be used instead of emacs-no-x as a dependency for other packages <Emacsite>taylan: Why would Emacs be a dependency in which actual Emacs is not needed? <taylan>Emacsite: IIRC the most commont use is to compile .el files shipped by programs that provide an Emacs mode <Emacsite>taylan: Ah, that makes sense. Maybe someday Guile can do it instead. ***yang_ is now known as yang
<taylan>Emacsite: hmm, Guile doesn't use elisp bytecode, and instead compiles elisp to its own bytecode, so guile-compiled elisp needs a guile-backed emacs to run <taylan>but hopefully upstream emacs will be guile-backed eventually ^^ <civodul>bavier: yeah, i think we'll soon declare an ultimatum ;-) <bavier>I got a openpgp smartcard from FSFE, just haven't set it up yet <jlicht>bavier: if you have a card reader that is supported, it is actually not that much of a hassle to set it up :-) <sneek>jlicht, civodul says: adding a "debug" output should be enough if the package uses gnu-build-system; check what the 'strip' phase does in the build log <bavier>jlicht: yeah, I have the card reader too, and it works alright. In my case though the set up also involves generating a master key, etc ***fps is now known as tapas
***tapas is now known as fps
<efraim>in nix, "propagatedBuildInputs = args.qtInputs" means I should pull in qt's inputs as inputs for this package? <bavier>llvm seems to need python2 for its test scripts, which appears to not be an issue until the 3.7.1 version <bavier>efraim: I don't know nix syntax much, but is qtInputs a list of qt packages? <efraim>and considering all the qt modules are dependant on qtbase they're already there and ready for inputs <efraim>should make for some fun factoring though, I think everything can just inherit qtbase <efraim>delete 'configure, replace 'build lambda _ zero? system* qmake <bavier>propagating inputs can always be done later as necessary <efraim>currently my qtbase propagates mesa like regular qt