<quiliro>but the problem is comming to a link <quiliro>bavier: what is the command you ran with that .scm? <bavier>quiliro: 'guix system disk-image /tmp/source-image.scm' <quiliro>bavier: package-direct-sources instead of package-transitive-sources ? <bavier>quiliro: vice versa, if you aren't interested in all packages source <bavier>idk at the moment how large an image might be <bavier>quiliro: np, glad we could make a little headway <civodul>lfam, mark_weaver: it seems to be running now <civodul>please keep an eye on the build queue though <civodul>lfam: also, tell mark_weaver if something looks wrong <civodul>well, not sure if the mips machines are in good shape <civodul>lfam: i've started an evaluation of 'staging' <joshuaBPMan_>Hello, I'm dual booting guixSD and Parabola. I'm having trouble logging into gnome as a normal user. I can login as "joshua" in a free tty, but I cannot log into gnome as the user "joshua". <joshuaBPMan_>I should not that my Parabola and GuixSD installs are sharing the same /home partition but have different / partitions. <joshuaBPMan_>I've recently updated all of my packages, and run 'sudo guix system reconfigure /etc/gnome-xfce.scm', but I still can't log into gnome as "joshua". Anyone have any ideas? <joshuaBPMan_>i just search syslog, and I couldn't find anything with "gnome" in it. Does guix use something sdm login utility? <lfam>joshuaBPMan_: GuixSD uses the SLiM login manager <lfam>joshuaBPMan_: Sorry I can't help more :/ My GuixSD system is non-graphical for now. If you can't figure it out, please send a message to help-guix@gnu.org <joshuaBPMan_>lfam: That's ok. And you use a non-graphical guixSD. May I ask why? server stuff? <lfam>joshuaBPMan_: It's just an always-on laptop "server" at home. It used to be graphical but there was a bug in Guix 0.11.0's glibc package that I didn't want to work around, so I built everything from source for a few months. I could do that faster without the graphical stuff. <lfam>I should reconfigure it now that that bug is fixed on the master branch and I can use substitutes again <lfam>I mean, reconfigure it graphically <joshuaBPMan_>lfam: Ok. That makes sense. I've actually just thought of something. I going to log off now. try to log in as my normal user, log in as root and check the syslog file for any changes. That might point me in the right direction. Be back in 10 minutes or so. <joshuaBPMan_>Well I've found some errors in my syslog. Looks like I have some permissions errors with gnome-keyring and parsing a desktop file. <lfam>Wooow, I guess that 21531add3205e400707c8fbfd841845f9a71863a was a long time coming! <lfam>Date: Sun Mar 2 22:39:48 2014 +0100 <lfam>It's a recent commit, but the date is from 2014 <lfam>If you amend a commit, it doesn't change the date <lfam>So, you can keep working on a commit forever but, unless you manually change its timestamp, it will still have the date of the original commit <bavier1>davexunit: I'm looking at your dolphin package right now <bavier1>I haven't tested the build yet, but it looks like it could use a few more inputs: enet, curl, and sfml <bavier1>the license should probably be gpl2+, since the Externals/Bochs_disasm that in unconditionally included is gpl2+ <bavier1>davexunit: the Externals/d3dx12.h has a questionable license <bavier1>since the license header is updated, and the diffs seem limited to whitespace and additional declarations <bavier1>davexunit: or simply removed... since the video backend that uses it is not built <albertoefg>sneek later tell lfam if he wants no play hedgewars <bavier1>In case anyone has been wondering, the source for all Guix packages occupies roughly 15.5G <sneek>lfam, albertoefg says: if he wants no play hedgewars <lfam>bavier1: Who has optical drives nowadays? :) <bavier1>lfam: sometimes I wonder if its only me <lfam>texlive-texmf is ~1/4 of that total <bavier1>davexunit: I was able to buid and start your dolphin package with additional curl and sfml inputs <bavier1>can't test, don't have any of my isos atm <buenouanq>what would a standard partition scheme recommendation look like? <buenouanq>how does Debian decide what sizes to choose for a boot, main, and swap partition on a drive? <civodul>buenouanq: there is no plan when it comes to what packages go in :-) <thomassgn>buenouanq: On my laptop I usualy have swap at 4GB-ish and / on the rest. Simple, seeing as I don't have a lot of space to play with I'd rather not spend time managing partitions much. <thomassgn>on a machine with more space or a less generic use I might partition differently. <thomassgn>does anyone know if guixsd will create mount points for file-systems? <rekado_>about mount points: is there a way to try to mount and give up if the disk does not exist? <rekado_>I have GuixSD on a workstation in our rehearsal room / studio without internet access, so I often take it home to update the system. The workstation has an extra disk for archival. <rekado_>when I use the disk in my laptop it tries to mount the archive disk forever <civodul>what i do is that i have a file-system declaration with (mount? #f) <civodul>so i can type "sudo mount /mnt/disk" when it's plugged in <civodul>downside is that it's not automatically mounted <rekado_>on the workstation this should be mounted, so that users don’t have to do this manually <civodul>we should use the udisks(?) automount stuff for this <rekado_>udisks automounts USB drives, but I haven’t ever used it to mount internal disks. <rekado_>(and it only mounts on user actions, e.g. clicking on the drive icon in a file manager or running “udisks mount -b /dev/sdb”) <rekado_>yes, the archive disk is just a large internal disk <civodul>does it make a difference to udisks? <rekado_>well, udisks mounts drives at /media/username/label <rekado_>and I haven’t seen the disk appear in a file manager. <rekado_>I guess I could run “udisks mount -b /dev/…” in a script after login <rekado_>but… I don’t know, this seems hackish <civodul>actually if you have a normal file-system decl, it may be that the corresponding shepherd service will simply be down if the disk is missing <civodul>BTW i think you should blog about GuixSD & music :-) <rekado_>a couple of blog post ideas (tasks?) are in my org pile… <rekado_>I’ll get around to it eventually, I hope <rekado_>without any of the extra mount options I tried booting without the disk but shepherd would try again and again to mount it. <rekado_>thus preventing the system from booting <rekado_>I don’t know if there’s an fstab flag that would allow us to do this <janneke>civodul: anything i can do to get mingw into 0.12? <fr33domlover>ACTION wonders why mingw would be useful to GuixSD users <civodul>janneke: could you rebase a branch and push it somewhere? <janneke>fr33domlover: to build binaries for unfortunate users <civodul>janneke: i'm sorry to ask you to redo this :-/ <civodul>the problem i have is that when i pick things to review/apply i tend to pick low-hanging fruits that i can complete in a timely fashion <fr33domlover>since i left my last tech job, over a year ago, it's so nice not to need to have any contact with that pr0prietary os stuff <janneke>also, deploying guile/guix `packages' could benifit from a guile.exe <fr33domlover>on the other hand making software support l0sed0w$ hurts our ability to compete. the more software GNU/Linux has and pr0prietary OSs don't, the bigger the reason for people to move <fr33domlover>i mean, i see lots of projects that have a build for l0sed0w$ and 0sx etc. <fr33domlover>but... dunno, just feels like were stepping in the stinky mud just to please users and get popularity <fr33domlover>i'm happy to teach vega diet to cannibals, but i won't serve it on a dead body for them :P <roelj>It's kind of hard to explain "we create software you are free to run wherever and however you wish" if it can only run on an OS that they don't have. <buenouanq>I would much rather have a system I loved and was proud of, than something I could use but was being catered to casuals. <civodul>"catered to casuals"? that sounds a bit elitist no? <civodul>it's just that i think there should not be "casuals" and "end users" <buenouanq>the people that are going to tune it will, and attempting to cater to those that never will only servse to make things worse for the ones that of us that are here <civodul>i think we should reach out to "those who don't tune" so that they eventually start tuning and hacking <buenouanq>yes, and the best way to do that is to have something that's nothing like what they already have <janneke>civodul: re mingw: conflicts in cross-kernel-headers...someone merged their stuff earlier <janneke>this will need some time to resolve, and *ugh* redo all tests <civodul>i guess you were competing with phantomas on this part of the code <janneke>running my tests on all individual patches takes about 2 days...if everything passes :-( <rekado_>there is a difference between making things easier and restricting access to tuning. <rekado_>I would be very happy if people who don't have a background in programming or system administration could use Guix to build the system they want to use. <rekado_>they'd still be users for the most part (like myself when it comes to most free software), but experiencing full software freedom would only be a small step away. <ng0>GUIs don't have to be restrictive. at some point there could be something which works in a set of modules, and those modules you can drag around and assemble, you can edit them if necessary. <ng0>it works better in my mind. or drawn. <ng0>in a project, someone mentioned something to me which just some minutes in looks like nix ops or where ever we are going.. <thomasd>is there a way to use the store path of a package A in the derivation of another package B, without making A a dependency of B? Dealing with some circular references here <thomasd>(package B can refer to A at runtime, but can also work without it) <civodul>thomasd: that's not possible, there cannot be circular references <thomasd>hmm actually that would be unwise, maybe a bootstrapping package A' is needed, so we can have A' < B < A :-/ <civodul>right, that's how we usually address such cases <thomasd>civodul: I think I just came to the conclusion :) <thomasd>but kdbusaddons is responsible for (re-)starting the kdeinit5 process at runtime, which is a /bin output of kinit <thomasd>so if I want to hardcode the store path to kdeinit5 in kdbusaddons, I'd need to to the bootstrapping thing <davidl>im having some install issues and need some help. When running system-init it says "grub-install: error: disk `lvm/my-root' not found" but Im not using lvm. <civodul>davidl: do you have a cryptsetup-encrypted root partition? <civodul>ok, and you're installing from the 0.11 image? <davidl>yes, the latest one on the website. <civodul>that one didn't support encrypted roots <civodul>this has been fixed in the meantime though <civodul>what you can do is run 'guix pull' in the installation image, which will give you the latest Guix <davidl>that only works if you already run guix right? <davidl>this is my first time installation of guix sd. <civodul>no no, you can run 'guix pull' from the installation image, even if you have not yet installed GuixSD <davidl>now it says gzip: stdin: not in gzip format and "failed to unpack source code" <civodul>did you set up networking as explained in the manual? <davidl>I did it with wpa_supplicant and dhclient as explained on the website I think. <civodul>ok, and does it fail systematically? <davidl>though I had a "possible network" issue before so I reverted to --fallback when invoking guix system init. <civodul>can you ping gnu.org or similar from there? <davidl>uhm, it says starting download and fetching patch <url> found valid signature, downloading and unpacking then the gzip error. <civodul>can you run "tar tf /gnu/store/..." on the faulty tar.gz file? <jmd>Is there a way I can get more verbose logging from make-system ? <jmd>s/make-system/make check-system/ <davidl>civodul: do you have any other suggestions or ideas as to why it can't unpack? <civodul>davidl: no sorry; maybe if you could copy/paste the full command and output that would help a bit <civodul>jmd: 'make check-system' simply builds derivations, so there logs are saved in /var/log/guix <Petter>davidl: pastebin.com is a bad paste service, it blocks some users and also mangles data. <davidl>Petter: ok, what's the suggested alternative? ***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | 0.12.0 is in the works! | videos: https://gnu.org/s/guix/help/#talks | bugs: https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix | patches: http://patchwork.sourceware.org/project/guix/list/ | paste: http://paste.lisp.org | log: https://gnunet.org/bot/log/guix'
<Petter>Looks like your network isn't working correctly. Try pinging gnu.org and see if that works. <davidl>sry, I made that paste wrong. network functions. Im annotating it. <civodul>davidl: run 'guix pull' without any argument; the command you gave here cannot work <davidl>returns the same ERROR: In procedure getaddrinfo: Name or service not known, etc. <Petter>How did you check that the network functions properly? <roptat_>hi, I would like to add a package that could be built with python-build-system, except that the steps must be performed in a subdirectory of the source <civodul>roptat_: hello! you can add a build phase that does (chdir "subdir") <civodul>see the 'unpack' phase in mit-scheme for example <davidl>so now guix pull works, it worked after pinging around a little including git.savannah.gnu.org which makes me suspect its some dns cache issue. <jmd>civodul: Which derivation is pertinent to running a system test? <civodul>you can see which derivations it builds i think, search for "build-started" tags in the console <roptat_>my #:phases in arguments is being ignored... <civodul>that is not properly diagnosed, which isn't great <thomasd>I think I've solved my circular dependency problem, but is there a way to automatically verify I didn't mess up? <thomasd>so I'm correct that circular dependencies only show up when the daemon actually tries to build derivations of the packages? <civodul>circular dependencies currently result in a stack overflow when trying to compute the derivation <civodul>that is, "guix build foo -d" would crash <thomasd>yes, but I've changed a number of KDE packages in the process (switching from the old kdbusaddons to an inherited package), so I should try to build all of them <thomasd>Meanwhile, let me submit a feature request for "no-messing-up" :-) <jmd>Does anyone else get "BUG: unable to handle kernek paging request ...." about every 2/3 attempts to run make check-system ? ***the_ktosiek is now known as ktosiek
<civodul>thomasd: "guix lint -c derivation" will tell you if there's any circular-dep style issue <civodul>it's a good idea to rebuild the relevant KDE packages though, to make sure they still builds, ofc <rekado_>I'd like to learn how to use Geiser better when doing Guix work. <rekado_>To be able to use M-. I need to have all Guix modules loaded into Geiser first, no? <branko>'lo folks. Guide suggested sharing experience, so just a small comment that current installation instructions include command "ifconfig interface up" - this one by itself did not obtain IP etc (had to run dhclient manually). <rekado_>are you using guix-switch-to-repl for this? <davexunit>geiser works by querying the running guile process <rekado_>guix-switch-to-repl is very slow for me, probably because my Scheme files aren't all compiled. <rekado_>do you run make each time you switch branches? <davexunit>I didn't even know guix-switch-to-repl existed until now <rekado_>I have so many branches here and switching them changes the timestamps, which makes Guile think that I need to compile everything again. <rekado_>switching from one branch to another and back again I'm again asked to compile everything <davexunit>usually my branches aren't vastly different so I only have to recompile a few things <davexunit>I think using git subtrees would make you happier <rekado_>I'm already using different workspaces to keep my regular Guix installation separate from all the wip stuff. <ng0>civodul: is there an ETA for 0.12 release? <davexunit>that way if you're working in many branches you don't have to recompile stuff so much <rekado_>with worktrees I always get confused about files that are already open in Emacs <rekado_>like "is this the emacs.scm from guix or from guix-wip...?" <rekado_>not happy about having to open a bunch of files from different worktrees <rekado_>I have 16 branches right now (and that's all current work, after merging and deleting some more branches). <rekado_>having a worktree for each of them feels clunky <ng0>I have 60 branches (guix) and some more checkouts and I don't like it either. <rekado_>could ccache or something like it be used? <davexunit>I think you'd have this problem in any project where you have 16 active branches <rekado_>yes, but that doesn't make it any less annoying :) <davexunit>I've never managed branches at that scale so I don't have any useful suggestions at this point. <ng0>i think my ~/src/guix/* is at 2GiB and more <rekado_>when you build guix do you do this inside of "guix environment guix" or do you install the dependencies somewhere? <rekado_>so do I but the lack of persistence also means that things are not safe from GC. <rekado_>after GC I need to manually fix up the shebang, run "guix environment guix", then reconfigure, and then make. <davexunit>if the shell started by 'guix environment' is running then it is protected <rekado_>so I'm considering to have a separate profile for all Guix deps <davexunit>the connection to the daemon remains open the entire time <rekado_>right, but in my case I rarely ever leave the environment active. <rekado_>I only need the guix environment when I build guix. <davexunit>or write the patch for 'guix environment --save' or whatever ;) <roelj>How can I disable the stripping of binaries for a package? <rekado_>do you know of a shortcut to load up all (gnu packages *) modules in the REPL? <davexunit>rekado_: it's doable, just needs a bit of code. <davexunit>assumes that the current working directory is the root of your guix source tree <davexunit>rekado_: oh but first run (use-modules (ice-9 ftw)) <davexunit>I can make the relevant changes before I submit upstream <davexunit>I didn't realize those libraries were bundled. <davexunit>I've used it to play a gamecube game online with other people <bavier1>I couldn't get it to take our enet package; didn't look at the logs though <davexunit>so it works quite well for me! getting the "broadband adapter" feature to work is a pain, though. it's no fault of guix, but it requires root privileges to setup a bunch of virtual network devices. <bavier1>I'd love to do some multiplayer melee <davexunit>and then the ethernet device can't be used for anything else while you're playing... <davexunit>and then the device isn't able for it's regular usage <paroneayea>davexunit: sadly putting "input" as a group for my user didn't fix pressure sensitivity in the wacom tablet... too bad! <paroneayea>it does work but I have no pressure sensitivity. <paroneayea>well, and it should register the eraser separately <paroneayea>you have to do something, and I forget what since my Gentoo days ;), to get the pressure and eraser working. <paroneayea>could be that our kernel doesn't have the wacom driver enabled. <paroneayea>or could be that we don't have the right udev rules. <civodul>ng0: i think 0.12 will be after the repro build summit <paroneayea>hm, someone wants to do a Jitsi call with me this week. I have a feeling Jitsi isn't a trivial thing to package. <paroneayea>iirc java isn't a fun packaging time in guix and maybe elsewhere too <rekado_>on the plus side, many jars are portable <rekado_>if jitsi doesn't depend on any bindings to system libs you might be able to just use the pre-built jars <roelj>In a couple of days we may get root access on our HPC for guix-daemon, but now that it's almost there, the non-root solution is working quite streamlined and well that I almost feel bad to give that up. <civodul>roelj: giving up on that brings tangible benefits too :-) <davexunit>ludo likes to say something and then drop the mic <roelj>It would be great fun to have the CI system deal with git pushes to package repositories. Something like git push -> CI server builds tarball -> CI server builds package with new tarball -> CI installs that package in a per-program profile -> user can directly access it through that per-program profile. <ng0>a nice maintainer pov writing about how hard negative articles can be and that there should be more outreach to the positive ones, etc <efraim>I assume you meant (let ((dir "SRC...")) <jmd>how can I find out why a service is not starting in the marionette? <ng0>hm. I did submit an epic5 package, or was this something I planed to do? <ng0>but no one comented on my questions since october <ng0>so the question is, drop gdbm functionality? <ng0>I will just asume gdbm is not vital for it <ng0>our online documentation is outdated again.. isn't this handled by a cron job or something? <Petter>How do I find out what f.ex. (with-directory-excursion) does? <thomasd>I think it does, if not it's just a package-install away <thomasd>then, from a guix source buffer, you can say "switch to REPL and enter module", to start a guile repl with the current module loaded, <thomasd>and Geiser can provide information on symbols (docstrings + links to source) <doktaNG>okay, I think I'll send this updated epic5 package <thomasd>Petter: though it won't magically work on every symbol. I believe expressions which are to be run by the build daemon and are quoted in the package descriptions are not analysed. (Other people on this channel should be able to provide a more proper explanation :-) ) <Petter>It looks like some configuration is needed, it says "no documentation available" for everything I've tried so far. <thomasd>ah, yes, you need to add the path to your guix source to geiser-guile-load-path <thomasd>yes, and the geiser manual itself is also usefule <Petter>Thanks for showing me the light! :) <ng0>why don't we have lib/libssl.a in our openssl? <ng0>while libressl has it <quigonjinn>is there a way for the build daemon to have network access while carrying out a build phase? <davexunit>quigonjinn: network access would apply to the whole derivation. the only derivations that may have network access are "fixed output" derivations where the sha256 hash is known in advance. <quigonjinn>davexunit: are there any examples I can take a look at? <ng0>alezost: ok, so what's the exact symlink format you want? something which takes the already created soffice symlink as a target? <davexunit>quigonjinn: source code downloads are the only example. <davexunit>my guess is that you are asking to do something that guix won't allow, though. <davexunit>maybe you should describe your problem more. <alezost>ng0: If 'libreoffice' should be placed in the same directory ("bin"?) then just: (symlink "soffice" "libreoffice") <ng0>*sigh* I'll build libreoffice then. but I think this could be changed without verifying it works? otherwise I'll compile it over night <alezost>ng0: don't build it; it's easy to check without building <alezost>so (symlink "soffice" "libreoffice") will surely work <ng0>i noticed a typo in my commit message, i'll send an update any minute <quigonjinn>davexunit: you are probably correct that guix won't allow. I am trying to bundle some java stuff for my university lab, namely maven. <davexunit>the usual problem here is that the build system is also a package manager that downloads pre-built jars. <davexunit>it's a tough problem to get software like this into guix. <alezost>ng0: I mean it will work inside (with-directory-excursion (string-append (assoc-ref outputs "out") "/bin") ...). Here is a simple guile script that you can test: http://paste.debian.net/900959 <alezost>(assuming you have "/usr/bin/env" and guix modules in your GUILE_LOAD_[COMPILED_]PATH) <ng0>ah right, the directory excursion i asked for in the mail i've just sent <ng0>so it can be shorter <quigonjinn>davexunit: yes i'm aware. i see there has already been some effort on this one <ng0>alezost: i#ve just sent the new version with-directory-excursion. could be that it can still be made shorter <janneke>i was kinda lucky: none of the cross-base conflict/changes triggered any compiler/libc rebuilds <janneke>readline-7.0 needed a patch...but i worked triggering non-cross rebuilds by using a mingw-specific CPP make flag... <janneke>and i removed wip-mingw32 some time ago...seems something did not update? <civodul>oh i was looking at your github.com thing, not the gitlab.com one <ng0>does an web radio player for the command line written in guile exist? if so I can spare myself the time to convert my bash player to guile <civodul>janneke: note that we cannot add the cross-toolchain variables at the bottom of cross-base.scm <civodul>i think it was just a convenience though <lfam>civodul: If a package foo fails spuriously on Hydra, and I restart the build, will packages that failed as a result of foo's failure be restarted as well? <civodul>lfam: does it fail to new offload issues or something else? <civodul>i just fixed an offload issue as i wrote on guix-sysadmin <lfam>There was a spurious failure of gobject-introspection on staging. It succeeded when I restarted the build of that package. But the thousands of failures that resulted are still failing. Should I request a new evaluation? <civodul>instead you should request to "restart all dependency-failed jobs" <civodul>in the "actions" menu of the evaluation page <lfam>Ah, that sounds like what I need :) <davidl>how long does it generally take to build something like webkit? <davidl>I passed the --fallback flag to the guix system init command and it's been building webkit for hours... <ng0>depending on your machine 1 - 13 hours <davidl>then probably somewhere around 13 hours <ng0>do we capture the start and end time of builds? this way we could easily get something where length of build is recorded and can be queried <davidl>maybe a -i flag for interactive fallback mode. <ng0>there was this gentoo tool I used for this, you could list all builds, all builds of a certain application and the build which is currently happening and depending on wether there was previous recorded data it would give you an ETA <lfam>david1: Supporting interactivity in the builds would break the functional packaging model? How would the human interaction be accounted for? <lfam>And yes, building webkitgtk takes a very long time <davidl>lfam: Im not qualified to answer either of those questions unfortunately xD <davidl>the interactivity I considered was just something along a regular install script where you press yes or no. <lfam>david1: Do you get what I mean? The functional packaging model tries to take all the inputs (source code, build scripts, etc) of a build into account, so that binaries can be substituted for building from source, but still be expected to provide the equivalent result. If a human do interact with the build process non-deterministically, this breaks the model <lfam>Where do you think it would be useful to have a yes-no dialog? <davidl>yeah I see kind of. I have programmed some haskell but Im not a developer. <davidl>while invoking the guix system init command with a flag. <davidl>I used --fallback so it would build packages from source which it couldn't download as binaries for some reason. <davidl>but since those build processes take so long in case of webkit then maybe you would want to individually say to not build some packages. <lfam>I typically use --dry-run before "big" things, to make sure I'm ready <davidl>I suppose I should have done that. <davidl>then I could have made sure to fetch these packages manually or something. <davidl>but Im not sure, since webkit also has dependencies? <lfam>If you can't fetch a binary substitute for webkitgtk right now, it's because we don't have one available. <lfam>david1: Are you usig the 0.11.0 USB installer image? <davidl>the 0.12 I think, since I entered guix pull to get the latest one. <lfam>I don't believe we've tagged 0.12.0 yet :) <lfam>So, you are somewhere in between <davidl>I was gonna do full disk encryption but needed lvm2 for grub to notice mapped devices. <lfam>I was going to suggest `guix pull` after explaining some caveats. But since you already did that, I think that we must have made some change recently that requires a webkitgtk rebuild, and that rebuild is not done yet <lfam>My best recommendation is to initialize with an OS configuration that doesn't require any graphical packages. Once you have the system installed, then reconfigure into a graphical system. <davidl>The build can run overnight =) not a big problem really. <lfam>Initialization is still somewhat brittle, so I prefer to init with the simplest system possible. Once installed, the system is very robust and you can reconfigure, roll-back, etc <lfam>But, if you are willing to run your x200 overnight, I think that webkitgtk will be done by then :) <davidl>mhm. Ill try that if it doesn't when I wake up. 
