IRC channel logs


back to list of logs

<MouldySammich>Is it possible to load the ath10k drivers for networking before installation? Right now if i run ifconfig -a all i get is lo
<MouldySammich>Ah sorry never mind, the driver for my wireless has a blob :( sorry about that
<Apteryx>Hello Guix!
<Apteryx>I have a grub test failure (FAIL: grub_func_test). Has anyone else experienced it?
<Apteryx>This is happening for GRUB 2.02~rc1 which was brought in Guix 1 month ago.
<Apteryx>Could reproduce it.
<fps>thomassgn: are you thomasd?
<Apteryx>It's strange that grub 2.02~rc1 passes its functional test on hydra but not on my machine.
<Apteryx>Another similar scenario is python2-urwid still fails its tests for me, but passing on hydra.
<Apteryx>Does anyone know how to navigate C sources using C-. and C-, in emacs? It prompts for a TAGS file.
<slyfox>you need to generate TAGS file yourself. smetimes makefiles provide 'make TAGS' but if not you'll have to run etags
<Apteryx>slyfox: Thanks :)
<Apteryx>etags apparently comes with Emacs! Strange that it's not more "integrated".
<Apteryx>Any reason why we're disabling setuid for the man-db package? Also, I don't really understand what setuid is for.
<snape>Apteryx: actually, you may use GNU Global, which has a very good Emacs integration
<Apteryx>snape: OK! Thanks for the suggestion.
<snape>Apteryx: np :) And have a look at the ggtags frontend, too. It is not the default one, but I think it is the best.
<Apteryx>I'm finding that mandb doesn't form its search path successfully. I'd expect it to use MANPATH, but it doesn't. To force it to use it, one has to pass it as an argument: `mandb $MANPATH`.
<Apteryx>snape: OK :)
<Apteryx>Maybe it's by design. mandb(8) says: "Supplying mandb with an optional colon-delimited path will override the
<Apteryx> internal system manual page hierarchy search path, determined from
<Apteryx> information found within the man-db configuration file.
<Apteryx>Confusingly enough there's a message that says "mandb: warning: $MANPATH set, ignoring /gnu/store/spaz62a39nrgm274gvmwz529lhrrms4s-man-db-2.7.5/etc/man_db.conf".
<fps>thomaasd: about your comment regarding calculating dependency graphs: care to elaboratte on that a little bit?
<snape>fps: you meant thomasd
<thomasd>hi snape fps :)
<snape>hi thomasd!
<thomasd>fps: Maybe (probably) I still misunderstand your idea, but in the example from yesterday, where A depends on B, B is updated, so we have A' <- B'.
<thomasd>as I understand it, the idea is that, if A', modulo embedded PATHS etc turns out to be bit-identical to A (e.g. in case where B is a C library and B' is ABI-compatible with B), it could be detected and A' could be generated from A by "automatic grafting"
<thomasd>my comment was that such a thing is hard to predict in advance (i.e. without building B' and A' and checking the results), but AFAIU Guix must be able to calculate the dependency graph from the package descriptions alone,
<thomasd>so to conclude my monologue :-) : I think guix devs would have to keep track of ABI versions of packages, and embed this information in the package descriptions to make it work. Seems hard to to in an automated way.
<thomassgn>fps: no, not that I'm aware (:
<thomassgn>anyone has a current context install running on guixsd?
<snape>thomassgn: what is a "context install"?
<thomassgn>snape: context is a TeX compiler. It's packaged as part of texlive I think
<snape>ok, thanks for the explanation :)
<efraim>I have a fix for binutils-vc4 and wine on core-updates but it involves a patch for flex which is a dealbreaker
<efraim>i take it back, the patch didn't work
<civodul>Hello Guix!
<bavier`>hello civodul!
<rekado_>sneek: later tell lfam I pushed two fixes to core-updates: one for freeimage, the other for python-pysam (also pushed this one to master).
<sneek>Got it.
<efraim>I have binutils-vc4 fixed locally and I can push it as soon as I get home
<rekado_>I find the load path settings in cuirass confusing.
<rekado_>there’s a load path field for specs and also for the cuirass service itself
<rekado_>I’m trying to set up cuirass such that it fetches both Guix upstream and our custom git repo *together* and then build a subset of the packages
<rekado_>I don’t need anyone to spend time helping me with this just yet; it’s just that I’d like to state that I find this a little cumbersome to configure.
<lfam>Hm. I'm guessing the core-updates libressl failures have the same root cause as the earlier Python getentropy() failures: a poor interaction between old kernels and new glibc
<sneek>Welcome back lfam, you have 1 message.
<sneek>lfam, rekado_ says: I pushed two fixes to core-updates: one for freeimage, the other for python-pysam (also pushed this one to master).
<erliphant>what's the link between a package definition and the substitute location? How does guix determine the url for the substitute?
<lfam>erliphant: By substitute URL, do you mean the URL of the substitute server? Or something more specific?
<methalo>hi lfam, i'm trying fix fails for ustr package on core-updates, but the project appears hasn't been active since 2008!
<erliphant>lfam: I mean the actual path. I know that the substitute server can be provided to either the build command or the daemon but how does it work out what file to request from hydra or the guix publish server
<lfam>erliphant: I don't know the details, sorry :) I'd start by looking in 'guix/scripts/substitute.scm'
<erliphant>lfam: I've got a package in gnu/store but it's not served up by guix publish. I think I'm missing something
<methalo>lfam: i found a patch for the Debian project
<erliphant>lfam: thanks.. I'll take a look
<lfam>erliphant: On the client, are you using the exact same Guix version / Git commit as the one used to build the substitute?
<lfam>erliphant: It doesn't have to be *exactly* the same, but the full dependency graph of the package in question must match
<erliphant>lfam: good question, and I've done my best to make sure they are the same
<lfam>Did you authorize the signing key of the build machine on the client?
<erliphant>lfam: I've worked that out .. this prevents invalidation of the graph
<erliphant>lfam: yes. I am able to achive --export and --import between my boxes
<lfam>methalo: That patch may be our best bet
<lfam>methalo: Are you comfortable preparing a patch for Guix using that Debian patch and sending it to
<lfam>erliphant: I'm not sure. If nobody else chimes in here, I'd ask on
<quiliro>saluton liberojn
<methalo>lfam: i'll send!
<erliphant>lfam: thanks as always - much appreciated
<fps>thomasd: sorry, i read your remarks. i'm at a conference and attention is a limited resource.. :)
<fps>thomasd: well, it wouldn't be predicted in advance. you build A and A' and after the fact you find out that the binaries are bit identical [their core resulting in a single store key]..
<fps>but you stil graft the core into two separate output keys to keep dependency graphs intact..
<fps>but now think about disk space saved and bandwidth saved when shipping substitutes..
<fps>it doesn't save build times :)
<fps>[two output keys are necessary anyways, since eve though A and A' are bit identical, they are functionally different, since there might be differences in functionality lurking in B and B'
<fps>now let's say that B and B' also are bit identical cause one of their depencencies changed, but the ABI stayed the same, then you can derive A' directly without rebuilding it
<fps>and damn the tests in the guix build when installing from the guix installer image are annoyingly long
<fps>s/are annoyingly long/take annoyingly long/
<quiliro>i am angry at claws-mail
<quiliro>the main dev is rude
<quiliro>he said this to me: praise be god, praise be to RMS and the cult of GNU!
<efraim>I might have to send my test-suite.log to guix-devel, lots of failures on aarch64
<quiliro>why does reason sound as dogmatism when it is not the majority proceeding
<quiliro>the guy says he will help with a source compilation and not distro specific problems
<catonano>quiliro: did you try to use strace as rekado suggested in his email ?
<quiliro>i thought it was in the chat and i was looking at the history
<thomasd>catonano: someone should do the same for the gspell tests, maybe :-) Few days ago, I tried to look at the code (briefly), but didn't get how gspell creates its list of available dictionaries
<catonano>thomasd: did you see Ludo's update about gspell ?
<thomasd>yes (the one from 10 Mar)
<thomasd>It seems it gspell only uses input from iso-codes to build a list of dictionaries... I didn't get it at all. But I'll try strace one of these days :)
<quiliro>rekado_: answered your email
<thomasd>I've been meaning to reply to that thread, but have been struggling with e-mail :-) (Now I've decided I'll just use gnus to reply to debbugs threads)
<catonano>thomasd: we all struggle with email :-)
<catonano>thomasd: it became a bit too complicated for me. Anyway, I meant to try to packaage Polari, that's why I tried with gspell. But now II have been using weechat for a quite long time
<catonano>thomasd: i it's true that the env var ASPELL_CONF is not honored, then it's about fiddling with thhat autoconf thing and that frightens me
<quiliro>what packages do you suggesti installing to collaborate in making packages for guix with emacs editor?
<quiliro>i mean recipes
<quiliro>guix pack -i emacs
<quiliro>guix package -i emacs
<fps>hmm, while trying to install guixsd 0.12 on the metal it barfed out at installing grub complaining about my gpt partition table
<catonano>quiliro:guix package -i emacs-guix
<thomasd>fps: yes, I believe you need a bios boot parttion
<catonano>quiliro: take a look here
<davexunit>unfortunately our emacs integration was taken away
<thomasd>davexunit: you mean it's no longer part of guix itself? Because emacs-guix 0.3 works well for recent guix versions, I think?
<davexunit>thomasd: yeah
<fps>let's see if grub wants to do its thing after a guix pull first :)
<thomasd>fps: I think you'll still need a bios boot partition after `guix pull'... but you can always try :)
<fps>thomasd: i have one :)
<fps>it's /dev/sda1, should i point grub to that instead of /dev/sda?
<fps>ubuntu was so nice as to create one for me when i installed it a while ago [grmbl, mbr always worked fine for me ;)]
<thomasd>fps: (bootloader (grub-configuration (device "/dev/sda"))) should work, then...
<thomasd>(on my machine, the BIOS boot partition is also /dev/sda1)
<fps>ok, now that i have irc in the image, let's see what happens. it seems with current guix almost everything needs to get built :)
<thomasd>fps: yes, I usually stay behind the tip of master by a few commits, so substitutes are available.
<fps>hmm, and ssh has minute long resting periods..
<fps>ca. 10 minutes after password prompt until login
<fps>and then after a while a complete freeze. rinse and repeat
<fps>oh, and q6rbp frommirror.hydra aborts after precisely 12mb downloaded
<fps>[python 2.7.12]
<lfam>fps: On GuixSD it takes 10 minutes to finish the SSH login process?
<lfam>fps: And can you give the full URL of the substitute that fails to download?
<erliphant>Very silly question - can you install a package without downloading the source (guix package -i)? Or do substitutes only get applied to dependencies?
<fps>lfam: i can't copy and paste on the console
<fps>lfam: and then i get 10-15 minutes freezes in ssh, too :)
<fps>oh, i can
<lfam>erliphant: Guix won't download source unless it needs to build, which would mean that a substitute was not available
<erliphant>lfam: that's what I thought. Thanks.
<lfam>fps: Which SSH implementation are you using? OpenSSH? lsh?
<fps>Downloading (54.1MiB installed)...
<fps> openssh
<lfam>That's very strange!
<fps>also, i have this for grub: (bootloader (grub-configuration (device "/dev/sda1")))
<fps>erm, that's with the attempted change.. i usually have /dev/sda there.. hold on for the error message
<lfam>Typically you'd put GRUB on /dev/sda
<fps>redoing it with sda to get the error..
<fps>Installing for i386-pc platform.
<fps>then: grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
<fps>and finally something about blocklists and then: grub-install: error: will not proceed with blocklists.
<lfam>Oh, the same error as before :)
<fps>yep ;)
<lfam>It's the wrong type of partition label. It needs to be 'dos'
<lfam>You can check the type with `fdisk -l /dev/sda`
<lfam>Perhaps there is a workaround. I'm not sure
<lfam>We recently added some info to the manual on this subject:
<efraim>gpsbabel on core-updates looks like an easy fix if someone wants to grab it
<lfam>efraim: I looked into it last night. Basically, it will build if you pass -fPIC
<lfam>The full story is very complicated
<fps>i can't install links to read it ;)
<lfam>And the discussion ranges all the way to the GCC bug trackers
<lfam>After so much reading, I felt totally unqualified to make a decision :p
<lfam>I think we should just pass -fPIC to gpsbabel
<efraim>that was my plan from looking at the log
<lfam>efraim: Can you make the commit?
<efraim>my x86_64 machine is incredibly slow ATM and my aarch64 board hasn't compiled mysql successfully yet so I can't test that it works :/
<lfam>okay, I'll do it soon
<lfam>It seems sort of like a bug in Qt, so we should keep track of packages that require this change
<efraim>i added a comment for the packages that needed not flex-2.6.3
<lfam>Ugh, don't remind me about flex ;)
<fps>let's see if i can get it done with system init --no-grub and then using ubuntu's grub magic to boot it
<efraim>my firefly board arrived, i'll get to unbox it in about a week
<efraim>if I read the specs correctly it'll take an additional M.2 2242 SSD
<fps>ok, it seems to be the wifi in the hotel that causes the freezes
<efraim>cvs checkout for source download is terrible
<pareidolia>civodul: Can I ask some questions about the roadmap for Shepherd and service facilities?
<civodul>pareidolia: sure!
<civodul>it's pretty unstructured
<civodul>there's a TODO file and ideas floating around, notably in the GSoC wiki page
<efraim> the armhf build failure of libevent-2.1.8 is the same one as I get on aarch64
<lfam>efraim: FAIL test/regress_util.c:1375: assert(total_diff/9 < maxstep): 31111 vs 25000util/monotonic_prc:
<efraim>lfam: mmm, probably. I haven't tried building it in a couple of days but all the warns and msgs looks familiar
<lfam>A different bug but a familiarname
<efraim>i just had to mark libffcall unsupported on aarch64
<pareidolia>civodul: I read all of that. I was wondering what the prevailing attitude is regarding dynamicity a la sytemd
<pareidolia>civodul: Importing .service definitions is one thing, but taking the system from one set of active services to another is something else
<pareidolia>civodul: A nixos-rebuild switch causes services to be restarted, guixsd doesn't do this afaict.
<slyfox>basic hydra question: there is a guix target that failed a few times and tried at "2016-03-01":
<slyfox>is it something outdated?
<lfam>I think it is outdated, by definition :)
<slyfox>oh, it's 2016, not 17
<slyfox>should it be just removed at some point?
<lfam>Perhaps, but I don't know exactly what it is.
<lfam>It looks like an attempt to build release tarballs on Hydra
<fpss>ok, i read up a little bit about efi. on an efi system the os just needs to put its boot loader into the EFI System Partition [which is a fs type similar to FAT or one of its variants]
<fpss>and then tell the firmware about it using e.g. efibootmgr
<fpss>i wonder why guixsd's grub-install tries to squeeze its boot manager into /dev/sda's mbr
<pareidolia>fpss: I put the grub EFI binary manually in an EFI boot dir
<fpss>pareidolia: or rather not complicated, but i'm ignorant about grub really, so i would have to do reading which is complicated without a web browser ;)
<civodul>pareidolia: 'guix system reconfigure' only restarts services that are currently stopped, and it also starts new services
<civodul>it's quite conservative
<civodul>slyfox, lfam: i is/was indeed an attempt to do continuous integration of Guix itself
<civodul> now uses 'guix publish' for narinfos & nars \\o/
<pareidolia>civodul: Do you think of the nixos approach as desirable?
<civodul>pareidolia: maybe, but we'd need to study the details
<civodul>the difficulty here is that restarting a service that's not a leaf in the dependency graph means that you have to restart everything it depends on
<civodul>sometimes it's ok, sometimes not
<civodul>for instance, "herd restart udev" would shut down Xorg
<civodul>undesirable :-)
<pareidolia>civodul: NixOS has done something that prevents that
<civodul>that said, there's room for improvement!
<civodul>pareidolia: so probably we need to still from them ;-)
<civodul>when i hacked on NixOS that was pre-systemd
<pareidolia>Systemd has this whole transaction-job thing, I haven't studied Shepherd but it doesn't take that approach afaict, correct me if I'm wrong
<pareidolia>It doesn't have runlevels/targets right?
<thomasd>"March 17, 2017: Some religious extremists updated their cult-approved Scheme implementation. Hackernews is pleased that this version is bug-compatible with a bad text editor." :-D
<buenouanq>Systemd made Debian unusable for me - Literally broke everything. I really hope no one here is suggesting we look towards that unauditable mess for design ideas.
<pareidolia>buenouanq: Quoth Time Cube Man: "An open mind is a slop bucket."
<pareidolia>civodul: ping :P
<civodul>pareidolia: shepherd is simple (simplistic?): it just sees a DAG of services
<civodul>i don't know the "transaction-job thing" of systemd, but it sounds interesting :-)
<pareidolia>civodul: This concerns calculation which steps are necessary to take the system from one state to another, stop this, stop that, start that etc.
<civodul>pareidolia: thanks for the link (big wall of text!)
<civodul>what 'guix system reconfigure' does is this function:
<civodul>ACTION -> zZz
<slyfox>good night :)
<civodul>pareidolia: i'm interested in discussing what you have in mind on guix-devel or
<pareidolia>Good night