<kevinfish>I've copied the USB install image to my "installer" disk and checked it to be DOS/MBR with file -s <kevinfish>but when I go to boot it with linode it says: Cannot Direct Disk boot a disk with no MBR: <laertus>automake has been testing itself for almost 4 hours now <apteryx[m]>IpswichTriptych: are you on latest master? Or old 0.13? <Apteryx>This particular problem should have been addressed by commit fe5519954. <Apteryx>laertus: how much ram does your box have? <laertus>i have almost 5 gigs of free ram right now <Apteryx>IpswichTriptych: OK. Note down the package which is failing to build due to that timeout (maybe Guile?), and then run "guix build package-name". after the package is built you can retry "guix pull". <Apteryx>laertus: if you are concerned about your security you might want to run "guix build --check some-package" in a while to rebuilt it locally; this will also warn when the hash of the generated binaries changed. It's covered in the user manual of Guix as well. <Apteryx>In Guix, we aim for bit reproducible builds, so if guix build --check fails that is either 1) a bug or 2) something fishy about the substitute obatained. <laertus>Apteryx: but if i've already installed and used a compromised package, by then it'll be too late <laertus>the malware could have already stolen my ssh keys, for instance, or keylogged by bank login creds <Apteryx>laertus: as long as your "guix" package is not compromised, I believe "guix build --check" should give you a trustable result. <Apteryx>oh, if you mean for the damage possibly done, yes. <laertus>i'd like to prevent that damage first and most imporantly of all <laertus>getting notified that i've been hacked is good too, but prevention is more important <Apteryx>there might already something being done when installing a package (checking that the hash on at least two substitute servers is the same), or could be done about it. <IpswichTriptych>Apteryx: what is the correct way to configure for avahi? (services (cons* (avahi-service) (xfce-desktop-service) %desktop-services)) ? <IpswichTriptych>or avahi is already included in desktop-services and therefore redundant... <IpswichTriptych>I ran "guix pull --verbose" ... it seems as though java is the one that caused the pull to fail <Apteryx>IpswichTriptych: I don't know about avahi. Have you looked in the manual? <IpswichTriptych>Apteryx: yep, it appears that avahi-service is included in desktop-services by default ***Piece_Maker is now known as Acou_Bass
<kevinfish>I've copied the USB install image to my "installer" disk and checked it to be DOS/MBR with file -s <kevinfish>but when I go to boot it with linode it says: Cannot Direct Disk boot a disk with no MBR: <xshumeng>I want to install the Guix into my compute, but i failed. can you help me ? <atw>we might be able to help. What's going on? <kevinfish>happy_gnu[m]: yes, I have on a regular machine. Not on a virtual server tho <happy_gnu[m]>It seems to me it is related to the type of image guix use <kevinfish>happy_gnu[m]: right now I'm just trying to install guix onto debian and use it to build guixsd on a different disk partition <kevinfish>its very weird that it sees a dos/mbr from file but not from linodes boot <kevinfish>I don't know if anyone's successfully gotten it on linode yet. I haven't found much about it on the search engines <kevinfish>do you know debian much? It seems to be missing some packages to compile guix <xshumeng>i'm sorroy. My English is too bad. I want to say a lot, but I said very slowly. <xshumeng>anyway, i just want to install that operating system into my computer by flash driver. <kevinfish>xshumeng: what OS does your machine have on it now? <kevinfish>okay, you're going to need something to write out the installer program onto your flash drive <IpswichTriptych>xshumeng: Did you select the GuixSD image that corresponds to your system's architecture? (i686 or amd86_64) <xshumeng>^_^, i have another one computer, apple mac osx <happy_gnu[m]>GuixSD is great but is in beta and my lack a few things. So if you install both Trisquel /GuixSD you will have benefits of both <efraim>Apteryx: you'd have to check the inputs and native inputs of the other GCCs, I made some changes there within the last month or two <Apteryx>efraim: thanks, you are correct. gcc 4.9 was overriding the native inputs field. <Apteryx>anyone good witch package matching? I'm failing at it, and don't see why ;) <laertus>with almost 4 hours of that being just automake testing itself <laertus>actually, looks like it didn't even complete <laertus> output path `/gnu/store/c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar.gz' should have sha256 hash `1cdwcw38frc1wf28x5ppddazv9hywc718j92f3xa3ybzzycyds3s', instead has `0ywcxw1mwd56c8qc14hbx31bf198gxck3nja3laxyglv7l57qp26' <laertus>is there anything i can do about that? <janneke>laertus: apparently the libgit2 source tarball contents have been changed -- not good <janneke>i just checked, the 0.26.0 tarball contents also changed <laertus>so does this mean that i've already run possibly compromised code from this library? <laertus>or does the warning i got mean that guix stopped before that code ran? <janneke>or at least: the hash changed; it could be harmless, but ugly for sure <laertus>i'm just not sure how to interpret that error message <janneke>it stopped when it found the source tarball content hash didn't check out <laertus>ok, so it never used that source to build, right? <laertus>is there some way to make my "guix pull" proceed with a version of the libgit2 source whose hash does match? <laertus>or do i just have to wait until guix maintainers fix this? <janneke>laertus: i'm not sure, it might be more difficult than that <janneke>you're running guix pull on 0.13, right? <janneke>laertus: are you using --no-substitutes? <janneke>okay yes, that's why you're hit by/detect this change <janneke>you can get around this by `building' the source using substitiutes <laertus>ah.. but i want to avoid substitutes <laertus>good to know that it's possible, though <janneke>something like: guix build -S libgit2 <laertus>i think i'll just wait until this gets fixed and try again ***pksadiq_ is now known as pksadiq
<laertus>i think it was mentioned here that github tarballs are generated on demand and are not necessarily bit-identical every time <laertus>maybe this libgit2 hash mismatch issue is due to that ***pksadiq_ is now known as pksadiq
<janneke>laertus: anyway, would you like to send a bug report to bug-guix@gnu.org? <jherrlin>i am having some problem with *system reconfigure* and grub. <jherrlin>i can reconfigure the system and it seems to work correct, i get a new entry when i look at *list-generations* <jherrlin>but when i reboot the system and i enter the grub menu, i cant find any item pointing to that generation <janneke>jherrlin: are you familiar with this? the new generation should be the first, default entry <janneke>jherrlin: old generations are available under a menu-item `GNU system, old configurations' <jherrlin>janneke: i know that the first entry should be the latest, but i think something happend <jherrlin>after removing everything from /boot and running a new system reconfigure, the first item points the the current generation <janneke>hmm, state in /boot that breaks stuff? <jherrlin>hmm, maybe i was stupid and changed the mount point or bootloader target <jherrlin>as you are saying, does not make sense that a state in /boot would break stuff right? <janneke>well, relying on file-system state is kinda evil so i hope we're not doing that <jherrlin>no, i am not doing anything outside if a "basic" config.scm <roptat>I finally have a package for maven, entirely from source! <roptat>I used most of what htgoebel1 did a few months ago, that was very helpfull <roptat>but it was still really painfull <roptat>also, I get this error when I try to search for a package on current master: <roptat>texinfo.scm:966:36: In procedure loop: <roptat>texinfo.scm:966:36: Throw to key `parser-error' with args `(#f "Unknown command" begin)'. <roptat>currently my maven lacks its wagon-http component, which means it cannot download precompiled dependencies, and it throws a warning about "unsupported slf4j logger" <roptat>sure, let me push my latest modifications <roptat>then you need to build the "maven" package <jherrlin>janneke: my grub is working again, stupid me doing stupid stuff <roptat>actually it won't work right away, I remember I did some modifications to the ant-build-system <janneke>jherrlin: hehe, don't we all -- well good to know <olivuser>hello everyone. I'm pretty sure I once read it in the manual (checked using CTRL-F, couldnt find)... I am currently on a distro other than GuixSD but try to incrementally get there from testing and adapting the system declaration file. My question: is it possible to test the working of a system declaration file without any actually building it and preserving all the errors that I would run into if it were to be built? <htgoebel1>roptat: I only had a quick look, but your package looks much leaner than mine. What's th trick? <roptat>maven uses something they call an "injector" to replace some of the fields in their classes at runtime <roptat>and it uses META-INF/sisu/javax.inject.Named and META-INF/plexus/components.xml to find out what dependency they can inject <roptat>they actually use two separate injector: javax.inject and eclipse-sisu-injector <roptat>the latest is a fork of plexus-containers-default. sisu-injector is used by maven but some of its deps still use containers-default, so the trick here was to use the correct one <roptat>also they have a fork of eclipse-aether called maven-resolver-*, so maven doesn't work with aether <roptat>I found all that by finding a binary distribution of maven, replacing each component one by one and not getting further until it worked again <htgoebel1>I was thnking about maven just a few days ago. <roptat>I will try to get wagon-http and then produce patches that I will send to the mailing list <roptat>olivuser: you can test with the -n option (it will not build anything), or by running "guix system vm" (it will build the system and you can test it in a vm) <efraim>Guix doesn't automatically cache failed builds <efraim>You can also run 'guix system build os-config.scm' to build the system declaration without installing it <roptat>if you want to examine a package that failed, you can use "guix build <package> -K", it will be kept in /tmp <janneke>olivuser: what is it about `the working of a system declaration file' that you want to test? why don't you want to build it? i have no idea what it is that you want to do or to avoid. <olivuser>roptat: I think I dont understand what you mean by "-n". do you mean to add it like "guix system -n"? <janneke>ah roptat overlooked your response ;-) <olivuser>janneke: I actually have very little clue about both scheme, guile and guix. I am trying to learn it by myself, so I am considering it a long term project with a lot of testing. <olivuser>efraim: thanks, I actually found that one out by myself and I guess this will be how I am doing it. <janneke>olivuser: see you already got some answers, good luck! <roptat>do we have a way to get the list of all packages in the inputs field from the builder, excluding those in native-inputs or propagated-inputs? <efraim>Do you mean like (package-inputs my-package)? <efraim>We have a couple packages that have (inputs `(("foo" ,foo) ,@(package-inputs bar))) <roptat>no, I mean from the builder, in a phase I would like to list packages from inputs <roptat>you can use #:key inputs #:allow-other-keys to get all inputs, but I don't want the native-inptus and propagated-inputs <janneke>ACTION updates another git-0.13 box ... again fell into the libgit2 trap ;-( <Apteryx>laertus: file a bug about non reproducibility of libgit2 <Apteryx>I don't believe it blocked the installation though, did it? It should be just a warning I think. <Apteryx>laertus: oh wait. it's a tar.gz which has a hash mismatch? Then it probably simply got updated in-place upstream. That's bad, but it happens. <icendoan>Hi, is there a guide anywhere for installing guixsd with uefi? <efraim>which libgit tarball are we looking for? I can check my aarch64 builder <efraim>/gnu/store/c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar.gz <janneke>efraim: yeah, i think the old tarball comes from hydra too (or else my local build server?) <janneke>possibly we should file a bug with the libgit2 project? <efraim>We could, not sure what good it would do <Apteryx>janneke: wasn't there another report of github tarballs being mutated? <janneke>Apteryx: not that i know, i did search for 'github' in debbugs <janneke>but as github is proprietary software, i can imagine they don't really care about such things <janneke>Apteryx: 20 days ago...we're pretty late re-discovering it... <janneke>"I don't know. We don't create these archives ourselves, they're automatically generated by GitHub." -- great <Apteryx>I think the problem is that Github apparently generates the tarball on the fly; which means, if it's infrastructure got updated (updated tar, updated gunzip), the result might change. <Apteryx>It seems dumb to regenerate the tarballs on the fly instead of once and caching it, but who am I to judge. <janneke>Apteryx: isn't that a symptom of not caring about software freedom? <Apteryx>hmmm. I need to read more about it before I can draw a conclusion. <Apteryx>anywhere we can poke github about that ugly issue? <Apteryx>they don't have github.com/github ;) <janneke>Apteryx: i don't care so much that github delivers a proprietary, borken service <janneke>i'm much more apalled that people decide to use it <Apteryx>yeah, I agree it is not great to put so much reliance on a central, proprietary platform. <Apteryx>The day they are bought and decide to change their hosting policies the FOSS world will scramble for months. <jherrlin>icendoan: hey, did you manage to install? <icendoan>No, not managed it yet. I figured out how to install grub-efi and specify that as my grub in config.scm, but trying to init with that fails. Running init with --no-bootloader and trying to grub-install myself is also failing <jherrlin>okey, what about if you umount it from /mnt/boot and mount it to /boot? <icendoan>No, same error (which is `grub-install: error: /gnu/store/...-grub-efi-2.02/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory'). It's a bit bizarre that it's after the i386, since this is an x86_64 image. I'm also not sure how to pass either of those flags in from the config. <jherrlin>okey, what about update with *guix pull* and *guix package -u*? <rekado>I’m trying to install GuixSD on a couple of servers. <rekado>I thought that I could be faster by not installing Guix from the tarball, then guix pull, then guix system init <rekado>instead of tarball + guix pull I wanted to build the system on a separate server and copy it over <rekado>now I did “guix pack guix” and copied that over to the target and ran it. <rekado>problem is that as soon as I use guix this way it appears to remove things under /gnu/store <rekado>so as “guix package -i” is running, the glibc package disappears and thus none of the applications from “guix pack” can be executed any more. <rekado>I don’t know at what point the glibc package disappears <rekado>this comes down to the problem of having something in the store but not in the database, I think <rekado>makes this route to GuixSD from Ubuntu less comfortable <IpswichTriptych>Good morning, folks. I'm back at it today. Trying to run "guix pull" followed by "guix system reconfigure /etc/config.scm" on a Lenovo X60 with 1GiB RAM and 4 GiB swap. Last night, "guix pull" timed out while compiling Python, so I ran "guix build python" (success!), and this morning I'm retrying "guix pull --verbose" <Apteryx>efraim: any progress with multi-disk btrfs? <janneke>rekado: what about /var/guix database? <janneke>rekado: i've maintained a deb-package for guix for a while, now we're just using a bash scripted binary-install <cbaines>there was also a bash installer sent to the guix-devel list a while back <janneke>cbaines: i like it that people do that, but tbh it scared me a bit; i'm able to audit 6 or 7 commands from the manual... <cbaines>yeah, when looking at that installer, I think it did a bit too much <rekado>I wrote a Guile script that builds the OS configs for all build nodes and then copies them to the target. <rekado>I’d like to do almost all of the work on the head node <rekado>only initial network and SSH configuration should be done on the target <rekado>janneke: the guix that I wrapped up with “guix pack guix” and unpacked on the target has no idea that there are other things under /gnu/store <rekado>so when I run “guix package -i” it seems to remove the existing thing under /gnu/store and try to build it. <rekado>I guess I’ll just need to write a script that populates the database with everything that “guix pack” wrapped up. <efraim>Apteryx: I haven't tried again yet <janneke>rekado: yeah, that makes sense...you need something inbetween guix copy and guix pack <icendoan>Okay, I've pulled and updated. Now, init is failing because says that the grub field in the grub-configuration is extraneous. If I remove this, it tries to install via bios, and not via efi. Is there a way to specify that I want to use grub-efi? <janneke>how sad i'm not automagically sharing that with you all... <icendoan>Yeah, that looks very similar to my problem. <icendoan>Huh, if I init with --no-bootloader and then use a manually installed grub-efi:grub-install binary then that works without error (but hasn't got me to bootable yet!) <Apteryx>efraim: I have a couple hours in front of me; I'll spend those on attempting to figure out how to get btrfs + raid1. If you'd like to join forces you're welcome! <ng0>though I had no chance to run it not in guix, so maybe it's not guix specific. but maybe someone sees a mistake I don't see yet <ng0>okay I figured it's just a python error <slim404>when I try to guix pull, I get an error : <slim404>guix pull: error: build failed: build of `/gnu/store/z99jmrjnzd30w28px70qp4q0s1pc34g3-guile-git-0.0-3.e156a10.drv <slim404>before that, I get a bunch of errors : <slim404>ERROR: failed to create path for auto-compiled file "/gnu/store/yf0j9s16dwyfz5y5w6f1z1h4mgf0w1xx-guile-2.2.2/bin/guild <slim404>note that when I guix pull as root, it works great <slim404>IpswichTriptych: 4G if you include swap disk <IpswichTriptych>slim404: Ah, OK. That should be enough, especially if you're not having problems when you pull as root. <slim404>IpswichTriptych: when I'm not root, I'm using gnome. You think it's a RAM problem? maybe I should try pulling from terminal <efraim>does anyone have an os-config with a tmpfs? <slim404>IpswichTriptych: thanks, that's helpful <Apteryx>Hello, looking at (gnu tests install), I'm very confused about the relationship between os-installation-scripts block devices and the way they appear under qemu. Take for example %raid-root-installation-script which defines a mapped-device over /dev/vdb{2,3}... then in the %raid-root-os-source refers to these as /dev/vda{2,3}... ? <efraim>jherrlin: thanks, i forgot to check The Fine Manual <Apteryx>Any qemu doc I should read to understand the rules/logic related to how these paravirtualized devices appear? <Apteryx>efraim: you could also check %separate-home-os in (gnu tests install), it uses a tmpfs filesystem for the separate /home partition. <pazzo>hi there, i just installed guixsd and wanted to build another install image, but first wanted to look at the files in gnu/system/examples/ but i can't find that folder <pazzo>am i missing a package or something? <janneke>rekado: tried reverting several xf86-video-intel and xorg-server patches...haven't found what's breaking xbacklight yet -- giving up for now and using /sys/class/backlight/intel_backlight/brightness :-( <jherrlin>pazzo: if you are in an installed system you can find the examples by *find /gnu/store/ -type d -name examples* <Apteryx>IpswichTriptych: yeah the heaviness of 'guix pull' is compiling the Guile modules that composes Guix; that is a bug in the Guile compiler which was introduced in 2.2. civodul is working on it. <IpswichTriptych>Apteryx: cool, I'm glad what I said was accurate. I ordered more RAM for my system, so hopefully I won't be having as much of a problem running guix pull regardless. <Apteryx>IpswichTriptych: I have 4GB myself and wouldn't say that I'm "swimming" unfortunately. I need to close Icecat everytime I want to run "guix pull". <IpswichTriptych>Apteryx: I was being a little facetious. 3GB is certainly not very much in 2017, but it is the maximum the Lenovo X60 permits unfortunately :( <IpswichTriptych>Could someone explain why guix pull must start from the beginning when it fails? <IpswichTriptych>I'm a novice at these things, but it seems to me that just like a package wouldn't be recompiled once it has already been compiled that the same should hold true for when guix pull fails towards the end of an iteration? <IpswichTriptych>Is it just because the steps are "download...compile...install"? so, if it fails before the install step, all that work is lost? <slim404>Apteryx: the error message : ERROR: failed to create path for auto-compiled file "/gnu/store/yf0j9s16dwyfz5y5w6f1z1h4mgf0w1xx-guile-2.2.2/bin/guild <slim404>Apteryx: does not seem to be about memory usage <Apteryx>indeed, it seems more of a permission issue. <Apteryx>slim404: what kind of install is that? <slim404>Apteryx: should I correct permissions the "roots" way? :) <slim404>Apteryx: also, when I guix pull as root it works <Apteryx>So you're problem is that it fails when running "guix pull" as a user? Did it use to work before? <slim404>Apteryx: err.. I don't know.. it's not supposed to work? :/ <slim404>Apteryx: when I install a package as a user, guix asks for a guix pull <slim404>Apteryx: my user packages don't seem to be updated <ng0>what is "the root way"? <slim404>Apteryx: ..and I can't guix package -u without guix pull it seems <Apteryx>IpswichTriptych: Not completely true; the dependencies (inputs) of Guix that were built/downloaded when running "guix pull" will not have to be redownloaded again. In the case of the Guix source modules, yes, currently, this has to be restarted over if "guix pull" didn't succeed. <slim404>ng0: /gnu/store/yf0j9s16dwyfz5y5w6f1z1h4mgf0w1xx-guile-2.2.2/ <ng0>just regard /gnu/store as something you never touch manually <Apteryx>slim404: my question was did it work at least once before (did you successfully run guix pull as a simple user in the past?) <Apteryx>if it never did it might be a problem in your operating-system declaration (config.scm) <slim404>Apteryx: I don't think so (it's been around 3 weeks I'm installing guix sd on my netbook, so I could have forgot) <slim404>Apteryx: it could be indeed, it's a LUKS encrypted partition <slim404>Apteryx: but there should be another explanation <Apteryx>slim404: could you post the full error message at paste.lisp.org?