Re: [gentoo-dev] media-video/vlc looking for a new maintainer

On 09/19/2012 04:00 PM, Ben de Groot wrote: > Thanks for all you have done maintaining VLC all those years. It is > undoubtedly one of the most popular and versatile video players out > there. I really hope someone steps up to become its new dedicated > maintainer. Given I'm in contact with upstre

Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass

On 09/29/2012 12:45 PM, Michał Górny wrote: > On Sat, 29 Sep 2012 12:00:18 +0200 > Tomáš Chvátal wrote: > >> 2012/9/29 Michał Górny : >>> Hello, >>> >>> Instead of the floating patches and p-d-ng modifications I sent >>> earlier, here are the two complete (so far, well, initial :P) eclasses >>> f

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

On 11/18/2012 04:34 PM, Vadim A. Misbakh-Soloviov wrote: > To be honest, in my opinion, «killing of separate /usr» can reasonable > be continued by moving all it's content to / (/usr/bin -> /bin, /usr/lib > -> lib, and so on) in despite of all objections, as it was invented just > because of disk s

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

On 11/18/2012 04:47 PM, Diego Elio Pettenò wrote: > But yes, many more can't understand that... and neither do I. Then would be nice if everybody shuts up, let people play with their toys and if something useful happens evaluate the result. According to the people that asked me to help the whole

Re: [gentoo-dev] net-irc/xchat

On 11/26/2012 01:16 PM, Rich Freeman wrote: > On Mon, Nov 26, 2012 at 5:33 AM, Mike Frysinger wrote: >> along those lines, a news entry is probably not even necessary. > > So, users will just suddenly have their binary change names, and will > need to manually move config files and update logrota

[gentoo-dev] Re: gcc-6.x status inquiry

On 5/3/17 6:43 PM, William Hubbs wrote: > Hey all, > > I am asking about this because I have been asked to look into > packaging software that has a specific requirement for >=gcc-6 in order > to build [1]. > > I see that gcc-6.3 doesn't have keywords, so I'm > wondering when it will get them? Do

[gentoo-dev] Re: [PATCH] toolchain.eclass: add DEPEND to dev-libs/boehm-gc, bug #617788

On 5/9/17 7:15 PM, Matthias Maier wrote: > sys-devel/gcc-7.1.0 requires external dev-libs/boehm-gc, the internal > copy got removed [1]. > > [1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=242985 > --- > eclass/toolchain.eclass | 6 ++ > 1 file changed, 6 insertions(+) > > diff --

[gentoo-dev] Re: glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ...

On 18/09/2017 11:56, Andreas K. Huettel wrote: So glibc-2.26 is already out for some time, but we still haven't keyworded it yet. Why? * I want to use the opportunity to make the long-delayed switchover from glibc-internal SunRPC (long deprecated and outdated) to external implementations (libtir

[gentoo-dev] Re: Current status with openssl-1.1

On 09/06/2018 10:22, Lars Wendler wrote: > Hello dear Gentoo Devs, > > this is somewhat written out of frustration so please bear with me ;) > > CCing crypto@ in case they can provide some valuable input to the > topic. If not, sorry guys for wasting your time. > > As you might have noticed, alt

[gentoo-dev] Re: Suggestions for simplifying VIDEO_CARDS situation

On 17/06/2018 06:40, Matt Turner wrote: > I would like to somehow get rid of the 'classic' and 'gallium' USE > flags entirely, but I'm not totally sure how. Maybe I can enable them > dependent on VIDEO_CARDS... But shouldn't mesa have a software fallback for a good deal of those features? Probabl

Re: [gentoo-dev] New virtual: virtual/jack for jack protocol implementations

On 04/02/16 15:05, Alexis Ballier wrote: > Hi, > > We've been supporting jack sound server [1] for a long time. > Currently, we're supporting jack1 as > media-sound/jack-audio-connection-kit. However, jack2 has been out for > quite some time. > > As its name does not imply, jack2 is not really th

Re: [gentoo-dev] Changing order of default virtual/udev provider

