IRC channel logs

2016-08-30.log

back to list of logs

<ng0>sneek: later tell jlicht: you wrote about progress on rust a while ago. is there something which can be done so that it temporarily works, not intended for guix master or any progress patch?
<sneek>Okay.
<jlicht>ng0: It has been some time since I last looked at this, but I just packaged a recent stage0 snapshot compiler, and used that to build a 'recent' rust from somewhere last February.
<sneek>Welcome back jlicht, you have 1 message.
<sneek>jlicht, ng0 says: you wrote about progress on rust a while ago. is there something which can be done so that it temporarily works, not intended for guix master or any progress patch?
<jlicht>ng0: The biggest inspiration for that effort was the nix package they had for rust. It involved some 'patchelf' invocations.
<jlicht>to clarify: I needed to package a prebuilt stage-0 compiler
<ng0>stage-0? something in the rust chain, or the stage0 assembler collectuion on github?
<ng0>I identified something needed to deactive which recently got into rustc, but I wanted to check how your progress differs from mine
<ng0>A software I package for recently switched to rust, so I'm interested in working out of tree on that
<ng0>hwoever hacky or 'ugly' it is, anything would give me something to improve my own rust build on :)
<jlicht>ng0: Besides some hello-world type of stuff, I never really used the result of my effort :-)
<ng0>I have this prototype2016 and the before that the panopticon application which requires cargo and rust
<jlicht>ng0: The following ML thread properly explains the bootstrap stuff: https://mail.mozilla.org/pipermail/rust-dev/2014-June/010222.html
<jlicht>at least as it was back when I tried to make it work
<ng0>thanks
<ng0>can you paste your rust package too? I'd be curious.. had to dig out my package from backups.
<jlicht> http://paste.lisp.org/display/324577
<ng0>uff. okay that's some additions to my original :) many thanks
<jlicht>the patches in that package definition should no longer be required
<ng0>afaik there was a switch for configure introduced in one of the last versions of rust
<ng0>i have a look at it in the next days, it's late. thanks again.
<jlicht>ng0: in case you need them, I added the patches as annotations to the paste
<ng0>ah, okay these are patched problems I did not even get to. cool
<kete>If multiple users install the same package on a system, will they share the same directory in /gnu/store?
<lfam>kete: Yup, the store is shared across the entire system
<kete>thanks, that's good
<lfam>The NixOS hardening blog post in on the front page of HN. No comments yet but hopefully there will be some interesting discussion
<retroj>i would like to set up an environment (using the term loosely) in which to run chicken scheme 4.10.0, while my main profile has chicken 4.11.0 installed. i've made a package definition for 4.10.0 and can install it from that file. how do i set up the environment?
<efraim>Guix environment --ad-hoc doesn't sound like the right choice since you'd then have two versions of chicken
<retroj>as long as 4.10.0 shadows 4.11.0 in the environment, that's fine
<retroj>there are some environment variables that need to be set as well
<lfam>retroj: If you just need to run chicken scheme in the environment, would `guix environment --pure --ad-hoc chicken@4.10 -- chicken` work? You could also try creating a profile for this and use `guix package -p`. It would be good if you could pass profiles to `guix environment`
<retroj>lfam: the chicken 4.10.0 package is in a file. is there a guix environment invocation that would take the package definition from a file?
<retroj>oh, found it. --load
<lfam>retroj: I thought about it some more, and the profile created by `guix environment` should be the first thing in your PATH, so you shouldn't need to use --pure to hide the other version of chicken
<efraim>That's what I was wondering about
<retroj>okay, so if i make a shell script that sets the environment variables that i need, i could do something like: guix environment --ad-hoc --load guix-chicken-4.10.0.scm -- ./chicken-4.10.env.sh
<retroj>is that right?
<retroj>or, i then need to rush bash in that environment, to have a shell to work in..
<lfam>Passing a command after '--' will not give you an interactive shell. It will just run the command in a new shell and then exit
<retroj>yeah, got it
<retroj>thank you
***tschwing_ is now known as tschwinge
<civodul>Hello Guix!
<alezost>brendyn: re "C-c . l" error: it happens because your guile doesn't know where to find guix modules; it's the same as when you run guile and evaluate ",use(guix)" there - it also fails, right?
<alezost>brendyn: I guess you use guix from a git checkout; if so, you need to add "/path/to/your/guix-checkout" directory to GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH environment variables
<malthe>so I'm trying to add group 'kvm' to my guix builders, but now the system can't find its members, presumably because they are now member of more than one group.
<malthe>the nixos documentation also specifically states to have them be members of just the one group.
<civodul>malthe: it's fine to have guixbuild users in the 'kvm' group
<jjmarin>Hi ! I've installed guixsd 0.11 on my laptop with GNOME. After that I installed Libreoffice, but although it is installed and I can launch it from the terminal, the installation didn't add it to the application list to launch it from the GUI. Is it a bug or there is anything else I have to do ?
<civodul>malthe: it should be a supplementary group though, not their main group
<civodul>jjmarin: this may well be a bug! could you send this to bug-guix@gnu.org?
<malthe>civodul: right, I forgot the '-a' argment to usermod :-)
<malthe>i'm trying to build a google compute engine image and test-drive it..
<civodul>neat
<civodul>interesting read: https://blog.mayflower.de/5800-Hardening-Compiler-Flags-for-NixOS.html
<lfam>civodul: That article is what made me revive the thread
<civodul>lfam: oh, i haven't read messages yet, but i'm happy you're looking into that!
<rekado_>I was about to post the same link just now.
<lfam>It seems we'd want a default set of values that would be appended to by #:configure-flags
<rekado_>lfam: the article on NixOS hardening suggests that there should be an easy way to disable some hardening flags for some packages (Xorg, for example).
<lfam>#:fortify? #f
<rekado_>maybe
<lfam>Something like that, per flag
<rekado_>I think that it may make sense to make these flags separately configurable, not only via #:configure-flags.
<rekado_>not sure.
<rekado_>ACTION goes afk
<lfam>Or, batch them together like the Nix example, (hardening-disable fortify)
<civodul>lfam, rekado_: i think we could do #:configure-flags '("CPPFLAGS=-O2 -g -D_FORTITY_SOURCE=2" ...), unless #:fortify-flags is empty, or something like that
<civodul>but again, many things will break as the article says
<lfam>Is this #:fortify-flags just referring to "-O2 -D_FORTIFY_SOURCE=2", or to a larger set of flags?
<lfam>It would be nice to be able to toggle them individually
<civodul>maybe something like #:hardened-flags '(fortify stack-protector)
<civodul>which would be translated to #:configure-flags etc.
<lfam>I like that
<civodul>not for this core-updates cycle ;-) but definitely something we should start working on
<civodul>lfam: BTW, do you know what's next for wip-python?
<lfam>civodul: I found the story of how NixOS upgraded their setuptools package: https://github.com/NixOS/nixpkgs/pull/12552
<lfam>A long story
<lfam>I updated the Python packages on core-updates. If that goes well, I will merge core-updates into wip-python and restart the work from that point
<jjmarin>after installing some packages, I've realised that it is common to some export lines following this line "The following environment variables maybe needed". I should add it to my bashrc ? Does it makes sense to ask for manual work instead of do it automatically ?
<jjmarin>n the island’s deep south, the villages they founded still preserve the traditions of the “Merikins,” as writer Judy Raymond and photographer Marlon Rouse discover — and still have much to teach their fellow citizens
<civodul>lfam: oh, i see; so we should focus on core-updates first, i guess
<jjmarin>sorry for the offtopic message, I was using the other keyboard :/
<lfam>Interesting topic, though!
<civodul>jjmarin: see the bit about ~/.guix-profile/etc/profile in https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html
<brendyn>alezost: I think I installed guix from the binary, then I did guix package -i guix which has given me a git version
<jjmarin>civodul: thanks for your reply and patience :-)
<alezost>brendyn: do you also have guile in your profile?
<brendyn>alezost: I think the guile I'm using is installed by my distro, Parabola. Should I run guix package -i guile?
<alezost>brendyn: yes, it should fix your problem
<alezost>brendyn: the problem is: if you look at "~/.guix-profile/etc/profile": it does not have GUILE_LOAD[_COMPILED]_PATH vars, while if you install guile, they should appear there
<brendyn>fantastic
<brendyn>By the way, I find guix package -s returns too many packages, because it searches package descriptions and synopsis. Can this be improved?
<brendyn>If I search for Emacs, I get weechat, skribilo, readline, etc...
<civodul>brendyn: results can be refined a bit, as illustrated at https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html
<civodul>however, the real improvement would be to compute a "rank" for each match
<civodul>like search engines do
<alezost>brendyn: probably, I never use "guix package -s", I use "M-x guix-search-by-name" or "M-x guix-search-by-regexp"
<lfam>civodul: In general, I think wip-python will take a while, but I need to refresh my memory of how it's broken. It might get done sooner if we merge it into core-updates, since there would be more people looking at the resulting problems.
<brendyn>All problems are Bayesian probability problems in the end :p
<civodul>lfam: OTOH that could delay core-updates for a long time
<civodul>i prefer to have separate topic branches
<brendyn>alezost: Sure, but I'd like it to work without Emacs. How can I make changes to guix it's self and test them?
<lfam>civodul: It's true, core-updates would be thrown into chaos
<alezost>brendyn: I don't understand, do you mean you want to change the guix code?
<brendyn>alezost: I'd like to modify ui.scm
<brendyn>I mean, how do guix devs hack on guix?
<alezost>brendyn: then you need to use guix from a git checkout, see (info "(guix) Building from Git")
<alezost>brendyn: in case you didn't know: in emacs you can evaluate this (info ...) expression, and it will open an info manual for you
<brendyn>I have been using https://www.gnu.org/software/guix/manual/guix.html
<alezost>ok, well, I just think info in Emacs is much more powerful than reading it in a web-browser :-)
<brendyn>Yeah but Emacs gets too difficult to use most the time so I usually just give up and use the command line with zile or nano and iceweasel
<civodul>very good summary of the hardware freedom situation, for French speakers: http://linuxfr.org/news/le-logiciel-libre-au-dela-de-x86
<brendyn>Haha, I can basically read it and I've never learnt any French.
<rekado_>A while ago I pushed a branch to patch our GTK packages to respect GUIX_GTK{2,3}_IM_MODULE_FILE. This allows us to use input modules. Could someone with access to hydra build this branch please?
<rekado_>Or should I push this to core-updates instead?
<civodul>rekado_: what's the branch name?
<rekado_>civodul: gtk-im-modules
<civodul>rekado_: here we go: https://hydra.gnu.org/jobset/gnu/gtk-im-modules :-)
<rekado_>civodul: thanks!
<civodul>we should create accounts for you and lfam
***MatthewAllan93 is now known as The-Ninja
***The-Ninja is now known as MatthewAllan93
<brendyn>alezost: I installed guile but it segfauls when I try to run guile
<alezost>brendyn: what is the backtrace?
<brendyn>how do I get the backtrace?
<alezost>oh, do you mean you run guile and the only message appear is about segfault?
<brendyn>yes
<alezost>hm, maybe some environment interfere, do you set some unusual env vars, like LD_LIBRARY_PATH?
<brendyn>LD_LIBRARY_PATH=/home/b/GNUstep/Library/Libraries:/usr/lib
<brendyn>No idea why that is set
<alezost>try unset LD_LIBRARY_PATH and run guile again
<brendyn>It works
<alezost>brendyn: ok, try ",use(guix)" there
<brendyn>It works.
<alezost>great!
<brendyn>Not sure that that env variable is needed for
<brendyn>Ok, well now when I run emacs I lose all my fonts
<alezost>I think it does not relate to a guile install :-)
<alezost>is it emacs installed with guix? did it work properly before?
<alezost>also what does "I lose all my fonts" mean exactly?
<brendyn>guix.el works
<brendyn>I mean after I unset LD_LIBRARY_PATH and then open up emacs, I get Font `Bitstream Vera Sans Mono 10' is undefined
<alezost>is it emacs installed with guix?
<brendyn>yes
<alezost>try to install font-bitstream-vera (maybe some other fonts, like font-dejavu)
<brendyn>Maybe I need the glibc-locales instead of glibc-utf8-locales
<brendyn>Since I get Gtk-WARNING **: Locale not supported by C library.Using the fallback 'C' locale.Gtk-Message: Failed to load module "canberra-gtk-module"
<efraim>i'm looking at the bidiv package, last updated 6 years ago
<efraim>you need to set your locale
<brendyn>I feel like I've set the locale stuff like 20 times
<efraim>:(
<brendyn>Do I need to actually edit a locale.conf?
<efraim>basically bidiv reads one char at a time, converts it to unicode, converts it to ISO_something_hebrew, and prints it back backward, line by line
<efraim>that I don't know
<efraim>bidiv looks like a candidate to rewrite in guile to get more familiar with it
<brendyn>Ok so updateding resulted in glibc-locales being downgraded from 2.23 to 2.22
<efraim>Ah, that would be a problem
<efraim>Or a fix
<brendyn>warning: collision encountered: /gnu/store/jm4pd6hvgpclkxw2jgxnjl0s77grcwnr-gmp-6.1.0/lib/libgmp.so /gnu/store/cdkrfbl10kbyyjjw3yfk9hckfw8n1b7g-gmp-6.1.0/lib/libgmp.so
<efraim>You're on guixsd or another distro?
<brendyn>Another distro
<brendyn>Maybe there are issues with upgrading guix as a user. Probably root still has the older version running the daemon
<efraim>What do you get from guix --version
<brendyn>If I run it as a user I get 0.10.0, if I run it as root I get 20160827.16
<efraim>So you'll need to run guix pull as your user too
<brendyn>I'm still confused about guix pull and guix refresh. I've being trying to complete guix refresh for like 3 days
<efraim>I normally run it as 'sudo guix pull && guix pull'
<efraim>To keep the two close
<brendyn>Do you run guix refresh?
<efraim>Guix refresh checks to see if there are new upstream releases of some of the packages
<efraim>To update your packages you need guix package -u
<brendyn>When I run guix package -u I get error: directory `/var/guix/profiles/per-user/b' is not owned by you
<alezost>brendyn: as a user, you never need to run "guix refresh", it's "guix pull" that you need to get the latest package recipes
<alezost>brendyn: what is the output of "file ~/.guix-profile"?
<brendyn>/root/.guix-profile: symbolic link to /var/guix/profiles/per-user/root/guix-profile
<alezost>for your user
<brendyn>.guix-profile: symbolic link to /var/guix/profiles/per-user/b/guix-profile
<brendyn>Seems ok
<alezost>ok, so you need to own "/var/guix/profiles/per-user/b"
<brendyn>I already do
<brendyn>I get that error as root, as if root somehow thinks it is b
<alezost>so, do you run "guix package -u" as your user? without sudo, or whatever
<brendyn>yes
<alezost>hm, check LOGNAME
<brendyn>guix pull: error: failed to unpack source code
<brendyn>LOGNAME is b
<alezost>I think you are the second person who faced this error: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24220
<alezost>what is the output of "stat /var/guix/profiles/per-user/b"?
<brendyn> http://pastebin.com/raw/gwXQfdkv
<alezost>brendyn: wait, but you told that you run "guix pull" successfully under root, right? but it fails with that error if you run it as user, is that correct?
<brendyn>Yes
<alezost>it is worth mentioning this in that bug, could you please send a message there reporting about it
<alezost>the stat looks good to me, so I don't understand why have that "not owned by you" error :-(
<alezost>btw pastebin is not welcomed here, as it blocks tor users, there are many alternatives, for example http://paste.lisp.org
<brendyn>Oh ok, sure
<brendyn>root has LOGNAME is b. Is that I mistake. I've never heard of this variable before
<brendyn>Ok, I need to fix my email server which has been broken for months so I can send an email...
<brendyn>If I have run guix pull as root, shouldn't it be possible to update the user account without downloading master.tar.gz again?
<random-nick>what happened with the guix on hurd project?
<ng0>it is still work in prgress, see search on guix-devel for hurd most recent message :)
<random-nick>I searched guix-devel a few days ago but couldn't find anything recent, I'll try again
<ng0> http://lists.gnu.org/archive/html/guix-devel/2016-08/msg01002.html
<civodul>we should post a GSoC update
<ng0>the series of import/* patches.. i forgot in 2 of those commit messages to start the sentence with a capital letter.. should I resend?
<ng0>sneek: later tell wingo: https://git-scm.com/docs/git-shell I will comment why this is different than /sbin/nologin
<sneek>Will do.
<ng0>i hope the nick was wingo.
<nckx>ng0: if that's the only issue, I'd say no. Just add a note for the future committer.
<wingo>ng0: that needs a much more strict security analysis i would think :)
<sneek>wingo, you have 1 message.
<sneek>wingo, ng0 says: https://git-scm.com/docs/git-shell I will comment why this is different than /sbin/nologin
<ng0>it depends. I have no preference.
<ng0>If you think that git-shell is worse than nologin, okay
<ng0>I also object to some of the proposed chnages as they break with expectations. do we have to do this just because it is GNU?
<ng0>object? well at least i think it is not logical
<wingo>i think you are not hearing what i am saying. a guix user should be able to read the manual and understand the impact of a service that they install. in particular a user should know if they are allowing more accounts via ssh access or no, if this is anonymous read-only access or something else, etc
<wingo>i don't think this was clear before.
<wingo>that was my feedback :)
<ng0>it makes sense..
<wingo>coolio, happy hacking
<ng0>I will apply changes.. writing new documentation is not my favorit thing to do.
<wingo>tell me about it, hehe :) the one good thing is that it helps make sure the code is the right thing. it's often the case that documenting code makes me realize that the code was the wrong thing to begin with :)
<ng0>the git-service still feels like a shot into the dark, with the VM not being able to port-forward to the host.. and localhost didn't work either afaik
<ng0>it would really help to have a system vm where you can dial-in from the host
<wingo>hmm, that should be possible yeah
<wingo>i guess it's a question of giving qemu the right incantation
<wingo>that thing has about a billion command line options :P
<davexunit>yeah qemu can definitely do that
<davexunit>just not sure which option it needs
<ng0>I tried but it did not work as expected.. applied the same with how i start qemu on nixos
<ng0>there is a new way, and an deprecated but still working way.. both failed
<wingo>something like -netdev type=tap,id=net2,ifname=${IFACE},vhost=on,script=${NETSCRIPT} \\
<wingo> -device virtio-net-pci,netdev=net2,addr=0xa,mac=52:54:00:00:00:03 \\
<ng0> http://lists.gnu.org/archive/html/guix-devel/2016-08/msg01816.html the new way is displayed when you use the old one
<wingo>then you need a script that will do ip addr add ${IP} dev ${IFACE}
<ng0>I don't know how much the generated qemu differs from just launching my simple gentoo vm on nix, which has the minimum of options
<ng0>oh.. okay I will add some more details, I'm reading the man page again
<kyamashita>Hello all!
<kyamashita>Packagers, should I disable the check phase of a build if the application wants to launch itself graphically ("gtk-launch $app.desktop")? It reports not being able to open an X display server.
<civodul>kyamashita: for testing purposes, you can spawn Xvfb
<nckx>kyamashita: if there aren't any significant non-graphical tests (and there likely aren't): yes. Otherwise you might only patch out the tests that require X.
<nckx>civodul: oh :-)
<kyamashita>lol
<ng0>I think git-shell is the binary i can use to test the daemon locally. i will have more results later
<nckx>That seemed overkill to me.
<civodul>kyamashita: there are a few examples where we start Xvfb so the tests can run
<nckx>civodul: OK, that is cool.
<kyamashita>civodul: I see one that's also in gnome.scm. I'll investigate and see if it works. Thank you!
<ng0>I think services are not so difficult.. you just spend more time writing them, and see own mistakes when documenting them
<ng0>when I started with guix, some packages looked equally 'difficult' to me
<brendyn>What should I write in the commit log when I add a package?
<kyamashita>brendyn: See http://paste.lisp.org/display/324641
<kyamashita>brendyn: Substitute your own package name and appropriate Scheme file.
<brendyn>Even with "New variable"
<kyamashita>Yes.
<ng0>I only need #:use-module ice-9 match when I use match-lambda, or is there more to it in gnu/services/?
<kyamashita>gnu: Add my-package.
<kyamashita>* gnu/packages/scheme-file.scm (my-package): New variable.
<kyamashita>civodul: The check fails, complaining about libGL and D-Bus. :-/
<civodul>kyamashita: some tests really cannot be run, just make sure to document the reasons in a comment
<civodul>like "requires access to /etc/machine-id", "needs OpenGL thingie", etc.
<kyamashita>Heh, it needs both, apparently.
<civodul>see how i manage to guess? :-)
<kyamashita>This happens often, huh?
<ng0>when the second option in an (if) would be nothing ("") is it "" or does the lack of a second part assume this?
<rekado_>ng0: I don't understand this question
<ng0>(if (git-configuration-user-directory? config) "--user-path" "")
<rekado_>looks good
<ng0>(if (git-configuration-user-directory? config) "--user-path" ) would be a syntax error than, i remembered the scheme introduction correctly
<ng0>*then
<rekado_>not a syntax error
<rekado_>try this in a repl: (format #t "~a\\n" (if #f "hi"))
<rekado_>this will print the value that the (if ...) returns
<rekado_>#<unspecified>
<rekado_>ng0: that's a real difference.
<rekado_>(string-append "hello " (if #f "world"))
<rekado_>this will fail
<rekado_>whereas this won't:
<rekado_>(string-append "hello " (if #f "world" "earth"))
<rekado_>#<unspecified> is not a string.
<ng0>i see.
<ng0>thanks
<brendyn>Oh, turns out this build isn't actually reproducible
<kyamashita>Eek. Packaging Polari seems to be out of my league. Anyone familiar with GNOME Javascript applications?
<civodul>not me :-/
<ng0>what is the difference between adding default values to define-record-types or just adding them in define git-service for example?
<ng0>for example comparing lsh and dropbear service
<ng0>their construction is different.. but why do some define them in the beginning and why does my service work with defining them in the end and not the record?
<brendyn>What tools can I use to compare two builds that differ?
<kyamashita>brendyn: I remember diffoscope being recommended.
<brendyn>Hmm I just used `head' and they were build with different versions of glibc
<brendyn>Will try again
<brendyn>Why does guix contact the internet even when uninstalling a package?
<ng0>I find this execiting to learn.. much more useful than the ebuild and openrc grammar and constructions :)
<kyamashita>brendyn: Can't say much on that, though I've never had trouble removing packages while I was offline.
<civodul>brendyn: when uninstalling a package, it rebuilds your profile, which might need stuff from the internet (e.g., it needs Texinfo to rebuild the 'dir' file, etc.)
<kyamashita>ACTION is temporarily afk
<brendyn>I want to build this package but it seems to refuse to do that after I've already built it
<kalashkash>hi everyone!
<kalashkash>im a noob in GNU-Guix, and i have been installing some packages like as emacs and others.... but, so i see the guix system package doesn't require privileges to install software.
<brendyn>yep
<kalashkash>doesn't that become more insecure?
<kalashkash>(sorry for my bad english)
<brendyn>Well Guix has a daemon that listens to all users and installs packages as they wish
<OrangeShark>kalashkash: it not much different from a user downloading the source code and building it themselves locally
<OrangeShark>what they install does not affect other users like it would other package managers
<kalashkash>ahhhh, ok... but the 'sudo make install' ?
<kalashkash>ahhhh ok
<OrangeShark>kalashkash: they can install to their home directory without sudo
<kalashkash>OrangeShark: ok, I see
<kalashkash>i like this system distribution, seems cleaner
<OrangeShark>it an interesting approach
<nee`>kalashkash: you can't install packages for other users without root rights. The default 'sudo make install' would put it into /usr/ which is in the PATH variable of most users on most systems. In guix other users and system-services (like your webserver) should stay unaffected by user-level package management.
<kalashkash>nee`: thanks, now i read more about this, it's looks pretty nice
<kalashkash>i have other question! Guix SD is rolling release? or it's can upgrade from the current version to a newer?
<brendyn>kalashkash: rolling
<kalashkash>oh yeah! =D
<brendyn>kalashkash: You could create such a model if you wanted, but currently everyone just keeps making improvements.
<brendyn>There isn't even a stable release to maintain at the moment anyway
<kete>I wonder how high the dot version will go.
<brendyn>I tried emailing a patch in. Not sure if it working though
<davexunit>ACTION reads these comments and is grateful that he uses guixsd http://lwn.net/Articles/698453/
<lfam>davexunit: That story is really disturbing. Nobody knows where RPM development is taking place?
<ng0>:O
<lfam>But, I think we should be careful to keep our own house in order. It seems that somebody with a lot of resources is studying the upgrade mechanisms of free operating systems. There's no reason they won't look at us.
<lfam> https://github.com/libarchive/libarchive/issues/743
<lfam>I like this comment in that LWN discussion: "That's the nice thing about being behind other distros. You can copy their solutions without having to make the same mistakes in the beginning."
<davexunit>I was more commenting about the horrible complexity around stateful package managers
<davexunit>my reaction to so many of the comments there is "glad I don't have to worry about that"
<lfam>I figured that's what you meant. But I wanted to comment on the lack of accountability for the core packaging tool of an entire family of operating systems
<lfam>Do we want to put glibc-2.24 on core-updates? Or is the branch too far along?
<bavier2>has anyone tried updating epiphany to 3.21.90 yet?
<efraim>from what i've built on core-updates, x86_64 is in good shape
<efraim>there's also been a new release of gawk
<bavier2>oh, or are odd minor versions on gnome apps unstable...
<efraim>odd gnome versions are dev releases
<kete>gnome looks like gnustep except for root
<dvc>@lfam what's wrong with our house? =P
<lfam>dvc: Who knows? That's why we need to be careful :)
<lfam>I recommend reading the "Trustable guix pull" discussion on bug-guix. We still have some work to do
<lfam>Oops: https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg04231.html
<lfam>Is anyone familiar with the people in that thread? I don't know how to judge if the patches are from a trusted source or not
<lfam>Too bad the emails aren't signed
<paroneayea>kete: you might need to hit f1
<paroneayea>kete: I've encountered a weird bug where if I don't hit f1 and explicitly select things it'll select the wrong session option
<paroneayea>ACTION should report that..
<kete>I might log in a few times and see what happens.
***fkz is now known as Guest7535
<paroneayea>ACTION misses icecat/firefox
<paroneayea>I know, don't complain, help patch the vulnerabilities :)
<kyamashita>I've been on GNOME Web until today. It takes a bunch of memory if you open many tabs.
<paroneayea>kyamashita: yeah it's not ideal
<paroneayea>I wonder if we should also make a more clear PSA to the list that current icecat has known vulnerabilities, don't use it
<kyamashita>Mark Weaver did that a while back.
<paroneayea>ah ok
<paroneayea>well then :)
<kyamashita>I have to say though, I really like the integration of GNOME Web with the desktop environment.
<paroneayea>ACTION is not using gnome right now, but would like to
<paroneayea>x200's opengl acceleration is not quite good enuf
<kyamashita>I'm on an X200, too. I just switched back to WindowMaker today for the same reason.
<lfam>paroneayea: There is a beta release of icecat 45: http://lists.gnu.org/archive/html/bug-gnuzilla/2016-08/msg00026.html
<lfam>So, I know a way you could speed up the process ;)
<paroneayea>lfam: aha, nice :)
<paroneayea>kyamashita: yes I'm on xfce for a bit because of it
<paroneayea>if I had time, I'd be packaging stumpwm or using guile-wm though
<kyamashita>guile-wm gives me crashes occasionally on GuixSD. I'm working on my Guile skills so I can investigate usefully.
<ksjogo>Brave browser is quite nice from a user perspective as well. Not packaged for guix though. Does anybody know how far node-gyp would work with guix?
<kyamashita>SICP FTW.
<lfam>ksjogo: There has been recent work on getting the Node ecosystem. I would search the guix-devel archives for "node" and possible "npm" to get a sense of the status of the project
<rekado_>bavier2: that version of epiphany also needs an unstable version of webkitgtk.
<rekado_>that’s why I only upgraded to the latest stable version
<rekado_>(why does the shell in Emacs not share the history as that outside of Emacs?)
<kyamashita>rekado_: which shell? M-x shell?
<rekado_>kyamashita: yes
<kyamashita>Perhaps this is the case. http://superuser.com/questions/597759/how-to-save-shell-history-from-emacs-and-use-it-in-terminal
<kyamashita>When I think about it, I rarely cleanly exit from my Emacs shell sessions
<rekado_>ah, I remember this.
<rekado_>I think I decided to write to the history on each prompt, but I forgot to actually implement this.
<ksjogo>lfam: thanks, will run through it
<rekado_>kyamashita: but it also seems like M-x shell doesn’t read the history. The history item I was after can be found in the shell when I use xfce4-terminal, but it’s not found in M-x shell.
<rekado_>I’m about to move my GuixSD installation from /dev/sda3 (unencrypted) to /dev/sda2 (encrypted LVM).
<paroneayea>rekado_: encrypted lvm!
<paroneayea>do we support that now?
<rekado_>paroneayea: I have libreboot, so it shouldn’t matter
<kyamashita>rekado_: I just tried it with "history -a" and it worked.
<paroneayea>rekado_: oh yeah, you can do that.. you just have to type your passphrase in twice on boot :)
<rekado_>should “guix system init /etc/config.scm /mnt” just work when I run this from within my current GuixSD system?
<ng0>ksjogo, Brave Browser solves the problem in the wrong way and I'd rather not see them officially supported in Guix. YOu can pakcage it out of treee of course.
<kyamashita>I can't think of anything wrong with that, rekado_. Though I haven't changed partitions this way.
<rekado_>I’m a bit worried about GRUB.
<rekado_>not sure how this will be handled.
<lfam>ng0, ksjogo: If Brave Browser is free software, the default answer is "package it". If it has some problems, they should be discussed on guix-devel
<kyamashita>Just talk to GRUB calmly about what's about to happen and run through what it needs to do. I'm sure GRUB will pull through.
<rekado_>:)
<lfam>rekado_: How about the --no-grub option to `guix system init`?
<dvc>brave browser has an interesting business model... replace other peoples ads with your own
<ng0>I think we discussed it before. If a patch will get to the list, I will address its intransparency and freedom issues
<paroneayea>we should replace brave's ads with ads that pay for guix ;)
<lfam>Yeah, a little bizarre IMO
<paroneayea>jk
<lfam>paroneayea +1
<lfam>;)
<paroneayea>well, maybe we could replace ads with "donate to guix"
<paroneayea>:)
<ng0>you will rely with your browser on a companies server architecture you don't know to only browse the web. I find that fact alone highly problematic
<lfam>ksjogo: If you are planning to package Brave, I recommend you ask for advice on guix-devel before starting work. It will probably be a big project to package it, and I'd hate for you to do a lot of work only to be rejected at the end
<lfam>So... who wants to review Hartmut's Django patches?
<lfam>Seems like a great contribution!
<ksjogo>Thanks for the heads up everybody. Modifying web pages is fine for me and blocking obstrusive ads as well, but I still want to pay the creators, so brave seems an interesting way. And you are the right that the server/replacement technology needs to be scrutinized, I would just not put a final verdict on it. I will look a bit into guix packaging and then check back before spending a lot of time on it.
<efraim>we also have python-django-filter and python-pytest-django in ... ooops wip/onionshare.scm
<lfam>ksjogo: I recommend you read the manual, section 7.6.1 Software Freedom https://www.gnu.org/software/guix/manual/html_node/Software-Freedom.html#Software-Freedom
<lfam>That part of the manual will give you an idea of the requirements for our packages. And, of course, feel free to ask for further clarification and advice :)
<ng0>it could fail for the same reasons we do not package Chrome.
<kyamashita>ng0: Chrome or Chromium?
<rekado_>not sure what to make of this error: http://paste.lisp.org/display/324666
<rekado_>this is at the very end of sudo -E ./pre-inst-env guix system init /etc/config.scm /mnt
<rekado_>maybe the problem is with my config.scm, which doesn’t mention LVM or rekado-root at all.
<kyamashita>rekado_: That might be part of it.
<civodul>rekado_: LVM?
<bavier2>I'm having a look at the icecat 45 beta source
<kyamashita>bavier2: :)
<bavier2>I have the origin adjusted, then I can start building
<bavier2>my spinning disk is pretty slow for the source unpack/repack though
<bavier2>still need to put in the new SSD I got
<efraim>did we update sqlite on core-updates?
<efraim>its at 3.13.0
<efraim>debian testing is at 3.14.1
<civodul>efraim: this should be a safe upgrade to do
<efraim>i figured as mush
<civodul>much safer than many of the non-core updates currently in "core-updates" ;-)
<efraim>s/mush/much/
<efraim>also their website suggests 3.14.1
<civodul>one more reason
<rekado_>civodul: yes, encrypted LVM. I’m planning to unlock it with libreboot.
<rekado_>guess I need to update my operating-system config to specify the new root.
***bavier2 is now known as bavier
<civodul>ok but we'd still need some sort of LVM support in the init script no?
<efraim>just tried to do :w in mutt instead of $
<efraim>still a bad header from guile with sqlite's own source download
<wingo>bad header?
<wingo>http thing?
<wingo>efraim: what do you mean?
<wingo>i wonder if this is a problem that was fixed in 2.0.12
<efraim>same bug as http://lists.gnu.org/archive/html/bug-guile/2013-01/msg00027.html i assume
<wingo>efraim: have you tried with guile 2.0.12?
<wingo>i think if that patch was pushed in 2013 tho it should be in 2.0.11
<efraim>guile in core-updates should be 2.0.12
<wingo>if you have a guile bug i will look at it :)
<efraim>the short version is:
<efraim>Starting download of /gnu/store/xmg92xzb4157shasvcvykm00nwm8j8z4-sqlite-autoconf-3140100.tar.gz
<efraim>From https://sqlite.org/2016/sqlite-autoconf-3140100.tar.gz...
<efraim>ERROR: Bad Date header: Tue, 30 Aug 2016 20:54:43 +0000
<bavier>icecat 45 requires another sqlite macro definition
<bavier>-DSQLITE_ENABLE_DBSTAT_VTAB
<efraim>i'll toss it in
<bavier>efraim: I think that's the only new one, from what I can gather from its configure.in, but we'll see
<bavier>have to rebuild a lot to try again
<efraim>i can leave it out for now then and you can toss it in later in core-updates
<bavier>yeah, that's fine
<wingo>efraim: humm, i think sqlite.org is running a weird web server that is giving a bogus Date: value
<efraim>i can test the other wierd one also, fossil
<wingo>same people that make those sites
<wingo>we should email them, i think they will fix it
<wingo>efraim: i can send a mail now or would you like to do so?
<efraim>you send it, i'm not sure I'd know what to tell them
<wingo>i will do it
<efraim>guile 2.0.12 seems to have fixed whatever the problem was with fossil's download
<efraim>well, it looks like fossil fixed it actually, it works on master too
<wingo>what!
<wingo>does it work now? or what happened
<wingo>efraim: lmk because i was about to send the mail :)
<efraim> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20962
<efraim>about 1.34
<wingo>well, i mailed sqlite anyway
<efraim>I'm about to go to bed, just got this email from debian security about libarchive https://lists.debian.org/debian-security-announce/2016/msg00235.html
<civodul>uh