[03:41] <Some_Person> How much space does a pbuilder thingy take?
[03:47] <nigelb> Some_Person: depends on what you do with it
[03:47] <Some_Person> the base image, i mean
[03:48] <Some_Person> This machine has limited HD space, so I need to knwo
[03:48] <Some_Person> s/knwo/know
[03:49] <nigelb> hold on, lemme check mine
[03:49] <keithy> hi, anyone here can talk about licencing of a project (again)
[03:49] <nigelb> Some_Person: mine seems to take around 100 MB
[03:49] <keithy> my emails to support have been ignored it seems
[03:49] <nigelb> keithy: want to talk to an LP admin?
[03:49] <keithy> that'll do
[03:50] <Some_Person> nigelb: It'll be a tight squeeze, but I think it'll fit
[03:50] <wgrant> keithy: The European or American working week is a much much better time.
[03:50] <nigelb> keithy: yeah, monday to friday EU time will have better luck
[03:50] <Some_Person> How can I screw the pbuilder stuff from my system when I'm done?
[03:51] <nigelb> Some_Person: donno what you mean + this is the wrong place for this discussion I think
[03:51] <Some_Person> nigelb: What is the right place?
[03:51] <nigelb> wgrant: #ubuntu-motu would be beter?
[03:51] <Some_Person> And what I mean is, how can I get rid of this 100MB image when I'm done?
[03:52] <Some_Person> What's #ubuntu-motu?
[03:52] <nigelb> Some_Person: I'm not sure how to remove the basefile other than to remove pbuilder.  we generally dont need that feature
[03:52] <wgrant> #ubuntu-motu is probably better, yes.
[03:53] <nigelb> Some_Person: join #ubuntu-motu channel and ask there, a lot more experts will be around
[03:53] <Some_Person> What is "motu"?
[03:53] <nigelb> !motu
[06:33] <Some_Person> It said my package was building now, but a minute later it says it'll start building in an hour
[06:34] <wgrant> Some_Person: Are you sure you weren't looking at different architectures?
[06:34] <Some_Person> No, I just refreshed the page
[06:35] <Some_Person> Now it says it's building again, though on a different builder
[06:35] <Some_Person> It's a really fishy package, so I want to make sure it builds and works properly
[06:39] <wgrant> Some_Person: Link to the build?
[06:40] <Some_Person> it's finished building now
[07:11] <micahg> are we allowed to make our ubuntu.com addresses default on LP yet?
[07:12] <rww> micahg: https://bugs.launchpad.net/launchpad-foundations/+bug/5292 is still open, so I'd guess not
[07:12] <micahg> rww: so, is that the same as having bugmail coming from the ubuntu.com address?
[07:12]  * micahg subscribes to that bug
[07:14] <rww> micahg: i think so
[07:14] <micahg> rww: so I'm wondering how people do it now
[07:14] <rww> micahg: example?
[07:15] <micahg> rww: PM?
[07:15] <persia> micahg: The reason it works for me is very old and historical, and predates that bug by a long time.
[07:15] <micahg> persia: you were going to be one of my examples :)
[07:15] <persia> (and happens to be different than the other reason it works for certain people)
[07:16] <micahg> k
[07:17] <persia> Basically, there are some folk who have @ubuntu.com not related to launchpad (for historical reasons), and there are some folk who have @ubuntu.com cowboyed in during early days of integration with launchpad, and it works for them, but it doesn't work for new folk since the improved launchpad integration.
[07:17] <persia> That's theoretically fixable, but hard, and making it work the way it works for either of the first two classes of people is just broken.
[07:18] <persia> (hence the bug)
[07:19] <micahg> rww: nm
[07:24] <persia> micahg: Sorry to disrupt your PM: I just don't think there's anything there which isn't public (the former case can be understood by reviewing MX records, and the latter case (mine) are a set of known exceptions and workarounds).
[07:34] <micahg> persia: I cancelled the PM request
[07:35] <persia> hence my apology :)
[07:39] <micahg> persia: I asked for a PM because I wasn't sure if people were doing stuff wrong and didn't want to "out" them in public :)
[07:39] <persia> I don't think any of the individuals did anything wrong.
[07:40] <micahg> persia: right, but I didn't know that when I started asking...
[07:40] <persia> The issue with namespace collision on the mailserver is long-standing, and awkward to address.
[07:40] <persia> The few of us who have hand-entered aliases from the beginning of the LP integration stuff are just acceidents of timing.
[07:41] <persia> A real fix to the bug is to be able to separate target address from preferred address in LP.
[07:42] <persia> And then to notify all the special cases that they need to set things properly.
[07:42] <persia> And then set up a new mailserver, have it pull from the new LP stuff, and then change MX records.
[07:42] <persia> That's hard, and it's questionable whether it's worth it.
[07:43] <persia> (especially because there are a few hundred special cases)
[07:44] <wgrant> persia: Are the special cases those Canonical employees with canonical.com aliases that happen to work on ubuntu.com too?
[07:45] <persia> wgrant: Not all of them.  There are two classes of special case.
[07:45] <wgrant> Well, yes, I meant the big one.
[07:45] <persia> wgrant: So, there's the @canonical.com @ubuntu.com thing (some of which I believe was addressed about 18 months ago, but I'm not sure).
[07:46] <persia> Yeah, the majority are probably those.
[07:46] <persia> But also there are folk (like me) that ended up with hardcoded aliases to work around bugs with the LP integration back in the early days.
[07:46] <wgrant> Ah.
[07:47] <persia> So in the beginning there was a big aliases table, and new members got added there.
[07:47] <persia> Then we wanted to use LP more, and sometimes that worked, and sometimes it didn't.
[07:47] <wgrant> Anyway, it's not actually much to do with LP -- IS handles it.
[07:47] <persia> And now LP mostly just works, so nobody gets added to the aliases table anymore.
[07:48] <persia> Well, there's a few bugs in IS, but the bug in LP is that it doesn't differentiate "preferred address" from "alias target address", making the bugs in IS hard to fix.
[07:48] <wgrant> LP doesn't know about aliases.
[07:49] <persia> Right.
[07:49] <persia> It would have to grow that as an attribute to fix the IS stuff.
[07:49] <persia> Without that attribute, it requires additions to the aliases table, which are currently (partially) automated based on LP preferred address (as I understand it: I'm not privy to the code)
[07:50] <wgrant> Alternatively the IS thing could be replaced with a simple webapp authenticating against LP and checking ~ubuntumembers membership.
[07:50] <persia> Indeed.  That's probably better than trying to force LP to do it.
[07:51] <wgrant> Now that authentication and membership verification against LP is easy, that is probably the way to do it. Plus it could be decoupled from the LP username, which is probably a good thing.
[07:51] <persia> So user@ubuntu.com wouldn't necessarily be lpnet/people/user ?
[07:52] <persia> I suppose it isn't always now do to how the mailserver works anyway.
[07:52] <wgrant> It could be implementable like that if so desired.
[07:52] <persia> s/do/due/
[07:52] <persia> That sounds like an excellent suggestion, except that I'm unsure IS is likely to develop such a webapp.
[07:53] <persia> But I'm now convinced this isn't an LP bug.
[07:57]  * persia updates the bug based on this discussion
[08:09] <persia> I've bumped into a bug: if a bug (e.g. bug #410028) has nominations for releases against multiple tasks, I don't seem to be able to approve one without leaving the other unapproved.  Does anyone happen to know if this is already filed?
[08:15] <persia> Err, that was supposed to be 401028, but I'm guessing nobody heard of this before anyway.
[08:15] <persia> Filing now.
[08:22]  * persia should trust the find-similar-bug algorithm more: it's bug #271697
[08:29] <wgrant> persia: You mean that you can't accept nominations for different source packages separately?
[08:30] <persia> Yeah.
[08:30] <wgrant> Bug #11195
[08:30] <wgrant> Er.
[08:30] <wgrant> Bug #110195
[08:30] <wgrant> I filed it about 3 years ago.
[08:31] <persia> Is 271697 a dup, or just an expression of 110195 also in javascript?
[08:31] <wgrant> They are separate.
[08:31] <wgrant> Although fixing 110195 will probably fix 271697, since the nomination objects will be distinct.
[08:32] <wgrant> But 271697 could be fixed independently.
[11:49] <p_masho> anyone here who can help a newbie. I want to "upload" around 300+ debs.
[11:50] <p_masho> Its for the flightgear project. There are over 300+ aircraft, which are just a bunch of files (images/xml) in a directory.
[12:10] <persia> p_masho: Why do you need that in 300 different packages?
[12:11] <p_masho> each aircradt needs to have its own ppa, they average around 10meg each..
[12:12] <p_masho> just realised I cant do this anyway.. after rtfm ing ;-(
[12:12] <persia> heh.
[12:12] <wgrant> Why can't you?
[12:12] <persia> Packages like that are trivial to do, but often need a lot of consideration.
[12:14] <p_masho> wats a pain in the ass is the updates
[12:15] <p_masho> ats them moment its (once in a blue moon ) >> "cvs co " (yes cvs).. >> scan dir for updates >>  make tarball >> upload tarball.. to ftp site >> mirrored
[15:08] <askhl> Hi.  I have a couple of different PPA packages which I would like to make available for different Ubuntu series.  One package contains only data and is quite universal, but depends on less universal packages.  Do I really have to make copies of this package for each series?
[15:13] <geser> askhl: is the data package build from its own source package?
[15:14] <askhl> geser: yes it is.  Also I wrote something wrong: it doesn't depend on anything - other packages depend on *it*.  Sorry
[15:14] <geser> depending on the packages you have (if they need a rebuild or not) it might be enough to copy them (through the web UI) to the other release
[15:15] <geser> for a data package copying should be enough
[15:15] <askhl> The data package is 20MB, so I would rather avoid that
[15:17] <geser> avoid the copying?
[15:18] <geser> without a copy it won't get published for the other release, I assume that this won't use any additional space in your PPA
[15:18] <askhl> So copying for different releases doesn't count against the PPA size limit?
[15:19] <askhl> Anyway, I'll just create copies if that's what it takes, whether or not it takes some space.
[15:20] <geser> I'm not sure, but as you re-use the same files and as they even stay in the same location I doubt it
[15:22] <askhl> Okay, that makes sense.  If I need to update the data package, though, what is the procedure?  Update the newest and then copy to other releases, or update each one individually?
[15:22] <askhl> I guess I should try to find these things in the Ubuntu or Debian packaging guides
[15:28] <askhl> I'll browse the documentation for further information.  But I'll make copies to support different series in any case.  Thanks a lot for the help, geser.
[15:37] <d34df00d> Hi!
[15:38] <d34df00d> Are there any plans for supporting TS (Qt Linguist) translation files in Launchpad?
[15:38] <d34df00d> I've googled a bit and only found recommendations to use translation-toolkit.
[15:39] <d34df00d> Also, there is an open wishlist bug on the tracker starting back from 2006, but it is quite inactive, and it is neither accepted nor rejected.
[15:41] <d34df00d> Converting to and from PO is a solution, but it is seems more like a workaround, and this way one would need to upload files manually.
[15:41] <d34df00d> Or keep the POs (which are, in fact, duplicates) in Bazaar repo.
[17:23] <rdz> hi all. i have a question regarding deb packaging for my PPA. is this the right channel to ask?
[17:34] <geser> yes
[17:36] <rdz> i try to build a binary package from the sources by doing: 'sudo pbuilder build ../gavl_1.2.0pre1-1.dsc'. it stops with this error: "make: dh_testdir: Command not found" . however, 'dh_testdir' exists (debhelper is installed). how comes that fakeroot does not seem to find the dh_testdir command?
[17:37] <geser> pbuilder uses a clean and bare chroot for building. if you need any special package during build (like debhelper) you need to specify it in Build-Depends
[17:38] <geser> in debian/control
[17:38] <rdz> geser, thanks
[17:50] <rdz> geser, am i right in thinking, that i should adapt <source-directory>/debian/control ? i added 'debhelper' there ('doxygen' was alreaday there), but when executing the 'pbuilder build' command, i see that it is still only installing 'doxygen', but not 'debhelper'. sorry for the noobish questions
[17:56] <rdz> that is the complete output:  http://pastebin.ca/1827292
[18:29] <geser> rdz: did you recreate the source package (debuild -S) after you changed debian/control?
[18:30] <rdz> geser, thanks.. yeah, i got it in the meantime
[18:31] <rdz> geser, now i am stuck at another issue:  http://pastebin.ca/1827344. there seems some problem with the debian/rules file
[18:33] <rdz> this is the 'clean' section of debian/rules: http://pastebin.ca/1827345
[18:45] <rdz> now, after i performed './autogen.sh' before doing 'debuild -S', it seems to work. does this mean i should add the './autogen.sh' command add to debian/rules?
[18:46] <rdz> or is the usual way to prepare a package to bring it into a state ready for doing ./configure ?
[19:38] <rdz> I just uploaded my first source package to my PPA. Will I just have to wait until I see it appear?
[19:42] <mwhudson> rdz: you should get an accepted mail within 5 minutes
[19:44] <askhl> Say, if you 'import' a translation in Launchpad, what happens if the msgids are not the same?
[19:45] <askhl> Presumably it is strictly required when 'importing' as well as when 'uploading' that the po-file in question actually contains exactly the same msgids.
[19:45] <rdz> mwhuds ah.. i see.. it was not accepted .. thanks
[20:43] <rdz>  "i386   - Pending publication": Am I required to publish this package? or do I simply need to wait?
[20:43] <rdz> If it requires me doing something, what shall i do?
[20:46] <rdz> ah.. i had simply to wait
[20:46] <rdz> :-)
[21:01] <blueyed> Is OOPS-1527L2262 because somebody changed the package while I was typing for minutes on a comment which appears to be lost now?
[21:06] <lifeless> blueyed: huh, that oops itself oopses
[21:06] <blueyed> OOPS-1527L2276 also?
[21:07] <thumper> morning
[21:07] <lifeless> blueyed: that one isn't replicated yet
[21:12] <blueyed> lifeless: then it's probably no error.. ;) - btw: another case of the comments/data being eaten. I really get to the habit of copying the most important fields to the clipboard before submitting something on LP. Chromium does not refill the form elements when going back.
[21:13] <lifeless> blueyed: file a bug ?
[21:13] <lifeless> [on chromium]
[21:14] <blueyed> I guess it's rather related to cache headers/ssl which prevents this. could be the case with FF, too.
[21:15] <lifeless> blueyed: filing a bug means  it might get fixed.
[21:16] <blueyed> I would bet that there's a bug filed for both LP and Chrome already. and yes, it might get fixed.
[21:22] <lifeless> shrug
[21:22] <lifeless> up to you, I wouldn't bet anything on that bet
[22:20] <rdz> hi all. i added a package to my ppa which has version 1.2.0pre1-1. ubuntu repos have version 1.1.0-2. although i added my ppa to the sources, aptitude still wants to install ubuntu's version. how are versions compared? do i have to specify the package at a different location as well (beside debian/control)=
[22:20] <rdz> ?
[22:38] <geser> rdz: have you run "aptitude update" after you added your PPA?
[22:40] <rdz> geser, i did
[22:40] <geser> what's the package name?
[22:41] <rdz> libgavl1
[22:43] <Some_Person> I have a 75MB package in my PPA. I need to get my debian folder out of the package but do not want to download 75MB because of my slow connection. Anything I can do?
[22:44] <geser> Some_Person: if it's a non-native package and the upstream tarball didn't contain the debian dir, then downloading the diff.gz is enough
[22:45] <Some_Person> Package has a completely different rules file than the one upstream due to changes since that version
[22:45] <geser> rdz: does "apt-cache policy" list your PPA?
[22:45] <Some_Person> Also, wouldn't the diff.gz only give me changes since the last version uploaded?
[22:46] <rdz> geser, no, it doesn't
[22:46] <geser> the diff.gz contains all differences compared to the upstream tarball (like e.g. a debian directory or patches)
[22:46] <Some_Person> There have been numerous changes since upstream
[22:47] <Some_Person> upstream package is 2 years old, lots of development since then
[22:47] <geser> rdz: then you probably didn't add your PPA correctly. how did you do it?
[22:47] <geser> then the .diff.gz will contain all those changes (if they aren't part of the .orig.tar.gz)
[22:48] <rdz> geser, sudo add-apt-repository ppa:reduzierer/rdz-pd-extra+deps
[22:55] <rdz> geser, when adding the ppa the traditional way (adding to /etc/apt/sources.list manually, adding the key manually) it works
[22:56] <rdz> although it did not work before, my ppa was listed by the software-properties-gtk gui program
[22:59] <rdz> geser, thanks for your help
[23:09] <rdz> i have troubles finding the information: how can i tell the ppa to compile for many supported distros?
[23:20] <geser> you need to re-upload for each release you want to support (and update the version and distribution field in the changelog)
[23:21] <rdz> geser, i see. why does the verion also need to be updated?
[23:21] <rdz> *version
[23:22] <geser> because you can upload a version only once (and because all files for a package are stored together and the version is part of the filename)
[23:23] <rdz> hm..how do you call the different versions then (that are actually the same)?
[23:23] <rdz> sorry for the noobish questions...
[23:24] <geser> you can just append e.g. ~karmic or ~jaunty to your version string. that's enough to make the different
[23:25] <rdz> geser, thanks
[23:39] <poolie> hi thumper - which bug has >1000 subscribers?
[23:41] <poolie> oh nm, i can find out
[23:41] <poolie> OOPS-1526ED777
[23:42] <poolie> bug 1 of course
[23:42] <poolie> jeez, why would someone want to subscribe to that?
[23:42] <idnar> I was just thinking the same thing
[23:50] <poolie> lifeless, btw https://bugs.launchpad.net/bugs/534066 broke hydrazine bugclient fairly completely :-/
[23:59] <lifeless> poolie: ugh
[23:59] <wgrant> I wonder if it's the heat bug.
[23:59] <wgrant> But it seems unlikely that that would fail every time.