Re: [gentoo-user] to nest commands
On Tue, 26 Nov 2013 09:58:24 -0500 Randy Barlow wrote: On Tue, 26 Nov 2013 11:52:10 +0100 Hinnerk van Bruinehsen h.v.bruineh...@fu-berlin.de wrote: There are some other options of nesting as well. You can use backticks ` or $(...) to run a command inside another. An example would be emerge `qlist -CI x11-drivers` (or the equivalent emerge $(qlist -CI x11-drivers) ) . This would run qlist -CI x11-drivers (lists installed packages of the category x11-drivers) and use this output for emerge (which will effectively result in reinstalling every package from the x11-drivers category). As I understand it, the $(...) syntax is the preferred way of nesting, as opposed to backticks. I think this may be due to backticks requiring some special escaping that the $(...) syntax does not require. I attempted a brief search for supporting information, but didn't find a definitive source to back up my claims :) The reason for $(...) being preferred is simple: you can nest $($($(...))), but you can't nest `...`. Deep nesting is quite useful indeed. Best regards, Andrew Savchenko pgpv4whI_T8sT.pgp Description: PGP signature
Re: [gentoo-user] Portage performance dropped considerably
On Sun, 26 Jan 2014 16:53:33 +0100 Mariusz Ceier wrote: No, it's not just you, running emerge -uNDvp world takes slightly over 18 minutes on my laptop (i5 M 430 @ 2.27GHz) - and when there was lot to update I had to wait over 1hr to just get the list of packages. I wonder if there's some profiling tool for portage. Also: time FEATURES=-xattr emerge owncloud -v real6m31.202s user2m42.057s sys 2m1.541s time FEATURES=xattr emerge owncloud -v real30m15.632s user22m44.369s sys 5m30.129s 5 times longer - for something that's essentially copying files. Slow xattr is a known problem, see bugs 482290, 465000: https://bugs.gentoo.org/show_bug.cgi?id=482290 https://bugs.gentoo.org/show_bug.cgi?id=465000 But xattr bug shows itself during install phase and has nothing to do with dependency calculation time mentioned in the original mail. Best regards, Andrew Savchenko pgpZwwW6J9EA7.pgp Description: PGP signature
Re: [gentoo-user] Re: Portage performance dropped considerably
On Sun, 26 Jan 2014 20:30:19 +0200 Alan McKinnon wrote: It comes from watching what happens at the end of running emerge, don't read any more into it than that. Especially not optimism, I think you might be projecting your own frustrations. A couple of years ago I used to have to manually resolve blockers about one world update in two. It started becoming a huge PITA especially as the deps are usually easy to solve - if I can look at the screen for a few seconds and figure it out, then software can do the same in milliseconds. Recent portages now do this properly when viewed from a results-only perspective. On my machines, that is what I see happening. That is the ONLY set of FACTS I have to work on; you may have more. I'm willing to give up 4 minutes while emerge runs so I don't have to spend many more minutes right afterwards doing manually the very shit that software is very good at. Whether portage is a complete pile of dogshit software or not is beside the point. Even if it is, my 4 minutes still buys me lots shrug 4 minutes are expendable but... on Atom N270 (my laptop) emerge -DNuav world takes 40 (yes, forty) minutes to build dependency tree with sqlite cache enabled and 60 minutes without sqlite. System was pretty old (not updated aside from GLSA updates for a year). And this 40 minutes repeated many times since USE flag clashes and dependency resolution failures. So I spent may day, damn whole day(!) for the sake to just start compiling (distcc is my friend here). Best regards, Andrew Savchenko pgpnG9flBECe4.pgp Description: PGP signature
Re: [gentoo-user] Re: Portage performance dropped considerably
On Fri, 31 Jan 2014 19:13:21 + Mick wrote: On Friday 31 Jan 2014 19:03:05 Andrew Savchenko wrote: On Sun, 26 Jan 2014 20:30:19 +0200 Alan McKinnon wrote: [...] I'm willing to give up 4 minutes while emerge runs so I don't have to spend many more minutes right afterwards doing manually the very shit that software is very good at. Whether portage is a complete pile of dogshit software or not is beside the point. Even if it is, my 4 minutes still buys me lots shrug 4 minutes are expendable but... on Atom N270 (my laptop) emerge -DNuav world takes 40 (yes, forty) minutes to build dependency tree with sqlite cache enabled and 60 minutes without sqlite. System was pretty old (not updated aside from GLSA updates for a year). And this 40 minutes repeated many times since USE flag clashes and dependency resolution failures. So I spent may day, damn whole day(!) for the sake to just start compiling (distcc is my friend here). Out of interest what fs are you running portage on? I changed an old box from reiserfs to ext4 and couldn't believe the speed up I got. I use ext4. In my case the problem is in CPU usage and Atom N270 is pretty weak these days. On this box HDD is fast and NCQ capable, memory is enough (2GB for 32bit setup). During dependencies calculation all 100% of time is spent in the python process. CPU is slightly overclocked (as much as SHE allows). There is nothing more that I can do here as an admin of this host. (Gentoo setup itself is complicated with 2200 packages.) IMO the only way to improve this issue (without throwing good working hardware in the window) is to rewrite dependency resolution code in some highly optimized pure C library (probably with some asm code) and to use this library via some python binding from portage. But I suppose algorithm itself should be reviewed first. Best regards, Andrew Savchenko pgp9TEWZL3PYu.pgp Description: PGP signature
Re: [gentoo-user] Re: Portage performance dropped considerably
On Sat, 01 Feb 2014 00:12:58 +0200 Alan McKinnon wrote: and to use this library via some python binding from portage. But I suppose algorithm itself should be reviewed first. ^this is where the speedups will lie 4 minutes on this here i7 monster and 40 on your Atom is ridiculous considering the problem that is being solved. Portage is probably searching and re-searching dead paths in the tree or something equally silly. The algorithm should be analysed and dead paths optimized away. Not a language problem. Another challenge is to make dependency resolution parallel — result should be awesome on modern multi-core CPUs. And I'm sure this is a doable task (on a first glance analyse subtrees first then join), but this issue requires further and deeper investigation. Best regards, Andrew Savchenko pgpzv2pb2yd7N.pgp Description: PGP signature
Re: [gentoo-user] blocking -systemd
Hi, On Thu, 6 Feb 2014 11:49:41 -0700 Joseph wrote: I have in make.conf USE: ... -systemd But gnome-base/gnome-settings-daemon wants to pull in systemd-208 so I need to emerge sys-apps/systemd-208-r2 and I have installed udev which conflicts with systemd. Do I need to unmerge udev and emerge systemd. I'm not planning on switching to systemd after recent experience. So I was planning on avoiding it but I don't know if I can. You can add openrc-force US flag to your make.conf. This way you will drop systemd dependency, though you may loose some run-time functionality of gnome. Other alternative is to add sys-apps/systemd to package.provided, though the effect will be the same as above. And you may switch to some other DE/WM of course. Best regards, Andrew Savchenko pgpc2mNVuTez1.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote: On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 16.02.2014 21:08, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [ snip ] or it is an idiotic decision. Because features means complexity. Yeah, like the kernel. Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. You didn't answered this, did you? Bugs are different. Bugs in the critical system components are critical to the whole system. If Libreoffice or browser segfaults, some data may be lost and inconvenience created, but the system will continue to run. If PID 1 segfaults — everything is lost, you have a kernel panic. That's why critical components should be as simple and clean as possible. SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. no, it isn't. How are those binaries talk to each other? dbus, which is about to be integrated into the kernel with kdbus. And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), anyway it is possible to disable this stuff in kernel and guess what will be done on my systems. Looks broken. Broken by design. The worst form of broken. By your opinion, not others. That is not just an opinion. There is a science and experience behind system's design. And all that science was ignored during systemd architecture process if there was any at all. Best regards, Andrew Savchenko pgpPqKWNVnvHI.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 11:13:39 -0600 Canek Peláez Valdés wrote: It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). You are setting a group of conditions that preemptively wants to stop adoption of anything that is tightly integrated. That is a losing strategy (different projects actually *want* tight integration), and besides the burden of work should not fall on the people wanting to use a tightly integrated stack. You want individual modules that are easily and simply replaced? Then WROTE THEM. Don't expect the systemd authors (or any other) to do it for you. And here we have a small problem: for modules to be replaceable the core system should be designed to support replaceable modules, but systemd is not. The whole deep integration approach and lack of inter-module boundaries doesn't allow one to write replaceable blocks without crazy hacking. Just imagine that one have PCI-E bus and this bug is being replaced with some other PC-systemd bus, where one have to interface each component differently. And if one removes e.g. audio card some other seemingly independent component e.g. network controller becomes broken. That is the nature of systemd and that is many people dislike this technology. That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Some of those packages *could* be made to switch functionality at run time instead of compile time, but SOMEONE has to write that support, and it's probably that the upstream for the package will not accept those changes, since for binary distributions it makes no sense to have the complexity on the code of switching behavior at runtime when doing at compile time is easier and the distribution generates one binary per architecture for all its users. The most sane and fair solution was already proposed: create a systemd profile for those who need it. I personally highly dislike systemd technology, but I respect the right of other to shoot them in the leg (or head) as much as they want to. This is Gentoo: a universal constructor providing people means to build any system in any shape they need. Unfortunately chances are that in future some software may become unusable or unsupported outside of systemd profile. But patches may be created and other profiles will continue to live the same way hardened exists now and will continue to exist later. BTW it was shown at the recent LVEE Winter 2014 conference that GDM can be easily freed from systemd and OpenBSD guys have an interesting idea for faking systemd presence for applications requesting one mandatory. Though IMO any end-user application strictly dependable on any init system is broken by design: for a daemon there should be no difference by which tool it was started. In fact, it seems to me that, since (from what I've read) the primary reason that systemd was written in the first place was to provide extremely fast boots *in virtualized environments*, You are wrong; systemd was created because Upstart had the silly CLA from Canonical[1], and because its authors wanted a novel init system for Linux (and Linux only) that used all the cool technologies the kernel provides, and that it could solve problems like: how to easily and consistently start daemons with well defined semantics for its dependencies; how to easily and consistently apply resource quotas to them; how to deal with modern computers where hardware comes and goes (including CPUs) all the time, etc. [2]. Excuse me please, but what you wrote above is very naive. All that reasons are just an excuse. The real reason is money: systemd is a Red Hat project (despite being formally open for everyone) and is their tool^Wweapon to fight with Canonical for a sales market. It the last years RH was pushed near even in a server market and now they are fighting back. They were lucky enough to acquire Poettiring guy and create from a simple and sound sysvinit (which is an important but not dictating peace of software) a key component where they can dictate their own line, where they can lead all Linux community in a way they need. That the real reason I despise systemd: in replaces the freedom of choice by a dictatorship of a small bunch of managers of a single corporation (yes, managers, not developers). And all this is under the veil of GPL and technical merits. This is the poison in the well of FOSS. Best regards, Andrew Savchenko pgpNXWRgUgRgH.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 14:52:33 -0500 Tanstaafl wrote: On 2014-02-17 12:52 PM, Andrew Savchenko birc...@gmail.com wrote: And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), anyway it is possible to disable this stuff in kernel and guess what will be done on my systems. Forcefully? Are you saying that *anyone* can *force* Linus to put something into the kernel? OK, my choice of words was not appropriate. I mean that not every kernel dev is happy that kdbus is in the kernel now. I'd also really, *really* like to hear a *recent* opinion from Linus on systemd... Judging from his previous opinions this one is unlikely to be systemd- friendly. Best regards, Andrew Savchenko pgpoH_OQWnQcJ.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 19:09:40 -0600 Canek Peláez Valdés wrote: How Integrated? The TCP/IP stack *is* integrated. But it is *protocol* integration, *standards* integration not *software* integration. You do want tight integration where it just can't work otherwise, but the design of Unix provides (well, again repeating this), and almost any robust design should provide, the ignorance of one abstraction level about another. Why HAL? Why udev? Why drivers as modules? Why not just go and integrate all stuff into the kernel, well (again!) like MS do, and don't please say I compare wrong things just because MS is not OSS. You make a wrong comparison, because MS is not free (libre) software. With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we have been able to try new technologies (and see that some of them fail, like HAL [yuck!]), because we have the source. But the comparison is quite right. When one have to deal with software lock-in, this means that one have to fork a huge stack of software which is theoretically doable (because software is free), but is impractical unless one owns a corporation with large number of full time paid developers. The same way one in theory can change everything in MS by changing assembler code of their software. Well, this will require some time, but asm is nothing more than low-level programming language, thus formally one have the sources. The key feature here is deliberate and malicious lock-in: as long as software enforces one, it is non-free in practical terms. As you said, you can replace the whole of Linux if you so desire (and have the technical ability). You will never be able to do that with any MS software, and so the comparison makes no sense. Hey, but people are already doing this! Google for ReactOS or Wine. The thing (and that's also my point), apparently *most* of the people willing and able to create cool software have decided that systemd is the way to go. And, even if you want to attribute that to a simple monetary issue, most of them do it *happily* because many things are just easier to do with systemd. Most people should never care what init system is in charge while writing end-user software. If software (e.g. some daemon) depends on specific init system, it is broken by design. They'll be able to stuff everything into it, making effectively a thing in itself which will dictate you where to go and what to do, just because you're not technically competent enough to deal with it -- hence more support calls and more $ etc etc. Oh, but nobody will be able to do that to me. I know how to write code. I'm willing (and I believe able) to write and/or modify software if I don't like how it does things. I've done it before; I could do it again. Even if you have superior and outstanding programming skills I doubt you have time and resources to rewrite the whole software stack (e.g. systemd and everything depending on it) yourself. If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE it would happen. But don't complain if no one does, and it doesn't. That's your point -- and mine. We aren't complaining -- we want to prevent this. Prevent what? People writing new software that offers cool features, and therefore distros are using them? Prevent loosing our freedom in practical sense: while the software will be still free in FSF license terms, it will be so locked onto itself that it will be eventually impossible for anyone besides large corporations to replace it. Thus in the end we'll be dictated what to do and how to do. The forward-looking people must unite, it may sound ridiculous, against systemd You cannot stop people for writing new cool stuff, nor distros for wanting to using them. You CAN write your own cool stuff, and convincing people that is better than the alternative. And you can't force people to use your cool stuff because you're assuming it is cool. That's called freedom, freedom of choice. That is what I love Gentoo for. That's why I support systemd profile propose. That's why I will do my best to protect this freedom in our community. You know what it is: everything's free but nothing to choose from. We had it before, it's called communism. Maybe it is not that bad but we don't want it anymore. (Really? A cold war reference?) Yes, we have a software^Wcorporation war right upon us. Best regards, Andrew Savchenko pgpwNStDaxmGV.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, 18 Feb 2014 11:46:14 +0800 Mark David Dumlao wrote: init scripts, in general, are ad-hoc, quirky, and incomplete implementations of service supervision in bash. They're reliable so long as the daemon can be relied on to advertise one or all of its processes in a pid file. Thing is, there are way too many different possible setups for services for that to be the case. In the average case watching a PID file works. And since most people use average software, most people don't care. That's ok. Thing is an init isn't just for most people. It's for all people. It should be reliable for all services. I used to use cherokee. Fast, light, awesome, and with a web admin. The init script always failed me. /etc/init.d/cherokee stop was not a guaranteed stop to all forked cherokee processes - the parent pid dies, but some forked process or something, usually related to rrdtool, doesn't. Or the parent does exit and erases the pid file but it returns control immediately and its not yet done exiting. Something like that or other. Point is, I've several times had to ps aux|grep ... kill; zap; start - on production servers. Was it cherokee's fault? Maybe. But the init script should have told me that. Or even better, the init script should have done its job and terminted the processes. See, pid files are just a proxy, they don't work for all services and all setups. Maybe a process crashes before it kills its forks. Maybe the server has a restart feature that fails to write the pid file because the init script created it as root but the daemon relinquished privileges. Maybe there's a bug somewhere. Maybe the pid file gets overwritten accidentally. Maybe the pid file is stale because of a power failure. Point is you don't know until the service restart which should just take a sec costs you maybe an hour or two in billable time. With supervised cgroups that's not a problem. Because all process forks are grouped together, it doesn't matter if there's a pid file or not. When its kill time, the daemon and all forks and children go down. Because they're dynamically created on start, they don't get stale or point to the wrong process. Sounds to me like the right tool for the job. I agree with you. But openrc has cgroups support now for each service started. Thus systemd is not the only solution solving problem you described above. Best regards, Andrew Savchenko pgpPRQOqUQGFy.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 18:35:34 -0600 Canek Peláez Valdés wrote: [...] Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. You didn't answered this, did you? Bugs are different. Bugs are bugs, period. And they get reported and fixed. Bugs are not equal. They differ in at least two dimensions: significance depending on the component affected and severity of the bug itself. Bugs in the critical system components are critical to the whole system. Yeah, that's why we have unit testing and QA teams and stable and unstable releases, etc. Every decent project has QA and unit tests one way or another. But the larger project is, the more bugs it has. And I do not want bugs in PID 1, that's why it should be small and sound, not bloated (even with some components split as separate binaries) and broken by design. If Libreoffice or browser segfaults, some data may be lost and inconvenience created, but the system will continue to run. If PID 1 segfaults — everything is lost, you have a kernel panic. And the world will end? The same happens if the kernel has an error. Kernel has mature error correction infrastructure (Oops handling) and much wider community. That's why critical components should be as simple and clean as possible. Like the kernel? You call that simple? Don't mix user space and kernel space, please. There are more secure by design micro kernels out there (like Hurd), but they're out of the scope of this discussion. I'm sorry, but you are (IMO) wrong: critical components should be thoroughly tested and debugged, and have integrated unit testing, and a large enough group of volunteers to test new releases before they go into the general public. You're pointing to valid issues, but not to the whole picture. Critical components should _start_ from good design, sound modular architecture and _then_ with QA and testing. You're omitting the most important stuff, though. SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. If you take into account the thousands of shell code that SysV and OpenRC need to fill the functionality of systemd, they use even more. If that code will fail, this wouldn't be critical at system level. Thus scope of fatal error is limited. Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. I don't care about probabilities; I care about facts: FACT, I've been using systemd since 2010, in several machines, and I haven't had a single segfault. FACT: almost no bug report in systemd involves a segfault in PID 1. You need facts? Here is one for you (systemd-208): http://fly.osdn.org.ua/~mike/img/misc/systemd-segfault.jpg Looks broken. Broken by design. The worst form of broken. By your opinion, not others. That is not just an opinion. There is a science and experience behind system's design. Yeah, what do you think about Greg Kroah-Hartman, Linus' right hand, or Keith Packard of X.org fame? None of them works for Red Hat; both of them know more about Unix and Linux than you and me together, and both of them promote systemd. I respect Greg for most of his work, but this doesn't mean he is an oracle we need to adhere to. But in FOSS reputation is not that important, though clean technical reasons are. And all that science was ignored during systemd architecture process if there was any at all. You should read systemd-devel and Lennart's blog posts before saying something like that. I did. I read that blog. No valid reason were found (if we're comparing systemd to what is outside of systemd's world, not only to bare sysvinit). But what I found it that blog is a lack of thorough project design (it looks like many components were added by the fly without preliminary planning) and a lot of religious statements. Best regards, Andrew Savchenko pgpko_nMZl2xr.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, 18 Feb 2014 04:05:03 +0200 Gevisz wrote: I mean, I myself know a thing or two about computing and Linux, and I promote systemd (and nobody pays me, BTW), but obviously you don't need to believe in my credentials. I have said you, he is just an unpayed fanatic systemd promoter! Frankly, I have doubts he is unpayed. Though as long as arguments are technical this doesn't matter. Though when arguments are down to Said who? Listen to the Oracle! it starts to. Best regards, Andrew Savchenko pgp3mkVhNVMFr.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 23:30:42 -0600 Canek Peláez Valdés wrote: On Mon, Feb 17, 2014 at 8:05 PM, Gevisz gev...@gmail.com wrote: [ snip ] How can you be sure if something is large enough if, as you say below, you do not care about probabilities? By writing correct code? Real world code without mistakes and larger than Hello, world! exercises is not possible. Large systems must have error suppression and correction techniques, modular and replaceable design is one of them, KISS is another one. Systemd has none known to me. I don't care about probabilities; If you do not care (= do not now anything) about probabilities (and mathematics, in general), you just unable to understand that debugging a program with 200K lines of code take 20!/(1!)^20 more time than debugging of 20 different programs with 10K lines of code. You can try to calculate that number yourself but I quite sure that if the latter can take, say, 20 days, the former can take millions of years. It is all the probability! Or, to be more precise, combinatorics. My PhD thesis (which I will defend in a few weeks) is in computer science, specifically computational geometry and combinatorics. You're not the one here on the list with PhD (either defended or near its end). And argument Listen to me! I'm PhD here! looks miserable. Please stop this. I care about facts: FACT, I've been using systemd since 2010, in several machines, and I haven't had a single segfault. Have you ever tried forex? If yes, you should have been warned that no past performance guarantee the future one. I never said that. I trust the quality of the code, measured by my own judgment and bug reports, etc. Not past performance. And even if a bug goes by, then what? The world will end? This depends on what bug at what component occurred. Just imagine pid 1 segfault on medical life support equipment. With systemd going into embedded this is not just pure speculation, though, of course medical stuff should have extra safeguards. But any FT or at least HA setup is a combination of multiple layers. I do not want to allow badly broken core component on mine setups even if its faults may be compensated by other means. Yet again, I respect ones right to use whatever one wants, but I ask to respect mine as well. That's why I propose a separate systemd profile for those willing to use it. Sorry, but it's you who doesn't know the matter at hand: kdbus was (and is) written by Greg Kroah-Hartman, Linus' right hand, and who works for the Linux Foundation. Lol, he seems to start to use the arguments like You even do not know my elder brother/acquaintance from the street nearby who can easily hit you down! If you don't think Greg's words have any weight in a Linux-related technical discussion, then I'm afraid we will need to agree to disagree on any technical subject. You know, common sense should always override person's prestige. History knows many examples. Sir Isaac Newton enforced corpuscular point of view on the light's nature. And while he was genius in other physical aspects, he was mistaken here. Albert Einstein was rejective to probabilistic nature of quantum mechanics and even proposed an entangled particles paradox as an example of its flawed nature. Though as we know these days such systems exist and are quite well used in numerous experiments. My point is simple: do not blindly adhere to someone's words, even if this person has high authority. Common sense must prevail. Period. Best regards, Andrew Savchenko pgpdeThnp3qdq.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
and able to produce a compatible replacement: logind works with a dbus API, so it's (in theory) *easy* to duplicate its functionality. Ubuntu has been working in a replacement, but (AFAIU) is not finished. And logind hardly depends on systemd . That's why Gnome depends on systemd. The real reason is money: systemd is a Red Hat project (despite being formally open for everyone) and is their tool^Wweapon to fight with Canonical for a sales market. It the last years RH was pushed near even in a server market and now they are fighting back. Nice conspiracy theory you have going on. You may call facts as like as you want to. This will not change them. They were lucky enough to acquire Poettiring guy and create from a simple and sound sysvinit (which is an important but not dictating peace of software) a key component where they can dictate their own line, where they can lead all Linux community in a way they need. And it gets better. Citation needed? Any hard proof? Citation for what? You're free to analyze fact and trends yourself. That the real reason I despise systemd: in replaces the freedom of choice by a dictatorship of a small bunch of managers of a single corporation (yes, managers, not developers). And all this is under the veil of GPL and technical merits. This is the poison in the well of FOSS. I don't work for RedHat; I teach in a University. Nobody pays me for using systemd; I just choose to because I think is a technical sound solution for the chaos that was the plumbing layer in Linux. This chaos is called freedom, freedom of choice, which leads to diversity, evolution and security. With every system unified in its core component we'll have a nice single and easily targeted point of failure. With systemd on most Linux distributions viruses (in terms of self-spreading windows malware) are just a matter of time. If this folly will not be stopped before it's spread you may recall my words in about five years. The technical merits and advantages of systemd are there in the open for anyone willing to study a little about it. *After* you carefully read the code, the documentation, and test the software in real life, you *may* still think you don't like the software or its design. Believe me or not, but I tested it, I read its docs and I studied its code. I vomited. There are two major types of failures: design failure and implementation failure. I'm tolerant to implementation issues, anyone have them after all. But monolithic deeply integrated approach is flawed by design. Even this issue can be tolerated as long as project is supposed to be compatible and replaceable with other solutions (remember, everyone has right to shoot oneself in the leg). But if project is being aggressively enforced, this is no way to go. Best regards, Andrew Savchenko pgpOjpSt4fW_y.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote: Yet again, I respect ones right to use whatever one wants, but I ask to respect mine as well. That's why I propose a separate systemd profile for those willing to use it. Then write. Just be aware that to write a systemd profile, you need to use systemd. Or to create a non-systemd profile :) Best regards, Andrew Savchenko pgpKEksCQfVOx.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Wed, 19 Feb 2014 10:19:43 + thegeezer wrote: [...] For all this talk about technical details, nobody seems to notice the marketing A few people including myself have noted it earlier. that's going on and frankly it disgusts me. And me too. I have to confess that it does feel very evangelistic the approach from folks pushing systemd. perhaps it is just because for some it has been four years of looking at new ways of doing things, whilst others are just realising now how different it is. I saw an interesting blog post [1] that basically tried to convince directly gentoo devs. it was interesting because of this comment: snip *Simon* September 26, 2013 at 2:58 am https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/comment-page-1/#comment-756 Yes, I think you’re dead on, there. It’s not that Gnome depends on systemd – but it’s increasingly dependent on features that are only provided by systemd. The example of OpenRC not behaving according to GDM’s assumptions is a perfect illustration of that. It’s dependent not on systemd, but on something that for practical purposes is indistinguishable from systemd /snip It looks like systemd PR agents put it quite simple: my way or the highway. And it looks like Gentoo is the last major shelter for freedom we have. the difficulty is that without knowing what features are required but assumed to be there it becomes very difficult to build something the has the API that logind or others might be requiring.an update of gnome might require a new feature that is hot off the presses, and until it breaks an openrc-logind system no one is aware of that requirement. the API does seem to be online [2], albeit updated 30days ago; i can't comment if this is up to date enough or not. I think the argument on the blog page is a bit disingenuous too - essentially implying that if you want gnome then you must have logind, and if you want logind you must supply the features supplied by systemd: but to get a list of the features required is _your_ problem: go through the gnome source code to find out. these kinds of things are what folks are taking umbrage against. I'm also a little confused over the socket matrix feature. I think it's very clever to be negotiating and buffering socket and mounts to services that need them, but I haven't seen a good technical argument as to why this is required. From my perspective i see it as xinet.d for unix sockets and well, is anyone using xinet.d on a production server? Hopefuly someone can enlighten me? also what happens if the socket arbitrator dies ? 1. We never use xinetd on either production systems or desktops/laptops. The only legitimate setup with xinetd I can recall is CVS server. Though the very CVS technology is obsolete this days (yes, I know portage tree is still using it and I'm looking forward for git migration). Socket activation feature is dubious at least. It looks like nobody from its developers cared to assume that services may start not as fast as they expect (e.g. network issues with cisco switches being too slow to answer dhcp which may take up to several minutes). That's why socket activation is extremely dangerous: it may cause services to fail _on_ start. Some may just crash and will be restarted (though not all services may be restarted after crash without manual interaction, e.g. some DB setups may fail badly), while other may loose some functionality and continue to work. Best regards, Andrew Savchenko pgpgPnRlfgeDk.pgp Description: PGP signature
Re: [gentoo-user] Why WordPress is masked?
Hi, On Wed, 19 Feb 2014 16:54:12 +0200 Gevisz wrote: After emerge --search wordpress, I have found that this package is currently masked (at least for amd64 architecture). The same says https://wiki.gentoo.org/wiki/WordPress Earlier, in this mailing list, I was told that I can see the reasons for masking a package in .../profile/package.mask file. However, looking into it, I have not found there the wordpress package at all. Does anybody know, why wordpress package is currently masked and how dangerous it is to unmask it as the wikipage above advises. Wordpress is not masked on my ~x86 and ~amd64 boxes. Probably you have stable amd64 setup. Unmasking is generally safe in such cases, though if you'll mix stable and unstable packages too much you may have unforeseen consequences. Best regards, Andrew Savchenko pgpdKbIpCtX_5.pgp Description: PGP signature
Re: [gentoo-user] Fwd: How about the gentoo server or cluster in production environment?
Hi, On Thu, 20 Feb 2014 07:40:59 +0800 Franklin Wang wrote: I'm not familiar with gentoo server and cluster. So could you tell me the experience about them? Thanks. We have successful experience with Gentoo on both production servers (someone call this area enterprise, though I dislike such name) and HPC setups. In short, Procs: - fine-tuned setups; - really large choice of components; - high-performance setups (especially rocks for HPC); - reduced attack surface; - nontrivial attack surface; - large system updates easy (comparted to e.g. RHEL4 - RHEL5 migration); - easier to add and maintain out-of-tree software. Cons: - much longer time for initial setup; - harder to apply routine updates; - poorly suitable for tasks like: create me this new service ASAP (for which you don't have prepared images), preferably yesterday. Other notes: - requires more qualified personnel to maintain. Best regards, Andrew Savchenko pgpkbel_Wkp06.pgp Description: PGP signature
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
On Thu, 20 Feb 2014 11:29:52 +0100 Nicolas Sebrecht wrote: The 20/02/14, Nilesh Govindrajan wrote: Gentoo makes the best server os because it's a custom built os where the admin knows each and every aspect of the os. Security wise, there are no unwanted or unused stuff, so lesser bugs to deal with. While I agree with the less code is less bug argument, I disagree with your point. Tuning softwares mean that the binaries compiled on a machine are less used in the wild (other Gentoo systems have other hardware, enabled use flags, etc). Hence, the binaries executed on you local server are likely much less tested by others. And this point is one of the highest security benefits in real world: one have non-standard binaries, not available in the wild. Most exploits will fail on such binaries even if vulnerability is still there. This will cut-off most off automatic botnet attacks even without additional security measures like hardened setup, PaX or GRSecurity (yeah, I never trusted SELinux because of its main author: sane agency will never release a security tool which can be a hinder to this agency). Of course, if system is specifically targeted by qualified professionals, this will only hinder their approach, but binary based distributions will not provide any advantage here either. Best regards, Andrew Savchenko pgpdyWR4NlZ8L.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Fri, 21 Feb 2014 11:36:15 +0800 Mark David Dumlao wrote: [...] So, please, don't take it as an insult. In fact you have done a very good job of patiently spelling out the advantages of systemd, to the point I'm no longer afraid of it taking over and devouring the linux world. If systemd truly is, as you say taking over and devouring the linux world such that the majority of distro maintainers are individually choosing to use a feature or two from it, then yes, it definitely is the job of people who want to opt out of it to do the work. If Gnome wants systemd, and you don't, but you want to continue using Gnome, it's _your_ job to look for a method or patch or package or script that makes it work. 1. I do _not_ want to use Gnome (and never used it) as DE. 2. Someone called Lennart was a long-time Gnome contributor before Gnome required systemd without alternative. Coincidence? I don't believe in them. I trust probabilities and statistics. If udev wants systemd, and you don't, but you want to continue using udev, it's _your_ job to look for a method or patch or package or script that makes it work. We have eudev fork which is clean from systemd crapware and works perfectly on production setutps. If foo wants systemd, and you don't, but you want to continue using foo, it's _your_ job to look for a method or patch or package or script that makes it work. If everybody else wants to use systemd but you, it's your job to keep your system working the way you want to. Nobody else requires systemd mandatory now as to my knowledge. Nobody's going to go out of their way to specifically and targettedly break your system, because you don't like their way. However, you can co-opt some package maintainer's way and say he's obligated to make a pure and systemd uncorrupted system for you. Because he's not. Bottom line: since Gentoo's default and primary init system is (and hopefully will be for a very long time) OpenRC, it is on the systemd folks to do the work to get systemd fully supported. systemd IS supported and working. The problem arises when there are people that want to push for a system with no systemd whatsoever and act like it's the systemd maintainer's job to make that happen. OpenRC is default in Gentoo now, and it is my best hope it will be. Thus anyone willing to use something else should do an appropriate job. Best regards, Andrew Savchenko pgpiEf5yXsVgJ.pgp Description: PGP signature
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
On Thu, 20 Feb 2014 18:08:43 -0600 Daniel Campbell wrote: It's marginally clever, but so clearly obvious at the same time. It's sad (to me) that the community didn't see it coming. Those who did have been written off as conspiracy theorists or FUDders. Time will reveal all. Indeed time reveals everything and part of this foiled plot revealed itself two days ago. It was said earlier in the list by systemd supporters, that this project is modular, fine split to binaries and thus critical issues in the pid 1 are not that likely. And just look at systemd-209 release notes: http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html [quote] We merged libsystemd-journal.so, libsystemd-id128.so, libsystemd-login and libsystemd-daemon into a a single libsystemd.so to reduce code duplication and avoid cyclic dependencies (see below). [/quote] So all talks about systemd being modular are nothing more than nonsense. Guess what will happen on segfault in libsystemd.so? Segfaults in pid 1 are so nice to bear... And Canek please talk no more about how talented systemd programmers are or even about how professional they are, because they're no longer. They failed a trivial textbook example: what should one do when libraries A and B have some common code and cyclic deps? Push common code to library C. That's the Unix way and secure way. Creating single bloated library will help in neither fencing nor debugging, nor code audit. It looks like to me that ultimate goal of systemd is to consume as much system and user tools and interfaces as possible. Perhaps, in the ideal systemd world there will be nothing but linux-systemd kernel and systemd-stuff userspace. Shell communication will extinct, all major application and daemons will be converted to systemd modules. Of course this goal will be never achieved as-is, but one may consider it as an asymptote of their actions. Best regards, Andrew Savchenko pgpef2uhhHI0s.pgp Description: PGP signature
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
On Thu, 20 Feb 2014 21:41:03 +0100 Nicolas Sebrecht wrote: On Thu, Feb 20, 2014 at 08:52:07PM +0400, Andrew Savchenko wrote: And this point is one of the highest security benefits in real world: one have non-standard binaries, not available in the wild. Most exploits will fail on such binaries even if vulnerability is still there. While excluding few security issues by compiling less code is possible, believing that non-standard binaries (in the sense of compiled for with local compilation flags) gives more security is a dangerous dream. Any decent security setup contains multiple layers of protection. Use of non-standard binaries, algorithms or implementations is just one of them and it is the simplest math to prove that security is _improved_ this way. Nobody says that system became _acceptably_ secure _only_ by using this techniques. Best regards, Andrew Savchenko pgpRPR7k1tXEj.pgp Description: PGP signature
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
On Thu, 20 Feb 2014 22:59:59 +0200 Alan McKinnon wrote: On 20/02/2014 22:41, Nicolas Sebrecht wrote: On Thu, Feb 20, 2014 at 08:52:07PM +0400, Andrew Savchenko wrote: And this point is one of the highest security benefits in real world: one have non-standard binaries, not available in the wild. Most exploits will fail on such binaries even if vulnerability is still there. While excluding few security issues by compiling less code is possible, believing that non-standard binaries (in the sense of compiled for with local compilation flags) gives more security is a dangerous dream. +1 non-standard binaries is really just a special form of security by obscurity. Or alternatively a special form of no-one will eva figure out my l33t skillz! Mwahahaha! Exactly. This is security trough obscurity. I never claimed this is an ultimate or a sufficient way to protect a system. But this is just a single of many multiple layers which can be used to provide acceptable security level. Which is a very poor stance to take. The total amount of code not compiled by setting some USE flags off is on the whole not likely to be very much, and hoping with finger crossed that the next weakness in a package will just happen to fall within a code path that got left out by USE flags is a fools dream. You mare compare binary sizes for e.g. openldap (and all its libraries) with minimal and full (USE=-minimal *) setup. Quite impressive, not to count all external so libraries involved. I'm glad you mentioned this Andrew, because the internets are full of stupid advice like this non-standard binary nonsense. Are you considering Bruce Schneier's advice as a stupid nonsense? In his Applied cryptography he recommended one of the ways to straighten a system: to use not so frequently used algorithms instead of selected standards because less frequently used algorithms has no better math but are less targeted, have less specialized hardware built to crack them and so on. Yes, the arguments at face value are difficult to refute with hard facts, but those that do not known it is stupid are easily led into a sense of false security, doesn't matter how many disclaimers are tagged on the end. I reckon it's the duty of all knowledgeable sysadmins to stamp out this crap HARD every time it raises it's head. To the user who brought it up - this might seem overly harsh but I've yet to find a better method that actually works and gets through to people. I never talked about a sense of security just because system has non-standard binaries. I talked about high variance which brings a _bit_ more security. And I'm talking not from some theorizing, but from practical experience on both ends (data protection and legitimate system forensics). Have you ever considered how systems became broken in the wild? The most common way (in numbers of hosts, not significance) are automated robots and botnets. They just scan the net, try to bruteforce any login service they found and try to apply any exploit appropriate from their database. If one have a widely used and improperly configured (or not timely updated) setup, it will be hacked this way. The key point of any attack is *cost*, is *money* one needs to spend for an attack. Automated attacks are cheap and such _simple and cheap_ measures as obscured binaries and non-standard (e.g. ssh) ports will stop most of these attacks. This way it will cost _more_ for the attacker to break into protected system and with raise of an attack cost system protection level also rises. Of course, obfuscation is _not_ sufficient for system protection. This is just one small step forward. I don't want to discuss full scope of server protection issues, because this is far out of the topic of this discussion and because measures needed are task- dependent. However I want to notice one critical security issue quite common for production servers: an old software. It doesn't matter how many protection layers system have, how skilled person configured it was. When software is old it is quite trivial to look up for CVEs and break the system. Quite practical encounter from my own experience: I was asked to legitimately obtain root on the box (admin forgot password, reboot (with init=/bin/bash) was not an option and root access was needed for reconfiguration); a box was a year old RHEL with SELinux enforced. Third kernel exploit worked perfectly (I just found them on the net, not bothered to code myself). Such trivia with Gentoo and its custom binaries is not possible. And Gentoo is quite good with recent software updates (RH sometimes is too slow with critical kernel/libc issues). Old software is evil. It doesn't matter how good and tested it _was_. Variety and diversity are quite important for real word systems protection. Of course, it is possible to break _any_ box on the Earth, the only question is how high the cost will be. My point is that Gentoo provides native
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Fri, 21 Feb 2014 16:40:46 -0600 Canek Peláez Valdés wrote: Of course the larger a project is the *potential* number of bugs increases, but so what? With enough developers, users and testers, all bugs are *potentially* squashed. Agreed, but I know of enough large projects with large development teams and even more users that don't get the most basic bugs fixed. Quantity is not equivalent to Quality. I also agree with that. My point is that the systemd project has enough numbers of *talented* developers to do it. You can disagree, of course. Talented developer, maybe. But not talented designers. That's subjective. For me (and many others), the design of systemd is sound. Thanks to your explanation of socket activation it is subjective no longer. Systemd design flaws may be discussed in sheer technical terms, see below. If I were to have sockets created in advance (does it work with TCP/IP sockets?) I would get timeouts on the responses which would lead to some services not starting correctly and ending up in limbo... You don't know how the socket activation works, do you? At boot time, if a service ask for a socket on port 1234 (and yes, they work on TCP/IP sockets), systemd opens the socket for the service, and the service *does not start yet*. When the *first* connection gets into the socket, systemd starts the service, and when it finishes starting, systemd passes the opened socket to it as an fd. Done, now the service has control of the socket, and it will until the services terminates; not when the connection closes (although you can configure it that way), when the *service* terminates. If several connections arrive to the socket *before* the service finishes starting up, the kernel automatically queues them, and when systemd handles the socket to the service, the service does it things for all of them. There is *no single* connection lost. Well, if a godzillion connections arrive before the service finishes starting up, the kernel queue is finite and some would be lost, but it would have to be a lot of connections arriving in a window of some microseconds. And here we have a design issue. I already pointed this issue in this discussion: http://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg144144.html Though it was completely ignored by you. I understand: it is easier to discuss design in terms of taste than in technical merits. Systemd assumes that time required to start service is small (at microseconds scale). While this is true for widely used simple setups, this is not true in general case. Service may take seconds or even minutes to start up (good example are services depending on enterprise SAN or large databases). And because systemd never assumes it can take long time to start we have the following issues possible in general case: 1. Client connections are lost due to timeout when service takes long time to start. Systemd fakes service to be available while it isn't still. Thus systemd is not an option for production grade servers. 2. Even if connection timeout is not reached, requests may pale up and be lost. Loss trigger depends on memory available, thus systemd is not an option for both embedded setups and production server setups. As one can see, while systemd socket activation design will work for many case, it will fail for corner ones and by no means can't be used in production (where this corner cases have a high chance to rise). Best regards, Andrew Savchenko pgphWTsbn3Qsg.pgp Description: PGP signature
Re: [gentoo-user] Peeve - finding kernel config options
Hi, On Thu, 27 Feb 2014 08:04:01 +0200 Alan McKinnon wrote: # eselect news read 10 2014-02-25-udev-upgrade Title Upgrade to =sys-fs/udev-210 AuthorSamuli Suominen ssuomi...@gentoo.org Posted2014-02-25 Revision 1 The options CONFIG_FHANDLE and CONFIG_NET are now required in the kernel. Whenever kernel config options are provided like this, it would be nice if time was taken to provide the path to where they are found. make menuconfig press / type CONFIG_FHANDLE press enter profit!!! Typing just FHANDLE is sufficient. CONFIG_ prefixes are allowed, but not needed at all for menuconfig search functionality. Best regards, Andrew Savchenko pgpY2OhQec4Ga.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Thu, 20 Mar 2014 21:00:27 +0100 Tom Wijsman wrote: OpenRC is default in Gentoo now, and it is my best hope it will be. Do you have a source that backs up this claim? http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1chap=6 It comes as part of stage3, but a systemd stage3 is being worked on[1]; however, it has only temporarily been in the @system set (due to functions.sh[2] which is now split) and will soon be removed from it. [1]: https://bugs.gentoo.org/show_bug.cgi?id=482702 If these stage will be alternative, I'm OK with this. If it will be the only one available, many people will have to say Gentoo good bye. Best regards, Andrew Savchenko pgpTdDzBnqsa_.pgp Description: PGP signature
Re: [gentoo-user] Questions about CPU settings in kernel and USE
On Mon, 14 Apr 2014 22:11:05 -0400 Walter Dnes wrote: I'm (re)installing Gentoo on an older AMD notebook. The output from less /proc/cpuinfo includes... processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Athlon(tm) II P320 Dual-Core Processor stepping: 3 microcode : 0x1b6 cpu MHz : 2100.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv svm_lock nrip_save bogomips: 4189.59 TLB size: 1024 4K pages Now for the questions * In make menuconfig, I'm not sure which of 2 CPU options to select in Processor type and features --- Processor family (*) --- ( ) Athlon/Duron/K7 ( ) Opteron/Athlon64/Hammer/K8 I'd like to recommend you this kernel gcc patch which enables -march=native support for kernel compilation: https://github.com/graysky2/kernel_gcc_patch Just select native and you will get both best performance and one less headache. Best regards, Andrew Savchenko pgpwPFk2d1kJG.pgp Description: PGP signature
Re: [gentoo-user] [SOLVED] Running cryptsetup under mdev
On Wed, 07 May 2014 20:57:29 +0200 J. Roeleveld wrote: On 7 May 2014 20:11:10 CEST, Walter Dnes waltd...@waltdnes.org wrote: On Wed, May 07, 2014 at 08:11:02AM +0200, J. Roeleveld wrote On Tuesday, May 06, 2014 05:34:52 PM Walter Dnes wrote: Unfortunately, mdev != udev. People running RAID have problems too. I know it isn't. I just find it strange that LVM can't work without udev when I see options which configure the LVM-tools to either double-check udevs actions or even completely bypass udev: Thanks for the pointer. After turning off the udev-related options in lvm.conf, I'm getting /dev/mapper device nodes as expected. That is good. Now if only mdadm can be confirmed to work with mdev. I could try it on one of my machines. And what is the problem with mdadm with mdev? I have such setup: nothing special here and works fine. Just to speed up device lookup: $ grep -v ^# /etc/mdadm.conf DEVICE /dev/sd* And here we go: $ cat /proc/mdstat Personalities : [raid10] md0 : active raid10 sdd[3] sdf[2] 2930265088 blocks super 1.2 256K chunks 2 far-copies [2/2] [UU] Best regards, Andrew Savchenko pgpYAu22dxvLA.pgp Description: PGP signature
Re: [gentoo-user] ceph on btrfs
Hi, On Wed, 22 Oct 2014 20:05:48 + (UTC) James wrote: Hello, So looking at the package sys-cluster/ceph, I see these flags: cryptopp debug fuse gtk +libaio libatomic +nss radosgw static-libs tcmalloc xfs zfs No specific flags for btrfs? Ceph is optimized for btrfs by design, it has no configure options to enable or disable btrfs-related stuff: https://github.com/ceph/ceph/blob/master/configure.ac No configure option = no use flag. ceph-0.67.9 is marked stable, while 0.67.10 and 0.80.5 are marked (yellow) testing and * is marked (red) masked. So what version would anyone recommend, with what flags? [1] Just use the latest (0.80.7 ATM). You may just nerame and rehash 0.80.5 ebuild (usually this works fine). Or you may stay with 0.80.5, but with fewer bug fixes. Ceph will be the DFS on top of a (3) node mesos+spark cluster. btrfs is being set up with 2 disks in raid 1 on each system. Btrfs seems to be keenly compatible with ceph [2]. If raid is supposed to be read more frequently than written to, then my favourite solution is raid-10-f2 (2 far copies, perfectly fine for 2 disks). This will give you read performance of raid-0 and robustness of raid-1. Though write i/o will be somewhat slower due to more seeks. Also it depends on workload: if you'll have a lot of independent read requests, raid-1 will be fine too. But for large read i/o from a single or few clients raid-10-f2 is the best imo. Guidance and comments, warmly requested, James [1] http://ceph.com/docs/v0.78/rados/configuration/filesystem-recommendations/ [2] http://ceph.com/docs/master/release-notes/#v0-80-firefly Best regards, Andrew Savchenko pgpUJMy39uiEh.pgp Description: PGP signature
Re: [gentoo-user] kernel 3.17.0
Hi, On Mon, 20 Oct 2014 07:06:32 +0200 Tomas Mozes wrote: On 2014-10-18 23:16, Volker Armin Hemmann wrote: Am 18.10.2014 um 06:17 schrieb Philip Webb: I just installed Kernel 3.17.0 (gentoo-sources) noticed there are specific options for Gentoo right at the beginning. Are we really privileged to have our own place in kernel-land or have these been added by the Gentoo devs ? and that is why I don't use gentoo-sources. Out of curiosity, may I ask why? My 2 cents here. 1) In the past I had hardly traceable issues with gentoo-sources which were not present in vanilla kernels. I just switched back to vanilla. 2) Gentoo-sources are sometimes behind vanilla kernel. Due to some derivative from Murphy's law this always happens when I need some new features. 3) I looked over patches in gentoo-sources and found none I'm interested into. (That doesn't mean they are useless, just not my usecases.) Best regards, Andrew Savchenko pgpLtEw0ic1_w.pgp Description: PGP signature
Re: [gentoo-user] Re: ceph on btrfs
Hello, On Thu, 23 Oct 2014 19:41:22 + (UTC) James wrote: [...] Just use the latest (0.80.7 ATM). You may just nerame and rehash 0.80.5 ebuild (usually this works fine). Or you may stay with 0.80.5, but with fewer bug fixes. So just download from ceph.com, put it in distfiles and copy-edit ceph-0.80.7 in my /usr/local/portage, or is there an overlay somewhere I missed? I don't know such. Just use a local overlay (or stay with 0.80.5 — difference should not be huge). [...] Last point. I'm using openrc and not systemd, at this time; any ceph issues with openrc, as I do see systemd related items with ceph. We are using openrc too, no related issues. (systemd is banned on all our setups: masked and its dirs are in INSTALL_MASK, so we don't have its stuff floating around.) Best regards, Andrew Savchenko pgpqwiFt5PNZ4.pgp Description: PGP signature
Re: [gentoo-user] Re: ceph on btrfs
On Fri, 24 Oct 2014 16:20:36 + (UTC) James wrote: Andrew Savchenko bircoph at gmail.com writes: We are using openrc too, no related issues. (systemd is banned on all our setups: masked and its dirs are in INSTALL_MASK, so we don't have its stuff floating around.) замечательно Рад помочь :) Best regards, Andrew Savchenko pgpRxUflonr6N.pgp Description: PGP signature
Re: [gentoo-user] Debian forked, because of systemd brouhaha
On Sat, 29 Nov 2014 22:32:18 -0500 Rich Freeman wrote: On Sat, Nov 29, 2014 at 9:01 PM, Bill Kenworthy bi...@iinet.net.au wrote: I am already really annoyed that by default systemd and apps designed to work with it leave traces on openrc based systems. You're getting worked up about text files and filenames. I suppose you'll be really upset that bash completion files are now being installed by default, and packages install logrotate configs and cron scripts even if you don't use logrotate or cron. We have INSTALL_MASK for such cases. While it should be used with care (as improper use will broke system), INSTALL_MASK=*/systemd/* keeps my systems clean from this filthy abomination. Sure, we could add a million more layers of conditionals to everything and you might save a few dozen inodes on your 10GB install, at the cost of lots of hassle/bugs/etc. In general Gentoo tends to take the pragmatic approach. If you're a purist of just about any kind you're going to have to hold your nose. However, this cuts both ways - the purists who don't want YOU to be able to make the choices YOU want to make also have to hold their noses. :) Best regards, Andrew Savchenko pgpl14gaxAGpX.pgp Description: PGP signature
Re: [gentoo-user] Debian forked, because of systemd brouhaha
On Sat, 29 Nov 2014 17:32:08 +0100 Marc Stürmer wrote: Am 29.11.2014 um 11:11 schrieb Pandu Poluan: What do you think, people? Shouldn't we offer them our eudev project to assist? Since Eudev has always been opensource under the GPLv2, like udev too, there's no need to /offer/ it. If they choose to use it, they can use it, no offer/questions necessary. Simple. As far as I understand, Pandu meant we can recommend them to use, but not some offer in commercial or proprietary terms. Don't forget that most people on the list are not native speakers, so IMHO superfluous verbalism is inappropriate here. Best regards, Andrew Savchenko pgpEVGBDFymZu.pgp Description: PGP signature
Re: [gentoo-user] How to find out to what file(...) writes goes on a idle system...
On Sat, 06 Dec 2014 12:01:16 +0100 Johannes Altmanninger wrote: Hi, meino.cra...@gmx.de writes: In the context of preserving the live of flash media by minimizing the count of unessary writes I want to know which application/daemon/etc is continous writing to that media and which entity (file/pipe/fifo...) is receiving those writes... You could use this: # echo 1 /proc/sys/vm/block_dump then every read and write operation on block devices shows up in dmesg with the PID, process name and the block id. (This can be a lot of lines, so dmesg -c might be useful) I'm not exactly sure how to identify which files belong to which block, though. This depends on filesystem being used. For ext* family debugfs may be used: # debugfs /dev/your_dev ncheck inode1 inode2 ... Best regards, Andrew Savchenko pgpTSVfkHacd7.pgp Description: PGP signature
Re: [gentoo-user] Choosing a new profile: multilib or not?
On Mon, 22 Dec 2014 10:53:06 + Mick wrote: It used to be the case that adobe flash and other applications would not work with a no-multilib profile. However, I was surprised to see that a previous no-multilib installation of mine was able to play flash in Firefox. So, I thought of asking here if there is any reason to avoid installing a no-multilib profile these days. What applications binary (e.g. Skype) or source compiled won't work with no- multilib? For skype you have to either build qt, X11 and some other libs with multilib support (abi_x86_32) or use emul-linux-x86-* prebuilt packages. Either way your system will end up with 32-bit libraries installed, but in case of multilib they will be optimized for your hardware and use cases (*FLAGS and USE). Best regards, Andrew Savchenko pgpE9EeFAs2rB.pgp Description: PGP signature
Re: [gentoo-user] ceph on gentoo?
Hi, On Tue, 23 Dec 2014 15:22:26 +0100 Stefan G. Weichinger wrote: Anyone here running ceph / http://ceph.com/ on gentoo? As server(s) or client or ... ? I am learning about this right now and currently on my way to a first small test cluster. Very interesting possibilities ! We used it about a year ago for our infrastructure (backup and live sync of HA systems), obviously both servers and clients were used, both on Gentoo. We stopped this because of numerous kernel panics, not to mention that it was quite slow even after tuning. So we switch to another solution for data sync and backups: clsync. (It was developed from scratch for our needs, this is not a filesystem, but may be considered as more powerful alternative to lsyncd.) Though this was a year ago or so. Your mileage may vary and it is likely that during this year stability was improved. Ceph is very promising by both design and capabilities. Best regards, Andrew Savchenko pgpVVw_WacZ9H.pgp Description: PGP signature
Re: [gentoo-user] ceph on gentoo?
Hi, On Tue, 23 Dec 2014 16:36:25 +0100 Stefan G. Weichinger wrote: Am 23.12.2014 um 16:20 schrieb Andrew Savchenko: [...] We used it about a year ago for our infrastructure (backup and live sync of HA systems), obviously both servers and clients were used, both on Gentoo. We stopped this because of numerous kernel panics, not to mention that it was quite slow even after tuning. So we switch to another solution for data sync and backups: clsync. (It was developed from scratch for our needs, this is not a filesystem, but may be considered as more powerful alternative to lsyncd.) Though this was a year ago or so. Your mileage may vary and it is likely that during this year stability was improved. Ceph is very promising by both design and capabilities. I agree! I expect that there were many changes over the time of a year ... they went from v0.72 (5th stable release) in Nov 2013 to v0.80 in May 2014 (6th stable release) ... and v0.87 in Oct 2014 (7th ...) We get 0.80.7 in ~amd64 now ... I will see. Ad slow: what kind of hardware did you use and how many nodes/osds? We used 3 servers, where each server was both node and osd (that's our hardware limitation). Each machine had hardware alike 2x Xeon E5450, 16 GB and 2 Gbps network connectivity (via bonding of two 1 Gbps interfaces). We went through a lot of software and kernel tuning, this helped to solve many issues, but not all of them: ceph nodes still got kernel panics once in a while. This was unacceptable and we moved for other approaches to our issues. Best regards, Andrew Savchenko pgplP4mXOrMjz.pgp Description: PGP signature
Re: [gentoo-user] ceph on gentoo?
On Wed, 24 Dec 2014 10:58:35 +0100 Stefan G. Weichinger wrote: Did you have the journal separated on SSDs? We don't have SSDs at all. I think that would make quite a difference both in performance and cost ;) Do you remember the kernel version and ceph version? Not exactly :/ It was something rather new at that time like 3.12.x. How many disks / OSDs? 3 OSDs with raid6 attached to each one. Sorry for being so curious .. Not a problem :) Best regards, Andrew Savchenko pgpp8nppQ12M9.pgp Description: PGP signature
Re: [gentoo-user] ceph on gentoo?
Hi, On Fri, 26 Dec 2014 00:38:58 -0600 Bruce Hill wrote: To whoever controls this list... I just arrived home to find my mailbox spammed with hundreds of messages from this luser Andrew Savchenko birc...@gentoo.org Please stop insults and offensive language. I just sent replies to the list, this is verifiable by mail headers. If you have mail problems, check your MTA or whatever you are using to receive e-mail from this list. As you can see, other people don't have this problems. What is the explanation for this please? Just my guess: greylisting is broken (or had a temporary lag) on mail server you are using. Best regards, Andrew Savchenko pgpFkYZ2ZzDfy.pgp Description: PGP signature
Re: [gentoo-user] How to automate an sshfs (fusermount) mounted share
Hi, On Sat, 03 Jan 2015 09:23:29 -0500 Harry Putnam wrote: I'm sshfs mounting an solaris zfs file system in the interactive fashion. sshfs $USR@HOST:/file/system MOUNTPOINT passwd? enter passwd RETURN Once mounted I run an rsnapshot backup onto the mounted FS. Any ideas on how to go about doing this mount automatically (scripted) will be greatly appreciated. 1) Set up your ssh to use keys. Key itself should not be protected by password (or manual intervention will be needed on each mount). 2) Add sshfs command to your .bash_profile (or whatever login shell you're using) with check that filesystem is not mounted already, something like: grep -q $MOUNTPOINT || sshfs $USR@HOST:/file/system MOUNTPOINT Alternatively you may add this to your DE/WM autostart scripts, if you are using GUI logins only. Best regards, Andrew Savchenko pgpJvFFahiIWL.pgp Description: PGP signature
Re: [gentoo-user] pdf viewer
On Sat, 03 Jan 2015 06:15:05 +0100 lee wrote: Hi, what do you as PDF viewer? Most of the time, I was using xpdf, and that doesn't seem to be available in Gentoo. I compiled it from source and found out that it cannot display PDFs so well and gives error messages about not being able to find fonts. Pdfpc isn't a good alternative. For advanced actions (e.g. pdf notes editing, pdf fields editing, work with pdf indexes and so on) I use evince. When I need something simple (e.g. to read pdf books) I use mupdf. Another bonus of mupdf is unlimited scale of pdf pages (limited only by available memory). This is really handy when handling huge pdf pages (e.g. some schemes, graphs) with very small fonts, so large zoom is required to made them readable; evince can't handle such issues. Best regards, Andrew Savchenko pgpkt9XrfqNla.pgp Description: PGP signature
Re: [gentoo-user] pdf viewer
On Sat, 03 Jan 2015 16:00:02 +0100 lee wrote: mupdf seems to display text only? No: images, internal references and hyperlinks are also OK. How did you find all these packages? I used 'emerge --search' and it didn't show many results for pdf. $ eix -c -C app-text -S pdf|viewer Best regards, Andrew Savchenko pgpJxLhd51IC7.pgp Description: PGP signature
Re: [gentoo-user] Ghost cyber threat
Hi, On Fri, 30 Jan 2015 10:11:52 -0500 symack wrote: Hello, From my understanding this is only an issue if a person is able to telnet or ssh to an effected system? Please confirm. Are you talking about ghost issue or about GLSA I mentioned above? If about ghost, then NO. Any applicaton using gethostbyname() or gethostbyname2() and glibc-2.18 IS vulnerable. Best regards, Andrew Savchenko pgp0memZyNaAg.pgp Description: PGP signature
Re: [gentoo-user] Re: Get off my lawn?
On Mon, 19 Jan 2015 18:03:44 + (UTC) James wrote: Interestingly, Bircoph has solve many of the problems that seem to be in my path of discovery. If you have any questions about particular issues, we may discuss them. Out of my memory for all setups we use nothing really special — standard Gentoo software, some custom scripts (for sync and/or HA) — and one really beatiful solution we wrote: clsync. In short this is lsyncd replacement in C which is much faster and have much more functionality (at least for our needs). Right now this software is not in tree, but can be found in my dev overlay. New clsync version was recently released and I plan to push it to tree after some testing. Best regards, Andrew Savchenko pgpaUDKvZUjwG.pgp Description: PGP signature
Re: [gentoo-user] Re: Get off my lawn?
On Sat, 17 Jan 2015 21:04:44 -0500 Rich Freeman wrote: Speak for yourself. :) I did comment on my thoughts in this area in Donnie's thread. Gentoo (IMHO) tends not to be the best distro for doing anything in particular. I find that its best feature is that it is reasonably good at doing just about anything - it is a jack-of-all-trades. I can't agree with you here, though your position have a rationale. I see Gentoo as a Universal Constructor (UC) which may be used to whatever specific needs Linux can be used at all. In general UC pros is ability to create setup suitable for every specific need, but cons is maintenance cost to create and update such setup. Also creating and maintaining UC-powered setups rises general professional level of system architect or amdin doing the job. So everything comes to how much user needs deviate from what already existing binary distributions provide. If user needs are perfectly satisfied with some binary distro, using Gentoo will only raise maintenance costs. But if users demands something hardly achievable with other (binary) distributions, then this is a good place for Gentoo. From my own experience I can point three directions where Gentoo was and is reasonably the best choise for our needs (mine or my colleagues): 1) HPC. When it comes to scalable tasks and large amount of hardware, even small performance gain results into huge saving of costs. On our first cluster we replaced CentOS by carefully tuned Gentoo and performance gain was about 30-50% depending on scientific application (please note I'm talking about real applications and not about synthetic tests like linpack). With hardware costs about million of dollars, 30% performance gain results in a great saving. Price for that was much longer time for initial setup (many weeks instead of many days), but it was still less then time required to setup hardware itself and all auxiliary engineering systems. An interesting observation here is that average software update cost of Gentoo is smaller that one of RH-based systems we used before. While it is easier to update RH-based solution within the same branch, then Gentoo setup, it is a complete nightmare to upgrade from one branch to another, e.g. from RHEL4 to RHEL5. I've gone through such update in the past an it is much worse than remove everything and install from scratch, including all user applications. As for Gentoo, all updates are equal: they bring some build failures, runtime issues and compatibility problems, but to a limited extent, which is handleable easy enough by prepared team. 2) High security servers. We have some systems dedicated to a very specific needs where security demands are extreme. Hardened Gentoo is the best solution here, since we can strip down such system close to an absolutely possible minimum and protect that minimum by all means (hardened toolchain and flags, PaX, SELinux and so on). Of course, on top of then containers may be use to isolate different daemons and so on... 3) Individual interested in getting every bit of performance possible from own hardware. Frankly this was the reason why I switched to Gentoo from RH about 8 years ago. I just tired to rebuild each time a significant part of packages with custom flags and configure options. Gentoo is much better suited for this task. And as a result 13 years old hardware is still usable to watch 720p and most of 1080p videos (without GPU hardware decoding). A byproduct of such interest is a deep understanding of system internals, which is a great result on its own. Best regards, Andrew Savchenko pgpIL0spPvaY8.pgp Description: PGP signature
Re: [gentoo-user] updating netbook : Python needs libjpeg.so.8 : solved
On Thu, 29 Jan 2015 05:52:27 -0500 Philip Webb wrote: The 3rd stumble was Python, which refused to compile, as it couldn't find /usr/lib/libjpeg.so.8 . It seems that Libjpeg-turbo works only on 64-bit systems that 32-bit systems like my netbook have to use simple Jpeg. No. libjpeg-turbo works fine here on ~x86. Best regards, Andrew Savchenko pgpKWytHpmp4L.pgp Description: PGP signature
Re: [gentoo-user] Re: Ghost cyber threat
On Wed, 28 Jan 2015 15:01:26 + (UTC) James wrote: Philip Webb purslow at ca.inter.net writes: 150127 Joseph wrote: Does anybody know more about this security flaw in the open-source Linux GNU C Library : http://www.theglobeandmail.com/technology/linux-makers-release-patch-to-thwart-new-ghost-cyber-threat/article22662060/?cmpid=rss1 Acc to this, it was patched 2013 today threatens only long-term systems : http://threatpost.com/ghost-glibc-remote-code-execution-vulnerability-affects-all-linux-systems/110679 I'm running 2.19-r1 , installed 140802 ; vulnerable are 2.18 . Linux systems are at risk only when admins don't keep versions upto-date. Maybe it's time to looking into some of the work the gentoo hardened devs have going on: http://wiki.gentoo.org/wiki/Project:Hardened_musl 1. Main security is outdated software. E.g. ghost bug affects only very old setups. 2. There is no proof that musl is more secure than glibc. Smaller codebase tends to have less bugs, of course; but audience of musl is multiple degrees smaller than that of glibc, thus many bugs are just likely to be undiscovered. With more users and features musl will also have critical bugs sooner or later. These reminds me of recent openssl issue, after which many switched to polarssl and that one had a critical security bug just recently. Best regards, Andrew Savchenko pgpvLwbU7JNjE.pgp Description: PGP signature
Re: [gentoo-user] Ghost cyber threat
On Thu, 29 Jan 2015 08:52:57 -0800 Grant wrote: Does anybody know more about this security flaw in the open-source Linux GNU C Library http://www.theglobeandmail.com/technology/linux-makers-release-patch-to-thwart-new-ghost-cyber-threat/article22662060/?cmpid=rss1 I updated a system of mine that was using an old version of glibc and rebooted. I can't do a full emerge world there or use various other portage tools due to the peculiarities of my current situation. Could I still be vulnerable? Your system may be vulnerable to this issue only if you have packages statically linked with vulnerable glibc libs, so most likely — no. But your system may be affected by a plenty of other issues in various packages. At the very least you should apply all GLSAs to your system: while they don't encompass all vulnerabilities, they should warn you about most common and important ones. Best regards, Andrew Savchenko pgpMWQmbZaBhp.pgp Description: PGP signature
Re: [gentoo-user] Question about flakey RAM
On Tue, 27 Jan 2015 15:28:11 -0800 walt wrote: Yesterday I installed 4GB more of RAM in this machine for a total of 8GB, and the machine soon began random segfaulting and even a kernel crash or two, so obviously I suspected the new RAM was faulty. I let memtest86+ run overnight and it found zero memory errors. Today I exchanged the new RAM anyway and got a different brand this time, and that fixed the problem. My question is why didn't memtest86+ find any errors? Could it be that the first RAM I bought was actually okay but this machine didn't like it for some reason? Both were DDR3/1333MHz, just from different manufacturers. As an addition to earlier posted comments: 1) memtest86+ has a bit fade test which is not enabled by default (at least for 4.x branch which is the latest in tree now), so you have to enable and run it manually. IIRC it is enabled by default in 5.x branch (bug pending in bugzilla). By the way 5.x have some additional tests which may find faults unknown to 4.x 2) The same frequency is not enough to guarantee memory banks compatibility. They may require different timings or, less probably, voltage. Some BIOS tuning may help here. 3) Memory may be (un)buffered, (un)registered, ecc/non-ecc. Many of these combinations are not compatible with each other. 4) In some rare cases even banks with the same parameters from different manufacturers are not compatible due to technological differences (this goes down to how logical circuits are implemented). Best regards, Andrew Savchenko pgpiXoHXB_nSL.pgp Description: PGP signature
Re: [gentoo-user] Ghost cyber threat
On Fri, 30 Jan 2015 12:19:01 -0500 symack wrote: Hello Andrew, Thank you for your response. For example, Exim implements reverse lookup. How is malicious activity used against it? Exim uses vulnerable function depending on its configuration, that's why it may be possible to remotely execute code with privileges of the exim process. Do they need telnet or ssh access, I don't understand this obsession with ssh or telnet. Remote code execution means that malicious party can execute any code on affected system. or buy some freak of nature can exploit the vulnerability in other ways? Considering how old one's setup should be to be affected to this issue, it is likely that such systems have another vulnerabilities, allowing attacker to gain root privileges even if exim itself is being run as a non-root user. Best regards, Andrew Savchenko pgpKpmns3wCDW.pgp Description: PGP signature
Re: [gentoo-user] merging pdf file into one page
On Sat, 24 Jan 2015 12:26:28 -0700 Joseph wrote: I've pdf form that I print. Once the form is printed I put it back in the printer tray and print information over top of it. It worked in the past but after I print it second time (over the printed form) the pages look as if they came out of the washing machine. They are crumpled. I think it as to do something with the static. How to I combine (overlap) two pdf files into one page. Use imagegick's composite tool to overlap images into single pdf, then print it. Best regards, Andrew Savchenko pgpBg2C5bORzm.pgp Description: PGP signature
Re: [gentoo-user] problem emerging Libdrm
On Sun, 25 Jan 2015 00:18:32 -0500 Philip Webb wrote: After exactly 2 years , I'm trying to update my Asus EEE netbook. I've emerged gcc-4.8.3 ( 3 h 31 m ), portage-2.2.14 udev-216 . However, I've lost X : trying to update gtk+ , I've run into a problem : it requires Mesa Cairo both require libdrm-2.4.58 , which refuses to compile, failing with lines reporting that libpng15.so.15 libudev.so.0 not found, which seem to be needed by Cairo Mesa, which depend on Libdrm ; I've already updated to libpng-1.6.16 , so libpng16.so.16 is installed. I've tried 'emerge --nodeps' with Cairo Mesa, but both fail. libdrm-2.4.58 was emerged on this desktop machine without any difficulty with libpng-1.6.16 emerged a bit later everything working properly. I've done searches of Bugs, Forum asked Google without much help. Can anyone suggest what might be causing this problem ? As for libpng: the problem is that after libpng update many pkg-config files still contain references to old libpng15.so. Usual way to fix this is to rebuild all libpng dependencies (emerge @revdep-rebuild or revdep-rebuild tool may be used for that). But this doesn't work on too old setups, where during such updates packages will require some newer stuff like libdrm to be updated itself. In order to broke this look you can manually edit all files in /usr/lib/pkgconfig in order to point them to proper libpng version, e.g.: $ cd /usr/lib/pkgconfig $ sed -i 's/libpng15/libpng16/ *.pc As for libudev, probably problem and solution is the same. Not all packages use pkg-config, some have $packagename-config scripts (like fltk-config). Some of these scripts hardcode library names in a similar way to pkg-config, so you have to fix this /usr/bin-*config scripts too if you have any problems with related applications. Best regards, Andrew Savchenko pgpcS7xPynewa.pgp Description: PGP signature
Re: [gentoo-user] Latest chromium-40 on ~x86
On Sat, 24 Jan 2015 16:43:41 +0100 Nils Holland wrote: Hi folks, I've been using chromium successfully on my ~x86 system for quite a long time, but starting with the last two updates that came in during the last few days (namely, chromium-40.0.2214.85 and chromium-40.0.2214.91), I started having problems. Both of these versions build just fine, but upon trying to launch them, the browser's interface comes up just fine, but will only display a Something went wrong... page. I can try typing in and accessing URLs, but all I will ever get is this error page. That's not all, though, I also get to see error messages, namely the following in my terminal: ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0265 And this here in dmesg: chrome[5274]: segfault at e806109 ip b5c5c945 sp ac280980 error 6 in chrome[b1864000+5eed000] Great, I thought, something wrong with the sandbox stuff. So I tried to launch chromium without it (chromium --no-sandbox), and indeed: The browser works absolutely fine this way - I get none of the problems or messages mentioned above. Of course, I tried to find a related entry in both the Gentoo as well as the chromium bug trackers, but I couldn't find anything in either. I'm a bit reluctand to report my own bug as I wouldn't be 100% sure that I'm not causing the problem (after all, I'm building my chromium with USE=custom-cflags, which is not officially supported, but has always produced nicely working builds for me in the past), so I thought I'd ask here first if I'm the only one observing this behavior. The question, thus, would probably be: Anyone using one of the recent chromium-40 versions on ~x86 or anywhere else and seeing something similar? Or probably someone who has experienced something like that before and could offer a guess what might be wrong here - a real bug, custom-cflags, or something entirely different? I gave up on chromium starting from chromium-36, where they dropped pre-SSE2 x86 support (and I use such system: Athlon-XP). I tried to re-add this stuff with partial success (works, but still SIGILLs sometimes) and it's very hard to clean all pieces. Looks like they're slowly abandoning x86 and older hardware at all. Best regards, Andrew Savchenko pgpkjjYmvwwIi.pgp Description: PGP signature
Re: [gentoo-user] Latest chromium-40 on ~x86
Hi, On Sun, 25 Jan 2015 19:43:12 +0100 Nils Holland wrote: On Sun, Jan 25, 2015 at 02:03:48PM +0300, Andrew Savchenko wrote: I gave up on chromium starting from chromium-36, where they dropped pre-SSE2 x86 support (and I use such system: Athlon-XP). I tried to re-add this stuff with partial success (works, but still SIGILLs sometimes) and it's very hard to clean all pieces. Looks like they're slowly abandoning x86 and older hardware at all. Actually, I can't say that I'm too much of a fan of chromium either. I'm more than happy using vimb, sometimes also midori and firefox. Chromium mostly only sits here as a last resort when some site doesn't seem to work right in one of the other browsers (which, fortunatly, only happens with a frequency that is rapidly approaching never). There are many things I don't like in Chromium, but there is one feature so important, that I can overlook all disadvantages of chromium: this feature is security. Unlike other browsers (I don't consider chrome or chromium forks here as a separate browsers) chromium is secure by design: it isolates tabs and plugins, supports various namespaces, seccomp sandboxing, yama framefork. Other browsers don't: tabs are not isolated, plugins have poor isolation (it seems firefox is working in this direction at least), thogh they work fine on my yama-enabled systems. So the fact that I don't care about chromium too much, with the added fact that my main machine is a lower-range laptop and takes quite a while to build chromium, is also the reason why I can't be bothered right now to re-build in order to try out various things or otherwise try to collect debugging information. distcc will help you here, that is the way how I maintain older boxes. Of course, you should use ccache too. Best regards, Andrew Savchenko pgpS22Eu7owem.pgp Description: PGP signature
Re: [gentoo-user] pdf viewer
On Fri, 09 Jan 2015 20:49:56 +0100 lee wrote: Andrew Savchenko birc...@gentoo.org writes: When I need something simple (e.g. to read pdf books) I use mupdf. How did you get mupdf to display a pdf? Just run it: $ mupdf file.pdf In my case mupdf is configured as follows: Installed versions: 1.5-r1(02:19:48 AM 12/28/2014)(X curl openssl -static -static-libs -vanilla) I'd have removed it if it wasn't required by llpp ... Funny thing. llpp segfaults to me to matter on what host I try it. How do I get seamonkey to suggest llpp as application to view PDFs? Sometimes it suggests emacsclient, sometimes browse ... I don't use seamonkey, so I can't get an exact advice, but in general there are two ways to do this: 1) Configure your handlers in seamonkey. 2) Configure your default mime handler using xdg-mime. Best regards, Andrew Savchenko pgp2viOPgFzel.pgp Description: PGP signature
Re: [gentoo-user] pdf viewer
On Sat, 10 Jan 2015 19:25:54 +0100 lee wrote: Andrew Savchenko birc...@gentoo.org writes: On Fri, 09 Jan 2015 20:49:56 +0100 lee wrote: Andrew Savchenko birc...@gentoo.org writes: When I need something simple (e.g. to read pdf books) I use mupdf. How did you get mupdf to display a pdf? Just run it: $ mupdf file.pdf In my case mupdf is configured as follows: Installed versions: 1.5-r1(02:19:48 AM 12/28/2014)(X curl openssl -static -static-libs -vanilla) There's only 'utool' and no 'mupdf'. You should enable USE=X as I wrote above. How do I get seamonkey to suggest llpp as application to view PDFs? Sometimes it suggests emacsclient, sometimes browse ... I don't use seamonkey, so I can't get an exact advice, but in general there are two ways to do this: 1) Configure your handlers in seamonkey. How? I don't have seamonkey, read its manual. 2) Configure your default mime handler using xdg-mime. Hm, xdg-mime is not installed; I've never heared of it. x11-misc/xdg-utils Most WM/DE will pull this package. Best regards, Andrew Savchenko pgpRigLqXTToR.pgp Description: PGP signature
Re: [gentoo-user] old EEE PC 1000
Hello, On Sun, 8 Feb 2015 18:05:44 -0700 Joseph wrote: I have an old Asus EEE PC 1000 and I don't think it will run Gentoo, it would be too slow to compile anything. It is running Ubuntu 11.10 and I think I'll need to re-install lighter version of Linux on it. What are my alternatives? Just use Gentoo. I have an EeePC 1000H and it runs fine. Well, I replaced memory bank with 2GB one and setup my system to be slightly overclocked (1700 MHz) when on AC power using SHE technology (available in linux kernel). But even without memory upgrade hardware is fine. I'll would like to run VPN, some browser on it and skype. VPNs are lightweight packages (e.g. openvpn). Both firefox and chromium are not a problem. Skype is binary only, so no difference from other distributions here. The only real problem with this hardware are @world updates. To facilitate this process use ccache and distcc. You most likely have another more powerful box (e.g. a desktop or more powerful laptop), so you can setup distcc there regardless of the distribution. So powerful box will compile C/C++/ObjC code for you, while EeePC will handle If by some chance you have another peace of very powreful hardware (e.g. 2x recent Xeon) there is another approach to follow. You may export root filesystem from EeePC to that host via NFS, setarch and chroot to it and run all stuff from your powerful box. This way the only bottleneck will be 100 Mbps network interface, which is quite bearable, especially using caching (like cachefilesd). Yet again, all these tricks are required for @world updates only, for other stuff EeePC is self sufficient box. Best regards, Andrew Savchenko pgpyDJl2Xegal.pgp Description: PGP signature
Re: [gentoo-user] repos.conf migration lost overlay priority
On Fri, 13 Feb 2015 20:29:07 +0200 Nikos Chantziaras wrote: I migrated my portage config to the new repos.conf system. I now have a file /etc/portage/repos.conf/local.conf: [Local] location = /usr/local/portage auto-sync = no And removed the path from make.conf. However, now layman overlays override my local repo. If I copy an ebuild to /usr/local/portage (for modifications) and try to emerge it, it is not emerged. Instead, the ebuild from the other overlay is emerged. How do I make my local overlay have the highest priority so that it overrides *everything*? Try to add priority = 100 to local.conf Best regards, Andrew Savchenko pgpLSYv7zqRwe.pgp Description: PGP signature
Re: [gentoo-user] gentoo announces total website makeover :-)
On Wed, 1 Apr 2015 01:37:06 +0200 waben...@gmail.com wrote: This really made my day. :-) https://www.gentoo.org/news/2015/03/31/website-update.html The best design ever! So nice and readable font, so yummy background, very fast page load. Many thanks for Web project team for hard work! As for the Phase II, are there any plans for 8 floppy support or only 5.25 devices are targeted? Best regards, Andrew Savchenko pgpEw4sFgcSlu.pgp Description: PGP signature
Re: [gentoo-user] How to find all packages which need Python2_7
On Tue, 03 Mar 2015 11:12:48 +0100 Helmut Jarausch wrote: On 03/03/2015 10:47:46 AM, Andrew Savchenko wrote: Hello, On Tue, 03 Mar 2015 10:21:19 +0100 Helmut Jarausch wrote: Hi, I'd like to install all packages which need Python, only for Python3 except those which cannot be installed for Python3. How can I find out which of the packages installed on my machine have PYTHON_TARGETS=python2_7 (only). I could loop over `qlist -IC` do an emerge -vp each grepping for this string. But is there an easier way. You are almost there, just learn the power of mighty eix: EIX_LIMIT=0 eix -I --only-names -\( -U python_targets_python2_ -! -U python_targets_python3_ -\) This will return you all installed packages having python2_* in their python targets, but not having python3_*. Many thanks Andrew. I have some problems, though. Your command shows media-libs/mesa (among many others) but emerge -vp media-libs/mesa doesn't show any python targets. Run plain: $ eix media-libs/mesa It has PYTHON_TARGETS=python2_7, though probably not in the version currently installed in your system. Please don't forget, that USE flag may appear and disappear during upgrades or downgrades. Best regards, Andrew Savchenko pgp3045y2fZIf.pgp Description: PGP signature
Re: [gentoo-user] How to find all packages which need Python2_7
On Tue, 3 Mar 2015 12:47:46 +0300 Andrew Savchenko wrote: EIX_LIMIT=0 eix -I --only-names -\( -U python_targets_python2_ -! -U python_targets_python3_ -\) On second though parenthesis are surplus here: EIX_LIMIT=0 eix -I --only-names -U python_targets_python2_ -! -U python_targets_python3_ Though be aware that some python2-only packages will require python2 support from packages supporting multiple python versions. Best regards, Andrew Savchenko pgpqhxwmfQ24e.pgp Description: PGP signature
Re: [gentoo-user] How to find all packages which need Python2_7
Hello, On Tue, 03 Mar 2015 10:21:19 +0100 Helmut Jarausch wrote: Hi, I'd like to install all packages which need Python, only for Python3 except those which cannot be installed for Python3. How can I find out which of the packages installed on my machine have PYTHON_TARGETS=python2_7 (only). I could loop over `qlist -IC` do an emerge -vp each grepping for this string. But is there an easier way. You are almost there, just learn the power of mighty eix: EIX_LIMIT=0 eix -I --only-names -\( -U python_targets_python2_ -! -U python_targets_python3_ -\) This will return you all installed packages having python2_* in their python targets, but not having python3_*. Best regards, Andrew Savchenko pgpqJxF4ePsjM.pgp Description: PGP signature
Re: [gentoo-user] distcc implementation failure
On Fri, 20 Feb 2015 17:09:02 -0800 Daniel Frey wrote:
Well, I decided to try distcc once again and set up a few machine to do so.
I have set the -march directive on each machine to its own (and not
native), and set up the accesses. It seems to work on most packages.
However, I've found that there's some packages that just don't work:
-mysql/mariadb errors out can't find synch.h
-ffmpeg errors out can't find windows.h
-xbmc and mythtv both failed as well, but this may be because of the
above two errors.
Looks like you are using pump mode. Disable it and use normal
distcc.
These are repeatable errors and they occur on all three of my mythtv
frontends.
Now, I've disabled distcc on one machine completely and above packages
compile fine, so it must be something to do with distcc. So that's what
I'm doing for the time being.
However, this poses another question: is there a way to tell portage to
NOT use distcc for certain packages? Rather than manually disabling it.
Yes, there is. Create a file /etc/portage/env/no-distcc.conf with
the following content:
FEATURES=${FEATURES} -distcc
and add the following entry in /etc/portage/package.env (create
file, if it doesn't exist):
category1/foo no-distcc.conf
category2/bar no-distcc.conf
Best regards,
Andrew Savchenko
pgpfH5oQn8S7W.pgp
Description: PGP signature
Re: [gentoo-user] compiling via distcc
On Wed, 11 Feb 2015 17:19:22 -0600 Jeff Smelser wrote:
People do it all the time. You have to set up the amd64's to cross compile.
https://wiki.gentoo.org/wiki/Distcc/Cross-Compiling
One doesn't need to setup cross-compilation in order to generate
x86 code on amd64 systems: 64-bit amd64 gcc natively supports this,
just be sure to add -m32 to your {C,CXX,F,FC,LD}FLAGS variables.
Care should be taken with -march=native or -mtune=native arguments.
Vanilla distcc doesn't support this. Patch can be taken here[1] or
distcc from my overlay[2] may be used.
Another approach will be to use one powerful box to build all
packages for an older system: either root filesystem may be
exported via NFS to a powerful host or just copy entire disk image
to and fro that host; afterwards just setarch chroot to that
image / NFS mount and build all packages using modern hardware.
An old but still useful guide is here[3].
[1] https://groups.google.com/forum/#!topic/distcc-patches/eeP-9pTgz7E
[2] git://git.overlays.gentoo.org/dev/bircoph.git sys-devel/distcc
[3] http://www.gentoo-wiki.info/HOWTO_Emerge_on_very_slow_systems
Best regards,
Andrew Savchenko
pgpqjFjXODScJ.pgp
Description: PGP signature
Re: [gentoo-user] updating netbook : Python needs libjpeg.so.8 : solved
On Thu, 29 Jan 2015 18:13:35 -0500 Philip Webb wrote: 150129 Andrew Savchenko wrote: On Thu, 29 Jan 2015 05:52:27 -0500 Philip Webb wrote: The 3rd stumble was Python, which refused to compile, as it couldn't find /usr/lib/libjpeg.so.8 . It seems that Libjpeg-turbo works only on 64-bit systems that 32-bit systems like my netbook have to use simple Jpeg. No. libjpeg-turbo works fine here on ~x86. So does your Libjpeg-turbo install /usr/lib/libjpeg.so.8 or does your Python look for a different library or is the Python you refer to 3.x rather than 2.7 ? I don't have libjpeg.so.8 on my system at all. Al for python, I have 2.7.8, 3.3.5-r1 and 3.4.2 installed. If during compilation package requires libjpeg.so.8 from you, you should fix pkg-config file(s) or rebuild an appropriate package(s). Best regards, Andrew Savchenko pgpb5wjMEr2oD.pgp Description: PGP signature
Re: [gentoo-user] Ghost cyber threat
On Thu, 29 Jan 2015 16:53:43 -0800 Grant wrote: glsa-check is working fine, it was a slotted issue. Still curious about a way to check for statically linked packages. There is no simple solution for this... USE flags static and static-libs handle cases where there is a choice between static and non-static version. In theory it is possible that some package (like boot loader helper) can be linked only statically, thus you will not be able to find it by USE flag. Though probability of this is very low, and due to a special nature of such binaries (or libraries) attack surface is even less. So you may assume your system reasonable secure if: - all GLSAs are applied; - there are no preserved libraries left (all packages using vulnerable libs must be rebuilt); - all static binaries and libraries depending directly or indirectly on vulnerable packages are rebuild; - there are no running processes using deleted files (reboot is a brute, but effective way to do this, otherwise one should grep lsof -n output for (deleted) files in use). - kernel should be updated to the latest version in branch if it is still supported, or upgrade to another branch, preferably LTS, if it is EOLed already. I have not seen GLSAs for kernel in ages, though old kernels definitely have serious security issues, and they may be far more serious than Ghost glibc bug. Best regards, Andrew Savchenko pgpgafG4_tW6U.pgp Description: PGP signature
Re: [gentoo-user] Ghost cyber threat
On Thu, 29 Jan 2015 20:53:31 -0500 Rich Freeman wrote: On Thu, Jan 29, 2015 at 7:53 PM, Grant emailgr...@gmail.com wrote: glsa-check is working fine, it was a slotted issue. Still curious about a way to check for statically linked packages. False positives in glsa data aren't unheard of - log those as bugs - vulnerable versions should be masked, and non-vulnerable versions shouldn't be flagged. So, if an unmasked package is flagged, there is a bug of some kind that should be fixed. It seems like glsa-check can't handle intervals at all. If package have several intermittent intervals of vulnerable and fixed versions, e.g. multiple slots fix fixes in several slots, glsa-check fail: https://bugs.gentoo.org/show_bug.cgi?id=106677 Quite an old bug... Best regards, Andrew Savchenko pgpAydWkL9zJS.pgp Description: PGP signature
Re: [gentoo-user] CFLAGs for kernel compilation
On Wed, 29 Apr 2015 13:31:13 +0200 Ralf wrote:
Hi,
just a short question: I don't like genkernel, I always compile my
kernel manually using menuconfig.
So the CFLAGs of my make.conf won't get applied.
What is the best way to (persistently) set the CFLAGs for the kernel
compilation?
- I don't like invoking 'CFLAGS=-O2 -march=foomake'
- I don't want to set CFLAGS as a persistent environment variable.
- I don't want to modify the kernel Makefile
Does it actually make sense to set an optimization level and -march?
Short answer: don't even try to use general CFLAGS for a kernel,
you'll badly damage its performance.
Long answer: context switching between integer and floating point
is very expensive, that's why kernel is integer only, any
non-integer calculations are implemented using fixed point (integer
numbers from CPU's POW). That's why kernel makes sure that no
floating point instructions sneaks in using CFLAGS, you may see a
lot of -mno-${intrucion_set} flags when running make -V. Futhermore
kernel needs several memory alignment flags which should not be
removed as well.
The proper way to fine-tune CFLAGS for a local CPU support will be
to use kernel-gcc-patches[1], as was pointed in other reply already.
This code will ensure that proper CPU support is enabled while
keeping all floating point instructions disabled. Just apply a
patch and select native arch in CPU arch menu.
[1] https://github.com/graysky2/kernel_gcc_patch
Best regards,
Andrew Savchenko
pgpuqTvm6pXaj.pgp
Description: PGP signature
Re: [gentoo-user] CFLAGs for kernel compilation
Hi, On Thu, 30 Apr 2015 18:26:22 +0200 Volker Armin Hemmann wrote: That simple. The kernel is too important and the people programming it know what they are doing. Don't set anything. It is retarded. - I don't like invoking 'CFLAGS=-O2 -march=foomake' - I don't want to set CFLAGS as a persistent environment variable. - I don't want to modify the kernel Makefile Does it actually make sense to set an optimization level and -march? no While I completely agree with you that kernel CFLAGS should not be randomly tampered with, I can't agree that -march itself is useless. Tests and results are available here: https://github.com/graysky2/kernel_gcc_patch Optimization is a very powerful tool if taken with care. Of course it may lead to a disastrous result if mindlessly used. Best regards, Andrew Savchenko pgpeiw2NIYR7p.pgp Description: PGP signature
Re: [gentoo-user] CFLAGs for kernel compilation
On Thu, 30 Apr 2015 20:11:52 +0200 Volker Armin Hemmann wrote: Am 30.04.2015 um 19:45 schrieb Andrew Savchenko: Hi, On Thu, 30 Apr 2015 18:26:22 +0200 Volker Armin Hemmann wrote: That simple. The kernel is too important and the people programming it know what they are doing. Don't set anything. It is retarded. - I don't like invoking 'CFLAGS=-O2 -march=foomake' - I don't want to set CFLAGS as a persistent environment variable. - I don't want to modify the kernel Makefile Does it actually make sense to set an optimization level and -march? no While I completely agree with you that kernel CFLAGS should not be randomly tampered with, I can't agree that -march itself is useless. Tests and results are available here: https://github.com/graysky2/kernel_gcc_patch Optimization is a very powerful tool if taken with care. Of course it may lead to a disastrous result if mindlessly used. Best regards, Andrew Savchenko if your mail client or browser is miscompiled, it is crashy, but worst case, a bunch of emails or bookmarks are lost. If the kernel fucks up, it might write across partition boundaries and destroy ALL your data. Or writes garbage instead of data. Don't f* with the kernel. That's why we have tests. Follow the link above. As for a personal experience: we have kernels with this patch and gcc native optimization in production for several years. Results are fine (no kernel related issues). In order not to crash kernel, do not add -ffast-math there. You need to have some understanding before touching such stuff. Best regards, Andrew Savchenko pgpoFIq0IXs1C.pgp Description: PGP signature
Re: [gentoo-user] Re: CFLAGs for kernel compilation
On Fri, 1 May 2015 05:09:51 + (UTC) Martin Vaeth wrote:
Andrew Savchenko birc...@gentoo.org wrote:
That's why kernel makes sure that no floating point instructions
sneaks in using CFLAGS, you may see a lot of -mno-${intrucion_set}
flags when running make -V.
So it should be sufficient that the kernel does not use float
or double, shouldn't it?
No. Optimizer paths may be very unobvious, i.e. I'll not be
surprised if under some conditions vectorizer may use float
instructions for int code.
I can hardly imagine that otherwise the compiler converts integer
or pointer arithmetic into floating point arithmetics, or is
this really the case for certain flags? If yes, why should these
flags *ever* be useful?
I mean: The context switching happens for non-kernel code as well,
doesn't it?
Yes, context switching happens for all code and have its costs. But
for userspace code context switching happens for many other
reasons, e.g. on each syscall (userspace - kernelspace switching).
Also some user applications may need high precision or context
switching pays off due to mass parallel data processing, e.g. SIMD
instructions in scientific or multimedia applications. But unless
special conditions mentioned above, fixed point is still faster in
userspace, some ffmpeg codecs have both fixed and floating point
implementations, you may compare them. Programming in fixed point
is much harder, so most people avoid it unless they have a very
goode reason to use it. And dont't forget that kernel is
performance critical unlike most of userspace applications.
Best regards,
Andrew Savchenko
pgpmtvztAOVCW.pgp
Description: PGP signature
Re: [gentoo-user] Changing the email address for bugzilla account
On Sat, 9 May 2015 07:06:25 -0300 José Romildo Malaquias wrote: Hello. I have requested Gentoo's Bugzilla to change the email address for my account, because the current address does not exist anymore. The site told me that An email has been sent to both old and new email addresses to confirm the change of email address. When confirming the change by following the link sent to the new email address, bugzilla tells me that The token you submitted does not exist, has expired, or has been canceled. I believe that means it expects me to click the old email link before the new email link. No, it doesn't. Well, at least at November 2014 (when I resubscribed from another e-mail) it did not. How to proceed now? Should I contact some admin to fix my account for me? If so, how can he/she be contacted? Just make another request on Bugzilla. Best regards, Andrew Savchenko pgpJye1cVvrb0.pgp Description: PGP signature
Re: [gentoo-user] Should www-plugins/adobe-flash have stable versions?
Hi, On Thu, 25 Jun 2015 16:02:00 -0700 walt wrote: Title: Adobe Releases Emergency to Patch Zero Day Under Active Exploitation in the Wild Description: Adobe released an out-of-band patch to address CVE-2015-3113, a Flash Player zero-day vulnerability that is actively being used by an APT group. The exploit has been ongoing since early this month via phishing emails and affects Windows, Mac, and Linux users. CVE-2015-3113 is a vulnerability in the way Flash parses Flash Video Files (FLV). The exploit bypasses memory-based protection such as ASLR and uses return-oriented programming (ROP) to bypass data execution prevention (DEP). Reference: https://helpx.adobe.com/security/products/flash-player/apsb15-14.html I see that the gentoo devs have already added the latest version to my ~amd64 machine (thanks, team) but what about all the people who are running stable gentoo? Taking how intensive vulnerability rate for adobe-flash is and considering its closed nature (e.g. no ability to fix issues in time yourself) I'd recommend to avoid its use at all. For cases where it can't be replaced (e.g. with gnash or html5-compatible browser) use isolated container or vm. Best regards, Andrew Savchenko pgpN4D6MH65Qf.pgp Description: PGP signature
Re: [gentoo-user] Google Chrome and audio capture
On Wed, 24 Jun 2015 07:08:01 +0100 Mick wrote: On Tuesday 23 Jun 2015 11:54:02 Neil Bothwick wrote: On Tue, 23 Jun 2015 05:26:31 -0500, Dale wrote: Take from that what you will. Note, the issues are for chromium and not for Google Chrome, shouldn't make a difference for what you want to know though. Thanks. That was what I was looking for. I guess they did do this then. This may be the first time I checked into a story from that site and it be true. It seems google did sort of sneak some code in there. o_O There is a now a USE flag to specifically enable this. It defaults to disabled but if you previously emerged chromium before the flag as added, you will still have it. Using --newuse will cause a world update to re-emerge chromium, but if you use --changed-use it doesn't, so re-emerge chromium if you want to get rid of this. What is the new USE flag and does it also apply to 43.0.2357.65? The flag is USE=hotwording, it applies to 45.0.2431.0 and later versions. Please note that this flag disables autoload of hotwording nacl plugin, so if one had earlier chromium versions installed, one will still have this plugin installed on a system. In order to remove already installed plugin one have to delete the following directory: ~/.config/chromium/Default/Extensions/lccekmodgklaepjeofjdjpbminllajkg See also: https://bugs.gentoo.org/show_bug.cgi?id=552298 Best regards, Andrew Savchenko pgpnWFEhA3sVN.pgp Description: PGP signature
Re: [gentoo-user] Profile listings
On Sun, 14 Jun 2015 19:22:14 + (UTC) James wrote: Hello Background: As a minimalist I'm trying to ferret out the differences in some of the more minimal profiles versus potential embedded profiles, across several different architectures: (arm32, arm64 x63_32 x86_64 ppc etc). I am also quite curious to find a tool that will clearly list the complete set of packages a given (eselected) profile will yield and the best ways to customize that list of minimal (critical) packages. So in /etc/portage/profiles, we have lots of good information. For example the 'base' dir currently lists 77 packages found in most profiles (?). The '/usr/portage/profiles/arch.list' dir lists not only the recognized arches but also Prefix Keywords. I'm not exactly sure how all of this profile stuff works; who decides what's (packages) in and out, package_masks etc etc. So my questions related to how does gentoo actually determines the exact list of programs that are minimally installed, with the specific arch and the profile selected? In previous times, I just put USE='-*' in the make.conf file and built upwards from there. Profile do all the stuff that can be done or overridden in /etc/portage, but they define some sane default sets of settings for common profiles. USE=-* will override all USE settings in your profile. As you were already warned, this may break stuff: e.g. expected functionality will not be available or package will refuse to build if it needs at least one of USE flags set (e.g. alternative foo providers). So you must test things very carefully with USE=-*. A set of default packages is defined in the packages file of each profile. Profiles usually have parent file which lists parent profiles: they are inherited, but may be overridden here and there in a child profile. If you want an absolutely minimal system, after you have set it up you may remove some packages even from the @system set. E.g. if you're sure you don't need man or ssh, remove corresponding packages. Just be careful here since it is easy to brick your system here. Best regards, Andrew Savchenko pgpLBt6CBmQM3.pgp Description: PGP signature
Re: [gentoo-user] What is the definition of a gentoo binary package?
On Fri, 29 May 2015 18:48:55 -0700 walt wrote: gory details of many frustrating hours of fighting with one particular gentoo package have been snipped to eliminate uncouth language I think of a gentoo binary package (e.g. oracle-jdk-bin) as an ebuild that fetches a file from somewhere, then merely unpacks that file and sticks the results in /opt/whatever. My experience today with libreoffice-bin has broken my mental model of how a gentoo binary package behaves. While trying to debug some broken behavior in the (non-binary) localc spreadsheet app, I decided to install libreoffice-bin as an experiment. The libreoffice-bin package wanted to drag in dozens of other non-binary gentoo packages before it would install itself, and even caused a blocker between two different versions of poppler. (I said no because I thought the blocker would make the entire experiment fail in the end.) It requires many other packages because it was compiled with specific versions of that packages. Of course that other packages will be source ebuilds mostly. You have blockers because your current system have different versions of some of that packages. These issues are usually solved either via slot installs or update of your currently installed system. Sometimes emerge -DNu @world may be needed. As for terminology, there are two kinds of binary packages: 1) binpkg — (usually) user-build binary packages, just a tarballs of source build packages. They are usufull for clustering, fast deployment, fast downgrades and so on. 2) The same binpkg packages, but put into the portage tree for specific hard to build packages, they usually have -bin suffix. That is your case. Best regards, Andrew Savchenko pgpE1rzm3lUeq.pgp Description: PGP signature
Re: [gentoo-user] recommended applications
Hi, On Sun, 24 May 2015 15:02:13 +0430 behrouz khosravi wrote: Hello everyone. After spending about a year in the world of linux (and mostly beloved gentoo!) I have realized that the key to a stable and fast machine is to keep the system as small as possible. So I am going to use console based tools mostly. I will also replace KDE with i3wm. What do you recommend as a replacement for kmail? (is mutt a good choise?) I depends on personal preferences. I'm not sure why, but I always had problems with intensive mail traffic and mutt. Also many mails are html-base and mutt is not the best way to deal with them. (I know that html mails are disgusting, but too many people use them these days to disregard this trend completely.) So I use sylpheed. It is GUI-based, can read html mails (but not write them, he-he). So it suits me well. Your mileage may vary, of course. What about IRC client? Use irssi. It is a reliable and highly configurable CLI solution. Torrent client? Use transmission. Just compile it without qt* and gtk flags. This is a client-server application, so transmission-daemon runs as system service as unpriviledged user and all management is done via nice CLI tool transmission-remote. Also transmission is fully-fledged solution supporting all trends like dht, utp and so on. You'll love it. I know that I can use google! but I would like to know your opinion. Browser-based solution can't be lightweight, so I try to avoid them whenever possible. Best regards, Andrew Savchenko pgp1oUncgslOe.pgp Description: PGP signature
Re: [gentoo-user] Re: want to upgrade 50 month old installation
On Tue, 4 Aug 2015 17:20:40 + (UTC) Grant Edwards wrote: On 2015-08-04, Felix Miata mrma...@earthlink.net wrote: That's right, May 2011, my first and only Gentoo installation, 32 bit on an old Athlon, which means no sse2, and kernel 2.6.37. It coexists in multiboot on one HD with 12 installations of Fedora and openSUSE. I'd like to upgrade it rather than installing fresh, Can we ask why? if it's doable. It probably is (for some degnerate value of doable). My gut feeling is that a fresh install is going to be a _lot_ easier and faster. A fresh install will take a couple hours. With all userspace software? No way on 32-bit Athlon. I have Athlon-XP. Even with distcc to Core2Duo it takes about 10 days of compilation time to build all stuff, I'm not counting time to fix all failures here. Well, I have 3000 packages installed... An upgrade will take somewhere between a couple days and a couple weeks. Best regards, Andrew Savchenko pgpIgLqQq7xXs.pgp Description: PGP signature
Re: [gentoo-user] want to upgrade 50 month old installation
On Tue, 4 Aug 2015 18:44:47 +0100 Neil Bothwick wrote: On Tue, 04 Aug 2015 13:12:42 -0400, Felix Miata wrote: 2-clone the existing partition to a larger one to be the upgrade target 3-boot the target 4-note that there exists no /etc/portage/ How did you clone it? It appears parts are missing. In the old days make.conf and other files were not in /etc/portage, but in /etc. At least non-optional stuff. Best regards, Andrew Savchenko pgpk_ozEwD__p.pgp Description: PGP signature
Re: [gentoo-user] iptables tunneling a chrooted Linux?
Hi, On Sat, 15 Aug 2015 06:53:30 +0200 meino.cra...@gmx.de wrote: on my Android tablet I have installed a Gentoo rootfs. I can start this by chgrooting it after Android has booted. Via xvnc I can connect from a running Android to the also running Gentoo Linux. If I set up a firewall as root (the Android is rooted) while I am in the chrooted Linux this firewall setting have to be active also in the Android environment, right? Of vice versa: I can track any network traffic of the Android OS inside my chrooted Linux, right? One kernel to rule them all...? If this is only chroot, you have to set all iptables rules (and other network configuration) in the host system environment (on Android). If you are using LXC or other container, involving network namespace separation (not sure this is doable on Android, kernel must support NET_NS as well as userspace tools should support this), then you have to set up network inside container and bridge/route it with the host system. Best regards, Andrew Savchenko pgp79Vhj9xFZf.pgp Description: PGP signature
Re: [gentoo-user] Packaging ASL
On Tue, 21 Jul 2015 07:18:58 -0600 Jc García wrote: 2015-07-21 5:41 GMT-06:00 Zeev Pekar zeev.pe...@avtechscientific.com: Dear Gentoo Developers, We have just released the version 0.1.4 of ASL - Advanced Simulation Library http://asl.org.il. May I ask somebody to volunteer to package it for Gentoo? Packaging efforts for other distros are underway and probably can be helpful for Gentoo [1]. Really interesting library, but I doubt you will get what you expect in this list, neither in the -dev list because as it is a library and AFAIK there's no applications requiring it, I doubt they'll want to add it to the main repository, but sure there's a place in gentoo for the library, the gentoo-science project[1], you can try create a github issue[2] requesting the add of the library there. You could also find more folks interested in it, this list I would say is mostly sysadmin/troubled-user stuff. If I find time I might try to make the ebuild and send pull request to the science repo, but I haven't learned much about CMake, so I would have to learn a bit more about it first. Regards, and thank you for the spread of such Important type software in a FOSS way. [1] https://wiki.gentoo.org/wiki/Project:Science [2] https://github.com/gentoo-science/sci (If you check the commits log you'll see that it is a very alive repo) I added sci-libs/asl-0.1.4 to the science overlay. Enjoy! Best regards, Andrew Savchenko pgpxlzvN6OU2s.pgp Description: PGP signature
Re: [gentoo-user] [OT] Very recent change in behavior of gmail imap/smtp servers
On Tue, 21 Jul 2015 18:34:25 -0700 walt wrote: Very soon after being invited to open a gmail account, I discovered that google offers non-web-browser access to their free (as in beer) email servers. This puzzled me (still does) because it seems to violate google's basic business model, which is based on advertising revenue. (I never see an advertisement when sending/reading email via smtp/imap, obviously.) 1. Even with pop3/gmail users occasionally use web interface: a) When travelling and location/country is changed, Google denies pop3/smtp login saying web access required. After web login (possibly with two-factor auth) user needs to confirm new location. b) In order to delete occasional spam messages as spam. c) In order to look through spam folder and retrieve false-positives. Unfortunately this happens sometimes. 2. Users are paying for services not only by reading ads, but with their private data: contents of their e-mails, various profiles, Google+ data and so on. Google has just introduced a 120-second delay before allowing login to their email servers. Just in the last day or two, literally. I can understand the delay for sending email (spammers) but why the same delay for reading email? I use POP3 and SMTP for gmail daily, no delays here. Maybe your ISP is doing something: either bug, or MitM or some other nasty things. Best regards, Andrew Savchenko pgpZ0HdjYsOda.pgp Description: PGP signature
Re: [gentoo-user] Re: In the fear of getting hacked (WLAN setup)
H, On Sat, 18 Jul 2015 06:47:21 +0300 Nikos Chantziaras wrote: The problem I (possibly needless) see is: While I am tinkering and testing the configuration I may setup an open Wifi access point without noticing it in first glance and BANG! get hacked ... in the worst case: unrecognized... What is the best practice here? Is there a certain independant configuration, which I can set, which prevents this scenario? Thank you very much in advance for any help! Best regards, Meino PS: If one knows the ASUS Memo Pad 7 ME176CX and knows a way to locally connect this tablet to the internet...this would be a way to go also. I would appreciate any hint in this case (Using Lollipop 5.0). If you don't have any daemons running that provide network services (have opened listen ports), you can't get hacked. This is usually a problem for Windows, which by default has a gazillion of services running (NetBIOS, printer/media/filesystem/everything sharing, messaging, remote desktop, etc.) On Gentoo, if *you* didn't set up a service, then nothing is listening on the network. Yes and no. If user enabled network interface and has no network daemons running, kernel still listens to that interface (ARP, icmp and so on) and may be hacked using vulnerabilities in network stack, protocol handlers or even network device drivers. By default Gentoo has no interfaces enabled, but usually they are set up during initial install. And users may be unaware that even without any network applications they may be vulnerable with enabled interfaces. Proper configuration of kernel, especially iproute2 and iptables can minimize such risks, of course. Best regards, Andrew Savchenko pgpKQ3DbwKSv3.pgp Description: PGP signature
Re: [gentoo-user] Packaging ASL
On Tue, 21 Jul 2015 07:18:58 -0600 Jc García wrote: 2015-07-21 5:41 GMT-06:00 Zeev Pekar zeev.pe...@avtechscientific.com: Dear Gentoo Developers, We have just released the version 0.1.4 of ASL - Advanced Simulation Library http://asl.org.il. May I ask somebody to volunteer to package it for Gentoo? Packaging efforts for other distros are underway and probably can be helpful for Gentoo [1]. Really interesting library, but I doubt you will get what you expect in this list, neither in the -dev list because as it is a library and AFAIK there's no applications requiring it, I doubt they'll want to add it to the main repository, There is no rule forbidding to have library with zero consumers in the main repository. As long, as someone maintains it. but sure there's a place in gentoo for the library, the gentoo-science project[1], you can try create a github issue[2] requesting the add of the library there. You could also find more folks interested in it, this list I would say is mostly sysadmin/troubled-user stuff. I agree, on science overlay there are more interested people. Mail to gentoo-science and gentoo-physics lists. I'm working on another branch of physics, so I'm not sure I'll be able to test this library thorough, though. Note to Zeev: if you're interested in packaging by various distributions, try to make their job easier. A quick check shows that there are version constrains on dependencies, e.g. =vtk-6.1, but they're not mentioned in the documentation. Fixing this will save people from digging into cmake files. Best regards, Andrew Savchenko pgpt687JWdJiO.pgp Description: PGP signature
Re: [gentoo-user] Gnupg-2.1.* nightmare
Hi, On Mon, 19 Oct 2015 10:57:37 +0200 Jean-Christophe Bach wrote: > I have a very similar problem, at least concerning your 2nd point > (duplicated keys). All my problems came when I updated gnupg from 1.x to > 2.x. I tried to solve them by playing with different 2.x versions but > with the last one it is broken: > > 1. I detect duplicated keys in the ring > 2. some friends told me my signature was bad > 3. I am not able to verify all the signatures with Mutt or Thunderbird > (I do not understand why it works for some signatures and not for others) > 4. with Thunderbird, I am not able anymore to sign/verify/cypher/decypher > > I think that it is related to your problems, but I have no clue to fix > that. I would also appreciate any help. I got help on gnupg-users mail list on this issue, see https://lists.gnupg.org/pipermail/gnupg-users/2015-October/054569.html Basically you need to re-import all your public keys, *delete* old pubring.gpg file (new file format is pubring.kbx) and restart your gpg-agent: gpg --export-ownertrust >myownertrust.lst gpg --export >allmykeys.gpg rm pubring.kbx killall gpg-agent gpg --import pgpVV_dBVquiH.pgp Description: PGP signature
[gentoo-user] Gnupg-2.1.* nightmare
Hello, I updated to gnupg-2.1.9 from 2.0.x on both my desktop and laptop and now I have big problems. 1. gpgme is now broken. Gpgme consumers (e.g. sylpheed, mcabber) can verify, encrypt and decrypt messages, but can't sign them. On signing I have the following issues: Please enter your PGP passphrase: [17:26:06] GPGME signature error: Unusable secret key Or: ** Sylpheed-WARNING: pgp_sign(): signing failed: User defined error code 1 I _can_ sign using the very same keys and plain gpg -s --default-key $id command. GPG itself works fine, something is amiss with gmgme. I updated gpgme, libgcrypt, libgpg-error and libassuan to the latest unstable versions and rebuilt consumer applications. Of course, keys were migrated to the new format using gpg --import and gpg-agent was restarted (I even rebooted the whole host), but problem is still here. The problem is even more strange, since I found a workaround way to sign messages in sylpheed. Program has three options for key selection: a) use default GPG key; b) select key by e-mail; c) use key with provided ID. Options b) and c) cause the error above, while option a) works, so by editing gpg.conf I can set default key id to what I need to sign a message. This is very inconvenient (since I have many keys), but at least works somehow. 2. I have duplicated keys in the ring with the same ID and fingerprint. Duplication happens only to _some_ of my keys where I have a secret key, fetched public keys of other users are not duplicated. Examples: a) Here I have the very same key twice: $ gpg --fingerprint -K 0x8EE705C07CFA83D3 sec rsa4096/0x8EE705C07CFA83D3 2012-09-11 [expired: 2015-09-11] Key fingerprint = 3F2D 1E49 4F96 2CE6 1597 F217 8EE7 05C0 7CFA 83D3 uid [ expired] Bircoph <birc...@jabber.ru> sec rsa4096/0x8EE705C07CFA83D3 2012-09-11 [expired: 2015-09-11] Key fingerprint = 3F2D 1E49 4F96 2CE6 1597 F217 8EE7 05C0 7CFA 83D3 uid [ expired] Bircoph <birc...@jabber.ru> b) Now comes more interesting: $ gpg --fingerprint -K 0x565953B95372756C sec rsa4096/0x565953B95372756C 2013-02-27 [expires: 2018-02-26] Key fingerprint = 63EB 04FA A30C 76E2 952E 6ED6 5659 53B9 5372 756C uid [ultimate] Andrew Savchenko <birc...@gmail.com> uid [ultimate] Andrew A. Savchenko (NRNU MEPhI) <aasavche...@mephi.ru> uid [ultimate] Andrew A. Savchenko (UT Department) <aasavche...@ut.mephi.ru> uid [ultimate] Andrew Savchenko (Gentoo Dev) <birc...@gentoo.org> uid [ultimate] Andrew A. Savchenko (XMPP) <birc...@jabber.ru> uid [ultimate] Andrew A. Savchenko (UT Department) <birc...@ut.mephi.ru> uid [ultimate] Andrey Savchenko (RHIC) <birc...@rcf.rhic.bnl.gov> ssb rsa4096/0x7AB649CA518C8321 2013-02-27 [expires: 2018-02-26] ssb rsa4096/0xF6535A33BA1EE48D 2015-01-13 [expires: 2018-01-12] sec rsa4096/0x565953B95372756C 2013-02-27 [expires: 2018-02-26] Key fingerprint = 63EB 04FA A30C 76E2 952E 6ED6 5659 53B9 5372 756C uid [ultimate] Andrew A. Savchenko (NRNU MEPhI) <aasavche...@mephi.ru> uid [ultimate] Andrew Savchenko <birc...@gmail.com> uid [ultimate] Andrew Savchenko (Gentoo Dev) <birc...@gentoo.org> uid [ultimate] Andrew A. Savchenko (XMPP) <birc...@jabber.ru> uid [ultimate] Andrew A. Savchenko (UT Department) <birc...@ut.mephi.ru> uid [ultimate] Andrew A. Savchenko (UT Department) <aasavche...@ut.mephi.ru> ssb rsa4096/0x7AB649CA518C8321 2013-02-27 [expires: 2018-02-26] ssb rsa4096/0xF6535A33BA1EE48D 2015-01-13 [expires: 2018-01-12] I have two versions of the same key: the latest and previous one (before I added one more e-mail uid to the key). This problem may be related to the first one, may be not, I'm not sure. It is possible that gpgme goes crazy with these duplicates. I have no idea how to remove duplicates and old versions. All gpg commands are tied to either key id, e-mail or fingerprint. They are all not unique to delete such duplicates. I have though that this may happen due to both secring.gpg and private-keys-v1.d present, but moving secring.gpg away doesn't help. Maybe manual editing of pubring.gpg will help to remove duplicates, but it will be quite hard to handle this binary format. Googling gave me very litte here: 1st issue: may happen for some custom gpgme client software, but no data on global failures after gnupg update. 2nd issue: may happen when key is stored in multiple sources and fetched from them, but I have no --keyring options in my gpg.conf (see attached file). Any ideas how to fix these issues, especially the signing failure are much appreciated. Best regards, Andrew Savchenko default-key 0x565953B95372756C require-cross-certification
Re: [gentoo-user] portage can not find local ebuild
Hi, On Thu, 17 Sep 2015 21:15:38 -0600 the...@sys-concept.com wrote: > I'm trying to emerge one of my local ebuild and portage can not find it. > What am I missing? > > emerge -avq nxclient > > emerge: there are no ebuilds to satisfy "nxclient". > > My settings: > > make.conf. > ... > PORTDRI_OVERLAY="/usr/local/portage" 1. PORTDIR_OVERLAY 2. It is no longer used, overlays should be declared at repos.conf these days. > cat /etc/portage/repos.conf/gentoo.conf > [DEFAULT] > main-repo = gentoo > > [gentoo] > location = /usr/portage > sync-type = rsync > sync-uri = rsync://192.168.139.7/gentoo-portage You are missing local overlay description. Add to gentoo.conf something like this: [local] priority = 100 location = /usr/local/portage Best regards, Andrew Savchenko pgpa7G4JRbOCP.pgp Description: PGP signature
Re: [gentoo-user] Re: Can't paste from selection in gtk-3 apps
On Wed, 16 Sep 2015 14:41:48 + (UTC) Grant Edwards wrote: > On 2015-09-16, J. Roeleveld <jo...@antarean.org> wrote: > > On Tuesday, September 15, 2015 06:57:36 PM Grant Edwards wrote: > >> On 2015-09-15, Grant Edwards <grant.b.edwa...@gmail.com> wrote: > >> > In most X11 apps I can select some text and then paste it somewhere > >> > else with a middle-click, or dump it to stdout with the command 'xclip > >> > -o'. That doesn't work for highligted text in gtk-3 apps (meld, > >> > evince, audacious, etc.). After selecting text in a gtk-3 app, if I > >> > middle-click in a terminal window it does nothing and 'xclip -o' just > >> > hangs. Selecting text elsewhere will deselect the text in the gtk-3 > >> > app, so gtk-3 isn't _completely_ ignoring X11 clipboards/buffers. > >> > > >> > Any ideas why gtk-3 copy/paste is broken and how to fix it? > >> > >> Ah, it turns out it's only a problem if you have multiple screens: you > >> can only paste a gtk-3 selection if the destination is on the same X11 > >> screen as the source. I'm pretty sure this is a known problem, but > >> I'm having trouble finding it again in the Gnome bugtracker... > > > > Must be related to gtk-3 then. > > > > I use 2 screens extensively and never experienced any issues like you > > describe. > > And you can select/paste from one screen to another where the source > is a gtk-3 app? > > I should clarify that I mean "screen" in the strict X11 usage. Using > Xinerama or the like to spread a single desktop across multiple > monitors is still a single screen setup. I'm trying to select text on > DISPLAY=:0.0 and paste it on DISPLAY=:0.1 Just for the record: I have the same problem with multihead setup (:0.0 and :0.1). While selecting with mouse doesn't work. Using menu functions "copy" in one application and "paste" in another one works fine. IIRC there are actually two buffers in X: for mouse selection and for copy-and-paste (both via menu and keyboard shortcuts). Best regards, Andrew Savchenko pgpQtXl3f62Nt.pgp Description: PGP signature
Re: [gentoo-user] Re: Can't paste from selection in gtk-3 apps
On Fri, 18 Sep 2015 16:22:00 +0200 Alan McKinnon wrote: [...] > >> That is a single X11 screen spread across two physical monitors. It > >> will not exhibit the gtk-3 selection bug. > >> > >> Are you sure you have two desktops and it's not just a single desktop > >> that is spread across two monitors? Can you drag a window from one > >> monitor to the other? If you can, then it's a single desktop. > > > > Yes, I can. > > When I maximize a window, it's only on 1 screen. > > > > This is how it seems "right" to me. > > > > Why would I want it to be different? Eg. windows can't be moved between > > screens? I don't see the point of having more than 1 screen in that case. > > There's a few reasons you might want more than one screen. Primary one > is two heads and two video cards with different resolutions and dpi. > Xinerama and big desktop et al will use the lower setting for both. Another reason (e.g. my case) is one dual head video card, but monitors with different dpi and colorspace. I tried xinerama: it looks really ugly on such setup. One more reason already mentioned by Grant is true for my case too: in my window manager (e16) I can have independent desktops on each screen, but not in xinerama mode. Probably this can be fixed in software, but might require a lot of work. JFYI dwm allows independent work on xinerama screens, but I have another issues with dwm. Best regards, Andrew Savchenko pgp0yKiSht8LF.pgp Description: PGP signature
Re: [gentoo-user] Distfiles cache setup
On Fri, 18 Sep 2015 17:48:15 -0700 Daniel Frey wrote: > On 09/18/2015 01:15 PM, Neil Bothwick wrote: > > How tight is space? eclean-dist only removes distfiles for packages that > > are no longer in the tree. So you can run it on one system and keep > > $DISTDIR reasonably trimmed. If you use the --package-names option, it > > will do as you suggest and only keep files needed by the machine running > > the command. > > > > Thanks for the replies. > > I regularly run eclean-dist on the mythtv frontends as I still have 32GB > SSDs on a couple of them. These are pretty lean as all file shares & > mythtv recordings are on the server that is running 24/7. > > I figured eclean-dist would wipe out everything that wasn't needed by > the machine it was run on, but if all it does is clean stuff that isn't > in the tree any longer that would work too. This is controllable: - eclean-dist cleans what is in the tree no longer and not installed in the system; - eclean-dist -d cleans everything not installed in the system. One can also restrict cleaning by file date (e.g. don't touch files newer than) or by file size; fetch-protected files may be spared as well. See eclean-dist --help for more details. > The server I'd be running it on has ample space. Which is why I was > debating over the http-replicator (thanks for the suggestion Peter!) and > just exporting the damn distfiles directory. > > I think I'm going to try exporting it first and see if it does what I > want first, if it works I'll leave it. :-) We have a cluster of identical machines. Exporting over NFS works just fine, though we exported not only /usr/portage, but /usr/local/portage, /var/lib/layman and /var/cache/edb/dep as well (we use sqlite backed for portage). Best regards, Andrew Savchenko pgpDWhszIE_6Q.pgp Description: PGP signature
Re: [gentoo-user] tc filter add ... fails
Hi, On Thu, 26 Nov 2015 13:52:20 +0100 lee wrote: > it seems I might be missing some kernel modules: > > > , > | heimdali ~ # tc filter add dev ppp0 parent : protocol all prio 10 basic > police mpu 64 rate 16000kbit burst 10kb action drop > | RTNETLINK answers: Invalid argument > | We have an error talking to the kernel > | heimdali ~ # > ` > > > This is a filter shorewall would add. I have enabled options as shown > in [1]. How can I find out which modules I'm missing, or what else went > wrong? See your dmesg after such command, it usually contains a hint on what is wrong. Also it is much better to write iptables / iproute / tc rules manually then using high level generators like shorewall — this will give you a good understanding on what is going on and how to optimize or tighten your setup. Best regards, Andrew Savchenko pgpqL3S9RiSjn.pgp Description: PGP signature
Re: [gentoo-user] blocking facebook
On Sat, 12 Dec 2015 01:29:20 -0500 waltd...@waltdnes.org wrote: > On Fri, Dec 11, 2015 at 08:03:14PM -0700, the...@sys-concept.com wrote > > Does anybody have an idea how to block facebook? > > > > I'm using dd-wrt. The "access restriction" can block http but not https > > and I'm not good in iptables :-/ > > In addition users are using VirtualBox on the network as well. > > An excerpt from my /var/lib/iptables/rules-save ruleset... > > [0:0] -A INPUT -s 31.13.24.0/21 -j FECESBOOK > [154:11168] -A INPUT -s 31.13.64.0/18 -j FECESBOOK > [0:0] -A INPUT -s 66.220.144.0/20 -j FECESBOOK > [0:0] -A INPUT -s 69.63.176.0/20 -j FECESBOOK > [0:0] -A INPUT -s 69.171.224.0/19 -j FECESBOOK > [0:0] -A INPUT -s 74.119.76.0/22 -j FECESBOOK > [0:0] -A INPUT -s 103.4.96.0/22 -j FECESBOOK > [0:0] -A INPUT -s 173.252.64.0/18 -j FECESBOOK > [0:0] -A INPUT -s 204.15.20.0/22 -j FECESBOOK > > [0:0] -A OUTPUT -d 31.13.24.0/21 -j FECESBOOK > [3763325:225839770] -A OUTPUT -d 31.13.64.0/18 -j FECESBOOK > [56:3360] -A OUTPUT -d 66.220.144.0/20 -j FECESBOOK > [0:0] -A OUTPUT -d 69.63.176.0/20 -j FECESBOOK > [874:52440] -A OUTPUT -d 69.171.224.0/19 -j FECESBOOK > [0:0] -A OUTPUT -d 74.119.76.0/22 -j FECESBOOK > [0:0] -A OUTPUT -d 103.4.96.0/22 -j FECESBOOK > [3306:198360] -A OUTPUT -d 173.252.64.0/18 -j FECESBOOK > [0:0] -A OUTPUT -d 204.15.20.0/22 -j FECESBOOK > > [3767715:226105098] -A FECESBOOK -j LOG --log-prefix "FECESBOOK:" --log-level > 6 > [3767715:226105098] -A FECESBOOK -j DROP +1. Just block their CIDR ranges. No need to do DPI like was suggested here. Of course smart users can use proxies or tunneling, so this is not 100% solution, but for the majority it will work. Just a tip here: use ipset hash:net for all this ranges and just a few iptables rules to check src and dst in FORWARD and/or INPUT/OUTPUT depending on whether host is router or target system, e.g. for dd-wrt will be sufficient: iptables -A FORWARD -m set --match-set facebook src -j DROP iptables -A FORWARD -m set --match-set facebook dst -j DROP A set can be created like this: ipset create facebook hash:net ipset add facebook 31.13.24.0/21 ... Of course logging may be enabled as above if desired. This way filtering will be much faster and blocklist may be updated without touching iptables rules. Gentoo init script support ipset rules save/load as well as iptables. Do not forget about ipv6 if it is enabled on your network. Best regards, Andrew Savchenko pgp4gZGYmgNxX.pgp Description: PGP signature
Re: [gentoo-user] QEMU/distcc combination question64-
On Sat, 2 Jan 2016 10:42:31 + Neil Bothwick wrote:
> On Fri, 1 Jan 2016 22:11:34 -0500, waltd...@waltdnes.org wrote:
>
> > I'm trying to run a distccserver in a 32-bit VM on a 64-bit host, for
> > the benefit of my ancient 32-bit-only netbook. Yeah, "it'll work" using
> > the native 64-bit host OS. But any stuff that links against 32-bit
> > libraries is going to be sent back to the netbook to compile locally.
> > That defeats the whole purpose of distcc. This is why I want the 32-bit
> > VM to compile for the 32-bit Atom. Here's the launch script for the
> > 32-bit VM on the i3 machine...
>
> I used to take a different approach. Instead of a VM I used a chroot
> that was a clone of the netbook, except that make.conf in the chroot
> included buildpkg in FEATURES and the netbook's make.conf have --usepkg in
> DEFAULT_OPTs. PKGDIR was an NFS share accessible to both.
Similar solution here, but instead of cloning, I NFS-mount root
from slow system using filescached to speedup I/O process and
placing all volatile data (/tmp, /var/tmp) either in local memory
or on fast local storage. This way there is no need to make manual
modifications twice or synchronize them somehow (e.g. when
modification of package.use or package.license during update is
needed).
I must warn that such approach should not be used for packages
using build-time profiling, like sci-libs/atlas or any ebuild with
USE="pgo" enabled; otherwise profiling will be wrong and targeted
on helper system instead of target box. In such cases distcc may be
used.
For 32-bit distcc on 64-bit host there is no need to chroot or
create VM (hey, they're hellishly slow!). Just add -m32 to your
*FLAGS to force 32-bit arch. (In some rare cases ebuild ignores
{C,CXX,F,FC}FLAGS, while this is a bug and should be fixed, this
can be worked around on distcc server by forcing -m32 for each
gcc call.
Best regards,
Andrew Savchenko
pgpDx8p1e6tpV.pgp
Description: PGP signature
Re: [gentoo-user] QEMU/distcc combination question64-
On Sat, 2 Jan 2016 13:27:52 -0500 waltd...@waltdnes.org wrote:
> On Sat, Jan 02, 2016 at 02:56:58PM +0300, Andrew Savchenko wrote
>
> > For 32-bit distcc on 64-bit host there is no need to chroot or
> > create VM (hey, they're hellishly slow!). Just add -m32 to your
> > *FLAGS to force 32-bit arch. (In some rare cases ebuild ignores
> > {C,CXX,F,FC}FLAGS, while this is a bug and should be fixed, this
> > can be worked around on distcc server by forcing -m32 for each
> > gcc call.
>
> -m32 in a 64-environment works for "Hello World". More complex code
> that requires arch-specific headers and libs will have problems. It
> "works" with Gentoo distcc.
No, it works for the entire system and for 8 years here, just don't
use pump mode. I don't use it because my 32-bit and 64-bit hosts
have quite a different software installed. Are you are sure
packages on both your host are identical in their list and
versions? Pump mode just have too many limitations to be used
outside of a cluster of (almost) identical hosts.
Best regards,
Andrew Savchenko
pgprPsWjRYF7_.pgp
Description: PGP signature
Re: [gentoo-user] modest list of miserable FAIL
On Sun, 03 Jan 2016 16:46:27 -0500 Alan Grimes wrote: > Okay, this is the list after the SECOND emptytree world. > > I then sync'd again and removed any packages scheduled for update from > this list and ran it again. > > Most of these are long-standing fails, the one that worries me the most > is klibc, that might byte me on reboot. That is a Gcc 5.3 incompatibility! gcc-5.3 is unstable for a reason. Most of 5.3-related failures come from the default C standard changed in gcc from gnu89 to gnu11. So one can fix most of such issues by setting old standard in CFLAGS. Of course there are also another reasons (e.g. stricter checks or standard compliance) and all problems should be dealt on per-case basis. Best regards, Andrew Savchenko pgpLG29Y3x2lW.pgp Description: PGP signature
Re: [gentoo-user] Full system encryption on Gentoo
On Wed, 30 Dec 2015 07:34:52 +1000 Hans wrote: > Hi, > > Is it possible to fully encrypt a Gentoo system as can be done with > Fedora, Suse, Arch Linux, Debian and Ubunto without using a unencrypted > USB boot stick or unencrypted /boot partition? > > If yes, where can I find instructions that really work on a BIOS only > box without UEFI, EFI, systemd using EXT4 file system? The easiest way is to use ATA password for your drive (go into BIOS menu for that or use some live image capable of that, e.g. any Linux with hdparm or mhdd). If you want to use Linux encryption (e.g. LUKS), you have to have some piece of data unencrypted, because bios/uefi needs to load some code which will be able to run kernel and decrypt your drive. This peace may be kernel + initrd on efi partition or boot partition, usb stick and so on. Of course it is possible to boot from external media (PXE, CD/DVD, USB stick) and have whole HDD/SSD encrypted. Though I see little point in whole / encryption. What is the point to encrypt /usr, /lib, /bin, /sbin? Just do this to /home, /var and other sensitive pieces. Best regards, Andrew Savchenko pgp3ktGTUqY72.pgp Description: PGP signature
Re: [gentoo-user] Re: Gcc 5.3
On Fri, 25 Dec 2015 12:40:48 -0800 walt wrote: > On Thu, 24 Dec 2015 10:18:27 -0500 > Alan Grimes <alonz...@verizon.net> wrote: > > > Hey, thanks for putting out gcc 5.3... > > > > Unfortunately, it fails to bootstrap on my machine. I am getting > > differences between the stage 2 and stage 3 compilers and it's > > dying... =( > > I'm waiting for 5.3.1 before I even try to install it on my main > desktop machine. There will be no 5.3.1 likely. Numeration scheme is changed from 5.x series: what was middle version is now major, what was minor is now middle. So 5.3 is a patch version of 5.0 the same as 4.9.3 is a patch version of 4.9.0. [offtopic] I really dislike this version race started mostly by chrome and systemd, but more and more software strives now for a high increment rate of major version. I wonder what they will do when large numbers like 1000 or 10000 will be reached. [/offtopic] Best regards, Andrew Savchenko pgpQZr78y9x78.pgp Description: PGP signature
Re: [gentoo-user] IPTABLES
Hi, On Tue, 22 Dec 2015 22:45:12 +0100 siefke_lis...@web.de wrote: > i try to run iptables, block bad ips and close the system. > > I want run firewall which block all INPUT, only ALLOW services i defined. > Ipset want to use to block spam ips, make it sure awesome as ever set rules > manuell. > > Im not so sure is okay, i has try and read but at end often i kick me out > from rootserver. So better ask what say profis of Gentoo. > > The Firewall Script > http://pastebin.com/b3305i41 I recommend you to read a good tutorial first, e.g. this one: https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html It is a bit old and isn't an ultimate description of all iptables features (you have manuals for that), but will give you a good understanding of how packet flow works and how they should be processed. I see three main problems with your current rules: 1. ESTABLISHED,RELATED packets are not accepted in the INPUT. You will have legitimate traffic blocked because of that. 2. Rules are vulnerable to SYN/ACK attack (see manual above on how to fix this). FORWARDed traffic is not protected at all (are tun+ interfaces completely trusted?). 3. Rules are far from being optimal, e.g. instead of having many enrtries for each accepted port, you can write just two rules using multiport target: one for tcp and another one for udp. These way your rules will be much faster. Also you should consider proper ordering of rules: those with higher hit rate should go first if this doesn't impact security scheme. There are minor issues of course, like blacklist check late on the rules (it should come one of the first, otherwise blacklisted hosts will be allowed to connect your open services). For remote debugging I recommend a small script like: ./iptables-current; sleep 1m; iptables-good where iptables-current is the script with your current rules you want to test and iptables-good are tested rules which work for you. This way if you'll screw up with current rules and remote control well be lost, in a minute good old rules will be applied. Of course, you should terminate this command with ^C if new rules are good, so that old ones will not be fired in a minute. Best regards, Andrew Savchenko pgpZWFGV4tF5F.pgp Description: PGP signature
