IRC channel logs

<Sleep_Walker>hm, Gnus seems to be bad choice for my 30k e-mails in maildir format, it's doing something for really long time

<ng0>if it converts to nnml, i can paste a perl script which re-converts them back to maildir

<ng0>i use notmuch

<ng0>i tried mu4e briefly, but did not like the threading

<brian|lfs>hello all

<brian|lfs>I feel rather stupid downlaod guixsd usb extracted it and my qemu is not letting me bott off the usb image

<brian|lfs>and I'm following the inscructions do I need to start with the binaryh and make an image fromt he binary perhaps

<demotri>brian|lfs: Sorry, I have to leave now. But here is what worked for me:

<demotri>Create image to install to : qemu-img create -f qcow2 guixsd0.qcow2 10G

<demotri>Start qemu:

<brian|lfs>ok

<demotri>qemu-system-i386 -m 1024 -smp 1 \\

<demotri> -boot menu=on \\

<demotri> -drive file=guixsd0.qcow2 \\

<demotri> -drive file=guixsd-usb-install-0.11.0.i686-linux \\

<brian|lfs>what about the install image

<demotri>Then immediately hit F12 during boot!

<brian|lfs>oh ok so the 64 bit didn't work for you either

<demotri>The install image can be "mounted" as raw format in qemu. That's the second parameter.

<brian|lfs>sorry should of mentioned that

<demotri>Ah, you mean qemu-system-x86_64?

<brian|lfs>yes

<demotri>Never tried that. I thought it is for AMD, but i386 is also 64 bit but for intel?

<demotri>Sorry, have to go. Good luck.

<brian|lfs>no 64 bit is for 64 bit i386 is for old 32 bit

<brian|lfs>ok

<ng0>hi

<ng0>is the guile website just not synced, or is 2.0.12 release not that important?

<rekado>ng0: better ask on #guile

<ng0>sure

<shymega>congrats on 0.11.0, #guix!

<shymega>and a good TZAG to you all ^^

<pmikkelsen>hi

<shymega>yo

<rekado>jlicht: yes.

<mark_weaver>rekado: so, it turns out that civodul wouldn't have been able to properly merge 'core-updates', because there are many unsigned commits on the core-updates branch, and so the commit hook rejects the merge :-(

<mark_weaver>the only options I see to address this are (1) rewrite the history of the core-updates branch, signing all of the commits myself (including the commits that are already signed by others), or (2) temporarily removing the commit hook, just long enough to push this merge.

<mark_weaver>and we are going to run into the same problem when trying to merge any other branch that contain unsigned commits, e.g. core-updates-next

<mark_weaver>rekado: do you know anything about how to modify the commit hook? is that something we need to ask the sysadmins to do, or can we do it somehow?

<mark_weaver>I don't like option (1) for several reasons.

<rekado>mark_weaver: I don’t know about how the hook was installed. If I understood correctly only the Savannah admins can do this.

<mark_weaver>thanks, I'm talking to nully now

<rekado>we would run into the same problem again as long as we have unsigned commits that need to enter master.

<rekado>but that’s a temporary cost.

<rekado>mark_weaver: okay, thanks.

<mark_weaver>okay, nully to the rescue, removed the gpg check for just a few seconds, long enough for me to push the proper merge :)

<ng0>why do we have to push unsigned commits? old branches to be merged into master?

<jlicht>mark_weaver: will we need to do anything special with our local repos?

<mark_weaver>ng0: core-updates contained a lot of unsigned commits, from before it was our policy to require them. trying to merge that branch then failed

<ng0>i see. okay

<mark_weaver>another issue is that maybe the commit hook only enforces signed commits on the master branch, and not on other branches, so this problem is likely to crop up again.

<mark_weaver>the most recent unsigned commits on core-updates are only 4 days old, which I think is after we added the commit hook on master

<mark_weaver>we're likely to run into the same problem with core-updates-next, assuming that it has unsigned commits (I haven't checked)

