[00:01] <mgz> lifeless: if you kick up in te next few hours and want to look at some subunit things I'll be around
[00:01] <lifeless> hi
[00:01] <lifeless> I'm here
[00:01] <lifeless> trunk subunit and testtools are, AFAICT, ready for releases
[00:01] <lifeless> Damn, I wanted to grab tres
[00:08] <mgz> we didn't explictly change subunit to use the unicode path though right? just relied on the __str__ behaviour now giving utf-8
[00:12] <lifeless> subunit depends on unicide exceptions no
[00:12] <lifeless> w
[00:13] <lifeless> if someone has it fail, we can say 'your exception isn't serialisable safely, see testtools for helpers, or hey, use testtools
[00:39] <johnjosephbachir> hey folks. a developer in my team has been using a branch bound to the server (IE, only using checkout, update, and commit), but also often uses the --local flag on commit and then commits to the server in a batch. she recently experienced a situation where she is missing some local commits, and can't find them in the repo OR her local code. she suspects that this is because she did a pull at some point in bettween local commits and server commits
[00:40] <johnjosephbachir> how can we start investigating what happened? i suspect this code is hiding out in one of the "hidden" branches that bazaar keeps around... i can't remember the name of that concept
[00:48] <johnjosephbachir> i suppose this is a mailing list -grade question
[01:14] <johnjosephbachir> fwiw, seems like i had the same problem as this guy http://srtsolutions.net/blogs/chrismarinos/archive/2008/10/24/don-t-loose-your-head-with-bazaar.aspx
[01:16] <spiv> johnjosephbachir: sounds strange
[01:16] <spiv> johnjosephbachir: it would be good to have a bug report with as many details as possible
[01:16] <johnjosephbachir> alas i probably don't have the time to do that
[01:17] <lifeless> morn morn
[01:26] <mgz> ah, lifeless back again
[01:26] <mgz> see my name in lights on planet debian, thanks ;)
[01:28] <johnjosephbachir> spiv: thanks-- code saved!
[01:38] <lifeless> mgz: :)
[01:38] <lifeless> mgz: and on planet.python.org
[01:38] <spiv> johnjosephbachir: great!
[01:38] <mgz> so, my subunit question boils down to if we want to something before release about:
[01:38] <mgz> http://bazaar.launchpad.net/~subunit/subunit/trunk/revision/125/python/subunit/__init__.py
[01:38] <mgz> your check-and-mention testtools suggestion sounds fine to me
[01:38] <poolie> hello mgz, spiv, lifeless
[01:38] <mgz> something like getattr(self, "_exc_info_to_unicode", None), then fall back to self._exc_info_to_string and complain if it's not ascii
[01:38] <mgz> hey poolie
[01:38] <lifeless> mgz: we could derive from testtools
[01:38] <mgz> is a goal to avoid an explict testtools depedency though?
[01:38] <lifeless> no
[01:38] <lifeless> it has an explicit one already
[01:38] <mgz> okay, in which case, just using the testtools class and maybe a version check would do
[01:39] <lifeless> -garh
[01:41] <lifeless> mgz: see my last commit to testtools :P
[01:42] <mgz> ha!
[01:43] <mgz> my fault too, didn't get as far as testing attempt 2 on py2k
[01:43] <mgz> *3
[01:49] <aaron01> I'm trying to use bzr import on a tarball, but I get a 'tree is malformed' error. Any ideas?
[01:51] <mgz> maybe something like: http://paste.ubuntu.com/458088/
[01:59] <lifeless> mgz: sorry I had already pushed :P
[01:59] <mgz> ah! I'll pull.
[01:59] <lifeless> aaron01: please file a bug? Not sure what is wrong there.
[02:00] <aaron01> Seems like adding a top level dir (that will be stripped) fixes the problem
[02:00] <aaron01> but now getting it trying to import that dir into another branch :(
[02:00] <aaron01> s/it/the same error
[02:00] <poolie> spiv does bug 600636
[02:00] <poolie> look to you like just another issue of a connection drop causing "too many concurrent requests"
[02:01] <poolie> it does to me
[02:01] <jam> lifeless, poolie: do you know why when submitting a bug with bzr, you get the option to set the priority, etc?
[02:01] <jam> I don't see that for Meliae, or Loggerhead, or fastimport or any other project, and I miss it
[02:01] <mgz> okay, yup, your rev is a less borked version of the same
[02:01] <jam> anyway, back to family time, just curious if it was an option that needs setting somewhere
[02:03] <poolie> jam it's something to do with permissions
[02:03] <poolie> i'm not sure which thing controls
[02:03] <poolie> it
[02:03] <poolie> perhaps whether you're in the bug control team
[02:04] <poolie> ask in #launcphad
[02:04] <spiv> poolie: oh wow
[02:04] <spiv> poolie: the commit code path was meant to be fixed ages ago.  Interesting!
[02:04] <poolie> mm?
[02:05] <spiv> It does seem plausible that a connection drop is involved.
[02:05] <spiv> Hmm, likely even.
[02:05] <poolie> there is a message about it
[02:06] <spiv> Oh right.
[02:07] <lifeless> jam: I think its driver permission
[02:07] <lifeless> most things don't have driver set
[04:32] <mkanat> poolie: Hey hey, do you have a second?
[04:33] <poolie> hi, i do
[04:33] <mkanat> poolie: Great, let me remember what I needed to chat with you about....
[04:34] <mkanat> poolie: Oh, right. So, it sounds a bit from the discussion with Francis and the way things are gong on the list that I am in fact actually sort of going to end up owning loggerhead. Is that right?
[04:34] <lifeless> \o/
[04:34] <mkanat> poolie: I mean, with oversight from you and the bzr team.
[04:34] <poolie> that sounds good to me if it's ok withy ou
[04:34] <mkanat> poolie: Yeah, it's totally okay with me, but it will probably require an adjustment in the way that the contract works.
[04:36] <mkanat> poolie: Should I discuss that with you first and then Francis, or should Jolie just discuss it with Francis?
[04:37] <poolie> with me first
[04:37] <poolie> it's up to you and jolie which of you wants to be involved from your side
[04:37] <poolie> this is because it's expanding the scope of your work?
[04:37] <poolie> let's talk in private
[04:37] <mkanat> Okay.
[04:47] <lifeless> poolie: I have a request; please document in doc/developers/testing.txt how to make bzr selftest run on a ramdisk.
[04:47] <lifeless> poolie: I think many folk would benefit.
[04:48] <lifeless> I can file that as a bug if you would like.
[04:50] <poolie> no i'll just do it
[04:52] <lifeless> thanks!
[07:17] <lifeless> poolie: http://pastebin.com/rULLkF29
[07:24] <lifeless> vila: --config please, not --conf
[07:25] <lifeless> --conf is a strange abbreviation
[07:25] <lifeless> c = config.LockableConfig(lambda : location)
[07:25] <lifeless> reads really strangely
[07:25] <lifeless> perhaps the LockableConfig constructor should be different
[07:27] <lifeless> vila: I *really* wish you would not mix changes to imports with test changes
[07:27] <lifeless> vila: it makes the patch about 4 times harder to review.
[07:27] <vila> lifeless: I don't want to break the chain of constructors, I can add a def get_filename if you prefer
[07:28] <lifeless> vila: its like a massive whitespace change *just because*
[07:28] <lifeless> vila: and as far as I can tell no actual changes to many tests.
[07:29] <lifeless> vila: so I'm going to push this back to you
[07:29] <vila> lifeless: yeah, jam complains about that too, but we won't get the import problem addressed until 1) we all stop importing symbols, 2) we fix all remaining wrong imports
[07:29] <lifeless> get me a diff that shows the *actual* test changes, and I'll happily review it.
[07:29] <lifeless> vila: be tolerant of what you accept, and strict in what you output - wonderful IETF principle.
[07:30] <lifeless> vila: it applies here - accept difference in files you are editing. Make what you write be up to scratch.
[07:30] <vila> lifeless: this one goes both ways :) That was my reply to jam :-D
[07:30] <lifeless> vila: I don't think you're considering the impact on the reviewer enough.
[07:30] <lifeless> We're here to think about the change, about what it is meant to accomplish, and we're having to go line by line through noise.
[07:30] <vila> I do, but the alternative is to postpone these fixes endlessly
[07:30] <lifeless> +1
[07:32] <lifeless> vila: 'the import problem' is approximately 0% of our bugs.
[07:32] <lifeless> vila: a bad review can easily let a new bug in, or fail to see a structural issue.
[07:32] <lifeless> vila: I really want you to think about the relative costs and merits here.
[07:33] <poolie> vila i think lifeless has a point there
[07:34] <vila> I really wish to feel less alone to realize that our actual tests serve as examples, get copy/pasted and decrease the overall quality which as an impact on our productivity because it makes them harder to modify :-(
[07:35] <poolie> i think i agree with you on that too :)
[07:36] <poolie> does importing the module make much difference in tests?
[07:36] <poolie> presumably we don't care much about laziness?
[07:36] <poolie> or is it just for the sake of consistency and examples?
[07:37] <lifeless> vila: I really don't see that the changes you're making make stuff easier or harder to modify.
[07:37] <lifeless> Just different.
[07:38] <lifeless> not importing symbols has a specific benefit when we want to use lazy_import, but that does not apply to tests [perhaps it should, but the general import in tests is TestCase*, which can't be lazy imported anyway)
[07:41] <vila> being consistent makes it easier to move code from one file to another or even inside the same file sometimes
[07:42] <lifeless> I don't like doing 'from bzrlib import trace' in tests, because in tests you normally want a test object of the class, and that can't be called trace, so it has to be 'from bzrlib import trace as _mod_trace', and thats ugly.
[07:42] <vila> not being consistent means you never know where a symbol is coming from and in this particular case prefixing with the module makes it 4 times easier to read
[07:43] <vila> lifeless: <1% of the cases
[07:44] <lifeless> Look, there are two things here.
[07:44] <lifeless> a) when we do cleanups
[07:44] <lifeless> b) whether they are better or worse.
[07:44] <lifeless> Put (b) to the side; I'm tired, have a different opinion anyway, and *I was not complaining about b before*.
[07:45] <lifeless> I, and John, are both complaining about mixing code changes with cleanups-to-code.
[07:46] <lifeless> if everytime you touch a module, you want to put in a separate branch to clean it up, it would not take much more-or-less of your time
[07:46] <lifeless> it could be reviewed totally separately to the *actual thing* you are working on.
[07:47] <lifeless> and your colleagues wouldn't be feeling that reviewing your changes is hard
[07:52] <Outlander> hi
[07:52] <Outlander> what's the best way to convert cvs repo to bzr? appears to be a few different ways?
[07:55] <vila> lifeless: 1) I got vaccines yesterday and that makes me grumpy  2) I've made separate branches in the past for cleanups and that raised discussions anyway so I grew tired of doing that on top of feeling alone cleaning this up 3) the import thing sounds like spurious spaces changes, yet, reviews are either a) not pushed back when they introduce them b) pushed back when they are VWS
[07:55] <vila> the end result is that spaces are still there and the problem is not addressed
[07:56] <maxb> Outlander: what are the ways? I only know of cvs2bzr
[07:57] <vila> the imports are more important than spaces and there has been associated problems with them (I encounter one when trying to monkey-patch transport.get_transport, another one was people were importing symbols already imported from another module which broke when the symbol went to a different module or were fixed to not being imported as a symbol)
[07:58] <lifeless> on whitespace - when it gets in the way of review, it gets pushback from me; when it doesn't, it doesn't.
[07:58] <lifeless> the changes here are big fraction of the total patch.
[07:59] <lifeless> its an 800 line patch, for a 200 line change, or something like that.
[07:59]  * vila tells his vaccines that they don't have to make it grumpy and come in the way to progress
[07:59] <vila> lifeless: that's unfair, please check
[07:59] <lifeless> I did
[08:00] <lifeless> 822 lines of diff
[08:00] <vila> 1) s/file/infile/ trivial to filter on reading
[08:00] <lifeless> 542->669 are the actual new tests (I think, my eyes are glazing over so I may be missing other semantic changes)
[08:01] <vila> add 426-> 448
[08:01] <lifeless> and 300 lines at the start; so 420/822
[08:01] <lifeless> ok, 440/822
[08:01] <lifeless> and thats exactly my point
[08:01] <lifeless> in all the excess I couldn't see an important part of the change.
[08:04] <vila> so, basically, you're saying that you should not cleanup, but you did so in many proposals and I supported that because it's part of keeping the code in good health, 324->333 for example is not required but the cleanup version make it easier to see what is happening here (and avoid useless calls)
[08:05] <spiv> He's saying: consider the audience (which is good advice for any kind of writing)
[08:05] <vila> So where is the limit on cleanups ?
[08:05] <lifeless> There is a balance; I may have gotten it wrong in the past, and for that I'm sorry.
[08:06] <vila> I'm sorry too but that doesn't address the problem :) Let's put emotions aside and focus on solutions
[08:06] <spiv> If you make a diff that seems unnecessarily hard for a reviewer to review, expect them to be a bit grumpy about it.
[08:07] <vila> yup, I was expecting that. I was hoping that people were rejoicing about cleanups progressing instead of staling though :)
[08:07] <spiv> So either try to make easier-to-review diffs, or perhaps take other steps to ease the burden, e.g. point out the lines of the diff with the interesting changes.
[08:08] <vila> I (and I think others) have been daunted in many occasions...
[08:08] <lifeless> vila: There are two sorts of cleanups here: code clarity ones, and 'import style'. The former I rejoice at, the latter are entirely mechanical, and have caused bugs in the paste. I do not rejoice at those.
[08:08] <spiv> There's no fixed limit, it really depends on the details of each patch.
[08:08] <vila> which bugs ?
[08:09] <lifeless> we've had import cleanups break due to shadowed names
[08:09] <lifeless> they are not risk free.
[08:09] <vila> true,
[08:09] <lifeless> They are also not reviewer time free.
[08:09] <spiv> (e.g. a 90% cleanups patch might be fine if the total patch is only 10 lines long :)
[08:10] <vila> they are not time free for me either, but some tests are so unclear that I spend time deciphering them too
[08:11] <lifeless> I'm saying that the cost and benefit need to be weighed; neither side is 0, and neither side is aleph-0
[08:11] <lifeless> or aleph-1
[08:11] <vila> on the overall, I consider that importing symbols is easier to *write* but harder to *read* and leads to more symbols staying around after they are not being used
[08:12] <vila> and since code is more often read than written, the weight is more important too
[08:12] <lifeless> vila: I don't see why symbols that aren't used is a maintenance problem; what does it make non-trivial that is trivial otherwise ?
[08:12] <vila> review is *part* of the readers but not the only part
[08:12] <lifeless> (I like a lean import list btw, don't get me wrong)
[08:12] <vila> false positives when grepping or even thinking about the module
[08:12] <lifeless> vila: something you can do in cases like this is filter the diff
[08:13] <lifeless> and only show the bits that are relevant
[08:13] <lifeless> andrew has done that in the past and its very nice
[08:13] <vila> lifeless: ha, nice one
[08:13] <lifeless> vila: but really, it all comes down to what has been said before
[08:13] <lifeless> consider what the people you ask to review are going to be reading.
[08:14] <lifeless> you know what a long repetitive patch is like to review.
[08:15] <vila> the problem with that is that we tend to *never* address some problems
[08:15] <vila> and we also said before that we are supposed to clean up things when we modify close enough parts
[08:16] <lifeless> I've got nothing more to offer.
[08:16] <lifeless> I'm sad.
[08:17] <vila> so, hmm, looks like I will get back to the two branches approach but there was some concerns about polluting the active review queue with such cleanups too
[08:17] <vila> and landing them without review was also frowned upon
[08:17] <lifeless> I think that that concern is a reflection of this
[08:17] <spiv> vila: so, my opinion is that opportunistic cleanups of nearby code is fine, but not at the cost of significantly worse diffs
[08:17] <vila> lifeless: I don't want to make you sad because I
[08:18] <vila> lifeless: I don't want to make you sad because I'm cleaning things up which should make you happy, that's counter-productive :)
[08:18] <spiv> vila: If it e.g. makes a smallish diff large and repetitive I'd rather get two separate diffs.
[08:19] <vila> so, how about a cleanup branch as a pre-requisite that gets automatically approved if not vetoed when the main branch is approved ?
[08:19] <spiv> Um,
[08:20] <vila> more work, but I'm ready to do it if it means we progress here
[08:20] <spiv> Perhaps that's ok, although it seems like a solution to a problem we don't have yet?
[08:20] <spiv> Is it really that hard to get approval for cleanup-only branches?
[08:20] <vila> we have a problem: our code base is not consistent
[08:20] <spiv> I haven't found that to be the case, but I also have not tried to land a large one recently.
[08:21] <spiv> To be clear: a pre-req branch sounds fine to me
[08:21] <spiv> It's the "automatically approved" part that I'm unsure about.
[08:22] <spiv> Also, I think we still have the notion that an unreviewed branch can "time out" and just be landed, although we don't exercise it very often.
[08:22] <spiv> Which would seem to cover that case (but I would hope we still do not exercise it very often).
[08:28] <vila> spiv: I think that's the crux of the problem: do we want cleanups, do we want to review them ?
[08:30] <spiv> Yes, and yes.
[08:30] <spiv> In my opinion :)
[08:31] <lifeless> I might let poolie have his office back.
[08:31] <vila> then it boils down to not mixing them up with actual fixes
[08:31] <spiv> The review will often be easy: read the explanation in the cover letter, and then eyeball the diff to feel secure that it is fine.
[08:31] <spiv> Right.
[08:32] <lifeless> vila: thats all I asked for
[08:33] <vila> lifeless: good, I'll try harder then
[08:40] <vila> lifeless: and sorry for starting grumpy on this subject
[08:44] <mneptok> FINISH HIM!
[08:44] <mneptok> (sorry. couldn't resist.)
[08:45] <spm> we hadn't noticed :-)
[08:45] <mneptok> i love you, too :)
[08:45] <spm> mneptok: so how's the new job going since you abandoned us all?
[08:48] <lifeless> mneptok: cavemen in mountain fortresses shouldn't throw spears.
[08:49] <mneptok> spm: it goes well. busy as hell. long days. but quite rewarding.
[08:49] <spm> excellent!
[08:49] <mneptok> lifeless: i'm touched you noticed my brow-ridge.
[08:50] <spm> touché!
[08:50] <lifeless> mneptok: I've seen the photos
[08:50] <lifeless> I went blind.
[08:50] <lifeless> :)
[08:51] <mneptok> lifeless: you know, i recently got another photo from the same day the "mnep the gigolo" photo was taken. this one onvolves a camisole, a top hat, and clown shoes.
[08:51] <lifeless> _LOL_
[08:52] <mneptok> oh, and grandma underwear
[08:52] <lifeless> this is a family rated channel
[08:52] <mneptok> grandma's part of the family.
[08:53] <mneptok> and until i finish chewing through this leash, so am i. ;)
[08:55] <mneptok> /m/m lifeless http://mneptok.com/kvf-clownshoes.jpg
[08:55] <mneptok> gah
[08:55] <mneptok> tab complete fail
[08:55] <mneptok> ah well, don't click that if you're under 18 or value your sanity
[08:56] <spm> I've menepolo'd before. how bad could this be.....
[08:56] <spm> AAAAAAAAAAAAAAAAaaaaaaaaaaaaaaaaaaa
[08:57]  * spm reaffirms the desire to NOT click on any menptok.com urls to images again
[08:58] <mneptok> am i not hot?
[08:59] <spm> um...
[09:00] <mneptok> 01:45 < mneptok> i love you, too :)
[09:00] <spm> hahahaha
[09:06]  * mneptok rm's before Google decides to index that
[09:08] <spm> Google. Knows. All. Google. Sees. All.
[09:09] <poolie> that's exactly what stephenconroy needs to save us from
[09:09] <poolie> apparently
[09:11] <mneptok> Bing knows and sees all, but the Executive Oversight Committee For Strategic Use Of Internet Data And Applicability For Increased Market Penetration can't get the data on their Zunes.
[09:12] <spm> EOCFSUOIDAAFIMP ?
[09:12] <mneptok> gesundheit
[09:13] <spm> thank you
[10:51] <lifeless> poolie_: your _ is showing.
[10:57] <poolie_> heh
[10:57] <poolie_> as nethack says "you are being punished"
[10:58] <poolie_> i think that's actually a _o
[11:06] <lifeless> yah ball n chain
[11:34] <jave> hello
[12:19] <jave> I'm trying to set up an Hudson instance to build emacs from bzr
[12:19] <jave> the Hudson bzr plugni tries to do this: bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk /var/lib/hudson/jobs/emacs-trunk/workspace
[12:19] <jave> but its really slow
[12:20] <jelmer> jave, is there any reason it needs the full history
[12:20] <lifeless> jave:  do 'bzr init-repo /var/lib/hudson/jobs
[12:21] <jave> well, I want it to be compatible with the hudson-bzr plugin, will it work if I do it by hand?
[12:21] <lifeless> yes
[12:21] <jave> lifeless: stuff that has nothing to do with bzr lies in /var/lib/hudson/jobs
[12:22] <lifeless> jave: you're right
[12:22] <lifeless> add --no-trees to the command
[12:22] <jave> hmm ok
[12:22] <lifeless> thought that may cause it to not work
[12:22] <jave> ok
[12:22] <lifeless> I'd really just do what I initially suggested
[12:23] <jave> ok, but what happens if I have different jobs with different bzr urls?
[12:27] <jave> I think I will need special workspace configuration for hudson
[12:27] <lifeless> no
[12:27] <lifeless> honestly
[12:27] <lifeless> just init-repo at the jobs level
[12:27] <lifeless> its what everyone does.
[12:30] <jave> ok
[14:28]  * bialix waves at GaryvdM
[14:29] <GaryvdM> Hi bialix
[14:29] <bialix> Hey Gary!
[14:29] <bialix> Thank you for doing release
[14:30] <GaryvdM> Sure - Want it to get into the win installers
[14:30] <bialix> yeah :-)
[14:30] <bialix> how's footbal 'raound you?
[14:30] <bialix> how's football around you?
[14:31] <GaryvdM> Ah - cool. I don't watch it much
[14:31] <GaryvdM> Do you watch it?
[14:32] <bialix> GaryvdM: sometimes. last weeks was a crunch for me :-/
[14:35] <bialix> GaryvdM: I'm planning to be on vacation in second half of July. And we need to release 0.19 final till August for Maverick. It means I have only 2 weeks for any QBzr development
[14:36] <bialix> GaryvdM: do you have any specific things in mind that I should look at?
[14:36] <GaryvdM> bialix: I'm also planing on taking a weeks leave soon.
[14:37] <GaryvdM> bialix: It would be cool if they were in sync
[14:37] <bialix> so maybe we should release 0.19 final till our vacations?
[14:37] <GaryvdM> bialix: I want to try get at least qcat and qdiff to have a toolbar like qannotate
[14:38] <GaryvdM> for 0.19
[14:38] <bialix> hmmm
[14:38] <bialix> yep, it would be cool
[14:38] <bialix> I will try to look at qlog labels again
[14:38] <bialix> we have one special case here: bzr qlog colo:
[14:39] <GaryvdM> I've been chipping away at the threads branch.
[14:39] <bialix> I want to see labels as colo:trunk, today it's shown as colo:/trunk
[14:39] <bialix> chip away? what do you mean?
[14:41] <GaryvdM> bialix: It's a saying - If you want to cut through a log, you chip away at it with a axe
[14:42] <GaryvdM> bialix: work on it in small chunks..
[14:44] <bialix> that means you have slow progress, correct?
[14:45] <GaryvdM> bialix: slow, but steady
[14:46] <jam>  morning GaryvdM, bialix, and vila
[14:46] <vila> mornign jam
[14:46] <GaryvdM> Hi jam
[14:46] <bialix> heya jam! and bonjour vila!
[14:46] <vila> bialix: privet :)
[14:46] <bialix> :-D
[14:47] <vila> bialix: brasil - netherlands should be a nice one ;-)
[14:47] <GaryvdM> Hey vila
[14:47] <bialix> vila: yep, I've heard comments and prognosis
[14:48] <GaryvdM> jam: lp:~garyvdm/bzr-windows-installers/maybe
[14:48] <GaryvdM> jam: I committed rev 119 with --author "John ... - I hope you don't mind
[14:49] <GaryvdM> jam: Please could you do a quick review of rev 120
[14:49]  * vila feel depressed, 2.1.0 and 2.1.1 have a test failure: bzrlib.tests.test_selftest.TestTestCaseWithMemoryTransport.test_dangling_locks_cause_failures does that ring anyone bell ?
[14:50] <vila> and 2.1.2 too
[14:51] <GaryvdM> jam: I'm now stuck with a can't find zlib.h build error. Maybe I need to adjust so env var.
[14:51] <jam> GaryvdM: well, for 2.2 we shouldn't need it at all
[14:51] <jam> maybe setup.py needs updating?
[14:51] <jam> or something is importing it that shouldn't be
[14:51] <jam> I thought mgz tracked those down
[14:52] <jam> vila: I haven't seen it before
[14:52] <vila> jam: me neither 8-(
[14:52] <vila> add 2.2
[14:52] <GaryvdM> jam: building _chk_map_pyx.c
[14:53] <jam> GaryvdM: other than not needing zlib.h, the original goal was that the build script would download zlib and put it in the path
[14:54] <vila> jam: pass in trunk at least (which kind of rules out a weird setup here)
[14:54] <jam> GaryvdM: so the issue
[14:54] <jam> is again that igc's new code doesn't grab a tag
[14:54] <jam> it grabs the latest in a branch
[14:55] <jam> and lp:bzr/2.2 hasn't been updated
[14:55] <GaryvdM> http://pastebin.org/375070
[14:55] <jam> so it is still trying to build old code
[14:55] <GaryvdM> jam: Ah - let me try build bzr.dev
[14:55] <jam> GaryvdM: _chk_map_pyx.pyx has "cdef extern from 'zlib.h':"
[14:55] <jam> which shouldn't be in 2.2b3
[14:55] <jam> GaryvdM: it looks like we need to do more direct work on ian's code
[14:56] <jam> and possibly get ahold of him to determine what he had in mind
[14:56] <jam> vila: does it fail when tested in isolation (and succeed in bzr.dev in the same case)?
[14:56] <vila> yup: ./bzr selftest -s bzrlib.tests.test_selftest.TestTestCaseWithMemoryTransport.test_dangling_locks_cause_failures --no-plugins
[14:57] <vila> with extensions compiled in all cases (but that shouldn't be relevant)
[15:00] <jam> fails here, too....
[15:00] <jam> makes me think it is a test-tools issue
[15:00] <vila> jam: forget it, sorry for raising it, unless pqm yelles at you , yeah, ne too
[15:01] <jam> vila: len(result.failures) == 1
[15:01] <jam> I have the feeling one testtools considered something a Fail
[15:01] <jam> and one considered it an Error
[15:01] <vila> definitely raises a bell now that you mention it
[15:01] <jam> so I would say the test should become something like
[15:01] <jam> assertEqual(1, len(result.errors) + len(result.failures))
[15:01] <jam> with a big:
[15:02] <jam> # Testtools sometimes considered this an Error, and sometimes a Failure
[15:02] <jam> # so make sure to trap for bothe
[15:02] <jam> vila: I seem to remember being worried that relying on a 3rd party tool for the test suite would cause spurious failures and lock-step versioning issues
[15:02] <vila> I'm pretty sure lifeless did a patch very close to that
[15:03] <jam> total_failures = result.errors + result.failures
[15:03] <jam> if self._lock_check_thorough:
[15:03] <jam>     self.assertLength(1, total_failures)
[15:03] <jam> yep
[15:03] <jam> in bzr.dev
[15:03] <jam> albeit without the snarky comment against testtools
[15:04] <vila> hmm, I think I asked for a comment, whatever the content was :) But fater the landing
[15:04] <vila> after
[15:05] <vila> anyway, we know how to fix it, back to regular schedule
[15:14] <jam> vila: feedback on https://code.launchpad.net/~vila/bzr/525571-minimal-lock-bazaar-conf-files-2.1/+merge/29086
[15:19]  * vila holds his breath...
[15:24] <chaosaddict> anyone know what might cause this error message when doing a bzr fast-import?
[15:24] <chaosaddict> "bzr: ERROR: The file id "TREE_ROOT" is not present in the tree <bzrlib.inventory.CHKInventory object at 0xa2a610c>."
[15:25] <jam> vila: sent to the list
[15:25] <jam> sorry, breathe again
[15:26] <vila> deep shudder
[15:28] <vila> jam: a = AtomicFile() ; a.write(data) ; a.commit() ; a.close() ?
[15:33] <jam> vila: well, a = AtomicFile(filename); but yeah, something like that
[15:33] <jam> IIRC LocalTransport uses AtomicFile for put()
[15:35] <jam> GaryvdM: what else is in the environment that you need to copy? (It seems ok, I just wanted to check)
[15:37] <jam> anyone know if the 2.1.2 installers are looking good? I'm thinking I should extract a nonadmin version
[15:38] <GaryvdM> jam: It was failing like this. http://pastebin.org/371858
[15:39] <GaryvdM> jam: I thought it would be easy to just copy the env rather than play wack-a-mole
[15:40] <GaryvdM> *easier
[15:40] <jam> GaryvdM: so the concern is accidentally having an env var like CFLAGS suddenly change your build (and it starts working/failing surprisingly)
[15:40] <jam> however, I probably agree with you
[15:41] <jam> I'm fine with just copying
[15:41] <jam> given that everything else that builds just uses the existing env vars
[15:41] <jam> we just want to *add* ones for tbzr
[15:41] <GaryvdM> jam: ok
[15:48] <GaryvdM> jam: I think we could maybe extend Project, Plugin, and Application in bazaar_releases.py to include revision specs.
[15:49] <GaryvdM> jam How do we allow for differences in revision specs, with out duplicating all other details?
[15:50] <GaryvdM> jam: Maybe copy and modify?
[15:50] <jam> GaryvdM: what do you mean duplicating all the other details?
[15:51] <jam> Are you thinking to have the same code base do multiple builds?
[15:51] <GaryvdM> jam: Differences in plugin version between distributions
[15:51] <jam> traditionally we just had separate branches for this
[15:51] <jam> afaik that isn't planned
[15:51] <jam> but I could be wrong
[15:51] <jam> I also really don't know the plan for the distribution stuff
[15:52] <jam> Certainly I don't really want to debug why Mac OS X has plugin version x, but windows has version y
[15:52] <GaryvdM> jam: yes, you can currently do ./build.py bzr-dev or ./build.py bzr-2.2 or just ./build.py for both
[15:52] <jam> or even worse, Vista has X, Win7 has Y, and XP has Z
[15:52] <GaryvdM> jam in this context, distribution = bazaar major release series.
[15:53] <GaryvdM> 2.1, 2.2, dev
[15:54] <jam> bad name, then
[15:54] <jam> IMO
[15:58] <GaryvdM> jam: Agree  - lets look a renaming it once we have everything else figured out.
[15:58] <jam> GaryvdM: so for that, I would even expect *what* plugins are bundled to be different
[15:58] <GaryvdM> "Series" ftw
[15:59] <GaryvdM> jam: yes
[15:59] <jam> and I would expect the versions to be different at least 50/50.
[15:59] <jam> since we have started working on stuff like stable qbzr releases, etc
[16:14] <GaryvdM> jam: For me but pdb is unusable with cygwin. I don't see a prompt. The prompt only shows after I've pressed a key. (I see the same thing with bzr uncommit)
[16:15] <GaryvdM> jam: Do you maybe know how to fix this?
[16:15] <jam> GaryvdM: I don't really know, something is weird on that machine
[16:16] <jam> I don't have problems at home
[16:16] <GaryvdM> :-|
[16:23] <vila> jam: fix with AtomicFile pushed
[16:29]  * GaryvdM off to find food. bbl
[16:39] <jam> vila: do you still need the intermediate StringIO, rather than just using AtomicFile as the thing you write to?
[16:46] <vila> jam: no, fixed
[16:46] <jam> vila: approve
[16:46] <vila> jam: thanks
[16:47] <vila> *now* I will have to take care of test failure :-/
[17:06] <GaryvdM> Yhea - I don't get zlib err on bzr-dev.
[17:07] <GaryvdM> I now get this error: http://pastebin.org/375504
[17:08] <GaryvdM> jam: ^ Any ideas?
[17:09] <chaosaddict> I'm new to Bazaar, but it seems like it might be useful to be able to use the Bazaar Explorer to get a file at an arbitrary revision number.
[17:10] <GaryvdM> chosaddict: Like bzr revert foo -r x
[17:10] <GaryvdM> chaosaddict: That was recently added to qlog.
[17:11] <GaryvdM> (Bazaar Explorer uses qlog...)
[17:11] <chaosaddict> oh cool, thanks.
[17:28] <mgz> garyvdm: I think I remember a list message about having to remove the py3k port bits of pyqt
[17:28] <GaryvdM> Hi mgz
[17:29] <mgz> yeah, by jam, so he's probably the right person to ask.
[17:29]  * jam hides
[17:30] <jam> ugh. that terrible stuff
[17:30] <jam> I ran into it, did something which seemed to fix it, it broke again, tried something else, etc, etc.
[17:30] <jam> GaryvdM: we have this: excludes.append('PyQt4.uic.port_v3') in bzr.dev setup.py
[17:31] <jam> which is the only thing that could approximately work
[17:31] <GaryvdM> mgz: I can't find the mail. What is the subject?
[17:31] <jam> but I ran in to all sorts of hell
[17:31] <jam> leaving it out caused one failure, putting it in caused another
[17:31] <GaryvdM> Err
[17:31] <jam> Check the version of PyQt as well
[17:32] <jam> PyQt4.QtCore.qVersion() says 4.6.1
[17:33] <mgz> it's in the middle of Robert's "Python 3" thread, but what jam is saying now will probably help you more
[17:33] <jam> QtCore.PYQT_VERSION_STR says 4.7
[17:33] <jam> so it seems to be PyQt4  (4.7) which wraps Qt 4.6.1
[17:33] <GaryvdM> I think that is the qt version. The pyqt version is 4.7
[17:33] <GaryvdM> Er you faster than me
[17:33] <jam> this was one-of-those-things that made me stick with python2.5
[17:35] <jam> GaryvdM: the easier solution is to delete that directory from PyQt4
[17:35] <jam> note questions like this: http://www.mentby.com/albert-cervera-i-areny/not-packaging-portv3-into-26-installer.html
[17:35] <jam> which are exactly my problem, but no answers
[17:37] <GaryvdM> jam: Please can we try moving the file out. You need to do. (admin)
[17:38] <jam> GaryvdM: sure, I have to relog
[17:38] <jam> though I thought I set the perms to be 'bzr' == Full Control
[17:38] <jam> did you check?
[17:39] <GaryvdM> No - let me try
[17:41] <GaryvdM> jam: Nope - I cant
[17:43] <GaryvdM> jam: We could maybe try exclued PyQt4.uic - let me check I we use it
[17:43] <GaryvdM> *if
[17:44] <jam> GaryvdM: I think we need it
[17:45] <GaryvdM> jam: looking at the code, we only use it as a dev tool, in extras/build_ui.py, in both qbzr and bzr-explorer.
[17:45] <GaryvdM> jam: The results are commited, so it is not even needed at build
[17:46] <mgz> can you exclude build_ui.py from the packaging then?
[17:46] <GaryvdM> Is it even included
[17:47] <jam> GaryvdM: py2exe is bundling it, which is why we are having the failure
[17:52] <jam> GaryvdM: try it now, I edited out the troublesome line
[17:52] <GaryvdM> ok
[17:52] <GaryvdM> jam: In which file?
[17:53] <jam> PyQt4/uic/__init__.py
[17:53] <GaryvdM> ok
[18:03] <cebesius> i think i might have ruined my development branch when i did a bzr pull --overwrite. is there a way to back that out somehow? i tried revert but that didn't seem to have any effect.
[18:03] <GaryvdM> cebesius: Look at bzr heads --all
[18:04] <GaryvdM> cebesius: See if you can find the revision in there.
[18:04] <cebesius> bzr: ERROR: unknown command "heads"
[18:04] <GaryvdM> cebesius: Ah - you need the bzrtools plugin
[18:05] <GaryvdM> cebesius: What os?
[18:05] <cebesius> ok thanks. sorry i apologize for the noobery
[18:05] <cebesius> ubuntu
[18:05] <cebesius>  sudo apt-get install bzrtools ?
[18:05] <GaryvdM> yes
[18:07] <cebesius> i see the branch nick for my development branch. at the end of the HEAD: line, it says (dead)
[18:08] <GaryvdM> cebesius: ok - now you can do bzr pull . -r <revid> --overwrite
[18:09] <GaryvdM> cebesius: You will then have diverged branches, and will need to do a merge in one of them
[18:09] <GaryvdM> cebesius: you can also do bzr merge . -r <revid>
[18:11] <cebesius> GaryvdM: that just took care of it. thanks!
[18:11] <GaryvdM> jam: wack-a-mole time: http://pastebin.org/375740
[18:12] <GaryvdM> cebesius: Glad I could help.
[18:12] <GaryvdM> jam: Don't you want to try give me permission to that dir.
[18:12] <jam> GaryvdM: I think I did
[18:12] <jam> I did try again
[18:13] <GaryvdM> jam: ok - let me try access
[18:13] <jam> so there are other entries according to grep, let me grab them
[18:14] <GaryvdM> jam: I can edit now.
[18:15] <GaryvdM> jam: It's building \o/
[18:16] <jam> k, I hacked out a few more files
[18:16] <jam> Compiler/qtproxies.py, objcreator.py pyuic.py and __init__.py are all touched
[18:17] <GaryvdM> jam: setup.py py2exe succeeded. Now running whole script.
[18:22] <GaryvdM> jam: If I edit something in any of the existing build branches, I get this error: http://pastebin.org/375786
[18:22] <jam> mgz: so what is your thought on the -OO issue with user-installed plugins? Should we just back out the change? Should we just push harder on getting plugins fixed?
[18:22] <jam> GaryvdM: you're not allowed to edit that way
[18:22] <jam> by design
[18:22] <GaryvdM> jam: note that the change I made was in bzr/setup.py, note in qbzr as the error indicates
[18:22] <jam> we want to build from committed code
[18:23] <jam> the qbzr-en.po stuff, I only see when that is actually regenerated
[18:23] <mgz> well, we have to either fix bug 600803 or backout the setup change for the moment
[18:24] <jam> mgz: ugh, timezone issues?
[18:24] <mgz> the bug will want fixing anyway, and it might still be best to backout the installer change for this release
[18:24] <jam> what is your TZ?
[18:24] <mgz> BST currently.
[18:24] <mgz> GMT+1
[18:24] <mgz> but it's when the installer is used that matters I think.
[18:25] <mgz> library.zip isn't affected because though the zip is time shifted, the files inside get their stamps from the zip metadata
[18:25] <GaryvdM> jam: the error also happens if I run build.py installer  (as as appose to bulid.py installer bzr.dev or bulid.py installer bzr-2.2.) But I guess that is something I can look at later...
[18:25] <jam> mgz: it looks like the build host is Pacific Time UTC-7
[18:25] <jam> you know what...
[18:25] <jam> timestamp == Unix seconds from epoch.. Do we adjust for TZ or not
[18:25] <jam> always been a bit wonky on Windows, IIRC
[18:26] <jam> GaryvdM: I thought the qbzr stuff was because we weren't building a snapshot with newly generated .po files, but I could be wrong
[18:26] <mgz> well, currently I wonder if the problem is actually our code or in nsis or whatever we use
[18:26] <jam> mgz: where do you get the magic from? (what bytes)
[18:26] <mgz> inside the pyo files - but it's being compared to the mtime of the py files
[18:26] <GaryvdM> jam: yes - I think the error report incorrectly reports the project.
[18:27] <jam> mgz: sure, but where in the pyo
[18:27] <jam> so I can compare
[18:27] <mgz> look at the first 8 bytes of the pyo files, first four are the magic, next four are little endian int_4 stamp
[18:27] <GaryvdM> maybe I'm wrong
[18:28] <mgz> so, if nsis is packing the files as localtime, and unpacking as localtime, that would break for anyone not in the same timezone as where the installer is created
[18:28] <mgz> either that, or py_compile is borked.
[18:29] <jam> mgz: they match here
[18:29] <jam> os.lstat('commands.py').st_mtime ==<PHONE_NUMBER>.0
[18:30] <mgz> what's your timezone?
[18:30] <jam> struct.unpack('<i', open('commands.pyo', 'rb').read(8)[4]) ==<PHONE_NUMBER>,)
[18:30] <jam> well not that exactly but you get the idea
[18:30] <jam> TZ == UTC-7 I believe
[18:30] <jam> (mine is -5, but build host is on Amazon EC2)
[18:31] <jam> so it could be NSIS
[18:31] <jam> mgz: what platform are you on?
[18:31] <mgz> Xp
[18:32] <jam> you know what, I can just set the TZ for that machine to UTC, who cares, right?
[18:32] <jam> let me try that
[18:32] <GaryvdM> jam: Please let me know when that is done
[18:33] <mgz> worth a go.
[18:33] <jam> GaryvdM: done
[18:33] <GaryvdM> jam thanks
[18:33] <mgz> might not work, but is easy to see if it does.
[18:33] <jam> note, though, that this is on the old-windows-installers stuff
[18:33] <jam> GaryvdM: and I'm being lazy and building as admin, since I don't want to relog
[18:35] <GaryvdM> jam: I don't think that that would affect anything.
[18:36] <GaryvdM> building as admin...
[18:37] <jam> GaryvdM: well, it screws up perms for the rest of us
[18:37] <jam> and is generally something I like to avoid
[18:37] <jam> (consider running make as root)
[18:37] <jam> just a 'hygiene' thing
[18:38] <mgz> okay, bad news, don't think changing builder to gmt will help
[18:38] <mgz> just checked the before and after stamps on 2.2b3 which I just installed (as in, in the summer, not the winter)
[18:38] <mgz> and it's 8 hours out.
[18:41] <jam> mgz: so you're saying that changing *your* timezone affected it?
[18:42] <jam> the build is just about done
[18:45] <mgz> I'm saying when my timezone changed one hour, the difference also changed an hour, which suggests my localtime matters, as well as the build slave's
[18:45] <mgz> ie, it's doing localtime(a)->localtime(b) not localtime(a)->gmt
[18:45] <GaryvdM> bla - wack-a-mole: http://pastebin.org/375882
[18:46] <mgz> hm, so, it's either looking in the wrong place for the c runtime libraries, or they should be being copied there and they aren't
[18:47] <mgz> not sure that's much help to you gary
[18:47] <GaryvdM> http://pastebin.org/375893 - yhea - they are not there
[18:48] <GaryvdM> So close, but yet so far...
[19:11] <GaryvdM> jam: I'm stuck. http://pastebin.org/375882 Any ideas?
[19:19] <jam> GaryvdM: if you look at build.py (or bazaar_releases.py) it mentions looking for where the msvcrt runtime redistributable stuff is
[19:19] <jam> let me check
[19:19] <jam> GaryvdM: DEFAULT_MSVC_REDIST_DIR
[19:20] <jam> I see 3 msvc* dlls there
[19:21] <jam> and build.py has a check if "self.python.find(26)" (which IMO is a bad check), then it tries to copy the msvcr90.dll over
[19:23] <GaryvdM> jam: Ah - there is msvcr90.dll in build-win32\release\bzr
[19:23] <GaryvdM> jam: Ah - there is msvcr90.dll in build-win32\release\bzr-dev\win32_bzr.exe\Microsoft.VC90.CRT
[19:24] <GaryvdM> So it is copying into a subdir
[19:24] <jam> sounds like it might be the wrong place
[19:25] <GaryvdM> ah - see comment in bulid.py line 408
[19:26] <GaryvdM> I'm going to modify that.
[19:33] <GaryvdM> I cant' belive it. It built!!!! \o/ !!!!
[19:39] <GaryvdM> http://dl.dropbox.com/u/4494367/bzr-2.2~bzr.dev~garyvdm-setup.exe
[19:39] <GaryvdM> mgz, jam ^
[19:54] <GaryvdM> Installed. bzr-explorer works, but I got this error: http://imagebin.org/103818
[20:09] <jam> GaryvdM: strange, bundling "" certainly seems wrong :)
[20:09] <GaryvdM> jam: I only get it when tbzr is selected
[20:09] <GaryvdM> jam
[20:10] <GaryvdM> jam: And toverlays is not getting installed.
[20:10] <GaryvdM> So I think thats related
[20:11] <jam> GaryvdM: maybe we are setting the env var incorrectly, or not getting it passed into the right part of the build
[20:11] <jam> you might check the iss file
[20:11] <GaryvdM> jam: I'm also getting a Unable to import library 'launchpadlib' error
[20:12] <jam> GaryvdM: I believe there was a "pipeline depends on launchpadlib so lets back out pipeline" maybe there is another on elike it?
[20:12] <GaryvdM> jam: I'm going to send a mail to the ml, and then go home. I'll try again.
[20:12] <GaryvdM> jam
[20:12] <jam> k
[20:13] <GaryvdM> jam: I'm really happy though that I got it to build. Thanks for all the help.
[20:13] <jam> GaryvdM: isn't it already like 10pm there?
[20:13] <GaryvdM> 9pm - thats still early :-)
[20:13] <GaryvdM> The last 3 nights I was in bed after 1am...
[20:14] <GaryvdM> :-p
[20:15] <GaryvdM> jam: And I need to add the ability to specify a revision spec for everything....
[20:30] <GaryvdM> jam: Thanks alot for all the help.
[20:30] <GaryvdM> Good night all.
[20:30] <jam> night GaryvdM
[20:55] <mgz> thanks for doing all this jam and gone-gary
[20:55] <mgz> I'll give your installers a try here when I cool down a bit.
[21:02] <mgz> http://gwolf.org/blog/debian-its-numbers-seen-keyring-maint <- perl... surely using bzrlib would be easier (if not shorter)
[21:02] <mgz> throwaway scripts are done in what you're familar with I guess
[21:07] <jam> mgz: yeah, you could do a lot with bzrlib and just extract the raw texts in an optimal order
[21:08] <jam> its a fairly sizeable branch
[21:38] <jam> mgz: so I was wrong, it seems to be strictly dependent on the number of files in a given directory., my perl fu is pretty weak, and there is some ... interesting... syntax
[21:49] <GaryvdM> Wow Brazil out...
[21:49] <jam> GaryvdM: unexpected
[21:50] <GaryvdM> Uruguay and Ghana in overtime...
[22:09] <jam> mgz: my version: http://paste.ubuntu.com/458491/
[22:09] <jam> takes about 20s to iterate 540 revs
[22:10] <jam> I could probably do better if I got down into some hardcore details
[22:10] <jam> but my graph looks just like his :)
[23:15] <mgz> ah, much better after bath, still hot though
[23:16] <lifeless> :>
[23:16] <mgz> jam: that's really neat. making a proper commandline tool of it is dedication
[23:17] <lifeless> of what ?
[23:18] <mgz> ah, I linked this earlier: http://gwolf.org/blog/debian-its-numbers-seen-keyring-maint
[23:19] <mgz> and jam answered my "would be better with bzrlib" by... doing a pretty (non-perl) version
[23:20] <mgz> interesting just to see how much of the internals you need to understand to write a short script like that not going through the command line ui
[23:31] <mgz> okay, tested the tz installer, and indeed the bug is still there, the stamp is now an hour out
[23:32] <mgz> I'll try and find some nsis docs I think.
[23:35] <mgz> http://sourceforge.net/tracker/index.php?func=detail&aid=2581469&group_id=22049&atid=373085
[23:35] <mgz> probably that.
[23:36] <lifeless> -lol-
[23:37] <mgz> hey, it tried!
[23:38] <mgz> hm, how did I do that link-to-upstream-bug thing in launchpad before? does it need a launchpad project registered as well as the sourceforge one?
[23:38] <lifeless> 'affects project', paste url.
[23:39] <mgz> ...doesn't seem to like that
[23:51] <mkanat> No subtrees yet, right?


