[gentoo-user] emerge firefox-52.4.0 compile failure

[gentoo-user] emerge firefox-52.4.0 compile failure

[Grant Edwards]

When I did my usual update today firefox 52.4.0 failed to build.
There are thousands of compiler warnings in the build log, but the
only thing I can find that looks like an error is this:

/usr/bin/x86_64-pc-linux-gnu-g++ [...] /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/ff/gfx/thebes/Unified_cpp_gfx_thebes0.cpp
[...]
In file included from /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/ff/gfx/thebes/Unified_cpp_gfx_thebes0.cpp:65:0:
/var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebes/gfxFont.cpp:2625:29: error: 'mozilla::gfx::ShapedTextFlags' has not been declared
/var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebes/gfxFont.cpp:2626:24: error: 'RoundingFlags' has not been declared
/var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebes/gfxFont.cpp:2618:1: error: template-id 'GetShapedWord<>' for 'gfxShapedWord* gfxFont::GetShapedWord(gfxFont::DrawTarget*, const uint8_t*, uint32_t, uint32_t, gfxFont::Script, bool, int32_t, int, int, gfxTextPerfMetrics*)' does not match any template declaration
[...]
make[4]: *** [/var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/config/rules.mk:951: Unified_cpp_gfx_thebes0.o] Error 1
make[4]: *** Waiting for unfinished jobs....

Google provides zero hits for any of those three errors.

Does this look familiar to anybody?

--
Grant

Re: [gentoo-user] emerge firefox-52.4.0 compile failure

[Mick]

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

On Sunday, 8 October 2017 03:51:41 BST Grant Edwards wrote:
> When I did my usual update today firefox 52.4.0 failed to build.
> There are thousands of compiler warnings in the build log, but the
> only thing I can find that looks like an error is this:
> 
> /usr/bin/x86_64-pc-linux-gnu-g++ [...]
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/ff/gfx/th
> ebes/Unified_cpp_gfx_thebes0.cpp [...]
> In file included from
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/ff/gfx/th
> ebes/Unified_cpp_gfx_thebes0.cpp:65:0:
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebe
> s/gfxFont.cpp:2625:29: error: 'mozilla::gfx::ShapedTextFlags' has not been
> declared
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebe
> s/gfxFont.cpp:2626:24: error: 'RoundingFlags' has not been declared
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebe
> s/gfxFont.cpp:2618:1: error: template-id 'GetShapedWord<>' for
> 'gfxShapedWord* gfxFont::GetShapedWord(gfxFont::DrawTarget*, const
> uint8_t*, uint32_t, uint32_t, gfxFont::Script, bool, int32_t, int, int,
> gfxTextPerfMetrics*)' does not match any template declaration [...]
> make[4]: ***
> [/var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/config/r
> ules.mk:951: Unified_cpp_gfx_thebes0.o] Error 1 make[4]: *** Waiting for
> unfinished jobs....
> 
> Google provides zero hits for any of those three errors.
> 
> Does this look familiar to anybody?
> 
> --
> Grant

Your compiler is barfing at something, but I'm no coder to know what this 
might be.  In a Gentoo context, I'd start by checking you have installed and 
switched to sys-devel/gcc-5.4.0-r3 which is the latest stable version and at 
least here compiled and installed firefox-52.4.0 on 4 PCs without a problem.

-- 
Regards,
Mick

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

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-08, Mick <michaelkintzios@gmail.com> wrote:
> On Sunday, 8 October 2017 03:51:41 BST Grant Edwards wrote:
>> When I did my usual update today firefox 52.4.0 failed to build.
>> There are thousands of compiler warnings in the build log, but the
>> only thing I can find that looks like an error is this:

[...]

>> Google provides zero hits for any of those three errors.

> Your compiler is barfing at something, but I'm no coder to know what
> this might be.

Yes, thanks, those are g++ compiler error messages.  I could track
down and fix the problem in the source code, but since it's a "stable"
system, and firefox builds fine on other systems, I should have to do
that.

> In a Gentoo context, I'd start by checking you have installed and 
> switched to sys-devel/gcc-5.4.0-r3

Yep, I'm using gcc-5.4.0-r3.  There were 20+ other packages that got
built in that same upgrade, and they all went fine.

> which is the latest stable version and at least here compiled and
> installed firefox-52.4.0 on 4 PCs without a problem.

As have I.

I was afraid it might be failing RAM, but a second attempt failed in
exactly the same way.  I guess I'll delete the ebuild files and the
source tarball to force a download and then try again.

