Re: [gentoo-dev] Reverse use of Python/Ruby versions
On 10/04/2017 19:58, Christopher Head wrote: > On April 9, 2017 7:04:13 PM PDT, "William L. Thomson Jr." > wrote: >> The present system is a PITA for users. Fiddling with adding/removing >> targets for Python/Ruby. > > As an ordinary user, that does sound like a real annoyance. As an ordinary > user, I also never do it. I don’t have any targets set by hand. I probably > never will. And yes, I do some Python development myself (not much packaging > but “using” Python in the sense of writing Python code). I find the Python > experience largely painless: I currently have 2.7.12 and 3.4.5 installed. > Eventually 3.5 will get installed and 3.4 will go away. Just like every other > package. I won’t need to do any config file editing, just a revdep-rebuild > run perhaps. So regardless of the situation for maintainers, as a user, I > don’t see this pain. > As another regular user, you most definitely will see this pain if you need to deviate from your profile defaults for python. I'm like you - use lots of python, package some, write some. I also don't go past the current ~arch python-3 because I have a good sense of what waits for me if I do. That you and I don't suffer too much breakage at all since years now is a testament that *someone* is touching all those ebuilds when they need to be touched, that they are managing to do it without much visible fallout is a minor engineering miracle or sheer hard work. I think William has a point; sometimes making a criteria a negative one result in a lot less work. A good survey usually gives numbers that let you tell if it will. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] [RFC] Restricted version of gentoo-dev mailing list
On 24/05/2017 12:24, Michał Górny wrote: > On śro, 2017-05-24 at 03:48 -0400, Walter Dnes wrote: >> On Wed, May 24, 2017 at 08:41:25AM +0200, Micha?? Górny wrote >>> Next time such a thing happens, the discussion will happen on a >>> completely private media or not happen at all because of the state >>> of this mailing list. Is this what you really want? >> >> Here's the part you did not quote... >> >>>> If we could have a guarantee of proposed changes like that being >>>> posted on Gentoo-User for comment, rather than being sprung on >>>> users by surprise, I'd be willing to sign off this list. >> >> Note where I said "...posted on Gentoo-User for comment...". What I'm >> asking is for such proposed changes to be posted on Gentoo-User, and the >> discussion/feedback/flamefests/etc will be on Gentoo-User. This type of >> surprise stuff seems to happen a lot in Open Source... >> >> * Gentoo /usr >> * Firefox Australis UI, and dropping ALSA and going PulseAudio-only >> * GNOME getting a hard-coded dependancy on systemd >> * etc, etc > > And what would be the use of those 'user comments'? Do you believe it > would change anything? So what is the purpose of asking more users from > feedback *we do not want*? > > Would it make you feel better if you were asked to raise your objection? > Would you feel better claiming that we did it against objections of many > users? Or do you believe we would abandon it and decide not to do > anything because of the resulting bikeshed -- which seems to be > a recurring theme lately? > > Yes, I *do not want feedback* on *how to do Gentoo* from people who do > *not help me do Gentoo* but instead only complain and demand. > I can't let this one go. Michał, Walter is a long-term high-quality Gentoo-user and does not deserve to be told what you just said above. Please get your act together and stop treating other people as worthless nuisances. You are annoyed by someone or something, that much has been obvious for a long time now. I can assure you, Walter is not the correct target for your annoyance. Please deal with the correct source. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: Categories for GUI stuff x11 and wayland
On 05/09/2017 00:15, Duncan wrote: > Kent Fredric posted on Tue, 05 Sep 2017 07:29:42 +1200 as excerpted: > >> On Mon, 4 Sep 2017 15:16:46 -0400 "William L. Thomson Jr." >> wrote: >> >>> Maybe just UI but that maybe to generic. >>> https://en.wikipedia.org/wiki/User_interface >> >> As a side question, what does "xui" mean in this world? >> >> I went googling and all I could find was "X User Interface" >> >> And all I could find there is that's "A user interface to the X Windows >> System" >> >> Are we allowed to consider Wayland and X11 are both "X Windows Systems" >> providing "X User Interfaces", despite the underlying protocols being >> different? > > Warnock agree? > > (Tho posting makes it no longer warnock.) Thanks for the warnock > reference[1], BTW. I knew of the problem but had no name for it, so you > broadened my vocabulary in a very useful way. =:^) > > [1] https://en.wikipedia.org/wiki/Warnock%27s_dilemma > "xui" is a nice descriptive name and gets the point across in a reasonably unambiguous way. wayland is not X11, but it comes from a desire to do what X11 does without X11's problems. There might be a smallish snag with educating users what "xui" means as the name is not in common use. "display-server" also serves as that is what wayland and X11 have in common. It's a long unwieldy name and the "-" might trip over hidden naming assumptions. Given a vote, I'd vote for "xui". Second choice is to stick with "x11-" as it will take a very long time for all users to forget what x11 is and how wayland relates -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] "Not a git repository" error on ebuild
On 07/11/2017 21:10, Damo Brisbane wrote: > Hi, > > I am getting an error on custom fabio-1.5.2.ebuild > <https://github.com/damobrisbane/damo-overlay/blob/master/net-proxy/fabio/fabio-1.5.2.ebuild> > - > "Not a git repository (or any of the parent directories)..." I've been > looking on web, trying some things, but still message is coming up, > appreciate suggestions. Note package is installing fine, just not sure > how to clean up this message. > > Thanks in advance: Please post the ebuild. That's a git error (not a portage error) and it means you are trying to run "git " without running "git init" first > > > >>>> Emerging (2 of 2) net-proxy/fabio-1.5.2::damo-overlay > * fabio-1.5.2.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... > [ ok ] > * Adding group 'fabio' to your system ... > * - Groupid: next available > * Adding user 'fabio' to your system ... > * - Userid: 116 > * - Shell: /sbin/nologin > * - Home: /var/lib/fabio > * - Groups: fabio > * - GECOS: added by portage for fabio > * - Creating /var/lib/fabio in / >>>> Unpacking source... >>>> Source unpacked in /tmp/portage/net-proxy/fabio-1.5.2/work >>>> Preparing source in > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2 ... >>>> Source prepared. >>>> Configuring source in > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2 ... >>>> Source configured. >>>> Compiling source in > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2 ... > make -j5 -C > /tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/github.com/fabiolb/fabio > <http://github.com/fabiolb/fabio> install > make: Entering directory > '/tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/github.com/fabiolb/fabio > <http://github.com/fabiolb/fabio>' > *fatal: Not a git repository (or any of the parent directories): .git* > GOGC=off go install -ldflags "-X main.version=" > make: Leaving directory > '/tmp/portage/net-proxy/fabio-1.5.2/work/fabio-1.5.2/src/github.com/fabiolb/fabio > <http://github.com/fabiolb/fabio>' >>>> Source compiled. > -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: usr merge
On 09/04/2016 20:34, waltd...@waltdnes.org wrote: > On Sat, Apr 09, 2016 at 12:18:25PM -0500, »Q« wrote >> On Sat, 9 Apr 2016 12:09:38 -0400 >> waltd...@waltdnes.org wrote: >> >>> 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. >> >> Booting without /usr mounted early is something Gentoo already doesn't >> support and can't support, right? > > If you can read this post, you've got a mighty powerful imagination. > Because we all know that Gentoo can't boot, let alone send emails, from > a machine with separate /usr and no initramfs... just like I'm using > right now. > That's not what he said. He said gentoo doesn't, and can't support it, because it's a world of pain to provide proper support to everyone who wants it. If you want it, as you do, you get to do it yourself. While it still works, grat. When it stops working, you fix it. He did not say, as you imply, that it cannot work right now. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] [RFC] Global USE=gui
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. 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
On 03/06/2016 23:33, Nick Vinson wrote: > 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. Well, that's your opinion and thank you for stating it. I stated mine, and neither are facts. Alan
Re: [gentoo-dev] why is the security team running around p.masking packages
On 05/07/2016 15:07, james wrote: > On 07/05/2016 06:25 AM, Rich Freeman wrote: >> On Mon, Jul 4, 2016 at 11:26 PM, Aaron Bauman wrote: >>> >>> The subject of this particular mailing list post is a little alarming >>> and >>> over reactive. We are not running around p.masking everyone's >>> packages, but >>> issues that have been outstanding for years often result in such >>> courses of >>> action. I personally told Anthony I should have requested his >>> assistance >>> initially on the matter, and I do apologize for that. He is an active >>> developer who would respond in a timely manner. So once again, I do >>> apologize. >> >> Thanks, and my intent wasn't to suggest that I thought there was any >> kind of a trend here. I just wanted to agree that this shouldn't be >> how it happens. It sounds like we're already on the same page, which >> isn't surprising since this was the first complaint I've heard in a >> while. >> >>> Finally, that does not dissolve the developer of providing usable, >>> substantiated, and verifiable information regarding the vulnerabilities. >>> The idea that a developer gets to choose whether or not they do so >>> should >>> not be considered. >> >> Also agree. I think we need to have a reasonable security policy, but >> clearly there can't be unresolved questions about whether a particular >> package-version is vulnerable or not. If we don't get a question like >> that resolved in a timely manner then the version should be masked. >> Users can then make an informed decision as to whether they want to >> take the risk in unmasking it. >> >> Our security policies are a tree-wide QA commitment that our users >> rely on. We shouldn't advertise a security policy that we aren't >> willing to enforce. > > As an old C hack, and user of gentoo for over a decade, I understand the > positions being articulated herein. However, I think there is a > fundamental perspective that is missing, so I shall attempt to > illuminate that perspective. 'C' is still a magical and most important > language. It is the transitive language between large, complicated > systems, and hardware. Like it or not, without hardware, there are no > systems. > > There are many new and modern languages with wonderful features. I get > that, and appreciated that they are needed and desired. But modern > (security and usefulness) metrics are being applied to old codes that > are useful for a variety of reasons, beyond compiling them and using them. > > There is an intersection between minimal unix (minimal gentoo in our > case) and embedded systems. Docker, many would cite as the leader in > commercial container deployments, has realized that minimal is better, > faster, easier to secure and can always be 'scaled up' by adding more > codes (hence they subsumed Alpine Linux). > > Gentoo has a rich, legacy in old, simpler codes that bridge embedded > linux to (bloated/full-featured) linux. Those old codes that appear to > many as useless, indeed form a narrow bridge to both the past and the > logic/tricks/methods to get various types of hardware working in a > minimal or embedded environment. They are often 'single function' codes > without the complexity of a gui or bloated formations. They are easy to > read and with a CLI focus, allow a developer to see how some things > work. Those old codes, folks are quick to purge now, often contain > logical information on how to talk to hardware. (think ethernet for one). > > > So when we had 'the attic' I was fine with codes being purged by > whomever. There is no easy to use equivalent in github (and believe me, > I'm a noob at github), so I have much anxiety about what, from my > perspective, appears to be needless purging of many old codes. I have no > problem with removal from the official tree, but I'd like to keep them > around, regardless of any security, brokeness or un-maintained status. I > completely OK with tree-cleaning, just a soon as the ink dries on the > new wiki pages that guarantee archival of old codes. Security, is > important, but not the main issue from my perspective. Maintenance of > old codes, particularly written in C and related to hardware or logic of > minimal systems, is keenly important to me. If gentoo remains 'a good > stuart' of these codes, it just another mechanism > to distinguish our distro, imho. > > So I would ask (beg if necessary) the kind folks that are the gentoo > devs to figure out a way to archive those old codes, and document how to > retrieve them, via github, as the attic too is probably like sunrise and > such, headed towards deprecation and the chopping block. s/github/git/g Big difference. Gentoo's tree is not hosted on github, and infra isn't going to put an attic equivalent there. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] why is the security team running around p.masking packages
On 05/07/2016 21:53, james wrote: * If you don't know the last commit before removal, juts load up the removal commit and copy the commit hash of the "Parent" link to get the commit before that Tada! Attic restored ^_~ Not bad, at first glance. Not too bad at all! Let me work with this a bit. THANKS! James James, As an old-time C hacker, to wrap your brains around git, forget everything you ever learned about CVS, SVN and similar tools. Then recall everything you ever learned in C about pointers, linked lists (all the juicy types), and structs. Now look at git again, you should feel in much more familiar territory. You still have to get used to Linus' quite bizarre names he gave commands. But then again, he does say git isn't really a source-code repo, he says it's a filesystem. Because that's what he does - writes filesystems. Alan
Re: [gentoo-dev] Re: Packages up for grabs
On 07/08/2016 15:32, Kent Fredric wrote: >> Let them use java* codes, as that is what all the universities are >> > teaching and promoting. I agree >> > with gentoo proper on severely restricting java*, on gentoo-proper, >> > but that sort of thing is killing gentoo and just appears to the open >> > world as a filter mechanism to keep out and go elsewhere, snoot. >> > There are just too many exciting and useful codes out there running >> > java. > "All" ? Some. And the dominance and focus on Java is itself telling of > the quality and type of the education provider. > > Some education providers may not touch Java at all, and focus > predominantly on C. > > You can't satisfy everyone out of the box. > I have no idea where James gets his information from, but I suspect it's a niche market where uni students do "clustering" - whatever that is. The interesting apps out there are mostly running python, go and (sometimes) lua. And that's what I observe in my day job - business/mobile ISP. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: Packages up for grabs
On 07/08/2016 19:36, james wrote: >> The interesting apps out there are mostly running python, go and >> (sometimes) lua. And that's what I observe in my day job - >> business/mobile ISP. > > > Look at the job listing on stackoverflow and elsewhere (java) is very > popular when they list several programming languages to meet the > requirements. I'm not promoting java, at all, but just stating that it > is very popular, on new projects (but not all) and it is a large and > frequent requirement, dictating by employers. Kids coming out of college > want a job, more than anything, and most are having java crammed down > their throats. So we should find a way to robustly > support those that need java. Nothing is precluding other languages > in my message. Personally I avoid java, unless it is critical to > a code or family of codes I need to run. I recommend Java as a teaching language at university level. You get all the benefits of a C-like syntax without the overhead of learning to deal with C and/or C++. You don't have to deal with the toolchain (much), you can easily show correct implementations of OOP style without getting into generics (or, you can avoid Java generics altogether at this level and pretend they don't exist). In short, what's not to like for teaching? All win not much lose. Well OK some kids come away thinking Java is the one and only, but they will have that too if Python is the teaching language. Realizing there are other things out there is part of the learning process. But, despite all that, Java is not special. It should run on Gentoo for anyone who wants it, just like things starting with P. You volunteering to do the grunt work? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] newsitem: openrc 0.22 updates (second draft)
On 26/09/2016 19:01, William Hubbs wrote: In previous versions of OpenRC, configuration information was processed so that service-specific configuration stored in /etc/conf.d/* was overridden by global configuration stored in /etc/rc.conf. OpenRC 0.22 reverses that. Global configuration stored in /etc/rc.conf is read first then overridden bby configuration stored in /etc/conf.d/*. service-specific configuration. The swapfiles service, which was basically a copy of the swap service, has been removed. If you are only using local swap partitions, as described in the handbook for example, this change will not affect you. If you are using swap files or swap partitions on network-backed devices such as iSCSI, please adjust the dependencies of the swap service as shown in /etc/conf.d/swap to reflect your situation. Two paragraphs, is that two distinct changes in openrc? Because the second doesn't logically follow from the first and it doesn't seem like an example of the first either. I suggest an intro para along the lines of "This version of openrc introduces two changes" and then number the paras following -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] RFC: Userkit.eclass
> system across others. You need consistent GID/UID mappings or things like NFS > will have lots of problems. NFS is an edge case. Maybe edge is not the best possible adjective here, but it certainly isn't the one killer app that requires the whole uid/gid scheme needing to be locked down. People running into NFS uid/gid problems can figure out their own ways to deal with it, (and that doesn't always imply mapping everything to root plus norootsquash...) > Package a few things in Gentoo that need a UID and/or GID and you will start > to understand the problem from a operating system packager perspective. I have packaged a few things in Gentoo (privately only), and written more shell installers, puppet manifests, ansible playbooks and user account deployers than I care to recall; I've never run into this problem that I couldn't solve trivially - usually by just knowing the username|groupname and looking up the corresponding uid/gid. Really, it's just data mapping and we have tools to do the lookup real fast. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Requirements for UID/GID management
On 29/01/2017 03:56, Michael Orlitzky wrote: > On 01/27/2017 11:21 PM, Rich Freeman wrote: >> >> It isn't like inconsistent UIDs are the end of the world. However, >> IMO it still makes sense to at least try to standardize such things. >> Really, if you have a package always installing the same user simply >> sticking a default UID without any effort to avoid collisions is >> better than nothing, but having a wiki page where people can register >> UIDs isn't that big a deal. >> > > I threw together an ugly implementation so I could play with both > approaches -- random or fixed UIDs by default. The code to get user and > group management working is of course nice and simple in either case. > Where they both turn to shit is the upgrade path. > > Here's a problem I have no solution for. Suppose we tell everyone to > pick a fixed UID for their user packages. I have a randomly assigned > "tcpdump" user as UID 102 on my machine today. If we roll this out next > week and the tcpdump maintainer chooses UID=321 as his fixed UID, what > happens when I go to install sys-user/tcpdump? Every option is bad: > > * Keep the existing user. Now its UID is wrong. You might say "so > what," but the majority of users on the majority of systems are > going to have this problem, so you have to wonder what we've > gained by deciding on fixed UIDs and then ultimately assigning > them randomly anyway. > > There's the related problem of what to do if the tuxracer maintainer > decides he wants to use UID=102 and I still have tcpdump using it. > > * Overwrite the existing user with the new one. Your packages all > break. > > * Have the ebuild die(), and tell the user to fix the UID and file > ownership himself before emerge can continue. Good luck with that. > > In the mostly-random-UIDs approach, I have an answer, even if it's not > pretty: I can use the pre-existing UID instead of the next available > one. This still fails if the ebuild author requests a specific > (conflicting) UID, but that should be extremely rare in the random-UIDs > model. > > Can anyone think of an upgrade path for fixed UIDs? That issue aside, I > may have convinced myself that fixed UIDs are better. The general process I would recommend is that if the ebuild finds the user already exists, leave it, it's UID and it's file ownerships alone, and keep them as they are. If the user does not exist then create it. Preferably use a pre-assigned UID/GID so there is some consistency with most other Gentoo things out there. If the user already exists, it's presumably because the sysadmin wants it that way or it was installed that way from an older ebuild. Either way the ebuild cannot mess around with that. It could output an elog saying the uid/gid doesn't match the new Gentoo norm, and provide the commands to run to bring things into line (usermod, groupmod, find / -user -exec chown, etc, etc) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Requirements for UID/GID management
On 29/01/2017 19:05, Michael Orlitzky wrote:
> On 01/29/2017 03:26 AM, Alan McKinnon wrote:
>>>
>>> Can anyone think of an upgrade path for fixed UIDs? That issue aside, I
>>> may have convinced myself that fixed UIDs are better.
>>
>> The general process I would recommend is that if the ebuild finds the user
>> already exists, leave it, it's UID and it's file ownerships alone, and keep
>> them as they are. If the user does not exist then create it.
>
> That's what I've got it doing now...
>
>
>> Preferably use a pre-assigned UID/GID so there is some consistency
>> with most other Gentoo things out there.
>
> This is the only point we have left to consider. To recap, there are
> three approaches to try:
[snip]
> 3 Mostly fixed UIDs, but with a fallback to random ones if you don't
> get the UID you want. Here, everyone specifies their "preferred"
> UID, and we try that first. If it doesn't work, you get the random
> assignment.
>
> Pros (w.r.t option 2):
>
> * On a new installation, all of the UIDs that are assigned will
> likely be fixed, so you get some of the benefit of the first
> option without having to create an overlay.
This is my preferred choice
>
> Cons (w.r.t. option 2):
>
> * The upgrade path is a little hairier. On an existing system,
> we'll be introducing a bunch of new user packages that want
> a particular UID but don't get it. On existing systems, the
> UID assignment will still essentially be random. That's
> problematic for packages that truly need the UID they've
> requested.
I say drop the upgrade path entirely. Why do you as a dev care?
You've made a compelling case that making any changes at all is hairy,
so don't even try and automate it.
As a mere user I personally would never expect Gentoo devs to deal with
this, and if there's a knob in make.conf to enable/disable such a user
upgrade path, I'd probably disable it.
I've had to do this exercise more times than I care to admit, usually to
get multiple machines across a network in sync or to deal with nfsv3,
and it's not something I'd ever dare throw a script or ebuild at.
If you achieved the simpler status of new installs of packages get the
preferred UID if available, then I'm 100% happy and over the moon.
Everything else is my problem, not yours (although I appreciate the
effort to even make the attempt)
> Option #1 is pretty much dead in the water without an upgrade path.
> We're considering #2 and #3 at the moment, but they're really not
> that different.
>
>
>> It could output an elog
>> saying the uid/gid doesn't match the new Gentoo norm, and provide the
>> commands to run to bring things into line (usermod, groupmod, find /
>> -user -exec chown, etc, etc)
>>
>
> There's no safe way to do that. If you call chown (as root) on
> everything in a user-owned directory, that user can just create a
> symlink to e.g. /root/.bashrc and you'll give it root. It's really a
> miserable time trying to switch ownership of anything safely once it's
> been created.
Sure it can be done, just don't chown -R ~user. DO it the VERY
long way round, file by file. Say you changed user "awesome" uid 300 to 400:
find / -uid 300 -exec chown awesome {} \+
It works every time, but involves " find / " - ouch - and you can't do
it if the user is logged in or has running processes. This is all for
system accounts, so I reckon you have a huge show stopper right there,
requiring admin intervention
--
Alan McKinnon
alan.mckin...@gmail.com
Re: [gentoo-dev] Requirements for UID/GID management
On 30/01/2017 00:20, Michael Orlitzky wrote:
> On 01/29/2017 05:07 PM, Alan McKinnon wrote:
>>
>> Sure it can be done, just don't chown -R ~user. DO it the VERY
>> long way round, file by file. Say you changed user "awesome" uid 300 to 400:
>>
>> find / -uid 300 -exec chown awesome {} \+
>>
>
> That will find symlinks created by UID 300, and chown will follow them
> to give "awesome" ownership of the TARGET of the symlink; an easy root
> exploit. If you are about to suggest "find -type f" or the
> "--no-dereference" flag, then beware that chown will also follow
> hardlinks and you're still screwed (albeit limited to one filesystem,
> and on vanilla kernels).
>
>
Good catch with symlinks.
I don't see the point about hardlinks, they are just files with 2
dentries. When find gets to the second one it's already changed, so no
problem.
But I'm sure there are plenty edge case scenarios that make this whole
process go awry, all pointing to the same conclusion:
As a dev you shouldn't even try. Let the sysadmin deal with it.
If a system user already has a UID different to the published standard,
leave it alone, it's a human's problem
--
Alan McKinnon
alan.mckin...@gmail.com
Re: [gentoo-dev] Requirements for UID/GID management
On 30/01/2017 01:04, Michael Orlitzky wrote: > On 01/29/2017 05:30 PM, Alan McKinnon wrote: >> >> Good catch with symlinks. >> I don't see the point about hardlinks, they are just files with 2 >> dentries. When find gets to the second one it's already changed, so no >> problem. >> > > Any user can create a hard link in its home directory to /etc/shadow, so > long as (a) they live on the same filesystem, and (b) there are no > special kernel protections in place to prevent it. If you call chown on > that hard link, it will change the ownership of /etc/shadow. That is absolutely not true, at least for the case of classic Unix filesystems. hardlinks are exactly the same thing as regular files. For any given filesystem object there is a dentry, and that dentry points to an inode. Usually that is the end of the matter. When we create hardlinked files all we are doing is create a new dentry and point it to an inode that is already there. The so-called "hardlinked" file is a fiction, the instant you do it the new dentry operates just like any other file and is not even aware of other dentries pointing to the same inode. The point being, there is only one inode, and that is where the ownerships and permissions are. I cannot chmod, chown or chgrp /etc/shadow because I do not own it, and the kernel will not let me ln it either: alan@khamul /alan $ ls -ald /alan/ drwxr-xr-x 2 alan root 4096 Jan 30 16:10 /alan/ alan@khamul /alan $ ln /etc/shadow ln: failed to create hard link './shadow' => '/etc/shadow': Operation not permitted alan@khamul /alan $ ls -al /etc/shadow -rw-r- 1 root root 1655 Dec 31 14:43 /etc/shadow alan@khamul /alan $ stat /etc/shadow File: /etc/shadow Size: 1655Blocks: 8 IO Block: 4096 regular file Device: 815h/2069d Inode: 1188230 Links: 1 Access: (0640/-rw-r-) Uid: (0/root) Gid: (0/root) Access: 2016-12-31 14:43:29.556174143 +0200 Modify: 2016-12-31 14:43:29.556174143 +0200 Change: 2016-12-31 14:43:29.568174144 +0200 Birth: - The only thing I can do after hardlinking a file is what I could do before. > I thought real hard about ways to avoid that and ultimately gave up. The > only safe way to chown is to "chown away"; that is, switch to the guy > who owns the files, and then give them to someone else. This is also not true. Only root can chown the owner of a file, and a regular user cannot give files away. The only ownership actions a user can do on a file is chgrp but only if the user is the owner, and then only to a group the user is a member of. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Moving our/portage stuff to var
On Wed, 19 Dec 2012 14:56:44 +0100 Diego Elio Pettenò wrote: > Just mv /usr/portage /var/portage ? FFS no. Among other things, as > many said before, we should really take distfiles out of the tree > itself, and packages the same. And I don't want /var/packages > or /var/distfiles at all. If we are going to move distfiles out of the tree into, what are the odds of getting /some/path/portage/local to move somewhere else too? That one has irked me for ages, its the one thing left on my systems that stops the local tree dir being an exact replica of the upstream master. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Moving our/portage stuff to var
On Wed, 19 Dec 2012 14:19:52 -0800
Zac Medico wrote:
> On 12/19/2012 02:01 PM, Alan McKinnon wrote:
> > On Wed, 19 Dec 2012 14:56:44 +0100
> > Diego Elio Pettenò wrote:
> >
> >> Just mv /usr/portage /var/portage ? FFS no. Among other things, as
> >> many said before, we should really take distfiles out of the tree
> >> itself, and packages the same. And I don't want /var/packages
> >> or /var/distfiles at all.
> >
> > If we are going to move distfiles out of the tree into, what are the
> > odds of getting /some/path/portage/local to move somewhere else too?
>
> What program uses this "local" directory? It's not used directly by
> portage itself, though portage has an exclude for it in the default
> PORTAGE_RSYNC_OPTS setting
> (in /usr/share/portage/config/make.globals).
It goes back a long time, and is basically a poor man's local overlay
without having to use layman. As I understand it, portage will treat
the directory like any other when looking for ebuilds and resolving
deps, but exclude it from a sync.
>
> > That one has irked me for ages, its the one thing left on my systems
> > that stops the local tree dir being an exact replica of the upstream
> > master.
>
> For portage's defaults, I won't settle for anything less than having
> them all refer to separate directories which are *not* nested within
> one other. These are the current default settings which violate my
> requirements:
>
> PORTDIR=/usr/portage
> DISTDIR=${PORTDIR}/distfiles
> PKGDIR=${PORTDIR}/packages
> RPMDIR=${PORTDIR}/rpm
/usr/portage/local has the taste feel and smell of a hacky workaround:
shove a directory in the tree and exclude it from sync.
I suspect the best solution all round is to move all support for local
overlays into layman. I'd be happy with that. Probably make the portage
code cleaner too.
--
Alan McKinnon
alan.mckin...@gmail.com
Re: [gentoo-dev] Moving our/portage stuff to var
On Thu, 20 Dec 2012 19:18:56 +0100 George Shapovalov wrote: > > It goes back a long time, and is basically a poor man's local > > overlay without having to use layman. As I understand it, portage > > will treat the directory like any other when looking for ebuilds > > and resolving deps, but exclude it from a sync. > Nope, he means /usr/portage/local, not /usr/local/portage. It is > rarely (if ever, nowadays) present, as I understand, but you can find > it mentioned in that config file. It may be just a legacy definition > by now, looking at how only layman was mentioned with relation to it > and even that one appears not to use it any more. I thought about this some more, and now realise I've been using essentially the same set of config files since about 2004. I've never lost them and always had a current copy so each time I build a new host I just copy, tweak CFLAGS, maybe MAKEOPTS, and let 'er rip. My "local" is probably years out of date. Serves me right for not reading 50 screens of man page with every new host :-) This sub-thread is probably just noise, sorry for that. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: Time based retirements
On Fri, 21 Dec 2012 17:57:44 +0100 Diego Elio Pettenò wrote: > > If someone has at some point contributed to Gentoo then why not let > > them keep their user around, should they want to come back. Of > > course this doesn't work retroactively, but I think it would be a > > cool tip of the hat to current and future developers. > > ... the users generally are kept, and locked, but also one of the > things that is done is archiving their home directory on dev.g.o as > it might be taking quite an amount of space. At my day job I'm the retirer (or BOFH depending who you speak to). I'll describe mt process, maybe you fellows can use it. Retiring people is too much effort, reinstating them doubly so; we all have better things to do with our time. There's only 3 things that get you retired or remvoed: 1. Resign from the company 2. Dramatically change your entire job (like move from technical to sales) 3. Prove I was wrong giving you access at all (i.e show a long history of stupid, or demonstrate malice) Most systems are Operations, so people who need access will do so at least once in 90 days to keep the account alive. If the account is not used in a 90 day period, it is parked (essentially "locked", but the user can unlock it by going to a specific web site and auth'ing using two-factor (password and hardware dongle) There's a small list of exceptions for people where 90 days does not apply, like for me. I need access to everything (I'm last call in any emergency) and most systems I rarely touch but I must not be locked out. What emerges out of this is the most security and ease for the smallest effort. Works for me :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: kerberos, virtuals, rattling cages
On 25/02/2013 13:03, Duncan wrote: > Eray Aslan posted on Mon, 25 Feb 2013 10:02:49 +0200 as excerpted: > >>>> I don't think samba will support MIT, since it's kinda windows >>>> focused. >> >> Ugh, no. MIT is not windows focused > > ... But samba is... > > > As far as the thread in general goes, the question arises, if you're > running both samba and nfs, why? They're both network-based-filesystems > that in theory at least should have reasonably similar functionality, so > an admittedly not particularly clueful reaction is "if it hurts when you > do that, stop doing it". > Two words: mixed environment In corporate networks it is very common to share the same backend over both smb/cifs and nfs. Windows clients can't easily deal with anything other than cifs. Linux client invariably whinge at length about how the performance of samba sucks. Solution: run both protocols, everyone wins. It only goes south when AD/Kerberos enters the mix. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Last rites: app-text/cuneiform
On 24/03/2013 15:40, Peter Stuge wrote: > Markos Chandras wrote: >> The masks are sort of announcements as you have 30 days to revert that >> decision. > > You don't seem to recognize the quite significant psychological > impact of you having already made the decision, compared to, say, > having an actually inclusive package removal process. > > Bugzilla does not count as inclusive in this case. > > I mean something like a process where users who have this package > installed are notified about the change in status, as opposed to > having to monitor a developer mailing list or portage.mask in order > to get those news. It would probably be a part of emerge --sync. > > I think that might do far more good than any web page. > > You might argue that such a thing is completely outside your > department, but please consider that what you do can't be seen > in isolation, because users don't care at all about the isolated > particulars which result in their package being masked and cleaned, > they just see that the package is gone one day. You should care > because what you do is the trigger for that user experience. > > Improving UX should be your priority too, even if it isn't formally > part of what you do. (Should be everyone's priority.) We have 5 "statuses" for packages - stable - unstable - masked by no keyword - hard masked - gone You are proposing one more: - stable - unstable - masked by no keyword - candidate for hard mask - hard masked - gone I see that as pointless, the extra category buys you nothing (except as one more thing users can ignore). Even if you prompt the user during emerge to accept the candidate packages after reading the reason, you have not actually done anything different from hard masking it. The effect is the same - the user tweaks the system to allow the package to be emerged, user gets on with life. And one day the package is gone. Masking already accomplishes everything you propose, which is to communicate "there is something wrong with this package and it is in danger of leaving the tree. To get it out of this state, you need to take action". As for what constitutes "take action", well that is highly variable and isn't something that easily submits to categorization. Better to give the reason in a plain text comment with a link where interested users can go to start the rescue process. You also didn't give any examples of how "inclusive" could work. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?
On 14/04/2013 12:52, Tom Wijsman wrote: > If people don't agree with this apporach, we may want to solve the > actual problem in a different manner; one could write `eselect elog` > just like we have `eselect news`, that would force them to process > through the log messages and just not simply ignore them. Listing that > there are unread elog messages upon the next emerge may be interesting. Speaking as a long time Gentoo user: I like this idea of displaying an elog summary reminder at the end of emerge. It's analogous to the preserved-rebuild, blocker, and failed emerge notices that are already there. There are insanely useful - emerge inside screen, reconnect later and just know the important stuff I need to tend to is right there on the screen. If possible I'd like to see categories of messages; some are pointless to me now like the mention of the kernel upgraded guide after installing kernel sources. I'd like to filter those out whilst keeping important stuff in (like all the recent udev spam) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On 21/05/2013 05:03, Daniel Campbell wrote: > That's missing the point. If you don't run systemd, having unit files is > pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems > like a hack instead of something more robust. Why include systemd unit > files (by default, with no systemd USE flag, thanks to the council...) > on a system that's not using it? 154 files isn't negligible unless > you're flippant with your system and don't care about bloat. Unused > software sitting around *is* a waste of disk-space. > > Some people (like myself) came to Gentoo to avoid putting systemd on > their systems and to make use of the great choice that Gentoo allows. > This push to make systemd a "first level citizen" or whatever reeks of > marketing. If there is desire among users for unit files, they can > contact upstream or maintain their own set of unit files. It's not like > they're hard to write. > This is such a weak argument it's quite laughable. I don't like gnu info files. Neither me nor anyone I know can figure out how to drive info. So, let's rip all the info files out of every package; leaving the 3 users who do know info free to grab their copies from upstream. I mean it's not like it's hard or anything, and info files are easy to write. Daniel, you should just get over it. Having choices means you let the other guy have his choices too. Sometimes that means you have to let that guy have a little bit of his infra lying around so his choice is possible. And no-one ever said having choices means your exact personal preferences wrt every little thing will be baked in. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On 22/05/2013 23:39, Daniel Campbell wrote: > I do not consider Gentoo to be only about my own choices, but as a user, > who else's choices am I going to consider when I administer my system? > I'm happy for any new choices as long as they don't step on mine. I > think that's fair. Your choices are necessarily constrained by the fact that other people also have choices, and those people use a copy of the same machinery you use to implement their choices. You do not operate in a vacuum, and you cannot consider just your own choices and get a sane result - Godel proved that this cannot happen in this universe, in much the same way you cannot multiple two and three and get nine. Now, you cannot know what choices I've made here on my systems, but you do know that I have choices and you must consider that fact when making your choices. This has many side-effects, but the most common is that often you have to give a little to get a lot. In the case of systemd - people like Canek have the choice to use it, and to give him that choice you pretty much have to tolerate that all our machines are going to get unit files. That's the bit where you give a little. It works in reverse too. If you want KDE you get .desktop files and so does everyone else, and they too must give a little. If the generic machinery (aka package managers) that deals with this stuff doesn't quite cut the mustard as you would like, you still retain the ultimate choice: rm or it's expedient cousin INSTALL_MASK -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] perl herd needs your help
On 30/07/2013 13:18, Mikle Kolyada wrote: > Hi folks! > > We need new active devs. Now we have ~200 bugs assigned to perl, but we > have new tracker too. (https://bugs.gentoo.org/show_bug.cgi?id=478714). > > 469 packages to update to EAPI >= 4. We have no enough time/resources to > do it singly. Please help us! > Long-time Gentoo user, not a dev ;-) I've been looking for a way to contribute back to Gentoo for a while, this might be a nice easy way to get going. And I get to use perl packages a lot at work. Would you be OK with a proxy-maintainer? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon
On 03/08/2013 13:43, Rich Freeman wrote: [snip] > I think the only real issue is the wording here. [snip] Agreed. Reading William's post, he's really just expressed in his own words what ~arch is all about: we accept the possibility of breakage. Everything after the first two sentences is redundant - perhaps the protest is more about that and the unfamiliar wording than anything else. I read it as an announcement of a new major version, and nothing more than that. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] renaming gentoo-oldnet
On 06/08/2013 00:09, Robin H. Johnson wrote: > I'm replying the start of this thread, rather than picking a single > person to respond to. I DO want more brainstorming on ideas for the > naming of the package, and I think people need to cast a wider net for > naming ideas. > > I'm most certainly not planning to get rid of the package whatsoever, > many of my systems have complex configurations that are made MUCH easier > with oldnet than any other network configuration system I have found. > > Goals of gentoo-oldnet: > - Make oldnet functionality available to users of other init systems > [1][2] > - If a package upstream is forcing you towards systemd, you shouldn't > have to lose other very useful packages. > - Seperate out development cycle from core OpenRC > - oldnet accounts for more than 30% of OpenRC bugs, and a large > fraction of the codebase. > > History of the oldnet name: > - It's only called oldnet because when Roy introduced 'newnet', what we > consider to be 'oldnet' didn't actually have a separate name. > > Various proposed names (in no specific order): > - openrc-oldnet (implies OpenRC, and has 'old'). > - openrc-gentoo-net (implies OpenRC) > - gentoo-networking (does this mean newnet is here too?) > - gen-net (ditto) > - netrc (conflicts) > - opennetrc (implies OpenRC) > - 'net run control' (hard to search) > - 'net run configuration' (hard to search) > - multi-net (conflicts) > - netctl (conflicts) > - netcfg (conflicts) > - netconf (conflicts) > - enet (conflicts) > - posixsh-netconf (conflicts netconf) > - nettool (conflicts) > - netcfgtool (conflicts) > - posixnet (conflicts) > - shnettool > > Naming goals: > - Should describe what it does > - Does NOT have a name conflict as verified by Google. > - Does NOT imply OpenRC. > - Implying Gentoo is fine, as it's where the package comes from. > - Should drop 'old' > > I think we should focus on the first goal the most: > "oldnet is a network configuring tool in pure POSIX shell" > So we probably want the substring 'net' somewhere in there. Beyond that, > all suggestions are welcome. > > [1] There was a failed GSOC project that I mentioned several years ago, > that was to support ALL openrc style init.d scripts on Upstart, so > oldnet would have worked implicitly. Unfortunately the student didn't > actually do ANY work. > > [2] The configuration itself ends up broken into two parts: > - directives that control the startup dependency tree. > - directives that control the actual configuration. > The former will need to be interoperable or exported to other init > systems in some way (hopefully dynamically), the latter can stay the > same. > The software was originally called "net", right? Perhaps not officially, but certainly colloquially. Why not just keep the name "net" and leave other newer systems to come up with their own names? I do agree that modifiers "old" and "new" are bad ideas - they come about because of the environment and no the software itself. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] rfc: stabilization policies
On 20/08/2013 21:24, Tom Wijsman wrote: > On Tue, 20 Aug 2013 13:19:10 -0500 > William Hubbs wrote: > >> All, >> >> I'm not really sure what the answer to this problem is, so I want to >> know what the group thinks about how we can handle it. >> >> During the last release of OpenRC, I learned that people *do* run >> production servers on ~arch. > > While I don't, and asked it just because of the large amount; it > appears from some things lately, and not just OpenRC, that there is a > certain group that regards ~arch as some kind of new stable. > > This isn't solely about versions entering ~arch, but also about > versions leaving ~arch; as ~ is for testing, people should expect their > version to break and they should also expect that they cannot rely on a > version remaining in the Portage tree, that's just wrong... As a long time user and citizen of -user I can tell you what the general feeling of arch vs ~arch there is: ~arch is plenty good enough for everything except very mission critical stuff arch has plenty old stuff in it ~arch does not break every other day, and breakage is actually surprisingly rare. And, it's usually confined to openrc/udev/systemd/baselayout and other critical packages where one just knows upfront anyway that danger may lurk ahead. Some folks like me sync daily and accept that I deal with occasional breakage maybe once a month. Usually I just mask an offending package and move on. Others wait a few days and if no reported bugs, then emerge it. I get the sense that hard masked and - is the new testing, ~arch is new stuff and arch is for fuddy duddys that can't abide breakage of any kind (very much like debian stable actually). I also get the sense that arch progresses too slowly for many people. How long did we wait for MySQL-5.5 to reach arch? Folk wanted that one in stable reasonably early and mixing arch/~arch is very very bad in real life. Hence the recommendation to switch to ~arch, and it usually works out just fine. Hey, maybe you guys are doing your job in ~arch *too well*, to your own detriment :-) Something to consider? [snip] -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] rfc: stabilization policies
On 20/08/2013 22:25, Tom Wijsman wrote: > On Tue, 20 Aug 2013 22:00:52 +0200 > Alan McKinnon wrote: > >> As a long time user and citizen of -user I can tell you what the >> general feeling of arch vs ~arch there is: > > Thanks for jumping into the discussion. > >> arch has plenty old stuff in it > > Yes, it keeps me from using it; I would have to unmask too much... > >> ~arch is plenty good enough for everything except very mission >> critical stuff >> >> ~arch does not break every other day, and breakage is actually >> surprisingly rare. And, it's usually confined to >> openrc/udev/systemd/baselayout and other critical packages where one >> just knows upfront anyway that danger may lurk ahead. >> >> Some folks like me sync daily and accept that I deal with occasional >> breakage maybe once a month. Usually I just mask an offending package >> and move on. Others wait a few days and if no reported bugs, then >> emerge it. > > This really sounds like what would be the description of stable; I > mean, for mission critical stuff someone would plan out a migration and > "test" the upgrade prior to applying it to the server. For the rest, > except for maybe that critical packages shouldn't break; an issue once > a month is something that slips through, eg. see the stable bugs... > >> I get the sense that hard masked and - is the new testing, > > Actually, hard masked is usually something that is really broken; while > there are some things masked for some other reasons, you can't really > regard it as testing. But yeah, as for -, it could be considered > testing; although it is often broken, because of broken patches, ... > >> I also get the sense that arch progresses too slowly for many people. > > +1 that's one of the points that came up on IRC; 30 days and more > being too long, because not everyone follows up with that time > schedule (we are people, not cronjobs), it even gets a bit longer... > >> How long did we wait for MySQL-5.5 to reach arch? Folk wanted that >> one in stable reasonably early and mixing arch/~arch is very very bad >> in real life. Hence the recommendation to switch to ~arch, and it >> usually works out just fine. > > Yes, but we don't want to end up having everyone having mixed trees or > be on ~arch; if we do, stabilization is going to become a wasted effort. Perhaps the area to be clarified is "what is the intended risk profile for arch and ~arch?" stable and unstable mean very different things to different people, they are quite overloaded terms, so a proper definition is in order. Then users can also accurately just what they are going to get in arch as well as the intended level of stability. We already have a good beginning with the usual description of ~arch as "works pretty much OK most of the time but new ebuilds go in here first so expect some breakage sometimes". Let's express that in terms of risk. Something else we should also keep in mind - binary distros often recommend that autoupdates be enabled. If people do this it changes the game play as they really don't know what is coming down the wire at all. Gentoo is different - nothing changes until you sync and emerge world and this really does require that the sysadmin eyeballs the output. This removes a lot of the risk from the devs (you can't really know what my USE will do on my end so I must assume some responsibility for my choices). I do believe this gives the devs a lot of wiggle room to get things into arch quicker without having to test and verify every little thing. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] rfc: stabilization policies
On 21/08/2013 03:54, Doug Goldstein wrote: > Its also precisely that mix and match that might cause instability due > to people not testing things. Case in point QEMU 1.6.0 just came out and > it went through a number of release candidates but no one ever saw that > it depends only on Python 2.4 but actually needs Python 2.6. That's kind > of like Gentoo, a package says it depends on libfoo 1.0 or higher and > the dev that tested stable baz 0.8 confirmed it worked with libfoo 1.0, > but baz 0.9 in ~arch still depends on libfoo 1.0 but really needs libfoo > 1.1 and libfoo 1.1 is ~arch as well. So the developer running ~arch > believed that baz 0.9 works fine since he has ~arch libfoo. > > My point is what Gentoo calls "stable" is just something that usually 2 > or more people have compiled and installed vs ~arch which 1 or more > people have compiled and installed. > +1 I think comparisons with the RHELs of this world to find what stable means are invalid. Gentoo does not play in RHELs space, and anyone who tries to deploy Gentoo where RHEL is a good fit is somewhat of a fool [Aside: I'm a huge Gentoo fan, all my personal machines are Gentoo or FreeBSD and yet I have banned Gentoo outright at work: juniors cause me too much headaches, and Centos fixed all of that] Gentoo simply cannot offer the same guarantees about stable that RHEL can, mostly for reasons of manpower. The best we can do is to state that we are confident stuff works pretty much mostly OK and doesn't break for everyone, so the user can now do their own tests and decide. Let's also keep in mind that Gentoo is a meta-distribution - it lets you build your own distro. So all the heavy QA lifting that RHEL does for you, you now have to do yourself (that role bumps one run down the ladder). The classic meaning of "stable" just doesn't quite fit in that scenario. And, a truly stable mission-critical system is one that has all the required features and emerge is never run again except for bug and security fixes. A rolling release will never be truly "stable" What I'm saying is let's not set the bar for stable too high. Our targeted userbase is somewhat unique in the world. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On 03/09/2013 22:11, Tom Wijsman wrote:
> On Tue, 3 Sep 2013 14:03:14 -0500
> William Hubbs wrote:
>
>> On Tue, Sep 03, 2013 at 10:25:19AM +0200, Ulrich Mueller wrote:
>>>>>>>> On Tue, 3 Sep 2013, Tom Wijsman wrote:
>>>
>>>> On Mon, 2 Sep 2013 14:21:52 -0500
>>>> William Hubbs wrote:
>>>
>>>>> I can see why someone might want to use escape codes for color
>>>>> displays, etc. However, imo, escape codes do not belong in log
>>>>> files.
>>>
>>>> They belong there so future display can remain colorful.
>>>
>>>> Why do they not belong there? What do people have to do who want
>>>> them?
>>>
>>> Escape sequences have been designed for communication with
>>> peripheral devices, not for markup or as a storage format.
>>>
>>> Also "future colorful display" generally won't be portabe because
>>> escape sequences depend on the setting of the TERM variable. (And
>>> again, software that emits them with TERM=dumb or TERM unset is
>>> broken.)
>>
>> Ulrich has summed this up well here. The bottom line is that escape
>> sequences are for communicating with the user's peripheral devices.
>
> Nice summary. But, it is also communicating with my peripheral device.
>
>> Since yours may not be the same as the user's who created the log, you
>> don't even know that yours will respond the same way.
>
> Sounds like something we need to standardize. Although, from the many
> build logs I have came across; it does respond fairly well in most of
> the cases, I am yet to come across a build log that displays bad.
>
> And for that occasional build log, stripping isn't a hard thing to do.
>
>> I don't care what goes to the user's terminal, but these escape
>> sequences do not belong in log files.
>
> And then I asked the questions that I'd like to see answered:
>
> Why do they not belong there? What do people have to do who want them?
>
escape sequences in logs (any kind of logs) are basically noise, they
make search and grep hard to use. They also make the log impossible to
read properly if your terminal type is not the same as what was in
effect when the log was created. And they are essentially candy. A log
without escapes that you wish had them is still usable. A log with
escapes you wish were absent is impossible to use sanely.
The solution is obvious - default to writing plain text to log files and
give the user an option to enable escapes in the log if {s,}he chooses
to have it. This does mean you can't use tricks with tee.
I *do* like colorized text on my terminal, but I do believe we ought to
keep defaults sane - the minimum that could possibly work. Everything
extra should be optional
--
Alan McKinnon
alan.mckin...@gmail.com
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On 03/09/2013 23:00, Magnus Granberg wrote: > tisdag 03 september 2013 22.41.14 skrev Alan McKinnon: > >> I *do* like colorized text on my terminal, but I do believe we ought to >> keep defaults sane - the minimum that could possibly work. Everything >> extra should be optional > > What about NOCOLOR="false" in make.conf see man make.conf for more info. > /Magnus That affects terminal output too. It does not seem desirable to force terminal and logs to always have the same setting. To my mind the sane approach would be individual config settings for both with sane defaults. But, and here's the catch, that then means one can't simply tee output to two places. There would have to be two output threads. This seems like a LOT of work to implement -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On 03/09/2013 23:03, Rich Freeman wrote:
> On Tue, Sep 3, 2013 at 4:41 PM, Alan McKinnon wrote:
>> The solution is obvious - default to writing plain text to log files and
>> give the user an option to enable escapes in the log if {s,}he chooses
>> to have it. This does mean you can't use tricks with tee.
>
> Not sure it is so obvious.
>
> Log files are about capturing information. Escapes are about the
> presentation of information - a reporting feature not unlike
> pagination/etc. It wouldn't make sense to embed page numbers in a log
> file - if they are desired they should be added at the time the
> information is presented, just like escape sequences.
>
> It seems to me that the cleaner situation would be to capture
> information in the logs, and use a pretty-printer of some kind to make
> it look nice. Terminate output should be made to look nice when
> directed at a terminal.
This implies that the log can only then be viewed with a pretty-printer.
I wouldn't want to be the maintainer that has to deal with outraged
users if that becomes the case.
> Of course, the ultimate result of the whole logs-are-information
> concept is something like the systemd journal, but I won't go there.
> I'm not sure that would really help here - the challenge is more about
> the actual content and not the metadata.
So do what we've always done in Unix-land: leave the decision up to the
user. Build logs can always be regenerated (run emerge again) if the
ANSI sequences truly are vital whilst troubleshooting a specific log.
And we already do this for localized logs if the dev can't make sense of
non-English messages. It only becomes a problem if the log is for one of
that small number of loong builds (libreoffice, kdelibs etc)
--
Alan McKinnon
alan.mckin...@gmail.com
Re: [gentoo-dev] last rites: dev-db/edb
On 19/09/2013 07:43, Vadim A. Misbakh-Soloviov wrote: > 19.09.2013 11:44, Michael Sterrett пишет: >> # Michael Sterrett (19 Sep 2013) >> # dead upstream and unused by anything in the tree >> # masked for removal on 20131019 >> dev-db/edb >> > > Are you sure, that enlightenment is dead? > Not that I'm opposite to delete the dep of old prehistoric version of > enlightenment, but I just can't get, why do you think that upstream is > dead... > enlightenment is not dead, edb is. It was replaced with eet years ago. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] newsitem: initramfs required on Linux systems with separate /usr
On 25/09/2013 16:51, Rich Freeman wrote: > On Wed, Sep 25, 2013 at 10:09 AM, Ian Stakenvicius wrote: >> William, I think what Tom was mentioning here is that he thinks a >> one-sentence answering the "Why" would be a good idea to have in the >> news item, so users that don't have a clue on all of these sep-/usr >> issues will get an idea of why the change is being made. > > How about something like: > Due to many upstream changes properly supporting a separate /usr > without an initramfs has become increasingly difficult - despite all > our efforts it already breaks in some exotic configurations, and this > is a trend likely to grow worse. if you add "For more info, see " after that paragraph, most users can have their questions answered in the simplest way possible. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
On 02/11/2013 17:03, Michał Górny wrote: > I was considering writing a news item for it but we discussed it on IRC > and decided that users are really expected to be able to handle > themselves, especially wrt to: > > 1. using 'emerge -Du @world' to upgrade their systems, > > 2. reading the blocker output to see that it states > ' which suggests: what if I upgrade to > 1? Sadly, it's somewhat common for (newish) users to not know what to do with that. Blocker output can be quite daunting in the beginning, especially if it's in the middle of 20 other things portage is also updating. It's not easy to parse this stuff; I've been using gentoo for what feels like forever and I still haven't managed to hard-wire my head to read blockers like an idiom. I have to study it and usually end up reading the affected ebuild directly. The basic problem is that there's a lot of information to convey re a blocker, but to new users it all just looks like noise. One set of questions that were never answered and probably do deserve some kind of notification: 1. What exactly is python-exec anyway? 2. Why are there two, in dev-python/ and dev-lang/ ? 3. One has a version of -1, which is *highly* unusual, what is that exactly? 1 more than -? 4. There is some kind of migration going on between an old and new python-exec, but I can't understand it using only standard portage tools. An advance notice was probably warranted in this case, not to avoid bugs, but just to alert folk that something is coming down the wire and a short description of what it's trying to achieve. Most folks are naturally suspicious of anything that alters their python setup. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
On 03/11/2013 01:45, yac wrote: > On Sat, 02 Nov 2013 19:19:21 -0400 > "Anthony G. Basile" wrote: > >> On 11/02/2013 06:09 PM, yac wrote: >>> I don't know how this releng stuff works. I bet there is lot of devs >>> who don't. >> >> This is why you should announce risking commits. Because you may not >> know what it will cause, but others will. >> > > If I don't know in the first place, how do I know it's risky? Assessing risk is somewhat intuitive and relies heavily on experience. python-exec changes python wrapper scripts, emerge is coded in python. You have the makings of a circular dep right there and alarms bells should already be going off in your head. With risk, you almost always already DO have more information than at first appears. Learn to trust the little voice in your head, when it pipes up rather be careful and double check. > > Afaik there is no official way to update gentoo, is there? It's always been "emerge -avuND world" > > I personally got used to -uaNDv and I don't even know what exactly is > the difference and it's implications between that and just -uD the difference is -N, it's in man emerge -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
On 03/11/2013 12:53, Michał Górny wrote: > Dnia 2013-11-03, o godz. 10:53:13 > Alan McKinnon napisał(a): > >> One set of questions that were never answered and probably do deserve >> some kind of notification: > > I can help you with these. However, I don't know on how much of it > a random user cares. > >> 1. What exactly is python-exec anyway? > > It's the wrapper script that chooses the proper version of Python > scripts for the currently selected Python version. Say, when you > install 'foomatic' for p2.6, 2.7, 3.2 and 3.3, /usr/bin/foomatic is > linked to python-exec and it determines which one to run. > >> 2. Why are there two, in dev-python/ and dev-lang/ ? > > The intent is that the one in dev-python/ was not slotted and the one > in dev-lang/ is. This seems like the only sane way to support both > slots without rewriting all the existing deps (which doesn't seem to > work) or risking breaking the system. > >> 3. One has a version of -1, which is *highly* unusual, what is that >> exactly? 1 more than -? > > It is a plain virtual/compat/meta-package. It is a meaningless version > that is supposed to be larger than anything that was earlier in > dev-python/python-exec and it only pulls in dev-lang/python-exec. > >> 4. There is some kind of migration going on between an old and new >> python-exec, but I can't understand it using only standard portage tools. > > Yes. The goal is that everything will dep on dev-lang/python-exec:=. > However, we need to somehow keep things that deped on > dev-python/python-exec in the past working. > I didn't make completely clear that the questions were mostly rhetorical - I since figured out the answers for myself (I'm used to cat'ing ebuilds almost routinely to find stuff out). But thanks for taking the time to answer, I'll probably repost to gentoo-user and that will no doubt help many more people. It makes a good example - we both made what I believe is the same mistake. I underestimated that you would understand what I was actually asking, and the python team underestimated how much information to convey ahead of time. I do appreciate hugely all the effort Gentoo devs put into the project so this isn't a criticism at all, it's more data points of experience put out there to help devs make judgement calls for the future. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
On 04/11/2013 14:28, Tom Wijsman wrote: >> The only way to get a more stable system is to do a emerge -e world >> > and update that way. At least that has been my experience so far. > I have never needed this; I wonder whether there exists an example case > for this, I only see this used when someone changes compiler / flags > and wants to ensure the whole system turns into rice. * > I've used this once or twice over the years to take care of inexplicable instability, the last time being right in the middle of kmail2/akonadi upheaval. I think it was in the KDE4.4 days. I strongly suspect the actual cause was inconsistencies around plug-in modules - the only thing I know of that portage and tools like revdep-rebuild can't really detect. I must stress that it's an exceptionally blunt hammer of a tool and not to be used lightly. It's really the very very last resort, only suitable when the cost of my troubleshooting time is more than the cost of cpu cycles over a weekend. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On 06/11/2013 17:26, Kent Fredric wrote: > > On 7 November 2013 04:15, Ian Stakenvicius <mailto:a...@gentoo.org>> wrote: > > > The bug that was filed, is that a user didn't do a full emerge -uDN > @world prior to emerging (upgrading?) firefox, and they had icu-49 > already installed. Because the firefox dep didn't have a minimum > version, portage didn't see upgrading icu as a requirement before > firefox emerged. > > > Theres another scenario not listed here which can still happen: > > The end user has a copy of icu-49.ebuild somewhere in their portage > layout still. > > Either this is due to a published overlay containing it, or them locally > maintaining their own private overlay. > > The "update world" thing *may* still work in such a circumstance, but > you'd have to change the policy to say "Update to a something that is in > ::gentoo before merging packages from ::gentoo", which is getting a bit > logically messy. > > Even then, it may not be apparent that there is a problem, for instance, > if they have the overlay in place, *AND* they've locally masked newer > versions of icu, for some reason ( perhaps they have 3rd party software > they're locally maintaining that requires an older version of icu ). > > Here, the *only* sane approach is for firefox to declare it needs a > certain version of icu as a minimum, regardless of what is, and what > isn't visible in tree, so that the end user at very least gets told > "firefox needs this", and its then their responsibility to sort out the > problem if they've caused one. I agree with this sentiment. It's always been my view that the needs of a package are driven by the package itself, not by the tree. Rationale: A package will build and run as long as it's own requirements are met regardless of what the tree states. We have layman overlays and user's own overlays. Whilst these are not 100% supported by Gentoo they are not banned either. They are also not "barely tolerated", it's more a case of overlays are not a problem and users are welcome to use them as long as they don't conflict with or break the tree for that user. This needn't be onerous. Presumably ebuild maintainers read the README and Changelog, these often state the versions of deps the package supports. Take that information and put it in the ebuild. Maintainers are under no obligation to provide the absolute minimum version of a dep, only at least one that will work. If the user decides to make other versions available to his system by whatever means, then portage can deal with it by and large transparently. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On 05/12/2013 01:45, Patrick Lauer wrote: > On 12/05/2013 05:30 AM, Mike Gilbert wrote: >> On Wed, Dec 4, 2013 at 4:25 PM, William Hubbs wrote: >>> On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen wrote: >>>> seems like a virtual that wouldn't do anything useful except pull in >>>> random package(s) a la binary-distribution style >>> >>> What about the stages? Don't we need some form of net support in >>> stage 3? >>> >> >> That's debatable. For a typical install, the user has to install other >> basic stuff like a boot loader, kernel, etc. So having them also >> select a network config framework seems logical. >> >> Is there a use case for a stage3 in which installing netifrc by hand >> is impractical? >> > Well ... > > I remember filing a bug quite a while ago because we didn't have a dhcp > client included anymore. This made installs quite annoying because > before it was stage3, kernel, bootloader, go! > > And now it was go ... stop ... reboot ... install dhcp client ... > grremblwrrxrmkrxtlmrrrg reboot > > That extra step of whining was loud enough to have openrc fixed to be > able to use busybox udhcp, so that "out of the box" most network worked. > > ... and now people are trying to do the same again. > > I would STRONGLY recommend having a working network setup included in > stage3, so that compared to now nothing changes. In this day and age not having a network-capable install out the box is silly. The first major action after unpacking the tarball is going to be adding new packages and doing updates, the source code for which is on the network. Network is only slightly less necessary than disk drivers - almost everyone is going to need it. So just ship the thing that the majority will need, for the few that have a valid case to not need networking after install, it's a simple matter for them to disable it. The default install doesn't need to have a network provider with all the bells and whistles, netifrc is perfectly adequate (especially if dhcp is enabled as it always was for years) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: New global use flags: 3dnowext, mmxext, ssse3, sse4_1, avx, avx2
On 16/12/2013 17:38, Michael Orlitzky wrote: > On 12/16/2013 05:44 AM, Duncan wrote: >> Matt Turner posted on Sun, 15 Dec 2013 15:34:13 -0800 as excerpted: >> >>> sse3: Use the SSE3 instruction set (pni in cpuinfo) >>> ssse3: Use the SSSE3 instruction set >> >> I'd suggest a parenthetical on ssse3 as well, something like: >> >> ssse3: Use the SSSE3 instruction set (NOT sse3, three s) >> >> I know that confused me for awhile, and I tend to be reasonably literate >> (as a user, anyway) on this sort of thing, > > Why not go all the way? > > "Enable use of the SSSE3 instruction set (NOT sse3). This is needed by > projects which contain assembly code or which use certain compiler > intrinsics. It is not a replacement for CFLAGS and friends." The second and third sentences add nothing to the description. They only describe how cpu instruction sets in general work and are used, but tell you nothing about ssse3. I recommend a short expansion on what ssse3 is, and shortening the rest while retaining it's meaning, then modifying all cpu instruction set flags similarly > You can make a case for brevity, but how many times do you find yourself > (a) reading USE flag descriptions, and (b) thinking they're too long? It's possible to have a very verbose, and meaningless, description. be verbose by all means if the verbosity carries useful information -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: New global use flags: 3dnowext, mmxext, ssse3, sse4_1, avx, avx2
On 16/12/2013 22:17, Michael Orlitzky wrote: > On 12/16/2013 01:21 PM, Alan McKinnon wrote: >>> >>> "Enable use of the SSSE3 instruction set (NOT sse3). This is needed by >>> projects which contain assembly code or which use certain compiler >>> intrinsics. It is not a replacement for CFLAGS and friends." >> >> The second and third sentences add nothing to the description. They only >> describe how cpu instruction sets in general work and are used, but tell >> you nothing about ssse3. > > USE flags are a user interface, not documentation. A good description is > one that helps the user decide, "do I want to enable this?" I'm not > particular about the wording -- and my use of "needed" was a mistake -- > but with that purpose in mind, a good description should contain, > > 1. Why might I want to enable this? > > 2. Why might I want to disable this? > > So e.g. my description is missing #2, "You should not enable this unless > you have a processor supporting SSSE3." > > >> then modifying all cpu instruction set flags similarly > > Yup. Is it worthwhile adding a link in the description to a resource that describes a USE flag in greater detail? Most flags are obvious as to what they do, like jpeg/png/gif: the user simply asks himself if he wants to use those formats. Most flags are like this, and come down to user preference; portage merges in any missing parts required cpu sets are different: they also depend on whether they CAN be used in a given environment. Portage cannot know if ssse3 will work for the cpu running the code so cannot fill in the missing bits. The user must first check if the intended cpu supports ssse3 at all (often preceded by finding out how to find this out). That's a lot of vital ,necessary info and it deserves the full documentation treatment. A USE description is not the place for that, but a link could work nicely. Especially if the linked page describes the intent and usage of the USE flag in full. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] RFC: storing predefined INSTALL_MASK directory lists in repos
On 11/01/2014 18:01, Michał Górny wrote: > Dnia 2014-01-11, o godz. 16:56:37 > Luis Ressel napisał(a): > >> I've got an additional proposal: It would be interesting if this >> feature could also make use of the LINGUAS var for selectively >> filtering /usr/share/man and and /usr/share/locale, as most ebuilds >> don't respect this variable natively. > > That's a side goal. > > I was thinking of something like: > > INSTALL_MASK="linguas -linguas_XX" > > that would remove all linguas except for language XX. That is similar to USE="no" with all the attendant user support problems it brings. A far better method from a user point of view is to install the linguas the user explicitly asked for. Your proposal as worded will be taken at first glance to mean "install all linguas, but not XX" as most users won't see the MASK portion and forget to flip the logic around in their head. How much work is it to get native support for LINGUAS into all ebuilds? That would be the intuitive place considering there is already USE flags for LINGUAS. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] RFC: storing predefined INSTALL_MASK directory lists in repos
On 11/01/2014 18:52, Michał Górny wrote: > Dnia 2014-01-11, o godz. 18:15:09 > Alan McKinnon napisał(a): > >> A far better method from a user point of view is to install the linguas >> the user explicitly asked for. Your proposal as worded will be taken at >> first glance to mean "install all linguas, but not XX" as most users >> won't see the MASK portion and forget to flip the logic around in their >> head. > > As said on the other mail, I think we could just make portage > implicitly convert LINGUAS into INSTALL_MASK. That is, use the old > variable and give it a bit of new behavior. Do you mean retain LINGUAS in make.conf and remove it from "emerge -p" output? I don't know much about how LINGUAS works behind the scenes, but you seem to be proposing a scheme that works something like this: 1. User specifics what LINGUAS they want in make.conf 2. Portage magically and invisibly installs files only for that LINGUA That seems a good approach, it unclutters emerge -p output [the amount of clutter that causes, together with APACHE2_MODULES, CAMERAS, PHP_MODULES etc is quite unbelievable] and gives the user what they asked for. If you hide the negative logic in the implementation that is double bonus > >> How much work is it to get native support for LINGUAS into all ebuilds? >> That would be the intuitive place considering there is already USE flags >> for LINGUAS. > > Honestly? I'm all limbs against LINGUAS in its current form. It's just > extra dumb. > > We have basically two cases: > > 1. packages that make LINGUAS into USE flags and use them to control > l10n. It's just useless extra work and extra rebuilds for locale > change. > > 2. packages that respect LINGUAS implicitly. That is, install only some > of the files silently and you don't even know which were enabled. > > install-mask provides a clean framework to strip linguas with > binpackage friendliness potential. > -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 16/01/2014 19:56, Rich Freeman wrote: > On Thu, Jan 16, 2014 at 10:54 AM, Peter Stuge wrote: >> Sergey Popov wrote: >>> As i said earlier, problem begins when we NEED to stabilize >>> something to prevent breakages and arch teams are slow. >> >> Isn't that simply a matter of assigning and respecting priority on >> bugs properly? > > Are you suggesting that we should forbid people from working on > lower-priority bugs anytime a higher-priority bug exists? That would > probably just reduce the amount of contribution. You can't force > anybody to work on the higher-priority ones. > > Sure, in an ideal world people work on the high-priority stuff. > However, often somebody either prefers to work on a lower-priority > bug, or finds it easier to do so. Simply marking a bug as > high-priority doesn't make the bug get resolved. > > Bottom line is that people work on what they work on. Unless you can > find people to work on the stuff that you want done you need to make > work go away. +1 "Respecting bug priority" feels like that corporate BS I have to put up with every day. Like every sysadmin team world-wide, we're understaffed so the only bugs that get any attention at all are ones where some fool of a manager thinks he can shout louder than anyone else. Gentoo is not like that. As you say, devs will work on what they feel like working on, heavily influenced by their own sense of responsibility. We have nothing to offer maintainers except fuzzy-feel-good and recognition; we have to trust them to do the right thing. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 16/01/2014 20:26, Peter Stuge wrote: > Alan McKinnon wrote: >> "Respecting bug priority" feels like that corporate BS I have to put up >> with every day. > > Gentoo is incorporated so maybe that fits. ;) > > On a more serious note, please try to understand what I meant rather > than just what I wrote. > > I wrote both "assigning" and "respecting"; your gripe with "corporate BS" > may be a result of how priority was assigned to your bugs, and likely > amplified if you can't do much to influence that process. If you only > get a priority shoved down your throat you of course can't really > respect it. > > For priority to have any meaning on bugs.g.o there would need to be > some buy-in among developers to actually want to work together to > assign the proper priority to each bug. > > Bug trackers aren't management command and control tools, they are > hive minds which just remember what workers agree on anyway. > > >> the only bugs that get any attention at all are ones where some >> fool of a manager thinks he can shout louder than anyone else. > >> We have nothing to offer maintainers except fuzzy-feel-good and >> recognition; we have to trust them to do the right thing. > > Nobody will do the right thing if they don't know what it is. > > Recognition can certainly communicate that higher priority bugs are > more important, but honestly, I wouldn't want someone who needs to > be told that explicitly on my (the Gentoo) team in the first place.. > > Disclaimer for anyone who might find this upsetting: Of course people > always have limited scope, and it is perfectly fine if high priority > bugs can simply not be fixed by whoever has time to work on bugs at > any given moment. > > IMO, closing bugs without having the right fix has negative value. > > I know that it can be depressing and demotivating to have too many > bugs, just like it is to live in a too messy room, but I really do > think that the best solution is simply to pick one thing up at a > time. It may take a long time, but in the end the room is clean. :) When relying on folk's goodwill (like in the open source world), I find there are really only two priorities 1. the bug breaks stuff 2. everything else with possibly a #3 - stuff that doesn't matter, can be done whenever. Gentoo devs have shown time and again that they do take #1 seriously. After all, they are themselves Gentoo users. The team that is dealing with the bug may of course assign priority as they see fit as long as they mostly agree on what it is. I reckon the cardinal rule is "avoid as much as possible having priority set by someone who is not solving the problem". I think that comes close in my words to what you are saying. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] overlays.gentoo.org restoration & post-mortem
On 18/01/2014 09:04, Patrick Lauer wrote: >> which could link to the >> > infra page would be good here perhaps, so when an outage occurred ( at >> > least on the web side ) appropriate links to infra could be given. > The more sane fix would be low DNS TTL and rotating DNS to a different > IP if things are down. > > That is already in place: $ dig overlays.gentoo.org ; <<>> DiG 9.9.4 <<>> overlays.gentoo.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49989 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;overlays.gentoo.org. IN A ;; ANSWER SECTION: overlays.gentoo.org.600 IN CNAME spoonbill.gentoo.org. spoonbill.gentoo.org. 604800 IN A 81.93.255.5 5 minutes downtime max if a switch needs to be done. 5 minutes is perfectly acceptable IMHO -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] overlays.gentoo.org restoration & post-mortem
On 18/01/2014 09:49, Alec Warner wrote: > On Fri, Jan 17, 2014 at 11:10 PM, Alan McKinnon <mailto:alan.mckin...@gmail.com>> wrote: > > On 18/01/2014 09:04, Patrick Lauer wrote: > >> which could link to the > >> > infra page would be good here perhaps, so when an outage > occurred ( at > >> > least on the web side ) appropriate links to infra could be given. > > The more sane fix would be low DNS TTL and rotating DNS to a different > > IP if things are down. > > > > > > > That is already in place: > > $ dig overlays.gentoo.org <http://overlays.gentoo.org> > > ; <<>> DiG 9.9.4 <<>> overlays.gentoo.org <http://overlays.gentoo.org> > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49989 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4000 > ;; QUESTION SECTION: > ;overlays.gentoo.org <http://overlays.gentoo.org>. IN A > > ;; ANSWER SECTION: > overlays.gentoo.org <http://overlays.gentoo.org>.600 IN > CNAME spoonbill.gentoo.org <http://spoonbill.gentoo.org>. > spoonbill.gentoo.org <http://spoonbill.gentoo.org>. 604800 IN > A 81.93.255.5 > > > > 5 minutes downtime max if a switch needs to be done. > 5 minutes is perfectly acceptable IMHO > > > infra TTL standards are 60 minutes for service CNAMEs and 30 minutes for > HA CNAMES. The TTL is 600 here (which is 10 minutes, not 5) because I > lowered it on 1/14 in anticipation of a machine failover, it was > previously 2 hours. Thanks for the clarification. Obviously I ran dig after you'd made the change. 60 mins is still acceptable for a CNAME IMHO. Wait one hour max to be able to sync in event of a change is not at all unreasonable. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On 01/20/14 15:59, Rich Freeman wrote: > On Sun, Jan 19, 2014 at 9:54 PM, Tom Wijsman wrote: >> #gentoo-qa | @hwoarang: pretty sure diego had the powerzz to suspend >> people >> >> Whether this has actually happened is something that is questionable; > > Not that this necessarily needs to make it into the GLEP, and I'm > still on the fence regarding whether we really need to make this > change at all, but things like access suspensions and other > administrative/disciplinary procedures should be documented. I think > whether this is a matter of public record or not is open to debate, > but I don't like the fact that we can really say for sure when/if this > has actually happened. Speaking as someone who had this power in his day job, for QA to be able to suspend accounts is a very bad idea indeed. It always ends badly. I suspended 20+ accounts in my current job over the years and the number of cases where it was the right thing to do is precisely 0. It was always a case of ill-advised action taken out of frustration, or bypass the training step, or don't try hard enough to reach the "infringer" and communicate like grown adults. Yup, I did all three. Suspending an account is a very serious thing to undertake, the effects on the suspended person are vast and this power should never lie with the person who is feeling the pain. Instead, there are well established channels to the body who can make the decision. If QA has a problem with a dev for any reason whatsoever, then QA should make a well-thought out case to that other body for decision. Anything else is madness and open invitation for it to all go south. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
I don't want to appear rude, but when reading this entire mail all I see is someone who has probably never had to do it for real. People are not machines. Volunteers really do not like having their freely given time nullified and access removed because one person thought it was deserved. Do you realise the message that is sent by denying someone access? You are saying that person is not good enough to work on Gentoo. Do you really want to send that message? Vast wholescale breakage is very rare and not something you can base policy on. Rich's most recent reply is the most sane proposal I've seen so far. Revoking access is a human problem and is solved with human solutions. Do beware the law of unintended side-effects. On 01/21/14 16:56, Tom Wijsman wrote: > On Mon, 20 Jan 2014 16:09:46 +0200 > Alan McKinnon wrote: > >> Speaking as someone who had this power in his day job, for QA to be >> able to suspend accounts is a very bad idea indeed. It always ends >> badly. I suspended 20+ accounts in my current job over the years and >> the number of cases where it was the right thing to do is precisely 0. > > The relation between "using power" and "having power is a bad idea" is > non-existing; it is rather how that power is used that determines > whether it is a good idea than whether one is able to use that power. > >> It was always a case of ill-advised action taken out of frustration, >> or bypass the training step, or don't try hard enough to reach the >> "infringer" and communicate like grown adults. Yup, I did all three. > > The prior experience demonstrated here shows how frustration or lack of > proper communication are really good symptoms to investigate and learn > from; however, these symptoms seem non-existing with our QA lead. > >> Suspending an account is a very serious thing to undertake, the >> effects on the suspended person are vast and this power should never >> lie with the person who is feeling the pain. > > This is the core symptom of the way you do QA, if you are the person > that is feeling pain then you need to reconsider your QA position; the > thing feeling the pain here is the Portage tree, and the QA team is > just ensuring its quality and thus should not get emotional or > personally affected by the developers' changes to some bits 'n bytes. > > Of course one could see QA as defending the Portage tree with our heart; > but not that literally, at least not up to the point that one gets > painfully hurt or even just frustrated... > >> Instead, there are well established channels to the body who can make >> the decision. If QA has a problem with a dev for any reason >> whatsoever, then QA should make a well-thought out case to that other >> body for decision. > > Adding extra bodies adds more delay; furthermore, these bodies have > less time, understanding and more about the technical QA issue at hand. > > If a developer does an unannounced mass action that breaks the tree > severely or is heavily prohibited by policy, is unreachable while he > continues to commit this; then it would be handy to "temporarily" be > able to withdraw the commit access to bring it to that developer's > attention. This is under the assumption that we have tried to contact > the person multiple time and after a reasonable amount of time the > person has not responded; if we still then need to wait for another > team to notice, investigate and finally take action whereas we have > already took the decision, ... > > This is rather to note that we need have a talk to coordinate that mass > action and unbreak the tree, than it is to punish that developer by > hitting with a ruler on his/her hand; in a sense of "let's fix the > damage to the tree and proceed". > > There even can happen worse things; like misusing 'pkgmove', the > @system set or similar that can cause some real havoc. It is in this > occasion where a developer hasn't discussed or talked to anyone earlier > before proceeding with a change he knows he shouldn't do, as well as > ignoring us afterwards; that we simply temporarily cannot allow further > commits, simply because the developer seems "technically unable to > follow the policy and its enforcement". > > This is similar to how you have Gentoo support ops in #gentoo, Gentoo > chat ops in #gentoo-chat and individual ops in individual IRC channels; > if they had to rely on another body which would be the group contacts or > FreeNode, you would have to wait a long for them to kick, ban or mute. > > If the non-technical ComRel lead has this power, then why doesn't the > technical QA lead have th
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On 01/22/14 14:34, Patrick Lauer wrote: >> Do you realise the message that is sent by denying someone access? You >> > are saying that person is not good enough to work on Gentoo. Do you >> > really want to send that message? > Yes. And I have no problem being the Evil Guy who pulls the trigger, > err, presses the enter key. > > You are saying that *any* contribution should be accepted just to not > hurt someones feelings. No, I'm not even remotely saying that. Please go back and read gain what I did say. I never mentioned anything about "any contribution". What I did say comes after the qualifier "by denying someone access", which is a very far cry indeed from "any contribution". I also have no problem being the Evil Guy, because I am that sonofabitch. I really know what happens when you suspend/nuke/delete access because I have done it. And every single time it was the wrong thing to do. The only time it was acceptable is for a runaway script or similar, or an honest mistake where I can fix the fallout far faster than the user can. As the sysadmin and root, I know more about the systems than the users do, similarly in Gentoo land it's a fair assumption that the average QA person is more knowledgeable about the tree and policies than the average dev. So when QA takes action in a spirit of help and with communication in place, all is good and things usually work out well. When it swings the other way and suspension is done as a means of punishment (to whatever degree) then QA has stepped beyond the bounds of what QA is about and into something else. I still don't see any suggestions in this thread on how to limit the scope of what QA wants. No-one will seriously try prevent a good QA guy from limiting damage, but what happens when QA itself abuses the policy? And it will happen, we both know this. How does QA propose to curb that downside? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On 28/01/2014 14:37, Steven J. Long wrote: > I concur that "QA should be focusing on making stable, actually stable, > not more bleeding edge." That's not a "performance" issue as you put it, > except in management nuspeek. It's the whole bloody point of the distro, > in overarching terms: to test and stabilise robust ebuilds. That process > is what leads to better software, not staying at the "bleeding-edge" > and forgetting about robustness since "a new version is out." +1 Nice to see a dev echo my sentiments almost word for word exactly. 9 years later I'm still here, still running Gentoo on all my hosts (over 10 at last count excluding VMs). Why? Because Gentoo just.works.right.every.single.time, even on ~arch - and that is an amazing accomplishment for an distro never mind a USE based one. If I want bleeding edge I'll use funtoo or exherbo or unmask everything -. If I want the latest new! improved! shiny! crap re-implemented yet again and badly, there's Ubuntu or nightlies from rawhide. The joy of Gentoo is that it works on just about anything. Stable well-tested code continues to just work for the most part even on slacker arches even if the ebuild is years old. When stable is just a bit too stable for a specific case, we have overlays and /usr/local/portage/cat/pkg. This is why Gentoo works so well, because the weird arches still get to play on the same playground with the other kids. I work at a carrier ISP and you'd be pleasantly surprised to see just how many gentoo-powered vendor POC blackboxes come through the office from vendors wanting to sell their network magic. Business seems to have cottoned onto the idea that gentoo let's you stop wasting time with make and rather fire off emerge, doesn't matter what the silicon is. Slow arches is the price for supporting everything out there. But so what? If slow_arch_X is stuck on some old version of an @system package, who cares? It's not like portage will pick it for an amd64 box. An old ebuild is a file, it sits next to 178,477 files and does no harm, it only gets used on hardware that needs it. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] [RFC] Tightening EAPI rules
On 10/02/2014 18:05, Ulrich Mueller wrote: >> Removing support for it from a package manager should of course >> > happen much later (well after it is banned). > The package manager must be able to uninstall old packages, which > essentially means that support for old EAPIs cannot be removed. I feel this aspect needs to be limited, no user can reasonably expect Gentoo devs to retain support in the package manager for obsolete features indefinitely. We also shouldn't be too hasty in removing the support, but there has to be a cut-off point somewhere, a point of no return. It's probably measured in years, my thumb suck guess is 3 years after a given EAPI is finally obsoleted. As a real example - I know someone who proudly shows off a Gentoo host with a 2004 profile. Can he reasonably expect portage to still work flawlessly 10 years later? I feel no, luckily he agrees with me. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] [RFC] Tightening EAPI rules
On 10/02/2014 22:56, Alec Warner wrote: > On Mon, Feb 10, 2014 at 8:26 AM, Alan McKinnon <mailto:alan.mckin...@gmail.com>> wrote: > > On 10/02/2014 18:05, Ulrich Mueller wrote: > >> Removing support for it from a package manager should of course > >> > happen much later (well after it is banned). > > The package manager must be able to uninstall old packages, which > > essentially means that support for old EAPIs cannot be removed. > > > I feel this aspect needs to be limited, no user can reasonably expect > Gentoo devs to retain support in the package manager for obsolete > features indefinitely. We also shouldn't be too hasty in removing the > support, but there has to be a cut-off point somewhere, a point of no > return. It's probably measured in years, my thumb suck guess is 3 years > after a given EAPI is finally obsoleted. > > > Why is that unreasonable? It's unreasonable for me to expect you to support long-dead features and EAPIs. Unless you choose to support them of course, or if it's no big deal to support them (I have a hunch this last is not true, that it is a big deal actually). The bottom line is that I don't pay you to write the pm I use, so I have no expectation that stuff will always work forever. A host where portage has not been updated for 2 years is basically a moribund host > > -A > > > > > As a real example - I know someone who proudly shows off a Gentoo host > with a 2004 profile. Can he reasonably expect portage to still work > flawlessly 10 years later? I feel no, luckily he agrees with me. > > -- > Alan McKinnon > alan.mckin...@gmail.com <mailto:alan.mckin...@gmail.com> > > > -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On 23/03/2014 22:08, hasufell wrote: > Michał Górny: >> Dnia 2014-03-22, o godz. 15:33:27 Alec Warner >> napisał(a): > >>> https://wiki.gentoo.org/wiki/Package_Tags >>> >>> Object or forever hold your peace. > > >> I'd honestly prefer that -- if we should really keep tags in the >> tree -- to do that with a single 'metadata/tags' file or some kind >> of hierarchy there. Keep them outside the package directory -- >> bind packages to tags, rather than tags to packages. Keep all the >> commits in a single place without altering the ebuild work flow. > > > That sounds better. That way it is also easier to get some > consistency. E.g. tags can be discussed... but adding packages to tags > is up to the maintainers. > > The GLEP should maybe cover a basic set of tags. Then projects like > games, science etc could add their sets as well which may be a bit > more specific... instead of random maintainers adding random tags. Regular user/sysadmin chipping in: This topic seems a lot like a solution seeking a problem to solve, or alternatively a dev is looking for an easy way to describe stuff. Not that there's anything wrong with that, but the proposal as written is way too vague to be useful. Tags work best when they describe narrow, clearly defined attributes, and the thing they are applied to can have one, two or more of these attributes or sometimes even none. Music and movie genres are an excellent example - there are only so many of them and for the most part one can tell whether a tag really is a genre or not. Nothing resembling such limits are proposed in this GLEP, there's not even a recommendation of what the tags will describe or how everything will be tagged equally. What happens if someone zealously over-tags all of gnome and the same thing doesn't happen for kde? Does kde just not show up in tag searches anymore? So this just seems like a nice-to-have that hasn't been properly thought through. The main stated use of it is for packages that logically belong to more than one category. So instead of a general catch all, do whatever you want mechanism, let's rather solve that exact problem by for example adding a specific field to metadata eg "supplementary categories". Pick those that apply from a clearly defined list and store the data in a clearly defined place. Such a thing can be made more generic, by making it a clear mechanism to describe extra metadata and the things to be described go through a defined process first before making it into the list. this concept is not present in the GLEP as currently written. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On 24/03/2014 02:43, Tom Wijsman wrote: > On Sun, 23 Mar 2014 23:47:22 +0200 > Alan McKinnon wrote: > >> Tags work best when they describe narrow, clearly defined attributes, >> and the thing they are applied to can have one, two or more of these >> attributes or sometimes even none. Music and movie genres are an >> excellent example - there are only so many of them and for the most >> part one can tell whether a tag really is a genre or not. > > There are more ways to search for a music or a movie than a genre: Genre was just one example of tag usage for illustration. Doesn't mean there aren't other equally good or valid examples. > > What mood is it in? What are key elements of its plot or lyrics? > Where does it take place? For which audience is it meant? Which praises > has it received? What kind of style is it made in? What is it based on? > What is the attitude of it? What looks or effects does it have? Is it > appropriate for children? Does it contain explicit things? > > Let's do this for movies. I'm looking for a ... > > ... serial killer (key element) that is scary (mood)? > Carrie, Halloween, Saw, Scream, ... > > ... musical (genre) that makes one feel good (mood)? > Aaja Nachle, Frozen, Grease, The Sound of Music, ... > > ... good versus evil (plot) based on comics (based on)? > Batman, Sin City, Superman, The Avengers, ... > > ... goofy (attitude) hero (key element) where nothing goes right (plot)? > Due Date, Faulty Towers, Monty Python's Flying Circus, Mr Bean, ... > > These are results from an actual movie recommendation site; similarly, > the same exists for music too, where you can for example look for a > female american singer-songwriter singing catchy contemporary country. > > Getting back to Gentoo; when I would look for some package, I want it to > be a lightweight, do audio recordings, organize these audio recordings > and do effects on these audio recordings. So, I'll be looking for tags > like "lightweight, audio-recording, file-organization, sound-effects"; > if that's to broad, I can take two of them and test some of that. > > Thinking about the different types of things to search for; I'm > thinking about ... > > ... what the characteristics of the software are > (light/heavy, new/old, extensible/modular/nonstandard, ...), > > ... what the software can do (record audio, organize files, ...), > > ... what category (browser, development, DAW software, utility, ...), > > ... what kind of interface the software has to me (CLI, GUI, ...), > > ... what interconnectivity the software has (internet, bluetooth, ...), > > ... and so on ... > > We could make a list of types (some already mentioned above) and a list > of possible tags for that type to shape the tag system somewhat. Have you considered just how much heavy lifting that is? Who is going to compile the list of tags? Who is going to approve/disapprove tagable attributes and the tags themselves? How will you resolve disagreements people have? What about the case of a package maintainer that simply can't be bothered doing tags at all? I'm not against tagging per se, they can be useful. But they do have to be strictly controlled otherwise things get out of hand very quickly. Every case I've seen of software that uses a freeform tagging mechanism fails almost instantly as it becomes very inconsistent. I have one of these apps in a corporate setting right now, have you any idea how many ways people can come up with to tag the concept of "cloud"? I have tags in there where someone translated the word "cloud" to a different language! It sounded like a good idea at the time to them All in all, tagging is a huge amount of work and the odds of failure are high. People need to be aware of this reality. Wyatt Epp's post at 03:25 expresses very nicely in a more formal language what I'm saying. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] RFC: news item for upower
On 03/06/2014 21:50, Samuli Suominen wrote: > > On 03/06/14 21:58, Peter Stuge wrote: >> Steev Klimaszewski wrote: >>> Instead of belittling the users because they are wasting so much of >>> your time >> Causing a rougher transition than neccessary is a waste of users' time. >> >> I don't think that's awesome. >> >> >> //Peter >> > > I still don't understand how the news item helps anything, it's all > matter of running > one command, or two at most, `eix upower` after seeing blockers, seeing > 2 different > options, selecting which one to go with, emerging it > I'd say such handholding distracts real admins from the real news items > that actually > require paying attention :/ Yes, it *is* a simple matter of running one easy command. Portage does that for you with trivial ease. But portage doesn't tell you *which* is the one easy command. A news item does that. Please realise that groking Portage's output takes considerable skill, understanding and familiarity with the scene. It's much easier when you know what will be printed before you run it - perhaps you are in that position? I've been using Gentoo for 10 years and portage still baffles me more often than it should. I resort to reading the ebuild to figure it out. Funny thing is, portage has the same information available as I do so why doesn't it print more human-friendly output? At least we got past that "satisfied by no parents in slot" stuff and now we have cute carets that point to stuff like some compilers. The point is, human communication is vastly more powerful than machine communication in cases like these, and a news item fits the bill perfectly. There are still 1000s of users out there who haven't run across this upower stumble yet, a news item will help them a lot and will be very well accepted (aka Samuli gets brownie points from user for caring) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] RFC: news item for upower
On 04/06/2014 00:32, Tom Wijsman wrote: > On Tue, 03 Jun 2014 22:24:11 +0200 > Alan McKinnon wrote: > >> The point is, human communication is vastly more powerful > > +1 > > It might not be clear in the moment, because it looks like a ton of > bikeshedding and other ways some individuals would label this; but it > will be useful some time from now, when it leads to useful results. > > Having some people talk about things on a chat, forum, blog, ... might > have a short lived effect now with an occasional spike in the future; > but, a news item reaches a much wider public for a much longer item. > > Let's say someone upgrades his system in some weeks / months from now, > that person will be thankful that a news item was written about this; > instead of having this be part of the already though job of updating. > > Of course, there is a thing like "too much handholding" but I think > that's not the case here as the upower case pops up in a lot of places; > one does not have to forget that there is also "too little handholding". > > If it weren't for genkernel or a kernel seed to help me start out with > a booting system, I perhaps might have never started using Gentoo; I've > afterwards managed to change my config over time to look nowhere near > the original, but at least it makes me happy to have experienced the > handholding to bring me where I am today. These "little things" matter. > Indeed. It really comes down to a judgement call whether to compose a news item or not. I myself in my sysadmin day job get this right about 50% of the time if I'm lucky. I've learned (via hard knocks) that if a number of people raise concerns, then it very well might not be bikeshedding, it might be valid. Often as the BOFH I'm too close to the technical problem to notice the human elements - that needs a view from 10 feet back. News items are probably one of Gentoo's best ideas ever. -- Alan McKinnon alan.mckin...@gmail.com
Re: Off-list: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore
On 04/06/2014 02:24, Tom Wijsman wrote: > There is no such thing as a non-systemd profile; a sub directory is a > specialization, that doesn't mean that it parents suddenly become the > opposite of that. No, the parents are just generalizations that aren't > as specific as the sub directory. > > Doing what you've suggested everywhere but in gnome/systemd and > kde/systemd is a recipe to upset everyone whom runs systemd on another > desktop environment than GNOME or KDE; so, that's not a way forward. > > Another option is to create no-systemd sub directories; but such > profiles will be highly controversial, besides helping the exponential > grow of the profiles directories as well as be a non-default profile. > > Mix-ins from Funtoo, anyone? p.s. off-list :-) mix-ins? Awesome idea. We should do more of those. I don't understand why people are punting this idea of a non-systemd profile, I can see how that could ever work. Profiles *add* stuff or set some defaults, taking things away in a profile is really hard. The only thing it works for is globally setting stuff that can never be used eg, you need to remove all x86 cpu flags from arm Desktop profiles with and without systemd or KDE or Gnome or whatever looks exactly like an inherited class plus interfaces problem. Which is what mix-ins do :-) So once again - mixins, an awesome idea -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] RFC: news item for upower
On 04/06/2014 06:11, Samuli Suominen wrote: > As in, don't you think I've considered, as a active GLEP 42 user, if there > was a need for one this time? I weighted my options for 3 months before > acting, and people actually agreed with me it wasn't necessary at this > time. I'm really suprised about this, how small group of loud people > on ML can have this kind of effect. It's like, pick a $package_name, > raise enough noise on ML about it, get a news item saying 'emerge ' I have no problem that you made a judgement call and didn't think a news item was necessary. But these things are always a gamble to some degree and sometimes the effect isn't what you expected with the facts to hand. Given the number of threads on -user, it really looks like the dice didn't roll in your favour this time; it looks to you like a simple decision re blockers but to the users there they see something very different, and a news item gives them the info they need. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] minimalistic emerge
On 08/08/2014 15:32, Jeroen Roovers wrote: >> If no such USE flag, what about stabilize >> > gentoo with STABILIZED flag implementation in make.conf? > Next time, please bother the gentoo-user@ mailing list. No, please don't. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)
On 16/09/2014 12:18, hasufell wrote: > Ulrich Mueller: >> >> ChangeLogs are aimed at users > > Did any1 ask them if they care? > > > I'm a user and I don't care. I use diff. I only go to the Changelog when I can't determine the maintainers intent from diff and the ebuild content. That happens maybe once a year. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Add bc back to the stage3
On 17/09/2014 14:49, Aaron W. Swenson wrote: > On 2014-09-17 14:20, viv...@gmail.com wrote: >> Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto: >>> On Wed, 17 Sep 2014, Luca Barbato wrote: >>> >>>> The bc utility is part of the posix tools and it might be used to build >>>> linux among the other stuff. >>> >>> Luca, >>> >>> bc is not in the system set and is a dependency of the kernel or any >>> other package that needs it, so why do we need to include a package >>> that takes ~20 seconds to build? >> >> Most people don't use the ebuild for the kernel > > That's a rather outrageous and difficult to substantiate claim. Given > what I've seen in the forums and on IRC, it would appear the reverse > is true; most people use the ebuild for the kernel. > > I wouldn't consider people who deviate from the supported methods as > our concern. If you're smart enough to do that and want to make your > own path, you're smart enough to emerge bc. > Agreed. I've been on -user for 10+ years and only a very few fetch their kernels directly from upstream. The vast majority of users who have described how they do it simply emerge one of the source packages just like the handbook says to do. There's an even split between genkernel users and those who make menuconfig (100% unscientific survey taken from my brain and nowhere else) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Monthly Gentoo Council Reminder for May
On Friday 04 May 2007, Jorge Manuel B. S. Vicetto wrote: > I also don't agree with having an exception for the games herd. As > others have questioned, how are games more important than security > bumps? If we were considering exceptions, I would argue that allowing > the security team to mark packages as stable would make a lot more > sense, imho. A quick 2c here from the peanut gallery: Just leave the affected games always keyworded ~arch. The users of games are generally pretty savvy and they know how portage works. You might even find the majority of games players run ~arch boxes anyway so they will never notice that the game ebuild is not in stable alan -- Optimists say the glass is half full, Pessimists say the glass is half empty, Developers say wtf is the glass twice as big as it needs to be? Alan McKinnon alan at linuxholdings dot co dot za +27 82, double three seven, one nine three five -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] qa last rites multiple packages
On 07/01/2015 14:56, Rich Freeman wrote: > On Tue, Jan 6, 2015 at 6:47 PM, William Hubbs wrote: >> >> I am particularly concerned about packages with known security >> vulnerabilities staying in the main tree masked. If people want to keep >> using those packages, I don't want to stop them, but packages like this >> should not be in the main tree. >> > > Is this policy documented anywhere? If not, I'd be interested in what > the general sense of the community is here, and this might be an > appropriate topic for the next Council meeting. > > I guess my question is what harm does it cause to have masked packages > in the main tree, where they at least benefit from other forms of QA > (eclass fixes, etc)? The mask messages clearly point out the security > issues, so anybody who unmasks them is making an informed decision. > If they just move to some overlay most likely they won't have any > warnings and people will just figure that they're one of 10k other > packages that someone doesn't want to bother getting into the tree. > > I'll go ahead and reply to the council agenda thread with this, and > I'd be interested in what the general sense of the rest of the > community is here. I always thought the (informal, ad-hoc) policy for buildable, working packages with security bugs was to p.mask them and let the user decide. For all the reasons you cite. And that packages are only removed from the tree when they don't build, don't work, upstream is gone and took their sources with them, etc, etc. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 03/02/2015 20:02, Michał Górny wrote: > Dnia 2015-02-03, o godz. 18:50:43 > "Jason A. Donenfeld" napisał(a): > >> If you want ffmpeg-ish features, at all, USE=ffmpeg. >> >> If you'd like to use the libav implementation, USE=libav. If you'd prefer >> to use the original ffmpeg implementation, USE=-libav. >> >> >> This is simple. Why can't we just stick with this? > > No, it's not simple. It requires users to read another useless manual > that doesn't teacj them with anything except for how to solve a very > specific problem we introduced. > Agreed. I'm a user, and when I say "USE=ffmpeg", I want to get the actual package called ffmpeg, not something that looks like ffmpeg but might be a fork. I especially don't want to disable the alternate package to get the original pre-fork package. I support the idea of re-defining the USE flags even if it means once-off temporary pain. That's far better than having to deal with the existing method forever. Plus, user bug reports will never stop. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Last rites: app-portage/portage-mod_jabber, media-sound/moodbar
On 08/02/2015 14:04, Hanno Böck wrote: > # Hanno Boeck (08 Feb 2150) > # Dead upstream, will be removed in 30 days if nobody > # complains. > media-sound/moodbar I use this, it builds without errors and works well with Amarok. Please leave it in the tree for as long as it functions correctly. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] why is a line in /usr/portage/profiles/base/package.use.mask ignored?
On Wed, 25 Feb 2015 17:23:03 +0600 (NOVT) gro...@gentoo.org wrote: > Hello *, > > dev-lisp/ecls-15.2.21 does not compiled with USE=cpu_flags_x86_sse. > So, I've added the line > > =dev-lisp/ecls-15.2.21 cpu_flags_x86_sse > > to .../profiles/base/package.use.mask. But I still see > > dns ~ # emerge -pv dev-lisp/ecls > [ebuild R] dev-lisp/ecls-15.2.21:0/15.2.21::gentoo > [15.2.21:0/15.2.21::grozin] USE="X emacs libatomic%* threads unicode > -debug -gengc -precisegc" CPU_FLAGS_X86="sse*" 0 KiB > > Why isn't sse masked? Because USE over-rides it. Profiles are only a starting point and a bunch of defaults, everything in them is subject to being over-ridden by /etc/portage/* Why are you messing around with the profile anyway, when all the available documentation in many many places tells you to set your chosen USE for specific packages in package.use? Alan
Re: [gentoo-dev] Re: why is a line in /usr/portage/profiles/base/package.use.mask ignored?
On Thu, 26 Feb 2015 02:22:40 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Alan McKinnon posted on Wed, 25 Feb 2015 14:00:57 +0200 as excerpted: > > > Why are you messing around with the profile anyway, when all the > > available documentation in many many places tells you to set your > > chosen USE for specific packages in package.use? > > I believe you missed his email address, @gentoo.org. =8^0 > > IOW, he's a dev, trying to actually set a profile setting for > others. But his own testing says it's not working, thus the question > (for which bkohler has provided an answer). > > /That/ is why he's messing with the profile, instead of setting his > chosen USE for that package in package.use. =:^) You're right, I did miss that. I'd just dealt with a backlog of unread mails in -user and didn't notice this thread is in -dev. My bad. It seems apologies to our devs are in order.
Re: [gentoo-dev] [RFC] News item about mysql client and server packages
On 17/07/2015 22:17, Brian Evans wrote: > Here is a second Draft based on comments > > > Title: MySQL client libraries and server packaging changes > Author: Brian Evans > Content-Type: text/plain > Posted: 2015-07-17 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: virtual/mysql > > First off, a new virtual is being introduced, virtual/libmysqlclient. > virtual/mysql will represent the server (mysqld) and tools (mysqldump, > mysql, mysqladmin, etc) while virtual/libmysqlclient will represent > the mysql client shared and static libraries, libmysqlclient.so for > example. This reads oddly. There's a "first" but I'm left wondering what the "second" is, and I have to re-read "mysql client shared and static" several times to figure out what is probably the noun and the adjective. If I were writing the news, I'd probably do this: Ebuild packaging for the various mysql packages is changing; including the addition of a new virtual virtual/libmysqlclient. The existing virtual/mysql will represent the server (mysqld) and tools (mysqldump, mysql, mysqladmin, etc), while virtual/libmysqlclient will represent the shared and static libraries for mysql clients, e.g. libmysqlclient.so > Ebuilds that only link the libraries may not pull in the server > packages with this change in the future. Because of this, you may have > to add a virtual/mysql or one of the providers; i.e. dev-db/mysql, > dev-db/mariadb, or dev-db/percona-server; to your world file if you > require a server to be installed locally. This will be phased in > slowly as other packages are updated. > > As for the server packages themselves, the minimal USE is being > replaced. The new USE flags are client-libs, server, and tools. > The server and tools flags are on by default to signify the primary > purpose of those builds. It's not obvious that "minimal" is a USE flag, I first thought you meant USE is short :-). I suggest: The USE flag "minimal" > The primary provider for libraries will be a new package > dev-db/mysql-connector-c. Thorough testing did not turn up any > issues, but packagers are permitted to block any provider of > virtual/libmysqlclient that does not work correctly. Enabling the > client-libs USE on a server package may be the necessary solution for > the rare case of a block on an incompatible provider. Finally, I'd flesh this out a little more so that users know what *they* need to with this change. You've done a good job of explaining what you have done. It's not completely clear what the user must do to retain their existing mysql clients, and many of them will think mysql-connector-c provides it. I'd suggest a wording myself, but I'm still not 100% clear how it will really work. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Managing etc/* in an embbeded system
On 22/07/2015 14:05, Joakim Tjernlund wrote: > On Wed, 2015-07-22 at 07:14 -0400, Rich Freeman wrote: >> On Wed, Jul 22, 2015 at 6:17 AM, Panagiotis Christopoulos >> wrote: >>> >>> you can subscribe to gentoo-embedded mailing list and ask there, as your >>> product >>> is embedded. Also, man make.conf and search for CONFIG_PROTECT. If I >>> understood >>> you correctly, it may be what you need. >>> >> >> That list is certainly a a good place if it is active, but I get the >> impression that he wants to package/manage his config files in some >> way. That is, install package foo, and then automatically get his >> config files for foo. > > Yes, I need to be able to change my own config files too over time. > >> >> Short of going to a true config management system, I'd consider just >> having a tarball/etc full of config files that you unpack after you've >> set up your system (or clone it from a git repo or whatever). If you >> have config files for packages you didn't install it isn't a big deal >> - they just use up a few inodes, and if you install the packages later >> the CONFIG_PROTECT settings will prevent them from being overwritten. >> >> A portage-based alternative is to stick them all in a package(s) >> (which will generate collision warnings, and since it would respect >> config protect it would mean you have to merge in all the changes), or >> fork all the ebuilds. I just don't think portage is really meant as a >> full-fleged configuration management tool. > > There can not be any manual merges after an SW update here. > > I started to look at INSTALL_MASK, what if I set INSTALL_MASK > to point to all conf files I want to manage myself. > Then /etc/inittab etc. will not be touched when updating init > > Then I add my own ebuild containing my modified conf files but how to > manage INSTALL_MASK, CONFIG_PROTECT etc.? > Is it possible from within the ebuild change INSTALL_MASK, CONFIG_PROTECT? > Then I could just zap INSTALL_MASK before installing my files. > > >> Also, if you're doing lots of these installs you might want to look at >> a true config management tool like ansible or puppet/chef. That could >> take care of all the installation as well as the configuration, and >> could be tied into portage. > > sound complicated for what I want to do > You could take the approach FreeNAS uses: /etc is a tmpfs mount. If I read you correctly, upgrades are done with the appliance off-line in the style of flashing a DSL router? In that case, upgrades will be done in maintenance mode, with /etc not mounted. So *MASK* and *CONFIG* don't even feature at all, just let emerge do it's thing as normal and your customizations are not even in the picture. Your ebuild containg config files should install copies somewhere appropriate, like /var/mystuff/ Last step of the install is to mount the /etc tmpfs, copy the existing on-disk /etc to it then copy /var/mystuff to /etc. They will overwrite portage's versions but so what? You know you want them changed and you have persistent pristine original copies of portage's versions and your mods. Finally, reboot. This whole last step must also happen after reboot, so make it a custom init script in an appropriate runlevel where you can launch it as needed during upgrade and reboot. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] rfc: openrc mount service prototype
On 30/07/2015 00:22, William Hubbs wrote: > On Thu, Jul 30, 2015 at 01:11:30AM +0300, Alon Bar-Lev wrote: >> On 29 July 2015 at 23:20, William Hubbs wrote: >>> >>> All, >>> >>> so that there is a better idea out there of what I'm talking about, the >>> OpenRC github repository now has a mount-service branch. >> >> Nice! >> >> But I still trying to figure out why do we need to keep fstab around. >> It is pure legacy. > > Is it? I have heard different people say it is, and it isn't, so I have > no idea. > > If fstab is truly legasy, I'll look into that. You have to list the standard mounts /somewhere/, it might as well be /etc/fstab... There's very little useless cruft in that file -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: useflag policies
On 03/08/2015 15:07, Dale wrote: > Michael Palimaka wrote: >> On 03/08/15 07:14, NP-Hardass wrote: >>> ^^ has the pleasant side effect of being easier to read, as a user. The >>> user receives a message saying "at-most-one-of" instead of some >>> convoluted other expression that they don't understand. >>> >>> I am all for the use of ^^ add the default for this reason. >> This introduces a usability nightmare for anyone with both qt4 and qt5 >> in their global USE flags (a common configuration). >> >> >> > > > As a Gentoo user. This is what I have set and what I hope to get > because of the settings. I have both qt4 and qt5 set in make.conf for > my USE flags. I expect qt5 for whatever packages can work with qt5 and > qt4 for whatever isn't ready for qt5 but requires qt. If for some > reason a package isn't quite ready for qt5 and won't function correctly > for me, I can always set that in package.use until it is. My current > entries for this: > > media-libs/phonon-vlc qt5 > media-video/mkvtoolnix -qt5 > > I don't have notes on that so not sure what was ran into to require > those. I may comment those out and give them another try. > > Point of this post, provide a little user info about expectations and > settings. Y'all sort out the best way forward and let us know if we > need to change something. :-) Dale and I think alike. I also have Qt4 and Qt5 installed, and I expect packages that use them to link to the version that works better (understanding that "better" is usually the opinion of upstream and the devs). If I decide I care about which one works better for a given package, then I'm happy to package.use but mostly I like that file to be as empty as I can get it. What I don't want is for the machinery to give the impression that I can't just go with whatever the dev put in the ebuild for the general case. I also don't want to have to keep going back to use.desc because it's not obvious what the flag probably does. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] useflag policies
On 03/08/2015 22:20, Rich Freeman wrote: > On Mon, Aug 3, 2015 at 3:07 PM, Maciej Mrozowski wrote: >> On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote: >> | The approach qt4=qt4 >> | and qt5=qt5 seems simpler on the surface, but it means that users end >> | up having to set tons of per-package configurations when they don't >> | actually care which one they use, >> >> I will risk a thesis that if they didn't care, they wouldn't have chosen >> Gentoo... >> > > Obviously there are many reasons people use Gentoo, but here is my > perspective on this. > > The value of Gentoo is that it gives you a LOT of power to tweak > individual package configurations, without the requirement to do this > for everything. There are packages that I carefully configure USE > flags for, CFLAGS for, epatch_user, and so on. Heck, some packages I > run in containers where I can carefully control almost all aspects of > their environment. Then on the same host I'll have screen and bash > and a million other packages installed where exact configuration is > not critical, and so I want it to "just work." If I wanted to > micromanage everything I might as well run Linux From Scratch. > > Gentoo should be the best of both worlds. We should give users the > power to tweak things, but we shouldn't force them to play with config > files all day long just to have a functional system. If users want to > care we let them care instead of telling them "don't touch" like most > other distros, but if they don't care we still provide reasonable > defaults. > +1 One of the most powerful aspects of ebuilds is the ability to not have to control something the user does not want to. I use Gentoo because I can control what I wish and like Rich the bits I want to control are a small fraction of the whole. When a dev says "I will risk a thesis that if they didn't care, they wouldn't have chosen Gentoo", there is a place for that but it is by no means the general case. We DO accommodate the control freaks, we let them USE="-*" and let them keep all the tiny shards. But the truth is far more subtle than a care-all/care-none scenario. I say stick with reasonable defaults, and for better or worse, that includes "use highest version in ACCEPT_KEYWORDS unless user says otherwise" -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] .gitignore
On 12/08/2015 23:29, James Le Cuirot wrote: > Mike Frysinger gentoo.org> writes: > >> >> On 10 Aug 2015 09:17, Michał Górny wrote: >>> Dnia 2015-08-10, o godz. 02:42:21 Mike Frysinger napisał(a): >>>> On 10 Aug 2015 08:28, Justin (jlec) wrote: >>>>> I like to propose to add the md5-cache into it. Which other >>>>> files are of interest? >>>> >>>> /distfiles/ >>>> /local/ >>>> /packages/ >>> >>> Those directories should not be ignored. Those should not exist for >>> a long time. >> >> there's no reason people can't use these on their own system. >> there's no reason they should be added to the git repo which means, >> if a user opted to utilize them, they should be ignored. > > I agree and I'm not sure what mgorny is basing his statement on anyway. > Apart from /local/, which I forget the purpose of, the default locations > for DISTDIR and PKGDIR still seem to be /usr/portage/distfiles > and /usr/portage/packages. I must admit that I'm struggling to find the > logic for this in Portage but those are the defaults nonetheless. So > why would they not exist? I'm certainly using them here and I would > like to see them in .gitignore. > /usr/portage/local was the original location for the user's own personal ebuild space - an "overlay" if you will. /usr/portage/distfiles and /usr/portage/packages are there because that's where ports has put them for decades, and no-one has gotten around to changing it in portage yet. FreeBSD defines the use of /usr very differently to what Linux users are used to. Those dirs really should be in /var/portage, and the user's overlay has no business being under main tree itself -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] .gitignore
On 13/08/2015 00:21, James Le Cuirot wrote: > On Thu, 13 Aug 2015 00:11:45 +0200 > Alan McKinnon wrote: > >> On 12/08/2015 23:29, James Le Cuirot wrote: >>> Mike Frysinger gentoo.org> writes: >>>> >>>> On 10 Aug 2015 09:17, Michał Górny wrote: >>>>> Dnia 2015-08-10, o godz. 02:42:21 Mike Frysinger napisał(a): >>>>>> On 10 Aug 2015 08:28, Justin (jlec) wrote: >>>>>>> I like to propose to add the md5-cache into it. Which other >>>>>>> files are of interest? >>>>>> >>>>>> /distfiles/ >>>>>> /local/ >>>>>> /packages/ >>>>> >>>>> Those directories should not be ignored. Those should not exist >>>>> for a long time. >>>> >>>> there's no reason people can't use these on their own system. >>>> there's no reason they should be added to the git repo which means, >>>> if a user opted to utilize them, they should be ignored. >>> >>> I agree and I'm not sure what mgorny is basing his statement on >>> anyway. Apart from /local/, which I forget the purpose of, the >>> default locations for DISTDIR and PKGDIR still seem to >>> be /usr/portage/distfiles and /usr/portage/packages. I must admit >>> that I'm struggling to find the logic for this in Portage but those >>> are the defaults nonetheless. So why would they not exist? I'm >>> certainly using them here and I would like to see them >>> in .gitignore. >> >> /usr/portage/local was the original location for the user's own >> personal ebuild space - an "overlay" if you will. >> /usr/portage/distfiles and /usr/portage/packages are there because >> that's where ports has put them for decades, and no-one has gotten >> around to changing it in portage yet. FreeBSD defines the use of /usr >> very differently to what Linux users are used to. >> >> Those dirs really should be in /var/portage, and the user's overlay >> has no business being under main tree itself > > I didn't say they were the most appropriate locations and I agree > that /var/portage is best but that doesn't change the fact that they > are still the defaults. :) > Indeed. And it's equally true they should be git ignored. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] www-client/chromium gtk3 support
On 10/09/2015 14:44, Rich Freeman wrote: > On Thu, Sep 10, 2015 at 8:33 AM, hasufell wrote: >> >> So this makes no sense, since it's already an unsupported corner case. > > Just what use of Gentoo do you not consider an unsupported corner > case, which isn't already better supported by some other distro? > > The whole point of using Gentoo is having "support" for all those > "unsupported corner cases." If you just want everything to support > doing things in the one way which is most supportable, you're > basically doing a really bad job at re-inventing Debian. > > I use quotes around support since all support on Gentoo is > best-effort, and that is all I'm getting at here. If a package > maintainer can support multiple configurations and are willing to do > so, they should be encouraged to do so. > >> >>> I'm not suggesting that package maintainers should be forced to >>> support both whenever possible. I just don't think they should be >>> discouraged from doing so. +1 I'm fully with Rich here. gtk+2 is out there, it's in the tree and stuff uses it. Therefore a way must exist for stuff to get to use it. Everything else is whinging and nattering. >>> >> >> Yes, they should be discouraged. It's a QA matter. >> > Since when does QA devise policy? QA never devises policy QA enforces policy that by definition is devised elsewhere > Well, I'm glad we've all aired our opinions on the matter. :) > > I just fail to see the QA issue here, unless it again boils down to > that it is easier to do QA when you have one configuration (like > Debian) and not many (like Gentoo). > > The other issue that keeps coming up is that we don't have good > standards for USE flag naming in these situations, and the solution to > that is to come up with a good uniform practice. Having gtk, gtk2 and gtk3 USE flags used inconsistently is a problem, that is not being denied. What is not a problem is a package that supports one or more toolkits, offers various ways to implement that support, is supported upstream and desired by users. That is a fact and as this is not Debian people need to be willing to let people solve that problem in ways they see fit. Citing "QA policy" as a way to avoid having to deal with murky real-life corner cases is just flat out wrong. And those murky corner cases exist, they always will and are the things that separate real life from theoretical ideals. gtk2 exists and is in use. I see no plans to deprecate it globally, so those who take issue with ugly USE syntax really should learn to deal with it, or propose a more elegant solution that still accomplishes what other devs are trying to do. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec
On 21/09/2015 21:45, Taahir Ahmed wrote: > > Instead of adding more and more layers to the Gentoo versioning spec to > work around insane upstreams, why not put the relative ordering of > versions into the ebuilds? > > Then, a version identifier would just be a unique string. > > An ebuild would declare which version strings it succeeds. That won't work too well for the case of earlier versions that receive updates or -r revisions example mysql. 5.5 and 5.6 are both in the tree so when 5.5.46 is released, 5.6.26 would need to have it's VERSION_SUCCEEDS ebuild updated. This leads to an odd situation where a change in one ebuild is reflected in another. To go the route of declaring order in the ebuild, VERSION_PRECEEDS would fit better. Personally the approach that makes most sense to me is to have a spec as simple as possible to cover the majority cases. Most projects are somewhat sane with version numbers, so cover those with a simple spec. Deal with all weird cases using VERSION_PRECEEDS > > Then even in the case of an upstream that did something stupid, like > only releasing versions identified by the git commit ID, the package > manager can both: > > * Use the upstream versioning scheme. > > * Know which version is "best", by finding a topological ordering on > the succession graph. > > mypackage-insaneversionspec1.ebuild --- > ... > # This was the first release of the package, so it succeeds nothing. > VERSION_SUCCEEDS="" > ... > EOF --- > > mypackage-insaneversionspec2.ebuild --- > ... > # This was the second release of the package, so it succeeds the first > # version. > VERSION_SUCCEEDS="insaneversionspec2" > ... > EOF --- > > Obviously, the downside of this scheme is that you have to load and > parse every ebuild for a given atom, rather than being able to find the > best one just by walking the filenames. > > Taahir Ahmed > -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] news item: OpenRC 0.18 changes to localmount and netmount
On 29/09/2015 16:29, Ian Stakenvicius wrote: > On 28/09/15 06:58 PM, William Hubbs wrote: >> Also, we are dropping the use of the -O switch for mount/umount >> -a. This is being dropped because it is util-linux specific and >> not compatible with busybox. > > Does this have any actual end-user impact? AFAIK, using the -O > switch was 'just added' by us originally (i think to reduce the > explicit listing of the different fs types or otherwise simplify the > init script code) right? I'm just wondering if this paragraph is > actually necessary or not.. As a user, that para in the news makes me ask "how does this affect me?". I have to go read man pages and init scripts to find out. Perhaps this: Also, we are dropping the use of the -O switch for mount/umount -a, because it is util-linux specific and not compatible with busybox. This only affects mounts with "_netdev" listed under options in /etc/fstab. Such systems should use "noauto" and/or "nofail" as described above. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: rfc: adding sbin directories to PATH for all users
On 26/11/2015 17:03, Duncan wrote: > Kristian Fiskerstrand posted on Wed, 25 Nov 2015 21:15:37 +0100 as > excerpted: > >> On 11/25/2015 09:16 PM, Mike Gilbert wrote: >>> On Wed, Nov 25, 2015 at 2:23 PM, Michał Górny >>> wrote: >>>> On Wed, 25 Nov 2015 11:18:34 -0800 Daniel Campbell >>>> wrote: >>>>> Maybe I'm missing something, but `df` is in /bin. Do you use >>>>> something else to determine free space? >>>> >>>> btrfs fi df >>> >>> In thins case, upstream's build system installs everything in bindir, >>> which I override to /sbin. I think that's where the ebuild was >>> installing things when I inherited it from the previous maintainer. >>> >>> If William's PATH proposal is not implemented, I would be happy to move >>> it all to /bin if so desired. Just file a bug. >> >> If moving it in the first place, wouldn't it go to /usr/bin as not being >> essential to system? > > It's essential to system, as btrfs device scan is needed before mounting > a multi-device btrfs, and btrfs check is a an fsck that may be needed to > fix a broken btrfs /usr/ mount. > > Else reiserfsck, e2fsck, fsck itself, and others, should be in /usr/sbin, > not in /sbin/. > > btrfs is the general userspace binary. Subcommands such as check and > device scan require device privs and don't normally work when run as > ordinary users, but some subcommands such as filesystem df don't need > device privs and work just fine when run as ordinary users. > > (Not that I particularly care about the topic of the thread in general, > as here: /sbin -> bin, /usr -> ., so all four locations, /bin, /sbin, > /usr/bin, /usr/sbin, point to the same single /bin, and I no longer have > to worry about which dir something's in, unless I'm checking the > canonical path as installed by the package, for which equery belongs > works nicely. But I'm a btrs user and upstream btrfs list regular so I > care about that angle, thus this reply. =:^) Picking a random (i.e. most recent) post to reply to. I don't really care what the default PATH is, I always set it to my liking anyway. I understand all the historical arguments but I don't think they matter too much these days anymore as times and OSes do change. I feel that the / vs /usr split is rather pointless on modern systems, but I do like the bin vs sbin split because it makes my life easier (which is the entire point of any env var when you think about it). When working as a user I'd rather not have my tab completion results cluttered with apps I have to be root to use properly. I vote to leave things as they are, and I also vote for showing people who don;t like it how to change $PATH -- Alan McKinnon alan.mckin...@gmail.com
