[00:02]  * ajmitch looks for someone to blame
[00:03]  * Laney wonders when ajmitch is going to sort out the udd mirror :P
[00:03] <ajmitch> Laney: that's what I was trying to do this morning, 3GB wasn't enough for postgres
[00:05] <Laney> :(
[00:12] <ashams> Hey guys, I'm new and want to get the vlc source code for lucid through bzr, but I can see 4 branches on lp for it, which one should I pull?https://code.launchpad.net/ubuntu/lucid/+source/vlc
[00:13] <ashams> https://code.launchpad.net/ubuntu/lucid/+source/vlc
[00:17] <RAOF> ashams: bzr branch ubuntu:lucid/vlc should get what's in the lucid archive, IIRC.
[00:17] <ashams> RAOF, I tested it but it doesn't give me anything
[00:18] <ashams> bzr: ERROR: Not a branch: "/home/ashams/ubuntu:lucid/vlc/".
[00:18] <ashams> oops
[00:18] <ashams> my bad
[00:18] <StevenK> lp:ubuntu/lucid/vlc
[00:19] <ashams> StevenK, it worked , thanks
[00:19] <ashams> Thanks RAOF
[00:21] <broder> err, that would be the one that was released with lucid
[00:21] <broder> there have been SRUs and security updates since then
[00:21] <broder> so you'd actually want lp:ubuntu/lucid-updates/vlc
[00:24] <ashams> broder, I see
[00:24] <ashams> ok, I'll get it instead
[00:24] <ashams> thanks
[01:58] <ockham_> hi, i've just uploaded unity-lens-bliss to REVU. anyone feel like reviewing it?
[01:58] <ockham_> http://revu.ubuntuwire.com/p/unity-lens-bliss
[06:17] <broder> tumbleweed: do you think requestbackport is stable enough that we could backport it to oneiric?
[06:25] <ajmitch> broder: I've imported the udd data now on qa.uw.org thanks to wgrant sorting out some more diskspace
[06:32] <tumbleweed> \o/
[06:34]  * ajmitch still has to sort out what postgres permissions go where, but at least the data's in & there's ~20GB of free space in the VM if you want to run some stuff
[06:37] <tumbleweed> broder: after the next udt upload
[08:08] <dholbach> good morning
[10:40] <l3on> broder, hi! :)
[10:41] <l3on> I see your comment here: bug 896902
[10:41] <l3on> sould I patch source to handle return value???
[10:41] <l3on> *should
[10:44] <tumbleweed> ...and actually do something sane with it (I've seen far too many patches for that kind of issue that catch the return value and proceed to do nothing)
[10:44] <tumbleweed> yes, patches like that are useful, and should be submitted upstream too
[10:45] <l3on> well.. tumbleweed where's upstream? :D
[10:45] <tumbleweed> it's a program handling passwords, so it would be nice if it was doing a good job
[10:45] <l3on> there's nothing in debian/control handling homepage
[10:46] <tumbleweed> https://launchpad.net/gtk-led-askpass by the look of it
[10:46] <tumbleweed> err, no, no code there
[10:47] <tumbleweed> but the copyright file indicates that the DD who packaged it in Debain, wrote it
[10:47] <tumbleweed> ah, it started out as a native package
[11:39] <tumbleweed> Laney: imported that test set again
[11:39] <tumbleweed> I'm giving it a once-over
[11:47] <tumbleweed> Laney: we still have N/A signed-bys. I'm guessing they are syncs
[11:58] <Laney> likely
[11:58] <tumbleweed> I can add signed-by, but I don't know how useful that'll be
[11:59] <Laney> blank would be a good way of detecting autosyncs
[11:59] <tumbleweed> autosyncs are easy to detect from changed_by_email=katie
[12:00] <capeta> I'm trying to create my own .deb package of nginx using checkinstall but it don't work, I'm using the sources of 'apt-get source nginx' and downloading the two new modules manually. It configure, using the ./configure with the same parameters of the official package plus new modules, compile (make) but the .deb generated (by the checkinstall) don't work. Anyone knows what I'm doing wrong?
[12:01] <tumbleweed> capeta: we don't build debs with checkinstall
[12:02] <Laney> changed_by_name = "Ubuntu Archive Auto-sync"
[12:02] <capeta> and where my .deb package came from?
[12:04] <tumbleweed> Laney: what I'm asking is, for consistency, should I add: if not signer: signer=changedby
[12:04] <Laney> what's the invariant?
[12:04] <Laney> signer should be the person who did the upload
[12:05] <tumbleweed> agreed
[12:05] <tumbleweed> and should it be katie for autosyncs? I'm happy with N/A there, but if we want N/A we have to special-case it
[12:05] <Laney> hmm
[12:05] <Laney> just though
[12:05] <Laney> t
[12:05] <Laney> we should make sure that all the fields come out right when sync sponsoring is worked out
[12:06] <Laney> i.e. clarify it in the bug
[12:07] <Laney> let's go for having signed_by in all cases
[12:07] <tumbleweed> sure, although that's for the mailing list
[12:07]  * tumbleweed has a separate bug for -changes mail being a bit crazy for syncs
[12:08] <Laney> for syncs, we have creator = requestor, changed = original uploader in Debian
[12:08] <Laney> we should make sure that they set signed = sponsor when this bug is fixed
[12:09] <tumbleweed> yup
[12:18] <Laney> actually that's not right, weird
[12:18] <tumbleweed> hrm?
[12:18] <tumbleweed> I've just pushed my proposed change. Will run again...
[12:18] <Laney> package_creator, package_maintainer = Debian /Maintainer/ (i.e. pkg-haskell-maintainers in this case)
[12:22] <tumbleweed> oh, great, looks like some dapper-era syncs had the demian uploader as Changed-By
[12:22] <tumbleweed> so, one should detect autosyncs by looking for signed_by = katie
[12:23] <Laney> newer ones are archive@ubuntu.com afaik
[12:23] <tumbleweed> we need a 20 page guide on using this data without killing yourself
[12:23] <Laney> you need to look for changed_by_name
[12:23] <Laney> err, signed_by_name
[12:23] <tumbleweed> yes :)
[12:23] <Laney> http://paste.debian.net/147425/ ?
[12:25] <tumbleweed> Laney: ok
[12:26] <tumbleweed> s/dapper-era//
[12:27] <Laney> history is fun
[12:27] <tumbleweed> turns out it's present, too
[12:27] <tumbleweed> I'm wondering if we should make our Changed-By only refer to the ubuntu developer whe requested the sync, but I don't know if we have the data for that
[12:31] <Laney> for which syncs?
[12:32] <tumbleweed> well, ideally it'd be all or nothing
[12:33] <Laney> I am under the impression that most manual syncs have that
[12:34] <tumbleweed> native syncs definitly have enough information
[12:38] <Laney> https://launchpadlibrarian.net/75056838/log4net_1.2.10%2Bdfsg-5_source.changes
[12:38] <Laney> that's an old manual sync
[12:38] <Laney> looks ok
[12:41] <Laney> we should bug elmo for the ancient data too :-)
[12:43] <tumbleweed> Laney: hrm, that does look right
[12:43] <tumbleweed> but I grepped for Changed-By:.*alioth and found quite a bit
[12:59] <ockham_> hi, i've uploaded unity-lens-bliss to REVU. anyone feel like reviewing it?
[12:59] <ockham_> http://revu.ubuntuwire.com/p/unity-lens-bliss
[13:52] <wzssyqa> any idea about https://bugs.launchpad.net/ubuntu/+source/tclcl/+bug/897158?
[13:55] <tumbleweed> wzssyqa: re: They seem being same. I have no idea why this happens
[13:56] <geser> wzssyqa: the "problem" is that those symbols are missing (in the test build; therefore the prepending #MISSING: lines you see in the diff)
[13:56] <tumbleweed> what geser said
[13:57] <geser> wzssyqa: compare your test-build log with the build from Debian and check if you see any differences (e.g. from configure or similar)
[13:58]  * tumbleweed is guessing compiler differences here
[13:58] <wzssyqa> geser: all of these lines are in my symbol file
[13:59] <tumbleweed> oh, maybe not
[14:11] <wzssyqa> tumbleweed: geser will it happen if buildflags are not the same ?
[14:12] <tumbleweed> very likely
[14:12] <tumbleweed> basically, the problem here is that the shared library doesn' thave symbols that are expected (and, I haven't checkde a full build log, so I don't know if it has unexpected symbols)
[14:17] <wzssyqa> tumbleweed: y, after change buildflags, it fails on Sid now
[14:19] <tumbleweed> wzssyqa: what was the difference?
[14:21] <wzssyqa> tumbleweed: dpkg-buildflags vs nothing
[14:30] <tumbleweed> wzssyqa: interestingly, it's the -O2
[14:30] <tumbleweed> I suggest you file a bug in Debian, requesting that the maintainer use dpkg-buildflags :)
[14:31] <wzssyqa> tumbleweed: if compat is 7, then without -O2, if compat is 8 or 9, it will use -O2
[14:32] <tumbleweed> wzssyqa: yes, that's because dh exports buildflags at compat level 9 (at 8, really?)
[21:36] <tumbleweed> Laney: hrm, still seem to have some Signed-By: N/As
[21:36] <tumbleweed> (mostly kernel uploads)
[21:37] <Laney> probably some weird ppa business
[21:37] <Laney> if it's not many i wouldn't worry
[21:38]  * tumbleweed tries to figure out why
[21:42] <Laney> I thought you added if not signedby: signedby = changedby
[21:44] <tumbleweed> it looks like a bug in person_to_name_email because sconklin doesn't have a public e-mail address
[21:44]  * tumbleweed contemplates caching all the e-mail addresses we've read from changes files. But that's evil :P
[21:46] <Laney> line 58 doesn't work?
[21:48] <tumbleweed> Laney: it returns N/A rather than Name <N/A>
[21:49] <Laney> oh, because you get ValueError
[21:51] <awsoonn> Hi all, I'm trying my luck at debugging a kernel oops that has been runing my day for about a week now....
[21:51] <awsoonn> where is some good documentation to start chewing on? bug 897883
[21:52] <awsoonn> i am assuming I will need to build my own kernel with debugging symbols in order to make any headway? tips and guidance greatly appreacated.
[21:58] <Laney> awsoonn: I don't know if anyone in here knows much about the kernel; #ubuntu-kernel might be a better place to look
[21:58] <awsoonn> Laney: wonderful sugestion, onward down teh rabbit hole I go~
[21:59] <Laney> sorry
[22:00] <tumbleweed> Laney: were there other situations that gave ValueError? (I mean I'm not going to get that from display_name, right?)
[22:00] <Laney> don't think so
[22:01] <tumbleweed> hrm, why are we catching both HTTPError and ValueError
[22:02] <tumbleweed> they both date back to the beginning
[22:04] <Laney> possibly got 403
[22:04] <Laney> from katie?
[22:04] <Laney> cogs... turning...
[22:05] <Laney> whack a debug in there and see
[22:08] <tumbleweed> yup
[22:08] <tumbleweed> katie
[22:08] <tumbleweed> gives a410
[22:09] <tumbleweed> seeing as katie is special-cased in LP, I'm tempted to do that here
[22:10] <Laney> seems needlessly ungeneral
[22:10] <Laney> i'd just log it
[22:13] <Laney> back soon (maybe)
[22:23] <l3on> DktrKranz, ma come si avvia debomatic ?
[22:23] <l3on> mi riferisco al demone...
[22:23] <DktrKranz> l3on: -ECHAN ;)
[22:24] <l3on> :)
[23:30] <broder> hmm...debian bug #633273 would be an NMU candidate because it's a release goal, wouldn't it? :)
[23:31] <broder> oh, also because the maintainer is listed on LowThresholdNMUs :)
[23:34] <tumbleweed> broder: sounds good to me, but I'm off to bed
[23:35] <tumbleweed> release goals aren't release critical
[23:35] <tumbleweed> but this is blocking somebody else, pretty save, and lowthreshold...
[23:35] <tumbleweed> *safe
[23:38] <broder> i thought release goal -> bug was Important; bug was Important -> it's NMU'able
[23:41] <tumbleweed> don' think there's a hard line on what's NMU'able
[23:42] <broder> fair enough
[23:42] <Laney> the severity changes the notice one is supposed to give
[23:42] <Laney> but you can always NMU if you make enough noise before uploading
[23:42] <micahg> for reference: http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu