On Tue, May 16, 2017 at 12:20 PM, Michał Górny wrote:
> Mike,
>
> I would really appreciate if you cared to follow procedures for eclass
> changes. Most notably, if you at least bothered to either ping us *or*
> sent the patch to the mailing list beforehand.
>
> This eclass is used by almost 6700
If I may ask, does anyone have any profiling information one way or the
other to shed light on the situation?
On Mon, Jul 10, 2017 at 6:12 PM, R0b0t1 wrote:
> On Mon, Jul 10, 2017 at 6:56 PM, William L. Thomson Jr.
> wrote:
> > On Mon, 10 Jul 2017 17:47:45 -0500
> > Gordon Pettey wrote:
> >
>
On Wed, Jul 12, 2017 at 9:07 AM, Gordon Pettey wrote:
> On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. <
> wlt...@o-sinc.com> wrote:
>
>> On Thu, 13 Jul 2017 01:03:00 +1000
>> Sam Jorna wrote:
>>
>> > $ emerge -C apg
>> > * This action can remove important packages! In order to be saf
On Wed, Aug 30, 2017 at 12:37 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> William L. Thomson Jr. posted on Wed, 30 Aug 2017 14:01:08 -0400 as
> excerpted:
>
> > This is more food for thought to start a discussion on new category
> > names. With Wayland becoming more of a reality every day. I think
I suppose we could consider it as a hard vs soft configuration?
hard enable = Enable no matter what, and cause an error
soft enable = Enable, unless it would break dependency
soft disable = Disable, unless it would break a dependency
hard disable = Disable no matter what, and cause an error
On We
Yeah the "soft" thing was meant as "do this unless something breaks, then
do it otherwise"
On Wed, Feb 10, 2016 at 8:57 PM, Kent Fredric wrote:
> On 11 February 2016 at 15:51, Rich Freeman wrote:
> > In this case you just wouldn't enable python 2.7 support, but you
> > wouldn't disable it eithe
My two cents:
Do it like in linux kernel.
The guys making the API change bear the burden of fixing anything it
breaks, however, if something gets officially deprecated, don't go out of
your way to support continued use.
I for one would consider "ok, this method is not working, deprecate it so
tha
So what do you guys think of leaving behind empty stubs for compatibility
and then simply filing a tracking bug blocked by any packages that removing
herds broke?
On Sat, Feb 13, 2016 at 2:44 PM, Rich Freeman wrote:
> On Sat, Feb 13, 2016 at 4:47 PM, Raymond Jennings
> wrote:
> &
Speaking of which is there a bug filed for that?
On Sat, Feb 13, 2016 at 5:16 PM, Rich Freeman wrote:
> On Sat, Feb 13, 2016 at 7:58 PM, Raymond Jennings
> wrote:
> > So what do you guys think of leaving behind empty stubs for compatibility
> > and then simply filing a track
Seems like there's a trade off in resource usage re: git vs rsync
Rsync seems to be relatively cheap, but has a fixed part of its overhead.
Probably one of the reasons that you get temp-banned from the mirrors if
you sync too often.
Git overhead appears ot be higher on the variable parts but lowe
I think this might be one reason that /etc/mtab was deprecated in favor of
a symlink to /proc/mounts :P
On Thu, Feb 18, 2016 at 9:07 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Rich Freeman posted on Thu, 18 Feb 2016 07:22:36 -0500 as excerpted:
>
> > 4. In the runlevel paradigm you usually think
Especially if the changelog files are broken up by year or so.
On Sat, Feb 27, 2016 at 5:14 AM, Luca Barbato wrote:
> On 24/02/16 01:33, Duncan wrote:
> > That option is there, and indeed, a patch providing it was specifically
> > added to portage for infra to use, because appending entries to e
I think best of all would be the good discipline not to break the tree in
the first place.
Is this something that Repoman could have caught? If no, should it in the
future?
On Tue, Feb 9, 2016 at 11:30 AM, Mike Frysinger wrote:
> On 03 Feb 2016 22:35, Andreas K. Huettel wrote:
> > Am Dienstag,
May I suggest first moving everything into /usr one at a time, and for each
file moved out of /bin or /sbin or whatever, replace it with a symlink?
This will allow the /bin and /sbin directories themselves to atomically be
replaced with symlinks later.
Doing it all at once will leave a gap.
For
Personally I think that merging things into /usr is a major policy decision
that is likely to contravene upstream installation locations. I wouldn't
do it lightly, if at all.
On Thu, Apr 7, 2016 at 11:54 AM, Rich Freeman wrote:
> On Thu, Apr 7, 2016 at 2:32 PM, M. J. Everitt wrote:
> > In the
My personal opinion:
Unless we have a good reason to do otherwise, don't fuck with upstream.
On Thu, Apr 7, 2016 at 8:12 PM, Damien Levac wrote:
>
> > Three points :-
> > 1) systemd - not all gentoo users subscribe to this 'philosophy' .. >but
> >no, I don't want get drawn into debates of yes/n
Please don't do this. I want my system left alone.
On Sun, Apr 10, 2016 at 11:41 PM, J. Roeleveld wrote:
> On Sunday, April 10, 2016 10:04:42 AM James Le Cuirot wrote:
> > On Sun, 10 Apr 2016 02:09:35 +0200
> >
> > "J. Roeleveld" wrote:
> > > I actually write my own initramfs because neither
AFAIK, gentoo-dev is nothing more than a mailing list, and does little more
than take in messages, archive them, and then distribute them to list
members. I don't believe that such things as IMAP or POP even apply in any
technical sense.
On Tue, May 24, 2016 at 2:51 AM, Duncan <1i5t5.dun...@cox.n
I'd honestly as a minor issue like ot know why we called it linguas in the
first place. Linguas itself is latin/romance based in name, so gentoo at
least has been showing a bit of a bias.
Personally I think its a bad name on neutrality grounds alone.
I think though I should also point out...don'
What about a global "default gui" somewhere in make.conf that says what GUI
to use if a package provides multiple?
Relatedly, I also like having a general "qt" USE flag to select any/the
best version of qt, and then having "qtX' for each version of qt...ditto
for gtk and gtkX
On Wed, Jun 1, 2016
use case: Telling a package to build a gui without deciding which one to
build. Also helps in cases where you have package A that can only build a
qt gui, and package B that can build both qt and gtk, and package C that
can build gtk only. You want to have a gui for all three, but you don't
want
+2
I don't know how many packages that is but it's WAY over the minimum of 5
advised in the dev handbook
On Sat, Jun 4, 2016 at 3:55 AM, Davide Pesavento wrote:
> On Sat, Jun 4, 2016 at 12:45 PM, Chí-Thanh Christopher Nguyễn
> wrote:
> > Suggested description: Add support for the WebP image fo
If tidy-html5 can take care of anything htmltidy can, then we can boot the
latter as obsolete anyhow. Are there any backwards compatibility issues if
we just punt it and let tidy-html5 take over?
On Mon, Jun 6, 2016 at 7:15 AM, Yury German wrote:
>
>
> On 6/5/16 8:02 PM, Patrice Clement wrote:
Stabl
> 2. dep and rdep need to be migrated to tidy-html5 and tested.
>
> Since Patrice (monsieurp) is the maintainer of tidy-html5, do you want
> to become maintainer of htmltidy temporarily to help kill it and move to
> tidy-html5?
>
>
> On 6/6/16 10:41 AM, Raymond Je
In my humble opinion, sunrise is a needless layer of bureaucracy to getting
new packages into the tree. Personlly, I think it's not a bad idea for new
packages to be submitted as enhancements directly on bugzilla, possibly
CCing any relevant projects who could provide a review.
On Mon, Jun 6, 20
How about simply closing sunrise to new packages, and migrate them to
elsewhere as resources permit?
Just plugging the spigot and deprecating it would improve things.
On Tue, Jun 7, 2016 at 12:55 AM, Robin H. Johnson
wrote:
> On Tue, Jun 07, 2016 at 09:44:42AM +0200, Dirkjan Ochtman wrote:
> >
I think the demise or replacement of the sunrise project should be put on
the agenda possibly. This is not anything official, just a hopefully
helpful suggestion.
On Fri, Jun 10, 2016 at 2:45 PM, Michał Górny wrote:
> Hello,
>
> Considering the strength of response from a Council member, I woul
I'd like to chime in if I may. I've found "VERIFIED" to be needless.
Especially in cases where I have logs or whatnot, having to prove the bug
is there is tedious.
Shouldn't the existence of the report be evidence enough?
On Fri, Jun 17, 2016 at 10:39 AM, Rich Freeman wrote:
> On Fri, Jun 17,
Just to give kudos, I would not be able to keep my system tidy without
eclean-kernel. It takes care of lots of stuff portage does not.
On Fri, Jul 1, 2016 at 10:58 AM, Guilherme Amadio wrote:
> On Thu, Jun 30, 2016 at 02:38:26PM +0200, Michał Górny wrote:
> > So if you have some time, please re
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
If an empty project has subprojects, I think that violates the definition
of empty.
On Sat, Aug 6, 2016 at 8:46 AM, james wrote:
> On 08/06/2016 09:29 AM, NP-Hardass wrote:
>
>> On 08/06/2016 04:31 AM, Pacho Ramos wrote:
>>
>>> Now https://wiki.gentoo.org/wiki/Project:Desktop
>>>
>>> Well, it se
Hey, just a heads up as a user. I'm currently using LXDE.
On Sun, Aug 7, 2016 at 1:22 AM, Pacho Ramos wrote:
> Now https://wiki.gentoo.org/wiki/Project:LXDE is empty
>
> Feel free to join, anyway, if I don't misremember, LXDE is dead for a
> long time in favor of LXQT... in that case treecleani
I think that a superproject can serve as a good rubber-band grouping
construct, personlaly
On Thu, Aug 11, 2016 at 11:19 AM, Pacho Ramos wrote:
> El jue, 11-08-2016 a las 13:15 +0300, Mart Raudsepp escribió:
> > [...]
> > It should be kept for the purposes of coordination between different
> > s
>From an interested user, you have my thanks.
On Sun, Aug 14, 2016 at 1:38 AM, Pacho Ramos wrote:
> El sáb, 13-08-2016 a las 22:39 -0700, Hanno Böck escribió:
> > Ok, so it seems I'm currently the only one interested.
> >
> > While the wiki page lists no other devs, there are two more devs
> > l
Strict compliance with the handbook would seem to forbid having a stable
package depend on an unstable package, and if you have to downgrade a
dependency and it causes a cascade, I would opine, that, perhaps, the
package in question should not have been stabilized to begin with.
That said, I as a
Just an FYI, games-emulation/dosbox tripped over this recently.
On Sat, Aug 6, 2016 at 7:05 AM, Andrew Savchenko wrote:
> Hi,
>
> On Sat, 30 Jul 2016 12:34:07 +0300 Andrew Savchenko wrote:
> > On Sat, 30 Jul 2016 07:37:08 +0200 Michał Górny wrote:
> > > > @@ -116,7 +123,8 @@ ESVN_PROJECT="${ESVN
On Tue, Aug 23, 2016 at 4:17 PM, Robin H. Johnson
wrote:
> Over the years, the base-system package herd has grown in size. Today
> it comprises 320 packages, of which 61 of those have more than one
> maintainer. The packages with more than one maintainer I'm only
> concerned about if the other ma
On Mon, Aug 22, 2016 at 9:00 AM, Pacho Ramos wrote:
> I am not sure when https://wiki.gentoo.org/wiki/Project:Arch_Testers wa
> s created, but it's empty and unused for a long time, hence, I don't
> know if anyone would be willing to join to it (I am unsure about what
> will it cover over the "de
On Fri, Sep 9, 2016 at 4:04 AM, Marek Szuba wrote:
> # Martin Gysel via g-p-m (09 Sep 2016)
> # Versions currently in Portage are old and block removal of other
> # packages. Current versions require building against modified versions
> # of dev-libs/libdivecomputer and kde-apps/marble which mus
On Fri, Sep 9, 2016 at 11:30 PM, Kent Fredric wrote:
> On Fri, 9 Sep 2016 21:59:10 -0700
> Raymond Jennings wrote:
>
> > +1. Any package whose upstream says "don't build this yourself" is
> hostile
> > to open source principles.
>
> That's also
On Mon, Sep 12, 2016 at 1:11 AM, Marek Szuba wrote:
> On 2016-09-11 14:19, Martin Gysel wrote:
>
> >> +1. Any package whose upstream says "don't build this yourself" is
> >> hostile to open source principles.
> > just to make it clear, upstream never said such thing nor are they in
> > any way h
On Sun, Sep 25, 2016 at 11:29 PM, Michał Górny wrote:
> On Mon, 26 Sep 2016 08:18:27 +0200
> Michał Górny wrote:
>
> > On Mon, 26 Sep 2016 00:42:11 +0300
> > Mart Raudsepp wrote:
> >
> > > Ühel kenal päeval, P, 25.09.2016 kell 23:08, kirjutas Michał Górny:
> > > > I'd like to introduce a new US
On Thu, Oct 13, 2016 at 7:01 AM, Fernando Rodriguez
wrote:
> On 10/04/2016 06:24 PM, William Hubbs wrote:
> >
> > This would actually be another reason to get rid of grub-0, if it can't
> > build on one of our profiles, it will more than likely never be fixed
> > upstream because they are now
On Mon, Oct 17, 2016 at 12:23 AM, Michał Górny wrote:
> Hello, everyone.
>
> I'd like to point out a major problem in Gentoo: there's a fair number
> of developers who add various local workarounds to problems they meet
> and don't bother to report a bug. Worst than that, this applies not
> only
My biggest opinion regarding workarounds and bugs, is that we're sweeping
things under the rug that should at least be documented, and perhaps
fixed...or even punted upstream if its serious enough.
Changing the status quo may require some adjustment though, but I suppose
we could start by openly
My personal opinion:
If you have to work around it, its already a bug.
ld process mangling) probably doesn't count.
On Tue, Oct 18, 2016 at 11:11 PM, Daniel Campbell wrote:
> On 10/17/2016 06:09 AM, Raymond Jennings wrote:
> > My biggest opinion regarding workarounds and bugs, is that we're
> > sweeping things under the rug that should at l
Don't you need autoconf and automake to build a lot of packages?
On Tue, Oct 25, 2016 at 7:03 AM, Kristian Fiskerstrand
wrote:
> On 10/25/2016 04:01 PM, Alexis Ballier wrote:
> > On Mon, 24 Oct 2016 20:43:44 -0400
> > Michael Orlitzky wrote:
> >
> >> Looking at profiles/base/packages, I see a b
Why exactly isn't libstdc++ a separate package anyway?
We already have glibc as a separate package, so why the difference?
On Tue, Oct 25, 2016 at 8:47 AM, Mike Gilbert wrote:
> On Tue, Oct 25, 2016 at 11:05 AM, Nick Vinson
> wrote:
> > That definition definitely excludes automake and autoconf
+1 for at least having this discussed out in the open.
The issue of copyright did tickle my mind when I saw the headers during my
dev quiz.
On Mon, Oct 24, 2016 at 4:21 PM, Rich Freeman wrote:
> On Mon, Oct 24, 2016 at 7:10 PM, Matt Turner wrote:
> > On Mon, Oct 24, 2016 at 4:07 PM, Rich Freem
On Tue, Nov 22, 2016 at 12:06 AM, Alice Ferrazzi wrote:
> What about maintainers that are away without writing it in their
> maintainer bug ?
> After how many days of no replay can be fair to touch their package ?
I think we already have dev-away.
If a maintainer marks themselves as devaway, m
On Sun, Nov 27, 2016 at 4:07 AM, Rich Freeman wrote:
> On Sun, Nov 27, 2016 at 5:56 AM, Raymond Jennings
> wrote:
> > On Tue, Nov 22, 2016 at 12:06 AM, Alice Ferrazzi
> wrote:
> >>
> >> What about maintainers that are away without writing it in their
> >
I hope this isn't a stupid question...but can we safely assume that all
such google code SRC_URI's have *already* been mirrored?
If I understand the mirrors correctly, they serve as a sort of cache of
sorts of upstream distfile sources. Is there such a thing as a "cache
miss" that could lead to a
Hey devs, and hopefully fellow devs before long.
Just joined this list as suggested on irc and I'm going to be lurking for
awhile to see what you guys actually do every day.
Carry on.
You know guys, I just joined this list so I could get an inside look at how
gentoo development is supposed to work, and hopefully find a few role
models so I know what to do to get the ball rolling on becoming a developer
myself.
I never expected to walk into this sort of tit for tat mud slinging
Not to mention how do you actually log a hangout for the record instead of
already having logs from an irc session or mailing list.
On Thu, Jul 4, 2013 at 2:10 AM, Peter Stuge wrote:
> Diego Elio Pettenò wrote:
> > just opening a webcam and talking is just going to give an amateurish
> feeling
If I may ask, isn't usage by 27 packages ample grounds on its own to make
it a global use flag?
This is one of the questions I noticed on the ebuild quiz, and there the
ballpark is around 5 packages sharing a use flag. we're way over that mark.
my two cents.
On Tue, Feb 25, 2014 at 11:22 AM, T
As long as an announcement is made in advance (perhaps as a NEWS item)
and portage itself is prepared to do an in-place migration if
necessary, I think things will be fine.
I do think it would be a wise idea to "grandfather" the current layout
for awhile.
On Wed, Jul 11, 2018 at 6:24 AM Gordon Pe
Just for the record, but would putting a setting inside
/etc/portage/make.conf be the appropriate way to handle this?
In that case, I vote for /var/cache/portage, since that's literally
what purpose it serves. Namely, the cache of the gentoo infra's
current copy of teh portage tree.
On Thu, Jul 12, 2018 at 11:00 AM Alec Warner wrote:
>
> On Thu, Jul 12, 2018 at 1:43 PM, Raymond Jennings wrote
On Thu, Jul 12, 2018 at 12:47 PM Brian Dolbec wrote:
>
> On Thu, 12 Jul 2018 11:49:37 -0700
> Raymond Jennings wrote:
>
> > In that case, I vote for /var/cache/portage, since that's literally
> > what purpose it serves. Namely, the cache of the gentoo infra'
On Fri, Aug 14, 2015 at 6:16 PM, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 14/08/15 06:43 PM, Johannes Huber wrote:
> >
> >
> > Am 08/15/15 um 00:19 schrieb Andrew Savchenko:
> >> Hi,
> >
> >> While I have no objections about EAPI 4 deprecation (except
> >
What's the best way to get rid of deprecated ebuilds?
Do we just wait for their maintainers to migrate them or should they be
sought out and flagged? I'm pondering searching for EAPI 0 ebuilds and
filing bug reports on them.
On Sun, Aug 16, 2015 at 6:57 AM, Rich Freeman wrote:
> On Sun, Aug 16
On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman wrote:
> On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell wrote:
> >
> > I like the general 'gtk' flag we generally use to choose *which*
> > toolkit, and local USE flags for specific versions, if they are
> > supported. But in that case, the general
I agree. I think that any "master" version of whatever repo we use should
be hosted on gentoo owned infrastructure.
Github might be allowed to take pull requests but I think it should be a
slave to whatever's hosted on gentoo.
That way if anything gets screwed up on github gentoo could always hi
Gentoo is a distribution that incorporates heterogeneous software packages,
each of which may have their own versioning scheme.
We kinda have to treat the upstream version as an opaque blob because of
this.
Maybe I'm missing something but I don't think it's ok to screw with
upstream supplied vers
Is it possible for projects to be nested, possibly within multiple
super-projects?
Like, for example, a project dealing with a gnome chat client itself being
members of both the gnome and the chat projects (hypothetically speaking)?
Maybe allow projects themselves to be members of other projects
Can a single project have multiple super-projects? If so, herds might
become redundant.
On Sat, Sep 19, 2015 at 5:07 PM, Rich Freeman wrote:
> On Sat, Sep 19, 2015 at 7:32 PM, Raymond Jennings
> wrote:
> > Is it possible for projects to be nested, possibly within multiple
> &
Isn't the whole anongit.gentoo.org concept designed to allow anonymous,
read-only git to scale indefinitely in the future?
Are there any plans in the works on how to utilize this domain name?
On Thu, Nov 5, 2015 at 6:33 AM, Alexis Ballier wrote:
> On Tue, 3 Nov 2015 16:04:38 +0100
> Chí-Thanh C
As a possibly relevant side note, I've observed how api changes are handled
in the linux kernel:
You can change whatever you want if it's a good idea, but as part of
proving it, you have to be willing to take over the warranty for anything
you break.
So basically you change what you please ONLY i
On Wed, Nov 18, 2015 at 1:25 AM, Alexander Berntsen
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 18/11/15 08:25, Ulrich Mueller wrote:
> > - If you mix stable and unstable then you are by definition an
> > advanced user, who will be able to cope with the situation. :)
> This
71 matches
Mail list logo
