Re: [gentoo-user] thin-provisioning-tools - but I don't provision anything!!!!!

[Daniel Campbell]

On 09/15/2017 02:43 PM, Alan Mackenzie wrote:
> On Fri, Sep 15, 2017 at 23:38:21 +0200, Marc Joliet wrote:
>> Am Freitag, 15. September 2017, 23:15:05 CEST schrieb Alan Mackenzie:
>>> Yes, but do I want it to go away?  What is it, what does it do?
> 
>>> OK, let's try emerge -s thin-provisioning-tools.  We get back only
>>> patronising garbage, namely "A suite of tools for thin provisioning on
>>> Linux" - well, duh!  Who write's this stuff?
> 
>>> So, WTF is thin provisioning?
> 
>> I'm tempted to ask whether google is down or something, but I'm tired and 
>> waiting for 7z to finish so here you go anyway:
> 
> For me, google is permanently down.
> 
>> https://en.wikipedia.org/wiki/Thin_provisioning
> 
> Yes, I've read it, thanks.  My question above was somewhat rhetorical.
> 
>> I would say you probably don't need to care about it.
> 
> I do.  I need to spend time and effort removing it.  It sounds like
> something only useful in servers, yet I have a desktop profile installed.
> 
> There's something not quite right, here.
> 
>> HTH
>> -- 
>> Marc Joliet
>> --
>> "People who think they know everything really annoy those of us who know we
>> don't" - Bjarne Stroustrup
> 
The USE flag is likely enabled by default so users won't have to rebuild
all of lvm2 in order to get one small feature that may be useful in
self-hosting or experimental/learning scenarios. That is, the feature
seems useful enough to add as a default. But the default is in
sys-fs/lvm2, not in a profile:

'''
# Assume gentoolkit is present
$ grep "+thin" $(equery w sys-fs/lvm2)
IUSE="readline static static-libs systemd clvm cman corosync lvm1
lvm2create_initrd openais sanlock selinux +udev +thin device-mapper-only"
'''

If you have app-portage/gentoolkit (I highly recommend it) you can run
`equery d sys-block/thin-provisioning-tools` to find what's pulling it
in. It's probably lvm2, which is expected if you use LVM for anything.
If you don't have any need for it:

* Add `USE="-lvm"` to make.conf to ensure you don't get LVM through IUSE
* Add `sys-fs/lvm2` to package.mask, but realize you may lose partial
functionality with some things, like net-fs/nfs-utils NFS v4.1 support.
* emerge --changed-use --ask @world
* emerge --ask --depclean

or

* Put `sys-fs/lvm2 -thin` in package.use, run `emerge --changed-use
--ask @world`, and go about your day.

If you want to learn what thin provisioning is, you'll have to do
research on it. Manpages, project pages, fora, tutorials, etc. A good
way to find detailed information is to look up support threads and see
what difficulties other people are having, so you can go straight to
useful advice. (search terms like "problem lvm thin provision") If the
software's remotely popular, you'll get some good results. Since we've
already established lvm2 uses it, you can consult its documentation
(usually found from HOMEPAGE) and get an idea for what it is. Some
terminology is understood differently in specialized scenarios, so the
only way to learn it is to read it.

A Web search for 'lvm thin provisioning' turned up results from Red Hat,
tech blogs, and other sources. This information is easily available, if
you're willing to seek it.
-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
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-user] remove gnome/systemd

[Daniel Campbell]

On 09/12/2017 03:07 PM, Heiko Baums wrote:
> Am Tue, 12 Sep 2017 17:28:40 -0400
> schrieb Mike Gilbert <flop...@gentoo.org>:
> 
>> I would advise against this INSTALL_MASK setting. It is quite likely
>> to break things (like sys-fs/udev).
> 
> No, it's not.
> 
> I'd consider it a bug if systemd is not installed and
> another package that doesn't depend on systemd relies on something that
> is installed in a systemd subdirectory.
> 
> And for me nothing was broken since several years now.
> 
> And, like I said, I'm using eudev instead of udev.
> 
> Heiko
> 
You may be using eudev (and thus don't need to worry about it), but if a
person blindly copies that into their make.conf and sys-fs/udev breaks,
they'll get to keep the pieces because they deliberately screwed
themselves. It's not a use case we can support. It doesn't mean
INSTALL_MASK is always a bad idea; it's simply meant to be used by
people who are fully aware of its effects.

-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
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-user] What do you think about Firefox 57?

[Daniel Campbell]

On 09/07/2017 07:47 AM, Ralph Seichter wrote:
> On 07.09.2017 15:20, Danny YUE wrote:
> 
>> Well, I know it is not the perfect place but I don't want to spam my
>> inbox with Firefox topics, so that's why I don't subscribe that mail
>> list and am asking here. ;-)
> 
> And you believe that spamming the inbox people interested in Gentoo
> (that's why we subscribed to this mailing list) is OK ? ;-) Seriously,
> this is completely off-topic here, so please use the appropriate mailing
> lists instead. Thanks.
> 
> -Ralph
> 
> 
> 
gentoo-user is for support *and* general talk.

https://gentoo.org/get-involved/mailing-lists/

-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
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-user] What do you think about Firefox 57?

[Daniel Campbell]

On 09/07/2017 05:26 AM, Danny YUE wrote:
> Hi all,
> 
> I have been using FoxyProxy in Firefox for a really long time, until
> today I found its new version really sucks.
> 
> Then I read the comment from author who declared that the old version
> can *only* be used before (roughly) end of 2017 before Firefox 57 and in
> new version some features must perish.
> 
> Afterwards I found that it seems Firefox 57 will use a new ecosystem for
> extensions and be more strict for plugin developers.
> 
> So Firefox gurus, what do you think about it?
> 
> 
> Danny
> 

I switched to Pale Moon a while ago, though I suspect fewer and fewer
mainstream sites will work with it as devs will begin requiring features
enabled in newer Firefox and Chrome (e.g. WebRTC, EME, localStorage,
etc). GitHub has already dropped support for Pale Moon, despite PM
supporting just about everything GitHub makes use of.

Losing XUL may be great from a security standpoint, but the feature-set
is lacking, it negatively impacts performance (no cache sharing,
blockers can't block correctly without a full render prior) and it all
reeks of a code merge. Why else would Mozilla be putting all this work
into looking *and* acting like Chrome? This behavior is that of a
company that is looking to get out of the market. They've already
abandoned their phone OS and their e-mail/calendar client. Firefox is
just the final nail in the coffin. Servo isn't up to snuff yet, and the
power users that gave Firefox its popularity are (like me) disinterested
in what passes for "modern Web". Many websites are flat-out malicious,
and more are insecure in general, largely due to feature creep in the
browser. Without the ability to protect yourself, it becomes a risky
decision to continue browsing a space filled with surveillance and
malware. In short, it's a dumpster fire. Like all grim scenarios,
however, there are sites out there that don't abuse people. But that
number is dwindling every day.

Aside from that, the hard requirement on PulseAudio is another strike
against it, and their culture wrt diversity is off-putting. Mozilla
isn't the Web leader it once was. To its credit, I don't think any
organization is "leading" the Web well. With the W3C approving DRM as a
standard in HTTP, it indicates a corporate acquisition of the standards
body, and it's no longer fit for purpose. We need a browser that is
opinionated and sticks to the standards that make sense, and hands
control of media to other programs. That would severely simplify the
browser, and leverage software that's generally already on a computer.
Web browsers as they are are fine for netbooks, which have little in the
way of system software. But for desktop machines, at least, most things
can be handed to a media player, PDF viewer, etc. The code's already
there: there are handlers for different protocols like irc:, mailto:,
torrent:, etc. Adding handlers via MIME-type would be fine.

As it is, I already don't read much on the Web. The experience has
become crap, even with blocking extensions. More trouble than it's
worth, most of the time. I have better things to do than endlessly tweak
my privacy just so sites don't slurp up all the metadata they can on my
connection. uBO, Privacy Badger, uMatrix, and others are great -- huge
jumps in quality compared to their predecessors -- but the rampant
misuse of the medium leaves me disinterested in the Web.

So few websites these days are designed with graceful degradation in
mind, let alone accessibility. It's all ECMAscript bells and whistles,
web "apps", etc. to the point where you have two systems: your Gentoo
system and your Web browser. I try to reduce complexity where possible,
balanced against safety. That leads me to an upstream who won't screw
with my interface and disrupt the add-on ecosystem because "this is
better for you".

Based on what I've read so far, Moonchild is up front about any
breakage, and warns about unsupported compilers or settings. One of our
regulars (Walter Dnes) helps maintain PM for us, too, so that's even
better. :)

But to be fair, I'll try it out when 57 is released so I have a stronger
opinion. I suspect I will be let down.

-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
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-user] systemD?

[Daniel Campbell]

On 08/30/2017 01:39 PM, mad.scientist.at.la...@tutanota.com wrote:
> I do not want to start a whole systemd storm, glad i was offline for
> that.  however, in my case i'd really like to avoid systemd.  can i
> setup with out systemd, or do i need to remove and patch later. 
> obviously better to start without it in this case.  so are some of the
> available kernels not systemd, and how much does it change the 
> installation?  i did search for it, and found a couple docs at
> gentoo.org it doesn't look too bad.  thanks.
> 
> -- 
> The Power Of the People Is Stronger Than The People In Charge.

We have a wiki page for it [1] that I'm awaiting review on for my edited
version[2], which briefly goes over the steps needed to setup Gentoo
without systemd.

In short:

eselect profile list
(choose one that doesn't have 'systemd' in its name)
eselect profile set [profile-number]

make.conf:
USE="$USE -systemd"

(sidenote: is logind a USE flag yet?)

package.mask:
sys-apps/systemd
sys-fs/udev

Remerging virtual/udev after configuring the above will pull in
sys-fs/eudev, which is a drop-in replacement for systemd-udev. Be sure
to merge your preferred init, and systemd will be removed on the next
depclean (if present and not in a set somewhere like @world).

[1]: https://wiki.gentoo.org/wiki/Gentoo_Without_systemd
[2]: https://wiki.gentoo.org/wiki/User:Zlg/Drafts/Gentoo_without_systemd

-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
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-user] Re: maim screenshooting

[Daniel Campbell]

On 08/01/2017 10:00 AM, Ian Zimmerman wrote:
> On 2017-08-01 03:00, Daniel Campbell wrote:
> 
>> # Add '-s' to interactively set the window to be captured.
>> screenie() {
>>  local curdir=$(pwd)
>>  local shotname=$(date +%Y-%m-%d_%H-%M).png
>>  echo "5 seconds! Go go go!"
>>  cd ~/img/screens/comp/
>>  scrot -d 5 -q 70 "$shotname" ${@}
>>  echo "Screen taken! Find it under ~/img/screens/comp."
>>  cd $curdir
>> }
>>
>> (now that I'm looking at it, it could use a spruce up to use pushd/popd
>> instead of storing the starting dir in a variable...)
> 
> pushd and popd are bashisms, your current way works with any POSIX shell.
> 
That's good to know!

I went in search of a few portable shell resources. Some suggest to use
dash or posh for the testing environment. I also found shellcheck, which
looks pretty promising (and it's in the tree! Thanks jlec). Do you have
any experience in portable shell scripting? My web search didn't return
a whole lot of good resources. Mostly just Stack Overflow and a few
tutorials which pointed to other resources.

What do you suggest?
-- 
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-user] Re: maim screenshooting

[Daniel Campbell]

On 07/31/2017 07:23 AM, Grant Edwards wrote:
> On 2017-07-30, tu...@posteo.de <tu...@posteo.de> wrote:
> 
>> I found this:
>>
>> "This is a basic, but useful command that simply screenshots the current 
>> active window.
>>  $ maim -i $(xdotool getactivewindow) ~/mypicture.jpg
>> "
> 
> [...]
> 
>> For what such a command is good for?
> 
> It's only an example.  If you don't want a screenshot of the active
> window, then specify a different one. You could also delay that
> command like this:
> 
>  $ sleep 10; maim -i $(xdotool getactivewindow) ~/mypicture.jpg
> 
> Then you've got 10 seconds to activate whatever the widow you do want
> a screenshot of.
> 
media-gfx/scrot is another good utility for that. Has a mode to
interactively choose the window you want to capture (-s), too. I've got
it hooked up to a bash function:

# Add '-s' to interactively set the window to be captured.
screenie() {
local curdir=$(pwd)
local shotname=$(date +%Y-%m-%d_%H-%M).png
echo "5 seconds! Go go go!"
cd ~/img/screens/comp/
scrot -d 5 -q 70 "$shotname" ${@}
echo "Screen taken! Find it under ~/img/screens/comp."
cd $curdir
}

(now that I'm looking at it, it could use a spruce up to use pushd/popd
instead of storing the starting dir in a variable...)
-- 
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-user] To install a testing version of a package on a stable OS installation.

[Daniel Campbell]

On 07/09/2017 12:59 PM, Ста Деюс wrote:
> Hi.
> 
> 
> Is it possible to compile/install a testing version of a package w/ its
> dependencies on a stable OS installation? -- I mean, if a have stable
> installation of whole the system, can i compile and install a testing
> version of single package and the packages this single package depends
> on?
> 
> 
> Thank you for your time,
> Sthu.
>

Yep, it can be done! Fairly easily, too:

A good way to do this (imo) is to create binary packages for any
packages you're going to be upgrading *BEFORE* attempting to install
from ~arch. This gives you a "get out of jail free" card to play around
with the ~arch package(s) and revert (by reinstalling the binary
package) in case it was a bad decision to upgrade. It's a good idea to
do this for any packages that could seriously break your system, like
toolchains.

Check out `man 5 make.conf`, `man quickpkg`, and `man
package.accept_keywords` for more information.

In short:

* Set '~arch' or equivalent in p.accept_keywords for the package(s)
  you're upgrading.
* Check `emerge -pv cat/foo` output, where cat/foo is the package being
  upgraded.
* Run `quickpkg` on the packages that you care about not breaking,
  especially anything close to the toolchain. Be sure to read the
  manual first, as usual. :P
* Double-check to make sure the binary packages are available. They'll
  be in $PKGDIR, defined in /etc/portage/make.conf.
* Run your emerge magic to upgrade.
* ???
* Profit!

-- 
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-user] Restricting git downloading the whole server farm and yet some

[Daniel Campbell]

On 07/07/2017 08:49 AM, Mick wrote:
> On Friday 07 Jul 2017 05:28:25 Rasmus Thomsen wrote:
>> I guess you could add "EGIT_CLONE_TYPE=shallow" to your make.conf, that way
>> you don't have to download the whole repo with all of its commit history.
>>
>> Regards,
>> Rasmus
> 
> Thanks! I will try this, but I am surprised it is not the default.  For two 
> packages I think I had to download the best part of 1GB of unneeded (by me) 
> cruft, which I will never look at or use.  I mean, there must be a cleverer 
> way of emerging a package without mirroring a complete project's history ...  
> O_O
> 
dev-libs/efl- is a live ebuild, meaning it's pulling from a version
control system. It appears there are two other versions of the package,
which shouldn't be pulling from git. If 1.17.0-r1 or 1.18.4 meet your
needs, a downgrade is all you'll need. Check
/etc/portage/package.accept_keywords and its manpage for more info.

If you need the live ebuild, Rasmus's suggestion will work fine.
-- 
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-user] Wow, the GTK3 file browser is awful!

[Daniel Campbell]

On 05/22/2017 12:40 PM, Kent Fredric wrote:
> On Mon, 22 May 2017 18:33:47 + (UTC)
> Grant Edwards <grant.b.edwa...@gmail.com> wrote:
> 
>> Having just recently allowed Firefox to upgrade from 45 to 52, I'm now
>> hobbled with the GTK3 file browser dialog.
>>
>> It's horrible.
> 
> Indeed :/. You're not alone, but what can we do about it?
> 
> Its not like we have sufficient staff to maintain a "Firefox but with
> GTK2" fork, heck, we can't even keep alsa support.
> 
> I've gone to using other older firefox forks (palemoon) instead simply
> because this march of progress doesn't seem to be delivering on that
> "progress", only making the user experience more boring and generic,
> and thus, more useless.
> 
> "One size fits all, copy everyone else" is not a useful axiom to me.
> 
> But at this rate, every browser trying to be "more like what the masses
> want" will end me up having no browser that exists and works that works
> how I want.
> 

I'm in a similar camp, using Pale Moon as my primary browser. I've found
the ads and constant bombardment of Javascript don't make for fun,
intuitive, fast, or useful browsing. There's much one can do to combat
it, but I think what needs to happen is an anti-Web 3.0 (2.0 was the
Semantic Web and the self-publishing boom) browser: a browser that
focuses on the "interlinked documents" Web and not the "every page is an
application" Web. I think there's sufficient demand for that version of
the Web to attract attention. I lack the experience to tackle it myself,
or I'd have started the project already.

It's possible to mold an existing browser to suit that ideal, but it
requires consistent vigilance to make sure new features or new defaults
don't reverse the work you put into it. It's stressful, I see why people
get tired of it.

(shameless praise follows)

Another alternative is the gopher protocol, which is slowly gaining a
following. It doesn't fill all the same holes the Web does currently,
but it could with a high quality client. Current clients are rather
lacking, though lynx can be configured to work with gopher and even
download images/videos to be opened by a custom program (I like piping
images to feh). All lynx is really missing is the 'unofficial' gopher+,
which adds a few more data types and allows direct linking to HTTP
addresses.

An additional benefit is Gopher -- being plain-text -- can easily be
filtered and "blockers" could block specific things if textual ads
become a problem. Many existing tools (like awk or sed) could be
leveraged to make that happen. It's also stupid simple to put a "gopher
hole" together, since it's just basic I/O. Even servers can be put
together in ~100 lines of bash. It's a breath of fresh air compared to
working with the Web, imo.

(usual disclaimer that my views don't represent Gentoo's official views,
etc)

~zlg
-- 
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-user] Re: How do I turn off text console screen in software?

[Daniel Campbell]

On 05/10/2017 04:08 PM, Walter Dnes wrote:
> On Wed, May 10, 2017 at 03:36:05PM -0400, Jonathan Callen wrote
> 
>> Additionally, "setterm --blank force" turns the console off immediately.
> 
>   Thank you; that's exactly what I was looking for.  My script
> ~/bin/dark now reads...
> 
> #!/bin/bash
> sleep 1 && xset -display :0.0 dpms force off
> setterm --blank force
> 
> ...so I can execute "dark" in either X or a true text console, and it
> works in both cases.
> 

If I may suggest an enhancement, you might want to probe the environment
the script is running in so that only the relevant command gets run;
unless of course you really do want everything off at once regardless of
whether X is running..

-- 
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-user] Re: htop wants cgroups

[Daniel Campbell]

On 05/01/2017 08:01 AM, Jorge Almeida wrote:
> On Mon, May 1, 2017 at 2:46 PM, Rich Freeman <ri...@gentoo.org> wrote:
>> On Sun, Apr 30, 2017 at 4:17 PM, Kai Krakow <hurikha...@gmail.com> wrote:
>>> Am Sun, 30 Apr 2017 10:33:05 -0700
>>> schrieb Jorge Almeida <jjalme...@gmail.com>:
>>>
>>>> It makes sense that the kernel has it. Should it be enabled? For a
>>>> server, probably. For a single-user workstation? Maybe.
>>>
> 
>>
>> Honestly, I can't think of why you wouldn't want to use it.
>>
>> The use cases of killing orphan processes and managing resources at a
>> service level have already been mentioned.
> 
> I don't usually have orphan processes (that process 1 doesn't reap).
> My services don't require fine tuning re resources.
> 
>>
>> Another use case is that the kernel automatically takes cgroups into
>> account when scheduling.  So, if one of your services launches a bunch
>> of children they'll be weighted together when allocating CPU.  That
>> means that a service with ten threads won't get 10x the CPU of a
>> service with one thread if CPU becomes limiting, assuming equal
>> niceness/etc.  On a multi-user system the same would apply to the user
>> running 100 processes vs 1.
>>
>> I also use cgroups to monitor memory use/etc at a service level.
> 
>  I don't have complex services (some might argue that very complex
> services are badly designed services, but I leave that discussion to
> pros). I only run single-user workstations.
> 
>>
>> Sure, they're somewhat optional, but they're a pretty useful kernel feature.
> 
> No arguing there. Still, it shouldn't be pushed. It's a bad sign.
> 
> Jorge
> 
cgroups are not being pushed in this case. Portage threw up a warning,
letting you know that some features of htop may not be available without
the CONFIG_CGROUPS flag on in the kernel. htop should work to your
liking as it is right now. Go try it out!

I'm having a little trouble understanding why this particular package
has you worried when there are dozens of others that spit out similar
"heads up" warnings, like qemu, anything relating to graphics and
virtualization... they're helpful messages that let you know that, if
something doesn't work as you expect, it's probably due to something you
have disabled. That's it.

Perfect example: I use an AMD processor, but still get 'warning'
messages about checking CONFIG_KVM_INTEL and other variables. qemu still
works, because my kernel is built to virtualize with my CPU. Someone
with an Intel CPU might really want that warning message, though.

I've not dabbled in cgroups but they seem very useful to those who need
to manage processes in ways the kernel itself can enforce. Cgroups
merely help htop do its job.
-- 
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-user] How do you manage manually compiled software?

[Daniel Campbell]

On 04/27/2017 07:19 PM, Michael Orlitzky wrote:
> On 04/27/2017 09:33 PM, Danny YUE wrote:
>> Hi guys,
>>
>> I am compiling RISC-V tools...I am just curious how do you manage your
>> manually compiled software?
> 
> Don't, write an ebuild for it.
> 
> 
> 
+1 for this. Even if it's a somewhat amateur ebuild, at least Portage
can manage it.

-- 
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-user] Difficulty setting up apache, php and joomla

[Daniel Campbell]

On 03/25/2017 09:13 AM, Mick wrote:

On Saturday 25 Mar 2017 11:13:36 Michael Orlitzky wrote:

On 03/25/2017 10:48 AM, Peter Humphrey wrote:

Hello list,

I'm setting up a new little box to be a web development server, to develop
a new website for my choir. I have it running with the old site,
hand-crafted from HTML and CSS, but after installing joomla into the new
site and on attempting to open index.php to configure it, as instructed,
I get this in
/var/log/apache2/error_log:

Joomla 3.4.x is not compatible with php-7.x:

   https://downloads.joomla.org/technical-requirements#footnote-3xPHP

You'll need Joomla 3.5 at least.

Or if you want some unsolicited advice and you're not picky about the
CMS: avoid Joomla. The user interface is incomprehensible, updates
require manual intervention, extensions are hard to write, and there's a
culture of paid support for things that should just work.


+1

Your error is due to Joomla, not apache.  I also recommend you give Joomla a
wide berth and use Drupal instead, or select a responsive design static
template from the interwebs.  There are a few free templates around which will
do a fine job for a simple website.


If I may piggyback on the recommendations:

Pelican (powered by Python) is a very powerful static site generator, 
and deployment is basically whatever you want it to be. Pages are 
basically plaintext (markdown or asciidoc by default iirc) and the theme 
(template + CSS) is completely separate from the content. It supports 
translation with standard gettext, too. I use it to power my personal 
site. I write posts, commit and push remotely, and use a post-commit 
hook to rsync the generated HTML into the webroot. If that sounds cool, 
check it out. [1] It might meet your needs.


If you must go PHP, you might want to take a look at the PHP-FIG[2] 
(Framework Interoperability Group). I can't say I'm 100% in favor of 
their decisions, but their work has led to some standardization in the 
PHP world and you might find more modern tools through them.


Best of luck with your site, Peter!

[1]: https://getpelican.com
[2]: http://php-fig.org
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6

Re: [gentoo-user] invitation to gentobb project

[Daniel Campbell]

On Sun, Mar 12, 2017 at 08:56:00PM +, Ural wrote:
> Hello guys. I am sorry about a bit of offtopic, but if everyone is
> interested, I am inviting anyone into
> https://github.com/edannenberg/gentoo-bb project discussion thread here:
> https://github.com/edannenberg/gentoo-bb/issues/102, where we user
> Docker as engine and Gentoo GNU/Linux as host OS. We have some ideas on
> (possibly) the best server and LAMP/LEMP management using Gentoo, Docker
> and GentooBB. Discussing the most table, fastest and secure dedicated
> server configuration to host everything. Thanks
> 

The concept sounds pretty neat; what do you guys do different than a
typical Gentoo installation?

What does Gentoo do for a containerized environment? Does this project
include easier container management than usual? I like the
containers-as-services idea. If it's not hard to write/make one, I could
see this project taking off.

Thanks for sharing!


signature.asc
Description: Digital signature

Re: [gentoo-user] The final of free software

[Daniel Campbell]

On 01/08/2017 08:49 AM, taii...@gmx.com wrote:
> On 01/08/2017 11:44 AM, Dominus Mundi wrote:
>> sume time ago i blessed sume gentooers with technological advantage to
>> the future. I had good intentions but litel did i now that it would
>> lead to the free software wars. Upon returning to my time I fund that
>> free software was dead. Popular free sofware projects replaced by
>> government controled forks. We held a comite at my time and concluded
>> that it wus not posible to unscrew this mess without also hurting the
>> porn industrie whish is unaceptable so we voted on just giving
>> gentooers a heads up. We also considered killing Donald Trump before
>> he passes the one kernel law but unfortunately due to the grandfather
>> paradox and other freaky stuf past asesinations are forbiden by the
>> intergalactic constitution so brace yourselfes because the free
>> software wars are about to begin and it's gonna be bloody.
>>
>> Our hope is that this message will trigger a reaction that will cause
>> gentoo to be selected as the US Government approved distro for use in
>> the US and conquered territories (whish in a short time will cover
>> most of the planet). May the light that radiates from the primeval
>> hole shine upon all gentooers!
>>
>>
>> -- 
>> Securely sent with Tutanota. Claim your encrypted mailbox today!
>> https://tutanota.com
> Damn what drugs are you on man.
> 
I have no clue but I kinda want some now. This could be a good (read: so
bad it's good) movie.

-- 
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-user] New box

[Daniel Campbell]

On 12/29/2016 11:18 PM, J. Roeleveld wrote:
> On Friday, December 30, 2016 12:24:36 AM CET Dale wrote:
>> J. Roeleveld wrote:
>>
>>> As for the specs:
>>>
>>> - 8 core CPU: nice
>>
>> Makes me drool a bit here.  I want a 8 core CPU.  The only downside,
>> gkrellm won't have enough screen to show each core separately.  That's a
>> problem there.  lol  It already takes up the whole right side on one
>> desktop.  I guess I could make the thing shorter to fit them all in.
> 
> I know what you mean. What I miss is an option to have gkrellm on 1 side of 
> the screen and when I maximize a window, that doesn't hide gkrellm.
> I limited some of the sensors to be able to fit all 12 virtual cores.
> (Or if there is, where do I set it)
> 
> [snip]
> 
> --
> Joost
> 

If you're using Fluxbox, the 'slit' USE flag will allow for a sort of
"dock" you can put programs into 'dockapp' mode. I believe gkrellm can
be made to fit into the slit, which you can configure in a number of
ways. If gkrellm can send its own hints to the WM, that's probably
better though.
-- 
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-user] multiple monitor video resolution problem

[Daniel Campbell]

On 12/29/2016 09:46 PM, Bill Kenworthy wrote:
> Hi all,
>   I have upgraded my old core2 to an i7 on a x58 gigabyte MB.  Lots
> faster  but I am still using my older nvidia card (GF119 [GeForce GT
> 610] Nouveau driver), storage and original gentoo install.
> 
> The problem is that I have two monitors - a 1920x1080 on DVI and a
> 1280x1050 on vga.  On boot up until logging into the xfce desktop, the
> 1280x1050 resolution dominates.  I have changed the boot through to end
> of the initrd level using grub, and I can overide the X Windowes desktop
> using xrandr.
> 
> Whats left after logging in is an invisible bounding box of 1280x1050 on
> the desktop that I cant move icons out of, and the console on the
> 1920x1080 monitor is a 1280x1050 window on the 1920x1080 sized screen :(
> 
> The strange thing is that this all worked perfectly on the old hardware
> (basicly just a motherboard/memory/powersupply swap with the same
> videocard and gentoo system)
> 
> Is anyone able to offer suggestions?
> 
> BillK
> 
> 
I'm not sure if XFCE needs this, but do you have the 'xinerama' USE flag
enabled? I know Fluxbox needs it to handle multi-monitor. That might be
the missing piece of the puzzle.

-- 
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-user] Pale Moon Air-Gapped portage EAPI 6 Install WAS: [Logging] SSL with PM

