[gentoo-dev] Making an overlay publicly available?
Apologies if this is the wrong place to ask or if it's in some FAQ I've missed. I have an overlay set up here https://github.com/timboudreau/gentoo with a number of generally useful things in it (etcd, statsd, flatbuffers, ebuilds for some fonts available from dafont.com and some X themes). For my own use I just add http://timboudreau.com/files/repositories.xml to my layman.cfg, but I'd prefer to make it part of the official list of overlays. Per the instructions there, I sent email to the address listed on gpo.zugaina.org; after several months, no response; tried tweeting about with a few hashtags I though might bring it to notice of someone in the know; no response there either. Some of these are stable, and I'd be happy to maintain them as official packages if that's of interest - but probably as I'm new to this list, it's best to start with just getting the overlay available. Any pointers on where to look if there's a process for this appreciated! Thanks, -Tim -- http://timboudreau.com
Re: [gentoo-dev] parser/generator for /etc/conf.d/net*
On Mon, Jun 30, 2014 at 3:46 PM, C.J. Adams-Collier KF7BMP c...@colliertech.org wrote: I've got a project on my plate to automate and reduce the human error in adding new VLANs, subnets, addresses, etc. to our production firewall fleet. Today, we manually make modifications to the following on both members of the VRRP pair: It sounds like the default init script isn't great for you. Rather than write a generator for a static configuration file that is consumed by a script, would it make more sense to modify the /etc/init.d script to compute whatever you need on the fly? I would think that would make deployment more flexible and (depending on what you're trying to do) perhaps eliminate the need for a manual configuration step. I did that once for a Gentoo VM that needed to figure out a working network configuration under a variety of hypervisors (the thing being distributed to customers was the VM, and final setup was web-based, so it had to work no matter what). -Tim
Re: [gentoo-dev] A constructive reommendation on stablity improvemt
FWIW: I have worked on a project for years where exception reporting was used as a pump handle for Bugzilla. It can be done; the trick is getting good data *in* and automating recognition of which failures are the same failure, doing NOTHING until some threshold number of failures are logged, and having a way to flag certain flavors of report as known-bogus. Here is an example failure report and resulting bug report: http://statistics.netbeans.org/exceptions/detail.do?id=205871 https://netbeans.org/bugzilla/show_bug.cgi?id=239261 That being said, it was done for ONE language in ONE application, where the error messages were detailed, meaningful and in a standard, Java-specific format. Doing that across the multiple languages, myriad bug tracking systems (including none at all), for all packages anyone ever might build on Linux sounds like a doomed enterprise. I'm not saying don't do it - such statistics might be interesting in aggregate - but don't have high hopes for it solving the world's problems, and plan on simply publishing those stats in a consumable way, promote their existence and plan on *attracting* developers and projects to *want* to consume those, as opposed to force-feeding every bug tracker in the universe, which I assure you, will not win friends. But the bottom line is: Write a patch. Prototype the server-side piece. People respond to working code; hypothetical discussions about what somebody else could or should do inevitably go nowhere. If you write something, nobody can say you're not committed to it, and *everybody* will agree on what the thing does because they can see it, rather than guessing at what files a bug report means and getting into arguments because people are using the same words for different things. You'll probably get a better sense of the problem space and what's easy and what's hard about it in the process, which will result in a better proposal. If it's just telling other people what they ought to do, then it looks like you're a dilettante, and people are rightly wary of that. -Tim
Re: [gentoo-dev] Fw: reviewboard and its bugs
FWIW, I suspect npm is here to stay, and it has a facility for installing system-wide utilities; and NodeJS is both usable and convenient for system-level scripting which has no connection to webapps, and has the ability to build native code that integrates with NodeJS code as well. IMO, it would be pretty insane to write packages that duplicate npm packages; support within portage for installing things with it makes more sense. I've occasionally toyed with the idea of a webapp that exposes packages in npm as ebuilds and generates the required metadata on the fly, so anything in the npm repository would simply *be* a Gentoo package. Not sure the idea is viable, but it might be. If that existed, and then some known-stable subset of packages for which system-wide installation is appropriate could be mirrored in the portage tree, that would probably be ideal. -Tim On Tue, Aug 19, 2014 at 8:48 PM, IAN DELANEY del...@iinet.com.au wrote: Begin forwarded message: Date: Wed, 20 Aug 2014 08:45:21 +0800 From: IAN DELANEY idel...@gentoo.org To: gentoo-pyt...@lists.gentoo.org Subject: reviewboard and its bugs cancel the gentoo-python@lists, was intended for gentoo-dev@lists The package reviewboard has reached a stage of warranting this submission to the ML. A simple search of reviewboard in bugzilla lists a few 'user submitted' bugs and no less than 3 sec bugs. This package I added initially because interest was expressed mainly by my final mentor and the other (prior) co-maintainer. Because of changes to reviewboard upstream, we need a new eclass and category to cater to certain js packages. Now wishing to re-write all I have already written in the bugs, in summary, reviewboard has become unworkable by the developers of reviewboard itself going down the path of nodejs. Enter npm. npm was an unknown to me until Djblets and django-pipeline ebuilds failed due to the absence of UglifyJS and some related js deps. On being informed of ebuilds for this and related deps in the overlay of neurogeek, I discovered they required npm which it seems comes in nodejs. The response drawn by fellow devs over npm is in my limited experience unprecedented. The overall reaction was leave it and don't go there. What became apparent from the ebulds in neurogeek's overlay was that these deps didn't lend themselves well to writing ebuilds for them for portage. In the overlay there is in fact an npm eclass to overseer their installation into the system. After some somewhat reluctant discussion of npm in irc, it has at least been suggested that the use of nodejs' UglifyJS in django-pipeline could be patched out to relieve us all of any reliance or involvement of npm to install these js oriented deps. That has not ofcourse been attempted or tested and allows for the probability of breaking Djblets and or reviewboard which I suspect has been written by reviewboard developers to explicitly depend on and call these deps. The decision it seems isn't whether to allows npm into portage, it already comes with nodejs correct me if I misunderstand. The question is whether to support this npm installing packages into a gentoo system by ebuilds essentially outside of portage. This requires an eclass and it has been suggested a whole new category for portage under which to categorise these npm type packages. Such an eclass has already been written, however, that it has never been added to portage along with js style packages in the overlay, to me at least, strongly suggests the author always had reservations with its addition. There is ofcourse the alternative; to write ebuilds to install these packages without npm involvement. This would still require an eclass anyway. Either way, nodejs and java script are totally outside the realm of pythonic packages and are therefore outside my realm of knowledge and experience. Reviewboard developers have essentially created a huge dilemma for users of reviewboard in gentoo by going electing to use this js 'toolchain'. While I normally go to any lengths to maintain any and all packages within the python realm, this reviewboard has gone way beyond that realm. Until this, its underbelly was pure python and posed no real problem. Now I have a growing and unwelcome list of bugs of this package assigned to me as the sole remaining maintainer which are now unworkable. The real problem here is that there is an apparent keen set of would be users of this package, one of whom is a gentoo dev, who is to be found in at least one of those bugs. To delete or mask the package amounts to a clean solution, and also abandons gentoo users looking to have the package made work for them. In summary, because of changes to reviewboard upstream, we need a new eclass and category to write ebuilds to these packages and add them to portage. -- kind regards Ian Delaney -- kind regards Ian Delaney -- http://timboudreau.com
Re: [gentoo-dev] Fw: reviewboard and its bugs
On Wed, Aug 20, 2014 at 11:08 AM, Jesus Rivero (Neurogeek) neurog...@gentoo.org wrote: I originally responded to another thread. Here is what I said: I gave this a try some time ago and was bummed down by some things. I dont like nodejs enough, and npm devs seems to not care about centrally/globally installed packages. There are some npm packages that have to be modified so they can work when globally installed and it gets boring after a while. npm packages tend to be really small so one package can have a really high number of deps. For NodeJS, the first-class thing is web applications, and as far as their concerned, the best practice is, if your application uses a library, it should have its own copy of it. And, for web applications, that *does* guarantee that you know what version of everything you're deploying, and allows an application to have dependencies which themselves have conflicting dependencies - which helps ensure deployment is uncomplicated and you know what you're deploying. However, globally installed packages are supported, and are increasingly important as people discover NodeJS is useful for things that are not web-application related. So it seems like something that's not going away, and sooner or later package managers will have to deal with it. If anybody is interested in this, check out my repo with npm packages[0] and a really simple g-npm tool[1] to generate ebuilds for them. These tools might be outdated cause I don't use nodejs anymore and I dont care much about it. g-npm looks interesting. -Tim
Re: [gentoo-dev] git security (SHA-1)
If someone wants to commit malicious code into Gentoo, they're far more likely to take the ugly but pragmatic approach of, say, forcing someone to commit malicious code at gunpoint and then shooting them, than to go to the vast effort it would take to come up with malicious code that conveniently has the same SHA-1 hash as an existing commit. -Tim