Re: [gentoo-dev] Changes in server profiles

[Markos Chandras]

Patch applied but only for amd64 profile.

@x86: feel free to adjust your profile too.
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411  3477 F7F7 1E8E 441A C410


pgpSlGrsGoXJW.pgp
Description: PGP signature

[gentoo-dev] [warning] the bug queue has 111 bugs

[Alex Alexander]

Our bug queue has 111 bugs!

If you have some spare time, please help assign/sort a few bugs.

Thanks!

Re: [gentoo-dev] [warning] the bug queue has 111 bugs

[Paweł Hajdan, Jr.]

On 11/14/10 1:00 PM, Alex Alexander wrote:
> If you have some spare time, please help assign/sort a few bugs.

I have another great idea for you. People are lazy, so could you make
the warning message include a direct link to the "Bug Wranglers" queue?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [warning] the bug queue has 111 bugs

[Alex Alexander]

On Sun, Nov 14, 2010 at 01:10:26PM +0100, "Paweł Hajdan, Jr." wrote:
> On 11/14/10 1:00 PM, Alex Alexander wrote:
> > If you have some spare time, please help assign/sort a few bugs.
> 
> I have another great idea for you. People are lazy, so could you make
> the warning message include a direct link to the "Bug Wranglers" queue?
> 

OK, link added
http://bit.ly/bsHeJt

Thanks :)
-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com


pgpHs1antwgQh.pgp
Description: PGP signature

[gentoo-dev] Lastrite: sys-apps/slocate

[Samuli Suominen]

# Samuli Suominen  (14 Nov 2010)
# No longer developed and replaced by sys-apps/mlocate
# Bug 338380
# Removal in 30 days
sys-apps/slocate

[gentoo-dev] Disabling auto-bumping of active Python version

[Sebastian Pipping]

Hello,

thanks for your interest.  This thread is not about Python 3.x in
particular, in case you wonder.


In this mail

- Typical GCC update  (for comparison)
- Python 2.7 update simulation  (and how it fails)
  - The scenario
  - What happens
  - How it happens
- Conclusion


Typical GCC update
==
Before we look at Python, let's have a look at how it works with GCC:

  When a new version of GCC appears in Gentoo, it is installed into
  a new slot.  To activate the new version, you run gcc-config.
  In the meantime your system is in working state and continues to
  use the old version of GCC.


Python 2.7 update simulation


The scenario

With Python it's very different.  Let's assume a system with Python 2.6
as the only Python around.  Now we would like to run this command:

  # sudo emerge dev-lang/python:2.7 dev-python/pyinotify

Assume that dev-lang/python:2.7 is unmasked already.
The resulting system state now depends on these two factors:

 - Has pyinotify been installed to the system before our invocation of
   emerge?  Depending on that, pyinotify may be installed first, or
   python 2.7 may.   Let's assume pyinotify comes last.  The difference
   is marginal.

 - Were we using USE_PYTHON in /etc/make.conf (e.g. USE_PYTHON="2.6")
   or not?  I'll assume USE_PYTHON is not set manually and implied
   during installation.  The last three devs I spoke to had not heard
   of variable USE_PYTHON, so that assumption may work.


What happens

Steps taken by emerge:
- Python 2.7 installed
- Python 2.7 is made the active version of Python automatically
- pyinotify is installed for Python ABI 2.7 (neither 2.6 nor both)

Resulting system state:
- Python 2.7 now is the main active version of Python
- All Python packages except pyinotify are installed for Python ABI 2.6
- pyinotify is the only package installed for Python ABI 2.7
- before running python-updater larger parts of the system may be
  unusable


How it happens
--
All dev-lang/python ebuilds run a Bash function called
"eselect_python_update" at the beginning pkg_postinst stage.
Former function wraps a call to

  eselect python update ${eselect_python_options}


Conclusion
==
When you update GCC your system stays at a healthy state.
You trigger the switch of active versions.

