August 2018 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1034320] New: kdevelop5.spec: improve summary & description
by bugzilla_noreply＠novell.com 03 Sep '21

03 Sep '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1034320 Bug ID: 1034320 Summary: kdevelop5.spec: improve summary & description Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: kossebau(a)kde.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Quite some people seem to think KDevelop is only for C++/Qt/KF5-based projects and only to be used with Plasma. To help with countering this wrong assumption, please consider updating the summary and description of the openSUSE package to the texts we have now set in the appdata.xml file (5.1 still has appdata with the old text, but new text content is also valid for 5.1). Cmp. https://cgit.kde.org/kdevelop.git/tree/org.kde.kdevelop.appdata.xml If you have proposals where to improve those new texts, happy to learn about it and also fix things in the appdata file. Summary: new: Featureful, plugin-extensible IDE for C/C++ and other programming languages old: C++ IDE using KDE technologies based on KDevelop Platform Description: new: " KDevelop is a Free and Open Source integrated development environment (IDE). It provides editing, navigation and debugging features for several programming languages, as well as integration with multiple build systems and version-control systems, using a plugin-based architecture. KDevelop has parser backends for C, C++ and Javascript/QML, with further external plugins supporting e.g. PHP or Python. " old: " An integrated development environment (IDE) based on the KDE Frameworks 5 which allows writing programs using C++ and optionally other languages through the use of plugins. It includes a documentation browser, a source code editor with syntax highlighting, a GUI for the compiler, and much more. " -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1010186] New: Kdenlive locks up when trying to add new clips
by bugzilla_noreply＠novell.com 29 Aug '21

29 Aug '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1010186 Bug ID: 1010186 Summary: Kdenlive locks up when trying to add new clips Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: neil(a)behindburlesque.co.uk QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When trying to add clips to an existing project, Kdenlive locks up or crashes. This happens regularly, but not always. Detail: Open an existing project Remove item on timeline - see note below Click dropdown to add clip to project Dialog opens and application often locks up before anything else can be clicked Alternatively, application sometimes crashes without opening the dialog at all Note This seems to be more prone to happening after removing an item from the timeline -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 909111] New: The rescan-scsi-bus.sh from the sgutils package is broken since SuSE-13.1
by bugzilla_noreply＠novell.com 26 Aug '21

26 Aug '21

