[gentoo-dev] About gcc-4.6 unmasking

[gentoo-dev] About gcc-4.6 unmasking

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

I don't know if this has been discussed before but, what issues are
preventing us from unmasking gcc-4.6 (and think on a near
stabilization)?

I have read hardmask message but it simply explains that it's masked for
testing purposes :-/

Thanks a lot for the info

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] About gcc-4.6 unmasking

[Justin]

On 20.02.2012 21:34, Pacho Ramos wrote:
> I don't know if this has been discussed before but, what issues are
> preventing us from unmasking gcc-4.6 (and think on a near
> stabilization)?
> 
> I have read hardmask message but it simply explains that it's masked for
> testing purposes :-/
> 
> Thanks a lot for the info

Here was the last one

http://archives.gentoo.org/gentoo-dev/msg_b6db68b41a4b318ea2122fb982c10dfb.xml

For me it worked fine for months now.

justin

Re: [gentoo-dev] About gcc-4.6 unmasking

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

El lun, 20-02-2012 a las 21:41 +0100, Justin escribió:
> On 20.02.2012 21:34, Pacho Ramos wrote:
> > I don't know if this has been discussed before but, what issues are
> > preventing us from unmasking gcc-4.6 (and think on a near
> > stabilization)?
> > 
> > I have read hardmask message but it simply explains that it's masked for
> > testing purposes :-/
> > 
> > Thanks a lot for the info
> 
> Here was the last one
> 
> http://archives.gentoo.org/gentoo-dev/msg_b6db68b41a4b318ea2122fb982c10dfb.xml
> 
> For me it worked fine for months now.
> 
> justin
> 
> 

Bleh, looks like grub is blocking this :(, will need to wait then (or
maybe move to grub2 ;))

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Re: [gentoo-dev] About gcc-4.6 unmasking

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

> 
> Bleh, looks like grub is blocking this :(, will need to wait then (or
> maybe move to grub2 ;))

Yeah... anyone helping to debug this tricky thingy [*] is likely welcome. 
Would like to help, but cant do much atm because of real-life work load...

[*] https://bugs.gentoo.org/show_bug.cgi?id=360513

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] About gcc-4.6 unmasking

[Richard Yao]

We had a chat about this in #gentoo-dev the other night. I might come
up with a solution as part of the ZFS stuff that I am doing, but it
won't happen for at least a month.

With that said, it doesn't look like GRUB is the only blocker:

https://bugs.gentoo.org/show_bug.cgi?id=gcc-4.6

On Mon, Feb 20, 2012 at 3:49 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> El lun, 20-02-2012 a las 21:41 +0100, Justin escribió:
>> On 20.02.2012 21:34, Pacho Ramos wrote:
>> > I don't know if this has been discussed before but, what issues are
>> > preventing us from unmasking gcc-4.6 (and think on a near
>> > stabilization)?
>> >
>> > I have read hardmask message but it simply explains that it's masked for
>> > testing purposes :-/
>> >
>> > Thanks a lot for the info
>>
>> Here was the last one
>>
>> http://archives.gentoo.org/gentoo-dev/msg_b6db68b41a4b318ea2122fb982c10dfb.xml
>>
>> For me it worked fine for months now.
>>
>> justin
>>
>>
>
> Bleh, looks like grub is blocking this :(, will need to wait then (or
> maybe move to grub2 ;))

[gentoo-dev] Re: About gcc-4.6 unmasking

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

On Mon, 20 Feb 2012 21:34:14 +0100
Pacho Ramos <pacho@gentoo.org> wrote:

> I don't know if this has been discussed before but, what issues are
> preventing us from unmasking gcc-4.6 (and think on a near
> stabilization)?
> 
> I have read hardmask message but it simply explains that it's masked for
> testing purposes :-/

Grub is the only blocker.  I don't want to unmask something that makes
people's systems unbootable.

I'm also out of ideas and open to suggestions.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: About gcc-4.6 unmasking

[Matt Turner]

On Mon, Feb 20, 2012 at 8:03 PM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> On Mon, 20 Feb 2012 21:34:14 +0100
> Pacho Ramos <pacho@gentoo.org> wrote:
>
>> I don't know if this has been discussed before but, what issues are
>> preventing us from unmasking gcc-4.6 (and think on a near
>> stabilization)?
>>
>> I have read hardmask message but it simply explains that it's masked for
>> testing purposes :-/
>
> Grub is the only blocker.  I don't want to unmask something that makes
> people's systems unbootable.
>
> I'm also out of ideas and open to suggestions.

Is it a bad idea to go ahead and unmask it on architectures that don't use grub?

Re: [gentoo-dev] Re: About gcc-4.6 unmasking

