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

and a quick look at an existing testcase I'd be surprised if you didn't work it out :) [22:43] this should not be the problem [22:43] :) [22:43] I just don't like the "touch xzy" idea yet [22:43] try it, it works :) [22:44] ALL this test need do is check that foo opens in bar [22:44] I was thinking about a proper test case with fancy example files [22:45] brainwash: simple is better - we are JUST needing to test open here [22:45] examples files could actually showcase the default apps, like ubuntu used to do (or do they still ship them?) [22:47] this isn't about showcasing - it's about making sure that foo works [22:48] people testing know what we use - they're using it and/or testing it [22:48] but having a set of example files could help to test and showcase at the same time [22:48] yes kind of [22:49] I'm looking at this from a specific point [22:49] that point being that if we're lucky we get 2 or 3 people reporting [22:50] and they do that daily for images and for packages when they know it's there [22:50] 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] the touch command can be a one liner touch test.pdf touch.mp3 test [22:51] ok, I'll have to get familiar with test case writing then [22:52] thanks :) [22:52] or in thunar, create new file [22:52] new empty file [22:53] and then rename them accordingly [22:53] brainwash: yea but in thunar you have to do them seperately [22:53] this isn't about checking anything BUT that foo opens in bar [22:53] so the simplest way to do that wins :) [22:55] brainwash: the same thunar is packaged in the -staging ppa if they want it bad enough [22:56] 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] it's nicer, if it works ootb for everyone :D [23:03] of course, but gotta play by the SRU rules [23:04] brainwash: when you do the mp for the testcase put my name in the box as reviewer [23:05] 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] 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] 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] ok - so a simple bash script will touch files and then xdg-open them [23:50] so testcase could be - save this - chmod +x it and run