http://bugzilla.opensuse.org/show_bug.cgi?id=909111 Bug ID: 909111 Summary: The rescan-scsi-bus.sh from the sgutils package is broken since SuSE-13.1 Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: dmarkh(a)cfl.rr.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 Build Identifier: This script no longer "finds new" or "removes no longer attached" scsi devices. As shown below, I have a scsi disk at scsi ID-0 at /dev/sg5. # lsscsi -g [0:0:0:0] disk ATA ST3320620AS K /dev/sda /dev/sg0 [13:0:0:0] process Marvell 91xx Config 1.01 - /dev/sg1 [16:0:0:0] disk IMPRIMIS 94601-15 4614 /dev/sdd /dev/sg5 [17:0:0:0] cd/dvd LITE-ON DVDRW LH-20A1P KL0G /dev/sr0 /dev/sg2 [18:0:0:0] disk ATA ST3160811AS E /dev/sdb /dev/sg3 [18:0:1:0] disk ATA ST3160815AS B /dev/sdc /dev/sg4 I remove the drive at scsi ID-0 drive and install an additional drive at scsi ID-1 then run the script. # rescan-scsi-bus.sh Scanning SCSI subsystem for new devices Scanning host 0 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning for device 0 0 0 0 ... OLD: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: ST3320620AS Rev: K Type: Direct-Access ANSI SCSI revision: 05 Scanning host 1 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 2 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 3 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 4 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 5 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 6 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 7 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 8 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 9 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 10 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 11 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 12 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 13 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning for device 13 0 0 0 ... OLD: Host: scsi13 Channel: 00 Id: 00 Lun: 00 Vendor: Marvell Model: 91xx Config Rev: 1.01 Type: Processor ANSI SCSI revision: 05 Scanning host 14 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 15 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 16 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning for device 16 0 0 0 ... OLD: Host: scsi16 Channel: 00 Id: 00 Lun: 00 Vendor: IMPRIMIS Model: 94601-15 Rev: 4614 Type: Direct-Access ANSI SCSI revision: 01 Scanning host 17 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning for device 17 0 0 0 ... OLD: Host: scsi17 Channel: 00 Id: 00 Lun: 00 Vendor: LITE-ON Model: DVDRW LH-20A1P Rev: KL0G Type: CD-ROM ANSI SCSI revision: 05 Scanning host 18 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning for device 18 0 0 0 ... OLD: Host: scsi18 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: ST3160811AS Rev: E Type: Direct-Access ANSI SCSI revision: 05 Scanning for device 18 0 1 0 ... OLD: Host: scsi18 Channel: 00 Id: 01 Lun: 00 Vendor: ATA Model: ST3160815AS Rev: B Type: Direct-Access ANSI SCSI revision: 05 0 new or changed device(s) found. 0 remapped or resized device(s) found. 0 device(s) removed. # lsscsi -g [0:0:0:0] disk ATA ST3320620AS K /dev/sda /dev/sg0 [13:0:0:0] process Marvell 91xx Config 1.01 - /dev/sg1 [16:0:0:0] disk IMPRIMIS 94601-15 4614 /dev/sdd /dev/sg5 [17:0:0:0] cd/dvd LITE-ON DVDRW LH-20A1P KL0G /dev/sr0 /dev/sg2 [18:0:0:0] disk ATA ST3160811AS E /dev/sdb /dev/sg3 [18:0:1:0] disk ATA ST3160815AS B /dev/sdc /dev/sg4 It not only did not remove the one at ID-0 that was removed, but did not find the new one attached. Below is an "lsscsi -g" after a reboot with BOTH drives attached. #lsscsi -g [0:0:0:0] disk ATA ST3320620AS K /dev/sda /dev/sg0 [13:0:0:0] process Marvell 91xx Config 1.01 - /dev/sg1 [16:0:0:0] disk IMPRIMIS 94601-15 4614 /dev/sdd /dev/sg5 [16:0:1:0] disk IMPRIMIS 94601-15 4614 /dev/sde /dev/sg6 [17:0:0:0] cd/dvd LITE-ON DVDRW LH-20A1P KL0G /dev/sr0 /dev/sg2 [18:0:0:0] disk ATA ST3160811AS E /dev/sdb /dev/sg3 [18:0:1:0] disk ATA ST3160815AS B /dev/sdc /dev/sg4 Reproducible: Always Steps to Reproduce: 1. See details 2. 3. Actual Results: This script, before SuSE-13.1 would remove any disks physically removed and add any physically added since boot. It is broken This is NOT kernel related as the same thing happens with a vanilla 3.16.7 kernel. I'm fairly certain this is a systemd issue. -- You are receiving this mail because: You are on the CC list for the bug.

2 16

[Bug 1039889] New: Yast handle category and pattern on a strange way for user visible/invisible
by bugzilla_noreply＠novell.com 26 Aug '21

26 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=1039889 Bug ID: 1039889 Summary: Yast handle category and pattern on a strange way for user visible/invisible Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: mlin(a)suse.com QA Contact: jsrain(a)suse.com CC: dimstar(a)opensuse.org Found By: --- Blocker: --- On TW snapshot 20170517 we see a strange situation on yast[1], while send 'down' key to 'x pattern', after press 'down' after 'font pattern'(x pattern is the next one) the list page is scroll up, the reason is 'Primary Functions' and 'Kubic Stack' entries suddenly appears on the top side. Dig into this issue I see weird behavior below: 1) at the beginning 'Primary Functions' and 'Kubic Stack' does not appear while scroll down the list to the bottom side, however after that, move to the top side these two entries appears at the top side. 2) press 'end' move the focus to the bottom side, and start repeating send 'up' key, till the focus was on the 'Server Functions' then press 'up' key again the next one is 'Kubic Stack'[2], and send 'up' key again the focus is lost[3], keep sending 'up' key the scroll bar does not change, now drag the scroll bar to the top side, I see 'Primary Functions' and 'Kubic Stack' is there, and the focus is on the 'Primary Functions' entry. issues lead us so confused the ordering of entries(and timing to resort entries) and pattern's visible/invisible, and thought that entry appeared suddenly at some point is a real bug. Note that, this issue now we only seen on NET install due to many patterns is only available from net install, tro to reproduce this issue from net iso[5] you have to set Server: openqa.opensuse.org and Directory: /assets/repo/openSUSE-Tumbleweed-oss-i586-x86_64-Snapshot20170517 from testing HEAD due to it's not published yet to download.o.o. [1] https://openqa.opensuse.org/tests/405554#step/installer_desktopselection/39 [2] http://susepaste.org/82684928 [3] http://susepaste.org/20244118 [4] http://susepaste.org/76581180 [5] https://openqa.opensuse.org/tests/405554/asset/iso/openSUSE-Tumbleweed-NET-… -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1079393] New: libyui-ncurses contains file in conflict with shared library packaging policy
by bugzilla_noreply＠novell.com 25 Aug '21

