Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
> On Fri, 15 Nov 2013, Ben de Groot wrote: > As I see it now, with respect to multilib, we have three competing > solutions, but not a clear direction which way we want to go as a > distro: > 1: emul-* packages > 2: multilib-portage > 3: multilib.eclass > I would like to vote for option 1, as it is the least intrusive and > does what we need. If it is really felt we need a more complete > solution, then my vote would be for 2, since 3 is too intrusive and > more likely to break or complicate stuff for normal users. Option 1 is not a solution, but a workaround. It has served us, but IMHO its replacement is overdue. Just to give an example, stable emul-linux-x86-xlibs suffers from several security issues (bug 471098, A1/critical severity) since half a year. Besides, distributing pre-compiled binary packages seems very un-Gentoo-ish. Not sure why you think that option 3 is more intrusive than option 2. What can be more intrusive than requiring a modified package manager? Ulrich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 15 November 2013 01:32, Rich Freeman wrote: > On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot wrote: >> I was particularly hit by this as maintainer of freetype, see bugs >> 455070 and 459352 for some of the mess that could have been avoided. > > Looks like 455070 was the source of problems there (the other is just > a tracker with the aftermath). The package had no maintainer at the > time, only a herd (per cvs). There was a request in the bug for > whether it was suitable to deploy to production. Somebody associated > with the herd gave a thumbs-up, apparently (I can only say that based > on your comment - I have no idea how that was communicated). Then > something went wrong. Since it caused problems, it was masked. Those > who run ~arch should be thanked for saving the stable users from > potential breakage! > > I'm not sure what should have been done differently. If the package > maintainer (in this case a herd) says that something is good to go, > why would anybody assume that it wasn't? You suggested testing in an > overlay 20 days earlier, but you weren't in any particularly > privileged position at the time (you were presumably just another > maintainer of the herd). I don't really want to bring up this episode again, but it is a telling example, which you asked for. As can be seen from the ChangeLog, I was the primary maintainer. As a member of the herd I didn't feel it necessary to assert any kind of "privilege" any other way. I had already said "no, or at least wait" but that was circumvented by asking another herd member who hadn't touched the package in years. It would have been nice were I asked for my okay before making any changes. And as can be seen, the mess I feared for indeed took place. This could have been prevented, in my opinion, had this seen more extensive testing in an overlay. And this is exactly why I am now more weary for the next package about to be mangled: cairo (bug 488672). I am even tempted to undo the multilib changes to freetype, since it is still causing trouble (just search for freetype bugs and see how often multilib pops up). > I'm not pointing fingers here. This was apparently a > miscommunication, and part of the cause was a failure to document that > there was a primary maintainer of the package (something which was > subsequently corrected). Michał did offer to just maintain the status > quo on that package instead of migrating it, and apparently he thought > he had the all-clear to migrate it anyway. > > Michał did add the multilib project as a co-maintainer, taking > responsibility for dealing with the multilib-related issues long-term. > In my mind this is the sort of things projects should do. Indeed, but more communication with the current actual maintainers of the package in question should also be part of that. > I'm sure there were other issues, but issues will happen when projects > make changes. That's just the way things roll around here. If Michał > just committed a change to a package without conferring with the > maintainer at all or giving significant notice, I'd feel differently. > I think we just need to learn and move forward, and from the looks of > things we have. Gentoo always has been a fairly "disruptive" distro, > though it has settled down of late. I don't think we're erring on the > side of breaking systems too often right now, though I'm always for > preventing that as long as it doesn't require ossification. > > (Just a note - this is all based on what I could piece together from > cvs and bugzilla. I'm sure those who were personally involved could > contribute more detail. I'm not sure it is necessary that do so, but > I'll gladly defer to those with firsthand knowledge.) > >>> In the end, stuff only >>> gets done if people write code. Your power in any FOSS project really >>> comes down to your ability to write code or convince others to write >>> code on your behalf. > >> No, it's more about your ability to commit and get away with it. > > So, I'm 100% for what Donnie said and in general I tend to lean > towards saying "thanks, but no thanks" when a heavy contributor is > driving everybody nuts. However, the reality is that those who commit > more also tend to be allowed to get away with committing more. That's > just human nature - we all like our free toys and we're reluctant to > take too much objection when we're slapped around a little by the guy > who is giving us the free toys. There needs to be a balance, and from > the sound of things Markos is looking to step in and adjust the > balance if it gets out of line. Honestly, I just wish everybody would > do what they can to make his job easier, and I say that without > pointing my fingers in any direction. I think we have a really great > thing going here... > > Rich > Markos has shown initiative and good ideas, so I'm looking forward to positive changes. I am also cautiously optimistic about a renewed QA team, which could be involved more
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 15 November 2013 17:56, Matt Turner wrote: > After using it for a month, he's now convinced that > Gentoo is clearly the most difficult to use. > > I'm inclined to agree, I'd have to disagree there slightly, arch is more easy to use if you stick to the core set, the binary packages ... as is debian. But if you verge outside that set, arch quickly becomes a headache, AUR may have lots of contribution, but its nowhere near the quality we have of even some of our worse quality overlays, and the arch toolchain lacks lots of features ebuild authors have come to rely on. This means if you use arch's equivalent of our overlays, you'll spend much time fixing up broken syntax in AUR packages. I mean, sure, its "simpler", but at the same time, it does so by simply cauterizing out the extra complexity, making it impossible for end users to even opt for the complex or different behaviours, by choosing one for them, and not informing them at all of that choice. So that argument mostly boils down to "useflags add complexity for people who aren't used to them, or aren't interested in them". -- Kent
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Wed, Nov 13, 2013 at 2:28 AM, Martin Vaeth wrote: > The new "features" use.stable.mask and package.use.stable.mask > have turned maintaining systems with mixed ARCH and ~ARCH keywords > into a nightmare: I agree. I have helped two friends convert to Gentoo recently (one used it a few years ago). They both came from Arch, and one told me that before he resumed using Gentoo recently he considered these two distros in the same category in terms of difficulty of use and maintenance. After using it for a month, he's now convinced that Gentoo is clearly the most difficult to use. I'm inclined to agree, and I think in large part recently it's because of use.stable.mask and package.use.stable.mask. These really are a nightmare for users. Heck, they're really a nightmare for me and I've been using Gentoo for nine years and feel like I have a pretty good ability to decipher portage's error messages. I think most of the confusion is caused by the necessity to put a *stable* package atom into package.keywords to unmask a *USE* flag. (Am I doing something wrong that would prevent 'x11-proto/kbproto -abi_x86_32' in /etc/portage/package.use.stable.mask from un-stable-masking the abi_x86_32 USE flag for kbproto?) And then in addition, we did really weird things like stabilizing package versions whose only difference from the previous is that it supports multilib (e.g., kbproto-1.0.6 vs kbproto-1.0.6-r1). Except that it's package.use.stable.mask'd. So you have to keyword a stable package to get its only defining feature. (Why did we stabilize it in the first place?) Portage correctly shows that unstable USE flags are masked by printing parenthesis around them, like use.mask'd flags, but the error messages are really unhelpful. Take for instance dropping the stable =x11-proto/kbproto-1.0.6-r1 from package.keywords, in order implicitly mask the abi_x86_32. Attempting to merge =x11-proto/kbproto-1.0.6-r1 results in: x11-proto/kbproto:0 (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libX11-1.6.2::gentoo, installed) x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libXt-1.1.4::gentoo, installed) There's a single problem. It can't enable abi_x86_32. Why didn't it just say that? You could even go beyond this and explain why it can't do it, but at this point I'd settle for a concise explanation of *what* it can't do.
Re: [gentoo-dev] News item about Gnome 3.8
On Thu, Nov 14, 2013 at 4:22 PM, Pacho Ramos wrote: > > We are pleased to announce the stabilization of GNOME-3.8. Users are > strongly encouraged to read the GNOME 3.8 Upgrade Guide to avoid any > possible issues relating to the upgrade. The guide will also show you > how to migrate to systemd as it is the only supported setup now, > suggesting you how to avoid blockers and problems trying to let you > have a smoother update. I like it - highlights the key elements that users should be aware of, and directs them to more details. Rich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 11/15/2013 03:35 AM, Ciaran McCreesh wrote: > On Thu, 14 Nov 2013 20:07:39 +0100 > Thomas Sachau wrote: >> - multilib-portage was planned to add features with a future EAPI >> version, so in the end needs agreement from maintainers of package >> managers, the pms team and the council. If anyone from those groups >> only claims "you wrote so much, but i dont understand it, write >> more", then it can be a very long time to get it into the main tree >> (also this usually means it is well reviewed and tested) > > That's only a problem if you've got a horribly complicated feature > where you can't remember yourself what you changed to make it work or > how or why you implemented it. > ... or if people shift the goalpost so much that you don't even remember what game is being played
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 11/15/2013 01:51 AM, Michał Górny wrote: >>> So tell me, what you exactly want or need? Or is it just bare >>> complaining for the sake of complaining? >> >> Well, you accidentally cut out all references to TommyD's work again. >> Almost as if you don't even want to discuss a working proper solution >> that just doesn't have the ego hammering it in ... > > 'Proper' is the keyword. The solution you mention has many issues that > I listed more than once, and is far from unobtrusive, clear > or explicit. It's supposedly working, yes, but it is nowhere near > production-ready. But at least the maintainer followed the protocol and did ask for feedback, did not just hammer it into the main tree etc. (Said maintainer was told to properly document AND DICSUSS it, or else ... one wonders why there's so much divergence between these two attempts)
Re: [gentoo-dev] News item about Gnome 3.8
New try: Title: Upgrade to GNOME 3.8 Author: Pacho Ramos Content-Type: text/plain Posted: 2013-11-14 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: http://wiki.gentoo.org/wiki/GNOME/3.8-upgrade-guide
Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/11/13 08:19 AM, Lars Wendler wrote: > Once you go the route to use mirror://gentoo in ebuilds as > SRC_URI people are screwed as soon as the ebuild vanishes from > portage. I'd love to see this (mis-)behavior being more vigorously > discouraged in Gentoo-land... Me too; at least until such time as infra starts running out of space, and i'm sure they can let us know when that's about to happen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKFKVkACgkQ2ugaI38ACPD7GgD+O0Of0R0BeOmGmKNKHwaLt/Oh 63xVewB5tQKdTeqn7dIBAKZgrPu2ScMfPSyOgSQNXpveUGWntsin3HqOifGLCTvQ =o4tM -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Package removal without proper last-riting
On Thu, Nov 14, 2013 at 3:08 AM, Ryan Hill wrote: > I wasn't aware last-riting had become general policy. It was originally > started by the treecleaner team to give people time to object to > maintainer-needed removals, and others thought it was a good idea, but it > was > always up to the discretion of the maintainer back then. > Last riting predates treecleaners by quite a bit. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, 14 Nov 2013 20:07:39 +0100 Thomas Sachau wrote: > - multilib-portage was planned to add features with a future EAPI > version, so in the end needs agreement from maintainers of package > managers, the pms team and the council. If anyone from those groups > only claims "you wrote so much, but i dont understand it, write > more", then it can be a very long time to get it into the main tree > (also this usually means it is well reviewed and tested) That's only a problem if you've got a horribly complicated feature where you can't remember yourself what you changed to make it work or how or why you implemented it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Rich Freeman schrieb: > On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer wrote: >> >> So just "fix it as problems appear and/or we have some spare time" ... > > Have any problems appeared that impact anybody who hasn't tried to > take advantage of the new multilib features (ie modified their config > files/etc)? > >> >> Well, you accidentally cut out all references to TommyD's work again. >> Almost as if you don't even want to discuss a working proper solution >> that just doesn't have the ego hammering it in ... > > We get it - there are two competing approaches to multilib... That's > perfectly fine - we can sort out which one works better once they both > work. It would be more of a concern if maintainers were being asked > to maintain things twice, but as far as I'm aware the developers of > each of the competing approaches have been doing most of the work > themselves. > > Of course, there could be issues I simply haven't heard of. There is a pretty big issue/difference here: - multilib-portage was planned to add features with a future EAPI version, so in the end needs agreement from maintainers of package managers, the pms team and the council. If anyone from those groups only claims "you wrote so much, but i dont understand it, write more", then it can be a very long time to get it into the main tree (also this usually means it is well reviewed and tested) - the new multilib eclasses dont need any ok from anyone, so they have been added instantly after first creation of a draft. So after addition (also they only support a subset of the things supported by multilib-portage) ebuilds are now converted to use them for multilib support. Noone will opt to revert/convert those changes once multilib-portage would be ready, so the eclasses win simply by the lower entrance barrier In the end multilib-portage will likely end as a portage-only feature allowing multilib-support on packages without the need to change ebuilds (it also has support for wrapping binaries per ABI, but this will hopefully at some point also go into the eclasses). -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Dnia 2013-11-14, o godz. 20:03:36 Patrick Lauer napisał(a): > On 11/14/2013 01:13 PM, Michał Górny wrote: > > https://wiki.gentoo.org/wiki/Multilib_porting_status > > > > That's the closest thing to a roadmap. > > So just "fix it as problems appear and/or we have some spare time" ... You could tell that. Or you could notice that this was specifically designed as an unobtrusive solution with possibility of gradual migration and backwards compatibility. > > So tell me, what you exactly want or need? Or is it just bare > > complaining for the sake of complaining? > > Well, you accidentally cut out all references to TommyD's work again. > Almost as if you don't even want to discuss a working proper solution > that just doesn't have the ego hammering it in ... 'Proper' is the keyword. The solution you mention has many issues that I listed more than once, and is far from unobtrusive, clear or explicit. It's supposedly working, yes, but it is nowhere near production-ready. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot wrote: > I was particularly hit by this as maintainer of freetype, see bugs > 455070 and 459352 for some of the mess that could have been avoided. Looks like 455070 was the source of problems there (the other is just a tracker with the aftermath). The package had no maintainer at the time, only a herd (per cvs). There was a request in the bug for whether it was suitable to deploy to production. Somebody associated with the herd gave a thumbs-up, apparently (I can only say that based on your comment - I have no idea how that was communicated). Then something went wrong. Since it caused problems, it was masked. Those who run ~arch should be thanked for saving the stable users from potential breakage! I'm not sure what should have been done differently. If the package maintainer (in this case a herd) says that something is good to go, why would anybody assume that it wasn't? You suggested testing in an overlay 20 days earlier, but you weren't in any particularly privileged position at the time (you were presumably just another maintainer of the herd). I'm not pointing fingers here. This was apparently a miscommunication, and part of the cause was a failure to document that there was a primary maintainer of the package (something which was subsequently corrected). Michał did offer to just maintain the status quo on that package instead of migrating it, and apparently he thought he had the all-clear to migrate it anyway. Michał did add the multilib project as a co-maintainer, taking responsibility for dealing with the multilib-related issues long-term. In my mind this is the sort of things projects should do. I'm sure there were other issues, but issues will happen when projects make changes. That's just the way things roll around here. If Michał just committed a change to a package without conferring with the maintainer at all or giving significant notice, I'd feel differently. I think we just need to learn and move forward, and from the looks of things we have. Gentoo always has been a fairly "disruptive" distro, though it has settled down of late. I don't think we're erring on the side of breaking systems too often right now, though I'm always for preventing that as long as it doesn't require ossification. (Just a note - this is all based on what I could piece together from cvs and bugzilla. I'm sure those who were personally involved could contribute more detail. I'm not sure it is necessary that do so, but I'll gladly defer to those with firsthand knowledge.) >> In the end, stuff only >> gets done if people write code. Your power in any FOSS project really >> comes down to your ability to write code or convince others to write >> code on your behalf. > No, it's more about your ability to commit and get away with it. So, I'm 100% for what Donnie said and in general I tend to lean towards saying "thanks, but no thanks" when a heavy contributor is driving everybody nuts. However, the reality is that those who commit more also tend to be allowed to get away with committing more. That's just human nature - we all like our free toys and we're reluctant to take too much objection when we're slapped around a little by the guy who is giving us the free toys. There needs to be a balance, and from the sound of things Markos is looking to step in and adjust the balance if it gets out of line. Honestly, I just wish everybody would do what they can to make his job easier, and I say that without pointing my fingers in any direction. I think we have a really great thing going here... Rich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 14 November 2013 23:12, Rich Freeman wrote: > On Thu, Nov 14, 2013 at 7:57 AM, Ben de Groot wrote: >>> I said >> As it is always happy to point out, Council doesn't see itself as >> leadership, just as a supreme court of appeal, when everything else >> seems to have failed. It likes to get involved as little as possible. > > The last time I talked to Council she said that she doesn't like it > when you anthropomorphize her. > > Certainly I stated in my manifesto that I believe that Council members > SHOULD be leaders, and should not limit their leadership of the distro > to casting votes. That's why we're chatting on a list, and I'm not > sitting back waiting for you to put this issue on a Council agenda. That is nice of you, but many of your fellow councilmen (historically, as well as currently) do not hold similar views, as was made painfully clear to me a few years ago. >>> We >>> also have Comrel, which is a better starting point for cases >>> concerning individuals vs policies. >> >> This also displays little real leadership. It concerns itself with >> conflict resolution, with various degrees of success. (I still have a >> bad taste in my mouth from my past dealings with that institution.) > > Well, that is the role of Comrel. I don't expect it to decide whether > developers can touch each other's ebuilds to add systemd units to > them, etc. However, if the Council establishes a policy then Comrel > should certainly take issue with devs that ignore that policy. Comrel > certainly can show leadership when it comes to how it operates, > facilitating better relations in the community in general, etc. > >> >> The costs are higher than the benefits, in my opinion. Where are the >> use cases for this high-cost solution that is being pushed upon us? > > Where are the costs for this high-cost solution that you purport the > existence of? Just what about this solution is difficult to maintain? > I keep hearing that it is painful, but I haven't seen specific > examples of HOW it is painful. See how much effort is expended on this, and how many maintainers are being involved: https://bugs.gentoo.org/buglist.cgi?quicksearch=ALL+multilib I was particularly hit by this as maintainer of freetype, see bugs 455070 and 459352 for some of the mess that could have been avoided. >>> The problem with having top-down leadership in a volunteer-based >>> organization is that it tends to drive away anybody who doesn't agree >>> with the leader. If a supreme leader said "mgorny has the right >>> solution to multilib - everybody is going to work to implement it" >>> that would probably cause more harm than good. Everybody wants a >>> supreme leader until the leader backs something they oppose. >> >> But what's the alternative? Having a few dozen self-appointed leaders >> doing whatever they want, and often taking things in opposing >> directions. It's not top-down leadership, but rule of the strongest. > > When you have officially-appointed leaders they usually tend to be the > same people who would otherwise be the self-appointed leaders. They > just have more power to kick everybody out who disagrees with them. > It is still the rule of the strongest. How did Linus become the > leader of Linux? He wrote it... At least there is one person in charge who sets a clear direction, and is accountable. > I used to get philosophical about things like this, but I think the > model Gentoo has is actually not a bad one. I guess we'll have to agree to disagree on this one then. > In the end, stuff only > gets done if people write code. Your power in any FOSS project really > comes down to your ability to write code or convince others to write > code on your behalf. No, it's more about your ability to commit and get away with it. > We can argue about what piece of software is > conceptually the best, but implemented software will almost always win > over the unimplemented competitor, unless the merits of the competitor > are such that people will flock behind it and actually implement it. > > Rich > -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, Nov 14, 2013 at 7:57 AM, Ben de Groot wrote: >> I said > As it is always happy to point out, Council doesn't see itself as > leadership, just as a supreme court of appeal, when everything else > seems to have failed. It likes to get involved as little as possible. The last time I talked to Council she said that she doesn't like it when you anthropomorphize her. Certainly I stated in my manifesto that I believe that Council members SHOULD be leaders, and should not limit their leadership of the distro to casting votes. That's why we're chatting on a list, and I'm not sitting back waiting for you to put this issue on a Council agenda. > >> We >> also have Comrel, which is a better starting point for cases >> concerning individuals vs policies. > > This also displays little real leadership. It concerns itself with > conflict resolution, with various degrees of success. (I still have a > bad taste in my mouth from my past dealings with that institution.) Well, that is the role of Comrel. I don't expect it to decide whether developers can touch each other's ebuilds to add systemd units to them, etc. However, if the Council establishes a policy then Comrel should certainly take issue with devs that ignore that policy. Comrel certainly can show leadership when it comes to how it operates, facilitating better relations in the community in general, etc. > > The costs are higher than the benefits, in my opinion. Where are the > use cases for this high-cost solution that is being pushed upon us? Where are the costs for this high-cost solution that you purport the existence of? Just what about this solution is difficult to maintain? I keep hearing that it is painful, but I haven't seen specific examples of HOW it is painful. >> The problem with having top-down leadership in a volunteer-based >> organization is that it tends to drive away anybody who doesn't agree >> with the leader. If a supreme leader said "mgorny has the right >> solution to multilib - everybody is going to work to implement it" >> that would probably cause more harm than good. Everybody wants a >> supreme leader until the leader backs something they oppose. > > But what's the alternative? Having a few dozen self-appointed leaders > doing whatever they want, and often taking things in opposing > directions. It's not top-down leadership, but rule of the strongest. When you have officially-appointed leaders they usually tend to be the same people who would otherwise be the self-appointed leaders. They just have more power to kick everybody out who disagrees with them. It is still the rule of the strongest. How did Linus become the leader of Linux? He wrote it... I used to get philosophical about things like this, but I think the model Gentoo has is actually not a bad one. In the end, stuff only gets done if people write code. Your power in any FOSS project really comes down to your ability to write code or convince others to write code on your behalf. We can argue about what piece of software is conceptually the best, but implemented software will almost always win over the unimplemented competitor, unless the merits of the competitor are such that people will flock behind it and actually implement it. Rich
Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors
On Thu, Nov 14, 2013 at 8:17 AM, Francesco R. wrote: > Rich, that made me smile, none of my remote machine has cvs since a > _very_ long time say 2006. > We are speaking of box that have troubles to emerging anything new, plus > me and most of the internet barely remember cvs up :) You don't need to run cvs on the box that you're trying to update. Just run it on a different box and create a tarball of the resulting tree. I couldn't tell you what the syntax for doing that is offhand, but I imagine that it wouldn't take you much longer than it would take me to read the manpage and figure it out. If you're really stuck I'm sure somebody would help you. > > I do highly appreciate the suggestion to keep a @system distfiles > snapshot (once a year + portage snapshot would be a bone), but that it's > not strictly needed, just a 40MB bzipped files on a public directory and > maybe some change to the cron that wipe old files. Personally I'd prefer to see a more standardized way of handling non-upstream distfiles as well (probably not a tarball). However, Gentoo really isn't one of those distros that is ever going to be easy to upgrade in-place if you only do it once a year or less often. There are ways to do it, but they're going to be painful. Rich
Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors
Am Wed, 13 Nov 2013 14:12:24 -0500 schrieb Rich Freeman : > On Wed, Nov 13, 2013 at 1:58 PM, Francesco R. > wrote: > > > > long story short > > having a portage-20130126.tar.bz2 snapshot (before the EAPI 5 > > switch) greatly simplified the upgrade of an old server on a client. > > > > Why not keep a copy on the servers? I mean > > http://distfiles.gentoo.org/snapshots/ > > > > Going back in time with portage is the easy part - it is in CVS. > > The real problem is all the distfiles themselves, especially things > like out-of-tree patch tarballs hosted by devs. IMHO not even the worst problems as long as devs stop removing files they consider as "deprecated" or "old". I keep everything in my dev-space I ever put in an ebuild that landed in our official portage tree. Of course this only works as long as you reference that place in the affected ebuilds. Once you go the route to use mirror://gentoo in ebuilds as SRC_URI people are screwed as soon as the ebuild vanishes from portage. I'd love to see this (mis-)behavior being more vigorously discouraged in Gentoo-land... Cheers -- Lars Wendler Gentoo package maintainer signature.asc Description: PGP signature
Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors
Il 13/11/2013 20:12, Rich Freeman ha scritto: > On Wed, Nov 13, 2013 at 1:58 PM, Francesco R. wrote: >> long story short >> having a portage-20130126.tar.bz2 snapshot (before the EAPI 5 switch) >> greatly simplified the upgrade of an old server on a client. >> >> Why not keep a copy on the servers? I mean >> http://distfiles.gentoo.org/snapshots/ >> > Going back in time with portage is the easy part - it is in CVS. > > The real problem is all the distfiles themselves, especially things > like out-of-tree patch tarballs hosted by devs. > > Rich Rich, that made me smile, none of my remote machine has cvs since a _very_ long time say 2006. We are speaking of box that have troubles to emerging anything new, plus me and most of the internet barely remember cvs up :) I do highly appreciate the suggestion to keep a @system distfiles snapshot (once a year + portage snapshot would be a bone), but that it's not strictly needed, just a 40MB bzipped files on a public directory and maybe some change to the cron that wipe old files. cheers, Francesco R.
Re: [gentoo-dev] keep a gen 2013 snapshot on mirrors
Il 14/11/2013 05:38, Johann Schmitz ha scritto: > >> long story short having a portage-20130126.tar.bz2 snapshot > >> (before the EAPI 5 switch) greatly simplified the upgrade of an > >> old server on a client. > > > Updating from old portage versions or > profiles isn't fun but it basically boils down to Sorry for the snip, but all you said is valid only if: you remember to update portage _before_ an emerge --sync _and_ you are able to do it. basically what I did was to remove the old snapshot find an old snapshot but recent enough to have EAPI5 portage. yes some wget of some distfiles was needed but it made the whole thing possible. Alternatively build a completely new system and then switch is a possibility, nothing deadly but as said a simple copy of a january snapshot would have made some paths simpler cheers, Francesco Riosa
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 14 November 2013 20:32, Rich Freeman wrote: > On Thu, Nov 14, 2013 at 7:21 AM, Ben de Groot wrote: >> On 14 November 2013 13:13, Michał Górny wrote: >>> >>> And how is it possible to discuss anything properly in Gentoo? >> >> That's because we have no proper leadership. We're an anarchistic >> collection of people working at cross-purposes at the best of times. >> There is no direction, and very little accountability. > > This seems to be an arrangement that everybody likes except when > somebody else does something differently than they would prefer... Seems, maybe. I for one do not like it at all, and I do bring that up from time to time. Others agree with me to various degrees. The problem is that it's so damn hard to change anything structurally in Gentoo. > We have a Council, and any issue can always be escalated there. As it is always happy to point out, Council doesn't see itself as leadership, just as a supreme court of appeal, when everything else seems to have failed. It likes to get involved as little as possible. > We > also have Comrel, which is a better starting point for cases > concerning individuals vs policies. This also displays little real leadership. It concerns itself with conflict resolution, with various degrees of success. (I still have a bad taste in my mouth from my past dealings with that institution.) > However, so far I haven't really seen any real indications of what the > concern is here. 32-bit software on amd64 has always been a kludge, > and if anything the latest multilib eclass seems to be less of a > kludge. I vehemently disagree. The emul-* packages may be a hack, but they work and cover the use cases we need. The new multilib eclass approach is much more intrusive in many packages, introduces new levels of complexity in ebuilds, with resulting new bugs and new behaviour that confuses users, and adding maintenance costs. It does this for very little gain. The great majority of our users doesn't need this functionality. The costs are higher than the benefits, in my opinion. Where are the use cases for this high-cost solution that is being pushed upon us? > Apparently some argue that there is a better solution being > worked on, and that's great to hear. What exactly is the problem? If > the eclass were breaking things that weren't already broken and having > a real impact on ordinary systems I'd consider that a concern. If you'd care to look at the history of bugs due to multilib eclass introduction in various packages, that's what you'd find. > The problem with having top-down leadership in a volunteer-based > organization is that it tends to drive away anybody who doesn't agree > with the leader. If a supreme leader said "mgorny has the right > solution to multilib - everybody is going to work to implement it" > that would probably cause more harm than good. Everybody wants a > supreme leader until the leader backs something they oppose. But what's the alternative? Having a few dozen self-appointed leaders doing whatever they want, and often taking things in opposing directions. It's not top-down leadership, but rule of the strongest. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, Nov 14, 2013 at 7:30 AM, Patrick Lauer wrote: > > Apart from me masking a few things because portage couldn't figure out a > way to a consistent state, and all that ... That is vague. It may be true, but it does nothing to help anybody understand what is going on. I haven't had to mask anything, which suggests that we're doing things differently. That isn't to say that you're doing things wrong, but it is hard to take complaints seriously when they're vague. > > I mean, not that we had lots of users in #gentoo WTFing all over the > place, or something. Oh wait, we did. Honestly, I wish that a news item went out before it was implemented. I'll agree that there was some end-user impact - I suddenly saw portage outputting requests to set ABI on a few packages due to dependency issues. However, when I followed portage's instructions as with any USE dependency issue everything "just worked." > > I have no idea how you think we can sort out anything with a pre-set > conclusion. What pre-set conclusion? Nobody said that you can't work on multilib in portage. Nobody said you couldn't put it in the tree either, but I would avoid namespace collision/etc unless done in a way that is compatible with the eclass-based solution. When we get to the point where we have two options I'd be all for making it possible for users to pick which one they want to use. > Apart from the maintainers that now have to figure out the funny bugs of > the in-tree work ... unlike a certain overlay. But I keep repeating > myself, which is redundantly redundant. I'll be the first to admit that I haven't seen these bugs, so I won't say they aren't severe. However, at least a few examples of the sorts of things that could go wrong wouldn't hurt. Again, this is vague. > So instead of figuring out bugs the proper way ... we let users hit > them? I feel tempted to use the letters "A" and "Q" together. > > Also, I could again redundantly point at a certain overlay. > > Oh well. I guess I should complain less and package.mask more to express > my feelings... Complaining isn't the problem. The issue is that complaints aren't helpful if they lack any detail or suggestions that are likely to be acted upon. Nobody is going to move the new eclass into an overlay, and it is unlikely that anybody is going to spend a year tweaking packages in an overlay just to find that they're all obsolete when it comes time to merge them into the main tree. Besides, it isn't like an overlay would get much testing on this scale anyway. Overlays are great places to work out issues on a small scale with a few packages if you have multiple developers involved. They don't really accomplish much when you scale up, because your overlay is always going to be out-of-date compared to the main tree. Honestly, I'm not trying to pick sides here. I just see complaints about very new features, and my sense is that if those features aren't working they should simply not be used. I don't think I have that variable set to anything but 64 on my stable amd64 system and I haven't seen any problems with it recently. If there are problems I'm certainly interested in hearing about them. Rich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, Nov 14, 2013 at 7:21 AM, Ben de Groot wrote: > On 14 November 2013 13:13, Michał Górny wrote: >> >> And how is it possible to discuss anything properly in Gentoo? > > That's because we have no proper leadership. We're an anarchistic > collection of people working at cross-purposes at the best of times. > There is no direction, and very little accountability. This seems to be an arrangement that everybody likes except when somebody else does something differently than they would prefer... We have a Council, and any issue can always be escalated there. We also have Comrel, which is a better starting point for cases concerning individuals vs policies. However, so far I haven't really seen any real indications of what the concern is here. 32-bit software on amd64 has always been a kludge, and if anything the latest multilib eclass seems to be less of a kludge. Apparently some argue that there is a better solution being worked on, and that's great to hear. What exactly is the problem? If the eclass were breaking things that weren't already broken and having a real impact on ordinary systems I'd consider that a concern. If it is just breaking things that never worked before then I'd just call it an experimental feature. The problem with having top-down leadership in a volunteer-based organization is that it tends to drive away anybody who doesn't agree with the leader. If a supreme leader said "mgorny has the right solution to multilib - everybody is going to work to implement it" that would probably cause more harm than good. Everybody wants a supreme leader until the leader backs something they oppose. Rich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 11/14/2013 08:13 PM, Rich Freeman wrote: > On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer wrote: >> >> So just "fix it as problems appear and/or we have some spare time" ... > > Have any problems appeared that impact anybody who hasn't tried to > take advantage of the new multilib features (ie modified their config > files/etc)? Apart from me masking a few things because portage couldn't figure out a way to a consistent state, and all that ... I mean, not that we had lots of users in #gentoo WTFing all over the place, or something. Oh wait, we did. >> >> Well, you accidentally cut out all references to TommyD's work again. >> Almost as if you don't even want to discuss a working proper solution >> that just doesn't have the ego hammering it in ... > > We get it - there are two competing approaches to multilib... That's > perfectly fine - we can sort out which one works better once they both > work. Given that one has been properly developed in an overlay, and one is now forcefully hammered into the main tree, it's a fait accompli. I have no idea how you think we can sort out anything with a pre-set conclusion. > It would be more of a concern if maintainers were being asked > to maintain things twice, but as far as I'm aware the developers of > each of the competing approaches have been doing most of the work > themselves. Apart from the maintainers that now have to figure out the funny bugs of the in-tree work ... unlike a certain overlay. But I keep repeating myself, which is redundantly redundant. > > Of course, there could be issues I simply haven't heard of. > >> There's this thing called overlay ;) >> Once you have everything prepared commit it all masked. >> A few days later if there's no obvious bug reports unmask it and duck. > > I'm not sure an overlay is a good solution for a tree-wide change that > will take months to roll out. It is great for testing the core > features with a small testing group, but the implementation is always > going to have to hit the whole tree and all its consumers with little > formal testing at that scale. So instead of figuring out bugs the proper way ... we let users hit them? I feel tempted to use the letters "A" and "Q" together. Also, I could again redundantly point at a certain overlay. Oh well. I guess I should complain less and package.mask more to express my feelings... Have a nice day, Patrick
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 14 November 2013 13:13, Michał Górny wrote:
> Dnia 2013-11-14, o godz. 07:49:55
> Patrick Lauer napisał(a):
>
>> On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
>>
>> > It's also worth pointing out that the whole reason why abi_x86_32 is
>> > {package.,}use.stable.masked is because trying to manage the partial
>> > transisition between emul-* and multilib-build dependencies
>>
>> ^^
>>
>> Why is there a partial random transition with no roadmap, no coordination?
>
> https://wiki.gentoo.org/wiki/Multilib_porting_status
>
> That's the closest thing to a roadmap.
Closest thing, yeah. But it doesn't really solve the problem. It's
basically a one-man show, but affecting a large part of the tree,
going ahead like a steam roller that can't be stopped, never mind the
road kill.
>> Well, discussing it properly would also maybe have been a good idea, but
>> since this is now getting unilaterally hammered in it's mostly about
>> damage limitation now ...
>
> And how is it possible to discuss anything properly in Gentoo?
That's because we have no proper leadership. We're an anarchistic
collection of people working at cross-purposes at the best of times.
There is no direction, and very little accountability.
--
Cheers,
Ben | yngwin
Gentoo developer
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, Nov 14, 2013 at 7:03 AM, Patrick Lauer wrote: > > So just "fix it as problems appear and/or we have some spare time" ... Have any problems appeared that impact anybody who hasn't tried to take advantage of the new multilib features (ie modified their config files/etc)? > > Well, you accidentally cut out all references to TommyD's work again. > Almost as if you don't even want to discuss a working proper solution > that just doesn't have the ego hammering it in ... We get it - there are two competing approaches to multilib... That's perfectly fine - we can sort out which one works better once they both work. It would be more of a concern if maintainers were being asked to maintain things twice, but as far as I'm aware the developers of each of the competing approaches have been doing most of the work themselves. Of course, there could be issues I simply haven't heard of. > There's this thing called overlay ;) > Once you have everything prepared commit it all masked. > A few days later if there's no obvious bug reports unmask it and duck. I'm not sure an overlay is a good solution for a tree-wide change that will take months to roll out. It is great for testing the core features with a small testing group, but the implementation is always going to have to hit the whole tree and all its consumers with little formal testing at that scale. I guess my main question is what exactly is broken? I haven't heard of any large-scale problems with the new multilib rollout. I'm sure if I went looking for bugs I'd find them, but that's pretty much par-for-the-course for Gentoo. If I go install the latest gcc the day after it gets added to the tree and enable some new flag that was just introduced I'm going to find lots of packages that break. That doesn't mean that the new GCC wasn't ready for the tree - just that I went looking for trouble, found it, and now I have the opportunity to help out by filing bugs if what I actually did was reasonable. Rich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 11/14/2013 01:13 PM, Michał Górny wrote:
> Dnia 2013-11-14, o godz. 07:49:55
> Patrick Lauer napisał(a):
>
>> On 11/13/2013 11:02 PM, Ian Stakenvicius wrote:
>>
>>> It's also worth pointing out that the whole reason why abi_x86_32 is
>>> {package.,}use.stable.masked is because trying to manage the partial
>>> transisition between emul-* and multilib-build dependencies
>>
>> ^^
>>
>> Why is there a partial random transition with no roadmap, no coordination?
>
> https://wiki.gentoo.org/wiki/Multilib_porting_status
>
> That's the closest thing to a roadmap.
So just "fix it as problems appear and/or we have some spare time" ...
> So tell me, what you exactly want or need? Or is it just bare
> complaining for the sake of complaining?
Well, you accidentally cut out all references to TommyD's work again.
Almost as if you don't even want to discuss a working proper solution
that just doesn't have the ego hammering it in ...
>> A more clean way would have been to target each of the emul-x86
>> libraries, replace one completely with multilib-enabled libraries, fix
>> all consumers, *then* unmask that whole shebang at once.
>
> We tried that. But in the end, it ended up masking new versions
> of a whole lot of libraries waiting for remaining maintainers'
> approval. And the maintainers that opposed the idea now complained that
> it caused the packages to be masked long...
There's this thing called overlay ;)
Once you have everything prepared commit it all masked.
A few days later if there's no obvious bug reports unmask it and duck.
> Feel free to convert all libraries, fix all consumers etc. We couldn't
> achieve that with our manpower.
So you just do it half-donkey'ed. Sigh.
Maybe ... you shouldn't do it if you can't properly finish it?
I mean, not like you cause a trail of destruction like the python-exec
fun, and such things ... maybe ... maybe ... you need to slow down and
plan more, and do your experiments in overlays.
Have fun,
Patrick
