Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Mike Gilbert]

On Sun, Aug 28, 2016 at 3:57 PM, Kristian Fiskerstrand  wrote:
> On 08/28/2016 07:28 PM, Paweł Hajdan, Jr. wrote:
>> B. Backport just the changes needed for chromium to older ffmpeg
>
> Any chance of it being included upstream or would it be a downstream
> carry for a long time?

I haven't looked at any code, but given that it's a major version bump
of a library, the changes probably involve API-breaks. Backporting
them upstream or downstream is probably not a simple matter, and
probably a bad idea.

>>
>> C. Mask chromium's system-ffmpeg flag when the dependency on
>> ffmpeg-3.0.1 can't be satisfied
>
> Would this result in using bundled libraries instead?

Yes, masking the system-ffmpeg USE flag would cause the bundled ffmpeg
code to be used.

The Chromium project applies security fixes quite regularly, so don't
get too worried over it.

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-08-28 23:59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2016-08-28 23:59 UTC.

Removals:
kde-apps/kde-wallpapers  20160828-16:16 johu2ffcd3a
kde-plasma/kactivities-workspace 20160825-20:36 johuecf50a8

Additions:
app-vim/tasklist 20160822-08:55 monsieurp   ce00a82
dev-db/cpp-driver20160825-09:53 soap0f002a7
dev-python/arpeggio  20160823-19:52 zmedico a5d6928
dev-python/textx 20160823-20:10 zmedico e5e1f3e
dev-ruby/neovim-ruby-client  20160822-20:33 tranquility fed33bd
sys-boot/systemd-boot20160828-15:09 floppym ab87fe6
sys-libs/compiler-rt 20160821-09:43 mgorny  1d2ecac
sys-power/acpilight  20160822-20:09 grknightfa6edf1
x11-libs/gdk-pixbuf-loader-webp  20160812-20:45 monsieurp   546c666

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
kde-apps/kde-wallpapers,removed,johu,20160828-16:16,2ffcd3a
kde-plasma/kactivities-workspace,removed,johu,20160825-20:36,ecf50a8
Added Packages:
sys-boot/systemd-boot,added,floppym,20160828-15:09,ab87fe6
x11-libs/gdk-pixbuf-loader-webp,added,monsieurp,20160812-20:45,546c666
dev-db/cpp-driver,added,soap,20160825-09:53,0f002a7
dev-python/textx,added,zmedico,20160823-20:10,e5e1f3e
dev-python/arpeggio,added,zmedico,20160823-19:52,a5d6928
dev-ruby/neovim-ruby-client,added,tranquility,20160822-20:33,fed33bd
sys-power/acpilight,added,grknight,20160822-20:09,fa6edf1
sys-libs/compiler-rt,added,mgorny,20160821-09:43,1d2ecac
app-vim/tasklist,added,monsieurp,20160822-08:55,ce00a82

Done.

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Kristian Fiskerstrand]

On 08/28/2016 07:28 PM, Paweł Hajdan, Jr. wrote:
> See  for context.
> 
> chromium-54 is currently hard masked; it'd soon enter ~arch, and then
> stable in ~6 weeks. ffmpeg-3.0.1 is currently hard masked.
> 
> These are the options I see for how to proceed. Feel free to share
> further alternatives.
> 
> A. Prepare to unmask and eventually stabilize ffmpeg-3.0.1

https://bugs.gentoo.org/show_bug.cgi?id=ffmpeg-3

> 
> B. Backport just the changes needed for chromium to older ffmpeg

Any chance of it being included upstream or would it be a downstream
carry for a long time?

> 
> C. Mask chromium's system-ffmpeg flag when the dependency on
> ffmpeg-3.0.1 can't be satisfied

Would this result in using bundled libraries instead?

> 
> D. Patch chromium not to require newer ffmpeg
> 
> Please share your thoughts about pros, cons, and viability of each option.
> 
> I'd certainly be willing to help with testing and making progress on
> these, and I could possibly use a fast machine as a tinderbox for this.
> 
> That also means help is welcome.
> 
> Paweł
> 


-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

[William Hubbs]

Ok all,

here is what openrc-0.22 is going to do in terms of setting the host
name.

If /etc/hostname exists, the first word of that file will be used as the
host name.
Otherwise, if the value is set in /etc/conf.d/hostname it will be used.
Otherwise, OpenRC will not touch the hostname.