[Zac Medico]

On 02/20/2012 05:03 PM, Ryan Hill wrote:
> On Mon, 20 Feb 2012 21:34:14 +0100
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
>> I don't know if this has been discussed before but, what issues are
>> preventing us from unmasking gcc-4.6 (and think on a near
>> stabilization)?
>>
>> I have read hardmask message but it simply explains that it's masked for
>> testing purposes :-/
> 
> Grub is the only blocker.  I don't want to unmask something that makes
> people's systems unbootable.
> 
> I'm also out of ideas and open to suggestions.

Stabilize grub-1.99, and modify the grub-0.9x ebuilds to die if they
can't find a supported compiler.
-- 
Thanks,
Zac

[gentoo-dev] Re: About gcc-4.6 unmasking

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

On Mon, 20 Feb 2012 17:17:30 -0800
Zac Medico <zmedico@gentoo.org> wrote:

> On 02/20/2012 05:03 PM, Ryan Hill wrote:
> > On Mon, 20 Feb 2012 21:34:14 +0100
> > Pacho Ramos <pacho@gentoo.org> wrote:
> > 
> >> I don't know if this has been discussed before but, what issues are
> >> preventing us from unmasking gcc-4.6 (and think on a near
> >> stabilization)?
> >>
> >> I have read hardmask message but it simply explains that it's masked for
> >> testing purposes :-/
> > 
> > Grub is the only blocker.  I don't want to unmask something that makes
> > people's systems unbootable.
> > 
> > I'm also out of ideas and open to suggestions.
> 
> Stabilize grub-1.99, and modify the grub-0.9x ebuilds to die if they
> can't find a supported compiler.

What's the state of 1.99?  I know someone was working on it recently.  We'd
also have to update the handbooks.  I think it could be several months of
work to get it ready, and I'd like to unmask 4.6 last September.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: About gcc-4.6 unmasking

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

El lun, 20-02-2012 a las 20:02 -0600, Ryan Hill escribió:
> On Mon, 20 Feb 2012 17:17:30 -0800
> Zac Medico <zmedico@gentoo.org> wrote:
> 
> > On 02/20/2012 05:03 PM, Ryan Hill wrote:
> > > On Mon, 20 Feb 2012 21:34:14 +0100
> > > Pacho Ramos <pacho@gentoo.org> wrote:
> > > 
> > >> I don't know if this has been discussed before but, what issues are
> > >> preventing us from unmasking gcc-4.6 (and think on a near
> > >> stabilization)?
> > >>
> > >> I have read hardmask message but it simply explains that it's masked for
> > >> testing purposes :-/
> > > 
> > > Grub is the only blocker.  I don't want to unmask something that makes
> > > people's systems unbootable.
> > > 
> > > I'm also out of ideas and open to suggestions.
> > 
> > Stabilize grub-1.99, and modify the grub-0.9x ebuilds to die if they
> > can't find a supported compiler.
> 
> What's the state of 1.99?  I know someone was working on it recently.  We'd
> also have to update the handbooks.  I think it could be several months of
> work to get it ready, and I'd like to unmask 4.6 last September.
> 
> 

As looks like fixing old grub is far away because nobody know what is
causing that issues, probably trying to get grub-1.99 ready for
stabilization would be interesting (we will need to do that sooner or
later anyway)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: About gcc-4.6 unmasking

[Alec Warner]

On Tue, Feb 21, 2012 at 1:26 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> El lun, 20-02-2012 a las 20:02 -0600, Ryan Hill escribió:
>> On Mon, 20 Feb 2012 17:17:30 -0800
>> Zac Medico <zmedico@gentoo.org> wrote:
>>
>> > On 02/20/2012 05:03 PM, Ryan Hill wrote:
>> > > On Mon, 20 Feb 2012 21:34:14 +0100
>> > > Pacho Ramos <pacho@gentoo.org> wrote:
>> > >
>> > >> I don't know if this has been discussed before but, what issues are
>> > >> preventing us from unmasking gcc-4.6 (and think on a near
>> > >> stabilization)?
>> > >>
>> > >> I have read hardmask message but it simply explains that it's masked for
>> > >> testing purposes :-/
>> > >
>> > > Grub is the only blocker.  I don't want to unmask something that makes
>> > > people's systems unbootable.
>> > >
>> > > I'm also out of ideas and open to suggestions.
>> >
>> > Stabilize grub-1.99, and modify the grub-0.9x ebuilds to die if they
>> > can't find a supported compiler.
>>
>> What's the state of 1.99?  I know someone was working on it recently.  We'd
>> also have to update the handbooks.  I think it could be several months of
>> work to get it ready, and I'd like to unmask 4.6 last September.
>>
>>
>
> As looks like fixing old grub is far away because nobody know what is
> causing that issues, probably trying to get grub-1.99 ready for
> stabilization would be interesting (we will need to do that sooner or
> later anyway)

