[00:18] <emgent> heya
[00:22] <bdmurray> howdy
[04:34] <mrooney> hmmm, why are aptitude and apt-get so different for installing python-epydoc
[04:34] <mrooney> apt-get will install it juuust fine
[04:34] <mrooney> but aptitude wants to pull in 230 megs of deps for a total of ~500MB unpacked
[04:34] <mrooney> is that some sort of bug
[04:34] <crimsun_> no.  aptitude installs Recommends by default, too.
[04:35] <mrooney> oh, well is it a bug against epydoc that it recommends so much? that seems off
[04:35] <mrooney> but, maybe not!
[04:36] <crimsun_> no, it's not a bug in either aptitude or epydoc.
[04:36] <mrooney> crimsun_: okay, fair enough
[04:36] <mrooney> I'll just use apt-get for it
[04:37] <mrooney> thanks!
[04:37] <RAOF> mrooney: You can turn off the recommends-by-default logic on a case-by-case basis; I think it's --without-recommends.
[04:38] <mrooney> RAOF: thanks, that is good to know, I will probably do that
[04:38] <mrooney> I have never seen such a large set of recommends
[05:15] <bimberi> Installing devscripts on sid wants to bring in all sorts of things - citadel-common, x11-common, subversion, dillo, mysql-common to name a few.
[06:46] <bliZZardz> \/join #ubuntu-in
[06:46] <bliZZardz> err...sorry for that
[15:30] <bliZZardz> when a bug is a duplicate, then what should be it's status ?
[15:33] <bliZZardz> got it - thanks!
[15:44] <bliZZardz> if there is a known issue in upstream, then how should the bug be changed? should the status of the bug be changed to 'Confirmed'?
[15:46] <pedro_> bliZZardz: it should be Triaged, but if you don't have the permissions to set it, Confirmed is ok
[15:49] <bliZZardz> pedro_ : kindly have a look at Bug #241808, and let me know whether my response was right.
[15:54] <pedro_> bliZZardz: that's ok, also it doesn't seems to be an openoffice.org issue so you might want to reject that task
[15:54] <pedro_> hi Iulian
[15:55] <Iulian> Hello pedro
[18:14] <Ienorand> Anybody in here got some spare time to look at new attachments for bug #219584? /give instructions for further "research"...
[18:46] <persia> I'll be doing a class on interpreting apport retraces in about 17 hours, and wondered if anyone had a favorite apport bug with a good stacktrace to nominate for investigation during the session?
[18:59] <bdmurray> persia: bug 136371 maybe?
[19:01] <persia> bdmurray: That could work.  I tend to like longer traces (10 or more calls) as they are easier to explain.  Do you have an interest in that bug  specifically?
[19:02] <bdmurray> persia: not really just rss-glx seems to be a mess
[19:02] <bdmurray> a mess of apport crashes that is
[19:03] <persia> bdmurray: Makes sense.  I'll look about and see if I can find a more complex crash, hopefully in hardy.
[19:03] <persia> On the other hand, I'm guessing most of the problem is with GL issues, which are a little special :(
[19:03] <bdmurray> that particular one has some more recent duplicates
[19:04] <persia> 9!  Wow.  Now I understand why it's interesting :)
[19:04] <bdmurray> persia: will you be covering a python crash at all too?
[19:06] <persia> bdmurray: There's usually only time for one, and I have more experience with C than with python.  Do you have a good python candidate?  I'd be willing to do a python, as I've had a few of the same students at previous sessions, and they may like variety.
[19:06] <persia> (said differently: I'll do a python one if I can figure it out before class :) )
[19:07] <bdmurray> heh
[19:09] <bdmurray> displayconfig-gtk has a fair number of crash reports but I believe the application is deprecated so that might not be best
[19:14] <persia> Not only that, but it likely breaks because of issues with which video drivers support what operations.
[20:37] <bdmurray> pedro_: ping
[20:41] <pedro_> bdmurray: hi
[20:41] <bdmurray> Did you already have a hug day planned for tomorrow?
[20:41] <pedro_> bdmurray: nothing for tomorrow, I'm more looking to next week
[20:42] <bdmurray> pedro_: okay, great
[22:05] <LimCore> hello
[22:05] <LimCore> is this a good place to discuss general ubuntu "wish" idea?
[22:08] <danbhfive> LimCore: maybe brainstorm.ubuntu.com
[22:08] <LimCore> yeas I know it, ok
[22:09] <LimCore> but is it brainstorm really usefull? Most ideas get a lot of votes... and what then?
[22:09] <danbhfive> I dunno, I've posted several ideas in several places, and none have gotten any attention from anyone important
[22:10] <bdmurray> Developers have started responding to ideas on brainstorm
[22:10]  * LimCore is a developer too \o/
[22:11] <LimCore> If I'm awesome C++ devel, can I get $$$ for developing for ubuntu?
[22:11] <LimCore> any sponsorhip etc?
[22:11] <LimCore> *spelling


[10:24] <Egbert9e9> am i the worst person for not liking to type in a password for an openid registration?
[10:24] <Egbert9e9> moshe742: #hasadna
[10:25] <Egbert9e9> moshe742: we should stage a coup over G+ / FB with our freenode channel


[08:14] <elacheche> Morning folks! Kilos :) theShirbiny sorry I was AFK → It was my weddign
[08:36] <Kilos> hi elacheche congrats sir
[13:10] <elacheche> thx Kilos
[18:07] <Kilos> hi guys
[18:07] <Kilos> didnt we have someone here from uganda a while back?
[19:00] <Kilos> sleep tight africa
[22:28] <theShirbiny> elacheche, congrats :)


[07:52] <nhaines> pleia2: thanks for the lovely email!  Even though I've only read it twice and haven't acted on it yet, it was really nice to have such a considerate handoff.  :)


[23:42] <pleia2> ~philipz85 is a legit user helping with Xubuntu, if someone could approve him to https://launchpad.net/~ubuntu-wiki-editors :)


[12:33] <lewmnik_> magicfab: http://wiki.ltsp.org/twiki/bin/view/Ltsp/LTSP-42-LocalDev
[12:55] <cbx33> ping ogra
[01:00] <cbx33> any progress on Tcm?
[01:06] <juliux> hey Yagisan
[01:08] <Yagisan> G'day juliux
[01:13] <cbx33> hi Yagisan
[01:13] <cbx33> howz it going
[01:23] <Yagisan> cbx33, rather crap actually
[01:24] <Yagisan> cbx33, about two weeks left to fnd a new place to live
[01:24] <Yagisan> and only dumps are available :/
[01:37] <Yagisan> cbx33, and yourself ?
[01:37] <BillMeLater> good morning
[01:44] <cbx33> sorry to hear that Yagisan
[01:44] <cbx33> I'm just going home - I'll chat to you when i get back if you're still around
[02:28] <RichEd> hey cbx33 : it's tamarra ... and note that ogra and i will be travelling ... so it will be hosted by willvdl
[02:28] <cbx33> right
[02:28] <willvdl> cbx33, I thought today was monday...
[02:28] <cbx33> hehe
[02:29] <willvdl> ow
[02:29] <BillMeLater> this place is violent
[02:29] <willvdl> we learn the hard way
[02:29] <cbx33> not always
[02:29] <BillMeLater> skool of hard nox
[02:30] <BillMeLater> of course
[02:31] <BillMeLater> dumb question: people here work in school districts?
[02:32] <RichEd> BillMeLater: some people ... educators, techies, developers, university students ... a range of peops
[02:32] <BillMeLater> I'm a school board member who wants to evangelize FOSS
[02:32] <BillMeLater> looking for look-see-it-works-great cases.
[02:33] <cbx33> ahh i see
[02:33] <cbx33> ok
[02:33] <cbx33> well I can give you one, we use jabber server at my school
[02:33] <cbx33> all the staff have IM
[02:33] <BillMeLater> So I'll lurk.
[02:33] <cbx33> and can message each other
[02:33] <BillMeLater> very good. ..
[02:33] <BillMeLater> where r u?
[02:33] <cbx33> http://www.progbox.co.uk/wordpress/?p=162
[02:33] <cbx33> UK
[02:34] <BillMeLater> I'm in Lawrence Township, New Jersey, US
[02:34] <BillMeLater> Our admin wants to upgrade HW so we can be ready for Vista, natch...
[02:34] <BillMeLater> u get the picture
[02:35] <cbx33> yuk
[02:35] <cbx33> yeh
[02:35] <cbx33> better to stay where you are
[02:35] <cbx33> for at least another year
[02:35] <cbx33> point him to the BECTA report about vista and office 2007
[02:36] <BillMeLater> Oh - they're in no hurry - they just figure that's where we are headed because...
[02:36] <RichEd> BillMeLater: i've got a great US advocate for you ... will need yout email to send
[02:36] <BillMeLater> well...
[02:36] <BillMeLater> just because!
[02:36] <RichEd> *your
[02:36] <BillMeLater> I'm all (virtual) ears
[02:37] <RichEd> he was k12ltsp and is now a rabid edubuntu supporter ... mixed environment of MS and Linux ... he's a teacher and an admin
[02:37] <BillMeLater> sounds like the ammo I need
[02:39] <RichEd> BillMeLater: see /msg window
[02:39] <BillMeLater> got it - I'm a lil slow
[02:40] <BillMeLater> thank u
[02:41] <BillMeLater> I want to accumulate a large group of references
[02:41] <TeePOG> afternoon gents
[02:42] <BillMeLater> mornin' mate
[02:42] <TeePOG> *phew*
[02:42] <TeePOG> not from where i'm sitting
[02:43] <TeePOG> or i'd have this day ahead of me
[02:43] <BillMeLater> I shoulda said "Yo!"
[02:43] <TeePOG> instead of almost over
[02:43] <TeePOG> :-D
[02:43] <TeePOG> indeed
[02:43] <RichEd> it's the US time TeePOG : they're behind us like on the koyot agreement ;)
[02:43] <BillMeLater> skary
[02:43] <RichEd> *koyoto
[02:43] <TeePOG> yar RichEd true
[02:43] <TeePOG> kyoto?
[02:43] <TeePOG> ciao RichEd
[02:44] <BillMeLater> Nagoya
[02:44] <BillMeLater> c ya
[02:44] <RichEd> TeePOG: the please don't kill the planet with your 18 cylinder cars and disposable consumerism
[02:44] <TeePOG> yah
[02:44] <TeePOG> toxic culture
[02:45] <RichEd> but no offense intended towards BillMeLater ... even if the nick does imply use the resources now and BillMeLater (or my grandkids)
[02:45] <RichEd> :)
[02:45] <BillMeLater> I can't get a break...
[02:45] <BillMeLater> I live in the Rodney Dangerfield of nations
[02:45] <RichEd> lol
[02:45] <BillMeLater> gotta tap your fones first
[02:54] <juliux> hey pirast
[02:54] <pirast> hi juliux
[03:23] <RichEd> ping BillMeLater : i'll need your email address now'ish ... leaving for a trip in a few hours
[03:38] <BillMeLater><EMAIL_ADDRESS>- see chat win for info on spam filter bypass
[03:39] <BillMeLater> RichEd, see chat window for info on spam filter bypass
[03:39] <RichEd> okily dokily
[03:39] <BillMeLater> thanx, Ned
[03:40] <RichEd> the chat window is blank apart from my own text earlier ?
[03:40] <BillMeLater> hmm ... I will email you in 2 mins
[03:41] <RichEd> you must not be identified to the nick server, I mean you must, but right not, you prolly aren't
[03:42] <BillMeLater> true - I don't IRC enuf to stay familiar with the rigamarole
[03:48] <BillMeLater> RichEd, I emailed u
[03:49] <RichEd> BillMeLater: thanks ... will check now
[04:03] <RichEd> BillMeLater: replied with 2 names & addresses
[04:04] <BillMeLater> thank u
[04:04] <bddebian> Heya
[05:00] <barktpolar> Hello Edubuntu Users
[05:01] <barktpolar> Which is better for dial-up, GNOME-PPP or KPPP?
[05:01] <barktpolar> !ubotu dial-up
[05:01] <ubotu> You want to connect via dial-up? Read https://wiki.ubuntu.com/DialupModemHowto
[05:29] <cbx33> ogra, is there any difference in the ubiquity install in edubunut and ubuntu
[05:29] <cbx33> also does the desktop install install any LTSP/dhcp stuff?
[06:23] <willvdl> cbx33, I doubt the desktop does any of that
[06:23] <willvdl> not sure about ubiquity
[08:03] <juliux> highvoltage, ping
[11:13] <Burgwork> cbx33: need that question answered?
[11:13] <cbx33> Burgwork, which one?
[11:13] <cbx33> hehe
[11:19] <cbx33> Burgwork, oh the one about the desktop cd?
[11:19] <Burgwork> I have no idea
[11:20] <cbx33> oh you were just asking if I needed that question answered
[11:20] <cbx33> not giving me the answer
[11:20] <cbx33> I see now
[11:20] <cbx33> did you get my emails?
[11:28] <Burgwork> cbx33: yes, but crazy busy right now
[11:29] <cbx33> np np
[11:38] <cbx33> just checking wasn't looking for a reply or anything ;)


