IRC channel logs

2018-09-26.log

back to list of logs

<dustyweb>hm
<dustyweb>oops
<dustyweb>I think I haven't been bumping the revision when bumping git-referenced packages
***rekado_ is now known as rekado
<rekado>Hi Guix!
<janneke>hi rekado!
<marusich>Hi there, rekado
<marusich>How's life?
<emacsomancer>hello all
<marusich>Hello there!
<rekado>marusich: life seems to be going by faster every day. Maybe it’s just me slowing down.
<marusich>I know how that feels :)
<jonsger>rekado: how does this Dell HBA shows up in hwinfo?
<rekado>what package provides hwinfo?
<rekado>lspci -v tells me this: Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)
<jonsger>oke
<rekado>kernel driver is mpt3sas
<jonsger>guix is missing a "cnf" (command not found) command, to determine from where a binary can be installed :P
<g_bor_>hello guix
<jonsger>rekado: we have a machine with LSI Logic / Symbios Logic MegaRAID SAS-3 3108, don't know if this is similar enough
<ng0>cnf would need code changes for us to work
<ng0>looked into this a while back :)
<marusich>rekado, hwinfo isn't mentioned in the Guix source tree on master, so maybe it isn't packaged?
<ng0>is there a reason why we build ffmpeg without libdvdread?
<ng0>comments in the code don't show one, so I guess no one thought of it so far
<efraim>ng0: I think it used to pull in java
<efraim>One of my early reverts dealt with libdvdread I think
<jonsger>efraim: If you mean that one https://github.com/openSUSE/scout I don't think it pulls java in
<efraim>But that would've been 2015? Worth revisiting
<ng0>okay, that would'vd made the DAG of ffmepg bigger, and what else?
<ng0>ok
<ng0>I'll try and see
<ng0>thanks
<jonsger>ah hups, I got confused...
<ng0>is hydra/berlin already building the rust-wip branch? if not, I might soon be able to reportat least for x86_64 that it works. I'm 18 hours into the build
<ng0>i mean with the tools available, mpv would be good enough, but I have no idea how to prevent a stream-dump of a DVD dropping from the track i wanted to the main menu track after it is finished. Maybe I'll just package vobcopy and do it like I used to
<ng0> it's really fascinating how fast backing up your dvd movies is with supported Bluray drives. I remember back then it took almost a day or something like that. Now it's just a tiny fraction of the play time of the movie track
<roptat>I tried to remove calls to make-static-device-nodes to see if that would solve my issue with containers
<roptat>but then in the container I get: error: connect: /var/run/shepherd/socket: No such file or directory
<roptat>and indeed the file doesn't exists...
<roptat>there's still a running shepherd process as PID 1
<g_bor_>roptat: what exactly are you trying to do?
<g_bor_>I missed the beginning of this discussion...
<civodul>o/
<roptat>my issue is that I cannot run a container (see http://issues.guix.info/issue/32814)
<roptat>civodul suggested that was related to make-static-device-nodes, so I tried to neutralize that procedure (replaced with a simple format) to see what it would do
<roptat>but then the shepherd doesn't create its socket :/
<roptat>but it doesn't stop either
<rekado>civodul: I’ve started looking through the wip-ui patches. I haven’t gone through everything yet, but it’s looking great already.
<rekado>(I found a few typos)
<rekado>looking at the problems we were having with the statelessness of the soft port I think the idea of issuing events and computing build state is exactly what we need.
<civodul>rekado: cool, thanks for looking into it
<civodul>i'm happy to fix the typos :-)
<civodul>did you try running it?
<rekado>yes, but without updates to the daemon, which I think are necessary.
<rekado>without the updates I don’t see any downloads. Since the substitution messages are not displayed it’s a little too quiet.
<civodul>the daemon updates are necessary for download progress reports
<civodul>oh i see
<rekado>maybe we could check whether the extended trace is available and print the substitution messages if it isn’t.
<civodul>hmm indeed
<civodul>not sure how to check though, it needs more thought
<rekado>is this not communicated through _NIX_OPTIONS?
<civodul>well we could bump the protocol version
<rekado>or that :)
<civodul>_NIX_OPTIONS communicates in one direction: from the daemon to 'guix substitute'
<rekado>oh, okay
<civodul>and here we'd like 'guix substitute' to tell the client what it supports
<civodul>the protocol version trick would seem reasonable
<civodul>it's sorta part of the protocol :-)
<rekado>yeah, it’s reasonable in my opinion.
<g_bor_>roptat: it seems, that some devices on that list might be needed, after all...
<g_bor_>could we mount the foreign-distro kernel modules dir into the container?
<roptat>no, because then the container attempts to symlink a parent directory to the store and fails
<efraim>Even with expose?
<roptat>efraim: yes
<roptat>with --expose=/lib/modules=/run/booted-system/kernel/lib/modules
<roptat>(I'm on a foreign distro)
<ebrasca>Hi is there suport for Talos II in guixsd?
<jonsger>ebrasca: no, not yet. Guix doesn't have ppc64le support at the moment
<jonsger>I tried to port, but the thing is we need a newer gcc version (6.2) for ppc64le
<efraim>jonsger: you can probably declare a later gcc in make-bootstrap.scm, and a different bootstrap path in commencement.scm
<efraim>Right now I'm slowly making debian packages of the different guile dependencies so I can get guix on my ppc
<jonsger>its ppc32 bit?
<ebrasca>jonsger: I think it is more 64bit and can run some operations in 128bits.
<jonsger>ebrasca: the question should go to efraim...
<jonsger>I know that TalosII is 64bit
<ebrasca>ok
<efraim>My ppc is 32 bit
<efraim>Old iBook G4
<efraim>Probably big endian, not sure if anyone bothered with PPC32le
<efraim>I know from #gentoo-powerpc the Talos is bi-endian
<nlyy>hi
<nlyy>how can i see the documentation/source for (process-package-actions ...)
<nlyy>it's a procedure from emacs-guix module
<rekado>nlyy: the code for emacs-guix is not part of the code of Guix. You can get its code with “guix build -S emacs-guix”.
<civodul>hmm weird stuff:
<civodul>guix package: package 'emacs-typo' has been superseded by 'emacs-typo'
<civodul>guix package: package 'emacs-org-tree-slide' has been superseded by 'emacs-org-tree-slide'
<civodul>guix package: package 'emacs-emms' has been superseded by 'emacs-emms'
<snape>does anyone know how to remove the Privacy settings window from the Icecat's new tab page?
<snape>I want a blank page, as with Firefox
<jonsger>about:preferences#home
<efraim>about:blank would've been my guess
<jonsger>New tabs -> blank page
<snape>jonsger: about:preferences#home doesn't exist
<jonsger>ah, I use Firefox Nightly (64)
<snape>jonsger: it's something Icecat specific
<snape>efraim: about:blank shows a blank page, but it doesn't change the "New tab" behaviour
<roptat>snape: it seems that from about:config you can set browser.newtabpage.enhanced to true
<roptat>not sure why, but now I have blank pages in new tabs :)
<roptat>ah nevermind
<roptat>it just took a second to show the page
<snape>found it
<roptat>browser.newtabpage.enabled to false
<snape>yes
<snape>thank you!
*civodul pushes shepherd 0.5.0
***Server sets mode: +cnt
<snape>civodul: \o/
<snape>will you update the Guix package as well?
<mbakke>civodul: I think you forgot to CC info-gnu@ (?).
<civodul>mbakke: ah no, it's too alphaish :-)
<civodul>maybe next time!
<mbakke>Oh :-)
<efraim> https://blog.digitalocean.com/custom-images/
<civodul>efraim: looks like one could easily import a GuixSD qcow2 image, no?
<efraim>Yep
<efraim> https://alpha.gnu.org/gnu/guix/
<civodul>is it a new feature of Digital Ocean?
<efraim>Yeah, as of yesterday I think
<civodul>nice, you should share on guix-devel :-)
<jonsger>civodul: shepherd is on place 2 on HN :P
<civodul>jonsger: people really upvote random things ;-)
<daviid>wowh gnu shepherd is 3rd on HN, congratulations!!
<daviid>I didn't see you just wrote aboyt it :)
<davexunit>always the same comments though
<davexunit>"this looks cool does anyone use it?" "no its gnu its bad"
<nlyy>lol
<nlyy>their loss :p
<mbakke>Mmmmm sweet HN karma :-)
<civodul>davexunit: heh :-) i just replied to the "no GNU-friendly software" comment
<GNUtoo>hi, as I understand guix pull is to get an updated package list (like apt update or pacman -Sy)
<GNUtoo>it also update guix as well
<GNUtoo>I installed guix in Parabola through Parabola's package manager (with pacman -S guix)
<GNUtoo>I did that long time ago, and guix package -s worked for instance
<GNUtoo>but yesterday I did guix pull and it built a lot of stuff
<GNUtoo>even if I've some public key in /etc/guix/acl
<GNUtoo>and then guix package -s or guix package --help doesnt work anymore,
<GNUtoo>I've some scheme backtrace with 'no code for module (gcrypt hash)' inside it:
<GNUtoo> https://paste.gnutoo.cyberdimension.org/guix/guix-pull-0001.txt
<GNUtoo>hmmm some lines were garbled during copy-paste, I'll scp the log instead
<divansantana>hmm. Is there a way in our chromium to display local timezone. I think ours is patched to not show the local time for privacy reasons. That is nice, but would be nice to override it. Grafana only displays the time in local browser timezone...
<GNUtoo>hmm still garbled, the part that is garbled is that one: <procedure 1ad46a0 a…>) instead of #<procedure 1ad46a0 a…>)
<GNUtoo>Is interrupting 'guix pull' (with ctrl+c) and restarting it (with 'guix pull') supposed not to create any issues?
<GNUtoo>or could it create the issue I described above?
<civodul>hey GNUtoo
<rekado>GNUtoo: you probably upgraded from an older version of Guix.
<GNUtoo>yes, I did
*civodul was about the say that :-)
<GNUtoo>hi
<GNUtoo>that's not supported?
<rekado>well, the mechanism for “guix pull” has changed significantly
<GNUtoo>oh ok
<rekado>it now prevents these kinds of problems
<GNUtoo>pcr/guix 0.14.0-1 [installed]
<rekado>but the cost is that old installations cannot upgrade easily. You’d need to upgrade in two steps.
<GNUtoo>else I could try to update my distro's guix package?
<GNUtoo>(Note that I'm a total newbie at guix)
<civodul>i'd recommend starting from 0.15, which provides the new 'guix pull' rekado mentioned
<roptat>GNUtoo: if it doesn't override the store, you could upgrade your system package and use it to pull the newer version
<GNUtoo>ok, thanks a lot
<roptat>making sure `which guix` is the new system version
<GNUtoo>can I safely delete that symlink: /root/.guix-profile ?
<GNUtoo>*how do I revert to something close to pristine, without the issue I have?
<GNUtoo>(2) and would I need to do that anyway, if I upgrade the system package to 0.15.0?
<civodul>GNUtoo: if you don't rely on your current Guix install, you can "rm -rf /gnu/store" and unpack 0.15.0 on top of it
<civodul>that's brute force :-)
<civodul>roptat: i'm looking at the container issue: shepherd inside the container is stuck waiting for /var/run/dhclient.pid, which is why it doesn't set up its socket
<roptat>civodul: ah I see
<civodul>that's with bare-bones
<roptat>why does it wait for it?
<civodul>good question :-)
<roptat>oh so without the dhcp-service it should work fine, no?
<civodul>it should, and indeed it makes no sense to use it
*civodul goes fix the infinite loop in dhcp-client-service
<roptat>but then of course it complains that there is no networking service
<civodul>for me it tries to reboot for some reason, which fortunately fails:
<civodul>In procedure reboot: Invalid argument: 0
<civodul>:-)
<roptat>actually it doesn't complain, which is good
<roptat>so removing the dhcp service and neutralizing make-static-device-nodes did the trick
<roptat>it still complains it can't start user-homes, virtual-terminal, term-tty* etc
<roptat>how can I add network support in my container though?
<roptat>manually via iproute2 I guess?
<roptat>and is there a way to know the PID of the shepherd process in the container?
<roptat>currently I use ps to discover that, but I'd like to use it in a script
<mckinley>mbakke: is the chromium build somewhat indeterminent, or should I be pretty successful on x86-64? I wonder if I may be running out of memory (?), as I haven't been able to get it to complete
<civodul>roptat: you could get the PID of the "run-container" script
<civodul>and then "nsenter" that
<roptat>civodul: I think the run-container script runs in the main namespace
<civodul>roptat: if i take bare-bones and remove the whole 'services' line, it says "failed to start" a few things and then tries to reboot
<civodul>are you doing something different?
<roptat>civodul: I have only one more service added to bare-bones
<roptat>the postgresql service
<roptat>after "failed to start ..." messages I get "errors in config/options: missing mapping" (not sure where from)
<roptat>it doesn't try to restart
<roptat>and I can entre the container with guix container exec
<roptat>but I need to give the PID of the shepherd process, not the run-container one
<civodul>ok
<roptat>regarding network isolation, we don't really create a separate netns, do we?
<roptat>it's just that the device node is not present, or something else?
<civodul>roptat: dunno
<civodul>if i comment out make-static-device-nodes, then /dev/tty* don't get created
<civodul>and then console-ttyN fails to start
<roptat>does it try to reboot then?
<GNUtoo>I tried to update the package but I stumble upon a build issue:
<GNUtoo>'gnu/services/lirc.scm:50:2: In procedure allocate-struct: Wrong type argument in position 2: 3'
<GNUtoo> https://paste.gnutoo.cyberdimension.org/guix/guix-build-0002.txt
<GNUtoo>here's what I have line50: https://paste.gnutoo.cyberdimension.org/guix/0003-guix-lirc-source.txt
<GNUtoo>(define %lirc-activation
<GNUtoo>#~(begin
<GNUtoo>(use-modules (guix build utils))
<GNUtoo>(mkdir-p "/var/run/lirc")))
<GNUtoo>no idea what's the issue here, I don't know scheme yet
<GNUtoo>maybe an issue with the use-modules?
<javistacruz>hi all. Every time I try to install guixsd, installation seems to be ok, but reboot leads me to grub rescue shell. I guess it has something to do with EFI, but can't realize what's exactly going on. Any ideas?, Is there any known issue I'm missing?
<roptat>do you configure grub for EFI?
<GNUtoo>javistacruz: what is grub rescue shell? something with 'grub >' or you're not even in 'normal' mode?
<javistacruz>roptat: I've put the boot in "legacy mode" and when I try to configure grub for EFI then installation gives me error. It only seems to work when I configure normal grub.
<mckinley>javistacruz: can you post your configuration and what steps you take during the install?
<javistacruz>GNUtoo: looks like "grub rescue >"
<civodul>GNUtoo: the "allocate-struct" error suggests you have stale .go files around; you may need to run "make clean-go && make"
<roptat>javistacruz: does your system start in legacy mode then?
<javistacruz>roptat: yes, it does
<roptat>could you share your configuration file?
<roptat>paste it on paste.debian.net and put the link here
<javistacruz>mckinley: I'm gonna try to post the config file somewhere, but essentially is the default one with username and sdX changed
<javistacruz>roptat: ok, give me some min, I've got it in the non working laptop ...
<roptat>what did you put instead of sdX?
<javistacruz>sda
<roptat>what's the filesystem on your main partition?
<GNUtoo>civodul: thanks
<GNUtoo>javistacruz: what does insmod normal says?
<javistacruz>roptat: sda1 is 15M partition for boot, sda2 for swap and sda3 rest for system
<javistacruz>GNUtoo: dont understand what you mean with insmod normal, sorry. You mean me to use insmod command in some way?
<GNUtoo>no, in gru
<GNUtoo>*in grub
<GNUtoo>when you have the "grub rescue >" if you type "insmod normal" it may complain about what's not working
<GNUtoo>here it probably doesn't find the normal module, or some modules necessary for grub to continue loading the rest of its code
<GNUtoo>afaik HDD encrption isn't supported in guix, so it's most probably not related to GRUB_ENABLE_CRYPTODISK
<GNUtoo>so it's probably related to not being able to load normal
***jonsger1 is now known as jonsger
<javistacruz>roptat: I pasted the config file at http://paste.debian/1044511
<javistacruz>GNUtoo: I'm gonna check the insmod thing
<snape>roptat: not sure I understood your questions, but the PID of a Shepherd service might be the running value. In that case, it can easily be obtained with some Guile code, or with 'herd status <service-name>'.
<javistacruz>GNUtoo: insmod normal gives me "error: unknown filesystem"
<snape>roptat: it's the case with the PostgreSQL service I believe
<GNUtoo>aha okay
<GNUtoo>how did it install GRUB? UEFI?
<GNUtoo>if so on what filesystem is the grub binary? it should be fat32 and ideally the partition table should be gpt and the partition type should be ef00
<javistacruz>GNUtoo: I configured (bootloader grub-bootloader), so I think it installed grub
<javistacruz>I'll check the partition in a while, I have to go out for a while ... thanks for your patience
<GNUtoo>ok, np
*GNUtoo will try to rebuild guix now (doing too much things at the same time)
*GNUtoo also has cleaned /gnu before attempting the clean rebuild
<roptat>that's a legacy system, so you don't need a fat32 partition
<roptat>snape: I don't want the PID of a shepherd service, I want the PID of the shepherd itself
<roptat>the one that's running in the container
<snape>Ok, that's why I thought I hadn't understood the question :)
<snape>yes got it
<roptat>(it's PID 1 inside the container, but I want its PID outside of the container)
<GNUtoo>civodul: hmmm indeed there is something with '.go' files: ;;; note: source file ./guix/build/compile.scm
<GNUtoo>newer than compiled /usr/lib/guile/2.2/site-ccache/guix/build/compile.go
<GNUtoo>I'm trying that but It did the error by building a fresh release tarball
<GNUtoo>and it still does it
<GNUtoo>so I'll uninstall guix and see if it builds that way
<GNUtoo>I'll also add the make clean-go in the package build script from parabola (PKGBUILD)
<ng0>roptat: x86_64 build of it works here
<ng0>just make sure to have around 16GB (RAM+swap)
<efraim>Does it depend on the number of cores? I got bored of testing with a VM with 2 cores and 9 GB
<rekado>samplet: I can’t seem to find your Haskell patches. Have you submitted them yet?
<samplet>rekado: I sent a message to guix-devel, but I have reason to suspect that my out-going mail has stopped working.
<divansantana>Why does one get these messages when doing a reconfigure? https://paste.debian.net/1044710/
<divansantana>note: source file... newer than compiled... etc
<samplet>rekado: I think it sent this time. Sorry!
<samplet>I have to go now, though.
<civodul> https://phoronix.com/scan.php?page=news_item&px=GNU-Shepherd-0.5-Released :-)
<daviid>guix is everywhere :), hoe nice!
<ng0>what is this "you may need these modules" check on reconfigure?
<ng0>oh, did not pull again on the server
<ng0>nvm :)
<ng0>this explains the message i got
<civodul>heh :-)
<ng0>civodul: it was like this, when the new kernel exists, but in the old generation a certain kernel module was required in the initrd, you'll get a message which you can then skip.. right?
<civodul>ng0: you can always skip with --skip-checks
<civodul>and it's necessary in cases like you describe
<ng0>yes, I asked because so far I never had this. I skipped it since *in theory* (no reboot yet and I personally lack the hardware) the fix Mark made for the module I had should work out.
<ng0>my rust-wip builds are donme I think :)
<ng0>my helloworld.rs compiles and executes.
<TwistedFate>hello all