-- 
Grant

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Mick]

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

On Sunday, 8 October 2017 18:02:43 BST Grant Edwards wrote:

> I was afraid it might be failing RAM, but a second attempt failed in
> exactly the same way.  I guess I'll delete the ebuild files and the
> source tarball to force a download and then try again.

This won't harm, although I would expect portage would complain and not run 
the emerge if downloads were corrupted somehow.
-- 
Regards,
Mick

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

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-08, Mick <michaelkintzios@gmail.com> wrote:
> On Sunday, 8 October 2017 18:02:43 BST Grant Edwards wrote:
>
>> I was afraid it might be failing RAM, but a second attempt failed in
>> exactly the same way.  I guess I'll delete the ebuild files and the
>> source tarball to force a download and then try again.

Same error.

> This won't harm, although I would expect portage would complain and
> not run the emerge if downloads were corrupted somehow.

True, but I couldn't think of anything else to try.  I'm building
chromium now -- it may be time to give up on firefox.  It's been
bahaving badly on several of my systems for a while now (burning 100%
cpu and using up huge amounts of RAM for minutes at a time while
apparently doing nothing).

-- 
Grant

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[R0b0t1]

On Sun, Oct 8, 2017 at 1:54 PM, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> On 2017-10-08, Mick <michaelkintzios@gmail.com> wrote:
>> This won't harm, although I would expect portage would complain and
>> not run the emerge if downloads were corrupted somehow.
>
> True, but I couldn't think of anything else to try.  I'm building
> chromium now -- it may be time to give up on firefox.  It's been
> bahaving badly on several of my systems for a while now (burning 100%
> cpu and using up huge amounts of RAM for minutes at a time while
> apparently doing nothing).
>

Usually what happens is it will be corrupted in RAM after being
verified on disk, and faulty results will be saved to disk from RAM. A
user on the forums recently had this issue compiling dev-lang/vala,
and I have had related issues.

As for what the error means: definitions are missing, which from an
end-user perspective is not really a fixable issue. I would rerun the
compilation with -j1 if you have not already done so. If other people
can build the package then portage may be munging the files in some
way, but these issues are hard to diagnose.

Cheers,
     R0b0t1

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-08, R0b0t1 <r030t1@gmail.com> wrote:

> Usually what happens is it will be corrupted in RAM after being
> verified on disk, and faulty results will be saved to disk from RAM. A
> user on the forums recently had this issue compiling dev-lang/vala,
> and I have had related issues.

I've had failing RAM corrupt files and cause compile failures (and 
various other odd problems). But, the exact symptoms tend to be pretty
random.  The chances are infinitesmal that a HW problem would corrupt
the download (or the compile itself) in an identical manner a second
time.

> As for what the error means: definitions are missing, which from an
> end-user perspective is not really a fixable issue.

Sometimes there are external library version/use-flag requirements
that don't make it into an ebuild file correctly.  But, all the other
cases I've run into like that yielded plenty of Google hits on the
error messages.

> I would rerun the compilation with -j1 if you have not already done
> so.

I'm going to try that as soon as chromium finishes building.

> If other people can build the package then portage may be munging the
> files in some way, but these issues are hard to diagnose.

-- 
Grant

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[R0b0t1]

On Sun, Oct 8, 2017 at 4:53 PM, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> On 2017-10-08, R0b0t1 <r030t1@gmail.com> wrote:
>
>> Usually what happens is it will be corrupted in RAM after being
>> verified on disk, and faulty results will be saved to disk from RAM. A
>> user on the forums recently had this issue compiling dev-lang/vala,
>> and I have had related issues.
>
> I've had failing RAM corrupt files and cause compile failures (and
> various other odd problems). But, the exact symptoms tend to be pretty
> random.  The chances are infinitesmal that a HW problem would corrupt
> the download (or the compile itself) in an identical manner a second
> time.
>

Right, redownloading or rerunning the compilation usually fixes such
issues. At the same time, I have seen people hit bad areas of RAM
repeatedly and have it look like other errors.

>> As for what the error means: definitions are missing, which from an
>> end-user perspective is not really a fixable issue.
>
> Sometimes there are external library version/use-flag requirements
> that don't make it into an ebuild file correctly.  But, all the other
> cases I've run into like that yielded plenty of Google hits on the
> error messages.
>

In this case the namespace of the missing declaration is inside
Mozilla's, e.g. it is part of Firefox or a closely bundled library.

