<fogbugz>Hello, im playing around with guixsd and i was wondering if you typically define packages available for your own user (not system-wide) somewhere (as a matter of convention) <paroneayea>fogbugz / fogbugz2: I don't think there's a specific convention of where to do it for user-defined packages that I know of <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 :) <paroneayea>fogbugz: if you need help, give me a ping, maybe I can look if I'm not too busy <mekeor>is there anybody using mu4e + isync/mbsync + msmtp in here? do you use a keyring in order to not need to save your passwords in plain-text? <sneek>mekeor, thomassgn says: thanks for input on the package I was trying to define (fpm2) <lfam>mekeor: I use mutt + mbsync + msmtp <lfam>Do you mean the SMTP password? <lfam>or IMAP, that sort of thing <mekeor>lfam: where do you keep your password? <lfam>.mbsyncrc and .msmtprc have the configuration fields 'PassCmd' and 'passwordeval', respectively <lfam>They take a shell command line. I use something like `gpg -d path/to/encrypted-password` <mekeor>yes. so what command do you use therefor? <mekeor>okay. so your password is encrypted but the encryption doesn't have a password? <lfam>No, I have to enter a password for gpg <mekeor>so it's not in plain-text but if someone could execute gpg on your computer, they could read your password, right? <lfam>Yeah, but they could do a lot of things in that case <lfam>They could install a keylogger, for example <mekeor>well, if you have a password for this, it doesn't matter anyway, i guess, no? <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? <lfam>mekeor: It's up to you, depending on which pinentry package is in your profile. There are pinentries for some of the graphical toolkits, and also ones for text environments <lfam>enderby: Basically, you'll change root's version of Guix to an older revision, update root's installed Guix package (which contains the guix-daemon), and then restart with the new guix-daemon. <lfam>Afterwards, you should update root's installed copy of Guix to the latest, with `guix pull && guix package -u guix` <kevinfish>how do you find out what package a file/program is in? E.g. the equivalent of equery belongs <filename> in gentoo? <katco>kevinfish: if i'm not mistaken you should just be able to see where the symbolic link points <kevinfish>no, I'm trying to find a package to install that has a certain program in it <katco>kevinfish: ah i see. sorry, don't know how to do that <katco>kevinfish: what's the program? maybe i know it <katco>kevinfish: ah, you're truly after "how do i fish" <kevinfish>but I want to be taught to fish, not given a fish <Apteryx>It's preventing me to run build or lint for example, using emacs-guix. <Apteryx>SSL_CERT_DIR=/etc/ssl/certs, SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt <roelj_>Hi! Reporting from GuixSD with EFI and btrfs root partition. ***snape` is now known as snape
<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 ;-) <catonano_>thomasd: I' d love if you would try and let me know if you can reproduce that <thomasd>lol, I totally just reproduced that :-D <catonano_>thomasd: ah, the computers of my beginnigs were Apple Macintoshes :-/ <thomasd>I wasn't even aware that was (supposed to be) possible. <thomasd>What does work, is right-clicking and "add to favorites" <thomasd>it didn't crash immediately though. first attempt, the screen just went black for a second, and the deskto reappeared. the second or third attempt, gnome crashed. <catonano_>thomasd: with me it crashes as soon as I start to drag the icon <catonano_>It could sound bad, but I'm glad it has been reproduced :-) <thomasd>ah you're welcome ;) seems likely to be a general gnome issue, though? <thomasd>what's the font issue you're having? is there a bugreport? <catonano_>thomasd: yes, I suspect it has to do with the ibus functionality. But I don' t know the first thing about how Gnome is broke up in pieces and how those pieces relate with one another <catonano_>thomasd: no, there' s no bug report. The issue that I'm having is that the fonts are ugly. I' m sorry I can' t say better than this :-/ <catonano_>thomasd: I'm on Fedora now and they are way more pleasant <thomasd>ah, I had the same initially, but then I enabled "hinting" somewhere and it became much better. <thomasd>something to do with showing fonts on raster displays ;) <thomasd>I remember I did it on xfce4, not sure if I did it in gnome (or if the xfce4 setting configures a user-wide property) <catonano_>thomasd: thank god for diversity in DEs ! ;-) <clacke[m]>At least a place to pick up terms for further searching :-) <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>(actually just "fc-cache -f" should be enough, the E is some error reporting flag) <catonano_>Now, I feel like I deserve a coffee in my ususal cute tiny cafe. Read you soon people ! <thomasd>keep talking about that cafe and make us non-italians jealous, will you? <thomasd>catonano_: I've fixed the issue with Gnome crashing when dragging icons on my system, probably it will work for you as well. <thomasd>somehow, the Adwaita cursor theme is not used in Guix' Gnome desktop (I had noticed earlier on that I was somehow using default X cursors). One way to enable it, is the following: <thomasd>2) "ln -s /run/current-system/profile/share/icons/Adwaita/cursors/ ~/.icons/default/cursors" <ng0>Hi, would anyone know if Lenovo X220 series hard drive caddy covers (the plastic part which covers the insert slot of the hdd place) are compatible with X200 ones? <ng0>*compatible/usable for the X200 <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. <ng0>on the picture it looks as if it would fit <rekado_>I can’t build latest guix. “make” aborts with “waitpid -1 failed unexpectedly: No child process” <ng0>okay, I looked at the FRU documentation, it fits :) <snape>I don't understand when ./pre-inst-env needs to be executed, for it seems that my modifications are taken into account even with a single "guix something" <snape>I mean, I never run ./pre-inst-env, and I don't understand when I should need it <snape>I also never run "make install" <snape>if, say, I modify package hello and run "guix package -i hello", it will install the newly modified version of hello <snape>I don't have to run "./pre-inst-env guix package -i hello" <snape>therefore I don't understand the point of ./pre-inst-env <snape>It might be related to the fact that "guix" is in my package list <iyzsong>well, ~/.config/guix/latest is added to the search path of guile, i think you must had put the git checkout of guix there. <ng0>yep.. if you modify in the same checkout you run from and you have symlinked it, than you don't need pre-.inst-env <snape>got it. So pre-inst-env is needed when I'm not symlinked to the checkout <jmd>Are we currently evaluating core-updates or what? <snape>iyzsong: by search path of guile, you mean GUILE_LOAD_PATH? <iyzsong>snape: yes, see the 'scripts/guix' file, it's pushed into %load-path and %load-compiled-path directly. the environment variable GUILE_LOAD_PATH works too. <ng0>looking at the current TAILS version GNOME environment, our GNOME is still missing some things (or they use a different one..) <catonano>thomasd: fonts are way better now. It was just a matter of iinstalling them and setting them with the gnome-tweak-tool <catonano>ng0: what do you see missing in the Guix Gnome ? <ng0>I',m currently not looking at the Guix gnome.. so I can't compare easily. <catonano>ng0: I though you meant the Guix gnome with "our GNOME" ;-)) <ng0>i think that's a different GNOME integration they use <ng0>the upper task bar is different <ng0>Gnome 3.14.1, that'S why <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 <ng0>Should we collect the file collisions somewhere? I haven't had any error because of them, but it would be nice to make them disappear one day <ZombieChicken>Anyone know how important /gnu/store/.links/ is? My backup software doesn't seem to like it in the least and keeps hanging on it <janneke>ZombieChicken: i have no clue, but do have about 1M of them <janneke>so maybe that's why it takes a while to backup .links/ <ZombieChicken>This isn't a case of "takes a while", it's a case of "completely hangs and does nothing else" <ZombieChicken>Which is weird, because it seemed to work fine going over the same dir before during the initial backup <cehteh>ZombieChicken: how do you back up? <cehteh>not the first one, but now its becoming practical with enough efforts <cehteh>ZombieChicken: i use rsync, dont forget the -H flag to track hardlinks, dunno about rsnapshot <lfam>cehteh: Was there really a previous collision of two files? <ZombieChicken>lfam: Isn't that why sha1 is pretty much not used? Same for md5 <jmd>I back up by selecting reverse and looking over my shoulder. <cehteh>sha1 is still way too much in use <ZombieChicken>cehteh: Good point. rsnapshot is based on rsync, so that might be it <lfam>ZombieChicken: That directory is full of hard links, so you will want to make sure rsync is handling them properly <lfam>cehteh: Can you point to news about the previous collision? <lfam>ZombieChicken: Its days have been numbered for many years now <cehteh>ZombieChicken: i have my 'own' backup system doing snapshots, called 'rstore' .. running flawless since many many years <lfam>cehteh: Guix uses SHA-256 <jmd>cehteh: But how do you store those snapshots? <cehteh>lfam: dunno .. have to search, or where the previous ones just theoretical or at least didnt produce any valid files <cehteh>aka you can found some gibberish to a pdf with the same sha1 but it wont be a valid pdf <ZombieChicken>Hrm. I wonder if the problem is that, since rsnapshot is using hardlinks a lot if that is causing the problem <jmd>How is that a "backup" system then? <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. <cehteh>tapes can fail, tape drives fail etc <lfam>jmd: The storage costs are reduced so much that one can afford to create several distinct backup repositories. <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. <cehteh>(aka, that prolly means our home burnt down, i give a shit about the backups then) <jmd>If you're storeing on a backup server I don't see how you can hardlink to it. Hardlinks can't go across filesystems. <lfam>Time Machine alone is infinitely better than nothing <cehteh>jmd: the backup server hardlinks between snapshots <lfam>Most layperson users don't back up at all, because the tools are inaccessible. <cehteh>of course not to the live data, and the servers have no access to the backup server, backups are pulled <ZombieChicken>lfam: Or crap. To this day I don't know of a single decent piece of backup software for Windows <lfam>Apparently Windows includes a backup system now. I wonder how it works. <lfam>Well, who knows? It might have something useful :) <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 <cehteh>zfs, maybe i migrate to it, but for backups i still like to rely on a portable software level hardlinking than filesystem support <cehteh>bfrfs is not stable, it got better but i still manage to crash it horribly <lfam>cehteh: What feature was unstable? <cehteh>enomem, getting slower, loosing data <lfam>*Please* report it upstream <ZombieChicken>Only other option I could think of is taring the image, diffing it with the last known image, and storing either the latest image + the diff to the last version, or the other way around <lfam>ZombieChicken: You could use borg to dedup the VMs <cehteh>i havent tried recently, maybe i try someday again <lfam>cehteh: btrfs is *the* choice for a new filesystem for free distributions. We need to try to help improve it <lfam>Nothing else is in the pipeline <ZombieChicken>I get the feeling btrfs is practically forever-alpha software at this point. <lfam>ZombieChicken: Did you know that OpenSUSE uses it as the default FS for the root partition of their operating system? <cehteh>i disagree, they packed an advertized too much features and nothing is solid right now, is the raid stuff fixed meanwhile? <ZombieChicken>lfam: You mean like how systemD is *the* choice for a new init for free distrubutions? <cehteh>and btrfs also doesnt support crypto yet <lfam>I'm not talking about systemd. I mentioned OpenSUSE because they are using it for a large number of *paying* customers. <ZombieChicken>lfam: Yes, I'm aware of that. Does btrfs still have the "may destroy data and rape puppies" line in their wiki? <ZombieChicken>I'm also curious how much they patched it to work in their kernel <cehteh>dunno, but in practice it may do that <cehteh>not regulary, only under rare conditions <cehteh>but still nothing i would trust my data to <cehteh>and with the broken raid system and no crypto almost all its advantages are void <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. <lfam>That message was in reply to ZombieChicken. <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 <cehteh>nilfs has some snapshotting too, maybe you can look into that if interested <ZombieChicken>reasonably sure nilfs is designed for a different workload than ext4, zfs, and btrfs <lfam>Sure, btrfs has been in development for about ~10 years. That's not abnormally long for a filesystem. <ZombieChicken>It's certainly interesting. If you're on a system that can run entirely out of RAM I'd use it in a heartbeat <cehteh>but any filesystem has most and foremost if not only to ensure that files stay there and dont vanish mysteriously <jmd>Whatever happened to reiserfs ? <lfam>Anyways, my points are 1) btrfs is not 100% done yet but, 2) it's getting there and it's a good option for free distributions in the future. <jmd>ZombieChicken: Yeah I heard about that. Unfortunate, but shouldn't kill the project. <cehteh>yes but i really dont like that some distros offer it as standard filesystem, its not there yet, definitely not <lfam>And 3) I don't think we should trash free software projects just because they aren't done yet. Rude people could find a lot of problems with Guix, too. <lfam>cehteh: Did you consider that maybe OpenSUSE has more experience and knowledge on that subject than you? <ZombieChicken>lfam: Guix hasn't been in development for 10 years and had financial backing from Fortune 500's and still isn't production ready <cehteh>the feature list if btrfs is nice, it it would be rock stable i would like to use it <cehteh>lfam: crashed on me crashed on friends .. thats all i can tell <cehteh>i give a shit about opensuse when things dont work for me <lfam>And it works for me on my systems. Our datasets are too small to compare to theirs <cehteh>a friend tried it on a backups server <lfam>ZombieChicken: It does support certain RAID levels, but not RAID-5/6 <cehteh>rsync just pretended data isnt there, copied all over again .. eventually completed, and nohing was there again <ZombieChicken>lfam: Which I'll bet it the most used RAID levels for desktop systems and probably most servers <lfam>I don't have any knowledge about that. No "bet" <ZombieChicken>tbh, nilfs would likely work really well for a backup system <cehteh>the ENOMEM and out of metadata space things are also still a problem, i see how many people have problems with btrfs on their jolla phones <ZombieChicken>lfam: I think we can at least agree it's the best bang for the buck hardware-wise unless you're needing raw speed <cehteh>but i admit they dont use the most bleeding edge kernel and i dont know if btrfs is patched there <lfam>The phone kernel situation is a disaster in general. You shouldn't ever use old kernels on machines that face the internet <lfam>Well, I also copy files such as keys onto offline storage by hand. Without some of those keys, I could not restore from the backup in case of total disk failure <lfam>I like it fine. The model is good, the development is active and serious about finding and fixing bugs. <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. <rekado_>I can’t do it right now (laptop is currently unusable and I have no keys on my workstation to sign the commit) <lfam>Sure, I'll push it on your behalf, and then you can reply to the thread later saying "okay" <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. <lfam>It's basically `borg extract host:repo::archive path/of/file` <ZombieChicken>Sometimes information is specific to a distro, which makes sense to put in a wiki <ZombieChicken>What is the on-disk layout look like? Could I easily find the file with, say, mc? <lfam>You might ask these questions in #borgbackup <lfam>But, no, the files are stored in deduplicated chunks <lfam>If you want to view the repo as a filesystem, you'll need to use the FUSE feature ***mildred4 is now known as mildred
<lfam>Au contraire, it saves a ton of disk space <lfam>As discussed previously, rsnapshot serves that use case well <rekado_>answering my own question: it wouldn’t work because the DT_RUNPATH section is consulted before the ldconfig cache file. <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 <ZombieChicken>I think you aren't passing the right drive somewhere in the config, if memory serves me anyways <felipebalbi>/dev/sda, the only drive I have :-) Or should I be passing the actual partition? I think not as grub install to MBR <felipebalbi>(bootloader (grub-configuration (device "/dev/sda"))) <ZombieChicken>felipebalbi: I'd double check and make sure the LiveUSB isn't showing up as /dev/sda <felipebalbi>ZombieChicken: /dev/sda1 is 110G which matches my partition size <ZombieChicken>I know I've seen that error before, and I'm reasonably sure it's usually just a case of a missed command somewhere or some other trivial problem <felipebalbi>ZombieChicken: is there a way of evaluating just (bootloader (grub-configuration (device "/dev/sda"))) ? <felipebalbi>without having to resort to a full guix system init ? <felipebalbi>ZombieChicken: guix eval "(bootloader....") would've been cool ;-) <felipebalbi>ZombieChicken: maybe I'll propose a patch once I get this installed :-p <lfam>felipebalbi: Please put the output of `fdisk -l` on <paste.lisp.org> <ZombieChicken>I'm currently trying to find a GuixSD-friendly backup program so I can backup my current system then reinstall with GuixSD <ZombieChicken>then figure out how to emulate my current setup (which I like) in a way guix won't choke on <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>Unfortunately I don't understand the nature of the bug well enough to clarify it. <lfam>Of course I intend to add a Co-authored-by line <wingo>yeah sorry, somehow I missed those mails <lfam>Howdy. rekado_ and I would like to push this commit until we have something better. <lfam>But we request your opinion on both the commit and the commit message :) <wingo>lfam: it looks good but can the fix be isolated to the url-fetch/reset-patch-level function? <nextos>Hi im trying a new guixsd installation. How do I avoid getting nix built after running guix system init? Authorizing hydra.gnu.org doesn't seem to do the trick. <lfam>wingo: That would be better, I agree. <lfam>I looked at your attempt, but I'm not sure how to improve on your attempt at that <lfam>nextos: Specifically what do you mean by "getting nix built"? By the way, substitutes from hydra.gnu.org are authorized by default on GuixSD <wingo>lfam: your patch sounds fine tho, i mean the problem is bad enough that we should get any old thing in <lfam>wingo: Yeah, I just want to prevent any more users from hitting the bug <wingo>i am a bit disappointed that i couldn't understand the problem well enough to fix it tho. <nextos>lfam: i get a makefile running which compiles with CXX a lot of nix files, and then GUILEC compiles lots of package definitions <wingo>there are some goops complexities that i have a hard time paging in <lfam>wingo: I agree... I plan to *try* digging in as far as I can. It's a problem if only one person understands this stuff. <lfam>And the commit message, is it sensible? <wingo>yes lgtm, no co-author needed fwiw <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 :) <nextos>wanted to avoid this if possible <nextos>i thought it was not expected, but maybe its a necessary bootstapping step? <nextos>i can reach it, but i didn't indicate that url to guix in any step, im just following the installation guide <nextos>so any way to avoid compiling guix? <lfam>nextos: There's no harm in sending a question about this to <help-guix@gnu.org>. 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. <lfam>Hopefully somebody else will chime in here, too <nextos>yes if someone chimes in it'd appreciated, otherwise i'll email the list <wingo>why does rekado_ only have one key <ZombieChicken>Can someone on a GuixSD install tell me if mkfs.nilfs (or something similar) exist? <lfam>ZombieChicken: It does not exist by default <lfam>sneek: What is core-updates <sneek>I've heard Core-updates is fontconfig, eudev and cups-minimal FTBFS, tcsh's test hangs <lfam>sneek: core-updates is fontconfig, eudev and cups-minimal FTBFS, tcsh's test hangs, util-linux needs a fix for CVE-2017-2616 <lfam>sneek: what is core-updates <sneek>From what I understand, core-updates is fontconfig, eudev and cups-minimal FTBFS, tcsh's test hangs, util-linux needs a fix for CVE-2017-2616 <lfam>sneek: I got hungry and ate your botsnack <lfam>sneek: core-updates is fontconfig, eudev and cups-minimal FTBFS, tcsh's test hangs, util-linux needs a fix for CVE-2017-2616, gnutls lacks IDN support unless it uses libidn2 <lfam>sneek: core-updates is fontconfig, eudev and cups-minimal FTBFS, tcsh's test hangs, gnutls lacks IDN support unless it uses libidn2 <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 <katco>janneke: thanks, i'm now in what i understand to be the module (guix licenses)? <katco>janneke: ah ok and i can do ,b from there <katco>janneke: thank you, you've unstuck me :) <janneke>katco: are you sure you don't want to `just read' the guix/licenses.scm file? <katco>janneke: that would make sense too! <janneke>katco: or even look for a package in gnu/packages/*.scm and steal their recipe <katco>janneke: i'm really floundering around atm, so i will probably end up doing that <lfam>katco: If you enter some of those sentences in a search engine, you will find that it is a 3-clause BSD license <lfam>That's the best way to find out about a license <katco>lfam: ok. can you tell this is my first time packaging software :) <lfam>It's okay :) Let us know if you need more help <katco>lfam: ta, i really appreciate it. <lfam>You're quite welcome! I got my start my asking questions here, too <katco>so, i asked this a couple days ago. ultimately i'm trying to package scala, which now requires sbt to build. sbt requires itself to build <katco>what i was planning on doing is packaging the earliest version of sbt i could find in the hopes that i could someday build it from source <katco>so i was going to package sbt 0.7, sbt 0.13, and the scala <katco>sbt 0.8 would be sbt-bootstrap <katco>does this sound like a sane plan? <lfam>katco: It definitely sounds like a plan :) I would propose it on <guix-devel@gnu.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 <lfam>You may want to search the guix-devel archives for discussion of maven and ant. I assume they are at least superficially similar <lfam>We have ant but, if I remember correctly, basically gave up on maven for the time being. <lfam>For completeness, you might as well search on <help-guix@gnu.org>. The discussions tend to get fragmented as we add new mailing lists :( <lfam>It's only convenient for those us who have the messages indexed locally somehow <katco>lfam: i'll have a look around, i'm sure it won't be too bad <lfam>ACTION tries to reproduce