January 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1217417] Realtek RTL-8126 Network Driver
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1217417 https://bugzilla.suse.com/show_bug.cgi?id=1217417#c18 Joe S <jmscdba(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jmscdba(a)gmail.com | |) | --- Comment #18 from Joe S <jmscdba(a)gmail.com> --- Created attachment 872067 --> https://bugzilla.suse.com/attachment.cgi?id=872067&action=edit dmesg log from 6.7 test kernel to try and get Realtek 8126 working -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1218951] New: vagrant: needs update for ruby3.3
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1218951 Bug ID: 1218951 Summary: vagrant: needs update for ruby3.3 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: ana.guerrero(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Vagrant is blocking the update to ruby3.3 because it's failing to build with this version. Relevant lines from the log: [ 17s] + cd /home/abuild/rpmbuild/BUILD [ 17s] + cd vagrant-2.3.7 [ 17s] + sed -i 's|gem '\''vagrant-spec'\'', git.*$|gem '\''vagrant-spec'\''|' Gemfile [ 17s] ++ ruby.ruby3.3 -e 'print Gem.path.reject{|path| path.include? '\''home'\''}.join('\'':'\'')' [ 17s] + export GEM_PATH=/home/abuild/rpmbuild/BUILDROOT/vagrant-2.3.7-4.1.x86_64/usr/share/vagrant/gems:/usr/lib64/ruby/gems/3.3.0 [ 17s] + GEM_PATH=/home/abuild/rpmbuild/BUILDROOT/vagrant-2.3.7-4.1.x86_64/usr/share/vagrant/gems:/usr/lib64/ruby/gems/3.3.0 [ 17s] + bundle exec rake test:unit [ 18s] bundler: failed to load command: rake (/usr/bin/rake) [ 18s] /usr/lib64/ruby/3.3.0/bundler/resolver.rb:116:in `rescue in solve_versions': Could not find compatible versions (Bundler::SolveFailure) [ 18s] [ 18s] Because every version of vagrant depends on Ruby >= 3.0, < 3.3 [ 18s] and Gemfile depends on vagrant >= 0, [ 18s] Ruby >= 3.0, < 3.3 is required. [ 18s] So, because current Ruby version is = 3.3.0, [ 18s] version solving has failed. [ 18s] from /usr/lib64/ruby/3.3.0/bundler/resolver.rb:79:in `solve_versions' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/resolver.rb:32:in `start' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/definition.rb:600:in `start_resolution' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/definition.rb:311:in `resolve' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/definition.rb:553:in `materialize' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/definition.rb:203:in `specs' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/definition.rb:270:in `specs_for' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/runtime.rb:18:in `setup' [ 18s] from /usr/lib64/ruby/3.3.0/bundler.rb:162:in `setup' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/setup.rb:26:in `block in <top (required)>' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/ui/shell.rb:159:in `with_level' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/ui/shell.rb:111:in `silence' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/setup.rb:26:in `<top (required)>' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/cli/exec.rb:56:in `require_relative' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/cli/exec.rb:56:in `kernel_load' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/cli/exec.rb:23:in `run' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/cli.rb:451:in `exec' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/vendor/thor/lib/thor/command.rb:28:in `run' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/vendor/thor/lib/thor.rb:527:in `dispatch' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/cli.rb:34:in `dispatch' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/vendor/thor/lib/thor/base.rb:584:in `start' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/cli.rb:28:in `start' [ 18s] from /usr/lib64/ruby/gems/3.3.0/gems/bundler-2.5.3/exe/bundle:28:in `block in <top (required)>' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/friendly_errors.rb:117:in `with_friendly_errors' [ 18s] from /usr/lib64/ruby/gems/3.3.0/gems/bundler-2.5.3/exe/bundle:20:in `<top (required)>' [ 18s] from /usr/bin/bundle:25:in `load' [ 18s] from /usr/bin/bundle:25:in `<main>' [ 18s] /usr/lib64/ruby/3.3.0/bundler/vendor/pub_grub/lib/pub_grub/version_solver.rb:237:in `resolve_conflict': Could not find compatible versions (Bundler::PubGrub::SolveFailure) [ 18s] [ 18s] Because every version of vagrant depends on Ruby >= 3.0, < 3.3 [ 18s] and Gemfile depends on vagrant >= 0, [ 18s] Ruby >= 3.0, < 3.3 is required. [ 18s] So, because current Ruby version is = 3.3.0, [ 18s] version solving has failed. [ 18s] from /usr/lib64/ruby/3.3.0/bundler/vendor/pub_grub/lib/pub_grub/version_solver.rb:73:in `block in propagate' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/vendor/pub_grub/lib/pub_grub/version_solver.rb:70:in `reverse_each' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/vendor/pub_grub/lib/pub_grub/version_solver.rb:70:in `propagate' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/vendor/pub_grub/lib/pub_grub/version_solver.rb:42:in `work' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/vendor/pub_grub/lib/pub_grub/version_solver.rb:58:in `solve' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/resolver.rb:81:in `solve_versions' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/resolver.rb:32:in `start' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/definition.rb:600:in `start_resolution' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/definition.rb:311:in `resolve' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/definition.rb:553:in `materialize' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/definition.rb:203:in `specs' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/definition.rb:270:in `specs_for' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/runtime.rb:18:in `setup' [ 18s] from /usr/lib64/ruby/3.3.0/bundler.rb:162:in `setup' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/setup.rb:26:in `block in <top (required)>' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/ui/shell.rb:159:in `with_level' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/ui/shell.rb:111:in `silence' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/setup.rb:26:in `<top (required)>' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/cli/exec.rb:56:in `require_relative' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/cli/exec.rb:56:in `kernel_load' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/cli/exec.rb:23:in `run' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/cli.rb:451:in `exec' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/vendor/thor/lib/thor/command.rb:28:in `run' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/vendor/thor/lib/thor.rb:527:in `dispatch' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/cli.rb:34:in `dispatch' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/vendor/thor/lib/thor/base.rb:584:in `start' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/cli.rb:28:in `start' [ 18s] from /usr/lib64/ruby/gems/3.3.0/gems/bundler-2.5.3/exe/bundle:28:in `block in <top (required)>' [ 18s] from /usr/lib64/ruby/3.3.0/bundler/friendly_errors.rb:117:in `with_friendly_errors' [ 18s] from /usr/lib64/ruby/gems/3.3.0/gems/bundler-2.5.3/exe/bundle:20:in `<top (required)>' [ 18s] from /usr/bin/bundle:25:in `load' [ 18s] from /usr/bin/bundle:25:in `<main>' [ 18s] error: Bad exit status from /var/tmp/rpm-tmp.L6GsJN (%check) -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1219005] New: cannot specify which multibuild package flavors to build in package metadata
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1219005 Bug ID: 1219005 Summary: cannot specify which multibuild package flavors to build in package metadata Classification: Internal Novell Products Product: openSUSE Build Service Version: master Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: backend Assignee: mls(a)suse.com Reporter: msuchanek(a)suse.com QA Contact: adrian.schroeter(a)suse.com Target Milestone: --- Found By: --- Blocker: --- For some packages a number of different builds uses the same source. For consistency and efficiency it is required to upload the sources only once, and run multiple builds against the same sources. Historically this has been done by package links: The sources would be uploaded with a number of spec files, and a number of package links created. Because OBS selects the spec file to build based on container name the different package links would build different spec files. In other ways these package links appear as any other build containers. In particular, it's possible to select in what repositories (if any) the individual spec files should be built in the package container metadata. There is a push to convert these packages to use multibuild instead. With multibuild a _multibuild file is created that lists the spec files to build but only one package container is created in which all these spec files are built. That results in only one container metadata, and inability to specify which spec file to build in which repository. https://github.com/openSUSE/open-build-service/issues/3574 This is important functionality for package development. The kernel uses this functionality to set up multiple repositories in the development project and select which spec file to build in which repository. That makes it possible to test kernel builds without breaking the project when the kernel fails to boot on the OBS builder. For both kernel and other packages that build a number of configurations this is important for people that want to branch the package and only build/change a specific configuration. Currently kernel and u-boot use different hacks to workaround this deficiency in OBS multibuild support, some packages completely give up on controlling which individual configurations to build. That means users that branch these multibuild packages have to read the package sources to find out how to select which configuration to build if the option is provided at all. There is no standardized and documented way to do it. Some workarounds have been proposed. The obvious one is to change the _multibuild file but that results in changing the package sources, it becomes a different package then. All already built configurations are rebuilt after the change. The source change is likely to cause package breaks because OBS is very bad at resolving updates to modified packages. Another option are build flags in project config. onlybuild/excludebuild flags can be used to (de)select some configurations. However, the project config is inherited, and so are these flags. Building against a project that already (de)selected some configuration (de)selects same configurations for the branched package, and this cannot be changed. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1211880] Using yast2 mail and selecting amavis gives an amavis service that does not run
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1211880 https://bugzilla.suse.com/show_bug.cgi?id=1211880#c4 --- Comment #4 from Freek de Kruijf <freek(a)opensuse.org> --- Inspection of the YaST2 mail module shows a lot of inconsistencies. This is one of them. I am working on a script which should mimic an enhanced YaST2 mail module which implements support for SPF, DKIM (from Amavis and openDKIM) and DMARC. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1218732] Lenovo T14 external monitor aliasing at monitor resolution
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1218732 https://bugzilla.suse.com/show_bug.cgi?id=1218732#c9 --- Comment #9 from Takashi Iwai <tiwai(a)suse.com> --- My question is whether the displayed area really matches with the expectation; i.e. it's 1920x1080 pixels are shown but it doesn't fit to the monitor, or is another size displayed actually? I guess the former, but it's hard to judge. If so, the next step is to identify whether it's a problem of the laptop (and the GPU driver) or it's the problem of the monitor. If you have another machine (with a different GPU) and you can check with this monitor, it'd be helpful. (Or check with another monitor that have the same resolution.) Last but not least, please boot with boot options "drm.debug=0x1e log_buf_len=16M", and get the dmesg output after configuring for the monitor. Compress the output and upload to Bugzilla. It'll show what GPU drivers are trying to do. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1217175] lokalize does not open project file when specified after --project
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1217175 https://bugzilla.suse.com/show_bug.cgi?id=1217175#c2 --- Comment #2 from Freek de Kruijf <freek(a)opensuse.org> --- Also reported on https://bugs.kde.org/show_bug.cgi?id=477039 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1215062] New: Ctrl+Alt+B in lokalize no longer works
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1215062 Bug ID: 1215062 Summary: Ctrl+Alt+B in lokalize no longer works Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: freek(a)opensuse.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I an using tumbleweed:20230902 and since a few days Ctrl+Alt+B in lokalize to insert exact matches in fuzzy or empty elements in a .po file no longer works. When I walk through these elements the Translation Memory shows exact translations (100%), but they are not inserted using Ctrl+Alt+B. I have to use Ctrl+1 to copy the translation from TM into the element. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1209070] Problem with Local Folders of KMail pointing to ~/.local/share/akonadi_maildir_resource_0 but using ~/.local/share/.akonadi_maildir_resource_0.directory
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1209070 https://bugzilla.suse.com/show_bug.cgi?id=1209070#c2 Freek de Kruijf <freek(a)opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |UPSTREAM --- Comment #2 from Freek de Kruijf <freek(a)opensuse.org> --- No reaction. Upstream. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1209022] pimdataexporter creates two Local Folders
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1209022 https://bugzilla.suse.com/show_bug.cgi?id=1209022#c1 Freek de Kruijf <freek(a)opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |UPSTREAM --- Comment #1 from Freek de Kruijf <freek(a)opensuse.org> --- No reaction. Should probably be reported as a KDE Kmail bug. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1200675] Outgoing e-mail from GMail account sometimes hangs
by bugzilla_noreply＠suse.com 22 Jan '24

22 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1200675 https://bugzilla.suse.com/show_bug.cgi?id=1200675#c2 Freek de Kruijf <freek(a)opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Freek de Kruijf <freek(a)opensuse.org> --- No reaction. Apparently fixed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0