<rekado>issues.guix.gnu.org does use a session cookie for comments :-/ <rekado>I think I can do without, though <rekado>AIUI our use of the cookie is fine, though, because it does not contain personal data. It’s just a server-provided signature of the current issue number. <marmulak>well I set $CC but opam init still gripes that I don't have cc, which it doesn't say is a requirement but procedes to set up anyway. Only problem is when it tries to build ocaml it fails and it also doesn't say why <marmulak>Does anybody know: ld: cannot find crt1.o: No such file or directory <leoprikler>can someone explain to me why printHash32 counts from n -> 0, while parseHash counts from 0 -> n? <joshuaBPMan>hey guix, anyone know any guix fonts that have good emojis? <marmulak>so when opam tries to build ocaml the config fails one way or another, like if CC is gcc then it's broken as it is, if I set it to clang then it gets one check but fails by saying /lib/cpp is not sane <lfam>Sounds like there is a sanity check that checks if /lib/cpp exists <marmulak>it's possible I'm just missing some package <marmulak>gcc being broken sounds kind of serious, but I could try a lower version. 9 is still kind of new <lfam>marmulak: Can you clarify what you're trying to do? <marmulak>trying to initialize opam ultimately but for now just build a C program or something <marmulak>I have written hello world in C and even that doesn't compile, so I'm not sure gcc-toolchain is really doing its job <leoprikler>I'm pretty sure the bug is elsewhere in your setup. <marmulak>maybe there's a command to verify the packages/system <leoprikler>marmulak: echo '#include <stdio.h>\nint main() { puts("Hello, world!"); return 0; }' > hello.c <leoprikler>guix environment --pure --ad-hoc gcc-toolchain -- gcc hello.c <marmulak>now to figure out how to work that for opam's building <marmulak>by the way, does shutdown not work normally on guix like I'm used to? <lfam>Depends on what you're used to. If you're having a problem, let us know... <marmulak>last time I tried I don't think "shutdown -h now" worked, but I am going to try again soon once this update finishes <lfam>marmulak: You can use `halt` <marmulak>but doesn't that not really properly shut down the system <lfam>There's also the shutdown command <lfam>Note that the implementation of these commands is different from system to system. Ours are specific to Guix / Shepherd <jfred[m]>Hmm, that's odd, my substitute downloads from ci.guix.gnu.org are super slow right now. ~230 Mb/s from ci.guix.gnu.org to my VPS's region, ~800 Mb/s from my VPS to my laptop, <1 Mb/s from ci.guix.gnu.org to my laptop direct <jfred[m]>Maybe some router along that route is overloaded, heh <lfam>jfred[m]: I had that too <lfam>From eastern North America <lfam>I'd guess it's a case of network congestion <lfam>No way! I'm in Philly too <lfam>I've never talked to another Philly person here :) <lfam>I'd guess it's a case of literally everyone watching TV online right now <jfred[m]>always weird how network congestion shows itself, you can sometimes dodge it if you bounce through a VPN somewhere haha <lfam>I'm on comcast if that's a valuable data point <jfred[m]>likewise, so that might have something to do with it <jfred[m]>this may be a good excuse for me to set up a VPN on a server somewhere heh *jfred[m] wonders if there are enough of us for a Philly Guix meetup <lfam>You would be the first I've met here <lfam>I'd love to try to get a little group together. Maybe it could piggyback on something else to start <jfred[m]>Fair, though it's not something that always comes up :P <lfam>This only help after the you've downloaded the stuff the first time, but if you have multiple Guix machines, we share the code for nginx caches: <lfam>Specifically the mirror.conf and mirror-locations.conf files <lfam>I point my machines at a private mirror cache I run <jfred[m]>I don't yet have multiple guix machines, but if I start running it on my servers that could be useful <lfam>Yes, it helps me in general, although I found myself tapping my foot an hour ago <marmulak>I think when I ran system reconfigure it installed gnome3 this time lol <Blackbeard>I've been looking a few melpa modes I want to package <jfred[m]>yeah, emacs packages are generally pretty straightforward <jfred[m]>there are a few odd ones looks like, but most of them are just "what's the name/where's the source/what's the hash" <anadon>Getting to the butchering of the Django packages. With 1.11 falling out of support on April 1, there are a ton of packages which have to get removed. I don't like how this is growing. It feels like many projects have just decayed. <anadon>Looks like the biggest thing which gets axed is `pootle`. After removing that, maybe this won't be so brutal? <brendyyn>lfam: I just tried updating python-txtorcon and saw your post. the packge seems to require geoip now :x, i guess thats not packaged since its proprietary data.. <raghavgururajan>Folks! What is the convention for git commit message, for adding mirrors in download.scm <bricewge>raghavgururajan: Have a look at the git log for this file to get some inspiration <bricewge>xelxebar: Thank you for sharing that. Did you manage to get the serial console working in the end? ***rekado_ is now known as rekado
<rekado>marmulak: GCC 9 definitely works. It may be that opam overwrites or clears environment variables that are necessary for the “gcc” executable. <rekado>consider writing to help-guix@gnu.org with details (e.g. how to reproduce this) <guix-vits>leoprikler: great; i'd both renderers working, probably gles30 should be default; updated submit message for [#40495] <bricewge>rekado: I know why mumi responded with an error when commenting through the web interface: #39332 was archived. <bricewge>Commenting should probably be disabled for archived bugs. <rekado>bricewge: archived bugs should be unarchived when commenting <rekado>there still are problems with sending email from issues.guix.gnu.org which (I guess) relate to the environment in which the service runs. *raghavgururajan requests any available commiter to review and push #40484 and #40487. :-) <kondor[m]>Is defining a function in a guix package module file frowned upon? So far, the modules i've seen are pretty declarative <kondor[m]>I thought to define a guile function to give me a skeleton for a particular set of java libraries that come together. Sure, there is an option to "inherit" a package, but that has it's limitations. <kondor[m]>it doesn't need to be a function, a simple hygienic macro would do, something like syntax rules <rekado>kondor[m]: it’s fine to define functions to help you instantiate packages <rekado>in tex.scm you can see an example <rekado>many of the texlive packages are built from simple-texlive-package <bricewge>Remove ~/.config/xfe, start xfe it ask for a location of it's config, choose cancel -> segfault <bricewge>Starting it again always result in segfault *guix-vits M-x battery (jokes about OS-in-OS) <raghavgururajan>bricewge Did you execute the binary manually by going to the store directory? If so, could you try guix install and run from terminal? <raghavgururajan>bricewge Yes, the lint warns about the source URI. The web server of home-page takes quite a while to load. <raghavgururajan>Also, SSL cert mismatch. That;s why I used "http" instead of "https". <raghavgururajan>Ah I see, could you try outside env? Like, first `./pre-inst-env guix install xfe` inside env and then `xfe` outside env after adding profile path. ? <bricewge>As expected installing it changed nothing <bricewge>I'm missing icons too, but I'm not sure if it's required in Guix <raghavgururajan>May be someone else could try and see if the seg-fault is reproducible? *raghavgururajan was hoping smoothness with fox and xfe. <xelxebar>bricewge: Yes, serial console works. I mention it in the email, but for some reason the only way to get 'serial' and the 'terminal_*' settings in grub.cfg is to set serial-speed or serial-unit to some non-default value. <bricewge>Guix System. Good except the linting issue about doxygen <bricewge>xelxebar: Cool. Yes that's how it's coded <bricewge>raghavgururajan: To reproduce, `mv ~/.config/xfe ~/.config/xfe.bak` `./pre-inst-env guix environment --ad-hoc xfe --pure`, select cancel on the popup <xelxebar>Well, the slightly problematic thing is that, 'serial' is needed in grub.cfg to initial the serial device, *even without providing default values*. <Blackbeard>i think elogind is what is suspending my computer, even without GNOME <Blackbeard>but to be honest I am tired, so I will check tomorrow <xelxebar>bricewge: I'm not sure it's even possible to serial working with just the standard defaults of unit 0 and baud 9600. <jeko>Hey Guixters ! I want to play with guile's exceptions. In order to do that, I need Guile 3 but I can't even make an environment using it... Guile 3 it packaged in guile-next, right? <bricewge>xelxebar: Just use “(serial-unit 0)” instead of the speed it should do. <bricewge>If I remember well if it's enabled the graphical isn't use at all <xelxebar>Hrm. Thought I tried that and saw serial, terminal_* getting elided. <bricewge>xelxebar: This setting generate “serial --unit=0” <xelxebar>Hrm. Maybe I my fumbling tests messed it up in some other way <xelxebar>So, to disable the gfxmode stuff, I included (theme (grub-theme)) in bootloader-configuration, but are you saying that with serial enabled, that shouldn't be needed? <PotentialUser-41>hey, is the blog post on depreciating the linux-libre kernel an April fools joke or is it real? <brendyyn>PotentialUser-41: however, it is true there has been some development in getting guix running on hurd successfully. <bricewge>xelxebar: No, that if serial would be set by default people expecting to have the graphical Grub theme wouldn't <brendyyn>PotentialUser-41: what brings you here? i you writing something about guix? <PotentialUser-41>why would guix not have been written in haskell though? it's better than scheme <bricewge>raghavgururajan: I don't know what's happening there, someone else should try building it <smithras>jeko: Yes, Guile 3 is available as guile-next <brendyyn>PotentialUser-41: this kinda discussion has occured before and is in the chat logs, there are some interesting reasons. it may be that we are blessed with too many good things and haskell could also work for this project just fine. but scheme has its strengths <smithras>jeko: I don't have any problems making an environment with `guix environment --ad-hoc guile-next` <xelxebar>bricewge: Ok. Thanks. Looking at gnu/bootloader/grub.scm, I'm not sure why my setting of (serial-speed 9600) was getting elided... <xelxebar>It was late and there were several moving parts. Perhaps I just missed something. <xelxebar>By the way, is there a good way to test out changes to operating-system without doing a full guix system reconfigure? <PotentialUser-41>brendyyn: I don't know if it's just me but after a successful struggle in learning haskell, other languages are just dull to me, I'll try and learn scheme in a few hours since I've seen it's not that different from elisp just for the software freedom offered by this distro <xelxebar>PotentialUser-41: If you like Haskell and want a brain stretch, you might enjoy J or APL. <brendyyn>PotentialUser-41: I haven't learnt it but it sounds like noone can pretend it's not difficult to learn. If we want the largest audience to be able to take part in using and developing Guix, is it not better that it's simple? <PotentialUser-41>brendyyn: ()()()()()()()()()()()()()()()()()()()()()()()()()() is not a simple thing to look at haha! <jeko>smithras: Ok, thank you for the confirmation. Maybe you know why after `guix environment --ad-hoc guile-next` `guile --version` returns guile (GNU Guile) 2.2.7 ? <rekado>jeko: what does “echo $PATH” say inside the environment? <rekado>I’m guessing that your bashrc contains something that overrides the environment <jeko>rekado: /home/jeko/.guix-profile/bin:/home/jeko/Builds/kindlegen:/home/jeko/bin:/gnu/store/5win5rywbknr2fm1xcimf7hmf8nn47da-profile/bin:/home/jeko/.guix-profile/bin:/home/jeko/Builds/kindlegen:/home/jeko/bin:/home/jeko/bin:/home/jeko/.guix-profile/bin:/home/jeko/.guix-profile/sbin:/home/jeko/.config/guix/current/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin <rekado>are you adding /home/jeko/.guix-profile/bin:/home/jeko/Builds/kindlegen:/home/jeko/bin to PATH in .bashrc? <rekado>because it sure looks like you do <rekado>what likely happens is that guix environment spawns a new shell with all the right environment variables, and then bashrc is loaded which overrides PATH. <jeko>at the end of my bashrc I `source ~/.bash_profile` <rekado>put this in ~/.bash_profile instead <rekado>bashrc is loaded for *every* shell, bash_profile is only loaded for so-called login shells. <rekado>since “guix environment” spawns a sub-shell you really don’t want to use .bashrc to override these variables. <jeko>rekado: thank you, it is fixed right now! I can go to hack <brendyyn>PotentialUser-41: I respect your enthusiasm :). <civodul>janneke: lots of cwazy things landed on wip-hurd-vm! <janneke>civodul: guix download now fails on name resolving <civodul>still these two annoying /dev/console messages <civodul>we'll have to pass the screenshot through GIMP <rekado>what needs to be done to fix the GNU logo? Isn’t this the right font? <civodul>name resolution, could it be that resolv.conf is bogus? <janneke>civodul: given that i know nothing of that all, it could be :-) <janneke>wakeup rekado, or you might miss it ;) *janneke tries to help with a frienly nudge <rekado>do we still need to build wip-hurd? Or should ci.guix.gnu.org build wip-hurd-vm instead? <xelxebar>I assume that not every package exaustively ports the configuration syntax to some scheme equivalent, so how does one go about configuring, say, dovecot or cron or whatever? <rekado>xelxebar: take a look at the documentation. <rekado>xelxebar: for dovecot there’s a heading “Dovecot Service” which describes the configuration <rekado>this differs from service to service <rekado>some only provide a configuration record with a single field for specifying a config file. <rekado>others have a more elaborate Schemey syntax <civodul>rekado: i think we'll rebase/clean up wip-hurd-vm and merge it into core-updates once we'd done playing :-) <civodul>so it doesn't need to be built on ci. IMO <civodul>i realized that by running "./pre-inst-env guix weather -m etc/system-tests.scm", we lead 'guix publish' to create nars for disk images <civodul>something we'll have to pay attention to, rekado <civodul>perhaps adding another mcron job if that becomes an issue <civodul>because the TTL on publish is quite long <civodul>or we could just mark disk images as non-substitutable <mbakke>making disk images non-substitutable sounds like a good solution <NieDzejkob>mbakke: update on the core-updates failures you mentioned to me: I don't think I'll be able to find time to look into it in the next two weeks. Sorry, my schedule just got more cluttered. Don't block on me if that's all that's left to do <mbakke>NieDzejkob: no worries, I'm sure there is plenty of work left even in two weeks ;-) <NieDzejkob>mbakke: OK. If you decide to tackle one of those, let me know, then :D <mbakke>I'll work my way through 'guix weather --display-missing -c 20' and see how far I get :-) *mbakke attempts a new merge of master into core-updates <civodul>i'm adding #:substitutable? all around, not great but hey <xelxebar>rekado: Oh shoot. This is way more extensive than I realized. So, in general, is it expected that each package offers some api into its configuration? <civodul>there's ongoing discussion about "parameterized packages" though <civodul>"some API into a package's configuration" <civodul>oh, were you talking about services? <xelxebar>I'm just trying to learn the ropes with my new, shiny guix system. <ilikeheaps>civodul: I'm interested in those parametrized packages. Does that already exist? Is it like a function that takes some kind of a config and returns a package? <xelxebar>I probably am talking about services, mostly? Can services essentially be thought of as the guix terminology for "daemons"? <xelxebar>I guess I should start reading from a more fundamental place in the docs <xelxebar>Trying to translate my traditional server expectations to the guix way. <leoprikler>services are sometimes analogous to daemons, but not always <civodul>ilikeheaps: it exists in that you can always write procedures that return packages <civodul>but the goal here would be to have something more streamlined, more discoverable, accessible from the UI <leoprikler>a service can just as well be something, that symlinks a bunch of files to a well-known location, etc. <xelxebar>In my head, on say Debian, I install packge foo and then configure something like /etc/foo/foo.conf, also potentially starting the /bin/food daemon or whatever. <xelxebar>Hrm. What's the sharp definition of a service? <leoprikler>you'd extend shepherd-service to start /bin/food and etc-service to define /etc/foo.conf <mbakke>wew, tests/guix-build.sh now fails after a merge <leoprikler>there is no "sharp" definition AFAIK. A service is anything, that does things outside a package scope imo <xelxebar>What if it's just something like gnuchess and we want to tweak the global defaults in /etc/gnuchess.conf? So something just inteded to be occasionally run locally? <leoprikler>don't you have ~/.config/gnuchess.conf for per-user configuration? <mbakke>hm, looks like it failed because I did not clean all test-tmp and t-guix-build-* files before running 'make check' <guix-vits>raghavgururajan: how can one test this possible-segfault issue? <rekado>xelxebar: for global defaults we’d probably just patch the installed file in /gnu/store/…-foo/etc/bar.conf <rekado>generally, placing files in /etc is icky <rekado>there are some packages that won’t work without global files in /etc and for those we use services <mbakke>civodul: it passed on the second try *mbakke concludes the merge <rekado>when we configure packages their sysconfdir is usually not /etc but /gnu/store/…-foo…/etc <rekado>so defaults still work, they just aren’t global <civodul>mbakke: always try twice, you never know <xelxebar>civodul, rekado, leoprikler: Thanks for entertaining my basic questions. Will take the remainder of my questions up with the docs and repo before bothering you guys with more for now. <dutchie>what should I do to get python imports working in an ad-hoc environment? <dutchie>ah, including python in the list of packages does the trick <rekado>dutchie: the reason why this works is that the “python” package has a search path specification, which tells Guix to set PYTHONPATH when it is installed. <rekado>PYTHONPATH lets Python find all other Python packages that are in the same profile. <dutchie>yeah, i think i dug that fact up from the back of my mind somewhere <rekado>the “python” package only provides “python3” (because that’s what upstream installs) <rekado>your “python” is your system’s Python <rekado>a good idea is to use “--pure” when you’re using a foreign distro <rekado>to clear environment variables (such as PATH) <dutchie>does that automatically include coreutils etc? <dutchie>I considered that but assumed I wouldn't be able to ls <brendyyn>include coreutils in the list. guix environment --ad-hoc --pure python coreutils <TZander>heya, is the gnunet packager here? I'm guessing this is a packager bug: $ gnunet-setup -v gnunet-setup v(null) <brendyyn>TZander: where did you get that gnunet-setup command from? I don't see it in the gnunet package <brendyyn>do you have another older gnunet on your host system? *guix-vits "now in emacs -with-x" <TZander>brendyyn: ah, this is from gnunet-gtk, I installed them at the same time <TZander>brendyyn: both downloaded, not compiled <TZander>switching back to the previous generation and its gone, so, yeah, the exe is from guix <marmulak>rekado: about opam working, I think there are multiple issues to be resolved, but I couldn't get gcc to compile hello.c even on my own (no opam), so that was one thing probably wrong <mbakke>not sure if there is a way to tell it to ignore all failures and try again *mbakke studies database schema <civodul>mbakke: failures are cached by "guix-daemon --cache-failures" <civodul>you can run "guix gc --clear-failures ....drv" <civodul>you could run guix gc --clear-failures $(guix gc --list-failures), but we'd end up rebuilding lots of things known to fail <mbakke>i.e. running 'guix build /gnu/store/...foo.drv' worked, even though Cuirass said many of foo.drv's dependencies failed <apteryx>we don't yet have a gpg keyring of the contributors in Guix sources, correct? <civodul>mbakke: ah well, there are other issues: sometimes when cuirass attempts the builds, it times out or something, and later, the build is started by "something else" and this time it succeeds <civodul>as for timeouts, i think we have a bug whereby cuirass builds often timeout because cuirass doesn't read the build output in a timely fashion or something like that <mbakke>civodul: I'm aware of that, I just want Cuirass to restart derivations that have already been --clear-failures or even succeeded "behind its back", but can't figure out how. <mbakke>civodul: perhaps setting build.status == 4 (cancelled) will cause Cuirass to retry derivations on the next evaluation? <apteryx>civodul: and 'make authenticate' doesn't fetch the keyring from savannah, right? <apteryx>(is there such a copy fetched and cached somewhere? or the user is in charge of manually procuring the keys themselve?) <civodul>my plan in the future is to store the keyring in a branch <civodul>so we don't rely on external service <apteryx>civodul: out of curiosity, why in a branch rather than somewhere in the sources (I was thinking under etc/ or build-aux/) <civodul>basically it'll be easier to access it that way <mbakke>does anyone know how to use NetworkManager as a regular user on Guix System? I assumed being member of "netdev" was sufficient, but it appears not. *mbakke provides support for users too shy to reach out to #guix directly :P <brendyyn>mbakke: mine has gone buggy too. I can't edit some connections anymore <mbakke>brendyyn: do you know roughly when that happened? <mbakke>seems like something we should fix for 1.1 <brendyyn>im not sure since I don't normally edit them. I can edit some connections but not others. Also if you have ones that were made in GNOME, you will need to edit them as root to delete a certain line, else you would need the polkit authentication daemon thingy. i forget the exact line <brendyyn>looking closer, i think the ones i can edit have <puoxond>It fixes an issue (I hope) that affects availability of substitutes for some ~340 packages on non x86_64 systems. <puoxond>Weirdly, it doesn't show up on issues.guix.gnu.org <bricewge>At this point it segfault on my side but not on raghav-gururajan 's. <lprndn>hey, does anyone has trouble getting a graphical prompt from pinentry? I tried pinentry-gnome3 and pinentry-gtk2 but they just never show up.. <apteryx>lprndn: you mean the package 'pinentry'? <civodul>mbakke: i thought "netdev" was the thing <pkill9>lprndn: do you have pinentry-program set in ~/.gnupg/gpg-agent.conf? <bricewge>lprndn: Does “echo getpin | pinentry-gtk-2” work? <lprndn>apteryx pkill9 bricewge: package and in gpg-agent.conf but nevermind, after way too long, I just discovered I had a pinentry process getting crazy in the background. Killed it and now it works... Thank you all anyway! <lfam_>pkill9: It's not necessary to set the path in gpg-agent.conf since commit e5b44b06b3fb19c897fb3e430bd41941905e101f <jsoo>is mumi having issues? individual issues seem to giving 500 status on issues.guix.gnu.org <rekado>puoxond, jsoo: issues.guix.gnu.org is not currently updating as we’re trying to sort out its effect on debbugs.gnu.org :-/ <rekado>I hope I can get a positive response from the Debbugs sysadmins soon. <rekado>I do like the question “is mumi having issues?”, though ;) <rekado>it’s an issue tracker! Of course it has issues! <brendyyn>mbakke: where is it decided that the netdev group should give user permission to edit connections? <mbakke>brendyyn: that's the thing, I grepped the network-manager output and it does not install a polkit rule that allows netdev to edit connections <jsoo>rekado: ah, ok. all the issues are explained, then <rekado>it’s very frustrating to me, but there is very little I can do at this point :-/ <jsoo>ah, i'm sorry to hear. I will be alright without it for a while <mbakke>the NetworkManager polkit rule uses "allow_active", which means that the currently logged-in user is supposed to be able to edit network connections <brendyyn>Ok I had no idea what that meant. What does currently logged in user mean? Does that require a login manager? <mbakke>brendyyn: I'm not sure, but suspect it requires elogind yes. <brendyyn>I know its possible to run the policykit daemon on login but that just seems ugly ***lfam_ is now known as lfam
<mbakke>brendyyn: if you use %desktop-services, you should already have polkit and elogind <brendyyn>It's possible to run that and you can edit connections, but you will be prompted for your password, <mbakke>brendyyn: do you get any output if you run: '$(guix build polkit)/bin/pkcheck -a org.freedesktop.login1.reboot --process $$' ? <mbakke>brendyyn: what about `$(guix build polkit)/bin/pkcheck -a org.freedesktop.NetworkManager.enable-disable-network --process $$` ? <civodul>mbakke: looking at that patch, good catch pinoaffe1! <lfam>efraim: Can you give me advice about cleaning the Rust crates? I was only going to fix the synopses and descriptions, and remove duplicates / upgrade semver-compatible additions. But I noticed you renamed some variables <mbakke>brendyyn: that's good, no output means that the authentication succeeds, so apparently you are able add and remove NetworkManager connections! <civodul>mbakke, pinoaffe1: i see no reason not to apply it since we were building useless things for non-x86_64 platforms anyway; WDYT? <mbakke>on the system that fails, those commands says "not authorized" <brendyyn>mbakke: I can, but when I add the connection, it puts "permissions=user:b:;" in the config file. If it just says "permissions=", then I can't <mbakke>brendyyn: well, that's another issue... perhaps something changed in a recent version of NetworkManager? do you have an idea what created the configs with and without permissions? <mbakke>i.e. does adding a new connection add the correct permissions= line, or is it just older ones? <brendyyn>Actually, I just found a connection I can't rename that has even that permissions line. <brendyyn>Ages ago I used GNOME, and the connections made with that couldn't be edited outside of GNOME until i edited them manually as root, but I forget exactly how I changed them <mbakke>IIRC there is a checkbox that says "Allow all users to edit connections", I guess that's what adds the permissions= line. <mbakke>but that's about as far as my NetworkManager knowledge extends :P *mbakke is happy with wpa_gui <brendyyn>its not letting me rename the connection that im currently using, maybe that's normal? <lfam>I wonder if there is a build system that is based on gnu-build-system that we can recommend as an example of how to make a new build system? Like, something that makes a very small number of changes and would serve as a good example <lfam>Thanks brendyyn, that one is short and sweet! <brendyyn>I might end up making it longer though since I wanted to add some kind of #:compile-with-fontconfig? flag to do automatic complilation. i would simplify some font packages. <lfam>Well I can always make a hyperlink to old versions of the file ;) <brendyyn>My code won't be that detestable I promise <lfam>Haha, that's not what I'm saying! <efraim>lfam: the only thing I really renamed was that one library, synopsis and description is good enough. I might go through later and see about others building but it's not really a big deal <lfam>When I first started looking at making a build system, without much Scheme experience, I found (what I considered to be) all the boilerplate scary and confusing. So it's good if the entire file fits in one screen <lfam>It's not about quality, brendyyn. Just brevity <brendyyn>lfam: Ever now and then I look at (guix records) longingly, hoping my eyes will just absorb comprehension through osmosis. <civodul>brendyyn: maybe not the best place to start :-) <lfam>I think that every time I go back and read something I didn't understand previously, I understand more and more :) <puoxond>civodul: I didn't notice your replies because you confused me with pinoaffe1. I agree that the patch can be applied. <lfam>Are we still trying to wrap lines in the documentation (guix.texi and guix-cookbook.texi) at 72 characters? <Veera>lfam: Should package description be wrapped at 72 characters <Veera>lfam: lint only warns if above 92 or so characters <lfam>Veera: We prefer to limit it to 80 characters, but sometimes that's not possible, so the linter is more lenient <mbakke>puoxond: whoops, my bad with the name confusion :-) <lfam>In any case, it's just a warning, Veera. Sometimes you have to go beyond even 92 characters <pkill9>how secure are containers created with `guix environment --container`? <lfam>It's not intended to be a serious security boundary pkill9. <mbakke>lfam: no? They should be reasonably secure, not as good as a VM, but still. <lfam>But I think that when people ask the question, it means they have very high standards <lfam>People discover VM breakouts from QEMU monthly <lfam>And Linux containerization bugs are not even publicized, let alone reliably backported to stable kernels <lfam>It really depends on the threat model <mbakke>are there really monthly VM escapes from QEMU though? most of the issues I've seen have been various DoS attacks <lfam>I think it's pretty good but you can't expect it to, like, keep you out of prison or anything <lfam>I consider the "execute code as the host" as a breakout <lfam>There's a couple bugs on oss-sec that I haven't patched in our QEMU yet <cbaines>I've been checking out mips64el in the last few days, I noticed that core-updates helps with a bison issue <roptat>civodul, would you add a banner on top of the april 1 post to say something like "this was an april foo, but most of it was accurate, see follow-up post" with a link to that blog post maybe? <lfam>CVE-2020-11102 QEMU: tulip: OOB access in tulip_copy_tx_buffers <cbaines>I'm trying to build hello on mips64el, using QEMU (which seems to be running qemu-mipsn32el). I haven't got there yet though... <guix-vits>bricewge: `xfe` -> 'Cancel' -> Segmentation fault <lfam>pkill9: Check %namespaces in (gnu build linux-container) to get an idea of what the container is virtualizing <lfam>The other reason I don't think this stuff is that tight is the regularity of serious security advisories for Xen <bricewge>guix-vits Thanks, did you had the icons showing up? <bricewge>raghav-gururajan It looks like xfe is missing something, guix-vits reproduced the segfault :( <mbakke>civodul, janneke: amazing work on the Hurd, and great blog post! \o/ <lisbeths>I'd like to note that the instalation process for guix is simpler and more straightforwards than debian's installer. <apfel>hi there, i am working on a package for munin. Its very much work in progres https://pastebin.com/8aDtPTFR . I have a problem though, the propagated inputs of the munin package are not available via PERL5LIB. I am not sure what i am doing wrong. The munin package is at the very bottom. The other packages are missing dependencies not packaged for guix right now. Any ideas or hints? <cbaines>apfel, assuming munin is an application, not a library, it should probably not propagate the Perl inputs, and instead wrap whatever it produces with PERL5LIB <cbaines>apfel, does the munin package output contain a Perl script that you run, or some kind of CGI thing? <apfel>cbaines: some cgi scripts and some perl standalone scripts. I am interessted in the standalone scripts for now <cbaines>apfel, so for the scripts you could use wrap-program. Have you seen an example of a package definition that uses wrap-program? <apfel>cbaines: nope, i did not see any, but i will grep for one <guix-vits>bricewge: no, i'd no icons (ran `./pre-inst-env guix environment --ad-hoc xfe`, without --pure) <nojr>what should a package version be if the commit is not tagged with a version number <guix-vits>nojr: version number of a latest release, example: "(version (git-version "1.6.0" revision commit))" <apfel>cbaines: i am a bit confused, does the wrap-program thing mean that the package itself does somehow know what inputs belong to it? is so, how is this information tracked? <bricewge>guix-vits OK, thanks. I don't know how to help raghavgururajan further though <apfel>cbaines: i mean, does a package have a 'profile'? if so, where can i find it? <cbaines>apfel, a store output (directory in /gnu/store) can contain references to other store outputs, and these references are tracked by the store daemon <cbaines>apfel, if you have a store item, you'll also have all the items it references. <Veera>is there a way to get the url of a package in substitute server <cbaines>apfel, one Perl package I know of is sqitch, if you have a look at bin/sqitch within the output for that package, you'll see how the wrap-program approach works <guix-vits>Veera: you mean those that mirror://some/some/more ? <Veera>guix-vits: no. the url of the file which are updated or installed from ci.guix.gnu.org <apfel>cbaines: ok thanks, so, the PERL5LIB is crafted based on the inputs. And the relation between the packages is tracked by guix-daemon. But this is nothing one can see in the filesystem, right? I gues guix-daemon uses some kond sql database <Veera>guix-vits: when a package is updated or installed, associated derivations/packages are also updated; I want those url's <janneke>str1ngs: ah, good; yes, maybe a release is a good idea. i would not be too bothered as we don't have many users ;) but it would be the proper thing do do, i suppose <cbaines>apfel, yeah, I believe the guix-dameon has a sqlite database with this information in it. You can ask guix through the gc command what the references are though, like: guix gc --references /gnu/store/8v7b96pwwj6nnn4nszvijyz816rl20mq-sqitch-1.0.0 <str1ngs>janneke: It's not critical I agree. I'll send a patch for emacsy-minimal at the very least. luckily guix-vits pointed this out. <Veera>How to know the url's of the all the file which are to be updated or installed from ci.guix.gnu.org for a given package before hand and not when only each package is getting downloaded <guix-vits>bricewge: is pthread works in Guix (idk what i'm asking, but)? <apteryx>civodul: enjoyed reading the hurd vm blog post :-) thanks to janneke and you for spearheading the Hurd effort. <pinoaffe1>civodul: mbakke: I think you got the wrong nick, don't see how I'm involved <bricewge>guix-vits Why shouldn't it? Maybe it isn't linked... <mbakke>pinoaffe1: yes, sorry about that :-) <pkill9>civodul: nice to hear about guix on hurd <guix-vits>bricewge: it's linked "-D_POSIX_PTHREAD_SEMANTICS=1"; i was thought (idk why :) that we have troubles with pthread. <blue_blue>lol i totally 100% believed the April 1 blog post from the other day ..... i've never been that fooled by an April's fools joke before XD <pinoaffe1>blue_blue: hurd is faaaar from functional, so that makes it a bit farfetched to drop linux-libre support :) <bricewge>guix-vits IDK the state of pthread on Guix <blue_blue>pinoaffe1: yes that does make sense in retrospect now :-) <drakonis>i knew that there'd be people who thought it was sincere, despite the day <drakonis>but the part that isnt true is the most damaging <drakonis>dont trick people into thinkng you're going to drop linux <apteryx>drakonis: there's now a clarification on the post itself that it was a joke, in case someone had missed it. <blue_blue>i thought it was pretty funny 8) , mainly i fell for it since i'm not 100% knowledgeable on the state of the hurd, etc, & i'm guessing ppl in similar situation as me fell for it. <str1ngs>hurd is like fusion reaction. only 30 years away :P *alextee[m] longs for the day he can run a high performance audio guix system on the hurd <jonsger>why does a installer image built from current master pull in MATE 1.22? MATE is at 1.24 on master for several days now <cbaines>jonsger, it's possibly using the Guix package definitions from the package definition for Guix, in Guix <guix-ci>Problem: Free disk space is less than 20% on volume /gnu Problem started at 19:28:24 on 2020.04.08 <guix-ci>Problem: Free disk space is less than 20% on volume /gnu/store Problem started at 19:28:25 on 2020.04.08 <guix-ci>Problem: Free disk space is less than 20% on volume /var/cache Problem started at 19:28:26 on 2020.04.08 <guix-ci>Resolved: Free disk space is less than 20% on volume /gnu Problem has been resolved at 19:29:24 on 2020.04.08 <guix-ci>Resolved: Free disk space is less than 20% on volume /gnu/store Problem has been resolved at 19:29:25 on 2020.04.08 <str1ngs>jonsger probably just needs an update patch. <guix-ci>Resolved: Free disk space is less than 20% on volume /var/cache Problem has been resolved at 19:29:26 on 2020.04.08 <guix-ci>Problem: Free disk space is less than 20% on volume /gnu Problem started at 19:30:24 on 2020.04.08 <str1ngs>guix-ci we got the message. thanks :P <guix-ci>Problem: Free disk space is less than 20% on volume /gnu/store Problem started at 19:30:25 on 2020.04.08 <guix-ci>Problem: Free disk space is less than 20% on volume /var/cache Problem started at 19:30:26 on 2020.04.08 <guix-ci>Resolved: Free disk space is less than 20% on volume /gnu Problem has been resolved at 19:33:24 on 2020.04.08 <guix-ci>Resolved: Free disk space is less than 20% on volume /gnu/store Problem has been resolved at 19:33:25 on 2020.04.08 ***guix-vits is now known as guix-ci
***guix-ci is now known as Guest75614
<guix-ci>Resolved: Free disk space is less than 20% on volume /var/cache Problem has been resolved at 19:33:26 on 2020.04.08 ***ChanServ sets mode: +o apteryx
***apteryx sets mode: +b guix-ci!~guix-ci__@141.80.181.40
<str1ngs>apteryx mere presence scared him off :P ***ChanServ sets mode: -o apteryx
<cbaines>I'm not sure banning guix-ci will solve the approaching disk space issue on ci.guix.gnu.org... <apteryx>eh, hope that settle things while this is being worked on <apteryx>cbaines: agreed, we need to look into the space issue <apteryx>those with sysadmin access have been notified <guix-vits>is `ldconfig` available on Guix (xfe try use it in 'install)? <str1ngs>it's not advisable to use ldconfig on guix <str1ngs>especially if you are on foreign distro <guix-vits>str1ngs: but the packages that use it should set some Variables? <str1ngs>you could maybe use LD_LIBRARY_PATH but that could cause issues as well. <str1ngs>probably you want to do some substitution instead. <str1ngs>what issue are you having that you need ldconfig? <guix-vits>though strange, as raghavgururajan have no issues with xfe. which is segfault for both me and bricewge <guix-vits>segfault happens on pressing 'Cancel' at the first start (program asks where its config is), and config is generated by program. But any next start segfaults, so long as config exist in .config/xfe/ <pkill9>guix-vits: ldconfig is disable in guix's glibc with a snippet in glibc's package definition <pkill9>which prevents it from using libraries in /etc/ld.so.cache, so it doesn't use a host distro's libraries on a foreign distro <anadon>OK, just back from #nginx . It looks like the nginx packaged in guix is missing many modules. The one I'm interested in is the one to support file uploads. Is there anyone more involved with that package, or is it still entirely on whoever has time to deal with it? <apteryx>anadon: you can look at the logs, but I'd guess the later <anadon>I'm still busy with figuring out all the changes needed for Django 3.0. <pkill9>pulseaudio doesn't seem to be reading any of my user config files, from search an stract log <sputny>I found a typo in the german version of the manual. Where should I report this? <guix-vits>sputny: Hi; you can report it there; also you can play with git and send a patch. Is that manual or manual-devel? <str1ngs>essentially xfe can not copy the default xfcerc because it assume a install path. this substitutes the /usr/share/xfe/xferc to the generated output path <bricewge>Thank you str1ngs How did you find this out? <str1ngs>bricewge: the initial error when generating the users xfcerc was an indicator <sputny>guix-vits: where can I find the repo? <bricewge>str1ngs: Right, it's in my strace... I should have looked more intensely <lisbeths>I installed guix in a virtual machine and I get a grub boot menu. After I boot from grub it runs the distro installer again. <str1ngs>lisbeths maybe eject the install CD from the VM <sputny>guix-vits: yes, it's still there. <guix-vits>str1ngs, bricewge: it is working for me too, and even the icons there. <civodul>rekado: there can't be 20% free on berlin given the current settings :-) <guix-vits>str1ngs: please send the patch to to the #40487 <sputny>guix-vits: it's double usage of "maximieren" in one sentence. I send a mail to translation-team-de@lists.sourceforge.net. thanks for the help. ***deesix_ is now known as deesix
<str1ngs>guix-vits: I send a patch, but it's out of series. can not grantee anything. this is not my normal workflow. ***dddddd_ is now known as dddddd
<guix-vits>str1ngs: thanks; next time i'll try strace too (horrible to imagine i'm spending some more time trying another inputs or configure-flags) <str1ngs>the software is not well designed. it should use a gcc -Dmacro to indicate the installed xferc path <jonsger>why do I always forget how to include packages with output (e.g. :doc) in config.scm <rekado>looking at the backlog it seems that guix-ci has something to say to us <rekado>does it have to tell us every minute, though? <rekado>g_bor[m]: are you familiar with Zabbix? <cbaines>rekado, given it was flip flopping between "Problem" and "Resolved", this could just mean the disk space was hovering around the threshold for alerting <rekado>shouldn’t there be a hysteresis? <mbakke>rekado: like everything zabbix, it's configurable <rekado>I don’t like configuring Zabbix. I get lost so easily. *rekado frees space on ci.guix.gnu.org <mbakke>I have spent quite a few hours configuring Zabbix in a past life, but it's just sooo boring :P <mbakke>I'll have a look at the triggers. <rekado>I just find myself clicking around, eyes glazed over, hypnotized by the flicker of contrast changes as I randomly select chunks of text and deselect them again… <rekado>web interfaces like that just aren’t for me *jonsger starts the long journey of switiching his daily driver to Guix System :P <roelj>Blackbeard: What happens if you start Emacs from a shell? And what does `which emacs` point to? <guix-vits>Blackbeard: `guix package -I| grep emacx-next` -- should at least highlight the place in /gnu/store <Blackbeard>Ok, I installed it from the package manager, not Guix system, maybe I need to reboot and try again one second *guix-vits playing with firewall... <Blackbeard>But it is failing , maybe it is my config for 26 :/ <mbakke>rekado: how long should the free disk space trigger be active before it causes an alert? <wshimmy>I'm sure this is a very silly question, but the rust package doesn't appear to install cargo, and I don't see another package for those tools. Is this just a "time to write one" situation? <stikonas>wshimmy: it does install cargo, it's in a different output <stikonas>guix search rust shows "outputs: out doc cargo" <lisbeths>it keeps asking me to pull and hten guix package -u <civodul>roptat: could you send a new tarball to the TP? <wshimmy>stikonas: I did see that; any idea where that ends up then? <stikonas>wshimmy: nowhere unless you request to install it <stikonas>well, it is in gnu store even if you don't request it, but it won't be symlinked in your profile <stikonas>anyway, good question :). I myself am recently new to guix and at some point this got me confused too ***jonsger1 is now known as jonsger
<mbakke>rekado: to prevent flapping i changed the trigger from '{Template OS Linux:vfs.fs.size[{#FSNAME},pfree].last(0)}<20' to '({Template OS Linux:vfs.fs.size[{#FSNAME},pfree].last()}<20 and {Template OS Linux:vfs.fs.size[{#FSNAME},pfree].avg(60m)}<20)' ***lisbeths` is now known as lisbeths
