Re: [blfs-dev] firefox-69.0 ftbfs

2019-09-03 Thread Tim Tassonis via blfs-dev

On 9/3/19 7:44 PM, Ken Moffat via blfs-dev wrote:

On Tue, Sep 03, 2019 at 06:56:11PM +0200, Tim Tassonis via blfs-dev wrote:

On 9/3/19 2:43 AM, Ken Moffat via blfs-dev wrote:

On Tue, Sep 03, 2019 at 12:19:46AM +0100, Ken Moffat via blfs-dev wrote:

Looks as if dbus-glib should now be required (the book comments it
because it used to be optional).  With that enabled, I completed
the build.

Arguably, it might be better as 'recommended', since the configury
doesn't seem to require it, but since that doesn't link with the
other options i nthe book I'm minded to make it required.

So, on this occasion my apologies for blaming r..t (but I still
think it is a house of cards).



Ok, so since I'm already using dbus-glib, I should be ok?



Yes.



I'm using rustc 1.35.0 and cbindgen 0.9.0, as in the book.



I built it successfully after removing that option from the
mozconfig.  All package versions as in the 9.0 book.  (Also built
successfully on 8.4 and even 8.3, I've stopped trying to maintain
older systems - I was keeping a couple of old, and now very slow,
boxes for that, but once I moved my so-called server to using hdmi,
the shared monitor doesn't use its vga input if the hdmi input is
active).



Bye
Tim


And it's now in the book.  Hope it works well for you (I've stopped
testing the alsa option, that was only used on one of the old
machines).



Just finished the build, ran it and it plays sound all nicely. So, all 
is well.




Bye
Tim
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


Re: [blfs-dev] firefox-69.0 ftbfs

2019-09-03 Thread Tim Tassonis via blfs-dev

On 9/3/19 7:44 PM, Ken Moffat via blfs-dev wrote:

On Tue, Sep 03, 2019 at 06:56:11PM +0200, Tim Tassonis via blfs-dev wrote:

On 9/3/19 2:43 AM, Ken Moffat via blfs-dev wrote:

On Tue, Sep 03, 2019 at 12:19:46AM +0100, Ken Moffat via blfs-dev wrote:

Looks as if dbus-glib should now be required (the book comments it
because it used to be optional).  With that enabled, I completed
the build.

Arguably, it might be better as 'recommended', since the configury
doesn't seem to require it, but since that doesn't link with the
other options i nthe book I'm minded to make it required.

So, on this occasion my apologies for blaming r..t (but I still
think it is a house of cards).



Ok, so since I'm already using dbus-glib, I should be ok?



Yes.



I'm using rustc 1.35.0 and cbindgen 0.9.0, as in the book.



I built it successfully after removing that option from the
mozconfig.  All package versions as in the 9.0 book.  (Also built
successfully on 8.4 and even 8.3, I've stopped trying to maintain
older systems - I was keeping a couple of old, and now very slow,
boxes for that, but once I moved my so-called server to using hdmi,
the shared monitor doesn't use its vga input if the hdmi input is
active).



Bye
Tim


And it's now in the book.  Hope it works well for you (I've stopped
testing the alsa option, that was only used on one of the old
machines).


After finally upgrading harfbuzz to 2.6.1, the compile now kicked off 
and is running. I still use alsa (as long a I still can), so I can 
report back if that still works.



Bye
Tim
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


Re: [blfs-dev] firefox-69.0 ftbfs

2019-09-03 Thread dueffert--- via blfs-dev

Hi,

On Tue, 3 Sep 2019, Ken Moffat via blfs-dev wrote:


On Tue, Sep 03, 2019 at 06:56:11PM +0200, Tim Tassonis via blfs-dev wrote:

On 9/3/19 2:43 AM, Ken Moffat via blfs-dev wrote:

On Tue, Sep 03, 2019 at 12:19:46AM +0100, Ken Moffat via blfs-dev wrote:

Looks as if dbus-glib should now be required (the book comments it
because it used to be optional).  With that enabled, I completed
the build.
I can confirm too that (glib-dbus being istalled anyway) commenting out 
--disable-dbus makes the difference between firefox-69.0 not compiling and 
running fine.



I'm using rustc 1.35.0 and cbindgen 0.9.0, as in the book.

rustc-1.36.0 and cbindgen-0.9.1 here


And it's now in the book. Hope it works well for you

For me it does.

(I've stopped testing the alsa option, that was only used on one of the 
old machines).

--disable-pulsaudio --enable-alsa works pretty well, including e.g.
alsa-configured upmix from stereo to 7.1 for Youtube videos...

Uwe
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


Re: [blfs-dev] firefox-69.0 ftbfs

