<axd-v>Owncloud-client package is failing to compile on guix commit <axd-v> d53e5b366d03ce29a16d96fbf91075a2de5bbd55 <axd-v> I filed a bug yesterday about a similar issue with keepassxc package and it was fixed in a few hours. This might be a similar issue with qt5 or whatever <axd-v>Is it normal procedure to file a bug every time a package reproducably fails to install/update/compile? <axd-v>ngz: ok, just didn't want to pollute the mailing list with little issues like small libraries and other packages not compiling properly or having some other problem. <marusich>axd-v, it's worth checking to see if the package was fixed on one of the other branches - staging or core-updates - but yes, that's the general practice. <axd-v>marusich: how would I go about that? Haven't messed around with other branch as of yet. <marusich>I don't know of a generic way to accomplish the task. But, if I were going to do it, I'd search bug-guix and guix-patches (two Guix Debbugs projects for bug tracking and patch tracking, respectively). I'd search the email lists for any recent mention of the package in question, using the Namazu web search page for them. And I'd get a local copy of the Guix Git repository and use "git log origin/master" or "git log origin/staging" or "git log <marusich>origin/core-updates" to search for possibly related commits. There are a lot of commits, so it might be helpful to parse the output for likely keywords, or to limit the "git log" to the file in question (e.g., "git log origin/core-updates -- gnu/packages/sync.scm"). <marusich>However, in this case, I think it's unlikely that changes to the package itself will show up on those branches. This is because the owncloud-client package has no dependents, and packages with no dependents are usually updated directly on the master branch. <marusich>We put changes that cause lots of rebuilds onto other branches (see (guix) Submitting Patches). <marusich>You can see the count of dependents by running "guix refresh -l owncloud-client", and it reports that there are none except itself. <marusich>So in this case, I think you're best bet is to search the email lists for keywords related to your problem, such as the error message itself. <marusich>If nothing shows up, it's probably the case that nobody has worked oni t. <marusich>That might have been more info than you needed, but I hope it helps. <axd-v>marusich: thank you very much for the detailed explanation. I'm gonna explore what you've provided me with. <marusich>OK! Don't stress too much about it, though. It's nice to avoid duplicate work if you can find that somebody worked on it already, but if you've got a problem, asking here, on the mailing list, or reporting a bug are the right ways to go. <axd-v>rekado_: question about your .xsession file. You have `exec exwm` as your last line. You also said that you still use slim. Does having exwm in the .xsession file interfere with slim's selection of a wm? Because at the moment I use slim to select either i3 or exwm as my wm. How would `exec exwm` play out if I choose a session using slim? <axd-v>Do you still choose exwm in slim when loggin into your session? <marusich>I think if you choose a session at the SLiM login screen, but your ~/.xsession ends with "exec exwm", your choice at the SLiM login screen will be ignored. <marusich>That's because when you select a desktop session from the SLiM login screen, Guix will call your ~/.xsession file (if it exists) with arguments. Those arguments are the command line invocation that will start up your selected desktop session. If in your ~/.xsession you choose to ignore those arguments, then the desktop session you selected will be ignored. <axd-v>marusich: I see, makes sense. Would you by any chance know where wms put their xsession files by default? <marusich>If I recall correctly, the way it's done in GuixSD is by extending some service... <marusich>Let me see if I can find something helpful. <marusich>Check the find-session procedure. It will find files like "PROFILE/share/xsessions/FOO.desktop", where PROFILE is a Guix profile, and FOO is some file. <marusich>Oh, actually this isn't quite what you were looking for. Looks like that only comes into play when ~/.xsession doesn't exist. <marusich>What you want is described in (guix)X Window in the manual./ <marusich>Look there, and you'll find out how to add your own desktop session to the list of menu items shown by SLiM. <marusich>You can immediately browse to it in the Info reader by pressing "i" and typing "slim" and hitting enter. <vagrantc>ACTION found it didn't remember which session i selected, and would always default to the default <vagrantc>hence, ~/.xsession being the only way to actually get what i wanted <axd-v>marusich: alright, that's perfect, I'll look at it. <axd-v>vagrantc: yeah that's part of the problem. ***jonsger1 is now known as jonsger
<efraim>rekado: python[2]-pyqt built with ptwebkit removed and the other diff I posted to the bug report ***jonsger1 is now known as jonsger
<efraim>rekado, civodul: success on matplotlib after disabling qtwebkit in python-pyqt <civodul>so i'd be in favor of taking that qtwebkit-less approach for now <efraim>i'm building to owncloud-client next, saw this from qtwebkit's config dump: Build ......................... webkit1 webkit2 <efraim>even if we take our time dumping qtwebkit we might want to dump webkit1 anyway <efraim>that's why I left it commented out rather than fully remove the line <efraim>They have some other machines also <efraim>Wikipedia has a bunch of info on the 3b line of MIPS chips <efraim>that's actually where I get most of my info on it <jonsger1>efraim: do you wan't to revive the mips port of guix? <efraim>It currently looks more ready for desktop usage than aarch64 but my hands are pretty full as is <jonsger1>I'll go for power9 on talosII, due to their dropping prices <civodul>/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/include/bits/string_fortified.h:34:10: internal compiler error: Segmentation fault <civodul> return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); <civodul>rekado: is this the kind of thing you experienced before? <rekado>but I’ve seen this also in the past, even years ago <civodul>i wonder if it could be due to my patch :-) <civodul>yes it's in my code, in store_reference_p :-/ <jlicht>ACTION just read that microsoft will be acquiring github. <jlicht>We will probably have a lot of upstream url changes the coming few weeks :-) <rekado>is it normal that the pyqt build freezes with “starting phase `configure'”? ***Exagone314 is now known as Exagone313
<jlicht>but eventually it started doing something again <mbakke>ffmpeg behaves the same way, perhaps we can increase verbosity of those configure scripts. <civodul>mbakke: most likely these are home-made configure scripts no? <nee`>What's the best way to remove old system generations? Can I just /var/guix/provfiles/system-x-link and run guix gc? <mbakke>nee`: that is currently the best approach. <roptat>is there a way to change grub's keymap for entering the passphrase of an encrypted disk? <civodul>keymaps in general are an issue, there's an open bug for that <efraim>how do I get the uuid of a fat partition? <civodul>or a Guile REPL with (gnu build file-systems) loaded :-) <roptat>I think I've found what commands I need in stateful OS's to load keymaps in grub, but I don't really know where I should start in guix <roptat>I need to run grub2-mklayout to generate the layout, then I can use "insmod keylayouts" and "keymap <keymap.gkb>" <roptat>but I don't know if that's loaded before grub asks for the passphrase <civodul>there must be a way to include keymaps and the keymap module in GRUB's "stage1" <roptat>what's the status of npm in Guix? <bill-auger_>nah too dignified - more like unwelcome vermin infestation <Gamayun>roptat: For encrypted disks I tend to stick with the insurance policy of always adding another passphrase with the same keys typed in the basic us keymap. ;) <civodul>roptat: jlicht went quite far with an importer as part of GSoC 2 (or 3?) years ago <jlicht>roptat: I have an npm importer lying around that kind of works, but is kind of dinky atm <civodul>jlicht: we should prolly merge it though <jlicht>civodul: I have some time upcoming weekend, and could clean it up and at least have it usable for leaf packages indeed. <bill-auger_>frankly i would think that guix would see any un-monitored third-party package manager that is capable of installing unvetted, unverifiable packages as abhorent <roptat>we're making the situation better though <roptat>by using guix to install javascript packages, you at least install them from source, and they become verifiable <civodul>don't hold your breath though: see the article above <jlicht>bill-auger_: guix could replace npm (the package manager), but replacing npm (the existing registry of all js packages) is a different and more difficult problem <jlicht> on a less depressing note, I'm halfway packaging bds (Beyond Dying Skies) :-) <rekado>On core-updates “java-picard-1.113” fails to build because of an error in the “generate-jar-indices” phase. <civodul>vigra fails to build on core-updates: "Failure in MultiFFTTest::testFFT2D()" <civodul>rekado: anthraxx of Arch is telling me that they build Bazel entirely from source, FWIW :-) <rekado>wait, including the Java things? <civodul>they seemed even shocked that i was questioning this ;-) <rekado>I have often been disappointed whenever I looked into the processes other distros have in place for Java things. <civodul>anthraxx even offers a beer if we get it done <civodul>well i was under the impression that nobody was doing the work <civodul>but apparently i must have been pessimistic, dunno <rekado>a single beer is not motivating enough, I’m afraid :) <rekado>one of many big obstacles I see is that Bazel bundles the JDK 9. <rekado>There is no icedtea build system for that version. <rekado>maybe it’s fine to use JDK 8 instead. <civodul>and "for d in examples third_party tools"... <civodul>there must have been a misunderstanding <rekado>yeah, they just use the bundled tools. <roptat>is it because we haven't packaged openjdk9, or is there no openjdk9? <rekado>there is openjdk9, but there’s no corresponding icedtea. <rekado>I haven’t attempted to build openjdk9 directly. <civodul>apparently JDKs are on a 6-month schedule now <rekado>the JDK9 has been out for a long time, but there has not been a new icedtea. <roptat>what's the difference between icedtea and openjdk? <rekado>icedtea is a build system for the openjdk. <rekado>it removes some non-free parts (I don’t know if that’s still necessary) and ensures that the openjdk can be built with free software tools. <civodul>and provides a ./configure build system, IIRC <rekado>It is possible that we don’t *need* icedtea for JDK 9 and greater; that we can just use the latest icedtea package to build the OpenJDK directly. <roptat>I'm having trouble even to find the source code <roptat>there's a configure script in there... let's try to run it ***Gamayun_ is now known as Gamayun
<rekado>I wonder why pyqt is an input to matplotlib at all. <rekado>the configure phase of python2-matplotlib just informed me that PyQt5 could not be found. <roptat>in a guix environment, can I exclude a package? <roptat>like I want all the inputs of openjdk, except openjdk7 <roptat>the configure script fails because it finds openjdk7 instead of openjdk8 that I added with --ad-hoc <rekado>maybe it’s better to start with a package definition. <rekado>you can define a package for openjdk9, inheriting from 8 and removing 7 from the inputs. <rekado>and then use that package with “guix environment”. ***jonsger2 is now known as jonsger
<civodul>if that's useful enough we could make a --without-input package transformation option <efraim>re owncloud, there's a newer version and a beta version, both are good candidates for building with qt 5.11 <bavier`>I'm getting "wrong type to apply '#f'" in several tests with current master <efraim>linux-libre kernel ftbfs on aarch64 on core-updates <CornBurglar>Hello, running into a problem while installing GuixSD: "grub-install: error: failed to get canonical path of '/boot/efi'. <rekado>FWIW, the locale problems I had were limited to building a project that was configured with tools from an environment that was made with Guix from “master”, while the rest of my system is on “core-updates” <rekado>so there really isn’t anything wrong after all. <axd-v>Hey everyone. I'm trying to configure my custom xkb layout. I have two ways of approaching it: 1. Generate my whole layout or 2. Add my layout as a varient of `us` layouts. Let's focus on option 2 right now, since 1 entails more steps. Since I can't modify system dirs, I found out that I can just recreate the whole ../share/X11/xkb dir in my $home @ ~/.config/xkb. Then I use option -I to setxkbmap to specify my alternative directory. <axd-v>However, I'm testing it with just modifying slightly any layouts already in place at symbols/us and none of my changes to their definitions is evident. The internet suggested that there is a cache that I need to deal with. Well it's supposed to be located at /var/lib/xkb. It's obviously not there but I can't find it anywhere so that I could delete it. Can anyone help? <axd-v>I'm supposed to find files that end in .xkm, but it's non-obvious where they might be. <mbakke>sneek: Later tell CornBurglar there is a bug in the Guix 0.14 installer where the ESP needs to actually be mounted at `/boot/efi`, not e.g. `/mnt/boot/efi`. :/ <bavier`>we can rebuild sneek; we have the technology ;) <axd-v>anyone know about that stuff with xkb maps? <reepca>hm, how does one specify a source for a package that's on one's own system? Uri that looks like "file:///..."? <roptat>rekado: I'm building openjdk9 right now :) <roptat>it's in an environment container, but I had to run "ip l set lo up" to make it work <roptat>oh, attempt to use impure library after some time <civodul>GUIX_LD_WRAPPER_ALLOW_IMPURITIES=yes FTW! <rekado>I’m having trouble using (ice-9 match) inside of a gexp. <rekado>I get a runtime error when the builder is executed: “Unbound variable: a”, where “a” is a variable in a match expression. <roptat>rekado: I bought a librem after all <roptat>I received it and install guixsd, but somehow the mouse doesn't seem to work in the graphhical environment <roptat>it worked in the installation image, so we have the drivers <civodul>rekado: it may be because 'match' wasn't expanded, which may be because (use-modules (ice-9 match)) is missing or is not at the right place <rekado>the expression was #~(call-with-output-file #$output (lambda (p) (use-modules …) … (match …))) <rekado>but it must be #~(begin (use-modules …) (call-with-output-file …) …) <roptat>so I can't set lo up in the build environment it seems <rekado>roptat: the mouse works for me. Do you have some xorg configuration that disables it? <roptat>I added a configuration for the keyboard layout <rekado>I had the same problem initially. <rekado>(I no longer use that evdev configuration snippet) <rekado>you either need to add the configuration for the touchpad to the evdev snippet or remove it. <rekado>I removed it because I wasn’t patient enough to figure out what configuration to use.