[00:01] <maxb> jam: It's a LP bug. It's failed to publish a build-dep on lpia
[00:03] <maxb> nooo, new bzr-git failure on hardy
[03:50] <quotemstr> How can I merge changes HEAD-2 and HEAD-3 in the history?
[07:02] <chx> hi. if i use --hardlink but then edit a file ... how can i make sure my editor breaks the hardlink?
[07:03] <bob2> depends on the editor
[07:03] <chx> i see. can nano do it? can a file system configured to do it, in general ?
[07:03] <bob2> no
[07:03] <bob2> to (b)
[07:04] <bob2> dunno if nano can/does by default
[07:37] <lifeless> there is an ldpreload hack to break them
[07:50] <chx> lifeless: FL-COW?
[07:53] <fullermd> Urp.  Bookmarks is broken with .dev   :(
[12:39] <damd> hi.  i have a weird problem which only happens when i use vc-bzr in emacs, but maybe someone here can help me anyways?
[12:40] <damd> when i do "C-x v =" on a file in emacs (bzr diff equivalent) i get: bzr: ERROR: [Error 2] The system cannot find the file specified
[12:40] <damd> however, when i do "bzr diff that/file.el" in cmd.exe it works just fine
[12:41] <damd> any ideas?
[12:44] <Tak> can you find out what actual filename emacs is using?
[12:44] <Tak> i.e. is it just trying to do `bzr diff file.el`
[12:45] <damd> i've tried to look in the source code, reluctant to modify it, but what the hell, what's the worst thing that can happen... let me check
[12:46] <Tak> well, if it logs someplace or something...
[12:46] <damd> it doesn't
[12:46]  * Tak not familiar with emacs nor vc-bzr
[12:52] <damd> i noticed just now that if the file has no changes, everything works as expected saying "no changes found" or similar
[12:52] <damd> so it's something that happens when it determines that there are changes
[13:01] <damd> okay, i think i've found the problem and it must be on emacs's side
[13:01] <damd> "Running bzr diff --diff-options -c vc-bzr.el in background... done"
[13:01] <damd> i don't think the working directory is correct
[13:01] <damd> therefore it can't find vc-bzr.el
[13:06] <damd> actually, i guess that's not the problem, since it works right when there are no changes
[13:17] <damd> okay, running the same command that emacs uses in cmd.exe gives me the same error abut a file not being found
[13:17] <damd> i'm guessing that this file is "diff"
[14:09] <vila> damd: sounds pretty weird
[14:09] <vila> damd: --diff-options without options for a given diff is suspicious
[14:10] <damd> vila: i wrote a patch for vc-bzr-diff which takes care of it
[14:10] <vila> damd: bzr has an internal diff, so I suspect having --diff-options triggers using an external 'diff' which it doesn't find
[14:10] <damd> exactly
[14:10] <vila> ha good
[14:10] <vila> damd: the fact that you're using windows may make the bug more obvious too
[14:10] <damd> i would have pushed the patch immediately if i had the time/ability to test it properly
[14:11] <vila> damd: are you running emacs from source or from a official release ?
[14:11] <damd> from weekly windows builds
[14:11] <vila> I see
[14:12]  * vila should really switch to vc and stop using dvc if only for test purposes
[14:12] <damd> vc is really nice when you get the hang of it
[14:12] <vila> I haven't use it for years
[14:15] <damd> why do all things emacs have so ugly logos?
[14:16] <damd> the emacs logo itself, the gnu logo, and now the DVC logo, christ that's bad
[14:16] <damd> http://download.gna.org/dvc/dvc.png
[14:18] <vila> aw, come on there are not that bad :)
[14:18] <damd> the DVC logo is probably one of the worst logo's i've seen :|
[14:18] <vila> actually the dvc is a nice variation of the emacs one (when you like the later ;)
[14:18] <damd> they've literally _forced_ it to look like it says DVC on that gnu head
[14:19] <damd> actually, that's what they did with the emacs logo as well... forced it to look like a gnu and now it looks like neither a gnu nor emacs
[14:19] <vila> well, the oldest logo I can remember for emacs was a kitchen sink :)
[14:19] <damd> yeah, i've seen that, but at least that wasn't official :P
[14:20] <vila> hmm, as official as it can be as this time: http://www.emacswiki.org/emacs/EmacsIcons
[14:22] <vila> I think even Lucid Emacs was using the kitchen sink icon, at least I was using lucid in these times so that's probably where I remember the icon from
[14:23] <damd> i thought only some "funny" distros shipped emacs with that icon
[14:23] <damd> this is the emacs icon that is the default in windows: http://www.emacswiki.org/pics/static/CarbonEmacsPackageIcon.png
[14:25] <vila> yeah, this one has been around for ehat... ~ 10 years ?
[14:25] <vila> ha no, the pencil was added at some point
[14:25] <damd> no idea, i only started using emacs about five years ago
[14:25] <damd> honestly, if i were to create an emacs logo, i wouldn't know where to start, but i _would_ know where to _not_ start and that is with the current gnu thing
[14:26] <vila> hehe
[14:26] <damd> enough senseless ranting for now!
[14:27] <vila> mwahaha, best wallpaper ever : http://i.imgur.com/RxlwP.png
[14:28] <damd> see, even the wallpapers are ugly :(
[14:28] <vila> lol
[14:28] <vila> scratch this itch !
[14:28] <damd> yeah
[14:30] <mgz> http://paste.ubuntu.com/558550/ <- that's a lot of PointlesslyBreakThings lines.
[14:31] <mgz> do I need to add a tests for all of the ones that get fixed, or just trust people not to write broken code in future...
[14:32] <vila> mgz: hellllo !
[14:33] <mgz> hey vila!
[14:33] <vila> mgz: what's the context ?
[14:33] <mgz> bug 707954
[14:33] <vila> str(xx) considered harmless ?
[14:33] <vila> harmful I meant
[14:34] <mgz> http://paste.ubuntu.com/558552/ <- example test.
[14:34] <mgz> str(any_path) is harmful, yup. bzr uses unicode for paths.
[14:34] <vila> ha ! yeah, so my last memories was running away crying from the rename exceptions
[14:35] <vila> adding tests to ensure we cover all code paths there will be ideal
[14:36] <vila> second to that would be to get rid of the str() harmful calls, but finding them and fixing them without tests may be tricky
[14:37] <vila> so to come back to your initial question, if you can add a test for every call your fix: perfect
[14:37] <vila> trying to avoid future errors... no idea on how to do that (the tests should be a good defense anyhow)
[14:37] <mgz> I'm guessing not to blackbox though.
[14:38] <vila> depends which layer you want to test
[14:39] <mgz> well, ideally lower if I'm covering all those.
[14:41] <vila> yup, my  memory tells me the relevant code is indeed lower
[14:41] <mgz> it's WorkingTree.move ._determine_mv_mode .rename_one
[14:41] <vila> have a look at the related exceptions too, that's where I started crying
[14:42] <mgz> yeah, they're a bit of a mess.
[14:42] <vila> at one point I got lost because exceptions were raised when trying to format an exception
[14:42] <mgz> as is the general code for displaying errors about paths, eg bug 388437
[14:43] <vila> related to that,
[14:43] <mgz> ^I need to fix some of this in another branch anyway
[14:43] <vila> the unicode exceptions have an attribute with the faulty string but it's not displayed by default
[14:43] <mgz> yeah, that'll be worth doing on top.
[14:44] <vila> I was wondering if we could catch them in the bzr script (or wherever the exceptions are caught).. you see the point
[14:44] <mgz> yup.
[14:44] <vila> I'm still awfully jet lagged so you type too fast for me ;)
[14:44] <mgz> so... where are WorkingTree methods tested?
[14:45] <vila> did you see the bash_completion failures on windows ?
[14:45] <vila> per_tree ?
[14:45] <vila> bt.per_tree, bt.per_workingtree
[14:45] <mgz> ah, yeah.
[14:45] <vila> or may be these ones aren't :-/
[14:46] <vila> I'd so love to add a 'raise' somewhere that would make all the relevant tests fail...
[14:46] <mgz> ^nope.
[14:46] <vila> -s bp.bash_completion -> 4 failures
[14:47] <vila> can you reproduce that ?
[14:47] <mgz> it's not really worth testing at all on windows though, and I thought wasn't.
[14:47] <mgz> "Missing feature 'bash executable' skipped 12 tests."
[14:47] <mgz> so, unlikely to get them.
[14:48] <vila> well, I thought that too, but babune was happy with them before...
[14:48] <vila> hmm
[14:48] <vila> jam: around ?
[14:48] <mgz> testing a cygwin bash under the windows python isn't very worthwhile.
[14:48] <jam> hi vila
[14:48] <vila> jam: hello !
[14:49] <jam> I'm currently on windows, but I ran the test and it gave "missing bash executable"
[14:49] <vila> can you run -s bp.bash_completion in your windows setup... damn
[14:49] <jam> I'll try and check into it a bit
[14:49] <jam> I run the win32 python under cygwin
[14:49] <jam> so I would have thought path would be correct
[14:51] <vila> rats, babune has no log about the features and skipped tests :(
[14:52] <mgz> 2.7 logs skips sensibly now, but the win slave is on 2.6 right?
[14:54] <jam> strange
[14:54] <jam> running python manually, I see cygwin in the path
[14:54] <jam> and running "p = subprocess.Popen('bash -c "echo hello"', shell=True)" works
[14:55] <jam> ah, it's the probe
[14:55] <jam> it specifically probes for the exact name "bash" in the path
[14:56] <jam> so it won't find "bash.exe"
[14:56] <vila> haaaa ! doxxx fix !
[14:56] <jam> so why is it finding it for vila
[14:56] <vila> in its mergetools proposal gordon tweaked osutils.find_executable_on_path, with weird bits for windows I didn't fully understand
[14:57] <vila> so my guess is that it makes it find exes that weren't found previously
[14:58] <vila> using a trick that is *not* used when calling the exe, so the probe succeeds now (it was failing before) and the tests now failed (they were skipped before)
[14:58] <jam> vila: yep
[14:58] <jam> vila: well, I wouldn't be surprised if the tests fail because it isn't compatible
[14:58] <vila> which means babune reports skipped tests as successful ones... :-/
[14:58] <jam> more than just because it can't find it
[14:58] <vila> true
[14:58] <jam> vila: right, the code in test_bashcomp.py looks to be using the exact path to 'bash'
[14:59] <jam> and not using shell=True
[14:59] <vila> hmm, not using shell=True is harmless on unices ?
[15:00]  * vila never uses shell=True
[15:03] <mgz> hm, I don't know how to hit some of these branches.
[15:06] <vila> mgz: scary ;)
[15:10] <mgz> ...the test just above where I'm adding these looks totally bogus too
[15:10] <mgz> self.assertRaises((errors.InvalidNormalization, UnicodeEncodeError),
[15:10] <mgz>             tree.rename_one, 'a', u'ba\u030arry')
[15:11] <mgz> what the hell kind of check is that? it will *always* be raising the second exception, which If A Real User Did It, would print a big ugly traceback.
[15:11] <wash> Do the latest versions of bzr-svn support any form of setting SVN properties (specifically, svn:eol-style and svn:mime-type)?
[15:11] <vila> mgz: this makes sense
[15:11] <vila> mgz: that's what the bug you're fixing is about
[15:12] <maxb> wash: No, there is no way to explcitly edit user svn properties through bzr-svn
[15:12] <vila> mgz: except that we now know that it's a bug and not an expected behavior
[15:14] <wash> maxb: *nods* Thanks
[15:17] <jam> mgz: check the annotate on that file. I probably wrote that code about 3-4 years ago
[15:18] <jam> back when I was working on supporting normalization inside bzr
[15:18] <jam> I know it pre-dated dirstate
[15:18] <jam> which was what, 0.15 ?
[15:18] <mgz> yeah, it's old, and I'm not even sure why the UnicodeEncodeError is checked for from the history
[15:18] <vila> jam: are you sure it hasn't been modified when the rename exceptions have been introduced ?
[15:19] <mgz> possibly for when unicode paths aren't supported at all? it's unclear.
[15:19] <vila> my gut feeling is that UnicodeEncodeError has been added at this point in time
[15:19] <jam> vila: could have been. I wouldn't be surprised if the test was saying "must raise InvalidNormalization" and someone decided to be lazy and have it raize Unicode
[15:19] <vila> mgz: you may want to check the InvalidNormalization one
[15:19] <vila> jam: yup, that's my feeling
[15:20] <jam> mgz: also note, I personally have stopped trying to fight that fight since getting normalization during status is pretty difficult to make it perform well
[15:21] <jam> and I ran into people on Windows not having normalized filenames
[15:21] <jam> because Japanese windows wanted to use all wide characters in the filename
[15:21] <mgz> NF(K)* is pretty deadly, but that's the K.
[15:22] <mgz> messes up kana as well as ＦＵＬＬＷＩＤＴＨ characters
[15:22] <vila> wow, nicely displayed here :)
[15:22] <mgz> something still needs to be sorted jam, because macs seem stuck in limbo wrt unicode at the moment in bzr
[15:23] <maxb> NFK* is evil madness
[15:23] <jam> mgz: Oh the system is pretty hosed at the moment. NFC is  better than NFK, (AIUI) though I didn't know it back in the day
[15:24] <jam> however, *I personally* have stopped trying to fight for it. I'd be happy to review stuff
[15:24] <leonardr> i have a bzr question for anyone who can help
[15:24] <cody-somerville> leonardr, no one can at the moment as you haven't asked your question ;)
[15:25] <leonardr> cody: ah, that's the problem. i never asked my question
[15:25] <leonardr> i'll explain it in abstract terms but here's the merge proposal of the branch: https://code.launchpad.net/~leonardr/lazr.restful/encode-xhtml-field/+merge/47536
[15:26] <jam> leonardr: I believe the standard line is: "Just ask the question, don't ask to ask", but honestly it is pretty ingrained in us that a polite interruption is the rigth thing to do...
[15:26] <leonardr> i do not want to get side tracked on this discussion, but to set the record straight, my first utterance was an introduction and i immediately proceeded to start writing the question
[15:26] <jam> I suppose in IRC you want short communication because everyone has to type? Not sure why that became standard
[15:27] <leonardr> the last release of this package was at revision 164
[15:27] <leonardr> we're now at revision 166, and i need to do a point release based on revision 164
[15:28] <leonardr> i can just do a release off my branch
[15:28] <leonardr> but i'd like to merge it in to the mainline so that it will be easy to find later
[15:29] <maxb> That all sounds correct.... where's the question? :-)
[15:29] <leonardr> my current plan is to revert to revision 164, commit, merge my branch, commit, do the point release, and then re-merge the code from revisions 155 and 156
[15:29] <leonardr> is there a better way, or is that it?
[15:29] <maxb> eek
[15:29] <jam> leonardr: reverting is probably not what you want
[15:29] <mgz> just branch from -r 164
[15:29] <vila> leonardr: just create a branch at...
[15:30] <leonardr> lp:~leonardr/lazr.restful/encode-xhtml-field is a branch from -r 164
[15:30] <vila> leonardr: -r 164, do your release stuff (including commitS)
[15:30] <vila> leonardr: then merge your point release on top of your trunk resolving conflicts
[15:31] <vila> leonardr: this will reflect the exact history of what you did, pretty clean IMHO
[15:31] <leonardr> vila: my problem with that is that there will be no revision in trunk that corresponds to the release
[15:31] <maxb> There will be no *mainline* revision in trunk which corresponds to the release
[15:31] <vila> leonardr: it will and you can tag it
[15:32] <leonardr> vila: ok, what do i tag?
[15:32] <vila> leonardr: the tip in your release branch *before* merging it to trunk
[15:32] <leonardr> vila: thanks, that was the missing piece
[15:33] <vila> leonardr: if you look at bzr history, you'll see that the tags are never on the mainline, always on a dotted revno
[15:33] <maxb> .... in a PQM-managed project, which this is not
[15:33] <vila> maxb: right, but this shouldn't be a problem either
[15:34] <maxb> Not a problem, but it does make the statement that tags are never on mainline not applicable here
[15:34] <vila> ho !
[15:34] <vila> right, my remark applied to bzr history *ONLY*
[15:34] <jam> maxb, vila: well *some* tags are on the mainline, for people like me that didn't like having to pre-tag before sending it to pqm, but we changed away from that because it was a real PITA to maintain. :)
[15:34] <maxb> Ah, the bzr history of bzr
[15:35] <vila> maxb: ouch, right, I missed the ambiguity there :-/
[15:35] <maxb> leonardr: So, is this making sense? :-)
[15:35] <leonardr> maxb: not at all :)
[15:35] <jam> but yes, leonardr, I would tag your release branch, and then merge it, and not try to tag the trunk mainline
[15:35] <leonardr> ok, i'll do that and let you know how it goes
[15:35] <vila> jam: as can be seen in bzr-0.{7,8,11,13,14,15,16,17,18,90} ? :-D
[15:36] <jam> vila: did you just run bzr log to find that ?
[15:36] <vila> bzr tags
[15:36] <jam> or 'bzr tags'
[15:37] <jam> vila: some of those are "?" tags
[15:37] <vila> all of them
[15:37] <jam> so those were before we merged release branches back into trunk
[15:37] <jam> but I still wanted to track them once we finally got tags
[15:38] <jam> vila: actually, only bzr-0.0.5 is a mainline revno.
[15:38] <jam> I think I did the work to have the tag on the release branch mainline
[15:38] <vila> yup, and plan0merge-dev >_<
[15:39] <jam> vs my local branch that got merged into the release branch, which was then eventually merged on the mainline
[15:39] <jam> vila: I don't have plan0merge-dev tag
[15:39] <jam> so that must have been one of yours
[15:39] <vila> plan-merge-dev
[15:39] <jam> I do have "plan-merge-dev" and "plan-merge-ab"
[15:39] <maxb> leonardr: short version: bzr branch -r 164 lp:lazr.restful lazr.restful-0.15.x; cd lazr.restful-0.15.x; bzr merge lp:~leonardr/lazr.restful/encode-xhtml-field; bzr commit; <Standard release procedures, which ought to involve bzr tag>; cd ....../branch-or-checkout-of-trunk; bzr merge ....../lazr-restful-0.15.x; bzr commit; bzr push
[15:40] <jam> vila: interesting that plan-merge-dev is a (vila) commit
[15:40] <jam> :)
[15:40] <vila> I don't think so
[15:40] <leonardr> maxb: ok, i'll let you know if i get unexpected results, but if the bzr tag works it should be fine
[15:41] <vila> jam: it's from pqm and plan-merge-ab from aaron
[15:41] <maxb> leonardr: One specific point to note - to ensure trunk's history is not confusing, it's important to merge the release branch into trunk, and not vice versa
[15:42] <vila> jam: both from 200712
[15:42] <jam> vila: it *is* a pqm revision, but it was a (vila) requested one :) I honestly don't know what the idea is
[15:42] <leonardr> maxb: sure. that's what i do usually, so it's no problem
[15:42] <jam> nor do I *really* care
[15:42] <leonardr> (except it's usually not a release branch)
[15:42] <jam> though it would be nice to be able to prune/hide tags
[15:42] <jam> 100 tags is getting a bit big, the 1000s of tags in an emacs branch is pretty overwhelming
[15:43] <maxb> hrm. bzr help does not tell you what the options are for tags --sort=???
[15:44] <vila> jam: weird... I never used tags until being RM...
[15:44] <jam> maxb: probably a bug in the help system. If you don't specify that an option can be supplied without the prefix, then it doesn't document the values
[15:44] <tedg> Hey, I'm getting a really odd Bazaar error: "ValueError: could not convert string to float: /bfa.ko"
[15:44] <jam> vila: "bzr.dev" is now properly failing the bash_completion tests
[15:45] <tedg> Any clue on how to get back to a running state from that?
[15:45] <maxb> tedg: Do you have a traceback with that?
[15:45] <jam> tedg: doesn't look like a float to me :)
[15:45] <jam> can you give more of a traceback
[15:45] <tedg> Traceback (most recent call last):
[15:45] <tedg>   File "/usr/bin/bzr", line 139, in <module>
[15:45] <tedg>     exit_val = bzrlib.commands.main()
[15:45] <tedg>   File "/usr/lib/pymodules/python2.7/bzrlib/commands.py", line 1203, in main
[15:45] <tedg>     _register_builtin_commands()
[15:45] <tedg>   File "/usr/lib/pymodules/python2.7/bzrlib/commands.py", line 182, in _register_builtin_commands
[15:45] <tedg>     import bzrlib.builtins
[15:45] <tedg> Not much...
[15:45] <vila> !paste
[15:46] <tedg> bug 708063
[15:47] <vila> tedg: ouch, sounds like a .pyc corruption no ?
[15:47] <vila> tedg: does 'bzr version' works ?
[15:47] <vila> tedg: or 'bzr info'
[15:47] <tedg> vila, No, neither of those work.
[15:48] <vila> tedg: right, so your install is... damaged ?
[15:48] <tedg> vila, Which pyc should I delete?
[15:48] <tedg> I can just remove the package and reinstall?
[15:48] <vila> tedg: well, yes
[15:49] <vila> tedg: but you may have a deeper issue there, .pyc files don't get corrupted randomly on well-behave machines ;)
[15:50] <vila> tedg: python-2.7 on lucid ??
[15:51] <tedg> vila, Yeah, it's odd.  But none the less, it works after the reinstall.
[15:51] <tedg> tedg, No on Natty
[15:51] <tedg> vila, ^ :)
[15:51] <vila> tedg: so InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429) is misleading ?
[15:52] <tedg> vila, It's correct.  That is what I used to install, then I upgraded.
[15:52] <vila> bah, of course, DistroRelease: Ubuntu 11.04 is the one I should have looked at
[15:52] <vila> tedg: anyway, good to know you're out of trouble
[15:52] <vila> I'll mark this bug invalid
[15:52] <tedg> Yes, thank you vila.    The web in general sucks :)
[15:58] <vila> tedg: shooting the messenger :)
[16:34] <mgz> okay, get this baby reviewd time.
[16:37] <vila> mgz: :)
[16:37] <vila> jam: do you know a way to look at the pending jobs for the package importer ?
[16:37] <jam> vila: define "look at"
[16:38] <jam> http://package-import.ubuntu.com/status/ tells you what is pending
[16:38] <jam> and what is currently running, etc.
[16:38] <vila> it currently says 0 but tail -f progress_log shows it keeps adding some
[16:39] <vila> so I guess my question is: what's the difference between outstanding jobs and pending jobs
[16:39] <jam> vila: when the package importer doesn't have explicit packages to import, it then spins checking random packages for consistency
[16:39] <vila> ha, I haven't seen that code yet then
[16:40] <jam> so "Outstanding" means it has seen new .deb files that need to be imported
[16:40] <vila> I'm working on mass_import.py
[16:40] <jam> otherwise it is just poking around doing sanity checks
[16:40] <vila> right, and it never stops doing that
[16:41] <vila> so I think I will stop poking at this code and start looking at testing it before deploying...
[16:46] <mgz> hm, have a feeling there was something else I was going to say in the mp but can't remember it.
[16:46] <jam> vila: your mail host is blocking emails from me
[16:47] <jam> vila: Remote host said: 550 Too many spams from your IP (<IP_ADDRESS>), please visit http://postmaster.free.fr/ [RCPT_TO]
[16:47] <jam> and the page they link me to is in French, so I really don't know what to do
[16:47] <jam> (well, click the English button...)
[16:47] <vila> to put their spam filters were the sun doesn't shine ?
[16:48] <jam> it looks like they are blocking all email from some of the mail.*.yahoo.com servers
[16:48] <jam> at least, the IP they give resolves to: nm6-vm0.bullet.mail.ac4.yahoo.com
[16:49] <jam> which is a bit hard for me to workaround.
[16:49] <jam> I can send mail directly from my IP, but that is usually blacklisted because it is a comcast account
[16:49] <jam> (or whatever the rules are. It is a "home" account, which is often blanket blocked)
[16:54] <maxb> heh :-/ So apparently bzr-git/hardy has *never* worked
[16:54]  * maxb wonders whether it's still worth doing hardy in ~bzr PPAs
[16:54] <vila> jam: try using my canonical address ?
[16:56] <jam> maxb: I believe hardy is still in its support window
[16:56] <maxb> Yes, but that's not *quite* the same question :-)
[16:57] <jam> vila: I'm just resending to make sure it works, but it was a note about the bash completion failures from sometime last night
[16:57] <maxb> oh, just a moment
[16:58] <maxb> Did hardy default to apt installing recommends?
[16:58] <vila> maxb: that's not the highest priority, if people are happy with hardy (instead of lucid), they are probably happy with whatever bzr version they have
[16:58] <mgz> jelmer needs more imaginative branch names.
[17:00] <mgz> he's submitted like, five different things called lazy something this month.
[17:05] <mgz> vila: I'm going to have to put up a 2.3 branch that just messes with imports as I've not had time to work on the transport hook and 2.3 is past beta
[17:07] <jam> mgz: for your Unicode changes, isn't it just moving when the error occurs? I thought the exception formatter still treats everything via str()
[17:08] <mgz> I cheated.
[17:09] <mgz> in this case, it gets safely upcast to unicode, then BzrError.__str__ encodes it to utf-8
[17:09] <mgz> I've got some other work that makes unicode things happen sensibly all the way down to bzrlib.trace
[17:12] <mgz> so, mojibake not UnicodeError
[17:12] <mgz> I'll add a note about this to the mp.
[17:12] <jam> well, its an improvement
[17:18] <catphish> does bzr have a native grep function?
[17:18] <catphish> (preferably in the CLI)
[17:18] <jam> catphish: there is a 'bzr-grep' plugin
[17:19] <vila> mgz: meh, why don't you just target 2.4 ?
[17:19] <catphish> jam: thanks, hopefully that'll do what i want :)
[17:19] <mgz> because I left a horrible hack in the code!
[17:21] <vila> mgz: with my blessing, send any complaint my way :)
[17:25] <mgz> hm, doesn't look like too many hits.
[17:28] <vila> mgz: you're referring to transport hook hack right ?
[17:30] <mgz> right.
[17:39] <vila> mgz: so nothing worth backporting to 2.3, target 2.4 :)
[17:40] <mgz> I'll put a mp up with some import changes and we'll see.
[17:41] <mgz> ...I actually intended that last mp to go to 2.3 as well, given it didn't change any interfaces, but perhaps 2.4 is safer.
[17:43] <vila> mgz: yup
[17:44] <vila> EODing, bye all
[17:44] <mgz> bye!
[18:12] <maxb> What is the name of the format defining the :param foo: constructs in bzr docstrings?
[18:23] <lifeless> maxb: epydoc restful ?
[18:23] <maxb> thanks
[19:13]  * jelmer waves
[19:14] <james_w> hi jelmer
[19:14] <james_w> are you at LCA?
[19:14] <jelmer> hi james
[19:14] <jelmer> no, I'm in Seattle
[19:15] <james_w> ah yeah
[19:30] <maxb> jelmer: Hi. I've now discovered that bzr-git has in fact never ever been compatible with hardy's ancient python-tdb. I'm thinking of uploading a bzr-git/hardy to the ~bzr PPA with the Recommends: python-tdb dropped, and the default cache format hardcoded to sqlite even if python-tdb is installed.
[19:32] <jelmer> maxb: sounds reasonable
[19:33] <jelmer> maxb: I wonder how useful it would be to have bzr-git on hardy if it's never been packaged for hardy though
[19:33] <maxb> great. This bzr-git/dulwich update has been an epic :-/
[19:34] <jelmer> maxb: is it really an update? have we ever hard bzr-git/dulwich available for hardy?
[19:34] <maxb> Well, we had previous versions in the PPA for hardy
[19:47] <jam> maxb, jelmer: Note that until fairly recently we still had production machines in LP on Hardy. However, they've all been transitioned to lucid, AFAIK
[19:48] <jam> I think LP itself went to lucid nov/dec last year
[19:48] <maxb> and there was much rejoicing :-)
[19:48] <jam> In Sept, there was "Don't use 2.6-isms because we are still running hardy"
[19:48] <jam> Oct 13th was the transition, it looks like
[19:49] <jam> anyway, that makes supporting Hardy much less interesting from at least Launchpad's standpoint
[19:50] <jelmer> maxb: that function in dulwich was never unit tested earlier
[19:51] <jelmer> maxb: (and bzr-git does its own patching of urlparse)
[19:52] <jam> mgz: do you need me to submit your non_ascii patch?
[19:53] <mgz> jam: I can do it. you have any opinion on whether it should have NEWS?
[19:53] <jam> it should have news
[19:53] <jam> I don't know that it merits whatsne
[19:53] <jam> whatsnew
[19:54] <mgz> will do that and push.
[19:54] <jam> Possibly, since it is a user-visible change, but definitely NEWS
[19:54] <jam> mgz: for your get_transport() change, this is all mechanical, right? You are just changing "from bzrlib.transport import get_transport" to "from bzrlib import transport"
[19:55] <mgz> it is.
[19:55] <mgz> diff in email is a little wrong because I suck, but I repushed the branch with a less screwed up first revision
[19:57] <jam> mgz: that one looks  fine to me as well
[20:15] <mgz> pushed the first one. I'll let vila look at the other in the morning if he likes before pushing.
[20:38] <sinzui> I am interested in getting https://bugs.launchpad.net/bzr-gtk/+bug/707482 fixed. Is anyone minding bzr-gtk about
[20:39] <poolie> hi mgz, sinzui
[20:40] <poolie> sinzui, it seems like you're most of the way there
[20:40] <sinzui> I can make this fix if someone agrees I am on the right path
[20:40]  * poolie looks
[20:41] <poolie> so which value is wrong?
[20:42] <poolie> i guess line_no?
[20:42] <sinzui> poolie: ganonnate's line_no and revno I think. UI is pretty simple, so changing the column types to int is probably right. Since gtktreeview reuses columns for layout when making a tree, casting to str() may be required
[20:42] <jam> hi poolie
[20:43] <poolie> sinzui, it's strange it's not failing before
[20:43] <poolie> i wonder if maverick's pygtk automatically casts or something?
[20:43] <poolie> i didn't think it did that
[20:44] <poolie> hi jam, how are you?
[20:44] <sinzui> pygtk 2.22+ behaves more like gtk
[20:44] <jam> poolie: doing well. Nice to see you online, though I worry it means you aren't sleeping all that well.
[20:44] <sinzui> poolie: There was a lot of implict goodness in pygtk that is lost as we gtk moves to 3 where there will be a standard api for all bindings
[20:45] <poolie> :) mm, i woke a bit before 7, which is pretty reasonable
[20:45] <poolie> sinzui, so, since i can't reproduce it, i suggest you change just lineno to type int and see what hapens
[20:45] <sinzui> poolie: but this brings up the crucial question what gtk and python is bzr-gtk targeting?
[20:45] <jam> strangely I've been waking up at just about exactly 6:51 since I got back. Not getting *up* mind you, but waking up.
[20:46] <jam> sinzui: we're certainly still targetting python 2 for the moment (unless you mean gtk v 3?)
[20:46] <sinzui> poolies casting with str() is very backward compatible with gtk2. changing the column types is not
[20:47] <poolie> ah
[20:47] <poolie> well, would we ever use a non-int line number?
[20:47] <sinzui> the early liststores had limited column types, which I believe is why the class uses just astring
[20:48] <sinzui> poolie: we care if we resorted the lines. We wont in this case
[20:51] <jam> I'm pretty sure line_no will always be an int, but revno will often be a str
[20:52] <jam> if it is hard to set a column type to int in older code, just go str, since as you mention, sort order doesn't matter
[20:55] <sinzui> thanks. I will put a branch together. I will also test the other widgets so that this class of error is fixed in a single effort
[20:59] <poolie> sinzui, ping me if you get stuck
[20:59] <sinzui> thanks
[21:00] <jam> poolie: have you seen the recent updates I did to the package-importer under-losa control discussion?
[21:00] <poolie> jam, can you join #ubuntu-meeting
[21:00] <poolie> no
[21:00] <jam> poolie: rt #39614 and bug #589521
[21:00] <jam> summarizes my thoughts on it
[21:01] <poolie> ok, thanks
[21:01] <jam> short summary is that it needs a fair amount of development done before we can really give up direct access
[21:01] <poolie> elliot's suggestion at dallas, which i agree with, is that we should do things ourselves rather than handing it over
[21:01] <jam> (and i wonder if that effort would be better spent integrating it with the vcs-import stuff)
[21:01] <poolie> i thought i said that's what we'd do, and we'll just rely on them for low-level stuff
[21:01] <poolie> keeping the os running etc
[21:02] <jam> poolie: note that both the bug and the rt have expanded from "nagios integration" into "move to a new server completely controlled by losas"
[21:02] <lifeless> giving up direct access is a bit separate :)
[21:02] <lifeless> (I'm lending support, I hope)
[21:02] <poolie> thanks for the pointer; i'll look at it
[21:03] <poolie> the udd meeting is starting now; let's be there
[21:03] <jam> lifeless: it is technically separate, but the discussion on the RT was that we don't want to integrate with nagios, we want to move you to a new server and take away all control. Not that it has to be done that way. :)
[21:04] <lifeless> so the new server thing
[21:04] <lifeless> thats because its on a borrowed box that is labelled 'landscape backup db server'
[21:15] <jam> oh, I understand why
[21:16] <jam> just mentioning that one rt got taken over by about 5 different things that they wanted to do
[21:19] <lifeless> :)
[22:12] <nhandler> So does anyone know why I am unable to push to lp:classbot/devel (on Launchpad) (doing so causes bzr to crash): ErrorFromSmartServer: Error received from smart server: ('error', "We are missing inventories for revisions: [StaticTuple('nhandler@ubuntu.com-20100920220053-yztqc4i042olpvnp',)]")
[22:13] <lifeless> poolie: I'd like to talk loggerhead (voice) a little when you have a timeslice spare
[22:13] <poolie> nhandler, at the broadest level i think someone has pushed bad data into it
[22:13] <poolie> lifeless, sure, let me finish things heer
[22:13] <james_w> IIRC that error is something to do with stacking
[22:14] <poolie> could it be renaming the stacked branch causes that?
[22:14] <poolie> :/
[22:14] <poolie> maybe we should ban that
[22:14] <james_w> nhandler, try "bzr pack lp:classbot/devel" and then try again
[22:14] <james_w> bug 437003
[22:15] <lifeless> I suspect an old bzr client actually
[22:15] <lifeless> we had some bugs in this area
[22:16] <nhandler> james_w: That did it. You rock! (but now I have no excuse for not fixing a few outstanding bugs in classbot ;) )
[22:16] <james_w> heh, we can probably break it again if you like ;-)
[22:17] <nhandler> james_w: Nah, that is alright. Thanks again.
[22:46] <jam> poolie, lifeless: bug 437003 covers it pretty well. It is autopack across pack files where the inventories aren't in the group being repacked.
[22:47] <jam> it is caused by stacking interacting oddly with autopack
[22:47] <jam> where you got the inventory in the past, but then get the revision, and then autopack without getting the original pack file in the group
[22:48] <lifeless> jam: is historydb optional in loggerhead?
[22:48] <jam> no
[22:48] <lifeless> poolie: ^
[22:48] <jam> you don't need the *plugin*
[22:48] <jam> but it changes how things are stored on disk
[22:48] <jam> you certainly could rewrite things until you got to that point
[22:49] <jam> but it isn't written that way
[22:52] <lifeless> jam: what I mean is
[22:52] <lifeless> jam: can trunk loggerhead be used with the performance profile of the loggerhead we use in lp
[22:53] <jam> lifeless: no
[22:53] <jam> which I tried to convey, but probably just got woryd
[22:53] <jam> wordy


