Re: [gentoo-user] Re: Gentoo's future directtion ?
Alan Mackenzie: So that instead of conceptualising a branch (as you would do with Mercurial, Bazaar, Subversion, or even CVS), you need to think about commits reachable from a certain head (excluding commits reachable from some other head). [snipping everything that is not technical] How exactly is that a disadvantage? You are just complaining about the way a concept is presented without saying what actual limitations that implies (if any). If you like mercurial better, use that. Speaking about disadvantages however requires a bit more than I like that way better.
Re: [gentoo-user] Re: Gentoo's future directtion ?
Martin Vaeth: hasufell hasuf...@gentoo.org wrote: With rsync I believe you can exclude categories: http://www.gentoo-wiki.info/TIP_Exclude_categories_from_emerge_sync That is uninformed. I think he is right. check the --depth option of git. You can even clone specific tags with --depth=1. Every tag will still contain all categories: AFAIK, with git, it is not possible to update everyting but e.g. *access* *kde* *i10n* *gnome* if you know that you will never install an ebuild from these categories. My max DL rate is ~700KiB/s and is the limiting factor. # time git clone --depth=1 --branch=v3.1 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git real2m56.615s user0m5.802s sys 0m0.578s So the initial comment A good example of why I don't think they will be using git for portage: ``git clone https://git.kernel.org' doesn't make much sense, because it isn't the recommended way to clone the kernel tree.
Re: [gentoo-user] Re: Gentoo's future directtion ?
James: hasufell hasufell at gentoo.org writes: I still don't see a good argument why we made our system so inflexible, that obviously needed change needs such high amount of work, PR and proof. I think that most folks appreciate your efforts and insightful ideas on how to open up development, particularly in non-critical (non-core) areas. The quesiton is how do we get from where we are to where we want to be. I find most of what I'm interested in already in Arch Linux. I wonder why it is so much easier for Arch users to create pkgbuilds (like gentoo's ebuilds) and find a dev to adopt the package? Surely someone has some insight on this differences, or do I miss something that creats the difference? [1] I also find the Arch documentation to be of the finest quality of any and all linux distros, close to gentoo. ymmv. Arch has done it wrong, IMO. Sure, their PKGBUILDs are easier to write, but their quality is also worse. I know how to write them and have written and looked at a lot of them. People went the easy way and didn't really care much about review workflow, so they ended up with AUR where everyone can upload random stuff, including dangerous and wrong code. Trying to improve a tiny fraction about gentoo workflow (including your attempts) already took more than 4(?) years with never ending excuses. The necessity was more than obvious. Now I could talk about similarly obvious things. Sure, not all issues are obvious and those shouldn't be easy to push through. Everyone understands small changes and all changes take time for the majority of members to digest, imho. Not everyone has your keen insight into the problem/opportunity. So your patience in explanation, encouragement and solicitation, is very important, if your idea is to be implemented and tested. Naturally, Rich and other deeply involved devs, with addtional responsibilities exude caution, to keep the gentoo stable. They will not be the source of team building for your idea, imho. Gentoo isn't even particularly stable anymore. It's a mess to maintain with a confused PM, toolchain hackery and random conflicting ideas in one repository (e.g. multilib clashing with crossdev). The distro can only be as stable as the PM and the PM depends on the input. The input depends on quality ebuilds. Quality ebuilds depend on a proper spec, but there is no proper spec... PMS team itself says it started as a collection of ancient portage behavior and then grew with time, so there was no real design behind it. Quality ebuilds also depend on review-workflow. Review-workflow needs proper tools. We don't even have the last one. Long way to go. Good luck. You can draw your conclusions about this. I drew mine: small changes will not get us out of here. I think the jury is still out. So, why can't we test a transient plan where we take something very broken areas at Gentoo (games or java or sys-cluster) and test out your hypothesis for package development expansion? Already doing so https://github.com/hasufell/games-overlay and that's where I will update ebuilds, not in the tree. And I don't care to get any of that into the tree. In fact, I've been looking over quite a few ebuilds and pkgbuilds at (Arch linux). [2] I see quite a lot of commonality. So, why can we not modify this aforementioned inflexible system on gentoo to allow for Arch Linux pkgbuilds to be routinely compiled and installed on gentoo? Maybe limit the test to /usr/local/portage or /usr/local/portage/test/ so folks can participate or purge the experiment? Maybe find some Arch linux devs keen on the idea of developing/evolving package management so that the two distros can readiy (or more easily) convert packages between Arch and Gentoo? Is it possible? Could your plan be modified to include a variety of Arch developers? Surely you have a collection of devs ready to implement your keen ideas? I, for one realize something fundamental has to change with Gentoo, after pushing a few months on java and cluster codes Also, there is a vast array of software, of various quality, among the overlay repositories to use as test-packages? The biggest thing I seen wrong with Arch is they have forced systemd onto their users, and all of the arch users I know, are not very happy about that. So if you approach this correctly, I'm sure quite a few Arch linux folks would also test your offerings. Have fun, if you can. Always we should have fun. That is why we should deeply discuss these issues to find common ground. Maybe fixing this inflexible system should involve a survey of those distros closest to gentoo, for ideas, particulary several (structured) methods to install packages, provide choices for the init system, and strongly advocate package development within the ranks of the user base. Clear and concise documentation, concurrent with this effort is probably your single greatest alley, should your idea
Re: [gentoo-user] Gentoo's future directtion ?
Rich Freeman: There has been a desire for a long time to try to make it easier to contribute, but in the end people have to step up to make that happen. Those who are most passionate about it are of course the best candidates to try to drive change. That's a common misconception in gentoo. Someone has an idea and no one cares until he makes it happen. A lot of ideas are not so trivial that you can just make it happen. You need consensus, a shift of thinking, workflow and maybe even that people work TOGETHER on that idea. But no, you keep saying make it happen and by all means, start working on it, completely ignoring the nature of the issues brought up. I don't know of literally any big project except gentoo that still does not _require_ a review workflow. Git would be the perfect excuse to make it happen, but that's something people have to agree on. Instead we are worrying about stuff like repeated rebases, push conflicts, push rate etc... so we will just end up using it wrong. I don't think there is any hope left that this will become sane. A review workflow (e.g. with appropriate high-level tools and maybe paired with a distributed approach) will just make all your questions about how to contribute go away. But I'm sorry, this is probably too vague and I should instead go away and make it happen. Sometimes it is NOT enough to try to improve things. Sometimes you have to break with concepts. The last guy who tried to do that on a purely technical level was ferringb and he ragequitted for good. The only reason he could even come up with all those GLEPs (he wrote a LOT) was because he got paid by google. So, having 200+ core developers with push access is not just completely wrong from the workflow perspective... it also makes it nearly impossible to break with more fundamental concepts that are not appropriate anymore. So, to reiterate: if you want to change more fundamental concepts in gentoo, you need a job at google and be resistant to burn-out. And now you are telling me nothing is wrong with our contribution culture? lol.
Re: [gentoo-user] Gentoo's future directtion ?
I still don't see a good argument why we made our system so inflexible, that obviously needed change needs such high amount of work, PR and proof. Trying to improve gaming in gentoo took me 2 years full of work just to realize it is a dead end and I am doing most of the work alone. The necessity was obvious. Trying to improve a tiny fraction about gentoo workflow (including your attempts) already took more than 4(?) years with never ending excuses. The necessity was more than obvious. Now I could talk about similarly obvious things. Sure, not all issues are obvious and those shouldn't be easy to push through. You can draw your conclusions about this. I drew mine: small changes will not get us out of here. Have fun, if you can.
Re: [gentoo-user] Gentoo's future directtion ?
Paige Thompson: You know I don't think thats going to happen because if you look at layman its not as if they didn't think of using git for package trees; all of them do use git. A good example of why I don't think they will be using git for portage: ``git clone https://git.kernel.org' This takes a very long time and a lot of bandwidth and a lot of space. Why move data that isn't going to be used? With rsync I believe you can exclude categories: http://www.gentoo-wiki.info/TIP_Exclude_categories_from_emerge_sync That is uninformed. check the --depth option of git. You can even clone specific tags with --depth=1. Shallow clones are fully supported and you can push from them.
Re: [gentoo-user] Gentoo's future directtion ?
On 11/23/2014 12:20 AM, Rich Freeman wrote: On Sat, Nov 22, 2014 at 5:44 PM, hasufell hasuf...@gentoo.org wrote: On 11/22/2014 11:20 PM, Rich Freeman wrote: Nobody can block progress under the current model. If you feel otherwise, please point them out so that they can be dealt with. They can block progress and they do. And by saying we allow conflicting ideas in one repository we are even making it worse. The council is a workaround to make the broken project structure not look too bad. What do you do if somebody blocks progress in your overlay structure? You start another one. What do you do if somebody blocks progress in the current Gentoo project structure? You either ask the Council for help, or start another project. You have just as many options under the status quo, and actually more. Why would that be? We have a centralized _culture_. All this is basically about culture, not just about tools. So regrouping is not as easy as you make it sound. Totally not. I don't like ruby eclasses and their virtuals. What can I do? Fix them? No, I cannot. Stop saying I can fix everything I please. That is incorrect and our model makes it even more complicated, because all that stuff is part of the tree. You say I can fix the nethack bug? Well, I talked with various people on how to do that, the basic idea was to stop using the games eclass. That is NOT possible unless you suggest we break QA standards and cause major inconsistencies in our tree. (the other possible fix just slipped my radar and will probably happen soon) I strongly disagree. I know a fair amount of games overlays where people do work on games ebuilds. They just don't give a sh*t anymore to try to get that stuff into the main tree, because they were alienated long ago. Well, then by your argument there is nothing wrong, since they're already in the distributed model. There is nothing I can do about people feeling alienated. First of all they are not really in a properly designed distributed model as I described just because they run an overlay. Most of them end with ::mynick, are randomly themed and not reviewed. Again: this is a culture thing and we have to make ourselves some policies on how this can work well. Random overlay != distributed model. Second thing: sure can we do something about people feeling alienated. A lot. We can: * abandon CVS finally * have proper contribution channels (NOT bugzilla) * kickban major assholes from the community, no matter how efficient they are * kickban people from IRC channels that make fun of your first ebuild (that's my first experience with gentoo btw... that guy is now a gentoo dev as well) * have a _working_ comrel project * fix project internal communication... it's unbelievably bad * stop the way we are recruiting, it's utterly tedious * ... If you want to contribute to Gentoo, then do it. If somebody blocks your progress then ask for help. You don't understand. It's not just about blocking progress, it is about _diverging_ ideas that cannot sanely be given as alternatives in a SINGLE REPOSITORY. What I can't stand is people moping about their feelings being hurt from umpteen years ago. I can't go back and fix the past. Get over it - contribute or don't. This is rude. Please stick to the topic, it's not about my feelings. The image of the games team is so bad, that not even gentoo devs bother anymore (except me, uh). Yet neither the council, nor comrel has done anything radical, except giving recommendations, asking for them to elect a new lead, blah blah. The games team has ZERO power over any dev doing anything to any package in the tree. That was the outcome of the most recent Council decision. We didn't disband the team because we thought that having a team focused on games wasn't a bad idea, but so far nobody else seems all that interested so it seems as likely as not that there won't be a games team in the future. How is that not doing something radical? What more do you want us to do? Again: there are various people who have a different concepts of how games in gentoo should look like. So we can either start breaking tree consistency (and I hope QA will kickban us for doing so, because that's exactly their job) or we just stop doing everything centralized and let things happen... which concept is the most popular one will then turn out by itself! That's how opensource works. Writing stuff modular, so that people don't have to fork the kernel, just because they don't like the icon theme. It's not about elitist old-timers, it's about a more dynamic model that has low tolerance for * bugs being open since 8+ years, because no one bothers to review/change stuff (check nethack bug) * territorial behaviour * slacking devs slacking so hard, but not stepping down The reason the nethack bug is still open is because nobody cares enough to fix it. ANYBODY can make themselves a maintainer of Nethack right
Re: [gentoo-user] Gentoo's future directtion ?
On 11/24/2014 12:24 AM, Rich Freeman wrote: So regrouping is not as easy as you make it sound. Totally not. I don't like ruby eclasses and their virtuals. What can I do? Fix them? No, I cannot. Stop saying I can fix everything I please. That is incorrect and our model makes it even more complicated, because all that stuff is part of the tree. What would you do under your proposal? You'd start a new repository with your own set of ruby packages. What would you do under the current state? You'd fork the ruby eclass and all the ruby packages. Yes, you're allowed to do that. The thing that keeps you from doing it is the same thing that will keep you from starting a new ruby repository - it is a lot of work. No, I am not doing it because I think it is utterly wrong to introduce two competing concepts in one repository, _especially_ on eclass level. That's bad for QA, bad for consistency and bad for the user. It's a completely different thing for a package like udev and totally unrelated... those are forked UPSTREAM. You say I can fix the nethack bug? Well, I talked with various people on how to do that, the basic idea was to stop using the games eclass. That is NOT possible unless you suggest we break QA standards and cause major inconsistencies in our tree. (the other possible fix just slipped my radar and will probably happen soon) Just stop using the eclass. Cite the QA standards that this would violate. The council ruled a month ago that games are free to use the eclass or not as they wish. As long as you actually commit to maintaining the Nethack package, you can do this. As above: I think it's wrong. Again: this is a culture thing and we have to make ourselves some policies on how this can work well. The policies ALREADY allow you to do all this stuff. What policy specifically needs to be changed? * abandon CVS finally Already underway. * have proper contribution channels (NOT bugzilla) By all means create it. Lots of us are interested in this. * kickban major assholes from the community, no matter how efficient they are Proposals welcome. Hint, things will go much better if you volunteer to do the work the assholes are doing... It isn't like we aren't all tired of this stuff, but if we go booting half the devs then the distro will basically die. * kickban people from IRC channels that make fun of your first ebuild (that's my first experience with gentoo btw... that guy is now a gentoo dev as well) Flag down a mod when this happens. If you can't find any, then volunteer to be a mod. IRC is a realtime medium, so it is very manpower-intensive. * have a _working_ comrel project Again, proposals welcome. Half the problem with comrel is that everybody gets so sick of all the second-guessing that they give up. People would rather work on stuff that is interesting and not deal with infighting. When we tried to institute the proctors we managed to drive them away in a day. Everybody wants a working comrel, which generally means they want to get rid of all the people they don't like, and not have any restrictions on their own behavior. * fix project internal communication... it's unbelievably bad What is wrong with it, specifically? * stop the way we are recruiting, it's utterly tedious Well, then don't participate in it. By all means offer improvements. I have offered one right now, including * changes to the project structure (shrinking the amount of devs, concentrating on the core, base-system, toolchain, PM) * changes to the culture (REVIEWS, not random push access) * changes to the policies (themes overlays, how to split overlay etc) * changes to the tools (pointed out some specific things that are already implemented in paludis) I feel like I am repeating myself over and over again. It's not just about then work on it if it's a cultural, organizational and technical change at once. The first step is NOT randomly implementing or changing things. The first step is to discuss, find people who think similar and see if this is even a thing we CAN move to. Everything else (like improving our overlay tools) is really minor compared to that. Saying I can go working on that right away is just a polite/smart way to say shut up. You don't understand. It's not just about blocking progress, it is about _diverging_ ideas that cannot sanely be given as alternatives in a SINGLE REPOSITORY. What is the difference between 1 million repositories on 1 million rsync servers and 1 million subdirectories on 1 rsync server? Administratively there is a difference, of course, but in terms of capability there is actually no difference. They're just different namespaces. Then we should merge all upstream packages automatically into the CVS tree. What I can't stand is people moping about their feelings being hurt from umpteen years ago. I can't go back and fix the past. Get over it -
Re: [gentoo-user] Gentoo's future directtion ?
On 11/24/2014 12:24 AM, Rich Freeman wrote: * kickban major assholes from the community, no matter how efficient they are Proposals welcome. Hint, things will go much better if you volunteer to do the work the assholes are doing... It isn't like we aren't all tired of this stuff, but if we go booting half the devs then the distro will basically die. That's actually an argument FOR my proposal of being more distributed and shrinking the dev community. In such a scenario we would not need 200 gentoo developers anymore.
Re: [gentoo-user] Gentoo's future directtion ?
On 11/22/2014 07:12 PM, wirel...@tampabay.rr.com wrote: On 11/22/14 01:20, Rich Freeman wrote: On Fri, Nov 21, 2014 at 7:13 PM, wirel...@tampabay.rr.com wrote: On 11/21/14 17:10, Rich Freeman wrote: If you want to work on them, you might consider becoming a dev, or working on them in an overlay (which is a good way to become a dev, actually). Exactly, I agree. That is why the idea to have a small core of Gentoo elites (the chosen devs) and move everyone else into overlays, is a very bad idea. I don't see the argument here. It depends very much on what that actually means. You seem to be under the impression that Gentoo devs work on things that the Gentoo leadership tells them to work on. That is hardly the case, many of our most important packages are also the least maintained, because devs work on what they work on, and not on the stuff the leadership considers important. If a Gentoo developer wanted to work on Java the leadership wouldn't interfere with that just as they didn't interfere with a couple of devs deciding to fork udev. Rich Not really. I think you misss my points and intentions exactly. Java is critical and growing. Folks are constantly knocking on the gentoo door with technologies, that are java centric. Here is the latest one, just posted to gentoo-dev: https://wiki.gentoo.org/wiki/Project:Android I tried to participate with the java herd/project. Few have the authority to close old java bugs. The few that do, are apathetic, absent or just do not 'give a shit'. I was told to go work on java bugs, maybe somebody will notice. Really. The first 100 or so I looked at, are deprecated. They just need somebody to 'remove them' the BGO java backlog is being artificially used to prevent java work on gentoo. Somebody of authority needs to open up java for other folks to work on. Close the 100 oldest bugs is a no brainer and a good start, yet nobody will do that, and nobody else is allowed to close them. *CONVENIENT* if you hate java and are in control. If this is not true, the the council should open up java bug cleaning. Worst case scenario, these hundreds of old bugs will have to be re-filed, with updated data from this decade. (actually a very excellent idea in and of itself). This policy, whether part of a grand conspiracy, or due to apathetic leadership, has the net effect to run off potential new devs to gentoo and who like java. PS. sorry about forking to new threads, my access is now nntp (earlybird) and it just down not follow the thread correctly. Rich, I actually appreciate you help. But somebody of authority is going to have to step into this java on gentoo mess and clean house, provide leadership and encourage (hell, just remove the roadblocks) from java on gentoo. OK? Gentoo has a lot of organizational, technical and social problems. Some of them would just stop existing if we'd move to a more distributed model, because you'd be able to regroup more easily and work on the things you care about without stepping on each others toes. No one would care in such a distributed model if there is one person blocking progress somewhere. They would just move on, regroup around a new overlay and start working there and let that guy/project rot forever. Users would easily be able to pick up what the most community-driven and collaborative overlays are and would support those instead of some idle, stubborn or hard-to-work-with overlay maintainers. In that sense, there wouldn't be a single java ebuild in the core tree. That would totally be a community effort and you wouldn't have to vent that much here, but would be working on java ebuilds instead. Hell, you could even easily fork the WHOLE base-system and toolchain without forking the whole rest of the distro. We don't need more authority, we need less... and we need more actual opensource workflow. Our tools, our organizational model and our workflow are ALL ancient. And they don't seem to work very well, do they? Also see: https://wiki.gentoo.org/wiki/Distributed_Gentoo
Re: [gentoo-user] Gentoo's future directtion ?
On 11/22/2014 11:20 PM, Rich Freeman wrote: On Sat, Nov 22, 2014 at 1:54 PM, hasufell hasuf...@gentoo.org wrote: No one would care in such a distributed model if there is one person blocking progress somewhere. They would just move on, regroup around a new overlay and start working there and let that guy/project rot forever. Nobody can block progress under the current model. If you feel otherwise, please point them out so that they can be dealt with. They can block progress and they do. And by saying we allow conflicting ideas in one repository we are even making it worse. The council is a workaround to make the broken project structure not look too bad. We don't need more authority, we need less... and we need more actual opensource workflow. Our tools, our organizational model and our workflow are ALL ancient. And they don't seem to work very well, do they? Gentoo is already fairly non-authoritative where the main tree is concerned. I'm all for more overlay support, but I doubt it is going to fix the kinds of issues you're bringing up. The problem with java is that nobody wants to work on it. Lots of people want to talk about working on it, but nobody is writing ebuilds. The problem with games is that nobody wants to work on those either. Lots of people like to talk about the games project blocking progress, but now that this has been eliminated, there isn't some flood of new games ebuilds. I strongly disagree. I know a fair amount of games overlays where people do work on games ebuilds. They just don't give a sh*t anymore to try to get that stuff into the main tree, because they were alienated long ago. The image of the games team is so bad, that not even gentoo devs bother anymore (except me, uh). Yet neither the council, nor comrel has done anything radical, except giving recommendations, asking for them to elect a new lead, blah blah. In a distributed model this project would just have been abandoned by the community 8 years ago and people would have started a new fresh overlay. Currently this all sucks, because it will conflict with in-tree ebuilds and because we don't have good enough tools for this kind of model. People love to talk about elitist old-timers blocking progress, but it seems to me that many of the old-timers don't do a whole lot of anything. I think the complaint is really that other people aren't doing the work we want them to do. It's not about elitist old-timers, it's about a more dynamic model that has low tolerance for * bugs being open since 8+ years, because no one bothers to review/change stuff (check nethack bug) * territorial behaviour * slacking devs slacking so hard, but not stepping down In addition, this model requires a workflow that is long overdue, including proper VCS like git or mercurial and a review culture. None of this happens on a larger scale. Instead we are stuck with tools like bugzilla for ebuild reviews and push our happy ebuilds to the CVS repository. So now guess again why people don't bother, because: * have to become gentoo devs over a period of 6 months or so, then realize they are stuck with territorial crap, people ignoring each other and have to appeal to the council, comrel or whoever multiple times before something happens? * or they have to write bugs reports on bugzilla, attach ebuilds manually, get a partly review in a timeframe of 9 months if they are lucky, re-push attachments, start again * or they can try to contribute to sunrise which may be simirlarly slow (mind you, I've been a sunrise dev, so we can talk about that if you like) * or they just start their own overlay and stop caring to collaborate with gentoo devs * If they are very lucky, then their favorite project already uses an overlay-workflow (e.g. haskell, science). And those projects usually are so slow with moving their overlay ebuilds into the tree, that it's almost useless doing so. They should just stop and focus on their overlays.
Re: [gentoo-user] [OT] Linus Torvalds on systemd
On 09/21/2014 07:23 PM, Canek Peláez Valdés wrote: On Sun, Sep 21, 2014 at 7:45 AM, hasufell hasuf...@gentoo.org wrote: Canek Peláez Valdés: On Sat, Sep 20, 2014 at 8:46 AM, hasufell hasuf...@gentoo.org wrote: • There's still value in understanding the traditional UNIX do one thing and do it well model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at *some* level, but I think it's also clear that it doesn't really describe most of reality. He doesn't make an actual argument why useful abstraction cannot be done in complex systems. He doesn't need to; Sure he does. No, he does not, because the link I posted was not an argument, was an interview and he was asked for his opinion, and in no moment was he asked to justify his opinion. You, on the other hand, seem to be arguing. I don't know exactly with whom, because surely is not with me. Then please just refrain from answering if you don't understand how my point matters in terms of systemd development, thanks.
Re: [gentoo-user] [OT] Linus Torvalds on systemd
Canek Peláez Valdés: On Sat, Sep 20, 2014 at 8:46 AM, hasufell hasuf...@gentoo.org wrote: • There's still value in understanding the traditional UNIX do one thing and do it well model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at *some* level, but I think it's also clear that it doesn't really describe most of reality. He doesn't make an actual argument why useful abstraction cannot be done in complex systems. He doesn't need to; Sure he does. He made a statement that needs technical arguments (not stuff like people do it these days) and didn't even answer the reporters question. I think this is not a problem about complex systems, but rather about development models. But no wonder a C programmer in one of the highest commit rate projects in the world thinks like that. And it's probably even true in that CASE.
Re: [gentoo-user] [OT] Linus Torvalds on systemd
• There's still value in understanding the traditional UNIX do one thing and do it well model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at *some* level, but I think it's also clear that it doesn't really describe most of reality. He doesn't make an actual argument why useful abstraction cannot be done in complex systems.
Re: [gentoo-user] accidentally deleted the /usr (I'm gonna kill myself!)
behrouz khosravi: On Mon, Aug 25, 2014 at 3:57 AM, Volker Armin Hemmann volkerar...@googlemail.com wrote: and now you know why you should have added --buildpkg to your default emerge options. Yeah, I am happy that I did it. I really don't like to compile chromium or libreoffice again! Those methods are all not safe if you happen to randomly delete system folders by accident. The only relatively safe methods are rsync to a remote (or similar) or file system level backups like zfs has.
Re: [gentoo-user] Re: What MTA to use to receiving mail for local users?
Grant Edwards: On 2014-04-10, Peter Humphrey pe...@prh.myzen.co.uk wrote: On Thursday 10 Apr 2014 17:41:05 Volker Armin Hemmann wrote: well, IMHO postfix is pretty easy to setup up. While sendmail is a complete nightmare. I've just about got it set up here, so it can't be too hard. Eximqmail - never touched those. Are they even still maintained? According to http://bugs.exim.org, bugs were still being resolved 9 days ago (though the most recent bug _fix_ was 5 weeks ago). qmail hasn't been touched since 2007, so it seems to be abandoned. good to know it's still in stable arch... ugh
Re: [gentoo-user] Honeypot distro?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Gentoo. -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJTPS7RXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgEE4QAJwEDQaUdUbzIu1Yr+vN94qN fNlz9dydP7fEHhh+ohkxRMT1fP736KpSelmIMRqdV8PpF6Rw/MbsD55zGt5v3JVP 9S4Bx5bMizovtHreDv2RhPnsjQos5OV2tpaSnCU84OEbF5ojzI+e8nrOE6aGyJ6t gcXmOlyjlugxPjRxdkPC+IiAVe5KAoDpMZhdNJy+e34FtyZDiYPjGt+7bTwHNNvq rm8iZiq/vMksicXXw4zxGjQRcdLykkIZ2HN1rjl+7Q9o4K/rRId0UncLynybj7dc 3y04MvL5BZUE9uXKTNVgtrd7CJ1ARCq7n8ILqH4q74v4Jd0WSn0YnwOZzdQwEYGa erav+OwJ0KsHDsfSusD4by2nTx/halpnZo8Z8y3OjqROMBoSluV1I2WkxVS8L8b4 0lEz4lyuHBXFktNjyQyZzFSfz6zzyKVo3MgLi5xxj64V1XZPq3rIW9PYwt0NTlH3 ZkBtFZTMd5RRrBZzVcxugjE6V+XzQwK3lVKKL8Rz9yhXH52ReBxlMI2WxL1UXYiL zGsxc2abSWgROy7oi+Dvtj9E5carM7r/gNm/mZSQL/zlGUzyqNDAv33/5mBToAPW EoQx35iXyAILmPJEZ2a+NHc+OGRH9bwXY03XDCWrgUTR9KQq3v6z2xbCWpYBMnAC 6ssLl35I1YGtAdkSH1hv =kpA4 -END PGP SIGNATURE-
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Alan McKinnon: On 21/02/2014 16:15, hasufell wrote: Alan McKinnon: On 20/02/2014 22:41, Nicolas Sebrecht wrote: On Thu, Feb 20, 2014 at 08:52:07PM +0400, Andrew Savchenko wrote: And this point is one of the highest security benefits in real world: one have non-standard binaries, not available in the wild. Most exploits will fail on such binaries even if vulnerability is still there. While excluding few security issues by compiling less code is possible, believing that non-standard binaries (in the sense of compiled for with local compilation flags) gives more security is a dangerous dream. +1 non-standard binaries is really just a special form of security by obscurity. So you are saying compiling a minimal kernel to minimize exposure to subsystem bugs is only obscurity? (I really wonder what Greg would say to this) No, I'm saying that I pay RedHat large sums of money to look after this on my behalf and that money is wasted if I build a custom kernel on that machine. RedHat has a vested interest in doing this right (it's the product they sell) and they have more engineering resources to apply to the problem than I can ever raise. The odds favour RedHat often getting this right and me often getting it wrong, simply because I don't have the unit testing facilities required and my employer doesn't employ OS builders. I won't permit Gentoo to be used in production here for precisely that reason - I can't provide the test guarantees the business and shareholders demand. Yes, I agree that RedHat might be a better choice, if you can afford it (although there are some counter-arguments since they practically maintain kernel-forks because of heavy backporting, but I am unable to make a definite opinion on this). But that was not the point of my claims, so I don't see an argument. The argument that this particular setup may be less tested is a valid one. But less tested also means less commonly known exploits and testing these setups is a win-win for users and upstream. Whether you like it or not... whenever you install software on a server, you become a tester at the same point. Proper testing carries a onerous burden. I've yet to find a enterprise anywhere in the world that does it right outside of their core business. Instead, they pay someone else to do it. Yeah, the kernel has _zero_ proper testing in the sense of software engineering. RedHat does not really improve that (e.g. unit tests and whatnot). Greg said why that's almost impossible, especially because the internal API changes way too frequently. Still unable to find a real counter-argument. This was about disabling codepaths/subsystems, not about RedHat vs Gentoo which is quite an uneven fight. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTDgH2AAoJEFpvPKfnPDWzhZUIAIyT9nUPXYAOigXnb6M+OB4x /KmYDZ59Fyuz0D0SoMn1pZCNWPrS8UPjAOzUIr4E0DT0uzh0348+1xHDYDv4ph/n C9+0jqd9yPQ9kw5rX3zefmjC7wVpJFtLQIiOxaIo6wOqtxfjdVNZdVDEVKU/QJ7G n2fOdAccuTFOHCiB2cV8LlF997GfuzJ9nNdXGev3tA8l46wV9/q3gp1HdbkhyAJV 61QGv8blsPHbXsC8G2fnz/YcNaa0iH6rRcboRHcpMa2Gk1Ui8UrTmiYC/NJO02bN TSV8mb/VWow5vVyQSYmpCO4xcylQFVwwWOh14IXcl+mC+CQG4rxPTyUcDUhbewo= =2JhD -END PGP SIGNATURE-
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Nicolas Sebrecht: The 21/02/14, hasufell wrote: So you are saying compiling a minimal kernel to minimize exposure to subsystem bugs is only obscurity? (I really wonder what Greg would say to this) Developers made the kernel to rely on modules. Distributions relies on them. Since they are almost always loaded on demand, Gentoo does not make things better in this area, either. I wasn't only talking about modules and yes... loading them on demand actually proves my point. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTDgJIAAoJEFpvPKfnPDWz7a8IAKwtA+Ab7ETdaJ+nw0mGJcXg Cq1QLQLlXheDoqNLDP63lKgePx82nenT9HxWRovpao1lzhr/y8AU0ZFLJhYTxAAC sLc1Fbf2CHV1XqoPPwdJgK5AWI60jf2v5HTsCLNr57NK9VhpZGAwRvWf2M3DnOA+ VRrMnB0kzm4BolTvM1pVLvgx1CM2CSyRZBQjhd948aEUsCkVslNbb5Ad5/BYfA53 z+gxY7H+0r/an0xcc4LMdIHvE5ztCBhX+M5gkEhqNtI9IG7rXJTWmjQb69WA0ZYO UpPPUzd+dNmyfd2w/lQoZFirPLMtEbgrFuzvu8OJHfDs02oyH6oLJ4eGjx4bXwo= =fSvm -END PGP SIGNATURE-
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Nicolas Sebrecht: The 26/02/14, hasufell wrote: I wasn't only talking about modules and yes... loading them on demand actually proves my point. No. We are talking about servers. I am aware of that. Please read the whole discussion. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTDo9PAAoJEFpvPKfnPDWzbVYH/2O8ILmj6D2BmA+NUWwLxbMK hEyx7t+jZ1oVEnQAVjmnj4n4ylLKAH0qawl7fI2tBjfyXmw68pxItyqw0V3FdHl8 Zf6l/v7hVxTcJpMbF8Lk27BPMIBh8PpOm1A/A1G5eb3NGlMQht3zZa4QhUZkoU+U rVHXVFfSeKyzNYFiRIfdD/dsGXHfqj5Z2PKAqxrjRYo7EdLcHhrJJ/3X1MczOOcf n04vNbPSVCaer4WN5cqLG9bgJVnjVjhzF7bKwkjTjezwedEI969PCBHT0SZWN0mg 7vTEJzfykglcQ7PDJ/PPRgt8gwoFQCU1U7x/NAaANOQfoiCTHoffpwtVOf7XyUQ= =LwNB -END PGP SIGNATURE-
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Alan McKinnon: On 20/02/2014 22:41, Nicolas Sebrecht wrote: On Thu, Feb 20, 2014 at 08:52:07PM +0400, Andrew Savchenko wrote: And this point is one of the highest security benefits in real world: one have non-standard binaries, not available in the wild. Most exploits will fail on such binaries even if vulnerability is still there. While excluding few security issues by compiling less code is possible, believing that non-standard binaries (in the sense of compiled for with local compilation flags) gives more security is a dangerous dream. +1 non-standard binaries is really just a special form of security by obscurity. So you are saying compiling a minimal kernel to minimize exposure to subsystem bugs is only obscurity? (I really wonder what Greg would say to this) The argument that this particular setup may be less tested is a valid one. But less tested also means less commonly known exploits and testing these setups is a win-win for users and upstream. Whether you like it or not... whenever you install software on a server, you become a tester at the same point. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTB19lAAoJEFpvPKfnPDWzxR0H/1sz9v/yvAS/EvdCUgo6MBYW 0+A1yJPNfDK3eNMtcipcfBLIs2PbxjamtXKI/Ysjbog3oJxrt1cczDlLByGgG2kW PM0buUKsId6eLM/X3X9UJ06ZCVIK4JN4Baf9OAaBdJrquwL1Ja7rfzjTbC7vEOWj 9H0UqHuVL6qgvUvyVodMJWVXjc8Deda5w+Z9bWAbeBncf/pDukOO0JWr/6/wUsNe fhdcDqijB+qZ3auHA7YYwpwIYTBIGdlHRUwqm9zVDbSnOQm79FLE/3+dsaAjTqv/ NmXvsAmggHb1Q6FpMwZmaXHCtTMN67zWRaE+Oi36p7p7gZK/1DyW8lwgqBsq5/M= =ZQID -END PGP SIGNATURE-
Re: OT: 'profit motive' - WAS Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Tanstaafl: On 2014-02-21 10:28 AM, Gevisz gev...@gmail.com wrote: On Fri, 21 Feb 2014 09:03:47 -0500 Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-21 8:54 AM, Daniel Campbell li...@sporkbox.us wrote: If you think all profit is the same, then we are talking on two different wavelengths. I didn't say that. I said that *everyone* operates under the profit motive. And that is simply not true. Yes, it is, but you may be confused about the meaning of 'profit'. Even someone who volunteers in the local soup kitchen feeding the homeless is doing so under the profit motive. The things is, the 'profit' involved (may) only involve(s) a 'warm fuzzy good feeling'. If you read my previous words, I said it wasn't always (though I think it is usually) some kind of 'financial' profit. You didn't say it, but it feels like you are talking about personal profit. If not, then your definition of profit is so broad, that it is almost meaningless. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTB32KAAoJEFpvPKfnPDWzvssIALcVgrXn/XGTx5ZmXJjuUpIq eN6m6pBQ8b8oO5ujZpx9/l2rMt5zNzwaLpHhF5UEZiZXEEqt9+NSOP62vEuGHn2y Xk5JUDNngIuQaz4geKJXs9YcyA2ZV1MFhZYaxDBOq4DZ4+j75e0FiHuh3jGHfr1+ qUkZWxyWAxoIGb3CUWTedgpr6HqzMJWycL8BDutItfp7dpCobGoY2DSRKX3iSH73 1jtfOx+Ec2QScAmy+fi7sVN9yp5sSSlM4YVmzS5nSw2zemsYVmfqhrTNdPAcy2QE k1xlalMzoIY2EGi68ThjRniXrAQoH2R7kfQsavFSVfratbjjuvdDHxa4sNnbjAE= =V8cT -END PGP SIGNATURE-
Re: OT: 'profit motive' - WAS Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Tanstaafl: On 2014-02-21 11:23 AM, hasufell hasuf...@gentoo.org wrote: Even someone who volunteers in the local soup kitchen feeding the homeless is doing so under the profit motive. The things is, the 'profit' involved (may) only involve(s) a 'warm fuzzy good feeling'. If you read my previous words, I said it wasn't always (though I think it is usually) some kind of 'financial' profit. You didn't say it, but it feels like you are talking about personal profit. If not, then your definition of profit is so broad, that it is almost meaningless. Not at all. The fact is, there are many different ways someone can 'profit'. Another fact is, there has been a concerted effort by some people to poison the meaning, twisting the meaning of financial profit into being something bad, as opposed to what it really is - a very *good* thing (it is a good thing, without it you would DIE). http://dictionary.reference.com/browse/profit?sourceid=mozilla Take your pick... they are all valid with respect to my comments, although the one that subtley attempts to create a negative meaning 'to take advantage: to profit from the WEAKNESS of others' bugs me no end... People can engage in good (ethical, honest, etc) or bad (unethical, dishonest, etc) behavior in their pursuit of profit, but it is the *behavior* (ethical/honest or unethical/dishonest) that is good or bad, not the result (profit). Then you ignore self-destructive behaviour which is a common thing in this world. It can even be intentional, causing no emotional, financial, social or intellectual profit. Maybe you have never met such a person or have never been in such an environment. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTB4oUAAoJEFpvPKfnPDWzKwkH/jZMgmx20pvKBJBSHBzVgzYn GCEo4y6OVLKR4MkOMFPbgDh0OiPyLAGwj9A2QJmstTO2UN9LVwdkZLZIT1V4/kK9 3UGoxz5Q/vgLawnJxKesBmq0Qq1acwaEXojT/tngBpLStYvOcNU3Mq4kDlzAcOJ3 tDVoUpxV7fvsAjJZ7hd4LXVWN3vYC/8AYnAfO6K9Cb+VlGIkGDZ6bYDs0k8Wflxn jdEYdsh0k1Bbr5aDZGXRO9pZl7scLRr8SJha0DJwIhc5ZuazyXrX9R8SNw+QSjN8 NiGUIRWMjvwKuziFqRWCGyOJVpbyoaJkg1fxcOHlWvOyHHcOM9TSHHhhGL7Bg3E= =U4Qh -END PGP SIGNATURE-
Re: OT: 'profit motive' - WAS Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Tanstaafl: On 2014-02-21 12:17 PM, hasufell hasuf...@gentoo.org wrote: Then you ignore self-destructive behaviour which is a common thing in this world. It can even be intentional, causing no emotional, financial, social or intellectual profit. Maybe you have never met such a person or have never been in such an environment. You are confusing 'intent' with 'result'. No. You are confusing yourself with the rest of the world. Even self-destructive behavior is in the vast majority of cases engaged in with the *intention* of profit. Best example I can think of would be a drug addict/alcoholic. When they use/drink, they 'profit' in that the feel better (albeit temporarily), regardless of the ultimate result. I wasn't really talking about drug addicts. If you are interested in real self-destructive behaviour, talk to someone who has worked in an asylum which is only one interesting environment that can make you think very different about people. There are even people who are not driven by anything, not even self-destruction. Pure apathy. Another interesting thing... talk to a trial lawyer who has been in that business for 10+ years. I really doubt that many of those will support your profit intention concept. Most of the time it's about short-cut reactions that are merely following instincts or emotional impulses. Strong emotions can make someone lose control and do all sorts of weird things without any hope or intention of improving/gaining anything for living it out. It's chemistry, it changes your consciousness. Profit is a bit more complex and requires a minimum amount of reflection, even if it is subconscious, short sighted and follows false assumptions. So these are just 3 points why your generalization does not work, like most of those all people... phrases. Unless you hack on the definition until it suits your interpretation, like redefining profit intention to intention. This reminds me of the user in computer science papers. Well, which one. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTB6qKAAoJEFpvPKfnPDWzD5MH/3qVBSactWRWng+x1bT29eP/ Vsd3pSdP5GJ5JkH8Vj2LAhRJy9feRselI/TnZuXOOT+gTzAT+ip1fgqmIHTkaLEx Z1a4L5WXEQxTq9aSoaBFzxstont0zb6LWHfW+c8H+V6UTXPUv6ZdGqP+PlLMLpYO az0KiB09PMa/a3LOzPjhACQ6s1aRo5d4mUqOG91rxh3bOljt6WlMJ61ZEATQGwZt iZJff4sO0qG9p6YeoZED0ep6QvH4UGkfl3yboiVf08uf9mbGSTnOffe5GSJqeBKo 9uGK/tJJ4vkYqcEG60pZaqBuIguobzh84rwWg8DGs++Nv9dWbXi7Focpdse/OaU= =8l+x -END PGP SIGNATURE-
Re: OT: 'profit motive' - WAS Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Even self-destructive behavior is in the vast majority of cases engaged in with the *intention* of profit. Best example I can think of would be a drug addict/alcoholic. When they use/drink, they 'profit' in that the feel better (albeit temporarily), regardless of the ultimate result. I wasn't really talking about drug addicts. You said 'self-destructive', so I just used the best 'self-destructive' reference I could think of... It was not the best. If you are interested in real self-destructive behaviour, talk to someone who has worked in an asylum which is only one interesting environment that can make you think very different about people. Ok, well, I wasn't talking about the truly *insane*, and it is disingenuous to use them as any kind of example in comparison to 'the rest of us'... That is just one example and those are not few people. Ruling them out in your generalization is invalid and just proves that you are trolling. The rest of us is as well defined as your profit intention stuff. Meh. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTB/ZWAAoJEFpvPKfnPDWzO8UIAJHAVyQCrpMp/bW0yKbAnHSK yvW+15teMgbQZQdru34OYjXHpiLFgjnKF+OwGgOE8+vA908Kawc5Fme2aazYGtC1 gnqFlnnFkMiE37hNvGmef7Jpzl/q1UuZPJHDeh6m0kAJ0QjoxbANxNayQThd1QNX UrlJEpzOr6LwDrjkTnnwcwzNLymr9EB8NAehqd4B5/jsf0ZFoUo7Zn9DOhlv8olp PqdnjkVuIgrtVxhd6OBeQ3OVPsE7qyI5ZTfJUDYYef38WJ6PDj2Nc7jEblJKPsxS NWnZKfS/1w7oIUqnzwS36mKf+PhWrGqefJcIfE3E68DeW+2kxpZlvSCnFMM/sX4= =eRGW -END PGP SIGNATURE-
Re: [gentoo-user] Portage performance dropped considerably
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/30/2014 07:15 PM, Stroller wrote: On 30 Jan 2014, at 03:50 am, hasufell hasuf...@gentoo.org wrote: I just tried paludis again (after some time). ... * you cannot unmask USE flags at all, not without hackery... and that is really non-trivial for unmasking abi_x86_32 globally, because those masks are scattered across a lot of files in profiles/ The explanation from the paludis developer is simply wrong: http://paludis.exherbo.org/trac/ticket/817 WONTFIX: you can hack around it with your own profile if you need to deal with Gentoo not following its own policies correctly. Yes, that's the Ciaran McCreesh I remember. Stroller. The thread gets funny. I guess this is not so much about NIH, but rather about the fact that no one wants to work with him or that no one wants to be one of his users and gets his feature requests all RESOLVED WONTFIX. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS7AKzAAoJEFpvPKfnPDWzKAkIAKEIAx/4l690pHYvxvKkaypJ XWPs+LRokNboyzXyeZLEgWhEIJ5LzflBMgcnn0KRRn3p81JYaERQ+Cnx3yBtL148 7ovlZug12dxLO+nWVajrOWP3YWcHV12Kla6q7qTWrTO4RxZbfNEncyyMc4uMzCyk mQ13nBP7gooNdRx5pN61POKI23OPyK4Z/AnlJdMq6aForVuY788vOUZq8q/n96MU tdkx7npzJVJ/OGgwIF5AqIn1G1NmzmkQ3R8hKnPN/0W+l6jlChoocq+9tELTnJ/r UtXmVwdlsHCnG4rY+RxeVBIfLMi0f9xce1/ckENbLIiyoj5xMNkZ3/+6dyI/VhU= =FIJW -END PGP SIGNATURE-
Re: [gentoo-user] Re: Portage performance dropped considerably
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2014 02:06 PM, Alan McKinnon wrote: On 27/01/2014 13:59, Tanstaafl wrote: On 2014-01-26 1:04 PM, hasufell hasuf...@gentoo.org wrote: So, not sure where your optimism comes from. But... some devs are interested in starting from scratch or picking up pkgcore (which would be the most sane thing to do IMO). ? If the problem is really this potentially serious, why start from scratch, when Paludis is already very mature? Is it pure politics (someone just doesn't like Ciaran)? No-one likes to admit it, but I think there's some NIH going on I just tried paludis again (after some time). Things that make it currently impossible to properly migrate my portage config: * you cannot unmask USE flags at all, not without hackery... and that is really non-trivial for unmasking abi_x86_32 globally, because those masks are scattered across a lot of files in profiles/ The explanation from the paludis developer is simply wrong: http://paludis.exherbo.org/trac/ticket/817 * seems there is no equivalent to --dynamic-deps=y (which is default in emerge)... either I am missing something or this is a pretty good reason to not use it -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS6cwfAAoJEFpvPKfnPDWz+MoIAJvH9zDbsVQaRwyb+yMEowJ8 qXjaLmDTx5BFyyL7tSelFEYyNwh0DN1ypyOQu2VkScNOTNIbqfffWXsAPoe4GJrP pngtb9xo4H4/IIdtr7i8fwRU937UK5V4Fq0Er/e56SGpdHG3G+emxrBeuB2Y6n0M m+gdEI1xmSuB/YOd/byDc+t9qK1688qM23fHJd/SsW732FY9ooUlfSZuO39ltjpk 96ojLyGe4TAp5zkk2BNBbpLXyuAtszwsc8U5nPN89v87gbC7gH5pIrJDXbQkRfMF EP0ouZ6nfB4cDqFM1/GVvJ2+V24jleWkpV3UQmCPDAd18T6Qa/fkujz0JuijXAg= =FfQN -END PGP SIGNATURE-
Re: [gentoo-user] Re: Portage performance dropped considerably
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/28/2014 06:45 PM, Martin Vaeth wrote: hasufell hasuf...@gentoo.org wrote: Many defaults gentoo sets do not have anything to do with default codepaths upstream has tested. I disagree: The USE-enabling in ebuilds usually follows upstream. IIRC there was even a policy for gentoo developers which strongly suggested this. I don't know of any and I strongly disagree with that concept. As above, our defaults are not necessarily following upstream recommendations/defaults. Apache alone should make you think about that claim. I never installed apache. However, especially for packages for which the choice of algorithms has to be selected (USE-flags thread, jit) or of protocols/interfaces (openssl or gnutls, neon or other, sqlite or mysql, openvpn[lzo], qtgui[exceptions], mesa, freetype, wine), the installation of tools (utils, examples, tk, perl, python) or extensions (tls-heartbeat, introspection, X, readline) the defaults usually follow the upstream default or recommendation unless there is a severe reason not to. No, they don't necessarily. There is no consistency about this. It's up to the maintainer to decide what most users will want. You want upstream defaults, others want different things. The decision is made individually. And profiles totally mess up that concept anyway. What I was trying to say is: if you allow useflag combinations that break the package (both in terms of build, runtime or _unexpectedly_ missing features) or break reverse dependencies in those same ways, then it's a bug, a missing REQUIRED_USE constraint, a missing elog or whatever. The whole line of argumentation does not work out anyway, imo. Thinking that the defaults from e.g. ./configure --help are what a) developers have tested most thoroughly and b) users of other distros like debian, ubuntu etc run... is simply an assumption. Debian rather goes for enabling whatever they can enable. Besides that... I run stable arch. And when I have a package that has severely broken runtime behavior with many useflags disabled (except for the features I expect to be disabled), then something went horribly wrong during stabilization. If we support disabling all useflags on package level (and we do), then we support disabling all on global level as well. All _unexpected_ breakage that occurs due to that are ebuild bugs that have incorrect dependencies or missing REQUIRED_USE constraints. Defaults are just a usability thing, nothing more. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS5/H3AAoJEFpvPKfnPDWzGXEH/Aw68GvxkA98GoGfpYeD5jAB TEc6BE7BXX+SjToZZd2LGvyo0gpzocTwYf0Y2OMkVvlrft1a4LJVPX1pHK8NSPdv DIl7r+AosUcddBrSI45VuCC53sy66XxUDrsKnuXu1Qm9FlfIHhYTNcfxQM1v4UIx /IP3X+MzH+kklPnYqzHDwxY+lpS1JB3lCPbYvKoJLvk22s+F9ZMg2zdserWRnSRB EYKrw7ZbnornP71K7dQykQe0fh9f6d/s1fA56fvQ968Pfa1QIF/7eSd2270GF9Vq 5KTWATp8rThfo9O526+A4bwgceDFe04Ksbf6p1oOjxe6Hn4MIo020YFhVl7HQNg= =NMPh -END PGP SIGNATURE-
Re: [gentoo-user] Re: Portage performance dropped considerably
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2014 12:26 AM, William Hubbs wrote: On Sun, Jan 26, 2014 at 07:41:52PM +0100, hasufell wrote: Starting with USE=-* on a server (which is a sane thing to do) has become a lot more difficult as well. No, starting with USE=-* is very dangerous. It is not recommended nor supported, in any setup, by the dev community. If you do it, you are solely responsible for your system and you get to keep the broken pieces when things do not work. A safer approach would be to turn off the specific use flags you do not want to support. William That's nonsense imo and I use that setup on multiple servers/routers without any issues. It makes sense because you have the most minimal setup possible, the most minimal codepaths possible which reduces exposure to bugs. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS5kalAAoJEFpvPKfnPDWz/DcIAIZtMLZ907iMbqQs71Q2KGoY kKhUavNCg/PxsxnASyRVahf9LBAoJ2ZOya5/V8fcyf5RZEh5M9Jhc05qmEh5FIPU t7jTyRN1P0rCt3WLv/KMrIkszh/0iPWygu7BGio9KsdqxeUtsSdrQ4ylmjiJKyCJ mszFnLmG57ovL/Uv4YB/QWyhRBbxf9Be1Vvv1XLHEKouJNzWeuVBoQtECozYpfp+ tLt5HVm9skvk2pnjlAuiIODT3bVlY0sgXlzBaz0EVHTrnId/EUqsn0U8JpVqOw05 HXRNt2GZtJBJuU6J/q9whvLt/oHl7yZsbilS9LbuWydO5ooAywO27qtuR24OVXc= =L7hT -END PGP SIGNATURE-
Re: [gentoo-user] Re: Portage performance dropped considerably
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2014 02:06 PM, Alan McKinnon wrote: On 27/01/2014 13:59, Tanstaafl wrote: On 2014-01-26 1:04 PM, hasufell hasuf...@gentoo.org wrote: So, not sure where your optimism comes from. But... some devs are interested in starting from scratch or picking up pkgcore (which would be the most sane thing to do IMO). ? If the problem is really this potentially serious, why start from scratch, when Paludis is already very mature? Is it pure politics (someone just doesn't like Ciaran)? No-one likes to admit it, but I think there's some NIH going on If it's about performance (in the sense of speed), then paludis is worse, because dependency calculation is more complex/complete there. Debatable if that's really a problem, though. If it's about code quality... it's probably better, especially because it's not that old. But from a few looks at the code, it's not properly documented at class/method level (at least I could not find any comments). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS5mW2AAoJEFpvPKfnPDWzsTEH/jsxytMr2IQhNZcPdWhyNdu1 vCkiqV/kejjPtd9xDuRGMa6Adh3Jka1+I287J5ie61H+SU/4+mHYtkq9npohi9T8 YFgg8GsdrTfeC3o/d1qIBPHrKCAVs11D9IBYnFjNS4DkqM9chj8itnt7GTRWGZvx 0i5/nLQPq6fCW3nz9QzRfa6Mocx7m803ayWBpBSocr2xuIX8AsibG8YGTJzPLl64 IeZ31QPHJ5CqyIo5cidS2k4ZKnf0tEAJVoJUBWr412UHs+s2w1XaeyWPc1Faena7 L40VVjQp/jTjIz6GgMdbQrn/RGNe4rjxNQY2MuSezbqme8NDEtz1PnEZoQR1n9U= =L3AQ -END PGP SIGNATURE-
Re: [gentoo-user] Re: Portage performance dropped considerably
On 01/27/2014 10:48 PM, Neil Bothwick wrote: On Mon, 27 Jan 2014 14:57:10 +0100, hasufell wrote: If it's about performance (in the sense of speed), then paludis is worse, because dependency calculation is more complex/complete there. That makes no sense at all. Paludis is written in a different language using different algorithms. It's not about the amount of work it does so much as how efficiently it does it. That's exactly what I was saying. I was talking about speed, not efficiency.
Re: [gentoo-user] Re: Portage performance dropped considerably
On 01/27/2014 11:57 PM, Neil Bothwick wrote: On Mon, 27 Jan 2014 22:54:28 +0100, hasufell wrote: If it's about performance (in the sense of speed), then paludis is worse, because dependency calculation is more complex/complete there. That makes no sense at all. Paludis is written in a different language using different algorithms. It's not about the amount of work it does so much as how efficiently it does it. That's exactly what I was saying. I was talking about speed, not efficiency. But the efficiency of the algorithm, and the language, affects the speed. You can't presume it does more, therefore it takes longer if the two programs do things in very different ways. For people who are used to portage, paludis will be _slower_ in total, although the dependency calculation will be more accurate.
Re: [gentoo-user] Re: Portage performance dropped considerably
On 01/28/2014 02:34 AM, Martin Vaeth wrote: hasufell hasuf...@gentoo.org wrote: On 01/27/2014 12:26 AM, William Hubbs wrote: No, starting with USE=-* is very dangerous. That's nonsense imo No, William is completely right. and I use that setup on multiple servers/routers without any issues. No one doubts that it is *possible* to add the correct USE for every single package manually, but it is not a good idea to hide the recommended defaults. As someone who writes those recommendations, I disagree. That's why many of my packages don't have a lot of them, because I don't like them in the first place. Another nice thing you can do is mess with USE_ORDER. And now don't tell me that is another bad idea. This is Gentoo. It makes sense because you have the most minimal setup possible This is not true, to start with: For instance, USE=minimal will usually choose a more minimal setup. With -* you will actually *disable* the default USE=minimal for e.g. www-client/firefox, x11-apps/startx, sys-block/blocks, dev-db/unixODBC, ... and thus get a setup which is even larger than the recommended default. USE=-* minimal most minimal codepaths possible which reduces exposure to bugs. No, you usually get less tested (and by upstream considered untypical) codepaths which actually increases the probability to hit a bug nobody did hit/test yet. Many defaults gentoo sets do not have anything to do with default codepaths upstream has tested. So this argument works both ways. Especially after a profile is activated. The USE=-* approach was reasonable before EAPI=1 was introduced: In these days, unusual codepaths would have been set by negative USE-flags, e.g. IUSE=nocxx for gcc. Nowadays, the upstream-recommended codepaths are set by default-USE-Flags in the ebuild, i.e. now the same is called IUSE=+cxx in gcc. Using -* you disable such defaults which are usually there for a good reason. As above, our defaults are not necessarily following upstream recommendations/defaults. Apache alone should make you think about that claim. Of course, if you know and care what every single USE-flags for every single package does, it does not matter much which approach you take, but I would guess that even in this case you need more exceptions in /etc/portage/package.use with USE=-* than with USE=. I made the opposite experience. Moreover, even for updates, it happens occassionally that a package gets an additional USE-flag, whose default is then usually chosen in such a way as the behaviour was before - so you risk dropping crucial behaviour on updates if you are not very careful. I am careful. The amount of crucial packages on my servers are not that big and I definitely watch _any_ update, unless I want a mysql update to break hell. Besides, if a useflag combination breaks something unexpectedly (e.g. the build or unrelated features) then it's a bug (minimum is to communicate the situation via elog). If disabling one useflag breaks the whole package, then it's a bug. That's something the packager has to care about and arch testers usually run all(or most?) useflag permutations before stabilizing. There is no excuse. Every other breakage is expected, because I have disabled the features. The power of useflags imply that I can mix them up any way I want. All of those mixtures must be supported by the maintainer, unless he warns the user about it through the ebuild, masks the useflag or sets an appropriate REQUIRED_USE constraint. Otherwise... it's a bug.
Re: [gentoo-user] Portage performance dropped considerably
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/26/2014 03:35 PM, Nikos Chantziaras wrote: Anyone else noticed this yet? Some portage update seems to have made emerge -uDN @world perform about 10 times slower than before. It used to take seconds, now it takes about 4 minutes only to tell me that there's nothing to update. And it does that every time, even directly in succession and with the caches warm. Is it just me? Some people don't follow PMS when writing ebuilds which could be one reason. https://bugs.gentoo.org/show_bug.cgi?id=174407 https://bugs.gentoo.org/show_bug.cgi?id=487846 https://bugs.gentoo.org/show_bug.cgi?id=393203 https://bugs.gentoo.org/show_bug.cgi?id=486566 https://bugs.gentoo.org/show_bug.cgi?id=434246 https://bugs.gentoo.org/show_bug.cgi?id=311267 toolchain has closed all relevant bugs as WONTFIX so far and even QA does not seem to care enough (?), although there are alternative approaches to fix the lack of USE-dynamic SLOTS. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS5R9dAAoJEFpvPKfnPDWz6zkH/13KbO6s3d5GWe4yXJsL1C7G xOx24vTwWkeEqmi7+kUxR5Y3LUmZ0Pl4E9n//q5KcgVouKtalwFmqNaVsxQSLG9h VyRZgGNdvcvTYfdlch8VoiIhUiP+1ZaOsZFuHTOzzfw3qoc52LceJYSyV/lo/x/9 Qe6xT+TuTyUzRJunBFTEzsool8hEhu1UWPYfmjTbZ94wRgSuu68yuL/7hIr75sin cjEWo25MGzXzf8IhgfM+nI37gurPX136aLuc+JGLTUnYqN9SC1Ad2wjtvHqWJ54O /kfVlL0790v+l2HyV8CfBs3Z3LktaE7EOgEJBzogHhuO1tjDaoERYDGoE+30pK4= =tCmP -END PGP SIGNATURE-
Re: [gentoo-user] Portage performance dropped considerably
On 01/26/2014 05:06 PM, Florian Philipp wrote: Downsides: - emerging pypy takes forever and uses a lot of memory - userfetch and userpriv don't work It also regularly causes segfaults. zmedico/#gentoo-portage hasufell: yeah, I get random segfaults with pypy also (always seems to be in libc iirc)
Re: [gentoo-user] Re: Portage performance dropped considerably
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/26/2014 06:42 PM, Alan McKinnon wrote: On 26/01/2014 17:24, eroen wrote: On Sun, 26 Jan 2014 16:35:43 +0200, Nikos Chantziaras rea...@gmail.com wrote: Anyone else noticed this yet? Some portage update seems to have made emerge -uDN @world perform about 10 times slower than before. It used to take seconds, now it takes about 4 minutes only to tell me that there's nothing to update. And it does that every time, even directly in succession and with the caches warm. Is it just me? You don't say when your baseline was, but the complexity of resolving the package tree has increased quite a bit over the last year due to new features like automatic rebuilds of consumers after library updates. Another somewhat common cause of sudden slowdowns is how portage resolves conflicts (like packageA requiring an old version of libraryB), which is rather time-consuming. You can try adding --backtrack=0 to the emerge command to make it stop and print an error message when encountering a conflict rather than look for a solution. Then you can 'help' out by manually resolving any conflicts by adding package versions to /etc/portage/package.mask . Preferably try this *after* running an update, so your system is up-to-date against your local version of the gentoo tree, otherwise normal simple-to-resolve conflicts might cause confusion. ;-) I've been noticing these slowdowns for a few months now too. I'm somewhat conflicted in my head about them, as unresolved blockers is now something that happens very rarely. How often did we do this in the past: emerge -avuND world stare at output trying to figure out wtf? emerge -C some problem package emerge -avuND world emerge problem package back if world update didn't already do it That used to happen A LOT, and it took much longer than 4 minutes. Nowadays it happens seldom but the resolution does take 4 minutes. So I dunno, it's annoying to have to wait, but it also prevents a lot of wasted time by doing what software can do so well - detecting dependency issues. Dependency resolution is broken and incomplete. Portage is unable to print useful autounmask and similar messages to solve conflicts manually, is unable to solve circular deps at all and bails out on simple things like only updating vim when gvim is installed as well. Then we have dirty workarounds like PDEPEND which shouldn't be there in the first place... It's a miracle that it works at all, especially when people keep breaking the cache and rely on undefined behavior. Also... we still have binary files in the tree. Each EAPI adds more complexity to the dependency calculation. We have no performance regression tests. We don't have many people who want to look into portage code (can't blame them and since ferringb is gone we don't have any1 who works on the QA-side of the code). Afais, it will get a lot worse. So, not sure where your optimism comes from. But... some devs are interested in starting from scratch or picking up pkgcore (which would be the most sane thing to do IMO). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS5U40AAoJEFpvPKfnPDWziK0IAKwuPe4DOBvamSkhtYbipZOv CdCmt4qjlYn/NjLMkyb8I5AO1m3rziHKuFnfMAksFodTZx9HJ8rbXh1H75bGNt+i k1cJ4Z6eg9R6hHqsBXAdwBfl4eDouINYMs2Q2R85XFD2QdZKUE/8AcUU5s2YHkxR NraYC/1n2LxUaXwA8D66KNHKSR31Gb5ISd+Slt+kvAGpXjRDJCDRAWD/QChPkVUL 06RA6qjIhmAooWo3x5lcBjpGUsVkiPk15sF3E0t1qyjp78eiOq8cZBMRYxnhUVN+ AtQlESyzVmYjaCI557fsPr6sZasD69U9luZM6UUToeDSoK7O81s99MilhqUGpKA= =vPSH -END PGP SIGNATURE-
Re: [gentoo-user] Re: Portage performance dropped considerably
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/26/2014 07:30 PM, Alan McKinnon wrote: On 26/01/2014 20:04, hasufell wrote: So, not sure where your optimism comes from. It comes from watching what happens at the end of running emerge, don't read any more into it than that. Especially not optimism, I think you might be projecting your own frustrations. That might be true. Mixing stable and unstable has become more and more difficult these days. Starting with USE=-* on a server (which is a sane thing to do) has become a lot more difficult as well. A couple of years ago I used to have to manually resolve blockers about one world update in two. It started becoming a huge PITA especially as the deps are usually easy to solve - if I can look at the screen for a few seconds and figure it out, then software can do the same in milliseconds. Recent portages now do this properly when viewed from a results-only perspective. On my machines, that is what I see happening. That is the ONLY set of FACTS I have to work on; you may have more. I'm willing to give up 4 minutes while emerge runs so I don't have to spend many more minutes right afterwards doing manually the very shit that software is very good at. Whether portage is a complete pile of dogshit software or not is beside the point. Even if it is, my 4 minutes still buys me lots shrug My pessimism comes from the fact that I wasn't able to communicate to any1 in real life that gentoo and especially portage have a positive usability score. Especially to those who have tried it once. As someone who knows the internals and doesn't read portage messages about conflicts anymore, but digs into the ebuilds directly... I don't have a lot of severe problems to maintain any gentoo system. But it is sad that you need those skills. Usually I tell people to use a desktop profile, never to use autounmask, not to mix stable and unstable branch and not to play too much with per-package useflags unless you are really missing something. Portage does alienate new users a lot. These performance issues add to that. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS5VbwAAoJEFpvPKfnPDWz5NAH/i5viXuWexvbLgVRefuDWCFo gmLekzmBpEQqvozdxXac1VNFHPWmmY8KVTkTe+JbtgGblzHsiQOug6n47Mpga+dt tn7f60dLDrTBBpvahVADln9pha3OjtmKDI/JXGV1nZQbFFRBW0x01K6absoFYNs3 bdylCzcG5ZUOCKvBqVzpS8pKVeuBtrItadSOpJTDj6CQys2Q1RVQAl3aIIX96nAx IcN8eyBeuhQbjACKOfUSgIV/q8XwLdzUHLu//SxJ4psMKL5ne/EQaph9aRI+si2h bOP9MkKt/QTmj0dGSpbR5DJt6r0tlsmIa1ZIS/DnC7vbKvXVRESUn2tMDes9NEM= =Hl9N -END PGP SIGNATURE-
Re: [gentoo-user] Mini-XML license
On 01/25/2014 08:07 AM, Pavel Volkov wrote: Is Mini-XML license (/usr/portage/licenses/Mini-XML) considered a free license? If so, why is it not in @FREE group? I have @FREE in my ACCEPT_LICENSE= in make.conf. http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/license_groups?r1=1.227r2=1.228
Re: [gentoo-user] lxde +openbox updates
On 01/24/2014 10:46 PM, James wrote: Hello, Well, I took the plunge and put LXDE and openbox on a FX-8350 with 32 gig of ram. KDE was just too much of a pig and I got tired of spending hours and hours of researching what had changesymmv. So I'm lov'n LXDE _ openbox, although I do have to go out and parse the scant documentation available. So I'll just post what I want. I set up my desktop manually, just the way I like it. I basically have 2 problems. 1. All of the software I install, only a few things are picked up by openbox into the menu and submenus. Is there a simple app I can add and run to pick up all of those apps into the openbox menu? What I have read seems confusing, as there are menu files all over the user and /etc/xdg dir structures? Advise? I recommend x11-misc/obmenugen but there are others like x11-misc/openbox-menu as well 2. In the ~/.config/lxsessions/LXDE/autostart file, I have: @lxpanel --profile LXDE @pcmanfm --desktop --profile LXDE @xscreensaver -no-splash seamonkey thunderbird @lxterminal I have 4 differnt lxterminal sessions, each with 6 windows. I do not see how this single line lxtermial can remember all 4 window locations and the 6 tabs under each window; so how do I config this so ti all comes up on logout/login or and reboots? James You might want to have a look at x11-terms/terminator which lets you configure complex terminal profiles. also mind the applications settings in openbox rc.xml where you can define how and where new windows are placed
Re: [gentoo-user] Mounts NFS in XFCE4
On 01/19/2014 05:46 PM, Chris Stankevitz wrote: Hi, Is it possible to mount an NFS share from XFCE4? I suspect the answer might have something to do with gvfs or fuse, neither of which I know anything about. Ideally after emerging or USEing I will have a Connect to server entry in my XFCE4 menu. If this is impossible, then I'd be ok with an approach that will allow a regular user to mount any network share with the mount command. Thank you, Chris Yes, use x11-misc/spacefm as filemanager and emerge sys-apps/udevil for ftp/nfs/smb/ssh URL support for the path bar. Then enter nfs://server:/path/to/share in the path bar.
Re: [gentoo-user] ZFS on Linux (spl build error)
On 12/13/2013 06:48 PM, Michael Rühmann wrote: Am 13.12.2013 18:34, schrieb Michael Rühmann: Hi all, had some troubles to build sys-kernel/spl-0.6.2-r2. snip Emerging (4 of 6) sys-kernel/spl-0.6.2-r2 * spl-0.6.2.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...[ ok ] * spl-0.6.2-p1.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/3.10.17-gentoo/build * Found sources for kernel version: * 3.10.17-gentoo * Checking for suitable kernel configuration options... * CONFIG_ZLIB_DEFLATE:is not set when it should be. * Please check to make sure these options are set correctly. * Failure to do so may cause unexpected problems. * Once you have satisfied these options, please try merging * this package again. * ERROR: sys-kernel/spl-0.6.2-r2::gentoo failed (setup phase): * Incorrect kernel configuration options /snap The problem is now: How do i set CONFIG_ZLIB_DEFLATE in menuconfig? Maybe i'm completely blind... Thanks in advance for any help, Mosh lol, done! As i thought...i was blind :D You could at least say how you did it. *sigh* maybe even add the kernel part to https://wiki.gentoo.org/wiki/ZFS
Re: [gentoo-user] ZFS on Linux (spl build error)
On 12/13/2013 08:21 PM, Bruce Hill wrote: What *is* so difficult about that? Nothing.
[gentoo-user] [call-for-testing] media-gfx/blender-2.69
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As discussed in a previous thread I'm trying to involve users more in testing. Since I'm not sure about the platform yet I'll just post on the user-ML and wait for comments. https://bugs.gentoo.org/show_bug.cgi?id=492968 Primarily you should focus on runtime-issues. Arch teams usually catch build-time stuff reliably. So if you are already using blender... tell us how stable it is or if another version works better. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSmjeAAAoJEFpvPKfnPDWzyBwH/RoRpH5akF9pzQobpeKTaLUy vwi5bMmc2E4GL01XN/MqZJFRxCdJRhu4ikI50Oz73tIbdrNk3LoDOdxNlHzlAGo5 hEDnvethMSrccACAfDITg2gAvWqvXS12zj0Jvkcef2+AhyhEPeB86S6hu3xsNXGR 1wABoms+Stbo/5n+pst6T+zomzkp0NHdjxDvPr+GJj76bpVSPDoPqIUTjOH8i/Ck ErfDZCfTFEJqNTZlCTAPs4SAB+fGMS/OVB3MCBOavQLzdb3VBuc0chY5a62Msc5P mXbvCzN6C3N4Ivh2HRd0yeIgk4N7ROKwWEpjh7Fdzo+XLeqb0t1MSXGLukVlcvo= =gWBQ -END PGP SIGNATURE-
Re: [gentoo-user] Re: Can we get users more involved in specific testing?
On 11/14/2013 12:21 AM, James wrote: hasufell hasufell at gentoo.org writes: Our arch testers are understaffed and often don't really do general runtime tests (it's mostly assumed the maintainer knows about runtime issues). I have often had a hard time to get some random users comment on certain packages or even assist on some runtime tests. I don't even know how many people use the package I maintain. When a new package is installed or upgraded, there are notes that the installer is optioned (and notified upon installation) about the package. Might it be a good idea to put your testing pleadings in the notes for those how install the package (stable, testing, experimental or overlay) about how to contact whoever related to the specific testing you want done? I. E. eselect news or is this a bad idea? JFFNMS is one of my favorite packages, so surely I'd respond on that one. Hell, I often go and find the patches and post bugs pleading to get documented patches installed on my favorite package. hth, James I think people will not like having that in eselect news. There could be a similar thing like: eslect test-requests but the question is if that will get bloated and other stuff I'm not sure about. The easiest thing I can think of is a project site on our wiki which would also point to relevant bugs. Then again... who really wants to maintain that. All other ideas are even more advanced. I wonder if we could add a keyword on bugzie like REQUSERTEST... so bored users could easily get a list of such bugs. But who would really use that?
[gentoo-user] Can we get users more involved in specific testing?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Our arch testers are understaffed and often don't really do general runtime tests (it's mostly assumed the maintainer knows about runtime issues). I have often had a hard time to get some random users comment on certain packages or even assist on some runtime tests. I don't even know how many people use the package I maintain. This makes it very difficult on some decisions when to stabilize non-trivial stuff like media-gfx/blender or sci-visualization/paraview. I don't use those things on a daily basis. I'm wondering if it would make any sense to set up some kind of portal to track at least such delicate packages where we need users to comment on general stability and especially runtime issues. (actually the bug-tracker was meant for that, but it seems that doesn't work out for general user reports... those are very rare) So when any1 of you is really bored, he could chime in there, do some random testing (or maybe you already use it on a daily basis...) and report it. It wouldn't really need to be professional. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSf5pdAAoJEFpvPKfnPDWzyFwH/0lvhLwyupLPvT+7iSgbXuTK 1MsHNZRnWGYqBqOtkJqx6B5QN3dG+od7YlFm7Z3wgyB1RShw1OYGIzTwQhVCcTdP lwtHjgr2lD4ER7bYxvOeP7PVz+SYPGG1WO4N/ITktHUYoO/n7m0Mvtd8EnpDDQ30 T0YZn7333JvCxLwVJJLvp63FqUUkDmL4VKT5QHLvDhK8okgvXcIiSNUhvO17T2/7 mRi4K5NsOSHinnQt0ziUQxGYgq9StqM6aDcmzvHiV0g0NmegAGQEAcFnVVZWcYUI Rv8DThMzkbJhOFrFBCvJLOYdTGNTs9AdfQLSCtrd6O2rmUTlwiBl9jZntSUPPq0= =/S73 -END PGP SIGNATURE-
Re: [gentoo-user] Re: do subslots improve user-experience?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/2013 08:07 PM, Martin Vaeth wrote: If you want my opinion on subslots: # grep EMERGE_DEFAULT_OPTS /etc/portage/make.conf EMERGE_DEFAULT_OPTS=--ignore-built-slot-operator-deps=y A different user interface would be preferrable: Something like FEATURES=show-built-slot-operator-deps which would *show* what would need to be rebuilt even if the above EMERGE_DEFAULT_OPTS is used. This is then something which users with less powerful machines like me can put into their make.conf and then decide from case to case whether/when to rebuild. Or even better: In --ask mode, one could ask the user in addition for those packages only pulled in by subslot deps. This way users with not so powerful machines would be informed regularly but would not be forced to call emerge twice or more times just to get the information (which meanwhile is really a time issue). The current way of reemerging subslots by default might (and IMHO should) be kept, anyway. Could you open a bug report for portage and make a properly formulated proposal about this? I think this idea has a realistic chance to get implemented, one way or the other. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSdqKjAAoJEFpvPKfnPDWzQ/0IAJ+S1CyBxLfd6TxQeer1dP+K JZYTG/6CDVEegpyLzypTB5TqlQeyk4p2BKIdE28Cgm48GIMiDGn3IsZIgELlc85b iCztw1l6aCSLtAxA1ck4b2N9jHU6z91+QFXfs1XSJ8uGdb7jZJtR6THS9Clzl4NL JvMRX1Cr0ZPsmzNLG7U/jcQ+FAhygeV6N4GFifcPRXOk9hqdpDahLsqlZ91OENn+ uC6taKJIgjElBHkc/sITEaFqkcAFt3kX//WsQwjIANeEYYniSXe9ucNUWPg6Gf76 BGd5gNap0SA1D2b8VPGgEU12pLzUOB6V6ITcJZyTTVyTgm5QVvKn2RrHpcNXwsU= =2zBZ -END PGP SIGNATURE-
[gentoo-user] do subslots improve user-experience?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Another round of questioning the users here. more specifically: * how often do you experience useless rebuilds? * do you really have a problem with running revdep-rebuild/haskell-updater/perl-cleaner etc after every emerge? * do you think it's worth the effort to add more stuff to the PM, so that you don't have to run revdep-rebuild that often? * do you trust the other methods like subslots or preserved-rebuild to work reliably? (as in: do you still use revdep-rebuild?) If you want my opinion on subslots: # grep EMERGE_DEFAULT_OPTS /etc/portage/make.conf EMERGE_DEFAULT_OPTS=--ignore-built-slot-operator-deps=y -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSdOpkAAoJEFpvPKfnPDWzJv4IAJXrLhHVJwsc4e1rqsKeA8MP 4NWYVPLlWpcCBibd4bH6T+nIc3u0Nw7sDVprVn2clZeN7jXNftUfnGVWi2gKFg5c TserKHr9/rVAwgOEl6O8x8aR9JbvBpAevWHwxOJ066JeLgY3ziNOlU+Y0Yo4c7CN TcmxjOyPTdhaYpcfR2KLfyNkbXHSMwImHCQcjNt7zbYXaKP6UOxCPR4ihOZUjrp5 c8eWQyrfh8Ubgk0RlpbqGN7SAkIv2ERWlQgyXY+PI4SbQNM/Jou3tbyt+De5b815 8gwrXOYEp+t/HfmDEtAGuGHQzdfu5sUev6/IVnpnnXFSLwrvR3wjuSSeCaIlrx4= =eAyd -END PGP SIGNATURE-
Re: [gentoo-user] did python-r1 improve user experience?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/27/2013 02:30 AM, Mike Gilbert wrote: The (non-)relationship between eselect python and PYTHON_TARGETS is something that would be nice to resolve, but I don't know how to do it. PYTHON_SINGLE_TARGET will probably cause problems if/when packages start supporting python3 only. I think python-single-r1 is one of the major problems for users, because they have to mess with two variables/useflags. Most just put PYTHON_SINGLE_TARGET=python3_3 or something in make.conf which then again affects all packages and WILL cause blockers/unresolvable deps. Afair in the very early versions we just picked the best implementation and were done with it (since a python-single-r1 package should not provide modules anyway). What is wrong with that approach (except that it still causes useless rebuilds)? Do users really need that sort of control over non-module packages? If they really do, you can still do some additional work and make a real python-r1 package out of it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSbQEKAAoJEFpvPKfnPDWz5vsIAIjvgXeR3bVy5ayT8XpZDjZ1 G9hghpRqVr6C4ITTXeFnOQcmOqtcHb2zt6rudgjV8//4H9Vr+ZSqUmPAMaaM7aN6 A0ujl6+awMDoK3GUHZ05Hk0W+gy561OkeFpoCMkBZ1Xe31DEo3nnWUktYOfscal6 QAWQRUbONX/efoDh0C6WOSMfpgvgMn2TYvem+SOQ7PTiK01rY9Hoy5+JiN1g/e/W 4dmvmxXMQ8e7n0Ec/L0vtmey4NM6znqMQHzvK6r5Aed/6B1hzwNRvFz0R7QcjjUO B/kYopuTOzj8jr52Vl00rFVRP69bMFq1M4lldQiy6dIznOGr8WLX23UhSHS1J30= =nAwp -END PGP SIGNATURE-
[gentoo-user] did python-r1 improve user experience?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since I maintain blender I have come across quite a few frustrated users already: https://bugs.gentoo.org/show_bug.cgi?id=488976#c7 I am not sure myself. On one hand we don't need python-updater anymore and have very tight dependencies that ensure that all needed modules are always available for the desired implementation. On the other hand it seems to give a lot of users trouble with blockers, general configuration and mass-updates on things like removing python:2.5. What are your opinions? Did it improve user experience? What could be improved? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSZ8uCAAoJEFpvPKfnPDWzeTgIAJeEatL7aJwIno1UVtkG11H4 DQpi3ofByswXWyCB8NjFJrKg5gxujnVnHqO30828C7RcIA0aR86BDsmI8RZHjRW5 9g7flVqLqxbMveCTzqM6EfZAzL449lcBCvXFkigbzO6Tkr5uqp6yzNe1BBqbUk2R NCGbQt2czpztWulPb3HUKtLKegRH3l7sW4mTZY8wQ0dz7YH9fo7JV/Khy4vRi+lh yj9Tks7R4o9vL8qmd72OqW8qF9L7uwudfER2jjRKKXBLYuRZv6GqjdTE9uTQtRwV hPG9fyKbzTKaYdN4CUy7bJoWTD5/+VoMQ8MXfrQjG83R5klD7u3X/pPmDJHTt3E= =f3kj -END PGP SIGNATURE-
[gentoo-user] on overlays and contributing to gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I sometimes have the feeling the number of people directly contributing to gentoo is decreasing and the number of people with their own overlays is increasing. Q: Why contribute? I have my own overlay. A: That is bad. There are several reasons: * most overlays don't get any reviews from any other person/dev and hence the quality is usually a lot lower than in the official tree (not necessarily because we are smarter, but because of more eyes) * overlays decentralize packaging which is a very bad thing and can cause so many problems that I cannot name them all here (most importantly overlay maintainers have no access to the trees profiles/ folder, cannot limit breakage that happened and cannot coordinate any delicate bumps of crucial system libs) * some overlay maintainers overwrite system libraries with their own versions, causing unnecessary bugs for users * user experience does not improve if he has to add a whole overlay for a single package * most overlays don't do pgp signing or even have thin manifests * many overlay maintainers do not even bother to communicate in bug reports about ebuild requests, so developers might not even notice that someone has already worked on an ebuild There is probably more. In the end the important thing is that an overlay is not a direct contribution to gentoo. Of course, direct contribution requires more work and more patience, but will solve all of the above problems. Q: What is direct contribution? A: There are many ways: * file a bug report with an ebuild request giving useful information about the package (I sometimes give up on working on an ebuild, because I don't use the software and have little knowledge about what users will expect from an ebuild) * file a bug report with an ebuild proposal, preferably after getting a review in #gentoo-dev-help or #gentoo-sunrise * communicate to devs that you are interested in becoming a proxy maintainer [1] * contribute to sunrise [2] the official user overlay (yes, also an overlay, but with very strict policy to ensure compatibility with the tree); here you also get a review in #gentoo-sunrise and we have mirrors on github and bitbucket to accept pull requests * start bothering the gentoo herds/projects directly, either in their IRC channel or in their official overlays (oh, an overlay again, yes... but most of the time the work done there flows directly into the tree with some delay); some are hosted on github etc * become a dev [3] Only do your own overlay if more than one of the contribution channels failed. As an example: if you propose binary ebuilds for software that is opensource, then devs will probably not like that. It is also fine to have your own overlay, e.g. for testing or for packages that are really alpha, but contributing directly is more awesome and benefits more users. - -- [1] http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml [2] http://www.gentoo.org/proj/en/sunrise/index.xml [3] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?full=1#book_part1_chap2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSMcfoAAoJEFpvPKfnPDWzIgEH/iOpSMzGMNW1Q+Kz4r3jC0e1 rsZd4YU+EgdCZrzcbYpYFyoJXdHkf4O7PxhBaMcRjLTZRMsuc5dy4l2MiyfWcV8m RJ2zeeu2ts99IQqkjncLwL3zuPT7xGt8hutwg8JRyvR47b3kvQqTO0XDq8uRdC8P 6jUtYHwJAG4F/YRjk7+vsH8RmQ9jPWRUb9pe/k9puW0ltdFAgC9vTInJnZJAY7j4 SJLAkST14R7mxTs2Uaqsfq/AgRK0A3d5o4OISECOx40VKBup9HZQqKkHBmSnKUMv lwFtQpl6ZyhuSUUUAVTuPMYIAozO49nzrpJ/i7whZ1fuXapfXvFGKMJltp1ZfR8= =gxlp -END PGP SIGNATURE-
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On 08/25/2013 06:34 PM, Mick wrote: On Sunday 25 Aug 2013 17:18:09 Alan McKinnon wrote: On 25/08/2013 02:45, »Q« wrote: On Sat, 24 Aug 2013 09:49:43 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 24/08/2013 06:26, Chris Stankevitz wrote: On Fri, Aug 23, 2013 at 9:12 PM, »Q« boxc...@gmx.net wrote: It looks like maybe the best way to tell which ebuilds support which kernels is to read the conditional for the ewarn message in each ebuild. If this sort of problem spreads it might be good to build into portage some kind of blocker/keyword mechanism so that users need not deal with this not that I have any appreciation for the work involved. Those tools already exist. Blockers, which do not really apply here; In a comment on the bug (which is full of bugspam), someone suggested blocking kernels which are incompatible with the currently-installed nvidia-drivers. I'm glad that idea was dismissed. elog messages Those elog messages are presented after compiling a new kernel and then trying and failing to compile nvidia-drivers. So now I grep the nvidia-drivers ebuilds for the messages before I compile a new kernel. A wiki page with info about which nvidia-drivers will build against which kernels would be a nice thing to have. Your reply demonstrates nicely the true nature of the problem: With nvidia-drivers, sometimes things break and there's nothing sane that portage and the devs can do to help you. You can't check the configured kernels as they may not be running. You can't check the installed sources as they may not be in use. You can't even try identify the sources symlinked by /usr/src/linux as they may have been patched, tweaked or modified and nvidia-drivers may well build whereas against stock sources they don't. The entire problem is completely due to how nVidia chose to do things, it's their business decision. Now, if they were to get their shim code into mainline, most of this nonsense would not happen anymore. The only thing left for Portage and the devs to do is to provide the ebuild and ask you to run it. If it doesn't compile, then don't run that kernel. I doubt your wiki page idea will work, it will be just accurate enough to look like it might work and just inaccurate enough to be useless. Which brings you back to the previous paragraph - try emerge nvidia-drivers and if it fails then don't use that kernel. I've been always running ATI Radeon cards, by accident rather than design. I was thinking of moving to NVidia on a new box to be built soon, because of the many accolades that I have read on the Internet, but reports of problems like this make me pause for thought. Sure it's not major borkage, but it is an inconvenience. How do NVidia users manage such problems? Trial and error? Sort of. When I hit a nice spot with a kernel/nvidia-driver combination, then I do not update both for quite a while.
Re: [gentoo-user] Jitsi or Other Skype Alternative
On 08/23/2013 05:48 PM, Marc Stürmer wrote: Am 23.08.2013 12:50, schrieb the: Does that mean that I should buy hardware to match software requirements? Do you really want to tell me that you are still working on a Pentium 133 with maybe 64 MB of RAM? I mean it has always been like that: people buy indeed hardware to match software requirements, e.g. to play better games or to watch Youtube videos in High Definition. Of course no one is going to force you to do so, so if you are happy with less power you need less, of course. The point for Skype, last time I am going to repeat that, is that it works out of the box for the normal user and the large user base. And that is still wrong. If it works for you, fine. There are enough users who have a LOT of trouble with it. Again: read the bugtrackers, I do. And even better: you cannot file bug reports properly (at least from what I see the skype jira is gone) and cannot read/fix code. You are lured into believing it's a good piece of software that works out of the box, because all they do is good advertisement and increasing their userbase with some shiny features. Even worse: distro maintainers have trouble with it, need to apply hacks or don't even include it at all because of the nasty license. How does that improve out-of-the-box experience? Next you will tell us windows works out of the box. I mean, wtf are you talking about? It doesn't make any sense. And doesn't even add anything to this topic.
Re: [gentoo-user] Jitsi or Other Skype Alternative
On 08/23/2013 08:09 PM, Yuri K. Shatroff wrote: On 23.08.2013 19:58, hasufell wrote: On 08/23/2013 05:48 PM, Marc Stürmer wrote: Am 23.08.2013 12:50, schrieb the: [ ... ] The point for Skype, last time I am going to repeat that, is that it works out of the box for the normal user and the large user base. And that is still wrong. If it works for you, fine. There are enough users who have a LOT of trouble with it. Again: read the bugtrackers, I do. (Again, I'm not a skypodefender in any way) Please recommend us a bugtracker for an actively developing software which has, well, considerably fewer bugs. (Add to this: multiplatform, multiuser, network-based etc) I was talking about crash and segfault bugs in specific. Check the xfce bug tracker if you need an example for a rather well maintained piece of software compared to skype. And even better: you cannot file bug reports properly (at least from what I see the skype jira is gone) and cannot read/fix code. You are lured into believing it's a good piece of software that works out of the box, because all they do is good advertisement and increasing their userbase with some shiny features. Even worse: distro maintainers have trouble with it, need to apply hacks or don't even include it at all because of the nasty license. How does that improve out-of-the-box experience? Your view is simply different from the view of most software users. A good piece of software for them is not what is well-coded or well-maintained or well-licensed or well-whatever. All they need is matching their expectations. You may be 146% correct about troubles and hacks but this doesn't change the average joe's expectations. And yes, in most situations skype does work out-of-the-box. Sad, but true. Repeating it and ignoring the troubles people have throughout distro forums and bug trackers will not help you prove your point. Next you will tell us windows works out of the box. It does, in most situations. Sad, but true. That is simply not true. It doesn't even come with most of the needed hardware drivers. There is almost nothing pre-installed. Getting programs is complicated. It seems to me you don't really understand what out of the box means. I mean, wtf are you talking about? It doesn't make any sense. And doesn't even add anything to this topic. That's all about off-topic. But not acknowledging the truth doesn't add anything either. Do people hate Windows or other proprietary stuff because of its bugs? Or because of its not working OOTB? In my experience, I'd probably number a thousand more times of open-source software not working OOTB and being buggy than Windows/etc. But I still adhere to OSS. I don't think that having an 'ideal' piece of proprietary software would change an open-source adept's mind towards PS. But neither I think that emphasizing PS' problems which are common to all software will help people turn to the open-source side. opensource often sucks if there is no one professionally working on it, as in: get's money
Re: [gentoo-user] Jitsi or Other Skype Alternative
On 08/22/2013 05:49 PM, Marc Stürmer wrote: And why not? Because most users just want a program that works right out of the box for them without problems and Skype is just that. It went great lengths to achieve this goal. You probably missed those hundreds of bugs we devs and also users were faced with, including linkage against non-existing sonames, random crashes and breakage when the binary is stripped. So this is somewhat wrong information. It's like saying windows works right out of the box without problems.
Re: [gentoo-user] Jitsi or Other Skype Alternative
On 08/22/2013 06:05 PM, Marc Stürmer wrote: Am 22.08.2013 17:58, schrieb hasufell: You probably missed those hundreds of bugs we devs and also users were faced with, including linkage against non-existing sonames, random crashes and breakage when the binary is stripped. So this is somewhat wrong information. It's like saying windows works right out of the box without problems. I am not arguing from the admin site of Skype; I am arguing from the user side. I was arguing from both sides. It is buggy, crashes a lot, consumes a lot of ressources and is able to slow down your whole desktop, mess with audio settings and whatnot.
Re: [gentoo-user] Jitsi or Other Skype Alternative
On 08/22/2013 06:11 PM, Marc Stürmer wrote: Am 22.08.2013 18:08, schrieb hasufell: I was arguing from both sides. It is buggy, crashes a lot, consumes a lot of ressources and is able to slow down your whole desktop, mess with audio settings and whatnot. Well, your opinion. Proven by bug reports. Search the distro bug trackers for skype crash and skype segfault. I am unable to find the upstream bugtracker, they have probably shut it down, because they are unable to deal with the amount of bugs coming in and want to prevent a bad image.
Re: [gentoo-user] Jitsi or Other Skype Alternative
On 08/20/2013 05:12 PM, Randy Westlund wrote: I've heard several people mention jitsi, but was surprised to find that it's not in the portage tree. Jitsi is written in java and thus by design buggy, bloated and hard to maintain. If you care a lot, you can propose it in sunrise user overlay and I will accept precompiled java packages there. Join #gentoo-sunrise and try to avoid random overlays. They have caused lots of trouble for our users in the past, because there is no one to review the ebuild most of the time and there is even less protection against overlays who mess with system packages and thus might break a LOT of things, partly because they have no idea what they are doing and partly because they have no access to profiles/ in gx86 and cannot coordinate any delicate changes.
Re: [gentoo-user] Jitsi or Other Skype Alternative
On 08/21/2013 05:59 PM, Jean-Christophe Bach wrote: * hasufell hasuf...@gentoo.org [21.08.2013. @16:48:10 +0200]: On 08/20/2013 05:12 PM, Randy Westlund wrote: I've heard several people mention jitsi, but was surprised to find that it's not in the portage tree. Jitsi is written in java and thus by design buggy, bloated and hard to maintain. What a categorical opinion! Developers are writing code and are making bugs, whatever the language they use. I am pretty sure I am able to write buggy, bloated and hard to maintain with Haskell, Ada, Java or any other language… It is really easy to criticize the programming language instead of reviewing the development methods. The main problem of writing an ebuild for a Java application comes from bad habits in the Java world: people are usually distributing all libraries and the program in a big ball of mud. It is great for Windows users or for users who do not use a real packages manager, but it needs lot of work to have clean packages. Regards, JC The average java application is buggy, bloated and hard to maintain. And that is a fact you have to realize as a distributor. The programming language java is another topic and it sucks too, but yes... you might be able to write non-buggy code.
Re: [gentoo-user] Moving from old udev to eudev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2013 05:01 AM, Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli * you are not telling the whole story about what happened and why the fork came into life in the first place. It's not as simple as you seem to suggest. There were good reasons at that point. Some changes were merged by udev upstream and there are still more differences than you point out. That has been discussed numerous of times. * claiming that eudev didn't improve anything is wrong and can be proven * that eudev is behind udev most of the time is correct * that it causes tons of breakage for users... well, I don't know, not for me since almost the beginning * eudev will not be treecleaned until the gentoo devs who maintain it agree (at best, it may be masked) and even if eudev will be obsolete at some point, then it has been a success * I don't understand why you add those rants all over different mailing lists. I have seen it numerous of times and your precision about explaining the situation does not improve. If you think that people need to be warned about eudev, then you should provide a reason to mask it or drop it back to ~arch. Anything else is not constructive and causes confusion. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSCMjkAAoJEFpvPKfnPDWz4/cH/1k5tyYetIZp0t+5BE2ytCFS 0FldL3IxIbOe16rfNP9LH5yqe/RnhabUbeja//rqhmMTeDGEEGbM/YgY6Tqo4q6Y usUQueYpwsVFAL9AL93+CLyQMC3cS6F1EFBeP98vcvErqHFPu9N/k2CXCQTWVlbe Vnbb+X9m2enso1rvSm/MBjtykJRzLw+Mq6gdVS9Pthb+UU78dX109z1Xtt9pSrUB Fa/NLvmQELu5QOb3+m6XXas8SoXUgjvKZ3xGgRjVmeCITBpjfsIf4KdvW0gqzOdE XjuIlNMPpLMZiWDV8yYMq2OVzRDwm8jTvSG/S4j45rHmBvTZj6km8979HAihtaQ= =Gnsu -END PGP SIGNATURE-
Re: [gentoo-user] Moving from old udev to eudev
On 08/12/2013 02:06 PM, Samuli Suominen wrote: On 12/08/13 14:37, hasufell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2013 05:01 AM, Samuli Suominen wrote: On 02/08/13 05:48, Dale wrote: Samuli Suominen wrote: Huh? USE=firmware-loader is optional and enabled by default in sys-fs/udev Futhermore predictable network interface names work as designed, not a single valid bug filed about them. Stop spreading FUD. Looking forward to lastrite sys-fs/eudev just like sys-apps/module-init-tools already was removed as unnecessary later on. So your real agenda is to kill eudev? Maybe it is you that is spreading FUD instead of others. Like others have said, udev was going to cause issues, eudev has yet to cause any. Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't bring in anything useful, and it reintroduced old bugs from old version of udev, as well as adds confusing to users. And no, sys-fs/udev doesn't have issues, in fact, less than what sys-fs/eudev has. Like said earlier, the bugs assigned to udev-bugs@g.o apply also to sys-fs/eudev and they have even more in their github ticketing system. And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so it doesn't fall too much behind, which adds double work unnecessarily. They don't keep it up-to-date on their own without prodding. Really, this is how it has went right from the start and the double work and user confusion needs to stop. - Samuli * you are not telling the whole story about what happened and why the fork came into life in the first place. It's not as simple as you seem True, I didn't mention people were needlessly unwilling to join the Gentoo udev team despite being invited to. That's a bit unrelated. It wasn't just about the gentoo ebuild. to suggest. There were good reasons at that point. Some changes were merged by udev upstream and there are still more differences than you point out. That has been discussed numerous of times. * claiming that eudev didn't improve anything is wrong and can be proven I can easily prove eudev is nothing but udev and deleted code, plus restored broken 'rule generator', plus useless kept static nodes creation which was moved to kmod, plus needlessly changed code for uclibc support -- uclibc now has the functions udev needs. Wonder why udev upstream merged back changes if it was all that bad. * that eudev is behind udev most of the time is correct * that it causes tons of breakage for users... well, I don't know, not for me since almost the beginning * eudev will not be treecleaned until the gentoo devs who maintain it agree (at best, it may be masked) and even if eudev will be obsolete at some point, then it has been a success * I don't understand why you add those rants all over different mailing lists. I have seen it numerous of times and your precision about explaining the situation does not improve. If you think that people need to be warned about eudev, then you should provide a reason to mask it or drop it back to ~arch. Anything else is not constructive and causes confusion. True, it won't be dropped for long as people are maintaining it. That's how maintainership works. But trying to lie to people it's somehow solving something currently is annoying as 'ell and should be corrected where seen. Who lied?
Re: [gentoo-user] Au revoir, gnome-3.8
On 08/09/2013 02:25 PM, Bruce Hill wrote: On Fri, Aug 09, 2013 at 11:33:53AM +0200, Alan McKinnon wrote: I long ago concluded that users who want to run Gnome3 need to do what Gnome3 devs want them to do. Currently with 3.8 that includes using systemd. This would be a _very_ good post to end this thread upon. Too bad there's not an /ignore gnome all switch for this ML. You can use a proper mail client and filter messages.
Re: [gentoo-user] Re: Killing Adobe Flash
On 08/06/2013 06:19 PM, Nikos Chantziaras wrote: On 06/08/13 17:37, Paul Hartman wrote: On Tue, Aug 6, 2013 at 9:32 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 08/06/2013 10:24 AM, Paul Hartman wrote: On Tue, Aug 6, 2013 at 9:20 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-08-06 10:12 AM, Paul Hartman paul.hartman+gen...@gmail.com wrote: For youtube you can enable HTML5 mode and avoid flash entirely for many videos (but not all). [...] Interesting... if you do enable HTML5 mode, and still have Flash installed, what happens? Is HTML5 'preferred'? Yes, some older unpopular videos that were uploaded before HTML5 support was added might not support it, but otherwise most videos seem to play using HTML5 instead of Flash once you've opted-in. You're better off using media-video/get_flash_videos- to download these anyway. [...] net-misc/youtube-dl is another one that supports many sites and is updated in portage quite often (to keep up with changes to the websites). I usually just dragdrop or copypaste the video URL into SMPlayer, which them streams the video immediately, resulting in playback of YouTube videos inside a proper media player. You can even use net-misc/youtube-viewer for that, either in console or gui (gtk useflag). And even more like net-misc/youtube-dl.
Re: [gentoo-user] Re: Gentoo is so AWESOME
On 08/03/2013 02:28 PM, Nicolas Sebrecht wrote: you guys @gentoo.org turned this thread into plain bullshits. I have a lot of patience, but that does not help us and definitely not your case either. Please stop. People who are _really_ interested in contributing are welcome to contact me directly as well.
Re: [gentoo-user] Re: Gentoo is so AWESOME
On 08/02/2013 01:16 PM, Nicolas Sebrecht wrote: And if you cba to review the basics, stuff most users know, or can find out easily, what makes you think you're cut out to be a developer? Please note I'm not discussing any technical ability you may or may not have with bash, ebuilds or upstream sources. Just your ability to find out the basics, which is much less difficult than installing Gentoo in the first place. If you want/ed to be a developer, my advice would always be: show you're useful, not that you need hand-holding and ego-stroking from the get-go. I've been an occasionnal contributor to Git, the active maintainer of OfflineIMAP for more than a year and I'm maintainer and developer at $DAY_JOB since years. I turned the OfflineIMAP worflow from one maintainer into a team of official maintainers. This is merely one example of my contributions to the open source world and when it comes to recruitement, workflow and decision processes I think I know what I'm talking about. We mainly care about gentoo contributions when it comes to gentoo recruitment and do not let people in, just because they are developers. That is not even a requirement. So we are pretty open to new contributors.
Re: [gentoo-user] Re: Gentoo is so AWESOME
On 08/02/2013 07:36 PM, Nicolas Sebrecht wrote: On Fri, Aug 02, 2013 at 01:58:35PM +0200, hasufell wrote: So we are pretty open to new contributors. Nice conclusion! Yes. We offer manys way to collaborate and the only real requirement is that people are able to read documentation and improve their knowledge. You can: * look for bugs and file them against packages * work on ebuilds that are not already in the tree and attach them to bug reports * alternatively contribute to the official user overlay sunrise, either in IRC, or on github/bitbucket mirrors * alternatively contribute directly to some herd overlays such as science or haskell (both hosted on github) * help out people with ebuild writing in #gentoo-dev-help, #gentoo-sunrise or just help users in #gentoo or on gentoo-user ML figuring out their daily gentoo problems * make techincal/political suggestions on the appropriate mailing lists * write a GLEP (everyone can) * find a mentor and become a gentoo developer Everyone can improve gentoo, just do it.
Re: [gentoo-user] Re: Gentoo is so AWESOME
On 08/01/2013 02:11 PM, Nicolas Sebrecht wrote: The 01/08/13, Alon Bar-Lev wrote: I don't see the major difference between that and opening a bug and attaching the patch. Only that bugzilla allow to manage the process, not have leftovers, and future people can resume past discussions. The bugzilla thing is what makes the difference, IMHO. git-push and git-send-email are one shoot simple commands to get things done. Having to open the web browser, connect to bugzilla, attach the patch and comment online is too much busy. You can use the command line too. www-client/pybugz With Gentoo, you have to find a mentor, officially call for being a member, success the online tests, keep mentored some time. Not very light and efficient... Can you please suggest a different method to ensure quality? Yes, having a few maintainers team with write access to the whole portage tree and contributors sending patches to them or to official package maintainers making the first review before they do the merge and submit to the main maintainers. Something like the kernel with the main maintainers, the lieutenants and open contributors. Git workflow has been on the todo list for a long time, as well as review systems such as gerrit. It is non trivial to implement and none of it is an excuse for not contributing IMO ;) Those are enhancements and we are already working on it. Get your hands dirty.
Re: [gentoo-user] Re: Gentoo is so AWESOME
On 08/01/2013 03:15 PM, Nicolas Sebrecht wrote: The 01/08/13, hasufell wrote: You can use the command line too. www-client/pybugz I know this tool. I did try it. At that time it was buggy and did not work for me. Though, this would still be a busy process as this is just another interface og the bugzilla thing. Git workflow has been on the todo list for a long time, as well as review systems such as gerrit. It is non trivial to implement Other than the git repository size requiring a huge initial clone, it's very easy to do. Let's not make this yet another git migration discussion. Sufficient to say, that it is not trivial to implement in Gentoo since we have to migrate history, tools (not just end-user tools, this is also about infra) and a lot of other stuff without breaking everything. Also: A lot of gentoo projects have an overlay on github or similar where they accept pull requests already. Including sunrise. Also, Gentoo organization has two heads making ambitious dicisions hard to take. And AFAIKS, to decision process in Gentoo is not helping at all. We are far from how it worked at the genesis/beginning of Gentoo. There is a lot of room for improvement in the political aspects of gentoo. In order to change it, you have to get more involved. It is non trivial to implement and none of it is an excuse for not contributing IMO ;) Those are enhancements and we are already working on it. Get your hands dirty. Oh, yes. Pass the recruitement process to enhance the recruitement process, workflow and decision process (not possible to change, IMO). Funny! :-) Again, I proposed myself to the dev list two times in the past. Nobody cared and I had no answers. I think the dev ML is not the right place to ask for a mentor, you actually have to _find_ one. Discuss on IRC, help out on bugzie, send pull requests to official gentoo overlays and then you might already know a few devs who work in that area you are intested in. If you are unable to find one, the recruiters will help you with that, just contact them. Also: we approach people ourselves who force us to commit for them every single time. It is annoying, so we want them to become devs ;)
Re: [gentoo-user] Gentoo is so AWESOME
On 07/30/2013 11:32 PM, Daniel Campbell wrote: On 07/30/2013 01:16 PM, hasufell wrote: And we need MOAR devs http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=2 https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs so awesome! srsly! What many people don't seem to get is: you don't need to be a commit monkey doing your 100+ commits per week. Our minimum rate of commits is pretty low before you actually are forced to retire. Better have a lot of devs each one focussing on a few packages than having few devs working on the entire tree and messing up things randomly. It's not that much work, just some regular attention. You want to join! I was interested in becoming a dev for a little while, but the testing and what looks to be prolonged process kinda put me off of the idea. It just seems like a lot of bureaucratic work. Perhaps my impression is wrong, though... Yes, your impression is wrong. You can: a) file bugs b) attach your ebuilds to bug reports (either demanding inclusion or fixing a bug, etc...) c) proxy-maintain a package (say in the bug report that you are willing to do that) d) start contributing to sunrise (join #gentoo-sunrise) and get noticed or participate in #gentoo-dev-help e) just be bold and tell us we need you; it's good if you already have an overlay and some experience or worked on bugzilla ebuilds a lot Which projects are most in need of developers or maintainers? I wouldn't mind learning a bit more about package maintenance, portage, and ebuilds... an incomplete list of herds needing help from my own perspective: - perl herd is officially asking for help - lang-misc consists of _one_ dev (we can also need help with packages like dev-lang/elixir, dev-lang/fpc and dev-lang/dmd, dmd not being in the tree yet for that very reason) - science herd is unable to import most of their ebuilds into the tree, so they stay in the science overlay. That sucks. More people. - gnome is really underpowered, hence the trouble with gnome3 if it's about projects, then well... maybe gentoo alt (bsd and prefix), arch testers or even kernel (kernel package maintainers don't have the resources anymore to stabilize vanilla-sources). Also: if you are good with python, you want to contribute to portage... very few people work on that and it's not getting less work. Our security system lacks some responsiveness imo due to being underpowered, we can improve that. GENTOO IS AWESOME!
[gentoo-user] Gentoo is so AWESOME
And we need MOAR devs http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=2 https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs so awesome! srsly! What many people don't seem to get is: you don't need to be a commit monkey doing your 100+ commits per week. Our minimum rate of commits is pretty low before you actually are forced to retire. Better have a lot of devs each one focussing on a few packages than having few devs working on the entire tree and messing up things randomly. It's not that much work, just some regular attention. You want to join!
Re: [gentoo-user] Rather ugly portage output today...
resync
