[Bug 1267059] Re: "Unattended-Upgrade::Remove-Unused-Dependencies" does not work
I can confirm what Nils Toedtmann says. I discovered this bug precisely because I encountered situation #1089195. This is a serious issue for any production servers as you want them to get automatic security updates, but running out of inodes will simply bring them down. I don't know why this hasn't been fixed in over a year. It's an extremely serious problem. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1267059 Title: "Unattended-Upgrade::Remove-Unused-Dependencies" does not work To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1267059/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 227808] Re: file permissions destroyed by vim/gvfs/fuse
At this point I hope it is never fixed. It's more hilarious that I keep getting emails every year or so when people discover it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/227808 Title: file permissions destroyed by vim/gvfs/fuse To manage notifications about this bug go to: https://bugs.launchpad.net/gvfs/+bug/227808/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 939300] Re: precise 12.04: consider adding Apache 2.4 ?
Why can't both be included in the LTS? There could be a package named apache-2.2 and one named apache-2.4. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/939300 Title: precise 12.04: consider adding Apache 2.4 ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/939300/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 227808] Re: file permissions destroyed by vim/gvfs/fuse
I just tested this on the latest 10.04 RC. The bug still exists. It's exactly the same as it has been for two years. ** Also affects: gvfs Importance: Undecided Status: New -- file permissions destroyed by vim/gvfs/fuse https://bugs.launchpad.net/bugs/227808 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 115637] Re: headphones on laptop don't mute laptop speakers on Toshiba A120-237
$ lspci -nv | grep -A1 0403 00:1b.0 0403: 8086:27d8 (rev 02) Subsystem: 10cf:13b4 -- headphones on laptop don't mute laptop speakers on Toshiba A120-237 https://bugs.launchpad.net/bugs/115637 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 115637] Re: headphones on laptop don't mute laptop speakers on Toshiba A120-237
I just tested 9.10 beta CD on my Fujitsu P7230. The speakers did not mute when I connected headphones. Audio came out of both outputs simultaneously. -- headphones on laptop don't mute laptop speakers on Toshiba A120-237 https://bugs.launchpad.net/bugs/115637 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 29560] Re: drag & drop improvement: delay bringing window to front until mouse released
Hi, My bug #388247 was marked as a duplicate of this one. However, I do not believe that mine is actually a duplicate. This bug, #296560, talks about a situation where people drag from a lower window to an upper window. Then the lower window steals focus when it should not do so. That is the opposite of my bug. My bug is not about stealing focus at a bad time. It's about not stealing focus when it should be stolen. Let's say I want to drag something from an upper window to a lower one. The lower window is currently obscured by upper windows. While my drag is hovering over the lower window, that lower window should steal focus, so that I can aim my drag at a specific folder or spot in that (formerly) lower window. Also, if I continue to drag around, any window I hover over for more than a short amount of time should steal focus. If this explanation isn't clear, please don't hesitate to ask for clarification. Thanks. -- drag & drop improvement: delay bringing window to front until mouse released https://bugs.launchpad.net/bugs/29560 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 338985] Re: Laptop speakers don't mute when headphone is connected
I have a Fujitsu P7230 laptop. It has the Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02). I can confirm that this problem still exists with the Ubuntu 9.04 beta Live CD. When I connect my headphones, they work, but the speakers do not mute. This used to work before pulse audio, now it doesn't. -- Laptop speakers don't mute when headphone is connected https://bugs.launchpad.net/bugs/338985 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 227808] Re: file permissions destroyed by vim/gvfs/fuse
Tested with Jaunty Live CD. Same exact problem still exists. Permissions on .gvfs folder are set to 700 in order to prevent unauthorized access of virtual file systems by other users of local system. vim and some other applications are running chmods and passing these permissions through to the virtual file system to the underlying non-virtual file system. -- file permissions destroyed by vim/gvfs/fuse https://bugs.launchpad.net/bugs/227808 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 227808] Re: file permissions destroyed by vim/gvfs/fuse
I just tested the bug, and the same exact problem persists in 8.10. I think really this is one of those bugs where you have two competing projects/philosophies against each other. It's not a problem of coding the solution, it's a problem of resolving conflict. When something is mounted in .gvfs, the virtual file system applies a umask of 077. This makes sense. If I use SSH to mount a virtual file system from another machine, I can't allow anyone else on the local machine to have any permissions on the remote files. If a user chmods a file in the virtual file system, the chmod is passed onto the real file system. That makes sense. I might virtually mount a directory on a web server I'm working on, and I might want to change permissions on some files so the web server allows access to them. I don't want the chmod to allow other users on the client end to go poking around my web server. I want it to change permissions on the other side. Some text editors, and I'm sure other programs as well, like to set a files permissions when they save. I'm sure they have a valid reason for this, even though I personally can't think of any. In order to set the permissions, the text editor first needs to know what the original permissions are. When they ask the virtual file system for the permissions, they are told the post-umask permissions. This is correct, otherwise the text editor might thing a file is read-write when it is read-only or some other such situation. When the editor saves the file, it also sets the permissions. The virtual file system doesn't modify its own permissions, it passes the chmod down the line to the real file system it represents. As a result, the local permissions overwrite the remote permissions, and the umask is pushed through. You have two separate things which behave correctly and appropriately when considered individually, but act very badly when working in combination. It's a problem that affects all virtual file systems. You want to give users the functionality to modify remote permissions, but you want the local security of the umask. I think there definitely needs to be a philosophical discussion before we're going to see a resolution. -- file permissions destroyed by vim/gvfs/fuse https://bugs.launchpad.net/bugs/227808 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 227808] Re: file permissions destroyed by vim/gvfs/fuse
Because I was reminded of this bug, I decided to check again. I can confirm that on my completely up to date install of Ubuntu 8.04, this bug is still in effect. I tested multiple text editors this time. Some of them caused the bug to appear, and some did not. Editing with vim, emacs, or anjuta(scintilla) all resulted in the undesired change of permissions. Editing with gedit or nano did not change the permissions. Editing with anjuta(gtksourceview) failed to even open my test file over gvfs. I ran these tests over two different gvfs/sftp connections. One connection was to a FreeBSD 6.3 box, and the other was to an Ubuntu 8.04 server. I imagine that looking at the source code of the save functions in these different text editors will bring the cause of this problem to light. -- file permissions destroyed by vim/gvfs/fuse https://bugs.launchpad.net/bugs/227808 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 227808] Re: file permissions destroyed by vim/gvfs/fuse
Also, Jonathan, the reason sshfs does not have a problem is that it does not involve gvfs or fuse. -- file permissions destroyed by vim/gvfs/fuse https://bugs.launchpad.net/bugs/227808 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 227808] Re: file permissions destroyed by vim/gvfs/fuse
Up until now I've been using gvfs/fuse with ssh. For the sake of experimentation, I tried this problem with gvfs/fuse and windows sharing. Here's what happened. I setup two Ubuntu 8.04 machines on the same network. One one machine I created a Public read/write file share on a folder named Public. I did this through the gui in Nautilus. On the other machine I went to places->connect to server to mount the share. On the host machine in the shared folder I created a file named test.txt with permissions of 644. The owner and group of the file were both srubin (me). Next, on the client machine, I went into the ~/.gvfs folder to find the file test.txt. The permissions on the file were set to 700, owner and group were both apreche (my user on the client machine). I then proceeded to make a minor edit to the test.txt file in the ~/.gvfs folder with vim and write the changes. After writing the changes, the permissions on the host changed! Instead of being 644 srubin:srubin they were now 744 nobody:nogroup. This is still the same bug, but it is not the same as what happens when using ssh. With ssh the permissions would have changed to 700 without changing the user or group. -- file permissions destroyed by vim/gvfs/fuse https://bugs.launchpad.net/bugs/227808 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 227808] Re: file permissions destroyed by vim/gvfs/fuse
I've investigated this issue more thoroughly, and I think I have come to the conclusion that this is a bug in vim. Here is a quote from the vim documentation. Vim attempts to preserve the ACL info when writing a file. The backup file will get the ACL info of the original file. I attempted to change some of the options in vim, such as set nowritebackup, but that didn't help. I was guessing that vim was creating a backup file with incorrect permissions, and then overwriting the real file with the backup file. However, even with nowritebackup set, which disabled the backup file behavior, the permissions are still destroyed. vim is the only text editor to have this problem. I'm going to submit a bug to vim to see what they say. -- file permissions destroyed by vim/gvfs/fuse https://bugs.launchpad.net/bugs/227808 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 227808] Re: file permissions destroyed by vim/gvfs/fuse
gvim sftp://[EMAIL PROTECTED]//home/leann/bug.txt Yes, this will not produce the error because gvim will connect to the remote "real" file system directly through sftp. The error only happens when going through the gvfs/fuse file system. Further thinking about it, I think this bug comes from two places. First, why does vim chmod files when it saves them? Other text editors don't do this. Perhaps a vim patch is necessary? Second, how come all files in the gvfs/fuse file system have permissions of either 600 or 700? What if someone wants to make a script in the gvfs/fuse file system executable? What if someone wants to allow a web server to deliver files from a gvfs/fuse file system? These things are not possible if all permissions are defaulted to 600/700 and all chmods are passed through to the underlying "true" file system (at least with sftp they are). I think there needs to be a fundamental change to the way gvfs/fuse deals with file permissions. -- file permissions destroyed by vim/gvfs/fuse https://bugs.launchpad.net/bugs/227808 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 227808] [NEW] file permissions destroyed by vim/gvfs/fuse
*** This bug is a security vulnerability *** Public security bug reported: This bug is a little difficult to explain, but I will do my best. I'm using Ubuntu Hardy Heron with no third party repositories. Every package is up to date as of this posting. It goes like this. When I edit files with vim or gvim through gvfs/fuse/sftp the file permissions on the real remote file system get destroyed. Here is a procedure you can follow to duplicate this bug. The only non-default package you need installed is vim or gvim. 1 - Open a terminal and ssh to a remote machine. 2 - In this terminal create a text file on the remote machine, and set the permissions to 644. 3 - Go to the Places->Connect to Server... menu item, and create an SSH connection to the remote machine. 4 - Double click the new sftp folder icon that appears on the desktop to open nautilus. 5 - In nautilus browse to the directory containing the text file you just created. 6 - Use the command ls -l in the ssh terminal to verify the permissions of the file are still 644. 7 - In nautilus right-click on the text file, open it with "Text Editor" (gedit) 8 - Make a change to the file in gedit and save it. 9 - Use the ls -l command in the terminal to verify that the permissions of the file are still 644. 10 - Exit gedit. 11 - In nautilus right-click on the text file and select the option to open it with "GVim Text Editor" 12 - Make some changes to the file in GVim, and save those changes. 13 - Use the ls -l command in the terminal, and you will see that the permissions of the file are now 600, not 644. Some interesting things to note about this bug. If you open the text editors from the command line, instead of through nautilus, the same problem happens. So opening gedit like this: gedit ~/.gvfs/sftp\ on\ remote/home/user/test.txt will not damage the permissions. However, opening vim like this: vim ~/.gvfs/sftp\ on\ remote/home/user/test.txt will damage the permissions. Also, I notice that if you do this ls -l ~/.gfvs/sftp\ on\ remote/home/user/ the permissions of test.txt (and every other file) will appear to be 600 (700 for directories), regardless of the file permissions on the "real" remote file system. If you attempt to chmod any files, it will result in a chmod of the actual permissions on the remote file system, but it will not change the permissions of the file in the local ~/.gvfs directory. This has led me to conclude that this bug is a combination of two things. First, using the chmod command on files through gvfs/fuse/sftp does not work in an expected fashion. Secondly, gvim and vim appear to be chmod-ing files when they write to those files. I'm not sure this bug is an actual security risk. It seems it can only result in file permissions becoming more strict, not more permissive. However, I have checked the security box just to be safe. If file permissions involved, there could always be an unseen security issue. I can see a situation where an application losing the ability to read a needed file causes system breakage, if not a security hole. ** Affects: ubuntu Importance: Undecided Status: New ** Visibility changed to: Public -- file permissions destroyed by vim/gvfs/fuse https://bugs.launchpad.net/bugs/227808 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 59695] Re: default value in power.sh potentially kills laptop disks
I can almost 100% confirm that this problem killed the 1.8" 40 gig Toshiba drive in my Fujitsu P7230. However, I am not upset because I have replaced it with a solid state drive that works quite well. -- default value in power.sh potentially kills laptop disks https://bugs.launchpad.net/bugs/59695 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 64630] Re: Crashes when trying to record (Segmentation Fault)
This bug is still the same in the gutsy beta. If the bug isn't going to be fixed, just remove rezound from the repositories. Do we want *buntu users to have easy access to the best open source single-track audio recorder/editor or not? -- Crashes when trying to record (Segmentation Fault) https://bugs.launchpad.net/bugs/64630 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 106930] Re: Audacity crashes unexpectedly
My roommate is having the same problem, and it has repeated multiple times. Seemingly at random times while working with Audacity on Fiesty on his new computer, it will crash, hard. Not just Audacity, but the whole system. He has to hard reboot to be able to do anything. It's only when working with Audacity and occasionally other audio apps are unstable, but not in the same way. I think there are problems in the audio parts of the Fiesty kernel that affect people with newer hardware. -- Audacity crashes unexpectedly https://bugs.launchpad.net/bugs/106930 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 64630] Re: Crashes when trying to record (Segmentation Fault)
We are also having this problem in rezound on Feisty on every machine we have tried. It crashes as soon as you try to record with a segfault. Trying to compile rezound from source results in the same exact issue. My guess is that one of the dependencies of rezound is a newer version in Feisty and that dependency, whatever it is, has changed in a way that breaks rezound. Heck, it might even be a kernel change. The reason the segfault happens appears to be because rezound screws up while reading from /dev/dsp. Perhaps the buffer it is reading into gets broken, or perhaps it is reading improperly. I can't tell. Also, I can say that rezound --audio-method=alsa has not worked to solve this problem. I have tried it on many different Feisty machines, and it crashes just the same as when using the default of OSS. However, there is a way to get rezound to work. The way is to use jack. Do the following if you don't have jack working already. sudo apt-get install qjackctl qjackctl # push the start button rezound --audio-method=jack Now rezound will be able to work properly without crashing. Using jack should also give you some measure of enhanced performance. This will be especially true if you have the low-latency audio stuff in the kernel, or if you use UbuntuStudio, which has the low-latency stuff by default. Regardless, I think this bug needs increased priority. Rezound is the only halfway decent single-track audio editor for Linux, and it's the only free open source one in existence. Multi-track editors like Jokosher or Audacity just do not cut it compared to Rezound, especially when it comes to thinks like podcasting. Not having this application work in Ubuntu Feisty is a pretty big deal. -- Crashes when trying to record (Segmentation Fault) https://bugs.launchpad.net/bugs/64630 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 85029] Re: Deskbar applet crashes at startup since I installed libdeskbar-tracker
I don't have this problem in Gnome under Feisty, but I do have the problem in Xfce under Feisty. I've uninstalled libdeskbar-tracker. I've also killed trackerd, and tried to make sure it does not start automatically. This, of course, allows deskbar to start without crashing. However, trackerd is still running when I login to Xfce! I can't figure out what is starting it. -- Deskbar applet crashes at startup since I installed libdeskbar-tracker https://bugs.launchpad.net/bugs/85029 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
