December 2013 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 133718] memory allocation hangs during DVD-RAM writing
by bugzilla_noreply＠novell.com 12 Dec '13

12 Dec '13

https://bugzilla.novell.com/show_bug.cgi?id=133718 https://bugzilla.novell.com/show_bug.cgi?id=133718#c36 --- Comment #36 from Jan Kara <jack(a)suse.com> 2013-12-12 13:04:51 UTC --- Yeah, that's kind of expected given the load and the configuration - when userspace creates some memory pressure we have to get free pages somewhere. Since the USB storage is slow in cleaning dirty pages, page reclaim likely finds itself under pressure by dirty pages remaining for a long time at the end of the LRU list and either decides to swap (if possible) or synchronously waits for IO to complete before giving back new pages. And that causes hiccups. Actually for 4GB or 8GB systems current dirty_ratio setting is already a bit too high for a standard desktop. Can you try setting /proc/sys/vm/dirty_bytes to "250000000" (~250 MB) and /proc/sys/vm/dirty_background_bytes to "125000000" (~125 MB). Does it help with hangs? Can you observe some adverse effects of these changes when using the desktop? I'm asking because we are thinking about a similar change upstream and you are my Guinea pig :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 0

[Bug 802998] New: systemd tmpfile cleanup should not recurse below mount points
by bugzilla_noreply＠novell.com 12 Dec '13

12 Dec '13

https://bugzilla.novell.com/show_bug.cgi?id=802998 https://bugzilla.novell.com/show_bug.cgi?id=802998#c0 Summary: systemd tmpfile cleanup should not recurse below mount points Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: nrickert(a)ameritech.net QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 I was backing up my root partition. So I did: mkdir /tmp/a mount --bind / /tmp/a so that I could backup without other mounted file systems. While backing up, the "systemd" tmpfile cleanup process deleted around 2/3 of the content of my root file system. (I guess I'll have to do without that backup :( ) It is a fairly common unix practice to create temporary mount points in "/tmp" . agressive file cleanup should not be deleting content of mounted file systems. Reproducible: Didn't try Steps to Reproduce: 1. 2. 3. -- Configure bugmail: https://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 854894] New: booth-arbitrator init script broken
by bugzilla_noreply＠novell.com 12 Dec '13

12 Dec '13

https://bugzilla.novell.com/show_bug.cgi?id=854894 https://bugzilla.novell.com/show_bug.cgi?id=854894#c0 Summary: booth-arbitrator init script broken Classification: openSUSE Product: openSUSE Factory Version: 13.2 Milestone 0 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: High Availability AssignedTo: lmb(a)suse.com ReportedBy: tserong(a)suse.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- On openSUSE 13.1 and Factory, if I try to start booth-arbitrator: # /etc/init.d/booth-arbitrator start redirecting to systemctl start booth-arbitrator ..(very long delay here)... Job for booth-arbitrator.service failed. See 'systemctl status booth-arbitrator.service' and 'journalctl -xn' for details. factory-1:~ # systemctl status booth-arbitrator.service -l booth-arbitrator.service - LSB: start and stop BOOTH arbitrator daemon Loaded: loaded (/etc/init.d/booth-arbitrator) Active: failed (Result: timeout) since Wed 2013-12-11 20:39:34 EST; 18s ago Process: 1907 ExecStart=/etc/init.d/booth-arbitrator start (code=exited, status=0/SUCCESS) Dec 11 20:34:47 factory-1 booth-arbitrator[1916]: [1916]: debug: catchup result: name: ticketA, owner: -1, ballot: 0, expires: 0 Dec 11 20:34:47 factory-1 booth-arbitrator[1916]: [1916]: debug: attempting catchup from 192.168.4.250 Dec 11 20:34:50 factory-1 booth-arbitrator[1916]: [1916]: ERROR: connection to 192.168.4.250 error No route to host Dec 11 20:34:50 factory-1 booth-arbitrator[1916]: [1916]: debug: attempting catchup from 192.168.4.251 Dec 11 20:34:53 factory-1 booth-arbitrator[1916]: [1916]: ERROR: connection to 192.168.4.251 error No route to host Dec 11 20:34:53 factory-1 booth-arbitrator[1916]: [1916]: debug: catchup result: name: ticketB, owner: -1, ballot: 0, expires: 0 Dec 11 20:34:53 factory-1 booth-arbitrator[1916]: [1916]: info: BOOTH arbitrator daemon started Dec 11 20:39:34 factory-1 systemd[1]: booth-arbitrator.service operation timed out. Terminating. Dec 11 20:39:34 factory-1 systemd[1]: Failed to start LSB: start and stop BOOTH arbitrator daemon. Dec 11 20:39:34 factory-1 systemd[1]: Unit booth-arbitrator.service entered failed state. `journalctl -xn` gives: Dec 11 20:39:34 factory-1 systemd[1]: booth-arbitrator.service operation timed out. Terminating. Dec 11 20:39:34 factory-1 systemd[1]: Failed to start LSB: start and stop BOOTH arbitrator daemon. -- Subject: Unit booth-arbitrator.service has failed I suspect that when systemd takes over the init script, somehow booth is not daemonizing correctly so remains attached to the terminal. Note that even after the failure reported above, booth is actually running: # ps ax|grep booth 1916 ? SLs 0:00 /usr/sbin/boothd arbitrator But the init script doesn't think it is: # /etc/init.d/booth-arbitrator status BOOTH arbitrator daemon is cat: /var/run/booth.pid: No such file or directory cat: /var/run/booth.pid: No such file or directory Stopped So the pidfile is missing for some reason. Rather than fixing the init script or the daemon, or whatever is causing this behaviour, I'd suggest throwing away the init script and replacing it with a systemd unit file. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 2

