IRC channel logs

2015-11-30.log

back to list of logs

<loz>hi guys
<loz>how is guix different from nix?
<fps>loz: scheme, all the way..
<fps>loz: i think a good start would be to watch one of ludovic's talks
<fps> https://www.youtube.com/watch?v=VZD_DOXoIVM
<fps>FOSDEM 2014 - Growing A Gnu With Guix
<fps>or
<fps> https://www.youtube.com/watch?v=AzebnJkfdvM
<fps>2015 01 GNU Guix The Emacs of Distros
<loz>fps: scheme is good
<loz>nix seems to be more popular
<loz>but I'll check out the videos
<loz>fps: can I install custom kernel in GuixSD?
<rekado>loz: yes. But there are no custom kernel packages in Guix. I suggest creating a package variant based on the linux-libre package.
<loz>rekado: I see, thanks
<loz>so
<loz>it's time to replace kernel with lisp one to have lisp OS back
<rekado>you could use the Hurd and write your translators and other servers in Scheme ;)
<efraim>found my circular dependency: new versions of python-mock need python-pbr-0.11, which needs python-pip, which needs python-mock for tests
<efraim>don't think I'll tackle that one for a while
<efraim>python-swiftclient built successfully! almost there on git-annex-remote-hubic
<b4283>thanks for helping out, but it was late last night and i have gone re-init the whole thing again <civodul> [02:21:04] b4283: what does "e2label /dev/your-root-partition-device" return?
<b4283>i have set -L MAIN for mkfs.ext4, so i must have set it wrong in the config.scm
<b4283>it was pretty surprising to see a guile shell when boot failed though :P
<b4283>i tried to reinstall linux-libre, which is the usual way to fix it on ordinary distros after correcting config issues
<b4283>but it didn't work, i figured guix is something else
<iyzsong>b4283: how do you 'reinstall' linux-libre? with the new config.scm, if GuixSD is installed, you can do a 'system reconfigure', otherwise I think you can only do 'system init'.
<b4283>iyzsong: i rebooted back into the guix usb drive, and run guix package -i linux-libre from there
<b4283>but i have no idea where did the package go in the end
<b4283>probably some place in the memory
<rekado>b4283: after changing config.scm it should be sufficient to do "guix pull && guix system reconfigure /etc/config.scm"
<b4283>on archlinux, it would require me to chroot back into the broken system, so i'll be running the "right" pacman
<b4283>rekado: great to know, thanks
<rekado>you have to make sure that your store (on disk) is mounted and used.
<rekado>if you haven't managed to install GuixSD due to a configuration problem I'd suggest just to do "guix system init" as explained in the documentation.
<roelj>Does the GuixSD installation install packages in alphabetical order?
<roelj>I'm trying to get some indication of how far it is in the installation process :)
<rekado>roelj: I don't think it does.
<rekado>You could always abort it and restart to see much is left.
<roelj>rekado: Ok. Would it be hard to calculate a rough percentage of completion? (I'd be willing to try to write it, and a nice progress bar when installing..)
<roelj>I imagine just looking at how many packages have been processed can be far off.
<rekado>I don't know. I haven't thought about this much.
<roelj>Ok
<h0wl3vvd>hey
<h0wl3vvd>what mean that guix is "transiatonal" package manager ?
<rekado>h0wl3vvd: where did you read that?
<h0wl3vvd>"transactional"
<h0wl3vvd>on official website
<h0wl3vvd>Dependable. The GNU Guix package manager, in addition to standard package management features, supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and more.
<h0wl3vvd>what mean that transactional ?
<rekado>oh, this means that upgrades and roll-backs can be aborted in between without leaving the system in an inconsistent state.
<rekado>(as in a database transaction)
<h0wl3vvd>what is roll-back
<h0wl3vvd>?
<rekado>you can roll back the system state to a previous version.
<h0wl3vvd>mhm
<h0wl3vvd>oh okay
<davexunit>finally able to get on freenode
<piyo>oh yeah
<piyo>i mean, some days before I go onto my local freenode and #guix was empty...
<davexunit>ddos
<piyo>all them people "guix pull"-ing
<davexunit>'guix pull' is actually an irc botnet client
<rekado>just realised that CRAN has a copy of all DESCRIPTION files, so there never was a need to parse HTML...
<rekado>oh well.
<piyo>comprehensive ruby accessory network never fails
<davexunit>rekado: live and learn
<rekado>I'm happy that I can now do what I love most: deleting code.
<davexunit>always a good feeling
<davexunit>such a good feeling that I delete random guix code sometimes and hope no one notices
<rekado>you too...?
<davexunit>;)
<rekado>for the bioconductor importer I'd need to use basic HTTP authentication to access the readonly SVN browser.
<rekado>hope this is supported by Guile out of the box
<rekado>our cran updater doesn't quite work because package names in R are not always lowercase.
<rekado>we currently get the name from the Guix package name, which is always lowercase.
<rekado>I'll try to update it by cutting out the name from the source URL.
<davexunit>rekado: I haven't seen anything in guile's web modules about basic auth
<avoine>one of you have a complex example of a config.scm? Like customising some services in %desktop-services?
<fps>avoine: i have an example customizing guix-service
<davexunit>avoine: not complex, but here's an example with service modification http://pamrel.lu/ba1e3/
<fps>also there's an example in the system configuration section of the manual
<avoine>ah! (modify-services %desktop-services is what I'm looking for
<fps>i guess we should make that service modification snippet its own section, so it's referenced in the manual
<fps>will send a patch
<rekado>fps: we don't need a separate section. You can just add words and phrases to the index.
***mood_ is now known as mood
<jroh>how do the VMs with guix work? are they using qemu underneath? or something else
<davexunit>jroh: qemu
<jroh>awesome.
<fps>rekado: ok
<jroh>interesting, so docker runs under guixsd, I wonder how far that can be pushed
<davexunit>should work like it does on any other distro
<davexunit>though guix has its own container implementation :)
<davexunit>'guix system container' and 'guix environment --container'
<davexunit>more stuff to come
<rgrau>does guix system container work already?
<davexunit>yes, with limitations
<davexunit>no networking yet
<davexunit>but you can still do networking stuff via sharing UNIX domain sockets from the host
<rgrau>I'd like to try guix system container to see if works for my day to day usage
<davexunit>rgrau: 'guix environment --container' is worth a look as well
<davexunit>both tools are brand new, so I'd love to see more people try them out and report successes and failures.
<davexunit>people have already uncovered a few bugs
<jroh>nice! i have two sort of goals there. I'm already doing a lot with docker, and I'm looking for a way to hack around some apps that don't like being in guix till I get more familiar
<davexunit>that sounds good
<davexunit>I've poked around with Docker at once, and I think (fear) that we'll be using it for everything soon enough.
<davexunit>s/at once/at work/
<amz3>I did install guix using the binary installer
<amz3>I'd like to setup git guix
<amz3>configure complain about missing guile but I installed guile
<efraim>do you also have guile-json?
<amz3>guix package --search-paths doesn't report PKG_CONFIG_PATH
<amz3>efraim: no
<amz3>I did `guix package -i guix guile-next'
<davexunit>amz3: you need pkg-config for that
<davexunit>also, this is the hard way to build guix
<amz3>why?
<davexunit>because we have 'guix environment' to make this easy
<davexunit>'guix environment guix'
<davexunit>that spawns a shell with all of the dependencies needed to build guix
<amz3>thx davexunit
<lfam>And that way, you keep your dependencies under control of Guix instead of just grabbing whatever is in the environment.
<efraim>any idea what this license is? https://www.red-dove.com/python_logging.html#license
<lfam>efraim: Try comparing it with the variants of the "MIT" license on this page: https://fedoraproject.org/wiki/Licensing:MIT
<efraim>lfam: thanks, will do. sometimes I have no idea looking at the license
<rekado>I get an error on "guix system reconfigure" which seems unrelated to my configuration.
<rekado>it's on a machine that hadn't been updated in a while.
<rekado>the error is in dmd-boot-gexp --> dmd-configuration-file --> concatenate: Wrong type argument ... (expecting empty list): #f
<davexunit>rekado: that's an ABI breakage thing
<davexunit>rm gnu/services/*.go && make
<rekado>ah, thanks.
<davexunit>ACTION wants to make a small GuixSD powered ARM computer with this screen http://www.thing-printer.com/product/manga-screen/
<jroh>are there particular maintainers for packages. it seems like weechat has a bad path for cacerts
<davexunit>no particular maintainers
<davexunit>file a bug report or send a patch :)
<fps>ooh, thanks for reminding me. that was a nice touch nixos had over guixsd - attribution to package creators/maintainers
<fps>with free software, attribution is often one main motivation to get people involved.. if the package definition had a author/maintainer field for the package definition itself. that might be an incentive not to be underestimated
<fps>besides giving a clue who is a good person to talk to about an issue with a particular package definition
<davexunit>'git blame' works enough for us
<rekado>a maintainer field would probably become outdated quickly.
<fps>yeah, and that's totally missing the point i tried to make. but that's cool.. i wanted to go to sleep anyways..
<rekado>git blame is the better tool.
<davexunit>there actually *is* a maintainer field in the <package> type
<davexunit>but we don't use it
<rekado>oh.
<rekado>heh.
<davexunit>I imagine it was around since the beginning
<jroh>i don't know if i have an opinion on it, but I think fps was making the point that people like the attribution karma of being a part of a project
<codemac>I think the maintainer fields are useful for things that have complicated, not yet automated package testing
<codemac>I was thinking last night about how it would be good for us to write some amount of qualification tests so we know when things are really working as opposed to building + #:tests? #t
<codemac>Also I wish we kept around as many versions of a package as necessary, it seems like the real win of guix is possibly having recipes for just about any version of anything, (whereas what the main guix substitute builds is a matter of what guixsd packages)
<codemac>also I want a unicorn
<davexunit>we keep around multiple versions when necessary
<davexunit>keeping every version is not practical.
<codemac>it's not practical for our hydra instance / builders etc, but I think it would be useful
<davexunit>there's no feasible way for it to work
<davexunit>think about what you'd have to do
<davexunit>if you wanted to keep an old version of emacs, let's say, you'd need to create new package variables for each dependency, recursively
<codemac>Yup! I did say unicorns no? :)
<davexunit>you can have what you want by locking to specific versions of guix
<davexunit>because the inner workings of the build systems and things affect package builds, too
<davexunit>so it wouldn't be sufficient to just keep around old package recipes
<codemac>You don't need to tell me that it would be difficult, I know that. But the "rolling release" attitude plus the "functionally resolved dependencies" makes this a battle I think guix will end up fighting anyways.
<davexunit>I don't think so.
<davexunit>we already know how to do stable/rolling versions
<davexunit>we just don't maintain anything besides the bleeding edge master branch because we're in alpha
<codemac>It's ok to disagree with me, I kind of expect it. I just think downgrades could be made very nice, I deal with them a lot at work and it's a huge pain point.
<davexunit>downgrades are roll-backs
<davexunit>we already keep all of the generations
<rekado>and you can usually install an older version by checking out an older version of Guix.
<davexunit>yes, exactly.
<davexunit>the packages cannot exist outside of the precise version of guix that was used to build them originally
<codemac>the downgrades I was referring to aren't the same as rollbacks as the machines I allocate are dynamic, not static. It's fine though, maybe there is a workflow that makes sense that I just haven't thought out other ways yet.
***HeisenbergsDog is now known as Guest65519
***Guest65519 is now known as HeisenbergsDog
***HeisenbergsDog is now known as Guest94175
***Guest94175 is now known as HeisenbergsDog
***HeisenbergsDog is now known as Guest62916
***trisquel_ is now known as HeisenbergsDog
<jroh>do the package definitions get downloaded somewhere by default? or maybe more generally what's the workflow if I want to rebuild a particular package locally, and possibly customize it?
<apa512>does anyone know how to get sound working in icecat? specifically youtube.