[17:09] <Konam> hi
[17:10] <Konam> I want to know where can I download the documentation for Hardy, I know where it is online but I like to keep the PDF
[17:14] <bcnaat> I believe that its still a work in progress, not even sure that its available in pdf format
[17:15] <Konam> bcnaat ok, but where is the page to get it for older versions (so I keep track when the Hardy version come out)
[17:15] <bcnaat> I'm searching now...
[17:16] <Konam> bcnaat me too
[17:18] <bcnaat> https://help.ubuntu.com/6.06/
[17:18] <bcnaat> looks like the pdf option stops at 6.10 unless its hiding somewhere *frown*
[17:20] <bcnaat> hardy was released 4/24/08, if that's what you're needing
[17:25] <dsas> Yeah we stopped producing PDFs when we changed the way we write help to be "topic based" rather than one big guide.
[17:26] <bcnaat> is there a way to download the whole docbook onto your system in case you don't have internet and need to find an answer?
[17:27] <dsas> bcnaat: It already is.
[17:27] <dsas> bcnaat: It's in System and then Help
[17:27] <bcnaat> duh on me *frown*
[17:27] <bcnaat> I stay connected all the time and tend to research online for answers
[17:28] <dsas> heh me too.
[17:28] <Konam> I think we all do
[17:29] <Konam> dsas so now the big guide is only on the desktop help but not in only in the ubuntu docs?
[17:30] <dsas> Konam: I'm not sure I understand your question. We don't produce a big guide as such any more. But all of the ubuntu desktop help we do produce is in the system docs and on help.ubuntu.com
[17:30] <bcnaat> Konam: yes, everything that you see on the site is actually included in your systems help files.
[17:31] <Konam> dsas the thing is that I'm looking for the PDF of the ubuntu-server, I don't have such a built in help on the server
[17:31] <bcnaat> dsas: when the help files are updated, they are included in updates through update manager, correct?
[17:34] <Konam> here is the online server guide: https://help.ubuntu.com/8.04/serverguide/C/index.html
[17:36] <dsas> bcnaat: yes
[17:36] <dsas> Konam: No such thing exists.
[17:36] <Konam> dsas since I will install the server on a vm I will be able to read the online doc but it will be good to have the PDF availabe
[17:36] <dsas> sorry, i'm on my way out. bye
[17:39] <bcnaat> Konam: maybe you could make your own? Here's a link to try http://wiki.docbook.org/topic/DocBookPublishingTools
[17:39] <DougieRichardson> konam: you could us dblatex from our xml's
[17:40] <Konam> bcnaat I thought about it but I need a lib to build it for me, you know, like use all the html links and build it, I don't know if that's possible or somethin of the sort
[17:40] <Konam> DougieRichardson I do it if you tell me how
[17:41] <DougieRichardson> ok, first install dblatex from the repos
[17:43] <DougieRichardson> then pull down the doc source from https://code.launchpad.net/~ubuntu-core-doc/
[17:43] <DougieRichardson> go to the server guide and dblatex filename.xml will create a pdf from the xml
[17:52] <bcnaat> how do you pull the doc source?
[17:52] <Konam> DougieRichardson dblatex filename.xml is the command I have to use? that simple?
[17:55] <DougieRichardson> konam: yes
[17:56] <DougieRichardson> bcnaat: you will need bzr installed
[17:56] <DougieRichardson> then follow the commands on https://code.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy
[17:56] <bcnaat> installed it, thanks.
[17:57] <DougieRichardson> i wont promise it'll be too pretty, lol
[17:57] <DougieRichardson> it took a fair bit of tweaking with the desktop training project, lol
[17:58] <Konam> DougieRichardson I'm already there, downloading dblatex, but I have to know if it is a heavy and prolonged process so I know if have to start in at night
[17:58] <DougieRichardson> it's 33 mb with all deps
[18:01] <bcnaat> dblatex didn't take long to download/install but the docs are taking a bit
[18:03] <DougieRichardson> that's bzr for you
[18:03] <Konam> DougieRichardson it won't be pretty in which sense? I thought that that was the way you built the latest PDF files
[18:03] <Konam> ?
[18:05] <DougieRichardson> dblatex is not as flexible with formatting as I would like it to be. It produces good pdf output though
[18:07] <bcnaat> that should be interesting. I'm still learning how to use wiki
[18:10] <DougieRichardson> i just tried the server guide and it generates an error - my bad
[18:10] <DougieRichardson> if you give me till tommorrow i'll sort it out and post a pdf of the current server guide on my webpage for you
[18:11] <DougieRichardson> it works fine with every other file in there as well!!
[18:17] <Konam> DougieRichardson ok, I would really appreciate that :)
[18:18] <DougieRichardson> ok, save you looking it up - http://blog.lynxworks.eu/
[18:22] <Konam> ok
[18:29] <DougieRichardson> nickellery: i was just about to email you!
[18:29] <nickellery> DougieRichardson: hi there
[18:30] <DougieRichardson> you know your tech patch for games.xml?
[18:31] <nickellery> yes
[18:33] <DougieRichardson> there was a spec last year to review games.xml completely
[18:33] <DougieRichardson> because it's essentially a big list of games
[18:34] <nickellery> so.. did I do a good or bad thing reviewing it?
[18:35] <DougieRichardson> no no its a good review
[18:35] <nickellery> thats good to hear
[18:35] <nickellery> any suggestions on what to review next?
[18:35] <DougieRichardson> just wondered if you felt like developing it a bit further
[18:36] <DougieRichardson> expanding the section on wine/cedega for example
[18:36] <nickellery> I'm not too experienced with cedega, but I have a little knowledge of WINE
[18:36] <nickellery> what needs to be expanded about it?
[18:38] <DougieRichardson> just whatever you think, from the perspective of someone migrating from windows - any ideas, discuss them with the mailing list
[18:39] <nickellery> alright... do you think that enough games have been mentioned?
[18:39] <nickellery> Perhaps that can be expanded too
[18:46] <DougieRichardson> whatever you feel might be an improvement. Nobody took this on as a task for 7.04
[18:46] <nickellery> Alright, I'll have a look and see what I can come up with
[18:48] <DougieRichardson> great
[18:52] <nickellery> how about provided info about all the games with a 4 or 5 star rating that haven't been mentioned yet?
[19:08] <DougieRichardson> nick: sounds like a good idea
[19:10] <nickellery> should i put together a summary of my ideas for the mailing list?
[19:18] <nickellery> Nevermind, I've already sent it out
[19:18] <nickellery> tell me what you think
[19:19] <DougieRichardson> ok
[20:13] <j1mc> is anyone around?
[20:20] <DougieRichardson> yes
[20:20] <j1mc> Hi DougieRichardson ... i've squished down the xubuntu-doc structure per mdke's suggestion, and everything is bombing out when i go to validate.
[20:21] <j1mc> i think it's in the XSL, but i don't really know much about xsl.
[20:21] <DougieRichardson> what's the first error from the validate
[20:21] <j1mc> DougieRichardson: good question.  there are so many errors, that i can't even scroll up to the first error to check it out.
[20:21] <DougieRichardson> lol
[20:22] <j1mc> and doing a pipe or grep on the validation output doesn't work.
[20:23] <DougieRichardson> try using the carat
[20:23] <j1mc> carat?  how so?
[20:23] <DougieRichardson> i.e. cat `validate.sh filename.sh`
[20:23] <j1mc> ok
[20:23] <DougieRichardson> i.e. cat `validate.sh filename.xml` rather
[20:23] <j1mc> right... brb
[20:24] <DougieRichardson> わたしわ
[20:24] <DougieRichardson> sorry
[20:24] <DougieRichardson> wrong screen
[20:34] <j1mc> DougieRichardson: hm, i'm trying this:  `./validate.sh ../index.xml` > ~/errors.txt
[20:34] <j1mc> but it is not working
[20:35] <j1mc> sorry... with "cat" at the front
[20:35] <DougieRichardson> ok well what's the earliest error you can see?
[20:36] <j1mc> Validating ../index.xml ...
[20:36] <j1mc> ../index.xml:5: warning: failed to load external entity "../../libs/global.ent"
[20:36] <j1mc> ah, i guess it is giving me the first error.
[20:37] <DougieRichardson> oh wait a minute - you can use the -o filename option to output to a file: try validate.sh -o errors filename.xml
[20:38] <DougieRichardson> yes that looks like a path error - are you checking the first file in the hierarchy?
[20:40] <j1mc> DougieRichardson: well, when i correct the path error to have the index.xml file correctly map to the global.ent file, that is when i get so many errors that i can't see all of them.
[20:41] <j1mc> (when i provide the correct path to all of my .ent files...)
[20:43] <DougieRichardson> send me your index.xml
[20:47] <j1mc> sent.
[20:48] <j1mc> xubuntu docs are a bit weird in that it's not really valid docbook.  we're set up to use xinclude to pull all of the various files together into one big megafile.
[20:49] <DougieRichardson> i see - give me a second. the kettle just pinged
[20:50] <j1mc> so individual files won't validate, but everything works if index.xml validates.
[20:50] <j1mc> if you want to pull down the xubuntu docs - it only takes about a minute.
[20:51] <j1mc> bzr branch http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/xubuntu-intrepid
[20:51] <DougieRichardson> ok - btw are those identitied meant to be absolute?
[20:51] <j1mc> "those identified" ... can you explain?
[20:52] <DougieRichardson> whoops i mean your references to the entities
[20:53] <j1mc> they were absolute (and they validated) in the hardy docs, so i guess that they are meant to be absolute.
[20:54] <DougieRichardson> ok - give me a couple of minutes to look it over, fresh eys and all that
[20:55] <j1mc> thanks, DougieRichardson.  i appreciate your help.
[20:56] <j1mc> without getting these errors resolved, no one can really proceed to work on other changes to the docs.
[21:03] <DougieRichardson> i see the problem - it's the references to the entities that are messed up. Has there been a change to the directory structure?
[21:03] <j1mc> yes
[21:03] <j1mc> we squished things down per mdke's request/suggestion
[21:04] <j1mc> the ref's to the entities in the index.xml file?
[21:04] <DougieRichardson> no all the refs have an extra ../ that they don't need
[21:04] <j1mc> can you provide a file name that has this problem?
[21:05] <DougieRichardson> all of them! every section!
[21:06] <j1mc> ok.... cool.  :)
[21:06] <j1mc> i will fix them... that, i can handle  :)
[21:06] <j1mc> thanks, DougieRichardson
[21:06] <DougieRichardson> no worries
[21:06] <j1mc> btw, do you speak japanese?  i noticed the hiragana earlier.
[21:07] <DougieRichardson> i'm learning to but very badly, lol
[21:07] <DougieRichardson> i was messing about preparing a page on IME for the wiki
[21:07] <j1mc> ah, ok.  i used to know some, but i'm quite out of practice.
[21:07] <j1mc> i lived in japan as an exchange student in the summer of 1992.
[21:08] <j1mc> anyway, thanks again for your help.  i very much appreciate it.
[21:08] <DougieRichardson> i'm terrible because i used rosetta stone to learn to speak so if things aren't spelt how i hear them i get it wrong
[21:08] <DougieRichardson> exchange in japan would have been cool
[21:09] <j1mc> ah... fortunately japanese pronunciation / spelling is usually pretty consistent, at least from what i remember.
[21:09] <j1mc> have a good day!
[21:14] <DougieRichardson> cheers
[21:18] <DougieRichardson> there are also some missing references to gnome menu entries, particularly in windows/glossary.xml
[21:20] <DougieRichardson> ah i see - were the gnome entities changed to xubuntu entities?
[21:29] <j1mc> DougieRichardson: i'll have to check that out.  i don't recall off of the top of my head.
[21:30] <DougieRichardson> i've got the thing to pass validate if you want me to push it
[21:40] <j1mc> DougieRichardson: sure.  that would be very nice of you.
[21:41] <DougieRichardson> ok, if you don't mind!
[21:42] <j1mc> i'll look over your changes, but i'm sure they'll be ok.  if not, it would be easy to change back.
[21:43] <DougieRichardson> ok mate I've pushed it
[21:46] <j1mc> thanks, DougieRichardson :)
[21:46] <DougieRichardson> no worries - i'm off for a coffee, lol
[21:49] <j1mc> you rock, DougieRichardson.  thanks.
[21:49] <DougieRichardson> ttfn
[22:04] <prvul> Hi! I need help regarding wiki, is this the right place?
[22:06] <nickellery> it might be, whats your question?
[22:07] <prvul> I am a member of serbian loco team. We want to move on official ubuntu wiki
[22:07] <prvul> and need some guide for that
[23:23] <PriceChild> Noticed http://ubuntuforums.org/showthread.php?t=780216 just want to clarify where to suggest they report it? (Isn't broken in system help)
[23:36] <LaserJock> PriceChild: file a bug against ubuntu-docs?
[23:37] <PriceChild> LaserJock: thanks, from the Doc team page mentioned in the topic I figured that was for the package in ubuntu.
[23:38] <LaserJock> hmm
[23:38] <LaserJock> it is
[23:38] <LaserJock> but we build the help.ubuntu.com pages from the same files
[23:38] <LaserJock> so it's likely a problem there
[23:39] <LaserJock> PriceChild: I guess better would be to file a bug against the ubuntu-doc project
[23:40] <LaserJock> https://launchpad.net/ubuntu-doc/+filebug
[23:41] <PriceChild> LaserJock: thanks very much :) Will post that advice to them and ask to post a link to the bug in the thread to get them involved, and if not will do it myself after a day or so.