One advantage of this, on Linux, is that you can set your host name in
the kernel and this setting will be respected.

Also, this means the script by default can run in containers if they
allow overriding the hostname inside the container.

William



signature.asc
Description: Digital signature

[gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Paweł Hajdan , Jr .]

See  for context.

chromium-54 is currently hard masked; it'd soon enter ~arch, and then
stable in ~6 weeks. ffmpeg-3.0.1 is currently hard masked.

These are the options I see for how to proceed. Feel free to share
further alternatives.

A. Prepare to unmask and eventually stabilize ffmpeg-3.0.1

B. Backport just the changes needed for chromium to older ffmpeg

C. Mask chromium's system-ffmpeg flag when the dependency on
ffmpeg-3.0.1 can't be satisfied

D. Patch chromium not to require newer ffmpeg

Please share your thoughts about pros, cons, and viability of each option.

I'd certainly be willing to help with testing and making progress on
these, and I could possibly use a fast machine as a tinderbox for this.

That also means help is welcome.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

[Rich Freeman]

On Sun, Aug 28, 2016 at 11:29 AM, Patrick Lauer  wrote:
>
> (and what abuse? it did exactly what it was supposed to do quite nicely,
> until it stopped doing that. Now you need to track state and hope you
> don't have race conditions ... )
>

You were tracking state before; in mtab.  It just isn't a terribly
great way to track state, especially when you start getting into
complex situations.  What happens when a service depends on a fuse
filesystem, which depends on a service?  And of course all the
situations where it is wrong, like when it is mounted read-only.

In the past we had kludges like iteration - try to unmount stuff, kill
stuff, and then try harder until it all dies, and then mount read-only
whatever got missed.  In theory today you can actually get messy
situations to cleanly shut down as long as you specify your
dependencies correctly (which you also need to start it all up).

I get that you can run a lot of systems without all the
complexity/rigor, but then you're pitting your ability to write
bug-free simple scripts against Redhat's ability to do QA on complex
scripts.  Sure, we aren't beholden to them, but half the point of FOSS
is to borrow stuff that works.

-- 
Rich

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

[Patrick Lauer]

On 08/28/2016 04:21 PM, Michał Górny wrote:
> On Sun, 28 Aug 2016 14:34:20 +0200
> Patrick Lauer  wrote:
> 
>> On 08/28/2016 08:30 AM, Daniel Campbell wrote:
>>> On 08/24/2016 09:42 AM, Zac Medico wrote:  
 On 08/24/2016 09:33 AM, Michael Orlitzky wrote:  
>   * no benefit put forth so far, other than that it's the same file that
> systemd uses, which is true but not beneficial as far as I can tell  

 It's a de facto standard. Being different for the sake of being
 different is not a virtue in cases like this.
  
>>>
>>> And doing things because "everyone else does it" is dumb, because it
>>> precludes our ability to choose and makes us subject to the decisions
>>> made outside of our distribution. Of course, as a distro we're subject
>>> to outside decisions often, but what's the point of being a distro if
>>> you're doing things the same way everyone else does?  
>>
>>
>> At this point I feel the need to point at /etc/mtab and how it doesn't
>> work anymore. Or rather:
>>
>> In the old days it did *not* carry all mountpoints, so you could hide
>> things like /dev and /run so that "umount -a" would not screw you sideways.
>>
>> Then tools forgot to properly update mtab because hurr why u no symlink
>> to /proc/mounts (oh wait, /proc/self/mounts )
>>
>> So everyone migrated to /etc/mtab as a symlink (even OpenRC, because
>> everyone does it)
>>
>> ... and now if you still instincively use umount -a you unmount /run and
>> other bits, breaking lots of stuff (can't shutdown if OpenRC strongly
>> considers not having booted!)
>>
>>
>> That's why some of us are very resistant to change.
> 
> Which could be pretty much summarized as 'I'm unhappy because I was
> abusing the existing system to make "umount -a" not do what it was
> supposed to do, and I'm unhappy because now it started to work
> correctly'.
> 

"Just because it worked for 30 years doesn't mean it worked" ?

I like how you claim to be the authority on how umount is supposed to
behave ...

(and what abuse? it did exactly what it was supposed to do quite nicely,
until it stopped doing that. Now you need to track state and hope you
don't have race conditions ... )

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

[Michał Górny]

On Sun, 28 Aug 2016 14:34:20 +0200
Patrick Lauer  wrote:

> On 08/28/2016 08:30 AM, Daniel Campbell wrote:
> > On 08/24/2016 09:42 AM, Zac Medico wrote:  
> >> On 08/24/2016 09:33 AM, Michael Orlitzky wrote:  
> >>>   * no benefit put forth so far, other than that it's the same file that
> >>> systemd uses, which is true but not beneficial as far as I can tell  
> >>
> >> It's a de facto standard. Being different for the sake of being
> >> different is not a virtue in cases like this.
> >>  
> > 
> > And doing things because "everyone else does it" is dumb, because it
> > precludes our ability to choose and makes us subject to the decisions
> > made outside of our distribution. Of course, as a distro we're subject
> > to outside decisions often, but what's the point of being a distro if
> > you're doing things the same way everyone else does?  
> 
> 
> At this point I feel the need to point at /etc/mtab and how it doesn't
> work anymore. Or rather:
> 
> In the old days it did *not* carry all mountpoints, so you could hide
> things like /dev and /run so that "umount -a" would not screw you sideways.
> 
> Then tools forgot to properly update mtab because hurr why u no symlink
> to /proc/mounts (oh wait, /proc/self/mounts )
> 
> So everyone migrated to /etc/mtab as a symlink (even OpenRC, because
> everyone does it)
> 
> ... and now if you still instincively use umount -a you unmount /run and
> other bits, breaking lots of stuff (can't shutdown if OpenRC strongly
> considers not having booted!)
> 
> 
> That's why some of us are very resistant to change.

Which could be pretty much summarized as 'I'm unhappy because I was
abusing the existing system to make "umount -a" not do what it was
supposed to do, and I'm unhappy because now it started to work
correctly'.

-- 
Best regards,
Michał Górny



pgp0w1KcBpfbo.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

[Rich Freeman]

On Sun, Aug 28, 2016 at 8:34 AM, Patrick Lauer  wrote:
>
> Then tools forgot to properly update mtab because hurr why u no symlink
> to /proc/mounts (oh wait, /proc/self/mounts )
>
> So everyone migrated to /etc/mtab as a symlink (even OpenRC, because
> everyone does it)
>

I think containers were the final straw here (which strangely you do
not mention).  Good luck running openrc in a container with /etc/mtab
as a file, especially if you want to share /etc across multiple
containers.

Ultimately though this all comes down to the fact that files are a
pretty lousy way to store state of a running system, especially when
there are system calls to retrieve this state.

Sure, files are a nice place to store static configuration that gets
loaded into the state of a running system, since they're persistent.
The problem comes when software reads the files and assumes that they
ARE the state.

/etc should be for storing static configuration.  Processes shouldn't
generally be writing to anything there.  You should be able to mount
/etc read-only without much issue.  With the rise of containers and
configuration management and software-defined infrastructure and so on
this becomes increasingly important.

There is value in neither changing for the sake of change, or
remaining the same for the sake of the past.  Many historical
practices in the Unix world are inconsistent and it makes sense to
keep moving in the direction of making them consistent (like mtab,
having dhcpd modify /etc/resolv.conf, and so on).  Gentoo should make
similar sorts of changes (like not sticking the Gentoo repo in /usr,
and we probably shouldn't name it portage either).

There are also many historical practices in the Unix world that maybe
aren't pretty, but we probably ought not to change them just for the
sake of doing so without driving the change across distros (and I
think /etc/hostname strikes me as one of these; having more of the
host-level configuration in one place does make sense, but moreso if
everybody does it the same way).  Lots of distros actually try to move
configuration to one place, but they do it inconsistently and it seems
like somebody should be able to fix this (though you may find the
demand for consistency ends up getting satisfied by systemd to some
extent, simply due to its ubiquity).

I think williamh's approach of using hostname if it exists, and
falling back to conf.d is a pretty sane compromise.

-- 
Rich

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

[Patrick Lauer]

On 08/28/2016 08:30 AM, Daniel Campbell wrote:
> On 08/24/2016 09:42 AM, Zac Medico wrote:
>> On 08/24/2016 09:33 AM, Michael Orlitzky wrote:
>>>   * no benefit put forth so far, other than that it's the same file that
>>> systemd uses, which is true but not beneficial as far as I can tell
>>
>> It's a de facto standard. Being different for the sake of being
>> different is not a virtue in cases like this.
>>
> 
> And doing things because "everyone else does it" is dumb, because it
> precludes our ability to choose and makes us subject to the decisions
> made outside of our distribution. Of course, as a distro we're subject
> to outside decisions often, but what's the point of being a distro if
> you're doing things the same way everyone else does?


At this point I feel the need to point at /etc/mtab and how it doesn't
work anymore. Or rather:

In the old days it did *not* carry all mountpoints, so you could hide
things like /dev and /run so that "umount -a" would not screw you sideways.

Then tools forgot to properly update mtab because hurr why u no symlink
to /proc/mounts (oh wait, /proc/self/mounts )

So everyone migrated to /etc/mtab as a symlink (even OpenRC, because
everyone does it)

... and now if you still instincively use umount -a you unmount /run and
other bits, breaking lots of stuff (can't shutdown if OpenRC strongly
considers not having booted!)


That's why some of us are very resistant to change.
> 
> mjo made a good point. What if the meaning of /etc/hostname changes? Or
> rather, what if the file gets moved altogether? All this effort to
> "follow the flock" will lead to higher maintenance burden. Symlinking it
> in pkg-postinst or some other mostly-automatic behavior makes sense
> because then a package "owns" the file. Should an update happen where
> the decision to follow the flock is rescinded, a revbump with the
> symlinking line removed would cleanly get rid of the symlink without any
> user intervention and next to zero maintenance burden.
> 
> /etc/conf.d/hostname sits alongside multiple other files, including
> hwclock, consolefont, localmount, fsck, modules, sshd, udev, etc. By
> glancing at it, it's clear that /etc/conf.d/ relates to system (or
> rather, package) configuration.
> 
> Considering that OpenRC puts package configuration there, and OpenRC (by
> default) looks for the hostname file in that directory, it's a
> non-issue. Why should OpenRC look elsewhere for configuration when
> there's already a place for it?
> 
> If systemd or other inits need it, then they should install the file and
> guess the initial value by sourcing /etc/conf.d/hostname. It's none of
> OpenRC's concern what other inits need.
> 

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

[Zac Medico]

On 08/27/2016 11:30 PM, Daniel Campbell wrote:
> On 08/24/2016 09:42 AM, Zac Medico wrote:
>> On 08/24/2016 09:33 AM, Michael Orlitzky wrote:
>>>   * no benefit put forth so far, other than that it's the same file that
>>> systemd uses, which is true but not beneficial as far as I can tell
>>
>> It's a de facto standard. Being different for the sake of being
>> different is not a virtue in cases like this.
>>
> 
> And doing things because "everyone else does it" is dumb, because it
> precludes our ability to choose and makes us subject to the decisions
> made outside of our distribution. Of course, as a distro we're subject
> to outside decisions often, but what's the point of being a distro if
> you're doing things the same way everyone else does?

Is /etc/fstab dumb? How about /etc/hosts? Should we use something
different, just because we can?
-- 
Thanks,
Zac

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

[Daniel Campbell]

On 08/27/2016 11:48 PM, Michał Górny wrote:
> On Sat, 27 Aug 2016 23:30:09 -0700
> Daniel Campbell  wrote:
> 
>> On 08/24/2016 09:42 AM, Zac Medico wrote:
>>> On 08/24/2016 09:33 AM, Michael Orlitzky wrote:  
   * no benefit put forth so far, other than that it's the same file that
 systemd uses, which is true but not beneficial as far as I can tell  
>>>
>>> It's a de facto standard. Being different for the sake of being
>>> different is not a virtue in cases like this.
>>>   
>>
>> And doing things because "everyone else does it" is dumb, because it
>> precludes our ability to choose and makes us subject to the decisions
>> made outside of our distribution. Of course, as a distro we're subject
>> to outside decisions often, but what's the point of being a distro if
>> you're doing things the same way everyone else does?
> 
> And doing things different just because "we can" is even more dumb,
> because it precludes our ability to offer users consistent environment
> and makes us subject to the decisions made by random Gentoo developers
> long time ago. Of course, as a distro we're subject to single developer
> decisions often, but what's the point of being a distro if you are
> bound to bad decisions made in the past by a single person?
> 
> Not saying that I care but just pointing out how dumb this
> argumentation is.
> 
Well, the thing is that -- on a Gentoo system -- /etc/conf.d/ is pretty
consistent. We still ship some things in their typical location, like
fstab, locale.gen, etc, but those don't directly relate to OpenRC and
aren't (to my knowledge) part of its problem space. The files in
/etc/conf.d/ that don't relate to system settings are shortcuts to
setting daemon options instead of shoving them into the scripts.

So if we go with /etc/hostname, it's inconsistent with what we (Gentoo)
do but in line with most others. The inverse is also true, putting us in
a catch-22. The "do both" will attract ire from some of us, but the
prior suggestion to throw it into an ebuild phase will largely avoid
this bikeshedding. Whether or not the phase can do that *cleanly* and
*correctly* is another matter for a different thread, but I do think
Portage (the openrc or systemd/docker/whatever package(s)) should be
handling that on Gentoo in order to reduce clutter and confusion.

There is one technical concern, though... If the OpenRC ebuild symlinks
or otherwise owns /etc/hostname and the user switches to a systemd
profile, would Portage be smart enough to leave /etc/hostname alone and
let the packages switch ownership of the file? They create an ownership
block otherwise, as (I assume) systemd would also own the file. Other
inits may, as well, and I'm fairly sure you can run Gentoo without
OpenRC at all. Would we expect the user to create the file before
switching profiles, and not permit OpenRC to own the file?

-- off-topic below --

I think "because we can", in the right circumstances, is a great reason
to do something. That's how ideas are tested and come to fruition.
Distributions need to have some sort of vision or strongly held belief
in order to form a good following, or software that exemplifies said
vision. Collaboration is important, sure, but design-by-committee is
proven to be a terrible process that's prone to analysis paralysis,
bikeshedding, and encourages a culture of yes-men (and/or yes-women for
those who want PC speech). There is a middle ground where people work
together when it's beneficial and makes sense, and go their own way on
certain decisions. It's what created the distribution model in the first
place.

For the most part, the "we should do what everyone else is doing" train
is slowly reducing most distribution differences to a package manager
and some default backgrounds. I can't speak for you or other people but
I personally enjoy technical diversity. The distribution model allows
for many different approaches to be followed: things from Gentoo to
Slackware, Debian to Arch, Fedora, Gobolinux, CRUX, SuSE, etc. Doing
things "because we can" is a feature, imo, not a bug. A consolidated
GNU/Linux world would be terrible and far less colorful.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

[M. J. Everitt]

On 28/08/16 07:30, Daniel Campbell wrote:
> On 08/24/2016 09:42 AM, Zac Medico wrote:
>> On 08/24/2016 09:33 AM, Michael Orlitzky wrote:
>>>   * no benefit put forth so far, other than that it's the same file that
>>> systemd uses, which is true but not beneficial as far as I can tell
>> It's a de facto standard. Being different for the sake of being
>> different is not a virtue in cases like this.
>>
> And doing things because "everyone else does it" is dumb, because it
> precludes our ability to choose and makes us subject to the decisions
> made outside of our distribution. Of course, as a distro we're subject
> to outside decisions often, but what's the point of being a distro if
> you're doing things the same way everyone else does?
>
> mjo made a good point. What if the meaning of /etc/hostname changes? Or
> rather, what if the file gets moved altogether? All this effort to
> "follow the flock" will lead to higher maintenance burden. Symlinking it
> in pkg-postinst or some other mostly-automatic behavior makes sense
> because then a package "owns" the file. Should an update happen where
> the decision to follow the flock is rescinded, a revbump with the
> symlinking line removed would cleanly get rid of the symlink without any
> user intervention and next to zero maintenance burden.
>
> /etc/conf.d/hostname sits alongside multiple other files, including
> hwclock, consolefont, localmount, fsck, modules, sshd, udev, etc. By
> glancing at it, it's clear that /etc/conf.d/ relates to system (or
> rather, package) configuration.
>
> Considering that OpenRC puts package configuration there, and OpenRC (by
> default) looks for the hostname file in that directory, it's a
> non-issue. Why should OpenRC look elsewhere for configuration when
> there's already a place for it?
>
> If systemd or other inits need it, then they should install the file and
> guess the initial value by sourcing /etc/conf.d/hostname. It's none of
> OpenRC's concern what other inits need.
+1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

[Michał Górny]

On Sat, 27 Aug 2016 23:30:09 -0700
Daniel Campbell  wrote:

> On 08/24/2016 09:42 AM, Zac Medico wrote:
> > On 08/24/2016 09:33 AM, Michael Orlitzky wrote:  
> >>   * no benefit put forth so far, other than that it's the same file that
> >> systemd uses, which is true but not beneficial as far as I can tell  
> > 
> > It's a de facto standard. Being different for the sake of being
> > different is not a virtue in cases like this.
> >   
> 
> And doing things because "everyone else does it" is dumb, because it
> precludes our ability to choose and makes us subject to the decisions
> made outside of our distribution. Of course, as a distro we're subject
> to outside decisions often, but what's the point of being a distro if
> you're doing things the same way everyone else does?

And doing things different just because "we can" is even more dumb,
because it precludes our ability to offer users consistent environment
and makes us subject to the decisions made by random Gentoo developers
long time ago. Of course, as a distro we're subject to single developer
decisions often, but what's the point of being a distro if you are
bound to bad decisions made in the past by a single person?

Not saying that I care but just pointing out how dumb this
argumentation is.

-- 
Best regards,
Michał Górny



pgprvWW7zInkM.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] base-system needs developers who care

