[00:07] <Noldorin> jelmer, doesn't like the upgrade :-(
[00:07] <jelmer_> Noldorin, which upgrade?
[00:07] <Noldorin> jelmer, to newest bzr-git/dulwich
[00:07] <Noldorin> Unable to load plugin u'git' from u'C:/Program Files (x86)/Bazaar/plugins'
[00:07] <Noldorin> bzr: ERROR: exceptions.KeyError: "Key 'git' already registered"
[00:08] <jelmer_> Noldorin, the bzr log file should have more information
[00:09] <Noldorin> oh wait; randomly working now hmm
[00:09] <Noldorin> bzr doesn't like symlinks in program files :O
[00:12] <Noldorin> jelmer, so a bit more playing around seems to reveal that this problem is due to the fact parent directories are not actually created (added to the git database?) before they get used
[00:13] <fullermd> git doesn't track directories period, neh?
[00:14] <Noldorin> fullermd, hmm, maybe that's the problem then?
[00:14] <Kamping_Kaiser> no it doesn't
[00:15] <fullermd> Noldorin: With git?  One of them anyway  ;)
[00:15] <Noldorin> fullermd, no with this bug jelmer and i are discussing about bzr-git :-)
[00:15] <Noldorin> fullermd, though i agree, it's a problem with git too hah
[00:17] <Noldorin> jelmer, thoughts?
[00:20] <jelmer_> Noldorin, I'm looking
[00:20] <Noldorin> ok :-)
[00:33] <Noldorin> right, so it's definitely one of the renames into tests/ failing...
[00:34] <Noldorin> *continues debugging*
[00:35]  * jelmer_ writes a testcase
[00:44] <yshavit> hi alll, I'm trying to use bzrlib (from python), but I keep getting an unsupported protocol exception. I'm using the remote_branch_url example from http://wiki.bazaar.canonical.com/BzrLib, straight copy-paste. bzrlib.version_info=(2, 4, 0, 'final', 0).  Any ideas?
[00:46] <Noldorin> jelmer_, the minimal mergeset that creates the issue is tests/IrcDotNet/ and tests/TraceAndTestImpactSettings.tracesettings
[00:46] <Noldorin> there are probably other equivalent minimals
[00:47] <jelmer_> yshavit: that example lacks this code: "from bzrlib.plugin import load_plugins; load_plugins()"
[00:48] <jelmer_> Noldorin, thanks
[00:48] <yshavit> jelmer_: thanks! is there someone I should email about that?
[00:49] <jelmer_> yshavit, I'm updating the page
[00:50] <yshavit> jelmer_: even better. Thanks for the quick help.
[00:50] <Noldorin> jelmer, sure. just some more playing around tells me (and trying to create new test branches which i dpush) that it's a highly order-dependent issue
[00:51] <Noldorin> jelmer, if you're digging through the code right now, i'll be here ready to assist :-)
[00:51] <Noldorin> (just not sure if there's much more i can do by *myself*)
[00:55] <jelmer_> Noldorin, thanks
[00:56] <Noldorin> jelmer, will be here watching TV for the next 2 hours about, so feel free to ping me with progress at any time then
[00:56] <jelmer_> heh, ok
[00:56] <jelmer_> I might get some sleep soon and look closer into this tomorrow
[00:57] <Noldorin> jelmer, heh okay, sure. i will be around tomorrow too
[00:57] <Noldorin> we are both in European time zones i suppose?
[00:58] <yshavit> jelmer_: is there any page that's somewhere between that front page and the autogenerated pydocs?  A tutorial-type thing? I can't find one on google.
[00:59] <jelmer_> yshavit, for the API? Not really. I generally just look at the tests in bzr itself for inspiration
[00:59] <jelmer_> what are you trying to do?
[00:59] <yshavit> jelmer: ah, okay
[00:59] <yshavit> jelmer_: for now, just merge. I've got the branch branched locally (through bzrlib)
[01:00] <yshavit> jelmer_: but in the larger scope, I'm also trying to teach myself how to fish :)
[01:12] <Noldorin> jelmer, well, feel free to ping me tomorrow after about 1pm, if that works for you better...
[05:12] <poolie> hi all
[06:10] <poolie> hi vila
[06:22] <vila> hey poolie, hi all :)
[06:31] <vila> jelmer: do we need to follow https://wiki.ubuntu.com/FreezeExceptionProcess for 2.4.1 on oneiric or is there some shortcut since we don't " introduce a new upstream version with new features and/or ABI/API changes" ?
 zzzzzz