25 Aug '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1079393 Bug ID: 1079393 Summary: libyui-ncurses contains file in conflict with shared library packaging policy Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other URL: https://openqa.opensuse.org/tests/601880/modules/zdup/ steps/254 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: lnussel(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- ## Observation openQA test in scenario opensuse-15.0-DVD-x86_64-zdup-Leap-42.2-gnome@64bit fails in [zdup](https://openqa.opensuse.org/tests/601880/modules/zdup/steps/254) Independent of why this failure happens during zypper dup, the libyui-ncurses* package does not follow the shared library packaging policy. /usr/bin/libyui-terminal must not be in the shared library package as it prevents parallel installations with older versions obviously. -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1081754] New: trackerbug: packages do not build reproducibly
by bugzilla_noreply＠novell.com 22 Aug '21

22 Aug '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1081754 Bug ID: 1081754 Summary: trackerbug: packages do not build reproducibly Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE Factory Status: CONFIRMED Severity: Normal Priority: P5 - None Component: Development Assignee: bwiedemann(a)suse.com Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Depends on: 1040589, 1041090, 1047218, 1061219, 1062303 Found By: Development Blocker: --- This bug is a meta entry to collect bugs about packages that produce different results on every build and thus waste OBS build power for rebuilding depending packages and waste network bandwidth to sync results to mirrors and users. See also https://reproducible-builds.org/ for other reasons -- You are receiving this mail because: You are on the CC list for the bug.

2 22

[Bug 1033081] New: fetchmail hardcoded to use log file - syslogging thus unavailable
by bugzilla_noreply＠novell.com 18 Aug '21

18 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=1033081 Bug ID: 1033081 Summary: fetchmail hardcoded to use log file - syslogging thus unavailable Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: x86-64 OS: openSUSE 42.2 Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: jmozdzen(a)nde.ag QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- :~ # rpm -qi fetchmail Name : fetchmail Version : 6.3.26 Release : 18.1 Architecture: x86_64 Looking at fetchmail.service -> /usr/lib/fetchmail-systemd-exec, I see that using logging to log file is hard-coded there: --- cut here: /usr/lib/fetchmail-systemd-exec --- [...] exec /usr/bin/fetchmail $OPTS $FETCHMAIL_EXPERT_OPTIONS \ -f $FETCHMAIL_RC_PATH -L /var/log/fetchmail --- cut here --- Hence, activating logging to syslog via options doesn't work: --- cut here --- :~ # grep syslog /etc/fetchmailrc set syslog :~ # systemctl restart fetchmail :~ # 2017-04-09T17:36:13.480966+02:00 myhost fetchmail[4441]: syslog and logfile options are both set, ignoring syslog, and logging to /var/log/fetchmail --- cut here --- A possible change would be to move "-L /var/log/fetchmail" to /etc/sysconfig/fetchmail (i.e. to FETCHMAIL_EXPERT_OPTIONS variable, or a new one). -- You are receiving this mail because: You are on the CC list for the bug.

2 14

[Bug 927832] New: libreoffice does not discover printers in client only mdns setup
by bugzilla_noreply＠novell.com 18 Aug '21

18 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=927832 Bug ID: 927832 Summary: libreoffice does not discover printers in client only mdns setup Classification: openSUSE Product: openSUSE Factory Version: 201503* Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: LibreOffice Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- libreoffice only offers "Generic Printer" when run without cupsd. Printers can be discovered nevertheless using mdns and e.g. evince works fine. LO probably needs to be compiled to use the new cups 1.6 APIs: http://www.cups.org/documentation.php/doc-2.0/api-cups.html#cupsEnumDests -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1052150] New: ASIX ax88179 USB ethernet disconnects with error
by bugzilla_noreply＠novell.com 11 Aug '21

