| samd | hi, im using lucid rc, i just removed a package using apt-get purge and the process ends up with a segmentation fault, the package seems to be removed tho | 00:06 |
|---|---|---|
| Keybuk | slangasek: yay, I literally don't need my GPG key anymore ;) | 00:54 |
| === dmb is now known as NullPointerExcep | ||
| Keybuk | you sign and upload for me <g> | 00:54 |
| ion | :-) | 00:55 |
| Keybuk | james_w: random question; how is the lp:ubuntu/lucid -> lp:ubuntu/maverick transition handled? | 01:08 |
| Keybuk | psusi: I've read your patch | 01:20 |
| psusi | Keybuk, and? what did you think? | 01:39 |
| Keybuk | psusi: I replied to your mail, but basically I like the idea | 01:46 |
| Keybuk | it's what I was trying to do with that code before, but I didn't know how to get the disk locations | 01:46 |
| Keybuk | I didn't know you could call readahead() on the actual disk like that, does it actually work? | 01:47 |
| psusi | Keybuk, seems to... it sped up my boot a bit... the way you had it before the calls into e2fslibs to get the next inode just did a synchronous read() of the inode table of the current block group, then once it had returned all the used inodes there, read() the next group and returns the first entry there... the read() calls read into the buffer cache, then copy the requested inode to the user buffer | 01:48 |
| psusi | readahead() just queues the read into buffer cache and doesn't bother taking a copy | 01:48 |
| psusi | after some discussion on the mailing lists it seems that there just isn't much you can do about readahead() blocking when it has to read the indirect block or external extent tree node to locate the rest of the blocks | 01:51 |
| psusi | so it seems the best thing to do is to have ureadahead map where all the data blocks PLUS indirect blocks are during profile, and call ureadahead() for all of those blocks on the block device, rather than going through the filesystem | 01:51 |
| psusi | of course if defrag manages to reduce the extents a file occupies to 4 or less so they all fit in the inode, then it doesn't make much difference | 01:52 |
| psusi | but I still have some work to do to have defrag properly expand and contract the size of the extent tree | 01:53 |
| Keybuk | right | 01:57 |
| Keybuk | if we can readahead() directly on the block devices, then we can avoid the overhead of open()ing every single file | 01:57 |
| psusi | exactly | 02:00 |
| psusi | but to avoid the overhead of the open() later when the file is actually needed we want to readahead() the blocks of the directories on the path to the files | 02:01 |
| psusi | calling readahead() on the block dev allows us to queue the reads in the background without blocking, and hopefully gets the directory blocks read, and in optimal order, so that they are there when the normal boot process tries to open() those files | 02:02 |
| Keybuk | right | 02:05 |
| Keybuk | makes sense | 02:05 |
| psusi | need to find an e2fslibs call to map the indirect blocks or extent tree blocks used by the file though | 02:08 |
| psusi | and add the to the block list in the pack file | 02:08 |
| Keybuk | right | 02:12 |
| Keybuk | may need to write one of those | 02:12 |
| Keybuk | can I just break a moment | 02:13 |
| Keybuk | I need to go out of the balcony and start screaming into the San Francisco air | 02:13 |
| Keybuk | because some fucking idiot has broken lvm ;) | 02:13 |
| Keybuk | (an upstream fucking idiot) | 02:13 |
| Keybuk | right | 02:14 |
| Keybuk | back | 02:14 |
| * Keybuk understands why lvm2 device nodes fail to get mounted during boot | 02:14 | |
| persia | why? | 02:17 |
| psusi | ? | 02:18 |
| Keybuk | because some idiot merged the broken package I'd deliberately not merged | 02:18 |
| Keybuk | well | 02:18 |
| Keybuk | no | 02:18 |
| Keybuk | that's unfair | 02:18 |
| Keybuk | the idiot is the upstream who wrote the broke software in the first place :p | 02:18 |
| * psusi is just pissed that lvm does not handle mirrors for shit | 02:18 | |
| persia | It doesn't actually expose the events? Will your fix mean that we can actually autodetect and autoload dm_mod as a bonus? | 02:19 |
| Keybuk | I don't think I can fix it | 02:20 |
| Keybuk | I simply know how it's broken | 02:21 |
| Keybuk | dm_mod is built-in | 02:21 |
| Keybuk | *that's* not a problem | 02:21 |
| persia | Ah. I'll stop asking then, so you can get past the pain of understanding the breakage but not the fix. | 02:22 |
| Keybuk | I'm not going to bother understanding the fix | 02:22 |
| Keybuk | we need to hire an lvm expert | 02:23 |
| Keybuk | or drop it | 02:23 |
| Keybuk | but I understand why it's broken | 02:23 |
| psusi | what's broken about it now? | 02:24 |
| Keybuk | it doesn't respond to "add" events anymore | 02:24 |
| Keybuk | almost the inverse of the change you made to dm-raid ;) | 02:24 |
| Keybuk | so basically, if an lvm device gets brought up before cold-plugging (say in the initramfs) | 02:27 |
| Keybuk | the "add" event caused by the cold plug gets ignored by lvm | 02:27 |
| Keybuk | so udev never learns about it | 02:27 |
| persia | Ah, that explains the wonkiness that happens when a USB cable falls out when one has a VG that spans multiple USB drives. | 02:27 |
| Keybuk | so blkid is never run | 02:27 |
| Keybuk | so permissions are never set | 02:28 |
| Keybuk | so mountall never sees it | 02:28 |
| Keybuk | so upstart never sees it | 02:28 |
| Keybuk | etc. | 02:28 |
| Keybuk | yeah, probably other bugs too | 02:28 |
| Keybuk | oooh | 02:30 |
| Keybuk | no, this is an easy one line fix | 02:30 |
| psusi | wait, I dropped the change event from dmraid and left it only responding to add... upstream changed lvm to not respond to add? | 02:30 |
| Keybuk | yes | 02:31 |
| Keybuk | changed devmapper in fact | 02:31 |
| psusi | wtf? when the hell is it supposed to detect the drive then? | 02:31 |
| persia | magic | 02:31 |
| Keybuk | apparently devmapper "always changes the device" | 02:31 |
| Keybuk | except, say, if udev wasn't running when that happened | 02:31 |
| psusi | sure... ignoring CHANGE is one thing... ADD is another... | 02:32 |
| Keybuk | I can understand why they thought that | 02:32 |
| Keybuk | you always get "add /block/dm-0" when the devmapper device is created | 02:32 |
| Keybuk | but that's always before the table is loaded (which is a separate ioctl) | 02:32 |
| Keybuk | loading the devmapper table means you get "change /block/dm-0" | 02:32 |
| Keybuk | (this is one of the reasons I think your dm-raid patch is wrong, fwiw) | 02:32 |
| Keybuk | so devmapper only really needs to respond to "change" events | 02:33 |
| Keybuk | at least | 02:33 |
| Keybuk | when you look at it that way | 02:33 |
| psusi | yea, but who cares unless you are trying to use a logical volume as a physical volume? | 02:33 |
| Keybuk | this is always the case for devmapper and lvm | 02:33 |
| psusi | eh? add event for /dev/sda1 needs to trigger an lvm scan to see if it is a pv.. | 02:34 |
| Keybuk | you're misunderstanding | 02:34 |
| Keybuk | I'm not talking about the underlying block devices | 02:34 |
| Keybuk | I'm talking about the devmapper devices | 02:34 |
| Keybuk | they're block devices too | 02:35 |
| Keybuk | called /block/dm-N | 02:35 |
| psusi | yea, don't need to scan that unless you are trying to use an lv as a pv... | 02:35 |
| Keybuk | no | 02:35 |
| Keybuk | again | 02:35 |
| Keybuk | you're misunderstanding | 02:35 |
| Keybuk | I'm not talking about *lvm* | 02:35 |
| Keybuk | I'm talking about *devmapper* itself | 02:35 |
| psusi | or a dmraid array as a pv... | 02:35 |
| Keybuk | when a dm-N block device is created | 02:35 |
| Keybuk | we need to query it to find out what kind of devmapper device it is | 02:35 |
| Keybuk | we need to *make a device node in /dev* for it | 02:35 |
| Keybuk | (so we need to know what it's name is, e.g. /dev/mapper/foo-bar) | 02:36 |
| Keybuk | we then need to run blkid on it, to see what kind of filesystem is inside | 02:36 |
| Keybuk | then | 02:36 |
| Keybuk | maybe | 02:36 |
| * psusi nods | 02:36 | |
| Keybuk | it's something else like lvm, in which case we add /dev/vg/lv symlinks | 02:36 |
| Keybuk | or maybe the filesystem is actually an lv or something sure | 02:36 |
| Keybuk | but that's just stacking | 02:36 |
| Keybuk | what I mean is some idiot disabled all those rules (create device node for dm devices, run blkid on them, etc.) for the "add" event | 02:36 |
| psusi | I thought it didn't matter for the add event, since the device is empty at that point... have to do all that during change | 02:37 |
| Keybuk | that's clearly what the person with no brain thought | 02:37 |
| Keybuk | but | 02:37 |
| Keybuk | during boot | 02:37 |
| Keybuk | what if the devmapper device is created before, say, udev is run? | 02:38 |
| Keybuk | then udev never knows about it | 02:38 |
| Keybuk | so we "coldplug" udev | 02:38 |
| psusi | ohh, then you only get the coldplug add event | 02:38 |
| Keybuk | right | 02:38 |
| Keybuk | so | 02:38 |
| Keybuk | on boot | 02:38 |
| Keybuk | all the dm devices that existed before udev were run ... | 02:38 |
| Keybuk | now don't get processed | 02:38 |
| Keybuk | and that neatly explains this bug | 02:38 |
| psusi | yep... | 02:38 |
| psusi | Hans did this? | 02:39 |
| Keybuk | no idea who did it | 02:39 |
| Keybuk | but it's wrong | 02:39 |
| Keybuk | badly wrong | 02:39 |
| Keybuk | (that being said, it partially explains a change to udev that will break dm-raid with your patch :p) | 02:39 |
| psusi | well, I still think the right thing to do is remove the partition table support from the kernel entirely and have udev invoke partx or similar to detect partition table and create partition devices ;) | 02:40 |
| Keybuk | I don't disagree | 02:41 |
| Keybuk | except that would make an initramfs mandatory | 02:41 |
| psusi | yep | 02:41 |
| psusi | but Ubuntu does not support installs that don't use an initramfs right? so... | 02:41 |
| persia | There are many folks who want them though. | 02:42 |
| Keybuk | yes we do | 02:42 |
| Keybuk | it's a perfectly acceptable variation | 02:42 |
| Keybuk | we put a not unreasonable amount of effort into continuing to support it | 02:42 |
| psusi | well, acceptable sure if you want do deal with the config changes needed.. but not the default... | 02:42 |
| Keybuk | it's not the default, but it's *entirely* supported | 02:42 |
| Keybuk | in fact, it's very little config change | 02:43 |
| Keybuk | sed -i -e "/do_initrd/s/yes/no/" /etc/kernel-img.conf iirc | 02:43 |
| Keybuk | (and change the root= line) | 02:43 |
| psusi | well, imho if you want to continue to have the kernel support reading partition tables on dmraid disks then the kernel partition code needs extended to detect dmraid signatures and ignore disks that have tnem | 02:44 |
| Keybuk | I think we should round up everyone who knows about dmraid | 02:44 |
| Keybuk | and kill them | 02:44 |
| Keybuk | and burn the evidence | 02:45 |
| Keybuk | and then round up everyone who knows how to recreate dmraid | 02:45 |
| Keybuk | and kill them too | 02:45 |
| psusi | but at the same time, that is more complexity than I feel belongs in the kernel, hence, fuck it, move it to udev rules and get the partition table code out of the kernel ;) | 02:45 |
| psusi | hehe | 02:45 |
| psusi | yea... especially dmraid level 1 arrays | 02:46 |
| psusi | stripe is one thing, but people using fakeraid mirrors need slapped silly | 02:46 |
| psusi | since it does not have write intent bitmaps or handle errors | 02:46 |
| Keybuk | heh | 02:51 |
| Keybuk | I like my good old raid-1 mdadm mirror | 02:51 |
| Keybuk | it's nice and simple | 02:51 |
| psusi | except with the --incremental bug reassembling diverged legs of a mirror | 02:52 |
| Keybuk | I don't know about that bug | 02:53 |
| Keybuk | (and don't want to :p) | 02:53 |
| psusi | heh... plug in one disk, boot degraded, reboot with the other disk only, boot degraded... which is now the default... | 02:53 |
| Keybuk | huh? | 02:54 |
| psusi | and now you have to degraded arrays that have diverged from the original unified mirrored state... boot with both disks, and mdadm can put them back together assuming they are still in sync even though they are not and you end up with a fucked up filesystem that contains parts of both | 02:54 |
| Keybuk | the default is "don't boot at all" | 02:54 |
| Keybuk | at least it was | 02:54 |
| Keybuk | in case of disk failure, we always used to fail | 02:54 |
| Keybuk | not automatically repair or continue without the other half | 02:55 |
| psusi | naw, default now seems to be wait to see if the other disk shows up for a while, and if it times out, boot degraded | 02:55 |
| Keybuk | fail | 02:55 |
| RAOF | Could I get an xserver-xorg-video-intel upload sponsored on bug #541511? It's just to drop the patch to disable DRI on 855 and 845 which didn't help as much as we thought it would. | 02:55 |
| ubottu | Launchpad bug 541511 in xserver-xorg-video-intel "MASTER: [i855] GPU lockup (apport-crash)" [Unknown,Confirmed] https://launchpad.net/bugs/541511 | 02:55 |
| psusi | not a problem there in and of itself... if one disk has actually failed, then booting degraded can be better than not at all for a remote machine | 02:55 |
| psusi | problem is that should the next boot only find the second disk, now youh ave both degraded and mdadm incorrect glues the two back together if the third boot sees both disks | 02:56 |
| Keybuk | right | 02:56 |
| Keybuk | which is why we didn't boot degraded | 02:57 |
| Keybuk | a server should never come up broken | 02:57 |
| psusi | when the metadata on disk 1 days disk 2 failed and was removed, and the metadata on disk 2 says the reverse... mdadm --incremental happily reinserts disk 2 into the running array when invoked from udev on add | 02:57 |
| Keybuk | a sysadmin should be despatched to your DC to investigate | 02:57 |
| psusi | and if the event count happens to be the same mdadm assums they are in sync and does not bother doing a resylc when it recombines the disks | 02:57 |
| psusi | so you sometimes can read data from disk1, and sometimes from disk 2, and they are not the same | 02:58 |
| Keybuk | dispatched too probably | 02:58 |
| Keybuk | I suspect despatched is a completely different work ;P | 02:58 |
| Keybuk | yeah | 02:58 |
| Keybuk | raid failure is bad | 02:58 |
| psusi | naw, booting degraded the first time is good... since at least you have a server up and running, and emailing the admin that a degrade has occured | 02:58 |
| Keybuk | it's a manual fix, not an automatic one | 02:58 |
| Keybuk | no it isn't | 02:58 |
| Keybuk | you should never bring a server up with a known failure | 02:59 |
| Keybuk | that server is no longer redundant | 02:59 |
| Keybuk | it should stay off | 02:59 |
| Keybuk | a sysadmin should pull the affected disk | 02:59 |
| Keybuk | and replace it | 02:59 |
| psusi | yea, but it's no worse off than it would be if you weren't using raid 1 | 02:59 |
| Keybuk | then the server should be brought up | 02:59 |
| Keybuk | you never bring up a server *without* raid | 02:59 |
| psusi | or if the second disk had failed while the system was already up and running | 02:59 |
| Keybuk | then you shutdown the system | 02:59 |
| psusi | naw, you rebuilt using a spare disk hopefully, if you have one ;) | 03:00 |
| psusi | if not, then the admin hopefully gets the email about the failure quicly and does something about it | 03:00 |
| Keybuk | my thinking on this is probably more "enterprise" | 03:00 |
| Keybuk | systems *do not* come up broken | 03:00 |
| Keybuk | you have engineers employed to work at the data centre in case of a remote failure | 03:00 |
| psusi | why not? is there really any difference between coming up degraded, and becoming degraded while already up? | 03:01 |
| Keybuk | it sounds like "small town ISP" thinking is creeping into the server team | 03:01 |
| Keybuk | "if my remote server fails, I have to drive all the way downtown to fix it" | 03:01 |
| Keybuk | psusi: no, but becoming degraded while up is an instant shutdown event | 03:01 |
| psusi | not usually | 03:01 |
| psusi | that's one of the big reasons people use raid 1... if a disk fails you don't crash and have down time while you replace it | 03:02 |
| psusi | default config is to email root telling them HEY! DISK WENT BAD... AND I AM OR AM NOT AUTOMATICALLY REBULDING WITH SPARE | 03:02 |
| psusi | hopefully you have the spare so the system automatically returns to redundant status quickly | 03:03 |
| ScottK | Of course we go to great lengths to avoid MTAs ending up in systems unless someone asks for it, so the odds of that email getting anywhere useful are not so great. | 03:06 |
| psusi | probably should not do that... | 03:08 |
| jdong | psusi: http://jdong.mit.edu/~jdong/ureadahead-pack.svg | 03:41 |
| jdong | psusi: y...yeah, some defragging needed (tm) | 03:41 |
| Keybuk | jdong: heh, what did you do to generate that? | 04:04 |
| psusi | jdong, neat, what do the colors mean? | 04:05 |
| Keybuk | different files I guess? | 04:07 |
| * ccheney thinks he found a bug or something wrt networkmanager and ipv4/ipv6 support | 04:13 | |
| ccheney | might already be reported though | 04:14 |
| ccheney | if you have ipv4 and ipv6 both set to automatic but you don't have something to provide the ipv6 address it doesn't work at all, ie no ipv4 address either | 04:14 |
| ccheney | is that supposed to happen? | 04:14 |
| sladen | ccheney: can't quite follow. Can you find it (with more details, screenshots, etc) | 04:22 |
| sladen | ccheney: certainly one of {ipv6,ipv4} failing should not be preventing the other from working, if there is the wherewithall to do so | 04:22 |
| sladen | ccheney: s/find/file a big/ | 04:22 |
| sladen | ccheney: s/find/file a bug/ | 04:22 |
| jdong | Keybuk: indeed different files; the svg is generated by a hackish python script that reads ureadahead --dump | 04:27 |
| jdong | the code is at bzr branch http://bradmisik.com/trunk/fragraph/ | 04:27 |
| Keybuk | jdong: I think the hackish python should be published ;) | 04:27 |
| Keybuk | ah, sweet | 04:27 |
| jdong | my friend wrote the code, lol I tossed him the idea early last week and he ran with it I guess :) | 04:28 |
| jdong | I just wanted code to generate tree-ring graphs for an unrelated project, but this is pretty neat too :) | 04:28 |
| jdong | but yeah, now that you're here, you can do a quick sanity check to make sure we're interpreting ureadahead's output correctly | 04:29 |
| Keybuk | each character is a page | 04:29 |
| Keybuk | @### represents a fragment of the file that's read in | 04:29 |
| Keybuk | with @ marking the first page, and # marking the rest of the pages read in that block | 04:29 |
| Keybuk | @##@## means an apparently contiguous part of the file is actually in two fragments | 04:30 |
| Keybuk | the numbers below are the same, but in terms of bytes and blocks | 04:30 |
| Keybuk | so yea | 04:30 |
| Keybuk | looks like you are | 04:30 |
| jdong | temugen, meet Keybuk; Keybuk, meet temugen :) | 04:30 |
| temugen | Nice to meet you. | 04:31 |
| jdong | temugen: congrats. you just got the Keybuk stamp of approval (tm) :) | 04:31 |
| jdong | and for the record, this is his ext3 disk on his messy thinkpad ;-) | 04:31 |
| Keybuk | so yeah | 04:31 |
| Keybuk | it's something like | 04:31 |
| temugen | Heh. Thanks. It's not entirely accurate, but I thought it was reasonable for one slide of a presentation | 04:31 |
| Keybuk | <tab>offset, len bytes at diskpos | 04:31 |
| Keybuk | you grab the len and the diskpos | 04:32 |
| Keybuk | so that'd be correct afaik | 04:32 |
| jdong | *nods* | 04:32 |
| Keybuk | pretty > accurate ;) | 04:32 |
| jdong | so wow, bootup files are virtually scattered across the disk then | 04:32 |
| Keybuk | jdong: now you know why I'm so keen for us to switch to btrfs | 04:32 |
| jdong | Keybuk: hehe I look forward to that :) | 04:32 |
| temugen | jdong: It's still slightly skewed since I don't draw the entire disk - only from the lowest read bootup block to the highest | 04:33 |
| jdong | Keybuk: speaking of that, *driveby bug* do you know what ureadahead doesn't seem to pick up a btrfs root fs? | 04:33 |
| temugen | and depending on the macroblock size it'll obviously look more clustered | 04:33 |
| Keybuk | jdong: doesn't pick up? how do you mean? | 04:34 |
| jdong | Keybuk: I don't get a pack generated for my / | 04:34 |
| Keybuk | what error do you get? | 04:34 |
| jdong | Keybuk: I don't get any error, just I only have packs for my boot and var/run mountpoints | 04:34 |
| Keybuk | jdong: kooky | 04:34 |
| jdong | I suspect it's yet another can't-match-the-UUID style bug? | 04:35 |
| Keybuk | jdong: wouldn't have thought so, if it gets mounted! | 04:35 |
| Keybuk | ureadahead doesn't care about such things | 04:35 |
| Keybuk | maybe btrfs doesn't support FIEMAP? | 04:35 |
| Keybuk | it should do though | 04:35 |
| jdong | what's a quick way to test that? | 04:35 |
| Keybuk | temugen: ooi, what are your plans for this code long-term? | 04:35 |
| Keybuk | jdong: err, strace ureadahead I guess ;) | 04:35 |
| Keybuk | it's about the only thing that uses that ioctl | 04:36 |
| temugen | Keybuk: my plans long-term were to give jdong a pretty slide for his presentation XD | 04:36 |
| Keybuk | haha | 04:36 |
| jdong | hahaha :) | 04:36 |
| jdong | Keybuk: what are *your* long-term wishes for this code? :) | 04:36 |
| Keybuk | would you have any objection if I included it in ureadahead? and maybe in the future ported it to C as another --dump mode? (with full credit to you, of course) | 04:36 |
| temugen | No objections at all | 04:37 |
| temugen | I think it could use a little bit of cleanup before that, but I'm never satisfied with my own code regardless | 04:38 |
| Keybuk | I'd need to know your licence terms for that ;-) | 04:39 |
| Keybuk | ureadahead is GPLv2 - is that to your liking? | 04:39 |
| Keybuk | jdong: OOI, if you're running btrfs, how do you get around http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575891 ? | 04:40 |
| ubottu | Debian bug 575891 in dpkg "dpkg makes wrong assumption about readdir() and lose metadata files with btrfs" [Important,Fixed] | 04:40 |
| Keybuk | oh, because apparently Colin backported it to lucid | 04:41 |
| Keybuk | in the _most_recent_ update ;) | 04:41 |
| jdong | Keybuk: (1) hehe was that why for several months I was randomly losing gconf default schema | 04:41 |
| jdong | (2) I saw the commit fly around the btrfs mailing list, and built my own btrfs from dkms | 04:41 |
| Keybuk | jdong: yeah, maintainer files had a tendency to go missing | 04:41 |
| jdong | ah, fun :) | 04:42 |
| ajmitch | because who cares about data as long as you've got the latest crack FS? :) | 04:42 |
| jdong | ajmitch: hey, I consider myself sacrificed for the science of testing :) | 04:42 |
| ScottK | ajmitch: If it's not jdong, it's not crack. | 04:42 |
| temugen | Keybuk: That is fine. | 04:42 |
| ajmitch | ScottK: he's been known for such things for a long, long time | 04:42 |
| ScottK | Yep. | 04:42 |
| ScottK | There was something he recommended against because it was too insane and everyone immediately backed away. | 04:43 |
| jdong | hahaha I vaguely recall that :) | 04:43 |
| Keybuk | temugen: sweet, thanks :) | 04:44 |
| kirkland | Keybuk: hiya ... have you tested raid much at all in 10.04? | 04:45 |
| jdong | Keybuk: is "ureadahead: Unable to obtain rotationalness for device 0:17: No such file or directory | 04:45 |
| Keybuk | as soon as we get a grub2 patch for btrfs, I'm going to switch again | 04:45 |
| jdong | normal? | 04:45 |
| Keybuk | kirkland: I don't test raid | 04:45 |
| Keybuk | jdong: hah, devmapper? | 04:45 |
| kirkland | Keybuk: i've spent the last two days fighting lucid/raid | 04:45 |
| Keybuk | kirkland: raid sounds like the kind of thing the server team should test ;-) | 04:45 |
| jdong | Keybuk: oh yeah, LVM | 04:45 |
| jdong | Keybuk: is that why? | 04:45 |
| kirkland | Keybuk: we usually cover it in vm's | 04:46 |
| temugen | Keybuk: No problem. If you have any ideas for it, I'm all ears. | 04:46 |
| kirkland | Keybuk: my experience this weekend on real hardware hasn't been good :-/ | 04:46 |
| Keybuk | jdong: yeah, LVM have no underlying extends/devices/etc. | 04:46 |
| Keybuk | you end up with a slew of ureadahead warnings/errors followed by it ignoring the device | 04:47 |
| Keybuk | iirc | 04:47 |
| jdong | Keybuk: oh okay. awww so lvm and LUKS users don't get ureadahead love for now? | 04:47 |
| Keybuk | kirkland: not really something I care about, sorry | 04:47 |
| Keybuk | jdong: I don't think it's "for now" so much as "ever" | 04:47 |
| jdong | Keybuk: hehe okay :) | 04:47 |
| Keybuk | figuring out the on-disk extends and ordering of an encrypted filesystem ... | 04:48 |
| Keybuk | that sounds more like a *science* project! | 04:48 |
| kirkland | Keybuk: when at an initramfs prompt, I can see a /dev/md0 and a /proc/mdstat that shows it operational; when i try to "mount /dev/md0 /root" in (initramfs), it fails, with Invalid Argument | 04:48 |
| jdong | Keybuk: and btw, have you seen ibuclaw's forward-porting of legacy grub device detection to grub2? | 04:48 |
| Keybuk | or the kind of thing where, if I succeeded, I'd be immediately hired by the NSA | 04:48 |
| jdong | Keybuk: http://ubuntuforums.org/showthread.php?t=1389279 "Hack GRUB2" | 04:48 |
| Keybuk | jdong: no, source? | 04:48 |
| Keybuk | kirkland: someone on the server team should be able to help with that ;-) | 04:48 |
| jdong | Keybuk: that's the patch I'm using so that update-grub behaves on btrfs | 04:48 |
| jdong | Keybuk: origin is bug 450260 | 04:49 |
| ubottu | Launchpad bug 450260 in grub2 "grub-probe fails with btrfs root (and ext3 /boot)" [Medium,Triaged] https://launchpad.net/bugs/450260 | 04:49 |
| Keybuk | jdong: ah, that's different to having grub root device support | 04:49 |
| kirkland | Keybuk: sorry, it's not the server team that has reinvented the boot process ;-) | 04:49 |
| jdong | Keybuk: oh yeah, right, I misunderstood your complaint :) | 04:49 |
| Keybuk | hmm | 04:49 |
| Keybuk | jdong: that bug is actually really quite interesting | 04:49 |
| kirkland | Keybuk: none of the old tricks that use to work, work any more | 04:49 |
| jdong | Keybuk: yeah, that patch is also needed for a btrfs root even with ext3 boot | 04:49 |
| Keybuk | kirkland: if you're at an initramfs prompt, you're not into the boot process yet - and you're in an area that's barely changed since dapper | 04:50 |
| Keybuk | jdong: right | 04:50 |
| Keybuk | now | 04:50 |
| Keybuk | that's REALLY interesting | 04:50 |
| Keybuk | you're on btrfs root right now? | 04:50 |
| jdong | yeah, I've got a Karmic system up, and can boot up a Lucid VM. | 04:50 |
| * Keybuk joins up two dots and sees a dog | 04:50 | |
| jdong | both btrfs root | 04:50 |
| Keybuk | jdong: can you grab the output of "stat /" for me? | 04:50 |
| jdong | Keybuk: http://paste.ubuntu.com/422540/ | 04:51 |
| Keybuk | aha! | 04:51 |
| Keybuk | so that ureadahead warning/error wasn't from devmapper | 04:52 |
| Keybuk | it was from your btrfs root, right? | 04:52 |
| jdong | Keybuk: correct | 04:53 |
| Keybuk | riiiight | 04:53 |
| Keybuk | sorry | 04:53 |
| Keybuk | I didn't join the dots | 04:53 |
| Keybuk | yeah | 04:53 |
| Keybuk | now that makes sense ;) | 04:53 |
| jdong | cool | 04:53 |
| Keybuk | ureadahead assumes that it can get the major/minor of a given filesystem by stat() on the mountpoint | 04:54 |
| jdong | yeah my lucid VM is devmapper-less and still doesn't generate a pack :) | 04:54 |
| jdong | ah | 04:54 |
| Keybuk | and convert that into a /sys/dev/block/%d:%d lookup | 04:54 |
| Keybuk | which it then uses to get at the queue/rotational file ;) | 04:54 |
| Keybuk | so for you it's looking for /sys/dev/block/0:17/queue/rotational | 04:54 |
| Keybuk | which doesn't exist | 04:54 |
| Keybuk | when it should be looking for /sys/dev/block/8:0/queue/rotational | 04:54 |
| jdong | ah | 04:55 |
| Keybuk | so yeah | 04:55 |
| Keybuk | exactly the same bug as update-grub actually ;-) | 04:56 |
| Keybuk | just in different code | 04:56 |
| jdong | makes sense. I was assuming the two were related | 04:56 |
| jdong | do I need to file a bug about this, or is this in the back of your mind? :) | 04:57 |
| Keybuk | yes, please file a bug | 04:57 |
| Keybuk | the back of my mind keeps falling off | 04:57 |
| jdong | I know what you mean :) Will do! | 04:57 |
| Keybuk | temugen: http://bazaar.launchpad.net/~scott/ureadahead/trunk/revision/109 | 05:01 |
| temugen | Keybuk: haha, I like the summary. Awesome. :) | 05:03 |
| jdong | :) awesome | 05:04 |
| jdong | temugen: ^5 | 05:04 |
| temugen | Keybuk: just a heads up - there's a template.svg script that the visualizer uses for building the svg file. I might submit a patch later to inline it, but I'm letting you know anyway | 05:28 |
| Keybuk | ah | 05:34 |
| Keybuk | I missed that? | 05:34 |
| Keybuk | added | 05:35 |
| ArneGoetje | Laibsch: the Takao fonts are derivatives of the official IPA fonts, which contain bug fixes that may go back into the IPA fonts. The IPA fonts are the industry standard fonts in Japan and it is highly desired that we ship and use them by default in order to gain market share in Japan. | 05:44 |
| pitti | Good morning | 06:00 |
| RAOF | pitti: Good morning. | 06:00 |
| csurbhi | good morning #kernel | 06:07 |
| pitti | kees, jdstrand: ugh, qa-regression-testing is > 500 MB now? what have you guys done? :-) | 06:16 |
| ccheney | sladen: oh ok, sorry i got plugged away from irc for a couple hours, so what i did was enabled ipv6 'automatic' just like is default for ipv4 in networkmanager 'edit connections' for my particular wifi setup | 06:17 |
| ccheney | sladen: when i do that it refuses to connect at all since my router doesn't actually support ipv6 or at least it seems to do that (checking again to verify) | 06:18 |
| ccheney | sladen: yea i have to set ipv6 'ignore' before it will let me connect again | 06:19 |
| ccheney | sladen: i saw someone mention this issue on the comcast ipv6 test forum, they are about to start testing for widespread ipv6 rollout on their cable network in the US | 06:20 |
| maco | ccheney: finally | 06:20 |
| ccheney | i think the rollout probably won't happen until late next year, some of the hardware manufacturers still don't have ipv6 support aiui | 06:21 |
| ccheney | but the testing is happening now to determine what bugs are still left | 06:21 |
| ccheney | one thing that would keep it from being seamless for ubuntu appears to be ipv6 is disabled by default and if you enabled it and don't have ipv6 on your network it keeps the connection down completely even for ipv4 (which seems odd) | 06:22 |
| ccheney | unless i am somehow doing something wrong, which if that is the case it seems non-intuitive | 06:22 |
| ccheney | maco: if you have comcast you can sign up for ipv6 test group still :) | 06:24 |
| ScottK | There's an open bug against (IIRC) eglibc about delays in this case, but not oughtright failure | 06:25 |
| ccheney | hmm they appear to have removed the sign up page now, maybe its not open any more | 06:25 |
| * ScottK is a former Comcast customer due to a desire to have reliable internet | 06:25 | |
| RAOF | ccheney: Your experience mirrors mine - network manager bails if it can't get an ipv6 address, even though the dhcp server has provided a perfectly acceptable ipv4 address. | 06:25 |
| ccheney | http://www.comcast6.net/volunteer.php | 06:25 |
| ccheney | still open just didn't see it | 06:25 |
| ccheney | RAOF: ok | 06:26 |
| ccheney | who took over NM from asac, anyone happen to know? | 06:26 |
| maco | ccheney: i heard, but im not the one whose name is on the comcast account at this flat | 06:26 |
| maco | ScottK: ever get a 4-month outage with comcast like i did? | 06:27 |
| ccheney | maco: ok | 06:27 |
| ccheney | maco: 4-month outage, eek | 06:27 |
| maco | that would be the first and only 4 months during which i had comcast "service" at my old place | 06:27 |
| * ccheney has never had any trouble with them here in houston area | 06:27 | |
| ScottK | maco: Not 4 months, but I had business class service with them and so what I did have was far and away unacceptable. Once FIOS arrived in my neighborhood, I was a former customer. | 06:28 |
| maco | i moved in in april and signed up with them... and in september i gave up and called RCN. RCN got it working within 3 hours :P | 06:29 |
| LinuxGuy2009 | Hi guys Im working on a DVD that will boot all of the buntu flavors from one disk. So far I have Ubuntu and Kubuntu finished for it. When I get it all done it will contain Ubuntu, Kubuntu, Xubuntu, Lubuntu, Studio and maybe Edubuntu depending on free space on the disk. I'm now wondering what my options for hosting this image would be. I'm not sure if its possible to get it hosted with canonical or if I would just need to get a goda | 06:32 |
| LinuxGuy2009 | Its basically a DVD with a folder with iso files and a custom grub4dos boot menu(s). | 06:34 |
| LinuxGuy2009 | http://imagebin.org/94400 | 06:34 |
| mantiena | LinuxGuy2009: we can offer you a mirror in Lithuania :) You can upload your image to ftp://ftp.akl.lt/incoming/ | 06:37 |
| LinuxGuy2009 | mantiena: Ok Ill take a look. Thank you! | 06:38 |
| LinuxGuy2009 | mantiena: If I start a little web page for it, can i just wind up linking to your hosting there? | 06:39 |
| LinuxGuy2009 | For the downloads I mean | 06:39 |
| mantiena | LinuxGuy2009: yea, but you shouldn't link 'incoming' folder. You can upload any files to 'incoming', but you can't remove them by yourself - when you will upload final version just write an email to mantas@akl.lt and rq@akl.lt - then we move these files to 'Linux/Ubuntu' subfolder | 06:40 |
| LinuxGuy2009 | mantiena: Great! thank you | 06:40 |
| mantiena | I'm very interesting in one DVD with all *ubuntu flavours :) | 06:41 |
| LinuxGuy2009 | mantiena: Yeah many people are interested and trust in me, its coming! | 06:41 |
| mantiena | It's nice way to check memory requirements of every *buntu flavour | 06:42 |
| LinuxGuy2009 | yep | 06:43 |
| LinuxGuy2009 | I still havent decided if I will distribute it as the basic ISO which is 1.5MB currently and then the user would download it, open it with something like ISO-Master drop in the iso files and save the final ISO. Burn and boot. Thats it. Or to have the 4+GB image. | 06:44 |
| Mirv | can someone confirm (or the opposite) that 8.04 LTS -> 10.04 LTS will only be enabled around 10.04.1 times? | 06:45 |
| Mirv | ie. the mentioning of the upgrade possibility in update-manager | 06:45 |
| Mirv | I believe that was the case with 6.06 LTS -> 8.04 LTS, but I cannot find any documentation to back that up | 06:45 |
| mantiena | LinuxGuy2009: You can build 2 iso files - one with Ubuntu, Xubuntu, Lubuntu, Studio (without Kubuntu) and another with Kubuntu, Xubuntu, Lubuntu, Studio (without Ubuntu). Most people already know Ubuntu and Kubuntu and most Ubuntu/Kubuntu users already have a Ubuntu or Kubuntu CD, so, I think it's not important to have Ubuntu and Kubuntu in one DVD image | 06:49 |
| LinuxGuy2009 | Hmm interesting point of view | 06:50 |
| LinuxGuy2009 | mantiena: not sure of a name yet. Maybe something like multibuntu or something I dont know yet. | 06:52 |
| RAOF | pitti: Is there still time to get a new xserver-xorg-video-intel uploaded? We need to revert the DRI disablement patch. | 06:55 |
| pitti | RAOF: that sounds ... intrusive? | 06:55 |
| pitti | RAOF: is there a bug report for it with the details? | 06:55 |
| RAOF | https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/541511 is the main one. | 06:56 |
| ubottu | Ubuntu bug 541511 in xserver-xorg-video-intel "MASTER: [i855] GPU lockup (apport-crash)" [Unknown,Confirmed] | 06:56 |
| RAOF | It references https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes | 06:56 |
| RAOF | Which we're release-noting, because everything we've tried fixes for some and breaks for others. | 06:57 |
| pitti | RAOF: hm, wasn't it just disabled two weeks ago to fix this bug? | 06:58 |
| RAOF | Yes. It doesn't fix the bug (for everyone) and appears to makes things worse (for some). | 06:58 |
| pitti | sounds like being between a rock and a hard place then | 06:59 |
| pitti | RAOF: I guess it's easy for an user to disable DRI themselves? | 06:59 |
| RAOF | Yup. | 06:59 |
| RAOF | The decision was to revert that patch to make it easier to test & SRU *actual* fixes that are being worked on upstream, and release note all the various work arounds that work for different people. | 06:59 |
| pitti | RAOF: ok; can you please add an ubuntu-release-notes task and propose a text snippet, and get it uploaded so that it's ready for review? | 07:00 |
| RAOF | I can't upload myself; I'll add the release-notes task. | 07:00 |
| pitti | RAOF: I can sponsor | 07:01 |
| RAOF | The debdiff is attached at the end of that bug. | 07:01 |
| RAOF | http://launchpadlibrarian.net/45412341/reenable-dri-on-845-855.debdiff | 07:01 |
| RAOF | bryceh has already got text for that on https://wiki.ubuntu.com/LucidLynx/ReleaseNotes | 07:04 |
| robertzaccour | anyone here develop for xubuntu? | 07:06 |
| robertzaccour | great theme for xubuntu and no new one ain't a bad thing, hard to imagine a much better one :) | 07:07 |
| mantiena | pitti: maybe you know why there are no daily iso images in cdimage.ubuntu.com since April 19 ? | 07:07 |
| pitti | RAOF: hm, do we have evidence that the regressions affect 845, too? | 07:07 |
| pitti | mantiena: the cronjobs are off; images are triggered manually until the final release | 07:08 |
| RAOF | pitti: The regressions with disabling DRI on 845? | 07:10 |
| pitti | RAOF: yes; your current debdiff seems to re-enable it on both i845 and 855 | 07:11 |
| mantiena | pitti: so, where I should ask for new daily image? There are ~150 updated packages since release candidate image (build on April 19), including ubiquity-casper, ubiquity installer, libc and other important packages, it would be nice to have an ability to test these improvements | 07:12 |
| pitti | mantiena: it's planned to build new ISOs today | 07:12 |
| pitti | mantiena: but in general, asking in #ubuntu-release is the right place | 07:12 |
| mantiena | pitti: thanks for info | 07:12 |
| RAOF | Right. Let me check my launchpad-fu. Certainly we know that the disablement isn't *fixing* the bug on i845. | 07:12 |
| RAOF | pitti: I can't seem to russle up anything definitive on whether disabling DRI on 845 has caused regressions. | 07:19 |
| pitti | RAOF: hm, perhaps we should leave it disabled on 845 then, for now? | 07:20 |
| RAOF | Hm. Apart from the *obvious* regression that 845 can no longer do 3D at all. | 07:20 |
| dholbach | good morning | 07:21 |
| pitti | right, but that was on purpose :) | 07:21 |
| RAOF | Some of the problem is that the 845 and 855 bugs have become a bit intertwined. | 07:21 |
| pitti | hey dholbach | 07:21 |
| RAOF | Morning dholbach | 07:21 |
| dholbach | hi pitti, hey RAOF | 07:22 |
| pitti | RAOF: it's weird that disabling DRI would work worse, though | 07:24 |
| RAOF | The bug is timing dependent. | 07:24 |
| pitti | RAOF: anyway, do you need some more time to check about i845? | 07:24 |
| RAOF | There's a reasonable contingent of 855 owners for whom everything was working acceptably (they were probably getting crashes every couple of days, but what doesn't crash? ;)). I'm concerned that there's a similar contingent of 845 owners who haven't complained because the 855 users had already filed the bugs. | 07:25 |
| pitti | RAOF: so it seems we can't disable/reenable DRI in an SRU then; but for upgraders it'll be a regression either way then | 07:30 |
| RAOF | I'm not entirely sure how to parse that. We can't reenable DRI in an SRU; there's no way we could declare that to be sufficiently safe of regressions. | 07:31 |
| pitti | right, that's what I mean | 07:32 |
| pitti | but we can't disable it either, if that causes new crashes, too | 07:32 |
| pitti | so it seems we should take a look at which problems it causes either way | 07:32 |
| pitti | i. e. a crash every three days with DRI is much better than immediate X startup failure, etc. | 07:33 |
| RAOF | The annoying thing about these bugs are that they're sensitive to the timing of GPU commands. Which may be why *some* people found disabling DRI to help, and some found no difference, or that X died early. | 07:35 |
| robertzaccour | how do i update grub in xubuntu? | 07:36 |
| robertzaccour | i know in gnome its how to update grub gksudo gedit /etc/default/grub but what is it in xfce? | 07:36 |
| pitti | RAOF: ok, so what's your recommendation based on the available bug feedback? | 07:36 |
| robertzaccour | hey RAOF i remember you | 07:37 |
| pitti | (I skimmed it, but there are way too many comments to get an overview in a few minutes) | 07:37 |
| === almaisan-away is now known as al-maisan | ||
| RAOF | I recommend that we drop the patch to disable DRI for both 845 and 855. 855 is easy to recommend. 845 is more borderline, but (a) disabling DRI doesn't actually *help* very much and (b) if upstream fixes it - and it seems like that might be possible - we won't be able to SRU DRI back on. | 07:40 |
| RAOF | Leaving i845 users without 3D for the entirety of Lucid. | 07:41 |
| pitti | RAOF: ok, thanks | 07:41 |
| pitti | RAOF: ok, sponsored | 07:42 |
| pitti | slangasek: ^ discussion wrt. current -intel upload | 07:42 |
| pitti | slangasek: it reverts the patch from two weeks ago, seems it was an un-improvement after all | 07:42 |
| pitti | I'm back in ~ 1 horu | 07:43 |
| RAOF | Thanks, pitti | 07:44 |
| james_w | Keybuk: scary script run by the LOSAs | 07:49 |
| Keybuk | james_w: ok, they know to run that scary script? | 07:52 |
| Keybuk | we included it in the NewReleaseProcess ? | 07:52 |
| === tkamppeter_ is now known as tkamppeter | ||
| james_w | Keybuk: yup | 08:00 |
| james_w | Keybuk: I emailed them last week to check that they were ready, and apparently they are. | 08:00 |
| slangasek | RAOF, pitti: very unhappy that we're flip-flopping on these patches so close to release; why was debian/patches/107_disable_dri_on_845_855.patch applied post-beta2 to begin with? Did we have what we thought was solid confirmation of the fix before uploading? | 08:36 |
| RAOF | We had solid confirmation from one person that disabling DRI worked for them, and a couple of other people also suggested that it fixed the problem for them. | 08:39 |
| slangasek | RAOF: as an aside, I would really prefer that uploads *drop* patches, instead of simply *disabling* them in series; it makes it much easier to see in a debdiff what's really going on | 08:39 |
| RAOF | slangasek: Noted for future debdiffs. | 08:39 |
| slangasek | RAOF: ok - anyway, when push comes to shove (and it has), I agree with you and pitti that it's better to make this change before release than after | 08:39 |
| slangasek | so - accepted | 08:40 |
| slangasek | pushes ISO generation out, but hopefully only by 30 min or so | 08:40 |
| RAOF | In hindsight, it's possible that we didn't get negative results for disabling DRI before we pushed the patch because the people for whom disabling DRI broke things weren't actually looking at the bugs, because *their* systems worked acceptably. | 08:41 |
| slangasek | (since I'm now afk to head into the office) | 08:41 |
| slangasek | RAOF: sure, that's often the case :/ | 08:41 |
| doko | savely arrived in London? | 08:41 |
| slangasek | yep | 08:41 |
| slangasek | RAOF: my doubt is whether we got enough positive confirmation before pushing the patch - if the change had actually helped more people, I guess the conversation today would be different | 08:42 |
| slangasek | because "broke it for some people, but helped a bunch of others" != "broke it for some people, and didn't help most of the people it was supposed to"... | 08:42 |
| RAOF | I think we were a bit desperate for a knob to turn to make it better at that point; we might have been too eager to do *something* | 08:44 |
| slangasek | that's often the case :) | 08:45 |
| slangasek | anyway, thanks for following through on this | 08:45 |
| * slangasek afks | 08:45 | |
| docdawning | Quick question - I'm interested in getting involved in development of applets and whatnot for the Gnome notification panel.. Does any of this sort of stuff get managed by Ubuntu projects or do I need to look more directly at gnome itself? | 08:58 |
| sladen | most at GNOME | 09:01 |
| sladen | docdawning: for things that Ubuntu has a particular interest in (eg. next-gen stuff, standardising interfaces), try the Ayatana lot | 09:03 |
| docdawning | sladen: Cool, any particular URL recommendations for prospective devs? | 09:03 |
| docdawning | sladen: Well, thanks anyway I'm checking it out. | 09:05 |
| sladen | docdawning: do you just want to contribute to $something, or have you something specifically in mind? | 09:06 |
| docdawning | sladen: Fair question. I'm in search of a project. I suppose I'd prefer something that lets me continue to train up my Python skills, but I could go hard core low-level if necessary. I used to have a *thing for C, I guess I could resurrect that. | 09:08 |
| docdawning | So at this point, I'm in search of a project to contribute to. I've been a Linux user for over a decade and yet not actually written any code for the community.. | 09:08 |
| RAOF | Everyone loves python; there's no particular reason that you'd be forced down to C. | 09:09 |
| docdawning | It's time to give something back. I just haven't picked where to focus just yet. I think there's probably room for a fair number of little config file editing GUI things that could be made.. I'd like one for fstab, though I haven't checked if that's been done. | 09:09 |
| docdawning | RAOF: I'm glad to hear that, then 'eveyone' stands a chance of being awesome.. | 09:10 |
| docdawning | ^^ | 09:10 |
| RAOF | :) | 09:10 |
| docdawning | I suppose I'd like to learn more about pretty core stuff for gnome. I did some cocoa/OSX dev for a brief time and saw some really awesome concepts I'd like to see applied more for gnome | 09:11 |
| sladen | docdawning: best way to explore/get up to speed might be to knock up some pygtk stuff | 09:12 |
| RAOF | There's some low-hanging fruit on the config front; I'm thinking specifically of “advanced” screensaver settings (which gnome-screensaver supports, but the current capplet doesn't expose) and an advanced button on System→Preferences→Monitors, to allow people to add modes to the config. | 09:12 |
| docdawning | Mainly I'm thinking of how Apple arranged quicktime to plugin to just about everything.. So if you tweak out quicktime to not suck, suddently a ton of other things inherit that awesome | 09:12 |
| sladen | docdawning: pick a small project (could be the /etc/fstab editor, but you're going to have parsing issues) and then work backwards to achieve that goal | 09:12 |
| docdawning | Yeah, I could rip in to pygtk, but I think the best approach for me is to just jump in to doing something. Seems I'm very capable of wasting vast amounts of time 'learning' things while hardly doing anything.. | 09:13 |
| sladen | docdawning: and do it in pygtk and is lovely and requires 1/10th of the boilerplating (eg. b = gtk.Button("Click me") ; w = gtk.Window("Hellow World") ; w.add(b) ; w.showall() | 09:14 |
| docdawning | RAOF: Low-hanging fruit sounds encouraging | 09:14 |
| docdawning | sladen: Cool, I recently whipped up a garbage little UI for something using tkinter | 09:14 |
| docdawning | I'm all for learning new things.. pygtk sounds fine - though any thoughts on how it compares with tkinter? | 09:15 |
| docdawning | .. I mean, are you saying that tkinter requires a lot more attention than pygtk? | 09:15 |
| pitti | YokoZar: dssi-vst> while it's clear that libwine-dev hasn't existed for ages, wine1.0-dev does not exist either | 09:24 |
| YokoZar | pitti: just uploaded | 09:24 |
| pitti | oh, it's in NEW | 09:24 |
| YokoZar | pitti: The problem was that dssi-vst needs wine 1.0 to build and we didn't have it in the archive anymore. Reuploads weren't working because wine1.2 was providing dummy wine packages that were higher version. Making a separate wine1.0 package was the least bad thing. | 09:25 |
| pitti | YokoZar: I'm still confused -- why do we have wine1.2, and wine1.0 is new? | 09:25 |
| pitti | ah, so it _is_ an older version indeed | 09:26 |
| docdawning | sladen & RAOF: Thx for the tips :) I'm really excited to help actually do some stuff for Ubuntu beyond reporting the odd bug | 09:26 |
| pitti | YokoZar: we are reintroducing obsolete code just to make an universe package building? | 09:26 |
| YokoZar | pitti: exactly, winelib's method of building changed a lot in the intermediate time | 09:26 |
| pitti | is 1.0 even remotely supported still? | 09:26 |
| sladen | docdawning: yes, pygtk is very easy, but it's a *way to learn the Gtk+ APIs* | 09:26 |
| YokoZar | pitti: it's still current stable wine release, technically | 09:26 |
| YokoZar | pitti: 1.2 should be out in like a month or two though | 09:27 |
| YokoZar | pitti: also dssi-vst is in the ubuntustudio seed | 09:27 |
| YokoZar | pitti: and I'm ~95% sure it can run with wine1.2 binary installed, just not build on it | 09:27 |
| RAOF | sladen, docdawning: When I'm doing GTK# coding I quite often refer to the pygtk docs; I've found them to be generally very good. | 09:28 |
| pitti | YokoZar: hm, so perhaps we should just have a wine1.0-dev without the runtime bits? | 09:28 |
| YokoZar | pitti: the runtime bits are needed for building | 09:28 |
| YokoZar | pitti: the only way to get wine1.0 at this point is to install it explicitly manually, as otherwise you'll be transitioned to wine1.2 | 09:29 |
| * pitti will put it into multiverse, since it recommends a multiverse package | 09:29 | |
| docdawning | RAOF: I believe I'm reviewing said documents now.. Exhibit A: http://www.pygtk.org/pygtk2tutorial/ch-GettingStarted.html | 09:29 |
| pitti | YokoZar: hm, doesn't wine1.0 conflict to wine1.2, too? if on nothing else, then at least on /usr/bin/wine? | 09:30 |
| YokoZar | pitti: yes, see new wine1.2 upload | 09:30 |
| RAOF | docdawning: Yup. That's it. | 09:30 |
| YokoZar | (ScottK was handling this but he went to bed) | 09:31 |
| pitti | YokoZar: ah, I see | 09:31 |
| pitti | YokoZar: I'll move the source to multiverse too then, for consistency | 09:31 |
| YokoZar | pitti: Should wine-gecko be in multiverse anyway? It's just a local copy of a file wine downloads at runtime if it's not installed | 09:31 |
| pitti | YokoZar: I don't know, you tell me :) | 09:32 |
| pitti | you mean "in multiverse" as opposed to "not in Ubuntu at all"? | 09:32 |
| YokoZar | pitti: no I mean as opposed to universe | 09:32 |
| pitti | and it seems to me that wine1.0 isn't really meant to be a runtime package in the first place | 09:32 |
| YokoZar | pitti: the file is gecko | 09:33 |
| pitti | or is -gecko needed to build packages, too? | 09:33 |
| YokoZar | no it's not | 09:33 |
| pitti | YokoZar: the primary reason for multiverse is that wine recommends ttf-mscorefonts-installer, which is in multiverse | 09:34 |
| YokoZar | Yeah that's another good reason | 09:34 |
| YokoZar | wine-gecko got put in multiverse originally because I wasn't sure (its Windows version of gecko requires a build step on Windows so the package includes a binary file) | 09:34 |
| pitti | that, too | 09:34 |
| YokoZar | pitti: reminds me, we probably want to do a scrape of the archive finding similar inconsistencies (universe package recommending multiverse one) | 09:35 |
| pitti | YokoZar: ok, thanks; sorry for the nitpicking, but at this point I rather make double-sure | 09:36 |
| doko | geser: did you regenerate the rebuild-test table? | 09:36 |
| YokoZar | pitti: Appreciated. I've been up kinda late working on this for a few days ;) -- I imagine you have too | 09:36 |
| pitti | YokoZar: "pitti is now known as queue_review_bot" :-) | 09:37 |
| YokoZar | Once all the wine packages go in then I need to make one last update to app-install-data to make it consistent | 09:37 |
| pitti | YokoZar: i. e. when dsst-vst has built? | 09:38 |
| pitti | wine should all be in now | 09:38 |
| YokoZar | Ahh, so it has. Ok then back to the salt mines | 09:38 |
| pitti | lol | 09:39 |
| geser | doko: your thanks should go to wgrant (for fixing the bug) | 09:45 |
| doko | geser, wgrant: thanks :) | 09:46 |
| doko | geser, wgrant: would it be possible to remove the packages with upload failures? it's a problem with the librarian, and we don't care about this for the rebuild test. then the results should be better comparable with lucas's test rebuild | 10:01 |
| geser | doko: all "Failed to upload" or only those about the librarian problem? | 10:06 |
| doko | geser: do you see any other failed to upload? | 10:07 |
| geser | I didn't check | 10:08 |
| doko | then all | 10:08 |
| ogra | soren, Ubuntuø ? the new danish remix ? | 10:35 |
| soren | ogra: It will have to be. Otherwise, I'd have to admit to having mistyped. | 10:36 |
| ogra | lol | 10:36 |
| soren | And I never mistpye. | 10:36 |
| ogra | indeed | 10:36 |
| dpm | hey pitti, good morning. A question for you: | 10:36 |
| dpm | pitti, for the final language packs we were planning to use the export from the 23rd, but due to a mistake we ended up using a previous one and thus we're not including the latest work from translators. | 10:37 |
| dpm | pitti, there is no possibility to update the ISOs now, so we'd like to concentrate on releasing those language packs asap post-release. | 10:37 |
| pitti | dpm: then I suggest we'll do a -proposed one about a week after release? | 10:37 |
| pitti | dpm: right | 10:37 |
| dpm | pitti, there are a couple of bugs that will need fixing, but we'll worry about them in yet another language pack upload post-release. For now, though, I find it important to include the latest translation work in the export that we already have | 10:39 |
| dpm | pitti, Arne will build the language packs from the export on the 23rd on the PPA, and we'd like to ask you what you think about copying them directly to -updates instead of going the usual -proposed -> updates way, since those were the ones that were going to be on the final ISOs anyway. | 10:39 |
| dpm | ArneGoetje, ^ | 10:39 |
| pitti | dpm: I'd rather have them uploaded to -proposed directly then | 10:39 |
| pitti | so that we don't have to build them twice | 10:40 |
| dpm | pitti, right, thanks. ArneGoetje, could you take care of that? | 10:41 |
| dpm | and coordinate with Martin? | 10:42 |
| === yofel_ is now known as yofel | ||
| gartral | i know 10.04 is in RC, but here's an issue i feel needs too be ointed out: when a machine has multiple hardwired interfaces, if both are connected to the same end point networking will fail.. falling into some kind of loop. no traffic gets in or out extreme cases have spilled over to the loopback interface, hanging the system. | 11:06 |
| ogra | gartral, what do you mean by "if both are connected to the same end point" ? | 11:09 |
| gartral | ogra: two interfaces, two cables, two ports of same router = dead network | 11:10 |
| gartral | my system has also hung and froze a few times when i had a cable in each interface of my mobo | 11:11 |
| ogra | sounds weird to me to connect both NICs to the same router | 11:14 |
| wgrant | doko: You could retry them.. but I guess I can just exclude the status. | 11:16 |
| gartral | ogra: it knocks my ping down in most games, and it does load websites faster. so i would like to have that back | 11:16 |
| * wgrant excludes the status. | 11:16 | |
| doko | wgrant: thanks, retrying would be a manual thing for now ... | 11:17 |
| wgrant | Rerunning. | 11:18 |
| wgrant | doko: Looks better now. | 11:25 |
| doko | wgrant: not sure if you did read that in the backlog: one more thing: looking at the kdebindings build failure. the corresponding build in lucid was made *after* the test build (given back). maybe these could be colored light red or marked in some way. but it looks good now | 11:29 |
| ScottK | pitti: Would you please toss "sync 570096 -S unstable" into mass-sync. ivoks has details if needed (I'm going back to bed). | 11:29 |
| pitti | ScottK: ok | 11:30 |
| ScottK | pitti: Thanks. | 11:30 |
| ivoks | please, please :) | 11:31 |
| ivoks | i have to rebuild whole stack :/ | 11:31 |
| pitti | ScottK: (in the wifi/network age, what made you leave it in the first place? :-) ) | 11:32 |
| pitti | s/network/laptop/ | 11:32 |
| ScottK | pitti: Getting the first wave of kids off to school. | 11:33 |
| pitti | ah :) | 11:33 |
| ScottK | They're off, so I'm going to crash for a while. | 11:33 |
| pitti | [done] | 11:33 |
| gartral | pitti: cant run an i7 860 in a laptop at 3.1 ghz, with 12 gb RAM and 3 tb hdd.. or if you can.. it would have cost a $%^&load more | 11:35 |
| pitti | gartral: ?? | 11:35 |
| gartral | pitti: sory, misread the "why leave" question | 11:36 |
| pitti | gartral: ah, heh :) | 11:36 |
| pitti | . o O { is there actually so much data in the universe to fill a 3 TB disk? :-P } | 11:37 |
| gartral | i want a computer wit enough hdd space to store all the internets >.> | 11:39 |
| unggnu | hi all | 11:45 |
| unggnu | Is there a reason why sun-java6 doesn't gets updated in multiverse? I mean it is r15 and it should be r20 I suppose. | 11:45 |
| cjwatson | it's updated in partner instead | 11:45 |
| unggnu | ah ok, thx | 11:45 |
| unggnu | But it isn't shipped with Lucid anymore? | 11:46 |
| pitti | right | 11:46 |
| unggnu | Because openjdk and icedtea doesn't seem to work for some sites | 11:46 |
| cjwatson | it's been removed from multiverse | 11:46 |
| pitti | unggnu: we have openjdk as supported option | 11:46 |
| cjwatson | sun-java6 | 6.20dlj-1ubuntu3 | lucid/partner | source | 11:46 |
| unggnu | while sun-java6-plugin works fine with them | 11:47 |
| unggnu | Hm, I am using Karmic 9.10 and have the partner repository enabled but I don't get a Java update. The Adobe Reader update works fine though. | 11:50 |
| cjwatson | it's only in partner for lucid. | 11:50 |
| unggnu | btw. the site is map24.com (java is needed for the interactive mode) | 11:50 |
| cjwatson | at this point I suspect 9.10 may just not get that update. | 11:51 |
| unggnu | cjwatson, but this is a security issue :/ | 11:51 |
| cjwatson | then I assume there is a security bug filed | 11:51 |
| cjwatson | "doesn't work for some sites" is not in itself a security issue | 11:51 |
| unggnu | cjwatson, no, I mean using the sun java r15 in Karmic | 11:52 |
| unggnu | I know that it is multiverse | 11:52 |
| pitti | unggnu: the latest sun-java is in karmic-proposed, eagerly awaiting feedback :) | 11:52 |
| unggnu | pitti, ok, thx :) | 11:52 |
| pitti | in bug 566353 | 11:52 |
| ubottu | Launchpad bug 566353 in sun-java6 "sun-java6 6u20 update available (including security updates)" [Undecided,Fix committed] https://launchpad.net/bugs/566353 | 11:53 |
| cjwatson | oh yes, so it is | 11:53 |
| cjwatson | sun-java6 | 6.20dlj-0ubuntu1.9.10 | karmic-proposed/multiverse | source | 11:53 |
| unggnu | Btw. is it worth a bug report if the partner repository doesn't get updated after an upgrade to Lucid? I still had the karmic distribution tag. | 11:57 |
| Riddell | bryceh: ever seen this before? http://people.canonical.com/~jriddell/tmp/broken-x.png | 11:57 |
| gartral | Riddell: change your font | 11:59 |
| ion | KDE probably has a checkbox for that in the sixteenth tab of some configuration window. :-P | 11:59 |
| gartral | ion: lol, good one | 12:00 |
| ogra | Riddell, learn chinorussian :) | 12:01 |
| pitti | Riddell: I think I saw it at some point, but I can't remember the circumstances any more; what triggered it for you? | 12:01 |
| pitti | could have been a suspend/resume bug | 12:02 |
| Riddell | pitti: I've been doing some login/out testing, otherwise nothing unusual | 12:02 |
| slangasek | asac: you've uploaded the fix for 528887 only to ppa, not to the unapproved queue? (the bug is still targeted to 10.04) | 12:03 |
| asac | slangasek: right. didnt know you were awake. wanted to get a QA confirm that this thing fixes all/doesnt break anything before letting it in. | 12:03 |
| ogra | slangasek, i'm just trying to test the fix | 12:03 |
| ogra | dist-upgrade isnt very fast on the beagle though :) | 12:04 |
| slangasek | asac: I'm in London ;) | 12:04 |
| asac | slangasek: oh right ;) | 12:04 |
| asac | let me see if it has built | 12:04 |
| ogra | it has | 12:04 |
| gartral | how do i get USB to throw more power.. i have a phone that isnt charging off usb in ubuntu but charges fine in windows | 12:05 |
| asac | let me see if a second person is avail for testing | 12:05 |
| ogra | plars should get up soonish | 12:05 |
| slangasek | asac: and have already started first ISO spins - so if we're trying to get this fix in on netbook for final, needs to be in the queue ASAP | 12:05 |
| asac | slangasek: any deadline you want to give? | 12:05 |
| asac | like 30 minutes 1h | 12:06 |
| asac | ? | 12:06 |
| asac | 2h? | 12:06 |
| asac | ;) | 12:06 |
| ogra | 4h ? | 12:06 |
| ogra | :) | 12:06 |
| slangasek | asac: meh, 30 minutes :) | 12:06 |
| asac | lol | 12:06 |
| slangasek | asac: get it in the queue so I can review in parallel | 12:06 |
| slangasek | I'll wait for QA validation before accepting | 12:06 |
| asac | slangasek: ah ok ... i can upload directly then | 12:06 |
| === MacSlow is now known as MacSlow|lunch | ||
| asac | uploaded | 12:08 |
| slangasek | mvo: have you seen bug #569941? any insight? | 12:19 |
| ubottu | Launchpad bug 569941 in update-manager "apport enabled after a distribution upgrade from Karmic to Lucid" [High,New] https://launchpad.net/bugs/569941 | 12:19 |
| unggnu | Is it more likely that the plugin has the bug or the runtime environment if a Java applet in Firefox makes problem with icedtea6-plugin but not with sun-java6-plugin? | 12:20 |
| whomee | how do i activate the Date::Manip module in perl? need it for a program im configuring | 12:22 |
| pitti | whomee: this is a question for #ubuntu | 12:22 |
| pitti | whomee: (install libdate-manip-perl) | 12:23 |
| whomee | ok sorry then :) and thanks | 12:25 |
| mvo | slangasek: looking | 12:26 |
| ogra | asac, slangasek, bug 568630 and bug 528887 both seems to be fixed with asac's PPA package | 12:31 |
| ubottu | Launchpad bug 568630 in netbook-launcher-efl "Default path is sometimes in an icon directory" [Low,New] https://launchpad.net/bugs/568630 | 12:31 |
| ubottu | Launchpad bug 528887 in netbook-launcher-efl "maximus does not give default focus to newly started apps in combination with efl launcher" [Medium,Fix committed] https://launchpad.net/bugs/528887 | 12:31 |
| asac | ogra: nice | 12:33 |
| asac | ogra: can you confirm your testing in the bug? | 12:33 |
| ogra | done already :) | 12:33 |
| asac | its strange though that the icon directory bug is fixed by the gdk window timestamps ;) | 12:33 |
| ogra | yeah | 12:34 |
| ogra | though we always suspected it was a race | 12:34 |
| ogra | timestamps might just solve that along | 12:34 |
| asac | yes, but why does the launcher react on a focus race ;) | 12:34 |
| === MacSlow|lunch is now known as MacSlow | ||
| slangasek | asac, ogra: thanks, netbook-launcher-efl accepted | 13:07 |
| ogra | great, thanks :) | 13:07 |
| asac | cool | 13:08 |
| asac | oh ... the error message bug wasnt confirmed. (ogra mentioned two bugs was confusing) | 13:08 |
| ogra | if we now could drop evo from the images (and loos 100MB) it would be perfect | 13:09 |
| ogra | asac, i cant test that one | 13:09 |
| ogra | no free sockets on my USB hub | 13:09 |
| sebner | slangasek: do you happen to know who is a contact person for the canonical partner repo? | 13:15 |
| xnox | Looking ahead - how about compress debs using xz in Maverick? | 13:16 |
| cjwatson | xnox: selectively | 13:16 |
| cjwatson | support in dpkg is already upstream | 13:17 |
| cjwatson | but we won't do it by default any more than we do lzma by default now | 13:17 |
| xnox | cjwatson, why not? | 13:17 |
| cjwatson | issues on less capable machines | 13:17 |
| cjwatson | don't really want to discuss it now, too busy with lucid | 13:18 |
| xnox | cause for my tiny package the -dbg package went from 7MiB to 1.5MiB | 13:18 |
| xnox | kk | 13:18 |
| cjwatson | so use it for your tiny package then | 13:18 |
| cjwatson | you don't need the default changed | 13:18 |
| xnox | cjwatson, so archive is not rejecting those? | 13:18 |
| cjwatson | you can use lzma | 13:18 |
| cjwatson | xz isn't supported yet | 13:18 |
| xnox | yeah i know that xz is only in debian right now cause we are frozen. | 13:19 |
| cjwatson | Launchpad will need some simple work in order to support xz | 13:19 |
| slangasek | sebner: hum, regarding what exactly? it's administered by the same ubuntu-archive team | 13:19 |
| xnox | cause lintian complains saying they will be rejected. I didn't know ubuntu autobuilds are fine with xz tarballs on ubuntu | 13:19 |
| cjwatson | well, they aren't right now | 13:20 |
| sebner | slangasek: nah, regarding asking for new apps/company offerings etc | 13:20 |
| cjwatson | sebner: http://www.ubuntu.com/partners/ISV | 13:21 |
| sebner | cjwatson: Yeah, I'm more asking for a name/irc nick | 13:22 |
| cjwatson | sebner: I don't know the correct contact, and given that this involves dealing with corporate stuff I suspect that going through the contact form on the website may have better results anyway | 13:24 |
| sebner | cjwatson: ic, thx | 13:25 |
| plars | asac, slangasek: just updated bug #528887 - looks pretty good from here | 13:38 |
| ubottu | Launchpad bug 528887 in launch-lite-proj "maximus does not give default focus to newly started apps in combination with efl launcher" [Medium,Fix committed] https://launchpad.net/bugs/528887 | 13:38 |
| slangasek | plars: cheers - good answer, since it's already accepted ;) | 13:39 |
| plars | slangasek: darn, if I had realized that I would have had some fun with it first :) | 13:40 |
| asac | plars: could you verify the error message UUID problem too? you seem to have a way to reproduce | 13:41 |
| plars | asac: updated bug... fixed... maybe? I'm kinda thinking that it looks like it's just a better phrased error message now | 13:47 |
| === radoe__ is now known as radoe | ||
| ArneGoetje | dpm: yep | 14:13 |
| dpm | thanks ArneGoetje :) | 14:13 |
| === pedro__ is now known as pedro_ | ||
| alkisg | statd isn't started for me by default, is this a problem in the statd upstart job? | 14:30 |
| alkisg | grep start /etc/init/statd.conf: start on (started portmap or mounting TYPE=nfs) | 14:30 |
| alkisg | status portmap: portmap start/running, process 715 | 14:30 |
| alkisg | status statd: statd stop/waiting | 14:30 |
| alkisg | If I stop and restart portmap, then statd also gets started. But it doesn't start on boot, even though portmap does. | 14:33 |
| maxiepax | anyone know what files gnome-system-monitor (used in ubuntu-9.10) uses to get f.ex. cpu load information from? | 14:36 |
| maxiepax | im looking for a file/application to use in a script that simply outputs the cpu utilization to determine what machines are used and not. | 14:36 |
| maxiepax | only ones i can find are either ncurses based or gd based. | 14:37 |
| maxiepax | /proc/avgload spits out the usual 1 5 15m load avg, however asfar as my research leads me, this is the waittime, not really the cpu utilized. | 14:37 |
| === barry` is now known as barry_ | ||
| pitti | maxiepax: top -b? | 14:47 |
| maxiepax | i trid top -b -n 1 | sed -ne '/Cpu/ s/.* \([0-9]*\.[0-9]*\)%us.* \([0-9]*\.[0-9]*\)%sy.*/User: \1%, System: \2%/p' | 14:48 |
| maxiepax | this gives me f.ex. User: 5.4%, System: 1.4% | 14:48 |
| maxiepax | should i assume this is from 1 core, or out of a total of 400% (4 cores) ? | 14:48 |
| pitti | maxiepax: max is always 100% | 14:49 |
| pitti | maxiepax: i. e. with 4 cores, one maxed-out core is 25% | 14:49 |
| maxiepax | well, in "uptime" 1.0 seems like 1.0 = 1 core. | 14:49 |
| pitti | as you just said yourself, numbers in uptime have got _nothing_ to do with CPU cores | 14:50 |
| maxiepax | okey, thanks :) so if i understood you correct, teh above top -b -n 1 i did, would represent 5.4% out of 100% summed up cores. | 14:51 |
| pitti | maxiepax: more like 7.0 (user +sys), but yes | 14:51 |
| maxiepax | pitti: Thanks allot! | 14:52 |
| pitti | maxiepax: I'm not aware of a central /proc/loadavg like file (I could be wrong, of couse) | 14:52 |
| pitti | maxiepax: I believe top just looks at proc/*/stat and sums up | 14:53 |
| maxiepax | yeah =/ linux has tons of different files (alot in /proc) that show different values, however it seems none are really ment for this. | 14:53 |
| maxiepax | and most webpages i read say thats its "impossible" to measure the load on a cpu, since the only true way to measure is by measuring the waiting que for the cpu once its reached its maximum. | 14:54 |
| === barry_ is now known as barry | ||
| pitti | sure, either a process has the (full) CPU power, or none has | 14:55 |
| pitti | never does a process use only "half" a CPU at a time | 14:55 |
| maxiepax | HT :) | 14:55 |
| maxiepax | but, yes i agree. | 14:55 |
| pitti | so I guess top measures the number of spent cycles per process and divides by available cycles | 14:55 |
| pitti | maxiepax: HT> cheating :) | 14:56 |
| pitti | maxiepax: the former is in e. g. getrusage(), so I suppose it's somewhere in /proc/pid as well | 14:58 |
| pitti | or clock_gettime (CLOCK_PROCESS_CPUTIME_ID) | 14:58 |
| maxiepax | im guessing what that does it create a cycle and measure how long it took for it to be processed? | 14:58 |
| pitti | maxiepax: as I said, I think it adds up the CPU time for all processes and divides by number of available cycles (for each slice) | 14:59 |
| pitti | but at this point I suggest to RTFS :) | 15:00 |
| maxiepax | yeah :) i think my boss will be sattisfied with this though, just need something simple to see if a machine is used or not ( found some machines that have been idle for 16 months ) | 15:01 |
| lamont | wtf does xchat suddenly decide that I must want to be cutting text (like I have button 1 down, only I don't) and mouse input elsewhere gets totally ignored... | 15:04 |
| lamont | totally calling that a lucid regression | 15:04 |
| maco | lamont: not just xchat | 15:04 |
| lamont | oh, well, that'd be about the only gui I use... | 15:04 |
| maco | or at least, im having issues with mouse focus in kubuntu as well | 15:04 |
| === xnox is now known as xnox_away | ||
| maco | today i could use the mouse on my channel list but not the nick list in quassel | 15:05 |
| maco | and couldnt click on mails in kmail | 15:05 |
| maco | logging out and back in tends to resolve it. this is only about the 3rd time its happened to me in 3 months | 15:06 |
| ogra_cmpc | lamont, i had the same when my system ran out of ram due to the gem objects bug | 15:06 |
| ogra_cmpc | pretty reliable right before i hit OOM | 15:07 |
| lamont | ogra: fresh boot, totally diff machine | 15:16 |
| === dendro-afk is now known as dendrobates | ||
| ogra_cmpc | strange | 15:16 |
| tkamppeter | pitti, hi | 15:34 |
| === joaopinto_ is now known as joaopinto | ||
| === bjf is now known as bjf[afk] | ||
| joaopinto | anyone else having issues with the mouse getting random buttons release events without an associated physical action ? | 16:12 |
| === vish is now known as Vish | ||
| === Vish is now known as vish | ||
| === vish is now known as Vish | ||
| \sh | hmm..does anyone know where to find python-restkit in our archives? | 16:45 |
| \sh | it'smissing for python-couchdbkit somehow | 16:45 |
| \sh | bts #511996 how nice...anyjson bug fixed in debian, but python-restkit is not available | 16:48 |
| pitti | tkamppeter: hello | 16:49 |
| \sh | pitti: do you think it's ok to file a removal request for python-couchdbkit for lucid so late in the cycle? there are two deps missing, one not mentioned in the version in our archives, and one dep is not available not even in debian :( | 16:56 |
| pitti | \sh: sure, it has zero rdepends | 16:56 |
| pitti | \sh: but it doesn't have any special dependencies, what do you mean? | 16:57 |
| pitti | Depends: python (>= 2.5), python-support (>= 0.90.0) | 16:57 |
| \sh | pitti, which is wrong | 16:57 |
| \sh | pitti: lp bug #511996 | 16:57 |
| ubottu | Launchpad bug 511996 in python-couchdbkit "missing dependency" [Undecided,New] https://launchpad.net/bugs/511996 | 16:57 |
| \sh | pitti, just added debians bug report to it.. | 16:57 |
| \sh | pitti, it doesn't work without python-anyjson and python-restkit...the last package is not even in debian...only as fragment of cached google search | 16:58 |
| pitti | \sh: sure, please file a removal request then, I'll do it right away | 16:58 |
| \sh | pitti: ok...I'll use the very same bug for now...or should I file another one? | 16:59 |
| pitti | \sh: those were added in the current unstable version | 16:59 |
| pitti | \sh: using that one will do | 16:59 |
| === dendrobates is now known as dendro-afk | ||
| tkamppeter | pitti, about bug 564633, can one make a freeze exception? This is really annoying that s-c-p always looks for drivers on the internet before looking locally. I have a patch and it works. | 17:00 |
| \sh | pitti: yes, because they were completly missing ;) and http://packages.debian.org/sid/python-restkit <- nothing | 17:00 |
| ubottu | Launchpad bug 564633 in system-config-printer "system-config-printer: make driver installation optional" [High,Triaged] https://launchpad.net/bugs/564633 | 17:00 |
| pitti | tkamppeter: it can become an SRU | 17:00 |
| pitti | tkamppeter: (final images are being built already) | 17:00 |
| === dendro-afk is now known as dendrobates | ||
| tkamppeter | pitti, can one make it am SRU which gets available before Lucid+1 opens? | 17:01 |
| pitti | tkamppeter: sure, we do that after every release | 17:02 |
| pitti | tkamppeter: in fact, you can upload it right now | 17:02 |
| pitti | tkamppeter: it just won't be processed until after the final release, but at least you can get it off your plate :) | 17:02 |
| tkamppeter | already to lucid-proposed? | 17:02 |
| pitti | yes | 17:02 |
| pitti | \sh: *flush* | 17:04 |
| tkamppeter | pitti, then I will upload s-c-p, ghostscript, and HPLIP soon, as they have some annoying problems. s-c-p will come first as I have the patch, for ghostscript I am still collecting patches (upstrream is very active in PDF interpreter problems currently). | 17:05 |
| pitti | tkamppeter: thank you | 17:06 |
| \sh | pitti: bug #511996 updated pls go ahead ;) | 17:07 |
| ubottu | Launchpad bug 511996 in python-couchdbkit "missing dependency" [Undecided,New] https://launchpad.net/bugs/511996 | 17:07 |
| pitti | \sh: oh, I just closed it :) | 17:07 |
| \sh | pitti, ah ok then ;) | 17:07 |
| \sh | pitti, thx a lot :) | 17:08 |
| pitti | danke Dir! | 17:08 |
| jarnos | I wonder, if the writer of release notes for Ubuntu could co-operate with his/her colleague for Xubuntu? | 17:11 |
| === deryck is now known as deryck[lunch] | ||
| cjwatson | jarnos: it should probably be the other way round, since we do the common stuff, and historically we have cooperated anyway ... Do you have specifics? | 17:18 |
| === beuno is now known as beuno-lunch | ||
| === bjf[afk] is now known as bjf | ||
| jarnos | cjohnston: What do you mean by the specifics? Release notes for Beta2 are here: https://wiki.ubuntu.com/Xubuntu/LucidLynx/Beta2 | 17:24 |
| cjwatson | "cjwatson" not "cjohnston" | 17:24 |
| jarnos | cjwatson: sorry | 17:25 |
| cjwatson | I mean, what are specific examples on which the Xubuntu folks tried to cooperate and didn't get results? | 17:25 |
| jarnos | cjohnston: sorry | 17:25 |
| jarnos | cjwatson: No, I don't have. Currently they are looking for a volunteer to write the release notes for the final release. And I just told I volunteer. | 17:27 |
| cjwatson | anyone doing release stuff for derivatives should coordinate with #ubuntu-release | 17:28 |
| jarnos | cjwatson: ok, I'll continue there. | 17:29 |
| cjohnston | i thought i was important for a minute | 17:41 |
| === dendrobates is now known as dendro-afk | ||
| === al-maisan is now known as almaisan-away | ||
| === beuno-lunch is now known as beuno | ||
| tkamppeter | pitti, s-c-p is uploaded now. | 18:16 |
| === deryck[lunch] is now known as deryck | ||
| === dendro-afk is now known as dendrobates | ||
| gangil | Hi , can can anyone help me how can I read the blocks on which the file is stored ? I know the inode number from the stat command , but how can I use it to find the block(s) on which the file is located and read the same ? I am using UBuntu 9.10 , I tried finding inode.h , dirnode.h , but couldnt find them , can anyone Please Help :-/ | 18:27 |
| Keybuk | gangil: you need to use the FIEMAP ioctl | 18:27 |
| Keybuk | http://lwn.net/Articles/297696/ is old, but relatively correct | 18:28 |
| gangil | thanks Keybuk :) , reading it | 18:32 |
| Keybuk | gangil: if you need an example, just "apt-get source ureadahead" | 18:33 |
| ccheney | cyphermox: ping | 18:35 |
| kirkland | Keybuk: i have a strange issue where it appears that some of my init scripts and upstart jobs are not being run | 18:46 |
| Keybuk | kirkland: probably "lo" not coming up | 18:47 |
| kirkland | Keybuk: at least the following: /etc/init.d/nfs-kernel-server, /etc/init.d/screen-cleanup, /etc/init/qemu-kvm.conf | 18:47 |
| Keybuk | or something in /e/n/i that overrides the /etc/network/if-up.d/upstart script from being run | 18:47 |
| kirkland | Keybuk: okay, how can I determine if that's the case? | 18:47 |
| Keybuk | do only some init scripts not get run, or all not get run? | 18:48 |
| kirkland | Keybuk: well, the system is functional (and gdm is up, etc) | 18:48 |
| Keybuk | that isn't answering the question | 18:48 |
| kirkland | Keybuk: but as I try to use stuff (like kvm, screen, nfs), i see that it just doesn't look like those inits happened | 18:48 |
| kirkland | Keybuk: network/interfaces: http://pastebin.com/XkK4Q4vA | 18:49 |
| Keybuk | probably not that bug then | 18:49 |
| kirkland | Keybuk: bridged networking is "non-standard", perhaps, but hopefully not precluding init, huh? | 18:49 |
| Keybuk | no idea | 18:50 |
| kirkland | Keybuk: what can i do to help troubleshoot this along with you? | 18:50 |
| asavar | Hi, does fedora's tuned daemon make any sense in ubuntu, and if yes, will be it included in repos someway? or ubuntu has similar tool? (I'm not talking about gnome-power-manager or kde's one which included by both systems). They says that it is very good thing but I can't find it in repos (and it's very hard to google it due very common word, btw) | 18:51 |
| Keybuk | kirkland: boot with --verbose and look at /var/log/boot.log and whichever of syslog/messages init messages end up with | 18:51 |
| kirkland | Keybuk: --verbose goes on the kernel cmdline? | 18:53 |
| Keybuk | kirkland: yes | 18:53 |
| kirkland | Keybuk: hmm, booted with --verbose, and everything worked this time :-/ | 19:07 |
| kirkland | Keybuk: trying a few more times | 19:08 |
| chrisccoulson | slangasek - i figured out what was wrong with my nvidia desktop in the end (Xorg starting on vt6) | 19:11 |
| chrisccoulson | for some reason, i have grub booting with console=tty6 ;) | 19:11 |
| chrisccoulson | not sure why though | 19:11 |
| === xnox_away is now known as xnox | ||
| shtylman | I are getting exit status 5 for ureadahead, and googling around doesn't reveal anything... the box we have won't boot cause of this | 19:15 |
| Keybuk | shtylman: ureadahead won't cause your machine to not boot | 19:15 |
| shtylman | Keybuk: that was my thinking as well | 19:15 |
| Keybuk | however whatever is causing ureadahead to exit with status 5 could also be causing the machine to not boot | 19:15 |
| shtylman | any particular kernel flags we can boot with to try and flush out the problem? | 19:16 |
| Keybuk | --verbose is always a good start | 19:16 |
| shtylman | k | 19:16 |
| Keybuk | status 5 is "error while tracing" fwiw | 19:16 |
| Keybuk | most common reason is that stat(/) doesn't translate to a block device | 19:16 |
| Keybuk | there should be other messages in the boot log | 19:17 |
| shtylman | interesting... ok... we will try with --verbose and see if it talks back to us :) | 19:17 |
| ccheney | shtylman: bug 508441 seems to still occur according to a user today? | 19:29 |
| ubottu | Launchpad bug 508441 in openoffice.org "soffice.bin crashed with SIGSEGV in QPixmap::handle()" [Medium,Fix released] https://launchpad.net/bugs/508441 | 19:29 |
| hyperair | crimsun: what do you mean "ck check"? | 19:29 |
| shtylman | ccheney: are you serious... sigh | 19:31 |
| shtylman | maybe packages aren't updated all the way... | 19:31 |
| shtylman | I dunno... this is tragic | 19:32 |
| ccheney | shtylman: perhaps the changes didn't make it into ooo-build-3-2 ? | 19:32 |
| ccheney | shtylman: our ooo-build is fairly recent certainly since feb anyway but wasn't pulled from head | 19:32 |
| shtylman | ccheney: no.. they most certainly have... I haven't touched OO for a long time | 19:32 |
| ccheney | shtylman: hmm :-\ | 19:32 |
| shtylman | and these fixes were in a long time ago | 19:32 |
| ccheney | shtylman: yea | 19:33 |
| shtylman | im tempted to say that this may be something else | 19:33 |
| shtylman | and nessesarily the extensions | 19:33 |
| ccheney | anyone know of an easy way to graph library interdependency from a given set of libraries? | 19:48 |
| ccheney | i'm trying to examine all the OOo libraries to see if there is a way to more efficiently package them | 19:48 |
| Damascene | hello, is there a tool to show up after startup and ask the user if he want to install something that was not installed? | 19:55 |
| ccheney | i did an upgrade just now from karmic and noticed it appears to be removing OOo hyphenation and thesaurus bits during the upgrade process, is that intended or is it not considered a safe time to upgrade causing it? | 20:00 |
| ccheney | or maybe caused by a difference in how language support is done now? | 20:01 |
| ccheney | running language support after upgrade asks to reinstall them again so maybe its intended | 20:04 |
| shtylman | Keybuk: http://paste.ubuntu.com/422946/ | 20:05 |
| shtylman | that is the dmesg log I pulled from the box | 20:05 |
| shtylman | the last part about: [drm:radeon_i2c_sw_put_byte] *ERROR* i2c 0x08 0x30 write failed | 20:05 |
| shtylman | is interesting | 20:05 |
| shtylman | cause we think the box has booted, but that the vid card doesn't let us see anything | 20:06 |
| shtylman | this is an install of ubuntu server btw | 20:06 |
| MTecknology | If I have initramfs-tools installed, does it really do anything to the boot process or is it mostly there for use by initrd? | 20:09 |
| shtylman | is there a kernel flag which will disable the radeondrmfb ? | 20:10 |
| shtylman | Keybuk: ahh ... it appears to be very similar to this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/546743 which has been fixed | 20:20 |
| ubottu | Ubuntu bug 546743 in linux "Blank screen at first boot with ATI ES1000 and 10.04 server" [High,Fix released] | 20:20 |
| shtylman | so we will try a newer cd | 20:20 |
| persia | plars: Hey. I've been looking at bug #569141 and have a solution that works except in the su -c case. Have you made any further progress with it? | 20:35 |
| ubottu | Launchpad bug 569141 in phoronix-test-suite "installing tests fails" [High,Triaged] https://launchpad.net/bugs/569141 | 20:35 |
| Caesar | elmo: yt? | 20:36 |
| plars | persia: I didn't get a chance over the weekend to test it with kdesudo, but the debdiff I proposed works with sudo at least for certain, not sure if kdesudo would be different, but michael seemed to think so | 20:37 |
| Besogon | hello. I'm reading ubuntu policy and trying undestand how contol file should be. Should every package, which has not got Debian's similar package, has field "ubuntu" in it name | 20:38 |
| persia | plars: I could replicate the issue with gksudo as well. Adding "--" makes it go away. | 20:38 |
| persia | Besogon: No, but it's best that it has it in the revision to differentiate. | 20:39 |
| persia | plars: The problem is with the degenerate case where none of kdesudo, gksudo, or sudo are available. | 20:39 |
| Besogon | ok. then next question. I'm not in MOTU group and trying to make little package (universe package). You advise include "ubuntu" field name of the package. Then What should be in Maintainer field of control file? | 20:42 |
| Besogon | http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-binary.html | 20:42 |
| Besogon | Paragraph 3.3 The maintainer of a package | 20:42 |
| persia | Besogon: My advice was to include "ubuntu" in the revision in the version of the package, not the name. | 20:43 |
| persia | Besogon: The maintainer is the folks that are going to maintain it. Initially, that's probably you. If you're looking to have it maintained by an Ubuntu team, you could put the email address of the team there, but you'd want to confirm the team is maintaining it. | 20:43 |
| plars | persia: I know it's ugly, but what about wrapping it with bash -c? did that work for the su -c case? | 20:46 |
| persia | plars: Nope. | 20:48 |
| persia | plars: For local test, try `su -c bash -c aptitude -y install hello` or similar. | 20:48 |
| plars | persia: that doesn't work, but su -c bash -c "aptitude -y install hello" does | 20:50 |
| persia | I thought the point was to drop the quotes. | 20:51 |
| persia | quotes works without the bash as well. | 20:51 |
| Besogon | persia, It shouldn't be maintained by ubuntu team. That is not good software (just a little program on fortran for our students). may be I undestand you. the package will be named "tmmfortran1.0-0ubuntu.deb" Will it correct? | 20:54 |
| persia | Besogon: No. If you're not expecting the software to be maintained in Ubuntu, I'll recommend visiting #ubuntu-packaging, and asking questions there: you're close, but I think there are some basic things that you haven't asked yet. | 20:55 |
| Besogon | thanks for link | 20:56 |
| jibel | cjwatson, hi, the zero-length problem is back with latest dpkg in lucid | 21:04 |
| jibel | cjwatson, but this time only maintainer scripts are affected. | 21:04 |
| YokoZar | pitti: now that we have wine1.0 and wine1.2 packages, we need to remove wine source package -- did you do that? | 21:23 |
| === antivirtel` is now known as antivirtel | ||
| bdrung | kirkland: http://people.canonical.com/~kirkland/Museum/4.10_warty.img.bz2 does not exist | 21:39 |
| kirkland | bdrung: yeah, i know, sorry .... that machine ran out of disk space and had to be deleted :-( | 21:39 |
| kirkland | elmo: any chance of re-hosting those "museum" VMs somewhere? | 21:40 |
| kirkland | elmo: per bdrung's msg ^ | 21:40 |
| Wazzzaaa | For reporting a bug I want to test an upstream kernel from https://wiki.ubuntu.com/KernelTeam/MainlineBuilds But I don't know which I need to download. uname -a gives me: 2.6.31-20 any ideas? | 21:42 |
| Wazzzaaa | no tips? | 21:49 |
| MTecknology | Wazzzaaa: no patience? | 21:49 |
| Wazzzaaa | hehe, ok i shall wait. | 21:50 |
| MTecknology | Wazzzaaa: lotta smart and busy folks in here, I'm only busy :P | 21:51 |
| slangasek | chrisccoulson: hah, ouch | 21:52 |
| chrisccoulson | slangasek - it's fixed and working now :) | 21:52 |
| chrisccoulson | i don't know why i configured grub like that in the past though ;) | 21:52 |
| === dendrobates is now known as dendro-afk | ||
| === sconklin is now known as sconklin-gone | ||
| === dendro-afk is now known as dendrobates | ||
| joaopinto | james_w, bug 381961 is not fixed | 22:14 |
| ubottu | Launchpad bug 381961 in mod-wsgi "libapache2-mod-wsgi should have a dependency on libpython2.6" [Undecided,Fix released] https://launchpad.net/bugs/381961 | 22:14 |
| _romeo_ | hello guys | 22:17 |
| ajmitch | joaopinto: it's in universe, should be possible to get a fix in still | 22:19 |
| joaopinto | ok, since the bug was set to fix released I assume there is a patch somewhere already :) | 22:20 |
| ajmitch | package hasn't been touched since an autosync in march | 22:20 |
| LinuxGuy2009 | Hello I just started a launchpad project and was wondering if Im able to upload my prject to it and how I would do that? | 22:28 |
| LinuxGuy2009 | https://launchpad.net/multibootu | 22:28 |
| joaopinto | LinuxGuy2009, #launchpad is the proper channel for LP related questions | 22:29 |
| LinuxGuy2009 | Oh ok cool thank you | 22:29 |
| JFo | anyone know where pre-proposed is? Apparently we are building the kernel tip there daily and i can't seem to find it | 22:30 |
| ccheney | JFo: a ppa maybe? | 22:31 |
| JFo | I was thinking that | 22:31 |
| JFo | just not sure where | 22:31 |
| * JFo keeps looking | 22:31 | |
| ccheney | JFo: maybe ask in #ubuntu-kernel | 22:37 |
| JFo | ccheney, I think I have found it | 22:37 |
| JFo | thanks though | 22:37 |
| ccheney | JFo: https://launchpad.net/~kernel-ppa/+archive ? | 22:37 |
| JFo | no, that is the normal PPA | 22:37 |
| JFo | I have it now, thank you | 22:37 |
| ccheney | JFo: oh ok | 22:37 |
| JFo | i was thinking it was a Lucid distro PPA | 22:38 |
| JFo | but it is a kernel one | 22:38 |
| Keybuk | anibal: hey | 22:57 |
| anibal | hey scott | 22:57 |
| Keybuk | give me a few minutes, hotel are just setting up international calling for me | 22:57 |
| anibal | ok | 22:57 |
| xnox | who is ubuntubama? | 23:46 |
| xnox | it got "attacked" by it on irc | 23:46 |
| persia | xnox: Asking in #ubuntu-irc or #ubuntu-ops may be more useful. | 23:47 |
| psusi | jdong, what do the colors mean in that disk map you made from the ureadahead pack? | 23:48 |
| jdong | psusi: each color represents a different file on-disk | 23:48 |
| psusi | ahh | 23:48 |
| jdong | psusi: the picture is "deceptive" in that it only graphs from min(blocks_mentioned) to max(blocks_mentioned) | 23:48 |
| jdong | not the "entire disk" | 23:48 |
| psusi | jdong, wanna try defragging? ;) | 23:49 |
| jdong | psusi: but it was pretty enough to put in a slide, which was my goal :) | 23:49 |
| jdong | psusi: hahaha you got code for that? | 23:49 |
| jdong | psusi: I can't try it NOW, but sometime this week, sure | 23:49 |
| psusi | yea... it still can't alter the height of an extent tree but other than that.... | 23:49 |
| jdong | ok cool | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
