<civodul>happy new year from CET for those into that :-) <NieDzejkob>nckx: Just read your mail re:vim. I just want to mention that I blame ./etc/indent-code.el for all indentation :P <leoprikler>btw. can someone tell me why the act of creating a profile always appears to take ages in guix? <str1ngs>leoprikler: probably related to building the manual db <str1ngs>hmm that seems to be my bottle neck. what hook takes time for you? <nckx>NieDzejkob: The changes were correct, just made the diff harder to read (yes, there are people who subscribe to guix-commits and read them all đ ). <nckx>Happy new copyright year everyone. <nckx>str1ngs: Pff, pull notifications, so 2019. <leoprikler>If I make a commit today, I can claim to be a two-year contributer to Guix :) <str1ngs>oh I wonder if I could use some pub sub for this <str1ngs>it will send nckx an alert on every commit :) *nckx already gets ânew mailâ notifications from guix-commits đ If you do so I'll write a script to send you a /msg on every mail. <leoprikler>I remember an assignment for university, where students and tutors communicated via IRC and there was a bot notifying everyone when a commit was pushed to master. <str1ngs>my ML patch workflow is so terrible I cringe every time I mail a patch off :( <nckx>leoprikler: I think #exherbo does (or did) this. I think it makes the channel unreadable but they do them. <str1ngs>but exherbo created keychain at least which is nice:) <nckx>Oh, I still like them đ <str1ngs>I'm not a fan of portage myself is all. exherbo the project seems friendly though <nckx>str1ngs: Exherbo never used Portage, or I'm misunderstanding you. <str1ngs>ah now I confuse Exherbo with funtoo my bad <leoprikler>I believe, I know what is slowing down profile creation so much. <str1ngs>though paludis uses ebuilds which added to my confusion I think <leoprikler>Due to gtk-icon-themes there is a metric fuckton of file conflicts that need to be resolved. <str1ngs>hmm I would think figuring why there is such a huge conflict <str1ngs>maybe remove from gtk-icon-themes that which provided by the other package? <str1ngs>assuming the packages don't conflict completely <leoprikler>it appears as though gtk-icon-themes pulls in all the icons from all the icon themes and then generates a cache (this cache is what we actually want) <leoprikler>problem is, the files themselves are not discarded afterwards, even though they probably should <str1ngs>I sometimes wonder if it would be feasible to run hooks more lazy. so as some background process. but I don't know if that is technically feasible. since I run into this same issue with mandb generation <leoprikler>you're probably also thinking of parallelizing them, aren't you? <str1ngs>guix has no notion of a user service which would be really nice. maybe slightly offtopic for your issue <str1ngs>I think parallelizing them is overkill. more like make non blocking <leoprikler>I mean parallelize in the sense of hook #1 and hook #2 can run in parallel <pkill9>happy new year, i hope this year brings many new advancements to Guix :) <leoprikler>for what other reason would you do non-blocking? <pkill9>I am confident that such hope is not needed <str1ngs>leoprikler that could work though and avoid the back ground process <str1ngs>well in the case of mandb the probability of using the mandb right after creating the profile is slim next to nill. so your terminal is blocked but probably for good atomic and locking reasons. <str1ngs>sequential and blocking is safer I guess <str1ngs>in therms of mandb maybe guix environment could atleast have a blacklist to remove hooks. ie I'm never going to use manuals for this enviroment <str1ngs>blacklist in the form of command aruement flags <leoprikler>I think I know what you're getting at, but I don't think lazy man-db is a solution. <leoprikler>That said, I second --skip-hooks for environments <str1ngs>and the lazy madb won't help your icon cache issue. that potentially would be need right away <str1ngs>someone did mention splitting profiles into logical groups helps improve this though <str1ngs>that seems too complicated for me though :( <leoprikler>The thing is I can't split my profile into logical groups easily. <str1ngs>yep, I think there is compounded complications with that. extra PATH's and source of profiles <leoprikler>As far as conflicts are concerned: I think many of them can be ignored safely. <leoprikler>E.g. consider a split, where you have info-reader in two profiles, because that's how you get INFOPATH set up. <leoprikler>There's no harm in taking either info, as long as INFOPATH is set correctly, which it would be. <leoprikler>sneek later tell raghav-gururajan I fixed the icon problem by adding hicolor-icon-theme to my local profile, but that's weird, because it even fixed system icons for me and should also not be required. How did we get here? <str1ngs>leoprikler: also I think fast nvme hide some of these performance issues <nckx>leoprikler: No harm, but would it be transparent to users how this choice is made and how/if they can affect it? And I mean intuitively, not âby retracing the code thatâ. <leoprikler>Perhaps we can make it so by enforcing some ordering. <leoprikler>We already have current/channels as "the last to be added" = "the first in PATH", so adding constraints on top of that should not be difficult on a philosophical level. <leoprikler>It may be a pain to write the shell script that does that, though đď¸ <str1ngs>I think this just skirts the real issue that environment variables do not scale well also trying to still maintain some an hence FHS is an uphill fight. guix and nix need a more top down solution to this problem <leoprikler>Well, the "top down" solution I currently use is merging several manifests into one profile. <str1ngs>I agree it's a start. and food for thought <leoprikler>Especially given the bottleneck of <hash>-profile. <str1ngs>what computes that btw? is that file based hashing? <str1ngs>right, but I've never looked at that algo. is it based on the sum of each input expression hash? <leoprikler>btw. to avoid confusion, the problem is not the hash algorithm <str1ngs>sorry slighty offtopic I've been meaning to ask that question for some time lol <leoprikler>the manifest you're using is passed to profile-derivation, which creates a builder that is passed to gexp->derivation <leoprikler>this in turn uses raw-derivation to access the store, which in some magical manner determines a hash for it (I assume) <str1ngs>leoprikler: thanks I'm just reading reading the manual on derivation and now G-expressions what rabbit have you lead me down? :P <str1ngs>g-expressions are so beyond my level of scheme. I only barely have an understanding of quasiquote, unquote, and unquote-splicing <wxie>Happy New Year, Guix. Is there a MIPS porting for guix? <ng0>wxie: you are asking for something which used to exist (see archives), unless i'm wrong ***apteryx_ is now known as apteryx
<sneek>Welcome back raghav-gururajan, you have 1 message. <sneek>raghav-gururajan, leoprikler says: I fixed the icon problem by adding hicolor-icon-theme to my local profile, but that's weird, because it even fixed system icons for me and should also not be required. How did we get here? <raghav-gururajan>sneek: later tell leoprikler: I think I found the issue. The package "adwaita-icon-theme" suppose to take care of icons. But the package definition has an argument not to create icon.cache. So we might need to remove that argument. <efraim>brettgilio: 'guix package -A znc' says version 1.7.5 in (gnu packages messaging) <efraim>raghav-gururajan: I'm here but I'm working ATM <brown121407>How do I get ldconfig? On Arch it's part of core/glibc, but even if I explicitly install glibc, there's no ldconfig found. <kirisime>brown121407: "there's no ldconfig in guix" is what I remember reading in some online discussion about julia. <sneek>Welcome back leoprikler, you have 1 message. <sneek>leoprikler, raghav-gururajan says: I think I found the issue. The package "adwaita-icon-theme" suppose to take care of icons. But the package definition has an argument not to create icon.cache. So we might need to remove that argument. <leoprikler>So I'm not sure whether adwaita-icon-theme is sufficient <leoprikler>it also does not appear to work when i put hicolor in my system config, but maybe I would have to reboot for that, idk <leoprikler>adwaita-icon-theme has Adwaita only (who would have thunk?) but XDG says hicolor must exist <efraim>brown121407: you could try gcc-toolchain <brown121407>efraim: I already have gcc-toolchain installed, no ldconfig <kirisime>Is there a version of wrap-program that wraps multiple programs with the same variables? <efraim>find /gnu/store -name ldconfig isn't finding anything <brown121407>efraim: I see that the package definition for glibc substitutes use_ldconfig=yes with use_ldconfig=no <kirisime>ldconfig is for systems that have globally installed libraries. <kirisime>I'm not sure how to work around software assuming such traditional stuff is present, but maybe you can pull your dependencies into a guix env and set LD_LIBRARY_PATH to $GUIX_ENVIRONMENT/lib <brown121407>kirisime: problem seems to be that Haskell's stack calls ldconfig whenever I want to do something like install a package. I see stack has Nix integration. I don't know much about Nix but I know Guix is based on it. Therefore it should be possible to build a Guix integration for stack. I'm going to look a bit into it, though I don't think I'm capable of doing a such thing, so that may turn into a feature request for stack <nckx>brown121407: Some Guix packages set LDCONFIG=true (as in, the âtrueâ command, doing nothing); can you tell Stack something similar? <kirisime>What's the difference between lambda and lambda* anyways? <nckx>Ugh my head I mean hullo g_bor. <nckx>kirisime: lambda* is an extension to lambda that can take (#:key word arguments) and optional arguments, which is why it's often used in phases. <brown121407>nckx: nope. Running `LDCONFIG=true stack install ...` still errors with "Executable ldconfig not found on path $PATH" <kirisime>nckx: That makes sense. Are keywords more special in scheme than in CL then? The latter only has one kind of a lambda list iirc. <g_bor>nckx: I got a bit further with debugging this. <g_bor>Problem is the generated iso does not have the installer in store. <g_bor>I believ I need a gc-root service somewhere... <nckx>brown121407: Right, I meant more the general concept than an exact variable name. Problem is I know nothing about using Stack. ***roptat_ is now known as roptat
<g_bor>roptat: I have a bit of problem, maybe you have some idea. I am trying to get something else to run insteda of the installation program. I have made a similar config, it looks like this: <nckx>g_bor: That's unexpected to me. The âregularâ gc-root-service-type also doesn't explicitly refer to the installer, as you probably saw yourself. <kirisime>I'm now more or less happy with my mypaint 2.0 package, save for the fact that since I still can't git-fetch the package definition uses github archives to download source. <g_bor>problem seems to me that the installer program is not copied to the iso. <g_bor>It is created on the machine where I run guix system. <g_bor>I was looking at the current code in guix, but don't find how the installer ends up in the original installer iso. <nckx>I don't see why it wouldn't just be pulled in by (login-program (installer-program)). <nckx>If yours was a complex multi-module beast I could see how required modules might be missing, but it's not. <g_bor>nckx: I don't get it either :) <g_bor>I also thought it should just work. <roptat>So login-program should be a file-like object, not a function, right? <leoprikler>Perhaps, but h-i-t should still not be part of a-i-t <raghav-gururajan>leoprikler yes, h-i-t should not be part of a-i-t. I am trying find which gnome element uses h-i-t as dep. <leoprikler>also it would need to be propagated either way, so adding it to a random package is not really helpful <nckx>raghav-gururajan: Could you link to the 2 patches you wanted merged? Have they been reviewed by a competent gnomologist? *raghav-gururajan : gnomologist made their day <nckx>If not, I'd rather wait. <nckx>raghav-gururajan: If it can be ignored why is it open? v2 incoming? Or can it be closed? <nckx>raghav-gururajan: Thanks. <leoprikler>Last time I checked, we were still a bit unsure of what v2 should actually be. The problem it tries to solve is the (optional) dependency of both evolution-data-server and gnome-settings-daemon on gnome-online-accounts. <leoprikler>well, maybe not gnome-settings-daemon, but the GNOME Settings, which appear to be a superset of it? <raghav-gururajan>Yes, even I am not sure. I just need time. Currently, I am trying to finishing gnome core packages. I think it's better to have all the components and then analyse how they are linked/work. <raghav-gururajan>As soon as I finish 4/5 more packages that I am currently on. Debugging those things we discussed going to be next work. :-) <nckx>raghav-gururajan: By the way, the convention is â* foo.scm (bar): Blah.â, not â(bar). Blah.â <nckx>Let's not discuss the grammaticality of capital letters after colons and blindly accept this dogma. <nckx>gitlab.gnome.org is heavily overloaded or otherwise malfunctioning here so I'll be back later. <g_bor>well login-program should be a gexp according to the docs. <g_bor>I will have a loo at this one more time... <str1ngs>nckx: do you know if a yasnippet exists for creating another commit it a series? <g_bor>I have tried to do a gexp-quote gexp-unquote <g_bor>it will take a while to build. <leoprikler>,package-x where package-x is the variable that holds (package (inherit package) (version x)) <str1ngs>raghav-gururajan: can you look at this commit message <str1ngs>a8cda7f57992e9ce9ae4a694eba54e3eab42c39b did yasnpippet add the input details? <str1ngs>raghav-gururajan: just read, I guess I'm asking how the commit message was auto generated <str1ngs>I need to add more patches after an initial add. and I'd like the patches in the series to be formatted <str1ngs>leoprikler: auto formatted my be a better choice of words <str1ngs>PotentialUser-34: assuming you are doing guix install. can you try again? ***PotentialUser-34 is now known as rekado
<str1ngs>rekado: and guix build nss-certs does the samething? <rekado>fallback works fie, so I wonde if the substitute's borked <rekado>everything else downloads just fine <rekado>nss-certs have previously broken due to odd characters in file names <rekado>I wonder if this might be related <str1ngs>I was thinking something like that. where it un tars while downloading. and then can't handle a file name <str1ngs>I think in this case it does since store paths are unique <str1ngs>in this case the error happens at 48% download so it could either be network related or indicate it's extracting while downloading <rekado>but I can't explain why the progress indicator shows that it's still downloading <str1ngs>or output has not been flushed assuming output is buffered <rekado>(i.e. it completes the download; obviously it doesn't unpack) <str1ngs>which foreign distro are you using rekado ? <str1ngs>gah I read your question wrong my bad <rekado>this is with the latest guix (well, an hour old) <str1ngs>this is kinda hacky using the new guix pull stop the herd guix-daemon and start the guix-daemon by hand. <str1ngs>ie $(guix build guix)/bin/guix-daemon <rekado>I'm already past this with "--fallback" (which built nss-certs locally), but I don't think it's a daemon problem <rekado>gotta reboot this machine now; be back later <str1ngs>sneek later tell rekado I'm just wondering if there is a chicken/egg scenario where the current system is to old to upgrade. <oriansj>str1ngs: the answer is yes if you are using the guix binary <str1ngs>oriansj: sorry yes, to which question? <oriansj>if there is a chicken/egg scenario where the current system is to old to upgrade <oriansj>The answer is yes, such a thing tends to occur when the root binaries change <str1ngs>right, is it possible starting the new guix daemon by hand could get around this? <oriansj>str1ngs: honestly I gave up when I hit that problem and simply rebuilt from guix-config.scm <str1ngs>oriansj: with guix system init I'm assuming? <oriansj>str1ngs: actually from the install media itself (known working solution and all) <str1ngs>right in that case init is implied I guess <lekzikon>Is there any way you can use private remote channels and packages available over SSH? <str1ngs>I don't think channels support ssh at this time. it's a feature that is currently being added to guile-git <oriansj>lekzikon: sshfs generally solves that <str1ngs>libgit2 does support this but the guile-git bindings need support added for it IIRC <str1ngs>sshfs with file:/// seems like a nice workaround though *lekzikon reads about sshfs <oriansj>the only thing you need to remember about sshfs is: sudo sshfs user@server:/path/to/folder /mnt/path/ -o allow_other,IdentityFile=/home/user/file <str1ngs>I need to update a patch in a series is it possible to auto format the changes? ie * gnu/packages/gnome.scm (gnome-themes-extra)[arguments]: Disable cache file from configure flags. looks auto generated but I'm not finding the yasnippet that does this <str1ngs>I'm only seeing add rename update. update only handles version bumping. nothing that handles fixs input changes etc. <str1ngs>though I see commit messages with fixs and even includes the input changes etc <leoprikler>you probably want to adapt use-https-home-page for that <str1ngs>ahh I think this will work leoprikler thank you <leoprikler>btw. are these snippets distributed somehow via guix? <str1ngs>I'm not sure. I just set it up with ~/src/guix.git and it just works <str1ngs>by overall my ML pathch workflow is atrocious which I'm trying to refine I guess :( <str1ngs>leoprikler: this https snippet helps though thanks. <str1ngs>is it okay to just re-email a whole series or is that bad ML etiquette? ***ng0_ is now known as ng0
<leoprikler>If all the files have changed, that's what you have to do. You can however collect the patches into files and send just one email for all of them. <leoprikler>If just one patch in between has changed without affecting the others (unlikely, but what do I know?) it may be simpler to just resend that single patch. <leoprikler>and if it's the last patch that has changed, then it's obvious that you don't have to resend everything ;) <str1ngs>if I can collect patches into one patch without squashing that might work <leoprikler>no, what I mean would be like format-patch -> 0001 ... 00nn <leoprikler>and send a mail with all of those as attachment (rather than sending one mail individually for each) <str1ngs>I see that makes sense thanks. I think that would work for this case <raghav-gururajan>Folks! I am building a gnome app using gnu-build-system. It is asking for "systemd developmental headers". How do I disable it? <raghav-gururajan>It tried "--with-systemduserunitdir=no", but did not work. Still asking. <str1ngs>what part of systemd is it using do you know? <leoprikler>if it requires logind you may trick it by supplying elogind <raghav-gururajan>In makefile.am All I see about systemd is --with-systemduserunitdir='$${libdir}/systemd/user-distcheck' <str1ngs>also maybe you want to use glib-or-gtk-build-system vs gnu-build-system? <raghav-gururajan>In configure.ac I see this line "PKG_CHECK_EXISTS([systemd],, [AC_MSG_ERROR([systemd development headers not found])])". <str1ngs>raghav-gururajan: that might not fix this particular issue but it could help with package creation <leoprikler>you could also try packaging a newer version than 3.32 <str1ngs>which version is this. probably a newer version uses meson <str1ngs>though it might not work with guix's gtk+ <leoprikler>looking at the build stuff, it doesn't appear to have a gtk dependency (just glib) <leoprikler>Okay, it's the webdav service unit, that "requires" systemd. <str1ngs>that check can removed then. system guix does not use systemd units at all <nckx>pkill9: It works in my browser. <nckx>str1ngs, leoprikler: So configure checks for systemd headers at build time because âyou'll need systemd to run this systemd unit file we'll installâ? Madness. <nckx>No CVEs yet? Impossible. <leoprikler>If I'm not mistaken, newer versions (built with meson) rectify this. <str1ngs>it should check for systemd pc and if it does not pass skip the unit files <str1ngs>the issue here is it needs to determine the target path for systemd unit files <nckx>str1ngs: No disagreement there. <leoprikler>because the systemd service NEEDS to be installed, there is no way around it đď¸ <nckx>raghav-gururajan: Pushed. <str1ngs>I guess it's a moot issue now that it uses meson <str1ngs>cause you know that's all we need is another build system <nckx>Why would you not want systemd, leoprikler? Are you a communist? <str1ngs>does this seriously need the service installed? <nckx>Your nick *is* red here. <nckx>str1ngs: Many Guix packages include a .service but there's no policy mandating it. <leoprikler>Well, there's no shepherd-service.scm, but more importantly it doesn't appear to use any other init system <leoprikler>this is probably a defense against people trying to use it on such older systems and then complaining that there's no service <str1ngs>I meant in terms of this package build system <nckx>Oh. Many build systems demand^Wneed things that are patched out in our packages. <nckx>But yah, Meson mootness. <leoprikler>I think newer versions also add an option to not install the service file, though I may be mistaken. <raghav-gururajan>leoprikler gnome-user-share uses meson build system only after version 3.3x.x. <leoprikler>that's why I suggested to you earlier to package the newer version ;) <leoprikler>that said, if it requires other stuff from gnome 3.34 (as opposed to 3.32) it will sit on wip-gnome for a while <nckx>raghav-gururajan: There are people who think that every GTK package with a 3.3x version number needs to be updated in one grand GNOME ta-da. I disagree with those people. Unless it breaks something, I'll upgrade âGNOMEâ things I use (like simple-scan) without waiting on the rest. <nckx>I suggest you do the same. <nckx>âNailed by systemdâ, by M.W. Lucas. <str1ngs>though to be fair any version bump of glib or gtk+ is going to cause output that use those inputs to be rebuilt. so might as well upgrade those too I guess? <nckx>raghav-gururajan: Lauded author of classics such as âSavaged by systemdâ. <leoprikler>I think you still have to set systemduserunitdir as option <nckx>str1ngs: Yes. By âGTK packageâ I meant âGTK packageâ, not âGTK packageâ. I should've clarified. *nckx out to post a letter like it's 2019. <raghav-gururajan>Btw, shouldn't an DE be init-system independent? DE's are supposed to be cross-platform, not platform with systemd. Damn, I hate GNOME in this aspect. *raghav-gururajan checks out xfce to see how they deal sysd <leoprikler>most 'modern' DEs at least depend on logind though <str1ngs>in this case DE's are dependent on dbus and some dbus components are part of systemd now <str1ngs>I think udev for example might be an example of this? <str1ngs>though I think libsystemd only can resolve most of these issues. I think that's what other distro's do <str1ngs>right and I think DE like to use that because it adds per seat features <leoprikler>either way, someone adjacent to Guix System (well, at least at the time) brought us elogind <str1ngs>it's interesting how Lennart has a bad rap for systemd but overlooks the usefulness of pkg-config. just a random thought <str1ngs>actually he's not the original author of pkg-config at all. don't mind me :( I thought he was for some reason <leoprikler>oh, but he did avahi zeroconf according to wikipedia <leoprikler>(again a piece of software that certain people love to have, but not to the same extent as systemd) <leoprikler>sure, but it's not wrong to draw inspiration from others as long as you make a positive influence <kirisime>I would happily buy OSX for my computer if I could and could expect it to just work. <kirisime>But since that doesn't seem possible in either regard I'm forced to believe that free software is the only way. <leoprikler>Even if you never read the source code, free software still is the only way. <str1ngs>there was linux trend for the longest time to emulate window and mac. which imho kinda stifled innovation <leoprikler>I personally see "easy to use for people used to Windows" as a still ongoing trend. <leoprikler>Granted, I have since sought refuge in Gentoo and later Guix, but certain popular distros build on this appeal. <NieDzejkob>My brain read that as "easy to upgrade for people used to Windows" :D <leoprikler>Arch even emulates the problems with Windows updates breaking everything đď¸ <NieDzejkob>I was on Arch for quite long and don't recall any problems with the updates <ixlun>Does anyone know where I should report a build error? <ixlun>For some reason the perl-gtk2 build is failing. <civodul>you can email the details to bug-guix@gnu.org <nckx>ixlun: bug-guix@gnu.org, but that sounds familiar so probably reported <civodul>specifically, the output of "guix describe" and the "guix build" command to reproduce <leoprikler>NieDzejkob: Well, I haven't had any problems with Arch either, so I probably should not joke like that. However, for some reason Arch has this image, probably because its wiki and forums are a source of every failure you will ever encounter on any other system. <nckx>raghav-gururajan: Stating âDE's are supposed to be cross-platformâ as fact is flame bait, but I'm not biting đ <leoprikler>You know the kind of bait you use to catch a fish? Same concept, but what you're trying to "catch" is a long-winded discussion. <rekado_>ixlun: I also see this build failure (it prevents youtube-viewer from being built) <sneek>rekado_, you have 1 message. <sneek>rekado_, str1ngs says: I'm just wondering if there is a chicken/egg scenario where the current system is to old to upgrade. <nckx>raghav-gururajan: Something bound to elicit fiery opinions. <ixlun>rekado_: that's the same package I was trying to install :-) <rekado_>ixlun: itâs odd because nckx just upgraded it and I assume that it could be built then. <nckx>rekado_: Not that âjustâ, was it? <ixlun>Huh, looking at the build output, it's a single unit-test that is failing <rekado_>nckx: oh, sorry, I misread a message to bug 38521. <leoprikler>Although I second your opinion. DEs should be multiplatform, said platforms being Guix on Hurd and Guix on Linux đď¸ <nckx>rekado_: Didn't I reply with a nice bisection & all? <rekado_>I have a hard time paying *enough* attention to the few mails I get to read :-/ <ixlun>Specifically, the test that's failing on my machine: "Failed test 'Don't crash on partial pixmap data'" <lispmacs>reading about guix challenge... does your local store somehow remember whether packages were built locally or downloaded from a certain substitute server? <rekado_>in other news, Gnome broke on the T60 that I upgraded today. It crashed *while* I was using it, 20 mins after the upgrade, just after I decided that it worked fine and I could GC the old system⌠<rekado_>tried to use MATE then, but itâs missing glib:bin at runtime as it uses gio-desktop-launch to run programs <rekado_>then noticed that I have no idea how to use ibus with MATE <rekado_>and why it doesnât fail reproducibly <rekado_>that other machine I have survived the upgrade just fine *ixlun has a X200 arriving in the post tomorrow. Looking forward to flashing libreboot and installing guix :-D <pkill9>i wouldnt mind getting an x200 just to say i have a fully libre machine, heh <pkill9>s/just to say i have/just to have <ixlun>You can pick them up pretty cheap <rekado_>they are fine, but graphics are very limited <rekado_>things like libfive Studio wonât run. <pkill9>do people generlaly use them as a laptop? old laptops don't tend to have full capacity batteries, or efficient power usage <pkill9>i'd probably use it as a portable desktop with inbuilt UPS <rekado_>looking at the state of libre laptops you wouldnât be able to tell itâs 2020 :-/ <rekado_>but weâre a good chunk into this century already <nckx>pkill9: It's not the same generation, but the X230t I bought last year came with a perfect (vintage) battery and runs for ~6 hours of normal use. Just don't compile anything on the road, but then most âpower efficiencyâ improvements since then are of the âdo nothing, betterâ variety anyway. <NieDzejkob>(ignoring the pedants that consider the decade to start in 2021) *rekado_ moves all data from the T60 to the workstation that had a successful Gnome upgrade⌠<nckx>And what are their opinions on systemd? <ixlun>Can guix copy prompt for a password or does it need ssh keys setup? *raghav-gururajan uses fully liberated X200T <civodul>rekado_: speaking of GNOME, efraim had proposed to make /var/lib/gdm a tmpfs a while back, perhaps we should do that? <civodul>BTW, GNOME upgrades are smooth on my partner's laptop <civodul>so i wonder why experience varies that much <NieDzejkob>dctrud: Have you taken a look at py3status yet? If not, would you mind if I did it instead? *raghav-gururajan taps out with sysd and takes a break. <civodul>raghav-gururajan: maybe not so recent (from a few weeks ago) <ixlun>Does anyone know why `guix copy' is building a package, rather than using the built one? <ixlun>raghav-gururajan: on the target machine or the host? <ixlun>Hm, but why would that stop guix copy? <raghav-gururajan>If you are trying to copy a built package that has been GC'd already, then it has to rebuild right? <ixlun>Ah but it hasn't been GC'd yet.. I can still see it in the hosts' store. <raghav-gururajan>I personally never used `guix copy`. I am suggesting based what I read from manual. <ngz>I'm sure it's getting old, but : happy new year, Guix. <kiwi_694>Hi. Does anyone know why I'm getting the error "guix package: error: cannot install non-package object: #<unspecified>" when running "guix package -i vim -f gnu/packages/vim.scm" from Guix git repo root folder? <ngz>kiwi_694: I think "-f" expects the code in the provided file to _return_ a package, which is not the case in "vim.scm" <kiwi_694>How can I build packages from the source then? This used to work a while ago <ngz>guix package --no-substitutes -i vim maybe <ngz>And from the repo, you can use ./pre-inst-env script. <kiwi_694>The ./pre-inst-env script didn't work for me either. I tried that <leoprikler>guix environment PACKAGE -- true && guix build --no-substitutes PACKAGE? <leoprikler>(I once got something along this line as a response to the same question, with the comment that it's pretty hacky.) <ngz>OK. Then I misunderstood your question. You want to install in your current profile a package whose definition is located in Guix's git repository. Something like pinning a package. <lispmacs>does guix store somehow keep track of whether a package was built locally or downloaded as a substitute? <kiwi_694>Why does the -f flag even exist then? Pretty sure it used to work, I have built packages like this before <leoprikler>Guix build -f exists, so that you can write a package definition to file and put it into version control outside of guix. <leoprikler>e.g. guile-gi has its own guix.scm file which you could use for development builds <ngz>Anyway, for something different, I have a question about Python packaging. I have a Python package who installs executable in "$out/share/bin/". If I create a symlink in $out/bin/, wrapping magic doesn't happen and the executable fails because it cannot find other libraries. If I copy the executable in $out/bin/, it cannot find its own data. I'm sure that's pretty trivial, but what would be a way out? <str1ngs>personally I think guix build -l defined.scm -e "vim bash" is a better approach then -f <kiwi_694>so how do you guys make changes to the packages in source and then test them? <ngz>kiwi_694: with ./pre-inst-env <str1ngs>this keeps the build and environment flags and behavior the same and allows package defined files to be used for a module and file definition <ngz>More specifically: guix environment guix then ./pre-inst-env guix build foo <leoprikler>don't forget bootstrap to make on your first run ;) <kiwi_694>hm, I am doing that, but it's not building with the changes that I've made <ngz>Then you need to make clean-go, and recompile Guix <ngz>It happens sometimes. <ngz>I mean ./configure --localstatedir=var && make -j4 <ngz>make clean-go is a bit strong, but necessary when encountering errors during compilation. In any case, if pre-inst-env ignores your change, you need to build Guix again. <ngz>(BTW I think that --localstatedir=/var should be a default value and safely ignored) <kiwi_694>shouldn't ./pre-inst-env work without even running make? <ngz>You don't need make install, but you do need make. <ngz>At least that's what my experience tells me. <kiwi_694>alright, thanks a lot for the help! I'll see if that works <NieDzejkob>dctrud: Actually, I got curious as to why the problem with py3status and file occurs and it turns out it's so simple I already have a patch (an update changed 's to "s) <NieDzejkob>This makes me think that substitute* shouldn't fail silently. If I change it, will that trigger package rebuilds so that I can see if any build recipe relies on this? <leoprikler>Doesn't substitute* fail loudly if your regex is bad? <leoprikler>And most tools operating on regexp substitutions allow 0 substitutions for obvious reasons. <ixlun>Does anyone know how what a modified system config would look like to pass an extra substitue URL to guix-daemon? <ixlun>I see there is `substitute-urls' in the `guix-configuration' data type, but I'm not sure how to modify that <ixlun>I think I need to brush up on my scheme <NieDzejkob>leoprikler: It depends on how substitute* is used. For per-package patches, if the substitute* doesn't match, it's probably a bug <NieDzejkob>I suppose there should be two functions, one allowing no matches, and one requiring a match <NieDzejkob>What would be a good name for that? substitute*-if-present ? <NieDzejkob>Hmm, I suppose migrating that way would be less disruptive <pkill9>how do you query for packages from a profile/manifest that contain a certain input? <leoprikler>but I personally don't think this use of substitute* is necessarily evil <pkill9>i think using mulitple profiles could be avoided with sufficient possibilities for querying packages <leoprikler>NieDzejkob: In your example, you could use a substitute* that matches either form, i.e. one line with single quotes and one line with double quotes <NieDzejkob>Is there an equivalent to Debian's 'apt source'? <pkill9>leoprikler: i mean that i wouldn't need to split packages up into separate profiles if i could manage different sets of packages from the default profile based on queries like 'which packages have x server in their dependency graph' or 'which packages are larger than 300mb' <NieDzejkob>leoprikler: The problem is that one has to anticipate that this will change <pkill9>at the moment i separate desktop packages intoa separate profile, so i can update all the small commandline packages without updating the larger desktop packages which will take a while to compile <leoprikler>Well, now that it did change, you could keep the old version in case someone decides to revert that patch ;) <NieDzejkob>I feel like making a policy of using /fail-hard in places like this would be more effective <leoprikler>I feel you're going to have some false positives in languages that aren't python. <pkill9>leoprikler: i would pass guile expressions instead of adding a commandline option for every use case <pkill9>e.g. you could search for packages with the word "game" in their description <pkill9>or search for packages which their source comes from a particular domain <NieDzejkob>leoprikler: re: false positives, are you talking to me or pkill9? <leoprikler>fine, "guix upgrade '(lambda (pkg) (>= (package-disk-size-voodoo pkg) 300mb))' <pkill9>i think this could be done with a guile script <leoprikler>I don't think, that's as big of a problem, given that you could script this up in Scheme. <leoprikler>Especially if you have to supply scheme code on the command line, chances are you're able to write the script that does that yourself. <pkill9>but yea leoprikler ,that example basically illustrates what i imagine <pkill9>and it could also work with `guix remove` <pkill9>maybe a self-contained script could provide a nice ncurses interface to interactively filter the packages <pkill9>then you choose what to do with it, that would be a nice little profile manager <nckx>NieDzejkob: It's probably better to phrase that as a stand-alone question than assume that people know what apt source does. Is it similar to âguix build --sourceâ? <ixlun>Hm, I'm getting an error when I try out my new config: <leoprikler>Don't get me wrong, nice frontend stuff is nice, but I don't think people use multiple profiles because the frontend is not nice enough. <leoprikler>The opposite actually, the frontend becomes less nice if you split things up. <pkill9>what other reasons do people use multiple profiles for? <leoprikler>one reason would be to activate them on command, like permanent environments <leoprikler>another would be to keep build times small and have better parallelism <pkill9>building the profile you mean? or building the packages themselves? <leoprikler>e.g. if you build most of gnome and a bunch of emacs packages in one place, you end up with a huge profile and equally long profile hooks <pkill9>yea, that's partly why i split my profile up <leoprikler>if you have one profile for gnome and one for emacs, the hooks run in parallel <NieDzejkob>ixlun: is that the full error, or does it say something more? <pkill9>how about, a profile for each package, heh <NieDzejkob>nckx: Yeah, that helps somewhat. apt source is a nice utility command that creates a folder and downloads a package's source into it, unpacks and applies any patches <leoprikler>that's not really useful, but you could do it in theory <ixlun>NieDzejkob: nope, all it says: '/etc/config.scm:41:1 error: invalid field specifier' <NieDzejkob>which of the lines in the paste is line 41 of your file? <efraim>part 1&2 of ripgrep review done, 266 patches applied, most with minor tweaks <efraim>now for the actual package by package review <ixlun>NieDzejkob: '(define %my-services' <leoprikler>ixlun that sounds like it shouldn't belong there <leoprikler>could you move the define outside of the operating-system record? <lekzikon>I'm trying to define a private package (guile-mar) in a private channel. Both, private channel repository and the repository of the packaged software are local git repositories. But "$ guix build guile-mar" fails with "fatal: '/home/lekzikon/repos/guile-mar' does not appear to be a git repository". <NieDzejkob>that would've been easier to notice if you posted your whole config :D <NieDzejkob>in general, prefer pasting too much than too little <lekzikon>leoprikler: I thought so, add the file://, but I get the same error. <nckx>NieDzejkob: What's missing? <nckx>Oh, it doesn't *always* unpack, right. <ixlun>Ahh, silly me, sorry I'm still getting to grips with scheme. Thanks NieDzejkob & leoprikler! <lekzikon>leoprikler: I mean, I tried with both an absolute path and a URI with file:// <leoprikler>nckx: that and it also puts the stuff into /gnu/store <leoprikler>lekzikon, did you guix pull after updating your channels.scm? <lekzikon>leoprikler: my repos have .git directories, and yes, I pull every time I make a change in the definitions. <NieDzejkob>lekzikon: Another thing to remember is that this does not consider uncommitted changes <lekzikon>NieDzejkob: I commit changes before running guix pull. <lekzikon>I tried again, but no luck: fatal: '/home/lekzikon/repos/guile-mar' does not appear to be a git repository <NieDzejkob>lekzikon: try running 'git clone ~/repos/guile-mar'. Does that work? <pkill9>leoprikler: i don't think we use URIs over paths, it's just because guix channels use git, and git reads file://, which is more of a happy accident <leoprikler>well, not everywhere, but in origins we certainly do <jsrana>i am packaging libresprite 1.1.6. im getting "guix package: error: cannot install non-package object: #<unspecified>", anyone know why? <efraim>add 'libsprite' to the end of your file <ixlun>I think I saw that someone had packaged my project for guix the other day; I was happy to see that! :-) <NieDzejkob>I think you actually want to construct a gst search path out of your gst-* inputs <ngz>That's what I tried. However, wrapping GST_SYSTEM_PLUGIN_PATH, GST_PLUGIN_PATH (as suggested by the configure script), GST_SYSTEM_PLUGIN_PATH_1_0 (as done by Nix) fails in the same way. <ngz>Oddly that the configure script suggest to use $out/lib/gstreamer-1.0 instead of $gstreamer-inputs/lib/gstreamer-1.0 <valignatev>Sup guix! I'm trying to import a crates package recursively and eventually it throws "X.509 certificate of 'crates.io' could not be verified". I've installed nss-certs, exported all needed environment variables and made sure nscd service is running. Here's a full paste: https://paste.debian.net/1123908/ <valignatev>Notice that after hitting wasm-bindgen-webidl it starts going circles. Maybe import can't handle some circullar dependencies? <mehlon>it's the first symmetrical year in 18 years <oriansj>mehlon: by that argument every year was symmetric when you add enough digits; thus it wouldn't be the first symmetrical year in 18 years... <mehlon>or, I guess I see what you're doing <oriansj>or if you prefer to be strict about just years: 2019.2019 <mehlon>it's the first symmetrical year in a year <oriansj>mehlon: translationally symmetric year in 271 days ^_- <oriansj>unless one wishes to express dates in alternate number systems, in which case the answer is even smaller (probaby greater than 1 days) <bandali>ngz, hey, thanks for updating orgalist! btw i just noticed that auto-fill-mode seems to break when itâs enabled. on emacs master. have you noticed that? <oriansj>I guess if one wanted to use the babylonian calender but that sort of thing leads only the madness. <oriansj>If we were to go Posix, today is only 1577915411; in which case we haven't hit the next epoch yet <mehlon>after being enlightened by einstein I prefer the non-calender, it's pretty simple: just take any UNIX date and multiply it by 0 <oriansj>mehlon: don't you mean divide it by 0 ^_^ <mehlon>in either case, all time becomes equal <oriansj>not for suffienciently large values of zero <mehlon>...except 1 jan 1970 which does not have an answer in einsteinian non-time <mehlon>or NaN according to your implementation <oriansj>only in infinite number spaces but not for a finite number space <mehlon>wait I can just use emojis in here đ¤ <oriansj>It is one of the reasons why the axiomatic assumption of infinity might itself be flawed (also older IRC clients don't support emoji) <mehlon>by finite number space you mean something like numbers mod n? <ngz>bandali: I don't use emacs-master, so I didn't notice anything. <oriansj>mehlon: well that is one of the possible subsets of number spaces that fit the requirements <bandali>ngz, ah. so auto-fill-mode works just fine in message-mode with orgalist in emacs 26? <ngz>bandali: I didn't check. What is the problem? <bandali>ngz, hereâs the error: orgalist--boundaries: Lisp nesting exceeds âmax-lisp-eval-depthâ <bandali>that happens when the line reaches wrapping mode (by default >72 chars) <bandali>and the paragraph isnât filled. a manual M-q works tho <PotentialUser-99>Hi all, I was looking for some help with Guix System 1.0.1 installation. I got confused over the manual. I have prepared a dedicated partition for Guix with GParted. I'm using reFind as boot manager/loader (having other OSs aside) and thus don't need/want to install GRUB. I think for this I need to revert to the manual installation procedure using <PotentialUser-99>--no-bootloader option on the guix system init command. Where I'm confused is that apparently the bootloader settings in the config must be defined. Can I leave it just empty in my case or does it need at least some valid entries e.g. EFI bootloader? Thanks <bandali>ngz, by âwrapping modeâ i meant âwrapping pointâ <ngz>bandali: I cannot reproduce this on Emacs 26. However, I get an error when trying to use M-q in Emacs-26 with orgalist-mode on (trying to funcall nil). <bandali>i wonder if theyâre both symptoms of the same bug <mehlon>PotentialUser-99: it's possible. you can do --no-bootloader which should not change EFI variables <mehlon>however, every time you do guix system reconfigure the bootloader needs to add a new entry to the latest config <mehlon>so I recommend you do not leave them empty, instead you should run with --no-bootloader every time <mehlon>the best way to use Guix is to boot reFind -> GRUB -> Guix <mehlon>also uhh I think you have to manually add Guix's GRUB to reFind <mehlon>some day Guix will add direct reFind support... but for now this is how you do it <ngz>bandali: I cannot reproduce your problem with guix environment --ad-hoc emacs-next emacs-orgalist -- emacs <PotentialUser-99>aright, I'll dive into the reFind documentation to see how I achieve that, thanks for the guidline <ngz>bandali: Did you customize `orgalist-context-function' somehow? <bandali>ngz, hmm, weird. iâll try with that in a sec. and no, i donât have any customizations to orgalist <bandali>ngz, hmm, youâre right, i wasnât able to reproduce with emacs-next. though iâm on a later commit than that <bandali>iâll bumping emacs-next to latest master (which was recently bumped to 28.0.50 btw) and see if i can reproduce then <bandali>if not, it must be something with my config <brettgilio>leoprikler: I added VoIP support to our build of emacs-telega. <brettgilio>leoprikler: i don't use it either. But I figure we should be complete about it incase somebody does want it and then comes to think we just have a broken package. ;)