[gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Duncan]

hasufell posted on Mon, 22 Jul 2013 02:50:04 +0200 as excerpted:

[Where to reply?  This seems the best spot in general.  Subthread is 
discussing permanent in-tree p.mask vs. overlay.  The below points were 
supposed to be the pros of the overlay choice.]

> On 07/22/2013 01:49 AM, Diego Elio Pettenò wrote:
>> On 21/07/2013 23:38, hasufell wrote:
> - consistency of tree quality
>>> does not apply to p.mask'd packages
>> 
>> p.mask says that the package is in _bad_ quality, explicitly, and you
>> can say how, so "does not apply" are not really the words I'd use.
>> 
> I did not know that p.mask is used indefinitely for low quality packages
> and I don't like that concept.

Yes, some packages remain in-tree permanently p.masked.  The mask gives a 
reason, and unmasking means users accept whatever risks or conditions you 
place in the reason.  In addition to unmasking, if you REALLY want to 
discourage use, you can use some variant of the  test for 
pkgname_I_KNOW_WHAT_I_AM_DOING=1 trick.

> - less user confusion (the checksum failures alone get us a lot of
> bugs every release without people realizing what it means...) and
> people expect packages to work in the tree
>>> maybe
>> 
>> Not p.masked packages they don't. Just state it outright, maybe even
>> fetch-restrict the package and warn them...

Absolutely.
 
> - less bugs no one can do anything about
>>> does not apply
>> 
>> *How* does making it into a semi-official one-purpose overlay reduce
>> the number of bugs users report? Either you're banning it into a
>> non-Gentoo-owned overlay, or you're just betting they would get the
>> reason why it's not in an overlay, same applies to p.mask.
> 
> It will reduce the number of bugs, because there will be no bugtracker,
> but only pull-requests. It would not be hosted on o.g.o. which means
> gentoo bugs are not allowed.

State in the p.mask that bugs will be ignored and/or that people filing 
bugs without patches will be summarily laughed at, and be done with it.

> - easier contribution of users in an overlay, testing of hacks or
> other stuff to make it work
>>> does not apply
>> 
>> I'm afraid I have to agree with Michael here. Proxies would do that,
>> and users are still free to experiment with overlaid version, I don't
>> see how this makes much of a difference.

Actually, I'll give you (hasufell) this one.  This is the one point I 
agree with, and it may well be enough on its own.  Proxies can help, but 
IMO that's a lot of hassle to go thru for a permanently package-masked 
package.  With an overlay, OTOH, non-dev volunteers can get direct access.

> - making clear that gentoo does not support software with such low
> QA
>>> does not apply
>> 
>> It applies perfectly. It's a p.mask for a reason, and can convey
>> reasons.

Agreed with Diego here.  If the p.mask message says unsupported, don't 
file bugs or you'll be summarily laughed at... doesn't get much clearer 
than that.

> Anyway... if people disagree, then it doesn't make much sense to remove
> it. Otherwise it will pop up in the tree sooner or later again.

FWIW, I wasn't strongly disagreeing with the removal to overlay or even 
full removal (I've never used the package and don't have that level of 
interest).  My question was real: Given the context discussing reasons 
for removal but an intention to continue making it available in an 
overlay, I simply wondered why the in-tree p.mask option that I'd seen 
used on a few other packages apparently hadn't even been considered.

Now that the option has been discussed, given you're the one that will be 
continuing the limited maintenance the package will get wherever it is, 
I've no further objection whatever you choose.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Tom Wijsman]

On Mon, 22 Jul 2013 01:26:25 +0200
hasufell  wrote:

> Afaiu pmasks are rather meant for
> a) new, very hot versions of libraries/tools that can break your
> system in more than one part
> b) security masks, temporary masks and other masks we expect to remove
> in the future

You can just summarize all possible reasons, by "does not work well";
and that's exactly what google-earth falls under as well. So, just go
mask it; and as we don't want to remove it just yet we can delay the
decision to last rite the package for later. Before we last rite, has
anyone tried to collaborate with upstream about their packaging style?

> And I said more than once that we can probably move it to science-overlay.

Overlays aren't the problem here, they'll follow automatically; even
with just the mask in place, I think there are people that are going to
try to provide it more easily anyway. And the use of a lot of overlay
packages isn't really a problem, when said person has a small overlay.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Diego Elio Pettenò]

On 22/07/2013 01:50, hasufell wrote:
> It does not apply, because we still support it officially in our main
> tree as a distribution, no matter if it's p.masked or not.

No we don't. P.masked software is *explicitly* not supported.

> Anyway... if people disagree, then it doesn't make much sense to remove
> it. Otherwise it will pop up in the tree sooner or later again.

Which is a perfect reason to keep it p.maske din tree so that nobody can
re-introduce it as they felt it "missing".


-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Michael Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/22/2013 02:34 AM, Rich Freeman wrote:
> 2.  Overlay package.* (accept one version of one package from a 
> particular overlay, mask all packages in an overlay that aren't 
> explicitly unmasked, don't apply package.(un)mask from one overlay
> to packages in another unless the mask references that overlay 
> specifically, etc).
Inside /etc/portage, */*::xmw is a valid token for p.mask, p.keyword etc.
p.mask:*/*::xmw
p.unmask:virtual/xmwce::xmw
works.


- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlHsx+sACgkQknrdDGLu8JD+uQD9E3iEX8p3zAC2Isbb8r1SJfWr
xUSK7P3F3Q3iFajBhXIA/0r2F4qyhidkjqGD8aUlJ+o+vcReCmBXegsEGbDUL496
=2xcw
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Zac Medico]

On Sun, Jul 21, 2013 at 5:34 PM, Rich Freeman  wrote:
> We're starting to drift off topic here, but I've always felt that this
> is something that could be improved on.  I'm not saying that any of
> this should just be thrown together, but some of the following might
> be useful:
>
> 1.  Overlay dependencies (depends on a particular package from a
> particular overlay).

In EAPI 5-progress, there's support for atom::repo deps.

> 2.  Overlay package.* (accept one version of one package from a
> particular overlay, mask all packages in an overlay that aren't
> explicitly unmasked, don't apply package.(un)mask from one overlay to
> packages in another unless the mask references that overlay
> specifically, etc).

