Re: [blfs-dev] qt patch missing from repository (version 2019-12-24)
Hello Doug... On Wed, 2019-12-25 at 16:48 -0600, Douglas R. Reno via blfs-dev wrote: > On 12/25/19 4:43 PM, Jean-Marc Pigeon via blfs-dev wrote: > > Hello > > > > According to me qt wayland patch > > http://www.linuxfromscratch.org/patches/blfs/svn/qt-5.14.0-qtwayland_cursor_fix-1.patch > > > > Is missing altogether from site: > > http://www.linuxfromscratch.org/patches/blfs/svn/ > > > > possible? > > > Good evening, > > The patch wasn't in the proper place at the last render. I've since > moved the patch to the proper location, but it will not appear there > until the next render. > > For now, you can fetch the patch from this URL: > > http://linuxfromscratch.org/patches/downloads/qt/qt-5.14.0-qtwayland_cursor_fix-1.patch > > > - Doug I Confirm link ok. Many many thanks for that very very quick reply.. > -- You have seen "Linux from scratch" and looking for ISO files www.osukiss.org -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] qt patch missing from repository (version 2019-12-24)
On 12/25/19 4:43 PM, Jean-Marc Pigeon via blfs-dev wrote: Hello According to me qt wayland patch http://www.linuxfromscratch.org/patches/blfs/svn/qt-5.14.0-qtwayland_cursor_fix-1.patch Is missing altogether from site: http://www.linuxfromscratch.org/patches/blfs/svn/ possible? Good evening, The patch wasn't in the proper place at the last render. I've since moved the patch to the proper location, but it will not appear there until the next render. For now, you can fetch the patch from this URL: http://linuxfromscratch.org/patches/downloads/qt/qt-5.14.0-qtwayland_cursor_fix-1.patch - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] qt patch missing from repository (version 2019-12-24)
Hello According to me qt wayland patch http://www.linuxfromscratch.org/patches/blfs/svn/qt-5.14.0-qtwayland_cursor_fix-1.patch Is missing altogether from site: http://www.linuxfromscratch.org/patches/blfs/svn/ possible? -- You have seen "Linux from scratch" and looking for ISO files www.osukiss.org -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] KDE and Qt-5.14
On 12/25/19 11:59 AM, spiky0011 via blfs-dev wrote: On 25/12/2019 17:55, Douglas R. Reno via blfs-dev wrote: On 12/25/19 11:52 AM, spiky0011 via blfs-dev wrote: On 24/12/2019 08:20, Pierre Labastie via blfs-dev wrote: Hi, As reported on support, some of KDE frameworks are broken by QT-5.14. I've found upstream fixes, so I am now sure that the fixes are needed. They can be done as sed. I think we should also apply the patch reported by "spiky" on -support to Qt-5.14. I have tested that it applies and builds OK, but I have not tested the cursor yet (need to build the desktop first)... I am not sure how much I can do in the next few days, since I go and visit my family for Christmas. Pierre Hi Pierre FYI just rebuilding qt the patch is not availble at link Hi Spiky, I just submitted the patch to the proper location at r4044, but it might not be correct in the book yet. I believe that happens overnight. Here's a direct link: http://linuxfromscratch.org/patches/downloads/qt/qt-5.14.0-qtwayland_cursor_fix-1.patch By the way, to everyone - Merry Christmas / Happy Holidays! Doug is it the same patch I linked the other day? I'm not sure since I was away for a bit, but the header contains this information: +From 36974955d13578071387695adb13a47be33e4d32 Mon Sep 17 00:00:00 2001 +From: David Edmundson +Date: Thu, 28 Nov 2019 02:31:17 +0100 +Subject: Avoid animating single frame cursors + +Currently to determine if a cursor is animated or not we check the +cursor theme delay. + +This doesn't work in practice as by default many cursor themes have a +delay of 50 set even if they don't animate. + +This comes from xcursorgen which specifies a delay of 50ms if there +isn't anything set in the config. +(https://github.com/freedesktop/xcursorgen/blob/master/xcursorgen.c#L92) + +Given many themes will have a delay we should also check the number of +images in a given cursor. + +In order to do that without a double lookup QWaylandCursor needed to +return the native wl_cursor, not wl_cursor_image and move the relevant +logic. + +Change-Id: Ie782ace8054910ae76e61cab33ceca0377194929 +Reviewed-by: Johan Helsing +--- + src/client/qwaylandcursor.cpp | 12 ++-- + src/client/qwaylandcursor_p.h | 3 +-- + src/client/qwaylandinputdevice.cpp | 16 + 3 files changed, 15 insertions(+), 16 deletions(-) -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] KDE and Qt-5.14
On 25/12/2019 17:55, Douglas R. Reno via blfs-dev wrote: On 12/25/19 11:52 AM, spiky0011 via blfs-dev wrote: On 24/12/2019 08:20, Pierre Labastie via blfs-dev wrote: Hi, As reported on support, some of KDE frameworks are broken by QT-5.14. I've found upstream fixes, so I am now sure that the fixes are needed. They can be done as sed. I think we should also apply the patch reported by "spiky" on -support to Qt-5.14. I have tested that it applies and builds OK, but I have not tested the cursor yet (need to build the desktop first)... I am not sure how much I can do in the next few days, since I go and visit my family for Christmas. Pierre Hi Pierre FYI just rebuilding qt the patch is not availble at link Hi Spiky, I just submitted the patch to the proper location at r4044, but it might not be correct in the book yet. I believe that happens overnight. Here's a direct link: http://linuxfromscratch.org/patches/downloads/qt/qt-5.14.0-qtwayland_cursor_fix-1.patch By the way, to everyone - Merry Christmas / Happy Holidays! Doug is it the same patch I linked the other day? -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] KDE and Qt-5.14
On 12/25/19 11:52 AM, spiky0011 via blfs-dev wrote: On 24/12/2019 08:20, Pierre Labastie via blfs-dev wrote: Hi, As reported on support, some of KDE frameworks are broken by QT-5.14. I've found upstream fixes, so I am now sure that the fixes are needed. They can be done as sed. I think we should also apply the patch reported by "spiky" on -support to Qt-5.14. I have tested that it applies and builds OK, but I have not tested the cursor yet (need to build the desktop first)... I am not sure how much I can do in the next few days, since I go and visit my family for Christmas. Pierre Hi Pierre FYI just rebuilding qt the patch is not availble at link Hi Spiky, I just submitted the patch to the proper location at r4044, but it might not be correct in the book yet. I believe that happens overnight. Here's a direct link: http://linuxfromscratch.org/patches/downloads/qt/qt-5.14.0-qtwayland_cursor_fix-1.patch By the way, to everyone - Merry Christmas / Happy Holidays! -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] KDE and Qt-5.14
On 24/12/2019 08:20, Pierre Labastie via blfs-dev wrote: Hi, As reported on support, some of KDE frameworks are broken by QT-5.14. I've found upstream fixes, so I am now sure that the fixes are needed. They can be done as sed. I think we should also apply the patch reported by "spiky" on -support to Qt-5.14. I have tested that it applies and builds OK, but I have not tested the cursor yet (need to build the desktop first)... I am not sure how much I can do in the next few days, since I go and visit my family for Christmas. Pierre Hi Pierre FYI just rebuilding qt the patch is not availble at link -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] llvm-9.0.1 seems to break rustc-1.37.0
On 2019-12-25 00:33 +, Ken Moffat via blfs-dev wrote: > On Tue, Dec 24, 2019 at 04:59:53PM -0600, Douglas R. Reno via blfs-dev wrote: > > On 12/24/19 3:14 PM, Ken Moffat via blfs-dev wrote: > > > On Mon, Dec 23, 2019 at 10:09:17PM +, Ken Moffat via blfs-dev wrote: > > > > Arch have a patch for thunderbird, described as for rustc-1.39.0. > > > > https://git.archlinux.org/svntogit/packages.git/plain/trunk/thunderbird-rust-1.39.patch?h=packages/thunderbird > > > > > > > There is also thunderbird beta in arch (currently 72.0b2 - > > > thunderbird tracks firefox major releases, but non-ESR are only > > > ever beta, although a comment suggests that might have changed) : > > > https://aur.archlinux.org/packages/thunderbird-beta/?setlang=en > > > > > > I'm mentioning this because at the moment it is noted as broken by > > > rustc-1.40.0. > > > > > > ĸen > > > > Good evening guys, > > > > Since we have LLVM-9 in the book now (since Sunday) and I had to leave the > > house for a bit today, I ran a build of rustc-1.37 with the following > > commit: > > > > https://github.com/rust-lang/rust/commit/04304fcd16e40c936dc5ba71c9ac3c445597f8bb > > > > I got past the LLVM build error, but now I have another one: > > > > Copying stage1 std from stage1 (x86_64-unknown-linux-gnu -> > > x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu) > > Building stage1 test artifacts (x86_64-unknown-linux-gnu -> > > x86_64-unknown-linux-gnu) > >Compiling proc_macro v0.0.0 (/sources/rustc-1.37.0-src/src/libproc_macro) > > error: Could not compile `proc_macro`. > > > > Caused by: > > process didn't exit successfully: > > `/sources/rustc-1.37.0-src/build/bootstrap/debug/rustc --edition=2018 > > --crate-name proc_macro src/libproc_macro/lib.rs --color always > > --error-format json --crate-type lib --emit=dep-info,metadata,link -C > > opt-level=2 -C metadata=b2a98432edc77a2f -C extra-filename=-b2a98432edc77a2f > > --out-dir /sources/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage1- > > test/x86_64-unknown-linux-gnu/release/deps > > --target x86_64-unknown-linux-gnu -L dependency=/sources/rustc-1.37.0- > > src/build/x86_64-unknown-linux-gnu/stage1-test/x86_64-unknown-linux- > > gnu/release/deps > > -L dependency=/sources/rustc-1.37.0-src/build/x86_64-unknown-linux- > > gnu/stage1-test/release/deps > > -C link-args=-lffi` (signal: 11, SIGSEGV: invalid memory reference) > > command did not execute successfully: > > "/sources/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" > > "build" "--target" "x86_64-unknown-linux-gnu" "-j" "1" "--release" > > "--manifest-path" "/sources/rustc-1.37.0-src/src/libtest/Cargo.toml" > > "--message-format" "json" > > expected success, got: exit code: 101 > > failed to run: /sources/rustc-1.37.0-src/build/bootstrap/debug/bootstrap > > build --exclude src/tools/miri > > Build completed unsuccessfully in 0:00:05 > > > > I don't think that I"m doing anything differently from the book. I copied > > and pasted the stuff in there. > > > > One of the things that I dislike about Mozilla is that they expect the > > version of rustc to be the same across the entire lifecycle of an ESR > > release. From my interpretation of this thread, I think we only have a few > > options: > > > > I think that expectation is probably common in "enterprise" distros, > it's just unusual that we happen to explicitly use such versions > (thunderbird, and for convenience firefox). > > > 1 - Revert LLVM to 8.0.1 > > > > 2 - Force rustc to use it's internal LLVM version > > > > 3 - Backport the fix for rustc and LLVM, and then somehow fix the problems > > with proc_macro > > > > 4 - Update rustc, and then patch Thunderbird and Firefox (and potentially > > other consumers) > > > > I think the easiest will be number 2. I don't think we want to stay with > > LLVM-8 for the rest of this release cycle at least. Eventually we will > > encounter updates to Mesa and the like that may need a later LLVM. > > Backporting that fix is the second easiest solution, but we might have a > > chicken and egg problem with other rust consumers. IIRC the primary reason > > why we had to upgrade rustc last time was due to librsvg. > > > > - Doug > > > > No. 2 certainly sounds easier. The problem with no.4 is identifying > the remaining fix(es). I can't say that I like no.2, and for my own > usage (avoid llvm if possible, because gcc tends to have better > security options in its available flags) llvm-8.0.1 is fine. But > whether that is true in mesa releases before we release 9.1 is > unknown. > > The big problem with rust is its lack of stability - other compilers > deprecate things and then often remove them in a release or two, but > that typically means 6 months or a year - with rust two releases is > only about 12 weeks. > > BTW - since I've noted the time : Happy Xmas everyone. I still perfer No. 3. There is a PR for LLVM-9 in rust repo: https://patch-diff.githubusercontent.com/raw/rust-lang/rust/pul
