| === Guest14243 is now known as temugen | ||
| === asac_ is now known as asac | ||
| === jjohansen is now known as jj-afk | ||
| === jtimberman_ is now known as jtimberman | ||
| james_w | if there are any buildd admins around could you please bump the priority of https://edge.launchpad.net/ubuntu/+source/initramfs-tools/0.98.1ubuntu4/+build/1964533 as it breaks installing initramfs-tools on armel, and hence building images | 02:45 |
|---|---|---|
| StevenK | james_w: Bumped. | 03:06 |
| james_w | merci | 03:06 |
| === dendro-afk is now known as dendrobates | ||
| === nxvl_ is now known as nxvl | ||
| === dendrobates is now known as dendro-afk | ||
| === buxy_bak is now known as buxy | ||
| === SolidLiq is now known as solid_liq | ||
| TheMuso | cjwatson: Good to know for the future, thanks. | 08:38 |
| SpamapS | ugh.. bzr branching samba is.. painful | 08:56 |
| SpamapS | 238964kB 372kB/s / Fetching revisions:Inserting stream:Estimate 110480/110699 | 08:56 |
| SpamapS | 165M.bzr | 08:56 |
| SpamapS | oi! | 08:56 |
| persia | #bzr can probaby help more with data analysis to improve performance. We just use what they send us. | 08:57 |
| SpamapS | Its an impressive amount of data.. :-P | 08:58 |
| * SpamapS hopes to only do this once ;) | 08:59 | |
| lifeless | package or upstream? | 09:00 |
| lifeless | its a big tree (its big in git too) | 09:01 |
| lifeless | SpamapS: how are we doing perf wise with Launchpad, a couple of months down the track. | 09:03 |
| lifeless | from your perspective-as-user | 09:03 |
| lifeless | persia: and you, any thoughts? | 09:03 |
| persia | I get significantly more timeouts, to the point that I avoid using LP if there is another way to get the same data, but pages that do render render considerably faster. | 09:04 |
| SpamapS | lifeless: most things are better. converting bugs to questions still stinks. ;) | 09:04 |
| lifeless | yes | 09:05 |
| persia | I'm really looking forward to the performance enhancement program ending, under the (perhaps false) expectation that this will lead to an increase in the timeout window for stuff that takes too long. | 09:05 |
| lifeless | its being worked on , there is a patch atm to do the email component async from the web xact | 09:05 |
| lifeless | persia: no, the timeouts are going to be clamped at 5 seconds | 09:05 |
| SpamapS | I haven't gotten timeouts regularly on anything except converting bugs to questions, which I only do about once a month anyway. | 09:05 |
| persia | Oh :([ | 09:06 |
| lifeless | persia: long transactions cause gc issues in the db server, locking issues (when the xact is a mutating one) and can cause cascading failures. | 09:06 |
| lifeless | persia: the solution to things that are slow is to make them fast. | 09:06 |
| persia | lifeless, Fair enough: now make it fast enough that I don't care that you clamp it at 5 seconds :) | 09:07 |
| SpamapS | lifeless: your message about the problem of putting 1000 entries ina todo list had me wondering if a unique key couldn't be used to coalesce those notifications. | 09:07 |
| lifeless | persia: we'll be able to make exceptions when something goes screwy to raise the timeout, but those will be rare and temporary. | 09:07 |
| SpamapS | lifeless: oh and to answer your first question, this is branch lp:ubuntu/samba | 09:08 |
| SpamapS | 369M.bzr | 09:08 |
| SpamapS | final size of the shared repo | 09:08 |
| lifeless | SpamapS: does it have full upstream history ? | 09:08 |
| lifeless | persia: thats the goal; we're aiming for a <1 second response for nearly all (99%) of backend renders | 09:08 |
| persia | lifeless, Things that I don't even bother trying to do anymore include: 1) filing apport bugs with lots of data (limited data is fine), 2) searching for anything at all, 3) attempting to look at "more data" beyond what I get by default (which usually isn't sufficient for the sorts of auditing I want to do) | 09:09 |
| lifeless | persia: the first stage is 5 seconds, at which point the hard timeout will stop being lowered. | 09:09 |
| SpamapS | lifeless: first entry is timestamp: Fri 2004-10-15 14:31:58 +0200 | 09:09 |
| lifeless | persia: search shouldn't timeout at all except for one case : Distribution:+search | 09:09 |
| lifeless | SpamapS: guess not | 09:09 |
| persia | I think that's a really good plan, and likely to get better results than turning off the timeout again once some performance work has been done. | 09:09 |
| lifeless | persia: apport bugs is a high pri one, I mailed the list about the root cause today in fact | 09:10 |
| lifeless | its just faulty programming, not intrinsically a lot of work though, so it can be fixed. | 09:10 |
| persia | lifeless, search *shouldn't* timeout? Hrm. I'll have to try that again. Lots of times if I'm searching for something very specific, I used to have >30 second response times, and since the limit, I get nothing. I'll try again, and report the results. | 09:10 |
| lifeless | https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=timeout | 09:10 |
| lifeless | master timeout list | 09:11 |
| StevenK | It would be amusing if that page timed out | 09:11 |
| lifeless | persia: search for 'search' in the text of that page you can see the known search isues | 09:11 |
| lifeless | and I think I found a dup :) | 09:12 |
| persia | Won't: it's already finding nearly the limit of the available window: one would have to report lots more bugs and do extensive URL hackery to get a timeout. | 09:12 |
| StevenK | persia: I know that it wouldn't time out, I was just chuckling and thinking it would be ironic | 09:12 |
| lifeless | we'll reject requests for too large a batch size anyway | 09:12 |
| persia | lifeless, I'll definitely give it a try, but not likely before release, as my list of things I *really* want to get done isn't going down nearly as quickly as I'd prefer. | 09:13 |
| persia | StevenK, It would be wonderfully ironic, yes. | 09:13 |
| persia | lifeless, That's mixed news to me: sometimes I really want lots of rows (yes, I know, go use the API) | 09:13 |
| lifeless | persia: sure, just saying if you get a search timeout: check that listing, if its not one of the search bugs on that page, file a bug. | 09:13 |
| lifeless | persia: | 09:13 |
| lifeless | bah | 09:13 |
| lifeless | 300 is the cap | 09:14 |
| lifeless | I think this is a bit noddy | 09:14 |
| persia | I'll definitely do that. From today, I'll put "searching on launchpad" back in my list of potentially acceptable actions to perform. | 09:14 |
| lifeless | its a proxy for 'do not let users use too much resources' | 09:14 |
| lifeless | but we have a more direct measure - the hard timeout | 09:14 |
| persia | really, with the API in place, anything more than ~150 isn't likely to render usefully for anyone. | 09:14 |
| lifeless | so I think we should consider remove it and just timeout if someone tries too much (and programatically ignore the errors) | 09:15 |
| persia | Ah, if the only reason for the limit is to prevent timeouts, yeah, that should be dropped. | 09:15 |
| lifeless | its the only reason i can think of | 09:15 |
| persia | Indeed: helps identify things better that way. | 09:15 |
| lifeless | certainly not aesthetics | 09:15 |
| persia | If there are any other little "um, well, maybe this will make things faster" heuristic limits, those probably ought be removed as well. | 09:15 |
| lifeless | persia: that limit isn't to make it faster; its to prevent bad behaviour - subtle but important difference | 09:16 |
| lifeless | we have other ones with the same characteristics, at different layers, and I'm not [yet] ready to remove them. | 09:16 |
| lifeless | when we're down to 5 seconds, yes. | 09:17 |
| lifeless | but only when we've also got timeout caps on backend tasks | 09:17 |
| lifeless | (which we don't today, partly because they are used to workaround frontend performance issues | 09:17 |
| persia | Used to be I'd regularly review lists of 500-700 bugs with something in common, and perform useful actions as a result of that. Would be nice to get that as a rendered list, rather than having to write my own frontend, but I admit I have somewhat specialised needs. | 09:17 |
| persia | Which reminds me: was something done about the slowness of e.g. loading results 750-825 of 1237? | 09:18 |
| lifeless | persia: the 300 batch size one I support removing happily. | 09:18 |
| lifeless | persia: what slowness? we don't have a report on that atm | 09:18 |
| persia | Well then, next time I have any excuse to do a big bug scan, I'll enable some timers in my browser, and report a bug if there is useful variance: I only have remembered subjective experience, which is useless for diagnostic purposes. | 09:19 |
| lifeless | sure | 09:20 |
| lifeless | if you look in the page source | 09:20 |
| lifeless | there is a time report at the bottom | 09:20 |
| persia | Oh, cool. That makes life easy then. | 09:20 |
| lifeless | thats the time that (for the moment, until that figure is universally healthy) we're using to analyse things. | 09:20 |
| * persia tries to concoct an example | 09:20 | |
| persia | Very snappy indeed: Getting above 1.79 seconds requires more effort than I'm willing to spend at the moment. | 09:25 |
| lifeless | persia: \o/ | 09:26 |
| persia | I did get a 20000 microsecond difference for 0-75 of 637 (+/- 20) vs. 225-300, but that could just be collision with other users. | 09:29 |
| persia | (and I'll remember that other SI modifier any second now) | 09:29 |
| lifeless | ยต ? | 09:29 |
| persia | No, that's the one I remember :p | 09:29 |
| persia | m | 09:29 |
| persia | Anyway, a fifth of a second or so. | 09:30 |
| lifeless | we have quite a lot of noise atm | 09:32 |
| lifeless | basically I'm not analysing anything once a page gets 99% of requests done in < 4 seconds: future work. | 09:32 |
| persia | That's fair. I'll definitely let you know about my next timeout, although I expect it will take some time for me to migrate my work back towards LP. | 09:33 |
| lifeless | persia: fair enough | 09:34 |
| lifeless | persia: anyhow; I think you can see some improvement ;) | 09:34 |
| persia | I see massive improvement. Enough that I'm tempted to try to use it as a tool again. | 09:35 |
| lifeless | cool | 09:35 |
| === Zic_ is now known as Zic | ||
| Kano | hi, i did install of maverick daily now, and i selected sda5 as target, but that stupid installer installed it to the mbr, why= | 10:32 |
| ogra_cmpc | doko, i made it !!! got root on the ac100 | 10:41 |
| persia | ogra, Cool! can you access a bootloader? | 10:42 |
| persia | (or otherwise swap kernels) | 10:42 |
| ogra_cmpc | persia, still trying to find out how to mount the bootloader partition | 10:42 |
| ogra_cmpc | i dont want to swap kernel | 10:42 |
| ogra_cmpc | i want to be able to boot from SD ... the kernel is fine (old though) | 10:43 |
| persia | Sorry: I'm looking at a goal past the goal you mention :) Ideally, be nice to have the SD slot free whilst running Ubuntu :) | 10:43 |
| ogra_cmpc | heh, indeed | 10:44 |
| ogra_cmpc | i only managed to break in right now so i didnt examine much yet | 10:44 |
| persia | But, yeah, alternate booting would get you 90% of the way there. | 10:44 |
| ogra_cmpc | right | 10:44 |
| persia | I'm getting very tempted: it's much faster than a replacement for my Netwalker, and similar price. | 10:45 |
| ogra_cmpc | there is no fstab or anything on android so it seems that everything is done by the bootloader/kernel cmdline | 10:45 |
| persia | Yes. | 10:45 |
| persia | Well, everything at boot time. There's dynamic loading of USB devices for some flavours. | 10:46 |
| ogra_cmpc | the init.rc looks suspiciously like an upstart script | 10:46 |
| persia | Wouldn't surprise me, really. | 10:47 |
| ogra_cmpc | i bet Keybuk would know if they used it | 10:47 |
| zyga | Kano, please report a bug about ubiquity | 10:47 |
| ogra_cmpc | oh ! there is a chroot binary, i should be able to chroot from init to an sd system | 10:48 |
| persia | That won't get you device access :( | 10:49 |
| ogra_cmpc | but a sanee system to work from | 10:50 |
| ogra_cmpc | android is just unusable and painful | 10:51 |
| ogra_cmpc | a shell whete all keys work would be a massive progress already :) | 10:51 |
| persia | Well, true, and then cp lets you get contents back. | 10:52 |
| ogra_cmpc | eventually i'd like to flash a sane fastboot onto it but thats far in the future i think | 10:53 |
| ogra_cmpc | first step is done though :) | 10:53 |
| persia | Excellent. Let me know if you get so you can launch X from the chroot, or ssh into it: either is likely enough to make me want one. | 10:55 |
| mdke | kees: sorry, I don't know anything about how manpages are translated - I guess any translations would come from upstream but I don't know for sure | 11:20 |
| mdke | can I ask someone with permissions to request a translation export of all templates at https://translations.launchpad.net/ubuntu/maverick/+source/ubuntu-docs and send me the link | 11:35 |
| mdke | I think that anyone in ~ubuntu-core-dev should be able to do this | 11:35 |
| mdke | unfortunately due to something screwy about LP's permissions, I can't download these translations even though I can upload this package | 11:35 |
| persia | mdke, You just want the tarball? | 11:37 |
| persia | PO or MO? | 11:37 |
| persia | (also, it doesn't seem to need core-dev: it's some other weird permission) | 11:38 |
| mdke | persia: po tarball would be perfect, thanks | 11:38 |
| persia | LP claims it ought be ~15 minutes. | 11:39 |
| mdke | brilliant, thanks | 11:39 |
| mdke | persia: if you could just msg or email me the link that would be great, I have to pop out now. Thanksa gain | 11:40 |
| wzssyqa | can i request syncing packages from debian? | 13:29 |
| wzssyqa | now, for 10.10 , I am maintainer of these debian packages | 13:31 |
| jpds | wzssyqa: You can use the 'requestsync' script in the ubuntu-dev-tools package. | 13:32 |
| torti | hi. in ubuntu 10.10beta when i install linus-source, extract the .tar.bz2, do "make oldconfig" and "make modules_prepare" before installing the vboxdrv (virtualbox 3.2), the resulting vboxdrv.ko has magicversion 2.6.35.4, thus cannot be loaded since the kernel has 2.6.35-22-generic. is this normal in the beta or is this a bug? | 15:57 |
| torti | /linus/linux/ | 15:57 |
| torti | i think 2.6.35.4 comes from ubuntu's /boot/config-2.6.35-22-generic, because it has: CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.35-22.32-generic 2.6.35.4" | 15:58 |
| ScottK | torti: #ubuntu-kernel is probably a better place to ask. | 16:00 |
| torti | thank you, scott | 16:00 |
| === hanska is now known as dapal | ||
| === dendro-afk is now known as dendrobates | ||
| Chipzz | jpds: you were wrong. He couldn't atm, freeze and all that (cfr topic) | 18:01 |
| ScottK | Chipzz: Depends on what the package is and what the change is. | 18:44 |
| sense | Why would Perl regexes from GTK#'s GAPI2 parser work on the Launchpad build farm, but not on my local installation? Is there any reasonable explanation for that? | 19:25 |
| sense | The same GAPI2 version, the same files, the same string, the same regex. | 19:25 |
| Aemaeth | why wouldn't the blueman applet be chosen over the other bluetooth that was installed? blueman has better support for DUN and equivalent support for the other bluetooth features | 19:49 |
| Aemaeth | ubuntu-one needs an option to backup / and enough to keep settings | 20:44 |
| fagan | Aemaeth: well we are getting oneconf | 20:45 |
| fagan | it backs up app configs | 20:45 |
| fagan | theres no point in backing up / because a lot of it is stuff on the cd and that would take up a hell of a lot of space | 20:45 |
| Aemaeth | i've never claimed my wants were rational | 20:46 |
| fagan | ha | 20:46 |
| Aemaeth | can skip anything that apt can get for you | 20:46 |
| fagan | Well the config files are the most important things to back up | 20:47 |
| Aemaeth | i'm not sure i could keep track of everything i've edited | 20:48 |
| hyperair | hmm so it's ubunutone-etckeeper | 20:48 |
| steve__ | hello all, sorry for the off topic, but is there anyone that could chat to about trouble shooting a ?broken usb drive. Im hoping you may be more than averagely qualified to help) ;) | 20:51 |
| hyperair | try #ubuntu | 20:53 |
| steve__ | hyperair, I have tried #ubuntu... but thanks for the idea. know of any other channels that could help? | 20:54 |
| hyperair | your local ubuntu channel? | 20:54 |
| hyperair | judging from your ip address, i'm assuming #ubuntu-g | 20:55 |
| hyperair | b | 20:55 |
| hyperair | er | 20:55 |
| hyperair | #ubuntu-gb | 20:55 |
| hyperair | i mean #ubuntu-uk | 20:55 |
| popey | yeah, people about in -uk | 20:55 |
| steve__ | hyperair, Good plan, going to my first lug meet soon (finally) so will see if anyone has any ideas. ;) I will have a look see on #ubuntu-uk. Thanks and have a good one | 20:56 |
| hyperair | np | 20:56 |
| === yofel_ is now known as yofel | ||
| Ologn | Digg has this dugg - http://labs.adobe.com/technologies/flashplayer10/ | 21:47 |
| Ologn | That should solve some problems, hopefully | 21:48 |
| penguin42 | Oh that is nice | 22:03 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| === s1aden is now known as sladen | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!