[Daniel Campbell]

-12-21 21:26 
> /usr/local/portage/www-client/palemoon/palemoon-27.0.3-r4.ebuild
> 21c21
> < EGIT_REPO_URI="https://localhost/cgi-bin/cgit.cgi/Pale-Moon.git 
> git://localhost/cgi-bin/cgit.cgi/Pale-Moon.git"
> ---
>> EGIT_REPO_URI="git://github.com/MoonchildProductions/Pale-Moon.git"
> --
> 
> -rw-r--r-- 1 miro miro 5907 2016-12-21 00:42 
> /some-dir/palemoon-overlay/www-client/palemoon/palemoon-27.0.3.ebuild
> -rw-r--r-- 1 miro miro 5902 2016-12-21 21:29 
> /usr/local/portage/www-client/palemoon/palemoon-27.0.3-r5.ebuild
> 21c21
> < EGIT_REPO_URI="git://localhost/cgi-bin/cgit.cgi/Pale-Moon.git"
> ---
>> EGIT_REPO_URI="git://github.com/MoonchildProductions/Pale-Moon.git"
> --
> 
> -rw-r--r-- 1 miro miro 5907 2016-12-21 00:42 
> /some-dir/palemoon-overlay/www-client/palemoon/palemoon-27.0.3.ebuild
> -rw-r--r-- 1 miro miro 5903 2016-12-21 21:44 
> /usr/local/portage/www-client/palemoon/palemoon-27.0.3-r6.ebuild
> 21c21
> < EGIT_REPO_URI="http://localhost/cgi-bin/cgit.cgi/Pale-Moon.git;
> ---
>> EGIT_REPO_URI="git://github.com/MoonchildProductions/Pale-Moon.git"
> --
> 
> The: https://localhost/cgi-bin/cgit.cgi/Pale-Moon.git would have probably also
> worked, but it was refused because the cert is both self-signed and expired
> ;-) .
> 
> If the reader followed carefully, she/he will have noticed that only the
> last one (palemoon-27.0.3-r6.ebuild) worked, and I actually started this
> email with how that ebuild installed palemoon in my Air-Gapped machine.
> 
> If I show to have forgot any details (which I tried not to), I'll post them in
> another reply to this thread.
> 
> ( Ah, the cgit, maybe. It's just a regular cgit install, other than I
> wasn't able to get the cgit, in many months now that I use it, so that
> my apache would serve git listings and tar.gz's, tar.bz2's, and zip's,
> with rewritten urls to get read of the cgi-bin/cgit.cgi string in every
> url...
> 
> Otherwise, it's just
> 
> $ cd /where-I-keep-my-local-and-cloned-git-repos/Pale-Moon/
> git clone --bare . /where-my-apache-serves-git-from/Pale-Moon.git/
> 
> and then
> 
> # /var/www/localhost/cgi-bin/cgit.cgi \
>   --scan-tree=/where-my-apache-serves-git-from/ > cgit-repos
> 
> (and append that to /etc/cgit-repos)
> )
> 
> I'm actually kind of almost disbelieving that this has happened, because the
> naming appears as if it worked out by some luck, so unusual it is, with the
> spaces in the filenames
> (
> e.g. just see the:
> 
> git3-src EGIT_MIRROR_URI=git:
> 
> name of the directory, first level underneath /usr/portage/distfiles/
> ).
> 
> It couldn't have been designed to be this kind of strange naming in the
> very /usr/portage/distfiles/ , or could it?
> 
> Is this regular, or have I successfully installed by some chance?
> 
> Thanks if there will be any explanations and advice. And in the meantime, I
> really enjoy using Pale Moon in my Gentoo, both master and, of course,
> clone(s)!
> 
> Regards!
> 

Could you be a bit more concise? I'm not sure what exactly you're asking
about. A simple question or two might be enough to better explain your
problem.

-- 
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-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Daniel Campbell]

On Wed, Dec 21, 2016 at 07:56:29PM +0100, Heiko Baums wrote:
> Am 21.12.2016 um 14:03 schrieb Rich Freeman:
> > I don't agree that you are "forced"
> > to use systemd.  Maybe you might be forced to use a different browser
> > or fork your browser or patch it or stick with an old version and
> > backport security fixes if you want to use it without systemd some
> > day.
> 
> And there it is again this silly argument and this twisting of words.
> Typical for those Poettering fanboys.
> 
> > But, if the entire Firefox developer community quit and decided
> > to do something else (a la Thunderbird) you'd be in a similar boat.
> > Sometimes you get what you pay for.
> 
> And this again. You know the difference between OpenSource and ClosedSource?
> 
> You pay for ClosedSource. For OpenSource you don't need to pay. But I
> have neither time nor energy to explain you the philosophy (before
> Poetterix) of OpenSource. But I can tell you this much. OpenSource and
> its developers usually have no commercial intentions. It seems to be
> different for Poettering and his fanboys.
> 
> > I get that people who want to avoid systemd are frustrated by this,
> > but honestly it feels like spitting against the wind at this point.
> 
> And the arrogance and ignorance of Poettering's and his fanboys' again.
> 
> > I
> > was frustrated back when everybody stopped taking care of kde-3.5 and
> > kde-4 wasn't really ready and was a resource hog on older systems.  I
> > switched to xfce for a while, because ultimately I can't demand that
> > the kde project cater to my whims.
> 
> Just compare apples and oranges. Also typical for Poettering and his
> fanboys.
> 
> The situation with KDE has nothing - and I mean nothing - to do with the
> situation with systemd. But I have neither time nor energy to explain
> that, too. I would talk to a wall anyway.
> 
> > In general though, nobody is required to engage in
> > debates/arguments/etc here, or even read your posts.  People choose to
> > participate in list discussions just as they choose what software they
> > want to maintain.
> 
> There they are again: The apples and the oranges.
> 
> Heiko Baums
> 

I'm getting the feeling that others would be more receptive to your
communication if you weren't belittling them with name-calling. I
personally feel similarly about systemd and Poettering, but it's more
effective to target ideas and behaviors rather than people. Targeting
people will -- understandably -- cause them to become defensive, which
will only make them dig their heels in and decide you aren't worth
conversing with. I don't think that's your intention.

Rich has a point that we're dependent on code we don't write. So when a
project goes in a direction we don't like, we have three options: go
along with it, reject it and use something different, or fork it.

Most choose 1 or 2 because 3 is demanding and often requires a team.
Teams are hard, wetware is hard.

I'm 100% with you on the political front. As long as we have distros
that respect that choice -- Gentoo, Devuan, etc. -- we still retain the
ability to "dodge" projects like systemd or Firefox. Life may become a
bit more difficult due to learning a new package, or finding a new
project that "speaks to you", but ultimately libre software developers
are volunteers and we can't force them to do anything. This is the
Bazaar at work.

Ironically, there are parallels to this and the idea of markets. If a
vendor isn't providing what you want, do you attack them or simply go to
another vendor? In libre software, mindshare and participation are
currency. Taking your currency somewhere else is the best way to show
that you don't approve of a project's direction. Blog posts, forks, or
participation in other (competing) projects shows that you care enough
to devote time to it. Most in the community respect someone who "puts
their money where their mouth is", so to speak. Taking part and getting
involved shows that you care and are willing to help make goals become
reality.

So, what can you or others do about Firefox? Use another browser. Help
them out, even if it's testing or bug reports. That stuff matters. I've
already started looking for another browser, myself, since I plan to
excise PA from my system again some time. It can definitely be done.

At some point, you have to ask yourself, "How much do I care about
this?" If you care enough, you will do something about it. It's my hope
that my e-mail inspires you to become more active in libre software.

TLDR: You catch more flies with honey than vinegar.


signature.asc
Description: Digital signature

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Daniel Campbell]

On Wed, Dec 21, 2016 at 07:53:51AM -0500, Rich Freeman wrote:
> On Tue, Dec 20, 2016 at 10:49 PM, Daniel Campbell <z...@gentoo.org> wrote:
> > On 12/20/2016 06:33 PM, Rich Freeman wrote:
> >> We don't have some
> >> committee on high pick a winner and tell all the maintainers that they
> >> all have to move from supporting x to supporting y.
> >
> > Fair points across the board but this stood out to me. We *do* have
> > groups that, on some subset of the tree, exert what they feel to be
> > winners. QA, the KDE team, and GNOME team have all made formal
> > recommendations or requirements that they expect to see in ebuilds going
> > forward. QA is blessed by council of course, so they have a bit more
> > sway. But we're lying if we say we don't have committees making
> > decisions on packaging guidelines.
> >
> > That's not the same as choosing a single package and telling every one
> > to scram, but we're not hands-off, either.
> >
> 
> Anybody wishing to add stuff to the main repository does not get a
> choice in following QA policy (though these matters can be appealed to
> the Council).  However, their policies for the most part are fairly
> sensible and concern stuff like listing things as a dependency if you
> link to them and so on.
> 
> KDE and GNOME developers work as a team, but these teams do not have
> any exclusive control over anything in the tree.  If a Gentoo
> developer doesn't like what they've done with kmail they can add a
> kmail2 or kmail-rich0 or whatever that works they way they want it to.
> Heck, if a bunch of devs wanted to do their own thing they could start
> a kde-improved team if they wanted to.

Right, I'm not disagreeing with any of that. I was just pointing out
that we *do* have teams that enforce their view of how packages should
be handled -- whether with Council's authority (QA) or not (others).
Some groups attempt to assert control over certain USE flags, too. Most
of the time we just aim for consistency with flags, so I can't fault
that. But we're lying to ourselves if we pretend that there aren't
groups within Gentoo who exert policy against others and make package
decisions, be it legitimate or otherwise.

If you want examples, look at gtk <-> gtk2 <-> gtk3, or qt <-> qt4 <->
qt5. Or memcache -> memcached, bikeshedding wrt virtual providers, etc.
At a certain point, teams are given the go-ahead by someone in authority
(QA or Council usually) to make sweeping changes or urge maintainers to
make changes. I'm not saying this is 100% bad; I'm just ensuring we stay
honest about what we do as a distro.

No value statements are intended.

> 
> In general this doesn't happen, because the developers interested in
> maintaining these packages tend to agree on how they want to maintain
> them, or at least they don't care enough to bother with forking them.
> 
> How do you think we ended up with eudev?

I assume we ended up with eudev because upstream decided that
they were going back on their promise that udev would remain usable
without systemd. (I can fish up the e-mail -- sent by Lennart himself
-- if you'd like. It may take some time) To this day it still is, but
that's only until the successor to kdbus wriggles itself into the
kernel. At that point, they will have the leverage (and the excuse, in
their minds) to drop all support for udev outside of systemd.

eudev is an attempt to retain udev as it was originally -- init
agnostic. At some point in the future, it will become the only way to
get udev outside of systemd.

> 
> -- 
> Rich
> 


signature.asc
Description: Digital signature

Re: [gentoo-user] Portage spokes again...

[Daniel Campbell]

On Wed, Dec 21, 2016 at 10:06:00PM +0200, Alan McKinnon wrote:
> On 21/12/2016 21:51, Rich Freeman wrote:
> > On Wed, Dec 21, 2016 at 2:46 PM, Rich Freeman  wrote:
> >> On Wed, Dec 21, 2016 at 2:20 PM,   wrote:
> >>
> >>> The following USE changes are necessary to proceed:
> >>>  (see "package.use" in the portage(5) man page for more details)
> >>> # required by kde-plasma/kwin-5.8.3::gentoo
> >>> # required by kde-plasma/plasma-workspace-5.8.3-r4::gentoo
> >>> # required by net-p2p/ktorrent-5.0.1::gentoo[shutdown]
> >>> # required by @selected
> >>> # required by @world (argument)
>  =media-libs/mesa-12.0.1 wayland
> >>
> >>
> >> I suggest ignoring this for the moment and see if the info above
> >> resolves your systemd issues.  I'm not sure why kwin has the
> >> dependency that it does, but it looks to me like it is set up as a
> >> hard dependency that you can't avoid without modifying the ebuild.
> >> I'll see if I can figure out more.  The changes above should at least
> >> get rid of whatever is pulling in systemd.
> >>
> >> Installing wayland shouldn't actually hurt anything.  I noticed that I
> >> have it installed likely for the same reason, and it isn't like it
> >> will start running on its own. But, I'm not sure yet whether you can
> >> avoid it.
> >>
> > 
> > Well, I should have just waited to reply, but here is the issue:
> > https://mail.kde.org/pipermail/release-team/2015-July/008725.html
> > 
> > kwin does in fact have a non-conditional dependency on wayland, so you
> > need to install it.  It won't do anything if you don't run it, but it
> > is not possible to build kwin without wayland support.  Judging by the
> > claim in the email that it used to take 100 conditionals in the source
> > to make it optional, I doubt anybody in Gentoo will be patching this
> > anytime soon.  I guess you could always fork it if you wanted to.
> > 
> > So, sorry, not what you wanted to hear, and not really what I care to
> > hear either since I don't use wayland, but at least it doesn't need to
> > be running in this case.  I wouldn't be surprised if that changes in
> > the future, but everybody knows that xorg is on borrowed time right
> > now.
> > 
> > Well, if nothing else at least this splits the thread so that you can
> > reply to the systemd and the wayland issues separately...
> > 
> 
> 
> Doesn't it strike you as curious that the 4 extra wayland packages
> consume 8.5M installed (sans size of sources in distfiles) and for 18
> months no-one has raised nary a whimper about it, whereas recall the
> giant whinge-fest a while back about a few 10s of harmless unit files
> (text), each less than one fs block?

How does a file take up less than a single FS block? An inode has to be
allocated _somewhere_, does it not?

As for the KDE <-> wayland thing, it's possible KDE users don't care
about something like that. In fact I would argue that the average person
who wants a desktop environment cares little about the dependency tree
for said environment, because they care more about their DE than what it
takes to run it. It's also an exercise in insanity, given the size of
DEs. I applaud the teams working on packaging them; it's a huge effort.

Exceptions are obviously GNOME + systemd, which caused a large upset.
If/when KDE starts requiring wayland, I expect a similar, though
somewhat smaller outcry. It'll come down to having a quality Wayland
setup that's as smooth to get up and running as Xorg.

One of the issues with wayland adoption is 1) the sheer amount of
software that'd need to be ported (there's apparently an X-compatible
mode in Wayland or something, but I've heard nothing regarding its
quality or its interoperability), 2) its structure is not exactly clear,
3) afaik there is no known compositor that supports all the features
you'd want to see in a modern display manager, and 4) writing tools
for the display server basically depends on a competent and extensible
compositor since everything goes through it first.

What I see more likely in the future for Wayland are different levels of
"rich" experience, all using a common Wayland protocol to be
mix-and-match. So someone can have a barebones system with Fluxbox (like
me), but another Wayland implementation can have all the bells and
whistles the DE crowd is used to. Who knows?

> 
> For the record, openrc user here on Gentoo; systemd on Ubuntu at work
> (no feasible choice with Ubuntu)
> 
> -- 
> Alan McKinnon
> alan.mckin...@gmail.com
> 
> 


signature.asc
Description: Digital signature

Re: [gentoo-user] Portage spokes again...

[Daniel Campbell]

On Wed, Dec 21, 2016 at 02:04:05PM -0500, Rich Freeman wrote:
> On Wed, Dec 21, 2016 at 1:44 PM,   wrote:
> > Corbin Bird  [16-12-21 17:12]:
> > The first run of emerge tells me to add the systemd USE flag to dbus.
> > I did that and ran into to problems I reported.
> 
> Ok, I think you left that bit out...
> 
> And this is why it is helpful to understand why portage is doing
> something before just changing configuration settings.  Adding the
> systemd USE flag to packages is a really quick way to end up with
> systemd getting installed.  Generally speaking it shouldn't just
> happen by default...
> 
> Can you show the output when you add -t to the emerge command?  I
> think that will be helpful.  However, I think an earlier poster was on
> the right track when he pointed out that the tmpfiles virtual requires
> an unstable version of openrc.  I'm not sure why that was getting
> pulled in in the first place, and -t should show that.
> 
> >
> > emerge: there are no ebuilds built with USE flags to satisfy 
> > "media-libs/mesa[egl,gbm,gles2?,wayland]".
> > !!! One of the following packages is required to complete your request:
> > - media-libs/mesa-11.2.2::gentoo (Change USE: +wayland)
> > (dependency required by "kde-plasma/kwin-5.8.3::gentoo" [ebuild])
> > (dependency required by "kde-plasma/plasma-workspace-5.8.3-r4::gentoo" 
> > [ebuild])
> > (dependency required by "net-p2p/ktorrent-5.0.1::gentoo[shutdown]" [ebuild])
> > (dependency required by "@selected" [set])
> > (dependency required by "@world" [argument])
> > [1]20322 exit 1 emerge -t --update --newuse --deep --with-bdeps=y 
> > --tree --keep-going
> >
> > What?
> >
> > Now wayland shall be installed? IK!
> > I want my UNIX back!
> 
> Interesting.  I just noticed that it pulled in wayland for me.  I have
> no idea why kwin requires wayland support in mesa.  It obviously works
> fine with xorg.  I might do some looking into that.
> 
> There isn't really anything non-UNIX about wayland, though I'm not
> sure I'd be in a rush to use it just yet.  It is just a replacement
> for xorg (to say the least, it doesn't purport to be a
> feature-complete replacement and may never be).

Wayland may not be non-UNIX, but putting everything into the compositor
(including keyboard input) just shifts responsibility to another piece
of software and actually complicates things a bit. I've not done much
digging into the matter but if I understood the structure of Wayland
correctly, you can't take screenshots or other talks-to-display-server
stuff unless the compositor supports it. With so much I/O going through
one thing (the compositor), it's ripe for abuse and security problems.

Of course, that doesn't make Xorg's security problems go away... like
any other set of competing software, you're trading one set of pros/cons
for another.

I've not seen anything about Wayland that convinces me it's hands-down
better.

That plasma dependency sounds weird, though. If you're not using
Wayland, it shouldn't require mesa to support it.

> 
> Your wayland issues and your systemd issues are most likely entirely
> unrelated...
> 
> -- 
> Rich
> 


signature.asc
Description: Digital signature

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Daniel Campbell]

On 12/20/2016 06:33 PM, Rich Freeman wrote:
> We don't have some
> committee on high pick a winner and tell all the maintainers that they
> all have to move from supporting x to supporting y.

Fair points across the board but this stood out to me. We *do* have
groups that, on some subset of the tree, exert what they feel to be
winners. QA, the KDE team, and GNOME team have all made formal
recommendations or requirements that they expect to see in ebuilds going
forward. QA is blessed by council of course, so they have a bit more
sway. But we're lying if we say we don't have committees making
decisions on packaging guidelines.

That's not the same as choosing a single package and telling every one
to scram, but we're not hands-off, either.

-- 
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-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Daniel Campbell]

On 12/18/2016 07:16 AM, Rich Freeman wrote:
> On Sun, Dec 18, 2016 at 3:23 AM, Daniel Campbell <z...@gentoo.org> wrote:
>>
>> Thankfully the kernel seems to have sane management; as long as Linus is
>> around, anyway. Just recently AMD had some of their code rejected, so
>> with a vigilant-enough team, you can effectively protect your project
>> from monied interests (be it poor code or an attempt to manipulate). Now
>> picture what might have happened if AMD was employing Linus or had some
>> other sort of contract. (For the record, I use an AMD CPU and like it;
>> they just happened to be the most recent corporation who's rejected code
>> popped on my radar. No bias intended.)
>>
> 
> I think this is an oversimplification of the issues involved in the
> AMD situation, which as with so many of these things people just
> jumped on picking sides.  And I think what has gotten lost is an issue
> that actually comes up somewhat often in FOSS.
> 
> [snip]
> 

Thanks for sharing more details about what happened, but those details
were irrelevant to the point I was making. I focused on the fact it was
rejected, despite being corporate code. The reasoning, in this
conversation, isn't important. It was an example of a project (the
kernel) that focuses more on quality than on the economic origin of the
code. That's it, no subtext.
-- 
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-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Daniel Campbell]

On 12/17/2016 11:45 PM, Tom H wrote:
> On Sat, Dec 17, 2016 at 4:36 AM, Daniel Campbell <z...@gentoo.org> wrote:
>> On 12/17/2016 12:53 AM, Neil Bothwick wrote:
>>> On Sat, 17 Dec 2016 00:55:21 -0500, Walter Dnes wrote:
>>>>
>>>> Again, the average home user is being jerked around for
>>>> a corporate agenda.
>>>
>>> Yes, it is disgusting that developers add the options desired by those
>>> that pay their wages while completely ignoring the users that give them
>>> nothing! It's almost like they are scratching their employer's itch while
>>> ignoring yours.
>>
>> I get where you're coming from, but Walter's talking about a real
>> concern when it comes to libre software and corporate involvement. The
>> profit motive has the potential to devastate community-oriented
>> operations, be they libre software, swimming pools, common areas,
>> municipal Internet, or even housing efforts. That potential for damage
>> should be baked into any community-based operation's decision-making
>> process.
> 
> Greg KH has (IIRC) made the argument that it's the involvement of
> corporations that has helped Linux grow exponentially, unlike the
> BSDs. (IIRC, he attributed their involvement to the GPL, but that's a
> different topic.)
> 

The licensing absolutely had the attention of companies. A kernel, free
of cost? And oh snap, the OS that started the free software movement --
these two projects aren't likely to change a whole lot in their
licensing or approach. They're _the_ foundation of a system, so
naturally if a business intends to build something, they'll want to
build on the lowest, most stable level.

Thankfully the kernel seems to have sane management; as long as Linus is
around, anyway. Just recently AMD had some of their code rejected, so
with a vigilant-enough team, you can effectively protect your project
from monied interests (be it poor code or an attempt to manipulate). Now
picture what might have happened if AMD was employing Linus or had some
other sort of contract. (For the record, I use an AMD CPU and like it;
they just happened to be the most recent corporation who's rejected code
popped on my radar. No bias intended.)

Growth comes from multiple things: quality, interest, cost, and
extensibility. The kernel definitely has the last one; modules are a
staple now. Maybe they weren't when it was first released. Quality has
naturally improved over time, but I think that's the most variable part,
since quality means different things to different people. Linux being
extensible coupled with a permissive license allowed companies to fix
bugs themselves and, if the code is good enough, spread their fixes to
everyone else. Other companies may see that, and either take part in
contributing code (for notoriety), or use it in-house to reduce costs
and improve whatever metrics like uptime or what-have-you. A community
then builds.

None of those actors have to be corporate, money-seeking entities in
order for growth to occur. Corporate involvement may have *accelerated*
Linux's growth, but it had quality of design and code going for it, so
growth was inevitable as it filled a huge niche at the time and
continued to do so until the BSDs opened up and GNU Hurd was released.
By that point, most heavy development was already on Linux, and the risk
of switching to another OS/kernel -- after contributing code to Linux --
would be a hard sell to a company. BSD of course garnered a decent
portion of the networking world and found its own niche, but Linux had a
lot going for it early on that helped spike its growth, separate from
*who* that growth came from.
-- 
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-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Daniel Campbell]

On 12/17/2016 08:58 PM, Andrej Rode wrote:
> 
>> Funtoo, knoppix and devuan are not serious professional grade distros,
>> two of those are in beta and gentoo isn't something you want on most
>> production servers.
>>
>> You can't be seriously suggesting that hobbyist distros with one or two
>> developers and bad security policies is a serious replacement for the
>> systemd corrupted distros can you?
> 
> So bascially you want to have a professinal grade distribution developed
> by independent hobbyists for free?
> Somehow distro maintainers have to be fed and live from something. So
> either you have a corporate-free hobbyist distro with a handful of devs
> or you have to suck it up and deal with it that people get paid by
> companies to develop free software (which is actually a good thing). And
> their company can give them directions how to develop free software they
> are working on.
> 
> Cheers,
> Andrej
> 

I don't think it's that clear-cut (companies paying for libre software
devs == good). Moneyed interests in something *can* be good for both
sides, if fair business is conducted. Frankly, most businesses get it
wrong, as can be expected from a profit-oriented entity.

Paying devs to work on libre software and telling them what to work on,
while mostly normal practice in the profit-driven world, can create
effects (unintended or otherwise) that guide other software; especially
if a business is employing a developer working on pivotal, important
projects. A business's direction of that employee can create ripples
throughout the rest of the libre software ecosystem that other projects
may have to work around or be forced to depend on the corporate work to
continue existing. Innocent enough at first, sure. Projects become
obsolete or have to change their dependencies all the time. But if a
business is targeting specific parts of the stack, replacing it with
theirs, and urging others to depend on their new stack, it's blatantly
obvious that they're not interested in collaboration or playing fairly.
They want to own the stack and every mechanism in it. For what ends, I
have no clue. Possibly to peddle their stack as the *only* stack to
clients so they can rake in more business while the libre software world
gets stuck maintaining it. In short, it's a form of crowd-sourcing labor
that they wouldn't otherwise pay for. And the average programmer will
fall for it because it makes them feel important and, like the rest of
us, has this pesky need for a home, food, and enough cash to save away
for emergencies and/or retirement.

I agree with your opinion otherwise. It's not reasonable to expect
volunteers to be available, on-call, and alert to news 24-7; that's the
level of commitment you need to be a serious security worker, and nobody
has the spare funds to sit around and stay up to date on stuff without a
paycheck coming in.

I'm reluctant to point to them, but sports may have a good idea with
sponsorships. Some people in libre software could be sponsored, and some
companies could sponsor someone in a hands-off fashion, just letting the
developer do their thing while the dev does support, consulting, or
maybe patches for the company for their internal projects. That's a
relationship that could work, though just like any other monetization
scheme, it's prone to abuse from the money holder. Maybe CS curricula
should have Contract Law 101 or something to protect them from being
fleeced or manipulated.

The next best model is public sponsorship through platforms like Flattr,
Gittip, Patreon, and so on. It gives the developer full autonomy, but a
less dependable cash flow.

Giving talks and publishing books has been super successful for a few
people, but naturally takes up a lot of time and can be draining.

Business models aside, the only real fix for this is to get to a
post-industrial and post-labor world, where people aren't forced to work
to survive. There's no telling how long that will take, however, as
those with money naturally want to maintain their powerful position in
society. That change won't come peacefully, and unfortunately probably
not in our lifetimes.


-- 
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-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Daniel Campbell (zlg)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On December 17, 2016 11:10:04 AM PST, Walter Dnes  wrote:
> A note; the developers have stated in the Pale Moon forum that they're
>working on getting rid of gstreamer, and having Pale Moon talk directly
>to ffmpeg and libav.  This gets rid of one layer of middleware, and the
>associated security problems.

