[03:47] <andol> Can't seem to push code to staging, due to ssh errors
[03:47] <andol> "ssh: connect to host bazaar.staging.launchpad.net port 22: Connection refused"
[03:47] <lifeless> there isn't a staging codehost as far as I know. IMBW
[03:47] <lifeless> mwhudson: thumper; ^
[03:48] <thumper> there should be
[03:49] <thumper> although staging codehosting is a massive pile of ghostly images
[03:49] <thumper> most branches aren't really there
[03:49] <thumper> although pushing a new branch should work
[03:49] <thumper> as long as there isn't a development focus branch
[03:49] <thumper> otherwise it'll try to stack on something non-existant
[03:51] <andol> thumper: Ok, preparing a Launchpad workshop, where I will be using a bogus project and a few bogus teams. Figured I'd use staging, to keep the real Launchpad "clean".
[03:51] <thumper> andol: nice
[03:51] <thumper> andol: you realise that the staging db gets blown away periodically?
[03:51] <thumper> when is the workshop?
[03:52] <andol> thumper: tonight, 17:30-20 CEST
[03:52] <andol> (UTC+2)
[03:52] <thumper> spm: when is the next staging db replacement?
[03:53] <andol> getting the results blown away is just fine, as long as it doesn't happen in the middle of the workshop :)
[03:53] <thumper> spm: and codehosting on staging appears down
[03:54] <gjditchf> I tried uploading to my ppa, and got this in my e-mail:
[03:54] <gjditchf> Rejected:
[03:54] <gjditchf> Further error processing not possible because of a critical previous error.
[03:54] <gjditchf> Terse.  Where do I look to figure out what went wrong?
[03:54] <spm> thumper: no idea. it's been breaking a lot lately; haven't had a chance to followup on that today; staging codehosting has been breaking the past week - same
[03:54] <thumper> spm: hmm...
[03:55] <andol> thumper, spm: In that case, perhaps I don't want to use staging for tonights workshop? How untidy is it if a register a couple of projects and teams just to today, and removes them afterwards?
[03:56] <thumper> andol: teams normally live forever :)
[03:57] <thumper> andol: do you not have a pet project to use?
[03:58] <persia> SHould https://api.launchpad.net/ return something useful?  I had expected documentation.
[03:58] <spm> thumper: actually - teams don't; projects do. ex-teams get merged to oblivion.
[03:59] <thumper> persia: try http://dev.launchpad.net/API
[03:59] <spm> persia: or even https://api.launchpad.net/--help (boom tish)
[03:59] <persia> That redirected me to https://help.launchpad.net/API which redirected me to http://edge.launchpad.net/+apidoc
[03:59] <persia> --help!
[04:00] <andol> thumper: Well, will be showing of a few well chosens projects, Likewise the main plan was to start a new project, with bug tracking, translation, etc.
[04:00] <lifeless> thumper: staging oopses
[04:00] <persia> Awww... :(
[04:00] <lifeless> thumper: where does one find them ?
[04:00] <lifeless> thumper: https://staging.launchpad.net/~mbp/bzr/trivial/+merge/21998 I did make it go boom
[04:00] <thumper> lifeless: devpad
[04:00] <lifeless> oh
[04:00] <lifeless> actually looks like staging librarian is down?
[04:01] <spm> thumper: https://pastebin.canonical.com/30406/ istr this was something we had an evi lhacky fix for last week....
[04:01] <thumper> spm: oh FFS, that's me
[04:01] <thumper> spm: sorry
[04:01] <lifeless> thumper: https://code.staging.launchpad.net/~bzr-pqm/bzr/bzr.dev/+activereviews seems to handle a 'queued' proposal ok
[04:02] <lifeless> thumper: though it doesn't show as 'approved ready to land'
[04:02] <thumper> lifeless: that is because they aren't approved ;-)
[04:02] <lifeless> thumper: would you like bugs?
[04:02] <thumper> lifeless: they are queued
[04:02] <lifeless> thumper: they show as 'other reviews you could do'
[04:02] <thumper> really?
[04:02] <thumper> if it really is, it is a bug
[04:02] <lifeless> https://code.staging.launchpad.net/~bzr-pqm/bzr/bzr.dev/+activereviews
[04:03] <lifeless> tell me which one is 'queued' on that page
[04:03] <spm> thumper: ah yes. here's the ahck we used: https://pastebin.canonical.com/30343/ and staging codehost should be live again.
[04:03] <thumper> lifeless: queued proposals would not show on +activereviews
[04:03] <lifeless> spm: I can has staging librarian ?
[04:03] <lifeless> thumper: it does
[04:03] <spm> lifeless: that's underway as you request :-)
[04:04] <lifeless> spm: thanks!
[04:04] <thumper> lifeless: which one?
[04:04] <lifeless> thumper: its ~mbp/trivial
[04:05] <thumper> except that blows up
[04:05] <lifeless> thumper: librarian causes that
[04:05] <thumper> yeah, that's bad
[04:05] <lifeless> thumper: I'm talking about it's rendering on +activereviews for now.
[04:05] <spm> lifeless: the staging librarian is working. ???
[04:05] <lifeless> spm: I can't get any MP on staging
[04:05] <lifeless> spm https://code.staging.launchpad.net/~ian-clatworthy/bzr/py2exe-534548/+merge/22193
[04:05] <lifeless>     *
[04:05] <spm> rephrase. it's up and responding as expected. working is a diff beastie....
[04:05] <lifeless>     * Module lp.code.model.diff, line 73, in text
[04:05] <lifeless>       self.diff_text.open()
[04:05] <lifeless>     * Module canonical.launchpad.database.librarian, line 108, in open
[04:05] <lifeless>       self._datafile = self.client.getFileByAlias(self.id, timeout)
[04:06] <lifeless>     * Module canonical.librarian.client, line 348, in getFileByAlias
[04:06] <lifeless>       raise LookupError, aliasID
[04:06] <lifeless> LookupError: 42032767<br />
[04:06] <spm> cool
[04:07] <lifeless> just checked an LP MP on staging; same symptoms
[04:08] <spm> wag here - the staging db is *old* - if this is stuff that needs a new replica, is possible weirdness is happening???
[04:08] <lifeless> thumper: ^
[04:09] <spm> I'm guessing based on it being a 'lookup' error....
[04:10] <thumper> lifeless: same error for a new proposal?
[04:10] <thumper> lifeless: link plz
[04:10] <lifeless> https://code.staging.launchpad.net/~bjornt/launchpad/form-overlay-render-by-default/+merge/10249
[04:10] <lifeless> I'll try a new proposal, sec
[04:11] <lifeless> thumper: +activereviews status
[04:12] <lifeless> https://bugs.edge.launchpad.net/launchpad-code/+bug/561157
[04:12] <ubottu> Launchpad bug 561157 in launchpad-code "'queued' merge proposals are unclear on +activereviews" [Undecided,New]
[04:12] <lifeless> thumper: ok, https://code.staging.launchpad.net/~vila/bzr/conflict-manager/+merge/22274 is new and works
[04:13] <lifeless> thumper: queuing up https://code.staging.launchpad.net/~vila/bzr/conflict-manager/+merge/22274
[04:14] <lifeless> spm: thanks, was old data yes. new mps work ok
[04:14] <lifeless> thumper: https://code.staging.launchpad.net/~vila/bzr/conflict-manager/+merge/22274 - shows 'queued' ok
[04:14] <spm> lifeless: \o/   I'm mildly terrified that my wag was accurate. clearly i've been here too long. ;-)
[04:15] <thumper> lifeless: and isn't in bzr/+activereviews
[04:15] <thumper> hmm
[04:15] <thumper> lifeless: is in the branch one though
[04:16] <lifeless> thumper: right
[04:37] <andol> Hmm, regarding the staging codehosting. Seems that I now can push, branch, etc fine using the bzr client. Yet when I try to view the changes on the web I just the the "Updating branch...", "availible in few minutes" etc even after having waiten quite a bit more than just a few minutes.
[04:44] <lifeless> spm: ^
[05:25] <thumper> andol: scripts use different configs, and run at much slower intervals than production
[05:27] <andol> thumper: interval config on staging? (still waiting for update)
[05:27] <thumper> andol: I think scanning happens every 10 minutes
[05:28] <andol> Well, since I did the push about an hour ago, and still don't see the result...
[05:35] <thumper> andol: scanner is probably broken
[05:35] <thumper> spm: ping
[05:35] <spm> thumper: yo
[05:35] <thumper> can you sync the staging logs please
[05:36] <spm> thumper: done
[05:38] <thumper> ta
[05:43] <thumper> spm: same config fubar for asuka
[05:44] <spm> woo
[05:44] <spm> one sec.
[05:44] <thumper> spm: FWIW I'm landing a db-devel branch that un-stuffs it
[05:44] <spm> sweet
[05:44] <thumper> spm: reverting a previous delete of mine
[05:44] <thumper> mwhudson: want to review a trival patch?
[05:48] <poolie> what browsers are supported for launchpad these days?
[05:48] <mwhudson> thumper: sure
[05:48] <poolie> does it have to be a modern ajaxy one, or do we still support text mode things as a fallback?
[05:49] <persia> I use w3m regularly to work around misfeatures in the AJAX UI
[05:49] <wgrant> I believe all AJAX is meant to have fallback.
[05:49] <wgrant> Though for some things like bug subscriber lists that seems to have been forgotten.
[05:50] <persia> You can still get it, but it requires significant URL hacking.
[05:50] <spm> thumper: that's applied
[05:50] <thumper> spm: ta
=== thekorn_ is now known as thekorn
[07:06] <dickelbeck> Hi, I need help please.
[07:07] <dickelbeck> bzr: ERROR: Cannot lock LockDir(lp-67241552:///~kicad-testing-committers/kicad/testing/.bzr/branchlock): Transport operation not possible: readonly transport
[07:07] <dickelbeck> I get the above error trying to do a bzr commit
[07:08] <lifeless> you've done a checkout without being logged in, or of a branch you cannot commit to.
[07:08] <lifeless> either change to a local branch, or switch to a branch you can commit to.
[07:08] <spiv> It's an import branch.
[07:09] <spiv> (although the import is suspended, but that doesn't affect permissions)
[07:09] <dickelbeck> we asked that it be converted to a non-import branch
[07:09] <spiv> Hmm, it appears that hasn't happened yet.
[07:09] <dickelbeck> https://answers.edge.launchpad.net/launchpad-code/+question/106929
[07:10] <dickelbeck> perhaps I did not state the request appropriately enough.
[07:10] <spiv> Yeah, I think there was probably some confusion.
[07:11] <spiv> For a Launchpad dev, asking for an import to "stop" doesn't mean converting the branch from an import to being hosted natively on LP
[07:11] <spiv> It means asking the importer to stop updating it, but leave the branch otherwise unchanged.
[07:12] <dickelbeck> now that you know what I need, how can I get it done?
[07:12] <spiv> So, ask another question (or reopen that one?) asking for it to be converted to a hosted branch, so that you can commit to it directly.
[07:12] <mwhudson> by far the easiest way to achieve that is just to push up a new hosted branch
[07:12] <spiv> mwhudson: gosh it would be nice if this stuff was more self-service *hint-hint* ;)
[07:14] <dickelbeck> There are quite a few developers affected by this.  We have some faqs that name the branch in help text.
[07:15] <dickelbeck> If we push a new branch, can I somehow preserve the documented name?
[07:15] <wgrant> You can rename the old one and push a new one in its place.
[07:15] <mwhudson> dickelbeck: the import branch can be renamed out of the way, or even deleted
[07:17] <dickelbeck> so first rename lp:kicad to notused, then push to lp:kicad from the local up to date branch?
[07:18] <mwhudson> dickelbeck: yes, although if you just want "lp:kicad" to keep working, that's easier
[07:19] <dickelbeck> what is easier than what? sorry.
[07:19] <mwhudson> dickelbeck: it's easy to change which branch "lp:kicad" refers to
[07:19] <mwhudson> so if your faq just says "lp:kicad" then this is all easy
[07:20] <mwhudson> dickelbeck: if the faq says "~kicad-testing-committers/kicad/testing", then that's not so easy
[07:20] <mwhudson> (although it's not very hard either)
[07:21] <dickelbeck> Ok, so lp:kicad is like a symlink, and if I really need "testing" then I have to go deeper with the renaming.
[07:25] <mwhudson> dickelbeck: right
[07:28] <dickelbeck> mwhudson:
[07:28] <dickelbeck> bzr push lp:~kicad-testing-committers/kicad/new-testing
[07:28] <dickelbeck> Using default stacking branch /~kicad-testing-committers/kicad/testing at lp-67241552:///~kicad-testing-committers/kicad
[07:28] <dickelbeck> Created new stacked branch referring to /~kicad-testing-committers/kicad/testing.
[07:29] <dickelbeck> wondering now if because it is stacked, can I delete the original?
[07:37] <mwhudson> dickelbeck: oh argh
[07:38] <mwhudson> dickelbeck: run "bzr reconfigure --unstacked lp:~kicad-testing-committers/kicad/new-testing"
[07:38] <mwhudson> (if you have a new enough bzr)
[07:40] <mwhudson> dickelbeck: if that doesn't work, stick this http://pastebin.ubuntu.com/412953/ in a file and run "python file-name lp:~kicad-testing-committers/kicad/new-testing"
[07:40] <mwhudson> dickelbeck: or i can do this for you
[07:41] <dickelbeck> the reconfigure seems to be working, I have Karmic.
[07:43] <mwhudson> ok cool
[07:45] <dickelbeck> mwhudson: I have 2 other branches that fit the same problem.  Solve the other 2 the same way?
[07:45] <mwhudson> dickelbeck: yeah
[07:47] <dickelbeck> too bad that the push does not have an --unstacked option.
[07:49] <dickelbeck> I have bzr version 2.1.1
=== henninge changed the topic of #launchpad to: http://launchpad.net/ | Read https://help.launchpad.net/ for help | Help contact: henninge | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/
[07:51] <mwhudson> dickelbeck: i think 2.2 will have that option
[07:51] <mwhudson> hm, maybe i imagined that
[07:52] <dickelbeck> does 2.2 exist already?
[07:53] <dickelbeck> bzr 2.1.1 has an option --stacked for the push command, suggesting its absence would mean non-stacked.  I think this is a bug frankly.
[07:55] <lifeless> dickelbeck: there is a bug open for this
[07:56] <lifeless> dickelbeck: it is a bug that you can't manually force it off; however the default is correct - follow server policy with no policy meaning non-stacked.
[07:58] <dickelbeck> bzr reconfigure --unstacked lp:~kicad-testing-committers/kicad/new-testing
[07:58] <dickelbeck> bzr+ssh://bazaar.launchpad.net/~kicad-testing-committers/kicad/new-testing/ is now not stacked
[07:58] <dickelbeck> bzr: ERROR: Lock not held: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~kicad-testing-committers/kicad/new-testing/.bzr/)
[07:59] <dickelbeck> Can you comment on the the last line of my output?  I find this ERROR alarming, did the unstacking actually succeed?
[08:05] <mdke> jelmer / mwhudson - ~vcs-imports/gnome-user-docs/master is still failing. Should I file a bug on launchpad or bzr-git?
[08:05] <mwhudson> mdke: i'm pretty sure it's fixed in bzr-git trunk
[08:05] <mwhudson> lemme try it on staging
[08:07] <mdke> mwhudson: thank
[08:07] <mdke> +s
[08:07] <mwhudson> mdke: keep half an eye on https://code.staging.launchpad.net/~vcs-imports/gnome-user-docs/master
[08:09] <mdke> will do
[08:11] <dickelbeck> mwhudson: the error message at the end of the reconfigure is a deal breaker for me.  I deleted new-testing and reopened the question.  It is bedtime here.
[08:12] <dickelbeck> mwhudson: thanks for your help.  I think bzr let us down here, I hope it is not a sign of things to come.
[08:13] <mwhudson> dickelbeck: it is dinner time for me, hopefully tomorrow will work out better
[08:17] <mdke> mwhudson: the import on staging seems to have worked. So do I just wait for the changes to filter through to regular LP?
[08:19] <mwhudson> mdke: i want to get these changes onto regular LP sooner than that for other reasons, so hopefully not that long
[08:20] <mdke> mwhudson: awesome, thanks a lot. if you remember, can you start the import again once that happens, or let me know so I can start it manually/
[08:21] <mwhudson> mdke: i'll try really hard to remember
[08:21] <mdke> mwhudson: :) have a good evening
=== jtv is now known as jtv-eat
[08:48] <Laibsch> I thought that some kind of cron job was regularly pulling in the latest debian packages in to bzr?
[08:50] <Laibsch> Ah, I see
[08:50] <Laibsch> It's pulling from testing, not from unstable, right?
[08:52] <geser> both, there should be a bzr import of the testing and unstable version (if it did fail)
[08:57] <Laibsch> I didn't see an unstable branch for pidgin, but indeed it's there, just a little hidden
=== jtv-eat is now known as jtv
=== henninge_ is now known as henninge
[10:23] <andol> thumper: Seems like scanner in staging is working again. Many thanks to you, or whoever fixed it.
[10:24] <thumper> andol: spm mainly, although i submitted a patch that fixes the break I caused :)
[10:25] <andol> thumper: seems fair somehow :)
[10:25] <thumper> :)
[10:25] <andol> spm: Thanks to you too then
=== stub1 is now known as stub
=== mrevell is now known as mrevell-lunch
=== Ursinha_ is now known as Ursinha
=== matsubara-afk is now known as matsubara
=== mrevell-lunch is now known as mrevell
[13:37] <jml> how can I upgrade lp:zope.testing to 2a format?
[13:41] <captainkernel> is this the right channel for discussing launchpad bugs/issues?
[13:42] <jml> pretty much
[13:42] <jml> there's also #launchpad-dev, which is oriented toward actually _fixing_ those bugs and issues.
[13:46] <captainkernel> good well in that case I have the following issue: I had created an account but then decided to start afresh by 'deactivating the account' and recreating one with the same email address. When I sign in I know get Oops messages such as (Error ID: OOPS-1563D1311). Any ideas?
[13:46] <ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1563D1311
[13:47] <captainkernel> how do I view this lp-oops info? It is asking for a usename and pw.
[13:48] <pabs3> how does one link an Ubuntu bug to a bug at sourceforge.net?
[13:53] <maxb> captainkernel: OOPSes are only viewable by Canonical employees (which I am not) in case they contain revealing private information. The fact that you've encountered one like that suggests a bug in Launchpad.
[13:53] <maxb> henninge: Can you advise captainkernel ?
[13:55] <andol> pabs3: Well, assuming that upstream uses SF for bug tracking the first step is usually to click on "Also affects project". What happens next depends on whatever LP already knows about that upstream in question or not.
[13:58] <pabs3> andol: lp doesn't seem to know anything about it
[14:13] <henninge> captainkernel: I'll be with you in a minute, need to reboot first ...
[15:00] <henninge> captainkernel: that looks like a bug, yes
[15:01] <henninge> captainkernel: looks like this
[15:01] <henninge> http://paste.ubuntu.com/413141/
[15:02] <henninge> captainkernel: so I suspect it has to do with you re-using your address on a new account
[15:03] <henninge> captainkernel: can you please file a bug referencing the OOPS id here:
[15:03] <henninge> https://bugs.launchpad.net/launchpad-web/+filebug
[15:03] <wgrant> More likely that the OpenID login code is reactivation-naïve.
[15:04] <henninge> yes, something like that
=== barry` is now known as barry_
[15:05] <henninge> captainkernel: argh, I just realized you cannot file bugs .. ;-)
[15:06] <henninge> captainkernel: please tell me what the old account name was, so I can add it to the bug report.
[15:06] <henninge> captainkernel: actually, both names
[15:07] <henninge> captainkernel: as a work around I suggest you create an account with a different email address. They can be merged later when the bug is fixed.
=== barry_ is now known as barry
[15:08] <wgrant> Um... I wouldn't trust merging to work terribly well at this point.
[15:10] <henninge> ok, renaming should work, though ...
[15:52] <deryck> jcastro, ping
[15:57] <jcastro> deryck: pong
[16:00] <captainkernel> henninge: ok thanks for your help I will create a new account with a new email address and then perhaps at some later stage merge.
[16:02] <henninge> captainkernel: will you file the bug from that account or do you want me to do it? Pleaes remember to include the account names.
[16:03] <captainkernel> I will chase it up. I am currently discussing the issue with one of the caninical guys via email.
[16:10]  * henninge is one of the canonical guys ... ;-)
[16:12] <captainkernel> Oops sorry.
=== deryck is now known as deryck[lunch]
[16:59] <tgm4883> I have unchecked the "People can ask questions in Launchpad Answers" but users are still able to ask questions in there. (I unchecked this awhile ago). Is there another place I need to look at? https://answers.edge.launchpad.net/mythbuntu
[17:00] <m_anish> Hi, I can't seem to login to my launchpad account... Here's what happens.. I am able to login to the initial login page at launchpad.net/+login then a page asks me whether to "Yes, sign me in" or "cancel". I press the former and nothing seems to happen after that! I have tried this multiple times. I am using the default firefox preinstalled on ubuntu-lucid-beta2-amd64, any ideas?
[17:10] <nigelb> m_anish, can try with another browser? perhaps epiphany-browser? if it works let me know
[17:13] <m_anish> nigelb, ok
[17:13] <nigelb> m_anish, this could be a potential problem in firefox
[17:14] <m_anish> nigelb, hmm
=== matsubara is now known as matsubara-lunch
[17:33] <askhl> Hi.  Is there any guarantee that a sufficiently early translation import will be processed before the lucid deadline?
[17:35] <dpm> askhl, if you are talking about an import of a manually uploaded PO file, there is no guarantee. It can take just a few hours, but it depends on the load and the number of other translations being imported. To be absolutely certain, I'd recommend using the web interface for translating
[17:36] <askhl> dpm, we can't manage that at all unfortunately
[17:36] <askhl> we don't have a system for designating that things should be proofread in the web interface, so our procedure involves exports and imports of po-files
[17:37] <askhl> I suppose I can write an urgent email prompting everything to be imported, and then say that the rest should be done in Rosetta
[17:37] <askhl> but it'll be rather chaotic
[17:37] <dpm> askhl, why don't you use a wiki? You must have a system already if you are doing it with po files, why not use the same system for online translation?
[17:39] <dpm> askhl, we use the wiki for our Catalan translations -> https://wiki.ubuntu.com/UbuntuCatalanTranslators/Llistat, and this method works for both offline (PO files sent to our list) and online translations
[17:39] <askhl> dpm, we send special po-diffs of po-files for proofreading on a mailing list, comments are written below each of the entries.  We have a multitude of scripts working on po-files, so we really prefer just getting the po-files
[17:39] <askhl> But anyway I'll try to make things happen in Rosetta
[17:41] <dpm> askhl, note that I'm not trying to force a workflow upon you (the current is fine, if it works for you!), just suggesting other alternatives to help if you've got a big backlog before deadline.
[17:41] <askhl> dpm, that's all right, just trying to do the best thing :)
[17:41] <askhl> One moment....
[17:42] <askhl> Okay, one *really* important question.
[17:43] <askhl> Why is LanguagePackTranslationDeadline one week *after* the "final" export of strings from LP?
[17:43] <askhl> Surely the "final" string export must be the final time at which translations can be made at all.  Or not?
[17:44] <dpm> askhl, shall we discuss this on #ubuntu-translators? I think it might be more appropriate there, as other Ubuntu translators might be interested or might be able to add more
[17:44] <askhl> dpm, oh, right
[17:58] <m_anish> nigelb, doesn't seem to work with epiphany-browser as well, same thing happens... Is there some way I could delete my account and recreate it... somehow via email?
=== matsubara-lunch is now known as matsubara
[18:48] <TresEquis> any known issues with mirrors of SVN repos into code.launchpad.net?  I have a branch marked as failed, but can see why, or where to have it try again
[18:49] <TresEquis> https://code.launchpad.net/~tseaver/karl3/trunk
[18:49] <TresEquis> which imports from http://osi.agendaless.com/bfgsvn/karl/trunk/
[18:49] <huats> does anyone can explain me a bit the private stuffs on LP bugs ?
[18:50] <huats> I am askig that since I am part of the MOTU mentoring reception team and we are wondering to use LP bugs to store informations o each applications... but we would like to have private bugs with only a team and theapplicant who can see it
[19:13] <maxb> TresEquis: You should look at the various "see the log" links for the failed imports
[19:14] <maxb> These show that something is exploding fairly deep in the import code.
[19:14] <TresEquis> yup
[19:14] <TresEquis> bzr or bzr-svn bug, i think
[19:17] <TresEquis> https://bugs.launchpad.net/bzr-svn/+bug/561695
[19:17] <ubottu> Launchpad bug 561695 in bzr-svn "svn-import crash inconsistent details in skipped record" [Undecided,New]
[19:22] <maxb> TresEquis: Why did you title that "inconsistent details in skipped record" ?
[19:24] <TresEquis> maxb:, that was what I was searching for:  there are warnings about 'incosistent details' just before the crash
[19:25] <TresEquis> the crash assertion is pretty uninformative:  11576 != 11625, or some such
[19:25]  * maxb retitles: bug 561695
[19:25] <ubottu> Launchpad bug 561695 in bzr-svn "svn-import crash inconsistent details in skipped record" [Undecided,New] https://launchpad.net/bugs/561695
[19:25] <maxb> meh, ubottu caching
[19:26] <maxb> bug 561695?
[19:26] <TresEquis> a better title would probably be "failed svn import w/ 'inconsitent details' and tx window size assertion."
[19:26] <TresEquis> that's my bug
=== mordred_ is now known as mtaylor
[19:27] <maxb> I have often observed "inconsistent details in skipped record" in imports which are otherwise perfectly fine, so it's quite likely to be an irrelevant corollary to the actual problem
[19:28] <TresEquis> I'm retrying the import over SSH, just in case the problem is the CGI script serving SVN over HTTP
[19:29] <TresEquis> I had a similar problem with an svn -> bzr mirror the other day:  only solution was to blow the mirror away and re-import
[19:30] <TresEquis> hmm, running over SSH, I see the same "inconsistent details" spew, but then
[19:30] <TresEquis> bzr: ERROR: checksum mismatch: '14dc2c155184a11a643127d1065f6543' != 'db81c41de9b824074d3c842243f4194d' in karl/trunk:5140
=== matsubara is now known as matsubara-afk
[19:39] <TresEquis> maxb: any chance that scrubbing ~/.bazaar/svn-cache/ would help, do you think?
[19:39] <maxb> TresEquis: Given the weird error, I'd be inclined to run 'svnadmin verify' on the repository, if you have access
[19:43] <TresEquis> $ svnadmin verify -r 5140 bfgsvn
[19:43] <TresEquis> * Verified revision 5140.
[19:45] <TresEquis> I'm running across all 5176 revisions now
[19:47] <TresEquis> all 5176 txns verify
[19:51] <jelmer> TresEquis: this is a known bug in bzr-svn trunk, I'm working on it
[19:51] <TresEquis> jelmer: ok, cool
[19:51] <TresEquis> anything I can do to help on reproducing it?
[19:52] <TresEquis> My public SVN HTTP mirror triggers it nicely for me on Jaunty with the PPA bzr (2.2.1) and bzr-svn (1.0.2)
[19:53] <TresEquis> and I have verified that SVN at least thinks the repo is in good shape
=== jtv1 is now known as jtv-afk
=== EdwinGrubbs2 is now known as EdwinGrubbs
[22:37] <jjardon> sinzui, ping
[22:38] <sinzui> hi jjardon
[22:39] <sinzui> jjardon, I was just going to write to say I was mistaken in my assumption that you are the current maintainer of glade-3 in launchpad
[22:39] <jjardon> hey! I'm the person of the Glade/Glade3 issue . Thank you for you support!
[22:40] <sinzui> jjardon, ~vgeddes ha 0 karma. I think we should ask him to update the project or transfer maintainership to someone who can keep the information current
[22:40] <donri> Rosetta can be used "standalone" right?
[22:41] <donri> I mean, you don't have to use Bazaar for example?
[22:41] <jjardon> sinzui, vgeddes was a contributor upstream, but I don't see him for a long time
[22:42] <donri> I don't mind Bazaar myself, but http://lwn.net/Articles/325311/ calls Rosetta "tightly integrated with Launchpad". But my understanding is you can simply upload and download .po files?
[22:42] <jjardon> I only see one patch from him in 2007
[22:42] <sinzui> jjardon, Do you want me to ask an admin to make you the maintainer?
[22:43] <jjardon> sinzui, sure. I can update all the info then ;)
[22:44] <sinzui> I will update the request. Thanks for working to clean up the data
[22:44] <jjardon> I'll ask the upstream maintainer to check all the info too
[22:45] <jjardon> sinzui, Can you remove glade-2 as a part of https://edge.launchpad.net/gnome ?
[22:46] <Ddorda> hey, can anyone please help me here: https://answers.launchpad.net/launchpad-registry/+question/107009 ?
[22:46] <sinzui> jjardon, I can
[22:47] <jjardon> sinzui, Also, there are a lot of projects in https://edge.launchpad.net/gnome that aren't part of official GNOME release set, Is this intential?
[22:47] <sinzui> jjardon, I also requested that glade be set as an alias of glade-3 so that people always find the current project
[22:48] <jjardon> sinzui, great, how about the bugs? Should I move the current glade bug to glade-3?
[22:49] <sinzui> jjardon, project groups are half-baked. We let anyone say they are a part of GNOME. We think we should only permit the GNOME maintainer to select the sub projects. Regardless, there are hundreds or projects listed in GNOME's repo: http://git.gnome.org/browse/
[22:50] <jelmer> sinzui: you seem to be implying in your latest blogpost that all klingon translators on Launchpad are native speakers ;-)
[22:50] <sinzui> jelmer, I knew someone would bring that up.
[22:51] <jjardon> sinzui, yeah, but only some modules are part of GNOME releases, take a look here for a complete list (in "Release suite"): http://live.gnome.org/TwoPointThirtyone
[22:52] <Ddorda> can anyone help me out with a problem?
[22:52] <sinzui> jelmer, while I do not endorse Klingon, I see it has more translators than Esperanto. I withhold judgement if the Klingon Cult can become a living language. I am willing to offer them the US state of Montana
[22:52] <jjardon> But there is no problem if the group is for projects that run in the GNOME desktop
[22:53] <jelmer> sinzui: :-)
[22:55] <sinzui> jjardon, The GNOME project does not represent the release set. It represents the gnome's bugzilla and  git. I think project groups have some serious flaws. They are either an over-engineered tag, or an under-engineered model of a project constellation
[22:55] <sinzui> or is that term galaxy?
[22:56] <jjardon> sinzui, ah ok, thank you for the info
[22:59] <Ddorda> can anyone help me about my LoCo team, please? it quite important and won;t take more that few minutes
=== matsubara-afk is now known as matsubara