[06:55] <Unit193> geary 0.8.2-1  uploaded by Vincent Cheng (vcheng) https://tracker.debian.org/geary  ;P
[07:31] <dkessel> bluesabre: OK thanks :) I can always use a PPA for testing, so no h
[07:31] <dkessel> +hurries about releasing
[09:40] <ochosi> bluesabre: quick reminder: please schedule our next meeting
[09:40] <ochosi> elfy: re: blanking, ok, we can debug that together a bit
[09:40] <elfy> hi ochosi 
[09:41] <ochosi> morning
[09:41] <elfy> I'm not *that* concerned if it's just me - just seems a bit odd is all :)
[09:42] <ochosi> yeah, but it's been a recurring issue and i guess it needs to be addressed in xfpm
[09:42] <ochosi> quite annoying, because generally this is a really simple thing
[09:43] <ochosi> it's possible that xfpm gets loaded before the X defaults are set in the session, so it gets overridden
[09:43] <ochosi> but that's just a theory
[09:44] <elfy> ochosi: no - it appears to happen during a session - not at the start
[09:44] <ochosi> hm
[09:44] <ochosi> how do you know it happens during the session?
[09:44] <elfy> because terminal echoes the xset-q reading for me :)
[09:45] <elfy> I'll start the machine in the morning and come back during the day - screen not blanked, then *later* it suddenly does 
[09:46] <elfy> which is why I'm looking for some sort of logging of what's going on with that - I could at least then try and narrow it down a bit to other things happening at the same time
[09:46] <elfy> anyway - off to wrk for a bit now - cya later
[09:47] <ochosi> mm, that'd be great (narrowing it down)
[09:47] <ochosi> maybe there are some apps you're using that are tampering with the setting?
[09:47] <ochosi> since it's a generic X11 setting, any app can basically access/change it
[09:48] <ali1234> http://codesearch.debian.net/search?q=xset+s
[09:49] <ali1234> http://codesearch.debian.net/search?q=XSetScreenSaver
[09:59] <ochosi> holy crap, chromium??
[09:59] <ochosi> and libreoffice
[09:59] <ochosi> pf
[09:59] <ochosi> i wonder how to monitor the X11 setting efficiently to override it with the setting in xfpm even if other apps tamper with it
[10:00] <ochosi> thanks for that link ali1234 
[10:01] <ochosi> if you have any idea on how to do that ^, lemme know
[11:45] <elfy> bluesabre: found odd bug in mousepad from staging - does that want reporting upstream?
[11:45] <elfy> bug 1390046
[11:51] <ochosi> elfy: yeah, worth reporting upstream, mousepad is actively maitnained
[11:51] <ochosi> maintained
[11:51] <ali1234> cannot reproduce...
[11:52] <elfy> also - I've undone the qt config for clementine so I can see it change when the fix arrives from vivid-proposed
[11:52] <ali1234> elfy: it's because you have "match whole word" selected and your file has no spaces in it
[11:52] <ochosi> indeed, i also can't reproduce (also using that version of mousepad)
[11:52] <ochosi> oh
[11:52] <ochosi> ali1234 was faster :)
[11:53] <bluesabre> hey elfy
[11:53] <bluesabre> !info xubuntu-default-settings vivid
[11:54] <ochosi> elfy: do you have chromium and/or libreoffice installed? both of those potentially mess with the blank settings
[11:54] <elfy> http://www.zimagez.com/zimage/screenshot-061114-115341.php
[11:54] <elfy> same issue without match whole word
[11:54] <bluesabre> ^ the qt-fixing xubuntu-default-settings has already landed in vivid
[11:54] <elfy> yea - I have lo installed
[11:54] <ochosi> odd though, i really can't reproduce
[11:54] <ali1234> search direction: down - cursor is already at the end of the document because you've been searching before
[11:54] <ali1234> it doesn't wrap around
[11:54] <ali1234> it probably should have an option for that
[11:55] <ali1234> you can set search direction: both though
[11:55] <elfy> ali1234: aah yes - that's found it
[11:56] <elfy> bluesabre: looked to me like it was in -proposed 
[11:57] <bluesabre> also, https://launchpad.net/ubuntu/+source/xubuntu-default-settings
[11:57] <bluesabre> in release
[11:57] <bluesabre> it should be there :)
[11:58] <elfy> looking at bug 1382741 branch is  lp:ubuntu/vivid-proposed/xubuntu-default-settings
[11:58] <elfy> and if it is released - then it's not working for at least 1 qt app :)
[11:58] <elfy> https://code.launchpad.net/~ubuntu-branches/ubuntu/vivid/xubuntu-default-settings/vivid-proposed
[11:58] <bluesabre> https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1382741/comments/8
[11:59] <bluesabre> it might be a config file that does not copy for existing accounts (new only)
[11:59] <bluesabre> try a guest user?
[12:00] <bluesabre> oh right, its in skel, so new users only
[12:00] <bluesabre> or new installs
[12:00] <elfy> ok 
[12:03] <elfy> bluesabre: yep - changed mine and that works now
[12:04] <bluesabre> cool
[14:53] <dkessel> hmmm is there a blueprint for default application changes in the vampire cycle?
[14:55] <ochosi> dkessel: nope, but it'd probably go in the features blueprint
[14:56] <ochosi> for a default app change to happen, usually what we'd do is an app comparison
[14:56] <ochosi> what do you have in mind?
[15:03] <dkessel> ochosi: hmm more of a default app addition... adding a backup app (i propose deja-dup)
[15:04] <ochosi> right
[15:04] <ochosi> i guess the best way would be to write up an app comparison anyway
[15:04] <ochosi> which backup-apps do we have in the repos
[15:04] <ochosi> what features do they have
[15:04] <elfy> didn't we have this last cycle? 
[15:05] <ochosi> how do they compare (installed size, size on iso, mem usage)
[15:05] <ochosi> certain aspects (like being qt instead of gtk) are no-gos
[15:05] <ochosi> elfy: yeah, possible that we had some discussions, but no real spec for it
[15:05] <ochosi> and anyway, i'd encourage anyone who'd wanna write one, for whatever default/new app they think is worth discussing
[15:09] <dkessel> ok
[15:10] <ochosi> here's an (old) example of such a comparison i did once: https://wiki.ubuntu.com/Xubuntu/Roadmap/Specifications/Karmic/DefaultMailClient
[15:11] <ochosi> i'd probably use more tables now
[15:23] <elfy> https://wiki.ubuntu.com/Xubuntu/Roadmap/Specifications/Utopic/Deja-Dup
[15:24] <ochosi> heh, my brain is obviously swiss cheese
[15:24] <ochosi> thanks for the reminder
[15:24] <elfy> :)
[15:24] <ochosi> anyway, comparing deja dup to alternatives would be important
[15:24] <elfy> my brain is the same - just got holes in slightly different places 
[15:25] <elfy> ochosi: yea - I'm meh about the whole thing tbh - was certainly not me pushing it last cycle :)
[15:30] <ochosi> dkessel: some aspects missing from this spec elfy just linked: alternative apps, dependencies, clear numbers (size: installed, iso, mem usage) etc
[15:30] <ochosi> if you need guidance or review, just post your WIP thingy here
[15:32] <dkessel> dkessel: ochosi, i will. If I really want to take this on... It sounds like a rather time-consuming thing tbh.
[15:32] <ochosi> yeah, i won't lie, it will take some time
[15:33] <ochosi> but keep in mind that we should strive to take informed decisions for all xubuntu users
[15:33] <ochosi> shipping something by default is something very different from having it readily available in the repos
[15:35] <dkessel> ochosi: yes, i understand the implications of shipping something be default. and i also think the process is ok. but i guess my time might be better spent helping with qa
[15:36] <ochosi> sure, that's fine
[15:36] <ochosi> feel always free to motivate others to do it though
[16:35] <elfy> knome: if you've got 10 minutes later today can you give me a shout :)
[19:05] <Unit193> Oh heh, abiword is orphaned now.
[21:24] <dkessel> It is? Why is that?
[21:26] <elfy> you have to guess dkessel 
[21:26] <elfy> it's Unit193 being concise again :)
[21:27] <pleia2> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740678
[21:27] <pleia2> 247 days ago
[21:27] <Unit193> Right, Debian people know!  "primary reasons for searching for (co-)maintainer(s) are lack of "
[21:27] <Unit193> time and interest to Abiword...
[21:27] <Unit193> pleia2: Actually changed from RFH to O on the second of Oct.
[21:28] <pleia2> Unit193: different bug?
[21:28]  * pleia2 was just looking at /devel/wnpp/orphaned
[21:28] <Unit193> pleia2: Same one, retitle at the bottom: Changed Bug title to 'O: abiword -- efficient, featureful word processor with collaboration' from 'RFA: abiword -- efficient, featureful word processor with collaboration' -- (Thu, 02 Oct 2014 10:09:04 GMT)
[21:29] <pleia2> oh right
[21:29] <pleia2> I hate the debian bts :s
[21:29] <Unit193> Truth.
[21:30] <Unit193> Remember, it's a mail system, therefor most of the latest data is at the bottom. :P
[21:30] <pleia2> it's at the bottom, looking nondescript so I just glaze over it
[21:30] <pleia2> brain thinks it's part of the footer
[21:31] <pleia2> (doesn't help that I'm kind of exhausted :))
[21:31] <Unit193> Exactly, bit annoying really. :P
[21:33] <pleia2> so, time to give up and ship libreoffice?
[21:33] <pleia2> :)
[21:34] <elfy> yay
[21:34] <elfy> that discussion :p
[21:34] <pleia2> hehe
[21:34] <pleia2> sorrrrrry
[21:35] <elfy> but not all of it :)
[21:35] <Unit193> Nope, because that means I nearly started that all up again. :3
[21:35] <Unit193> pleia2: QA will take care of it. :P
[21:35] <elfy> yay
[21:35] <elfy> QA Lead delegates to Unit193 
[21:36] <Unit193> elfy: Erm, I'm talking Debian land, so https://qa.debian.org/developer.php?login=packages@qa.debian.org  sorry about the confusion.
[21:36] <elfy> I thought knome was muttering about abiword and gnumeric recently
[21:36]  * Unit193 might be in Debian mode right now.
[21:36] <elfy> best go to a debian channel then
[21:41] <Unit193> D:
[21:42] <elfy> ):
[22:05] <brainwash> bluesabre: meh, I was not aware of the fact that packages have to stay in -proposed for 7 days until they can be moved to -updates :/
[22:06] <elfy> you are now ;)
[22:06] <brainwash> people have to wait some more days for the updated thunar package :>
[22:07] <elfy> yes
[22:07] <elfy> but - they waited a LOT longer for the sound issue a couple of cycles ago
[22:08] <elfy> and if people complain - tell them it's because we don't get enough testing done by users
[22:08] <brainwash> or the fix for the black screen madness
[22:10] <elfy> so - some time next week is a whole lot better than some time in December ;)
[22:13] <brainwash> right, someone should have noticed this bug earlier
[22:16] <brainwash> I am not familiar with the test cases, but isn't there one for opening pdfs files or opening files in general?
[22:16] <elfy> nope
[22:17] <elfy> they're easy enough to write - write one and I can check it, merge it, sync it to trackers and get it on the package tracker
[22:17] <elfy> but of course if we only get 1 or 2 people reporting to there again it might be late in the cycle before it's noticed
[22:18] <elfy> https://wiki.ubuntu.com/QATeam/ContributingTestcases/Manual
[22:18] <brainwash> I'm not an expert
[22:18] <elfy> in what?
[22:18] <brainwash> test case writing :D
[22:18] <elfy> it really is simple - I can do it :)
[22:19] <elfy> pull the branch and look - is is as simple as "do this" "result is this"
[22:19] <elfy> really :)
[22:19] <brainwash> so, the user should open a pdf file in thunar... but how does he get a pdf file in the first place?
[22:20] <brainwash> are there any?
[22:20] <elfy> well that's the thing isn't it :)
[22:20] <GridCube> >print to file
[22:21] <brainwash> this is getting a bit too complex
[22:21] <elfy> and what filetypes are we interested in making sure work properly - at the most those we have default apps for 
[22:21] <brainwash> right, only testing pdf files is not enough
[22:21] <elfy> indeed 
[22:21] <brainwash> for a good test case
[22:22] <elfy> things that mousepad, parole, abiword, gnumeric for a start can open
[22:22] <GridCube> cant there be a test folder people could download?
[22:22] <brainwash> didn't ubuntu ship some example files?
[22:22] <brainwash> file a movie, a picture, a doc, ..
[22:22] <GridCube> lets ask ubottu 
[22:22] <brainwash> like
[22:23] <Unit193> With how many PDFs there are, can't we just presume people can find one? :P
[22:23] <elfy> you don't have to actually be able to open a file if all you are doing is testing that foo.pdf opens in the right app
[22:23] <elfy> touch foo.pdf
[22:23] <brainwash> Unit193: on the interwebs?
[22:23] <elfy> as long as it OPENS that's sufficient to test that it does in fact opne
[22:24] <brainwash> but seeing some content helps
[22:24] <elfy> no
[22:24] <Unit193> Google PDF File => www.cse.msu.edu/~chooseun/Test2.pdf  too much handholding will get you germs...
[22:24] <brainwash> otherwise the app might complain that the file is not valid
[22:24] <elfy> brainwash: all you are doing is testing that it opens with the right app
[22:24] <elfy> I've just tried :)
[22:25] <elfy> doc viewer tried to open it but complains
[22:25] <elfy> parole will open a touched test.mp3
[22:25] <elfy> can't do anything but it WILL open it :)
[22:26] <elfy> so the first part of testcase is just touch a bunch of files 
[22:27] <elfy> other testcases should be checking that the app itself does as it should
[22:27] <brainwash> combining these two test cases helps to reduce the time spent on testing
[22:27] <elfy> Unit193: better not to go online for things - one of the other tests did that - and then got fails 
[22:28] <Unit193> ...
[22:28] <elfy> brainwash: there's not a test for doc viewer :)
[22:29] <elfy> oh yes there is 
[22:29] <elfy> needs fixing - but it's not in any of our testing groups
[22:30] <elfy> and it doesn't test that clicking on a file works 
[22:30] <elfy> I'm not sure that any do *that*
[22:30] <elfy> they tend to open app, open file, does it work
[22:31] <elfy> so - a click a file - does it open in the right place appears to be a hole that could be filled
[22:31] <elfy> too much talking from me at late o'clock
[22:32] <brainwash> I don't know if I want to mess around with test cases
[22:33] <elfy> brainwash: all you have to do is pull the branch, write something and then push it back :p
[22:34] <elfy> if it takes longer than 30 minutes you're writing too much and no-one will test it :)
[22:34] <brainwash> ..and then maintain my changes? =S
[22:34] <elfy> brainwash: nah
[22:34] <slickymaster> elfy, if there's the need to fix any test case, I can do it
[22:34] <elfy> brainwash: tesstcases doesn't really work like that
[22:34] <brainwash> not fix, but improve :)
[22:34] <elfy> nope 
[22:35] <elfy> in general there's one person that watches the testcase bugs
[22:35] <elfy> <-
[22:36] <elfy> I Tend to do the fixes - that's why it always looks like I've written them if you look on trackers
[22:36] <elfy> last editor gets named
[22:36] <elfy> as long as the draft is ok - I watch the testcase bugs
[22:37] <elfy> brainwash: really touch.foo for all the things you think that WE should check then click each app opens 
[22:37] <elfy> so - x lines for each touch
[22:38] <elfy> then 1 do and 1 result for each :)
[22:42] <elfy> brainwash: basically with <dl> <dt> <em> and a quick look at an existing testcase I'd be surprised if you didn't work it out :)
[22:43] <brainwash> this should not be the problem
[22:43] <elfy> :)
[22:43] <brainwash> I just don't like the "touch xzy" idea yet
[22:43] <elfy> try it, it works :)
[22:44] <elfy> ALL this test need do is check that foo opens in bar 
[22:44] <brainwash> I was thinking about a proper test case with fancy example files
[22:45] <elfy> brainwash: simple is better - we are JUST needing to test open here
[22:45] <brainwash> examples files could actually showcase the default apps, like ubuntu used to do (or do they still ship them?)
[22:47] <elfy> this isn't about showcasing - it's about making sure that foo works
[22:48] <elfy> people testing know what we use - they're using it and/or testing it 
[22:48] <brainwash> but having a set of example files could help to test and showcase at the same time
[22:48] <elfy> yes kind of
[22:49] <elfy> I'm looking at this from a specific point
[22:49] <elfy> that point being that if we're lucky we get 2 or 3 people reporting
[22:50] <elfy> and they do that daily for images and for packages when they know it's there
[22:50] <elfy> so *I'm* really not that bothered about making it nice - I'm bothered about making an extra thing for the few who do it for us simple as possible
[22:51] <elfy> the touch command can be a one liner touch test.pdf touch.mp3 test
[22:51] <brainwash> ok, I'll have to get familiar with test case writing then
[22:52] <elfy> thanks :)
[22:52] <brainwash> or in thunar, create new file
[22:52] <brainwash> new empty file
[22:53] <brainwash> and then rename them accordingly
[22:53] <elfy> brainwash: yea but in thunar you have to do them seperately
[22:53] <elfy> this isn't about checking anything BUT that foo opens in bar
[22:53] <elfy> so the simplest way to do that wins :)
[22:55] <bluesabre> brainwash: the same thunar is packaged in the -staging ppa if they want it bad enough
[22:56] <elfy> bluesabre: yea - meant to make that point earlier, it's also available in -proposed - I pointed someone at that on forum today for that very reason
[22:57] <brainwash> it's nicer, if it works ootb for everyone :D
[23:03] <bluesabre> of course, but gotta play by the SRU rules
[23:04] <elfy> brainwash: when you do the mp for the testcase put my name in the box as reviewer 
[23:05] <elfy> and for ^^ to work out ootb - we need more people testing things, reporting them, seeing bugs - but we're not Ubuntu with 000's of people :)
[23:06] <elfy> dkessel: actually I wonder if there could be an autopilot test that touches a bunch of files and checks they open in app correctly
[23:07] <elfy> but don't let that stop you brainwash as it will likely be 15.10 before we get things working there for us
[23:47] <elfy> ok - so a simple bash script will touch files and then xdg-open them 
[23:50] <elfy> so testcase could be - save this - chmod +x it and run