justin | 1 Apr 14:40 2011
Picon

Fortran.eclass is marked obsolete and is going to be removed

Hi,

no package in the tree is using the fortran.eclass anymore. Please check
your overlays and remove any usage.
toolchain-funcs.eclass support tc-getFC/F77 to check for fortran compilers.

In case of questions, the sci team will help.

WE will going to remove the eclass soonish.

justin

"Paweł Hajdan, Jr." | 2 Apr 12:02 2011
Picon

Re: Re: virtual/ffmpeg and media-video/libav

On 3/31/11 9:37 AM, Tomáš Chvátal wrote:
> Ok two versioned virtuals (0.5 0.6) are now in the tree if people need
> to specify the version.

Thank you, but it's still not enough for chromium. The virtual uses
>=ffmpeg-0.6, and chromium is known to be broken with <ffmpeg-0.6_p25767.

We need to require >=ffmpeg-0.6_p25767, not just 0.6.

By the way, I still didn't have time to test with libav, but it seems
that it's expected to be compatible.

"Paweł Hajdan, Jr." | 2 Apr 18:22 2011
Picon

Re: developer profile, FEATURES=digest

On 3/27/11 1:13 PM, "Paweł Hajdan, Jr." wrote:
> I'd like to suggest removing "digest" from the line above. I've been
> running with the developer profile and -digest in /etc/make.conf, and
> everything is working fine.

Are there any objections against doing the above?

Christos (angelos), Mike (vapier): your comments don't sound like a
strong "no objections" to me, but they also don't sound like "please
don't do that". I guess you may need to add FEATURES=digest to your
/etc/make.conf after the profile change, but that should generally be
fine, right?

Paweł Hajdan, Jr.

Mike Frysinger | 2 Apr 19:08 2011
Picon

Re: developer profile, FEATURES=digest

On Sat, Apr 2, 2011 at 12:22 PM, "Paweł Hajdan, Jr." wrote:
> On 3/27/11 1:13 PM, "Paweł Hajdan, Jr." wrote:
>> I'd like to suggest removing "digest" from the line above. I've been
>> running with the developer profile and -digest in /etc/make.conf, and
>> everything is working fine.
>
> Are there any objections against doing the above?
>
> Christos (angelos), Mike (vapier): your comments don't sound like a
> strong "no objections" to me, but they also don't sound like "please
> don't do that". I guess you may need to add FEATURES=digest to your
> /etc/make.conf after the profile change, but that should generally be
> fine, right?

drop it
-mike

Alexis Ballier | 2 Apr 21:41 2011
Picon

Re: Re: virtual/ffmpeg and media-video/libav

On Saturday, April 02, 2011 07:02:54 AM Paweł Hajdan, Jr. wrote:
> On 3/31/11 9:37 AM, Tomáš Chvátal wrote:
> > Ok two versioned virtuals (0.5 0.6) are now in the tree if people need
> > to specify the version.
> 
> Thank you, but it's still not enough for chromium. The virtual uses
> 
> >=ffmpeg-0.6, and chromium is known to be broken with <ffmpeg-0.6_p25767.
> 
> We need to require >=ffmpeg-0.6_p25767, not just 0.6.
> 
> By the way, I still didn't have time to test with libav, but it seems
> that it's expected to be compatible.

iirc, this dep in chromium is due to the need for libavcore, but this lib has 
been merged back to libavutil in latest snapshots (and thus chromium fails to 
build); if chromium goes back to look for the functions in libavutil, you may 
have chances to be compatible with 0.6

A.

Christoph Mende | 2 Apr 22:04 2011
Picon

Re: Re: virtual/ffmpeg and media-video/libav

