<adfeno>LordShadowWing: Perhaps, but I find it strange that I did what was told in the documentation, and it worked. <adfeno>LordShadowWing: Don't worry, both of us don't have, we're trying to understand what's happening. <LordShadowWing>though it doesn't say where to download the file, I assummed to wget it to /tmp <LordShadowWing>adfeno, I might just go back to debian, everything just worked and the packages weren't so OLD <adfeno>Yes, but we cannot recommend it to general public. <adfeno>LordShadowWing: I found something useful <adfeno>Try: sudo initctl reload-configuration <adfeno>Now do: sudo initctl list | grep guix <ng0>Only 3 tests left to fix and I can send the tcsh update <adfeno>Now we can do: start guix-daemon (if it's not running already) <adfeno>LordShadowWing: Mine did that too when I started it that way. <LordShadowWing>Now i need to fix warning: failed to install locale: Invalid argument <adfeno>LordShadowWing: If, however, we let the system start it... It will work <adfeno>LordShadowWing: That's perfect :) <adfeno>LordShadowWing: Before caring for Mumble, let's see something important... <adfeno>I want to know if, by chance, "/root/.profile" has lines similar to the following ones: <adfeno>export GUIX_LOCPATH="${HOME}/.guix-profile/lib/locale"; export GUIX_PROFILE="${HOME}/.guix-profile"; source "${HOME}/.guix-profile/etc/profile" <adfeno>LordShadowWing: Please replace ";" with a line break, and remove the next space <adfeno>There should be only three lines. <adfeno>export GUIX_LOCPATH="${HOME}/.guix-profile/lib/locale" <adfeno>export GUIX_PROFILE="${HOME}/.guix-profile" <adfeno>source "${HOME}/.guix-profile/etc/profile" <adfeno>This floods the channel sometimes. <adfeno>We can put the three lines I presented in the end of the file <adfeno>LordShadowWing: Currently, it depends on which one you want to install. <adfeno>LordShadowWing: Generally, to answer your question another way: Currently, there's no way for Guix to know that he should install an application when you click on an item in the "App menu". <adfeno>This would be rater difficult to do for now. <adfeno>LordShadowWing: Not exactly... For some applications, you can copy a file which comes with the package you installed from Guix, and that file, when copied to a specific place, will let the application appear in the "App menu". <adfeno>Or, even if the application doesn't provide one, you can right-click in the App menu (the one with Trisquel logo) and click Edit, and from there, create a menu item for the command. <adfeno>atw: Oh...I see. that was a bug you were fixing. <adfeno>LordShadowWing: In this case, the Mumble package from Guix provides a menu item for us, we just have to organize things here first <LordShadowWing>adfeno, It seems like It's not working, I'm gonna reboot to see if things remain <adfeno>... please... wait and follow along. <adfeno>LordShadowWing: so I ask, did you insert the three lines I mentioned earlier in "/root/.profile"? <adfeno>OK, now let's do similar thing with your normal user's ".profile" (it's in your home), however, the lines are somewhat different now. <adfeno>export GUIX_PROFILE="${HOME}/.guix-profile" <adfeno>export GUIX_LOCPATH="${GUIX_PROFILE}/lib/locale" <adfeno>source "${GUIX_PROFILE}/etc/profile" <adfeno>export PATH="${GUIX_PROFILE}/bin:${GUIX_PROFILE}/sbin${PATH:+:}$PATH" <adfeno>There are some other adjustments that need to be done according to the docs, and also according to some of my recommendations... But if you want we can stop here. <ng0>filename substitution in tcsh is tricky <ng0>also, is it a faux pas to add perl in the native-inputs to fix test 122 once and for all? <adfeno>LordShadowWing: Hm... So you want us to continue? <ng0>is there anything really low level whic hdepends on tcsh but does not want perl? <adfeno>LordShadowWing: We must do the following: <LordShadowWing>adfeno, Use a pastebin for long lists please, termbin is awesome <adfeno>↑ This one will take some minutes (not much). <LordShadowWing>guix pull: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused <adfeno>Let's see... Still in the same shell, do: ls -al "/var/guix/daemon-socket/socket" <LordShadowWing>srw-rw-rw- 1 root root 0 Jan 8 17:09 /var/guix/daemon-socket/socket <adfeno>LordShadowWing: Are you by chance running guix somewhere else? <adfeno>Hm... whats the output of: ps -axo pid,args | grep guix <adfeno>What is the output of: status guix-daemon <adfeno>It seems Upstart isn't remembering that Guix exists... Let's see if we can fix this. <LordShadowWing>Just reloaded the config and it's there again, but is lost upon reboot <adfeno>sudo chown root:root ~root/.guix-profile/lib/upstart/system/guix-daemon.conf <atw>adfeno: well, reporting, but yeah <adfeno>atw: In both cases, it still helps. :) <adfeno>OK... Let's see if it helps now... Try rebooting. <adfeno>Now... let's see the output of: status guix-daemon <adfeno>Perhaps... I'll see if there's a reason for it not to be remembering the Guix service. <adfeno>LordShadowWing: Does it change the output if you do: sudo status guix-daemon <mystified>I was given a link about 12 hrs ago for a GuixSd alpha installer, I've now lost the link. <mystified>Can you guys point me in the direction of guixsd site with all the imgs <davexunit>ACTION notices that we got new graphics on this page <adfeno>LordShadowWing: I'll talk to Upstart project now, perhapst they have IRC channel. <atw>first time using debbugs...if I cc nnn-done@debbugs.gnu.org that should close the issue, right? <LordShadowWing>adfeno, I'm assuuming that maybe some of my issues come from my hardware, Intel ME is Evil <mystified>Hi again downloaded & extractedthe installer. Do I just dd the img to make bootable usb ? <ng0>ah :) I'm in the offlist conversation for that <adfeno>LordShadowWing: Unfortunatelly... No. <adfeno>LordShadowWing: I have a feeling that there must have been something we overlooked when installing Guix... <adfeno>Particullarly, there must be an error when extracting the package and moving things around. <adfeno>Because, as far as I can tell, it was the only part of the installation for which I was not here to guide. <adfeno>Well... must be going now, unfortunatelly, it's 23:00 already, and eyes hurt. <mystified>gpg: key 197A5888235FACAC: public key "rekado <rekado@elephly.net>" imported <lfam>mystified: You can also look into the --recv-key argument to gpg ***lewo_ is now known as lewo
***erdic_ is now known as erdic
<mystified>Ive downloaded it directly & unzipped it. It's come aou as a "binary pkg" is it alright to DD that as a binary ! <lfam>mystified: dd just moves data around, so it's fine to dd it to whatever file or device you're ready to overwrite <Apteryx>How are debug symbols dealt with in Guix? <Apteryx> Still not clear on how adding debugging information works. Does just adding a "debug" output automagically strips the binaries from the debug symbols and put those under the debug output? <Apteryx>I guess if this is how it works, I would still need to use configure flags such as --enable-debug? <Apteryx>How can I compare the size of a package before and after adding debug symbols? <Apteryx>OK, so to answer one of my previous question, yes, adding the 'debug' output will automatically copy any debug symbols found to the debug output. A comment in guix/build/gnu-build-system.scm says: ;; If an output is called "debug", then that's where debugging information <Apteryx> ;; will be stored instead of being discarded. <Apteryx>I guess the more switches we flip on to generate debugging symbols, the better when we want to create the "debug" output. <davexunit>paroneayea: listening to your HPR interview. very fun! <davexunit>(and I'm not just saying that because you kindly mention me several times ;) <Apteryx>paroneayea: I've listened to it as well, thanks for sharing! <sankey>random question, any guix contributor live in boston? <efraim>sankey: some live close enough to go to Libreplanet <sankey>i was just curious because i live in boston <sankey>in fact, i've gone to the last two libreplanet conferences <sankey>i'm quite sure there was a guix talk at the last one, i didn't even go because i wasn't interested at the time :P <atheia>I'm trying to get to grips with github/git based package recipes, but don't know how to use guix download to fetch the hash for a given recipe. <atheia>Does anyone here know what the way to do that is? <civodul>atheia: just do "git clone foo; cd foo; guix hash -rx ." <atheia>civodul: when I try that I get a hash mis-match. <atheia>Presumably I should check out the commit that the recipe specifies before doing the "guix hash -rx ." command? <atheia>(so, e.g. "git clone foo; cd foo; git checkout foo tag; guix hash -rx ." <atheia>HEAD is now at 03a897d... NEWS: Bump version to 0.1.1 <atheia>063lnvwp2jvjwkm9iimj1i5b6andnr3nw1m51g24b11g622xqhw6 <thomasd>Hi Guix, is there a reason why "guix import pypi" doesn't return a package description with (uri (pypi-uri ...)), but returns the full url as a string instead? Or would a patch be welcome? <atheia>$ ./pre-inst-env guix build guile-ics <atheia>output path `/gnu/store/vg5j89xzz3zfsyhapdg79v240n4sfx5n-git-checkout' should have r:sha256 hash `063lnvwp2jvjwkm9iimj1i5b6andnr3nw1m51g24b11g622xqhw6', instead has `1pvg6j48inpbq47hq00yh5hhl2qd2srvrx5yjl7w7ky1jsjadp86' <roelj>Would it be possible to let a separate system user own /gnu/store (say 'guix' user), and when Linux user namespaces are enabled for unprivileged users, let guix-daemon run as 'guix' instead of as 'root'? <roelj>That would end the need for super user privileges (apart from user namespaces) for guix-daemon. <jmd>Could it be that if the url in a package definition has the schema "file://" then the hash check is skipped? <efraim>if its already in the store then the hash check is skipped <efraim>I don't think I've ever tried with file:// <jmd>efraim: So how does guix determine which item in the store I'm refering to? <efraim>it checks the hash, but it doesn't check if the url is valid if its already in the store <jmd>So the hash is the hash of what exactly? <efraim>sometimes the tarball gets updated in place, sometimes its the .tar.gz and not .tar.xz, there are a bunch of different things that could happen <efraim>but it looks it up in the store by the hash <roelj>jmd: Using file:// indeed skips the hash check. <jmd>roelj: Is that a bug? <roelj>jmd: I think it's a feature :) <ng0>on 2017-01-06 there were many CVEs for pidgin <roelj>jmd: It makes local development easier I believe. <thomasd>ng0: according to `guix package -s pidgin`, we do <ng0>maybe this was the wrong pigdin <ng0>now it's gone from the results <jmd>roelj: I had better ask on the list about this. It seems dangerous to me ... <ng0>sorry for the long link <ng0>it states these issues <adfeno>ACTION is shaking, being a Pidgin user himself. <ng0>I'm about to update it now <ng0>oh, it is updated already <ng0>I think the CVEs were published late <ng0>no recent commits on this in the pidgin source, other than the current release <roelj>Is there a way I can modify the result of a Gexp before writing it to the store? <roelj>I'm currently using gexp->script. ***jonsger1 is now known as jonsger
<thomasd>seeing as the guile devroom was moved to Sunday, who has any recommendations for Saturday at FOSDEM? <roelj>What's the difference between 'guix download <url>' and downloading <url> when using <roelj>'guix package -i <package>'? <roelj>Is the latter handled by guix-daemon, and the former handled by the guix client? <thomasd>roelj: I think there is no difference. I think both result in a store file, so they must both be handled by the daemon? <roelj>Weird.. It fails to download from HTTPS when doing 'guix package -i ...', and then copying/pasting the failed URL 'guix download <url>' works fine! Then re-running 'guix package -i ...' works fine too (because the tarball is already in the store). <thomasd>well, thinking about it again, the file could be downloaded by the client, and then passed to the daemon to intern it in the store. so i'm not sure... <jmd>I thought there was no difference. "guix download <url>" is a convenience function for package development. <thomasd>roelj: strange, according to the manual, guix download should check the certificates, too. <ng0>Oh, I need string-join, not string-append for the setenv PATH problem in the last patch i have sent, right? <roelj>thomasd: Heh, it's in a build right now, so I'll have to wait for the next URL to fail. <efraim>thomasd: I'm checking out the fosdem app on fdroid to choose what looks interesting. Also dont discount Bsd, they're generally interesting talks <rekado_>I also updated bootstrappable.org; will announce later today. <roelj>A haskell embedded in Common Lisp..! I didn't even knew it existed..! <roelj>thomasd: Regarding the HTTPS problem with 'guix package -i ...'. It cannot load the (gnutls) module: "ERROR: In procedure module-lookup: Unbound variable: make-session". Yet, when doing 'guix download <url>', it does not error on the (gnutls) module. <ng0>do you think it'd be easy to get localized text string support into commonmark markdown (or any other variant of it)? Someone I know wrote their own markup language over the decades just because there's no markup language supporting this <ng0>I'm thinking of Haunt and that I should not need a javascript to translate text <ng0>Or am I wrong and there is some markup language which supports this? <davexunit>does anyone know of someone that has written a more comprehensive list? should I make a blog post about it? <davexunit>civodul: hey there! I noticed %guile-static-stripped has a glibc reference removed in /bin/guile, and I have a hunch that is why dynamic-link doesn't work. strace reveals that it is using that /gnu/store/eeee... directory as a search path for dynamic libs. I haven't found anything in the guile source code that is clearly the culprit. do you happen to have any institutional knowledge on the subject? ;) <civodul>davexunit: iconv tries to dlopen a bunch of stuff, and some of those you're seeing in strace come from that <civodul>as for (dynamic-link), i think it simply doesn't work on a statically-linked program <adfeno>quiliro: Would you do both of us a favor: Can you report the IceCat and Nautilus file naming issue to Guix's bug list? <civodul>davexunit: when linking statically a program that uses dlopen, you get this ld warning: <civodul>t.c:(.text+0xf): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking <davexunit>civodul: hmm not sure I saw that warning text, but I believe you. <davexunit>maybe I want a dynamically linked guile after all... <davexunit>thanks, that was the course correction I needed. <davexunit>I wrote a procedure called (for lack of a better name) package-with-fhs-build-system <davexunit>that replaces the implicit inputs of the gnu build system with a set that has no ld-wrapper and a gcc compiled without the hacks that hardcode glibc/libgcc references <civodul>i thought it was building using FHS directory names <davexunit>so far I've produced libz.so and libpng.so with no store references <civodul>you should share the conclusions of this experiment, i'm curious <davexunit>civodul: I will consider it a success when I'm able to open a graphical window with guile-sdl2 on ubuntu. <davexunit>I'll try with a dynamic guile later tonight if I have some time. <davexunit>I wasn't sure if it was feasible, but I'm now convinced it is. mostly my own ignorance of linkers is holding me back. <Akko_Teru>Can anyone here tell me how well MIDI controllers will work with GNU/Linux without using the CD of proprietary software that they ship with? I've been looking at Alesis Q25 and an AKAI 25 key. ***jonsger1 is now known as jonsger
<rekado_>Akko_Teru: if the USB MIDI hardware is class compliant it will just work. <rekado_>I use the Tascam US-16x08 (audio interface with MIDI) and since it’s class-compliant it works out of the box with GuixSD. <davexunit>I recently got a yamaha digital piano for my living room, and I discovered it has MIDI out. I want to try playing with some of the stuff rekado has packaged sometime <rekado_>I also have the Swissonic EasyKey 49 with MIDI over USB. That also works just fine. <quiliro>icecat cannot reproduce vimeo videos but youtube works <ng0>it's still mostly flash <bavier`>quiliro: youtube-dl works for downloading vimeo videos <efraim>I got lumina to build, now I have to package fluxbox to test it out <sankey>bavier`: quiliro: also mpv uses youtube-dl to download and play a video when given a URL on the command line <sankey>the issue is likely that youtube offers many videos with free codecs, whereas vimeo tends to only provide mp4 (or whatever patent-encumbered codec mp4 encapsulates) <nliadm>although if another part of your system can play h264 files, you should be able to make your browser do it <sankey>ACTION wonders if icecat/firefox uses the same multimedia library as mpv <sankey>guix commits e3cb00d2 and d505801a add x264 to gstreamer (icecat) and ffmpeg (mpv) respectively <sankey>in the case of gstreamer, you may have to additionally install the gst-plugins-bad package, but it's unclear to me how a package can treat that as an input without rebuilding <sankey>i'm guessing icecat in guix, as currently packaged without gst-plugins-bad as input, cannot play h264 video for this reason, and thus cannot play videos from Vimeo <sankey>whereas mpv, which uses ffmpeg as an input, can play videos from Vimeo <efraim>Rage from enlightenment will find gst-plugins-* if its built with gstreamer, I assume others are similar <ng0>2f30 is interconnected with the suckless community. When I upstream my collection of packages of this community, should they go into suckless.scm or should they be moved into admin etc <ng0>I have them in twoefthirty.scm in my guix_package_path currently <ng0>I will go for suckless.scm <quiliro>hello...thank you for your help.... i am installing gst-plugins-* and ffmpeg <ng0>but I think "st" is in shells too, so I think others would be ok <quiliro>what is the advantage of using the shell to run programs besides the fact that it is more powerful and light at the same time? <bavier`>quiliro: it's (usually) programmable <ng0>speaking of shells, is anyone interested in helping me to fix the last 2 failing tests for the tcsh update? <quiliro>ng0: i am interested but lack the skills <ng0>I've got stuck at those two tests <adfeno>quiliro: To give you an idea: I made a script that automates inserting logos in some selected images where I used to work. <adfeno>It was time-consuming to open Inkscape, measure where the unwanted part is, import the logo, resize the logo so it is at least greater than unwanted part, and place it upon this. <adfeno>Besides, I would have to keep one extra file (inode) for the Inkscape/.svg project files. <adfeno>So now, where I used to work for, they just need to keep two files: the original image, in case they want to do some other art with it, and the image with the logo inserted. <adfeno>Besides, at least for those who use ext-and-some-number file systems, inode consumption is something that must be dealt with. <sankey>it simply extracts objects from an svg file, something that was needed for my laser cutting workflow <quiliro>i would like my setup to open web pages show in the chat (pidgin) <adfeno>sankey: In my case, I used a mix of POSIX-compliant sh, find, grep, xdg-utils, and ImageMagick. <ng0>Oh. st is in suckless. So maybe I really move all into suckless. <sankey>ng0: weren't you talking earlier about splitting out suckless packages from suckless.scm into their respective categories? <ng0>there's also qt.scm .. and kde-frameworks.scm etc <lfam>jmd: Hi, can you undo that Imagemagick update and instead use the lastest release in the 6 series? That's what all the other distros are using, it's still maintained, and we haven't tested 7 with out packages AFAIK <lfam>Maybe we should try the 7 series on an imagemagick-updates branch. <quiliro>i probably need to specify mimetypes <jmd>lfam: According to upstream the 6 series is legacy. <lfam>jmd: Understood, but my question stands <lfam>We've held off updating to the 7 series since it seems that nobody has tested it across a whole distribution yet <lfam>I can do the revert+update if you want; I was actually getting ready when you joined IRC <jmd>Sure I can do that, but it seems like a curious course of action. <jmd>As I understand it, we use what upstream maintainers recommend unless there is a good reason to do otherwise. <lfam>The 6 series is maintained in parallel with the 7 series. Debian, Fedora, and Nixpkgs still use 6. I don't want to test 7 on the master branch. <lfam>We can use Hydra to test it without causing disruptions for our users. And users are not missing some important security updates by using 6. <lfam>The good reason to use 6 is that 7 is untested <jmd>Would the same argument also not apply to every other package which gets updated? <lfam>Well, it's untested across an entire software distribution. I'm sure the ImageMagick maintainers are testing it somehow <lfam>Not every other package has two branches developed in parallel <lfam>The are specifically helping us do this by maintaining both branches <lfam>If they wanted us to stop using 6 immediately, they'd stop maintenance of it. <lfam>For now, they've ported every bug fix back to 6 on the same day it was committed to 7 <jmd>Well I interpret their use of the word "legacy" to imply not recommended for use in new systems. <lfam>(You might be able to tell that I've been paying attention to this) <nliadm>whoa, I thought tcsh was dead as hell <lfam>jmd: Correct, but we have packages that were developed to use 6, and we haven't yet tested their compatibility with 7. Those are "systems" too <lfam>So, unless there is a pressing reason to make this potentially breaking change on the master branch*, I think we should do it in another branch <lfam>*We shouldn't break things on master unnecessarily or users will be wary of updating and will learn to miss security updates <jmd>Do we have reason to believe that it will break things? <lfam>jmd: Did you read the 6->7 porting instructions? <lfam>Several APIs have changed <jmd>I also ran the tests. 7 of which failed - exactly the same behaveiour as the 6.x version. <lfam>The APIs that other packages use to access ImageMagick have changed. Let's test the packages' compatibility on a branch <davexunit>upgrading imagemagick will cause at least 110 rebuilds <davexunit>we should try out an upgrade in a new branch <jmd>davexunit: That is less than the threshold for staging. <jmd>... if I recall correctly. <lfam>Did anybody test that the referring packages are updated to use the new API? <lfam>If not, I think we should revert the change, update to the latest 6, make a new branch that adds 7 alongside 6, and then we can make the 7-capable packages use 7. I don't think trying this on the master branch is appropriate <lfam>110 rebuilds is fine for the master branch, but in this case we have reason to believe that packages will break, and so it's not appropriate for master. <jmd>Anyway I've reverted it, but for future reference how should I know when it's ok to upgrage a package and when i is not? <lfam>We can't always know. I just happen to know about this one; I've paid close attention since the "ImageTragick" bug was published <jmd>Ok. Then I suggest you put a comment in imagemagick.scm "Do not upgrade". <ng0>what if we have 7 and 6 as separate apckages? <lfam>ng0: I think we should do that, and try using 7 with all the packages on an imagemagick-updates branch. <jmd>I have another suggestion: Rather than doing commits Revert "Revert "Revert "Revert .... <lfam>In general, I think we should try updating packages like this to latest series. If we can eventually drop the legacy series, that's good for upstream. <jmd>why not just cherry-pick the original commit? <lfam>jmd: Yes, good idea. My recent mess with nss and nss-certs is hard to read <lfam>jmd: I sent some patches to guix-devel for starting the imagemagick-updates branch <jmd>Soon we will have more branches than commits! <efraim>i'm wondering if qtdeclarative should be a native-input by default, or if its always listed as a dependancy because its needed by so many other modules <efraim>yay, I didn't realize we already had fluxbox packaged ***paolo_ is now known as paolo
<lfam>Is anyone else having trouble with Git and HTTPS? ***snape` is now known as snape
<lfam>For some reason my GIT_SSL_CAINFO environment variable stopped working as expected <ZombieChicken>Anyone here know how to get qemu to handle 5 drives without barfing? <ZombieChicken>One has to love it when a program can't find a file that exist, is readable and writeable, and that one has triple checked exist <ZombieChicken>but can easily find all the other identical files in the directory without issue <lfam>ZombieChicken: The error message is probably wrong <lfam>Maybe it's trying to execute a program on said file, but the program can't be found. I've seen that <lfam>You can use strace to see exactly what it's doing <ZombieChicken>Well, it's qemu and I'm trying to start it up with 4 drives to simulate my desktop's setup to test a guix install on <ZombieChicken>and those 4 files are empty qcow2s, the one with a problem is 1G, the other 3 are 5 <lfam>What happens if you try 3 drives? <ZombieChicken>the only difference is the file names (replaced "-[0-9]" with "-boot" in the name, and 4G of space <lfam>You're probably hitting the Linux limit of 4 primary partitions somehow <lfam>How are you invoking QEMU? <ZombieChicken>qemu-system-x86_64 --enable-kvm -cpu host -net nic,model=virtio -net user -usbdevice tablet -m 2G -usbdevice disk:guixsd-usb-install-0.12.0.x86_64-linux -hda file=guixSD-boot.qcow2 -hdb file=guixSD-1.qcow2 -hdc file=guixSD-2.qcow2 -hdd file=guixSD-3.qcow2 <ZombieChicken>Now to get it to realize the liveUSB is what it should boot from... <ng0>hrmmmmm... there must be some other solution to a first basic uclibc-ng build. before the checks I need to link linux-libre-headers into uclibc-ng /include directory, which feels awful given that there are many files in -headers <ng0>but that's just needed for cross compile iirc. I'm happy if it compile on one arch first <ZombieChicken>Anyone know if your can partition an encrypted volume? By that I mean run cfdisk over a LUKS-encryped drive? <ng0>ah, slowly i'm getting to a point where it's usable... pakcaging compilers is not so easy