Ubuntu has used grub2 for 3 years, I am considering working on making
it stable for at least x86 / amd64.

-A

Re: [gentoo-dev] Re: About gcc-4.6 unmasking

[Mike Gilbert]

On Tue, Feb 21, 2012 at 5:38 PM, Alec Warner <antarus@gentoo.org> wrote:
> On Tue, Feb 21, 2012 at 1:26 AM, Pacho Ramos <pacho@gentoo.org> wrote:
>> El lun, 20-02-2012 a las 20:02 -0600, Ryan Hill escribió:
>>> On Mon, 20 Feb 2012 17:17:30 -0800
>>> Zac Medico <zmedico@gentoo.org> wrote:
>>>
>>> > On 02/20/2012 05:03 PM, Ryan Hill wrote:
>>> > > On Mon, 20 Feb 2012 21:34:14 +0100
>>> > > Pacho Ramos <pacho@gentoo.org> wrote:
>>> > >
>>> > >> I don't know if this has been discussed before but, what issues are
>>> > >> preventing us from unmasking gcc-4.6 (and think on a near
>>> > >> stabilization)?
>>> > >>
>>> > >> I have read hardmask message but it simply explains that it's masked for
>>> > >> testing purposes :-/
>>> > >
>>> > > Grub is the only blocker.  I don't want to unmask something that makes
>>> > > people's systems unbootable.
>>> > >
>>> > > I'm also out of ideas and open to suggestions.
>>> >
>>> > Stabilize grub-1.99, and modify the grub-0.9x ebuilds to die if they
>>> > can't find a supported compiler.
>>>
>>> What's the state of 1.99?  I know someone was working on it recently.  We'd
>>> also have to update the handbooks.  I think it could be several months of
>>> work to get it ready, and I'd like to unmask 4.6 last September.
>>>
>>>
>>
>> As looks like fixing old grub is far away because nobody know what is
>> causing that issues, probably trying to get grub-1.99 ready for
>> stabilization would be interesting (we will need to do that sooner or
>> later anyway)
>
> Ubuntu has used grub2 for 3 years, I am considering working on making
> it stable for at least x86 / amd64.
>
> -A
>

FYI, the code freeze for Grub 2.00 was announced today. It might be
better to target that at this point.

http://lists.gnu.org/archive/html/grub-devel/2012-02/msg00147.html

[gentoo-dev] Re: About gcc-4.6 unmasking

[Nikos Chantziaras]

On 22/02/12 00:38, Alec Warner wrote:
> On Tue, Feb 21, 2012 at 1:26 AM, Pacho Ramos<pacho@gentoo.org>  wrote:
>> As looks like fixing old grub is far away because nobody know what is
>> causing that issues, probably trying to get grub-1.99 ready for
>> stabilization would be interesting (we will need to do that sooner or
>> later anyway)
>
> Ubuntu has used grub2 for 3 years, I am considering working on making
> it stable for at least x86 / amd64.

