[00:00] <ogra> slangasek, arm images dont use OO.o, we need to make sure OO.o gets built on one of the new machines, the old ones segfault randomly
[00:01] <slangasek> which ones are the new ones?
[00:01] <ogra> slangasek, but that shouldnt hold up beta
[00:01] <ogra> ubuntu-netbook and ubuntu-server are the ones we test
[00:02] <ogra> netbook has the new weboffice stuff in the image, while its important that we have OO.o building and running for final it doesnt impact the milestones anymore
[00:03] <ScottK> It's still on the KNR armel images.
[00:03] <ogra> slangasek, oh, you mean the new builders ? (sorry, i'm very tired) lamont should be able to tell, i think gourd is one of the new ones
[00:03] <ogra> cushaw sounds new as well
[00:04] <slangasek> previous build was on buttercup - do you know if that's new or old?
[00:05] <ogra> not of the top of my head, lamont is really the safest person to ask here, he just set up a set of new builders
[00:05] <slangasek> lamont: ping
[00:06]  * ogra is totally swamped in omap stuff since a while 
[00:08] <ogra> slangasek, do you plan a d-i upload before beta ? (i saw you bumped the ABI for armel arches and the commit i did today for omap would be helpful for server images)
[00:08] <slangasek> server images?
[00:09] <ogra> we build netbook, servar and netinst images for all arm arches
[00:09] <lamont> ogra: new (bbg3): buttercup, cushaw, gourd
[00:09] <ogra> *server
[00:10] <slangasek> ogra: ^^ then OOo is FTBFS on the new armel buildds.
[00:10] <lamont> ogra: and to come: acorn crabapple satinash hubbard sycamore hawthorn
[00:10] <lamont> though one of those will be livecd builds
[00:10] <ogra> slangasek, given the kernel is only half way there (still waiting on amit here to do teh final fixes) i'd be fine to have at least a server image atm
[00:11] <ogra> lamont, can you give back OO.o to build on one of the old buildds to check if its probably an issue with the new setup ?
[00:12] <slangasek> ogra: building server images is an artifact of how the cronjobs are set up, no one has mentioned to me that we're supposed to support armel server images; why do you care if those are working?
[00:12] <lamont> ogra: with some sobbing, yes
[00:12] <slangasek> (I had no plans to upload d-i because I was unaware anyone cared - you can upload it, though)
[00:12] <ogra> slangasek, we dont *suuport* them per se :) they are just the easiest thing to get working to have something at all
[00:13] <ogra> slangasek, currentl kernel prob with omap is that HID is screwed, so live images are a no go on an arch that only has USB input
[00:13] <ogra> *current
[00:13] <slangasek> heh
[00:13] <lamont> ogra: so we know it'll fail on buttercup?
[00:13] <ogra> lamont, apparently
[00:13] <slangasek> lamont: yes
[00:14] <lamont> just for the record, this isn't trivial.
[00:14] <slangasek> what isn't?
[00:14] <lamont> forcing the m achine it lands on
[00:14] <slangasek> oh, giving back on an old one
[00:14] <ogra> well, its not urgent that we have oo.o for beta, but i think it seems to show a potential buildd prob
[00:14] <slangasek> I don't see the point in doing it
[00:14] <wgrant> lamont: I suppose you have to flip them all onto manual, tweak a build score, and flip one back onto auto? Ew.
[00:15] <ogra> well, probably something for next week anyway, given that all old machines are totally busy atm
[00:15] <lamont> wgrant: step 0: nuke the current build to get it back into failed
[00:16] <ogra> yeah, dont nuke gcc
[00:16] <lamont> which actually is just a matter of waiting for the build to get to that step
[00:16] <wgrant> True.
[00:16] <lamont> the easy part is landing it on an old machine - I have some of those that are trying to be retired
[00:22] <ogra> slangasek, when did you give it back last time ?
[00:23] <ogra> the log i checked today seems to have failed in a different place
[00:23] <ogra> (today like about 12-14h ago)
[00:24] <lamont> it does help to have a spare buildd in your back pocket.
[00:25] <lamont> huito is building it, but ogra... I'm thinking you really want it to fail there, too.
[00:25] <ogra> yeah, i really hope it does
[00:25] <slangasek> ogra: I think I last gave it back before that
[00:26] <ogra> hmm, k, then i might misremember, i cant remember seeing anything about localedata around the segfault line
[00:32] <ogra> slangasek, d-i is in the queue
[00:32] <slangasek> ok
[00:32] <lamont> at any rate,  afk for a goodly while, I think
[03:40]  * slangasek gets the isotracker a-movin'
[04:08] <ScottK> Ah my, he's not done.
[04:12] <ScottK> Ah/Oh
[04:15] <slangasek> who?
[04:27] <ScottK> slangasek: zul.  This big slew of Universe uploads is all zul doing mysql rebuilds.
[04:28] <slangasek> ah
[04:28] <slangasek> why are mysql rebuilds needed, OOI?
[04:28] <slangasek> (I don't see anything on NBS)
[04:36] <ScottK> Maybe he's trying to get everything to 5.1.
[04:36] <ScottK> Not sure.
[04:38] <slangasek> mmk
[04:39] <slangasek> GrueMaster: FWIW, ARM candidate images for beta2 have started building, but with the addition of omap, I guess that'll take another 2 hours longer so won't be ready 'til morning
[04:39] <ScottK> If stuff isn't seeded, I'm just pushing Universe through.  I view needing the push as a workaround to an LP limitation because the unseeded part of Universe isn't frozen.
[04:40]  * slangasek nods
[04:41] <slangasek> speaking of which, is there a reason chromium-browser is still in the queue?  Does somebody have that seeded somewhere?
[04:42]  * wgrant points at the augmented queue, with package sets.
[04:42] <ScottK> I thought it was seeded on armel, but I wasnt' sure
[04:42]  * slangasek chuckles
[04:42] <ScottK> wgrant: Very helpful.
[04:42] <ScottK> Unfortunately I've discovered as a result that package sets are manually maintained at the moment and not always in sync with the seeds.
[04:43] <wgrant> YAY
[04:43] <ScottK> That's a limitation of the current initial implementation.  Not "the plan".
[04:43] <slangasek> ScottK: chromium-browser was investigated for armel this cycle, and in the end they stuck with firefox
[04:43] <wgrant> Ah, good.
[04:43] <ScottK> slangasek: OK.  Thanks.  I'll accept it then.
[04:44] <ScottK> slangasek: I left twm there because it's a pending MIR issue.  I'm not sure Depends -> Suggests for menu is a great idea.
[04:45] <ScottK> I didn't get a chance to see what twm uses it for.
[04:45] <slangasek> twitch
[04:45] <slangasek> has someone opened an MIR bug, or is it just currently in components-mismatches?
[04:45] <ScottK> There's a MIR bug.  It's referenced in debian/changelog
[04:46] <ScottK> The MIR is ~approved too.
[04:46] <ScottK> Read the bug and then double twitch.
[04:47] <slangasek> meh, I think the right answer is to b-d on metacity instead of twm
[04:47] <slangasek> promoting a wm just to have it for a java test suite seems absurd to me
[04:47] <ScottK> Thus the double twitch.
[04:51] <ScottK> slangasek: Are you going to write in the bug and reject it?
[04:51] <slangasek> ScottK: I've commented the bug, but I'm not ubuntu-mir
[04:52] <slangasek> so I'll wait for their decision before accepting/rejecting the package
[04:52] <ScottK> OK.
[04:52] <slangasek> in the meantime, AFK
[05:42] <GrueMaster> slangasek: What, you mean I can't start testing until after midnight?  Aww.  :P
[07:23] <ara> morning all!
[07:46]  * slangasek waves
[07:48] <ara> hey slangasek
[07:58] <ttx> slangasek, ara: o/
[08:05] <mvo> ttx: good morning, not sure you have noticed, I added the server-tasks upgrade test profile. karmic->lucid seems to have a conffile prompt in bind9, otherwise it looks good
[08:06] <ttx> mvo: no, haven't had a look yet. That sounds good, thanks. Do we have a bug about the bind9 thing or do you want me to look into it ?
[08:06] <mvo> ttx: I have not checked for bugs or details yet, I do a app-install-data update now, then I can check it out
[08:27] <slangasek> GrueMaster: arm netbook is up
[08:28] <slangasek> ara: should the UbuntuGlobalJam milestone be hidden on the tracker?
[08:29] <ara> slangasek, indeed, I'll do it
[08:29] <slangasek> thanks
[09:19] <pitti> slangasek: still okay to sync a new tzdata into lucid at this point, or shall I do it after beta-2? (just two simple DST rule updates, bug 550157)
[09:35] <slangasek> pitti: if it's not urgent, please wait until after beta2 or until we have to reroll for something else
[09:35] <slangasek> http://qa.ubuntu.com/reports/ogasawara/weatherreport.html is a lot easier to read when it lists 0s instead of 1s
[09:35] <pitti> slangasek: not that urgent; time will be wrong in Tunesia and Pakistan, but it's certainly not worth a re-roll
[09:36] <pitti> yes, understood
[09:36] <slangasek> will be wrong immediately?
[09:36] <pitti> yes, the changes got effective two weeks ago in Tunis
[09:36] <slangasek> yuck :/
[09:36] <pitti> oh, Pakistan only changes April 15, so that's still ok
[09:37] <pitti> slangasek: but we'll provide an updated tzdata in lucid, so on an installed system you can just upgrade
[09:37] <slangasek> yeah
[09:37] <pitti> slangasek: I'd only sync it if you were planning a re-roll anyway
[09:37] <slangasek> I guess the SRUs are more important for production
[09:37] <pitti> right, I'm doing them right now
[09:37] <pitti> +# > On Thursday (2010-03-25) it was announced that DST would start in
[09:37] <pitti> +# > Pakistan on 2010-04-01.
[09:37] <pitti> How the heck can governments do things like that??
[09:38]  * pitti stops grumbling and continues to fire SRUs
[09:39] <slangasek> they can do things like that because there's no physical law that ensures good sense in government :)
[09:40] <pitti> right, and instead we get bug comments "24 hours later, still not assigned... and importance "undecided".... Viva Ubuntu ! Pfffffff...... :-(" ...
[09:41] <pitti> slangasek: want me to process those SRUs myself?
[09:42] <slangasek> yeah, feel free
[09:43] <slangasek> comments> those are the kind of people I tell that they should be complaining to their government for being irresponsible
[09:45] <ttx> cjwatson: "splash" is still present on the beta2 candidate server install
[09:45] <ttx> pitti: sounds like an april 1st joke
[09:45] <pitti> ttx: sadly not; many countries do that unfortunately
[09:47] <ttx> slangasek: for some reasons, the samba-server task installs winbind, so the pam_winbind profile borkenage affects the resulting install -- I'm looking at where that comes from
[09:48] <slangasek> ttx: I would expect a samba server task to include winbind
[09:49] <slangasek> I'd rather focus on understanding the profile error, which I have yet to reproduce here despite having pam_winbind configured
[09:49] <ttx> slangasek: right
[09:49] <slangasek> I really need someone who's seeing this problem to post me their full /etc/pam.d/common-* for analysis
[09:49] <ttx> I can reproduce on a bare ISO+samba-server task install, cannot log in
[09:50] <ttx> I can provide that info
[09:50] <slangasek> including on console?
[09:50] <ttx> yes.
[09:50] <slangasek> ok
[09:51] <ttx> just a sec, booting single-user mode and packing that up for you
[09:51] <slangasek> thanks
[09:54] <ttx> the missing piece of the puzzle might be that pam_smbpass is also active
[09:54] <ttx> (or not)
[09:55] <slangasek> I've been running with both pam_winbind and pam_smbpass active for months
[09:55] <slangasek> no errors
[09:55] <slangasek> I've just stripped it down to unix+winbind; still no errors
[10:00]  * ttx grumbles -- for some reason I can't login even with winbind disabled
[10:00]  * ttx digs deeper
[10:01] <slangasek> ah :)
[10:06] <ttx> hmm, I must have forgotten the password I used in my ISO install (or mistyped it... twice??!), let me re-reproduce cleanly :)
[10:07] <ttx> or.. maybe the password was not set correctly at the end of the install on top of the borken stack.
[10:09] <ttx> ew, and the primary user is not added to sudoers group either
[10:10] <slangasek> check for a password hash in /etc/shadow?
[10:10] <slangasek> (if you haven't already clobbered it)
[10:10] <ttx> I clobbered it
[10:10] <ttx> but I'm reproducing on another box
[10:10] <slangasek> ok
[10:10] <slangasek> I was musing that this might be a possibility
[10:11] <slangasek> but that means the installer isn't letting the user know about failures setting the password?
[10:12] <ttx> I'll have a look at the install console and see if there is something showing, but yes, I'd suspect the installer wouldn't let you know about it
[10:13]  * ttx reboots in single-user mode to get sufficient privileges to access that profiles tarball
[10:14] <slangasek> I expect better than that of the installer :)
[10:18] <ttx> took longer than expected, but here you go:
[10:18] <ttx> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/546874/comments/17
[10:18] <ttx> I'm reproducing on an unclobbered new install to look at the state of the passwd file
[10:20] <ttx> slangasek: confirmed, no passwd hash entry on the regular user in /etc/shadow at the end of the install
[10:20] <slangasek> yay
[10:22] <ttx> also the installer logs show that it fails
[10:22] <ttx> chpasswd pam_winbind failure
[10:22] <ttx> WBC_ERR_WINBIND_NOT_AVAILABLE
[10:23] <ttx> warning: /usr/lib/finish-install.d/06user-setup returned error code 1
[10:23]  * slangasek nods
[10:23] <ttx> but that's apparently not a blocking error.
[10:26] <ttx> slangasek: so the "even on console" answer above might be biased: doing it "from ISO" like this will end up with no passwd set, so you obviously can't login even on console.
[10:27] <ttx> that doesn't mean the pam stack would prevent you from doing so, given that there is a good passwd entry set.
[10:27]  * ttx checks on an already-installed system
[10:30] <slangasek> ttx: so the fix to winbind is pretty straightforward, I think
[10:30] <slangasek> 1) call pam-auth-update in winbind.postinst
[10:30] <ttx> (and prerm)
[10:31] <slangasek> 2) Password-Type: Primary instead of Password-Type: Additional in debian/winbind.pam-config
[10:32] <ttx> ah, so the auth stack was never wrong, just the password stack
[10:32] <ttx> with the ISo installs blurring the line
[10:34] <ttx> slangasek: if that's all it takes, I'll assign me and target to beta2, if that's ok with you
[10:35] <mvo> ttx: bug #556332 - bind9 is acting strange here, feedback welcome
[10:35] <mvo> ttx: not a showstopper or anything, but really odd IMO
[10:35] <ttx> mvo: I'll add it to the hit list
[10:35] <ttx> mvo: thanks
[10:36] <slangasek> ttx: sure, go ahead
[10:37] <slangasek> (still doesn't explain some people who are reporting *recent* problems being able to log in, but we can at least fix the installer case this way)
[10:38] <ttx> most people report passwd-changing issues. The ones with login problems are usually beta ISo testers
[10:38] <ttx> so that seems coherent
[10:39] <slangasek> re: the prerm, I've already committed the fix for that in Debian Samba svn; but it's bound up now with the question of whether Debian is doing 3.4 or 3.5 for squeeze, so you'll need to cherry-pick
[10:40] <ttx> ok
[10:49] <mvo> ttx: and bug #556343
[10:49] <mvo> ttx: more important as it causes a real failure
[11:01] <slangasek> ttx: bug #546874's submitter claimed that logins were broken, only after an upgrade, and he installed from a desktop - I don't see any way that winbind would get pulled in immediately as part of a desktop install so the initial password setting should still be correct, and anyway we have his statement that it broke only after upgrade
[11:01] <slangasek> so there's some other bug here, still
[11:03] <ttx> ah, yes, got lost in duplicates.
[11:06] <ttx> slangasek: did you get some answer about removing the wine rdepends ?
[11:11] <cjwatson> ttx: still catching up from holiday - syncing and having a look, may take a while
[11:20] <ttx> cjwatson: ack
[11:20] <slangasek> ttx: no
[11:21] <slangasek> ttx: I also didn't file a bug about it; would you care to, or should I do so in the morning?
[11:21] <ttx> slangasek: I'll do it
[11:21] <cjwatson> that winbind failure in user-setup above might well cause some odd knock-on effects, despite not blocking
[11:21] <slangasek> python-pkg-resources> curses, one o-o-d package on all ISOs now
[11:22] <slangasek> cjwatson: it causes knock-on effects like a successful install w/o an authenticatable user, apparently...
[11:24] <cjwatson> yes, I can believe that.  needs rather better error handling, but for now we need to fix the failure anyway ...
[11:24] <slangasek> yep
[12:42] <ttx> slangasek: here is the winbind fix ^
[13:17] <ScottK> slangasek: Last week you removed libannodex, but left pyannodex.  Would you please remove that too?
[13:17]  * ScottK reports a bug.
[13:19] <cjwatson> ttx: is there a bug open for the server splash still not working?  (if not, don't bother filing one, just want to check if I should be closing one)
[13:21] <ttx> cjwatson: no, I just commented on the existing one, wasn't sure which task I should reopen, if any
[13:21] <ttx> I was wondering if something wasn't just waiting for a respin to trigger
[13:23] <cjwatson> no, it's a bug
[13:24] <cjwatson> I'll reopen the existing bug, then
[13:24] <cjwatson> the "could not write bytes: broken pipe" bit is unrelated, but I think there's already a bug somewhere for that
[13:29] <cjwatson> parted: not needed for beta-2
[13:57] <cjwatson> could somebody please review grub-installer?  RC IMO, to fix ttx's problem above
[13:59] <ttx> yes, we definitely need the potentially-final server boot experience in beta2 for testing :)
[13:59] <cjwatson> it also needs another debian-cd change, which I have prepared and ready to go
[14:09] <ScottK> cjwatson: Looks good to me.  Accepting.
[14:10] <ScottK> Done.
[14:12] <cjwatson> ScottK: thanks
[14:15] <ScottK> cjwatson: I know there isn't any documentation in the package to be affected, but is there online documentation about customization that needs updating for splash=false instead of nosplash?
[14:17] <cjwatson> ScottK: I wouldn't expect so - nosplash is very new, on the order of days
[14:17] <ScottK> OK.  Thanks.
[14:18] <ScottK> "If your documentation is that bleeding edge, you need to be paying attention"
[14:24] <ttx> cjwatson: could you respin a Server ISO / beta2 candidate whenever that fix lands ? Also the samba in the queue (unbreaking the samba-server task) would be good to have in the next candidate.
[14:29] <cjwatson> planning to
[14:29] <cjwatson> would prefer somebody more domain-competent to review samba, though
[14:35]  * ScottK is fixing quediff to work with .bz2 orig 
[14:37] <ScottK> Done, so it can be used by whoever has the domain-competence to review it.
[16:02] <james_w> any thoughts on https://bugs.edge.launchpad.net/ubuntu/+source/xpdf/+bug/556483?
[16:02] <james_w> no new features, but rewritten packaging, would that require an exception?
[16:05] <ScottK> james_w: Generally yes.
[16:49] <Riddell> ev: thanks for fixing bug 556180
[16:49] <ev> sure thing
[16:59] <Riddell> ev: planning a ubiquity upload at some point?
[17:00] <ev> Riddell: yeah.  I was hoping to get Ken's timezone map changes in, but as those will require an exception, I might as well do an upload now so that your fixes don't block on that.
[17:01] <Riddell> ev: changing the SVG requires a UI freeze exception?
[17:01] <ev> I had assumed so
[17:02] <Riddell> doesn't seem like a big enough change to need that, I doubt we have many screenshots of the map with India or Pakistan selected
[17:03] <ev> Russia as well, but noted
[17:03] <Riddell> Russia claims Kashmir?
[17:03] <cjwatson> some of Russia's timezones changed a bit recently
[17:04] <cjwatson> I agree, I think it's worth notifying the doc team but I don't think it needs freeze paperwork really
[17:04] <ev> okay cool, I'll take care of this first then
[17:10] <ScottK> Bug #556629 is potentially significant.
[17:27] <ev> if anyone has some free cycles, I'd appreciate a review of bug 554570 and bug 554976
[17:45] <ev> Riddell: ubiquity 2.2.15 is in the queue
[17:51] <Riddell> ev: accepted!
[18:21] <mvo> http://people.ubuntu.com/~mvo/automatic-upgrade-testing/current/ looks not that great currently (but server-tasks and lts-ubuntu should really only be WARN and not FAIL, the bugs are not that serious)
[18:25] <GrueMaster> Riddell: Does this mean there will be a respin for Ubiquity 2.2.15?
[18:25] <Riddell> GrueMaster: for Kubuntu yes, probably the rest too if we want to keep the Kashmir lobby happy
[18:26] <GrueMaster> sigh.  I'm doing the ubuntu-armel testing.  Takes a lot longer than desktop or netbook due to limited resources.
[18:27] <GrueMaster> And I hate having to recompile my bug lists.
[18:32] <Riddell> such is the world of ISO testing, slow and painful
[18:32] <Riddell> surely launchpad can handle bug lists
[18:33] <ttx> slangasek: please review the samba (winbind) fix whenever you have the time, and respin server ISo / refresh beta2 server candidate when it lands
[18:34] <ttx> slangasek: ping smoser when done so that he can generate EC2 cloud image candidates
[18:35] <Riddell> ttx: not sure if slangasek is around just now, maybe another release team member should help?
[18:36] <ttx> Riddell: iirc most of them declined to review the samba as not being in their domain, but yes, anyone can help :)
[18:40] <Riddell> ttx: I accepted samba
[18:41] <ttx> Riddell: ok, so when it lands, we could use a server ISo respin/ candidate refresh, the sooner the better
[18:41] <Riddell> disabled current images in tracker
[18:42] <Riddell> ev: we want new ubuntu desktop images I take it?  I should disable those in tracker too?
[19:06] <slangasek> ttx, Riddell: samba> thanks
[19:07] <slangasek> ScottK: libannodex> yes, was going to file that bug myself prior to removal
[19:25]  * cjwatson writes an interactive version of packageset-push in the hope that that will enable him to keep up with packageset changes a bit more effectively
[19:47] <charlie-tca> Are you going to respin xubuntu?
[19:47] <charlie-tca> 7q83+TKbzFN
[19:50] <slangasek> the ubiquity changes would also apply to xubuntu, but I wouldn't think it's critical
[19:51] <charlie-tca> okay
[19:51] <cjwatson> charlie-tca: might want to change that password :)
[19:51] <charlie-tca> yeah, good thing it is for testing, huh
[19:53] <slangasek> so bug #519541 keeps getting reported as a serious bug in all the xubuntu tests, but it has no assignee?
[19:54] <charlie-tca> yup
[19:54] <charlie-tca> It completely freezes abiword, the Xubuntu default word processor. If the document is not already saved, it is lost
[19:55] <slangasek> yes, I understand it's a serious bug, that's not the question - the question is why no xubuntu dev has taken responsibility for it
[19:56] <charlie-tca> I don't know. I keep telling them about it, too.
[20:15] <slangasek> Riddell: what did kubuntu alternate need respun for?
[20:15] <Riddell> slangasek: I don't think it did, did I mark that in iso tracker?
[20:16] <Riddell> fixed
[20:16] <slangasek> ok, cheers
[20:16] <slangasek> I'm going to start the respins now
[20:16] <slangasek> assuming I'm not colliding with you :)
[20:16] <Riddell> go ahead
[20:17] <Riddell> although `ls cdimage/ftp/pool/main/u/ubiquity/*2.2.15*` is empty on antimony, I take it that's not what counts?
[20:18] <slangasek> GrueMaster: I don't think I'll respin armel netbook for the ubiquity change; I don't imagine there are a lot of ARM hardware vendors is Kashmir that are going to come after us for an inaccurate beta map
[20:18] <GrueMaster> cool
[20:18] <slangasek> Riddell: nope, antimony's mirror is updated /by/ the ISO job
[21:37] <slangasek> ev, cjwatson: any other installer issues on the horizon that look like they could be beta blockers?
[22:05] <slangasek> all respins done/posted except for DVD
[22:10] <cjwatson> slangasek: not that I've seen so far, but I've been feeling ill this evening so am not as on top of bugs as I'd like :-/
[22:12] <slangasek> understood
[22:12] <slangasek> aside from the last kubuntu issues, the ISO tracker looks (deceptively?) calm
[22:59] <kees> ScottK: are you around to push selinux and refpolicy-ubuntu for me?
[23:08]  * kees thanks mystery pusher
[23:15] <mdeslaur> lol
[23:18] <slangasek> lamont, elmo: old-releases.u.c requires a manual push, is that right?
[23:18] <slangasek> (I've dropped intrepid from releases.u.c, but I don't see it showing up on old-releases)