Re: [gentoo-dev] Uppercase characters in package names

[Nick Vinson]

On 12/02/2016 10:28 AM, Ulrich Mueller wrote:
>> On Fri, 2 Dec 2016, Mike Gilbert wrote:
> 
>> The devmanual states:
>> The name section should contain only lowercase non-accented letters,
>> the digits 0-9, hyphens, underscores and plus characters. Uppercase
>> characters are strongly discouraged, but technically valid.
> 
>> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> 
> 
>> Why are uppercase characters strongly discouraged?
> 
>> Wouldn't it make sense to follow upstream's naming convention?
> 
> No, because even for the most common packages it would be hard to
> guess what the actual convention is. For example, is it GCC (used on
> its web page and in documentation) or gcc (name of the command and
> displayed by gcc --version)?
> 
> If we allow uppercase, then should we also allow two packages in the
> tree whose names differ only in character case?

If Gentoo chose to perfectly match GNU's naming with GCC, then the
ebuild should be GCC-.ebuild.

The reason is simple.  GNU says GCC refers to the GNU Compiler
Collection, and gcc refers to the GNU C compiler.

Personally, I've disliked that differentiation. Most people don't pay
close enough attention to such things.  For example, how many people
think iOS and IOS are the same thing?

-Nicholas Vinson

> 
> Ulrich
> 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Optimizing toe stepping

[Nick Vinson]

On 11/03/2016 03:16 AM, Jason A. Donenfeld wrote:
> Hey guys,
> 
> Every other day on IRC, I see people arguing about touching each
> others packages, despite our policies against it. (Sometimes it's even
> me who's doing the touching!) My instinctive reaction is always,
> "can't everybody calm down and be happy somebody is doing your work
> for you?" The answer to this question is, of course, that it depends
> who the developer is and how competent you are.
> 
> So, nothing new here. I don't want to bikeshed about it. Business as usual.
> 
> Perhaps we can come up with something more formal for solving this,
> that works a bit better than my package-policy.txt idea (see other
> thread).
> 
> A few have proposed in the past adding this kind of "attitude
> information" to metadata.xml. Does anybody have any concrete proposals
> for what this would look like?

I must have missed the latest IRC conversation on this.  Was the issue
really about someone else doing the work or was it about someone
committing changes without informing the actual maintainer(s) first?

If it's the first, there's no issue and nothing needs to be done in my
opinion (well maybe the maintainer(s) should take note and solve the
issue(s) faster next time).  If it's the latter, then I think a much
easier solution would be to file a PR, write a bug, or send an email
before committing the change.  None of those options are particularly
difficult to do and it keeps the maintainer in the loop.

Just doing that one little thing would have prevented or shutdown the
arguments I have seen.

Thanks,
Nicholas Vinson

> 
> Thanks,
> Jason
> 



signature.asc
Description: OpenPGP digital signature

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

[Nick Vinson]

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

-Nicholas Vinson

On 10/25/2016 07:11 AM, Raymond Jennings wrote:
> Don't you need autoconf and automake to build a lot of packages?
> 
> On Tue, Oct 25, 2016 at 7:03 AM, Kristian Fiskerstrand  > wrote:
> 
> On 10/25/2016 04:01 PM, Alexis Ballier wrote:
> > On Mon, 24 Oct 2016 20:43:44 -0400
> > Michael Orlitzky mailto:m...@gentoo.org>> wrote:
> >
> >> Looking at profiles/base/packages, I see a bunch of lines that are
> >> commented out. For example,
> >>
> >>   *sys-apps/which
> >>   #*sys-devel/autoconf
> >>   #*sys-devel/automake
> >>   *sys-devel/binutils
> >>   #*sys-devel/bison
> >>   #*sys-devel/flex
> >>   *sys-devel/gcc
> >>
> >> Does anyone know why those are commented as opposed to just.. not
> >> there?
> >
> >
> > Those used to be in @system and were dropped at some point once ebuilds
> > had proper deps. My guess would be ppl wanted to keep them commented
> > out just in case it appeared to be a bad idea to drop them and be able
> > to "revert" easily. Nowadays, we can probably assume it was ok :)
> >
> 
> Indeed, to avoid confusion I'd suggest cleaning it up unless base-system
> or QA has any objections.
> 
> --
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> 
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: rfc: the demise of grub:0

