[00:39] <wgrant> Laney: You do some UDD stuff, right (the Debian definition, not the Ubuntu one)?
[00:46] <ajmitch> he does
[00:46]  * ajmitch doesn't expect to see him online at this hour though
[00:59] <james_w> broder, is there a way to get Debian info from distro-info?
[01:03] <ajmitch> james_w: debian-distro-info
[01:19] <james_w> ajmitch, thanks
[07:02] <dholbach> good morning
[07:43] <Laney> wgrant: only one specific bit, but yes
[07:44] <wgrant> Laney: There's at least one UDD thing using the LP edge API, which has been deprecated for nearly a year now. The consumer name is "merges". Do you know who is responsible for that, so I can convince them to use production instead?
[07:56] <Laney> wgrant: Hmm, I don't see anything in svn, and I am not aware of anything external which uses lplib...
[07:56] <Laney> is it coming from a d.o machine?
[07:58] <wgrant> Laney: I don't know directly which machine it's from, but it's the ultimatedebiandatabase user.
[07:59] <Laney> maybe lucas knows
[08:00] <wgrant> Ahhh, just looked up the IP address. It is indeed one of lucas' scripts, running on ubuntuwire.
[08:00] <wgrant> That explains why you couldn't find it.
[08:01] <Laney> aha
[10:02] <Laney> ajmitch: or someone else ubuntuwire-ish — can we get a mirror of UDD on ubuntuwire? (if so, would I be able to have a public_html?)
[10:02]  * Laney has a fun script idea
[10:03] <nigelb> Laney: does it involve graphing? :)
[10:03] <Laney> no
[10:04] <Laney> I got annoyed by another one of manish's posts on plus
[10:04] <Laney> he seems to want to do away with universe now
[10:04] <Laney> it's to showcase cool stuff in there :-)
[10:04] <ajmitch> Laney: I guess we could, I'll need to read up on how to mirror it though
[10:05] <Laney> well you'll need postgres
[10:05] <Laney> and then there's a dump on udd.d.o generated every two days
[10:05] <ajmitch> yeah that's not a problem
[10:05] <Laney> not sure if it is rsyncable
[10:06] <ajmitch> both postgres 8.3 & 8.4 are installed
[10:07] <Laney> jesus I must be ill
[10:07] <ajmitch> how much diskspace do you need for your idea?
[10:07] <Laney> I can't type "psql" properly
[10:07] <ajmitch> heh
[10:07] <Laney> don't imagine much
[10:08] <Laney> it's just "show me a random cool universe package"
[10:08] <Laney> with cool to be defined
[10:08] <ajmitch> ok, since there's only a few GB free, the udd dump is currently 667MB compressed
[10:08] <Laney> this is the box that hosts revu too?
[10:08] <Laney> laney@samosa> ld -l /usr/bin/pdsq;                                                                                         ~
[10:08] <ajmitch> no
[10:08] <Laney> ld: cannot find -l/usr/bin/pdsq
[10:08] <Laney> there is so much wrong with that
[10:09] <ajmitch> this is qa.ubuntuwire.com
[10:09] <Laney> aha
[10:09] <Laney> dunno, I'm sure I could figure out another way if it's too hard
[10:10] <ajmitch> not hard, I just have to see what I need to shuffle :)
[10:10] <Laney> maybe app-install-data would be better, if cool is limited to .desktoped apps only
[10:10] <Laney> that would probably be a shame
[10:10] <ajmitch> yeah it would, don't limit it
[10:11] <ajmitch> a mere 2.6GB uncompressed
[10:12] <Laney> heh
[10:12] <Laney> you don't have to mirror every table
[10:12] <ajmitch> http://wiki.debian.org/UltimateDebianDatabase/CreateLocalReplica is useful
[10:12] <ajmitch> yeah, but I have to grab the whole dump initially
[10:12] <Laney> unless you generate your own
[10:12] <ajmitch> right
[10:13] <ajmitch> but it might be useful to have the whole thing on qa.uw, right?
[10:13] <Laney> certainly
[10:13] <Laney> tumbleweed could move his scripts there then
[10:14] <Laney> maybe people could chip in for a bigger drive :-)
[10:14] <ajmitch> I'll see what's unallocated on the host first
[10:17] <tumbleweed> yeah, I'd also find a mirror of the Ubuntu UDD stuff on ubuntiwire handy
[10:19] <ajmitch> wgrant would know better than I would about what to sort out for disk space there
[10:19] <Laney> who hosts it / owns the hardware?
[10:20] <ajmitch> iirc it's nafallo that touches the hardware itself
[10:21] <ajmitch> there are a few kvm guests on the server
[10:21] <nigelb> Laney: who's post were you annoyed at?
[10:21] <Laney> manish
[10:22] <nigelb> sinha?
[10:22] <Laney> yes
[10:22] <nigelb> The one about battle for wenoth?
[10:22] <nigelb> *wesnoth?
[10:22] <Laney> no, i got annoyed about that one before
[10:22] <Laney> something about icons
[10:22] <nigelb> Ah, right.
[10:23] <nigelb> I've learned to ignore a few posts
[10:23] <Laney> it was in the comments
[10:23] <ajmitch> Laney: #ubuntuwire if you want
[10:23] <tumbleweed> Laney: btw, before I forget, in early breezy auto-syncs did make it to -changes. This was giving a huge spike in that graph. I ignored them now. Determining components for upload history is also non-trivial. If you could include that in your new importer, that'd be great.
[10:23] <Laney> ack
[10:23] <nigelb> Ah. I see it.
[10:24] <ajmitch> packages can be in universe at the time of upload & then promoted to main a few days later without you seeing it
[10:24] <Laney> hmm?
[10:24] <Laney> oh, yeah
[10:24] <ajmitch> promotions don't require an upload
[10:24] <Laney> but for upload history the component at the time of upload is interesting
[10:25] <ajmitch> and new packages go to universe by default
[10:25] <tumbleweed> ajmitch: yeah, I know, but... what Laney said
[10:25] <ajmitch> yeah it is interesting
[10:25] <ajmitch> it probably won't skew numbers too much
[10:25] <Laney> if you need the current component you can look in another tabe
[10:25] <Laney> table
[10:25] <tumbleweed> it's currently badly skewed towards unknown http://people.ubuntu.com/~stefanor/upload_activity/
[10:25] <tumbleweed> partly because we aren't importing archived releases sources
[10:26] <tumbleweed> partly because not every sourec package uploaded during a release is in the final sources for that releas
[10:26] <ajmitch> large images ahead :)
[10:26] <tumbleweed> naah, it's all js
[10:27] <ajmitch> right but I'm scrolling for miles
[10:27] <tumbleweed> :)
[10:27] <Nafallo> ajmitch: not that I've had to touch it since I installed it, but yeah. I'm the PoC :-P
[10:27] <ajmitch> Nafallo: right :)
[10:28] <wgrant> It has tonnes of space free, since it no longer does archive rebuilds.
[10:29] <ajmitch> almost 120GB unallocated
[10:29] <wgrant> And I suspect a fair bit of the rest is in unused VM images.
[10:30] <ajmitch> yes, though the VMs look to be using images on the filesystems instead of lvm?
[10:31] <wgrant> ajmitch: Right, the VM-specific LVs are from the Xen days.
[10:34] <wgrant> They can probably be deleted without much thought, but there's a bit free in the existing virt volume, and 110GB free in the VG...
[10:34] <ajmitch> yeah, it's mostly syklone that I want more disk space on at the moment
[13:39]  * Laney welcomes tumbleweed!
[13:39] <tumbleweed> heh, thanks
[13:40]  * Laney flashes the secret signal
[13:41] <nigelb> To DMB?
[13:41] <Laney> aye aye cap'n
[13:41] <nigelb> \o/
[13:42]  * tumbleweed whispers something discreetly
[13:42] <tumbleweed> nigelb: I'm a temporary standin for persia
[13:42] <Laney> TO THE DEVELOPER-APPLICATIONMOBILE!
[13:42]  * Laney hits "Add member" and speeds off
[13:43] <tumbleweed> we vaguely talked about a motu session at UDS. Any more thoughts?
[13:45] <nigelb> tumbleweed: Yeah, I hope persia's alright.
[13:45] <nigelb> I actually talked to him at UDS about board members being inactive.
[13:46] <nigelb> I find it ironic now :)
[13:46] <tumbleweed> apparently he is, but yeah I haven't got any responses either
[13:53] <Laney> apparently there are a lot of people getting their first fixes in (so dholbach told me yesterday), we are just failing at converting them into developers
[13:55] <tumbleweed> that sounds about right. the locals who jammed with me got sponsored uploads, but haven't got hooked (they claim not to have the time)
[14:25] <ajmitch> tumbleweed: I don't have time either, but I'm still sort of somewhat in the launchpad team :)
[14:28] <tumbleweed> yeah, if we all just had more time...
[14:32] <AnAnt> Hello, is there a way to control the logo position in unity-greeter ?
[21:11] <tumbleweed> DktrKranz: seeing as you appear to be around and just mentioned syncpackage. I had a question for you: Have you seen bug 878868
[21:12] <tumbleweed> it's a bit of a crazy corner case, but it made me wonder why we were doing what we are in syncpackage
[21:14] <DktrKranz> I've seen something similar in the past too
[21:16]  * tumbleweed just noticed that his patch in that bug would probably break new package syncs, but that's not related to the question :)
[21:18] <DktrKranz> for NEW packages from Debian, it makes sense to have full changelog. It doesn't for packages we already had in Ubuntu.
[21:19] <tumbleweed> the problem here wasn't that we took the full changelog, but that we had version 1.1-0ubuntu1 in ubuntu, so we took changelog enttries >= 1.1-0. Why not >> 1.1-0ubuntu1
[21:21] <DktrKranz> value passed to -v should be current version or 0 in case there isn't one
[21:21] <DktrKranz> then, dpkg will do the right thing
[21:21] <tumbleweed> right, I'll sort that out, my real question here is why are we using get_related_debian_version() at all?
[21:23] <DktrKranz> mmh
[21:25] <DktrKranz> I vaguely remember something
[21:26] <tumbleweed> one possible reason I can think of is packages like configure-debian, which went native to non-native, and we can't sync them properly until they get a new upstream version.
[21:26] <DktrKranz> I think it already checks wheter versions are fine
[21:27] <tumbleweed> yes, but if it did get a new upstream version, we'd want to pick up theintermediate changelog entries too, with get_releated_debian_version() we do
[21:29] <DktrKranz> as long as it takes the current version in the suite, intermediate changelogs should be considered automatically
[21:30] <tumbleweed> in this case. Ubuntu: 1.0.2ubuntu3. Debian: 1.0.2-0.1. If Debian were to go to 1.0.3-1. We'd want to not miss 1.0.2-0.1's changelog entry
[21:33] <DktrKranz> get_related_debian_version() is useful here, perhaps it just needs to be extended to pick common ancestor
[21:33] <tumbleweed> that requires walking both changelogs
[21:34] <tumbleweed> but yes, I also agree that that's probably the right thing to do
[21:34] <DktrKranz> aren't LP APIs able to determine versions?
[21:34] <DktrKranz> I thought LP would know
[21:34] <tumbleweed> ah, yeah ,we could walk the publication histories
[21:35] <DktrKranz> (oh, btw. "debuild", "--no-lintian" => "dpkg-buildpackage" ?)
[21:35] <tumbleweed> sounds about right
[21:37] <tumbleweed> looks like bdrung made that change
[21:37] <tumbleweed> not sure why. For the build log?
[21:37] <tumbleweed> (r 653)
[22:11] <bdrung> DktrKranz: no to "debuild", "--no-lintian" => "dpkg-buildpackage" because it doesn't evaluate debuild options (key signing is a killer feature for me)
[22:12] <bdrung> tumbleweed: re version: we need to find the common anchor for the debian and ubuntu version
[22:15] <tumbleweed> bdrung: agreed. I started looking at it, but doing it probably will require a little refactoring, to save lp roundtrips elsewhere in syncpackage
[22:22] <bdrung> tumbleweed: btw, i commented the bug with one example
[22:22] <bdrung> tumbleweed: we should put that function into a library and write some test cases for it.
[22:24] <tumbleweed> 'fraid it's not that easy. We need to implement it twice. Once for a local changelog (syncing from a dsc), and once for LP records on both distros
[22:25] <tumbleweed> btw, I have some ideas for running tests that require lp. But I doubt I'll have time for that any time soon :/
[22:33] <bdrung> tumbleweed: using stubs for the lp objects?
[22:49] <tumbleweed> bdrung: no, recording api queries and responses, and replaying them
[22:50] <bdrung> nice
[22:50] <bdrung> idea