That's good news.  I think Gentoo has a policy on not providing 
unmaintained software in the tree (they're getting tree cleaned.)  Given 
that Grub 1 is both beta software (it got stuck at 0.97, never made it 
to 1.0) and unmaintained, stabilizing Grub 2 ASAP is the sanest thing 
you can do, since even though it's also beta software, it's at least 
maintained by upstream.

Re: [gentoo-dev] Re: About gcc-4.6 unmasking

[Ben]

On 22 February 2012 06:57, Nikos Chantziaras <realnc@arcor.de> wrote:
> [...] Given that Grub 1 is
> both beta software (it got stuck at 0.97, never made it to 1.0) and
> unmaintained,

Just looking at KDE 4.0 and GNOME 3.0 should tell you that version
numbers can be *very* deceiving. And while grub-0.97 may "officially"
be beta software it is much more stable than a lot of software that
does sport the 1.0 designation.

I think we should keep this version of grub around, at least for a
while longer, since a lot of our users are used to this essential
piece of software and may be hesitant to migrate to grub2 or other
boot loaders.

> stabilizing Grub 2 ASAP is the sanest thing you can do, since
> even though it's also beta software, it's at least maintained by upstream.

I would hesitate to say it's the *sanest* thing to do, but we should
at least get it into ~arch and make sure our documentation is up to
date.

Cheers,
Ben

Re: [gentoo-dev] Re: About gcc-4.6 unmasking

[Alec Warner]

On Tue, Feb 21, 2012 at 8:22 PM, Ben <yngwin@gmail.com> wrote:
> On 22 February 2012 06:57, Nikos Chantziaras <realnc@arcor.de> wrote:
>> [...] Given that Grub 1 is
>> both beta software (it got stuck at 0.97, never made it to 1.0) and
>> unmaintained,
>
> Just looking at KDE 4.0 and GNOME 3.0 should tell you that version
> numbers can be *very* deceiving. And while grub-0.97 may "officially"
> be beta software it is much more stable than a lot of software that
> does sport the 1.0 designation.
>
> I think we should keep this version of grub around, at least for a
> while longer, since a lot of our users are used to this essential
> piece of software and may be hesitant to migrate to grub2 or other
> boot loaders.

My intent was not to suggest that we ditch grub1, but that grub2 would
be stable and the 'default' assuming we (I?) can get it to work.

-A

>
>> stabilizing Grub 2 ASAP is the sanest thing you can do, since
>> even though it's also beta software, it's at least maintained by upstream.
>
> I would hesitate to say it's the *sanest* thing to do, but we should
> at least get it into ~arch and make sure our documentation is up to
> date.
>
> Cheers,
> Ben
>

Re: [gentoo-dev] Re: About gcc-4.6 unmasking

[Robin H. Johnson]

On Tue, Feb 21, 2012 at 09:36:03PM -0800, Alec Warner wrote:
> My intent was not to suggest that we ditch grub1, but that grub2 would
> be stable and the 'default' assuming we (I?) can get it to work.
As one of the main Grub1 maintainers in Gentoo presently, I welcome this
course of action with the recent Grub2 codefreeze.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: About gcc-4.6 unmasking

[James Cloos]

>>>>> "B" == Ben  <yngwin@gmail.com> writes:

>> stabilizing Grub 2 ASAP is the sanest thing you can do, since even
>> though it's also beta software, it's at least maintained by upstream.

B> I would hesitate to say it's the *sanest* thing to do, but we should at
B> least get it into ~arch and make sure our documentation is up to date.

Actually, given grub2's crazy config, the real upgrade from grub1 is
sys-boot/syslinux's extlinux(1).

The configuration and operation styles are much more comfortable for
those who are familiar with grub1.

It would make a better default for x86/amd64 than grub1 or grub2.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

[gentoo-dev] default to syslinux instead of grub, was Re: About gcc-4.6 unmasking

[Chí-Thanh Christopher Nguyễn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Cloos schrieb:
> B> I would hesitate to say it's the *sanest* thing to do, but we 
> should at B> least get it into ~arch and make sure our 
> documentation is up to date.
> 
> Actually, given grub2's crazy config, the real upgrade from grub1 
> is sys-boot/syslinux's extlinux(1).
> 
> The configuration and operation styles are much more comfortable 
> for those who are familiar with grub1.
> 
> It would make a better default for x86/amd64 than grub1 or grub2.

Speaking as sys-boot/syslinux maintainer, I would like to see it
included in the official installation documentation. However there are
some differences between grub{,2} and syslinux/extlinux that could
block universal adoption.

Installation:
Syslinux installs into a partition which means that /boot must be on
one of the supported filesystems. Currently these are btrfs, ext2/3/4
and vfat (ntfs support will come in the next release). Also this means
that /boot cannot reside on a logical partition. To my knowledge,
there are no plans to allow booting from LVM either.

Dual-booting:
Telling users to create GPT instead of MBR partitions could address
the logical partition issue, however this would make dual-booting
Windows difficult. And Windows has been observed to behave strangely
when its BCD is not on a partition which has the boot flag set. There
are workarounds but documenting them would increase the complexity of
the handbook.

EFI:
Syslinux does not boot on EFI yet. Not a big problem as UEFI will fall
back to BIOS mode but this can bite users on Apple hardware.

Xen:
Booting Xen generally works, but some specialties like Mini-OS aren't
supported and likely won't be in the near future.

tl;dr
Syslinux/extlinux can replace grub in many if not most cases. But for
a number of setups it is not well-suited. So a documented and stable
grub2 will still be needed.


Best regards,
Chí-Thanh Christopher Nguyễn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9EwsIACgkQ+gvH2voEPRBInwCfT9t7qmILcCG11pKcJJlJSMpr
hggAmwaeo4sl2OwnyhLr5sZFV+hUM7Vc
=l/NZ
-----END PGP SIGNATURE-----

[gentoo-dev] Re: About gcc-4.6 unmasking

[Duncan]

Alec Warner posted on Tue, 21 Feb 2012 14:38:53 -0800 as excerpted:

> On Tue, Feb 21, 2012 at 1:26 AM, Pacho Ramos <pacho@gentoo.org> wrote:
>> El lun, 20-02-2012 a las 20:02 -0600, Ryan Hill escribió:
>>> On Mon, 20 Feb 2012 17:17:30 -0800 Zac Medico wrote:
>>>> On 02/20/2012 05:03 PM, Ryan Hill wrote:
>>>>> On Mon, 20 Feb 2012 21:34:14 +0100 Pacho Ramos wrote:
>>>>>
>>>>>> [W]hat issues are preventing us from unmasking gcc-4.6
>>>>>> (and think on a near stabilization)?

>>>>> Grub is the only blocker.

>>>> Stabilize grub-1.99, and modify the grub-0.9x ebuilds to die if they
>>>> can't find a supported compiler.

The latter should be doable now, with the die suggesting either
grub-static or gcc-config to gcc-4.5, user's choice.

The former (grub-1.99)... will take some time... mostly for docs, see my 
experience as noted below.

>>> What's the state of 1.99?  I know someone was working on it recently.
>>> We'd also have to update the handbooks.  I think it could be several
>>> months of work to get it ready, and I'd like to unmask 4.6 last
>>> September.
>>>
>> As looks like fixing old grub is far away because nobody know what is
>> causing that issues, probably trying to get grub-1.99 ready for
>> stabilization would be interesting (we will need to do that sooner or
>> later anyway)
> 
> Ubuntu has used grub2 for 3 years, I am considering working on making it
> stable for at least x86 / amd64.

Ubuntu also defaults to upstart (IIRC, it's certainly not openrc!) and 
unity.  I run grub2 here and am all for the update (for one, it allows 
amd64/nomultilib to actually build grub, no more forced grub-static!), 
but surely there's better arguments in a gentoo context than mentioning 
the U-word, however long they've been doing it.


My grub2 upgrade experience, FWIW.  TL;DR: Gentoo grub2 docs need SERIOUS 
improvement for even ~arch usage (the bulk of the below), but I'm 
thrilled with how it works now that I have it figured out and setup to my 
liking.  VAST improvement over grub-legacy!

FWIW, I unmasked gcc-4.6 when I was still running grub-static, but I was 
thrilled to discover that grub-1.99 builds (and runs) just fine with it, 
even on amd64/no-multilib.

**BUT** there's still a HUGE lack of decent gentoo specific grub2 
documentation.  The stub of a guide-page that the ebuild mentions, at 
least as of a few weeks ago when I upgraded, is a start, but it can 
almost be said to be more missing than there. the holes are so big!  
There's no way that's fit for even ~arch yet, which is why it's still 
unkeyworded.  grub2 /works/ OK, there's simply no decent documentation at 
the gentoo level, and the documentation that's out there just isn't meant 
for or targeted at gentoo users /at/ /all/!

This is the current doc, FWIW:
http://dev.gentoo.org/~scarabeus/grub-2-guide.xml

Since I'm running a quad-spindle md/raid (generally raid-1) setup, except 
that /boot is only two spindles, thus allowing for a backup /boot on the 
other two, I had the luxury of building and installing (to system) 
grub-1.99 with DONT_MOUNT_BOOT=1 set in /etc/portage/env/sys-boot/grub, 
then installing it to one boot record, gpt-BIOS partition and /boot at a 
time, keeping the other grub-static until I was comfortable with grub2's 
functionality.

That allowed me to do a trial-and-error install and play around with the 
one, until I was absolutely SURE it was working well, then install to the 
second spindle and verify them both, before even TOUCHING the backup 
/boot and grub-static install on the other two spindles.

It's a very good thing, too, as it took me QUITE some trial and error to 
get things working well, because THE DOCS JUST AREN'T THERE yet.  So get 
the docs there and IMO it's basically ready to go, but that's going to 
take some time, even to get them to reasonable ~arch level, for folks who 
don't have the luxury of multiple bootable spindles and /boot install 
locations, as I do, and thus need documentation that works, at least for 
a minimal boot, the first time they let it touch /boot and (on BIOS 
systems, gpt and mbr both) the boot sector.

Some problems I ran into:

1) grub-static blocks all grub, not just <=grub-1.90.

https://bugs.gentoo.org/show_bug.cgi?id=398451

As mentioned above, I kept both installed.  There's no file-conflicts, 
once grub-static is set to block <=grub-1.90, not all grub, as that work 
is long since done, slotting grub2 against grub-legacy, only grub-static 
hasn't been updated appropriately.

2) The doc covers BIOS/mbr and UEFI, but not BIOS/gpt

https://bugs.gentoo.org/show_bug.cgi?id=398459

The current doc URL again:

http://dev.gentoo.org/~scarabeus/grub-2-guide.xml

Some people (like me) switched to gpt some time ago.  The existing doc 
doesn't say anything about what they should do.  As it happens, a gpt 
BIOS partition is detected automatically, and it solves a nasty problem 
MBR folks might have if there's not room between the boot sector and the 
first partition for grub-core.

That's the only two I bugged, as I don't want to bother people /too/ much 
with bugs on masked packages.  I figured once that doc bug gets fixed and 
there's some sign of movement, I can file other bugs.

3) LVM is mentioned as auto-detected, but md/raid isn't covered.  As it 
happens, it's auto-detected and handling has VASTLY improved compared to 
grub-legacy, as well.