Thanks for sharing more about Pale Moon. I thought it was Windows-exclusive and 
64-bit oriented. Good to see it's cross-platform. Do you guys still write C++?
- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7NBxEYW5pZWwgQ2FtcGJlbGwgKEdlbnRvbyBEZXZlbG9wZXIpIDx6
bGdAZ2VudG9vLm9yZz4FAlhV5R0ACgkQASQOlFA54XDBGxAAuazBlCwN57wLg14z
IBUi+RSA8NMDFPSR0dpFPnOYWA/fnSs/TdCzZgjdPIYeAIdDgqJ68DDhtqHWfU4g
KRRKxDFEzrb4no5iDdJaI2nSAiMU4moCyAbl7CDGnSl6/rWYas/jMqee2V/Zl5N3
RJbPr0phCPMksa98uJFMQG/xSweHkIJY9Nl5QsXifuby1qn2uhkoWkkeQ/8ci8qu
p0vn3FVFUD2ZFJKR4sIfCj2LGuXXk7Rr/9WIdRs6Lk2CWE5iwEML3XV1+03kMrhs
B6Z2DS6AxQFlXWSlE3dQG80obMJG0k6WNgf6rNMM5sveDn2cIDDKfMtG/G7wCYuZ
JRbIUcFWf2Bb3GlDgU7cLrJlwrCNBJr7U7s76WFl2mEKrKX4dtqEe8+Y/gm9w3WJ
0FvLk4MFLFo6BnMAUE5Iv9x6GSIG+qSL3bbh2M/jbKaARUbepGwltqF0hcakiSjj
u1jIhyhXNneS1NeZ9RiBrwV/b9x6M5EgV3Me3KnUCg47UAG2ZkUJAMiijyWVh7ou
rTu23sUh3p+d1IA49t3FrHJImCNpOKlvFSz5UyzpNwTh8IL5ITBG8OJIQLGY/d3u
iJkV7qDcjzMtPZteaN8HOYQApK6wZH1j7g2DO4H45eq7PuYkaYsNDmld7HmPkKAE
klc838Ss6BhXxcFFcz3h0I8wwjI=
=mZG+
-END PGP SIGNATURE-

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Daniel Campbell]

On 12/17/2016 12:53 AM, Neil Bothwick wrote:
> On Sat, 17 Dec 2016 00:55:21 -0500, Walter Dnes wrote:
> 
>>> Well, he is a Red Hat employee.  Nobody really debates that.  
>>
>>   Maybe it's not intentional spyware malice, but rather that home users
>> are being jerked around while Redhat re-writes linux as a corporate OS.
>>
>>   Systemd does all sorts of management that isn't really required by the
>> regular home user, but Redhat doesn't give a hoot about their experience
>> being made more difficult.  Redhat only cares about their paying
>> customers.
> 
> Any non-trivial, off the shelf software does more than you need it to,
> it's the only way to be sure it does not do less than you need it to. I'd
> rather a program have ten features I don't need than be missing one that
> I do.
> 
>>   Similarly, the vast majority of home users have a machine with one
>> ethernet port, and in the past it's always been eth0.  Now the name
>> varies in each machine depending on the motherboard layout; oogabooga11?
>> foobar42?  It may be static, but you don't know what it'll be, without
>> first booting the machine.  In a truly Orwellian twist, this "feature"
>> is referred to as "Predictable" Network Interface Names.  It only makes
>> things easier for corporate machines acting as gateways/routers, with
>> multiple ports.
> 
> It wouldn't be so bad if they had provided an easy way to revert to the
> old behaviour like maybe a boot option or touching a file in /etc :(
> 
>> Again, the average home user is being jerked around for
>> a corporate agenda.
> 
> Yes, it is disgusting that developers add the options desired by those
> that pay their wages while completely ignoring the users that give them
> nothing! It's almost like they are scratching their employer's itch while
> ignoring yours.
> 
> Really, no one is forcing you to use anything. If you don't like the way
> particular piece of software is going, you can get a full refund and
> switch to something else.
> 
> 
That argument doesn't really offer anything of substance in return.
Yeah, "just use something else", until whatever entity has completely
owned the platform. What then? Switch platforms ad nauseum? At some
point, you need to take some sort of action. Talking about it is a good
start. It helps formulate and refine ideas that can turn into real,
tangible action. Usually it just ends in a fork; though there's nothing
wrong with that. It's a feature, not a bug.

I get where you're coming from, but Walter's talking about a real
concern when it comes to libre software and corporate involvement. The
profit motive has the potential to devastate community-oriented
operations, be they libre software, swimming pools, common areas,
municipal Internet, or even housing efforts. That potential for damage
should be baked into any community-based operation's decision-making
process. Sometimes a partnership can be great (like getting hosting from
a reseller for a rebate in return for some consulting or mentoring on
the side), sometimes it's bad (losing license to a given piece of
software because you wanted to improve or correct it (Linus and
BitKeeper, for the uninitiated)))

Just consider the source of all the 'innovations' coming down the pike,
and ask yourself why they wrote that software. I think that's solid
advice no matter what your opinion of corporations is.
-- 
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-user] Pulseaudio now needs USE="gnome"?

[Daniel Campbell]

On 12/10/2016 12:10 AM, Mick wrote:
> Hi All,
> 
> I have set up USE="-gnome" in my make.conf, but I saw this cropping up at my 
> latest emerge --update:
> 
> [ebuild   R] media-sound/pulseaudio-9.0::gentoo  USE="X alsa alsa-plugin 
> asyncns bluetooth caps dbus gdbm glib gnome* ipv6 orc qt4 ssl tcpd udev 
> webrtc-aec -doc -equalizer -gtk -jack (-libressl) -libsamplerate -lirc -
> native-headset (-neon) -ofono-headset (-oss) -realtime (-selinux) -sox (-
> system-wide) -systemd {-test} -xen -zeroconf" ABI_X86="32 (64) (-x32)" 0 KiB
> [snip...]
> 
> Total: 127 packages (83 upgrades, 3 new, 41 reinstalls), Size of downloads: 
> 268,203 KiB
> 
> The following USE changes are necessary to proceed:
>  (see "package.use" in the portage(5) man page for more details)
> # required by kde-plasma/plasma-pa-5.8.3::gentoo
> # required by kde-plasma/plasma-meta-5.8.3::gentoo[pulseaudio]
> # required by kde-apps/kdebase-meta-16.04.3::gentoo
> # required by @selected
> # required by @world (argument)
>> =media-sound/pulseaudio-9.0 gnome
> 
> which is dragging in gconf:
> 
> [ebuild  N ] gnome-base/gconf-3.2.6-r4:2::gentoo  USE="introspection ldap 
> (policykit) -debug" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7" 0 KiB
> 
> 
> I don't see gnome in REQUIRED_USE and since this is a relatively gnome-free 
> PC 
> I was wondering what's causing the above and if I can avoid gconf?
> 
> PS:  euse -i gnome shows:
> 
> [- c] gnome
> media-sound/pulseaudio: Use GConf to store user preferences on 
> streams and so on. Don't enable this flag if you want to use a system 
> wide instance. If unsure, enable this flag.
> [-  ] 7.1 [gentoo]
> [-  ] 8.0 [gentoo]
> [-  ] 9.0 [gentoo]
> 

When portage suggests a USE change due to a blocker, the "culprits" are
listed from "smallest" to "largest". So in this case,
kde-plasma/plasma-pa is the culprit: a quick `less $(equery w
plasma-pa)` shows that plasma-pa is depending on gconf and
pulseaudio[gnome].

If upstream has decided to depend on gconf, it makes perfect sense to
depend on PA with the 'gnome' USE flag. This is probably so plasma can
correctly run as a user and keep track of file/sound settings.

The KDE team can likely explain *why* this change happened, though you
might want to check the homepage for plasma-pa first. The KDE team can
be reached via the mail alias (kde@g.o) or on Freenode via #gentoo-kde.

I hope this helps clear things up for you.

~zlg
-- 
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-user] Firefox 49.0 & Youtube....Video: Yes - Audio: No...

[Daniel Campbell]

On 11/28/2016 08:30 AM, Miroslav Rovis wrote:
> I just got Firefox to play HTML5 pages (and likely other stuff as well),
> with audio working, my system.
> 
> But let me first vent my frustration for why it was so hard...
> 
> On 161120-20:46+0100, Miroslav Rovis wrote:
>> Hi Daniel!
>>
> ...
>> On 161120-00:10-0800, Daniel Campbell wrote:
>>> On 11/19/2016 01:59 AM, Miroslav Rovis wrote:
>>>> On 161119-10:22+0100, Miroslav Rovis wrote:
> ...
> 
> It took me such long time, well, yes, because ALSA had advanced and I
> kept the old config, simply because it worked with all apps (but not the
> Firefox, more below...)...
> 
> What other conclusion could a not very advanced user get but this one
> below?:
>> Just in the meantime, a (hopefully) easier question: doesn't this bug
>> below mean harder to get non-pulse audio to work with Firefox:
>>>>>>>>> Mozilla went pulse all the way:
>>>>>>>>>  Require PulseAudio on Linux
>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1247056
>>>>>>>>> See also:
>>>>>>>>> Firefox nightly requires Pulse Audio
>>>>>>>>> http://forums.debian.net/viewtopic.php?f=20=130028
>> and if the other info that the dev at alsa-user gave me:
>> http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg31929.html
>> where he gave the link to:
>> html5 in ff through jack
>> http://lists.linuxaudio.org/pipermail/linux-audio-user/2016-June/105188.html
> 
> And I've just delivered on this promise of mine:
>> if that means the info in that bug page is incomplte in the sense it is
>> misleading to users who want to stick with sans-pulse alsa... then once
>> I figure out how to do it, I'll post there for other users to know...
> Pls. read my comment of just some half hour ago:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1247056#c171
> 
>> [ I'll try all of your suggestions ... as I'm confident again there must
>> be a way to fix audio in FF without pulse... ] just as the other dev
>> said, that it is there, only for Archlinux, at:
>> http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg31927.html
> How on Earth would a non-advanced user know after reading that Mozilla
> bug, that she/he don't need to get that another layer for suspicious
> purposes onto their fine ALSA?
> 
> Now I'll explain what was the reason it did not work (because I promised
> I would ;-) and you were kind to offer help)...
> 
> On 161120-00:10-0800, Daniel Campbell wrote:
>> On 11/19/2016 01:59 AM, Miroslav Rovis wrote:
>>> On 161119-10:22+0100, Miroslav Rovis wrote:
>>>> On 161119-00:33-0800, Daniel Campbell wrote:
>>> ...
>>>>>> And there is a question/query/my-asking-for-advice further below.
>>> ...
> ...
> No, jack was not needed, but according to:
> https://wiki.gentoo.org/wiki/ALSA#JACK_audio_connection_kit
> is far superior to pulseaudio, just to make clear. The below wasn't
> needed for me to solve my issue. 
>>>>>> [linuxaudio.org] html5 in ff through jack
>>>>>> http://lists.linuxaudio.org/pipermail/linux-audio-user/2016-June/thread.html#105188
>>> ...
> 
> This was one of two issues that needed to be fixed/put in place/corrected:
>>> Also:
>>>>> defaults.ctl.card x;
>>>>> defaults.pcm.card x;
> 
> Yeah! And what I had, the below...:
>>> I every do often change my default card... I have only these two lines
>>> (if I grep out all that is commented out) in my:
>>> $ cat ~/.asoundrc | grep -v '^#'  
> This:
>>> pcm.!default { type hw card 1 }
>>> ctl.!default { type hw card 1 }
> was wrong!
> (that's old config, maybe 2-3 or more years old. It just worked all the
> time, who cared... MPlayer, Vlc, the old cinch cables --the RCA IIRC--
> could get the recordings from old/new equipment... So who cared...)
> 
> So one of my two issues was exactly this one (and the change to make):
> https://wiki.gentoo.org/wiki/ALSA#Firefox_and_YouTube_have_no_audio_with_custom_.asoundrc_but_other_apps_do
> 
> And after making the other change first, which is simply what Gentoo Firefox
> Wiki says at:
> https://wiki.gentoo.org/wiki/Firefox#Lack_of_sound
> so after:
> # emerge gst-plugins-meta:1.0
> 
> and changing my ~/.asoundrc to:
> 
> defaults.ctl.card 0
> defaults.pcm.card 0
> 
> (or it will be
> 
> defaults.ctl.card 1
> defaults.pcm.card 1
> 
> sometimes, in my case)
> 
> only then did Firefox finally start to play both video and audio when I

Re: [gentoo-user] QEMU virtio_gpu

[Daniel Campbell]

On 11/25/2016 11:10 AM, john wrote:
> On Thu, 24 Nov 2016 13:12:33 +
> john <j...@jdm.myzen.co.uk> wrote:
> 
>> Hi,
>>
>> I am trying to run qemu virtual machine with virtio_gpu using the
>> following command 
>>
>> /usr/bin/qemu-system-x86_64 -enable-kvm -m 4096 -smp 8 -localtime
>> -cdrom Fedora-Workstation-Live-x86_64-25_Beta-1.1.iso  -boot
>> once=d,menu=off -vga virtio -display gtk,gl=on
>>
>> but getting the following error when machine gets to display manager
>>
>> (qemu-system-x86_64:3192): 
>> Gdk-WARNING **:gdk_gl_context_set_required_version - GL context
>> versions less than 3.2 are not supported. 
>>
>> No provider of glUniform4uiv found.  
>> Requires oneof: 
>> Desktop OpenGL 3.0 
>> OpenGL ES 3.0
>> GL extension "GL_EXT_gpu_shader4"
>>
>>
>> I have also tried using -display with sdl,gl=on
>>
>> I have tried this in another (arch) linux box and works so I think it
>> must be a use flag or something but struggling to find out which one
>> or perhaps missing something else!
>>
>> lsmod shows virtio_gpu
>>
>> emerge -vp mesa
>> media-libs/mesa-13.0.1::gentoo  USE="bindist classic dri3 egl gallium
>> gbm gles2 llvm nettle nptl -d3d9 -debug -gcrypt -gles1 -libressl
>> -opencl -openmax -openssl -osmesa -pax_kernel -pic (-selinux) -vaapi
>> -valgrind -vdpau -vulkan -wayland -xa -xvmc" ABI_X86="(64) -32 (-x32)"
>> VIDEO_CARDS="radeon radeonsi (-freedreno) -i915 -i965 -ilo -intel
>> -nouveau -r100 -r200 -r300 -r600 (-vc4) -vmware" 0 KiB
>>
>> virglrenderer is installed.
>>
>> If anyone has qemu and virtio-gpu running please let me know and I'll
>> keep trying.
>>
>>
>> Many Thanks
>> John
>>
> 
> After having a search around the net and trying a few things emerged
> mesa with the use flag -bindist and qemu machine fired up with
> virtio_gpu
> 
> the following command showed this in virtual guest
> dmesg | grep virt
> 
> Not sure what the bindist use flag is for but hey ho it's working.
> Now shall I ditch lxc for qemu??
> 
> John. Long live Gentoo (the Ferrari of Linux distros).
> 
> 
>  
> 
'bindist' is short for "binary distribution"; some code (mostly
microcode, firmware, GPU drivers, multimedia codecs) is copyright- or
patent-encumbered, meaning that you can't legally distribute some pieces
of software in binary (compiled) form. The 'bindist' USE flag, in
combination with the LICENSE variable in make.conf, give you the tools
needed to decide how free (libre) you want your system to be.

USE=bindist should be set per-package inside package.use, unless you
understand the implications of setting or unsetting it globally.

Great to read things are working!
-- 
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-user] Re: elog default lifespan

[Daniel Campbell]