<catern>when compiling a simple C program I get: ld-wrapper: error: attempt to use impure library "/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/libgcc_s.so"

<catern>what could the problem be?

<rekado>catern: are you using "gcc-toolchain"?

<rekado>when compiling with the Guix GCC none of the system libraries should be considered.

<catern>rekado: yes

<rekado>I suggest checking the environment variables

<catern>hm, which ones?

<rekado>for best results compile in a pure environment created by "guix environment --pure ..."

<catern>ah but that's such a nuisance...

<rekado>well, but otherwise it's very hard to ensure that the compiler doesn't see libraries it cannot possibly use.

<ng0>C_INCLUDE_PATH , CPLUS_INCLUDE_PATH i think

<rekado>that's just for headers

<ng0>LIBABRY_PATH ?

<rekado>there's also LIBRARY_PATH and LD_LIBRARY_PATH

<mark_weaver>catern: you must ensure that when compiling things, you either use *only* toolchain/libraries from Guix, or *only* toolchain/libraries from your host OS. mixing them will lead to problems like this.

<paroneayea>hello #guix!

<catern>LIBRARY_PATH looks fine, LD_LIBRARY_PATH is unset (but setting it to $LIBRARY_PATH has no change)

<rekado>catern: don't set LD_LIBRARY_PATH.

<catern>okay

<paroneayea>holy moly

<catern>C_INCLUDE_PATH and CPLUS_INCLUDE_PATH are both fine

<paroneayea>the git graph in guix right now is intense :)

<catern>mark_weaver: hmm, what library am I missing from Guix, then?

<paroneayea>|\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ;)

<ng0>guitar hero ^^

<catern>the gcc package should have libgcc_s.so in it, right?

<rekado>catern: yes. Are you sure you're using GCC from Guix?

<catern>aaaaaaaaaaaaaaaaaaaaaaa

<catern>I see the issue :)

<catern>I was running make, and make was running "cc" not "gcc" :)

<catern>and cc is pointing to a program on my host

<catern>easily fixed!

<catern>actually, what is the best way to fix that?

<jlicht>set the CC env variable?

<jlicht>or using a makeflag perhaps ;-)

<rekado>catern: depends on the Makefile

<catern>well - I'd rather have things work without configuration - so I'd rather that there be a "cc" entry in the guix binary directory

<catern>I definitely won't modify this specific Makefile in any case, I'd rather fix the problem at the source :)

<catern>since make defaults to using cc

<catern>(afaik?)

<rekado>you don’t need to modify the Makefile.

<rekado>in some cases it’s enough to do “make CC=gcc”

<catern>well, for now I'm just going to ln -s ~/.guix-profile/bin/gcc ~/bin/cc as that seems easiest, but I'd rather there was already a ~/.guix-profile/bin/cc as that would make make work by default

<civodul>Hello Guix!

<jlicht>Hello civodul!

<jlicht>how can I get patch-shebangs to apply to also apply to a file which is not in <output>/bin or <output>/sbin

<civodul>ACTION looks

<civodul>the list of directories scanned by the 'patch-shebangs' phase is hardcoded

<civodul>we should fix that

<civodul>but in the meantime, you could add a phase that does what you want

<civodul>basically mimic the 'patch-shebangs' phase from gnu-build-system.scm

<civodul>WDYT?

<civodul> http://news.softpedia.com/news/guix-system-distribution-0-11-uses-linux-libre-kernel-4-7-supports-raid-devices-506950.shtml

<jlicht>civodul: seems agreeable.

<jlicht>Your fix regarding the use of lstat in patch-shebangs and the particular fix for the node npm symlink you once pushed seem to not like eachother ;-)

<mark_weaver>civodul: did you see my recent emails about the core-updates merge issue?

<mark_weaver>iiuc, unsigned commits can get into branches other than master, which effectively makes those branches unmergeable into master.

