Re: [gentoo-dev] Re: Making systemd more accessible to normal users
Good news. I've been able to make logind work with OpenRC and GNOME 3.6 (which means that GNOME 3.8 can work as well). Disclaimer: I use systemd as device manager. I don't know if my logind (there is a bug about it) works with udev without further hacking. See: https://plus.google.com/u/0/107663298003289209275/posts/TxjqZkniR9f Now, the problem is that, as I wrote before, we're more and more drifting away from what upstream is supporting. Today the source of all our troubles is just GNOME, I am afraid that tomorrow it will expand beyond it. There are technical advantages for both distro makers and desktop environment makers in using systemd (besides the disadvantages). For instance, having a centralized tool for collecting system and user logs is certainly something that would make our job easier, having working (or mostly working) init scripts provided directly by upstream projects would reduce our maintenance burden in the long run. Anyway, I'm not trying to convince anybody in using either init systems, I am just suggesting that you should try both and decide yourself. Which translated, is the same goal as making systemd more accessible to you. -- Fabio Erculiani
Re: [gentoo-dev] readme.gentoo.eclass: Add a note informing people a file is being installed for future reference
El mar, 14-05-2013 a las 23:54 +0200, Pacho Ramos escribió: El mar, 14-05-2013 a las 23:27 +0200, Ulrich Mueller escribió: On Tue, 14 May 2013, Pacho Ramos wrote: As discussed at: https://bugs.gentoo.org/show_bug.cgi?id=457598#c4 we need a way to inform users the ebuild is installing a README.gentoo file with needed information for configuration tips and so. Attached patch does it. Could the notice be separated from the preceding message by at least one empty line? Ulrich Sure, I was thinking on that also :) + 18 May 2013; Pacho Ramos pa...@gentoo.org readme.gentoo.eclass: + Add a note informing people a file is being installed for future reference, + http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg58207.html +
Re: [gentoo-dev] Re: Making systemd more accessible to normal users
On Fri, May 17, 2013 at 10:45:18PM -0500, William Hubbs wrote No one is arguing against that. All this thread is about is making systemd a first-class citizen, like OpenRC/Sysvinit, so it will be as smooth as possible for someone who wants to switch between the two. It seems that some of the proposals are crossing the line to make systemd first-class and openrc second-class. *THAT* is what's causing the complaints. The best analogy I can think of is the more extreme type of affirmative action that effectively amounts to racial discrimination against white people. The pro-systemd group here is advocating double-standards... 1) http://www.gossamer-threads.com/lists/gentoo/dev/272180?do=post_view_threaded Having a package to install every systemd unit in existence just clutters the end user's system and makes it harder to tell which units are actually valid. Yet openrc users are supposed to accept having their systems cluttered with systemd units. 2) I suggested keying on a systemd USE flag, to inform portage whether or not to install systemd units. I was told that https://bugs.gentoo.org/show_bug.cgi?id=198901 forbade using it that way. And therefore systemd config files would be installed regardless of flags. Therefore udev/eudev don't have systemd flags. But both have openrc flags, and will not run OK on an openrc machine without the openrc flag. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: Making systemd more accessible to normal users
Am Samstag, 18. Mai 2013, 19:02:12 schrieb Walter Dnes: [snip] Having a package to install every systemd unit in existence just clutters the end user's system and makes it harder to tell which units are actually valid. Yet openrc users are supposed to accept having their systems cluttered with systemd units. This is getting more and more ridiculous. Next, systemd users will (correctly) remark that their systems are unnecessarily cluttered with openrc init scripts. Then, I may remark that my system is unnecessarily cluttered by quite some cmake modules that can search for libraries I'll never install. Not to speak of the boost sub-libraries that none of my installed packages uses. Etc etc etc. Please get a grip. 2) I suggested keying on a systemd USE flag, to inform portage whether or not to install systemd units. I was told that https://bugs.gentoo.org/show_bug.cgi?id=198901 forbade using it that way. And therefore systemd config files would be installed regardless of flags. Therefore udev/eudev don't have systemd flags. But both have openrc flags, and will not run OK on an openrc machine without the openrc flag. The decision was made long ago. Use flags are not the correct way to control solely the installation of a few small files. If you really care (i.e. embedded systems), this is what install masks are for. Then just modify your /etc/make.conf accordingly. Believe me, that goes much faster than writing another discussion mail. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Making systemd more accessible to normal users
On Sat, May 18, 2013 at 1:38 PM, Andreas K. Huettel dilfri...@gentoo.org wrote: The decision was made long ago. Use flags are not the correct way to control solely the installation of a few small files. This was really the heart of the discussion where the decision was made before. USE flags should control things that affect dependencies, especially linked dependencies. If a package wants to pull in systemd or link to it, then it should have a USE flag if at all possible. Likewise if a package wants to pull in openrc or link to it then it should have a USE flag. When you're talking about just a few text files it isn't worth it. Those who disagree can use INSTALL_MASK and nuke them from orbit. Openrc isn't going anywhere as long as somebody cares to maintain it. I don't see that changing anytime soon, and if it does change the only thing its users can do is step up and maintain it (or pay somebody to do it for them). That's pretty-much how everything works on Gentoo, or any other volunteer distro. Don't worry about it - considering we had a few devs step up and fork udev I doubt openrc is going away anytime soon. Rich
Re: [gentoo-dev] Re: CPU use flag detection
On Fri, May 17, 2013 at 9:39 PM, Ryan Hill dirtye...@gentoo.org wrote: On Wed, 15 May 2013 16:59:57 +0200 yac y...@gentoo.org wrote: Hi, I was recently investigating what cpu flags do I have and how does it work. I have put what I have so far at [1]. So I thought I let you know in case someone wants to chip in. [1] https://github.com/yaccz/cufd I've seen gcc -Q --help=target giving false results before due to the way that options are parsed and some flags that set other flags not getting processed on the --help code path. The second option you list is better. -native doesn't set 3dnow, mmx, sse, sse2, sse3, ssse3 or sse4a. I'm guessing they're just handed through the -march setting. Yes, they are. sys-apps/cpuid is awesome. MMX2/MMXEXT still confuses me. SSE1 and /Enhanced/ 3DNow! added some extra MMX instructions. Some (pshufw and pmulhuw particularly) turn out to be rather useful in software compositing. I use them in the pixman MMX code. See http://mattst88.com/programming/asmref/ (Sorry about the broken search box. It works, you just don't see what you type) Set Requires = Enhanced 3DNow!. The instructions that are listed as 'Enhanced 3DNow! or SSE1' are what are known as MMX2 or MMXEXT. The particularly annoying thing about using them is that there's no -mmmx2 or -mmmxext, but turning on -msse causes illegal instructions to be generated for old AMD or Geode CPUs, while -m3dnow causes the same problems for Intel CPUs. And, there's not actually even an -m3dnowext flag (anymore?) anyway, so it's kind of a mess.
Re: [gentoo-dev] Re: Making systemd more accessible to normal users
Is the real problem just the god damn unit/init files?! Damn, who cares about 2KiB files in the age of GiBs?! You can install 1000 of them that it will only take 2MiB of storage, so please, quit complaining about this. One thing dev's should take care is (not that affects me, 'cause I really don't care) is mentions to rc-update on einfo's. Again, I really don't care, but, for the sake of making them (openrc, systemd, etc) equal, that really shouldn't be mentioned. On Sat, May 18, 2013 at 5:47 PM, Rich Freeman ri...@gentoo.org wrote: On Sat, May 18, 2013 at 1:38 PM, Andreas K. Huettel dilfri...@gentoo.org wrote: The decision was made long ago. Use flags are not the correct way to control solely the installation of a few small files. This was really the heart of the discussion where the decision was made before. USE flags should control things that affect dependencies, especially linked dependencies. If a package wants to pull in systemd or link to it, then it should have a USE flag if at all possible. Likewise if a package wants to pull in openrc or link to it then it should have a USE flag. When you're talking about just a few text files it isn't worth it. Those who disagree can use INSTALL_MASK and nuke them from orbit. Openrc isn't going anywhere as long as somebody cares to maintain it. I don't see that changing anytime soon, and if it does change the only thing its users can do is step up and maintain it (or pay somebody to do it for them). That's pretty-much how everything works on Gentoo, or any other volunteer distro. Don't worry about it - considering we had a few devs step up and fork udev I doubt openrc is going away anytime soon. Rich
Re: [gentoo-dev] Re: CPU use flag detection
On Sat, May 18, 2013 at 12:14:35PM -0700, Matt Turner wrote The particularly annoying thing about using them is that there's no -mmmx2 or -mmmxext... Now that you mention it... [i660][waltdnes][~] grep mmxext /usr/portage/profiles/use.local.desc media-libs/libpostproc:mmxext - Enable mmx2 support. media-plugins/vdr-softdevice:mmxext - enables MMXExt support media-video/ffmpeg:mmxext - Enables mmx2 support media-video/libav:mmxext - Enable mmx2 support. media-video/mplayer:mmxext - Enables mmx2 support media-video/mplayer2:mmxext - Enables mmx2 support x11-libs/pixman:mmxext - Enable MMX2 support. ...shouldn't mmxext be moved out of use.local.desc into use.desc? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Re: Making systemd more accessible to normal users
On Sat, May 18, 2013 at 01:02:12PM -0400, Walter Dnes wrote: On Fri, May 17, 2013 at 10:45:18PM -0500, William Hubbs wrote No one is arguing against that. All this thread is about is making systemd a first-class citizen, like OpenRC/Sysvinit, so it will be as smooth as possible for someone who wants to switch between the two. It seems that some of the proposals are crossing the line to make systemd first-class and openrc second-class. *THAT* is what's causing the complaints. The best analogy I can think of is the more extreme type of affirmative action that effectively amounts to racial discrimination against white people. The pro-systemd group here is advocating double-standards... 1) http://www.gossamer-threads.com/lists/gentoo/dev/272180?do=post_view_threaded Having a package to install every systemd unit in existence just clutters the end user's system and makes it harder to tell which units are actually valid. Agreed, I don't propose having a package that installs all of the systemd units. Yet openrc users are supposed to accept having their systems cluttered with systemd units. 2) I suggested keying on a systemd USE flag, to inform portage whether or not to install systemd units. I was told that https://bugs.gentoo.org/show_bug.cgi?id=198901 forbade using it that way. And therefore systemd config files would be installed regardless of flags. Therefore udev/eudev don't have systemd flags. But both have openrc flags, and will not run OK on an openrc machine without the openrc flag. We do that because there is a separate package (udev-init-scripts) in the tree which has the OpenRC init scripts for udev and eudev. Both of them have RDEPENDS on this package if the openrc use flag is set. Also, there are some udev rules in the udev-init-scripts package which should not be installed if openrc is not in use. So, the use flag does more than just not install init scripts. William signature.asc Description: Digital signature
