<alezost>edangor: there is no special extension for a guix package, it's a usual scheme (guile) file with package definition(s)
<alezost>edangor: I meant .scm as brendyn says, but it's not a special-purpose extension
<brendyn>edangor: The actual compiled 'package' is just a directory containing all the relevant files in /gnu/store/...../ I think. I suppose you could make that into a tar.xz file and call it a guix package?
<cehteh>now he uses zfs and is much more happy, if only the licensing issues with zfs wont be
<cehteh>no idea, whenever i tried/stresstested it i ran into trouble too
<cehteh>feature wise i would be very happy if btrfs would be stable and deliver what it promises
<cehteh>but from my experience it is far from there yet
<brendyn>Well I've got some ext4 backup drives and btrfs backup drives. I kinda just pillage any drive I can find and put backups on it
<cehteh>some people even say its fundamentally broken .. and when i look about the doctoring they do on it in the past years instead making real progress i start to believe that. and i am really sad about that
<cehteh>well wanrnings saied, for some light usecases it seems to work, but its nothing you would trust valuable data to
<cehteh>and the raid5/6 code is broken beyond repair, some time ago they announced that it should not be used and will be completely rewritten
<brendyn>I never expect to trust any in the first place
<cehteh>while a filesystem based dedup could do that block or extent based and using cow
<cehteh>but the savings from that wont be dramatic
<cehteh>civodul: btw: with the services stuff, guix creates the config for deamons and so on from guile expressions .. i feel this has a steep learning curve and each and every service created needs a lot works to get this going.
<brendyn>hmm ok well I guess I'll just keep ext4 for now and switch over to GuixSD one day
<cehteh>i would like to have some way to specify a configfile at some user defined position (/root/my-system-config...) and let system reconfigure copy/install that into place. that would be straightforward and still functionally sound or?
<civodul>cehteh: there's indeed quite a bit of learning here, but how much harder is it compared to creating a system service in, say, a .deb?
<cehteh>(well i would like lua more, but really thats not the point here)
<cehteh>just the way things are done should be simple and consistent
<jmd>There is indeed a lot to learn. But I think that guix is easier to learn and in general is self consistent. Of course the hardest part is letting go of pre-conceived notions.
<cehteh>currently one needs to know a lot scheme to configure some details, this should eventually be wraped up to make things simpler
<jmd>I agree that things should be better documented and with more examples.
<cehteh>yes, but argueing this way doesnt improve guix, even if it *is* a lot easier to learn and package stuff, the goal should be to make it much easier further
<brendyn>Essintially, Currently, many packages only link to source tarballs, but I think this is missing out on a big opporutinity. If instead of just the tarball, the version control repo was provided with the revision corresponding to the tarball (assuming upstream is kinda enough to do that, then I'd like to implement in no-nonsense feature in guix to download the repo, copy out the guix package definition to a .scm
<brendyn>file changing it to set the repo as the package source, set GUIX_PACKAGE_PATH etc...
<brendyn>The goal would be facilitate taking any program in Guix and immediately start hacking on it without pain ant struggle
<brendyn>For example, we could start by doing it for all GNU packages since gnu.org follows a consistant format
<cehteh>brendyn: fetching sources from git tags etc? .. would be nice
<jmd>brendyn: That would be a useful feature to have, but I don't think it should be the default way that packages are built.
<cehteh>you have to clone it and remove the .git to make the source tree verbatim
<brendyn>cehteh: What I think is ideal is a sort of source agnostic source specification... if you get what I mean. The hash is the true source identifier, and the rest are just methods of getting it, ftp, http, gnunet-fs, git, ...
<davexunit>guix graph --type=package librecad | dot -T pdf > librecad.pdf
<davexunit>the graph is quite big but you can zoom around and read it
<davexunit>you will quickly see that the graph is pretty much entirely Qt.
<davexunit>some effort has been taken to break up the monolithic qt package into many smaller ones
<davexunit>so perhaps the librecad needs tweaking to use those instead
<davexunit>that will hopefully eliminate a lot of nodes from the graph
<cehteh>just forget about it, i just installed librecad because i wanted to test the new installation and how it works woth a slightly more complex package, i dont even have any use of librecad in that vm
<cehteh>either way .. i have guix running fine now, one 'farm' vm for building and some experimental vm's, only waiting for the full disc encryption finished to deploy it on real hardware
<lfam>My preference is to apply the patch, even if the bug doesn't manifest for our expat package. I don't think it's unreasonable that somebody would use Guix as a tool for getting free source code that they build in some other way.
<habs>lfam: Hm, I think I can get around it, thanks. One more question, if a package wants the gtk+-2 dev files but guix uses gtk+-3, how can I install gtk+-2 separately without downgrading gtk+-3 using the @ syntax?
<lfam>habs: I don't really understand how GTK software works. But typically an application built with Guix will link against a specific build of its dependencies in /gnu/store.
<lfam>So, one application would link against a build of gtk+-2 and another against gtk+-3, as needed by each application
<lfam>I don't believe it's usually necessary to install GTK in your profile with `guix package --install gtk`
<habs>lfam: Actually I wasn't being too clear, what I meant was if I was trying to build a binary (in this case a claws-mail plugin .so file) from source code, and it depends on the gtk+-2 libraries
<habs>I was able to get around that in the mean time by downgrading my gtk+ package to gtk+-2 though, thanks for your very helpful answers!
<OrangeShark>habs: you can use a guix environment to just put gtk+-2 in your environment
<OrangeShark>it useful for building software from source without having to install it in your profile