These things are all supported by portage, through use of atom::repo
in /etc/portage/package.* (or profile with EAPI 5-progress) and
repo-level configurations in $repo/profiles/package.* (which only
apply to packages from that repo).

> 3.  Repository priority (paludis handles this fairly well I think) -
> where you can control which overlays override which other ones.

Portage also supports priority setting in /etc/portage/repos.conf.

> I've never really liked the all-or-nothing design of overlays as they
> currently stand.

These days, they should be much more flexible than they have been in the past.

> Even simply prioritizing them is a pretty crude
> approach.  It makes them fairly useless for general-purpose
> distribution of packages.
>
> Rich
>

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[hasufell]

On 07/22/2013 01:49 AM, Diego Elio Pettenò wrote:
> On 21/07/2013 23:38, hasufell wrote:
 - consistency of tree quality
>> does not apply to p.mask'd packages
> 
> p.mask says that the package is in _bad_ quality, explicitly, and you
> can say how, so "does not apply" are not really the words I'd use.
> 

I did not know that p.mask is used indefinitely for low quality packages
and I don't like that concept.

 - less user confusion (the checksum failures alone get us a lot of bugs
 every release without people realizing what it means...) and people
 expect packages to work in the tree
>> maybe
> 
> Not p.masked packages they don't. Just state it outright, maybe even
> fetch-restrict the package and warn them...
> 
 - less bugs no one can do anything about
>> does not apply
> 
> *How* does making it into a semi-official one-purpose overlay reduce the
> number of bugs users report? Either you're banning it into a
> non-Gentoo-owned overlay, or you're just betting they would get the
> reason why it's not in an overlay, same applies to p.mask.

It will reduce the number of bugs, because there will be no bugtracker,
but only pull-requests. It would not be hosted on o.g.o. which means
gentoo bugs are not allowed.

> 
 - easier contribution of users in an overlay, testing of hacks or other
 stuff to make it work
>> does not apply
> 
> I'm afraid I have to agree with Michael here. Proxies would do that, and
> users are still free to experiment with overlaid version, I don't see
> how this makes much of a difference.

Well, I actually only mentioned that point as a side effect. Until
now... no one was able to provide a patch to fix one of the bugs you can
read in a hundred forums and bug trackers.

But it wouldn't make much of a difference, that's probably true.

> 
 - making clear that gentoo does not support software with such low QA
>> does not apply
> 
> It applies perfectly. It's a p.mask for a reason, and can convey reasons.
> 

It does not apply, because we still support it officially in our main
tree as a distribution, no matter if it's p.masked or not.

One could probably argue that no one cares about this difference, but
it's still true.


Anyway... if people disagree, then it doesn't make much sense to remove
it. Otherwise it will pop up in the tree sooner or later again.

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Rich Freeman]

On Sun, Jul 21, 2013 at 6:33 PM, Michał Górny  wrote:
> Dnia 2013-07-22, o godz. 00:16:31
> hasufell  napisał(a):
>> - users have to run "layman -a foo" ...I hope they will manage (and the
>> masking reason will be updated to explain where to look for googleearth
>> ebuilds)
>
> Then to get *a single package* they start using the whole overlay. If
> it's a sane overlay, fine. But some overlays really replace a lot of
> stuff silently and trigger failures we didn't even imagine before.
>

We're starting to drift off topic here, but I've always felt that this
is something that could be improved on.  I'm not saying that any of
this should just be thrown together, but some of the following might
be useful:

1.  Overlay dependencies (depends on a particular package from a
particular overlay).
2.  Overlay package.* (accept one version of one package from a
particular overlay, mask all packages in an overlay that aren't
explicitly unmasked, don't apply package.(un)mask from one overlay to
packages in another unless the mask references that overlay
specifically, etc).
3.  Repository priority (paludis handles this fairly well I think) -
where you can control which overlays override which other ones.

I've never really liked the all-or-nothing design of overlays as they
currently stand.  Even simply prioritizing them is a pretty crude
approach.  It makes them fairly useless for general-purpose
distribution of packages.

Rich

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Diego Elio Pettenò]

On 21/07/2013 23:38, hasufell wrote:
>>> - consistency of tree quality
> does not apply to p.mask'd packages

p.mask says that the package is in _bad_ quality, explicitly, and you
can say how, so "does not apply" are not really the words I'd use.

>>> - less user confusion (the checksum failures alone get us a lot of bugs
>>> every release without people realizing what it means...) and people
>>> expect packages to work in the tree
> maybe

Not p.masked packages they don't. Just state it outright, maybe even
fetch-restrict the package and warn them...

>>> - less bugs no one can do anything about
> does not apply

*How* does making it into a semi-official one-purpose overlay reduce the
number of bugs users report? Either you're banning it into a
non-Gentoo-owned overlay, or you're just betting they would get the
reason why it's not in an overlay, same applies to p.mask.

>>> - easier contribution of users in an overlay, testing of hacks or other
>>> stuff to make it work
> does not apply

I'm afraid I have to agree with Michael here. Proxies would do that, and
users are still free to experiment with overlaid version, I don't see
how this makes much of a difference.

>>> - making clear that gentoo does not support software with such low QA
> does not apply

It applies perfectly. It's a p.mask for a reason, and can convey reasons.

It's your package, do what you want, but stop just trying to force your
views into suggestions, just because you already reached your
conclusion, please.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[hasufell]

On 07/22/2013 01:20 AM, Michael Weber wrote:
> On 07/22/2013 01:03 AM, Brian Dolbec wrote:
>> On Mon, 2013-07-22 at 00:35 +0200, hasufell wrote:
>>> On 07/22/2013 12:33 AM, Michał Górny wrote: I'd either use a
>>> separate single-purpose overlay or add it to science-overlay.
> 
> 
>> If it's a separate overlay, then googleearth overlay in gentoo's
>> github account for easy access for users, both to get and
>> contribute.
> 
> This is scope of proxy-main, imho. starting overlays for single
> pckages is hilarious.
> 
> 

You are ignoring the rest of the arguments. The main concern is not how
people can contribute.

And I said more than once that we can probably move it to science-overlay.