[06:31] <poolie> ;)
[06:31] <vila> :)
[06:33] <vila> jelmer, poolie: I think we qualify for "FeatureFreeze for bugfix-only updates" which says "Up through RC, if a developer believes an upload of a new upstream release that just has bug fixes in it is warranted, they may upload it."
[06:33] <vila> poolie: by the way, can *you* upload ?
[06:33] <poolie> i probably can, yes
[06:33] <poolie> since you said it was already up i just wanted to understand the situation
[06:34] <vila> that was a rhetoric question, AIUI jelmer should already have the branch/package ready for that
[06:34] <poolie> i'm not sure if it's more appropriate to request a sync or to merge and upload
[06:34] <poolie> ok
[06:34] <vila> poolie: justasec, searching the IRC log
[06:35] <vila> of course xchat history threshold is just where it shouldn't
[06:35] <poolie> vila, so that "biweekly meetings" thread is quite relevant to our discussion last night
[06:36] <vila> Sep 13 17:30:51 <jelmer>	vila: bzr-2.4.1-1 uploaded to debian, 2.4.1-1ubuntu1 now building..
[06:36] <poolie> oh ok, cool
[06:36] <vila> poolie: which thread ?!?!?!
[06:37] <poolie> on udd
[06:37] <poolie> you are subscribed?
[06:37] <vila> AFAIK, yes
[06:38] <vila><EMAIL_ADDRESS>right ?
[06:38] <poolie> no, https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
[06:39] <vila> right, both end up in the same mailbox here
[06:40] <poolie> ok
[06:40] <vila> ... wth, I have a filter for it but I'm not subscribed ???
[06:41] <poolie> vila, i wouldn't say bug 849715 is a really high priority unless it's trivial
[06:41] <vila> damn, yes I am subscribed
[06:41] <poolie> classic case of of course per-project priority vs team priority
[06:41] <vila> poolie: high in the plugin context and yes it's trivial
[06:42] <vila> I agree it's not high in the team context
[06:42] <poolie> so you've got it?
[06:42] <poolie> i mean, got the mail from the udd list?
[06:42] <vila> yup
[06:42] <vila> marked as read
[06:43] <vila> except for james's one which I didn't recognize as matching your reference
[06:44] <vila> ok, read, I see your point, and I can only repeat that having goals bigger than bugs but smaller than strategic goals will help
[06:46] <vila> huh, did james_w moved from UTC+1 tz to UTC-4 tz ?
[06:48] <bradm> hi
[06:48] <poolie> yes, to canada
[06:48] <bradm> so, bug#788072
[06:49] <bradm> we've got two servers being bitten by it now
[06:49] <poolie> bradm, does it consistently fail?
[06:49] <vila> oooooh
[06:49] <poolie> did something on this machine change when it started happeing?
[06:49] <bradm> poolie: seems to be consistent
[06:50] <bradm> I can't say if anything changed, its a lp builder so I don't know what else has been going on
[06:50] <vila> bug #788072
[06:50] <bradm> there's been general package upgrades, I don't usually use these machines all that often so I can't say when it started
[06:50] <poolie> how urgent is it to fix this?
[06:50] <poolie> we could change it so that it at least doesn't mask the error
[06:51] <poolie> if we try a fix, would you be able to run bzr eg from a branch to see if it fails the same way
[06:51] <bradm> I think its breaking our use of puppet on the boxes, since we've got etc in bzr
[06:51] <poolie> for that matter, can you see if it works the same way with the latest bzr 2.3 from the ppa?
[06:51] <bradm> I can certainly try some stuff
[06:52] <vila> bradm: AIUI, we have never been able to reproduce it and my last debug attempts with lamont pretty much convinced me it was a weird local install issue
[06:53] <poolie> vila, in the standup yesterday you said something about making udd robust about lp downtime
[06:53] <bradm> vila: fwiw, I don't know if we can rule that out, since these are both lp buildds, its possible there's something local
[06:53] <vila> poolie: yup, that's my targets for today
[06:53] <poolie> i guess that's https://bugs.launchpad.net/udd/+bug/795321 assigned to jr, not obviously started
[06:53] <vila> bradm: oh, new context then ! Can you add that to the bug ?
[06:53] <vila> poolie: yup
[06:54] <poolie> i'm not sure that increasing the parallelism is all that important at the moment compared to some specific failures
[06:54] <bradm> this is interesting, one of them is bzr 3.2.1
[06:54] <bradm> er, 2.3.1 even
[06:54] <bradm> silly fingers
[06:55] <vila> poolie: you mean bug #724893 ?
[06:55] <bradm> and the other is 2.3.3
[06:55] <vila> poolie: the issue here is not to increase parallelism but that this bug can happen *now* triggered by any tweak anywhere
[06:56] <poolie> ok
[06:56] <poolie> does that show up as an actual import failure?
[06:56] <poolie> if so we should be able to measure how many suffer from it
[06:56] <vila> poolie: what ? bug #724893 ?
[06:56] <poolie> yes, that
[06:57] <jam> morning all
[06:57] <vila> poolie: it's not package specific at all, it's a bug in the design and we are lucky that it doesn't trigger more often
[06:57] <poolie> let's finish with bradm first
[06:57] <poolie> bradm, that's worth adding too
[06:57] <poolie> so the short story is, if we have something we think will help, you can deploy and test it?
[06:57] <bradm> poolie: I'd say so, given that the existing bzr stuff is busted
[06:58] <poolie> ok
[06:58] <poolie> i assigned it to the team
[06:58] <poolie> hi jam
[06:59] <bradm> just added a comment about the 2nd server and them being lp buildds
[06:59] <poolie> vila, i know it's not caused by the particular package, but my question is whether the import logs will tell us how often it occurs
[06:59] <poolie> if it's not actually often, it doesn't need to be critical
[07:00] <vila> ok, I resign, downgrade it to low if you wish, the day we'll encounter it because some totally unrelated optimization make the imports faster... we'll marked it critical
[07:01] <poolie> i'm just trying to understand the situation
[07:02] <vila> poolie: both mass_import and import_package want to update a db, as of today, there is no contention because imports are slow enough
[07:02] <vila> increasing parallelism (as I did as an experiment) revealed the bug and made it obvious
[07:02] <vila> but the bug is there nevertheless
[07:03] <jam> My 2c, if we don't have to stop everything and work on it, it isn't "Critical", it can be "High", it can be in our "bugs to work on next" list, but that doesn't make it *Critical*.
[07:03] <vila> I don't think we still have the logs for the last debian massive import where this occured
[07:03] <jam> I don't think anyone has said it isn't a bug
[07:03] <jam> or worth fixing, etc.
[07:04] <vila> jam: you already said that in the comment and I disagreed and still do
[07:04] <jam> vila: then why aren't you working on it *right now*, if it is critical
[07:04] <jam> ?
[07:04] <poolie> vila, jam said what?
[07:04] <jam> If *you* feel it is critical, then certainly it should trump the config stuff you are doing, etc.
[07:04] <jam> poolie: I said I didn't feel the bug was "Critical"
[07:05] <jam> vila: I'm not trying to start the argument again. But that is what Critical is supposed to mean. At least in my understanding.
[07:05] <jam> "This bug should be fixed before all High priority bugs"
[07:05] <poolie> jam, that is what critical ought to mean
[07:05] <poolie> in fact "even ahead of other work that's already in progress"
[07:05] <vila> to me it means a bug that can break the whole package importer
[07:05] <poolie> we haven't always been great about doing it but we shouldn't dilute it ay further
[07:05] <vila> and that needs to be fixed to resurrect it
[07:09] <bradm> poolie: anyway, let me know if you need any more info, or have something for us to try
[07:10] <vila> jam: I didn't start working on it because: 1) you pointed me to wal which is more complicated than a file-based locking, 2) as mentioned repeatedly this doesn't occur *yet* and I see nothing in the pipe that will trigger it (once 2.4 (and its optimizations)  is deployed on jubany, I may reconsider)
[07:11] <poolie> bradm, ok, i will, i'm not personally going to start on it now
[07:11] <poolie> vila, il'l see if i can get your config things unblocked soon
[07:11] <bradm> poolie: no worries
[07:11] <poolie> oneiric's borked, biab
[07:11] <vila> jam: I'd appreciate if you could make more constructive suggestions about config instead of considering a pet project, there are numerous, real and deep issues around this area
[07:13] <bradm> poolie: looks like this bug has been around for a bit and it seems to only be hitting 2 servers, so its not ultra high priority
[07:13] <poolie> ok
[07:13] <poolie> it would be nice to know why only those two
[07:13] <poolie> if you know when the problem started perhaps you can attach the dpkg.log
[07:15] <bradm> poolie: the server I'm seeing started within the last day or so I'm guessing from some puppet stuff
[07:16] <bradm> poolie: but the last thing in dpkg.log was apache stuff about 2 weeks ago
[07:16] <poolie> halp! puppet!
[07:16] <vila> bradm: why are those builds still using bzr < 2.3.4 (not strictly related but well, who knows, may be some upgrade went wrong)
[07:17] <bradm> vila: I don't know, but they're fully up to date according to the current sources.list on them
[07:17] <vila> bradm: 8-/ no -updates there ?
[07:18] <bradm> another random lp buildd has 2.3.1 as well
[07:18] <vila> err wait, what ubuntu release are they based on ?
[07:18] <bradm> vila: hardy
[07:18] <vila> ha, ok, thanks
[07:19] <vila> hmm, I think jelmer has backported 2.4 for hardy-cat recently
[07:19] <bradm> these definately have hardy-cat on them
[07:19] <vila> or is it jelmer_ :)
[07:19] <bradm> interesting, and hardy-cat-buildd
[07:20] <vila> dunno about that last one but I'm pretty sure jelmer is already trying to address some buildd issues so I think he targeted the right one
[07:20] <bradm> vila: if there is a hardy-cat versoin of 2.4 its not on our servers
[07:20] <bradm> vila: I do see lucid-cat 2.4
[07:21] <vila> bradm: https://launchpad.net/~canonical-bazaar/+archive/cat-proposed IIUC
[07:22] <bradm> vila: interesting - I don't know the mechanics by which that makes it into our hardy-cat suites, lamont would know more I'd say
[07:23] <vila> right, so let's postpone that part of the discussion for when jelmer and lamont are around
[07:23] <bradm> for sure
[07:23] <bradm> I'm just a lowly GSA seeing a problem on one server ;)
[07:23] <vila> bradm: sure, thanks for chiming in here
[07:24] <bradm> no worries, let me know if you need more info or anything
[07:24] <vila> bradm: do you have a direct access to one of the failing servers to try some diagnosis ?
[07:24] <bradm> vila: sure
[07:24] <bradm> vila: I'll be EODing shortly, but I can do some stuff
[07:25] <vila> bradm: no problem, start reading the comments in bug #788072 and see if you can follow the proposed steps starting in comment #2
[07:27] <bradm> vila: BZR_PDB=1 bzr st looks the same as bzr st
[07:27] <vila> bradm: i.e. python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' with a bzrlib reachable from your pYTHONPATH
[07:27] <bradm> vila: I can't get anything from bzr version or bzr plugins -v other than the error
[07:28] <vila> good, you're in the right context then (hopefully)
[07:28] <vila> bradm: i.e. python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__' with a bzrlib reachable from your pYTHONPATH
[07:28] <vila> bradm: python -V (just to be sure)
[07:29] <bradm> $ python -V
[07:29] <bradm> Python 2.5.2
[07:29] <vila> ok
[07:29] <vila> bradm: and the python import above ?
[07:30] <bradm> $ PYTHONPATH=/var/lib/python-support/python2.5 python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__'
[07:30] <bradm> /var/lib/python-support/python2.5/bzrlib/_chunks_to_lines_pyx.so
[07:30]  * vila blinks
[07:30] <vila> and if you remove the PYTHONPATH ?
[07:30] <bradm> $ PYTHONPATH=/usr/lib/python-support/python-bzrlib/python2.5/ python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__'
[07:30] <bradm> Traceback (most recent call last):
[07:30] <bradm>   File "<string>", line 1, in <module>
[07:30] <bradm> ImportError: No module named _chunks_to_lines_pyx
[07:30] <bradm> $ python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__'
[07:30] <bradm> Traceback (most recent call last):
[07:31] <bradm>   File "<string>", line 1, in <module>
[07:31] <bradm> ImportError: No module named _chunks_to_lines_pyx
[07:31] <vila> that's the issue, the install is broken
[07:31] <vila> well
[07:31] <vila> the install and the context are not what bzr is expected may be more accurate and less offensive ;)
[07:32] <bradm> awesome, I can poke some other servers to see the difference tomorrow
[07:32] <vila> bradm: find / -name _chunks_to_lines_pyx.so -print ? Or something equivalent
[07:32] <vila> bradm: but if you can relate this missing files with failing servers, yeah, that would narrow down the problem space
[07:33] <bradm> $ sudo find / -name _chunks_to_lines_pyx.so -print
[07:33] <bradm> /var/lib/python-support/python2.4/bzrlib/_chunks_to_lines_pyx.so
[07:33] <bradm> /var/lib/python-support/python2.5/bzrlib/_chunks_to_lines_pyx.so
[07:33] <bradm> /usr/lib/python-support/python-bzrlib/python2.5/bzrlib/_chunks_to_lines_pyx.so
[07:33] <bradm> /usr/lib/python-support/python-bzrlib/python2.4/bzrlib/_chunks_to_lines_pyx.so
[07:34] <bradm> interesting, similar on another working server except it doesn't have a /var/lib/python-support/python2.4/bzrlib
[07:34] <vila> if it has python-2.5 we don't care
[07:34] <bradm> right, since we're using python 2.5
[07:34] <vila> but the /var/lib/python-support part... I'm not sure we ever search there, let me check
[07:35] <bradm> oho, interesting
[07:36] <bradm> on a working server:
[07:36] <bradm> $ PYTHONPATH=/usr/lib/python-support/python-bzrlib/python2.5/ python -c 'import bzrlib._chunks_to_lines_pyx ; print bzrlib._chunks_to_lines_pyx.__file__'
[07:36] <bradm> /var/lib/python-support/python2.5/bzrlib/_chunks_to_lines_pyx.so
[07:36] <vila> python -c 'from distutils.sysconfig import get_python_lib ; print get_python_lib()'
[07:36] <bradm> $ python -c 'from distutils.sysconfig import get_python_lib ; print get_python_lib()'
[07:36] <bradm> /usr/lib/python2.5/site-packages
[07:37] <bradm> same on a working system
[07:37] <vila> on a failing server ? ha, rats
[07:38] <bradm> okey, I've got a 4 year old boy wanting some attention, I'll have to take this up again tomorrow
[07:38] <vila> bradm: ok, no worries, that may be something in this area, some missing symlink here or there, hard to guess
[07:39] <vila> bradm: take care of your boy :)
[07:39] <bradm> vila: will do - thanks for the help, its given me somewhere to look :)
[07:41] <poolie> vila, i'm reading the stacks patch now
[07:44] <vila> poolie: \o/
[08:08] <poolie> vila, i answered
[08:08] <poolie> can you tell me: why a registry?
[08:10] <vila> poolie: 1) you asked for it :) 2) it simplifies many issues including centralizing the way to get a stack, overriding by a plugin, etc
[08:12] <vila> it doesn't address (yet) more convenient ways to build stacks (more on that soon, but roughly a stack is already a list of tuples (store, section_matcher(context)) plus one optional mutable store, to reach one read/write by store we need to centralize the way stores are acquired so they can be shared, the stack registry is a first step
[08:12] <vila> poolie: i.e. it's harder to track all stores if everybody build stacks at call sites instead of using a registry
[08:13] <vila> poolie: we've been there (no registry) in other areas and always ended up fixing the issues by introducing a registry,
[08:14] <vila> the only exception I can think of is transports but we already encountered issues that a registry could address (replacing or behind transport.get_transport)
[08:18] <poolie> why is a registry better for that than just having named functions?
[08:19] <vila> poolie: because we all agree it was better when we start using registries ?
[08:20] <vila> started
[08:20] <poolie> uh
[08:20] <poolie> i don't think it's just universally better
[08:20] <poolie> it solves some particular problems
[08:20] <poolie> it's not obvious to me those problems exist in this case
[08:21] <poolie> i don't think people ought to build the stacks inline, but the simplest solution to that seems to be to have functions that build them
[08:24] <poolie> vila?
[08:24] <vila> poolie: searching the relevant mp
[08:27] <poolie> i need to stop soon
[08:27] <poolie> can we just talk?
[08:28] <vila> ok
[08:28] <poolie> here is fine
[08:29] <vila> I can't find it back, but *I* don't care about whether we use a registry or named functions at this point, I seem to recall that you suggested a registry for stacks in some discussion so I took that route
[08:29] <mwhudson> does accessing branches with bzr+ssh://user:pass@host/ type urls work in the way one might hope?
[08:30] <vila> along this route I indeed found that a registry was addressing some issues so I followed up on this route
[08:31] <vila> from a pure syntactic point of view, as explained in the cover letter, this makes sense too,
[08:31] <vila> so this proposal is only about introducing the registry
[08:32] <vila> it doesn't show *how* it helps addressing the other issues to keep it small
[08:32] <poolie> ok
[08:32] <poolie> what are the issues?
[08:33] <jam> mwhudson: yes
[08:33] <vila> single point of access to control which stack is returned for a single context (this became a blocker when jelmer mentioned that subversion.conf was already implementing some additional feature that requires more flexibility when building branch stacks)
[08:34] <vila> this can addressed differently but since this is now needed *and* that a stack registry provides *one* way to address it, I just went ahead
[08:34] <vila> s/can/can be/
[08:34] <mwhudson> jam: thanks
[08:34] <vila> single point of access to control which stores are used so they can be shared,
[08:35] <jam> mwhudson: of course, it leaves your password in bash history, kills babies, etc. :)
[08:35] <mwhudson> jam: yeah yeay
[08:35] <poolie> is this to say that bzr-svn wants to hook into the creation of some stacks?
[08:35] <vila> yes
[08:35] <mwhudson> jam: you can use authorization.conf too right?
[08:35] <jam> mwhudson: You might look at authentication.conf, but I'm pretty sure it doesn't support passwords for ssh
[08:35] <poolie> so one other possible way to do this would be for it to override Branch.get_config?
[08:35] <jam> since we figure "you already have ssh/config to set up a key"
[08:35] <jam> which is more secure anyway
[08:35] <vila> otherwise migrating the branch options to the new config scheme will break the UUID default values for options
[08:36] <mwhudson> jam: is there a chance that a user:pass in a url might end up in a traceback or other console output?
[08:36] <mwhudson> jam: presumably that's fixable though
[08:36] <jam> mwhudson: I *believe* we are good about omitting :pass from anything we log
[08:36] <vila> poolie: yes, but that makes it harder to migrate the options
[08:36] <vila> poolie: and also harder to control which stores are used
[08:37] <jam> mwhudson: http://paste.ubuntu.com/688966/
[08:37] <jam> "does not appear in base" means it doesn't show up in stuff like tracebacks
[08:37] <mwhudson> jam: ah nice
[08:38] <jam> we strip it from the URL, and then hide it around as necessary
[08:38] <vila> poolie: s/harder/different/ if you prefer but the proposal is an incremental progress in *one* direction
[08:39] <poolie> wull
[08:39] <poolie> *well, it's adding some complexity
[08:39] <vila> which one ?
[08:39] <poolie> it's reasonable to ask why it's there
[08:39] <vila> for who ?
[08:40] <poolie> adding a registry rather than just having functions
[08:40] <poolie> so the point of a registry is, in short, so that plugins can control how stacks are created for some particular purposes?
[08:41] <vila> but you objected (rightly) that these functions are not good examples of how to build stacks and indeed they don't address the issues I mentioned above
[08:41] <poolie> which issues?
[08:41] <vila> taking command line overrides into account needs a central place, not requiring eveybody to modify these functions
[08:42] <vila> "which issues?" : overriding by plugins, centralizing store access
[08:43] <poolie> couldn't handling command line options be done by just saying there's a global stack, which most others build upon, that includes per-command options?
[08:44] <vila> I never talked about per-command options,
[08:44] <poolie> i meant per-process
[08:44] <poolie> command line overides
[08:44] <vila> can you elaborate about build upon >
[08:44] <vila> can you elaborate about build upon ?
[08:45] <vila> to me it means having helpers to create the appropriate list of (stores, section_matcher(context))
[08:45] <poolie> basically just that branch_stack() should return stack(BranchStore(branch), LocationStore(), global_stack())
[08:45] <vila> and one central place to ensure the command-line overrides always dominate
[08:46] <poolie> then global_stack can include system-wide, per-user, and command-line parts
[08:46] <vila> wrong
[08:46] <vila> command-line overrides should come first
[08:46] <poolie> ok, i see
[08:46] <poolie> that's true
[08:46] <poolie> how does a registry help with this?
[08:46] <vila> or do you want stacks to be able to be build recursively ?
[08:46] <vila> it provides this central point
[08:46] <vila> place
[08:47] <poolie> but how is it more central than the config module holding some functions?
[08:48] <vila> (I think recursive stacks are neat, but introduce complexity for users as well as devs so I'm more against than for)
[08:48] <vila> some functions all implementing the same rules ?
[08:49] <vila> but, it's not *more* central, it's just *as* central
[08:49] <vila> and again, it's just one way, there are others, this one just seem to be the easiest and fastest...
[08:49] <_arch> Hi
[08:50] <vila> poolie: what is this added complexity you're seeing there ?
[08:50] <vila> even get_config() or get_config_stack() are still possible, they are just implemented by querying the registry,
[08:50] <vila> how is that complex ?
[08:50] <poolie> it's basically just one more level of indirection to go through the registry
[08:51] <poolie> it's not enormously complex, i just don't think you're communicating why it's helpful
[08:51] <poolie> it's not obvious to me how it's going to help with plugins
[08:51] <poolie> i assume the point of having it is to enable things from plugins?
[08:52] <poolie> perhaps one way to move this along would be for you to give some illustrative cases of what plugins want to do with this and how they would do it through the registry?
[08:53] <_arch> I have a problem: During commit, I want to inject my new revision number to each modified file
[08:53] <poolie> hi _arch, you want http://doc.bazaar.canonical.com/plugins/en/keywords-plugin.html
[08:53] <_arch> I checked that out but I'm not sure if it helps. The $Revision-Id$ has a bunch of stuff I don't want apparently.
[08:54] <vila> poolie: how will plugins implement command-line overrides ?
[08:54] <poolie> vila i'd probably just do that in the core
[08:54] <vila> poolie: do you want them to explicitly change their stack builder ?
[08:55] <vila> poolie: but how will they get the feature from the core ?
[08:55] <_arch> So I figured I'll try to write a quick start_commit hook myself which injects the revno to the modified files
[08:55] <vila> poolie: how would you output the help associated with a stack ?
[08:55] <_arch> however I seem to have absolutely no clue of where to begin :)
[08:55] <vila> poolie: how would support the plugin specific configs with 'bzr config' ?
[08:55] <poolie> vila, i'm interested in the answers but i'm also suggesting that if in future you explain some cases like this in the mp, it might be better understood
[08:56] <vila> that doesn't match my understanding of small piece easy to propose :-/
[08:57] <poolie> " but how will they get the feature from the core ?" - i'm not sure what you mean, but if you mean "how will they see values from the command line", i'd expect that all of the *_stack() functions will return a stack that looks at the command line
[08:57] <vila> I'm not addressing rewriting 'bzr config' for now
[08:57] <vila> poolie: indeed, that puts the responsibility on the plugin authors
[08:57] <poolie> i'm not sure if there needs to be help for a stack or whether that needs to be exposed to the user as such
[08:57] <vila> you should do this and this and don't forget this, instead of: register your stack
[08:57] <poolie> i would not expect it needs any plugin changes
[08:58] <vila> ...
[08:58] <poolie> " doesn't match my understanding of small piece easy to propose "-- i think generally, saying "previously, you couldn't do X.  now, it works like so" is pretty helpful to establishing the change is worthwhile
[08:58] <poolie> that can be either in the mp or in a bug
[08:58] <vila> but we have no idea today that plugins implement config files, nor do we have any way to know they do
[09:00] <poolie> _arch, are you saying the problem is that bzr-keywords just puts in too much text? like the revision id and you just want the number?
[09:00] <_arch> yeah
[09:00] <poolie> maybe then the easiest thing is to just add another option to  bzr-keywords?
[09:00] <poolie> you should be able to just go off the existing code
[09:01] <_arch> Hmm, true. I'll check that out, thanks
[09:01] <poolie> if you fix it, please push up a branch so we can merge it
[09:01] <poolie> ask here if you need any help
[09:01] <poolie> vila, that might be true we don't know whether plugins are looking at config files but i don't see why it's actually a problem
[09:01] <_arch> Right I'll check out the source and see if I can make something out of it.
[09:02] <vila> poolie: no, I said *we* don't know that plugins use their own config files and/or if they introduce new features for our own config files
[09:03] <poolie> ok
[09:03] <poolie> is this a bug?
[09:03] <vila> and if jelmer didn't mention that subversion.conf use [UUID] sections I would have break it by migrating the branch options
[09:03] <vila> bug #832036
[09:04] <vila> we're running into circles
[09:04] <poolie> yeah, but that's basically the same problem
[09:04] <poolie> that bug does not describe an actual problem
[09:04] <vila> ok, we don't have problems
[09:05] <vila> better un-migrate the global options and forget about that
[09:05] <poolie> is that sarcasm?
[09:06] <vila> obviously I'm not able to explain the issues in a way we can agree upon
[09:06] <poolie> :/
[09:06] <poolie> sorry
[09:07] <vila> no, it's just that I suck at this particular point and therefore cannot progress, so it's wasted time
[09:07] <poolie> ok
[09:07] <poolie> let's shelve this until it's clear it's solving a pressing problem for plugins
[09:07] <poolie> does it block anything else?
[09:08] <vila> https://bugs.launchpad.net/bzr/+bugs?field.tag=config i.e. 40 bugs, plus all the ones I failed to file
[09:09] <poolie> i think 832036 is a good example of a bad bug, because it specifies a solution, not a problem
[09:09] <poolie> are you saying this blocks all those bugs?
[09:09] <poolie> i have some trouble believing it
[09:10] <vila> oh, there are surely alternate ways to address them, someone just have to analyze them and find a relevant fix
[09:11] <poolie> ok so of those bugs
[09:11] <poolie> the one i care most about is 832042
[09:12] <vila> is that sarcasm ?
[09:12] <poolie> nup, it's true
[09:12] <poolie> well, more precisely
[09:12] <poolie> if these changes have a performance impact, i care about fixing it
[09:13] <vila> yes they do have one and I've added -Econfig_stats to track progress
[09:13] <poolie> istm an easy way to fix 832042 would be to just create the config stacks early on in the object they correspond to
[09:14] <poolie>  the global-ish ones which have no obvious owner can go onto the library_state
[09:14] <vila> you need a central place to share the stores (not mentioning how it interacts with library_state)
[09:17] <poolie> hm
[09:18] <poolie> i think you can either have them on library_state, or inherited from one object to another
[09:18] <poolie> it seems pretty possible
[09:19] <poolie> i'v closed 832036  and i pushed down some of the others
[09:21] <vila> then we should also revert all stack related stuff or it will make it harder to address these bugs
[09:22] <poolie> i don't see how that really follows
[09:22] <poolie> i think the stacks are just fine
[09:23] <vila> you don't want to address sharing both stores and config files don't you ? Nor maintain both get() and get_user_option() and get_xxx APIs right ?
[09:25] <poolie> i don't really understand the question
[09:25] <poolie> i do need to stop
[09:26] <poolie> i'm sorry this is frustrating
[09:26] <vila> I mean, I don't mind getting rid of this stuff if we can't agree upon, but in this case that's a non-sense to keep it because it means we have a fragmented API and this is definitely something that makes it harder to fix the remaining bugs
[09:26] <poolie> if you can think more about actual "X doesn't work as it should" bugs rather than what you want to write, i think that will help communicate it
[09:27] <vila> that's what the devnotes doc was about :-/
[09:28] <vila> ha, I have some bugs mentioned with the corresponding issues in my uncommitted version
[09:28] <poolie> hm, so
[09:29] <poolie> i can see there's something in there about plugins wanting to add new files
[09:30] <poolie> i think for a particular mp just pointing to configuration.txt is not enough, because the specific connection is not clear
[09:30] <vila> see also the part about not being able to delete some options ?
[09:30] <vila> or the already existing fragmentation in the API ?
[09:31] <poolie> i really do not see how the registry would help with deprecating options
[09:31] <vila> the stack registry ? unrelated,
[09:31] <poolie> i think if you filed a bug saying "there is no way to gracefully deprecate an option" we can agree on whether that's true, whether it's important, and then on whether a particular mp is a decent way to solve it
[09:31] <vila> but the option registry can be used to say one option deprecates another one (or vice versa)
[09:32] <poolie> right
[09:32] <poolie> so
[09:32] <vila> far from the top of my TODO list
[09:32] <_arch> poolie: have you used the keywords plugin? Am I supposed to add the keyword template (like, $Revision-Id$) to each of my files?
[09:32] <poolie> _arch, i haven't used it recently, but yes, add it where you want the text to come out
[09:32] <poolie> vila, ok, so, i'm -1 on the registry until the reason is clear
[09:33] <poolie> i think it would overall be most excited about you doing bug 795321 or maybe bug 832042
[09:33] <poolie> or bug 836782, which is just pushing #is perhaps
[09:33] <poolie> or rebuilding it?
[09:33] <_arch> poolie: and once the file is pushed the keyword is going to be replaced by whatever it's supposed to be? i.e, in place of $Revision-Id$, there's going to be the revid?
[09:34] <poolie> i think it will be expanded within the keyword
[09:35] <poolie> ok, good night all
[09:35] <_arch> Right, there's something wrong then :)
[09:35] <_arch> thanks
[09:43] <Riddell> jelmer: how long does it take for a package to move from debian incoming to unstable?
[09:45] <jelmer> Riddell: it happens several times a day (if it doesn't have to go through NEW)
[09:45] <Riddell> hmm those bzr packages are still there (according to the incoming.d.o and packages.d.o websites)
[09:46] <jelmer> Riddell: http://packages.debian.org/sid/bzr-explorer already has 1.2.1-1
[09:47] <Riddell> you're right, http://packages.debian.org/search?keywords=bzr-explorer is slacking
[09:47] <Riddell> or maybe it's my browser cache
[09:47] <Riddell> weird
[09:50] <Riddell> jelmer: I'll sync bzr-explorer and qbzr, and make the necessary changes to bzr to upload that
[09:51] <jelmer> Riddell: I was about to do an upload of bzr to oneiric too
[09:52] <Riddell> go ahead then
[09:53] <Riddell> jelmer:
[09:54] <jelmer> Riddell: thanks
[09:57] <Riddell> is there a reason why printing text in builting.py is often done with self.outf.write() rather than note() ?
[10:33] <vila> Riddell: the FIXME in trace.note are probably part of the answer
[10:50]  * Riddell discovers bzr rocks
[10:51] <Riddell> that'll keep our translators amused finding suitable localised equivalents :)
[11:08] <jam> Riddell: self.outf.write goes to stdout and is in terminal encoding. note() I think goes to stderr and is officially UTF-8 encoded. Further note() also goes to .bzr.log
[11:18] <Riddell> hmm, so use of note() in commands might break if you're not using a utf-8 language?
[11:18] <Riddell> what is the "cannot import name info" message I get all the time?
[11:19] <Riddell> oh it's a plugin at fault
[11:22] <jelmer> Riddell: ~/.bzr.log is your friend :)
[11:43] <jam> Riddell: .bzr.log and -Derror
[13:34] <jam> mgz: ping
[13:34] <mgz> pong-to-avoid-what-I-should-be-doing
[13:36] <jam> mgz: I just upgraded bzr and did "bzr st" outside of a working tree
[13:36] <jam> and got the giant-explosion of IndexError.
[13:36] <mgz> traceback in the message you just put on the lp:~gz/bzr/root_drive_file_url_841322 mp implies the branch didn't land correctly
[13:36] <mgz> File "C:\dev\bzr\bzr.dev\bzrlib\urlutils.py", line 391, in
[13:36] <mgz>  _win32_extract_drive_letter
[13:36] <mgz>     if len(path) < 3 or path[2] not in ':|' or path[3] != '/':
[13:36] <mgz> IndexError: string index out of range
[13:36] <mgz> that's still `< 3` not `< 4`
[13:37] <mgz> double check the branch is at the right revision?
[13:38] <jam> mgz: I'm at 6125.. Looks like update *didn't*
[13:38] <jam> bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_on
[13:38] <jam> ly setting on branch "C:/dev/bzr/bzr.dev/".
[13:38] <jam> how did we manage that?
[13:39] <jam> mgz: so it looks like my branch is out-of-date.
[13:39] <jam> Sorry for the noise. I'll poke at the other stuff
[13:40] <mgz> ugh, not sure, don't think I have that setting on so pull works here
[13:41] <jam> mgz: looks like discrepancy between PQMs
[13:42] <jam> specifically, 'bzr.dev's rev 6124 is now by "Patch Queue Manager" instead of "Canonical.com Patch Queue Manager"
[13:42] <jam> so it seems we landed (and I pulled) 2 revisions on the old PQM, which are now gone from history in the new PQM
[13:42] <jam> vila, poolie, jelmer: ^^ Did you see this?
[13:43] <jam> http://paste.ubuntu.com/689201/
[13:43] <jam> I'm a little concerned that we lost revisions, but I guess if a plain "bzr pull" works, then we shouldn't have.
[13:44] <vila> jam: yes, mentioned a couple of days ago, occurred during the migration to the new pqm, was considered minor enough to deal with it
[13:44] <vila> jam: you have append_revisions_only set locally ?
[13:44] <vila> jam: pqm doesn't
[13:44] <jam> vila: Yes, I have it set here
[13:45] <vila> jam: again see log for discussions about why we considered not doing that
[13:45] <jam> that way I don't screw stuff up locally
[13:45] <jam> vila: irc log?
[13:45] <vila> yup
[13:45] <vila> around pqm migration, I raised the issue as soon as I discover it on bzr.dev
[13:46] <jam> vila: so we did already merge them into the actual trunk. I was trying to look at the changes, and didn't specifically see it.
[13:47] <vila> jam: yes, the first succesful submission based on the trunk pushed by the old pqm carried all the diffs
[13:48] <jam> vila: I'm fine with the solution, I just wanted to make sure we didn't lose anything. so good enough.
[13:48] <vila> jam: nothing has been lost bar the cleaner history
[13:49] <jam> vila: yeah. no problem. I often start my day by running "bzr up" but not actually reading the output. So I didn't see that it wasn't updating.
[13:49] <vila> jam: yeah, same reaction here, I even blew the whistle before checking, but I did not check very deeply given that this didn't seem necessary (I was lucky enough to do a 'bzr missing' at the right time)
[13:49] <jam> I did 'bzr missing' but wasn't 100% sure it wasn't lying :)
[13:56] <jam> mgz: so in the end, Yay for you! I don't get the traceback anymore. :)
[13:56] <mgz> good good :)
[14:07] <blackarchon> hi all!
[14:09] <blackarchon> I just posted bug 850004, is it maybe already solved in trunk?
[14:12] <mgz> that sounds like a bug for me.
[14:13] <blackarchon> 2.4.0 was entirely broken, and 2.4.1 seems also broken :(
[14:14] <mgz> there's nothing obviously wrong from your log or traceback
[14:16] <mgz> does S:/v5_x/projects/10074_YYY-Lüftersteuerung/.bzr/repository/pack-names actually exist?
[14:17] <mgz> and if not, which is the first parent directory that does?
[14:17] <blackarchon> yes, it exists
[14:18] <blackarchon> well the letter ü is (according to the log) sometimes coded in a wrong way, this may propably be the reason for this error
[14:19] <mgz> it's right in all the bits in that bug, and the error isn't related to non-ascii characters, so I think that may be a red herring
[14:20] <mgz> blackarchon: paste me the output of `dir S:/v5_x/projects/10074_YYY-Lüftersteuerung/.bzr/repository/pack-names` run in the cmd prompt please?
[14:20] <mgz> !paste
[14:23] <blackarchon> mgz: http://paste.ubuntu.com/689235/
[14:24] <mgz> okay, fun. I'll try and repo here.
[14:24] <blackarchon> note I have to use \ instead of /
[14:25] <mgz> one last thing for you to try, run the command bzr-explorer is passing, but at the command line
[14:26] <blackarchon> I should run "bzr explorer S:/v5_x/projects/10074_YYY-Lüftersteuerung" on the command line?
[14:26] <Noldorin> hi jelmer
[14:27] <jelmer> hi Noldorin
[14:27] <Noldorin> any progress on the issue? :-)
[14:27] <mgz> blackarchon: so, `bzr commit -m "Vor 2. Wegschicken zu Hr. xxx" YYY-Lüftersteuerung.sch`
[14:27] <jelmer> Noldorin: sorry, been distracted with other things so far
[14:27] <Noldorin> jelmer, no prob
[14:27] <jelmer> it's high on my todo list though
[14:27] <Noldorin> jelmer, just thought i'd let you know i'm here to assist you when ready :-)
[14:27] <Noldorin> sure
[14:29] <blackarchon> mgz: If i run "bzr explorer S:/v5_x/projects/10074_YYY-Lüftersteuerung"
[14:29] <blackarchon> I get an error
[14:30] <blackarchon> unable to change to <path> - closing page
[14:30] <mgz> paste me that, then try the command I suggested?
[14:31] <blackarchon> mgz: sorry, my fault - the command was fine
[14:31] <blackarchon> just had a typo
[14:32] <mgz> I hope you're not having to retype Lüftersteuerung each time :)
[14:34] <blackarchon> mgz: http://paste.ubuntu.com/689241/
[14:36] <mgz> interesting. do `bzr add YYY-Lüftersteuerung.sch` too?
[14:36] <blackarchon> why should adding a file help if it is already added?
[14:37] <mgz> it's not clear what the state of the branch is, it might be there really isn't anything to do.
[14:38] <mgz> if you were committing in bzr-explorer, and it gave you an error, I was presuming you had outstanding changes that still needed to be comitted.
[14:39] <blackarchon> ok - well, the problem is that committing seems to work. at the moment, I have 6 revisions in this standalone tree. But I also get these errors while committing.
[14:39] <mgz> that's wrong I guess, either you already did that or reverted them, or bzr left things in a funny state.
[14:40] <mgz> okay.
[14:40] <blackarchon> so it seems to do something right, but not all.
[14:40] <mgz> can you make a new change of some kind to that file, try the commit from the command line (you can always uncommit after trying) and see if you get the same error?
[14:40] <blackarchon> ok
[14:42] <mgz> it looks like this may just be an problem in the explorer commit reporting code.
[14:43] <blackarchon> this went fine without an error on the command line
[14:44] <mgz> great, thanks for testing all of that, will help me try and reproduce it locally.
[14:45] <blackarchon> but there seems to remain a little discrepancy in umlaut handling: http://paste.ubuntu.com/689250/
[14:45] <blackarchon> is this really not a problem?
[14:45] <mgz> yes, that does look funny but is actually correct.
[14:45] <blackarchon> ok :)
[14:46] <blackarchon> and thanks for your time! :)
[14:46] <mgz> some parts of the code use a unicode string where ü is u'\xfc' and some use a utf-8 byte string where it's '\xc3\xbc'
[14:47] <blackarchon> well this seems like a problematic approach
[14:48] <mgz> it is, but I think your bug is a different problem.
[14:50] <blackarchon> ok
[14:52] <davi_> jelmer, hi, can you fix bzr-git trunk to work with dulwich 0.8.0? current trunk attempts to import HttpGitClient which i think is not implemented in dulwich 0.8
[15:00] <Riddell> vila: is https://code.launchpad.net/~jr/bzr/i18n-unoverride-no-i18n-tests/+merge/75181 ok now?
[15:02] <vila> Riddell: didn't I approve it already ?
[15:03] <vila> oh no,
[15:06] <vila> Riddell: gha the diff makes no sense (not enough context), let me review that locally
[15:23] <vila> Riddell: ok ,so, this is better. One thing that comes to mind reading the patch though is that there are two idioms to test i18n: either you allow installing one or you install one without asking
[15:24] <systemclient> how can I export a repo with multiple branches to git?
[15:24] <vila> Riddell: and I don't really understand what the two TestInstall tests do. Are they just smoke tests ?
[15:25] <vila> Riddell: shouldn't test_custom_languages fails if there is no translations avaiable for nl:fy ?
[15:26] <Riddell> vila: I don't know, I didn't write those tests
[15:27] <Riddell> vila: yes the two ways to test i18n are documented with this merge proposal
[15:28] <vila> Riddell: oh, so sorry, they are indeed documented
[15:30] <vila> Riddell: alright, so, TestTranslate alreday calls self.overrideAttr(i18n, '_translations', ZzzTranslations()), the tests don't need to do it again. I know, you didn't write them either, but better fix them if they need to serve as examples
[15:32] <Riddell> vila: how about adding this to the end? self.assertTrue(isinstance(i18n._translations, i18n._gettext.GNUTranslations) ?
[15:32] <vila> Riddell: for the TestInstall ones ?
[15:32] <Riddell> yes
[15:32] <vila> sounds good !
[15:33] <mgz> Riddell: can use assertIsInstance there.
[15:34] <vila> Riddell: does that mean that i18n.install('nl:fy') succeeds even if the translations are not available ?
[15:34] <vila> Riddell: if that's true, yeah, that will make the test intent clearer (and mgz remark applies too ;)
[15:38] <Riddell> I'm not sure, investigating
[15:42] <Riddell> vila: it'll produce a NullTranslation always, only if the language is there will is make a GNUTranslation
[15:43] <Riddell> so I've pushed a change to test for NullTranslation
[15:43] <vila> Riddell: ha ha, won't that break if that translation *is* available ? Or should you have a test for a known always available translation and one for a known never available one ?
[15:44] <Riddell> no because GNUTranslations inherits from NullTranslations
[15:44] <vila> ok, but mgz mentioned assertIsInstance (provided by testtools maybe ?)
[15:45] <vila> Riddell: and TestTranslate alreday calls self.overrideAttr(i18n, '_translations', ZzzTranslations()), the tests don't need to do it again. I know, you didn't write them either, but better fix them if they need to serve as examples
[15:45] <vila> bah copying my tyops now :-/
[15:46] <vila> Riddell: assertIsInstance is provided by TestCase (not testtools)
[15:46] <vila> Riddell: and will give a better error message than assertTrue(isinstance(...))
[15:49] <Riddell> vila: pushed
[16:02] <Noldorin> jelmer, had LP support for collocated branches arrived yet?
[16:02] <Noldorin> i knwo 2.5b1 is being released tomorrow
[16:03] <Noldorin> which has support
[16:22] <Noldorin> jelmer, let me know if you want me to send you my powershell script...
[16:22] <Noldorin> for testing the issue
[17:14] <lamalex> hey bzr folks- need some help
[17:14] <lamalex> (i'm tying my question- don't hassle me about asking to ask)
[17:15] <lamalex> i've got a branch which i want to merge into my trunk, but i want to squash the history of the old branch, as to basically not have it
[17:15] <fullermd> Aw, man, you take all the fun out of it...
[17:15] <lamalex> :)
[17:15] <lamalex> there is some private info in the history i don't want exposed to the world
[17:15] <Noldorin> lamalex, a normal merge does that
[17:16] <Noldorin> just make sure it doesn't pull
[17:16] <fullermd> You could merge, revert --forget-merges to dump the intermediate revs, then commit.
[17:16] <lamalex> Noldorin, but can't i go and do a bzr log -n0 and see the history of the branch?
[17:16] <lamalex> fullermd, ah ha, that sounds like a sane way
[17:16] <lamalex> i was trying to do a bzr diff  > and then patch it
[17:16] <fullermd> Oh no.  What will taht do to my reputation?
[17:16] <lamalex> but there are all kinds of renamed files and whatnot
[17:16] <lamalex> it was messy
[17:17] <Noldorin> lamalex, oh, i forgot about that
[17:17] <Noldorin> lamalex, fullermd has a decent solution :-)
[17:17] <lamalex> indeed
[17:18] <lamalex> oh my god that worked perfectly
[17:18] <lamalex> fullermd, you're a genius
[17:19] <Noldorin> bzr send --no-bundle may also work
[17:19] <Noldorin> i'm not sure though
[17:19] <lamalex> fullermd, do you work for canonical btw?
[17:19]  * fullermd buffs his nails on his shirt and looks haughtily down on everyone.
[17:19] <fullermd> Oh, no.  They'd make me run Linux and code in Python.  Who wants that?
[17:21] <lamalex> ha
[17:21] <lamalex> zing
[17:21] <lamalex> isn't it odd, some people /like/ coding in python
[17:21]  * lamalex shudders
[17:22] <Noldorin> many, in fact :-P
[17:22] <fullermd> Stockholm syndrome is a terrible thing   :(
[17:22] <Noldorin> some people like coding in obj-c
[17:22] <Noldorin> which is even worse
[17:22] <fullermd> It could be worse though.    It's incredible to watch.
[17:28] <vila> fullermd: you imply he's still alive ?
[17:28] <fullermd> Well, I dunno if you'd classify COBOL programmers as "alive" in any meaningful sense...
[17:29] <vila> well, zombies walk but they don't TALK
[17:29]  * fullermd _wishes_ he didn't talk...
[17:29] <vila> on the other hand, I heard you could do subroutines and even pass parameters in COBOL these days...
[17:30] <fullermd> He's actually so far off in his own world, it's impossible to argue with him about anything.
[17:30] <vila> and did they fix the compiler saying: 'You miss a period here, it's a fatal error, but I will assume there is one so I can show your all your other errors' ?
[17:31] <fullermd> He can actually say, with a straight face, that COBOL is totally relevant because it's kept up with the times, since it has all the modern bells and whistles like (I'm not making this up) while and for loops.
[17:32] <vila> that also reminds me of this guy writing perl scripts to generate visual basic that inject data in excel documents...
[17:32] <vila> fortunately I only *heard* about him
[17:32] <fullermd> I use a perl script to generate my window manager config on the fly...
[17:33] <vila> fullermd: pff, you miss the vb part, too easy, doesn't count
[17:33] <fullermd> At one time I had perl in my shell rc file too.  Only has sed and awk now, though.
[17:34] <fullermd> (at this point of course we x-ref the classic Know Your Sysadmin   :p)
[17:38] <vila> :)
[19:15] <Noldorin> hi jelmer
[20:27] <poolie> hi
[20:27] <GRiD> hi poolie
[20:28] <GRiD> are you up early? :)
[20:29] <poolie> i am
[20:30] <poolie> how are you?
[20:31] <GRiD> good thanks. saw you had the flu, over i hope?
[20:31] <poolie> yes, fine now
[20:33] <GRiD> cool. we're just about to get into that season here, not looking forward to that...
[21:04] <abentley> poolie: Didja know Martin Poole is a character on a Canadian TV show? http://www.imdb.com/character/ch0184436/
[21:06] <poolie> i did not
[21:06] <abentley> poolie: it was rather bizarre watching for me.
[21:19] <poolie> statik, hi?
[21:19] <statik> hi poolie
[21:40] <Noldorin> jelmer, hey
[22:00] <jelmer> Noldorin: hi
[22:00] <Noldorin> how's it going..?
[22:11] <jelmer> Noldorin: it's alright
[22:11] <jelmer> how are you?
[22:11] <Noldorin> good good
[22:11] <jelmer> g'morning poolie, statik
[22:11] <Noldorin> haven't had chance to do much more investigating
[22:11] <Noldorin> jelmer, how about you?
[22:11] <jelmer> Noldorin: been busy with other things all day too
[22:11] <jelmer> I'm going to have a look now, but might fall asleep before I have a chance to...
[22:12] <poolie> hi jelmer
[22:12] <poolie> well, it's a great day to bisect intermittent kernel bugs
[22:12] <poolie> but i think i will anyhow
[22:13] <jelmer> poolie: check out revision, recompile kernel, reboot, repeat?
[22:13] <poolie> yeah
[22:13] <poolie> i'm going to start just with the various sub-versions of packaged kernels
[22:16] <poolie> for bug 833479 fwiw
[22:18] <poolie> jelmer, can i just confirm you started the process for 2.4.1 into oneiric?
[22:19] <jelmer> poolie: yep - the package built fine, it's just waiting to be uploaded now
[22:19] <poolie> great
[22:19] <poolie> that was really pretty smooth
[22:19] <Noldorin> jelmer, ok sounds good :-)
[22:19] <Noldorin> jelmer, looking forward to the 2.5b1 release tomorrow too
[22:26] <Noldorin> jelmer, something tells me the fix is going to be very small....just difficult to figure out
[22:26] <jelmer> Noldorin: I think the fix will be trivial once we have a test that reproduces the issue
[22:29] <Noldorin> jelmer, you were away earlier today, but i offered to send you my powershell script...
[22:29] <Noldorin> if you like
[22:29] <Noldorin> but you know how to reproduce it anyway i think
[22:29] <jelmer> Noldorin: thanks, but I don't have powershell here (Linux)
[22:30] <jelmer> unless your script reproduces the issue in less revisions that the original branch?
[22:31] <Noldorin> jelmer, afriad not. everything happens at r47...
[22:31] <jelmer> it should still happen with the contents of r46 and the problematic changes
[22:33] <Noldorin> that's what i mean yeah
[22:33] <Noldorin> my script shows that
[22:33] <Noldorin> we discussed it yesterday :-)
[22:35] <jelmer> Noldorin: I mean, if you commit the entire set of contents of r46 in a new branch as r1 and then make the same problematic changes that triggered the bug in your r47
[22:37] <jelmer> anyway, time for some sleep. g'night
[22:42] <poolie> night
[23:53] <poolie> GRiD, hi?
[23:53] <GRiD> hi