[Daniel Campbell]

On 08/25/2016 01:01 AM, Alexis Ballier wrote:
> On Tue, 23 Aug 2016 23:17:58 +
> "Robin H. Johnson"  wrote:
> 
>> Over the years, the base-system package herd has grown in size. Today
>> it comprises 320 packages, of which 61 of those have more than one
>> maintainer. The packages with more than one maintainer I'm only
>> concerned about if the other maintainer is also very busy or not
>> available.
>>
>> Some of these packages are very niche, and while they continue to
>> work, they could use a bit more attention than they get presently
>> (you might only hear about them when they break and never when they
>> work). 
>>
>> They are generally NOT broken and in need of tree-cleaning, but are
>> just lacking forward momentum (not a few bugs are reasonable upstream
>> bugs or feature improvements). Many were once shiny and had lots of
>> people that cared, but that dwindled as they become mundane and just
>> expected to work.
>>
>> General increase in the number of developers in base-system would not
>> be a bad outcome from this email either ;-).
> 
> 
> Count me in then.
> 
> What's the "official" way of joining these days ?
> 
afaict add yourself to the project on the wiki and then the usual mail
alias deal.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

[Daniel Campbell]

On 08/24/2016 09:42 AM, Zac Medico wrote:
> On 08/24/2016 09:33 AM, Michael Orlitzky wrote:
>>   * no benefit put forth so far, other than that it's the same file that
>> systemd uses, which is true but not beneficial as far as I can tell
> 
> It's a de facto standard. Being different for the sake of being
> different is not a virtue in cases like this.
> 