With Python, when you install a newer version if gets activated, leaving
your system in broken state.  An update of Python always involves
running python-updater.  If the user/admin has to run that anyway, why
should we take the call to eselect python off his shoulders, especially
we break the system doing so?

So I plan to remove the call to eselect_python_update from all Python
ebuilds in two weeks from now.  Besides Arfrever everybody I spoke to on
this topic so far agreed to this approach.  The two weeks window are to
give people room to think and discuss about it.

Please try to keep this thread as low-heat as possible.
Thanks for reading.



Sebastian

[gentoo-dev] Re: Disabling auto-bumping of active Python version

[Jesus Rivero (Neurogeek)]

+1

I totally agree with the conclusion. I believe that choice, "select
the active version of Python", should not be implied by us, but taken
by the user even if he explicitly asked for a new version to be
installed.

I've been in this situation before, and just because I wanted to try
some new cool features, sometimes I ended up with a semi broken system
just because I wouldn't take extra care with it.

Plus I think users are going to miss that feature much.

Best regards,

Jesus

On 11/14/10, Sebastian Pipping  wrote:
> Hello,
>
> thanks for your interest.  This thread is not about Python 3.x in
> particular, in case you wonder.
>
>
> In this mail
> 
> - Typical GCC update  (for comparison)
> - Python 2.7 update simulation  (and how it fails)
>   - The scenario
>   - What happens
>   - How it happens
> - Conclusion
>
>
> Typical GCC update
> ==
> Before we look at Python, let's have a look at how it works with GCC:
>
>   When a new version of GCC appears in Gentoo, it is installed into
>   a new slot.  To activate the new version, you run gcc-config.
>   In the meantime your system is in working state and continues to
>   use the old version of GCC.
>
>
> Python 2.7 update simulation
> 
>
> The scenario
> 
> With Python it's very different.  Let's assume a system with Python 2.6
> as the only Python around.  Now we would like to run this command:
>
>   # sudo emerge dev-lang/python:2.7 dev-python/pyinotify
>
> Assume that dev-lang/python:2.7 is unmasked already.
> The resulting system state now depends on these two factors:
>
>  - Has pyinotify been installed to the system before our invocation of
>emerge?  Depending on that, pyinotify may be installed first, or
>python 2.7 may.   Let's assume pyinotify comes last.  The difference
>is marginal.
>
>  - Were we using USE_PYTHON in /etc/make.conf (e.g. USE_PYTHON="2.6")
>or not?  I'll assume USE_PYTHON is not set manually and implied
>during installation.  The last three devs I spoke to had not heard
>of variable USE_PYTHON, so that assumption may work.
>
>
> What happens
> 
> Steps taken by emerge:
> - Python 2.7 installed
> - Python 2.7 is made the active version of Python automatically
> - pyinotify is installed for Python ABI 2.7 (neither 2.6 nor both)
>
> Resulting system state:
> - Python 2.7 now is the main active version of Python
> - All Python packages except pyinotify are installed for Python ABI 2.6
> - pyinotify is the only package installed for Python ABI 2.7
> - before running python-updater larger parts of the system may be
>   unusable
>
>
> How it happens
> --
> All dev-lang/python ebuilds run a Bash function called
> "eselect_python_update" at the beginning pkg_postinst stage.
> Former function wraps a call to
>
>   eselect python update ${eselect_python_options}
>
>
> Conclusion
> ==
> When you update GCC your system stays at a healthy state.
> You trigger the switch of active versions.
>
> With Python, when you install a newer version if gets activated, leaving
> your system in broken state.  An update of Python always involves
> running python-updater.  If the user/admin has to run that anyway, why
> should we take the call to eselect python off his shoulders, especially
> we break the system doing so?
>
> So I plan to remove the call to eselect_python_update from all Python
> ebuilds in two weeks from now.  Besides Arfrever everybody I spoke to on
> this topic so far agreed to this approach.  The two weeks window are to
> give people room to think and discuss about it.
>
> Please try to keep this thread as low-heat as possible.
> Thanks for reading.
>
>
>
> Sebastian
>
>

