[00:00] <jtaylor> well it builds and pyside builds (with a couple new failures which might not necessarily be related)
[00:01] <jtaylor> when I finally get a raring install going I wanted to test some basic functionality
[00:01] <jtaylor> and hope upstream replies at some point ...
[00:01] <jtaylor> if not I guess upload and hope for the memleak is not too bad
[00:01] <jtaylor> and if it is replace it with the crash again ^^
[00:02] <jtaylor> I'd say we should decide before feature freeze
[00:03]  * jtaylor offline
[00:06] <cjohnston> jtaylor: I'm able to test with raring if you want some assistance
[07:29] <dholbach> good morning
[07:31] <ESphynx> 'morning dholbach :)
[07:32] <dholbach> hey ESphynx
[07:48] <dholbach> To everyone who speaks a language apart from English: please help out with translating: https://translations.launchpad.net/ubuntu-packaging-guide/ :-)
[07:48] <dholbach> thanks
[07:48]  * dholbach will do a page of German translations now
[07:49] <dholbach> wow... the Brazilians are getting close to the magic 70% mark: pt_BR.po (64%) :-)
[17:45] <jtaylor> wtf
[17:46] <jtaylor> su: System error in my chroot
[17:46] <jtaylor> what does that mean? it worked yesterday ._.
[17:48] <jtaylor> I need to test something, can someone build http://incoming.debian.org/sundials_2.5.0-3.dsc in raring and check the dpkg-shlibdeps output?
[17:54] <tumbleweed> is week-old raring ok? (my local mirror is on the blink)
[17:56] <jtaylor> yes
[17:58] <jtaylor> weird unstable chroot works
[17:59] <tumbleweed> talknig of which, mirror-maintainer-poking-time...
[18:01] <jtaylor> hm quantal works too, should be sufficient for the test
[18:01] <jtaylor> tumbleweed: you may abort if you like, thanks
[18:04] <tumbleweed> jtaylor: it finished. all I saw was
[18:04] <tumbleweed> dpkg-shlibdeps: warning: symbol N_VNewEmpty_Serial used by debian/libsundials-nvecserial0/usr/lib/libsundials_fnvecserial.so.0.0.2 found in none of the libraries
[18:04] <tumbleweed> dpkg-shlibdeps: warning: symbol N_VCloneVectorArrayEmpty_Serial used by debian/libsundials-nvecserial0/usr/lib/libsundials_fnvecserial.so.0.0.2 found in none of the libraries
[18:04] <jtaylor> only those two? good
[18:05] <tumbleweed> yeah
[19:43] <Rhonda> Subject: problem
[19:43] <Rhonda> blad 502 getaway
[19:44] <Rhonda> … and that's all of the mail.  I can just *assume* that it's meant to be related to packages.ubuntu.com, but who knows.  Mails get weird these days.
[19:44] <Logan_> This may be a silly question, but, as a MOTU, do I also have to be part of ubuntu-sponsors to sponsor stuff for people?
[19:45] <jtaylor> no
[19:45] <jtaylor> grats on motu btw
[19:45] <Logan_> Cool, thanks. :)
[19:46] <tumbleweed> Logan_: being a membor of ubuntu-sponsors allows you to unsubscribe the team from bugs
[19:46] <tumbleweed> that's about it
[19:46] <Logan_> Oh, I see. So it's more of an administrative thing.
[19:46] <tumbleweed> yeah
[19:47] <Logan_> Still waiting on my cloak (*cough* Pici *cough*) ;)
[20:00] <Logan_> Is sync package not working for anyone else?
[20:00] <Logan_> *syncpackage
[20:00] <jtaylor> what happens?
[20:01] <Logan_> jtaylor: http://paste.ubuntu.com/5571510/
[20:01] <Logan_> It's weird because it was definitely working yesterday.
[20:02] <tumbleweed> Timestamp appears to come from bad system clock
[20:02] <Logan_> I checked my system time, and it is correct.
[20:02] <Logan_> I even did a dpkg-reconfigure of tzdata.
[20:03] <Logan_> …wait, no it's not.
[20:03] <Logan_> I set it to EST, and it says "Local time is now: Wed Feb 27 11:43:13 EST 2013."
[20:03] <Logan_> And it's 3:03 PM...
[20:03] <jbicha> Logan_: by the way, when the sponsoree doesn't have a public email address in LP, you probably don't want to use the -s option
[20:05] <Logan_> kk
[20:05] <tumbleweed> and that bug wasn't a sync request
[20:07] <Logan_> But, since it, by the nature of the new version of the software being in experimental, fixes the bug, shouldn't I mark that bug as fixed by the sync?
[20:07] <Logan_> (Or are you just saying that I shouldn't include a sponsor?)
[20:07] <Logan_> *sponsoree
[20:07] <tumbleweed> yeah, the sponsoring
[20:07] <Logan_> Ah, okay.
[20:09] <Logan_> Another question (sorry) - when it says to wait for the sync to be successful before closing the bug, does that mean I should wait until the package has been built/accepted into the archive?
[20:09] <Logan_> Or should I just wait until I get the e-mail saying the sync was acknowledged?
[20:10] <tumbleweed> so, syncpackage sends a sync request to LP
[20:11] <tumbleweed> LP doesn't actually do that immediately, but queues it
[20:11] <tumbleweed> when it does get around to looking at it, it may reject the sync
[20:11] <tumbleweed> so, either leave it open until you get an email saync it synced, or remember to go back and re-open syncs, if it gets rejected
[20:11] <Logan_> Okay, awesome.
[20:12] <tumbleweed> *sayng, *re-open bugs
[20:12] <tumbleweed> I'm typing sync too much :P
[20:12]  * ScottK can't remember the last time he had one rejected, so has a strong opinion on which option is less work.
[20:13] <tumbleweed> yeah, I put that prompt in before we really had a feel for how it would work
[20:16] <ajmitch> probably best to wait until you know the package has built successfully & been published
[20:16] <tumbleweed> we should really just add bug-closing support to syncs in LP
[20:17] <tumbleweed> although, that's probably hard
[20:17] <tumbleweed> for normal uploads, the bugs get closed on copy into -release, right?
[20:18] <Laney> yeah
[20:18] <Laney> or -updates
[20:20] <tumbleweed> so, if we wanted to attach bug closing to a sync, it'd have to be attached to the SPPH
[20:24] <jtaylor> got a step closer to installing raring
[20:24] <jtaylor> if I pull out the usb before starting the step that hangs it continues
[20:24] <jtaylor> but of course the test fails with io errors then
[20:25] <jtaylor> I probably have to try a cd ._.
[21:28] <Laney> tumbleweed for DPL!
[21:28] <Laney> (re -vote)
[21:28]  * tumbleweed hides
[21:30]  * ajmitch seconds


[20:01] <adom> just found out the hard way that whomever provisioned the rack I'm working on decided to power the APC using two daisy-chained power cables, but they didn't feel the need to zip tie or crosstie the cables at all.
[20:01] <adom> so when you pull on an APC power cable to get a little slack, the whole thing powers down and half the rack goes offline.
[20:02] <adom> awesome
[20:05] <ChinnoDog> doh
[20:06] <ChinnoDog> Time to set some standards for data center wiring.