<bavier>nckx: hadn't seen that note; that should do, thanks! <nckx>I just can't imagine what kind of tiresome pedant would need a ‘citation’ that a distribution is in fact called… itself. <nckx>bavier: You're welcome! 🙂 <nckx>You can leave of the #anchor, makes a nicer link. <Minall>Because of that, shouldn't it be separated? <atw>quiliro: maybe install on a vm (or on a machine that's not one's primary machine)? As to the second part, find a package that one wants that's not in the distribution, read some packaging tutorials, write a package definition, then share <atw>Minall: yeah...but there's a few packages in lua.scm that seem like they might be modules themselves. Probably I should just make lua-xyz.scm <Minall>atw: Well, in that case its on you <Minall>Maybe you add it on lua.scm but then guix developers separate it <Minall>The only action of adding a package is a lot o/ <quiliro>atw: It would be nice to have a more detailed curricula for teaching (guiding) Guix. ***catonano_ is now known as catonano
<vagrantc>yay, managed to get the veyron-speedy working with linux-libre 5.1.21 at least... <vagrantc>now i just need to figure out what broke in 5.2.x <vagrantc>hmmmm... maybe i should finally figure out how to use channels <nckx>I'll think you'll be pleasantly surprised by how trivial they are to both add and create. <ful0n>maybe silly question, but couldnt find a discussion anywhere: are there any plans for focusing on embedded systems? I'm not talking about having guix on my router, but being able to create customized, reproducible and immutable images of librecmc, for instance. <vagrantc>so, linux-libre 5.1.x is no longer getting updates, so i assumed that's why it shouldn't go into guix master... <nckx>vagrantc: Bingo. The only up-to-date releases are 5.3.1-gnu, 5.2.17-gnu, 4.19.75-gnu, 4.14.146-gnu, 4.9.194-gnu, and 4.4.194-gnu, which I just blatantly copied from #linux-libre. <nckx>ful0n: Not specific ‘plans’ AFAIK, but work in that area (as in any area that expands the systems/architectures supported by Guix) would certainly be welcomed and supported. <nckx>ful0n: ‘Focus’ as in ‘change the goals of the project to focus primarily on embedded’: certainly not, but I doubt that's what you mean anyway 🙂 <vagrantc>ful0n: i've done some basic work to enable support for a variety of boards (e.g. bootloader, kernel, etc.) <vagrantc>ful0n: though "embedded" devices using guix are certainly not going to be space efficient or able to be upgraded in-place very easily <ful0n>vagrantc: nckx thanks! I'm still learning but I want to experiment with that <ful0n>vagrantc: any reason for not being space efficient? I get the upgrade being hard but why would it not be possible to use guix to automate the configuration of buildroot? wouldnt that come to the same size? are your .scm public? I would love to take a look! <nckx>Guix will never be as compact as some other distribution{s, methods}, that's true. Part of that is simply due to the design, but a lot of it is just lack of optimisation for space-constrained use cases. <nckx>If you treat Guix as a Gentooish toolkit-to-build-your-system, e.g. writing your own tiny (foolibc?) packages instead of using Guix's general-purpose ones, I don't immediately see how a Guix system would have any significant overhead. <nckx>But then it's late and I'm not an embedded person so I might be missing an obvious 🙂 <vagrantc>well, fairly often there will be multiple versions of a library on an installed system, for example. <vagrantc>at least, the guix model allows for that sort of thing... <ful0n>nckx: makes sense, but I think that still reflect just how things have being done so far for non-embedded systems. I think if it proves to be useful for embedded, there will be repos out there with embedded-optimized packages <vagrantc>nckx: the reasons are good, but the result is multiple copies of essentially the same or similar things <nckx>ful0n: ‘There will be… out there’ — well, someone just has to make them. ;-) <nckx>That's just the reality of being the first to use tool X to do Y, not an attribute of X. <ful0n>nckx: yes, hehe, I'm sparking the discussion to create it. I'm still learning scheme and guix basics. btw, your zswap conf tip worked, thanks <ful0n>vagrantc: yes, but lets imagine we start another repo for embedded packages. The build system will act as guix does today, copying and linking and so on. But on the final step we can make the image by moving the final parts to it as we like. the image itself wont have guix installed, for embedded case, so maybe there is a way to tune that as a last step to generate a "new kind of image", lets call it <ful0n>"embedded-disk"? I can be wrong here as I'm glueing pieces of what I learned so far <vagrantc>ful0n: yeah, sounds like a great project for *someone* to work on :) <nckx>vagrantc: I'm not seeing it… could you give an example? It happens in ‘stock Guix’ only because we're OK with it; someone who cares about embedded would define their packages more carefully (but in my limited ‘embedded’ experience — creating extremely small rescue systems with Gentoo/Exherbo — that's true of any distribution). <vagrantc>nckx: sure, it will take more fastidiousness ... <ful0n>vagrantc: someday, my friend, someday. I gotta fight those parenthesis for now while learning scheme, but if someone starts such thing I'm in to test <vagrantc>nckx: honestly, one of the advantages i see in guix is you don't have to be so particular and you can let the build system take care of that :) <nckx>vagrantc: Tradeoffs, tradeoffs everwhere. 🙂 *vagrantc forks guix to use wisp <vagrantc>i guess guix is already kind of a grown-up distro; there's at least one derivative distribution already :) <nckx>ful0n: I don't see a reason why what you describe shouldn't be possible. Really, it must be possible to create an embedded system with Guix where the only ‘overhead’ is the fact that some file names are longer. That's it. Everything else is just putting in the packaging/chiseling work that's been done elsewhere but not yet in Guix. *nckx goes to check on our downstream friends. <nckx>(And even those longer file names alone carry useful information even in the final image. You could combine image layers. Or something.) <ful0n>nckx: cool! btw, what I meant with "another repo" actually is about packages, not another guix. embedded-optimized ones, probably using musl for instance. I'm still getting terms like downstreams, probably something like that (just searched for it, after you mentioned) <nckx>Yeah. Once you ditch glibc, your package graph is disjunct from Guix's anyway. ‘Embedded’'s pretty broad (my printer has 1 GiB of RAM), but I really don't think there's a way around a separate package set, once you need to fit beneath a certain threshold. *nckx .oO …our feline friends should have a ‘Beta 2’ release out by now, but I can't find it… <ful0n>nckx: that explains a lot for a beginner, thanks. I will see how thats done and if someone have a downstream like that to learn. <nckx>ful0n: My ramblings about ‘downstream’ were unrelated to embedded, though. I was talking about PantherX, the derivative that vagrant was hinting at. Their stated goal was a beginner-friendly desktop system. ***wingo_ is now known as wingo
<laz>jackhill: thanks a lot! <laz>but now the problem is with GHC_PACKAGE_PATH <laz>cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal <laz>also, i would really like to use stack, as my team uses it and our is built around stack <laz>s/our/our infrastructure/ <civodul>g_bor[m]: is everything on track for this Outreachy round? <civodul>and thumbs up to nckx for the linux-libre updates! *civodul is all thumbs-up today <efraim>is it a known bug that 'guix environment --ad-hoc font-foo' doesn't add font-foo to the font cache? <civodul>efraim: you mean it doesn't run fc-cache? *janneke builds the new core-updates-next <efraim>civodul: yeah, basically. I got the command 'convert -list font' to see that the new ones aren't added. On the other hand, fc-cache would need to be run again when leaving the environment <g_bor>We now have two Outreachy proposals for this round. <civodul>efraim: yeah, 'guix environment' doesn't fiddle with user state <efraim>civodul: so I guess working as intended. ok <g_bor>civodul: yes. We are still looking for comentor for the Guix Data Service project. <g_bor>civodul: the only thing is that I missed the e-mail about the installer project, na dnow it is too late to get that in shape. Sorry about that. <civodul>what do you mean "comentor for the Guix Data Service project"? <civodul>we have to comment on-line about the proposal? <g_bor>civodul: cbaines is the only mentor. <g_bor>If someone could step up to help it would be great. <g_bor>Not strictly needed, but can reduce the load on the mentor greatly. <civodul>Mathieu was willing to mentor another project, perhaps we could ask if they'd be willing to co-mentor this one? <civodul>BTW, we should also publish a blog post as soon as the projects are officially accepted <g_bor>civodul: the link should not be promoted before Oct. 1. I will create the blog post, and send to guix blog with a do not push before notification. <civodul>thanks for taking care of all this, as always! <idnull>Hello, I'm trying to customize my Guix setup, so far I have some problems (this is the config: http://dpaste.com/3V1D0H0.txt) 1. I want to use custom console font (had no luck with this substitution, what am I doing wrong? 2. I want to use console autologin too (or gdm for now, before I move to a more comfy packages) (still no luck) 3. How would one customize dwm/st (build from selected repo applying config.h) 4. rebuild everything <idnull>from scratch and replace openssl with libressl 4.1. is it possible to use custom cflags/ldflags 4.2. how could one get ./configure --help for the packages (I want to do something-like USE flags on a per package basis) 4,3, Is there an option to make optional dependencies for a package (only for selected flags)? 4.4. I would like to package iwd but I need to create a service for it (it can replace wpa_supplicant and work with NM <idnull>afaik), how do I package service? <roptat>idnull, the first argument to modify-services is a list of services, like %desktop-services <roptat>in your file, you have a few uses of modify-services, but they all have something else as first argument, that can't work <roptat>actually the last attempt looks correct, although it only modifies gdm <roptat>cons* takes different objects and a list as last argument, and returns a new list that contains these objects and the content of the list <roptat>console-font-service-type is not part of %desktop-services, so it has nothing to do inside the modify-services <roptat>also, if ter-p20b is not part of kbd, then that won't work properly, but I'm not sure which package it's part of <idnull>So how could I change part of base-services? <roptat>idnull, in that case, change "ter-p20b" with (file-append terminus-font "/share/consolefonts/ter-p20b.psf.gz") <roptat>%desktop-services already extends %base-services, so using modify-services, you can also change anything that's part of %base-services <roptat>but console-font-service-type is part of neither, that's why you add it separately from modify-services <idnull>(file-append terminus-font "/share/consolefonts/ter-p20b.psf.gz") gives Wrong number of arguments to #<procedure map (f l) | (f l1 l2) | (f l1 . rest <roptat>there's probably a missing parenthesis or you replaced too much from what I gave you :) <roptat>I told you to replace "ter-p20b" with the file-append form I gave you, it should be (cons tty (file-append font-terminus "/share/consolefonts/ter-p20b.psf.gz")) on that line <roptat>with an additional ")" to close the lambda <idnull>I tried it fistly, had no luck, let me try it again <roptat>if that doesn't work, give us the error and associated config <idnull>now: /etc/config.scm:77:16: Wrong type to apply: #<service-type console-fonts 7eed70> <roptat>oh I didn't see you used modify-services on the console-fonts service, don't do that <roptat>and also, use (service console-font-service-type ...) not just (console-font-service-type ...) <idnull>guix system: error: service 'console-font-tty1' provided more than once <roptat>ah! it's actually part of %base-services, I just didn't look hard enough ^^' <idnull>thos bts are difficult to read though (for a newb for sure) <roptat>one missing parenthesis on this line: (default-user "id0") <roptat>but "error: =>: unbound variable" means there's a => symbol outside of the macro, which often means parenthesis mismatch <idnull>still I read in the mailing list that gdm autologin is not working (not a problem as I want to use autologin from console and dwm/st (still need to understand how to package things up) <roptat>for packaging things, there's the tutorial on the blog, and the new guix-cookbook info manual <idnull>and one more thing, before I've started changing services it was looking: (services %desktop-services). Do I need to add %desktop-services somwhere? <roptat>no, it's already in the modify-services form, right? <roptat>it returns a list of services that's the same as its first argument, but with some changes to some services <idnull>and what about replacing openssl with libressl system-wide (I got used to source-based distros, yes)? <roptat>that's going to be more difficult <roptat>of course you could fork guix and redefine openssl to be libressl <roptat>but there might be some other way <roptat>in any case, it means you'll rebuild almost everything <idnull>I want to build everything from scratch with custom dependencies <roptat>you could get your own variant of guix by applying your patches and rebasing from time to time <roptat>or maybe someone has a better solution, some sort of wrapper maybe... you could ask on help-guix@gnu.org <mfg>hi, does someone use the kitty terminal emulator? <roptat>mfg, I don't, and if nobody can help here, maybe you'll have more luck posting a message to help-guix@? <mfg>may i directly write to tha tlist or do i have to be subscribed? <roptat>you don't need to be subscribed, we'll CC you <civodul>roptat: looks like your overdrive is down <roptat>my other home server does respond, so my house is not on fire :p <roptat>unless it didn't reach the server and the modem yet :p <roptat>I'll restart the overdrive this evening <roptat>civodul, I was wondering, since I'm moving and I'll get another subscription for internet, I might not have a stable IP, do you think I could set up a tor service on the machine, to have a stable .onion address on which to ssh? <roptat>it would be nice to have: no more firewall issue, and changing the machine from person to person, or changing IP would be completely transparent <civodul>roptat: we'd have to set up an SSH tunnel (because guile-ssh can't do SOCKS directly i believe), and throughput and latency may not be all that great <janneke>bah --target=x86_64-w64-mingw32 is still broken on core-updates-next and google has no simple answers <janneke>../../../../gcc-7.4.0/libstdc++-v3/libsupc++/new_opa.cc:76:10: error: ‘memalign’ was not declared in this scope <janneke>*searching the internet // me actually uses duckduckgo <civodul>janneke: you should try on core-updates <civodul>core-updates-next has just one additional commit <civodul>well actually more now, but nothing significant <civodul>janneke: not that it'll solve the issue, though... <janneke>civodul: you're right ahead of me -- indeed, same problem <janneke>i cannot imagine that debian or someone else hasn't already solved this, but i looked for .deb files and did not find any patches <janneke>i must be looking at the wrong places <janneke>jonsger: ../../../../gcc-7.4.0/libstdc++-v3/libsupc++/new_opa.cc:76:10: error: ‘memalign’ was not declared in this scope <jonsger>janneke: when building gcc7 on core-updates? <janneke>more specificly: gcc-cross-x86_64-w64-mingw32-7.4.0 <janneke>jonsger: so, using --target=x86_64-w64-mingw32 <jonsger>janneke: there is no mingw cross compiler in (open)SUSE. So no patches to share from that site... <janneke>jonsger: thanks .. i now see a gcc-8 cross compiler in debian, haven't found 7 yet <mfg>What does guix do with font dirs when building a vm-image? i built one which contains icecat but not a single character gets rendered, just the square boxes which state the unicode number... <civodul>mfg: you probably have to add a bunch of font packages to the system profile <civodul>the "desktop" example in the manual works fine, AFAIK <sirmacik1>how can I change directory to keep guix files while building so it won't be /tmp ? <quiliro>or something like that...I do not remember <mfg>civodul: ah okay, i will check that <sirmacik1>quiliro: as I can see it just instructs guix to keep failed build files or keep going after fail <sirmacik1>but I want guix to keep build files whil building package away from /tmp (I get no space left error) <quiliro>sirmacik1: I do not have all the answers. But maybe I can help you have a better idea of what you know and what you don't know. Then possibly you can find the solution. Please explain to me: how can you keep files if you do not have enough space? <sirmacik1>I now that due to defaults in host distribution I have 4G of space in /tmp <sirmacik1>and that's not enough to build icecat package <sirmacik1>while building icecat guix stores files in /tmp, that /tmp fills up and guix fails <sirmacik1>I want to instruct the guix to put its files somwhere else <sirmacik1>so I can succesfully build icecat and update my packages <janneke>hmm debian has no apparently significant patches in gcc-8 and they don't carry a gcc-7 mingw cross compiler <janneke>i could look at the mingw-w64 package or try gcc-6 or 8 ... or try the patches that do not look like they fix this memalign thing <Minall>How can I use herd to start a service at startup? <Minall>I'm using the ssh-daemon, which is not started by default, I have to do it manually <roptat>sirmacik1, you need to set TMPDIR for the daemon <Minall>Oh, sorry, I was asking about ssh too, so i though <roptat>Minall, there's an issue with ssh, it's actually started at boot, but on some machines fails to start, and then you have to start it manually <roptat>there's already a bug report about it <Minall>Is there a fix of it, or is just a bug? <roptat>just a bug, it seems to be related to ipv6 <roptat>but that's weird because I'm pretty sure I have a machine that doesn't start ssh at boot and another that does, on the same network <roptat>it might also be a race, and I don't reboot them very often <roptat>and maybe I was just lucky with one of them ^^ <raghavgururajan>> lfam: I'm not 100% sure but I think that the `guix pull` interface is versioned now so we shouldn't have issues like this again <vagrantc>i wonder if ssh not starting might be an issue with insufficient entropy... <janneke>hmm, gcc 8.3.0 gives the same memalign error; yet debian has package <janneke>debian's mingw-w64 packages does not carry interesting patches, let's try the debian gcc patches then <roptat>I'll try to change the ssh-service to log to a file, that might give us more info :) <idnull>Hello once again, how can I import created packages/local repo? <bavier>idnull: using "channels" is the preferred method <idnull>bavier: this is rather silly question, one replaces url with path? (path ,"/home/../")? <bavier>idnull: I think you can give a file:///... url <roptat>So the overdrive won't boot, grub can't finl the kernel <sirqwit>i have the error no such file or directory on linux/errno.h <sirqwit>i have see that search on /gnu/store/h90.../include/bits/ <sirqwit>and with find i have found the library in /gnu/store/h90.../include <reepca>sirqwit: do you have the gcc-toolchain package installed? <reepca>sirqwit: is CPATH set? Does ~/.guix-profile/include/linux/errno.h exist? <reepca>if CPATH is not set, it's likely you haven't started a new shell since installing gcc-toolchain, so run 'source ~/.guix-profile/etc/profile'. <sirqwit>what do you think if i put that command in .bashrc? is the right way? ***PotentialUser-65 is now known as vsm
<idnull>what am I doing wrong? (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (license:x11)) (value #f)) <nckx>sneek: later tell sirqwit: No! You'll regret it. Just start a new shell, don't add anything to .bashrc. <reepca>idnull: inside the (guix licenses) module it's just called "x11". You often see it referred to as license:x11 because in those modules it's arranged for all identifiers from that module to be prefixed with 'license:'. See: info '(guile) Using Guile Modules' <reepca>in short, replace '#:use-module (guix licenses)' with '#:use-module ((guix licenses) #:prefix licenses:)' <idnull>ty! It's time to write some packages (eg: new moon, iwd, themes, k8vavoom, and dwm/st with my configs) <nckx>idnull: Happy to hear that! It's always time to write some packages. <idnull>don't know about newmoon, but I'll try to upstream at least k8vavoom and iwd <idnull>because it's not that easy to upstream something like Pale Moon <nckx>idnull: Pale Moon upstream has a very bad record of threatening and just generally being rude out of the blue to distributions that dare package it. <nckx>Personally, I'm doubt it's even possible (or desirable) to upstream it at all. They freak out if you unbundle stuff. We unbundle stuff. <idnull>ncks: afaik one can redistribute New Moon safely. Yeah, people can be rude, but I'll still be using New Moon nevertheless <idnull>from my newb point of view writing ebuilds was easier <idnull>I spent two days and still know almost nothing about Guix <nckx>idnull: Possible, I'd have to read about Pale Moon again to remember the branding details and I don't wanna. I hope it's improved! <nckx>idnull: I get it. Ebuilds have the advantage (FWIW) that you can just write the same thing you'd write on the command line. *nckx gets distracted by Yet Another Doom source port. <idnull>and one more thing, why consequent guix pull sometimes takes zillion of time? <idnull>nothing changed, I only want to package my first small packages <nckx>I can't speak for Guix. It seems unlikely that *nothing* changed if it takes so long, but Guile is absolutely not the fastest compiler around. <bavier>idnull: when testing packages from a local channel, I sometimes use `guix build -L /path/to/channel/root -e '(@ (module name) package)'` to avoid having to go through guix pull every time *janneke sent out a patch too quick, will retest and update <idnull>(exception misc-error (value #f) (value "~A ~S") (value ("no code for module" (stest))) (value #f)) <bavier>idnull: guile modules need to be named the same as the file they're in <nckx>This would be an stest.scm file (which seems to be the case) at the top level of your hierarchy (which we can't know). <bavier>i.e. a module "my-dwm" would be loaded from a file name "my-dwm.scm" relative to some directory in the load path <idnull>I added #:use-module (gnu packages fontutils) but now it shouts: (exception unbound-variable (value "module-lookup") (value "Unbound variable: ~S") (value (openscenegraph) but this package is not needed... <idnull>before Guix shouted about unbound freetype and asked to add packages fontutils <idnull>I don't understand, I copied dwm directly from suckless.scm, it should just build <nckx>idnull: Why is that package not needed? <nckx>I'm not saying Guix is always right, but nor does it shout and it seems to disagree ;-) <idnull>because my small gentoo setup has no such package (stupid justification, yes) <idnull>and it's a copy-paste from suckless.scm <nckx>openscenegraph has only 3 dependents: openmw, simgear, and flightgear. Something else is going on here; Guix isn't saying that it needs it to build dwm. <nckx>(Yes, I do wish I could tell you more than that 🙂) ***lx0 is now known as lxo
*janneke oh crap, used the wrong email address for a bug report *nckx goes to get the jorts of shaming. ***jonsger1 is now known as jonsger
<nckx>roptat: Do you know what went wrong with the Overdrive? I was going to update mine; now I'm hesitant. <laz>i'm trying to build a haskell package with a long list of dependencies and it fails with a error `execv: Argument list too long` <laz>i think this problem may be common as all include paths and library paths can be quite long, so maybe there is a solution somewhere in guix library? <mbakke>whoops, the OpenEXR update broke 'freeimage', and possibly some others <laz>google suggests to increase stack size for building process, but i'm not sure where this should be done <ng0>nckx: search the guix-devel archives <ng0>iirc i posted the results of my conversation with the pale moon developer there, back then <ng0>if I didn't, tell me and I'll summarize it <ng0>but the New Moon is unbranded and can be redistributed <ng0>someone contacted me about my package recently.. or the one bitrotting now on my side <nckx>I'll try. I was referring mainly to the infamous *BSD incident of which I'm sure you're aware. I didn't know about explicit Guix discussion. Thanks. <ng0>imo spend time packaging SeaMonkey, more useful if applicable under guix policies <nckx>(I've also talked to newwhatstheirname, which was not pleasant, but that was not public.) <ng0>yeah I packaged New Moon for guix and then left it at that <ng0>i wouldn't call my interaction pleasant, but I also wouldn't call it as nasty as they did on the wip ports package of OpenBSD.. so unknown, so much anger to put into trademark defenses. <ng0>like yeah do a TL;DR of the trademarks and brandings page because I have a good understanding of trademarks but had to ask to get it right. torbrowser was more lax about when you can call it torbrowser <ng0>it was more open than I thought, I CC'd guix-devel back then o.O <ng0>thanks brain for not keeping up space for this <ng0>there's a very tiny percentage to which i regret that I remember conversations from almost 2 years ago which are largely irrelevant for my life or work o.o <nckx>Hm, that is much more liberal than the impression I was given (by a different developer). It felt like they were, what's the word, grandstanding their own importance in a uncomfortable way, trying to ‘impress’ me with weird pseudolegal language, it was all a bit odd. <nckx>Yeah, the brain's default GC algorithms need some serious tuning. <idnull>nckx: was this impression given to you by some of the openbsd devs? <nckx>I'm now sorry for bringing this up (my own fault); I'm not going to give out any more names. It was years ago. I don't want to get trolled for this. <idnull>i'd say that i'm being trolled by a distro right noe <idnull>I will tell you in a few moments. This problem started when I changed (packages in system.scm and made a new build. I'm reverting it <mbakke>idnull: are you working from a guix checkout? <coldpress>I know guix is good, but are there any visual demonstrations (like pictures or videos) of how good it is? <mbakke>idnull: try reverting f95ec65be394538c9ec848e502a37f1c3ec21157 if you can <ng0>idnull: ah. if you need a new moon package to finish, feel free to take mine (iirc it's even in some form still an open patch? if not I can send you the link to my mercurial) and keep me as co-author (if you don't happen to rewrite it all <idnull>ng0: you've sent me the scm already (today or yesterday) <ng0>i don't know names on irc.. so it was you. cool <idnull>as I am getting used to the build env and so on <mbakke>but if you don't have it, it's unlikely to be the problem <nckx>Oh, I hadn't pulled to that commit yet. That certainly sounds like a very big coincidence… <mbakke>laz: I have not heard of that problem before, could you perhaps ask on guix-devel ? <laz>mbakke: thanks, i'll do <nckx>Hullo uncapitalised minall. <nckx>Nobody bad, just so unusual I noticed it. *nckx gets ready to change the /topic again if this lasts more than a few minutes, sigh <nckx>Not sighing at you asking, zalox[m], that's completely understandable. But I hope we're not looking at weekly outages becoming normal. <cbaines>I think it's been down for a little while now, at least 20 minutes or so