-- 
Sent from my mobile device

Jesus Rivero
Gentoo Python Team

Re: [gentoo-dev] [warning] the bug queue has 111 bugs

[Alexis Ballier]

On Sunday 14 November 2010 09:45:04 Alex Alexander wrote:
> On Sun, Nov 14, 2010 at 01:10:26PM +0100, "Paweł Hajdan, Jr." wrote:
> > On 11/14/10 1:00 PM, Alex Alexander wrote:
> > > If you have some spare time, please help assign/sort a few bugs.
> > 
> > I have another great idea for you. People are lazy, so could you make
> > the warning message include a direct link to the "Bug Wranglers" queue?
> 
> OK, link added
> http://bit.ly/bsHeJt

could you please include a link pointing to https:// ?

A.

[gentoo-dev] News item: Dropping Java support on ia64

[Petteri Räty]

Any improvements to the text are welcome.

Regards,
Petteri
Title: Pending Removal of Java support in ia64
Author: Petteri Räty 
Author: IA64 Arch Team 
Content-Type: text/plain
Posted: 2010-11-14
Revision: 1
News-Item-Format: 1.0
Display-If-Keyword: ia64
Display-If-Installed: dev-java/java-config

The IA64 arch team does not have the resources to maintain Java support so we
agreed that support will be dropped unless more man power becomes available.
If you are willing to help maintaining support please contact i...@gentoo.org.
If there is no interest the removal of Java support well be done during week
50 of year 2010.

The removal is tracked in bug #345433.


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News item: Dropping Java support on ia64

[Paweł Hajdan, Jr.]

On 11/14/10 8:36 PM, Petteri Räty wrote:
> The IA64 arch team does not have the resources to maintain Java support so we
> agreed that support will be dropped unless more man power becomes available.

Could you also add the info to
 ?

Moreover, what does dropping support mean? Are there any packages that
are not obviously java-related (i.e. not in dev-java), but will have
dropped support?

> If you are willing to help maintaining support please contact i...@gentoo.org.
> If there is no interest the removal of Java support well be done during week
> 50 of year 2010.

IMHO a date range would be more readable than a week number.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News item: Dropping Java support on ia64

[Alistair Bush]

> Any improvements to the text are welcome.

I think the following could be written clearer.   Reading it made me have to 
go off and check what week 50 was.

"If there is no interest the removal of Java support well be done during week
50 of year 2010."

why not say

'If there is no interest the removal of Java support well be done during the 
week starting 13th Dec 2010."

(please confirm the date on that)

> 
> Regards,
> Petteri

Re: [gentoo-dev] News item: Dropping Java support on ia64

[Nirbheek Chauhan]

On Mon, Nov 15, 2010 at 1:16 AM, Alistair Bush  wrote:
>> Any improvements to the text are welcome.
>
> I think the following could be written clearer.   Reading it made me have to
> go off and check what week 50 was.
>

52 weeks in a year, so, effectively "last two weeks of the year".

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

[gentoo-dev] Last rites: dev-tex/ha-prosper

[Alexis Ballier]

# Alexis Ballier  (14 Nov 2010)
# Last rites: dev-tex/ha-prosper
# Old standalone ebuild, provided by dev-texlive/texlive-latexextra these days
# Removal on 14 Dec 2010
dev-tex/ha-prosper

[gentoo-dev] fat binaries

[Thomas Kahle]

Hi,

I have a package (sci-libs/mpir) whose configure supports building of
fat binaries with both x86 and amd64 assembler in the binary.  While I
personally think it is not useful to gentoo users, one might still want
to give the choice to build the fat binary.

-) Are there other packages that can build fat binaries ?

If yes,