[Bug 848775] New: Install grub2-branding takes "forever"
by bugzilla_noreply＠novell.com 12 Dec '13

12 Dec '13

https://bugzilla.novell.com/show_bug.cgi?id=848775 https://bugzilla.novell.com/show_bug.cgi?id=848775#c0 Summary: Install grub2-branding takes "forever" Classification: openSUSE Product: openSUSE 13.1 Version: RC 2 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: rschweikert(a)suse.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Installation of the grub2-branding-openSUSE package takes "forever". I believe this is related to disk scanning. The system has 1 60GB SSD, this is used as the system disk and has two >1TB spinning disks that are configure with LVM to store data, /home, music files etc. During the initial setup of the install the installer was already spinning for a rather long period of time when detecting the disk configuration and the LVM setup. Install of the kernel packages also took a long time. But grub2-branding-openSUSE tops them all. After more than 45 minutes this is still not done. The drive light on the machine is on indicating disk activity. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 13

[Bug 845590] New: the server rejects credentials for rawlog
by bugzilla_noreply＠novell.com 11 Dec '13

11 Dec '13

https://bugzilla.novell.com/show_bug.cgi?id=845590 https://bugzilla.novell.com/show_bug.cgi?id=845590#c0 Summary: the server rejects credentials for rawlog Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Minor Priority: P5 - None Component: BuildService AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: giecrilj(a)stegny.2a.pl QAContact: adrian(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 The OBS rejects credentials provided through the browser’s built-in authentication dialog box. Reproducible: Always Steps to Reproduce: 1. Tell Mozilla Firefox to navigate to <URL: https://build.opensuse.org/package/rawlog/home:doiggl/joomla/openSUSE_Facto… >. 2. Provide valid credentials to access the resource. 3. Provide valid credentials to access the resource. 4. Provide valid credentials to access the resource. and so on Actual Results: 1. Mozilla Firefox asks for authentication. 2. Mozilla Firefox asks for authentication. 3. Mozilla Firefox asks for authentication. 4. Mozilla Firefox asks for authentication. and so on Expected Results: 2. [ 0s] Using BUILD_ROOT=/var/cache/obs/worker/root_1/.mount and so on Workaround: log in on the main page first. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 3

[Bug 854646] New: Running grub2-mkconfig -o /boot/grub2/grub.cfg crashes some fs kernel modules
by bugzilla_noreply＠novell.com 11 Dec '13

11 Dec '13

