[Desktop-packages] [Bug 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

** No longer affects: libnl3 (Ubuntu Precise)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578

Title:
   libnl should be updated to support up to 63 VFs per single PF

Status in libnl3 package in Ubuntu:
  Fix Released
Status in libnl3 source package in Trusty:
  Fix Released

Bug description:
  [Impact]

  libnl can only enable up to 30 VFs even if the PF supports up to 63
  VFs in an Openstack SRIOV configuration.

  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on
  Ubuntu 14.04.4.

  When trying to enable a guest with more than 30 VFs attached, the
  following error is returned:

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

  [Test Case]

   1) Edit /etc/default/grub.

  GRUB_CMDLINE_LINUX="intel_iommu=on ixgbe.max_vfs=63"

   2) Update grub and reboot the machine.

  $ sudo update-grub

   3) Check that the virtual functions are available.

  $ sudo lspci|grep -i eth | grep -i virtual | wc -l
  126

   4) Create a KVM guest.

  $ sudo uvt-kvm create guest1 release=trusty

   5) List the VF devices.

  $ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed
  's/\:/\_/g' | sed 's/\./\_/g' > devices.txt

   6) Get the libvirt node device.

  $ sudo for device in $(cat ./devices.txt); do virsh nodedev-list |
  grep $device; done > pci_devices.txt

   7) Generate the XML config for each device.

  $ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh
  nodedev-dumpxml $d > devices/$d.xml; done

   8) Save and Run the following script.
  (http://pastebin.ubuntu.com/23374186/)

  $ sudo python generate-interfaces.py |grep address | wc -l

   9) Finally attach the devices to the guest.

  $ sudo for i in $(seq 0 63); do virsh attach-device guest1 
./interfaces/$i.xml --config; done
  Device attached successfully
  [...]

  Device attached successfully
  Device attached successfully

   10) Then destroy/start the guest again, at this point the error is
  reproduced.

  $ sudo virsh destroy guest1
  Domain guest1 destroyed

  $ sudo virsh start guest1

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

  [Regression Potential]

   * None identified.

  [Other Info]

   * Redhat Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1040626

   * A workaround is to install a newer library release.

  $ wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  $ wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  $ wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
  $ dpkg -i libnl-3-200_3.2.24-2_amd64.deb
  $ dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
  $ dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

Hello Bryan,

After installing the -proposed version the error presented on this bug
is not reproducible anymore and the guest starts correctly.

You can follow the reproduction steps that I added to the bug's
description.

Without -proposed:

$ sudo virsh destroy guest1
Domain guest1 destroyed

$ sudo virsh start guest1

error: Failed to start domain guest1
error: internal error: missing IFLA_VF_INFO in netlink response

With proposed:

root@bronzor:/home/ubuntu# start libvirt-bin
libvirt-bin start/running, process 31492

root@bronzor:/home/ubuntu# virsh start guest1
Domain guest1 started


** Tags removed: verification-needed
** Tags added: verification-done

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578

Title:
   libnl should be updated to support up to 63 VFs per single PF

Status in libnl3 package in Ubuntu:
  Fix Released
Status in libnl3 source package in Precise:
  New
Status in libnl3 source package in Trusty:
  Fix Committed

Bug description:
  [Impact]

  libnl can only enable up to 30 VFs even if the PF supports up to 63
  VFs in an Openstack SRIOV configuration.

  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on
  Ubuntu 14.04.4.

  When trying to enable a guest with more than 30 VFs attached, the
  following error is returned:

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

  [Test Case]

   1) Edit /etc/default/grub.

  GRUB_CMDLINE_LINUX="intel_iommu=on ixgbe.max_vfs=63"

   2) Update grub and reboot the machine.

  $ sudo update-grub

   3) Check that the virtual functions are available.

  $ sudo lspci|grep -i eth | grep -i virtual | wc -l
  126

   4) Create a KVM guest.

  $ sudo uvt-kvm create guest1 release=trusty

   5) List the VF devices.

  $ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed
  's/\:/\_/g' | sed 's/\./\_/g' > devices.txt

   6) Get the libvirt node device.

  $ sudo for device in $(cat ./devices.txt); do virsh nodedev-list |
  grep $device; done > pci_devices.txt

   7) Generate the XML config for each device.

  $ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh
  nodedev-dumpxml $d > devices/$d.xml; done

   8) Save and Run the following script.
  (http://pastebin.ubuntu.com/23374186/)

  $ sudo python generate-interfaces.py |grep address | wc -l

   9) Finally attach the devices to the guest.

  $ sudo for i in $(seq 0 63); do virsh attach-device guest1 