11 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=1052150 Bug ID: 1052150 Summary: ASIX ax88179 USB ethernet disconnects with error Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: tonyj(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 735177 --> http://bugzilla.suse.com/attachment.cgi?id=735177&action=edit supportconfig Anker USB 3.0 ethernet adapter randomly disconnects. Seems a known issue but I don't see any fixes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1333003 https://bugzilla.redhat.com/show_bug.cgi?id=1238617 link comes up after inserting adapter into USB3 port, generate some minor traffic (nature of traffic not relevant, ftp/scp/ssh all reproduce) and link drops. amount of time it takes varies. supposedly doesn't occur on USB2 but I've not tried this. latest 4.11.8-2-default kernel but it's been broken for a fair while. Hardware in question is a Macbook Pro (USB3) but I don't think it is on above redhat/ubuntu bugs. dmesg below, support config attached [11493.769864] usb 4-1: new SuperSpeed USB device number 3 using xhci_hcd [11493.796691] usb 4-1: New USB device found, idVendor=0b95, idProduct=1790 [11493.796696] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [11493.796699] usb 4-1: Product: AX88179 [11493.796701] usb 4-1: Manufacturer: ASIX Elec. Corp. [11493.796703] usb 4-1: SerialNumber: 0000000000015E [11494.131928] ax88179_178a 4-1:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:00:0d:00:ee:30 [11494.153818] ax88179_178a 4-1:1.0 enp0s20u1: renamed from eth0 [11494.204082] IPv6: ADDRCONF(NETDEV_UP): enp0s20u1: link is not ready [11494.529718] IPv6: ADDRCONF(NETDEV_UP): enp0s20u1: link is not ready [11497.127891] ax88179_178a 4-1:1.0 enp0s20u1: ax88179 - Link status is: 1 [11497.133370] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s20u1: link becomes ready [12021.041777] xhci_hcd 0000:00:14.0: Cannot set link state. [12021.041788] usb usb4-port1: cannot disable (err = -32) [12021.041793] usb 4-1: USB disconnect, device number 3 [12021.042026] ax88179_178a 4-1:1.0 enp0s20u1: unregister 'ax88179_178a' usb-0000:00:14.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet [12021.042053] ax88179_178a 4-1:1.0 enp0s20u1: Failed to read reg index 0x0002: -19 [12021.042056] ax88179_178a 4-1:1.0 enp0s20u1: Failed to write reg index 0x0002: -19 [12021.061697] ax88179_178a 4-1:1.0 enp0s20u1 (unregistered): Failed to write reg index 0x0002: -19 [12021.061699] ax88179_178a 4-1:1.0 enp0s20u1 (unregistered): Failed to write reg index 0x0001: -19 [12021.061700] ax88179_178a 4-1:1.0 enp0s20u1 (unregistered): Failed to write reg index 0x0002: -19 -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1026449] New: vagrant fails configuring VM network
by bugzilla_noreply＠novell.com 09 Aug '21

09 Aug '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1026449 Bug ID: 1026449 Summary: vagrant fails configuring VM network Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Other Assignee: virt-bugs(a)suse.de Reporter: dennis.keck(a)rock5.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Using 1.9.1-9.1-x86_64 from Virtualization When using vagrant up for a Ubuntu VM with configured "vm.network" this error occurs: /usr/share/vagrant/plugins/guests/debian/cap/configure_networks.rb:3:in `require_relative': cannot load such file -- /usr/share/vagrant/plugins/guests/debian/cap/vagrant/util/template_renderer (LoadError) This happens because of a wrongly set require_relative which is still just like it should be when using vagrant as a rubygem. See this bugreport on the Debian bug mailing list: https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1449666.h… This change should be applied to all distribution specific configure_networks.rb templates. Full error output: /usr/share/vagrant/plugins/guests/debian/cap/configure_networks.rb:3:in `require_relative': cannot load such file -- /usr/share/vagrant/plugins/guests/debian/cap/vagrant/util/template_renderer (LoadError) from /usr/share/vagrant/plugins/guests/debian/cap/configure_networks.rb:3:in `<top (required)>' from /usr/share/vagrant/plugins/guests/debian/plugin.rb:15:in `require_relative' from /usr/share/vagrant/plugins/guests/debian/plugin.rb:15:in `block in <class:Plugin>' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/registry.rb:27:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/registry.rb:27:in `get' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/capability_host.rb:170:in `block in capability_module' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/capability_host.rb:164:in `each' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/capability_host.rb:164:in `capability_module' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/capability_host.rb:92:in `capability' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/guest.rb:43:in `capability' from /usr/share/vagrant/plugins/providers/virtualbox/action/network.rb:133:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/clear_network_interfaces.rb:26:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/prepare_nfs_settings.rb:18:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/synced_folders.rb:87:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/synced_folder_cleanup.rb:28:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/synced_folders/nfs/action_cleanup.rb:25:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/prepare_nfs_valid_ids.rb:12:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:49:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/prepare_forwarded_port_collision_params.rb:30:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/env_set.rb:19:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/provision.rb:80:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/clear_forwarded_ports.rb:15:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/set_name.rb:19:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/clean_machine_folder.rb:17:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/box_check_outdated.rb:78:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/config_validate.rb:25:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/config_validate.rb:25:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/machine.rb:225:in `action_raw' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/machine.rb:200:in `block in action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/environment.rb:533:in `lock' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/machine.rb:186:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/machine.rb:186:in `action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run' -- You are receiving this mail because: You are on the CC list for the bug.

2 1