[00:08] <igc> emmajane: ping
[00:35] <KhaZ_> Hello!  I apologize if this is the wrong place to ask this, but does anyone here use the bzr-p4 plugin?  I'm trying to understand just what it does but the documentation on it appears to be rather minimal.
[00:36] <lifeless> you can try bzr help p4 (if thats what the directory for the plugin is called)
[00:36] <lifeless> I don't know how complete it is
[00:36] <KhaZ_> Ah, OK.  I supopse I'll isntall it.  Just trying to  read more of it before I install it - not sure if it will solve my problems or not.
[00:37] <lifeless> but most foreign VCS plugins allow 'bzr pull' 'bzr branch' etc to Just Work with urls/locations in those systems
[00:37] <KhaZ_> Ah, neat.  Maybe that is something similar to what I want.  Is bzr push normally facilitated as well, or is it usually up to the client to use the other VCS' tool for that?
[00:37] <lifeless> depends on how complete the plugin is :)
[00:38] <KhaZ_> Ah, but it's not out of the qeustion then at least.
[00:38] <lifeless> but yes, certainly for bzr-svn and bzr-git the whole gamut of push/pull/branch/merge commands work
[00:38] <KhaZ_> Swank.  I will have to dabble with this.    How can I see what plugin directory bzr is scanning for?  I'm running cygwin on vista, and I've tried $APPDATA/bazaar/2.0/plugins and ~/.bazaar/plugins, and yet bzr plugins doesn't return me any of my nifty plugins.  Is there an easy way to get it to spit out the path it's looking up?
[01:18] <fullermd> Not directly, I don't think.  But it should be a 'plugins/' subdir under the 'Bazaar configuration' dir that `bzr version` spits out, I think.
[01:19] <KhaZ_> Genius, that works.  Thanks fullermd.
[01:20] <KhaZ_> Ah, right.  I had reset my BZR_HOME in order to try and keep my linux/windows configurations the same.  D'oh, should've checked the env. variables. :/
[01:20] <fullermd> Maybe there should be an arg to 'plugins' to list the search path.
[01:20] <KhaZ_> I was hoping --verbose would show it
[01:20] <KhaZ_> fullermd: Might be a nice add.
[01:20] <fullermd> Nah, that just shows where the existing plugins are from.
[01:20] <jdub> i'm getting the following error after attempting to bzr co with http basic auth against loggerhead:
[01:20] <jdub> bzr: ERROR: exceptions.KeyError: 'user'
[01:21] <jdub> (interactive or provided in the url)
[01:21] <KhaZ_> fullermd: Right.  I guess my assumption was it woudl say, "Found the following plugins from scanning these paths [searchpath1,searchpath2,searchpath3]: plugin1 [plugin1path], etc."
[01:21] <KhaZ_> Not that it matters, but that was where my intuition took me.
[01:24] <fullermd> It's a reasonable intuition.  You should file a bug on it.
[01:26] <spiv> jdub: hmm, sounds crummy.  pastebin a full traceback?
[01:27] <jdub> spiv: http://www.gnome.org/~jdub/2009/bzr-20091021002215-9259.crash
[01:31] <KhaZ_> fullermd: Good idea.  Done: https://bugs.launchpad.net/bzr/+bug/456834
[01:47] <lifeless> jdub: is loggerhead doing the auth, or some front-end web server?
[01:48] <jdub> lifeless: front end
[01:48] <lifeless> how are you passing the user details to the backend then ? :)
[01:49] <jdub> lifeless: not sure i am; if anything, i don't want to
[01:49] <mwhudson> jdub: i'm suspicious of the bzr-svn in that traceback
[01:50] <jdub> mwhudson: you think bzr-svn on the client might be screwing with it?
[01:50] <mwhudson> it's possible
[01:51] <jdub> ah, you know, yes
[01:51] <jdub> it might be trying to use bzr svn on the http url?
[01:51] <jdub> jdub@sliver:/tmp$ bzr co bzr+http://whitlam.crikey.com.au/code/live/bzr: ERROR: Generic bzr smart protocol error: Invalid http response for http://whitlam.crikey.com.au/code/live/.bzr/smart: Unknown response code 403
[01:51] <lifeless> I think you should:
[01:51] <lifeless> file a bug
[01:51] <lifeless> remove bzr-svn if you don't need it
[01:51] <lifeless> see if that helps
[01:51] <lifeless> there is a bug, thats for sure.
[01:51] <mwhudson> jdub: that seems like a more plausible problem in some ways
[01:52] <lifeless> jdub: note that bzr+http shouldn't be needed - http:// will probe for .smart anyway.
[01:52] <jdub> yeah
[01:52] <jdub> jdub@sliver:/tmp$ bzr co http://whitlam.crikey.com.au/code/live/
[01:52] <jdub> bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden) for http://whitlam.crikey.com.au/code/live/.bzr/branch-format
[01:52] <jdub> ^ without bzr-svn installed
[01:53] <jdub> ooh, what a lovely little mess :-)
[01:53] <lifeless> jdub: 403 sounds like you aren't passing POST to the backend, to me.
[01:53] <jdub> that interactive password request dudie did seem a little svn-riffic
[02:01] <jdub> lifeless: naw, looks like i'm not serving static files at all :_)
[02:03] <lifeless> jdub: yes but that doesn't matter
[02:03] <lifeless> jdub: there should be a 'smart' POST attempt in the log
[02:03] <lifeless> if that is passed through to loggerhead properly, bzr will talk to that, not to static files.
[02:05] <jdub> right
[02:05] <jdub> the smart post hits the frontend with a 403
[02:06] <RenatoSilva> how to  bzr pull --preview merge-directive.patch?
[02:06] <RenatoSilva> or bzr mssing it
[02:18] <jdub> lifeless: does the smart check attempt to auth before posting?
[02:19] <lifeless> jdub: auth is on-demand, when the server gives 401
[02:19] <lifeless> RenatoSilva: I'm not sure missing works with merge diectives
[02:20] <lifeless> RenatoSilva: pull --preview should just work
[02:22] <jdub> lifeless: aaaaaaaahhhhhhhhh
[02:22] <jdub> lifeless: *lightbulb*
[02:22] <jdub> lifeless: i should not bar access to .bzr on this host :)
[02:23] <lifeless> you want .bzr/smart to work
[02:23] <lifeless> not the rest
[02:23] <lifeless> [or at least, you *shouldn't need* the rest]
[02:23] <jdub> right
[02:23] <lifeless> and you want it auth protected.
[02:25] <jdub> yeah
[02:25] <james_w> does loggerhead work as a smart server with no extra configuration?
[02:25] <jdub> lifeless: oh man... new issue
[02:25] <jdub> bzr: ERROR: Server sent an unexpected error: ('error', 'No repository present: "chroot-46030224:///"')
[02:25] <jdub> james_w: recent versions, yeah
[02:25] <lifeless> jdub: ah, shared repo ?
[02:26] <jdub> lifeless: yeah :|
[02:26] <lifeless> jdub: there is a bug, Peng will know more
[02:26] <james_w> that's neat
[02:26] <lifeless> basically it needs to make the chroot in the backend higher up.
[02:26] <lifeless> so I know what needs to be done, I haven't gone and looked at it
[02:26] <lifeless> jdub: look for Chroot in the loggerhead code, you can probably figure it out
[02:27] <lifeless> jdub: rather than branch.base, it will be branch.repository.bzrdir.root_transport, for the chroot root path
[02:28] <jdub> lifeless: looks like that might be a bzrlib thing
[02:28] <lifeless> jdub: nope
[02:28] <lifeless> smart server handles this fine ;)
[02:28] <jdub> there's no Chroot in loggerhead
[02:28] <lifeless> ugh
[02:28] <lifeless> look for smart then
[02:29] <jdub> can i /msg for a moment?
[02:30] <lifeless> of course
[02:30] <spiv>             wsgi_app = wsgi.SmartWSGIApp(self.transport)
[02:31] <spiv> that's in loggerhead/apps/transport.py, line 85
[02:31] <lifeless> so self.transport needs to be adjusted
[02:31] <lifeless> you'll need to find the actual root you want
[02:31] <lifeless> and probably need to pass in some adjuster - spiv knwos this much better than I :)
[02:32] <spiv> which in turn gets transport from make_app_for_config_and_path, which gets it from the config
[02:33] <spiv> Which apparently defaults to '.', unless you pass a command line arg?
[02:34] <spiv> I don't really know my way around the loggerhead codebase very well.
[02:34] <jdub> yeah
[02:34] <lifeless> spiv: yes, but you know the wsgi helpers in bzrlib
[02:34] <lifeless> spiv: you see the problem, right?
[02:36] <RenatoSilva> lifeless: pull --preview didn't work
[02:36] <spiv> lifeless: not really, it's calling the right wsgi helper, I would expect that so long as it feeds the right path to it is all good.
[02:38] <RenatoSilva> lifeless: iirc someone here noted that pull doesn't have --preview as expected
[02:38] <spiv> lifeless: but I don't know enough about how self.transport is created to know where loggerhead is going wrong
[02:39] <spiv> or where jdub's configuration of loggerhead is going wrong, perhaps?
[02:39] <jdub> spiv: i'm just passing it a path (to the repo)
[02:39] <jdub> spiv: then attempting to co the branch under it
[02:40] <jdub> loggerhead autoserves branches under a repo
[02:41] <lifeless> spiv: its the transport of the branch, not the repo
[02:41] <spiv> lifeless: oh, right, yes, I got that bit :)
[02:42] <lifeless> spiv: it needs to be shifted up to the repo; but requests at that path need to be shifted down to the branches relative path
[02:42] <spiv> lifeless: I don't know why; the code I've read suggests it shouldn't be
[02:42] <spiv> lifeless: i.e. the code I've seen so far looks like it is doing things correctly
[02:43] <lifeless> spiv: if you're not bogged down with critical stuff, I think this is actually well worth treating as high and digging into
[02:43] <jdub> spiv: 0.17 or beyond?
[02:43] <spiv> Hmm, the UserBranchesFromTransportRoot looks a bit suspicious
[02:43] <spiv> jdub: I'm reading the code in trunk
[02:43] <spiv> Not sure how that relates to version numbers ;)
[02:44] <spiv> lifeless: I'm certainly happy to dig for a while
[02:44] <spiv> lifeless: I just posted a patch for that "second push failed to complete" bug
[02:44] <jdub> thanks dudes :-)
[02:44] <lifeless> spiv: awesome; I saw it, but got distracted just as I hit the diff
[02:44] <lifeless> Lynne has the lurgy now too
[02:45] <spiv> Urgh, lucky Lynne :(
[02:46] <spiv> mary and I think we've been fighting off something this week, so far not so bad but not quite feeling 100% either.
[03:02] <spiv> Ah, found it I think.
[03:02] <lifeless> spiv: vitamin C!
[03:08] <thumper> can anyone with windows experience comment on https://bugs.launchpad.net/bugs/455636 to say where to put the ssh key that bzr will use?
[03:11] <lifeless> thumper: there isn't a place AIUI
[03:12] <lifeless> thumper: you run a gui - pageant - and tell it to add the key
[03:12] <thumper> lifeless: hmm, that's about as much as I know too
[03:12] <SamB_XP> that really ought to be in the help file :-(
[03:34]  * igc lunch
[03:39] <SpamapS> Hi.. in perforce if I see a change #, I can say 'p4 describe ######' and it shows me al the changes associated with that.. does bzr have something similar? Right now I have to find the previous revision and use bzr diff..
[03:39] <spiv> jdub, lifeless: so I have a fix for your bug, but now I'm hitting https://bugs.edge.launchpad.net/bzr/+bug/348308
[03:39] <jdub> spiv: boh!
[03:40] <spiv> jdub, lifeless: will keep poking after lunch, that bug was going to bubble to the top of my list sooner or later
[03:41] <fullermd> SpamapS: You don't have to find the previous revision, you can use '-c'.
[03:41] <SpamapS> fullermd: ahh thats what I get for only paying attention to the examples and not reading the whole manual. ;)
[03:42] <fullermd> SpamapS: (and technically you don't need it with -r either, -c is just less typing  ;)
[03:43] <fullermd> SpamapS: "bzr diff -c$REV" == "bzr diff -rbefore:$REV..$REV"
[03:51] <lifeless> spiv: sweet
[03:51] <lifeless> spiv: that is the bug isn't it :)
[04:04] <mwhudson> oh _that_ bug!
[04:05] <SpamapS> fullermd: thank you.. :)
[04:20] <fullets> I've been using a workflow like: bzr init-repo repo; bzr branch svn-trunk bzr-trunk; bzr branch bzr-trunk bzr-feature; hack on bzr feature; cd bzr-trunk; bzr merge ../bzr-feature; bzr push
[04:20] <fullets> Trying to bzr diff -c a merge commit from a branch outside that repository causes bzr to crash. Are there any workarounds for this?
[04:21] <dash> huh. what version of bzr?
[04:21] <fullets> 2.0.1 from the jaunty ppa
[04:21] <dash> huh, dang.
[04:22] <dash> I've never seen that happen
[04:22] <lifeless> what crash
[04:22] <fullets> bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository(path) has no revision
[04:24] <lifeless> interesting
[04:24] <lifeless> can you try -r before:X..X PATH/TO/BRANCH
[04:24] <lifeless> as in 'bzr diff -r before .....
[04:25] <fullets> Sorry, what should the X's be? The revision number of the merge commit?
[04:25] <fullets> If so, the same crash happens
[04:26] <lifeless> fullets: yes, exactly.
[04:26] <fullets> Also -r m..n that cross the merge commit give the same crash
[04:26] <lifeless> fullets: if you cd to that branhc
[04:26] <lifeless> and then run the command, does it work?
[04:27] <fullets> It crashes whether the branch, repo, or the repo's parent dir are my cwd
[04:29] <lifeless> does 'bzr log' work when the branch is your cwd
[04:31] <fullets> Yes, both displaying the whole log and the log for the merge commit work. Trying to show the merged revisions with --include-merges shows none of the merges
[04:33] <lifeless> log -n0 will do that
[04:33] <lifeless> I think you should file a bug
[04:33] <lifeless> if log works but diff -c doesn't, there is something very strange going on.
[04:35] <fullets> I shall file a bug once I finish putting steps to reproduce together :)
[04:42] <lifeless> fullets: please file the bug earlier
[04:42] <lifeless> fullets: as you may need our help to diagnose it, and bugs provide a place to track the conversation
[04:42] <fullets> Very good
[04:53] <thumper> how do I create a branch with the LCA of two other branches?
[04:54] <lifeless> thumper: cd two; bzr revision-info -r ancestor:one
[04:54] <lifeless> then bzr branch -r revid:.... one
[04:55] <fullets> lifeless: https://bugs.launchpad.net/bzr/+bug/456908
[04:55] <lifeless> thanks
[04:55] <lifeless> bug 456908
[04:55] <thumper> lifeless: ta
[06:17] <spiv> jdub: http://bzr.pastebin.com/m5e6d6205
[06:18] <spiv> jdub: there's a couple of minor debug droppings in that (the print statement and the commented out pdb line), but that makes serve-branches work for me with a shared repo
[06:18] <spiv> jdub: I'm working on a proper fix for the bzr bug that works around
[06:20] <jdub> spiv: rocking -- thanks! :-)
[06:20] <lifeless> spiv: nice
[06:21] <jdub> spiv: beautiful :-)
[06:22] <jdub> spiv: what are the chances that will work with --allow-write? :-)
[06:24] <spiv> jdub: I don't see why it wouldn't :)
[06:28] <spiv> thumper: btw, https://answers.edge.launchpad.net/bzr/+questions?field.search_text=ssh+windows&field.sort=RELEVANCY&field.sort-empty-marker=1&field.actions.search=Search&field.language=en&field.language-empty-marker=1&field.status=OPEN&field.status=NEEDSINFO&field.status=ANSWERED&field.status=SOLVED&field.status-empty-marker=1 has some info about ssh and windows if you're prepared to dig a bit
[06:33] <jdub> spiv: it does, btw :-)
[06:37] <Peng_> spiv: You rock! Thanks for working on this! :)
[06:40] <lifeless> james_w: is there a PPA with bzr builder in it?
[07:16] <Peng_> mwhudson: ping
[07:37] <bialix> hello all
[07:37] <Peng_> Hi. :)
[07:47] <spiv> Ah good, I have what seems to be a working fix for the bzr+http bug and a draft of a reasonable test.
[07:48]  * spiv heads to yoga class feeling satisfied
[07:48] <Peng_> spiv: I love you. :)
[08:46] <Kamping_Kaiser> sigh. dependancy hell for the win.
[09:39]  * igc dinner
[09:49] <alex_morelli> hello all
[09:50] <alex_morelli> long time ago, I found a plugin for bzr that implemented a "make-log" command a la tla
[09:51] <alex_morelli> Now I can't find it anymore... anyone ever heard of it?
[09:57] <bob2> what did make-log do?
[10:00] <alex_morelli> It created a log file, to which you appended what you were doing until commit
[10:00] <alex_morelli> and you couldn't commit without that log file
[10:01] <bob2> what does it do different to 'touch x ; edit x ; bzr ci -F x'
[10:02] <alex_morelli> not much, but you can commit anyway this way
[10:07] <alex_morelli> and make-log sort of forced you to behave
[10:14] <Kamping_Kaiser> Is `bzr svn-import` supposed to work from a client checkout of an svn repo?
[10:15] <Peng_> Kamping_Kaiser: Not sure. It's not hard to get the URL, though.
[10:15] <Kamping_Kaiser> I gen an error "bzr: ERROR: No Repository found at gns/builder-clean. For individual branches, use 'bzr branch'." when trying to run it against an svn checkout (I don't hae access to the svn repo)
[10:15] <Kamping_Kaiser> Peng_: ah, i'm supposed to run it on the url?
[10:16]  * Kamping_Kaiser tries
[10:18] <Kamping_Kaiser> aaah. *yay*
[10:18] <Kamping_Kaiser> Peng_: thanks :)
[10:19] <Peng_> Kamping_Kaiser: :)
[10:19] <Peng_> Kamping_Kaiser: FYI, if you *did* have a copy of the repo locally, you could run it against the directory path too.
[10:19] <Peng_> Probably.
[10:22] <Kamping_Kaiser> good to know, thanks.
[10:28] <james_w> lifeless: https://edge.launchpad.net/~dailydebs-team/+archive/bzr-builder
[10:32] <Kamping_Kaiser> perhaps a strange question: having vampired out of the svn repo, i have a 34mb .bzr directory, and the builder/ directory is empty. is there a non-obvious step involved in making the repository useful?
[10:33] <Peng_> Kamping_Kaiser: svn-import doesn't create working trees by default. cd to a branch and run "bzr checkout".
[10:33] <Kamping_Kaiser> ah.
[10:34] <Kamping_Kaiser> Peng_: would it be worth noting that somehow on the help (bzr help svn-import)? (sorry if it is, in newer versions)
[10:34] <Peng_> Kamping_Kaiser: I'm running the bzr-svn trunk, and it does mention it.
[10:34] <Kamping_Kaiser> Peng_: no worries then. thanks for checking!
[10:42] <Kamping_Kaiser> caw. its there
[10:42] <Kamping_Kaiser> thanks so much\o/
[10:43] <Peng_> jam: StaticTuple.as_tuple() doesn't recursively convert other StaticTuples inside the StaticTuple to tuples. Do you think it should?
[10:43] <Peng_> jam: In other words, is that a bug or a feature? :)
[11:38] <Peng_> beuno: ping
[12:10] <bialix> шпсЖ зштп
[12:10] <bialix> igc: ping
[12:10] <igc> hi bialix
[12:11] <bialix> I want to convert cvs repo of FTE to bzr
[12:11] <bialix> I've managed to rsync entire repo from sf.net
[12:11] <bialix> can you point me where to start?
[12:11] <bialix> should I use instructions from here: http://cvs2svn.tigris.org/cvs2bzr.html
[12:12] <igc> bialix: start with http://doc.bazaar-vcs.org/migration/en/data-migration/index.html
[12:12] <bialix> or your plugin has inside something else?
[12:13] <igc> bialix: if the instructions aren't clear, we need to improve them
[12:13] <bialix> ok, I'll read
[12:13] <bialix> will ask questions tomorrow
[12:13] <igc> bialix: fast-export-from-cvs calls cvs2bzr to do the export
[12:13] <bialix> aha
[12:14] <bialix> cvs2bzr page mentions some options.file
[12:15] <igc> bialix: hopefully you don't need a custom options file. If you do, I think fast-export-from-cvs allows you to provide one
[12:16] <bialix> igc: I have installed TortoiseCVS
[12:17] <bialix> I hope it will be enough to use cvs2svn
[12:17] <bialix> as I know it can work with RCS co utility or cvs executable
[12:17] <bialix> do you control this aspect somehow?
[12:18] <bialix> igc: ok, help for fast-export-from-cvs is clear, I'll start experimenting and will report all issues I'll encounter
[12:19] <igc> bialix: thanks. we need to get the process *clearly* documented
[12:19] <spiv> Peng_: test added, patch up for review
[12:20] <spiv> Peng_: feel free to sneak it into your deployment right now and get rid of your monkey patch ;)
[12:20] <bialix> igc: my mileage as typical windows/tortoisecvs user will vary
[12:21] <spiv> Peng_: Btw I discovered that doing that fix was exactly as painful and confusing as I thought it would be, so I feel less bad about not doing it sooner now :P
[12:21] <bialix> igc: and btw, I found gnuwin32.sf.net project is better than unxutils.sf.net
[12:22] <spiv> Peng_: (even though the eventual patch is actually quite clear I think, but fully analysing this stuff is always makes me go a bit cross-eyed)
[12:24] <bialix> igc: unxutils.sf.net is no more maintained and I'm unable to download sort there
[12:27] <Peng_> spiv: Heh, that makes me feel better about not trying to figure it out myself.
[12:33] <Peng_> spiv: I just confirmed that your fix works. I love you! :)
[12:46] <spiv> Peng_: great, thanks for testing :)
[12:51] <spiv> Peng_: yeah, it's not so much that it's hard exactly.  Just that there are just enough confusingly similar variables involved that it's hard to keep track of what's going on.
[12:52] <Peng_> spiv: Not to rush you, but you're working on a fix for Loggerhead too, right? What's the status of that?
[12:52] <spiv> All the various path the user sees/path the http request is delivered to/path in the hpss request/path adjusted relative to server backing transport/path relative to request handler etc
[12:53] <spiv> Oh yeah, good point.
[12:53] <spiv> I've even tested that it works (with my fix for bzrlib)
[12:53] <spiv> So I'll file that merge directive now
[13:00] <spiv> Peng_: https://code.edge.launchpad.net/~spiv/loggerhead/shared-repo-fix/+merge/13701
[13:02] <Peng_> spiv: Great. :)
[13:03] <Peng_> This is missing the point, but testing with "bzr revno" is clever. I always use "bzr log -r -1 -n 1", which takes a while
[13:04] <spiv> Peng_: :)
[13:04] <spiv> Peng_: a while to type if nothing else!
[13:04] <Peng_> Yeah, that too.
[13:10] <igc> night all
[13:11] <spiv> g'night
[13:19] <beuno> Peng_, hi
[13:24] <Peng_> beuno: I just wanted to say that lp:~beuno/loggerhead/yui3-0-0 is redundant. I pushed a similar branch to lp:~mnordhoff/loggerhead/yui-3.0.0 and lp:~loggerhead-team/loggerhead/yui-3.0.0, which also handles a couple of renamed files better.
[13:26] <beuno> Peng_, did you get it working?
[13:31] <Peng_> beuno: No. I didn't do anything more than update the copy of YUI.
[13:33] <beuno> Peng_, gotcha. I will see if I can spend an afternoon fixing it. I have some idea of what needs to be tweaked
[13:34] <Peng_> Oh, good. :)
[13:35] <beuno> Peng_, did you get the LP tshirt?
[13:36] <Peng_> beuno: Not yet.
[13:37] <beuno> mrevell-lunch, do you know anything  ^
[13:37]  * beuno has delegated the problem to a smarter person
[13:40] <nil1> Hi!
[13:41] <nil1> Is bzr able to handle concurrent commits on a "dumb" server (like FTP)?
[13:41] <beuno> nil1, yes
[13:41] <nil1> thanks!
[13:42] <Peng_> There are very brief windows where the repo will be write-locked, though, no?
[13:42] <nil1> Does it require a reliable locking mechanism?
[13:43] <nil1> (locking in the sense of a .lock file being written)
[13:43] <Peng_> nil1: Yes. Bazaar implements said reliable locking mechanism itself. It works fine over FTP.
[13:43] <beuno> yes, it locks the repo for brief moments
[13:43] <beuno> I guess that would limit how concurrent it can be
[13:44] <nil1> I use the FTP interface of the Tahoe storage grid, where the latency is probably higher than on a normal FTP server
[13:47] <nil1> I'll ask them if writes are reasonably atomic
[13:47] <nil1> (them = Tahoe devs)
[13:47] <beuno> nil1, let is know  :)
[13:47] <nil1> will do!
[13:52] <Peng_> Using StaticTuple in Loggerhead is fun. There are currently fewer tuples than lists in memory. :D
[13:55] <beuno> Peng_, did it have an impact in memory usage?
[13:57] <Peng_> beuno: It's way too dynamic to be sure.
[13:59] <mrevell> Peng_ Your t-shirt'll be in the post today.
[14:00] <Peng_> mrevell: Yay!
[14:02] <beuno> thanks mrevell
[14:08] <mrevell> Peng_ I've just been told that it has now been sent.
[14:10] <beuno> Peng_, spiv's branch looks good to land now, want to merge it yourself or want me to?
[14:12] <Peng_> beuno: You can if you want to.
[14:12] <Peng_> mrevell: Thanks! :)
[14:12] <Peng_> beuno: But I don't mind doing it.
[14:12] <spiv> Peng_: woo
[14:12]  * spiv -> zzz
[14:13] <beuno> spiv, thanks
[14:13] <beuno> Peng_, go for it
[14:13] <Peng_> beuno: 'kay
[14:17] <Peng_> Pushing now
[14:19] <beuno> woo!
[14:22] <Peng_> (Pushed again, cuz I forgot to mention bug #348308 in NEWS.)
[14:22] <Peng_> I can never merge something in just one revision. :P
[14:24] <beuno> heh
[14:33] <Peng_> jam: ping
[14:36] <pickscrape> Could someone explain to me what the --incremental option of bzr svn-import does?
[14:39] <Peng_> pickscrape: "bzr svn-import --incremental" is to "bzr svn-import" as "bzr pull" is to "bzr branch".
[14:40] <pickscrape> Peng_: Ah, so if I have an import that I have to kill due to it using 13G of ram, using that option will allow it to carry on from where it left off?
[14:41] <Peng_> pickscrape: ...Probably.
[14:41] <pickscrape> Peng_: thanks, I'll try that the next time I have to kill it
[14:42] <Peng_> pickscrape: I'm not sure how much of the import will have been saved if you kill it, but it probably will include most of the repo.
[15:00] <jam> morning all
[15:00] <jam> spiv: thanks for the reviews, sleep well
[15:00] <jam> Peng_: wave
[15:01] <jam> jelmer: it looks like we need an updated bzr-rewrite as wel
[15:04] <Peng_> jam: First of all, I'm sorry about pestering you to keep adding features to StaticTuple. Thanks to all of your work, I finally got the Loggerhead branch working. :)
[15:05] <jam> Peng_: good to hear. Did you see my recent patch to support more object types?
[15:05] <jam> That should land in bzr.dev today
[15:05] <Peng_> jam: Yeah, I'm using it.
[15:05] <jam> it will change slightly, but not dramatically
[15:05] <Peng_> jam: Anyway, on to the continued pestering: The only other things I could want are these, but they're not necessary: Pickle support, and the ability to pass a generator to from_sequence.
[15:06] <Peng_> jam: What do you think? Like I said, they're not necessary, but they would be nice.
[15:07] <jam> Peng_: from_sequence(tuple(generator)) should work fine :)
[15:07] <jam> and essentially give the same results
[15:07] <jam> I have to iterate the generator because ST is a fixed-width object
[15:07] <Peng_> jam: OK.
[15:07] <jam> given that, from_sequence(list(generator)) might be better
[15:07] <jam> I'm not clear on the tuple internals wrt a generator
[15:08] <Peng_> from_sequence(list(generator)) might be better than from_sequence(tuple(generator))? Why?
[15:08] <jam> Peng_: because tuple() is also fixed width, so it has to somehow stage the whole generator result somewhere
[15:08] <jam> and then create a tuple
[15:08] <jam> *list* can grow
[15:09] <jam> so it can stage the contents into itself
[15:09] <Peng_> jam: Ahh, interesting. ...It probably doesn't matter much, though.
[15:09] <jam> Peng_: looking at the internals of PySequence_Tuple() it re-allocates the internal tuple
[15:10] <jam> holding a size of 10, and then reallocating over and over as it grows
[15:10] <jam> so I guess ~ the same as List does
[15:10] <jam> Pickle support... I really don't know what it takes to tell pickle about a custom type
[15:11] <Peng_> I think these tuples are only like 1 or 2 items long, so it shouldn't matter much.
[15:12] <jam> http://docs.python.org/library/pickle.html#pickling-and-unpickling-extension-types
[15:12] <Peng_> Oh, I hadn't scrolled down that far in the docs.
[15:13] <Peng_> jam: BTW, your merge proposal got the LP equivalent of bb:tweak, more or less. Have you seen it yet?
[15:13] <jam> Peng_: yeah, I'm cleaning it up now
[15:13] <Peng_> jam: ok :)
[15:19] <jam> Peng_: so if pickling is important to you, I'm happy to look over a patch, give suggestions, etc. I'm probably not going to worry about it myself, though.
[15:19] <jam> In general, I think it wouldn't be too hard
[15:19] <jam> you just have to implement __reduce__() and __setstate__()
[15:20] <jam> except __setstate__() sounds like it happens *after* the class has been instantiated
[15:20] <Peng_> Step 1: Learn C. :P
[15:20] <jam> Peng_: if you wrote it sufficiently in Python, translating it to C wouldn't be hard (for someone)
[15:21] <jam> you could try doing it on the pure python StaticTuple type to start with
[15:21] <jam> or if it 'just gets' it from 'tuple', check what to do there
[15:22] <jam> they also mention that you can do this 'after-the-fact' by registering with the 'copy_reg' module
[15:23] <jam> http://docs.python.org/library/copy_reg.html#module-copy_reg
[15:23] <jam> that may work better, as it can
[15:23] <jam> 1) probably be done in pure python
[15:24] <jam> 2) you can be more sure that you don't have to construct an object and then call __setstate__ on it
[15:24] <jam> hmm.. maybe no nee
[15:24] <jam> need
[15:24] <jam> given the callable you pass takes a tuple of arguments for the callable
[15:25] <Peng_> I just tested a copy_reg one-liner. It whined about __builtin__.StaticTuple not existing.
[15:26] <jam> Peng_: did you have _static_tuple_c imported before you did the unpickle?
[15:28] <Peng_> jam: I had "from bzrlib.static_tuple import StaticTuple".
[15:29] <jam> so potentially that is the pure python class, though not if everything is working correctly
[15:29] <Peng_> jam: It's the C version.
[15:29] <Peng_> I note that the C StaticTuple has no __module__ attribute.
[15:32] <jam> interesting, given that 'tuple' itself does
[15:35] <jam> Peng_: actually *instances* of tuple do not have the __module__ attribute, but t.__class__.__module__ does
[15:35] <jam> and
[15:35] <jam> >>> _static_tuple_c.StaticTuple.__module__
[15:35] <jam> '__builtin__'
[15:35] <jam> I don't specifically know how to change that
[15:35] <jam> as I don't see where it is set
[15:40] <jam> it seems to be in 'typeobject.c' a function called type_module()
[15:40] <jam> and it looks like if you set "tp_name" to "bzrlib._static_tuple_c.StaticTuple" then it will get a module
[15:41] <jam> otherwise it defaults to __builtins__
[15:42] <jam> Peng_: give this a shot: http://paste.ubuntu.com/298325/
[15:44] <Peng_> Are you supposed to hardcode the module like that? Obviously, it isn't necessary when writing Python code.
[15:45] <jam> Peng_: that seems to be why Type.__module__ expects
[15:46] <jam> we aren't creating a heap type, so we can't just set "Type.__module__" directly
[15:46] <jam> and if it isn't a heap type, it checks 		s = strrchr(type->tp_name, '.');
[15:46] <jam> and if not found returns __builtin__
[15:46] <jam> so I think so
[15:50] <Peng_> jam: This fixes it, but you'll have to adjust __repr__, as it now includes the module too.
[15:51] <Peng_> jam: Or, don't adjust repr, but adjust any tests where it's still hardcoded (if there are any).
[15:52] <jam> well, seeing the full format in print '%r' also isn't very nice
[15:52] <jam> and I think we have the flag set so you can't subclass StaticTuple
[15:52] <jam> so it is safe to just hard-code it there
[15:53] <Peng_> jam: With that patch, pickling works with this one-liner: copy_reg.pickle(StaticTuple, lambda st: (StaticTuple, st.as_tuple()))
[15:53] <Peng_> jam: Although it will probably die horribly if you enable or disable the C extensions in between pickling and unpickling.
[15:54] <jam> Peng_: it won't work because the module is hard-coded in the pickle stream
[15:55] <jam> now if we wanted to be 'evil'
[15:55] <jam> we would make the module name "bzrlib.static_tuple"
[15:55] <jam> and then set
[15:55] <jam> bzrlib._static_tuple_py.StaticTuple.__module__ == 'bzrlib.static_tuple'
[15:55] <jam> at that point
[15:55] <jam> I think you could switch between them
[15:55] <jam> i'm not positive
[15:56] <Peng_> Probably.
[15:56] <jam> but I think the unpickler just tries to grab a class at the given path
[15:56] <jam> and passes it the args
[15:57] <Peng_> IMO doing that is nice, but unacceptably evil.
[16:00] <Peng_> Boy. I'm running bzr.dev with 2 unmerged branches + a patch. Fun!
[16:28] <Peng_> jam: So... what do you want to do? About tp_name, and about __reduce__? I could probably do it all, but it would take me a while, since I've written about 4 lines of C, none of them involving Python's C API.
[16:34] <jam> Peng_: I can probably put it on my "get to it eventually" list, as the actual amount of work is pretty small
[16:34] <jam> did you try the 'nice but evil' hack and see if it worked?
[16:39] <Peng_> jam: What, to make switching between C and Python work? No.
[16:41] <Peng_> jam: Are you going to land the tp_name patch? I'm going to work on pickling -- though I might give up -- so I can make it a part of that. But I don't know what, if anything, to do about repr.
[16:42] <jam> Peng_: just change the part that formats to hard-coding it
[16:42] <jam> I would land them all together
[16:42] <Peng_> jam: Alright.
[16:46] <jam> static tuple type support is in pqm now
[16:47] <jam> Peng_: what other unmerged branch are you running?
[16:49] <Peng_> jam: lp:~spiv/bzr/bzr-http-jailbreak-bug-348308
[16:50] <Peng_> Uh-oh. Applying the tp_name patch to another branch, it doesn't work. :\
[16:52] <Peng_> And no, I'm not making some mistake like importing the wrong file.
[17:08] <awilkins> Thought of the day : a fast-import frontend you can use for benchmarking
[17:08] <awilkins> ie - it replays revisions by making changes to the filesystem and driving the porcelain of your chosen VCS
[17:09] <awilkins> So you could take a git-fast-export of say.. the kernel tree... and pipe it through this thing to see how various things performed on real-world data
[17:21] <jfroy> verterok: ping
[17:21] <verterok> jfroy: pong
[17:21] <verterok> jfroy: hi
[17:22] <verterok> jfroy: I wasn't able to get a spare minute and reboot into OS X, so no push yet :(
[17:24] <jfroy> alright, just ping me when you do
[17:35] <verterok> jfroy: sure, let me try to get the changes from the HFS+ disk ;)
[17:44] <verterok> jfroy: pushed revno 13 to lp:~verterok/+junk/OSX-package
[17:44] <verterok> jfroy: I remove the -desktop pmdoc, as it was quite outdated
[17:44] <verterok> *removed
[18:08] <jfroy> verterok: so what's the process for the desktop installer?
[18:09] <verterok> jfroy: there isn't a desktop installer :)
[18:09] <verterok> jfroy: I just builded a PyQt.pkg and included it in the DMG
[18:09] <verterok> jfroy: as I'm still using my old script to build the 10.5 installer
[18:10] <verterok> jfroy: basically, I think we need a new pmdoc (-desktop) for 10.6
[18:11] <jfroy|work> I see
[18:12] <jfroy|work> well that should be easy enough
[18:12] <jfroy|work> I don't see a switch to have fetch-external grab PyQt and Sip, am I missing something?
[18:13] <Tak> yay, subvertpy crash fixed!
[18:14] <verterok> jfroy: it should fetch all the deps
[18:15] <jfroy|work> Ah, so it did
[18:17] <jfroy|work> hum
[18:18] <jfroy|work> why did you modify the config for sip and pyqt that much?
[18:23] <jfroy|work> ah I see, the default paths are bogus
[18:24] <verterok> jfroy: yeap
[18:27] <jfroy|work> anyways, it needs to be done that way too because there's no prefix or root option
[18:27] <jfroy|work> was the -q option necessary for pyqt?
[18:28] <jfroy|work> it should find the default just fine I would think
[18:29] <jfroy|work> oh, did you include Qt in your dmg?
[18:34] <verterok> jfroy: no, QT  needs to be installed
[18:34] <verterok> jfroy|work: ^
[18:35] <verterok> jfroy|work: I'm still trying to build a standalone bundle with qt and pyqt
[18:39] <Peng_> jam: I just sent a merge request for pickling. Peng_ wrote C, ha! (Well, Peng_ copy-and-pasted C.)
[18:41] <jam> Peng_: \o/ for you
[18:43] <jam> Peng_: https://code.launchpad.net/~mnordhoff/bzr/statictuple-pickling/+merge/13720 doesn't have anything with pickling
[18:43] <jam> it only has the repr and tp_name changes
[18:44] <Peng_> jam: I know. Launchpad's mirror is out-of-date; see my message.
[18:44] <Peng_> I didn't want to wait another 4 hours to submit the proposal, or figure out how to trigger a mirror again.
[18:44] <Peng_> Sorry for making it confusing.
[18:46] <abli> Hi! If I do a bzr merge of certain revisions (i.e. with from_rev..to_rev) why doesn't it get noted that I have pending merges when I do a "bzr st"? And why dont the merged versions's comments get added when I check in the merge? Any ideas?
[18:47] <abli> (using bzr 1.16.1)
[18:47] <dash> abli: that's a cherry-pick and bzr doesn't treat it like a 'normal' merge
[18:47] <dash> it just applies the changes and doesn't track history
[18:48] <jam> Peng_: you could have always hosted the branch... :)
[18:48] <abli> and is there some way  to make bzr treat it like a normal merge? To get the merged comments in the checkin comment?
[18:48] <jam> Peng_: reviewed. I think you need one more Py_INCREF but otherwise it looks good.
[18:48] <jam> abli: use "bzr merge -r to_rev"
[18:49] <jam> and if you really need to
[18:49] <abli> For example, bzr will know that those revisions were merged, right? I.e. won't show them when I run "bzr missing" later?
[18:49] <jam> bzr merge --force -r from_rev..ancestor:../other
[18:49] <jam> abli: it will show them as missing
[18:49] <jam> as said earlier, we don't track the history of cherrypicks
[18:49] <Peng_> jam: How's that fun? If I had originally pushed to LP, it would have been very quick, instead of 8 minutes of streaming data to the out-of-date repo on my server. :D
[18:50] <dash> abli: what's your situation?
[18:50] <abli> Btw why isn't cherry-picking treated like a normal merge? (I.e. why is the workaround you guys mentioned needed?)
[18:51] <jam> Peng_: well at least your server is up to date now :)
[18:52] <abli> trying to merge "half" of a branch to trunk. I.e. I have a branch with commits that implement  two features, and I want to merge those belonging to one of the features to trunk
[18:56] <abli> jam: how should I read that from_rev..ancestor:../other part? I assume I am to run "bzr merge" from the branch I am merging to, right? So running "bzr merge -r from_rev..to_rev other_branch" is a normal cherry-picking, right? so how do I run this non-cherry-pick-but-only-some-revisions merge? Or is it even possible?
[18:57] <Peng_> jam: Thanks for the review. :)
[18:58] <Peng_> Writing (a little bit of) C is kind of fun. Python is so easy that it's boring. :P
[19:02] <jam> abli: we don't have a way to internally represent "i'm merging some of the ancestry but not all of it"
[19:02] <jam> so there are some options
[19:02] <jam> but they all 'break' for some use cases
[19:03] <jam> abli: for example you can do
[19:03] <jam> bzr merge ../other -r from_rev
[19:03] <jam> bzr revert .
[19:04] <jam> bzr commit -m "Explicitly remove the initial changes"
[19:04] <jam> bzr merge ../other -r ../to_rev
[19:04] <jam> however, in that case the initial changes 'won't' land
[19:04] <jam> though you can then do the reverse sync
[19:04] <jam> with cd ../other
[19:04] <jam> bzr merge ../trunk
[19:04] <jam> bzr revert .
[19:04] <jam> bzr commit -m "Revert the removal from trunk"
[19:04] <jam> or something along those lines
[19:05] <jam> caveat that merging trunk probably does more than just bring in the feature you just did
[19:06] <jam> abli: alternatively, you can look at something like: http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html
[19:06] <jam> for how to take a branch that has multiple features developed on it
[19:06] <abli> and then merge to to_rev, and commit, right? But that will show the revisions up to from_rev as merged, won't it? I will want to merge those at some later point
[19:06] <jam> and split it into independent branches
[19:19] <abli> Ok, thanks, I'll try out that refactoring thing.
[20:57] <emmajane> igc, pong (belated)
[20:58] <igc> hi emmajane, how are you?
[20:58] <beuno> mwhudson, Peng_, I think I have LH working with 3.0.0
[20:58] <emmajane> igc, hey :)
[20:59] <beuno> just need to iron out a few errors with the search js
[21:00] <mwhudson> beuno: cool
[21:10] <thumper> beuno: 3.0.0 what?
[21:13] <lifeless> moin
[21:13] <lifeless> YUI I imagine
[21:16] <igc> hi lifeless, thumper
[21:23] <beuno> thumper, lifeless, yes
[21:23] <beuno> I'm pretending this is research for the lazr-js sprint in dallas
[21:26] <lifeless> beuno: 'it is'
[21:29] <jml> I've recently been motivated to care about this bug: https://bugs.launchpad.net/bzr/+bug/152008
[21:35] <jml> lifeless, you now have commit rights to testtools.
[21:36] <lifeless> cool
[21:36] <lifeless> [what prompted this?]
[21:36] <jml> I'm yak shaving :)
[21:37] <jml> I want to release txsshserver
[21:37] <jml> to do this, I need to make sure the tests pass
[21:37] <jml> right now, running the tests in trial makes them all skip
[21:37] <jml> I have NFI why that's the case, but suspect a bug in testtools (or maybe in trial)
[21:37] <lifeless> awesome
[21:38] <jml> you've been keeping up to date with python test development much more than I, so I feel that you are in a much better position to get stuff landed.
[21:38] <jml> and I feel I'll be less of a blocker if I don't have sole commit rights.
[21:39] <lifeless> what was your previous 'policy' about reviews of committer's code
[21:39] <lifeless> and how do you want me to behave
[21:40] <lifeless> e.g. 2 +1s, then land, or 'if you think it is right just land', or 2 +1s with a timeout?
[21:41] <lifeless> jml: ^
[21:43] <jml> lifeless, my policy has been patches get reviewed, and I land patches without review. but I was the sole controller.
[21:43] <jml> lifeless, I just got on a call w/ thumper, will actually think about policy when I'm off :)
[21:44] <lifeless> jml: indeed, but you can see why I ask :)
[21:44] <jml> yes :)
[21:44] <lifeless> jml: if you're to be less of a blocker we need committing to be quorate without needing you
[21:45] <jml> lifeless, that's right.
[21:45] <lifeless> enjoy the call
[21:45] <jml> :)
[21:46] <jam> jelmer: ping (still need a newer bzr-rewrite for 2.1.0b1 release...)
[21:46] <jam> morning lifeless
[21:47] <lifeless> hi jam
[21:47] <igc> hi jam, jml
[21:48] <jml> igc, hi
[21:49] <igc> emmajane: my email from last week? Did I miss your reply or is it still coming?
[21:49] <emmajane> igc, email from last week?
[21:49] <emmajane> igc, on-list?
[21:49] <igc> emmajane: no, just to you
[21:49]  * emmajane checks the backlog of lsit email.
[21:49] <emmajane> oh. hrm.
[21:49] <jam> morning igc
[21:49] <emmajane> igc, can you resend?
[21:50] <igc> emmajane: it was the one about templating, etc - shall do
[21:50] <GaryvdM> Hi jam - Thanks for the bzr-beta-ppa approval.
[21:50] <emmajane> igc, thanks. I don't remember getting one to me about templating. :/
[21:51] <igc> emmajane: just re-forwarded it now - date was 12/Oct; title was "Next steps ..."
[21:51] <jam> GaryvdM: no problem
[21:51] <jam> easier than having you request a copy every month :)
[21:51] <GaryvdM> :-)
[21:52] <emmajane> igc, got it this time. I'm not sure where the other one went. :/
[21:52]  * emmajane reads
[21:52] <igc> jam, lifeless: OOo fast-imports now with latest trunk and cache of inventories cut down to 5 (was 100)
[21:53] <igc> jam, lifeless: I'm just trying qt now with a few different cache sizes to see memory and speed impact
[21:53] <emmajane> igc, Good list. I'll send a response back tonight with a plan.
[21:53] <igc> emmajane: thanks
[21:54] <emmajane> no problem! thanks for pinging me about it.
[21:54] <jam> igc: you're saying that it succeeds at importing w/ a cache of only 5?
[21:54] <jam> (and cache of what?)
[21:54]  * ToyKeeper ponders how to rebase a series of merges on top of a new upstream tarball...  bzr-rebase seems to think the source branch (with new tarball) is a descendent of the target branch (with merges), and pulls instead of rebasing.
[21:54] <jam> btw, it *might* be reasonable to handle a hunk stream by copying everything into the chk store, and then extracting it from there.
[21:55] <jam> though 'pack' won't gc those extra objects.
[21:55] <ToyKeeper> Hmm, I bet a null commit before the merges would un-confuse it.
[21:56] <himanshu__> Hi, I am getting following error :bzr: ERROR: Unknown repository format: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n'
[21:56] <himanshu__> Not sure why?
[21:57] <ToyKeeper> himanshu__: It sounds like your version of bzr is too old to read the repository.
[21:57] <himanshu__> bzr server is running on remote repository  with version 2.0.1
[21:58] <himanshu__> my client machine is ubuntu with bzr version 1.6.1
[21:58] <ToyKeeper> It's because your client is old, then.
[21:58] <himanshu__> so new bzr version is not backward compatible with any bzr version?
[21:59] <ToyKeeper> It is if you're using a backward-compatible format.  Format 2a is compatible back to bzr 1.16...
[22:00] <fullermd> (though you really would rather not use it with <2.0.0)
[22:00] <fullermd> _bzr_ is compatible; that _repo_ isn't.
[22:00] <ToyKeeper> Ah, okay.
[22:01] <ToyKeeper> himanshu__: Upgrading your client would probably be the best option, but you could also rebuilt the repo with an old format, like 1.6.1-rich-root.
[22:01] <ToyKeeper> s/rebuilt/rebuild/
[22:02] <himanshu__> so what do you suggest..Shoudl I rebuilt repo with old format  or upgrade client
[22:02] <fullermd> Upgrade the client, definitely.
[22:02] <fullermd> 2a is a better format in a lot of ways, and unrelated to that 2.0.1 will be a lot faster etc. than 1.6.1 as well.
[22:03] <himanshu__> what is the quickest way to upgrade client on ubuntu?
[22:03] <himanshu__> I have installed using apt-get install bzr
[22:03] <fullermd> Older format mirrors are for when (for whatever reason) clients _can't_ be upgraded.
[22:04] <fullermd> That probably involves PPA's, but I don't know any details about it.
[22:04] <himanshu__> ohk so I need to build it from source ?
[22:04] <ToyKeeper> Ubuntu backports may have it.
[22:04] <himanshu__> what is backports?
[22:04] <ToyKeeper> https://help.ubuntu.com/community/UbuntuBackports
[22:04] <igc> jam: fastimport caches inventories
[22:04] <himanshu__> ok cool let me check
[22:05] <himanshu__> Also, 1 more question
[22:06] <GaryvdM> himanshu__: New versions can also be found in the ppa: https://launchpad.net/~bzr/+archive/ppa/
[22:06] <himanshu__> ok cool let me check
[22:07] <lifeless> jam: inventory cache
[22:07] <lifeless> jam: fast import has a huge one
[22:08] <ToyKeeper> BTW, know of any tools to modify fast-import files?  It would be nice sometimes to remove files, revisions, and other stuff from history.
[22:09] <himanshu__> I have 1 question related to supporting bzr repositor
[22:09] <ToyKeeper> It can be done by hand, but it's a lot of work.
[22:10] <himanshu__> say if I have 10 users acess to bzr repository but I want to ensure that no user can have read/write access in other user's project
[22:10] <himanshu__> how can that be possible?
[22:10] <jam> ToyKeeper: you may want to look at 'bzr replay' versus 'bzr rebase'
[22:10] <fullermd> himanshu__: Why do you need it in one repository?  Or do you?
[22:10] <ToyKeeper> jam: Ooh, sounds promising.  Thanks.  :)
[22:11] <himanshu__> so it possible to start bzr server with each user repository?
[22:11] <jam> igc: so you might be extra interested in the patch I'm about to propose again (chk_map changes). Providing you are caching chk inventories.
[22:11] <rockstar> ToyKeeper, I'm actually rather surprised you hadn't heard about bzr replay.
[22:12] <fullermd> himanshu__: The server and 'repositories' are almost completely decoupled.  You serve a directory tree, which may have one, two, or six hundred repositories under it.
[22:12] <fullermd> himanshu__: Now, the bzr server doesn't itself do any AAA.  You'd have to do that in a high level, via the web server for bzr+http, or the ssh daemon for bzr+ssh.
[22:13] <himanshu__> what is AAA?
[22:13] <fullermd> himanshu__: I've never messed with bzr+http; I use bzr+ssh everywhere.
[22:13] <fullermd> himanshu__: Authentication, Authorization, Accounting.
[22:14] <himanshu__> ok here is what i am doing rite now: I have created 1 bzr repository  and executed following command
[22:14] <himanshu__> nohup bzr serve --allow-writes --directory=/home/bzradmin/repository >> /home/bzradmin/logs/bzr_serve.log &
[22:14] <himanshu__> nohup serve-branches /home/bzradmin/repository >> /home/bzradmin/logs/bzr_loggerhead.log &
[22:14] <himanshu__> but this way I am giving everyone read-write access
[22:14] <igc> jam: cool
[22:14] <fullermd> Right.
[22:14]  * igc breakfast - bbl
[22:15] <himanshu__> but I just want to limit it to each user group
[22:15] <himanshu__> I mean each user group should not have any read-write access of other usergroup
[22:15] <himanshu__> not even on http
[22:15] <fullermd> I'd do it all via bzr+ssh (the writing, anyway).
[22:16] <fullermd> And use FS permissions.
[22:16] <ToyKeeper> rockstar: It was a hidden command...  :(
[22:16] <rockstar> ToyKeeper, those are the ones you find first usually.
[22:16] <rockstar> :)
[22:16] <fullermd> Really, there's no way to provide meaningful security differentiation within a repository; if you can write into it, you can change anything.  So you'd need one repo per slice of the auth domain.
[22:17] <himanshu__> how do you use bzr+ssh?
[22:17] <fullermd> Oh, I just use regular system accounts.
[22:18] <fullermd> You COULD do it with a ssh daemon that uses PAM or some other auth, and refers to an external database rather than using regular system accounts.
[22:18] <fullermd> But that would be rather more complicated.
[22:19] <himanshu__> so this way each usergroup will be having their own repository?
[22:19] <ToyKeeper> I haven't checked in a while, but if bzr-access ever got developed to a usable point, it might help.
[22:19] <fullermd> bzr-access can't provide control at a sub-repository level.
[22:19] <ToyKeeper> No, it can't.
[22:20] <fullermd> Nothing can, without bzr moving a ways.
[22:20] <lifeless> if you need privacy or integrity, use separate repos
[22:20] <lifeless> thats a design statement, not a feature statement
[22:21] <fullermd> himanshu__: You may be assigning more meaning to 'repository' than bzr does.  It's not like cvs/svn, where the 'repository' is an important semantic unit.
[22:21] <lifeless> we can and will remove the VFS eventually, or at least make pushing with it disabled work [modulo plugins this is the case already]
[22:21] <lifeless> and with the VFS removed many middling hostile attacks are prevented
[22:22] <fullermd> Yah, VFS is a hole you can drive a 11-dimensional multiverse through.
[22:22] <fullermd> I didn't know we have all the core actions moved off it.  That's pretty neat.
[22:23] <himanshu__> I am getting little confure here: say I need to support 10 usergroup over same bzr server completly isolated from one another
[22:23] <lifeless> fullermd: 2.0.0. baby
[22:23] <fullermd> (well, aside from having to longcut to it to find out the !@&$ format of a remote branch...)
[22:23] <lifeless> himanshu__: then you have 10 repositories
[22:23] <lifeless> himanshu__: or more if you like :)
[22:23] <himanshu__> then I should create 10 different respository setting read-write access according to group
[22:24] <fullermd> himanshu__: Remember, your users will [practically] never be interacting with repositories; they'll be dealing with branches.  So think in terms of a directory hierarchy of branches, slicing that up how access control needs to be.
[22:24] <fullermd> Then you can see where it's worth creating repositories within that.
[22:25] <himanshu__> then each user group can access their resporitory over the bzr+ssh
[22:27] <himanshu__> I agree that users will always interact with branches but I need a way to make sure that set of branches are accesible to only 1 particular user group
[22:28] <fullermd> Yah, having those branches have all their data be 775/664 works well for that.
[22:28] <himanshu__> ok  cool
[22:29] <himanshu__> so it seems 1 repository, within that I create sub directory fo reach user group
[22:30] <fullermd> No, that's a step backward, since they all have to write into the repository.
[22:30] <fullermd> Step back and forget about [explicit] repositories; just arrange a bunch of individual standalone branches.
[22:30] <himanshu__> ok
[22:31] <fullermd> So you end up with $ROOT/team1/ and $ROOT/team2/ and $ROOT/team3/ etc. dirs, each full of branches.
[22:31] <himanshu__> ok
[22:31] <fullermd> With everything under teamX set with that group having write access, and everybody else just read (or no access, if that's what you want)
[22:31] <fullermd> So, you can run with just that, and not create any repositories.
[22:32] <fullermd> That has its shortcomings, but it's functionally equivalent.
[22:32] <himanshu__> what is the shortcoming here?
[22:32] <fullermd> Every branch has a full copy of the history, so (assuming that some/many/most/all of the branches are of the same project), you'll have a giant pile of copies of the same data.
[22:32] <fullermd> Which eats up disk space, and also means the users can end up having to push up more data to get their work done.
[22:33] <fullermd> But, ignoring space and time, everything acts just like it would with repos.
[22:33] <fullermd> Now, if we assume that most/all of these branches are of the same project, just creating a repo in each teamX/ branch means we have 10 copies of the history (one for each team), but that's not so bad probably.
[22:34] <himanshu__> i want branches of same project in teamX directory only
[22:34] <fullermd> You could have a repo for teamX/ even if all the branches in it were of different projects of course, but it wouldn't gain anything in that case (since there's no common history to store only 1 copy of)
[22:35] <fullermd> So, it sounds like you want a tree sorta like that, with a repo per teams and its perms set as appropriate.
[22:35] <himanshu__> so requirement is that if there is some projectX, then that projectX is just limited to TeamX, cannot be read/write by any other Team
[22:39] <himanshu__> thanks a lot fullermd, i got your suggestions
[22:40] <himanshu__> From my requirement, it makes sense to maintain 1 respoitory for each Team as they have nothing in common, I mean no project, no read-write access
[22:40] <fullermd> Sounds like a perfect fit then   :)
[22:41] <himanshu__> so when I start bzr server, this would be wrong choice"
[22:41] <himanshu__> nohup bzr serve --allow-writes --directory=/home/bzradmin/repository >> /home/bzradmin/logs/bzr_serve.log &
[22:41] <himanshu__> "
[22:41] <himanshu__> so how should I start server?
[22:42] <himanshu__> assume I have multiple respository
[22:43] <himanshu__> should I give path of top level common directory maintaningg all user repos as underlying sub directory
[22:44] <fullermd> You don't 'start' the server.  The users use bzr+ssh, which ssh's in and spawns bzr itself behind the scenes.
[22:45] <fullermd> So you just have bzr installed and in $PATH, and them able to login.
[22:45] <himanshu__> ok cool
[22:45] <fullermd> Then they give whatever path they want.  Even a path to one of the other teams if they want, but since the filesystem permissions won't let them write...
[22:45] <jml> lifeless, how's this: all patches need reviews from a committer who is not the author. If the author is a committer, there is a 24hr timeout on this rule.
[22:45] <himanshu__> ok cool
[22:45] <fullermd> So they'd do something like "bzr branch bzr+ssh://me@server/bzr/team5/mainbranch mylocalbranch"
[22:46] <himanshu__> ok cool~
[22:46] <lifeless> jml: sounds fine to me
[22:46] <himanshu__> Also, is it possible if I can expose this kind of view over http using loggerhead?
[22:46] <jml> lifeless, cool.
[22:46] <jml> lifeless, let's do that then.
[22:48] <fullermd> himanshu__: Well, since you've moved the devs to bzr+ssh, you don't need writes over the web (or over a 'bzr serve' bzr:// server, if you still want to run one), so that just needs read access.
[22:48] <fullermd> If you wanted write over bzr+http, you'd have to do access control via Apache (well, or whatever other httpd you have).
[22:48] <himanshu__> ok cool
[23:22] <lamalex> is there a way to only get part of a branch?
[23:32] <beuno> mwhudson, https://code.edge.launchpad.net/~beuno/loggerhead/yui3-0-0/+merge/13744
[23:32] <beuno> in case you have a little while
[23:32] <beuno> notifying oopsed
[23:32] <beuno> so I'm doing it manually  :)
[23:32] <beuno> Peng_, ^
[23:32] <lamalex> im trying to set up bzrbuilder, but our debian package branch is in a subdir of the branch
[23:33] <lamalex> is there a way to just get the debian dir of the branch or should i just use run to do an mv
[23:33] <beuno> lamalex, there's no way to get a specific dir with bzr at the moment
[23:34] <lamalex> so i guess run mv is the way for now
[23:34] <lamalex> thanks
[23:35] <lifeless> jml: is the new team subscribed for reviews to trunk ?
[23:37] <jml> lifeless, is now.
[23:37] <lifeless> :)
[23:37] <jml> g'night.
[23:37] <lifeless> night