[Nick Vinson]

On 10/04/2016 12:45 AM, Jörg Schaible wrote:
> -1
> 
> I'd love to move to grub2 for all of my machines, but it does simply not 
> work for one of my servers. I can install grub2 and it tells me that 
> installation and anything else went fine, but when I try to boot with it, it 
> stops and reports me that it found some conflicting area in my bios why it 
> cannot work (sorry, I tell this from my memory, I've tried it quite some 
> time ago). Mr. Google says that this may happen for some hardware, but has 
> no solution to it.

Was this ever reported in bugs.gentoo.org?

> 
> So, what are my options (or other people's options with such incompatible 
> hardware) without grub 1? Lilo?

Grub could also be an option depending on what version you tried.  If
you only tested against the stable versions, a second check would be in
order as 2.02_beta3-r1 went stable recently.

-Nick

> 
> - Jörg
> 
> 
> William Hubbs wrote:
> 
>> All,
>>
>> I want to look into removing grub:0 from the tree; here are my thoughts
>> on why it should go.
>>
>> - the handbook doesn't document grub:0; we officially only support
>>   grub:2.
>>
>> - There are multiple bugs open against grub:0 (15 at my last count). A
>>   number of these as I understand it are because of custom patches we
>>   apply.
>>
>> - grub:0 can't boot a nomultilib system, so we have to maintain a
>>   separate package (grub-static) specifically for that setup.
>>
>> - Removing grub:0 from the tree doesn't stop you from using  it. If people
>>   really want it I will place it in the graveyard overlay.
>>
>>   - We have custom patches for grub:0, which will never go upstream.
>>
>> - grub:0 is dead upstream. They have not done any work on it in years.
>>
>> - The only real problem with grub:2 has to do with pperception. Yes,
>>   their documentation has a strong preference toward using their
>>   configuration script (grub-mkconfig) to generate  your grub.cfg, but
>>   this is not required.
>>
>> So, I want to make a plan to lastrite grub:0 and grub-static.
>>
>> I'm thinking, in about a week,  p.mask grub:0 along with grub-static and
>> send out a lastrites msg with a 30 day removal notice.
>>
>> If there any technical objections to this, let me know what they are.
>>
>> Thanks,
>>
>> William
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [gentoo-proxy-maint] Package up for grabs

[Nick Vinson]

Hi,

I am the former maintainer of net-print/hplip-plugin, and because I have
removed myself as the package maintainer, there are no other maintainers
listed in metadata.xml.

Thus, the net-print/hplip-plugin package is now up for grabs.

- Nicholas Vinson



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] nftables

[Nick Vinson]

On 09/08/2016 05:31 PM, Ian Bloss wrote:
> Anyone actively using nftables for their firewall over iptables?
> Considering giving it a go as the syntax looks much nicer than iptables.

Works well enough for me.  I haven't seen any obvious bugs with the
newest version and no one has reported any issues either.

- Nicholas Vinson



signature.asc
Description: OpenPGP digital signature

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

[Nick Vinson]

On 06/03/2016 07:35 AM, Ian Stakenvicius wrote:
> On 02/06/16 09:48 PM, Nick Vinson wrote:
>> On 06/02/2016 08:08 AM, Raymond Jennings wrote:
>>> use case:  Telling a package to build a gui without deciding which one
>>> to build.  Also helps in cases where you have package A that can only
>>> build a qt gui, and package B that can build both qt and gtk, and
>>> package C that can build gtk only.  You want to have a gui for all
>>> three, but you don't want to hav epackage B build both guis and at the
>>> same time while you may prefer qt, you don't want to leave package C
>>> without a gui.
>>
>> How do you decide which one package B builds in such a case?
>>
>> Honestly, I don't think this is a good idea.  The rationale  and
>> suggested implementation just don't bring enough benefit in my opinion.
>> Often times it's hard enough to research a reported issue with the
>> current implementation.  Having a flag like 'gui' whose behavior
>> (potentially) changes based on what profile is being used makes things
>> considerably harder.  It would no longer be a simple matter of matching
>> versions and USE flags, the package maintainer would also need to setup
>> an equivalent system with the same profile or research what the 'gui'
>> flag with profile 'x' does and setup an equivalent USE flag set.
> 
> 
> OK this makes absolutely no sense.
> 
> 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.

