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

2017-10-11 Thread mad.scientist.at.large 
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 r03...@gmail.com:


> On Sun, Oct 8, 2017 at 4:53 PM, Grant Edwards <> grant.b.edwa...@gmail.com> > 
> wrote:
>> On 2017-10-08, R0b0t1 <>> r03...@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

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

2017-10-11 Thread Grant Edwards 
On 2017-10-11, R0b0t1  wrote:
> On Tue, Oct 10, 2017 at 6:30 PM, Peter Humphrey  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.edwardsYow! Inside, I'm already
  at   SOBBING!
  gmail.com

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

2017-10-11 Thread Peter Humphrey 
On Wednesday, 11 October 2017 04:02:36 BST R0b0t1 wrote:
> On Tue, Oct 10, 2017 at 6:30 PM, Peter Humphrey  
> 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.

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

2017-10-10 Thread R0b0t1 
On Tue, Oct 10, 2017 at 6:30 PM, Peter Humphrey  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

2017-10-10 Thread Peter Humphrey 
On Tuesday, 10 October 2017 11:46:22 BST Neil Bothwick wrote:
> On Mon, 9 Oct 2017 19:20:53 + (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

2017-10-10 Thread Marc Joliet 
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


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

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

2017-10-10 Thread Neil Bothwick 
On Mon, 9 Oct 2017 19:20:53 + (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...


pgpgALZN7yARx.pgp
Description: OpenPGP digital signature

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

2017-10-10 Thread Marc Joliet 
Am Dienstag, 10. Oktober 2017, 02:57:21 CEST schrieb Grant Edwards:
> On 2017-10-09, R0b0t1  wrote:
> > On Monday, October 9, 2017, Grant Edwards  
wrote:
> >> On 2017-10-09, allan gottlieb  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


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

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

2017-10-10 Thread Marc Joliet 
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=firefox

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


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

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

2017-10-10 Thread 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

2017-10-09 Thread R0b0t1 
On Mon, Oct 9, 2017 at 7:57 PM, Grant Edwards  wrote:
> On 2017-10-09, R0b0t1  wrote:
>> On Monday, October 9, 2017, Grant Edwards  wrote:
>>> On 2017-10-09, allan gottlieb  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.

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

2017-10-09 Thread Grant Edwards 
On 2017-10-09, R0b0t1  wrote:
> On Monday, October 9, 2017, Grant Edwards  wrote:
>> On 2017-10-09, allan gottlieb  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

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

2017-10-09 Thread Grant Edwards 
On 2017-10-08, Mick  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.edwardsYow! Being a BALD HERO
  at   is almost as FESTIVE as a
  gmail.comTATTOOED KNOCKWURST.

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

2017-10-09 Thread Grant Edwards 
On 2017-10-09, allan gottlieb  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.edwardsYow! Four thousand
  at   different MAGNATES, MOGULS
  gmail.com& NABOBS are romping in my
   gothic solarium!!

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

2017-10-08 Thread allan gottlieb 
On Mon, Oct 09 2017, Grant Edwards wrote:

> On 2017-10-09, Grant Edwards  wrote:
>> On 2017-10-09, R0b0t1  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

2017-10-08 Thread Grant Edwards 
On 2017-10-09, Grant Edwards  wrote:
> On 2017-10-09, R0b0t1  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

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

2017-10-08 Thread Grant Edwards 
On 2017-10-09, R0b0t1  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

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

2017-10-08 Thread R0b0t1 
On Sun, Oct 8, 2017 at 4:53 PM, Grant Edwards  wrote:
> On 2017-10-08, R0b0t1  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

2017-10-08 Thread Grant Edwards 
On 2017-10-08, R0b0t1  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

2017-10-08 Thread R0b0t1 
On Sun, Oct 8, 2017 at 1:54 PM, Grant Edwards  wrote:
> On 2017-10-08, Mick  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

2017-10-08 Thread Grant Edwards 
On 2017-10-08, Mick  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

2017-10-08 Thread Mick 
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

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

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

2017-10-08 Thread Grant Edwards 
On 2017-10-08, Mick  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