[00:36] back [00:36] nighty flocculant [00:39] knome: poke [02:15] dkessel: updated the packaging for the mousepad recipe, now we just need a new commit on http://git.xfce.org/apps/mousepad/ to get new builds [04:19] thanks bluesabre :) [10:14] Unit193: do you use (or have) the apt-offline doobiwotsit? could you look at the updates to the docs page I have done for that :) [10:15] https://code.launchpad.net/~flocculant/xubuntu-docs/updates/+merge/277329 [11:05] a wild ochosi appears [11:29] Hahah [14:09] flocculant: I briefly looked over it. [14:13] https://wiki.ubuntu.com/Xubuntu/DeveloperDocumentation [14:13] :] [14:19] Unit193: cheers - just wanted to make sure it makes sense [14:19] ...the apt-offline doobiwotsit... didn't. :P [14:26] :p [16:09] bluesabre: so parole not playing films using clutter here [19:12] bluesabre, Should just running ./configure --enable-maintainer-mode work? [19:12] (for mousepad) [21:46] evening folks [21:46] ochosi: evening :) [21:46] hello ochosi [21:47] so what's clickin? [21:47] most of my joints [21:48] ochosi: so you found the poll thread yesterday - don't forget to do more than read it :D [21:48] yeah, for some reason i dont receive ML mails anymore [21:48] no idea what's up with that [21:48] had no time to check it out last night [21:49] but will now [21:49] that's odd then [21:49] yeah, no clue, haven't changed anything in the subscription or the email filters [21:50] Spam. [21:51] Or knome removed you to mess with you. [21:51] both is possible or even probable [21:51] it's the baby who is (literally) messing with ochosi [21:52] s/with/on [21:52] ;) [21:52] gee, did anyone warn those guys on the ML in terms of spamming us with their "votes"? [21:53] Did you read te first one? [21:53] ochosi, didn't you see my reply to the thread? [21:53] ochosi: I was silly enough to think that a centre justified line in bold would suffice [21:54] flocculant: sorry, my emails are plaintext ;) [21:54] :) [21:54] but it was still line #1 I hope :D [21:54] flocculant, who reads the first line? [21:54] right right, i'm still catching up on the thread and i started from the bottom here (for some odd reason): https://lists.ubuntu.com/archives/xubuntu-devel/2015-November/thread.html [21:54] I used a text client, it was very clear too. :P [21:54] well i guess it's become a habit for you to work with the bottom [21:55] ha ha [21:56] knome: yeah yeah, i'm just waiting for you... ;) [21:56] i know [21:56] but i'll use this non-overlapping time as well as i can [21:56] haha [21:56] can't argue with that [21:57] just tell me if i'm going too far [21:57] sure thing :) [21:57] and i'll tell your baby she can stop crying because you have picked up the crybaby hat of the family [21:57] :D [21:57] you weren't expecting THAT [21:58] i wasn't expecting THAT [21:58] ha ha ha [21:58] :) [22:00] ok, more serious note [22:00] anyone up for fosdem in february? [22:00] i know it's early to ask [22:00] not me [22:00] but then again, asking later might even make less sense [22:00] silly brussels [22:00] we still have time to gather some funding [22:00] the fosdem website says 30/31 january [22:01] so i don't think anybody is going there in february [22:01] ok ok [22:01] so that then [22:01] i don't think so, but if enough people from the team will attend, and i will be desperate enough avoiding the poop cannons, maybe [22:02] Not me either. [22:02] also, i wonder why "beer" is mentioned as the first thing int he fosdem header. [22:04] because brussels - belgium - beer? [22:04] :P [22:05] Well considering we're talking about beer, vomit, and poop in here I suppose saying I'm rebuilding the xubuntu-core isos isn't that bad of spam. :P [22:05] meh, Unit193 is sooo on-topic [22:06] :) [22:06] Nono, it's spam, 'community' stuff and all. [22:06] the reason why we talk about poop and vomit is to make Unit193 more comfortable in this room [22:06] flocculant: ever heard anything from that jenkins testing initiative again? [22:06] ochosi: it's not dead [22:06] oh, that's comforting news [22:07] it does work mostly for ubuntu, there's issues getting it to work on flavours from the last update [22:07] the guy who's been working on it I've not seen for a few weeks [22:07] Also, everyone vote for which IRCC member looks best? [22:08] ochosi: oh hang on [22:08] balloons: at this stage I would like to at least see that the image boots to a desktop [22:08] balloons> right right. They were keen to see the same thing [22:09] that was during one of the uos sessions apparently [22:09] ok [22:09] I do at least check that images boot properly once a day [22:09] wow, that's definitely something we should automate [22:10] ++ [22:10] that's what they're trying to do [22:10] and just checking the manifest file size gives a clue that it's not gone horribly wrong too [22:11] doesn't obviously prove it boots - but if the file is too small then it's not going to :) [22:11] i haven't ever gotten into this myself, but wasn't there that ubuntu autopilot python app that helped with app-testing? [22:12] * ochosi feels a bit silly for asking this [22:12] ochosi: pretty sure that's what I'm talking about [22:12] Thought so, but only GTK3. [22:12] ochosi: there are 2 basic types - iso and packages [22:12] packages hates gtk2 [22:12] thing is, in my current dayjob i work with jenkins a lot [22:12] which is why we never got far [22:12] right [22:12] i wonder why it doesn't work with gtk2 [22:13] ochosi: I promise never to tell balloons [22:13] flocculant: thank you. [22:13] ochosi: it doesn't introspect properly - whatever that means [22:13] oh that [22:13] right, i guess there's nothing we can do about that, other than port xfce to gtk3 [22:13] Which'll be a sad day. [22:14] and frankly - I don't mind that we don't get package testing - it's never going to be what people can do [22:14] so - if we can kinda forget images as a daily issue I'd be happier [22:14] Unit193: why? just keep using 4.12 [22:15] not sure, routine tests with apps can all be automated [22:15] from what i learned, the LO guys even do some automated click-testing [22:15] that works with *any* toolkit that accepts mouse-input [22:16] ochosi: yes but we're finding more stuff with not routine use :) [22:16] right, but then you can throw out all testcases ;) [22:16] unless you decide to only write weird non-standard ones [22:16] ochosi, i believe we could do that, but then it'd rely on mouse position instead of knowing that we are activating the right element [22:17] ok - but then we have to hope people report things [22:17] knome: if it's running in a fixed resolution automated environment that [22:17] 's no problem [22:17] don't we already have to hope for that even if they are running the predefined tests? [22:17] flocculant: don't we have to hope that either way? :) [22:17] knome: of course [22:17] ochosi: ^^ [22:17] ;) [22:17] ochosi, yeah, that's not the main problem - but what if some popup doesn't appear, or for some reason, the UI is off? [22:18] knome: the UI is off..? [22:18] but - at least we're asking people to test something AND saying report to the tracker anyway [22:18] knome: if a popup doesn't appear, that's a bug, so the click-test found one. yay. [22:18] not that we're getting much [22:18] ochosi, an icon in a button is too large -> puts off all other buttons by X pixels? [22:18] ochosi, and sure, it's finding bugs then, but meh [22:18] knome: sounds like a bug to me! [22:18] ochosi, if you ever change the UI, then you have to rewrite the test [22:19] ochosi, but not if the test relies on gtk element ids [22:19] and i guess figuring out if something went wrong is harder with the non-id stuff too [22:19] well yes, i only mentioned the click tests as a last resort for classic "humans-only" things [22:19] as an example of: even this can be automated [22:19] not in the sense of: let's do all tests like that! [22:20] sure [22:20] besides, automated tests aren't exploratory either, they only test predefined scenarios too [22:21] and most of the time start with a clean state [22:22] which is why upgrade tests work [22:22] :) [22:22] exactly [22:22] so they only are supposed to work in well-defined environments [22:23] test should really say - add this bunch of random ppa's to the mix, make sure you have a prop graphics driver in use, fiddle with as many things as you can - then test it :D [22:24] anyway - I'm off - night all :) [22:25] night flocculant! [22:46] krytarik, do we even need the language name list? [22:46] krytarik, i don't think it's used by docbook internally, and we don't really refer to those entities manually either [22:46] Yep, that's the list of native language names. [22:46] For the translation links, that is. [22:47] ok [22:48] that looks like a good list [22:48] \o/ [22:49] (For all other: http://paste.openstack.org/show/Zv2HRFVBuHzAEfhCtvjD/ ) [22:49] * others [22:50] when can we expect to see a MP? [22:51] Probably best to merge the current one first, and then I'll incorporate all the recent changes into mine. [22:53] That is, I'll be trying to include them, and when further changes occur while I'm doing it, that'd be bad. :P [22:57] ;) [23:01] Btw, there are minor fixes for validation too, but not sure I should specifically list it. :P [23:01] krytarik, where's the "current stuff"? [23:02] not seeing in https://code.launchpad.net/xubuntu-docs/+activereviews [23:02] Well, I see one there :P - https://code.launchpad.net/~flocculant/xubuntu-docs/updates/+merge/277329 [23:03] me too [23:09] I mean, you could merge it after mine too, but then you'd need to take care of the changed ENTITY's at the top of the XMLs, I guess. [23:09] Because it'd probably revert it. [23:12] true [23:13] Hrm, well is my old pre-bump all covered in the contributor docs now? Can I rm it? [23:14] Unit193, bump to new version numbers? [23:14] Well not as explictly, so I guess I'll hold on to it. [23:17] And does the contributor docs really need to be !English? It's not like we'd really be able to work with any contributors that don't speak English, and the mailing lists require it. [23:17] i've been thinking that too [23:18] knome: domain/pre-bump.html [23:18] Well, I think it's nice to offer the option to translate it anyway. [23:18] Unit193, sigh, stop sending cryptic messages :P [23:18] +1 [23:19] I'm trying to not spam that stupid ubuntulog. [23:19] krytarik: Sure, but at the cost of having people put effort into translating it.. [23:21] one thing to consider now that XSD is there is if we want ANY translations for that [23:21] it's sameish with licenses [23:22] krytarik, ^ note that, we don't want to translate the CC license, so there's some reason to keep shipped-docs [23:22] knome: I solved that though. [23:22] aha. [23:22] what about the strategy document? [23:22] how do you solve that? [23:22] Also, people forgot to update that file. [23:22] maybe ;) [23:22] If it's a separate XML, sure. [23:23] i agree that life would be easier with that [23:23] of course it's a separate xml file [23:23] Then \o/ [23:24] so how do you solve that? [23:24] a file that tells which files NOT to translate? [23:24] Nope, just move it to 'libs-common'. [23:24] * knome facepalms [23:24] i don't think that can be the answer for everything [23:24] it's NOT a common thing [23:25] Well, we could move anywhere you want - just not leave it in the main docs dir. [23:25] well... [23:25] i'd actually rather have it there :] [23:27] Oh, and yes, it's a common thing - between the C docs and the translations. [23:27] Just not the most appropriate place maybe. [23:27] "libs...", that is. [23:28] well, yeah, kind of... [23:28] i would be happy with a file that listed files excluded from translations [23:28] of course that's not ideal either, but hey... [23:28] that file could be in libs-common [23:29] i don't think we will have the problem that there's a file with the same name in both docs and we want to translate the other but not the other :P [23:29] And for the CC license, also shared between the two doc variants. [23:29] that's fine where it is [23:37] For XMLs specific to only *one* of the doc variants, I guess both the easiest and most transparent way to do it would be to create a subdir within the main docs dir for them. [23:38] That way we don't have to maintain and parse a lists file for them. [23:38] meh [23:38] :) [23:38] * list [23:39] i wonder if there could be any way to add a docbook attribute or something that told the script creating the pot file to not include strings in that file [23:40] That'd be one for *you* then, yep. :P [23:41] Either way, that doesn't affect my current changes. [23:42] well i don't think there is a way [23:42] xml2po is very simple [23:50] krytarik, flocculant's merge is done, ready to take your MP [23:50] Ugh. :D [23:50] ;)= [23:50] I'll work on it tomorrow. [23:50] Because I'll have to merge quite some files manually. [23:51] :)