<mark_weaver>details in the emails

<mark_weaver>we'll likely have the same problem merging 'core-updates-next' later

<mark_weaver>the commit hook rejects merges from branches that contain unsigned commits, even if the most recent commits, and the merge itself, are all signed.

<civodul>mark_weaver: i haven't checked mail yet; will do!

<civodul>jlicht: if there's a problem in this area, could you report it to the mailing list? i'll be away from keyboard soon

<ng0>484 new packages in 4 or 3 months is a good number for us small number of people

<civodul>mark_weaver: so you managed to redo the merge commit, right?

<mark_weaver>civodul: yes, but only because nully came to the rescue, and disabled the gpg check for a few seconds while I pushed the merge

<civodul>mark_weaver: yes; a big thanks anyway!

<civodul>i didn't even consider this option, because i thought it would be too tricky

<civodul>so i'm glad you succeeded, that was the right thing to do!

<mark_weaver>the thought of rewriting the entire core-updates history was too terrible to consider

<mark_weaver>especially with all those merges, etc.

<ng0>wee... the segfaulting must be something with torsocks. i need to report that one bug perl fixed and told me it needs to be reported to torsocks... so there's one more bug in addition

<ng0>i can not torify, i can not torify git

<ng0>which worked before

<ng0>but i can torify getmail

<ng0>torify and torified shell i mean

<rekado>ng0: have you tried debugging with gdb?

<ng0>i need the :debug outputs for human readable output, right?

<ng0>or do the normal builds install symbols and code to debug? I found the manual not so good in that section when I last read it

<mark_weaver>ng0: if the package specifies a "debug" output (via the 'outputs' field), then the default phases of gnu-build-system will put the debugging information there. otherwise, it gets stripped.

<mark_weaver>ng0: at present, we only provide "debug" outputs for relatively few packages.

<ng0>oh. that's too bad.

<mark_weaver>adding a "debug" output to a package will force a rebuild of all dependent packages

<ng0>wait i did not read it all

<ng0>ah .. okay.. it is

<mark_weaver>it would probably be good to add "debug" outputs to a bunch of libraries in a future core-updates cycle.

<ng0>why do we strip this? diskspace on current hydra?

<ng0>did ircii really cut out emacs? or did i not write emacs? strange

<ng0>nope

<mark_weaver>ng0: are you asking why "debug" is not included as an output to all packages by default?

<ng0>so torify is just a script. gdb --args torify $application does not work

<ng0>yes

<ng0>i know it increases space and compiling time.. i have my whole gentoo system running with debug default

<mark_weaver>well, that would lead to empty "debug" outputs for packages with no C code, e.g. python/ruby/perl packages.

<ng0>right

<mark_weaver>I think it's probably cleaner to get in the habit of adding "debug" outputs where appropriate

<ng0>okay

<mark_weaver>it's true, though, that hydra disk space is currently an issue there.

<civodul>ng0: yeah, the justification is at the bottom of https://www.gnu.org/software/guix/manual/html_node/Installing-Debugging-Files.html

<civodul>maybe we should revisit it someday

<civodul>s/maybe/probably/ :-)

<ng0>this is not very helpful either: https://github.com/dgoulet/torsocks/blob/master/doc/notes/DEBUG (old source though, moved to torproject.org)

<ng0>i think i know why it fails..

<ng0>torify is now just a wrapper around torsocks(1) for backwards compatibility.

<ng0>i get when torify --help

<ng0>i'lladjustmy scripts and see if I still get segfaults

<ng0>problem is, i used . torsocks on; .... ; . torsocks off; .. which should just work as before

<ng0>segfaults too. so i really need to debug torsocks

<mark_weaver>ng0: thanks for working on ti

<mark_weaver>*it

<ng0>torproject is on oftc, right? i don't want to address the devel mailinglist with asking for how to debug torsocks

<ng0>torsocks -d is not helpful for my test cases

