[01:21] <silverarrow> hi margo
[01:22] <margo> hi silverarrow
[01:23] <silverarrow> I am trouble shooting gecko - gnome mplayer issues for powerpc
[01:25] <silverarrow> are you clever with mplayer issues?
[01:26] <silverarrow> margo:  I am getting help from a guy who makes gnome mplayer
[01:26] <silverarrow> but need to retreive some info
[01:27] <silverarrow> so much for margo
[06:04] <silverarrow> after I got the battery indicator working, the screen dormant modes have changed
[10:55] <thomas___> hi, i'm trying to figure out how to maintain keyboard preferences between reboots - any advice? everytime i reboot they get reset, and i have to setup my keyboard preferences again
[11:14] <kanliot> thomas___, what kind of settings?
[11:23] <thomas___> kanliot: i want to set extended gb keyboard, and swap the win key for th e alt key
[11:23] <thomas___> i've found /etc/default/keyboard, but of course, can't do anything with it
[11:24] <kanliot> r u using lxkeymap?
[11:25] <thomas___> yes
[11:27] <kanliot> using 12.04?
[11:27] <thomas___> i think so - how do i find out?
[11:28] <kanliot> !version
[11:29] <thomas___> thanks, and yes 12.04
[11:30] <thomas___> mhh, i've edited /etc/default/keyboard, can i restart the keyboard manager without rebooting?
[11:30] <kanliot> donno
[11:31] <thomas___> rebooting then
[14:15] <Riddhish> My lubuntu installation is stuck at "Install System" since a long time after Downloading packages.. Any possible reasons? Should I turn it off?
[14:20] <holstein> Riddhish: i dont download packages during the install
[14:20] <holstein> Riddhish: that could take a long time, or fail... i would wait as long as you feel you can
[18:08] <wxl> silverarrow: sounds like a bunch of work has recently been completed on the lubuntu 12.10 ppc and many more to come https://lists.launchpad.net/lubuntu-qa/msg01169.html
[18:08] <silverarrow> how great
[18:09] <wxl> now might be a good time to consider joining the testing team
[18:09] <silverarrow> then I don't have to migrate to debian
[18:09] <silverarrow> ;-)
[18:09] <silverarrow> it is?
[18:09] <wxl> sure
[18:09] <silverarrow> I am not the cleverest of testers though,
[18:10] <wxl> let's think about it: you haven't found a solution you're happy with, so you're already thinking about getting rid of what you got
[18:10] <silverarrow> I can install 12.10 at least,
[18:10] <silverarrow> perhaps it is possible to upgrade?
[18:10] <wxl> that being said, continuously testing new upgrades is giong to be easy to do
[18:10] <wxl> (you won't lose anything)
[18:10] <silverarrow> I see
[18:10] <wxl> when you find a problem, you report the bug. try to be as detailed as you can. you don't have to understand everything, just report what you see.
[18:11] <wxl> the important thing is that until 12.10 is officially released, there are daily changes that need testing
[18:11] <silverarrow> is it possible to initate an upgrade from 12.04 to the beta version, or is a new install recommended?
[18:11] <wxl> you don't need to test daily but the more you do the better
[18:11] <wxl> as a general rule i would not plan on having one of these dailies (or even the beta) be your final solution
[18:12] <silverarrow> I see
[18:12] <wxl> but testing on them will ensure that when the release is out, you are close as possible to what you want
[18:12] <wxl> see here https://wiki.ubuntu.com/Lubuntu/Testing
[18:13] <silverarrow> I would need to do a full intall
[18:13] <wxl> that's one of the options
[18:13] <wxl> here are the four testcases for an example http://iso.qa.ubuntu.com/qatracker/milestones/219/builds/22391/testcases
[18:13] <silverarrow> this is a fairly stable situation, where I can work and store my writing on a usb connected hd?
[18:14] <silverarrow> what needs to be stable really is the word processor
[18:14] <wxl> again, i would not expect these to be perfect. sometimes things go very awry. i'd save your writing elsewhere.
[18:14] <silverarrow> it would make the testing much easier
[18:14] <wxl> i've had dailies that really need a lot of work to boot, but usually those sorts of problems are resolved fairly quickly
[18:15] <wxl> in general, you should be good
[18:15] <silverarrow> ok,
[18:15] <silverarrow> should I go for install now then
[18:15] <wxl> as far as i remember i've been running 12.10 since it first came out
[18:15] <wxl> but again, the FORMAL testing procedure is what's giong to matter
[18:15] <wxl> you follow the test cases exactly and report bugs as you see them
[18:16] <wxl> and then do ove
[18:16] <wxl> (do over i mean)
[18:16] <wxl> again and again
[18:16] <silverarrow> I see
[18:16] <wxl> might be good to join the lubuntu-qa mailing list
[18:16] <wxl> basically the more you contribute the better it will be
[18:16] <silverarrow> so lubuntu, then
[18:17] <silverarrow> I was thinking about xubuntu, but happily stick with lubuntu
[18:17] <wxl> also do you know the tracker for gnome-mplayer? i found an x86 bug that they suggested i post upstream
[18:17] <wxl> as i said yesterday it seems that lubuntu has become the sort of de facto ppc build
[18:17] <TheLordOfTime> !info gnome-mplayer
[18:17] <TheLordOfTime> ... oh right no botty :P
[18:17] <wxl> that was unnecessary
[18:18] <TheLordOfTime> wxl:  is the bug in Ubuntu?
[18:18] <wxl> ;)
[18:18] <silverarrow> tracker? I have posted bugs for gnome mplaeyr ppc
[18:18] <TheLordOfTime> wxl:  actually was, needed the source name ;P
[18:18] <wxl> TheLordOfTime: it's in EVERY buntu
[18:18] <TheLordOfTime> wxl:  the bug
[18:18] <TheLordOfTime> has it been REPORTED in ubuntu
[18:18] <wxl> yep
[18:18] <TheLordOfTime> bug number?
[18:18] <wxl> and in the bug report, it was suggested to report it upstream
[18:18] <wxl> one sec
[18:18]  * TheLordOfTime was going to help you "upstream" it
[18:19] <silverarrow> I have been posting back and forth with a KEvin who are involved with gnome mplayer
[18:19] <wxl> !bug 654047
[18:19] <silverarrow> but is sort of came to a hault
[18:19] <wxl> silverarrow: what's your bug number? cuz that's what i was suggesting: moving it upstream. maybe TheLordOfTime could help there, too
[18:21] <TheLordOfTime> depends on the bug :P
[18:21] <wxl> silverarrow: i should add the long and short of the reason why i think you should be a tester is because you are so intent on fixing the problems. that sort of drive and perseverence is the true sign of a good tester. we just need to formalize your contributions.
[18:22] <silverarrow> you have persuaded me, I am downloading
[18:22] <silverarrow> I shall have to be active here on the lubuntu channel a lot then
[18:22] <silverarrow> i will ask and be a  nusanse
[18:22] <TheLordOfTime> you know what
[18:22] <wxl> silverarrow: i would also suggest to help the long term repeated testing that you use zsync. don't worry, you can use it next time.
[18:22] <TheLordOfTime> that bug has not enough information
[18:23] <TheLordOfTime> that's why it was marked incomplete
[18:23] <wxl> it was, because no one had tested with 1.0.6-1, which i did, TheLordOfTime
[18:23] <TheLordOfTime> and you're not the bug reporter?
[18:23] <wxl> seems that the originally reporter neglected his/her own bug
[18:23]  * TheLordOfTime is double checking
[18:23] <wxl> nope
[18:23] <silverarrow> I reported a bug with 1.0.6, but someone marked it a dulpicate of 1.0.5
[18:24]  * wxl is a recent add to lubuntu package team so i get updates of expired bugs and that's how i noticed
[18:24] <wxl> give us the bug number, silverarrow
[18:24] <silverarrow> I had the 1.0.6 packages built in precise 12.04
[18:24] <silverarrow> let me google
[18:25] <silverarrow> download takes 4 hours?
[18:25] <wxl> depends on your connection
[18:25] <wxl> but another way to ensure that it doesn't take long in the future is to use zsync. zsync only downloads the part that's different
[18:25] <silverarrow> I need to get wired
[18:25] <TheLordOfTime> wxl:  did you guys check in quantal?
[18:25] <wxl> so if only 5% of it has changed, you only download 5%
[18:26] <TheLordOfTime> wxl:  for that bug, did you check in Quantal's 1.0.6 package?
[18:26] <wxl> TheLordOfTime: apparently my last note there isn't clear. i tested in 12.10 (quantal) which is where 1.0.6-1 is current. i posted the results.
[18:26] <TheLordOfTime> wxl:  looks like a *different* bug now
[18:27] <TheLordOfTime> if the original bug was fixed in 1.0.6, it shouldn't be upstreamed
[18:27] <TheLordOfTime> if there's a *different* bug, i.e. the one you said...]
[18:27] <TheLordOfTime> that needs its own upstreaming
[18:27] <wxl> hey man, i'm just repeating what was suggested, but yes XD
[18:28] <TheLordOfTime> i'm not going to upstream bug 654047 since that's already "fixed"
[18:28] <TheLordOfTime> if you file another bug i'll help upstream that
[18:28] <TheLordOfTime> but tag it as Quantal
[18:28] <TheLordOfTime> (or use `ubuntu-bug gnome-mplayer` from a quantal system)
[18:29] <silverarrow> https://bugs.launchpad.net/ubuntu/+source/gecko-mediaplayer/+bug/1025815
[18:29] <wxl> sounds good
[18:29] <silverarrow> I shall get better at reporting bugs
[18:29] <wxl> curious question: for people who are trying to use "lts" or for whatever reason are using an old version, will the fix ever trickle down?
[18:29] <TheLordOfTime> wxl:  only if someone submits a patch to fix it
[18:30] <TheLordOfTime> or you could have the package backported
[18:30] <TheLordOfTime> (1.0.6 being backported would allow 1.0.6 to run on Precise, but that's a more tricky process)
[18:30] <wxl> i see
[18:30] <TheLordOfTime> silverarrow:  wxl:  https://wiki.ubuntu.com/Bugs <-- for future
[18:30] <wxl> package management has its pros and cons
[18:33] <TheLordOfTime> it may be ubuntu docs for bugs, but the process is still the same for triaging
[18:34] <TheLordOfTime> silverarrow:  phillw commented on that bug.  i'm not touching it because its still "new"
[18:34] <TheLordOfTime> that, and i'm not sure whether its an FFox or a gecko issue
[18:34] <TheLordOfTime> silverarrow:  if it eventually gets to "confirmed" then i'll consider upstreaming it
[18:34] <TheLordOfTime> i usually don't upstream "new" bugs
[18:34] <TheLordOfTime> (I meaning me personally, not the rest of bugsquad/bugcontrol)
[18:35]  * TheLordOfTime notices PHP is segfaulting for the 89th time this week, gets out the package purger, and preps to downgrade php on his system
[18:35] <TheLordOfTime> ping me if ya need me
[18:37] <silverarrow> I am on the G4 now
[18:37] <TheLordOfTime> so you missed my last few messages?
[18:37] <silverarrow> yes
[18:37] <silverarrow> mozilla got messed up
[18:37] <TheLordOfTime> http://paste.ubuntu.com/1187645/
[18:38] <silverarrow> it`s all rightr
[18:38] <silverarrow> needs more investigation
[18:39] <TheLordOfTime> that's why i'm not going to touch it
[18:39] <silverarrow> however, it is much the same as with 1.0.5 I think
[18:39] <TheLordOfTime> still needs confirmation wherever
[18:39] <TheLordOfTime> by someone else
[18:39] <silverarrow> and I am not the cleverest with these things, but I will happily do what testing I can
[18:39] <TheLordOfTime> not by the OP
[18:39] <TheLordOfTime> :P
[18:40] <wxl> bug 1046479 please confirm TheLordOfTime
[18:40] <silverarrow> is there a torrent for the beta version?
[18:40] <wxl> (since it seems you're on quantal)
[18:40] <silverarrow> 1 hour and 40  minutes
[18:40] <wxl> and if you can confirm, then it's not new, in which case you can move it upstream XD
[18:40] <TheLordOfTime> wxl:  i'm not on quantal
[18:40] <TheLordOfTime> i'm on precise.
[18:40] <TheLordOfTime> i can't run quantal on this machine
[18:40] <wxl> silverarrow: just be patient. as i said before, you can zsync it next time.
[18:40] <TheLordOfTime> not until nvidia releases new drivers
[18:40] <TheLordOfTime> wxl:  i'm just on bugsquad / bugcontrol
[18:40] <wxl> TheLordOfTime: ok, nevermind then
[18:40] <TheLordOfTime> part of bugsquad is to help triaging :P
[18:41] <TheLordOfTime> whether that triaging happens upstream or in ubuntu only... :P
[18:41] <TheLordOfTime> ... okay, i'm sufficiently annoyed at PHP now
[18:41]  * TheLordOfTime walks off to rant a bit
[18:42] <silverarrow> I am not complaining about gnome mplayer in its self though
[18:42] <silverarrow> well some issues
[18:48] <silverarrow> wxl, could you link to be beta 1 DOWNLOADS again ?
[18:48] <silverarrow> oh sorry
[18:48] <wxl> silverarrow: you found?
[18:48] <silverarrow> I am googeling and loads of quantal hits, but not the downloads
[18:50] <wxl> http://iso.qa.ubuntu.com/qatracker/milestones/232/builds/22556/downloads though i'd suggest zsync
[18:50] <silverarrow> thanks
[18:50] <silverarrow> I switched comptuers and sort of lost my way
[18:51] <silverarrow> what is rsync and zsync?
[18:51] <TheLordOfTime> !rsync
[18:51] <TheLordOfTime> !zsync
[18:51] <TheLordOfTime> factoids ftw
[18:52] <wxl> hah
[18:52] <wxl> as i said before, with zsync, the first time you download 100% the second time you download only the part that changed. if only 1% changes, you only download 1%
[18:52] <silverarrow> oh clever
[18:52] <wxl> this is the tester's best friend
[18:54] <silverarrow> I didn`t get it the first tome
[18:54] <silverarrow> time*
[18:55] <silverarrow> download is speeding up
[18:56] <silverarrow> 20 minutes
[19:35] <silverarrow> back
[19:35] <silverarrow> cd is burned
[19:36] <silverarrow> It is always a nervous moment intalling os
[19:36] <silverarrow> :-|
[19:37] <silverarrow> wxl is the blacklist 42b thing fixed?
[19:37] <silverarrow> for the initial bootup?
[19:37] <silverarrow> do I get wireless on first bootup?
[19:37] <silverarrow> major hassle ;-)
[19:39] <silverarrow> wxl, firt bootup is crucial
[19:44] <silverarrow> now for install
[19:46] <wxl> silverarrow: don't know!
[19:46] <silverarrow> b4something is not fixed for boot up?!
[19:46] <silverarrow> why not
[19:46] <silverarrow> darn
[19:46] <silverarrow> I have to look it up again
[19:46] <wxl> i haven't open up the ppc in a long time
[19:46] <wxl> i usually just hardwire
[19:47] <silverarrow> oh, it is fixed
[19:47] <wxl> it is?
[19:47] <wxl> oh SWEET
[19:47] <silverarrow> yes, cd has booted, and I get desktop image
[19:47] <silverarrow> yeah great
[19:48] <silverarrow> however, desktop image is very coars
[19:48] <silverarrow> odd
[19:48] <silverarrow> I can't live with it
[19:48] <wxl> remember you can send screenshots and file bugs while live
[19:48] <silverarrow> unless its suppose to be liket hat
[19:48] <wxl> assume anything that looks wrong is probably a bug
[19:49] <wxl> at worst they'll make yuor bugs as invalid because they're not bugs which is not a problem
[19:49] <silverarrow> some things are fixed at first bootup though
[19:50] <silverarrow> the gui installer is haulting
[19:50] <silverarrow> I don't get the widow to show properly
[19:50] <silverarrow> what is b43 cutter?
[19:51] <silverarrow> what would first bug report be then "fix the installer" ?
[19:52] <silverarrow> Installer is frozen though
[20:12] <silverarrow> hi
[20:20] <silverarrow> third try and no success
[20:21] <silverarrow> I did the md5 sum check
[20:21] <kanliot> ubiquity?
[20:21] <kanliot> 12.10?
[20:21] <silverarrow> what, ubiquity?
[20:21] <kanliot> that's the name of the software installer of the graphical installer
[20:22] <silverarrow> I get as far as booting, desktop image is a bit coarsed pixeled and installer do not work
[20:22] <silverarrow> i suppose it is a bug
[20:22] <kanliot> 12.04?
[20:22] <silverarrow> 12.10 beta
[20:22] <kanliot> yeah
[20:22] <silverarrow> I am on ppc G4
[20:23] <silverarrow> something with ubiquity then
[20:23] <kanliot> well someone just told me 12.10 beta was a bad build, because ubiquity doesn't support any extended partitions (which is nearly alll pcs IMHO)
[20:23] <kanliot> so it's crashy trashy
[20:23] <silverarrow> there are issues with 12.04 too, but they are different
[20:24] <silverarrow> can't be entirely bad
[20:24] <silverarrow> has to be fixed though
[20:25] <silverarrow> wonder how I can report it in a simple way
[21:01] <theteju> hey silverarrow
[21:01] <theteju> are you there?
[21:03] <silverarrow> hi
[21:03] <silverarrow> hi
[21:03] <theteju> sorry,, never realized my user name
[21:03] <silverarrow> :-)
[21:03] <theteju> finally i could not solve the flash issue on google chrome
[21:03] <theteju> so i did again , fresh install
[21:04] <silverarrow> it helped?
[21:04] <theteju> now, I forgot the browser you recommended
[21:04] <silverarrow> well, I recommended midori
[21:04] <silverarrow> which worked fine until recently
[21:04] <theteju> NO re install did not help
[21:04] <theteju> ok, is there any ppa for midori?
[21:04] <silverarrow> it still works fine with most sites and youtube, but it crashes on some sites
[21:05] <silverarrow> yes, just type midori in package manager
[21:05] <silverarrow> or sudo apt-get install midori perhaps
[21:06] <theteju> i finally went with minitube ,, works good
[21:06] <theteju> for youtube.
[21:08] <theteju> is there anything else do you think light weight and worth installing?
[21:12] <silverarrow> well,  regular adobe should work
[21:12] <silverarrow> but it's not lightweigt
[21:13] <silverarrow> if minitube works it is great
[21:15] <theteju> so , that means,, my cpu is powerful enough to play with it
[21:15] <theteju> i think something wrong with default chromium
[21:15] <theteju> it simply S***s
[21:17] <kanliot> firefox
[21:18] <kanliot> xxxterm if you really have no ram
[21:18] <wxl> w3m ftw
[21:18] <wxl> XD
[21:18] <theteju> i got 1 gb ram and 2 gb swap
[21:18] <theteju> i dont think 1 gb ever gets used fully
[21:19] <theteju> so,, system is powerful enough for Lubuntu
[21:19] <kanliot> hey wxl, have you noticed that update-manager never runs anymore?
[21:20] <theteju> also,, to point out,, lubuntu software center does not work out of the box
[21:20] <kanliot> what's the error.  i've read some of the LSC bugs
[21:20] <theteju> i add to add ppa for lubuntu-desktop for it to work
[21:20] <kanliot> using 11.10?
[21:20] <wxl> kanliot: no, i don't really bother with it
[21:21] <theteju> 12.04
[21:21] <kanliot> weird
[21:21] <kanliot> if you can reproduce the bug i'd be interested
[21:21] <wxl> kanliot: i mean honestly it pops up every now and then but i ignore it
[21:21] <wxl> i am one of those "only use apt" kind of guys
[21:22] <wxl> but
[21:22] <silverarrow> wxl, harly ever going to test for quantal
[21:22] <wxl> i'd be happy to try to reproduce if you give me a bug number
[21:22] <wxl> currently on 12.10 but if you give me a while i could set up another vbox for 12.04
[21:22] <wxl> or whip out the netbook
[21:22] <kanliot> ahh you're too nice
[21:23] <wxl> silverarrow: not sure i grok your meaning
[21:23] <silverarrow> well, i cannot install
[21:23] <silverarrow> or get online
[21:23] <kanliot> but no thanks i'll figure it out
[21:23] <kanliot> anyone here running 12.04?
[21:23] <silverarrow> ubiquity doesn''t launch properly on ibook G4
[21:23] <wxl> silverarrow: then keep trying. meanwhile join lubuntu-qa and post a message to the mailing list about it
[21:24] <silverarrow> kanliot, yes?
[21:24] <wxl> however, you can do the live testcase, silverarrow
[21:24] <wxl> kanliot: the netbook ain't far
[21:24] <silverarrow> wxl, I struggle as a total newbie
[21:24] <kanliot> silverarrow, when was the last time update manager opened on your desktop, to advise to install software
[21:25] <kanliot> ?
[21:25] <silverarrow> i get all kinds of simple basic fillin questions wrong lol
[21:25] <silverarrow> a few days ago?
[21:26] <kanliot> ahh i'll report it to the lubuntu-qa mailing list.  see if someone can test it
[21:26] <wxl> you can do this test silverarrow http://testcases.qa.ubuntu.com/Install/DesktopLiveSession
[21:26] <wxl> kanliot: have you already reported a bug?
[21:26] <theteju> kanliot : update manager never comes up. just to let you know.
[21:26] <kanliot> he already tried the testing tracker and had problems with it.  (not a surprise, IMHO)
[21:27] <theteju> i installed twice lubuntu 12.04 in last week
[21:27] <kanliot> how the hell do i reproduce the bug?
[21:27] <silverarrow> wxl, very basic, how do I maneuver the ubuntu test pages, the bug numbers and fails and passes?
[21:27] <kanliot> run your machine for a week, see if update manager doesn't come up?
[21:27] <theteju> never seen update manager prompt
[21:27] <kanliot> fine i'll file it
[21:27] <kanliot> hold on
[21:28] <silverarrow> wxl, I would like to report the installer bug for powerpc though, possible G4 spesific
[21:28] <wxl> kanliot: i did have it come up yesterday
[21:28] <wxl> maybe there are no updates?
[21:28] <silverarrow> 12.04 installer was better, even with bugs
[21:28] <wxl> if there's a bug in update-manager (not in apt), wouldn't apt-get update come up with something where update-manager did not?
[21:29] <silverarrow> wxl, you mean synaptic?
[21:29] <silverarrow> let me check
[21:30] <wxl> silverarrow: i was more talking about kanliot's bug
[21:30] <wxl> silverarrow: anywho, go to iso.qa.ubuntu.com and login using your launchpad credentials.
[21:30] <wxl> from there click on the release version that corresponds to what you have
[21:31] <silverarrow> no updates
[21:31] <wxl> make sure you're using the right version (on the far right)
[21:31] <silverarrow> oh,
[21:31] <silverarrow> ....
[21:32] <silverarrow> this is heavy work
[21:32] <kanliot> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1046563
[21:32] <silverarrow> thinking a new thought
[21:33] <silverarrow> I do get regular "udpates available" popups
[21:33] <silverarrow> synaptic launches its' sel
[21:35] <theteju> midori crashes a lot bro
[21:37]  * kanliot doesn't know any gnome project that doesn't crash horribly
[21:38] <silverarrow> theteju: unfortunately
[21:38] <kanliot> besides, how could you not use firefox?
[21:38] <silverarrow> theteju the first weeks I had it it behaved perfectly
[21:39] <silverarrow> I think it behaves better on ppc than regular pc
[21:40] <wxl> silverarrow: you might also join #ubuntu-testing and see if they can offer any advice on what to do with that ubiquity bug
[21:40] <wxl> kanliot: booting netbook now XD
[21:41] <silverarrow> theteju: unfortunately flash video replacer seems to be gone
[21:41] <silverarrow> it was great for low specs and lubuntu
[21:41] <kanliot> wxl you might have to upgrade the netbook to 12.04.1 then test
[21:41] <wxl> wtf is 12.04.1
[21:42] <kanliot> point release
[21:42] <silverarrow> f involved?
[21:42] <kanliot> maybe that's what i did wrong
[21:42] <kanliot> maybe i wasn't supposed to upgrade
[21:43] <wxl> how did you do that? through what tool?
[21:43] <wxl> update manager just popped up for me
[21:43] <silverarrow> very advance
[21:43] <kanliot> hmmm i'm not 100% sure
[21:43] <kanliot> i have 2 machines, i upgraded 1 though apt-get something, 2nd machine i used update manager
[21:44] <kanliot> does your netbook say anything about upgrade?
[21:44] <kanliot> your netbook's update manager?
[21:44] <wxl> there's some security updates
[21:44] <kanliot> no upgrade huh?
[21:44] <wxl> nope
[21:45] <wxl> what's lsb_release -a give you?
[21:45] <silverarrow> theteju:  there is an issue with adobe flash player making midori crash, and there is a fix for it
[21:45] <kanliot> ubuntu 12.04.1 LTS
[21:45] <wxl> interesting
[21:46] <wxl> do-release-upgrade is how you update in command line
[21:46] <wxl> so it's doubeful you did that
[21:46] <wxl> interesting i have 12.04.1 lts too
[21:46] <wxl> oooh wow i'm LTS now
[21:46] <kanliot> lol
[21:46]  * wxl gives a big woop
[21:47] <kanliot> well you're less confused than me
[21:47] <kanliot> so you doing ok
[21:47] <wxl> i am? XD
[21:47] <kanliot> whats' the cron directory?
[21:47] <kanliot> just askin
[21:47] <wxl> it's interesting that the description is 12.04.1 but the release is 12.04
[21:48] <kanliot> yeah same here
[21:48] <wxl> default for cron is /var/spool/cron/crontabs
[21:48] <wxl> crontab -e to edit tho
[21:49] <kanliot> run this: /etc/cron.daily/update-notifier-common
[21:49] <kanliot> its a script
[21:49] <wxl> lemme finish these updates
[21:49] <wxl> man they're going insanely slow
[21:50] <wxl> wrong wifi network
[21:51] <JoaoVitor> Hello, I'm having a problem. Can you help me?
[21:51] <wxl> ooh my turn
[21:51] <wxl> !ask
[21:53] <JoaoVitor> All distro Ubuntu and derivatives (xubuntu, Lubuntu etc) are crash my netbook when in battery usage. And I have to push the reset button
[21:54] <Dice-Man> hello people
[21:54] <silverarrow> JoaoVitor: bad battery?
[21:54] <wxl> JoaoVitor: so if you are using ac, there's no problem. the second you remove it and it runs on battery, it freezes? what exactly happens?
[21:54] <Dice-Man> i've a windows machine where i've put a tightvnc server on it
[21:55] <Dice-Man> i'm entering the right stuff in vinagre
[21:55] <kanliot> JoaoVitor, might be a question for the hardware people on the forum
[21:55] <Dice-Man> but i don't have any connections :(
[21:55] <JoaoVitor> silverarrow:not. the slackware for example, typically run
[21:56] <gomiboy> Dice-Man: windows firewall is down?
[21:56] <kanliot> JoaoVitor, might be kernel versions
[21:57] <JoaoVitor> wxl:lock when the netbook is on battery usage, unplugged. It simply freezes the screen
[21:57] <wxl> JoaoVitor: yeah, that sounds like a problem with the battery or the kernel. which netbook?
[21:57] <JoaoVitor> kanliot:I'm using kernel 3.2.0-29
[21:58] <wxl> JoaoVitor: what kernel in slackware?
[21:59] <wxl> kanliot: /etc/cron.daily/update-notifier-common does nothing. but apt-get update && upgrade does indeed pull up some upgrades that need to happen.
[22:00] <JoaoVitor> wxl:slack 3.2.28
[22:00] <JoaoVitor> i think
[22:02] <wxl> JoaoVitor: 3.2.0-29 ≠ 3.2.28. use the same kernel and see what happens.
[22:03] <silverarrow> JoaoVitor: I have had lubuntu on a few laptops and never had the power issue you are experiencing
[22:03] <silverarrow> odd though
[22:04] <kanliot> bah it's just a guess
[22:04] <JoaoVitor> wxl:I'll try. Thanks for the help.
[22:04] <kanliot> i'd use slackware
[22:04] <silverarrow> yeah, whatever ever works
[22:04] <silverarrow> though it sould be fixed in lubuntu !!
[22:04] <silverarrow> should*
[22:05] <Dice-Man> gomiboy: i'm using comodo firewall
[22:05] <wxl> kanliot: also running update-manager pulls up available updates.
[22:05] <Dice-Man> but no it isn't
[22:05] <wxl> JoaoVitor: i should add i had that problem once, too. bad battery.
[22:05] <silverarrow> JoaoVitor: you might post on the Ubuntu forum, perhaps a clever guy will read it
[22:06] <silverarrow> i have problems with flickering screen
[22:06] <silverarrow> on my hp computer
[22:06] <Dice-Man> gomiboy: i'm using remmina client on lubuntu
[22:06] <silverarrow> what could it be?
[22:06] <Dice-Man> gomiboy: it's a tightvnc connection what to put in the username field ?
[22:06] <Dice-Man> tightvnc doesn't require a username
[22:06] <Dice-Man> that's odd
[22:08] <wxl> kanliot: consider yourself confirmed
[22:09] <kanliot> ok thx wxl
[22:10] <gomiboy> Dice-Man: reading tightvnc documentation here: http://www.tightvnc.com/winst.php : "Until a password is set, TightVNC will not accept incoming network connections."
[22:10] <kanliot> oh btw silverarrow, they said bet1 ppc is broken, but fixes will be landing soon
[22:10] <kanliot> on the lubuntu-qa mailing list
[22:12] <wxl> silverarrow: problem seems to lie in bug 1041625
[22:12] <kanliot> wxl i thought that was the bug on the alternate cd?
[22:12] <kanliot> so many bugs so little communication
[22:13] <wxl> InstallationMedia: Lubuntu 12.10 "Quantal Quetzal" - Alpha i386 (20120724.2)
[22:13] <kanliot> yeah i386
[22:13] <kanliot> thats not ppc is it?
[22:13] <wxl> that's not
[22:13] <wxl> and it's not alternate either
[22:14] <kanliot> lol sourcepackage: ubiquity
[22:14] <wxl> but this is both https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-openchrome/+bug/1041625/comments/34
[22:15] <kanliot> man please tell me i'm not the only one who has to play a guessing games when qa sends out these emails
[22:15] <wxl> nope
[22:15] <wxl> you're not
[22:15] <kanliot> i just talked to phillw
[22:15] <kanliot> he said he was in waist deep
[22:15] <kanliot> in muck
[22:15] <wxl> heheh
[22:16] <kanliot> he had to ask for respins
[22:16] <kanliot> a bug not listed hold on
[22:16] <kanliot> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1046175
[22:17] <silverarrow> yeah, in powerpc ubuquity doesn't even launch
[22:17] <kanliot> so basically, any pc with extended paritionss or soemthing, wouldn't install, or something, maybe automatic worked i guess
[22:17] <kanliot> something
[22:17] <silverarrow> wonder if it is a connected bug?
[22:17] <silverarrow> probably not though
[22:17] <kanliot> bye
[22:18] <kanliot> wxl if you have another few minutes
[22:18] <kanliot> https://bugs.launchpad.net/ubuntu/+source/lxkeymap/+bug/1026510
[22:18] <kanliot> this seems like an actual bug in 12.04
[22:18] <kanliot> actually i could test it myself
[22:18] <kanliot> dont really need u
[22:19] <silverarrow> I wasn't affected by teh keymap bug
[22:19] <wxl> i thought we already had that one somewhere
[22:19] <kanliot> what keyboard do you use silverarrow
[22:19] <silverarrow> no idea, ibook stuff
[22:19] <kanliot> yeah it was in hardy  i think can't remember
[22:20] <silverarrow> powerpc seems to have bugnumbers multiplied
[22:20] <wxl> so do you need me to double check this, kanliot ?
[22:21]  * wxl doesn't think openchrome applies to ppc but we'll see
[22:21] <silverarrow> i still can't manage to report ubiquity bug !"#¤
[22:21] <kanliot> i'll ask you to triple check it
[22:21] <kanliot> pleasee wait wxl
[22:22] <wxl> silverarrow: there are two options. one, you could hardwire your machine, try hitting ctrl-alt-f1 and run ubuntu-bug ubiquity or two, you could just go to launchpad and report a new bug and fill in the info about it.
[22:22] <wxl> there's also a third option
[22:23] <kanliot> The ones that need testing are date stamped 20120905 (It does not affect Alternate etc).
[22:23] <kanliot> @ PPC users, I've had a good long chat with cjwatson and he asks that you re-test the ppc isos, a lot of work has been done.
[22:23] <kanliot> silverarrow if you have time you can doubletest the new ppc iso that just dropped
[22:23] <silverarrow> but I just downloaded less than two hours ago
[22:24] <kanliot> wxl please tripletest the lxkeymap bug
[22:24] <kanliot> silverarrow, seriously i think there's a new build
[22:24] <kanliot> if you like, use zsync
[22:24] <wxl> yeah zsync
[22:24] <silverarrow> kanliot, can you sort of slip the info to him, that G4 users have trouble launching insaller?
[22:24] <kanliot> i can
[22:24] <wxl> also this may be useful, silverarrow https://help.ubuntu.com/community/ReportingBugs#Filing_bugs_when_off-line
[22:24] <silverarrow> iBook g4,
[22:24] <kanliot> but can you retest with the build in the past hour or so?
[22:25] <silverarrow> I can
[22:25] <kanliot> cool
[22:25] <silverarrow> and I need to buy a rack of CDs
[22:25] <kanliot> :(
[22:25] <silverarrow> I have four left
[22:25] <silverarrow> which should see me through to tomorrow
[22:26] <kanliot> :)
[22:26] <silverarrow> kanliot, same download site?
[22:26] <silverarrow> ooh, this is exiting
[22:26] <wxl> you should try cd-rws
[22:27] <kanliot> hold on
[22:28] <kanliot> http://iso.qa.ubuntu.com/qatracker/milestones/232/builds/22623/downloads
[22:28] <kanliot> i think that's the right one
[22:28] <kanliot> actually they said 20120905 in the email, i think they meant to say 20120905.1
[22:28] <kanliot> more confusion
[22:30] <silverarrow> downloading
[22:32] <wxl> confirmed
[22:33] <kanliot> yeah\
[22:34] <kanliot> wxl i've done that
[22:35] <kanliot> oopps replying to a convo about an hour ago
[22:35] <kanliot> sorry
[22:35] <wxl> hahahahah
[22:35] <wxl> XD
[22:35] <wxl>  /lastlog 1434
[22:35] <wxl> XD
[22:37] <silverarrow> who is the clever guy working with the ppc iso?
[22:37] <wxl> you mean the guy trying to fix it?
[22:37] <silverarrow> yes
[22:37] <silverarrow> i hope he isn't all alone though
[22:38] <wxl> not sure really
[22:38] <silverarrow> my mom just bought a new laptop
[22:38] <silverarrow> a hp
[22:38] <silverarrow> slim and very wide screen
[22:38] <silverarrow> about 2 kg
[22:38] <silverarrow> I was going to get her a ultrabook
[22:38] <kanliot> http://pastebin.com/qN8HXpX1
[22:38] <silverarrow> like samsung 9 series
[22:38] <silverarrow> but she was out on her own
[22:39] <kanliot> sorry that's some random convo with the ppc guy
[22:39] <silverarrow> she bought it today, looks nice
[22:39] <Unit193> May want to join offtopic and talk there if it isn't support related.
[23:40] <silverarrow> hi again