On 09/02/16 04:09, Rich Freeman wrote: > On Mon, Feb 8, 2016 at 7:58 PM, Anthony G. Basile wrote: >> >> what does in-house tool mean? i'm a gentoo developer but i also work >> on an upstream project (eudev) that 14 distros use. >> >> some of the criticism given here are my concerns as well and i'

Re: [gentoo-dev] rfc: Does OpenRC really need mount-ro

On 16/02/16 19:05, William Hubbs wrote: > All, > > I have a bug that points out a significant issue with > /etc/init.d/mount-ro in OpenRC. > > Apparently, there are issues that cause it to not work properly for file > systems which happen to be pre-mounted from an initramfs [1]. Who is using tha

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

On 24/02/16 01:33, Duncan wrote: > That option is there, and indeed, a patch providing it was specifically > added to portage for infra to use, because appending entries to existing > files is vastly easier and more performant than trying to prepend entries > and having to rewrite the entire fil

Re: [gentoo-dev] usr merge

On 05/04/16 03:19, William Hubbs wrote: > Thoughts on any of this? The whole usr-merge moves the problem of putting stuff in / to putting the very same stuff in the initrd when something different from busybox (or equivalent) is needed to get the early boot mounting. Do we have a reliable way to

Re: [gentoo-dev] usr merge

On 09/04/16 13:53, Rich Freeman wrote: > On Sat, Apr 9, 2016 at 7:41 AM, Luca Barbato wrote: >> On 05/04/16 03:19, William Hubbs wrote: >>> Thoughts on any of this? >> >> The whole usr-merge moves the problem of putting stuff in / to putting >> the very sam

Re: [gentoo-dev] usr merge

On 08/04/16 14:55, Rich Freeman wrote: > The purpose of a /usr merge is to get all the stateless stuff into one place. beside what you have in /etc ... usr-merge, in practice just moves early-boot/core tools where the rest of the userspace lives. > Some of the ultimate goals include: > 1. A rea

Re: [gentoo-dev] usr merge