[13:10] <seekr> I am attempting to configure a cloud-based Ubuntu system for web hosting purposes.  I've run into a problem which I think may be related to a bug reported at https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1787886 .  One of the first things I did in configuring the server was to do an upgrade to what I think is the system described in this bug report.  Since I'm unfamiliar with Ubuntu itself, I didn't even know how to determine what LTS
[13:10] <seekr> release I'm running.  Since I see no resolution posted for this bug, it would seem it has not yet been resolved, though the bug report was filed four months ago.  Can anyone help?
[13:13] <ikonia> seekr: what's your actual problem
[13:13] <seekr> ikonia: I'm trying to restore a Joomla!-based site.
[13:14] <seekr> I've installed Apache and MySQL and PHP, all of which are required.
[13:14] <ikonia> right, what's the actual problem
[13:14] <ikonia> yeah, I get how Joomla works
[13:14] <ikonia> what's your actual problem
[13:14] <seekr> The problem is that there's a failure in executing index.php a few lines from the end of that file.
[13:15] <ikonia> ok, what failure
[13:15] <ikonia> what problem
[13:15] <seekr> I put print statements in the index.php file to determine where the failure occurs.
[13:15] <seekr> It's the one described in the bug report.
[13:15] <ikonia> I'm not interested in the bug report
[13:15] <ikonia> I'm interested in the information you can give me
[13:15] <ikonia> what's teh actual problem
[13:15] <seekr> It appears to be failing on the line:   $app = JFactory::getApplication('site');
[13:16] <seekr> That's the actual problem at this point.
[13:16] <ikonia> what does the apache error logs show
[13:16] <seekr> nothing useful - I'll take another look...
[13:16] <ikonia> and when you said you upgraded to 18.04 did you move the site to an 18.04 host, or actually upgrade in situ an 16.04 host
[13:17] <seekr> in situ, afaik
[13:17] <ikonia> what do you mean as far as you know
[13:17] <ikonia> you said "the first thing I did was upgrade" you must know how you did it
[13:17] <seekr> I don't even know what it means to move the site to an 18.04 host.
[13:17] <ikonia> why did you upgrade to 18.04 then ?
[13:17] <ikonia> if you don't know how to upgrade / how to use the upgrade process, why did you upgrade and not just continue on 16.04
[13:17] <seekr> Yes, I followed an instruction that was displayed when I logged in as root.
[13:18] <seekr> I'll see if I can find it.
[13:18] <ikonia> there is an offer to upgrade, not a mandate
[13:18] <ikonia> either way, what does the apache logs show when you try to parse the index.php
[13:19] <seekr> will look
[13:21] <seekr> ikonia: https://termbin.com/g5t0
[13:22] <ikonia> seekr: what log is that ?
[13:22] <seekr> ikonia: error.log
[13:22] <ikonia> seekr: what does the access log show
[13:22] <ikonia> is this the default site or is it a named site
[13:23] <seekr> well, it does have a domain pointing to it, but I'm accessing it via IP address
[13:23] <seekr> It's the site defined by what's in /var/www/html
[13:24] <ikonia> are you using the default site or a name based host
[13:24] <seekr> access log shows nothing interesting - just GETs
[13:24] <seekr> I don't quite know what you mean by "default site"
[13:25] <ikonia> there is a default config for apache or there is a config you can use to build/define a name based host
[13:25] <ikonia> which are you doing, using the default or defining a name based host
[13:26] <seekr> I haven't touched the Apache config file, except to move the PHP thing closer to the front of the line that indicates what file name suffices will be recognised and processed
[13:26] <ikonia> which apache file have you touched
[13:26] <ikonia> what is the name of the file that defines the site you are looking at
[13:27] <seekr> /etc/apache2/apache2.conf, I think it's called.
[13:27] <ikonia> you think ?
[13:27] <ikonia> please be sure
[13:27] <seekr> yes, that's it
[13:28] <ikonia> ok - so are you view the correct access/error logs defined in that file ?
[13:28] <seekr> no - wait - that's not the file - hmmm
[13:30] <seekr> ikonia: I changed /etc/apache2/mods-available/dir.conf
[13:30] <ikonia> why ?
[13:30] <tomreyn> chances are it's a php (5->7) upgrade issues, missing modules or general webapp incompatibility / need for webapp upgrade.
[13:30] <ikonia> tomreyn: yup, php-curl is the likley candidate
[13:30] <seekr> The line I changed now reads:  DirectoryIndex index.php index.html index.cgi index.pl index.xhtml index.htm
[13:31] <ikonia> but based on the total lack of solid information I want to be sure before suggesting package changes
[13:31] <ikonia> seekr: no no, "why" did you change it
[13:31] <tomreyn> ikonia: yes, details are needed.
[13:31] <seekr> I changed it because it appeared that the index.php file was not being recognised and processed - but I could be wrong - I'm a bit fuzzy now on the order of events - but I'm sure that's not where the problem lies
[13:32] <seekr> I just told you why I changed it.
[13:32] <ikonia> seekr: if you're sure that's not where the problem lies, why did you change it
[13:32] <ikonia> you didn't tell me why you changed it
[13:32] <seekr> look - it's easy to change it back to what it was, if only to prove to you that that's not the cause of the problem
[13:32] <ikonia> seekr: I didn't say it was the cause of the problem
[13:33] <seekr> I know you didn't - but this thing is a red herring
[13:33] <ikonia> I'm just trying to understand what you've done and why as you don't seem very clear on a lot of things
[13:33] <seekr> I'm clear that the problem I'm experiencing is the one cited in the bug report!
[13:33] <ikonia> seekr: please don't state that, as it's clear you have no idea what you're doing or you wouldn't have blindly changed a file
[13:33] <ikonia> seekr: right - have you done what the bug report says then ?
[13:33] <ikonia> if it's that clear
[13:33] <seekr> I don't need to deal with this sort of attitude - I'll come back later when things may be different.  Thanks anyway.
[13:34] <seekr> The bug report only talks about adding some modules, and yes, I did follow that advice.
[13:35] <seekr> PHP 7.2 modules
[13:35] <ikonia> seekr: so what modules have you added
[13:35] <ikonia> and how did you add the
[13:35] <ikonia> which ones
[13:35] <ikonia> specifically which modules by which packages
[13:35] <seekr> It really doesn't much matter, since adding those modules made no difference - didn't make the problem either better or worse.
[13:35] <ikonia> it really does matter
[13:35] <ikonia> hence why I'm asking
[13:36] <seekr> It may matter to you, since you seem to be trying to make the point that I'm completely confused.
[13:36] <ikonia> no
[13:36] <ikonia> it matters to fixing the problem
[13:36] <ikonia> hence why I'm asking
[13:36] <seekr> I'm not finding your questioning to be at all helpful.
[13:36] <ikonia> because you don't understand the problem
[13:36] <ikonia> which is fine
[13:36] <ikonia> however, if you give us the info, I'm sure it can be fixed
[13:36] <seekr> My problem, as I originally stated, is what's described in the bug report.
[13:36] <ikonia> which modules did you add via which packages
[13:36] <seekr> I want to know how to find out whether the bug has been fixed, and what I need to do to take advantage of that fix.
[13:37] <ikonia> seekr: right, they are the same symptoms, so lets see what the problem is
[13:37] <ikonia> which packages have you added
[13:37] <ikonia> seekr: we can work that out now
[13:37] <ikonia> it doesn't look like an actual "bug"
[13:37] <ikonia> (if it's the same as that bug report)
[13:37] <seekr> Clearly you are not willing to pursue that line of inquiry, so I don't find your questioning to be helpful.
[13:37] <ikonia> it looks like a difference in how the packages are broken up in php7
[13:37] <ikonia> seekr: I am pursuing it exactly
[13:38] <seekr> I need to know why the statement I showed you, which is the same one shown in the bug report, is failing.
[13:38] <ikonia> right, and I'm trying to explain that to you
[13:38] <ikonia> but I need to know what packages you have so I can understand which ones may be missing and required by your web app
[13:38] <seekr> If you can give me a way to list the installed PHP modules, please do so.
[13:39] <ikonia> seekr: you said you manaully installed some - those are the key ones
[13:39] <ikonia> tell me which ones you installed and how
[13:39] <ikonia> (or the key ones to understanding the delta in that bug report I should say)
[13:39] <seekr> It's not relevant to the problem solution - but if only to satisfy you, I'll find the statement I used.
[13:39] <ikonia> it is relevant
[13:40] <ikonia> it's really important to understand what packages you've added in and how you did it
[13:40] <ikonia> as that bug report is showing that the upgrade process may miss packages due to the way the packges are broke down different in later versions of php
[13:40] <ikonia> seekr: it's clear you're going to fight giving the information so I'll leave you to it
[13:40] <seekr> ikonia: apt-get install -y libapache2-mod-php7.2 php7.2-cli php7.2-common php7.2-mbstring php7.2-gd php7.2-intl php7.2-xml php7.2-mysql php7.2-zip
[13:41] <seekr> That's fine, ikonia - I don't see the logic in your inquiry.
[13:41] <ikonia> no problem then
[13:41] <seekr> The problem was not caused by my installation of modules.
[13:41] <ikonia> no, if you have the same problem as that bug report, it's most likley cause by missing modules
[13:41] <ikonia> that are not installed as part of the 16.04 -> 18.04 upgrade process
[13:42] <ikonia> (if it's the same as that bug report - if it's not it will need to be worked through)
[13:42] <seekr> which is why I asked you how to display what PHP modules are installed - perhaps you don't know
[13:42] <ikonia> seekr: I do know, but what mattered what you manually installed and how as that is the "delta"
[13:42] <seekr> delta between what and what?
[13:42] <ikonia> and that will tell us what maybe missing as part of the upgrade or if it's the same symptom, but a different bug
[13:43] <ikonia> seekr: between would should be installed as part of the upgrade and what changes due to package name/version changes
[13:43] <seekr> We don't have enough info to be able to tell what modules are required - we have only that bug report.
[13:44] <seekr> I need to find some later report that describes the real cause of the problem and how to solve it.
[13:45] <ikonia> seekr: it can be worked out
[13:45] <seekr> how?
[13:45] <ikonia> it's not hard, jamoola is pretty basic
[13:45] <ikonia> by understanding the delta between the old working php packages and the new ones
[13:45] <seekr> It's not about Joomla! per se - it's just that that instruction is failing.
[13:46] <ikonia> hence why I was asking for the info I was asking for
[13:46] <ikonia> seekr: it's about php - and joomla is your example in this case
[13:46] <ikonia> the cause will be different depending on the app and what the app needs
[13:46] <ikonia> so it sort of does matter what your usecase is (joomla in this case)
[13:46] <seekr> I think I'll be better off just searching for later reports, because I think this sort of debugging exceeds the knowledge of either of us.
[13:47] <ikonia> as different web apps will have different dependencies
[13:47] <ikonia> and those packages will differ in name/version in different php versions
[13:47] <ikonia> seekr: doesn't exceed my knowledge
[13:47] <ikonia> but nice try at a sly insult though
[13:47] <seekr> Well, I'm still looking for something genuinely useful from you.
[13:47] <ikonia> all of it was useful
[13:47] <seekr> So far, I've only heard criticism and slurs.
[13:48] <ikonia> you've seen requests for debug information so that I can get to the answer as quick as possible for you
[13:48] <ikonia> but even if what you said where true, it doesn't mean I don't know how to resolve it
[13:48] <seekr> The thing is that neither of us has a way to know what might be missing that's causing that instruction to fail.
[13:49] <ikonia> I'm pretty sure I can figure it out quickly
[13:49] <ikonia> hence why I was asking for some information
[13:49] <ikonia> it's not hard with php - it's just going to be package version/name changes most likley
[13:49] <ikonia> the other thing you'll need to explain to others is if you are using 18.10 or 18.04 as php 7.2 is default in 18.10
[13:50] <ikonia> and you said you where using 7.2
[13:50] <ikonia> not 7.2
[13:50] <ikonia> I'm not %100 sure without looking if that's true of 18.04 which I think was 7
[13:50] <ikonia> (but I'd need to check that)
[13:50] <ikonia> (again this matters due to package names)
[13:50] <seekr> but the information you're asking for doesn't bear on the problem - I installed a few PHP modules, but the fact of their being there didn't help.  The task is to figure out what module(s) might be needed -- IF that's the cause of the problem, which I doubt either of us has any way to say is what's causing the failure.
[13:50] <ikonia> seekr: it does matter to the problem
[13:51] <ikonia> if you assume you don't know how to fix it, and assume I do, I'm telling you it does matter which modules are installed and which ones are missing by default
[13:51] <seekr> Well, tell me what you think you need.
[13:51] <ikonia> rather than argue you it, why not just provide the information to the person trying to help
[13:51] <ikonia> even if you don't understand it, it's a good way to learn
[13:51] <ikonia> (it's fine to not understand it by the way)
[13:52] <seekr> It may well matter, but I don't see how we can figure out what's wrong with respect to missing or incorrect version modules/packages or whatever they're called.
[13:52] <ikonia> I've told you it's pretty straight forward
[13:52] <ikonia> you just need to work the packages through
[13:52] <seekr> I admit my lack of understanding, but I'm not hearing any useful questions from you - only meta-chat criticising my logic.
[13:53] <ikonia> again, if you assume you don't know, and I do, rather than constantly saying "you can't work it out" why don't you work with someone to actually work it out who is saying they can
[13:53] <ikonia> seekr: then read back all the lines I've typed, I've explained multiple times why I'm asking for what I'm asking for
[13:53] <seekr> Give me what you think to be a relevant question!
[13:53] <ikonia> understanding the version of ubuntu, understanding what packges you added and how, knowing the php app (to work out deps)
[13:54] <ikonia> understanding if it was a clean install or an upgrade
[13:54] <seekr> your question??
[13:54] <ikonia> those are all pretty key questions, you can then work out the package deltas
[13:54] <ikonia> I've already asked them
[13:54] <seekr> I need a command to use to determine version, etc.
[13:54] <ikonia> you don't
[13:54] <ikonia> well, hang on
[13:54] <ikonia> versions of what ?
[13:54] <seekr> I'm not a regular Ubuntu user (I use Linux Mint, which is based on Ubuntu, as I'm sure you know).
[13:55] <ikonia> actually, I apologies, I'm taking up your time
[13:55] <ikonia> I'll leave you to it, but that maybe info that helps whomever helps you
[13:55] <ikonia> and it may help you get to the chase quicker
[13:55] <seekr> Well, you are as long as you're give me nothing useful, including useful questions.
[13:55] <ikonia> please try not to argue that it doesn't matter with those trying to help - they are normally asking for good reasons
[13:55] <ikonia> seekr: I've given you multiple useful questions to debug it
[13:55] <ikonia> so that you can get a quick and fatual resoution
[13:56] <seekr> I'm prepared to accept that possibility, but I need a better demonstration than what you've given me thus far.
[13:56] <ikonia> I don't have to demonstrate anything to you
[13:56] <ikonia> I know what I'm doing
[13:56] <ikonia> I've offered help
[13:56] <ikonia> you don't want it (which is fine)
[13:56] <seekr> You've given me nothing useful, I'm afraid.  :(
[13:56] <ikonia> I'm pretty sure I have
[13:56] <seekr> Well, I don't know what it is.
[13:57] <ikonia> but if you can't see the importance of that information, that's fine,
[13:57] <seekr> You're not talking about the actual problem, only trying to convince me of something, and I'm not even sure what it is at this point.  Thanks anyway.
[13:58] <ikonia> I'm talking about the exact problem
[13:58] <ikonia> it can't fully parse the index.php most likely (according to the bug report you posted) due to a missing package
[13:58] <ikonia> hence why I asked for the error log to see if we could get there quicker/easier
[13:58] <ikonia> and a quick search of ubuntu packages (which I did while we where talking) shows multiple package name differences between php versions
[13:58] <ikonia> which backs up the basic principal of the bug report
[13:59] <ikonia> so then it's just the question of which packages you need
[13:59] <ikonia> (as each use case will be different due to different dependencies)
[13:59] <seekr> It's "principle," actually, and as I said, there's nothing interesting in the Apache log file.
[13:59] <ikonia> hence why that bug isn't really a "bug" it's just a difference between PHP versions
[14:00] <ikonia> seekr: nope, fine there is nothing interesting in the logs (hence why I asked you to check it was the right file)
[14:00] <ikonia> it's a hope that you get a clue to short cut debugging
[14:00] <ikonia> don't always get it from the error log (although I'm very surprised you got nothing - I'd check for sure if that is the right log file)
[14:00] <seekr> I looked in both error.log and access.log - which are the only ones being written to, based on their timestamps.
[14:01] <ikonia> that's fine, you don't always get the answer from them, it's just a good tool to check and cut to the chase quicker
[14:01] <seekr> /var/log/apache2/error.log
[14:01] <ikonia> sometimes you'll see something like "could not find libphpbc.so" so you know straight away it's the bc-math package
[14:01] <ikonia> which you can them map to your php version
[14:01] <ikonia> (as an example)
[14:01] <seekr> yes, fine, but that's not the situation here!
[14:02] <ikonia> no, you don't get the output, which is why you need to work out the packages
[14:02] <ikonia> the log file is just a useful short cut
[14:02] <ikonia> again "useful information" and "useful questions"
[14:02] <ikonia> I'll leave you to it, sorry, didn't mean to harp on
[14:03] <seekr> whatever
[14:03] <ikonia> ?
[14:03] <ikonia> look - drop the attitude
[14:03] <ikonia> if you want to use this channel, this attitude can't continue
[14:05] <ikonia> (for the record 18.04 is php 7.2 too - so you're ok on that front)
[19:46] <mybalzitch> is the docker snap considered production ready? I'd imagine so given how hard canonical is pushing snap
[20:04] <ikonia> mybalzitch: I certainly am not confident with it


[03:15] <SpamapS> smoser: http://download.cirros-cloud.net/streams/v1/index.json.gpg <-- whose key is that?
[03:16] <SpamapS> smoser: doesn't mean much to sign things if the public key isn't itself in the web of trust
[03:22] <SpamapS> smoser: anyway, I need to know where I can fetch that key so I can use cirros w/o wondering if I've been MITM'd
[17:09] <harlowja> my guess SpamapS is thats smoser key, but not sure
[17:09] <harlowja> since smoser is mr.cirros
[17:12] <SpamapS> it is not
[17:12] <SpamapS> harlowja: that key is unknown.. not in any key servers.
[17:12] <harlowja> hmmm
[17:12] <harlowja> not my key
[17:12] <SpamapS> Ideally smoser would sign it, and upload the signed public key
[17:12] <harlowja> agreed
[17:13] <SpamapS> Actually ideally several people would sign it, whoever has root on the box that builds those really.
[17:13] <SpamapS> But smoser has enough sigs.. his key is good enough for me. :)
[17:14] <harlowja> :-P


[00:00] <bluesabre> Smaller future diffs that way
[00:05] <ali1234> after the vacuum there are 114 instances of the target colour
[00:06] <ali1234> some files still have multiple copies :(
[00:08] <ali1234> ah, some of this are not the same gradient at all
[00:45] <ali1234> this should be a list of every svg which has a linear gradient with exactly two stops, and both of those stops are #d7e866 or #8cab2a
[00:45] <ali1234> http://paste.ubuntu.com/p/9gqZH9dJ3Z/
[01:32] <bluesabre> All the arrows are there, so that's a good sign
[02:18] <Unit193> bluesabre: https://salsa.debian.org/dbnpolicy/policy/blob/master/policy/upgrading-checklist.rst#version-4-1-4
[07:14] <ochosi> ali1234: have you pushed your vacuumed stuff anywhere?
[07:14] <ochosi> if you want to, i can take a look and review later
[08:11] <jarnos> Hello, how can you change keyboard layout, when booting 18.04 ISO? In 14.04
[08:58] <ali1234> ochosi: pushed to https://github.com/ali1234/elementary-xfce
[08:58] <ali1234> vacuum-defs and export-plain branches
[09:46] <ochosi> ali1234: any recommendations/feedback on the two branches..? shall i just "take a look" to see if i spot diffs? :p
[09:47] <ochosi> also, is it easier with either of the two branches to script the color-change?
[09:47] <ali1234> export-plain cleans out more stuff
[09:48] <ochosi> (without the latter benefit i think i'd postpone the vacuum stuff for post 18.04)
[09:48] <ali1234> it probably isn't any easier
[09:49] <knome> otoh, the package would then be "clean"
[09:57] <ochosi> knome: the package contains only pngs
[09:58] <ochosi> the git repo would be clean/er
[09:58] <ochosi> we convert and optipng everything anyway
[09:58] <ochosi> also because it's way faster than using svg-based themes
[10:00] <ali1234> where's the script to build pngs?
[10:00] <knome> ochosi, right
[10:00] <knome> ochosi, so why wait then?
[10:04] <ali1234> found it
[10:39] <ali1234> both of the branches produce byte-identical png files
[10:40] <ali1234> tested with http://paste.ubuntu.com/p/f2NtDMt6rP/
[10:40] <ali1234> all three directories are identical according to diff -Nur
[10:47] <bluesabre> Neat
[12:53] <flocculant> afternoon
[15:07] <ochosi> ali1234: wanna file a PR on github? i'll go ahead and merge then and then we can continue considering a scripted conversion
[15:07] <ochosi> frankly even just adding the gradient to every file would help because thats otherwise a manual process
[15:07] <ochosi> so that would save me a lot of time
[15:08] <ochosi> and the old gradient would be kicked out by vacuuming anyway
[15:09] <ochosi> knome: i wanted to wait because i didnt want to have to manually check the output after the vacuuming. but if the png output is the same then that's not necessary anyway
[15:45] <willem> hi all, in testcases I'm asked to start "thunar". But in Xubuntu, in the whiskermenu, typing "thu..." thunar does not show up. I got in contact with the whiskermenu maintainer (https://bugzilla.xfce.org/show_bug.cgi?id=14326); he's looked into it, and now thinks it is something that should be reported at Xubuntu. I don't know against which package I need to report this issue; could anyone give me a pointer?
[15:46] <flocculant> that's really a testcase issue
[15:47] <flocculant> well - kind of - the reason you found it is at least, bluesabre ^^
[15:47] <willem> hmm, I don't know: when I open whisker and start typing "fire..."
[15:48] <willem> ... yes, indeed, I found it thanks to a testcas
[15:48] <willem> but thunar should pop up if I start typing its name in whisker I think
[15:48] <flocculant> possibly a .desktop file
[15:49] <willem> I'd be happy to report this on launchpad, but I don't know against which package.
[15:49] <flocculant> we'll let sean see the ping first
[15:53] <willem> let's
[16:09] <ali1234> ochosi:  okay but which?
[16:23] <ali1234> i'm rerunning the vacuum now cos you added stuff...
[16:39] <ochosi> ali1234: if both produce bit-identical png output i'd go with the more stripped down version
[16:39] <ali1234> okay
[16:39] <ochosi> or with whatever elementary use, as its 'proven in use'
[16:39] <ali1234> same
[16:39] <ochosi> thought so
[16:40] <ali1234> i just hope it doesn't re-order all the attribs every time you run it
[16:40] <ali1234> that's possible if it uses unordered dicts
[16:40] <ali1234> or hash tables or whatever
[16:40] <ochosi> i'll add a local pre-commit hook
[16:40] <ochosi> so it'll happen automatically for all new/edited files
[16:42] <ochosi> i'm also considering to add a makefile that runs the svgtopng converter and then installs the icon theme
[16:42] <ochosi> for people who dont use the package or xubuntu as a wholr
[16:53] <ali1234> just going to run export-plain again on the previous output to check it doesn't change anything
[16:53] <ali1234> if it doesn't then i'm happy
[16:54] <ali1234> okay bad news
[16:55] <ali1234> export-plain shuffles the order of attributes every time you run it
[16:55] <ali1234> meaning every time you run it on a file, the entire file changes, even if you didn't change anything at all
[17:00] <ali1234> i will try a newer inkscape
[17:18] <ali1234> getting somewhere
[17:18] <ali1234> inkscape doesn't randomize the attributes, it always reverses their order
[17:19] <ali1234> so running it twice will cancel out the effect :)
[17:22] <flocculant> evening you two
[17:59] <ali1234> okay, megapatch incoming
[17:59] <ali1234> just need to run the png diff one more time
[18:00] <ali1234> passed :)
[18:03] <ali1234> PR sent
[18:37] <pleia2> all the sticker+note letters are ready to be sent out to our wallpaper winners \o/
[18:38] <pleia2> didn't do anything formal, but I did include a quick hand-written thank you
[18:44] <ochosi> ali1234: awesome, thanks! will review/merge later
[18:44] <ochosi> pleia: nice work!
[18:47] <flocculant> pleia2: thanks for doing that stuff
[18:47] <pleia2> np
[18:47] <flocculant> bluesabre: you might want to be aware of bug 1761593
[18:48] <flocculant> can't remember if you commented here about that
[18:48] <flocculant> at the time it would have been against nvidia
[20:26] <Unit193> Thunar was accepted, of course.
[20:28] <ochosi> sweet
[20:28] <ochosi> ali1234: what a homungous commit :p
[20:29] <ali1234> it's 60% smaller than the previous version...
[20:30] <ochosi> hehe
[20:31] <ochosi> you still pushed yourself to #9 of the contributor list with this one commit :D
[20:32] <ochosi> and you have more deleted lines than me now
[20:33] <ochosi> so would you suggest to just run the whole inkscape command twice as pre-commit hook?
[20:33] <ali1234> it's the simplest thing to do
[20:33] <ali1234> the alternative is to use a totally different tool
[20:34] <ali1234> or try to get inkscape fixed
[20:34] <ali1234> since we're working to a deadline i'd say go with the simplest workaround for now
[20:34] <ochosi> sure
[20:34] <ochosi> i mean the pre-commit hook is not *essential* for getting the arrows fixed
[20:35] <ali1234> agreed
[20:35] <ali1234> changing to a different tool could mean another monster commit
[20:35] <ochosi> yeah
[20:35] <ochosi> i would stick to just "doing it twice"
[20:36] <ali1234> it's not that slow unless you are doing the whole file
[20:36] <ali1234> the whole repo i mean
[20:37] <ochosi> yeah
[20:37] <ochosi> i usually change not more than 10 icons per commit
[20:39] <ali1234> ou probably saw i sent an upstream bug report. probably best to just see what they do and copy it :)
[20:40] <ochosi> yup, true that :)
[20:52] <ochosi> knome: i would love for inkscape to throw a readable warning when things like "union" don't work...
[21:07] <ochosi> knome: also, this is a direction that elementary is considering currently (not really decided at all yet though) https://github.com/elementary/icons/blob/26fed9053f2731351f36fa1aebcc7f248012b0a0/places/128/folder-documents.svg
[21:36] <ochosi> ali1234: how do we best continue regarding the scripting? shall i convert a single arrow now manually as a sample so we see if it's doable?
[21:36] <ali1234> that would help actually
[21:36] <ali1234> i'm going to do it partially by hand
[21:42] <ochosi> craaaaap
[21:42] <ochosi> there's more to it than the gradient and stroke :(
[21:42] <ochosi> at least if i wanna do it properly
[21:47] <ochosi> ali1234: https://github.com/shimmerproject/elementary-xfce/commit/960ff154294826a96e3653d8c98fd19ba46b62f4
[21:48] <ochosi> these are the changes that need to be done
[21:49] <ochosi> craaap, should've pulled before i did the changes to clean up the diff
[21:52] <ali1234> well i can substitute all the linear gradients
[21:53] <ali1234> there's a whole new path in there?
[21:54] <ochosi> this is the rebased commit: https://github.com/shimmerproject/elementary-xfce/commit/7ef5bd97c92c7eb2399d1281524c08cc99bec180
[21:54] <ochosi> yeah, there is a "new" path
[21:54] <ochosi> the arrow is one path in the old icon
[21:54] <ochosi> fill + stroke
[21:54] <ochosi> for the new style, they have to be separated into two objects
[21:55] <ali1234> the one i looked at was already two parts
[21:55] <ochosi> so that the stroke can be 50% opacity and overlaying the fill
[21:55] <ali1234> hmm
[21:55] <ochosi> yeah, i just cleaned up the diff a little
[21:55] <ochosi> so it's more readable
[21:55] <ali1234> no i mean yesterday
[21:55] <ochosi> ah
[21:55] <ochosi> hm
[21:55] <ali1234> i'll do all the gradients and then we can look at what's left
[21:55] <ochosi> maybe not all of those arrows are consistnt
[21:55] <ochosi> awesome
[21:55] <ochosi> thanks a bunch for helping on this!
[21:56] <ochosi> gotta get some sleep now...


[22:53] <bazhang> heh 'pick up the slack'
[22:53] <bazhang> that made me think of slackware
[22:54] <bazhang> < chu > step away from the vim, sir
[22:55] <chu> lol
[23:15] <hggdh> so, teenis is back
[23:19] <SonikkuAmerica> Repeat offender?
[23:21] <SonikkuAmerica> Although if anything s/he says is true, s/he either (a) has a ridonkulous amount of RAM or (b) has a partition on which Solaris or illumos or a derivative is installed.


[16:31] <cjdg> hi there, i been testing edubuntu, and wanted to ask if there is possible to add wine as a preinstalled package, also maybe bottles too? here is the thing, is pretty common in schools to use windows based software,
[16:47] <Eickmeyer> cjdg: So, if we were to add wine, it would make the image gigantic beyond 6.0GiB. Bottles isn't in the repos, so that's a no-go.
[16:48] <Eickmeyer> wine is easily installable via the repos. I would have a hard time justifying it to the higher-ups.
[16:50] <Eickmeyer> We are held accountable for the size of the preinstallation .iso image size, and every time it goes above the limit I'm asked two things: either to bring it back down or to have the release team increase the limit.
[16:50] <Eickmeyer> Increasing the limit has risks: 1) people are more reluctant to download due to the size, and 2) the infrastructure becomes more burdened.
[17:25] <cjdg> ohhh
[17:25] <cjdg> i see
[17:25] <cjdg> thanks
[17:27] <cjdg> i was thinking something
[17:27] <cjdg> in countries like mexico, there are places which internet is impossible
[17:28] <cjdg> and most people are non tech
[17:29] <cjdg> can we make a gui like system to make a portable installer, using  apt-cache or similars, and include it to edubuntu?
[17:30] <Eickmeyer> 🤔
[17:31] <Eickmeyer> We have ways of seeding packages for offline installation, but, again, that increases the .iso image size.
[17:32] <Eickmeyer> Anything we include in Edubuntu increases the .iso image size, so it all comes back to the same problem.
[17:32] <cjdg> i mean, not seeding the iso
[17:33] <cjdg> like a gui based tool for filling a folder
[17:33] <cjdg> in a hdd or usb, and move it to
[17:33] <cjdg> where is needed
[17:33] <Eickmeyer> I see what you're saying.
[17:33] <cjdg> i used apt-mirror and similars
[17:34] <cjdg> so making this "portable gui repo maker"
[17:34] <cjdg> for using on edubuntu
[17:34] <cjdg> even maybe available in the live cd,
[17:35] <cjdg> now that ubuntu has raspberry support, is more easy to have the repos for almost any architecture
[17:36] <cjdg> i can try to make it
[17:37] <cjdg> just one question, does there is any gui guideline you would like it will follow?
[17:37] <cjdg> also if you want in any particular programming language..?
[17:38] <Eickmeyer> So, typically GTK is what we'd want to use on GNOME, and I've typically used bash with the frontend being zenity because I'm simple and that's what I know. But if you want to write it in another language, that's up to you.
[17:39] <Eickmeyer> We just don't want to break any policies, that's my only concern here (meaning, packaging policies or others)
[17:39] <Eickmeyer> I can do the packaging if you can write it.
[17:39] <cjdg> ok
[17:40] <cjdg> and here is the important thing
[17:40] <cjdg> how we call it?
[17:40] <Eickmeyer> This is the perfect time to do something since it's the beginning of the cycle. Feature Freeze is end of February.
[17:41] <cjdg> great!
[17:41] <Eickmeyer> local-repo-maker or something to that effect seems reasonable.
[17:44] <cjdg> ok im making the repo on github, which licence would you like it to have?
[17:44] <Eickmeyer> cjdg: One could, in theory, take edubuntu's .iso image and respin it using cubic if they wanted to add wine.
[17:44] <Eickmeyer> cjdg: Something not too permissive but still compatible, such as GPL-3 is fine.
[17:44] <Eickmeyer> Er, GPL-3+ (meaning GPL 3 or later)
[17:45] <cjdg> https://github.com/cjdg/local-repo-maker
[17:45] <Eickmeyer> Cool.
[18:02] <cjdg> have to go man, see  you later, have a nice weekend!
[18:02] <Eickmeyer> cjdg: You too! I'll probably be low on communication this next week as I'm heading to Latvia, but I'll catch you as much as possible.