The only question now is if we want to keep it p.masked or remove it. I
don't like pmasking package indefinitely.
Afaiu pmasks are rather meant for
a) new, very hot versions of libraries/tools that can break your system
in more than one part
b) security masks, temporary masks and other masks we expect to remove
in the future

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Michael Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/22/2013 01:03 AM, Brian Dolbec wrote:
> On Mon, 2013-07-22 at 00:35 +0200, hasufell wrote:
>> On 07/22/2013 12:33 AM, Michał Górny wrote: I'd either use a
>> separate single-purpose overlay or add it to science-overlay.
> 
> 
> If it's a separate overlay, then googleearth overlay in gentoo's
> github account for easy access for users, both to get and
> contribute.
> 
This is scope of proxy-main, imho. starting overlays for single
pckages is hilarious.



- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlHsbKUACgkQknrdDGLu8JDlZQD/fnk1Z869tY0DUVjSedW/TDnm
bVuv0IrCjn/UJoDvjIMBAJCMgLNF2QUBprZMVjw5Fj6zFiWqGckCM+Q0aHBieUJ7
=DH1b
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Brian Dolbec]

On Mon, 2013-07-22 at 00:35 +0200, hasufell wrote:
> On 07/22/2013 12:33 AM, Michał Górny wrote:
> > Dnia 2013-07-22, o godz. 00:16:31 hasufell 
> > napisał(a):
> > 
> >> On 07/22/2013 12:07 AM, Duncan wrote:
> >>> hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as
> >>> excerpted:
> >>> 
>  solution: Treeclean it and maintain it in an overlay (maybe 
>  science-overlay). That's exactly what overlays are for...
>  experimental stuff.
> >>> 
> >>> What's the pros/cons of overlay vs. in-tree-but-masked for
> >>> something like this?  In-tree-but-masked is at least available
> >>> for those who want it, without having to load an overlay, but I
> >>> don't see that discussed at all, here.
> >>> 
> >> 
> >> cons: - users have to run "layman -a foo" ...I hope they will
> >> manage (and the masking reason will be updated to explain where
> >> to look for googleearth ebuilds)
> > 
> > Then to get *a single package* they start using the whole overlay.
> > If it's a sane overlay, fine. But some overlays really replace a
> > lot of stuff silently and trigger failures we didn't even imagine
> > before.
> > 
> 
> No.
> 
> I'd either use a separate single-purpose overlay or add it to
> science-overlay.


If it's a separate overlay, then googleearth overlay in gentoo's github
account for easy access for users, both to get and contribute.


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[hasufell]

On 07/22/2013 12:22 AM, Diego Elio Pettenò wrote:
> On Sun, Jul 21, 2013 at 11:16 PM, hasufell  wrote:
> 
>> pros:
>> - consistency of tree quality
does not apply to p.mask'd packages

>> - less user confusion (the checksum failures alone get us a lot of bugs
>> every release without people realizing what it means...) and people
>> expect packages to work in the tree
maybe

>> - less bugs no one can do anything about
does not apply

>> - easier contribution of users in an overlay, testing of hacks or other
>> stuff to make it work
does not apply

>> - making clear that gentoo does not support software with such low QA
does not apply

>> - making clear that this software is experimental
applies

>>
> 
> Half of those apply also to p.mask'd packages as Duncan pointed out. Maybe
> even more than half.
> 
> 

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[hasufell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/22/2013 12:33 AM, Michał Górny wrote:
> Dnia 2013-07-22, o godz. 00:16:31 hasufell 
> napisał(a):
> 
>> On 07/22/2013 12:07 AM, Duncan wrote:
>>> hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as
>>> excerpted:
>>> 
 solution: Treeclean it and maintain it in an overlay (maybe 
 science-overlay). That's exactly what overlays are for...
 experimental stuff.
>>> 
>>> What's the pros/cons of overlay vs. in-tree-but-masked for
>>> something like this?  In-tree-but-masked is at least available
>>> for those who want it, without having to load an overlay, but I
>>> don't see that discussed at all, here.
>>> 
>> 
>> cons: - users have to run "layman -a foo" ...I hope they will
>> manage (and the masking reason will be updated to explain where
>> to look for googleearth ebuilds)
> 
> Then to get *a single package* they start using the whole overlay.
> If it's a sane overlay, fine. But some overlays really replace a
> lot of stuff silently and trigger failures we didn't even imagine
> before.
> 

No.

I'd either use a separate single-purpose overlay or add it to
science-overlay.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJR7GI8AAoJEFpvPKfnPDWzVrQH/3o8FrgSaCFpWEAJj1qeFpQP
/01wJzMsTV3YWZ9ZqvIZ7txPls+KBlV7hrm0SSNdP5SWO/tdXPllwNu7B+3rdcKN
UOP56hlGtRRT2xw1/M/EWX76+hQmMUSYncMJ5kwqWwWGiKYRgJqR6WYH99igxwSV
7OOewcdU9p56l1MY5TxyH0tG/7KkJADSmYCf6xIK7Lkz1yU9G/e2I1WQsMGVnIBR
TUkV+q1gM9zDwjKtK64X4rA4l2KiTDfoksyBgSelVMYNPcNEGYZgwmrXCJhKZK7B
dYONlBDp/9BG+ihhsNTAXewxsDuVPtXTdFX4dzLciXgGdFw81r+LoNFViH7pRVM=
=4JPG
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Michał Górny]

Dnia 2013-07-22, o godz. 00:16:31
hasufell  napisał(a):

> On 07/22/2013 12:07 AM, Duncan wrote:
> > hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as excerpted:
> > 
> >> solution: Treeclean it and maintain it in an overlay (maybe
> >> science-overlay). That's exactly what overlays are for... experimental
> >> stuff.
> > 
> > What's the pros/cons of overlay vs. in-tree-but-masked for something like 
> > this?  In-tree-but-masked is at least available for those who want it, 
> > without having to load an overlay, but I don't see that discussed at all, 
> > here.
> > 
> 
> cons:
> - users have to run "layman -a foo" ...I hope they will manage (and the
> masking reason will be updated to explain where to look for googleearth
> ebuilds)

Then to get *a single package* they start using the whole overlay. If
it's a sane overlay, fine. But some overlays really replace a lot of
stuff silently and trigger failures we didn't even imagine before.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Diego Elio Pettenò]

On Sun, Jul 21, 2013 at 11:16 PM, hasufell  wrote:

> pros:
> - consistency of tree quality
> - less user confusion (the checksum failures alone get us a lot of bugs
> every release without people realizing what it means...) and people
> expect packages to work in the tree
> - less bugs no one can do anything about
> - easier contribution of users in an overlay, testing of hacks or other
> stuff to make it work
> - making clear that gentoo does not support software with such low QA
> - making clear that this software is experimental
>

