<efraim>i'm trying to find a version of isl that doesn't break cloog but does support aarch64 <efraim>new plan: update isl to latest, update cloog to latest, try to fix cloog <z0d>why are e.g. games in one package file and not split? <civodul>z0d: there's no real justification, other than we avoid to have one package per file <efraim>I (think I) got pretty far on aarch64 bootstrap-tarballs but ran into a snag with isl being too old. I'm trying to find an isl/cloog combo that will work but I'm not quickly finding one <rekado>haha, our institute is hiring and among the desired skill set is this: "experience establishing shared software profiles using reproducible builds (e.g. Guix)" <foobarry>hi guys, i'm testing out guix in HPC environment <foobarry>is there a bunch of bioinformatics packages i can install in one go? <rekado>ACTION wonders why "guys" is still so popular as a greeting :) <rekado>when you install guix and update to the latest version you'll have access to all of these packages. <foobarry>ok ta. is there a way to install all the bio tools using a meta package? <rekado>you can install them by listing them in a manifest (see the manual for how). <foobarry>(btw guys is male and female in my part of the country) <foobarry>ok, i need to define the manifest, or there is one already ? <rekado>the manifest is just regular scheme code, so if you can filter all bioinfo packages with scheme you can also install all of them. <rekado>I suggest not doing this, though. <z0d>yeah, usually 'guys' can mean both genders <foobarry>how are you getting on with guix in your HPC? <rekado>we leave software installation up to users <rekado>i.e. they have manifests for each project they work on. <foobarry>do you also provide packages outside guix? <rekado>and then install the set of software they want in a separate profile ***davi_ is now known as davi
<rekado>for other software we really also use guix :) <foobarry>looks like it would be a lot of work to add that for guix ***davi is now known as Guest83122
<rekado>the way people use it here is usually: guix package --profile /my/project/.guix-profile --manifest=/path/to/project/manifest.scm <rekado>then: bash; source /my/project/.guix-profile/etc/profile <rekado>at that point they are in an environment with all the Guix stuff available that they defined in the manifest. <rekado>to leave the environment just "exit". <foobarry>and how do they switch between samtools 2.10 and 2.05 <rekado>they'd use separate profiles, usually. <rekado>because you don't generally want to have both in the same project. <foobarry>is there any best practice documented anywhere for HPC? <rekado>I'm working on adding things to the manual, but I have been too busy lately. <rekado>not sure if it's *best* practice, but I'm sure that it is practice :) <rekado>I think we're about to switch to Uneva Grid Engine. <foobarry>we are on SGE, just bought univa, but infra guys are slow to deploy the hardware <rekado>we've got three different clusters and they have been on SGE for as long as I can remember. <rekado>the plan to move to Univa has been around longer than I've been working here. <foobarry>and learned a load of new stuff thats in UGE <rekado>we have group profiles as well as personal profiles. <foobarry>still can't quite see how they could access gcc4 vs gcc3. <rekado>the group profiles are managed by IT in much the same way as traditional software provisioning works. <rekado>the personal profiles are managed by the scientists themselves. <foobarry>is that documented anywhere? example of group profiles etc? <rekado>it's just a special case of using "guix package -p" <rekado>we've just made sure that the shared profiles can be accessed by groups instead of single uids. <rekado>I really should take some time and add some HPC documentation to the manual. <foobarry>if we adopted it i would certainly document <rekado>me too! But currently I'm doing work for 2--3 people; should get better by the end of May. <rekado>ACTION has to get back to sysadmin drudgery <cbaines>Trying to run guix package -u and getting a 410 error from mirror.hydra.gnu.org. What does this mean? <foobarry>ERROR: Throw to key `ftp-error' with args `(#<input-output: socket 7> "RETR Test-Deep-0.114.tar.gz" 550 "Test-Deep-0.114.tar.gz: No such file or directory\\r")'. <shymega>cbaines: according to HTTP status dogs, the resource is 'gone'. Which package does it fail on? <foobarry>Test-Deep was not found on multiple ftp servers <rekado>has the Test-Deep tarball been removed...? <cbaines>shymega, Sorry, was not looking at IRC. It's texlive-20150523-texmf. <rekado>I had the same problem. Looks like the cached item has been removed. <rekado>You can add --fallback to build texlive-texmf from sourc. <z0d>how do you log out from Gnome Shell? I can only reboot and shut down <-: <z0d>the usual user menu isn't there <z0d>well, I can do Alt-F2 gnome-session-quit <jlicht>z0d: that was also something I was wondering, thanks :-) <z0d>jlicht: I seemed silly to reboot just to be able to log in as user after resetting his password <-: <wingo>z0d: usuall that means that you don't have the desktop services running <wingo>humm, actually i see the same things :) <wingo>there must be some service that gnome-session isn't finding or something <z0d>wingo: I think it's a shortcut. I'm not sure if Gnome Shell creates it or not <foobarry>"guix package -i bowtie" causes the issue <jmd>From guile, How can I find out if a package is installed ? <efraim>can't test my changes to connman atm because it wants to rebuild gcc-4.9 :( <civodul>the xtensa cross-compiler for the ath9k firmware <civodul>you can work around it by setting 'firmware' to '() in the os config, if that's an option for you <efraim>I was double-checking now, but yeah I remember seeing that <efraim>I can do that, it's just the minimal config i made with openbox + connman <rekado>foobarry: are you not using substitutes? We do have binaries for bowtie. Of course, the underlying issue of the missing tarball needs to be addressed. <ng0>so I reassembled my laptop after flashing and I have 11 screws left and the laptop is stable... weird wormhole screw mystery <foobarry>no it's my first day playing with it. the manual wasn't very linear so i started playing <rekado>did you install Guix from the binary release tarball? <rekado>then substitutes should be enabled by default, actually. <ng0>normally I have around 5 <foobarry>hmm. i had to guix archive --authorize < hydra.gnu.org.pub <ng0>i can see 2 in the back missing which i still need to get in, but that's all <foobarry>i didn't know what that was at the time, and it sounded kind of optional. which it is, i guess <foobarry>a separate getting started guide might be more apt <foobarry>output path `/gnu/store/9s87z7j59w6cchy1xdmwcfy30812apan-edirect.tar.gz' should have sha256 hash `1cr3gzcs3flmgnnbj5iz93vh9w0fca1ilzi2q82cl63ln3mwvpz0', instead has `15zsprak5yh8c1yrz4r1knmb5s8qcmdid4xdhkh3lqcv64l60hli' <davexunit>foobarry: seems to me that upstream has changed their source tarball <foobarry>most packages are older than our installed ones <foobarry>and quite a few build issues such as that <foobarry>guix packages vs ones we build manually at some point in the last few years <davexunit>foobarry: this is a volunteer effort, you know. if upstream replaced their source tarball, then we need to fix it. <davexunit>guix has many distinct advantages over just building things manually <foobarry>most people in my place asking for it are asking because of getting newest versions quicker <davexunit>well, it depends. we generally update things to the latest version quickly, but of course this depends on volunteers caring about those packages. <davexunit>it's very easy to update these recipes if they need a version bump. <davexunit>but look, if guix isn't for you right now, that's fine. this is beta software maintained by a small group of volunteers. <foobarry>i'm evaluating, kicking the tyres , rather than dissing <foobarry>because the main reason the bio guys are asking is not a reason, and i'm surrprised <foobarry>but i was raising it here in case there was a reason that i had missed <foobarry>their main reason is to get new versions of apps faster <foobarry>but only 10 of the apps they wanted are available and most are older than our current set of apps. so its not a magic bullet <davexunit>we are generally quite up to date when compared to other distributions. <foobarry>of course they have a guy that is paid to look after the bio guys <davexunit>the point is that guix gives you a framework for controlling the complete dependency graph of your applications. <foobarry>obviously most of the issues i've experienced are solved by a larger community of contributors <foobarry>but at some point somebody has told the users that they will always have bleeding edge apps of all their desires <bavier>sounds like some marketing that didn't come from the guix developers <bavier>but, if you have your own resources that could be put into maintaining the packages you're interested in, it could still work out that way <davexunit>in practice, guix generally *does* have newer versions of things than other distros. <foobarry>i'm gonna look at the recipe files to see how much is involved <foobarry>we're still evaluating this alongside jenkins <foobarry>which would be quite a bit of work to maintain <davexunit>if the software hasn't changed dependencies or build system, then updating is just changing the version number and the checksum for the source tarball <foobarry>can i reference a local recipe file to build from <davexunit>you can extend guix with your own packages by maintaining your own fork or by using GUIX_PACKAGE_PATH as explained in the manual <kristofer>foobarry, I'd venture to guess almost every guix user is maintaining certain packages manually <foobarry>location: gnu/packages/bioinformatics.scm:125:2 <davexunit>foobarry: it's on disk in /gnu/store somewhere, but read-only. <davexunit>if you want to modify guix packages to submit upstream, then you should clone the git repo <civodul>foobarry: you can use "guix edit packagename" to view/edit a package definition <civodul>easier than searching for the source file ;-) <foobarry>i'm struggling with the checksum - is it not sha256sum? <rekado>foobarry: re edirect: that's an annoying upstream issue. I'm half-decided to throw out edirect. <z0d>sh: emacs: command not found <rekado>they keep updating the tarball in place. <rekado>it's no fun to try to catch up with them. <foobarry>how are the sums generated? i can't match the checksum with md5 or sha256 <mark_weaver>foobarry: they are sha256 hashes, but the hash is serialized to a string in a different way <bavier>rekado: ftp://ftp.ncbi.nlm.nih.gov/entrez/entrezdirect/versions/ <rekado>re versions: I've been packaging the majority of the bioinfo stuff in the past, but for the past two months I've been excessively busy doing unrelated work. Since bioinfo tools are not that popular among Guix contributors they don't get updated as often as other packages. <rekado>bavier: thanks! This looks good. <bavier>looks recent; they might have heard your cries <foobarry>bamthanks guys, i got bamtools 2.4.0 built with your help <foobarry>guix package: warning: failed to load '(bioinformatics)': <foobarry>ERROR: no code for module (bioinformatics) <foobarry>if i copy bioninformmatics.scm to a custom folder and change the GUIX_PACKAGE_PATH <rekado>the module name is related to the path. <bavier>foobarry: the file declares the (gnu packages bioinformatics) module, so the file needs to be found at gnu/packages/bioinformatics.scm under GUIX_PACKAGE_PATH <rekado>GUIX_PACKAGE_PATH/packages/bio.scm would have to contain a module named (packages bio) <rekado>bavier: updated edirect. Thanks for pointing out the new URL. <rekado>foobarry: while Guix could be used to get access to more recent versions its main feature for us is reproducibility and independence. <foobarry>how would i switch to bamtools 2.3.0 instead of 2.4.0? <rekado>you'd have to have a package expression for that version. <rekado>in that case the output should tell you that there are conflicts that guix resolved by picking one or the other. <phant0mas>janneke: have you ever tried to build libiconv targeting linux? <rekado>designing a new poster now for OTS2016 (which is, erm, tomorrow) <rekado>need to come up with pretty things now. So difficult! <civodul>a pink background, a logo, a diagram with packages-as-functions <rekado>I'll recycle 50% of my previous poster, but I'll need more positive pretty things. <civodul>an illustration of "practical freedom" <rekado>didn't think of (idealised) console snippets; will add those. <rekado>"practical freedom" is easy to demonstrate. A poster is a difficult medium. <wingo>someone in a mask holding a gun and a keyboard <rekado>(I have the pink background already and the function diagram) <wingo>a tag cloud of java web frameworks <rekado>wingo: that's stock photography when searching for "hacker" <davexunit>someone *has* to use that title for *something* <mark_weaver>civodul: btw, I cancelled the gnome-updates jobs yesterday because I noticed that some changes were made on master that forced a moderately large number of rebuilds. <mark_weaver>civodul: I just merged master into gnome-updates and asked hydra for another evaluation <mark_weaver>maybe we should let that evaluation complete before restarting queue-runner? <civodul>i stopped the queue runner earlier today to evaluate master <civodul>and then i, ahem, kinda forgot to restart it <davexunit>ACTION patches imagemagick vulnerability the hard way because guix hasn't conquered the world yet <davexunit>looks like even we haven't updated yet, though. I can probably take care of that. <davexunit>updating imagemagick causes libreoffice to be rebuilt, along with 68 other smaller packages. <davexunit>is that an okay price to pay for pushing to master? <davexunit>I guess I'll update to the latest 6.9 series <davexunit>ACTION tries getting rid of it since it's trivial ***jgay_ is now known as jgay
<ajgrf>i don't understand how /etc/profile doesn't end up in an endless loop on guixsd <ajgrf>seems like it should just keep sourcing itself <ajgrf>the first line to execute (other than setting variables) sources /run/current-system/profile/etc/profile <ajgrf>which also sources that file <mark_weaver>ajgrf: /run/current-system/profile/etc/profile doesn't source /etc/profile on my system. does it on yours? <mark_weaver>on my system, /run/current-system/profile/etc/profile consists solely of environment variable settings <ajgrf>no sorry, i mean /etc/profile sources /run/current-system/profile/etc/profile, which then sources /run/current-system/profile/etc/profile again <mark_weaver>ajgrf: can you paste your /run/current-system/profile/etc/profile somewhere? <ajgrf>oh sorry, looks like it was just a case of me mixing up my emacs buffers <mark_weaver>civodul: bah, hydra's method of scheduling between jobsets is terrible. gnome-updates has 50 scheduling shares, and master has 100, but queue-runner just allocated *every* slot to gnome-updates <mark_weaver>I have no idea how to prioritize master except to temporarily cancel all of the gnome-updates jobs :-( <mark_weaver>after the important things are built on master, I'll restart the gnome-updates jobs <civodul>mark_weaver: ISTR that individual jobs have a priority too, no? <mark_weaver>civodul: yes, and I've gotten in the habit of setting those manually to direct hydra <mark_weaver>civodul: but hydra only uses priorities to prioritize within a single jobset <mark_weaver>it has some different mechanism to schedule between jobsets, and I guess that's what the jobset's "scheduling shares" is about, except that it doesn't seem to work properly. <mark_weaver>very often I've seen queue-runner allocate all slots to a single jobset, even when multiple jobsets have pending jobs <civodul>bah, i admit i never groked this "scheduling shares" thing <mark_weaver>civodul: well, I'm just venting, no need to waste your time on this. <jlicht>is someone currently using artanis 0.1.2 on guix? I'm having some weird issues, where the artanis store entry yet again has a gnu/store/asdfasdfasdf-artanis-0.1.2 dir, where the actual modules and binaries are located <mark_weaver>civodul: I looked briefly at the queue-runner code, and might attempt to hack it a bit, although my perl-foo is rather weak these days :) <janneke>ACTION just refactored mingw, ncurses, libtool; now ncurses does not cross build anymore ... %-/ <phant0mas>this is frustrating, shouldn't libiconv build on x86_64? <mark_weaver>phant0mas: iiuc, there's no reason to use GNU libiconv on a GNU system, because GNU iconv is built into glibc, or something like that. <davexunit>does anyone know how to set the gpg binary that git should use? <davexunit>I need it to use gpg2 but it's trying to use gpg 1 and failign <davexunit>trying to sign my imagemagick update commit before pushing <davexunit>of course, I found it immediately after asking... <davexunit>I was crawling the docs looking for the config option for it <mark_weaver>what the Subject header for the discussion on guix-devel about signing git commits? <mark_weaver>I haven't had time to keep up with the ML lately, but I'd like to find that thread. <phant0mas>mark_weaver: but does this mean that we shouldn't be able to build it while targeting a GNU system? <davexunit>mark_weaver: it was on bug-guix, subject: bug#22883: Trustable "guix pull" <mark_weaver>phant0mas: I agree that it should ideally build, but I guess it's not something people do in practice, so I'm not surprised that it fails <civodul>phant0mas: the 'gets' think is a "known issue", see gnu/packages/patches/*gets*.patch :-) <rekado>in two or three simple words how would you express that Guix gives you a safety net to experiment with software without fear of breaking stuff? <bavier>"dependable, hackable, liberating" ;) <rekado>I'm trying to come up with a couple of little feature blobs, each with a small graphic. <rekado>one of them is "GNU inside!\\n100% free software" <rekado>another is about reproducibility <ajgrf>Guix: "trusted computing" for realz <janneke>sneek: later tell phant0mas: thanks for testing my package, we'll have to see about a gets.patch then <sneek>Welcome back phant0mas, you have 1 message. <sneek>phant0mas, janneke says: thanks for testing my package, we'll have to see about a gets.patch then <adfeno>Guix: Empowerin*g*, A*u*tomated, L*i*bre, E*x*pandable :D <rekado>thanks for all the creative suggestions :) <adfeno>Then, "SD" suffix will refer to system distribution. <mark_weaver>might that be caused by chapters running "guix gc" while this offload was being arranged? <mark_weaver>so the offload sees that a .drv file is already on chapters, so doesn't transfer it, but in the meantime GC deletes it? <jmd>What is the smallest consol on which we envisage GuixSD will be used? <mark_weaver>jmd: did you mean to write "console"? smallest by what metric? <jmd>mark_weaver: console Yes. <mark_weaver>do you mean the size of a text console, for purposes of an ncurses interface? <frafra>how do I get the sha value for the package I'm trying to create? <mark_weaver>frafra: if the source tarball is signed, please check the signature first <adfeno>Welcome frafra. I'm not a Guix user, but I plan to be. :D <frafra>adfeno, thank you too :) I waited many months before try to install guix sd <adfeno>Besides, I sometimes help people with their questions, as long as I can find the needed information. <frafra>I have a simple one: is it possible to change cflags? <jmd>Am I correct in thinking that the messages from the substituter go to current-build-output-port ? <mark_weaver>frafra: if you run guix directly from a git checkout (as most of us developers do, and I highly recommend), then you can run out of your own private git branch, with arbitrary modifications to guix, while easily integrating our upstream work into your branch <mark_weaver>frafra: in that case, you can easily make global changes like that, but of course if you do that you'll have to build everything from source code yourself. <mark_weaver>frafra: but we don't provide any easy way to set global compile-time preferences like that, analogous to gentoo USE flags <frafra>mark_weaver, thank you, really helpful <suitsmeveryfine>Is it only I who cannot reconfigure from master? I get "suspicious ownership or permission on `/gnu/store/72cp43sqala9j0hn3fsy5bcsc8whgjqb-clutter-1.24.2". <mark_weaver>suitsmeveryfine: I think it's just you. what are the permissions (and ownership) of that directory? <suitsmeveryfine>mark_weaver: drwxrwxrwx 3 guixbuilder01 guixbuild 4096 4 maj 20.27 include/ <mark_weaver>frafra: the online manual should be from the most recent release, 0.10.0, about 5 weeks ago <suitsmeveryfine>mark_weaver: how did this happen? I haven't modified anything there myself <mark_weaver>suitsmeveryfine: is your guix-daemon running as root? <suitsmeveryfine>mark_weaver: when I try to apply chown I get "Filesystem only readable" <frafra>(I was asking because the hello packages looks different on my box) <mark_weaver>suitsmeveryfine: on GuixSD we use some bind mount magic to make /gnu/store mounted read-only, to prevent people from accidentally editing things in there, which would lead to badness <mark_weaver>suitsmeveryfine: did you edit something somewhere to set umask to 0? <suitsmeveryfine>mark_weaver: the only thing I can think of is my my encrypted /home in the OS definition. <ajgrf>mark_weaver: suitsmeveryfine: a similar thing happened to me last week, although i can't remember which package it was. i never did anything to fix it, just waited and tried the reconfigure again later with a new "guix-latest" <mark_weaver>suitsmeveryfine: can you do "ls -l /gnu/store | grep rwx" to find out how many directories in there are writable? <ajgrf>so maybe we both messed up our own systems somehow, or maybe it is a bug in guix <ajgrf>suitsmeveryfine: no i think it just used a different package version when it worked the second time <mark_weaver>suitsmeveryfine: can you email bug-guix@gnu.org about this? <mark_weaver>including the output of "ls -l /gnu/store | grep rwx" and mentioning that this is on GuixSD <suitsmeveryfine>grafting '/gnu/store/pm1043sf438anc08xzw2sgc89rrjiir2-clutter-1.24.2' -> '/gnu/store/72cp43sqala9j0hn3fsy5bcsc8whgjqb-clutter-1.24.2'... <frafra>no code for module (gnu packages alsa-lib) <frafra>I suppose I'm not specifying dependencies correctly <ajgrf>suitsmeveryfine: unfortunately i've also garbage collected my system since then, so `ls -l /gnu/store | grep rwx` doesn't return anything noteworthy. just some packages which happen to include rwx in their hash <mark_weaver>frafra: the alsa-lib package is in gnu/packages/linux.scm, a.k.a. (gnu packages linux) <mark_weaver>frafra: you can find where a package is using "guix package -s" <mark_weaver>in general, module (a b c) is found in a/b/c.scm within some directory in the load path <frafra>mark_weaver, ah, got it! thank you <frafra>not something we can build... mmm.. <suitsmeveryfine>mark_weaver: I remember that you discovered that swap isn't working after the dmd -> shepherd transition <efraim>trying to update gnupg, took until the 9th mirror for the file to be found <alezost>suitsmeveryfine: yes, it should work now <mark_weaver>suitsmeveryfine: iirc, the problem was specifically that I specified my swap device as /dev/disk/by-label and for some reason that wasn't working. but that was long ago. <mark_weaver>iirc, it always worked when specifying the device as /dev/sdaN <suitsmeveryfine>I don't want to create a swap partition but a swap file. Is it safe to do that in the root directory? <mark_weaver>suitsmeveryfine: I haven't tried it, but I would expect it to work <mark_weaver>remember, with guix, if you already have a system installed that works, you can be reasonably certain that if you install a new system that's broken, you can still boot into an older version of the system <mark_weaver>grub is the only package that, if broken, will make it less convenient to boot into your system. <suitsmeveryfine>mark_weaver: so I'd probably need to take out the HDD and put it inside another computer if I ever needed to select an older system version <mark_weaver>suitsmeveryfine: does the T60 have an exposed serial (RS-232) port? <mark_weaver>(as in, a raw serial device, not a USB serial adapter) <mark_weaver>suitsmeveryfine: in that case, I guess you could use GRUB via the serial port. if you're using GRUB from Libreboot, I guess maybe that's set up by default. <suitsmeveryfine>But I can't see GRUB in GNU Screen because I use a very old version of libreboot that produces an error that hides the second GRUB menu that you load <suitsmeveryfine>If I use a more recent version of libreboot then I can see the grub menu but the keyboard doesn't work :/ <mark_weaver>suitsmeveryfine: well, it might be that Guix's grub.cfg menu would show up if we changed our grub.cfg to support serial devices. <mark_weaver>I don't think we do right now, but I don't have time to check at the moment.. <janneke>aaarghhh changed something, somewhere now i686-w64-mingw32-libtool does not work anymore <frafra>guix build error: #<unspecified>: not something we can build <rekado>frafra: how do you try to build things? <rekado>this sounds like you build from a file that does not return any package value. <rekado>the file must end on a value, e.g. the package variable that you defined. <mark_weaver>frafra: when you use -f, the file has to end with an expression that evaluates to a package object. so, just add the name of the package object on a single line at the end <davexunit>frafra: the file must evaluate to a package object <rekado>(I never used "guix build -f file") <mark_weaver>at some point, I would recommend building guix from a git checkout, and then you can add packages to the guix source itself <mark_weaver>but that doesn't have to be right now, of course. things like -f and GUIX_PACKAGE_PATH are useful to lowering the barrier to adding new packages <davexunit>I added 'guix build -f' primarily for making it easy to build package files that are used for dev environments via 'guix environment -l' <davexunit>each of my projects have a guix.scm file that I can use to make development environments or build snapshots <frafra>rekado, mark_weaver, davexunit, really thank you <frafra>as soon as I'll be able to build it correctly, I'll clone the git repo <mark_weaver>frafra: when the time comes, see the 'contributing' chapter of the guix manual <mark_weaver>specifically "building from git" and "running guix before it is installed". don't run "make install" <rekado>at some point I just had to wrap it up and print it. <rekado>would have liked another day to procrastinate and refine it. <rekado>no command line snippets, because I'll be sitting right next to it to demo guix. <frafra>rekado, I've seen these colors and layout today; I was looking for slides and presentations about guix <frafra>fosdem 2016 if I'm right; are you the author of that presentation? <civodul>mark_weaver: looks like a GC race, technically a bug in 'guix offload', but for now i'd suggest simply restarting it :-) <civodul>maybe you should replace samtools/bowtie with emacs/vim or something <rekado>frafra: yes, there are two FOSDEM 2016 slide sets that I prepared. <rekado>civodul: I ran out of time there and just went with what I already had :-/ <rekado>(thinking about the new illustrations took way too much time.) <civodul>ah yes, prolly needs to be made larger <civodul>but core-updates makes Perl's closure much smaller, which should help <civodul>rekado: no problem, it's great! the package names are just a detail <civodul>ACTION has a working system test infrastructure, lots of fun :-) <frafra>where modify-phases instruction should stay? <rekado>frafra: it's used inside the arguments field. I suggest you look at any other package definition. <rekado>I know what the problem with Tuxguitar is: our build of SWT is bad. <rekado>there are two parts to SWT: the native libs and the Java part. <rekado>the Java code assumes that it's built on a 32 bit system. <rekado>there are lots of "int /*long*/" in the code. If built on 64 bit systems "long" should be uncommented. <rekado>I'll first change the java-swt package to use the ant-build-system (it's much faster than the custom build phase that we have right now) and then patch the code conditionally. <frafra>sorry if I disturb you, but I never used guile; it says "unbound variable: modify-phases" <alezost>frafra: 'modify-phases' is in (guix build utils) module, but you shouldn't need it if you use it inside a package definition. Could you show the package you are working on? <alezost>frafra: my guess is: you didn't quote 'arguments' list <frafra>alezost, mmm... no, even worst... syntax error... I didn't see it because it was distant <frafra>I think I'd better go to sleep :D by the way, it compiles correctly now! thank you all :) <frafra>I'll just try to install and run it now <cow_2001>just installed the thing and it looks very cool <frafra>trying to figure out how can I install it :) <frafra>oh, it was just guix package -i -f file.scm <Luoar>hello everyone! I just did a guix system init and it worked. <Luoar>only thing so far: keyboard is qwerty. i would prefer qwertz. should I have declared this in my config.scm? <ajgrf>Luoar: sort of. you can declare it in config.scm to change the *console* keymap. currently it won't change your keyboard layout in X <ajgrf>that will hopefully be fixed soon, but i don't know the best way to work around it right now. there is always setxkbmap to change it from the command line <alezost>I don't think it will be fixed soon, as it's not the bug <ajgrf>i know it's not exactly a bug <ajgrf>but it would be nice if you could just specify it once and have it take effect everywhere it needs to <alezost>there is "console-keymap-service" that can be specified in a system config, and as you pointed it is intended only for console (the same as "loadkeys ..." will do). X server can be started in various ways, I think it's up to a user to change a layout there <Luoar>thanks for the answers and fir reminding me of setxkbmap :-)