IRC channel logs

2018-06-08.log

back to list of logs

<kmicu>( ^_^)/
<nckx>Hi!
<pkill9_>hey
<Copenhagen_Bram>Hey pkill9_
***samis is now known as CompanionCube
<Copenhagen_Bram>Where can I get news of new guix packages?
<pkill9_>Copenhagen_Bram: http://git.savannah.gnu.org/cgit/guix.git/log/?qt=grep&q=gnu%3A+Add
<pkill9_>ooo Xonotic got added
<Copenhagen_Bram>Ooh :o
<Copenhagen_Bram>Will xonotic run on an Intel GMA 4500MHD?
<pkill9_>probably, it's really light, and it lets you disable a lot of graphical effects
<Copenhagen_Bram>Ah. I'm hoping that Guix is more stable than Parabola, in that I will no longer have the problem where opengl games will play at an acceptable framerate if played shortly after booting up, but then will slow down drastically, making me play low-graphics games such as Cataclysm DDA and wesnoth
<Copenhagen_Bram>Has anyone else gotten that issue, or am I the only one?
<pkill9_>I'm not sure if i've had that issue
<pkill9_>actually I have had that issue
<pkill9_>actually i'm not sure
<baconicsynergy>hello friends
<baconicsynergy>hi sneek!
<baconicsynergy>roptat, I'm attempting guix on android again. lets hope things go well!
<baconicsynergy>lineage 15.1
<baconicsynergy>roptat, will the /etc/protocols and /etc/services be different from guixsd from trisquel?
<baconicsynergy>or do I need to push /etc/protocols and /etc/services from a guixsd machine
<baconicsynergy>I'm not sure if/how /etc/protocols and /etc/services vary from distro to distro
<Copenhagen_Bram>Hey baconicsynergy
<baconicsynergy>hey Copenhagen_Bram
<Copenhagen_Bram>damn, pkill9 left before I could ask him about his issues to compare them with mine
<baconicsynergy>ugh. another failure.
<baconicsynergy>"ERROR: In procedure getaddrinfo: Temporary failure in name resolution"
<baconicsynergy>even with resolv.conf having 8.8.8.8 and 8.8.4.4
<baconicsynergy>i give up
<baconicsynergy>I was successfully downloading so many substitutes from hydra. I don't know why it just stops working after 10 or so packages
<baconicsynergy>i thought for sure it would work this time
<baconicsynergy>it was working so well this time
<Copenhagen_Bram>Are there third party guix repos, like portage overlays or arch AURs?
<soundtoxin>is qute fixed yet? I'm about to run updates
<soundtoxin>hangouts chat doesn't work in icecat (never has for me, can't send things for some reason) so I usually use qutebrowser as a backup
<Rukako>isn't hangouts non-free?
<soundtoxin>well the problem occurs with librejs and all similar addons disabled
<soundtoxin>not sure why it wouldn't act like regular firefox in this scenario
<brendyn>guix pull fails for me with: http://paste.debian.net/1028416/
<efraim>brendyn: one of my machines fails the same way, we're looking for a known good hash still to point people to
<brendyn>efraim: I'd have to build from git? I'm having trouble with that also. After running guix environment guix, running make clean tells me aclocal is not available
<brendyn>i thought guix environment guix ensured everything to build guix was made available.
<efraim>try commit e13240f598d8e89eeb1fbf34fd94f49d6bf0b7a4
<efraim>hmm, nvm, i couldn't update from that commit to head
<Rukako>/run/current-system/profile/bin/ld: cannot find crt1.o: No such file or directory
<Rukako>w-what should I do?
<Rukako>I am on gcc 7.3
<Rukako>it also shows the same error for crti.o
<Rukako>nevermind, needed me to log-out after installing glibc
<civodul>Hello Guix!
<efraim>hi!
<Rukako>hi!
<civodul>hey hey, it's Friday! :-)
<rekado_>Hi civodul! Happy Friday!
<civodul>heya rekado_!
<civodul>i'm head-down trying to finish a patch set that was supposed to take me a couple of hours
<civodul>and which has taken me a few days already
<civodul>bah!
<rekado_>加油!
<rekado_>(exclamation of encouragement)
<civodul>i'll have to trust you :-)
<civodul>"FULLWIDTH EXCLAMATION MARK", interesting
<rekado_>(it literally means “add oil/fuel”)
<rekado_>here are some more: ,。:、
<rekado_>;?「」
<YoungFrog>is it "!" which means "add oil/fuel" ? or the whole "加油!" ?
<YoungFrog>(oh hi, I'm new here)
<brendyn>The chinese means that literally
<civodul>the FULLWIDTH codepoints are interesting, because the difference with the non-FULLWIDTH variant is pretty much the same you'd have between two different Latin font faces
<civodul>when looking at the glyphs
<YoungFrog>Thanks brendyn. So the exclamation mark really is nothing more than an exclamation mark ;-)
<brendyn>YoungFrog: yet
<brendyn>yep
<rekado_>fullwidth ensures that they take up the same space as other characters, so you can line up everything nicely in a grid.
<rekado_>YoungFrog: welcome to #guix!
<Rukako>rekado_: is it like monospace but by default or something?
<brendyn>It's what you use if your typing chinese
<rekado_>Rukako: I guess monospace is like fullwidth characters :)
<YoungFrog>Rukako: yes, but without having to say which font to use. also it is wider than your usual Courier New
<Rukako>good to know!
<YoungFrog>rekado_: thanks
<roptat>hi guix!
<g_bor[m]>roptat: Hello!
<soundtoxin>anyone here use mpd? mine doesn't work. might be a pulse issue, not sure. I think I discussed it here a few weeks ago, but I have been ignoring it and playing music another way lately.
<soundtoxin>ncmpcpp connects to mpd, but when I attmempt to play a song it's stuck at 0:00 and there's no sound
<civodul>heya roptat!
<roptat>soundtoxin: I don't use mpd, but is there any error message that could be useful?
<roptat>like maybe there's something in /var/log?
<civodul>looks like Bash completion broke for me when i switched to the post-merge master
<civodul>is anyone else seeing this?
<Rukako>my systemd thing for shepherd works somewhat now \\o/
<g_bor[m]>civodul: Unfortunaltely I'm not there yet.
<nee`>soundtoxin: I never managed to make mpd work with pulse on any distro, only alsa and http streaming, but http streaming has an annoying command latency for desktop usage.
<soundtoxin>I've had pretty good luck in the past with and without pulse
<soundtoxin>roptat: I'll take a look.
<roptat>hey, now there's a patch that allows us to use the pulse plugin for alsa
<roptat>so maybe you can make mpd use alsa with the pulse plugin?
<soundtoxin>what should I look for in /var/log? there's nothing labeled mpd in there
<roptat>mh… the shepherd has a bad habit of not logging the output of the command it runs :/
<roptat>so if the service is not configured to log anywhere, it's lost
<soundtoxin>well, the problem is quite reproduceable
<soundtoxin>so if I can configure it and restart mpd, it should ehlp
<soundtoxin>s/ehlp/help
<roptat>I'll have a look at the service definition
<soundtoxin>I think last time I was getting help with this in here, someone had me use strace
<soundtoxin>I found this in my log "sudo strace -fo logfile -s 4000 herd start mpd"
<civodul>Rukako: excellent!
<soundtoxin>in my .bash_history I should say
<civodul>Rukako: please do send us a note on what you're up to on guix-devel
<roptat>soundtoxin: an easier way is to stop the guix daemon and run mpd from the command line while debugging
<civodul>ACTION posts the damn patch set
<soundtoxin>ah, like just run "mpd" instead of starting it with herd?
<civodul> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31755
<roptat>you'll have to find the mpd.conf in the store
<Rukako>I will be making a post along with the patch on the maling list once I fix a few more bugs, probably by tomorrow
<roptat>then "mpd --no-daemon <mpd.conf>"
<roptat>(that's the command that herd runs in the background)
<roptat>soundtoxin: that's just for debugging, so we know what's going on
<Rukako>civodul: does guix not use savanah for bug reports?
<jonsger>civodul: I already started packaging guile-sqlite3 for opensuse. a release (0.0.1) would be nice :)
<roptat>maybe you can add --verbose or something too
<Rukako>*savannah
<rekado_>Rukako: no, we just use bug-guix@gnu.org, which is backed by a Debbugs instance.
<civodul>jonsger: nice, thank you! and yeah, i'm still trying to get Someone™ step up to make a release :-)
<jonsger>I could make it, but I dont have really good understand of guile neither of sqlite and databases...
<civodul>thanks for offering anyway :-)
<civodul>nckx: i think 504be7db587d5ba2f5d777b45920f3f1229b7243 (bash-completion upgrade) somehow broke completion: it seems that none of the completion "plugins" are being loaded now
<civodul>any idea?
<g_bor[m]>Do we have a guide how to do patch review?
<roptat>g_bor[m]: I think there's only the checklist in the contributing chapter of the manual
<roptat> https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html#Submitting-Patches
<roptat>soundtoxin: any luck with your investigation?
<soundtoxin>no, got kind of sidetracked. I don't know how to find the config in the store like you said
<soundtoxin>if I run locate mpd.conf I get like 50+ results from the store
<g_bor[m]>Ok, so the policy is to do the same steps when reviewing, that you do when you are contributing. That makes sense. I just wanted to be sure, that there are no additional steps involved.
<roptat>soundtoxin: try ls /gnu/store/*-mpd.conf
<roptat>that should be enough :)
<roptat>(* corresponds to the guix hash)
<soundtoxin>two results
<roptat>so one of them is the one used
<roptat>the other should be an older version
<soundtoxin>oh yeah, I was doing a reconfigure and it failed on mumble
<soundtoxin>in case that's not reported as broken yet
<roptat>maybe ls -a will tell you which one is the most recent
<soundtoxin>good point
<soundtoxin>ugh
<soundtoxin>no
<roptat>otherwise, you can test both, it's not too many possibilities
<soundtoxin>-r--r--r-- 2 root root 219 Dec 31 1969 /gnu/store/dr01ql8wv1n1yl04qqg9ry4x00jnv1if-mpd.conf
<soundtoxin>-r--r--r-- 2 root root 219 Dec 31 1969 /gnu/store/grwdww3r00ir1n22p88gbda0j71dirq2-mpd.conf
<roptat>of course ^^'
<roptat>I'd say try with both, and paste any error message so we can help
<soundtoxin>what am I doing again? making changes to those files?
<soundtoxin>they're very similar already, they had a different port between them, so I'm making them match
<roptat>no, don't change anything in /gnu/store
<soundtoxin>oh okay
<roptat>we're trying to run mpd from the command line to catch any error message
<soundtoxin>oh I'm just putting their path as the config for mpd to run from?
<roptat>the guix service runs "mpd --no-daemon <mpd.conf>"
<roptat>exactly
<roptat>so you'll have to replace <mpd.conf> with one of these files and maybe add --verbose or something similar
<soundtoxin>wtffffff
<soundtoxin>it just works
<roptat>mh…
<roptat>maybe it's a user permission?
<soundtoxin>exception: bind to '0.0.0.0:6600' failed (continuing anyway, because binding to '[::]:6600' succeeded): Failed to bind socket: Address already in use
<soundtoxin>I got this, but then opened ncmpcpp and the song played this time
<soundtoxin>what should I look into to find out if it's user permissions?
<soundtoxin>also, is it safe to delete the other store file? it had the wrong port in it
<roptat>actually the service is run as root, so it shouldn't be
<roptat>oh, maybe that's the file your current config uses?
<soundtoxin>maybe, but probably not because then ncmpcpp should complain about connecting to mpd, and it doesn't
<roptat>you can't modify the store, it would break guix badly
<soundtoxin>I can view my library and add songs which requires a connection
<soundtoxin>okay I won't touch it
<roptat>the only way is to use guix tools to modify the store, like "guix gc" to remove whatever is not used by anything
<roptat>ok I see... strange
<roptat>can you start the herd service again and try to listen to some music?
<roptat>kill the mpd you ran from the cli first
<soundtoxin>yeah I'll give that a go
<soundtoxin>okay, after a 'sudo herd start mpd', the problem is back
<soundtoxin>also I did 'sudo guix gc' and there are still two mpd.conf files...
<roptat>I think the log is in /var/run/mpd/mpd/log
<roptat>soundtoxin: one of them must be used by an older generation of your system
<roptat>can you have a look at /var/run/mpd/mpd/log?
<soundtoxin>exception: bind to '0.0.0.0:6600' failed (continuing anyway, because binding to '[::]:6600' succeeded): Failed to bind socket: Address already in use
<roptat>is that all?
<soundtoxin>and in case it matters, it was /var/run/mpd/myuser/log
<soundtoxin>or at least there wasn't another folder besides the one names after my user
<roptat>you're overwritting the user field in your configuration?
<soundtoxin>yeah I think so
<soundtoxin> (mpd-configuration
<soundtoxin> (user "brad")
<soundtoxin>yeah
<roptat>ok
<roptat>I'm so confused, it doesn't make any sense :/
<soundtoxin>well, for now I can use another player or specify the config from the store to use I guess
<soundtoxin>if you think of anything, let me know
<roptat>I think the only difference is the environment, but I don't know very much how mpd works so I can't help you
<soundtoxin>oh, in case it's relevant, I've got 29 days of uptime
<soundtoxin>and have been updating periodically
<soundtoxin>so if a reboot was needed, maybe that's related
<roptat>if you can reboot, please try it, otherwise you can stop the mpd service, reconfigure and try again
<roptat>when a service is running, the shepherd doesn't always reload it with the new configuration
<soundtoxin>I know I've kill mpd and restarted it several times and updated several times since I first had the issue
<soundtoxin>I'm attempting a guix pull + reconfigure now but I can probably reboot in a bit
<soundtoxin>I've also got a pulse issue where on boot pulse is running, but it doesn't work and pavucontrol can't connect to it and such. I think just killing pulse and then opening an application that uses it, such as pavucontrol, was how I was getting around that
<soundtoxin>and the pulse issue could maybe be related to the mpd issue
<roptat>ok, if that doesn't solve anything, can you send a bug report to bug-guix@gnu.org?
<soundtoxin>sure
<roptat>thank you :)
<civodul>ACTION has a fix for Doxygen on ARM \\o/
<civodul>regarding the "guix pull" invoke-error? bug, i really don't have a better idea than upgrading in two steps
<civodul>and the problem is that users have no way to discover the workaround
<civodul>in the event this happens again, perhaps we should somehow piggyback information about workarounds in Git commits
<civodul>such that 'guix pull' can automatically do the multiple-step thing
<civodul>dunno
<roptat>civodul: interesting idea
<roptat>but once we discover such a bug, isn't it to late?
<roptat>too*
<civodul>in this case it's too late for users who are using guix before that specific commit
<civodul>it's ok for those who are above that commit
<civodul>so, if you could communicate to guix pull that the upgrade requires at least commit X, then it could arrange to do it in multiple steps
<civodul>not sure exactly how to do that
<civodul>nor whether it's really a good idea :-)
<roptat>I think it's a good one
<roptat>it means users are not left behind
<rekado_>we could record this information in the repository.
<rekado_>A file that would be fetched by guix pull and evaluated.
<rekado_>this would require that Guix version hashes can be sorted.
<rekado_>then a pulling Guix could evaluate the file giving its own version as an argument and be told how to upgrade.
<efraim>do we know which one is a good stepping-stone commit?
<thomassgn>catonano: read your blog about gnu&guix and also the one on autotools (the one referencing g-golf and skribilo). alot of agreement is here together with me. Also I agree a lot. :) It's hard to remember the worst parts of the things you use/make/work on, but it's oh so important. Thanks for pointing at it.
<civodul>rekado_: instead of an actual file, i was thinking of specially-formatted commit logs
<civodul>an empty commit whose log provides that kind of info
<civodul>that requires the ability to determine whether you're behind a given commit
<civodul>Git can do that in general, not sure how easy it is with libgit2/guile-git
<civodul>thomassgn: URL? :-)
<civodul>bah, 'guix system disk-image --format=iso9660' includes more than the OS
<civodul>like QEMU and all
<civodul>no wonder we have big ISOs ;-)
<rekado_>wha?
<civodul>yup
<OrangeShark>civodul: I think that was the blog post catonano posted awhile ago on the mailing list
<civodul>rekado_: but the database is correct, which means that 'guix gc --list-dead' lists QEMU & co.
<civodul>OrangeShark: ooh, i must have read it "back then"
<OrangeShark>civodul: I think you even replied to it :)
<civodul>OrangeShark: bah, i have too many bugs and features on my mind i suppose :-)
<civodul>speaking of which, i've just fixed a couple of bugs, which makes my day
<catonano>civodul: yesterday I posted a new post and a thread ensued on the guix dev mailing list :-)
<catonano>civodul: here: http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html
<civodul>ACTION is tempted to stop reading at "Now for the bad part" :-)
<catonano>this is the Conversations ap on my phone. I configured it to access this grroup and it keeps going on line and off line, I'm not sure exactly why
<OriansJ`>catonano: honestly, that post gave me a moment of reflection. Made me wonder if I am doing everything I should to ensure #bootstrappable is a healthy group environment for the guix bootstrapping work. We have been making good progress but I wonder why so few join. Is it the technical difficultly of the work or is it something we can improve.
<catonano>OriansJ`: I never visited the #bootstrappable community. So I can't say. I'm glad that you considered the problem, though. There's not so muchh that I can do more than ensue debate and reflection
<catonano>OriansJ`: you can surely start by using more emojis :-)
<OriansJ`>noted :-D
<catonano>OriansJ`: maybe it won't hhelp but it surely won't hurt either :-)
<thomassgn>civodul: Picked it up from the ML. http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html
<thomassgn>I should learn to read :) didnt see the responses.
<OriansJ`>thomassgn: I guess this is going to be something we think about and discuss for a while; til we all reached what it means to us.
<thomassgn>indeed. I keep seeing more and more of very positive signs though. Both in inclusion/diversity and in "empathy"(as a catch-all for a lot of closely related things). Been reading a few of the 'compassionate coding' and April Wensels posts (2 of them are linked to from catonano's post).
<thomassgn>I am a bit afraid of taking these though: https://implicit.harvard.edu/implicit/index.jsp It's a measurement of implicit prejudices. I know I have them, not sure how much though. It's difficult seeing yourself I think :)
<OriansJ`>thomassgn: I feel it is a bit like discussions about improving the environment. Everyone prefers to live in a clean and pastoral environment but there is a level which is too far for the population to accept (Who likes collecting their own poop?). So we need to on one hand be decent to each other but realize just like evironmentalists that some people like to eat meat and throwing paint on them isn't going to improve the world.
<OriansJ`>As for the topic of implicit prejudices, I would like to point out that is not actually a bad thing. For example, it is generally implicity assumed that all technical discussions on this channel were in English; even though a large chunk of the people here certainly do speak other languages (some of them even did some wonderful translation work); it is just a biological side effect of group selection theory. In group behaviors good and
<OriansJ`>excusable, outgroup behaviors bad and unforgivable.
<OriansJ`>We need to remember that generally everyone here is trying to help and trying to reach reasonable common ground is the hardest problem ever faced.
<OriansJ`>We all make mistakes, we all have bad days and sometimes we say the wrong things because we didn't stop and think about the other people reading our words. But that is the great thing about good communties, they help all of us become better people. We grow together, learn together and change the world for the better together.
<civodul>ACTION is in patch-application mode
<thomassgn>OriansJ`: +1, agreed.
<thomassgn>I used to, and will soon again be, collecting my poop. No stress, and if you do it right, no smell or other nastiness. :)
<thomassgn>just a little tangent of your comment there, quite off topic.
<OriansJ`>thomassgn: well hopefully your organic vegatable garden does well, personally I am more of a fan of genetically engineered crop varieties mixed combined with engineered planting patterns to reduce pests and allow plants to do the soil enrichment. But the world is only made better when we learn from each other's sucesses and failures.
<rekado_>ACTION is in debugging mode
<thomassgn>OriansJ`: intriguing. Do you have any examples of this in practise? It seems like something I'll be disagreeing strognly with, but as you say, learn from eachothers success and failure. :)
<roptat>oh, interesting: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
<OriansJ`>thomassgn: well yes, it is a rather old technique. https://en.wikipedia.org/wiki/List_of_companion_plants and if you are into longer term improvements in human crop yield, you may wish to consider https://permaculturenews.org/2012/01/04/hugelkultur-composting-whole-trees-with-ease/
<bavier`>thomassgn: composting toilet?
<OriansJ`>thomassgn: the thing most people forget about GMO crops is that, it is just a technology, that if used correctly simply reduces the number of generations required to tune a crop species to a particular climate. But this sort of discuss I could pursue for hours and we probably should take it else where so we don't disrupt the channel.
<thomassgn>bavier`: yes. Just have enough dry carbon rich materials (bark, leaves, wood chips). The bad smell from basically any digestion/decomposing process is because a lot of valuable chemicals are escaping as gas; because it is lacking carbon to bind/change with. escaping nitrogenbindings smell like shit and are so incredibly valuable. :)
<thomassgn>OriansJ`: Yes, if we want to continue this thread we should probably find a different channel. I see your argument and have some perspectives on it, but some other channel would be better.
<thomassgn>it's not very important either. It's an interesting conversation to be sure, but I'm happy to have it at a different time or not at all. (:
<rekado_>thomassgn: bavier`: it can also help to separate feces from urine. There are systems designed to separate this early and store the two separately.
<rekado_>But that’s all I’m going to say about this on #guix
<rekado_>:)
<bavier`>rekado_: heh, indeed ;)
<efraim>Gotta keep that humanure separate until its been fully processed
<thomassgn>indeed, 3yrs is a good rule of thumb. You can do much faster (theoreticly down to 6 months), but no. And yes, maybe we need a #guix-homesteading channel :)
<OriansJ`>thomassgn: done, #guix-homesteading is now live
<bavier`>:)
<thomassgn>hahahahaha
<pkill9_>lol
<g_bor[m]>hello guix! Exim just failed building for me.
<g_bor[m]>Anyone else noticed this?
<g_bor[m]>On first look, it seems exim is missing libnsl as input.
<wigust->g_bor[m]: Hello. Yes, libnsl is missing. Could you add it and propose a patch, please?
<g_bor[m]>yes, will do.
<wigust->g_bor[m]: Thank you for a work on this and also the report.
<g_bor[m]>wigust-: is it ok to send this to patches?
<g_bor[m]>Or should it be bugs instead?
<wigust->g_bor[m]: guix-patches@gnu.org
<g_bor[m]>ok, done.
<wigust->g_bor[m]: Thank you, I'll look on it shortly.
***Copenhagen_Bram is now known as Linard_Stallvald
***Linard_Stallvald is now known as Linard_Starvalds
<kmicu>Do we have any articles for beginners about ‘what’s the difference between containers (Flatpak/Appimage/Snaps) and Guix’?
<kmicu>(You could also write your own answer (under 500 characters) here ;)
<civodul>heya kmicu
<civodul>we don't really have such an article, i think
<kmicu>( ^_^)/
<civodul>there are two articles about guix pack:
<civodul> https://www.gnu.org/software/guix/blog/2017/creating-bundles-with-guix-pack/
<civodul>and https://www.gnu.org/software/guix/blog/2018/tarballs-the-ultimate-container-image-format/
<civodul>but it's not quite what you're asking for
<kmicu>Yeah, they are too advance/complicated.
<civodul>the "related work" part of https://hal.inria.fr/hal-01161771/en sorta mentions this
<civodul>but yeah, not great either
<civodul>look, if you write such an article, i'm happy to put it on the web site! :-)
<wigust->I think it will be not fair comparison without ‘guix run’ script from https://lists.gnu.org/archive/html/help-guix/2018-01/msg00108.html ;-)
<civodul>heh, right, if you wanted to touch the topic of "security" :-)
<civodul>that said, the reason Flatpak/Snap insist on that is primarily because they're about shipping proprietary software
<kmicu>Such article would be useful too, but I am searching for an explanation under 500 characters. I find that task difficult. [Jokin’] I want to avoid ‘guix(SD) is a marvelous time machine that let us travel in time on a package manager (operating system) level, and a container is a bucket’.)
<kmicu>(Of course GNU TARDIS is much cooler than a bucket.)
<civodul>heh
<civodul>500 chars is really short, now that i think about it
<kmicu>(It is like explaining monads in a short social media post; which is possible when we want to be correct, but is not helpful for beginners at all.)
***Linard_Starvalds is now known as Richus_Torvman
<roptat>trying to build openjdk9, I got a segfault from gcc
<roptat>it used to work before the core-updates merge
<civodul>roptat: congratulations! you hit the ugly bug! :-)
<roptat>:/
<civodul>explanations & workarounds at: https://bugs.gnu.org/31708
<roptat>so I need to initialise every static const array?
<civodul>every static const array that's used as a source in memcpy and friends
<civodul>is it C or C++?
<roptat>C++
<roptat>and a large codebase
<roptat>do we have an idea how to fix the bug?
<civodul>uh
<civodul>roptat: you could do like Mark proposed in this bug, which is to add a dependency on a bug-free compiler
<civodul>or you could try to fix issues individually like i did for Doxygen and perf
<civodul>it may be that there will be only a couple of issues
<civodul>so i would tend to prefer the local fix, or at least try to do it that way
<civodul>now, in C++ it's more painful
<civodul>maybe give it a try for the first couple of issues that you find to see how hard it'd be?
<roptat>ok
<roptat>how far are we from fixing gcc?
<civodul>the fix isn't committed yet, but it's trivial
<civodul>however it's a full-rebuild change
<roptat>ok, so next year during the next core-updates merge? :p
<civodul>exactly :-)
<roptat>is the bug reproducible?
<roptat>it looks like it's taking longer to hit it
<roptat>ouch, the segfault is caused by a generated cpp file
<civodul>ouch
<civodul>the bug is 100% reproducible but in the Doxygen case it would trigger only on ARM
<bavier`>on my aarch64 system, I get a backtrace from `guix build texlive-tiny`
<bavier`>there's more to the story here, though, working on tracking it down...
<roptat>error: invalid in-class initialization of static data member of non-integral type ‘const Pipeline_Use_Element [11]’
<roptat>I'll try with another compiler
<civodul>you cannot add the initializer to the 'static const' declaration (which is in the class decl)
<civodul>which is why it's tricky in C++
<civodul>so the patch for Doxygen simply confuses the compiler so that it doesn't recognize the static const thing :-/
<pkill9>+1 support for `guix run`
<roptat>well gcc-6 will probably work
<civodul>yes but it lacks the patch in question, doesn't it?
<civodul>i mean, we need that patch, just without the bug
<roptat>civodul: what do you mean?
<roptat>ok, I didn't understand the issue ^^'
<civodul>roptat: that we need a compiler that has "gcc-strmov-store-file-names.patch" or a fixed variant thereof
<roptat>how can the bug affect all compilers?
<roptat>oh it's a patch we apply that causes it, right?
<roptat>I think I understand now
<civodul>yes, this bug is just for us
<bavier`>civodul: bootstrapping make on this system, I get "/dev/null: Permission denied" from 'configure'. I inserted "ls -l /dev/null" into phases, but the permissions seem fine: "crw-rw-rw- 1 0 0 1, 3 Jun 6 13:55 /dev/null"
<civodul>"bootstraping make", what do you mean?
<bavier`>sorry: building "make-boot0"
<bavier`>(@@ (gnu packages commencement) gnu-make-boot0)
<civodul>oh, ok
<civodul>are you using --disable-chroot?
<bavier`>no
<bavier`>just a non-standard storedir
<civodul>ok
<civodul>could you "strace -f" guix-daemon and restart "guix build ..." to see what happens?
<bavier`>just seems like the builders can't write to /dev/null for some reason
<bavier`>even a simple '(with-output-to-file "/dev/null" (display "hello"))' fails
<bavier`>ERROR: In procedure open-file: Permission denied: "/dev/null"
<civodul>what the daemon does is bind-mount /dev/null and similar files
<bavier`>civodul: strace might be helpful, yes, just have to get the sysadmin on board
<civodul>see build.cc:2137
<civodul>heh
<bavier`>will not be confidence-inspiring...
<civodul>bavier`: you inserted "ls -l" as a phase in gnu-make-boot0, right?
<bavier`>right
<thomassgn>anyone have qutebrowser fail to start because "QTWebEngine is required to run qutebrowser but could net be imported! Maybe it's not installed?" ? Started happening a few days ago here, but I hadn't updated in a long while.
<bavier`>thomassgn: known bug, unfortunately. qutebrowser doesn't like the current qtwebkit, and we don't have a qtwebengine package yet
<thomassgn>cool, was assuming something along those lines. Have seen some things about it earlier, but never paid attention. Might chip in later, just wanted to check now. :) Thanks