2019-09-03 Thread Ken Moffat via blfs-dev
On Tue, Sep 03, 2019 at 06:56:11PM +0200, Tim Tassonis via blfs-dev wrote:
> On 9/3/19 2:43 AM, Ken Moffat via blfs-dev wrote:
> > On Tue, Sep 03, 2019 at 12:19:46AM +0100, Ken Moffat via blfs-dev wrote:
> > 
> > Looks as if dbus-glib should now be required (the book comments it
> > because it used to be optional).  With that enabled, I completed
> > the build.
> > 
> > Arguably, it might be better as 'recommended', since the configury
> > doesn't seem to require it, but since that doesn't link with the
> > other options i nthe book I'm minded to make it required.
> > 
> > So, on this occasion my apologies for blaming r..t (but I still
> > think it is a house of cards).
> 
> 
> Ok, so since I'm already using dbus-glib, I should be ok?
> 

Yes.

> 
> I'm using rustc 1.35.0 and cbindgen 0.9.0, as in the book.
> 

I built it successfully after removing that option from the
mozconfig.  All package versions as in the 9.0 book.  (Also built
successfully on 8.4 and even 8.3, I've stopped trying to maintain
older systems - I was keeping a couple of old, and now very slow,
boxes for that, but once I moved my so-called server to using hdmi,
the shared monitor doesn't use its vga input if the hdmi input is
active).

> 
> Bye
> Tim

And it's now in the book.  Hope it works well for you (I've stopped
testing the alsa option, that was only used on one of the old
machines).

ĸen
-- 
thread 'main' panicked at 'giraffe',
/tmp/rustc-1.32.0-src/src/test/run-fail/while-panic.rs:17:13
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


Re: [blfs-dev] firefox-69.0 ftbfs

2019-09-03 Thread Tim Tassonis via blfs-dev

On 9/3/19 2:43 AM, Ken Moffat via blfs-dev wrote:

On Tue, Sep 03, 2019 at 12:19:46AM +0100, Ken Moffat via blfs-dev wrote:

On Mon, Sep 02, 2019 at 11:08:09AM +0200, gabriele balducci via blfs-dev wrote:

Looking at fedora,
https://src.fedoraproject.org/rpms/firefox/tree/master they seem to
manage to build some sort of 69.0 but using a "shipped" cbindgen
(and I've no idea where/how they got that).  Without system


I usually (since 66.0) build cbindgen on the fly (as one of the very
first steps during firefox build) and catch the "good" version to be built
from these two locations in the FF tree:

  taskcluster/scripts/misc/build-cbindgen.sh
  build/moz.configure/bindgen.configure


Short summary: anything using the r language (as distinct from R
which is probably a perfectly good language) is a house of cards
built on sand, any help in resolving this would be welcome.


hope this helps

ciao
gabriele


Thanks Gabriele.

I notice that the git hash has a comment '# V0.9.0' which is what
I've been using.  so, I don't think this is the cause of my problem.


Indeed it was not.  For my own builds I use a mozconfig with the
correct options for what I am doing.  But when measuring a vanilla
build for the book I usually copy the mozconfig that is in the book.

Looks as if dbus-glib should now be required (the book comments it
because it used to be optional).  With that enabled, I completed
the build.

Arguably, it might be better as 'recommended', since the configury
doesn't seem to require it, but since that doesn't link with the
other options i nthe book I'm minded to make it required.

So, on this occasion my apologies for blaming r..t (but I still
think it is a house of cards).



Ok, so since I'm already using dbus-glib, I should be ok?


I'm using rustc 1.35.0 and cbindgen 0.9.0, as in the book.


Bye
Tim
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


Re: [blfs-dev] firefox-69.0 ftbfs

2019-09-02 Thread Ken Moffat via blfs-dev
On Tue, Sep 03, 2019 at 12:19:46AM +0100, Ken Moffat via blfs-dev wrote:
> On Mon, Sep 02, 2019 at 11:08:09AM +0200, gabriele balducci via blfs-dev 
> wrote:
> > > Looking at fedora,
> > > https://src.fedoraproject.org/rpms/firefox/tree/master they seem to
> > > manage to build some sort of 69.0 but using a "shipped" cbindgen
> > > (and I've no idea where/how they got that).  Without system
> > 
> > I usually (since 66.0) build cbindgen on the fly (as one of the very
> > first steps during firefox build) and catch the "good" version to be built
> > from these two locations in the FF tree:
> > 
> >  taskcluster/scripts/misc/build-cbindgen.sh
> >  build/moz.configure/bindgen.configure
> > 
> > > Short summary: anything using the r language (as distinct from R
> > > which is probably a perfectly good language) is a house of cards
> > > built on sand, any help in resolving this would be welcome.
> > 
> > hope this helps
> > 
> > ciao
> > gabriele
> 
> Thanks Gabriele.
> 
> I notice that the git hash has a comment '# V0.9.0' which is what
> I've been using.  so, I don't think this is the cause of my problem.
> 
Indeed it was not.  For my own builds I use a mozconfig with the
correct options for what I am doing.  But when measuring a vanilla
build for the book I usually copy the mozconfig that is in the book.

Looks as if dbus-glib should now be required (the book comments it
because it used to be optional).  With that enabled, I completed
the build.

Arguably, it might be better as 'recommended', since the configury
doesn't seem to require it, but since that doesn't link with the
other options i nthe book I'm minded to make it required.

So, on this occasion my apologies for blaming r..t (but I still
think it is a house of cards).

ĸen
-- 
thread 'main' panicked at 'giraffe',
/tmp/rustc-1.32.0-src/src/test/run-fail/while-panic.rs:17:13
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


Re: [blfs-dev] firefox-69.0 ftbfs

2019-09-02 Thread Ken Moffat via blfs-dev
On Mon, Sep 02, 2019 at 11:08:09AM +0200, gabriele balducci via blfs-dev wrote:
> > Looking at fedora,
> > https://src.fedoraproject.org/rpms/firefox/tree/master they seem to
> > manage to build some sort of 69.0 but using a "shipped" cbindgen
> > (and I've no idea where/how they got that).  Without system
> 
> I usually (since 66.0) build cbindgen on the fly (as one of the very
> first steps during firefox build) and catch the "good" version to be built
> from these two locations in the FF tree:
> 
>  taskcluster/scripts/misc/build-cbindgen.sh
>  build/moz.configure/bindgen.configure
> 
> > Short summary: anything using the r language (as distinct from R
> > which is probably a perfectly good language) is a house of cards
> > built on sand, any help in resolving this would be welcome.
> 
> hope this helps
> 
> ciao
> gabriele

Thanks Gabriele.

I notice that the git hash has a comment '# V0.9.0' which is what
I've been using.  so, I don't think this is the cause of my problem.

ĸen
-- 
thread 'main' panicked at 'giraffe',
/tmp/rustc-1.32.0-src/src/test/run-fail/while-panic.rs:17:13
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


Re: [blfs-dev] firefox-69.0 ftbfs

2019-09-02 Thread gabriele balducci via blfs-dev
> Looking at fedora,
> https://src.fedoraproject.org/rpms/firefox/tree/master they seem to
> manage to build some sort of 69.0 but using a "shipped" cbindgen
> (and I've no idea where/how they got that).  Without system

I usually (since 66.0) build cbindgen on the fly (as one of the very
first steps during firefox build) and catch the "good" version to be built
from these two locations in the FF tree:

 taskcluster/scripts/misc/build-cbindgen.sh
 build/moz.configure/bindgen.configure

> Short summary: anything using the r language (as distinct from R
> which is probably a perfectly good language) is a house of cards
> built on sand, any help in resolving this would be welcome.

hope this helps

ciao
gabriele
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


[blfs-dev] firefox-69.0 ftbfs

2019-09-01 Thread Ken Moffat via blfs-dev
Warning, this contains swearing (r..t).

I built firefox-69.0b15, apparently successfully (in /opt) on
LFS-9.0 on 24th August.  But the 69.0 release is due within the next
24 hours and will probably match build 2 of the 69.0 candidates
since that was created on 27th August -
https://archive.mozilla.org/pub/firefox/candidates/

But libxul fails to link:

46:36.89 /usr/bin/ld: 
/scratch/ken/firefox-69.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/libgkrust.a(gkrust-b93ea53969332fa4.gkrust.7cevgj2m-cgu.0.rcgu.o):
 in function `audio_thread_priority::promote_current_thread_to_real_time':
46:36.89 
gkrust.7cevgj2m-cgu.0:(.text._ZN21audio_thread_priority35promote_current_thread_to_real_time17hcb9eeb851c002882E+0xe0):
 undefined reference to `dbus_error_init'
 and so forth.

This seems to be somewhere in the rust (sorry for swearing!) code,
one of
./media/audioipc/client/src/context.rs:use 
audio_thread_priority::promote_current_thread_to_real_time;
./media/audioipc/client/src/context.rs:match 
promote_current_thread_to_real_time(0, 48000) {
./media/audioipc/client/src/lib.rs:use 
audio_thread_priority::promote_current_thread_to_real_time;
./media/audioipc/client/src/lib.rs:match 
promote_current_thread_to_real_time(0, 48000) {
./media/audioipc/server/src/lib.rs:use 
audio_thread_priority::promote_current_thread_to_real_time;
./media/audioipc/server/src/lib.rs:match 
promote_current_thread_to_real_time(0, 48000) {

Doing a verbose build (./mach build --verbose) it appears that
-ldbus-glib-1 -ldbus-1 are no longer pulled in for the libxul
linkage.

Looking at fedora,
https://src.fedoraproject.org/rpms/firefox/tree/master they seem to
manage to build some sort of 69.0 but using a "shipped" cbindgen
(and I've no idea where/how they got that).  Without system
cbindgen, it craps out very quickly.  Trying the latest release of
cbindgen (0.9.1) makes no difference, and that looks as if it is the
latest commit in cbindgen.

Short summary: anything using the r language (as distinct from R
which is probably a perfectly good language) is a house of cards
built on sand, any help in resolving this would be welcome.

ĸen
-- 
Adopted by dwarfs, brought up by dwarfs.  To dwarfs I'm a dwarf, sir.
I can do the rite of k'zakra, I know the secrets of h'ragna, I can
ha'lk my g'rakha correctly ... I am a dwarf
   Captain Carrot Ironfoundersson (in The Fifth Elephant)
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page