Half of those apply also to p.mask'd packages as Duncan pointed out. Maybe
even more than half.


Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[hasufell]

On 07/22/2013 12:07 AM, Duncan wrote:
> hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as excerpted:
> 
>> solution: Treeclean it and maintain it in an overlay (maybe
>> science-overlay). That's exactly what overlays are for... experimental
>> stuff.
> 
> What's the pros/cons of overlay vs. in-tree-but-masked for something like 
> this?  In-tree-but-masked is at least available for those who want it, 
> without having to load an overlay, but I don't see that discussed at all, 
> here.
> 

pros:
- consistency of tree quality
- less user confusion (the checksum failures alone get us a lot of bugs
every release without people realizing what it means...) and people
expect packages to work in the tree
- less bugs no one can do anything about
- easier contribution of users in an overlay, testing of hacks or other
stuff to make it work
- making clear that gentoo does not support software with such low QA
- making clear that this software is experimental

cons:
- users have to run "layman -a foo" ...I hope they will manage (and the
masking reason will be updated to explain where to look for googleearth
ebuilds)

[gentoo-dev] Re: remove sci-geosciences/googleearth from the tree

[Duncan]

hasufell posted on Sun, 21 Jul 2013 17:22:24 +0200 as excerpted:

> solution: Treeclean it and maintain it in an overlay (maybe
> science-overlay). That's exactly what overlays are for... experimental
> stuff.

What's the pros/cons of overlay vs. in-tree-but-masked for something like 
this?  In-tree-but-masked is at least available for those who want it, 
without having to load an overlay, but I don't see that discussed at all, 
here.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Remove eclass/ChangeLog

[Ryan Hill]

On Wed, 23 May 2012 11:02:58 +0300
Samuli Suominen  wrote:

> On 05/23/2012 05:36 AM, Ryan Hill wrote:

> > One person doesn't do entries.  OMG let's remove it!

> absolutely because inconsitency renderess the file useless

Perfect is the enemy of good enough.  Stuck in a cabin for the weekend
without cvs access, it was handy enough for me.

When we switch to git 4-8 years from now, then yes, kill it.  Until then,
leave it alone please.


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Remove eclass/ChangeLog

[Markos Chandras]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/23/2012 05:46 PM, Michał Górny wrote:
> On Wed, 23 May 2012 12:29:34 -0400 Rich Freeman 
> wrote:
> 
>> On Wed, May 23, 2012 at 4:02 AM, Samuli Suominen 
>>  wrote:
>>> On 05/23/2012 05:36 AM, Ryan Hill wrote:
 One person doesn't do entries.  OMG let's remove it!
 
>>> 
>>> absolutely because inconsitency renderess the file useless
>>> 
>> 
>> Well, for now the solution is to enforce following policy.
>> 
>> For the future, perhaps the policy's time has ended.  Sure,
>> Changelogs can be handy, but they are increasingly redundant and
>> scm comments have the potential to be far more useful.  By all
>> means require meaningful scm commit comments, but if Changelog
>> files are holding us back either auto-generate them or ditch
>> them.
> 
> ChangeLogs could be fine for ebuilds. But for more broad cases
> like eclasses, one can usually have a set of changes prepared for
> commit. With CVS, it's PITA but with git it's already much better.
> Of course, it all fails if every commit has to update a randomly
> changed, shared file called ChangeLog...
> 

So we did we introduce changelogs for eclass/ in the first place if
everyone is happy with getting rid of them?

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBCgAGBQJPvSyUAAoJEPqDWhW0r/LCrp0QAIwYhxeO5qeYaCrh3B7WCd3X
pt8cMAquC38VOIjfd+Lz+iG2+8ftYb1s5xQu52F6zZEkbwxCLmYBKJrnpNljSm8T
QAmB4xXg4vKxjpwAyc+fOev53HZdQyzav36m1DhOEXZKixI+OR1MplZ55VlEAT0+
wRPJj9+WsiTMONRkuukCCJtvnY1kDjJLtjNDzUA4QSxh+pgcgAPGoDMh5nL706h5
KW5/jBTW01+oEWyBosXxBUoX8p2/FvAG1Meib0BbEBdsyrYdQSDJK2xMjK0JJ7PH
QhOeA2NameaFA1YzvebB7KDNSGB3zMm1TdnYmhfU1jmWImyB1BQvdFT37KcvZagQ
WhErwHxDojz27lhiCHY95nPDATMxxiC61WdBLoByV93xRAqwnpeSva26hV1Nv552
n3nZ5DWCKRF+qSSEo1Oz3DCtDxV5ygyOw8iHOhqhZ5IcuNIchfYgss/dCFRRy3zy
uN8l/wge7J0MjOVKBnpT9nWmmwhB4pD+o3Avq2OBwuDrqAW7iYKkTPzQwsIq7ZGI
HTvtMhOrULIkm/2c77FGXdFwJWMPueroUe4LntY/0c2l30P2Fafe0sEp5yCjzCeA
uXwWC0iWTPuVBYGFJQ5iZqB3X+LAVWz2HLpqZRJ9qW4X3QXSuXsrr5wdAukjAUCu
8qMUNncYeLeHvdeazWey
=/lXi
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Remove eclass/ChangeLog

[Michał Górny]

On Wed, 23 May 2012 12:29:34 -0400
Rich Freeman  wrote:

> On Wed, May 23, 2012 at 4:02 AM, Samuli Suominen
>  wrote:
> > On 05/23/2012 05:36 AM, Ryan Hill wrote:
> >> One person doesn't do entries.  OMG let's remove it!
> >>
> >
> > absolutely because inconsitency renderess the file useless
> >
> 
> Well, for now the solution is to enforce following policy.
> 
> For the future, perhaps the policy's time has ended.  Sure, Changelogs
> can be handy, but they are increasingly redundant and scm comments
> have the potential to be far more useful.  By all means require
> meaningful scm commit comments, but if Changelog files are holding us
> back either auto-generate them or ditch them.

ChangeLogs could be fine for ebuilds. But for more broad cases like
eclasses, one can usually have a set of changes prepared for commit.
With CVS, it's PITA but with git it's already much better. Of course,
it all fails if every commit has to update a randomly changed, shared
file called ChangeLog...

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Remove eclass/ChangeLog