-) How to name the USE flag?

Cheers,
Thomas



-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/


pgpdXEPAZkc8R.pgp
Description: PGP signature

Re: [gentoo-dev] Disabling auto-bumping of active Python version

[Florian Philipp]

Am 14.11.2010 17:28, schrieb Sebastian Pipping:
> 
> With Python, when you install a newer version if gets activated, leaving
> your system in broken state.  An update of Python always involves
> running python-updater.  If the user/admin has to run that anyway, why
> should we take the call to eselect python off his shoulders, especially
> we break the system doing so?
> 
> So I plan to remove the call to eselect_python_update from all Python
> ebuilds in two weeks from now.
[...]

Is there a chance to do the same for perl and perl-cleaner?

I understand perl is not slotted at the moment and there are probably
good technical reasons for not doing so but I still wanted to ask. :)

There are similar issues with ocaml and ocaml-rebuild.sh.

Best regards,
Florian Philipp



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [warning] the bug queue has 111 bugs

[Alex Alexander]

On Sun, Nov 14, 2010 at 03:20:05PM -0300, Alexis Ballier wrote:
> On Sunday 14 November 2010 09:45:04 Alex Alexander wrote:
> > On Sun, Nov 14, 2010 at 01:10:26PM +0100, "Paweł Hajdan, Jr." wrote:
> > > On 11/14/10 1:00 PM, Alex Alexander wrote:
> > > > If you have some spare time, please help assign/sort a few bugs.
> > > 
> > > I have another great idea for you. People are lazy, so could you make
> > > the warning message include a direct link to the "Bug Wranglers" queue?
> > 
> > OK, link added
> > http://bit.ly/bsHeJt
> 
> could you please include a link pointing to https:// ?
> 
> A.

sure, https link added as well
http://bit.ly/8Z4xUU

:)
-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com


pgpf81oufmdZ7.pgp
Description: PGP signature

[gentoo-dev] Re: fat binaries

[Diego Elio Pettenò]

Il giorno dom, 14/11/2010 alle 22.03 +0100, Thomas Kahle ha scritto:
> I have a package (sci-libs/mpir) whose configure supports building of
> fat binaries with both x86 and amd64 assembler in the binary. 

Oh the heck are they implemented? If they are FatELF, no they shouldn't
be used, ever, full stop.

In most cases, this sounds fishy and almost a hack deemed to failure so
my default vote would be "do not expose this functionality to the user".

-- 
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-11-14 23h59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2010-11-14 23h59 UTC.

Removals:
net-wireless/libeap 2010-11-08 17:42:50 alexxy
dev-python/IcePy2010-11-08 19:13:48 arfrever

