[gentoo-user] problem upgrading to apache 2.4.7 from 2.2.26
Hi. I am having problems upgrading to apache 2.4.7 from 2.2.26. It seems mod_perl and mod_python require
Re: [gentoo-user] problem upgrading to apache 2.4.7 from 2.2.26
On 24 Feb 2014 13:43, wrote: > > Hi. I am having problems upgrading to apache 2.4.7 from 2.2.26. It > seems mod_perl and mod_python require Anyway to fix this or am I stuck with the apache2.2 series? I was doing > this in my normal upgrade process and I postponed this particular mess > for quite a while, but now I have to make a decision one way or the > other. > > I am running the unstable gentoo x86_64. > > Any ideas would be appreciated. > > -- > Your life is like a penny. You're going to lose it. The question is: > How do > you spend it? > > John Covici > cov...@ccs.covici.com > It's quite possible that those modules need 2.2. Check upstream? If they're compatible, then just modify the ebuild and report a bug.
Re: [gentoo-user] problem upgrading to apache 2.4.7 from 2.2.26
Nilesh Govindrajan wrote: > On 24 Feb 2014 13:43, wrote: > > > > Hi. I am having problems upgrading to apache 2.4.7 from 2.2.26. It > > seems mod_perl and mod_python require > Anyway to fix this or am I stuck with the apache2.2 series? I was doing > > this in my normal upgrade process and I postponed this particular mess > > for quite a while, but now I have to make a decision one way or the > > other. > > > > I am running the unstable gentoo x86_64. > > > > Any ideas would be appreciated. > > > > -- > > Your life is like a penny. You're going to lose it. The question is: > > How do > > you spend it? > > > > John Covici > > cov...@ccs.covici.com > > > > It's quite possible that those modules need 2.2. Check upstream? If they're > compatible, then just modify the ebuild and report a bug. Looks like they don't work with the 2.4 series, so I will just mask that and go on with my update. Thanks. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] technical review of systemd
On 02/23/2014 06:01 PM, Canek Peláez Valdés wrote: > On Sun, Feb 23, 2014 at 5:06 AM, wrote: > [ snip ] >>> Corrupt filesystems or logs? >> logs. currently if fsck runs anywhere on boot i get zero log about what >> was done, so i prefer to do this on a running system. / is obviously >> special, so this is a pro that fsck is logged, but of course if / has >> issue i'm not sure what systemd would do other than drop you to emergency > Mmmmh; > > centurion ~ # journalctl /usr/lib/systemd/systemd-fsck -b > -- Logs begin at Tue 2013-09-24 13:39:03 CDT, end at Sun 2014-02-23 > 11:37:30 CST. -- > Feb 18 23:49:16 centurion systemd-fsck[1047]: Centurion: clean, > 1054301/3389904 files, 10171017/13533184 blocks > Feb 18 23:49:17 centurion systemd-fsck[1531]: Data: clean, > 308819/30531584 files, 105744823/122096390 blocks > Feb 18 23:49:17 centurion systemd-fsck[1568]: Files: clean, > 509045/9773056 files, 20704341/39072470 blocks > > I mean; my file systems were clean, but if some output was generated, > it would be there. > > I don't think I understand what do you mean by "zero log"? using openrc if i reboot a system that requires fsck on /mnt/data it will do an fsck. but not log anything anywhere about the result, which is why i put this as a pro. does systemd have configurable options for '/' so that it can run readonly rather than dropping to emergency in case of problems? >>> It's been a while since I've read the source code, but it isn't in >>> src/activate/activate.c[3]? >> ok so it does look like it would have a systemd-activate process for each >> socket being activated on behalf of a service. that makes me feel better >> than one process doing all of them. perhaps someone using service >> activation can do a 'ps aux' to confirm? > It is one instance of systemd-activate for each socket; I don't have > any socket activated service waiting for the first connection at this > moment, but it's obvious from the source code, I believe. It waits in > a loop for a connection, if specified it accepts it, and then launches > the service. > > [ snip ] > 7.chroots no longer work. forcing use of nspawn to ensure environment set up correctly. >>> I'm sorry, chroot doesn't work? First time I heard about it. While >>> systemd-nspawn is a gazillion times better than a simple chroot, you >>> *can* still use a chroot if you so desire. Where did you found that >>> chroot doesn't works? >> agreed nspawn is better due to the filesystem namespaces. chroot itself >> works, but the environment doesn't so it is effectively broken. full >> explaination from lennart's blog [5] This is quite old so i don't know if >> this has been fixed, seems unlikely based on what he described > Oh, I see. Yeah; you cannot longer start a service inside a chroot; > but in the blog post you cited [5], there is a recipe to launch a > chroot inside a unit file, working around this limitation. And, if you > are running systemd and want jailed services, systemd-nspawn works so > much better. > > For non service-start-up-and-management stuff (for example, boot from > a non-systemd LiveCD and emerge something you forgot that you need), > chroot still works. > > So, there is a workaround if you want to keep using chroot for jailed > services, and there's a better alternative. > > [ snip ] > >>> networkd (again, netctl is the command-line front-end) is not for >>> enterprise networks; on the contrary, is for the trivial cases. For >>> example, in a little web server I administer I have: >>> >>> $ cat /etc/systemd/system/network.service >>> [Unit] >>> Description=Static network service >>> After=local-fs.target >>> Before=network.target >>> Documentation=man:ifconfig(8) >>> Documentation=man:route(8) >>> >>> [Service] >>> Type=oneshot >>> RemainAfterExit=yes >>> ExecStart=/bin/ifconfig enp2s12 192.168.1.2 broadcast 192.168.1.255 >>> netmask 255.255.255.0 up >>> ExecStart=/bin/route add default gw 192.168.1.1 enp2s12 >>> >>> [Install] >>> WantedBy=multi-user.target >>> >>> (Yeah, I know, I should switch to ip, I'm sorry, I haven't had the time >>> yet). >>> >>> I'm going to get rid of this trivial network.service unit file when >>> 209 (or better 210) hits Gentoo. Cases like this are the use-cases for >>> networkd. >> what i don't understand is if you look at how openRC does it, it only >> really cares about up/down events and the /etc/conf.d/net is very >> comprehensive, in part because it passes everything to iproute2 to handle, >> the only thing i can't do without an additional shell script is tc qdiscs. >> i don't need or want a network manager, just need something that applies >> confs on startup / stop of interfaces. I'm a little surprised that there >> isn't an iproute2 .service file >> >> reading through your example, in fact this is preferrable to me than using >> a network manager but using iproute2. I would rather you keep this >> example in, and have this shown on the wiki or somewhere as this neatly >> resolves my network c
Re: [gentoo-user] Re: banshee installation without systemd
On 24/02/14 09:31, eroen wrote:
> On Sun, 23 Feb 2014 18:02:01 +0100, Fox wrote:
>> Hello,
>> after reading the thread about systemd somebody mentioned
>> sys-fs/eudev. I decided used because I had systemd only to used udev
>> and unmerge systemd.
>>
>> Now I can't use Banshee which I use as my music player because of the
>> next dependency tree:
>>
>> banshee
>> <- gnome-base/gnome-settings-daemon
>> <- sys-apps/gentoo-systemd-integration
>> <- sys-apps/systemd
>>
>> and systemd can't be used because it conflicts with eudev.
>>
>> Is there anyway to avoid emerge systemd in this case?
>>
>> Thank you,
>> Quim
>>
>>
>
> On a system running ~amd64 with eudev/openrc:
>
moriah ~ # emerge gnome-base/gnome-settings-daemon -vp
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] gnome-base/gnome-desktop-3.8.4:3/7 USE="introspection
-debug" 1,019 kB
[ebuild N ] x11-themes/gnome-themes-standard-3.8.4 USE="gtk" 3,765 kB
[ebuild N ] sys-apps/systemd-208-r2:0/1 USE="filecaps
firmware-loader gcrypt kmod lzma pam policykit python tcpd xattr -acl
-audit -cryptsetup -doc -gudev -http -introspection -qrcode (-selinux)
{-test} -vanilla" PYTHON_SINGLE_TARGET="python2_7"
PYTHON_TARGETS="python2_7" 2,335 kB
[ebuild N ] sys-apps/gentoo-systemd-integration-2 0 kB
[ebuild N ] gnome-base/gnome-settings-daemon-3.8.6.1 USE="colord
cups i18n policykit short-touchpad-timeout udev -debug (-openrc-force)
(-packagekit) {-test}" INPUT_DEVICES="-wacom" 1,543 kB
[blocks B ] sys-apps/systemd ("sys-apps/systemd" is blocking
sys-fs/eudev-1.4-r1)
I have a system like the above ... eudev/openrc with openrc-force in the
USE flags and the 13.0 profile (not desktop/gnome etc)
As you can see above, something is forcing (-openrc-force) - any ideas
on how to get it to honour the openrc-force flag or find out what is
causing the problem?
BillK
Re: [gentoo-user] Re: libpng slot usage
On 02/24/2014 02:06 AM, eroen wrote: On Sun, 23 Feb 2014 17:54:07 +0100, Fox wrote: Hello, I am trying to compile fltk-1.1.10 both using an ebuild from [1] and with just the downloaded source. I think this version needs libpng 1.2 which is installed in one of the slots. Using the source code and cmake with FLTK_USE_SYSTEM_PNG off it complies fine. I can see that it automatically points the libs to /usr/lib64/libpng12.so.0. The ebuild does not use cmake, it uses autoconf/automake which is also suported. I tried to build the code this way with --disable/enable-localpng with no luck. The problem is the used png.h file. Which is /usr/include/png.h which points to /usr/include/libpng16/png.h but I need the one from version 1.2. I thought slots would allow to have both versions of the library and use them but only one include file is present: $ equery f libpng:1.2 * Searching for libpng:1.2 ... * Contents of media-libs/libpng-1.2.50-r1: /usr /usr/lib64 /usr/lib64/libpng12.so.0 /usr/share /usr/share/doc /usr/share/doc/libpng-1.2.50-r1 /usr/share/doc/libpng-1.2.50-r1/CHANGES.bz2 /usr/share/doc/libpng-1.2.50-r1/README.bz2 /usr/share/doc/libpng-1.2.50-r1/TODO.bz2 Any idea on how to solve this problem? Some how it should be possible maybe not using the system lib like I did with cmake but I can't figure it out how to do it with autoconf/automake. Thank you, Quim [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/fltk/fltk-1.1.10.ebuild?view=log The libpng slots, apart from "0", only install the shared library files, not the headers. They are intended for compatibility with old binaries for which no source code is available, not for building new software. Afaik the common opinion is that different libpng versions are mostly source compatible, and minor patching to other things is preferable to inventing a non-standard way to make the libpng implementation switchable at build-time. Is there a reason you can not use fltk-1.1.10-r2.ebuild [1] in stead, which incorporates a patch [2] for libpng-1.5 (which probably still works with 1.6), as well as various other fixes? 1: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/fltk/fltk-1.1.10-r2.ebuild 2: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/fltk/files/fltk-1.1.10-libpng15.patch I didn't know about this patch, this should make the job.
Re: [gentoo-user] Re: banshee installation without systemd
On Mon, 24 Feb 2014 17:52:13 +0800, William Kenworthy wrote: > As you can see above, something is forcing (-openrc-force) - any ideas > on how to get it to honour the openrc-force flag or find out what is > causing the problem? The flag is masked because it is an unsupported option. Unmask it by adding this to /etc/portage/profile/package.use.mask gnome-base/gnome-settings-daemon -openrc-force -- Neil Bothwick "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." signature.asc Description: PGP signature
[gentoo-user] Re: banshee installation without systemd
On Mon, 24 Feb 2014 17:52:13 +0800, William Kenworthy
wrote:
> moriah ~ # emerge gnome-base/gnome-settings-daemon -vp
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild N ] gnome-base/gnome-desktop-3.8.4:3/7
> USE="introspection -debug" 1,019 kB
> [ebuild N ] x11-themes/gnome-themes-standard-3.8.4 USE="gtk"
> 3,765 kB [ebuild N ] sys-apps/systemd-208-r2:0/1 USE="filecaps
> firmware-loader gcrypt kmod lzma pam policykit python tcpd xattr -acl
> -audit -cryptsetup -doc -gudev -http -introspection -qrcode (-selinux)
> {-test} -vanilla" PYTHON_SINGLE_TARGET="python2_7"
> PYTHON_TARGETS="python2_7" 2,335 kB
> [ebuild N ] sys-apps/gentoo-systemd-integration-2 0 kB
> [ebuild N ] gnome-base/gnome-settings-daemon-3.8.6.1 USE="colord
> cups i18n policykit short-touchpad-timeout udev -debug (-openrc-force)
> (-packagekit) {-test}" INPUT_DEVICES="-wacom" 1,543 kB
> [blocks B ] sys-apps/systemd ("sys-apps/systemd" is blocking
> sys-fs/eudev-1.4-r1)
>
>
> I have a system like the above ... eudev/openrc with openrc-force in
> the USE flags and the 13.0 profile (not desktop/gnome etc)
>
> As you can see above, something is forcing (-openrc-force) - any ideas
> on how to get it to honour the openrc-force flag or find out what is
> causing the problem?
>
> BillK
>
openrc-force is masked in /usr/portage/profiles/base/use.mask:
# Pacho Ramos (28 Sep 2013)
# This USE flag is available after long dicussion in
# http://www.gossamer-threads.com/lists/gentoo/dev/276077
# to let some prople not able to run systemd to skip the dep (#480336).
# Enabling this you will get a fully unsupported Gnome setup that
# could suffer unexpected problem, don't expect support for it then.
openrc-force
If you are unfamiliar with gentoo's profiles, most (all the
handbook-documented) profiles inherit the "base" profile which
contains this file, which means this mask is in effect on most systems.
None of the other profiles currently disable this use-mask. emerge's
output indicates to you that this use flag is masked by enclosing it in
parenthesis, check the documentation for the --verbose switch in
emerge(1)[1].
Use-flag masks from the selected profile (and the opposite, force)
override the use-flag settings normally made by users in make.conf and
package.use. User modifications to the profile should be made
in /etc/portage/profile/, see portage(5)[2].
To un-mask the openrc use flag, you can create the
file /etc/portage/profile/use.mask with this line:
-openrc-force
1: https://dev.gentoo.org/~zmedico/portage/doc/man/emerge.1.html
2: https://dev.gentoo.org/~zmedico/portage/doc/man/portage.5.html
--
eroen
signature.asc
Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, Feb 24, 2014 at 3:11 PM, Yuri K. Shatroff wrote: > 24.02.2014 02:32, Alan McKinnon wrote: >> [1] For lack of a better term, let's just call systemd here a "system >> controller". What is this ONE thing a system controller should do and do >> it well? > > > An init daemon generally does one thing well. it's obvious you haven't thought this through. consider, for a moment, that the "one thing well" that an init daemon is supposed to do is "run programs that do arbitrary things to get the system to an arbitrary state". do you not see a problem? -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [ ] up to you [x] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] Re: banshee installation without systemd
On 24/02/14 18:39, Neil Bothwick wrote: > On Mon, 24 Feb 2014 17:52:13 +0800, William Kenworthy wrote: > >> As you can see above, something is forcing (-openrc-force) - any ideas >> on how to get it to honour the openrc-force flag or find out what is >> causing the problem? > > The flag is masked because it is an unsupported option. Unmask it by > adding this to /etc/portage/profile/package.use.mask > > gnome-base/gnome-settings-daemon -openrc-force > > Ta, thats the hint I needed. Thanks, BillK
[gentoo-user] EAPI 4-python
Hello, I am trying to install an ebuild that used EAPI=4-python getting the error: API of python.eclass in EAPI="4-python" not established I googled the problem but there is not much to read (or at least I could not find much) and what is there is old. So I wonder what is the problem with this and if there is a way to use it as there are many ebiulds (maybe only in overlays, I am not sure) that use it. Quim
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
24.02.2014 16:39, Mark David Dumlao пишет: On Mon, Feb 24, 2014 at 3:11 PM, Yuri K. Shatroff wrote: 24.02.2014 02:32, Alan McKinnon wrote: [1] For lack of a better term, let's just call systemd here a "system controller". What is this ONE thing a system controller should do and do it well? An init daemon generally does one thing well. it's obvious you haven't thought this through. consider, for a moment, that the "one thing well" that an init daemon is supposed to do is "run programs that do arbitrary things to get the system to an arbitrary state". do you not see a problem? No. As you say, ``an init daemon is supposed to do is "run programs``, until here you're right, but then you start talking about things the init doesn't do but the programs do. In your wording, an init daemon is also a DBMS, an MTA, a network startup daemon, a firewall, a getty and whatever program runs on the system. There was a post in this thread with a link to an opinion what an `ideal init` would do: just fork and exec anything in /etc/init.d or somewhere else. In the real world, it's of course not so simple. But it doesn't mean you may imply init's responsibility for `arbitrary` tasks. If I write an ASM program with an illegal instruction, is it the init's problem? If my mail/web server is DDOSed, is it the init's problem? If my HDD dies, also the init's problem? -- Regards, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, Feb 24, 2014 at 9:42 PM, Yuri K. Shatroff wrote: > > > 24.02.2014 16:39, Mark David Dumlao пишет: > >> On Mon, Feb 24, 2014 at 3:11 PM, Yuri K. Shatroff >> wrote: >>> >>> 24.02.2014 02:32, Alan McKinnon wrote: [1] For lack of a better term, let's just call systemd here a "system controller". What is this ONE thing a system controller should do and do it well? >>> >>> >>> >>> An init daemon generally does one thing well. >> >> >> it's obvious you haven't thought this through. >> >> consider, for a moment, that the "one thing well" that an init daemon >> is supposed to do is >> "run programs that do arbitrary things to get the system to an arbitrary >> state". >> >> do you not see a problem? > > > No. As you say, ``an init daemon is supposed to do is "run programs``, until > here you're right, but then you start talking about things the init doesn't > do but the programs do. In your wording, an init daemon is also a DBMS, an > MTA, a network startup daemon, a firewall, a getty and whatever program runs > on the system. Let's try to talk you through to a soft landing here. When we say init, are we just referring to pid 1, or are we referring to something else entirely? OpenRC is often spoken of in the same breath as systemd, as if they were the same kind of thing. That sounds fair but think about it for a second: openrc - as most people talk about it - isn't even pid 1. as most people talk about it, openrc includes the functions.sh, the net.eth0 scripts, the script for starting your /sys, /proc, mounting local and network filesystems, setting the hostname and so on. They may be written in a different language from pid1, but when people talk about openrc, they are talking about that whole ball of wax. From a systems perspective - they're parts of the same thing. Even discounting the parts that you think are ridiculous, like databases and loggers, there are clearly more parts in there above than can be cleanly defined as "one thing". Who gets to decide which is the "one thing" or not? You? Don't you rely on openrc to set your hostname? Load your kernel modules? Run your sysctl? Set any miscellaneous options in /sys? Mount your filesystems? Go ahead, define for everyone, once and for all, what this "one thing" is. Does this one thing init include a subsystem for reading separate environment files per-service? Isn't this just feature creep? Can't you just edit the init scripts to add those in? I mean, they are already scripts after all. And they're in /etc, they're meant to be configured. Does this one thing include service dependencies? Why sysv has gone for a LONG time without them, just a sequencing, and that works fine for almost all cases anyways. Isn't this just feature creep? Can't you just edit the init scripts to start any dependent services? Point is - go look at any arbitrary feature that's part of your "init system" and you could cry to hell and high water that it's violating the "one thing", whatever that "one thing" is that doesn't seem to be defined. At least with systemd the parts are cleanly split off into separate executables. Yes, it's technically not needed for pid 1 to create tempfiles for other programs. That's why systemd-tmpfiles is its own tiny program, that does one "one thing" (create tempfiles for other programs) and nothing else. Yes, it's technically not needed for pid 1 to check your filesystems. That's why systemd-fsck is once again, a separate utility, that does "one thing" (run fsck) well. Yes, it's technically not needed for pid 1 to remount your filesystems readwrite. Again there's a separate utilty for that, that does nothing but just that. It's clear to me that there's an analogue between the different parts of a full openrc system - that just happen to be implemented in scripts - and the different parts of a systemd system - that just happen to be implemented in small binaries. Every time people complain about systemd having too many features, they just _casually_ forget to mention that, for instance, their init actually asks them if they want to run interactive (why do that when you can specify from the boot loader?) or checks the configuration files of their daemons to see if they're valid and prompts the user to config if not. They just _casually_ fail to mention that their init has plugins for NetworkManager and ifplugd, that it comes with scripts for setting the consolefont. Meanwhile systemd does those same things, and it's bloated, theirs isn't. Oh you're going to say that that's not fair, it's external optional stuff, it's not _really_ part of openrc, but that's not intellectually honest is it? Heck, I could do that same. I could control my bootup process so that I run my own stuff instead of systemd-fsck, systemd-tmpfiles, systemd-mount and all that jazz and run plain old init scripts in their place. Why bother? The reality is that - init scripts don't do just one thing, and don't even do it well. -- This email is:
[gentoo-user] Re: EAPI 4-python
On Mon, 24 Feb 2014 14:30:29 +0100, Fox wrote:
> Hello,
> I am trying to install an ebuild that used EAPI=4-python getting the
> error:
>
> API of python.eclass in EAPI="4-python" not established
>
> I googled the problem but there is not much to read (or at least I
> could not find much) and what is there is old. So I wonder what is
> the problem with this and if there is a way to use it as there are
> many ebiulds (maybe only in overlays, I am not sure) that use it.
>
> Quim
>
>
Afaik the *-python eapis are almost exclusively used by Arfrever's
Progress overlay (and, by extension, funtoo). The error message you
show seems to be from python.eclass in the main gentoo tree, which does
not take un-official eapis into account. The code in question for
reference (lines 30-32):
if ! has "${EAPI:-0}" 0 1 2 3 4 5; then
die "API of python.eclass in EAPI=\"${EAPI}\" not established"
fi
You might be able to use the ebuild stand-alone by also copying the
relevant eclasses from whereever you got the ebuild into your local
overlay (where I presume you put the ebuild?). However, from previous
experience with the Progress overlay, you might want to use the entire
overlay though layman in stead. Due to unfortunately incompatible
python-implementation dependencies with gentoo proper it's rather an
all-or-nothing deal.
--
eroen
signature.asc
Description: PGP signature
Re: [gentoo-user] Re: EAPI 4-python
On 02/24/2014 04:32 PM, eroen wrote:
On Mon, 24 Feb 2014 14:30:29 +0100, Fox wrote:
Hello,
I am trying to install an ebuild that used EAPI=4-python getting the
error:
API of python.eclass in EAPI="4-python" not established
I googled the problem but there is not much to read (or at least I
could not find much) and what is there is old. So I wonder what is
the problem with this and if there is a way to use it as there are
many ebiulds (maybe only in overlays, I am not sure) that use it.
Quim
Afaik the *-python eapis are almost exclusively used by Arfrever's
Progress overlay (and, by extension, funtoo). The error message you
show seems to be from python.eclass in the main gentoo tree, which does
not take un-official eapis into account. The code in question for
reference (lines 30-32):
if ! has "${EAPI:-0}" 0 1 2 3 4 5; then
die "API of python.eclass in EAPI=\"${EAPI}\" not established"
fi
You might be able to use the ebuild stand-alone by also copying the
relevant eclasses from whereever you got the ebuild into your local
overlay (where I presume you put the ebuild?). However, from previous
experience with the Progress overlay, you might want to use the entire
overlay though layman in stead. Due to unfortunately incompatible
python-implementation dependencies with gentoo proper it's rather an
all-or-nothing deal.
The ebuild is from the ezod overlay. I am trying to use the ROS related
packages like wstool, rosdep. etc. They all seem to use this EAPI. I
thought that using this overlay would be easier than using pip but
apparently it's not is it?
Re: [gentoo-user] RAID 1 vs RAID 0 - Read perfonmance
On 24-Feb-14 7:27, Facundo Curti wrote: n= number of disks reads: raid1: n*2 raid0: n*2 writes: raid1: n raid0: n*2 But, in real life, the reads from raid 0 doesn't work at all, because if you use "chunk size" from 4k, and you need to read just 2kb (most binary files, txt files, etc..). the read speed should be just of n. Definitely not true. Very rarely you need to read just one small file. Mostly you need many small files (i.e. compilation) or a few big files (i.e. database). I do not know what load you expect, but in my case raid0 (with SSD) gave me about twice the r/w speed on heavily-loaded virtualization platform with many virtual machines. And not only speed is higher, but also IOPS are splitted to two disks (nearly doubled). I did some testing with 2xSSD/512GB in raid1, 2xSSD/256GB in raid0 and 3xSSD/256GB in raid5 (I used 840/pro SSD with quite good HW-controller but I think with mdadm it might be similar). Raid0 was way ahead of other two configurations in my case. Finally I went for 4xSSD/256GB in raid10 as I needed both speed and redundancy... Jarry -- ___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 24.02.2014 18:33, Mark David Dumlao wrote: On Mon, Feb 24, 2014 at 9:42 PM, Yuri K. Shatroff wrote: 24.02.2014 16:39, Mark David Dumlao пишет: On Mon, Feb 24, 2014 at 3:11 PM, Yuri K. Shatroff wrote: 24.02.2014 02:32, Alan McKinnon wrote: [1] For lack of a better term, let's just call systemd here a "system controller". What is this ONE thing a system controller should do and do it well? An init daemon generally does one thing well. it's obvious you haven't thought this through. consider, for a moment, that the "one thing well" that an init daemon is supposed to do is "run programs that do arbitrary things to get the system to an arbitrary state". do you not see a problem? No. As you say, ``an init daemon is supposed to do is "run programs``, until here you're right, but then you start talking about things the init doesn't do but the programs do. In your wording, an init daemon is also a DBMS, an MTA, a network startup daemon, a firewall, a getty and whatever program runs on the system. Let's try to talk you through to a soft landing here. When we say init, are we just referring to pid 1, or are we referring to something else entirely? Sorry but I think I was quite clear: An init daemon generally does one thing well. Following a "Unix way" design, Everything else should be done by something else. OpenRC is often spoken of in the same breath as systemd, as if they were the same kind of thing. That sounds fair but think about it for a second: Sorry but did I mention OpenRC? openrc - as most people talk about it - isn't even pid 1. as most people talk about it, openrc includes the functions.sh, the net.eth0 scripts, the script for starting your /sys, /proc, mounting local and network filesystems, setting the hostname and so on. Obviously. That is why OpenRC *can* be treated as a "Unix way" thing, because the whole bunch are pretty interchangeable, independent and do their own things well, don't they? They may be written in a different language from pid1, but when people talk about openrc, they are talking about that whole ball of wax. From a systems perspective - they're parts of the same thing. Even discounting the parts that you think are ridiculous, like databases and loggers, there are clearly more parts in there above than can be cleanly defined as "one thing". Who gets to decide which is the "one thing" or not? You? Don't you rely on openrc to set your hostname? Load your kernel modules? Run your sysctl? Set any miscellaneous options in /sys? Mount your filesystems? Go ahead, define for everyone, once and for all, what this "one thing" is. > Does this one thing init include a subsystem for reading separate environment files per-service? Isn't this just feature creep? Can't you just edit the init scripts to add those in? I mean, they are already scripts after all. And they're in /etc, they're meant to be configured. Sorry, do you mean *everything* in /etc/ is to be configured? That's a convention to put the init stuff in /etc/. You could as well put it in /usr, /boot, wherever. In FreeBSD, the local init stuff resides in /usr/local/etc. In Solaris, elsewhere. In AIX, elsewhere. Why do you look at everything from a single linux's angle? Please note, I never say the 'linux way' but the "Unix way". And you might also notice, an init system does not really much depend on the init daemon. It's pretty possible to run a SysV init daemon on a BSD system, or the opposite, because all the init daemon does is start some init scripts. Maybe /etc/rc, maybe /etc/init.d/* ... Does this one thing include service dependencies? This depends on what one thing you want the init daemon to do. In e.g. FreeBSD, the dependencies are handled by /etc/rc. > Why sysv has gone for a LONG time without them, just a sequencing, and that works fine for almost all cases anyways. Isn't this just feature creep? Can't you just edit the init scripts to start any dependent services? > Point is - go look at any arbitrary feature that's part of your "init system" and you could cry to hell and high water that it's violating the "one thing", whatever that "one thing" is that doesn't seem to be defined. At least with systemd the parts are cleanly split off into separate executables. Yes, it's technically not needed for pid 1 to create tempfiles for other programs. That's why systemd-tmpfiles is its own tiny program, that does one "one thing" (create tempfiles for other programs) and nothing else. Yes, it's technically not needed for pid 1 to check your filesystems. That's why systemd-fsck is once again, a separate utility, that does "one thing" (run fsck) well. Yes, it's technically not needed for pid 1 to remount your filesystems readwrite. Again there's a separate utilty for that, that does nothing but just that. Okay, but can I take them out and substitute mine own easily? How? Is there a well-defined standard? Is there a well-defined objective, a target at whi
[gentoo-user] Re: EAPI 4-python
On Mon, 24 Feb 2014 16:49:56 +0100, Fox wrote:
> On 02/24/2014 04:32 PM, eroen wrote:
> > On Mon, 24 Feb 2014 14:30:29 +0100, Fox
> > wrote:
> >> Hello,
> >> I am trying to install an ebuild that used EAPI=4-python getting
> >> the error:
> >>
> >> API of python.eclass in EAPI="4-python" not established
> >>
> >> I googled the problem but there is not much to read (or at least I
> >> could not find much) and what is there is old. So I wonder what is
> >> the problem with this and if there is a way to use it as there are
> >> many ebiulds (maybe only in overlays, I am not sure) that use it.
> >>
> >> Quim
> >>
> >>
> > Afaik the *-python eapis are almost exclusively used by Arfrever's
> > Progress overlay (and, by extension, funtoo). The error message you
> > show seems to be from python.eclass in the main gentoo tree, which
> > does not take un-official eapis into account. The code in question
> > for reference (lines 30-32):
> >
> > if ! has "${EAPI:-0}" 0 1 2 3 4 5; then
> > die "API of python.eclass in EAPI=\"${EAPI}\" not
> > established" fi
> >
> > You might be able to use the ebuild stand-alone by also copying the
> > relevant eclasses from whereever you got the ebuild into your local
> > overlay (where I presume you put the ebuild?). However, from
> > previous experience with the Progress overlay, you might want to
> > use the entire overlay though layman in stead. Due to unfortunately
> > incompatible python-implementation dependencies with gentoo proper
> > it's rather an all-or-nothing deal.
> >
> The ebuild is from the ezod overlay. I am trying to use the ROS
> related packages like wstool, rosdep. etc. They all seem to use this
> EAPI. I thought that using this overlay would be easier than using
> pip but apparently it's not is it?
>
Installing python packages though pip (without using virtualenv or such)
is not generally a great idea on gentoo, in particular many
not-quite-standard packages seem to get confused by gentoo's
python-exec and overwrite it, or automagically pull in some other
dependency (typically setuptools) which is already installed, and
clobber files that have been especially patched for gentoo with
non-working vanilla versions.
Looking at [1], it appears the overlay maintainer just recently (last 4
commits) moved to use the 4-python eapi. From having made this mistake
myself in the past, I would guess he added the eclasses to his overlay
locally and forgot to add them to git. Alternatively, an updated
layout.conf might not have been commited.
You could try creating an eclass/ folder in the overlay and put
distutils.eclass and python.eclass from the Progress overlay[2] in
there.
I notice that the ebuilds in question seem to be quite cookie-cutter
(as python ebuilds generally are, bless them!). Functionally migrating
them to the gentoo python eclasses should not be a large job.
Change `EAPI=4-python` to `EAPI=5`,
change `inherit distutils` to `inherit distutils-r1`,
add a line `PYTHON_COMPAT=( python2_7 python3_3 )` (or as appropriate).
Slightly more involved (but not strictly necessary to make it work
locally) is to fix up the dependencies. In particular, python library
dependencies should specify the required python implementation, like so:
DEPEND="dev-python/pyyaml[${PYTHON_USEDEP}]"
See the wiki[3] for more information on python ebuilds :-)
I CC the ezod overlay maintainer on this email to inform about the issue
and facilitate a proper fix, either in documentation form or overlay
code.
1: http://git.overlays.gentoo.org/gitweb/?p=user/ezod.git
2: http://code.google.com/p/gentoo-progress/
3: https://wiki.gentoo.org/wiki/Project:Python/distutils-r1
--
eroen
signature.asc
Description: PGP signature
Re: [gentoo-user] RAID 1 vs RAID 0 - Read perfonmance
Thank you all! :) I finally have all clear. I'm going to do raid 10. Any way, I'm going to do a benchmark before to install. Thank you!;) 2014-02-24 14:03 GMT-03:00 Jarry : > On 24-Feb-14 7:27, Facundo Curti wrote: > > n= number of disks >> >> reads: >>raid1: n*2 >>raid0: n*2 >> >> writes: >>raid1: n >>raid0: n*2 >> >> But, in real life, the reads from raid 0 doesn't work at all, because if >> you use "chunk size" from 4k, and you need to read just 2kb (most binary >> files, txt files, etc..). the read speed should be just of n. >> > > Definitely not true. Very rarely you need to read just one small file. > Mostly you need many small files (i.e. compilation) or a few big files > (i.e. database). I do not know what load you expect, but in my case > raid0 (with SSD) gave me about twice the r/w speed on heavily-loaded > virtualization platform with many virtual machines. And not only speed > is higher, but also IOPS are splitted to two disks (nearly doubled). > > I did some testing with 2xSSD/512GB in raid1, 2xSSD/256GB in raid0 and > 3xSSD/256GB in raid5 (I used 840/pro SSD with quite good HW-controller > but I think with mdadm it might be similar). Raid0 was way ahead of > other two configurations in my case. > > Finally I went for 4xSSD/256GB in raid10 as I needed both speed and > redundancy... > > Jarry > > -- > ___ > This mailbox accepts e-mails only from selected mailing-lists! > Everything else is considered to be spam and therefore deleted. > >
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 25, 2014 at 1:42 AM, Yuri K. Shatroff wrote: > On 24.02.2014 18:33, Mark David Dumlao wrote: > Sorry but I think I was quite clear: > > An init daemon generally does one thing well. > Following a "Unix way" design, Everything else should be done by something > else. ... >> At least with systemd the parts are cleanly split off into separate >> executables. >> Yes, it's technically not needed for pid 1 to create tempfiles for >> other programs. >> That's why systemd-tmpfiles is its own tiny program, that does one "one >> thing" >> (create tempfiles for other programs) and nothing else. Yes, it's >> technically >> not needed for pid 1 to check your filesystems. That's why systemd-fsck is >> once again, a separate utility, that does "one thing" (run fsck) well. >> Yes, >> it's technically not needed for pid 1 to remount your filesystems >> readwrite. >> Again there's a separate utilty for that, that does nothing but just that. > > > Okay, but can I take them out and substitute mine own easily? How? Is there > a well-defined standard? Is there a well-defined objective, a target at > which the systemd software set will be considered stable 'version 1.0'? I am > asking again, if a bug is found in the systemd infrastructure, is it > possible (i.e. how much effort it would take) to fix it temporarily on a > running system? > It's almost as if you don't bother reading the docs on something, then comment that they're impossible. Yes you can take them out and substitute yours, in fact I just mentioned that I could replace them with plain old init scripts. systemd services are controlled by the same unit files that control other services. >> OpenRC is often spoken of in the same breath as systemd, as if they were >> the same kind of thing. That sounds fair but think about it for a second: > > > Sorry but did I mention OpenRC? > There is a context to this conversation that you appear to be selectively ignoring, wherein openrc, sysvinit, and systemd are being compared, and only one of them is being demonized as anti-Unix. I compared systemd above _both_ to openrc and to sysvinit. The point being ethat systemd is not comparable to _just_ init, but to the whole init ball of wax. > >> openrc - as most people talk about it - isn't even pid 1. as most people >> talk about it, openrc includes the functions.sh, the net.eth0 scripts, >> the script >> for starting your /sys, /proc, mounting local and network filesystems, >> setting >> the hostname and so on. > > > Obviously. That is why OpenRC *can* be treated as a "Unix way" thing, > because the whole bunch are pretty interchangeable, independent and do their > own things well, don't they? > interchangeable: I also pointed out that the systemd parts, like openrc parts, are interchangeable, and do their own things well. I did mention, for example, that I could replace systemd-fsck with an init script. Heck I could disable it entirely if I didn't care about fsck (for instance, in a container). Likewise the mount unit the network units, etc etc can be disabled or replaced if wanted. independent: I do not think independent is an important concept for Unixness, as most of the parts of postfix, dovecot, xorg, qmail, squid, etc are not independent. What you DIDN'T and have not been able to point out is what this one thing that pid 1 is supposed to do. What you also have not been able to demonstrate is that openrc or other init systems' parts follow the same criteria. There's was a long-standing bug, for instance, in that functions.sh has not been separated from openrc. I believe Canek was one of the people pushing to have it done so - to better support systemd - something that violates "independence" and "interchangeability". > Sorry, do you mean *everything* in /etc/ is to be configured? That's a > convention to put the init stuff in /etc/. You could as well put it in /usr, > /boot, wherever. In FreeBSD, the local init stuff resides in /usr/local/etc. > In Solaris, elsewhere. In AIX, elsewhere. Why do you look at everything from > a single linux's angle? Please note, I never say the 'linux way' but the > "Unix way". /etc scripts ARE meant to be configured. At the very minimum, from the perspective of gentoo, they are treated by the conf-update tool as config files. You are expected to copy and customize init scripts for custom or local daemons. > And you might also notice, an init system does not really much depend on the > init daemon. It's pretty possible to run a SysV init daemon on a BSD system, > or the opposite, because all the init daemon does is start some init > scripts. Maybe /etc/rc, maybe /etc/init.d/* ... This is besides the point. Different programs are free to rely on different standards and different features. That openrc can't work or depend on systemd is not systemd's fault, in the same way that not all parts of postfix can work or depend on all parts of qmail. None of this says anything about the unixiness of postfix or qmail, none
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 24.02.2014 22:55, Mark David Dumlao wrote: [...] I didn't attribute anything to you you didn't say. It just so happens, though that there is a context to this conversation, which, if you ignore, just tends to perpetuate a lot of confusion. I am responding to questions and points in that context for the benefit of the larger conversation, not just for you. I'll be short. You also ignored much of what I asked, and tend to answer "that's besides the point" to things which IMO matter. If you are responding to my post, then I'm expecting you to be replying to me, rather than to the benefit of the larger conversation, if you didn't say otherwise. ;-) As for the context, I was answering to Alan's ``I've been wondering about this concept of "the*nix design principles"... `` which (as well as my answer) didn't mention systemd and openrc at all. In this thread, there's already a rattling mixture of contexts. I'm opting out of it, because I no longer see the benefit of the larger conversation here. Nevertheless, thank you for your time and answers. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sunday 23 Feb 2014 23:54:32 Canek Peláez Valdés wrote: > On Sun, Feb 23, 2014 at 5:12 PM, Mick wrote: > > [ snip ] > > > Well, I'm no authority on this since I can't code, > > My point exactly. I think your point is not valid, unless you view Linux as an operating system intended for and inviting comments only from an inspired l33t who can code and it is *only* their user requirements that count. I understand though that it is their/their employer's choice as to how they spend their coding time and what they spend it on. I am not ungrateful for their generosity whether I agree with their approach or not. > And that's the point; the people doing this changes *obviously > understand Unix*. They understand it so well that they are able to > look at it honestly, beyond dogma or articles of faith, and see its > downsides, so they can try to fix them. You seem to have a lot of faith in their approach and choice-limiting decisions. They have made arbitrary decisions in developing their software in ways contrary to their predecessors. I don't know if this is because they are cleverer than their predecessors, or more ignorant/arrogant/wrong. > > http://en.wikipedia.org/wiki/Unix_philosophy > > This reminds me of the people that quote from religious books to argue > about anything non theological. The "rules" and "sound bites" in the > links you provide are there to summarize rules of thumb; they are NOT > scripture, and they are certainly NOT the only way to get a > technically good program that is easily maintainable. In other words, > you can ignore most of them, or just following them to a point, and > anyway end up with a sound design and a technically great program that > is easy to maintain and extend. I agree. This is not a religion, but a statement of design principles based on some observations of what seemed to work (at the time) that were made after the event. > The people with coding experience (or most of them anyway) understand > this; we are not a religion, we don't have prophets that speak the > undeniably truth. We have highly skilled developers who can have > opposing views on how to design and implement many different ideas, > and that doesn't (necessarily) means that any of them are wrong. We agree again, except that some of these opposing ideas are limiting future development choices and current user options. > There are many ways to solve a problem of sets of problems. Having > Emacs doesn't mean vi is "wrong", nor having GNOME means KDE is > "wrong", nor the other way around. KDE took a wrong turn the moment it started emulating Gnome by hardcoding redland a whole host of components in its pursuit of a semantic desktop, removing choice from users who would be otherwise very happy with the KDE3 functionality. Many users have voted with their feet - not because they can code better or code at all, but because they still have a choice as plain users. At least KDE has not hardcoded a requirement for systemd as Gnome now has. > >> I've now concluded it's a myth, much like invisible pink unicorns. > >> > >> Is it like the kernel? A huge monolithic chunk of code with support for > >> modules? > > > > I would think that although the kernel has grown over the years, it has > > not done so like systemd. You can still *not* build modules you don't > > need in your kernel. > > This has nothing to do with "Unix principles"; it's just that someone > willing and able implemented the different options. Well, "someone willing and able implemented the different options", but did so by following the paradigm of modular development. > > The Unix design philosophy may not be globally applicable, but has served > > Linux well over the years. > > No; what has served Linux is to have developers willing and able to > write the necessary code, following whatever design they decide is the > correct one. I think we have a fundamental disagreement here. The Unix design principles inc. modularisation and extensibility make good sense when seen from the perspective of many contributors adding to and improving code in a piece meal fashion. X11 did not follow this approach and ended up with convoluted unmaintainable code that had to be broken up. Having developers able and willing to write code is of course a precondition, but not just any code. It has to be code which others can pick up, improve and extend. In other words, they have to write code which is versatile, being respectful of and keeping in mind future development effort. > > Lennart has de facto introduced a different way of > > developing his Linux code, which to others and me seems more restrictive. > > First of all, it's not only Lennart; the systemd repo has (literally) > dozens of contributors with write access. > > Second of all, calling "restrictive" the tightly integrated approach, > is exactly as constructive as calling "anarchic" the loosely > integrated one. Like "Unix principles"
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, Feb 24, 2014 at 2:54 PM, Mick wrote: > On Sunday 23 Feb 2014 23:54:32 Canek Peláez Valdés wrote: >> On Sun, Feb 23, 2014 at 5:12 PM, Mick wrote: >> >> [ snip ] >> >> > Well, I'm no authority on this since I can't code, >> >> My point exactly. > > I think your point is not valid, unless you view Linux as an operating system > intended for and inviting comments only from an inspired l33t who can code and > it is *only* their user requirements that count. Of course comments can come from anyone. But it stands to reason that, in the first place, the people *writing* the code would primarily listen to people that actually know what they are talking about. In the second place, even if they *listen*, that doesn't mean they will *implement* whatever a random set of users ask for. > I understand though that it is their/their employer's choice as to how they > spend their coding time and what they spend it on. I am not ungrateful for > their generosity whether I agree with their approach or not. Glad to hear that. >> And that's the point; the people doing this changes *obviously >> understand Unix*. They understand it so well that they are able to >> look at it honestly, beyond dogma or articles of faith, and see its >> downsides, so they can try to fix them. > > You seem to have a lot of faith in their approach and choice-limiting > decisions. I have nothing even remotely close to "faith". I can read code, I can read design documents, and I follow the discussions in the different forums where systemd is the topic. It's my educated and reasonable conclusion that their approach is correct (in general terms; of course I don't agree with everything). > They have made arbitrary decisions in developing their software in > ways contrary to their predecessors. Excuse me, but where do you get the idea to call their decisions "arbitrary". Again, read the code (if you are able to), read the design documents, read the discussions. You can disagree with their decisions (I do with some of them); but I don't think there is a single one that can be called "arbitrary". > I don't know if this is because they are > cleverer than their predecessors, or more ignorant/arrogant/wrong. Not necessarily "cleverer"; they just have more software history available to determine what it works and what it doesn't. >> > http://en.wikipedia.org/wiki/Unix_philosophy >> >> This reminds me of the people that quote from religious books to argue >> about anything non theological. The "rules" and "sound bites" in the >> links you provide are there to summarize rules of thumb; they are NOT >> scripture, and they are certainly NOT the only way to get a >> technically good program that is easily maintainable. In other words, >> you can ignore most of them, or just following them to a point, and >> anyway end up with a sound design and a technically great program that >> is easy to maintain and extend. > > I agree. Glad to hear that. > This is not a religion, but a statement of design principles based > on some observations of what seemed to work (at the time) that were made after > the event. You said it: "at the time". Hardware is highly dynamic now; hard drives, sound cards, network cards, memory and even CPUs can come and go while the systems is running. SysV (and therefore, OpenRC) was *never* intended to work like that, so what it does it does badly, if at all. >> The people with coding experience (or most of them anyway) understand >> this; we are not a religion, we don't have prophets that speak the >> undeniably truth. We have highly skilled developers who can have >> opposing views on how to design and implement many different ideas, >> and that doesn't (necessarily) means that any of them are wrong. > > We agree again, except that some of these opposing ideas are limiting future > development choices and current user options. No they are not; THE CODE IS OUT THERE. Anyone can take the code at any point in time before systemd, and start a new path if this one turns out to be failing. There is no "limiting" no one and nothing; while there are people willing and able to, any design path can be explored. >> There are many ways to solve a problem of sets of problems. Having >> Emacs doesn't mean vi is "wrong", nor having GNOME means KDE is >> "wrong", nor the other way around. > > KDE took a wrong turn the moment it started emulating Gnome by hardcoding > redland a whole host of components in its pursuit of a semantic desktop, > removing choice from users who would be otherwise very happy with the KDE3 > functionality. Many users have voted with their feet - not because they can > code better or code at all, but because they still have a choice as plain > users. That's your analysis; I really don't like KDE, but I love my GNOME 3 desktop. That's subjective and has nothing to do with the topic at hand; I was talking about how different (and sometimes opposite) ways to solve a problem doesn't mean (necessarily) that one of
[gentoo-user] OT(?) new linux cellphone
Gentoo on a cell phone next? http://www.techrepublic.com/article/the-ubuntu-phone-is-official-let-the-madness-begin/#ftag=RSS56d97e7 enjoy!
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Monday 24 Feb 2014 21:48:39 Canek Peláez Valdés wrote: > > At least KDE has not hardcoded a requirement for systemd as Gnome now > > has. > > GNOME has no hardcoded requirement for systemd; do your homework. I beg your pardon, I got this wrong - I extrapolated from the Gentoo state of affairs (I don't use or follow the Gnome project). -- Regards, Mick signature.asc Description: This is a digitally signed message part.