[Rich Freeman]

On Wed, May 23, 2012 at 4:02 AM, Samuli Suominen  wrote:
> On 05/23/2012 05:36 AM, Ryan Hill wrote:
>> One person doesn't do entries.  OMG let's remove it!
>>
>
> absolutely because inconsitency renderess the file useless
>

Well, for now the solution is to enforce following policy.

For the future, perhaps the policy's time has ended.  Sure, Changelogs
can be handy, but they are increasingly redundant and scm comments
have the potential to be far more useful.  By all means require
meaningful scm commit comments, but if Changelog files are holding us
back either auto-generate them or ditch them.

And, to add my own to cents to this chain about the only thing worse
than failing to directly inherit an eclass dependency is to break the
tree fixing the problem on personal initiative.  When a dev messes up
the solution is to talk to them or if necessary talk to devrel/QA -
not to break end-user systems.

Rich

Re: [gentoo-dev] Re: Remove eclass/ChangeLog

[Samuli Suominen]

On 05/23/2012 05:36 AM, Ryan Hill wrote:

On Sun, 20 May 2012 15:33:11 +0300
Samuli Suominen  wrote:


ChangeLog entries missing for every autotools.eclass modification today.

On 05/20/2012 03:31 PM, Mike Frysinger (vapier) wrote:

vapier  12/05/20 12:31:33


One person doesn't do entries.  OMG let's remove it!




absolutely because inconsitency renderess the file useless

[gentoo-dev] Re: Remove eclass/ChangeLog (was: Re: [gentoo-commits] gentoo-x86 commit in eclass: autotools.eclass)

[Ryan Hill]

On Sun, 20 May 2012 15:33:11 +0300
Samuli Suominen  wrote:

> ChangeLog entries missing for every autotools.eclass modification today.
> 
> On 05/20/2012 03:31 PM, Mike Frysinger (vapier) wrote:
> > vapier  12/05/20 12:31:33

One person doesn't do entries.  OMG let's remove it!


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Remove package from system set in custom profile

[Canek Peláez Valdés]

On Thu, Feb 16, 2012 at 10:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Canek Peláez Valdés posted on Thu, 16 Feb 2012 19:26:22 -0600 as
> excerpted:
>
>> Hi; I'm trying to make a custom profile, and I need to remove a package
>> from the system set. Is there a way I can do this without editing
>> /usr/portage/profiles/base/packages?
>>
>> Sorry if this is the wrong place for asking such a question.
>
> FWIW, gentoo-dev is for development related questions.  The right place
> would be the gentoo-user list.  Not really right but better than the
> general gentoo-dev list would be the portage-devel list.

I would have that in mind next time.

> Never-the-less and not to send you away empty-handed, yes of course
> there's a way to override it locally.  Gentoo wouldn't be gentoo
> otherwise. =:^)
>
> See the portage (5) manpage, in particular, a search on
> "/etc/portage/profile" in that manpage, plus the note under the packages
> file description (in the /etc/make.profile/ section) about removing
> packages from the system set.
>
> More specifically, here's my /etc/portage/profile/packages:
>
> # I don't need these
> -*sys-apps/busybox
> -*sys-apps/module-init-tools
>
> If the package is listed as a dependency somewhere as well, you may need
> to add an entry to packages.provided in the same dir, as well.  For
> example, from mine (I build everything I need into the kernel,
> no kernel modules so no module-init-tools needed to load them, either):
>
> sys-apps/module-init-tools-

That's exactly what I needed. Thanks.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

[gentoo-dev] Re: Remove package from system set in custom profile

[Duncan]

Canek Peláez Valdés posted on Thu, 16 Feb 2012 19:26:22 -0600 as
excerpted:

> Hi; I'm trying to make a custom profile, and I need to remove a package
> from the system set. Is there a way I can do this without editing
> /usr/portage/profiles/base/packages?
> 
> Sorry if this is the wrong place for asking such a question.

FWIW, gentoo-dev is for development related questions.  The right place 
would be the gentoo-user list.  Not really right but better than the 
general gentoo-dev list would be the portage-devel list.  

Never-the-less and not to send you away empty-handed, yes of course 
there's a way to override it locally.  Gentoo wouldn't be gentoo 
otherwise. =:^)

See the portage (5) manpage, in particular, a search on
"/etc/portage/profile" in that manpage, plus the note under the packages 
file description (in the /etc/make.profile/ section) about removing 
packages from the system set.

More specifically, here's my /etc/portage/profile/packages:

# I don't need these
-*sys-apps/busybox
-*sys-apps/module-init-tools

If the package is listed as a dependency somewhere as well, you may need 
to add an entry to packages.provided in the same dir, as well.  For 
example, from mine (I build everything I need into the kernel,
no kernel modules so no module-init-tools needed to load them, either):

sys-apps/module-init-tools-

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Remove package from system set in custom profile

[Canek Peláez Valdés]

On Thu, Feb 16, 2012 at 7:26 PM, Canek Peláez Valdés  wrote:
> Hi; I'm trying to make a custom profile, and I need to remove a
> package from the system set. Is there a way I can do this without
> editing /usr/portage/profiles/base/packages?

I see now that I can copy the whole /usr/portage/profiles dir to my
overlay, edit base/packages there, and link /etc/make.profile to the
profile in my overlay. This has several drawbacks:

1. I need to keep in syncro the profiles dir in my overlay to the one
in the portage tree.
2. I probably don't need a whole copy of /usr/portage/profiles.
3. It sure is ugly as hell.

Is there a better way to do it?

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

[gentoo-dev] Re: REMOVE

[Duncan]

Stelios Boulios posted on Tue, 28 Jun 2011 09:51:41 +0300 as excerpted:

[blank, see subject]

See the headers for any post forwarded by this list.
They all contain the following information:

List-Post: 
List-Help: 
List-Unsubscribe: 
List-Subscribe: 
List-Id: Gentoo Linux mail 

It would appear that you want to mail the address in List-Unsubscribe 
(you missed the +unsubscribe bit).  Be sure to watch for the confirming 
unsubscribe mail and confirm it as required.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Remove "dev"-status of mips profiles

[Torsten Veller]