./interfaces/$i.xml --config; done
  Device attached successfully
  [...]

  Device attached successfully
  Device attached successfully

   10) Then destroy/start the guest again, at this point the error is
  reproduced.

  $ sudo virsh destroy guest1
  Domain guest1 destroyed

  $ sudo virsh start guest1

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

  [Regression Potential]

   * None identified.

  [Other Info]

   * Redhat Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1040626

   * A workaround is to install a newer library release.

  $ wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  $ wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  $ wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
  $ dpkg -i libnl-3-200_3.2.24-2_amd64.deb
  $ dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
  $ dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

** Patch added: "fix-1567578-trusty.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+attachment/4766476/+files/fix-1567578-trusty.debdiff

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578

Title:
   libnl should be updated to support up to 63 VFs per single PF

Status in libnl3 package in Ubuntu:
  Fix Released
Status in libnl3 source package in Precise:
  New
Status in libnl3 source package in Trusty:
  In Progress

Bug description:
  [Description]

  Ubuntu 14.04.4 and SRIOV settings.

  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on
  Ubuntu 14.04.4

  When trying to enable a guest with more than 30 VFs attached, the
  following error is returned:

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

  [Impact]

  The library release is the 3.2.21-1 the bug is impacting on the
  maximum VFs number that can be enabled (up to 30) even if the PF
  supports up to 63 VFs in an Openstack SRIOV configuration

  [Test Case]

  The sequence to reproduce this bug is:

  1) Edit /etc/default/grub

  GRUB_CMDLINE_LINUX="intel_iommu=on ixgbe.max_vfs=63"

  2) $ sudo update-grub

  ### Reboot the machine.

  3) Check that the virtual functions are available:

  $ sudo lspci|grep -i eth | grep -i virtual | wc -l
  126

  4) Create a KVM guest

  $ sudo uvt-kvm create guest1 release=trusty

  5) List the VF devices :

  $ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed
  's/\:/\_/g' | sed 's/\./\_/g' > devices.txt

  6) Get the libvirt node device:

  $ sudo for device in $(cat ./devices.txt); do virsh nodedev-list |
  grep $device; done > pci_devices.txt

  7) Generate the XML config for each device:

  $ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh
  nodedev-dumpxml $d > devices/$d.xml; done

  8) Save and Run the following script
  (http://pastebin.ubuntu.com/23374186/)

  $ sudo python generate-interfaces.py |grep address | wc -l

  9) Finally attach the devices to the guest.

  $ sudo for i in $(seq 0 63); do virsh attach-device guest1 
./interfaces/$i.xml --config; done
  Device attached successfully
  [...]

  Device attached successfully
  Device attached successfully

  10) Then destroy/start the guest again, at this point the error is
  reproduced.

  $ sudo virsh destroy guest1
  Domain guest1 destroyed

  $ sudo virsh start guest1

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

   * detailed instructions how to reproduce the bug

   * these should allow someone who is not familiar with the affected
 package to reproduce the bug and verify that the updated package fixes
 the problem.

  [Regression Potential]

   ** None identified.

  [Other Info]

  - Redhat Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1040626

  [Workaround]

  The workaround is to install a newer library release, the 3.2.24-2:

  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

Hello,

After running a bisect between tags libnl3_2_21 and libnl3_2_22 I identified
the fixer commit to be 807fddc nl: Increase receive buffer size to 4 pages

commit 807fddc4cd9ecb12ba64e1b7fa26d86b6c2f19b0
Author: Thomas Graf 
Date:   Wed May 8 13:52:27 2013 +0200

nl: Increase receive buffer size to 4 pages

Assuming that the kernel does not send more than a page is no longer valid,
and enabling MSG_PEEK'ing by default to figure out the exact message buffer
requirements can have a negative influence on the performance of existing
applications. Bumping the default receive buffer space to 4 pages seems
a sane default.

Signed-off-by: Thomas Graf 

---