[05:53] <setuid> If I use 'openstack-install' on 14.04, and it installs all of the nodes using juju except the broken keystone node, why does 'juju status' in another session to the same host, not show all of the nodes currently deployed?
[05:54] <setuid> Is there a way to tell juju to use the specific config that openstack-install uses in ~/.cloud-installer/juju/local/, vs. the 'normal' config that would go in ~/.juju/ ?
[07:08] <kjackal> Good morning juju world!
[08:22] <hoenir> someone has some good documentation on how to bootstrap on manual provider mode?(i'm interested in juju2.0)
[12:52] <kjackal> kwmonroe: Good morning! I have some good news for bigtop Zeppelin
[13:33] <ryebot> is there some way to disable the juju login timeout or login without using the interactive prompt? (juju2)
[13:57] <Prabakaran> Hello Team, I am facing the scenario wherein I will have to create a database for my product installation in the remote container/machine and for this I am using Mysql charm and in my host I have installed mysql-client in order to create a database and run some sql commands.
[13:57] <Prabakaran> To test this functionality, I have installed mysql charm in the container 1 and installed mysql-client in an another container 2. I ran the command “mysql -h <IP_ADDRESS> -u root -pedba1124-c825-4a8a-9ca9-b3caea9789cd” and getting an error stating “ERROR 1130 (HY000): Host '<IP_ADDRESS>' is not allowed to connect to this MySQL server”
[13:57] <Prabakaran> And I was trying to trace this issue and found out an actual cause by running this command  SELECT host FROM mysql.user WHERE User = 'root';  As per this command there is no % symbol to allow remote unit to execute mysql commands.  Kindly advise me on how to use mysql-client for mysql charm.
[14:10] <Prabakaran> Could somebody help me on this?
[14:16] <babbageclunk> Prabakaran: So you installed mysql-client on another machine using apt?
[14:16] <babbageclunk> Prabakaran: Is that machine managed by juju?
[14:21] <babbageclunk> Prabakaran: If so, I think you could deploy ubuntu-devenv to the machine and add a relation between mysql and ubuntu-devenv. That should set up access to the database from there.
[14:21] <Prabakaran> yes
[14:22] <babbageclunk> Prabakaran: Essentially, deploying any charm that can be related to mysql should do it.
[14:22] <Prabakaran> i have just created the container and sshed into it
[14:22] <babbageclunk> Prabakaran: (and linking them together)
[14:23] <babbageclunk> Prabakaran: https://jujucharms.com/requires/mysql
[14:23] <Prabakaran> and thru charm it should work .. is that what u r sayin?
[14:24] <babbageclunk> Well, at the moment, mysql doesn't know anything about the other machine (and nor does juju).
[14:25] <babbageclunk> If you want juju to manage it, it needs to know that you want to use the database from outside.
[14:25] <babbageclunk> or rather, from another machine.
[14:26] <babbageclunk> Prabakaran: I think so.
[14:27] <Prabakaran> if i use ubuntu-devenv and add-relation between them.. how do i test mysql-client usage ?
[14:27] <babbageclunk> Prabakaran: hmm - good question. Just checking...
[14:31] <babbageclunk> Prabakaran: I'm fairly sure you'd use a hook tool to find out the connection information, but I don't know the exact command.
[14:35] <Prabakaran> k <babbageclunk> thanks
[14:35] <Prabakaran> let try using a charm
[17:24] <Prabakaran> I am not able to run sql commands in the remote-database using mysql charm and mysql interface. I am getting permission error.  Below is the log file and reactive file link Log: http://paste.ubuntu.com/19094490/ Reactive file of sampledatabasecharm: http://paste.ubuntu.com/19094762/
[17:24] <Prabakaran> Below are the commands which I used juju deploy mysql juju deploy <sampledatabasecharm> juju add-relation mysql sampledatabasecharm
[17:29] <Prabakaran>  Kindly advise me on this issue
[17:29] <kwmonroe> Prabakaran: you won't be using the 'root' user to connect
[17:29] <kwmonroe> the mysql relation will return a username that you can use
[17:31] <Prabakaran> still i was getting the same error. and also it was showing there is no username. thats y i commented username and gave as root
[17:33] <kwmonroe> Prabakaran: line 13 here should be "user", not "username" :)  http://paste.ubuntu.com/19094762/
[17:33] <Prabakaran> k let me deploy and try once
[17:34] <kwmonroe> also Prabakaran, the mysql relation will create and return a database for you to use.. you would get the name of that database with "relation_call --state 'mysql.available' 'database'"
[17:35] <Prabakaran> is it a default database?
[17:35] <kwmonroe> yes
[17:35] <Prabakaran> k
[17:36] <kwmonroe> Prabakaran: i don't think you'll need the config_db() function at all.  unless you have a specific need to create a database, user, and grant privs for that user, you should just use the default db that mysql creates for you.
[17:38] <kwmonroe> Prabakaran: if you *do* need to create dbs and users and do stuff like "grant", you'll need to relate your charm to mysql over the mysql-admin relation.  see the openbook charm for an example that uses the admin relation vs the normal mysql relation: https://api.jujucharms.com/charmstore/v5/trusty/openbook-3/archive/metadata.yaml
[17:39] <kwmonroe> Prabakaran: the openbook db-admin-relation-changed hook shows how they use the admin relation to create specific databases and users:  https://api.jujucharms.com/charmstore/v5/trusty/openbook-3/archive/hooks/db-admin-relation-changed
[17:41] <kwmonroe> so i think the first thing you'll need to decide is whether or not you need to do administrative things to the mysql charm, or if you can simply use the db and credentials that mysql creates for you by default.
[17:43] <Prabakaran> for my requirement i need to create a database and let me try with mysqladmin
[17:43] <Prabakaran> for mysqladmin, should i need to install anything using apt-get ?
[17:44] <Prabakaran> here i am using apt-get install mysql-client
[17:44] <kwmonroe> nope Prabakaran, nothing else to install.  mysqladmin is included in mysql-client
[17:44] <Prabakaran> k
[17:45] <Prabakaran> let me deploy and confirm to you
[17:47] <kwmonroe> ok Prabakaran, but just to be clear, the mysql relation only grants your user access to a default db.  since you need to create your own db, you will need to specify the mysql-root relation in your metadata.yaml.
[17:50] <Prabakaran> so i will have to use   db-admin:       interface: mysql-root
[17:50] <Prabakaran> in metadata.yaml
[17:51] <Prabakaran> then what about   "mysql":     "interface": "mysql"
[17:51] <Prabakaran> which i have already included>
[17:55] <kwmonroe> marcoceppi: cory_fu:  Prabakaran needs a mysql-root interface insted of mysql.  i'm pretty sure that means he can remove "interface: mysql" from his metadata.yaml, but i'm not sure what state he will then need to react too.  will mysql.available be set with mysql-root?
[17:57] <cory_fu> kwmonroe: It will not, because mysql-root is a different interface than mysql, so the mysql interface layer will not work with mysql-root.  A new interface layer will need to be created to support the mysql-root interface protocol
[17:57] <cory_fu> There is already a mysql-shared interface layer registered for that protocol
[17:59] <cory_fu> kwmonroe, Prabakaran: That said, if you change the interface to 'mysql-root' but keep the relation name as 'mysql', and the interface layer for the mysql-root protocol follows the same pattern, then you could conceivably still use the 'mysql.available' state, since the prefix ('mysql') is based on the relation name, not the interface name.  But from your conversation above, it would probably need to change to 'db-admin.available'
[18:01] <kwmonroe> i don't understand how mysql-shared works (especially since provides.py is empty)
[18:02] <cory_fu> kwmonroe: Well, the provides.py would presumably be used by the mysql charm itself, but since that hasn't been converted to layers yet, it's currently unused.  It should definitely be filled in, though.
[18:03] <Prabakaran> should i need to change anything in the layer.yaml file?
[18:04] <cory_fu> Prabakaran: You would need to change the "includes:" item that references "interface:mysql" to "interface:mysql-root"
[18:07] <cory_fu> marcoceppi: Is there actually anything different in the protocol between mysql and mysql-root?
 here i have a doubt ... there is no mysql-root interface available in the interface.juju.solutions then how charm build cmd will pick mysql-client?
