IRC channel logs
2018-03-07.log
back to list of logs
<Apteryx>how to proceed when a software cannot work unless the user take extra action (such as setting a setuid bit on jackd)? <Apteryx>It seems the best I can do under Guix/GuixSD is to provide this information in the package description and let the user fend for themselves to do so. What do you think? <atw>I think that's the best you can do. The manual has a section on this (6.2.8) and the GuixSD way is for the system administrator to whitelist it. <atw>Apteryx: seems like the best way to do it. The manual says that the system administrator has to effectively whitelist a program for it to get setuid on a particular system <atw>I couldn't find a good example, but it might be worth grepping the existing packages. <rumpadump>Does guixsd and linux-libre work on amd 17 gen family? Aka AMD Ryzen processors. <rumpadump>I was able to boot the installation media for guixsd 0.14 in bios boot mode <rumpadump>But then I thought maybe I should install uefi grub, but rebooting into uefi mode didn't work. <rekado>There are still 508 different pyc files after recompiling all .py files. <rekado>nix and guix are separate implementations of functional package management, so they have many differences. <rumpadump>Nix had overlays and overrides, does guix have them too? <rekado>in Guix we have GUIX_PACKAGE_PATH where you can add custom modules providing custom package definitions. You can also inherit from other packages in your custom package definitions. <rekado>I don’t know how this relates to overlays and overrides, as I’m not a Nix user. <rumpadump>Overlays and overrides do just what they sound like they do, override the configuration file <rekado>override what configuration file? <rumpadump>The configuration file, the file that is supposed to define the system <rumpadump>I'm sorry I assumed nix and guix are similar and didn't explain myself properly <rumpadump>Again, now I know I should pay more attention <rumpadump>It would be equivalent to /etc/configuration.scm I suppose. <rekado>GuixSD is specified with a configuration file in Scheme. There are no overrides, but we have syntax to replace services with custom services. <rekado>that’s still functional, though. <rekado>despite the interface that implies modification, nothing is really modified. <rumpadump>Now it would be great if I get my system running guixsd quickly <rumpadump>BTW, there is some issue with uefi and AMD 17 family processors <rumpadump>In uefi the installation media won't boot, but in bios mode it does <rekado>please send email to bug-guix@gnu.org <rekado>rumpadumpagain: please send email to bug-guix@gnu.org <snape>civodul: thanks for the load* fix and the mention in the commit message <rekado>g_bor: do you know which of the tests we may disable for python-3.6? <rekado>oh, never mind. It’s the tests that I already disabled :) <rekado>with that patch even python-pandas built reproducibly; I didn’t patch the build system in my copy, so one pyc file (version…pyc) has a different timestamp. <rekado>didn’t expect pandas would make fewer problems than numpy. <MaliRemorker>since guix crew seems a bit livelier than guilers ... do you guys ever use guild? <thorwil>what the * is wrong with (bootloader (bootloader-configuration (bootloader grub-bootloader) (target "/dev/sdb2")))? <thorwil>all guix had to say was that it failed to install grub <pkill9>thorwil: i think you need to change 'sdb2' to just 'sdb' <pkill9>i think there's a commend above that line saying you need to set it to /dev/sdX (X being variable) <thorwil>pkill9: all i want is a /boot/grub/grub.cfg that i can use from the grub already present on /dev/sda <thorwil>i don't think i want a grub in /dev/sdb mbr <pkill9>oh then maybe try setting the target to '/dev/sda'? <mange>Even if it failed to install grub, I think it will still have generated a *-grub.cfg file in the store. I don't know how you could find out which one it is, though. <rekado>mange: with “guix system build config.scm” <mange>I can't see it, or `find` it in /run/current-system, so I assumed it wasn't in the built system. <snape>mange: there is a way to avoid bootloader installation <mange>You could take a list of the files in /gnu/store, then try to reconfigure and see what's new? That sounds like a pretty terrible solution, though. <snape>(if you already have grub installed somewhere else) <mange>Yeah, but then how do you get the guix-generated grub.cfg? <snape>it won't prevent its generation. Wait a minute <snape>(bootloader (bootloader-configuration (bootloader (bootloader (inherit grub-bootloader) (installer #~(lambda args #t)))))) <snape>In English: I want the grub bootloader, but with a custom install phase that will do nothing and return #t <mange>Okay, but then where does grub.cfg go? <snape>same place: /boot/grub/grub.cfg <snape>#~(lambda args #t) could be rewritten as #~(const #t) I guess <snape>Oh I talked to mange but it was you thorwil who had the issue, sorry <thorwil>i certainly don't mind, if people discuss my issue! ;) <thorwil>if init fails after doing much of the work, should the command be reused, or should one switch to reconfigure? <snape>thorwil: I think you needs to use init, because reconfigure doesn't know about your system being in /mnt. Unless you do it in a chroot? I have no idea, really, I've done this once, long time ago :-) <snape>if it's just the bootloader install phase that failed, it's probably safe to consider that the installation is an overall success <snape>Assuming you have a bootloader installed somewhere else, that is able to read grub.cfg of course <snape>(you should check that /boot/grub/grub.cfg has been generated) <thorwil>yes, i already was at the point of having a grub in the store, but no grub.cfg, since i did use --no-bootloader. to only then notice that it's useless that way :} <pmikkelsen>hi guix, I have a question that may be a bit strange. Would it make sense to have a package definition which builds a static website using one of the many static site generators, and then use the output directy in a nginx service configuration? This way, I think it would be possible to update the package definition, run 'guix system reconfigure ...' and then the new website will be used. Just an idea I had, but I would like your view on <rekado>pmikkelsen: yes, this would work. It may be a little heavy-handed to update the package definition each time, but it coudl be okay for sites that don’t change too often. <pmikkelsen>rekado: okay, I guess I will have to package the software I use first then <mange>At the moment it won't work, though, because I don't think reloading nginx config works using reconfigure. I was just reading some issues earlier, where nginx hardcodes its config and reconfigure doesn't touch running services, so it would take reboot to update. <mange>You could do it by writing a system service that puts your package/website contents into a predefined folder that nginx reads from, but at that point you might as well just put it there yourself. <pmikkelsen>What I have now is that I put it there myself via rsync from my laptop which works OK <rekado>but you need to stop nginx before reconfigure. <mange>#22039 in debbugs has some details about the start/stop issues, too. <rekado>it says: if a service is currently running, it does not attempt to upgrade it since this would not be possible without stopping it first. <mange>It's from before the rename, though, so you need to remember deco=herd and dmd=shepherd. <AMDmi3>guix web site is partially broken <thorwil>so (bootloader (bootloader-configuration (bootloader (inherit grub-bootloader) (installer #~(lambda args #t))))) <thorwil>lead to a "invalid field specifier" at the inner "bootloader" <roptat>don't you need one more (bootloader …)? <roptat>like (bootloader (bootloader-configuration (bootloader (bootloader (inherit grub-bootloader) (installer #~(lambda args #t)))))) <roptat>bootloader-configuration contains many fields, one of which is bootloader you must give a bootloader to <thorwil>ah, could be that i misinterpreted and then ... misfixed what was posted :/ <roptat>and that bootloader inherits grub-bootloader and don't install it <Apteryx>atw: thanks for confirming. Although now with a fresh head I'm seeing I might just need to propagate jackd, as the app is looking for the jackd binary. <civodul>AMDmi3: thanks for the repo, that should be fixed now (the time for the update to propagate) <atw>Morning #guix! Hello, Apteryx! <Apteryx>Is there a group my user should be in to allow this without being root: sched_setscheduler(23836, SCHED_FIFO, [1]) = -1 EPERM (Operation not permitted) <atw>rekado: and speaking of which, I think my changes should be ok on top of 30501, but I should test <Apteryx>apparently I could do this: setcap cap_sys_nice+ep ./your_program <Apteryx>to allow that particular program to use sched_setscheduler when it's not being run as root. <civodul>yes but you don't want to do this in the store <civodul>the patch backlog is quite intimidating <civodul>we should organize patch/bug squashing days! <snape>thorwil: does it work now? :-) <rekado>so, the python-updates branch seems to be good. It allowed me to build python-pandas reproducibly. <rekado>shall we build it all on hydra? It is based on staging. <rekado>I guess I could also just build it on berlin and leave hydra alone. <thorwil>snape: that'll be another reboot. soonish <rekado>civodul: on berlin I’d like to build the python-updates branch. Is it enough to change cuirass-specs in (sysadmin services) and to reconfigure? <rekado>I remember last time you modified the Cuirass database manually and ran things from your home directory. <civodul>rekado: fiddling with the database manually is all it takes :-) <civodul>first you run: sudo sqlite3 /var/run/cuirass/cuirass.db <civodul>then something like: insert into specifications values ('staging', 'https://git.savannah.gnu.org/git/guix.git', '.', 'build-aux/cuirass/gnu-system.scm', 'cuirass-jobs', '((subset . "all") (systems "x86_64-linux" "i686-linux" "aarch64-linux"))', 'staging', NULL, NULL, 1); <civodul>the first 'staging' is the jobset name, the 2nd one is the branch name <thomassgn>I'm using emacs and guix-devel-mode, I changed a package definition press C-c . b to build it but it gives me the path to the "old" package already installed... <thomassgn>how do I build the package defined at point? <rekado>civodul: should I feel bad about doing it this way? Would be more correct to do this in the config file? <rekado>wha…? For some reason none of the packages I install on the cluster are grafted. <rekado>does b672a8160755bab07fb3c13dbc43dcc26525a7b7 not do what it should? <rekado>the difference between that commit and the working patch is using package/inherit in commencement. <rekado>I’m pretty sure that glibc-final ought to use package/inherit <rekado>that would also explain why I thought that “guix environment -l” is broken wrt grafts. It is not. It’s just that the graft isn’t properly applied to glibc-final. <rekado>I’m going to push a change to glibc-final. <civodul>rekado: don't feel bad about doing it this way; Cuirass config has to be a dynamic thing, we don't want to reconfigure etc. every time we add a branch <snape>thomassgn: you need to reevaluate the package before doing C-c . b <civodul>indeed glibc-final is probably not being graft <civodul>but we should not graft glibc-intermediate either, it doesn't make sense <civodul>so ideally glibc-final would inherit from glibc, not from glibc-intermediate <rekado>so I should graft both “glibc-final” and “glibc-final-with-bootstrap-bash” from commencement (by using package/inherit). <rekado>or not graft “glibc-final-with-bootstrap-bash”, because that’s “glibc-intermediate”. <rekado>(the names are a bit confusing to me) <rekado>but when I don’t change glibc-final-with-bootstrap-bash then no grafts are applied when building “hello”. <civodul>glibc-final-with-bootstrap-bash = glibc-intermediate <civodul>(define glibc-final (package/inherit glibc ...)) <civodul>it may be more difficult than it seems though, because currently it inherits from glibc-final-with-bootstrap-bash <civodul>and we don't want to trigger a full rebuild, so care must be taken <rekado>I can’t believe I didn’t notice this until now. <civodul>yeah and i've marked your message about 'guix env' but didn't get around to investigating <rekado>it looks like guix env is fine after all. <rekado>its operation for “-l” is weird, but the grafting problem is unrelated to “guix env” and just due to the botched commit :) <civodul>still you were asking interesting questions in that message :-) <thomassgn>hmm, geiser complains about "possibly unbound variables cppunit-1.14" and xmlsec-nss. And then when I try to build the definition it gives me "ERROR: xmlsec-nss: unbound variable" despite xml module being included/used... How to get around it? <thomassgn>explicitly running (use-modules (gnu packages xml)) in geiser does not help <resh>tried all 3 Always some error pops up <resh>tried for 0.14 version in all 3 cases <resh>Has anyone done installation of GUIX on ubuntu plz help <rekado>resh: could you show us the errors? <rekado>I have installed it on Ubuntu a bunch of times. <rekado>resh: it’s best to use the official instructions from the last URL. <rekado>if you could show me the error you got I’m sure we can help you. <resh>will take time,doing it once more <snape>thomassgn: you can either manually eval the unbound variables, or kill the REPL, start it again, and 'C-c . b'. <resh>I tried sudo cd /tmp ,showing error <resh>sudo: cd: command not found <snape>resh: cd is built into the shell, you can't use sudo with it <bavier`>resh: `su -` will switch to the root user <snape>"as root" is unclear, it actually means that you need to switch to the root user because "sudo" doesn't work <thomassgn>snape: allright, didn't work though. I get the same errors from both restarting geiser and evaluating and evaluating the variables and use-module exp. xmlsec-nss is in xml.scm - don't see how or what is causing this one to fail as there's plenty of other variables/packages from modules with different names. <snape>thomassgn: did you try C-M-x within xmlsec-nss>? <resh>ohh so I should not use su- and sudo before. <snape>well for most commands, it's the same <rekado>resh: at the beginning you just need to become the root user by running “su -” <rekado>(you need to input the root user’s password for that) <rekado>you could also do “sudo su -”, which will ask for your user password. <snape>(or "sudo su", which may prompt for your password instead) <thomassgn>snape: allright, that does the trick. quite cumbersome though, it keeps throwing these at me, resolving number 3 now... :) <snape>thomassgn: as an alternative, you can just run "guix build <my-package>" in a shell <thomassgn>hehe, yes. Or not really. 'guix build -f ./libreoffice.scm libreoffice' tells me it cannot build. how can I tell it to build this definition of package...? <snape>you need to put it into GUIX_PACKAGE_PATH <snape>if it's your own package file <snape>if it's within the guix source, then guix build libreoffice should work <thomassgn>ok. But how do I know which libreoffice it builds if I say guix package -i libreoffice? I'm just testing a few things, and would like to do just copy the file and test some changes... <thomassgn>I guess I could start changing the names and so on in the package definition. <snape>if you modify Guix's libreoffice definition and run: "guix build libreoffice", it will build the modified libreoffice <efraim>GUIX_PACKAGE_PATH takes precedence over guix proper for leaf packages <snape>thomassgn: your custom libreoffice package should probably inherit Guix's one <snape>so that you don't have to copy everything <thomassgn>nice. So any package with duplicate variable-name in my GUIX_PACKAGE_PATH will always be chosen?! nice. <snape>yes, but it's probably clearer if the name is different <thomassgn>Yes, I don't entirely understand inheritance though :P I'm a bit slow :) <snape>you're not slow, it takes time ;) <snape>thomassgn: there are a few package inheritance examples in the Guix source. You can grep "inherit" in /gnu/packages/ to see them. <thomassgn>cool, I'll have a look. I've used it once in a simple thing I mostly copied. <snape>also, things in GUIX_PACKAGE_PATH need to be valid Guile modules <rekado>inheritance is a way to avoid duplication. <thomassgn>hehe, yes. I keep getting warnings from guix commands when I'm fiddling with somethings in there. <rekado>a package can inherit all fields from another package. <rekado>you can then override individual fields without having to specify others. <thomassgn>ah, but if I specify parts of a field will it append it to contents of the previous? or discard the previous? <roptat>but you can get the value by using (package-<field-name> libreoffice) <resh>roptat and rekado not inside any directory ... installed without cd to any directory <rekado>resh: so it might still be in your home directory then. <thomassgn>So if I just want to add something I have to copy the contents of the inherited field into the new def.? uh, sorry, what did you mean with (package-<field-name> libreoffice)? I ould just go read the docs ofc. <rekado>thomassgn: (package-synopsis libreoffice) gives you the synopsis of the libreoffice package, for example. <rekado>thomassgn: (package-inputs libreoffice) gives you the inputs. <roptat>for instance to add an input you would write (inputs `(("some-package" ,some-package) ,@(package-inputs libreoffice))) <rekado>i.e. the inputs field has a quasi-quoted list with the list ("some-package" ,some-package) followed by the items in the inputs field of the libreoffice package. <resh>roptat , rekado oh okay so need to mention full directory <rekado>but you could also just move it to /tmp <roptat>~ won't be the user's home when you're root though <snape>resh: you can use the 'pwd' command to know where you are, and 'ls' to list files somewhere, it might help <resh>roptat installed before entering root <roptat>so it's probably in your user's home directory <snape>resh: if the path starts with '/', it's full, or absolute. Otherwise it's relative to the result of the 'pwd' command. <bavier`>resh: do you have stuff in /var/guix from a previous attempt? <rekado>a previous attempt included running the installer script <resh>i have deleted previous dir using rm -rf <rekado>what does “ls -dl /var/guix” say? <resh>even gnu is not empty,need deletion <rekado>it’s just left-overs from running the script. <rekado>resh: in the first line you removed “var” <rekado>so you can’t move “var/guix” any more, because you removed it. <rekado>and you shouldn’t create the directory /var/guix <rekado>please follow the instructions exactly. <resh>yes, so what does that instruction on instruction page mean <resh>mv var/guix /var/ && mv gnu / <rekado>the goal here is to move the unpacked directories “var/guix” and “gnu” to their target locations. <rekado>previously you unpacked the tar.xz file, which contains “var” and “gnu”. <rekado>with this command you move them to /var/guix and /gnu, respectively. <rekado>since you’ve deleted the unpacked “var” directory, you will need to unpack the tarball again. <rekado>please be careful with “rm -rf”. You are root now and can damage your system if you delete the wrong thing. <vagrantc>in guix, is there some policy about maintaining multiple versions/forks for a given codebase? <rekado>vagrantc: we try to avoid multiple versions. <rekado>vagrantc: we keep them if there are “good reasons” <vagrantc>rekado: ah, i was wondering regarding u-boot and arm-trusted-firmware ... of which commonly there are vendor folks of one or both <rekado>oh, I don’t know much about that, I’m afraid. <rekado>AIUI we may need different variants for different ARM boards. <rekado>but that’s already the full extent of my knowledge in this area. <vagrantc>rekado: but the "good reasons" answer pretty much settles it, thanks :) <vagrantc>obviously, there's a judgement call there somewhere <rekado>in general we cannot commit to maintaining too many different versions at the same time, so we usually err on the side of picking the latest version. <rekado>in some cases this won’t be the right decision and then we’ll correct it by adding variants (possibly using package inheritance to avoid having these copies diverge). <vagrantc>ACTION saw a bunch of u-boot related commits and was hoping to add a few more arm boards <rekado>civodul: when you need me to test the glibc graft fix just let me know. <rekado>I’m eager to use latest version of Guix on the cluster again. <snape>vagrantc: your patches to support new arm boards will be very welcome :-) <vagrantc>snape: first i'll have to wrap my head around guile a bit, but i can probably get pretty far with cargo-culting based on other boards :) <vagrantc>though simply running guix pull seems like it would be a remarkable excersize in patience on these boards <efraim>vagrantc: I have some patches locally for arm trusted firmware, and I got u-boot booting on my pine64, but I wasn't able to get te board booted to TTY1 <vagrantc>efraim: i've got an unused pine64 and pinebook that i'd be happy to experiment with <vagrantc>efraim: also have some wandboard/cubox-i/hummingboard variants i might be able to test <g_bor>rekado: I've checked your message related to jeromq. <g_bor>There are two possibilities, as the whole testsuite is being refactored. Either we go with this big patch, and we can drop that on release, or we can downgrade from 0.4.3 to 0.4.2, where we don't need the patch , and wit for the release WDYT? <efraim>I should toss my pine64 os config somewhere <vagrantc>efraim: handful of other boards too, but mainline support is spotty <efraim>I also have an odroid-c2, hikey something that I forgot, and a firefly 3399 <efraim>Odroid-c2 looked good, until I realized it needed blobs to build the ATF <vagrantc>yeah, i was surprised to see odroid-c2 support at all <vagrantc>efraim: many of the boards i can test i've already got working in debian, so it's likely just a matter of making the right guix recipe <efraim>I added the package for u-boot odroid before I realized I couldn't make it work <efraim>vagrantc: does it work with grub or with extlinux? <vagrantc>efraim: most should work with "extlinux" using the distro_bootcmd support in u-boot <vagrantc>efraim: if it doesn't, i usually patch it in debian and submit upstream <vagrantc>efraim: haven't done much testing with grub, but very recent versions of u-boot have fiarly complete EFI emulation, so grub-efi should work <efraim>I get a non-standard grub screen from the pine64, and then during boot it looks like it initializes some hardware and then the screen cuts out <efraim>vagrantc: is there a spot where the debian image scripts are kept? <vagrantc>efraim: there aren't really images, other than the debian-installer images <vagrantc>efraim: there's a bit of a legacy-keeps-growing-new-features package called "flash-kernel" which generates u-boot boot scripts <vagrantc>efraim: there's also u-boot-menu which generates extlinux-style boot menus <efraim>I don't think I've ever actually run the arm64 debian-installer, just debootstrapped a couple of times <efraim>i'll check those out, should be cleaner than armbian's scripts <efraim>they actually patched boot0 back in for the pine64 <rekado>g_bor: I’d rather not downgrade. <rekado>civodul: looks like cuirass on berlin doesn’t do anything. <rekado>I added a record for the python-updates branch and all I could see in the log was GC warnings. <rekado>GC Warning: Repeated allocation of very large block (appr. size 186150912): <rekado> May lead to memory leak and poor performance <bavier`>Sleep_Walker: is the patch package in config.scm's 'packages' field? <Sleep_Walker>removing the package from the list makes problem go away :| <jonsger[m]>Sleep_Walker: guix seems to be broken again due to pkgconfig... <Sleep_Walker>jonsger[m]: scarabeus reverted guile back to 2.0 which caused all new problems, but home:sleep_walker:guile have it all good ;) <bavier`>Sleep_Walker: patch is in %base-packages <bavier`>Sleep_Walker: so if you add it yourself, you'll get two versions, which leads to the error <Sleep_Walker>bavier`: you are right, but why it ends with different hash? <bavier`>Sleep_Walker: the 'patch' in %base-packages is the "canonical package" <bavier`>Sleep_Walker: afaict, the patch in %base-packages is the one gnu-build-system uses, rather than the top-level package <civodul>rekado: 2018-03-07T22:35:13 spec 'python-updates': fetched commit "accec9d67f78b5dab88eb815d17e92365b9d9ce4" (stamp was "") <civodul>it seems that it's still evaluating the branch <civodul>rekado: i just pushed the package/inherit thing for glibc-final <axg>So, I'm trying to install java, and while there is many packages that come up, nothing looks like openjdk or openjre in any way. Who is using java successfully and what package did you grab to get the javac and java? <civodul>mbakke: do you think we're ready to merge 'staging'? <mbakke>civodul: not sure, we're still lacking many substitutes (evolution-data-server). There's also been a lot of activity on master, so IMO we should merge and do another eval first. <civodul>did you check whether berlin has more substitutes? <mbakke>Also, I haven't actually tested GNOME yet after the EDS upgrade. <mbakke>Me neither and "afk" atm. I don't expect any problems, so it should be safe to merge. But would like to test GNOME first. <mbakke>I can merge and start a Hydra evaluation in a few hours if Hydra isn't too busy. <mbakke>But feel free to merge if the weather is good ;) <civodul>ok, i guess i should take a closer look first :-) <rekado>civodul: thanks for taking care of the glibc graft! <rekado>civodul: re cuirass on berlin: yeah, it’s finally doing something. I restarted it after about an hour. <civodul>that shouldn't have been necessary, but maybe it went amiss <jackhill>I'm looking at the postgresql package and would like a postgres build with SSL and gssapi support. How are optional features usually handled? Would it be okay to submit a patch that added those to the existing package, or something else so not to increase the current closure size? <bavier`>hrmm, or, it might work if *all* the packages you want to install have substitutes available <bavier`>confirmed, if the proot'd guix-daemon ever needs to build something, failure <bavier`>guix package: error: build failed: cannot change ownership of ?/gnu/store/af19ma2vm3qhvh3rw6cdivyp98s18bj3-guile-bootstrap-2.0.drv.chroot?: Operation not permitted <civodul>that doesn't seem related to proot though, does it? <bavier`>maybe not, I was missing the '-0' flag... <bavier`>ok, now I get "guix package: error: build failed: cloning builder process: Operation not permitted" <bavier`>that's definitely a problem, probably my kernel is too old <bavier`>what's the version that's needed for NEWNS? <rekado>jackhill: it depends on how common this feature is and how much larger it makes the package closure. In some cases it may be good to add a “-minimal” variant for use with other packages and a regular variant for installation. <bavier`>oh, 2.6-ish, my kernel has all those then, maybe processes cannot clone inside proot? <civodul>bavier`: i think we had EPERM in containers too, but i can't remember why <bavier`>the daemon refuses to build anything as root (faked inside proot), but I don't see any way to add fake users in proot or ask the daemon to just build as the current unprivileged user <civodul>it may be that the clone thing requires "real" root <civodul>jboy: what does "herd status | grep cow" return? <jboy>I'm using the 0.14.0 qemu image <rekado>jboy: the qemu image is just a virtual machine image, not an installer. <jboy>rekado: ah, thanks. guess I misread the instructions in an earlier step <jboy>Ludovic's PGP key has expired. <vagrantc>pub rsa4096 2014-08-11 [SC] [expires: 2018-04-23] <vagrantc> 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 <vagrantc>uid [ undef ] Ludovic Courtès <ludo@gnu.org> <jboy>yes, it expired 2017-10-28 <jboy>oh, I see he changed the date of expiration <soundtoxin>Any menu I open in icecat (right click, global menu, addon menus, etc.) closes instantly. Anyone else have this issue?