<ng0>hi. I submitted my soon-finished work in progress of rust.scm to the list. I won't have time to work on this any time soon, but I'm sure someone here might have more time to put finishing touches to it. <free_>hi! i have just installed guixsd following the lightweight desktop configuration file. how am I to configure fonts, add directories to path, etc? <zacts>which kernel is 0.10.0 using? <zacts>(I want to make sure my wifi driver is supported (it's a libre atheros device, but it needs >= 4.*)) <zacts>nice, that will for sure work <zacts>I think in the future (maybe a couple of years from now), a GUI installer and GUI package tools would be cool. <zacts>I just think that guix would be better than debian dpkg for background updates, for people who don't know the command line <zacts>debian background auto-updates always break eventually <zacts>guix could be the first gnu/linux distro that non-tech savvy users could use reliably <zacts>due to the design of the guix package system, and rollbacks, and all that jazz <rain1>how would you make a GUI package tool? <zacts>rain1: I don't know, but some sort of GUI interface into the guix commands? (I honestly don't really know even how feasible this would be) <zacts>but at least to install + uninstall + rollback + upgrade packages kind of thing <zacts>and maybe if absolutely needed, a frame with a bash prompt and instructions on commands right next to it for newbies who want to learn a bit more <zacts>(I'm just completely tbrainstorming here) <zacts>rain1: I don't know what implementation language or framework would be best, but probably guile maybe? <zacts>does guile have any GUI bindings? <pizzaiolo1>sadly PackageKit devs think it is too much work to do it <rain1>it would be someone from guix tha does the work, no? <zacts>does packagekit rely on systemd though? <pizzaiolo1>I use PackageKit with parabola, it's super handy <zacts>if we could get it to work with dmd that might be cool <rain1>yeah they renamed it to shepherd though <geeks>hi :) I'm new to geeks. how is one supposed to configure path, fonts, etc in guixsd? <rain1>geeks: for fonts you can just install them as packages <rain1>for PATH i think you can edit .bashrc or .bash_profile i forgot which one <geeks>ok. so it is normal way then .D <geeks>by configuring fonts I mean the filter, hinting etc <geeks>usally one can use the "switches" in /etc/fonts/conf.d <rain1>ah im not familiar with this, hopefull somoen else will know <pizzaiolo1>geeks: someone helped me set up that, the process seems a bit different, but I haven't learned how to actually do it myself ): <geeks>I'm trying to install the texlive package <geeks>but the substitutes seem to fail <geeks>I tried to download from the texlive file <geeks>and it doesn't seem to run the setup file <rain1>guix package -i texlive --no-substitutes <geeks>but i got an error when i tried to run the executable setup from the texlive file <geeks>i don't recall it precisely (i'm not at home right now) <geeks>sorry. i'm not being very specific :s <geeks>ah! and when i installed icecat <geeks>it had instructions to export path at the end <geeks>and i could not run icecat without exporting the path <rain1>maybe you need to log out and back in <rain1>sometimes guix installation adds vaariables for you <rain1>but they aren't applied instantly <geeks>soo you don't have this behaviour? <rain1>eval $(guix package --search-paths=prefix) <geeks>ok. thanks :) i will look it when i get home. maybe i will reinstall with a full desktop. <zacts>how does icecat differ from debian iceweasel? <robsyme>Does anybody know if there is a trick to getting the guix icedtea package to recognise certificates in /etc/ssl/certs? <taylan>zacts: it's more in line with GNU ideals; includes plugins for security, privacy, and hindering of non-free JS by default. <taylan>IceWeasel is purely a rebranding AFAIK? <lfam>With grafts, is it necessary to put (replacement #f) in the new variable? I see it in some commits and not others <civodul>lfam: i wondered too ;-), but actually no <civodul>the code doesn't traverse replacements <civodul>it's just (or (package-replacement p) p) <lfam>civodul: When we make grafts, do you think we should also make a commit to a "fix-without-grafting" branch that can be merged into security-updates or core-updates later on? <civodul>sneek: later tell lfam re "fix-without-grafting", for now i would suggest moving fixes-without-grafts to core-updates, but it's really a build scheduling problem in the eend <civodul>{fencepost,git.sv}.gnu.org unreachable :-/ <janneke>'bout time they swich to GuixSD, no ;-) <civodul>though it's unclear how much it would help here ;-) <civodul>i think there's one physical machine hosting a whole lot of VMs <civodul>probably explains why everything can be down at the same time <rekado>robsyme: I'm not very knowledgeable about Java but I know that certificate stores can be set up at configure time. Could be that our package would need to be changed. <taylan>all gnu.org were down and all are up again it seems <civodul>iyzsong: let me know if/when you think it's the right time to rebuild gnome-updates <robsyme>rekado: Thanks :) I'll have a look around online at configure-time store defintiion and a closer look at the icedtea definition. <iyzsong>civodul: I just rebase it upon master, and have build and test locally the 'gnome' meta package before the rebase :-) <iyzsong>civodul: i'd like to add the xdg profile hooks too, it will fix some issues for GNOME. will report back when I finish the build (and test with gnome-desktop-service). <ng0>civodul: if I build the website from the repository of guix artwork, how many external static sources are there if there are some at all? I'm thinking of cloning it and providing a mirror in onionland. <jlicht>Am I correct in assuming that guix-specific patches for software should ideally be submitted and integrated upstream, but otherwise included in the guix git repo? <taylan>jlicht: if it's a generic fix for the build system of the software or such, then yeah, ideally it should go upstream <taylan>there may also be instances where there's a really guix-specific patch, such as gnu/packages/patches/mupen64plus-ui-console-notice.patch, which don't belong upstream <jlicht>taylan: In this case, it _is_ actually already accepted by upstream, but not released yet. So until the next release it can go into the guix repo, I assume? <taylan>I would say yes, together with a comment within the package recipe that says the patch should be removed when the version is updated <jmd>I want to build/install a package with complete debug information and without optimisation. Is there an easy way to do that or do I need to write a custom package definition? <jmd>WTF!? Has bootstrap-binaries changed recently?? <jmd>phant0mas: I just did a guix build on some small package and was suprised to see the substiter download gcc coreutils bootstrap-binaries and almost everything else. <jmd>Ahh maybe because of commit 7de1f10363bab159c77b5728743703b4c1614848 <janneke>git show 7de1f10363bab159c77b5728743703b4c1614848 <ngz>Hello. I packaged thinkfan, a fan control program. The compilation is successful. However, there are two issues: 1. the thinkfan program must be run as root, and think_fan acpi kernel module has to be loaded with a specific option. What would be the proper way to handle this at the package level? <ngz>I guess the first issue can be solved by adding thinkfan to %setuid-programs. <ngz>Also it is not much of an issue on a foreign distribution. <ngz>(so is the second actually...) <ngz>I assume the second point could be solved by creating a service, although I have no clue about what service to extend to load kernel modules. <taylan>packages themselves can't declare that they need setuid root AFAIK. (automatically making them suid 0 when they request it would be insecure since users can arbitrarily command the daemon to build packages in a guix system.) so it needs to be done at the OS configuration level. <taylan>(as you said, with %setuid-programs) <cpjjl>Hi, I read in the documentation that it was not encouraged to put standard user packages (such as VLC or whatever) in the config.scm declaration because it installs them system-wide. <cpjjl>My question is: is there a way to install user-packages _declaratively_? <cpjjl>maybe in the config.scm where the user stuff is… <cpjjl>but there does not seem to be anything like that in the documentation <cpjjl>and anyway it wouldn’t make sence to put it in config.scm <cpjjl>because standard users don’t have write access to it <rain1>i think thaht there is a way, and it's something to do with manifest files <ngz>Hmmm, actually one can load modules with `base-initrd'. Not sure how to provide options tho. I cannot find anything about it in the manual. <taylan>cpjjl: see 'guix package --manifest=FILE' <jlicht>ng0: I've been having a look at your rust package, but it seems that part of the build process is downloading a stage 0 bootstrap binary <jlicht>which seems to be a Bad Thing, looking at it from the guix perspective :O <taylan>jlicht: we already have a few like that. the issue will be addressed Eventually... <rain1>jlicht: good or bad it's logically impossible to avoid it <random-nick>why do so many languages try to self-host before they got a large ecosystem? <taylan>rain1: not really. rust in particular could in theory be bootstrapped from C. <rain1>I beleieve 99% of the badness is removed if the bootstrap is reproducible and it is verified that downloaded binary = bootstrapped binary <taylan>random-nick: it's a compiler development milestone / badge of honor I guess <rain1>sadly the bootstrap is rarely reproducible - but Chez is! <jlicht>if I understood correctly: In a perfect world, we would bootstrap everything via C. (E.g., build compiler 0.1 with gcc, then iteratively build newer version of the compiler) <taylan>jlicht: yes, and the C compiler would be verified through other means <rain1>jlicht: because C compilers are so enormous and complicated I would rather it not be from C <jlicht>but right now, (or if this is not realistic), we package the bootstrap binaries as well? <jlicht>*compiler specific bootstrap binaries <taylan>for the cases where bootstrapping from another language is unrealistic, there's still possible strategies to reduce the risk. we had a thread about this on the ML recently. <taylan>TL;DR: somebody has to start working on one of the plausible solutions and see where they get :) <rain1>GHC needs itself to bootstrap <rain1>no i don't think anyone else can compile it <jlicht>taylan: I tried to follow along with this thread, although it quickly went beyond my paygrade so to say ;-). <rain1>sadly it's another enormous enormous beast, way bigger than gcc <rekado>random-nick: it doesn't use hugs. <df_>C compilers don't *need* to be enormous and complex <jlicht>Is there any flag or commenting convention that is used to signify that a package actually is one of these 'untrusted' binaries? <rekado>currently we use a fat GHC binary to bootstrap. <rain1>df_: I just wish there was a nice simple one taht had good coverage <rekado>it's on my list to experiment with bootstrapping GHC from an interpreter, but I don't have time for this at the moment. <df_>hmm, whatever happened to lcc <rain1>jlicht: no there isn't - I actually suggested this as a good idea but I don't think they liked it <rain1>df_: oh yeah lcc used in quake3 i've seen thaht! I like thaht one a lot <rain1>I should have a go using it for normal programming <df_>oh, it's non-free though <random-nick>is it possible to implement haskell on top of guile? I don't think it is <rain1>ah i see.. that is realy unfortunate <rain1>random-nick: a lot of things are possibly but nobody is doing it <z0d>random-nick: why not? <rain1>there's no obstruction to implementing that, except that it's a huge amount of effort <df_>I wonder whether it's that way for ideological or profit reasons <rain1>df_: the ' Addison Wesley' bit is worrynig <rain1>that's a publisher... publishers are..... yeah <rain1>I think there is zero chance of this ever beeing free <df_>it looks like the authors retained copyright <df_>and david hanson is apparently retired, so you never know <df_>8cc or tcc might be worth a look too <civodul>ng0: currently some of the "assets" (mostly PDFs) are not in guix-artwork.git, only on gnu.org/s/guix <rain1>8cc is half the size of lcc, which is otherwise the shortest <df_>it's x86-64 only, that's got to save a lot <df_>also it's not clear how complete it is <df_>is that just clang or the rest of llvm too? <civodul>rain1: we need to package ldc and 8cc and see how far we can get with them <rain1>by ldc - is that The LLVM-based D compiler ? <davexunit>downloading git from mirror.hydra.gnu.org at 13KiB/s :| <random-nick>davexunit: GNU's server(s?) seems to have a lot of problems today <jlicht>did any results from the fsf-related donation drive get published already? <rain1>oh but lcc is not free software <rain1>I actually sent an email asking if they will consider relicensing it, will see what they say <rain1>yeah its sort of only education purposes or something <df_>I suspect it's just that they're academics and aren't keen on people getting rich off their work, in which case they may well be persuadable <civodul>jlicht: basically we have the money, and we've been waiting for a Libreboot-capable server, which should happen Real Soon Now, we're being told <civodul>davexunit: weird, i would think it's been in cache for some time <jlicht>civodul: Seems like a successful drive :-). Good to hear <davexunit>civodul: well, it could be networking here, but nothing else really seems sluggish. it started downloading other things a bit faster afterwards. <civodul>jlicht: yes, it worked great! too bad the Libreboot thing is taking longer than we thought, but it's worth it <bavier>with the "patches" tool, is there a way to list uncommitted patches? <civodul>if everything goes well, that is :-) <bavier>oh, I missed the part about boolean operators <bavier>had to read the python source to get an idea of what's available <civodul>yeah, documentation is, ahem, sparse <davexunit>civodul: looks like I warmed the cache for you, yeah. :) <civodul>davexunit: actually nar/m80rgjyqznlb98lccbb813xqa43laxk8-git-2.7.4 was put in cache on Apr. 21 so i don't know, something else must have gone havoc <davexunit>could just be my network. I didn't do a very scientific analysis. <civodul>digitteknohippie: i see rank 72 for the last month, no? <civodul>comes after ReactOS, interesting :-) <bavier>they include a pretty ugly rendering of our nice logo <ADFENO>Although popular, DistroWatch seems to make mistakes, specially regarding distinctions between "open source" and "free software". <bavier>maybe want to send some corrections <ADFENO>And... "education"? Ok ok ok.... I know that Guix educates alot of people regarding how to make packages that can be reproducible builds... <ADFENO>... but I see "education" as means for college and high school materials. <ADFENO>I think Guix can also be used as a server, specially if you want to provide your own substitutes to other Guix users around the world. <digitteknohippie>i do look forward to the day i have my server running guix. with gentoo (or nearly any other distro) upgrades can be a little scary. <ADFENO>DistroWatch, (dramatic pause) What are you doing?! <taylan>digitteknohippie: Guix is totally configurable, like Nix. we could eventually have a base OS configuration for servers, assuming we don't already have one. <ADFENO>I'm pretty sure I have seen some server configuration lying around.... <rekado>today I learned: Guix comes out of the USA. <bavier>rekado: seems like a default value ***vasile_ is now known as vasile
<davexunit>civodul: distrowatch says that guix is a distro from the USA <davexunit>which is wrong and also a weird thing to categorize since distros are always global volunteer efforts <rain1>wouldn't it be best to say it comes from france? <davexunit>that would be more accurate, but it's also from the US, the UK, etc. <davexunit>weird to associate a digital thing with a country <ADFENO>From Brazil also... I heard there's a Brazilian contributing to Guix. <bavier>yeah, it's strange they don't have a "global" value <df_>is the chief distributor of it not the fsf though? <bavier>df_: guix copyright is not assigned to the FSF <df_>I thought that was a requirement for gnu projects <random-nick>df_: when your project becomes GNU you have the option of FSF handling the copyright or you handling it yourself <ADFENO>(continuing my last message) ... Unless the proprietors/directors/owners of the project make a clear statement to defend users' essential freedoms. <df_>still, my point stands I think <df_>assuming the server serving www.gnu.org is owned by the fsf <random-nick>"For a program to be GNU software does not require transferring copyright to the FSF; that is a separate question. If you transfer the copyright to the FSF, the FSF will enforce the GPL for the program if someone violates it; if you keep the copyright, enforcement will be up to you." <cpjjl>but free software do not have owners, the copyright assignment is only a legal thing. IMHO authorship counts more, and based on authorship, GUIX would be more a World/France thing than a Boston thing. <df_>*shrug* if I were to define it at all I'd define it by the primary distributor <df_>but then I don't see much reason to want to define it <cpjjl>usually, free softwares are attached to animals, rather than countries :) <jlicht>Lol, someone in the #rust-internals seems to kind of like nix, but guix not so much <jlicht>How would you characterize the differences, at least in some kind of pro/con kind of way? <random-nick>well why would he hate it if he doesn't even know the differences? <janneke>I'd say: beauty is in the eye of the beholder ;-) <ADFENO>I once found someone in the GNU Social network that likes Nix over Guix because "Guix is not pure DSL"... Whatever this means... :S <janneke>I for one like Guix because I believe Greespun's 10th rule, and it's Guile and it's GNU <jlicht>janneke: that would always be a good answer :-) <janneke>jlicht: some people like things only because they are "different", others hate things because of that, etc. <jlicht>anyway, current situation is that rust will try to bootstrap itself by downloading a (compatible) rustc binary <davexunit>ADFENO: people that make that argument don't really understand Guix. <jlicht>the only way to prevent this download is by putting our own (bzipped) binary in that path, somewhere before running make. <davexunit>there's precendent for accepting blobs for compiler bootstrapping. <ADFENO>davexunit: Yeah... That was the first thing I though about that guy when he told me so. <jlicht>davexunit: sure. If the binary is only used for bootstrapping, would it make sense to even decompress it, or could I just as well have the 'rustc-stage0' package only be an archive that gets linked to the right place when building 'rust' <ADFENO>I don't have GuixSD installed here (I don't even have Guix here), but I plan to install it alongside my copy of Trisquel. <rain1>it woul be nice to at least have a complete list of packages that make use of bootstrap binaries <davexunit>jlicht: you would just drop the file wherever it needed to be. if the rust build system does the decompression, then you don't need to do it yourself. <jlicht>davexunit: cool. Is there anything special about packages that are only internally used? E.g., naming conventions, guile-isms that make the symbols private-yet-usable? <davexunit>jlicht: for this you would make an origin record that is an input to the rust package <jlicht>ACTION quickly opens up the guix manual again... <davexunit>(let ((bootstrap-binary (origin ...))) (package (name "rust") ...)) <davexunit>jlicht: in the both psuedo-code I'm using the let syntax so that bootstrap-binary is bound only within the form that creates the package object <jlicht>davexunit: the let binding makes sense. Why would I use an 'origin', instead of the admittedly larger 'package' form though? <davexunit>jlicht: you can't use a package here, because package derivations cannot access the network. <davexunit>you need what's called a "fixed output derivation" here, where the hash of the build is known in advance. such derivations may use the network. this is how all source files are downloaded. <pmal>hi all, sorry to interupt, but mayby someone could help and answer how to instal icedtea jdk, so i could use javac tool. guix package -i icedtea, install's only jre as i understand. <jmd>What's the easiest way to get a non-stripped package? <bavier>jmd: with gnu-build-system, put "#:strip-binaries #f" in arguments <jmd>bavier: I was afraid you might say that. <jmd>Na it's just that I had hoped there what a guix build --not-stripped option or something. <bavier>some packages define "debug" outputs <jmd>But those do something different I think. <rain1>i don't think so, it's entirely console/command line <rain1>but you can install desktop environment with ratpoison <sietedosfede>Oh I found various links at google, thanks for solve my prior question <jlicht>How do I modify the filename that a certain file is saved as, in the `origin` form? file-name does not seem to do the trick <rain1>sietedosfede: did someone get i3 working on guixsd, i have never seen that? <jlicht>actually, file-name does the trick, but some kind of hash is prepended to my filename <rain1>thank youiv'e added the link to my notes :) <sietedosfede>Sup? Here another question: Can you do 'make install' on Guix? Or it's intended to 'guixify' a store first? <rain1>you cant easily do make install no <rain1>one option is ./configure --prefix=`pwd`/out <rain1>then install it locally without being root <rain1>on create a guix package definition ***digitteknohippie is now known as Digit
<bavier>jlicht: file-name field of an origin dictates the suffix of the store item, not the entire name <bavier>do you really need a specific name though? <jlicht>bavier: no, not really, just mv'd it to the right name later on in the actual build process <hade>ACTION Hello! I'm installing GNU/Linux GuixSD now. I use an old computer with 40GB hard drive. It's possible to install with 38GB root and 2GB swap? <rain1>i think its possible hade but another option might be to use a swap file <hade>rain1: do you have a reccomendation about my partition? I use 40GB hard drive and 1GB RAM. <rain1>why not use 100% of the disk as one partition <rain1>and then create a 2G or so swap file inside it <keverets>a swap partition used to be (and may still be) faster than a swap file since it avoids the filesystem overhead <keverets>note that you could have a swap partition, and add a swap file as needed <keverets>dd if=/dev/zero of=/tempswap bs=1M count=1024; mkswap /tempswap; swapon /tempswap <keverets>could do it in /tmp as well if you're not using tmpfs (which would defeat the point) <hade>ACTION now I'm partitioning using cfdisk ***nckx is now known as nckx|offline
<hade>if `mkfs.ext4 -L my-root /dev/sda1` for root partition, what command for swap? <pmal>rain1, yes you can use i3wm on guixsd. I am using it, everything works. Just dont forget install dmenu and i3status packages ;) <sietedosfede>Another question: Is there a way to rebuild config with generation entries at boot like NixOS? <ajgrf>sietedosfede: yes, run something like `guix system reconfigure /etc/config.scm` <hade>ACTION I'm confuse what next step after using command `herd start cow-store /mnt <ajgrf>hade: next step is copying a sample config file to the system, customize if you want, and run the rest of the installer with `guix system init`. it's a bit confusing because the documentation for what to put in the config file is in another chapter of the manual <hade>ajgrf: yeah, I read the tutorial about setting configuration file, but Idk 'what file and where'. Do you can guide me step-by-step of installation? this is first time I install GuixSD. <hade>ACTION sorry if my english so bad. <ajgrf>cp /etc/configuration/desktop.scm /mnt/etc/config.scm <z0d>tw, I usually don't create a separate swap partition <ajgrf>then edit /mnt/etc/config.scm <z0d>but create a swapfile on the root FS <ajgrf>then run `guix system init /mnt/etc/config.scm /mnt` ***thedrums is now known as Guest47933
<ajgrf>you won't need to change very much of the config file if you don't want to, but make sure your filesystems section is right at a minimum. and you probably want to pick your username too <ajgrf>everything else can be changed later if you want, after you can boot the system ***Guest47933 is now known as kjylkrjt
<hade>ajgrf: ok, now processing 'accepted connection from.......' <adfeno>Just a quick question: Suppose I'm installing GuixSD alongside my Trisquel system, and I want to keep my current booltoader (GRUB from Trisquel) which command should I use to tell Guix to use the GRUB already installed? <rain1>i don't think there is any way <rain1>there is danger it wil overwrite your bootloader <adfeno>I mean, I want to be able to use the bootloder. (I'm not talking about the package). :D <ajgrf>adfeno: in the operating-system section of your system config, put (bootloader (grub-configuration (device #f))). you will get an error when you reconfigure but it's safe to ignore, i do this on my system <adfeno>So, when I finish installing GuixSD, I have to take my Trisquel live media, boot it, prepare a chroot envirnment to install the GRUB from the installed Trisquel on the disk? <ajgrf>in trisquel you'll need to manually add a grub entry for guixsd <adfeno>ajgrf: Question is: Is the trick with "#f" safe? Isn't there a risk of GuixSD installing it's GRUB bootloader even when using "#f"? <lfam>I'm working on updating OCaml to the latest version to fix CVE-2015-8869. <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, civodul says: re "fix-without-grafting", for now i would suggest moving fixes-without-grafts to core-updates, but it's really a build scheduling problem in the eend <lfam>I also have a graft to fix the Poppler CVE <lfam>The graft takes the upstream patch, so it should be ABI compatible (and it appears to be based on my limited tests). <lfam>The ocaml build phase 'prepare-socket-test' doesn't work with the latest version. The file it refers to '.../testsocket.ml' doesn't exist. <mark_weaver>lfam: oooh, what's the status of your poppler update? <lfam>I wrote it last night but I don't like to push "big" changes while I'm tired <lfam>I ask civodul about that and he said it's not necessary. I asked because I noticed his recent grafts don't do it <lfam>It should be in the #guix history from sometime in the last 24 hours <lfam>Can you look at the source of the patch and verify it's acceptable? I have to go AFK for ~1 hour but then I will be back.