Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[Dustin C. Hatch]

On 2017-01-30 14:04, William Hubbs wrote:
> I have opened an issue on OpenRC's github wrt migrating OpenRC to the
> meson build system [3].
> 
> …
> 
> What do folks think here?
> 

I looked at Meson a bit, and I liked almost everything, except the
configuration file-based mechanism for cross-compiling. Has anyone
thought about how that will integrate with Portage, or more
specifically, with cross-emerge/emerge-wrapper, and the environment
variable-based mechanism used by other build systems?

-- 
♫Dustin

Re: [gentoo-dev] tmpfiles virtual

[Dustin C. Hatch]

On 2016-11-14 23:09, Michał Górny wrote:
> On Mon, 14 Nov 2016 18:23:10 -0600
> William Hubbs  wrote:
> 
>> Hi all,
>>
>> I have been working on splitting the tmpfiles functionality out of
>> OpenRC [1], and I believe the new package is about to enter the tree.
>>
>> OpenRC itself doesn't need this package to boot since it doesn't use
>> tmpfiles.d files, but other software does need it.
>>
>> This brings up a couple of questions.
>>
>> Since we now will have two different ways to process tmpfiles, is
>> virtual/tmpfiles appropriate, with the default being opentmpfiles?
> 
> Yes. Virtual will allow us to control list of supported implementations
> easily. We can also use it to control different versions of tmpfiles
> format.
> 
>> Once opentmpfiles is in the tree and stable, should virtual/tmpfiles
>> be added to @system, or should we have the packages that need it rdepend
>> on it directly? I tend to lean toward the second option.
> 
> We will RDEPEND on it via tmpfiles.eclass. I think floppym has a draft
> somewhere. In case that draft uses DEPEND, it just occurred to me that
> we need RDEPEND for pkg_postinst().
> 

What about administrator-specified temporary files in /etc/tmpfiles.d?
It would be rather unfortunate to have stuff suddenly stop working
because an OpenRC got updated and stopped creating these temporary files.

-- 
♫Dustin

Re: [gentoo-dev] rfc: /etc/init.d/functions.sh deprecation

[Dustin C. Hatch]

On 03/06/2014 11:04 AM, William Hubbs wrote:
 ...
 The second question is about the rc_nocolor variable. This is an
 undocumented variable which can be set in /etc/rc.conf to force OpenRc
 to not use color in its output. Is this something that should be carried
 over to gentoo-base-functions? Also, is it worth a config file in /etc
 for one variable?
 
Too bad this isn't a documented variable! I've been searching for it for
ages, trying to clean up the console log on my EC2 instances. I hope it
doesn't go away now!

-- 
♫Dustin
http://dustin.hatch.name/

Re: [gentoo-dev] Package removal without proper last-riting

[Dustin C. Hatch]

On 11/11/2013 06:51, Tom Wijsman wrote:

On Mon, 11 Nov 2013 10:47:30 +0100
Michał Górny mgo...@gentoo.org wrote:


Silent removals do us no good.

...


  1) dev-only seems to be the main cause of lost announcements, which
 isn't that worry some as most of us still receive them but it would
 be nice for them to be in dev-announce as well;


This is actually the reason I subscribed to -dev in the first place. I 
started noticing that some packages I needed/used/used to use/etc. were 
being removed and I wanted to find out why. At first, I subscribed to 
-announce and -dev-announce, but I found that I still wasn't being notified.


I know overlays aren't officially supported, but the courtesy of 
announcing package removals, especially libraries, would be much 
appreciated. There have been times that a library I use for an internal 
project, for example, was removed without notice, forcing me to look at 
the CVS attic to find out why. More often than not, though, the commit 
message is simply removed or clean up, which is just as unhelpful. 
While I have no problem copying stuff back out of the attic into a local 
overlay, it would be nice to prepare for that before something breaks.


Thank you,

--
♫Dustin
http://dustin.hatch.name/

Re: [gentoo-dev] Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations?

[Dustin C. Hatch]

On 8/8/2013 20:05, Zac Medico wrote:

On 08/08/2013 12:11 PM, Tom Wijsman wrote:

On Thu, 8 Aug 2013 21:57:37 +0300
Alon Bar-Lev alo...@gentoo.org wrote:


Multiple implementations shouldn't block Gentoo going forward.

We need to come up with a solution similar to the above to avoid
this...


This is called a 'profile'.

You can have systemd and openrc profiles, and then able to mask
specific packages...


That's an interesting solution. Though, I wonder if it constitutes as
use or as misuse of profiles as we haven't thought this out; also, I
wonder how different people's stance is over having profiles like this.


This seems like a possible applicatio for mix-in profiles like Funtoo
uses:

   http://www.funtoo.org/wiki/Flavors_and_Mix-ins


+1 for mix-ins, been hoping to see that hit mainline for a while now.