<mark_weaver>ng0: is torsocks a C program? can you run it in gdb?

<mark_weaver>tor on oftc sounds right to me, but I'm not sure

<mark_weaver>you could also enable core dumping and then use gdb to look at the core

<ng0>there this (https://rt.perl.org/Public/Bug/Display.html?id=128740) which pointed out that torsocks has at least one problem.

<ng0>how do i enable core dump? i just used gdb and valgrind alone so far

<mark_weaver>in bash, "ulimit -c unlimited" will enable it for subprocesses

<ng0>okay.. thanks

<mark_weaver>(resource limits are inherited from parent to child processes, like environment variables)

<mark_weaver>and then "gdb <program> <core>" for post-mortem investigation

<ng0>is this something where i need/can restore a default afterwards, the ulimit?

<paroneayea>ACTION reads the mailing list

<paroneayea>eep, I should be using epiphany? :\\

<mark_weaver>ng0: ulimit -c 0

<mark_weaver>paroneayea: yes, unfortunately :-(

<paroneayea>is it time for us to just ship firefox?

<mark_weaver>it's not a bad browser, although I very much miss things like cookie and javascript filtering

<mark_weaver>paroneayea: firefox steers users to non-free software (e.g. plugins), so we cannot include it

<paroneayea>ok, well

<mark_weaver>it violates the GNU FSDG

<mark_weaver>what we really need is more developers working on IceCat, I think

<paroneayea>yeah but I'm not confident when that's going to happen, even though I really admire the project

<mark_weaver>which is basically just Firefox with many freedom/privacy issues addressed

<paroneayea>in the meanwhile, maybe it's time for an OOB repo with firefox in it

<ng0>there's torbrowser.. which should be compatible. but i don't know enough about all the contained licenses, just a general overview and what i wrote on the list

<ng0>but it's restricted to tor usage.

<paroneayea>there are some things I don't trust doing over tor

<mark_weaver>iirc, torbrowser also steers users to non-free software, e.g. plugins, no?

<ng0>idk..? check the licenses

<mark_weaver>torbrowser has a mode that bypasses tor, to deal with captive portals (e.g. at coffee shops)

<paroneayea>it's not a licenses issue in this case

<paroneayea>well not directly

<ng0>i found no obviously vioalting plugins, only the store

<ng0>which can be patched away easily

<ng0>and other minor profile stuff

<ng0>and torsocks is just a script i think:

<ng0> /home/ng0/.guix-profile/bin/torsocks": not in executable format: File format not recognized

<mark_weaver>ng0: the issues (as I vaguely recall them) include: (1) firefox steering users to a catalog of addons that include non-free software, and (2) suggesting that users install non-free codecs and plugins when they try to watch videos, etc.

<ng0>1) is easy addressed with patching, 2) also

<mark_weaver>and that's exactly what IceCat does.

<ng0>but icecat lags behind

<ng0>torbrowser has enough developers

<ng0>also there are individual addons to torbrowser

<ng0>til.. torsocks is a bashscript

<mark_weaver>here's what I don't understand. people are saying that contributing to IceCat development is too much, and then they propose as an alternative to do the exact same work, but not in the IceCat project.

<mark_weaver>torbrowser has enough developers, but they have different goals. they are not doing the job we need.

<ng0>I could get in touch with the icecat developer, but i don't feel confident enough in firefox sources to do direct development in it, i only know how to build and patch things there

<ng0>plus time limits

<mark_weaver>IceCat should probably be based on TorBrowser, since that group is doing a lot of what we want, but not all.

<mark_weaver>and then we could just add the relatively few patches needed to deal with the freedom issues.

<ng0>i had this discussion with someone in the past.. talk to torproject and make them address the freedom issues

<mark_weaver>sure, that would be even better, if they are willing

<ng0>lead to no action so far as I lost track of doing it

<ng0>maybe someone more experienced in such discussions could do it

