Re: [gentoo-dev] Commented packages in the @system set

[waltdnes]

On Tue, Oct 25, 2016 at 08:05:55AM -0700, Nick Vinson wrote
> Theoretically no.  When autotools is used correctly, the release tarball
> has no dependency on either.  That said, many people don't generate /
> distribute a release tarball.
> 
> However, I don't think this is the criterion used to determine what
> should be in @system.  The wiki defines the system set as the set that
> "contains the software packages required for a standard Gentoo Linux
> installation to run properly".
> 
> That definition definitely excludes automake and autoconf (arguably gcc
> should also excluded, under that definition, so the wiki might not be
> 100% correct).

  A binary distro can get by without gcc.  For that matter, so could a
Gentoo "snapshot".  But my definition of "run properly" includes being
able to update software for new features and security fixes.  For a
build-from-source distro like Gentoo, gcc and associated tools are a
vital part of the distro.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Firefox bloat Was: chromium ...

[waltdnes]

On Thu, Sep 01, 2016 at 02:36:27AM +, Duncan wrote

> FWIW, the australis thing never really affected me much.  I had some
> extensions (and configuration mania guified native options) changing
> the look somewhat before, and have some extensions (and config mania
> options) changing the look somewhat now.  It did take me several hours
> (between configuring and extension browsing) to get the new UI setup
> to something I was comfortable with, but then I'm used to that any
> time I change desktop (kde) major versions as well, and this was a
> comparable change.

  I had always customized Firefox's GUI to my own liking.  When I first
saw the Atrocious^H^H^H^H^H Austraulis gui, I said "No problem", I'll
reconfigure it, like I've always done before".  What really shocked me
was not only the garbage gui, but the fact that you couldn't get a sane
"classic" gui withing Firefox.  The Firefox people obviously knew that
users' first reaction would be to get rid of Australis, so they removed
that ability.

  Extensions soon sprang up that sort of allowed you to go back to a
sane desktop.  But I didn't want to go that far.  Australis was the
breaking point.  Attached is a sample of what the top of my Pale Moon
gui looks like, which is how I used to do Firefax way-back-when.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

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

[waltdnes]

On Thu, Sep 01, 2016 at 03:12:08PM +1200, Kent Fredric wrote
> On Wed, 31 Aug 2016 21:03:34 -0500
> »Q«  wrote:
> 
> >  says it's in Gentoo overlays, but I don't
> > know which ones.
> 
> Tar.bz2's from http://linux.palemoon.org/download/mainline/ are
> working nicely for me as a straight download/unpack/run-in-$HOME

  Or, with root or sudo, you can make Pale Moon global on your system.

rm -rf /usr/local/palemoon
tar -C /usr/local/ -xvjf palemoon.bz2
ln -sf /usr/local/palemoon/palemoon /usr/bin/palemoon

...or in /opt...

rm -rf /opt/palemoon
tar -C /opt/ -xvjf palemoon.bz2
ln -sf /opt/palemoon/palemoon /usr/bin/palemoon

  And there's also the option of cloning the git repository, and
building on your own machine with "-march=native".  I also build a
32-bit version "-march=bonnell" in a VM on my desktop, for use in my
ancient 32-bit-only Atom netbook.  I disable webRTC, gconf+dbus,
pulseaudio, etc. in my personal builds.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] newsitem: openrc runscript transition (draft 3)

[waltdnes]

On Wed, Aug 24, 2016 at 07:32:05PM +1200, Kent Fredric wrote
> On Mon, 22 Aug 2016 17:57:43 -0500
> William Hubbs  wrote:
> 
> > I thought about dropping the version number from the
> > display-if-installed line, but that doesn't make sense because it means
> > that everyone, including all new installs of OpenRC after this version,
> > would have to read the newsitem.
> > 
> > William
> > 
> 
> That concern is in the wrong priority.
> 
> "Your system might break" is more important than "ugh, annoying
> news items"
> 
> Viewing the news item once per clean install is still less of a
> "Problem" than "everyone with an old system syncs, doesn't get any
> warning, upgrades openrc to a version which breaks this, and they
> brick their boot"

  These things get left in forever.  I once filed a bug report
https://bugs.gentoo.org/show_bug.cgi?id=569056 because the warning that
English word lists in vim had been removed was still present *TWO YEARS*
after the fact.

  How flexible is the ewarn option?  Can printing the warning be made
conditional?  I suggest warning only if there are any hits on...