https://bugzilla.novell.com/show_bug.cgi?id=854646 https://bugzilla.novell.com/show_bug.cgi?id=854646#c0 Summary: Running grub2-mkconfig -o /boot/grub2/grub.cfg crashes some fs kernel modules Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Critical Priority: P5 - None Component: Kernel AssignedTo: jslaby(a)suse.com ReportedBy: rmilasan(a)suse.com QAContact: qa-bugs(a)suse.de CC: duwe(a)suse.com Found By: L3 Blocker: --- If the system is having a kernel update or running manually 'grub2-mkconfig -o /boot/grub2/grub.cfg' we can see a lot of crashes and errors from several file systems (mainly xfs and reiserfs): [86670.434667] EXT4-fs (sda2): unable to read superblock [86670.435741] EXT4-fs (sda2): unable to read superblock [86670.436785] EXT4-fs (sda2): unable to read superblock [86670.437805] isofs_fill_super: bread failed, dev=sda2, iso_blknum=16, block=32 [86670.441084] FAT-fs (sda2): invalid media value (0x00) [86670.441087] FAT-fs (sda2): Can't find a valid FAT filesystem [86670.442173] REISERFS warning (device sda2): sh-2006 read_super_block: bread failed (dev sda2, block 8, size 1024) [86670.442177] REISERFS warning (device sda2): sh-2006 read_super_block: bread failed (dev sda2, block 64, size 1024) [86670.442178] REISERFS warning (device sda2): sh-2021 reiserfs_fill_super: can not find reiserfs on sda2 [86670.443478] XFS (sda2): bad magic number [86670.443484] ffff880220398000: eb 63 90 16 68 14 21 80 0c ff 35 d8 83 81 0c 8b .c..h.!...5..... [86670.443486] ffff880220398010: c8 e8 4d 7a 00 00 8b f0 eb 02 33 f6 85 f6 74 27 ..Mz......3...t' [86670.443489] ffff880220398020: 8b ce e8 17 73 00 00 8b d8 85 db 7c 14 e8 08 fe ....s......|.... [86670.443491] ffff880220398030: ff ff ff 75 0c 8b 06 68 50 1a 80 0c 56 ff 03 02 ...u...hP...V... [86670.443494] XFS (sda2): Internal error xfs_sb_read_verify at line 637 of file /home/abuild/rpmbuild/BUILD/kernel-desktop-3.12.3/linux-3.12/fs/xfs/xfs_sb.c. Caller 0xffffffffa05f2b8d [86670.443499] CPU: 0 PID: 231 Comm: kworker/0:1H Tainted: G O 3.12.3-1.gf37dca6-desktop #1 [86670.443500] Hardware name: Dell Inc. OptiPlex 990/06D7TR, BIOS A10 11/24/2011 [86670.443528] Workqueue: xfslogd xfs_buf_iodone_work [xfs] [86670.443529] 0000000000000000 0000000000000001 ffffffff815e8853 ffff8800ca9fa800 [86670.443531] ffffffffa05f5f22 ffffffffa05f2b8d 84d800be0000027d 00660fb6c68864ff [86670.443533] ffff880221260e40 0000000000000016 ffff8800ca9fa800 ffffe8ffffc01300 [86670.443535] Call Trace: [86670.443543] [<ffffffff81004c08>] dump_trace+0x88/0x300 [86670.443547] [<ffffffff81004f5a>] show_stack_log_lvl+0xda/0x1e0 [86670.443549] [<ffffffff810064ac>] show_stack+0x1c/0x50 [86670.443553] [<ffffffff815e8853>] dump_stack+0x50/0x80 [86670.443563] [<ffffffffa05f5f22>] xfs_corruption_error+0x62/0x90 [xfs] [86670.443596] [<ffffffffa064ebc1>] xfs_sb_read_verify+0x141/0x150 [xfs] [86670.443658] [<ffffffffa05f2b8d>] xfs_buf_iodone_work+0x8d/0xb0 [xfs] [86670.443673] [<ffffffff810703b6>] process_one_work+0x166/0x460 [86670.443688] [<ffffffff81070b36>] worker_thread+0x116/0x370 [86670.443698] [<ffffffff81077673>] kthread+0xb3/0xc0 [86670.443703] [<ffffffff815f64cc>] ret_from_fork+0x7c/0xb0 [86670.443708] XFS (sda2): Corruption detected. Unmount and run xfs_repair [86670.443723] XFS (sda2): SB validate failed with error 22. [86670.446331] FAT-fs (sda2): invalid media value (0x00) [86670.446334] FAT-fs (sda2): Can't find a valid FAT filesystem [86670.447405] MINIX-fs: unable to read superblock [86670.448407] attempt to access beyond end of device [86670.448409] sda2: rw=0, want=3, limit=2 [86670.448411] hfsplus: unable to find HFS+ superblock [86670.449471] qnx4: wrong fsid in superblock. [86670.450686] You didn't specify the type of your ufs filesystem mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ... >>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old [86670.452910] hfs: can't find a HFS filesystem on dev sda2 Normally, grub2 will try to check all types of installation and will load all modules for fs, but this seems to not work so well. NOTE: I'm running kernel 3.12.3 from http://download.opensuse.org/repositories/Kernel:/stable/standard/ repo. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 2