After applying this patch on top of the current trusty-updates this problem
is not longer exhibited and I can attach the full 128 VFs to the guest.

I am proposing this patch for SRU, and I already updated the description
with the reproduction steps.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578

Title:
   libnl should be updated to support up to 63 VFs per single PF

Status in libnl3 package in Ubuntu:
  Fix Released
Status in libnl3 source package in Precise:
  New
Status in libnl3 source package in Trusty:
  In Progress

Bug description:
  [Description]

  Ubuntu 14.04.4 and SRIOV settings.

  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on
  Ubuntu 14.04.4

  When trying to enable a guest with more than 30 VFs attached, the
  following error is returned:

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

  [Impact]

  The library release is the 3.2.21-1 the bug is impacting on the
  maximum VFs number that can be enabled (up to 30) even if the PF
  supports up to 63 VFs in an Openstack SRIOV configuration

  [Test Case]

  The sequence to reproduce this bug is:

  1) Edit /etc/default/grub

  GRUB_CMDLINE_LINUX="intel_iommu=on ixgbe.max_vfs=63"

  2) $ sudo update-grub

  ### Reboot the machine.

  3) Check that the virtual functions are available:

  $ sudo lspci|grep -i eth | grep -i virtual | wc -l
  126

  4) Create a KVM guest

  $ sudo uvt-kvm create guest1 release=trusty

  5) List the VF devices :

  $ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed
  's/\:/\_/g' | sed 's/\./\_/g' > devices.txt

  6) Get the libvirt node device:

  $ sudo for device in $(cat ./devices.txt); do virsh nodedev-list |
  grep $device; done > pci_devices.txt

  7) Generate the XML config for each device:

  $ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh
  nodedev-dumpxml $d > devices/$d.xml; done

  8) Save and Run the following script
  (http://pastebin.ubuntu.com/23374186/)

  $ sudo python generate-interfaces.py |grep address | wc -l

  9) Finally attach the devices to the guest.

  $ sudo for i in $(seq 0 63); do virsh attach-device guest1 
./interfaces/$i.xml --config; done
  Device attached successfully
  [...]

  Device attached successfully
  Device attached successfully

  10) Then destroy/start the guest again, at this point the error is
  reproduced.

  $ sudo virsh destroy guest1
  Domain guest1 destroyed

  $ sudo virsh start guest1

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

   * detailed instructions how to reproduce the bug

   * these should allow someone who is not familiar with the affected
 package to reproduce the bug and verify that the updated package fixes
 the problem.

  [Regression Potential]

   ** None identified.

  [Other Info]

  - Redhat Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1040626

  [Workaround]

  The workaround is to install a newer library release, the 3.2.24-2:

  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

Hello,

I am able to reproduce this bug consistently on a Trusty (3.19.0-73-generic) 
machine
equipped with 2 ixgbe 10GbE cards:

04:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit 
X540-AT2 (rev 01)
04:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit 
X540-AT2 (rev 01)

The sequence to reproduce this bug is:

1)  Edit /etc/default/grub

GRUB_CMDLINE_LINUX="intel_iommu=on ixgbe.max_vfs=63"

2) $ sudo update-grub

### Reboot the machine.

3) Check that  the virtual functions are available:

$ sudo lspci|grep -i eth | grep -i virtual | wc -l
126

4) Create a KVM guest

$ sudo uvt-kvm create guest1 release=trusty

5) List the VF devices :

$ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed
's/\:/\_/g' | sed 's/\./\_/g' > devices.txt

6) Get the libvirt node device:

$ sudo for device in $(cat ./devices.txt); do virsh nodedev-list | grep
$device; done  > pci_devices.txt

7) Generate the XML config for each device:

$ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh
nodedev-dumpxml $d > devices/$d.xml; done

8) Save and Run the following script
(http://pastebin.ubuntu.com/23374186/)

$ sudo python generate-interfaces.py |grep address | wc -l

9) Finally attach the devices to the guest.

$ sudo for i in $(seq 0 63); do virsh attach-device guest1 ./interfaces/$i.xml 
--config; done
Device attached successfully
[...]

Device attached successfully
Device attached successfully

10) Then destroy/start the guest again, at this point the error is
reproduced.

$ sudo virsh destroy guest1
Domain guest1 destroyed

$ sudo virsh start guest1