Which only works with packages that provide support for a single GUI
implementation.  In cases where there's more than 1 option, you have to
either introduce RESTRICTED_USE as Patrick alluded to, or decide a
pecking order (or decide who gets to decide the pecking order).

and in that case, it *does* matter what dependencies the gui flag will
pull in.  Even if the user doesn't care, there's no reason for it to
pull in version A when version B is also supported by the package and
every other package with GUI support is using version B.

> It's the same as USE="server" to build the server daemon for an app
> that provides both client and server.

Maybe if IPX was still popular and I had to be concerned about whether
"server" would favor a TCP/IP server or an IPX one, but that's not the
case, so I don't see the two being equivalent here.

In fact, I see this flag more like the 'dedicated' USE flag (which in my
opinion, causes more problems than it solves).

> 
> You get that use flags are not supposed to represent dependencies
> right, but features of the package??  If you're only able to debug a
> build of your package because the flag is called gtk instead of gui,
> well...

I'm well aware how use flags are supposed to work, thank you.  Also had
you actually read what I had wrote and the context surrounding it, you
probably wouldn't have made such an asinine remark.

> 
> 
>>
>> Gentoo already has Gnome, KDE, Plasma, and Desktop profiles which mostly
>> do the same thing.  The only thing they don't do (as I understand the
>> profiles) is enable GUI support for packages that don't support the
>> preferred libraries.  Is that really enough justification to implement
>> this flag?
> 
> Yes.
> 
> More specifically, the cleanup of all of those other uses of flags
> that are there just to trigger a gui build instead of to indicate a
> choice between options, is also enough justification.  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.
> 
> Yes, the USE=gui on this hypothetical app may well pull in Xorg libs,
> but that's not a reason to keep the flag called "X", because again,
> its about the feature of the package *not* the dependency.

Sure it is.  The feature is supporting X11 not Wayland or some
hypothetical "omnigui".  Do you really think upstream is going to care
if their X11 app fails to work correct correctly in Wayland,  but runs
fine in a native X11 setup?

I tunnel X11 over ssh all the time, do you really think it makes more
since for me to have to set the 'gui' flag to do this instead of the X flag?

Yes, I agree that the 'X' flag should control a feature.  For most
packages, that feature is integrating with an X11 environment (i.e.
providing X11 bindings) and for most packages the X11 feature introduces
dependencie

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

[Nick Vinson]

On Jun 3, 2016 1:15 PM, "Alan McKinnon"  wrote:
>
> On 03/06/2016 21:34, waltd...@waltdnes.org wrote:
>>
>> 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.
>
>
> Walter,
>
> I think you're missing where the devs want to take this and what USE is
all about. It's about *features*, not about dependencies.
>
> USE="gtk" is a dependency.

No.  It is a feature.  However, it is a feature named after the
dependencies needed to enable it.  If a package has a hard dependency on
libgtk, a USE flag would not be added, but a soft dependency on libgtk
means that libgtk support is a feature or part of a feature (the feature
being you get to choose which toolkit is used).

If it was a dependency, then packages such as XFCE and evince would have to
use flags.  However they don't.

So enough with the these are dependency use flags and those are feature use
flags.  It's not true and it's a poor attempt to try and force this idea
through.  If this is idea is a good one, such tactics aren't needed.  If
it's not, the tactics aren't warranted.