--
♫Dustin
http://dustin.hatch.name/

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

[Dustin C. Hatch]

On 7/29/2013 19:33, Matt Turner wrote:

On Mon, Jul 29, 2013 at 5:28 PM, yac y...@gentoo.org wrote:

I have fully encrypted systems, including /, which requires an
initramfs with cryptsetup built staticaly.


Doesn't it actually require them built statically, or simply that the
necessary libraries are also in the initramfs?

I think this has already been covered.

I think the point is that users may have an initramfs (that they built 
manually or using some tool besides dracut or genkernel) that makes use 
of cryptsetup/lvm2 built statically, or perhaps they just like it that 
way, so why take away that ability and make them change?


--
♫Dustin
http://dustin.hatch.name/

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

[Dustin C. Hatch]

On 7/29/2013 20:07, Rich Freeman wrote:

On Mon, Jul 29, 2013 at 9:01 PM, Dustin C. Hatch admiraln...@gmail.com wrote:

I think the point is that users may have an initramfs (that they built
manually or using some tool besides dracut or genkernel) that makes use of
cryptsetup/lvm2 built statically, or perhaps they just like it that way, so
why take away that ability and make them change?


Presumably because it is harder to maintain?  If somebody wants to
maintain (proxy or otherwise) the needed changes to support the static
USE flag my opinion is that they should be able to do so.  They would
need to be responsive on bugs/etc and not be a burden on the other
maintainers.

However, if nobody wants to step up and do the work, then those who
are doing the work basically get the last word in how it gets done.
That's just how things roll around here.

Besides, you could make the same argument about every binary in
/(s)bin.  Initramfs builders manage to deal with a dynamically-linked
bash, so they should be able to handle lvm+cryptsetup.

Rich

As I understood the OP's request, he was looking for current use cases 
of the option. yac offered one. As usual, he was met with your argument 
is invalid. I was merely trying to help his point.


--
♫Dustin
http://dustin.hatch.name/

Re: [gentoo-dev] USE_EXPAND is not an IUSE replacement [was: New USE_EXPAND: CLAWS_MAIL_PLUGINS]

[Dustin C. Hatch]

On 5/3/2013 16:08, René Neumann wrote:

Am 03.05.2013 22:20, schrieb Zac Medico:

Is it worth changing?


Nope. What's worth changing is the excessive use of USE_EXPAND for no
reason (your described usecase makes sense for reasonable USE_EXPAND
stuff like VIDEO_CARDS). But seems like I'm the only one concerned by
this, so I should probably rest my case and switch to silent sobbing
instead ;-).

- René

I definitely agree with you. USE_EXPAND combined with nearly everything 
on-by-default (ENLIGHTENMENT_PLUGINS, for example) really annoys me. 
There are two ways to turn off USE_EXPADed flags: explicitly set 
everything but what you don't want in make.conf, or use the 
fully-qualified flag in make.conf:USE or package.use, which defeats the 
purpose entirely. Both of these are overly verbose, in my opinion. I 
don't know how the over-utilization of USE_EXPAND got started, but I 
would very much like to see it go away.


--
♫Dustin
http://dustin.hatch.name/

Re: [gentoo-dev] splashutils needs a maintainer

[Dustin C. Hatch]

On 2/2/2013 13:19, Pacho Ramos wrote:

El mar, 29-01-2013 a las 15:55 +0400, Sergey Popov escribió:

28.01.2013 23:26, Pacho Ramos пишет:

Then, looks like no alternative is in good shape on Gentoo. What is
Sabayon using? They look to have plymouth ebuilds in their overlay (but
not in for-gentoo one, then, it probably has some incompatibility
Gentoo :/)


We have plymouth ebuilds in tree, but they are outdated(see
https://bugs.gentoo.org/show_bug.cgi?id=430478).



Could anyone summarize the advantages of splashutils over plymouth? As
both look to be needed of some love in Gentoo, maybe would be better to
focus on later one (that is the preferred option in most distributions
and is actively developed)

As a user, I can say that one advantage of splashutils over plymouth is 
that I could never get the latter to work, whereas the former has worked 
on every machine I've tried to use it on (server, desktop, and virtual 
machine).


--
♫Dustin

Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Dustin C. Hatch]

On 1/22/2013 05:56, Rich Freeman wrote:

On Tue, Jan 22, 2013 at 6:11 AM, viv...@gmail.com viv...@gmail.com wrote:

IMHO the number of cases where CONFIG_CHECK is reliable is so small that
making it fatal will only bloat make.conf and env with a new var for most
users.


Tend to agree.  I just got an elog out of udisks complaining about
USB_SUSPEND not being set, and I have no idea why I'd need that on a
system that is powered 24x7.  Even the kernel docs suggest that it
should be disabled if users aren't sure if they need it.