Cheers,
    R0b0t1

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-09, R0b0t1 <r030t1@gmail.com> wrote:

> In this case the namespace of the missing declaration is inside
> Mozilla's, e.g. it is part of Firefox or a closely bundled library.

Yep, after a bit more research, that was my conclusion.

The chromium build finished happily, so I've just started another
firefox build with MAKEOPTS=-j1.  

The USE flag settings for firefox appear to be the same as my other
systems where it builds without error.

Weird.

-- 
Grant

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-09, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> On 2017-10-09, R0b0t1 <r030t1@gmail.com> wrote:
>
>> In this case the namespace of the missing declaration is inside
>> Mozilla's, e.g. it is part of Firefox or a closely bundled library.
>
> Yep, after a bit more research, that was my conclusion.
>
> The chromium build finished happily, so I've just started another
> firefox build with MAKEOPTS=-j1.  

Same error.  But at least it's at the end of the build log now where
it's easy to find. :)

I guess I'll wait for the next firefox ESR update and see if that one
builds.

-- 
Grant

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[allan gottlieb]

On Mon, Oct 09 2017, Grant Edwards wrote:

> On 2017-10-09, Grant Edwards <grant.b.edwards@gmail.com> wrote:
>> On 2017-10-09, R0b0t1 <r030t1@gmail.com> wrote:
>>
>>> In this case the namespace of the missing declaration is inside
>>> Mozilla's, e.g. it is part of Firefox or a closely bundled library.
>>
>> Yep, after a bit more research, that was my conclusion.
>>
>> The chromium build finished happily, so I've just started another
>> firefox build with MAKEOPTS=-j1.  
>
> Same error.  But at least it's at the end of the build log now where
> it's easy to find. :)
>
> I guess I'll wait for the next firefox ESR update and see if that one
> builds.

This is a know bug see https://bugs.gentoo.org/633790

allan

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-09, allan gottlieb <gottlieb@nyu.edu> wrote:

> This is a know bug see https://bugs.gentoo.org/633790

Yep, that's it.  Yet when you search for roundingflags or
shapedtextflags in Gentoo's bugzilla, it finds nothing.  Has the
search feature in Bugzilla ever worked?

-- 
Grant Edwards               grant.b.edwards        Yow! Four thousand
                                  at               different MAGNATES, MOGULS
                              gmail.com            & NABOBS are romping in my
                                                   gothic solarium!!

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-08, Mick <michaelkintzios@gmail.com> wrote:

> Your compiler is barfing at something, but I'm no coder to know what this 
> might be.  In a Gentoo context, I'd start by checking you have installed and 
> switched to sys-devel/gcc-5.4.0-r3 which is the latest stable version and at 
> least here compiled and installed firefox-52.4.0 on 4 PCs without a problem.

It turns out that over the past week or so, there have been several
_different_ firefox ebuilds released.  One of them was broken:

  Version 52.4.0 (Oct 3) was OK.

  Version 52.4.0 (Oct 7) was broken.

  Version 52.4.0 (Oct 9) is OK.

You (and I) had successfully installed the Oct 3 version of 52.4.0,
but when I tried to install the Oct 7 version of 52.4.0, it failed.
The Oct 9 version is supposed to be fixed. I don't really see how you
can repeatedly release new versions of something without changing the
version number, but maybe that's just me...

-- 
Grant Edwards               grant.b.edwards        Yow! Being a BALD HERO
                                  at               is almost as FESTIVE as a
                              gmail.com            TATTOOED KNOCKWURST.

Re: [gentoo-user] emerge firefox-52.4.0 compile failure

[R0b0t1]

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

On Monday, October 9, 2017, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> On 2017-10-09, allan gottlieb <gottlieb@nyu.edu> wrote:
>
>> This is a know bug see https://bugs.gentoo.org/633790
>
> Yep, that's it.  Yet when you search for roundingflags or
> shapedtextflags in Gentoo's bugzilla, it finds nothing.  Has the
> search feature in Bugzilla ever worked?
>

It's pretty limited. You might notice developers renaming bugs - this is
why. They usually include the full package name and version in their
rename, as well as the exact text from the last or most important error
encountered.

I filed a bug against nvidia-drivers last night which was a duplicate of
something that came up in the automatic search. It's hard to canvas the
tracker exhaustively.

R0b0t1.