* Ryan Hill :
> Torsten Veller  wrote:
> > * Torsten Veller :
> > > Can we please move the mips profiles from "dev" to "exp" in
> > > profiles/profiles.desc?
> > 
> > Based on the current feedback I'll change it not earlier than friday
> > next week if nobody objects.
> 
> Did you get feedback from anyone on m...@?

No, I don't think so. Nonetheless mips was CC'ed on the last mail.

I also got no reply to the keywording bugs waiting for mips.
-- 
Thanks

[gentoo-dev] Re: Remove "dev"-status of mips profiles

[Ryan Hill]

On Thu, 25 Feb 2010 11:30:32 +0100
Torsten Veller  wrote:

> * Torsten Veller :
> > Can we please move the mips profiles from "dev" to "exp" in
> > profiles/profiles.desc?
> 
> Based on the current feedback I'll change it not earlier than friday
> next week if nobody objects.

Did you get feedback from anyone on m...@?


-- 
fonts,by design, by neglect
gcc-porting,  for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Remove "dev"-status of mips profiles

[Robin H. Johnson]

On Thu, Feb 25, 2010 at 05:24:25PM +0200, Samuli Suominen wrote:
> Every machine type profile has a developer, desktop and server sub profile.
> 
> How about deleting those? If you are capable of setting up a Gentoo/MIPS
> setup, then you are certainly capable of setting up few profile defaults
> on your own too.
Or better yet, you can stack your own mix of profiles:
# rm /etc/make.profile
# mkdir /etc/make.profile
# cat >/etc/make.profile/parent <

pgppkM9MCOZkK.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Remove "dev"-status of mips profiles

[Samuli Suominen]

On 02/25/2010 05:14 PM, Mark Loeser wrote:
> Torsten Veller  said:
>> * Torsten Veller :
>>> Can we please move the mips profiles from "dev" to "exp" in
>>> profiles/profiles.desc?
>>
>> Based on the current feedback I'll change it not earlier than friday
>> next week if nobody objects.
> 
> That would be nice.  I'd also love to know why we need about 150
> different profiles for MIPS...
> 

Every machine type profile has a developer, desktop and server sub profile.

How about deleting those? If you are capable of setting up a Gentoo/MIPS
setup, then you are certainly capable of setting up few profile defaults
on your own too.

See attached patch
--- profiles.desc.orig  2010-02-25 17:19:46.0 +0200
+++ profiles.desc   2010-02-25 17:21:34.0 +0200
@@ -44,158 +44,41 @@
 m68kdefault/linux/m68k/10.0/server  dev
 
 # MIPS Profiles
-mipsdefault/linux/mips/10.0/cobalt/desktop 
 dev
-mipsdefault/linux/mips/10.0/cobalt/developer   
 dev
-mipsdefault/linux/mips/10.0/cobalt/n32/desktop 
 dev
-mipsdefault/linux/mips/10.0/cobalt/n32/developer   
 dev
-mipsdefault/linux/mips/10.0/cobalt/n32/server  
 dev
 mipsdefault/linux/mips/10.0/cobalt/n32 
 dev
-mipsdefault/linux/mips/10.0/cobalt/n64/desktop 
 dev
-mipsdefault/linux/mips/10.0/cobalt/n64/developer   
 dev
-mipsdefault/linux/mips/10.0/cobalt/n64/server  
 dev
 mipsdefault/linux/mips/10.0/cobalt/n64 
 dev
-mipsdefault/linux/mips/10.0/cobalt/server  
 dev
 mipsdefault/linux/mips/10.0/cobalt 
 dev
-mipsdefault/linux/mips/10.0/desktop
 dev
-mipsdefault/linux/mips/10.0/developer  
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/desktop
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/developer  
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/desktop 
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/developer   
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n32/desktop 
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n32/developer   
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n32/server  
 dev
 mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n32 
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n64/desktop 
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n64/developer   
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n64/server  
 dev
 mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/n64 
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/fulong/server  
 dev
 mipsdefault/linux/mips/10.0/lemote/lm2e/fulong 
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/n32/desktop
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/n32/developer  
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/n32/server 
 dev
 mipsdefault/linux/mips/10.0/lemote/lm2e/n32
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/n64/desktop
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/n64/developer  
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/n64/server 
 dev
 mipsdefault/linux/mips/10.0/lemote/lm2e/n64
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2e/server 
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2f/desktop
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2f/developer  
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2f/n32/desktop
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2f/n32/developer  
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2f/n32/server 
 dev
 mipsdefault/linux/mips/10.0/lemote/lm2f/n32
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2f/n64/desktop
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2f/n64/developer  
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2f/n64/server 
 dev
 mipsdefault/linux/mips/10.0/lemote/lm2f/n64
 dev
-mipsdefault/linux/mips/10.0/lemote/lm2f/server  

Re: [gentoo-dev] Re: Remove "dev"-status of mips profiles

[Mark Loeser]

Torsten Veller  said:
> * Torsten Veller :
> > Can we please move the mips profiles from "dev" to "exp" in
> > profiles/profiles.desc?
> 
> Based on the current feedback I'll change it not earlier than friday
> next week if nobody objects.

That would be nice.  I'd also love to know why we need about 150
different profiles for MIPS...

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com

[gentoo-dev] Re: Remove "dev"-status of mips profiles

[Torsten Veller]

* Torsten Veller :
> Can we please move the mips profiles from "dev" to "exp" in
> profiles/profiles.desc?

Based on the current feedback I'll change it not earlier than friday
next week if nobody objects.

-- 
Thanks

Re: [gentoo-dev] Re: Remove "dev"-status of mips profiles

[Brian Harring]

On Thu, Feb 11, 2010 at 10:12:44PM +0100, Christian Faulhammer wrote:
> Hi,
> 
> Jeremy Olexa :
> > I would guess that it would be far easier to work in an overlay at
> > this point. I would also guess that if there are ANY mips users out
> > there that they would have to use some other ACCEPT_KEYWORDS value
> > because the shape of ~mips is so...bad.
> 
>  Don't remove an architecture.  Ask vapier what it means to reintroduce
> it.  Even if it rots, mark it as unmaintained and wait for someone to
> pick-up.

I question if this will hold true when gentoo-x86 goes git; at the 
very least folding an arch back into mainline should be a helluva lot 
easier.

Anyone got any comments on similar attempts?
~harring