Additions:
dev-tex/floatflt2010-11-08 00:21:00 aballier
sci-misc/flashdot   2010-11-08 00:35:17 tomka
games-misc/lucidlife2010-11-08 01:32:44 xmw
dev-python/pisa 2010-11-08 10:48:23 nelchael
dev-python/python-gflags2010-11-08 11:24:09 nelchael
dev-util/buildbot-slave 2010-11-08 12:21:18 arfrever
sci-geosciences/foxtrotgps  2010-11-08 13:16:23 bangert
net-zope/zope-keyreference  2010-11-08 13:38:21 arfrever
net-zope/zope-intid 2010-11-08 13:41:35 arfrever
net-zope/zope-app-intid 2010-11-08 13:44:14 arfrever
net-zope/zope-server2010-11-08 13:46:02 arfrever
net-zope/zope-copypastemove 2010-11-08 13:49:08 arfrever
net-zope/zope-app-container 2010-11-08 13:54:27 arfrever
net-zope/five-localsitemanager  2010-11-08 14:16:54 arfrever
net-zope/five-grok  2010-11-08 14:17:43 arfrever
net-zope/infrae-rest2010-11-08 14:21:57 arfrever
net-zope/five-intid 2010-11-08 15:50:25 arfrever
net-zope/zope-deprecation   2010-11-08 16:20:00 arfrever
net-zope/z3c-recipe-scripts 2010-11-08 16:30:42 arfrever
net-zope/zc-recipe-testrunner   2010-11-08 16:35:31 arfrever
net-zope/zope-sqlalchemy2010-11-08 16:58:57 arfrever
dev-libs/libcaldav  2010-11-08 22:32:34 dilfridge
sci-libs/cddlib 2010-11-08 23:19:56 tomka
kde-misc/kcaldav2010-11-08 23:37:31 dilfridge
sci-mathematics/topcom  2010-11-09 17:48:55 tomka
x11-themes/qgtkstyle2010-11-10 10:52:13 wired
x11-themes/gion-icon-theme  2010-11-10 14:35:55 ssuominen
x11-themes/nuovo-icon-theme 2010-11-10 17:07:16 ssuominen
media-gfx/gimp-lqr-plugin   2010-11-10 21:06:25 phajdan.jr
app-misc/hexcompare 2010-11-10 23:01:05 xmw
dev-util/valkyrie   2010-11-11 01:28:22 xmw
x11-themes/yasis-icon-theme 2010-11-11 10:33:57 ssuominen
sci-chemistry/gabedit   2010-11-11 11:38:02 jlec
sci-libs/mpir   2010-11-12 13:15:46 tomka
sci-mathematics/gfan2010-11-12 14:50:27 tomka
sci-libs/cdd+   2010-11-12 15:04:32 tomka
sci-libs/lrslib 2010-11-12 18:43:10 tomka
sci-mathematics/Macaulay2   2010-11-12 18:56:55 tomka
kde-misc/wicd-client-kde2010-11-12 22:15:33 dilfridge
x11-themes/faenza-icon-theme2010-11-14 00:00:20 ssuominen
dev-java/gcj-jdk2010-11-14 01:04:19 caster
app-admin/patchelf  2010-11-14 12:53:31 jlec
sys-auth/munge  2010-11-14 23:04:40 jsbronder

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
net-wireless/libeap,removed,alexxy,2010-11-08 17:42:50
dev-python/IcePy,removed,arfrever,2010-11-08 19:13:48
Added Packages:
dev-tex/floatflt,added,aballier,2010-11-08 00:21:00
sci-misc/flashdot,added,tomka,2010-11-08 00:35:17
games-misc/lucidlife,added,xmw,2010-11-08 01:32:44
dev-python/pisa,added,nelchael,2010-11-08 10:48:23
dev-python/python-gflags,added,nelchael,2010-11-08 11:24:09
dev-util/buildbot-slave,added,arfrever,2010-11-08 12:21:18
sci-geosciences/foxtrotgps,added,bangert,2010-11-08 13:16:23
net-zope/zope-keyreference,added,arfrever,2010-11-08 13:38:21
net-zope/zope-intid,added,arfrever,2010-11-08 13:41:35
net-zope/zope-app-intid,added,arfrever,2010-11-08 13:44:14
net-zope/zope-server,added,arfrever,2010-11-08 13:46:02
net-zope/zope-copypastemove,added,arfrever,2010-11-08 13:49:08
net-zope/zope-app-container,added,arfrever,2010-11-08 13:54:27
net-zope/five-localsitemanager,added,arfrever,2010-11-08 14:16:54
net-zope/five-grok,added,arfrever,2010-11-08 14:17:43
net-zope/infrae-rest,added,arfrever,2010-11-08 14:21:57
net-zope/five-intid,added,arfrever,2010-11-08 15:50:25
net-zope/zope-deprecation,added,arfrever,2010-11-08 16:20:00
net-zope/z3c-recipe-scripts,added,arfrever,2010-11-08 16:30:42
net-zope/zc-recipe-testrunner,added,arfrever,2010-11-08 16:35:31
net-zope/zope-sqlalchemy,added,arfrever,2010-11-08 16:58:57
dev-libs/libcaldav,added,dilfridge,2010-11-08 22:32:34
sci-libs/cddlib,added,tomka,2010-11-08 23:19:56
kde-misc/kcaldav,added,dilfridge,2010-11-08 23:37:31
sci-mathematics/topcom,added,tomka,2010-11-09 17:48:55
x11-themes/qgtkstyle,added,wired,2010-11-10 10:52:13
x11-themes/gion-icon-theme,added,ssuominen,2010-11-10 14:35:55
x11-themes/nuovo-icon-theme,added,ssuominen,2010-11-10 17:07:16
media-gfx/gimp-lqr-plugin,added,phajdan.jr,2010-11-10 21:06:25
app-mis

