February 2010 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 503065] New: yast2-printer: suppress "root"-instances
by bugzilla_noreply＠novell.com 15 Apr '16

15 Apr '16

http://bugzilla.novell.com/show_bug.cgi?id=503065 Summary: yast2-printer: suppress "root"-instances Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: All OS/Version: openSUSE 11.1 Status: ASSIGNED Severity: Minor Priority: P5 - None Component: YaST2 AssignedTo: jsmeix(a)novell.com ReportedBy: jsmeix(a)novell.com QAContact: jsrain(a)novell.com CC: jw(a)novell.com Found By: Development As root create instances, e.g.: root@host# lpoptions -p hplaserjet1220/Letter -o PageSize=Letter root@host# lpoptions -p hplaserjet1220/Legal -o PageSize=Legal root@host# cat /etc/cups/lpoptions Dest hplaserjet1220/Legal PageSize=Legal Dest hplaserjet1220/Letter PageSize=Letter root@host# lpstat -p printer hplaserjet1220 is idle. enabled since Thu May 7 19:29:20 2009 printer hplaserjet1220/Legal is idle. enabled since Thu May 7 19:29:20 2009 printer hplaserjet1220/Letter is idle. enabled since Thu May 7 19:29:20 2009 The yast2-printer shows the instances in the "Overview" dialog as "Remote" queues because it uses "Remote" as fallback for each "printer" which is shown by lpstat but which is not found in /etc/cups/printers.conf It is not recommende that root crates instances in /etc/cups/lpoptions because those instances do not appear via CUPS Browsing in the network Instead each normal user should create its own instances which are stored in ~/.cups/lpoptions Therefore there will be no support for "root"-instances in yast2-printer so that yast2-printer must only suppress instances in /etc/cups/lpoptions -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 4

[Bug 502957] New: the new version of wpa_supplicant causes NetworkManager to fail with wireless networks
by bugzilla_noreply＠novell.com 15 Apr '16

15 Apr '16

http://bugzilla.novell.com/show_bug.cgi?id=502957 Summary: the new version of wpa_supplicant causes NetworkManager to fail with wireless networks Classification: openSUSE Product: openSUSE 11.2 Version: Factory Platform: i686 OS/Version: SuSE Other Status: NEW Severity: Major Priority: P5 - None Component: Network AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: tittiatcoke(a)gmail.com QAContact: qa(a)suse.de Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1b4) Gecko/20090426 SUSE/3.5b4-1.2 Firefox/3.5b4 Factory of May 10 contains an updated version of wpa_supplicant. This brings it's version from 0.6.4 to 0.6.9. However this version does not work correctly. After a restart, NetworkManager is indicating that the wireless interface is not available. After some checking it appears that NetworkManager can not communicate somehow with wpa_supplicant. Also ifup/iwconfig can not bring the wireless network up as it should be. In the NetworkManager logfile I see the following : May 10 17:41:51 hqvm000261 NetworkManager: <info> (wlan0): device state change: 1 -> 2 May 10 17:41:51 hqvm000261 NetworkManager: <info> (wlan0): bringing up device. May 10 17:41:51 hqvm000261 NetworkManager: <info> (wlan0): preparing device. May 10 17:41:51 hqvm000261 NetworkManager: <info> (wlan0): deactivating device (reason: 2). May 10 17:41:51 hqvm000261 NetworkManager: supplicant_interface_acquire: assertion `mgr_state == NM_SUPPLICANT_MANAGER_STATE_IDLE' failed Switching back to wpa_supplicant version 0.6.4 and everything works smoothly again. Reproducible: Always Steps to Reproduce: 1.Update to factory (May 10) 2.Restart system (or restart network) 3. Actual Results: NetworkManager indicate that the wireless interface is not working.Also trying to bring the wireless network up with ifup/iwconfig does not function. Expected Results: Working network -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 5

[Bug 501724] New: firefox 3.5 downloads into some weird wherever-defined directory
by bugzilla_noreply＠novell.com 15 Apr '16

15 Apr '16