On 09/04/16 14:37, Rich Freeman wrote: > I've certainly haven't had many problems with dracut. When it fails > it is usually because I'm doing something ELSE that is off-the-wall > and it just doesn't have a plugin for it yet. (And in those cases it > isn't like the kernel tends to get it right w

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

On 18/04/16 00:50, Anthony G. Basile wrote: > Does base-system object if I bump it to EAPI=5 before I commit the > ssl-cert patch? I'll start stabilization too obviously. > Please do.

Re: [gentoo-dev] New project: LLVM

On 19/08/16 05:11, C Bergström wrote: > I think you're getting a bit confused > > libsupc++ is the default now, from GNU > > libcxxabi is the bloated runtime from Apple > > libcxxrt is the faster c++ runtime, PathScale+David Chisnall, which > PathScale and FreeBSD use by default. We don't need a

Re: [gentoo-dev] New project: LLVM

On 19/08/16 19:13, C Bergström wrote: > I finally got it to build and here's the size numbers > 952K./lib/libc++abi.a > 616K./lib/libc++abi.so.1.0 > > If the above isn't enough motivation and you really want benchmarks > which prove it's a pig... I'll try to figure something else > > Not

Re: [gentoo-dev] New project: LLVM

On 19/08/16 17:15, C Bergström wrote: > On Fri, Aug 19, 2016 at 11:01 PM, Luca Barbato wrote: >> BTW is pathscale ready to be used as system compiler as well? > > I wish, but no. We have known issues when building grub2, glibc and > the Linux kernel at the very least. Someone*

Re: [gentoo-dev] nftables

On 09/09/16 02:31, Ian Bloss wrote: > Anyone actively using nftables for their firewall over iptables? > Considering giving it a go as the syntax looks much nicer than iptables. > I'm using a bit and just works fine =) lu

[gentoo-dev] Re: LLVM-3.9 news item for review

On 01/10/16 10:10, Michał Górny wrote: > explicitly selecting all targets. The item seems fine.

[gentoo-dev] Re: [PATCH v2] profiles: promote USE=vulkan to global USE flag

On 22/05/23 22:41, Nick Sarnie wrote: On 5/22/23 16:40, Matt Turner wrote: On Mon, May 22, 2023 at 4:27 PM Sam James wrote: Thanks to leio for this improved phrasing. Signed-off-by: Sam James ---   profiles/use.desc | 1 +   1 file changed, 1 insertion(+) diff --git a/profiles/use.desc b/pro

Re: [gentoo-dev] Re: [gentoo-project] eudev project announcement

On 12/15/2012 01:48 PM, Rich Freeman wrote: > On Fri, Dec 14, 2012 at 10:52 PM, Richard Yao wrote: >> The systemd developers were in the middle of a transition to the LGPL >> from the GPL when we forked. We inherited the code in the middle of that >> transition and we see no reason to purs

Re: [gentoo-dev] Re: [gentoo-project] eudev project announcement

On 12/15/2012 05:20 PM, Rich Freeman wrote: > On Sat, Dec 15, 2012 at 10:43 AM, Luca Barbato wrote: >> >> >> eudev is a Gentoo project is not Gentoo. Same could be said for OpenRC. >> > > OpenRC isn't a Gentoo project, at least, it wasn't in the past. &

Re: [gentoo-dev] new global USE flag: orc

On 12/16/12 5:28 AM, Alexandre Rostovtsev wrote: Currently, the "orc" local USE flag is used by 11 packages, 9 of them with identical descriptions. I think it's time to make it a global flag. I would suggest the following description: "Use dev-lang/orc for just-in-time optimization of array oper

Re: [gentoo-dev] Moving our/portage stuff to var

On 12/17/12 11:30 AM, Michał Górny wrote: On Mon, 17 Dec 2012 11:23:00 +0100 Diego Elio Pettenò wrote: On 17/12/2012 11:19, Tomáš Chvátal wrote: I've always myself override these defaults in make.conf to point for /var/portage/ (not /var/lib because I never bothered enough how to make world

Re: [gentoo-dev] Re: eudev project announcement

On 12/17/12 11:40 AM, Olav Vitters wrote: So systemd still works with a separate /usr and you're continuing to spread misinformation. Demonstrating such behaviour while complaining about the behaviour of upstream is IMO very ironic. No it does not, try by yourself please ^^ (or just issue and

Re: [gentoo-dev] Defaulting for debug information in profiles

On 12/17/2012 02:55 PM, Rich Freeman wrote: > On Mon, Dec 17, 2012 at 8:43 AM, Kacper Kowalik wrote: >> All trouble can be saved by asking user to recompile package with >> relevant flags on bug report, resolving the bug as NEEDINFO. Instead of >> forcing everybody out there using Gentoo to have a

Re: [gentoo-dev] Re: eudev project announcement

On 12/17/12 2:25 PM, Olav Vitters wrote: On Mon, Dec 17, 2012 at 12:09:08PM +0100, Luca Barbato wrote: On 12/17/12 11:40 AM, Olav Vitters wrote: So systemd still works with a separate /usr and you're continuing to spread misinformation. Demonstrating such behaviour while complaining abou

Re: [gentoo-dev] Is /var/cache the right place for repositories?

On 12/20/2012 07:14 PM, Ciaran McCreesh wrote: > The tree is a database. It belongs in /var/db/. > That's a good point. lu

Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig

On 02/01/13 13:11, Samuli Suominen wrote: > On 01/01/13 23:01, Jeff Horelick wrote: >> I would like to propose a switch of the order of DEPENDs in >> virtual/pkgconfig to make dev-util/pkgconf[pkg-config] the default >> choice for new installations. >> >> dev-util/pkgconf has less external dependen

Re: [gentoo-dev] Chromium system ffmpeg

On 15/01/13 05:34, "Paweł Hajdan, Jr." wrote: > I'm trying to make Chromium be more compatible with more versions of > ffmpeg: > > (although not stated there, that includes libav). > > Now the initial response t

Re: [gentoo-dev] Chromium system ffmpeg

On 16/01/13 12:54, Alexis Ballier wrote: > On Tue, 15 Jan 2013 21:10:12 -0800 > ""Paweł Hajdan, Jr."" wrote: > >> On 1/15/13 4:55 AM, Alexis Ballier wrote: >>> On Mon, 14 Jan 2013 20:34:42 -0800 >>> ""Paweł Hajdan, Jr."" wrote: I'm trying to make Chromium be more compatible with more versio

Re: [gentoo-dev] app-emulation/qemu-user mask

On 12/01/13 05:45, Doug Goldstein wrote: > Just wanted to give everyone a heads up. app-emulation/qemu provides > all the functionality of app-emulation/qemu-user without all the > outstanding security bugs and issues the package has. For users using > a cross chroot, I encourage you to look at QEM

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

On 16/01/13 21:09, Alexis Ballier wrote: > More seriously: Why ? Who decided this ? I never pushed my weight over it before since as you are involved in FFmpeg directly, I am involved in Libav directly. Thus anything I say on this topic has a clear bias. Same goes for you. Tomas is not related t

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

On 16/01/13 22:31, Alexis Ballier wrote: > interesting, did they report it? OTOH, they switched _after_ the 2.0.5 > release which happens to be the latest one. Since vlc is probably the > ffmpeg/libav interface the most popular in the world (due to their > windows and mac builds), I'd like to see a

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

On 17/01/13 15:07, Alexis Ballier wrote: > On Thu, 17 Jan 2013 10:41:58 +0100 > Tomáš Chvátal wrote: > [...] >> So yes it works and should not pose any issues to user. I also >> announced it over blog to get people report more issues they find out >> so I can be really sure it works out. It turned

[gentoo-dev] Re: About dropping ppc-kernel herd

On 20/01/13 10:26, Pacho Ramos wrote: > Looks like no package is included in it, I think we should drop that > herd then > > Do you agree? > Agreed.

Re: [gentoo-dev] Chromium system ffmpeg

On 19/01/13 20:10, "Paweł Hajdan, Jr." wrote: > have a way to more simply exclude code that requires CODEC_ID_OPUS. Exclude in chrome or in libavcodec? The latter is a matter of adding --disable-decoder=opus and/or not --enable-libopus in the configure. lu

Re: [gentoo-dev] app-emulation/qemu-user mask

On 16/01/13 20:20, Luca Barbato wrote: > Again please do not mix qemu system emulation with qemu userspace > wrappers. They have different needs and requirements. qemu-user-1.2.2 in portage. I'll drop the mask as said before. We can discuss on irc or here on what's the bes

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

On 08/02/13 22:46, Alexis Ballier wrote: > On Fri, 08 Feb 2013 22:41:04 +0100 > Maciej Mrozowski wrote: > >> On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote: >> >>> Tomáš Chvátal wrote: we as gentoo will provide both while preffered default will be what major distros use. >>>

Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

On 11/02/13 03:01, Alexis Ballier wrote: > Sorry, I was away this week end... Not a problem, I should be reachable anytime today. > This is only because libav people do not care at all about what FFmpeg > defines, while FFmpeg seems to care more about its consumers and users > by trying to provid

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

Your whole email is derailing a bit from discussing the code at hand and it is going deep down on the people, I'd rather not get there since it gets totally unrelated the question at hand. On 11/02/13 14:49, Alexis Ballier wrote: > All of this because ~10 people cannot work together, well, really,

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

On 11/02/13 22:33, Peter Stuge wrote: > Luca Barbato wrote: >> May I point you that ~10 people were the majority of what was FFmpeg, >> thus 10 people were enough to demote democratically the so called Leader >> and that guy got the name from Fabrice as his personal dec

Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)

