<apa512>i thought so too. putting some nonsense like `(#:phases aoeu)) will still run the %standard-phases without complaining. misspelling arguments as argumentss doesn't work though, so it's not that the wrong file is used or anything like that.
<tsyesika>rekado, davexunit: give me a few minutes, I'm currently getting the dmesg output which took some doing as network didn't work and the mac only had 2 usbs so ended up writing a script, will try what you've suggested and feedback shortly
<piyo>hello my rpi2 crashed and I doubt the fs integrity, is there a way to verify the /gnu/store ?
<davexunit>lfam: if there's a branch I can pull, I can do the clean up, test, and push upstream.
<lfam>davexunit: I've done a little work to address the questions I asked in my email, specifically the questions about python-3 -> python-2 dependency issues. I keep rereading the Efraim's emails of 2015-11-25 regarding this subject, and I still don't understand the heart of the issue. But when I made "proper" python-2 packages so that the python-2-specific dependencies didn't muddy up the python-3 packages, I had the same kind of problems as
<lfam>davexunit: Well, my original patch series did things like specify python-setuptools as a native-input for python-zope-event, even though it didn't need it, because python2-zope-event needs it. I was being layz and just used the automatic translation of package-with-python2. When I tried to split them up "properly" it goes awry.
<tsyesika>davexunit, rekado: okay so! keyboard works fine in guix's grub, all the keys are dead, not some of them and doing a modprobe on hid-apple doesn't make the keyboard work
<lfam>5834a8c is what I submitted to the ML. The next commit is just a version bump from Let's Encrypt. It builds but I haven't tested it. The rest of the commits are fixups that I have not rebased yet.
<tsyesika>(the all the keys are dead comment isn't about grub btw, it's about once i've booted in, rekado asked if all keys were dead)
<lfam>In those "fixup" you see the python-3 -> python-2 problems emerge
<lfam>I'm sorry, 5834a8c is not the same as what I sent to the ML. I did rebase some changes in. Specifically, the correct url for the dialog package and a changed commit message for python-parsedatetime
<lfam>But it is functionally the same because the "correct url" does provide the same tarball
<lfam>Be careful about hitting Let's Encrypt per-account and per-domain rate limiting — it was pretty severe as of a week ago. The limits are higher for test certs.
<lfam>Of course whoever pushes it will have to either trust my review or do some of their own. But it could help as a "sanity check" for the basic stuff.
<lfam>Okay, time to learn how to automatically apply patches from mutt
<davexunit>for frequent contributors, I don't do much in the way of thorough checks, I just check for style issues mostly.
<davexunit>I assume that they have linted and tested that it builds
<lfam>Yeah, the Guix / Nix system is so robust that a bad push is not the end of the world. It's not like Debian where a bad push can break a system so badly that it's faster to reinstall from scratch.
<lfam>I've been thinking about that, too, since I had to reinstall my debian-armhf system :(
<lfam>It's a really concrete way that this model saves tons of human time
<avoine>what could be the cause of: warning: collision encountered: /gnu/store/44m...-xfce-4.12.0/bin/startxfce4 /gnu/store/hn6a...-xfce4-session-4.12.0/bin/startxfce4 ?
<bavier>avoine: did you install both xfce and xfce-session packages?
<lfam>avoine: For some reason both of those packages are in your profile and providing the same-named binary. Guix will choose one at random. You could use the `guix gc --r...` to find out what is propagating the "extra" package
<lfam>Did you install it to test it out and then forget to remove it? You can use `guix environment --ad-hoc foo` to do that. That way your profiles don't get "polluted" and the garbage collector can remove the unneeded software automatically.
<bavier>the problem is that xfce provides a symlink to xfce-sessions's startxfce4 while at the same time propagating its xfce-session input
<bavier>but maybe that's not an issue, I haven't tried it myself
<lfam>Is it supposed to do that or is it a bug in the package definition?
<lfam>It's an issue when your terminal gets clobbered by several screens worth of conflict warnings. And sometimes the conflicts are real problems, like with GNU Parallel and joeyh's moreutils' parallel.
<bavier>lfam: sure. we certainly want to minimize unnecessary conflicts
<davexunit>I believe we have a bug open about the absurd amounts of conflicts
<bavier>I'm guessing the symlink was made so that one can do things like `guix build xfce`/bin/startxfce4
<bavier>but one could just as easily s/xfce/xfce-session/
<lfam>It's funny. The thing that finally got me to sit down and install Guix on Debian was GNU Parallel vs moreutils. But the joke was on me: I misunderstood Guix, and the conflict is still an issue ;) Of course, it's much easier to work around the problem in Guix.
<davexunit>lfam: 'guix environment' is good for picking the thing you want.