http://bugzilla.novell.com/show_bug.cgi?id=501724 Summary: firefox 3.5 downloads into some weird wherever-defined directory Classification: openSUSE Product: openSUSE 11.2 Version: Factory Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Firefox AssignedTo: bnc-team-mozilla(a)forge.provo.novell.com ReportedBy: jmatejek(a)novell.com QAContact: qa(a)suse.de Found By: --- There should be a consistent default download location across firefox versions and across distribution releases. On linux, that location should obviously be $HOME. There were some long-standing bugs in firefox that made it impossible, so i got used to downloading to $HOME/Desktop. (note that it's "Desktop" not "Plocha", "Arbeitsplatz" or "页文电子图书") And for a time, it was good. steps to reproduce: 1. do your packaging work 2. download a new version of a package with firefox (yeah, i know, should've used wget). this time it's GraphicsMagick-1.1.5.tar.bz2 3. back to shell, try to copy from download location to current directory: $ cp ~/Desktop/Gra<TAB> (beep) 4. aha, so we're (finally?) back to downloading to home? $ cp ~/Gra<TAB> (beep) 5. check manually... $ ls ~ (nothing of interest) $ ls ~/Desktop (nothing of interest) 6. open firefox download window, right-click the file, show folder !!!! 7. stare in disbelief as a Nautilus window opens with a directory called "Stažené soubory" (that's "downloaded files") !!!! 8. bang head against desk see, this is why openSUSE is hacker unfriendly! well okay, this might be firefox's fault, but anyway. whose braindead idea was this? not only creating a special directory for downloads (what was wrong with downloading to $HOME? oh, i remember, poor windows users don't get to see their $HOME ... alright then what was wrong with downloading to desktop?), but localizing its name? now come on, that is just ... wtf. Additional info: all download-related settings from about:config are on their default states. i like them that way, because i tend to change location of $HOME from time to time, and i can always rely on finding my files in ~/Desktop. (well not anymore, i guess) but granted, not many people move their $HOME around -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 26

[Bug 501397] New: Build packages against xulrunner191
by bugzilla_noreply＠novell.com 15 Apr '16

15 Apr '16

http://bugzilla.novell.com/show_bug.cgi?id=501397 Summary: Build packages against xulrunner191 Classification: openSUSE Product: openSUSE 11.2 Version: Factory Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME AssignedTo: vuntz(a)novell.com ReportedBy: vuntz(a)novell.com QAContact: qa(a)suse.de Found By: --- AFAIK, the following packages need to be moved to xulrunner191: librsvg (need some patch) mozilla-bonobo (need some patch) The following packages have been moved but need testing (submitted to G:F right now): PackageKit (it installs a plugin, iirc) gnome-web-photo (check that HTML pages still get thumbnailed in nautilus) jscall-sharp (no idea how to test) libproxy (not sure what's the best way to test it) liferea (just read a feed ;-)) rhythmbox (it installs a plugin, iirc) The following packages have been moved and tested: python-gnome-extras The following packages could be done too, but we'll probably ignore them because of the GNOME switch to webkit that should happen soon: epiphany epiphany-plugins seahorse-plugins yelp (if someone want to migrate and test them, this will still be accepted) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 7

[Bug 501037] New: incorrect coding of the text in the menu LanguageTool
by bugzilla_noreply＠novell.com 15 Apr '16

15 Apr '16

http://bugzilla.novell.com/show_bug.cgi?id=501037 Summary: incorrect coding of the text in the menu LanguageTool Classification: openSUSE Product: openSUSE 11.2 Version: Factory Platform: Other OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: OpenOffice.org AssignedTo: bnc-team-ooo(a)forge.provo.novell.com ReportedBy: egd.free(a)gmail.com QAContact: kyu(a)novell.com Found By: --- User-Agent: Opera/9.64 (X11; Linux i686; U; ru) Presto/2.1.1 after installation OpenOffice_org-LanguageTool-0.9.7-2.5 from the menu all the new items look like "????????????????" see attaches Reproducible: Always Steps to Reproduce: 1. install packeges OpenOffice_org-LanguageTool-0.9.7-2.5, OpenOffice_org-LanguageTool-en-0.9.7-2.5, OpenOffice_org-LanguageTool-ru-0.9.7-2.5 2. Run OOo Writer -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 8

[Bug 500661] New: wvdial fails to retry on modem init string sending
by bugzilla_noreply＠novell.com 15 Apr '16

15 Apr '16

http://bugzilla.novell.com/show_bug.cgi?id=500661 Summary: wvdial fails to retry on modem init string sending Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: All OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: osv(a)kiae.ru QAContact: qa(a)suse.de Found By: --- Created an attachment (id=289746) --> (http://bugzilla.novell.com/attachment.cgi?id=289746) patch to solve the problem User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) SUSE There is a trivial bug which is probably rather a typo in the wvdialer.cc code. The bug is in the modem init strings sending code below: modem->print( "%s\r", *this_str ); log( "Sending: %s\n", *this_str ); received = wait_for_modem( init_responses, 5000, true ); switch( received ) { case -1: modem->print( "ATQ0\r" ); log( "Sending: ATQ0\n" ); received = wait_for_modem( init_responses, 500, true ); modem->print( "%s\r", *this_str ); log( "Re-Sending: %s\n", *this_str ); received = wait_for_modem( init_responses, 5000, true ); switch( received ) { case -1: err( "Modem not responding.\n" ); return( false ); case 1: err( "Bad init string.\n" ); return( false ); } goto end_outer; The code's purpose is to send modem init strings such as "ATZ" at the beginning of the dialer session. As you see the code tries to resend an init string in case the was no response from the modem on the first try. The problem with the bug is the re-sending does not help even if the sending succeeds on the second try. This is due to "goto end_outer;" statement at the end of the above fragment. The statement makes the wvdial leave the init strings sending loop even after the re-sending succeeds. I guess it was a typo and the author's intention was to place "break;" statement here to proceed with sending the init strings. I did find this bug rather annoying due to my modem has a bad habit of not responding randomly on the first init string sent to it. It does respond when the string is resent, but the bug fails the wvdialer session anyway. I was forced to restart wvdial again and again until the modem's response to the first init string was catched from the first try. Finally I did find the bug and I am happy now thanks to the open source. Hopefully the fix will be in the next release. The patch for 1.56 is attached. Reproducible: Always Steps to Reproduce: 1. 2. 3. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 4