And doing things because "everyone else does it" is dumb, because it
precludes our ability to choose and makes us subject to the decisions
made outside of our distribution. Of course, as a distro we're subject
to outside decisions often, but what's the point of being a distro if
you're doing things the same way everyone else does?

mjo made a good point. What if the meaning of /etc/hostname changes? Or
rather, what if the file gets moved altogether? All this effort to
"follow the flock" will lead to higher maintenance burden. Symlinking it
in pkg-postinst or some other mostly-automatic behavior makes sense
because then a package "owns" the file. Should an update happen where
the decision to follow the flock is rescinded, a revbump with the
symlinking line removed would cleanly get rid of the symlink without any
user intervention and next to zero maintenance burden.

/etc/conf.d/hostname sits alongside multiple other files, including
hwclock, consolefont, localmount, fsck, modules, sshd, udev, etc. By
glancing at it, it's clear that /etc/conf.d/ relates to system (or
rather, package) configuration.

Considering that OpenRC puts package configuration there, and OpenRC (by
default) looks for the hostname file in that directory, it's a
non-issue. Why should OpenRC look elsewhere for configuration when
there's already a place for it?

If systemd or other inits need it, then they should install the file and
guess the initial value by sourcing /etc/conf.d/hostname. It's none of
OpenRC's concern what other inits need.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package up for grabs

[Hans de Graaff]

On Wed, 2016-08-24 at 15:26 +0200, Lars Wendler wrote:
> This package is now up for grabs:
> net-irc/rbot

I've added this package to the ruby project, but a more dedicated
maintainer would still be welcome.

Hans

signature.asc
Description: This is a digitally signed message part