On 12/02/13 08:21, Ian Whyman wrote: > Guys, > > Can we not just have a developer wide vote or something? This > instance clearly not going to resole itself. It is a little bikeshed. Originally the virtual was ordered in a way, then ordered in another and now we are discussing which one is bette

Re: [gentoo-dev] GCC 4.7 unmasking

On 25/02/13 22:32, Rich Freeman wrote: > On Mon, Feb 25, 2013 at 4:18 PM, Tom Wijsman wrote: >> Though people that use -ffast-math / -fLTO / -fuse-linker-plugin should >> be on their own, thus I drop -ffast-math because it breaks my browser; >> but that doesn't mean that those ricer flags should s

Re: [gentoo-dev] GCC 4.7 unmasking

On 25/02/13 23:21, Rich Freeman wrote: > My point was just that: > 1. No, the fact that entire packages fail to build/operate using > -ffast-math is not a valid bug. >From your email the message was the opposite, maybe a not got lost? > 2. If individual packages DO carefully use -ffast-math and

Re: [gentoo-dev] rfc: oldnet scripts splitting out from OpenRC

On 04/24/2013 06:16 PM, William Hubbs wrote: > All, > > it has been suggested that gentoo's oldnet scripts be split out into > their own package separate from OpenRC so that they can be developed > independently. I am looking at doing this for OpenRC 0.12, which I hope > to release soon. > > This

