[Bug 1688056] Re: Package outdated
Confirming that 0.8.9-0ubuntu0.16.04.1 works for me on xenial. Thank you! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1688056 Title: Package outdated To manage notifications about this bug go to: https://bugs.launchpad.net/xfce4-weather-plugin/+bug/1688056/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1692270] [NEW] Unable to download weather data (URL changed)
Public bug reported: The 0.8.6 xfce4-weather-plugin included in Xubuntu 16.04 (and the 0.8.5 version in Linux Mint) expect to retrieve weather data from a server using a weather API v 1.2. The servers used for download have sunset the 1.2 API and now require 1.3. This causes the download to fail with an HTTP 404 and the app to display some variant of "Currently no data available". Specific failure data: weather-Message: getting http://api.yr.no/weatherapi/locationforecastlts/1.2/?lat=[...] (wrapper-1.0:16241): weather-WARNING **: Download of astronomical data failed with HTTP Status Code 404, Reason phrase: Not Found Note the "1.2" in the URL; swapping in "1.3" successfully retrieves data. It looks like the problem would probably be fixed by applying the following commit from Feb 2017, just prior to the release of xfce- weather-plugin 0.8.9. At least one user has reported that 0.8.9 continues to work. https://git.xfce.org/panel-plugins/xfce4-weather- plugin/commit/?id=e3f53da02a6c4918c0436a8a459f81f1c9eac131 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: xfce4-weather-plugin 0.8.6-1 ProcVersionSignature: Ubuntu 4.4.0-77.98-generic 4.4.59 Uname: Linux 4.4.0-77-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: XFCE Date: Sat May 20 18:44:15 2017 InstallationDate: Installed on 2015-02-28 (812 days ago) InstallationMedia: Xubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1) SourcePackage: xfce4-weather-plugin UpgradeStatus: Upgraded to xenial on 2016-07-03 (321 days ago) ** Affects: xfce4-weather-plugin (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1692270 Title: Unable to download weather data (URL changed) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xfce4-weather-plugin/+bug/1692270/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1297849] Re: VPN Connection fails after last upgrade on 14.04
Also seeing this on Xubuntu 14.04, upgraded from 13.10. Restart doesn't fix it. I don't have a keyrings file or directory in ~/.local/share/. If I right click on nm-applet, then Edit Connections, then select a VPN and click Edit, a small edit panel comes up but remains blank/greyed-out for about a minute or so. Then after about a minute, the edit panel is replaced by larger panel with all the data populated and controls enabled. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1297849 Title: VPN Connection fails after last upgrade on 14.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-openconnect/+bug/1297849/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 742257] Re: Natty Narwhal 64-bit for Mac: macbook pro runs very hot - no fans can be heard
Chris or Mike, I was considering installing 12.04 on my MBP 6,2 and was reading through the issues and ended up here. Was just curious where this has ended up since there have been no updates for a month. If there is additional help needed for testing I might be able to contribute if that's where its at... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/742257 Title: Natty Narwhal 64-bit for Mac: macbook pro runs very hot - no fans can be heard To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/742257/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 498911] Re: nspluginwrapper fills .xsession-errors until disk space is exhausted
Seen also on Ubuntu 10.10: flashplugin-nonfree10.2.152.27ubuntu0.10.10.1 firefox 3.6.13+build3+nobinonly-0ubuntu0.10.10.1 nspluginwrapper1.2.2-0ubuntu7 *** NSPlugin Viewer *** WARNING:(/build/buildd/nspluginwrapper-1.2.2/src/npw- viewer.c:1017):invoke_NPN_InvalidateRect: assertion failed: (rpc_method_invoke_possible(g_rpc_connection)) The error message are being produced at a rate of about 60 per second on my machine. -- You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. https://bugs.launchpad.net/bugs/498911 Title: nspluginwrapper fills .xsession-errors until disk space is exhausted -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 132089] Re: sub_info dereferenced after free in finish_usermodehelper_pipe
I looked at kmod.c in jaunty's linux-source-2.6.28 package. The code of interest has been re-written. The corresponding code seems to be in call_usermodehelper_exec() now. That new routine correctly saves off the return value before freeing the sub_info structure. So I believe this bug does NOT affect jaunty and can be closed/removed/whatever. brian -- sub_info dereferenced after free in finish_usermodehelper_pipe https://bugs.launchpad.net/bugs/132089 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 210819] Re: ide-scsi: cdrom tray always reported open
On Tue, 2008-09-09 at 05:21 +, Leann Ogasawara wrote: > Thanks for testing and the update Brian. Yes, if you could open new bug > reports for the other issues you are seeing that would be great. I'm > going to go ahead and mark this bug "Fix Released" for Intrepid. Thank you for your help, Leann. I've opened bug 271202 to describe the interaction between hal and other apps. I'll watch that one to see what those folks say. Regards, brian -- ide-scsi: cdrom tray always reported open https://bugs.launchpad.net/bugs/210819 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 271202] [NEW] Intrepid alpha: cd interaction between hal, grip, and eject
Public bug reported: Binary package hint: hal With the latest Intrepid (alpha 5 + updates as of Sep 17), I found an unfortunate interaction with 'hal' versus 'grip' and 'eject'. As background: - 'grip' tries only ioctl(CDROMEJECT) to eject the tray - 'eject' tries ioctl(CDROMEJECT) to eject the tray and escalates to issuing SCSI commands via ioctl(SG_IO) if CDROMEJECT fails I'm seeing: - grip can close the tray from an open state 100% reliably - if no CD has been inserted (empty tray), then grip and eject can open the tray 100% reliably using CDROMEJECT - once an audio CD has been "mounted" by 'hal' (i.e. appears on the desktop), then ioctl(CDROMEJECT) begins to fail (EIO) leaving grip unable to eject the CD - while the CD remains mounted by hal and with grip running, eject also cannot eject the CD via CDROMEJECT (EIO); when eject escalates to SG_IO, the tray ejects then immediately closes again, and the volume is remounted - when the manually unmounting the CD while grip is running (right click 'Audio CD' on the Desktop, then Unmount volume), the tray ejects then immediatly closes again, and the volume is remounted - hal will "mount" an audio CD (scan it and place an icon on the desktop upon volume detection) even if the action for Audio CD has been set to "Do nothing" in Nautilus (or if 'Do nothing' and and the 'always perform this action' is chosen when a new user loads a CD for the first time) - if hal is shut down (kill hald-addon-storage and gvfs-hal-volume-monitor) then grip restarted, grip will be able to open and close the tray 100% reliably, regardless of whether a CD is in the drive Basically, I think I want a convenient way to tell hal to ignore the cd/dvd drive entirely so that I can run arbitrary applications without unwanted interactions. ** Affects: hal (Ubuntu) Importance: Undecided Status: New -- Intrepid alpha: cd interaction between hal, grip, and eject https://bugs.launchpad.net/bugs/271202 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 267228] Re: Intrepid Alpha 5: AHCI boot regression (fixed in 2.6.27-rc5-git7)
Hi, Leann, I just wanted to report that this boot problem no longer occurs on my machine since applying the new kernel package: linux-image-2.6.27-3-generic -- Intrepid Alpha 5: AHCI boot regression (fixed in 2.6.27-rc5-git7) https://bugs.launchpad.net/bugs/267228 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 267228] [NEW] Intrepid Alpha 5: AHCI boot regression (fixed in 2.6.27-rc5-git7)
Public bug reported: Binary package hint: linux-image-2.6.27-2-generic Intrepid alpha 5's 2.6.27-2 kernel fails to boot on my machine (Gigabyte GA-MA78G-DS3H mb, AMD 64 X2 5600+ CPU, w/ 2x SATA drives). Alpha 4's 2.6.26-5 kernel booted just fine. The boot fails due to an AHCI startup failure. dmesg includes: ahci :00:11.0: version 3.0 ahci :00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 ahci :00:11.0: implemented port map (0x) contains more ports than nr_ports (1), using nr_ports ahci :00:11.0: forcing PORTS_IMPL to 0x1 ahci :00:11.0: controller reset failed (0x8001) ahci :00:11.0: PCI INT A disabled ahci: probe of :00:11.0 failed with error -5 This appears similar to the problem described in the recent kernel mailing list subthread "Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd" (Rafael J. Wysocki", Message-ID: <[EMAIL PROTECTED]>). I built a 2.6.27-rc5-git7 kernel and it boots OK. (I'm running it now.) ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- Intrepid Alpha 5: AHCI boot regression (fixed in 2.6.27-rc5-git7) https://bugs.launchpad.net/bugs/267228 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 210819] Re: ide-scsi: cdrom tray always reported open
Howdy, Leann, I upgraded my test partition to the 2.6.27-2 generic linux image. The results were as on 08/08/08--he initially reported defect involving the CDROM_DRIVE_STATUS ioctl() is fixed. The new problem of the hal volume manager interfering with 'grip' and 'eject' still exists. But perhaps that should be a different bug report against those components, rather than the kernel? -- ide-scsi: cdrom tray always reported open https://bugs.launchpad.net/bugs/210819 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 210819] Re: ide-scsi: cdrom tray always reported open
Hello, Leann, I was able to test Intrepid alpha-3 this afternoon (actually, I tested with Intrepid as of 08/08/2008--dist-upgrade brought me to kernel 2.6.26-5). The original problem of the CD tray status being misreported has been corrected. However, some application-level symptoms described above remain. Some background: - 'grip' tries only ioctl(CDROMEJECT) to eject the tray - 'eject' tries ioctl(CDROMEJECT) to eject the tray and escalates to issuing SCSI commands via ioctl(SG_IO) if CDROMEJECT fails With the latest Intrepid, I found an unfortunate interaction with 'hal' versus 'grip' and 'eject' - grip can close the tray from an open state 100% reliably - if no CD has been inserted (empty tray), then grip and eject can open the tray 100% reliably using CDROMEJECT - once an audio CD has been "mounted" by 'hal', then ioctl(CDROMEJECT) begins to fail (EIO) leaving grip unable to eject the CD - while the CD remains mounted by hal, eject also cannot eject the CD either via CDROMEJECT (EIO) nor via SG_IO - after the CD has been manually unmounted (right click, then Unmount volume), CDROMEJECT still fails, but eject can now open the tray via SG_IO - CDROMEJECT can be made to work again by closing and re-opening grip. (grip holds the cd device in an open state the entire time it's running. hal's mounting of the CD apparently sets some state in the driver that's not cleared until all applications close the device.) - hal will "mount" an audio CD (scan it and place an icon on the desktop upon volume detection) even if the action for Audio CD has been set to "Do nothing" in Nautilus - if hal is shut down then grip restarted, grip will be able to open and close the tray 100% reliably, regardless of whether a CD is in the drive -- ide-scsi: cdrom tray always reported open https://bugs.launchpad.net/bugs/210819 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 210819] Re: ide-scsi: cdrom tray always reported open
I checked out https://edge.launchpad.net/~kernel-ppa/+archive but was unable to find the kernel packages. It looks like the last update was in late May and the builds then failed. I tried adding the sources and updating, but no joy. -- ide-scsi: cdrom tray always reported open https://bugs.launchpad.net/bugs/210819 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 210819] Re: ide-scsi: cdrom tray always reported open
I'd be happy to test the new patch. Would someone be able to build an installable package like Leann made available last time? I'd be testing on a machine running Hardy. -- ide-scsi: cdrom tray always reported open https://bugs.launchpad.net/bugs/210819 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 210819] Re: ide-scsi: cdrom tray always reported open
Hello Leann, I tested this just now. I modified my apt sources as you suggested and installed the generic kernel: $ sudo aptitude install linux-image-2.6.25-1-generic I noticed several unrelated issues when I rebooted. Let me know if you'd like me to report any of them formally; some may be fallout of using an early kernel build: 1. There were some artifacts while the graphical boot "slider bar" was displaying 2. My VGs were not automatically activated; I had to activate them manually in busybox (vgscan ; vgchange -a y ) 3. It appeared that the busybox startup was not clean--there were several error messages before the busybox prompt that suggested busybox was trying to execute the output of a failed command. I didn't write them down, but the messages were roughly of the form: "The command was not found", where s were a similar series "The", "command", etc. 4. X fell back to a low resolution mode; I guess this is expected since I'm using the Nvidia restricted driver and didn't install a driver package in concert with the kernel 5. My normal desktop display has, on the top panel, in this order: the Ubuntu logo, "Applications", "Places", "System", Firefox icon, Evolution/Mail icon, Help icon, Terminal icon, etc. In low resolution mode, the panel display showed the Ubuntu logo, and the Applications, Places, and System menu headers normally, but due to space limitations on the panel, some of the icons were obscured under those menu headers. The Firefox and Mail icons were completely obscured and only the right half of the Help icon was displayed to the right of "System". Clicking on the fully-visible "System" menu header, though, opened Evolution, rather than the system menu. That is, the menu headers were visible, but the obscured icons were active. I had to click on the Applications menu header and use the arrow keys to navigate to the System menu. About the patch itself, I had mixed results... With no CD in the drive, Grip would open or close the CD tray when clicking Grip's Eject button with 100% success. Even if the tray was closed and empty when Grip started. That's an improvement from the old behavior. When a CD was inserted and the tray was closed, Grip would no longer open the tray when its Eject button was pressed. That's a regression from the old behavior. Grip would show "No disc" momentarily, then would reload/display the disk information. I have Nautilus set to "Do Nothing" for CD Audio. Still an "Audio CD" icon will appear on my desktop when a CD is inserted. Bringing up the Properties of the Audio CD icon and selecting Eject would usually, but not always, successfully eject the audio disc. Even if that Eject failed, the Audio CD icon would disappear and Grip would still be unable to eject the disc; it would be necessary to eject the disc manually using the physical button on the drive. After that, Grip would be unable to manipulate the tray at all (via Grip's Eject button) until Grip was restarted. The following messages would appear /var/log/messages when attempting to eject via the Audio CD Properties: 16:50:42 aether kernel: [ 253.489088] cdb 1b 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 16:50:42 aether kernel: [ 253.489091] res 40/00:03:00:00:00/00:00:00:00:00/b0 Emask 0x4 (timeout) 16:50:42 aether kernel: [ 254.105009] ata2: soft resetting link 16:50:42 aether kernel: [ 254.285438] ata2.00: configured for UDMA/100 16:50:42 aether kernel: [ 254.301362] ata2.01: configured for UDMA/33 16:50:42 aether kernel: [ 254.301405] ata2: EH complete 16:50:42 aether kernel: [ 254.318452] sd 1:0:0:0: [sdc] 156301488 512-byte hardware sectors (80026 MB) 16:50:42 aether kernel: [ 254.319431] sd 1:0:0:0: [sdc] Write Protect is off 16:50:42 aether kernel: [ 254.322380] sd 1:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA 16:50:42 aether kernel: [ 254.325098] sd 1:0:0:0: [sdc] 156301488 512-byte hardware sectors (80026 MB) 16:50:42 aether kernel: [ 254.326146] sd 1:0:0:0: [sdc] Write Protect is off 16:50:42 aether kernel: [ 254.327999] sd 1:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA This looks to me like an OPEN/CLOSE ELEMENT command met with a CHECK condition of some sort. I don't know which driver logged the 'res' line, so I can't decode the SK/ASC/ASCQ. After the messages above, I would see the following when Grip was shut down (and sometimes earlier): 16:57:03 aether kernel: [ 635.341268] sr0: CDROM not ready. Make sure there is a disc in the drive. Overall, the patch fixes the problem of Grip being unable to open the tray initially, but at the cost of being unable to open the tray when a CD is loaded and sometimes having to use the physical eject button and reload Grip. The overall behavior with the patch is worse than without. Please let me know if you need more data or need further testing. -- ide-scsi: cdrom tray always reporte
[Bug 210819] Re: ide-scsi: cdrom tray always reported open
I'm seeing this same problem. I have a NEC 3540A attached as the slave device on my second IDE channel: Apr 20 18:52:24 kernel: ata2.01: ATAPI: _NEC DVD_RW ND-3540A, 1.01, max UDMA/33 Apr 20 18:52:24 kernel: ata2.01: configured for UDMA/33 Apr 20 18:52:24 kernel: scsi 1:0:1:0: CD-ROM_NEC DVD_RW ND-3540A 1.01 PQ: 0 ANSI: 5 Apr 20 18:52:24 kernel: sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray Apr 20 18:52:24 kernel: Uniform CD-ROM driver Revision: 3.20 Apr 20 18:52:24 kernel: sr 1:0:1:0: Attached scsi generic sg3 type 5 Apparently, the drive was managed by the IDE driver under gutsy but now is managed by the SCSI driver since upgrading to hardy. I noticed this when using grip. It's my habit to start grip then click on the Eject icon to open the CD tray. That no longer works, so I have to open the tray manually. grip's Eject button works if there is a CD in the drive, but not if the drive is empty and tray closed. The code in grip that trips on this is in TrayOpen() in cddev.h in this failing case called from EjectDisc() in cdplay.c. It's not a dire problem by any means, but it is a regression that grip users might see. I just wanted to make you aware of that. -- ide-scsi: cdrom tray always reported open https://bugs.launchpad.net/bugs/210819 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 46015] Re: Sbackup should exclude browser cache files by default?
Oumar, Thank you for you quick response. My apologies--I had installed sbackup when I was running feisty but didn't notice the problem until after I upgraded to gutsy. You are of course correct that problem is fixed in gutsy. I must have brought the feisty config file forward when I upgraded. I'll check the source package next time before reporting a problem. Regards, brian -- Sbackup should exclude browser cache files by default? https://bugs.launchpad.net/bugs/46015 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 46015] Re: Sbackup should exclude browser cache files by default?
This bug is marked as Fix Released and noted as fixed upstream, but the
problem persists in sbackup svn on sourceforge (and so in gutsy and
hardy). The latest revision (79) of /trunk/data/sbackup.conf.example
contains:
regex=\.mp3,\.avi,\.mpeg,\.mpg,\.mkv,\.ogg,\.ogm,\.tmp,/home/[^/]+?/\.thumbnails/,/home/[^/]+?/\.Trash,/home/.mozilla/.+/Cache/
The expression "/home/.mozilla/.+/Cache/" doesn't actually match any
particular user's browser cache and doesn't effectively exclude
anything. The regex listed above ("/home/[^/]+?/\..+/[cC]ache") seems
like a good candidate for a fix. Or, perhaps, to exclude only browser
cache:
/home/[^/]+?/\.mozilla/.+/Cache
I've tested the latter here. It works as expected.
--
Sbackup should exclude browser cache files by default?
https://bugs.launchpad.net/bugs/46015
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 132089] Re: sub_info dereferenced after free in finish_usermodehelper_pipe
On Mon, 2007-08-27 at 21:03 +, Brian Murray wrote: > Thank you for taking the time to report this bug and helping to make > Ubuntu better. This bug does not meet the criteria for a stable release > update and is being marked as Won't Fix for this particular version of > the kernel. > ** Changed in: linux-source-2.6.22 (Ubuntu) >Importance: Undecided => Medium > Assignee: (unassigned) => Ubuntu Kernel Team >Status: New => Confirmed > Thank you, Brian. I see you've noted that the problem occurs in 2.6.22 also, so perhaps gutsy will be a candidate for a fix. I'm content to defer a fix--I'd be surprised if anyone's actually hit this. Regards, brian -- sub_info dereferenced after free in finish_usermodehelper_pipe https://bugs.launchpad.net/bugs/132089 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 132283] Re: feisty: metacity: inconsistent window maximize behavior
Sebastien, Thank you for looking into this... On Wed, 2007-08-22 at 16:05 +, Sebastien Bacher wrote: > Thank you for taking the time to report this bug and helping to make > Ubuntu better. The issue that you reported is one that should be > reproducable with the live environment of the Desktop CD of the > development release - Gutsy Gibbon. It would help us greatly if you > could test with it so we can work on getting it fixed in the next > release of Ubuntu. I tested on Gutsy Tribe 5 and updated the Bug. The short summary is that the problem no longer occurs at Tribe 5 (I didn't test the earlier Tribes). Thank you! Regards, brian -- feisty: metacity: inconsistent window maximize behavior https://bugs.launchpad.net/bugs/132283 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 132283] Re: feisty: metacity: inconsistent window maximize behavior
I tested with Gutsy Tribe 5; the problem no longer occurs there. I tested with both gedit and Firefox. In both cases, opening new child windows from a maximal-height window results in a child window that can be freely moved and resized. The inconsistent behaviour is gone, and I think the inconsistency was resolved in the right direction. I suspect the common use case is: User immediately wants to resize or move a new child window. Maximized constrains resize or move, so I think avoiding maximized for new windows is the Right Thing. I'm satisfied with the Gutsy behaviour. Thank you Sebastien! -- feisty: metacity: inconsistent window maximize behavior https://bugs.launchpad.net/bugs/132283 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 132283] feisty: metacity: inconsistent window maximize behavior
Public bug reported:
Binary package hint: metacity
New application windows pick up some partial notion of "maximized" by
virtue of having been created with a maximal width or height.
"maximized" is conceptually distinct from "at maximal width/height"--
windows created with the latter attribute shouldn't assume the former.
Steps to recreate in the vertical using Firefox are described below.
The problem is not restricted to Firefox (I can recreate with gedit),
nor to the vertical (I can recreate in the horizontal as well).
To recreate:
- Open a new Firefox instance. Arrange that the new instance will open
in a window that's smaller than maximum in both horizontal and vertical
directions and is not adjacent to either panel or left or right screen
edges.
- Move the initial Firefox window so the top of the window is adjacent
to the top panel.
- Resize the Firefox window vertically so that the bottom of the window
is adjacent to the bottom panel.
- Open a new Firefox window (ctrl-N).
- Note that the original window can be moved and resized both
horizontally and vertically.
- Note that the new window can only be moved and resized horizontally,
not vertically. Note that when the cursor approaches the top or bottom
border of the new window, it changes to the resize cursor, but an
attempt to resize does not work.
- Maximize the new window. Note that when maximized the cursor does not
change to the resize cursor when it approaches a window border.
- Unmaximize the new window. Note that it can now be moved and resized
both horizontally and vertically.
If the initial window is resized to maximal width _and_ height before
the new window is created, then the new window is created fully
maximized and cannot be moved or resized in either direction. The
window can then be unmaximized; it will still be at maximal width and
height, but can then be resized or moved in either direction.
Relevant package levels:
$ dpkg -l | grep -Ei 'metacity|firefox|gedit'
ii firefox 2.0.0.6+1-0ubuntu1 lightweight
web browser based on Mozilla
ii firefox-gnome-support 2.0.0.6+1-0ubuntu1 Support for
Gnome in Mozilla Firefox
ii gedit 2.18.1-0ubuntu1light-weight
text editor
ii gedit-common2.18.1-0ubuntu1light-weight
text editor support files
ii libmetacity02.18.2-0ubuntu1.1 library of
lightweight GTK2 based Window Man
ii libnspr41.firefox2.0.0.6+1-0ubuntu1Netscape
Portable Runtime Library
ii libnss3 1.firefox2.0.0.6+1-0ubuntu1Network
Security Service Libraries - runtime
ii metacity2.18.2-0ubuntu1.1 A
lightweight GTK2 based Window Manager
ii metacity-common 2.18.2-0ubuntu1.1 Shared files
of lightweight GTK2 based Windo
ii mozilla-firefox-locale-en-gb2.0.0.1ubuntu-1Mozilla
Firefox English language/region pack
I believe this is a metacity problem, and it looks to me like the
culprit may be in meta_window_place(). The call-chain might be:
meta_window_new_with_attrs() -> meta_window_move_resize_internal() ->
meta_window_constrain() -> place_window_if_needed() ->
meta_window_place()
I suspect the following code:
/* Maximize windows if they are too big for their work area (bit of
* a hack here). Assume undecorated windows probably don't intend to
* be maximized.
*/
if (window->has_maximize_func && window->decorated &&
!window->fullscreen)
{
MetaRectangle workarea;
MetaRectangle outer;
meta_window_get_work_area_for_xinerama (window,
xineramas_list[placed_on],
&workarea);
meta_window_get_outer_rect (window, &outer);
if (outer.width >= workarea.width)
window->maximize_horizontally_after_placement = TRUE;
if (outer.height >= workarea.height)
window->maximize_vertically_after_placement = TRUE;
}
** Affects: metacity (Ubuntu)
Importance: Undecided
Status: New
--
feisty: metacity: inconsistent window maximize behavior
https://bugs.launchpad.net/bugs/132283
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 132089] sub_info dereferenced after free in finish_usermodehelper_pipe
Public bug reported:
Binary package hint: linux-image-2.6.20-16-generic
Running feisty, 2.6.20-16-generic, but this problem remains in the
latest feisty and gutsy trees in git.
Found via code inspection that structure "sub_info" is dereferenced
after kfree() in finish_usermodehelper_pipe() in kernel/kmod.c:
int finish_usermodehelper_pipe(struct subprocess_info *sub_info)
{
wait_for_completion(sub_info->complete);
kfree(sub_info->complete);
kfree(sub_info);
return sub_info->retval;
}
This could result in an unwanted fault or a bad return value going back
to the caller. I believe the fix is:
$ diff -u kmod.c.orig kmod.c.fix
--- kmod.c.orig 2007-04-12 12:16:23.0 -0500
+++ kmod.c.fix 2007-08-12 18:00:07.0 -0500
@@ -338,11 +338,13 @@
int finish_usermodehelper_pipe(struct subprocess_info *sub_info)
{
+ int retval;
wait_for_completion(sub_info->complete);
+ retval = sub_info->retval;
kfree(sub_info->complete);
kfree(sub_info);
- return sub_info->retval;
+ return retval;
}
EXPORT_SYMBOL(finish_usermodehelper_pipe);
** Affects: linux-source-2.6.20 (Ubuntu)
Importance: Undecided
Status: New
--
sub_info dereferenced after free in finish_usermodehelper_pipe
https://bugs.launchpad.net/bugs/132089
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