[Bug 685223] New: Thunar will not allow emptying trash after deleting files from USB, Space for deleted files is unrecoverable from GUI.
by bugzilla_noreply＠novell.com 11 Dec '13

11 Dec '13

https://bugzilla.novell.com/show_bug.cgi?id=685223 https://bugzilla.novell.com/show_bug.cgi?id=685223#c0 Summary: Thunar will not allow emptying trash after deleting files from USB, Space for deleted files is unrecoverable from GUI. Classification: openSUSE Product: openSUSE 11.4 Version: Factory Platform: x86-64 OS/Version: openSUSE 11.4 Status: NEW Severity: Minor Priority: P5 - None Component: Xfce AssignedTo: bnc-team-xfce(a)forge.provo.novell.com ReportedBy: dac1138(a)gmail.com QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.0) Gecko/20100101 Firefox/4.0 When plugging in a USB thumb drive and deleting files, Thunar does not provide me with an option to empty the trash. Thunar looks as if the files are deleted, but it doesn't show the space taken up by the files added back to the total amount of empty storage. If I browse to the USB drive using the command line, I can navigate to the .Trash folder and see the files/folders that I had just deleted and I can delete them this way. Thunar 1.3.0 OpenSuSE 11.4 with the latest updates as of 4/5/2011 Reproducible: Always Steps to Reproduce: 1. Insert USB thumb drive with files ready to be deleted 2. Select and delete files 3. Take note that there's no ability to empty the trash. 4. (optional) Using the command line, navigate to /media/Path-to-USB/.Trash and do "ls". You'll see the files that were deleted in step 2. Actual Results: After the steps above were performed to delete the files using Thunar, the disk space was unrecoverable. If I navigated and removed the files using the command line, everything worked fine and the space was useable again. Expected Results: Deleting files using Thunar should allow you to either permanently remove files without adding them to the trash, or move them to the trash with the ability to recover or permanently remove. Either way, when permanently removing files the space should be recovered and be useable again without having to go through the command line. -- Configure bugmail: https://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 848754] New: Xen domU can't find VG after dom0 is rebooted
by bugzilla_noreply＠novell.com 11 Dec '13

11 Dec '13

https://bugzilla.novell.com/show_bug.cgi?id=848754 https://bugzilla.novell.com/show_bug.cgi?id=848754#c0 Summary: Xen domU can't find VG after dom0 is rebooted Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Critical Priority: P5 - None Component: Xen AssignedTo: jdouglas(a)suse.com ReportedBy: eruby(a)knowledgematters.net QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 I build a Xen server using OpenSUSE 12.3 with all of the latest patches. I can reboot the server and it reboots just fine, no problems. Then I create several OpenSUSE 12.3 VMs. I can reboot the VMs and they reboot just fine, no problems. However, once I reboot the dom0 Xen server the domU VMs will no longer boot. The console shows 'Volume group "whatever" not found' errors. dom0 has a single physical LUN from a SAN with an LVM installed. The LVM has the VG name "switch". We are using multipathd and there are four fiberchannel paths to each LUN. The domU's are also single physical LUN from the same SAN with an LVM installed. The LVMs have a VG name matching the host name, e.g. host www4 has VG "www4". Everything works fine as long as I do not reboot dom0. Once dom0 reboots, none of the domUs can find their volume groups. I can see the volume groups when I type "vgdisplay" or "vgs" in dom0, but they cannot be accessed in their domU VMs. I did verify that the blkbk module is loaded. I have rebuilt the OpenSUSE 12.3 Xen server 4 times now. I get the same results each time. I suspect any problem this serious in 12.3 Xen would already have an open ticket, so there's probably something in my setup that isn't correct, or it could be something about the combination of multipathd + LVM + Xen I'm using. If anyone has any suggestions of what I should look at or what else I should try I'm open to suggestions. Separate data point: I also tried shutting down a OpenSUSE 11.4 domU running on a OpenSUSE 11.4 Xen server, I changed it's LUN mapping on the SAN so the LUN was visible on the OpenSUSE 12.3 Xen server, then tried to boot it up on the OpenSUSE 12.3 Xen server. I got the same error on the console that it could not find its volume group. I shut it down, remapped the LUN back to the 11.4 Xen server and bought it back up on the 11.4 Xen server without a problem. Reproducible: Always Steps to Reproduce: 1. Build OpenSUSE 12.3 Xen server 2. Build OpenSUSE 12.3 VMs 3. Reboot OpenSUSE 12.3 Xen Server 4. OpenSUSE 12.3 VMs no longer boot Actual Results: Non-working VMs Expected Results: Working VMs The Xen console for www4 shows: Will boot selected entry in 2 seconds [ 0.172967] PCI: Fatal: No config space access function found [ 0.176373] Unable to read sysrq code in control/sysrq [ 1.365196] i8042: No controller found [ 1.366095] /home/abuild/rpmbuild/BUILD/kernel-xen-3.7.10/linux-3.7/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) doing fast boot Creating device nodes with udev Volume group "www4" not found Volume group "www4" not found Volume group "www4" not found Volume group "www4" not found Volume group "www4" not found Trying manual resume from /dev/www4/swap0 Trying manual resume from /dev/www4/swap0 Waiting for device /dev/www4/root to appear: Reading all physical volumes. This may take a while... No volume groups found PARTIAL MODE. Incomplete logical volumes will be processed. Volume group "www4" not found PARTIAL MODE. Incomplete logical volumes will be processed. Volume group "www4" not found PARTIAL MODE. Incomplete logical volumes will be processed. Volume group "www4" not found PARTIAL MODE. Incomplete logical volumes will be processed. Volume group "www4" not found PARTIAL MODE. Incomplete logical volumes will be processed. Volume group "www4" not found PARTIAL MODE. Incomplete logical volumes will be processed. Volume group "www4" not found [this goes on for a long time.............] -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 28