[00:58] <pvangundy> hello
[00:59] <LaserJock_> hi
[01:00] <pvangundy> can some one give me a name or email address of an individual I can contact in regards to issues with the current Edubuntu kernel?
[01:00] <pvangundy> not so much issues, more limitations
[01:00] <LaserJock_> hmm
[01:00] <LaserJock_> you could email the ubuntu-kernel list maybe
[01:01] <pvangundy> not a bad idea...i just didn't know if the project was forked in a way that each had it's own kernel development
[01:01] <pvangundy> you see, the kernel doesn't have high mem built into the kernel
[01:02] <pvangundy> because it uses the generic kernel it only recognizes up to roughly 3gigs of memory even if you have more installed
[01:02] <LaserJock_> oh, right
[01:02] <pvangundy> This is a very bad thing for individuals running Edubuntu that have servers with more than 3gigs due load/usage
[01:03] <LaserJock_> the -server kernel has higher memory support
[01:03] <pvangundy> correct
[01:03] <pvangundy> i switched the individual to that and they have experienced crashes frequently
[01:03] <pvangundy> we went back to the generic kernel and all is well....very weird
[01:03] <LaserJock_> yeah, so that's just a question of whether Edubuntu should ship -generic or -sever by default
[01:03] <LaserJock_> right, I've been following the thread on that
[01:04] <pvangundy> cool, so it's been talked about
[01:04] <pvangundy> i didn't know that. :)
[01:05] <pvangundy> i was told by this individual that they talked to ogra or sbalneav (don't remember which) recently and they said that the generic kernel has a wider range of support for devices and such
[01:05] <pvangundy> that's why it's in there
[01:05] <pvangundy> if that's the case
[01:06] <pvangundy> compile a kernel based off of the generic kernel (using the .config) and add  high mem support...just an idea
[01:07] <LaserJock_> well
[01:07] <LaserJock_> it's not exactly that easy
[01:08] <pvangundy> why
[01:08] <LaserJock_> well, kernel maintenance is very time consuming and difficult
[01:08] <LaserJock_> if you could convince the Ubuntu kernel maintainers that high mem support should be in -generic then fine
[01:09] <LaserJock_> but I'm thinking they probably don't have it in there for a reason
[01:09] <pvangundy> i know, I compile maintain and compile the kernel where I work. That's why you use the old .config to have the majority of the work done for you then add the support you need. :)
[01:09] <pvangundy> true, and you did answer my question
[01:09] <pvangundy> i should pose this to the kernel developers/maintainers. I just didn't know if they might be in here as well
[01:10] <pvangundy> and i would also think they don't have it in there for a reason and that's why it's not...maybe why we experienced crashes. :)
[01:10] <LaserJock_> yeah, Edubuntu just uses Ubuntu kernels
[01:11] <LaserJock_> what we *can* do, IMO, is have better documentation maybe so people aren't caught off-guard
[01:11] <pvangundy> yup
[01:11] <pvangundy> you can never have too much documentation
[01:15] <pvangundy> well, what I am going to do is compile a vanilla kernel based off of the .config from the generic kernel and add high mem support and see how that goes (since we tried server version and it crashed frequently). I will come back and report at a later date and try to push high mem support through the mainstream kernel Ubuntu releases for Edubuntu
[01:15] <pvangundy> nice chatting
[01:16] <LaserJock_> pvangundy: no problem, and feel free to email edubuntu-devel or ubuntu-kernel
[01:16] <pvangundy> thanks
[01:17] <pvangundy> i'll stay in this channel just in case this spurs a talk later when people on here wake up ;)
[01:17] <LaserJock_> heh, yeah, it's kind of a dead time of day
[01:17] <pvangundy> i see that ;)
[01:18] <LaserJock_> it's also the start of the weekend
[01:18] <pvangundy> yeah, that should tell you something about me :p
[01:38] <sbalneav> Evening all
[01:42] <pvangundy> alright, i'm off
[01:42] <pvangundy> talk to you all later
[10:39] <bluekuja> ogra, around?
[11:11] <high5> Hello, does anybody have any experience with setting the thin clients in the Gutsy release?
[14:05] <Mil> Hola, hola
[14:06] <Mil> alguien que hable español?
[14:06] <Mil> hello
[14:06] <Mil> cant readme
[14:06] <Mil> ?
[14:07] <Mil> Bueno, la cosa es asi
[14:07] <Mil> soy docente
[14:07] <Mil> y quiero que mi live CD de Edubuntu incluya Gambas
[16:46] <ctkroeker> have the ltsp5 packages been updated also for ubuntu and not just edubuntu?
[19:38] <justi1> hello, I'm having trouble setting up dhcp on my edubuntu ltsp server.  I have two NIC's and I want one to listen to dhcp requests for the thin clients and the other to connect to the rest of the network.  I've read that that should be possible, but I can't find detailed instructions on how to do so.  Could any of you point me in the right direction?
[19:44] <nrp> justi1, since 7.04 and possibly earlier, it should set it up automatically during install.  Like, during the install, if it detects two NICs, itll ask which one is the primary one, and use that to connect to the rest of the network.  And then it'll use the other NIC for the dhcp server
[19:48] <justi1> well, I selected the correct primary one, as I am connected to the rest of the network, however, my clients won't boot from the other NIC.  Is there a command or configuration file that I can use to tell for sure that dhcp is or isn't working on the other NIC?
[20:18] <nrp> hmm, well, not sure if dhcpd starts by default, try restarting dhcpd and see if there are any error messages in syslog
[20:27] <justi1> I restarted dhcpd - no errors in syslog and the client won't boot.