error: Failed to start domain guest1
error: internal error: missing IFLA_VF_INFO in netlink response

Please note that this error is not reproducible using libnl3_2_22. I am 
currently 
working to bisect and identify the offending commit and propose a backport to 
Ubuntu Trusty.



** Description changed:

+ [Description]
+ 
  Ubuntu 14.04.4 and SRIOV settings.
  
  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on Ubuntu
  14.04.4
  
- The library release is the 3.2.21-1 and the bug is impacting on the
- maximum VFs number that can be enabled (up to 30) even if the PF
- supports up to 63 VFs in an Openstack SRIOV configuration
+ When trying to enable a guest with more than 30 VFs attached, the
+ following error is returned:
+ 
+ error: Failed to start domain guest1
+ error: internal error: missing IFLA_VF_INFO in netlink response
+ 
+ [Impact]
+ 
+ The library release is the 3.2.21-1 the bug is impacting on the maximum
+ VFs number that can be enabled (up to 30) even if the PF supports up to
+ 63 VFs in an Openstack SRIOV configuration
+ 
+ [Test Case]
+ 
+ The sequence to reproduce this bug is:
+ 
+ 1) Edit /etc/default/grub
+ 
+ GRUB_CMDLINE_LINUX="intel_iommu=on ixgbe.max_vfs=63"
+ 
+ 2) $ sudo update-grub
+ 
+ ### Reboot the machine.
+ 
+ 3) Check that the virtual functions are available:
+ 
+ $ sudo lspci|grep -i eth | grep -i virtual | wc -l
+ 126
+ 
+ 4) Create a KVM guest
+ 
+ $ sudo uvt-kvm create guest1 release=trusty
+ 
+ 5) List the VF devices :
+ 
+ $ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed
+ 's/\:/\_/g' | sed 's/\./\_/g' > devices.txt
+ 
+ 6) Get the libvirt node device:
+ 
+ $ sudo for device in $(cat ./devices.txt); do virsh nodedev-list | grep
+ $device; done > pci_devices.txt
+ 
+ 7) Generate the XML config for each device:
+ 
+ $ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh
+ nodedev-dumpxml $d > devices/$d.xml; done
+ 
+ 8) Save and Run the following script
+ (http://pastebin.ubuntu.com/23374186/)
+ 
+ $ sudo python generate-interfaces.py |grep address | wc -l
+ 
+ 9) Finally attach the devices to the guest.
+ 
+ $ sudo for i in $(seq 0 63); do virsh attach-device guest1 
./interfaces/$i.xml --config; done
+ Device attached successfully
+ [...]
+ 
+ Device attached successfully
+ Device attached successfully
+ 
+ 10) Then destroy/start the guest again, at this point the error is
+ reproduced.
+ 
+ $ sudo virsh destroy guest1
+ Domain guest1 destroyed
+ 
+ $ sudo virsh start guest1
+ 
+ error: Failed to start domain guest1
+ error: internal error: missing IFLA_VF_INFO in netlink response
+ 
+  * detailed instructions how to reproduce the bug
+ 
+  * these should allow someone who is not familiar with the affected
+package to reproduce the bug and verify that the updated package fixes
+the problem.
+ 
+ [Regression Potential]
+ 
+  ** None identified.
+ 
+ [Other Info]
+ 
+ - Redhat Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1040626
+ 
+ [Workaround]
  
  The workaround is to install a newer library release, the 3.2.24-2:
  
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  wget 