pgpqbjLufTbxO.pgp
Description: PGP signature

[gentoo-dev] Re: Remove "dev"-status of mips profiles

[Christian Faulhammer]

Hi,

Jeremy Olexa :
> I would guess that it would be far easier to work in an overlay at
> this point. I would also guess that if there are ANY mips users out
> there that they would have to use some other ACCEPT_KEYWORDS value
> because the shape of ~mips is so...bad.

 Don't remove an architecture.  Ask vapier what it means to reintroduce
it.  Even if it rots, mark it as unmaintained and wait for someone to
pick-up.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

http://gentoo.faulhammer.org/>


signature.asc
Description: PGP signature

[gentoo-dev] Re: Remove "dev"-status of mips profiles

[Christian Faulhammer]

Hi,

Torsten Veller :

> Can we please move the mips profiles from "dev" to "exp" in
> profiles/profiles.desc?

 Agreement here.  Maybe a restart on non-obsolete MIPS hardware (read
Loongson instead of SGI) would be great.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

http://gentoo.faulhammer.org/>


signature.asc
Description: PGP signature

[gentoo-dev] Re: Remove global USE flag tetex

[Christian Faulhammer]

Andrey Grozin <[EMAIL PROTECTED]>:

> On Wed, 3 Sep 2008, Christian Faulhammer wrote:
> > there should be no more packages in the tree that have USE=tetex, so
> > this global USE flag can be removed.  Any opinions?
> Great.
> 
> The following packages still depend on virtual/tetex:

 Which is no showstopper for the removal of the USE flag...for everyone
else, the tracker bug for phasing out virtual/tetex is bug 222501,
any help is appreciated.
 
> [EMAIL PROTECTED]:
> x11-plugins/pidgin-latex

 Already fixed.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

http://www.faulhammer.org/>


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: remove my address

[Alin Nastac]

David Shakaryan wrote:
> George Prowse wrote:
>   
>> Mike Frysinger wrote:
>> 
>>> On Wednesday 25 October 2006 01:53, Drake Wyrm wrote:
>>>   
 I think someone is yanking your chain, vapier.
 
>>> i doubt it ... other people on irc mentioned receiving said e-mail as
>>> well
>>>
>>>   
>> Haven't seen said email here...
>> 
>
> From my understanding, it wasn't sent to the actual mailing list, but to
> a few specific @gentoo.org addresses.
>
>   
Infra team, please block anything from [EMAIL PROTECTED] I could do
it for my mailbox, but since there are many of us spammed by that moron,
I think it would be best to block it on mail from SMTP command.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: remove my address

[David Shakaryan]

George Prowse wrote:
> Mike Frysinger wrote:
>> On Wednesday 25 October 2006 01:53, Drake Wyrm wrote:
>>> I think someone is yanking your chain, vapier.
>>
>> i doubt it ... other people on irc mentioned receiving said e-mail as
>> well
>>
> 
> Haven't seen said email here...

From my understanding, it wasn't sent to the actual mailing list, but to
a few specific @gentoo.org addresses.

-- 
David Shakaryan
GnuPG Public Key: 0x4B8FE14B



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: remove my address

[George Prowse]

Mike Frysinger wrote:

On Wednesday 25 October 2006 01:53, Drake Wyrm wrote:

I think someone is yanking your chain, vapier.


i doubt it ... other people on irc mentioned receiving said e-mail as well



Haven't seen said email here...

George
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: remove my address

[Drake Wyrm]

Mike Frysinger <[EMAIL PROTECTED]> wrote:
> stop spamming this shit and go read the mailing list page like i said
> already: http://www.gentoo.org/main/en/lists.xml -mike

I think someone is yanking your chain, vapier. You're replying to a
message that I didn't see on the list. Also, while this reply was only
Cc'ed to gentoo-dev, you sent that last one to twelve different
addresses, including .

-- 
Every absurdity has a champion to defend it.
  -- Oliver Goldsmith


pgpgvAnzLRhIH.pgp
Description: PGP signature

[gentoo-dev] Re: remove my address

[Mike Frysinger]

stop spamming this shit and go read the mailing list page like i said already:
http://www.gentoo.org/main/en/lists.xml
-mike


pgpfLyWPE49l3.pgp
Description: PGP signature

[gentoo-dev] Re: remove my address

[Mike Frysinger]

read the goddamn mailing list page for how to unsubscribe *yourself*
-mike


pgpPKfrfwYOZb.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Remove your modular X unmask

[Donnie Berkholz]

Duncan wrote:

Is it worth posting bugs on these yet?  Gentoo or upstream?  Any tracker
bug to point me at?  (I have the binpkgs so can remerge them for
additional testing with little trouble, if necessary.)


Yes, and they are most likely upstream bugs. Two things to do before 
posting a bug:

1) Make sure you're using drivers known to be compatible with 1.0.99.
2) Check out your X log for errors.
3) For the RandR bugs, see whether running xrandr allows you to change 
resolutions, and make sure your XKB is working (setxkbmap -print).



It's impressive enough to have me eagerly awaiting the next rc.  Good work
both here and upstream!  Is the proposed schedule on the wiki at
desktop.org still valid? A couple more RCs, and release in about a month
if all goes well?


Sounds pretty reasonable.

Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Remove your modular X unmask

[Mart Raudsepp]

On Thu, 2006-04-20 at 07:05 -0700, Duncan wrote:
> * Overlay was doing strange thing.  In this case it was SDL overlay as
> used by dosbox -- I tried rebuilding both libsdl and dosbox, but the
> overlay still failed.  Maybe related to the ABI change?

SDL is being dumb with alpha visuals here.
Need XLIB_SKIP_ARGB_VISUALS=1 env var for SDL apps if a composite
manager is running. That's for SDL apps, giving that to everything would
defeat the purpose of the composite manager quite a bit, I think.

I'll have to pass commenting on anything else. Not sure about the other
points and don't want to express guesses :)

> It's impressive enough to have me eagerly awaiting the next rc. Good work
> both here and upstream!

Indeed!

> Is the proposed schedule on the wiki at desktop.org still valid?

I think ajax is getting out his whip soon, if he hasn't already :P
The schedule should be pretty accurate on xorg.fd.org wiki.

> A couple more RCs, and release in about a month
> if all goes well?

-- 
With regards,
Mart Raudsepp

