Re: [gentoo-dev] Re: Packages up for grabs
On 8/7/2016 10:06 AM, Alan McKinnon wrote: I have no idea where James gets his information from, but I suspect it's a niche market where uni students do "clustering" - whatever that is. Many of the new frameworks/servers that are developed for running or managing clusters are written in Java, which is what he's referring to as far as I can tell. Hadoop, spark, hive, pig, marathon, cloudstack, zookeeper, and many more (see http://www.apache.org for plentiful examples) are all JVM-based languages. University students do not touch on anything related to clustering until graduate level courses (I just graduated from the University of Michigan), unless they work on that stuff as a job or in their spare time. The interesting apps out there are mostly running python, go and (sometimes) lua. And that's what I observe in my day job - business/mobile ISP. Yes and no, depending on what you find interesting. Plenty of web applications are written in python or ruby, but I think it's safe to assume that most high-traffic organizations have mounds of Java and C/C++ services on the backend for various reasons. Alec
Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)
On Fri, Jun 10, 2016 at 04:20:06PM +0100, M. J. Everitt wrote: > (2) any user can edit wiki pages not governed by Projects. Even Project > pages I'm sure could be updated by means of patches submitted to the > appropriate team, with some basic follow-up to ensure action. Only users with a wiki account. The gentoo wiki/handbook et. al. are great, but I personally really do not like editing wikis in general. When I see a clarification or improvement that I could make in gentoo's docs, I remember that I'd have to: * get a wiki account * use a dumb web editor and (probably) HTML to make a change instead of vim * get it approved somehow All my enthusiasm vanishes at that point. If gentoo's wiki/docs were, say, a bunch of markdown files in a git repo somewhere, I would be much more willing to clone the repo, make a change, and send in a patch. A wiki and handbook could be auto-generated from this, of course. From an infra standpoint, this is also simpler than maintaining a wiki. > (3) until some enthusiastic sponsors come forward to host/maintain these > systems, I don't think its fair to overburden the already stretched > Infra guys (no offence, guys! you're doin a great job). Agree. Gentoo is fantastic. Alec
Re: [gentoo-dev] www-client/chromium gtk3 support
On Thu, Sep 10, 2015 at 02:33:09PM +0200, hasufell wrote: > On 09/10/2015 02:25 PM, Rich Freeman wrote: > > > > gtk2+gtk3 in RAM at the same time has a higher memory footprint than > > either one alone. If any package uses one or the other, it will end > > up being loaded into RAM, so there is potentially value in using one > > of them exclusively. > > > > So you are saying for the unlikely case that someone runs gentoo on a > desktop system where he cannot even compile gcc, llvm and others without > waiting for 2 weeks or setting up his on binhost, we have to provide a > backup-path for him, so that gtk3 is not loaded into his RAM? That was my situation until very recently. Firefox builds took ~6 hours. gcc took 2-3 hours. Even though gtk is not that big, it still took 15ish minutes for me to build. If upstream gives the option of gtk2 or gtk3, why shouldn't the ebuild? >From the "I want a usable system with as little code as possible" and "I want a system tailored to my needs" standpoints, having only one version of gtk makes quite a bit of sense. Alec
Re: [gentoo-dev] www-client/chromium gtk3 support
On Thu, Sep 10, 2015 at 03:07:16PM +0200, Michał Górny wrote: > Dnia 2015-09-10, o godz. 08:46:41 > Alec Ten Harmsel <a...@alectenharmsel.com> napisał(a): > > > If upstream gives the option of gtk2 or gtk3, why shouldn't the ebuild? > > From the "I want a usable system with as little code as possible" and "I > > want a system tailored to my needs" standpoints, having only one version > > of gtk makes quite a bit of sense. > > This is the same case as with many other libraries which suffered major > API changes -- SDL, for example. Just because upstream *thinks* they > support two GTK+ versions, doesn't mean they do. Only one of the > versions is well-tested, and the second one sometimes isn't tested at > all, neither by upstream nor by the developer. I'm sorry, I wrote too briefly. hasufell seems to be saying that gtk2 should be deprecated now. I'm just agreeing with Rich that if upstream supports both *and* the maintainer wants to support both, there's no reason to force them to only support one. > The happy end result is, sometimes user has choice between 'working > package' and 'package randomly segfaulting when you least expect it'. > Of course, it's all hidden nicely under USE=gtk2 and USE=gtk3, so just > *maybe* if you have the time to read local flag descriptions for every > single package you may notice which of the flags should be enabled to > get a working app. > > But yes, wasting people's time and offering easy way to data loss is > better than not supporting some imaginary corner case when you can > actually use some fancy combination of applications that can actually > run without that one library without losing stability and benefit you. > > I hope you are ready to pay the developers who will waste their time > figuring out what goes wrong when you report a bug, until they figure > out it's because you have forced GTK+ version which upstream thought > they're supporting but they do not. That's certainly a better > alternative than paying for hardware that can handle loading two > libraries. As Rich has mentioned already, if upstream thinks they support gtk2 but it crashes when using gtk2, I am perfectly fine with the maintainer closing the bug as WONTFIX because upstream broke things. Alec
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 02/02/2015 09:06 AM, Michał Górny wrote: Hi, everyone. Just after the news item got published, user Wes mailed me with a suggestion. While I think someone mentioned it earlier in the bikesheds over ffmpeg, I have completely forgotten about it and now I'd like to reconsider it. For this reason, I've reverted the news item while it's still fresh and p.masked the revbumps. The idea is that instead of having USE=libav (that's tangential to USE=ffmpeg and confusing) to use a USE_EXPAND like FFMPEG_IMPL taking either ffmpeg or libav. Now, why... First of all, one of the key points in my news item is that users need to keep consistent state of USE=libav throughout all the packages. Wes pointed out that users are more likely to consider a dedicated variable (USE_EXPAND) in make.conf global than a regular USE flag. Which makes it more likely for them to end up in terrible state full of blockers. Secondly, it avoids the confusion of having USE=ffmpeg and USE=libav being used for completely different purposes. This is not only confusing by users who need to set USE='ffmpeg libav' if they want libav, but also confusing to developers who may end up using the two flags to signify the two implementations. Think of the mess of USE='gtk gtk3'. I might not have followed this discussion close enough; wasn't the end result that USE='ffmpeg' uses ffmpeg and USE='libav' uses libav? As in there will be no more USE='ffmpeg libav' in the future, only USE='libav' for libav? FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will exactly get used. Much less confusion. I would agree except that as far as I know ffmpeg and libav are not trying to be binary compatible. Fourthly, there's the case of implicity. Right now USE=-libav implies ffmpeg. Therefore, USE=-* implies ffmpeg as well -- which is kinda weird since it's supposedly the non-default. With this solution, USE=-* will result in explicit error asking user to select an implementation. As for the downsides: 1. there is a number of non-meaningful flag combinations. FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be blocked via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'. 2. There is some more work to get ebuilds correct (REQUIRED_USE). However, this is a minor issue compared to the potential mistakes in interpretation of USE='ffmpeg' and USE='libav'. What are your thoughts? During the earlier discussion, I was of the opinion that USE='ffmpeg' should just cause a dependency on virtual/ffmpeg and that would solve all the problems. I don't think this is right, though; if ffmpeg and libav are not trying for (or actively avoiding) binary compatibility, why not treat them as separate projects and just add RDEPEND='!media-video/ffmpeg' to libav's ebuild and vice versa? Just my two cents. I'm not a developer, but this seems like the simplest solution to me. Alec
Re: [gentoo-dev] RFCv2: USE=avcodec (+ USE=ffmpeg/libav)
On 01/20/2015 07:46 AM, Andreas K. Huettel wrote: Am Dienstag 20 Januar 2015, 08:57:43 schrieb Michał Górny: So a package supporting both providers has: IUSE=ffmpeg libav RDEPEND= ffmpeg? ( media-video/ffmpeg:= ) libav? ( media-video/libav:= [media-libs/libpostproc:=] ) REQUIRED_USE=^^ ( ffmpeg libav ) And a package with optional support for both ends up like: IUSE=avcodec postproc ffmpeg libav RDEPEND= avcodec? ( ffmpeg? ( media-video/ffmpeg:= ) libav? ( media-video/libav:= ) ) postproc? ( ffmpeg? ( media-video/ffmpeg:= ) libav? ( media-libs/libpostproc:= ) ) REQUIRED_USE= avcodec? ( ^^ ( ffmpeg libav ) ) postproc? ( ^^ ( ffmpeg libav ) ) ffmpeg? ( || ( avcodec postproc ) ) libav? ( || ( avcodec postproc ) ) No. As a user, I completely agree with Andreas. What's wrong with a dependency on virtual/ffmpeg? Let's say I want to install mpv; if I completely ignore the upstream's recommendation of ffmpeg and instead use libav to satisfy a virtual/ffmpeg dependency, that's my problem, not the Gentoo developers (in my opinion). I've written a few ebuilds, and by no means am even close to competent. If they get more and more complex like this, why should I even bother ever learning? I feel like ebuilds should be as simple as possible, to keep devs sane and to interest more people. Another downside is that a much more verbose solution like this will make dependency resolution take longer imnho. Alec
Re: [gentoo-dev] Running repoman on the portage tree
On 11/18/2014 09:38 PM, Brian Evans wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2014 09:17 PM, Alec Ten Harmsel wrote: Hey devs, This is my first mail to this list. If this is out of line, let me know. I've been playing around with Jenkins (continuous integration server) recently for a couple of personal projects, including my own overlay. I thought it would be cool to run 'repoman full' on the portage tree. A couple of things surprised me: * It took over 4 hours * So many (~3MB output) warnings, especially upstream parallel compilation bug... thought autoconf handled this, but I guess not * 9233 ebuilds that use a deprecated EAPI Please don't take this the wrong way; I'm not accusing anyone, and I still love Gentoo, it was just kind of funny. I've attached the full log for anyone that's interested. Alec This is nothing new http://packages.gentooexperimental.org/repoman-checks/ has continuous output. Brian Cool, I didn't know about that. Alec