[Desktop-packages] [Bug 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

** Changed in: libnl3 (Ubuntu Trusty)
   Status: New => In Progress

** Changed in: libnl3 (Ubuntu Trusty)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578

Title:
   libnl should be updated to support up to 63 VFs per single PF

Status in libnl3 package in Ubuntu:
  Fix Released
Status in libnl3 source package in Precise:
  New
Status in libnl3 source package in Trusty:
  In Progress

Bug description:
  Ubuntu 14.04.4 and SRIOV settings.

  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on
  Ubuntu 14.04.4

  The library release is the 3.2.21-1 and the bug is impacting on the
  maximum VFs number that can be enabled (up to 30) even if the PF
  supports up to 63 VFs in an Openstack SRIOV configuration

  The workaround is to install a newer library release, the 3.2.24-2:

  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

** Changed in: libnl3 (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: libnl3 (Ubuntu)
 Assignee: Jorge Niedbalski (niedbalski) => (unassigned)

** Changed in: libnl3 (Ubuntu Trusty)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

** Changed in: libnl3 (Ubuntu Precise)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578

Title:
   libnl should be updated to support up to 63 VFs per single PF

Status in libnl3 package in Ubuntu:
  Fix Released
Status in libnl3 source package in Precise:
  New
Status in libnl3 source package in Trusty:
  New

Bug description:
  Ubuntu 14.04.4 and SRIOV settings.

  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on
  Ubuntu 14.04.4

  The library release is the 3.2.21-1 and the bug is impacting on the
  maximum VFs number that can be enabled (up to 30) even if the PF
  supports up to 63 VFs in an Openstack SRIOV configuration

  The workaround is to install a newer library release, the 3.2.24-2:

  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

** Changed in: libnl3 (Ubuntu)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

** Changed in: libnl3 (Ubuntu)
   Importance: Low => Medium

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578

Title:
   libnl should be updated to support up to 63 VFs per single PF

Status in libnl3 package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 14.04.4 and SRIOV settings.

  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on
  Ubuntu 14.04.4

  The library release is the 3.2.21-1 and the bug is impacting on the
  maximum VFs number that can be enabled (up to 30) even if the PF
  supports up to 63 VFs in an Openstack SRIOV configuration

  The workaround is to install a newer library release, the 3.2.24-2:

  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1244578] Re: lightdm-session runs xrdb with -nocpp option

[Jorge Niedbalski]

** Changed in: lightdm (Ubuntu Trusty)
   Status: New = In Progress

** Changed in: lightdm (Ubuntu Utopic)
   Status: New = In Progress

** Changed in: lightdm (Ubuntu Vivid)
   Status: New = In Progress

** Changed in: lightdm (Ubuntu Trusty)
 Assignee: (unassigned) = Jorge Niedbalski (niedbalski)

** Changed in: lightdm (Ubuntu Utopic)
 Assignee: (unassigned) = Jorge Niedbalski (niedbalski)

** Changed in: lightdm (Ubuntu Vivid)
 Assignee: (unassigned) = Jorge Niedbalski (niedbalski)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1244578

Title:
  lightdm-session runs xrdb with -nocpp option

Status in lightdm package in Ubuntu:
  Confirmed
Status in lightdm source package in Trusty:
  In Progress
Status in lightdm source package in Utopic:
  In Progress
Status in lightdm source package in Vivid:
  In Progress

Bug description:
  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet

  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213

  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1244578] Re: lightdm-session runs xrdb with -nocpp option

[Jorge Niedbalski]

** Patch added: Utopic Patch
   
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+attachment/4415159/+files/fix-lp-1244578-utopic.patch

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1244578

Title:
  lightdm-session runs xrdb with -nocpp option

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Trusty:
  In Progress
Status in lightdm source package in Utopic:
  In Progress
Status in lightdm source package in Vivid:
  In Progress

Bug description:
  [Impact]

  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet

  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213

  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)

  [Test Case]

   - Install solarized theme
  https://github.com/solarized/xresources/blob/master/solarized

  - Load default Xresources file (xrdb  .XDefaults )

  - Now every macro supported by CPP will not work.

  
  [Regression Potential] 

  * No regression potential advised, small (0.001%) load average increase
  on startup time because of enabling Cpp.

  [Solution]

  Backport default wily session to older releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1244578] Re: lightdm-session runs xrdb with -nocpp option

[Jorge Niedbalski]

** Patch removed: Vivid Patch
   
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+attachment/4415158/+files/fix-lp-1244578-vivid.patch

** Patch added: Vivid Patch
   
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+attachment/4415185/+files/fix-lp-1244578-vivid.patch

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1244578

Title:
  lightdm-session runs xrdb with -nocpp option

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Trusty:
  In Progress
Status in lightdm source package in Utopic:
  In Progress
Status in lightdm source package in Vivid:
  In Progress

Bug description:
  [Impact]

  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet

  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213

  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)

  [Test Case]

   - Install solarized theme
  https://github.com/solarized/xresources/blob/master/solarized

  - Load default Xresources file (xrdb  .XDefaults )

  - Now every macro supported by CPP will not work.

  
  [Regression Potential] 

  * No regression potential advised, small (0.001%) load average increase
  on startup time because of enabling Cpp.

  [Solution]

  Backport default wily session to older releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1244578] Re: lightdm-session runs xrdb with -nocpp option

