<nckx>I hadn't heard of AppStream until now but don't see the synergy between it & Guix. <nckx>‘AppStream 2.0 simplifies application delivery by securely running your desktop applications in the cloud and delivering the same version of each application to your users.’ <pkill9>actually there is already metainfo files created by guix packages <nckx>DOAP 2.0, but with a shit name? Galaxy brain stuff. <pkill9>looking at ~/.guix-profile/share/metainfo <nckx>Description Of A Project <nckx>back when RDF was all the rage. <nckx>This looks verrry similar. <nckx>(Thanks for the link, by the way.) <nckx>So this could be used to interface Guix & graphical software browsers, right? <nckx>It seems to be aimed at upstreams, might make more sense to consume it than to generate it (would that be... impolite?). Dunno of course, I've read all of 4 paragraphs about it : <nckx>pkill9: Is there a standard place to put these *it the source tree*? <nckx>Or how would it be distributed through the GDS? <nckx><each appstream file can be associated with each revision of guix> What would that allow? Installing any Guix revision from a GUI software shoppe? <pkill9>nah, i was just obsessing over details <pkill9>although technically i guess you could yea <pkill9>but i was just thinking it would be reliable, you wouldn't just have one file for the latest guix, you couldn't have one for each revision, but it's just a boring detail i was thinking of <pkill9>also i dunno if all applications with desktop files generate an appstream file <nckx>Ah, I didn't mean to be pedantic, those were genuine but confused questions since I'm extremely out of my depth with this GUI stuff. I've never used the kind of thing at which this file is obviously aimed. <pkill9>this is why i just want to be able to get all the desktop files, although i suppose you could fill in missing appstream files with metadata from the .desktop files <nckx>It doesn't seem that common; I have 25 unique ones on my system. But I don't use GNOME of course. <nckx>I assume that's where they're all hidin'. <Sleep_Walker>is there a way, how to specify user's initial set of packages via system config? so when I init new system via `guix system init`, the packages are in /gnu/store ready, user can have them installed without any network requirements and it's not linked to system profile? <leoprikler>you can specify global packages, but for everything else I'd run guix pull in the booted system <leoprikler>Guix will automatically reuse packages, that have already been built <vagrantc>you could define a package that installs nothing itself, but has inputs for other packages and include that in the system profile ... <vagrantc>then all the packages you want would be readily available in the store without polluting the global install... <vagrantc>something like that, if not that exactly <nckx>Sleep_Walker: Check out gc-root-service-type. It's used by (gnu system install) to reduce downloads during installation. <tricon>Just wish to continue to extol my adoration for Guix. Ya'll are doing a great job. ***catonano_ is now known as catonano
***terpri_ is now known as terpri
<lfam>sneek: later ask vagrantc: I noticed in gnu/packages/linux.scm the comment saying that the Pinebook Pro patched can be removed for linux-libre 5.7. Is that still accurate? <joshuaBPMan>hey guix, I just installed artanis... guile; ,use (artanis artanis) gives me an error, no code for artanis... <str1ngs>joshuaBPMan: is guile in your profile? <str1ngs>you might need restart your terminal. to update search paths. <joshuaBPMan>also I get a nice waring about trying to use guile@2.2.7 <joshuaBPMan>I get a big message about /run/current/system.../lib/guile3.0 blah blah incompatible bytecode. <str1ngs>joshuaBPMan: what does this output. printf "%s: %s\n" $(which guile) $(guile -c "(display (version))") <sneek>raghavgururajan, you have 1 message! <nckx>raghavgururajan: It didn't occur to me immediately but it came back to me later: I've seen this before; Meson automagically invokes pkexec for you if you're not careful. <sneek>nckx, raghavgururajan says: So any clue regarding that "pkexec" error? <nckx>See no-polkit-magic in fprintd for how I ‘fixed’ it there. <nckx>Perhaps it would work here too. <nckx>raghavgururajan: If that works, please keep the comment so future greppings of ‘pkexec’ find it 😉 *nckx + too hot for coffee → 😴 <str1ngs>why did they bother with meson? who doesn't like autotools! <nckx>¯\_(ツ)_/¯ I am the wrong person to ask; I don't throw away my power tools to buy shiny plastic ones. <str1ngs>I think I'm the only one who likes autotools :( <lfam>Distro maintainers like autotools <nckx>str1ngs: Wot? I flippin' love autotools. <nckx>Probably because I don't maintain projects, but use and package them. <str1ngs>like autotools has CONFIG_SITE. you can easily care a hierarchy of autotools project that build and installs all the projects. <str1ngs>I think meson can do nested projects too. only thing I can think that meson has is windows support. *str1ngs slow claps for windows support <nckx>Now you've done it. Here comes everyone to say they like traff^Wautotools. <nckx>Odd, I thought I was remarkably lucid. <nckx>raghavgururajan: The gist is: ‘See no-polkit-magic in fprintd for how I ‘fixed’ it there.’ <raghavgururajan>I never experienced this before. Is there a way to prevent meson from doing that? <nckx>And by ‘see’ I mean ‘copy/paste/enjoy’. <bavier[m]1>indeed, autotools projects are far easier to work with as a maintainer for several systems <nckx>raghavgururajan: Yes, using that phase. <raghavgururajan>nckx: Btw, never mind about the Mutter issue I mentioned. I fixed it. <nckx>Great, because my bouncer had a heat stroke & I never saw that bit 🙂 *raghavgururajan made some "GagnamStyle" moves after fixing Mutter tests xD *nckx just killed a mosquito on their keyboard and is feeling pretty bad-ass too. <str1ngs>I once say a friend vacuum his keyboard...... there was a swath of missing keys after 😬 <nckx>That is why we use the brush extension. *raghavgururajan names the phase 'no-meson-shenanigan <nckx>...a single shenanigan sounds so much more devious than the plural... <nckx>str1ngs: That's just begging karma for a test failure. <str1ngs>renames his check phase to 'fail-successfully-phase <nckx>In seriousness, it might make sense to move this into the meson-build-system if it becomes common. I hope not though. <str1ngs>is there a reason it want's to use pkexec? is that for a make install like target or something? <str1ngs>I don't see a good reason of privilege escalation in a build system. <raghavgururajan>> I don't see a good reason of privilege escalation in a build system. <nckx>When I said ‘this is as brilliant an idea as calling sudo in a Makefile’ I was joking, Meson. <nckx>str1ngs: Yes, it auto-ops itself when it encounters a permission error (see mesonbuild/minstall.py). <nckx>It reduces friction and improves the UX. <str1ngs>why not just let the system throw an error. and let the user run pkexec make install. just <nckx>It's no secret that Linux lags far behind Windows when it comes to easily installing & modifying system files. <nckx>This is a step in the right direction! <str1ngs>I know right, for some reason my Linux never needs restarting after an update. something must be wrong! <brendyyn>str1ngs: i heard it has something to do with how the filesystem works differently between unix and windows. on unix when you update a file, programs reading it at the time still refer to the old version. where as windows locks files so you gotta stop and restart with the new file <brendyyn>str1ngs: many things do also break after updating on GNU/Linux anyway so i think its not quite right to tell users they can just update and keep going. i actually think it may be desirable to add a may-require-restart property to packages known to break on update to notify the user when they are updated <str1ngs>brendyyn: I don't find things break on upgrades at all. <raghavgururajan>nckx: I have a doubt. If a package declares a env-var, will that env-var be available right after install phase inside build-env? For example, let assume package foo supposedly establish/set an env-var called FOO_PATH. (like how elogind sets XDG_RUNTIME_DIR). Now, if I wrapping execulatbles of package foo, via (getenv FOO_PATH), right after install phase, will getenv receives any value? *raghavgururajan needs beans <str1ngs>raghavgururajan I need a good bean recipe! *raghavgururajan also stares at nckx ***apteryx_ is now known as apteryx
<fnstudio>Hi, any idea on how to set xdg entries, eg to set a default app to open PDFs? <fnstudio>i tried `xdg-mime default xpdf.desktop application/pdf` but that doesn't seem to make my guix happy <fnstudio>context: guix on foreign distro here; the PDF app, as well as xdg-utils were installed via guix though <fnstudio>oh cool, setting this env var `XDG_UTILS_DEBUG_LEVEL=100` makes xdg-mime more talkative <fnstudio>xdg-open does actually add an entry to `~/.config/mimeapps.list`; however, xdg-open seems to be ignoring it <fnstudio>sorry, by the way, this might be a bit OT... it may very well just be me not understanding xdg-utils <fnstudio>anyway, since we're here and for the record, let me add that this is very useful for debugging: `XDG_UTILS_DEBUG_LEVEL=100 xdg-mime query default application/pdf` is very useful <wigust>fnstudio: The config is ~/.local/share/applications/mimeapps.list and update-desktop-database ~/.local/share/applications to apply changes after config editing. <wigust>application/pdf=zathura.desktop; <fnstudio>wigust: that's very helpful, thanks, and i think it's exactly the problem with my setup <fnstudio>wigust: any idea on why my `xdg-mime default ...` edits `~/.config/mimeapps.list` instead? <wigust>fnstudio: probably because this file should be for MIME configuration by conventions ;-) I didn't find a documentation when I wrote my config and didn't strace update-desktop-database :-) <fnstudio>wigust: i see, makes sense, thanks a lot for your help <brendyyn>str1ngs: I don't know about guix but I've found KDE does get a bit funky. <aadcg>I'm trying to install a package with rpm on guix with sudo rpm -i file.rpm and I get -> error: cannot open Packages database in /gnu/store/5ci625m65m8jpv8xiq2wna3s1rmj94x2-rpm-4.14.2.1/var/lib/rpm. Any ideas? <nckx>raghavgururajan, str1ngs: ...what the hell 😳 <alextee[m]>does guix have some type of mechanism to check GPG signatures yet after pulling packages? <alextee[m]>arrr was gonna repackage zrythm but it needs meson 0.55 <nckx>raghavgururajan: So I don't understand your question about variables. I thought you meant [native-]search-paths, but elogind doesn't declare one. What does ‘establish/set an env-var’ mean, *exactly*? <nckx>raghavgururajan, str1ngs: The only bean of which I approve is the fruit of the C. arabica. <nckx><raghavgururajan> ‘I'm trying to install a package with rpm on guix’ -- just... why. <nckx>alextee[m]: core-updates. <nckx>aadcg: So... that's not going to work. rpm is packaged in Guix to allow inspecting/unpacking/&c. .rpm files, but it is not remotely set up to install packages, and Guix System is not remotely set up to accept them (they would assume tonnes of things about the system, like FHS, that just aren't there). <nckx>alextee[m]: For massive rebuilds. staging is for changes that cause between 300 and 1200 rebuilds. <nckx>Search the manual for core-updates. <alextee[m]>so is it ok to send a multi-patch for meson, reproc, libcyaml + zrythm for core-updates? <nckx>I don't know if core-updates is frozen yet, but it's always OK to send them 🙂 Just add [core-updates] to the subject. <nckx>alextee[m]: Does the meson-build-system not accept a #:meson or similar argument where you could specify a newer meson? Then you could create a meson-0.55 package on master, use it only for zrythm without causing rebuilds. <nckx>Of course a global meson update on c-u would still be very welcome. <alextee[m]>it's really just patching the version number and the hash <alextee[m]>0davfjikrg42q99lqny5fnvyjygvj0rgjdrmb53sq55fwazy46ha <alextee[m]>i've been using this for a while now in my own channel <nckx>Hm? Yes, I can push a meson bump to core-updates. ‘Real quick’ -- no, because I'd want to run some tests. Meson on master would still be 0.53 until the next c-u merge (~ a month or so). <nckx>You can't bypass c-u through me if that's what you mean 😛 <nckx>Oh boy, 3 dovecot CVEs. Up we date. ***terpri_ is now known as terpri
***sneek_ is now known as sneek
<str1ngs>nckx: I' more of a Lavazza espresso crema kinda guy. *str1ngs sips his americano. <str1ngs>brendyyn even if there are instabilities most things are fixable without a restart. <joshuaBPMan>does anyone know of a guix package for wordpress? I know that Wordpress can't be included properly in guix, because the javascript can't be built properly.... <nckx>alextee[m]: Did you actually test anything that *uses* Meson, not just Meson itself? I think that would explain it. <nckx>That patch is applied to the meson-for-build variant, which is hidden but used for all meson-build-system packages, and is pretty important. <nckx>(I just posted the same note to the bug, for the record.) <nckx>alextee[m]: I know you're more into Python than I am, so I hope you give it a shot 😉 <nckx>I don't really... wanna. <rekado_>the upgrade to python 3.8 broke our old version of conda, so i’m now trying to upgrade it… again. <rekado_>tries to write to other packages’ prefix directories and cannot be taught not to. <gnutec>Yes! Now we are with linux 5.7.x o/ <leoprikler>I think this is a general flaw^H^H^H^H feature in the assumptions, that language package managers make. <str1ngs>scheme as in URI scheme. so you can do something like this. nomad:/about/version <str1ngs>this is sill WIP so take it with a grain of salt. <str1ngs>pkill9 view is just a Nomad term for presenting a webpage transparently. it's essentially just sxml to html strings. here are other moving parts that you don't see in (nomad views) mainly some webkit magic. though it's generic enough I hope <pkill9>i wonder if there's any fun stuff you could do if you integrated haunt static site builder with nomad somehow <str1ngs>also with restfull views I can do something like this. nomad:/describe/function/nomad-version so that when you click link it opens a text help buffer. describing that function. <str1ngs>it's a nice way to interlink different buffer modes. <str1ngs>pkill9 that's primarily why I did this. I want to have one point source code for the Nomad website. but internally as a modules then also as the static website. <str1ngs>also with custom scheme support I can do something like gnutls://fs/<hash> ipfs://ipfs/<cid> . where gnunet and ipfs are first order protocol.s <joshuaBP`>hey, I read online that RMS is not a big fan of web technologies to build applications...I guess he perfers toolkits...like gtk+. anyone know why? <joshuaBP`>str1ngs: I actually just uploaded a video of me web hacking in guile last night <str1ngs>probably because of things like javascript and cookies <str1ngs>though technically he probably prefers text buffers ala Emacs. which is not strictly GTK <aadcg>nckx: it's smth related to my government and I'm given is a .deb file or a .rpm. I was wondering how to make it run on Guix... <str1ngs>joshuaBP` also nomad is in guix :). though its still pretty early days. <joshuaBP`>str1ngs: it's still pretty freaking awesome! <butterypancake>wigust: Patch #42674 had its prerequisite patch applied if you'd like to review it again. No pressure, just thought I'd let you know <butterypancake>also I have a searx package patch I'd like to send in but I want to wait for patch #42808 first, so if anyone has some spare time, reviewing that one would make me really happy :D <apteryx>how are debugging symbols found when using 'guix environment' with debug outputs? <apteryx>ah, I'm using gdb from emacs which probably doesn't know about my environment profile <butterypancake>well the debbuging symbols are pulled from the binary right? So you do `gdb -i=mi binary' and you get the symbols right? <apteryx>but I also want the debug symbols of some library, namely qtserialbus (I've added a debug output for it) <butterypancake>oh, a dynamic library? That's out of my comfort zone as an embedded developer :P if you want to make it easy you can compile against the library statically so the symbols are in your binary <apteryx>I think it's manual, the .bashrc Guix skeleton has this: set debug-file-directory ~/.guix-profile/lib/debug <apteryx>which suggests there's no environment variable magic to make this automatic per-profile. <butterypancake>which profile is currently active is determined by symlinks right? That kinda sucks if you want to run two seperate profiles in two seperate terminals at once under the same user... <butterypancake>wait, maybe that's not right... idk, profiles really confuse me tbh <apteryx>To set a profile active all that is needed is exporting the GUIX_PROFILE environment variable then sourcing the profile's 'etc/profile' file. <apteryx>or running eval "$(guix package --search-paths /path/to/profile)", if you want it to be pure. <apteryx>there's a blog post about using profiles, it may help <butterypancake>oh ok. But in this case there is just some user global gdbinit when really that gdbinit really should be per profile? is the .guix-profile/lib/debug populated by guix? So you want `guix environment blah' to add additional debug paths? <apteryx>butterypancake: yeah, it'd be nice if there was a mechanism to automatically take care of that, but I don't know one (yet). <butterypancake>I remeber having a .gdbinit but I removed it when I was cleaning my home folder a while ago and apparently those don't regenerate :P <apteryx>nope, they're put there at the original installation time, and then left untouched. <apteryx>it'd be risky to mess with those at any later time. *apteryx investigates why guix-set-emacs-environment stopped working <apteryx>uh, (guix-geiser-eval "(search-paths-specifications \"/gnu/store/iwzzf1pwfv4gsxj1cglz8l797xlyc0z5-profile/etc/profile\")" (guix-get-repl-buffer 'internal)) -> ("()"). <butterypancake>so looking into gdb itself, the only way to modify the debug folder locations through environment variables (which would obviously be ideal for guix profiles) is to add those folder to your PATH variable. This means we probably should handle debug symbol files in the exact same way we handle the profiles bin folder and then just add that debug folder to the path <apteryx>or, to reproduce which your ~/.guix-profile: (guix-geiser-eval (format "(search-paths-specifications \"%s\")" (expand-file-name "~/.guix-profile/etc/profile")) (guix-get-repl-buffer 'internal)) <butterypancake>idk what your doing, but running that code blindly I got: ("()") <apteryx>eh, so the 'guix-set-emacs-environment' procedure from 'emacs-guix' appears broken for everyone ;-) <apteryx>that procedure is useful to lead the environment variables of a profile (say, $GUIX_ENVIRONMENT) into your current Emacs instance. <butterypancake>emacs-guix has never had all of it's features working for me in the 3 months I've used it. I never seems to know how to install or remove stuff. Is this realated? <apteryx>otherwise Emacs wouldn't know about the tools specific to that profile unless you'd launch Emacs from a session where that profile is active. <apteryx>to install stuff, I use 'guix-all-packages', to get the global view. Then find something, and press 'i' for install, then 'x' for execute, IIRC. <apteryx>removing a profile would be similar, except using 'k' for kill I believe. <butterypancake>No variable named gzip in #<interface (gnu packages compression) 7ff165c95960> <butterypancake>Ok, usually it's not broken like this but ya. Something always goes wrong :P <butterypancake>now opensll is unbound? it's actually more broken than usual. I think I'll stick to the cli becase that works :P <butterypancake>apteryx: I'm currently on a foreign distro so probably don't mind me. I still have problems on GuixSD but they usually don't look like that <butterypancake>usually they're something like: we don't like that guile key you sent me, but we don't like it like 3 layers down so you can't just remove the key from the repl command and have it work. I should probably debug it but I never bothered to learn guile so it'd be hard. I'll learn guile eventually <PotentialUser-79>My ext4 filesystem always gets corrupted (2-3 times/month), requiring me to use the installer image to run fsck to repair it. It never happened before on other distributions. <butterypancake>You run the latest Guix? You did a `guix pull' and `sudo guix system reconfigure' after installing? <nly>how to open the russian manual for guix? <sneek>Welcome back vagrantc, you have 1 message! <sneek>vagrantc, lfam says: I noticed in gnu/packages/linux.scm the comment saying that the Pinebook Pro patched can be removed for linux-libre 5.7. Is that still accurate? <PotentialUser-79>It replaces the proprietary BIOS and uses GRUB to load GNU+Linux (it's a libre distro of coreboot). <nckx>butterypancake: It's Libreboot. It's most often used with a GRUB payload which reads your operating system's grub.cfg directly, but it also has a ‘BIOS’ payload. Coreboot (on which it's based) also had a UEFI implementation but not sure if Libreboot does. <vagrantc>sneek: later tell lfam yes, the pinebook pro patch just pulled in the device-tree, if i remember correctly, which is now in upstream as of 5.7.x <butterypancake>PotentialUser-79: in your system config.scm is it grub-efi-bootloader or grub-bootloader? <PotentialUser-79>My friend uninstalled Guix last year because he was having the same problem (on a 2018 apple computer). <nckx>No, neither; it hands off to one. <vagrantc>sneek: later tell lfam full support for pinebook pro requires more patches ... working on it in wip-pinebook-pro branch <butterypancake>PotentialUser-79: have you checked your hardware? It could be a flakey sata controller or harddrive. I think there are some harddrive diagnostic tools you could run just to make sure <butterypancake>Also, just to make sure, are you currently using any of the hardware your friend had in that 2018 apple? <nly>this spellling is wrong "уитилита" <vagrantc>a while back i had issues with guix not doing a proper shutdown with ... ctrl-alt-delete and/or just hitting the power button <butterypancake>I was just about to ask how you turned off your computer. Because now it sounds like the problem occurs based on the way you use it. Some distros handle hard shutdowns better than others. <butterypancake>Shuttind down while the OS is using the hard drive is usually not a good thing to do <PotentialUser-79>It happens when I run a guix command like guix pull, I get a "Bad message" error and when I restart my computer it fails to boot and tells me to run fsck manually. <butterypancake>Ya, I had a computer die like two days ago from restarting after a bad message. It did it consistantly too even after a reinstall. However my 3 other machines are just fine so I though it was a hardware issue. Maybe it was a config issue. Can you post a link to your config.scm? <PotentialUser-79>I'm using ext4, not btrfs, but the bootloader, file-systems and mapped-devices config is the same. <PotentialUser-79>I'm only generating a grub config file that the libreboot GRUB payload can load. <butterypancake>but for EFI you have to make a fat32 parition first. Did you try that and still get the same result? <nckx>butterypancake: They are using GRUB, not BIOS or UEFI. <nckx>Guix's GRUB is never used. <vagrantc>it's not using either bios or efi ... it's just using grub-bootloader to generate the configuration file that libreboot's grub loads <bdju>getting a libfive build failure <nckx>(libfive/test/heightmap.cpp:261:5: error: ‘BENCHMARK’ was not declared in this scope) ☝ ***bkv is now known as bqv
<butterypancake>oh ok, I guess I never understood the difference. So what I was calling booting with BIOS is actually where the machine just starts executing code right away (in this case GRUB code) where as efi does some fancy stuff first so it needs it's own fancy partition <vagrantc>the matrix bridge some people use to connect to irc fell down? <butterypancake>I like how the libreboot instructions say to ignore all the warnings on boot and just keep hitting enter to make them go away. Maybe someone should look at that :P <vagrantc>a bit disconcerting to embed so much guix-specific information in libreboot documentation ... likely to get out of sync <butterypancake>but almost none of it looks different from the guix documentation. I fail to see where the diffrences are... <butterypancake>they do a crazy cryptsetup command but I don't think that libreboot specific <nckx>I wonder which warnings they mean. <butterypancake>rereading it, it actually say the warnings "may" appear, so maybe it's not that bad ***guix-vits is now known as the-y-is-wrong
<nckx>97% generic Guix instructions that have nothing to do with Libreboot and probably shouldn't be there, 3% not clear enough 😛 <butterypancake>someone should tell them just to take it down. It's not adding any value. I guess we could add "works with libreboot" at the top of our manual because that's all that page really seems to mean *nckx nods, cheers someone on. <butterypancake>I mean in '3.3 USB Stick and DVD Installation' we do tell you how to boot in libreboot so I guess we already imply "works with libreboot" <nckx>guix-vits: y is it wrong? <nckx>‘Any users, for their generalised use cases, need not stumble away from this guide to accomplish the setup. Advanced users, for deviant use cases, will have to explore outside this guide for customisation’ <nckx>Surely you're not a stumbling deviant who prefers the official docs. <vagrantc>the author appears to be an active outreachy contributor to guix <butterypancake>I posted respectfully in the libreboot IRC so they can deal with it as they see fit <butterypancake>nckx: I apologize for messing up the patch thread for the openrc stuff. I've been experimenting with git send-email's --in-reply-to and chainReplyTo. I think I understand it now, but the threads for that report are not right :P emails are hard <butterypancake>I assumed that when you send a patch series --in-reply-to something, that the entire series would be in-reply-to that. Silly me. How could I not see that the obvious outcome of that would be send the first email in-reply-to that and the second email to have no in-reply-to field. How could I be so naive <nckx>butterypancake: Yes they are. Only people who can't be bothered to *try* to get things right need apologise; not you. <nckx>That's not right that is. <nckx>I thought chainReplyTo would result in: <patch 1, In-Reply-To (say) the bug number> <patch 2, In-Reply-To patch 1> <p 3, I-R-T p 2> <...> etc. <nckx>Giving something of a triangle vibe in MUAs. Instead of all patches being In-Reply-To the bug number, which is what you want. <butterypancake>wait, the documentation agrees with you. So I do want chain-reply-to set to no, not yes. But then why did my 2/2 not get sent to the right thread? <butterypancake>after reading the doumentation, I've come to the conclusion that there is no possible way I did what I did because subsequent emails always have an in-reply-to thing. There is no way to turn that off <butterypancake>I'm going to assume I accidentally deleted something during annotation and that next time it'll hopefully work <nckx>git wouldn't come up with <20200812033842.99352-1-Morgan.J.Smith@outlook.com> on its own, so where did that come from? <apteryx>lost TLS support from docker... wonder what this is caused by? system upgrade? <butterypancake>the weird date thing is apparently the X-Microsoft-Original-Message-ID <nckx>I sent myself 5 patches (without chainReplyTo set) and 2-5 are all in-reply-to 1. 1 is in-reply-to a bogus message ID I gave on the command line. That's what I consider ‘normal’ (2-5 are indented under 1, sure, it's not aEsthEtic, but it doesn't break any threads). <butterypancake>the in-reply-to of the second email matches the X-Microsoft-Original-Message-ID of the first. I think that means I did everything right and then microsoft decided to mess with my message-id just to mess with me <nckx>I guess mu4e was clever enough to figure out what was meant. <nckx>I think it's pretty hard to break threads as long as you use --to=<the bug>. <butterypancake>I'm very tempted to "solve" this by self hosting an email server :P would probably be a better use of my time <nckx>It's certainly more fun. <butterypancake>oh sick! I could have added -v2 so they'd show up as [PATCH v2]. That's a good backup if the threads fail. <nckx>After all this I haven't actually read the content of you mails. I should do that. <butterypancake>I mean that'd be cool because once that happens I can put Guix on my Pinephone, but also I should really be doing actual work instead of doing that anyways :P <vagrantc>yeah, when are they going to release a guix community edition pinephone! <butterypancake>well, I'm going to try out Guix ontop of sxmo on pinephone. If that works, I might try to get actual GuixSD working on it. Are most of the packages working on aarch64? That's really going to be my deciding factor <vagrantc>i've got it working enough that i've run a pinebook and pinebook-pro with guix system <vagrantc>web browsers tend to be a bit hard to come by ... netsurf is the only one i seem to be able to reliably build <nckx>I think so. All of the ‘base OS’ at least (our aarch64 build nodes run Guix System) and I often compile random GUI things for aarch64 just as a smoke test. Most. <nckx>Oh, right, browsers, good point. <nckx>s/Most./Most build just fine./ <vagrantc>and netsurf is really fast because it's missing support for a lot of annoying things <butterypancake>sounds alright then. maybe learning uboot is the next thing on my agenda then. I'm not exactly sure what I'll need to do to port it, but I'll start with getting Guix on Alpine Linux to work and go from there <vagrantc>butterypancake: feel free to ping me ... i've worked with u-boot on a wide variety of systems <butterypancake>Will do! I'm hoping I can just copy paste stuff from other pinephone OS's but we'll see <vagrantc>specifically, u-boot on pinebook and pine64+ ... which should be really similar to the pinephone <vagrantc>i've got my eye on the pinephone ... though i have too many random systems and i really must cut myself off at some point :) <nckx>Yeah but the right answer is always ‘...after the next one’. <apteryx>where I've inserted some newline to hint at where it's spent a lot of time <apteryx>I'm wondering if this can be nscd related <jsoo>hi guix. is simplehttpserver installed with python3.8? <apteryx>any new domain I resolve takes a few seconds (about 8 seconds). <apteryx>could be just my network too, of course... <nckx>apteryx: Am I reading correctly that nscd doesn't even respond? <nckx>apteryx: Does stopping it improve things? <nckx>jsoo: Wouldn't that be http.server then? <jsoo>nckx: oh! probably. yep. perfect, thanks! <apteryx>nckx: oh, I just noticed my machine is connected via IPv6 <apteryx>that's probably what is not working very well with my provider's DNS <apteryx>ok, so totally disabling IPv6 didn't help. <apteryx>stopping nscd also didn't help. These addresses in the log got me thinking: 192.168.55.1 and 192.168.50.37; they don't exist in my network, these are configured through a VPN connection that I keep. It seems NetworkManager didn't bother cleaning up /etc/resolv.conf when the connection was closed/died. <apteryx>OK, nmcli con up vpn, then nmcli con down vpn does take care of cleaning up the /etc/resolv.conf file. Not sure what happened, but my DNS latency problem is happily resolved. ***OsamaChibani[m] is now known as Chibani[m]
<apteryx>nckx: it also fixed my dockerd connection problem (that I mistakenly thougth was related to TLS certs) <apteryx>more like a gnu I guess, but thanks ;-) 
