Re: [gentoo-dev] Multiple occurences of flags in use.local.desc

2016-07-15 Thread Ulrich Mueller
> On Fri, 15 Jul 2016, waltdnes wrote: > Another day, another thread about multiple occurences of a flag in > use.local.desc. Howsabout a serious overall look at the situation? > [...] > The final result is that flagcount.txt has a count, in descending > order, of each flag in use.local

[gentoo-dev] Multiple occurences of flags in use.local.desc

2016-07-15 Thread waltdnes
Another day, another thread about multiple occurences of a flag in use.local.desc. Howsabout a serious overall look at the situation? Start with the following short script... #!/bin/bash rm -rf flagcount0.txt sed "s/:/ /" /usr/portage/profiles/use.local.desc | \ cut -d \ -f 2 | \ sort -u

Re: [gentoo-dev] rfc: new global use flag: luajit

2016-07-15 Thread waltdnes
On Fri, Jul 15, 2016 at 11:23:37PM +0200, Dirkjan Ochtman wrote > On Thu, Jul 14, 2016 at 4:34 PM, William Hubbs wrote: > >> I'd rather avoid adding more of this until we figure out what to do > >> about multiple Lua versions. The Lua5.1/5.2 split is still stuck > >> nowhere, and luajit is yet ano

Re: [gentoo-dev] rfc: new global use flag: luajit

2016-07-15 Thread Dirkjan Ochtman
On Thu, Jul 14, 2016 at 4:34 PM, William Hubbs wrote: >> I'd rather avoid adding more of this until we figure out what to do >> about multiple Lua versions. The Lua5.1/5.2 split is still stuck >> nowhere, and luajit is yet another variant to handle. > > If we don't do this, the only way to add lua

Re: [gentoo-dev] rfc: new global use flag: luajit

2016-07-15 Thread Raymond Jennings
My personal opinion is that anything that reduces complexity or duplication in the tree is a good thing. At least if there's some kind of version spat, you only need to fix it in one place (the eclass) instead of in individual ebuilds. On Thu, Jul 14, 2016 at 7:34 AM, William Hubbs wrote: > On

[gentoo-dev] Signed push & clock drift rejection

2016-07-15 Thread Robin H. Johnson
Hi all, In tracing down problems with the git->rsync path, it has been noticed that some developers have significant clock drift on their local systems (up to one case of 14 days wrong), and it's potentially contributing to problems in generating the rsync tree. I have implemented a check as part