[Jorge Niedbalski]

** Patch added: Trusty Patch
   
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+attachment/4415160/+files/fix-lp-1244578-trusty.patch

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1244578

Title:
  lightdm-session runs xrdb with -nocpp option

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Trusty:
  In Progress
Status in lightdm source package in Utopic:
  In Progress
Status in lightdm source package in Vivid:
  In Progress

Bug description:
  [Impact]

  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet

  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213

  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)

  [Test Case]

   - Install solarized theme
  https://github.com/solarized/xresources/blob/master/solarized

  - Load default Xresources file (xrdb  .XDefaults )

  - Now every macro supported by CPP will not work.

  
  [Regression Potential] 

  * No regression potential advised, small (0.001%) load average increase
  on startup time because of enabling Cpp.

  [Solution]

  Backport default wily session to older releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1244578] Re: lightdm-session runs xrdb with -nocpp option

[Jorge Niedbalski]

This is fixed on Wily, I am attaching the Vivid, Utopic and Trusty
patches.

** Description changed:

+ [Impact]
+ 
  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet
  
  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213
  
  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)
+ 
+ [Test Case]
+ 
+  - Install solarized theme
+ https://github.com/solarized/xresources/blob/master/solarized
+ 
+ - Load default Xresources file (xrdb  .XDefaults )
+ 
+ - Now every macro supported by CPP will not work.
+ 
+ 
+ [Regression Potential] 
+ 
+ * No regression potential advised, small (0.001%) load average increase
+ on startup time because of enabling Cpp.
+ 
+ [Solution]
+ 
+ Backport default wily session to older releases.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1244578

Title:
  lightdm-session runs xrdb with -nocpp option

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Trusty:
  In Progress
Status in lightdm source package in Utopic:
  In Progress
Status in lightdm source package in Vivid:
  In Progress

Bug description:
  [Impact]

  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet

  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213

  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)

  [Test Case]

   - Install solarized theme
  https://github.com/solarized/xresources/blob/master/solarized

  - Load default Xresources file (xrdb  .XDefaults )

  - Now every macro supported by CPP will not work.

  
  [Regression Potential] 

  * No regression potential advised, small (0.001%) load average increase
  on startup time because of enabling Cpp.

  [Solution]

  Backport default wily session to older releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1244578] Re: lightdm-session runs xrdb with -nocpp option

[Jorge Niedbalski]

** Patch added: Vivid Patch
   
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+attachment/4415158/+files/fix-lp-1244578-vivid.patch

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1244578

Title:
  lightdm-session runs xrdb with -nocpp option

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Trusty:
  In Progress
Status in lightdm source package in Utopic:
  In Progress
Status in lightdm source package in Vivid:
  In Progress

Bug description:
  [Impact]

  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet

  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213

  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)

  [Test Case]

   - Install solarized theme
  https://github.com/solarized/xresources/blob/master/solarized

  - Load default Xresources file (xrdb  .XDefaults )

  - Now every macro supported by CPP will not work.

  
  [Regression Potential] 

  * No regression potential advised, small (0.001%) load average increase
  on startup time because of enabling Cpp.

  [Solution]

  Backport default wily session to older releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1244578] Re: lightdm-session runs xrdb with -nocpp option

[Jorge Niedbalski]

** Patch added: Precise Patch
   
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+attachment/4415201/+files/fix-lp-1244578-precise.patch

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1244578

Title:
  lightdm-session runs xrdb with -nocpp option

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Trusty:
  In Progress
Status in lightdm source package in Utopic:
  In Progress
Status in lightdm source package in Vivid:
  In Progress

Bug description:
  [Impact]

  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet

  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213

  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)

  [Test Case]

   - Install solarized theme
  https://github.com/solarized/xresources/blob/master/solarized

  - Load default Xresources file (xrdb  .XDefaults )

  - Now every macro supported by CPP will not work.

  
  [Regression Potential] 

  * No regression potential advised, small (0.001%) load average increase
  on startup time because of enabling Cpp.

  [Solution]

  Backport default wily session to older releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1171878] Re: Adding/Removing an external monitor causes maximized windows to move to another workspace

