June 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1221322] New: cannot open yast software management app, caller yast.rb:186:in `import_pure'
by bugzilla_noreply＠suse.com 14 Jul '24

14 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1221322 Bug ID: 1221322 Summary: cannot open yast software management app, caller yast.rb:186:in `import_pure' Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Ruby Assignee: ruby-devel(a)suse.de Reporter: canalcheferaser(a)tutanota.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 873462 --> https://bugzilla.suse.com/attachment.cgi?id=873462&action=edit y2log when trying to open yast software management app i get this error: ` Internal error. Please report a bug report with logs. Run save_y2logs to get complete logs. Caller: /usr/lib64/ruby/vendor_ruby/3.3.0/yast/yast.rb:186:in `import_pure' Details: component cannot import namespace 'Pkg' ` I attached the log. Also "sudo zypper dup" doesnt work, with error: ` sudo zypper dup [sudo] password for root: zypper: error while loading shared libraries: libabsl_log_internal_check_op.so.2308.0.0: cannot open shared object file: No such file or directory ` Restarting does not help. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1222019] New: krdc can not connect to VNC hosts in plasma 6
by bugzilla_noreply＠suse.com 13 Jul '24

13 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1222019 Bug ID: 1222019 Summary: krdc can not connect to VNC hosts in plasma 6 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: noreply.section+dev(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- After upgrading to Plasma 6, krdc can not connect to VNC hosts anymore. When trying to connect, krdc goes straight to a blue screen. After that, if trying to disconnect, the program freezes and the only way out is to kill the application. The behavior is the same regardless of what string is typed in the address field: i.e. the lock must happen quite early in the program. This still happens in tw 20240325 with krdc 24.02.1. A workaround so far is to use an alternative VNC viewer, such as tigervnc. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1222875] New: ghostwriter crash on start
by bugzilla_noreply＠suse.com 13 Jul '24

13 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1222875 Bug ID: 1222875 Summary: ghostwriter crash on start Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: hol.jimis(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I can not tell from what tumbleweed update it started not working but version 24.02.1-1.3 crashes with segmentation fault (core dumped) ghostwriter The only output I have is Command "pandoc" is not available. Command "multimarkdown" is not available. Command "cmark" is not available. [1] 12170 segmentation fault (core dumped) ghostwriter I installed pandoc, it finds it ok, but the crash seems irrelevant to previous output. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1225451] New: zypper invoked as non-root no more warns about outdated repositories
by bugzilla_noreply＠suse.com 13 Jul '24

13 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1225451 Bug ID: 1225451 Summary: zypper invoked as non-root no more warns about outdated repositories Classification: openSUSE Product: openSUSE Tumbleweed Version: Slowroll Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)suse.de Reporter: arvidjaar(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- andrei@tumbleweed:~> rpm -q zypper zypper-1.14.73-1.2.x86_64 andrei@tumbleweed:~> zypper se no-such-package Loading repository data... Reading installed packages... No matching items found. andrei@tumbleweed:~> grep cpe /var/cache/zypp/raw/repo-oss/repodata/repomd.xml <distro cpeid="cpe:/o:opensuse:opensuse:20240520">openSUSE Tumbleweed</distro> andrei@tumbleweed:~> cat /etc/zypp/repos.d/repo-oss.repo [repo-oss] name=openSUSE-Tumbleweed-Oss enabled=1 autorefresh=1 baseurl=http://download.opensuse.org/tumbleweed/repo/oss/ andrei@tumbleweed:~> Well, as of now the available snapshot is 20240524 so I most certainly expect Repository 'openSUSE-Tumbleweed-OSS' is out-of-date. You can run 'zypper refresh' as root to update it. ... -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1226910] New: After “booting” into Leap 15.6 with Linux kernels of the form kernel-default-6.4.0-150600.21…, the touchpad pointer “arrow” was initially invisible over most of the LXDE (Lightweight X Windows System, Version 11 [X11] Desktop Environment) window.
by bugzilla_noreply＠suse.com 12 Jul '24

12 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1226910 Bug ID: 1226910 Summary: After “booting” into Leap 15.6 with Linux kernels of the form kernel-default-6.4.0-150600.21…, the touchpad pointer “arrow” was initially invisible over most of the LXDE (Lightweight X Windows System, Version 11 [X11] Desktop Environment) window. Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: LXDE Assignee: andrea(a)opensuse.org Reporter: l_pat_s(a)hotmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Hello. I upgraded my Leap-15.5 installation in Oracle Corporation VM (Virtual “Machine”) VirtualBox 7.0.18 r162988 (Qt5.15.2) with gratefully well-working VirtualBox Guest Additions from the last version 5.14.21-150500.55.65.1.x86_64 of the software package kernel-default I had installed in my Leap-15.5 installation to Leap 15.6 with initially the Linux kernel-default, version 6.4.0-150600.21.2.x86_64 in Leap 15.6. Then on June 21, 2024 the Leap-15.6 Linux kernel kernel-default was updated to version 6.4.0-150600.21.3.x86_64 of it; and the previous version 6.4.0-150600.21.2.x86_64 of the software package kernel-default was removed from my Leap-15.6 installation. In recent years I have mainly been using the Lightweight X Windows System, Version 11 (X11) Desktop Environment (LXDE) in installations of 64-bit, openSUSE, Leap, Linux operating systems installed as so-called “guest” operating systems in VirtualBox. And in Leap 15.5 and Leap 15.6 I have in VirtualBox’s “Settings, Display” been using primarily the Graphics Controller VMSVGA of VirtualBox, which I think stands for Virtual “Machine” Super Video Graphics Array. In each one of those two Linux kernels, versions 6.4.0-150600.21… of kernel-default, in my Leap-15.6 installation after I had chosen “LXDE desktop session” at the login screen, entered my regular-user password on that screen, and then pressed down on my computer’s “Enter” key, initially I could not see my notebook computer’s touchpad, pointer “arrow” symbol when it should have been seen over most of the window provided by VirtualBox for Leap 15.6. (For users of desktop computers instead of notebook or “laptop” computers I should explain that my Dell Corporation notebook computer, which looks like what you might call a “laptop” computer, includes a touchpad instead of a so-called computer “mouse”. The movement of one of my fingers over that touchpad is equivalent to the movement of a so-called “mouse” over a pad. That is in either case such movement should be accompanied by the movement a symbol looking like a pointer “arrow” or “I beam” over the computer screen. And, just as a computer “mouse” has at least left and right buttons on it, so my touchpad also has left and right buttons on the side of it close to me, the user of that touchpad and its buttons while I face my computer’s Liquid Crystal Display [LCD], screen, or monitor.) But interestingly if I moved my invisible touchpad “arrow” symbol off the LXDE window, it could be seen, say for example, if the touchpad “arrow” would then be over a part of my VirtualBox-“host”, 64-bit, Windows 10 Home Edition, operating system’s screen. I hope to somehow, perhaps by the assistance of one or more of you readers and/or computer-code developers, to instead make that pointer “arrow” symbol initially visible over all of the LXDE window after entering an LXDE desktop session of Leap 15.6. But to provide clues to a computer-code developers toward eliminating this touchpad-pointer-”arrow” invisibility over most of the LXDE window, I mention that there have been some situations in which I could initially see the pointer-“arrow” symbol over a desktop screen in my Leap-15.6 installation: 1) after entering a Plasma (X11) desktop session instead of an LXDE desktop session when either one of the Linux kernels kernel-default, version 6.4.0-150600.21.3.x86_64 or 6.4.0-150600.21.2.x86_64 was running; or 2) after entering an LXDE desktop session in my Leap-15.6 installation when the running Linux kernel was the last version of the Linux kernel I used in my Leap-15.5 installation before upgrading Leap 15.5 to Leap 15.6, namely kernel-default, version 5.14.21-150500.55.65.1.x86_64. So whether the touchpad pointer “arrow” was invisible or not in my Leap-15.6 installation has been both desktop session dependent and kernel-default version dependent. Nevertheless, when after realizing that the touchpad-“arrow” symbol was invisible over the LXDE window in my Leap-15.6 installation, I found a so-called “workaround” solution to make the touchpad pointer “arrow” become visible over the LXDE window after entering an LXDE desktop session. And this, what-I-have-termed “trick” of mine, might be yet another clue as to where in the relevant computer source code that the trouble might lie. My “trick” has been to move a finger over my computer’s touchpad from right to left and watch the touchpad-“arrow” symbol correspondingly move from right to left below my LXDE window. Then, when that “arrow” symbol was just below the bottom-left-hand corner of my LXDE window, I probably moved my finger slightly upward and clicked once with my left, touchpad button. Though the touchpad “arrow” was invisible then, had it been seen, I suppose it then would have been over the “Start button” of my LXDE window. That clicking made the “Start menu” appear with options listed on it. Among those options I could select “Internet” and then “Konquerer” to open my installation of the Konqueror file manager. Shortly after Konqueror’s main window appeared, the touchpad-“arrow” symbol gratefully became visible over probably anywhere I would want to choose over the entire LXDE window! I could even close Konqueror; and that touchpad “arrow” was still visible over the LXDE window. (I don’t think that opening Konqueror in this way was special toward making the touchpad “arrow” become visible over the entire LXDE window. For example, later I could use the beginning of the “trick” to again click on the “Start button,” but afterward, instead of clicking on “Internet” and then on “Konqueror,” click on “System”, and then on perhaps “YaST” [Yet another Software Tool] “Software” to make the touchpad “arrow” become visible over probably the entire LXDE window.) Toward making the touchpad-“arrow” symbol everywhere and always visible over the window provided by VirtualBox for an LXDE desktop session in Leap 15.6, I can imagine a computer-code developer immediately thinking of a place in the relevant source computer code where the touchpad- or “mouse”-pointer “arrow” is made visible and the dependent factors which will make it visible or invisible. And with the different outcomes of the pointer “arrow” being visible or invisible in the beginnings of the, respectively, Plasma (X11) or LXDE desktop sessions I guess that something was properly initialized in a Plasma (X11) session, but not properly initialized in an LXDE desktop session. There has been a strange “behavior” in, for my user name “newbie”, the normally hidden file /home/newbie/.local/share/recently-used.xbel’s owner changing from “root” to “newbie” or that the file recently-used.xbel with one ownership may have been deleted and remade with a different ownership. I have seen “Permission denied” in /var/log/warn concerning that file, I suppose when its owner is “root” and it might then have had restricted permissions concerning what a regular user could do with that file. However, the purpose of that file recently-used.xbel is to make a list of applications used, which seems to me to not be directly related to making the pointer-“arrow” symbol visible or invisible over the LXDE window. I read on the Internet that the file recently-used.xbel is a part of the GNU’s Not Unix (GNU) Image Manipulation Program (GIMP) Tool Kit (GTK). But suppose that there is some other file or directory owned by “root,” with therefore likely restrictions on what a regular user can do with it, that after I open an application is then owned by “newbie” or else is deleted and remade with the owner “newbie,” with therefore imaginably few, if any restrictions on what a regular user can do with it, and that that file or directory is instead important toward making the pointer “arrow” symbol become visible over the LXDE window. Then by a change in ownership and permissions of that file or directory is one way I can imagine how the pointer “arrow” might switch from being invisible to being visible over the entire LXDE window. But this imagination of mine might not match reality in the relevant computer code. Now here is my best guess, which I present in the form of an outline, of a possible general, not very-specific explanation of the data I presented here. 1. I suppose that openSUSE code developers receive the source code for a new kernel version from an organization outside of openSUSE and then modify that code to make it suitable for an openSUSE environment. 2. I suppose that there was a change in the source code for the software package kernel-default from the Leap-15.5 kernel-default version 5.14.21-150500.55.65.1.x86_64 to the new series of Leap-15.6 kernel-default versions 6.4.0-150600.21….. regarding the initialization of something concerning the display of the touchpad- or “mouse”-pointer “arrow” over a Leap-15.6 desktop that required that a corresponding change be made in the source code for each type of desktop session, for example, Plasma (X11), LXDE, et cetera, in Leap 15.6. 3. I suppose that that necessary change was made in the Plasma (X11), desktop-session, computer source code, but for some reason was not also made in the LXDE, desktop-session, computer source code. For example, suppose that the developers of the Plasma (X11) and LXDE source codes are different human beings and that at a non-final stage of development the Plasma (X11) code developer passed along to the LXDE code developer his source code. From the word “Lightweight” appearing in the Lightweight X Windows System, Version 11 (X11) Desktop Environment (LXDE) desktop session I suppose that an LXDE desktop session is, in a perhaps oversimplified description, a reduced version of a Plasma (X11) desktop session. Assuming so, it would make sense for the LXDE code developer to use as a basis for his code development the Plasma (X11) code developer’s computer code and afterward to modify it according to the needs of an LXDE desktop session. Then suppose that at a later stage of development the Plasma (X11) code developer realized that he needed to make the change I have been discussing here in his source code and made it, but neglected to pass along the news to the LXDE code developer that he needed to make a similar change in the LXDE code. I think that I probably have some debugging computer software installed in my Leap-15.6 installation, based on the names of some online repositories set up in my Leap-15.6 installation. But I have not used such debugging computer software in recent years of time. In about the year 1998 I wrote some computer code in the Visual C++, computer programming language. I guess that much of the computer code used in an openSUSE Linux operating system might be written in the C, computer-programming language. Instead my experience in computer programming has mainly been in the Fortran, computer-programming language. Regarding debugging openSUSE computer source code it would seem good if I would be familiar with some C, computer-programming language and be able to debug such code using some debugging computer software that I might already have in my Leap-15.6 installation. In this regard I think it might be good if I could sit down for an hour or so of time with an expert in both the C, computer-programming language and the use of debugging computer software available to openSUSE, Leap-15.6, Linux users to have him show me and explain to me with his computer how he can debug some C-language computer code in an openSUSE, Leap-15.6 installation. Or instead I wonder if there would be a YouTube video provided on the Internet within https://www.youtube.com/… of someone showing how to use similar debugging computer software to debug openSUSE computer code, or less desirably, the computer code for some other distribution of a Linux operating system. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1225906] New: GCC14: Package openvswitch fails to build
by bugzilla_noreply＠suse.com 12 Jul '24

12 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1225906 Bug ID: 1225906 Summary: GCC14: Package openvswitch fails to build Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: mjambor(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1220574 Target Milestone: --- Found By: --- Blocker: --- Package openvswitch foes not build with GCC 14: It can be reproduced locally with command: osc build --clean --alternative-project home:rguenther:nextgcc but is also visible online: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… Even though it looks like it is one of the new errors of GCC 14 that used to be warnings, adding -fpermissive leads to link issues. Instead we need: https://github.com/openvswitch/ovs/commit/335a5deac3ff91448ca14651e92f39dfd… -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1225935] New: Package tftp does not build with gcc14 because of new errors
by bugzilla_noreply＠suse.com 12 Jul '24

12 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1225935 Bug ID: 1225935 Summary: Package tftp does not build with gcc14 because of new errors Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: mjambor(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1220571 Target Milestone: --- Found By: --- Blocker: --- GCC 14 newly by default treats as errors a number of situations which before were only warnings. For more information see https://gcc.gnu.org/gcc-14/porting_to.html and meta bug #1220571. Because of this, package tftp fails to compile. This can be seen online at: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… It can be reproduced locally with command: osc build --clean --alternative-project home:rguenther:nextgcc We most likely need the patch from https://bugzilla.redhat.com/show_bug.cgi?id=2148911 The (first) error (that halts the build) is: [ 18s] tftp.c: In function ‘tftp_sendfile’: [ 18s] tftp.c:88:5: error: implicit declaration of function ‘bsd_signal’; did you mean ‘ssignal’? [-Wimplicit-function-declaration] [ 18s] 88 | bsd_signal(SIGALRM, timer); [ 18s] | ^~~~~~~~~~ [ 18s] | ssignal -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1225926] New: Package seahorse does not build with gcc14 because of new errors
by bugzilla_noreply＠suse.com 12 Jul '24

12 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1225926 Bug ID: 1225926 Summary: Package seahorse does not build with gcc14 because of new errors Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: gnome-bugs(a)suse.de Reporter: mjambor(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1220571 Target Milestone: --- Found By: --- Blocker: --- GCC 14 newly by default treats as errors a number of situations which before were only warnings. For more information see https://gcc.gnu.org/gcc-14/porting_to.html and meta bug #1220571. Because of this, package seahorse fails to compile. This can be seen online at: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… It can be reproduced locally with command: osc build --clean --alternative-project home:rguenther:nextgcc Related Fedora notes (with a patch for a C99 issue): https://gitlab.com/fweimer-rh/fedora-modernc/-/blob/main/pkg/s/seahorse.md?… The (first) error (that halts the build) is: [ 19s] In file included from /usr/include/glib-2.0/glib.h:64, [ 19s] from /usr/include/glib-2.0/gobject/gbinding.h:30, [ 19s] from /usr/include/glib-2.0/glib-object.h:24, [ 19s] from /usr/include/glib-2.0/gio/gioenums.h:30, [ 19s] from /usr/include/glib-2.0/gio/giotypes.h:30, [ 19s] from /usr/include/glib-2.0/gio/gio.h:28, [ 19s] from common/seahorse-common.h:6, [ 19s] from ssh/seahorse-ssh.h:6, [ 19s] from ssh/libseahorse-ssh.a.p/operation.c:25: [ 19s] ssh/libseahorse-ssh.a.p/operation.c: In function ‘seahorse_ssh_operation_operation_async_co’: [ 19s] /usr/include/glib-2.0/glib/gmessages.h:671:16: error: returning ‘void *’ from a function with return type ‘gboolean’ {aka ‘int’} makes integer from pointer without a cast [-Wint-conversion] [ 19s] 671 | return (val); \ [ 19s] | ^ -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1225918] New: Package redland does not build with gcc14 because of new errors
by bugzilla_noreply＠suse.com 12 Jul '24

12 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1225918 Bug ID: 1225918 Summary: Package redland does not build with gcc14 because of new errors Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs(a)suse.de Reporter: mjambor(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1220571 Target Milestone: --- Found By: --- Blocker: --- GCC 14 newly by default treats as errors a number of situations which before were only warnings. For more information see https://gcc.gnu.org/gcc-14/porting_to.html and meta bug #1220571. Because of this, package redland fails to compile. This can be seen online at: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… It can be reproduced locally with command: osc build --clean --alternative-project home:rguenther:nextgcc The (first) error (that halts the build) is: [ 21s] rdf_files.c: In function 'librdf_files_temporary_file_name': [ 21s] rdf_files.c:96:6: error: implicit declaration of function 'mkostemp'; did you mean 'mkstemp'? [-Wimplicit-function-declaration] [ 21s] 96 | fd=mkostemp(name, O_CLOEXEC); [ 21s] | ^~~~~~~~ [ 21s] | mkstemp -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1222442] New: [20240404] Xorg crash running Android studio
by bugzilla_noreply＠suse.com 12 Jul '24

12 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1222442 Bug ID: 1222442 Summary: [20240404] Xorg crash running Android studio Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X.Org Assignee: gfx-bugs(a)suse.de Reporter: pujos.michael(a)gmail.com QA Contact: gfx-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Since snapshot 20240404 and upgrade of xorg-x11-server (21.1.11 -> 21.1.12), starting Android Studio crashes Xorg hard everytime. Most specifically, I am using Android Studio Koala | 2024.1.1 Canary 3 that can be downloaded here: https://developer.android.com/studio/preview. I would not be surprised this crash happens with other Jetbrains IDE but I have not tried. I triggered 2 crashes, both of which killed the Xorg process. There first crash had a crash stack in journalctl why the other did not: Apr 08 10:06:11 p72 systemd-coredump[16070]: [🡕] Process 11338 (Xorg.bin) of user 1000 dumped core. Stack trace of thread 11338: #0 0x00007f63b22949ec __pthread_kill_implementation (libc.so.6 + 0x949ec) #1 0x00007f63b2241176 raise (libc.so.6 + 0x41176) #2 0x00007f63b2228917 abort (libc.so.6 + 0x28917) #3 0x0000555e1e464efc n/a (/usr/bin/Xorg.bin + 0x1dbefc) #4 0x00007ffee9bf4ba0 n/a (n/a + 0x0) ELF object binary architecture: AMD x86-64 Reverting to 21.1.11 fixes that issue and I have added a lock for package xorg-x11-server for the time being. -- You are receiving this mail because: You are on the CC list for the bug.

1 17