[18:09] <cory_fu> Prabakaran: Yes, the mysql-root interface does not currently exist and needs to be created.  However, I think that the protocol may actually be identical to 'mysql' in which case it could be trivial to add
[18:11] <kwmonroe> cory_fu: i don't see (m)any diffs between mysql and mysql-root.. it's just that root grants privs on everything vs just a single db (https://api.jujucharms.com/charmstore/v5/mysql/archive/hooks/db-relation-joined)
[18:11] <kwmonroe> who is a ~mysql-charmer?
[18:11] <cory_fu> marcoceppi, kwmonroe, Prabakaran: From my reading of the mysql charm, I think the protocol itself is actually identical and we can probably just re-register https://github.com/johnsca/juju-relation-mysql under the mysql-root name and call it done
[18:12] <cory_fu> kwmonroe: It's only marcoceppi: https://launchpad.net/~mysql-charmers/+members
[18:12] <kwmonroe> maintanership through obscurity.  i like ;)
[18:14] <kwmonroe> cory_fu: i'll do the re-register and see how we fair
[18:14] <cory_fu> +1
[18:15] <cory_fu> Prabakaran: For you, that means that all you have to do is change your layer.yaml to "interface:mysql-root" and metadata.yaml to "interface: mysql-root"  If you keep the same relation name, you shouldn't have to change anything else
[18:16] <kwmonroe> wait wait.. he'll need to make the relation name db-admin because the "admin = xyz" line here https://api.jujucharms.com/charmstore/v5/mysql/archive/hooks/db-relation-joined looks for db-admin
[18:17] <kwmonroe> unless i'm reading this wrong... "admin = os.path.basename(sys.argv[0]) == 'db-admin-relation-joined'" means mysql is checking to see if the hook name is 'db-admin-relation-joined', right cory_fu?
[18:18] <cory_fu> kwmonroe: You're confusing the mysql charm's relation name vs the client charm's relation name
[18:19] <kwmonroe> dang.. you're right.  my bads.
[18:20] <kwmonroe> ignore my last couple comments Prabakaran.  any really, any time cory_fu is in the covo, just do what he says... "Prabakaran: For you, that means that all you have to do is change your layer.yaml to "interface:mysql-root" and metadata.yaml to "interface: mysql-root"  If you keep the same relation name, you shouldn't have to change anything else"
[18:20] <Prabakaran> after all these changes files looks like http://paste.ubuntu.com/19099534/ http://paste.ubuntu.com/19099537/ http://paste.ubuntu.com/19099560/
[18:21] <kwmonroe> LGTM Prabakaran
[18:21] <Prabakaran> i have pasted my reactive file, metadata.yaml and layer.yaml file...if you see any changes let me know
[18:21] <Prabakaran> LGTM means :)?
[18:23] <kwmonroe> Prabakaran: looks good to me :)
[18:23] <Prabakaran> oh grt thanks:)
[18:24] <Prabakaran> how about reactive file with database related query changes
[18:24] <kwmonroe> np, let us know how it works out.. i think mysql-root could be useful to others too.
[18:25] <kwmonroe> Prabakaran: the relation_calls look fine, but i'm not versed in mysqladmin syntax, so i don't have any input there.
[18:25] <Prabakaran> so you will be adding mysql-root interface under interface.juju.solutions right? than only i willl be able to test my charm?
[18:25] <kwmonroe> Prabakaran: it's already there
[18:25] <kwmonroe> i added it a few minutes ago
[18:25] <marcoceppi> cory_fu: the protocol /is/ the same, for the most part
[18:26] <Prabakaran> oh cool :) added soon
[18:26] <Prabakaran> thats grear
[18:26] <Prabakaran> *great
[18:26] <Prabakaran> Thanks all , i will test and confirm to u..
[18:26] <marcoceppi> cory_fu kwmonroe I'll probably re-register the mysql-root and mysql layers as I round out the MySQL charm layerization
[18:27] <kwmonroe> cool marcoceppi -- any beef with Prabakaran using the mysq-root interface as-is for now?  (which is just a dupe of the mysql interface with a new name atm)
[18:27] <marcoceppi> kwmonroe: no
[18:27] <marcoceppi> the consumer side shouldn't change much
[18:28] <kwmonroe> cool
[18:33] <kwmonroe> anyone writing bash charms (or anyone that has bash scripts in general).. i was at texas linux fest this past weekend and got turned on to http://www.shellcheck.net/.  it's a *really* neat way to lint your bash, if you're into that kind of thing.  turns out, i'm terrible at quoting my ${variables}.
[18:36] <jrwren> im terrible at declaring function local variables. does it lint for that?
[18:38] <magicaltrout> rock and roll kwmonroe ! You know how to live it up!
[18:38]  * magicaltrout goes to take a look out of morbid curiosity
[18:39] <kwmonroe> jrwren: i'll check in a sec, but here's one that gets me all the time..
[18:39] <kwmonroe>                 if [ -f  $ARCHIVE_DIR/*.gz ]; then
[18:39] <kwmonroe>                          ^-- SC2086: Double quote to prevent globbing and word splitting.
[18:39] <kwmonroe>                          ^-- SC2144: -f doesn't work with globs. Use a for loop.
[18:41] <jrwren> very nice!
[18:45] <kwmonroe> well jrwren, it does not seem to bark at local func vars (or lack thereof).  i'll adjust my rating to 9/10 ;)
[18:50] <Prabakaran> i kwmonroe, i just tested my sample charm and it is pending for long time on unknown state with the log http://paste.ubuntu.com/19102078/ and code files are http://paste.ubuntu.com/19099534/ http://paste.ubuntu.com/19099537/ http://paste.ubuntu.com/19099560/.
[18:55] <kwmonroe> Prabakaran: can you paste the states that your charm thinks are set?  juju run --unit <unit/X> 'charms.reactive -p get_states'
[18:56] <kwmonroe> Prabakaran: also, did you re-run charm build after the code changes and deploy that new charm?
[18:56] <Prabakaran> yes
[18:57] <Prabakaran> root@ptcvm2:~# juju run --unit sampledatabase/3 'charms.reactive -p get_states' {}
[18:57] <Prabakaran> it shows null
[18:57] <kwmonroe> Prabakaran: how about:  juju status-history sampledatabase/3
[18:58] <kwmonroe> that may not show much depending on what states your sampledatabase charm sets
[18:59] <Prabakaran> juju status-history sampledatabase/3 ----http://pastebin.ubuntu.com/19103015/
[19:01] <kwmonroe> hmph.. odd that you wouldn't at least see the mysql.connected state since it clearly ran the joined and changed hooks
[19:02] <kwmonroe> cory_fu: anything jump out at you? ^^
 it is time for me to sleep.. i will lookinto this issue... and if you come to know anything regarding this please mail me. Thanks for your support :)
[19:04] <kwmonroe> np Prabakaran - have a good night..
[19:04] <Prabakaran> Thanks kwmonroe
[19:06] <cory_fu> Sorry, I was grabbing some food.
[19:06] <cory_fu> Have a good night, Prabakaran
[19:08] <cory_fu> That is odd
[19:09] <cory_fu> Actually, it looks like the hooks aren't getting built properly: 2016-07-11 18:38:40 INFO juju.worker.uniter.operation runhook.go:116 skipped "mysql-relation-joined" hook (missing)
[19:12] <cory_fu> kwmonroe: I think I know what the problem is.  Interface layers aren't designed to be re-used like that; it's interface.yaml still calls it "mysql" and I think that's blocking it from being included in the build (should have gotten a build warning or something)
[19:12] <cory_fu> We're going to have to clone that repo, change that one line, and re-register
[19:14] <kwmonroe> ah, on it.
[21:27] <petevg> marcoceppi, cory_fu: following up on the coversation in the broadcast hangout on Friday, I put together a first pass at a unit testing helper lib for layered charms. Feedback, harsh criticism, etc. welcome! PR here: https://github.com/juju-solutions/charms.unit/pull/1
[21:28] <petevg> It works with the unit tests that I wrote here: https://github.com/juju-solutions/layer-apache-bigtop-base/pull/28 (You just have to change the name of the import, and put charms.unit somewhere in your path).
[21:55] <cory_fu> petevg: Comments added.  I'm particularly confused about the docstring vs implementation of to_mock / mock_layers.
[21:55] <petevg> cory_fu: reading through your comments now. Thank you very much :-)


[00:01] <thomi> spiv: hmmm, I can't see how to get a rev_id for a give file_id in the branch.repository inventory
[00:03] <thomi> ahhh, this works (bug is kind of ugly): dict(inv.entries())[relpath].revision
[00:09] <thomi> spiv: got it! Are you able to tell me if I;m doing anything really wrong in this: http://pastebin.ubuntu.com/882561/ please?
[00:19] <lifeless> thomi: inv[inv.path2id(relpath)].revision
[00:19] <lifeless> I think there is a more direct one still
[00:21] <thomi> ahh, I didn't realise the inventory was usable like a dictionary :)
[01:05] <Pikkachu> hi, how can I keep an up-to-date reference in my code to submit or push branch?
[01:05] <Pikkachu> in the specific case, it's the branch url used as project home
[01:06] <Pikkachu> does bazaar allow to create a commit hook at least?
[01:07] <Pikkachu> or is it better to just write an enclosing shell script which performs the changes before committing (for example using sed)?
[01:15] <spiv> Pikkachu: you can create commit hooks, yes
[01:15] <spiv> Pikkachu: I don't entirely follow what you're asking for, though
[01:16] <spiv> Pikkachu: you want the text you commit to contain the location of the submit or push branch?
[01:38] <Pikkachu> no, I want every commit to trigger the references in code to be updated before the commit is performed
[01:48] <Pikkachu> I think I can enclose the commit with a previous look into .bzr and subsequent update of required files...
[01:48] <Pikkachu> with a shell script, I mean
[02:44] <Kamping_Kaiser> is it possible to diff one bzr branch against another branch at an arbitrary revision?
[02:44] <Kamping_Kaiser> i want to find out if foo/ (at rev 13) was merged into bar (at rev 191) at any point
[02:46] <spiv> Kamping_Kaiser: bzr help revisionspec, see revno:
[02:46] <spiv> Kamping_Kaiser: e.g. -r revno:13:foo/..revno:191:bar/ I think
[02:47] <Kamping_Kaiser> spiv: i'll have a try, thanks.
[03:02] <Pikkachu> thanks spiv anyway
[03:37] <spiv> Oh!  It sounds a bit like Pikkachu wanted keyword expansion.
[03:40] <mwhudson> noone really wants keyword expansion do they?
[03:40] <bob2> lots of people think they do though
[03:55]  * fullermd does.
[03:58]  * bob2 expands fullermd's keywords into merge conflicts
[03:59] <fullermd> I didn't say I want a crap implementation of keywords   :p
[04:00] <bob2> haha
[08:46] <poolie> hey all
[09:06] <vila> hmm, internet access issues here :-/ Rare but painful event, seems to to come from ADSL itself which is worrying
[09:10] <ggherdov> vila: totally OT, but you hit a point that bothers me when I have unstable connections: i am conversating over IRC, then I am cut off from the internet, the person I'm talking with continues writing, but I miss part of the chat. Is there any kind of "IRC buffering thing" I can install on a remote server I have (which has reliable internet), in order to proxy my IRC connection thru a "stabilyzer"?
[09:11] <mgz> morning all!
[09:12] <vila> ggherdov: probably what IRC proxies are about, I don't use one myself :-/ (On the other hand, since I'm connected via ADSL I think the availability have been like 99.999999% or something...)
[09:12] <vila> mgz: hey !
[09:13]  * ggherdov IRC proxies... interesting.
[09:13] <Peng> ggherdov: They're frequently known as bouncers.
[09:13] <ggherdov> Peng: good to know. thx.
[09:14] <Peng> ggherdov: Personally, I prefer to run a command-line IRC client, and I usually run it on something with a stable connection that I have SSH access to. (That's what I'm doing now.)
[09:16] <ggherdov> Peng: I see your point. But is the SSH part of the connection is faulty, you risk to miss stuff. You still need you remote-cmd-line-irc-client to buffer stuff for you, and send all the stuff you missed when it sees you again.
[09:16] <ggherdov> s/is/if
[09:17] <Peng> ggherdov: I use GNU screen, so the SSH connection doesn't have to be reliable.
[09:17] <Peng> Sorry, I should've said so, but I think of screen/tmux as a given when using SSH.
[09:17]  * ggherdov Peng got game
[09:17] <ggherdov> Peng now I see. wow a powerful combination
[09:18] <ggherdov> btw, using tmux since 2 months and it's a great util.
[09:18] <Peng> I've never tried tmux. screen's good enough for me.
[09:19] <ggherdov> Peng: I use tmux in order to split my terminal in several shell in a tiledfashion. didn't know of the fault tolerance thing untill now.
[09:19] <ggherdov> shells*
[09:19] <Peng> Ah. I don't tile stuff.
[09:20]  * ggherdov nobody's perfect :-)
[09:22] <Peng> :(
[09:41] <nigelb> Peng: tiling irssi leads to really really claustrophobic typing space :)
[09:43] <Peng> But but I need to IRC in six channels at once.
[09:44] <nigelb> haha
[11:02] <ggherdov> there was an option to 'bzr rm'  in order to bzr-remove a file that you had already bash-removed. what was that ?
[11:03] <jelmer> ggherdov: there is no special option necessary
[11:04] <jelmer> ggherdov: 'bzr rm' (without other arguments) should also pick that up
[11:04] <ggherdov> ah good.
[11:04] <ggherdov> thx jelmer
[11:04] <ggherdov> I was mixing up with 'bzr mv --after'
[11:29] <jelmer> vila: hah, the main user of .revision_history() is bzrlib.tests.per_branch.test_bound_sftp, but all tests there seem to be skipped for some reason
[11:31] <vila> jelmer: hmm, did I tyoped set_revisions_history ?
[11:31] <vila> in the line above ? yes :)
[11:31] <mgz> "Not a local URL"
[11:31] <mgz> fun.
[11:33] <vila> mgz: huh ?
[11:35] <vila> jelmer: so, having read your review (thanks !), I'm talking about *set_revision_history* not revision_history, probably related but still different beasts
[11:35] <mgz> we don't really have a way of detecting test success->skip regressions
[11:35] <mgz> without carefully watching babune test counts across runs
[11:35] <vila> jelmer, mgz: By the way, I didn't touch code deprecated in 2.5.0, I can't remember what our rule is ? n+1, n+2 ?
[11:36] <vila> meh, rule to delete code deprecated in series n that is
[11:36] <mgz> vila: what you did seems fine, 2.4 gone in 2.6 seems right
[11:36] <vila> anyway, there is still a bunch to remove before touching code deprecated in 2.5
[11:37] <vila> k, thought it was a bit conservative but since there is still a bunch to do before touching that...
[11:37] <vila> I think I saw code that was deprecated without any version attached which is... bad :)
[11:43] <vila> but again, let's get rid of what we can safely remove first
[11:44] <mgz> jelmer: those tests seem too be skipping all the way back to 2.2
[11:46] <mgz> it might make more sense to work out what they're trying to do, write new tests, and delete the module
[12:36] <mgz> there's already bug 728252 for those tests skipping, so just proposed deleting them to reduce the chance of us rediscovering that again in future
[12:55] <mgz> "Ran 1 test in 102.260s" heh...
[13:08] <ams_cs> bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps
[13:08] <ams_cs> anybody know what I can do about that?
[13:12] <jelmer> hi ams_cs
[13:12] <jelmer> ams_cs: can you provide some more background?
[13:13] <ams_cs> I'm trying to merge lp:gcc/4.7 into (a clone of) lp:gcc-linaro/4.7
[13:13] <ams_cs> I've tried it on two machines and get the same result, so it doesn't appear to be some local corruption
[13:18] <jelmer> ah, hmm
[13:18] <jelmer> I didn't realize those two branches had related history
[13:19] <jelmer> that usually indicates branches having a slightly different view on shared history
[13:19] <jelmer> can you file a bug? I'll try to look into it.
[13:19] <ams_cs> hmm, lp:gcc-linaro/4.7 was originally branched from lp:gcc/trunk
[13:20] <ams_cs> upstream branched 4.7 from trunk (in SVN) a week or two ago
[13:21] <ams_cs> doko imported the new branch as lp:gcc/4.7, but they should share history right up to the svn branch point
[13:21] <ams_cs> and lp:gcc-linaro/4.7 has not diverge far from lp:gcc/trunk
[13:39] <ams_cs> jelmer: any luck?
[13:41] <jelmer> ams_cs: still fetching the branches
[13:43] <ams_cs> jelmer: yeah, that'll take a while. BTW, there's no need to have a local copy of lp:gcc/4.7 to reproduce the problem ... although maybe to debug it
[13:53] <jelmer> ok
[14:23] <mgz> vila: did you file a bug for the bzrlib/locale thing?
[14:23] <vila> mgz: nope, sry
[14:24] <vila> mgz: this test_bound_sftp stuff is... worrying :-/
[14:24] <mgz> I think it's less worrying than it looks.
[14:25] <vila> how d'you know we're not reducing coverage here ?
[14:25] <mgz> because the tests have never (at least since 2.0) actually been run.
[14:26] <mgz> we certainly lack functional style testing on various real world things with both the smart server and other remote branches
[14:26] <vila> revno 5030 (2.1 => 4857, 2.2 => 5120) says otherwise (but I can't run the tests there due to some testtools/subunit issue)
[14:27] <vila> well, not 5030 but rather 5017.3.33
[14:27] <vila> but what worries me is that we didn't notice it earlier
[14:27] <mgz> we did!
[14:27] <mgz> spiv filed a bug :)
[14:28] <vila> # ?
[14:28] <mgz> linked from the mp.
[14:28] <mgz> bug 728252
[14:28] <vila> gha, I parsed that as added by lp :-)
[14:29] <mgz> anyway, deleting these certainly doesn't reduce coverage, and I don't think there's much worth salvaging from their logic
[14:30] <vila> ... color me confused but how to you know these doesn't reduce coverage ?
[14:30] <vila> s/to you/do you/
[14:31] <mgz> we have pretty good unit testing for bound stuff, and we know we have holes for functional testing
[14:32] <vila> ha, ok
[14:34] <mgz> vila: eg. bt.per_branch.test_branch.TestBound
[14:35] <jelmer> it does seem kindof odd to have these kinds of tests in bt.per_branch
[14:35] <mgz> we're not testing against remote branches, but that's been true for... ages
[14:35] <vila> yeah, yeah, I mis-interpreted :)
[14:35] <vila> indeed, looks like very old bb tests
[14:36] <vila> approved by the way
[14:38] <jelmer> uhoh
[14:38] <jelmer> I guess that means https://code.launchpad.net/~jelmer/bzr/remove-branch-history/+merge/97411 will conflict
[14:38]  * vila reviewing, was about to mention
[14:40] <mgz> jelmer: you made them run again?
[14:41] <vila> nope, he made them keep skipping ;)
[14:41] <vila> instead of erroring :)
[14:41] <mgz> well, I better win the race then :)
[14:42] <jelmer> well, I kept them around but at least avoided the calls to the functions I was removing
[14:42] <vila> which is a bit unfortunate :-/
[14:44] <vila> err, I mean, it's unfortunate you spend time on them not knowing they were skipped anyway
[14:44] <jelmer> vila: in what way? It should be trivial to resolve the conflict..
[14:44] <jelmer> ah
[14:44] <jelmer> well, not the worst thing in the world :)
[15:06] <Pikkachu> what a straightforward way to make automated pre-commit (1) validations and/or (2) source code modifications? I'm just thinking of using shell script or the like
[15:11] <LarstiQ> Pikkachu: you could look at how the bzr-text-checker plugin works
[15:31] <ams_cs> jelmer: any news?
[15:38] <jelmer> ams_cs: I'm still looking, but I'm pretty sure it'll take a couple of days squash this bug. I'm not really familiar with this bit of the code.
[15:38] <jelmer> ams_cs: I'll file a bug about it and subcribe you - who are you on Launchpad?
[15:38] <ams_cs> ams-codesourcery
[15:39] <ams_cs> jelmer: thanks, I was hoping there'd be a work-around :(
[15:40] <alansaul> If I push over the top of a respository, can get get the previous one back?
[15:45] <jelmer> alansaul: yes, by using "bzr pull -rREV ."
[15:45] <jelmer> alansaul: yes, by using "bzr pull -rREV . --overwrite"
[15:47] <mgz> one jelmer always tells the truth, and the other jelmer always lies
[15:47] <mgz> how can you tell which command to run?
[15:47] <alansaul> Lol
[15:47] <alansaul> Uh oh
[15:48] <mgz> okay, so maybe I'm an idiot, and someone would have pointed the problem out by now if it was actually the case but...
[15:48] <mgz> don't the .mo files never actually get installed?
[15:49] <mgz> so... all that translation stuff we did for 2.5 isn't actually enabled?
[15:50] <vila> mgz: as in: on debian/ubuntu you mean ?
[15:50] <mgz> well, I'm looking at the code in setup.py
[15:51] <vila> I thought we had bug reports about that and that you even fixed some of them... may be we are 2 idiots :)
[15:51] <mgz> it may be that the way debian builds it the files are included, but they don't seem to be in the windows installer
[15:51] <LarstiQ> how does gettext on windows work btw?
[15:51] <mgz> badly.
[15:52] <mgz> ehem...
[15:52] <vila> it misses a leg or two may be...
[15:52] <mgz> python has it's own implementation, so you just point it at a directory of specially arranged .mo files
[15:54] <vila> . o O (post-install tests)
[15:55] <mgz> hm, there are .mo files in python-bzrlib
[15:55] <mgz> so, however we're building for debian works somehow at least
[15:55] <vila> WARNING: gnome-keyring:: couldn't send data: daemon closed connection
[15:56] <vila> while running the full test suite
[15:56] <vila> does that ring a bell ?
[15:56] <mgz> but the code seems to need the build artefact to exist at setup.py invocation to include it
[15:56] <mgz> which... implies you must run setup.py twice for it to function
[16:01] <jelmer> mgz: translations seem to work here..
[16:02] <mgz> jelmer: how do you build for debian exactly?
[16:02] <mgz> the intersection of makefile and setup.py is a little confusing
[16:03] <mgz> I'm trying to fix the inplace creation of .mo files but don't want to accidentally break you.
[16:04] <jelmer> mgz: don't worry about that
[16:08] <mgz> oh but I do :)
[16:24] <Pikkachu> sorry, pidgin crashed, who was talking to me?
[16:24] <Pikkachu> the text checker plugin seems overkill
[16:39] <LarstiQ> Pikkachu: sure, but the interest for you is the pre-commit machinery?
[16:41] <wgz> what was that thing from lifeless about not using "should" in bug titles?
[16:42] <wgz> I'm struggling to phrase things without it
[16:43] <jelmer> wgz: I think the point was mainly that bug reports should primarily describe problems
[16:44] <jelmer> as opposed to a ticket tracker I think
[16:45] <LarstiQ> wgz: I find that hard too
[16:45]  * LarstiQ looks it up
[16:47] <wgz> I think it was on google+ so good luck ever finding it again...
[16:51] <Pikkachu> LarstiQ: I don't want a machinery that's why it's overkill, I want some simple concept
[16:52] <Pikkachu> LarstiQ: I don't need to set up and configure any machinery for using an enclosing shell script with the custom rules for each branch, for example
[16:53] <Pikkachu> wgz: maybe because it's implied
[16:53] <wgz> Pikkachu: that's contradictory
[16:54] <Pikkachu> how so?
[16:54] <wgz> you want to do something pre-commit, but not have to worry about any machinery for doing things in response to actions?
[16:54] <LarstiQ> wgz: actually, it is the second hit on "bug should" in my circles
[16:55] <Pikkachu> wgz: I mean for example "Bazaar should grep revisions from diffs" => "Grep revisions from diffs in Bazaar"
[16:55] <LarstiQ> wgz: https://plus.google.com/u/0/105660309458564946897/posts/BLhnbgoouXV
[16:55] <Pikkachu> wgz: ah you mean my case, ok
[16:55] <wgz> LarstiQ: logging in and being in Robert's circle is cheating :)
[16:55] <Pikkachu> wgz: it's not contradictory, it's you who's not understanding
[16:56] <LarstiQ> wgz: isn't that how you find stuff on g+? ;P
[16:56] <LarstiQ> Pikkachu: could you explain some more what you're trying to do?
[16:57] <wgz> Pikkachu: I mean, sure you can write a shell script that does something and then calls bzr commit, and use that rather than commit itself
[16:57] <Pikkachu> wgz: doing complex things may require a machinery setup or not, making the former case unnecessarily complex, that's what I mean. In this specific case, I don't want to depend on some plugin installed and configured for anyone willing to commit to the branch. This can be completely avoided
[16:58] <Pikkachu> wgz: the shell script has the advantage of not requiring any installation, it's self-contained in the branch and ready for use for anyone who branches the repo
[16:59] <wgz> provided they remember to run it instead of using commit
[16:59] <Pikkachu> wgz: READE.BEFORE.COMMITING :)
[17:00] <Pikkachu> wgz: or seriously, for a single file branch, commit.sh will call user's attention unless he's dumb
[17:00] <wgz> doesn't seem that different from having an instruction in there to cp commit_hook.py to ~/.bazaar/plugins
[17:01] <wgz> but whichever you like.
[17:01] <wgz> it would be nice to have a better mechanism for branch-specific thingies, but there are reasons it hasn't happened
[17:02] <Pikkachu> wgz: that's why I was looking for a even better solution, but pre-steps like installing and configuring stuff *so that* I can achieve what I want is a non-go. This step can be completely replaced with a shell script already there and ready for using
[17:02] <wgz> mostly because the idea of branching something then meaning it automatically runs arbitrary code when you do some operation is scary
[17:02] <Pikkachu> wgz: I think a more straightforward solution was if I was able to register a commit hook natively within the branch without any external setup required
[17:02] <wgz> there are a few threads on the bazaar list on this topic
[17:03] <lamalex> jml, with testtools, what's the proper matcher to ensure something is not None?
[17:03] <jml> lamalex: assertThat(x, Not(Is(None)))
[17:04] <Pikkachu> wgz: I'd be really surprised that bzr does not support commit hooks though
[17:04] <wgz> it does, you just need to manually install them, for the above reason.
[17:04] <jml> lamalex: I guess if you wanted to you could define 'IsNotNone = Not(Is(None))' and then do assertThat(x, IsNotNone)
[17:05] <lamalex> ha right
[17:05] <lamalex> thanks
[17:05] <lamalex> i wasn't reading carefully and skipped over Not :P
[17:05] <lamalex> whoope
[17:10] <Pikkachu> wgz: manually install? how so?
[17:13] <wgz> as mentioned, `cp commit_hook.py ~/.bazaar/plugins/commit_hook.py` or similar.
[17:14] <wgz> probably want `mkdir -p ~/.bazaar/plugins` first.
[17:16] <wgz> if you desperately want to write your checking logic in shell you'd have to use subprocess from the commit hook callback
[17:22] <wgz> jelmer: you're the man today. or maybe the page?
[17:25] <Pikkachu> wgz: I have no idea what to put within that file
[17:25] <Pikkachu> wgz: besides a hook should be a hook not what the hook holds
[17:25] <Pikkachu> wgz: a hook is supposed to just trigger something, not be that very something
[17:26] <jelmer> wgz: eheh
[17:26] <jelmer> wgz: This coming from somebody with surname that's just begging for VCS-related puns?
[17:27] <jelmer> *a
[17:27] <Pikkachu> wgz: I mean something like $bzr add-hook --pre-commit --system "commit-validation.sh"
[17:27] <LarstiQ> Pikkachu: in my hazy memory something like that exists
[17:28] <jelmer> Pikkachu: that is what this is, except it is in Python, not shell.
[17:28] <wgz> Pikkachu: LarstiQ was trying to help you earlier linking an example
[17:28] <Pikkachu> wgz: or $bzr add-hook --post-commit afterCommitting => afterCommitting.py, run it directly from within python instead of catching output/return value from a system executable
[17:28] <jelmer> Pikkachu: hooks are installed per-user, perchance using per-branch configuration data. They don't live in the branch itself, for security reasons.
[17:29] <Pikkachu> jelmer: if it's like wgz is saying, then it's not really a hook, it's a plugin which catches commit events
[17:29] <LarstiQ> Pikkachu: branch.Branch.hooks.install_named_hook('pre_commit', pre_commit_hook, 'text-check')
[17:29] <wgz> apart from a slightly different wrapper, I don't see the difference
[17:30] <Pikkachu> LarstiQ: 'text-check'?
[17:30] <LarstiQ> Pikkachu: that is from bzr-text-checker, it is the analog of your `bzr add-hook --pre-commit text-check.py`
[17:30] <Pikkachu> jelmer: what reasons
[17:30] <jelmer> Pikkachu: if I download a branch from somewhere, tweak it and then run "bzr commit" I don't want to run arbitrary code that came from that branch.
[17:30] <Pikkachu> LarstiQ: no it's not, mine is a command line, yours is python code
[17:31] <LarstiQ> Pikkachu: hence, analog
[17:31] <Pikkachu> LarstiQ: no
[17:31] <Pikkachu> LarstiQ: it may be analog but not in the sense I mean
[17:31] <LarstiQ> Pikkachu: and as I also said, I remember there being something to run arbitrary commands for hooks
[17:31] <Pikkachu> jelmer: that's easy to fix
[17:32] <Pikkachu> LarstiQ: ah thanks...that would be interesting....
[17:32] <jelmer> LarstiQ: there is bzr-shell-hooks, which allows you to define shell commands to run in .bzr/branch/branch.conf
[17:32] <jelmer> I haven't updated it in a long time though, so it may have bitrotted
[17:32] <LarstiQ> Pikkachu: apparently, it is called bzr-shell-hooks ;)
[17:33] <Pikkachu> jelmer: so you're the author? cool... by shell you mean any system command or the underlying shell like bash etc?
[17:33] <Pikkachu> is it my imagination or can plugins be installed within a branch?
[17:34] <LarstiQ> Pikkachu: you can have configuration for them in a branch
[17:34] <jelmer> Pikkachu: plugins can't be installed within a branch, they're installed in the users home directory
[17:34] <jelmer> Pikkachu: bzr-shell-hooks installs trivial hooks that can run commands configured in the branch
[17:35] <LarstiQ> jelmer: or well, you _could_ point BZR_PLUGIN_PATH at a branch
[17:36] <jelmer> LarstiQ: that's true
[17:37] <lamalex> hi im trying to write a push hook, and i want to get the author of the last commit
[17:37] <lamalex> really i want all the authors for each commit since the point where its parent was branched
[17:37] <lamalex> but just the one is fine for now :P
[17:37] <jelmer> lamalex: your hook should receive the relevant revision ids, which you can use to retrieve the revision metadata
[17:37] <lamalex> anyone have a tip? i see i can get the revision easily, but i dont see what i can actually do with that
[17:38] <jelmer> lamalex: The revision object has a .committer attribute which is just a string with the author name and email, and it has a .get_apparent_authors() method which returns a list of strings with authors
[17:38] <lamalex> ah nice
[17:39] <lamalex> so would i take that from my target branch
[17:41] <Pikkachu> LarstiQ: the BZR_PLUGIN_PATH seems a good idea if bzr-shell-hooks is lightweight, this way users would not be required to install it
[17:42] <jelmer> lamalex: yeah, usually. since you're sure the revision is present there
[17:42] <Pikkachu> lamalex: how are you writing a bzr hook?
[17:42] <LarstiQ> Pikkachu: on the other hand, you might not want to forcefully override their plugin path
[17:42] <lamalex> Pikkachu, http://doc.bazaar.canonical.com/beta/en/user-guide/hooks.html
[17:43] <Pikkachu> jelmer: well, wasn't you who said about security risks? and yet has such a plugin like bzr-shell-hooks? :P
[17:43] <lamalex> jelmer, so do i just take that id and make a new revision?
[17:43] <LarstiQ> Pikkachu: are you confusing me with jelmer?
[17:44] <lamalex> Revision(id).get_apparent_authors
[17:44] <jelmer> Pikkachu: that's exactly why bzr-shell-hooks is a plugin, and not part of the core
[17:44] <jelmer> Pikkachu: also, I don't actually use bzr-shell-hooks myself.. it was just a quick hack a couple of years ago
[17:46] <Pikkachu> lamalex: that looks like non-branch specific
[17:46] <Pikkachu> no LarstiQ: "jelmer: Pikkachu: hooks are installed per-user, perchance using per-branch configuration data. They don't live in the branch itself, for security reasons."
[17:47] <lamalex> Pikkachu, i have no idea what you're talking about. i'm guessing you pinged me due to a misunderstanding
[17:47] <Pikkachu> lamalex: we're talking about commit hooks, coincidently
[17:47] <jelmer> lamalex: e.g. something like target_branch.repository.get_revision(id) will return the revision object
[17:47] <lamalex> ah, im talking about push hooks
[17:47] <lamalex> but totally unrealted
[17:48] <Pikkachu> lamalex: I want a commit hook on a specific branch, not wherever I typ bzr commit
[17:48] <LarstiQ> Pikkachu: that's easily controllable with configuration
[17:53]  * LarstiQ eats dinner
[18:16] <Pikkachu> actually I will explain the exact problem:
[18:19] <Pikkachu> I have a pidgin plugin written in C which needs to provide an URL, I didn't care to register a project in LP so the URL is basically [...]/+junk/branch-name. But it happens that this URL is already contained in .bzr as push/submit branch. I want to keep source code always up-to-date with what's in .bzr. Any ideas?
[18:19] <Pikkachu> well, actually I think it doesn't matter that much it being in source code, more in the resulting builds...
[18:20] <Pikkachu> therefore I could implement this as a build step not a commit hook... but I don't want to use make because I would duplicate code from pidgin build environment which is mostly required anyway in windows
[18:20] <Pikkachu> so any ideas? thanks
[18:23] <jelmer> re
[18:25] <jelmer> Pikkachu: I'm not sure I follow what you mean; are you talking about changing the default locations for 'bzr pull' and 'bzr push' ?
[18:32] <Pikkachu> no... nevermind I think I'll resolve the problem myself
[18:48] <LarstiQ> Pikkachu: at build time you want to say "this code came from <here>"?
[18:54] <Pikkachu> at build time it would be like:
[18:55] <Pikkachu> plugin.c => #define URL "@@PLUGIN_URL@@", then
[18:56] <Pikkachu> something like using sed for replacing @@@PLUGIN_URL@ from what's within .bzr before compiling it
[18:56] <LarstiQ> right
[18:56] <LarstiQ> sort of like the `bzr version-info` use case, but with different data
[18:57] <Pikkachu> seems like not
[18:57] <LarstiQ> Pikkachu: where would the url come from? Is `bzr config parent_location` sufficient?
[18:57] <Pikkachu> $ bzr help version-info => Show version information about this tree.
[18:57] <Pikkachu> shows, does not change anything
[18:57] <LarstiQ> Pikkachu: read on
[18:58] <Pikkachu> ah sorry...
[18:59] <Pikkachu> nice to know about $ bzr config, I'm not sure if it's submit or push branch, but yes it's either of it
[19:01] <Pikkachu> unfortunately the submit/push urls are not available there :(
[19:01] <LarstiQ> Pikkachu: if they're not set probably not
[19:01] <LarstiQ> Pikkachu: but it depends on your workflow what will be in there
[19:02] <Pikkachu> the ones listed are {date} {build_date} {revno} {revision_id} {branch_nick} {clean}
[19:02] <LarstiQ> Pikkachu: e.g., in my bzr.dev copy submit_branch is not set, but in my 2.5-fixes branch it is
[19:02] <LarstiQ> Pikkachu: ah, in version-info?
[19:03] <LarstiQ> right, that is what I meant with "different data"
[19:03] <LarstiQ> Pikkachu: I wonder if it makes sense for version-info to include this data
[19:03] <Pikkachu> it includes the branch nick already
[19:04] <LarstiQ> Pikkachu: yeah, but that is more portable
[19:04] <LarstiQ> Pikkachu: it's actually contained in the commit data
[19:04] <Pikkachu> I don't get this command though, the example says it will *generate* a C header file?
[19:05] <LarstiQ> Pikkachu: in the example the template will give valid C syntax
[19:05] <LarstiQ> Pikkachu: and then you'd direct the output to, say, build_info.h
[19:06] <Pikkachu> but I don't think it meant to " produce a C header **file**", just a valid header string
[19:07] <Pikkachu> anyway, I think I can simply seek into .bzr anyway
[19:07] <LarstiQ> Pikkachu: that is more fragile, but if you want, yes
[19:08] <LarstiQ> Pikkachu: sure, the example is a valid header *fragment*. The common use of it would be as a single header file though. And of course your template can be more complicated
[19:09] <Pikkachu> I think the help message needs a small fix
[19:09] <Pikkachu> fragile in which sense, just missing to be there?
[19:10] <LarstiQ> Pikkachu: that, and in theory subject to change
[19:11] <LarstiQ> Pikkachu: what fix to the help message do you propose?
[19:11] <Pikkachu> LarstiQ: change what, the config format/location?
[19:11] <LarstiQ> Pikkachu: yeah
[19:11] <LarstiQ> Pikkachu: you're poking around in internals
[19:11] <LarstiQ> Pikkachu: that's always at ones own risk
[19:12] <Pikkachu> LarstiQ: fix: not mentioning it will generate a file, it just generates text output which is supposed to be placed separately into a file (from what I've got of what the command does)
[19:13] <Pikkachu> LarstiQ: I just forgot, I can use cd branch; url=$(bzr config push_location)
[19:14] <LarstiQ> Pikkachu: or even `url=$(bzr config -d branch push_location)`
[19:17] <Pikkachu> oh I tried without -d, cool!
[19:18] <Pikkachu> now the problem is: I reuse the whole pidgin build infrastructure, because most of it is required anyway
[19:19] <Pikkachu> a pidgin windows build environment contains everything a regular plugin requires, plus the ability to build them if you place them in the correct place
[19:20] <Pikkachu> I could duplicate the makefiles and make them point to pidgin root, but I think it's overkill
[19:20] <Pikkachu> hmm I just had an idea
[20:02] <Pikkachu> something like build.sh:
[20:02] <Pikkachu> url=$(bzr config push_location | sed 's/\//\\\//g')
[20:02] <Pikkachu> cat plugin.c | sed s/@url@/$url/ > "$devroot/pidgin-$version/pidgin/plugins/plugin.c"
[20:03] <Pikkachu> cd "$devroot/pidgin-$version/pidgin/plugins" && make...
[20:03] <LarstiQ> Pikkachu: right.
[20:04] <LarstiQ> Pikkachu: stylistically I would go for including a header instead of rewriting plugin.c, but that's a small niggle
[20:08] <Pikkachu> LarstiQ: it's overkill to split the plugin into a separate files, and it doesn't rewrite the plugin itself, but the copy from which it will be built
[20:09] <Pikkachu> the above would be the same as copying the plugin to there then sed -i
[20:11] <Pikkachu> hmm actually I could use your suggestion to avoid build.sh not being used (if one copy the file to there and $ make it, then the url will remain as "@url@" in the binary)
[20:11]  * LarstiQ nods
[20:14] <Pikkachu> if I use #include "plugin.url.h" then 'URL' instead of @url@, compilation will fail if build.sh is not used and no header is manually created...sounds interesting, thanks for the tip LarstiQ
[21:19] <Pikkachu> thanks all for the constructive discussion!
[21:45] <poolie> hi all
[21:45] <poolie> hi lifeless
[22:42]  * jelmer waves to poolie