[21:47] <wrst> Omnifrog: how you doing?
[22:01] <DJOmnifrog>  Radio KoL: Orleans - Dance With Me - What The Frog??? ....It's Frog time! Now with more H2G2 Contest! - Omnifrog - What The Frog?
[22:01] <DJOmnifrog> err
[22:01] <DJOmnifrog> oops
[22:01] <DJOmnifrog> hi wrst
[22:01] <DJOmnifrog> brb
[22:02] <wrst> haha
[22:02] <wrst> :)
[22:12] <DJOmnifrog> doing good wrst  !
[22:16] <wrst> awesome, hopefully no more emergency surgeries?
[22:19] <cyberanger> or non-emergency for that matter
[22:20] <wrst> good point cyberanger!
[22:21] <DJOmnifrog> yeah, that was teh SUCK!
[22:23] <wrst> i'm sure DJOmnifrog
[22:24] <DJOmnifrog> I'm still purple all over but able to do things again
[22:24] <DJOmnifrog> light duty things
[22:52] <wrst> good


[07:44] <ikonia> that doesn't seem right
[07:50] <IdleOne> I don't think it is
[11:58] <ikonia> @mark #kubuntu eur33r problem in #ubuntu - kicked, being purposfully impossible to help in #kubuntu after being banned from #ubuntu
[13:11] <Myrtti> he's acting ok in -fi, which is a bit surprising
[17:29] <ikonia> johnjohn101 possible syko also
[17:30] <ikonia> ident = richards (he's been using richardstallman) and on a vpn account/provider he's used before
[17:30] <ikonia> and just joined after his other account was kicked from #freenode
[17:43] <ikonia> another account for syko = turblance,
[17:43] <ikonia> all registered on freenode
[17:46] <ikonia> turbulence sorry
[17:57] <kloeri> that's not syko
[17:57] <ikonia> it is
[17:57] <ikonia> he confirmed it to me
[17:57] <kloeri> nope
[17:57] <ikonia> lancer/syko/stein/any_one_of_his_mental_accounts
[17:57] <kloeri> it's cholby
[17:58] <ikonia> then in that case they are the same person/thing
[17:58] <kloeri> and yeah, he'll probably confirm any shit you ask him to
[17:58] <ikonia> as he quoted past incidents that I hadn't mentioned before
[17:58] <kloeri> nope but believe that if you like
[17:58] <ikonia> well, I can only go by the info he's given me, if that's wrong, then he's got very lucky quoting things
[17:59] <ikonia> kloeri: is there no corolation between them at all ?
[17:59] <kloeri> I'm quite certain they're different people
[18:00] <kloeri> both idiots but different idiots
[18:00] <Flannel> Hooray for paranoia and witch hunts!
[18:00] <ikonia> they must have got very lucky with the quotes they gave me then, which just seemed very unlikley
[18:01] <kloeri> turbulence == cholby has been known ever since he created that account (along with another ~70 accounts of his or whatever the current count is)
[18:01] <ikonia> 70 !!!!
[18:02]  * kloeri shrugs
[18:03] <Pici> cholby is problems
[18:03] <ikonia> he must have just got very lucky with his wording then
[18:03] <kloeri> he's just a very persistent guy with lots of psychological problems
[18:04] <kloeri> who's not helping himself by also being a drug addict, an alcoholoc and so on
[18:04] <ikonia> oh, so you seem to know a pretty big picture on him then
[18:05] <kloeri> yes, I've been talking to him and hearing about him for years
[18:05] <ikonia> fair enough
[18:32] <ikonia> sadly, all grown out of now
[18:45] <ikonia> I have placed 15 gags on the ubottu host - you have 2 hours to find them
 I need in neuroprogrammer on my ubuntu
[20:21] <genii> Bah, again?
[20:34] <IdleOne> no
[20:34] <IdleOne> the bots are not synced
[20:35] <IdleOne> maybe restarting them?
[20:56] <hotmedal> I'm somehow banned in #ubuntu. Haven't been there in a month
[20:58] <IdleOne> syko again
[20:58] <IdleOne> you should know by now the ban will not be removed. Have a good day.
[20:59] <hotmedal> why not
[20:59] <hotmedal> who is syko
[21:03] <IdleOne> simply because you are a constant problem in #ubuntu
[21:04] <hotmedal> but I haven't been there in a month and I don't remember departing on less than friendly terms
[21:14] <hotmedal> come on! am I going to get anything other than false accusation here?
[21:14] <hotmedal> or is there some other channel that deals with these issues?
[21:28] <AlanBell> hotmedal: what nick were you using at that time?
[21:28] <hotmedal> this same nick
[21:35] <IdleOne> hotmedal: I'm going to remove the ban, we may have ,mistaken you for someone else.
[21:35] <IdleOne> !guidelines
[21:35] <IdleOne> all the same I would like you to read the guidelines so we can avoid any problems in the future
[21:36] <hotmedal> thanks, I'll do it once I get my gnome back
[21:36] <IdleOne> you should be able to join now
[21:37] <AlanBell> hotmedal: I would recommend you get a cloak, you can ask for one in #freenode
[21:37] <hotmedal> I'm pretty much an IRC noob, no idea what a cloak is, but I'l look into it
[21:37] <hotmedal> and yes, I can join now
[21:38] <IdleOne> !cloak
[21:38] <IdleOne> you want the unaffiliated one
[21:38] <AlanBell> ok, a cloak means you log on to freenode with a password, then bans on IP address ranges won't pick you up by accident
[21:38] <hotmedal> oh, ok
[21:42] <IdleOne> hotmedal: if there is nothing else please part this channel.
[21:43] <hotmedal> I just need to keep these links here until I get the gui back
[21:44] <hotmedal> thanks and bye
[22:30] <holstein> Flannel: no need... im going to thin it out a bit anyways.. but nothing i said was against the COC
[22:30] <holstein> and, i welcome you to disagree, and "set the record straight" so to speak, if you disagree with me, at anytime
[22:31] <Flannel> holstein: IRC Guidelines, "When helping, be helpful."  Telling someone summarily to disable their hardware after software makes it not work is not helpful.
[22:33] <holstein> Flannel: and, you are welcome to share that with the user.. i think a fingerprint reader, as another user who was *not* reprimanded had imlied, is *not* a key piece of hardware.. and may never be supported properly
[22:33] <holstein> implied*
[22:33] <holstein> again, i welcome you to point out to any user at any time if you disagee.. but, my intentions were meant to be constructive
[22:33] <Flannel> holstein: I don't understand how if it was supported, say, a month ago, but then stops working properly, you can claim it "may never be supported" in good faith
[22:34] <holstein> Flannel: maybe i hadnt read that far back in the scroll?
[22:34] <holstein> Flannel: there are many reasons i might have suggested that. but, i have a record of being generally helpful and constructive, even with the most challenging of support cases
[22:35] <Flannel> holstein: That's fair, but yet, I pointed that fact out to you a few times already.
[22:35] <holstein> the logs are public and logged.. but, if you feel that.. thats fine.. and again, i welcome you to disagree
[22:35] <holstein> Flannel: sure. and i didnt disagre with you in channel
[22:35] <holstein> Flannel: we were in OT where you instigated the exchange
[22:36] <Flannel> holstein: I know, and then halfway through that, you went back to #ubuntu to tell him to contact his manufacturer for support
[22:36] <holstein> Flannel: i did.. and ideally, they would
[22:37] <Flannel> Except, it worked [yesterday], so it's a software issue, not a hardware one.
[22:37] <Flannel> and now I've told you this a few + 1 times.
[22:37] <holstein> Flannel: otherwise, i hadnt read back far enough to say that it could have been a kernel regression.. i thought it was that the hardware was never going to work
[22:38] <holstein> Flannel: and, i felt attacked by what you had said to me.. because, what you had said to me was arguably constructive.. and i likely took that personal.. and i am allowed to.. and i dont feel that i took that out in the #ubuntu channel on that user
[22:38] <Flannel> yet you're still claiming they should contact their hardware vendor?
[22:38] <holstein> Flannel: but, as i said, i need to think it out. and im out of that channel
[22:38] <Flannel> holstein: You just did it six lines ago
[22:38] <holstein> Flannel: so, agree to disagree? and you are, as i said, always welcome to state to a user that i am wrong
[22:39] <holstein> Flannel: OK.. thanks for your time
[22:43] <Flannel> well, that went poorly.
[23:03] <IdleOne> Only because you are welcome to disagree, but that doesn't mean I will consider your opinion.
[23:07] <Flannel> Nah, some of it was my fault.  I shouldn't have asked him in here until I wasn't distracted.


[00:23] -queuebot:#ubuntu-release- New binary: libnginx-mod-http-modsecurity [amd64] (mantic-proposed/universe) [1.0.3-1] (no packageset)
[00:23] -queuebot:#ubuntu-release- New binary: libnginx-mod-http-modsecurity [s390x] (mantic-proposed/universe) [1.0.3-1] (no packageset)
[00:24] -queuebot:#ubuntu-release- New binary: libnginx-mod-http-modsecurity [armhf] (mantic-proposed/universe) [1.0.3-1] (no packageset)
[00:24] -queuebot:#ubuntu-release- New binary: libnginx-mod-http-modsecurity [ppc64el] (mantic-proposed/universe) [1.0.3-1] (no packageset)
[00:25] -queuebot:#ubuntu-release- New binary: libnginx-mod-http-modsecurity [arm64] (mantic-proposed/universe) [1.0.3-1] (no packageset)
[00:47] -queuebot:#ubuntu-release- New binary: libnginx-mod-http-modsecurity [riscv64] (mantic-proposed/universe) [1.0.3-1] (no packageset)
[02:00] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Mantic Daily] has been updated (20230516)
[02:04] -queuebot:#ubuntu-release- Builds: Edubuntu Desktop amd64 [Mantic Daily] has been updated (20230516)
[02:16] -queuebot:#ubuntu-release- Builds: Xubuntu Minimal amd64 [Mantic Daily] has been updated (20230516)
[02:59] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Mantic Daily] has been updated (20230516)
[05:18] -queuebot:#ubuntu-release- New binary: wmmatrix [amd64] (mantic-proposed/none) [0.2-12.2] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: wmmatrix [ppc64el] (mantic-proposed/none) [0.2-12.2] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: wmmatrix [arm64] (mantic-proposed/none) [0.2-12.2] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: wmmatrix [s390x] (mantic-proposed/none) [0.2-12.2] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: wmmatrix [armhf] (mantic-proposed/none) [0.2-12.2] (no packageset)
[05:24] -queuebot:#ubuntu-release- New: accepted libnginx-mod-http-modsecurity [arm64] (mantic-proposed) [1.0.3-1]
[05:24] -queuebot:#ubuntu-release- New: accepted libnginx-mod-http-modsecurity [riscv64] (mantic-proposed) [1.0.3-1]
[05:24] -queuebot:#ubuntu-release- New: accepted wmmatrix [arm64] (mantic-proposed) [0.2-12.2]
[05:24] -queuebot:#ubuntu-release- New: accepted wmmatrix [ppc64el] (mantic-proposed) [0.2-12.2]
[05:24] -queuebot:#ubuntu-release- New: accepted libnginx-mod-http-modsecurity [armhf] (mantic-proposed) [1.0.3-1]
[05:24] -queuebot:#ubuntu-release- New: accepted wmmatrix [armhf] (mantic-proposed) [0.2-12.2]
[05:24] -queuebot:#ubuntu-release- New: accepted wmmatrix [amd64] (mantic-proposed) [0.2-12.2]
[05:24] -queuebot:#ubuntu-release- New: accepted wmmatrix [s390x] (mantic-proposed) [0.2-12.2]
[05:24] -queuebot:#ubuntu-release- New: accepted libnginx-mod-http-modsecurity [amd64] (mantic-proposed) [1.0.3-1]
[05:24] -queuebot:#ubuntu-release- New: accepted libnginx-mod-http-modsecurity [s390x] (mantic-proposed) [1.0.3-1]
[05:24] -queuebot:#ubuntu-release- New: accepted omemo-dr [arm64] (mantic-proposed) [0.99.1-1]
[05:24] -queuebot:#ubuntu-release- New: accepted omemo-dr [riscv64] (mantic-proposed) [0.99.1-1]
[05:24] -queuebot:#ubuntu-release- New: accepted libnginx-mod-http-modsecurity [ppc64el] (mantic-proposed) [1.0.3-1]
[05:24] -queuebot:#ubuntu-release- New: accepted omemo-dr [ppc64el] (mantic-proposed) [0.99.1-1]
[05:24] -queuebot:#ubuntu-release- New: accepted omemo-dr [amd64] (mantic-proposed) [0.99.1-1]
[05:24] -queuebot:#ubuntu-release- New: accepted omemo-dr [s390x] (mantic-proposed) [0.99.1-1]
[05:27] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Mantic Daily] has been updated (20230516)
[05:27] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Mantic Daily] has been updated (20230516)
[05:33] -queuebot:#ubuntu-release- New binary: wmmatrix [riscv64] (mantic-proposed/universe) [0.2-12.2] (no packageset)
[05:55] -queuebot:#ubuntu-release- New: accepted wmmatrix [riscv64] (mantic-proposed) [0.2-12.2]
[06:31] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Mantic Daily] has been updated (20230516)
[06:31] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Mantic Daily] has been updated (20230516)
[06:31] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Mantic Daily] has been updated (20230516)
[06:31] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Mantic Daily] has been updated (20230516)
[06:31] -queuebot:#ubuntu-release- Builds: Ubuntu Base riscv64 [Mantic Daily] has been updated (20230516)
[06:31] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Mantic Daily] has been updated (20230516)
[06:33] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Mantic Daily] has been updated (20230516)
[07:25] <LocutusOfBorg> OSError: [Errno 28] No space left on device
[07:25] <LocutusOfBorg> boost1.81 is failing on arm64 and armhf, maybe big_packages please?
[07:53] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Mantic Daily] has been updated (20230516)
[07:53] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Mantic Daily] has been updated (20230516)
[07:53] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Mantic Daily] has been updated (20230516)
[07:53] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Mantic Daily] has been updated (20230516)
[08:02] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Mantic Daily] has been updated (20230516)
[08:40] -queuebot:#ubuntu-release- Builds: Ubuntu Core amd64 edge [Mantic Daily] has been updated (20230516)
[09:01] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop (Legacy) amd64 [Mantic Daily] has been updated (20230516)
[10:26] -queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (lunar-proposed) [2.1.9-2ubuntu1.1]
[10:59] -queuebot:#ubuntu-release- Builds: Ubuntu WSL [Mantic Daily] has been updated<PHONE_NUMBER>)
[13:28] -queuebot:#ubuntu-release- Builds: Ubuntu Unity Desktop amd64 [Mantic Daily] has been updated (20230516)
[13:55] -queuebot:#ubuntu-release- Builds: Ubuntu Cinnamon Desktop amd64 [Mantic Daily] has been updated (20230516)
[14:35] -queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.13-0ubuntu5.3 => 2:17.0.13-0ubuntu6] (openstack, ubuntu-server)
[15:39] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Mantic Daily] has been updated (20230516)
[15:51] <bdmurray> vorlon: your stick-table-header change has been deployed
[16:00] <vorlon> bdmurray: woot thanks
[17:01] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Mantic Daily] has been updated (20230516)
[17:31] <ginggs> sticky table headers ftw!
[17:32] <bdmurray> Now I want them for the package names. ;-)
[17:42] <jbicha> yay
[18:22] -queuebot:#ubuntu-release- Unapproved: rejected gst-python1.0 [source] (jammy-proposed) [1.20.3-0ubuntu1]
[18:26] -queuebot:#ubuntu-release- Unapproved: rejected gst-plugins-ugly1.0 [source] (jammy-proposed) [1.20.3-0ubuntu1]
[18:42] <bdmurray> LocutusOfBorg: big_packages does not increase the amount of space available and its really the autopkgtest-cloud-worker units that are running out of space
[19:01] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Mantic Daily] has been updated (20230516)
[20:42] <ricotz> bdmurray, hi :), is there a solution in sight? the libreoffice autopkgtests having a hard time :(
[20:49] <bdmurray> ricotz: make the package smaller?
[20:50] <ricotz> bdmurray, maybe the number of parallel running tests is a problem?
[20:50] <ricotz> I mean the running instances
[20:50] <bdmurray> Could be
[20:51] <ricotz> the "running out of disk space" problem is not restricted to libreoffice
[20:53] <vorlon> well it's shared disk space on the units dispatching the tests, so it's probably libreoffice running other packages out of disk space
[20:55] <bdmurray> And multiple libreoffice and kernel tests running at once.
[21:01] <ricotz> ok, feel free to restrict the number for those
[21:01] <vorlon> there's not really an interface for doing so
[21:01] <vorlon> IIRC the problem we've been running into is the size of the logs generated by the libreoffice tests?
[21:44] <vorlon> there are a LOT of libreoffice tests queued in parallel.  I've culled all of them from the queues (except for the ppa ones) and we can retrigger one per arch per series once things settle.
[21:45] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Mantic Daily] has been updated (20230516.1)
[21:45] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64 [Mantic Daily] has been updated (20230516.1)
[21:47] <vorlon> 78 tests running in parallel.
[21:47] <vorlon> bdmurray: ^^ should we manually kill some of these off?
[21:48] <vorlon> 164 hits on "No space left on device" on https://autopkgtest.ubuntu.com/running
[21:51] <bdmurray> vorlon: I'm actively trying to clean things up
[21:51] <vorlon> bdmurray: ack
[22:05] <ricotz[m]> vorlon: bdmurray: thank you
[22:51] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Mantic Daily] has been updated (20230516)
[23:19] -queuebot:#ubuntu-release- New binary: v86d [amd64] (mantic-proposed/none) [0.1.10-2] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: xfonts-nexus [amd64] (mantic-proposed/none) [0.0.2-18] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: cvprac [amd64] (mantic-proposed/none) [1.3.1+dfsg-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: libapache-mod-auth-radius [amd64] (mantic-proposed/none) [1.5.8-2] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: node-react-highlight-words [amd64] (mantic-proposed/none) [0.20.0+~cs7.2.2-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: rust-cargo-options [ppc64el] (mantic-proposed/none) [0.6.0-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: force-ip-protocol [amd64] (mantic-proposed/none) [0.2.0-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: rust-cargo-options [amd64] (mantic-proposed/none) [0.6.0-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: libapache-mod-auth-radius [ppc64el] (mantic-proposed/none) [1.5.8-2] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: force-ip-protocol [s390x] (mantic-proposed/none) [0.2.0-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: node-emotion [amd64] (mantic-proposed/none) [11.10.7+ds1+~cs8.3.3-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: libapache-mod-auth-radius [s390x] (mantic-proposed/none) [1.5.8-2] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: force-ip-protocol [armhf] (mantic-proposed/none) [0.2.0-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: force-ip-protocol [ppc64el] (mantic-proposed/none) [0.2.0-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: force-ip-protocol [arm64] (mantic-proposed/none) [0.2.0-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: libapache-mod-auth-radius [armhf] (mantic-proposed/none) [1.5.8-2] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: rust-cargo-options [s390x] (mantic-proposed/none) [0.6.0-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: libapache-mod-auth-radius [arm64] (mantic-proposed/none) [1.5.8-2] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: rust-cargo-options [armhf] (mantic-proposed/none) [0.6.0-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: rust-cargo-options [arm64] (mantic-proposed/none) [0.6.0-1] (no packageset)
[23:30] -queuebot:#ubuntu-release- New: accepted rust-cargo-options [arm64] (mantic-proposed) [0.6.0-1]
[23:30] -queuebot:#ubuntu-release- New: accepted rust-cargo-options [s390x] (mantic-proposed) [0.6.0-1]
[23:30] -queuebot:#ubuntu-release- New: accepted force-ip-protocol [arm64] (mantic-proposed) [0.2.0-1]
[23:30] -queuebot:#ubuntu-release- New: accepted force-ip-protocol [ppc64el] (mantic-proposed) [0.2.0-1]
[23:30] -queuebot:#ubuntu-release- New: accepted libapache-mod-auth-radius [arm64] (mantic-proposed) [1.5.8-2]
[23:30] -queuebot:#ubuntu-release- New: accepted libapache-mod-auth-radius [ppc64el] (mantic-proposed) [1.5.8-2]
[23:30] -queuebot:#ubuntu-release- New: accepted node-emotion [amd64] (mantic-proposed) [11.10.7+ds1+~cs8.3.3-1]
[23:30] -queuebot:#ubuntu-release- New: accepted rust-cargo-options [ppc64el] (mantic-proposed) [0.6.0-1]
[23:30] -queuebot:#ubuntu-release- New: accepted force-ip-protocol [armhf] (mantic-proposed) [0.2.0-1]
[23:30] -queuebot:#ubuntu-release- New: accepted libapache-mod-auth-radius [armhf] (mantic-proposed) [1.5.8-2]
[23:30] -queuebot:#ubuntu-release- New: accepted rust-cargo-options [armhf] (mantic-proposed) [0.6.0-1]
[23:30] -queuebot:#ubuntu-release- New: accepted force-ip-protocol [s390x] (mantic-proposed) [0.2.0-1]
[23:30] -queuebot:#ubuntu-release- New: accepted libapache-mod-auth-radius [s390x] (mantic-proposed) [1.5.8-2]
[23:31] -queuebot:#ubuntu-release- New: accepted cvprac [amd64] (mantic-proposed) [1.3.1+dfsg-1]
[23:31] -queuebot:#ubuntu-release- New: accepted libapache-mod-auth-radius [amd64] (mantic-proposed) [1.5.8-2]
[23:31] -queuebot:#ubuntu-release- New: accepted rust-cargo-options [amd64] (mantic-proposed) [0.6.0-1]
[23:31] -queuebot:#ubuntu-release- New: accepted xfonts-nexus [amd64] (mantic-proposed) [0.0.2-18]
[23:31] -queuebot:#ubuntu-release- New: accepted force-ip-protocol [amd64] (mantic-proposed) [0.2.0-1]
[23:31] -queuebot:#ubuntu-release- New: accepted v86d [amd64] (mantic-proposed) [0.1.10-2]
[23:31] -queuebot:#ubuntu-release- New: accepted node-react-highlight-words [amd64] (mantic-proposed) [0.20.0+~cs7.2.2-1]
[23:34] -queuebot:#ubuntu-release- New binary: libapache-mod-auth-radius [riscv64] (mantic-proposed/universe) [1.5.8-2] (no packageset)
[23:36] -queuebot:#ubuntu-release- New binary: force-ip-protocol [riscv64] (mantic-proposed/universe) [0.2.0-1] (no packageset)
[23:37] -queuebot:#ubuntu-release- New binary: rust-cargo-options [riscv64] (mantic-proposed/universe) [0.6.0-1] (no packageset)
[23:45] -queuebot:#ubuntu-release- New: accepted rust-cargo-options [riscv64] (mantic-proposed) [0.6.0-1]
[23:46] -queuebot:#ubuntu-release- New: accepted force-ip-protocol [riscv64] (mantic-proposed) [0.2.0-1]
[23:46] -queuebot:#ubuntu-release- New: accepted libapache-mod-auth-radius [riscv64] (mantic-proposed) [1.5.8-2]