[-- Attachment #2: Type: text/html, Size: 1002 bytes --]

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-09, R0b0t1 <r030t1@gmail.com> wrote:
> On Monday, October 9, 2017, Grant Edwards <grant.b.edwards@gmail.com> wrote:
>> On 2017-10-09, allan gottlieb <gottlieb@nyu.edu> wrote:
>>
>>> This is a know bug see https://bugs.gentoo.org/633790
>>
>> Yep, that's it.  Yet when you search for roundingflags or
>> shapedtextflags in Gentoo's bugzilla, it finds nothing.  Has the
>> search feature in Bugzilla ever worked?
>
> It's pretty limited.

You're being too kind.  It's broken.  According to the bugzilla web
page, the search includes the summary/description (as one might
expect), but it doesn't actually _do_ that.

> You might notice developers renaming bugs -
> this is why. They usually include the full package name and version
> in their rename, as well as the exact text from the last or most
> important error encountered.

Why do people still use bugzilla??

I've used MantisBT a lot over the past few years, and it seems like it
works much better than bugzilla in many ways. It even has a search
that works!  Even Jira was better than bugzilla, and I never liked
Jira much.

Of course switching from one bug tracking system to another is a
pretty big undertaking...

--
Grant

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[R0b0t1]

On Mon, Oct 9, 2017 at 7:57 PM, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> On 2017-10-09, R0b0t1 <r030t1@gmail.com> wrote:
>> On Monday, October 9, 2017, Grant Edwards <grant.b.edwards@gmail.com> wrote:
>>> On 2017-10-09, allan gottlieb <gottlieb@nyu.edu> wrote:
>>>
>>>> This is a know bug see https://bugs.gentoo.org/633790
>>>
>>> Yep, that's it.  Yet when you search for roundingflags or
>>> shapedtextflags in Gentoo's bugzilla, it finds nothing.  Has the
>>> search feature in Bugzilla ever worked?
>>
>> It's pretty limited.
>
> You're being too kind.  It's broken.  According to the bugzilla web
> page, the search includes the summary/description (as one might
> expect), but it doesn't actually _do_ that.
>

Well, it successfully searches for substrings.

>> You might notice developers renaming bugs -
>> this is why. They usually include the full package name and version
>> in their rename, as well as the exact text from the last or most
>> important error encountered.
>
> Why do people still use bugzilla??
>
> I've used MantisBT a lot over the past few years, and it seems like it
> works much better than bugzilla in many ways. It even has a search
> that works!  Even Jira was better than bugzilla, and I never liked
> Jira much.
>
> Of course switching from one bug tracking system to another is a
> pretty big undertaking...
>

I worked with a project that used Mantis and had a good experience
with it. At this point I'm not sure it would be possible to get people
to switch.

There are a few migration scripts:
http://www.mantisbt.org/wiki/doku.php/mantisbt:faq.

R0b0t1.

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Peter Humphrey]

On Monday, 9 October 2017 20:20:53 BST Grant Edwards wrote:

> I don't really see how you can repeatedly release new versions of
> something without changing the version number, but maybe that's just me...

No, it isn't just you. What you describe is a classic example of a developer 
trying to hide his mistakes - strictly unprofessional. It would not have 
been allowed anywhere I've worked.

I know that volunteers are hard to find, but even so ...

Good work spotting the trail, by the way.

-- 
Regards,
Peter.

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Marc Joliet]

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

Am Dienstag, 10. Oktober 2017, 11:19:02 CEST schrieb Peter Humphrey:
> On Monday, 9 October 2017 20:20:53 BST Grant Edwards wrote:
> > I don't really see how you can repeatedly release new versions of
> > something without changing the version number, but maybe that's just me...
> 
> No, it isn't just you. What you describe is a classic example of a developer
> trying to hide his mistakes - strictly unprofessional. It would not have
> been allowed anywhere I've worked.
> 
> I know that volunteers are hard to find, but even so ...
> 
> Good work spotting the trail, by the way.

It's actually simpler than that: ebuilds do not need a revision bump when 
fixing compilation errors, since the ebuild remains uninstalled [0].  And if 
you /were/ able to build it, you won't profit from a revbump, either (in fact, 
people tend to loudly complain about unnecessary rebuilds).  So, no, it most 
likely is /not/ someone trying to hide their mistakes.  Never mind that the 
changes are easy to find in Gentoo's version control history [1], which 
references bug #633640, which in turn reveals that they were trying to fix a 
build error, but accidentally caused another in the process.  So, yeah, so 
much hiding going on here!

