[01:37] <james_w> mwhudson: thanks for the pointer to iolaus
[01:38] <james_w> lifeless: sounds similar to some of the ideas you were telling me about: http://github.com/droundy/iolaus
[01:38]  * james_w crashes
[01:43] <jelmer> \o/ it's in haskell
[01:46] <lifeless> james_w: yes, there are similarities
[01:47] <poolie> igc, re bug 524177
[01:47] <poolie> is that some kind of problem with the scripts on escudero?
[01:48] <poolie> also, when you file bugs, can you please triage them too?
[01:48] <poolie> no point making someone else reopen the bug to do it
[01:55] <poolie> spiv, maybe at the end of the eintr thread we should add something about it to the developer guide
[01:56] <spiv> poolie: yeah
[01:56] <spiv> poolie: and, assuming we keep until_no_eintr (which I think we need to for reading from pipes at least), put a very clear warning in its docstring.
[01:56] <spiv> Probably with a pointer to full treatment in the developer guide.
[01:57] <poolie> hm
[01:58] <poolie> so until_no_eintr is a bit dangerous because it's highly likely to be needed on functions that can return partial results
[01:58] <poolie> and you need to loop separately on them too
[01:58] <poolie> perhaps
[01:58] <poolie> i suppose it's not actively dangerous, just often not sufficient
[01:58] <poolie> so a patch that describes the way these things should be handled might be a good way to get to agreement with gzlist
[01:58] <poolie> just an idea
[01:58] <poolie> also
[01:59] <poolie> we could add a test_source for known broken apis
[02:02] <spiv> Right, so until_no_eintr is right for things that are very close to the underlying syscall, or at least std libc, interface.
[02:03] <spiv> But as soon as you have any layers between that and until_no_eintr it's probably wrong.
[02:03] <spiv> And you either need to push the eintr handling down into a lower layer, or use a different API entirely.
[02:04] <spiv> I think I am converging on agreement with gzlist.
[02:05] <spiv> There was a disconnect because he wasn't aware of the pipe.read issue being a valid and appropriate use of until_no_eintr, so he was of course sure the right thing was to rip out until_no_eintr, whereas I was of course sure we still wanted it :)
[02:05] <spiv> I'm not aware of a better alternative for the pipe.read than just wrapping it in until_no_eintr, but if one comes up we can evaluate that.
[02:11] <lifeless> freetown2: hmm, 350mb apt-get update
[02:11] <lifeless> erem grade.
[02:19] <poolie> lifeless: ?
[02:19] <lifeless> poolie: lucid moving fast
[03:37] <parthm> poolie: I am going through your review comment https://code.launchpad.net/~parthm/bzr/2.0_376388_dot_bazaar_ownership/+merge/19593
[03:37] <parthm> Does http://pastebin.com/m4d62c257 seem like a reasonable approach in osutils?
[03:38] <parthm> I also plan to add osutils.open that optionally takes ownership_src arg. This can then be used succintly for creating files like log and conf.
[03:53] <poolie> parthm: that looks pretty reasonable
[03:55] <poolie> parthm: raise just one warning when it fails, and use trace.warning not warnings.warning
[03:55] <parthm> OK. Thanks.
[03:57] <parthm> I saw your comment regarding making this patch for trunk. That sounds fine to me. I am thinking that for now I will continue working on the same branch so that review comments are not lost. Then it can be merged up?
[03:58] <poolie> yep
[03:59] <parthm> One more question, is there a doc that lists the dependencies we need to have in order to hack bzr? I have been installing packages seperately one at a time as I hit issues (pyrex, testtools, pyftpdlib, subunit etc.).
[03:59] <parthm> Due to time some tests also get skipped.
[04:00] <poolie> is this on ubuntu?
[04:00] <poolie> the easiest way is to say 'apt-get build-deb bzr'
[04:02] <spiv> Theoretically the INSTALL file should list the dependencies, but that part of it seems to be out of date.
[04:04] <parthm> Yes. Its ubuntu. build-deb sounds good. Thanks.
[04:05] <parthm> Yes. INSTALL does look out of date :)
[04:50] <poolie> parthm: what do you think of http://pastebin.ubuntu.com/379525/
[04:50] <poolie> are there any other questions it should answer?
[05:00] <parthm> poolie: This certainly answers most of my. I wasn't aware of the appendpath trick. Maybe we can have pointers for getting further help (irc, mailing list). Specifically I faced a problem getting into irc (i am new to it) as it required a registered nick, I kept getting "cannot send" messages before I googled and realized what was happening.
[05:00] <poolie> yeah that kind of sucks actually
[05:00] <poolie> i'll add some pointers
[05:01] <parthm> Maybe somewhere a tip can be put in regarding avoiding "resubmit merge request" as comments are lost. I made that mistake.
[05:02] <parthm> The doc looks good.
[05:07] <parthm> I seem to have hit upon an interesting situation. http://pastebin.ubuntu.com/379534/ Not sure what I did (maybe ^C of some test?), I ended up with some unknown file/dir which don't exist on disk. How do I get rid of it?
[05:11] <spiv> parthm: that's pretty weird.
[05:14] <poolie> lifeless: did you or anyone already register #bzr with freenode?
[05:18] <lifeless> poolie: yes years ago
[05:19] <poolie> did you register the group too?
[05:20] <lifeless> don't know what you mean
[05:20] <poolie> ok, that works
[05:20] <lifeless> I've just added you to the channel access list though
[05:20] <poolie> http://freenode.net/group_registration.shtml#groupcontacts
[05:21] <lifeless> what does that mode do ?
[05:22] <poolie> allows non-registered users to talk
[05:22] <poolie> isn't it obvious? ;-)
[05:22] <parthm> Nice :)
[05:22] <lifeless> poolie: no, its not :P
[05:23] <lifeless> poolie: you might like to drop op though; and tell chanserv the mode bits you want, otherwise netsplits can confuse things.
[05:23] <lifeless> poolie: [dropping op because freenode frown on folk sitting with op on for extended durations, telling chanserv so that it sticks properly]
[05:24] <poolie> ok
[05:24] <poolie> >  freenode frown on folk sitting with op on for extended durations
[05:24] <poolie> why?
[05:25] <lifeless> something about community spirit; I don't recall really.
[05:25] <lifeless> http://freenode.net/using_the_network.shtml
[05:25] <lifeless> Use the chanserv "op" command to obtain channel operator status only when needed. This will help to keep your channel temperature low and reduce conflicts.

