[00:02] <apachelogger> JontheEchidna, txwikinger, lex79: do you have time for a bug triage week sometime soon? (next week?)
[00:02] <JontheEchidna> sure
[00:02] <lex79> I'm out for two weeks since next monday, I will go to Hamburg :)
[00:05] <apachelogger> Riddell: I'll try to get libcouchdb-qt && a not yet existing desktopcouch overlay for it ;) && the addressbook resource to alpha for next week ... though that has the same problem as the other stuff (gnome-keyring dependent) ... also for some reason I do not think that we will see a not-gnome-keyring dependent ubuntuone-syncdaemon any time soon :/
[00:06] <Riddell> apachelogger: what is that reason?
[00:06] <apachelogger> lex79: cool, vacation? :)
[00:06] <apachelogger> Riddell: no progress on the u1 side of things
[00:07] <apachelogger> gotta do some poking again
[00:07] <Riddell> apachelogger: you're a core dev, you could just upload the package with the patch :)
[00:07] <apachelogger> well, my patch does s/gnome-keyring/kwallet, so it is not any better ;)
[00:08] <lex79> apachelogger: yes, meet my girlfriend, she is in Erasmus but come back to home in Italy in August :)
[00:08] <apachelogger> come to think of it, I could just deploy a patched syncdaemon in the u1-kde ppa
[00:08] <JontheEchidna> bleh, filter by origin has boogs
[00:08]  * apachelogger really needs to do an alpha to get some feedback :)
[00:08] <JontheEchidna> my assumptions were wrong :(
[00:09] <apachelogger> lex79: brilliant, have fun :D
[00:09] <lex79> thanks :P
[00:10] <apachelogger> JontheEchidna: you know... assumptions are like workarounds ... ;) ;)
[00:10] <Riddell> apachelogger: can't you write a patch for syncdaemon which does the right thing depending on the desktop?
[00:10] <apachelogger> well, I could look into it
[00:11] <apachelogger> python-keyring is supposed to do that anyway
[00:11] <apachelogger> (i.e. provide a desktop-independent API)
[00:12] <Riddell> the new freedesktop standard for it is also under way
[00:12] <apachelogger> not implemented in KDE though :/
[00:12] <Riddell> but in the team time, I'd just do a if env(KDE_FULL_SESSION):
[00:12] <Riddell> mean time
[00:12] <Riddell> sheesh
[00:12] <JontheEchidna> Aha!
[00:12] <JontheEchidna> When iterating over a QHash, the items are arbitrarily ordered. With QMap, the items are always sorted by key.
[00:12] <JontheEchidna> ^from Qt docs, that explains my bug
[00:12] <maco> Riddell: sleep time now?
[00:12] <Riddell> maco: yes
[00:13] <JontheEchidna> Oh, wait, they're out of order before I put them in the hash
[00:13] <apachelogger> Riddell: do you want me to give more priority to getting a working UI or the raw essentials of akonadi foo?
[00:13] <JontheEchidna> :/
[00:13] <Riddell> although Kubuntu should do a takeover of #ubuntu-devel more often, it's quite fun :)
[00:13] <maco> :D
[00:14] <Riddell> apachelogger: my general preference would be getting file syncing working fully before caring about the data stuff
[00:14] <JontheEchidna> Ah, but QSet is a QHAsh internally...
[00:14] <apachelogger> okies
[00:14] <Riddell> but either way is acceptable
[00:14] <apachelogger> thing is
[00:14] <apachelogger> full user experience will only be possible in KDE 4.6 anyway, because dolphin lacks appropriate plugin capabilities right now
[00:16] <apachelogger> so what we can do is everything under the hood (authentication + getting the sync daemon all hooked up) but the dolphin integration will stay a bit behind expectations
[00:18] <apachelogger> JontheEchidna: well, either way you should not use a data type that is not guaranteed to maintain a specific order where you need order IMHO
[00:18] <JontheEchidna> yeah, but I also want no duplicate items in the list. I suppose I could use qlist and remove dupes manually
[00:18] <apachelogger> ...imagine someone else does changes to the code in 1 year and does not know about the implicit order requirement... :/
[00:19] <apachelogger> JontheEchidna: well, if you insert by key you would just overwrite any previous item in a QMap I suppsoe
[00:20] <JontheEchidna> oh yeah, qmap doesn't allow dupes either
[00:26] <Riddell> apachelogger: are there changes being made in 4.6 to improve plugins in dolphin?
[00:29] <apachelogger> Riddell: that is the idea, no definite plans yet ... but something like putting the current VCSplugins on a generic base from which we can then draw what we need for u1 integration, most importantly more control over what goes on and when
[00:30] <apachelogger> most importantly I want the ability to register for directories, because currently the .ubuntuone file is only necessary because the only way dolphin can tell whether to use a plugin or not is by asking the plugin for what dot-file it expects :S
[00:46] <mathiaz> is there a way to get the list of binary packages with their description for a given source package using the LP API?
[00:47] <slangasek> lifeless: could you trigger a retry of the UDD import of aptitude?  It complained about a missing tag, which I've manually added, but no retry since the 20th of June
[00:47] <lifeless> slangasek: I think I might be able to. But i'm going to see if a losa can first.
[00:47] <slangasek> ok!
[00:48]  * lifeless counts the seconds till a losa pops up :)
[00:48] <spm> 'udd import'??
[00:48] <spm> heh, evil bugger
[00:48] <lifeless> james_w's package importer service
[00:49] <lifeless> spm: I think you added a ref to the losa docs a few weeks back about this very issue
[00:49] <slangasek> lifeless: fwiw, that this error was hit at all tells me there's still a problem with the upstream branch tagging - possibly specific to packages that have had the merge done by a dev rather than by the importer
[00:49] <spm> oh that thing. right.
[00:49] <lifeless> mathiaz: I'm pretty sure there is
[00:49] <slangasek> because my last merge of this package was done *after* our last conversation where you mentioned that the cause of the missing tags was fixed
[00:49] <lifeless> mathiaz: have you had a poke around the API docs ? Its likely not a single call at the moment (and perhaps it needs to be)
[00:50] <mathiaz> lifeless: I've looked at the api doc and I can't find it
[00:50] <lifeless> mathiaz: ok, gimme a couple of minutes and I will have a poke at it with you
[00:50] <lifeless> slangasek: yup
[00:50] <slangasek> (I had already been suspecting this to be the case, given the high incidence of this issue on packages I've previously merged :)
[00:50] <mathiaz> lifeless: https://edge.launchpad.net/+apidoc/devel.html
[00:50] <lifeless> slangasek: I have another couple of days directly working on this
[00:50] <slangasek> ok
[00:50] <mathiaz> lifeless: ^^ doesn't show anything special
[00:50] <lifeless> slangasek: but then my focus will be ... broadning
[00:51] <lifeless> spm: https://wiki.ubuntu.com/DistributedDevelopment/UnderTheHood
[00:51] <slangasek> lifeless: does that mean there will be someone else I should prod about bugs? :)
[00:52] <lifeless> slangasek: so I'm the new Launchpad TA
[00:52] <lifeless> slangasek: Once I track down the right people in prague to discuss UDD, we'll know what team(s) are responsible going forward
[00:52] <lifeless> slangasek: and even after that I'll still be very interested.
[00:52] <lifeless> slangasek: but not directly hacking on it myself
[00:54]  * spm praises james_w and documenting everything I need \o/
[00:54] <lifeless> spm: favour for me please.
[00:54] <spm> sure?
[00:54] <slangasek> lifeless: "TA"?
[00:54] <lifeless> spm: when, in doing one of these things, you think it would be reasonable for an Ubuntu dev to 'make it happen' themselves - please file a bug somewhere.
[00:55] <spm> slangasek: Tech Architect
[00:55] <slangasek> ah, not teaching assistant
[00:55] <slangasek> ok :-)
[00:55] <lifeless> spm: and each time it happens poke in the bug that its affecting you - to keep it visible.
[00:55] <spm> well..... this is debatable....
[00:55] <spm> lifeless: sure. I'm honestly not sure on something like this.
[00:55] <lifeless> spm: thats ok, so - in this case, are you applying any policy questions other than 'slangasek wants it' ? :)
[00:56] <spm> lifeless: tho... from a brief, not analysis look; failing from codehost going offline and needing manual intervention does seem unnecessarilly fragile.
[00:56] <lifeless> spm: definitely, that needs a bug, I think an incident report would be a bit heavyweight for now.
[00:56] <spm> lifeless: 'slangasek wants it' is a policy in our policy documents. Number 6 or 7 frommemory
[00:57] <slangasek> heh
[00:57] <slangasek> spm: you may want that updated to say "the release manager wants it"? :)
[00:57] <spm> no... I think we have it right atm. ;-)
[01:00] <spm> heh. ./show_failure.py --help ==> --help has not failed
[01:03] <spm> almaisan-away: in any event, aptitude is resubmitted whatever, the 700+ other failures do worry me - I suspect they're all tied to the release yesterday morn somehow.
[01:03] <spm> gah sorry almaisan-away. slangasek ^^
[01:04] <slangasek> spm: well, failures have been accumulating for a while and for the most part only resolve when someone has a chance to pick off the bugs
[01:04] <slangasek> 700+ isn't a pretty number, but doesn't alarm me
[01:04] <spm> ah, kk, I'll let it slide for now then
[01:04] <lifeless> there is a situation where it will clamp up and stop
[01:05] <lifeless> which is, i think, codehost downtime
[01:05] <lifeless> I opened a bug with a plausible explanation
[01:05] <spm> ah, ta.
[01:06] <james_w> fwiw, there's automatic retries in the face of certain failure conditions, of which this should be one
[01:06] <james_w> if it's like http://package-import.ubuntu.com/status/udav.html then it will be retried soon
[01:06] <lifeless> james_w: right, slangasek was asking for 'now please'
[01:06] <james_w> there's a bug that only the index page tells you that and not the individual page
[01:06] <lifeless> james_w: you know these devs, impatient folk.
[01:06] <james_w> sure
[01:06] <lifeless> :P
[01:07] <james_w> I was responding to "failing from codehost going offline and needing manual intervention does seem unnecessarilly fragile."
[01:07] <lifeless> right - thats the bug I opened last release, I think :)
[01:07] <spm> Ahh. coolio. I was wrong in my assumptions. excellent.
[01:07] <slangasek> james_w: how frequent and where does the index page tell this?  The per-package page says last attempt was 20 Jun
[01:08] <james_w> slangasek: that one is certainly different then
[01:08] <james_w> under udav near the top of http://package-import.ubuntu.com/status/ it says "and will be retried automatically around 2010-07-08 02:18:31.725122"
[01:09] <james_w> perhaps overly precise, but still
[01:09] <slangasek> oh, and the index page only shows that detail for the last 50 failures
[01:10] <slangasek> so for aptitude there was no indication whether a retry was intended
[01:12] <maxwellian> james_w: I don't usually use "around" with a time that's precise to fractions of a millisecond. ;)
[01:13] <james_w> maxwellian: then you're just not trying hard enough
[01:13] <slangasek> it's a LP tradition to be precisely inaccurate
[01:14] <slangasek> like the Ubuntu release dates that were specified to the minute :)
[01:14] <james_w> both filed, thanks
[01:14] <maxwellian> Heh. :)
[01:14] <slangasek> james_w: cheers!
[01:15] <james_w> first step to getting fixed at least
[03:36] <wrinkliez> hey guys, im creating a source package for windows (first time! woot).  and im at the section section (what?) of the control file.  is there like a list of sections i can look at?
[03:37] <RAOF> wrinkliez: Yup.  Debian policy has a list of the current sections.
[03:38] <RAOF> http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
[03:38] <wrinkliez> ah great, exactly what i wanted. thanks man
[03:39] <wrinkliez> and all of these are the same for ubuntu?
[03:39] <wrinkliez> any sections i can use for one but not the other?
[03:43] <RAOF> Same sections in Ubuntu.
[03:49] <lukehasnoname> Where would I tell a developer or packager about package dependency issues in Maverick? Launchpad Bugs is not the place, I'm told.
[03:49] <RAOF> Who told you that?
[03:50] <RAOF> Unless it's a transient arch-skew dependency issue, Launchpad is absolutely the place.
[03:50] <lukehasnoname> Brian Curtis, via a similar bug post
[03:50] <lukehasnoname> At this time since all the packages can be out of sync at times, and because you are using the development release of Ubuntu this isn't a bug. Wait for the packages to get updated and it should fix itself.
[03:50] <lukehasnoname> " "
[03:51] <RAOF> Right.  Transient arch-skew.
[03:51] <RAOF> If you're not sure whether it's a transient problem or not you c.  There'll still be a lot of transient dependency problems at the moment, though.
[03:52] <lukehasnoname> OK, I don't understand why that would happen, but I'll go with it. My issue, for example, is that logging in Empathy is broken ATM in Maverick because telepathy-logger, the new empathy logging tool, isn't depended on.
[03:52] <lukehasnoname> this change was made in empathy with the latest gnome updates a few days ago, and when I installed the package logging started happening again
[04:00] <lukehasnoname> RAOF, assume it'll be fixed?
[04:03] <RAOF> lukehasnoname: Indeed.  My update today pulled in telepathy-logger.
[04:16] <LucidFox> Is it possible for me to get my access to the private fonts PPA revoked? I feel dirty just for being able to access it.
[04:48] <LucidFox> Right. I suppose a better question would be: is it possible to get one's Ubuntu Member status revoked while retaining the @ubuntu.com address?
[04:50] <lifeless> AFAIK, no.
[04:51] <lifeless> whats wrong with the PPA ?
[04:51] <mneptok> LucidFox: not to my knowledge. an @ubuntu.com e-mail address is a privilege of membership.
[04:51] <LucidFox> Blimey
[04:51] <LucidFox> I have too many things tied to that address :(
[04:52] <lifeless> what is your concern with the PPA?
[04:52] <LucidFox> lifeless> Soon Planet Ubuntu should pull my post detailing what I find wrong with this whole concept of a closed beta.
[04:54] <wgrant> There were reasons given during the UDS talk, IIRC.
[04:54] <wgrant> I don't like it either, but, well...
[04:55] <LucidFox> Why is it named ubuntu-private-nda-fonts? Did I implicitly get signed an NDA without my knowledge?
[04:55] <wgrant> LucidFox: They've said that the font isn't going to be proprietary.
[04:56] <LucidFox> Right now it is.
[04:57] <LucidFox> Apparently it wasn't enough that the default install includes a client for a Canonical-run proprietary file syncing service
[04:57] <wgrant> The default install does not include a proprietary font.
[04:57] <wgrant> This is not in the default install yet.
[04:58] <LucidFox> But it's going to be. The default install is going to include a font that, right now, is proprietary and members-only.
[04:59] <wgrant> Right now it is, yes.
[04:59] <wgrant> Lost of things start off in development behind closed doors.
[04:59] <LucidFox> But that's limited to developers.
[04:59] <wgrant> No, this is not optimal, and I've been most critical of U1 and LP (while it was closed).
[05:00] <wgrant> IIRC they don't want it distributed too widely, since they're still tweaking metrics and the like.
[05:00] <wgrant> That was one of the reasons given; I do not recall the full rationale.
[05:00] <LucidFox> I'm not a developer of this font, yet I got implicitly signed an NDA for this closed beta that I want to opt out of.
[05:01] <wgrant> I don't think there's an NDA. I certainly haven't seen one. Perhaps there was before, before it was opened to community members.
[05:01] <ScottK> If you didn't sign an NDA, then there's no NDA.
[05:01] <j1mc> there's an article on arstechnica that shows the font... i don't really see how their could be an nda at this point.
[05:01] <wgrant> The misleading name may simply be an artefact of the upgrade path requirement.
[05:02] <j1mc> though i know the package name includes NDA in it
[05:02] <LucidFox> The package name is ubuntu-private-nda-fonts
[05:02] <wgrant> ScottK: Well, clearly.
[05:02] <ScottK> I find it somewhat odd that they are distributing it while the license is undecided.
[05:03] <wgrant> It is odd and probably unusable, yes.
[05:06] <j1mc> if anyone has a few minutes, would you mind reviewing a packaging guide survey i put together?  http://spreadsheets.google.com/viewform?formkey=dHZEVGFLNkROMnROQ2FBVUdjRGlTYnc6MA
[05:06] <j1mc> you DON'T need to fill it out
[05:06] <j1mc> just let me know any feedback before i put it up
[05:07] <j1mc> feedback... with regards to the questions i'm asking - if there's something else i should ask, or if i should ask something in a different way.
[05:08] <j1mc> if it makes you cry, i would want to know that, too.
[05:13] <ajmitch> j1mc: it's a little hard to answer some of those questions about what's missing from the packaging guide if I've answered that I very rarely reference it :)
[05:13] <ajmitch> though at least those questions aren't mandatory
[05:17] <j1mc> ajmitch: good point - not sure what i can do on that.
[05:17] <j1mc> i didn't set any questions to be mandatory, so i'll certainly take that into consideration if you don't answer them.
[05:18] <ajmitch> I haven't submitted anything, just read through most of the questions so far
[05:19] <j1mc> sure - i haven't released it upon the world yet... daniel holbach has given me some feedback, but no one else really, yet.
[05:22] <j1mc> ajmitch: would it be helpful to ask, "if you rarely reference the guide, why is that?" (or something similar) and then let the person know they can stop the survey...?
[05:25] <j1mc> bbiab
[05:26] <ajmitch> it could be useful to ask that & then skip to the last section about what packagers may need
[05:38] <MagicFab> hi all
[05:38] <MagicFab> what would be the difference between regression-release and regression-update ?
[05:39] <j1mc> ajmitch: thanks
[05:40] <j1mc> g'nite, all
[05:47] <jcastro> ScottK: in wordpress there's an option to enable "full text feeds", if you enable that your blog posts won't be cut off on planet.
[05:47] <ScottK> jcastro: Thanks.  I was just wondering about that exact thing.
[05:51] <ScottK> jcastro: Did you like that one?
[05:51] <ajmitch> the link to the post just links back to planet.ubuntu.com
[05:52] <jcastro> ^^^
[05:52] <jcastro> ScottK: the card game looks amazing!
[05:52] <MagicFab> nevermind, found it
[05:53] <ScottK> jcastro: I picked that because it shows of the beauty of KDE nicely.
[05:54] <jcastro> ScottK: the Close X on the right is pretty genious
[05:54] <jcastro> way more genius than my spelling today!
[05:54]  * maco is getting a netbook preinstalled with KNR :D
[05:55] <ScottK> jcastro: That's part of the standard Plasma Netbook interface (and I agree).
[05:55] <maco> i like that newspaper view plasmoid
[05:55] <maco> even on my fullsize laptops, i'd like that
[05:58] <ScottK> maco: zareason?
[05:59] <maco> ScottK: yep
[06:00] <maco> i dont know of any other oems that do kubuntu
[06:00] <maco> dell, hp, and s76 all do ubuntu but not kubuntu
[06:01]  * ScottK neither.  That's why I guessed them.
[06:02] <maco> riddell was surprised when "what os does it come with?" had that answer :)
[06:02] <maco> i told him one step toward world domination ;-)
[06:02] <maco> (since he was talking about world domination during tutorial day)
[06:03] <ScottK> Nice.
[06:03]  * ScottK is off to bed.
[06:04] <maco> oh!
[06:04] <maco> that screenshot is much more pleasant than what i expected
[06:04] <maco> ScottK: good night
[06:04] <maco> i thought it would be mac-style global menu. the hidden menu though...thats not bad
[06:04] <ScottK> jcastro: wordpress.com is smarter than me tonight.  I'll look for it again tomorrow.
[06:05] <ScottK> It'll do the mac style thing too.
[06:05] <ScottK> That's not what we're looking at for Kubuntu netbook though.
[06:18] <jcastro> LucidFox: ScottK: wgrant: the name nda in the package is a bug: lp #602835
[06:19] <LucidFox> ...So there was an NDA earlier in its development.
[06:19] <jcastro> I guess
[06:23] <wgrant> Well, it could well have been to indicate that it was covered under the normal Canonical NDA. That's what I would assume.
[06:24] <jcastro> it would behoove us to fix it asap, I've pinged ken about it
[06:24] <jcastro> LucidFox: I realize it's odd and not ideal
[06:25] <LucidFox> There's a "normal Canonical NDA"?
[06:25] <jcastro> all companies have NDAs, if you're doing contract work, etc.
[06:31] <Damascene> hi,
[06:31] <Damascene> ArneGoetje, there?
[06:37] <pitti> Good morning
[07:58] <dholbach> good morning
[08:37] <wgrant> pitti: I have branches that give native ddeb support to PPAs, but primary archive stuff is still not finished, since it's not clear how we want to expire them to conserve librarian space.
[08:37] <wgrant> I should probably try to start that discussion somewhere.
[08:38] <pitti> wgrant: ah, thanks; when do normal packages expire?
[08:38] <pitti> wgrant: i. e. is the difficulty to expire them after a different grace period than regular debs?
[08:39] <wgrant> pitti: At the moment we only expire non-final binaries from obsolete series.
[08:39] <pitti> wgrant: ah, right, I just thought about expiration on the archive, not in soyuz itself
[08:40] <wgrant> We could probably expire them earlier, but it would require changes to the copying code, which is why I haven't written it yet.
[08:42] <pitti> wgrant: right, I think we can discard non-current ddebs after a week
[08:42] <pitti> they take an insane amount of space
[08:44] <wgrant> pitti: Do you have numbers for how much the entire current set takes per arch?
[08:44] <pitti> wgrant: hang on
[08:45] <wgrant> I need to give the LOSAs a heart attack :)
[08:45] <spm> .....
[08:45]  * spm thinks wgrant is of the 'revenge is a dish best served cold' school
[08:45] <ajmitch> spm: I don't think you're meant to be watching this conversation :)
[08:46] <wgrant> Damn, forgot you lurked in here :P
[08:46] <spm> ajmitch: I was reading it; does that change the dynamic at all? ;-)
[08:46] <pitti> wgrant: du is running..
[08:47] <wgrant> pitti: Thanks.
[08:47] <dholbach> … still running …
[08:48] <pitti> wgrant: so we have 5 arches (i386, amd64, lpia, powerpc, sparc) and 5 releases (hardy to maverick), which take 146 GB pool/ space
[08:48] <pitti> wgrant: since lpia died in between, it's not that accurate to divide by 25, though
[08:48] <pitti> and ports have a lot of ftbfs, too
[08:49] <pitti> wgrant: so perhaps 10 GB per arch and release sounds realistic?
[08:49] <pitti> hm, wait, that can't be
[08:49] <pitti> I thought I removed some ports
[08:49] <wgrant> spm: Is mizuho creaking at those numbers yet?
[08:50] <pitti> right, I killed lpia completely
[08:50] <pitti> wgrant: let me clean up lpia properly and count agani
[08:51] <spm> wgrant: hrm. not sure I appreciate the nuances there, is that 146Gb to be added? or removed? or?
[08:51] <wgrant> spm: Added.
[08:52] <pitti> and I stopped retrieving ports as well (except armel)
[08:52] <pitti> wgrant: so, I think 12 GB per arch and release
[08:53] <pitti> this includes the usual sharing of versions between releases, but that'd affect Soyuz all the same
[08:53] <spm> we have space for that yeah, but that will have a corresponding hastening on getting more added
[08:53]  * pitti will remove jaunty
[08:53] <spm> err. assuming that's a single 146Gb. not multiples of same.
[08:54] <pitti> spm: my entire ddebs.ubuntu.com pool/ is 146 GB ATM
[08:54] <pitti> spm: but as I said, I filter out most ports
[08:54] <pitti> there's some cruft, though
[08:55] <spm> pitti: heh, fair enough. any chance of removing karmic and lucid while you're at it? no reason for asking... ;-)
[08:55] <pitti> we certainly do want to keep hardy and lucid
[08:55] <spm> damn. he's seen thru my cunning plan.
[08:55] <pitti> karmic can probably go after maverick's release
[08:56] <dholbach> spm: try harder :-P
[08:56] <wgrant> I guess I can make the copier deal with it if ddebs are missing.
[08:56] <wgrant> Revolting, but they're huge, so we'll need to expire them far earlier than everything else.
[08:57] <spm> wgrant: it's probably worth getting julian (I assume) to raise this space issue via an RT or in the bi-weekly call. Just to ensure all the details are understood by those who make the decisions?
[08:58] <wgrant> spm: Well, yes, I was just getting an idea of how big we were talking, and was going to bring it up with Soyuz when they were next around.
[08:58] <spm> coolio, great minds etc
[08:58] <pitti> well, I guess this would be a gradual buildup anyway?
[08:58] <pitti> or is there a chance that we could import the current ddebs into that?
[08:59] <wgrant> pitti: I think it would have to be gradual, I'm afraid.
[08:59] <pitti> right, so we need some tricks to merge the old ddeb archive with the new soyuz-generated one
[09:00] <pitti> with the easiest one being to ask people to just add two deb sources :)
[09:00] <wgrant> Or just stick both in the retracers' sources.lists.
[09:00] <wgrant> Right.
[09:03] <wgrant> Then we can demolish the non-virt builders, pool the i386/amd64/lpia builders, and make the build farm a happier, more efficient place.
[09:03] <wgrant> And use stock sbuild.
[09:03] <wgrant> And that makes me happy.
[09:04] <pitti> wohoo
[09:04] <pitti> wgrant: oh, how can we build ports on virtualized PPAs?
[09:05] <wgrant> pitti: Well...
[09:05] <wgrant> LP 10.06 lets us nominate certain architectures as being restricted.
[09:06] <wgrant> Archives need special configuration to be able to use restricted architectures.
[09:06] <wgrant> For example, there'll be 'virtual' armel builders soon, which aren't actually virtual. This will let OEM PPAs be marked as virtual, but still build on armel.
[09:06] <wgrant> It still has the big security issues, of course.
[09:06] <wgrant> But that's what you get for platforms that don't do virt.
[09:07] <wgrant> But the new system enables more flexibility with which architectures PPAs build on, and will let us safely remove the virt/non-virt distinction once ddebs are out of the way.
[09:07] <pitti> wgrant: right, I'd be happy to see some unification there
[09:08] <pitti> wgrant: it's sad to see three i386 buildds grinding through 800 langpacks while 20 other buildss just twiddle thumbs and amusedly watch them
[09:08] <wgrant> pitti: Exactly.
[09:08] <pitti> or the other way round with PPAs
[09:08] <wgrant> I have a branch that makes the x86 buildds build whatever is available.
[09:09] <wgrant> So there'll be something like 60 buildds available to build any given i386/amd64/lpia package.
[09:09] <wgrant> Which will be handy, and eliminate the lag that i386 sees due to arch-indep packages building only there.
[09:09] <pitti> nice
[09:09] <pitti> we have had some amd64 congestion for quite some time now
[09:10] <wgrant> I've found that a bit odd.
[09:10]  * lag starts to thing that lag was a bad nick choice! ;)
[09:10] <lag> think*
[09:10] <wgrant> lag: No, no, my branch eliminates you. No mistake there.
[09:10] <lag> ;)
[10:32] <ogra> lamont, could it be that acorn died ?
[10:33]  * ogra cant get a w3m connect
[10:44] <ogra> hmm, does anyone know how to log in to LP via w3m ?
[10:45] <ogra> i get the openid page but the continue link doesnt work
[11:12] <geser> ogra: try with elinks. Bug #556927 mentions problems to login to LP with w3m.
[11:12] <ogra> ah, thanks
[11:19] <pitti> wgrant, spm: cleanup run finished; 111 GB for three releases and 2.5 arches
[11:19] <pitti> (.5 because hardy didn't have a lot of arm ddebs yet)
[11:22] <wgrant> pitti: You mean jaunty? Hardy didn't have armel at all.
[11:22] <pitti> wgrant: right; jaunty is gone, it's just hardy, karmic, lucid, maverick now
[11:23] <pitti> ah, 4 releases
[11:23]  * pitti shouldn't count from 0 :)
[11:25] <wgrant> Heh.
[11:25] <wgrant> So roughly 12ishGB, as you estimated earlier.
[11:25] <wgrant> Thanks.
[11:48] <lamont> ogra: acorn died yesterday, I think someone was going to go stab it back to life today..
[11:48] <ogra> lamont, k, thanks ... archive is out of sync anyway
[12:01] <apw> cjwatson, ok i've put a cleaned up version of this bios fbcon stuff over onto some real h/w, and we do seem to still get a mode-switch from plymouth to X, not sure how to tell why
[12:05] <apw> cjwatson, i suspect this is cause the mode is actually different
[12:07] <apw> http://people.canonical.com/~apw/fbcon-hold-maverick/ <-- cjwatson updated kernels are here
[12:10] <cjwatson> apw: planar->tiled perhaps
[12:11] <apw> cjwatson, i presum we are expecting this ?
[12:11] <cjwatson> I think it happened before as well, didn't it?
[12:11] <apw> before?
[12:11] <cjwatson> with the current kernel in the archive
[12:12] <kaushal> hi
[12:12] <apw> with your grub yes
[12:12] <cjwatson> certainly a mode-switch there isn't unfamiliar to me ... might be worth asking RAOF though
[12:12] <kaushal> I have a wierd issue about disk space. my pastebin is here http://pastebin.ubuntu.com/460588/
[12:12] <apw> with the regular grub setup, there is no modeswitch between plymouth and X
[12:12] <cjwatson> oh, odd, I guess plymouth is doing something better than a vesa mode
[12:12] <kaushal> I dont get count of approximately 43 Gb
[12:12] <kaushal> Any ideas ?
[12:13] <cjwatson> kaushal: please ask on #ubuntu
[12:14] <kaushal> cjwatson: sure
[12:14] <cjwatson> apw: any chance of a way to set the handoff flag via struct screen_info?
[12:14] <kaushal> Thamls
[12:14] <kaushal> Thanks*
[12:14] <apw> cjwatson, well the machine in question has a 1024x600 native
[12:14] <cjwatson> i.e. to go with VIDEO_FLAGS_NOCURSOR
[12:14] <cjwatson> apw: so grub doesn't know how to deal with native modes, unless VBE exposes it
[12:15] <apw> cjwatson, perhaps, i have been testing with it just added to the kernle command line for now
[12:15] <cjwatson> in such cases, there has to be a mode switch at *some* point
[12:15] <cjwatson> so the question is whether we want the mode switch on grub->plymouth or on plymouth->X
[12:15] <apw> cjwatson, i suspect that means the very common case is a mode switch mid boot
[12:15] <cjwatson> apw: right, I just don't want to have to do stringwise editing of the command line in grub
[12:16] <apw> cjwatson, why would you need to do that in grub?
[12:16] <cjwatson> because the decision on whether to keep the existing video mode is dynamic
[12:16] <apw> hrm ok
[12:16] <cjwatson> it depends on things like the type of video mode grub managed to probe at runtime
[12:17] <apw> cjwatson, so i'll have a look then
[12:17] <cjwatson> ta
[12:17] <apw>  cjwatson oh an the cursor seems to be on at the moment on real h/w ... seems to be a difference from the VM
[12:17] <cjwatson> apw: 'if (vt_handoff) vt_handoff = 0;' seems redundant
[12:18] <apw> possibly we are losing visibility of it in the VM due to the changes based update
[12:18] <apw> cjwatson, we need to clear it on mode swtich ?
[12:18] <cjwatson> could be, I did try using VIDEO_FLAGS_NOCURSOR but it has a similar kind of problem - you need a way to turn it back on when you've finished booting
[12:18] <cjwatson> apw: I mean you might as well just say 'vt_handoff = 0;'
[12:19] <apw> well that dirties the cache line evret tim, whiis evil
[12:19] <cjwatson> oh, hm
[12:19] <cjwatson> ok, I bow to your superior expertise :)
[12:20]  * apw hits his e key ... why does your disk being busy break xchat mid input line
[12:25] <geser> StevenK (or any other archive admin): Could you please kill default-jdk-builddep from the NBS list. default-jdk-builddep got renamed to gcj-native-helper (which still provides default-jdk-builddep) and the stale deb prevents that packages build-depending on it can't currently get build. Except tex4ht all dependencies on default-jdk-builddep are unversioned so they are still fulfilled by
[12:25] <geser> gcj-native-helper. For tex4ht bug #603101 awaits sponsoring. Thanks.
[12:28] <\sh> jcastro: ping
[12:29] <apw> cjwatson, can i not already tell which buffer you chose from the VIDEO_TYPE ?
[12:38] <cjwatson> apw: which buffer?
[12:38] <apw> cjwatson, sorry i mean do you not already pass me the frambuffer mode you chose ?
[12:39] <cjwatson> no, you just know "it's VESA" AFAIK
[12:39] <cjwatson> oh, it's in the screen_info structure
[12:39] <cjwatson> I don't know offhand if that's precisely enough information to reconstruct the VESA mode
[12:39] <cjwatson> but in any case, it's not necessarily the desired final mode
[12:40] <cjwatson> enough information> you get height/width etc., not the actual VESA mode number
[12:40] <apw> cjwatson, no indeed.  so it looks like there is only one flag in that byt,e, want to spin me a patch to set the bit in grub, and i'll have a go at it
[12:45] <cjwatson> apw: something like http://paste.ubuntu.com/460598/ - it would probably need more checks than that in real life
[12:47] <apw> cjwatson, don't think the padding needs to change size does it, the byte is still a byte
[12:48] <cjwatson> it's an array of bytes which needs to get one shorter ...
[12:51] <apw> cjwatson, no as you didn't use any additional bytes did you ?
[12:51] <apw> oh you did, stupid me
[12:52] <apw> i didn't see the + as i was expecting the flags to be there already
[12:52] <apw> for the cursor on off which i thought was already supported
[12:54] <apw> cjwatson, in other words yes thats looking great
[12:54] <jdstrand> seb128: hi! would you mind taking a look at bug #597940? it is a very annoying bug for those that seem to hit it (one happens to be my wife, but people are blogging about it with workarounds posted on Planet Ubuntu)
[12:55] <jdstrand> seb128: it had been stuck at Incomplete, but I changed that and the priority. It maybe should go even higher (see my comment), but I'll let you decide that
[12:57] <apw> cjwatson, that patch changes a file i don't see to have, i suspect it is the copy of a file
[12:57] <jdstrand> seb128: fyi-- I asked tedg about this issue at UDS, and he speculated it might be the indicator applet. it was a wild guess, so take it with a grain of salt. neither of us (at least at the time) had looked at any code or bugs
[13:00] <cjwatson> apw: which one?
[13:00] <apw> cjwatson, bah ignore me, seems if you use -p1 they apply to the wrong file
[13:01] <seb128> jdstrand, hey
[13:01] <cjwatson> apw: http://paste.ubuntu.com/460603/ -> more familiar formatting perhaps
[13:01] <seb128> jdstrand, https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/439448
[13:01] <seb128> jdstrand, is that this one?
[13:01]  * jdstrand looks
[13:02] <seb128> jdstrand, in short, nobody in our team has any clue what's going on and how to start debugging
[13:02] <seb128> jdstrand, we would very much like to get it squashed though...
[13:03] <seb128> jdstrand, it's probably bug number 1 on our list of annoyance in lucid
[13:04] <jdstrand> seb128: I'm still looking at that long bug, but I can say this: the hallmark sign of the bug for me is that the power button icon goes away and there is no way to logout via the desktop (obviously can use a terminal)
[13:04] <jdstrand> seb128: I've not seen the issue on any of my computers, but my wife sees it at least once a week
[13:04] <seb128> I don't get it a lot there
[13:04] <jdstrand> seb128: I have seen my applets out of order occassionally
[13:05] <seb128> we are still at a fail to know in which cases it triggers or what could trigger it
[13:05] <seb128> the ordering bug is another known one
[13:05] <seb128> especially if you change screen settings
[13:05] <Tanguy> Hello.
[13:05] <seb128> ie have a laptop and dock, undock it
[13:05] <Tanguy> Do you know if there are currently problems with Launchpad?
[13:05] <seb128> but that's a different issue than the corruption one
[13:05] <seb128> Tanguy, hi, try #launchpad?
[13:05] <Tanguy> Indeed. :-)
[13:05] <jdstrand> seb128: yes, I think the ordering has to do with attaching an external monitor, which my wife does not do, so I figured that was a different bug
[13:06] <jdstrand> seb128: let me rephrase
[13:06] <jdstrand> seb128: I only saw that when attaching/detaching an external monitor, so thought it was different
[13:06] <seb128> right, they are different
[13:06] <seb128> the ordering bug has always been there
[13:06] <seb128> it's likely the corruption one is due to the indicators
[13:07] <seb128> but I've no clue what and why
[13:07] <seb128> it happens on random applet
[13:07] <seb128> and is a visual corruption
[13:07] <seb128> changing the gnome-panel settings workaround it
[13:08] <seb128> I got it a few times, I could move the applet but it stayed corrupted
[13:08] <seb128> jdstrand, ie in your case the session button is probably there and can be opened using the keyboard
[13:08] <seb128> super-s
[13:08] <seb128> it just seems to not be layed out of the gnome-panel for some reason
[13:09] <jdstrand> seb128: the workaround I used was found in http://en.andregondim.eti.br/?p=160, which is 'Alt+F2' followed by 'killall gnome-panel'. That is less than ideal ;)
[13:09] <seb128> right
[13:10] <seb128> if you read the bug I pointed some people tweak gnome-panel settings
[13:10] <seb128> or move the orientation
[13:11]  * jdstrand continues to read
[13:12] <jdstrand> seb128: fwiw, my wife ran jaunty, then upgraded to karmic and then lucid the same day, so she never had a chance to see it in karmic
[13:12] <seb128> jdstrand, it was there in karmic
[13:12] <seb128> I'm not sure if it become increasing in frequency in lucid
[13:13] <seb128> or if we just have higher number of users
[13:13] <jdstrand> yeah, I saw that the report came in against 9.10
[13:13] <seb128> if ted had any clue on what could create the issue that would be useful
[13:14] <jdstrand> well, I only mentioned ted so you had all the info I had-- to be fair, that was a while ago and we were just chatting over a donut or something
[13:15] <seb128> ok
[13:15] <seb128> I would probably have told you I though it was indicator related as well
[13:15] <seb128> but in practice it doesn't put us any closer of understanding what could be going on
[13:16] <jdstrand> seb128: I'm at comment #15-- fyi wife does not have nvidia and she does have 32 bit
[13:16] <seb128> I would be interested to have somebody who get the bug reliably to get debug infos though
[13:16] <seb128> jdstrand, I think we can exclude any sort of video driver issue
[13:16] <jdstrand> yeah, it is like once a week or so :\
[13:16] <seb128> it happens on all sort of hardware
[13:17] <seb128> we tried to turn off gtk client side which could have been an issue but it's not it either
[13:17] <jdstrand> seb128: it also doesn't have anything to do with suspend/resume, as my wife doesn't do that
[13:27] <jdstrand> seb128: so in comment #66, someone finally posted a screenshot of the bug I see (ie the shutdown button is missing). While I have seen the duplicate icons issue, that is more livable than the shutdown one. do you feel that comment #66 fits with everything else? I kinda do, but that bug is kinda all over the place so don't want to just duplicate it willy-nilly
[13:28] <jdstrand> #70 also shows it
[13:32] <jdstrand> ok, later comments people are talking more and more about the shutdown issue
[13:45] <seb128> jdstrand, not sure to understand the question there
[13:46] <jdstrand> seb128: I was looking for guidance, but no longer need it. I feel strongly it is a dupe and will mark it as such
[13:46] <seb128> jdstrand, there is one bug I think, it just corrupts randomnly applets and indicators
[13:46] <jdstrand> seb128: I'm still reading all the comments :)
[13:47] <seb128> there is quite some of those, and yeah when it breaks the session indicator it's rather annoying since it breaks the way to stop the computer
[13:47] <jdstrand> seb128: yes, and in the default install, there is no shutdown icon anywhere in the menus, etc
[13:48] <seb128> well there is one in the corner which is enough when it doesn't get broken ;-)
[13:48] <jdstrand> seb128: I'll provide a workaround for my wife and try to reproduce, but not hugely hopeful. intermittent bugs stink
[13:48] <jdstrand> seb128: hehe, yes :)
[13:49] <seb128> right, having the bug once a week makes debugging difficult
[13:49] <seb128> it's not even easy to try potential fixes because not having it in 2 weeks doesn't mean it's fixed
[13:49] <seb128> it's just that you could be a lucky for a week
[13:50] <jdstrand> yeah :(
[13:56] <cjwatson> pitti: what do you think about colouring INPROGRESS differently from TODO on work items charts?  we were talking about this in the foundations meeting yesterday
[14:21] <ricotz> siretart, hello, are there plans updating/merging xine-lib?
[14:30] <siretart> ricotz: I have a merge ready, but I have problems pushing the changes to launchpad. the merge just needs some testing and uploading
[14:34] <ricotz> siretart, ok, i had just a look at https://merges.ubuntu.com/x/xine-lib/
[15:18] <joaopinto> mvo, ping
[15:19] <maxb> Hello, could I have a give-back on https://edge.launchpad.net/ubuntu/+source/subversion/1.6.12dfsg-1ubuntu1/+build/1853955 please?
[15:23] <mvo> hey joaopinto
[15:24] <ScottK> maxb: Done
[15:24] <maxb> thanks
[15:25] <maxb> Does anyone know about java segfaulting on armel? I'm uncertain what to do with the subversion maverick/armel FTBFS  (https://edge.launchpad.net/ubuntu/+source/subversion/1.6.12dfsg-1ubuntu1/+build/1853956)
[15:28] <apw> cjwatson, ok that seems to be possible
[15:28] <apw> s/possible/work ok/
[15:31] <joaopinto> mvo, hey, a question about APT from a generic perspective, is it valid to have the same package in the same release contained in multiple components ?
[15:32] <joaopinto> since Index is kept or a per release/component basis it can be done, but I am unsure if it's valid from a design perspective
[15:32] <joaopinto> erm, I mean "Packages"
[15:39] <mvo> joaopinto: what is your use-case?
[15:40] <joaopinto> mvo, this is to help in a decision to define an archive structure, the goal is to have a "beta" and "stable", they can be implemented as releases or components
[15:41] <joaopinto> on a regular archive I have never seen a package contained on multiple components for the same release
[15:43] <joaopinto> I think the best solution is to use releases, but I didn't find anything invalidating the use of components for the same purpose
[15:43] <cybersnoop> Wow.. something went pretty wrong with my SSD on 2.6.35-7 (on lucid).
[15:44] <cybersnoop> System nearly locked-up. When I switched to tty1 I saw some messages from "ata3" about being unable to flush and failed command DRDY
[15:44] <cybersnoop> Now these messages don't appear in /var/log/messages .. probably because that's on the same SSD
[15:45] <mvo> joaopinto: it should work fine but its a bit unusal afaics. the only thing is that you need to ensure the packages are really the same (I guess that is obvious) if they have the same (name, version)
[15:45] <cybersnoop> Is there anyway I can be of any help for kernel-developpers with this error?
[15:45] <joaopinto> right, reprepro enforces that by validating the md5sums
[15:45] <joaopinto> mvo, thanks
[15:45] <mvo> cheers
[16:14] <ebroder> Has anybody tried to use the live CD creator on an Android phone?
[16:24] <ScottK> jcastro: Thanks for the hint.  I finally fixed it....
[16:44] <pitti> cjwatson: anything is possible, of course; we'd need to actually start tracking "in progress" as a separate state (it can't be represented at the db level right now), and it's some code changes; I estimate two hours for the changes and testing
[16:49] <cjwatson> pitti: do you think it's a worthwhile thing to do?  there are enough inprogress items on my team right now that I'd be willing to do so
[16:58] <pitti> cjwatson: not from my side really, since the difference between "todo" and "inprogress" isn't that interesting in terms of planning
[16:58] <pitti> cjwatson: (lagged, me @ phone)
[16:59] <cjwatson> ah, the reason I find it interesting is that if work items are insufficiently granular for some reason then it means that progress is visible rather than artificially reduced
[17:17] <gnarl> pitti, cjwatson I just uploaded lucid mvl-dove and ec2 which are rebases to the kernel we already got up in proposed. Can those get accepted?
[17:22] <cjwatson> looking
[17:27] <gnarl> thanks
[17:30] <cjwatson> smb-afk: done
[17:30] <smb-afk> cjwatson, Yeah, saw the mails coming in. Ta
[17:35] <cjwatson> pitti,slangasek: could you review base-files and debian-installer in lucid-proposed?
[17:57] <apw> cjwatson, so kernels which implement the check via 'flags' seem to work for me, also think i have the cursor turned off now.  kernels uploading to here now:  http://people.canonical.com/~apw/fbcon-hold-maverick/
[17:58] <cjwatson> ok, I'm battling with my attempt to implement 'linearfb'
[17:58] <cjwatson> which is being less than a perfect model of glorious success right now
[17:59] <apw> cjwatson, ok ... hopefully that can give you some idea what it looks like on real h/w
[18:01] <cjwatson> jdstrand: could you have a look at busybox in NEW?
[18:03] <jdstrand> cjwatson: k
[18:04] <apw> cjwatson, ok just tested the amd64 one on real h/w with your double patched grub and its looking pretty good ... obviously we have the mode switch to X due to the non-vesa native mode
[18:04] <pitti> cjwatson: can do later on, just need to start a rather large build first
[18:06] <jdstrand> cjwatson: looks like it got held up on the new busybox-syslogd. accepted
[18:09] <pitti> lamont: the current qt4-x11 armel FTBFS in maverick looks like someone forcefully cancelled the build, is that right? i. e. it's not a "real" ftbfs in the "bad package" sense
[18:09] <pitti> lamont: https://edge.launchpad.net/ubuntu/+source/qt4-x11/4:4.7.0~beta1+git20100706-0ubuntu1/+build/1856835/+files/buildlog_ubuntu-maverick-armel.qt4-x11_4:4.7.0~beta1+git20100706-0ubuntu1_FAILEDTOBUILD.txt.gz
[18:09] <lamont> pitti: um... well. ...  so about that.
[18:09] <lamont> oops
[18:09] <pitti> (this was probably done to ease the armel buildd load a bit, since there were a couple of OEM armel builds of qt4-x11, too)
[18:10] <lamont> it was done to clean out a surplus of qt4-x11 uploads to an armel suite... OTOH, maverick is not that suite.
[18:10] <pitti> lamont: ok, understood; thanks for confirming
[18:10] <pitti> I just wanted to make sure that I interpret it correctly
[18:10] <pitti> lamont: I'll take over that qt4-x11 OEM thing now and test it locally first :)
[18:11] <lamont> yeah - totally mistook it for part of the OEM cluster
[18:11] <pitti> so hopefully we'll just have one build then
[18:11] <lamont> you'll give it back then?
[18:11] <pitti> lamont: I don't really need it
[18:11] <pitti> if the Kubuntu or mobile guys do, it should be fine to give back
[18:11] <pitti> but it won't be the last maverick upload, so *shrug*
[18:32] <ScottK> pitti: Thanks for bringing it up.  I've retried it because qt4-x11 being out of sync on armel has quite a number of unfortunate knock on effects (including making it really hard for NCommander to work on fixing KDE ftbfs that he's been exploring.
[18:32] <ScottK> NCommander: Looks like nevermind on fixing qt4-x11 on armel.
[18:33] <NCommander> ScottK: woo, unexpected good news
[18:34] <pitti> ScottK: fair enough; it built everywhere else, so it should build on arm, too
[18:35] <ScottK> That's an interesting theory that doesn't seem to work out in an unfortunate number of cases.  I suspect it's likely to be OK this time though.
[18:39] <pitti> ScottK: it's my hope, anyway :)
[18:43] <ScottK> ;-)
[18:56] <ScottK> jono: I think the last line of your latest blog post is missing a word.
[18:57] <in-pog-form> a friend of mine has uncovered a serious security issue
[18:57] <in-pog-form> in PAM
[18:57] <in-pog-form> i wish to let the devs here know
[18:58] <ebroder> in-pog-form: https://wiki.ubuntu.com/DebuggingSecurity#How%20to%20File
[18:58] <in-pog-form> without telling the whole world
[18:58] <jdstrand> in-pog-form: if it is http://www.ubuntu.com/usn/usn-959-1, it was fixed yesterday, otherwise, follow ebroder's advice
[18:59] <in-pog-form> ah yes it was that issue
[18:59] <in-pog-form> thank you
[18:59] <jdstrand> np
[18:59] <in-pog-form> i tried it
[18:59] <in-pog-form> shit gets real yanno
[19:00] <jdstrand> I'm unfamiliar with that saying, but yeah, it is not good
[19:01] <in-pog-form> exploitable privilege elevation is never a good thing®
[19:01] <in-pog-form> any way
[19:01] <in-pog-form> back to sysadminning
[19:01] <in-pog-form> cheers lads
[19:02] <jdstrand> see ya :)
[19:05] <jono_> ScottK, lol, I will fix that now
[19:05] <ScottK> ;-)
[19:05] <jono_> well spotted :-)
[19:05] <jono_> cheers
[19:22] <cjwatson> jdstrand: thanks
[19:23] <jdstrand> oh sure :)
[19:24] <zul> When someone from the foundations team review the upstart script in https://bugs.edge.launchpad.net/ubuntu/+source/dovecot/+bug/603285 thanks!
[19:39] <cjwatson> zul: commented on the bug
[19:39] <zul> cjwatson: thanks
[19:53] <SpamapS> Hm, trying to add memcached and libmemcached to the seeds as they've been approved.. but I'm not sure where things go.. https://wiki.ubuntu.com/SeedManagement seems to list a lot of seeds that aren't in maverick
[19:57] <cjwatson> they're spread across platform.maverick and ubuntu.maverick
[19:57] <cjwatson> what seed are you looking for?
[19:57] <slangasek> cjwatson: base-files, debian-installer accepted.  What's the timeline for 10.04.1?  Is jul 29 the target date (as per https://wiki.ubuntu.com/LucidReleaseSchedule)?
[19:57] <slangasek> er, getting ahead of myself here - haven't actually accepted d-i yet :)
[19:58] <SpamapS> cjwatson: Well neither need to be on the CD, the main reason we're adding them to main is for long term support for web apps.. so I'm thinking 'supported-server'
[19:59] <SpamapS> cjwatson: that page doesn't mention platform.XXX .. like I said, it seems very out of date
[19:59] <cjwatson> SpamapS: lp:~ubuntu-core-dev/ubuntu-seeds/platform.maverick
[19:59] <SpamapS> cjwatson: indeed, I just pulled that one down
[20:00] <cjwatson> slangasek: shooting for what's on the release schedule but may not quite hit

