<marusich>I'm sure there must be an example of how to use it to remove packages from a package list hiding somewhere. Let me see if I can point you to one... <ScaredySquirrel>guix tells me problem on line 62, Wrong number of arguments to procedure remove <leoprikler>that's because you're missing a bracket before %desktop-services <atw>as leoprikler said, you have (remove (lambda (service) (eq? (service-kind service) (gdm-service-type)) %desktop-services)) and you want (remove (lambda (service) (eq? (service-kind service) (gdm-service-type))) %desktop-services) <atw>fair enough, perhaps your editor could give you a hand <ScaredySquirrel>I hit the show matching brackets key M-] and it shows me but it won't tell me why it doesn't match in the end <leoprikler>as far as your packages are concerned, you will only need openbox (maybe), nss-certs, xorg-server due to your setup and perhaps xinit <marusich>ScaredySquirrel, the invocation of "remove" is incorrect on line 62. You are passing only 1 argument, the procedure you create, but it requires 2. You need to add a second argument which is the list from which you want to remove services. <marusich>Here is an example of how to invoke remove, using packages: <leoprikler>also refer to the packages themselves instead of using the map, e.g. (packages (cons* openbox %base-packages)) <atw>I gave the fish, marusich teaches fishing :) <atw>leoprikler: I think the specification->package+output may originally be from a config.scm that was generated by the graphical installer <leoprikler>For bracket matching, Emacs is probably the best tool (don't forget about electric-pair-mode) <leoprikler>I think it would be better to pull in the appropriate modules and use cons* <atw>leoprikler: not sure, but that's my assumption having seen earlier versions of ScaredySquirrel's conifg. re editors: while installing a system, nano and zile may be most convenient as they're already available <leoprikler>IIRC the default config writer uses (append (list ...) %base-packages) though <leoprikler>ScaredySquirrel was given the hint about this function existing in IRC. <leoprikler>ScaredySquirrel: still missing a bracket: (eq? (service-kind service) (gdm-service-type)) ) <- this one <ScaredySquirrel>I added it one where you just said and on line 47 there's an invalid field specifier <leoprikler>that's because you're brackets are messed up there too <leoprikler>(also don't install all those at system level – this is not Gentoo) <marusich>Not sure what automated mechanisms exist... If I find myself in that situation, I try to walk through the bracket groups to find the problem. Does Emacs highlight matching brackets for you? that makes it easier. <leoprikler>you don't really tell it how to find errors, since Emacs does not know the meaning of your program <leoprikler>however, as marusich points out, it can highlight matching braces for you <leoprikler>I personally prefer electric-pair-mode as already pointed out, but I'm sure there's something more visual out there if you look hard enough. <marusich>ScaredySquirrel, once you fix your brackets, I can offer one more piece of minor feedback. In http://dpaste.com/3N6SGNG on lines 48-50, you construct the list of additional packages by mapping specification->package+output over a list of specifications. This works, but it relies on undocumented or undefined behavior in Guile. According to R5RS, the procedure used with map must return a single value; Guile's manual is silent on that topic. To <marusich>avoid potential issues, you should replace specification->package+output with specification->package, which returns just a single output: the package. <ScaredySquirrel>I can't even fix my config.scm in emacs it says wrong type argument: stringp, nil <leoprikler>you may want to debug your Emacs, but that's a whole other problem <leoprikler>you might get away with `emacs -Q` and just enabling some basic features for now <snape>wrong type argument: stringp, nil <bandali>i think i saw that recently too when opening emacs installed from guix <ScaredySquirrel>that was shown in emacs where it buffer messages are while opening config.scm <bandali>(without any customizations on my part) <snape>it's when you have apteryx_ changes but you didn't restart your computer <snape>actually, it's not exactly that <snape>it's if you don't source ~/.guix-profile/etc/profile <snape>which adds the EMACSLOADPATH variable <snape>if you don't have that variable in your environment, you get that error <snape>wrong type argument: stringp, nil <snape>so ScaredySquirrel, you could add in your .profile: <snape>GUIX_PROFILE=/home/clement/.guix-profile; source $GUIX_PROFILE/etc/profile <snape>and that should fix your issue <leoprikler>Wouldn't that profile be sourced anyway, though? <snape>no, it's sourced only if you source it <snape>anyway once you've that new huge EMACSLOADPATH variable, you may encounter bug 38309 <snape>but that's only if you use Gnome ***catonano_ is now known as catonano
<sputny>nckx: Thanks for the answer. I read the logs ;) So my installer is broken, because after these messages the boot halts. Tried 2 different USB-Sticks and an DVD, all the same... <sneek>sputny, nckx says: Those errors & warnings are scary, but ‘normal’ (we all get them) and don't affect the boot. If your installer works there's nothing to worry about, if it doesn't it's unrelated to those messages and we'll need more info to find out why. <sputny>nckx: What further information can I provide? <wingo>is anyone else having problems with emacs? i upgraded on friday (after a long time not upgrading) and starting with "emacs -nw -q" it gives me an error in the messages ("wrong type argument") <wingo>but if i run with guix environment --ad-hoc emacs -- emacs -nw -q it is fine <wingo>so i will see if one of my installed packages is bogus or something <snape>wingo: that error happened when the EMACSLOADPATH environment variable became required <snape>basically you need to make sure it's set (by sourcing ~/.guix-profile/etc/profile/) and restarting your session <snape>(or better: rebooting your computer) <roptat>so I tried to update ocaml this week-end, but it's difficult. I managed to get rid of camlp4 on the current version of ocaml by updating some packages, and I pushed the changes (camlp4 was blocking the update because it's not compatible with the newer version and not maintained anymore) <roptat>I also ended up updating another ~50 packages after the ocaml update, and added maybe 5 more packages, but I'm stuck because we have two packages whose latest version is not compatible with the newest version of ocaml : bap and earley <roptat>they are leaf packages, and all their dependencies are compatible <roptat>I haven't tested coq yet, but I think it will work <roptat>I'm going to a conference this week, so I won't work on it, and then I have my thesis, then holidays with my family, so if anyone wants to work on it, feel free :) <efraim>You can keep the old version around a bit if you want, we've done that before <efraim>I fixed jp2a by downgrading it. Aparently 1.0.7 is super buggy. Now I have a new CLI presentation program :) <raghav-gururajan>nckx snape "./configure" worked \o/. I tried env without additional dependencies other than guix. It worked. <raghav-gururajan>Hmm! Now I have "pre-inst-env" file. But when I do `./pre-inst-env guix lint gnome-contacts`, I am getting unknown package error. <wingo>if your gnome-contacts is not in-tree you might need -L /path/too/foo.scm <wingo>omg i wrote too instead of to, my english is degrading :P <zimoun>raghav-gururajan: where is your package defined? <g_bor[m]>Our nginx config is missing an error_log level directive. <g_bor[m]>Right now I am running ninginx in debug log mode by copying the service file and starting it manually after modifying the config. <zimoun>raghav-gururajan: GUIX_PACKAGE_PATH=~/guix/gnu/packages/ guix lint gnome-contacts <snape>raghav-gururajan: glad it worked! <snape>raghav-gururajan: is gnome-contacts a new package you wrote within the Git Guix tree? <snape>or is it written outside, as an external module? <snape>you only need to set GUIX_PACKAGE_PATH in the latter case <snape>also, after ./configure ..., you need to 'make' <roptat>oops, looks like I pushed the wrong version of my blog post... ***MinceR_ is now known as MinceR
*jonsger tries the new qt-build-system <bandali>and the former redirects to the latter, it seems <snape>ScaredySquirrel: guix pull && guix package -m ~/your/manifest.scm <agg0>Hello. I recently installed guixSD on my system and I'm running into issues from the get go, just running guix pull. I get this print out: <agg0>don't know what to do with this since this command is supposed to be so basic <zimoun>bandali, roptat: thank you. Crap! coming from side then. <snape>ScaredySquirrel: it's not, when you have a decent editor <snape>ScaredySquirrel: LISP is really (my-fun my-arg-1 my-arg-2) <snape>you can't possibly do anything simpler <agg0>snape: meaning I'm screwed until this gets fixed? How do we mess up guix pull still? hah <snape>I agree... and yes we are screwed <snape>I've no idea who is in charge of this, and I haven't seen any guix maintainer for a while here <jackhill>agg0: As I understand it though, it's more of an infrastructure problem. Guix pull doesn't work because the thing it is pulling from returns an error. Suvanna is, I believe, actually run outside of the Guix project. <snape>ScaredySquirrel: so what don't you understand exactly? <agg0>how is the lead on guix these days? I was running it for a few months about a year ago, but life forced a break on me. Now I can finally have fun again... if guix gets fixed hah <snape>it's good, expect when nothing works and nobody's there <agg0>jackhill: makes sense. But that shouldn't happen if we put out guix as a dependable system. I suppose if you aren't in my position your older config should run no problem. But talking about guix in HCP environments, while such basic issues easily occur, is a bit of a joke. <snape>(btw why do you have slim-service-type twice?) <agg0>Just to put it out there for the novices: lisps are the most enlightenemed languages out there. Once you get it, you got it. And even getting it isn't that hard)))) <agg0>jackhill: makes sense. Once I get my system set up, and I got a bunch of free time, I'd love to get into the backend of this project a bit more. I love everything it stands for and tries to bring to the table. I guess I just wish we had on-pay maintainers))) <snape>ScaredySquirrel: for example, 'name' is a field of the 'user-account' structure <jackhill>that said, in critical environments I think Guix provides enough rope for administrators to insulate themselves from breakage: e.g. pull from a local git mirror and, potentally, only adding known good commits to that mirror. Still it would be nice if doing so weren't required. *jackhill wonders how the guix ipfs project is coming along <snape>ScaredySquirrel: the problem is with 'packages' <snape>it takes a list of (package ...) <snape>(wait, I'm saying something wrong) <atw>let's avoid FUD and declarations that the sky may be falling <snape>ScaredySquirrel: so, the problem is your cons* within the packages field <snape>it should include %base-packages <snape>basically, (cons* 1 2 3 '(4)) == '(1 2 3 4) <snape>the last argument of cons* should be a list <snape>in that case, the list is %base-packages <snape>ScaredySquirrel: as a more general strategy, I'd suggest that you start with a very simple config such as one given as example in the docs, and once you're sure it works, you try to add things to it little by little <alextee[m]>does the installation of vimb fail for anyone else? <alextee[m]>make[1]: *** No rule to make target '../version.h', needed by 'main.o'. Stop. <snape>alextee[m]: works for me on commit c6d130630a85709fc5a5488cfd6715ec13e72399 <snape>that may be a multithreading bug <snape>maybe with -j1 it's more likely to work <jackhill>but while I know that I didn't introduce any malicious commits, you have no way to verify that as far as I know. <snape>jackhill: commits are signed <jackhill>snape: oh! does Guix very them when pullling? <snape>I don't think so, but you can display the signatures with git, at least, and see (against your GPG keyring) if they are valid <snape>jackhill: git log --show-signature <anadon>What is the package name for gcc's 9.x branch? gcc and gcc-9 are not resolving as package names <roptat>gcc-toolchain-9 maybe? or gcc-toolchain@9 <roptat>the gcc package exists but is hidden, because it doesn't do what you want (it doesn't work by itself) <anadon>I want to try compiling files directly. <nckx>sputny: Hm. If that's really all you see before the system freezes, I'm not sure. My own Guix is badly broken at the moment (not Guix's fault)… Have you verified the signature of the installer image? That would rule out download corruption. Someone else reported a similar error recently, but I don't remember who. Could you send a bug report with the information you've provided here to bug-guix at gnu.org? <dongcarl>Hey does anyone know if Mathieu Othacehe has an IRC handle? <sputny>nckx: Yes, it's all I see. I have verified the signiture. I try once again. If it doesn't work out, I report a bug. Thanks a lot :) <nckx>sputny: Wish I could say more, but you don't describe anything I've not seen myself on a successful boot. What kind of machine is this? When you say BIOS, do you mean non-UEFI? (Some still call UEFI ‘BIOS’.) UEFI in CSM mode? <leoprikler>Does anyone else experience error 504 on git clone/guix pull? <atw>leoprikler: I've had occasional failures on those but usually 502s <nckx>leoprikler: Yep, past few days. <nckx>until guix pull; … done eventually does it. <nckx>Savannah's having problems, which is out of our control. <nckx>If you don't mind the smell you can pull from github.com/guix-mirror/guix, which I can't vouch for but was signed correctly last time I checked. <nckx>Not affiliated with Guix at all though. <leoprikler>it would probably work for writing patches, but that won't go into my channel.scm <nckx>It's not deterministic, eventually it succeeds. <bandali>i think only the savannah web frontends are having issues <bandali>you should still be able to pull over ssh <nckx>Ah, excellent point my friend. <bandali>i don't think you need to be a member of that project for the pull to work <bandali>i tried with emacs, and though i'm not an emacs committer, i was able to pull over ssh <dftxbs3e>git://git.savannah.gnu.org/guix.git seems to work better <nckx>Ah, the deprecated-since-forever git:// protocol to the rescue! <bandali>i'd personally recommend pulling over ssh in this situation, and only if that doesn't work, trying git:// <nckx>Yeah, it is the insecure & the bad. <dftxbs3e>what's bad about that git protocol if it's unauthenticated? <leoprikler>the lack of encryption and authentication I'd guess <nckx>I don't mind sitting round the fire hatin' on the PKI all evening but git:// is just worse. <bandali>also, a quick update re savannah: the issue is that its web frontends have been under a somewhat large botnet attack <bandali>the savannah volunteers and fsf staff are trying to mitigate it, but it takes some time <sputny>nckx: With newly downloaded iso und verified signature, same behaviour. It's an UEFI machine, Asus Motherboard, intel i5 2500, not in CSM mode. I write a bug report. <bandali>it seems to be originating from china <bandali>not *too* weird though; there have been large-scale attacks, e.g. on github, by the chinese in the past <dftxbs3e>"China Great Firewall" redirecting traffic> <nckx>dftxbs3e: It's probably too Free. <nckx>bandali: Are malicious incidents like this reported afterwards? <bandali>nckx, hmm, generally i don't think so ? <bandali>though they are reported in #savannah, and lately i've been updating #gnu's topic with news about any disruptions to the gnu infra ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ ‘guix pull’ servers are having serious issues: try and try again. | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel is logged: http://logs.guix.gnu.org'
<nckx>Just seems like it would be picked up as news, much like when it happens to GitHub, but what do I know. ***ChanServ sets mode: -o nckx
<nckx>Ah, no, I didn't even read it. Not mentioned at all. <bandali>nckx, ah, no this attack is separate from the last issue <bandali>and yeah i don't think they've updated their fediverse account with info about the attack <nckx>I realised that as soon as I hit return 😛 <nckx>If it's in #savannah's topic anyway, I'll be less euphemistic here. ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ Savannah (guix pull) servers under attack: try and try again | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel is logged: http://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<rekado_>nckx: we should put a clone of the repo on ci.guix.gnu.org, so that we don’t have to tell people to pull from a mirror that we cannot vouch for. <nckx>I will otherwise, but you are wiser. <bandali>nckx, sure, will send a reply in a bit <nckx>rekado_: Do you have any experience with setting up a git service on Guix? I haven't, or I'd honestly be on it. <nckx>I don't even know how to set up a mirror on a trad distro. <nckx>Do they just cron git pull? 🤷 <Blukunfando>I pulled a while ago. I hope my computer doesn’t blow up. <rekado_>I just init’ed a --bare repo on berlin, will push to it shortly <rekado_>next would be to add a cron job or something to reset the repo every half hour. <nckx>Blukunfando: The contents are trustworthy, it's just the reliable delivery that's borked. <mbakke>FWIW the github mirror is operated by yours truly, but I agree we should not advertise it as any sort of official capacity <mbakke>having a mirror (+ fallback) on berlin makes a lot of sense <mbakke>I noticed some people were "forking" my personal repo on GitHub (which used to be a mirror), so I moved it. <nckx>mbakke: Might want to set up alerts for pull requests, if that's an option. I found one languishing & pointed them to the tracker. <mbakke>Also, github won't get blocked in China any time soon. <nckx>‘while wondering who the heck owns this ‘mirror’. Hint: it's not Guix :-)’ <mbakke>nckx: thanks! I decided to just ignore those; i'd rather disable pull requests but that does not seem possible. <nckx>On the one hand I understand completely, OTOH it was a very friendly PR and I got a very friendly response so that seems a bit harsh. <mbakke>nckx: having seen some of the PR's on Linus' kernel tree on GH (which explicitly asks not to send PRs there), I did not even want to venture into those :P <nckx>Maybe edit the blurb to say ‘NO PRs’ when you have time? Some people can't read, but it being GitHub I'm sure you can add all the ⚠️ and other moji you want. <nckx>Don't know who would do something like that. <decent-username>Good evening. I tried to follow the instructions detailed in the video called "Installation from Script" from https:guix.gnu.org. But I have trouble importing the public key (At least I think that's what I'm supposed to do after downloading the script.). <mbakke>nckx: I updated the description, thanks :-) <mbakke>decent-username: what is the error you are getting? <decent-username>I've used the command "gpg --keyserver pool.sks-keyservers.net --recv-keys 3CE464558A4FDC69DB40CFB090B11993D9AEBB5" <decent-username>mbakke: I just found the "security" section on the website and after copy-pasting the text from there, it worked. <mbakke>decent-username: there is a a character missing from the key -- the section "64558A4FD" should read "64558A84FD" (note the extra '8'). <mbakke>decent-username: I thought the script imported the key automatically, did that fail for you? <mbakke>no wait, it recommends downloading it straight from savannah <decent-username>mbakke: I wouldn't want to run the script before I've made sure it's not been tampered with. *mbakke does not install Guix on foreign systems very often... ***xwvvvvwx- is now known as xwvvvvwx
***malaclyps2 is now known as malaclyps
*decent-username will install GuixSD on his thinkpad once he managed to libreboot that thing without bricking it. ***eir0 is now known as eiro
<rekado>but this is just my latest copy of the repo <mbakke>decent-username: great that you managed to get it working :-) <lfam>So, about the problem with the OpenSSH service not starting at boot — it works for me if it requires 'networking' instead of 'loopback' <lfam>The loopback "service" is a static-networking-service-type that only handles ipv4. We think that the issues with sshd not starting are because it tries and fails to bind to ipv6 <lfam>So maybe loopback should set up ipv6? Or the OpenSSH service should depend on 'networking' rather than loopback <mrb`>The guix cookbook talks about how to use several profiles with <mrb`>manifests and keep the main profile empty for throw-away packages. But <mrb`>this does not work for me. Emacs can’t find it’s lisp and site-lisp <mrb`>folders and fonts are missing in X and emacs too. Profiles are sourced <mrb`>from .bash_profile on login. Any ideas? Or have some packages to be <mrb`>installed in the main user profile? <leoprikler>mrb`: I think the right thing to do in your situation would be to put all the Emacs-related packages into one profile. <leoprikler>That being said, Emacs specifically is currently not in a great state <mrb`>They are in one profile together with emacs itself and some fonts. Emacs has all installed packages in its load-path, but can't find it's own lisp files. Does not matter if on console or X with exwm. <mrb`>They meaning the emacs-related packages. <mbakke>lfam: that assessment makes sense... I don't remember any more why I removed the "networking" requirement for openssh-service-type (07bf68ed09), it can probably be re-added while we figure things out. <nckx>ScaredySquirrel: What have they done now. <lfam>mbakke: I thought about it some more and now I am looking into setting up an ipv6 loopback in base services <lfam>mbakke: I feel like that should be sufficient <g_bor[m]>I've set up a fine environment where the nginx tls issue is reproduced just fine. <nckx>ScaredySquirrel: I've been told by people on Hacker News that if we just sed all our ()s into {}s our language will be magically better so I believe you. <g_bor[m]>Enabling debug loggin showed that on version 1.17.6 a 60000 ms epoll timer is started, that eventually times out. <nckx>It's started happening to my server too (also nginx → guix publish) so I'm all ears. <g_bor[m]>One workaround is to downgrade. like it was done for berlin. <g_bor[m]>Another that I found tweaking the config was to reduce the keepalive_requests parameter. <g_bor[m]>Now I intend to do a bisect on the mercurial repo, to find the exact commit. <nckx>g_bor[m]: To what? I've noticed that setting keepalive_requests to 1001 kills guix weather, 1000 is fine. That was before .6, though. <mbakke>g_bor: it would be great if you could turn your reproducer into a system test for nginx! <mbakke>ScaredySquirrel: try removing the ) after 'emacs' in your packages field <mbakke>the last argument to cons* is the list where all other elements are added <mbakke>ScaredySquirrel: you also need another ) after %base-packages <nckx>ScaredySquirrel: %base-packages needs to be the last argument to remove, it currently is not. Like mbakke says, but alse remove the last ) after gdm-service-type. <nckx>OK, that was based on your previous paste. <nckx>I had to add 2 ))s after the last %desktop-services. <g_bor[m]>nckx: it seems to be dependent on the number of request piped <lfam>Now I am starting to remember why things are a little messed up regarding the default loopback interfaces. The static-networking-service is limited to a single interface, and might not even support ipv6 yet? <lfam>Gabor had started working on the wip-netlink branch to overhaul this stuff but that work has paused <g_bor[m]>on my setup 93 is the max that gets through currently, civodul tested it was 85 on 1.17.5, so somewhere around 80 should be safe. Of course it is not a great performancewise, but better than nothing. <g_bor[m]>lfam: yes, right now I was waiting how the outreachy proposal turns out. We don't have an intern, so work could go on. <lfam>Thanks for the info g_bor[m] <g_bor[m]>I have seen some interesting problems documented in the recv-from! guile implementation, so this needs some thought, so that it is not a world stopper :) <nckx>ScaredySquirrel: Nope, I'm going to keep working only from your first paste, not restarting from scratch every time. You're still not importing the openbox package module, and I remember that being discussed previously. Also missing are gnuzilla, xdisorg, vim, video, emacs. I commented out ungoogled-chromium-wayland, I guess that would require (gnu packages chromium) too. <lfam>g_bor[m]: Do you remember if there is a code comment or email thread about why static-networking-service doesn't support ipv6? <mbakke>lfam: I think it was just never implemented. <nckx>Then you have (gdm-service-type) which should be gdm-service-type, otherwise you're calling it as a procedure. <nckx>ScaredySquirrel: When I make all those changes the file builds perfectly. <lfam>mbakke, g_bor[m]: Okay, I will look into the implementation <g_bor[m]>lfam: I believe there is some info, but it boils down to that it is configured using ioctl, and that only supports ipv4. <lfam>g_bor[m]: And netlink is the new way to configure this stuff? <nckx>g_bor[m]: Digging through my nginx.conf I see ‘keepalive_timeout 15m;’. That reeks of desperation, but I can't remember why it's there or why I didn't comment. <nckx>ScaredySquirrel: Their birthday was in June. <nckx>g_bor[m]: Oh, I don't expect it to be, I just wonder what past nckx was onto (if anything) and mildly angry at them for not commenting more. <nckx>Weren't there Guile-netlink bindings in the works for exactly this case? Or did that never happen? <g_bor[m]>Most of the times you see it using some scatter-gather type buffering,but you can collect you message yourself as well. <nckx>ScaredySquirrel: What are you smoking and at which .onion site can I buy it. <lfam>Nothing will change your perception like a good dose of time ***ScaredySquirrel is now known as OnlyYouCanSeeCom
***OnlyYouCanSeeCom is now known as OnlyYCSCommodore
<nckx>Oh, it's a real thing. ‘In the book, Scaredy Squirrel does not want to have a big birthday party for fear of it being spoiled by clownfish’ <nckx>TIL & haven't we all been there. <nckx>Meanwhile, back at the topic: have you been able to get your Guix on, dear friend? ***OnlyYCSCommodore is now known as youstoleme
***youstoleme is now known as ScaredySquirrel
<ScaredySquirrel>I've gotten a file that's exactly the same if not for maybe not the same package modules ***avocado_ is now known as spiderglass
***spiderglass is now known as zalckos
***zalckos is now known as porto
***porto is now known as zalckos
***zalckos is now known as temp3424234
***temp3424234 is now known as zalckos
<lfam>Hm, it's also unreliable to let the ssh service require networking <lfam>I mean it sometimes has the same issue where ipv6 doesn't come up in time and so sshd fails to bind to it and exits <lfam>It worked for me at first but after trying some other system configurations and then returning to that proposed solution it fails again <lfam>I mean, the networking service (in this case wicd) shouldn't be considered started until both ipv4 and ipv6 interfaces are working, but it seems to be a widespread problem for us <lfam>Maybe we should make "ListenAddress 0.0.0.0" the default for our openssh-service until we fix this. It's not great to have the service fail very often <lfam>And probably there are more users who want to use openssh than who require ipv6 <lfam>And even if they did require it, it's not working reliably <lfam>I'm trying to find a workaround for it <lfam>I'm thinking we should just make the service only listen on ipv4 for now <civodul>i'd like to get to the bottom of it, but it's non-deterministic <lfam>Once we have ipv6-capable loopback we can put it back, and people can always add the ipv6 address in the service's escape hatch <lfam>It's really annoying how non-deterministic it is <lfam>There are timing issues with bringing the network interfaces online, and I think also with the speed of disks <lfam>And of course nobody wants to test it on their servers because it's a minor disaster if the ssh service doesn't come online <lfam>I'm writing a patch for the listen address thing now