IRC channel logs
2025-01-30.log
back to list of logs
<eikcaz>trying to send a patch, but git send-email fails. Can I just paste the patch into the body of an email? Are the headers like "Message-ID: ..." or "Content-Transfer-Encoding: ..." generated by git send-email important? <mange>Generally those headers aren't important, but pasting the patch into the body of the email is usually a bad idea. If you can't use "git send-email", I think the next best option would be to use "git format-patch" to assemble the patch files and then send them as attachments. <mange>The reason is that mail clients often mess up the formatting of patches (e.g. formatting as HTML, or reflowing, or changing encoding, or something), whereas they usually send attachments through verbatim. <eikcaz>I'm using gnus from emacs, so maybe there is still hope? <eikcaz>I had to remove "From <HEX> <DATE>", but otherwise it seems like my patch sent <mange>The problems with mail clients messing things up usually come on the "applying the patch" side, rather than the sending side. <eikcaz>Oh no, gnu.org requires rdns to submit patches? So people that don't have a static ip address aren't allowed to contribute? <lockbox____>eikcaz: I'm not sure how you came to that conclusion but I'm not sure that had ever been the case? <lfam>Spam on guix-devel... smh <lfam>Really unusual to have spam hit my inbox these days <divya>lfam: Same, I was thrown a bit off guard..didn't know what sort of GNU organization chooses to use Wetransfer. <worni>Can I request a package? I dont know much about packaging and updating but dont have much time to look into it, if someone could update Anki I would be immensely grateful <abbe__>Is there an IRC channel for GUIX days ? Stuck in road traffic but still wish to follow <tae>What's up with git.savannah.gnu.org? <ekaitz>ddosing the fsf... what kind of person would do that...? <orahcio>Hi, somebody knows how to turn off test when install some guix package? Or I need to make a channel with that change? <hako>guix build ... --without-tests=PACKAGE <orahcio>thanks hako, I will also send a bug report, the conda package fails on check phase, I think many python packages are impossible to sucess on that phase :( <orahcio>I mean, anaconda-client fails on check phase, the conda just depends of it <hako>orahcio: I have fixed it locally, running conda tests rn <orahcio>hako: I could not build or install conda, after turn off tests on python-anaconda-client the conda sanity-check fails here <hako>Yes, a pytest plugin is missing <orahcio>hako: Do you have a channel with a funcional conda? <orahcio>Or are you modifying the check phase? <divya>guix-devel is being spammed again <jlicht>How can I force push a rebased-on-master team branch? Or am I doing it wrong? <hako>orahcio: fix pushed to master <hako>jlicht: delete the branch and push? <orahcio>hako: You mean, I need to copy the official conda from guix, and add pytest plugin? <csantosb>Hi Guix ! What does it mean the message "domain not found: Servname not supported for ai_socktype" ? <hako>run `guix pull` and conda should be buildable now <ieure>csantosb, Network issues. What are you doing to produce that error? <jlicht>hako: will I need to ask for a new "request to merge <my-branch>" mail as well? <csantosb>ieure: I send the patch in a while anyway, but it would be nice to understand <ieure>csantosb, Yeah, definitely weird. <csantosb>"guix lint: warning: while connecting to Software Heritage: host lookup failure: Servname not supported for ai_socktype" <ieure>csantosb, I can take a look after work today if nobody's picked it up, ping me around 14:45 Pacific time. <hako>jlicht: not sure about this. python-team branch was recreated recently and QA still lists it in the queue so I think you don't have to? <jlicht>just tried, seems to be picked up. Thanks hako <imagine-a-cool-n>I've recently heard of Guix and as a fairly longtime Nix user, would like to know more about it. <imagine-a-cool-n>In particular, when I want to switch to a software, I like to know its shortcomings. I already know (and despise) Nix's limitations, but what are some things that can be annoying in Guix? <decfed>I think we have some nix users here and there is also a nix-service-type to use nix on top of guix <decfed>I never used nix. You can look at the recent blog posts on the guix user survey that highlights typical user annoyances <imagine-a-cool-n>Can you describe how some common workflows are done in Guix System? e. g. Adding hosts, adding users, etc <decfed>I use guix as a package manager on a foreign distro. So cannot be helpful regarding guix system. <imagine-a-cool-n>decfed: How is (declarative) package management done, then? Any bit of information that I can contrast with Nix would be helpful. <decfed>its a DSL embedded in guile scheme. You define the expected outcome inclusing a list of userd and then instantiate the system with guix systen reconfigure <decfed>the main advantage I am hearing is guix using guile scheme as config language. That way all the tools of a general purpose prog lang are st your disposal <decfed>downsides: strong focus on source reproducibility which makes ot hard to packages certain ecosystems (go, rust) and binary only packages (usually proprietary SW) <decfed>I heard people preferring guix home to nix home manager as it is better thought out and intergrates and does not force thebuse of "flakes" as guix does. Not sure that makes sense to you <imagine-a-cool-n>decfed: Guile is one of the main reasons I want to switch. Nix is a frustrating language, and not very consistent. <decfed>I love guile. I learned scheme recently because of what feels like a revival and projects like guix, goblins, hoot, shepherd... And I really fell in love with scheme. It's simplicity and elegance <decfed>however, even with this scheme background I have trouble sometimes understanding if a function or syntax comes from guile scheme or the guix dsl <decfed>I do think that guix having been inspired by nix got some things "righter" simply because it could avoid evident shortcomings. That is the consistency you are seeing imho <imagine-a-cool-n>Also, is there a way to tell if linux-libre will break something in my system? <decfed>learning curve is steep though, you familiarity with some nix concepts might make it essier (or more confusing). The manual and documentation is excellent and I recommend a thorough read througz <decfed>Linux libre is a barrier to entry sometimed. You can use the regular kernel via the nonguix channel if linux libre does not support your particular HW <imagine-a-cool-n>Yes, that's one thing I like about Guix. The documentation may be smaller, but at least it's consistent. Nix documentation is a task unto itself. <nckx>sneek: later tell lfam: The spam was my fault (hi, it's me, I'm the spammer). I'd disabled moderation to facilitate impromptu FOSDEM meet-ups. Turns out that the spam filter is, somehow, tied up in moderation, somehow. I don't see the necessity but it is. Re-enabled. <decfed>Have you thought about using guix ontop of nix for a bit before switching your system over? <decfed>you could first switch to guix home, guix shell, manifests/profiles and the like. Then using guix system will not feel much different <decfed>maybe better than going cold turkey <decfed>packages.guix.gnu.org/ and toys.whereis.xn--q9jyb4c/ (includes third party channels) <theesm1>decfed: toys.whereis.social instead of toys.whereis.xn--q9jyb4c works asw since recently <divya>It has a bunch of crates inside, do you think I should package the crates first and then the whole thing? <divya>But that doesn't make sense to me since fetching would already fetches all those crates. <divya>I've tried to run cargo2guix through it, but haven't really got anything working. <divya>Nothing to rush for, I'll be off throughout the weekend, so let me know according to your ease. <ieure>tschilp, python-build-system has a thing that makes sure the dependencies provided by the package inputs satisfy the declared dependencies, so if that's the case, it's a symptom of an upstream bug. <tschilp>I yesterday played around in the build environment (first time doing this), I noticed ~matrix-nio 0.20.2~ getting pulled. Things however are confusing to me, as matrix-nio 0.20.2 (https://github.com/matrix-nio/matrix-nio/blob/0.20.2/pyproject.toml) does not seem to list cachetools as a hard requirement. I however encountered the error ~error: cachetools 5.5.0 is installed but cachetools<5.0.0,>=4.2.1 is required by {'matrix-nio'}~. <ieure>tschilp, What thing gives that error? <tschilp>ieure: yes, this all looks very confusing! I'm having a hard time imagining how to properly put this together. <ieure>tschilp, Is that output from `guix build', or from when you were poking around in the source tree by hand? <tschilp>but that's running ~python3 setup.py install --prefix=./installation~ from within the source tree that came with from ~guix build pantalaimon --keep-failed~. I then set up a shell with ~guix shell -D pantalaimon~, sourced the environment-variables file and started poking around.. <tschilp>As guix build keeps timing out (like on ci.guix.gnu.org as well) <ieure>Well, it's timing out during the tests, the big hammer is to disable them. Far from ideal, though. <tschilp>I'm not using matrix a lot, so I'm kind of thinking to clean up my home-environment, needs to be done anyway. Reading through the dependencies (not so much on the guix side) this does not look so good... <tschilp>me: feeling like a messy looking up my home-configuration... <PotentialUser-46>Hello. I'd like to know what's wrong with torbrowser package on aarch64-linux. It doesnt builds locally on my machine, nor in ci.guix.gnu.org. Will it ever be built? <lfam>sneek: later tell nckx: Ha! <sneek>Welcome back lfam, you have 1 message! <sneek>lfam, nckx says: The spam was my fault (hi, it's me, I'm the spammer). I'd disabled moderation to facilitate impromptu FOSDEM meet-ups. Turns out that the spam filter is, somehow, tied up in moderation, somehow. I don't see the necessity but it is. Re-enabled. <lfam>Hope everyone is having a good time in Brussels. I'm sorry to hear that Au Bon Vieux Temps is closed <lfam>We can see "Failed (dependency)" <lfam>We can look at the dependencies that can't be built because some of their dependencies fail to build, and keep clicking through until we get to the root of the problem <PotentialUser-46>More general what I want to mention is aarch64-linux support is much worse than x86_64 and a lot of packages still need to be build locally. Can somebody explain why this happens and is this realistic future that support for aarch64-linux will be better? <lfam>It's true that only x86_64 seems to have developed a "critical mass" of users, bug reporters, and people who fix bugs <lfam>There's no magical "they" who support things in Guix. It's just... us <lfam>Every package that works in Guix, it works because somebody like you or me makes an effort <PotentialUser-46>@Ifam I get it. So the only way is to send bug-report to clang team so they can fix it? <lfam>Um... that's one way. The other way is that you send a bug report and also help fix it :) <lfam>The flip side is that it's hard to find suitable hardware to make an aarch64 build farm. So there's a chicken and egg problem where nobody wants to use their weak aarch64 ARM board to test fixes, so they don't fix them. And our build farm doesn't really "keep up" with aarch64 like it can with x86_64 <lfam>It's not terrible, we have probably about 100 64-bit ARM cores. But it's not very much <ieure>PotentialUser-46, aarch64 support is definitely a known issue. I think the two main roots are that daily-driveable ARM computers that can run Free Software are still very uncommon, and the Guix CI infrastructure needs some help; it currently doesn't provide very timely feedback, even for x86_64, and aarch64 is much worse. <ieure>What architecture you run Guix on would be a very good question to have in the next survey. <lfam>I think that aarch64 is not really a mature hardware platform compared to x86_64, at least when you look for computers that can run Guix. But I think it's getting there soon between Apple and all the Qualcomm laptops from major manufacturers <ieure>It is very easy to make packages that don't work on aarch64, and very hard to find that out. <lfam>I was suprised to see recently that all the big laptop companies are offering Snapdragon laptops <lfam>And they are pretty inexpensive <ieure>Yeah, they're starting to move that direction. But the whole ecosystem is still bootstrapping, it's early days still. Not a lot of ARM software for them to run, so the cost is more difficult to justify. <PotentialUser-46>Yep. I use apple silicon, so at least for now guix builds many things locally, and many of them fails <lfam>Apple Silicon is really great stuff. Do you use it with Guix System, or Guix on another distro? <ieure>PotentialUser-46, I recently set up a Guix VM on an M4 MacBook Pro (it's a work laptop, we don't get an option, I'd never have picked this thing), and it's rough. But it's way less rough than building aarch64 stuff on x86_64 under qemu. <lfam>Your bug reports about build failures will definitely be valuable. Of course it helps immensely if you can help develop fixes too <lfam>Have you tried building the kernel on the M4? I'm curious how long it takes <lfam>I use those at work (not software related) and they are wicked fast <PotentialUser-46>but I searched for native guix distro for apple m1, and did not found that. Only thing i found is NixOs unofficial port for M1 <ieure>lfam, I haven't had to compile the kernel, but it built LibreWolf in around 1/3rd the time as my fastest x86 machine. <lfam>PotentialUser-46: Yes, we don't currently offer an aarch64 Guix System installer, although in principle it should work <ieure>Apple Silicon CPU is mostly very good (though I hate the on-chip system RAM you can never upgrade), speakers are excellent, MagSafe charger is great. Everything else about it is horrible. <lfam>There is a native installer for Guix as a tool on other distros, though <lfam>Heh ieure. It's really nice stuff... as long as you like it ;) <ieure>Hate the glossy screen, hate the notch, hate the rounded upper corners on the screen, hate the keyboard, hate the haptic trackpad, hate that it's so heavy, macOS is *awful* and tremendously buggy. It cost three thousand three hundred US dollars. <ieure>macOS is so primitive that you can't even use Emacs as your window manager. Intolerable! <Kolev>It's too bad Apple shut down pure Darwin. <PotentialUser-46>ieure i use macbook pro m1 and it was not so expensive. i think it is good as device and only thing i don't like in it is macos. So under linux it works great for me. But its interesting what laptop do you prefer as replacement <ieure>PotentialUser-46, My daily driver is a ThinkPad X13 AMD Gen 2, it's not perfect, but I like it. <ieure>I'm an unabashed TrackPoint fan. <Kolev>PotentialUser-46, does Guix work on Asahi? <ieure>PotentialUser-46, I'm a professional programmer, I do 95% of everything in Emacs, so am a heavy keyboard user. TrackPoint lets me switch from typing to mousing (ex. to use the web issue tracker or whatever) very quickly, which I value. <ieure>But, matte screen, good keyboard, can run whatever software I want. Battery life is fine. I have honestly been very unimpressed with the Apple Silicon battery life. The 16" M1 Max at my last job lasted ~4.5 hours from 100% to dangerously low. This brand new 14" M4 Max drained from 100% to dead flat over a three-day weekend of being asleep and unplugged. <PotentialUser-46>Kolev yes, it works. Some basic stuff like zsh, clang, mutt and so on distributed as pre-build packages, and it's great. As a C++ dev i found useful guix environments <ieure>ThinkPad speakers suuuuuck and pretty much always have. I do miss MagSafe on it. The 16:10 screen aspect is very nice. Having USB-A ports and not needing dongles or adapters is also very nice. <Kolev>ieure, oh yes, my speakers on my X200 are junk compared to my Chromebook. <ieure>They're also highly repairable, the manual full of exploded diagrams is a free PDF download, no account or signup or anything. Parts are plentiful and inexpensive. <Kolev>PotentialUser-46, so do you have to Guix build everything on Asahi? <ieure>Kolev, X200/X210 speakers are actually pretty good compared to some of the stuff they shipped later. X270 speakers are some of the worst. <Kolev>ieure, with my Chromebook, I can fill a room with radio. With my ThinkPad, I have to blast it, and it doesn't fill the room. <ieure>Kolev, Yeah, they've always had kind of terrible speakers. Heard a lot of people saying, well, they're business laptops. Never made sense to me, don't businesses need to do a lot of videoconferencing? <PotentialUser-46>ieure Dont know why but i think usb-a is somehow outdated port and we all better to use type-c <Kolev>ieure, video conferencing is a more recent thing. <ieure>Kolev, Well, they've continued to ship machines with pathetic speakers for the last several years. <ieure>PotentialUser-46, USB-C is massive overkill for a ton of stuff. I'm not going to buy all new peripherals because the same protocol needs to go in a different-shaped hole. <PotentialUser-46>Kolev not everything but othen some packages with many huge dependencies i need to build. My laptop got hot when guix builds some browser or llvm <ieure>Yeah, when I was first setting up the Guix System VM, it spent multiple days compiling stuff. <Kolev>ieure, I do like USB-C but having A-holes is a must for legacy devices. <ieure>Kolev, Yeah, not saying I dislike USB-C at all, just that I still use USB-A every single day, and not having a port make that a hassle. <ieure>Love that I can use the same charger for my phone, laptop, game console, etc etc. <podiki>ha "A-holes"... (i'll see myself out now) <meaty>could somebody please test the antimicrox package and verify that it segfaults for them? <meaty>and confirm with bug #75952 if possible <podiki>meaty: "guix shell antimicrox -- antimicrox" does run and pops open its window, saying it doesn't find any joysticks (indeed, nothing plugged in right now). on commit f2b3c36bee8c232b026a66de93db38e13fbd7076 <meaty>strange. what could be going wrong then? I'm running 'guix gc --verify=contents' now <meaty>oh, wait--is there a way to test with the udev tools installed without rebooting your system? <meaty>I got the same message cos though the udev rules are in the package, they weren't "loaded" until I rebooted podiki <meaty>and then once they were loaded, it starts with a segfault <podiki>udev is supposed to detect new rules but i find i need a relogin/reboot usually <podiki>i won't be able to test with the udev rules though, sorry (currently tracking down some weird gnupg yubikey issue) <meaty>that's ok, was just wondering if you knew some container wizardry or smth <podiki>udev is supposed to just reload rules (or maybe there is some command to tell it to refresh) but yeah, not in my experience <podiki>anyone recently have issues with gpg/smartcard (yubikey)? it is not the upgrade to 2.4.7 for gnupg... <ieure>podiki, Haven't had issues, I use a YubiKey every day. <podiki>hrm. maybe something with hyprland? don't see how that would affect it... <podiki>confusing errors about either pinentry not found (it is there, store path up to date in config) or something "command 'PKDECRYPT' failed: Invalid ID <SCD>" <podiki>something about scdaemon perhaps. i tried with/without disable-ccid <Kolev>I wish there was a cushy live system with a full desktop. I tried making a GNOME live image once, but it always told me "disk space full" when I booted it. <podiki>i've made one before for guix, just used the desktop config and wrote it to the usb <ieure>podiki, Suggest manually launching gpg-agent with the --debug-level argument, I've done that before to figure out what was going wrong. <podiki>booted and could play around, didn't try any installing stuff though <ieure>Kolev, Hmm, I was going to suggest making a system-image, surprised it wasn't as easy as I thought. <lfam>Hm, it's supposed to be easy <ieure>I mean, I say that, but it took over a week to produce a functional aarch64-linux system-image for a VM, and I eventually had to install Debian in an ARM VM and use Guix in there to make the system image. So maybe this stuff is actually that hard. <lfam>Ah, for aarch64. That's not going to be as easy as x86_64 <ieure>Could be as simple as needing to give a bigger size to `guix system image'. Though I'm not sure how to juggle making /gnu/store read-only and stick everything else in a ramdisk. <Kolev>ieure, I basically want GNOME + installer + diagnostic tools. <podiki>i would start with x86_64 to make sure that works (and will be quick) first <podiki>i do have some notes somewhere, but it really just was guix system image and dd (this was many years ago but worked without issue) <podiki>"gpg-agent[2307]: command 'PKDECRYPT' failed: No such file or directory <Pinentry>" and yet pinentry in gpg-agent.conf exists and works <podiki>oh i think i know, pinentry uses xwayland and i think i messed up an env variable <podiki>or rather hyprland isn't launching xwayland, might need to update in package definition <Kolev>podiki, could you give me the code to add GNOME to the installer image? <podiki>i didn't use the installer image at all, i used (if i remember) the desktop sample system config <podiki>you can use any config. the installer is a bit different <podiki>so i would take a basic desktop config, the sample one let's say, as a starting point <Kolev>Ah. See, I want the TUI installer on GNOME. <podiki>to install from there to the main disk? <podiki>you still have a full guix system, so you could just use guix system init from a config. but if you want to run the installer from in there...not sure, probably some way <podiki>would be nice to do that so we can have a nice live image with installer easily accessible. or a graphical tool to set up a basic config (or the config you use live!) and write that <Kolev>podiki, I want to have a 'rescue live system' complete with GNOME and gparted and stuff, but also have the option to run the installer. <podiki>so i'm not sure what the installer really does for you, it mostly to do disk partition and a system config <Kolev>podiki, I'm having to use the barebones installer image to run fsck on my broken Guix System. <podiki>both of which are easier if you are in Gnome to just use your favorite text editor and gui partitioning tool <podiki>i understand, what do you need the installer to do? <Kolev>podiki, partitioning. Anything to do with LUKS and partitioning is Greek to me. <podiki>yeah it is difficult, been a while since i set it up <podiki>but from a live image you can just use tools and instructions for the disk stuff like on any other distro <Kolev>podiki, last time I tried a manual installation, I had issues finding my UUID. I think that was my only issue. <podiki>the system config though...maybe the basics are in the templates from the installer (you can see that in...the git somewhere) <Kolev>System config, I have no issue. I can just grab a config from my Git. <podiki>so if you have a config, then what do you need the installer for exactly? sorry i don't follow <podiki>anyway, running instller from a graphical environment would be nice; would love to investigate but have to run <Kolev>podiki, like I said, I have never partitioned by myself before. With encryption, it's especially hard. <podiki>i getcha. i do think the general idea of installer in live DE environment is a good one, besides taht <podiki>good luck, maybe someone knows how to just call the installer program/guile script? directly but maybe everyone is having fun at the conference :)