On 11/19/2016 04:21 PM, Harry Putnam wrote:
> Mick <michaelkintz...@gmail.com> writes:
> 
>> On Saturday 19 Nov 2016 08:54:53 Harry Putnam wrote:
>>> After looking thru the portage man pages, the make.conf.example in
>>> /usr/share/portage/config, and the `Portage log wiki' it still is not
>>> clear to me how long elogs are kept if you use the `save' flag in
>>> make.conf or not.
>>>
>>> I did see something about '7 days' but it was not clear if that is the
>>> default and `save' over-rides it or what.  Or if there is another flag
>>> that controls there duration...
>>>
>>> Can anyone throw light on that?
>>
>> If you have logrotate then its configuration and associated cron jobs will 
>> take 
>> care of that.
> 
> What I want to know is if the elog program will do something on its
> own... I'm wanting to hang on to the logs a good while... I saw
> something in my readings about the elog system about 7 days... was not
> clear if that is a defalult or what.
> 
> So my fear was losing them even if I am logrotate at them in some
> capacity. So I'm asking about inside the elog program... what happens
> to the logs and when.
> 
> 
According to make.conf.example, PORTAGE_ELOG_SYSTEM="save" creates one
log per package under $PORT_LOGDIR/elog (/var/log/portage/elog if unset).

What this means is Portage will continue to use whatever path you have
specified, and it's up to your syslogd or logrotate to determine whether
those particular logs get deleted.

I suggest looking through /etc/logrotate{.conf,.d/} and grokking things
to determine how long your elogs will last. On my system, I noticed I
have /etc/logrotate.d/elog-save-summary, so if you find a file like
that, it's a good place to start. Without logrotate handling it, I see
no reason to believe Portage will nix elog output after 7 days.

In case I've missed something, could you link to the page that mentions
7 days? I searched through manpages and the wiki but haven't found any
other "save" option or anything to do with elog and 7 days.

-- 
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-user] Firefox 49.0 & Youtube....Video: Yes - Audio: No...

[Daniel Campbell]

On 11/19/2016 01:59 AM, Miroslav Rovis wrote:
> On 161119-10:22+0100, Miroslav Rovis wrote:
>> On 161119-00:33-0800, Daniel Campbell wrote:
> ...
>>>> And there is a question/query/my-asking-for-advice further below.
> ...
>>>>>> If jackd is to do with alsa, then it could be the following.
>>>>>>
>>>>>> Mozilla went pulse all the way:
>>>>>>  Require PulseAudio on Linux
>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1247056
>>>>>> See also:
>>>>>> Firefox nightly requires Pulse Audio
>>>>>> http://forums.debian.net/viewtopic.php?f=20=130028
>>>>>>
>>>>>>> Hmmm...
>>>>>>>
>>>>>>> Is there any fix for that?
>>>>>> Not familiar with jackd. But as far as alsa (which I stick to, like
>>>>>> other discontented users), I don't have sound since months ago.  The
>>>>>> only way to get it would be to compile alsa myself, I'm afraid. 
>>>>>>
> ...
>>>> In that thred on alsa-user archive that I linked to, I got this link:
>>>>
>>>> [linuxaudio.org] html5 in ff through jack
>>>> http://lists.linuxaudio.org/pipermail/linux-audio-user/2016-June/thread.html#105188
> ...
>> So it's only this, probably (and I had given links that, indirectly,
>> mislead another Gentoo user...):
> ( No, it's not only this: )
>>> Generally if you run into this problem, it's one of two things:
> I've looked all options of my alsamixer, and it doesn't appear to me
> that is's muted. I can play anything with MPlayer, and I can play an
> HTML video by giving the url to Vlc...
>>> 1. `alsamixer` hasn't been used to unmute the levels. After configuring
>>> it, be sure to run 'alsactl store' as root and make sure the 'alsasound'
>>> service is in the default run-level (`rc-update add alsasound default`
>>> as root), or...
>>> 2. Try adding these to your user's ~/.asoundrc file:
> 
> Also:
>>> defaults.ctl.card x;
>>> defaults.pcm.card x;
> I every do often change my default card... I have only these two lines
> (if I grep out all that is commented out) in my:
> $ cat ~/.asoundrc | grep -v '^#'  
> 
> pcm.!default { type hw card 1 }
> ctl.!default { type hw card 1 }
> 
> and sometimes I need to set it to 0, sometimes to 1 (depending of the
> update of the system and where the old Hauppauge HVR3000's audio, or the
> MBO's Intel HD Audio end up...
> 
> So this below is what I somehow practice since long:
>>> Replace 'x' with the numeric index of your card (which you can view in
>>> alsamixer using F6).
> That does give the option to choose the card. But it's only one of the
> two, the Hauppauge or the Intel HD...
> 
> Starting alsamixer and hitting F3 should be where to look for. And I
> don't see anything the changing of which gives me audio to work in
> Firefox...
>>> If the order of your cards changes on boot, you'll
>>> need to tell the module controlling your sound (snd_hda_intel is common)
>>> to set its index in a file like /etc/modprobe.d/alsa-base.conf, with
>>> lines like `options snd_hda_intel index=1` or something similar.
> I have all built in the kernel. I do have audio, such as with MPlayer or
> with Vlc, just I don't have audio in Firefox.
> 
>>> Others have done a far better job explaining this than me. Our own guide
>>> on our wiki [0] and Arch's wiki [1] should be adequate to get you going
>>> fairly quickly. Just Ctrl+F "default" to find what you need. Assuming
>>> you don't have exotic hardware, this can be fixed in 15 minutes or less.
>>>
>>> Hope this helps.
>>>
>>> [0]: https://wiki.gentoo.org/wiki/ALSA#Configuration
>>> [1]:
>>> https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture#Set_the_default_sound_card
> It appears to be basically the same info as in your kind explanation...
> 
> But this is now getting way more than 15 minutes... I will try to find
> more time, still, but not hours, for this issue...
> 
>> I don't think I even need to be back to report here if this just works
> No, it doesn't. And the issue is not solved yet...
> 
> Regards!
> 
Hmm, that's strange... Your config looks sane to me (though specifying
something as 'type hw' can interfere with mixing sometimes; an empty or
non-existent ~/.asoundrc should default to dmix internally. I doubt this
is your problem though since it works on everything else)

Here's an idea: try using the ALSA_CARD environment variable and run

Re: [gentoo-user] Firefox 49.0 & Youtube....Video: Yes - Audio: No...

[Daniel Campbell]

On 11/18/2016 10:11 PM, Miroslav Rovis wrote:
> Hi Meino!
> 
> I regret not having told you more... See below...
> 
> And there is a question/query/my-asking-for-advice further below.
> 
> On 161016-08:48+0200, meino.cra...@gmx.de wrote:
>> Miroslav Rovis <miro.ro...@croatiafidelis.hr> [16-10-16 07:00]:
>>> On 161015-20:27+0200, meino.cra...@gmx.de wrote:
>>>> Hi,
>>>>
>>>> this evening I updated GENTOO and a new firefox was installed.
>>>> This one seem completly to disable flash video finally...
>>>> since I got no video/audio at all.
>>>>
>>>> I disabled all flash-related addons of my firefox and
>>>> restarted  it.
>>>>
>>>> Now I got a video ... but without any audio.
>>>> (I am running jackd by the way).
>>>> I check with qjackctl whether there were any
>>>> ports which I missed to connect...nothing.
>>>
>>> If jackd is to do with alsa, then it could be the following.
>>>
>>> Mozilla went pulse all the way:
>>>  Require PulseAudio on Linux
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1247056
>>> See also:
>>> Firefox nightly requires Pulse Audio
>>> http://forums.debian.net/viewtopic.php?f=20=130028
>>>
>>>> Hmmm...
>>>>
>>>> Is there any fix for that?
>>> Not familiar with jackd. But as far as alsa (which I stick to, like
>>> other discontented users), I don't have sound since months ago.  The
>>> only way to get it would be to compile alsa myself, I'm afraid. 
>>>
>>> Regards!
>>> -- 
>>> Miroslav Rovis
>>> Zagreb, Croatia
>>> http://www.CroatiaFidelis.hr
>>
>> Hi Miroslav,
>>
>> THANKS A LOT ! :)
> You may not thank me, if you read my view, and even remotely agree:
> http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg31926.html
> ( and that is what I regret not having told you... I regret it because
> you now may remain with that pulse spyware.. 
> 
> However, pls. note that in my first message to you I just said what the
> reason was. I did not recommend pulse to you... )
> 
>> ...got it working...somehow...
>>
>> I installed pulseaudio and used pactl to set the default sink
>> and source to the one soundcard (onboard), which is connected
>> to my loudspeakers.
>>
>> Drawback: Setting the volume seems only to be tweakable via
>> the volume slider of the HTML5 player in Firefox...and my alsa
>> volume "app" of my taskbar doesn't work anymore.
>>
>> Hopefully the rest of my sound stuff still works
>>
> 
> And now the question/query/my-asking-for-advice.
> 
> In that thred on alsa-user archive that I linked to, I got this link:
> 
> [linuxaudio.org] html5 in ff through jack
> http://lists.linuxaudio.org/pipermail/linux-audio-user/2016-June/thread.html#105188
> 
> I'm gasping for free time to do various things, fixing audio in ff is
> not of higest priority... Can not dedicate hours to this...
> 
> Anyone has a link for easy fixing of audio in Firefox the sans-pulse
> way (and other poetterware excluded as well, of course)? With clear easy
> steps, maybe?
> 
> Thanks in advance!
> 
Generally if you run into this problem, it's one of two things:

1. `alsamixer` hasn't been used to unmute the levels. After configuring
it, be sure to run 'alsactl store' as root and make sure the 'alsasound'
service is in the default run-level (`rc-update add alsasound default`
as root), or...
2. Try adding these to your user's ~/.asoundrc file:

defaults.ctl.card x;
defaults.pcm.card x;

Replace 'x' with the numeric index of your card (which you can view in
alsamixer using F6). If the order of your cards changes on boot, you'll
need to tell the module controlling your sound (snd_hda_intel is common)
to set its index in a file like /etc/modprobe.d/alsa-base.conf, with
lines like `options snd_hda_intel index=1` or something similar.

Others have done a far better job explaining this than me. Our own guide
on our wiki [0] and Arch's wiki [1] should be adequate to get you going
fairly quickly. Just Ctrl+F "default" to find what you need. Assuming
you don't have exotic hardware, this can be fixed in 15 minutes or less.

Hope this helps.

[0]: https://wiki.gentoo.org/wiki/ALSA#Configuration
[1]:
https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture#Set_the_default_sound_card
-- 
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-user] showing files in numerical order

[Daniel Campbell]

On 10/29/2016 04:59 AM, Emanuele Rusconi wrote:
> Have a look at renamexm from sys-apps/rename (it's actually called
> rename
> but for Gentoo is was renamed to avoid a collision). It has a lot more
> options than rename and defaults to prompting you if you try to
> rename to
> an existing file.
> 
> 
> I use vidir from sys-apps/moreutils.
> All the power of vim (or whatever you set in $VISUAL) and no need to
> pray that your incantation is correct: you edit the file list as a text,
> and when you're satisfied, save and exit.
> 
> -- Emanuele Rusconi
> 
I second the vidir recommendation. I can't tell you how many times it's
made batch renaming easy, powerful, and intuitive for me.

-- 
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-user] Possible heads up: Digest verification failed

[Daniel Campbell]

On 10/29/2016 03:11 AM, Rich Freeman wrote:
> On Sat, Oct 29, 2016 at 5:42 AM, Neil Bothwick <n...@digimed.co.uk> wrote:
>> On Fri, 28 Oct 2016 23:53:03 -0700, Daniel Campbell wrote:
>>
>>>> Anyone seeing this again? I've just sync'd to two servers in
>>>> Australia, and then, for the hell of it, one in Canada and am getting
>>>> it for:
>>>>
>>>> dev-libs/botan
>>>> app-arch/tar
>>>> media-video/libav
>>>> app-crypt/qca
>>>> net-print/cups-filters
>>>>
>>>> I suppose time will sort it out.
>>>>
>>>> Andrew
>>>>
>>> This shouldn't happen unless the distfiles aren't found, or someone (a
>>> dev) didn't use repoman to commit, leaving an old Manifest around.
>>
>> It looks like repoman is the culprit
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=598376
>>
> 
> This is probably not the issue here, since Gentoo uses thin manifests
> (there is nothing for repoman to update).  The manifests that are
> causing the problem aren't created by regular Gentoo developers.
> They're created by a script that runs as a part of the rsync mirror
> process.
> 
> This is a fairly well-known problem that has been around for over a year.
> 
> You will only run into this problem if you use rsync to update your
> repository, since the problem is created when creating the master
> rsync mirror.  The original git repository doesn't contain the error,
> and the git mirror on github doesn't mess with the Manifests.
> 
> The issue apparently has to do with Changelog generation.  In April
> the Council gave Infra the option to stop generating Changelogs, which
> would eliminate the problem.  I suspect those maintaining the scripts
> prefer to keep them around, and I don't think anybody on the Council
> has access to change the scripts.
> 
> I switched to git syncing eons ago, so I've never seen this bug.  I
> recognize it has been a source of frustration for a lot of users, and
> a bit of frustration for the Council, since there doesn't seem to be a
> lot we can do to change it in practice.
> 
> zlg is of course right that these kinds of problems can also be caused
> by maintainer failure to use repoman/etc or if an upstream distfile
> changes.  If that is the problem then you'll see it no matter how you
> sync your repo.  However, when you get a bunch of these after syncing
> it is almost always a result of the mirror creation process.  I can't
> remember the last time I saw a manifest error (granted, I'm also using
> mgorny's stable mirror branch, which I think screens for these kinds
> of errors).
> 
> While there can be some latency I do in general recommend syncing from
> https://github.com/gentoo-mirror/gentoo .  This is a mirror of the
> Gentoo developer git repository with two changes:
> 1.  Metadata is added to the mirror, which greatly speeds things up
> compared to using the raw git repository (you can do this yourself, it
> is one of the steps done by the rsync generation process as well, but
> this one is not buggy).
> 2.  The default stable branch of this mirror screens for numerous
> issues before accepting commits.  That means it is generally a little
> behind the main branch (at this moment the main branch is 2 minutes
> old, and the default stable branch is 20min old), but a lot of the
> really annoying issues that are caused by devs skipping repoman won't
> be seen.   Now, if a maintainer breaks a package then this mirror will
> quickly get out of date until the problem is corrected, but Gentoo QA
> gets warnings when this is happening and usually the maintainer is
> being pestered or somebody else is fixing it.  I suspect this process
> has probably reduced the error rate for everybody.  I have seen this
> get a few days old though, which is something to keep in mind.
> 
> It does not contain Changelogs, though if you use it you'll have a
> full history so you can just run git whatchanged  to get
> something pretty close to a changelog.
> 
> To use it just put this in /etc/portage/repos.conf/gentoo.conf:
> [DEFAULT]
> main-repo = gentoo
> 
> [gentoo]
> location = /usr/portage
> sync-type = git
> sync-uri = https://github.com/gentoo-mirror/gentoo.git
> auto-sync = yes
> 
> If you want to git-sync from some other mirror, just change the url 
> accordingly.
> 
> If you switch your mirror I suggest just renaming /usr/portage and
> letting portage re-create it.
> 
> The other big benefit of git syncing is that if you sync every day it
> is a lot faster.  If you sync less often it will become slower
> compared to rsync.  git is much more efficient at f

Re: [gentoo-user] Possible heads up: Digest verification failed

[Daniel Campbell]

On 10/28/2016 09:56 PM, Andrew Lowe wrote:
> Hi all,
> Anyone seeing this again? I've just sync'd to two servers in
> Australia, and then, for the hell of it, one in Canada and am getting it
> for:
> 
> dev-libs/botan
> app-arch/tar
> media-video/libav
> app-crypt/qca
> net-print/cups-filters
> 
> I suppose time will sort it out.
> 
> Andrew
> 
This shouldn't happen unless the distfiles aren't found, or someone (a
dev) didn't use repoman to commit, leaving an old Manifest around.

Which servers in question? Have you popped in IRC to ask about it? I'm
not involved with our mirrors, and I sync directly from git, so I can't
really help on that front, but it seems to me that it's a simple
oversight that is sure to be fixed once someone knows about it.

-- 
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

[gentoo-user] Small computing recommendations?

[Daniel Campbell]

My birthday's coming up in 10 days and my SO and others are wanting to
know what to get me for my birthday. I'm slowly growing tired of trying
to keep my desktop Gentoo machine lightweight and "clean", so it'd be
fun to hack on a little computer that I could possibly DIY a case or
other arrangement for. Maybe a file/web server, or a "freetoo" machine
where I can experiment with being rigidly FSF-APPROVED or other fun
shenanigans.

I've looked around at the Raspberry Pi 3, the Pocket CHIP (I also have
PICO-8 and am hacking something for it), the Pi Zero, and have heard
about the Beaglebone and Arduino, though isn't the latter meant for more
interactive or robotic thing due to the large array of IO pins?

If I had the right tools or gadgets, creating my own UMPC would be
really fun.

At a minimum, I would prefer HDMI instead of composite or VGA, though it
could be headless and I just use SSH or an Adafruit LCD.

Any opinions or use cases and stories would be much appreciated. I would
prefer running Gentoo on it, but Debian, Mint, or Slackware would be
tolerable.
-- 
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-user] Skype users

[Daniel Campbell]

On 10/04/2016 02:12 PM, Raymond Jennings wrote:
> Please be advised that skype has been split off into two packages
> 
> * skype remains for the "classic" version of skype
> * skypeforlinux is the new package name for microsoft's alpha version
> 
> There were some version number snarls and it was decided that a split
> would be cleaner.
> 
> Blame microsoft for giving their current version a lower number than the
> classic one.
Thanks for the heads-up. I saw it in a recent additions/removal email
and checked eix but didn't see anything pointing out differences.

Does MS have plans to force classic Skype to be obsolete? I hope not...
-- 
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-user] Infrastructure?

[Daniel Campbell]

On 09/19/2016 10:54 AM, Raymond Jennings wrote:
> Just curious, but how are gentoo's infra assets organized?
> 
> Do you guys use VMs on top of hardware machines and whatnot?
> 
> Reasons for asking:
> 
> * general curiosity
> * wondering how a migration to use anongit.gentoo.org
> <http://anongit.gentoo.org> instead of github would go, particularly if
> it would help ease pressure on the rsync servers if demand went down
> - I heard something about a social contract where relying on third
> parties was a frowny point.
> 

Popping in to #gentoo-infra and chatting with the folks there may get
you a faster response.

As far as I know, we accept pull requests from the GitHub mirror *or* a
standard `git format-patch` e-mail.

We do have a social contract[1] which indicates that we will not depend
on proprietary software. That said, the GitHub mirror is there for
convenience; I'm betting part of why we use it on the side is because it
already meshes well with Git to begin with and can be a good 'gateway'
for new contributors.

We also accept patches on the gentoo-dev ML or (depending on the
developer) personal e-mails or Bugzilla bugs. You might want to check
out a few pages on the wiki regarding how we handle contributions, or
pop in #gentoo-proxy-maint on Freenode.

[1] https://gentoo.org/get-started/philosophy/social-contract.html
-- 
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-user] removal of bopm before hopm is in tree

[Daniel Campbell]

On 08/25/2016 07:29 PM, Raymond Jennings wrote:
> I still use bopm, and it built fine last time I emerged it.
> 
> If hopm isn't in the tree yet, why was bopm still pmasked for removal?
> 
> Reason for asking is I'm curious about removal procedures.  I was under
> the impression that replacement packages get added to the tree before
> their obsolete predecessors get pmasked for booting out.
> 
> And if that's not the case, should it be?
That's a good question, best answered by the developer who chose to have
the package removed.

-- 
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-user] Keep alive within SSH session

[Daniel Campbell]

On 07/17/2016 11:03 AM, lukash wrote:
> On Sun, 2016-07-17 at 18:47 +0100, Mick wrote:
>> On Sunday 17 Jul 2016 14:14:42 you wrote:
>>> On Sun, 17 Jul 2016 17:35:55 +0100
>>> Mick wrote -
>>>
>>>> On Sunday 17 Jul 2016 16:20:30 Ralf wrote:
>>>>> On 07/17/2016 04:02 PM, Mick wrote:
>>>>>> I am not sure of the correct approach to achieve a prolonged
>>>>>> remote=
>>>>>>
>>>>>> debugging session through SSH and avoid the SSH session
>>>>>> timing out.=
>>>
>>> What you need is expect or Expect or pexpect depending on your base
>>> scripting language preference - tcl, perl, or python.
>>>
>>> Dave F
>>
>> Thank you Dave!  I'm emerging dev-tcltk/expect as I type
>> this.  Hopefully the 
>> learning curve won't be too steep.  ;-)
> 
> You may also wanna try the ServerAliveInterval option in your client's
> ssh config. It sends some keepalive data to the server every X seconds,
> sounds like what you need.
> 
Please let me know if you have any issues. I'm not an expert in Tcl (or
expect), but I help maintain the package and it's recently had bugs that
I attempted to fix, so let me know how it works out if you decide to go
that way.
-- 
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-user] Call for opinions and/or use cases regarding games.eclass

[Daniel Campbell]

On 07/01/2016 12:34 PM, Terry Z. wrote:
> On Fri, Jul 1, 2016 at 4:27 AM, Daniel Campbell <z...@gentoo.org
> <mailto:z...@gentoo.org>> wrote:
> 
> Most of us know about the games.eclass history. Let's put that aside;
> I'm looking for user consensus on packages that use(d) games.eclass.
> 
> 1. Do you take advantage of games.eclass features, including restricting
> game access to a given group and installing games outside of /usr and/or
> on different media?
> 
> 
> I like the game group feature.  On a multiuser system it makes it fairly
> simplistic to ensure access goes to whom I want to have access to those
> games.  It also behaves similarly to other services which allow non root
> users to run things based on their group membership.
> 
> I do not really care much about the ability to install outside of /usr,
> but I can see that being very useful.  Of course, a symlink can provide
> this same feature.

Could you share a little more about your use case? You mentioned
multi-user and restricting based on group membership. Do you have
children that you don't want playing specific games, is this a work
environment?

The more information, the merrier. With the removal of games.eclass,
this case is going away, so if I or others can learn more about your use
case, we might be able to help you figure out how to better meet that
use case, or begin drafting features and/or documentation to make this
possible again.

> 2. If yes, how do you feel about the removal of the eclass? Did you rely
> on its functionality? Does your use case require it?
> 
> 
> I have very few personal ebuilds that take advantage of much of the
> features other than the group reqs etc.  Still, I see the value in them.
>  
Which features are your personal ebuilds using? Could you supply a
snippet or even a paste somewhere that shows what you're doing?

> 3. If yes, _what is your use case_? Which features are important to your
> use case wrt games and what can Gentoo do to improve that.
> 
> 
> I make use of the games group in my personal ebuilds.  I find some of
> the other features provided in games.eclass potentially useful, but do
> not make immediate needs of them.
>  
> 
> We cannot make concrete decisions without concrete evidence, so please
> answer and speak for your use case. This will serve as a public record
> of interest, and might even inspire a few people. :)
> 
> Thanks for your time,
> 
> ~zlg
> --
> Daniel Campbell - Gentoo Developer
> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net <http://keys.gnupg.net>
> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
> -- 
> The irony is that Bill Gates claims to be making a stable operating
> system and Linus Torvalds claims to be trying to take over the world.
> -- seen on the net

Thanks again for supplying information to help form an accurate view of
things.


-- 
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

[gentoo-user] Call for opinions and/or use cases regarding games.eclass

[Daniel Campbell]

Most of us know about the games.eclass history. Let's put that aside;
I'm looking for user consensus on packages that use(d) games.eclass.

1. Do you take advantage of games.eclass features, including restricting
game access to a given group and installing games outside of /usr and/or
on different media?

2. If yes, how do you feel about the removal of the eclass? Did you rely
on its functionality? Does your use case require it?

3. If yes, _what is your use case_? Which features are important to your
use case wrt games and what can Gentoo do to improve that?

We cannot make concrete decisions without concrete evidence, so please
answer and speak for your use case. This will serve as a public record
of interest, and might even inspire a few people. :)

Thanks for your time,

~zlg
-- 
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-user] Re: Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/21/2014 07:24 AM, Tanstaafl wrote:
 On 2014-02-20 9:39 PM, Daniel Campbell li...@sporkbox.us wrote:
 Indeed, Greg doesn't work for Red Hat. Prior to working for LF, however,
 he worked for Novell, another for-profit Linux company.
 
 Good god, is that the best you can do?
 
 What is your aversion to 'profit', anyway? You do realize that
 *everyone* operates under the profit motive, right? EVERYONE. All day.
 Every day, in everything that they do. It may not always be a
 *financial* profit motive, but in many or even most cases it ultimately is.
 

This discussion has nothing to do with me.

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/21/2014 07:43 AM, Tanstaafl wrote:
 On 2014-02-21 8:34 AM, Daniel Campbell li...@sporkbox.us wrote:
 On 02/21/2014 07:24 AM, Tanstaafl wrote:
 On 2014-02-20 9:39 PM, Daniel Campbell li...@sporkbox.us wrote:
 Indeed, Greg doesn't work for Red Hat. Prior to working for LF,
 however,
 he worked for Novell, another for-profit Linux company.
 
 Good god, is that the best you can do?

 What is your aversion to 'profit', anyway? You do realize that
 *everyone* operates under the profit motive, right? EVERYONE. All day.
 Every day, in everything that they do. It may not always be a
 *financial* profit motive, but in many or even most cases it
 ultimately is.
 
 This discussion has nothing to do with me.
 
 So stop making comments in this thread.
 
 Or are you suggesting that I mis-attributed that post (I just
 dbl-checked and I didn't)?
 

I certainly wrote what you quoted, but I'm not taking the bait to
devolve this already heated discussion into personal attacks.

If you think all profit is the same, then we are talking on two
different wavelengths.

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/15/2014 08:09 PM, walt wrote:
 On 02/15/2014 12:30 PM, Daniel Campbell wrote:
 The social
 tactics at work from the systemd team (and verily, other Red Hat
 projects like GNOME) are reminiscent of Microsoft through the use of the
 Embrace, Extend, Extinguish methodology.
 
 I certainly share your hostility towards M$ for suppressing competition.
 
 Red Hat, like M$, is a for-profit corporation, so I share your suspicion
 that they want to suppress their competitors (though I don't know who
 their competitors are).
 
 But comparing a completely closed-source shop like M$ to any open source
 company leaves me feeling uneasy.  I can't find the exact argument to
 explain my unease, but I'm hoping someone else will jump in with a more
 rational argument.
  
 
 

I think I understand where you're coming from. How can they compare
when Red Hat releases their source under a liberating license while MS
locks it down behind closed doors?

That's missing the point, though. In the FOSS world, that's the bait,
so to speak. The wolf in sheep's clothing. Red Hat can release (or hack
on) a bunch of attractive software or features, get people interested
(so interested that, say, the majority of distros depend on it *wink
wink*), and then use that influence to indirectly control where FOSS
moves. By striking the weakest part of the stack (sysv probably *did*
need a good replacement, but not one as ambitious as systemd) and
digging down into the kernel level (kdbus), Red Hat devs will now have a
very influential role in the FOSS world. This will in turn generate
interest (and thus profit) in Red Hat.

It's marginally clever, but so clearly obvious at the same time. It's
sad (to me) that the community didn't see it coming. Those who did have
been written off as conspiracy theorists or FUDders. Time will reveal all.

~Daniel

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/20/2014 07:42 PM, Canek Peláez Valdés wrote:
 On Thu, Feb 20, 2014 at 6:08 PM, Daniel Campbell li...@sporkbox.us wrote:
 On 02/15/2014 08:09 PM, walt wrote:
 On 02/15/2014 12:30 PM, Daniel Campbell wrote:
 The social
 tactics at work from the systemd team (and verily, other Red Hat
 projects like GNOME) are reminiscent of Microsoft through the use of the
 Embrace, Extend, Extinguish methodology.

 I certainly share your hostility towards M$ for suppressing competition.

 Red Hat, like M$, is a for-profit corporation, so I share your suspicion
 that they want to suppress their competitors (though I don't know who
 their competitors are).

 But comparing a completely closed-source shop like M$ to any open source
 company leaves me feeling uneasy.  I can't find the exact argument to
 explain my unease, but I'm hoping someone else will jump in with a more
 rational argument.

 I think I understand where you're coming from. How can they compare
 when Red Hat releases their source under a liberating license while MS
 locks it down behind closed doors?

 That's missing the point, though.
 
 No, it's not.
 
 In the FOSS world, that's the bait,
 so to speak. The wolf in sheep's clothing. Red Hat can release (or hack
 on) a bunch of attractive software or features, get people interested
 (so interested that, say, the majority of distros depend on it *wink
 wink*), and then use that influence to indirectly control where FOSS
 moves. By striking the weakest part of the stack (sysv probably *did*
 need a good replacement, but not one as ambitious as systemd) and
 digging down into the kernel level (kdbus), Red Hat devs will now have a
 very influential role in the FOSS world. This will in turn generate
 interest (and thus profit) in Red Hat.
 
 First of all, you do realize that Greg Kroah-Hartman, the primary
 author of kdbus, works for the Linux Foundation, right? Not RedHat.
 
 Second, good for RedHat if they can turn a profit. Meanwhile the code
 from the whole stack is free, and anyone willing and able can fork it
 and use, enhance, or replace any part of it. And yes, I said replace.
 
 So, again, the comparison makes no sense at all.
 
 It's marginally clever, but so clearly obvious at the same time. It's
 sad (to me) that the community didn't see it coming.
 
 So you are saying we are idiots? Or just naive? Or both? And *all* of
 us who use systemd and think is a great idea?
 
 Damn, if only we had knew. Too bad you didn't come before to open our
 eyes to this undeniable truth. Now it's too late, the sky is falling
 and the world will end on fire and brim.
 
 Those who did have
 been written off as conspiracy theorists or FUDders. Time will reveal all.
 
 Indeed it will. Wanna bet a beer?
 
 Regards.
 

Indeed, Greg doesn't work for Red Hat. Prior to working for LF, however,
he worked for Novell, another for-profit Linux company. Moot point.
Businesses tend to do favors for other businesses. What makes you think
Red Hat hasn't given LF some money at some point? Further, isn't Lennart
friends with Greg? Isn't that how he got udev into systemd, since Greg
maintained udev before it was merged into systemd? Tell the full story
if you're going to bring it up.

I will refrain from stooping to the level of petty insults... but yes,
collectively the FOSS community at large has *terrible* social awareness
within its own ecosystem and would not see an agenda coming until it was
too late and they had to fork or rebuild. It has nothing to do with me;
it has everything to do with foresight. And the FOSS world is lacking in
that. Those that have it are outnumbered by those who get distracted by
shiny objects and if they care about the future of FOSS, it's only in a
superficial sense.

FOSS is not just code, it's culture too.

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/20/2014 08:53 PM, Canek Peláez Valdés wrote:
 On Thu, Feb 20, 2014 at 8:39 PM, Daniel Campbell li...@sporkbox.us wrote:
 On 02/20/2014 07:42 PM, Canek Peláez Valdés wrote:
 On Thu, Feb 20, 2014 at 6:08 PM, Daniel Campbell li...@sporkbox.us wrote:
 On 02/15/2014 08:09 PM, walt wrote:
 On 02/15/2014 12:30 PM, Daniel Campbell wrote:
 The social
 tactics at work from the systemd team (and verily, other Red Hat
 projects like GNOME) are reminiscent of Microsoft through the use of the
 Embrace, Extend, Extinguish methodology.

 I certainly share your hostility towards M$ for suppressing competition.

 Red Hat, like M$, is a for-profit corporation, so I share your suspicion
 that they want to suppress their competitors (though I don't know who
 their competitors are).

 But comparing a completely closed-source shop like M$ to any open source
 company leaves me feeling uneasy.  I can't find the exact argument to
 explain my unease, but I'm hoping someone else will jump in with a more
 rational argument.

 I think I understand where you're coming from. How can they compare
 when Red Hat releases their source under a liberating license while MS
 locks it down behind closed doors?

 That's missing the point, though.

 No, it's not.

 In the FOSS world, that's the bait,
 so to speak. The wolf in sheep's clothing. Red Hat can release (or hack
 on) a bunch of attractive software or features, get people interested
 (so interested that, say, the majority of distros depend on it *wink
 wink*), and then use that influence to indirectly control where FOSS
 moves. By striking the weakest part of the stack (sysv probably *did*
 need a good replacement, but not one as ambitious as systemd) and
 digging down into the kernel level (kdbus), Red Hat devs will now have a
 very influential role in the FOSS world. This will in turn generate
 interest (and thus profit) in Red Hat.

 First of all, you do realize that Greg Kroah-Hartman, the primary
 author of kdbus, works for the Linux Foundation, right? Not RedHat.

 Second, good for RedHat if they can turn a profit. Meanwhile the code
 from the whole stack is free, and anyone willing and able can fork it
 and use, enhance, or replace any part of it. And yes, I said replace.

 So, again, the comparison makes no sense at all.

 It's marginally clever, but so clearly obvious at the same time. It's
 sad (to me) that the community didn't see it coming.

 So you are saying we are idiots? Or just naive? Or both? And *all* of
 us who use systemd and think is a great idea?

 Damn, if only we had knew. Too bad you didn't come before to open our
 eyes to this undeniable truth. Now it's too late, the sky is falling
 and the world will end on fire and brim.

 Those who did have
 been written off as conspiracy theorists or FUDders. Time will reveal all.

 Indeed it will. Wanna bet a beer?

 Regards.


 Indeed, Greg doesn't work for Red Hat. Prior to working for LF, however,
 he worked for Novell, another for-profit Linux company. Moot point.
 Businesses tend to do favors for other businesses. What makes you think
 Red Hat hasn't given LF some money at some point? Further, isn't Lennart
 friends with Greg? Isn't that how he got udev into systemd, since Greg
 maintained udev before it was merged into systemd? Tell the full story
 if you're going to bring it up.
 
 So, now it's RedHat, Novell and the Linux Foundation. Anyone else? The
 NSA? The CIA? The Cobra Commander?
 
 The Cobra Commander is always involved.
 
 I will refrain from stooping to the level of petty insults... but yes,
 collectively the FOSS community at large has *terrible* social awareness
 within its own ecosystem and would not see an agenda coming until it was
 too late and they had to fork or rebuild. It has nothing to do with me;
 it has everything to do with foresight. And the FOSS world is lacking in
 that. Those that have it are outnumbered by those who get distracted by
 shiny objects and if they care about the future of FOSS, it's only in a
 superficial sense.
 
 Gee, if I though that about our community, then I would not want to be
 part of it.
 
 Good think I don't think like you.
 
 FOSS is not just code, it's culture too.
 
 Exactly, and it seems you miss the whole point about the FOSS culture too.
 
 I will not answer any more of your mails until you present some actual
 evidence about this big bad group of people under the guidance of
 shady corporations trying to take advantage of the poor, stupid,
 social inept FOSS community.
 
 I do not care about hearsay. I care about facts, and technological
 arguments. If you do not have any of those, I'm done with you in this
 thread.
 
 Regards.
 

Firstly, you don't control whether or not I send an e-mail. The high
horse is completely unnecessary. This particular thread (from walt) had
nothing to do with you directly, so I don't know why you're getting so
upset. You're free to hit the Delete button in your e-mail client or
add me to your spam filter.

I said nothing

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/19/2014 03:02 AM, Neil Bothwick wrote:
 On Wed, 19 Feb 2014 01:04:14 -0600, Daniel Campbell wrote:
 
 Or to create a non-systemd profile :)
 
 For such a profile to be legitimate, systemd would have to be
 chosen as the default.
 
 Quite the opposite, to have a separate systemd profile would mean
 that systemd was not the default, otherwise it would be in the
 default profile. Not that defaults really matter with Gentoo, you
 have a systemd profile and an openrc profile, who gives a toss
 which is default when you have a simple to make choice?
 
 Gentoo is one of the last bastions of choice available to 
 GNU/Linux users and it would create a complete shitstorm if
 systemd were pushed on Gentoo's users.
 
 How is putting systemd setting in a profile that a user has to 
 consciously choose to use forcing anything on anyone? Profiles are
 the essence of choice but it appears you only want the choices you
 approve of to be available.
 
 

Perhaps I didn't phrase it correctly. Logically, a non systemd
profile would necessitate either a systemd profile, or require the
default to already ship systemd. I hadn't considered the prior
existence of systemd profiles, which we currently have, so afaict the
issue is mostly moot.

Choices are great until the existence of other choices infringes on
mine. Profiles prevent that, so I have no problem with systemd
profiles. The problem lies with evangelists who aren't happy with
systemd being *a* choice. They want systemd to be *the* choice, *the*
default. That is what I take issue with.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTBIi7AAoJEJUrb08JgYgHducH/2VLDbRimgiZ1rM404CjIDwy
nl5dCdNcu6XtXt/q5zxY9zVUyYQtGCZmZxT1s41xT0NpYlMv2mo++tASuZwI5tye
1bzjzd9wGPwYwqTgrWgfusH170zWURaTKXwvTAgzZowKR++MXr918HtDiHzIJtpR
QjSBvMHK3TXFe1dSQKwHFYqJ/uhx1sGTsKh7tDGdUIknXB0oaVSvuzZAlzy+2GMV
g4x189EVO46kuOSXkBWobFGVwbYSttADg97Wgol55NZiyKPGaqioHKJoLeUYVlCt
NR4L76APyUHXBqdfk+/9clPHOg3x7XJuo/cjluTjC2yDvezWpojEUJKgNAZ0fZ8=
=jg5F
-END PGP SIGNATURE-

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/19/2014 04:50 AM, Neil Bothwick wrote:
 On Wed, 19 Feb 2014 04:34:35 -0600, Daniel Campbell wrote:
 
 How is putting systemd setting in a profile that a user has to
  consciously choose to use forcing anything on anyone? Profiles
 are the essence of choice but it appears you only want the
 choices you approve of to be available.
 
 Perhaps I didn't phrase it correctly. Logically, a non systemd 
 profile would necessitate either a systemd profile, or require
 the default to already ship systemd. I hadn't considered the
 prior existence of systemd profiles, which we currently have, so
 afaict the issue is mostly moot.
 
 We already have non-systemd profiles. Until recently that is all we
 had.
 
 Choices are great until the existence of other choices infringes
 on mine. Profiles prevent that, so I have no problem with
 systemd profiles. The problem lies with evangelists who aren't
 happy with systemd being *a* choice. They want systemd to be
 *the* choice, *the* default. That is what I take issue with.
 
 Why are you so concerned about the default, not that anyone in
 this thread has suggested making systemd the default, not even
 Canek? If you cannot use eselect profile set, Gentoo is not for you
 anyway? The handbook tells you to select a profile quite early in
 the installation, there is no default - portage complain loudly if
 you haven't chosen a profile, so I fail to see how anyone can force
 systemd (or openrc for that matter) on users when the choice must
 be made.
 
 There are technical arguments for and against systemd, which is why
 this thread was started, rhetoric about forcing default profiles on
 people when there is no such thing as a default profile only serve
 to cloud the real issues.
 
 

Ah. It's been a while since I installed Gentoo; I wasn't aware that
portage would yell at you for not choosing a profile, or that one
wasn't already set. In that case there's nothing for me to say wrt
defaults.

Insistence upon technical-only discussion is a bit dishonest imo, as
free software is more than code. Without the social practices,
community, etc, there wouldn't be free software. So I think
non-technical concerns can be relevant to discussions on a project,
especially ambitious ones that seek to greatly change the ecosystem.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTBI1QAAoJEJUrb08JgYgHLbwIAI9sg65uA330dpWdoZHua81q
CGnoHzmClRdToNeYI40UKt7uT4rlebVvV2/A4DCcOb/qOPy7V1yNX8Etdsk/PHGi
5fhmqIgG/pU7lLeBI1FVMJmGaPZOju/g23Ney1AknoAdSH6r3F1S4k7d95C3CgWs
VDlZpsB/q5e8bTIVfFSQZ4vj9I4cKz+ZNzDsD2oGepDGtH+66OPjF1MUBhBao/+c
rFrZcdaWOpTc0Soj6I+bdffijKldyOflzRkINo6mBaWWOlEh34A10rGDDcOnkT6L
0ioUBn+5C9/AIDbBX8uplaaT4nG0QWPg/gi/WH6swLme5X9kSUVeTYJMCqRFBkk=
=mK4M
-END PGP SIGNATURE-

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/18/2014 12:14 PM, Canek Peláez Valdés wrote:
 On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko birc...@gmail.com wrote:
 On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote:
 Yet again, I respect ones right to use whatever one wants, but I ask
 to respect mine as well. That's why I propose a separate systemd
 profile for those willing to use it.

 Then write. Just be aware that to write a systemd profile, you need to
 use systemd.

 Or to create a non-systemd profile :)
 
 That's the best response I've read in, like, many years. That's
 perfect; I'm 100% behind it. I even volunteer to help (with testing)
 to anyone going for this.
 
 You guys create a systemd-sucks-we-dont-want-it profile, and I promise
 to give you guys a hand.
 
 Make a profile that frees users from using systemd, and I think even
 several Gentoo developers will get behind that.
 
 Now we are talking; this has been my whole point the whole time.
 Everybody that don't want to use systemd; help this idea, and if there
 are enough of you, you'll pulled through.
 
 Regards.
 

For such a profile to be legitimate, systemd would have to be chosen as
the default. Gentoo is one of the last bastions of choice available to
GNU/Linux users and it would create a complete shitstorm if systemd were
pushed on Gentoo's users. You're just trying to push systemd on one of
the few distros that doesn't use it by default. Do you hang out with
John Paul Adrian Glaubitz? He's a Debian developer who has a
long-running history of pushing systemd as well. There is nothing wrong
with systemd as a choice, but to push it as the default is ridiculous.
systemd can have its own profile while the rest of the world goes on
without it. Everybody wins.

For all this talk about technical details, nobody seems to notice the
marketing that's going on and frankly it disgusts me.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/17/2014 06:17 AM, Tanstaafl wrote:
 Thanks to all who chimed in...
 
 On 2014-02-16 3:27 PM, Canek Peláez Valdés can...@gmail.com wrote:
 On Sun, Feb 16, 2014 at 1:26 PM, Mick michaelkintz...@gmail.com wrote:
 [snip]
 You may have lost it in the link that Volker posted (thanks Volker),
 but this
 comment from HaakonKL probably sums it up:

 ... I will give Upstart this though: Should something better come
 along, you
 could replace upstart. I guess this holds true for OpenRC as well.

 You can't say that about systemd.
 
 I had read that blog entry before. Is full of errors, like believing
 that everything that systemd does is inside PID 1.
 
 Maybe it is 'full of errors', but is the primary point true?
 
 There is actually little code inside PID 1;
 
 The quoted text said nothing about this, so please stay on point.
 
 As to the point raised:
 
 Can you surgically remove systemd in the future without reverse
 engineering
 half of what the LSB would look at the time, or will its developers
 ensure
 that this is a one time choice only?
 
 You guys talk about software like if it was a big bad black magical
 box with inexplicable powers.

 If someone is willing and able, *everything* can be surgically
 remove[d]. We got rid of devfs, remember? We got rid of OSS (thank
 the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo,
 and ESD. KDE got rid of aRts (and who knows what more).
 
 I think you are being a little disingenuous here.
 
 The obvious unspoken meaning behind the 'can you surgically remove' was:
 
 Can you do it *easily*? I'm sure you would not suggest that getting rid
 of the above were 'easy'?
 
 It simply doesn't matter if systemd boils down to one monolithic binary,
 or 600, if they are tied together in such a way that they can not
 *individually* be replaced *easily and simply* (ie, without having to
 rewrite the whole of systemd).
 
 That said, it seems to me that, for now at least, it isn't that big a
 deal to switch back and forth between systemd and, for example, OpenRC.
 
 So my main concern is - will it still be possible - *and* easy - in a
 year? Three years? Five? If the answer to *any* of those is no, then I
 think the best solution - for gentoo at least - is to make whether or
 not systemd is to be used more like a *profile* choice - a decision that
 you can make at install time, similar to choosing between hardened or
 not (not easy/simple to switch to/from after a system is up and running).
 
 In fact, it seems to me that, since (from what I've read) the primary
 reason that systemd was written in the first place was to provide
 extremely fast boots *in virtualized environments*, having it be a
 choice made by selecting a corresponding *profile* is the *ideal*
 solution - at least for gentoo. At least this way everything could be
 documented, and switching between a systemd and non-systemd profile can
 be supported for as long as possible, understanding that at some point
 in time it may have to become an install time choice - kind of like
 choosing between hardened or not is mostly an install time choice now.
 

That's actually a really smart idea. It would allow for the integration
that systemd-fans desire and still respect the choice of people that
don't want systemd on their systems. Combined with USE flags and the
PORTDIR_MASK variable (iirc), it should create a best of both worlds
situation for Gentoo and a decision wouldn't need to be made. Despite my
distaste for systemd, I think this is a great middle ground that
everyone could, with some considerations or compromises, agree to.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/15/2014 11:32 AM, Canek Peláez Valdés wrote:
 On Feb 15, 2014 11:02 AM, Tanstaafl tansta...@libertytrek.org
 mailto:tansta...@libertytrek.org wrote:

 On 2014-02-15 10:16 AM, Tanstaafl tansta...@libertytrek.org
 mailto:tansta...@libertytrek.org wrote:

 Hi all,

 Not to revive a flame-fest against systemd, but...

 I'm sure some or most of you have already heard about this, but I found
 a really decent thread discussing this whole systemd thing. It is only
 really comparing systemd and upstart, as that was the debate going on in
 the debian TC, but it is a great read, and has actually made me rethink
 my blind objections to systemd a bit.


 One of which was logging:

 20. Myth: systemd makes it impossible to run syslog.

 Not true, we carefully made sure when we introduced the journal that
 all data is also passed on to any syslog daemon running. In fact, if
 something changed, then only that syslog gets more complete data now
 than it got before, since we now cover early boot stuff as well as
 STDOUT/STDERR of any system service.

 From: http://0pointer.de/blog/projects/the-biggest-myths.html
 
 Also, for those of you who don't follow Linux-related news, Ubuntu will
 also change to systemd in the future:
 
 http://www.markshuttleworth.com/archives/1316
 
 And I *heard* that Slackware was also discussing the possibility, but
 since I don't follow Slackware at all, I don't know for sure.
 
 Anyway, distros not using systemd, and that they are not really small
 and/or niche, seem to be disappearing. The discussion that Tanstaafl
 posted is interesting since the arguments used by the four TC members
 are really focused on the technical merits of the proposed init systems.
 
 Regards.
 --
 Canek Peláez Valdés
 Posgrado en Ciencia e Ingeniería de la Computación
 Universidad Nacional Autónoma de México
 

The lack of foresight on social and political ramifications is epidemic
to most of the FOSS world, as evidenced by the creeping adoption of
systemd. Things are already depending on things that systemd provides,
and is dividing the ecosystem into systemd vs everything else.
Ambitious projects like systemd are damaging to the rich variety that
should be found in the FOSS ecosystem. systemd in particular encourages
embracing vertical integration and rejection of POSIX and UNIX
principles. Its culture is adversarial to anyone who doubts the Great
Image that Lennart and his employer has. If it were a project that was
humble, without an agenda, and did not undergo evangelism, I'd have no
problems with it because choice is something that I value immensely. But
because it *isn't* humble, *has* an agenda, only reached the adoption it
currently has by *lots* of arguing and pushing, and refuses to coexist
with other init systems, I cannot respect it as a legitimate,
non-aggressive, non-intrusive software project. I consider it a toxic
threat to FOSS and refuse to have it on any system I maintain.

systemd has technical merits (cgroups, socket activation, parellel
execution of daemons, etc), but they fall by the wayside and become
irrelevant to me when it swallows the functionality of multiple projects
that should be separate (see: udev) and tries to be everything to
everyone (splash image, web server, boot time graphs, etc). The social
tactics at work from the systemd team (and verily, other Red Hat
projects like GNOME) are reminiscent of Microsoft through the use of the
Embrace, Extend, Extinguish methodology. With their paid developers
and more abundant resources, Red Hat (and arguably other corporations)
can use their developers to push their agendas and, in a sense,
commandeer control of the FOSS world. I will give them no inch on my
systems. I am skeptical of their involvement in the kernel, as well.

It's sad to see Debian giving into peer pressure. I honestly thought
that they would see the agenda miles away and prevent a monoculture. For
people who are technically intelligent, they're seriously lacking any
foresight in their decisions and are completely blind to the social and
political ramifications. Distros will regret depending on such a project
and it will set GNU/Linux development back many years when systemd
becomes a full stack and working without it is made difficult or
impractical (through the use of lock-in tactics). I hope that Gentoo
continues to be a safe haven for choice and the spirit of FOSS. Without
it, I may have to concede and either start building my own distro, or
going to the BSDs.

Just my two cents. Ignore or reply at your discretion.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/15/2014 02:32 PM, Canek Peláez Valdés wrote:
 On Sat, Feb 15, 2014 at 2:23 PM, Mick michaelkintz...@gmail.com wrote:
 On Saturday 15 Feb 2014 17:32:44 Canek Peláez Valdés wrote:
 On Feb 15, 2014 11:02 AM, Tanstaafl tansta...@libertytrek.org wrote:
 On 2014-02-15 10:16 AM, Tanstaafl tansta...@libertytrek.org wrote:
 Hi all,

 Not to revive a flame-fest against systemd, but...

 I'm sure some or most of you have already heard about this, but I found
 a really decent thread discussing this whole systemd thing. It is only
 really comparing systemd and upstart, as that was the debate going on in
 the debian TC, but it is a great read, and has actually made me rethink
 my blind objections to systemd a bit.

 One of which was logging:

 20. Myth: systemd makes it impossible to run syslog.

 Not true, we carefully made sure when we introduced the journal that all

 data is also passed on to any syslog daemon running. In fact, if something
 changed, then only that syslog gets more complete data now than it got
 before, since we now cover early boot stuff as well as STDOUT/STDERR of any
 system service.

 From: http://0pointer.de/blog/projects/the-biggest-myths.html

 Also, for those of you who don't follow Linux-related news, Ubuntu will
 also change to systemd in the future:

 http://www.markshuttleworth.com/archives/1316

 And I *heard* that Slackware was also discussing the possibility, but since
 I don't follow Slackware at all, I don't know for sure.

 Anyway, distros not using systemd, and that they are not really small
 and/or niche, seem to be disappearing. The discussion that Tanstaafl posted
 is interesting since the arguments used by the four TC members are really
 focused on the technical merits of the proposed init systems.

 There was a thread sometime last year mentioning a slimmer/slicker and 
 obeying
 to the *nix design principles initialisation system, but can't find it at the
 moment.  Isn't that at all in the running?
 
 For Slackware, I have no idea. For Debian, no the only options were[1]:
 
 1. sysvinit (status quo)
 2. systemd
 3. upstart
 4. openrc (experimental)
 5. One system on Linux, something else on non-linux
 6. multiple
 
 It should also be noted that no one in the TC voted OpenRC above
 systemd AND upstart, and that while a couple voted systemd below
 everything else, it can be argued that it was a tactical vote.
 
 Regards.
 
 [1] https://wiki.debian.org/Debate/initsystem/
 

Why didn't they consider runit? It has parallel execution of daemons and
is backwards compatible with sysv. It has a few other mini-features as
well, iirc. I used for a little while before Arch pushed systemd on
their community and it was interesting.

Re: [gentoo-user] going from systemd to udev

[Daniel Campbell]

On 02/04/2014 01:58 PM, Joseph wrote:
 Is it possible to go from systemd to udev?
 
 I don't like the way systemd works.  I have a problem with mounting USB
 sick (it mounts as root:root) and I can not even change the permission.
 I am receiving Hylafax fax transmission reports (email) on all incoming
 faxes and now these emails are empty.
 It all start happening after switching to systemd :-(
 

systemd and udev are part of the same project, so I believe what you
meant was switching from systemd to OpenRC. I've not made such a switch,
but if you remember the steps you took, you can generally just reverse
them. That is, emerge openrc again, change the kernel line in GRUB to
point to regular init instead of systemd's init, reboot, and things
*should* fall into place.

USB drives mounting as root sounds like a udev thing rather than a
systemd thing, and switching to OpenRC for your init won't fix it afaik.
For the devices that you need this behavior for, it might be worth
looking into writing some udev rules. You can get a start by consulting
`lsusb` output and Googling for 'udev rules' to get a wide variety of
guides for writing udev rules. Despite the recent changes to udev by the
systemd team, udev still functions mostly the same and most guides will
be accurate.

I hope this helps!

~Daniel

Re: [gentoo-user] OT: Flash+nspluginwrapper versus Gnash comparisons?

[Daniel Campbell]

On 10/31/2013 10:15 PM, Walter Dnes wrote:
   I'm getting rather annoyed with Firefox.  I don't want to get into
 that flamewar right now.  I'm trying to migrate to UZBL.  The latest git
 version is a lot better than the stale stable version.  The uzbl-
 ebuild is broken (yes, I've filed a bug), so I pull directly from git
 and build and install to ~/.local.  It's a steep learning curve, and
 I've gradually resolved almost every issue.  The last reason to have
 Firefox or Opera hanging around is Flash.  I subscribe to NHL GameCenter
 Live and Live365.com, so Flash functionality is mandatory for me.
 
   The git version of UZBL requires a recent version of webkit, which
 requires gtk3.  Flash is a gtk2 program, so it doesn't work.  I've heard
 that the 2 options are...
 1) Running Flash in nspluginwrapper
 2) Using Gnash to replace Flash
 
   How are people's experiences with the 2 options above?
 

Have you checked to see if the sites you use have an interface for
mplayer or another media player? (Assuming they are streaming services
similar to Youtube) If not, it may be simpler to use nspluginwrapper.
Gnash compatibility can be spotty, but is improving. If you suspect that
the services that you use don't use advanced/recent Flash features, give
gnash a whirl.

The last time I used gnash, it was completely fine for basic streaming
stuff, but marketing sites and tech demos and (some) Newgrounds material
was borked. But that was over 3 years ago; times have certainly changed,
and I'd wager for the better. :)

Good luck.

Re: [gentoo-user] re: resolving blocked packages [media-video/ffmpeg-1.2:0]

[Daniel Campbell]

On 10/27/2013 12:08 PM, Alexander Kapshuk wrote:
 As I ran 'emerge --ask --update --deep --with-bdeps=y --newuse world', I
 got the message below.
 
 These are the packages that would be merged, in order:
 
 Calculating dependencies... done!
 [ebuild  N ] dev-scheme/guile-1.8.8-r1  USE=deprecated nls regex
 threads -debug -debug-freelist -debug-malloc -discouraged -emacs
 -networking
 [ebuild  N ] sys-devel/autogen-5.15
 [ebuild U ~] net-libs/gnutls-3.2.5 [2.12.23-r1] USE=-dane%
 LINGUAS=-cs% -de% -en% -fi% -fr% -it% -ms% -nl% -pl% -sv% -uk% -vi%
 -zh_CN%
 [ebuild  N ] media-libs/libpostproc-0.8.0.20121125  USE=-3dnow
 (-altivec) -mmx -mmxext -pic -static-libs
 [ebuild U ~] media-video/vlc-2.1.0 [2.0.9] USE=-chromaprint% -fdk%
 -opencv% (-qt5) -rdp% {-test%} -vdpau%
 [blocks B  ] media-video/ffmpeg-1.2:0 (media-video/ffmpeg-1.2:0
 is blocking media-video/vlc-2.1.0)
 [blocks B  ] media-video/ffmpeg:0 (media-video/ffmpeg:0 is
 blocking media-libs/libpostproc-0.8.0.20121125)
 [blocks B  ] media-libs/libpostproc (media-libs/libpostproc is
 blocking media-video/ffmpeg-1.0.7)
 
 !!! Multiple package instances within a single package slot have been pulled
 !!! into the dependency graph, resulting in a slot conflict:
 
 net-libs/gnutls:0
 
   (net-libs/gnutls-3.2.5::gentoo, ebuild scheduled for merge) pulled in by
 =net-libs/gnutls-3.0.20:0 required by
 (media-video/vlc-2.1.0::gentoo, ebuild scheduled for merge)
 
   (net-libs/gnutls-2.12.23-r1::gentoo, installed) pulled in by
 (no parents that aren't satisfied by other packages in this slot)
 
 
 It may be possible to solve this problem by using package.mask to
 prevent one of those packages from being selected. However, it is also
 possible that conflicting dependencies exist such that they are
 impossible to satisfy simultaneously.  If such a conflict exists in
 the dependencies of two different packages, then those packages can
 not be installed simultaneously. You may want to try a larger value of
 the --backtrack option, such as --backtrack=30, in order to see if
 that will solve this conflict automatically.
 
 For more information, see MASKED PACKAGES section in the emerge man
 page or refer to the Gentoo Handbook.
 
 
  * Error: The above package list contains packages which cannot be
  * installed at the same time on the same system.
 
   (media-video/vlc-2.1.0::gentoo, ebuild scheduled for merge) pulled in by
 media-video/vlc required by @selected
 
   (media-video/ffmpeg-1.0.7::gentoo, installed) pulled in by

 =media-video/ffmpeg-0.10.3:0[X?,encode?,gsm?,jpeg2k?,mp3?,sdl?,speex?,theora?,threads?,truetype?,vaapi?,vdpau?,x264?]
 (=media-video/ffmpeg-0.10.3:0[X,encode,mp3,sdl,truetype,x264]) required
 by (virtual/ffmpeg-0.10.3::gentoo, installed)
 
 
 For more information about Blocked Packages, please refer to the following
 section of the Gentoo Linux x86 Handbook (architecture is irrelevant):
 
 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked
 
 
 The following keyword changes are necessary to proceed:
  (see package.accept_keywords in the portage(5) man page for more details)
 # required by media-video/vlc-2.1.0[gnutls]
 # required by @selected
 # required by @world (argument)
 =net-libs/gnutls-3.2.5 ~x86
 
 Use --autounmask-write to write changes to config files (honoring
 CONFIG_PROTECT). Carefully examine the list of proposed changes,
 paying special attention to mask or keyword changes that may expose
 experimental or unstable packages.
 --
 After reading the 'Blocked Packages' found here,
 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked,
 would updating media-video/ffmpeg to version 1.2 [the current version of
 ffmpeg is 1.0.7], fix the blockage?
 
 Any input would be much appreciated.
 
 

It looks like you just need to add `net-libs/gnutls` to
/etc/portage/package.accept_keywords, which will fetch the testing
version of gnutls. Is your version of vlc also from testing? That may be
why emerge is complaining. I also noticed a lot of -USE% flags, which
tells me they were removed. Did you change USE flags at the same time
you attempted this update? There's no problem with that, of course, but
it can complicate upgrades sometimes. :)

Hope that helps.

Re: [gentoo-user] re: resolving blocked packages [media-video/ffmpeg-1.2:0]

[Daniel Campbell]

On 11/02/2013 06:07 AM, Alan McKinnon wrote:
 On 02/11/2013 12:49, Daniel Campbell wrote:
 On 10/27/2013 12:08 PM, Alexander Kapshuk wrote:
 As I ran 'emerge --ask --update --deep --with-bdeps=y --newuse world', I
 got the message below.

 These are the packages that would be merged, in order:

 Calculating dependencies... done!
 [ebuild  N ] dev-scheme/guile-1.8.8-r1  USE=deprecated nls regex
 threads -debug -debug-freelist -debug-malloc -discouraged -emacs
 -networking
 [ebuild  N ] sys-devel/autogen-5.15
 [ebuild U ~] net-libs/gnutls-3.2.5 [2.12.23-r1] USE=-dane%
 LINGUAS=-cs% -de% -en% -fi% -fr% -it% -ms% -nl% -pl% -sv% -uk% -vi%
 -zh_CN%
 [ebuild  N ] media-libs/libpostproc-0.8.0.20121125  USE=-3dnow
 (-altivec) -mmx -mmxext -pic -static-libs
 [ebuild U ~] media-video/vlc-2.1.0 [2.0.9] USE=-chromaprint% -fdk%
 -opencv% (-qt5) -rdp% {-test%} -vdpau%
 [blocks B  ] media-video/ffmpeg-1.2:0 (media-video/ffmpeg-1.2:0
 is blocking media-video/vlc-2.1.0)
 [blocks B  ] media-video/ffmpeg:0 (media-video/ffmpeg:0 is
 blocking media-libs/libpostproc-0.8.0.20121125)
 [blocks B  ] media-libs/libpostproc (media-libs/libpostproc is
 blocking media-video/ffmpeg-1.0.7)

 !!! Multiple package instances within a single package slot have been pulled
 !!! into the dependency graph, resulting in a slot conflict:

 net-libs/gnutls:0

   (net-libs/gnutls-3.2.5::gentoo, ebuild scheduled for merge) pulled in by
 =net-libs/gnutls-3.0.20:0 required by
 (media-video/vlc-2.1.0::gentoo, ebuild scheduled for merge)

   (net-libs/gnutls-2.12.23-r1::gentoo, installed) pulled in by
 (no parents that aren't satisfied by other packages in this slot)


 It may be possible to solve this problem by using package.mask to
 prevent one of those packages from being selected. However, it is also
 possible that conflicting dependencies exist such that they are
 impossible to satisfy simultaneously.  If such a conflict exists in
 the dependencies of two different packages, then those packages can
 not be installed simultaneously. You may want to try a larger value of
 the --backtrack option, such as --backtrack=30, in order to see if
 that will solve this conflict automatically.

 For more information, see MASKED PACKAGES section in the emerge man
 page or refer to the Gentoo Handbook.


  * Error: The above package list contains packages which cannot be
  * installed at the same time on the same system.

   (media-video/vlc-2.1.0::gentoo, ebuild scheduled for merge) pulled in by
 media-video/vlc required by @selected

   (media-video/ffmpeg-1.0.7::gentoo, installed) pulled in by

 =media-video/ffmpeg-0.10.3:0[X?,encode?,gsm?,jpeg2k?,mp3?,sdl?,speex?,theora?,threads?,truetype?,vaapi?,vdpau?,x264?]
 (=media-video/ffmpeg-0.10.3:0[X,encode,mp3,sdl,truetype,x264]) required
 by (virtual/ffmpeg-0.10.3::gentoo, installed)


 For more information about Blocked Packages, please refer to the following
 section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked


 The following keyword changes are necessary to proceed:
  (see package.accept_keywords in the portage(5) man page for more details)
 # required by media-video/vlc-2.1.0[gnutls]
 # required by @selected
 # required by @world (argument)
 =net-libs/gnutls-3.2.5 ~x86

 Use --autounmask-write to write changes to config files (honoring
 CONFIG_PROTECT). Carefully examine the list of proposed changes,
 paying special attention to mask or keyword changes that may expose
 experimental or unstable packages.
 --
 After reading the 'Blocked Packages' found here,
 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked,
 would updating media-video/ffmpeg to version 1.2 [the current version of
 ffmpeg is 1.0.7], fix the blockage?

 Any input would be much appreciated.



 It looks like you just need to add `net-libs/gnutls` to
 /etc/portage/package.accept_keywords, which will fetch the testing
 version of gnutls. Is your version of vlc also from testing? That may be
 why emerge is complaining. I also noticed a lot of -USE% flags, which
 tells me they were removed. Did you change USE flags at the same time
 you attempted this update? There's no problem with that, of course, but
 it can complicate upgrades sometimes. :)

 Hope that helps.

 
 
 The basic problem is a stable system with a bunch of unstable packages
 installed.
 
 The requested vlc version is ~arch, which wants a ~arch version of
 gnutls. This conflicts with other stable packages that want a stable
 version of gnutls.
 
 Mixing and matching arch and ~arch like this often causes unsolveable
 problems, especially with basic libs like gnutls used by lots of
 packages. In this specific case, I doubt very much that the problem is
 solveable. Either make the entire system ~arch or downgrade vlc to
 stable. Mixing is not recommended, not that it won't work (it often

Re: [gentoo-user] do subslots improve user-experience?

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/02/2013 07:04 AM, hasufell wrote:
 Another round of questioning the users here.
 
 more specifically: * how often do you experience useless rebuilds? 
 * do you really have a problem with running 
 revdep-rebuild/haskell-updater/perl-cleaner etc after every
 emerge? * do you think it's worth the effort to add more stuff to
 the PM, so that you don't have to run revdep-rebuild that often? *
 do you trust the other methods like subslots or preserved-rebuild
 to work reliably? (as in: do you still use revdep-rebuild?)
 
 If you want my opinion on subslots: # grep EMERGE_DEFAULT_OPTS
 /etc/portage/make.conf 
 EMERGE_DEFAULT_OPTS=--ignore-built-slot-operator-deps=y
 
To be honest, I don't know what subslots are or what they do. Regular
slots allow for multiple versions of a package to coexist, right?
Using context and knowledge of English, a subslot tells me that it'd
be a second level of slotting, which I see limited use for. It'd be
most useful for development languages that have multiple subversions.

In short, subslots don't seem to be visible enough for me to give an
opinion on them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSdRr5AAoJEJUrb08JgYgHlEgH+QF954wvjrHPt15KBVuFHt1Q
AOSWYmtZJFEDi/xiIpMi6a36fcyV7NY/G6jUqq7MmcGf/vW4hHOxn25cqYJd4dZB
Ausb4TcAp9l86LsMdlVEJ+W4IBBVRgDnylD6TM9nUahSwwt/zQ4LzaLnbOW+V9F6
Rozj9VaXbYR5P4rfMHUK6ojZGpEtirTaaAFmmvuQH0ZkjEZzJVJqKwOxzIwIq1mf
9AUnO9cRJpXHE23xxDJ0YXQ8PZxvPnUBjQFXKj2XPoGm67bljK+3LVC9iPDQ5mLw
sL5sKe83GkQK+VtxXv3MvcLi4pExJaKbPVXscsaeDbXElXYvDc6a0X7snjA0YGQ=
=ki5a
-END PGP SIGNATURE-

Re: [gentoo-user] re: resolving blocked packages [media-video/ffmpeg-1.2:0]

[Daniel Campbell]

On 11/02/2013 02:06 PM, Alexander Kapshuk wrote:
 On 11/02/2013 05:29 PM, Daniel Campbell wrote:
 On 11/02/2013 06:07 AM, Alan McKinnon wrote:
 On 02/11/2013 12:49, Daniel Campbell wrote:
 On 10/27/2013 12:08 PM, Alexander Kapshuk wrote:
 As I ran 'emerge --ask --update --deep --with-bdeps=y --newuse world', I
 got the message below.

 These are the packages that would be merged, in order:

 Calculating dependencies... done!
 [ebuild  N ] dev-scheme/guile-1.8.8-r1  USE=deprecated nls regex
 threads -debug -debug-freelist -debug-malloc -discouraged -emacs
 -networking
 [ebuild  N ] sys-devel/autogen-5.15
 [ebuild U ~] net-libs/gnutls-3.2.5 [2.12.23-r1] USE=-dane%
 LINGUAS=-cs% -de% -en% -fi% -fr% -it% -ms% -nl% -pl% -sv% -uk% -vi%
 -zh_CN%
 [ebuild  N ] media-libs/libpostproc-0.8.0.20121125  USE=-3dnow
 (-altivec) -mmx -mmxext -pic -static-libs
 [ebuild U ~] media-video/vlc-2.1.0 [2.0.9] USE=-chromaprint% -fdk%
 -opencv% (-qt5) -rdp% {-test%} -vdpau%
 [blocks B  ] media-video/ffmpeg-1.2:0 (media-video/ffmpeg-1.2:0
 is blocking media-video/vlc-2.1.0)
 [blocks B  ] media-video/ffmpeg:0 (media-video/ffmpeg:0 is
 blocking media-libs/libpostproc-0.8.0.20121125)
 [blocks B  ] media-libs/libpostproc (media-libs/libpostproc is
 blocking media-video/ffmpeg-1.0.7)

 !!! Multiple package instances within a single package slot have been 
 pulled
 !!! into the dependency graph, resulting in a slot conflict:

 net-libs/gnutls:0

   (net-libs/gnutls-3.2.5::gentoo, ebuild scheduled for merge) pulled in by
 =net-libs/gnutls-3.0.20:0 required by
 (media-video/vlc-2.1.0::gentoo, ebuild scheduled for merge)

   (net-libs/gnutls-2.12.23-r1::gentoo, installed) pulled in by
 (no parents that aren't satisfied by other packages in this slot)


 It may be possible to solve this problem by using package.mask to
 prevent one of those packages from being selected. However, it is also
 possible that conflicting dependencies exist such that they are
 impossible to satisfy simultaneously.  If such a conflict exists in
 the dependencies of two different packages, then those packages can
 not be installed simultaneously. You may want to try a larger value of
 the --backtrack option, such as --backtrack=30, in order to see if
 that will solve this conflict automatically.

 For more information, see MASKED PACKAGES section in the emerge man
 page or refer to the Gentoo Handbook.


  * Error: The above package list contains packages which cannot be
  * installed at the same time on the same system.

   (media-video/vlc-2.1.0::gentoo, ebuild scheduled for merge) pulled in by
 media-video/vlc required by @selected

   (media-video/ffmpeg-1.0.7::gentoo, installed) pulled in by

 =media-video/ffmpeg-0.10.3:0[X?,encode?,gsm?,jpeg2k?,mp3?,sdl?,speex?,theora?,threads?,truetype?,vaapi?,vdpau?,x264?]
 (=media-video/ffmpeg-0.10.3:0[X,encode,mp3,sdl,truetype,x264]) required
 by (virtual/ffmpeg-0.10.3::gentoo, installed)


 For more information about Blocked Packages, please refer to the following
 section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked


 The following keyword changes are necessary to proceed:
  (see package.accept_keywords in the portage(5) man page for more 
 details)
 # required by media-video/vlc-2.1.0[gnutls]
 # required by @selected
 # required by @world (argument)
 =net-libs/gnutls-3.2.5 ~x86

 Use --autounmask-write to write changes to config files (honoring
 CONFIG_PROTECT). Carefully examine the list of proposed changes,
 paying special attention to mask or keyword changes that may expose
 experimental or unstable packages.
 --
 After reading the 'Blocked Packages' found here,
 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked,
 would updating media-video/ffmpeg to version 1.2 [the current version of
 ffmpeg is 1.0.7], fix the blockage?

 Any input would be much appreciated.


 It looks like you just need to add `net-libs/gnutls` to
 /etc/portage/package.accept_keywords, which will fetch the testing
 version of gnutls. Is your version of vlc also from testing? That may be
 why emerge is complaining. I also noticed a lot of -USE% flags, which
 tells me they were removed. Did you change USE flags at the same time
 you attempted this update? There's no problem with that, of course, but
 it can complicate upgrades sometimes. :)

 Hope that helps.


 The basic problem is a stable system with a bunch of unstable packages
 installed.

 The requested vlc version is ~arch, which wants a ~arch version of
 gnutls. This conflicts with other stable packages that want a stable
 version of gnutls.

 Mixing and matching arch and ~arch like this often causes unsolveable
 problems, especially with basic libs like gnutls used by lots of
 packages. In this specific case, I doubt very much that the problem is
 solveable. Either make the entire system

Re: [gentoo-user] Re: systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/23/2013 05:51 PM, Steven J. Long wrote:
 Daniel Campbell wrote:
 Do you know the design consequences of opt-in versus opt-out? I'll keep
 this short: When evolving a codebase, new behavior for core parts of the
 system should not be pushed or forced on users. If you must, keep the
 old behavior around as a default and allow users to try the new thing by
 explicitly opting in. The new naming in whichever udev started the mess
 did it the exact opposite (and wrong) way.
 
 Good luck with that argument; you have to bear in mind Gentoo devs are
 mostly fresh out of Uni (or still in it.) They're not very experienced iow,
 as a rule, apart from in Gentoo ebuilds and making the tree work together,
 which is all we ask of them. Oh and usually Java from Uni; they typically
 have a snobbery about shell as well (and doesn't it show) which is quite
 amusing when one considers their implementation language.
 
 (No this is not to the topic per se: it's a wider point that I had to
 repeat to someone recently, who apparently found the insight very useful.
 So I put it out there for other users, or those to come.
 
 I have zero interest in arguing the toss with anyone: you're welcome to
 your opinion, that's mine. You ain't gonna change it, so don't bother
 trying. Feel free to rant amongst yourselves. ;)
I know you said you won't argue about it, and that's fine. I'm not sure
how fair it is to broadly denigrate the Gentoo devs, though. There are
so many, with varying levels of experience, specialty, and education,
that it would be difficult to put them into a neat label box. Among all
the distributions out there that run Linux as the kernel, I think Gentoo
is probably the most compatible in terms of choices. They do a good job
of making sure OpenRC, sysv, systemd, runit, and others are possible on
Gentoo. Perhaps you know more about some of the devs than I, though. I'm
just a user who aspires to become an official developer to learn more
about it.

 
 The point is that this is actually why Gentoo is a very good place for a
 developer to cut hir teeth: they learn from the other users when they
 install, and usually come up through the forums, where if you've ever
 been to OTW, the difference between a personal attack and criticism of
 someone's work is blatantly obvious. Further they have to run any major
 design ideas past that same experienced user-base, who had the rough
 edges knocked off ages ago, and simply want it to work for everyone.
 
 They don't always see it like that, ofc, but I for one remember thinking
 much dumber things. [1]
Well, the udev behavior I was discussing isn't really the fault of
Gentoo devs. It was just the default for udev, as shipped by upstream.
My guess is the devs decided to opt for the default so those who planned
on using the new behavior (and/or GNOME 3.8) wouldn't have to do
additional configuration... at the expense of everyone else having to if
they wanted to retain the net.ifnames behavior. They were screwed no
matter what, really. Had the systemd/udev guys not created the new
behavior, Gentoo's devs wouldn't have had to make a decision that they
knew wouldn't please everyone.

 
 The way the new behavior was introduced may have led users of single-NIC
 systems to believe that the old way was broken, when as demonstrated
 through past use, works *just fine* for single-NIC machines. It was
 *multi-NIC* use that wasn't as predictive and needed the fix, not
 *single*. It's basically using poor design/defaults decisions to smear
 existing technology dishonestly. Technical propaganda, so to speak.
 
 Even more amusing when you consider that the original race that was so
 terrible it justified breaking the machines of those it was supposedly
 in aid of, as well as those of people who had zero use for it, yet were
 apparently the target market, was in fact implemented by the same set
 of early userspace experts who put themselves forward as such 5 years
 previously.
 
 I personally have no words to describe such a situation beyond idiocy.
Pretty much agreed. Self-proclaiming as an expert has such an air of
egotism it's hard to take it seriously.

 
 Getting back to the original topic, cgroups sound like a pretty neat
 idea that other init systems could benefit from. If the systemd guys are
 willing to work on that subsystem for themselves, are they also
 interested in seeing what other init systems would want from cgroups?
 
 This is actually what I posted about: I know qnikst already implemented
 a large chunk of functionality in openrc and was concerned about the
 proposed changes mainly because as usual it was a grand statement of
 intent, with little in the way of coherent content. But we're spitting in
 the wind: you can't expect amateurs who've backed themselves into a
 corner, full of ego-attachment to their work, to ever admit it's crap,
 or that they fscked-up. Certainly not based on the record of this team.
Agreed. To this day, PulseAudio is still synonymous with my sound

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/21/2013 03:33 PM, Volker Armin Hemmann wrote:
 Am 20.10.2013 13:18, schrieb Daniel Campbell:
 On 10/20/2013 06:02 AM, Volker Armin Hemmann wrote:
 Am 20.10.2013 12:52, schrieb Daniel Campbell:
 On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote:
 Am 20.10.2013 08:34, schrieb Daniel Campbell:
 hm, Redhat is one of the companies investing the most money into linux
 kernel, userland, graphics... if you 'don't trust them' you are pretty
 much 20 years too late.
 Investing money does not make them any more qualified or deserving of
 making decisions. Red Hat is not the sole user of Linux. They should
 consider themselves lucky that they are even able to profit from
 something that's free.

 You're right, though. They've been around for a while, and I've never
 trusted them or any other corporate interest in *nix. There's always a
 catch when dealing with a business.

 'have been around for a while' - replace that with 'are financing more
 core developers than anybody else'.

 That's less reason to trust, not more. That's like citing the popularity
 of something as proof of its quality, when oftentimes it's the exact
 opposite that's true.

 So they spend a lot of money hiring developers. The more important
 question is what is their agenda? What do they tell those developers to
 *make*? You don't hire people without a business plan in mind.


 without Redhat, there would be no linux. gnu software would be massively
 lacking and X would be without drivers.

 So calm down.

 Linux was created and released in 1991, built with GNU tools. Red Hat
 didn't come along until 1993. Linux and GNU would both still be here;
 their quality without Red Hat involvement is speculative at best.
 
 no, it is not. Several of the most important Kernel devs are or were
 Redhat developers.
 
 So you just showed that you have no clue at all. You should stop right
 there.
I do have a clue, but there is logically no way to say, for sure, that
Linux and GNU would be worse off without Red Hat's existence. Why?
Because we only know what happened _with_ their existence. The assertion
can't be validated or even tested without somehow going back in time and
preventing Red Hat from forming. It's an empty assertion.

 
 I maintain that motives matter more than money and that they (motives)
 should continually be audited, especially when receiving contributions
 from a company. They may already be; I don't know.

 Re: drivers, do you expect me to believe Red Hat is responsible for
 every X11 driver out there?
 no, but they paid a lot of developers working on several drivers.
 
 For example David Airlie is employed by Redhat.
 
 Look him up.
 
The no is all I need to see. You said X would be without drivers. So
unless Red Hat employees wrote every line of the X driver code
(unlikely) or produced every single X driver available (proven false),
the assertion is false.
 
  How many of this list?[1] What of radeon and
 
 radeon? David Airlie again.
 
 nouveau? nvidia's own driver? xf86-input-wacom (and linuxwacom)[2]? I'm
 sure Red Hat has contributed plenty to X11, but your statement is
 flat-out false.
 
 nope. Your statements lack any connection to reality.
 
 since you like links, think about this one for a while:
 
 https://www.linux.com/learn/tutorials/560928-counting-contributions-who-wrote-linux-32
 http://www.linuxfoundation.org/news-media/announcements/2012/04/linux-foundation-releases-annual-linux-development-report
 
 

My statements reflect the truth that Red Hat contributed to, but did not
single-handedly *build*, the GNU/Linux operating system. Without their
existence, there's no proof that the same drivers (X11 or otherwise)
wouldn't be written by some other people. Like I said, speculative at
best. On both sides.

Your links truthfully reflect that Red Hat contributes the most changes
of any company. A majority of something does not magically make it
perfect or good or whatever other mythical ideal one can conjure.

The links prove that Red Hat guides a lot of the changes. Taking a look
at the pdf[1] from 2012, Red Hat's contribution percentage, compared to
other companies, is rather high (11.9%, p.10). Almost double the next
highest contributor (Novell, at 6.4%). Why would a company invest that
much effort into something open and free if there was no agenda, no
business plan, no grander scheme or vision?

I'm sure some of their work is good. Nothing's all bad or all good. But
a company should not be trusted simply because they throw money at
something or have the most people working on something compared to other
companies. That's reason to be *suspicious*. A business does not throw
money at something unless they plan on capitalizing on it in some way.

[1]: http://go.linuxfoundation.org/who-writes-linux-2012

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
 Am 19.10.2013 17:02, schrieb Daniel Campbell:
 On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
 https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign

 Not sure if I read that just right... but since nobody is doing cgroup
 management besides systemd, in practice the cgroups implementation in
 Linux wasn't very consistent. So since systemd is doing it, their work
 is helping shape the kernel's cgroups api?

 Interesting...

 From my perspective it looks like systemd developers are trying to push
 their ideas into the kernel, almost like they intend to merge systemd
 *with* the kernel. 
 
 from what I read in the article cgroups are a mess and are cleaned up
 anyway. The only real user of cgroups at the moment is systemd.
 Others are welcome to make use of cgroups too. But in the current state
 nobody blames them for not jumping in.
No complaints here in improving something, but consider the source is
all I'm saying.

 
 If systemd is the only implementation of cgroups and
 their developers are working on cgroup support in the kernel, it spells
 calamity given their history of evangelism and zealotry.
 
 well, going over some old ml threads on fedora mailing lists all I could
 find was that Poettering and Sievers DID listen and DID make changes if
 the demand was high enough.
 
 Sure, I dislike systemd. Sure what happened with udev was a dick move.
 But their 'zealotry' is a lot less developed than the zealotry of those
 who exploded about using an 'init-thingy' in the future.

I'd say their zealotry is less loud and more persistent. Their way is
best, UNIX (and its philosophy) is outmoded, people are thinking 30
years behind where we are, etc etc etc. Those who have separate /usr and
blame systemd for pushing them to use an initramfs aren't seeing the
real problem (upstreams not putting things where they belong, FHS no
longer *really* being worked on, generally just the filesystem being
played with like a toy)


 I truly wish I understood why a single userland program and its
 developers are being given the keys to an entire subsystem of the
 kernel. 
 they aren't.
Of the people who have committed to the cgroup subsystem of the kernel,
how many are not members of the systemd, GNOME, or Red Hat projects?
I'll let that speak for itself.

 
 Their changes to udev have proven to be a headache for users,
 
 yes? which ones?
Persistent NIC naming, for starters. The former maintainer's idea to
merge with systemd (which was influenced by Mr. Poettering in the first
place) when the two are completely separate pieces of software that do
two completely different jobs, and various other troubles with udev 
175 that one can Google for and find tons of results.
 
 and the kernel is held to a much higher standard of stability and
 interoperability. In addition, the top-level developers of systemd (and
 GNOME, and the now-deprecated consolekit/polkit/udisks/etc) are employed
 by a for-profit company (Red Hat), which has a vested interest in
 shaping Linux as a platform. They and other corporations cannot be
 trusted with stuff like this...
 
 hm, Redhat is one of the companies investing the most money into linux
 kernel, userland, graphics... if you 'don't trust them' you are pretty
 much 20 years too late.
Investing money does not make them any more qualified or deserving of
making decisions. Red Hat is not the sole user of Linux. They should
consider themselves lucky that they are even able to profit from
something that's free.

You're right, though. They've been around for a while, and I've never
trusted them or any other corporate interest in *nix. There's always a
catch when dealing with a business.

 

 I'd like to see what Linus has to say about this if/when he finds out.
 He's not impressed with Sievers or Poettering. Personally I'd like to
 see them ostracized from the community and contained to their own
 distro, where they belong.

 so much about zealotry.
 
 
When a tumor is growing, if you cannot excise it, you must make its
environment so harsh that it recedes. I have strong opinions, but I
don't go around shoving my software in peoples' faces or tell people
they're wrong to not use my software. Even Linus, who's known for his
ego, wouldn't cross that line.

If I'm a zealot of anything, it's freedom of choice.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/20/2013 02:37 AM, Samuli Suominen wrote:
 
 On 20/10/13 09:34, Daniel Campbell wrote:
 On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
 Am 19.10.2013 17:02, schrieb Daniel Campbell:
 On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
 https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign

 Not sure if I read that just right... but since nobody is doing cgroup
 management besides systemd, in practice the cgroups implementation in
 Linux wasn't very consistent. So since systemd is doing it, their work
 is helping shape the kernel's cgroups api?

 Interesting...

 From my perspective it looks like systemd developers are trying to push
 their ideas into the kernel, almost like they intend to merge systemd
 *with* the kernel. 
 from what I read in the article cgroups are a mess and are cleaned up
 anyway. The only real user of cgroups at the moment is systemd.
 Others are welcome to make use of cgroups too. But in the current state
 nobody blames them for not jumping in.
 No complaints here in improving something, but consider the source is
 all I'm saying.

 If systemd is the only implementation of cgroups and
 their developers are working on cgroup support in the kernel, it spells
 calamity given their history of evangelism and zealotry.
 well, going over some old ml threads on fedora mailing lists all I could
 find was that Poettering and Sievers DID listen and DID make changes if
 the demand was high enough.

 Sure, I dislike systemd. Sure what happened with udev was a dick move.
 But their 'zealotry' is a lot less developed than the zealotry of those
 who exploded about using an 'init-thingy' in the future.

 I'd say their zealotry is less loud and more persistent. Their way is
 best, UNIX (and its philosophy) is outmoded, people are thinking 30
 years behind where we are, etc etc etc. Those who have separate /usr and
 blame systemd for pushing them to use an initramfs aren't seeing the
 real problem (upstreams not putting things where they belong, FHS no
 longer *really* being worked on, generally just the filesystem being
 played with like a toy)

 I truly wish I understood why a single userland program and its
 developers are being given the keys to an entire subsystem of the
 kernel. 
 they aren't.
 Of the people who have committed to the cgroup subsystem of the kernel,
 how many are not members of the systemd, GNOME, or Red Hat projects?
 I'll let that speak for itself.

 Their changes to udev have proven to be a headache for users,
 yes? which ones?
 Persistent NIC naming, for starters. The former maintainer's idea to
 merge with systemd (which was influenced by Mr. Poettering in the first
 place) when the two are completely separate pieces of software that do
 two completely different jobs, and various other troubles with udev 
 175 that one can Google for and find tons of results.
 
 I can't find anything that would be true. Can you point out some?
 A lot of FUD[1] and outright lies coming from people, who, for example,
 don't like systemd.
 
 [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
 
 I know for a fact udev-208 is a full replacement for udev-171 in terms
 that both work on same kernels, same libcs, and so forth. That's why
 171 is no longer in Portage, because it's completely useless from users
 (and developers) point of view.
 
 Adjusting some configs and enabling some kernel options that have been
 around for a long time is just part of normal maintenance process,
 that's what we have admins for.
 

Do you know the design consequences of opt-in versus opt-out? I'll keep
this short: When evolving a codebase, new behavior for core parts of the
system should not be pushed or forced on users. If you must, keep the
old behavior around as a default and allow users to try the new thing by
explicitly opting in. The new naming in whichever udev started the mess
did it the exact opposite (and wrong) way.

While editing and updating configs is a normal part of system
maintenance, turning a system on its head and screwing it out of network
accessibility until the new default is reversed (by means of a `kernel`
line in GRUB, requiring a reboot) is straight-up wrong design.
Conversely, keeping old behavior, even for systems that *do* have
multiple NICs, will at least be functional (for one of the NICs, anyway)
until they set the option to get their expected behavior sorted out.
Multi-NIC systems are less common than single-NIC systems, and that
alone should've been enough motivation to leave old behavior as default,
with the new behavior a simple config switch away.

The way the new behavior was introduced may have led users of single-NIC
systems to believe that the old way was broken, when as demonstrated
through past use, works *just fine* for single-NIC machines. It was
*multi-NIC* use that wasn't as predictive and needed the fix, not
*single*. It's basically using poor design/defaults decisions to smear
existing

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/20/2013 04:55 AM, Samuli Suominen wrote:
 
 On 20/10/13 12:24, Daniel Campbell wrote:
 On 10/20/2013 02:37 AM, Samuli Suominen wrote:
 On 20/10/13 09:34, Daniel Campbell wrote:
 On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
 Am 19.10.2013 17:02, schrieb Daniel Campbell:
 On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
 https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign

 Not sure if I read that just right... but since nobody is doing cgroup
 management besides systemd, in practice the cgroups implementation in
 Linux wasn't very consistent. So since systemd is doing it, their work
 is helping shape the kernel's cgroups api?

 Interesting...

 From my perspective it looks like systemd developers are trying to push
 their ideas into the kernel, almost like they intend to merge systemd
 *with* the kernel. 
 from what I read in the article cgroups are a mess and are cleaned up
 anyway. The only real user of cgroups at the moment is systemd.
 Others are welcome to make use of cgroups too. But in the current state
 nobody blames them for not jumping in.
 No complaints here in improving something, but consider the source is
 all I'm saying.

 If systemd is the only implementation of cgroups and
 their developers are working on cgroup support in the kernel, it spells
 calamity given their history of evangelism and zealotry.
 well, going over some old ml threads on fedora mailing lists all I could
 find was that Poettering and Sievers DID listen and DID make changes if
 the demand was high enough.

 Sure, I dislike systemd. Sure what happened with udev was a dick move.
 But their 'zealotry' is a lot less developed than the zealotry of those
 who exploded about using an 'init-thingy' in the future.

 I'd say their zealotry is less loud and more persistent. Their way is
 best, UNIX (and its philosophy) is outmoded, people are thinking 30
 years behind where we are, etc etc etc. Those who have separate /usr and
 blame systemd for pushing them to use an initramfs aren't seeing the
 real problem (upstreams not putting things where they belong, FHS no
 longer *really* being worked on, generally just the filesystem being
 played with like a toy)

 I truly wish I understood why a single userland program and its
 developers are being given the keys to an entire subsystem of the
 kernel. 
 they aren't.
 Of the people who have committed to the cgroup subsystem of the kernel,
 how many are not members of the systemd, GNOME, or Red Hat projects?
 I'll let that speak for itself.

 Their changes to udev have proven to be a headache for users,
 yes? which ones?
 Persistent NIC naming, for starters. The former maintainer's idea to
 merge with systemd (which was influenced by Mr. Poettering in the first
 place) when the two are completely separate pieces of software that do
 two completely different jobs, and various other troubles with udev 
 175 that one can Google for and find tons of results.
 I can't find anything that would be true. Can you point out some?
 A lot of FUD[1] and outright lies coming from people, who, for example,
 don't like systemd.

 [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

 I know for a fact udev-208 is a full replacement for udev-171 in terms
 that both work on same kernels, same libcs, and so forth. That's why
 171 is no longer in Portage, because it's completely useless from users
 (and developers) point of view.

 Adjusting some configs and enabling some kernel options that have been
 around for a long time is just part of normal maintenance process,
 that's what we have admins for.

 Do you know the design consequences of opt-in versus opt-out? I'll keep
 this short: When evolving a codebase, new behavior for core parts of the
 system should not be pushed or forced on users. If you must, keep the
 old behavior around as a default and allow users to try the new thing by
 explicitly opting in. The new naming in whichever udev started the mess
 did it the exact opposite (and wrong) way.
 
 
 It's not forced upon you. You received a news item that had instructions
 on howto assign names you want, like lan0, internet1, wireless3, and so
 forth.
 And it also described howto turn off udev from completely renaming the
 devices, to keep kernel assigned names.
 What they did was they dropped the *broken* feature called 'persistent
 rule_generator' which never worked correctly, and in
 race conditions still flipped eth0 - eth1 around -- that was a
 *security* flaw that *needed* to go.
 It would have gone even without providing the alternative of providing
 biosdevname -like new name optionality to the users.
 Kernel and kernel drivers are designed in a way it's not supported to
 flip in-place kernel names and udev tried to workaround that.
 
 https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html
 

Like I mentioned in a prior e-mail, the change didn't affect me when it
was pushed, and doesn't affect me

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote:
 Am 20.10.2013 08:34, schrieb Daniel Campbell:
 hm, Redhat is one of the companies investing the most money into linux
 kernel, userland, graphics... if you 'don't trust them' you are pretty
 much 20 years too late.
 Investing money does not make them any more qualified or deserving of
 making decisions. Red Hat is not the sole user of Linux. They should
 consider themselves lucky that they are even able to profit from
 something that's free.

 You're right, though. They've been around for a while, and I've never
 trusted them or any other corporate interest in *nix. There's always a
 catch when dealing with a business.

 
 'have been around for a while' - replace that with 'are financing more
 core developers than anybody else'.
 
That's less reason to trust, not more. That's like citing the popularity
of something as proof of its quality, when oftentimes it's the exact
opposite that's true.

So they spend a lot of money hiring developers. The more important
question is what is their agenda? What do they tell those developers to
*make*? You don't hire people without a business plan in mind.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/20/2013 06:02 AM, Volker Armin Hemmann wrote:
 Am 20.10.2013 12:52, schrieb Daniel Campbell:
 On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote:
 Am 20.10.2013 08:34, schrieb Daniel Campbell:
 hm, Redhat is one of the companies investing the most money into linux
 kernel, userland, graphics... if you 'don't trust them' you are pretty
 much 20 years too late.
 Investing money does not make them any more qualified or deserving of
 making decisions. Red Hat is not the sole user of Linux. They should
 consider themselves lucky that they are even able to profit from
 something that's free.

 You're right, though. They've been around for a while, and I've never
 trusted them or any other corporate interest in *nix. There's always a
 catch when dealing with a business.

 'have been around for a while' - replace that with 'are financing more
 core developers than anybody else'.

 That's less reason to trust, not more. That's like citing the popularity
 of something as proof of its quality, when oftentimes it's the exact
 opposite that's true.

 So they spend a lot of money hiring developers. The more important
 question is what is their agenda? What do they tell those developers to
 *make*? You don't hire people without a business plan in mind.


 without Redhat, there would be no linux. gnu software would be massively
 lacking and X would be without drivers.
 
 So calm down.
 
Linux was created and released in 1991, built with GNU tools. Red Hat
didn't come along until 1993. Linux and GNU would both still be here;
their quality without Red Hat involvement is speculative at best.

I maintain that motives matter more than money and that they (motives)
should continually be audited, especially when receiving contributions
from a company. They may already be; I don't know.

Re: drivers, do you expect me to believe Red Hat is responsible for
every X11 driver out there? How many of this list?[1] What of radeon and
nouveau? nvidia's own driver? xf86-input-wacom (and linuxwacom)[2]? I'm
sure Red Hat has contributed plenty to X11, but your statement is
flat-out false.

[1]: http://www.usinglinux.org/x11-drivers/
[2]: http://sourceforge.net/apps/mediawiki/linuxwacom/

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/20/2013 09:34 PM, Walter Dnes wrote:
 On Sun, Oct 20, 2013 at 05:03:51PM +0300, Samuli Suominen wrote
 
 That's a bridge we will cross when there is a bridge to be crossed, but
 from top of my head:
 We will maintain a minimal patchset that reverts the offending code.

 As in, that's nothing to be worried about before it happens.
 
   That's not always possible, e.g. GNOME 3.8.
 
I think that's an exception to the rule. I mean, upstream deliberately
chose to depend on systemd/logind and whatnot. In such a situation
there's literally no way to fix it without a fork, and I doubt Gentoo as
an organization is interested in that.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
 https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign
 
 Not sure if I read that just right... but since nobody is doing cgroup
 management besides systemd, in practice the cgroups implementation in
 Linux wasn't very consistent. So since systemd is doing it, their work
 is helping shape the kernel's cgroups api?
 
 Interesting...
 

From my perspective it looks like systemd developers are trying to push
their ideas into the kernel, almost like they intend to merge systemd
*with* the kernel. If systemd is the only implementation of cgroups and
their developers are working on cgroup support in the kernel, it spells
calamity given their history of evangelism and zealotry.

I truly wish I understood why a single userland program and its
developers are being given the keys to an entire subsystem of the
kernel. Their changes to udev have proven to be a headache for users,
and the kernel is held to a much higher standard of stability and
interoperability. In addition, the top-level developers of systemd (and
GNOME, and the now-deprecated consolekit/polkit/udisks/etc) are employed
by a for-profit company (Red Hat), which has a vested interest in
shaping Linux as a platform. They and other corporations cannot be
trusted with stuff like this...

I'd like to see what Linus has to say about this if/when he finds out.
He's not impressed with Sievers or Poettering. Personally I'd like to
see them ostracized from the community and contained to their own
distro, where they belong.

Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01

[Daniel Campbell]

On 10/11/2013 09:21 PM, walt wrote:
 On 10/11/2013 01:42 AM, Neil Bothwick wrote:
 
 I don't like systemd,
 
 Sorry if my memory is failing (it surely is) but I don't recall any
 explanation from you describing your dissatisfaction with systemd.
 
 The three happiest months of my life were spent as a student in London
 in the summer of 1974, where I frequently heard the phrase I should have
 thought that you
 
 Only much later did I discover that such a benign phrase conveys the most
 severe form of British disapproval :(
 
 With belated apologies to my many kind Brit friends from 1974, I ask you
 to tell us WTF you dislike systemd, and use language that us Yanks can
 fscking unnerstand, got it, punk?
 
 
What do his personal opinions regarding systemd have to do with separate
/ and /usr? It's just another one of many, many applications that
migrated to /usr and added more inertia to de facto practice.

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Daniel Campbell]

On 09/30/2013 04:31 AM, Alan McKinnon wrote:
 On 30/09/2013 01:31, Daniel Campbell wrote:
 
 
 Curious; how is merging two filesystems done? I don't have a separate
 /usr and am completely unaffected by this change, but it's somewhat
 interesting to me. /usr stores some pretty important data on it, and I
 imagine you'd need to mount it somewhere else in order to move the
 files from it to /'s /usr dir. Is a Live environment recommended
 instead? How would you mitigate the leftover partition, assuming it's
 not adjacent to /'s partition?
 
 
 Because /usr is continually in use, boot using a livecd of your choice.
 In that environment, use fdisk (or whichever *disk you like) to make any
 changes to partitions you know you will need.
 
 Mount your gentoo / somewhere convenient
 Mount your gentoo /usr somewhere convenient
 
 copy the latter over to the former
 edit fstab
 reboot
 
 It really is just a case of moving a large number of files around, but
 because those very files are always in use you have to do it in livecd
 environment.
 
 There's no exact checklist one can follow to guarantee a 100% result
 blindly. Instead, as this is Gentoo, we assume users built their system
 knowing what they were doing and can appropriately deal with their
 config themselves. RAID and LVM for example may need attention, but the
 user is usually equipped to deal with that and knows what t do.
 
 

 I don't run an initramfs, thankfully, but I keep a pretty simple
 system in terms of filesystems: /, /boot, and /home.

 
My suspicions were mostly correct, then. If the merge is that simple, I
see no reason not to do it if one doesn't want to roll an initramfs.
However, I imagine moving partitions around in gparted or something
similar would be quite a wait if / and /usr weren't adjacent on the drive.

Thanks for the simple-but-thorough explanation. :)

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/28/2013 09:04 AM, Alan McKinnon wrote:
 On 28/09/2013 13:32, Tanstaafl wrote:
 On 2013-09-27 7:10 PM, Alan McKinnon alan.mckin...@gmail.com
 wrote:
 No really,*why exactly*?
 
 Because that was the RECOMMENDED WAY IN THE GENTOO HANDBOOK when
 I first set this system up many years ago.
 
 This was something almost all of us recommended way back then. Lord
 only knows why we recommeded that. Maybe it was small drives (which
 didn't have), maybe it was different mount options (which I never
 did and never saw anyone else do either), or maybe it was for thin
 clients (which I only ever saw in use once - Shuttleworth labs in
 University of Cape Town).
 
 So why did we all (and I included myself) recommend this so much?
 Dude, I have no idea, but I *think* we were cargo-culting more than
 any other single factor.
 
 
 I have no philosophical reason reason to stick with it, only a
 (maybe irrational) fear of breaking things if I attempt to merge
 it back into /.
 
 This, combined with an intense (also maybe irrational) desire to
 avoid like the plague using an initramfs, is why this decision to
 FORCE me into a position of possibly having to break my system
 (either by a filed attempt at merging /usr into /, or a failed
 attampt at using an initramfs).
 
 No-one is forcing you to do anything, the news item did not say
 that.
 
 It says that if you do it, the devs will not support you and you
 are on your own. It also says that in the dev's opinion, the day
 when you can no longer support it either is probably not too far
 away
 
 I too sincerely hope eudev bypasses this issue.
 
 This has nothing to do with eudev, not with udev
 
 The main thing about this that pisses me off is the lack of
 enough warning... one month? Really? One month to compleyelt
 rebuild a seerver that has been running flawlessly for many
 years, just because someone doesn't like something that has been
 done for many years?
 
 
 First, it is not one month, it is much longer. We've all been
 whinging about the issue for most of this year. Two, why do you
 think you need to rebuild the entire machine? You don't need to do
 that just to merge two filesystems.
 
 To merge two filesystems, you just merge two filesystems. You
 don't rebuild anything. You might have some downtime though
 
 Please see the news item for what it actually is, not something
 else.
 
 

Curious; how is merging two filesystems done? I don't have a separate
/usr and am completely unaffected by this change, but it's somewhat
interesting to me. /usr stores some pretty important data on it, and I
imagine you'd need to mount it somewhere else in order to move the
files from it to /'s /usr dir. Is a Live environment recommended
instead? How would you mitigate the leftover partition, assuming it's
not adjacent to /'s partition?

I don't run an initramfs, thankfully, but I keep a pretty simple
system in terms of filesystems: /, /boot, and /home.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSSLhZAAoJEJUrb08JgYgHFk4H/3e4LobiR0KXODLC1xznXbY0
Q923rabxPj82VDS8bP+hNx9YopKLJUlpqAtvQG982Kztw/8UUY2Q4euLfrXlN7ah
pNNC0UG8KGpN9K4RF1tcEVwtXkS23f9s6GdgRPRFWq0ngJq9iJXCEW134jlcXQel
vbcRiJMtmKzpnyDIrs7XZxOWhV0V5EQc1uFq4r97ydKZeOjXCpHXtYTjD8dGv3ZH
0GHQgjOFpo5WU0eIN06Jt862b/WjE7RVQZJvSY8DrXkdIDcUO5PsVHsc/Van5pMV
pzQ2xV6Idh1AhQQ3meZzzAAcHzDWgXCHqnBM/gwnFCFSL/zRcFThdwapObfIVMI=
=tAhS
-END PGP SIGNATURE-

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Daniel Campbell]

On 09/28/2013 12:31 PM, Dale wrote:
 William Hubbs wrote:
 On Fri, Sep 27, 2013 at 07:32:20PM -0500, Bruce Hill wrote:
 On Fri, Sep 27, 2013 at 05:57:06PM -0500, Dale wrote:
 Bruce Hill wrote:
 On Fri, Sep 27, 2013 at 05:33:02PM -0500, Dale wrote:
 I'm hoping that since I use eudev, I don't have to worry about this.
 If I do, this could get interesting, again. Dale
 Do you have /usr separate from / ?

 Yep.  From my understanding tho, eudev is not supposed to be affected by
 this problem tho.

 One reason for this being seperate, I have / and /boot on a regular
 partition and everything else on LVM.  Sometimes that /usr gets a bit
 full.  It's not so bad after I moved all the portage stuff out and put
 it in /var.  Now I have to watch /var too.  lol

 Dale

 You need to read the blog post listed in the news item, as it's not just
 specific to udev anymore.

 Bruce is correct; This issue is not specific to udev/eudev/mdev.

 I suppose that what I am about to say isn't really relevant, but it is
 unfortunate over the past year that people blamed udev specifically for
 this. It is true that it does things that don't work if /usr isn't
 mounted, but eudev does as well, since it is basically the same code.

 If you read flameeyes' blog post, you will get a better idea of what the
 issue involves. It is the entire boot process and how to deal with which
 software is considered critical for booting.

 There is no reason to rebuild your server; we aren't telling you you
 have to merge /usr into /. The only thing we are saying is that you will
 need to use an initramfs if you are going to keep them separate.

 I have a pretty simple setup, but I have been using an initramfs which I
 built some time ago with genkernel and I barely know it is there.

 I recommend that you familiarize yourself with genkernel or dracut and
 build an initramfs. Since nothing is changing until at least
 Nov 1, you can test your initramfs by adding an entry to your boot
 loader configuration that uses it and get it set up correctly while you
 can still fall back on booting without it.

 I do not recommend that anyone who has separate /usr do nothing at
 this point. Please re-read the second paragraph of the news item.

 Thanks,

 William

 
 One thing that you seem to be missing here.  Before Gentoo, I used
 Mandrake.  It had a init thingy.  It caused me much grief and is one
 reason I left Mandrake.  I also didn't like the upgrade process either
 but one reason I chose Gentoo is no init thingy.  I wanted to be rid of
 that.  Now, whether it is udev or not, here comes that stupid init
 thingy just because someone doesn't want to put files where they should
 be which is not inside /usr.
 
 So, given my history with the init thingy, if I do use a init thingy and
 it fails for whatever reason, I'll be installing something else.  I done
 went down the road of trying to fix one of those stupid things and I
 have no plan or desire to do so again.  I'm also not going to spend
 hours reinstalling Gentoo either.  If, more than likely when, the init
 thingy fails, I'll be installing something else and I'll most my last
 sign off message here.  One thing about Linux, there are plenty of
 distros to pick from .  I love Gentoo but I like to be able to boot up
 without dealing with a init thingy that I have to fix when it goes belly
 up.
 
 Dale
 
 :-)  :-)
 
 -- 
 I am only responsible for what I said ... Not for what you understood or
 how you interpreted my words!
 

The best path for you seems to be a merge of / and /usr. I asked Alan
how to do this since he seemed knowledgeable about it. If he replies,
maybe his advice will be handy and save you a lot of trouble. It seems
clear to me that you want to avoid trouble, but looking at your options,
putting /usr in / is probably the least painful thing you can do, and it
won't require an initramfs. I don't like initramfs's either, but that's
because I'm lazy and don't like maintaining more than two things (kernel
and GRUB config) in order to boot.

Other distros use initramfs's for the most part, and more and more are
using systemd. Gentoo is pretty much one of the last distros that
supports booting without an initramfs and without systemd.

Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01

[Daniel Campbell]

On 09/29/2013 01:55 PM, William Hubbs wrote:
 On Sun, Sep 29, 2013 at 01:55:49PM -0400, Tanstaafl wrote:
 On 2013-09-28 6:36 PM, Alan McKinnon alan.mckin...@gmail.com wrote:
 So this brings us back to the essential technical problem that still
 needs to be solved on your machines:

 /usr needs to be available (and not only for BT keyboards) at the
 earliest possible opportunity - this is a technical constraint. To
 guarantee that, you need to either merge /usr with /, or use an
 initramfs to guarantee that /usr is available before anything else
 happens in userland.

 It*really*  is that simple. If you have a better solution than my last
 two choices, then I am all ears.

 Ok, and if this is all true, I can accept it.
 
 Alan, this is a very good summary of the issues involved. Everyone on
 the list should go and read flameeyes' blog post then this summary.
 
 Tanstaaf,
 
 I am the OpenRC author/maintainer and a member of base-system. I can
 tell you that we are not discussing forcing systemd on everyone in
 Gentoo Linux as a default init system. I can also tell you that I am not
 aware of the Gentoo systemd team discussing this. Even if they were, a
 distro-wide change like this would have to be brought before the
 Council.
 
 William
 

I understand Gentoo has a much more structured way of making decisions
like systemd, but perhaps you aren't the best person to assuage fears. I
say this not because of anything you do, but your position. Arch Linux
used their sysvinit maintainer to calm fears of users before their
switch to systemd. I'm not saying that you are trying to do this at all,
but rather being OpenRC maintainer doesn't add much in the way of
credibility of your stance. Everything else (the lack of discussion on
it, the fact that the Council would have to vote on it) are much better
logical support for systemd not being forced.

I'm not sure if you knew about what happened with Arch, so I just
figured I'd point it out. I and others who switched from Arch to Gentoo
over the systemd debacle still remember the false promises (from the
sysvinit maintainer) that systemd won't be forced, when it was. So one's
position can't really be trusted, regardless of how much I and others
appreciate the work that goes into OpenRC.

No offense is intended, by the way. Just adding some context. I hope you
understand.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] systemd installation location

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/29/2013 02:52 PM, William Hubbs wrote:
 All,
 
 I can clarify one part of the systemd issue, because I have been 
 involved in this part of the issue for months. Again,  I am not
 trying to start a dispute here, just providing a clarification.
 
 The choice to install all of the systemd binaries in /usr is not
 an upstream choice. It was a choice made a year ago when our
 systemd team was one person [1], and now the team doesn't want to
 change it because it would require users to go through a migration,
 and the rest of the team doesn't see a benefit in changing it since
 it still links to libraries in /usr/lib.
 
 I joined the team, primarily to take responsibility for this change
 and to try to make it go as smoothly as possible, but I was
 overruled even though upstream gave us a pretty strong warning
 about it.
 
 William
 
 [1] 
 http://blogs.gentoo.org/mgorny/2012/01/04/moving-systemd-into-usr-the-technical-side/

 
Ouch. So systemd upstream doesn't suggest putting binaries in /usr?
That shows at least a little respect for /bin, et al. Based on the
blog post, I'm getting the feeling that -- for systemd anyway -- the
issues with /usr are caused by its dependencies rather than systemd
itself. If dbus and whatnot were in /bin where they belong, the need
for an initramfs (for separate /usr) and/or dealing with things in a
non-standard place wouldn't need to happen.

I'm not affected by anything regarding the /usr switch, but I'd like
to have a good talk with the first person who decided a
system-critical binary belonged in /usr instead of /bin or /sbin.
They've created a mess for every distro and any project that depends
on their work.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSSMu5AAoJEJUrb08JgYgHFz4H/iyZt6MlTeW702KOlIy2Ydse
mzsfiyPfPz8Rbz0Mqp5/17R8aQzOUG4l6dZS7d9HFKuMCG7t+kNZCSvxD69XeTVO
tZY6YjHCGQaE6WaAMbiasXfRTeRt4ZDtP5l/lCUsYcTCWN13PyIcHCb5rGNHnHqq
J/OcSeF5EoS+G/uSAuzDVaQ5wa0Z0qkqVSqQGjJ5NUHYIA5ZrtYpMNDR+MkFYYAB
7I4JE5kDXRYoBSiLLDb7tI7F1nGogHXxzECmMYW4ZneU0AJwhUAK0kU+oTHY2Z9Q
8TcjpdaG1BH4gA2NT+i+ZJz4XNqkMPa2vbvhcfGFs9Dg7IwabiuunOzh0GQM1S4=
=jgci
-END PGP SIGNATURE-

Re: [gentoo-user] systemd installation location

[Daniel Campbell]

On 09/29/2013 08:17 PM, Mark David Dumlao wrote:
 On Mon, Sep 30, 2013 at 8:54 AM, Daniel Campbell li...@sporkbox.us wrote:
 I'm not affected by anything regarding the /usr switch, but I'd like
 to have a good talk with the first person who decided a
 system-critical binary belonged in /usr instead of /bin or /sbin.
 They've created a mess for every distro and any project that depends
 on their work.
 
 As I've pointed out before:
 - system-critical is actually dependent on the system. A system dependent
on an smb share will find smbmount system critical. One dependent on
zfs-fuse will find fuse system critical. With the advent of fuse, arbitrary
 
 
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.20 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQEcBAEBAgAGBQJSSMu5AAoJEJUrb08JgYgHFz4H/iyZt6MlTeW702KOlIy2Ydse
 mzsfiyPfPz8Rbz0Mqp5/17R8aQzOUG4l6dZS7d9HFKuMCG7t+kNZCSvxD69XeTVO
 tZY6YjHCGQaE6WaAMbiasXfRTeRt4ZDtP5l/lCUsYcTCWN13PyIcHCb5rGNHnHqq
 J/OcSeF5EoS+G/uSAuzDVaQ5wa0Z0qkqVSqQGjJ5NUHYIA5ZrtYpMNDR+MkFYYAB
 7I4JE5kDXRYoBSiLLDb7tI7F1nGogHXxzECmMYW4ZneU0AJwhUAK0kU+oTHY2Z9Q
 8TcjpdaG1BH4gA2NT+i+ZJz4XNqkMPa2vbvhcfGFs9Dg7IwabiuunOzh0GQM1S4=
 =jgci
 -END PGP SIGNATURE-

 
 
 
It's fairly obvious (to me, anyway) that anything mounting a filesystem
and making it available is system-critical. I run samba and don't need
it for boot, but like you said, someone may need that. I wouldn't see a
problem with smbmount being in /bin. FUSE deserves similar treatment.
LVM's another that probably deserves special treatment.

Re: [gentoo-user] systemd installation location

[Daniel Campbell]

On 09/29/2013 08:40 PM, Mark David Dumlao wrote:
 On Mon, Sep 30, 2013 at 8:54 AM, Daniel Campbell li...@sporkbox.us wrote:
 I'm not affected by anything regarding the /usr switch, but I'd like
 to have a good talk with the first person who decided a
 system-critical binary belonged in /usr instead of /bin or /sbin.
 They've created a mess for every distro and any project that depends
 on their work.
 
 (sorry for the previous post, accidentally clicked somewhere onscreen)
 
 As I've pointed out before:
 1) system-critical is actually dependent on the system. A system dependent
  on an smb share will find smbmount system critical. One dependent on
  zfs-fuse will find fuse system critical. With the advent of fuse,
 some filesystem
  that depends on an arbitrary user program will find that system-critical.
  While this works for for 99.(99?)% of user systems out there, FHS
 is supposed
  to be targetting all of them, and so it fails in principle in that 
 respect.
  I remember making a lengthy thread on this mailing list challenging how 
 FHS
  defined this and it appeared that nobody could make a defense.
 2) the reality is, it's not just binaries even. There are some things
 that binaries
 depend on, that in theory should be in /. For example, the hwid database, 
 or
 libraries. Libraries make for a complex problem, because /usr is supposed 
 to
 be network-sharable. Any libraries your programs depend on can't simply 
 just
 be pushed to /, because then there'd be the chance that the
 programs and their
 libraries were not in sync.
Libraries were one of my concerns when I was replying. I thought to
myself, Well damn, won't shared libraries make this even more
difficult? Perhaps it's a case for static-linked core binaries. :)

Anyway, I'm not in favor of FHS _per se_, but it sounds pretty
reasonable to have some semblance of order among where different parts
of a system go. Shoving everything into /usr and symlinking everything
else seems like a stop-gap or good-enough solution that came about due
to ignoring the existing standard (FHS) and refusing to try to change
it. I could be wrong, though. My point is I'm not dogmatic about it; I
just think that if the FOSS community were willing, a better solution
could be crafted.
 
 I made a handful of criticisms to FHS in that thread before, and nobody was
 able to mount a suitable defense. The point being, even in principle, 
 separating
 / and /usr is flaky design at best. That we just so happened to
 accumulate a number
 of packages that are historically installed to /usr is a consequence
 of that. It's not
 even necessarily the fault of the upstream developer, who's not
 supposed to care so
 much which PREFIX they install to, or the distro packager, who can't yet 
 predict
 how the user will tailor their system.
 
 If you were in the shoes of the ebuild packagers, you would be hard-pressed to
 predict which packages belong in the / PREFIX and which ones in /usr PREFIX,
 100 times out of 100. But you need 100 times out of 100 or you'll get
 people whining
 that they can't boot or whining that they need to do some migration. That's
 why / and /usr separation is broken.
 
I agree, but perhaps the / and /usr separation is a symptom of a greater
problem instead of being the problem in and of itself. Like Inception,
maybe we need to go further. :P

Re: [gentoo-user] systemd installation location

[Daniel Campbell]

On 09/29/2013 08:51 PM, Mark David Dumlao wrote:
 On Mon, Sep 30, 2013 at 9:22 AM, Daniel Campbell li...@sporkbox.us wrote:
 It's fairly obvious (to me, anyway) that anything mounting a filesystem
 and making it available is system-critical. I run samba and don't need
 it for boot, but like you said, someone may need that. I wouldn't see a
 problem with smbmount being in /bin. FUSE deserves similar treatment.
 LVM's another that probably deserves special treatment.

 
 If you allow FUSE you've already failed, because arbitrary programs can
 be required by FUSE filesystems. Suddenly your ssh client should be pushed
 to /, or your telnet, or rsync, or ftp.
 
FUSE is that lenient with what it can use to mount with? o_O

Re: [gentoo-user] systemd installation location

[Daniel Campbell]

On 09/29/2013 09:05 PM, Mark David Dumlao wrote:
 On Mon, Sep 30, 2013 at 9:50 AM, Daniel Campbell li...@sporkbox.us wrote:
 Anyway, I'm not in favor of FHS _per se_, but it sounds pretty
 reasonable to have some semblance of order among where different parts
 of a system go. Shoving everything into /usr and symlinking everything
 else seems like a stop-gap or good-enough solution that came about due
 to ignoring the existing standard (FHS) and refusing to try to change
 it. I could be wrong, though. My point is I'm not dogmatic about it; I
 just think that if the FOSS community were willing, a better solution
 could be crafted.
 
 It's true that it's nice to have a semblance of order where different parts 
 go.
 But all libraries and binaries in /usr is also a semblance of order. You 
 don't
 separate stuff for the sake of separating stuff. You separate them because you
 have a good reason to separate them. It turns out that there isn't a good 
 reason
 to separate them, and that there's no way to predictably separate them.
 
 Mushing them together isn't just a stop-gap or good-enough solution. The
 idea of keeping system-critical separate from non-critical was not 
 maintainable
 in the long run to begin with.
 
If separating them was unmaintainable, why bother with /bin and /sbin at
all, then? If /usr is essentially replacing what / was originally, it's
hard to take any filesystem standard seriously and we return to chaos.
What was /usr's original purpose? I'm not really in favor of the
separation or the merging; I'm in favor of what makes sense. For now,
shoving things into /usr is practical because most other software does
it. But that's following a trend. It's become *de facto* standard
instead of a well-designed, well-reasoned standard. If the change to
/usr was brought about because the FHS has holes in it, why not draft a
new FHS completely from the ground up? Sometimes a vast rewrite is
necessary in a standard, and the new standard could address modern
challenges.

 If you were in the shoes of the ebuild packagers, you would be hard-pressed 
 to
 predict which packages belong in the / PREFIX and which ones in /usr PREFIX,
 100 times out of 100. But you need 100 times out of 100 or you'll get
 people whining
 that they can't boot or whining that they need to do some migration. That's
 why / and /usr separation is broken.

 I agree, but perhaps the / and /usr separation is a symptom of a greater
 problem instead of being the problem in and of itself. Like Inception,
 maybe we need to go further. :P
 
 The greater problem is what I'm pointing out already. Even in principle, you
 just can't predict which files belong in /. It's always been a case-by-case,
 system-by-system thing, and it just so happens that 99.9xxx% of the cases
 are the same. Distro packagers, however, have to decide for 100% of the cases.
 So they're going to end up making weird decisions that are easy for you to
 second-guess but are actually tough.
 
 If you want to solve the hard problem, you want to create a tool that
 will automate / and /usr migrations. Portage has to be aware of the tool
 and maybe 100% of ebuilds will have to be rewritten to take advantage of the
 dynamic prefixes set by the tool. That solves it for good, and you can have
 your / and /usr separate. But only for gentoo.
 
 Every package manager needs to have a similar tool and similar intelligence
 for that to work.
 
I agree, but I don't see a tool like that coming up. Enforcing a /usr
merge and in edge cases forcing initramfs is the right *practical*
solution, but I don't think it solves the greater problem, which is
social and organizational. It may not even be a solvable problem, given
how vast and diverse the FOSS world is. But maybe discussion on it can
still be insightful, even if it can't be fruitful.

Re: [gentoo-user] some of the stuff in /usr that's become a problem

[Daniel Campbell]

On 09/29/2013 09:03 PM, Greg Woodbury wrote:
 One of the most obvious things that broke booting with a seperate /usr
 is not GNOMEs fault, but GRUB 2's fault.
 
 the move of /bin to /usr/bin (for things like cp,mv,ln,ls) came after
 the breakage of /usr, but is symptomatic of some distros cavalier
 attitudes to the problem.
 
 /usr/lib/udev.
 /usr/lib/systemd.
 
 were both placed in /usr despite objections from a number of folks.
 
 So claims that udev and systemd are not responsible are not true.
 
 /usr/lib/e2initrd-helper was placed in /usr despite objections.
 /usr/lib/libdevmapper* was moved despite objections...
 /usr/lib/liblvm2* helpers were placed in /usr despite objections...
 
 There were deliberate placements of new or updated libraries in /usr
 that were known ahead of time that would break the use of a separate
 /usr filesystem.
 
 It was pointed out quite plainly at the time, and the placements were
 made anyway, dismissing the concerns are mere historical artifacts or
 clinging to ancient and outmoded traditions.
 
 The *same things* are still being cited (about being outmoded) in
 dismissing concers about forcing useres to adopt technologies they do
 not want to use.
 
I agree with you but I think the distinction made on udev and systemd is
that their *upstreams* didn't suggest they go in /usr. I don't know for
sure since I don't follow systemd and frankly detest it, but if they
said systemd and udev belong in /bin or somesuch, then they can't be
held responsible. The responsibility for that decision falls on the
maintainers, but it's compounded by the dependencies of systemd/udev.
They depend on dbus, which resides in /usr. Was that an upstream
decision or a distro decision? If we follow this dependency tree of /usr
moves, which package was the first to migrate to /usr and begin this
problem? The move to /usr was a social one that started years ago, not a
technical decision made this year. The issue right now is damage control
and, for some, maybe taking a good look at the FHS and deciding what
really makes sense.

Re: [gentoo-user] systemd installation location

[Daniel Campbell]

On 09/29/2013 09:25 PM, Mark David Dumlao wrote:
 On Mon, Sep 30, 2013 at 10:01 AM, Daniel Campbell li...@sporkbox.us wrote:
 On 09/29/2013 08:51 PM, Mark David Dumlao wrote:
 On Mon, Sep 30, 2013 at 9:22 AM, Daniel Campbell li...@sporkbox.us wrote:
 It's fairly obvious (to me, anyway) that anything mounting a filesystem
 and making it available is system-critical. I run samba and don't need
 it for boot, but like you said, someone may need that. I wouldn't see a
 problem with smbmount being in /bin. FUSE deserves similar treatment.
 LVM's another that probably deserves special treatment.


 If you allow FUSE you've already failed, because arbitrary programs can
 be required by FUSE filesystems. Suddenly your ssh client should be pushed
 to /, or your telnet, or rsync, or ftp.

 FUSE is that lenient with what it can use to mount with? o_O
 
 Fuse is filesystems in userspace. The hard problem that isn't obvious
 here, is that
 anybody can come up with a userspace filesystem, and there is ZERO 
 intelligence
 in the package manager that some filesystem is dependent on some userspace
 logic.
 
 for example, there's a filesystem called sshfs. It allows you to view an ssh
 connection as a directory. sshfs itself could be in /, but it depends
 on ssh and its
 libraries, which are normally in /usr. Now what do you do? Just to
 support sshfs,
 you have to move or copy all those programs to /. Portage doesn't know this.
 Ebuilds don't know this. Manual compiles don't know this. What should the ssh
 packagers do? What should the fuse-sshfs packagers do? What should users
 who are manually rolling out sshfs do?
 
 How about when you develop the next revolutionary crazy filesystem that
 allows you to view emacs sessions as directories? What should the emacs
 packagers do? What should the fuse-emacsfs packagers do? What should users
 manually rolling out that do?
 
 You want to automatically version /etc using some filesystem that uses a git
 backend (I'll call it gitfs). What should git packagers do? What
 should fuse-gitfs
 packagers do? etc How about svnfs? hgfs? bzrfs? scpfs? ...
 
Ah, I wasn't aware of how flexible and arbitrary fuse could be. In that
case I'd probably keep it out of /bin for the reasons you outlined. But
that doesn't solve the problem of what if people want to boot with
fuse?. At least, not without an initramfs. And then we've created a
similar problem.

If the proposed solution is all binaries and libraries in the same
root/prefix directory, then why call it /usr? It has little to do with
users if it's nothing but binaries, libraries, etc. In addition, would a
local directory still be under this, for user-compiled programs not
maintained by the PM? Or does that deserve a different top level directory?

Then there's /opt, whose purpose I'm still not sure of. This is
strengthening the idea that something new should be thought up and
drafted. Not necessarily by us at Gentoo, but *somebody*. If I was crazy
and knowledgeable enough I'd volunteer myself.

Re: [gentoo-user] some of the stuff in /usr that's become a problem

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/29/2013 10:13 PM, William Hubbs wrote:
 On Sun, Sep 29, 2013 at 09:21:01PM -0500, Daniel Campbell wrote:
 /usr/lib/udev. /usr/lib/systemd.
 
 were both placed in /usr despite objections from a number of
 folks.
 
 So claims that udev and systemd are not responsible are not
 true.
 
 Udev is installed in / in gentoo. I am a co-maintainer of udev and
 that was fixed quite some time back, it is the Gentoo systemd team
 that installs their version of udev in /usr.
 
 Installing udev or eudev, however, doesn't really solve the issue 
 though, because it is possible to run arbitrary programs from
 within udev rules.
 
 Another unrelated concern is if you install a program in / that
 needs to access something in /usr/share, this will be broken by not
 having /usr mounted. This means that, for example, the locale logic
 of most software can't work without /usr since it accesses files in
 /usr/share/locale.
 
 William
 
I believe you misquoted. Greg said those things; I was merely quoting
him. :)

You're right, though; it's a problem that lots of programs have. I
guess it's the natural result of modular software that has
interdependencies. You basically need *everything* available on boot.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSSPLCAAoJEJUrb08JgYgHFaEH/ietryULwNCbYdoLYFNJXoT1
vjecOzD0nKxY/dN26X5nZfBuuLkN/SARdrk/xqlp7Fw4UKEuP6XwcJWSoP2/o8t7
TxdlbqAAxNGytOpUlqZmJd53c3pivD11PS467Iy4UsRmpH0TbOerqESi9lR+X7bI
OR6ghVpOqkBrNjwNtSREOHjApjQ6h451bGHW2rHUUbOlzoOZYiIBCxBxsCYc/fEc
jS8LbNioj9BeipRFeIAqr+LPhpPDq7KE3EA/tcOb2WT5ro0yy6MAAdoBJSRKiFmI
woSKmEWgFVAa6eGJjTmTRTJjra0L9EWcxHSRDBBNuJTsV1AfMR8stRPD6+FUkaE=
=b8AN
-END PGP SIGNATURE-

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Daniel Campbell]

On 08/19/2013 12:52 AM, Mark David Dumlao wrote:
 On Mon, Aug 19, 2013 at 5:54 AM, pk pete...@coolmail.se wrote:
 On 2013-08-18 23:08, Mick wrote:

 I honestly cannot understand why we/Gentoo are allowing the RHL
 monolithic development philosophy to break what we have.  Is
 Poettering the only developer available to the Linux world?  Are
 RHL dictating what path Debian and its cousin distros should
 follow?

 Problem is that Linux is dependent on udev and udev is in the hands of
 Kay Sievers which also develops systemd together with Lennart
 Poettering which in turn used to be a Gnome developer... With that
 said, what I cannot understand is why people advocating systemd (and
 the kitchen-and-sink model) are using Gentoo in the first place. Are
 they just trying to make the rest of the Linux distro landscape as
 miserable as Fedora? Why don't they stay with Fedora instead of trying
 to turn Gentoo into Fedora?

 
 This kind of response has been repeatedly grating on my nerves
 on this mailing list. It's just so TECHNICALLY WRONG, but more than
 that I feel that it hints at a deeper problem about user attitudes and the
 need to act like a know-it-all that is so prevalent on this mailing list.
 
 Systemd is _not_ a monolithic design. I don't know how anyone who
 has taken even a casual glance at it, or its documentation, can say
 otherwise. It's so reminiscent of qmail or postfix, where you have a
 bunch of small programs each doing one thing well, but for init
 systems rather than for mail, that it's just one step away from being
 the kind of program you show to kids to teach them how to Unix.

It's not monolithic? Okay, then why won't logind work separately after
systemd-206? QED. If you cannot separate its parts and use them
piecemeal, it's monolithic. Period. Separation of concerns within a
project as vast as systemd is to be expected if you want to be able to
read the source. That doesn't mean that systemd isn't monolithic when
used in an actual system. Systemd swallowed udev and is doing whatever
they can to tie logind behavior into the init system to get people to
use it. That's the very definition of monolithic.

 
 Scroll up further on the random systemd rants on this mailing list and
 you'll learn that systemd has a binary / xml configuration format
 (it doesn't, it's plaintext INI, like samba) that requires binary code to
 run daemons (um, no it doesn't), or that thanks to systemd, old,
 perfectly working servers will just stop running...
 
 You know what I think? You can't understand why some people
 like or want to support systemd because you don't _want_ to
 understand. It requires you to learn something new. There's an
 old problem, _mostly_, but not entirely, solved, where we've swept
 the ugly parts out of sight so that they don't bug you. The parts of
 systemd that you don't understand why they should be there
 are the parts that deal with those ugly things you don't want to learn.
 I know that feeling, of being forced to learn something new and thinking
 do I really have to? and I know I hate it. It's the same reason why
 RTFM is considered rude. But it's basically the appropriate response
 here. You wanna figure out why systemd does what it does? RTFM.
 
 Yes, system initialization SHOULD be simple. Just like
 mail or web SHOULD be. And heck, If you want to run some bash
 script to do your web or mail or init, nobody's stopping you.
 
 But somebody, somewhere, is going to want features, which is why
 we have apache or postfix, and what-have-you. And if other projects want
 to use those features, they're free to want to require those software
 as they please. You don't like it? Don't use those projects. Or fork
 them. But stop acting like a pompous know-it-all, quoting software
 design witticisms as if you've actually looked at the problem domain
 even half as seriously as the developers involved.
 
 Oh but systemd is going to eat up all our software so that nothing
 will run without it! Don't be ridiculous. They said that about Emacs,
 Java, Lisp, GNOME, kdepim, The Browser(tm), etc etc etc. If you've
 paid any attention at all to the history of software, it's obvious that it's
 not happening. Why the hell would apache, which runs on windows,
 require systemd? Or firefox? Or google chrome? Or qmail? Or postfix?
 Or MySQL? Or samba? etc etc etc
 
 If there's anything surprising, it's that you seriously thought a software
 development house (cough cough Redhat) wouldn't try to dogfood their
 own stuff into their other products (cough cough GNOME) _which
 already have forks by the way_, so what are you worried about?
 

What he and others are worried about is a single company homogenizing
the distribution landscape, starting at the bottom with the init system.
By making every distro dependent on them for init, they can
systematically homogenize the software ecosystem and kill (mainstream)
FOSS. This would benefit their business immensely. It's hard to deny
that this isn't being attempted 

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Daniel Campbell]

On 08/18/2013 03:53 AM, Alessio Ababilov wrote:
 
 
 
 2013/8/18 Daniel Campbell li...@sporkbox.us mailto:li...@sporkbox.us
 
 On 08/17/2013 02:26 PM, Alon Bar-Lev wrote:
  On Sat, Aug 17, 2013 at 10:22 PM, Andreas Eder
 andreas_e...@gmx.net mailto:andreas_e...@gmx.net wrote:
  On 17 Aug 2013, the guard wrote:
 
  But requiring people to have an initramfs to boot a system
  that doesn't legitimately require it is silly. I don't even
  have /usr mounted separately, but there are many, many
  different system configurations out there and Gentoo is famous
  for supporting a wide variety. That variety is stomped on if
  something like a /usr merge is forced. It also makes building
  your default environment more complicated due to generating an
  initramfs.
 
  Absolutely agreed.
 
  Might be a good time to switch to freebsd :-(
 
  I agree. This is the only escape plan against the new wind of
  dictation into monolithic approach that comes from systemd sponsors
  direction.
 
  Let's see how it turns out... if Linux userspace will become like the
  Windows user space, then freebsd suddenly looks very promising
  alternative.
 
  Regards,
  Alon
 
 
 I've considered this as well. It's simply beyond me why so many people
 are willing to drink the kool-aid from a *single upstream* and let them
 shape the entire GNU/Linux landscape. It's one thing to support an
 *option*, but quite another to *force* users to use this option. Systemd
 itself doesn't look to be forced yet, but if the requirements for it are
 forced onto users, forcing systemd afterwards would be child's play. I
 saw this in action when I used Arch. It started with bash functions in
 their init scripts calling some systemd tools. Then the /usr merge.
 Eventually systemd itself was pushed. I'm beginning to lose confidence
 that Gentoo will avoid the same fate as Arch. Even Debian is falling to
 the systemd crowd. If this keeps up, it's only a matter of time before
 systemd infects every Linux-based distribution and BSD will be the only
 major free OS to avoid it. Red Hat may end up digging its claws into the
 kernel itself. What will protect the Linux landscape, if not distros
 like Gentoo that supposedly support user choice? Will all users who give
 a damn be forced to run LFS or Slackware if they wish to use Linux as
 their kernel? Maintain their own portage|pacman|deb repos and keep
 systems free of systemd? Where does the madness end?
 
 systemd is devouring other daemons. udev was the first victim, and now
 consolekit is dead and replaced with systemd-logind. Who knows what will
 be the next?
 
 Gentoo guys maintain now eudev. Ubuntu (which avoids systemd and uses
 its own upstart) splits systemd into several parts and happily uses
 them. The second way seems to be easier for me.
 
 BTW, what are you arguments against systemd (except for /usr merge)?
 
 Best regards,
 Alessio Ababilov

Systemd has a monolithic design, is headed by an egotist with no respect
for other developers, and cannibalizes other projects. The projects it
can't cannibalize will be strongarmed into irrelevance. Couple this with
Red Hat employees working on both systemd and GNOME, with a very clear
agenda to vertically integrate them, and you have a recipe for a closed
and/or heavily limited operating system. This is becoming clear with the
way GTK+ 3.x is handled, too.

I don't approve of an init system (or any other software) becoming
everything-and-the-kitchen-sink. UNIX philosophy is being forgotten by
these developers, and they openly condemn it while benefiting from it at
the same time. While the job of init could be argued as complex or
multifaceted, an init system can still do one thing, and do it well:
Bring the system to an initial state. At the core, it means populate
sysfs (or an equivalent), start the specified daemons, load the relevant
modules, and standby until an event signals it to shutdown or restart.
No splash screens needed, no need to swallow a device management system,
no need to replace logging mechanisms, and so on.

Coupling systemd with udev was a political move, not a technical one. It
was a deliberate effort to force their software on the FOSS world, with
the false pretense of standardization, which is a buzzword among
developers that's effective at garnering support. The sad part is people
bought it. They will regret this move.

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Daniel Campbell]

On 08/18/2013 09:39 PM, microcai wrote:
 
 在 2013-8-19 上午5:55，pk pete...@coolmail.se
 mailto:pete...@coolmail.se写道：

 On 2013-08-18 23:08, Mick wrote:

  I honestly cannot understand why we/Gentoo are allowing the RHL
  monolithic development philosophy to break what we have.  Is
  Poettering the only developer available to the Linux world?  Are
  RHL dictating what path Debian and its cousin distros should
  follow?

 Problem is that Linux is dependent on udev and udev is in the hands of
 Kay Sievers which also develops systemd together with Lennart
 Poettering which in turn used to be a Gnome developer... With that
 said, what I cannot understand is why people advocating systemd (and
 the kitchen-and-sink model) are using Gentoo in the first place. Are
 they just trying to make the rest of the Linux distro landscape as
 miserable as Fedora? Why don't they stay with Fedora instead of trying
 to turn Gentoo into Fedora?

 Best regards

 Peter K

 
 any one complant to systemd is not a programer. he does not understand how
 bad sysvinit it is from the code point of view..
 
 some one even say the old version is more stable than latest version
 even the author say no and drop the support.
 
 this is all the stupicy of non programer. they think they understand
 progam while in fact no.
 

As a budding programmer I understand that a lot of the functionality
that users take for granted in sysvinit scripts is hacked together and
prone to bash upgrades breaking them, syntax for outside programs to
change, and other auxiliary breakages. This is true of *any* program
that relies on code not written by the author, however, and it is
managed through something called maintenance. All code needs
maintenance or it will eventually cease to work, unless the code that
the programs rely on does not change. It's a fact of life for
programming projects. Some would rather maintain C code than bash
scripts. Nothing wrong with that. I prefer C over bash as well, but it's
not like bash is *terrible*. It's a language that practically any
serious *nix user will know some variant of. Due to this, sysadmins and
users can gain familiarity with sysvinit or other bash-script-using init
systems much faster than with a broad, C-only init system like systemd.
This familiarity means end-users can fix their own problems without
needing to recompile or do backtraces or other higher-level debugging
tasks. This also ensures that the primary init binary stays untouched
and can still bring up a system.

sysvinit may not be perfect, but systemd's approach (Include as much as
possible in one package) is just as bad, if not worse. At least
sysvinit is hackable, which adds to its versatility. Systemd is not free
of good ideas. cgroups can be a useful, optional build-time thing that
Linux users can opt into. Parallel boot sequences can speed up the
booting of a machine that launches many services. The fatal mistake made
from a technical point is that systemd became too ambitious. Taking on a
new feature or a new task in a project has a multiplicative or
exponential effect, *not* an additive one. Given the broad array of
features that systemd has, its purpose is spread too thin and tries to
do too much. It's not simple code and it does too many things.

People often forget that there are other init systems out there, as
well. runit is a great little package, and also uses bash scripts like
sysvinit. It's designed to be lightweight, supports a custom amount of
run levels, and a few extras I'm forgetting. The important thing about
runit is that *it knows what it is*. It's an init system with
service-management added in. It doesn't log things for you, it doesn't
manage your splash screen, it doesn't manage devfs/sysfs, it doesn't
make you coffee and comb your hair, it doesn't take over
security-related tasks. It knows itself and is *happy* to stay focused
on its one job. Because of this, runit and other specialized projects
can focus on being the best it can be on that single task. Compare this
approach to a project that wants to add tons of features or do a little
bit of everything to appeal to the broadest audience possible. This is
literally what systemd does, as a project and as code. It's a yes
project instead of a no project.

Lastly, programmers are not immune to the effects of cognitive biases.
They are just as prone as anyone else to social engineering and
groupthink influencing their decisions. To believe any group is immune
to social misdeeds is foolhardy. This doesn't completely discredit
programmers (or other groups that fall to kool-aid), but it certainly
casts an unfavorable light and earns them suspicion. By asserting that
only the programmers' viewpoints matter, you are forgetting the social
aspects of software development, which are equally important. Without an
audience and users who have good relations with the devs, there's not a
healthy dialogue to enrich the project and make bug fixes, feature
discussions, and so on easier to work 

Re: [gentoo-user] Optional /usr merge in Gentoo

[Daniel Campbell]

On 08/16/2013 07:29 AM, Alessio Ababilov wrote:
 2013/8/13 Canek Peláez Valdés can...@gmail.com mailto:can...@gmail.com
 
 I think it's a great experiment, but perhaps too much work for little
 gain, at least currently.
 
 Thank you! 
 
 The next council meeting will vote if separated /usr without and
 initramfs is officially supported by Gentoo; I hope this time around
 finally is officially and unequivocally stated by the council that a
 separated /usr without an initramfs is *NOT* supported.
 
 As I see
 from http://www.gentoo.org/proj/en/council/meeting-logs/20130813.txt,
 the council has stated that it is not supported anymore.
 
 The usr-merge will be a slow, gradual change; it will probably take
 years. The systemd package entered the tree in June 2011, after more
 than a year in an overlay, and then it took more than two years to
 make it an official alternative to OpenRC. The /usr merge will take a
 similar amount of time, if not longer.
 
 Yes, but systemd is a large important package and it requires changes to
 startup files in other packages, so, it took a lot of time.
 
 As the opposite, /usr merge is easier and, IMHO, it doesn't introduce
 any _obvious_ problems to Gentoo.
 
 2013/8/16 Daniel Campbell li...@sporkbox.us mailto:li...@sporkbox.us
 
 
 Red Hat is only upstream for GNOME and systemd. What they choose to do
 with their distro should not affect the choices of any other distro. I
 see no reason for a /usr merge unless one is using Fedora or wants to
 turn their Gentoo installation into a makeshift Fedora installation.
 This merge should not be forced on Gentoo whatsoever.
 
 
 I would like to ask you to understand my intension. I believe that
 Gentoo is a distro that is famous for providing choises (USE flags and
 so on). /usr merge is also a choise, and I look for volunteers
 and supporters.
 BTW, /usr merge is not just a Fedora's caprice: is is done in Arch this
 year:
 https://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html
 
 
 Sincerely,
 Alessio Ababilov
 Senior Software Engineer
 Grid Dynamics

I'm completely in favor of choice, but only if it doesn't impede on any
other choice(s). If /usr merges are completely optional and only tied to
software that require it (read: systemd), then I'm fine. But requiring
people to have an initramfs to boot a system that doesn't legitimately
require it is silly. I don't even have /usr mounted separately, but
there are many, many different system configurations out there and
Gentoo is famous for supporting a wide variety. That variety is stomped
on if something like a /usr merge is forced. It also makes building your
default environment more complicated due to generating an initramfs.

Arch is following Fedora as they consider them an upstream. They were
one of, if not *the* first non-Fedora distros to ship systemd by
default. They're a poor example. Really, Arch is just Fedora with a
better package manager.

~Daniel

Re: [gentoo-user] Re: Optional /usr merge in Gentoo

[Daniel Campbell]

On 08/17/2013 02:26 PM, Alon Bar-Lev wrote:
 On Sat, Aug 17, 2013 at 10:22 PM, Andreas Eder andreas_e...@gmx.net wrote:
 On 17 Aug 2013, the guard wrote:

 But requiring people to have an initramfs to boot a system
 that doesn't legitimately require it is silly. I don't even
 have /usr mounted separately, but there are many, many
 different system configurations out there and Gentoo is famous
 for supporting a wide variety. That variety is stomped on if
 something like a /usr merge is forced. It also makes building
 your default environment more complicated due to generating an
 initramfs.

 Absolutely agreed.

 Might be a good time to switch to freebsd :-(
 
 I agree. This is the only escape plan against the new wind of
 dictation into monolithic approach that comes from systemd sponsors
 direction.
 
 Let's see how it turns out... if Linux userspace will become like the
 Windows user space, then freebsd suddenly looks very promising
 alternative.
 
 Regards,
 Alon
 

I've considered this as well. It's simply beyond me why so many people
are willing to drink the kool-aid from a *single upstream* and let them
shape the entire GNU/Linux landscape. It's one thing to support an
*option*, but quite another to *force* users to use this option. Systemd
itself doesn't look to be forced yet, but if the requirements for it are
forced onto users, forcing systemd afterwards would be child's play. I
saw this in action when I used Arch. It started with bash functions in
their init scripts calling some systemd tools. Then the /usr merge.
Eventually systemd itself was pushed. I'm beginning to lose confidence
that Gentoo will avoid the same fate as Arch. Even Debian is falling to
the systemd crowd. If this keeps up, it's only a matter of time before
systemd infects every Linux-based distribution and BSD will be the only
major free OS to avoid it. Red Hat may end up digging its claws into the
kernel itself. What will protect the Linux landscape, if not distros
like Gentoo that supposedly support user choice? Will all users who give
a damn be forced to run LFS or Slackware if they wish to use Linux as
their kernel? Maintain their own portage|pacman|deb repos and keep
systems free of systemd? Where does the madness end?

Re: [gentoo-user] Optional /usr merge in Gentoo

[Daniel Campbell]

On 08/13/2013 01:08 PM, Alessio Ababilov wrote:
 
 2013/8/13 the the.gu...@mail.ru mailto:the.gu...@mail.ru
 
 The site doesn't describe any real problems.
 
 Well, it is a question to discuss.
 I am not going to begin a holy war, I would like just to provide a
 possibility to perform a harmless /usr merge for those who share
 FreeDesktop's opinion.
 
 
 Also I don't see how the current dir tree is not compatible
 with gnu autoconf/automake. 
 
 In a simple way: please look at coreutils-8.20.ebuild that has to move a
 lot of binaries from /usr/bin to /bin:
 
 cd ${D}/usr/bin
 dodir /bin
 # move critical binaries into /bin (required by FHS)
 local fhs=cat chgrp chmod chown cp date dd df echo
 false ln ls
mkdir mknod mv pwd rm rmdir stty sync true uname
 mv ${fhs} ../../bin/ || die could not move fhs bins
 
 2013/8/13 pk pete...@coolmail.se mailto:pete...@coolmail.se
 
 So, how would this work for me who have /usr on a separate harddrive?
 
 If you have an initrd, it will work.
 Anyway, I just look for people that are interested in /usr merge.
 
 And what would be the benefit? To me, mentioning Fedora, makes the alarm
 bells go off...
 
 Yes. it does. Fedora is a big distro sponsored by Red Hat and its /usr
 merge will be in RHEL-7. That's not a great idea to fight against
 upstream if it will do /usr merge. Remember, /bin/mail now is moved to
 /usr/bin/mail - what will be the next?
 
 Sincerely,
 Alessio Ababilov
 Senior Software Engineer
 Grid Dynamics
Red Hat is only upstream for GNOME and systemd. What they choose to do
with their distro should not affect the choices of any other distro. I
see no reason for a /usr merge unless one is using Fedora or wants to
turn their Gentoo installation into a makeshift Fedora installation.
This merge should not be forced on Gentoo whatsoever.

Re: [gentoo-user] Moving from old udev to eudev

[Daniel Campbell]

On 08/05/2013 05:12 AM, Anthony G. Basile wrote:
 On 08/04/2013 11:56 AM, Dale wrote:
 Anthony G. Basile wrote:

 I have refrained from flamewars, but I want to reassure people, eudev
 will not be dropped.


 I noticed the other day, posted on this thread by the way, that it left
 beta too.  I'm assuming you are involved in the project so allow me to
 say this:  THANKS MUCH!!

 Dale

 :-)  :-)

 
 I am the current lead.  You may follow the activity here [1].
 
 [1] https://github.com/gentoo/eudev/commits/master
 
If I knew more about detecting hardware and knew more C, I'd gladly join
you in eudev development. As a user all I can offer is a hearty thanks
and a promise to report any bugs that I find. Your work is appreciated!

Re: [gentoo-user] Re: Gentoo is so AWESOME

[Daniel Campbell]

On 07/31/2013 02:05 PM, Michael Palimaka wrote:
 On 1/08/2013 04:34, Michael Orlitzky wrote:
 It seems a little rude to pop in, address them personally, and ask them
 each if they'd devote months of their time towards mentoring me. (Doing
 so can pressure someone into agreeing to something he doesn't want to
 do, or makes him reject you personally which many people find awkward.)
 
 I definitely understand that. I wonder if it would help if we had a page
 where developers could register their interest in being a mentor.
 
 
 
I think that'd be a great idea. If each developer could state where
their interests/expertise laid and what type of dev they'd be interested
in mentoring, that could make the selection process more natural for
both prospective devs and established devs.

The problem I have is I don't know what I'd want to work on. I love vim,
tmux, and fluxbox, but I believe they already have capable maintainers.
I'm learning C and Python, and know PHP, so there's probably a bit I
could learn about C and Python. And my competency in PHP may qualify me
for some packages. Which ones, I don't know.

Overall I just can't think of a reason for Gentoo to take me.

Re: [gentoo-user] gentoo-systemd-only deprecation

[Daniel Campbell]

On 07/30/2013 05:40 PM, Canek Peláez Valdés wrote:
 There is going to be resistance. Two months ago there was a huge
 thread in gentoo-dev, because a package maintaner complained that his
 co-maintainer added a systemd unit to the package:
 
 http://thread.gmane.org/gmane.linux.gentoo.devel/85792
 
 In the end, the maintainer rage-quit:
 
 http://article.gmane.org/gmane.linux.gentoo.project/2551
 
 However, this is the extreme behaviour: most developers (and rational
 people) agree to adding systemd unit files to all packages, and we
 have much better coverage now that some months ago.
 
 If users cooperate opening bugs adding systemd unit files (after
 testing them in their machines), the coverage is going to grow even
 faster.
 
 Regards.
 
 On Tue, Jul 30, 2013 at 5:04 PM,  cov...@ccs.covici.com wrote:
 Canek Peláez Valdés can...@gmail.com wrote:

 On Tue, Jul 30, 2013 at 12:53 PM,  cov...@ccs.covici.com wrote:
 Canek Peláez Valdés can...@gmail.com wrote:

 On Tue, Jul 30, 2013 at 2:47 AM, Pavel Volkov negai...@gmail.com wrote:
 On Tue, Jul 30, 2013 at 11:09 AM, Pavel Volkov negai...@gmail.com 
 wrote:

 On Sunday 28 July 2013 03:22:02 Canek Peláez Valdés wrote:
 Therefore, as of today, anyone can have a Gentoo machine with only
 systemd, with no OpenRC installed.

 Really? Bug 373219 is still open.


 Sorry, I missed your explanation at the end about that one. Ok, thanks 
 for
 what you've done :)

 Mmmh, and I missed this last reply of you.

 Anyway, dealing with /etc/init.d/functions.sh is basically trivial.

 But still, we have lots of packages with no systemd units -- shouldn't
 they all have a systemd use flag and units to go with it -- basically
 anything which has something in /etc/init.d .  I was looking for a
 sendmail unit and could find nothing, for one example.

 Yeah, we are not even near 100% coverage. However, one of the many
 advantages of systemd is that a service unit from a distribution
 usually works as-is or with minimal changes in any other.

 For many basic unit files, you can go to

 https://github.com/vonSchlotzkow/systemd-gentoo-units

 It has a unit file  for postfix, for example. If the one you are
 looking for is not there, you can search in other distributions. If
 you download the RPM from
 http://rpm.pbone.net/index.php3/stat/4/idpl/21317874/dir/fedora_19/com/sendmail-8.14.7-1.fc19.i686.rpm.html,
 and extract the files with rpm2tarbz2, then you can get the
 sendmail.service file.

 It will probably need some changes to work with Gentoo, but it should
 not be difficult.

 When is working, you can send your unit to the package maintainer in
 Gentoo, and at some point it could be included in the package (like
 the OpenRC init script).

 That's how we will get 100% coverage, eventually.

 OK, I will check those -- thanks.  I hope package maintainers now start
 putting those service units in, now that systemd is required by gnome.


 --
 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

 
 
 


What's irrational about that guy's reasons for being against the systemd
unit files? I remember that thread, and he made some decent technical
points. Unfortunately, the council rejected a systemd USE flag, so the
best route was shot in the head before it had a chance. Yet OpenRC needs
a USE flag to enable it... rather fishy.

Re: [gentoo-user] Gentoo is so AWESOME

[Daniel Campbell]

On 07/30/2013 01:16 PM, hasufell wrote:
 And we need MOAR devs
 
 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=2
 https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs
 
 so awesome! srsly!
 
 What many people don't seem to get is: you don't need to be a commit
 monkey doing your 100+ commits per week.
 Our minimum rate of commits is pretty low before you actually are forced
 to retire.
 
 Better have a lot of devs each one focussing on a few packages than
 having few devs working on the entire tree and messing up things randomly.
 
 It's not that much work, just some regular attention. You want to join!
 

I was interested in becoming a dev for a little while, but the testing
and what looks to be prolonged process kinda put me off of the idea. It
just seems like a lot of bureaucratic work. Perhaps my impression is
wrong, though...

Which projects are most in need of developers or maintainers? I wouldn't
mind learning a bit more about package maintenance, portage, and ebuilds...

Re: [gentoo-user] java vs icedtea6

[Daniel Campbell]

On 01/15/2013 11:32 PM, Nilesh Govindrajan wrote:
 On Wednesday 16 January 2013 10:32:11 AM IST, Kevin Brandstatter wrote:
 I'm curious as well about the potential exploitability of icedtea. I
 would think that since the icedtea vm is not the same as the sun/oracle
 one and so I don't think the code base is the same, which would mean an
 exploit in the sun/oracle jvm would not necessarily affect icedtea.
 However, I know very little on this matter and seeing as i think both
 are open sourced i have no idea how much or if there is any code overlap.

 
 Oracle Java is open source?
 
 --
 Nilesh Govindarajan
 http://nileshgr.com
 

I was thinking the same thing. Last I knew, the VM is closed while the
language is pretty much open.

Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[Daniel Campbell]

On 01/11/2013 09:14 AM, Nikos Chantziaras wrote:
 On 11/01/13 16:04, walt wrote:
 This seems to me like very happy news indeed, but I'm interested in
 contrary
 opinions.  There's a recent thread discussing how udev-197 breaks
 lvm2, but
 that's a trivial fix once you know about it.

 The problem is caused because many apps including lvm2 install their udev
 config scripts in /usr/lib/udev/rules.d/ (where they never belonged in
 the
 first place IMO) and they should instead now go in /lib/udev/rules.d/.
 All you need to do is to re-emerge all of those packages *after*
 installing
 udev-197 and the config scripts will go in the correct place.

 You should do this before rebooting the machine because lvm2 won't
 work until
 its udev scripts are in the correct directory.
 
 Running this command (all in one line):
 
 emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do
 echo =$p; done)
 
 should re-emerge all packages that still have files there.  After that,
 /usr/lib/udev should no longer exist.  If it still does, then there are
 files in it that don't belong to any package.  Check them manually and
 delete them as needed or move them over.  Then delete /usr/lib/udev.
 
 

Thanks for the command line tip. I wasn't aware of the /lib/ move and
would've had a handful of problems had I not read the list.