[01:56] <mate|57617> hey there
[01:56] <mate|57617> installing this on an IBM T60 right now - pretty cool!
[02:32] <ibm> hey
[02:32] <Guest60801> hey
[02:32] <Guest60801> i just installed MATE on a new-to-me IBM T60!
[02:32] <Guest60801> what should i do with this bad boy?
[03:20] <jf_> help  how to change the screen resolution
[03:21] <jf_> help
[05:36] <liu> hi
[08:54] <makers> hello
[08:56] <makers> merry christmas
[09:55] <SuperEngineer>  Wishing you all a very peaceful & loving Doctor Who Christmas Special Day ;-)
[09:59] <ouroumov> Thanks SuperEngineer: you too!
[11:02] <LinuxNovice> hello...
[11:02] <LinuxNovice> I am new to Linux. Curious about Ubuntu Mate.
[11:03] <LinuxNovice> How is Mate different and better than other distros?
[11:05] <SuperEngineer> LinuxNovice: why not download it to a live usb/dvd and try it [run it from usb/dvd with no change to your system whatsoever..  If you you like it, that's why it's better.
[11:33] <LinuxNovice> hello..
[13:49] <crossy> Hi everybody. I just a Raspberry PI on the net
[23:33] <zachary> can i have some help ? my headphone jack isnt working on my rasberry pi
[23:53] <sixwheeledbeast> are you sure, what headphones are you using


[00:01] <pleia2> https://wiki.ubuntu.com/Xubuntu/Documentation needs some love, I don't really know how our docs work but it links to http://doc.ubuntu.com/xubuntu/ which is more than a little out of date
[00:01] <knome> mmh
[00:01] <knome> i rewrote:
[00:01] <knome> http://xubuntu.org/contribute/
[00:01] <knome> http://xubuntu.org/contribute/qa/
[00:01] <knome> and
[00:02] <knome> http://xubuntu.org/contribute/marketing/
[00:02] <knome> the other subpages are going to need love too
[00:02] <pleia2> ah, hadn't seen updated qa/ yet, I shall look
[00:02] <knome> those are pretty much "merges" of the website stuff + stuff on the wiki
[00:02] <knome> to be able to drop unnecessary duplicated info on the wiki
[00:03] <knome> eg. the Bugs subpage is probably unnecessary now
[00:03] <pleia2> based on feedback I got from charlie, /Testing on the wiki is more clear and should be accurate now
[00:03] <knome> aha
[00:03] <knome> since when?
[00:03] <pleia2> I made edits when I wrote the blog post
[00:04] <knome> mm-hmm
[00:04] <knome> that's not too bad
[00:04] <pleia2> we probably want to revisit it at the beginning of the next cycle though, once we trick someone into becoming the new testing lead :)
[00:04] <knome> and some of that should definitely stay there
[00:04] <knome> including the testers page and the testcases
[00:04] <knome> but the "how to start testing" stuff should mostly be in x.org, i think...
[00:04] <knome> as the same stuff for other teams
[00:05] <pleia2> yeah
[00:05] <knome> that way we have one place where we can point all new contributors
[00:05] <knome> and the wiki is for those who want to get started already
[00:05] <knome> probably "how to contribute" could be removed once we make sure all of it is in x.org
[00:06]  * pleia2 nods
[00:06] <knome> "projects" too, just link to the release schedule somewhere in the page :)
[00:10] <pleia2> knome: when we consider a replacement application, I'm assuming we just do a casual discussion on -devel rather than the more formal /ApplicationComparisonTemplate?
[00:11] <knome> well, it's good to have something formal to point to
[00:11] <knome> also, i think wiki is a good tool to compare applications and gather opinions
[00:11] <pleia2> that one's the first one listed on Old
[00:12] <knome> i know
[00:12] <knome> https://wiki.ubuntu.com/Xubuntu/Toolbox/SpecificationTemplate
[00:12] <knome> that's a bit less formal and scary template
[00:13] <pleia2> ah, good :)
[00:13] <knome> i tried to condense the stuff found on the other templates to that
[00:13] <knome> everybody can use common sense in deciding what should be covered
[00:13] <knome> btw, if you are okay with deleting the pages under XubuntuOld, feel free to do it right away :)
[00:14] <pleia2> seems to me the BugWatch stuff is much better being tracked on LP with bug importance and stuff (but I don't know the history there)
[00:14] <knome> yes, i agree with that
[00:14] <knome> that's why i wondered that we still did that for precise
[00:15] <knome> tbh, i didn't even know that page existed, so that's it for the watching part :)
[00:23]  * knome is still lurking
[00:23] <knome> https://twitter.com/#!/rreyes1979/status/186246528514539520
[00:35] <pleia2> I wonder if we should keep just one of these around https://wiki.ubuntu.com/Xubuntu/XubuntuOld/DocumentationHardyAssignments
[00:35] <pleia2> but again, I don't know about docs or how useful such a thing is
[00:35] <knome> well, i'm trying to get our whole documentation rewritten in Q
[00:36] <pleia2> I think we can delete everything else though
[00:36] <knome> well
[00:36] <knome> hmm
[00:36] <knome> the latest is from intrepid
[00:36] <knome> and that's just a really quick listing
[00:37] <pleia2> yeah, hardy is the one with stuff in it
[00:37] <knome> hardy... that doesn't look too extensive too
[00:37] <knome> *either
[00:37] <pleia2> whatever you think, I just think it may be useful for when we revive docs
[00:37] <pleia2> one of them anyway
[00:37] <knome> but those are all just sections in the offline docs?
[00:38] <knome> file:///usr/share/xubuntu-docs/index.html
[00:39] <pleia2> I think so, but the page has a framework for easy viewing of who is doing what
[00:39] <pleia2> which I think may have value
[00:39] <knome> if we want to assign things, that's fine
[00:39] <knome> i was thinking of a more collaborative approach with etherpad
[00:39] <knome>  -> paste the doc section to a pad
[00:39] <knome>  -> let people edit
[00:39] <knome> with some sprints, that should work pretty well
[00:39] <pleia2> ok :)
[00:40] <knome> and if we really need a table, we can just recreate
[00:40]  * pleia2 nods
[00:40] <knome> that's what i was thinking
[00:40] <pleia2> ok, delete 'em all!
[00:40] <knome> yay!
[00:41] <knome> wiki lags :D
[00:42] <knome> ok, done :)
[00:42] <knome> now we must only rewrite the pages
[00:43] <knome> https://wiki.ubuntu.com/Xubuntu/Cleanup
[00:44] <knome> pleia2, do you have an insight on the testers-page table?
[00:55] <pleia2> knome: not at the moment, I'll think
[00:55] <knome> thanks :)
[00:58] <knome> pleia2, btw, you might want to subscribe to Xubuntu/* at least temporarily as i go and change things here and there :)
[01:01] <knome> pleia2, https://launchpad.net/~xubuntu-doc
[01:01] <knome> pleia2, WOW!
[01:01] <knome> pleia2, we have that too?
[01:01] <knome> :)
[01:03] <knome> gah, the wiki is really slow
[01:04] <knome> pleia2, you there? quick question...
[01:05] <knome> pleia2, do we want to keep the meeting agenda archive?
[01:06] <knome> pleia2, i mean, they have *some* documentative value, but on the other hand, you will know what the agenda was when you look at the meeting minutes...
[01:07] <knome> pleia2, there is one agenda in 2010, two in 2009, and three in 2008, rest are older
[01:07] <pleia2> yeah, keep the archive
[01:07] <knome> really?
[01:07] <pleia2> yes, everyone does
[01:07] <knome> i'm not deleting the *minutes* archive
[01:07] <knome> i'm talking about *agenda* archive
[01:07] <knome> which we haven't updated in over a year
[01:07]  * pleia2 shrugs
[01:08] <pleia2> I guess that's ok then :)
[01:08] <knome> ok, good
[01:10] <knome> the wiki is lagging again :(
[01:10] <pleia2> it does that
[01:10] <knome> okay, agenda archive deleted
[01:10] <knome> now i could fix the archive frontpage and go to sleep :)
[01:11] <pleia2> :)
[01:22] <knome> everything under Xubuntu/Archive/Minutes/ could now be moved directly under Xubuntu/Archive/ :)
[01:25] <knome> https://wiki.ubuntu.com/Xubuntu/Meetings/Archive is updated
[01:25] <knome> and i'm off to bed
[01:25] <pleia2> good night!
[01:25] <knome> see you later! :)
[01:25] <knome> good day+night to you too :)
[01:26] <Unit193> Adios.
[01:43] <pleia2> the wiki fails at subscribing me to more than a single page at once
[01:44] <Unit193> I think the first three words said it all.
[01:45] <pleia2> :P
[07:17] <knome> pleia2, hmm?
[07:17] <knome> pleia2, "Xubuntu/.*"
[07:17] <knome> pleia2, without quotes, add that to your subscription box
[07:18] <pleia2> knome: I know how to add it :) I'm saying it doesn't work
[07:18] <knome> :o
[07:19] <knome> i didn't know the . -trick
[07:19] <knome> until recently
[07:19] <knome> weird then
[07:19] <pleia2> I've known this for a while, tried subbing to UbuntuWeeklyNewsletter/.* a few months ago
[07:19] <knome> :/
[07:26] <pleia2> ok, sleepies time
[07:28] <knome> nighty
[10:49] <knome> starting to wrap up the "rebase" thing
[10:50] <knome> https://twitter.com/#!/XubuntuLinux/status/186404591208898561
[13:58] <astraljava> Soo... how do I make the window borders easier to grab? They're way, way too thin at the moment.
[14:01] <Pjotr> Hello, I have a question about the Abiword package for Xubuntu Precise.
[14:01] <Pjotr> Upstream, some overdue translations have been commmitted for Abiword 2.9.x: http://www.abisource.com/contribute/translate/
[14:01] <Pjotr> Will they make it into Xubuntu Precise?
[14:04] <astraljava> I guess an FFe bug could be filed against it, it could be possible, but I'm not an expert WRT translations.
[14:05] <astraljava> Pjotr: Give me 2 hours, I'm in the middle of a hockey game. :)
[14:06] <Pjotr> astraljava: OK, thanks in advance.... good luck with the hockey!  :-)
[14:07] <astraljava> Pjotr: No worries, would be good to get it in for an LTS. Thanks, neither of them are 'my teams', but then... it's hockey, after all. :)
[14:58] <knome> afaik the translations deadline didn't pass yet
[15:01] <astraljava> knome: Oh, cool. So just a debdiff for mr_pouit or micahg would suffice, no?
[15:06] <knome> i suppose, but ask -release first ;)
[15:27] <astraljava> Well, it's no biggie. I will have to create the debdiff anyhoo, so filing an FFe bug is just one more step.
[15:31] <pleia2> quite the extensive april foolery on G+ (I didn't post it, but I let my co-maintainer in on the joke and he wrote a whole intro for knome's post
[15:32] <pleia2> knome: btw, you can click on the timestamps in the logs to get more precise links
[15:32] <pleia2> http://irclogs.ubuntu.com/2012/03/31/%23xubuntu-devel.html#t20:37
[15:34] <pleia2> oh my, the DPL retweeted
[15:37] <astraljava> ochosi: knome: No idea about the window border thingie? My google-fu seems to suggest it's theme-related, but I have virtually no knowledge about them.
[17:09] <knome> pleia2, didn't know that :)
[17:13] <knome> aaaanyway, https://twitter.com/#!/XubuntuLinux/status/186501460773707776
[17:22] <knome> (opme
[17:22] <knome> er
[18:08] <knome> astraljava, hmm, what issue?
[18:09] <BufferOverflow> Corners to resize too small.
[18:09] <BufferOverflow> IIRC.
[18:09] <knome> alt+right-mouse-drag.
[18:09] <astraljava> Ahh... cool, didn't know that.
[18:09] <astraljava> Thanks!
[18:09] <knome> np
[18:10] <knome> astraljava, maybe you SHOULD be following @XubuntuLinux, that tip was posted there
[18:10] <astraljava> But that's _SOCIAL_, I don't do that.
[18:10] <knome> i don't do that personally either. i lurk behind the @XubuntuLinux-account.
[20:34] <astraljava> Whee. ssh transfer between a Studio precise box and a Xubuntu precise box was interrupted due to a corrupt packet. *facepalm*


[13:25] <cmaloney> morning
[14:46] <jrwren> https://www.youtube.com/watch?v=Xtu-w28cbbI&feature=youtu.be if you are retro computer nerd you might like
[14:47] <jrwren> it is live streaming https://www.kansasfest.org convention for apple 2
[14:53] <cmaloney> I think there was also the vintage compute festival that either did or was doing something similar
[15:31] <_stink_> fun!
[22:05] <Scary_Guy> https://www.youtube.com/watch?v=Xtu-w28cbbI&feature=youtu.be
[22:08] <Scary_Guy> Oops, didn't realise I pasted into the wrong channel, disregard
[22:13] <Scary_Guy> Also I like how they spent the first 40 someodd minutes trying to figure out how to use Zoom.  Also, shame on them for using Zoom
[22:32] <_stink_> is the Apple II client for zoom secure? :D


[08:07] <wers> hello everyone :)
[09:31] <jdifool> hi there*
[09:32] <jdifool> I'm trying to build up slackware packages for the whole indicator group
[09:34] <jdifool> I'm facing two different problems
[09:37] <jdifool> the main one being the compilation of Nunit which is needed for indicator-application
[09:37] <jdifool> if someone can point me towards a way to get Nunit to compile on Linux...
[09:37] <jdifool> thanks in advance
[15:06] <seb128> qense, hi
[15:09] <qense> hello seb128
[15:54] <hyperair> tedg: ping.
[16:01] <tedg> Howdy hyperair
[16:01] <hyperair> tedg: howdy.
[16:01] <hyperair> tedg: so anyway i've been poking aroudn appindicator-sharp, and the issue seems to be that you've incremented the AssemblyVersion to 0.1
[16:02] <hyperair> however, you didn't break ABI, and you didn't change the package name, so this is equivalent to a no-ABI-break SONAME bump, but without changing the package name.
[16:03] <hyperair> i.e. now libraries looking for 0.0 can't find it in the GAC, because it got replaced by 0.1
[16:03] <hyperair> er sorry i meant applications
[16:03] <tedg> hyperair, Oh, I think the issue is that we've got too many c files in the gapi-parser: https://code.edge.launchpad.net/~ted/indicator-application/mono-bindings-startup
[16:03] <hyperair> tedg: no, i don't think that's the issue.
[16:04] <tedg> hyperair, I think the versions were the same, right?  I thought we just moved files and names packages correctly there.
[16:04] <hyperair> tedg: i've run mono-api-check
[16:04] <hyperair> the versions are different.
[16:04] <tedg> Hmm, I've rebuilt with that and I get Tomboy working :)
[16:04] <hyperair> indeed, you should
[16:04] <tedg> Is it because I rebuilt Tomboy?
[16:04] <hyperair> yes.
[16:04] <hyperair> and because you're using upstream sources, i should think
[16:04] <hyperair> the one in maverick is screwed
[16:05] <hyperair> because you moved everything back to 0.0
[16:05] <hyperair> but didn't move the pkg-config file
[16:05] <hyperair> i mean the pkg-config file still spits out -r/usr/lib/cli/appindicator-sharp-0.1/...
[16:05] <tedg> Hmm, shouldn't everything be going to 0.1 ?
[16:06] <hyperair> tedg: your packaging shoved everything back into 0.0
[16:06] <hyperair> which is what's wrong.
[16:06] <hyperair> tedg: another thing is, since ABI wasn't broken, you should add a policy.appindicator-sharp.config or something
[16:06] <hyperair> that maps 0.0-0.1 => 0.1
[16:07] <hyperair> er policy.2.0.appindicator-sharp.config
[16:08] <hyperair> it should also be compiled into a dll using al2 -keyfile:somethignorother.snk policyblahblah.config
[16:08] <hyperair> and gacutil -i'd
[16:08] <tedg> Hmm, you're loosing me a little bit there.
[16:09] <tedg> I'm not sure how to map the policy there.
[16:09] <hyperair> okay, let me go through this, looking only at the upstream situation first.
[16:09] <hyperair> appindicator-sharp in trunk now has AssemblyVersion=0.1
[16:10] <hyperair> however, there is no ABI break between appindicator-sharp <IP_ADDRESS> and appindicator-sharp <IP_ADDRESS>
[16:10] <hyperair> hence, applications which linked against apindicator-sharp <IP_ADDRESS> should be able to use appindicator-sharp <IP_ADDRESS> no problem, without recompiling
[16:10] <tedg> Okay, so how do I tell Mono that?
[16:11] <hyperair> there is a way to tell mono that when things look for appindicator-sharp <IP_ADDRESS>, use the appindicator-sharp <IP_ADDRESS> dll, because it'll be fine.
[16:11] <hyperair> that's using the policy file
[16:11] <hyperair> i've written one
[16:11] <hyperair> give me a moment ot pastebin it
[16:12] <hyperair> http://paste.debian.net/77917/
[16:13] <tedg> Okay.  Why is it 0.0-@ASSEMBLY_VERSION@ ?
[16:13] <tedg> Shouldn't it be <IP_ADDRESS> ?
[16:14] <tedg> And how do I generate "publicKeyToken" ?
[16:16] <hyperair> tedg: i got that from your snk file
[16:17] <hyperair> http://paste.debian.net/77919/
[16:17] <hyperair> see
[16:17] <tedg> hyperair, Oh.  I thought that was the example.
[16:17] <tedg> Should that be generated in the build?
[16:18] <hyperair> well, you can
[16:18] <hyperair> it's up to you really, how much to generate
[16:18] <hyperair> what it *should* end up with currently is... ASSEMBLY_NAME=appindicator-sharp, and ASSEMBLY_VERSION=0.1
[16:18] <hyperair> after that, you compile it with al2
[16:18] <hyperair> or $(AL) really
[16:19] <hyperair> al works too
[16:19] <hyperair> seems it's symlinked
[16:20] <hyperair> $(AL) -link:policy.$$i.config -out:policy.$$i.$(ASSEMBLY_NAME).dll -keyfile:$(top_srcdir)/mono-addins.snk;
[16:21] <hyperair> that's how it was done in mono-addins
[16:21] <tedg> hyperair, Where $$i is appindicator-sharp?
[16:21] <hyperair> in appindicator-sharp's case, it can be done with $(AL) -link:policy.2.0.appindicator-sharp.config -out:policy.appindicator-sharp.dll -keyfile appindicator-sharp.snk
[16:22] <hyperair> tedg: ^
[16:23] <hyperair> $$i = 2.0,  i.e. the .NET version, afaik
[16:23] <tedg> hyperair, Okay.  And where do I put policy.appindicator-sharp.dll ?
[16:26] <hyperair> tedg: in the same directory as appindicator-sharp.dll
[16:26] <hyperair> tedg: and gacutil the dll
[16:28] <hyperair> tedg: once that's all done, there are the downstream changes: libappindicator0.0-cil must be renamed to 0.1
[16:29] <tedg> hyperair, Okay.  Let me see if I can get this working first :)
[16:31] <htorque> hello, how can i change the font size in the une panel? after an update it changed to super-small
[16:34] <kenvandine> tedg, sorry... afk for a few... bbiab
[16:37] <tedg> kenvandine, np
[16:37] <tedg> htorque, It should be the same as the application font... but I've not played with UNE much.
[16:37] <hyperair> tedg: sure. if you've got any further troubles please ask
[16:37] <tedg> njpatel would be the guy to ask -- but he's not here right now.
[16:38] <htorque> tedg, thanks! after a unity crash it's back to normal - very strange
[17:06] <tedg> hyperair, Could you look at this branch and see if it matches what you were thinking?  https://code.launchpad.net/~ted/indicator-application/mono-version-agreement
[17:09]  * hyperair checks
[17:10] <hyperair> that would be... lp:~ted/indicator-application/mono-version-agreement, right?
[17:15] <tedg> hyperair, Yup
[17:15]  * hyperair branches
[17:49] <hyperair> tedg: i think you need to use sed instead of just "cp" re: generation of the policy.2.0.appindicator-sharp.config from the .config.in
[17:49] <hyperair> the @ASSEMBLY_*@ things need replacement
[17:49] <tedg> hyperair, Ah, okay.
[17:49] <tedg> hyperair, I wasn't sure if the al tool did that.
[17:50] <hyperair> hmm what's this gtk-doc that autogen  complains about?
[17:53] <tedg> hyperair, It's used to generate the API documentation.
[17:53] <tedg> hyperair, Should ASSEMBLY_VERSION be "0.1"?
[17:54] <hyperair> tedg: yes.
[17:55] <hyperair> tedg: it should follow whatever's inside AssemblyInfo.cs
[17:55] <hyperair> tedg: if you ever break ABI, then the "0.0" bit needs to be changed.
[17:55] <tedg> hyperair, How about we just don't break ABI ;)
[17:56] <hyperair> tedg: that's ideal, of course ;-)
[17:56] <tedg> Okay, pushed the sed stuff.
[17:57]  * hyperair fetches
[18:06] <schmichael> Hi all, I'm a python web dev looking to make a fairly simple app that displays notifications popups and allows a user to take an action...
[18:07] <schmichael> ...I was assuming the correct route to go is via appindicator and the existing messaging appindicator, but I'm having trouble figuring out how to hook everything up.
[18:07] <schmichael> I'm looing at gwibber's source, but that's a bit daunting
[18:08] <schmichael> hm, reading this now: https://wiki.ubuntu.com/MessagingMenu#API
[18:10] <tedg> schmichael, Well, it would depend on what you're representing.  Would it qualify as a "human-to-human" message?
[18:11] <tedg> schmichael, That's all that should be in the messaging menu
[18:11] <schmichael> hm, I suppose not necessarily
[18:11] <schmichael> more like e-mail
[18:11] <schmichael> where it's human-or-app to human recipient
[18:12] <tedg> Well, as long as it's more like Twitter feeds, I think you're probably good.
[18:12] <tedg> Where they can be both.
[18:13] <hyperair> tedg: DLLPOLICY = policy.2.0.$(ASSEMBLY)
[18:13] <hyperair> tedg: and add gacutil calls for the policy dll into (un)install-data-hook
[18:14] <hyperair> then i think it should be good to go
[18:14] <tedg> schmichael, http://bazaar.launchpad.net/~indicator-applet-developers/libindicate/trunk/annotate/head:/examples/im-client.py
[18:15] <schmichael> tedg: interesting. thanks
[18:55] <schmichael> Just got my app to add menu items based on methods called via dbus, very excited :)
[18:58] <schmichael> So I'm using appindicator currently for my tray icon. Is pynotify the preferred way to raise notifications from python?
[19:01] <tedg> schmichael, Ah, cool.  You can use the appindicator python library if you want, that might make it easier.  It hides the dbus parts.
[19:01] <tedg> schmichael, Yes, pynotify works.
[19:01] <tedg> hyperair, I can't figure out how to get it to uninstall :(
[19:01] <tedg> hyperair, Let me push what I have.
[19:06] <hyperair> tedg: just copy paste whatever you had?
[19:06] <tedg> hyperair, Sadly doesn't seem to work.
[19:06] <tedg> hyperair, It doesn't seem to find the policy files.
[19:06] <hyperair> hmm weird.
[19:06] <hyperair> did it even install?
[19:06] <hyperair> well let me pull and see
[19:06] <tedg> Yeah, it installs.
[19:07] <schmichael> tedg: hm, indicator.notify('foo') just gives me an error
[19:07] <schmichael> Warning: IA__g_object_notify: object class `AppIndicator' has no property named `message'
[19:07] <schmichael> where 'message' is what I pass to notify
[19:07] <tedg> schmichael, The AppIndicator library isn't for notifications -- it's for putting icons in the panel.
[19:07] <tedg> schmichael, And attaching menus for them.
[19:07] <schmichael> ah, sorry
[19:08] <schmichael> thought you had said I could use it for notifications too
[19:08] <schmichael> k
[19:08] <schmichael> will use pynotify then
[19:08] <tedg> schmichael, You'll still want pynotify for the notifications.
[19:08] <schmichael> thanks!
[19:08] <tedg> np
[20:07] <hyperair> tedg: er sorry, looks like it was supposed to be policy.$(ASSEMBLY_VERSION).appindicator-sharp.{config,dll}
[20:08] <tedg> hyperair, Okay, cool.  Let me try that.
[20:11] <hyperair> still doesn't get uninstalled.
[20:11] <hyperair> hmmmm
[20:15] <hyperair> tedg: aha. during the uninstall call, you need to give the assembly name, not the dll name.
[20:15] <hyperair> tedg: DLLPOLICY has .dll stuck on
[20:15] <tedg> hyperair, Ah, okay.
[20:20] <tedg> hyperair, Okay, it distchecks now.  Can you pull and make sure it looks right?
[20:20] <hyperair> okay
[20:36] <hyperair> tedg: i think the policy.*.config file should also be installed to /usr/lib/cli/appindicator-sharp-0.1/
[20:39] <hyperair> tedg: Failure adding assembly policy.0.1.appindicator-sharp.dll to the cache: The system cannot find resource policy.0.1.appindicator-sharp.config <-- this will happen when using the debian packaging without the .config file included, because the libraries are added into the GAC during a postinst script.
[20:39] <hyperair> to get that message, i just deleted the .config file and tried adding the .dll
[20:40] <tedg> hyperair, Okay, I added that to the TARGET
[20:41]  * hyperair tests
[20:43] <hyperair> okay, it's good =
[20:43] <hyperair> =)
[20:45] <tedg> hyperair, Cool.  Thanks!
[20:45] <tedg> hyperair, No what do I need to do to the packaging?
[20:45] <tedg> Now
[20:46] <hyperair> rename the libappindicator0.0-cil package to libappindicator0.1-cil
[20:46] <hyperair> also, change the .install file to not install to a separate location
[20:46] <hyperair> currently it takes things installed in /usr/lib/cli/blahblah-0.1 and installs it itno /usr/lib/cli/blahblah-0.0
[20:47] <tedg> Ah, okay.  Yes.
[20:47] <hyperair> and then add the policy.whatever.dll to the .installcligac file
[21:14] <tedg> hyperair, Hmm, I didn't do something right -- Tomboy still can't find it :(
[21:15] <tedg> The packaging branch I'm using is here: lp:~indicator-applet-developers/indicator-application/ubuntu/
[21:15] <tedg> The policy file got into the package and looks correct.
[21:15] <tedg> I'm not sure what else to check.
[21:16] <hyperair> did it get into the gac?
[21:16] <hyperair> gacutil -l | grep appindicator
[21:17] <tedg> appindicator-sharp, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=bcae265d1c7ab4c2
[21:17] <tedg> policy.0.1.appindicator-sharp, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=bcae265d1c7ab4c2
[21:17] <tedg> Seems like it should be in the gac as "appindictor-sharp", eh
[21:17] <tedg> ?
[21:25] <hyperair> tedg: is it not appindicator-sharp already?
[21:25] <hyperair> tedg: can you give me tomboy's backtrace?
[21:25] <tedg> hyperair, Well there's two lines.  One for appindicator-sharp and one for policy*.  It seems they should be appindicator-sharp.
[21:25] <hyperair> no, it's correct that way.
[21:26] <hyperair> appindicator-sharp is already appindicator-sharp
[21:26] <hyperair> the policy one is registered and treated differently -- it provides the mapping from 0.0-0.1 => 0.1
[21:26] <tedg> http://pastebin.ubuntu.com/451763/
[21:29] <hyperair> urgh, how weird.
[21:31] <hyperair> hmm i just got an idea.
[21:32] <hyperair> can you try changing these things: oldVersion="<IP_ADDRESS>-<IP_ADDRESS>" and newVersion="<IP_ADDRESS>"
[21:32] <hyperair> seems that it might need the full version in the policy file after all.
[21:40] <hyperair> tedg: ^
[21:45] <tedg> hyperair, k, just a second
[21:46] <hyperair> sure
[21:51] <tedg> hyperair, Hmm, nope, that didn't help.
[21:51] <hyperair> =\
[21:51] <hyperair> did you regenerate the dll?
[21:53] <tedg> Yeah, I rebuild the package.
[21:53] <tedg> rebuilt
[22:39] <hyperair> tedg: aha. the weird version that's stuck onto the policy.${VERSION}.appindicator-sharp.{config,dll} should be for the version of the assembly it's applying to (i.e. in order to map 0.0 => 0.1, it needs to ${VERSION} in this case needs to be 0.0)
[22:40] <tedg> hyperair, Ah, okay.
[22:41] <hyperair> sorry for leading you on a wild goose chase =(
[22:41] <tedg> Let me try it.
[22:46] <hyperair> it works this time with bce at least.
[22:46] <hyperair> i mean banshe
[22:50] <hyperair> Replaces: libappindicator0-cil (<= 0.0.19-0ubuntu4~)
[22:51] <hyperair> er whoops
[22:51] <hyperair> wait a sec.
[22:51] <hyperair> tedg: i think the ~ is unnecessary.
[22:52] <hyperair> it's generally used for >= relations to include backports of the version, or << to exclude backports of that particular version, but in the case of <=, it'll miss out on 0.0.19-0ubuntu4.
[22:53] <hyperair> also i think the previous package name was libappindicator0.0-cil
[22:54] <tedg> hyperair, Hmm, the change to 0.0 didn't seem to help :(
[22:54] <tedg> I'll fix the version.
[22:54] <hyperair> http://paste.debian.net/77952/
[22:55] <hyperair> tedg: i did that ^^, and renamed the policy.0.1.blah.in
[22:57] <tedg> hyperair, Hmm, I did the same...
[22:57] <hyperair> weird.
[22:57] <hyperair> try purging and trying again?
[23:05] <hyperair> libappindicator0.1-cil should also Provides: libappindicator0.0-cil
[23:05] <hyperair> i think.
[23:05] <tedg> Ah, I was just about to ask that :)
[23:06] <tedg> I think that might be the issue as I have a libappindicator0.0-cil installed on my system.
[23:06] <tedg> Anyway, I need to run.  I try that later.  Thanks for your help hyperair!


[00:16] <RAOF> Maybe they're getting the patch? It's not particularly invasive.
[00:17] <RAOF> Alternatively: maybe they're not supporting EGL on mirclient? The only components which need mirclient are the various lomiri infrastructures, and they're going to be reasonably happy with a software renderer.
[02:49] -GitHub[m]:#mir-server- **[MirServer/mir]** RAOF opened [pull request #2747](https://github.com/MirServer/mir/pull/2747): cmake: Fix ptest target... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/0be3de2576a23b8f1511d76a04d43087e7ea99ec>)
[03:00] -GitHub[m]:#mir-server- **[MirServer/mir]** RAOF edited [pull request #2744](https://github.com/MirServer/mir/pull/2744): Add core mmap-backed SHM handling
[04:13] -GitHub[m]:#mir-server- **[MirServer/mir]** RAOF assigned  to [pull request #2747](https://github.com/MirServer/mir/pull/2747): cmake: Fix ptest target
[08:13] <Saviq> Good weekend o/
[08:19] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq opened [issue #2748](https://github.com/MirServer/mir/issues/2748): wlcs.Anchor/LayerSurfaceLayoutTest.is_positioned_to_accommodate_other_surfaces_exclusive_zone unstable... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/a637038f101c14ce3b0a04ba771cc0d43c88524e>)
[08:20] <Saviq> Good morn'
[09:06] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq requested a review from AlanGriffiths for [pull request #2744](https://github.com/MirServer/mir/pull/2744): Add core mmap-backed SHM handling
[09:49] <alan_g[m]> Saviq, if you want to fixup #2747 we can land it and the follow-on
[09:49] <Saviq> Sure, I can
[09:50] <alan_g[m]> I'll poke at #2748
[15:19] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths opened [pull request #2749](https://github.com/MirServer/mir/pull/2749): Fix race... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/2c6954f1014175e57bacba99d79fccd49a5cccdb>)
[15:33] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq requested a review from wmww for [pull request #2749](https://github.com/MirServer/mir/pull/2749): Fix race
[15:49] -GitHub[m]:#mir-server- **[MirServer/wlcs]** AlanGriffiths drafted [pull request #257](https://github.com/MirServer/wlcs/pull/257): test
[15:50] -GitHub[m]:#mir-server- **[MirServer/wlcs]** AlanGriffiths edited [pull request #257](https://github.com/MirServer/wlcs/pull/257): test
[17:09] <Saviq> Good night o/
[17:12] <grayson-g[m]> Does anyone know where touch scrolling is implemented? I'm working on the touch drag code right now and it prioritizes scrolling over starting a drag event.
[17:13] <alan_g[m]> In the client toolkit?
[17:18] <grayson-g[m]> alan_g[m]: Thanks! Poking around right now.
[20:46] <sophie-w> There's no guarantee that clients implement touch drag and drop
 "There's no guarantee that..." <- Huh, sure enough I can't drag on Weston with touch in either Firefox or Chrome. Reading over the specification for `wl_data_device`, it *never mentions* touch. I wonder if any clients have it implemented 🤔
[21:06] <grayson-g[m]> > <@wmww:matrix.org> There's no guarantee that clients implement touch drag and drop
[21:06] <grayson-g[m]>  * Huh, sure enough I can't drag on Weston with touch in either Firefox or Chrome. Reading over the specification for `wl_data_device`, it _never mentions_ touch with regard to drag-and-drop. I wonder if any clients have it implemented 🤔
[21:07] <grayson-g[m]> grayson-g[m]: In fact, `wl_data_device::enter` explicitly describes its x and y arguments as "the position of the pointer." huh
[21:24] <grayson-g[m]> I feel like this means I should remove all touch-related logic from drag-and-drop. Any differing opinions?
 "I feel like this means I..." <- Oh, wow. GTK's touch support is surprisingly poor.
[22:18] <RAOF> RAOF: That's a +1 on removing touch-related logic from drag&drop.
[23:29] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2743](https://github.com/MirServer/mir/pull/2743): Drop server/graphics/gl_extensions_base.cpp; it's dead code


[13:21] <ion> keybuk: Feel like merging my mountall changes? :-) I could rebase the patch set on to the current mountall source package later today, but there are probably no conflicts.
[13:22] <Keybuk> ion: am going to merge after alpha 6 is out
[13:22] <ion> Alright
[19:58] <pocek> Hi
[19:59] <sadmac2> hello
[20:05] <pocek> How's upstart 1.0 going? I watched fosdem video and it seems really promising :)
[20:05] <sadmac2> its going'
[20:09] <sadmac2> pocek: are you on the mailing list?
[20:12] <pocek> Just subscribed
[20:12] <sadmac2> pocek: well that's the place to be
[20:13] <sadmac2> I'll probably shoot another braindump towards scott tonight
[20:14] <Keybuk> \o/
[20:15] <sadmac2> Keybuk: celebrating my braindump or have you done wonders?
[20:16] <Keybuk> celebrating your brain dumps
[20:16] <Keybuk> I like them
[20:16] <sadmac2> sweet
[20:16] <Keybuk> for a start, they help me actually work out what *I* mean sometimes :p
[20:16] <Keybuk> plus you have lots of ideas
[20:16] <sadmac2> Keybuk: I got a bit sidetracked last night in my coding. Long story short libnih is about to grow a non-deterministic RE language parser to replace nih_config :)
[20:16] <sadmac2> Keybuk: bison was inadequate, so I'm writing us our own.
[20:17] <Keybuk> heh
[20:17] <Keybuk> I'm clearly rubbing off on you ;)
[20:17] <ion> :-)
[20:17] <Keybuk> "why use this pre-canned library when I COULD WRITE MY OWN!" :p
[20:18] <ion> sadmac: Have you looked at PEGs?
[20:18] <ion> http://treetop.rubyforge.org/ as an example project implementing PEG.
[20:18] <ion> They have some pros and some cons.
[20:22] <sadmac2> ion: I spent a good few hours trying to get my hands on any parser generators I could find. Didn't find those.
[20:23] <sadmac2> ion: the big thing we need is a non-deterministic lexer. For example: "start on start". The same token has two different meanings in that stanza.
[20:24] <sadmac2> Its a keyword, and then later its an unquoted string.
[20:24] <ion> PEG should handle that fine
[20:24] <ion> Without any extra effort.
[20:25] <sadmac2> ion: the other thing I wanted (more of a nice-to-have) is expressions that take arguments. Its good for things like this:
[20:25] <sadmac2> opstring(SEP) ::= event SEP OPERATOR SEP event
[20:26] <sadmac2> on_opstring ::= opstring(NONBREAKING_SPACE)
[20:27] <sadmac2> event ::= event_spec | '(' opstring(BREAKING_SPACE) ')'
[20:27] <ion> Please give an example of a chunk to be parsed by that.
[20:27] <sadmac2> the being-nested-makes-linebreaks-ok thing is really annoying in bison
[20:27] <ion> Ah
[20:28] <sadmac2> ion: surely. "start on a and (b or \n c) \n start on a and b or \n c"
[20:28] <ion> Yeah, got it
[20:28] <sadmac2> ion: the \ns are linebreaks
[20:28] <sadmac2> ion: the second line there should be an error
[20:28] <sadmac2> ion: the first should be fine
[20:29] <sadmac2> its less of a pain to do conventionally when you don't have big chunks of identical handler code for each version of opstring
[20:30] <sadmac2> that grammar was kinda fudgy
[20:32] <sadmac2> opstring(SEP) ::= event | opstring(SEP) SEP OPERATOR SEP opstring(SEP) | '(' opstring(BREAKING_SPACE) ')'
[20:32] <sadmac2> on_opstring ::= opstring(NONBREAKING_SPACE)
[20:32] <sadmac2> much better.
[20:32] <sadmac2> BNF is hard, lets go shopping
[20:41] <sadmac2> ion: implementing these can't be easy, and ruby isn't a good libnih dependency :)
[20:42] <ion> As i said, it’s just an example implementation. One is free to implement PEG without such dependencies.
[20:46] <sadmac2> ion: yeah, I just wonder what it would take to do in C :)
[20:46] <sadmac2> ion: right now the plan is just to use C syntax and express it that way.
[20:49] <sadmac2> with hopes of then bootstrapping the specification of a better grammar through that later on.
[20:50] <ion> Extending e.g. Treetop’s ‘rule’ element with parameters (as you described) would be very natural in fact. If one is to implement PEG in C, passing the separator as a parameter wouldn’t be the hard part. :-)
[20:51] <ion> Pseudo-treetopish-code:
[20:51] <ion> On a second thought, i’ll write this to pastebin. Moment.
[20:57] <ion> Something like http://pastebin.com/f79d84635
[20:58] <sadmac2> ion: I'm so used to people bending ruby into dsls that I keep trying to think how this still constitutes valid ruby :)
[20:59] <ion> PEG consumes input greedily, just like a regexp, without a need for separate tokenization. PEG can be thought of as an extended regexp that supports giving names to chunks and calling them by names (and recursion comes with that).
[20:59] <ion> That’s not Ruby. That’s Treetop grammar syntax.
[20:59] <sadmac2> ion: yeah
[21:04] <ion> Say, begin with a plain regexp:
[21:04] <ion> hello\s+[a-zA-Z0-9]+
[21:04] <ion> Give it a name:
[21:04] <ion> hello_stanza := hello\s+[a-zA-Z0-9]+
[21:05] <ion> Split it to parts and give them names:
[21:05] <ion> hello_stanza = 'hello' whitespace name; whitespace := \s+; name := [a-zA-Z0-9]+
[21:05] <ion> And implement support for recursion. There’s your basic PEG parser.
[21:05] <ion> Just a regexp engine extended a bit.
[21:06] <sadmac2> ion: sounds nice.
[21:06] <sadmac2> ion: I may do that.
[21:06] <sadmac2> ion: I could probably extend glibc regexen to do most of it for me too
[21:07] <ion> And as for precedence, it’s greedy just like regexps: the first matching tree is the one it picks.
[21:08] <ion> Want anything in parenthesis to have precedence over an and expression, and that to have precedence over an or expression? Give them in that order:
[21:08] <ion> event_spec := '(' event_spec ')' | event_spec sep 'and' sep event_spec | event_spec sep 'or' sep event_spec | event;
[21:08] <ion> or something along those lines.
[21:09] <ion> The regexp engine looks at the next character. Is it '('? Nope? Then look at the next alternative. Just like a plain regexp such as /\(foo\)|alternative|another/
[21:10] <ion> PEG does have some disadvantages: http://en.wikipedia.org/wiki/Parsing_expression_grammar#Disadvantages
[21:21] <sadmac2> ion: searching the fedora repos for peg gives me every mpeg and jpeg tool or library ever written
[21:21] <ion> http://piumarta.com/software/peg/
[21:21] <sadmac2> ion: I was just about to link you the same thing
[21:21] <ion> Search for \<peg\> or \bpeg\b, depending on the regexp dialect of rpm or whatever. :-P
[21:22] <ion> (No PEG results in Ubuntu, though.)
[21:23] <sadmac2> ion: this looks new, and reeks of next months abandonware
[21:23] <ion> He has bothered to write an extensive manual, that tells something. :-) http://piumarta.com/software/peg/peg.1.html
[21:24] <sadmac2> Keybuk: care to weigh in with preferences?