Hello, all.
I'd like to ask finally: who feels himself responsible for deploying
bashcomp-2.1-r1? Does he have any kind of plan? Does anyone care at
all?
Do I have to say it's pretty far from professional to commit it
half-working, with no clear information how to proceed, neither for
users nor f
On 09/09/13 12:24, Michał Górny wrote:
Hello, all.
I'd like to ask finally: who feels himself responsible for deploying
bashcomp-2.1-r1? Does he have any kind of plan? Does anyone care at
all?
2.1-r1 works great here and I don't see any other work left than maybe a
wiki page for instructing p
Dnia 2013-09-09, o godz. 12:50:03
Samuli Suominen napisał(a):
> On 09/09/13 12:24, Michał Górny wrote:
> > Do I have to say it's pretty far from professional to commit it
> > half-working, with no clear information how to proceed, neither for
> > users nor for developers? As far as I can see, the
Ryan Hill wrote:
>
> You will be expected to fix them, and `append-flags
> -fno-stack-protector` is not an acceptable fix.
I guess there might be some projects with special
assembler code where this is the only possiblity.
For your information, I attach my list of packages
(of about 1400 install
On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill wrote:
> You will be expected to fix them, and `append-flags
> -fno-stack-protector` is not an acceptable fix. You can't champion for more
> secure defaults and then just disable them when they get in your way.
Why not? Surely a system where 99.9% of th
On 09/09/13 13:05, Michał Górny wrote:
Dnia 2013-09-09, o godz. 12:50:03
Samuli Suominen napisał(a):
On 09/09/13 12:24, Michał Górny wrote:
1. how to properly disable completions the 'new way'?
something like
http://blog.onetechnical.com/2012/06/19/disable-bash-autocompletion-on-ubunt/
shou
Dnia 2013-09-09, o godz. 18:12:08
Nikos Chantziaras napisał(a):
> On 09/09/13 13:05, Michał Górny wrote:
> > Dnia 2013-09-09, o godz. 12:50:03
> > Samuli Suominen napisał(a):
> >
> >> On 09/09/13 12:24, Michał Górny wrote:
> >>> 1. how to properly disable completions the 'new way'?
> >>
> >> som
Hello, all.
I've been working on solving the issues we had with Python script
wrapping. I'd like to present the best solution I could think of, along
with a technical demo, and ask for your opinion.
Wrapping Python scripts currently involves renaming them through
appending ${EPYTHON} suffix. Thi
As a follow up to this discussion, I came with the attached patch. It
appears to work ok for regular merges and binpkg merges with
FEATURES="collision-protect".
Per my reading of PMS it does not appear to violate anything so I guess
it is ok.
--
Gilles Dartiguelongue
Gentoo
[1;32mIndex: gdk-pi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/10/2013 02:29 AM, Gilles Dartiguelongue wrote:
> As a follow up to this discussion, I came with the attached patch.
> It appears to work ok for regular merges and binpkg merges with
> FEATURES="collision-protect".
>
> Per my reading of PMS it d
On 09/09/13 08:29 PM, Gilles Dartiguelongue wrote:
>
> [1;32mIndex: gdk-pixbuf-2.28.2.ebuild[0;0m
> [1;32m===[0;0m
> [1;32mRCS file:
> /var/cvsroot/gentoo-x86/x11-libs/gdk-pixbuf/gdk-pixbuf-2.28.2.ebuild,v[0;0m
> [1;32mretriev
Michał Górny posted on Mon, 09 Sep 2013 17:18:50 +0200 as excerpted:
> Dnia 2013-09-09, o godz. 18:12:08 Nikos Chantziaras
> napisał(a):
>
>> On 09/09/13 13:05, Michał Górny wrote:
>> >
>> > Trying plain:
>> >
>> >complete -r git
>> >
>> > it removes git completion indeed. But when I type 'g
On Mon, 9 Sep 2013 08:21:35 -0400
Rich Freeman wrote:
> On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill wrote:
> > So does anyone have any objections to making -fstack-protector the default?
> > Now is the time to speak up.
>
> So, in this world of all-or-nothing we want people who realize that
> 100
Ryan Hill wrote:
> I don't like creating more work for people, so I want to be sure
> there is consensus on this first. So far it sounds like there is.
I think there will come enough objections, but only down the road,
and only from people who don't want to care about quality.
Don't let that sto
Markos Chandras wrote:
> the whole eclass is inside the " if [[ ! ${_GIT_R3} ]] " block.
Rather than putting the whole eclass inside a block like that maybe
it's possible to test for that condition and "exit" early?
//Peter
04.09.2013 18:01, Ian Stakenvicius пишет:
> On 04/09/13 01:28 AM, Sergey Popov wrote:
>> 02.09.2013 19:29, Ian Delaney (idella4) пишет:
>>> idella4 13/09/02 15:29:57
>>>
>>> Modified: ChangeLog Added:
>>> sendpage-1.1.0-r2.ebuild Removed:
>>> sendpage-1.1.0-r1.ebuild Log: revbump ->
16 matches
Mail list logo
