IRC channel logs


back to list of logs

<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
<wednesday> says I need hydroxide to do that with that email, but that's not packaged heh, was looking into new email providers
<nckx>wednesday: I had to jump through some tedious hoops to apply your startx patch so it would be great ( if you could get git send-email to work.
<nckx>wednesday: So you sure you want ‘frozenpigs <purpjuice@...>’ as committer or...?
<wednesday>That was the only account I had handy heh
<nckx>I can still change it if you like.
<nckx>E.g. to the one used in your copyright line.
<wednesday>Well I just made myself a savannah account
<wednesday>Yea use that email, and this name if possible heh, thats also what I registered my savannah with
<nckx>‘This name’ == J... G...?
<nckx>Can do.
<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>Here's the Web version:
<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
<wednesday>this is what I need for sendmail when I tried packaging it I had it complain about some go related thing, can't entirely remember, I'll give it another go tomorrow or something
<nckx>Unfortunately the relevance of that general document to Guix is limited IMO. Not everything is explained and we don't ever do things like .
<nckx>wednesday: Um... So this protonmail thing doesn't speak plain old (encrypted) SMTP? :-/
<wednesday>Apparently not
<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>Oh, that one 😃
<wednesday>different ones for different tasks
<nckx>Not sure if ‘swears’ is quite it. I'd personally be OK with someone contributing with an 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 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 ☺
<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
<dongcarl>maybe I need to pull latest
<nckx>dongcarl: Hmm, maybe, or maybe you're just hitting an untested combination.
<nckx>dongcarl: Which error would that be, exactly?
<dongcarl>my s-expr
<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
<dongcarl>Maybe even get musl in there...
<nckx>That would be cool.
*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>wednesday: In what way?
<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.
<nckx>Oh wait
<nckx>I'm the confused one.
<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?
<wednesday>error is the comment at the top, my config may be a bit weird
<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)).
<wednesday>The one that give me the error is line 65
<nckx>wednesday: No, ‘wed/system/pc.scm:208:63’ means line 208, column 65.
<wednesday>oh wait yea
<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>(Sorry, not a fan.)
<nckx>Hydra refuses to serve me 🤷
<nckx>Are three people trying to use it at once now.
<nckx>Stop it both of you.
*nckx gives up.
<wednesday>I'm just rebuilding my repo
<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>It's been literal years since I've used Hydra but I guess this <> is the relevant error?
<apteryx>UTC, yeah that's what I meant.
<nckx>apteryx: I think I'll hack that up unless you want to.
<apteryx>nckx: oh please, go ahead :-)
<nckx>Hafta do something while watching $SPORTS_TEAM lose. 😒
<apteryx>my hands are pretty fulla lready
<wednesday>I'll be off for tonight, thanks for the help and such nckx
<apteryx>nckx: eh
<nckx>wednesday: o/
<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 no longer part of the default substitute-urls? I'm getting "system reconfigure --dry-run" build significantly less when I explicitly include
<apteryx>get started only after crucial initial services have been started
<nckx>apteryx: I think it's just a ‘signal’ virtual thing.
<nckx>Oh. Nvm. Lag.
<vagrantc>sturm: i think it's only now
<vagrantc>which seems to really be lagging on armhf
<apteryx>nckx: :-)
<sturm>thanks vagrantc
<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’.
<apteryx>I thought there was a bug fixed about it:
<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 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>hello guix!
<g_bor>I am willing to set up a channel for the first time, and running into a problem.
<civodul>Hello Guix!
<Blackbeard[m]>civodul: hi ٩(◕‿◕。)۶
<Blackbeard[m]>civodul: could you please guide me on how should i try to fix this
<Blackbeard[m]>Provide --only-substitutes flag to "guix package --upgrade"
<civodul>i'd recommend starting by looking at the API in (guix store) that allows you to determine whether substitutes are available
<Blackbeard[m]>civodul: ok
<roptat>hi guix!
<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)
<abcdw>your* 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 :-)
<civodul>it may be easier than you think
<abcdw>meiyopeng, thank you. You probably forgot to commit packages/linux-***free.scm :)
<meiyopeng>abcdw, linux-nonfree is in
***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
*nckx feels ya.
<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
<wednesday>nckx: Some python packages (like mypy) have the license as like "MIT License", so would it be better to add that to the pypi importer, or change str in to lowercase and all the comparisons?
<nckx>wednesday: We don't have an ‘MIT licence’ because that name covers multiple (subtly) distinct licences.
<nckx>Namely X11 and ‘Expat’.
<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 from what I know, or stuff from requirements.txt
<nckx>If so, a patch to lower-case them would indeed be useful.
<ebrasca>When I try to use "guix pull" I get :
<ebrasca>I am using GuixSD
<nckx>I just assumed they had some kind of enum system for licences but never looked.
<nckx>Ah, the name that will never die.
<ebrasca>I have alredy reported it by email.
<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>ebrasca: Try again?
*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.
<wednesday>nckx: here is a bunch of weird python license stings I've found maybe it'd be best to use regex or somethin
<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>sure it is
<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>(E.g. Arch doesn’t mention any keyboard issues )
<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.
<kmicu>nckx: Qwant showed me
<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
*nckx bought a Thinkpad.
<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 -> AFThinkPadK
<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 ;-)
<dongcarl>the touchies?
<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.
<joshuaBPMan>rekado: ahh. Ok. Thanks.
<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>in your bash_profile or the like
<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>how many guix bulider workers, yes
<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?
<apteryx>definitively cores
<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
<pkill9>sneek: botsnack
<dongcarl>atw: Thanks!
<dongcarl>apteryx: Thanks!
<bavier`>hi guix
<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
<pkill9> email:
<pkill9>sneek: later tell dannym I get the issue with `guix gc` failing to complete, and I've sent an email with debug information to the bug report for it that you replied to, but I don't know if I sent it right, this is the email:
<sneek>Got it.
<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>hello guix!
<g_bor>I need a bit of help.
<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>(repl-version 0 0)
<g_bor>(exception misc-error (value #f) (value "~A ~S") (value ("no code for module" (\
<g_bor>libosmium))) (value #f))
<g_bor>this is the log
<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: I did a guix pull, with a channels.scm pointing to the channel, which is available here:
<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>this seems to work fine.
<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.
<g_bor>thanks, it works now.
<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
<kmicu>Thank you pkill9
<pkill9>can inferiors pull the latest git commit? (instead of specifying a git commit)
<jonsger>I think there is something broken in the po/packages/Makefile will investigate tomorrow...
<rekado>“anonymous user is not allowed here”