<fogbugz>Another question. I use pip & virtualenv extensively. Some pip packages compile their own stuff. This goes a bit against Guix philosophy. Ideally, I'd write my own guix package definitions for python. There are many already. But for those that don't have any, what's the solution to keep pip packages reproducible? Running pip inside a guix environment so that pip packages link against precisely defined dependencies?
<paroneayea>fogbugz: yes, you can use "guix environment" as a universal virtualenv :)
<paroneayea>I've been doing that for my own python development
<paroneayea>use "guix import pypi <pkgname>" as a way to get started, make a guix.scm at the top of your project and add the packages you're working on in there, and when they're ready and work contribute upstream to Guix proper :)
<lfam>I'm interested to hear about problems with it, however
<lfam>It would be better to use an external token of some kind
<lfam>I'm skeptical about the possibility of keeping secrets long-term on the machine
<mekeor>i was thinking about something like the gnome-keyring-daemon
<lfam>There a million places for bugs, and I haven't looked at how gnome-keyring-daemon works, but I'm doubly skeptical of the idea of letting a DE keep secrets
<mekeor>true. i'd love to solve this issue just like you, but i'd like to make emacs (mu4e) ask me for my GPG-password and i wonder if that's possible
<enderby>hi i'm trying to upgrade with guix pull. it successfully completes, but then I do guix pull again, I get something very similar to something that was already posted here http://pastebin.com/b9UbRHLN and I get the same kind of message when I do a guix package -u
<lfam>I let gpg-agent spawn a pinentry dialog and I type the password there
<lfam>I wonder how emacs tries to handle data that is supposed to be secret?
<enderby>current version is 20170129.21, I keep having to relink back to the previous version
<mekeor>is that pinentry dialog is a window? i think i'd be fine with that, too
<lfam>enderby: Are you using GuixSD or Guix on another distro?
<thomasd>hi catonano_ . Is your Gnome running smoothly yet?
<thomasd>hi catonano_ . Is your Gnome running running smoothly yet?
<catonano_>thomasd: no. There' s a reply to my inquiry about fonts, I still have t read it. But there are crashes and bugs scattered all around in the Gnome desktop. I attempted to create a virtual machine to make a footage to demonstrate those and put it on youtube, but my laptop overheated and switched off :-/
<catonano_>thomasd: so now I' m mumblimg about my next move
<catonano_>I should probably buy a new computer, maybe a desktop, thsi time
<mekeor>personally, i can't run Gnome on GuixSD because i have one Intel graphics gard and one Nvidia graphics card which isn't well supported by Nouveau driver. but my tiling window manager doesn't use the Nvidia graphics card, so that works fine. also, i have to use `mpv -vo=x11` parameter for mpv, otherwise it overheats, too.
<catonano_>mekeor: I' m not that young, changing desktop envs is demanding to me. I was hoping I could have a decent Guix based Gnome gifted setup :-/ You' re right about the driver, though, I didn' t even checked what is my graphic card and what driver it is using
<catonano_>mekeor: as for the overheating, it didn' t happen while recording the footage, it happened while running "guix system vm-image conf.scm"
<thomasd>catonano_: sorry to hear that. Gnome doesn't work for me either on my personal laptop (graphics card issues).
<thomasd>xfce4. It's not super stylish, but I find it very usable (and fast!).
<catonano_>thomasd: admittedly, if I really have to move to another DE, I' d prefer xfce over one of those tiling things. It' d be less alien
<thomasd>on my work laptop, gnome works fine though. I'm surprised you have so many issues (2 GuixSD systems with similar config should be practically identical). Is it very old (or very new) hardware?
<catonano_>thomasd: the worst issue is that when attempting to move the icon of an application to the floating bar on the left, the whole DE crashes, it restarts and I have to log in again
<thomasd>xfce4 feels a lot like windows 95, so might be somewhat familiar ;-)
<thomasd>catonano_: in xfce4-settings-manager -> appearance -> Fonts, you can enable anti-aliasing, hinting, and play with "sub-pixel order". I had to do that to get proper-looking fonts in xfce4. In gnome, they always seemed to look ok, but I made the xfce4 settings before trying gnome, so ...
<clacke[m]>"Since May 2010, all patents related to bytecode hinting have expired worldwide. It it thus no longer necessary to disable the bytecode interpreter, and starting with FreeType version 2.4, it is enabled by default."
<mekeor>catonano_: i'd actually guess that you just have to install some fonts... just `guix package -s font | less` and look for `/name: font-`
<mekeor>i'm rather guessing that the font you are using is ugly because you didn't install any nice ones
<clacke[m]>whay one can glean from this is that fonts are code
<thomasd>catonano_: indeed, install some nice fonts, and maybe "fontconfig" as well (at least I had to run "fc-cache -Ef" to be able to use those fonts in emacs)
<thomasd>catonano_: if you log in again after the steps above, you should see the Adwaita icon cursors, and be able to drag icons. I (or you) should figure out the "proper" way to configure the cursors, and submit a patch.
<thomasd>catonano: maybe GuixSD should include a nicer font by default? Which one did you install?
<catonano>the cantarell one. It was suggested by Ludo a few months ago when I asked about Emacs
<catonano>thomasd: yes, I think a few font packages should be installed by default. We'll see
<roelj>You know what's cool? The disk I/O for the builds can be separated from the disk I/O for accessing programs by putting $TMPDIR on a different disk..! I wonder whether that was something the good people of Nix thought of when they created the daemon..
<roelj>Either way, it's very handy for a HPC deployment :)
<ng0>Okay, some time later today a patch release of cURL will come out.. do we need that? I'll be using it anyway, but I could also update cURL while I'm doing gnURL
<ng0>yesterday I was told we are likely not affected by the issue
<lfam>cehteh: I've never heard of a full SHA-1 collision before today. There have been collisions of "partial" SHA-1 computations.
<cehteh>http://public.pipapo.org/rstore pretty simple, but the way things are set up is not documente, i havent really makde it a public project, some friends use it and consider it GPL or WTFPL but i am to lazy to document it any further
<ZombieChicken>What rsnapshot does is sync the target dir to another location, then when you go to backup again, it hardlinks the files into a new dir, then removes the hardlinks and replaces them, if they need to be updated. It's a rather nice way to do incremental backups
<lfam>jmd: With deduplicating backup systems, the idea is that you rely on something else (like the filesystem) to protect the deduplicated chunks or files.
<ZombieChicken>that means you can easily copy everything over to restore the backup
<lfam>jmd: But if you do lose a deduplicated piece of data, it is of course really gone
<cehteh>jmd: it creates snapshot dirs hardlinked to the previous snapshot with only the differences not hardlinked
<jmd>It will be useless if the physical hardware fails.
<jmd>Yes, but it's not likely that both will fail at the same time.
<cehteh>i switched to online backups on raid6 years ago, because i can detect media/hardware failures much much earlier and easier
<lfam>And at least for users / consumers (that is, not enterprise businesses), all of the layperson-accessible backup systems deduplicate at the file or chunk level, and rely on the integrity of the backing store.
<cehteh>there is some risk that the server unrecoverably dies, yes, but benefits outweigth that
<cehteh>and usually even if the backup server fails, chances that the life data fail in the same time are small and would be my least worry then
<lfam>For example, using ZFS, or a block store like S3. Not to mention what is probably the world's most popular backup system, Apple's Time Machine, which doesn't do any integrity checking of the store, and just uses a journalling file system with hard link dedup.
<jmd>To me, there are two important things to a backup system: 1. If the building burns down, it'll allow me to get the system going again within 1 hour of taking deliveray of the replacement hardware. 2. If someone comes to me and says I give me a copy of file /x/y/z as it was 7 months ago, I can do that within 20 minutes.
<lfam>Look, I don't use Windows, but I won't deny that Microsoft ships _some) good, albeit sadly non-free, software.
<cehteh>we need to run a business software in a windows vm unfortunally .. i just snaphsot the whole vm image for backup, eats a shitload of space because that not deduplicated but i dont care about that crap and swallow that pill
<ZombieChicken>lfam: Maybe at the enterprise level. I've heard some reasonably good things from their server stuff
<ZombieChicken>cehteh: Honestly, zfs or btrfs w/ data deduplication /might/ help there
<lfam>I'm thinking about things like exploit mitigation at the low-level of the operating system. ASLR et cetera
<lfam>I really don't think it's a good idea for free operating systems to not engage with the development of btrfs. We are probably never going to include ZFS. If we don't have a competitive filesystem, users will stop using our operating systems in the long run.
<lfam>I'm not saying we should make it the default, but we should try to report bugs upstream and test if possible.
<ZombieChicken>lfam: ZFS will never integrate directly into the Linux kernel because of licensing issues
<cehteh>i'd put my bets into ZFS, i am rather not a fanboy and oracle should die a horrible death
<lfam>That's my point. We need to develop a replacement for it.
<cehteh>but what the zfs team does in sense of stability and sanity and deveopment is much much more sane than the btrfs progress
<ZombieChicken>lfam: The question is do you sink time and money into developing a project that is, after all this time, STILL not stable or look for a better option that isn't smelling like it's fundamentally flawed?
<cehteh>when you look at the kernel log whats fixed on btrfs it somewhat looks like they only patch up bug and design problems one after another instead making real progress
<lfam>Do you have any information about "fundamental flaws" in btrfs?
<ZombieChicken>Note I said "smelling like it's fundamentally flawed". It's been in dev for a long time now and still isn't stable
<lfam>ZombieChicken: Sure, if there is another filesystem we can support in GuixSD, let's add it.
<cehteh>sad thing that the ZFS license is incompatible with the GPL, but it is still free software, it could deserve some more praise from the gnu ppl as well imp
<ZombieChicken>lfam: I'm reasonably sure there is a zfs module for the kernel
<lfam>ZombieChicken: Yes, but we can't include it in GuixSD.
<lfam>Maybe that decision will change, but for now it's not an option.
<cehteh>btw, whenever i stresstested the nilfs2 it looked pretty solid, not feature complete yet and has performance issues but you can thow a running server out of the window and the files are still intact
<lfam>The only thing that I don't like is that it lacks the idea of "key capabilities" from Tarsnap, which borg / attic are pretty obviously inspired by.
<lfam>Well, it's pretty easy, and I recommend you read the documentation :)
<rekado_>I wonder: could we run something like “ldconfig -C $out/etc/ld.so.cache“ to build a cache of dynamic libraries and then augment the binaries (by changing the INTERP section) such that they run the dynamic linker with ‘--library-path’ pointing at the cache?
<lfam>There is a mitigation against clients destroying backups, which helps with the lack of key capabilities. But it would be ideal if clients could not even read backups
<rekado_>maybe we could speed up our applications this way, because libraries would no longer have to be looked up repeatedly in all directories in the runpath.
<lfam>rekado_: I'm not sure. Changing the subject, I think you should push your "gross fix" for the old-daemon problem. I helped another user work around it last night.
<lfam>I'm wondering is there is a "meta-bug" that leads users to not update their root user's packages for ~1 year.
<ZombieChicken>lfam: Documentation is no substitude for first-hand experience, especially when it comes to restoring backups
<lfam>Sure, but the documentation should be the first place a new user looks. If they find some missing info, that's a bug.
<lfam>And you are not restoring anything at the moment, right?
<rekado_>ZombieChicken: it’s easy to restore individual files with borg. You can mount the backup as a FUSE file system and browse through all your backups.
<lfam>You can also extract files without the neat FUSE mount
<ZombieChicken>lfam: Actually, I'm asking questions and reading the docs at the same time
<lfam>I guess I think it's a so-called "anti-pattern" to replicate upstream documentation is 3rd-party wikis and checklists. They are always full of mistakes and they divert energy from maintaining the upstream docs.
<rekado_>that’s a good hint. I’ll take a closer look at this later. Thanks!
<ZombieChicken>It would be really hacky, but maybe you could (ab)use LD_PRELOAD to do something similar and generate a shell script to run the program via "LD_PRELOAD='/foo/bar'; exec /gnu/store/baz; return $?", but that is, like I said, really hackyu
<felipebalbi>just tried installing guix on my laptop. grub installation failed :-s
<lfam>ZombieChicken: Can you help me improve it? I don't fully understand the problem that is being fixed, so I can't write a great commit message
<ZombieChicken>lfam: Well, is %bootstrap-guile being used because there isn't a built-in downloader, or is a downloader writtin in %boostrap-guile being used in leu of something else? I don't know exactly what is going on myself, but that is the only obvious question I have
<lfam>felipebalbi: Well, I don't know much about GRUB, but "Disklabel type" of the device I install GRUB to is 'dos', not 'gpt'.
<felipebalbi>lfam: just noticed that. Guix doesn't support EFI so grub needs MBR not GPT partitions
<lfam>nextos: Well, it sounds like you are building something for which substitutes are not available. You can try `guix system init --dry-run` to see what would happen in the absence of grafts, although there is at least one graft in the 0.12.0 release.
<lfam>Okay, I should credit rekado_ since it's his diff that I'm pushing while he is AFK (away-from-key)
<nextos>lfam: im using a tiny config.scm file when running guix system init, i think this is not due to any packages
<lfam>If you are seeing GUILEC, it sounds like you are building Guix itself.
<lfam>I don't recall if this is expected or not, but I don't think it indicates a problem. Do you?
<nextos>lfam: no no, its not a problem, it just takes very long in my very humble machine :)
<lfam>nextos: There's no harm in sending a question about this to <email@example.com>. Like I said, I don't remember if this is expected or not, and I don't have to time to look into it closely at the moment.
<katco>i need some hand holding. trying to package something, and i'm trying to discover licenses. the manual says i can use any of the values in (guix licenses), so i'm trying to understand how to enumerate those. in guile's repl i do ",m guix" and then type "licenses" and it gives me "$5 = #<directory (guix licenses) 3063480>" unsure what to do with that as i do not know guile
<lfam>katco: It definitely sounds like a plan :) I would propose it on <firstname.lastname@example.org> before spending a serious amount of time working on it, unless you just want to work on it to "get your feet wet" (which is a totally valid use of one's time, in my opinion).
<lfam>That sort of bootstrapping system is used for a few other compilers, so I think it's fine in principle, but we may want to nitpick exactly where the chain starts :)
<lfam>I assume you mean to write "sbt 0.7 would be sbt-bootstrap"
<katco>lfam: i know, that's why i was going to package the earliest 0.7 i could find. i haven't poked around too much to discover how that was built