[0] https://devmanual.gentoo.org/general-concepts/ebuild-revisions/
[1] https://gitweb.gentoo.org/repo/gentoo.git/log/?qt=grep&q=firefox

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

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

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Marc Joliet]

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

Am Dienstag, 10. Oktober 2017, 02:57:21 CEST schrieb Grant Edwards:
> On 2017-10-09, R0b0t1 <r030t1@gmail.com> wrote:
> > On Monday, October 9, 2017, Grant Edwards <grant.b.edwards@gmail.com> 
wrote:
> >> On 2017-10-09, allan gottlieb <gottlieb@nyu.edu> wrote:
> >>> This is a know bug see https://bugs.gentoo.org/633790
> >> 
> >> Yep, that's it.  Yet when you search for roundingflags or
> >> shapedtextflags in Gentoo's bugzilla, it finds nothing.  Has the
> >> search feature in Bugzilla ever worked?
> > 
> > It's pretty limited.

Do you still think so when you consider the advanced search (or the saved 
search feature)?  Just curious, since I don't tend to perform complicated 
searches in any of the bug trackers I use.

> You're being too kind.  It's broken.  According to the bugzilla web
> page, the search includes the summary/description (as one might
> expect), but it doesn't actually _do_ that.

It does exactly what it says, e.g., when I search for qt I see:

"     Status: UNCONFIRMED, CONFIRMED, IN_PROGRESS Alias: qt Summary: qt "

And it shows me exactly that: bugs with qt in the summary or as part of the 
alias that have their status set to UNCONFIRMED, CONFIRMED, or IN_PROGRESS.  
(Note that it does *not* search the description by default, and doesn't claim 
to, either!)

Now, it could be that other search filters are preventing you from finding 
bugs.  For example, as in my above example, bugs with their status set to 
"RESOLVED" or "VERIFIED" are not searched by default (searching only for 
VERIFIED found 120 additional bugs).  Or, more likely, your search strings 
simply aren't part of the summary.

Of course, it's not like I actively like bugzilla, but it's not quite 
"broken", either.  "Baroque" might be a better word ;) .

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

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

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Neil Bothwick]

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

On Mon, 9 Oct 2017 19:20:53 +0000 (UTC), Grant Edwards wrote:

> It turns out that over the past week or so, there have been several
> _different_ firefox ebuilds released.  One of them was broken:
> 
>   Version 52.4.0 (Oct 3) was OK.
> 
>   Version 52.4.0 (Oct 7) was broken.
> 
>   Version 52.4.0 (Oct 9) is OK.
> 
> You (and I) had successfully installed the Oct 3 version of 52.4.0,
> but when I tried to install the Oct 7 version of 52.4.0, it failed.
> The Oct 9 version is supposed to be fixed. I don't really see how you
> can repeatedly release new versions of something without changing the
> version number, but maybe that's just me...

It depends on the breakage. If the installed program is broken it should
be bumped, but if the breakage only relates to the build in some
circumstances, it makes sense not to bump it. Otherwise everyone that
installed the first time, maybe because they had the necessary
dependencies already, would have to re-emerge the package another two
times for no benefit.

If they truly were new versions it would be different, but all the ebuilds
resulted in the same version of the software being installed.


-- 
Neil Bothwick

Puns are bad, but poetry is verse...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Marc Joliet]

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

Am Dienstag, 10. Oktober 2017, 12:27:25 CEST schrieb Marc Joliet:
> (Note that it does *not* search the description by default, and doesn't
> claim to, either!)

Ha, I tried to find a way to search only the description, but came up empty 
(you *can* search the description by searching through all comments, though).  
I then found this: https://stackoverflow.com/questions/33493375/bugzilla-how-to-search-in-the-description-of-the-bug-reports.  Does anybody on this list 
know if it's possible?  Maybe in newer versions of bugzilla?  (I vaguely 
remember that Gentoo runs an older one.)

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

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

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Peter Humphrey]

On Tuesday, 10 October 2017 11:46:22 BST Neil Bothwick wrote:
> On Mon, 9 Oct 2017 19:20:53 +0000 (UTC), Grant Edwards wrote:
> > It turns out that over the past week or so, there have been several
> > 
> > _different_ firefox ebuilds released.  One of them was broken:
> >   Version 52.4.0 (Oct 3) was OK.
> >   
> >   Version 52.4.0 (Oct 7) was broken.
> >   
> >   Version 52.4.0 (Oct 9) is OK.
> > 
> > You (and I) had successfully installed the Oct 3 version of 52.4.0,
> > but when I tried to install the Oct 7 version of 52.4.0, it failed.
> > The Oct 9 version is supposed to be fixed. I don't really see how you
> > can repeatedly release new versions of something without changing the
> > version number, but maybe that's just me...
> 
> It depends on the breakage. If the installed program is broken it should
> be bumped, but if the breakage only relates to the build in some
> circumstances, it makes sense not to bump it. Otherwise everyone that
> installed the first time, maybe because they had the necessary
> dependencies already, would have to re-emerge the package another two
> times for no benefit.
> 
> If they truly were new versions it would be different, but all the ebuilds
> resulted in the same version of the software being installed.

