| asac | ScottK: hi. i think micah already talked to you that this was coming :) ... seamonkey 2 is in the queue and chrisccoulson confirmd that its working properly etc. so should be fine. | 01:06 |
|---|---|---|
| ScottK | asac: Yes. We've discussed. What about lightning? | 04:06 |
| micahg | ScottK: chrisccoulson will talk to pitti about it in the morning | 04:09 |
| ScottK | OK | 04:09 |
| ScottK | By the time I wake up tomorrow it'll likely be later than I'm comfortable accepting it, so don't wait on me. | 04:10 |
| micahg | ScottK: we're not uploading for lightning, so either it'll be a binary drop or a source+binary drop | 04:12 |
| ScottK | OK, but IIRC the binary removal requires a publisher run which needs an upload to stimulate it, so don't wait too long. | 04:13 |
| micahg | ScottK: ok, I'll check with pitti before I go to sleep than and let chrisccoulson make the final decision | 04:13 |
| ScottK | They can always sync clamav-data again if they need something to upload. | 04:14 |
| micahg | ScottK: I have a universe package that could use a fix :) | 04:14 |
| ScottK | Tonight I'm still reviewing/accepting. | 04:15 |
| micahg | mediatomb currently has the JS part disabled and someone attached a partial fix | 04:15 |
| ScottK | If stuff is uploaded I'll review it, but that sounds to me like a good SRU candidate. | 04:15 |
| micahg | ScottK: yeah, I was going to leave it for SRU, but if you need an upload :) | 04:16 |
| ScottK | Don't, yet. | 04:16 |
| micahg | ScottK: k, I don't have upload rights anyways ;) | 04:16 |
| ScottK | I've still got one I'm holding back for slangasek in case of emergency. | 04:16 |
| micahg | ScottK: k, sounds good, thanks | 04:16 |
| ajmitch | ScottK: I assume most things should be held for SRU now? | 04:25 |
| ScottK | ajmitch: I'll still take FTBFS and things that it's important to get in. | 04:26 |
| ScottK | But it won't be much longer. | 04:26 |
| ajmitch | OK | 04:26 |
| micahg | ScottK: a sparc FTBFS on seamonkey isn't a big deal is it? (we'll be updating in about 2 weeks) | 04:31 |
| ScottK | micahg: No. Sparc is pretty broken these days. | 04:31 |
| ScottK | Fixing it is preferred, but it would be stunning if there were any sparc seamonkey users. | 04:32 |
| micahg | ScottK: it's a just a disable flag to fix, but since it's pretty broke anyways, I figure we can wait till 2.0.5 | 04:32 |
| ScottK | That's fine. | 04:33 |
| micahg | ScottK: how much longer will you be up? | 04:35 |
| ScottK | Depends on how my headache does. | 04:36 |
| ScottK | An hour or two, probably | 04:36 |
| micahg | ScottK: sorry to hear that, I might try for firegpg FTBFS | 04:36 |
| slangasek | stgraber: the grub2 issue has been triaged off to release notes, no respins for it - it's straightforward to fix in SRU | 05:38 |
| ScottK | slangasek: I'm done reviewing stuff and headed to bed. I didn't yet call a halt to people uploading Universe FTBFS fixes, so please tell them when it's time to stop. I still left you anjsp if you need something. | 05:50 |
| ScottK | I assume it'll be too late in the morning to for me to accept stuff, so I'll leave it to you to review or not. | 05:50 |
| micahg | thanks for firegpg ScottK, I'm trying one more FTBFS | 05:54 |
| pitti | Good morning | 05:55 |
| slangasek | ScottK: well, the mail sent out at https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-April/000705.html said we would cut off universe packages at April 26, so anything else is going to be only if I'm twiddling my thumbs :) | 05:55 |
| * slangasek waves to pitti | 05:55 | |
| ScottK | micahg: I'm heading to bed, so it'll be up to one of the other release team members to approve if they have time. | 05:55 |
| micahg | slangasek: should I not bother with this other FTBFS than? | 05:55 |
| ScottK | slangasek: OK. | 05:55 |
| micahg | *then | 05:55 |
| micahg | ScottK: k, feel better | 05:56 |
| slangasek | micahg: you can - I just can't promise that *I* will have time to review and accept it | 05:56 |
| micahg | pitti: chrisccoulson will be chatting with you later, but I figured that I'd prime the pump so to speak, WRT lightning-sunbird, we're not sure if we should drop some of the binaries that wouldn't be updated with an SRU or to drop the whole package | 05:57 |
| micahg | slangasek: nevermind, the FTBFS is too much for me at this hour | 06:00 |
| pitti | micahg: if the current one is unsupportable, then we should perhaps drop the entire package? I remember a discussion about updating it to 2.0? | 06:04 |
| micahg | pitti: well, the problem with that one is that upstream is only continuing development of a piece of it | 06:17 |
| slangasek | ev, cjwatson: bug #570843 is odd, not sure why this would be turning up so late when we know lucid has already been tested in networked-but-not-really environments before now | 06:18 |
| ubottu | Launchpad bug 570843 in ubiquity "[Lucid Lynx RC] Install hangs on a LAN-connected (but no internet) workstation" [Undecided,New] https://launchpad.net/bugs/570843 | 06:18 |
| pitti | micahg: I'm not a big fan of just removing some binaries of a source; I don't remember a precedent for this, and don't know what could go wrong in soyuz for that | 06:22 |
| pitti | micahg: so I'd actually prefer an upload which properly drops those packages, or just remove it completely if it doesn't break (too many) rdepends | 06:22 |
| micahg | pitti: k, then we'll probably remove then chrisccoulson can confirm in a few hours | 06:22 |
| pitti | thanks | 06:22 |
| ara | morning! | 06:50 |
| kirkland | slangasek: got your response on https://bugs.edge.launchpad.net/ubuntu/+source/etherboot/+bug/570870 ... what about motu-sru ... still the same? | 06:53 |
| ubottu | Ubuntu bug 570870 in etherboot "pxe boot doesn't work with kvm" [Low,In progress] | 06:53 |
| kirkland | slangasek: or is that merged with ubuntu-sru too? | 06:53 |
| pitti | oh, how was the sparc kde issue sorted out? http://people.canonical.com/~ubuntu-archive/component-mismatches.txt lost all its vpn stuff | 06:53 |
| pitti | I approved/promoted the texinfo-doc-nonfree MIR, so that'll be gone soon, too | 06:54 |
| pitti | kirkland: it's just ubuntu-sru now | 06:54 |
| kirkland | pitti: thanks | 06:55 |
| slangasek | pitti: per-arch binary removal :/ the kde failure has mysql-dfsg-5.1 at its root, and doesn't seem tractable - cjwatson gave it a try yesterday | 07:20 |
| slangasek | KDE is entirely uninstallable on sparc right now anyway, so I didn't feel bad about doing the binary removal | 07:21 |
| pitti | slangasek: ah, ok; I thought as much, thanks for confirming | 07:21 |
| pitti | the sparc users will be furious! | 07:21 |
| pitti | . o O { both of them! } *cough* | 07:22 |
| Jeeves_ | :) | 07:24 |
| ev | slangasek: fingers crossed that he was using the RC and not a daily | 09:06 |
| ev | it sounds like it might be bug 567749, which we fixed post-RC | 09:06 |
| ubottu | Launchpad bug 567749 in ubiquity "Broken packages during oem-config" [Undecided,Fix released] https://launchpad.net/bugs/567749 | 09:06 |
| ev | erm, nevermind. He wasn't using oem-config. | 09:06 |
| ev | trying to reproduce now | 09:12 |
| ara | Riddell, around? | 10:05 |
| Riddell | ara: hola | 10:26 |
| Riddell | ara: grub always says "Ubuntu" to answer your question from yesterday | 10:27 |
| ara | Riddell, ok, thanks. Another one :) | 10:27 |
| ara | Kubuntu Netbook, when installed in English I get "Konqueror" "KMail" "System Settings" and "Home" in Bookmarks | 10:28 |
| ara | but, when installed in Spanish, I only get the first three items | 10:28 |
| ara | (not Home) | 10:28 |
| Riddell | that'll be a beastie | 10:30 |
| * ogra sees the headlines already "No home for that spanish in ubuntu !!!" | 10:31 | |
| ogra | *the | 10:31 |
| ara | hehee | 10:32 |
| asac | ScottK: i dont think he has time to do it ... but in case: killing sunbird and just keeping lighting is ok from my pov | 10:34 |
| asac | not perfect, but better than killing it completely. | 10:34 |
| Riddell | ara: it's patch kubuntu_105_netbook_favourites.diff which adds that, although I think that patch is upstream now. file a bug on kdebase-workspace anyway | 10:38 |
| ara | Riddell, ok, will do, thanks | 10:40 |
| slangasek | cjwatson: bug #567592 | 11:04 |
| ubottu | Launchpad bug 567592 in plymouth "rm: cannot remove `/var/lib/urandom/random-seed': Read-only file system" [Undecided,New] https://launchpad.net/bugs/567592 | 11:04 |
| smoser | lool, ttx , cjwatson , ttx tells me of mountall issue ? | 11:10 |
| cjwatson | lool and I have been trying to run the UEC image under kvm (alone, not via eucalyptus) | 11:10 |
| cjwatson | I understand this isn't the usual path, so I don't think there's any cause for panic if your usual tests are passing | 11:11 |
| cjwatson | however it did show up an issue or two in plymouth | 11:11 |
| ttx | smoser: we were wondering if those could be the source of some of the racy behavior of the images under uec | 11:11 |
| smoser | is there backscroll i should read? | 11:12 |
| cjwatson | specifically attaching to the session fails if you don't have an initramfs, and if you're then also running the details plugin then plymouth crashes | 11:12 |
| ttx | smoser: no, the discussion was live so far :) | 11:12 |
| smoser | ok. so you have modified /etc/fstab in the image ? | 11:13 |
| smoser | it has hard coded /dev/sda1 as root filesystem | 11:13 |
| smoser | never mind that. | 11:14 |
| cjwatson | -append "root=/dev/sda" | 11:14 |
| cjwatson | didn't touch /etc/fstab | 11:14 |
| smoser | yeah, but mountall still gets all upset on /etc/fstab | 11:14 |
| smoser | when /dev/sda1 is never going to appear | 11:14 |
| smoser | so filesystems event is never going to fire (... i think ... this is memory of a while ago) | 11:15 |
| cjwatson | smoser: I understand that the setup I have is going to break for other reasons :) | 11:16 |
| cjwatson | so I don't think it's a UEC blocker of any kind | 11:16 |
| cjwatson | smoser: but having run into this problem I've been trying to assess what its impact would be outside UEC | 11:16 |
| cjwatson | at the moment, I think that the answer is that server boots with no initramfs and without the 'splash' argument are broken | 11:17 |
| smoser | broken how ? | 11:17 |
| smoser | because instances boot that way both on ec2 and uec | 11:17 |
| smoser | oh. if youre running the details plugin. i see. which (i guesss?) is not running in our instances by default. | 11:19 |
| smoser | cjwatson, ^^ | 11:19 |
| cjwatson | details plugin happens if you boot without 'splash' | 11:20 |
| cjwatson | my suspicion is that you just don't notice problems because you're running headless :) | 11:20 |
| ttx | there are some scary messages appearing on the get-console-output, nevertheless | 11:21 |
| cjwatson | certainly to some extent I'm only seeing this because mountall needs to ask questions due to other bugs | 11:21 |
| cjwatson | smoser: and FWIW the problem I'm debugging here is the same segfault you reported in https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/567592/comments/3, so I do not believe that you are not seeing it at all :-) | 11:21 |
| ubottu | Ubuntu bug 567592 in plymouth "rm: cannot remove `/var/lib/urandom/random-seed': Read-only file system" [Undecided,New] | 11:21 |
| smoser | ah. i see. | 11:21 |
| smoser | yes, we dont see stuff lke "starting" | 11:22 |
| smoser | or "started" | 11:22 |
| cjwatson | ah, though to be fair you were triaging hggdh's bug | 11:22 |
| smoser | i can point you at ec2 logs if you're interested. | 11:22 |
| cjwatson | starting/started are only meaningful terms in conjunction with a job name | 11:22 |
| cjwatson | not really, laser-focusing on this bug :-) | 11:22 |
| cjwatson | I don't want to get sucked into debugging ec2 in general | 11:22 |
| smoser | ok. so yeah, i would say that we're in trouble if plymouth wants to promt the user for information on uec/ec2. | 11:23 |
| slangasek | we would be anyway | 11:24 |
| slangasek | that's not a bug in plymouth, that's a failure to boot the UEC image correctly | 11:24 |
| cjwatson | right, but leaving UEC aside, a server boot without initramfs looks like it'll fail if it needs to prompt | 11:25 |
| * slangasek nods | 11:25 | |
| cjwatson | right now, I'm trying to figure out why it's prompting for /tmp | 11:25 |
| slangasek | as far as release noting, this should probably be tacked onto https://wiki.ubuntu.com/LucidLynx/ReleaseNotes#Changes%20in%20boot-time%20output%20on%20Ubuntu%20Server | 11:26 |
| smoser | an initramfs-less install outside of ec2/euc instances is not really something that is supported. | 11:27 |
| smoser | right? already it means the user is using a custom kernel | 11:27 |
| cjwatson | my understanding from Keybuk is that that is false | 11:27 |
| cjwatson | it's not a default Ubuntu installation, sure, but it's not an uncommon thing for people to want to do and it's something we want to support | 11:27 |
| smoser | which, obviously should be supported, but if they're rolling their own kernel then they can just roll it with an initramfs. | 11:27 |
| cjwatson | in the sense of "make not hideously fail", not in the sense of "accept paid support calls" | 11:28 |
| ttx | cjwatson: ok | 11:28 |
| ttx | so we are in agreement that this precise issue doesn't change anything fro UEC users | 11:28 |
| ttx | though supporting no-initramfs + no-splash would be good to have. | 11:29 |
| ttx | (for server generally) | 11:29 |
| smoser | fwiw, it was a pain to get "no-initramfs" working in ec2/uec. | 11:30 |
| smoser | we ran into several bumps in the road causing that feature to wobble back and forth | 11:30 |
| cjwatson | I realise that | 11:31 |
| cjwatson | the server in general is simpler though | 11:31 |
| lool | sorry was in a call | 11:37 |
| smoser | i dont necissarily think that the server is a simpler case. ec2/uec has the "single set of hardware" simple-ness. ie, console is serial, network driver is X... its all known and explicitly supported. | 11:44 |
| ttx | slangasek: should I add bug 557429 to the release notes targets ? | 11:44 |
| ubottu | Launchpad bug 557429 in mdadm "array with conflicting changes is assembled with data corruption/silent loss" [High,Triaged] https://launchpad.net/bugs/557429 | 11:44 |
| cjwatson | smoser: *shrug* by simpler I was referring to the fact that it doesn't tend to have a set of complicated and delicate upstart jobs. anyway, it's something we should make work, and in most cases it is not that hard. I don't think it's release-critical or anything. | 11:46 |
| cjwatson | that is, simpler in userspace. | 11:46 |
| smoser | fwiw, i do hope on maverick, what you were attempting (booting in "stock kvm") will be much better supported and ideally "just work" | 11:50 |
| cjwatson | well what I'm trying to do here is to contribute to that, not just complain! :-) | 11:51 |
| ogra | slangasek, are all your rebuilds done already ? seems ports -server is still old | 11:52 |
| slangasek | ogra: I'll do ports builds shortly | 11:54 |
| ogra | thanks | 11:54 |
| ogra | i still have a netinst running so no hurry | 11:55 |
| slangasek | ttx: 557429> eh? already has a release notes task ): | 11:55 |
| ttx | arh | 11:55 |
| ttx | slangasek: I missed it. I guess I need another massage | 11:56 |
| ttx | sorry for the noise | 11:56 |
| smoser | cjwatson, yeah, i didn't think you were just complaining. was just saying, i hope that in maverick this test , your running of the instance would have worked better than it did. (ie, wouldnh't have failed to get to 'filesystems' event) | 13:11 |
| === rgreening_ is now known as rgreening | ||
| cjwatson | smoser: what specifically is planned for maverick in this regard? | 13:20 |
| cjwatson | I'd expect most of the work to be essentially in the foundations arena, and to be bug-fixes | 13:20 |
| slangasek | smoser: I see published-ec2-release.txt, which should tell me that you've pre-published these to EC2 for final release, yes? | 13:50 |
| smoser | yes. | 13:51 |
| slangasek | great, thanks! | 13:51 |
| pitti | slangasek: did you accept linux lucid-proposed, or did I screw up with my langpack accept? | 14:33 |
| slangasek | pitti: that was me | 14:33 |
| pitti | ok, thanks | 14:34 |
| slangasek | did it specifically before asking you about langpacks :) | 14:34 |
| pitti | ok, langpacks flushed | 14:34 |
| pitti | https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1 is useful again, yay! | 14:34 |
| ScottK | And queuediff too (it was timing out for me) | 14:34 |
| doko_ | slangasek: llvm, clang and llvm-gcc-4.2 all in the queue. let me know if I have to reupload to -proposed =) | 14:57 |
| slangasek | doko_: odds are better if you can get a member of the release team *other* than me to review it... | 15:02 |
| * pitti reviews | 15:07 | |
| doko_ | slangasek: ok. thanks pitti | 15:07 |
| pitti | doko_: oh, clang looks easy :) 50 line diff | 15:09 |
| doko_ | pitti: llvm has to go first, clang b-d on it | 15:09 |
| pitti | okay | 15:09 |
| doko_ | pitti: the b-d's are correctly set, so you could accept all at once after review | 15:13 |
| pitti | doko_: I'm though with all three; diffs are very small, nice | 15:13 |
| doko_ | pitti: cool, thanks! | 15:13 |
| * pitti reviews the other stragglers while he's at it | 15:13 | |
| doko_ | now a working jit for the powerpc jvm | 15:14 |
| pitti | slangasek: ok, I accepted two more universe packages (simple FTBFS); for the remaining ones, xsane is on ubuntustudio and wine1.0 might take too long to build | 15:21 |
| pitti | oh, and wine is on u-studio, too | 15:22 |
| pitti | oops, that was 1.2 | 15:22 |
| pitti | the wine1.0 diff looks reasonable | 15:22 |
| slangasek | pitti: did you leave the one in there that ScottK was leaving in case we needed to provoke a publisher run? | 15:22 |
| pitti | I didn't see that, sorry | 15:23 |
| slangasek | no worries, just means we'll do it by hand if necessary :) | 15:23 |
| pitti | if we need one, I can find/fix another universe FTBFS | 15:23 |
| slangasek | ok | 15:23 |
| pitti | sorry if one was deliberately held | 15:23 |
| pitti | wine1.0 would actually be suitable; takes 30 mins to build on i386/amd64, no other arches | 15:24 |
| * slangasek nods | 15:24 | |
| ogra | thats a shame ! | 15:24 |
| * pitti needs to run now, about an hour | 15:24 | |
| * ogra wants wine on ARM !!! | 15:24 | |
| slangasek | ogra: talk to me in 4 months | 15:25 |
| ogra | slangasek, lol ... | 15:25 |
| slangasek | maybe I'll have something for you then | 15:25 |
| ogra | slangasek, like the famous wince emu in wine on ARM ? *g* | 15:25 |
| slangasek | er, probably not that | 15:25 |
| ogra | heh | 15:25 |
| ogra | i doubt you can port it to arm | 15:26 |
| ogra | but who knows | 15:26 |
| slangasek | no, I'm not going to port it to arm | 15:26 |
| lamont | ogra: I'd recommend a red wine for ARM. | 15:32 |
| ogra | yummy ... | 15:32 |
| * ogra has plenty boxes with rioja in the cellar... i should try that | 15:33 | |
| ogra | rioja with a bagel board :) | 15:34 |
| === bjf is now known as elBoto | ||
| === elBoto is now known as bjf | ||
| Riddell | slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/akonadi/+bug/564263 should be release noted if you're collecting them | 16:52 |
| ubottu | Launchpad bug 564263 in akonadi ""No resource agents found" error when starting for the first time" [Undecided,Confirmed] | 16:52 |
| slangasek | Riddell: got it - you can just add an ubuntu-release-notes task to bugs, fwiw | 16:54 |
| ogra | wohoo | 16:56 |
| ogra | so its possible to do an ubuntu-netbook install with netinst | 16:56 |
| ogra | it only takes 6h ! | 16:56 |
| ogra | (on omap) | 16:57 |
| ogra | ok, on to server image testing | 17:05 |
| ogra | slangasek, ^^^ omap netinst is good | 17:06 |
| slangasek | alrighty | 17:06 |
| slangasek | cjwatson: can I get a second opinion on https://bugs.launchpad.net/ubuntu-release-notes/+bug/546245 ? | 17:41 |
| ubottu | Launchpad bug 546245 in ubuntu-release-notes "warn about using ubuntu with md raid (unreliable raid config)" [Undecided,New] | 17:41 |
| ttx | jjohansen: so should we have a release note about how crappy ext4 can be and suggesting the use of ext3 ? | 18:27 |
| cjwatson | there's already a release note task about the dpkg performance problems | 18:27 |
| ttx | yes, I'd say that's enough -- but jib and jjohansen were discussing a more generic warning | 18:28 |
| jiboumans | it's not just intsallation taking longer | 18:28 |
| jiboumans | it's actual service performance after installation | 18:28 |
| cjwatson | have we run our server tests with ext3? | 18:29 |
| jjohansen | ttx: well yes we could do that | 18:29 |
| jiboumans | cjwatson: we know why ext4 is slower than ext3 and there's a benchmark available publicly that shows it | 18:29 |
| cjwatson | I'm not sure that answers my question ... | 18:29 |
| ttx | jiboumans: I'd argue that you should choose your FS based on your workload, so unless ext3 beats ext4 on most scenarios, it's difficult to write that in release notes | 18:29 |
| ttx | cjwatson: the answer is no | 18:29 |
| jjohansen | I was talking to psurbi and she hasn't done anything more with it lately. Its still basically the same cases | 18:29 |
| jiboumans | cjwatson: we dont have numbers no | 18:30 |
| jjohansen | jiboumans: yes sort of, that isn't a great benchmark | 18:30 |
| cjwatson | jiboumans: I wasn't asking for numbers | 18:30 |
| cjwatson | jiboumans: I was asking for server validation with ext3, just as we're doing validation with ext4 | 18:30 |
| cjwatson | anyway, I think "ext4 is slower than ext3" is too simplistic | 18:30 |
| cjwatson | we should have a release note, but it needs to be in slightly more depth than that | 18:30 |
| jiboumans | cjwatson: agreed | 18:31 |
| jiboumans | i'm not attached to any wording, but i want to make it clear you have ext4 by default and what that may mean | 18:31 |
| cjwatson | for example I recall the kernel team switching to ext4 in droves at one point upon realising that its unlink was much faster orsome such | 18:31 |
| cjwatson | *or some | 18:31 |
| ttx | A "pick your FS wisely" section warning on advantages/drawbacks of each ? | 18:32 |
| cjwatson | "File system selection" perhaps | 18:32 |
| cjwatson | it could note that btrfs won't work yet :-) | 18:32 |
| jiboumans | i'm happy with our choice of default, but only if we point out why we picked it | 18:32 |
| ttx | Who would know the issue well enough to be able to draft that ? | 18:32 |
| jiboumans | i suggest 'data safety' | 18:33 |
| cjwatson | that sounds inappropriate? it's not a safety issue | 18:33 |
| jiboumans | cjwatson: sorry, multitasking and not phrasing myself well | 18:33 |
| cjwatson | I can draft some of it, as it relates to installation | 18:34 |
| cjwatson | I'm not convinced that I can draft the whole thing well | 18:34 |
| cjwatson | so perhaps I can tag-team on it with somebody else | 18:34 |
| ttx | I wouldn't phrase it "data safety or performance" | 18:35 |
| ttx | but rather "performance on workload A vs. perf on workload B" | 18:35 |
| ttx | that highlights the best practice of doing that perf test yourself before choosing | 18:36 |
| ttx | jjohansen: anyone in kernel that would know this issue particularly well that could help Colin ? | 18:37 |
| cjwatson | do we have enough information to write a note like that at this point? | 18:37 |
| jiboumans | in short, disk reads/writes seem slower compared to 8.04 and whinging will happen if we dont disclose | 18:37 |
| pitti | jiboumans: in dpkg, certainly not in general? | 18:37 |
| cjwatson | I think that's too short. I haven't seen evidence that actual disk read/write throughput is much slower. Isn't the issue regarding write *barriers*, which is a slightly different matter? | 18:37 |
| jiboumans | pitti: in general according to the benchmarks we've seen | 18:38 |
| jiboumans | this is what i refer to: http://www.phoronix.com/scan.php?page=article&item=ubuntu_lts_perf&num=2 | 18:38 |
| cjwatson | (poorly-explained phoronix benchmarks aren't evidence here) | 18:38 |
| pitti | subjectively my system feels not slower, rather a bit faster with ext4 | 18:38 |
| jjohansen | ttx, cjwatson: it was csurbi who looked into it and did some benchmarking | 18:38 |
| jiboumans | other than that, anecdotal only | 18:38 |
| pitti | especially with things like large rm -r, fsck, and reading of files | 18:38 |
| jiboumans | 'we are not using ext4 as it doenst perform as well as X' | 18:38 |
| jiboumans | where X isn't necessarily ext3 | 18:38 |
| cjwatson | I've read the article, I'm not entirely sure I believe it without more of a microbenchmark. I'm aware of certain things that will be much slower in ext4 and static web pages weren't one of them. Perhaps something to do with log file writes? | 18:39 |
| pitti | please don't generalize from dpkg to overall behaviour? | 18:39 |
| cjwatson | if apache is fsyncing its log file, that would explain it | 18:39 |
| cjwatson | although it would be a bit odd! | 18:39 |
| jjohansen | jiboumans: right, well that doesn't even cover ext3 on the same OS version, a lot more than ext4 has changed | 18:39 |
| jiboumans | pitti: i'm not. this is from my friends & network in operations | 18:39 |
| cjwatson | release notes really need to be evidence-based and not rumour-based | 18:40 |
| jiboumans | cjwatson: it's not a rumour | 18:40 |
| jiboumans | 'we did the benchmarks and we picked X instead' | 18:40 |
| cjwatson | where's the science in that phoronix article? | 18:40 |
| cjwatson | where's the method? | 18:40 |
| jjohansen | right, the are cases where it doesn't perform as well, this is known | 18:41 |
| jiboumans | i dont have those numbers or specifics. the only thing public i can point at is that article | 18:41 |
| jiboumans | jjohansen: this is known to...? | 18:41 |
| jiboumans | everyone upgrading from 8.04? | 18:41 |
| cjwatson | without method, it's rumour | 18:41 |
| jjohansen | jiboumans: the developers | 18:41 |
| cjwatson | we know of certain things that aren't rumour | 18:41 |
| cjwatson | we should stick to those for the time being | 18:41 |
| jjohansen | they have been working on stability and other issues first | 18:41 |
| jiboumans | cjwatson: again, not caring about the specifics here. i'm only addressing pitti who said 'only for dpkg, right?' | 18:41 |
| jjohansen | they know there are some corner cases | 18:42 |
| jiboumans | jjohansen: i care about the people installing it and making sure they're not surprised, or that there's any FUD around our default | 18:42 |
| cjwatson | jiboumans: do we care about the specifics for the release note, or not? | 18:42 |
| jiboumans | cjwatson: sure | 18:42 |
| jiboumans | pick any specifics you want to include | 18:42 |
| cjwatson | you're saying "disk reads/writes seem slower", and I'm saying that we should not be specific about the operations that are slower unless we have evidence | 18:42 |
| cjwatson | I agree it isn't just dpkg; that's merely the situation where we have most immediate evidence | 18:43 |
| jiboumans | cjwatson: i think you're mixing up my conversation with you to point out my concerns with my suggested text for the release notes | 18:43 |
| jjohansen | jiboumans: understood | 18:43 |
| cjwatson | I hadn't actually seen any suggested text yet :-) | 18:43 |
| cjwatson | all I'm saying is that we shouldn't just say "it sucks, use ext3" on the basis of phoronix :-) | 18:44 |
| jiboumans | cjwatson: we violently agree | 18:44 |
| cjwatson | jiboumans: ok, good :) | 18:46 |
| cjwatson | I have a bit of a thing about phoronix I'm afraid - I've seen some pretty disgracefully bad things masquerading as science there (complete unawareness of statistical significance), so I tend to have a negative knee-jerk reaction to them | 18:47 |
| jiboumans | cjwatson: appreciated. it's unfortunately the only public thing i can point at =/ | 18:48 |
| cjwatson | I think it would be interesting to time ext4 with write barriers turned off, and possibly ext3 with write barriers turned on | 18:50 |
| cjwatson | the most recent hypothesis is that that's the specific property that changes dpkg's performance characteristics between ext3 and ext4 | 18:50 |
| cjwatson | it would further be interesting to know what difference that makes to phoronix' benchmarks | 18:51 |
| cjwatson | apache2 doesn't appear to be using fsync or fdatasync | 18:56 |
| cjwatson | unless it's wrapped up in something outside the apache2 source | 18:57 |
| cjwatson | ah, separate library source | 18:57 |
| cjwatson | still not seeing any references from C code though | 18:58 |
| cjwatson | so I think it would be a good idea to further analyse where the apache slowness is coming from | 18:59 |
| cjwatson | is anyone able to take that on? | 18:59 |
| cjwatson | I've started a benchmark run in kvm, with the aim of comparing installation time with and without write barriers | 19:05 |
| cjwatson | kvm probably isn't a great benchmark for this but it's better than nothing | 19:05 |
| jjohansen | cjwatson: I can kick it off on real hardware. Which installer are you using? | 19:13 |
| cjwatson | server | 19:16 |
| cjwatson | there's nothing built-in to disable barriers - you'd have to edit /lib/partman/mount.d/70ext3 before starting the partitioner to get it to do that | 19:17 |
| cjwatson | actually no, make that /lib/partman/fstab.d/ext3 | 19:18 |
| cjwatson | and unless you can be bothered to preseed everything, probably best to just compare times of the base-installer and pkgsel segments from syslog | 19:19 |
| jjohansen | okay, I'll give it a run | 19:19 |
| harmoney | Food time for Londoners. | 19:24 |
| === bjf is now known as bjf[afk] | ||
| lool | Riddell: heya; is LP #564263 still present and worth a release note? Would you have some sample text? | 21:54 |
| ubottu | Launchpad bug 564263 in akonadi ""No resource agents found" error when starting for the first time" [Undecided,Confirmed] https://launchpad.net/bugs/564263 | 21:54 |
| Riddell | lool: yes we'd like a release note for that | 22:04 |
| Riddell | "Akonadi startup is sometimes faulty preventing access to the addressbook and other resources, close and restart Kontact when this happens to work around" | 22:05 |
| lool | Riddell: thanks | 22:18 |
| cjwatson | FWIW disabling write barriers shows no obvious improvement in kvm (and actually seems to disimprove the pkgsel stage, though it's possible my system was just a bit busier) | 22:21 |
| lool | cjwatson: At the ext4 or kvm backend level? | 22:27 |
| lool | ScottK: release notes task for LP #290153 seems to have been opened a long time ago, and I understand that the scope of the problem is smaller now, since the systems actually boot albeit slowly; so I'm closing the task, but please reopen if it necessary | 22:28 |
| ubottu | Launchpad bug 290153 in linux "Fails to find boot device in Intel D945Gnt" [High,Confirmed] https://launchpad.net/bugs/290153 | 22:28 |
| slangasek | - | 22:29 |
| cjwatson | lool: where I disabled write barriers? I mounted the ext4 file system with barriers=0 | 22:47 |
| cjwatson | er barrier=0 | 22:47 |
| lool | slangasek: LP #470776 still an issue in final? cjwatson seemed to think it might be fixed now with the latest lucid packages | 22:53 |
| ubottu | Launchpad bug 470776 in mountall "retry remote devices when parent is ready after SIGUSR1" [Medium,Fix released] https://launchpad.net/bugs/470776 | 22:53 |
| lool | slangasek: That is, the part which relates to the mount.nfs errors reaching the console | 22:53 |
| === bjf[afk] is now known as bjf | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!