On Thu, Jan 09, 2014 at 04:11:28PM -0500, Rick "Zero_Chaos" Farina wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/09/2014 03:58 PM, Magnus Granberg wrote:
> > Hi
> >
> > Some time ago we discussed that we should enable stack smashing
> > (-fstack-protector) by default. So we
On Fri, Jan 10, 2014 at 12:30:04AM +0100, Andreas K. Huettel wrote:
> Am Freitag, 10. Januar 2014, 00:26:03 schrieb Ryan Hill:
> >
> > > Please avoid "noblah" use flags.
> > >
> > > http://devmanual.gentoo.org/general-concepts/use-flags/
> > >
> > > ssp flag that defaults to on is fine.
> >
> >
All,
It is becoming more and more obvious that we do not have enough manpower
on the arch teams, even some of the ones we consider major arch's, to
keep up with stabilization requests. For example, there is this bug [1],
which is blocking the stabilization of several important packages.
I spoke t
On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote:
> On 01/14/2014 04:37 PM, William Hubbs wrote:
> >
> > 2. I would like to see the policy below applied to all arch's [2].
>
> [ ] Yup
> [X] Nope
The reverse of this would be to let maintainers sta
On Tue, Jan 14, 2014 at 05:43:57PM -0500, Michael Orlitzky wrote:
> On 01/14/2014 05:33 PM, William Hubbs wrote:
> > On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote:
> >> On 01/14/2014 04:37 PM, William Hubbs wrote:
> >>>
> >>> 2. I wou
On Wed, Jan 15, 2014 at 01:38:08AM +0100, Tom Wijsman wrote:
> On Wed, 15 Jan 2014 01:06:07 +0100
> "Andreas K. Huettel" wrote:
>
> > Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman:
> > > On Tue, 14 Jan 2014 15:37:19 -0600
> > >
&
On Tue, Jan 14, 2014 at 08:36:10PM -0500, Michael Orlitzky wrote:
> On 01/14/2014 08:23 PM, Tom Wijsman wrote:
> > On Tue, 14 Jan 2014 20:11:24 -0500
> > Michael Orlitzky wrote:
> >
> >> On 01/14/2014 08:08 PM, Tom Wijsman wrote:
> >>>
> >>> This is under the assumption that the user knows of the
On Tue, Jan 14, 2014 at 09:21:51PM -0500, Michael Orlitzky wrote:
> On 01/14/2014 09:09 PM, William Hubbs wrote:
> >
> > After the package has been sitting in ~arch for 90 days with an open
> > stable request with no blockers that the arch team has not taken any
> > ac
On Wed, Jan 15, 2014 at 10:48:53AM +0700, gro...@gentoo.org wrote:
> On Tue, 14 Jan 2014, William Hubbs wrote:
> > 1. I think maintainers should be able to stabilize their packages on arch's
> > they have access to. I think this is allowed by some arch teams, but I
> >
On Wed, Jan 15, 2014 at 03:30:39PM +0400, Sergey Popov wrote:
> 15.01.2014 01:37, William Hubbs пишет:
> > All,
> >
> > It is becoming more and more obvious that we do not have enough manpower
> > on the arch teams, even some of the ones we consider major arch's, t
On Wed, Jan 15, 2014 at 07:33:45PM +0100, Thomas Sachau wrote:
> William Hubbs schrieb:
>
> > Thoughts?
> >
> > William
> >
> > [1] http://bugs.gentoo.org/487332
> > [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt
> >
On Thu, Jan 16, 2014 at 01:42:41PM -0500, Rich Freeman wrote:
> On Thu, Jan 16, 2014 at 1:11 PM, Peter Stuge wrote:
> > I certainly don't think the work needs to go away if the work is
> > considered to be important. It's fine to have open bugs for years
> > in the absence of a good solution.
>
>
On Fri, Jan 17, 2014 at 04:02:27PM +0100, Michał Górny wrote:
> Dnia 2014-01-17, o godz. 14:02:51
> gro...@gentoo.org napisał(a):
>
> > Maybe, a good solution is to introduce a special arch, "noarch", for such
> > packages (similar to what's done in the rpm world). Then, if a package is
> > ~noa
All,
I would like to bring back for discussion an old patch to glep 48 [1]
which was suggested by Jorge [2].
That patch evolved into this one [3], and in the council meeting back
then [4], parts of it made their way into glep 48, but the rest seemed to
be forgotten.
Attached you will find an upd
All,
I put this on the wrong list, so please disregard this here and reply
on -project instead; I forwarded this msg over there.
Thanks,
William
signature.asc
Description: Digital signature
On Mon, Jan 20, 2014 at 02:23:24AM -0500, Mike Frysinger wrote:
> this has all been fairly ad-hoc in the past, so formalize it in the one place
> that impacts everyone -- profiles.desc.
> -mike
If it is policy, shouldn't it go in the dev manual rather than in this
file?
Given that, I have questio
On Mon, Jan 20, 2014 at 07:18:46PM +0100, Alexander Berntsen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 20/01/14 18:26, William Hubbs wrote:
> > On Mon, Jan 20, 2014 at 02:23:24AM -0500, Mike Frysinger wrote:
> >> this has all been fairly ad-hoc i
On Tue, Jan 21, 2014 at 10:47:50AM -0500, Rich Freeman wrote:
> If Comrel really objects to this I'm not entirely opposed to letting
> QA have the reins (certainly we can't just let policy go unenforced
> entirely). However, I would encourage the teams to give some thought
> as to whether it makes
On Tue, Jan 21, 2014 at 11:56:14PM +0100, Tom Wijsman wrote:
> On Tue, 21 Jan 2014 22:03:22 +0100
> Thomas Sachau wrote:
>
> > With this in mind, i currently dont see any case where QA would need
> > the ability to remove the commit access of a dev, so i dont see a
> > need for this glep update.
On Thu, Feb 06, 2014 at 01:48:38AM +0100, Tom Wijsman wrote:
> On Wed, 05 Feb 2014 17:05:08 -0500
> "Rick \"Zero_Chaos\" Farina" wrote:
>
> > >
> > > Yes, making the newest versions never available because the old
> > > versions sink all your time really stops progress to a dead halt.
> > >
> >
Hi all,
I responded to this a while back, but I guess my email didn't go out for
some reason.
As the primary go maintainer, I do want to be involved in this. :-)
On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote:
> On Mon, 30 Dec 2013 15:48:17 -0500
> Emery Hemingway wrote:
>
> > I really li
On Fri, Feb 14, 2014 at 11:02:49AM -0500, Emery Hemingway wrote:
> On Fri, 14 Feb 2014 13:30:10 +0100
> Jan Matejka wrote:
>
> > On Thu, 13 Feb 2014 11:59:16 -0600
> > William Hubbs wrote:
> >
> > > Hi all,
> > >
> > > I responded to
On Sat, Feb 15, 2014 at 12:48:44AM +0100, yac wrote:
> On Fri, 14 Feb 2014 11:02:49 -0500
> Emery Hemingway wrote:
> > The default GOROOT that go looks at for base libraries seems to be
> > compiled in so this should be pretty easy, like python but simplier.
>
> I'm not sure what you are trying t
On Sat, Feb 15, 2014 at 11:41:57AM +0100, Tom Wijsman wrote:
> On Sat, 15 Feb 2014 01:28:55 +0100
> Jeroen Roovers wrote:
>
> > 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 maintainer
On Sat, Feb 15, 2014 at 02:30:21PM +0100, Jeroen Roovers wrote:
> 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
On Sun, Feb 16, 2014 at 12:37:03AM +0100, Jeroen Roovers wrote:
> 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 wh
On Sun, Feb 16, 2014 at 09:38:20AM -0500, Rich Freeman wrote:
> Well, if they make no choice then the maintainer deletes the package.
> That's what you want, right? The package would only stay around if
> the minor arch asked them to. If they don't do that, then nobody can
> complain.
>
> Howeve
On Sun, Feb 16, 2014 at 06:58:47PM +0100, Tom Wijsman wrote:
> On Sun, 16 Feb 2014 09:41:03 +0100
> Pacho Ramos wrote:
>
> > El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribió:
> > [...]
> > > > If we want a separate assignee for old stabilizations, what about
> > > > a separate projec
On Wed, Feb 19, 2014 at 12:34:22PM +0100, yac wrote:
> On Sat, 15 Feb 2014 16:44:09 -0600
> William Hubbs wrote:
>
> > On Sat, Feb 15, 2014 at 12:48:44AM +0100, yac wrote:
> > > On Fri, 14 Feb 2014 11:02:49 -0500
> > > Emery Hemingway wrote:
> > > >
All,
there is a significant change I want to make to the
sys-process/runit ebuild to fix a couple of bugs [1] [2].
In a nutshell, we set up a default runlevel as shown in this upstream
document [3] in /etc/runit/runsvdir. We rebuild it every time an upgrade
happens, so this is why we are hitting
On Mon, Feb 24, 2014 at 02:16:20AM +, Duncan wrote:
> What about putting the rebuild in a non-pkg_config function, then hooking
> up that function to BOTH the above, so users can choose automatic rebuild
> if they like, and regardless of whether they've done so, they can run
> emerge --confi
On Mon, Feb 24, 2014 at 08:39:33AM +, Duncan wrote:
> William Hubbs posted on Mon, 24 Feb 2014 02:14:54 -0600 as excerpted:
> > Think of /etc/runit/runsvdir as being similar to /etc/runlevels in
> > OpenRc.
> > It is a directory that gets set up once, then only the admin s
On Fri, Feb 28, 2014 at 03:59:35PM +, hasufell wrote:
*snip*
> Despite that... the answer is already here:
> http://devmanual.gentoo.org/general-concepts/filesystem/index.html
>
> > Gentoo does not consider the Filesystem Hierarchy Standard to be an
> > authoritative standard, although much
On Fri, Feb 28, 2014 at 09:57:15PM +, David Leverton wrote:
> William Hubbs wrote:
> > The reason the split happened is pretty straight forward, and every other
> > "justification" for continuing it was come up with after the fact.
>
> I keep hearing this,
On Sat, Mar 01, 2014 at 12:24:02AM +, David Leverton wrote:
> William Hubbs wrote:
> > And I would argue that the maintenance cost of having separate /usr in a
> > general sense is much higher than the benefit it provides.
>
> That's a legitimate point (not t
On Fri, Feb 28, 2014 at 07:09:08PM -0600, Steev Klimaszewski wrote:
> I'm not exactly a fan of systemd, though I know it has some uses, and
> I'm still curious as to why it installs/stores *configuration* data
> in /lib - if only from an upgrade point of view, we back up /etc, we
> back up /home -
On Fri, Feb 28, 2014 at 09:06:36PM -0500, Rich Freeman wrote:
> On Fri, Feb 28, 2014 at 8:57 PM, Steev Klimaszewski wrote:
> > The way that it's been presented throughout this thread made it seem
> > like the network configurations when using e.g. networkd were being
> > stored in there.
>
> So,
On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote:
> On Fri, Feb 28, 2014 at 7:47 PM, William Hubbs wrote:
> >
> > Patrick thinks that all configuration files belong in /etc, and what has
> > happened is, some packages are placing default configuration
> > fi
On Sat, Mar 01, 2014 at 06:48:54AM +, Steven J. Long wrote:
> On Fri, Feb 28, 2014 at 09:31:08PM -0600, William Hubbs wrote:
> > On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote:
> > > But let's be real here: if I install something and
> > > want to con
On Sun, Mar 02, 2014 at 05:49:59PM +0100, Peter Stuge wrote:
> Gilles Dartiguelongue wrote:
> > Sure at some point you have to make things evolve but this upstream
> > solution simply isn't nice for its users.
>
> That may be, but I don't think it's a distribution's responsibility
> to try to own
All,
we are getting closer to being able to deprecate
/etc/init.d/functions.sh, but I have a couple of questions I need input
from this list about. They are in the comment of the bug [1].
The first is about /etc/init.d/functions.sh. That link is not needed at
all by scripts in OpenRc. It was only
All,
for bug 373219 [1], we are working on providing a functions.sh that does
not rely on OpenRc so that people who are not using OpenRc can
completely remove it from their systems.
I can now report that gentoo-functions has been added to the tree. Also,
I have opened a tracker [2] that explains
On Tue, Mar 11, 2014 at 03:10:16PM -0400, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 11/03/14 02:24 PM, Rich Freeman wrote:
> > On Tue, Mar 11, 2014 at 1:54 PM, Michał Górny
> > wrote:
> >> Dnia 2014-03-10, o godz. 18:30
On Tue, Mar 11, 2014 at 10:10:42AM -0400, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 10/03/14 07:30 PM, William Hubbs wrote:
> > All,
> >
> > for bug 373219 [1], we are working on providing a functions.sh that
> > does n
On Wed, Mar 12, 2014 at 09:14:58AM -0400, Ian Stakenvicius wrote:
> yeah.. I scanned that bug, saw his arguments, but didn't see anything
> afterwards that seemed to address his arguments (nor anything that
> specifically addressed the removal of /etc/init.d/functions.sh as the
> de-facto location)
On Wed, Mar 12, 2014 at 01:08:43PM -0400, Rich Freeman wrote:
> On Wed, Mar 12, 2014 at 12:52 PM, William Hubbs wrote:
> > On Wed, Mar 12, 2014 at 09:14:58AM -0400, Ian Stakenvicius wrote:
> >> ...why not? As you've said yourself, nothing related to openrc uses
> >&
On Wed, Mar 12, 2014 at 01:02:13PM -0400, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 10/03/14 07:30 PM, William Hubbs wrote:
> > The quickest way to find things that will need this fix is to rm
> > /etc/init.d/functions.sh and file
All,
thinking about this further,
There may not be a need to remove /etc/init.d/functions.sh as long as it
is understood that this is part of OpenRc, not the gentoo base.
In other words, tools that must work when OpenRc is not present should
source /lib/gentoo/functions.sh, NOT /etc/init.d/funct
On Sun, Mar 16, 2014 at 09:36:02PM -0400, Mike Gilbert wrote:
> On Mon, Mar 10, 2014 at 7:30 PM, William Hubbs wrote:
> > All,
> >
> > for bug 373219 [1], we are working on providing a functions.sh that does
> > not rely on OpenRc so that people who are not using OpenR
On Thu, Apr 03, 2014 at 04:30:20PM +0400, Mikle Kolyada wrote:
>
> 02.04.2014 20:52, Samuli Suominen пишет:
> > The "30 days maintainer time out" stabilization policy isn't working
> > when package has multiple SLOTs, because
> > the bugs are filed for only latest SLOT, where as some packages requ
On Tue, Apr 22, 2014 at 09:43:24PM +0200, Tom Wijsman wrote:
> On Tue, 22 Apr 2014 22:13:16 +0400
> Mikle Kolyada wrote:
>
> > 22.04.2014 21:59, Mike Gilbert пишет:
> >
> > > Ok, then the stable keyword is going to get lost when I drop old
> > > versions.
> >
> > Vapier can restore stable keywo
All,
just a quick update.
I now have a box set up for installing gentoo on it so I will be able to
take the lead on OpenRC again.
I will have that up and running, probably tomorrow, then I also have a
medical situation I have to take care of in a couple of weeks.
I will continue to be inte
All,
I attempted to post an update a bit earlier, but I haven't seen it yet,
so I thought I would try again.
Thanks to Daniel Robbins of funtoo, I am about to getGentoo installed on
another box, so I will be able to take the lead on OpenRC again. He
assisted me on Skype today with getting in
All,
after having several hardware and software issues that I finally got
some assistance with, I am back up and running. :-)
So, now, I should be able to grab OpenRC and gentoo-base-functions by
the horns again. :-) I intend to get a new OpenRC out the door,
hopefully before next Thursday.
Than
Hi all:
On Sun, Jun 15, 2014 at 07:00:15AM -0400, Rich Freeman wrote:
> During the council meeting there was a bit of a philosophical debate
> over the proper role of EAPI vs implementing functions in eclasses. I
> felt that it was important enough to at least get more community input
> before we
All,
I am starting a new thread so we don't refer to a specific package, but I
am quoting Rich and hasufell from the previous masking thread.
On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote:
> On Sun, Jun 29, 2014 at 8:36 AM, hasufell wrote:
> > This is still too vague for me. If it
On Mon, Jun 30, 2014 at 06:13:45PM +0200, Jeroen Roovers wrote:
> On Mon, 30 Jun 2014 11:40:19 -0400
> Ian Stakenvicius wrote:
>
> > But... if I unmask it, -everyone- using ~arch will install it and
> > it'll break all the systems that it doesn't work on, which -could- be
> > quite a lot at this
All,
Rich Freeman asked, in another thread, for specific examples of old
package.mask entries that just have "masked for testing" as the
description.
Here is what I found with a quick look through package.mask. These
should be cleaned up by either 1) removing the mask or 2) booting the
affected p
On Mon, Jun 30, 2014 at 01:07:17PM -0400, Rich Freeman wrote:
> On Mon, Jun 30, 2014 at 12:32 PM, William Hubbs wrote:
> > On Mon, Jun 30, 2014 at 06:13:45PM +0200, Jeroen Roovers wrote:
> >> On Mon, 30 Jun 2014 11:40:19 -0400
> >> Ian Stakenvicius wrote:
> &
On Mon, Jun 30, 2014 at 12:46:38PM -0700, C.J. Adams-Collier KF7BMP wrote:
> Which brings me to the question, does there exist a parser/generator for
> the /etc/conf.d/net.* files? If not, would Gentoo like me to contribute
> my work on the generator, and would one of you point me to the parser?
On Mon, Jun 30, 2014 at 04:46:04PM -0400, Mike Gilbert wrote:
> On Mon, Jun 30, 2014 at 12:38 PM, William Hubbs wrote:
> > All,
> >
> > Rich Freeman asked, in another thread, for specific examples of old
> > package.mask entries that just have "masked for
All,
I'm moving to a new thread since the discussion has moved away from just
a sub profile for no-multilib.
On Wed, Jul 02, 2014 at 09:30:50AM -0400, Rich Freeman wrote:
> On Wed, Jun 25, 2014 at 4:01 PM, Andreas K. Huettel
> wrote:
> > Am Mittwoch 25 Juni 2014, 15:11:40 schrieb Rich Freeman:
>
This is a question to lxc users, since I don't run it.
I have a bug against OpenRC in which the user is saying that I should
allow /etc/init.d/sysctl to run inside an lxc container [1].
My understanding is that this is not a good idea since an lxc container
actually changes settings in the host's
On Sun, Jul 06, 2014 at 01:07:18PM +, hasufell wrote:
> If you are talking about actually testing and running the software then
> that's a different story and definitely not within our scope when
> committing to ~arch.
>
> That said, I think it's a reasonable minimum to at least check if an
>
On Sat, Jul 12, 2014 at 12:37:53PM +, hasufell wrote:
*snip*
> KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc
> ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd
> ~arm-linux ~x86-linux"
If a provider of the virtual is already stable, you can commit the
virtual
ld like to
know is whether I can nail down more how to describe when connectivity
can be lost so people don't get a surprise after they upgrade.
Any suggestions would be helpful.
Thanks,
William
Title: dhcpcd 6.4.2 defaults to stable private ipv6 addresses
Author: William Hubbs
Content-Typ
All,
I am reposting this because I got a couple of updates from IRC.
Let me know what you think.
Thanks,
William
Title: dhcpcd 6.4.2 defaults to stable private IPv6 addresses
Author: William Hubbs
Content-Type: text/plain
Posted: 2014-07-17
Revision: 1
News-Item-Format: 1.0
Display-If
All,
here is the second update from IRC today.
I reworded the title and added more information to the body recommending
that users adjust to the new configuration.
William
Title: dhcpcd >= 6.4.2 changes defaults for IPv6
Author: William Hubbs
Content-Type: text/plain
Posted: 2014-07
I'm picking a random msg to reply to.
My concern about doing a revbump just because the deps change is that
the new revision has to be committed in ~arch, so we then have to hit
the arch teams, which we know are overworked anyway, with stable
requests just because we changed the dependencies. Isn'
On Tue, Jul 22, 2014 at 11:42:30AM +0200, Alexander Berntsen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 22/07/14 02:36, hasufell wrote:
> > William Hubbs:
> >> My concern about doing a revbump just because the deps change is
> >> that the
On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote:
> On 07/25/14 15:50, Pacho Ramos wrote:
> > El vie, 25-07-2014 a las 15:38 -0400, Anthony G. Basile escribió:
> >> On 07/25/14 15:28, Pacho Ramos wrote:
> >>> That is the reason for me thinking that maybe the way to go would be to
>
On Fri, Jul 25, 2014 at 03:54:53PM -0400, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 25/07/14 03:51 PM, Pacho Ramos wrote:
> > El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh escribió:
> >> On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel
> >> wrote:
>
On Fri, Jul 25, 2014 at 10:25:57PM +0100, Ciaran McCreesh wrote:
> On Fri, 25 Jul 2014 16:23:23 -0500
> William Hubbs wrote:
> > I think this could get complicated really quick though.
> > For example, if I have an ebuild with three use flags,
> > flag1/flag2/flag3 with
On Sat, Jul 26, 2014 at 10:44:26AM +0200, Pacho Ramos wrote:
> El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió:
> > El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió:
> > > On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote:
> > >
I know I'm replying to my own message, but I do have a concern about
this that I want to ask about.
When a stable request is filed for a package, it is filed for all
architectures which have the ~arch keyword for the package and are
marked stable or dev in profiles.desc.
If an arch wants to stay
On Sat, Jul 26, 2014 at 06:31:50PM +0200, Andreas K. Huettel wrote:
> Am Samstag, 26. Juli 2014, 18:20:11 schrieb William Hubbs:
> > I know I'm replying to my own message, but I do have a concern about
> > this that I want to ask about.
> >
> > When a stable reque
On Sat, Jul 26, 2014 at 01:45:46PM -0400, Jonathan Callen wrote:
*snip*
> If you want to say "At most one of the flags 'foo', 'bar', and 'baz'
> may be selected", then you say it like so (requires EAPI=5):
>
> REQUIRED_USE="?? ( foo bar baz )"
>
> If you want to say "Exactly one of the flags
On Mon, Jul 21, 2014 at 06:20:12PM -0500, Gordon Pettey wrote:
> On Mon, Jul 21, 2014 at 5:06 PM, Alexander Berntsen
> wrote:
>
> > On 21/07/14 19:41, Ciaran McCreesh wrote:
> > > What's wrong with HOMEPAGE="()" ?
> > It is not very informative.
> >
> The wiki page is equivalently informative. Wh
On Wed, Jul 30, 2014 at 07:29:22PM +0200, Michael Haubenwallner wrote:
>
> Am 2014-07-30 14:33, schrieb Samuli Suominen:
> >
> > There is no need to package.mask if proper if -logic is used, like, for
> > example,
> >
> > if [[ ${PV} == * ]]; then
> > inherit git-r3
> > KEYWORDS=""
> > else
On Fri, Aug 01, 2014 at 10:13:33AM +0100, Steven J. Long wrote:
> On Sun, Jun 29, 2014 at 11:01:53PM -0500, William Hubbs wrote:
> > On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote:
> > > A package that hasn't been tested AT ALL doesn't belong in ~arch.
>
# William Hubbs (5 Aug 2014)
# Masked by QA for removal in 30 days.
# The unmasked version is very old, there are multiple open security
# bugs and several version bumps. The package appears to be abandoned.
# This will be removed on 5 Sep 2014 unless someone takes over
# maintenance and brings
On Sun, Aug 10, 2014 at 03:22:11PM +0300, Sergei Trofimovich wrote:
> Hello World!
>
> TL;DR:
> This evening I plan to mangle ~3000 ebuilds in the main tree
> by dropping trailing '.' in all 'DESCRIPTION=' fields (except "etc." case)
>
> Long story:
>
> As you may know newest portage release
On Tue, Aug 12, 2014 at 03:59:30AM +0200, Manuel Rüger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
*snip*
> These links might be helpful:
>
> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=06637c4215d55c57517739214c6e0fd6f8f53914
>
> https://bugs.gentoo.or
On Tue, Aug 12, 2014 at 09:26:07AM -0400, Rich Freeman wrote:
*snip*
> Yeah, at best this seems a bit trivial. Do we have a policy that
> descriptions aren't allowed to be complete sentences? Many of our
> developers are not native English speakers in the first place, so
> striving for gramma
On Tue, Aug 12, 2014 at 01:25:44PM -0400, Rich Freeman wrote:
> On Tue, Aug 12, 2014 at 1:13 PM, Ian Stakenvicius wrote:
> >
> > I don't consider a recommended style message to be 'broken' just
> > because it's not listed in the devmanual/PMS/etc as a requirement.
> > The implementation of it, on
All,
there is an ongoing discussion about how we handle eclass phase
functions by default [1].
Currently, EXPORT_FUNCTIONS is called in eclasses, and because of the
way this works, the phase function that is exported last in the chain of
inherited eclasses is the one that is called for a given ph
On Sun, Aug 17, 2014 at 10:32:14AM +1200, Kent Fredric wrote:
> On 17 August 2014 09:54, William Hubbs wrote:
> > My counter proposal to this is that we stop calling eclass phase
> > functions automatically, and to minimize the amount of boilerplating
> > we would have to
On Sun, Aug 17, 2014 at 12:54:17AM +0200, Michał Górny wrote:
> Dnia 2014-08-16, o godz. 16:54:28
> William Hubbs napisał(a):
>
> > The initial proposal is to change this behaviour so that the PMS default
> > phase functions call all matching phase functions from inhe
All,
I spoke with mgorny on IRC and found out what his concerns are about our
current eclasses.
First, he thinks we should get rid of base.eclass.
I know there is work going on to get rid of it, but I haven't really
looked into the status much yet. I do agree though, we shouldn't have a
general-
On Wed, Aug 27, 2014 at 11:43:19PM +0100, Ciaran McCreesh wrote:
> On Thu, 28 Aug 2014 00:37:48 +0200
> Michał Górny wrote:
> > What do you think?
>
> Kill it! With fire! And blood!
Add me to the list requesting that we kill dohtml as well.
William
signature.asc
Description: Digital signatur
On Sat, Aug 30, 2014 at 09:45:23AM -0400, Rich Freeman wrote:
> A possible solution is to remove it in the next version of openrc, as
> it is deprecated already. Another solution is to ask the Council to
> let somebody apply patches if the maintainer is unresponsive, set a
> deadline, etc.
The pr
On Wed, Sep 03, 2014 at 02:19:02PM -0400, Ian Stakenvicius wrote:
> I thought the whole point of the gentoo-functions package was for it
> to take over the /etc/init.d/functions.sh shortcut??
>
> As far as I am aware (and i believe vapier will confirm),
> /etc/init.d/functions.sh is and shall alwa
All,
there is a bug open requesting that we add sys-apps/iproute2 to the
system set [1]. Originally the request was to drop net-tools, but it has
become just adding iproute2.
If no one objects, I would like to do this sometime in the next 72
hours by adding sys-apps/iproute2 to profiles/default/l
All,
there are still several open bugs on the tracker for this issue [1],.
This is the only thing that is preventing us from removing the direct
reference to sys-apps/openrc from @system.
As shown in the bug, the fix is to have the package depend on
sys-apps/gentoo-functions and source /lib/gento
On Sun, Sep 14, 2014 at 08:04:12PM +0200, Andreas K. Huettel wrote:
>
> > Deciding on a _commit policy_ should be fairly straightforward and we
> > already have one point
> > * gpg sign every commit (unless it's a merged branch, then we only care
> > about the merge commit)
>
> +1
Merge commits
On Mon, Sep 15, 2014 at 09:53:43AM +0200, Fabian Groffen wrote:
> On 14-09-2014 16:56:24 +0200, Michał Górny wrote:
> > Rich Freeman napisał(a):
> > > So, I don't really have a problem with your design. I still question
> > > whether we still need to be generating changelogs - they seem
> > > inc
All,
I would like to suggest a couple of changes to the
"commit message format" section of the Gentoo git Workflow page on the
wiki.
The first bullet, which states that all lines have a max length of 70-75
characters is not quite correct. The brief explanation (the first line)
is supposed to be 5
On Tue, Sep 23, 2014 at 04:52:56PM +0200, Andreas K. Huettel wrote:
>
> > > Modified: ChangeLog perl-module.eclass
> > > Log:
> > > Remove support for EAPI 1, 2, 3 in perl-module.eclass (no packages left
> > > in the tree)
> > This could have used some kind of heads-up. Now I'm
To all pybugz users,
I need some folks to upgrade to pybugz- for a short time and see if
you can break it.
The big change is the inclusion of default configuration files as well
as the ability for the sys admin and for an individual user to override
configuration information. Also, now the co
All,
I have been working on the version bump for sys-process/runit [1].
Service directories will be stored in /etc/sv; think of this as being
like /etc/init.d.
Once this is done, there are two suggested ways of linking to the
service directories you want to monitor.
The first is to make a direc
601 - 700 of 1450 matches
Mail list logo
