[00:46] <micahg> I remembered a bug about making project/distro bug tasks interchangeable, is it bug 1334
[00:46] <micahg> or is there another
[00:47] <wgrant> There is a specific bug for it.
[00:49] <micahg> wgrant: would you happen to have the number?
[00:52] <wgrant> micahg: Bug #80902
[00:52] <micahg> thanks wgrant
[00:53] <micahg> oh, I was looking in malone, that's why I couldn't find it :)
[00:53] <wgrant> micahg: It is in malone.
[00:53] <wgrant> But I couldn't find it directly either.
[00:53] <wgrant> I only found it from a reference in another bug.
[00:54] <micahg> hmm
[00:54] <micahg> now it comes up
[00:54] <micahg> maybe it was there before
[00:54] <micahg> I was searching for 'project distribution'
[00:55] <wgrant> I couldn't find it because my queries included 'task'
[00:55] <micahg> yeah, that was my first few searches
[02:00] <fmarier> so I complained to my ISP that Launchpad PPAs are not working through their transparent proxy and here's what their response was: "Its due to the administrators of those hosts not using cache control headers. I will try to get int touch with them and apply a LART, it may take some time as its low priority. Best thing you can do, is suggest to them that they use cache controls like everyone else."
[02:02] <Ursinha> spm: ^
[02:04] <spm> wget -Sv ppa ==> Cache-Control: max-age=31536000, public
[02:04] <spm> fmarier: which ppa in question?
[02:05] <fmarier> spm, my own: deb http://ppa.launchpad.net/fmarier/ppa/ubuntu karmic main
[02:07] <spm> intresting. my file in the test above came from the librarian; yours from the ppa server. most interesting....
[02:08] <fmarier> (just realised that i should probably include the trailing slash in my sources.list to avoid the unnecessary 301...)
[02:08] <spm> fmarier: what's the issue you're seeing - it simply takes ages for you ppa files to be notcied as refreshed - the main dexy ones as in?
[02:08] <spm> indexy*
[02:08] <fmarier> spm, i get a GPG BADSIG when I run "apt-get update"
[02:09] <spm> awesome
[02:09] <delfick> Hello, how do choose "won't fix" for the status of a bug report ? for me, it's blanked out and unclickable...
[02:09] <Ursinha> delfick: I think you can only choose this if you're a bug supervisor of the project
[02:10] <delfick> I am
[02:10] <delfick> actually... I own the project
[02:10] <delfick> how does one become a bug supervisor?
[02:10] <fmarier> spm, I'm also getting the same error from http://nz.archive.ubuntu.com now (and my PPA seems to be fine today)
[02:11] <Ursinha> delfick: you go to the main project page, and click on the yellow ! in the right side of Bug Supervisor (I guess)
[02:11] <Ursinha> now not sure if it's the main page or the bugs page
[02:11] <wgrant> It's on the Bugs page.
[02:12] <mwhudson> don't see Cache-Control headers on say http://ppa.launchpad.net/fmarier/ppa/ubuntu/dists/karmic/Release
[02:12] <spm> fmarier: urgness. sounds to me like the transparent proxy is being too aggressive in caching. holding stuff for too long; our fix would just enforce a faster timeout of same.
[02:12] <spm> mwhudson: agreed.
[02:12] <mwhudson> do see Last-Modified and Etag thoguh
[02:12] <delfick> wgrant, Ursinha : hmm, can't see a yellow ! :(
[02:12] <mwhudson> my brain is incompatible with the bits of the http rfc do with this
[02:13] <spm> mwhudson: I've managed to purge it. used to have a copy of the 1.1 rfc dog eared on my desk @ $job-1. horrible stuff.
[02:13] <delfick> except for "Edit bug mail subscription'
[02:13] <fmarier> mwhudson, what arguments are you passing to wget to see those?
[02:14] <spm> fmarier: -Sv
[02:14] <mwhudson> fmarier: what spm said, -Sv
[02:14] <fmarier> i'm using "wget -Sv -O /dev/null http://ppa.launchpad.net/fmarier/ppa/ubuntu/" and i don't get any of these headers
[02:14] <mwhudson>   Last-Modified: Wed, 18 Nov 2009 01:11:23 GMT
[02:14] <mwhudson>   ETag: "93fc132-1019c-4789aebc9a4c0"
[02:14] <mwhudson> fmarier: well i guess we know whose fault that is!
[02:16] <mwhudson> fmarier: i also don't see headers on that directory
[02:18] <Ursinha> delfick: are you logged in?
[02:18] <delfick> yeap
[02:18] <spm> I suspect a bug vs soyuz at this point is in order. I'm not familiar enough with the intricacies of debs and apt and transparent proxies to just make the change
[02:19] <fmarier> spm, should I file a bug?
[02:19] <lifeless> spm: transparent proxies are just plain bad
[02:19] <fmarier> lifeless, +1
[02:19] <spm> fmarier: please  - I'll subscribe the losas to same
[02:19] <spm> lifeless: +111
[02:19] <lifeless> spm: there is one in NZ run by clear that fucks ubuntu dist-upgrades
[02:20] <fmarier> that's the one :)
[02:20] <wgrant> lifeless: +10000
[02:20] <spm> I was about to ask... :-D
[02:20] <fmarier> TelstraClear ftw
[02:20] <lifeless> s/w/l
[02:20] <lifeless> fmarier: so a TODO I have
[02:20] <lifeless> is to whip up a squid config to add no-cache to the cache-control headers
[02:20] <lifeless> then point folk @ that squid
[02:21] <fmarier> spm, so I should file a bug against soyuz, right?
[02:21] <lifeless> (many intercepting proxies honour cache busting headers)
[02:21] <spm> fmarier: yup
[02:21] <wgrant> So there is actually an ISP in NZ that has a transparent proxy?
[02:22] <fmarier> yes and it doesn't make the interwebs go any faster :(
[02:22] <mwhudson> i'd be surprised if there was one that doesn't
[02:22] <sproaty> is it me or the little yellow circle "edit" button misleading in places?
[02:22] <mwhudson> fmarier: who are you with?
[02:22] <fmarier> TelstraClear
[02:22] <mwhudson> oh you said just above
[02:22] <sproaty> sometimes it opens ajax request boxes, other times it opens a URL -- always hard to tell which
[02:23] <wgrant> sproaty: Yes. Some of the links are green, others are blue. But there's no text in those cases, so the colour doesn't show :(
[02:23] <mwhudson> fmarier: is that the cable lot, or adsl?
[02:25] <lifeless> wgrant: all of NZ
[02:25] <sproaty> https://launchpad.net/whyteboard/0.39  - like here (probably can't see it since I'm the owner) - but there's many edit icons next to things like "No Release Manager" that opens a new URL, whereas the icons for say, editing a bug status is ajax'd
[02:25] <lifeless> wgrant: for all intents and purposes
[02:25] <lifeless> mind you telstra are just cheap, the southern cross cable should have capacity ;)
[02:28] <ajmitch> you could say that about all NZ ISPs, being cheap
[02:28] <fmarier> mwhudson, it's on cable
[02:28] <mwhudson> fmarier: how is it, apart from the terrible proxy?
[02:28] <fmarier> spm, i've just filed https://bugs.launchpad.net/soyuz/+bug/485151
[02:30] <fmarier> mwhudson, it's a bit early to say (i only started using it a few days ago) but so far i'm not too impressed
[02:30] <mwhudson> oh dear
[02:30] <spm> fmarier: ta; have subscribed the losas; so we shall see.
[02:30] <fmarier> i'm glad i'm not on a contract though, i might be going back to DSL
[02:30] <fmarier> spm, thanks!
[02:30] <mwhudson> we were thinking of switching to cable when we move to welly
[08:08] <mwhudson> maxb: hey, i build launchpad dependencies 0.57 for karmic
[08:08] <mwhudson> maxb: does it still need to be rebuilt for hardy?
[08:09]  * mwhudson is not here fwiw
[08:09] <maxb> yup, and let's take the opportunity to fix the version too
[08:09] <maxb> ah
[08:09] <maxb> It would be great if someone could reassign the branches to ~launchpad-committers so I can push too
[08:10] <maxb> By fix the version, I mean, call it 0.57~hardy1 such that the hardy version is less than the later series, as it should be
[08:13] <RenatoSilva> can't we delete groups?
[08:13] <maxb> groups?
[08:14] <RenatoSilva> sorry, teams
[08:15] <maxb> You can ask an admin for a team to be deactivated, which hides it
[08:15] <RenatoSilva> we were talking about creating a group and we ended up creating two groups at the same time
[08:16] <henninge> maxb: afaiu it is actually deleted (for all that it's worth).
[08:16] <henninge> RenatoSilva: If you are the group owner, please add a request to the answer tracker.
[08:16] <dreimark> how can I change my Contact Address in launchpad?
[08:17] <henninge> *team owner* !!!
[08:17] <henninge> ;-)
[08:18] <henninge> dreimark: https://launchpad.net/people/+me/+editemails
[08:19] <henninge> RenatoSilva: https://answers.launchpad.net/launchpad/+addquestion
[08:19] <dreimark> henninge: thx
[08:22] <dreimark> aha a I should have done a reload, thought it didn't changed
[08:25] <RenatoSilva> henninge: thanks https://answers.launchpad.net/launchpad/+question/90830
[08:30] <RenatoSilva> code hosting offline in LP?
[08:30] <RenatoSilva> how long?
[08:31] <spm> RenatoSilva: per topic. ~ 4 hours in total; hopefully less. but.
[08:31] <RenatoSilva> weird, I just branched a project now
[08:32] <RenatoSilva> it's 6:30am here, and 8:30 UTC
[08:33] <spm> RenatoSilva: that'd be a nice trick. the server in question is shutdown. :-)
[08:38] <RenatoSilva> hmm, dir created at  05:57:25
[09:22] <thekorn> hi,
[09:22] <thekorn> wasn't there a nice error page on http://bazaar.launchpad.net in the past
[09:22] <thekorn> all i get is this generic browser page
[09:23] <wgrant> thekorn: The server is actually offline this time.
[09:24] <thekorn> ah ok
[09:25] <maxb> Would have been nice to have brought something else up on the IP address to display a notice
[09:27] <thekorn> and as a super bonus, it would be nice if the same kind of message could be shown when running bzr instead of "[...]Please check connectivity and permissions, and report a bug if problems persist.[...]"
[09:35] <maxb> It would be a bit trickier to make that happen for ssh
[10:25] <rowinggolfer_> getting an error message with bzr push. ssh: connect to host bazaar.launchpad.net port 22: Connection refused
[10:25] <rowinggolfer_> is the problem at my end?
[10:32] <noodles775> rowinggolfer_: Codehosting is temporarily offline (see topic)
[10:32] <rowinggolfer_> noodles775, thanks.
[10:59] <RenatoSilva> from #bzr:
[10:59] <RenatoSilva> RenatoSilva: bialix: in LP there's a section in the branch "Repository format:  Packs 6 (uses btree indexes, requires bzr 1.9)"
[10:59] <RenatoSilva> bialix: it's eq to 1.9 format
[10:59] <RenatoSilva> RenatoSilva: wouldn't one be interested in the "storage formats" like displayed in bzr help current-formats, rather than this specific internal info?
[11:23] <gioele> hello
[11:23] <gioele> I proposed to merge a branch of mine into bzr. I got some comments, changed the code and pushed the updated branch. What should I do now to make to tell the reviewers (and launchpad) that I updated the branch?
[11:24] <gioele> Should I use the "Request another review"?
[11:24] <gioele> or should I use "Propose for merging" again?
[11:24] <noodles775> gioele: Launchpad will automatically update the diff displayed on your merge proposal, so no need to resubmit...
[11:25] <noodles775> gioele: but it is worth replying to the comments on the MP (this will email anyone who has reviewed the MP already).
[11:25] <gioele> noodles775: how long does it take usually? seconds/minutes/hours?
[11:25] <noodles775> My general approach is to reply to a comment with my responses inline, and if it's worthwhile, include a link to a paste of the incremental.
[11:26] <noodles775> gioele: normally within 10 minutes (afaik, but someone from codehosting can confirm), but codehosting was down for an upgrade for the past 4 hours.
[11:27] <gioele> noodles775: ah, OK, I'll wait then. I don't want reviewers to see the old version when they receive the email
[11:28] <noodles775> gioele: great. losa: do you know if the process that updates diffs on MP's back up and running since the upgrade?
[11:28] <noodles775> s/MP's/MP's is
[11:43] <maxb> RenatoSilva: That string comes from bzr itself, it's not an invention of Launchpad. Though I agree the command-line terse alias would be more useful
[11:45] <RenatoSilva>  maxb: ok, hope someone change than in the future :)
[11:46] <maxb> RenatoSilva: Looks to me like the bzr code doesn't make it easy to do the lookup from format object to command-line name. Which is probably why LP is set up to show the description, which is retrievable easily
[11:47] <RenatoSilva> maxb: bzr xmlinfo
[11:47] <maxb> bzr: ERROR: unknown command "xmlinfo"
[11:49] <RenatoSilva> maxb: it's a plugin shipped with bzr 2, you may want the dev version: bzr branch lp:bzr-xmloutput $plugins/xmloutput
[11:51] <maxb> RenatoSilva: It doesn't work very well. It tells me 'unnamed' in most of my non-2a branches
[11:51] <RenatoSilva> maxb: #bzr told me it is a mix of formats
[11:51] <maxb> Not xmloutput's fault, given plain 'bzr info' does too
[11:52] <RenatoSilva> maxb: bzr info -v, will display the metadata that LP currently uses, but they told me that data are internal
[11:53] <RenatoSilva> maxb: btw, do you parse the raw output of bzr info -v to get that info there in LP?
[11:53] <maxb> heh, "I" don't.
[11:54] <RenatoSilva> but do you know how is it done?
[11:55] <RenatoSilva> maxb: I think if the storage format is unnamed, then that's what LP should display
[11:55] <maxb> I have not found the code in LP, but based on grepping for the string in the bzr source, it looks like it's a simple matter of calling get_description() on the repository format object
[11:55] <maxb> RenatoSilva: No, because that would be useless
[11:56] <RenatoSilva> maxb: why?
[11:56] <maxb> If I tell you the format is unnamed, you have no useful information
[11:56] <RenatoSilva> maxb: why is internal data more useful than that?
[11:57] <RenatoSilva> if unnamed is useful info or not, it is a bzr issue I think, not LP's
[11:57] <maxb> Why do you think it's internal? It's a human-readable description. That's pretty external
[11:58] <RenatoSilva> I prefer 'unnamed' storage format than cool internal data that sounds absolutely random and doesn't matter for the end user
[11:58] <RenatoSilva> maxb: one from LP told the formats 1 2 3 4 5 etc way displayed in bzr info -v is internal information
[11:58] <RenatoSilva> maxb: for example, if you use an old bzr version, and you look at a branch in LP
[11:59] <RenatoSilva> maxb: and you see the format is 2a, you may know your old bzr can't work with that branch
[11:59] <RenatoSilva> maxb: it's like a bzr info in LP
[12:00] <RenatoSilva> maxb: current behavior is like a bzr info -v, (where verbose is not usually default in any tool, but it is in LP currently)
[12:01] <RenatoSilva> maxb: I think at a 1st look you could see the overall format (2a, 0.92 etc) (I think it was that way in LP 2?), then in some other page we would have "detailed info" (-v)
[12:02] <RenatoSilva> well, ideas :)
[12:11] <RenatoSilva> when you cerate a merge proposal to trunk where you branch contains a merge from trunk, shouldn't that revision be hidden in the "unmerged revisions" section?
[12:12] <maxb> No
[12:12] <maxb> Because it's a revision in your branch which isn't in trunk
[12:14] <RenatoSilva> ok, it won't get merged anyway, so no problem
[12:14] <wgrant> Why won't it get merged?
[12:18] <maxb> Or rather, it will get merged, why do you think otherwise? :-)
[12:19] <wgrant> That too.
[12:20] <RenatoSilva> the merge from trunk won't get merged into trunk
[12:21] <wgrant> It will.
[12:21] <RenatoSilva> why? trunk already contains the merged revisions
[12:21] <maxb> But it doesn't contain conflict resolution you may have done as part of the merge
[12:21] <RenatoSilva> ok you mean it will go in the history?
[12:22] <RenatoSilva> maxb: oh I see, the history with merges is still veru hard to understand to me
[12:23] <RenatoSilva> *very
[12:25] <RenatoSilva> for example
[12:26] <RenatoSilva> o.O http://img20.imageshack.us/img20/3403/65098324.png
[12:27] <RenatoSilva> there are cases with dashed lines too
[12:29] <maxb> RenatoSilva: dashed lines are not complicated. They just mean there is more history there than is currently being displayed.
[12:32] <RenatoSilva> ok, all this is hard to get, hopefully the only thing I need to know is that when I merge and branch, things get working
[12:32] <RenatoSilva> maybe someday I stop to understand that well
[16:04] <sproaty> so how do I get my application into ubuntu's repository?
[16:04] <sproaty> I think I accidently linked my project to Jaunty, https://launchpad.net/ubuntu/jaunty/+source/whyteboard
[16:16] <tsimpson> sproaty: if you want to get a package into Ubuntu, you should start with the MOTU at #ubuntu-motu
[16:17] <sproaty> cheers
[16:28] <cyberix> I'm trying to do "this bug also affects Debian"
[16:29] <cyberix> What should I use as the bug tracker url?
[16:29] <cyberix> I know the bug number, but Debian uses a mailing list for bug reporting
[16:29] <tsimpson> the URL from the debian bug tracker
[16:29] <cyberix> oh
[16:29] <cyberix> didn't know about that existing
[16:29] <tsimpson> bugs.debian.org
[16:29] <cyberix> thank you
[17:09] <jldupont> hi - I have a bunch of .deb repositories.  Is there an easy way just to "dput" those .deb in a PPA?
[17:12] <jldupont> ... just a link would be great!
[17:15] <maxb> jldupont: You can't upload pre-built .debs to PPAs, only debian *source* packages
[17:15] <jldupont> so no binary packages then?
[17:16] <maxb> All binary packages must be built by the launchpad build farm, not uploaded directly
[17:17] <jldupont> @maxb: Oh I see.... if my package contains Erlang source file, is this supported?
[17:17] <LarstiQ> jldupont: sure
[17:17] <jldupont> cool!
[17:17] <LarstiQ> jldupont: your package will need to declare the correct Build-Dependencies of course
[17:18] <jldupont> so the debian/rules file is used to buld the package?
[17:18] <LarstiQ> jldupont: yeah
[17:18] <jldupont> Thanks guys!
[17:18] <LarstiQ> jldupont: it's built as a Debian package, so everything that applies to building those applies
[17:19] <jldupont> I never had to worry about debian/rules before... I built my own apt repositories without those before...
[17:20] <jldupont> any pointers to a good debian/rules tutorial?
[17:20] <jldupont> let's just say that http://www.debian.org/doc/maint-guide/ch-dreq.en.html is thin on details...
[17:21] <maxb> It is quite strange to build .debs without using debian/rules
[17:22] <jldupont> @maxb: probably... but I pretty much figured out how to build one using bits & pieces of web pages...
[17:22] <LarstiQ> ehm, so how _do_ you build one?
[17:22] <jldupont> I am using a combination of Scons / make
[17:23] <jldupont> with tools such as dpkg-scanpackages etc.
[17:23] <LarstiQ> wow
[17:23] <maxb> None of those actually build .deb files
[17:23] <jldupont> @maxb: I don't have all the details OTH
[17:23] <jldupont> I just know I've got it working: http://erlang-dbus.googlecode.com/
[17:25] <LarstiQ> jldupont: apt-get install devscripts
[17:25] <jldupont> now I need to add signing and so I decided to revisit my whole process.
[17:25] <LarstiQ> jldupont: and invoke `debuild`
[17:25] <LarstiQ> jldupont: from the base of an unpacked debian source package
[17:25] <LarstiQ> jldupont: that will build your .deb
[17:25] <jldupont> ... assuming I've got a good debian/rules file I guess.
[17:26] <LarstiQ> jldupont: if it doesn't, it's a hint it needs work :)
[17:26] <jldupont> ;-)
[17:27] <jldupont> where do I drop my makefile?
[17:27] <LarstiQ> jldupont: depending on how far from a good rules file it is, the lintian errors are helpful
[17:27] <LarstiQ> jldupont: which makefile
[17:27] <LarstiQ> ?
[17:27] <LarstiQ> the upstream package one?
[17:27] <jldupont> upstream package??
[17:27] <LarstiQ> jldupont: what does your makefile do, exactly?
[17:27] <jldupont> let's say I have a bunch of .cc files and .erl files I need to compile
[17:27] <LarstiQ> right
[17:28] <jldupont> you said "sources package"
[17:28] <jldupont> and not binary packages... so I suspect launchpad will want my makefile to build stuff, no?
[17:28] <LarstiQ> jldupont: yes
[17:29] <jldupont> so, where do I drop my makefile in the folder hierarchy?
[17:29] <LarstiQ> same place it is now?
[17:29] <LarstiQ> jldupont: `apt-get source hello` might be helpful as an example?
[17:30] <jldupont> hmmm... let me check this out.
[17:30] <LarstiQ> jldupont: everything in debian/ is debian specific, and everything outside of debian/ is Debian orthogonal
[17:30] <jldupont> right. cool.
[17:31] <LarstiQ> so normally, you would have package/Makefile that just takes care of building the program
[17:31] <LarstiQ> and then package/debian/ which takes care of packaging it up
[17:31] <LarstiQ> specifically debian/rules for driving it, but debian/control is at least as important
[17:33] <LarstiQ> jldupont: debhelper(7) is a tool that does a lot of the heavy lifting
[17:33] <jldupont> I am missing a bit here...
[17:33] <LarstiQ> jldupont: which bit?
[17:33] <LarstiQ> jldupont: ( http://kitenet.net/~joey/blog/entry/ten_years_of_free_software_--_part_5_debhelper/ for a relevant blogpost by the author)
[17:34] <jldupont> so Launchpad is only concerned with .tar.gz file, right?
[17:35] <LarstiQ> jldupont: no
[17:35] <jldupont> the .dsc also maybe
[17:36] <jldupont> (sorry I am backtracking cos I am missing a bit here)
[17:36] <LarstiQ> jldupont: and the diff.gz
[17:36] <LarstiQ> (certainly the .dsc, if my reply wasn't clear)
[17:36] <jldupont> ok.
[17:37] <jldupont> I have peeked inside the hello stuff you pointed me to.
[17:37] <jldupont> I see .diff.gz, .dsc, .orig.tar.gz
[17:37]  * LarstiQ nods
[17:37] <jldupont> in the .orig, I see no /debian folder
[17:37] <LarstiQ> jldupont: correct
[17:37] <jldupont> then I am utterly confused now.
[17:37] <LarstiQ> jldupont: you'll find that in the .diff.gz
[17:38] <jldupont> ah!
[17:38] <glatzor> danilos, hello
[17:38] <glatzor> danilos, could you join the user contributed data in software-center session?
[17:38] <jldupont> .diff is a tar?
[17:38] <glatzor> danilos, it is a double session.
[17:38] <LarstiQ> jldupont: the orig being what one, as a Debian packager, would download from an upstream project. All the packaging bits go in the diff.gz and orig is left untouched
[17:39] <LarstiQ> jldupont: no, a gzipped diff
[17:39] <jldupont> makes sense.  You are being VERY helpful.
[17:39] <LarstiQ> jldupont: note that 'apt-get source hello' will have combined the various bits into a hello-version/ directory
[17:40] <LarstiQ> jldupont: in case you got a .dsc, orig and diff via other methods, dpkg-source -x .dsc will do the unpacking and assembling
[17:41] <LarstiQ> jldupont: you might want to make use of http://mentors.debian.net/ or the irc channel/mailinglist
[17:41] <jldupont> I am getting it now.
[17:41] <LarstiQ> jldupont: or Ubuntu MOTU for the Ubuntu side of things
[17:42] <jldupont> @LarstiQ: you are making my day!
[17:42] <jldupont> ok now,
[17:42] <LarstiQ> jldupont: gladly :)
[17:43] <jldupont> my makefile will reside in /package
[17:43] <danilos> glatzor, sure, in about 15 minutes, is that fine?
[17:43] <glatzor> danilos, great
[17:43] <jldupont> along with the rest of my source files etc
[17:43] <LarstiQ> jldupont: yup
[17:43] <jldupont> in /package/debian, the usual CONTROL files etc.
[17:43]  * LarstiQ nods
[17:43] <jldupont> along with the rules file
[17:44] <jldupont> I use debuild to package it up
[17:44] <jldupont> and then dput to upload it
[17:44] <LarstiQ> jldupont: yup, that's it
[17:44] <jldupont> on the other side,
[17:44] <LarstiQ> and then the launchpad build machines will process it, produce a package or an error
[17:44] <jldupont> Launchpad will build the package and inform me of any errors, wardning etc.
[17:45] <jldupont> ... how do I get notified of errors?
[17:45] <jldupont> snail email?
[17:45] <LarstiQ> jldupont: yeah, do take care to sign the package with a key that is registered in launchpad
[17:45] <LarstiQ> jldupont: email
[17:45] <jldupont> ok
[17:45] <LarstiQ> the email is sent to the account the key is attached to
[17:45] <jldupont> Is there a way to know in advance IF there will be errors?
[17:45] <jldupont> i.e. test run on my side AS Lanchpad would do it?
[17:45] <LarstiQ> jldupont: not a 100% guarantee
[17:46] <jldupont> hmmm.
[17:46] <jldupont> so, how long is the full cycle?
[17:46] <LarstiQ> jldupont: the kind of errors you won't notice locally are for example: forgetting to specify a necessary dependency you happen to have installed
[17:46] <jldupont> check
[17:47] <jldupont> so, turn around time is.... as fast as the web site ;-)
[17:47] <LarstiQ> jldupont: you could set up pbuilder locally to guard against such things
[17:47] <jldupont> launchpad.net is slow... at least on my side
[17:47] <jldupont> pbuilder??
[17:48] <LarstiQ> jldupont: pbuilder builds packages in a chroot
[17:48] <LarstiQ> (or other isolated enviroment)
[17:48] <LarstiQ> jldupont: it's the `pbuilder` package in Debian
[17:48] <jldupont> ... a sort of VirtualEnv like in Python?
[17:49] <LarstiQ> right
[17:49] <jldupont> cool !
[17:49] <LarstiQ> jldupont: the package provides the command 'pdebuild' which you call the same way as 'debuild'
[17:49] <jldupont> ... and I'll catch missing dependencies...
[17:49] <LarstiQ> but it copies your source over and does a build in a cleaner environment
[17:49] <LarstiQ> yes
[17:50] <LarstiQ> launchpad is like pbuilder, but remote, and higher latency ;)
[17:50] <jldupont> it will create another enviroment... but where?
[17:50] <LarstiQ> usually with more processing power than a lone laptop though
[17:51] <LarstiQ> jldupont: /var/cache/pbuilder iirc, but that is part of setting up pbuilder
[17:51] <LarstiQ> jldupont: for now, I wouldn't bother with it if I were you
[17:51] <jldupont> got it.
[17:51] <jldupont> let me get cracking and see how it goes!
[17:51] <LarstiQ> ok :)
[17:51] <jldupont> THANKS FOR ALL THE ALL !
[17:51] <jldupont> FOR ALL THE HELP i meant
[17:51] <jldupont> YOU ROCK!
[17:52] <LarstiQ> np, hope it helps
[17:52] <jldupont> I am sure it will!  I got by with MUCH less before!
[17:54] <jldupont> @larstiq: Wouter van Heyst ?
[17:55] <LarstiQ> that's me, yes
[17:55] <jldupont> (of course... sorry)... I'll shut up now. ciao
[17:55] <LarstiQ> jldupont: (in case you didn't know, irc clients have a /whois command that would, in my case, have told you that too)
[17:56] <jldupont> I was just checking the Launpad site to see if there was a correlation with larstiq... but of course there was.... silly me.
[17:56] <LarstiQ> :)
[17:57] <jldupont> I am new on Launchpad... been using GoogleCode for long.
[17:57] <LarstiQ> ah
[18:12] <jldupont> @LarstiQ: usually, in a .deb file, the "layout" in the filesystem is all done... I guess I'll need to cp files accordingly in debian/rules ?
[18:13] <LarstiQ> jldupont: usually, the upstream makefile has an 'install' target
[18:13] <LarstiQ> jldupont: debian/rules calls that install target, with DESTDIR set (often to debian/tmp/)
[18:13] <jldupont> got it. thanks
[18:14] <jldupont> in debian/tmp ?
[18:14] <LarstiQ> jldupont: a temporary area to gather files before packing them up
[18:15] <jldupont> So I have to respect DESTDIR in rules file then...
[18:15] <jldupont> important to know :-)
[18:15] <LarstiQ> jldupont: well, you provide it ;)
[18:15] <jldupont> ?
[18:16] <LarstiQ> jldupont: debian/rules sets DESTDIR, package/Makefile should respect it
[18:16] <LarstiQ> jldupont: if you have a simpler build process, you could do something like hello-2.2 does with `install`
[18:16] <tsimpson> would this discussion not be better in #ubuntu-motu ?
[18:17] <LarstiQ> tsimpson: probably
[18:17] <jldupont> ... but Larstiq is SO helpful.
[18:17] <tsimpson> well, you can _both_ join there ;)
[18:17] <LarstiQ> jldupont: other people can be helpful too :)
[18:18]  * LarstiQ is at his channel max, so that won't happen
[18:18] <tsimpson> register and get +e from staff
[18:18] <jldupont> what's "+e" ?
[18:18]  * tsimpson is in nearly 50 channels on freenode
[18:18] <maxb> +u, no?
[18:18] <tsimpson> erm, yes
[18:18] <tsimpson> +e is identified
[18:19] <LarstiQ> tsimpson: irc costs me enough time as is ;P
[18:19] <LarstiQ> but thanks for the hint, it's useful to know that is possible (nowadays?)
[18:19] <tsimpson> it's a feature of freenode, has been for quite a while
[18:20] <jldupont> I do not know what "+e" or "+u" are
[18:20] <tsimpson> jldupont: ignore +e for now, +u is a mode set which lets you join more channels. see the output of "/mode jldupont"  to see your modes
[18:21]  * LarstiQ gets back to his homework
[21:04] <oly_> errk, can anyone tell me how to resolve different rich-root support
[21:04] <oly_> bzr kept telling me i should upgrade my repository so i did but now seems to have stopped me uploading to launchpad :/
[21:05] <oly_> does that mean the remote copy should be updated as well some how ?
[21:11] <thumper> oly_: yes
[21:11] <oly_> i tried doing an upgrade and it said that backup.bzr already exists :p
[21:12] <oly_> is there a way i can remove that some how ?
[21:13] <oly_> hum, can you ssh in to edit the files direct ?
[21:13] <mwhudson> oly_: not ssh but sftp works
[21:14] <mwhudson> don't use the openssh sftp client though
[21:14] <mwhudson> as it doesn't have rm -rf
[21:14] <mwhudson> lftp works
[21:14] <oly_> okay what about filezilla as i am familiar with that
[21:16] <oly_> ah the gnome client seems to work
[21:17] <oly_> cheers for that, never realised i could do that
[21:20] <mwhudson> oly_: np
[21:20] <mwhudson> oly_: it's a bit weird until you get past the ~user/project/name part as that's a completely virtual filesystem
[21:22] <oly_> yeah, well i am deleting those bzr upgrade files will try upgrading my remote branch and then see if i can upload my local changes
[21:22]  * oly_ crosses his fingers
[21:22] <mwhudson> cool
[21:23] <mwhudson> bzr/launchpad should handle this better, somehow...
[21:24] <oly_> especially for those who are not that familiar with version control
[21:24] <oly_> its quite a steep learning curve i have found
[21:24] <oly_> know how to deal with situations that arise
[21:24] <mwhudson> yeah
[21:24] <mwhudson> well
[21:24] <mwhudson> everyone should just use the 2a format now
[21:24] <mwhudson> and likely for the next year or so
[21:24] <mwhudson> so this problem will actually fade a bit
[21:25] <oly_> yeah, but i just mean things in general like bringing branchs back in sec
[21:26] <oly_> s/sec/sync :p
[21:26] <oly_> i am getting there though
[21:26] <mwhudson> cool