<mark_weaver>well, maybe not more-than-double in practice, but increase it anyway.. <lfam>I personally wouldn't be interested in doing extra work required to maintain a stable branch. It's a lot of extra work and I don't think the result is worth it. <mark_weaver>it would be useful for running on Guix on production servers <mark_weaver>I can see the value in it, but I think we'd need a larger team of people working on security updates <mark_weaver>dmarinoj: security-updates is not a stable branch though. it's just a branch that hydra is building before it gets merged into master. <lfam>Security updates are often patches that require a lot of work to backport to older versions of the software they are patching. mark_weaver is right. We would need a lot more volunteer-power. <codemac>have there been any recent libgmp+guile bugs? I'm finding on my i7 it runs fine, but on an intel celeron (3205U) it issues an invalid instruction during 'guix pull'. Will be posting details later tonight, just curious if there are any outstanding bugs on libgmp/guile that I should try to rule out first. <dmarinoj>Got it. It would be really cool to have a security team in the future like Debian. I am really excited about the future of GuixSD <lfam>mark_weaver: You symlink .config/guix/latest to your source tree, right? Just confirming before responding to an email on the subject. <lfam>It would be useful. Feel free to jump in :) <mark_weaver>lfam: for the record, alezost was the one who first thought of doing that <mark_weaver>the only caveat is that if your source directory is in a bad state, then you won't be able to use guix until it's fixed. <lfam>mark_weaver: I assume you've considered the implications for root privilege escalation, if the source tree is in ~mhw. <mark_weaver>but given that I'm developing the OS that I'm running, I don't see a way around that <mark_weaver>and btw, if you're worried about that, you should never use 'sudo' or 'su' either. <lfam>Yes, I expected you to have thought of it. I'm not sure about the user who I am responding to on guix-devel. <lfam>I remember you saying that. You do all that stuff in a separate tty? <lfam>The security model of Unix-style systems is rather scary, to be honest <mark_weaver>more precisely, I *never* use sudo, but every once in a while I use su <mark_weaver>the fact that sudo, in its default configuration, would allow *any* program running as my user to do arbitrary things as root, I find terrible <lfam>I don't trust all this software that runs in my name <codemac>mark_weaver: ok thanks, will try to chase it down more <mark_weaver>I've gotten to the point that I don't trust any computers at all. <lfam>I talk to "laypeople" about computer security, and they ask for recommendations, and I really have nothing to offer them. <Jookia1>mark_weaver: :( That must really suck <lfam>The whole ecosystem is a disaster <Jookia1>Microkernels and GNU Hurd to the rescue! <NiAsterisk>I can only talk about what sucks, why it sucks and what's coming for social networks etc.. I couldn't even answer security related requests for windows users. <NiAsterisk>there's grsec etc, and it#s interesting, but you have to invest some amount of time. <lfam>There are lots of effective mitigations, but if you consider the system as a whole, it's really discouraging. <lfam>We have *a long* way to go before computers will really be safe tools <lfam>Maybe in another century <NiAsterisk>run everything in isolated VMs.. oh wait now, virtualization just became insecure. well. I like how ioerror travels.. diskless tails systems, it's not suited for development, but it does not hurt you. <NiAsterisk>there's no one answer and the problem is complex. <lfam>I think it was de Raadt who asked about virtualization something like, "Why should we expect programmers who can't create secure kernels and operating systems to create secure virtualization tools?" <NiAsterisk>maybe we see an answer in our lifetime, maybe not. maybe it all blows up and computers become irrelevant. who knows. <lfam>We are all in the "worldwide collection of software engineers" <NiAsterisk>it's not just software.. it's hardware, and the lack of audit of the entire chain of parts used and delivered for for example an entire mainboard. <Jookia1>Hardware isn't as threatening as the Internet <NiAsterisk>if there's a backdoor in your chip (there are) and it can be (theoretically) be used to access your computer, it's threatening more than that <NiAsterisk>you can shift elements in processors and get a backdoor... etc <lfam>We have literally no idea what our CPUs do. Even if Intel released a processor without the ME, microcode, etc, you still can't trust it meaningfully. <NiAsterisk>it was rather okay before 2000s or the mid 90s... then there was another economy crisis and quality went downhill <Jookia1>I have a feeling it'll stay this way until capitalism falls and people are working together rather than against each other <lfam>I wasn't "around" then, so I don't know. But I think we just didn't know about the bugs back then. For example, format string attacks were present since printf() was introduced, but according to wikipedia they weren't "discovered" until 1989. <codemac>lfam: loving that email, thanks for sharing <lfam>codemac: Yes, I'd hate to be on the receiving end of one his emails, but they are entertaining! <mark_weaver>certainly very old computers are much simpler and less likely to have back doors, I would say <dmarinoj>That's why free hardware and 3D printing is the future <lfam>And I respect what their project does <mark_weaver>but even apart from lfam's comments on hardware, which I completely agree with, our software is a lost cause as well. it's like swiss cheese. <mark_weaver>IMO, we need to reduce the amount of C code by a factor of about 10000 <mark_weaver>because it's prohibitively difficult to write secure code in C. <lfam>Well, I think this very long and painful process will be necessary to improve. Hopefully the damage is not too severe to the people affected. <Jookia1>We need to start having fisher price programming languages because we obviously can't handle anything that lets us do something dangerous <mark_weaver>I think that Guix is part of the solution, but only the beginning <mark_weaver>we need to radically reduce the size of our bootstrap binaries to something that can be effectively audited. <NiAsterisk>i would like if projects like Guix can get down to the level where kids can get involved and bring in new, fresh, unaffected ideas. some projects do this. <mark_weaver>and IMO we need to incrementally replace our core trusted components with rewrites in languages that are less prone to security holes. <lfam>I bet if you start kids on Scheme they will grok it easily <mark_weaver>and we need free designs for all of the trusted hardware in our systems, and a way to inspect a piece of physical hardware to verify that is corresponds to the design that we've audited. <Jookia1>We probably need to learn with less-is-more and worse-is-better while we start back with decades old technology <NiAsterisk>there's too little people working on all the important things, and I have only so little time :/ <mark_weaver>doing so would surely require destroying the hardware, but that's okay, there's a solution to that problem. <lfam>NiAsterisk: On the other hand, the problem domain of providing trusted software (Guix's domain) is probably not something that a kid with no experience would have much to say about. But who knows? <NiAsterisk>for example, for the internet, I agree with the assumption that it's best to burn it down and recreate from scratch, stop the patching, start new. doing so for other fields will be difficult and time consuming. <lfam>I should say, Guix's potential domain. <mark_weaver>when buying hardware, get together with N people buying the same hardware, and then purchase some extras and randomly choose some to inspect/destroy. <lfam>We (humans) will have to invent a better method <NiAsterisk>lfam: who knows... I have vague ideas with no concrete forms on applying emancipation on projects. <NiAsterisk>mark_weaver: it will.. it just seems impossible now. <mark_weaver>NiAsterisk: first of all, how will you "burn it down" ? <mark_weaver>convince everyone to stop using networked computers? good luck with that :) <mark_weaver>what we could do is to replace one trusted component at a time <NiAsterisk>bad figure of speech maybe. what I meant is what's happening at EDN.. looking rationally at useful parts out there, analyze and later apply and advocate through many different channels the change. politically, technically, codewise. GNUnet, regulations for parliaments on certain topics, etc etc <NiAsterisk>nothing I can talk about while multitasking though :) <lfam>Man, I really don't think there are political or legal solutions. People will *always* break the law if they want to. <NiAsterisk>I have problems keeping to short sentences in general and with chat in general. I have spend some amount of time since last year with reading and looking into the projects surrounding EDN. <NiAsterisk>there's a proposed, work in progress, set on youbroketheinternet.org <lfam>Ah. I was talking about things like illegal government surveillance. <mark_weaver>I think we'll be ready to merge the glibc security fix in the next few hours. <mark_weaver>paroneayea: to be clear, there will be *many* unbuilt packages. <mark_weaver>but enough of the most popular packages will be built that maybe it should be done anyway. <lfam>I agree. In practice, many packages do not really take that long to build. <mark_weaver>the hope is that it won't take unreasonably long for most people to build whatever remaining packages they need. <lfam>And I think it's good to "exercise" the compilers on users' machines once in a while. You never know what sort of bugs will show up! <mark_weaver>and we'll make it a high priority to get grafts working soon so that next time we won't get caught with our pants down again. <NiAsterisk>the RUNPATH validation is part of gnu-build-system? I get output like this on the end of a build: /gnu/store/cy6ib13vnw84r6gbmfh1idf8pk9bhpag-kyotocabinet-1.2.76/bin/kccachetest: error: depends on 'libkyotocabinet.so.16', which cannot be found in RUNPATH ("/gnu/store/gybk6iz6n659njzg56vqsy5bg7irk370-glibc-2.22/lib" "/gnu/store/n9ap5r8j6vw92ban7baisg4vswsmf299-gcc-4.9.3-lib/lib" <NiAsterisk>"/gnu/store/n9ap5r8j6vw92ban7baisg4vswsmf299-gcc-4.9.3-lib/lib/gcc/x86_64-unknown-linux-gnu/4.9.3/../../..") <mark_weaver>ld-wrapper takes care of adding -rpaths for libraries that are linked in the usual way with -l arguments to ld, but I gues something different is happening there. <NiAsterisk>I think I might know how to solve it.. but not today. got to go to bed. I see some gentoo and nixos builds on this. <mark_weaver>NiAsterisk: okay, I can help you more with that another time then. sleep well! <NiAsterisk>i'll try my best to solve kyoto and panopticon on my own, but I'll come back to you :) thanks. <mark_weaver>NiAsterisk: most likely, you just need something like the "LDFLAGS=-Wl,-rpath=" thing in our python-2 package <mark_weaver>damn, one of our three intel builds slaves is offline. bad time for it. <_`_>lfam: de raadt wrote that but openbsd's working on a accelerated hypervisor almost a decade later when x86 hasn't really improved much in that regard. <_`_>SLAT/CMT/VMCS/DDIO are barely improvements and worst of all mean AMT. <ajgrf>if i add a package.scm file to my project (which imports some guix modules), does that mean the whole project needs to be GPL 3? <ajgrf>i like that guix is GPL, but it might need an exception for this use case similar to autotools <ajgrf>although the language for this exception would be a lot more difficult <davexunit>I mean, that one file must be GPLv3+ licensed, but it is completely isolated from the rest of your codebase. <davexunit>so I don't see how that could make your whole project a derivative work of guix. <davexunit>if that is the case, then I am violating the GPL currently. <davexunit>I'd like someone more knowledgable in licensing to confirm/deny, but I suspect it's OK. <mark_weaver>ajgrf: out of curiosity, what are you working on and what license do you plan to use? <mark_weaver>I don't think we can provide an answer to the question as you've asked it, without more details. <mark_weaver>the key question is whether your project would be considered a derivative work <Jookia1>By Kirkland, the guy who talked about ZFS in that blog post <ajgrf>i'm working on invoicing software that probably won't ever get distributed, so it's not a real problem for me yet <davexunit>ajgrf: when you say "package.scm", are you talking about putting a file in the source tree in order to provide a way to build a dev environment via 'guix package -l'? <ajgrf>mark_weaver: it's the build system <mark_weaver>ajgrf: the build system can have a different license than the software its building <ajgrf>then why does autotools need an exception? <mark_weaver>ajgrf: the reason is that the contents of the generated ./configure script (and other files) contain a great deal of code that comes from autoconf itself. <ajgrf>not even sure what you meant by `guix package -l` <davexunit>anyway, your program isn't linking against Guix code in this case. you happen to be using a GPLv3 licensed tool to perform a software build. <mark_weaver>ajgrf: if all you're doing is providing a file to facilitate building your program with guix, and not using guix modules within your invoicing program, then it's certainly fine. <davexunit>the file that contains the packaging code would be a derivative work of Guix, but not your software itself. <mark_weaver>having said all of this, I hope you'll consider using the GPLv3 for your invoicing system :) <mark_weaver>and fyi, using the GPLv3 does not mean you need to distribute it to anyone. <ajgrf>i know, but not distributing it means i don't need to worry GPL compatibility <ajgrf>and the reason it probably won't be distributed is because i doubt it would be useful to anybody else <ajgrf>it's not really general purpose <Jookia1>What is general purpose softwawre anyway who knows <ajgrf>mark_weaver: ok i said i understood before, but i think i just now realized what you really meant. i hadn't even thought of making it GPL but private <sheeple>I'm fairly new to this... How do I remove a service from a list of services? <sheeple>Specifically, I want to remove slim-service from %desktop-services <mark_weaver>ajp: if you keep it private, then you might as well make it GPLv3 from the beginning :) <mark_weaver>only those who possess a copy of GPL'd software have the rights granted by the GPL <mark_weaver>so in this case, that means "only you" before you distribute it <lfam>_`_: Okay, but the point made in his email still holds, if you ask me <lfam>And we had to rush to patch an OpenSSH vulnerability a few weeks ago. <lfam>It's valid to say the state of the art sucks but keep making art. <iyzsong`>sheeple: You can filter it out by '(filter (compose not slim-service?) %desktop-services)' with '(slim-service? s)' defined as '(eq? (service-type-name (service-kind s)) 'slim). Or don't use %desktop-services, and list explicitly :-) <sheeple>iyzsong`: You still here? Because I'm doing something very wrong... <sheeple>I currently have this: (services (filter (compose not (eq? (service-type-name (service-kind s)) 'slim) %desktop-services))) <sheeple>When I reconfigure I'm getting an error due to "Unbound Variable: s" <iyzsong`>oh, I'll do it in a function or lambda. but maybe you should just list what services you need explicitly instead of using %desktop-service. <iyzsong`>my intention is show that it's a bit complex to filter out a service. <iyzsong`>sheeple: in your case, replace (eq? ...) with '(lambda (s) (eq? ..))'. <sheeple>iyzsong`: I'm getting a wrong number of arguments error <iyzsong`>sheeple: can you paste your config.scm into paste.lisp.org? <iyzsong`>sheeple: you got a '()' match wrong, the 'filter' need 2 arguments, one is (compose ...) and another is %desktop-services. <lfam>Is anyone else having trouble reaching the git repository on savannah? <lfam>iyzsong`: Oh well. I guess we have to wait! <lfam>What package provides `top`? <lfam>So many failing sources :( freedesktop *and* x.org <wingo>most fd.o things we can change to https <lfam>It seems they have begun auto redirecting everything to https. Probably a good idea <wingo>for xorg i think mirror://xorg/ works fine <wingo>if there is a package that doesn't use that, it should be updated i guess <wingo>this failing sources thing is a huge pain :/ <wingo>ACTION goes to work instead of fixing it <lfam>It also seems that Savannah's git server is offline <marusich>lfam, indeed, I wasn't able to do guix pull becuase of that earlier <NiAsterisk_>does somebody use GNUS and have an input for me on what I could look into that wide character names, like 宋文武, do not break my layout of group content? iirc there were options for that. ***NiAsterisk_ is now known as NiAsterisk
<NiAsterisk>relativley offtopic, maybe this is better for a GNUS list oder emacs-help <marusich>There is a #gnus channel, also. FWIW, I use emacs with gnus basically out of the box, and that name does not break my layout. <marusich>Perhaps you are not using the best fonts? <marusich>It works for me using font-adobe-source-han-sans, which I installed using "guix package -i font-adobe-source-han-sans". It didn't require any special effort. <NiAsterisk>okay :) I'm not using GNUS out of the box.. hm, I don't have emacs or gnus in general set up to use any font <NiAsterisk>sneek: later tell mark_weaver: thanks for the tip to look into python-2, kyotocabinet did build without errors now <NiAsterisk>but, I can#t test it, as the only software which needs it to build I have is the one I am packaging. it builds without errors, so I assume it will work. <NiAsterisk>if I stash changes in git, and rebase a branch against master, and then I apply the stash again, is this good use? or should I commit before rebase? <NiAsterisk>or just set a branch to track for the current working branch? <marusich>I personally don't use the stash feature very often <marusich>I don't think you need to bother stashing <marusich>When you rebase, you're modifying commits; you're not doing anything with the index or the working tree. <marusich>If you're paranoid, you could stash and also create a branch, or make a backup of your local repo first :) <NiAsterisk>I know the basics, but rebasing is still something I struggle with because I am a bit too careful on what I do. <marusich>well, that's prudent, since rebasing modifies history <NiAsterisk>say I commit what I have now, fetch, rebase against master, and then maybe if needed I do some commit merge stuff.. <NiAsterisk>at most I work on 1 file, but how do people handle 3 or more files? rebase, unmerge, merge again, repeat? <NiAsterisk>all good. I think I'm slowly getting better with git, just using it daily helps ***\\e is now known as exio
***exio is now known as exio4
<mark_weaver>can anyone tell me whether I successfully pushed the glibc security fix to master many hours ago? I lost my internet connection *while* I was pushing it, so I had to go to sleep without sending out any announcement or even knowing whether it went through, and now savannah is being very slow; can't pull either. <NiAsterisk>hm. can't say for sure, last commit I have is 3c98acb <mark_weaver>hmm, even before pushing I saw a commit on master more recent than that one. <NiAsterisk>there's glibc: add fix for cve-2015-7547 in origin/master <a_e>Has anybody else problems updating after the latest security fix? <a_e>./pre-inst-env guix package -u <a_e>lets the CPU run for a while, then it hangs indefinitely. <a_e>I wondered if there was a link to the lack of response from the git repo on savannah, but normally updating should not connect there. <wingo>ACTION updates all freedesktop urls to https <a_e>If now we had git, everybody could profit :-) <mark_weaver>a_e: a "git pull" that I started over 30 minutes ago is still hung. <a_e>There it is probably better to stop and restart. It succeeded in the end for me. <a_e>For me, "guix package -u" hangs even before contacting hydra as far as I know, on two different machines. <a_e>There is absolutely no output on screen. <a_e>Normally it should at least compute the packages to upgrade and then contact hydra for a list of substitutes. <mark_weaver>it might just be that it takes longer than you expect after a core-update? dunno. <mark_weaver>or maybe it's trying to do freshness checks of packages and having network issues <a_e>Ah, that might be it. The freshness checks have unnerved me on a number of occasions. <mark_weaver>a_e: for now, you could comment out the line with "(check-package-freshness package)" in guix/scripts/package.scm <a_e>But even then it normally prints out the name of packages it is looking for. <wingo>ACTION wonders what perl-boot0 is <wingo>heh, it seems to mean the build process has only just begun <wingo>ah damn my https patch introduces an httpss:// <wingo>so secure it will never download a bad tarball <mark_weaver>wingo: the *-boot0 packages are early builds of those things based on our bootstrap binaries <mark_weaver>see gnu/packages/commencement.scm for details of the bootstrap <a_e>mark_weaver: It was the freshness! Thanks a lot. <NiAsterisk>so freenode news.. I hope they bring back tor, that's all I care about for irc. <a_e>Should I file a bug report? If possible, we should add a (relatively short) time-out, or even a command-line switch. <a_e>All this comes at a perfect moment, since I had decided to switch to GuixSD over the weekend. <a_e>But without "guix/git pull", this is quite pointless. <a_e>Hopefully things will return back to normal soon! <a_e>Okay, will send it later. <mark_weaver>wingo: if you use substitutes, you shouldn't need to rebuild the early bootstrap. hydra has built all that stuff for us already <wingo>mark_weaver: just as fast for me to do that than to use hydra, in theory i think, b/c hydra slow, especially across the atlantic. didn't expect to run into these source problems tho <wingo>i usually enjoy using substitutes tho! <mark_weaver>hmm, I think it may be more to compile than you expect, but as you wish :) <wingo>heh, you are probably right, but i am curious, so it's ok :) <wingo>ACTION wishes the topological sort of dependencies would put source downloads first <mark_weaver>wingo: you can use guix challenge later to compare your builds to hydra's and help us find non-deterministic builds <mark_weaver>get your glibc updates, everyone! (although armhf or mips64el users will have a lot of local compiling to do, I'm afraid) <mark_weaver>hydra has built the most popular x86_64 packages, anyway, and i686 is not too much worse. <wingo>you could just merge security-updates and then do a hard reset later <mark_weaver>davexunit: yeah, just "git cherry-pick origin/security-updates" :) <a_e>There is no announcement on the savannah website. Do they know they have a problem? <a_e>Maybe someone in Boston could pay them a visit :-) ***grinhaus is now known as Guest78757
***Guest78757 is now known as wgreenhouse
<fhmgufs>It's really slow and git cloning isn't working. <davexunit>the relevant people surely know about it by now <fhmgufs>I just wanted to clone the guix git repository. ***nckx is now known as nckx|offline
<fhmgufs>keverets: Of course, but I would like to get the git repository. <a_e>It is working for me right now! <a_e>I think it may pay off if you try several times. <a_e>At least git access works intermittently. <NiAsterisk>I tried 20 times i nthe last hours, I doubt it changes if it doesn#t work the first 2 times. <fhmgufs>a_e: Yes, now it's working for me, too. <a_e>So maybe it is repaired now, that would be nice! <ajgrf>`git pull` works for me but not `guix pull` <mark_weaver>yes, at present git access seems to work, but the web interface to the git repo is down, and "guix pull" actually uses a feature of the web interface to pack up a tarball of the current master branch. <mark_weaver>it turned out that the sysadmins were unaware, and nully I think has the day off. only just now did I alert quidam to the situation. <a_e>This is the typical situation where one just assumes that people must be aware and also flooded with requests, so one does not think it necessary to make a report... <NiAsterisk>but people do all kinds of things for profit... I remember a place I worked at for some time, where I had to order and sell a good amount of harddrives from before the floods, only to sell it for +25% or something <fhmgufs>The Guix git binary says 'no git command'. <davexunit>fhmgufs: it's a separate output of the 'git' package ***Nogfson is now known as lainon
<ryuslash>is there someting going on with the gnu server(s)? Guix pull fails <tg>are there no mirrors? <mordocai>tg: I have an unofficial gitlab mirror but it doesn't have the snapshots directory which appears to be necessary for guix pull <tg>mordocai: so what do you need for setting up a proper mirror? someone was asking me with loads of disk space if any project needs a mirror.. <mordocai>tg: Idk, i've only ever setup my "git only" mirror. <mordocai>tg: mark_weaver or davexunit might know if you catch their attention <mordocai>davexunit: the snapshots directory isn't <mordocai>davexunit: well then it isn't just source code, it's source code + running an api :) <davexunit>but it doesn't matter, 'guix pull' can be pointed at any arbitrary tarball url <mordocai>Right, but you need to be making those tarballs <davexunit>pretty much every git web interface can generate these on the fly <davexunit>but again, it's really not important. you do not need to use 'guix pull' at all. <ryuslash>really? If I don't use guix pull I usually can't update any packages <davexunit>most of us just run guix from a git checkout <davexunit>and symlink ~/.config/guix/latest to that git checkout <ryuslash>ah, yeah I think that was recommended to me as well one of the last times I was in here :) <Jookia>Maybe that should be default recommendation until guix pull has better things like rollbacks <ryuslash>If I want to add an extra file to a package like xkeyboard-config, can I do this by creating a new package that inherits from xkeyboard-config and do I have to create packages for all packages having xkeyboard-config as an input as well? or is there perhaps a better way? <mordocai>ryuslash: i'd think modifying the package would be better than creating a new one in this case <mordocai>Super easy to manage package modifications with guix IMHO <ryuslash>any pointers in how I should go about that? <mordocai>ryuslash: I'd imagine the easiest way to add a file would be to add a patch to gnu/packages/patches or wherever that directory is and have the package definition use it. I'm pretty novice at guix compared to many here though. <ryuslash>but that would require me to have a modified version of guix on my system, wouldn't it? <mordocai>ryuslash: Ummm... i'm not entirely sure how precedence work. It might be if you added your own guix package definition directory you could override the guix ones. <ryuslash>thanks :) let's see what I can find about package definition directories <mordocai>That is probably not what guix calls them, but I don't know the term :) <ryuslash>do you know a command-line switch or anything exact I can search for by any chance? <ryuslash>I'll give you as many as you want, I'm thankful for the help :) <mordocai>ryuslash: Took me a bit. look like you can use the -L option to build/package commands or set GUIX_PACKAGE_PATH <mordocai>ryuslash: That manual has a lot of info throughout it on making package definitions and stuff too. Probably be most useful to grab the guix source and look at examples though. <ryuslash>I try looking at the source, but if I don't know where to look it becomes somewhat difficult :) <lfam>Indeed, the manual is a good reference, but most further questions have already been answered in the source tree <lfam>ryuslash: If you are packaging things, almost all the relevant file are under 'gnu/packages' <mordocai>lfam: I get a bad cert error for your link btw, had to switch com to org <ryuslash>that much I know, thanks :) I want to add a custom xkb layout to xkeyboard[config basically and am looking for ways to do that without changing xorg itself :) <lfam>mordocai: Yeah I noticed that <mordocai>lfam: As far as whether 2.12 is vulnerable it seems hard to figure out. As you no doubt noticed, all the distros seem to be using 2.11 so the reports only discuss that version. <lfam>Yeah, I'm going to have to read the source <daviid>I think both browsing savannah source code projects and git.sv.gnu.org are in pain! friday night, too bad! <lfam>daviid: Now we see the benefits of git being distributed :) <lfam>paroneayea: "minimizing the number of requests needed to get a repo" seems worthwile to merge into upstream git, if it's any good. <paroneayea>hydra seems to also be nonresponsive at the moment to me? <paroneayea>maybe I'll hold off on the upgrade till tomorrow <paroneayea>btw asheesh suggested, why not do the builds on some donated servers on digital ocean or some other org that would be likely to donate, since we seem to be able to challenge many packages anyway <paroneayea>seems like a good idea; hydra can farm out ot build machines, right? <davexunit>paroneayea: we already farm out to many build machines. <davexunit>we gladly accept donations of build machines <paroneayea>davexunit: are the substitutes themselves hosted on hydra, or can those be farmed out too? <davexunit>setting up some way to mirror them would be good. <davexunit>moving the nginx cache to another box entirely would also be good. <davexunit>long term, this system should be peer to peer. <paroneayea>is hydra on the same machine as the gnu version control stuff or something? :) <davexunit>but 1) having a real server as the front-end will be a massive improve and 2) having a load balancer with mirrors could improve things further <davexunit>paroneayea: not sure, it's on some FSF machne at MIT <lfam>What I've heard is that the problem with hydra.gnu.org (the front-end) is that its disk I/O bandwidth is *very* low <davexunit>we're a noisy neighbor on that machine. we just need more resources across the board. <lfam>FSF is updating it, and that should make it faster. Maybe this was the maintenance that just ended. Then, we'll get our own machine and it will be much faster.