Re: [gentoo-dev] Making systemd more accessible to "normal" users

On 05/01/2013 12:04 PM, Fabio Erculiani wrote: > PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. > THIS IS NOT A POST AGAINST OPENRC. Amen > With the release of Sabayon 13.04 [1] and thanks to the efforts I put > into the systemd-love overlay [2], systemd has become much more > accessible and

Re: [gentoo-dev] Making systemd more accessible to "normal" users

On 05/04/2013 03:12 PM, Fabio Erculiani wrote: > I just forgot the tricky part. > If future lvm versions are going to use udev more extensively (for eg: > storing more critical metadata in it), the net result will be that > mdev won't work anymore. This is why I wrote that lvm is working "by > mira

Re: [gentoo-dev] Making systemd more accessible to "normal" users

On 05/04/2013 03:05 PM, Fabio Erculiani wrote: > Long story short, we should: > 1) give up with cross compiler support in genkernel, which has been > anyway in a broken state for ages. Nobody is using it anyway. > 2) make possible to optionally use udev in the initramfs (compiling > just for it is

Re: [gentoo-dev] Making systemd more accessible to "normal" users

On 05/10/2013 09:45 AM, Ralph Sennhauser wrote: > [1] http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files What if openrc/upstart/runit devs start harassing upstream in the same way? Strategically is great, but isn't exactly something nice to do. Probably people caring about alternatives s

Re: [gentoo-dev] Making systemd more accessible to "normal" users

On 05/15/2013 03:41 PM, Fabio Erculiani wrote: > Are we realizing that in order to keep systemd out of our way, we're > currently writing and maintaining drop-in replacements for the > features that systemd is already providing in an actively maintained > state? openrc-settingsd was the first thing

Re: [gentoo-dev] Making systemd more accessible to "normal" users

On 05/15/2013 05:03 PM, Luca Barbato wrote: > On 05/15/2013 03:41 PM, Fabio Erculiani wrote: >> Are we realizing that in order to keep systemd out of our way, we're >> currently writing and maintaining drop-in replacements for the >> features that systemd is alread

Re: [gentoo-dev] Making systemd more accessible to "normal" users

On 05/15/2013 07:26 PM, Tom Wijsman wrote: > On Wed, 15 May 2013 17:03:13 +0200 > Luca Barbato wrote: > >> On 05/15/2013 03:41 PM, Fabio Erculiani wrote: >>> ... GNOME ... >> >> And given that the end-plan according to the guys is to kill the >> di

Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users

On 05/21/2013 09:03 AM, Alan McKinnon wrote: > On 21/05/2013 05:03, Daniel Campbell wrote: >> That's missing the point. If you don't run systemd, having unit files is >> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems >> like a hack instead of something more robust. Why inclu

[gentoo-dev] eselect init

Hi, since the whole discussion got somehow sidetracked on where and if to install for everybody the rc system specific files for everybody (that should be an implementation detail for the specific dohelper IMHO), I'm back to the other part of it: switching the actual init implementation. # WHY (no

Re: [gentoo-dev] eselect init

On 05/25/2013 01:29 PM, Sergei Trofimovich wrote: > If you can't change options at boot time it's very simple to get > unbootable system. Just curious, who does such systems and > how root filesystem (+ it's mount options) is expected to be > found there? You write your bootargs in the kernel, if

Re: [gentoo-dev] eselect init

On 05/25/2013 01:13 PM, Pacho Ramos wrote: > El sáb, 25-05-2013 a las 11:54 +0200, Luca Barbato escribió: >> Hi, since the whole discussion got somehow sidetracked on where and if >> to install for everybody the rc system specific files for everybody >> (that should be an impl

Re: [gentoo-dev] eselect init

On 05/25/2013 02:13 PM, hasufell wrote: > Isn't eselect for cases where I might want to reconfigure something or > add configuration values such as for bash-completion, do testing with > java-vm or python implementations during development, switch opengl > implementation depending on the graphics d

Re: [gentoo-dev] Usage of dev-utils/ninja in ebuilds

On 5/25/13 9:17 PM, Tom Wijsman wrote: On Sat, 25 May 2013 14:48:30 -0400 Mike Gilbert wrote: For those unaware, dev-util/ninja is a make-replacement created by one of the Chromium guys at Google. Its focus is on making incremental builds of large software faster. I've no idea how this would

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

On 5/25/13 6:48 PM, Michał Górny wrote: On Sun, 26 May 2013 00:14:36 +0800 Ben de Groot wrote: I'm taking this from https://bugs.gentoo.org/412697 to the dev mailing list, since this discussion doesn't really belong on bugzilla. Seems that *upstream* had to a bit of work in order to support

Re: [gentoo-dev] eselect init

On 5/26/13 8:43 AM, Michał Górny wrote: On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato wrote: - /sbin/init (or whatever linux currently calls by default with top priority) should be either a symlink to the actual implementation or a wrapper such as our gcc one. I like better the latter since

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

On 5/26/13 9:45 AM, Michał Górny wrote: As in, say, lastrite GNOME and tell users to switch to other distro? Or maybe everything using udev? Sounds much like the way to get the 'one distro' dream some people have. But wasn't the intent opposite? eudev was made on purpose to let people avoid sys

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd

On 5/26/13 9:37 AM, Michał Górny wrote: By the way, we should really keep the separation between systemd itself and the unit files. I agree that systemd is not the best thing we could have. But the unit file format is, er, good enough -- and has the advantage of eventually taking a lot of work fr

Re: [gentoo-dev] eselect init

On 5/26/13 12:57 PM, Michał Górny wrote: On Sun, 26 May 2013 11:55:24 +0200 Luca Barbato wrote: On 5/26/13 8:43 AM, Michał Górny wrote: On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato wrote: - /sbin/init (or whatever linux currently calls by default with top priority) should be either a

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd

On 5/26/13 1:31 PM, Robert David wrote: Come on, it is 2013, wasting few inodes. I did not got these problems in the old good times with my 386 with 4mb ram and few MB hdd. Those with embedded system will mask many other files, not only systemd units (so they save one inode more with my approach,

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd

On 5/26/13 1:15 PM, Michał Górny wrote: I'd suspect this is mostly with the growing irritation of systemd haters who spawn endless threads about how they hate anything with 'systemd' name in it. Plus the people who try hard to port the mistakes of OpenRC init scripts to systemd services files.

Re: [gentoo-dev] eselect init

On 5/26/13 2:08 PM, Michał Górny wrote: You could've asked me that when I was still using OpenRC. I don't really want to grep the 40 scripts right now, and I don't think I have the worse cases installed here. Worth investigation, not by you, but those that loathe systemd should have a look and

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd

On 5/26/13 3:35 PM, Sergei Trofimovich wrote: On Sun, 26 May 2013 13:59:34 +0200 Luca Barbato wrote: You need to name a unit with @ suffix, like openvpn@.service: $ cat /etc/systemd/system/openvpn@.service [Service] Type=simple ExecStart=/usr/sbin/openvpn --user openvpn

Re: [gentoo-dev] eselect init

On 5/26/13 1:58 PM, Tom Wijsman wrote: On Sun, 26 May 2013 12:57:42 +0200 Michał Górny wrote: Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. It doesn't need to be in the wrapper, inittab is something read at boot only as

Re: [gentoo-dev] eselect init

On 5/27/13 12:58 AM, William Hubbs wrote: From what I just read, the difference is that busybox init ignores the runlevels specified in sysvinit inittab. Nope, it interprets the numbers in a different way. If that's the only difference, do we really need to modify the inittab at all? Yes, I

Re: [gentoo-dev] eselect init

On 5/26/13 4:13 PM, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/05/13 03:08 PM, Matthew Thode wrote: On 05/25/13 05:25, Peter Stuge wrote: Luca Barbato wrote: - init gets effectively switched only at boot/reboot Please not on reboot, because an unclean

Re: [gentoo-dev] eselect init

On 5/26/13 4:58 PM, Ian Stakenvicius wrote: The way it's being proposed (and please correct me if i'm wrong), the wrapper is a direct replacement binary (small C program) for all init systems, and would based on some configuration file or whatnot determine and exec the init system it's supposed t

Re: [gentoo-dev] eselect init

On 5/28/13 6:19 AM, Michał Górny wrote: And you actually make the boot depend on: 1) valid /bin/sh If it doesn't exist you have a few order of magnitude bigger problem. 2) valid /etc/switch-init which would not interfere with boot process. I guess if you want to switch init system you need

Re: [gentoo-dev] Separate boot/root already [WAS: eselect init]

On 05/28/2013 01:45 AM, Walter Dnes wrote: > Out of sheer curiosity... is "bb-init" based on busybox? If so, a it IS busybox =) > separate partition would also prevent standard utilities from stomping > all over their busybox symlink equivalants. Add another entry to the > grub/lilo menu, and

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

On 05/29/2013 10:55 PM, William Hubbs wrote: > On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote: >>> There are a couple of other possible approaches... >>> >>> 1) If the 2 systems can achieve peacefull co-existance (i.e. no >>> identically-named files with different contents) then simply

