IRC channel logs
2016-11-12.log
back to list of logs
<Apteryx>Great! Working on something in particular? <Apteryx>My laptop is too crappy for games :/ <albertoefg>and we usually like hedgewars i bet your laptop support it <Apteryx>OK! Sorry I'm not much into gaming. But I just read the page about mana world, it looks interesting. I'll try it at some point! <Apteryx>albertoefg: The channel has been very quiet today! But if you are into gaming and you don't find your favorite (libre) game on Guix you could help by trying to package it! <Apteryx>I know on the Guix website it seems like packaging is one of the area where they need the most help. <Apteryx>I installed using the GuixSD image (on USB drive). <Apteryx>It took a while but not terribly long. I chose lightweight desktop config, so if you opted for a full desktop config it would be longer I guess. <Apteryx>It takes forever to build the kernel on my machine :o <Apteryx>The Libre-Linux kernel, I should say. <alezost>Apteryx: re guix-daemon and gnutls error: it looks like you start guix-daemon in the environment that does not contain GUILE_LOAD_PATH with gnutls modules <alezost>run "guile" in that environment and try ",use(gnutls)" there <alezost>Apteryx albertoefg: btw "manaplus" (the client for "The Mana World") is packaged for Guix <albertoefg>if i screwed guix installation (not guixsd ) is there a way to start again or something <alezost>albertoefg: to remove it, you need to remove /gnu, /var/guix and ~/.guix-profile link <alezost>if you are going to reinstall guix, then I think you need it still, no? <albertoefg>if i install gnash with guix that means i can use it with icecat that was installed with fedora repos? <albertoefg>but my government sucks more and requires to use flash on many sites <albertoefg>some websites can only be used with internet explorer <albertoefg>it bothers me so much that u have to use internet explorer to use a government web site <albertoefg>because they make arrangements with Microsoft no use certain software <albertoefg>and if Microsoft doesn't offer then politicians demand a part of te money's deal <albertoefg>any way that was not the point.. I'll reinstall Guix in the morning :) <rekado>albertoefg: I’m working on packaging hedgewars <rekado>not so easy because it depends on Free Pascal, which cannot be bootstrapped without Free Pascal. <rekado>trying to build the ancient GNU Pascal in hopes to then build a version of Free Pascal. <rekado>most applications are easier to package. <janneke>...now if only my Guile build reproduces <jmd>janneke: Git it neutered. Then it can't! <civodul>janneke: yup, we need to get the attention of wingo and mark_weaver! <janneke>civodul: i should be almost there... <janneke>now only having trouble with 2 .go files so it seems...but finding/bisecting down to the problem is a time-wise nontrivial task <civodul>janneke: you mean the patch leads to miscompilation issues? <janneke>no, some files still are nondeterministic...i tried understanding and then commentting-out bits...but all of guile needs to be rebuild to find the nondeterminism <janneke>when i make changes and run guild by hand, it's always deterministic. i'm at loss at how nondeterminism enters in some cases <janneke>yes, i can diff the build and the -check disasseblies <janneke>now just trying with two whole files commented-out...see where that goes <civodul>so how do those two .go files differ? <civodul>generated identifiers or something else? <janneke>civodul: it looks like generated identifiers...but i find it hard to tell from the disassembly <Apteryx>SSL_CERT_FILE, SSL_CERT_DIR looks OK. <Apteryx>I could use "--no-check-certificate" but I'd rather understand why this happens? <rekado>Apteryx: I had this too. Is the daemon running in an environment in which SSL_CERT_DIR is set? <Apteryx>rekado: It was started automatically, how can I verify that? <rekado>(maybe we should update the systemd unit file for the daemon such that SSL_CERT_DIR is set.) <Apteryx>I have no idea how services are start, haven't investigated that part of the system yet :) But I'm using the lightweight desktop base config, which I believe only manage services with Shepherd, AFAIU. <rekado>I haven’t tried using the daemon with SSL_CERT_DIR on GuixSD yet (haven’t upgraded). <Apteryx>Could it simply be that the cert for "mirror.hydra.gnu.org" truly is invalid (expired, maybe?) How would I check that? <rekado>you may have to install nss-certs into the root user’s profile <rekado>but I’m not sure about this as I haven’t tried it myself <rekado>ACTION needs to go back to studying <Apteryx>rekado: OK. Good luck with the sudies! <albertoefg>in website it says guixsd doesn't support some packages for example kde applications <jmd>I think some kde things have been packaged. <jmd>albertoefg: Can you give me a reference to that statement? <albertoefg>GNOME, Xfce, and Enlightenment are available (see Desktop Services), as well as a number of X11 window managers. However, some graphical applications may be missing, as well as KDE. <jmd>I think that is refering to the display managers. <jmd>The applications have been packaged (at least many of them have). But you can't actually log in to a kde-desktop-environment. <jmd>... at least not out of the box. <jmd>Yeah I think most people here prefer Gnome over Kde. That's why not it's had more attention. <albertoefg>the thing is i found guixsd installation really complicated :( <jmd>albertoefg: Really? Can you elaborate on what you found difficult. <jmd>What did you find complicated about GuixSD installation? <jmd>I'm afraid I'm not familiar with parabola, so you will have to enlighten me. <jmd>I don't know arch either :( <jmd>I've heard of it, but never used it. <jmd>What did you find difficult about installing GuixSD? <albertoefg>well i have my hard drive encrypted with lvm or not sure what so i cant install another distribution <jmd>GuixSD doesn't support booting from LVM (yet). <albertoefg>and when i tryed installed parabola i could not make it work <jmd>I'm confused. I asked you about GuixSD but you keep on talking about parabola. <jmd>Tell parabola to change their installation procedures. then it won't be similar. So then you will find GuixSD easy. <jmd>As it happens, I'm working on a graphical installer for GuixSD. <jmd>So I'd be interested to know *specifically* what you found hard. <albertoefg>With the target partitions ready and the target root mounted on /mnt, we’re ready to go. First, run: <albertoefg>This makes /gnu/store copy-on-write, such that packages added to it during the installation phase are written to the target disk on /mnt rather than <albertoefg>but for me is difficult as i dont know what to expect or how long will it take <jmd>They general convention in operating system design, is that if everything is correct, then the command will silently succeed. <jmd>However if there is a problem, then a warning/error message will be emitted. <albertoefg>and thats why i say i found installation complicated <albertoefg>Create a disk image that will hold the installed system. To make a qcow2-formatted disk image, use the qemu-img command: <albertoefg>i did that my terminal was in the same folder as guix <albertoefg>but i didn't know how to tell to use guixsd-usb-install-0.11.0.system.xz’ <jmd>Actually, I have never tried installing in a VM, so I don't actually know either. <albertoefg>i know is my fault trying things before understand how they work :) <jmd>I don't think it's your "fault". <albertoefg>i was just trying to explain you what i meant for difficult <jmd>The only way to understand something is to try it. <jmd>Well it is supposed to be simple for everyone. So if you have any suggestions how to make it easier I'd be interested to hear. <albertoefg>oh i normally found video tutorials easy so u can see exactly what happens in terminal and the person explains what is going on :) <Apteryx>jmd: I for one found the GuixSD install procedure enlighting and empowering (thanks to the good info manual). But command line is not for everyone. I have coworkers, programmers, mind you, that are horrified at the idea of having to use a terminal. <albertoefg>:( ok i am sorry i wasn't trying to speak bad of anyone nor guix <Apteryx>albertoefg: Didn't get it that way! It's nice to get feedback, whatever it is! <Apteryx>If GuixSD is to appeal to larger demographics it will need to become easier to install for sure. <albertoefg>i will try to installation again after breakfast <Apteryx>albertoefg: OK! The manual is your friend, and don't hesitate to ask questions here as well. <jmd>The manual is your friend, and the terminal is your servant. You tell it what to do and it does it. <Apteryx>Is there a way I can list the applications installed *globally* rather than in my user profile? <Apteryx>I'd like te verify that nss-certs is well installed. <rekado>Apteryx: in GuixSD you can add packages to the system profile. <Apteryx>rekado: The system profile is this: /run/current-system/profile? Is it only modifiable through a "guix system reconfigure" ? <Apteryx>albertoefg: A "guix package --list-available=wayland" tells me that it is. <Apteryx>You can get a summary of all the packages command by doing a "guix package --help". <Apteryx>rekado: I was looking for the equivalent of "guix package --list-installed", but for the system profile rather than my user profile. Is this possible? <jmd>albertoefg: So if I understand your correctly, you prefer an interface where you get an *explicit* confirmation of the success of each command as you issue it? <Apteryx>Found my answer: guix package -p /run/current-system/profile/ -I :) <albertoefg>maybe in documentation could be a you can expect something like this <albertoefg>u told me u were working on a graphics installer so <Apteryx>hmm, nevermind, the /run/current-system/profile is *my* profile. <rekado>Apteryx: no, this is the system profile. <Apteryx>Arg, sorry for the confusion, but /run/current-system/profile is the system profile. <rekado>Apteryx: you change it by modifying your operating system configuration. <Apteryx>rekado: yes! Got my output confused. <rekado>Apteryx: to make the changes take effect you have to reconfigure. <jmd>albertoefg: Graphical user interfaces a finicky things. <jmd>They can easily annoy users. <Apteryx>rekado: Thanks! And sorry for interrupting your studies :D <jmd>Whenever I use one I'm constantly bombarded with yes/no questions. <jmd>and I always find myself worring: "I wonder what it's actually going to do if I say yes?" <jmd>For that reason I think most people prefer a command like interface where the *user* explicitly says what should be done. <jmd>However some people have expressed interest in a gui - so I want to know exactly what they expect in one. What would you expect? <rekado>I find command line interfaces difficult to explore. ‘--help’ isn’t always helpful as the scope of commands grows. In my opinion, a GUI should help users to assemble a series of commands by initially hiding complexity and revealing it step-wise in a controlled fashion. <rekado>Apteryx: no problem. I’m not very successful right now anyway :) <Apteryx>Ah. What is it that you are studying? <Apteryx>Maybe one thing that I did before this problem occured was to point my /root/.config/guix/latest to ~/.config/guix/latest as recommended in the manual ("If you are the sole user of your system, you may also <Apteryx>consider pointing the ‘/root/.config/guix/latest’ symlink to point to <Apteryx>‘~/.config/guix/latest’; this way it will always use the same ‘guix’ as <jmd>rekado: I agree that some commands have poorly designed command sets. <jmd>rsync is a classic example. <jmd>Part of the problem is, that as an application grows, its organisation of its commands needs to be reorganised. <jmd>But developers of a command line interfaces are reluctant to do that because of backward compatibility. <jmd>Whereas gui developers usually don't care. and will radically change the interface on each release. <jmd>Both approaches have advantages and disadvantages. <Apteryx>albertoefg1: What kind of install are you doing? Guix over an existing system? <jmd>Apteryx: He said on a VM. <Apteryx>I'm not familiar with installing Guix on a foreign distro, but glancing over the installation section of the manual, it seems that you'd have to remove /gnu/store, /var/guix and ~/.guix-profile to undo the actions there, +++ PATH, services, etc. <jmd>From what I recall about foreign distro installation, the biggest hassle is getting the build daemon set up <albertoefg1>3.- Make root’s profile available under ~/.guix-profile:# ln -sf /var/guix/profiles/per-user/root/guix-profile \\ ~root/.guix-profile <albertoefg1>nothing showed on my terminal. So far so good right? <Apteryx>Oh, looks like a regression which affected substitute, which was fixed in master 8 hours ago by Ludovic: 166ba5b * substitute: Disable HTTPS certificate verification. <jmd>albertoefg: It's not a question of how many people use the machine. <albertoefg1>my question is: should i just do the command like that any way? do i have to do it as a root? <albertoefg1># groupadd --system guixbuild # for i in `seq -w 1 10`; do useradd -g guixbuild -G guixbuild \\ -d /var/empty -s `which nologin` \\ -c "Guix build user $i" --system \\ guixbuilder$i; done <jmd>Having more than one build users has optimisation advantages. <jmd>yes it must be done as root. <albertoefg1>i understand jmd, so basically don't touch it and do it as root ok give me a second <albertoefg1>ok now i have guixbuilder10 and guixbuilder9 and so on <albertoefg1>what do i do next? go back to installation page or continue on this page and do # guix-daemon --build-users-group=guixbuild <jmd>I can't remember. What do the instructions say? <albertoefg1>the instructions say: 4.- Create the group and user accounts for build users as explained below (see Build Environment Setup). <jmd>So you have done that. <albertoefg1>this The guix-daemon program may then be run as root with the following command: # guix-daemon --build-users-group=guixbuild <albertoefg1>5. Run the daemon, and set it to automatically start on boot. <albertoefg1>To use substitutes from hydra.gnu.org or one of its mirrors (see Substitutes), authorize them: <albertoefg1># guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub <albertoefg1>[root@despacho info]# guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub <alezost>albertoefg1: warning is not an error, you can ignore it for now; it is explained later in the manual how to get rid of this locale warning <albertoefg1>guix package: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory <albertoefg1># cp ~root/.guix-profile/lib/systemd/system/guix-daemon.service \\ /etc/systemd/system/ # systemctl start guix-daemon && systemctl enable guix-daemon <albertoefg1>but as u asked i did this manually: Otherwise, you can still start the daemon manually with:# ~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild <alezost>albertoefg1: I think guix-daemon is not running, look at the output of "systemctl status guix-daemon" <albertoefg1>and when i did it manually nothing happened terminal just stayed like working <alezost>albertoefg1: you need to start guix-daemon before using "guix ..." commands, either manually or with systemd <Apteryx>albertoefg1: Did you run it with "#" as you showed us? if so you didn't run anything as this is the comment symbol <Apteryx>albertoefg1: Also the manual says you should run this command as root <albertoefg1> Loaded: not-found (Reason: No such file or directory) <alezost>albertoefg1: "terminal just stayed like working" ← this is normal; the daemon does not quit, it just stays running <albertoefg1>so alezost start it as root on one terminal and continue installation as root an another terminal? <alezost>albertoefg1: yes, or start it with systemd: "systemctl start guix-daemo" <alezost>assuming you called it "guix-daemo", not "guix-daemon" <alezost>but you probably didn't, and it was just a typo <albertoefg1> Loaded: loaded (/etc/systemd/system/guix-daemon.service; enabled; vendor pres <albertoefg1> Active: active (exited) (Result: exit-code) since sáb 2016-11-12 13:00:14 CST <albertoefg1>nov 12 13:00:14 despacho.despacho systemd[1]: Started Build daemon for GNU Guix. <albertoefg1>nov 12 13:00:14 despacho.despacho systemd[1]: guix-daemon.service: Main process <albertoefg1>nov 12 13:43:33 despacho.despacho systemd[1]: Started Build daemon for GNU Guix <albertoefg1>i dont know how to use paste.lisp.org give me a minute :) <alezost>does it run after "systemctl restart guix-daemon"? <albertoefg1>SELinux is preventing (x-daemon) from execute access on the file guix-daemon. <Apteryx>I'm facing the regression that my guix cannot uses substitute from mirror.hydra.gnu.org because of the HTTPS regression that has already been fixed in master; As a result, I can't even update my guix using the usual "guix pull" (fails with the invalid cert error). Can I get out of this catch22 situation using my git checkout? <alezost>Apteryx: by "./pre-inst-env guix pull", but actually if you use a git checkout, you don't need to "guix pull", just update your checkout (git pull) and "make" it <alezost>albertoefg1: I know nothing about selinux, is it started if you run it manually? (guix-daemon --build-users-group=guixbuild) <Apteryx>alezost: Yes, I was not yet comfortable using git checkout as my ~/.config/guix/latest. I remember someone running "guix gc" and borked its system. <Apteryx>Thanks, I'll try the "./pre-inst-env guix pull" :) <alezost>Apteryx: "guix gc" problem does not relate to the way you run guix (from a checkout or from a "guix pull"-ed code) <alezost>"guix pull" is really not needed if you use a git checkout <albertoefg1>~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild <alezost>albertoefg1: ok, now you can try "guix build --dry-run hello" <Apteryx>alezost: OK. I'll just point my ~/.config/guix/latest to it then :). I thought there was something special about a git checkout that if I ran "guix gc" it would collect stuff which guix rely on, such as guile, and break the system. <alezost>Apteryx: no, it doesn't matter, both "guix pull" and latest git checkout have the same code <Apteryx>Not sure about the exact details of that issue as I remember it though. I'm happy to be mistaken about it! <albertoefg1>substitute: warning: failed to install locale: Invalid argument <albertoefg1> /gnu/store/zy5aanymkq37l91yhq0xa6rddv1skl6s-hello-2.10 <alezost>albertoefg1: it is explained in the manual (info "(guix) Application Setup") how to solve the locale warning; as for the https_proxy thing, I've never seen it, the rest is ok. So now you can try to install something <len__>I am trying to get my guixSD to some basic functionality :) <len__>but I had to flash bios of my thinkpad before I could change wifi card from intel to atheros <len__>atheros wifi was not white listed on bios <len__>intel wifi does not have libre drivers <alezost>albertoefg1: great! as for the problem with guix-daemon, systemd and selinux, I can't help :-( <alezost>albertoefg1: do you mean you wish to try "M-x guix-..." commands? <alezost>for that you need to install both emacs and guix to your profile <len__>I can not install wpa_supplicant it says that it is unrecognised package <alezost>albertoefg1: well, fedora's emacs will not find *.el files inside ~/.guix-profile, so you need to use guix's emacs if you want to use emacs packages from guix (including emacs interface for guix itself) <alezost>for example, if you do "guix package -i magit", and start fedora's emacs, you will not "M-x magit-status" command <alezost>but if you also install emacs, and run it, it will find magit files <albertoefg1>so everything should be installed and used from guix <alezost>no, but if you want to use emacs packages from guix you have to use guix's emacs <alezost>len__: in guix it's name is "wpa-supplicant", not "wpa_supplicant" <alezost>in Guix (more generally Guile/Scheme/Lisp) world it's a convention to use "-" instead of "_" <alezost>actually wpa_supplicant should be available in the installation image <alezost>albertoefg: Guix's Emacs is not worse than your Fedora's Emacs; it is a usual Emacs, and it will also find your (M)ELPA packages, if that's your concern <len__>one more qustion, what is the best way to learn guix <alezost>len__: wget? but you already have it if you use guix; just run "info guix" (or "M-x info" if you use Emacs) <len__>It lasted more than a month since installation and than flashing new bios ... <rekado>for work I now must publish status updates to Google docs each week. Does anyone know of a tool that allows me to do this a) without a google account and b) from the command line / within Emacs? <necrophcodr>I've install Guix on a non-GuixSD system, and I'm wondering if it's possible to take my user-profile with me to another location? <necrophcodr>But without all the files and folders and structures <necrophcodr>Just a general file that can recall the exact generation on a different platform <rekado>necrophcodr: this can be achieved with manifests <rekado>a manifest is a file in which you declare the contents of your profile <rekado>you can instantiate a manifest with ‘guix package --manifest=/path/to/manifest.scm’ <rekado>alternatively, you can export the closure of your profile and import the exact same binaries on another Guix system. <rekado>and here’s how to export the closure of your profile: <rekado>guix archive --export --recursive \\ <rekado> $(readlink -f /path/to/.guix-profile) | \\ <rekado> gzip --stdout - > my-profile.nar.gz <rekado>that will take a while but in the end you’ll have everything in one gzipped file which you can import on the target. <jje>got a problem with mirror.hydra.gnu.org guix pull fails with signer-not-found invalid for the X.509 cert. how does one fix this? <rekado>jje: are you using GuixSD or Guix on top of some other distribution? <superflip>I am trying to run gnome on Debian stable using guix. So I ran "guix package -i gnome". When I try to run gnome using "DISPLAY=:1 gnome-session", I get "dbus-update-activation-environment: error: unable to connect to D-Bus: /gnu/store/3s8ifq6vpdykaw695k4b083xwrsvc3k5-dbus-1.10.8/bin/dbus-launch terminated abnormally with the following error: Autolaunch error: X11 initialization failed." and "** (gnome-session-failed:3532): WARNING * <Apteryx>Just to be sure about one thing: When I use a git checkout as my ~/.config/guix/latest, to update, I just run <Apteryx>git pull... Then I need to rebuild guix if I want the new guix version using "guix environment guix", "make -j3 check"? <Apteryx>Not sure I need the "guix environment guix" part. <necrophcodr>rekado, oh my god, that was amazing. thank you so much for the explanation of how it works, and the links for me to read on about it. i surely will too! this will help me be a lot more productive at work, thanks! <Apteryx>This means I'd never need to issue "git pull" anymore. <Apteryx>jje: This was a regression which was fixed in the master branch. <rekado>jje: I’m still updating to the latest version, but the problem you face is likely caused by not having a certificate store in a place where guix-daemon can find it. <jje>ok can i amend that some how rekado ? <Apteryx>jje: The problem is that if your currently installed guix version exhibits the problem, you won't be able to run "guix pull" to refresh it... <rekado>jje: one way to do this is to install nss-certs (if you don’t have it yet) and point SSL_CERT_DIR at it in the environment in which guix-daemon runs. <jje>thank you i will try that rekado <Apteryx>rekado: This won't do. The certificates are installed and the envars point to these. I believe the problem is that mirror.hydra.gnu.org doesn't have a certificate and it was being validated. The commit you referenced turns validation off for certain situations where it doesn't matter. <rekado>necrophcodr: I’m glad you found this helpful. That’s the documentation for the Guix deployment at the institute where I work. Note that all instances of ‘guixr’ should be ‘guix’ (unless you’re on one of our institute’s machines.) <rekado>Apteryx: hmm, I had a problem with cert checking for substitutes on Friday at work and I fixed it by setting SSL_CERT_DIR in the daemon’s environment. <rekado>can’t check this right now, though. <necrophcodr>rekado, which i'm not, but i figured as much. i'm using per-user profiles, can the manifest files be used from those directly then? that is, the manifest files in, for instance, $HOME/.guix-profile/manifest ? <necrophcodr>they appear to, but i wanted to be sure before i test it out and ruin test environments too much ;) <civodul>Apteryx, rekado: re the TLS error in 'guix substitute', i fixed it earlier today <civodul>i sent a message today, though i can't find it <civodul>166ba5b10207f44360e218d9e3f00772d09bc7cd <rekado>necrophcodr: I don’t know. I think they are in a different format from what ‘guix package --manifest’ expects, but I haven’t tried this recently. <necrophcodr>rekado, they do appear to be. i'll do my duty and dig deeper. thanks for providing a useful stepping stone to greatness though! <Apteryx>civodul: Yes I found about it in the log <necrophcodr>rekado, it says in the docs that "file must return a manifest object, which is roughly a list of packages: ", which it appears the `manifest` file does, so it should work :) i'll do a bit of testing, but i've got a good feeling about this guix deal. <Apteryx>I've linked my ~/.config/guix/latest to ~/src/guix (my git checkout). Does that mean that any guix commands from now on get run from the binaries under ~/src/guix? <Apteryx>And if I restart the guix-daemon using "sudo hurd guix-daemon restart" it will use binaries from my checkout as well? <Apteryx>I just tried "sudo herd restart guix-daemon", then "guix build hello", but I still get the cert error. Maybe I have to logout & back in after pointing ~/.config/guix/latest to my git checkout? <Apteryx>Because right now, `which guix` returns "/run/current-system/profile/bin/guix", which is a link to a store item. <civodul>right, but then this 'guix' program sets its load path to ~/.config/guix/latest <jonsger>oh very nice, the new news section and feed :) <Apteryx>civodul: OK. Thanks. Not sure why I'm still getting the same error though :( I rebuilt successfully the guix in my checkout like 2 hours ago. <Apteryx>Maybe I need to do "guix system reconfigure /etc/config.scm"? <Apteryx>rekado: Maybe I also need to set this SSL_CERT_DIR like you did. Mine currently points to /etc/ssl/cert. Do you remember the value you had to set it to to resolve your problem? <rekado>Apteryx: I set it to ~/.guix-profile/etc/ssl/certs after installing the nss-certs package. <Apteryx>rekado: OK. Tried, but cannot even install nss-certs. <Apteryx>AFAIU, my guix should be the one I built from my git checkout, but I somehow doubt that. <Apteryx>civodul: Just read you message on the mail list, looks like I should use "guix system reconfigure --no-substitute /etc/config.scm". I'll try that. <civodul>you have to use --no-substitutes to work around the bug until you've successfully reconfigured <necrophcodr>rekado, it didn't work to use the existing one, but rebuilding it from scratch was surprisingly easy to do, so i'll keep a profile.scm file along with me instead, it seems to be a lot more useful anyway. thanks again!