[07:54] <erichj> How does one go about requesting an ubuntu hostname clock?
[07:59] <erichj> cloak
[08:02] <nalioth> !member
[08:02] <ubotu> Want to become an Ubuntu member? Look at http://www.ubuntu.com/community/processes/newmember
[08:03] <erichj> thanks
[16:02] <erUSUL> !connectionsharing
[17:24] <fetova> o/
[17:35] <popey> PriceChild: what's the deal with people setting up #*ubuntu* channels? do they need to let you guys know or not?
[17:35] <popey> (anyone can answer that by the way) :)
[17:50] <PriceChild> popey: they don't need to, but its sometimes nice :)
[17:51]  * popey pokes PriceChild with #freshubuntu
[17:51] <popey> not mine, but I am in there
[17:52] <PriceChild> popey: stepping out a min to set up new routers... we don't really mind what happens in that as its not #ubuntu*
[17:53] <popey> where "set up new routers" is a euphamism for "get a hair cut" yes PriceChild ?


[00:00] <maxb> Could I have a copy of jubany:/srv/package-import.canonical.com/new/logs/packages/libfile-touch-perl please?
[00:12] <james_w> maxb, http://paste.ubuntu.com/626940/
[00:12] <maxb> thanks
[00:16]  * maxb stares at the log and wonders what changed that it now errors
[00:22] <poolie> hi amanica
[00:33] <maxb> Hmm. I'm totally failing to be able to reproduce the "727 packages failed with key AssertionError:<module>:main:find_unimported_versions" issue
[00:33] <maxb> Is UDD's meta.db small enough that I could download a copy?
[00:58] <poolie> i'll look
[00:59] <spiv> Hi maxb
[00:59] <poolie> hi spiv!
[00:59] <maxb> Hi
[00:59] <spiv> Thanks for digging into those failures, it's a shame to have slipped so far backwards :(
[00:59] <poolie> maxb: 153MB; so probably yes
[00:59] <maxb> poolie: Great - maybe you could copy it into the www directory?
[01:00] <poolie> yup
[01:00] <maxb> or symlink could work too, I guess
[01:00] <poolie> done
[01:02] <maxb> downloading
[01:04] <maxb> got it
[01:19] <maxb> Grr. It works fine here
[01:20] <maxb> Given the importer queue is empty, I propose a ./requeue_package.py --all-of-type libfile-touch-perl    - even though a previous single requeue failed again, the importer might as well be exhaustively checking each failure still fails again, given I'm totally unable to reproduce the failure, even having supposedly used identical data
[01:38] <spiv> maxb: ok, I'll kick that off
[01:39] <spiv> maxb: if that fails, I guess we start narrowing down version differences and the like :/
[01:39]  * maxb crosses fingers and hopes the problem disappears as mysteriously as it arrived
[01:39] <spiv> (in the software on jubany, that is)
[01:40] <spiv> Requeued, let's see what happens.
[01:44] <maxb> Hmm... this is odd. I see a different testament sha in the DB to what bzr testament reports
[01:47] <maxb> but that still should not be able to cause this failure modoe
[01:50] <poolie> thanks for the reviews gz
[01:50] <poolie> hi spiv; can you comment on my mp about del methods?
[01:50] <spiv> maxb: huh
[01:50] <spiv> maxb: so some of those failures are indeed clearing :/
[01:51] <spiv> e.g. “Success libfile-touch-perl: Nothing new”
[01:51] <spiv> poolie: sure
[01:56] <james_w> maxb, workaround-fix merged and rolled out, thanks for the fix
[01:58] <maxb> thanks
[01:59] <maxb> spiv: Hmm. Mysterious indeed. I can only conjecture that my first broken version of the workaround managed to trigger some insanely counter-intuitive behaviour
[02:08] <poolie> spiv, thanks for that
[02:09] <spiv> np
[02:09] <poolie> i'm surprised bug 659590 could be reliably fixed by relying on del
[02:09] <poolie> perhaps it's an object that's only ever refcounted at present
[02:10] <poolie> perhaps i should revert that one change, and then file a separate bug to deterministically close them?
[02:10] <spiv> I think that would be safest.
[02:11] <spiv> If this were the start of the 2.5 release cycle rather than near the end of the 2.4 cycle I'd be more tempted to land it and see what the fallout is
[02:12] <spiv> I'm not sure that removing that __del__ would necessarily cause a regression along those lines, but given that we have had surprises in this area before my instinct is to be a little conservative.
[02:12] <poolie> really that bad?
[02:13] <poolie> hm
[02:13] <poolie> i'm glad i asked then
[02:14] <spiv> Hmm, it may be interesting to note that bzrlib.transport.ssh has something similar, but with weakref callbacks
[02:16] <spiv> i.e. makes sure to try kill the SSH subprocess when the corresponding object is GCed (if it hasn't already)
[03:57] <poolie> hm
[05:27] <Kamping_Kaiser> hi all. trying to update a pakage with bzr merge-upstream and it tells me i haven't got a tag on the branch upstream-0.2011. how can i tag that branch? help on branches/branch/tag/tags didn't clear it up for me
[05:33] <KombuchaKip> Is there any way to get the branch revision number, e.g. just 43, as opposed to something like 43<EMAIL_ADDRESS>when one runs bzr revision-info?
[05:34] <Kamping_Kaiser> bzr revno?
[05:36] <KombuchaKip> Kamping_Kaiser: Thank you. I didn't see that switch.
[05:36] <Kamping_Kaiser> KombuchaKip: np
[05:36] <spiv> Kamping_Kaiser: 'bzr tag -r REV TAG_NAME' sets a tag on a branch
[05:37] <spiv> Kamping_Kaiser: specifically it sounds like bzr merge-upstream is looking for a tag called "upstream-0.2011"
[05:37] <Kamping_Kaiser> spiv: the error implies i have multiple branches. could that be the case, or is it just fooling with me?
[05:38] <spiv> I think you may be misreading the error
[05:40] <Kamping_Kaiser> quite possible. full message is 'bzr: ERROR: Unable to find the tag for the previous upstream version, 0.20110614, in the branch: upstream-0.20110614'. i don't know how to tell if i'm in that branch; bzr info doesn't tell me
[05:42] <spiv> Kamping_Kaiser: Right.  I see the confusion.
[05:42] <spiv> Kamping_Kaiser: "upstream-0.20110614" is the tag name it is looking for
[05:42] <spiv> (Which would be the tag corresponding to upstream version 0.20110614)
[05:43] <Kamping_Kaiser> spiv: thanks for clarifying. have to say, thats a rather confusing message :/
[05:44] <spiv> Apparently so!
[05:44] <spiv> I'll file a bug about that.
[05:45] <Kamping_Kaiser> spiv: thanks. if you could let me know the number that would be great :)
[05:47] <spiv> bug 797518
[05:48] <Kamping_Kaiser> thnks
[05:48] <Kamping_Kaiser> *thanks
[06:29] <Kamping_Kaiser> hi all, another merge-upstream question. while using merge-upstream it deleted my debian/ directory. is this, uh, normal? http://paste.debian.net/119879/ am i missing more tags? (bzr help merge-upstream doesn't mention tags at all)
[06:44] <spiv> Kamping_Kaiser: I don't think that's normal, but I don't know enough about bzr-builddeb to suggest how to debug :(
[06:45] <Kamping_Kaiser> spiv: np. i'll hang around, hopefully someone else will wander by
[06:45] <spiv> Kamping_Kaiser: hmm, although a quick guess might be that the debian/ directory is incorrectly part of the previous upstream-* version?
[06:47] <Kamping_Kaiser> spiv: let me try retagging to check
[06:47] <spiv> Kamping_Kaiser: or just inspect the contents (e.g. with 'bzr qlog')?
[06:49] <Kamping_Kaiser> spiv: qlog doesn't appear to be a bzr command
[06:49] <spiv> Kamping_Kaiser: it's part of the qbzr plugin
[06:50] <spiv> ('bzr viz' from the bzr-gtk plugin is nearly as good)
[06:51] <Kamping_Kaiser> ah, don't have that plugin
[06:55] <Kamping_Kaiser> spiv: looks like you are correct - it wants the upstream release tagged, not the package release.
[06:55] <spiv> Kamping_Kaiser: yes, the upstream-* tags are for tagging upstream versions
[06:56] <spiv> (Although I think normally you'd rely on merge-upstream or import-upstream to create those revisions and tags for you)
[06:57] <Kamping_Kaiser> spiv: its probably because i crated the repo with dh-make manually, instead of bzr dh-make (which i just discovered)
[08:03] <vila> morning all !
[08:32] <fullermd> What, again?  We just survived the last one...
[08:38] <jam> morning all
[08:52] <mgz> will try to find some time for coding today, about to go offline though
[09:05] <Riddell> spiv: can't hear you
[09:05]  * jelmer waves
[09:05] <spiv> Software.  It's marvellous.
[09:06] <jelmer> should we try skype?
[09:06] <Riddell> jelmer: mumble still not happy for you?
[09:07] <Riddell> is vila around?
[09:07] <vila> errk, here I come
[09:08] <jelmer> Riddell, not really, trying the audio wizard setup again..
[09:09] <jelmer> \o/
[09:37] <maxb> james_w: Do you remember what the "sleeping to stack" thing the UDD importer does is for? (Sleep for 5 minutes after pushing a dev-focus branch if the push created a new remote branch) Is it, as speculated in the code, obsolete now launchpad doesn't have separate read / write branch areas?
[09:38] <spiv> maxb: sounds highly plausible
[09:38] <spiv> jelmer, Riddell, vila, jam: g'night!
[09:38] <vila> spiv: cu !
[09:42] <jelmer> Riddell, one of the bugs associated with it is bug 465517
[09:48] <Riddell> jelmer: unapproved queue is fairly long, hasn't been processed in a week, I guess you can try politely pinging members of ~ubuntu-sru
[09:48] <jelmer> Riddell: thanks - just pinged pitti in #ubuntu-devel
[10:19] <vila> jelmer: I forgot to ask, which bzr versions did you deploy on lp ?
[10:45] <jelmer> vila: 2.3.3
[10:45] <vila> jelmer: thks
[10:47] <jelmer> vila: I'm looking forward to the day we can deploy 2.4
[10:48] <vila> yeah, happens every 6 months ;)
[14:43] <james_w> maxb, experimentation showed that if it slept for about the latency of copying branches between the two areas they still failed to stack
[14:43] <james_w> maxb, no-one had any explanation for why it was happening, so I left it at 5 minutes which seemed to avoid the issues
[15:05] <spiv> james_w: so now that there's no copying to wait for that sleep is probably unnecessary then?
[15:06] <james_w> spiv, the conjecture at the time was that it wasn't the split that was causing it, but no alternative explanations were forthcoming
[15:08] <spiv> james_w: hmm.  Still tempting to try removing it and see if the bug and/or trigger is no longer present...
[15:09] <james_w> yeah
[15:09] <spiv> Or maybe it if it still fails it might be more obvious why
[15:10] <spiv> And with that optimistic thought I'm off to bed!
[15:33] <achiang> hello, looking for some help on how to recover from a pretty bad mistake. :-/ i had 2 branches, A and B. for a long time, i've been making changes in A, and then merging/pulling into B. i just made a mistake of pulling B back into A, and want to undo that.
[15:34] <achiang> even worse is that both A and B are committed and pushed into LP.
[15:50] <maxb> This doesn't sound too bad
[15:51] <maxb> The potentially slightly tricky part is that you will have to identify the old tip of A by browsing the revision history and figuring it out
[15:52] <maxb> Are A and B public? Sometimes it's easier to explain by just saying "look at these branches"
[15:54] <achiang> no, A and B are not public, unfortunately.
[15:54] <maxb> Alright.
[15:55] <maxb> First thing is - we need to be clear on whether you pulled/pushed B into A, or merged it
[15:55] <maxb> Second, are you familiar with qbzr and "bzr qlog" ?
[15:56] <jam> have a good night everyone
[15:56] <achiang> i definitely did a 'bzr pull B', so i do not have a clean merge point. :(
[15:58] <maxb> OK, so, start "bzr qlog", and look back in the history for the last merge of A into B - this should allow you to identify the revision that should be the correct tip of A
[15:58] <achiang> maxb: ah, what i do have is good versioning
[15:59] <maxb> james_w: Thanks - do you know if it has been revisited at all since the "two areas" design was changed to a single area? It seems likely that this behaviour could be removed now, for significant simplification of the code.
[15:59] <achiang> so, my A version string looks like: 0.4~bzr457
[15:59] <achiang> and my B version string looks like 0.4~bzr457versionB
[16:00] <james_w> maxb, it has not been revisited
[16:00] <achiang> so, i think that r457 in A is the last time i branched off B
[16:00] <achiang> or rather, r457 in A is the last time i merged it into B
[16:01] <maxb> achiang: Ok, that will help in confirming that you have found the right revision, but you'll still need to hunt through the history. If you start "bzr qlog", and look back through the merge commits, it should hopefully be reasonably easy to locate revisions which are intended to be part of A
[16:08] <achiang> maxb: hm, actually life is a little easier -- on another machine, i have a good copy of A before my mistake
[16:11] <maxb> achiang: OK, so once you have convinced yourself that it is not missing any revisions that should be there, you can just "bzr push --overwrite" it to other places where it needs to be
[16:13] <achiang> maxb: ok, i'll try that
[16:16] <achiang> maxb: is there a way to diff branches at the revision level?
[16:21] <vila> achiang: bzr qlog branchA branchB
[16:21] <vila> achiang: or bzr qlog branchB branchA
[16:22] <vila> generally you put the most inclusive one first (trunk)
[16:23] <achiang> hm, thanks
[17:00] <maxb> Some of the older UDD branches are... not very pretty
[17:01] <maxb> scala has somehow managed to end up with separate (though related) upstream revisions in ubuntu and debian, and three separate revisions for each version, one in unstable, one in testing, and one in ubuntu
[17:01] <maxb> Despite never having had an ubuntu delta
[17:20]  * jelmer waves
[17:26] <apw> can anyone explain why bzr moves things to .moved when merging?
[17:27] <vila> apw: bzr help conflict-types
[17:28] <vila> apw: but in a nutshell, I suspect you're running into a parallel import ?
[17:28] <vila> apw: i.e. do you have a few .moved files or a huge number of them ?
[17:29] <apw> i have a world of them, and the importer is somehow making the kind of mess which reintroduces the collission for every upstream merge, and it is getting on my nerves
[17:29] <vila> :-/
[17:30] <apw> vila, is there some way i can say ... these files are the same file really, treat them as a textual collission
[17:30] <vila> apw: so, the root issue is that bzr use file ids to track renames and that works well except... when the "same" files received different IDs
[17:31] <vila> apw: not yet no, sorry, but it's a know issue for udd and we should fix it (and will)
[17:31] <apw> vila, so i should be using git to do my merge then, git-bzr or something, as that will not make the same mistake
[17:31] <vila> known
[17:31] <apw> vila, anyhow thanks for the info that is helpful
[17:31] <vila> I don't know how bzr-git handle that
[17:32] <apw> well git doesn't track files, so its merge would be what i want, just texttual
[17:32] <vila> apw: but yes, git doesn't have this problem
[17:32] <vila> yup
[17:33] <vila> apw: what is the package you're having an issue with ?
[17:33] <jelmer> bzr-git won't help with that
[17:33] <apw> vila, module-init-tools
[17:33] <apw> jelmer, i atually meant git-bzr in that context
[17:34] <apw> jelmer, as in check it out in git, merge it there with its dumber merge, and push it back into bzr
[17:34] <vila> maxb: does module-init-tools ring a bell ?
[17:34] <jelmer> apw: Ideally bzr's merge would support per-path merging
[17:35] <apw> jelmer, well indeed, but as right now what it does is hose my working directory and break my poor mind ...
[17:35] <maxb> I have not looked at module-init-tools
[17:35] <jelmer> apw: it shouldn't actually be that hard to implement, there just never has been a lot of reasons to implement it
[17:36] <apw> vila, so in my problem case the merge seems to have merged some files, ie noticed they are ok, then moved them aside, such that if i take the 'other' side i won't actually get the other side i'll get only like 2 files
[17:36] <maxb> Unfortunately I think quite a few of the UDD imports have ended up with differing Ubuntu vs. Debian file-ids
[17:36] <apw> maxb, and thats insoluable? as the merge side of things just doesn't work at all when they are like that
[17:37] <vila> apw: I don't follow, how do you take the 'other' side ?
[17:37] <maxb> It's a tractable problem, but it's most easily solved by throwing away the mangled import and reimporting if there are no non-importer revisions
[17:38] <gour> is 2.4 going according to the schedule?
[17:38] <apw> maxb, that seems fine, what i don't get is once i have merged them why it doesn't know they are then the same
[17:38] <vila> gour: so far, yes
[17:38] <vila> 'once I have merged them' How ?
[17:38] <apw> vila, i have a tests directory with some files, i merge in a near identicle directoy with the same conents different file id's
[17:39] <apw> vila, and i end up with tests/ with one directory in with the one new file from the merge, and everything else in tests.moved.  i then say "bzr resolved --action=take-other which to my reading should give me whats in what i am merging and nothing from my local
[17:39] <fullermd> But you haven't _merged_ the files, you've just picked one or the other.
[17:39] <maxb> OK, so in the module-init-tools case, the problem is that we have the existing oneiric branch which is derived from an import of upstream's git - whereas the existing debian branches are derived from tarball imports
[17:40] <apw> vila, but what i get is exactly one file from the other side and nothing else.  that seems like a completely erronius resolution
[17:40] <vila> apw: argh
[17:40] <apw> fullermd, well indeed, but picking the ones from the right place aught to sort out the wrong file ids in my world
[17:40] <vila> apw: 1) 'bzr resolve --take-other' *with no path specified* has bugs
[17:41] <maxb> So in this case it is uncovering the problem that UDD cannot work for merging changes from Debian if the ubuntu side is tracking one representation of upstream but the debian side is tracking a different one
[17:41] <apw> vila, quality software
[17:41] <vila> apw: well, I just fixed one today, 'cause I had a bug report ;)
[17:41] <vila> apw: what version are you using ?
[17:41] <apw> maxb, and i can't fix it can i, not even by careful use of merging
[17:42] <apw> vila, whatever version is in natty
[17:42] <apw> vila, its hard to know whats a bug and whats meant to work that way when i am in such a pickle
[17:42] <vila> 'bzr version' but that's probably 2.3.1 (2.3.3 is currently SRUed)
[17:42] <vila> apw: I know
[17:42] <maxb> apw: Well, you could, but if you "fixed" the use case of merging from Debian, you would have introduced the equivalent problem for merging from upstream's bzr-git import.
[17:42] <vila> apw: I know :-(
[17:42] <apw> 2.3.1 indeed
[17:43] <vila> apw: there are no known bugs if you use 'bzr resolve --take-other FILE' (at least in trunk)
[17:43] <apw> maxb, i assume the problem persists because of how the importer pushed down new versions ... now if i push my branch to the import branch before i upload, it shouldn't stand on my branch at all should it ?
[17:44] <maxb> The root cause of failure here is that we have allowed official package branches to be used with non-UDD-importer upstream sources, without realizing and documenting how this breaks the merge workflow
[17:44] <apw> maxb, might that let me fix the ids ?
[17:44] <gour> vila: good luck with release...it looks it might be an important one
[17:45] <apw> maxb, i think module-init-tools was a very early adopter of bzr and so very very likley all the horrors you suspect have happened to it
[17:45] <maxb> apw: The importer will honour tagged revisions pushed before uploading if it assesses their content to be essentially the same as the upload
[17:46] <apw> so then its down to what 'essentially the same' means ... as i have watched it wack my tagged revisions before
[17:47] <maxb> apw: Basically the problem is that someone decided to make lp:ubuntu/oneiric/module-init-tools be a branch derived from upstream's vcs (which is a good idea in general) but without knowing the consequence that it is incompatible with merging from a Debian UDD-imported branch
[17:47] <apw> maxb, i suspect it actually was joined there before the importer existed even
[17:49] <apw> maxb, so no magic bullet ... just slog t
[17:49] <apw> through the conflicts every time, papering over the bugs in resolved ...
[17:50] <maxb> Well. If I was doing this merge, I would disregard lp:debian/module-init-tools completely
[17:50] <apw> maxb, ok, is there somewhere else i can get the 'contents' and apply it?
[17:50] <maxb> I would import the debian .dsc into a local branch and merge that
[17:51] <apw> maxb, ok will give that a go, it cannot possibly be any harder
[17:51] <apw> maxb, any idea where i'd find that
[17:52] <maxb> If we want to continue this style of package maintenance, I'd probably take the opportunity to disentangle from the unwanted debian import whilst we still can, first.
[17:53] <maxb> Ah, so is this package maintained in bzr in debian? Looks like it
[17:53] <maxb> Right OK
[17:54] <apw> maxb, could be, i have managed to merge the package in the sense that i know the real differences from debian and its back to a small set thereof
[17:54] <apw> maxb, the plan was to try and push it back to being related in the 'normal way' when i started out
[17:54] <maxb> So the nice and tidy way to manage this would definitely be to remove the painful messy 3.13-1ubuntu1 revision before we build any more history on top of it
[17:55] <apw> maxb, whatever you think is appropriate
[17:56] <maxb> So, here is what I'd do:
[17:57] <maxb> * Have a local copy of lp:ubuntu/module-init-tools
[17:58] <maxb> * Have a local copy of the Debian packaging branch which Debian is actually using - *not* lp:debian/module-init-tools
[17:58] <maxb> * In the ubuntu branch, uncommit the painful merge of 3.13-1ubuntu1 ("bzr uncommit")
[18:00] <maxb> * Reconstruct that revision with different ancestry, by first merging the appropriate revision from Debian's bzr ("bzr merge -r 3.13-1 ../local-debian-branch"), then removing all the files, unpacking Ubuntu's .dsc into the tree, and committed
[18:00] <maxb> committing
[18:00] <maxb> At that point, I'd be well placed to merge 3.16-1 from Debian with bzr helping, rather than fighting me
[18:01] <apw> that sounds at least sane
[18:01] <apw> so i need to find their upstream branch,
[18:01] <apw> hopefully that is in their package
[18:02] <apw> maxb, i'll have a go at that and publish something for review
[18:03] <maxb> I can try to do what I just described and post exact commands
[18:03] <maxb> Hmm, their debian/control lacks Vcs-* fields - naughty
[18:04] <apw> maxb, yeah i think i grok your intent and indeed why it makes sense, its finding the debian one which will challenge one
[18:04] <maxb> Ask Scott James Remnant?
[18:05] <apw> maxb, well i don't think he is maintining the debian side, we have been deviant from them for the longest time
[18:05] <maxb> Oh yikes, I have misinterpreted somewhat
[18:06] <maxb> "3.12-1" was deceptively a direct upload to maverick apparently, not via debian
[18:06] <apw> ahh yes, there was much badness done in the packages history
[18:06] <maxb> oh, yuck
[18:06] <maxb> erm, right
[18:07] <maxb> oh
[18:07] <maxb> there's no Debian history in this branch at all
[18:07] <apw> whats annoying is i know how to un-fook self here with git, i'd just take the debian import, drop our files on it, merge the history from the current mess branch without taking any files at all and push the result
[18:07] <maxb> just Ubuntu history mislabelled with debianlike revisions
[18:08] <apw> maxb, yeah this branch is an utter mess, i wonder if i rm'd all the files in the ubuntu one and merged it into a new checkout of the debian one
[18:08] <apw> would i get a clean debian one with the ubuntu history still attached but not affecting me ?
[18:09] <apw> ie all my files would be the right id's from the import side
[18:09] <maxb> Vaguely - I am currently trying to remember how I solved one of these before
[18:10] <apw> well perhaps i will go try that
[18:10] <apw> and see what bzr vis does after
[18:11] <maxb> apw: I think I know what to do now
[18:11] <maxb> bzr branch -r 3.13-1 existing-ubuntu-branch reconcile-fileids
[18:11] <maxb> cd reconcile-fileids
[18:12] <maxb> bzr merge ../existing-ubuntu-branch # which is at 3.13-1ubuntu1
[18:12] <maxb> bzr revert . # Note the final . character in the command
[18:13] <maxb> Delete everything but the .bzr dir
[18:13] <maxb> Copy in the content from 3.13-1ubuntu1
[18:14] <maxb> bzr diff, briefly check the output looks like the existing ubuntu delta
[18:14] <maxb> bzr ci -m "Committing existing Ubuntu 3.13-1ubuntu1 with fileids from Debian UDD branch>"
[18:14] <maxb> done
[18:15] <apw> maxb, why do i get ids from debian there?  as i never mentioned it anywhere?
[18:15] <apw> or is that 3.13-1 the real debian one in that case
[18:15] <maxb> Yes, that's correct
[18:16] <apw> ok will give it a go and see if we can unfook this mess
[18:16] <apw> maxb, thanks
[18:17] <maxb> I will try these commands too and make sure they actually do what I claim :-)
[18:22] <apw> maxb, well it looks sane enough in bzr vis, will try merging it up as well
[18:22] <apw> as there is anohter upstream version to merge to as a test
[18:24] <maxb> It does appear to have done something approximately sensible
[18:25] <apw> maxb, thats doing much more what one might expect, exactly one conflict, where i'd expect one
[18:26] <apw> maxb, awsome thank you, that revert . thing is essentially what i would have done in git too
[18:26] <maxb> There really ought to be a way to do this without deleting and manually replacing the tree, but I'm having trouble thinking of one right now
[18:27] <apw> maxb, but as the history is still attached i can still find everything so i think its ok
[18:43] <apw> maxb, and the merge to 3.16-1 has gone exactly as i would expect not just the odd conflict nice ... thanks
[22:56] <dash> i'm getting a lovely 'checksum mismatch' error when trying to pull from an svn repository. anything i can do to diagnose/work around this, or is cloning a fresh branch outside the shared repo my best bet?
[23:03] <poolie> dash, hi, i suggest you file a bug with details and then branch into a different repo to see if that helps
[23:03] <maxb> dash: A fuller view of the error message would help a useful answer
[23:03] <dash> thanks
[23:04] <dash> it's just "bzr: ERROR: checksum mismatch: '0fa285e09d5f0258f68f2bd3c95474af' != '3f62e97923e50d938a211951ff56e753' in mysvndir/trunk:22246"
[23:04] <dash> no traceback
[23:04] <maxb> Please check your ~/.bzr.log - I think the traceback will be saved there
[23:07] <poolie> hi maxb
[23:08] <maxb> hello
[23:46]  * Riddell politely reminds spiv to review his bzr-explorer merges sometime today