[00:31] <mvdk> I have a packaging of JBIG-KIT on my PPA.  I wish to submit it for inclusion, solving #594250.  How do I do it?
[00:33] <mvdk> Are there any MOTU in the house?
[00:39] <mvdk> Are there any MOTUs here?
[00:41] <RAOF> Yes.  Some might be a bit busy :)
[00:41] <mvdk> Did any of them see my question, or is it fair to suppose I should ask in an hour's time?
[00:42] <RAOF> The first question they'll likely ask is: can this be submitted to Debian?  That'll get it into Ubuntu, and also be useful for a bunch of other people.
[00:42] <mvdk> Not before precise's feature freeze closes
[00:43] <achiang> can someone explain gpg keys to a dummy? i normally sign packages with @foo.com, but now, i want to make an upload with @bar.com. i have both @foo.com and @bar.com as uids on my private key but... not sure how to actually sign as @bar.com
[00:43] <achiang> i used @bar.com in debian/changelog
[00:43] <RAOF> achiang: Then you're signing as @bar.com
[00:43] <mvdk> Reason being that last patent it's subject to is a US patent that expires on 4/4/2012
[00:44] <RAOF> Hm.  Debian's patent policy is roughly the same as Ubuntu's - has it been rejected from Debian before?
[00:44] <mvdk> About 3 years ago
[00:44] <achiang> RAOF: hm, but... http://pastebin.ubuntu.com/809232/
[00:44] <mvdk> The final patent is rather dubious, but it's US only, anyway
[00:44] <broder> mvdk: if it's still protected by a patent, that seems like it would be a problem for Ubuntu as well
[00:45] <mvdk> So all the patents have expired in the UK, which is where Canonical is
[00:45] <psusi> achiang, debbuild signs with whatever key has the id listed in the changelog
[00:46] <psusi> achiang, so as long as the new address is listed on your key, using that address in the changelog should be all you need to do
[00:46] <achiang> psusi: maybe i don't actually have a key for '@bar.com'... perhaps i only added @bar.com as a uid?
[00:46] <achiang> psusi: there's a pastebin above with my error
[00:47] <psusi> achiang, does gpg -K show that address?
[00:48] <achiang> psusi: ah, i figured out my issue... i used a debian/changelog line of:  -- Alex Chiang <alex@chizang.net>  Thu, 19 Jan 2012 00:33:45 +0000
[00:48] <RAOF> mvdk: Ubuntu is also distributed from US servers
[00:48] <achiang> psusi: but in reality, what is in my key is Alexander Chiang <alex@chizang.net>
[00:48] <achiang> psusi: i didn't realize it was going to match on the entire string, not just the actual email address
[00:48] <psusi> achiang, ahh, yea
[00:48] <RAOF> It matches on full string *and* comment.
[00:49]  * psusi finally started using his @ubuntu.com email recently
[00:49] <RAOF> So if you've got, for example, a comment of RAOF then you need to sign as Christopher James Halse Rogers (RAOF) <raof@ubuntu.com>.
[00:49] <achiang> RAOF: yep, got it now.
[00:49] <achiang> is that a gpg thing or a debuild thing (the matching)
[00:49] <RAOF> Which is why my GPG keys no longer have a comment of RAOF :)
[00:50] <mvdk> RAOF: So what I was hoping for was to include it in the pre-release so it could be included in Precise when it is released
[00:50] <mvdk> RAOF: It's actually a pretty big thing for hylafax - yeah, including patents in things that are actually in common circulation is kind of nasty :(
[00:51] <RAOF> mvdk: We need to care about it from the time it hits the archive - after all, we're distributing it as soon as it hits archive.ubuntu.com.
[00:51] <RAOF> mvdk: To what extent is this patent enforced?  Have you read https://wiki.ubuntu.com/PatentPolicy ?
[00:51] <RAOF> Yes, software patents generally suck.
[00:52] <mvdk> Practically not enforced any more
[00:52] <mvdk> Mitsubishi is the owner of the patent in question
[00:53] <RAOF> And about to expire…
[00:53] <mvdk> Yep
[00:53] <mvdk> And it's the last one of about 25
[00:54] <RAOF> So, I've not been following the recent discussions about new-package-uploads on the MOTU lists; I *think* the current correct procedure is still to upload to REVU.  You might also want to attach your source package to the bug in question, and subscribe (not assign!) ubuntu-sponsors.  That'll get it on the sponsorship queue.
[00:55] <mvdk> See http://www.cl.cam.ac.uk/~mgk25/jbigkit/patents/
[00:55] <mvdk> OK, I'll google for REVU
[00:55] <mvdk> Thanks
[00:58] <broder> i still don't understand why uploading to debian isn't an option. it's possible to get exceptions to feature freeze, and for universe they tend to be handed out pretty liberally
[00:58] <RAOF> Aha! http://revu.ubuntuwire.com/ says that it's deprecated, and contains a link to the current process https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[00:59] <mvdk> Ah, so I need to speak to "the" MOTU
[00:59] <mvdk> I'm guessing there is in fact more than one...
[01:01] <mvdk> broder: libtiff isn't universe, and I would submit a one-liner in the control for it
[01:01] <mvdk> Add a depends for libjbig-dev
[01:02] <mvdk> Build-depends, rather
[01:02] <mvdk> OK, so I should attempt debian first, no probs
[01:04] <RAOF> Yeah.  There are more people who can upload to Debian than who can upload to Ubuntu (as a goodly number of Ubuntu developers are also Debian developers, but not visa-versa).
[01:07] <mvdk> RAOF: broder states that exceptions are sometimes given.  Is it likely that an exception would be given for a Build-Depends on libtiff?
[01:08] <broder> mvdk: are you saying that your thing needs to build-dep on libtiff?
[01:08] <RAOF> broder was talking about feature-freeze exceptions; it's reasonably easy to get a new package into Universe after feature-freeze, because that's quite safe.
[01:08] <mvdk> In order for libtiff to use libjbig, there needs to be a build-dep on libtiff, yes
[01:09] <RAOF> But if you need to add a build-depends on this new package to libtiff, that's different.  It needs libjbig to be in the archive and have a main-inclusion-report done for it (because libtiff is in main it can only build-depend on things in main).
[01:09] <mvdk> Ah
[01:09] <mvdk> Ouch
[01:10] <mvdk> So I should make a tiff-jbig source package that has that one-liner, that is a virtual for all the main package parts?
[01:10] <mvdk> Sorry, is a provides for all the main package parts
[01:11] <RAOF> That would potentially be one way to have jbig support in libtiff without getting jbig in main, yes.
[01:11] <RAOF> Unfortunately, due to limitations of dpkg, that'll only work if nothing has a versioned dependency relationship on libtiff. [Ie: declares Depends: libtiff (>= someversion)]
[01:12] <mvdk> Yuck
[01:12] <psusi> RAOF, glib timeouts are called without gdk lock, so you need to call gdk_threads_enter() before doing any gtk stuff right?
[01:12] <mvdk> So it's more like "Sit in the corner and cry" :(
[01:13] <RAOF> psusi: That sounds right.
[01:13] <psusi> damn...
[01:13] <RAOF> mvdk: It'd still be possible to get that happening, but it's tight.  What is jbig support, and how much do we need it?
[01:14] <mvdk> Several printers are useless without it
[01:14] <mvdk> In particular, a heap of Samsung & Lexmark printers are useless - all the ones with splix support
[01:14] <RAOF> That sounds like something we want to have, then.
[01:15] <mvdk> They don't depend on libtiff support, though
[01:15] <mvdk> hylafax depends on libtiff support
[01:15] <psusi> RAOF, is there a sigc or gtkmm template somewhere you can use to wrap a sigc::mem_fun in a gdk_enter_threads so you can pass it to Glib::SignalTimeout::connect without writing your own function to do so? ;)
[01:16] <RAOF> Is there a bug for the fact that we lack support for those printers?
[01:16] <RAOF> psusi: Dunno; I'm not familiar with gtkmm.  If I want to write something in a high-level language I'll use a high-level language :P
[01:16] <psusi> hehe...
[01:16] <mvdk> Yeah, with wontfix, I think
[01:17] <RAOF> Is it only the fax functionality that's broken?
[01:17] <psusi> you would think that gtk would have its own timeout wrapper that made sure to grab the lock
[01:18] <mvdk> hylafax won't be able to use JBIG if libtiff doesn't get built without libjbig
[01:18] <mvdk> splix (the printers) won't work if libjbig doesn't get built
[01:18] <mvdk> splix is a universe package, though
[01:19] <mvdk> splix is not a universe package, I didn't realise, sorry
[01:20] <RAOF> mvdk: If you can hunt down that bug, this sounds like something that should be fixable now.  Hardware support is generally a good reason for a MIR :)
[01:20] <mvdk> But the ubuntu maintainer has decided to add the libjbig as a statically linked bit of source in his own package :P
[01:20] <mvdk> As of about 2 weeks ago
[01:21] <RAOF> Urgh, really?
[01:21] <mvdk> Yep, nasty hey?
[01:21] <RAOF> Hm, so he has.
[01:22] <micahg> RAOF: mvdk: policy around REVU is if you have someone to REVU it and it's going straight into Ubuntu, that's the place, otherwise, try to get into Debian through debexpo
[01:23] <RAOF> mvdk: So, I think that's actually a mistake on his part, and we should do the work to get your proper libjbig package into main.
[01:23] <mvdk> OK, no probs.  Do you have the PPA I set up?
[01:24] <mvdk> That's the package I actually intend to attempt to submit
[01:24] <RAOF> I don't, no.  Is the package lintian-clean?
[01:25] <mvdk> Yes, but the symlinks aren't properly set up.  I haven't quite figured out libtool. (That is, lintian doesn't actually check that the build scripts do sensible things)
[01:26] <mvdk> Only the libjbig-dev does symlinks (That is, libjbig-dev has libjbig.so -> libjbig.so.0, but both libjbig.so.0 and libjbig.so.0.0 are real files)
[01:26] <RAOF> Huh.
[01:27] <mvdk> I think libjbig.so.0 ought to be a symlink to libjbig.so.0.0
[01:27] <mvdk> It doesn't actually cause it to fail, but it seems silly
[01:28] <RAOF> That's the way it generally should be.
[01:28] <RAOF> Does libjbig do ABI stability?  An SONAME of .0 is sometimes suspicious. :)
[01:29] <mvdk> libjbig has been stable for the last 4 years
[01:29] <mvdk> That is to say, the author hasn't made any releases - and why would he, the library is only 3 files containing about 2K lines...
[01:30] <mvdk> +3 headers
[01:31] <mvdk> And the author has never released them as so's
[01:31] <mvdk> His build script made .a's...
[01:31] <mvdk> So the part about making it into a .so was my part
[01:32] <RAOF> Ah.  Joy!
[01:33] <mvdk> Yeah, hence my looking into what I need to do to make libtool work...
[01:34] <RAOF> I found http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id292165 an excellent reference for general library packaging things.
[01:36] <mvdk> I think I found what my issue is
[01:36] <mvdk> I said install -s -m ...
[01:36] <mvdk> But I should only have said that for the main file
[01:37] <mvdk> So I need install -s -m ... *.*.* but just install -m ... .so .so.[^.]*
[01:40] <RAOF> I generally use the magic of autofoo, which tends to get it right.
[02:17] <mvdk> RAOF: I got that working.  Lintian has some more output: It doesn't like some binaries not having man pages.  I guess I ought to write them, right?
[02:17] <RAOF> Hm.  Why does the package have binaries at all?  Are they demos or something?
[02:19] <mvdk> It seems the author had some other file formats that were supported.  The demo directories seem to have some weird stuff.  In any case, they allow conversion from pbm to a raw jbig stream (if you can think of a reason to want to do that)
[02:19] <mvdk> And vice-versa
[02:20] <RAOF> That doesn't sound awesomely useful.  Feel free to simply not ship those.
[02:21] <mvdk> I put them in jbigkit-bin, which wouldn't need to be a main package
[02:21] <mvdk> So I have 3 packages from the source at the moment: libjbig, libjbig-dev & jbigkit-bin
[02:22] <mvdk> The libjbig & libjbig-dev would need to be in main
[02:22] <RAOF> That sounds roughly right (I presume it's actually libjbig0)
[02:22] <mvdk> Yes, it is, sorry
[02:24] <mvdk> It wants me to fill in minimum versions for libc-dev & gcc.  Is there a good minimum to use?
[02:24] <mvdk> The build worked on lucid, I'm thinking I should use its version numbers
[02:30] <mvdk> Any idea what a reasonable minimum for libc-dev is? I put >= 4.4 for gcc...
[02:33] <RAOF> I think the actual problem is that you don't actually _need_ a Depends on libc-dev and gcc.
[02:34] <RAOF> They're assumed to be provided by the build environment, so you only need to specify an explicit dependency if you need a specific version - hence the warning.
[02:34] <mvdk> Oh, very classy.  I wonder why the new-package scripts gave me it for free?
[02:35] <RAOF> Dunno.
[02:46] <mvdk> RAOF: I just packaged a jbigkit-2.0-6 for precise that has everything but the manpages fixed
[06:45] <mvdk> RAOF: Thanks for all your help.  I've posted the package on mentors.debian.net.  Hopefully I can find someone to sponsor it...
[07:18] <ricotz> siretart, hello, could you get libaacs 0.3.0-3 synced?
[07:50] <dholbach> good morning
[07:58] <siretart> hi dholbach, morning ricotz
[07:58] <siretart> ricotz: yes, let me testbuild it
[07:59] <ricotz> siretart, hi, thanks
[08:02] <dholbach> hey siretart
[08:04] <siretart> ricotz: that the first time I'm using this newfangled syncpackage script. let's see if the sync really gets attributed to you :-)
[08:06] <ricotz> siretart, hoping the best ;P
[08:14] <siretart> Changed-By: Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>
[08:14] <siretart> doesn't look like it, but it got accepted :-)
[08:23] <ricotz> siretart, i see, dont worry
[09:17] <Laney> sure it did https://launchpad.net/~ricotz/+synchronised-packages
[09:25] <ricotz> Laney, oh nice, havent seen this new categories there yet
[09:25] <Laney> https://lists.ubuntu.com/archives/precise-changes/2012-January/007584.html even says your name :-)
[09:27] <ricotz> i see :), formerly the name would have appeared here too https://launchpad.net/ubuntu/+source/libaacs/0.3.0-3
[09:27] <Laney> ye that bit is missing
[09:27] <Laney> hopefully be back soon
[09:27] <ricotz> ok, it isnt important
[11:36] <dholbach> hey, so I mailed a few folks about this already, but it might be worth bringing it up here as well - I need some help filling the schedule for Ubuntu Developer Week, so I can go and announce it and try to get some press attention, so we can get many new contributors :)
[11:36] <dholbach> looking at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable what I feel we still need is a few hands-on sessions, maybe even just 30 minute ones which most of you could probably just off-the-cuff :)
[11:37] <dholbach> in a dog-walking break I came up with these ideas already http://paste.ubuntu.com/809547/
[11:38] <dholbach> having reached out to new contributors in the last months, I found that demo'ing how things are done with an example generally had a huge impact on their views of how easy it is to get involved
[11:45] <micahg> dholbach: a security session would be good  Ithink
[11:46] <dholbach> ah yes
[11:46] <micahg> I'll see if I can find someone to do it :)
[11:46]  * dholbach hugs micahg
[11:47] <tumbleweed> Laney: looks like nobody has volunteered for the second debian slot yet
[11:48] <dholbach> it's hard work getting the schedule filled this time
[11:48] <Laney> those slackers
[11:48] <dholbach> which is why I suggested more hands-on sessions, where you just talk about a few examples you picked earlier - which I I supposed would come naturally to most of the ubuntu developers and contributors :)
[11:49] <tumbleweed> people often come aind and ask what they can do to help, does a short slot on the kind of things MOTU does sound interesting? It wouldn't be particularly hands-on
[11:50] <dholbach> sure - explaining where we list our task lists and what they all mean would be super helpful
[11:53] <dholbach> or maybe a "here's how reviews are done, let's pick 5 items from the queue" session
[11:53] <dholbach> would have the nice side-benefit of getting the queue shorter ;-)
[11:58] <ajmitch> not really the best time of day for me to help out with that
[12:00] <dholbach> ajmitch, I know :-/
[12:00]  * dholbach hugs ajmitch
[13:33] <dholbach> maybe we can groups of 2 or more to copresent sessions, like Laney and tumbleweed do?
[13:35] <Laney> well actually we might split that up
[13:35] <Laney> give one half of the debian stuff each
[13:36] <dholbach> ah, so that'd be "working with debian" and "working in debian" like you mentioned some days ago?
[13:36] <Laney> yeah
[13:36] <Laney> but I'll re-ping
[13:36] <dholbach> sweet
[13:36] <dholbach> great
[13:36]  * dholbach hugs Laney and tumbleweed
[13:36] <dholbach> rock stars :)
[14:40] <scott-work> i uploaded a lowlatency kernel package to REVU last night i have yet to get a confirmation email or see it on the website, is this unusal and do i need to worry about it yet?
[15:30] <psusi> scott-work: revue is for brand new packages that want to get into universe, and is obsolete
[15:43] <siretart> scott-work: did you upload a _source.changes or a _i386.changes file?
[16:02] <ScottK> psusi: It's not obsolete.
[16:03] <ScottK> Little used, I would agree with, but not obsolete.
[16:05] <scott-work> psusi: the lowlatency kernel is a new package that needs to be into universe
[16:05] <scott-work> siretart: i believe i uploaded a _source.changes, but i can check when i get home tonight
[16:05] <scott-work> siretart: i used 'debuild -S -sa' to generate the .changes files if that helps any
[16:06] <psusi> scott-work: linux is already packaged... if you want to add a low latency flavor, it is just another binary package that should be added to the existing suorce package.. but there used to be one and the kernel removed it a few releases ago
[16:07] <psusi> ScottK: there was some discussion yesterday about it and there was a new proceedure that didn't involve revu iirc
[16:07] <psusi> kernel-team removed it that is
[16:07] <psusi> iirc, because the generic one is pretty much just as good now
[16:09] <ScottK> The kernel team is not everybody.
[16:09] <ScottK> there is an intent to replace it with mentors.debian.net, but it's not there yet.
[16:41] <scott-work> psusi: there has been discussion with the kernel team and they do not want to maintain this kernel and therefore will need to be community maintained kernel
[16:41] <scott-work> psusi: the kernel team is very accepting of a community maintained kernel based on the ubuntu kernel
[16:42] <scott-work> psusi: but it would need to be in universe therefore and a separate package
[16:42] <psusi> scott-work: you can't have a main source build a universe binary?
[16:42] <scott-work> psusi: per a uds-p blueprint i we are to build, package the lowlatency kernel and then submit to REVU
[16:43] <scott-work> psusi: it would suggest it's not a matter of ability but that the kernel team does not want to be directly involved with this kernel, including having it in their code
[16:43] <scott-work> no disrepect to UKT intended as i completely understand and agree with their motivations and concerns
[16:43] <psusi> by low latency, do you just mean switching the config option from desktop to preempt?  or are there actual source changes?
[16:44] <scott-work> psusi:  i am not a kernel expert, but my understanding is that the only changes are flags during build
[16:45] <scott-work> psusi: this is the blueprint if you are interested:  https://blueprints.launchpad.net/ubuntu/+spec/other-p-lowlatency
[16:46] <psusi> seems silly to upload a near duplicate source package just for a config change... how much difference does it actually make anyhow?
[16:48] <scott-work> psusi: performance wise for recording audio it can lower the latency by at least a factor of 2, in some cases it has lowered performance by a factor of almost 8
[16:48] <scott-work> psusi: and it also practically eliminated _all_ xruns at most of those latencies
[16:49] <psusi> I found the other day that glib's timer implementation is horribly incaccurate and submitted a patch for it... in my testing it got 20% off when run niced with stress -c in the background running a 50 Hz timer... simple patch to glib and that went down to like 0.0001% error
[16:49] <psusi> how much latency are we talking about here?  microseconds?
[16:51] <scott-work> psusi: yes, microseconds
[16:52] <psusi> wow... so you want to work with only a few microseconds of audio buffer?  damn...
[17:04] <astraljava> Ehh... that can't be right. Gotta be milliseconds.
[17:13] <scott-work> psusi: sorry, astraljava is correct, it's milliseconds....i mispoke preparing to go to a meeting
[17:14] <scott-work> but the point is per an approved bluepring from uds-p i was to submit to the lowlatency kernel to REVU
[17:14] <scott-work> if i can being told that i cannot use REVU in this capacity i need to find another vector to get this package into the universe archive
[17:17] <scott-work> also, i uploaded last night (approximately 16 hours) but have not yet received an email or can see it on the website, is there perhaps a problem with the dput although it said it uploaded properly?
[17:22] <micahg> scott-work: what's wrong with REVU now?
[17:22] <scott-work> micahg: hi, it started like this....
[17:22] <scott-work> [08:40] <scott-work> i uploaded a lowlatency kernel package to REVU last night i have yet to get a confirmation email or see it on the website, is this unusal and do i need to worry about it yet?
[17:24] <astraljava> psusi: Even though we're not actually talking microseconds, the difference is drastic on some heavy audio-related tasks. People interested in such have provided test results regarding such sessions, and in several cases the latency was dropped to even smaller than one third.
[17:24] <micahg> scott-work: it should show up fairly quickly, I assume you did dput revu foo_source.changes?
[17:24] <scott-work> micahg: i think siretart had a good suggestion on checking which *.changes file was uploaded, which i will check in approximately 6 hours hence, but generally i was just trying to get a feel for if this is normal and i dont' need to worry
[17:25] <astraljava> psusi: So even when we're only talking miniscule amounts of diffs codeline-wise, there are other differences.
[17:25] <scott-work> micahg: aye
[17:33] <jbicha> gcompris fails to build with the latest librsvg "error: 'RsvgSizeFunc' is deprecated [-Werror=deprecated-declarations]"
[17:33] <jbicha> is there an easy fix for that?
[17:34] <micahg> why wasn't this caught before the upload?
[17:34]  * micahg would have assumed 2 devs test built this in this case
[17:35] <jbicha> because new librsvg was just uploaded a few hours ago, it didn't fail earlier
[17:35] <micahg> ah, ok :()
[17:35] <micahg> :)
[17:36] <micahg> the big hammer would be to use the no-error equivalent when building, ideally, patch it to use whatever replaced it
[17:39] <scott-work> interestingly nothing since 02 jan 2012 is showing up on the revu website :/
[17:45] <ScottK> It was down for awhile before it got rebooted yesterday
[18:37] <l3on> do you think it normal that a package in universe depends on a non-free package ?
[18:37] <psusi> so why is using pkexec better than gksu?
[18:38] <ScottK> l3on: No.  It's a bug.  What package?
[18:38] <l3on> boinc-amd-opencl
[18:39] <scott-work> siretart:  i called my wife and asked her to read me the filename for the .changes file, it was a _source.changes file
[18:39] <l3on> in precise
[18:39] <ScottK> l3on: It's in multiverse: boinc-amd-opencl | 7.0.7+dfsg-1 | precise/multiverse | amd64, i386
[18:39] <l3on> right right... well, in this case ?
[18:39] <l3on> is still a bug ?
[18:40] <ScottK> No, that's where non-free stuff goes.
[18:40] <l3on> ah ok, thanks :)
[18:40] <l3on> in anycase, it has a bronken dep on amd-libopencl1
[18:42] <ScottK> Different sort of bug.
[18:42] <ScottK> It's not strictly required that multiverse packages be installable just from packages in the archive.
[18:47] <l3on> thanks for the info :)
[18:59] <siretart> scott-work: gpg: Can't check signature: public key not found
[18:59] <siretart> scott-work: seems you're not added to the keyring yet
[19:00] <scott-work> hmmm, i did this for the zynjacku, strange
[19:01] <l3on> do you know where can I find information about what happened to package libcassad1 ?
[19:01] <scott-work> maybe i'm using a different key than i did back then
[19:01] <siretart> but 9E2AC7F4 is your key, which is registered in launchpad, right?
[19:01] <scott-work> siretart: i'm guessing then i need to verify my key is in the ubuntu keyring?
[19:02] <scott-work> siretart: "9E2AC7F4", i'll check, but it shoudl be
[19:02] <siretart> you need to join the revu-uploaders team
[19:02] <siretart> revu has a cronjob that collects keys from launchpad
[19:02] <scott-work> siretart: aye, that is my key
[19:02] <scott-work> siretart: okay, i'll join now then
[19:03] <scott-work> and then dput again?  or will i need to dput -f this time?
[19:04] <siretart> scott-work: dputting again should work, or some revu admin can move back the .changes file
[19:09] <scott-work> siretart: okay, maybe i'm flusttered, but i simply can't find 'revu-uploaders' in launchpad
[19:09] <siretart> oh
[19:09] <siretart> right, that was removed at some point..
[19:10] <siretart> RainCT: around? see above
[19:16] <siretart> scott-work: sorry, I was wrong
[19:16] <siretart> scott-work: 2012-01-19 20:16:43 - linux-lowlatency_3.2.0-9.16_source.changes: Incorrect signature, moving to rejected.
[19:17] <siretart> or wait. no
[19:19] <RainCT> Hey
[19:19] <scott-work> siretart: i would like to point out that no matter the outcome, i really do appreciate your efforts to help me :)
[19:19] <RainCT> siretart: the cronjob is long gone
[19:20] <RainCT> keys are pulled individually from Launchpad every time you log in on the REVU website
[19:20] <RainCT> scott-work: ^
[19:20] <scott-work> RainCT:  i _think_ i might have dput'ed before logging in (at least in a year)
[19:20] <siretart> RainCT: aah, that explains
[19:20] <scott-work> RainCT: now that i have logged into the website do you think dput will work
[19:20] <scott-work> ?
[19:20] <siretart> scott-work: http://revu.ubuntuwire.com/p/linux-lowlatency
[19:21] <siretart> scott-work: I've reprocessed your upload manually.
[19:21] <scott-work> siretart: i simply cannot thank you enough!  if i see you at a uds i will buy you several of your favourite beverages :)
[19:21] <siretart> :-)
[19:39] <l3on> hi guys, how a package can be updated with bzr ?
[19:39] <l3on> I looking at "condor"
[19:40] <l3on> well, maybe it's too much complex for me :/
[19:44] <scott-work> l3on: my experience is to download the bzr branch, make the changes, upload back to the branch, and then ask for a sponsor to upload the changes to the archives
[19:45] <l3on> scott-work, well but I'm going to "upgrade" package, in meaning of new upstream release.. is there something like --pristine ?
[19:45] <jtaylor> there should be an merge-upstream command
[19:46] <l3on> found, thanks jtaylor
[19:47] <micahg> l3on: http://developer.ubuntu.com/packaging/html/udd-merging.html#merging-a-new-upstream-version
[19:52] <l3on> well, seems to not work...
[19:52] <l3on> bzr merge-upsream $HOME/condor-7.6.6.tar.gz
[19:52] <l3on> returns an exception...
[20:17] <broder> l3on: you need to specify the version number as well. don't remember exactly how - might be --version or -v or something
[20:54] <koolhead17> slangasek: hi there