[gentoo-dev] Re: inittab was: Re: Switchup-mode and boottime selector? Was: eselect init

On 05/30/2013 10:52 PM, William Hubbs wrote: > On Thu, May 30, 2013 at 08:30:00AM +0200, Luca Barbato wrote: >> Because it isn't just editing a file or rebuilding the kernel but also >> have a short trip in single mode to switch back and forth inittab. > > inittab is

Re: [gentoo-dev] Re: eselect init

On 06/01/2013 11:23 AM, Steven J. Long wrote: > That's not an argument for using a symlink switcher or the > equivalent across the board, by any means. Your opinion. > Firstly, we should be recommending people install Gentoo with enough > flexibility to configure and use their system how they ch

Re: [gentoo-dev] Re: Re: eselect init

On 06/02/2013 08:20 PM, Steven J. Long wrote: > On Sun, Jun 02, 2013 at 11:15:37AM +0200, Luca Barbato wrote: >> On 06/01/2013 11:23 AM, Steven J. Long wrote: >>> That's not an argument for using a symlink switcher or the >>> equivalent across the board,

Re: [gentoo-dev] Re: Re: eselect init

On 06/03/2013 02:37 AM, Walter Dnes wrote: > On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote > >> - eselect init will be opt-in ***FOR THE TIME BEING***, people can >> be left on their own tools if the want it > > This statement should bring the same reac