[05:25] <parthm> poolie: I plan to send a new merge request for 2.0_376388_dot_bazaar_ownership against the trunk. Its seems overrideAttr are not available in 2.0. I will be using them for writing the tests as you suggested.
[05:26] <poolie> hm
[05:26] <lifeless> poolie: /msg chanserv access #bzr list -- thats what I looked at when you asked, and you weren't there so I did
[05:26] <poolie> yeah, i see
[05:26] <lifeless> access #bzr add poolie
[05:26] <poolie> i think all the core devs should have access
[05:26] <lifeless> I don't know if that makes you fully-capable; I don't  know enough to tell.
[05:27] <lifeless> I suggest you try adding e.g. jam
[05:27] <poolie> 'flags #bzr' gives more linenoise
[05:27] <lifeless> if you can't I'll dig deeper to find out how to make you as-capable as me
[05:27] <poolie> hang on
[05:28] <poolie> so you have also sRA bits
[05:28] <lifeless> I don't know what they mean
[05:28] <poolie> and f
[05:28] <lifeless> I didn't want to randomly type stuff in until I check
[05:29] <lifeless> are you able to add jam ?
[05:29] <poolie> oh go on :-P
[05:29] <cody-somerville> +f - Enables modification of channel access lists.
[05:29] <cody-somerville>  +F - Grants full founder access.
[05:29] <poolie> send chanserv help flags
[05:29] <poolie> so i think i can't grant access, but i'll try
[05:30] <poolie> yeah, i can't grant rights
[05:30] <poolie> so i think i need you to do
[05:31] <poolie> flags #bzr poolie +*
[05:31] <lifeless> poolie: you look the same as me now
[05:31] <poolie> ew
[05:31] <poolie> sweet, thanks
[05:32] <cody-somerville> poolie, lifeless: You guys should get the +F flag from Christel (who is a freenode staff member IIRC).
[05:32] <lifeless> cody-somerville: thanks for helping out
[05:33] <poolie> cody-somerville: by asking christel, i suppose?
[05:33]  * cody-somerville nods.
[05:33] <cody-somerville> lifeless, Is that a polite way of telling me to bugger off? :=)
[05:33] <poolie> seems away atm
[05:33] <poolie> no, seriously, thanks
[05:34] <cody-somerville> If you guys register yourself as a group, you can get your own cloaks and then you grant anyone with that cloak certain privileges (ie. ops).
[05:34] <Kamping_Kaiser> jelmer: out of intrest, does that subvertpy test need disabling in testing/unstable or only stable?
[05:34] <poolie> cody-somerville: right, i was just asking about that too
[05:34] <poolie> i wonder if we should register our own group or be subsidiary to canonical
[05:34] <lifeless> cody-somerville: no, its me saying thanks
[05:34] <poolie> istr some mail about this
[05:34] <lifeless> cody-somerville: I so rarely look at IRC modes it all pages out.
[05:35] <lifeless> poolie: I think we should be like ubuntu, or perhaps subsidiary to ubuntu - more than staff can help.
[05:35] <lifeless> cody-somerville: besides which, I have no politeness chip.
[05:35] <poolie> their policy seems to prefer a company
[05:36] <lifeless> whose?
[05:37] <poolie> freenode's policy
[05:37] <lifeless> hmm, odd.
[05:37] <poolie> ok, so it's filed now
[05:37] <poolie> we'll see
[05:37] <cody-somerville> poolie, Ubuntu is a registered group.
[05:37] <poolie> i'm glad that's sorted
[05:37] <poolie> ok, i tried to register Bazaar c/o Canonical
[05:37] <cody-somerville> poolie, You have a cloak of canonical/launchpad/poolie
[05:38] <poolie> and i granted flags to some core devs
[05:38] <lifeless> cody-somerville: are cloaks like bitmasks ?
[05:38] <cody-somerville> lifeless, They mask your hostname
[05:38] <lifeless> yes I know that
[05:38] <lifeless> but their value
[05:38] <lifeless> can you have e.g. canonical/launchpad/ubuntu/fsf/bazaar/lifeless
[05:39] <lifeless> oh, add debian
[05:39] <poolie> i think they are hierarchical
[05:39] <lifeless> hmm thats a bit annoying
[05:39] <lifeless> community membership is more setlike
[05:39] <poolie> one propeller beanie at a time please
[05:39] <lifeless> or can you choose amongst many cloaks you have permission to use ?
[05:40] <lifeless> (at login time I mean)
[05:40] <cody-somerville> You can only have one but you can combine them - although its a bit awkward.
[05:41] <cody-somerville> Some people have: pdcp/supporter/ubuntu/member/$nick
[05:41] <cody-somerville> and what not.
[05:42] <poolie> k
[05:42] <poolie> so more to the point is """[+o]  attracts the attention of participants who react negatively to authority. Have your nick added to the channel access list and op yourself only when needed. """
[05:43] <lifeless> http://web.media.mit.edu/~marcelo/cornucopia/
[05:43] <mneptok> poolie: OH, LOOK AT *YOU*, MISTER IMPORANT!
[05:43] <poolie> see
[05:43]  * mneptok pouts in the corner
[05:43]  * cody-somerville recommends a script created by Dennis Kaarsemaker, http://www.kaarsemaker.net/downloads/code/chanserv.py
[05:44] <parthm> I am getting two failures while running blackbox selftest on unmodified trunk http://pastebin.ubuntu.com/379546/ . Is this expected?
[05:44] <mneptok> IIRC, i had a /canonical/staff Freenode cloak when i was an employee
[05:44] <lifeless> cody-somerville: sadly its for xchat :P
[05:45] <lifeless> parthm: no, because pqm selftests trunk on every commit
[05:46] <mneptok> i think "canonical/staff/bzr" would look sexy on poolie
[05:46] <poolie> that's pretty strange
[05:46] <poolie> i pick up my wizard staff and cloak
[05:46] <spiv> parthm: hmm, both in "expectFailure"
[05:46] <mneptok> while lifeless should get canonical/staff/i/get/around/more/than/a/monaco/hooker
[05:47] <spiv> parthm: what version of testtools do you have?
[05:47] <poolie> k
[05:47] <poolie> so that's done
[05:47] <lifeless> mneptok: how much does a monaco hooker get around?
[05:47] <poolie> now i don't need to document
[05:47] <parthm> spiv: testtools-0.9.2. I installed it locally from a downloaded tarball.
[05:47] <poolie> ok, i think this ^^ is exactly what i was reading about inappropriate behaviour :)
[05:47] <mneptok> lifeless: my memories of that time in my life are kinda hazy ...
[05:48] <mneptok> wait ... was that out loud?
[05:48] <poolie> but presumably in their maserati
[05:48] <spiv> parthm: hmm, that's what I have (well, a deb saying 0.9.2-1, from the bzr PPA IIRC)
[05:48] <lifeless> spiv: doesn't look like testtools to me ?
[05:49] <lifeless> its interesting that some extensions are not built
[05:49] <lifeless> parthm: try running 'make'
[05:50]  * parthm running tests again after make
[05:50] <spiv> parthm, lifeless: FWIW, trunk with and without extensions passes those tests for me, as known_failure
[05:51] <lifeless> ah
[05:51] <lifeless> could be testtools then, but that version should be fine
[05:51] <parthm> I see the same failures even after make. :(
[05:51] <lifeless> parthm: are you sure that version of testtools is being loaded?
[05:52] <spiv> parthm: what if you don't use --parallel=fork?
[05:52] <spiv> (and what version of subunit?)
[05:52] <poolie> parthm: you can vote on https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/19682 if you want; I put in your suggestions
[05:52] <lifeless> oh, I didn't realise subunit was in there. Smells like an old subunit perhaps.
[05:52] <spiv> lifeless: neither did I at first, but parthm sensibly included the command line in the paste :)
[05:52] <parthm> lifeless: Yes. I see the correct path in the error log.
[05:53] <parthm> subunit is 0.0.2 from packages
[05:54] <lifeless> poolie: as a potential user, you might like https://code.edge.launchpad.net/~lifeless/testresources/bug-522338/+merge/19684
[05:54] <lifeless> parthm: thats pretty old
[05:54] <lifeless> parthm: what platform are you on?
[05:54] <parthm> poolie: will do. thanks.
[05:55] <parthm> lifeless: I am using ubuntu 9.10
[05:55] <parthm> will run again w/o fork.
[05:57] <lifeless> parthm: you might want to grab the subunit PPA, it has newer subunit, testtools all packaged
[05:58] <poolie> maybe we should add a version assertion to bzr?
[05:58] <lifeless> poolie: it doesn't turn up all that often. We can if you like
[05:58] <poolie> maybe next time
[06:00] <parthm> yep. subunit was the problem. all tests pass without fork. will install the latest ppa.
[06:01] <parthm> i agree with poolie, it would be good to have a version check. for someone new to bzr codebase its very helpful if the error message clearly indicates this.
[06:01] <parthm> thanks for the help
[06:31] <parthm> got to go. have a nice day!
[06:38] <Kamping_Kaiser> james_w: bzr-builddeb from testing fails to build on stable ( http://paste.debian.net/60457/ ). Would this be a dependencies issue, or is the setup.py file actually broken?
[06:39] <quicksilver> Hmm. bzr missing defaults to 80 cols with no terminal on stdout?
[06:39] <quicksilver> that seems nasty.
[06:40] <lifeless> quicksilver: it defaults to your terminfo
[06:40] <lifeless> and if there is no terminal, we use something that will often be sensible
[06:41] <lifeless> Kamping_Kaiser: possibly a parser change in rst
[06:41] <quicksilver> I'd hoped --line would default to infinitely long lines
[06:41] <quicksilver> (if there was no terminal)
[06:41] <lifeless> we did that for about 3 days
[06:41] <lifeless> after gigabytes of output in test runs it got changed
[06:41] <quicksilver> ok :)
[06:42] <lifeless> I can see your argument, perhaps file a bug - we may have solved our issue the wrong way.
[06:42] <Kamping_Kaiser> lifeless: rst?
[06:42] <lifeless> you could mention that other tools defaults to no-apparent-limit (if they do)
[06:42] <lifeless> Kamping_Kaiser: ReST - restructured text
[06:42] <Kamping_Kaiser> oh
[06:43] <lifeless> the language README is written ni
[06:43] <mneptok> NI!
[06:43] <Kamping_Kaiser> lifeless: would that be bzr's rest parser? I'll check the changelog incase theres some info
[06:43] <lifeless> no
[06:43] <lifeless> python module
[06:43] <Kamping_Kaiser> ok
[06:45] <quicksilver> lifeless: what I'm actually doing is writing a command line tool to analyse a bunch of repos with --missing and deduce some things about their topology.
[06:45] <quicksilver> lifeless: like, which ones have already been merged into "mainline", and which of the non-merged ones shared common parents, etc
[06:46] <quicksilver> lifeless: are you aware of any prior art?
[06:51] <lifeless> quicksilver: bzr removable
[06:53] <Kamping_Kaiser> lifeless: looks like its a stray space. whats the preferred way of submitting trivial changes? patch? bzr branch?
[06:57] <quicksilver> lifeless: thanks. Interesting. I had slightly more ambitious plans but that's definitely the basic function.
[07:01] <Kamping_Kaiser> (used a patch :))
[07:24] <lifeless> Kamping_Kaiser: 'whatever works'
[07:50] <lifeless> poolie: the apt-cache policy bug is committed to apt trunk
[07:51] <poolie> great
[07:55] <lifeless> very small patch for being open for 5 years :(
[07:55] <poolie> many are
[07:55] <poolie> i'd like to do a scatterchart of (open_time,close_time)
[08:00] <ejat> hi .. anyone can help me with this bug 524269
[08:03] <naoki_> Hi
[08:03] <naoki_> http://paste.ubuntu.com/379585/
[08:04] <naoki_> bzr branch svn+ssh://...  fails on Windows.
[08:07] <naoki_> I think it isn't a bug of bzr-svn.
[08:14] <ejat> lifeless: thanks for changing the description .. so confirm its a bugs ?
[08:17] <lifeless> ejat: doubt it
[08:18] <lifeless> ejat: I suspect you're missing ca-certificates or something
[08:19] <naoki_> I read strace. All opened fd is closed correctly.
[08:19] <naoki_> I can't find a suspect.
[08:20] <poolie> naoki_: hello!
[08:20] <lifeless> naoki_: disable your virus scanner
[08:20] <poolie> the first error looks like one we fixed recently
[08:21] <poolie> lifeless: you're probably right but that's such a bad thing to have to say :-/
[08:21] <lifeless> naoki_: its not hooking in at a low enough level, so it is interfering with normal system calls
[08:21] <lifeless> poolie: it is; I blame microsoft.
[08:23] <ejat> lifeless: sorry .. after upgrade .. im missing the bzr-svn .. after reinstall bzr-svn .. working fine
[08:26] <ejat> lifeless: can i change the status to invalid ?
[08:27] <lifeless> I hope so
[08:29] <poolie> lifeless: i mean other apps must hit this
[08:29] <poolie> writing a file then reading it is not such a strange thing to do
[08:30] <poolie> perhaps we should show a message and block
[08:30] <lifeless> poolie: sure
[08:41] <naoki> In linux, strace shows close() correctly.
[08:41] <naoki> But in Windows, Process Monitor desn't show CloseFile!
[08:42] <poolie> interesting
[08:43] <naoki> http://paste.ubuntu.com/379598/
[08:44] <naoki> In line 86, CreateFile failse. (rename)
[08:44] <naoki> In line 85, WriteFile happens to pack file.
[08:45] <naoki> There are no CloseFile between line 85 and 86.
[08:45] <naoki> http://paste.ubuntu.com/379599/
[08:46] <naoki> This is strace in Linux.
[08:47] <naoki> write(7, "E", 1) is writing 1 byte.
[08:47] <naoki> next, close(7), and then, rename() happens.
[09:14] <lifeless> poolie: I've fixed the sort performance in testresources
[09:14] <poolie> mm i saw
[09:15] <poolie> i wonder if the effort estimates are actually accurate enough that it's worth sorting carefully
[09:20] <lifeless> poolie: well, it takes 0.02 seconds to sort for u1 now
[09:20] <lifeless> so there is room to grow :P
[09:20] <lifeless> anyhow, its not sorting carefully now
[09:20] <lifeless> its sorting quickly
[09:42] <lifeless> poolie: you might find http://www.youtube.com/watch?v=1HatEDkNnn8 and the related videos interesting
[09:51] <poolie> igc, you really don't have to finish the explorer bug tonight
[10:08] <jelmer> Kamping_Kaiser, it needs disabling when subvertpy is built against svn < 1.5
[10:10] <Kamping_Kaiser> jelmer: <= or < ? I thought i had 1.5.1, since its a stable system
[10:10] <jelmer> Kamping_Kaiser, <
[10:10] <Kamping_Kaiser> hmm. most odd.
[11:11] <naoki> I want subvertpy binary package...
[11:11] <jelmer> naoki: for windows you mean?
[11:11] <naoki> Yes
[11:11] <jelmer> naoki: Isn't subvertpy included in the windows installer?
[11:12] <naoki> Yes. But I test bzr-svn with python2.6 and python2.5 I have.
[11:12] <naoki> Yes. But I'd like to test bzr-svn with python2.6 and python2.5 I have.
[11:19] <naoki> Wow! I can build subvertpy!
[11:23] <naoki> I can reproduce svn+ssh: problem with Python 2.6...
[11:25] <jelmer> which problem?
[11:28] <naoki> In Windows, bzr branch svn+ssh://.../foo foo fails.
[11:28] <naoki> svn+http is OK. In Linux, all OK
[11:29] <naoki> traceback is http://paste.ubuntu.com/379585/
[11:29] <naoki> strace in Linux is http://paste.ubuntu.com/379598/
[11:29] <naoki> Procmon in Windows is http://paste.ubuntu.com/379599/
[11:29] <naoki> In Linux, close() called after last 1-byte write()
[11:30] <naoki> In Windows, CloseFile() isn't called after last 1-byte WriteFile()
[11:31] <naoki> So rename() fails.
[11:36] <jelmer> naoki: that doesn't seem related to bzr-svn
[11:36] <jelmer> it happens deep down in bzrlib (though it's perhaps masking another error from bzr-svn)
[11:37] <lifeless> naoki: have you tried turning off your virus scanner? just to see?
[11:40] <naoki> I've disabled auto-protect feature in AntiVirus. But I can't totally disable AntiVirus because I am using my company's PC.
[11:41] <lifeless> the lack of a close is interesting though
[11:41] <lifeless> perhaps a generator in the svn side not completing appropriately
[12:20] <radoe> jelmer: is the usage of --layout=trunkX (like trunk2) documented somewhere?
[12:26] <jelmer> radoe: What layouts are available you mean?
[12:26] <jelmer> "bzr help svn-layout"
[12:28] <radoe> jelmer: no, I had to used --layout=trunk2 to be able to svn-import a somewhat weird svn repo. And Ihad to look into the source to figure this out, as it is not mendtioned anywhere. bzr help svn-layout only mentions trunk without an additional level.
[12:29] <radoe> Hm, my connection has some serios lag, sorry for the typos...
[12:30] <jelmer> the 2 just means two levels of directories before the actual branches
[12:34] <radoe> jelmer: yes, I figured this out, but had to look into the sources to get it. And I'm not sure why I had to use it anyway, because my trunk/branches are directly below the URL I specified. Let me explain about layout used in SVN a bit...
[12:36] <radoe> jelmer: The repo root used is svn+ssh://app/svn/instsrv. The repository has a /packages directory, which holds individual packages, like nagios-client
[12:37] <radoe> jelmer: so I tried to svn-import like "bzr svn-import svn+ssh://somehost/app/svn/instsrv/packages/nagios-client"
[12:37] <radoe> jelmer: and got the error  "
[12:38] <radoe> "bzr: ERROR: The specified path is inside a branch."
[12:38] <jelmer> radoe: svn-import imports all branches in a repo or all branches under a specific directory
[12:38] <jelmer> radoe, it looks like you're trying to retrieve an individual branch
[12:38] <radoe> jelmer: i had to specify layout=trunk2, simply trunk did not work (same error)
[12:39] <jelmer> radoe: for an individual branch, use "bzr branch svn+ssh://somehost/app/svn/instsrv/packages/nagios-client nagios-client"
[12:40] <radoe> jelmer: well, like I said, the repo is somewhat weired. It holds different packages below /packages, each with trunk and branches.
[12:41] <jelmer> radoe, what is the repo root?
[12:42] <radoe> jelmer: svn+ssh://somehost/app/svn/instsrv/
[12:43] <jelmer> radoe, does it say it's using trunk2 when it starts?
[12:46] <radoe> jelmer: I had to specify trunk2 explicitly like in "bzr svn-import --layout=trunk2 svn+ssh://rdoering@zsl01/app/svn/instsrv/packages/nagios-client" to get what I want.
[12:46] <jelmer> radoe: Does the repository also have parts that do not follow the branches/tags/trunk convention?
[12:47] <jelmer> or perhaps at different levels?
[12:47] <jelmer> that would confuse the heuristics
[12:48] <radoe> jelmer: possible, let me check...
[12:50] <radoe> jelmer: below /packages/*/ there is always a trunk, only some have a branches/ dir
[12:50] <jelmer> radoe, and packages is the only top-level directory?
[12:51] <radoe> jelmer: no, I'm lookiong at the others currently.
[12:52] <radoe> jelmer: ah, in parallel to /packages there are two directories which qualify for trunk1 layout.
[13:01] <Ng> why would bzr think a file has been removed/added when its md5sum hasn't changed?
[13:02] <Peng> Because you did "bzr rm" and "bzr add"?
[13:02] <Peng> Or an equivalent merge?
[13:02] <Peng> There's more to a file's identity than its contents.
[13:02] <Ng> I'm merging an update from my pristine upstream branch into my local modified branch, but I haven't explicitly rm'd/add'd these files
[13:02] <Ng> normally when I do this it just merges in the upstream changes
[13:03] <beuno> Ng, maybe the merge deletes it?
[13:04] <Ng> http://paste.ubuntu.com/379718/ that's the pristine branch, with a diff of the revision that relates to the bzr import of the new release zip
[13:04] <Ng> skipping down to the bottom of that, version.php - after the merge that change shows up as a full conflict
[13:05] <Ng> not the whole file, just that one line. I'm sure that's within bzr's merging abilities, it always has been before
[13:05] <Ng> I wonder if this is some subtle, barely visible side effect of bzr import
[13:07] <beuno> hm
[13:10] <beuno> james_w may know
[13:11] <james_w> whu?
[13:13] <james_w> Ng: I'm not too sure
[13:14] <james_w> Ng: why do you say bzr thinks a file has been removed/added?
[13:15] <Ng> james_w: hmm, that might actually just be fallout from trying to correct the conflicts. I just branched afresh and did the merge and it looks more like it thinks that lots of files that are already in the branch have been added
[13:16] <naoki> I got it!
[13:16] <naoki> plink.exe have an pack file handle!
[13:16] <james_w> Ng: can you show me the bzr status of the fresh merge?
[13:17] <Ng> james_w: http://paste.ubuntu.com/379723/ is the merge itself, http://paste.ubuntu.com/379724/ is bzr st
[13:17] <moldy> hi
[13:18] <james_w> Ng: it seems like the root id of your tree changed somehow
[13:18] <james_w> that's not usual
[13:18] <moldy> is there decent bzr completion for zsh yet?
[13:18] <james_w> Ng: I assume that you don't do anything odd on your branch, and the pristine branch just uses "bzr import" each new version?
[13:20] <Ng> james_w: correct
[13:21] <james_w> Ng: care to run a couple of bits of python for me?
[13:22] <Ng> james_w: sure :)
[13:23] <james_w> Ng: python -c "from bzrlib.branch import Branch; print Branch.open('.').basis_tree().path2id('')"
[13:23] <james_w> run that in both branches
[13:24] <Ng> james_w: both say TREE_ROOT
[13:25] <james_w> oddness
[13:25] <james_w> Ng: not different tree roots then apparently
[13:25] <james_w> lets try all the file ids changing
[13:25] <james_w> python -c "from bzrlib.branch import Branch; print Branch.open('.').basis_tree().path2id('license.txt')"
[13:26] <james_w> in both again please
[13:26] <Ng> ok those are different
[13:27] <james_w> ok
[13:27] <james_w>  python -c "from bzrlib.branch import Branch; b = Branch.open('.'); rev = b.revision_history()[-2]; print b.repository.revision_tree(rev).path2id('license.txt')"
[13:27] <james_w> that in the pristine branch please
[13:27] <james_w> should print the same as the working branch did
[13:30] <Ng> huh, no, it's still different
[13:33] <Ng> I can make both branches available if that would be helpful, there's nothing secret in either
[13:33] <Ng> I hope the answer isn't that I'm doing something stupid ;)
[13:34] <james_w> I can take a look
[13:34] <james_w> easier than IRC-RPC
[13:35] <Ng> hehe
[13:35] <Ng> http://mairukipa.tenshu.net/~cmsj/bzr-wat.tgz - "www" is the working tree, "wordpress" is the upstream imports
[13:37] <naoki> Ping: jelmer
[13:37] <jelmer> naoki: pong
[13:38] <naoki> I foud ssh client have "upload/xxxxx.pack" handle.
[13:38] <naoki> I tried cygwin ssh and plink (PuTTY)
[13:38] <naoki> Both client have pack file handle.
[13:39] <naoki> bzr branch from svn+ssh success if I kill ssh client before renaming ".pack" file.
[13:40] <naoki> Is there any way to kill source.transport connection before groupcompress?
[13:40] <naoki> Or bzrlib should not rename but copy .pack file?
[13:40] <jelmer> naoki: why would that be necessary?
[13:42] <naoki> Because commit_write_group() renames .bzr/repository/upload/randomname.pack
[13:42] <naoki> So ssh client should not have the handle of the file.
[13:45] <bialix> hi naoki, jelmer
[13:45] <naoki> hi
[13:45] <jelmer> naoki: The ssh client doesn't handle the bazaar packs at all
[13:46] <naoki> I don't know why ssh client have a handle of pack file.
[13:46] <naoki> But procmon tells me the ssh client have the handle.
[13:46] <naoki> And I success to branch when I kill the ssh client.
[13:48] <bialix> naoki, can you convert your patch for unicode Popen to merge proposal?
[13:48] <bialix> this is related to bzrlib
[13:49] <naoki> Okey, I'll do. bialix
[13:49] <bialix> naoki: about SSH: do you have a real reasons to prefer plink over pageant?
[13:50] <naoki> I use pagent daily. So I set SVN_SSH=plink.
[13:50] <naoki> Is there way to use paramiko with ssh?
[13:51] <naoki> I've tried http://sshwindows.sourceforge.net/
[13:52] <naoki> But ssh.exe also grip a handle of pack file.
[13:52] <bialix> sorry, I meant paramiko
[13:52] <naoki> Very very strange..
[13:53] <bialix> svn has no pack files, right?
[13:53] <naoki> Procmon tells me only ssh client have the handle when renaming.
[13:54] <naoki> # I added "time.sleep(100)" in front of rename()
[13:54] <jelmer> naoki: It's inheriting handles from the parent process perhaps?
[13:56] <naoki> Oh
[13:56] <naoki> How libsvn sucks!
[13:58] <jelmer> naoki: I don't know, just speculating
[14:02] <naoki> Can paramiko do port forward?
[14:03] <naoki> sorry, port forward cant convert svn+ssh://remotehost to svn://localhsot
[14:04] <jelmer> naoki: you can't use paramiko for svn+ssh
[14:04] <jelmer> naoki: you need to have a ssh executable
[14:04] <jelmer> naoki: svn and svn+ssh are different protocols
[14:04] <james_w> Ng: so, there's something a little odd going on here
[14:04] <james_w> Ng: I can't pinpoint any bugs. Is there a chance you had this happen before and dealt with it?
[14:05] <maxb> *blink* Why can't you use paramiko for svn+ssh?
[14:06] <Ng> james_w: it's not impossible, but I don't immediately remember anything obviously weird happening previously
[14:06] <james_w> Ng: ok
[14:06] <james_w> Ng: something a bit odd happened when you merged the last couple of versions, but I can't really work out what
[14:09] <jelmer> maxb: Because we call out to libsvn
[14:09] <jelmer> maxb: and that just invokes ssh.exe
[14:09] <maxb> oh, I see
[14:10] <Ng> james_w: thanks for looking. If it was you, would you manually fix up this merge and keep using these branches, or reconstruct the working one from a fresh copy of the pristine branch?
[14:10] <james_w> Ng: I'd fix up
[14:11] <james_w> Ng: have you modified any of the files that it is complaining about?
[14:12] <Ng> james_w: I don't think so. I can imagine I might previously have removed things like license.txt, but I shouldn't have any changes in the php/css stuff
[14:12] <james_w> you did remove license.txt :-)
[14:12] <james_w> in that case it's pretty much in the situation you want moving forwards
[14:12] <james_w> as merges from the pristine branch should be much more happy now
[14:14] <Ng> james_w: ok, thanks :)
[14:15] <naoki> afk
[15:16] <naoki_> apr_proc_create uses CreateProcessW(bInheritHandles=TRUE)
[15:16] <naoki_> libapr/threadproc/win32/proc.c
[15:17] <naoki_> libsvn uses this function.
[15:24] <naoki_> http://msdn.microsoft.com/en-us/library/ms682499%28VS.85%29.aspx
[15:25] <naoki_> Inheriting handles is required for pipe.
[15:25] <naoki_> So, libsvn and libapr is not wrong.
[15:28] <naoki_> One option is killing connections before commit_write_group().
[15:30] <naoki_> Second option is pooling enough connections before start_write_group()
[15:30] <naoki_> Any other solutions?
[15:47] <jelmer> naoki: we shouldn't kill connections before commit write group, there might be more actions the user would like to do
[15:47] <jelmer> Why would pooling connections before start write group help?
[15:53] <naoki_> when start write group, bzr creates pack file.
[15:53] <naoki_> A handle of the pack file is inherited to ssh client process.
[15:54] <naoki_> When commit_write_group, bzr renames the pack file.
[15:54] <naoki_> ssh client blocks renaming.
[16:11] <jam> naoki: if you set BZR_SSH=paramiko it will use pageant as well
[16:11] <jam> and avoid spawning a separate process
[16:11] <jam> ah, but jelmer is saying you need an actual ssh process...
[16:11] <jelmer> you can set BZR_SSH but that will just be ignored :-)
[16:13] <jam> naoki_: what about a pre-exec function that closes the extra file handles
[16:13] <jam> all you need is stdin/stdout, right?
[16:14] <naoki_> libsvn creates ssh process. We cannot control it.
[16:15] <jam> well, we could have an ssh wrapper
[16:15] <jam> jelmer: does it need something explicitly called 'ssh' ?
[16:16] <jelmer> you can set a different executable in ~/.subversion/config
[16:20] <naoki_> or SVN_SSH environment
[16:21] <naoki_> But how the wrapper release handles?
[16:21] <jam> naoki_: so we could set SVN_SSH before we call out to svn+ssh
[16:22] <jam> naoki_: well, given that there is a program that can ask Windows what program has what files open, I'm sure you can enumerate your own file handles
[16:22] <jam> I don't know the functions
[16:23] <jam> this: http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/37dc9843-2583-41fc-8260-b78183aa4bed
[16:23] <jam> says there is NtQuerySystemInformation
[16:25] <jam> also: http://stackoverflow.com/questions/733384/how-to-enumerate-process-handles
[16:26] <jam> naoki_: possibly we could also open the file handle with "DELETE_OK" and possibly a rename-ok?
[16:28] <jam> it seems surprisingly ugly: http://www.techreplies.com/development-resources-58/enumerating-handles-processes-c-like-procxp-782021/
[16:53] <naoki_> How about try rename, catch PermissionDenied, and then copy instead of rename?
[16:55] <slicslak> any macosx users here?  should I d/l bzr or use macports?  i prefer macports but I don't want to use it if the port isn't maintined well (It appears to be a few versions behind atm)
[16:55] <naoki_> In NewPack.finish()
[17:00] <naoki_> http://paste.ubuntu.com/379852/
[17:04] <mobby> Hi, sorry if this is the wrong place to ask this so feel free to point me in the direction (politely ;-) but I would like to know a bit more about co-located branches Bazaar.
[17:05] <mobby> I don't know anything about co-located branches so you will have to have some patience :)
[17:06] <mobby> Really my question is... How do colocated branches work? Or more specifically as a developer how would I use co-located branches day-to-day
[17:07] <rubbs> mobby: I'm not an expert, and I"m not too sure how they would work in Bzr, but colocated branches allow for multiple branches within the same directory
[17:07] <jam> naoki_: given that the file may be >>GB in size, I'm not particularly happy with that solution, but it would be possible
[17:07] <jam> when does it get deleted, though?
[17:07] <rubbs> git does this by having all of the repo information in one directory and you "switch" between the different branches.
[17:08] <rubbs> mobby: every time you switch you reload the working tree.
[17:08] <mobby> ah rubbs that the bit that I was really wondering about
[17:08] <rubbs> mobby: IIRC it would also let you have a project within a project.
[17:08] <jam> mobby: so the way *I* do it isn't exactly colocated. I set up a shared treeless repository (bzr init-repo --no-trees) and then a single working tree (bzr co --lightweight trunk work)
[17:08] <jam> and that point you can create new branches cheaply
[17:08] <jam> and switch between them
[17:08] <jam> the colo: plugin does something akin to this
[17:08] <jam> only puts the branches under a new namespace "colo:" and hides them under .bzr/branches IIRC
[17:09] <rubbs> jam: just curious is this also the answer to the "externals" question?
[17:09] <jam> the main reason I prefer not having them colocated
[17:09] <jam> is that I can have *multiple* working trees sharing the same set of branches
[17:09] <mobby> yeah I saw the colo plugin, which intrigued me but I couldn't find much information for what it was all about and hence me coming here
[17:09] <jam> which I use fairly often
[17:09] <jam> I have a 'work' which is my primary action item, and then an 'alt_work'
[17:10] <jam> So if I work on a bugfix, and submit it for review, I'm on to the next
[17:10] <jam> but the review needs some minor tweaks before landing
[17:10] <jam> so alt_work gets switched, fixed, submitted
[17:10] <jam> without disturbing the current work
[17:11] <jam> rubbs: do you mean bzr-externals ?
[17:11] <rubbs> jam: ah, I haven't looked into that recently. I'll go check it out.
[17:14] <mobby> so I suppose the co-located branch thing works best with branches of the same project rather than branches of differing projects?... I have a feeling I might have asked a stupid question there...
[17:15] <rubbs> mobby: not a dumb question because I was a little confused. it works best with branches of the same project.
[17:15] <mobby> ah ok cool. thanks.
[17:15] <rubbs> np
[17:16] <jam> mobby: 'it works best' because switching a tree to an unrelated one takes a lot of effort
[17:16] <jam> otherwise we don't specifically care
[17:16] <mobby> so rather than having folder upon folder of branches for each bit of work you are doing you can just have one folder which is the working tree and when you swicth branches the working tree files are updated to reflect that branch?
[17:16] <jam> mobby: right
[17:16] <rubbs> mobby: correct
[17:17] <rubbs> jam: you beat me to it ;)
[17:17] <jam> (with or without the colo: plugin, as mentioned)
[17:17] <mobby> ah great thanks! Yeah that does sound good.
[17:17] <rubbs> mobby: I believe it was created to reflect a more git-like workflow.
[17:17] <rubbs> and that is the way git works (more or less)
[17:17] <mobby> so I suppose if you had uncommitted changes in the working tree, if you switched you would lose those changes (if it doesn't warn you)?
[17:18] <jam> mobby: generally it preserves them
[17:18] <jam> with the idea that you may be switching to a new branch to put those changes
[17:18] <jam> (like a bugfix, etc)
[17:18] <rubbs> mobby: if it doesn't do what you want, you could potentially use shelve to get around the default behavior
[17:19] <mobby> yeah sorry my VCS knowledge is pretty much reserved to CVS and SVN as that is what I've been using in working life. I decided that I would look into others, found Bazaar and think it is really very good. Thus I;ve been trying to improve my knowledge of Bazaar and its capabilities
[17:19] <mobby> oh that;s cool it preserves them
[17:20] <mobby> thanks guys for your help.
[17:20] <rubbs> mobby: don't apologize for learning ;) I just thought I'd point that part out, didn't mean to make you feel ignorant.
[17:20] <rubbs> np
[17:22] <awilkins> SVN does switching between branches, but it's merging is painful
[17:22] <mobby> no you didn't make me feel ignorant at all, I've learnt a lot in just a few mins :)
[17:23] <mobby> yeah that's the other thing even my SVN knowledge is fairly limited as works process has not required further investigation into features
[17:23] <rubbs> good to hear! I think I can speak for both jam and myself when I say we like to help people learn about bzr.
[17:24] <mobby> I started trying to think of better ways of working, started learning about Bazaar, found out what VCS's can do (and realised how little I knew) and I've enjoyed using bazaar. I'm just trying to get as confident with it as possible so I can recommend its use in the compant i work for
[17:25] <aleksander_m> does 'bzr send -o patch.merge' include always by default the patch preview?
[17:25]  * awilkins now has to install Vista (sob)
[17:26] <naoki_> os.O_NOINHERIT avoids HANDLE inheritance
[17:26] <aleksander_m> the mini-tutorial says that it 'usually' contains the patch preview, but I cannot get it included
[17:28] <mobby> Thanks again for the help guys. Bye.
[17:33] <jam> naoki_: I thought you had to inherit handles to get pipes
[17:37] <james_w> hi jam
[17:37] <jam> hey james_w
[17:37] <james_w> I'd like to merge https://code.edge.launchpad.net/~jameinel/bzr-builddeb/changelog-parser/+merge/18557 but I don't understand one of the comments in the file
[17:38] <jam> k
[17:38] <james_w> there's a comment in there asking about it
[17:39] <jam> james_w: the strict=True stuff?
[17:39] <jam> so the BASE file is used as a reference
[17:39] <jam> but its content won't ever be put into the final changelog file
[17:39] <james_w> # BASE lines don't end up in the output, so we allow strict=False
[17:40] <jam> james_w: so we determine if THIS or OTHER should be used, based on whether they match BASE
[17:40] <jam> (if one matches BASE, then the other gets chosen)
[17:40] <jam> however, only THIS or BASE content is ever put into the file
[17:40] <james_w> right
[17:40] <jam> my idea was that
[17:40] <jam> if someone went through and cleaned up old content
[17:40] <jam> such that it now passes strict
[17:40] <jam> but didn't used to
[17:40] <jam> then we can still use the advanced merging
[17:41] <james_w> I think that makes sense
[17:41] <james_w> thanks, merging now
[17:42] <jam> james_w: I'm currently testing the md5sum caching logic
[17:42] <james_w> I just used the old code in a merge and got confused by it not conflicting on anything
[17:42] <jam> I have a patch, but want to make sure it works properly
[17:42] <james_w> great
[17:42] <james_w> which approach did you choose>
[17:42] <james_w> the "correct" way?
[17:42] <jam> download .dsc, compare md5sums for files that are on disk
[17:42] <jam> I think that was the correct way
[17:42] <jam> anyway to avoid downloading the .dsc ?
[17:43] <jam> though probably if it requires an extra round trip, we don't win
[17:43] <james_w> not really
[17:44] <james_w> they are small, so yeah, it's just round trip costs
[17:44] <james_w> we should only download a .dsc once though
[17:44] <jam> well, once per run at least
[17:44] <james_w> well, twice for syncs, but yeah, that can't be avoided
[17:44] <jam> ... why did it delete all of the old downloads?
[17:44] <jam> is that the cleanup when finished stuff?
[17:45] <james_w> yeah
[17:45] <jam>  :,(
[17:45] <jam> :'(
[17:45] <james_w> I don't want the entire history of Debian and Ubuntu on jubany
[17:45] <jam> sure
[17:45] <jam> messes with my work, though :)
[17:45] <james_w> you could change it to download in to the updates dir if that's not what it is doing
[17:45] <jam> well, my testing
[17:45] <james_w> then when you use --no-push they will stick around
[17:46] <james_w> and it will then just download the .dsc each time
[17:46] <jam> it downloads into updates, but even with --no-push they went missing
[17:46] <james_w> anyway, changelog merge improvements merged, thanks
[17:46] <james_w> ah, maybe there's a finally block at a lower level too
[17:46] <james_w> that's probably worth removing once we have the cache
[17:47] <james_w> that's a win wherever it is used
[17:47] <jam>         if commit_db.has_commit_started():
[17:47] <jam>             revid_db.cleanup_last_run(cleanup, push_back)
[17:47] <jam>             commit_db.finish_commit()
[17:47] <jam> that cleanup includes an rmtree
[17:47] <james_w> oh, yeah, so not a win
[17:47] <james_w> we could make the cleanup smarter then
[17:51] <jam> james_w: so how does that all work. You have  a global sqlite file, and if you start working on a package import, but don't finish it, the next run you nuke the wohle directory?
[17:51] <jam> what is the rationale?
[17:51] <jam> just that you can't trust the intermediate steps?
[17:51] <james_w> yeah
[17:52] <james_w> I wasn't confident that the work wouldn't be in some inconsistent state
[17:52] <james_w> if bzr is atomic, and bzr-builddeb makes use of that in the correct way then we could just carry on
[17:52] <james_w> but I wasn't confident in that
[17:53] <jam> genearlly bzr is atomic
[17:53] <jam> generally
[17:53] <jam> however, I also see this:
[17:53] <jam> if push :commit_db.start_commit()
[17:53] <jam> with *no* matching finish_commit()
[17:53] <jam> argh
[17:53] <jam> I missed the else:
[17:54] <jam> http://paste.ubuntu.com/379881/
[17:54] <jam> so it seems that when starting, we nuke the old content
[17:54] <jam> unconditionally
[17:54] <jam> either we first rollback, and then nuke it
[17:54] <jam> or we just nuke it
[17:55] <james_w> cleanup_last_run is misnamed
[17:55] <james_w> it's finish then cleanup
[17:55] <james_w> I think
[17:55] <jam> well, it checks if there are rows in the db
[17:55] <jam> and if there are or aren't it calls cleanup_cb()
[17:55] <jam> so all code paths lead to cleanup
[17:55] <jam> which rmtree(updates/<PACKAGE>)
[17:56] <james_w> ah, yeah, we always cleanup
[17:56] <james_w> you're right
[17:56] <james_w> which would interfere with any caching of the packages
[17:56] <naoki_> I've made patch and report bugs
[17:56] <naoki_> https://bugs.launchpad.net/bzr/+bug/524560
[17:56] <jam> well, at least it shouldn't re-download files in a single run
[17:56] <jam> which is better for me
[17:56] <jam> but it would be nice to not re-download them between runs, since I'm using --no-push so lp doesn't get updated
[17:56] <james_w> yeah
[17:56] <jam> anyway, test is currently running to at least look for double-downloads of a single import
[17:59] <james_w> ok, all your fixes are on production now
[17:59] <jam> \o/
[17:59] <james_w> including the encoding one
[17:59] <james_w> and it's up and running again
[17:59] <james_w> it's got 2000 nops to churn through though unfortunately
[18:00] <jam> james_w: which.. requires getPublishedSources for all of them?
[18:00] <james_w> yeah
[18:02] <jam> james_w: https://code.edge.launchpad.net/~jameinel/udd/single-download-524123/+merge/19731
[18:09] <james_w> jam: merged, thanks
[18:13] <pynonoir> Hi. If I replace a normal directory with bazaar branches, by a shared repository with the same branches inside (same path for bzr+ssh), will my users have some problems when pulling/pushing ?
[18:13] <jam> james_w: thanks
[18:14] <jam> pynonoir: you should be fine
[18:14] <Kinnison> as long as the urls to the branches don't change, you should be fine
[18:14] <jam> only possible problems would be perms
[18:14] <Kinnison> oh true; permissions if this is multiple unix users
[18:14] <pynonoir> there are indeed multiple users
[18:15]  * Kinnison typically doesn't expect repositories to be shared between users
[18:15] <Kinnison> unless you *really* need the space savings, I'd say it wasn't worth the risk
[18:16] <pynonoir> Kinnison: that was more to save bandwidth
[18:16] <Kinnison> hmm
[18:17] <Kinnison> in what sense?
[18:17] <Kinnison> give me a use-case in which you expect bandwidth to be saved
[18:17] <Kinnison> (I'm not very well today; so forgive me if I'm a touch slow :-)
[18:19] <pynonoir> mmm, if there is a branch called A on the distant server. Then one of my users make a clone (bzr branch), do some modifications and then push it as a new branch on the distant server
[18:19] <pynonoir> maybe only the delta can be sent if it pushed on a shared repo ?
[18:22] <Peng> If each user has a separate shared repo, you should still get most of the bandwidth savings..
[18:22] <pynonoir> Peng: good idea, I will do this
[18:22] <pynonoir> thanks
[18:23] <Kinnison> and that will negate any user permissions issues too :-)
[19:57] <Lo-lan-do> Hi all.  What to do if bzr check tells me about sha1 mismatches?
[19:58] <fullermd> Flip a bit at a time until they match?   8-}
[19:59] <Lo-lan-do> Haha.
[20:00] <Lo-lan-do> And seriously?  Should I worry, or is it a harmless warning that should be marked as such?
[20:01] <james_w> I doubt it is harmless
[20:03] <james_w> unfortunately I don't know how to dig deeper
[20:03] <Lo-lan-do> Will bzr reconcile fix them?
[20:03] <james_w> I'm not sure about that either
[20:03] <james_w> you could file a bug/question
[20:03] <rubbs> it wouldn't hurt, but doubt it would fix it.
[20:03] <lifeless> Lo-lan-do: please file a question
[20:04] <lifeless> if the data is private, file a private bug
[20:05] <Lo-lan-do> lifeless: ?
[20:05] <lifeless> if the error message contains data that you feel is confidential, you can't get privacy on answers.lp
[20:05] <lifeless> but you can in bugs
[20:06] <Lo-lan-do> Oh, I see.  Launchpad.
[20:08] <Lo-lan-do> No questions unless I register?
[20:09] <lifeless> yes
[20:09] <lifeless> if you don't want to register, you can mail the list
[20:11] <Lo-lan-do> I'll do that, thanks.
[20:44] <mkanat> mwhudson: Have there been any more hangs?
[21:16] <mwhudson> mkanat: don't think so
[21:36] <james_w> Lo-lan-do: what are the messages exactly?
[21:37] <james_w> perhaps others have seen them before or know what they will refer to, but I don't
[21:59] <Lo-lan-do> sha1 mismatch: ('6500@9d84d37e-dcb1-4aad-b103-6f3d92f53bf6:trunk%2Fgforge%2Fwww%2Fplugins%2Ffckeditor', 'svn-v4:9d84d37e-dcb1-4aad-b103-6f3d92f53bf6:trunk:6500') has sha1 9287ea6b641b2676b769ce316258446d8f20f4fd expected da39a3ee5e6b4b0d3255bfef95601890afd80709 referenced by<EMAIL_ADDRESS>[22:05] <_TiN_> Hi, what is the solution to serve bazaar, with apache? I'm trying to add support for bzr-vcs in http://trac.usla.org.ar
[22:07] <james_w> Lo-lan-do: aha, bzr-svn, that changes things a little. I'm still no closer to knowing if it's a problem or what to do about it though.
[22:08] <mneptok> _TiN_: http://doc.bazaar.canonical.com/bzr-0.15/http_smart_server.htm
[22:08] <mneptok> _TiN_: note the strongly worded "this is NOT secure!" bit
[22:08] <Lo-lan-do> james_w: I'm re-running check, will paste output into a mail if it helps.
[22:09] <lifeless> mneptok: that warning is gone now
[22:09] <james_w> Lo-lan-do: good idea, it might clue some people in
[22:09] <lifeless> mneptok: please ref current docs
[22:10] <jam> james_w: the packaging script was stopped for a while, right?
[22:10] <jam> I just ran hottest-100 and got about 5 branches moved from 'ok' to 'packaging-out-of-date'
[22:11] <james_w> jam: yeah
[22:11] <james_w> just catching up now
[22:11] <jam> well, as of 2 hrs ago
[22:11] <jam> k
[22:12] <mneptok> lifeless: couldn't find CURRENT for FastCGI setup. but PEBKAC is more than likely to blame.
[22:12] <_TiN_> mneptok: I'm trying with fcgi and mod_python and doesn't work, I suspect bazaar is not generating correctly the app
[22:13] <lifeless> mneptok: http://doc.bazaar.canonical.com/latest/en/user-guide/http_smart_server.html
[22:13] <lifeless> 'fast cgi bzr' into google
[22:13] <mneptok> _TiN_: is mod_python actually loaded as a module in your Apache configs?
[22:14] <_TiN_> mneptok: iep, In this tracs i have svn hg git
[22:14] <mneptok> _TiN_: FYI, i have never set up bzr+apache, so i'm not the best resource. please click that URL lifeless pasted.
[22:15] <mneptok> _TiN_: if you read that document, it's "the blind being led by the sighted." if you ask my advice, it's "the blind being led by the blind idiot." :)
[22:22] <jam> lifeless: it looks like we need to strip some zeros out of our sha1 strings (bug #524553)
[22:22] <jam> :)
[22:23] <lifeless> jam: oh did you get an answer to it? my mail is closed...
[22:23] <jam> lifeless: he was getting "abcd0fgh..." and we were saying "abcd000fgh", of course his sha1 strings were only 35 chars long
[22:24] <lifeless> ! where was he getting the truncated one from ?
[22:24] <jam> I'm pretty sure it amounts to using '%x' versus '%08x' sort of thing
[22:24] <jam> lifeless: I have no clue, custom code I would assume
[22:24] <lifeless> heh
[22:26] <fullermd> It was compressed.  Space savings are important.
[22:28] <jam> fullermd: of course, the next step is to get a collision under these circumstances
[22:30] <fullermd> Pshaw.  Everybody knows hashes don't collide.  I checked every file in my home dir, and none of the hashes were even close.


[13:59] <lucas-arg> hey guys.... where can i find new mate themes?
[16:52] <superkuh> https://www.mate-look.org/
[16:53] <superkuh> Oh, way too late.


[04:10] <andresj> hello. anybody here? :)
[04:11] <ScottK-laptop> Nope.
[04:11] <andresj> haha
[04:12] <andresj> hey I'm trying to package the latest versions of lyx in my PPA; but I'm running into problems.
[04:12] <andresj> I could upload 1.5.6 (only source change, no debian/ dir changes) for intrepid to launchpad, and it worked well
[04:13] <andresj> but when I run pbuilder locally on a package for hardy, it cant find some dependencies
[04:13] <andresj> the thing is, those dependencies are in hardy RELEASE
[04:14] <andresj> (whilst lyx-1.5.5 is in hardy-backports)
[04:16] <ScottK-laptop> You pbuilder probably doesn't have backports in it's sources.
[04:16] <ScottK-laptop> You/Your
[04:17] <andresj> that could be... but does it matter? the packages it says are virtual (e.g. Depends: libboost-test-dev which is a virtual package.) all come from boost source package, which changelog says is in "hardy", not "hardy-backports"
[04:18] <andresj> * ScottK-laptop
[04:18] <ScottK-laptop> Ah.
[04:21] <ScottK-laptop> andresj: What version of boost do you want?
[04:22] <ScottK-laptop> Yeah, there aren't any in backports
[04:23] <danbhfive> anyone here that can help me with debugging a c project's compile errors?
[04:23] <andresj> ScottK-laptop: any that works :P >= 1.34.1 the package seems to say
[04:23] <ScottK-laptop> Which hardy has.
[04:24] <andresj> exactly.
[04:24] <andresj> I don't see why pbuilder fails
[04:24] <andresj> telling me they're virtual
[04:24] <ScottK-laptop> It's not a virtual package either.
[04:24] <ScottK-laptop> I suspect a pbuilder bug.
[04:24] <wgrant> Perhaps the pbuilder lacks universe?
[04:24] <ScottK-laptop> boost is in Main
[04:25] <wgrant> So it is.
[04:25] <ScottK-laptop> andresj: There is more than one way to get pbuilder to try and satisfy dependencies.
[04:25] <andresj> ScottK-laptop: I am completely lost regarding that sentence.
[04:25] <m8i-freya> Could I ask some question about packaging? If I found some bug in the "debian" directory comes from svn, should I report to upstream?
[04:26] <ScottK-laptop> andresj: pbuilder has to figure out what packages you need to build with.
[04:26] <andresj> of course
[04:26] <ScottK-laptop> There's more than one set of methods it has to do that.
[04:26] <andresj> mm... ok...
[04:26] <ScottK-laptop> I find the current default method somewhat problematic.
[04:26] <ScottK-laptop> IIRC I got errors like that.
[04:27] <andresj> mm... how do I change it, then?
[04:27] <ScottK-laptop> So I'm going to suggest you change it.
[04:27] <ScottK-laptop> I'm looking that up.
[04:27] <ScottK-laptop> It's been a while since I've done it.
[04:28] <andresj> hahaha ok
[04:29] <ScottK-laptop> andresj: You'll need to edit /etc/pbuilder/pbuilderrc
[04:30] <ScottK-laptop> andresj: There's a line that starts PBUILDERSATISFYDEPENDSCMD=
[04:30] <ScottK-laptop> andresj: Make it say: PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-classic"
[04:30] <ScottK-laptop> I'm not sure that will help, but it's helped me when I had problems like yours in the past.
[04:30] <andresj> mm... ok ill try that :) thanks.
[04:33] <andresj> still telling me that libboost-filesystem-dev is not available. :/
[04:33] <andresj> oh thats in universe!
[04:33] <andresj> ScottK-laptop: do u know how to add universe to pbuilder?
[04:34] <ScottK> andresj: Sorry, I'm exhausted and off to bed.
[04:34] <andresj> hahaha
[04:34] <andresj> thats ok thanks for your help :)
[05:17] <andresj> hey any idea why a specific requeriment was added to my package when debian/control doesn't say that? More specifically, lyx-1.5.6~ppa1~hardy1 has Build-Depends:  libboost-dev (>= 1.34.1),  libboost-filesystem-dev, libboost-signals-dev, libboost-regex-dev (among others), but Dependencies in aptitude appear: libboost-filesystem1.34.1 (>= 1.34.1-8), libboost-regex1.34.1 (>= 1.34.1-8), and libboost-signals1.34.1 (>= 1.34.1-8) none o
[05:18] <RAOF> andresj: dpkg-shlibdeps magic.
[05:19] <andresj> RAOF, oh I see... but I only have 1.34.1-4 in enabled repositories, I don't know where 1.34.1-8 came from... (I am using PPA)
[05:19] <RAOF> Apparently 1.34.1-8 is the last time that the ABI was added to.  Alternatively, because it's crazy C++, they might just bump the shlibs each revision.
[05:20] <RAOF> andresj: Where are you building it?  Because it'll pick up the dependencies from where you build it.
[05:20] <andresj> RAOF, on launchpad, in a PPA
[05:21] <RAOF> Presumably actually building in a hardy context?
[05:21] <andresj> RAOF: well, the package is distribution hardy, if that's what you mean
[05:22] <andresj> (I mean, not only in the version number)
[05:22] <RAOF> Right.  I'm not sure if PPAs build against backports?  Maybe that's it?
[05:22] <andresj> RAOF, does that mean the package won't build? it did, though.
[05:23] <andresj> i have binaries, and I added my PPA to my sources.list, and tried installing lyx through aptitude
[05:23] <RAOF> The package obviously built, and is picking up those dependencies from the packages installed during the build process.
[05:24] <andresj> now, where does packages come from? I have all checkboxes marked in my Software Sources dialog
[05:26] <RAOF> Can you pastebin the build log?
[05:26] <andresj> RAOF, you mean from the PPA? It already has an URL: http://launchpadlibrarian.net/17331201/buildlog_ubuntu-hardy-i386.lyx_1.5.6-0ubuntu1%7Eppa3%7Ehardy1_FULLYBUILT.txt.gz
[05:28] <RAOF> andresj: Hm.  The boost libs are all coming from Hardy universe.  I idon't know why you've got crazy dependencies.
[05:30] <andresj> RAOF, yeah, its very wierd. What's even more wierd is that the build log never mentions 1.34.1-8; only 1.34.1-4 (for libboost-filesystem, that is)
[05:31] <RAOF> Right.  I dunno.
[05:31] <andresj> whats more, it specifically says that the pkg depends on libboost-filesystem1.34.1 (>= 1.34.1-2.1)...
[05:31] <andresj> thats extremely wierd
[05:31] <andresj> well thank you for your help RAOF :)
[05:32] <andresj> oh!!
[05:32] <andresj> lol
[05:32] <andresj> i added my PPA for intrepid, not for hardy
[05:33] <andresj> 'tupid 'tupid!
[05:33] <andresj> :P
[05:33] <RAOF> HEh.
[05:53] <andresj> OK, so now I have packages for LyX 1.5.6 in my PPA. I think this almost fixes the bug https://bugs.edge.launchpad.net/ubuntu/+source/lyx/+bug/253196 (Bugfix upstream release of Lyx (1.5.6)). All that is needed is for the package to be put into the official distribution.
[06:49] <jscinoz> yay revu is broken again
[06:49] <jscinoz> http://revu.ubuntuwire.com/details.py?package=google-gadgets
[06:49] <jscinoz> fail.
[08:18] <RAOF> Hm.  Any motu-release around?
[08:19] <RAOF> I'd like to get an FFe for gnome-do + gnome-do-plugins; do you want 2 separate bugs for that, or just one?  -plugins is useless without the first, and gnome-do is fairly useless without -plugis.
[08:46] <NCommander> RAOF, gnome packages had a freeze exception already I thought
[08:46] <RAOF> Do isn't a GNOME package.
[08:46] <NCommander> oh
[08:46] <NCommander> d'oh
[08:47] <RAOF> I don't suppose anyone said anything ueful while I was punched off the internest?
[08:50]  * RAOF wonders how long he'll stay on the net this time.
[09:04] <DKcross> RainCT,
[09:04] <DKcross> estas ahi?
[09:04] <DKcross> alguien anda por aqui?
[09:05] <DKcross> necesito una ayuda porfavor
[09:05] <Hobbsee> RAOF: i'd say together.
[09:05] <Hobbsee> RAOF: i could ack it, technically, but...
[09:06] <DKcross> hi
[09:06] <DKcross> can help me man?
[09:06] <DKcross> i have problems. with package
[09:07] <DKcross> Hobbsee,
[09:07] <NCommander> morning Hobbsee
[09:07] <Hobbsee> hey NCommander
[09:07] <Hobbsee> DKcross: yes?
[09:08] <DKcross> help me please
[09:08] <Hobbsee> DKcross: with?
[09:08] <DKcross> packaging
[09:08] <DKcross> dpkg-source: construyendo emesene en emesene_1.0.1-1.dsc
[09:08] <DKcross>  debian/rules build
[09:08] <DKcross> test -x debian/rules
[09:08] <DKcross> mkdir -p "."
[09:08] <DKcross> /usr/bin/make  -C . CFLAGS="-g -O2 -g -Wall -O2" CXXFLAGS="-g -O2 -g -Wall -O2" CPPFLAGS="" LDFLAGS="-Wl,-Bsymbolic-functions"
[09:08] <DKcross> make[1]: se ingresa al directorio `/home/dkito/Preparacion evento/de home/charla/tar conversion/emesene-1.0.1'
[09:08] <DKcross> make[1]: *** No se especificó ningún objetivo y no se encontró ningún makefile.  Alto.
[09:08] <DKcross> make[1]: se sale del directorio `/home/dkito/Preparacion evento/de home/charla/tar conversion/emesene-1.0.1'
[09:08] <NCommander> DKcross, please do not flood the channel
[09:08] <DKcross> make: *** [debian/stamp-makefile-build] Error 2
[09:08] <DKcross> dpkg-buildpackage: fallo: debian/rules build entregó error de estado de salida 2
[09:08] <DKcross> dkito@dk-System:~/Preparacion evento/de home/charla/tar conversion/emesene-1.0.1$
[09:08] <NCommander> DKcross, post the logs/output on paste.ubuntu.com
[09:08] <Hobbsee> *pastebin*.
[09:09]  * wgrant makes some gurgling noises, then asphyxiates.
[09:09] <NCommander> ah crud, I missed the MOTU meeting
[09:09]  * NCommander pokes wgrant's dead body with a stick
[09:09]  * wgrant rots.
[09:09] <Hobbsee> NCommander: seeing as no one really bothered to attend it (again), then...you didn't miss much
[09:09] <DKcross> what is the problem?
[09:09]  * NCommander shoves wgrant corpse in a blender for quick and easy disposal
[09:10]  * Hobbsee doesn't read whatever language that is.
[09:10] <slangasek> the problem is your debian/rules doesn't correspond to your upstream sources
[09:10] <NCommander> DKcross, most of us speak english, you'll have to set LC_ALL/LANG to en_US to get the error messages in something we can read
[09:10] <NCommander> or another en setting
[09:10] <slangasek> and is looking for a makefile, which you don't have
[09:10] <Hobbsee> and don't paste the english version in this channel, either!
[09:10] <DKcross> mm
[09:14] <sebner1> siretart: is already someone else working on mlt?
[09:15] <DKcross> i need help:(
[09:28] <siretart> sebner1: not that I know, just assign the bug to you
[09:31] <DKcross> hi
[09:31] <DKcross> need help please
[09:37] <wgrant> DKcross: Why are you trying to repackage emesene 1.0.1 in what is likely a highly inappropriate manner?
[09:39] <DKcross> wgrant,  hola?
[09:39] <DKcross> hi wgrant
[09:42] <DKcross> hola alguien habla español?
[09:42] <wgrant> !es
[09:43] <DKcross> pero necesito ayuda de motu
[09:43] <DKcross> no es problema que este en un canal hablando español
[09:43] <Nafallo> and in English?
[09:44] <DKcross> ubottu, please help me
[09:44] <DKcross> :p
[09:44] <DKcross> Nafallo,  u can help me?
[09:44] <Nafallo> I can help you in Swedish if you want? :-)
[09:45] <DKcross> :o
[09:45] <DKcross> ok thanks
[09:45] <sebner1> DKcross: we can help you in English ;)
[09:45] <Nafallo> the point was you're better off with English. sorry :-)
[09:46] <slangasek> some of us can help in Spanish, but I assume it's considered a faux pas to do so on channel
[09:57] <slangasek> is there a quick tutorial on how to make a python package with cdbs?
[09:58] <tseliot> DKcross: si encuentras a algun motu hispanoablante (por ej. pochu) le podrás hacer preguntas en privado (yo soy italiano y aun no soy motu)
[09:58] <wgrant> slangasek: Module or application package?
[09:58] <slangasek> wgrant: application
[09:59] <DKcross> tseliot,  gracias
[09:59] <DKcross> tseliot, thanks
[09:59] <slangasek> tseliot: he already found one, but I can't offer very good advice in this case
[10:00] <tseliot> slangasek: oh, ¿hablas español? ;)
[10:00] <slangasek> he's trying to do a packaging demo shortly for an ubucon, but is trying to use dh_make to repackage emesene, and this obviously doesn't work out of the box
[10:00] <wgrant> slangasek: There's nothing to it, then.
[10:00] <slangasek> tseliot: entre otros idiomas
[10:01] <wgrant> Um. Isn't dh_make meant to die?
[10:01] <slangasek> meant to by whom?
[10:01] <slangasek> are you thinking of debmake?
[10:01] <wgrant> Anybody with sanity?
[10:01] <tseliot> slangasek: nice. BTW did you have a look at this page? http://wiki.debian.org/DebianPython/NewPolicy
[10:01] <wgrant> Possibly.
[10:01] <POX_> slangasek: I guess the easiest way is to start with files generated with stdeb (http://stdeb.python-hosting.com/, it doesn't use cdbs IIRC, though) or just take a look at one of packages from python-{apps,modules} repo and and then join #debian-python ;)
[10:03] <slangasek> DKcross: the URL that tseliot gives, http://wiki.debian.org/DebianPython/NewPolicy, appears to include a quick example of how to set up CDBS for use with distutils
[10:03] <slangasek> DKcross: and emesene uses distutils
[10:03] <RainCT> morning
[10:03] <DKcross> ok
[10:03] <wgrant> Doesn't one need just a single line, in general?
[10:03] <DKcross> i go :p
[10:04] <DKcross> http://stdeb.python-hosting.com/ this?
[10:04] <DKcross> its http://stdeb.python-hosting.com/
[10:04] <slangasek> DKcross: http://wiki.debian.org/DebianPython/NewPolicy, busca "CDBS + distutils"
[10:04] <_ruben> hmm .. the debian maintainer's guide still lists dh_make as the way to go .. so apparently there's another/better way? ..
[10:04]  * _ruben googles
[10:05] <slangasek> _ruben: dh_make is still what I use for spawning a new package, but I don't package python stuff
[10:05] <slangasek> (I also don't spawn many new packages, either...)
[10:05] <DKcross> ok thanks
[10:05] <_ruben> ive only done a small number of repackaging .. am about to start working on my first 'fresh' package
[10:07] <slangasek> DKcross: and I'm afraid that's all I can do for you, son las dos de la madrugada aqui y ya tengo que dormirme
[10:07] <_ruben> ah .. debmake is an old package .. i thought it was dh_make successor or smth, but seems the other way around
[10:07] <POX_> slangasek: some examples for Python applications: http://svn.debian.org/viewsvn/python-apps/packages/
[10:08] <DKcross> :o aqui son las 43
[10:08] <DKcross> 3
[10:08] <DKcross> perdon
[10:08] <DKcross> soy de EL Savdor man
[10:08] <DKcross> graciaspor tu ayuda
[10:08] <DKcross> creo que lo terminare haciendo
[10:08] <DKcross> sudo apt-get source emesene
[10:08] <DKcross> ese ya trae la carpeta "debian"
[10:09] <slangasek> indeed it does... :)
[10:10] <DKcross> ni modo
[10:11] <_ruben> what would be the best/recommended way to package (3rd party) kernel modules? i guess smth with module-assistent?
[10:13] <RainCT> wgrant: how many times have you died already? :P
[10:13] <wgrant> RainCT: Too many. Floods tend to do that.
[10:13] <DKcross> RainCT,
[10:13] <DKcross> HI
[10:17] <RainCT> hola
[10:17] <DKcross> hola
[10:17] <DKcross> necesito tu ayuda
[10:17] <DKcross> por fa..
[11:06] <RainCT> DktrKranz: Hey. Just to be sure, does bug #267078 need an exception or can I consider it a bug fix release?
[11:07] <DktrKranz> RainCT, is there a "common" changelog? I see several of them, scattered into the diff
[11:08] <RainCT> DktrKranz: No. There's a NEWS file, but the changes it lists for 1.00 were already done in versions 0.98 and 0.99 (currently in Intrepid).
[11:09] <DktrKranz>      - Better support for low resolutions.
[11:09] <DktrKranz>      - Better error handling.
[11:10] <DktrKranz> those could be considered as feature, unless they are bugfixe
[11:13] <RainCT> DktrKranz: well, I consider them bug fixes, someone else may consider them features ;)
[11:14] <RainCT> DktrKranz: anyway. that's the diff for the low resolutions: http://paste.ubuntu.com/43876/plain/
[11:16] <RainCT> DktrKranz: and here is the error stuff: http://paste.ubuntu.com/43880/
[11:19] <toobaz2> hello. I don't want to bother, and it even isn't a direct problem for me, and I have no problem in waiting. But that said: is there any particular reason why my simple patch for the critical (for its package) bug 221007 hasn't still been accepted after a week? I mean: should I contact someone or just wait? thanks
[11:19] <DktrKranz> RainCT, seems low impact or just bugfixes then. You can proceed
[11:20]  * DktrKranz mode cooker on, c u later
[11:20] <RainCT> DktrKranz: thanks :)
[11:21] <Hobbsee> toobaz2: er, probably because we can't read minds, and don't read all bugs.
[11:21]  * Hobbsee grabs a link
[11:22] <toobaz2> Hobbsee: this was just the point: I thought "[patch]" tag would have taken your attention; next time, should I ping someone here?
[11:23] <toobaz2> I mean: what's the expected behaviour of a "patcher"?
[11:23]  * Hobbsee mutters at teh wiki.
[11:23] <Hobbsee> toobaz2: have a look at https://wiki.ubuntu.com/SponsorshipProcess
[11:24] <Hobbsee> toobaz2: (and patch is less than useful, as various people are known to tag their bugs with 'patch', even when there isn't a valid patch, in an attempt to get them fixed faster)
[11:24] <Hobbsee> toobaz2: the https://wiki.ubuntu.com/SponsorshipProcess is the preferred process - although i don't know why it's not linked from the MOTU/ section.
[11:25] <Hobbsee> so it gets looked at every once in a while, and preference tends to be given to the sponsorship queue
[11:25] <toobaz2> Hobsee: OK, was just following https://wiki.ubuntu.com/MOTU/Contributing under "Preparing patches"...
[11:25] <Hobbsee> i figured.  it needs an amalgamation :)
[11:25] <Hobbsee> 151.  yeesh.  i thought people had been working on it
[11:26] <RainCT> toobaz2: (note that you will have to provide a debdiff for the sponsorship queue; normal patches will just be rejected)
[11:29] <toobaz2> RainCT: OK
[11:29] <RainCT> toobaz2: basically the only difference is that you're missing a new changelog entry (use  dch -i -D intrepid  to create it) and that you've to use the command  debdiff  instead of  diff
[11:30] <toobaz2> yep, I know debdiff, I maintain a package in Debian, I just didn't know how to act in Ubuntu. thanks, shall act immediately
[11:32] <RainCT> toobaz2: Ah, alright. The process is basically creating the debdiff, testbuilding the package (with pbuilder or whatever) to ensure that it works, and uploading the debdiff to a bug and subscribing ubuntu-universe-sponsors (universe, multiverse) or ubuntu-main-sponsors (main, restricted) to it :)
[11:33] <RainCT> (although some packages, like the mythbuntu- ones, have a different prefered workflow)
[11:34] <toobaz2> RainCT: shall I post a patch for Intrepid and one for Hardy? Or will Hardy - in case it seems necessary - just be backported?
[11:34] <RainCT> toobaz2: first one for Intrepid, and once it has been accepted you can create one for Hardy and follow the https://wiki.ubuntu.com/StableReleaseUpdates process
[11:34] <toobaz2> ok
[12:19] <bobbo> If an Ubuntu native package (not in Debian) has the version number "0.1", how should the next version be named? (0.1-1?)
[12:20] <geser> bobbo: can you be more specific? which package is it?
[12:21] <bobbo> geser: usb-creator
[12:21] <sebner> geser: \o/ for the ACK script :)
[12:21] <bobbo> geser: current version is 0.1 and I dont know how to version the next bugfix
[12:23] <geser> I'd probably use 0.1.1 but better ask evand about the versioning scheme for it
[12:23] <bobbo> geser: ok, thanks
[12:24] <geser> but 0.1-1 seems also good as you don't touch "upstream" version space
[13:56] <nhandler> Is there a way to be able to build a source package (debuild -S) with an Ubuntu version in debian/changelog, but a non-ubuntu maintainer in debian/control?
[13:57] <DktrKranz> nhandler, export<EMAIL_ADDRESS>[13:58] <DktrKranz> I'm not sure it can be bypassed in other ways, that's the one I use when I need to :)
[14:00] <nhandler> Thanks DktrKranz. That worked. IMHO, there should be an option you can pass to debuild that will tell it to not complain about this.
[14:01] <DktrKranz> that change is hardcoded in devscripts, but I think a wishlist bug can be filed. Not sure if it has already discussed, though
[14:02] <DktrKranz> nhandler, could you please try with dpkg-buildpackage -S -W ?
[14:03] <nhandler> What does the -W option do DktrKranz ?
[14:03] <DktrKranz> if it doesn't work, change could be probably integrated with that option to turn error into a warning
[14:03] <RainCT> nhandler: -W     Negates  a  previously  set -E.  Only dpkg-source uses this, but dpkg-buildpackage recognizes it, and passes it thru to dpkg-source.
[14:03] <RainCT> nhandler: manpages are your friends :)
[14:03] <DktrKranz> RainCT, we haven't manpages.u.c yet :)
[14:04] <RainCT> DktrKranz: we have :)
[14:04] <DktrKranz> wasn't it empty?
[14:04] <iulian> And it rocks so far :)
[14:04] <RainCT> DktrKranz: no, the default page is just bad. search for something or click on a distro and you'll get the manpages
[14:04] <geser> nhandler: what's the use case for this? (ubuntu version but no ubuntu maintainer)
[14:04] <nhandler> DktrKranz: 'dpkg-buildpackage -S -W' failed with the same error
[14:05] <DktrKranz> RainCT, WOW, thanks :)
[14:06] <iulian> RainCT: Well, I wouldn't say that the default page is bad :-) What would you expect to see in a page that shows only manpages?
[14:06]  * iulian thinks that is great.
[14:06] <nhandler> geser: I am currently submitting a patch that was applied in Ubuntu to Debian. As a result, there is no need to have an Ubuntu maintainer. I like to include the changelog entry in the patch to make it easy for the Debian Maintainer to quickly see what changes the patch includes.
[14:08] <RainCT> iulian: something ;). the current page looks confusing
[14:08] <nhandler> RainCT: I don't think it is too confusing. I just hope that they create a script that I can run from a terminal to fetch manpages from manpages.ubuntu.com.
[14:09] <RainCT> iulian: at least the dots would link to the <distro>/<section>/ index page, or there should be a big version of the search box or something
[14:09] <RainCT> iulian: I also thinked that the page was empty like DktrKranz until I saw that someone mentioned the search box on the ML
[14:09] <RainCT> *thought :P
[14:10] <RainCT> nhandler: somewhere someone (yes, my memory is great :)) said that he was working on a patch for man
[14:10] <iulian> nhandler: That website is there just to not use 'man' in a command line, isn't it?
[14:10] <RainCT> nhandler: which would fetch the manpages if it isn't available
[14:10]  * DktrKranz was lazy enought to avoid noticing search box
[14:11] <sebner> RainCT: requestsync is totally b0rken for me. but /me can't send a crash report since firefox is also b0rken xD
[14:11] <RainCT> lol
[14:11] <RainCT> sebner: what's the problem?
[14:11] <nhandler> RainCT: I would love to see that patch in the repositories. It would save me a lot of time.
[14:12] <DktrKranz> RainCT, it's a feature, it's a feature, IT'S A FEATURE! :)
[14:12] <sebner> RainCT: http://paste.ubuntu.com/43924/
[14:12] <DktrKranz> I broken it intentionally to avoid sebner using it
[14:12] <DktrKranz> *broke
[14:12] <sebner> DktrKranz: /me is using it the first time :P
[14:12] <iulian> RainCT: Ahh, you haven't noticed the search box? Yeah, I think it should be moved somewhere else.
[14:12] <geser> RainCT: perhaps somewhere = planet.u.c, someone = kirkland ?
[14:12] <nhandler> sebner: Have you tried using the --lp option?
[14:12] <RainCT> sebner: you didn't close Firefox properly or something
[14:13] <sebner> nhandler: in the first try, yes
[14:13] <sebner> ah
[14:13] <sebner> working again
[14:13] <sebner> ^^ xD xD xD
[14:13] <DktrKranz> gah!
[14:13] <RainCT> sebner: although showing a warning and trying to find a cookie somewhere else would be good. feel free to submit a patch ;)
[14:13]  * DktrKranz hides from sebner
[14:13] <sebner> DktrKranz: I still have >5 sync requests without filing more now ;)
[14:14]  * geser has exported his LP cookie to a text file which requestsync uses
[14:14] <sebner> RainCT: /me != python
[14:14] <RainCT> sebner: then learn python while you are young :P
[14:14] <iulian> Or C
[14:14] <DktrKranz> sebner, brainfuck is a better choice
[14:14] <sebner> RainCT: no ^^ , btw. how to use this thing O_o I read the manpage but it's still a secret to me
[14:14]  * RainCT runs away from iulian
[14:14] <sebner> iulian: C , gah
[14:15] <sebner> DktrKranz: what about whitespaces?
[14:15] <RainCT> sebner: requestsync <package> intrepid
[14:15] <DktrKranz> sebner, butterflies
[14:15] <DktrKranz> sebner, you are new to programming languages, it's better to start with something easy. assembler is a good starting point
[14:16] <sebner> RainCT: you are my hero :D (writing intrepid shouldn't be necessary. fix it!) :P :P :P
[14:16] <sebner> DktrKranz: rofl. hmm not that new. /me likes C# xD
[14:16] <RainCT> DktrKranz: ah, a got an idea a while ago.. We should get a rule so that when sebner gets a MOTU he has to sponsor as many stuff as he got sponsored
[14:16] <nhandler> DktrKranz: Yeah right. I would suggest perl ;)
[14:16] <RainCT> s/a/I
[14:16] <iulian> RainCT, sebner: I prefer to write something in C instead of python, but yeah, python is great too.
[14:16] <DktrKranz> sebner, c#??? go away, go away, GO AWAY!
[14:17] <nhandler> RainCT: I think all MOTUs should be doing that anyway.
[14:17] <sebner> DktrKranz: :P
[14:17]  * geser throws mono at sebner
[14:17] <DktrKranz> RainCT, sebner is under *my* pressure. When he become MOTU, I'll push so many debdiffs to him he will collapse
[14:17] <iulian> Haha
[14:17] <RainCT> :)
[14:17]  * RainCT hugs DktrKranz
[14:17] <sebner> geser: mono rocks :)
[14:17] <sebner> DktrKranz: what about reviewing it yourself instead :P
[14:18] <DktrKranz> sebner, I'll drop my MOTU icon by then
[14:18] <DktrKranz> just for the sake to bother you
[14:18] <sebner> DktrKranz: lol.
[14:18]  * RainCT rofl
[14:18]  * sebner hides and runs away.  I'm fixing RC bugs :P
[14:20] <iulian> Well yea...
[14:20] <DktrKranz> does anybody know how many times (and what are they) PPA publishes binary packages?
[14:20] <jorgenpt> PPAs are updated every 5 minutes, afaik?
[14:20] <RainCT> sebner: yes but once you're a MOTU you can fix more RC bugs as you save time because you don't need to subscribe u-u-s ;)
[14:21] <RainCT> iulian: C# is more like Java, afaik
[14:21] <sebner> RainCT: doesn't matter. Have I never told you? I pushed my application back after intrepid release
[14:21] <nhandler> RainCT: C# and java are very similar
[14:21] <RainCT> (I don't know much about it, though. Knowing who created it scares me away *g*)
[14:21] <DktrKranz> jorgenpt, upload queue is scanned every 5 minutes, I was referring to publishing binary packages into the repository
[14:21] <iulian> RainCT: Indeed
[14:21] <jorgenpt> Oh, thought that was the same timer.
[14:21] <sebner> DktrKranz: have you noticed that nhandler uploaded >50 packages more than I did? Punish him! :P
[14:22] <DktrKranz> nhandler, keep rocking.    sebner: go on retirement
[14:22] <RainCT> sebner: where are the stats?
[14:23] <iulian> RainCT: /+uploaded-packages?
[14:23] <sebner> RainCT: http://thc.emanuele-gentili.com/utu/
[14:23] <sebner> well exactly 50 ^^
[14:23] <RainCT> thanks
[14:23] <sebner> DktrKranz: I should :)
[14:23]  * DktrKranz has 285 ?!?!?!?
[14:24] <sebner> DktrKranz: seems so ^^
[14:24] <DktrKranz> mh... I didn't think so many
[14:24] <iulian> Ahh, didn't know that emgent hosts a service like this.
[14:24] <DktrKranz> but I suppose it's right :)
[14:24] <sebner> DktrKranz: xD
[14:25]  * DktrKranz wrote underlying code... python rocks!
[14:25] <RainCT> blargh my package count for intrepid is pathetic :P
[14:25] <iulian> Yikes! I'm 69
[14:25] <sebner> RainCT: hihi :P
[14:25]  * RainCT considers breaking some stuff and fixing it afterwards to get some more uploads :P
[14:26] <sebner> lol
[14:26] <sebner> lol
[14:26] <sebner> lol
[14:26]  * RainCT discards that idea before Scott kills him ;P
[14:26] <sebner> RainCT: meanwhile you could tell me how to haXX0r my .lpcookie.txt to make it working
[14:26] <DktrKranz> RainCT, could I suggest you "dch -i Rebuild just to enter Top-10 uploader list" ?
[14:26] <RainCT> and I'm still listed several times.. emgent`nl will you fix that somewhen? :P
[14:27] <RainCT> DktrKranz: Good idea. I could write a script to do that with all 20.000 universe packages :)
[14:27] <geser> sebner: wget http://people.ubuntu.com/~kees/scripts/cookies-sql2txt, run it and store the output in ~/.lpcookie.txt
[14:28] <DktrKranz> RainCT, do you want it? I already have it... now seahorse-plugins is in place, it's all automatic :)
[14:28]  * DktrKranz hugs twice seb128 for that!
[14:28] <RainCT> geser: I think requestsync already uses that script
[14:29] <sebner> geser: you are my hero now :D
[14:29] <RainCT> DktrKranz: woo. what is that for?
[14:29] <RainCT> (seahorse-plugins)
[14:29] <DktrKranz> RainCT, it keeps stored your gpg password, no need to retype it each time
[14:30] <geser> RainCT: yes, but sebner wanted to store the cookie in a text file
[14:30] <DktrKranz> and when you do NBS cleaning, it's AWESOME!
[14:30] <RainCT> btw, I installed and purged epiphany-browser a while ago and since then whenever I try to open a link from terminator it opens in gnome-terminal with elinks :/. How can I fix that?
[14:30]  * sebner doesn't want but requestsyncs wants
[14:33] <geser> RainCT: select an other default browser doesn't work for you?
[14:34] <RainCT> geser: Where?
[14:34] <geser> Gnome or KDE?
[14:35] <RainCT> geser: Gnome. I already have Fx3 selected on System -> Prefs. -> Prefered Applications
[14:37] <DktrKranz> use chrome with wine :P
[14:37] <Laney> RainCT: What does `xdg-open http://some.url' do?
[14:38] <sebner> DktrKranz: It's running but not usable xD
[14:38] <RainCT> Laney: elinks
[14:38] <DktrKranz> sebner, so I guess you already tried... bad boy
[14:38] <Laney> RainCT: https://bugs.edge.launchpad.net/ubuntu/+source/xdg-utils/+bug/255621
[14:38] <sebner> DktrKranz: sure I tried :P
[14:39] <sebner> geser: sebner@ubuntu:~/Desktop$ python cookies-sql2txt
[14:39] <sebner> Usage: %s SQLITE3DB DOMAIN
[14:39] <sebner>  !?
[14:39] <RainCT> Laney: thanks
[14:40] <RainCT> Laney: is the problem also on Hardy?
[14:40] <Laney> No idea!
[14:40] <Laney> I don't think so though
[14:40] <geser> sebner: python cookies-sql2text ~/.mozilla/firefox/*/cookies.sqlite launchpad | tee ~/.lpcookie.txt
[14:40] <sebner> geser: O_o
[14:40] <Laney> Do echo $GNOME_DESKTOP_SESSION_ID and see if it returns anything
[14:41] <RainCT> Laney: OK, it doesn't; I'll define that in my ~/.bashrc then. Thanks :)
[14:43] <sebner> geser: output is "# HTTP Cookie File" xD
[14:45] <geser> so it worked
[14:47] <sebner> geser: not really xD but nvm. I'm doing it oldstyle
[14:48] <RainCT> sebner: the "database is locked" exception is catched now and only prints a warning
[14:48] <mok0> What is the status of the following page? It seems to be somewhat out of date. When looking through the MOTU minutes, it seems persia promised to create a writeup on the New Upstream Review process (using interdiff) but I can't locate that anywhere? https://wiki.ubuntu.com/MOTU/Meetings/2007-11-05/NewUpstreamReview
[14:49] <RainCT> mok0: I don't know about that page, but I thought we don't use interdiff anymore?
[14:49] <mok0> RainCT: yeah, me too
[14:49] <geser> that's what I also remember, current is attach the new .diff.gz
[14:49] <sebner> RainCT: bah, you did gbrainy 1.0 :P
[14:50] <mok0> geser: but it's not documented anywhere?
[14:50] <RainCT> sebner: of course :P
[14:50] <mok0> Our wiki is getting sanded with loads of out-of-date info
[14:51] <sebner> RainCT: you stole me a FFe sync :P
[14:52] <geser> NCommander: Hi, interested in an interesting FTBFS? It involves libtool though.
[15:00] <ScottK> geser: NCommander likes fixing libtool stuff.
[15:10] <devfil> zul: ping
[15:11] <zul> devfil: pong
[15:11] <devfil> zul: can you please take a look at bug 264554 ?
[15:12] <Laney> apachelogger: Hi, are you interested in a debdiff for the kdelibs ftbfs?
[15:12] <zul> devfil: ok
[15:12] <apachelogger> Laney: very much so
[15:12] <Laney> apachelogger: Excellent, just testbuilding then I will give it to you
[15:13] <apachelogger> cool :)
[15:15]  * Laney updates GPG key with Ubuntu address \o/
[15:27] <RainCT> sebner: uhm? gbrainy 1.00 isn't in Debian
[15:28] <RainCT> sebner: and it didn't need a FFe
[15:31] <RainCT> mok0: nice mail (re rsplib) :)
[15:31] <mok0> RainCT: All that stuff ought to be in a guide for REVU uploaders
[15:32] <RainCT> mok0: indeed. maybe somewhere in (or linked from) https://wiki.ubuntu.com/MOTU/Packages/REVU
[15:33] <mok0> RainCT:  Right! I could start a document based on that email
[15:50] <Ampelbein> hi there! i have a question about fixing a bug. If the package has not yet an automated-patch-system could i then use quilt to make my patches? or should i use inline-patching?
[15:53] <RainCT> Ampelbein: if there isn't any commented out patch system or such it is usually recommended to see which one the Maintainer uses on some others of his packages, or use the easiest one (eg., if the package uses CDBS then the obvious choice would be simple-patchsys.mk)
[15:54] <Ampelbein> ah, ok. thank you.
[15:55] <ScottK> liw: Are you around?
[16:03] <Adri2000> zul: fail2ban sru?
[16:17] <gnomefreak> is revu updated every 10 minutes? or is there an issue with revu
[16:33] <RainCT> gnomefreak: do you have a problem?
[16:41] <gnomefreak> RainCT: i repushed a package and its not updating it
[16:41] <gnomefreak> RainCT: http://revu.ubuntuwire.com/details.py?package=firegpg isnt updating its been 30 minutes or so since push
[16:43] <andresj> are people here? i created a package to solve https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/253196 in my PPA (https://edge.launchpad.net/~andresjriofrio/+archive), and I was wondering if a MOTU member could check it (it works flawlessly with me) and release the upgrade...
[16:43] <andresj> i have both intrepid and a straightforward backport (no changes except in changelog) to hardy
[16:46] <Laney> andresj: You should follow https://wiki.ubuntu.com/SponsorshipProcess
[16:47] <andresj> Laney: mm... ok I'll go that, thanks :)
[16:48] <Laney> andresj: Did you speak to the Debian maintainer of lyx?
[16:49] <andresj> Laney: no, I didn't. I created the package mainly so that I could have the new version. :P   but then I saw that bug and thought my packages would help.
[16:50] <Laney> andresj: Well if it's good he might want to upload it to Debian, no sense duplicating work
[16:50] <Laney> But there is a freeze on over there so he might not
[16:51] <andresj> Laney: mm... I see, I see. Do bugfix releases superseed freezes like in Ubuntu?
[16:52] <Laney> andresj: Only for "important" bugs
[16:52] <Laney> And I see that 1.6 is already in experimental so it's probably not very likely
[16:54] <andresj> hahaha, ok. I'll try sending this using the Sponsorship Process, then. :)   And nice to hear that, now I can use that package and port it to Ubuntu. :P Although I'm not sure which would be easier...
[16:54] <Adri2000> are automatic config.{guess,sub} changes acceptable in a sru?
[17:04] <RainCT> gnomefreak: the firegpg upload was rejected
[17:05] <andresj> hey is there a way to see the changes in the .diff.gz between two packages (same program, diff versions)?
[17:06] <RainCT> gnomefreak: uhm.. seems like it worked now; do you see it?
[17:06] <RainCT> andresj: debdiff <old>.dsc <new>.dsc
[17:08] <andresj> RainCT: thanks :) oh and btw there's somebody in RainCT_
[17:09] <andresj> oh and is there a command to download all files related (.orig.tar.gz, .diff.gz) given the .dsc?
[17:11] <DktrKranz> Adri2000, it could be better if they can be omitted (e.g. launching debuild -S in a $distro chroot)
[17:11] <ScottK> andresj: dget is what you want.
[17:13] <Adri2000> DktrKranz: ok
[17:17] <andresj> ScottK: oh ok thanks :)
[17:19] <andresj> ScottK: hey debdiff also compares the upstream version files; is there a way to stop it from doing that?
[17:19] <ScottK> No.
[17:20] <andresj> umm...
[17:20] <ScottK> Just use diff directly and diff the two debian dirs.
[17:20] <andresj> ScottK: what is the command to prepare a dir?
[17:20] <andresj> that does: tar -xf .orig; apply diff; etc
[17:21] <ScottK> dpkg-source -x xxx.dsc
[17:22] <andresj> haha thanks! wow its like u had all this in your head already
[17:29] <gnomefreak> RainCT: ill check
[17:29] <gnomefreak> RainCT: ah it did thanks
[17:30] <gnomefreak> should i add ubuntu-universe-sponsors to the bug ?
[17:31] <gnomefreak> ah already are
[17:33] <gnomefreak> can someone please review and sponsor http://revu.ubuntuwire.com/details.py?package=firegpg u-u-s is already subscribed to bug all lintian warnings/errors have been fixed
[17:40] <mok0> gnomefreak: we have FeatureFreeze...
[17:40] <gnomefreak> already
[17:40] <mok0> gnomefreak: since aug. 28
[17:41] <gnomefreak> oh
[17:42] <mok0> Hopefully REVU days will start again when the devel cycle begins
[17:42] <gnomefreak> devel cycle for intrepid+1
[17:42] <mok0> gnomefreak: yes
[17:43] <mok0> "jj" :-)
[17:45] <nxvl> cody-somerville: ping
[18:07] <cody-somerville> nxvl, pong
[18:07] <nxvl> cody-somerville: i forgot what i was looking for you :S
[18:09] <nxvl> s/what/why
[18:13] <andresj> hey anybody know how to add universe/multiverse repositories to my pbuilder?
[18:13] <andresj> i tried `pbuilder --login` and adding them, but it won't work.
[18:13] <andresj> it doesn't change anything, i mean
[18:14] <ScottK> andresj: If you want to login and have the results saved, you also need --save-after-login
[18:14] <andresj> hahaha oh ok! :)
[18:14] <andresj> thanks
[18:15] <geser> andresj: see also the wiki how to add universe to your pbuilder (https://wiki.ubuntu.com/PbuilderHowto#Universe%20support)
[18:16] <andresj> haha thanks that's so much easier :)
[18:17] <DktrKranz> ScottK, re bug 267187, is it legal for motu-release members to self-ACK requests?
[18:19] <ScottK> DktrKranz: Absolutely.
[18:19] <ScottK> It's one of the prime perks of doing all this work.
[18:19] <DktrKranz> ok, I'll ack it myself and then upload. thanks.
[18:22] <riot_le> hi @all, i have an Question about Bugfixing
[18:25] <riot_le> i joined dholbachs Lessons at UDW this week and want to start with my new knownledges, i take an patch from fedora (found on harvest: http://daniel.holba.ch/harvest/handler.py?pkg=gnome-settings-daemon&not_apply=11547) and apply this patch, edit the changelog, debuild, pbuilder and created an debdiff. What have to follow next?
[18:31] <riot_le> no one there who can help?
[18:31] <albert23> riot_le: now you attach your debdiff to the bug report and subscribe the right sponsor team. See https://wiki.ubuntu.com/SponsorshipProcess
[18:34] <riot_le> there is no bug in Launchpad to that, i have taken this patch from direct from fedora-cvs
[18:35] <albert23> riot_le: in that case you open a bug yourself and describe the problem that will be fixed with your patch.
[18:37] <riot_le> ok thank you albert23
[18:38] <albert23> riot_le: no problem
[18:41] <mok0> I've thrown a few paragraphs into a new wiki document. Please help expand! https://wiki.ubuntu.com/MOTU/Packages/REVUWhatNext
[18:43] <riot_le> albert23: i open a new bug report: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/267210 do you think that looks good?
[18:46] <albert23> riot_le: From reading the bug, it's not clear for me yet what the problem is that will be fixed.
[18:48] <riot_le> i think there was no real problem, the patch just added a plugin
[18:50] <albert23> riot_le: so it is a new feature?
[18:51] <riot_le> in my opinion yes
[18:51] <riot_le> i try it
[18:51] <albert23> riot_le: in that case it may be a problem. We have FeatureFreeze now, and only fix bugs for Intrepid
[18:52] <riot_le> ah ok, ill try to find another bug to improve my bugfixing-knowledge
[18:55] <albert23> riot_le: that may be better. Good luck!
[18:55] <riot_le> thanks for your help
[19:11] <apachelogger> Laney: what's the testbuild status?
[23:17] <NCommander> ScottK, :-P
[23:17] <ScottK-laptop> ?
[23:17] <ScottK-laptop> Oh, the libtool thing.
[23:22] <NCommander> ScottK, yeah :-P
[23:25]  * NCommander runs through his email


[23:44] <ZeroAdam> I need a new video card
[23:46] <JonathanD> Mmm
[23:47] <ZeroAdam> I have a desktop I built myself and the video card took a dump.
[23:47] <ZeroAdam> have any recommendations?