On Sat, 2011-04-02 at 16:41 -0300, Alexis Ballier wrote:
> On Saturday, April 02, 2011 07:02:54 AM Paweł Hajdan, Jr. wrote:
> > On 3/31/11 9:37 AM, Tomáš Chvátal wrote:
> > > Ok two versioned virtuals (0.5 0.6) are now in the tree if people need
> > > to specify the version.
> > 
> > Thank you, but it's still not enough for chromium. The virtual uses
> > 
> > >=ffmpeg-0.6, and chromium is known to be broken with <ffmpeg-0.6_p25767.
> > 
> > We need to require >=ffmpeg-0.6_p25767, not just 0.6.
> > 
> > By the way, I still didn't have time to test with libav, but it seems
> > that it's expected to be compatible.
> 
> 
> iirc, this dep in chromium is due to the need for libavcore, but this lib has 
> been merged back to libavutil in latest snapshots (and thus chromium fails to 
> build); if chromium goes back to look for the functions in libavutil, you may 
> have chances to be compatible with 0.6
> 
> A.
> 

I've reported that upstream 2 days ago and it was fixed yesterday. I'm
running chromium-11.0.696.28 against libav-0.7_pre20110327 here and it
works fine.
"Paweł Hajdan, Jr." | 2 Apr 22:39 2011
Picon

Re: developer profile, FEATURES=digest

On 4/2/11 7:08 PM, Mike Frysinger wrote:
> On Sat, Apr 2, 2011 at 12:22 PM, "Paweł Hajdan, Jr." wrote:
>> On 3/27/11 1:13 PM, "Paweł Hajdan, Jr." wrote:
>>> I'd like to suggest removing "digest" from the line above. I've been
>>> running with the developer profile and -digest in /etc/make.conf, and
>>> everything is working fine.
>>
>> Are there any objections against doing the above?
>>
> drop it

done.

Ryan Hill | 3 Apr 06:11 2011
Picon

GCC 4.6.0

I just added 4.6.0 to the tree.  We probably won't be unmasking it any time
soon (after 4.6.1 for sure), but please start testing your packages now so we
can get things rolling.

http://gcc.gnu.org/gcc-4.6/changes.html

For general testing you may want to add the gcc-porting overlay to avoid
known failures that haven't been fixed in the tree yet.

Outstanding issues I know about:

  - hardened is broken (stage comparison mismatch)
  - sys-boot/grub-0.97 is miscompiled (bug #360513)

  https://overlays.gentoo.org/proj/gcc-porting/browser/README-4.6

Common errors:

  https://overlays.gentoo.org/proj/gcc-porting/browser/ERRORS-4.6
  http://lists.fedoraproject.org/pipermail/devel/2011-February/148523.html

  You may also want to test your packages with the new -Ofast option to be
  sure it doesn't have any hardcoded assumptions about -O flags.

Please assign any bugs you find in GCC itself to toolchain, and any bugs in
packages to their respective maintainers with a block on "gcc-4.6" (ie. bug
#346809).

--

-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
(Continue reading)

Duncan | 3 Apr 07:50 2011
Picon
Picon

Re: GCC 4.6.0

Ryan Hill posted on Sat, 02 Apr 2011 22:11:12 -0600 as excerpted:

>   You may also want to test your packages with the new -Ofast option to
>   be sure it doesn't have any hardcoded assumptions about -O flags.

The release description I've read for -Ofast says it includes -fast-math, 
among other things, a flag Gentoo has always strongly discouraged (you 
break with it, you keep the pieces) and which can get bugs resolved/
invalid as a result.

Now that gcc 4.6 itself is more strongly supporting it as enabled with one 
of the -O options, is that policy going to change, or is Gentoo going to 
officially not support -Ofast, as well?

Or is that yet to be established, thru testing?

FWIW, I've always stayed away from that flag, but if Gentoo's going to 
support it now, that may well change, tho I'd certainly disable it for 
specific packages using /etc/portage/env/*, as I already do for 
-combine, in my default CFLAGS but not CXXFLAGS, for instance.

--

-- 
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

Thomas Beierlein | 3 Apr 10:52 2011
Picon

Re: Packages up for grabs

On Wed, 16 Mar 2011 17:18:52 +0000
Christoph Mende <angelos <at> gentoo.org> wrote:

> app-editors/hexedit

I will care for it.

Thomas

--

-- 


Gmane