Re: [gentoo-dev] [RFC] SRC_URI behaviour

On 06/15/2013 02:34 PM, Vadim A. Misbakh-Soloviov wrote: > 15.06.2013 18:50, Diego Elio Pettenò пишет: >> Over my dead CVS access. > Any reasonable/argumented objection? to put in different words: We do not want to use untraceable/transient/ephemeral sources for main ebuilds, live ebuilds are cor

Re: [gentoo-dev] [RFC] SRC_URI behaviour

On 06/15/2013 05:33 PM, Rich Freeman wrote: > On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec wrote: >> The other thing is that would put a mandatory system requirement on >> layman which many of the devs would be opposed to. But, there is an open >> bug calling for it to be merged with portage...

Re: [gentoo-dev] [RFC] SRC_URI behaviour

On 06/16/2013 02:24 AM, Zac Medico wrote: > How about it we add a src_fetch phase, so that the VCS intricacies > can be delegated to ebuilds/eclasses (like they are now, but without > having to abuse src_unpack). If we include a way for src_fetch to > communicate changes in VCS revisions to the pac

Re: [gentoo-dev] Temporary DevRel actions for CoC violations

On 06/19/2013 09:15 PM, g...@malth.us wrote: > Sorry to hear you have such a low opinion of the socialization of Gentoo > developers. Since I'm not one of them, I'll just put forth my 2c in on > this, without fear of "consequences." Yet even users not behaving will get a friendly warning and migh

