IRC channel logs


back to list of logs

*mark_weaver works on updating icecat to 31.5.0
<mark_weaver>(and having it use fewer bundled libraries while I'm at it)
<iyzsong>Sleep_Walker: I have add xsession for ratpoison ;-)
<Sleep_Walker>iyzsong: perfect!
<Sleep_Walker>it was driving me crazy
<Sleep_Walker>I spent two hours to understand the build error I had and in the end I was desperate and exhausted
<iyzsong>Sleep_Walker: Alright. I'll waiting ludo to review my slim patches (which remove a lot of code in xorg.scm).
<Sleep_Walker>iyzsong: good, I was just about doing the same
<Sleep_Walker>iyzsong: please, define publicly xsessions-directory so it can be used in packages for the case we would decide changes in this matters
<Sleep_Walker>no, ignore it, sorry
<iyzsong>ok ;-)
<Sleep_Walker>for WMs in system-profile it will work automatically, for the rest it is not useful at all
<Sleep_Walker>I feel like I'm |-----| this tiny bit from using Guix for daily work
<iyzsong>I only use GuixSD for daily hack o.O
<Sleep_Walker>I still couldn't leave my gentoo
<zacts>Sleep_Walker: I like funtoo > gentoo
<zacts>but guix is going to be cool
<zacts>I'm trying to decide what to put on my laptop
<zacts>I just accidentally totally destroyed my current laptop's power cable
<zacts>so I'm going to use my mum's laptop until my cable gets here next week
<zacts>I can put whatever I want on the laptop
<zacts>I'm considering either guix or funtoo, or something
<zacts>so I may brb, in a bit. as my battery will die in an hour
<Sleep_Walker>I'm no longer distribution tourist :)
<Sleep_Walker>I use openSUSE and SLES at work, Gentoo on notebook, Debian on router, Ubuntu and Android on ARM machines
<Sleep_Walker>and now I finally am on Guix on notebook
<zacts>I had Slackware on my laptop for like two years
<zacts>but the base system became too outdated, I don't know when a new release will be for it
<zacts>so I switched to arch
<zacts>and now that my laptop is b0rked
<zacts>I'm considering something else too
<zacts>but I may just put something like arch or parabola back on it
<civodul>Hello Guix!
<davexunit>hey civodul
<rekado_>Hi civodul!
<civodul>i realize i may have annoying Sleep_Walker in handling the bug reports
<civodul>Sleep_Walker: i hope you're fine and everything regardless :-)
<Sleep_Walker>civodul: I don't feel annoyed, I feel annyoing :)
<Sleep_Walker>I started to write an answer which would describe my setup and thought to myself the problem is probably elsewhere
<Sleep_Walker>but I think we can create some package set for rescue where grub can be one of them
<civodul>Sleep_Walker: more generally, i think we really need different "template" OS declarations
<civodul>like 'desktop-operating-system' would directly give you Xorg, xterm, Xfce (say) etc.
<Sleep_Walker>yes, I had the same in mind
<civodul>i'm not yet sure how to do it
<civodul>but we must definitely have it
<Sleep_Walker>it depends on desired behaviour
<Sleep_Walker>for me sets of packages with reasonable name is enough
<Sleep_Walker>In openSUSE we have patterns of packages which is more or less the same
<Sleep_Walker>installing pattern cause installing packages, nothing else
<civodul>what do these patterns look like?
<iyzsong>civodul: while (file-exists "~/.xsession") don't work, the 'catch' or 'false-if-exception' don't work too ;-)
<iyzsong>because execl does success with 'bash -c xxx', so we can really just call it once. I have sent new patches to ML.
<Sleep_Walker>good, good
<civodul>iyzsong: ooh, right
<civodul>thanks for catching this
<civodul>Sleep_Walker: oh i see, it looks like what some call "meta-packages" in a way
<Sleep_Walker>only it doesn't imply un-installation
<iyzsong>this mean we need 'recommends' or 'suggestions' for package?
<Sleep_Walker>iyzsong: not necessarily
<Sleep_Walker>iyzsong: if you'd install some set of packages, you can then install/uninstall them separately
<iyzsong>current, when the meta-package using 'propagated-inputs' or 'union-build' unistall, all packages it bring uninstall too.
*iyzsong don't know how to implenment it through
<Sleep_Walker>(define %enlightenment-desktop-packages (list enlightenment terminology elemines ev)) ?
<Sleep_Walker>If it would show package list on uninstallation and ask for confirmation - that would work
<Sleep_Walker>another topic can I somehow trace what is wrong with the networking? I see no information, no log
<Sleep_Walker>`deco enable networking' enable it for a while and then disable again
<iyzsong>without a working wifi card, I use my android phone as usb wifi, always using 'dhclient' manually.
<Sleep_Walker>I could do the same
<Sleep_Walker>but I'm trying to improve the usability
<Sleep_Walker>no networking, no users
<civodul>Sleep_Walker: you could write a "meta-package" for Enlightenment like the one iyzsong wrote for Xfce maybe?
<Sleep_Walker>not that there is reason right now
<Sleep_Walker>but when there is technical solution I understand, I can usually copy&paste it :D
<Sleep_Walker>I plan to do that once there is more application
<Sleep_Walker>(maybe shotgun XMPP, MPD client, media player, webkit browser, ...)
*iyzsong AFK, good night #guix.
<civodul>night, iyzsong!
<Sleep_Walker>civodul: I also miss configuration for GUIX_PACKAGE_PATH - I'm not sure what and how should that do, but I'm altering /etc/profile to set it, I'm copying that manually to some path and reconfigure may destroy my changes...
<civodul>why do you want to use GUIX_PACKAGE_PATH?
<Sleep_Walker>for my packages which shouldn't get to guix
<Sleep_Walker>like my version of dwm
<Sleep_Walker>something like additional repositories in other distributions
<Sleep_Walker>or when I'll get mad and create adobe flash package, I'd put it there
<davexunit>Sleep_Walker: there are several mpd clients packaged, fwiw.
<Sleep_Walker>davexunit: I'm aware of that :)
<davexunit>having a webkit package will be a good day.
<davexunit>I say we need guile bindings for webkit :)
<davexunit>and write a guile version of conkeror but using webkit
<civodul>+1 :-)
<civodul>GSoC maybe? ;-)
<Sleep_Walker>I'm too addicted to Firefox addons, but EFL browser was the only desktop browser with decent touchscreen controls
<davexunit>civodul: hehe
<civodul>Sleep_Walker: i set GUIX_PACKAGE_PATH in ~/.bash_profile, FWIW
<civodul>it seems preferable to do it per-user than in /etc/profile
<mark_weaver>huh, I was just about to push the icecat-31.5.0 update, but it seems to have lost all of my settings and bookmarks from 31.4.0 :-(
<Sleep_Walker>so it is something, which will be available _after_ `guix system init'
<mark_weaver>I wonder if this has to do with me switching it to use the system nss and nspr libraries
<Sleep_Walker>mark_weaver: check whether it haven't created new profile
<mark_weaver>ah, it's in ~/.gnu/icecat instead of ~/.mozilla/icecat
*mark_weaver tries moving the directory over
<mark_weaver>okay, that worked. you need to move ~/.mozilla to ~/.gnu
<Sleep_Walker>I have Guix with failing networking (with wicd-service) here, but I have no idea, how to debug it
<Sleep_Walker>Respawning too fast.
<Sleep_Walker>wicd daemon is just ending with return value 1
<mark_weaver>sorry, I'm needed elsewhere right now
<Sleep_Walker>I should install connman :b
<mark_weaver>I would try running it from the command line and see what happens.
<Sleep_Walker>15:26:39 Sleep_Walker wicd daemon is just ending with return value 1
<Sleep_Walker>sometimes with stale pid file
<Sleep_Walker>I just installed strace to have a look
<mark_weaver>anything useful in /var/log/wicd/wicd.log
<mark_weaver>anyway, gotta run
<mark_weaver>but if you're motivated to work on connman, that's even better :)
<Sleep_Walker>mark_weaver: seems to be dbus security issue
<Sleep_Walker>in connamn I need to copy manually one file - either I will find the way to do that in guile or fixed version with my patch will be released :b
<Sleep_Walker>rest should work
<mark_weaver>Sleep_Walker: ah yes, you need to add wicd to the list passed to dbus-service
<mark_weaver>e.g. I have: (dbus-service (list avahi pulseaudio wicd))
<Sleep_Walker>this part is unclear to me
<Sleep_Walker>I see no reason for that (and it reminds me too much Czech bureaucracy :)
<Sleep_Walker>you have systemwide pulseaudio service?
<mark_weaver>actually no, I'm not sure if that's needed
<mark_weaver>(the pulseaudio part)
<Sleep_Walker>I'll check how wicd does that and hack it same way for connman
<mark_weaver>also make sure to add your human user(s) to the netdev group to allow them to configure the network with wicd
<Sleep_Walker>mark_weaver: mere adding wicd to the dbus-service list didn't solve the issue
<Sleep_Walker>hm, maybe I should restart dbus-system as well
<Sleep_Walker>do you know in which package is `pidof'? I miss it very much
<Sleep_Walker>chm, how can one compile anything by hand?
<Sleep_Walker>ld: cannot find crt1.o: No such file or directory
<Sleep_Walker>I have it here:
<mark_weaver>Sleep_Walker: well, you need to reconfigure your system after making those changes, and maybe reboot.
<mark_weaver>(I'm not sure off hand how to reload updated services without rebooting)
<Sleep_Walker>reconfigured, service restarted
<mark_weaver>well, the thing is, that probably just reloads the old service
<mark_weaver>civodul: after making changes to 'services' in an OS config, is there a good way to reload the new services into DMD without rebooting?
<mark_weaver>DMD allows you to execute arbitrary code in it, so it's certainly possible, but I'm not sure of the details of how to do it, or whether it can be done safely.
<Sleep_Walker>I just will remember that for future
<Sleep_Walker>and now I can confirm it works!
<mark_weaver>that's good!
<Sleep_Walker>that's _very_ good
<mark_weaver>did you have to reboot, or was it enough to restart the service?
<Sleep_Walker>but still - why I need to specify the service once again as dbus-service?
<mark_weaver>that could certainly be improved
<Sleep_Walker>OK, I'll file the bug >:)
<Sleep_Walker>today is bug day
<Sleep_Walker>and I almost forgot - how to suspend?
<mark_weaver>basically, packages that provide services on the system dbus need to provide some configuration/policy files for dbus
<civodul>mark_weaver: not yet!
<civodul>mark_weaver: the goal is to have 'guix system reconfigure' handle it
<civodul>but the thing is, you can't reload all the services
<Sleep_Walker>systemd takes care of it, there were pm utils or I can just send `mem' to /sys/power/state
<civodul>because reloading, say, 'user-processes', would first kill all the processes on your machine
<civodul>my plan is first to move each service definition into its own file
<civodul>and then have 'guix system reconfigure' load the "right" ones
<mark_weaver>Sleep_Walker: I made a script that does an infinite loop of "echo mem > /sys/power/state", sleep 10 seconds, and repeat.
<mark_weaver>the reason is that at least on my system, the laptop sometimes wakes up spuriously.
<mark_weaver>and so I need it to go back to sleep again.
<Sleep_Walker>too loud neighbours? :)
<mark_weaver>so when I wake it up intentionally, I use Ctrl-C to exit my script
<mark_weaver>obviously this is a terrible hack until we have something more proper.
<mark_weaver>ideally, I guess that dmd should handle putting the system to sleep.
<mark_weaver>so that services can provide actions to be run before sleeping and after resuming.
<Sleep_Walker>I was productive for Guix but not much for my employer today :)
<mark_weaver>heh :)
<mark_weaver>civodul: sounds good!
<mark_weaver>although we'll probably also need to make dmd more robust to errors before reloading services can be safe enough to use.
<mark_weaver>it's one thing for a system to panic on boot, it's another to bring down a live system with 'guix system reconfigure'
<civodul>mark_weaver: yes, there are fine details like that to work out :-)
<civodul>users should also be able to choose whether or not to restart services, like apt does
<mark_weaver>btw, I've tried rebuilding current master on armhf, and there are serious problems from corrupted ELF files created by the buggy patchelf
<mark_weaver>basically, we don't have a working patchelf on ARM.
<mark_weaver>last time, I worked around the problem by fixing our icu4c package to not use patchelf.
<mark_weaver>but since then, patchelf has been used in more places, and now things aren't working again.
<mark_weaver>either someone needs to step up and fix patchelf on ARM, or else we need to minimize our use of patchelf
<mark_weaver>(or we drop armhf, but I'm assuming that's off the table)
<mark_weaver>my preference would be to never use patchelf if it can be avoided, which I guess means only to patch precompiled binaries that we get from elsewhere
<mark_weaver>(e.g. for self-hosted compilers)
<mark_weaver>what do you think?
<mark_weaver>(patchelf is broken on MIPS now too)
<civodul>i would rather avoid ELF hacks in general
<civodul>and when we do want ELF hacks, i'd rather use (guix elf)
<mark_weaver>agreed :)
<civodul>but yeah, avoid ELF hacks as much as possible
<civodul>mark_weaver: is an interesting, you'll like it :-)
<mark_weaver>it's interesting that with the last core-updates merge, ngircd started working on i686 and started failing on x86_64
<mark_weaver>looks like a flaky test suite
<taylanub>mark_weaver: it mucks with sockets, so maybe taking global resources on build machines, which arbitrarily fails?
<Sleep_Walker>aha, I started to run `make' on Guix repository when and the problem vanished because 'gnu/system/linux.go' was refreshed
<Sleep_Walker>iyzsong: good catch
<Sleep_Walker>(that 20037)
<taylanub>I discovered that my problems with mplayer2 are probably in the samba package. `augment-rpath' is used there, but it leaves files in lib/ with dangling .so references, and I guess the mplayer executable just somehow inherits them (I know little on how linking stuff works)
<taylanub>I'm guessing the problem is that it augments the rpath of files in bin and sbin, but not lib.
<bavier`>I'm getting a "guix/serialization.scm:142:2: In procedure module-lookup: Unbound variable: %default-port-conversion-strategy" error after recently pulling from master
<taylanub>bavier`: have you tried cleaning etc.?
<bavier`>yes, I did `make clean && make`, restarted the daemon, even updated my guile version; same issue
<taylanub>samba problem fixed; listening to Aqualung with guix-built mplayer2 :3
<taylanub>bavier`: let me just try building it too. (if you have time you could try "git clean -fdx" but WARNING: that command cleans pretty much *everything* away from the git repo that's foreign)
<bavier`>taylanub: the build succeeds, but any invocation of 'guix build ...' gets that error
<taylanub>bavier`: oh
<bavier`>I do see a warning about a "possibly unbound variable `%default-port-conversion-strategy'" when compiling guix/serialization.go though
<bavier`>oh, I see, I guess my guile got updated, but it was still referencing the 2.0.5 shared library
<bavier`>seems like a guile library versioning issue
<mark_weaver>we have to move away from using augment-rpaths except when there's no other way.
<mark_weaver>because we have no working patchelf on arm, and it's also now broken on mips :-(
<mark_weaver>and it's a terrible hack anyway
<Sleep_Walker>nfbrown ma asi starosti s L3 bugama :)
<Sleep_Walker>err, sorry, wrong channel
<taylanub>mark_weaver: I didn't realize augment-rpath is using patchelf :\\ in any case I didn't add a new use of it, just added more files to its usage.
<taylanub>(in the samba package, where it was already being used to patch files in bin/ and sbin/)
<taylanub>(now additionally lib/)
<mark_weaver>taylanub: I know, and I appreciate your fix :)
<Sleep_Walker>hm, it seems that xdg-utils are not aware of icecat
<bavier`>mark_weaver: I'm packaging a "Mozilla::CA" perl module and thought you might have some input. It's intent is basically to provide mozilla's cert bundle. I was wondering if we might instead want to have it just point to our nss-certs?
<mark_weaver>yes, definitely
<mark_weaver>we should aim to minimize redundancy for multiple reasons
<bavier`>ok, I can patch the source to not install the tarball's bundle, and instead point to nss-certs' pem bundle.
<mark_weaver>bavier`: sounds good, thanks!
<mark_weaver>taylanub: regarding ngircd, a second rebuild attempt failed in the same way. See
<mark_weaver>specifically: "starting server 1 ... failed!"
<mark_weaver>ditto for server 2, and then I guess the rest of the tests fail because there's no running server
<bavier`>this might be more difficult than I thought... I hadn't realized that the certs in nss-certs are separate
<mark_weaver>you need them in one big file?
<bavier`>the perl module and its interface assume they're in a single file
<mark_weaver>where can I find the source code for that perl module?
<Sleep_Walker> - this should work, shouldn't it?
<mark_weaver>bavier`: I mean the source code not just for the .pm file, but for the whole source tarball of that package
<mark_weaver>(is there such a thing? I confess to be ignorant of modern perl packaging)
<bavier`>that's the root of the distribution
<bavier`>sorry, not that one...
<bavier`>^ that one
<civodul>Sleep_Walker: i think you would need GUIX_PACKAGE_PATH=$GUIX_PACKAGE_PATH/gnu/packages
<Sleep_Walker>civodul: this worked `export GUIX_PACKAGE_PATH=/extra:/extra/gnu/packages/patches'
<Sleep_Walker>but I don't think it makes sense :)
<Sleep_Walker>GUIX_PACKAGE_PATH=/extra - will make package definitions available, the latter is for finding the patch
<Sleep_Walker>%patch-path definition looks like /gnu/packages/patches would be added automatically
<civodul>only for the "real" distro dir
<civodul>yeah that's a bit weird
<mark_weaver>I would expect it to look in DIR/gnu/packages/patches for each DIR in $GUIX_PACKAGE_PATH
<civodul>well rather DIR/patches
<bavier`>mark_weaver: or look at subroutine "_find_CA_file" in if you're curious as to how the module is used.
<Sleep_Walker>civodul: so there will be DIR/gnu/packages and DIR/patches?
<mark_weaver>civodul: well, it looks for packages in DIR/gnu/packages for each DIR in $GUIX_PACKAGE_PATH, right?
<mark_weaver>I never use this stuff myself. I just work out of a git checkout, and I recommend you do the same.
<mark_weaver>but we might as well make GUIX_PACKAGE_PATH behave in a consistent fashion.
<Sleep_Walker>this is my local version of dwm, it doesn't make sense to mix it
<civodul>mark_weaver: no, it browses DIR recursively
<civodul>there's no "gnu/packages" assumption
<mark_weaver>Sleep_Walker: I've been making modifications to packages and other things in Guix for almost as long as I've been using it. it works well
<Sleep_Walker>mark_weaver: you maintain local branch for that?
<mark_weaver>Sleep_Walker: yes
<mark_weaver>and I keep rebasing my local branch on top of upstream master
<civodul>mark_weaver: is GUIX_PACKAGE_PATH inappropriate for these local changes?
<mark_weaver>civodul: I see that the definition of %package-module-path adds the components of $GUIX_PACKAGE_PATH to %load-path and %load-compiled-path
<Sleep_Walker>I like my way as I can simply separate my private packages and public packages and I'll be able to pass it to other machines when I'd like to
<mark_weaver>okay, as you wish
<mark_weaver>civodul: there are inconsistencies here in the handling of $GUIX_PACKAGE_PATH
<mark_weaver>it adds the components without gnu/packages to the entries of %package-module-path
<mark_weaver>but this is not consistent with what it adds to %load-path
<mark_weaver>or at least it seems inconsistent to me. maybe I just don't understand it yet :)
<mark_weaver>civodul: how did you intend for $GUIX_PACKAGE_PATH to be used?
<mark_weaver>because if (use-modules (gnu packages foo)) is going to find foo.scm in $GUIX_PACKAGE_PATH, then it'll have to be in $GUIX_PACKAGE_PATH/gnu/packages/foo.scm
<mark_weaver>but then we aren't looking for patches in $GUIX_PACKAGE_PATH/gnu/packages/patches
<mark_weaver>and 'all-package-modules' is looking in $GUIX_PACKAGE_PATH without the gnu/packages suffix.
<mark_weaver>(though I guess as you suggest it may search the entire hierarchy starting at $GUIX_PACKAGE_PATH)
<mark_weaver>well, I guess maybe the idea was that the modules in GUIX_PACKAGE_PATH could have any name, not necessarily starting with (gnu packages ...)
<mark_weaver>bavier`: I see that it will fall back to the system file. we now have one of those in the same place as in Debian, namely /etc/ssl/certs/ca-certificates.crt
<bavier`>mark_weaver: I see, I wasn't aware of that file.
<bavier`>we may be able to ignore the issue then, for now.
<mark_weaver>on GuixSD, that file will contain all of the CA certificates that have been installed in the system-wide profile. we currently have only one package with CA certificates: nss-certs
<mark_weaver>bavier`: what I really wanted to see was the code that creates the single-file certificate bundle that's used by Mozilla::CA
<mark_weaver>do they just distribute a copy of it, or do they build it dynamically from the upstream 'nss' package, or what?
<civodul>mark_weaver: exactly, my personal modules in $GUIX_PACKAGE_PATH are under a different name space
<bavier`>They distribute a script that can be used to create the bundle
<civodul>so in that case it just works
<mark_weaver>bavier`: I think it would be better to just use /etc/ssl/certs/ca-certificates.crt which will have the CAs the user chose
<Sleep_Walker>tolik bilych plastu
<Sleep_Walker>wrong channel again
<Sleep_Walker>I'm experimenting with split window for IRC and it is not always obvious where the message will go :b