<ng0>torsocks is weird.

<mark_weaver>anyway, I agree that in the short term, adding torbrowser to Guix with the freedom issues addressed via local patches would be a good next step

<mark_weaver>and then perhaps I can propose to GNU to make this the new model for IceCat development.

<mark_weaver>clearly, IceCat has serious issues, and GNU will want to find a solution

<mark_weaver>I have to go afk. happy hacking!

<ng0>a discussion to point to which shows torprojects torbrowser developers positions and outcome of addressing issues would be useful for this i guess?

<ng0>urgh. everybody switches to letsencrypt who was running their own CA before.. oftc now too

<ng0>genious. no more tor at oftc or temporarily.

<demotri>ACTION rebooted into Guix for the first time after installation (in Qemu)

<myglc2>hello guix!

<demotri>Gg-

<ng0>yay, more splitting off.. why not improve upstream docs >.< http://stackoverflow.com/tour/documentation

<obarun>hello, how i can make a bug report about compilation issue of guix source package?

<obarun>i mean where i can post

<roptat>hi, I am trying to follow the instructions there : https://www.gnu.org/software/guix/manual/html_node/Building-from-Git.html#Building-from-Git

<roptat>I am in the environment (guix environment guix --ad-hoc git)

<roptat>but ./bootstrap doesn't find autoreconf

<roptat>I thought guix environment would add it in the environment

<roptat>I'm running GuixSD and the command was run as an unpriviledged user

<civodul>roptat: you may have to run 'guix pull' first if you just installed from 0.11.0

<obarun>according to the last commit on git repo the files /packages/zsh.scm was removed but the entry at guix/po/packages/POTFILES.in is always there and call to zsh.scm, so the build fail :)

<obarun>a simple sed do the stuff but ....

<roptat>civodul, if I do guix pull as root, does it update guix for everyone?

<civodul>roptat: no, it's per-user

<civodul>obarun: oh indeed

<civodul>mark_weaver: ↑ could it be that something went wrong with the re-merge?

<ng0>alright, torsocks reported upstream, lets see how it works out. I'll search their trac now for eventual discussions on freedom issues and torbrowser, see if someone tried to address this before

<ng0>there are so many tickets.. some are usable, but the keyword i search for now returns so many results i should just address the tor devel list

<ng0>hu. i compared to torsocks-2.2.0-rc1 on my gentoo with a torsocks'd git fetch, and it seems my problem is directly related to the perl5 bug

<ng0>if i only knew more about torsocks to hack and patch it

<civodul>obarun, mark_weaver: i've fixed the POTFILES.in issue in master

<ng0>i see i missed a file in my commit which fixed part of that. thanks

<sapientech>using python2.7 from guix, and getting an issue with python2-pygtk: glib/_glib.so: undefined symbol: PyUnicodeUCS2_DecodeUTF8

<sapientech>online, people are saying that the interpreter is not compiled with the same settings as the binary extension

<ng0>can i address the guix-devel list so that people can review what I plan to open as one or multiple (child) trac tickets on trac.torproject.org regarding freedom issues? Or to decide wether trac or tor-dev ML is to be addressed.

<sapientech>update: looks like i was actually using my systems python2, using an environment to check...

<mark_weaver>civodul: I ran "git diff origin/master master" before pushing to verify that no files were changed by the combination of commits I did.

<mark_weaver>but I'd encourage someone else to double-check that, in case I made a mistake

<ng0>Can someone review my libextractor patch if it requires some more changes?

<rekado>sapientech: yes, this usually means that you’re mixing system python with Guix libraries or vice versa.

<cmhobbs>are there any tiling wm packages in guix yet?