Maybe we need some way to distinguish between must-have and
nice-to-have situations?  Clearly failure to boot is in a different
category than not-able-to-suspend.

Rich

I agree. During an update recently, I noticed that qemu complains if 
KVM_INTEL isn't set on an AMD CPU. Making this fatal would be stupid, 
but then nobody who runs qemu-kvm would ever get a fatal error about 
missing DEVTMPFS.


--
♫Dustin

Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default

[Dustin C. Hatch]

On 1/24/2013 12:18, Ian Stakenvicius wrote:

On 24/01/13 01:09 PM, Rich Freeman wrote:

On Thu, Jan 24, 2013 at 12:49 PM, Duncan 1i5t5.dun...@cox.net
wrote:

That said, presumably udisks would choose not to make its check
fatal, altho changing the default to fatal could complicate
things for existing ebuilds until they're fixed.


That was basically my whole point - it can't be one-size-fits-all.
Honestly, based on some of the other feedback I'm not convinced it
should ever be fatal.  Perhaps it should be more or less noisy.

Keep in mind that a typical user may be running parallel builds
and such - so a delay doesn't really make much sense there either.
There should also be some way to kill any interactivity in advance
- if I'm running a bootstrap script of some kind and I'm
installing/updating udev before I even compile a kernel that
shouldn't cause the whole process to die.



a fatal die in pkg_pretend could be circumvented by an environment
variable such as ${PN}_I_KNOW_WHAT_IM_DOING being set.  Just a thought.

People keep quoting, on this list and on gentoo-user, that Gentoo is not 
a hand holding distribution. Having to set I_KNOW_WHAT_IM_DOING=1 sure 
seems to me like I'm telling my dad I don't need him to hold my hand to 
cross the street anymore, I'm a big boy. It seems like an added step 
that isn't necessary. If users are not reading the messages they're 
receiving and it breaks their systems, why should that make extra work 
for those of us who do pay attention?


--
♫Dustin

[gentoo-dev] Re: How a proper server profile should look like

[Dustin C. Hatch]

On 1/21/2013 02:01, Ralph Sennhauser wrote:

On Mon, 21 Jan 2013 13:27:18 +0800
Ben de Groot yng...@gentoo.org wrote:


On 21 January 2013 12:16, Peter Stuge pe...@stuge.se wrote:

Panagiotis Christopoulos wrote:

I don't build server machines every day, others do and it would be
much appreciated if they could respond here.


I build catalyst stage4s. Any default profiles are kindof pointless
for me; I have USE=-* and the flags that I want.

Anything else seems a bit too random.


This is why I think we do need something like a truly minimal profile
to start building from. Too many people are doing this.



-* will still be required by those same people for EAPI 1 package
defaults. Cleaning a profile won't change that.

The package defaults have gotten out of hand, in my opinion. I use 
default/linux/amd64/10.0 on all my machines and my 
/etc/portage/package.use directories have dozens of -flag entries for 
packages with ridiculous defaults, and almost none that come from the 
profile. I'm considering removing pkginternal from USE_ORDER.


--
♫Dustin

Re: [gentoo-dev] removing the server profiles...

[Dustin C. Hatch]

On 1/16/2013 11:32, Alexis Ballier wrote:

Other option: kill the server subprofiles, keep profiles/target/server
and let people finally set /etc/make.profile as a dir and play with
multiple inheritance. We don't need dozens of subprofiles with only
eapi and parent files in them...

A.

I would love to see this option, especially if eselect would allow us to 
activate multiple profiles. It would really make centralizing 
configuration across multiple machines much easier (i.e. one could 
activate the base profile and a personal profile from a layman overlay).


--
♫Dustin

Re: [gentoo-dev] Re: [RFC] Defaulting desktop profiles to net-nds/openldap[minimal]

[Dustin C. Hatch]

On 12/1/2012 22:21, Diego Elio Pettenò wrote:

If anything, what you just say would call for making openldap follow the
39 packages already out there using IUSE=+server, so that there is no
doubt that changing the default on desktop profile from USE=-minimal to
USE=-server means that _you're losing your server_.

As a user and a sysadmin, I can say that I have had enough bad 
experiences with ebuilds using the minimal USE flag that I typically 
try to avoid it. There are so many different packages that have that 
flag, and in most of them, having it set usually ends up removing 
something I didn't expect. Personally, I would prefer to see the 
introduction of a server flag. That way, when I do updates, I know 
exactly what's going to change.


I also think the news item is a good idea. I know I don't always do a 
perfectly thorough job of it, but I do --pretend and go through the list 
before a world updates. Sometimes, though, I don't quite understand the 
USE changes. Especially with global flags like minimal or gtk, doing 
`equery uses package` isn't much help because the description is so 
generic. A news item would help reduce that confusion somewhat, 
especially if combined with the flag name change.


Just my $ 0.02

--
♫Dustin