[Bug 852611] New: openSUSE 13.1 shipped with buggy amavisd-new!
by bugzilla_noreply＠novell.com 11 Dec '13

11 Dec '13

https://bugzilla.novell.com/show_bug.cgi?id=852611 https://bugzilla.novell.com/show_bug.cgi?id=852611#c0 Summary: openSUSE 13.1 shipped with buggy amavisd-new! Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: HP OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: joerg.rohrer(a)upc-cablecom.ch QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 The error in mail log after zypper dup from 12.3 to 13.1- ----- (!)DENIED ACCESS due to INVALID PEER IP ADDRESS::ffff:127.0.0.1: lookup_ip_acl (inet_acl): IPv6 address [::ffff:127.0.0.1] contains fewer than 8 fields ----- fix please check: http://lists.amavis.org/pipermail/amavis-users/2013-September/002574.html --------------- Here is the patch from Mark Martinec --- amavisd~ 2013-09-04 14:43:24.000000000 +0200 +++ amavisd 2013-09-05 00:54:37.000000000 +0200 @@ -5612,5 +5612,5 @@ !grep($_ > 255, @d) or die "Invalid decimal field value in IPv6 address: [$ip]\n"; - $ipa = $2 . sprintf('%02x%02x:%02x%02x', @d); + $ipa = $1 . sprintf('%02x%02x:%02x%02x', @d); } elsif (!$have_ipv6 && $ipa =~ m{^ \d{1,3} (?: \. \d{1,3}){0,3} \z}xs) { # IPv4 @@ -5650,5 +5650,5 @@ @ip_fields >= 8 or die "IPv6 address [$ip] contains fewer than 8 fields\n"; @ip_fields <= 8 or die "IPv6 address [$ip] contains more than 8 fields\n"; - !grep(!/^[0-9a-zA-Z]{1,4}\z/, @ip_fields) # this is quite slow + !grep(!/^[0-9a-fA-F]{1,4}\z/, @ip_fields) # this is quite slow or die "Invalid syntax of IPv6 address: [$ip]\n"; my $vec = pack('n8', map(hex($_), at ip_fields)); Reproducible: Always Steps to Reproduce: 1. install amavisd-new from opensuse 13.1 repo 2. watch mail log. 3. Actual Results: mail-flow is broken. Expected Results: Test software first in some sort of real mailsystem. -- Configure bugmail: https://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 849914] New: Annoying: in some cases, 'directories' open in baobab instead of nautilus
by bugzilla_noreply＠novell.com 11 Dec '13

11 Dec '13

https://bugzilla.novell.com/show_bug.cgi?id=849914 https://bugzilla.novell.com/show_bug.cgi?id=849914#c0 Summary: Annoying: in some cases, 'directories' open in baobab instead of nautilus Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME AssignedTo: bnc-team-gnome(a)forge.provo.novell.com ReportedBy: dimstar(a)opensuse.org QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- baobab.desktop registers as a MIME handler for inode/directory, with some unfortunate consequences: 1) Download any file in Epiphany and click "Show in Folder" -> folder opens in Baobab instead of in Nautilus 2) Inserting removable media (external hard drive or USB stick) triggers a notification prompt to open in Baobab instead of Nautilus -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 6