<bavier`>cmhobbs: a few, bspwm, awesome, etc

<ng0>cmhobbs: see latest bug I opened on this and closed again

<cmhobbs>ng0: link?

<ng0> http://lists.gnu.org/archive/html/bug-guix/2016-08/msg00025.html

<cmhobbs>i use i3 at the moment but i'm probably going to start testing guixsd in a vm at work

<cmhobbs>ng0: thank you

<ng0>We should actually list those WMs and DMs somewhere.. maybe

<cmhobbs>yeah, maybe

<ng0>those all appeared while searching for either manager or window manager i think. gnome also included.. not sure about xfce. one search which would find them all.

<ng0>or just listed in a visible place.

<ng0>where does "mar-tools" originate on mozilla? is there an upstream ulr?

<ng0>*url

<civodul>mark_weaver: ok, nice; i quickly checked and didn't see any obvious issue

<roptat>I am trying to write a new service for openssh, so I wrote it in gnu/services/ssh.scm in my git clone. I ran make, but now, how can I test it?

<ng0>roptat: you can try it in a testvm

<ng0>with.. i need to get back to testing my git service, i had it there how to test it. ./pre-inst-env guix ..commands-for-vm-i-forgot.. /path/to/system.scm which contains the testvm with the ssh service

<roptat>ok, thanks, I'll try it

<civodul>roptat: yeah, "./pre-inst-env guix system vm test-config.scm"

<roptat>I get "Unbound variable: openssh-service"

<civodul>make use to add (use-service-module ssh) in the config

<roptat>it's already present

<ng0>did you export it?

<roptat>probably not

<roptat>that was the problem, thanks :)

<civodul>cool :-)

<ng0>I will send the torproject request for edits etc email later to our list, there might be a better one, but we talked about it here and my stress level can not afford to subscribe to more mailinglists than necessary which might or might not be impossible to catch with tagging.

<bavier`>just packaged aircrack-ng

<ng0>cool

<bavier`>and it even builds with '--rounds-3' :)

<bavier`>s/rounds-/rounds=/

<ng0>civodul, what do you consider a frustrating situation? (re: member request savannah)

<civodul>ng0: i guess each one of us has their own definition of that

<civodul>my comment was meant to suggest that we don't want anyone to have that feeling

<ng0>i understand. okay

<ng0>one expression of frustration for me is where #355355 in Gentoo lead. it was one of the things turning me away from Gentoo, the ignorance, inability to talk about problems, get no clear feedback, and in the end the clear separation between official appointed developers and out-of-tree developers like the collaborative I work with.

<ng0>this is nothing i have encountered so far in guix.

<civodul>ok, i see

<ng0>i think i bring this bug up so often because it's the thing which annoyed me the most in trying to build guix on gentoo. then you fix it out of tree, try to upstream to portage, positive reaction at first, and then somebody rolls over you and the talk with the other people like a tank and all questions remain unanswered

<civodul>this is not a feeling that we want to see anyway, but could happen if we don't pay enough attention

<civodul>yeah

<ng0>this really hit me hard, the ignorance towards contributions... I withdrew my intentions to become a gentoo dev and limit what I do to our gentoo overlay

<ng0>"not all gentoo devs.." but every one who doesn't step in (in fact I got even called out with someone else to "stop making drama") on this supports it. and their council seems pointless from discussions I followed, some leadership problems in gentoo. Well, i don't want to drag this here. there's this large thread on the guix-devel list i wanted to add my replies too but it kept growing so it's hard to add to that. as long as we can discuss, have open discu

<civodul>yeah that thread was pretty long :-)

<civodul>but sure, we need to pay attention to these things, so people should not remain silent

<ng0>i have a draft reply, but it will not be in the tree of the discussion i guess, i can't fix a point where to insert it.

<ng0>there's not much to add but my perspective and view on some of the things said

<ng0>Reported: 2011-02-17 20:25 UTC. Closed: 2016-08-04 20:38 UTC (Resolved).

<ng0>hopefully we don't beat that in a bug time

<civodul>heh

<civodul>ACTION -> zZz

<civodul>later!

IRC channel logs

2016-08-04.log