[01:06] <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.
[04:06] <ScottK> asac: Yes.  We've discussed.  What about lightning?
[04:09] <micahg> ScottK: chrisccoulson will talk to pitti about it in the morning
[04:09] <ScottK> OK
[04:10] <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:12] <micahg> ScottK: we're not uploading for lightning, so either it'll be a binary drop or a source+binary drop
[04:13] <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:14] <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:15] <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:16] <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:25] <ajmitch> ScottK: I assume most things should be held for SRU now?
[04:26] <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:31] <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:32] <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:33] <ScottK> That's fine.
[04:35] <micahg> ScottK: how much longer will you be up?
[04:36] <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
[05:38] <slangasek> stgraber: the grub2 issue has been triaged off to release notes, no respins for it - it's straightforward to fix in SRU
[05:50] <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:54] <micahg> thanks for firegpg ScottK, I'm trying one more FTBFS
[05:55] <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:56] <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:57] <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
[06:00] <micahg> slangasek: nevermind, the FTBFS is too much for me at this hour
[06:04] <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:17] <micahg> pitti: well, the problem with that one is that upstream is only continuing development of a piece of it
[06:18] <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:22] <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:50] <ara> morning!
[06:53] <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] <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:54] <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:55] <kirkland> pitti: thanks
[07:20] <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:21] <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:22] <pitti> . o O { both of them! } *cough*
[07:24] <Jeeves_> :)
[09:06] <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] <ev> erm, nevermind.  He wasn't using oem-config.
[09:12] <ev> trying to reproduce now
[10:05] <ara> Riddell, around?
[10:26] <Riddell> ara: hola
[10:27] <Riddell> ara: grub always says "Ubuntu" to answer your question from yesterday
[10:27] <ara> Riddell, ok, thanks. Another one :)
[10:28] <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:30] <Riddell> that'll be a beastie
[10:31]  * ogra sees the headlines already "No home for that spanish in ubuntu !!!"
[10:31] <ogra> *the
[10:32] <ara> hehee
[10:34] <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:38] <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:40] <ara> Riddell, ok, will do, thanks
[11:04] <slangasek> cjwatson: bug #567592
[11:10] <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:11] <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:12] <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:13] <smoser> ok. so you have modified /etc/fstab in the image ?
[11:13] <smoser> it has hard coded /dev/sda1 as root filesystem
[11:14] <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:15] <smoser> so filesystems event is never going to fire (... i think ... this is memory of a while ago)
[11:16] <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:17] <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:19] <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:20] <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:21] <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] <smoser> ah. i see.
[11:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <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:29] <ttx> though supporting no-initramfs + no-splash would be good to have.
[11:29] <ttx> (for server generally)
[11:30] <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:31] <cjwatson> I realise that
[11:31] <cjwatson> the server in general is simpler though
[11:37] <lool> sorry was in a call
[11:44] <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:46] <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:50] <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:51] <cjwatson> well what I'm trying to do here is to contribute to that, not just complain! :-)
[11:52] <ogra> slangasek, are all your rebuilds done already ? seems ports -server is still old
[11:54] <slangasek> ogra: I'll do ports builds shortly
[11:54] <ogra> thanks
[11:55] <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:56] <ttx> slangasek: I missed it. I guess I need another massage
[11:56] <ttx> sorry for the noise
[13:11] <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:20] <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:50] <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:51] <smoser> yes.
[13:51] <slangasek> great, thanks!
[14:33] <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:34] <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:57] <doko_> slangasek: llvm, clang and llvm-gcc-4.2 all in the queue. let me know if I have to reupload to -proposed =)
[15:02] <slangasek> doko_: odds are better if you can get a member of the release team *other* than me to review it...
[15:07]  * pitti reviews
[15:07] <doko_> slangasek: ok. thanks pitti
[15:09] <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:13] <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:14] <doko_> now a working jit for the powerpc jvm
[15:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:32] <lamont> ogra: I'd recommend a red wine for ARM.
[15:32] <ogra> yummy ...
[15:33]  * ogra has plenty boxes with rioja in the cellar... i should try that
[15:34] <ogra> rioja with a bagel board :)
[16:52] <Riddell> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/akonadi/+bug/564263 should be release noted if you're collecting them
[16:54] <slangasek> Riddell: got it - you can just add an ubuntu-release-notes task to bugs, fwiw
[16:56] <ogra> wohoo
[16:56] <ogra> so its possible to do an ubuntu-netbook install with netinst
[16:56] <ogra> it only takes 6h !
[16:57] <ogra> (on omap)
[17:05] <ogra> ok, on to server image testing
[17:06] <ogra> slangasek, ^^^ omap netinst is good
[17:06] <slangasek> alrighty
[17:41] <slangasek> cjwatson: can I get a second opinion on https://bugs.launchpad.net/ubuntu-release-notes/+bug/546245 ?
[18:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <ttx> that highlights the best practice of doing that perf test yourself before choosing
[18:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:46] <cjwatson> jiboumans: ok, good :)
[18:47] <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:48] <jiboumans> cjwatson: appreciated. it's unfortunately the only public thing i can point at =/
[18:50] <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:51] <cjwatson> it would further be interesting to know what difference that makes to phoronix' benchmarks
[18:56] <cjwatson> apache2 doesn't appear to be using fsync or fdatasync
[18:57] <cjwatson> unless it's wrapped up in something outside the apache2 source
[18:57] <cjwatson> ah, separate library source
[18:58] <cjwatson> still not seeing any references from C code though
[18:59] <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?
[19:05] <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:13] <jjohansen> cjwatson: I can kick it off on real hardware.  Which installer are you using?
[19:16] <cjwatson> server
[19:17] <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:18] <cjwatson> actually no, make that /lib/partman/fstab.d/ext3
[19:19] <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:24] <harmoney> Food time for Londoners.
[21:54] <lool> Riddell: heya; is LP #564263 still present and worth a release note?  Would you have some sample text?
[22:04] <Riddell> lool: yes we'd like a release note for that
[22:05] <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:18] <lool> Riddell: thanks
[22:21] <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:27] <lool> cjwatson: At the ext4 or kvm backend level?
[22:28] <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:29] <slangasek> -
[22:47] <cjwatson> lool: where I disabled write barriers?  I mounted the ext4 file system with barriers=0
[22:47] <cjwatson> er barrier=0
[22:53] <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] <lool> slangasek: That is, the part which relates to the mount.nfs errors reaching the console