[00:33] <yeez> Hello
[00:37] <TheLordOfTime> hi!
[00:41] <yeez> I own an XPS 13 and following a restart, my laptop screen is at minimum brightness. My external LCD (using Mini DisplayPort to HDMI) Works great however.
[00:41] <yeez> Was hoping someone here could help me out. I'm running 13.04
[13:18] <melodie> hi
[13:18] <melodie> I a trying to improve a feh desktop file in Ubuntu Precise in an Openbox environment, and on the way I happen to notice feh won't start
[13:19] <melodie> instead I get:
[13:19] <melodie> "feh WARNING: ./feh.desktop - No Imlib2 loader for that file format
[13:19] <melodie> and several more lines
[13:20] <melodie> feh WARNING: ./lxshortcut.desktop - No Imlib2 loader for that file format
[13:20] <melodie> ...
[13:20] <melodie> googling for the error message led me at Gentoo forums:
[13:20] <melodie> http://forums.gentoo.org/viewtopic-p-4193200.html?sid=1d4f8e381005c64e52072eab4b57cdb9#4193200
[13:21] <melodie> "I noticed the jpeg imlib2 loader was not being built, USE="jpg" emerge imlib2 has fixed it here for me,"
[13:22] <melodie> I want to try to find out with which switches the Ubuntu version of feh which is "Version: 1.4.4-1build1" has been built.
[13:22] <melodie> I noticed that in Archlinux, starting it from the menus or from console both work and start feh with an image in it
[13:22] <melodie> the image is a png image
[13:23] <melodie> how could I find out how it has been compiled ?
[13:26] <melodie> I notice that invoking feh with a direct argument works, but won't start with the "%f" argument in the desktop file, for instance
[13:52] <melodie> hi hggdh_
[13:52] <melodie> :)
[13:52]  * melodie preparing to jump on hggdh_ ^^
[13:53] <melodie> would you have a few minutes available for me ? I have posted about an issue on feh a while ago this afternoon and didn't yet get an answer
[14:05] <hggdh_> good morning/afternoon melodie
[14:05] <melodie> hi hggdh !
[14:05] <hggdh> melodie: reading the backlog now :-)
[14:05] <melodie> ok, thank you
[14:06] <melodie> I'll have something to add after, related to one more test
[14:08] <hggdh> melodie: you can grab the current packaged source for feh via 'bzr branch lp:ubuntu/precise/feh"
[14:08] <hggdh> melodie: just did it, looking at it now
[14:09] <melodie> hggdh I will need to let you look at it. I am finishing a ubuntu openbox mini remix and after I have to go out for the rest of the afternoon
[14:09] <melodie> and also I don't have coding knowlegde... :(
[14:11] <hggdh> melodie: well, the packge does depend on libimlib2, so installing it would also install (if not there yet) libimlib2
[14:12] <melodie> libimlib2 is here. not possible to do otherwise it is a depend for feh, for openbox as well
[14:12] <hggdh> so, probably the issue is with libimlib2, not feh
[14:12] <melodie> this is possible
[14:13] <melodie> what I notice also is this:
[14:13] <melodie> when starting feh from console with an argument : an image file to load, it loads it. then I quit feh, and restart it with no argument, it will load the image loaded just before.
[14:14] <melodie> what would be nice as an expected result would be to be able to start feh from the menus, with no argument at all.
[14:14] <melodie> I don't know if this is possible
[14:14] <melodie> and if it is then possible to load whatever image we would want from there
[14:15] <melodie> going now. :)
[14:15] <melodie> thanks
[14:15] <hggdh> hurmm. imlib2 is also build built with jpeg. Also, based on what you said, you *can* load the image, although kludgly
[14:21] <hggdh> melodie: melodie I will only be able to check on it this evening, only console access now
[14:22] <melodie> hggdh whenever you can; I had loaded a png file, so this might not be representative
[14:25] <melodie> and thank you very much for your time...
[17:01] <evfool> hi all
[17:02] <evfool> any idea who I could bug about an empathy ubuntu online accounts integration bug making impossible to use any other accounts with empathy except gmail and facebook?
[17:02] <evfool> bug 1147639, being 100% reproducible on all 3 of my fresh fully updated raring installs
[17:02] <ubot2> Launchpad bug 1147639 in empathy (Ubuntu) "Cannot add IRC account details" [Low,Confirmed] https://launchpad.net/bugs/1147639
[17:11] <hggdh> evfool: did you check if this is UBuntu-only? It might have already been reported upstream, at bugs.gnome.org
[17:58] <evfool> hggdh: I have been trying to compile the upstream stuff to see if it's also affected, but as the account stuff is coming from Ubuntu online accounts, being different from Gnome online accounts, and raring is at 3.6.4, while upstream is already at 3.8.x it's not too easy
[17:59] <evfool> that's why I'm asking who I can talk with about this topic, I am willing to do any debugging required, to have a complete and fixable bug, as it's really disappointing that I can't use my IM accounts with the latest Ubuntu, and would like to fix it
[18:03] <evfool> hggdh: btw, I have checked the upstream bugzilla, but no sign of the bug there
[18:04] <hggdh> evfool: I would say either #ubuntu-desktop or #ubuntu-unity would be better to find out about this
[18:04] <hggdh> evfool: it may indeed be an unity/Ubuntu thing
[18:06] <evfool> hggdh: thanks, I'll try in ubuntu-desktop
[20:51] <bdmurray> hggdh: did you look into bug 1161073 any further?
[20:51] <ubot2> Launchpad bug 1161073 in coreutils (Ubuntu) "seq puts the separator on wrong spot!" [Low,Confirmed] https://launchpad.net/bugs/1161073
[20:53] <ujee> Hello..  Am I supposed to change a status on a bug from "Fix Released" when there is still a corner case that got looked over?   What shall be the new status (New or Confirmed?)  Bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1162046
[20:53] <ubot2> Launchpad bug 1162046 in xserver-xorg-video-intel (Ubuntu) "[gm45] Xv video falls apart and flickers when obstructed by 2 windows" [Undecided,Fix released]
[20:58] <bdmurray> In the event that is was fixed in a package and contains a changelog entry regarding the fix its best to open a new bug and reference the old one in it.
[20:59] <ujee> Yes, the bug is in a changelog.. Thanks for the quick reply
[20:59] <ujee> *the bug number
[21:04] <ujee> bdmurray, I already attached files documenting the corner case to the old report.  Shall they be duplicated to the old one, or is there a way of referencing them?
[21:04] <ujee> *duplicated to the /new/ one
[21:05] <bdmurray> well, you could add comments to the new one using the same link as in the old one but then they wouldn't be attachments to the new bug report which might be important to someone
[21:07] <bdmurray> so duplicating them seems best
[21:07] <ujee> ok, thanks
[21:12] <hggdh> bdmurray: did not have time, but it is fixed on 8.21. It is now just a question of looking for the specific patch
[21:13] <bdmurray> hggdh: it'd probably be good to get it in R
[21:16] <hggdh> bdmurray: might be commit
[21:17] <hggdh> bdmurray: might be a commit of Sep 21 2012
[21:17] <hggdh> bdmurray: I can check it when I get home
[21:18] <hggdh> bdmurray: it might also be good to get it in Precise
[21:18] <hggdh> but that might be a bit more difficult, a lot of releases in between
[21:18] <bdmurray> well let me know how I can help
[21:20] <hggdh> bdmurray: roj, will do. Hopefully I will be able to extract the patch this evening
[22:13] <hggdh> not good, got a X crash on the nwew kernel