4) There needs to be a section dealing with what to do (repartition?) if 
there's no room between the boot sector and the first partition for the 
grub-core image.

On gpt, this image will be placed in the BIOS partition if it's 
available, but mbr doesn't have such a thing, and I'm sure there's a few 
gpt folks out there who thought they didn't need a BIOS partition, since 
grub-legacy doesn't use it anyway.  Luckily, I had the foresight to setup 
BOTH a BIOS and an EFI partition, for forward compatibility, and that 
"just works".  But surely there's others still on MBR without a 
sufficient gap (I had problems with that and grub-legacy, it installed 
to /boot but /boot was/is reiserfs, which would relocate critical bits 
out from under grub-legacy at times, thus the /boot and 
/bak/boot scheme), and still others on gpt who didn't have that 
foresight, who will have problems and need to know how to solve them.

5) After system installation I had trouble installing to the backup boot
(/bak/boot, normal /boot was still grub-static and I wanted to keep it 
that way until I knew grub2 was working), because the script has /boot 
hardcoded -- it allows the boot record device to be set, but hard-codes 
/boot, which doesn't make a lot of sense.  There's a danger of having 
/boot on an entirely different device, which may or may not actually be 
present when the device with that boot record is booted.  Surely, they 
should both be settable.  (upstream?  What about the pkg_config phase?)