[gentoo-dev] Re: fat binaries

[Nikos Chantziaras]

On 11/15/2010 01:30 AM, Diego Elio Pettenò wrote:

Il giorno dom, 14/11/2010 alle 22.03 +0100, Thomas Kahle ha scritto:

I have a package (sci-libs/mpir) whose configure supports building of
fat binaries with both x86 and amd64 assembler in the binary.


Oh the heck are they implemented? If they are FatELF, no they shouldn't
be used, ever, full stop.

In most cases, this sounds fishy and almost a hack deemed to failure so
my default vote would be "do not expose this functionality to the user".


It's not FatELF.  It's pretty much what the Intel compiler does, but in 
this case it's done by hand; the binary includes several versions of the 
code.  Which version is executed depends on the CPU detected at runtime. 
 Has nothing to do with the FatELF brain damage :-)

Re: [gentoo-dev] Re: fat binaries

[Thomas Kahle]

On 00:30 Mon 15 Nov , Diego Elio Pettenò wrote:
> Il giorno dom, 14/11/2010 alle 22.03 +0100, Thomas Kahle ha scritto:
> > I have a package (sci-libs/mpir) whose configure supports building of
> > fat binaries with both x86 and amd64 assembler in the binary. 
> 
> Oh the heck are they implemented? If they are FatELF, no they shouldn't
> be used, ever, full stop.

They don't tell.  From the manual:

Fat binary, ‘--enable-fat’ 

Using ‘--enable-fat’ selects a “fat binary” build on x86 or x86 64
systems, where optimized low level subroutines are chosen at runtime
according to the CPU de- tected. This means more code, but gives
reasonable performance from a single bi- nary for all x86 chips, or
similarly for all x86 64 chips. (This option might become available for
more architectures in the future.)

Cheers,
Thomas

 

-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/


pgpjQMJx5P6bA.pgp
Description: PGP signature

Re: [gentoo-dev] Restabilizing MIPS

[Jeremy Olexa]

On 11/11/2010 05:00 PM, Matt Turner wrote:

Hi,
I'd like to begin stabilizing packages on MIPS. I've gotten acks from
Redhatter, leio, and r0bertz, and Kumba doesn't really care.

What's the best method to go about doing this? Stabilize the system
packages, then remove ~mips from ACCEPT_KEYWORDS in the profiles?
Should we target package versions that aren't stabilized on other
architectures yet, so that we'll have an extended testing period
before they'll come up for stabilization? That is, can I plan to make
gcc-4.5.1 or something the first restabilized version of gcc, go ahead
and begin testing it, and be ready for stabilization when toolchain
requests it?


What is the long term plan here? Stable @system set, stable everything 
currently ~mips keyworded, or something random in between that? I'd 
caution mips keywording here in general as the team is small and seems 
unlikely to keep up from my POV. I'm not being negative, just being 
real. I suppose it is somewhat possible to keep up if the mips team 
dropped some ~mips packages in general and focused on the @system set.


-Jeremy

Re: [gentoo-dev] Re: fat binaries

[Jeremy Olexa]

On 11/14/2010 05:41 PM, Thomas Kahle wrote:

On 00:30 Mon 15 Nov , Diego Elio Pettenò wrote:

Il giorno dom, 14/11/2010 alle 22.03 +0100, Thomas Kahle ha scritto:

I have a package (sci-libs/mpir) whose configure supports building of
fat binaries with both x86 and amd64 assembler in the binary.


Oh the heck are they implemented? If they are FatELF, no they shouldn't
be used, ever, full stop.


They don't tell.  From the manual:

Fat binary, ‘--enable-fat’

Using ‘--enable-fat’ selects a “fat binary” build on x86 or x86 64
systems, where optimized low level subroutines are chosen at runtime
according to the CPU de- tected. This means more code, but gives
reasonable performance from a single bi- nary for all x86 chips, or
similarly for all x86 64 chips. (This option might become available for
more architectures in the future.)


This is useless for Gentoo Users, IMO. Besides, the people that *want* 
this (anyone?) can use 'EXTRA_ECONF="--enable-fat" emerge sci-libs/mpir'


-Jeremy

Re: [gentoo-dev] Restabilizing MIPS

[Matt Turner]

On Sun, Nov 14, 2010 at 10:22 PM, Jeremy Olexa  wrote:
> On 11/11/2010 05:00 PM, Matt Turner wrote:
>>
>> Hi,
>> I'd like to begin stabilizing packages on MIPS. I've gotten acks from
>> Redhatter, leio, and r0bertz, and Kumba doesn't really care.
>>
>> What's the best method to go about doing this? Stabilize the system
>> packages, then remove ~mips from ACCEPT_KEYWORDS in the profiles?
>> Should we target package versions that aren't stabilized on other
>> architectures yet, so that we'll have an extended testing period
>> before they'll come up for stabilization? That is, can I plan to make
>> gcc-4.5.1 or something the first restabilized version of gcc, go ahead
>> and begin testing it, and be ready for stabilization when toolchain
>> requests it?
>
> What is the long term plan here? Stable @system set, stable everything
> currently ~mips keyworded, or something random in between that? I'd caution
> mips keywording here in general as the team is small and seems unlikely to
> keep up from my POV. I'm not being negative, just being real. I suppose it
> is somewhat possible to keep up if the mips team dropped some ~mips packages
> in general and focused on the @system set.
>
> -Jeremy

I don't have a long-term plan other than to stabilize the base system
and provide n32 stages. Where it goes from there, I don't know.

There's certainly the potential for new users and developers to join
in since Lemote/Gdium hardware is available and in general faster than
all but the fastest Linux-supported SGI systems.

Though, you'd think with six members of the MIPS herd we'd have enough
man-power between us to keep some stable keywords.

Matt

Re: [gentoo-dev] 150 bugs at bug-wranglers@

[Paweł Hajdan, Jr.]

On 11/10/10 4:16 PM, Markos Chandras wrote:
> On Wed, Nov 10, 2010 at 04:14:28PM +0100, "Paweł Hajdan, Jr." wrote:
>> If there are no objections, I will update the staffing needs page with
>> info that we need more bug wranglers.
>>
> Please do. Thanks

Here's the diff I'm going to apply:

Index: index.xml
===
RCS file:
/var/cvsroot/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml,v
retrieving revision 1.18
diff -u -B -r1.18 index.xml
--- index.xml   26 Oct 2010 18:46:09 -  1.18
+++ index.xml   15 Nov 2010 07:17:57 -
@@ -45,6 +45,21 @@
 
 

+
+
+Bug Wrangler
+
+Gentoo needs more people handling new bugs (i.e. assigning them
+to the right people, making sure the reporter has submitted enough info,
+etc.)
+
+
+Good understanding of Gentoo and Bugzilla, always respecting the users.
+
+jer
+
+
+
 jer
 jlec
 Polynomial-C

What do you think?



signature.asc
Description: OpenPGP digital signature