<nckx>wednesday: I'll take a look but since I don't use SDDM I might wait to give someone who does a chance to stumble upon it. Although if it's an obvious bug fix that might not be necessary. <wednesday>It's only one line and seemed pretty obvious to me, but I'll leave that for you or others to decide later on heh <wednesday>from my testing the patch worked fine, my current system is using it right now <nckx>wednesday: How do you send your patches? <nckx>I can't get ‘git am’ to like you ☹ <nckx>Weird, they don't look off. <wednesday>Right now I've just copy pasted them into the email because I have not set up the git email stuff and such <nckx>wednesday: I had to jump through some tedious hoops to apply your startx patch so it would be great (https://tobias.gr/yeah.jpg) if you could get git send-email to work. <nckx>wednesday: So you sure you want ‘frozenpigs <purpjuice@...>’ as committer or...? <nckx>I can still change it if you like. <nckx>E.g. to the one used in your copyright line. <wednesday>Yea use that email, and this name if possible heh, thats also what I registered my savannah with <nckx>‘This name’ == J... G...? <wednesday>Sorry for the trouble, I'll try to do better next time heh <nckx>wednesday: No worries. There's probably some emacs wizardry I could have used to mangle the patch back into shape but it was just as quick to fix it by hand. For many patches... not so much. <nckx>A working git send-email and some commit messages following the GNU conventions and you'll be golden. *nckx runs the system test suite just to be sure. <wednesday>Also by my this name earlier I meant irc name, but anything'll do really <wednesday>Is there somewhere I can read about the commit messages? <nckx>wednesday: 14.6 Submitting Patches in the Guix manual (‘info guix’). The actual format is documented in another document... to which the link here is broken. Hm. <nckx>If you're like me, ‘git log’ is worth a thousand words more. *nckx is also building two kernels so tests will take a while. <wednesday>yea I have tried somewhat with some commit messages to mimic what I've seen, but better to read that and know it all ay <nckx>wednesday: Um... So this protonmail thing doesn't speak plain old (encrypted) SMTP? :-/ <nckx>That's roll-your-own-crypto level 😒 . <wednesday>I would switch email but don't know what ones out there to use <nckx>Well kudos for not using Gmail ☺ *nckx also has no idea, sorry. <wednesday>I used to use some unspeakable ones, I don't know this places rules on swares and such so wont say heh <nckx>Not sure if ‘swears’ is quite it. I'd personally be OK with someone contributing with an @poop.lol address (just roll my eyes but fine), but that particular site comes with tonnes of extra unpleasantness that just isn't aligned with our values at all. <nckx>Anyway, how about disroot.org or something? Just randomly off the top of my head. <wednesday>I'll have a look, any that wont sell my soul to the nsa and friends is a good choice <wednesday>I assume only cool kid get to have any of the gnu email addresses :( <nckx>wednesday: Only way to be sure of that is to run your own. On Guix, of course. Works for me. Now I just have to trust my hosting provider and ISP and every single correspondent and... <wednesday>how are them tests and kernels chugging along ha <nckx>I see a certain such cool GNU person added Guix to git-send-email.io ☺ <nckx>The tests are waiting for build slots from the kernels, I'm afraid. <dongcarl>Hi all, I've discovered that I can generate cross-compiler packages with `cross-gcc` and boy is it a joy to work with <wednesday>ha no worries, I may be going to sleep soon though, late over here <dongcarl>I'm wondering if I could specify which gcc version I want the cross compiler to be? <nckx>wednesday: It's 1 in the morning here, I understand. I'll close the bug if (probably when) I push. I'll leave the mypy patches open for review for now, they're not that old. <nckx>dongcarl: I've never used CROSS-GCC but I see that it takes an optional #:XGCC argument. <nckx>I'd naively assume that the output GCC is of the same version. <dongcarl>nckx: I used it to specify gcc-8 but there was a dependency error <nckx>dongcarl: Hmm, maybe, or maybe you're just hitting an untested combination. <nckx>dongcarl: Which error would that be, exactly? <dongcarl>cannot build derivation `/gnu/store/pw8lhcxzifwi3r23ypjg86djq99pwvhn-gcc-cross-arm-linux-gnueabihf-8.2.0.drv': 1 dependencies couldn't be built <dongcarl>Throw to key `srfi-34' with args `(#<condition &invoke-error [program: "/gnu/store/a4rxl40jr7gmq8bp3dryq4yq67cwkwiw-patch-2.7.6/bin/patch" arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input" "/gnu/store/z20a7ji2jimmxd7vpcbshc0g8lax2ygp-gcc-6-cross-environment-variables.patch") exit-status: 1 term-signal: #f stop-signal: #f] 56dc80>)'. <dongcarl>Looks like it was trying to apply a patch meant for gcc-6 <nckx>Yeah, that's the kind of mismatch I was expecting, unfortunately. <dongcarl>No worries, just means I can contribute one more patch lol <nckx>Parameters like #:XGCC are nice, but give the false impression that most combinations have actually been tried by someone, somewhere, ever 😛 <dongcarl>True... Well if I get what I wanna do working I'll definitely maintain the cross-base.scm stuff *nckx has a soft spot in their spleen for musl. <wednesday>tomorrow I might try patch the keyboard field for the bootloader and operating system, since they didn't work for me either heh <wednesday>If I can't fix them then I'll report them soon enough <nckx>I was surprised at how well they handled my obscure layout & frankly ridiculous set of XKB options, but did notice that GRUB fails to honour it still. <wednesday>nckx: well with (keyboard-layout "us" "dvp") in operating-system I get wed/system/pc.scm:64:1: error: invalid field specifier, with (keyboard-layout (keyboard-layout "us" "dvp")) I get wed/system/pc.scm:208:63: Wrong type to apply: #<<keyboard-layout> name: "us" variant: "dvp" model: #f options: ()> <wednesday>and with the bootloader it just made my keyboard not work ha *nckx ♥ another dvp user. <nckx>wednesday: Use dvorak-programmer, which is the XKB name. <apteryx>what's the difference between dvorak-programmer and plain dvorak? <wednesday>heh, I don't know if it's just me not knowing the right syntax for using keyboard-layout in operating-system of if it's just not working, but I think the second <nckx>apteryx: Numbers are shifted and grouped into odd/even (much like Dvorak handles vowels/consonants, it just ‘clicks’ with my brain) and IMO symbols are better placed. <apteryx>I see. Seems a light variation; I should give it a try. <apteryx>I've been interested in Bépo as well as that'd enable me to both program and type in French without switching layouts. <nckx>wednesday: Here's mine: (keyboard-layout (keyboard-layout "us" "dvp" #:model "thinkpad" #:options (list "" "caps:shiftlock" "shift:breaks_caps" "compose:102" "lv3:ralt_switch" "nbsp:level3n" "numpad:shift3" "kpdl:semi" "misc:typo" "ctrl:swapcaps" "terminate:ctrl_alt_bksp"))) <nckx>And it works even on the Linux console! (Well, probably not terminate:ctrl_alt_bksp ;-) ) Maybe you missed the ‘double‘ keyboard-layout? <apteryx>would someone here knows how to determine when shepherd is done initializing the services defined in a config? If I put 'shepherd --config my-config.scm' in my xsession, it goes on to execute the next command (non-blocking), which could be an issue. <nckx>One's a field, the other's a constructor. <nckx>apteryx: The name's a bit pretentious (though better than ‘dvorak-mod0539’) but it's a great layout. <wednesday>Whet I double it up like that I get the Wrong type to apply error for some reason <atw>:o that's where I can put ctrl:nocaps! thanks nckx! <nckx>The translation X/VT/GRUB isn't perfect yet but how is that not just completely awesome. <wednesday>nckx: why do I get wed/system/pc.scm:208:63: Wrong type to apply: #<<keyboard-layout> name: "us" variant: "dvp" model: #f options: ()> :( <wednesday>does it for some reason think the outer keyboard-layout is also calling the function? <nckx>wednesday: Could you paste(bin)(.debian) both your configuration + the error? <nckx>wednesday: Oh, I see the problem. <nckx>(k-l (k-l ...)) goes at the ‘top’ level of your OPERATING-SYSTEM, just like LOCALE and HOST-NAME and … <nckx>So it really is a top-level keyboard-layout field with a value of (keyboard-layout ...). <nckx>Then your xorg-configuration and bootloader-configuration merely refer to it. <wednesday>Are you talking in reference to the keyboard-layout on line 209? Because that one works fine <nckx>So I have (xorg-configuration (keyboard-layout keyboard-layout) (extra-config (list %xorg.conf)). <nckx>wednesday: No, ‘wed/system/pc.scm:208:63’ means line 208, column 65. <wednesday>after reading the message before my last one I got you <sturm>does ungoogled-chromium build? When I've checked on hydra over the last few keews the build seems to show failed for i686 and x64_64 master. *nckx The build farm has become self-aware and refuses to build it. \o/ <nckx>Hydra refuses to serve me 🤷 <nckx>Are three people trying to use it at once now. <apteryx>does anyone else thinks that timezone in operating-system record could default to GMT? <apteryx>Right now I *have* to give a timezone, even for throw-away container system definitions <nckx>apteryx: Or UTC but yeah, agreed. *nckx couldn't help themselves. <nckx>apteryx: I think I'll hack that up unless you want to. <nckx>Hafta do something while watching $SPORTS_TEAM lose. 😒 <wednesday>I'll be off for tonight, thanks for the help and such nckx <apteryx>what is the 'user-processes' service, and why does syslog-service-type depends on it? <apteryx>oh, got my answer: This is a synchronization point used to make sure user processes and daemons <sturm>Is https://mirror.hydra.gnu.org no longer part of the default substitute-urls? I'm getting "system reconfigure --dry-run" build significantly less when I explicitly include mirror.hydra.gnu.org <apteryx>get started only after crucial initial services have been started <nckx>apteryx: I think it's just a ‘signal’ virtual thing. <vagrantc>sturm: i think it's only ci.guix.info now <vagrantc>which seems to really be lagging on armhf <nckx>sturm, vagrantc: Yes. See %default-substitute-urls in (guix store) . *nckx was about to contradict that but apparently adds mirror.hydra back manually in their system.scm. ***langdon_ is now known as langdon
<apteryx>hmm, I'm still seeing this: error in finalization thread: Success <nckx>apteryx: It's still ‘normal’. <nckx>Without looking in depth, that's a different error (bad file descriptor) that I've also been seeing a lot. So neither is fixed. <apteryx>Shutting it up for now with: GUILE_AUTO_COMPILE=0 guile /var/guix/profiles/system/boot > /tmp/boot.log 2>&1 & <apteryx>(this is in my entrypoint.sh script for a Docker image generated by guix system docker-image) :-) <nckx>I was just about to ask. I only see it when booting old-school real 'puters ☺ <apteryx>sucks a bit that /tmp gets wiped in the process though, I'll save the file somewhere else (CWD, ahem) <apteryx>I'll post this to guix-help when I'm done. It's a lot of hours sunk into the experiment! ***vagrantc_ is now known as vagrantc
***vagrantc_ is now known as vagrantc
<g_bor>I am willing to set up a channel for the first time, and running into a problem. <Blackbeard[m]>civodul: could you please guide me on how should i try to fix this <civodul>i'd recommend starting by looking at the API in (guix store) that allows you to determine whether substitutes are available <abcdw>Guys and girls share your guix system configs plz. Want to see how people manage their systems and maybe pick some ideas. <abcdw>roptat, beautiful, thank you) If anyone else wants to share, will be glad to see you repos) <tune>can someone look into updating the mumble package to 1.3.x? currently it's on 1.2.19 where apparently pulse considers it a phone, making it mute music apps. on 1.3 they declare themselves as a game which doesn't cause this issue. <civodul>tune: consider giving it a try and sending a patch :-) <abcdw>meiyopeng, thank you. You probably forgot to commit packages/linux-***free.scm :) ***buffet_ is now known as buffet
<wednesday>awesome my sddm change made it in all fine; now there is only one thing keeping me on my git version but that one should hopufully be delt with in a few days <nckx>wednesday: The mypy stuff? <wednesday>nckx: Nah that's fine, I had some patches for some lispy things, the one patch there that I /need/ was the update to bordeaux-threads, when I updated it in my package path I would get complaints about it being imported from 2 modules heh <wednesday>It's all stuff that I needed to build next browser from git, if you use it heh <nckx>Nope. Waiting for it to mature. Interesting that you do, though. *nckx looks up purp juice. <wednesday>I'll be looking into setting up git mail stuff today, so my future patches wont be such a pain, sorry about that <wednesday>Gotta get used to the whole flow of things ya get me <wednesday>Now that I got the operating-system keyboard working I should see if I still get my boot loader problem, I'll try that out later <nckx>wednesday: Note that you'll still need to add (keyboard-layout keyboard-layout) to bootloader-configuration. <wednesday>yea, I presumed that heh, I was going to reboot before that too just to ensure my keyboard already works, ya never know with these things <nckx>OK. Just mentioned it since it seemed like the kind of thing e.g. NixOS would just magically pass everwhere. <nckx>(Not saying that's a good thing.) <wednesday>Well I requested a disroot account, but need to wait to get accepted next ha <nckx>wednesday: We don't have an ‘MIT licence’ because that name covers multiple (subtly) distinct licences. <nckx>(When in doubt, it's usually expat.) <nckx>Both of those are in Guix. <wednesday>Well in that it already maps it to expat, its just it misses some case variations, like a capital L on license <wednesday>which makes it set the license for the import to #f instead of what it should me <nckx>Ah. So the licences on PyPI are just free-form strings? Nice. <wednesday>Yea, all the info the importer gets is just the variables at the bottom of the setup.py from what I know, or stuff from requirements.txt <nckx>If so, a patch to lower-case them would indeed be useful. <nckx>I just assumed they had some kind of enum system for licences but never looked. <nckx>Ah, the name that will never die. <wednesday>From what I've seen it just does it the way I said above, but I'll look into it a bit more and mess about with it <nckx>ebrasca: I see the problem. Fixing... *nckx just replied to guix-patches@ 😒 gah. <ebrasca>nckx: After repeating it worked, thanks! <nckx>ebrasca: There was an error in web.scm. That's what that backtrace was trying to say. <nckx>wednesday: Regexes can get unwieldly fast but that seems like a manageable set. We'll just have to be very careful not to parse e.g. ’GPL3+ except ...’ as ‘gpl3+’. Maybe have the importer add a comment with the raw string value whenever it falls back to regexing. Anyway, stuff to be discussed on the ML ☺ *nckx can't get backspace, pipe, and backstroke keys to work on their new 'top and is becoming very annoyed. <nckx>No, backspace is not ‘XF86ScreenSaver’ you dolt. <wednesday>is this libinput being weird or other things? ha <atw>nckx: it wouldn't happen to be a librem, would it? I had to do a weird thing to fix that ***rekado_ is now known as rekado
<rekado>nckx: I used to have an activation service type extension that would run kbd’s setkeycodes with 56 and 43 to change the behaviour of the pipe key on the Librem 13. <rekado>otherwise | would produce < or >. <nckx>I'm not sure yet. This is my first time on a US keyboard (blech) and I thought it was the 104/105 key mismatch but I doubt that now. <nckx>rekado: Sounds like yours was, since <> is the key that's missing on 104-key ones. *nckx will try setkeycodes as the dreaded last resort. <nckx>atw: No, it's an X230(T but that shouldn't matter). Thing is, I borrowed an L430 which is more or less its sister ship (and has the same keyboard, but 105-key Belgian) and it worked just fine. <nckx>I wish I still had it so I could swap them. <nckx>atw: What did you have to do? <nckx>(-model thinkpadxxx doesn't fix this, by the way, I think that's for the older top-heavy Thinkpad keyboards.) <nckx>Now it thinks backspace is ‘i’. I can't even remap that. How'd I get into this mess. *nckx to the rebootmobile. <kmicu>nckx: did you try any other distro? Maybe that issue is specific to Guix’s defaults. <kmicu>nckx: ah, it looks like T version is special xD Good luck then. <nckx>kmicu: How so? It should be identical to the X230 in all respects but the touchscreen. <nckx>kmicu: No other distros on hand, but the lack of similar search results makes it pretty clear that this is a Guix thing. <nckx>\o| \o/ |o/ Well remapping works for now. <nckx>Great fun using Unix without \ and |. <nckx>atw: Thanks. I'll keep that bookmarked just in case. <nckx>Well serves me right for not adding the T. (Shouts ‘...but they *are* identical!!’ into the sunset.) <kmicu>(Yeah, ‘but the touchscreen’ and that input device could mess everything up for T version.) <nckx>Oh no, wait, I did try that. <atw>might wanna copy it, nckx, I set the paste to expire <nckx>(Also the ‘My x230t is dead [now]’ later in that thread made me feel really great about my punchase. 😒 ) <kmicu>Nah, that could be anything, including user’s misbehavior. <kmicu>(In the end that person fixed it so that sounds like a usual Thinkpad Tank.) <nckx>kmicu: I'd doubt that the touchscreen could affect keyboard mapping but, honestly, I've seen weirder. You may be right. *nckx didn't get Thinkpad fandom *nckx borrowed a Thinkpad for 2 weeks after their laptop broke <rekado>I was actually rather underwhelmed when I got my first Thinkpad. <rekado>the keyboard was just okay. Only when I had to use other laptops at work did I realize that they are actually pretty exceptional. <rekado>I still want to build my own one day. ***apteryx_ is now known as apteryx
<nckx>I found some ‘retrofit your x230 with the older x220 keyboard’ (because older == always better) guides, but having used both I'm not convinced it's worth it. <dongcarl>nckx: Definitely not worth the man-hours the Guix project would lose from it ;-) <nckx>dongcarl: I'm lucky that the touchies make it impractical to replace the screen with a (slightly larger) high-DPI one or I'd lose a week ;-) <nckx>The screen bezel contains magical touchies that would escape, and also not quite cover a full-HD mod. <nckx>One could hack around that in software but honestly 1377x768 is fine. *nckx → AFK for hours. o/ <dongcarl>Trying to install from git... `make check` is showing that tests are failing <dongcarl>Anyone know a recent-enough commit to use that's stable? <joshuaBPMan>hmmm, I can't seem to get gdm to auto-log me in. I also can't seem to get xorg to use the dvorak layout. <rekado>joshuaBPMan: gdm auto-login appears to be broken. I have the same problem on my workstation. <dongcarl>Hey all, can someone explain to me the difference between cores and jobs when I build guix packages or environments? <abcdw>getting "no code for module (ice-9 readline)", when trying to reuire module from guix repl or just guile. Tryed guix package -i guile-readline, but it doesn't help :( <ebrasca>Htop don't display correctly in GuixSD . *abcdw wanting to fix misspelled require and tried <apteryx>abcdw: make sure that you have $HOME/.guix-profile/share/guile/site/2.2 in your GUILE_LOAD_PATH env var. <apteryx>it should automatically be the case if your distro is the Guix system, otherwise you have to source ~/.guix-profile/etc/profile <apteryx>dongcarl: I'd think # of jobs is how many packages to build in parallel, and cores is # of CPU core to use per job. <abcdw>apteryx, I use GuixSD, but GUILE_LOAD_PATH contains only /run/current-system/profile... <apteryx>it must be explained in the info reference <apteryx>abcdw: have you installed guile as your user? <dongcarl>apteryx: # of jobs = how many guix builder daemons I'm using? <apteryx>abcdw: guile package is responsible for setting up the GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH <dongcarl>apteryx: Okay, so which one gets passed to `make -j` then? <dongcarl>apteryx: And always one package one worker, correct? <apteryx>I would expect so, but I haven't double check in the manual. <abcdw>apteryx, no, installed only guile-readline. Also tried to do guix enviornment guile guile-readline. Same result. <apteryx>actually, maybe more like one derivation per worker, and there are usually one main derivation per package I believe (a derivation is the Guile build script that a package was lowered ("compiled") to) <apteryx>abcdw: weird, try installing guile in your user profile and then start a fresh shell and try <abcdw>apteryx, I tried, it said that "following env vars defs may be needed:" and showed export commands examples, but not updated GUILE_LOAD_PATH, new bash instance also have GUILE_LOAD_PATH equal to system profile <apteryx>abcdw: you might need to relogin for the new variable definitions to take effect <pkill9>sneek: tell dannym I get the issue with `guix gc` failing to complete with "guix gc: error: executing SQLite statement: FOREIGN KEY constraint failed", and I've sent an email to the bug report for it that you replied to, with debug information, but I don't know if I sent it right (plus i didn't reply to your message, I replied to the original one), this is the <sneek>dannym, pkill9 says: I get the issue with `guix gc` failing to complete with "guix gc: error: executing SQLite statement: FOREIGN KEY constraint failed", and I've sent an email to the bug report for it that you replied to, with debug information, but I don't know if I sent it right (plus i didn't reply to your message, I replied to the original one), this is the <tortoise>Hey, is there any package for plan9port out there? <ng0>i have 9base, but that's not the same iirc <ng0>ah, plan9port is bigger <kmicu>ebrasca: could you try a different terminal emulator (and state your current one)? <abcdw>apteryx, After relogin it works, thank you. <pkill9>can you specify local paths for guix channels? <pkill9>ah yes you can, by putting file:// at the beginning <g_bor>I tried to set up a channel, and I can't find out what's wrong with it. <rekado>so! Looks like the GNOME problems were due to outdated state in /var/lib/gdm. <rekado>I don’t know yet what exactly caused this, but I’m thinking that maybe we shouldn’t keep /var/lib/gdm at all. <g_bor>I intend to push all the packages contained there, but I need some time to poilish them. <g_bor>(exception misc-error (value #f) (value "~A ~S") (value ("no code for module" (\ <g_bor>rekado: how do you solve it now? <g_bor>Does the state get regenerated? <rekado>I only had to move it out of the way <rekado>I’ll take this to the mailing list to discuss solutions <rekado>g_bor: what did you do to get this output? <g_bor>rekado: does this gdm problem happen on a running system, or cleaning up on reboot would solve the issue? <g_bor>I belive I might be doing something wrong in the channel... <pkill9>i am liking Claws Mail, so lightweight <g_bor>the output comes from the build log of the failed derivation of the channel, which fails to produce its output. <rekado>g_bor: I suggest cleaning up the gdm user’s home directory as an activation service. <rekado>but my own user account’s ~/.cache directory also needed clearing <rekado>g_bor: the problem with your channel is that the directory tree is wrong. <g_bor>rekado: the gdm cleanup activation service looks workable. <rekado>you have two files there which declare modules like (nominatim packages …), but the files are not under the nominatim/packages/ directory. <rekado>you should create that directory and move the files there. <g_bor>rekado: ok, thanks. Will do that. <g_bor>I could not find a pointer to this info. <rekado>g_bor: this is unrelated to channels. It’s how Guile modules work. <rekado>module names must map to file names at the module root directory. <g_bor>I was simply not aware of that. <g_bor>It's time for me to have a look at guile docs again, I guess... <g_bor>I will send these upstream soon, but I still miss pyosmium, and nominatim can't update without that. <pkill9>for some reason gnome-shell is being built by `guix system build`, yet `guix build -n gnome-shell` reports it would just be downloaded instead of being built <pkill9>oh well, it didn't take long at all, i thought it would <kmicu>That could be a wrapper or drv file. <pkill9>it seems to build gnome-shell itself <pkill9>it unpacks the gnome-shell source, compiles it etc <kmicu>pkill9: is hash the same for it as reported by guix build -n? <pkill9>i can't check, i'm pretty sure it isn't though, because `guix build -n` still says it will download it <pkill9>after i've built the system derivation <pkill9>can inferiors pull the latest git commit? (instead of specifying a git commit) <rekado>“anonymous user is not allowed here” 