[08:44] <infinity> pitti: The new udev-udeb has a non-udeb dependency (libacl1).
[08:45] <infinity> pitti: Either need to build it in a way to drop that dep, or we need a libacl-udeb.
[10:21] <infinity> pitti: unping, re: udev/acl.  Uploaded a fix.
[12:07] <chrisccoulson> infinity, chromium finished building on arm overnight \o/
[12:08] <chrisccoulson> (i'll try to run it later)
[12:15] <infinity> chrisccoulson: Oh, that's good news.  I just finished force-hinting the broken stack into raring, so udev/systemd could migrate, but an upload that actually builds would be FAR better. :P
[12:19] <ogra_> chrisccoulson, !
[12:20] <infinity> ogra_: Don't get your hopes up, it still might not run. :P
[12:20] <ogra_> yeah
[12:20] <ogra_> but its at least one step forward
[12:21] <ogra_> i still dont get why though ... given that chromeos/chrome runs just fine so it *must* be possiblle to get it working
[12:21] <infinity> There seems to be some serious left-hand/right-hand lack of communication there.
[12:22] <ogra_> yes
[12:22] <infinity> I don't know if jbailey still works on that, but I should talk to him about WTF is up.
[12:22] <infinity> Though, that mostly just accounts for failures to build (the right/left thing).
[12:22] <infinity> The failures to RUN could be v8 having bugs with armhf register usage, etc.
[12:22] <ogra_> qwell, and there are Keybuk and kees too
[12:22] <infinity> Unless ChromOS is now armhf too?
[12:23] <ogra_> it is
[12:23] <infinity> Ahh, so even fewer excuses now.  Lovely.
[12:23] <ogra_> i'm using their flash plugin in my ubuntu chromium all day here
[12:23] <ogra_> and i can run the whhole chromeos desktop in a window under unity too :)
[12:24] <ogra_> by just firing it up from /opt
[12:25] <ogra_> not that unity would be very useful (doesnt get along with mali drivers to use HW accel it seem ... everything else does though) or that chromeos in a window would
[12:26] <ogra_> but for laughs and testing it is fine :)
[12:50] <jtaylor> slangasek: you m-a'ed tcl recently, will you also do tk for raring?
[12:54] <infinity> jtaylor: That was xnox, actually.
[12:55] <infinity> Or maybe wookey, sponsored by xnox, looking at the changelog.
[12:56] <xnox> that.
[12:56] <xnox> i guess everyone is pieced off about it, so i should multiarch tk & ship compat shell config script.
[12:57] <jtaylor> having tk and tcl in the same state would be good
[12:57] <infinity> There needs to be a compat script?  What broke?
[12:57] <jtaylor> as they are kind of related
[12:57] <jtaylor> just a bad configure check in a science package
[12:57] <xnox> infinity: TkConfig.sh script moved from /usr/lib/ to /usr/lib/$(multiarch)
[12:58] <xnox> (and tcl)
[12:58] <jtaylor> my concern is just if I fixx it for tcl now, do I need to revisit it for tk in a few days?
[12:58] <infinity> Oh.  That's arch-specific? :/
[12:58] <xnox> infinity: but those config scripts can totally be dpkg-architecture & call the right script.
[12:59] <xnox> not to break stuff that expects that config script to be there.
[12:59] <infinity> Yeahp, that would work.
[12:59] <xnox> jtaylor: well, you can totally test for tk m-a, and try that, if not try normal one, and then bail.
[13:00] <jtaylor> thats what the bad configure dos
[13:01] <infinity> I'm not sure there's any value in patching upstream sources to look for the M-A config script at all, if you're going to put the compat one in.
[13:01] <jtaylor> a enormous list of possible locations it checks :)
[13:01] <jtaylor> instead of just doing a try link
[13:01]  * infinity gets the kernels and d-i to migrate and calls it a night.
[13:02] <jtaylor> the simplest fix for thix package is just add --with-tcl-library=/usr/lib/$(DEB_HOST_ARCH)
[13:02] <jtaylor> but do I need to do that for tk too in a few days or not?
[13:02] <infinity> DEB_HOST_MULTIARCH even.
[13:02] <jtaylor> yes
[13:03] <infinity> But if xnox adds the compat scripts, you don't need to change anything.
[13:03] <infinity> And it'll all just work again.
[13:03] <infinity> Which seems like a whole lot less effort. :P
[13:03] <jtaylor> the configure does not sue the script
[13:03] <infinity> Oh.
[13:03] <infinity> It's looking for the .so?
[13:03] <jtaylor> yes
[13:03] <infinity> People who do that should be shot.
[13:04] <infinity> I'd switch to either the config script or a try link and forward it upstream, instead of adding to the brain damage.
[13:05] <jtaylor> the funny thing is they do that too
[13:05] <jtaylor> but only after checking for the so in the hardcoded locations
[13:05] <jtaylor> very weird :)
[13:05] <infinity> So, you could just delete the .so checks?
[13:05] <infinity> Also very valid.
[13:06] <infinity> The only argument for .so checks is if you're dlopening a hardcoded path.  Which is, in itself, wrong.
[13:06] <infinity> At least, it's wrong if the library is on the search path, since this isn't 1975, and dlopen() is smart.
[13:07] <jtaylor> afk 15 min
[13:24] <cjwatson> jtaylor: I'm in the process of multiarching it - was working on it end of last week
[13:24] <jtaylor> k so it will be done, thanks thats all I wanted to know
[13:24] <cjwatson> because it's just madness for one of tcl and tk to be multiarched and the other noe.t
[13:24] <cjwatson> *not
[13:25] <jtaylor> yes I though too
[13:25] <cjwatson> If anyone's really desperate, my current work is http://paste.ubuntu.com/5619256/
[13:25] <cjwatson> But I plan to get that uploaded early next week once I've prepared corresponding tcltk-defaults changes and done some testing with the ruby1.8 build
[17:09] <guest16950> hello
[17:09] <guest16950> question:
[17:09] <guest16950> ubuntu XX.04 usually gets released at the end of april
[17:10] <guest16950> but windows xp support will end at 8th of april 2014 (beginning of april)
[17:10] <guest16950> are you planning to release ubuntu 14.04 prior or on the the 8th of april ;p?
[17:11] <guest16950> probably would be a good move, wouldn't it ;)?
[17:11] <guest16950> just saying
[17:14] <ScottK> guest16950: The release date was set almost half a year ago.  It's a bit late to change it now.
[17:23] <ogra_> ScottK, really ?ho set it ?
[17:23] <ogra_> *who even
[17:23]  * ogra_ wasnt aware we had a 14.04 date 
[17:23] <ScottK> ogra_: Oh.  Sorry, I misread his comment.
[17:23] <ogra_> :)
[17:24]  * ScottK was thinking 13.04.
[17:24] <ogra_> yeah, me too first, i had to read twice
[17:26] <ScottK> OTOH, 10.10.10 was so annoying, I'm sure I don't want to release at the start of the month.
[17:27] <ogra_> well, depends what the TB decides ... if there is actually a six month cycle before yeah ...
[17:27] <ogra_> in a rolling model two weeks dont really hurt
[17:32] <guest16950> just imagine how many users still are using windows xp ;)
[17:32] <guest16950> and on the 8th of april 2014 they have to look for a new os
[17:33] <guest16950> because ms won't provide any updates to xp any longer from that date on ;)
[17:33] <guest16950> (according to the current plan)
[17:33] <guest16950> having 14.04 ready until or on that date sounds like a good idea to me ;)
[17:35] <guest16950> btw: i really hope the following bug:
[17:35] <guest16950> https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/578045
[17:35] <guest16950> will be fixed until then ;)
[17:44] <ScottK> ogra_: I hope the discussion at the TB will coalesce around Mark's latest proposal.  It seemed generally reasonable to me.
[17:44] <ogra_> well, i dont know how much rick wants to still push his proposal ... so we'll see
[17:45] <ogra_> but yeah, marks is definitely sensible
[17:52] <slangasek> jtaylor: no, I didn't :)
[17:53] <jtaylor> slangasek: found the "culprit" already
[17:53] <jtaylor> but you are wookey on oftc or?
[18:00] <ScottK> jtaylor: He's vorlon on oftc.
[18:01] <jtaylor> oh
[18:01] <jtaylor> sorry, mixed that up
[18:01] <slangasek> yes, wookey is wookey everywhere
[18:16] <penguin42> it's the only name he has
[18:25] <jcastro> If there's a backport request that deals with a major bug in a package with a fix I need to ping .... ?
[18:25] <jcastro> can someone fill in the blank for me?
[18:27] <ScottK> jcastro: With a package that's already been backported?
[18:27] <jcastro> I don't think it's been backported yet
[18:27] <ScottK> jcastro: It kind of depends on the specifics.
[18:27] <jcastro> https://bugs.launchpad.net/precise-backports/+bug/1095056
[18:27] <jcastro> is the bug in question
[18:28] <jcastro> someone pinged me about it, seems like there's a fix available, I just need to know what the next step is
[18:28] <jcastro> getting people to test the backport?
[18:29] <ScottK> Someone needs to test unhide and unhide.rb with it.
[18:30] <ScottK> If those work, then it can be backported.  Feel free to ping me and I'll do it if no one else is around.  Laney or micahg could too.
[18:30] <jcastro> ok, I'll get the guy to post his findings on the bug
[18:30] <jcastro> thanks!
[18:31] <ScottK> You're welcome.