Project manager of wxMUD  - http://wxmud.sourceforge.net/
Developer of wxWidgets- http://www.wxwidgets.org/
GTK+ port maintainer of OMGUI - http://www.omgui.org/

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Remove your modular X unmask

[Duncan]

Donnie Berkholz posted <[EMAIL PROTECTED]>, excerpted below,  on
Wed, 19 Apr 2006 22:08:54 -0700:

> This is a reminder to everybody that now modular X is in ~arch, you need
> to REMOVE YOUR MODULAR X UNMASK.
> 
> We're getting lots of issues because people aren't doing this and are
> getting package.mask'd versions of programs because they forgot about it.
> 
> In particular, xorg-server 1.0.99 has an ABI break, which breaks all
> Nvidia and ATI binary drivers.

FWIW, I played with xorg-server 1.0.99 and the new ATI drivers (Radeon
9250, dual monitor in merged framebuffer mode, on amd64, compiled with
gcc-4.1.0) for about 12 hours yesterday. There's some really nice
improvements coming (with Option AccelMethod "EXA", the CPU cost of
composite transparency/shadows/fading is virtually zero, and EXA is far
more stable than in current ~arch), but as might be expected with an early
release candidate, there's still enough issues that I eventually reverted
back to ~arch, which now seems slow and CPU hungry with
composite/transparency on, dull and stuffy without! 

In particular:

* The zoom hotkeys (CTRL-ALT-PLUS/MINUS) didn't work at all -- I had to
use krandrtray which isn't the same since it shrinks the virtual desktop,
not just the viewport.

* krandrtray failed to restore a full sized desktop in some cases (this
may be due to an error in the log I saw -- from memory so isn't exact,
failed to allocate backup/restore memory, display may get corrupted)

* Overlay was doing strange thing.  In this case it was SDL overlay as
used by dosbox -- I tried rebuilding both libsdl and dosbox, but the
overlay still failed.  Maybe related to the ABI change?

* General instability, with both EXA and XAA.  Not entirely unexpected at
this point, and EXA is /vastly/ improved over  both the current ~arch
version and XAA (new and ~arch) efficiency-wise.

Is it worth posting bugs on these yet?  Gentoo or upstream?  Any tracker
bug to point me at?  (I have the binpkgs so can remerge them for
additional testing with little trouble, if necessary.)

It's impressive enough to have me eagerly awaiting the next rc.  Good work
both here and upstream!  Is the proposed schedule on the wiki at
desktop.org still valid? A couple more RCs, and release in about a month
if all goes well?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: remove

[Kumba]

Mike Frysinger wrote:


we know it's retarded, but not everyone is a ninja ... no reason to rant about 
it


/me drags from the pile of dead conversations

But it's easy to become a Ninja, all you need is a simple t-shirt:
http://homepage.ntlworld.com/philbooth/How_To_Be_A_Ninja.jpg


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: remove

[Mike Frysinger]

On Wednesday 10 August 2005 04:15 pm, Duncan wrote:
> Eric Clapprood posted
> <[EMAIL PROTECTED]>,
>
> excerpted below,  on Wed, 10 Aug 2005 11:53:25 -0400:
> >   > xmlns:w="urn:schemas-microsoft-com:office:word"
> > xmlns="http://www.w3.org/TR/REC-html40";>
>
> Wow!  Perfect demonstration of the technical literacy both of those that
> post "remove" instructions to mailing lists, and of those that post using
> not only HTML, but some MS mangled version of same!

we know it's retarded, but not everyone is a ninja ... no reason to rant about 
it

Eric: visit http://www.gentoo.org/main/en/lists.xml
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: remove

[Henrik Brix Andersen]

On Wed, 2005-08-10 at 13:15 -0700, Duncan wrote:
> Wow!
[snip]

Next time please ask yourself - is this e-mail really necessary?

./Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


signature.asc
Description: This is a digitally signed message part

RE: [gentoo-dev] Re: remove....IN TEXT ONLY FORMAT

[Eric Clapprood]

Hey Duncan,

Thanks for taking the time to provide me with your paragraph of wisdom.
What's a mail Header?

jk

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Duncan
Sent: Wednesday, August 10, 2005 4:15 PM
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: remove

Eric Clapprood posted
<[EMAIL PROTECTED]>,
excerpted below,  on Wed, 10 Aug 2005 11:53:25 -0400:

>   xmlns:w="urn:schemas-microsoft-com:office:word"
> xmlns="http://www.w3.org/TR/REC-html40";>

Wow!  Perfect demonstration of the technical literacy both of those that
post "remove" instructions to mailing lists, and of those that post
using
not only HTML, but some MS mangled version of same!

A hint, Eric, if you are reading this.  Look in the mail headers for
unsubscribe instructions, or go to the same site you used to subscribe,
and read them there.

If you don't know how to read mail headers, and don't remember which
site
you used to subscribe, well...  click on the "lists" link at gentoo.org,
taking you to the lists page, with... surprise! instructions for
subscribing and unsubscribing from the lists! Amazing how you find the
unsubscribe instructions for a Gentoo list, under the lists link on the
Gentoo site, isn't it?  It's not as if you go to an MS Office site, or
one
for the Interior ministry of China, or something, to find instructions
for
unsubscribing from a Gentoo list.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: remove

[Duncan]

Eric Clapprood posted
<[EMAIL PROTECTED]>,
excerpted below,  on Wed, 10 Aug 2005 11:53:25 -0400:

>   xmlns:w="urn:schemas-microsoft-com:office:word"
> xmlns="http://www.w3.org/TR/REC-html40";>

Wow!  Perfect demonstration of the technical literacy both of those that
post "remove" instructions to mailing lists, and of those that post using
not only HTML, but some MS mangled version of same!

A hint, Eric, if you are reading this.  Look in the mail headers for
unsubscribe instructions, or go to the same site you used to subscribe,
and read them there.

If you don't know how to read mail headers, and don't remember which site
you used to subscribe, well...  click on the "lists" link at gentoo.org,
taking you to the lists page, with... surprise! instructions for
subscribing and unsubscribing from the lists! Amazing how you find the
unsubscribe instructions for a Gentoo list, under the lists link on the
Gentoo site, isn't it?  It's not as if you go to an MS Office site, or one
for the Interior ministry of China, or something, to find instructions for
unsubscribing from a Gentoo list.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list