[03:08] bdmurray: Error is apparently fixed in xserver-xorg-core 2:1.9.0 The Lucid updates only go up to 2:1.7.6 thus an upgrade from lucid is still an issue. Have you talked with mvo yet? [03:09] I pinged him ~10 hours ago [03:10] bdmurray: ah ok, BTW are you having this issue on *your* machine? [03:10] no [03:11] alright, just wondering :) [03:11] I run natty! [03:11] Ahhh bleeding edge man!! [05:04] Hi guys, a doubt. After doing code change I am using diff command to get difference of files then using patch command to create a patch. It just updated the new file. Is that correct? [05:05] i use quilt to create patches [05:06] what is the command? [05:08] gaurav_pawaskar: http://pkg-perl.alioth.debian.org/howto/quilt.html [05:08] this probably isn't the best channel for talking about that though [05:10] okey :) [05:10] i will ask the same in developers [08:16] I would like to report a bug that affects both the graphical and the alternate installers. What package should I report it to? The problem is disks that uses 4096B sectors, but doesn't report it so that Linux assumes 512B sectors, causing the disks to have really poor write performance. [08:17] jo-erlend: Sounds like the bug is in the hardware -- uses 4K sectors but does not tell the machine it does? That is the bug, isn't it? [08:18] So you need a firmware update to the drive, I would think. [08:23] jmarsden: yes, but still.. From what I read, I gather that the problem is that the partitions begin at sector 63, which isn't divisible by 4. Can I change this without reinstalling and repartitioning? [08:23] jmarsden: that's something I really haven't done before. How do I do that? [08:25] jo-erlend: You might be able to boot from a LiveCD and use a tool like parted to move partitions around slightly, but I would think that reinstalling would be easier/safer. [08:25] jmarsden: if I understand correctly, the problem would magically disappear if we always started and ended partitions on sectors that are divisible by 4. If that's so, is there any reason not to? [08:26] As for drive firmware updates, the exact process depends on the manufacturer of the drive but (if you can get a firmware update that fixes the issue) can be a bootable CD or floppy that uploads the new firmware to the drive. I would not expect the data on the drive to still be there after a firmware update though! [08:26] because this was catastrophic to me. I dualbooted with Windows 7 for a while, and even though I've been using Ubuntu for years, I was really dismayed at how much faster Windows 7 was. That's not so strange, considering that Windows 7 handles the sectors correctly. That means Ubuntu gets more than a 66.6% reduction in write speed, in comparison. [08:27] I'm not sure the "just make everything on 4K boundaries" thing is quite that simple, but I'm not really expert on that. [08:28] I think what you will find is that the reason the drive does not identify itself as 4K is that if it did, Win7 would become unhappy, so they fudged it... but that's just a guess. [08:28] the difference between >100MB/s in Windows and <35MB/s in Ubuntu is _really_ significant. [08:29] Windows XP has the same problem. It actually says so on the harddisk itself, but I never considered it since I use Linux. [08:30] Yes, and I suspect the 63sector offset is a WinXP legacy of some sort. [08:30] I suppose I'll make a backup and then manually partition before I start reinstalling. [08:31] the disk actually has jumpers to decide if you want one of more partitions with XP. [08:32] Ugh! So I was somewhat correct, the drive works overtime to help Windows out, and in the process confuses Linux, perhaps? [08:32] but perhaps the installer could have a list of known disks that suffers from this and partition accordingly? Because these disks are new and are being sold. And people installing Ubuntu _will_ notice the radical speed differences. [08:33] Does a clean install from a current Ubuntu CD still get you the 63 sector offsets by default? That should probably be fixed... [08:33] jmarsden: it does. [08:35] actually, I think there is something wrong. sda1 starts at 1 and ends at 13. The second starts at 13 ... That's not right, is it? [08:35] Maybe related to bug #530071 [08:35] Launchpad bug 530071 in util-linux (Ubuntu Lucid) (and 9 other projects) "Lucid Default live-cd install fails with 4K sector / Advanced Format drives (affects: 5) (heat: 11)" [Undecided,Fix released] https://launchpad.net/bugs/530071 [08:36] jo-erlend: That sounds like you have two overlapping partitions... that would be bad. [08:36] jmarsden: that sounds very similar, yes. That's the disk I have as well. [08:36] OK, so you might want to add any info to that bug that you think will help, or check for fixes mentioned there you can use. [08:37] I just installed 10.04.2 yesterday, so it isn't fixed. [08:39] jmarsden: it's related, except I used the alternate installer. That bug is for live-cd. [08:42] jo-erlend: OK. Then file a new bug against (whatever the alternate installer is called) and see what happens, I suppose. I'd mention the relatedness to #530071 so others can find and read that discussion too. [08:43] jmarsden: the problem is that I don't really understand this. [08:44] jo-erlend: That's OK, describe what you did and what happened, in detail so someone else could repeat it. Include the fdisk -l /dev/sda (or whatever device is relevant) info in the report. [08:45] jo-erlend: You could also try installing 10.10 Maverick and see if it does any better. [08:46] I need to go to bed... I hope I helped a little, anyway :) [08:46] jmarsden: you did. Thanks and sleep well :) [08:47] Hi, i need your help about bug 677226, this package still have security problem in Natty. can anyone open this bug in natty? i will merging this package now [08:47] Launchpad bug 677226 in systemtap (Debian) (and 2 other projects) "CVE-2010-4170 and CVE-2010-4171: staprun module loading/unloading security fixes (affects: 1) (heat: 147)" [Unknown,Fix released] https://launchpad.net/bugs/677226 === cdbs_ is now known as cdbs [09:48] Hi people! [09:49] A couple days ago I opened a new bug that is now fixed with the latest release of Natty. What is the correct way to proceed in this case? [09:50] procced with what? the bug status? or the ap for which bug submited? [09:51] the bag status. I have to close the bug report? [09:51] no [09:51] What is the ap? [09:51] marke it as fix released [09:52] Ok perfect tks AbhijiT [09:54] np === mrpouit is now known as mr_pouit === maxb_ is now known as maxb [17:24] acarpine: re the bug just fixed with a new natty package: it would be nice to find out *which* change fixed the issue, and point to it; of course, if nothing pops up, just state 'fixed by unknown change in package xyz (full version string) === ikonia_ is now known as ikonia === Pici` is now known as Pici === hggdh_ is now known as hggdh