I see what you mean, but in that case the development management model is 
broken. It's sacrificing correctness and rigour to convenience. It needs a 
review at the highest level. What's called Management in ISO9000.

-- 
Regards,
Peter.

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[R0b0t1]

On Tue, Oct 10, 2017 at 6:30 PM, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
> What's called Management in ISO9000.
>

ISO9000 still lets you shoot yourself in the foot. You just wrote down
that you were going to shoot yourself in the foot well in advance.

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Peter Humphrey]

On Wednesday, 11 October 2017 04:02:36 BST R0b0t1 wrote:
> On Tue, Oct 10, 2017 at 6:30 PM, Peter Humphrey <peter@prh.myzen.co.uk> 
> wrote:
> > What's called Management in ISO9000.
> 
> ISO9000 still lets you shoot yourself in the foot. You just wrote down
> that you were going to shoot yourself in the foot well in advance.

It aims to ensure that what is produced is exactly what is intended. If 
shooting yourself in the foot is a credible business objective, so be it, 
but you'd have trouble showing how the business would benefit from it, or in 
persuading an auditor. Or the shareholders in the business, for that matter.

ISO9000 operates at company management level, not programmer level.

Actually, I can't be authoritative on ISO 9000 today; my experience dates 
back 20 years, to when I got a varied group of 100 software people through 
an audit against ISO 9001 (long story, not relevant here). I don't suppose 
the principles will have changed much though.

-- 
Regards,
Peter.

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-11, R0b0t1 <r030t1@gmail.com> wrote:
> On Tue, Oct 10, 2017 at 6:30 PM, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>> What's called Management in ISO9000.
>
> ISO9000 still lets you shoot yourself in the foot. You just wrote
> down that you were going to shoot yourself in the foot well in
> advance.

Yep.  As somebody involved in the ISO9000 effort at a large
manufacturer once told me: "Being ISO9000 compliant doesn't prevent
you from shipping low-quality crap products.  It just means that you
_know_ you're shipping low-quality crap products."

The assumption presumably being that your _customers_ could also
figure that out from reviewing your ISO9000 documentation.  I have no
idea how many customers actually do a good enough review of their
vendors' ISO9000 documents to figure it out...

-- 
Grant Edwards               grant.b.edwards        Yow! Inside, I'm already
                                  at               SOBBING!
                              gmail.com            

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[mad.scientist.at.large]

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

it's worth noting that a failing power supply can produce what seem to be ram problems.  it happened to me, swapping ram, a motherboard and then a power supply made it clear.

--
Note the right side (his right) of Mr. Trumps face, He's clearly had a major stroke or similar neurological insult.   The eye always droops, and that side of his mouth hardly moves when he speaks.  I try not to throw stones from inside my glass house, others obviously don't mind hypocrisy.


8. Oct 2017 18:14 by r030t1@gmail.com:


> On Sun, Oct 8, 2017 at 4:53 PM, Grant Edwards <> grant.b.edwards@gmail.com> > wrote:
>> On 2017-10-08, R0b0t1 <>> r030t1@gmail.com>> > wrote:
>>
>>> Usually what happens is it will be corrupted in RAM after being
>>> verified on disk, and faulty results will be saved to disk from RAM. A
>>> user on the forums recently had this issue compiling dev-lang/vala,
>>> and I have had related issues.
>>
>> I've had failing RAM corrupt files and cause compile failures (and
>> various other odd problems). But, the exact symptoms tend to be pretty
>> random.  The chances are infinitesmal that a HW problem would corrupt
>> the download (or the compile itself) in an identical manner a second
>> time.
>>
>
> Right, redownloading or rerunning the compilation usually fixes such
> issues. At the same time, I have seen people hit bad areas of RAM
> repeatedly and have it look like other errors.
> --------------------------snip
> Cheers,
>     R0b0t1

[-- Attachment #2: Type: text/html, Size: 2102 bytes --]