<DynastyMic>Hey guys, do any of you know if I can use maven as a build system? <porcupirate>I think I want to try writing a book on how to make practical use of guix. I don't think my book would be valuable if I only cover things in the manual or cookbook. Any recommendations on topics I should cover? <DynastyMic>I happen to be a complete noob at guix. But I think an easy yet complete guide on packaging would be good for making guix grow <DynastyMic>also do you plan to print the book? or would it be a online book? <porcupirate>I hope I can physically publish it. That's one reason I want to avoid simply going over information in the manual. <DynastyMic>mhhh... It might require lots of editions, but maybe you can cover the core of guix <porcupirate>Some things I don't expect to change in the foreseeable future, like how it's built on guile. <porcupirate>I deploy to 3 different computers on my LAN, and whereas each OS configuration needs different specifics like the disk UUIDs, I like to keep the list of system packages the same for each computer. <porcupirate>I actually don't think guix is changing very rapidly. Sure, we've recently seen changes in a few big things like the format expected for inputs and the deprecation of guix environment, but I don't think we are likely to lose features like guix deploy or guix home or guix build --with-source=package=source <DynastyMic>I guess the current documentation lacks examples <DynastyMic>for someone who is not a pro at os engineering it is hard to understand exactly how to achieve x <DynastyMic>right now I'm having a hard time packaging the protege software <DynastyMic>as it is my first time creating a guix package, and also I'm don't have a full CS degree <DynastyMic>the hard thing to understand is the nitty gritty of packaging, such as the build systems, phases, inputs, native inputs, etc. <DynastyMic>like, I already know I want to package a specific software, but what should I look for in the source code's software <porcupirate>I'll keep that in mind. So far my plan for the bulk of "part 2 - development" includes a chapter on defining packages, including "basic package definition", "types of input", "modifying build phases (adding, removing, modifying)", "inheriting packages", "importing package definitions" <porcupirate>I don't have an index yet. I'm just in the planning phase. <porcupirate>If it's python, use python-build-system. If it's guile, you can usually use the guile-build-system. If it's perl, there's a perl-build-system. <DynastyMic>yeah, maybe a hands on approach, could differentiate from the documentation <porcupirate>It only gets complex with languages like C and C++. Does it use the gnu build system with a configure script, or does it include files that cmake looks for? <DynastyMic>i think python, java and C++ are the most common <DynastyMic>I guess most people would want to package software with such languages <porcupirate>Java is also tricky. Last I checked there's only the ant-build-system, but that was 2 years ago. <DynastyMic>so yeah, maybe one doesn't even know what questions to ask <DynastyMic>since it seems there's only one package built on maven <porcupirate>Mostly newbies who already know something about gnu/linux. I'm also hoping that I can make the case for guix as a development tool, though we might be too late to compete against Docker. <porcupirate>If guix can be used professionally that will spark its development. <DynastyMic>if it helps, I've been reading "The Land of Lisp", and it is the kind of books a newbie can digest <porcupirate>I like "The Land of Lisp". But its dice of doom web server project is broken. <DynastyMic>I spent a year and a half understanding why guix is superior <DynastyMic>so as a newbie the features of guix are only appreciated by pro os engineers. lol <porcupirate>I might touch on some FAQs that can't be answered on the mailing lists or in this IRC channel. Forbidden dark magics that won't ever be in the approved manual. ***robin_ is now known as robin
<porcupirate>I'm not a pro os engineer. But that is one of the careers I wouldn't mind taking up. <DynastyMic>It occurs to me that maybe it is the case for two different books <DynastyMic>as it seems the guix as a development tool, could make room for an entire book <DynastyMic>as you said, having the same software shared across computers is a bliss <DynastyMic>so you might first have a clear audience target and purpose <DynastyMic>ex. help *newbie and mid developers* understand how guix is superior as a development environment <porcupirate>So far, my plan for 500 words per section and 8 sections per chapter and 16 chapters leaves me at an estimated 250 pages. That includes chapters on guix as a package manager, as a development tool, as a distro, and as a decentralized project <drakonis>porcupirate: did you try using clisp for it? <porcupirate>The programming books in my collection have as many as 620 pages <DynastyMic>mmh... maybe you're aiming too abroad. Not sure if you could cover those topics enough <porcupirate>drakonis: yes. ungoogled-chromium and icecat both said the http syntax was incorrect. <porcupirate>I'll write about all those topics until I feel like they're in-depth enough, then reorganize and restructure if I have too many pages. <DynastyMic>also have you tried asking in the r/guix subreddit? <porcupirate>"Too many pages" may depend on the publisher. Apress published a 3-volume set of Using and Administrating Linux with 600 pages in the first 2 volumes. <porcupirate>No, I actually have tried to avoid reddit. But if you think that's a good place to ask for topic ideas, I can head there. <drakonis>asking reddit about topics for a book is probably not the best route <drakonis>you should look at the documentation beforehand <porcupirate>I did ask here after considering the manual, the cookbook, and the tutorial videos. I'll probably ask here tomorrow as well. <drakonis>i'm not sure whether what's in the book will always apply <porcupirate>I've been with guix since 2019. In that time, guix added a lot of features and changed only a little of the API. <porcupirate>Many of my ideas stem from the advantages of guix being written in guile. That's not going to change. <porcupirate>The biggest API change since I got into guix was probably the change in the inputs format from a list of tuples to just a list of packages. <porcupirate>I can only think of two or three instances when I've had to check what changes I missed when my system failed to build, and those changes only required minor tweaks. <porcupirate>guix home is not stable yet, but by the time I'm ready to publish I expect it to have settled down. <donofrio>so if you had a log4j older exploitable version of log4j would you use guix-update and such in order so to solve log4j exploits like updateing thelog4j2.17.x.jar file within my tomcat_base.2021-12-17-04-19 would guix-update to auto version control of a directory that contains packages? ***erhandsome_ is now known as erhandsome
***erhandsome is now known as erhandsome_
***erhandsome_ is now known as erhandsome
***LispyLights is now known as Aurora__v_kosmos
***Aurora__v_kosmos is now known as Aurora_v_kosmose
<AIM[m]>How to make Pipewire work on guix? <AIM[m]>What all services or packages do I need? <AIM[m]>I did install the pipewire package.... <iyzsong[m]>AIM: you need wireplumber too. start pipewire, pipewire-pulse and wireplumber before any pulseaudio based applications should work. <AIM[m]>How do I add the services for them? <KarlJoad>Is there anything fancy that needs to be done to make stumpwm or sawfish work? <iyzsong[m]>pulsewire need to be as a normal user who own the desktop session, i run it in my sxrc or sway/config or in xfce session startup apps. maybe it can run as shepherd user services too, but not system services. <AIM[m]>I run with base services and some other services I added manually <AIM[m]>Anyone got qutebrowser working? I'm having the fonts not display... I heard it is coz of webengine dependency being outdated? <iyzsong[m]>AIM: yes, xinitrc sounds right. elogind is system service, but pipewire isn't. <AIM[m]>I remember Pipe wire havung pipewire-alsa on other distro <iyzsong[m]>um, that's for applications not support pulseaudio, if you does have those apps, then you can fix it later... <AIM[m]>Thanks, I'll just install wireplumber and have them start using xinitrc <KarlJoad>iyzsong[m]: I know they do not have service-types defined for them, so I figured there might have to be additional configuration to make them work. Neither TWM has information in the guix manual. <iyzsong[m]>display manager (slim, gdm, etc.) will list them if they are in the system profile, or you can start it in ~/.xsession. or without display manager, use sx and xorg-server-service-type. <AIM[m]>iyzsong @iyzsong:envs.net: I'm getting errors <KarlJoad>iyzsong[m]: Just tested it. Thanks! Good to know it is that easy to add stumpwm. But sawfish had an error compiling. Something is wrong, but I cannot track it down right now. <iyzsong-w>KarlJoad: you're welcome. also a bug report for sawfish build failure to the bug-guix list is welcomed too. <iyzsong-w>um, can you see the correct audio device in 'pavucontrol'? <AIM[m]>It shows no output devices available <iyzsong-w>AIM[m]: does your user have the 'audio' group? <iyzsong-w>well, last try, what's your window manager? you can launch it with 'dbus-run-session -- XXX' <iyzsong-w>okay, how dwm was started? replace 'exec dwm' with 'dbus-run-session -- dwm'.. <AIM[m]>Is it requivalent to dbus-launch? <AIM[m]>Like that's how it's running now <AIM[m]>Do I need to change it to dbus-run-session ? <iyzsong-w>you can try, or check that shells for 'wireplumber' and 'mpv' have the same value for the 'DBUS_SESSION_BUS_ADDRESS' enviranment variable. <iyzsong-w>um, I have no idea now.. does pulseaudio (stop pipewire, etc. and start pulseaudio) works? <gnoo>what about mpv --ao=alsa? <iyzsong-w>yeah, first make sure alsa works, 'mpv -ao=alsa' or 'alsamixer'... <gnoo>do you want pipewire/pulseaudo for headphones/bluetooth? else, alsa is working preety good for me <gnoo>well alsa _has_ to work, everything else uses it but not adding anything on top is working so far <fproverbio>i have to ask, after bashing my head against the documentation i can't make this work <fproverbio>i would like to modify %base-services and %desktop-services inside the services field in a config.scm file. How would i go about doing that? <roptat>finished a round of ocaml updates :) <AIM[m]>Is this a thing now? "Hi guix", it feels like some random Yout*ber saying their intro, normally people just say "hello everyone".... <fproverbio>for context, i'm writing a system declaration for a vm i would like to have. The vm needs to have the gnome desktop environment and the nix service with annex binaries and builder <roptat>we've been saying that for *years* <AIM[m]>fproverbio: I just used base services with additional services <fproverbio>AIM[m]: never thought about it, i see people do it here all the time <AIM[m]>Idk desktop services are bloated af <AIM[m]>Base services are needed I guess <gnoo>then use my-base-services instead of base-services <roptat>%desktop-services extends %base-services, so don't use them at the same time <fproverbio>roptat: thanks, i was trying to fit two cons* procedures (?) into the services field but it wasn't gonna have it ***iyzsong-www is now known as iyzsong-w
<AIM[m]>Anyone got Zathura working with poppler? <phf-1>Dear Guix, what are the best resources you know for learning Guile? Of course, I checked the Cookbook and the Guile Reference Manual. Are there others? <gnoo>AIM[m]: i've installed zathura, zathura-pdf-poppler and zathura-djvu and it's working without any configuration <gnoo>not exactly guile but it's a great book, <gnoo>oh, nice! i've not yet finished that one <AIM[m]>gnoo: Oh, for me it just shows a black screen <AIM[m]>And says cannot recognize file type <AIM[m]>It says could not open plugin directory and could not determine file type <ekaitz>phf-1: you already know while then! <gnoo>AIM[m]: what does `guix package -I zathura' output? <ekaitz>phf-1: you might be missing some <ekaitz>phf-1: ...api stuff you can learn from other guile projects <ekaitz>phf-1: sometimes guile is weird for me comparing with other schemes that support less things, but in the end it's just making yourself confortable with it <ekaitz>there's some people trying to make a guile cookbook but it will take time <ekaitz>that's the hardest part in my opinion, learning how does people do things: how do I read a file? how do I ...? <phf-1>ekaitz, exactly: this is what I'm trying to find resources on. Racket is quite different for example. <ekaitz>phf-1: the sad news about this is there's no good reference for that... just code <phf-1>ekaitz, maybe you know some good and small code bases ? <phf-1>things from which to take inspiration from? <ekaitz>I contribute to guix usually and I feel a little bit lost with guile's cool things too, it helps <ekaitz>you don't really need to know all the fancy stuff to make some packages and start getting in the project <phf-1>ok, thanks! will study that. <donofrio>so if you had a log4j older exploitable version of log4j would you use guix-update and such in order so to solve log4j exploits like updateing thelog4j2.17.x.jar file within my tomcat_base.2021-12-17-04-19 would guix-update to auto version control of a directory that contains packages? <jlicht>anyone using guix's clojure-tools package? I'm trying to do something with the `-T` flag and I'm getting some pretty obscure errors, and I'm wondering if this is PEBKAC or a known issue <SeerLite[m]>I just learned about `git diff --color-words` and it's amazing. It makes understanding changes so much easier :) <SeerLite[m]>AIM: Hey, did you install zathura+plugins globally or in your user profile? Try re-logging or rebooting <AIM[m]><SeerLite[m]> "AIM: Hey, did you install..." <- Globally actually <AIM[m]><gnoo> "AIM: what does `guix package -..." <- Gives me nothing <gnoo>how did you install zathura, zathura-pdf-poppler? <SeerLite[m]>Yeah it gives you nothing because that searches the user profile only <SeerLite[m]>Have you tried rebooting yet? I had issues getting zathura working at first too. Not sure if it can be fixed by just re-logging/rebooting or if they have to be installed in the user profile <gnoo>why not install in user-profile? <gnoo>system packages won't get updated unless you guix system reconfigure, i think <AIM[m]>Like I installed with reconfigure <AIM[m]>I'll probably make a user config file <AIM[m]>It's strangely working after reboot? <AIM[m]>Like aren't Linux programs supposed to work without reboots? <gnoo>it's better to install in your user profiles and only include necessary programs in system config <AIM[m]>I'm not used to like keeping user profiles <AIM[m]>Like dya copy over the system config and place it in the home dir? <AIM[m]>And then you update both the system and user by running reconfigure on both? <SeerLite[m]><AIM[m]> "It's strangely working after..." <- Sometimes a re-log or reboot is needed to get the right environment variables. Search paths magic <AIM[m]>Can I like have it force reload? <SeerLite[m]><AIM[m]> "I'm not used to like keeping..." <- I think what gnoo means is to just use `guix install` to install packages and `guix upgrade` to manage packages from the default profile. That's how I do most too <SeerLite[m]>AIM[m]: Yeah, sometimes `guix install` will tell you what to do, not sure if `guix system reconfigure` does (maybe it should?). For the default user profile it's `GUIX_PROFILE="$HOME/.guix-profile"; source "$GUIX_PROFILE/etc/profile" <SeerLite[m]>And for the system profile I think it's just `source /etc/profile` <SeerLite[m]>It only works for that one shell you do that though. I think a reboot is unavoidable, but maybe I'm wrong idk. This is just what I personally understand about how search paths/profiles in Guix work <ngz>It seems Repology has had troubles catching up with Guix package updates since a couple of days. <donofrio>so if you had a log4j older exploitable version of log4j would you use guix-update and such in order so to solve log4j exploits like updateing thelog4j2.17.x.jar file within my tomcat_base.2021-12-17-04-19 would guix-update to auto version control of a directory that contains packages? <tbss[m]>Alguém aqui fala português ou espanhol? <apteryx>civodul: zstd is about 350% faster at decompression compared to gzip, so if we were to move manpages compression to that format, the man-db hook shoud be sped up by as about much, I'd think <gnoo>AIM[m]: if you're using bash, you don't have to do anything, just `guix install <package>' should work <gnoo>if not, then source ~/.guix-profile/etc/profile in your shell's initrc <AIM[m]>Like I've seen vids where they copy /etc/config.scm to home dir <gnoo>read info "(guix) Getting Started" <gnoo>they're probably using guix home, which you don't really have to <AIM[m]>Like I thought maybe I could run guix system reconfigure without sudo and have it reconfigure just user profile <AIM[m]>Guix home is documented in the same manual? <gnoo>you can, just `guix package -u' will upgrade all installed package without requiring sudo <gnoo>(and a guix pull beforehand) <AIM[m]>gnoo: I did read it back then, I need to revise it again... <gnoo>yes, but first just use guix <gnoo>also don't soure the file as the manual says if you're using bash, the manula should probably be fixed to say that <gnoo>>Unless you’re on Guix System,... <SeerLite[m]>gnoo , AIM Putting the system config file under .config/guix has nothing to do with Guix Home nor reconfiguring without sudo. It's mostly just done for organization purposes (to have both channels.scm and the system config in the same place). It doesn't really do anything else <gnoo>hmm, will guix update that file whenever it changes something? <AIM[m]>SeerLite[m]: Ohh, Thanks for the clarification <gnoo>hmm, ohh ok i get what you mean, you mean instead of using /etc/config.scm, you use ~/.config/guix/config.scm <AIM[m]>Also, like can I keep a scheme file to keep track of user installed packages <AIM[m]>Like packages local to the user? <gnoo>yeah that makes sense i was thinking something else <gnoo>AIM[m]: there's ~/.guix-profile/manifest <gnoo>but guix keeps track of that, you don't have to do that at all <gnoo>you can "roll back" to previous list of installed package at any time <gnoo>so, even if you uninstalled something, it'll be in /gnu/store and you can unroll it again <gnoo>guix does that better ;) <SeerLite[m]>Yup. You can also use --export-manifest (I think on guix pull?) o get an editable file <AIM[m]>I wanna git both my system config file and user installs... <AIM[m]>So export manifest spits out a scheme file? <SeerLite[m]>AIM[m]: I've been meaning to set this up too. I think there's a page about a workflow with manifests in the cookbook. Don't know if it's declarative but check it out <SeerLite[m]>AIM[m]: Yeah and then you can install it with guix package -m <SeerLite[m]>Like gnoo said though, if it's just for local version tracking, you don't need Git, you can use `guix pull --roll-back` and/or `guix system --roll-back`. Personally I only intend to use Git it as a backup <AIM[m]>But I kinda like have many systems <AIM[m]>And I like to sync them all maybe after a wipe <AIM[m]>Guix seems good for servers as well <AIM[m]>If I do home servers, Guix is the way then.... <donofrio>which is the best version control for packages within a directory, guix or nix or homebrew? like we have a directory called /vendor and this is where we run apache tomcat out of and more.... <rovanion>donofrio: Well, on which platforms do you need to run it? Homebrew is OSX only and Guix Linux/Hurd only IIRC. <donofrio>rovanion, i've run homebrew on redhat and suse before <castilma>I'm running guix time-machine -C g.channel -- package -m g.manifest and it fails with compute-guix-derivation 1005B 21KiB/s 00:00 [##################] 100.0% <castilma>guix time-machine: Fehler: bind: Datei oder Verzeichnis nicht gefunden <castilma>the manifest only contains icecat. So I don't get why time-machine needs bind, /or why it can't find it. <civodul>i'm not sure about the translation of the 'bind' error <civodul>is it reproducible if you run it again? <castilma>guix time-machine: error: bind: No such file or directory <civodul>castilma: could you run the same command, preceded by "strace -o /tmp/log -f"? <castilma>note: my $TMPDIR is set to /run/user/1000/. I changed it to /tmp/tmp, and now it is at 'computing guix derivation' <castilma>with the changed TMPDIR to '/tmp/tmp/' the bind line in the strace is: 1973 bind(15, {sa_family=AF_UNIX, sun_path="/tmp/tmp//guix-build-output-1973"}, 34) = 0 <civodul>ah, so presumably, with the former TMPDIR, it was trying to create a file in a non-existent directory <castilma>see the last line of the pasted strace log: 1909 bind(15, {sa_family=AF_UNIX, sun_path="/run/user/1000/:/run/user/1000//guix-build-output-1909"}, 56) = -1 ENOENT (No such file or directory) <castilma>i think guix creates the path in a wrong way. <nckx>‘Hi Guix’, as Pewdiepie would say. <nckx>tbss[m]: Relatively few people here speak those languages, but please ask anyway :) There's also the help-guix <at> gnu.org mailing list, which reaches more people. <AIM[m]>nckx: I bet he says the Swedes invented Guix, and we should be thankful to them... <nckx>I don't actually know anything about him. <nckx>He's the only ‘YouT*ber’ I know :) <civodul>castilma: looks like build-aux/build-self.scm picks $TMPDIR as-is, so yes, it could be that you set an incorrect TMPDIR <acrow>It was recently pointed out to me that when building packages we needed to delete bundled software even if it were only used in testing because, if malicious, it could taint the build. It is a great point. Reproducible builds is one of guix's greatest virtues. <acrow>Having said all this, testing is increasingly also very important and we want to facilitate this too. <acrow>I am wondering if there is not reason to consider making the check phase by default follow the install phase? or provide a mechanism to swap the order. Is this already possible!, by just reordering %standard-phases? Hmm... <nckx>It's already possible, and an existing build system might even do this already. Your (very implied) read-only #$output is not the case, though, so ‘tainted’ test suites could still modify the installation. <acrow>nckx: Ok, yeah, you get the gist of my thoughts, I'm thinking stash away the valuables and then let go with any testing you could imagine. But if we can't effectively stash things away then it isn't a real option. <nckx>It's a bit close to the ‘security is all that matters, so a sandbox is all you need’ hype that plagues software at the moment. It distracts from why there's software being bundled in the first place and doesn't solve that. <nckx>Why can't it be unbundled? remains. <nckx>But eh, I'm being a stick in your mud. <acrow>I tend to think of the bundling being marketing for developers... It isn't a good thing; except that it facilitates a good test methodology. It would be great to be able to distinguish between the cases. <acrow>btw, I obviously haven't tried; but, is phase re-ordering as simple as changing the %standard-phases list? or are there going to be unforseen consequences? <nckx>TBC, I think your suggestion is good and should be considered, it just doesn't obviate unbundling IMO. <nckx>acrow: I'm sure there will be (modifying anything at this point breaks one of 20K+ packages :) <acrow>Excellent point, I wasn't even thinking about backward compatibility. <nckx>But that doesn't mean it's bad. A package might (add-before 'check 'setenv-some-stuff-that-install-also-happens-to-need). That's not a fatal flaw & can be fixed. <civodul>acrow: for the GNU build system (and similarly for CMake), "make check" is designed to work before "make install" <civodul>so changing the order for these two build systems wouldn't buy us anything i believe <civodul>ah sorry, i meant "changing the order of the check and install phases for these two build systems" <nckx>You've packaged more things than I have but I don't recall one ever implying the other, and don't see how installing something could break the check suite (actually, I can, ‘mv foo /bin’ in a Makefile, but c'mon :) <nckx>I didn't know that was a problem. <civodul>having check after install is probably not a problem, but i wonder what it would bring <acrow>I have noticed that, for example, no outputs dirs exist during the preliminary phases (and that made sense) but it does prevent putting anything aside until the install phase arrives. <nckx>You can actually always (mkdir #$output) AFAIK. Phases aren't as sandboxed as you might think. <nckx>Making it so that only 'install (or phases named 'install-*, 'split-*, but ew, policy by convention) have a writable #$output is one of those things that makes sense in an optimistic way but would break many many more packages in practice. <nckx>‘many many’ was a typo but it works. :shrugs: <nckx>Oy, my auto-replacements have deserted me :-/ <jackhill>I'd be interested in some more examples that this is a common testing pattern before feeling confident making build sandbox changes. My intuition is that testing problem solutions will be unique to each package, but perhaps I'm wrong? <acrow>The thought is only valid if 1). reproducible builds is not jeopardized and 2). it still facilitates testing by allowing you to carry some approriate testing-only bundled materials. <podiki[m]>should the change to guix pull --news errr...have had a news update? (or did I miss it, ironically) <acrow>I think you have to use 'guix pull -N --details' now. <jackhill>acrow: I think I say the package you're working on go by on the mailing list, but I guess I could use some more examples from various packages about what these testing-only bundled materials are and why they can't be unbundled and built from source. Of course, my understanding what's going on won't help you solve the problem, so it's probalby not that important 😁 <gnoo>porcupirate: yes, just have a git directory then include that in channels.scm <jackhill>porcupirate: I believe that they channels spec supports file:// URLs. Depending on what you're doing you may also be interested in GUIX_PACKAGE_PATH <nckx>acrow: Note that AFAIC this change wouldn't change or at all reduce the ‘please unbundle things’ policy of the distro though. It would be a set of extra braces on top of your jorts (in case the jorts are malicious, as many jorts are) but we'll keep a general anti-jort sentiment in the distro. That won't change. <nckx>As far as I'm concerned anyway. <gnoo>porcupirate: i only needed that when using packages defined there for system configuration. otherwise, you can get away with -L flag for guix package and guix build <porcupirate>jackhill: Helping someone on Matrix. That's what I was looking for. Thanks! <nckx>We bridge to Matrix. Please tell them they're welcome to join. <nckx>acrow: I have no clue which package this is about, by the way. <gnoo>i'm getting weird errors by ld while trying to build a package: <gnoo>ld: i8086util.o:/tmp/guix-build-i8086emu-0.9.2.drv-0/i8086emu-src-0.9.2/src/i8086proc.h:35: multiple definition of `core'; /tmp/guix-build-i8086emu-0.9.2.drv-0/cc24KWSn.o:/tmp/guix-build-i8086emu-0.9.2.drv-0/i8086emu-src-0.9.2/src/devices/../i8086proc.h:35: first defined here <porcupirate>"Failed to make link: This room has 434 users, but the maximum for a bridged room is 100." <apteryx>seems mysql should propagate zlib and openssl for pkg-config <nckx>I'll have to ask. Thanks for reporting that. <nckx>gnoo: I've not seen it in quite this form before (a .h file, rather than a section+offset), but try adding "-fcommon" to CFLAGS. <roptat>uh, I'm trying to use lld to build my android stuff, but I get "unable to find -lc++", even though it's in ${CROSS_,}LIBRARY_PATH :/ <nckx>porcupirate: When exactly do you get that error? I am a Matrix noob. <roptat>when I add the right entry from the variable to the command line (-L/gnu/store/.../lib) it works <nckx>As I posted elsewhere recently: TIL <kline> there are days now where we are doing more klines against matrix than native irc ones <nckx>Maybe spam measure, I dunno. <nckx>Would be a pretty silly one so probably not. <gnoo>nckx: ok, it looks like it compiles! <porcupirate>nckx: I'm using riot.im as the client. Bottom right corner "Add widgets, bridges & bots". Bridge to IRC. Network liberachat, channel #guix. <nckx>gnoo: Great! Add a comment like ‘XXX required to build i8086emu <version> with GCC 10’ next to it, because upstream should eventually fix it and it can be removed. <nckx>porcupirate: Chanop Nick? <gnoo>well it's that voting age package, i don't think upstream wants to manage it anymore ;) <nckx>Still, it deserves a comment, because it's an ‘ugly’ option. <nckx>I'm a chanop here but I'm a bit confused as to what you're trying to do (owing to my Matrix cluelessness). Can you not just join #guix:libera.chat ? <nckx>Actually ‘creating’ a bridge might be just that, and that's not a cheap operation. <gnoo>nckx: usually you'd set configure flags like this right? (arguments '(#:configure-flags '("CFLAGS=-fPIC -g -O2 -fcommon"))) <apteryx>yeah, mysqlclient.pc has Requires.private: openssl but doesn't propagate it <porcupirate>I was trying to make it so posts here are forwarded to #guix:matrix.org and posts to #guix:matrix.org are forwarded here. Perhaps I misunderstood something. <apteryx>porcupirate: isn't the whole of libera.chat already bridged with matrix? <nckx>Well, it's hard to know what ‘here’ is from here :) #guix:matrix.org is already a Matrix room forwarded (in both directions) to #guix. <nckx>I don't think making another really makes sense. <nckx>Ah, I mean #guix:libera.chat, sorry. <nckx>#guix:matrix.org is *not* bridged, it is an independent Matrix room not managed by the Guix project at all (which is fine, although I think it's a shame that discussions are split). ***darosior9 is now known as darosior
<lispmacs[work]>hi, always in the past I have used "guix pull --news" to see a list of packages that are new and that are upgraded. but this doesn't seem to be working now <nckx>You're the second; I guess I will write a news entry. <civodul>those dissatisfied by that behavior must have been more vocal than those satisfied :-) <porcupirate>guix pull --list-generations looks like it does the same as guix pull --news --details. <civodul>would it make sense to keep in the source tree only translations that are above some threshold? <roptat>I don't know, I like to have them because it can motivate new translators to see there work being integrated early <djeis>Whelp, I figured out my grafting weirdness. Sortof. I ran a guix gc and then tried building python again, now it works. <djeis>Must've gotten something corrupted in to the store. <djeis>Maybe a drive issue after all, actually. <djeis>No real way to know for sure at this point though. <civodul>roptat: yes, i agree it can be a motivating factor; but i wonder if we could make the threshold a tiny bit higher <acrow>I appreciate the discussions. I got drawn away but regarding the install then check suggestion I understand and appreciate the consistency of the way we are handling it. FWIW, after some investigation (usually mimicing what others have done), guix has always already had a testing framework that I could leverage. Kudos to the progenitors. <acrow>I'm sincere. I better understand now. It's not unbundling, it is "UNBUNDLING->package (even for testing stuff)" and it makes sense. <acrow>acrow: feels an undue need to provide substantive closure to all responders. <nckx>‘hint: Run `guix pull -l' to view the news for earlier generations.’ seems inaccurate now. <nckx>Hm, my news entry doesn't show up here with guix pull && guix pull --news. Could someone confirm/deny? Did I make a typo? check-channel-news passed & the commit looks correct. <roptat>civodul, what do you have in mind? <civodul>thing is, developers complain that this part takes time <civodul>i think it's okay to take time, but not if the end result is essentially the English manual :-) <nckx>apteryx: I just realised they're banned from that wiki. <nckx>But that doesn't change anything. <roptat>I suppose po/guix and po/packages do not need a threshold? <roptat>we need to document that at least. There's a threshold to be part of the guix repository, and another for the online manual to be published <abrenon>what about keeping the files to motivate developers ("it's right there, you only have to modify them ! see, easy ?") but prevent the generation process from building things under a given threashold ? <roptat>rather "it's right there, you can modify them at weblate" <roptat>if we don't build them, I think they're just as invisible as if they were not there <abrenon>hmmm true I always forget about that *roptat is still working on cross-clang, this time it'll work for sure! <roptat>oh and I alraedy drop translations that are at 0% (no translated strings), that's a threshold, right? :p <nckx>Great! I seem to have complexed my Guix into a confused state :) <nckx>Although the news commit *is* in there. But anyway, great, thanks. <tbss[m]>I am not able to virtualize windows because of the virtualization extensions of gnome boxes <Cassio>Is there anyting wrong with this command? <Cassio>guix shell -c 4 -M 6 --no-cwd --pure --container --network \ <Cassio> --manifest=./etc/manifest.scm \ <Cassio> --profile=./home/sys-conf/.guix-profile \ <Cassio>guix shell: error: "--profile" can't be used with package options <lilyp>Cassio: you want to omit the --profile <djeis>Any suggestions for why guix time-machine would throw an error about ssl certs? <lilyp>depending on how far back you go into the past there might be an issue with the openssl package <djeis>Ah, really it's an issue with git's ssl. <djeis>Do I need to do something special to get ssl CA certs on to a guix system? <djeis>Oh, so I do. Not sure how I missed that before, must've been a transitive dep of my previous systems. <Cassio>lilyp, I've tried that, but then a shell is opened without any packages in it... <lilyp>but you're passing --manifest=./etc/manifest.scm? <lilyp>what are the contents of that? <lilyp>for the record, you might be having an issue with the cache if the manifest was previously empty and now contains packages; use --rebuild-cache in that case <Cassio>Well if I omit --profile and keep --manifest, it opens a shell with the package, but doesn't apply any changes to the proper profile <Cassio>I'll try the --rebuild-cache, and then report back... <lilyp>I'm not quite sure whether this is a good restriction to have, but if you wanted to install the packages rather than spawn a shell, you could use `guix package --profile=... -m ...` and spawn the shell afterwards <lilyp>there's nothing to be afraid of in that case, whether you do the guix package before or afterwards, it will only build things if it has to <Cassio>lilyp, yes, the profile was created, but then how do I open that profile in a --container shell? <Cassio>By the way --rebuild-cache did't change anything <lilyp>guix shell --container --manifest $MANIFEST <lilyp>alternatively guix shell --container --manifest $GUIX_PROFILE/manifest <Cassio>Neither these variables are defined, and note that I'm using a `--user` that is different than my user-name, and a profile that is different than my user-profile <lilyp>they are metasyntactic variables, you should put the path to your manifest there <lilyp>or the path to the guix profile you want to load <nckx>tbss[m]: Alas we don't support Windows here, but is this a bug in our Qemu package that one could reproduce with free software? How? *roptat managed to create a cross-clang <roptat>it cross-builds etc1tool for instance, but fails for adb or fastboot because they don't support i686... <lilyp>nckx: I don't think it's a qemu thing; at the very least I got Windows working within just qemu. <lilyp>gnome boxes on the other hand is a little more intricate than "just fire up qemu" but has the nice feature of abstracting all those nasty bits away from the user most of the time <lilyp>I'd guess that some libvirt component or similar might not be configured the way you would need to just click and be done <Cassio>Yes, lilyp, I think that will work. I'll write a script, though, because after I leave the shell I want to go back to my original profile and manifest. <lilyp>Cassio: then why modify the profile in the first place? <lilyp>just spawn a normal guix shell <Cassio>It worked! I have my shell open just the way I wanted! I'm containerized with the programs I need for this environment! <roptat>that's weird, llvm-12 defines some flags when %current-target is set. llvm-11 inherit from llvm-12 and doesn't modify the arguments, when cross-compiling it uses the same flags as when cross-compiling llvm-12. llvm-10 inherit llvm-11 and doesn't modify the arguments, when cross-compiling it, it doesn't get the cross-compilation flags <nckx>lilyp: Somehow ‘Gnome Boxes’ got turned into ‘Qemu’ for reasons unknown (probably because I, like you, use Qemu, and because I thought GB was just a gnomic wrapper around it). Thanks! It's not clear to me what the problem report actually… is. <the_tubular>'texlive-latex-listings' is deprecated, use 'texlive-listings' insted <ngz>the_tubular: texlive-latex-listings is an (deprecated) alias for texlive-listings. They are both in "tex.scm" <the_tubular>I'm getting this warning since today when I'm guix pulling <ngz>You can ignore it, unless your have specifically installed one of the mentioned packages. <ngz>Send a patch for what? <nckx>ngz: 'texlive-latex-listings' is deprecated, use 'texlive-listings' insted. <ngz>This change was introduced to avoid patching master <ngz>Modifying the affected inputs will build thousands of packages <ngz>So it's either transient warnings or a world rebuild <ngz>Partly, I think. I don't see all changes in core-updates. <nckx>Yeah, hm, that's where I was looking. <ngz>For example, latex-pgf is taken care of there. <nckx>Last touched in December. <nckx>That seemed to be the only remaining reference and it's not fixed upstream (c-u) AFAICT. 