[Bug 500520] New: totem does not work outside of gnome
by bugzilla_noreply＠novell.com 15 Apr '16

15 Apr '16

http://bugzilla.novell.com/show_bug.cgi?id=500520 Summary: totem does not work outside of gnome Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Other AssignedTo: bnc-team-gnome(a)forge.provo.novell.com ReportedBy: lnussel(a)novell.com QAContact: qa(a)suse.de CC: vuntz(a)novell.com Found By: Development totem does not work outside of gnome with remote URLs. That renders esp the very cool browser plugin useless in practice when firefox is used on alternative desktops. Try for example (with the proper codecs installed): $ totem http://www.cinecitta.de/filmeevents/startrek.mov ** Message: no file info ** Message: Error: Resource not found. gstfilesrc.c(1018): gst_file_src_start (): /GstPlayBin:play/GstFileSrc:source: No such file "/filmeevents/startrek.mov" Gstreamer itself works fine though: $ gst-launch-0.10 playbin uri=http://www.cinecitta.de/filmeevents/startrek.mov [plays movie] Same problem with packages from Factory. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 18

[Bug 498669] New: Nagios ntp check check_ntp_peer aborts due to buffer overflow
by bugzilla_noreply＠novell.com 15 Apr '16

15 Apr '16

http://bugzilla.novell.com/show_bug.cgi?id=498669 Summary: Nagios ntp check check_ntp_peer aborts due to buffer overflow Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: All OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jschrod(a)acm.org QAContact: qa(a)suse.de Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.19) Gecko/20081213 SUSE/1.1.14-1.1 SeaMonkey/1.1.14 The Nagios check command check_ntp_peer aborts with a message that a buffer overflow is detected and outputs a stack backtrace. The check command is from package nagios-plugins-1.4.13-1.4. Reproducible: Always Steps to Reproduce: 1. Call /usr/lib/nagios/plugins/check_ntp_peer -H localhost This happens both on x86 and x86_64, so it's probably not system dependent. On localhost NTP is configured and active, in case that matters. Actual Results: Command output: *** buffer overflow detected ***: /usr/lib/nagios/plugins/check_ntp_peer terminated ======= Backtrace: ========= /lib/libc.so.6(__fortify_fail+0x48)[0xb7f55db8] /lib/libc.so.6[0xb7f53dd0] /lib/libc.so.6(__read_chk+0x58)[0xb7f542d8] /usr/lib/nagios/plugins/check_ntp_peer[0x804a0a1] /usr/lib/nagios/plugins/check_ntp_peer[0x804ac0e] /lib/libc.so.6(__libc_start_main+0xe5)[0xb7e85705] /usr/lib/nagios/plugins/check_ntp_peer[0x8048f01] ======= Memory map: ======== 08048000-0804f000 r-xp 00000000 09:02 430573 /usr/lib/nagios/plugins/check_ntp_peer 0804f000-08050000 r--p 00007000 09:02 430573 /usr/lib/nagios/plugins/check_ntp_peer 08050000-08051000 rw-p 00008000 09:02 430573 /usr/lib/nagios/plugins/check_ntp_peer 08051000-08072000 rw-p 08051000 00:00 0 [heap] b7e53000-b7e60000 r-xp 00000000 09:02 1215108 /lib/libgcc_s.so.1 b7e60000-b7e61000 r--p 0000c000 09:02 1215108 /lib/libgcc_s.so.1 b7e61000-b7e62000 rw-p 0000d000 09:02 1215108 /lib/libgcc_s.so.1 b7e62000-b7e6c000 r-xp 00000000 09:02 1216926 /lib/libnss_files-2.9.so b7e6c000-b7e6d000 r--p 00009000 09:02 1216926 /lib/libnss_files-2.9.so b7e6d000-b7e6e000 rw-p 0000a000 09:02 1216926 /lib/libnss_files-2.9.so b7e6e000-b7e6f000 rw-p b7e6e000 00:00 0 b7e6f000-b7fc4000 r-xp 00000000 09:02 1215002 /lib/libc-2.9.so b7fc4000-b7fc5000 ---p 00155000 09:02 1215002 /lib/libc-2.9.so b7fc5000-b7fc7000 r--p 00155000 09:02 1215002 /lib/libc-2.9.so b7fc7000-b7fc8000 rw-p 00157000 09:02 1215002 /lib/libc-2.9.so b7fc8000-b7fcc000 rw-p b7fc8000 00:00 0 b7fcc000-b7fcf000 r-xp 00000000 09:02 1216792 /lib/libdl-2.9.so b7fcf000-b7fd0000 r--p 00002000 09:02 1216792 /lib/libdl-2.9.so b7fd0000-b7fd1000 rw-p 00003000 09:02 1216792 /lib/libdl-2.9.so b7fd1000-b7ff8000 r-xp 00000000 09:02 1216921 /lib/libm-2.9.so b7ff8000-b7ff9000 r--p 00026000 09:02 1216921 /lib/libm-2.9.so b7ff9000-b7ffa000 rw-p 00027000 09:02 1216921 /lib/libm-2.9.so b7ffa000-b800c000 r-xp 00000000 09:02 1216929 /lib/libresolv-2.9.so b800c000-b800d000 r--p 00011000 09:02 1216929 /lib/libresolv-2.9.so b800d000-b800e000 rw-p 00012000 09:02 1216929 /lib/libresolv-2.9.so b800e000-b8010000 rw-p b800e000 00:00 0 b8010000-b8025000 r-xp 00000000 09:02 1215013 /lib/libnsl-2.9.so b8025000-b8026000 r--p 00014000 09:02 1215013 /lib/libnsl-2.9.so b8026000-b8027000 rw-p 00015000 09:02 1215013 /lib/libnsl-2.9.so b8027000-b8029000 rw-p b8027000 00:00 0 b804e000-b804f000 rw-p b804e000 00:00 0 b804f000-b806d000 r-xp 00000000 09:02 1217040 /lib/ld-2.9.so b806d000-b806e000 r--p 0001d000 09:02 1217040 /lib/ld-2.9.so b806e000-b806f000 rw-p 0001e000 09:02 1217040 /lib/ld-2.9.so bfc58000-bfc6e000 rw-p bffea000 00:00 0 [stack] ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso] Aborted Expected Results: Command shall check if I have good NTP peers. I know of check_ntp and that works; but that's deprecated. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 4

