Le 4 nov. 2009 à 20:25, Peter Volkov a écrit :
В Срд, 04/11/2009 в 17:34 +0100, Tiziano Müller пишет:
Am Mittwoch, den 04.11.2009, 18:44 +0300 schrieb Peter Volkov:
So are there any good reasons to split packages?
In environments with a staging server and binary packages, yes.
in case whe
On Monday 09 November 2009 18:45:46 Mike Frysinger wrote:
> On Monday 09 November 2009 17:52:23 Patrick Lauer wrote:
> > On Monday 09 November 2009 21:16:28 Mike Frysinger wrote:
> > And talking about glibc ...
> >
> > For 2.11 you didn't even test if all patches apply (bug #292139)
>
> this examp
On Sunday 08 November 2009 18:36:00 Richard Freeman wrote:
> Petteri Räty wrote:
> #SRC_URI="mirror://sourceforge/${PN}/${P}.tar.gz"
> # starting to hate sf.net ...
> SRC_URI="http://foremost.sourceforge.net/pkg/foremost-1.5.6.tar.gz";
> >
> > The filename that violates our policies
Richard Freeman said:
[good stuff]
i share this sentiment. lets stay an open community and encourage
learning.
if somebody improves a package then that is a good thing. even if it could
be improved even more.
signature.asc
Description: This is a digitally signed message part.
On Monday 09 November 2009 17:52:23 Patrick Lauer wrote:
> On Monday 09 November 2009 21:16:28 Mike Frysinger wrote:
> > oh muffin ! get over it already. either do it right or stop doing it.
>
> perl?
you [thankfully] arent handling perl, so i dont see how that package is
relevant.
> > > You
Mike Frysinger wrote:
> hmm, let's see, one package that was already broken under other C libraries
> broke under glibc-2.11. and it's already been fixed. of course, if you'd
> simply used bugzilla's search function, you wouldnt have to rhetorically
> wonder aloud.
> -mike
and I was all excit
On Monday 09 November 2009 21:16:28 Mike Frysinger wrote:
> oh muffin ! get over it already. either do it right or stop doing it.
perl?
That's how you want to handle things? Great.
I think we can agree that that strategy doesn't work.
> > You should understand one thing: I don't care at all
On Monday 09 November 2009 17:30:27 Patrick Lauer wrote:
>
> "Unmaintained stuff is unmaintained"
>
If i can recall my recruitment process, i remember one sentence which was like
"if you touch any package, you are responsible for it".
Please don't hide behind your great job that you are doing
I believe QA is important from the perspective that you want to assure that
the ebuilds work. Nothing makes a casual user more annoyed that having an
emerge for his machine fail to work. But if you are running the emerges
unconstrained (e.g. you specify them in the keywords file) then you are
"ex
On Mon, 09 Nov 2009 22:12:03 +0200
Samuli Suominen wrote:
> as I've never used embedded / uclibc myself, i'm a bit confused about
> the function for uClibc++ package then, but that's a different
> story. ;)
uClibc++ is a broken C++ standard library implementation that
introduces security holes in
On Monday 09 November 2009 15:12:03 Samuli Suominen wrote:
> Mike Frysinger wrote:
> > On Monday 09 November 2009 05:37:49 Samuli Suominen wrote:
> >> but disable it in profiles/uclibc/make.defaults, since AFAIK, uclibc
> >> doesn't have libstdc++
> >
> > erm, no, that isnt correct at all. libstdc
On Monday 09 November 2009 11:30:27 Patrick Lauer wrote:
> And instead of being happy that people like ssuominen just fix things where
> other people don't (be it because these other people have no interest, only
> care about a few packages or have become distracted with life) some people
> get re
Thank you very much for your work on stabling 4.5.3. Sorry I overdid it bit,
I was getting a tad frustrated. I'll try finding the right persons on IRC then,
when I notice bugs going unanswered.
All we need now is hppa.
Cheers,
--
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc
Mike Frysinger wrote:
> On Monday 09 November 2009 05:37:49 Samuli Suominen wrote:
>> $subject
>
> sounds good to me
>
>> but disable it in profiles/uclibc/make.defaults, since AFAIK, uclibc
>> doesn't have libstdc++
>
> erm, no, that isnt correct at all. libstdc++ comes from gcc, not the C
>
On Monday 09 November 2009 07:36:31 Maciej Mrozowski wrote:
> On Sunday 08 of November 2009 23:19:13 Mike Frysinger wrote:
> > > So, you didn't get my point. It must be true then, what they say about
> > > geeks and social skills...
> >
> > i dont think your point is relevant to this thread
>
> I
On Monday 09 November 2009 05:37:49 Samuli Suominen wrote:
> $subject
sounds good to me
> but disable it in profiles/uclibc/make.defaults, since AFAIK, uclibc
> doesn't have libstdc++
erm, no, that isnt correct at all. libstdc++ comes from gcc, not the C
library. and there is little in the C
Ben de Groot wrote:
> I am of the opinion it is irresponsible to leave vulnerable versions of Qt
> with
> known security bugs any longer in the tree. The Qt team therefore requests
> that arches that have not done so already move quickly on stabilizing Qt
> 4.5.3, see bug 290922 and 283810.
>
>
Matthias Schwarzott wrote:
Up to now I have just added use-flag "extras" to control these. But I suppose
that udev-acl and maybe gudev is a hard requirement for newer hal or
devicekit versions. And upstream thinks these should be enabled by default.
I've been playing with Fedora lately and the
On Mon, 2009-11-09 at 14:33 +0100, Ben de Groot wrote:
> I am of the opinion it is irresponsible to leave vulnerable versions of Qt
> with
> known security bugs any longer in the tree. The Qt team therefore requests
> that arches that have not done so already move quickly on stabilizing Qt
> 4.5.3
Hi!
On Mon, 09 Nov 2009, Ben de Groot wrote:
> We especially request ppc64 to be marked as an experimental arch, as it
> is the worst one lagging in stabilization. See bug 281821 for a poignant
> example, a 3 months open security bug.
As a side note, don't hesitate to poke me or armin76 if you h
On Sun, 2009-08-30 at 16:11 +0200, Matthias Schwarzott wrote:
> Hi there!
A late hello,
> Second point: udev-145 bundles a lot of new extras, but they can only be
> enabled/disabled all or nothing.
>
> These extras are:
> * udev-acl: Apply consolekit permissions to devices for users (audio, vid
On Monday 09 November 2009 13:08:52 Peter Volkov wrote:
[Snip]
> Well, it looks like the root of this problem is the following statement:
> "QA is less important then new packages in the tree". I failed to hear
> any arguments why QA is unimportant so I still believe that QA problem
> is a problem.
Peter Volkov wrote:
1. Our good non-formal policy "if developer touched anything he becames
responsible for that ebuild and should fix issues noticed" is sometimes
ignored. We see people reacting: you've noticed - you fix. I think such
attitude is unacceptable.
Keep in mind the downside to such
I am of the opinion it is irresponsible to leave vulnerable versions of Qt with
known security bugs any longer in the tree. The Qt team therefore requests
that arches that have not done so already move quickly on stabilizing Qt
4.5.3, see bug 290922 and 283810.
We plan on REMOVING or at the very l
Christian Faulhammer posted on Sun, 08 Nov 2009 16:13:22 +0100 as
excerpted:
> Duncan <1i5t5.dun...@cox.net>:
>> 1) Users using ** in their package.keywords file should know enough
>> about what they're doing to use their own package.mask, as well. If
>> they're using ** in the keywords file, the
On Sunday 08 of November 2009 23:19:13 Mike Frysinger wrote:
> > So, you didn't get my point. It must be true then, what they say about
> > geeks and social skills...
>
> i dont think your point is relevant to this thread
> -mike
Indeed it is - it's not about what's been said, but about the way
If you have concerns, try a friendly approach and ask Patrick to fix them.
I'm quite convinced he would be happy to do so. Your offensive approach
achieves the opposite. That isn't in the interest of QA either.
Cheers,
--
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
___
В Пнд, 09/11/2009 в 01:37 +0100, Vlastimil Babka пишет:
> I totally agree. And I must say it started with the very first mail of
> pva. Accusing of not knowing quizzes was totally uncalled for.
If you know how to do thing properly what are the reasons avoid doing
that? All I heard here is lazines
$subject
but disable it in profiles/uclibc/make.defaults, since AFAIK, uclibc
doesn't have libstdc++
because every ebuild adding USE="cxx" is doing EAPI="2" now, and having
it in profiles by default, would allow also EAPI="0" toolchain and
system ebuilds to stop using nocxx.
did I miss something
29 matches
Mail list logo