I worked around that with a combination of hacking and rearranging my 
fstab and scripts to mount what had been /bak/boot as /boot.

6) Most existing documentation seems to assume grub-mkconfig
(grub2-mkconfig on gentoo), but on my system anyway, running
grub2-mkconfig took longer than building a kernel from clean!
Seriously, building a kernel takes about 4 minutes here, and
grub2-mkconfig was taking about 5!  While that's /arguably/ acceptable 
for folks doing distro kernel upgrades perhaps a few times a year, it's 
definitely *NOT* acceptable for people like me who routinely run live-git 
kernels, normally upgrading them every few days, but occasionally doing a 
git-bisect with a new kernel every few minutes for 12 rounds or so!  
Doubling that turnaround time due to upstream's incredibly STUPID
grub2-mkconfig implementation just isn't going to cut it!

With a bunch of script-timestamp debugging, I discovered that the problem 
was some 30-ish calls to grub2-probe, each of which took ~10 seconds!  
The primary problem is upstream's, as neither grub2-probe nor
grub2-mkconfig caches results, so *EVERY* call to grub2-probe takes ~10 
seconds, and there are around *30* of them!  However, the wouldfallout is 
gentoo's to deal with.

The workaround is simple enough, or *WOULD* be with proper documentation, 
simply don't use grub2-mkconfig.  Instead, hand-configure grub.cfg just 
as gentooers have been hand-configuring grub.conf for years.  Done right, 
unlike the automated monster upstream uses, such a config doesn't even 
need updated with a kernel upgrade, it "just works".

(Here, I use the dated but still extremely effective update-symlinks-to-
newest-two and a stable backup, trick.  It's in my kernel install script, 
and the grub config simply points to the symlink so doesn't itself need 
updated.)

FWIW, Arch actually recommends hand-configuring too.  (Note the FWIW, 
unlike the U-word comparison I complained about above.  IMO arch's close 
enough to gentoo to at least have /some/ relevance, but the "FWIW" is 
there to cover and acknowledge those who find it worth little if 
anything.)

But... gentoo needs some documentation for it, because as I said, most of 
what's out there assumes the automated /etc/grub.d/* and grub2-mkconfig.

There's nothing on that in the current doc, AT ALL.


But WOW, once it was done and before I've even setup a graphics theme, 
has it ever been worth it!  My favorite feature is being able to access 
any file from any filesystem, directly from grub.  On top of md/raid or 
lvm2, doesn't matter, it can still access it!  No more having to keep 
copies of such files on /boot!  Grub fonts and themes in /usr/share and 
for that matter, kernel command-line textfile documentation (read with 
the build-in pager) in /usr/src/linux/Documentation, NOT A PROBLEM! =:^)