[Jorge Niedbalski]

** Tags added: cts

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/1171878

Title:
  Adding/Removing an external monitor causes maximized windows to move
  to another workspace

Status in Compiz:
  Fix Committed
Status in Compiz Core:
  Fix Committed
Status in “compiz” package in Ubuntu:
  Fix Released
Status in “compiz” source package in Precise:
  Fix Released

Bug description:
  [Impact]

  If I plug in external monitor, move a window to it, maximize window and 
remove external monitor, window is moved to the same workspace primary screen - 
this is correct behavior, but when I un-maximize it - window moves to different 
workspace. This most likely is because original window positions are not 
updated after removing the monitor and un-maximize still uses those old values 
to move the window to supposedly original position.
  Another use case is when window movement is somewhat wrong - external monitor 
plugged in, window is maximized on primary screen, move focus to different 
workspace, unplug the monitor, move back to the workspace when we have 
fullscreen window, unmaximize it - window un-maximizes not to original 
position, it's moved away by the same mount of pixels as external monitor width 
is.

  I expect that window stays on the same workspace - once it's on it it
  should not move unless I do that manually, also I expect that un-
  maximizing moves window to original position, not different.

  This is continuation of bug
  https://bugs.launchpad.net/compiz/+bug/763148, fullscreen window bug
  was separated as per Christopher Townsend (townsend) wrote on
  2013-04-18.

  P.S. Most likely bug can be fixed quite easy as behavior is similar to
  bug I mentioned, hopefully this can be included in the same SRU.

  thanks in advance
  Eduards

  [Test Case]

  ** Test Case 1

  1. plug in external monitor and move a windows to it
  2. maximize window
  3. unplug external monitor
  4. window moves to the primary display of the same workspace (this is correct)
  5. un-maximize window
  6. window un-maximizes to a different workspace (this is incorrect)

  ** Test Case 2

  1. plug in external monitor
  2. maximize window on primary (laptop display)
  3. change to a different workspace
  4. unplug external monitor
  5. return to workspace with maximized window
  6. un-maximize window
  7. window un-maximizes to wrong position. instead of the original position it 
is shifted over by the same number of pixels as the width of the external 
monitor (also incorrect)

  [Other information]

  The bug fix also address bug LP: #763148 on precise.

  [Regression]

  None determined  expected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/compiz/+bug/1171878/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1171878] Re: Adding/Removing an external monitor causes maximized windows to move to another workspace

[Jorge Niedbalski]

** Description changed:

  If I plug in external monitor, move a window to it, maximize window and 
remove external monitor, window is moved to the same workspace primary screen - 
this is correct behavior, but when I un-maximize it - window moves to different 
workspace. This most likely is because original window positions are not 
updated after removing the monitor and un-maximize still uses those old values 
to move the window to supposedly original position.
  Another use case is when window movement is somewhat wrong - external monitor 
plugged in, window is maximized on primary screen, move focus to different 
workspace, unplug the monitor, move back to the workspace when we have 
fullscreen window, unmaximize it - window un-maximizes not to original 
position, it's moved away by the same mount of pixels as external monitor width 
is.
  
  I expect that window stays on the same workspace - once it's on it it
  should not move unless I do that manually, also I expect that un-
  maximizing moves window to original position, not different.
  
  This is continuation of bug
  https://bugs.launchpad.net/compiz/+bug/763148, fullscreen window bug was
  separated as per Christopher Townsend (townsend) wrote on 2013-04-18.
  
  P.S. Most likely bug can be fixed quite easy as behavior is similar to
  bug I mentioned, hopefully this can be included in the same SRU.
  
  thanks in advance
  Eduards
+ 
+ [Test Case]
+ 
+ ** Test Case 1
+ 
+ 1. plug in external monitor and move a windows to it
+ 2. maximize window
+ 3. unplug external monitor
+ 4. window moves to the primary display of the same workspace (this is correct)
+ 5. un-maximize window
+ 6. window un-maximizes to a different workspace (this is incorrect)
+ 
+ ** Test Case 2
+ 
+ 1. plug in external monitor
+ 2. maximize window on primary (laptop display)
+ 3. change to a different workspace
+ 4. unplug external monitor
+ 5. return to workspace with maximized window
+ 6. un-maximize window
+ 7. window un-maximizes to wrong position. instead of the original position it 
is shifted over by the same number of pixels as the width of the external 
monitor (also incorrect)
+ 
+ [Other information]
+ 
+ The bug fix also address bug LP: #763148 on precise.
+ 
+ [Regression]
+ 
+ None determined  expected.