[22:42] <rsully> Does anyone have any recommendations for vendors to configure servers from? If this isn't allowed here please feel free to PM me regarding this.
[23:58] <xibalba> I'm trying to NAT from my LAN into my tun0 interface. I've used the iptables cmd, sbin/iptables -A FORWARD -i ens160 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT, however when i do a tcpdump I dont see any data going into my tun0 interface. I have the tun0 interface up, and ping across the internet to the other peer point. Any suggestions?
[23:59] <xibalba> it's a tun interface spawned from ssh


[01:03] <xnox> xz?
[01:06] <infinity> xnox: *blink*
[01:06] <infinity> xnox: Oh, my webkit question?  No, it really is relinking.
[01:06] <infinity> xnox: Adds about 11h on ARM.  Totally unfun.
[01:06] <xnox> although it has separate -dbg packages.
[01:06] <xnox> infinity: 0_0
[01:07]  * xnox noticed a checky -Zxz in cdbs/gnome.mk
[01:07] <infinity> It's the whole libtool relink-on-install business.
[01:07] <xnox> s/checky/$(whatever proper way to spell it)/
[01:07] <infinity> Cheeky?
[01:07] <xnox> yes.
[01:11] <micahg> webkit doesn't use cdbs
[01:12] <xnox> micahg: sure. it was a slightly vaguely on-xz-topic references. considering that a few things in desktop seed do use cdbs/gnome.mk.
[01:14] <infinity> xnox: I don't mind if things are sneakily switching.  udebs have been xz for ages.
[01:14] <micahg> switching to xz debs is a good thing for things that are frequently updated
[01:15] <infinity> Over time, I think it's the right answer for almost everything, the only thing I've been pushing back on is us doing it on our own without coordination with Debian.
[01:17] <micahg> so, Debian's main goal right now was to try to get everything that's supposed to be on CD #1 back on CD #1, so that probably explains the GNOME usage
[01:17]  * micahg is telling people what they already know again...
[01:18] <xnox> infinity: micahg: should we switch langpacks from bz2 to xz?
[01:18] <xnox> frequent && !debian-upstream
[01:18] <xnox> =))))
[01:19] <infinity> xnox: Probably, yes.  Anything we're forcing to bz2 right now should probably switch.
[01:19] <infinity> xnox: Need to be careful, though, since that's all autogenerated, and we don't want to accidentally switch, say, lucid langpacks.
[01:19] <xnox> that would be all emacsen & texlive.
[01:20] <xnox> infinity: is lucid still getting langpack updates?!
[01:20] <infinity> Oh, probably not, since we're not doing point releases anymore.
[01:21] <xnox> yeah, that's what i thought - surely it must be past it's point releases.
[01:21] <infinity> But there's always the chance someone may decide that we should.
[01:21] <infinity> *shrug*
[01:21] <micahg> wait till april?
[01:21] <infinity> Anyhow, I wouldn't be against changing langpacks.  It's not really as meaningful as it was when we were trying to stuff them on alternate CDs, mind you.
[01:21] <infinity> Which was why they were bz2.
[01:22] <xnox> infinity: but these days we download them on-demand & the smaller they are the faster we download them.... not sure about the unpack time penalty vs bz2
[01:22] <infinity> It was never about mirror space or download time, just trying to stuff a ton of packages on a CD.
[01:23] <xnox> on-demand = during the install that is.
[01:23] <infinity> Download time versus unpack is hard to benchmark, since we first have to decide what an "average user" has for both bandwidth and CPU/RAM.
[01:24] <micahg> unpack should be faster than bz2
[01:24] <infinity> My gut feeling, though, is that almost any unpack time impact will negate bandwidth concerns almost immediately for all but people on dialup.
[01:24] <micahg> it's compression that might be a tad slower
[01:24] <infinity> micahg: Oh, for bz2, yes.  Which is why I said we should just switch bz2 stuff to xz.
[01:24] <infinity> This sort of turned into a generic xz discussion for me halfway through. :P
[01:25]  * xnox the 21st centure term for dial-up  is 3G or metered/expensive 4G
[01:25] <infinity> In general xz will almost always be a win over bz2.
[01:25] <infinity> But it can often be a loss over gzip.
[01:25] <StevenK> infinity: In terms of CPU time, file size or both?
[01:25] <infinity> StevenK: Both, usually.  bzip2 is pretty awful.
[01:26] <infinity> Which reminds me, I should drag our buildd chroots kicking and screaming into the current century and stop using bz2.
[01:27] <StevenK> Haha
[01:27] <StevenK> Does lp-buildd depend on them being bz2?
[01:27] <infinity> StevenK: Yeah, but that's easily solved.
[01:27] <StevenK> What about dak?
[01:27] <infinity> StevenK: What I need to double-check is that there are no server-side assumptions there.
[01:27] <infinity> StevenK: ...dak?
[01:28] <StevenK> infinity: Yeah, I've been trying to think about the chroot handling in LP, and I'm not sure.
[01:28] <infinity> StevenK: Preeeeetty sure we have no dak instances with a buildd/sbuild setup backed by the librarian's chroot tarballs. :P
[01:28] <StevenK> Heh
[01:28] <xnox> there is always first time for everything =)
[01:28] <infinity> Anyhow, if there are any soyuz assumptions, they'd just be filename assumptions.
[01:29] <infinity> Which isn't actually a big deal.
[01:29] <infinity> Cause I can check file(1) magic when I grab the librarian blob and work with that.  Filenames are meaningless.
[01:30] <infinity> (And given that they're stored as filcache/$HASH on the buildd anyway, filenames are already meaningless)
[01:30] <xnox> infinity: also tar knows how to auto-guess all supported compression formats by default....
[01:30] <StevenK> infinity: Oh, so it just assumes filecache/$HASH is bzip2? Orsum ...
[01:31] <infinity> StevenK: It's a bit weirder than that.  Since the $HASH is the hash of the tar.bz2, but after the first unpack, the contents are actually just the .tar
[01:31] <infinity> (To avoid unzipping over and over)
[01:31] <StevenK> Hah
[01:31] <infinity> Not sure what Daniel was smoking that day.
[01:32] <StevenK> Right, I was wondering if we were paying the bzip2 penalty over and over.
[01:32] <infinity> Nah, the bz2 hit is only on first unpack of a new chroot, so it's not a big deal.
[01:32] <infinity> Which is why I never cared deeply about changing format.
[01:33] <StevenK> infinity: And yet you seem to care a little now? :-)
[01:33] <infinity> I'll stop caring soon.
[01:33] <infinity> But I'm touching lp-buildd for some other fixes over the holidays, some compression magic could accidentally slip in.
[07:38] <pitti> Good morning
[07:44] <mlankhorst> could one of the sru admins accept xorg so that I can retire the backports ppa? :-)
[08:00] <dholbach> good morning
[09:54] <blami_> what's a ubuntu developer usual workflow? When I decide to patch something should I do my changes to upstream first and then have them propagated to package or fix package first and then contribute to upstream?
[09:56] <persia> For ease of testing, I generally fix the package first, make sure it runs in the current development environment, and then see how the patch could go upstream.
[09:57] <dholbach> blami_, getting fixes as upstream as possible is usually the best idea, but depending on how urgent the fix is, it might make sense to get it into Ubuntu first
[09:57] <persia> That said, it is usually a good idea to check upstream to see if the issue is already solved beforehand (and perhaps cherrypick, if the new upstream version isn't looking likely to land in the current release), which may mean that the first solution is against upstream.
[09:58] <persia> dholbach: In terms of committing the patch, I couldn't agree more, but in terms of initial testing, do you usually pull the upstream source (repackaging if necessary), and patch it for issues?
[09:58] <dholbach> persia, no - I was merely commenting on where to contribute the fix to
[09:59] <persia> Oh, indeed.  Once the patch works, sending upstream is best, and sometimes it's not even worth an Ubuntu upload.
[10:11] <blami_> persia: so you usually do something like bzr branch something or apt-get source something, apply your changes, build the package, test it and then, if it works you decide how to integrate your changes?
[10:15] <persia> blami_: Precisely.  Generally it's apt-get source, edit-patch ${SOMETHING}, debuild -S -us -uc, sbuild -d -A ${PACKAGE}, dpkg -i ${PACKAGE}, test
[10:15]  * xnox with edit-patch hopefully dieing with fire =)
[10:15] <persia> If I'm testing something that only works in a low-performance environment, a headless environment, or an environment with limited flash-only storage, there might be some scps involved.
[10:16] <persia> xnox: Why?
[10:16] <xnox> "just edit in place & dpkg-source --commit" instead
[10:16] <xnox> persia: note "ing" as in process of, not 'dead' as in no longer used =)
[10:17] <persia> Ah, yeah, perhaps we'll reach that point someday.  Since we still have some packages not updated since warty (because they have no known issues that updates would solve), I suspect it will be a long time.
[10:17] <persia> Mind you, someone could teach dpkg-source --commit about the various format:1.0 patch systems :)
[10:23] <blami_> persia: thing is I was asked to evaluate possibility of adding location profiles to NetworkManager. As it seems I will need to integrate a larger body of code for prototype (not one or two line fix), I would appreciate some sort of version control in process of patching.
[10:24] <jtaylor> blami: you can write your patch in a clone of upstreams vcs
[10:24] <persia> If you're doing something complex like that, it's probably better to do the work upstream, wearing a "NetworkManager developer" hat, rather than an "Ubuntu Developer" hat.
[10:24] <jtaylor> most vcs have methods to dump your changes into a single patch for the package
[10:25] <persia> Big changes done downstream tend to be hard to push upstream, as they tend to lag trunk.
[10:25] <xnox> blami_: bzr branch is good for that as well =)
[10:39] <pitti> sbeattie: it seems the last hardy glibc update broke postgresql; I put some analysis to bug 1088393
[11:05] <pitti> doko, jelmer: FYI, sent the samba4 patch to https://bugzilla.samba.org/show_bug.cgi?id=9503
[11:20] <seb128> pitti, oh, thanks for that bug reference, I got bitten by that recently in another upload as well
[11:20] <seb128> I wonder how many source will have the issue
[11:26] <xnox> seb128: interesting. what package was that?
[11:26] <seb128> xnox, py3cairo
[11:27] <seb128> xnox, http://launchpadlibrarian.net/125114732/py3cairo_1.10.0%2Bdfsg-3~exp3_1.10.0%2Bdfsg-3~exp3ubuntu1.diff.gz is the quick diff I didn't when the sync failed to build
[11:28] <seb128> xnox, I was a bit puzzled by why it was working before, but after reading pitti's comment that it's doko who changed the python script by a shell one things start making sense ;-)
[11:28] <xnox> *sigh*
[11:32] <xnox> seb128: upstream git history doesn't have pre-git history in it. but at least since Sep 2011 waf simply calls the python-config (without prepending interpreter)
[11:32] <xnox> weird.
[11:36] <pitti> seb128: oh, so that does affect more packages then?
[11:36] <seb128> pitti, yes
[11:36] <seb128> pitti, cf the url I just posted
[11:36] <pitti> *nod*
[11:41] <ev> xnox: you were saying last night that the hadoop charm relates to gunicorn multiple times. I can't seem to find this though - could you point me in the right direction?
[11:42] <xnox> ev: ....ehm not to gunicorn. within itself only.
[11:42] <ev> oh
[11:42] <xnox> ev: it has e.g. worker-role, data-node-role or worker-and-data-node-role.
[11:43] <xnox> ev: sorry, i probably missunderstood what you need.
[11:43] <xnox> ev: and depending on what is the name of relationship it configures one or other or both "roles.
[11:44] <xnox> ev: and depending on what is the name of relationship it configures one or other or both "roles".
[11:46] <ev> ahh
[11:46] <ev> that is indeed slightly different
[12:07] <xnox> ev: you could write your own subordinate charm/relationship to gunicorn. connect to gunicorn via normal relationship & via subordinate relationship.
[12:08] <xnox> ev: since you can deploy subordinate onto your whoopsie charm.
[12:08] <ev> xnox: Gnuicorn is already a subordinate
[12:08] <ev> gunicorn*
[12:08] <xnox> I see....
[12:08] <xnox> =((((
[12:20] <doko> seb128, does pycairo have it's own copy of waflib?
[12:25] <xnox> doko: thanks to debian ftp-masters all waf packages must be unpacked & ship their own copy of waflib. but it seems like there has been broken piece of code cargo-culted outside of waf upstream.
[12:34] <StevenK> cjwatson_: In terms of that bug, I reported what I saw in terms of the traceback. Sadly, I didn't save a copy.
[12:43] <seb128> doko, yes
[12:52] <mdeslaur> pitti: thanks for figuring out the glibc issue, we'll look into it
[12:53] <pitti> mdeslaur: cheers
[14:28] <stgraber> @pilot in
[14:28] <stgraber> (missed my shift last Monday)
[14:36]  * dholbach hugs stgraber
[14:43] <pitti> stgraber: FYI, I'm looking at the autopkgtest one
[14:43] <pitti> (sponsor queue item, I mena)
[14:43] <pitti> "mean" -- TGIF!
[14:43] <stgraber> pitti: ok
[14:46] <rbasak> Is there any difference between a source debdiff and a run of diff against two source directories? Can I just attach a suitable diff that can be applied to a debian source tree and claim it's a debdiff, or would that be wrong?
[14:47] <rbasak> (with an implied necessary -p1 the same as debdiff does)
[14:47] <infinity> rbasak: Why claim it's a "debdiff" at all?  Just call it a "patch", which is what it is. :P
[14:47] <pitti> rbasak: a debdiff between two .dsc is more reliable
[14:47] <pitti> rbasak: but in general, no; as long as your diff doesn't have junk in it it should be fine either way
[14:47] <infinity> (And I have no issues with people submitting source patches, and letting the sponsor sort out how best to apply it to the package)
[14:47] <rbasak> LP (or more likely some bots) treats a debdiff slightly differently in some cases
[14:48] <rbasak> infinity: thanks. Because you're getting this one :-)
[14:48] <rbasak> And thank you pitti
[14:48] <rbasak> (this is because I wanted to revert half of a previous commit and I used git to achieve it)
[14:49] <infinity> rbasak: Oh, I am?  Lucky my.  Should I point out that I've been on vacation since yesterday? :)
[14:49] <infinity> (Happy to look at whatever your patch is when I'm bored, though)
[14:50] <ScottK> If you're really bored, you could look at pitti's libc6 regression in Hardy.
[14:50] <infinity> ScottK: Yeah, I have a firefox tab open for that.
[14:50] <pitti> infinity: or enable ddebs :) what better time to enable them than a Friday afternoon before holidays?
[14:50] <pitti> *duck*
[14:51] <infinity> ScottK: I suspect I know which of the sketchy security patches is the problem, but it'll take a rebuild to test.
[14:52] <mdeslaur> ScottK, infinity: I'm currently looking at the libc regression
[14:52] <infinity> mdeslaur: Oh, shiny.  If you find the offending patch but see no way out other than reverting it (which may be the right answer, depending on the severity of the CVE), let me know, and I can help look.
[14:53] <mdeslaur> infinity: ok, cool. thanks.
[14:53] <jodh> Is there a standard idiom for detecting if a library has bumped its ABI from that same libraries maintainer script? Or is it inferred from the changing version number?
[14:53] <infinity> jodh: If the SOVER hasn't changed, the ABI hasn't changed, or that's a grave bug in the packaging.
[14:54] <infinity> jodh: That's what SOVERs are for.
[14:54] <infinity> jodh: Is there context for this, though?  Why is this something a maintainer script should need to know?
[14:55] <rbasak> infinity: so this is in relation to bug 1084106 and bug 1079185. I've explained everything in those bugs. I'd appreciate you looking at it for the obvious reasons, but also that I'd like to get this resolved and landed before the holidays if possible. I think it's bad that we've not managed to land a fix sooner.
[14:55] <infinity> jodh: Generally, this is something you should be detecting (and hard-failing on) during the build, not during install.
[14:55] <jodh> infinity: Now we have stateful re-exec in Upstart, we can change the maint scripts for the libs it uses to say "restart upstart if our ABI version hasn't changed".
[14:55] <rbasak> infinity: (and I've attached suitable debdiffs^Wpatches)
[14:56] <rbasak> infinity: one final question. I noticed that your changelog entry named quantal rather than quantal-proposed. Does that mean that it's not necessary to use quantal-proposed, that we don't care, that it doesn't matter if you're specific where you dput or something else?
[14:56] <infinity> jodh: You're overthinking it.  You can just have it be "telinit u" unconditionally.
[14:57] <infinity> jodh: If upstart depends on libfoo5, it won't be removed because you install a new libfoo6, so the "if my ABI changed" test is meaningless.
[14:57] <infinity> rbasak: The archive auto-rewrites $series to $series-proposed.
[14:57] <infinity> rbasak: Or, rather, the upload processor does.
[14:58] <rbasak> infinity: so should I submit SRU proposals with -proposed or without? Or don't care?
[14:58] <jodh> infinity: right - thanks! ;-)
[14:58] <infinity> rbasak: I think without looks nicer, but it doesn't matter, both are valid.
[14:58] <rbasak> OK, thanks!
[14:58] <infinity> jodh: As a side note, this should be a trigger.
[14:58] <infinity> jodh: Cause restarting init several times on upgrade is silly.
[15:00] <jodh> infinity: agreed. thanks for pointer.
[15:00] <infinity> rbasak: I'm not sure reverting is necessary.  Let me give reproduction a whirl here, I have a pretty good idea how this should blow up.
[15:01] <rbasak> infinity: thank you! I appreciate it, especially on your holidya.
[15:01] <rbasak> FWIW, I've been trying on armadaxp, not panda (as I don't have my pandas set up since I moved my office). I didn't see before how that would matter, but perhaps it does.
[15:03] <infinity> rbasak: Could matter a lot, if the bug only manifests when installing with ubiquity.
[15:03] <infinity> rbasak: Which would be hard to reproduce on anything but omap/omap4. :P
[15:03] <rbasak> Ah. I assumed d-i!
[15:04] <rbasak> And that would explain it
[15:04] <ricotz> infinity, hi :), i hate to bother you again, but do you have any news on the eglibc cherry-pick?
[15:05] <infinity> ricotz: It's in progress.  It's pending fixing an ARM bug at the same time.
[15:06] <soren> infinity: You suck at vacation.
[15:06] <soren> infinity: Just sayin'.
[15:06] <ricotz> infinity, do you mind to put a "preview" packages somewhere? i can build it locally too
[15:06] <jpds> soren: He works until infinity.
[15:06] <infinity> soren: I've noticed.
[15:06] <soren> jpds: And beyond?
[15:06] <soren> jpds: Or would that be overdoing it=
[15:06] <soren> ?
[15:07] <infinity> ricotz: When I'm done the other bits, sure.  The current source isn't buildable. :P
[15:07] <ricotz> infinity, ok, thanks, feel free to ping me
[15:08] <ricotz> this is really an annoying issue here causing lock-ups :\
[15:31] <barry> mvo: so, xapian :)
[15:33] <mvo> barry: eh
[15:34] <barry> mvo: what about whoosh?
[15:34] <mvo> http://whoosh.org/ - Birthplace of the International Association of Xena Studies  ?
[15:35] <barry> http://pypi.python.org/pypi/Whoosh/
[15:35] <barry> mvo: but your link looks like more fun :)
[15:36] <mvo> barry: is it available for py3 ;) the package I have here is py2
[15:36] <mvo> barry: I don't know about it, it looks interessting, I have a look. but it would be nice to know the py3 state
[15:37] <infinity> barry: Pure python doesn't sound like it would be performant.
[15:37] <barry> mvo: upstream claims to support py3, and yeah i see it's only py2 in raring.  shouldn't be too difficult to whip up py3 packaging
[15:37] <barry> infinity: there's fast, and then there's fast enough :)
[15:37] <infinity> barry: If we're replacing xapian, surely we want to replace it with something that doesn't suck on ARM.
[15:37] <mvo> infinity: !python I guess
[15:37] <mvo> (at all!)
[15:37] <infinity> mvo: C/C++ would be nice...
[15:38] <infinity> But you know how I feel about that. :P
[15:38] <mvo> :)
[15:38] <barry> infinity: maybe you'd like to take a crack at http://trac.xapian.org/ticket/346  -- i failed ;)
[15:39] <stgraber> sounds like a good holiday project for infinity ;)
[15:39] <infinity> I saw the word "swig" and was scared away.
[15:40] <barry> infinity: wise
[15:40] <seb128> slangasek, bdmurray, ScottK, infinity, SRU team: I would appreciate if somebody could review the nautilus fix from ritz that I just uploaded to precise quantal (https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1090344)
[15:41] <bdmurray> seb128: oh hey, yesterday I noticed there are two popplers in the quantal queue with different fixes
[15:41] <seb128> slangasek, bdmurray, ScottK, infinity: it's a small patch and some people have been waiting on it to be rolled out for a while (but it got blocked due to organizational issues ... anyway it would be good to get it out before holidays if we can)
[15:42] <infinity> seb128: I'll look at it.
[15:42] <seb128> infinity, thanks
[15:42] <infinity> seb128: On the condition that you talk to bdmurray about the poppler collision. ;)
[15:43] <seb128> bdmurray, shrug, the queues don't make those errors visible ... I've rejected mine, please accept the old one if you can, I will reupload mine after the holidays
[15:43] <seb128> infinity, ^
[15:43] <infinity> seb128: Better if you reupload yours incorporating the other one, IMO.
[15:43] <infinity> seb128: No point dragging it out into two SRU releases.
[15:44] <seb128> infinity, right, I'm not sure I will get to that today though ... but I will try
[15:44]  * infinity nods.
[15:45] <barry> mvo: at the very least, i'll put together a py3 packaging of whoosh, and maybe we can give it a try and see how well/poorly it works?
[15:50] <mvo> barry: yeah, indexing the app-install-data and indexing software-center agents data would be good
[15:51] <infinity> Indexing, and then some sort of mock testsuite to see how well the indexes perform.
[15:51] <infinity> And do it on the slowest device you can find. :P
[15:52]  * stgraber looks at his beagleboard C4
[15:52] <barry> infinity: i have an mx53 :)
[15:52] <infinity> barry: stgraber wins.
[15:52] <barry> fsvo "wins"
[15:53] <infinity> Yeah.  I have a "winning" C4 too.  It's going to learn to fly any day now.
[15:53] <barry> infinity: out the window at high velocity?
[15:53] <infinity> barry: Something like that, yes.
[15:57] <mvo> I have a rapberry pi, where does that stand in the ordering of fast<->slow?
[15:58] <infinity> mvo: Right around the C4.
[15:59] <stgraber> except that the C4 can actually boot Ubuntu )
[15:59] <stgraber> (well, for some definition of boot that doesn't involve anything more complex than a shell)
[15:59] <infinity> Except that, yes.  I believe mvo runs Raspbian on his Pi.
[16:02] <mvo> yeah, its the debian thing running on it with some "crossports" from ubuntu
[16:02] <infinity> seb128: Accepted.
[16:09] <xnox> stgraber: i totally saw a lab of rasbianpis running mythbuntu, does that count as "can actually boot ubuntu" or not?
[16:09] <infinity> xnox: It can't have been mythbuntu.
[16:09] <infinity> xnox: It could have been some mythbuntu stuff recompiled, but not mythbuntu as it exists in our archives.
[16:10] <stgraber> infinity: well, actually, wouldn't quantal armel sort-of vaguely work on the raspberry pi?
[16:11] <stgraber> (at least for the part of main we rebuilt)
[16:11] <infinity> stgraber: Yes, assuming all the packages you wanted were recompiled during the quantal cycle.
[16:11] <infinity> We rebuilt all of main.
[16:11] <infinity> And possibly most of mythbuntu was rebuilt in that timeframe.
[16:12] <infinity> So, I suppose it's concievable that quantal/mtyhbuntu could run on v5/v6 devices.  Maybe.
[16:12]  * xnox saw it running, but didn't have chance to tinker with it much they were display units.
[16:12] <infinity> I wouldn't hold my breath.
[16:44] <seb128> infinity, thanks
[16:50] <jono> Sweetshark, are you an ubuntu member?
[17:20] <jamespage> jodh, still around?
[17:20] <jodh> yup
[17:22] <Sweetshark> jono: hmm? no, doesnt seem so.
[17:22] <jono> Sweetshark, you should apply, and then we can get your blog posts on planet
[17:22] <jono> Sweetshark, ping Daniel Holbach, he will help you through the process
[17:23] <Sweetshark> jono: yep.
[17:23] <jamespage> jodh, am I correct in thinking that an upstart configuration that is a task
[17:23] <jamespage> really has no concept of 'stop on'
[17:23] <jamespage> i.e. its not long running....
[17:24] <jodh> yes
[17:24] <jamespage> jodh, great - thats what I though
[17:24] <jono> Sweetshark, cool :-)
[17:26] <Sweetshark> dholbach actually asked me to reapply for upload rights, which IIRC would make me qualify ~automatically, but it fell over the cliff. inbox zero is on the horizon, but its run quickly away from me :/
[17:26] <stgraber> jodh: did you see my pm from earlier today?
[17:29] <jodh> stgraber: ?
[17:31] <stgraber> jodh: I sent you a private message around 14:00 UTC regarding the dbus events branch
[17:31] <jodh> stgraber: too many splits - on sec...
[17:31] <stgraber> ok :)
[18:04] <xnox> slangasek: half of language-pack packages are actually in fact empty.
[18:04] <xnox> (binary that is)
[18:04] <slangasek> huh
[18:04] <slangasek> seems like we should fix things to stop generating those
[18:05] <slangasek> unless they're needed as dependencies of other langpacks that aren't empty?
[18:05] <xnox> slangasek: i guess we need to have ability to generate 'language-pack-none' which provides 'langauge-pack-<countrycode>'
[18:06] <slangasek> I don't think we should need to do that at all if they're empty
[18:06] <xnox> slangasek: otherwise things like ubiquity/presseeeding/languages checks might break. Or do we have locales that don't have language packs?
[18:06] <slangasek> I would expect this to be handled in language-selector
[18:06] <slangasek> I'm pretty sure that from time to time we've had supported locales with no language packs
[18:07] <xnox> slangasek: it's even bigger number of packages that provide <<10% of the template translation.
[18:07] <slangasek> sure
[18:07] <slangasek> we still want to provide those, though
[18:07] <xnox> ok.
[18:07] <slangasek> incomplete translation is better than none if it's the only language you speak :)
[18:08] <xnox> slangasek: some are funny, the only string translated is "continue" - i guess that's all that user will be clicking =)
[18:09] <slangasek> heh
[18:10]  * xnox ponders to launch juju spin up hadoop cluster to tell me the most translated string. Will it be "quit" or "continue" ?
[18:21] <stokachu> stgraber: when you get a chance could you review bug 633109?
[18:26] <stgraber> stokachu: nomination approved, I'll review and upload in a minute
[18:26] <stokachu> stgraber: sweet thanks man
[18:26] <stgraber> np
[18:30] <hrw> hi
[18:32] <hrw> I have bug 1085392 which is about adding Samsung Chromebook UCM profiles into alsa-{lib,utils} in order to protect users from frying speakers (if they will try to get sound working on their own). Changes landed in Raring and I made SRU for both quantal and precise. Official procedure requires uploading SRU packages to -proposed but as alsa is in main I am unable to do that. Can someone review patches/packages and upload them for me?
[18:32] <hrw> http://tygrysek.juszkiewicz.com.pl/~hrw/ubuntu/chromebook/SRU/ contains SRU packages
[18:33] <mdeslaur> infinity: it's CVE-2012-3480.patch...still trying to figure out why though
[18:34] <mdeslaur> infinity: oh, and only on i386
[18:39] <stgraber> stokachu: ah, oneiric and precise are the exact same release...
[18:39] <stgraber> stokachu: so your version number is wrong as you can't upload the same version to the archive twice
[18:39] <stgraber> stokachu: but I'll fix that for you
[18:39] <stokachu> ah..
[18:39] <stokachu> even for different releases?
[18:39] <stgraber> stokachu: yeah because http://archive.ubuntu.com/ubuntu/pool is shared for all releases
[18:39] <stokachu> ah ok
[18:40] <stokachu> so i needed to mark precise .2 i presume?
[18:40] <xnox> hrw: please update the bug report details. it's currently not in the state fit for SRU.
[18:40] <stgraber> so the first one will be <IP_ADDRESS>ubuntu<IP_ADDRESS> and the other one will be <IP_ADDRESS>ubuntu<IP_ADDRESS>
[18:41] <stokachu> stgraber: is the 11.10.1 12.04.1 something I  need to continue to use?
[18:41] <stgraber> stokachu: in such case we usually embed the release in the version, that avoids clashes if another SRU is needed later
[18:41] <stgraber> stokachu: in cases where the exact same version exists in more than one release you're SRUing to, yes
[18:41] <stokachu> ah ok gotcha
[18:42] <stgraber> stokachu: the security team has an handy guide at: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation
[18:42] <stokachu> sweet /me bookmarks
[18:43] <stokachu> ah i see the version examples have it listed nicely
[18:53] <stgraber> stokachu: oh, another note, the package is 3.0 (native), so you can't use debian/patches
[18:53] <stgraber> stokachu: I'll just apply the patch inline
[18:54] <stokachu> stgraber: ah damn.. ok thanks :D
[18:54] <stokachu> is it not worth doing patches for a package like this then?
[18:54] <stokachu> its pretty small
[18:55] <stgraber> uploaded
[18:56] <stokachu> awesome! :D
[18:56] <stgraber> native packages are usually just patched inline. Using quilt would require some more changes to debian/rules
[18:56] <stokachu> cool, understood
[18:56] <stgraber> (I vaguely wish dput wasn't a native package, but there's no point in divering from Debian for that...)
[18:56] <stgraber> @pilot out
[18:58] <stokachu> micahg: i was able to get a new package pushed to my ppa for bug 1068399
[19:00] <hrw> xnox: ok
[19:01] <micahg> stokachu: ok, so, the backport from raring needs to go through quantal, as soon as you can confirm that the new version builds/installs/runs on quantal and precise, I"ll push it for you
[19:01] <stokachu> micahg: cool can i just use the backport tool for quantal and test it myself?
[19:02] <micahg> stokachu: wait, how was the issue I mention addressed?
[19:02] <stokachu> the latest parallel doesn't exhibit the issue filed in the debian bug
[19:03] <stokachu> at least from my testing
[19:03] <micahg> well, unless the two were made cli compatible, it still shares a binary with another package, but doesn't conflict
[19:06] <micahg> though, it's not any worse than the distro version
[19:06] <stokachu> would we want to do a one-off for Ubuntu where it conflicts then?
[19:08] <micahg> well, I'd like someone to talk to the Debian maintainer first about it, there might be an easy solution
[19:08] <stokachu> ok
[19:09] <jtaylor> there is no easy solution ._.
[19:28] <hrw> xnox: I hope that new description will be fine
[19:28] <hrw> s/description/comment/
[19:30] <xnox> hrw: so it's still possible to fry speakers =/ oh well
[19:30] <hrw> xnox: thats kernel stuff which may get fixed later
[19:31] <hrw> xnox: but less users will play with mixer once they get working audio == less fried speakers
[19:31] <xnox> sure.
[19:58] <hrw> xnox: thanks for help
[19:59] <xnox> hrw: np.
[21:36] <arges> how do I get a package in the upload queue to be dequeued?
[21:36] <marga> dput
[21:36] <marga> dcut
[21:37] <bdmurray> pitti: I've a _usr_lib_indicator-session_indicator-session-service.1000.crash file wihtout a StacktraceAddressSignature with the latest apport in quantal if that is interesting to you
[21:41] <dobey> oh that reminds me
[21:42] <dobey> in raring at least, it seems apport gets launched under python3, even when python2-only apps crash, and it will crash if the apport source.py file for the app tries to import stuff that's only in python2
[21:44] <arges> marga, even if didn't upload it?
[21:58] <Laney> the ubuntu archive doesn't support dcut
[21:58] <Laney> arges: which queue?
[22:05] <arges> Laney, precise queue, duplicity
[22:05] <arges> Laney, i'm doing a fixed debdiff right now
[22:05] <Laney> arges: so an UNAPPROVED queue. The answer is to ask an archive admin to delete it.
[22:05] <Laney> s/delete/reject/
[22:06] <Laney> if it's not your upload you better also explain why
[22:06] <arges> Laney, ok... who should i ask at this hour on a Friday
[22:06] <arges> Laney, it is my upload
[22:06] <arges> but it was sponsored by somebody else
[22:07] <Laney> https://launchpad.net/~ubuntu-archive/+members#active
[22:07] <Laney> Someone will probably look here soon enough though, I'd imagine.
[22:10] <arges> infinity, hey if you get a chance can you delete an upload for duplicity/precise ?
[23:02] <NCommander> Any MIR team members awake? I have a bit of an unusual situation
[23:19] <infinity> arges: You want me to reject duplicity_0.6.18-0ubuntu4 from the precise queue?
[23:36] <arges> infinity, yes I have a fixed debdiff on that bug
[23:36] <arges> bug  1013446 btw
[23:36] <infinity> arges: Rejected.
[23:37] <arges> thanks