Plus, being able to actually build it from amd64/nomultilib instead of 
having to depend on grub-static, is a big plus. =:^)

-- 
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: About gcc-4.6 unmasking

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

On Tue, 21 Feb 2012 10:26:38 +0100
Pacho Ramos <pacho@gentoo.org> wrote:

> El lun, 20-02-2012 a las 20:02 -0600, Ryan Hill escribió:
> > On Mon, 20 Feb 2012 17:17:30 -0800
> > Zac Medico <zmedico@gentoo.org> wrote:
> > 
> > > On 02/20/2012 05:03 PM, Ryan Hill wrote:
> > > > On Mon, 20 Feb 2012 21:34:14 +0100
> > > > Pacho Ramos <pacho@gentoo.org> wrote:
> > > > 
> > > >> I don't know if this has been discussed before but, what issues are
> > > >> preventing us from unmasking gcc-4.6 (and think on a near
> > > >> stabilization)?
> > > >>
> > > >> I have read hardmask message but it simply explains that it's masked for
> > > >> testing purposes :-/
> > > > 
> > > > Grub is the only blocker.  I don't want to unmask something that makes
> > > > people's systems unbootable.
> > > > 
> > > > I'm also out of ideas and open to suggestions.
> > > 
> > > Stabilize grub-1.99, and modify the grub-0.9x ebuilds to die if they
> > > can't find a supported compiler.
> > 
> > What's the state of 1.99?  I know someone was working on it recently.  We'd
> > also have to update the handbooks.  I think it could be several months of
> > work to get it ready, and I'd like to unmask 4.6 last September.
> 
> As looks like fixing old grub is far away because nobody know what is
> causing that issues, probably trying to get grub-1.99 ready for
> stabilization would be interesting (we will need to do that sooner or
> later anyway)

We should probably work on getting it keyworded first. ;)  But yeah, this
might be the good reason needed to push it forward.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: About gcc-4.6 unmasking

[Alexandre Rostovtsev]

On Mon, 2012-02-20 at 19:03 -0600, Ryan Hill wrote:
> On Mon, 20 Feb 2012 21:34:14 +0100
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > I don't know if this has been discussed before but, what issues are
> > preventing us from unmasking gcc-4.6 (and think on a near
> > stabilization)?
> > 
> > I have read hardmask message but it simply explains that it's masked for
> > testing purposes :-/
> 
> Grub is the only blocker.  I don't want to unmask something that makes
> people's systems unbootable.
> 
> I'm also out of ideas and open to suggestions.

gcc is slotted. Is there any reason why we can't simply make grub depend
on a working slot of gcc and set CC appropriately in the ebuild?

-Alexandre

[gentoo-dev] Re: About gcc-4.6 unmasking

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

On Mon, 20 Feb 2012 20:30:40 -0500
Alexandre Rostovtsev <tetromino@gentoo.org> wrote:

> On Mon, 2012-02-20 at 19:03 -0600, Ryan Hill wrote:

> > Grub is the only blocker.  I don't want to unmask something that makes
> > people's systems unbootable.
> > 
> > I'm also out of ideas and open to suggestions.
 
> gcc is slotted. Is there any reason why we can't simply make grub depend
> on a working slot of gcc and set CC appropriately in the ebuild?

We have no way of forcing an ebuild to be built with a particular version of
GCC.  This is on purpose, and there are both technical and sociological
reasons for it.

What we can do is take some kind of action if the compiler is 4.6, such as
die with a message to use grub-static instead.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: About gcc-4.6 unmasking

[Xavier Miller]

Hello,
Quoting Ryan Hill <dirtyepic@gentoo.org>:

>> gcc is slotted. Is there any reason why we can't simply make grub depend
>> on a working slot of gcc and set CC appropriately in the ebuild?
>
> We have no way of forcing an ebuild to be built with a particular version of
> GCC.  This is on purpose, and there are both technical and sociological
> reasons for it.
>
> What we can do is take some kind of action if the compiler is 4.6, such as
> die with a message to use grub-static instead.


There were a time many applications needed libstdc++3 (or even GCC  
2.96) and we lived with 2 slots of GCC without any problem. And there  
are many work-around for not using grub legacy : grub-static, grub2,  
lilo, syslinux, u-boot-tools, ...

Sorry for the intrusion,

Xavier Miller.

Re: [gentoo-dev] Re: About gcc-4.6 unmasking