grep -l '^#!/sbin/runscript' /etc/init.d/*

  Note the single-quote around the expression.  Otherwise "#" can be a
special character for grep.  Furthermore, "grep -l" output can be used
to tell the enduser which specific scripts are non-compliant.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] news item: grub2 multislot use flag is being disabled

[waltdnes]

On Mon, Aug 08, 2016 at 09:12:32AM -0500, William Hubbs wrote

> Title: Grub2 multislot use flag is being disabled
> Author: William Hubbs 
> Content-Type: text/plain
> Posted: 2086-01-09

  ?!?!?!?!

> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: >=sys-boot/grub-2
> 
> The multislot use flag in sys-boot/grub-2.x, which has been enabled by
> default, is being disabled.
> 
> This means that, for all new systems, and for anyonewho doesn't take

  Minor typo...
s/anyonewho/anyone who/

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Signed push & clock drift rejection

[waltdnes]

On Tue, Jul 19, 2016 at 10:07:12AM +0200, Chí-Thanh Christopher Nguy???n wrote
> Kent Fredric schrieb:
> > On Mon, 18 Jul 2016 22:21:22 -0400
> > waltd...@waltdnes.org wrote:
> >
> >>I'm amazed that "robust linux servers" are deathly afraid of simply
> >> setting the time, and being done with it.
> >
> > There's problems at the software level everywhere that are not so
> > simply solved.
> >
> > A more obvious example is in the event your system time gets *ahead* of
> > real-time.
> 
> And even if the system is behind time, it can cause problems. cronjobs 
> running unexpectedly close to each other (or missed cronjobs in extreme 
> cases). User sessions expiring early, etc.
> 
> And even if there is only one second, and that is known well ahead
> (e.g. leap seconds): Unless you know that there isn't going to be
> a problem, a great deal of care needs to go into handling that.

  In that case, the dev machine should be a separate machine from the
server.  They don't even have to be separate physical machines.  Do the
dev work in a VM, and set the time in the VM just before doing the push.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Signed push & clock drift rejection

[waltdnes]

On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko wrote
> 
> As I wrote earlier in this thread, ntp server is not a guarantee
> that such problems will not happen. If hardware clocked was
> significantly offset during boot, it may take several _hours_ for
> ntp to fix this via clock skew. Apparantly commit may be made
> during these several hours.

  I'm amazed that "robust linux servers" are deathly afraid of simply
setting the time, and being done with it.  And while we're at it, if a
developer is doing development on a server machine, he may have other
problems to worry about.  At home I occasionally manually run a script
that includes the 2 lines...

/usr/bin/sudo /usr/bin/openrdate -n -s ca.pool.ntp.org
/usr/bin/sudo /sbin/hwclock --systohc

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] RFC: migration from uclibc to uclibc-ng

[waltdnes]

On Sat, Jul 16, 2016 at 01:02:42PM -0400, Anthony G. Basile wrote

> I welcome comment on any of the above.

  I don't know if this is on topic.  Is it possible to backport 64-bit
date/time to uclibc-ng in 32-bit mode?  32-bit date runs between late
1901 and early 2038.  2038 is not that far away.  E.g. in a 32-bit VM...

[g32gst1][waltdnes][~] date --date='@-2147483649'
date: invalid date '@-2147483649'
[g32gst1][waltdnes][~] date --date='@-2147483648'
Fri Dec 13 15:45:52 EST 1901
[g32gst1][waltdnes][~] date --date='@2147483647'
Mon Jan 18 22:14:07 EST 2038
[g32gst1][waltdnes][~] date --date='@2147483648'
date: invalid date '@2147483648'

  64-bit date covers beyond the heat death of the universe each way...

[i3][waltdnes][~] date --date='@-2147483649'
Fri Dec 13 15:45:51 EST 1901
[i3][waltdnes][~] date --date='@-2147483648'
Fri Dec 13 15:45:52 EST 1901
[i3][waltdnes][~] date --date='@2147483647'
Mon Jan 18 22:14:07 EST 2038
[i3][waltdnes][~] date --date='@2147483648'
Mon Jan 18 22:14:08 EST 2038

-- 
Walter Dnes <waltd...@waltdnes.org>
I don't run "desktop environments"; I run useful applications

[gentoo-dev] Multiple occurences of flags in use.local.desc

[waltdnes]

  Another day, another thread about multiple occurences of a flag in
use.local.desc.  Howsabout a serious overall look at the situation?
Start with the following short script...

#!/bin/bash
rm -rf flagcount0.txt
sed "s/:/ /" /usr/portage/profiles/use.local.desc | \
   cut -d \  -f 2 | \
   sort -u > /dev/shm/flags.txt
while read flag
do
   echo -n "${flag} " >> flagcount0.txt
   grep -c ":${flag} " /usr/portage/profiles/use.local.desc >>
flagcount0.txt
done < /dev/shm/flags.txt
sort -n -r -k2,2 flagcount0.txt > flagcount.txt

  The final result is that flagcount.txt has a count, in descending
order, of each flag in use.local.desc.  It does need some manual
cleaning up, which I've done.  It's file-attached.  I've included all
flags with 5 or more occurences, as well as stuff that looks like it is,
or should be, a USE_expand var.  The developers may want to look at the
issue of hyphens versus underscores.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications


flagcount.txt.gz
Description: Binary data

Re: [gentoo-dev] rfc: new global use flag: luajit

[waltdnes]

On Fri, Jul 15, 2016 at 11:23:37PM +0200, Dirkjan Ochtman wrote
> On Thu, Jul 14, 2016 at 4:34 PM, William Hubbs  wrote:
> >> I'd rather avoid adding more of this until we figure out what to do
> >> about multiple Lua versions. The Lua5.1/5.2 split is still stuck
> >> nowhere, and luajit is yet another variant to handle.
> >
> > If we don't do this, the only way to add luajit support to dev-lua/busted 
> > is to
> > propegate the local use flag into all of its dependencies [1], and that is
> > what I'm trying to avoid.
> 
> rspamd has (since [1]) used the jit flag to distinguish between lua
> and luajit for a while. Then, lua is about lua support in general, and
> jit can select between lua and luajit. This is maybe not the best
> solution, but not so bad either, in my view.

  Seamonkey and Firefox both have a "jit" USE flag, which I doubt has
anything to do with lua/luajit.  "lua" and "luajit" appear to be
languages.  They should have flags just like fortran and gcj.  It appear
that the default is "-luajit", and "luajit" turns it on.  BTW...

grep ":luajit " /usr/portage/profiles/use.local.desc | wc -l

...gives 17 hits.  It looks like a good candidate for "globalization".
Note the trailing space.  There are 2 for USE flag "luajittex" for
app-text/texlive-core and dev-texlive/texlive-basic

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [PATCH 2/2] eclass/toolchain-funcs: add clang version functions

[waltdnes]

On Tue, Jul 05, 2016 at 01:08:13AM -0500, Austin English wrote
> 
> My goal is clang support parity with gcc. If you are opposed to these
> sort of checks, then why don't we deprecate and remove those functions?
> I want to know why gcc deserves special treatment, either all compilers
> should have easy way to check major/minor/full versions, or none should.
> Obviously I'm not saying gcc should be removed now, but it could
> certainly be marked deprecated so the usage doesn't spread (hopefully)
> further.

  This is reminiscent of the web-browser situation.  I use Pale Moon.
It's feature-compatible with Firefox, but has not gone berserk with the
version numbering.  The current Firefox is 49-point-something.  Stupid
webpages see Pale Moon 26.3.3 and whine about "out-of-date-web-browser"
and kick the user out.  But if the user sets the user agent (i.e. lies
to the webpage) that he's using Firefox 49.1, it works just fine.

  It's not unique to the current FOS world, either.  Some old MS-DOS
applications would only run when the OS reported a certain narrow range
of versions.  When you updated MS-DOS, some older applications would
refuse to run, even though the newer MS-DOS was perfectly capable of
running it.  Things got so bad that Microsoft introduced the SETVER
command https://support.microsoft.com/en-us/kb/96767 to deliberately
lie about the MS-DOS version number, when queried by specific
applications.

   How is the version checking done?  Does the check parse the file name
of the compiler?  Can we get the GCC and CLANG people to agree to a
common command/parameter that returns a compatibility level for
"version-checking"?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[waltdnes]

On Sat, Jun 11, 2016 at 10:58:35PM +0200, Kristian Fiskerstrand wrote
> On 06/11/2016 10:53 PM, Daniel Campbell wrote:
> > On 06/11/2016 07:48 AM, james wrote:
> >> [snip]
> >>
> >> Good/Bad idea, posting proxy-maintainer questions to gentoo-user?
> >> (recall irc does not work for me). Also, it might just spur on other
> >> users to create/maintain a few packages in their own area of interest.
> 
> There is also a gentoo-proxy-ma...@lists.gentoo.org list for these
> kinds of questions that is likely more appropriate

  And also gentoo-devhelp

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] New global USE flag: webp

[waltdnes]

On Sat, Jun 04, 2016 at 12:45:15PM +0200, Chí-Thanh Christopher Nguy???n wrote
> Suggested description: Add support for the WebP image format
> Currently in use by the following packages:

  Out of sheer curiousity...

grep -i -w webp /usr/portage/profiles/use.local.desc

...returns the same list *PLUS*

dev-lang/php:vpx - Enable webp suppoprt for GD

?!?!?!?!  Is that a typo?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Fri, Jun 03, 2016 at 10:35:45AM -0400, Ian Stakenvicius wrote

> USE=gui is about building the graphical user interface that an
> application offers, when it is optional.  That's it.  What
> dependencies that means and so on have nothing to do with the flag.

  That reasoning may have been valid many years ago when qt was the only
toolkit around.  All GUI-optional apps back then either used qt or wrote
their own primitives directly to X.  Fast-forward to 2016.  You now have
X/Wayland/Mir/qt4/qt5/gtk2/gtk3/fltk/whatever.  If a package can have a
GUI from more than one of the above, you *NEED* to select implementation
type *SOMEWHERE* (make.conf/package.use/profile).  Deal with it.

> You get that use flags are not supposed to represent dependencies
> right, but features of the package??

  Gentoo currently assumes that users are reasonably competent, and that
if they've selected specific graphics libs to be linked to a package,
that they've done it for a reason; i.e. to enable a GUI.

> Think about a wayland system -- there's lots of packages that
> IUSE="X" to build their gui implementation.  If someone wanting
> wayland set USE="-X" then they don't get the gui app even if it'll
> work in wayland just fine.

  If someone wants to run a wayland system, why wouldn't they set
USE="-X -mir wayland" in make.conf in the first place?!?!?

  Here's my problem with USE="gui"... I've set up various packages which
have the gui/no-gui option.  If USE="-gui" overrides USE="X gtk3 qt4 fltk",
then I would have to set USE="gui" *IN ADDITION TO* telling packages
which GUI toolkit to use.  Since I may want some packages GUI, and some
non-GUI, that would be one more USE flag to set in package.use and/or
make.conf.

  The reason for the pushback is that this "feature" would be rammed
down peoples' throats, Poettering-style.  I propose a compromise
solution that both sides should be happy with.  It would require 2 USE
flags, namely "forcegui" and "forcenogui".

  If "forcegui" is set, all optional-GUI apps will be built with GUIs,
regardless of USE="-X -Mir -Wayland -gtk2 -gtk3 -qt4 -qt5".

  If "forcenogui" is set, no optional-GUI apps will be built with GUIs,
regardless of USE="X Mir Wayland gtk2 gtk3 qt4 qt5".

  If USE="-forcegui -forcenogui" is set, things will be as they are
today.  GUIs will be built, or not, depending on what toolkit flags are
set or not set.  Gentoo is about choice.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Thu, Jun 02, 2016 at 04:25:07PM -0400, Ian Stakenvicius wrote
> On 02/06/16 03:42 PM, waltd...@waltdnes.org wrote:
> > On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote
> >>
> >> IMHO, you see this in reverse. the 'gui' useflag would be useful for 
> >> users who don't want to care about X/wayland/mir and do not want to care 
> >> about gtk/qt, they just want windows to be drawn for the applications 
> >> they install -- without, if possible, pulling useless dependencies.
> > 
> >   How, exactly, will the app draw windows without linking against one of
> > X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
> > pike?
> > 
> 
> The "useless dependencies" is the result of one or more of these
> random flags being enabled globally when an end-user just wants to
> make sure they get the GUI built for their apps.

  The original discussion was about global defaults.  If you want
per-app settings, package.use is your friend.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote
> 
> IMHO, you see this in reverse. the 'gui' useflag would be useful for 
> users who don't want to care about X/wayland/mir and do not want to care 
> about gtk/qt, they just want windows to be drawn for the applications 
> they install -- without, if possible, pulling useless dependencies.

  How, exactly, will the app draw windows without linking against one of
X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
pike?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Thu, Jun 02, 2016 at 06:50:59AM +0100, Graham Murray wrote
> waltd...@waltdnes.org writes:
> 
> >   Let me re-phrase my question... is there *ANY* set of circumstances
> > under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> > can be set for a package *WITHOUT* requiring a gui?
> 
> Yes. X/xorg could be needed to incorporate the X Client libraries so
> that X servers can connect to it but not itself have a gui. This
> could, for example, be on a headless server.

  Is it broken right now?  What improvement will we see from having to
add a "GUI" flag?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote

> waltd...@waltdnes.org wrote:
> 
> >   I see this as at least a redundancy, if not a problem.  First, let's
> > look at the general case.  An optional "UI" (User Interface) is also
> > selected...
> > * via the "tools" useflag 78 times in use.local.desc
> > * via the "ncurses" useflag 10 times in use.local.desc.
> > * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
> >   does "ncurses" show up in use.local.desc ???)
> > 
> >  There is no need for an additional "TUI" (Text User Interface) use flag
> > for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
> > "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
> > thing they have in common is a hard-coded dependancy on graphics libs.
> > "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
> > Using any of them tells you enough.  What do we accomplish by requiring
> > one more USE flag?  This will also make dependancy resolution of ebuilds
> > more complex, i.e. slower.  Why?
> 
> Simple regular users don't want to be concerned with choice of toolkit
> for every single package, as long as a GUI is provided.

  Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
make.conf.  This will *FORCE* a gui where applicable.

> Furthermore, this matches the recommended USE flag design where the
> more important flags are provided as feature flags, while specific
> dependency choice flags are minor.

  This is going to require *THREE* levels of flags, with the first one
being totally unnecessary...

Level 1) GUI

Level 2) X or xorg or Wayland or Mir

Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk

  Let me re-phrase my question... is there *ANY* set of circumstances
under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
can be set for a package *WITHOUT* requiring a gui?  I can see any of X
or xorg or Wayland or Mir being a requirement for any of
qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
a GUI of one sort or another.

  I repeat, requiring a "GUI" use flag for GUI apps makes as much sense
as requiring a "TUI" flag for commandline apps.  I hope I'm not giving
people ideas the wrong way.  No I don't want a "TUI" flag either.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Global USE=gui

[waltdnes]

On Wed, Jun 01, 2016 at 05:29:55PM +0300, Mart Raudsepp wrote

> It is meant as a feature based USE flag, as opposed to the "extra dep"
> based USE flags we've been using for this.
> There are a lot of those with USE=gtk right now. In many cases it's
> some little add-on graphical utility for a library, or some graphical
> configuration GUI in addition to command line, or some bigger cases in
> more modular packages that provide multiple frontends, and not all of
> them are graphical, but CLI or TUI (TUI meaning ncurses-based or
> similar).
> Also there are various with USE=X where it's also about that, but X
> isn't the only way to do GUI these days (any gtk3 app that doesn't
> directly use libX11/libxcb/etc themselves natively supports wayland,
> for example).
> 
> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
> available in only one toolkit version. So hence feature based flag, not
> dependency-based.

  I see this as at least a redundancy, if not a problem.  First, let's
look at the general case.  An optional "UI" (User Interface) is also
selected...
* via the "tools" useflag 78 times in use.local.desc
* via the "ncurses" useflag 10 times in use.local.desc.
* for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
  does "ncurses" show up in use.local.desc ???)

 There is no need for an additional "TUI" (Text User Interface) use flag
for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
"GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
thing they have in common is a hard-coded dependancy on graphics libs.
"GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
Using any of them tells you enough.  What do we accomplish by requiring
one more USE flag?  This will also make dependancy resolution of ebuilds
more complex, i.e. slower.  Why?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

[waltdnes]

On Sun, May 29, 2016 at 02:58:03PM +0200, Micha?? Górny wrote
> On Sat, 21 May 2016 11:19:07 -0400
> waltd...@waltdnes.org wrote:
> 
> > 5. An reversed variant of INSTALL_MASK in make.conf, e.g.
> > LOCALE_ALLOW="foo bar fubar"
> > 
> > which would block installing files in /usr/share/locale/* and
> > /usr/share/man/* EXCEPT for...
> > 
> > /usr/share/locale/foo
> > /usr/share/locale/bar
> > /usr/share/locale/fubar
> > /usr/share/man/foo
> > /usr/share/man/bar
> > /usr/share/man/fubar
> 
> This can be accomplished using inclusion/exclusion logic included in
> the patches I've recently sent for Portage.
> 
>   INSTALL_MASK="/usr/share/locale -/usr/share/locale/foo"

  Thanks.  localepurge cleans up after the fact.  Your patches would
prevent the problem in the first place, which is a better approach.  It
also handles systemd files and can be used when some new stuff comes up
in future that we haven't thought of yet.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[waltdnes]

On Fri, May 27, 2016 at 05:21:06PM +0300, Mart Raudsepp wrote

> This would ideally not be needed, as the package would instead be
> slotted and parallel installable for gtk2 and gtk3, which should be
> theoretically possible in all cases, because gtk2 and gtk3 may not live
> in the same process, so not the same library either.
> Due to some packages needing too much manpower effort to do such a
> split, USE flags are used in such a case.
> Good examples of such slot splits existing are for example the
> libappindicator stack. This used to be the case with almost all GNOME
> libraries as well, but most of them only provide gtk3 now, as gtk2 is,
> well, dead.

  What at the original gtk+, for which the "gtk" flag was probably
originally invented?

[i3][waltdnes][~] ls /usr/portage/x11-libs/gtk+/*.ebuild
/usr/portage/x11-libs/gtk+/gtk+-1.2.10-r13.ebuild
/usr/portage/x11-libs/gtk+/gtk+-2.24.28-r1.ebuild
/usr/portage/x11-libs/gtk+/gtk+-2.24.29.ebuild
/usr/portage/x11-libs/gtk+/gtk+-2.24.30.ebuild
/usr/portage/x11-libs/gtk+/gtk+-3.16.7.ebuild
/usr/portage/x11-libs/gtk+/gtk+-3.18.7.ebuild
/usr/portage/x11-libs/gtk+/gtk+-3.18.9.ebuild

> tl;dr and my proposal would be the following:
> 
> * USE=gtk means providing support for GTK+; because we don't have a
> USE=gui, this also means "provide a GUI version built on top of gtk+"
> for packages where a GUI is optional.

  There is a way to specify a GUI...

[i3][waltdnes][~] grep "^\(X \|wayland \)" /usr/portage/profiles/use.desc
X - Add support for X11
wayland - Enable dev-libs/wayland backend

  If overloading the meaning of USE="gtk" is the problem, the better
solution would be to use "X" or "wayland" or whatever to indicate the
GUI you need.  "gtk" is a relic from the days of gtk+-1.x, when there
were no other versions of gtk.  With the advent of multiple versions, we
arguably need "gtkn" useflags for every version in the tree, where "n"
is the major version #.

  While we're at it, why are there 23 occurences of the "X" useflag in
/usr/portage/profiles/use.local.desc when it exists in
/usr/portage/profiles/use.desc ???  I'm talking about stuff like...

app-misc/vifm:X - Add support for X11
dev-libs/m17n-lib:X - Builds the Graphical User Interface API and
utilities for the package.
dev-libs/wlc:X - Enable X11 backend and XWayland support.
dev-python/PyQt4:X - Build bindings for the QtGui module
dev-python/pyside:X - Build QtGui and QtTest modules

-- 
Walter Dnes <waltd...@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

[waltdnes]

On Sat, May 21, 2016 at 09:41:28AM +0200, Micha?? Górny wrote

> I see the following possibilities:
> 
> 1. We start explicitly listing linguas_* in all ebuilds, no matter how
> tiny they are. Maintainers are required to keep IUSE up-to-date
> and users are forced to rebuild a lot. This is also a QA violation
> in terms of invalid use of USE flags.
> 
> 2. We hack-unset LINGUAS in ebuilds. This is a lot of effort, easy to
> miss and probably would need to repeated for every single phase anyway
> due to how global variables are handled in PMS. Additionally, it may
> break at some point since those variables are likely expected to be
> read-only anyway.
> 
> 3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds have
> a good reason to use flags for localization, we introduce a new,
> non-colliding USE_EXPAND for that. We also ask users to replace LINGUAS
> with the new flag in their make.conf files. LINGUAS gets the original
> upstream behavior back, and we eventually discourage it in favor of new
> INSTALL_MASK features (WiP) [2].
> 
> 4. We fix build systems not to do magic depending on whether LINGUAS
> is unset or set-to-empty. Instead, we could some special special value
> like '-' to signify not installing localizations at all. But that's
> upstream thing to do, and breaks backwards compatibility with existing
> systems disabling localizations.
> 
> 
> Your thoughts?

5. An reversed variant of INSTALL_MASK in make.conf, e.g.
LOCALE_ALLOW="foo bar fubar"

which would block installing files in /usr/share/locale/* and
/usr/share/man/* EXCEPT for...

/usr/share/locale/foo
/usr/share/locale/bar
/usr/share/locale/fubar
/usr/share/man/foo
/usr/share/man/bar
/usr/share/man/fubar

6. Integrate localepurge into Portage, and run it post install

  There are some lazy programmers out there who *DO NOT* respect the
LINGUAS setting, and splatter files throughout /usr/share/locale/* and
/usr/share/man/* regardless.  That's the reason "localepurge" was
written in the first place.  Any proposed solution should take that
problem into consideration, and handle it too.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] What is the procedure for requesting a new eselect module?

[waltdnes]

On Mon, May 09, 2016 at 04:17:06PM +0200, Ulrich Mueller wrote
> >>>>> On Mon, 9 May 2016, waltdnes  wrote:
> 
> >   I've cobbled together a bash script that resembles an eselect
> > module, to list/set cpu speeds on my netbook and notebook. It may be
> > useful to a lot of other people. The script is a bit ugly looking,
> > but it has done the job for me for several months. Some may prefer
> > to treat it as "proof of concept" and do a re-write in python or C
> > or whatever. Given its function, it seems logical to make it an
> > eselect module. Anyhow, what is the procedure to follow up this
> > idea?
> 
> We have a developer guide:
> https://wiki.gentoo.org/wiki/Project:Eselect/Developer_guide

  Thanks for the pointer.  I see that modules are stored in directory
/usr/share/eselect/modules/ with a ".eselect" extension.  Nice to have
a bunch of working examples.  I'll modify my script to module format.

  Should I email you offline when I'm finished?  One
cpu-governor-related question, is there any real difference between...

"powersave" governor versus
"userspace" mode with the lowest speed selected?

  Similarly is there any real difference between...

"performance" governor versus
"userspace" mode with the highest speed selected?

-- 
Walter Dnes <waltd...@waltdnes.org>
I don't run "desktop environments"; I run useful applications

[gentoo-dev] What is the procedure for requesting a new eselect module?

[waltdnes]

  I've cobbled together a bash script that resembles an eselect module,
to list/set cpu speeds on my netbook and notebook.  It may be useful to
a lot of other people.  The script is a bit ugly looking, but it has
done the job for me for several months.  Some may prefer to treat it as
"proof of concept" and do a re-write in python or C or whatever.  Given
its function, it seems logical to make it an eselect module.  Anyhow,
what is the procedure to follow up this idea?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Reminder: ALLARCHES

[waltdnes]

On Wed, May 04, 2016 at 04:05:50PM -0400, Ian Stakenvicius wrote
> On 04/05/16 03:43 PM, waltd...@waltdnes.org wrote:
> > 
> > emerge --keyword-write
> > 
> > ... similar to "emerge --autounmask-write", but have it write to
> > package.accept_keywords, rather than package.unmask?
> > 
> >   That would achieve the effect that people are looking for, with less
> > work.
> > 
> 
> 
> --autounmask-write modifies package.mask, package.accept_keywords and
> package.use already, FYI -- has done so since its inception so far as
> I'm aware..

  The emerge man page does mention unmasking packages and setting
package.use with --autounmask, but not keywords

--autounmask [ y | n ]
   Automatically unmask packages and generate package.use  settings
   as  necessary to satisfy dependencies.

***BUT***

--autounmask-unrestricted-atoms [ y | n ]
  If --autounmask is enabled, keyword and mask changes using  the
  ´=´  operator  will be written

  This is confusing, to say the least.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Reminder: ALLARCHES

[waltdnes]

On Tue, May 03, 2016 at 09:46:10PM -0700, Matt Turner wrote
> On Tue, May 3, 2016 at 5:50 PM, Mike Gilbert  wrote:
> > On Tue, May 3, 2016 at 5:34 PM, Jeroen Roovers  wrote:
> >> The solution is to have people with an actual interest in a specific
> >> architecture determine whether stabilising a package is viable, and
> >> taking sensible action, like dropping stable keywords where applicable.
> >
> > If these people do not actually exist or are not doing their job by
> > culling the depgraph appropriately, we should really drop a number of
> > archs from "stable" status.
> 
> I mostly agree, modulo the comment about people "doing their jobs".
> Arch testing completely sucks.
> 
> Having built many stages for an "unstable" arch (mips) has taught me
> one thing: it's awful being unstable-only. There's no end to the
> compilation failures and other such headaches, none of which have
> anything at all to do with the specific architecture.
> 
> Short of adding a middle level ("stable, wink wink nudge nudge") where
> things at least compile, I think the current situation is actually
> significantly better than the alternative of dropping them to
> unstable.

  Matt points out a problem with the current situation.  There are
basically 2 levels of unstable...

1) Ancient or really new stuff that doesn't compile, let alone run, in
the presence of current libraries.

2) Stuff that actually works, but the devs have not stabilized it yet.

  People who accept unstable ~arch generally want the second group, but
going all out ~arch brings in builds from the first group, which breaks
systems.  The way to get "the best of both worlds" is to start with
stable, and only keyword stuff that you need, which is hopefully in the
second group.  That can get painfull with multiple dependancies,
requiring re-iterative multiple runs and keywording.  Can I make a
suggestion here?  Is it possible for the devs to come up with with...

emerge --keyword-write

... similar to "emerge --autounmask-write", but have it write to
package.accept_keywords, rather than package.unmask?

  That would achieve the effect that people are looking for, with less
work.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Is X86 uclibc environment supported?

[waltdnes]

On Mon, May 02, 2016 at 04:04:46PM -0400, Anthony G. Basile wrote
> On 5/2/16 2:37 PM, waltd...@waltdnes.org wrote:
> > On Mon, May 02, 2016 at 10:37:45AM -0400, Ian Stakenvicius wrote
> >> On 29/04/16 09:34 PM, waltd...@waltdnes.org wrote:
> >>> On Fri, Apr 29, 2016 at 08:19:53PM -0400, Anthony G. Basile wrote
> >>>
>  1) i support uclibc across many arches. see
> 
>  https://wiki.gentoo.org/wiki/Project:Hardened_uClibc
> 
> 
>  2) you can file uclibc bugs and i will look at them.  i know about that
>  one and i've got the fix upstream.  its going slowly because the bug was
>  in libcheck which is bundled with gstreamer and so there's layers of
>  backporting.  see
> 
>  https://bugs.gentoo.org/show_bug.cgi?id=577312
> >>>
> >>>   Thanks.  For the time-being, I'll try building Pale Moon without HTML5
> >>> video support.  It may turn up other problems.
> >>>
> >>
> >>
> >> If you needed this for Firefox, grab 45.x or 46.0 since you can get
> >> HTML5 support from ffmpeg directly without needing gstreamer.
> > 
> >   Firefox's "Australis" can best be described as "the systemd of GUI's".
> > It's what drove me away from Firefox to Pale moon, in the first place,
> > and I'm not going back.
> > 
> >   I understand that Anthony is frustrated with uclibc, and is working on
> > replacing it with the uclibc-ng fork in the uclibc stage 3.  I've run
> > into other issues, besides gstreamer, in uclibc.  Hopefully, uclibc-ng
> > will have fewer issues.  For now, I'll simply wait until the uclibc-ng
> > stage 3 comes out.
> > 
> 
> Yes, I am frustrated with uClibc and I'm just one package and a few
> stabilizations away from switching to uclibc-ng.  The problem is that
> upstream is very far behind in patches, and even further behind in
> releases.  So you submit a patch and you don't even know if it will
> apply cleanly because its in a queue of submissions that have not even
> hit git master/HEAD.  Or you want to back port a fix to the 0.9.33
> branch and there's a dozen other intermediate patches that have to be
> applied first.  Since these patches really address other issues, you're
> cutting and pasting code.  Its a mess.

  Let me know offline if/when you need a beta tester.  I have QEMU and
an ancient 32-bit-only Atom netbook that could really use a smaller
libc.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Is X86 uclibc environment supported?

[waltdnes]

On Mon, May 02, 2016 at 10:37:45AM -0400, Ian Stakenvicius wrote
> On 29/04/16 09:34 PM, waltd...@waltdnes.org wrote:
> > On Fri, Apr 29, 2016 at 08:19:53PM -0400, Anthony G. Basile wrote
> > 
> >> 1) i support uclibc across many arches. see
> >>
> >> https://wiki.gentoo.org/wiki/Project:Hardened_uClibc
> >>
> >>
> >> 2) you can file uclibc bugs and i will look at them.  i know about that
> >> one and i've got the fix upstream.  its going slowly because the bug was
> >> in libcheck which is bundled with gstreamer and so there's layers of
> >> backporting.  see
> >>
> >> https://bugs.gentoo.org/show_bug.cgi?id=577312
> > 
> >   Thanks.  For the time-being, I'll try building Pale Moon without HTML5
> > video support.  It may turn up other problems.
> >
> 
> 
> If you needed this for Firefox, grab 45.x or 46.0 since you can get
> HTML5 support from ffmpeg directly without needing gstreamer.

  Firefox's "Australis" can best be described as "the systemd of GUI's".
It's what drove me away from Firefox to Pale moon, in the first place,
and I'm not going back.

  I understand that Anthony is frustrated with uclibc, and is working on
replacing it with the uclibc-ng fork in the uclibc stage 3.  I've run
into other issues, besides gstreamer, in uclibc.  Hopefully, uclibc-ng
will have fewer issues.  For now, I'll simply wait until the uclibc-ng
stage 3 comes out.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Is X86 uclibc environment supported?

[waltdnes]

On Fri, Apr 29, 2016 at 08:19:53PM -0400, Anthony G. Basile wrote

> 1) i support uclibc across many arches. see
> 
> https://wiki.gentoo.org/wiki/Project:Hardened_uClibc
> 
> 
> 2) you can file uclibc bugs and i will look at them.  i know about that
> one and i've got the fix upstream.  its going slowly because the bug was
> in libcheck which is bundled with gstreamer and so there's layers of
> backporting.  see
> 
> https://bugs.gentoo.org/show_bug.cgi?id=577312

  Thanks.  For the time-being, I'll try building Pale Moon without HTML5
video support.  It may turn up other problems.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

[gentoo-dev] Is X86 uclibc environment supported?

[waltdnes]

  I'm currently trying to get a 32 uclibc environment working in a QEMU
VM.  My eventual goal is to get my ancient 32-bit-only Atom netbook
working under uclibc.  Is it worth bothering to file bugs for stuff that
builds under glibc, but fails under uclibc?  Or should I forget it?  If
it's not supported, there's no point in bugging the developers.

  E.g. gstreamer-1.6.3 builds under glibc, but under uclibc...

In file included from 
/var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check_error.c:25:0:
/usr/include/string.h:386:14: error: conflicting types for 'strsignal'
 extern char *strsignal (int __sig) __THROW;
  ^
In file included from 
/var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check_error.c:21:0:
/var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/libcompat.h:104:24:
 note: previous declaration of 'strsignal' was here
 CK_DLL_EXP const char *strsignal (int sig);
^
Makefile:672: recipe for target 'libcheckinternal_la-check_error.lo' failed
make[5]: *** [libcheckinternal_la-check_error.lo] Error 1
make[5]: *** Waiting for unfinished jobs
In file included from 
/var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check.c:23:0:
/usr/include/string.h:386:14: error: conflicting types for 'strsignal'
 extern char *strsignal (int __sig) __THROW;
  ^
In file included from 
/var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check.c:21:0:
/var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/libcompat.h:104:24:
 note: previous declaration of 'strsignal' was here
 CK_DLL_EXP const char *strsignal (int sig);
^


-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[waltdnes]

On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote

> It was simply a recognition that we were already in a state where
> booting a system without /usr mounted early can cause problems.

  For certain edge cases... yes.  But they were already using initramfs
or merging /usr into /.  I'm talking about the 95% who don't really need
it.

> I never really got the mentality that using an initramfs is a burden.

  One more piece of software that can go wrong.  You have to
maintain+configure it; e.g. sync software and library versions with
what's on the rest of the system.

> An initramfs is just a secondary bootloader for userspace.  I almost
> always use them even if I'm just booting a VM with a single partition
> on it.  If something goes wrong you can fall back to a shell in the
> initramfs and it is like having a rescue disk built into your system
> disk.

  There is single-user mode for rescue.

> For a more complex setup it is much more robust than relying on
> the kernel to find your root, and it also lets you build with a more
> module-based kernel, which has some benefits as well even if you build
> kernels tailored to each host.

  I have "Production" and "Experimental" entries in my LILO menu.  A new
kernel is always set up as the "Experimental" entry.  After running
several days without problems, I run a script which copies the data from
the "Experimental" portion to "Production".

  The only time my system had problems "finding root" was years ago when
the switch from /dev/hd* to /dev/sd* took place.  The "Experimental"
boot with the new kernel died.  I booted "Production", read the mailing
list, changed "hd" to "sd" for the "Experimental" entry, and rebooted.
After several days without problems, I made the same change to the
"Production" entry, and copied the "Experimental" portion to
"Production".

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[waltdnes]

On Fri, Apr 08, 2016 at 11:59:09PM -0400, Damien Levac wrote
> 
> >  Seriously... how many people run Bluetooth keyboards on Gentoo
> >  anyways?
> 
> That you ask such a question is concerning to me. Are we
> discriminating against normal desktop users now?

  Here's the item that really bugs me...

before - many people successfully used separate /usr, without initramfs.
A few edge cases, e.g. people with bluetooth keyboards, had to use
initramfs if they wanted a separate /usr.  The poor darlings felt left
out because they had to do extra setup work, versus the other 95%.

now - an arbitrary decree comes down that *EVERYBODY* who wants a
separate /usr needs to have initramfs.

* IT DOES NOT MAKE THINGS ANY EASIER FOR THE ORIGINAL 5% EDGE CASES *.
But the other 95% who could run separate /usr are now being told they
must run initramfs "just because".  What does it accomplish?

BTW, I'm still running a separate /usr without initramfs, and no related
problems; thank you.  If I decided to go to an edge-case setup (e.g.
Bluetooth keyboard, or ell partitions encrypted) then I could understand
being asked to run initramfs.

This is reminiscent of the "Mozilla Mentality", where everybody is
forced to the lowest common denominator.  Yes, a desktop GUI sucks on
a tablet/smartphone; I get it.  So Firefox was saddled with the
smartphone-oriented Atrocious^H^H^H^H^H^H Australis GUI, which sucks
on a desktop.  That was the last straw that drove me to Pale Moon.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[waltdnes]

On Fri, Apr 08, 2016 at 04:30:04PM -0400, Rich Freeman wrote

> Half the reason we don't officially support running without /usr
> mounted during early boot is that if we actually put everything in /
> that could conceivably be needed during early boot we'd end up with
> everything there.  Bluetooth keyboards is a common example.  The
> console should work during early boot, right?

  Seriously... how many people run Bluetooth keyboards on Gentoo anyways?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[waltdnes]

On Fri, Apr 08, 2016 at 04:18:58PM -0400, Joseph Booker wrote
> 
> From my own experience, it is useful to run "ifconfig" or "mount"
> as a regular user, same as the gimp or firefox commands. Given that
> all the commands you listed are in /usr/bin or /bin, I think I'm
> not the only one.  The difference between "system software" and
> "regular applications" isn't clear-cut.

  Let me rephrase that... instead of calling it "system software", let's
call it "software that the system needs for its own purposes".  Whether
end users run them later is beside the point.  Systems will boot, mount
disks, and set TCP/IP connections fine without GIMP or Firefox.  Not so
much without mount and ifconfig/ifcfg.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[waltdnes]

On Fri, Apr 08, 2016 at 09:20:19AM -0500, William Hubbs wrote
> 
> Here is more info about the split and why it exists. It turns out it hs
> nothing to do with system admininistration or permissions.
> 
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
> http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split/
> https://news.ycombinator.com/item?id=3519952
> 
> In short, this is all a historical artifact with justifications thought
> up after the fact.

  The historical reasons may or may not exist any longer.  The question
is "what is the current situation?".  The current situation is that
there are 3 classes of software...
1) system software that is required for bootup (mount, init, etcetera)
2) system software that is usually used by root for admin purposes
3) regular applications that users use

  Question... do we really want "GIMP", "Firefox", etcetera, in the same
directory as "mount", "chroot", "login", "passwd", "ifconfig", etcetera?
I don't think so.  I want separate "system progs" versus "user progs"
directories.  There may be an argument for merging /bin and /sbin
directories (items 1 and 2 above), but user applications should be
separate.  If we move /bin and /sbin into /usr/bin, I suggest moving all
user programs to /usr/local/binuser applications should be separate.  If
we move /bin and /sbin into /usr/bin, I suggest moving all user programs
to /usr/local/bin.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[waltdnes]

On Wed, Apr 06, 2016 at 12:15:58AM -0400, Richard Yao wrote


> If others are not willing to be advocates for ***THOSE USERS THAT WOULD
> ONLY MAKE THEMSELVES KNOWN AFTER AN A FUNDAMENTAL CHANGE HAS BEEN MADE
> AND PEOPLE ARE DETERMINED TO GO AHEAD WITH THIS***, I suggest having
> and testing a plan for backing out the change should the backlash
> from users after systems break be more than people can stomach. This
> is not the sort of change we should make without an "exit strategy".

  The problem is that those end users didn't know about it until it they
read the news item during an emerge.  That is why they "would only make
themselves known after a fundamental change has been made".  There are a
couple of alternatives...

a) tell all end-users that they should regularly monitor this list.  The
disadvantage is that you probably don't want to be flooded with
questions from newbies on this list.

b) ask on the Gentoo-user mailing list... ***BEFORE MAKING A DECISION
AND INVESTING ANY WORK IN A MAJOR CHANGE***

  Otherwise, you end up with a scenario similar to the following "fair
use" snippett from "The Hitch Hiker's Guide To The Galaxy" series...



ARTHUR DENT:
Didn't anyone consider the alternatives?

MISTER PROSSER:
There aren't any alternatives! But you are quite entitled to make any
suggestions or protests at the appropriate time!

ARTHUR DENT:
Appropriate time?

MISTER PROSSER:
Yes.

ARTHUR DENT:
The first I knew about it was when a workmen arrived at the door
yesterday.

MISTER PROSSER:
T- oh!

ARTHUR DENT:
I asked him if he'd come to clean the windows and he said he'd come to
demolish the house! He didn't tell me straight away of course. Oh no.
First he wiped a couple of windows and charged me a fiver. Then he told
me.

MISTER PROSSER:
But Mister Dent the plans have been available in the planning office for
the last nine months!

ARTHUR DENT:
Yes! I went round to find them yesterday afternoon. You'd hadn't exactly
gone out of your way to pull much attention to them have you? I mean,
like actually telling anybody or anything.

MISTER PROSSER:
The plans were on display.

ARTHUR DENT:
Ah! And how many members of the public are in the habit of casually
dropping around the local planning office of an evening?

MISTER PROSSER:
Er - ah! 

ARTHUR DENT:
It's not exactly a noted social venue is it? And even if you had popped
in on the off chance that some raving bureaucrat wanted to knock your
house down, the plans weren't immediately obvious to the eye were they?

MISTER PROSSER:
That depends where you were looking.

ARTHUR DENT:
I eventually had to go down to the cellar!

MISTER PROSSER:
That's the display department.

ARTHUR DENT:
With a torch!

MISTER PROSSER:
The lights, had# probably gone.

ARTHUR DENT:
So had the stairs!

MISTER PROSSER:
Well you found the notice didn't you?

ARTHUR DENT:
Yes. It was on display in the bottom of a locked filing cabinet, stuck
in a disused lavatory with a sign on the door saying "Beware of the
Leopard". Ever thought of going into advertising? 

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

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

[waltdnes]

On Wed, Feb 10, 2016 at 12:09:58AM -0500, Mike Frysinger wrote
> On 09 Feb 2016 22:39, Duncan wrote:
> > Mike Frysinger posted on Tue, 09 Feb 2016 14:26:52 -0500 as excerpted:
> > > On 08 Feb 2016 13:46, Micha?? Górny wrote:
> > >> I'm strongly against this, because:
> > > 
> > > agreed.  i also don't see any reasons in Patrick's e-mail to suggest the
> > > current default is inadequate.  "i don't like upstream" isn't relevant.
> > 
> > I'd agree, except that the way we're running udev is strongly discouraged 
> > and generally not supported by upstream, with a statement that it /will/ 
> > break in the future, it's simply a matter of time. 
> 
> start a thread then when that actually happens

  The problem with that approach is that all at once the Gentoo forum
will be hit with questions by a whole bunch of people who will have to
migrate to either eudev or systemd on a short deadline.  As the old
saying goes, an ounce of prevention is worth a pound of cure.  I believe
that the best way to handle a crisis is to prevent it in the first
place.  That means getting into a lifeboat before standalone udev sinks.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

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

[waltdnes]

On Tue, Feb 09, 2016 at 03:47:34PM -0800, Daniel Campbell wrote

> I think the only people who can rightfully complain about lack of
> attention or coverage are those who are using these lesser-known or
> lesser-used systems. Maybe we can get some users to step up to the
> plate and contribute to the documentation.

  See https://wiki.gentoo.org/wiki/Mdev and
https://wiki.gentoo.org/wiki/Mdev/Automount_USB

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

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

[waltdnes]

On Mon, Feb 08, 2016 at 08:15:42PM -0500, Alex McWhirter wrote

> As far as upstream support for eudev goes, consider that we are
> currently breaking out udev for use with openrc. There may still be
> loose support for this now, but when udev is not longer able to be
> separated from systemd it's guaranteed that support for this kind of
> configuration will be dropped.

  I think the whole point of eudev is that Anthony here, rather than
Lennart at Redhat, is "upstream".  Stop looking at the Redhat people as
"upstream" for eudev.  They're doing their best to break it.  I don't
know how many of you are old enough to remember the dirty tricks that
Microsoft pulled when IBM was running Windows 3.1 inside OS/2.  One
minor tweak, and Windows 3.11 broke inside OS/2.  Lennart and company
are actively hostile to us, and Gentoo risks annihilation and/or
absorption into the systemd Borg, if we consider the systemd people as
our "udev upstream".

  eudev is an independant fork, and should stand on its own.  I
currently use Pale Moon web browser, which is an independant fork of
Firefox.  Look Ma, no Atrocious^H^H^H^H^H^H^H^H Austraulis GUI.  Because
it's an independant fork, Firefox can shut down altogether, and Pale
Moon will keep going.  That's the model I want eudev to follow.

> So with that being said, I'm all for making eudev default as the only
> other option would be making systemd default which is a completely
> different discussion. One or the other will likely have to happen at
> some point.

  How difficult would it be to make it an install-time choice, like the
bootloader?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[waltdnes]

On Thu, Jan 21, 2016 at 07:51:51PM -0500, Michael Orlitzky wrote
> On 01/21/2016 05:41 PM, waltd...@waltdnes.org wrote:
> > 
> >   Maybe we should start a "gentoo-ebuilds" mailing list to help regular
> > users learn the ins and outs of making ebuilds.
> 
> Try gentoo-devhelp@lists.g.o, or the associated #gentoo-dev-help on IRC.
> 
> We should be trying to get these things proxy maintained at least since
> they don't do anyone else any good in a personal overlay.

  Thanks for the pointer to gentoo-devhelp.  I'll try that list.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Re: [RFD] Adopt-a-package, proxy-maintenance, and other musings

[waltdnes]

On Sat, Jan 23, 2016 at 10:54:01PM +0300, Andrew Savchenko wrote

> Please make this optional. Elog already contains too much information
> and it is already hard to read logs after world update or other
> massive change. It literally takes hours sometimes.

  Agreed 100%.  I filed a successfull bug request last month to remove
the "ewarn" about English word lists being dropped from default vim
install 2 years ago https://bugs.gentoo.org/show_bug.cgi?id=569056  The
last thing I want is more ewarns.

  A better policy may be to keyword them, e.g. ~amd64 ~x86, etc.  This
would be reasonable, because there is actually a valid reason to do so.
I.e. users would be using unmaintained software.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[waltdnes]

On Thu, Jan 21, 2016 at 06:45:20PM +0100, Micha?? Górny wrote
> On Thu, 21 Jan 2016 17:25:02 +
> Roy Bamford  wrote:
> 
> > There is no point in removing unmaintained but perfectly functional
> > software from the tree.  It needs to be both unmaintained and broken.
> > Broken being evidenced by at least one open bug.
> 
> That's nonsense. In fact, that's exactly the opposite of what should
> be removed.
> 
> If I see a package that clearly doesn't build or otherwise simply
> doesn't work, could not have worked for past 3 years, are you forcing
> me to waste a time reporting a bug to no maintainer who could fix it?

  I think you misunderstood Roy.  He was speaking about "unmaintained
but perfectly functional software".  You're talking about "a package
that clearly doesn't build or otherwise simply doesn't work, could not
have worked for past 3 years".  Between those 2 extremes will be many
cases of doesn't-work-for-me/works-for-me.  Who'll be the final arbiter?

  Maybe we should start a "gentoo-ebuilds" mailing list to help regular
users learn the ins and outs of making ebuilds.  Once regular users run
a lot of their own ebuilds from their local overlays, then it would be
possible to do draconian pruning of the "official portage tree", without
so adversely affecting regular users.  This would fit in with the mantra
of Gentoo being about freedom of choice.

  E.g. I use Pale Moon, a fork of Firefox.  Currently, I have to build
as regular user, su, and copy the binary to /usr/local.  You can see
"Walter's excellent adventure"  as I learn the build process at...
https://forum.palemoon.org/viewtopic.php?f=37=10002

  I'd like to have Portage manage the process.  The ebuild from Firefox
should serve as a template, because they both use the same weird Mozilla
build setup.  The main change should be where the source is pulled from.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

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

[waltdnes]

On Wed, May 15, 2013 at 03:41:31PM +0200, Fabio Erculiani wrote
 Are we realizing that in order to keep systemd out of our way, we're
 currently writing and maintaining drop-in replacements for the
 features that systemd is already providing in an actively maintained
 state? openrc-settingsd was the first thing that we as Gentoo
 developers (Pacho?) had to write in order to merge GNOME 3.6 into our
 tree.

  So Redhat, who are heavily into GNOME
( http://fedoraproject.org/wiki/Red_Hat_contributions#GNOME_developers )
decided to make GNOME depend on other Redhat-developed software (systemd
and pulseadio).  Well... like... do...

  Question... when Sun made OpenOffice depend on Java (also a Sun
product) did Gentoo developers run around suggesting that Java be made a
part of the core Gentoo base system?  I don't think so.  If a user wants
to run GNOME badly enough, he'll switch to systemd.  I don't see why the
rest of us (i.e. non-users of GNOME) should have to follow along and
reconfigure our systems.  This is a case of the tail wagging the dog.

 So what do we want to do then? Isolate from the rest of the world?
 (It's not a sarcastic question). I hope that everybody does their
 own reality check.

  You are effectively calling not-using-GNOME isolationist.  Let's just
say I disagree with you on that.  BTW, see my sig.

-- 
Walter Dnes waltd...@waltdnes.org
I don't run desktop environments; I run useful applications

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

[waltdnes]

On Wed, May 15, 2013 at 06:38:14PM -0400, Rich Freeman wrote

 It will probably be more than a decade before anybody is FORCED to run
 systemd on Gentoo.  You don't even have to run udev on Gentoo.
 
 It will probably be years before the default even changes, assuming
 the trajectory of systemd remains as it seems to be.
 
 I think people are really getting carried away here.  I believe the
 udev team generally wants to follow upstream udev, and there is eudev
 and busybox mdev for those who don't want that.  No distro provides so
 many ways of avoiding systemd.  I don't see that changing anytime
 soon.

  I was replyiny to a poster who said...

 at some near point in the future, our users will be forced to replace
 udev/eudev with systemd. Like it. Or not.

  You mentioned that it will be years before it happens.  I realize
that this borders on the political, but if nobody objects *NOW*, in a
couple of years it'll happen.  And the developers will say but nobody
objected.  You're right that the process takes time.  It's precisely
because of that that unhappy users need to make their feelings known
now before it's too late.

-- 
Walter Dnes waltd...@waltdnes.org
I don't run desktop environments; I run useful applications