[Bug 498435] New: sane-backends: 4 * undefined code
by bugzilla_noreply＠novell.com 15 Apr '16

15 Apr '16

http://bugzilla.novell.com/show_bug.cgi?id=498435 Summary: sane-backends: 4 * undefined code Classification: openSUSE Product: openSUSE 11.2 Version: Factory Platform: All OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: dcb314(a)hotmail.com QAContact: qa(a)suse.de Found By: --- I just tried to build Factory package sane-backends-1.0.19-102.32 and the build said 1. mustek_pp_ccd300.c:1016: warning: operation on 'priv->blueline' may be undefined The source code is priv->blueline = ++priv->blueline % priv->blue_offs; I agree with the compiler. Better code would be priv->blueline = (priv->blueline + 1) % priv->blue_offs; 2. mustek_pp_ccd300.c:946: warning: operation on 'priv->blueline' may be undefined mustek_pp_ccd300.c:943: warning: operation on 'priv->blueline' may be undefined mustek_pp_ccd300.c:982: warning: operation on 'priv->blueline' may be undefined Duplicates. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 6

[Bug 498429] New: adding cups to allowed services in the firewall does not allow broadcasting
by bugzilla_noreply＠novell.com 15 Apr '16

15 Apr '16

http://bugzilla.novell.com/show_bug.cgi?id=498429 Summary: adding cups to allowed services in the firewall does not allow broadcasting Classification: openSUSE Product: openSUSE 11.2 Version: Milestone 1 Platform: x86 OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: christiandehne(a)web.de QAContact: jsrain(a)novell.com Found By: --- User-Agent: Mozilla/5.0 (compatible; Konqueror/4.2; Linux) KHTML/4.2.2 (like Gecko) SUSE I wanted to have my network in an external zone, but allow network printing via cups. So I enabled the cups service in the firewall module of yast, but still no remote printers were listed in the printer module of yast, although several are available in my network. I have to manually add '631' in the field for the external zone in the broadcast section of the firewall module or to modify to receive the printers via cups. Reproducible: Always Actual Results: No remote printers found after enabling the cups service in the firewall module. Expected Results: Remote printers are shown after enabling cups service in the firewall. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 9