[20:00] <SpamapS> actually supported-misc-servers seems appropriate for memcached
[21:15] <robbiew> pitti: awake?
[21:20] <slangasek> lifeless: the missing upstream tags thing is totally reproducible for me
[21:21] <slangasek> lifeless: do you have time for us to put our heads together on it?
[21:21] <lifeless> slangasek: not immediately. In 3 hours I will.
[21:21] <slangasek> lifeless: sounds good
[21:21] <lifeless> ok, I'll get out and do my chores before the sprint trip, and then ping you.
[22:06] <achiang> how can one get the source to various udebs, such as partman-auto?
[22:06] <achiang> just go poke around in the public pools, find it, and then extract? or is there a more elegant way?
[22:07] <achiang> apt-cache search doesn't reveal anything useful
[22:10] <achiang> hm, maybe they're tucked away in debian-installer
[22:24] <achiang> apt-get source partman-auto works
[22:41] <Cheery> It's not like anyone other would have ever noticed. but I think I/O for UI peripherals in linux is cumbersome.
[22:43] <Cheery> it results in oddities like having to insert joystick before starting a game.
[22:44] <Cheery> and having to use cumbersome libraries to do simple tasks like play a sound.
[23:32] <SpamapS> hmm, looking at bug 603363 .. anybody know why ssh is the only service that uses 'stop on runlevel S' instead of [!2345] ?