> USE="gui" is a feature.
> You only need enable a specific graphics lib flag when there is ambiguity
about what "gui" means for a package.
>
>
>>
>>> 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.
>>
>
> That's a silly idea not least because it's non-deterministic. A force USE
flag is really just USE="gtk" or USE="qt" on a larger scale as there's now
*more* toolkits to randomly pick one from.
>
> Most apps support one toolkit, often either gtk2/3 or qt4/5. It's a
minority that support both and we have special means to handle those. For
that small set of apps that do support several toolkits, what exactly are
you going to force? If you can have one of gtk 2 or 3 but not both, which
one is it? Well you'd need a USE="gtk2" or USE="gtk3" to find out what the
user wants.
>
> This proposal makes things simpler and reduces flags and their usage.
> "gui" means build the gui the thing supports.
> "X" stops meaning "gui" or maybe "XLibs" or perhaps "usually RDP but also
supports magic X11" and starts to mean "X11 Window System" as opposed to
Wayland or Mir.
> The other toolkit flags start to mean specific versions of toolkits and
only need be used when things get ambiguous and portage wants you you tell
it what you want.
>
> In short, flags will get simpler (as cruft will be removed) and flags
gain clearer distinct names. Think of it as a code refactor after years of
accumulating rubbish due to no clear plan.
>
> Alan
>
>
>

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

[Nick Vinson]

On 06/02/2016 08:08 AM, Raymond Jennings wrote:
> use case:  Telling a package to build a gui without deciding which one
> to build.  Also helps in cases where you have package A that can only
> build a qt gui, and package B that can build both qt and gtk, and
> package C that can build gtk only.  You want to have a gui for all
> three, but you don't want to hav epackage B build both guis and at the
> same time while you may prefer qt, you don't want to leave package C
> without a gui.

How do you decide which one package B builds in such a case?

Honestly, I don't think this is a good idea.  The rationale  and
suggested implementation just don't bring enough benefit in my opinion.
Often times it's hard enough to research a reported issue with the
current implementation.  Having a flag like 'gui' whose behavior
(potentially) changes based on what profile is being used makes things
considerably harder.  It would no longer be a simple matter of matching
versions and USE flags, the package maintainer would also need to setup
an equivalent system with the same profile or research what the 'gui'
flag with profile 'x' does and setup an equivalent USE flag set.

Gentoo already has Gnome, KDE, Plasma, and Desktop profiles which mostly
do the same thing.  The only thing they don't do (as I understand the
profiles) is enable GUI support for packages that don't support the
preferred libraries.  Is that really enough justification to implement
this flag?

As a maintainer I'd ask that, at the very least, a more compelling
reason than "it's too annoying to update package.use" is given.  I find
the argument against putting all the flags in global a valid but weak as
there are already mitigations for that scenario.   Perhaps I'm missing
something, but I'm not convinced this will provide a significant enough
benefit to the average Gentoo user to offset the increased
troubleshooting demand it'll put on Gentoo's developers, maintainers,
and proxy-maintainers.

Thanks,
Nicholas Vinson

P.S. I'd also like to add that I do spend a considerable amount of time
in #gentoo and I don't recall seeing this problem come up that much.
The closest I've seen was a user asking where /usr/bin/VirtualBox was
(as it only gets installed when the proper qt USE flag is set), but
based on personal experience that happens maybe 1 or 2 every 3 - 4
months (if that often).

> 
> On Thu, Jun 2, 2016 at 7:20 AM, Ian Stakenvicius  > wrote:
> 
> On 01/06/16 10:13 PM, waltd...@waltdnes.org
>  wrote:
> > 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.
> >
> 
> 
> The whole point of USE=gui is to get away from needing to do that.
> Those flags should be used to choose -which- gui toolkit users want
> when one is available, not to choose IF a gui should be built or not.
> Take my example into account, i don't want anything qt based if I can
> avoid it, but i definitely want wpa-gui.  Right now I only get wpa-gui
> if I enable USE=qt4 (or USE=qt5 presumably) on wpa_supplicant.  I'm
> not going to set that globally though because I don't want to choose
> qt4 based front-ends for anything else, and having to guess for every
> random package when i don't care so that I can set a package.use entry
> for it is annoying.
> 
> 
> >> Furthermore, this matches the recommended USE flag design where the
> >> more important flags are provided as feature flags, while specific
> >> depend