Re: [gentoo-dev] Re: Changing order of default virtual/udev provider
On 02/10/2016 20:15, Ian Stakenvicius wrote: > On 10/02/16 12:09 PM, Brian Dolbec wrote: >> On Wed, 10 Feb 2016 10:26:12 -0600 William Hubbs >> wrote: > > Often the decision to procrastinate is a decision that is rewarded. That should be considered carefully. >>> >>> + 1. >>> >>> I also saw another issue that made me shudder. If we change >>> the default to eudev, people who are running separate /usr are >>> going to think they can kill their initramfs's, because people >>> in gentoo conflated the separate /usr and initramfs issue with >>> udev [1]. >>> >>> William >>> >>> [1] https://bugs.gentoo.org/show_bug.cgi?id=573760#C4 > [snip] > > Yeah I second this -- it was decided officially by council (what, 2 > years ago now?) that separate-/usr-without-initramfs doesn't need to > be officially supported anymore, and so if things break that it is > up to end-users to ensure they pick up the pieces. > > Although it is likely that eudev *will* keep installation onto / and > out of /usr to help with this not-officially-supported situation in > Gentoo, that doesn't mean the other projects have to stay out of > /usr, and "it worked before the upgrade but doesn't now" certainly > doesn't mean it's a valid bug. If a user or sysadmin drops their > initramfs when they have a separate-/usr system, any resulting > breakage is on them. > FWIW, I have separate /usr on several systems, and haven't needed an initramfs thus far. I thought we had some trick active in busybox or even eudev that handles separate /usr for *simple* filesystem configurations (i.e., just basic partitions, no LVM, evms, encryption, etc). So I don't there would be immediate breakage in this scenario. It's going to depend on how a given system was configured. Simple setups appear to JustWork(), AFAICT. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Uncoordinated changes
Speaking of which is there a bug filed for that? On Sat, Feb 13, 2016 at 5:16 PM, Rich Freeman wrote: > On Sat, Feb 13, 2016 at 7:58 PM, Raymond Jennings > wrote: > > So what do you guys think of leaving behind empty stubs for compatibility > > and then simply filing a tracking bug blocked by any packages that > removing > > herds broke? > > It isn't entirely clear that anything is actually broken at the > moment, but if distributing an empty herds.xml file makes somebody's > life easier I have no objections. I don't think it would have > alleviated Patrick's original concerns in this case. > > -- > Rich > >
Re: [gentoo-dev] Uncoordinated changes
On Sat, Feb 13, 2016 at 7:58 PM, Raymond Jennings wrote: > So what do you guys think of leaving behind empty stubs for compatibility > and then simply filing a tracking bug blocked by any packages that removing > herds broke? It isn't entirely clear that anything is actually broken at the moment, but if distributing an empty herds.xml file makes somebody's life easier I have no objections. I don't think it would have alleviated Patrick's original concerns in this case. -- Rich
Re: [gentoo-dev] Uncoordinated changes
So what do you guys think of leaving behind empty stubs for compatibility and then simply filing a tracking bug blocked by any packages that removing herds broke? On Sat, Feb 13, 2016 at 2:44 PM, Rich Freeman wrote: > On Sat, Feb 13, 2016 at 4:47 PM, Raymond Jennings > wrote: > > The guys making the API change bear the burden of fixing anything it > breaks, > > however, if something gets officially deprecated, don't go out of your > way > > to support continued use. > > We tend to do this already for things like PMS, which is as close as > Gentoo gets to something like the kernel API. > > However, sometimes a gradual transition doesn't always make as much > sense, and Gentoo doesn't always have the manpower to make every > change a pretty one. > > And there is a cost to maintaining that kind of backwards > compatibility. For example, debian chose to keep its LSB init scripts > and write systemd unit wrappers around them. If they had chosen > openrc instead I wouldn't be surprised if they kept the LSB init > scripts and wrote an openrc compatibility layer around that. While > this does provide a more stable experience, it also leaves around a > ton of cruft. > > In general I tend to favor a balance. Trying to get everything just > right was why the git migration literally took years, and even that in > the end had a few bumps. Gentoo users need to be willing to deal with > the occasionally bump in the road - we try to provide a fairly cutting > edge experience, with minimal layers in integration. > > But, there is nothing really wrong with your suggestion, and we try to > accommodate that approach when we can. > > > And yes, the personal attacks probably should die down. > > ++ > > -- > Rich > >
[gentoo-dev] Planet Gentoo / Gentoo Blogs - Announce
== Announcement Gentoo Blogs: == We have upgraded the WordPress install, the themes and the plugins for the blogs.gentoo.org. There are a few announcements as some things have changed with the latest version: 1. "Twenty Fifteen" Theme. "Twenty Fifteen" was the theme for the previous version of wordpress as the default theme, and if you accepted the default theme it is your theme as well. There were some changes where some sites, are not displaying correctly using that theme. Please take a look at your site and feel free to pick another theme. Wordpress has introduced "Twenty Sixteen" which looks cleaner now and might be a good choice. 2. "Twenty Thirteen" theme is currently broken. The new WordPress update also brought with it a broken theme now. "Twenty Thirteen" no longer works correctly as well. Please take a look at alternative themes for your web site. As within seven (7) days we will be turning off that theme. 3. Picasa Albums Plugin The Picasa Albums plugin has not been updated in Two (2) years, and with this version is no longer functioning. If you are using this version. If you are using this plug-in please let me know. As we would have to find a replacement. If you have any questions please feel free to contact me directly or "pla...@gentoo.org" -- Yury German GLSA Coordinator | Gentoo Security Team Administrator | Planet Gentoo Email: bluekni...@gentoo.org GPG Fingerprint: 8858 89D6 C0C4 75C4 D0DD FA00 EEAF ED89 024C 043 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Uncoordinated changes
On Sat, Feb 13, 2016 at 4:47 PM, Raymond Jennings wrote: > The guys making the API change bear the burden of fixing anything it breaks, > however, if something gets officially deprecated, don't go out of your way > to support continued use. We tend to do this already for things like PMS, which is as close as Gentoo gets to something like the kernel API. However, sometimes a gradual transition doesn't always make as much sense, and Gentoo doesn't always have the manpower to make every change a pretty one. And there is a cost to maintaining that kind of backwards compatibility. For example, debian chose to keep its LSB init scripts and write systemd unit wrappers around them. If they had chosen openrc instead I wouldn't be surprised if they kept the LSB init scripts and wrote an openrc compatibility layer around that. While this does provide a more stable experience, it also leaves around a ton of cruft. In general I tend to favor a balance. Trying to get everything just right was why the git migration literally took years, and even that in the end had a few bumps. Gentoo users need to be willing to deal with the occasionally bump in the road - we try to provide a fairly cutting edge experience, with minimal layers in integration. But, there is nothing really wrong with your suggestion, and we try to accommodate that approach when we can. > And yes, the personal attacks probably should die down. ++ -- Rich
Re: [gentoo-dev] Uncoordinated changes
My two cents: Do it like in linux kernel. The guys making the API change bear the burden of fixing anything it breaks, however, if something gets officially deprecated, don't go out of your way to support continued use. I for one would consider "ok, this method is not working, deprecate it so that it doesn't get any worse because we're going to be changing it later" is quite an appropriate way to bear the burden. Anyone getting grandfathered from doing it the old way escapes the burden, but by putting the entire community on notice via the GLEP process, well, grandpa got put out to pasture and after that point the community inherited the burden of not deepening the dependency on the freshly deprecated feature. Since this is a collective superproject it can also be said that we all bear the collective burden of cooperating towards a common goal. And yes, the personal attacks probably should die down. I'm not with devrel or comrel but even I can tell such sniping and whatnot can decrease overall productivity of the distro by bringing down morale. Solution? If anything broke because herds were removed? My suggestion is to leave behind herds as empty stubs somehow, officially deprecate herds (which the council already did from what I gather), and file a tracking bug to have herds removed entirely. Then just do what they do with new versions of gcc, and have existing tools that break when herds are removed have new bugs filed on them that block the tracking bug. The breakage cited in the first post would be a good example of a dependent bug that ought to block the "we still have herds" bug. What do you guys think? Just use a tracking bug to flush out anything still using herds like they do when new versions of GCC come out and break stuff? On Fri, Feb 12, 2016 at 2:02 PM, Michał Górny wrote: > On Fri, 12 Feb 2016 10:07:10 +0100 > Patrick Lauer wrote: > > > On 02/12/2016 08:48 AM, Michał Górny wrote: > > > Dear Ignorant Patrick, > > Hello human! Your politeness module seems to have crashed. > > Please do not expect politeness when you insult someone. > > > > On Thu, 11 Feb 2016 21:15:34 +0100 > > > Patrick Lauer wrote: > > > > > >> ... or why just changing stuff is not enough: > > >> > > >> A few days ago I was told that > > >> http://euscan.gentooexperimental.org/herds/ was displaying an empty > > >> list. Which is annoying because people sometimes want to see what > > >> upstream updates are available for their herd. > > >> > > >> Well, we renamed herd to project. Because reasons. > > > No, we didn't. Herd was collection a packages. Project is a collection > > > of developers. Project coexisted with herds for a long time. As it was > > > explained already in length. Multiple times. > > So you just pivoted the organization from A->B to B->A. > > > > I still don't see the advantage in that. Maybe I should have expressed > > my concerns more vocally, but in general I don't have time to worry > > about all the little things. > > You still have trouble understanding who did what. I'm tired of being > blamed for something that wasn't my idea. > > > >> I don't care how it is named, but this change broke euscan in a > > >> user-visible way. Now I could just try to rename things there too, but > > >> that won't work: > > >> > > >> euscan uses gentoolkit for parsing metadata.xml and herds.xml > > >> (Since herds.xml is basically unmaintained cruft at this point this > will > > >> break soon anyway ... but ...) > > >> Changing gentoolkit to use projects.xml instead of herds.xml won't be > a > > >> simple migration since the data organization changed. > > >> > > >> Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml] > > >> -> email it goes backwards: > > >> [metadata.xml] -> (maintainer type=project) -> email -> [projects.xml] > > >> -> Project name > > >> > > >> Since this involves XML and python's ElementTree library it's a > > >> nontrivial change that also removes a few now useless helpers > > >> (_get_herd_email has no reason to be, but we'd need a _get_herd_name > > >> helper instead. Err, get_proj ... ah well, whatever name works) > > >> > > >> And all that just so (1) gentoolkit output works and (2) euscan > updates > > >> properly. Both of which I don't really care about much, but now that > > >> I've invested ~4h into debugging and trying to fix it I'm a tiny bit > > >> IRRITATED. > > > You are completely incorrect, as you have been told already multiple > > > times. People would really appreciate if you spent at least a little > > > part of the time you spend complaining, inventing issues and insulting > > > others listening to what they're telling you. > > > > > > So let me repeat, again. euscan works. Want packages from Python > > > project? Then select the appropriate maintainer from the 'maintainers' > > > section: > > So you're saying I have no way to search by herd, err, project now. > > Yes, you have. You can use project's e-mail address to find > the project. And as