[Chí-Thanh Christopher Nguyễn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ryan Hill schrieb:
>> I don't know if this has been discussed before but, what issues
>> are preventing us from unmasking gcc-4.6 (and think on a near 
>> stabilization)?
>> 
>> I have read hardmask message but it simply explains that it's
>> masked for testing purposes :-/
> 
> Grub is the only blocker.  I don't want to unmask something that
> makes people's systems unbootable.
> 
> I'm also out of ideas and open to suggestions.

Does gcc-4.7 have the same problem with grub?


Best regards,
Chí-Thanh Christopher Nguyễn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9ExLEACgkQ+gvH2voEPRAkGQCeL46mVSwwzYioE18Y3qJ/34xD
zQ0AnAy3pOu6Cv5xSbabwT2CGEwdvXTb
=LLbL
-----END PGP SIGNATURE-----

[gentoo-dev] Re: About gcc-4.6 unmasking

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

On Mon, 20 Feb 2012 19:03:13 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> On Mon, 20 Feb 2012 21:34:14 +0100
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > I don't know if this has been discussed before but, what issues are
> > preventing us from unmasking gcc-4.6 (and think on a near
> > stabilization)?
> > 
> > I have read hardmask message but it simply explains that it's masked for
> > testing purposes :-/
> 
> Grub is the only blocker.  I don't want to unmask something that makes
> people's systems unbootable.

Okay, I'm bringing up a dual-boot system this weekend.  If I can get it
to fail I'll have something to debug.  If not, I'm just going to make grub
die on amd64 when 4.6 is used.  So, wish me bad luck. :D


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: About gcc-4.6 unmasking

[Richard Yao]

Ryan,

I took a look at the problem cited in your bug report. I suggest
compiling sys-boot/grub with CFLAGS="-O0 -ggdb3", attaching gdb to
grub-install and then watching what happens in the debugger. If you
compare runs with a GCC 4.5.3 built stage2 and a GCC 4.6.2 built
stage2, you should be able to find the bug.

Yours truly,
Richard Yao

On Mon, Feb 20, 2012 at 8:03 PM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> On Mon, 20 Feb 2012 21:34:14 +0100
> Pacho Ramos <pacho@gentoo.org> wrote:
>
>> I don't know if this has been discussed before but, what issues are
>> preventing us from unmasking gcc-4.6 (and think on a near
>> stabilization)?
>>
>> I have read hardmask message but it simply explains that it's masked for
>> testing purposes :-/
>
> Grub is the only blocker.  I don't want to unmask something that makes
> people's systems unbootable.
>
> I'm also out of ideas and open to suggestions.
>
>
> --
> fonts, gcc-porting
> toolchain, wxwidgets
> @ gentoo.org

Re: [gentoo-dev] Re: About gcc-4.6 unmasking

[Richard Yao]

> I took a look at the problem cited in your bug report. I suggest
> compiling sys-boot/grub with CFLAGS="-O0 -ggdb3", attaching gdb to
> grub-install and then watching what happens in the debugger. If you
> compare runs with a GCC 4.5.3 built stage2 and a GCC 4.6.2 built
> stage2, you should be able to find the bug.

I should add that I was able to use this technique to fix a bug that I
encountered during my initial attempt to port Illumos GRUB a month
ago. The code the introduced the Illumos GRUB bug is not present in
sys-boot/grub, but I imagine that the same technique should work here.

Also, for anyone interested in what happened to the
sys-boot/grub-illumos port I mention, there are issues with the
generated stage2 binary, grub-install is broken (Solaris uses a
separate install-grub tool) and I would prefer to rework the Sun
Microsystems code into a patch for sys-boot/grub, but the diff between
Illumos GRUB and GRUB 0.97 is a few megabytes in size, so that won't
happen this month.

[gentoo-dev] Re: About gcc-4.6 unmasking

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

On Mon, 20 Feb 2012 20:37:39 -0500
Richard Yao <ryao@cs.stonybrook.edu> wrote:

> Ryan,
> 
> I took a look at the problem cited in your bug report. I suggest
> compiling sys-boot/grub with CFLAGS="-O0 -ggdb3", attaching gdb to
> grub-install and then watching what happens in the debugger. If you
> compare runs with a GCC 4.5.3 built stage2 and a GCC 4.6.2 built
> stage2, you should be able to find the bug.

Sorry, the bug report is confusing.  It's actually two bugs, the first being
a miscompiled stage2 causing an error when running grub-install and making
the system unbootable.  I fixed that back in Sept.  The second bug is a
continuous boot loop that only seems to manifest on certain machines or
configurations.  This is the one I'm having trouble with.  I should have
opened a new report for it, but at the time I thought it was due to fallout
from the first patch.

The biggest problem is that I can't reproduce it on either of my systems, so
I have no way of narrowing it down.  FWIW, I did a comparison of /boot/grub/*
from a broken system and my own and they are byte-for-byte identical.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]