[00:14] evening folks [00:14] hey bluesabre [00:15] Unit193, slickymaster: I tried experimenting with building the docs, but could not get the build process far enough... if died with some xml validation [00:15] bah just hope we're not facing a dead-end [00:17] bluesabre, pastebin the output plz, it sounds like it's a problem somehwhere else [00:19] knome, regarding the last section of managing-applications.xml you pinged me about -> http://pastebin.com/sAeTEcnq [00:19] review and tell me if I can merge it [00:21] slickymaster, i think the wording is a bit clumsy [00:21] which one? [00:21] and while the argumentation is true, it's not mentioning the most important things [00:21] ince each new Xubuntu release ships not only bug fixes but also updates for potential security problems and hardware support improvements, it's not recommended setting to Never the option to handle release updates notifications. [00:21] i'll put that in a pad and you can see how i'd change that [00:22] ok [00:22] http://pad.ubuntu.com/xubuntu-docs [00:24] http://paste.ubuntu.com/8827154/ [00:25] slickymaster, there [00:25] hmmm [00:25] Unit193, sounds like a problem with relative paths? [00:26] or simply malformed translator xml files [00:27] not sure about starting the second sentence with "At the same time..." knome [00:28] I mean it's already been stated that it would be a EOL version [00:28] which pretty much sums it all [00:28] yeah... [00:28] i was thinking the same [00:29] what about that? [00:29] nah, i think it's as much duplication now [00:30] the point is not that their system is crap [00:30] :P [00:30] the point is that we will not support it [00:30] Just to give some background [00:30] on why [00:30] and, at the same time, their system might be a bit duh [00:30] that will happen for sure [00:30] but then they'll be at their own risk [00:31] ok, so what about hat [00:31] that too [00:31] no hats allowed [00:31] happy with it [00:31] ok, great [00:31] knome: what about the other options sub.section [00:31] fine with the rest as is [00:31] one more thing i considered [00:32] because the mailing list thread [00:32] do we want to mention synaptic? [00:32] i thought on dropping it, but the again i thought of expanded it a bit [00:32] no, just for one reason [00:32] we'ew nor shipping it [00:32] yep [00:32] we could say something like "Advanced users might want to use Synaptic (available from the repositories), ..." [00:33] but yeah, there are a few problems with that [00:33] yeaps, if it works don't touch it [00:33] 1) everybody suddenly becomes an advanced user when we say that [00:33] exactly [00:33] bluesabre: bzr pull && bzr status [00:33] 2) if we have decided that USC (and apt-get) is good enough, why mention other things [00:34] translators.xml:1: element itemizedlist: validity error : Element itemizedlist content does not follow the DTD is all I get, and that's because it doesn't setup translators. [00:34] slickymaster, oh, one more liiitle thing [00:34] shot [00:34] shoot [00:34] a shot would be nice, also [00:34] slickymaster, in the itemizedlist "never" section, maybe say "not recommended, see below" [00:35] or alternatively, [00:35] move the note about why the LTS method is recommended below the list as well [00:35] consistency, consistency... [00:35] i'd probably lean towards the latter [00:35] with a simple box or sth [00:36] so, x 3 [00:36] [00:36] [00:36] yep [00:36] ok, I'll cahnge the wording, update the changelog (including the bug elfy worked onDDD [00:36] and do those changes also [00:36] and merge [00:37] damn so many typos [00:37] "Opting in for LTS notifications is usually the recommmended option, especially if you are running Xubuntu on a production machine and/or need maximum stability." [00:37] s/usually/in most cases/ [00:37] there's something to start with :) [00:38] instead of "...recommended if you need maximum stability" you say? [00:38] Fixed it, maybe. [00:38] knome: ^ [00:39] slickymaster, yeppers [00:39] ok [00:39] because i think that's what we want to say [00:39] * slickymaster agrees [00:39] saying "update only every 2 years if you want max stability" is self-evident [00:40] so is the new form to say it, but meh... :) [00:40] it's a richer wording anyhow [00:41] it shows we care [00:41] ;) [00:41] of course, it's many words longer as well ;) [00:41] ok, doing it [00:43] Actually, more confused than before. [00:43] lol Unit193 [00:44] Ah I see. [00:44] What idiot wrote this?! [00:44] ...Oh right. [00:48] hah. [00:50] knome, should I run: bzr commit -m "bla bla" --fixes LP:1385479 ? [00:50] because I'm updating the changelog on that bug [00:50] or should i drop that parameter from the commit command? [00:51] if it's mentioned correctly on the changelog, no need to do that on the commit [00:51] ok [00:52] apparently using the parameter makes the bug marked as "Fix Available", which is more suitable for "real" bugs in software anyway [00:54] oth it would close that bug report [00:54] it wouldn't [00:54] * slickymaster thought it would :P [00:54] fix available is as good as fix committed, which is what the changelog change does [00:55] fix released is the status we get once the new docs package is uploaded [00:55] ok [00:55] Pushed up to revision 272. [00:55] care to check it knome, pretty please [00:55] great [00:56] ok, since you ask so nicely [00:56] danka [00:56] validates at least [00:57] lol [00:57] the shame if it wouldn't [00:57] echo $TEXTDOMAINDIR $LANGUAGE [00:57] /tmp/buildd/xubuntu-docs-15.04/desktop-guide/po//mo/ es [00:57] http://pastebin.com/YdV3J01a [00:58] I see nowhere does it search that dir. [00:58] knome, I forgot to add to the changelog what I've done :P [00:58] slickymaster, you know, i think we should use "Long-term Support (LTS)" instead of just LTS in that note [00:59] change that and change the changelog as you do that :) [00:59] otherwise - looks good [00:59] okie doke [01:01] gettext just doesn't care about ENV vars? [01:01] Unit193, maybe? [01:02] But it works outside the chroot! [01:03] * knome shrugs [01:03] `../scripts/translators.sh -l es` [01:03] http://paste.openstack.org/show/5ewmsZgxTd8zxSytPTy9/ [01:04] i "understand" chroots, but they are in a way just as black magic to me as programming is to elfy [01:04] ok knome, Pushed up to revision 273. [01:04] if you'd be so kind [01:04] sec [01:04] sure [01:07] looks all good to me [01:07] ok, that done [01:07] now we just have to wait for jjfrv8 on the glossary [01:07] :) [01:10] And, that's enough for one evening. [01:12] what [01:12] so soon Unit193 ?! [01:13] :) [01:13] lazy Unit193 [01:14] age does not forgive [01:14] nor forgets [01:17] Well, it just seems to ignore them, with no reason as to why, and no manual says it either. [01:17] Brick wall with nowhere to go. [01:19] we still have time Unit193 [07:15] bluesabre: I updated utopic thunar, but I'm not sure my machine is one to test verification on as I fiddled with mimecache.info - the new thunar didn't make any difference to pdf opening in gimp there [08:57] morning everyone [09:56] elfy: thanks for the testing-overview email! [09:56] i guess this time around there are a few good reasons to participate in a2, we'll get a new gtk3 version as well and that might break stuff again, and upower0.99 [10:36] hey elfy [10:36] thanks for letting me know... will set up a vm to verify [10:36] morning bluesabre [10:36] and sorry for pinging you all over the place :> [10:38] it happens [13:26] ochosi: [13:26] sigh [13:26] :) [13:27] elfy: yes..? [13:27] :) [13:27] ochosi: the bug I reprted yesterday has been marked a dupe of another private one that no-one can read [13:27] awesome :/ [13:28] yep [13:28] by whom? [13:28] launchpad I guess [13:28] commenting [13:28] yeah, uncool [13:28] why would that be a private issue [13:28] it's not really security/privacy related [13:29] coredump [13:29] commented [13:29] this means that at least one other user encountered the same crash :) [13:30] yep and entirely likely that the other user won't go back to it either [13:31] https://bugs.launchpad.net/ubuntu/+source/xfce4-panel/+bug/1389400/comments/3 [13:31] Error: Could not gather data from Ubuntu for bug #1389400 (https://launchpad.net/bugs/1389400). The error has been logged [13:34] bluesabre: re thunar - not too sure what's going on with that actually [13:35] elfy: a patch was provided upstream, we packaged that and added it to vivid, and the same patch added to utopic-proposed [13:36] I'll comment/verify the bug tonight [13:36] bluesabre: ok - what I meant was I didn'ty know why I couldn't verify it - I'm assuming because I mucked about with the .cache file [13:37] ochosi: ok - panel - I've removed indicator-app and will watch it, then add that and remove another [13:37] might be related, defaults should be respected now [13:37] gotta run, bbl [13:37] meant to say that this morning [13:38] bluesabre: mmm then if that's the case I'd have to verification-failed [13:38] cya later - have fun :) [13:38] elfy: ok thanks [13:39] elfy: not sure of the risk, but you can try deleting that cache file and logging in/out [13:39] bluesabre: ok - I'll try that when back properly - it's an unused install now anyway :) [15:32] anyone want to do a session at UOS? [15:36] ali1234, not really; if we want to have a session, there's no need to coordinate it to happen at the same time than UOS anyway [15:37] after real-life UDS's ended, there hasn't been any benefits/synergies when doing that [15:38] it would be more for promotional purposes [15:38] what would the subject of the session be? [15:39] "look at us, hey, look, we're still here" [15:39] that's a bad subject line.. [15:39] lol [15:40] * slickymasterWork likes ali1234 subject [15:40] lubuntu is doing a session titled "Latest Developments In Lubuntu Development" [15:40] and there's also "happy second birthday ubuntu gnome" [15:41] ok, so who's willing to run that session? [15:41] me [15:41] what are we actually talking about? [15:41] ok, great [15:41] i don't know [15:41] mind creating a pad and dump ideas there? [15:42] and send an email to the list saying you'd be interested and willing to run the session and ask for feedback/idas [15:42] *ideas [15:42] i don't actually have any ideas [15:43] kubuntu: "We will be showing off our Plasma5 tech preview and have a Q&A session for users." [15:43] it's not a bad idea, but i'm also not sure what it could be about [15:44] so far, there haven't been colossal steps forward [15:44] yeah, and there are no big plans either [15:44] (although i guess that's not necessary for every release) [15:44] ali1234, but if you could still do that... at least we'd have a place where we can drop ideas, and somebody saying "i'll do it" [15:44] i'm sure i can figure out a few things that we can talk about [15:46] as long as we have a title as self-referential as lubuntu's, i'm fine :> [15:46] huhu [15:47] "Xubuntu Developments in Xubuntu Development" would be my #1 [15:47] please no [15:47] don't even joke about that [15:47] :D [15:47] with Xubuntu developers? [15:47] ftr, my vacation overlaps with UOS, so I'm skipping this time around [15:47] pleia2, that's good to know and completely fine :) [16:16] so - did that discussion ^^ actually get a result? or is it still we don't do theseuds/uos things? [16:18] if ali1234 is willing to host a session, i'm +1 [16:18] ok - well for my sins I've apparently agreed to be a track lead so should be able to set it up [16:18] that does not equal run it I add ;) [16:22] elfy, i'm working on the qa-v-cycle pad, or tbe, the draft for the process page updates [16:23] though i'm not really working *at the pad* [16:23] i have a three-way comparison in meld [16:26] k - well when you think you've got something that I can ack or not let me know - thanks :) [16:28] let me send you email with some files you can compare [16:28] well - I would rather just have a draft of what you get to tbh [16:29] done [16:29] well, one of the files is a draft [16:29] but i have added the appropriate partsf for your and the current version for comparison [16:29] two things i've left out: [16:30] the specific testing requirements for the team, because i'm not sure if the processes page is the right one for those [16:30] which is the draft? the proc-test-new one? [16:30] the draft is -knome [16:30] -new is your version [16:30] -old is the one in the wiki [16:30] k [16:30] well [16:31] and the other thing, the qa incenctive program, because we need to find the right place for that as well (probably website) [16:35] what about [16:35] yea - wasn't too sure what to do with that tbh [16:35] and I would say without a doubt that x.org is the place for it - then we've got complete control [16:37] "The Xubuntu team members are expected to run milestone tests when they can." [16:37] or sth along the lines of that [16:37] to me, that communicates the same thing, and even a bit more [16:37] lily-livered [16:37] hehe, yeah [16:38] that communicates nothing that we've not got already [16:38] I'm sorry - but if -team is the group who thinks 'release' is what we want to actually release - they should be prepared to test at least once in a cycle [16:39] from my pov, what we need is a change in attitude [16:39] change in the strategy document can hardly do that [16:39] and asking nicely 2 or 3 times a cycle for people to actually test does not work [16:39] so putting down "you need to do X" in the SD is as good as.. nothing, in a way [16:39] and my position is that if team can't be bothered to test - why should I be bothered to set all this stuff up? [16:40] ^ don't get me wrong [16:40] agree with you [16:40] everyone says that knome - and then nothing actually changes or happens ;) [16:40] i don't [16:41] ali1234: you're not in -team [16:41] thing is, people might wanna just contribute to the team in one field, and that's still a valid position [16:41] elfy, that proves there is no change in attitude [16:41] ochosi: sorry - if people in team can't be bothered to test I see no reason why I should care either [16:42] i guess "because you care about xubuntu" [16:42] elfy: well, i could also say that if others in the team can't be bothered to draw icons, why should i? [16:42] ochosi: what happens if we have to drop some new package in and the only person who tests it is me [16:42] and then we get hundreds of bugs [16:42] ochosi: becasue testing is about making sure the whole thing works [16:43] elfy, then it's a fail [16:43] if it took 24 hours to run a test I can understand it - but a few minutes once in 6 months :) [16:43] the problem is that it does take 24 hours to run a test [16:44] because the installer has very few bugs. installing an iso and then checking each default program loads up just doesn't uncover bugs [16:44] ali1234, that'a a different thing [16:44] most of the actual bugs this cycle would not have been found by iso testing [16:45] of course [16:45] for example the suspend thing, and the Qt problems [16:45] ali1234: they might have been found if more people had been testing packages and running the system [16:45] if you want testers to check for stuff like that, then you're asking them to spend a day on each test [16:46] I'll bbl [16:46] elfy, or not - we do not do/encourage a lot of exploratory testing [16:46] well quite, i think more people should run the development system. i don't see much benefit in iso tests and the iso tracker [16:49] so I'm just completely wasting my time then - can't even get some people to check that the image boots [16:50] elfy, no, we should still keep on doing that [16:51] you are just talking about two different things [16:51] exploratory testing, with which people find the most bugs [16:51] and manual ISO/package testing with testcases, which test that the basics of the system are working [16:52] what ubuntu desktop have done lately is that they've shifted (or at least tried to shift) more towards the exploratory testing, because most of the basic tests are run automatically now [16:53] creating PPA's that have the development versions of the packages is in the same spirit as that [16:53] so we should encourage people to do that (as well) [16:53] but find a balance/way to get the basic manual tests ran enough times as well [16:54] we have none of that - we aren't ubuntu with a whole team for QA [16:55] no, but that's why we have to find other ways to do ti [16:55] *it [16:55] if we aren't able to get people to run a basic install test at milestones - we have no chance of getting them to run the packages we're releasing [16:55] and if you look at the ubuntu desktop testing results, they aren't wonderful at all times either, even if they have the whole team for QA, and many more testers from the community [16:55] (or at least more potential testers) [16:56] i run the development PPA all the time [16:56] they don't have to be - they've got other tests running [16:56] it's much easier than constantly reinstalling my computer [16:56] elfy, ^ what ali1234 said, running a development PPA *is* testing the packages we're about to land [16:56] and yes, it is easier [16:56] ali1234: you might - and thanks, but all I CAN know about is the results I see on the trackers [16:56] not comments in an IRC channel that I might possibly see [16:56] it is also much more useful, i'm much more likely to find bugs on a system i am using, rather than one i'm going to trash after 5 minutes [16:57] and THOSE tell me that no-one cares [16:57] so the question is: how do we measure how successful the PPA testing is? [16:57] i don't think there is an easy way [16:57] report it on the tracker [16:58] there isn't a test on the tracker for PPA testing [16:58] and the point is that the PPA testing doesn't follow a tight testcase definition; people do what they usually do with the apps [16:58] and then they either find or don't find bugs [16:58] there doesn't need to be as long as there is a test for mousepad - report mousepad things there - if someone's using staging mousepad - put in the comment [16:59] ok, then we should encourage people to do that [16:59] maybe a general testcase for "PPA tests" [16:59] why must this be done in addition to reporting a bug on launchpad? [16:59] if a find a bug i report it. if the bug report is not closed, you can assume the bug is not fixed. the tracker reports could be generated automatically [17:00] what about adding a specific tag for bugs found with the staging PPA? [17:01] that sounds like the most accurate method to measure it [17:01] (of course not the time that went to it) [17:01] yes, one big problem with launchpad is it hates when you use PPAs and tries to prevent you from reporting a bug (at least apport does) [17:02] ali1234, unless you file the bug manually [17:02] yeah [17:02] that's a valid point [17:03] although this is not an issue if you are running +1 [17:03] as opposed to release plus staging ppa [17:07] https://errors.ubuntu.com/?user=a-j-buxton&period=month look at all those bugs [17:07] then perhaps we don't bother with package tracker at all this cycle and tell the -dev list that we'll just be looking for reported bugs [17:08] elfy, if we manually add tags to those bugs that are found when using the staging PPA, yeah that sounds like a good experiment [17:12] well that's not anymore wishy washy than hoping people report on the tracker so not any worse [17:21] it's a different change, but if people are running the staging PPA already, it's less asked [17:21] yep - so anyway to know how many do? [17:22] and we'd get bugs reported from people running vivid but not ppa as well - assuming they report them [17:23] but not specific to us unless of course it's a specific xubuntu package [17:23] we don't want to just look at staging ppa [17:24] I've not got an issue with us doing this - but team has to agree - and soon I guess or it'll be too late [17:25] none of this though makes any difference whatsoever to the not running basic install tests [17:27] elfy, no way to know how many do except ask [17:28] ok [17:28] not that bothered by it - just if there was an easy way to see how many times a ppa package gets downloaded [17:30] knome: re the -gnome attachment works for me - but if we change package testing then the end needs to go [17:30] yep [17:31] well [17:31] let me read it again [17:31] i would say change it to: [17:31] Calls for package testing sprints will be sent out as required. [17:32] and the first paragraph to: [17:32] The QA team can schedule package testing sprints to happen during the cycle between milestone testing to ensure applications that are included in Xubuntu have sufficient amount of testing conducted. [17:33] s/can/wiil [17:33] will even [17:33] sure [18:42] bluesabre: so thunar fix does work, just needed a reboot [19:02] btw this seems to be how to find out download counts of a PPA: http://askubuntu.com/questions/296197/how-to-find-out-the-package-download-count-from-a-ppa [19:03] (have not tried it) [19:26] bluesabre, following that ping in -offtopic, bug 1389840 [19:26] bug 1389840 in parole (Ubuntu) "parole crashed with SIGSEGV in packspu_VBoxPackSetInjectID()" [Undecided,New] https://launchpad.net/bugs/1389840 [20:06] ochosi: sigh ... so somehow I would really like to get to the bottom of this screen blanking issue - which is now present in vivid for me :D [20:15] I'm not even sure where to look to see when it's being changed - if there is such a place [20:15] it? [20:16] something is randomly changing the never's I have for blanking in power manager [20:16] that [20:17] oh. i thought the "black screen after wake up" thing was back [20:17] oh no - not that - this is something that apparently only I see :) [20:45] elfy, so if you have fundamentally nothing against my version of the proposal, i'll start to process it further :) [20:45] well [20:46] until we've got a finite view of what we're going to do with packages then doing the processes page seems a bit premature [20:46] how i see it is that the manual testing we do now and the exploratory testing can live side-by-side [20:47] since the processes page isn't heavy to change in the bureaucratic level, i'd rather get it updated sooner than later [20:48] run it by ochosi again please [20:49] and we've not made any decisions on what we do with packages - just a discussion with 3 people so far [20:49] i will, that's partly what i meant with pushing it forward [20:49] ...and the other part was to ask for comments from the team :) [20:50] again [20:50] yeah. [20:50] Hmm? [20:51] one way to do that is to add it to the meeting agenda, then ask a few questions, and so. i'll see what we'll have to do :) [20:51] knome: well I'm not likely to be about for meetings till either pleia2 or I call one as we usually do them later in the day [20:52] i can do one later in the day when it's my turn [20:52] that's the one after the next one. [20:53] knome: if you can mail me the one with the changes re packages too please [20:53] sec [20:54] done [20:54] ta :) [21:02] So we're going with general rules/guidelines, and punting the support over to #ubuntu+1 when it's more of a core problem? One downside will be known issues for release+1 in #ubuntu+1, but unknown thus takes longer to identify them in #xubuntu. [21:03] what i was thinking because there was so little feedback... [21:03] what about just supporting +1 everywhere starting from beta1? [21:03] Unit193: no idea what we're going to do - just no-one cares enough to say anything so ... [21:03] it isn't like there are dozens of requests every day [21:03] and nobody wasn't really negative about any of the options [21:03]