[gentoo-dev] Package up for grabs: dev-python/influxdb
I no longer use InfluxDB. The ebuild is at version 5.3.0, while upstream is at 5.3.1, so it’s only one micro version out of date. The ebuild declares compatibility up to Python 3.10. It’s a pretty simple package. -- Christopher Head pgp3yBZ2Nmwn_.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH news] Add Python 3.9 news item
On Thu, 29 Apr 2021 13:43:41 +0200 Michał Górny wrote: > +If you wish to use a safer approach to the migration and temporarily > +preserve the support for Python 3.7 and Python 3.8 simultaneously, > +set /etc/portage/package.use to: This should be talking about preserving support for 3.8 while adding 3.9, right? (likewise the next handful of lines) > +You can also switch to Python 3.8 earlier by setting: Likewise, 3.9 here? > +The Python 3.7 cleanup requires that Python 3.7 is removed from 3.8 here? -- Christopher Head pgp_6ql8obmSt.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: app-cdr/sync2d
On Fri, 5 Jun 2020 21:39:51 -0400 Aaron Bauman wrote: > Of course, the depgraph is not an issue. If a package is > masked, it will break immediately. Hence, required checks > are run then the package is masked. I meant that if $P is removed, then things that $P depends on could also start getting removed, which makes it ever harder and harder to install $P if you need it. I wasn’t talking about things that depend on $P. -- Christopher Head pgppPDza5h85T.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: app-cdr/sync2d
On Fri, 5 Jun 2020 12:40:17 -0700 Matt Turner wrote: > With that in mind, I don't expect it to gain Python 3 support, nor do > I expect an additional 15 days of waiting time to change that fact. 15 > vs 30 days doesn't seem worth squabbling over. Not that I care about this specific case, but isn’t the 30-day time period also meant as a nice long warning time for people *using* the package to give them time to migrate to something else before it starts to be unsupported, potentially break the depgraph, no longer be installable on additional systems, and so on? -- Christopher Head pgpO1_Yh5m_dG.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On Wed, 27 May 2020 11:38:39 +0200 Nils Freydank wrote: > Zoltan, I prepared a branch with khard plus metadata.xml and would > like to ask you to merge it into your PR as you took deps of khard: > > https://github.com/holgersson32644/gentoo/tree/bump-khard Hi Nils, I already had a PR[1] open for the version bump and Python 3.7 support. I’m happy for you to take over if you like; mine is waiting for review. Just thought you ought to know in case you get merge conflicts later on, or want to take any bits of my changes. [1] https://github.com/gentoo/gentoo/pull/15783 -- Christopher Head pgp9AYxcdnXhY.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Changes made by acct-* ebuilds
On Thu, 13 Feb 2020 08:09:13 -0800 Christopher Head wrote: > On Wed, 12 Feb 2020 19:14:45 +0100 > Michał Górny wrote: > > > I'm pretty sure user.eclass does print whatever changes it is doing. > > It isn't elog-ged though, I admit. This is probably worth fixing. So, I didn’t intend to provoke a massive debate here—personally I somewhat prefer users being modified by new versions of the user ebuilds so that I get security fixes as time goes by to fix e.g. users being in groups they shouldn’t be, but it’s not a huge deal to me. elogging when the eclass makes changes, though: Michał, do you want me to file a bug at bugs.gentoo.org for that? Or is it trivial enough you prefer to just do it straight away and not bother? -- Christopher Head pgpPK4oftJ8Sd.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d/60appdata-path: new check
On Wed, 12 Feb 2020 23:39:11 -0800 Georgy Yakovlev wrote: > + eqawarn "For more details, please see the > freedesktop Upstrem Metadate guidelines" Couple of typos here: s/Upstrem/Upstream/, s/Metadate/Metadata/. -- Christopher Head pgp6oJDIFyQwY.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Changes made by acct-* ebuilds
On Wed, 12 Feb 2020 19:14:45 +0100 Michał Górny wrote: > I'm pretty sure user.eclass does print whatever changes it is doing. > It isn't elog-ged though, I admit. This is probably worth fixing. Yes, I meant elog; sorry about the unclear wording. I generally don’t even see ordinary print output—most of my machines run emerge -jN where it isn’t shown at all, and even on the serial ones, there’s so much build output from a few dozen packages that I’m not going to scroll up looking for specific things which may have been lost from scrollback anyway. -- Christopher Head pgpRLsOnQ3l5k.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Changes made by acct-* ebuilds
H. Thinking about it more, this feels a lot like “configuration”, and we have a well-established tool for handling sysadmins customizing configuration while packages land new changes: CONFIG_PROTECT. Is that possibly relevant here? -- Christopher Head signature.asc Description: PGP signature
[gentoo-dev] Changes made by acct-* ebuilds
Hi all,
Yesterday something surprised me. I updated my system and got the
acct-{user,group}/lighttpd for the first time. Because lighttpd was running,
package installation failed to change the home directory—fine, it printed an
error message, I stopped the server, changed the home directory by hand, and
started the server back up.
What I didn’t realize was that it also, successfully, removed the lighttpd user
from a couple of auxiliary groups I had put it in. It did this without telling
me, without printing any messages. I only noticed because I happened to look at
syslog and discovered that usermod or gpasswd or whatever it called had logged
the changes. Presumably this has broken a service or two (nothing too critical)
since now Lighttpd won’t be able to connect to SCGI sockets any more.
Does it make sense for these ebuilds to print out all the changes they make to
existing users and groups, so that the sysadmin can see what happened and
immediately look into alternative solutions if it breaks something, rather than
silently changing things? Maybe this could even be limited to cases where the
package is being newly installed (not upgraded) and the user or group already
exists, to ease migration from the old world where sysadmins are easily able to
do anything we want with our users and groups to the new world where we’re
expected to leave them alone as the ebuilds make them, or worst case make out
changes in an overlay.
Thoughts?
--
Christopher Head
signature.asc
Description: PGP signature
Re: [gentoo-dev] Vanilla sources
On January 4, 2020 4:54:07 AM PST, Rich Freeman wrote: > >Uh, all it does is install kernel sources. They're useless unless you >build a kernel using them. > >Apparently git and tar are too complicated for Gentoo users, but >managing symlinks, using make, managing a bootloader, dealing with the >kernel's configuration system, and so on are just fine? I use gentoo-sources myself, but still, I would like to propose one reason for keeping vanilla-sources. For me, git/tar are not too complicated, but having V-S in the Gentoo tree would provide another benefit: reducing the number of things I have to check every weekly update cycle. Every piece of software I get from a source other than the Gentoo tree is another website I have to visit every update day to check whether there’s a newer version available. So from that perspective, the advantage of having packages in tree that just install some files is that emerge tells me when a new version is available, rather than me having to go every week to upstream’s website and check manually (or sign up for countless announcement mailing lists). Of course this would be a bad argument if V-S were lagging behind upstream significantly, and it’s a much better argument for packages that come with expectations of security team support than those that don’t, but it is something to consider. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On July 20, 2019 1:22:39 PM PDT, "Michał Górny" wrote: >Yes, I get it. User experience is not important if it would mean >developers would actually do anything but the bare minimum to get >from one paycheck to another. The usual Gentoo attitude. Is my experience as a user really improved if a package I use is dropped because its maintainer no longer has time to maintain it because they now have to spend their N available hours per month building man pages for one package rather than maintaining two? -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: hwclock service in OpenRC
On Sat, 15 Dec 2018 17:36:00 +0300 Andrew Savchenko wrote: > Yes, it is. CONFIG_RTC_HCTOSYS (and CONFIG_RTC_SYSTOHC) is > available in kernel for years and should be a preferred way to > handle the clock. > > Best regards, > Andrew Savchenko AFAIK those options still don’t work with RTCs set to local time, do they? Which, sadly, are required by anyone who dual-boots with a certain other OS made by Microsoft? So hwclock will still be needed for many people—perhaps kernel support should be the default, but a painless migration path for those who need to keep using hwclock would be appropriate (if any migration is even needed—I’m unclear on whether hwclock would be removed from the boot runlevel on existing installs or only not added on new installs). -- Christopher Head pgp9kI8u8utDp.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On July 18, 2018 2:55:55 AM PDT, Ulrich Mueller wrote: >It was mentioned that all three directories (ebuild repository, binary >packages, distfiles) have some characteristics of a cache. However, I >think this is much more true for distfiles than for the other two, >which cannot be easily restored to a previous state. Neither can a Web browser’s cache, if the remote page has changed, yet those are still called caches. Surely a cache is something that can safely be discarded without negative impact (which, for most users, the ebuild tree can be, since for most users, getting back today’s tree rather than last week’s is not a negative impact), not something that can be restored to exactly its prior state automatically. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
On July 11, 2018 8:52:56 PM PDT, Kent Fredric wrote: >Standard git tools will not attempt to even *change* these commits even >with an explicit rebase, because Git will detect that nothing needs to >change, and will no-op the rebase, leaving Committer and Signatures >intact, degrading to a fast-forward merge. Well, unless you consider “git rebase --no-ff” to be standard git tools, I guess… it’s not like you need to do anything *that* obscure to fix it. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [PATCH v3 00/12] GLEP 63 update
>> > 4. Expiration date on key and all subkeys set to at most 2 years >> >> -at most 2 years. >> +at most 2 years from generation or refresh of expiry. > >Now, this won't really work because it's self-propagating date. You're >soon going to see keys with 10 years to expiration because if you >update >the date 5 times from 'refresh of expiry', that's what you get. > >I get what you're trying to say but I can't really think of a sane way >of stating that. Maybe I should just explicitly state '(plus the >period >specified in point 5)'. “The expiry date of the key shall never be more than two years in the future”? -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] News item for Radicale upgrade
One more try, this time with the proper revision number. Title: Radicale 2 requires pre-install migration Author: Christopher Head <ch...@chead.ca> Posted: 2018-04-02 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: http://radicale.org/1to2/ If you do a custom migration, please ensure the database is cleaned out of /var/lib/radicale, including the hidden .props file. -- Christopher Head pgpEoKq8vhG8b.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] News item for Radicale upgrade
Hello, After much discussion on the pull request <https://github.com/gentoo/gentoo/pull/7274>, reviewers and I have concluded with a new pkg_pretend message, which I would like to use as the new news message as well. As before, I ask that the committer of that merge request adjust the posted date in this news item and add it to the news repo when accepting the PR. Thanks! Title: Radicale 2 requires pre-install migration Author: Christopher Head <ch...@chead.ca> Posted: 2018-03-30 Revision: 2 News-Item-Format: 2.0 Display-If-Installed: http://radicale.org/1to2/ If you do a custom migration, please ensure the database is cleaned out of /var/lib/radicale, including the hidden .props file. -- Christopher Head pgpmwdLDP2kml.pgp Description: OpenPGP digital signature
[gentoo-dev] News item for Radicale upgrade
Hello, I have filed a pull request <https://github.com/gentoo/gentoo/pull/7274> to add Radicale 2.1.8 to the tree. Migrating from Radicale 1 to 2 requires running a database export command using Radicale 1, i.e. *before* upgrading, as Radicale 2 can’t read version 1’s storage format. Please see below my proposed news item to go along with this version bump. Note that I am not a developer and am therefore unable to commit this myself; I would appreciate that it be reviewed and then whoever accepts my pull request also add this news item at the same time. Because of this, I have set the Posted date to today, as I can’t predict when it will actually be posted; I ask that the committer please revise the date accordingly. Thank you! Title: Radicale 2 requires pre-install migration Author: Christopher Head <ch...@chead.ca> Posted: 2018-03-01 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: http://radicale.org/1to2/ -- Christopher Head pgplBBA2idDBJ.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] The problem of unmaintained packages in Gentoo
On December 20, 2017 8:49:03 AM PST, "Michał Górny" <mgo...@gentoo.org> wrote: >Ad. 1. We currently have over 1650 m-n packages [1] and the list keeps >growing. The advantage of this type is that we have an explicit list >and everyone clearly sees that the packages need a new maintainer. We >also have some dedicated people who try to help fixing worst issues >but they're obviously not capable of doing all the work themselves. Is there an easy way to check whether any packages I have installed on my system are m-n? I checked “man q” and “man equery” but neither seemed to support searching by maintainer. The closest I found was “equery meta”, but that requires a specific package name on the command line. I read the last rites and it’s quite easy to notice if a package I actively use is shown there, but that doesn’t help with the hundreds of libraries and other dependencies whose names I don’t even really recognize but I have installed. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
On December 3, 2017 1:35:23 PM PST, "Michał Górny" <mgo...@gentoo.org> wrote: > >The best way to reach specific Gentoo developers is through Bugzilla. >This gives the best chance for focused discussion on the specific issue >without unnecessary distraction for other developers who are not >interested in the specific topic. While this is true for bugs, is it true for everything else as well? Bugzilla seems to me to be a more reactive, rather than proactive, tool when dealing with changes of behaviour in particular packages, eclasses, etc.. That is to say, if I object to the current behaviour in a particular eclass, in Portage, or in some core package with high impact, I can file a bug. If someone is considering changing behaviour and I want to voice my opinion on that proposal, Bugzilla is less helpful. Case 1, the developer does it without non-dev-community input and I am left with the only choice being to object after the fact, when my system is already broken. Case 2, the developer files a bug describing the change and then implements it; in this case, we suffer from the problem that Bugzilla isn’t so easily discoverable, given the number of bugs filed; gentoo-dev has the nice property that the maintainers self-select which proposed changes are important enough to announce, which Bugzilla doesn’t do. So if I wanted to be notified of all important changes to core system packages on Bugzilla, today, I would have to (1) choose the set of packages to follow myself, probably missing a few in the process, and (2) filter out the unimportant bug mail which currently never reaches this list at all. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] NEWS item for games destabling
For those of us who run mostly stable systems, there is one question I don’t know a good answer to. If I add a specific version of a game to package.accept_keywords, I will get that version forever. That’s not really what I want: I prefer to stay up to date as new versions are packaged. If I add just a cat/pkg to p.a_k, Portage will always try to pull in the latest version. If that version has some unstable dependencies which I haven’t also accepted, Portage will yell at me. An example of this is games-emulation/mednafen-0.9.46 depending on dev-libs/lzo-2.10, the latter of which is unstable. What I really want to install is, “the latest version of the package that doesn’t pull in any deps that aren’t available (stable or accepted),” but I don’t know any way to tell Portage that. Am I missing something, or is that indeed impossible? -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Tue, 25 Jul 2017 09:22:08 +0200 Dirkjan Ochtman <d...@gentoo.org> wrote: > Second, I believe a lot of the value in our stable tree comes *just* > from the requirement that stabilization is only requested after 30 > days without major bugs/changes in the unstable tree. Assuming there > are enough users of a package on unstable, that means important bugs > can be shaken out before a version hits stable. This could mean that > potentially, even if we inverted our entire model to say we > "automatically" stabilize after a 30-day period without major bugs, > we hit most of the value of the stable tree with again drastically > reduced pain/work. I’m a stable user when I can be. I use Gentoo for the configurability, not for instant access to the newest versions of things. I think this is a fairly reasonable proposal if stabilization is otherwise happening too slowly right now. If 30 days with no bugs plus an automated successful build against an otherwise-stable set of dependencies led to an automatic stabilization, I’d be fine with that. Some clarification would be needed on what bugs block stabilization, and of course there would need to be a flag that maintainers could add to specific ebuilds to indicate whether or not they’re stabilization candidates (though I wonder if it would be better to flag the ones that *aren’t* candidates, rather than the ones that *are*). -- Christopher Head pgpnLOp9yoUTL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On Fri, 28 Apr 2017 23:02:40 +0200 Manuel Rüger <mr...@gentoo.org> wrote: > www-servers/spawn-fcgi I’ll file for proxied maintainership of this one, since it looks like nobody else has taken it yet. -- Christopher Head pgpGqPRsTEBZz.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Reverse use of Python/Ruby versions
On April 10, 2017 11:12:10 AM PDT, "William L. Thomson Jr." <wlt...@o-sinc.com> wrote: >Are you running stable? There are other versions in tree. 3.4, 3.5, >3.6. If you were running unstable, you would have 4 pythons, including >2.7. That you only have 2 seems like you are running stable. Yep. Absolutely. I bring in ~ versions of packages when I have no choice. >If your writing new python code against say 3.4 and not 3.6. Not sure >about that... Seems like it would keep things bound to older versions >and never let things move forward. Not true. I will certainly move forward when a newer version becomes stable. >Usually when writing new code, you use the latest version of stuff. Not >always but usually best. If anything make code support older while >targeting newer. No, not how I develop. I always start by determining my target audience and then develop using a feature set that allows my target audience to use the code as easily as is practical. I wouldn’t use a syscall introduced in kernel 4.9 if I could avoid it, even if it made my code simpler, because most of my colleagues run Ubuntu LTS, they are part of my target audience, and it wouldn’t be available there. To me, responsible development practices mean NOT forcing my target audience to do a manual kernel build. Eventually the syscall will be “generally available” to my target audience, at which point I may go back and change the code. I wouldn’t build conditional branches that do it either way if I could possibly avoid it, either, because then I would have to do all the work of doing it the old way plus more, and it would also be more code which means more maintenance. >> 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. > >Because you are not setting or dealing with the targets. You went with >the mindless approach. Like doing a wildcard on USE flags. Yes, exactly. I don’t want to manually choose what version of Python I have installed, even though I sometimes do Python development. Just like I do a lot of C/C++ development, but I don’t want to manually choose which version of glibc I have installed. Or libfoo, for some foo. That’s what a depgraph is for, and if I do need some specific thing, then I will ask for it, but not before. >Your enabling support for all versions across the board for anything >that supports it. That is quite a different experience if you go trying >to use a specific one. I’m not trying to invalidate the pain that some people experience, just pointing out that I think it may be inaccurate to call that the “ordinary user” use case. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] Reverse use of Python/Ruby versions
On April 9, 2017 7:04:13 PM PDT, "William L. Thomson Jr." <wlt...@o-sinc.com> 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. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs post disbanding Ada: dev-lang/gnat-gcc and metastuff
On February 22, 2017 2:07:47 AM PST, "Michał Górny" <mgo...@gentoo.org> wrote: >Hi, > >The Ada project has been disbanded as having no members. Although there >were a few people interested in helping out with Ada, nobody made it >past the initial reply. Shortly after sending my reply noting that I used ghdl, my situation changed and I no longer need it. It also sounded like there was at least one other person who was actually interested in and knowledgeable about Ada as a language rather than just one consuming package. So I think I shouldn’t be involved. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Requirements for UID/GID management
On Fri, 3 Feb 2017 14:29:04 -0500 Michael Orlitzky <m...@gentoo.org> wrote: > > However, it is no rocket science to write a race-free chown command > > in C: Just open the file and use stat() and fchown() to be sure to > > change only files from the "correct" user. > > > > Since this works on the filehandle and not on the filename, I think > > that there is no possibility for an exploit when this is used in the > > above find loop. > > Not a bad idea... we chould ship that safe-chown utility, and then > tell users how to use it to fix their UIDs. The draft that I wrote up > was for the "fixed UID with random fallback" model, but said utility > could still be useful for people who want to change their running > systems to use the same UIDs that would have been chosen by default. Are you sure that said utility isn’t simply “chown --from”? -- Christopher Head pgpJBrNLgjlvb.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] REQUIRED_USE, global USE flags, user-friendliness...
On Sun, 29 Jan 2017 15:11:43 +0100 Róbert Čerňanský <ope...@tightmail.com> wrote: > If I may add a user opinion. I agree with you but I would choose > different solution for user-friendliness. Instead of _adding_ > interactivity to PM I would _remove_ it. So if there would be > multiple choices the user would not be prompted, but some default > option would be selected by PM. To the user, such behaviour would be > similar to current handling of virtuals - if a package depends on a > virtual the user is not prompted to make a choice but the default is > selected instead. This. Exactly this. In fact, I would go even further. Let’s look at two parallel situations. Situation 1: app-cat/foo DEPENDs on dev-libs/bar. I want app-cat/foo. I emerge app-cat/foo. Portage automatically installs dev-libs/bar. It doesn’t require me to say anything about dev-libs/bar (though if I ask to confirm before starting the build then it will mention it). I never have to add dev-libs/bar to any user-maintained files (i.e. /etc/portage/* or /var/lib/portage/world). If I ever uninstall app-cat/foo, then dev-libs/bar will go away on its own when I depclean. Situation 2: app-cat/foo DEPENDs on dev-libs/bar[baz]. I want app-cat/foo. I emerge app-cat/foo. Portage… fails. It requires me to manually add “dev-libs/bar baz” to /etc/portage/package.use/* (it will do it itself, if desired, due to autounmask, but of course it puts it in the wrong file because I like to keep things organized with multiple files). That setting goes on living in /etc/portage, a user-maintained area, forever. If I ever uninstall app-cat/foo, baz will stay set until I eventually get around to slogging through /etc/portage/package.use looking for things I can turn off because I don’t need them any more. Why? It’s just another dependency. Why does DEPEND="dev-libs/bar" work so beautifully but DEPEND="dev-libs/bar[baz]" work so horribly? If I haven’t explicitly said I want baz, and I haven’t explicitly said I *don’t* want baz, and enabling baz doesn’t conflict with any other packages I have installed, Portage should just rebuild dev-libs/bar with USE=+baz. If I eventually uninstall app-cat/foo, something like depclean should reinstall dev-libs/bar with USE=-baz. Just like all the other dependencies, if I don’t care to make a manual choice, it should be automatic and dynamic. -- Christopher Head pgpdkiVtAMXgB.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Ada project needs your help!
On Thu, 15 Dec 2016 12:55:43 -0800 Matt Turner <matts...@gentoo.org> wrote: > On Sun, Dec 11, 2016 at 7:59 AM, Michał Górny <mgo...@gentoo.org> > wrote: > > dev-lang/gnat-gcc > > Something I've wondered about since I used gnat-gcc for assignments as > an undergrad -- why is gnat-gcc a separate package from gcc? Isn't the > Ada frontend just part of gcc? Why not just a gcc[ada] USE flag? > I agree. Anyone from toolchain@, if someone (perhaps myself) were to submit a pull request adding an ada useflag to sys-devel/gcc, would it be accepted (assuming the patch were sensible and clean)? -- Christopher Head pgpRbYgNQQBxF.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Ada project needs your help!
On December 15, 2016 12:19:05 AM PST, "Michał Górny" <mgo...@gentoo.org> wrote: >Would it be fine with you if we kept gnat-gcc and ghdl? (but lastrited >dev-ada/*) I personally have no use for the others. -- Christopher Head
Re: [gentoo-dev] Ada project needs your help!
On Wed, 14 Dec 2016 16:47:41 +0100 Michał Górny <mgo...@gentoo.org> wrote: > So the only real consumer is GHDL -- yet another case when someone > thought it'd be fun to use a fringe language to implement something > useful... However, it seems to be undermaintained in Gentoo as well, > not bumped for a long time. > Undermaintained perhaps, but it works. Not a lot of bugs filed. Would a pull request be sufficient to stop this package I use from being steamrollered into oblivion? I honestly wasn’t hoping to spend my holidays learning how the GCC build system works, but if I’m left with no other choice, then I possibly might look into it. I won’t bother though if there’s some reason why it wouldn’t be accepted anyway, because people don’t want Gnat or GHDL in the tree. -- Christopher Head pgpz_Xk5oibPC.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Ada project needs your help!
On Sun, 11 Dec 2016 16:59:50 +0100 Michał Górny <mgo...@gentoo.org> wrote: > Hello, everyone. > > The Ada project seriously needs help. For some time already, it has no > active developers (George is retiring), and a lot of bugs needing > attention. > > The packages maintained by aga@g.o are: > > app-eselect/eselect-gnat > dev-ada/asis-gcc > dev-ada/charles > dev-lang/gnat-gcc > virtual/ada > virtual/gnat > > Since the Ada subsystem in Gentoo is practically unmaintained now > and has only those two packages, the alternative is to lastrite it > all. > > Is anyone interested in Ada? Any comments? > I notice sci-electronics/ghdl is not in this list. Is it considered part of this? It depends on gnat-gcc. I guess it would also be lost if the above were given last rites? -- Christopher Head pgpXcBNpo99EH.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish
On December 9, 2016 10:12:54 PM PST, "A. Wilcox" <awil...@adelielinux.org> wrote: >I think James has perhaps spoken ambiguously, or at least I hope that >you have misunderstood his proposal. (If you haven't, then he's >misunderstood mine.) > >The point of making it easier to fork is not only for the benefit of >developers. As James says: > >> And then folks running gentoo-proper now can pick and choose which >> innovations they want to include in the master tree. > >The idea being the people who "run" Gentoo, that being the developers >of Gentoo, can pick what they want from the forks and derivatives, and >include those improvements in the master tree. Then all Gentoo users, >and all derivatives of Gentoo, can benefit from those improvements. You’re right, I took the word “run” in the sense of “execute” (the OS), not in the sense of “manage” (the organization). If forks are a way to develop work destined for upstream, they’re great. It’s when they become a tool for fragmenting the community (of both users and developers) without any hope of work being recombined that they become a problem. -- Christopher Head
Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish
On Wed, 7 Dec 2016 12:15:06 -0500 james <gar...@verizon.net> wrote: > Being able to use stage-4 or stage-5 (G. forums) installs to rapidly > provision a collection of bare-metal systems [BGO-593218] into a wide > variety of hardened clusters is my passion. Unikernels as stage 4 > packages can then very easily be targeted for very specific needs: VM > or container or bare-metal. Gentoo-proper is has too much political > baggage to encourage folks to innovate, imho. So, I really hope the > gentoo dev community gets behind the Anna Wilcox idea of streamlining > Gentoo into the most fork-able distro on the planet. WE could all be > one happy family and yet be very competitive with our ideas, trials > and published results? Surely a few eggheads (academcis/pedantics) > see the wisdom of competing micro_distros? Not unlike competing > micro_breweries, it make the entire craft much stronger and better > for all. > > > Then there can be peace and harmony as everybody can do exactly as > they please with their little cluster of gentoo and their very own > portage-tree. And then folks running gentoo-proper now can pick and > choose which innovations they want to include in the master tree. > Isn't that pretty much what Google and CoreOS do now, as well as the > gentoo derivative OS? Why not accelerate what has worked, for the > few, to emancipate those of us still chained into user-land servitude. As an ordinary user, this sounds pretty bad. Forking is great for developers, but bad for users. I don’t *want* 27 different Gentoo-derived fork distributions, each of which is great at one thing. I don’t want to have to reinstall a different OS just because I switch from writing embedded code to running Octave. Honestly, I don’t even want to go out and find other OS’s repos, add them as overlays, and hope the inter-OS dependencies work. As an ordinary user, what I *want*, is to install one OS and not think about it again. Ideally, Gentoo. When I want to do embedded development, I just emerge dev-embedded/thingy. When I want to do some math, I just emerge sci-mathematics/octave. Most things that most people care about in the main tree. Breaking things up into overlays or different OSs or whatever just means adding more hoops that I have to jump through before I can start working on a new topic. -- Christopher Head pgpa8a3bVCWvb.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: important fstab update
On Thu, 27 Oct 2016 10:25:39 -0400 Rich Freeman <ri...@gentoo.org> wrote: > It would be nice if standards like USB incorporated some kind of GUID. > I ended up having to write a udev rule for a pl2303 RS232 adapter to > tie it to a specific USB port precisely so that I could have more than > one and know which one talked to which device. > > I'd argue that the udev network interface names were a better (if > painful to transition to) solution to a problem created by somebody > else. Being able to use wildcards in configuration files is probably > an adequate solution for those who are using a single device. > You mean like a device serial number? Which is totally part of the USB standard, but many devices don’t bother to include one because they would have to be serially programmed in the factory? If your device has a serial number, you can generally see it as a udev attribute and use it to set up meaningful persistent names for multiple otherwise-identical devices. -- Christopher Head pgphi7PNcCbPu.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Need design help/input for eclean-kernel
On Thu, 30 Jun 2016 14:38:26 +0200
Michał Górny <mgo...@gentoo.org> wrote:
> So if you have some time, please reply to this thread with
> a specific /boot layout that you think needs to be handled, with
> as much helpful information as possible -- including possible
> distinctive features and pitfalls.
I use genkernel to build my kernels and initramfsen. Most of my
machines don’t support EFI, so my /boot contains a bunch of
{initramfs,kernel,System.map}-$KV files plus the
{initramfs,kernel,System.map}.old symlinks. My GRUB2 grub.cfg points at
the symlinks. Once in a while (usually when I get disk full errors on
the dedicated partition) I delete the old files by hand.
A couple of my machines do support EFI. On those, I set INSTALL=no in
genkernel.conf. I then run a custom script afterwards which maintains
directories /boot/EFI/gentoo and /boot/EFI/gentoo-old. Each of these
contains a file kernel.efi and another file initramfs. This is FAT, so
no symlinks. The script deletes gentoo-old, copies gentoo to
gentoo-old, and finally puts the new files in gentoo. I have EFI boot
records pointing to both, using initrd=\gentoo\initramfs syntax.
--
Christopher Head
pgp7PeYxC9xcO.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] LFS QA warnings coming soon to a build near you
On May 31, 2015 7:33:28 AM PDT, Alexis Ballier aball...@gentoo.org wrote: I'm not sure what's best for every one: 1. Push hundreds of patches upstream to add lfs flags; 2. Apply your patch to our glibc ebuilds, fix the corner cases, and go back to glibc upstream with these data. If the changes are made to glibc, would these be under a new symbol version for ABI compatibility, or just be changes to headers to make _FILE_OFFSET_BITS=64 the default? If not, what about binary software? Not saying you haven’t considered the relevant issues; I just haven’t seen binary software brought up on this list yet. -- Christopher Head
Re: [gentoo-dev] Re: vmware team needs help
On Sun, 15 Feb 2015 11:36:50 +0200 Markos Chandras hwoar...@gentoo.org wrote: No one is going to boot you for inactivity if you have nothing to do. You might get an are you alive? email, but assuming you answer within a few weeks, all my work is done is the best reason to be doing nothing. That is true yes. There is a difference between I have nothing to do and I am not interested in doing anything anymore. If you only maintain one package and you commit once a year so be it :) It's a volunteering project so nobody can actually force you to maintain a certain rate of commits per $time. In case you appear inactive, people will send you a fair amount of emails over a significant period of time before they start the retirement process OK, thanks for the clarification—I was honestly under the impression that, to be a dev, one was *expected* to pick up a lot of packages and spend a lot of time. Good to know that’s not the case. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] About reducing or even removing stable tree for some arches
On Mon, 16 Feb 2015 10:59:06 -0500 Joshua Kinard ku...@gentoo.org wrote: Once we complete the git migration, why not take a second look on using a stable/testing/unstable (or -RELEASE/-STABLE/-CURRENT) system used by Debian and FreeBSD? That should be entirely doable under a git tree versus CVS. It would require beefing releng up again and a whole host of other issues. Keep the core git tree constantly rolling forward, have a dedicated branch get cut say, once a year (or less -- Debian is ~18mo?), another group of devs works on stabilizing that (and periodically cherrypicking from the master branch), and when the time comes, totally freeze that for security revs only by a smaller group of devs? Personally, one of the things that I love about Gentoo is that I never have to deal with EVERYTHING changing all at once. Sure, things may change more often through the year than they do with staged releases, but it’s all spread out over the year, so that in any given week, what changes is a nice, bite-sized chunk of my system, so that I can easily isolate and deal with any problems—rather than a staged release that upgrades 150 packages, leaving a dozen things broken and no idea where to start looking. Also, from a more pragmatic point of view, I don’t particularly want to have to *compile* a year’s worth of new packages at one moment in time—better to spend an hour here, an hour there, spread out over the weeks. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] Re: vmware team needs help
On Sat, 14 Feb 2015 21:49:56 +0200 Markos Chandras hwoar...@gentoo.org wrote: You don't have to participate to the discussions in the mailing lists :) You can just contribute code! Even a single patch a month or so is better than nothing Forgive me for hijacking the thread, but, the “or so” in the above isn’t all that flexible. See section 3.k of http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=3. Being required to do something Gentoo-related at least every two months in order to not be considered “inactive” pretty much eliminates any incentive I had to try and become a developer presently. I could certainly see myself picking up three or four packages that I personally care about and maintaining them, but not actually needing to commit anything for a couple of months simply because those packages don’t release anything new very often. Then I’m declared inactive and kicked out because I didn’t commit often enough, simply because I chose to make a small contribution appropriate to my other workload, rather than no contribution at all. Perhaps that’s “your” (collective) intent—to avoid developers who do a tiny bit of work here and there on a few packages, in favour of having a much smaller number of developers who have to handle more packages—which is fine, but it excludes people like me from participating as full developers. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Moving CPU flags into USE_EXPAND
On Wed, 21 Jan 2015 01:13:08 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: (a lot) Thank you, Duncan. You explained by position perfectly. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] Moving CPU flags into USE_EXPAND
On Tue, 20 Jan 2015 09:21:54 +0100 Alexis Ballier aball...@gentoo.org wrote: you will not see it if no package use it. I guess you mean I wouldn’t see it in emerge output if no package uses it, even if it is USE-expanded? Yes, I’m aware of that. But if all the flags are listed together in one place (I forget what the file was called—cpu.flags.use.desc or something?), then I can just open that file to see the list, hence why case 2 is better IMO—put all the entries in that file for users to look at, even if no package uses them yet. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] Moving CPU flags into USE_EXPAND
On January 20, 2015 12:47:03 AM PST, Alexis Ballier aball...@gentoo.org wrote: So, you're telling me that if you have a list of 90 cpu extensions, you will from time to time open that list to see if there is a 91st one added ? I think most people won't even notice, at best they'll look for the changelog. No, actually, I’m advocating the exact opposite. I’m saying that, as long as the list file is kept up to date, then I will look at those 90 flags when I first install and never again. If a 91st flag appears some day, then as long as the file was maintained as I described in an earlier message (i.e. flags are added as soon as manufacturers announce features), I already know I can reliably ignore the new flag. After all, if the flag didn’t exist when I installed the system, then my CPU must necessarily not have that feature—unless CPUs are in the habit of sprouting new instructions after you buy them! Isn't it better to have a script, e.g. in gentoo-x86/scripts (that would be the first of this kind here I think), that would parse /proc/cpuinfo and output 'CPU_FLAGS_...=...' so that for a first install you can simply send its output to make.conf and, if you are paranoid, can use it to check if this has changed in a postsync hook ? I see having a script to select flag values as orthogonal to when the flag values need to be looked at. I also agree that having a script would be a good thing. -- Christopher Head
Re: [gentoo-dev] Moving CPU flags into USE_EXPAND
On Wed, 14 Jan 2015 11:01:16 -0800 Zac Medico zmed...@gentoo.org wrote: Why should we have to foresee the future? We can easily add support for new flags in CPU_FLAGS_* variables at any time. Ah, what I meant was that whoever maintains this flag list only needs to forsee the present—when AMD or Intel adds a new instruction set extension, you add a flag for it to the variable immediately, whether or not any package actually uses it yet. Why? Here’s why: Case 1: flags are added only as packages need them. This is pretty much what we have today, only without the USE-expand feature. Every time a package adds support for a new CPU feature, it gets a new USE flag, and I see it in my emerge output. Now I have to go and look up what the feature is, what it would be called in cpuinfo, and whether I have it. Maybe I already looked up the same CPU feature two or three times, many months ago, and forgot about it, for some other package. Lots of wasted work. But I can’t just ignore it, because maybe this is the first time that flag showed up, because no package ever used that feature before, but my CPU *does* have it, so I really want to turn it on! Case 2: flags are all added immediately as the CPU features are announced. When I install Gentoo, all the possible flags for my CPU are already listed in the variable. I immediately turn all those I have on and all those I don’t have off. Done. Now I can completely stop paying attention to the flags. As packages gain support, they gain new flags, and I can ignore them, secure in the knowledge that the flags for those features I have will all be turned on, while those I don’t have will be turned off, with no further input from me. Nice and easy. I’m not saying add flags for feature sets that haven’t been announced yet. I’m just saying, add flags for feature sets that *are* announced but that no package actually uses yet. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] Moving CPU flags into USE_EXPAND
On January 14, 2015 7:16:46 AM PST, Alexis Ballier aball...@gentoo.org wrote: however, i disagree with your rationale: asm for specific cpu extensions tend to be written and tested after given cpu is available, thus if you have a brand new cpu, you want to be notified if a package gains support for this new instruction set Do people really want to be notified if a package gains support for a new instruction set? I know I don’t. I would rather have all possible instruction set extensions available as flags and set whichever ones my CPU has once, at install time. If a package gains support for an extension later, then whenever it upgrades, it will just work, because the relevant flag will already be set in make.conf from back when I installed Gentoo on the box. For this to work right requires that a dev add all the extensions to the flag before I buy the CPU. All that requires is knowing the names, though; it would be fine if no package actually uses the feature yet. -- Christopher Head
Re: [gentoo-dev] rfc: openrc service script dependency checker
On December 4, 2014 8:12:58 AM PST, Andrew Savchenko birc...@gentoo.org wrote: Yes. But booting as much services as possible is even more preferable, especially when box is remote. Are you sure booting most, but not all, services in a loop is always better than booting none of them at all? What if I have an insecure dæmon listening on TCP, I need it running, but I want to ensure only local processes can connect to it? Obviously, I would make it “need iptables”, assuming the dæmon doesn’t have its own bind address config knob. What if now, by some accident, iptables ends up in a loop (maybe not even a loop including $insecure_service, but some other loop entirely), and it’s the randomly chosen victim? Is it still good to boot as many services as possible? I think not. -- Christopher Head
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Thu, 16 Jan 2014 23:44:42 +0100 Tom Wijsman tom...@gentoo.org wrote: If I don’t, why do I care if the package is a year old? I lose none of my time to use the old version, since it does all I want; This is under the assumption that the old version has no further implications, which is a false assumption; because the older a stable ebuild get, the higher the chance is that it becomes incompatible with its libraries and/or causes blockers. Even further, a security bug for an old version of a library it depends on could cause its removal. Right, of course things can become incompatible—but the distro handles that by either leaving old enough version of e.g. libraries around that the latest stable versions of their reverse dependencies don’t break, or, in exceptional cases (e.g. security), by breaking things intentionally if necessary, thus telling me that there’s a problem. I lose a nonzero amount of time if I get a version which breaks things (even if the only time I lose is the time it takes to downgrade), Depends on whether the stable version is as perfect as one thinks it is; an upgrade can go two ways, it improves or regresses. (Well, three ways as it can stay the same, but that wouldn't demonstrate the point) Well, yes. I was considering the case of a stable version that does work well. If the stable version has a bug that affects me, I won’t be using it—I’ll pull in an unstable version that fixes the bug, and then get back to stable ASAP after that. so it’s in my best interest to use the stable versions of such packages, even if they’re a month, a year, or three years old. Based on what you know, what you need and that you can resist change; yes, but this doesn't take into account what you don't know, you don't know you need and the improvements that change can bring. While it doesn't happen often, some people will say if I knew this earlier, I would have already upgraded a long while ago; either because the new version brings something good, or the old version has a regression they were not aware of yet or came due to incompatibility... Sure, it was wrong to say it takes *no* time, but I think less time than sticking to the bleeding edge and having things break from time to time. My experience with stable has been that bugs (at least bugs that I encounter) are rare and, most importantly, bugs are *very* rare in the important packages that are hard to fix (glibc, openrc, gentoo-sources, openssh for servers, etc.). I understand they’re fairly rare in unstable as well, but I would expect a bit more common than in stable. If stable really is falling behind and the backlog is always growing, obviously something has to be done. I just don’t want “something” to mean “don’t have a stable tree”. The stable tree provides me with a benefit. If standards have to slip a bit to maintain timeliness, then I’d prefer a stable tree that’s as stable as practical, accepting reality—perhaps where users are able to submit reports of working packages, or where we let platform-agnostic packages be stabilized after one arch has tested, or various of the other suggestions in this thread. Just not no stable tree at all. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Hosting daily gx86 squashfs images and deltas
On Fri, 17 Jan 2014 19:53:44 +0100 Michał Górny mgo...@gentoo.org wrote: Dnia 2014-01-17, o godz. 10:18:58 Alec Warner anta...@gentoo.org napisał(a): On Fri, Jan 17, 2014 at 8:27 AM, Michał Górny mgo...@gentoo.org wrote: Hello, all. I'm using squashfs to hold my Gentoo repositories on all of my systems for some time. As you probably know, this allows me to save space while keeping portage fast. However, it makes updating the tree quite burdensome and time-consuming. Yes, full metadata with md5-cache. That's the same thing you get via 'emerge --sync'. And that's why the deltas are so big -- I recall three big cache updates this week. I would absolutely use this on my machines. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 20:46:04 -0600 William Hubbs willi...@gentoo.org wrote: s/month/year/ Do you feel the same way then? I have heard of stabilizations taking this long before. I just had to try to pick something reasonable for the discussion. I suppose a compromise would be, instead of removing the old versions, move them back to ~arch for a month then remove them, but that still implies action on your part. William If I need or want a feature or bugfix which isn’t in the newer version, I always have the choice to use ~. If I don’t, why do I care if the package is a year old? I lose none of my time to use the old version, since it does all I want; I lose a nonzero amount of time if I get a version which breaks things (even if the only time I lose is the time it takes to downgrade), so it’s in my best interest to use the stable versions of such packages, even if they’re a month, a year, or three years old. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] Moving more arches to dev profiles
On Thu, 22 Aug 2013 12:28:24 +0100 Markos Chandras hwoar...@gentoo.org wrote: Wow! That is something we actively encourage people to avoid. Mixed systems are totally unsupported and I am sure quite a few bugs are closed as invalid when a mixed system is detected. It may work on regular basis but encouraging and supporting such configurations is definitely not desirable. It's also a bit ehm, funny, to give them a stable stage3 and then tell them that for everything else, please use ~arch. Really? So you’re telling me that if I want Drupal on my Web server, which if it breaks then takes a few minutes to revert to the previous version and has virtually zero chance of taking anything else down with it, then it’s “definitely not desirable…to encourage” me to use mixed keywords—instead I should be using ~arch versions of, say, glibc, iproute2, openssh, openrc, and the kernel, every single one of which, should it break, would be fixable only with a bus ride across the city, access to a locked room, wiring up a keyboard and monitor, and possibly booting from a live disk? There’s breakage of one package, and then there’s breakage of the *system*. Running mixed versions may increase the chance of breakage of the particular package that’s ~arch as compared to running a full ~arch system, but as long as that package isn’t part of or needed by the system boot process, I can’t see how mixed versions could do anything but decrease the chance of breakage of the system as a whole. Chris signature.asc Description: PGP signature
Re: [gentoo-dev] Re: renaming gentoo-oldnet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 5 Aug 2013 05:20:32 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Exactly. That's why I like it. netrc is generic enough to be used elsewhere, yet descriptive enough of what it actually does, that from my perspective anyway, it's perfect. =:^) Probably not a big deal, but there is a “~/.netrc” file which holds usernames and password for various services (some FTP clients use it, maybe others). Chris -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlH/OSYACgkQnfE3lq0v9IzItAEAh2t+7HZKTthl0im5aMtIp3AQ nDfQkCOetZMyXEqvRGAA/05+NalxmSIn5FkkNK5+MeVrMydToxFfctROFy8FeS4U =cPcz -END PGP SIGNATURE-
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, 10 Feb 2013 20:43:02 +0100 Dirkjan Ochtman d...@gentoo.org wrote: On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani lx...@gentoo.org wrote: +1 from me; I've had a few machines break on kernel upgrades because I didn't have the proper firmware installed (I guess older kernel sources came with the firmware?). This is another problem, namely dependency level problem. I don't see how having kernel sources ebuilds providing /lib/firmware would fix any of the listed issues without causing other side effects. For starters, if kernel sources provide /lib/firmware, how do you deal with file collisions? Sorry this is not threaded properly; I accidentally deleted the e-mail I intended to reply to. Please don't make kernel sources RDEPEND on firmware. The kernel DOES NOT depend on firmware to work properly. Well over half my machines prove that: they work perfectly fine (read: 100% of their hardware works) with no firmware at all installed. Don't force me to install a package that provides me with a grand total of zero benefit, just so you can hand-hold people. It's unfortunate that people were caught by the firmware being removed from the kernel and breaking their hardware. This sounds like an application for a news message telling people to install firmware if needed, but IMO it doesn't call for a dependency. Chris
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, 10 Feb 2013 14:49:03 -0800 Alec Warner anta...@gentoo.org wrote: Most external firmware is not needed to boot. If you need it to boot, you will have to stow it in the initramfs. For those of us who prefer monolithic kernels, virtually all firmware is needed to boot. Even if a network interface doesn't need to be operational for boot, the kernel insists that the firmware be available right at boot or else it will fail and the interface will never appear. Chris
Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)
On Tue, 12 Feb 2013 20:51:15 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Christopher Head posted on Tue, 12 Feb 2013 11:38:14 -0800 as excerpted: On Sun, 10 Feb 2013 20:43:02 +0100 Dirkjan Ochtman d...@gentoo.org wrote: On Sun, Feb 10, 2013 at 5:54 PM, Fabio Erculiani lx...@gentoo.org wrote: +1 from me; I've had a few machines break on kernel upgrades because I didn't have the proper firmware installed (I guess older kernel sources came with the firmware?). For starters, if kernel sources provide /lib/firmware, how do you deal with file collisions? Please don't make kernel sources RDEPEND on firmware. The kernel DOES NOT depend on firmware to work properly. Well over half my machines prove that: they work perfectly fine (read: 100% of their hardware works) with no firmware at all installed. Not a problem as long as the RDEPEND is under USE=firmware or similar. No USE=firmware, no rdepend! =:^) Kernel sources providing /lib/firmware itself shouldn't be a problem either, as that's just a dir, which many packages may own. The individual firmware files would be a problem, but the USE=firmware RDEPEND solution should solve that. Yes, of course, I meant please don’t depend unconditionally. A conditional depend is fine by me, and I don’t care about one random directory being created—I just don’t want a whole package being pulled in for nothing. Chris
Re: [gentoo-dev] Re: Please stop useless removals
On Fri, 1 Feb 2013 09:45:07 -0500 Rich Freeman ri...@gentoo.org wrote: That seems rather speculative. I'm sure that people look for vulnerabilities in unmaintained software - if they didn't then nobody would be able to exploit them in the first place (you have to find a vulnerability to exploit it). I imagine most vulnerabilities are found by people outside of projects in the first place. We don't know how many vulnerabilities there are in maintained packages, let alone unmaintained ones, so a comparison is a bit difficult. Also, there are plenty of packages that can't really *have* interesting security vulnerabilities in the first place. I don't know the specifics of the games that were removed, but games in general, if they are purely single-player and only ever read and write files in the player's home directory, don't really have an attack surface to start with. You can't remotely exploit a program that never creates a socket, and you can't locally exploit a program that never tries to access files other than those in its invoker's home directory and root-writable directories like /usr/share, and does so with the invoker's usual privileges. Do you treeclean those because they might have security holes? Chris
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Fri, 25 Jan 2013 13:47:05 -0500 Rich Freeman ri...@gentoo.org wrote: Very problematic. What is built in for the currently running kernel can be fairly reliably determined by grepping /proc/config.gz - IF support for that was enabled in the kernel. But, there is no guarantee that this kernel will be running on the next boot. Determining what is build as a module really requires interpreting the contents of /lib/modules - a module could have been built after the kernel was built, in which case /proc/config.gz might indicate no support even though it is supported. I don't think DEVTMPFS can be made a module, however (not sure on that). Surely even that isn’t good enough, since the user could have built an option as a module, tested it out, discovered it worked fine, and then rebuilt the kernel with the option set to Y, but the .ko file would still be left lying around? Chris
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
Are you sure? I have CONFIG_DEVTMPFS_MOUNT disabled, latest stable udev (197-r3) and openrc (0.11.8), and no /dev line in my fstab, yet my /dev is still a devtmpfs with a proper set of device nodes. Chris On Wed, 23 Jan 2013 17:03:15 +0100 Michael Weber x...@gentoo.org wrote: Hi, On 01/23/2013 04:04 PM, Rich Freeman wrote: System seems to work fine, so I'm not sure how essential that line is. The fact that I'm using an initramfs might also have an effect. I'd strongly suggest using CONFIG_DEVTMPFS_MOUNT=y. and stop worring about udev/openrc. udev/openrc stopped re-mounting /dev that last year. Michael
Re: [gentoo-dev] removing the server profiles...
On Thu, 17 Jan 2013 15:02:48 -0500 Rich Freeman ri...@gentoo.org wrote: We might be talking past each other. Sane but minimal is the target. Bottom line is that the question isn't whether a minimal system should have CUPS installed (that would be an argument for putting it in @system - ugh!). The question is whether a minimal/base system should have the cups USE-flag enabled for packages that actually use it. And cups is just an example - maybe not a good one. I just want to make sure we're not just dropping flags left and right that everybody and their uncle will either re-enable, or won't notice them being removed anyway. I understand that enabling flags only affects packages if they’re installed. I’m just saying that, in my opinion, sane-but-minimal should have CUPS disabled because there are plenty of computers that would want LibreOffice and/or Chromium installed but not have a printer. They need not be servers if the target is simply sane-but-minimal. Chris
Re: [gentoo-dev] removing the server profiles...
On Wed, 16 Jan 2013 22:17:26 -0500 Rich Freeman ri...@gentoo.org wrote: Oh, and keep in mind that flags really only have an effect if the corresponding packages are actually installed. For example, the cups flag doesn't really have an effect unless you install apps that do printing, so it seems pretty safe to leave in a minimal profile (would you really want to install libreoffice, chromium, or foomatic and not have cups support?). Really? Yes, I can see plenty of cases where I’d want LO or Chromium but with USE=-cups, because there’s no printer anywhere in sight. Why should that mean I don’t want an office suite or a web browser? Probably not so much foomatic (though maybe there are other printing frameworks than CUPS that people might use?), but LO and Chromium absolutely. Chris
Re: [gentoo-dev] removing the server profiles...
On Thu, 17 Jan 2013 14:32:01 -0500 Rich Freeman ri...@gentoo.org wrote: Sure, I can think of reasons why I would want chromium with -cups, but the whole point is to target the TYPICAL user. And the context here is servers - how many servers would have chromium installed with -cups? If anything I'd expect more servers to have CUPS installed than chromium in the first place. Sorry, I thought the point was to make the base profile “sane but minimal”, not to make it server-specific. In that case USE=cups might make sense. Chris
Re: [gentoo-dev] call for testers: udev predictable network interface names
On Wed, 9 Jan 2013 16:13:10 -0600 William Hubbs willi...@gentoo.org wrote: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames This seems like a good thing for some systems. Will there be a news item when 197 (or greater) goes stable informing people that the option is available and if they want to use it they can do so? In my (ordinary user) opinion, there should be. Chris
Re: [gentoo-dev] call for testers: udev predictable network interface names
On Wed, 9 Jan 2013 18:13:21 -0600 William Hubbs willi...@gentoo.org wrote: There is a way for users to opt out if we default this to on, but I think the new naming scheme has advantages over the traditional eth* wlan* etc names. I think it should be taken with a grain of salt. The page mentions how it lets you replace a failed NIC without losing its name. But given a simple computer with just one NIC, if the NIC fails and is replaced (perhaps by a different type of NIC in a different slot, or perhaps an onboard NIC disabled in the BIOS and replaced by an add-in), the name could change, while the kernel’s automatically assigned name will not: eth0 (this also applies to a computer with one Ethernet NIC and one wifi NIC: eth0 and wlan0). That fact was never mentioned on the wiki page, even though it applies to a heck of a lot of systems. Perhaps something to include when the Gentoo docs are put together, as part of the balance of reasons to choose one way or the other? Chris
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On Mon, 10 Sep 2012 09:48:32 -0500 William Hubbs willi...@gentoo.org wrote: Does anyone have any thoughts about whether we should keep OpenRC support for one or both of these? As a user… yes? I use a laptop, so I don’t much care which one is maintained but I’d be quite annoyed if both went away (unless there’s some other dæmon that does the same job that I’ve never heard of). Side note… we’re talking about a pretty tiny program here. Is “upstream unmaintained” actually really a big deal? I mean, if ifplugd has worked without bugs for the last seven years then it doesn’t really matter that it’s unmaintained, does it? All the bugs on ifplugd in BGO appear to be mostly a pile of stuff related to the scripts around it, plus #214842 which appears to have been the kernel’s fault and #171415 which was a minor QA issue. Chris
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Sun, 12 Aug 2012 11:03:01 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: 2. I saw on some lists that Gnome/Kde and Xfce plan to use some SystemD API, so does it means that we will need to install SystemD aside of OpenRC ? For Xfce it only means that xfce4-session will try to query credentials also from systemd, not ConsoleKit alone There are no plans of removing ConsoleKit support for Xfce wrt upstream anytime soon since Xfce is committed for long-term BSD support, and the Xfce development team includes developers, from eg. OpenBSD 4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps related to SystemD ? I don't understand why these desktops want to depend on a specific Sysint || ( sys-auth/consolekit sys-apps/systemd ) or something can be done if the package tries to query both via DBUS calls As in, something needs to tell PolicyKit (polkit) that you are a local user and thus grant access to eg. USB removable devices What about those of us who are perfectly happy using neither one? I’ve never had any of the Kits installed, and the recommendation has always been to just put yourself in the “plugdev” group which has worked fine. Is this going to continue to be possible, or is this going away? Chris
Re: [gentoo-dev] pid 1 design
On Thu, 9 Aug 2012 12:30:54 -0500 William Hubbs willi...@gentoo.org wrote: Ok folks, I hit the wrong key; this was meant to go to the list. On Thu, Aug 09, 2012 at 05:59:39PM +0200, Luca Barbato wrote: Yet I'm not used to have to reboot after issuing emerge -u world and most of the times I don't have even to restart X... What if sysvinit is updated during that emerge -u world? Don't you reboot then? William # telinit U (also works for libc replacement, and it’s actually done automatically by the sysvinit ebuild) Chris
Re: [gentoo-dev] Opinion against /usr merge
On Thu, 19 Jul 2012 07:05:39 -0400 Rich Freeman ri...@gentoo.org wrote: As others have mentioned, coreutils doesn't impact the initramfs much anyway, though other tools like mdadm/lvm/etc are more likely to. I think the more practical issue is that it isn't straightforward to do in an automated way. I suppose we could keep an always-up-to-date kernel and initramfs SOMEWHERE, but that won't necessarily be where the user boots it from. Also, we need flexibility as users tend to tweak these things - dracut has lots of options for how the initramfs is built, users might use any of several initramfs implementations, and the kernel config is frequently tweaked, and doesn't always work if you just do a make oldconfig. Usually the way other distros make all of this work is by making everything generic and not support configurability. Rich For me, the issue isn't so much that it's *hard* to rebuild an initramfs as that it's not obvious *when* to do so. For the kernel, this is a trivial problem: when sys-kernel/gentoo-sources bumps, rebuild the kernel. For an initramfs, when do I rebuild? When there's a new, what? Coreutils? Mdadm? LVM? Glibc? Busybox? Something-firmware? What about any less-obvious libraries they might link to, like zlib or something? All of those things are presumably in my initramfs, but there's no canonical list I'm aware of that tells me if one of the packages in this list updates, you must rebuild your initramfs if you wish to take advantage of the upgrade. Chris
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 11 Jan 2012 08:41:04 +0100 Michał Górny mgo...@gentoo.org wrote: Remind me of a single good reason. Last time I heard those were mostly hacks and laziness. Here's one: ability to share disk space automatically between /usr and /home (implication: must be same filesystem; useful because these are the two largest filesystems in most of my installs; substitute /var if you prefer for servers), ability to take consistent backups without stopping activity (implication: /home must be on LVM for snapshots; implication: /usr must also be on LVM due to sharing filesystem with /home), ability to not use an initramfs (implication: root must not be on LVM). Unless you'd like to suggest a better way to achieve all three of these goals? Chris signature.asc Description: PGP signature
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 31 Jul 2011 04:40:33 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: Can we discuss both options? If there's any option that allows the use of a separate /usr partition without an initramfs, then let's explore it. I don't feel like having to use an initramfs just because I want a small / without /usr on it. The message is really missing all the context without explanation for WHY you want it. (As an interested non-developer) My own rationale is as follows: 1. I do regular backups of /home. I would prefer to have them run in the background while I continue using the system, so the filesystem won't be idle. For consistency, that means I want /home in LVM, so I can create a snapshot and back that up instead—it will be at least as consistent as an instantaneous power failure would be, which things tend to be pretty good at recovering from (both the filesystem and anything above it that uses a journal of some sort, like sqlite). 2. /home is big. /usr is big. When I first install a system, it's not clear exactly how big each one will be. It's really nice to be able to share space between them without any manual intervention, which is what happens if you put both on the same filesystem. Thus, if /home is in LVM, then /usr must also be in LVM, on the same LV. 3. Booting with / on LVM requires an initramfs. It's much easier to not use an initramfs than to use one. So I keep / outside LVM as a small ordinary partition, typically ~250MB (no need for a separate /boot partition in this case). That said, I hadn't ever actually noticed that putting /usr on a separate filesystem was broken in the first place. It's served me well enough. I'd just like it if it would continue to do so. If I have no choice I suppose I will have to switch to using an initramfs, but I prefer not having to poke the early boot sequences of machines it's a PITA to get physical access to that have been working fine for years. Chris -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk41E38ACgkQXUF6hOTGP7emFACfYeoq2vSxk8B1I+URk5ohGbvJ soYAoJZ1p2cm4IjoEFvdfzkQNlxERCv1 =yZkv -END PGP SIGNATURE-
[gentoo-dev] Virtual default changes for old users, was: Heads up: libjpeg-turbo stabilization, becoming the default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 27 Mar 2011 11:33:03 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: libjpeg-turbo stabilization is happening for amd64/x86 at http://bugs.gentoo.org/360715 - the gentoo-x86 has been converted to virtual/jpeg to support this. - we have no bugs reported against the package. - libjpeg-turbo is default in virtual/jpeg so just heads up. Hi everyone, Just a user, not a developer, but: The third point of this message made me wonder about something. New installs will get libjpeg-turbo, as it's the default. Old users may never know it exists! It seems that making lbjpeg-turbo the default implementation of virtual/jpeg is expressing some small preference in favour of it, but old users will never be presented with the choice to switch. It seems like this is a bit of a gap in package management, that even if a better package becomes available and becomes the default implementation of a virtual, existing users will keep using the worse package for no other reason than that it's already installed (and there's no message anywhere even telling them that the change happened). Does anyone think this is suboptimal and that it might be nice to investigate alternatives? Chris -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk3nHIkACgkQXUF6hOTGP7ftqwCgho+EhlOnvy1swE7nOE21TcMq wiIAn1Vr9fRZmvRIvyO5vsILWT9XzSxi =GIqk -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: Do we still want group based permissions for storage and power devices in light of ConsoleKit and Policykit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 17 May 2011 01:13:15 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: User perspective... If it's at all possible to continue to have a consolekit/polkit-less system, making them USE-based dependencies of kde, gnome, etc, relying entirely on apparently now legacy groups, that should be done. Given upstream dependencies it might not be possible, or might require dummy libraries/services that simply return permitted for whatever and let kernel user and group permissions handle it, but having such dummy services is still a good thing, and /shouldn't/ be too hard to maintain, given most functionality would be stubbed in. (I'm only a user, not a developer, but…) I agree with this. I don't use the various *kits. Don't have any use for them. I just throw myself in plugdev and I'm happy with that solution, and I'd appreciate being able to keep on doing that. Of course if it becomes impossible to support then it's not reasonable for distro maintainers to do that, but as long as it works I'd appreciate having the choice. Chris -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk3R+pMACgkQXUF6hOTGP7e8EwCgkrW12lHNxJFov9HwP63CTZ+e dwAAn2DOTWnkfMW9MT0GpKIeCabs2+7G =HQoP -END PGP SIGNATURE-
Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 27 Mar 2011 08:30:16 -0500 Jeremy Olexa darks...@gentoo.org wrote: The tree has 679 m-n packages. http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml I want to proxy-maintain app-misc/pwsafe. It hasn't been updated in six years, but it still builds (albeit with a few warnings) and works and I use it and don't want to see it disappear. Is anyone willing to do this? Chris -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: GnuPT 2.7.2 iEYEARECAAYFAk2PnAEACgkQXUF6hOTGP7fSvACgls+xMxexfWytiXxYH0VwTY9c G1MAn3nKImR6inTrnh2Bsnq86rcsbzXd =pDQ6 -END PGP SIGNATURE-