[14:20] <chrisccoulson> hmmm, wth is going on here?
[14:20] <chrisccoulson> client.py keeps failing, yet i can just call hg directly and it works fine :/
[14:20] <chrisccoulson> http://paste.ubuntu.com/806220/
[14:21] <bhearsum> that's because of our hg upgrade last week =\
[14:21] <bhearsum> you're probably getting a different hg when running manually
[14:21] <bhearsum> older versions work properly, newer ones are hosed
[14:22] <bhearsum> if you have ssh access, that will work regardless of the hg version
[14:27] <chrisccoulson> bhearsum, ah, ok. thanks
[14:28] <bhearsum> np, and sorry =(
[15:26] <chrisccoulson> heh: https://twitter.com/#!/bhearsum/status/158929871194693632 ;)
[15:27] <bhearsum> yeah =\
[15:27] <bhearsum> time to get back on the treadmill
[15:27] <chrisccoulson> yeah, i know that feeling
[15:28] <chrisccoulson> and then i had our platform sprint last week too, which always involves overeating and over-consumption of beer ;)
[15:28] <bhearsum> oops ;)
[15:28] <bhearsum> i have a work trip next month in hawaii...unless i manage to sweat off the pounds, that's not going to be helpful either
[15:32] <chrisccoulson> hawaii would be a pretty cool place to go for a work event :)
[15:34] <bhearsum> yeah, i'm not going to complain!
[16:10] <chrisccoulson> hmmmm, precise is way too stable for my liking
[16:10] <chrisccoulson> where's all the breakage?
[16:31] <chrisccoulson> m_conley, do you have any plans for the search bar / quick filter bar? the current layout is a bit strange with tabs-on-top (where the toggle button above the search bar makes the QFB appear below the searchbar)
[16:32] <m_conley> chrisccoulson: we're fiddling with a few ideas, but whether or not they make it into 11 is a bit up in the air
[16:32] <chrisccoulson> ah, ok
[16:35] <chrisccoulson> ooh, i've got monochrome toolbar icons again with tabs-on-top :)
[16:50] <chrisccoulson> m_conley, https://bug665871.bugzilla.mozilla.org/attachment.cgi?id=588897 ;)
[16:52] <m_conley> whoop!
[16:52] <m_conley> chrisccoulson: that's perty
[16:52] <chrisccoulson> m_conley, the icon in the tab looks kinda out-of-place now though
[16:53] <chrisccoulson> but i'm glad i've got these icons back again :)
[16:53] <m_conley> chrisccoulson: how so?  Maybe ping andreasn in #maildev
[16:56] <chrisccoulson> m_conley, oh, it's nothing major. it's just that it's the only coloured item between the toolbar and the window title
[16:56] <m_conley> chrisccoulson: ohhh, I thought by "out of place", you meant alignment
[16:57] <chrisccoulson> m_conley, ah, not that
[16:57] <chrisccoulson> although, i'm just about to file an alignment bug for something else ;)
[16:57] <m_conley> yay!  More boogs!
[17:01] <chrisccoulson> m_conley, mozilla bug 718447 ;)
[17:01] <ubot2> Mozilla bug 718447 in Theme "Folder tree alignment issue when "new message" star is visible" [Normal,New: ] http://bugzilla.mozilla.org/show_bug.cgi?id=718447
[17:02] <chrisccoulson> i generally don't like reporting bugs without a patch, but figuring out styling issues is not something that my brain is programmed to do correctly ;)
[17:03] <m_conley> chrisccoulson: it sure beats *not* reporting the bug. :)
[17:03] <chrisccoulson> heh
[20:06] <chrisccoulson> nice bug report: bug 917317
[20:06] <ubot2> Launchpad bug 917317 in firefox "Your G&%D#@$ useless sh86ware deleted all of my bookmarks and saved passwords!!!!!!!!!! " [Undecided,Invalid] https://launchpad.net/bugs/917317
[20:06] <chrisccoulson> i think he reported that in the wrong bug tracker
[20:06] <chrisccoulson> bhearsum, do you get bugs like that? ;)
[20:07] <bhearsum> we do, but thankfully not in the components i look at :D
[20:08] <chrisccoulson> heh
[20:08] <chrisccoulson> unfortunately, i get to look at all firefox reports in ubuntu
[20:11] <mdeslaur> chrisccoulson: hah! I haven't laughed that hard in a while. :)
[20:11] <chrisccoulson> lol
[20:12] <chrisccoulson> mdeslaur, was it you who reported it? did you set up a fake account? :P
[20:12] <chrisccoulson> how does he know i have lara croft posters????
[20:12] <chrisccoulson> ;)
[20:13] <mdeslaur> chrisccoulson: although I do suspect you have you hands in your pants, it wasn't me, no :)
[20:16] <chrisccoulson> hmmm, i'm not sure whether to undock my laptop and move downstairs for the evening
[20:16] <chrisccoulson> bad things happen when i undock
[20:16] <chrisccoulson> right, here goes
[20:16] <mdeslaur> chrisccoulson: I thought precise was bug-free for you :P
[20:16] <chrisccoulson> lol
[20:17] <chrisccoulson> except for multi-monitor stuff, it's perfect
[20:17] <chrisccoulson> it normally completely locks up when i undock
[20:17] <mdeslaur> chrisccoulson: what about screen locking?
[20:17] <mdeslaur> ah, well, I consider completely locked up to be secure, so that's ok I guess
[20:18] <chrisccoulson> mdeslaur, yeah, screen locking works now we reapplied this patch: https://lists.ubuntu.com/archives/precise-changes/2012-January/007197.html ;)
[20:18] <chrisccoulson> we noticed that seb was hitting that bug at the rally last week
[20:18] <mdeslaur> chrisccoulson: that's what was preventing locking from coming up after suspend?
[20:19] <chrisccoulson> mdeslaur, no, the gamma doesn't get restored correctly
[20:19] <chrisccoulson> (because the VT switch happens during the fade out)
[20:19] <mdeslaur> chrisccoulson: ok, different issue
[20:19] <chrisccoulson> yeah
[20:19] <chrisccoulson> so we were getting blank screens on user switch again
[20:19] <mdeslaur> meh, sucks
[20:19] <chrisccoulson> yup
[20:20] <chrisccoulson> right, i'm going to try undocking for realz this time
[20:22] <chrisccoulson_> that went well