Re: [gentoo-dev] Temporary DevRel actions for CoC violations

On 06/20/2013 05:53 AM, Diego Elio Pettenò wrote: > Does this mean the QA lead finally gets to suspend people who are > patently not suited for developing a stable distribution without > asking devrel? Because last time we got into the same judge, jury, > and executioner argument, which I guess was

Re: [gentoo-dev] eselect init

On 06/21/2013 01:26 PM, Pacho Ramos wrote: > Thanks for the explanation. But I think that, currently, the only > remaining "objection" is whether play with /sbin/init (that needs > sysvinit to be changed if I don't misremember) or with /sbin/einit. > Looks like mgorny has shown some problems on rel

Re: [gentoo-dev] eselect init

On 06/21/2013 05:23 PM, Fabio Erculiani wrote: > Fix the reason why the wrapper got broken then. > If the wrapper broke, it is most likely a symptom of a bigger problem. > > I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit > (or /bin/sysvinit?), anyway... > /bin/init lu

Re: [gentoo-dev] eselect init

On 06/21/2013 06:50 PM, William Hubbs wrote: > On Fri, Jun 21, 2013 at 05:13:33PM +0100, Markos Chandras wrote: >> On 21 June 2013 16:29, Michał Górny wrote: >>> Dnia 2013-06-21, o godz. 10:16:10 >>> William Hubbs napisał(a): >>> On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:

Re: [gentoo-dev] Re: eselect init

On 06/22/2013 12:07 PM, Pacho Ramos wrote: > After talking with WilliamH yesterday, I have this opinion: > - Playing with /sbin/init (instead of /sbin/einit) has two interesting > advantages: > 1. For example, I now have init=/sbin/e4rat-preload in my grub.conf, if > I do a typo, it would fallback

Re: [gentoo-dev] News item preceding net-print/cups-1.6 stabilization

On 06/29/2013 12:03 AM, Andreas K. Huettel wrote: > script to your default runlevel). By default cups-browsed uses the basically the functionality got split in a stand alone daemon?

Re: [gentoo-dev] new category: games-adventure/

On 07/14/2013 07:47 PM, Diego Elio Pettenò wrote: > On 14/07/2013 18:42, Peter Stuge wrote: >> I bet you a tasty beverage that it will grow over time! :) > > I don't believe in the future until I can see it. I'm pretty sure that's > the same thing that they said about app-antivirus at some point (

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

On 01/08/13 04:03, William Hubbs wrote: > On Wed, Jul 31, 2013 at 07:42:26PM +, Robin H. Johnson wrote: >> As both a member of base-system, and the lvm2 maintainer, I'm going to >> go and look at fixing them, because I'd prefer to keep them available as >> static builds. > > Robin, > > I'm cu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

On 01/08/13 17:04, William Hubbs wrote: > There is a hack in our udev and kmod ebuilds that makes it possible to > build the static libraries, but I think we should remove that hack since > upstream bans building them. linking statically makes the problem apparent, I guess isn't that wise hiding i

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

On 01/08/13 17:36, Michał Górny wrote: > So esystemd and ekmod now? You know my stance on systemd, for me it is a jumble of bad and interesting ideas not so soundly implemented, I do not have much time or will to play with that thing. kmod on the other hand had a pressing issue and getting it fix

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

On 01/08/13 19:46, Pacho Ramos wrote: > El jue, 01-08-2013 a las 18:11 +0200, Luca Barbato escribió: >> On 01/08/13 17:36, Michał Górny wrote: >>> So esystemd and ekmod now? >> >> You know my stance on systemd, for me it is a jumble of bad and >> interesting id

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

On 01/08/13 19:54, Samuli Suominen wrote: > still, first the patch goes upstream and after upstream review and > commit to git it goes in tree otherwise we opt to the fallback and > disable udev from lvm2/cryptsetup when USE=static is enabled (like > cryptsetup upstream suggested to me) gentoo-spe

<    1   2   3   4   5   6   7   8   >