** Description changed:

+ [Impact]
+ 
  If I plug in external monitor, move a window to it, maximize window and 
remove external monitor, window is moved to the same workspace primary screen - 
this is correct behavior, but when I un-maximize it - window moves to different 
workspace. This most likely is because original window positions are not 
updated after removing the monitor and un-maximize still uses those old values 
to move the window to supposedly original position.
  Another use case is when window movement is somewhat wrong - external monitor 
plugged in, window is maximized on primary screen, move focus to different 
workspace, unplug the monitor, move back to the workspace when we have 
fullscreen window, unmaximize it - window un-maximizes not to original 
position, it's moved away by the same mount of pixels as external monitor width 
is.
  
  I expect that window stays on the same workspace - once it's on it it
  should not move unless I do that manually, also I expect that un-
  maximizing moves window to original position, not different.
  
  This is continuation of bug
  https://bugs.launchpad.net/compiz/+bug/763148, fullscreen window bug was
  separated as per Christopher Townsend (townsend) wrote on 2013-04-18.
  
  P.S. Most likely bug can be fixed quite easy as behavior is similar to
  bug I mentioned, hopefully this can be included in the same SRU.
  
  thanks in advance
  Eduards
  
  [Test Case]
  
  ** Test Case 1
  
  1. plug in external monitor and move a windows to it
  2. maximize window
  3. unplug external monitor
  4. window moves to the primary display of the same workspace (this is correct)
  5. un-maximize window
  6. window un-maximizes to a different workspace (this is incorrect)
  
  ** Test Case 2
  
  1. plug in external monitor
  2. maximize window on primary (laptop display)
  3. change to a different workspace
  4. unplug external monitor
  5. return to workspace with maximized window
  6. un-maximize window
  7. window un-maximizes to wrong position. instead of the original position it 
is shifted over by the same number of pixels as the width of the external 
monitor (also incorrect)
  
  [Other information]
  
  The bug fix also address bug LP: #763148 on precise.
  
  [Regression]
  
  None determined  expected.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/1171878

Title:
  Adding/Removing an external monitor causes maximized windows to move
  to another workspace

Status in Compiz:
  Fix Committed
Status in “compiz” package in Ubuntu:
  Fix Released
Status in “compiz” source package in Precise:
  

[Desktop-packages] [Bug 1171878] Re: Adding/Removing an external monitor causes maximized windows to move to another workspace

[Jorge Niedbalski]

@khadgaray patches appears to fix this behavior on precise.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/1171878

Title:
  Adding/Removing an external monitor causes maximized windows to move
  to another workspace

Status in Compiz:
  Fix Committed
Status in “compiz” package in Ubuntu:
  Fix Released

Bug description:
  If I plug in external monitor, move a window to it, maximize window and 
remove external monitor, window is moved to the same workspace primary screen - 
this is correct behavior, but when I un-maximize it - window moves to different 
workspace. This most likely is because original window positions are not 
updated after removing the monitor and un-maximize still uses those old values 
to move the window to supposedly original position.
  Another use case is when window movement is somewhat wrong - external monitor 
plugged in, window is maximized on primary screen, move focus to different 
workspace, unplug the monitor, move back to the workspace when we have 
fullscreen window, unmaximize it - window un-maximizes not to original 
position, it's moved away by the same mount of pixels as external monitor width 
is.

  I expect that window stays on the same workspace - once it's on it it
  should not move unless I do that manually, also I expect that un-
  maximizing moves window to original position, not different.

  This is continuation of bug
  https://bugs.launchpad.net/compiz/+bug/763148, fullscreen window bug
  was separated as per Christopher Townsend (townsend) wrote on
  2013-04-18.

  P.S. Most likely bug can be fixed quite easy as behavior is similar to
  bug I mentioned, hopefully this can be included in the same SRU.

  thanks in advance
  Eduards

To manage notifications about this bug go to:
https://bugs.launchpad.net/compiz/+bug/1171878/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp