November 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1192286] New: Missing gtk4-branding-openSUSE package
by bugzilla_noreply＠suse.com 05 Nov '21

05 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192286 Bug ID: 1192286 Summary: Missing gtk4-branding-openSUSE package Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: gnome-bugs(a)suse.de Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- There is only gtk4-branding-upstream in Leap 15.4, but no gtk4-branding-openSUSE. It appears like the gtk4-branding package is missing, but just adding that to SLE would not be enough due to its use of %{?is_opensuse}. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1191260] kernel 5.14.8 post scriptlets failing
by bugzilla_noreply＠suse.com 05 Nov '21

05 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1191260 Jeffrey Cheung <jcheung(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jcheung(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192067] Rust1.55 miscompiles Firefox on Tumbleweed
by bugzilla_noreply＠suse.com 05 Nov '21

05 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192067 https://bugzilla.suse.com/show_bug.cgi?id=1192067#c22 --- Comment #22 from William Brown <william.brown(a)suse.com> --- > Usually Mesa wants a newer LLVM and that's how it ends up in SLE. But I'd > ship the newest version at the time of release in Leap even if it wasn't for > Mesa. Yep, thought it was something like this. But again, I'm not really involved in that side of things .... > > I see two possible reasons why things didn't work out this time: > > * Normally Rust doesn't compile with newer LLVMs because of interface > changes, but this time that hasn't been the case. The relevant PR > https://github.com/rust-lang/rust/pull/87570 was not in 1.55, yet we didn't > have any compiler errors. With previous LLVM updates I saw that Rust didn't > build and then I either ported back the "Upgrade to LLVM XX" PR or we waited > for the next release to come out. This time we didn't see any errors, so we > didn't do anything. > > * The new pass manager is now the "default". Rust switched in > https://github.com/rust-lang/rust/pull/88243, also in 1.56. The old PM is > still maintained, but probably not as well-tested anymore since Clang made > the switch. I think 87570 is the likely missing piece, but it's a good lesson that we don't just need a minimum llvm version for rust, but also a maximum one because anything newer may not be tested or supported. So again, the lock-step will resolve that and reduce our potential surface area to issues. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192067] Rust1.55 miscompiles Firefox on Tumbleweed
by bugzilla_noreply＠suse.com 05 Nov '21

05 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192067 https://bugzilla.suse.com/show_bug.cgi?id=1192067#c21 --- Comment #21 from Aaron Puchert <aaronpuchert(a)alice-dsl.net> --- (In reply to William Brown from comment #20) > IIRC it's related to LLVM being part of the graphics pipeline somewhere but > I don't recall all the details ... Usually Mesa wants a newer LLVM and that's how it ends up in SLE. But I'd ship the newest version at the time of release in Leap even if it wasn't for Mesa. > > Though it could lead to issues with the installation medium, perhaps that's > > why we want to limit the versions in Leap. In Tumbleweed we mostly switch > > everything to newer versions when they become available, but on SLE packages > > aren't rebuild when dependencies update, so we might need multiple libLLVMs > > on the DVD. > > Again, I think here it's up to what SLE does given how llvm/rust are managed > there. I have a hand in Rust inside SUSE, but I'm not involved in the LLVM > side. Regardless, I think keeping llvm lock stepped to rust versions will be > important from now, and the question is how we go about that with SLE with > regard to bundling LLVM or not. But that's something for me to chase up :) I don't have any concerns with that, given that Rust is usually quick to catch up. On the contrary, it makes it easier for me to bring newer LLVMs into TW. As for SLE/Leap, let's see how we handle that. I see two possible reasons why things didn't work out this time: * Normally Rust doesn't compile with newer LLVMs because of interface changes, but this time that hasn't been the case. The relevant PR https://github.com/rust-lang/rust/pull/87570 was not in 1.55, yet we didn't have any compiler errors. With previous LLVM updates I saw that Rust didn't build and then I either ported back the "Upgrade to LLVM XX" PR or we waited for the next release to come out. This time we didn't see any errors, so we didn't do anything. * The new pass manager is now the "default". Rust switched in https://github.com/rust-lang/rust/pull/88243, also in 1.56. The old PM is still maintained, but probably not as well-tested anymore since Clang made the switch. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192067] Rust1.55 miscompiles Firefox on Tumbleweed
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192067 https://bugzilla.suse.com/show_bug.cgi?id=1192067#c20 --- Comment #20 from William Brown <william.brown(a)suse.com> --- > > > 1. llvm is very slow to compile, so when compiling rustc / cargo is good to > > > use the llvm from the system to gain some speed. > > > > Correct - but we can speed it up with the use of sccache in OBS, [...] > It's not just that, to be fair, but also about unbundling. I'm aware :) > > > The reason we have to build llvm in leap15.3 is just because llvm13 isn't > > available there yet, else we could use the distro llvm. I can't remember the > > exact details about llvm and out-of-band updates in 15.3 but if 13 becomes > > available we can swap to that potentially. > That's not up to me��someone at SUSE would have to do that. So far we've only > added new LLVMs with new Leap releases, but I don't see why it has to be > that way. We could certainly add newer versions between releases as well. IIRC it's related to LLVM being part of the graphics pipeline somewhere but I don't recall all the details ... > > Though it could lead to issues with the installation medium, perhaps that's > why we want to limit the versions in Leap. In Tumbleweed we mostly switch > everything to newer versions when they become available, but on SLE packages > aren't rebuild when dependencies update, so we might need multiple libLLVMs > on the DVD. Again, I think here it's up to what SLE does given how llvm/rust are managed there. I have a hand in Rust inside SUSE, but I'm not involved in the LLVM side. Regardless, I think keeping llvm lock stepped to rust versions will be important from now, and the question is how we go about that with SLE with regard to bundling LLVM or not. But that's something for me to chase up :) > > > we could do the checks just on package submit time instead as an option, but > > then we'd only be testing on x86_64 (for now, I intend to get aarch64 > > hardware soon). > In Python packages there is often some kind of multibuild setup that runs > the tests separately from the actual package. Perhaps that could work? There is also a way to specify in OBS to run checks vs not so I think that's an option I need to look into. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192067] Rust1.55 miscompiles Firefox on Tumbleweed
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192067 https://bugzilla.suse.com/show_bug.cgi?id=1192067#c19 --- Comment #19 from Aaron Puchert <aaronpuchert(a)alice-dsl.net> --- (In reply to William Brown from comment #18) > Code generation bugs are hard to detect at runtime. There are absolutely > things you can do as a developer in your project to try to detect anomalies > at run time like this, but not every project has written things so > defensively. So I think it's honestly hard to actually make this "fail > better" in this situation without projects making defensive changes. Agreed, miscompilations are pretty ugly. If you add defensive coding, then possibly the issue disappears for unrelated reasons because you're not triggering the bug anymore. Had to debug such an issue once where the miscompilation disappeared with enabled assertions. The typical cause of miscompilations is some inconsistency in LLVM's IR model or its usage in clients. Now that model isn't precisely specified and changes between versions. (Though of course with some care.) Some inconsistencies go a bit deeper and are hard to fix [1]: "The LLVM community has dealt with these issues by usually fixing a problem when it can be demonstrated to lead to an *end-to-end miscompilation*: an optimizer malfunction that leads to the wrong machine code being emitted for some legal source program. The underlying, long-standing problems��and, indeed, a few opportunities for end-to-end miscompilations��remain unsolved." Of course we'd like to have a formally proven model, but I guess things change too fast for that, and of course many ideas haven't been fully fleshed out yet. Though at least some formal tools for peephole optimizations are used in LLVM development. [2] > > 1. llvm is very slow to compile, so when compiling rustc / cargo is good to > > use the llvm from the system to gain some speed. > > Correct - but we can speed it up with the use of sccache in OBS, [...] It's not just that, to be fair, but also about unbundling. > The reason we have to build llvm in leap15.3 is just because llvm13 isn't > available there yet, else we could use the distro llvm. I can't remember the > exact details about llvm and out-of-band updates in 15.3 but if 13 becomes > available we can swap to that potentially. That's not up to me��someone at SUSE would have to do that. So far we've only added new LLVMs with new Leap releases, but I don't see why it has to be that way. We could certainly add newer versions between releases as well. Though it could lead to issues with the installation medium, perhaps that's why we want to limit the versions in Leap. In Tumbleweed we mostly switch everything to newer versions when they become available, but on SLE packages aren't rebuild when dependencies update, so we might need multiple libLLVMs on the DVD. > we could do the checks just on package submit time instead as an option, but > then we'd only be testing on x86_64 (for now, I intend to get aarch64 > hardware soon). In Python packages there is often some kind of multibuild setup that runs the tests separately from the actual package. Perhaps that could work? [1] https://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf [2] https://github.com/AliveToolkit/alive2 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192067] Rust1.55 miscompiles Firefox on Tumbleweed
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192067 https://bugzilla.suse.com/show_bug.cgi?id=1192067#c18 --- Comment #18 from William Brown <william.brown(a)suse.com> --- (In reply to Hans-Peter Jansen from comment #16) > Thanks guys, this is one of the most helpful bug records ever. You are most welcome! We always try to help here :) > > @Aaron, @William, @Wolfgang: one thing, that makes me nervous is the errors > behavior. In Firefox, it seems to be sandbox related, but no real failure > there, apart from some hints of failing access to /dev/random. Why/how does > this break specific areas like WebRTC only, while most of the rest is acting > fine? > > Without understanding, what and how it is going wrong, we'll have a hard > time to look for similar issues in other packages. Code generation bugs are hard to detect at runtime. There are absolutely things you can do as a developer in your project to try to detect anomalies at run time like this, but not every project has written things so defensively. So I think it's honestly hard to actually make this "fail better" in this situation without projects making defensive changes. > > 1. llvm is very slow to compile, so when compiling rustc / cargo is good to > use the llvm from the system to gain some speed. Correct - but we can speed it up with the use of sccache in OBS, which I have been trying to have included in our OBS instances (if you know any OBS admins/maintainers, please get them to contact me because I can't seem to get in touch with any of them ...) > > 2. rustc is expected to work with some range of llvm versions "yes-ish". Even if it works, we still need to focus on "what received the most testing". Software always is reflective of, and works best in the way it was developed, and for rust that means lock-stepping llvm to rust versions, because that's how it's developed. From now, I intend to pair rust versions to llvm versions rather than allowing it to change on us mid-release of a rust cycle like happened here, which introduced this chaos. The reason we have to build llvm in leap15.3 is just because llvm13 isn't available there yet, else we could use the distro llvm. I can't remember the exact details about llvm and out-of-band updates in 15.3 but if 13 becomes available we can swap to that potentially. > I think that they are fair points, and TW can help in detecting early issues. > > But still I think that there should be an outcome of this bug, like working > on enabling the tests inside the %check section on the rust package. That's an option, but it's also another time consuming option. OBS already is excruciatingly slow to build rust taking 2hrs or more - and that's with distro llvm, not the bundled llvm. Enabling the tests will likely only make this worst. (Contrast my home lab, where I can build rust in 40 mins with cold sccache and 10 minutes with hot cache). we could do the checks just on package submit time instead as an option, but then we'd only be testing on x86_64 (for now, I intend to get aarch64 hardware soon). Another option to consider too is extended openqa testing of firefox *as well* as the rust checks. Clearly this was missed and every time we see a failure like this, we can potential grow openqa to detect issues like this. Anyway, the rust1.55 updates are accepted and are in the Factory/Tumbleweed pipeline at the moment, and once that's accepted, I have staged the 1.55 updates for 15.3 in SLE, which will then flow out to leap. So I think this bug should probably switch focus to proactive steps to detect and prevent issues like this. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192290] Switch of system language: no language files installed
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192290 https://bugzilla.suse.com/show_bug.cgi?id=1192290#c8 --- Comment #8 from Axel Braun <axel.braun(a)gmx.de> --- (In reply to Stefan Hundhammer from comment #7) > Maybe you didn't have any xfce4-*lang packages installed at all. > Did you by any chance install with "no recommends"? I used the image from https://en.opensuse.org/HCL:Raspberry_Pi4 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1191765] New: [SLPP] libksieve: E: shlib-policy-name-error
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1191765 Bug ID: 1191765 Summary: [SLPP] libksieve: E: shlib-policy-name-error Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: martin.liska(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The following rpmlint error was seen for the package: libksieve.log:[ 220s] libksieve.x86_64: E: shlib-policy-name-error SONAME: libKF5KManageSieve.so.5, expected package suffix: 5 libksieve.log:[ 220s] libksieve.x86_64: E: shlib-policy-name-error SONAME: libKF5KSieve.so.5, expected package suffix: 5 libksieve.log:[ 220s] libksieve.x86_64: E: shlib-policy-name-error SONAME: libKF5KSieveUi.so.5, expected package suffix: 5 Note the updated rpmlint will reach openSUSE:Factory soon. We would like to make 'shlib-policy-name-error' a package build failure error, so please fix the error. Link to the SLPP documentation: https://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Package_na… -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1192011] Build service dependency resolution generates ambiguity
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192011 https://bugzilla.suse.com/show_bug.cgi?id=1192011#c6 Robert Schweikert <rjschwei(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo? | --- Comment #6 from Robert Schweikert <rjschwei(a)suse.com> --- SLES 15 SP2 image builds in IBS fell over. -- You are receiving this mail because: You are on the CC list for the bug.

1 0