[00:24] <Noldorin> hi guys
[00:25] <Noldorin> lifeless, jelmer
[00:43] <lifeless> hi there
[01:24] <MechanisM> hello. who can help me with creating ppa?
[01:25] <MechanisM> I'm so bored that ubuntu doesn't have latest chromium builds so I'm going to create new ppa with all latest builds and maintain it daily builds like
[01:26] <lifeless> https://launchpad.net/~chromium-daily/+archive/ppa
[01:27] <MechanisM> lifeless you sure it's latest? it has 18 chromium while now it's 21!
[01:27] <MechanisM> and it's called daily builds and latest build on january?
[01:28] <lifeless> micahg: ^ sup with that ?
[01:29] <MechanisM> lifeless I mean repos called daily builds but latest built there is only date january. actually all builds outdated even compare to stable.
[01:34] <MechanisM> I'm already discussed it with ppl here http://askubuntu.com/questions/112432/chromium-19-for-ubuntu <-- since 19 chromium I'm missing builds on chromium-daily ppa
[01:38] <MechanisM> Guys I'm a lot of time coding and so much need latest chromium coz I like it and work via this browser. Please help me create repos and I'll maintain it. So other ppl can use it. I'm really care about latest chromium builds
[01:40] <MechanisM> Currently I'm using bash script to download latest builds and put it in folders used by chromium-daily
[01:40] <lifeless> so there is a ppa that is meant to have daily builds alread
[01:40] <lifeless> chromium takes ages to build, its a waste to ahve two daily ppas.
[01:40] <lifeless> micahg runs the ppa, so I've asked him.
[01:40] <lifeless> Now we wait for a response:)
[01:41] <MechanisM> ok I hope this repos will back
[01:41] <MechanisM> lifeless sometimes not needed to build. just download from build server and package it as deb
[01:42] <MechanisM> all builds on build server
[01:44] <lifeless> MechanisM: Part of the way we make Ubuntu trustworthy is making the code that goes into it auditable and inspectable.
[01:44] <lifeless> MechanisM: downloading binaries from somewhere else and then uploading them would circumvent that entirely.
[01:45] <MechanisM> for example latest build of chromium for x64 is http://commondatastorage.googleapis.com/chromium-browser-snapshots/Linux_x64/139446/chrome-linux.zip just needed to be packaged. It's already built on ubuntu 12.04
[01:47] <MechanisM> lifeless okay I see your point
[01:48] <lifeless> I'll nag micahg when he comes online
[01:49] <MechanisM> lifeless okay I'm glad someone can see this problem
[01:49] <MechanisM> web dev not so good without lates chromium builds
[01:52] <MechanisM> lifleless btw do you know someone I can talk with my project related to ubuntu? I'm creating website where ppl can design and generate their own gtk3 themes and donload it etc.
[01:52] <MechanisM> about my project*
[01:56] <lifeless> MechanisM: what sort of role should this person have?
[01:56] <MechanisM> lifeless I'm just wanna know if it's really needed to community and if yes I need to find someone who can help etc.
[01:57] <MechanisM> to join the team
[01:58] <lifeless> so for the former bit, you could ask around, see how many folk want it
[01:59] <lifeless> for finding help, you can blog about it, and if lots of folk want it, they''ll probably repost it etc. :)
[02:00] <MechanisM> lifeless I know about it. So until I show any result noone cares
[02:01] <MechanisM> I wanted to get help before releses and not telling to others before release
[02:09] <jimis1> In a bug report, can I use special syntax for pasting code segments?
[02:09] <jimis1> like the {{{blah blah}}} in other wikis
[02:12] <bigjools> no, there's no special syntax.  You can attach patches though.
[02:12] <lifeless> bigjools: someone should finish poolies markdown branch ;)
[02:13] <lifeless> bigjools: by which I mean prod testing and feature flag enablement
[02:13] <bigjools> lifeless: you sound like a volunteer!
[02:13] <jimis1> alright, thanks bigjools
[02:14] <jimis1> bug filed, bzr slowness again :-p
=== Karmaon is now known as doesUbuntuHateAw
=== doesUbuntuHateAw is now known as AwayNickAwayNick
=== AwayNickAwayNick is now known as Karmaon
=== jimis1 is now known as jimis
[04:16] <micahg> lifeless: I've had a build failure for weeks on generating the translations for chromium 19, it's on my list (I've been off since Fri)
[07:51] <jf_> hi, please could you help me on bug #869022 : I can't branch my project.
[07:51] <ubot5> Launchpad bug 869022 in Bazaar "ValueError: Something wrong with: cp_off = 2314752, cp_size = 3 source_size = 494614, size = 89493" [Undecided,Confirmed] https://launchpad.net/bugs/869022
[08:21] <czajkowski> jelmer: are you alive?
[08:22] <czajkowski> mgz: vila jam ^^^^^^
[08:25] <vila> jf_: as explained in the bug, your local repository seem to be corrupted, you need to create a new one from lp. From there, you can try to rescue local bits if needed (but don't hold your breath)
[08:25] <jam> czajkowski: I'm around, but I don't know if jelmer is alive or not, I assume he is
[08:25] <jam> when I stopped by earlier, jf was no longer in chat
[08:25] <jf_> vila, is not the local repositroy but the repository in bazaar
[08:25] <czajkowski> was just help with bzr :)
[08:26] <vila> jf_: note that all corruption reports we got in the past years have all been linked to either: hard disk dying or hard crashes leading to disk corruption
[08:26] <jf_> vila, I can't push nor pull from.to my project
[08:26] <wgrant> vila: The repository on LP is corrupt.
[08:26] <vila> on lp ???
[08:27] <vila> darn, misread the bug, let me try
[08:33] <vila> jf_: reproduced locally, digging
[08:33] <jf_> so you will fix it ? :)
[08:33] <vila> jf_: hold on, I trying to understand what the issue is, it's a pre-requisite to even pretend it can be fixed :)
[08:34] <jf_> vila, ok thanks
[08:34] <vila> jf_: I can branch lp:unifield-server/sprint4 at least (but trunk and main fail)
[08:36] <vila> weird, after branching sprint4 (in a local shared repo), both trunk and main succeed
[08:36] <vila> jam: can you imagine what can allow such a scenario ??
[08:36] <jf_> vila, yes I know, it's very strange, but you can't: "bzr diff -c 3359.2.65"
[08:36] <wgrant> vila: That sounds rather expected.
[08:37] <wgrant> vila: The relevant repo bits are uncorrupted in sprint4.
[08:37] <wgrant> vila: So if you branch that first, it won't try to retrieve the corrupt bits from trunk...
[08:37] <vila> wgrant: on how can trunk and main succeed when I retry then ?
[08:38] <jam> vila: if there is a specific block that is bad, you only get the error when accessing it. so if you have a duplicate copy of the data that gets used, or if the current tip doesn't access it, etc.
[08:38] <wgrant> vila: It'll see the relevant texts or whatever are already in your shared repo, so it won't try to download them from trunk.
[08:38] <mgz> what's the bug #? predated me joining the channel.
[08:38] <wgrant> mgz: Bug #869022
[08:38] <ubot5> Launchpad bug 869022 in Bazaar "ValueError: Something wrong with: cp_off = 2314752, cp_size = 3 source_size = 494614, size = 89493" [Undecided,Confirmed] https://launchpad.net/bugs/869022
[08:38] <mgz> ta.
[08:38] <vila> jam: hmm, so a repack will be a russian roulette ?
[08:39] <jam> vila: repack will always touch everything
[08:39] <jam> so either it will always fail, or it will succeed and clean things up
[08:39] <vila> jam: but select one out of the duplicates right ?
[08:39] <wgrant> I suspect you want to just empty out the branch on LP and repush it from a good local copy.
[08:39] <jam> if it is dupes, yes
[08:39] <wgrant> Which can be obtained by grabbing sprint4 first.
[08:40] <vila> right, russian roulette indeed
[08:40] <jf_> wgrant, I can't push to a new repo
[08:41] <jf_> revno  3359.2.65 is corrupted when I push or when I pull
[08:41] <vila> jf_: this revno comes from which branch ?
[08:43] <jf_> vila, it comes from lp:openobject-server/6.0
[08:45] <vila> nah, I wanted the context where this revno is valid, it's neither in trunk nor sprint4
[08:45] <vila> 3359.2.65 is a 'launchpad automatic translation update' in trunk
[08:48] <vila> even weirder, sprint4 is stacked on trunk...
[08:49] <wgrant> What if the revision was first in sprint4, and merged into trunk later, at which point it was corrupted?
[08:49] <vila> ha right, several merges from sprint4 into trunk
[08:49] <vila> wgrant: yup
[08:50] <jf_> I think there isn't any merge from sprint4 to trunk
[08:50] <jf_> everything is developped on trunk and then push to sprint4
[08:54] <vila> bzr check bzr+ssh://bazaar.launchpad.net/~unifield-team/unifield-server/trunk fails
[08:55] <vila> bzr: ERROR: Corruption while decompressing repository file, zlib: Error -3 while decompressing data: incorrect data check
[08:55] <wgrant> vila: Interestingly, I can't branch sprint4 locally over bzr+ssh
[08:55] <wgrant> Or HTTP
[08:55] <vila> 8-/
[08:56] <wgrant> Ah
[08:56] <wgrant> main branches OK
[08:56] <vila> wgrant: try 'bzr init-repo xxx; cd xxx; bzr branch lp...' ?
[08:56] <jf_> to my mind, the only branch I can't branch from scratch is lp:unifield-server/main
[08:57] <wgrant> Yeah, main branches from scratch fine, trunk/sprint4 don't
[08:57] <wgrant> main has the relevant data uncorrupted.
[08:57] <vila> wgrant: standalone branches ?
[08:58] <vila> no, main, does not contain everything used in trunk/sprint4
[08:58] <wgrant> vila: Standalone branches of trunk/sprint4 fail, main works. If I then branch main into a shared repo, I can branch trunk/sprint4 into it.
[08:58] <vila> ha, right
[08:59] <vila> bzr check bzr+ssh://bazaar.launchpad.net/~unifield-team/unifield-server/main fails nevertheless
[08:59] <wgrant> vila: Hm, indeed.
[09:00] <wgrant> The repo with all 3 has a zlib error.
[09:00] <vila> yeah, but no indication of which file
[09:00] <wgrant> But all three trees build.
[09:00] <vila> note that (as mentioned earlier) zlib error strongly hint corruption
[09:00] <wgrant> Oh yes.
[09:00] <vila> but I've never ever heard about corruption on lp repos :-/
[09:01] <vila> by corruption I mean: hardware failure, crash, nothing inside bzr itself
[09:01] <wgrant> Well
[09:01] <vila> main is not stacked
[09:01] <wgrant> If it was not using normal smartserver ops it could reasonably happen.
[09:01] <vila> sprint4 is stacked on trunk
[09:02] <vila> wgrant: what do you mean ?
[09:03] <wgrant> vila: "reasonably" meaning a client-side RAM issue or similar.
[09:06] <vila> wgrant: hmm, you mean, RAM issue locally when creating the pack file which is then uploaded ?
[09:06] <wgrant> vila: Right, something like that seems most likely to me.
[09:07] <vila> never heard about such a scenario, not sure we have additional checks for that nor when the md5 is processed though
[09:07] <wgrant> Given that none of LP, bzr or SSH are known for corrupting things.
[09:07] <vila> oh right, yeah, when you've ruled out the unlikely...
[09:08] <vila> still, it's weird we have the corruption in both main and trunk/sprint4 (or even in the 3 of them) but still manage to branch them all
[09:09] <wgrant> main and trunk seem to be corrupted in different ways.
[09:10] <wgrant> vila: Huh, now this is interesting.
[09:10] <wgrant> vila: Can branch main, and can branch trunk into that.
[09:10] <wgrant> But can't branch trunk *out* of that.
[09:10] <vila> urgh
[09:11] <wgrant> So it can build the trunk tree in the repo, but you can't branch it from that repo to elsewhere... wtf
[09:11] <vila> I just did
[09:11] <vila> bzr branch trunk out-of-trunk
[09:11] <vila> Branched 3401 revisions.
[09:22] <wgrant> vila: That looks like you're branching within the repo.
[09:23] <vila> wgrant: yes. That's not what you meant by 'out of that' ?
[09:23] <wgrant> vila: I meant branching from inside the repo to out of it.
[09:23] <vila> ha
[09:24] <vila> yeah, reproduced, ouch
[09:25] <wgrant> There's only 33 extra mainline revs in trunk
[09:37] <wgrant> Aha
[09:37] <wgrant> Salvaged.
[09:37] <wgrant> I have a clean standalone trunk branch.
[09:37] <wgrant> vila, jf_: ^^
[09:38] <jf_> wgrant,  great !
[09:38] <wgrant> Let me just run a few checks and then we can work on fixing the one on LP.
[09:38] <jf_> wgrant, thanks
[09:39] <wgrant> vila: How's your link to LP?
[09:39] <wgrant> vila: I don't really want to push up 67MB over 512kbps if I can help it.
[09:40] <vila> well done, I have a list of corrupted entries here: http://paste.ubuntu.com/1014470/
[09:40] <mgz> wgrant: do the ops over ssh to a machine in london?
[09:40] <wgrant> mgz: Hopefully nowhere in London has my SSH key, but maybe.
[09:41] <wgrant> Anyway, the key is to use lp:openobject-server as the base.
[09:41] <wgrant> Seed the repo with that, then you can branch lp:unifield-server fine.
[09:41] <wgrant> So we should probably delete lp:unifield-server's .bzr, then push up a clean copy from the seeded repo.
[09:45]  * vila blinks
[09:46] <vila> wgrant: I don't enough about lp internals to do that kind of stuff (which I agree is the right thing to do though, just checking I find no corruption in lp:openobject-server)
[09:46] <wgrant> checked repository <bzrlib.transport.local.LocalTransport url=file:///home/wgrant/really/trunk/> format RepositoryFormat2a()                                                                                                                                                                                       6611 revisions 2418 file-ids
[09:47] <wgrant> I got a bit uncreative with branch names by the 20th try
[09:47] <wgrant> really/trunk is a copy of lp:unifield-server
[09:48] <wgrant> vila: The broken revision is a massive merge of lp:openobject-server, so I tried seeding with that, and it all seems happy.
[09:49] <vila> ok, reproduced locally, in a shared repo, branch lp:openobject-server then lp:unifield-server(main,trunk,sprint4) run repodetails there, no corruption
[09:49] <wgrant> Yep
[09:51] <mgz> I've got a machine in the data center with that on it.
[09:51] <mgz> tell me where to poke things and I will.
[09:52] <wgrant> mgz: Push it up to like lp:~mgz/+junk/unifield-server or so
[09:52] <mgz> sure
[09:52] <vila> mgz: beat me to it :)
[09:54] <mgz> is done.
[09:54] <wgrant> We can then get either jf_ or an admin to branch mgz's copy locally, rename lp:unifield-server's .bzr to something else, then "bzr push --use-existing-dir lp:unifield-server".
[09:55] <mgz> main is a strict subset, right?
[09:55] <vila> no
[09:55] <wgrant> No
[09:55] <wgrant> 5 extra revs in main
[09:55] <vila> but the repo should contains everything
[09:55] <mgz> sprint4 and trunk are the same thing
[09:55] <vila> yes
[09:55] <wgrant> Ah, indeed, sprint4 is identical.
[09:56] <vila> meh, subset != superset, but anyway, they diverge
[09:56] <mgz> if main has 5 revs not present, what I just pushed will not be enough
[09:56] <wgrant> mgz: What did you push?
[09:57] <vila> mgz: push trunk then push --overwrite main
[09:57] <wgrant> I doubt any revs unique to main are corrupted
[09:57] <vila> so the repo will get them all
[09:57] <wgrant> But it's possible, I guess.
[09:57] <mgz> yeah, I'll cheat and get those revs in as well
[09:57] <wgrant> jf_: Still around?
[09:57] <jf_> wgrant, yes,  should I do something ?
[09:59] <wgrant> jf_: lp:~gz/+junk/unifield-server is a fixed copy of lp:unifield-server
[09:59] <wgrant> jf_: Now we just need to replace lp:unifield-server with it.
[09:59] <jf_> wgrant, ok
[09:59] <vila> argh ! I meet melmoth at 12:00 ! Should run
[10:01] <jf_> wgrant, who is "we" in "we just need" ?
[10:01] <wgrant> jf_: you or a Launchpad sysadmin. So ideally you :)
[10:02] <jf_> wgrant, ok so I need to: bzr branch  lp:~gz/+junk/unifield-server in a standalone repo ?
[10:02] <wgrant> jf_: Right, eg. in /tmp somewhere.
[10:02] <wgrant> It must not be in a shared repo which has been anywhere near the broken branch.
[10:03] <jf_> ok should I make a backup of branches in lp:unifield-server ?
[10:03] <wgrant> jf_: You'll also need lp:hitchhiker. I'll tell you how to use hitchhiker to remove the broken branch content from Launchpad.
[10:03] <wgrant> jf_: Might be a good idea, but it might be difficult because of the corruption.
[10:04] <jf_> ok
[10:05] <wgrant> Once you're ready, in your local branch of hitchhiker, run './hitchhiker lp:unifield-server'. Once that's connected you should say 'rename .bzr backup.bzr'.
[10:06] <wgrant> Then you can switch over to your copy of the fixed branch, then 'bzr push --use-existing-dir lp:unifield-server'
[10:06] <wgrant> And that should fix it.
[10:10] <jf_> wgrant, I'm pushing, it should take time ....
[10:11] <wgrant> jf_: Yeah, you'll have to push the full 67MB or so, since it's the trunk branch that you're recovering :(
[10:15] <jf_> wgrant, done
[10:16]  * wgrant tries.
[10:16] <wgrant> Branched 3401 revision(s).
[10:16] <wgrant> Branched 3401 revision(s).
[10:17] <wgrant> jf_: That's fixed it!
[10:17] <jf_> wgrant, ok many thanks, should I remove all my corrupted shared repo ?
[10:18] <wgrant> jf_: Yeah, you and anyone else working on the project will probably need to recreate any shared repos from scratch.
[10:18] <wgrant> It won't re-corrupt the branch on LP, but it will still be corrupt locally.
[10:19] <jf_> wgrant, ok perfect !
[10:19] <jf_> wgrant, many many thanks
[10:19] <wgrant> jf_: np, glad we could sort it out.
[11:18] <czajkowski> jam: jelmer vila mgz can someone look into this please.  https://bugs.launchpad.net/launchpad/+bug/1006323
[11:18] <ubot5> Ubuntu bug 1006323 in Launchpad itself "ppa statistics broken since approx. 2012-05-21" [Undecided,New]
[11:19]  * mgz has a look
[11:25] <vila> wgrant: thanks (I should have thought about hitchhiker)
[13:50] <mdeslaur> I'm sure getting a lot of "Processing Failed" errors when trying to download stuff from launchpad bugs and PPAs...is this a current known issue?
[14:21] <james_w> mdeslaur, bug 1000805 probably
[14:21] <ubot5> Launchpad bug 1000805 in Launchpad itself "server errors accessing attachments of private bug reports" [Critical,Triaged] https://launchpad.net/bugs/1000805
[14:22] <mdeslaur> james_w: looks like it, thanks
=== mbarnett` is now known as mbarnett
[15:31] <colon_D> still having a permission denied error when uploading my ppa.  anyone around to check what's wrong?
[15:33] <czajkowski> colon_D: what issues are you seeing ?
[15:33] <colon_D> czajkowski: I get this: Rejected:  Unhandled exception processing upload: [Errno 13] Permission denied: '/tmp/tmpbAwawq/trafficserver-3.1.3/debian/copyright'
[15:34] <czajkowski> colon_D: what lp id and what ppa ?
[15:35] <colon_D> czajkowski: i'm uploading here: https://launchpad.net/~wolfnet/+archive/trafficserver
[15:36] <czajkowski> colon_D: ok let me see if I cna get someone to help
[15:37] <colon_D> czajkowski: thanks :-)
[15:41] <czajkowski> jelmer: if you can would you mind helping colon_D please
[15:42] <dobey> colon_D: is the permissions of that file mode 600 or something?
[15:44] <colon_D> dobey: 644 root:root for everything when I package it up
[15:44] <colon_D> kind of weird it stops on copyright as there are other files like control compat changelog above it with same permissions
[15:50] <dobey> is the debian.tar.gz for that package accessible somewhere?
[15:53] <colon_D> debuild seemed to make one trafficserver_3.1.3-0ubuntu1~precise.debian.tar.gz
[15:56] <jelmer> hi colon_D
[15:56] <colon_D> hi jelmer :]
[15:57] <dobey> colon_D: accessible on the internet by persons other than yourself, in order to look at it directly
[15:57] <dobey> :)
[15:57] <dobey> anyway
[15:57] <dobey> maybe jelmer will help you
[16:07] <jelmer> colon_D: did you see dobey's last question?
[16:08] <colon_D> jelmer: yes I'm not sure what that means
[16:09] <jelmer> colon_D: can you put the .debian.tar.gz file up somewhere?
[16:10] <colon_D> jelmer: http://dl.dropbox.com/u/85144/trafficserver_3.1.3-0ubuntu1%7Eprecise.debian.tar.gz
[16:11] <jelmer> colon_D: the debian/ directory does not have any x bits set
[16:12] <jelmer> so it's imposible for anybody to list its contents
[16:12] <colon_D> jelmer: ah! you are right
[16:13] <colon_D> thanks a lot!  I will fix and resubmit
[16:13] <jelmer> colon_D: great :)
[16:23] <colon_D> Awesome!  It was accepted.  Thanks everyone for the help.  User error in the end x_x
=== samkottler is now known as samkottler|afk
=== samkottler|afk is now known as samkottler
=== jacob_ is now known as jacob
=== Pici is now known as Guest55530
=== Pici` is now known as Pici
=== samkottl_ is now known as samkottler
=== yofel_ is now known as yofel
[23:57] <broder> how does registering a private project work? are proprietary projects private by default?