On Tue, 21 May 2013 18:57:20 -0600
Ryan Hill wrote:
> Huh? The severity of the bug is it's an enhancement.
The point I was making is we could improve things by a fair margin. If
all stabilisation bugs had a Severity that actually reflected the
severity, then I'd pay attention to it. Right now o
On Wed, 22 May 2013 19:18:41 +1000
Michael Palimaka wrote:
> A newer version of a package is usually considered to be better in
> some way, hence it is an enhancement.
Unless it's a Blocker, of course. :)
> According to the bug-wrangler's own docs[1]: "A stabilisation request
> should be handl
On Thu, 23 May 2013 23:40:42 -0600
Ryan Hill wrote:
> Okay, so what are you using the STABLEREQ keyword for that you want
> to set it when the bug is filed but before archs are added? If you
> want to see only stabilization bugs you can search in the Keywording
> and Stabilization component. Ca
On Fri, 20 May 2011 17:39:22 +0200
Jeroen Roovers wrote:
> for a while now I've been wondering if all those sed scripts in all
> those ebuilds are really effective.
This took rather long to find some spare time for.
Plonk the attached bash script into /etc/portage/bashrc.d (which yo
For a good while now, I have been obsoleting ebuild attachments on as
yet unassigned bug reports and pasting proper unified diffs into
comments. I have been doing this so that the maintainers of these
ebuilds see the actual changes instead of a giant blob of code that the
submitter of the ebuild mi
On Thu, 20 Jun 2013 10:39:54 +0200
Fabio Erculiani wrote:
> The final outcome I would love to see is that everybody eventually
> graduates from kindergarten :-)
> And perhaps introduce a "culture-fit" score in the recruiting,
> mentoring process.
Maybe we should require everyone to be able to re
On Thu, 04 Jul 2013 09:31:35 -0700
Brian Dolbec wrote:
> Thank you for the extra effort. I appreciate it, although for the
> one I had recently, it made it harder. I had just migrated the
> ebuild to the new python eclasses. So the diff included the reversal
> of those changes too.
That happene
On Sat, 27 Jul 2013 16:09:20 +0400
"Vadim A. Misbakh-Soloviov" wrote:
> What about adding "export LC_ALL=POSIX" (or, at least, LC_MESSAGES)
> [...]
We've been over this plenty of times in the past. Notably in March 2009,
July 2010 (about python specific build issues), April 2011, December
2011 a
On Sat, 27 Jul 2013 18:36:26 +0400
"Vadim A. Misbakh-Soloviov" wrote:
> Unfortunately, gentoo.org's archive seems to be broken/frozen, while
> it is a bit hard to grep 3party archives to find already discussed
> topics :-/
Please reply below the quoted text.
> 27.07
On Tue, 30 Jul 2013 10:53:11 -0400
Rich Freeman wrote:
> On Tue, Jul 30, 2013 at 10:40 AM, viv...@gmail.com
> wrote:
> > does "storage space" make everyone happy?
> >
>
> rich0 is confused and looks over at the "storage space" he keeps his
> bicycles in...
So what colour would your storage spa
On Tue, 30 Jul 2013 09:04:56 -0700
Matt Turner wrote:
> I committed it last night before your email.
# Keep it sorted. Please do not add anything without prior
discussion # on
gentoo-dev.
n32
n64
o32
This is not a valid format for a .desc file. You should use:
-
jer
On Mon, 5 Aug 2013 13:57:55 +0200
Ulrich Mueller wrote:
> Currently, USE flag descriptions are a mix of imperative ("Enable")
> and indicative ("Enables") forms, the former occuring more often:
>
>Enable : Enables = 2143 : 408
>Add : Adds = 525 : 341
>Build : Builds =
23:37:25 rej, you have notes! [21:13] Let me
rephrase this: Just a friendly notice to please refrain from rephrasing
bug summaries from "Stabilize ${P}" to "${P} stable req". This just
adds unneeded noise to the bug. I don't want this on bugs I've reported
or am assigned to.
This is my equally
On Wed, 07 Aug 2013 19:07:55 +0200
Manuel Rüger wrote:
[...]
I appreciate the kinder tone.
> first of all I welcome and appreciate the work all members of the
> other bug wranglers project[1] and you do.
This is where you start to slip. I am not just a bug wrangler.
- I maintain many hundreds
recting your mistakes, whether trivial or indeed
grave (see below).
Oh, and now we can't do anything without an existing policy? Good thing
you decided to grace this project with your attention, or we wouldn't
get anything done, like:
Jeroen Roovers 2013-08-06 12:46:43 UTC
Summary:
On Tue, 13 Aug 2013 22:59:49 +0200
"Andreas K. Huettel" wrote:
> anymore but default to English. The intention behind this is to
intention behind this is => rationale is
> have a hard time analyzing localized builds.
analyzing localized builds => reading build logs in foreign languages
> Thi
On Thu, 22 Aug 2013 12:28:24 +0100
Markos Chandras wrote:
> Wow! That is something we actively encourage people to avoid. Mixed
> systems are totally
> unsupported and I am sure quite a few bugs are closed as invalid when
> a mixed system is detected.
Mixing stable and testing is precisely what
On Mon, 26 Aug 2013 09:38:04 +0200
Michał Górny wrote:
> I've noticed that some people are using internal eclass functions
> in their ebuilds. [...] What should I do to them?
File a bug report. Don't do anything "to" anyone.
jer
On Sat, 31 Aug 2013 12:37:58 -0400
"Rick \"Zero_Chaos\" Farina" wrote:
> I know we are a little OT here but the fifth type of recruit is
Yes.
> someone who is very excited, very dedicated, and completely unable to
> find a mentor. That is where I was for a long time, no one seemed to
> have th
On Sun, 8 Sep 2013 18:06:56 -0600
Ryan Hill wrote:
> So does anyone have any objections to making -fstack-protector the
> default? Now is the time to speak up.
On PARISC you get plenty of warning of how well it's going to work out:
(cc1|gcc|foo): warning: -fstack-protector not supported for thi
On Mon, 16 Sep 2013 14:41:12 +0200
"Andreas K. Huettel" wrote:
> Please stop pointless bugspam.
Nice one. I'm all for it. I'm not sure how it applies to me, though.
You could prevent getting mail like that 1) by sending comments like the
above to /dev/null or 2) by writing proper bug summaries
On Mon, 16 Sep 2013 09:19:47 -0400
Rich Freeman wrote:
> Jer - can you comment on how these changes are getting made? Is this
> some kind of script, or are you manually making these changes?
It's a thing called "editing" and it is still usually done by humans
(with a broad exception for modern
On Mon, 16 Sep 2013 15:50:06 +0200
Dirkjan Ochtman wrote:
> On Mon, Sep 16, 2013 at 3:09 PM, Michael Palimaka
> wrote:
> > At what point do we draw the line? Today my mailbox is full of
> > email with changes like "app-foo/bar-1.2.3: version bump" ->
> > "app-foo/bar-1.7.3 - Version bump.", chan
# ChangeLog for app-misc/emelfm2
# Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2
# $Header: /var/cvsroot/gentoo-x86/app-misc/emelfm2/ChangeLog,v 1.56
2013/09/23 09:47:35 ssuominen Exp $
23 Sep 2013; Samuli Suominen
emelfm2-0.8.1.ebuild, emelfm2-0.8.2.ebuild, emelfm2-0.9.
On Sun, 29 Sep 2013 23:41:03 +0200
hasufell wrote:
> Arch teams do not test them
When "arch teams" do not test them, there is something wrong with "arch
teams". Being a member of one, I assure you that is not what *I* do.
jer
On Mon, 30 Sep 2013 08:14:29 +0200
Agostino Sarubbo wrote:
> These type of failures are _not_ architecture dependant.
This is wrong.
Libraries behave differently on different architectures because the
compiled code is actually different. Different architectures use
different ways to access and
On Tue, 01 Oct 2013 00:23:16 +0800
Patrick Lauer wrote:
> On 09/30/2013 07:45 PM, Chí-Thanh Christopher Nguyễn wrote:
> > due to technical issues with the robo-stable scripts.
>
> > due to technical issues with the robo-stable scripts.
>
> let me summarize my response as "WAT"
I call, and rais
On Fri, 11 Oct 2013 18:00:33 +0200
hasufell wrote:
> I c. Woukd there be a way to change the plugin dir, so it is not
> version specific anymore?
Yes, we could call wireshark's configure with
--with-plugins="${libdir}/wireshark/plugins" . It defaults to
'${libdir}/wireshark/plugins/${VERSION}'.
On Sat, 19 Oct 2013 12:14:51 -0400
"Anthony G. Basile" wrote:
> I'm worried about removing desktop-wm. I think we need some new
> developers in that direction. I too am busy, but I think the best
> use of my time might be mentoring new devs that want to pick up some
> of the weak areas.
With
request on alpha, |dev-lang/luajit:2 |arm, ppc, ppc64, sparc
>
> --- Comment #10 from Tom Wijsman (TomWij) ---
> (In reply to Jeroen Roovers from comment #5)
> > No, you broke it for HPPA users and for devs working on mpv.
>
> Yes, HPPA only because of the comment in pack
On Sun, 20 Oct 2013 12:41:02 +0100
Markos Chandras wrote:
> No I never meant broken depgraphs. Well for broken deps, repoman does
> not let you commit. If you use --force to workaround broken deps,
> well, then you get what you deserve.
No, apparently tomwij can get not only away with this (and
On Sun, 20 Oct 2013 14:30:56 +0200
Tom Wijsman wrote:
> Yes, I am sorry for that; it didn't came to mind to unkeyword HPPA,
> because I planned to unkeyword the USE flags instead and have planned
> to have a bug filed, I'll pay more attention to not -f again in a
> hurry.
There is no "instead".
On Mon, 21 Oct 2013 17:32:03 +0200
Tom Wijsman wrote:
> On Mon, 21 Oct 2013 15:50:34 +0200
> Jeroen Roovers wrote:
>
> > On Sun, 20 Oct 2013 14:30:56 +0200
> > Tom Wijsman wrote:
> >
> > There is no "instead".
>
> Why is there no "in
On Sat, 7 Dec 2013 07:42:48 -0500
Rich Freeman wrote:
> By all means have an @useful-utils set or some kind of profile that
> auto-installs a list of packages like openssh, vim, and so on.
> However, these are not required to bootstrap a system
Since we do want net-misc/rsync, having net-misc/op
On Mon, 16 Dec 2013 02:13:28 +0100
"Francesco R." wrote:
> another possible case are packages that do run-time checking of usable
> instruction set.
www-plugins/adobe-flash[1]
> The use flag could restrict the code to be compiled and installed from
> the ebuild.
Yes, and in that extreme case,
On Mon, 16 Dec 2013 18:07:42 -0500
"Rick \"Zero_Chaos\" Farina" wrote:
> 3.) Broken build systems. Forgive me for the term, but packages like
> libpng seem to require arcane configure flags like
> "--enable-arm-neon=$(usex neon on off)" to enable my neon fpu despite
> passing -mfpu=neon. Retard
On Sun, 22 Dec 2013 20:07:21 -0600
Donnie Berkholz wrote:
> Seems we should add repoman support to check profiles/. Spec mandates
> that are not implemented in any tool are unlikely to be adhered to.
repoman does not work in profiles, to my knowledge. It expects ebuild
in package directories in
On Wed, 25 Dec 2013 20:15:00 -0600
Donnie Berkholz wrote:
> > repoman does not work in profiles, to my knowledge. It expects
> > ebuild in package directories in categorie directories.
>
> I'm confused. Isn't that exactly what I just said? "add repoman
> support"
Yes, you did, but apparently th
On Tue, 7 Jan 2014 21:12:59 +
"Robin H. Johnson" wrote:
> I was also asked by a user to make it possible to adjust the priority
> of some mirror URLs, instead of only random choice.
While we are at it, we could add keywords for (global) regions, so
that I can set portage to look for a Europe
On Wed, 08 Jan 2014 13:37:13 -0500
Alex Xu wrote:
> Eww. Geographically-close files should be made available through
> GENTOO_MIRRORS and the regular distfiles system.
How do you define GENTOO_MIRRORS? Where did RESTRICT=mirror go? Oh
right. What if those are not available? What I am proposing i
On Thu, 9 Jan 2014 19:26:24 +0400
Igor wrote:
> >> For various reasons many techs were not implemented and now Gentoo
> >> is in a
> > kind of stagnation.
>
> > What do you mean by that in particular?
>
> Gentoo stopped.
https://bugs.gentoo.org/show_bug.cgi?id=298754
https://bugs.gentoo.org/
On Fri, 10 Jan 2014 21:26:47 +0400
Igor wrote:
> In project like that I can't rush to programming it without
> everyone's approval.
You don't need anyone's approval to do anything. Just go for it.
jer
On Sun, 19 Jan 2014 13:22:07 -0700
Denis Dupeyron wrote:
> Yes, thoughts, absolutely. Asking for QA to be at the same time judge,
> party and executioner. Need I say more?
Actually, infra would be the executioner. Also, as already pointed
out, this practice was established a very long time ago,
On Sun, 19 Jan 2014 10:46:28 +0100
Ulrich Mueller wrote:
> Instead, we should come up with a clear set of rules under what
> circumstances package maintainers are allowed to stabilise ebuilds
> themselves on all architectures.
The cases where stabilisation is important (for security, progress) a
On Mon, 20 Jan 2014 01:01:40 -0500
Mike Frysinger wrote:
> at any rate, if other devs who use this want to give it a crack,
> that'd be great. iron out bugs before the next release.
> http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=blob_plain;f=src/ekeyword/ekeyword.py;hb=gentoolk
On Mon, 27 Jan 2014 16:52:09 +0100
Michał Górny wrote:
> That's just the LZ4 library code. We additionally need the SquashFS
> support code. It has been introduced in squashfs-tools lately
> (4.2_p20140119 has it, though disabled by ebuild) and I don't see it
> in the kernel's master branch yet.
On Mon, 27 Jan 2014 18:14:54 -0500
Mike Frysinger wrote:
> > It's more obvious with the fancy colouring
>
> if you dislike the color format, then pick a different one. there
> are a large number available.
I didn't intend that at all. A coloured multiline output would be a nice
default, though
On Tue, 28 Jan 2014 08:33:05 -0800
""Paweł Hajdan, Jr."" wrote:
> Why not allow maintainers to drop redundant stable and even ~arch
> keywords from their packages?
This is standard practice already.
jer
On Wed, 29 Jan 2014 19:25:08 -0800
"W. Trevor King" wrote:
> > +report issues to the catalyst team,
>
> This reads “catalyst@” to me, which is fine if that's what you indend.
> However, you may want to suggest gentoo-catalyst@ instead, if you want
> a wider net of possible responders.
Issues sh
On Thu, 30 Jan 2014 14:03:52 +0100
Ulrich Mueller wrote:
> It may be little known, but strictly speaking, hyphens in bash
> identifiers are illegal:
>
> `name'
> A `word' consisting solely of letters, numbers, and underscores,
> and beginning with a letter or underscore. `Name's are u
On Wed, 05 Feb 2014 15:41:58 +0400
Sergey Popov wrote:
> Cause it seems that not everybody agrees with policy that we are
> trying to make.
Because it's impossible to create a simple policy to solve complex
problems. It's a waste of time and it's going to break more than you
set out to fix.
Use
On Wed, 05 Feb 2014 10:07:22 -0600
Steev Klimaszewski wrote:
> > Why is this pure and utter bullshit?
>
> Because I'm attempting to have a discussion with a brick wall.
I hit that problem immediately in another sub-thread. Are we on to
something here?
Regards,
jer
On Fri, 14 Feb 2014 19:59:58 +0100
Tom Wijsman wrote:
> > And that can work without a problem if we have a mechanism
> > in place to relieve maintainers of those bugs.
>
> Such mechanism could be to assign those bug to the arch team, this
> idea came up at FOSDEM; it won't solve the lack of manp
On Sat, 15 Feb 2014 11:41:57 +0100
Tom Wijsman wrote:
> > Assigning bugs so arch teams is cosmetic at best.
s|so|to|
> While it was not explained here, the idea can also move the actual
> maintenance of the ebuild to the arch team; such that it becomes the
> arch team's responsibility to deal w
On Sat, 15 Feb 2014 16:53:22 -0600
William Hubbs wrote:
> The problem with this is, what if it is more than one arch team? Which
> one do you assign it to?
Oh the fun we had in the past when bugs got assigned to one arch team
with a few others CC'd and no maintainer in sight (because maybe the
m
# Jeroen Roovers (16 Feb 2014)
# Unmaintained, has several problems on modern systems,
# superseded by net-analyzer/ifststatus (bug #501432)
net-analyzer/ethstatus
Removal in about 30 days.
On Sun, 16 Feb 2014 08:23:27 +0100
Tom Wijsman wrote:
> > > While it was not explained here, the idea can also move the actual
> > > maintenance of the ebuild to the arch team; such that it becomes
> > > the arch team's responsibility to deal with it, or rather don't
> > > deal with it
> >
> > H
On Sun, 16 Feb 2014 09:00:16 +0100
Tom Wijsman wrote:
> In this case the maintainer isn't needed on the bug anymore.
You can't simply drop your old toys when you get bored with them.
You're leaving a mess in the tree and blaming others. You have achieved
nothing else.
> > Or when another arch a
On Sun, 16 Feb 2014 09:03:31 -0500
Rich Freeman wrote:
> Well, that depends on your perspective. If they fix them by deleting
> the old version, then whether they've made things better or worse is a
> matter of philosophy.
When you've cut the understaffed arch team out of the loop and removed
t
On Sun, 16 Feb 2014 09:22:49 -0500
Rich Freeman wrote:
> Well, they can assign the burden to an understaffed team if the team
> wants them to.
Achieving nothing in the process, even if the understaffed team
actually responds.
> Perhaps an intermediate solution is that when a STABLEREQ gets stal
On Sun, 16 Feb 2014 15:18:42 +0100
Pacho Ramos wrote:
> I think that, if they delete del old version without breaking the tree
> (and, then, moving the package to testing for that arch), the
> situation is improved. But, if the bug is assigned to the same team
> that cannot handle its stabilizati
On Sun, 16 Feb 2014 09:38:20 -0500
Rich Freeman wrote:
> Basically that one version of the package is now maintained by the
> arch team. Yes, I know they won't maintain it. The only people that
> impacts are those who use the arch, who are free to join the arch
> team and help out. My sense is
On Sun, 16 Feb 2014 15:53:57 +0100
Pacho Ramos wrote:
In this case:
> > > - Versions that are not stabilized because arch team doesn't have
> > > the man power to do that.
> >
> > As above, package.mask would be a good intermediate solution,
> > communicating the problem to the arch users for,
On Mon, 17 Feb 2014 19:46:43 +0100
Tom Wijsman wrote:
> It allows undermanned arch teams to prioritize
Oh, so you're still assuming an understaffed team somehow manages
to do some work in an appropriate time frame. It's getting old.
Apparently "understaffed" isn't the right word since it keeps
On Sun, 2 Mar 2014 09:37:22 +0100
Michał Górny wrote:
> Few months ago I have written a small FAQ on how to use slots
> and subslots for library dependencies properly [1]. However, today
> I see that most of the developers didn't care to properly update their
> packages and when I introduced bina
On Sun, 2 Mar 2014 16:52:22 +0100
Michał Górny wrote:
> > How about you file a tracker bug report for each library package,
> > and then file bug reports per package using that dependency
> > blocking the tracker bug?
>
> Excuse me but are you serious?
Sure.
> I'm supposed to report a faftilli
On Sun, 2 Mar 2014 17:34:36 +0100
"Andreas K. Huettel" wrote:
> > How about you file a tracker bug report for each library package,
> > and then file bug reports per package using that dependency
> > blocking the tracker bug?
>
> I see your point. However please read this beautiful document for
On Sun, 2 Mar 2014 12:32:05 -0500
Mike Gilbert wrote:
> On Sun, Mar 2, 2014 at 10:45 AM, Jeroen Roovers
> wrote:
> > On Sun, 2 Mar 2014 09:37:22 +0100
> > Michał Górny wrote:
> >
> >> Few months ago I have written a small FAQ on how to use slots
> >
On Sun, 2 Mar 2014 14:44:52 -0500
Mike Gilbert wrote:
> Unless I have missed mgorny's point here, this isn't just about
> libraries that have currently subslots. This is about every single
> library in the tree.
Some (many?) libraries rarely change API/ABI so it wouldn't make sense
to include th
On Sun, 2 Mar 2014 19:58:47 +0100
Michał Górny wrote:
> > Honestly, setting up a tracker and blocking it with bugs about
> > packages which someones-sub-SLOT-checking-script has vetted to be
> > involved could be done in less than a day (for the hundred or so
> > packages that depend on dev-libs/
On Sat, 22 Mar 2014 15:33:27 -0700
Alec Warner wrote:
> https://wiki.gentoo.org/wiki/Package_Tags
"This GLEP author would love to blight categories out of gentoo
history as a giant mistake."
Why?
jer
On Sun, 23 Mar 2014 16:03:38 +0100
Alexander Berntsen wrote:
> On 23/03/14 15:46, Jeroen Roovers wrote:
> > "This GLEP author would love to blight categories out of gentoo
> > history as a giant mistake."
That's not what I wrote. It's a quotation.
> It
On Mon, 24 Mar 2014 12:36:19 +0100
Jan Matejka wrote:
> Categories are essentially tags, only less powerful as they can
> express relationship of 1:N while tags are can express M:N
No, categories are essentially directories.
I was asking about tags, not about categories.
It appears it's very h
On Mon, 24 Mar 2014 10:55:38 -0400
Damien Levac wrote:
> A lot of people already replied to this question: package search.
I didn't ask for an explanation on the mailing list. I quoted [1]
because it needs to be more specific exactly where it needs to be more
specific. The GLEP still doesn't exp
categories.
>
> The original mails are:
>
> > On Sun, 23 Mar 2014 15:46:09 +0100
> > Jeroen Roovers wrote:
> >
> > > On Sat, 22 Mar 2014 15:33:27 -0700
> > > Alec Warner wrote:
> > >
> > > > https://wiki.gentoo.org/wiki/Package
On Tue, 01 Apr 2014 19:18:44 +
hasufell wrote:
> Tom... I am not sure if you know that, but your posts are difficult to
> read. You split up posts horribly and I am often unable to follow what
> you mean... at all.
>
> If I am the only one, then it's probably my fault.
It's a good thing you
On Fri, 9 May 2014 00:53:59 +
Kent Fredric wrote:
> On 8 May 2014 22:23, Jason A. Donenfeld wrote:
>
> > Would somebody help me to make the ebuild do the right thing with
> > the emacs stuff? It would be most appreciated.
>
>
> Title of the mail is a little confusing/distracting/misleadin
On Wed, 14 May 2014 00:11:21 +
"Robin H. Johnson" wrote:
> Anyway, I'm ripping that out entirely to replace with RESTRICT=test.
Great.
jer
On Sun, 18 May 2014 20:13:07 +0200
Ulrich Mueller wrote:
Are you sure this is useful?
> --- a/eclass/elisp-common.eclass
> +++ b/eclass/elisp-common.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2013 Gentoo Foundation
> +# Copyright 1999-2014 Gentoo Foundation
> # Distributed under the terms of
On Tue, 27 May 2014 10:09:45 -0400
Ian Stakenvicius wrote:
> I don't know how much chromium is built and tested on lesser-used
> arches (ie: arm, hppa, ia64, etc)
No version of webkit/blink is known to work on HPPA, particularly
because the JS engine is broken on systems where the stack grows up
On Thu, 29 May 2014 13:42:01 -0400
"Anthony G. Basile" wrote:
> Back in Jun 2012 I added a CURL_SSL to the USE_EXPAND to represent
You could start by fixing boring old bugs instead of working on
exciting new features. See bug 510580, née 499398, which stops everyone
from stabilising because you
On Fri, 30 May 2014 23:07:55 +0100
Markos Chandras wrote:
> On 05/28/2014 09:32 PM, Dirkjan Ochtman wrote:
> > Perhaps it makes more sense to disband the herd and put all packages
> > except the ones you use up for grabs?
> I suppose so. Let me have a look and see how many packages belong to
> t
On Sun, 01 Jun 2014 13:33:22 +0200
Pacho Ramos wrote:
> This makes me wonder about the real status of some of this arches. I
> know that now we will probably see how Agostino goes ahead and does
> all the work (that is nice and I really welcome his work trying to
> keep this arches in shape), but
On Fri, 30 May 2014 19:17:31 +0200
Tom Wijsman wrote:
> On Fri, 30 May 2014 18:14:11 +0100
> Ciaran McCreesh wrote:
> > A more reasonable approach would be for the Council to permit the
> > tree to contain at most 6 wrong lines at any given time. That way
> > any developer wishing to add a new w
On Wed, 04 Jun 2014 07:29:17 +0300
Samuli Suominen wrote:
>
> On 04/06/14 07:11, Samuli Suominen wrote:
> > I'm just expecting more from our users. I don't think the news items
> > were ever designed for simplistic things like this.
>
> As in, GLEP 42 Critical News Item != Learning tool for und
On Sat, 07 Jun 2014 15:35:04 -0500
Daniel Campbell wrote:
> > [2]: Overview of bugs that involve OpenRC, most for the package
> > itself. https://bugs.gentoo.org/buglist.cgi?quicksearch=openrc
> I think working on OpenRC would be a great learning experience for me
> and would be a great opportu
On Sun, 08 Jun 2014 03:05:28 +0200
Alexander Berntsen wrote:
> On 07/06/14 23:08, Jeroen Roovers wrote:
> > You can start fixing bugs immediately. You can check out the
> > sources, write patches and attach the patches to the bug reports.
> > Then all it takes is someone
On Sun, 08 Jun 2014 14:41:04 +
hasufell wrote:
> The amount of contributors (with real patches and real ebuilds) is
> constantly decreasing,
As evidenced where exactly?
> because our workflow is horrible. I hope you
> don't actually think that bugzilla is an appropriate review platform.
A
On Mon, 09 Jun 2014 21:34:06 +0400
Mikle Kolyada wrote:
> > app-admin/389-admin-console
> > app-admin/389-console
> > app-admin/389-ds-console
> > app-admin/aws-as-tools
> > app-admin/aws-elb-tools
> > app-admin/aws-iam-tools
> > app-admin/aws-rds-tools
> > app-emulation/edumips64
> > dev-java/id
On Mon, 9 Jun 2014 18:16:02 -0600
Ryan Hill wrote:
> Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be
> enabled by default.[..]
.. on supported architectures.
Right?
jer
On Mon, 9 Jun 2014 21:46:56 -0600
Ryan Hill wrote:
> Yes. But now you've got me worried. We have to build gcc itself with
> -fno-stack-protector. Does compiling something with that flag give
> an error on hppa? Maybe give 4.8.2-r1 a whirl.
Setting -fstack-protector on HPPA does this:
warnin
On Tue, 10 Jun 2014 21:39:30 +0400
Andrew Savchenko wrote:
> On Sat, 7 Jun 2014 23:08:15 +0200 Jeroen Roovers wrote:
> > On Sat, 07 Jun 2014 15:35:04 -0500
> > Daniel Campbell wrote:
> >
> > > > [2]: Overview of bugs that involve OpenRC, most for
On Tue, 10 Jun 2014 21:47:50 -0600
Ryan Hill wrote:
> v2: Restrict by arch
> --
>
> Title: GCC 4.8.3 defaults to -fstack-protector
> Author: Ryan Hill
> Content-Type: text/plain
> Posted: 2014-06-10
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: >=sys-devel/gcc-4.8.3
> Display-If
On Thu, 12 Jun 2014 23:43:55 -0600
Ryan Hill wrote:
> On Wed, 11 Jun 2014 15:23:15 +0200
> Jeroen Roovers wrote:
>
> > Will bug #332823 and its ilk somehow be mitigated? Emerging glibc
> > with -fstack-protector still leads to similar problems. There
> > doesn&#
On Sun, 15 Jun 2014 03:50:06 +0700
"Vadim A. Misbakh-Soloviov" wrote:
> You're right in all remarks, but Maxim is just proxy here.
And that's where the whole proxy maintainership falls down, isn't it?
The committer should check for and take responsibility for any QA
issues that may arise.
On Sat, 14 Jun 2014 19:17:49 -0400
Rich Freeman wrote:
> Sure, those who commit are responsible for QA, but in general we
> should be going easy on them, especially for minor stuff.
Nobody was going hard on anyone. hasufell replied to an automated
e-mail, blaming no one in particular for a few i
On Mon, 16 Jun 2014 19:31:58 +
hasufell wrote:
> Also check the history of this thread for a few proposed solutions.
The history of this thread and the history of gx86-multilib and
crossdev development suggest that crossdev was doing nothing wrong until
gx86-multilib came around and a proble
On Mon, 16 Jun 2014 16:27:19 -0400
Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 16/06/14 04:05 PM, Joshua Kinard wrote:
> > On 06/16/2014 15:47, hasufell wrote:
> >> So I don't see what else we can do here other than taking more
> >> radical steps to INFORM
On Thu, 19 Jun 2014 01:25:03 +
hasufell wrote:
> Sergey Popov:
> > As we should not do anything crazy with DOCS and HTML_DOCS, let's
> > simplify our eclass
> >
>
> Just deprecate the whole eclass. I don't see much useful stuff there
You have got to be kidding.
jer
On Wed, 18 Jun 2014 23:43:34 +0400
Sergey Popov wrote:
> As we should not do anything crazy with DOCS and HTML_DOCS, let's
> simplify our eclass
Looks good. What ebuilds would be affected (i.e. simplifying them)?
jer
201 - 300 of 683 matches
Mail list logo
