[00:22] <ScottK> Is it on purpose there's only one amd64 builder and i386 has seven?
[00:27] <wgrant> ScottK: Someone Ubuntuish probably moved them across to take care of the langpacks.
[00:27] <ScottK> wgrant: Hmmm. Probably.  Can they be put back?
[00:28] <wgrant> Indeed, just doing so now.
[00:28] <ScottK> Cool.  Thanks.
[00:28] <wgrant> Much better.
[00:28] <ScottK> I don't suppose you can give ross a kick too?
[00:29] <wgrant> ross or rothera?
[00:29] <ScottK> Oh, I see it's better now.
[00:29] <ScottK> ross was dead a few minutes ago.
[00:29] <wgrant> Hm
[00:29] <wgrant> I didn't fix it.
[00:29] <ScottK> Indeed, kicking rothera wouldn't hurt, but we're not sort on i386 builders.
[00:29] <wgrant> It was doing nothing for 12 hours, though, which is a bit odd.
[00:30] <wgrant> rothera has hardware issues.
[00:30] <ScottK> I checked ~5 minutes ago and ross had a big red X next to it on the builder page.
[00:30] <ScottK> Maybe when you reconfigured the others something got reset?
[00:31] <wgrant> Nope. Someone else must be playing with them.
[00:31]  * ScottK suspects infinity.
[00:31] <wgrant> Indeed.
[00:33] <micahg> hloeung got ross fixed
[00:34] <wgrant> Ah
[00:34] <wgrant> Too many IS channels.
[00:40] <spm> wgrant: 6-7 isn't  "too many!!!
[00:40] <lifeless> 67 is
[00:41] <cjohnston> Does staging.launchpad.net get reset every so often, or is it something I could create a sprint on to use for testing for a week with Summit?
[00:43] <lifeless> yes, weekends
[00:43] <cjohnston> lifeless: every weekend? so if I set up a sprint on Monday, I would have ~Friday to do testing and whatnot?
[00:43] <wgrant> cjohnston: Right.
[00:43] <lifeless> yah
[00:44] <cjohnston> sweet
[00:44] <cjohnston> thanks
[01:33] <michaelh1> Hi there.  Is there a HTTP URL for https://launchpad.net/gcc-linaro/4.6/4.6-2012.03/+download/gcc-linaro-4.6-2012.03.tar.bz2?
[01:33] <michaelh1> I want to point to it from an auto builder, but want to put a HTTP proxy in the middle to cut the download time.
[01:36] <StevenK> It should redirect to the librarian
[01:45] <michaelh1> StevenK: yip, which serves over HTTPS
[01:45] <michaelh1> You can go to http://launchpad.net/*, get redirected to https://launchadlibrarian/*, hit Ctrl-C, then go to http://launchpadlibrarian/* and it will work
[01:45] <michaelh1> But that's not automatic or documented.
[01:46] <tsimpson> michaelh1: librarian is http too
[01:46] <tsimpson> just take of the 's'
[01:47] <michaelh1> I'm using an existing tool that takes an URL and then internally does a wget.  I'd have to hack it quite a bit to handle the http -> https redirect.
[01:54] <maxb> wget should easily handle downloading it over https, so what's the real problem?
[01:56] <dobey> michaelh1: echo $url|sed -e "s/^https/http/"|wget
[01:57] <StevenK> But that won't work either, since you need to redirect and then change the URI scheme.
[01:57] <dobey> michaelh1: although it shouldn't matter. the proxy is not the connection to the outside server. the proxy server should still be able to let you connect to https outside
[01:57] <michaelh1> dobey: yes, but only after I've found out what the redirect is
[01:57] <rmk> Is there any way to copy base ubuntu packages into a PPA?
[01:58] <michaelh1> This is an auto builder.  I don't want to hit Launchpad with each build due to speed and download count issues
[01:58] <dobey> rmk: no, and there isn't any need to unless you want to change it, which means you download the source, make changes, and upload to ppa
[01:59] <dobey> michaelh1: auto-builder to build packages?
[01:59] <michaelh1> No, this uses crosstool-NG to build a binary toolchain from the Linaro toolchain source
[01:59] <michaelh1> So the build scripts change but the aunchpad hosted tarball doesn't.
[01:59] <rmk> dobey: Yeah I wanted to try a rebuild of the same package for oneiric
[02:00] <michaelh1> It would be nice if a http://launchpad.net URL redirected to http://launchpadlibrarian
[02:01] <dobey> rmk: backporting things often requires a lot more work than just copying things over and rebuilding. and the version in debian/changelog should be changed to append ~oneiric1 for example, so that the actual precise version is still newer, if one were to install from the ppa, then upgrade
[02:02] <dobey> michaelh1: i don't understand why the non-ssl url matters.
[02:03] <michaelh1> Because I want to cache the file in a local proxy.  HTTPS will go through the proxy but then I'll end up re-downloading ~70 MB each time the build script changes
[02:03] <dobey> why? the proxy should still cache it
[02:03] <michaelh1> A proxy can't cache HTTPS as it would have to decrypt it
[02:04] <dobey> s/can't/isn't supposed to/ :)
[02:05] <michaelh1> dobey: afraid not unless you do HTTP to the proxy and then HTTPs past that.  You can cache it as an end user, but not in a proxy
[02:06] <rmk> dobey: Fair enough. These particular packages tend to work across distros but your point is valid.
[02:06] <dobey> michaelh1: i presume you're sticking this url inside a script or conf file said script reads?
[02:06] <rmk> I'll do a rebuild and submit it to the PPA.
[02:06] <rmk> Thanks.
[02:07] <michaelh1> dobey: yip.
[02:07] <wgrant> michaelh1: Generally that sort of caching should be done locally.
[02:07] <dobey> michaelh1: why not just stick the http://lauanchpadlibrarian.net/ url there instead?
[02:07] <michaelh1> dobey: it's hard to maintain and bypasses the download count
[02:07] <wgrant> We used to serve that over HTTP, but the world has now come to its senses.
[02:07] <wgrant> And HTTPS can be used pretty much universally.
[02:08] <wgrant> dobey: Does not bypass the download count.
[02:08] <wgrant> er, michaelh1 ^^
[02:08] <michaelh1> wgrant: OK.  It seems that a proxy using existing tools would be much easier then implementing a new type of caching in the client
[02:09] <michaelh1> I understand that HTTPS everywhere is a good goal
[02:09] <dobey> if [ ! -f $localcopy ]; then weget $remoteurl -O $localcopy; fi ?
[02:09] <wgrant> michaelh1: It would be easier, but it is also a rather bad idea to download stuff for an autobuilder without verifying it...
[02:10] <michaelh1> wgrant: true, but GPG and md5sums can help there.
[02:10] <dobey> right; so add a sha256sum check to that
[02:10] <michaelh1> Having https doesn't authenticate the package
[02:10] <wgrant> It doesn't, no.
[02:11] <dobey> nor does having a proxy cache it
[02:12] <wgrant> Sure, but you could verify it against a trusted signature afterwards.
[02:13] <michaelh1> Yip.  And having a proxy means nothing to manage, faster downloads, and no change or hacks to the tool set.
[02:13] <wgrant> Anyway, we will not serve things over HTTP.
[02:14] <wgrant> If you don't want to implement local caching (like most build tools do), you'll need to intercept the redirect and rewrite it to HTTP.
[02:14] <dobey> except for having to manage a proxy. :)
[02:27] <maxb> Re above.... actually you can copy Ubuntu primary archive packages into a PPA
[02:27] <maxb> Which is actually really handy at times
[02:28] <maxb> https://launchpad.net/~maxb/+archive/preserved for example
[02:32] <dobey> and *how* do you do that exactly?
[02:33] <bigjools> with the API
[02:33] <dobey> right
[02:33] <bigjools> see Archive.syncSource
[02:33] <dobey> so in other words, you can't do it on the web site.
[02:33] <bigjools> not reliably
[02:33] <dobey> and most people don't want to write a program to do it
[02:34] <micahg> ISTR soren writing a tool for that
[02:34] <bigjools> the kind of people who want to do it are the kind of people who can write some code to do it
[02:34] <wgrant> Where 'some code' == 1 line in lp-shell
[02:34] <bigjools> it's like three lines total
[02:34] <dobey> i don't see why anyone would want to do that
[02:35] <bigjools> well, feel free to fix the timeouts on the archive page if you want to do it in the UI
[02:35] <dobey> i don't want to do it :)
[02:36] <bigjools> "you
[02:36] <bigjools> "
[02:36] <bigjools> :)
[02:36] <dobey> heh
[02:36] <dobey> it just seems like something that is too easy for people to get wrong and break things
[02:36] <bigjools> the PPA page is not designed to handle the 16k+ packages that's in the Ubuntu archive
[02:36] <dobey> sure
[02:37] <bigjools> and it's rather trivial too either use the API or download the package and re-upload
[02:37] <dobey> i am very aquainted with launchpad timeouts :)
[02:37] <bigjools> s/too/to/
[02:37] <dobey> yeah; download + dch + debuild + upload, seems like the best option for that
[02:38] <bigjools> dget to download
[02:38] <bigjools> very easy
[02:38] <dobey> anyway. i am not in oz. so i should probably get off here :)
[02:38] <bigjools> can even re-use the orig
[02:39] <dobey> aye; though it gets a bit more complicated if you're pulling from say oneiric, and building on lucid (since updates/proposed/etc might be the right place to pull from, and it's not always obvious)
[02:40] <dobey> anyway. night :)
[02:40] <maxb> I have to admit, I copied all the things to that PPA URL I posted using the web ui
[02:40] <maxb> and some carefully calculated URL hacking
[02:41] <bigjools> you're clued in :)
[07:45] <Pikkachu> how to delete packages form the PPA?
[08:32] <vivekimsit1> How can I merge my branch with some other branch?
[08:33] <nigelb> )/ws 30
[09:18] <vivekimsit1> How can I merge my branch with some other branch?
[09:20] <bigjools> vivekimsit1: bzr help merge
[09:21] <vivekimsit1> I can't find this link :"Click on the Propose for merging into another branch link. "
[09:22] <czajkowski> vivekimsit1: http://doc.bazaar.canonical.com/beta/en/user-guide/merging_changes.html  may be of some use to you
[09:34] <vivekimsit1> I not able to find the link "propose for merging the branch "! in the launchpad
[09:47] <jelmer> vivekimsit1: it should be on the branch web page
[09:48] <vivekimsit1> jelmer: Its not visible on my branch page! you can check it! : https://code.launchpad.net/~vivekimsit/commission/trunk
[09:51] <jelmer> vivekimsit1: it doesn't look like there are any other branches in the project
[09:51] <jelmer> vivekimsit1: you need at least two branches, as you'd merge one into the other
[09:52] <vivekimsit1> jelmer: Ya! Ok! but I want to merge my branch with some other project's branch (They basically the same but with diff names)
[09:57] <jelmer> vivekimsit1: I'm not sure if you can do cross-project merge proposals in Launchpad; bzr should support cross-project merges though.
[11:03] <DNX> hi guys! Do I have any chance to change my username with another already existing but unused? Few days ago I've mailed the account owner to ask him if they use this LP account, but no response received. Can you help me?
[11:03] <czajkowski> DNX: wasn;t that friday I suggested to mail them ?
[11:04] <DNX> yes czajkowski, you remember right
[11:05] <czajkowski> DNX: yup maybe give it till friday and give the person a chance to reply
[11:05] <DNX> :)
[11:06] <DNX> oook czajkowski, thank you
[11:09] <DNX> czajkowski, because this stops me to contribute more to https://code.launchpad.net/ubuntu-accomplishments-web-editor
[11:09] <DNX> or I'll be able to move my branch later?
[11:10] <czajkowski> DNX: nothing stops a person contributing :)
[11:11] <DNX> :) "contribute more"... because there are already some pull requests accepted from me. BTW you are right!
[11:12] <DNX> ok, I'll continue with my current nickname... until DNX' owner will respond
[11:12] <DNX> thank you for your time
[11:47] <Pikkachu> can anyone tell me why these packages weren't deleted yet? https://launchpad.net/~renatosilva/+archive/ppa/+packages?field.name_filter=&field.status_filter=&field.series_filter=
[11:47] <Pikkachu> the non-date and 20120311 were a mistake, only 20120315 should be there
[13:18] <XavB> Hi, I am trying to rebuild xserver for ARM + one patch on LP, armhf build is OK, unfortunately armel build is failing with strange error: "qemu: uncaught target signal 11 (Segmentation fault) - core dumped" - https://launchpad.net/~tiomap-dev/+archive/omap-trunk/+build/3293012
[13:19] <XavB> This was OK with previous xserver version: https://launchpad.net/~tiomap-dev/+archive/omap-trunk/+build/3254321
[13:19] <XavB> Is it a known issue?
[13:38] <ndec_> lool: did you see question from XavB ^^^. looks like there are qemu builders now?
[14:08] <lool> ndec_: that's right
[14:08] <lool> XavB: Hey
[14:09] <ndec_> so now there are new bugs ;-)
[14:09] <lool> XavB: There have been two types of errors hitting QEMU based builders really badly in the last weeks
[14:09] <lool> there was a workaround, but it would cause regressions for other uses
[14:09] <lool> the workaround was to set QEMU_RESERVED_VA=0
[14:09] <lool> the problem occurs on 64-bits host with 32-bits QEMU (our case)
[14:10] <lool> Then the QEMU mmap implementation would fail
[14:10] <ndec_> where to put this WA?
[14:10] <lool> this is something we patched in the qemu package that gets used there
[14:11] <lool> now Peter Maydell from Linaro redesigned this upstream starting from the OBS patches and I think we have patches so that it would work in all cases
[14:11] <lool> but the new qemu release had a regression, so that I'm not sure where it stands
[14:11] <lool> the next steps would be to merge the latest qemu-linaro release with a patch in precise, then use it for our buildds
[14:11] <ndec_> ouch... and how do we reliably build packages on LP then?
[14:11] <ndec_> is qemu used for armel only?
[14:12] <lool> https://bugs.launchpad.net/bugs/956875 seems to be a bug on the topic
[14:12] <lool> the regression preventing the precise update is https://bugs.launchpad.net/bugs/928432
[14:13] <lool> and the original discussion on the workaround and such is at https://bugs.launchpad.net/bugs/883136
[14:14] <lool> ndec_: I don't know whether it's enabled for armhf too; in fact, I don't know whether it's meant as a replacement for all virtual PPAs, for all non-virtual PPAs, or just for another set of PPAs; I would think Adam Conrad (infinity) would know, it's actually a project lead by buildd admins/sysadmins at Canonical AFAICT
[14:14] <lool> Nick Moffitt being one of the engineers working on the deployment of qemu binaries in buildd chroots
[14:15] <lool> slangasek is the person packaging new qemu-linaro updates into precise
[14:16] <XavB> lool: apparently, armhf builds are not using qemu
[14:16] <lool> In fact, it seems the new release is already in precise https://launchpad.net/ubuntu/+source/qemu-linaro/1.0.50-2012.03-0ubuntu1
[14:17] <lool> XavB: indeed, I see e.g. https://launchpad.net/builders/peryton as a PPA buildd which has "QEMU Armel buildd", but the two armhf PPA buildds don't have that
[14:18] <lool> that said, it would look exactly the same for armhf
[14:18] <lool> and it should if you ask me  :-)
[14:19] <XavB> lool: in fact, the most critical for me is the armhf version that is available even if armel build is KO, so I am happy to have different config for armhf... :D
[14:20] <lool> hehe
[14:20] <lool> XavB: You'd have to check with buildd admins as to which PPAs use QEMU buildds vs. real hardware for armel
[15:11] <elopio> Good morning.
[15:12] <elopio> I'm using launchpadlib on precise, and I get this on login_with
[15:12] <elopio> ssl.SSLError: [Errno 185090050] _ssl.c:340: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib
[15:12] <elopio> have you seen that? any idea?
[15:43] <czajkowski> elopio: has this onlys tarted to happen today ?
[15:43] <elopio> czajkowski: I noted it yesterday. But I haven't run the launchpadlib scripts for a couple of weeks.
[15:44] <czajkowski> are you still seeing the issues now if so can you file a bug and I'll get it looked into please?
[15:45] <elopio> czajkowski: sure. One second...
[15:45] <czajkowski> elopio: thanks
[15:57] <elopio> czajkowski: bug #959429
[15:57] <czajkowski> elopio: thanks
[16:02] <jadoe> Hi there. I just created a launchpad account.   http://s3.imgimg.de/uploads/launchpadad1b471apng.png Is this normal?
[16:03] <czajkowski> jadoe: what browser are you using ?
[16:03] <jadoe> midori and firefox, looks this way in both of them
[16:04] <czajkowski> jadoe: and what OS ?
[16:04] <jonrafkind> if I upload a new package for some series, are all the old packages (source/binaries) deleted for that series?
[16:05] <czajkowski> jadoe: also what is the lp ac name please?
[16:05] <apw> when i add a new GPG key to my account, is it only the current contact address email which is notified ?
[16:06] <jadoe> czajkowski: account name = email address? launchpad@maps.rubbldiekatz.de
[16:06] <jadoe> czajkowski: Ubuntu 11.10
[16:06] <czajkowski> jadoe: user name?
[16:06] <jadoe> czajkowski: Alfons Bauer
[16:07] <czajkowski> apw: yes
[16:07] <czajkowski> jadoe: I'm not seeing the lp page created under the email address or alfons
[16:08] <czajkowski> jadoe: on the lp page launchpad.net/~username what is the username ?
[16:11] <jadoe> czajkowski: the site I get to, when I click on my name? https://launchpad.net/~78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1oh-90kfclz5t-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x
[16:12] <jadoe> czajkowski: I don't see a "user name" there, only  launchpad id. and launchpad id is that long letter-number-mess
[16:12] <czajkowski> jadoe: yes that is a bit messy
[16:12] <czajkowski> what did you want it to be
[16:13] <jadoe> czajkowski: i don't remember being asked for it, only name, mail, password. are you about to change it? jadoe
[16:13] <czajkowski> jadoe: you already have an account set up https://launchpad.net/~jadoe
[16:13] <czajkowski> shall I remove the other account for you?
[16:14]  * jadoe is confused now
[16:14] <jadoe> one sec
[16:14] <czajkowski> you've created 2 accounts and the user name Jadoe is one of the them, and the other you seem to have copied some long string into the user name text box
[16:14] <jadoe> czajkowski: ok, remove the new on
[16:15] <czajkowski> done
[16:16] <jadoe> clipit says I did not have that string in the clipboard. how could I have copied it in the user name text box? and where was that user name text box? I don't remember seeing it. But never mind, thank you.
[16:40] <jonrafkind> if I upload a new package for some series, are all the old packages (source/binaries) deleted for that series?
[16:46] <czajkowski> jonrafkind: may be of some use to you https://help.launchpad.net/Packaging/PPA/Uploading#Uploading_with_SFTP
[17:04] <jonrafkind> i dont see my question answered in that section
[21:00] <ScottK> Did LP change it's download URL patters a few months ago?  Debian/watch files for my LP hosted projects no longer work.
[21:01] <ScottK> This used to work:
[21:01] <ScottK> http://launchpad.net/authentication-results-python/+download http://launchpad.net/authentication-results-python/.*/.*/authres-(.*)\.tar\.gz debian uupdate
[21:01] <ScottK> What would it be now?
[21:05] <dobey> ScottK: what version are you expecting it to pick up?
[21:05] <ScottK> 0.399 now
[21:05] <ScottK> It doesn't pick up any version at all anymore.
[21:07] <ScottK> https://launchpad.net/authentication-results-python/trunk/0.399/+download/authres-0.399.tar.gz
[21:07] <ScottK> It didn't pick up https://launchpad.net/authentication-results-python/0.3/0.3/+download/authres-0.3.tar.gz either when that was the current release.
[21:07] <dobey> hrmm, that's odd
[21:08] <dobey> it seems to also not work when i run uscan in lp:ubuntu/ubuntuone-installer
[21:08] <dobey> or at least, it does something and just exits. doesn't print anything
[21:08] <ScottK> Got it.
[21:08] <dobey> and exits with code 1
[21:08] <ScottK> If I change the second one to https:// it works.
[21:09] <dobey> ah
[21:10] <dobey> i guess it did change and broke uscan :(
[22:10] <wgrant> ScottK: We removed direct HTTP access a month or so back, because there was very little justification for it past 2006.
[22:11] <ScottK> wgrant: Reasonable.
[22:11] <ScottK> It just broke all my watch files ...
[22:11] <wgrant> Heh
[22:11] <jelmer> mine too :)
[22:11] <wgrant> Should have all been HTTPS already, I guess :)
[22:12] <ScottK> I rarely examine watch files beyond the point of "it works".
[22:12] <ScottK> I cargo culted the format for an LP watch file from somewhere.