[00:12] <ali1234> okay, i think it is in my PPA now
[00:14] <ali1234> or not- connection timed out when uploading :/
[00:19] <skellat> Here's the example cited in the wiki docs you're looking for: https://launchpad.net/bugs/173082
[00:21] <ali1234> brb after rebooting router
[00:32]  * skellat disappears for a while
[00:33] <ali1234> https://launchpad.net/~a-j-buxton/+archive/xfce/+packages
[00:34] <ali1234> http://paste.ubuntu.com/6292199/
[00:36] <brainwash> I'll test it tomorrow on my test machine
[00:37] <brainwash> and you should add a comment about your ppa and the updated package in the lp report
[00:38] <ali1234> let's see if it builds first
[00:40] <brainwash> I really should learn how to build and publish packages for a PPA
[00:41] <ali1234> it's quite easy
[00:42] <ali1234> the hardest part is modifying the package
[00:42] <micahg> ali1234: you can copy the version from my PPA if it helps (for libxfce4ui-1, ppa:micahg/patch-test)
[00:43] <brainwash> there was just no need for it yet, maybe I can fix something and publish an updated package for testing just like you :)
[00:43]  * micahg is behind on backscroll
[00:43] <brainwash> users-admin comes to mind >.<
[00:43] <ali1234> micahg: i looked at your xfce4-panel package, i don't understand what is going on with that at all... why it has no configure script?
[00:44] <micahg> I fixed most of it (it has no configure since I grabbed a git snapshot
[00:44] <ali1234> running autogen.sh before generating the orig.tar.gz doesn't work either, it makes loads of new files that aren't in the previous version
[00:44] <micahg> I have the packaging generating it
[00:44] <micahg> the problem is I only got it working in a chroot, not a clean one
[00:44] <micahg> that's why I haven't uploaded yet, been a bit busy with work, I can probably poke some tonight
[00:45] <ali1234> ah... so maybe there's some magic for autogen.sh to build a "release" type package?
[00:45] <ali1234> or .tgz rather
[00:45] <micahg> yeah, I got that part, the only issue is the the potfiles right now
[00:47] <ali1234> when i built it direct from git it was missing some dependencies
[00:47] <ali1234> something to do with gnome-doc
[00:47] <micahg> I fixed that
[00:47] <micahg> well, added the needed dependencies
[00:47] <ali1234> gtk-doc-tools
[00:48] <micahg> yeah
[00:48] <ali1234> i didn't notice any other problems... it would always tell me when running the autogen.sh anyway
[00:48] <ali1234> i never got weird cryptic build errors
[00:50] <ali1234> maybe adding the dependencies is not the solution - maybe it needs some special configuration so that it doesn't even try to do that stuff
[02:44] <Noskcaj_> micahg: Any progress on pkg-xubuntu team?
[02:45] <Noskcaj_> Does anyone want me to package the new gthumb? It so far seems pointless since debian doesn't want it and no one here seems to either
[02:47] <Noskcaj_> Also, can someone update the topic with something trusty related?
[02:47] <skellat> Noskcaj_: Why doesn't Debian want gthumb?  Low popcon score?
[02:47] <skellat> Noskcaj_: As to the topic, ask knome to fix it.
[02:48] <micahg> Noskcaj: no, been busy, on my list
[02:48] <Noskcaj_> skellat: I've not found anyone willing to upload, plus the gnome team says it's not gnome enough
[02:49] <skellat> Noskcaj_: How far is the packaged version diverging from what is released in the wild?
[02:49] <micahg> Noskcaj: we'll take it, but I just need a little time
[02:49] <Noskcaj_> skellat: i don't fully understand your question, but the current version is very outdated
[02:50] <skellat> Noskcaj_: It's been a weird day for me.  You caught my meaning, though.
[02:52] <skellat> Noskcaj_: It looks like the DM hasn't found an adopter to let Debian Bug #711827 get cleared up yet.  That's been open for five months now.
[02:53] <Unit193> knome: Trusty Tahr schedule http://ubottu.com/y/trustysch  and the Xubuntu roadmap: http://ubottu.com/y/xubmap
[03:39] <Unit193> Reminder that there is a scheduled meeting tomorrow.
[03:42] <skellat> Unit193: 1500 UTC?
[03:44] <Unit193> "the next Xubuntu community meeting is at Thursday, October 24 at 15UTC on #xubuntu-devel on the Freenode IRC network."
[03:46] <skellat> In other words...yes...
[06:23] <Unit193> brainwash: First time getting this on resume: https://www.dropbox.com/s/rb00k7spkdetgtf/failed.png
[06:55] <astraljava> knome: Noskcaj: We got ours at Studio side (@ubuntustudio.org) just recently. I wasn't part of the organizing committee, so don't know the details.
[07:05] <Noskcaj> thanks for the info astraljava 
[08:09] <brainwash> ochosi: take a look at this http://forum.xfce.org/viewtopic.php?id=8375
[08:10] <elfy> good lord - I forgot I had an account there
[08:10] <elfy> it didn't
[08:10] <elfy> Last visit: 2012-07-30
[08:10] <Unit193> It's a forum, so I don't. :D
[08:11] <elfy> :)
[08:11] <brainwash> that's our bug 1232804
[08:14] <brainwash> Unit193: this resume problem is still a mystery.. the bug report gets spammed with comments about the fix to re-enable the network manager, no real debugging has been done yet
[08:14] <brainwash> and pitti is not affected :/
[08:15] <Unit193> Yeeeep.  Not really sure what I can do.
[08:15] <brainwash> ubuntu's systemd-shim is most likely the culprit
[08:15] <Unit193> Yes, lets blame that. :D
[08:15] <elfy> brainwash: I found this morning that I was affected by another power manager thing - subscribed xubuntu to it
[08:15] <elfy> systemd-shim is fix on the way I Thought
[08:15] <elfy>    Status: New => Fix Committed
[08:16] <elfy> But indeed logind is a rather
[08:16] <elfy> critical piece of infrastructure these days, so I lifted the recommends to a depends.
[08:16] <brainwash> different bugs
[08:16] <elfy> didn't read much - not awake much either :)
[08:17] <brainwash> on the one hand it can be missing or it can be removed, on the other hand it could be the cause of the resume from suspend problem
[08:18] <brainwash> yea, I should have added systemd to the list of affected package earlier
[08:20] <brainwash> mmh, is bug 1116643 still around?
[08:22] <astraljava> brainwash: That resume from suspend bug, networking doesn't work after, or is this another thing? I have it happen randomly. Sometimes works, but hard to give any numbers.
[08:22] <brainwash> yeah, it happens randomly, sometimes more frequently as reported by other users
[08:23] <brainwash> bug 184262
[08:23] <brainwash> woops
[08:23] <brainwash> bug 1184262
[08:23] <brainwash> ^ this one
[08:24] <elfy> brainwash: yes - 1116643 is still around - it was definitely around at 7:30 am and then at 7:40 am - hence me me too'ing it and subscribing us :)
[08:24] <elfy> biab
[08:24] <elfy> and hi astraljava 
[08:26] <brainwash> usually you could use the systemd cli tool to get some information about system jobs involved in this matter.. but ubuntu only uses a wrapper for systemd calls and does not ship this tool (it would be broken)
[08:30] <brainwash> elfy: so the power button does nothing at all or triggers the shutdown sequence immediately without asking the user (dialog)?
[08:30] <astraljava> Hi elfy.
[08:31] <Unit193> astraljava: Hello.
[08:31] <astraljava> Unit193: Hello there, how's life?
[08:33] <Unit193> I don't even know... You?
[08:37] <Unit193> brainwash: I saved some random logs from last time, guessing of no use?
[08:38] <brainwash> Unit193: some? did you notice any suspicious warning or error message?
[08:39] <astraljava> Unit193: It's very odd, but I refuse to complain. I've done enough of that in the past. *smirk*
[08:40] <astraljava> Ahh... too bad the timing of the meeting is unfortunate for me, got choir practice.
[08:41] <Unit193> brainwash: I pasted the one, and "b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)" seems odd only because I use b43. :P
[08:41] <Unit193> astraljava: Bad for me too.
[08:44] <brainwash> Unit193: ok, doesn't look that odd or suspicious. the whole thing _could_ be cause by the kernel, I read comments of other distros about a similar issue and reverting back 3.10 did help
[08:45] <Unit193> brainwash: Not exact kernel at least, maybe 3.11 in general.
[08:45] <Unit193> uname -r: 3.11-4.dmz.1-liquorix-686
[08:47] <brainwash> I did install 3.12 on my test machine, but it almost never fails to resume properly anyway (logind and network-manager)
[08:47] <brainwash> so I'm still waiting for it to fail
[08:51] <brainwash> but same for my laptop with kernel 3.11... now that I'm monitoring everything it simply did not fail yet :/
[08:54] <slickymaster> good morning all
[09:11] <brainwash> ali1234's patched xfce4-terminal package is now available for download, https://launchpad.net/~a-j-buxton/+archive/xfce
[09:12] <elfy> brainwash: yep - press power button - shutdown commences with no 'ask' dialogue
[09:12] <brainwash> it fixes bug 1206739 and needs some testing
[09:13] <brainwash> elfy: right, that's systemd listening to the power button press
[09:15] <brainwash> edit /etc/systemd/logind.conf and add "HandlePowerKey=ignore"
[09:16] <brainwash> and test again
[09:20] <elfy> brainwash: so that successfully didn't make any difference :p
[09:21] <brainwash> try again, but I'm sure changes to the config file are applies immediately
[09:21] <elfy> I did - restarted and had another go - no change
[09:26] <brainwash> check "gdbus introspect --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 | grep HandlePowerKey"
[09:26] <brainwash> should be set to ignore
[09:27] <elfy> readonly s HandlePowerKey = 'ignore';
[09:27] <elfy> why do we want it to ignore anyway - given that I've set power manager to ask?
[09:28] <brainwash> because 2 different programs are reacting to lid-close and power-button-press actions, systemd and xfce4-power-manager
[09:28] <brainwash> and xfce4-power-manager lacks the ability to inhibit systemd's actions as of now
[09:29] <brainwash> so now systemd got told to do nothing, but the system sill shuts down o.o
[09:30] <brainwash> you could try to kill xfce4-power-manager and test again
[09:30] <brainwash> make sure it does not get restarted by xfce4-session
[09:31] <elfy> trying a bit later - off again now 
[09:35] <brainwash> cya
[09:56] <ochosi> slickymaster: yes, please report bugs in bugzilla
[09:56] <slickymaster> ochosi: good morning
[09:57] <slickymaster> ochosi: ok, will do. I think I'll have the command options page, in the staging site, ready in about an hour. Do you want me to ping you so you can take a look to see if I'm doing something wrong?
[09:58] <ochosi> slickymaster: great! sure, do that
[09:58] <slickymaster> ochosi: ok
[10:00] <ochosi> brainwash: yeah yeah, i understand it's an annoying issue, that session-loading transition ;)
[10:00] <ochosi> also, the problem with xfce4-power-manager is that it's currently not maintained and doesn't support systemd
[10:19] <brainwash> ochosi: lightdm-gtk-greeter does set the root background and it remains after login, the question currently is, why is xfwm4 (the compositor) not able to copy it
[10:19] <brainwash> it only works if the root background gets set again by a tool like feh
[10:19] <ochosi> how did you check that the root bg remains set after login?=
[10:20] <brainwash> well, you login and it is still visible
[10:20] <brainwash> before even xfdesktop shows up
[10:20] <brainwash> http://bazaar.launchpad.net/~lightdm-gtk-greeter-team/lightdm-gtk-greeter/trunk/view/head:/src/lightdm-gtk-greeter.c#L1302
[10:21] <brainwash> "/* Open a new connection so with Retain Permanent so the pixmap remains when the greeter quits */"
[10:22] <ochosi> right, that explains that
[10:22] <brainwash> currently I've added feh to xinitrc (before the xfce4-session)
[10:22] <ochosi> but as you said, that makes it odd that xfwm4 wouldn't be able to pick it up
[10:22] <brainwash> right
[10:23] <brainwash> https://github.com/derf/feh/blob/master/src/wallpaper.c#L498
[10:23] <ochosi> mhm, same method as used in the greeter
[10:24] <ochosi> the only logical assumption (to me) is that there's something that scraps the root bg
[10:27] <brainwash> feh does call XChangeProperty to change some properties
[10:28] <brainwash> and xfwm4 does XGetWindowProperty
[10:29] <brainwash> yeah, probably that
[10:30] <brainwash> I'll test that and report back
[10:38] <ochosi> great, thanks!
[10:48] <slickymaster> ochosi: unfortunately, and due to a work assignment, I haven't finished the command line page, but I'll get back to it after lunch. I just want you to take a look to what I've done so far in order to confirm if what I've done is what is intended
[10:48] <slickymaster> ochosi: http://smdavis.us/doku/doku.php?id=command-line
[10:49] <ochosi> slickymaster: looks good to me
[10:50] <slickymaster> ochosi: ok, thanks. I'll pick up on it later on
[10:50] <ochosi> slickymaster: and no stress ;) after all, you're a volunteer so we're happy you're helping us out
[10:50] <slickymaster> ochosi: np :)
[10:51] <ochosi> slickymaster: btw, there are a few small formatting differences to be ironed out
[10:51] <ochosi> see that as reference: http://docs.xfce.org/apps/terminal/command-line
[10:51] <ochosi> (well i guess you did, but if you need help with the formatting, lemme know)
[10:51] <slickymaster> ochosi: yeah, I know. I'm not happy about the formatting either
[10:52] <ochosi> but no worries, that's a minor thing that can be taken care of in minutes
[10:52] <slickymaster> ochosi: one of the things I'm struggling with is indentation
[10:53] <ochosi> slickymaster: well there are standards you can use, i can show you the source of the terminal's page if you want
[10:53] <ochosi> (i guess as you only have read-only access you don't see the source)
[10:54] <slickymaster> ochosi: no, I do manage to see the command line source
[10:54] <ochosi> ok, then just use the same formatting they use there
[10:54] <ochosi> consistency ftw
[10:55] <slickymaster> ochosi: but are the standards used there applicable in dokuwiki? 
[10:56] <ochosi> slickymaster: no, not for documentation purposes. the only standards that matter here for us is the rest of the xfce docs
[10:56] <ochosi> it should simply be in line with that so that users are not confused when checking the docs
[10:57] <slickymaster> ochosi: I see
[10:58] <ochosi> despite it's name, dokuwiki isn't made for documentation purposes in this sense (afaik)
[10:58] <ochosi> i see it simply as an easy-to-use wiki
[10:58] <slickymaster> ochosi: dokuwiki is a bit scarce in what formatting options is concerned 
[11:01] <ochosi> slickymaster: indeed, but as i said, don't worry bout that too much. as long as parole-docs are consistent with the rest of xfce, we're fine
[11:01] <slickymaster> ochosi: ok, thanks
[11:02] <ochosi> slickymaster: well thank you, and ttyl
[11:03] <slickymaster> knome: FYI https://code.launchpad.net/~slickymaster/xubuntu-docs/xubuntu-docs/+merge/192413 related to https://bugs.launchpad.net/ubuntu/+source/xubuntu-docs/+bug/1243946
[12:12] <jjfrv8> ochosi, sorry I wasn't around yesterday for the discussion on the Parole docs
[12:12] <jjfrv8> I had some questions and issues I wanted to run by you or bluesabre and I was hoping I could catch you guys today
[12:13] <knome> jjfrv8, we have a meeting at 15UTC, that is, in a little less than 3 hours :)
[12:13] <jjfrv8> Yeah, that's why I was hoping today would be a good day.
[12:14] <jjfrv8> I'll be there for the meeting
[12:14] <knome> cool
[12:14] <knome> slickymaster, yep, i got notifications of that :)
[12:18] <jjfrv8> ochosi, a couple of the questions were on formatting...
[12:19] <jjfrv8> first, I think we might still be missing a plugin. I can't get Definition List to work on bluesabre's wiki
[12:20] <jjfrv8> second, I don't know how to get the Gtk and Xfwm themes installed that they want for the screenshots
[12:21] <jjfrv8> I don't know if that really matters, I think my screenshots look pretty much like theirs in the Terminal example
[12:21] <jjfrv8> but we'll need to standardize them among all of us who are working on Parole, no?
[12:23] <jjfrv8> ochosi, the other issues are with the dev version of Parole
[12:23] <jjfrv8> I can't get it to work at all in vbox
[12:23] <knome> jjfrv8, what kind of errors do you have?
[12:23] <jjfrv8> it works for most things on my test hardware but I still have issues with playing dvds
[12:24] <jjfrv8> knome, I'll get the exact error for you in a sec, let me fire it up.
[12:24] <knome> sure
[12:26] <jjfrv8> knome, "GStreamer backend error" "Could not initialise Xv output"
[12:26] <jjfrv8> I get that when I try to play any kind of media
[12:27] <knome> that's weird
[12:27] <knome> have you installed xubuntu-restricted-extras?
[12:27] <jjfrv8> Oh yeah
[12:27] <knome> try that, and if that doesn't work, keep poking bluesabre 
[12:27] <knome> that's out of my area of expertise
[12:27] <jjfrv8> mine too :)
[12:28] <ochosi> hey jjfrv8 
[12:28] <jjfrv8> afternoon, ochosi 
[12:28] <ochosi> ah, so you're in my tz :)
[12:28] <ochosi> so, your questions?
[12:29] <jjfrv8> no, but I know where you are :)
[12:29] <ochosi> oh
[12:29] <ochosi>  :)
[12:30] <ochosi> jjfrv8: so what questions did you have?
[12:32] <jjfrv8> Some about formatting, others about issues/bugs with Parole and how you want me to file/handle them
[12:32] <jjfrv8> did you seem my posts from a few minutes ago?
[12:32] <ochosi> yes, the dvd playback error
[12:32] <ochosi> not sure, that could be vbox related
[12:33] <ochosi> problem is, i don't have any dvds here so i can't test anything
[12:33] <jjfrv8> and the formatting issues with the wiki?
[12:33] <ochosi> yeah, i'll check what plugin we need for that
[12:33] <ochosi> and inform bluesabre to put it in
[12:34] <ochosi> lemme check the theme they use
[12:34] <jjfrv8> re the Definition Lists, not a biggie, but for indenting, now we have to use bullets, even if it's only one line
[12:34] <ochosi> the xfwm4 theme is fine
[12:35] <ochosi> well, it will be there as soon as i copy the contents over to the xfce wiki
[12:35] <ochosi> which we can do as soon as your part is reviewed
[12:35] <ochosi> so i'd say stick to the same formatting markup as we wanna have in final
[12:35] <ochosi> no matter if it looks a bit off now
[12:35] <jjfrv8> ok
[12:36] <ochosi> what packages did you install to get the gtk theme?
[12:37] <jjfrv8> you know what? I can't remember :(
[12:37] <ochosi> hehe
[12:37] <ochosi> no problem
[12:38] <ochosi> i'll check what pkg you need
[12:40] <ochosi> jjfrv8: you need the package gtk2-engines-xfce
[12:40] <ochosi> that also installs the gtk-themes
[12:41] <ochosi> so then we can stick to the rules of the xfce-docs (which i think is the easiest)
[12:41] <ochosi> and you got the icon-theme, right?
[12:42] <jjfrv8> No, I tried installing faenza, but that seemed to mess things up for some reason.
[12:42] <jjfrv8> i could be wrong, but I don't think icons will matter for screenshots in Parole, will they?
[12:43] <ochosi> not terribly
[12:44] <jjfrv8> I was using Greybird for Appearance, Default for the WM style and a custom highlight color in Theme Configuration
[12:44] <jjfrv8> I'll install the gtk2-engines-xfce package
[12:45] <ochosi> ok great
[12:46] <jjfrv8> just as a watchout for the other guys, I found that if you need to replace a screenshot, it's a pain...
[12:46] <jjfrv8> you can't just upload another file and overwrite the previous one. It keeps using the first one you created.
[12:47] <jjfrv8> You have to rename the file and change the reference in the source code to the new name. :(
[12:52] <ochosi> jjfrv8: are you sure?
[12:53] <ochosi> i mean, are you sure it's not just your browser tricking you?
[12:53] <ochosi> try ctrl+shift+r e.g. in firefox
[12:53] <ochosi> that clears the cache and reloads
[12:54] <jjfrv8> Ok, I'll double-check that. But I actually removed the reference to the screenshot in the code, saved and viewed, then added it back, saved again, and it still displayed the old file.
[12:55] <knome> if things do not go as expected, i might be slightly late for the meeting, but i will be here.
[15:01] <pleia2> anyone about for the meeting?
[15:01] <jjfrv8> o/
[15:02] <slickymaster> o/
[15:02] <pleia2> knome said he'd be slightly late
[15:02] <knome> HAI
[15:02] <elfy> hey ho pleia2 - here comes piskie :)
[15:02]  * ochosi is kinda around
[15:03] <pleia2> 8AM, boo
[15:03] <knome> hehe
[15:03] <elfy> :)
[15:03] <knome> so,
[15:03] <knome> #startmeeting Xubuntu community meeting
[15:03] <meetingology> Meeting started Thu Oct 24 15:03:32 2013 UTC.  The chair is knome. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:03] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[15:03] <knome> #topic Items carried on
[15:03] <slickymaster> it's the early bird whocatches the worm
[15:03] <knome> #subtopic Open action items from previous meetings
[15:03] <GridCube> ø/
[15:03] <knome> #action knome to prepare the website for the desktop of the week 
[15:03] <meetingology> ACTION: knome to prepare the website for the desktop of the week
[15:03] <GridCube> :) thanks
[15:04] <knome> #info knome tries to have time for that latest next week
[15:04] <knome> #action skellat to prepare blog article discussing updating & upgrading for users and why it is okay to do so 
[15:04] <meetingology> ACTION: skellat to prepare blog article discussing updating & upgrading for users and why it is okay to do so
[15:04] <knome> #nick skellat
[15:04] <GridCube> #info GridCube will be ready whenever knome needs his asistance
[15:04] <knome> that's it for the open action items
[15:04] <GridCube> yes, i mean the desktop of the weeks thing
[15:04] <GridCube> :)
[15:04] <knome> let's postpone the strategy document review for a bit, we have more news about it
[15:04] <GridCube> i tiped slow
[15:05] <knome> #subtopic Ideas for using the project money
[15:05] <knome> #info Discussion will continue on the mailing lists
[15:05] <knome> #topic Team updates
[15:05] <GridCube> i though we had agree to that already
[15:05] <knome> partly, not wholly
[15:05] <GridCube> ok
[15:05] <knome> ok, everybody, is there any news?
[15:05] <knome> (remember to use #action and #info)
[15:05] <knome> i'm afk for 2mins
[15:06] <GridCube> i've been tracking the reviews for xubuntu around
[15:06] <GridCube> and watching the responses on the main channel
[15:06] <elfy> #info  Planning for testing of LTS is moving on http://pad.ubuntu.com/SdHxBbkLTO
[15:06] <GridCube> most reviews says that our desktop is "simple" and "minimalist"
[15:06] <elfy> # Some input from -team on various aspects of that is required
[15:07] <elfy> #info  Some input from -team on various aspects of that is required
[15:07] <elfy> even
[15:07] <pleia2> #info Published latest in "Xubuntu at" series: http://xubuntu.org/news/xubuntu-at-techs-for-a-cause-in-kansas-city/
[15:08] <pleia2> #info If anyone else knows of people using Xubuntu in the wild, please send them my way :)
[15:08] <knome> elfy, looks good
[15:08]  * elfy saw the draft of that - nice :)
[15:08] <knome> GridCube, for me, that sounds like what we are after - cool! we should add those reviews to the press page
[15:08] <knome> GridCube, if you have a list of them, can you send it to the -devel ML?
[15:08] <GridCube> ok
[15:08] <knome> #info knome has still one "Xubuntu at..." -series mail QIP
[15:08] <knome> WIP too
[15:09] <knome> #action GridCube to send a list of Xubuntu reviews to the -devel mailing list
[15:09] <meetingology> ACTION: GridCube to send a list of Xubuntu reviews to the -devel mailing list
[15:09] <GridCube> knome, there is a few people that complains about that though
[15:09] <knome> GridCube, let's discuss that in the "wrap-up saucy" bit. remind me...
[15:09] <knome> any other updates?
[15:10] <elfy> #info Elfy is half way through doing an QA Saucy roundup
[15:10] <knome> elfy, you've kept yourself busy :)
[15:10] <pleia2> indeed!
[15:10] <elfy> :)
[15:10] <elfy> on holiday apparently ... 
[15:11] <pleia2> knome: mention edits to strat guide?
[15:11] <knome> pleia2, i'll speak about that later :)
[15:11] <elfy> knome pleia2 - I want to make more use of the xubuntu.org page for getting QA information out there - so a roundup seems like a good place to start
[15:11] <knome> but yeah, i could
[15:11] <pleia2> l
[15:11] <pleia2> k
[15:11] <knome> #info knome and pleia2 reviewed the strategy document a bit further...
[15:11] <pleia2> elfy: great, we all should make more use of it
[15:12] <knome> elfy, definitely1
[15:12] <knome> ! too
[15:12] <knome> #topic Annoucements
[15:12] <knome> so,
[15:12] <knome> as some of you acknowledge, this is my second and last term as the XPL within the extended term
[15:13] <GridCube> :)
[15:13] <knome> so that it doesn't come as a surprise, and the project can plan accordingly, i'm announcing it will stay at my last for now; to put it differently, i'm not seeking for another extension
[15:13] <pleia2> :'(
[15:13] <elfy> sad but unexpected 
[15:13] <elfy> expected ... 
[15:13] <knome> i will keep around though, for consulting and more, but i wish to focus on different things in the community for a change
[15:15] <knome> and finally, i hope to get the community and the infrastructure in a good shape before i quit
[15:15] <knome> my main goals for this cycle is to get at least one more contirbutor upload rights and to finalize the strategy document review so it can actually be helpful in the daily work
[15:16] <pleia2> ++
[15:16] <knome> other goals include, but are not limited to finalizing long-term projects, like getting some new apps uploaded and making logging/locking/shutting down consistent
[15:17] <GridCube> :)
[15:17] <GridCube> sounds good
[15:17] <knome> anyway, there seems to be another announcement in the wiki:
[15:17] <knome> #info skellat article about upgrading is in progress and can be found at lp:~skellat/+junk/UpgradingXubuntu 
[15:17] <knome> since skellat isn't around, let's move on
[15:17] <knome> #topic New and emerging items
[15:17] <knome> #subtopic Strategy Document reviewing
[15:18] <knome> so, as mentioned in the updates, me and pleia2 worked more with the SD
[15:18] <pleia2> it was boring, knome caught me off guard as I was wrapping up work
[15:18] <knome> ha!
[15:18] <pleia2> :)
[15:18] <knome> anyway, we were able to strip off all process-related stuff from the strategy document
[15:18] <knome> what this means?
[15:18] <knome> well, the processes are now listed in https://wiki.ubuntu.com/Xubuntu/Processes
[15:19] <knome> the goal is to make that separate from the strategy document and allow more flexibility and updating the process descriptions while we go
[15:20] <pleia2> \o/
[15:20] <pleia2> and hopefully with the shortening of the strategy document it'll be easier for folks to actually read
[15:20] <knome> i also hope these could be more helpful for new contributors, specifically the release cycle process description
[15:20] <knome> and that we could keep that updated, so when we start a new cycle, everybody knows what's going to happen
[15:20] <knome> and yeah, to keep the strategy document shorter, and to the point
[15:21] <knome> changing things in the strategy document shouldn't be easy, but after this last set of changes it *shouldn't* be easy.
[15:22] <knome> err, first shouldn't -> isn't
[15:22] <knome> basically, the SD should only describe what our long-term goals and core ideals are
[15:22]  * pleia2 nods
[15:22] <knome> describing how we plan a release isn't such a thing
[15:23] <knome> #action knome to make sure latest draft for the new SD is available for everybody before next week
[15:23] <meetingology> ACTION: knome to make sure latest draft for the new SD is available for everybody before next week
[15:23] <GridCube> i would like it very much if we could get people who develops xfce to join us to review the SD
[15:23] <GridCube> if our goals and theirs dont collide its well 
[15:23] <GridCube> its not good
[15:23] <knome> can you shed some light why do you think it would be beneficial?
[15:24] <knome> after all, our SD says that something being xfce-related doesn't mean it should be automatically included in xubuntu, or by that nomination, be preferred over something else
[15:24] <GridCube> well if they decide to go a road that we can not easily follow,or we decide to go a road that they dont wish to go (like just for example the mir issue) then we are going against the thing that makes us different
[15:25] <GridCube> no ofcourse not
[15:25] <knome> if they decide to do something we don't agree with, then we need to either rethink our mission or drop the component that is against our mission
[15:26] <GridCube> as said, I, myself, think it would be nice to have someone upstream to review it and give their impressions
[15:26] <GridCube> just that
[15:27] <knome> while xubuntu is ubuntu with xfce, i personally do not think xubuntu is "the xfce OS", or that we should without constructive criticism and thought follow the way they are leading
[15:27] <ochosi> i'm wondering whether the SD isn
[15:28] <knome> i am not sure i see how it would be beneficial still
[15:28] <ochosi> 't too xubuntu-specific and probably not too interesting for xfce devs
[15:28] <GridCube> (i'd like to think xubuntu is not just one more of the xfce distros outhere but a very important one, i might be wrong ofcourse)
[15:28] <knome> i'm pretty sure some of the xfce people disagree with some of our goals, or the means to reach them, or whether we have reached them or not
[15:28] <GridCube> anyway, it was just a wish, lets move on
[15:29] <knome> i think i'm also with ochosi on being not-too-interesting for them :)
[15:29] <GridCube> i wouldnt hurt to ask
[15:30] <knome> i suppose we could forward the SD to their development list once the rewrite is done
[15:30] <GridCube> mmhm :)
[15:30] <knome> (this last rewrite didn't really change anything re: xfce, just internal procedures and stuff)
[15:31] <GridCube> i was thinking more about the whole gtk3 indicators issue
[15:31] <knome> that's been discussed with them
[15:31] <knome> and tbh, that's a non-SD related issue
[15:31] <ochosi> yeah, and that's more a roadmap item 
[15:31] <GridCube> but again, lets move on
[15:31] <knome> (or it should be)
[15:31] <knome> #subtopic Developer communication and coordination in IRC
[15:32] <knome> ok, i just wanted to let you guys know that we *really* should use #xubuntu-devel for development discussion, not -offtopic
[15:32] <knome> it keeps the development transparent and logged
[15:32] <GridCube> alright, sounds fair
[15:33] <knome> #info Use #xubuntu-devel for development discussions, not #xubuntu-offtopic (where you are of course encouraged to socialize with other developers)
[15:33] <GridCube> can i note that we should not use -offtopic for devel things aswell
[15:33] <knome> well that's what i said ;)
[15:33] <GridCube> oh ahahaha i missreaded
[15:33] <GridCube> i swapped the channels
[15:34] <knome> heh.
[15:34] <knome> #subtopic Translating the website, LP 797600
[15:34] <knome> can't remember who set this agenda item up, but
[15:34] <GridCube> olbi probably
[15:35] <knome> anyway, the relevant comment: https://bugs.launchpad.net/xubuntu-website/+bug/797600/comments/6
[15:35] <knome> pleia2, what do you think of that?
[15:35]  * pleia2 reads
[15:35] <knome> we would be able to do this without any translation plugins, and the text itself could be something that was useful for flyers and stuff as well.
[15:35] <pleia2> seems messy
[15:35] <pleia2> but possible
[15:36] <knome> not really, as long as the languages are a subpage of a page
[15:36] <knome> that's of course just one of the options
[15:36] <knome> i was thinking that would also help the burden for translators short- AND long-term
[15:37] <ochosi> can't we handle the translations via launchpad?
[15:37] <knome> ochosi, website translations?
[15:37] <knome> humm,
[15:37] <ochosi> something like putting the source of xubuntu.org on lp
[15:37] <knome> heh.
[15:37] <knome> the problem is how to *handle* those translations
[15:37] <knome> but that's another idea.
[15:37] <ochosi> on the wordpress-side, you mean?
[15:37] <knome> yep
[15:37] <ochosi> right
[15:37] <knome> i mean, even for this translate-one-page
[15:38] <ochosi> well you're the wp-expert, i've never handled translateable installations ;)
[15:38] <knome> we could create a simple plugin that loads a page and serves alternative languages from .po files
[15:39] <knome> but that's somewhat fishy as well
[15:39] <knome> let's see how i have time during the next cycle
[15:39] <knome> maybe i might be able to finish off my translation plugin as well
[15:40] <knome> #subtopic Wrap up the Saucy cycle; things we did well, areas to improve, postponing blueprints to T, ... 
[15:40] <knome> so...
[15:40] <knome> GridCube, people not liking xubuntu?
[15:40] <knome> or thinking it's too simplistic...
[15:41] <GridCube> yes
[15:41] <GridCube> the reviews i've seen are a bit dissapointed with us
[15:42] <GridCube> i understand that they have to show new shinny things and we dont provide that
[15:42] <GridCube> and over that we even give away a desktop that has an obvious broken indicator issue
[15:42] <knome> so what they are saying is that we didn't provide enough new features for them?
[15:42] <ochosi> from what i read the broken sound-indicator is quite a bummer for most upgraders
[15:42] <ochosi> (unsurprisingly)
[15:43] <GridCube> knome, basically they say that there is no reason to install 13.10 whatsoever
[15:43] <knome> the broken indicators situation sucks.
[15:43] <GridCube> just wait for next LTS waht most of them say
[15:43] <ochosi> and there are some logind/suspend issues
[15:43] <knome> from my POV, we progressed more "behind the curtains" than in front of
[15:44] <GridCube> knome, yes, i do understand that, im not saying not, as said they need to show new thingies to their readers
[15:44] <GridCube> they could copy paste the review from 13.04 and it would still work
[15:44] <brainwash> we have a new wallpaper, this is a major change!
[15:44] <GridCube> yeah... 
[15:44] <knome> heh, i read a review that said you can barely notice it unless you compare the two next to each other
[15:44] <GridCube> not even a few wallapers to choose
[15:45] <knome> that's highly subjective though
[15:45] <brainwash> the average xubuntu/xfce user does not like fancy changes anyway, things should simply work
[15:45] <GridCube> yeah well, also some said that basic xubuntu needs about 500mb of ram with nothing open
[15:45] <pleia2> speaking of reviews, can you pleia2: me when you find one? http://xubuntu.org/press/ doesn't have many at the moment
[15:45] <knome> brainwash, that's a dangerous generalisation to make
[15:46] <knome> brainwash, probably more true with xfce users, but i don't know about xubuntu users
[15:46] <GridCube> pleia2, i've been pasting some on -offtopic
[15:46] <GridCube> but sure
[15:46] <knome> so;
[15:46] <pleia2> GridCube: I can't read full backlogs of that channel, so highlight here is appreciated
[15:46] <GridCube> :D
[15:47] <GridCube> most of them did say that our system almost never crash and its fast
[15:47] <knome> pleia2, i understand, it's icky enough that most of us can't
[15:47] <ochosi> sorry folks, gotta go, have a goo drest of a meeting
[15:47] <knome> 1) we need to get the fixed indicator stack in the backports soon
[15:47] <knome> 2) people want new features, but we didn't provide them those; we will with 14.04
[15:47] <GridCube> :)
[15:48] <knome> i think the indicator stack issue is one of the things where we could've done better
[15:48] <knome> releasing with them was a decision taken, not an accident though
[15:48]  * GridCube wasnt really involved to notice how broken that was
[15:49] <elfy> knome: not sure how - it was down to time for the few that could do anything 
[15:49] <knome> it was known for a long time, but fixing it in a way or other wasn't trivial
[15:49] <elfy> indeed
[15:50] <knome> elfy, i suppose we should've asked for more external support and/or generally just going for the gtk3 stack because we "need" that for 14.04 anyway
[15:50] <elfy> possibly - I don't know enough about the ramifications of that to comment :)
[15:50] <knome> and a lot of that discussion could have happened earlier in the cycle, even/especially amongst those who couldn't do the final heavy lifting
[15:51] <knome> and that might've given the people who were able to do the heavy lifting more time to do it
[15:51] <knome> anyway, i think it was a good cycle community-wise
[15:51] <elfy> as far as I know it was being discussed in here almost as soon as it showed up
[15:51] <knome> and as i said, more things seemed to happen behind the curtains than in front of
[15:52] <elfy> yea definitely
[15:52] <knome> elfy, the gtk3 indicator stack was a possible direction at the beginning of the cycle, though at that point it wasn't as clear how broken the gtk2 indicators would've been (but maybe we would've found out...)
[15:53] <knome> and - congrats to everybody who contributed
[15:53] <GridCube> the overall status of xubuntu is impressive, if i can say, i mean besides the gtk3 indicators i dont think there is a single complain that is not subjetive
[15:53] <knome> 13.10 is a good stepping stone for 14.04, which will be, i'm sure, the best xubuntu LTS out there
[15:53] <elfy> :)
[15:53] <GridCube> ;D
[15:53] <elfy> it's be tested - that's for sure :p
[15:53] <knome> that too!
[15:54] <knome> the agenda has a mention of postponing blueprints/work items for T, but we'll do that later
[15:54] <knome> Unit193, you around?
[15:54] <knome> #subtopic Xubuntu Core (or xubuntu-core)
[15:54] <knome> i'm thinking we should carry on this item for the next meeting
[15:55] <elfy> I agree with that
[15:55] <GridCube> third
[15:55] <knome> #subtopic Schedule next meeting
[15:55] <GridCube> o/ 
[15:55] <knome> GridCube, oi?
[15:55] <GridCube> i want to ask something for 14.04
[15:56] <GridCube> i've read on a review this; 
[15:56] <GridCube> xfce4-power-manager-plugins is not installed by default, and in 13.10 is now hidden under technical items in the software center.
[15:56] <GridCube> This means that the users who can't get their brightness buttons working have to know all of that as well as how to add the brightness manager to the panel to see it at all. That is unacceptable for a newbie to linux.
[15:56] <knome> i don't know enough of that to say this or that
[15:56] <GridCube> i've heard a lot of people comming to the channel to ask about brightness and this is the first time i've learned that xfce has a tool for it
[15:56] <knome> we need to look at it
[15:56] <GridCube> i would like this to be investigated
[15:56] <GridCube> :) yes
[15:57] <knome> can you add that to the roadmap page in the discussion?
[15:57] <knome> https://wiki.ubuntu.com/Xubuntu/Roadmap
[15:57] <GridCube> in lp¿
[15:57] <GridCube> ok yes
[15:57] <knome> thanks
[15:57] <knome> so, next week is the end of brainstorming
[15:57] <knome> we should discuss the roadmap then, so let's schedule a meeting for next week
[15:58] <knome> #info Next Xubuntu community meeting: Thu, Oct 31st, 15UTC at #xubuntu-devel
[15:58] <knome> #endmeeting
[15:58] <meetingology> Meeting ended Thu Oct 24 15:58:44 2013 UTC.  
[15:58] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/xubuntu-devel/2013/xubuntu-devel.2013-10-24-15.03.moin.txt
[15:58] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/xubuntu-devel/2013/xubuntu-devel.2013-10-24-15.03.html
[15:58] <knome> thanks
[15:58] <knome> i'll add the minutes in the wiki later today
[15:58] <elfy> thanks knome 
[15:58] <elfy> and everyone else too :)
[15:59] <elfy> biab
[15:59] <GridCube> done knome 
[16:00] <knome> ta
[16:00] <GridCube> ø\
[16:01] <pleia2> thanks knome 
[16:02] <knome> ok, i'm off again
[16:02] <knome> see you later
[16:03] <jjfrv8> ochosi, I'll be back around 22UTC tonight and then back tomorrow around 12.
[16:04] <jjfrv8> I think Preferences is pretty much ready for review - except for one bug I have to discuss with bluesabre.
[16:04] <jjfrv8> I don't think I'm qualified to do the Introduction so the only one left is Usage. I can move onto that but don't want to conflict with efly or slickymaster 
[16:06] <slickymaster> jjfrv8: I'm wrapping up the Command-line Options, I think I'll have finished later on
[16:07] <jjfrv8> cool
[16:07] <slickymaster> jjfrv8: but I don't know if elfy is going to pick up on Usage or not
[16:12] <jjfrv8> bbl
[16:21] <elfy> slickymaster: doubt it - or not any time soon - still catching up with myself
[16:23] <slickymaster> elfy: np. If jjfrv8 is unable to do it, I'll do it.
[16:23] <elfy> ok - thanks :)
[17:00] <slickymaster> ochosi: http://smdavis.us/doku/doku.php?id=command-line ready for review. Ping me if you want/think that there's any changes need to be done
[17:19] <brainwash> ali1234: your terminal package works
[17:20] <brainwash> ali1234: what's the deal with 1.2?
[17:25] <ali1234> brainwash: well, i uploaded it as ubuntu2 the first time
[17:25] <ali1234> then i rad you're not supposed to number it that way so i changed it to 1.1
[17:25] <ali1234> but i didn't change it everywhere
[17:25] <ali1234> so then i deleted the 1.1 and tried to upload it again but fixed but this is not allowed
[17:25] <ali1234> so i had to bump it to 1.2
[17:25] <brainwash> I see =S
[17:26] <brainwash> the fix works, the package works, everything seems ok
[18:33] <Unit193> knome: Now that I've read backlog, pretty much yes. :P
[18:55] <elfy> pleia2 knome - when you've got time can one of you look at the draft qa roundup I did for the blog
[20:11] <Unit193> andrzejr: I take it you haven't contacted the Ubuntu desktop team about actually releasing what's being used in Ubuntu as far as indicators?
[20:18] <knome> andrzejr, we really want the gtk3 indicator stuff in 14.04, if you need any help with organizing anything, please ask us
[20:19] <Unit193> knome: Hello, I ponged but it was too late. :P
[20:20] <knome> Unit193, yeah, np. was just wondering if you wanted to lead the discussion or not.
[20:20] <Unit193> Not really. :P
[20:22] <knome> well clearly not, you hid until the meeting ended! :P
[20:22] <Unit193> It'd be nice if whoever does actually knew what they were talking about though.  So I still see it as something to install from the mini iso, is this wrong?  It changes how it's made if you use some sort of black magic to get it in Ubiquity.
[20:22] <Unit193> Found a good hiding place, what can I say?
[20:22] <slickymaster> good night all
[20:22] <knome> heh. yeah.
[20:22] <knome> hey slickymaster 
[20:22] <slickymaster> hi knome 
[20:40] <elfy> knome: looks ok - but I'm not sure about a beer tasting of gooseberries
[20:55] <Unit193> knome: Please to speak about goals on that?
[20:57] <Unit193> knome: And one thing that'd help ^ is actually having Ubuntu *release* the NG indicator stuff, right now Ubuntu is basically rolling from git and hogging it to itself. :P
[21:00] <andrzejr> knome, any particular requests for the indicator plugin?
[21:05] <knome> andrzejr, as long as it works...
[21:06] <knome> andrzejr, i can't speak of the technical side, you should be in touch with ochosi, bluesabre and micahg on that
[21:08] <xnox> Unit193: what's your question?
[21:08] <andrzejr> knome, ok
[21:08] <elfy> Unit193: I've got to say - I imagined the core being something to install via mini iso 
[21:09] <Unit193> xnox: Hmmm?  I had a couple questions, but wasn't trying to ping you (yet)
[21:09] <xnox> Unit193: re: "It'd be nice if whoever does actually knew what they were talking about though.  So I still see it as something to install from the mini iso, is this wrong?  It changes how it's made if you use some sort of black magic to get it in Ubiquity."
[21:09] <xnox> Unit193: i have highlights on "ubiquity"
[21:10] <knome> xnox, speaking about a "xubuntu-core" metapackage, but we're undecided yet.
[21:10] <Unit193> Yeah, figured that.  It's nothing yet, didn't mean to ping.  We're looking at a xubuntu-core thing and I'm not quit sure the target. :)
[21:10] <andrzejr> knome, the biggest problem at the moment is that the plugin depends on xfce4-panel from my private git branch. Nick promised to merge the changes but until it is done we should not assume the panel will support mixed gtk2 and gtk3 plugins.
[21:10] <xnox> Unit193: installing from netboot, mini.iso, server.iso, desktop.iso is all valid methods. To be honest it doesn't matter how one installs. If one installs xubuntu-desktop, one gets xubuntu experience. One may need to adjust alternatives/themes if one installs multiple.
[21:10] <Unit193> xnox: The things I meant to ping you about, no chance of shipping a /usr/share/pixmaps/ubiquity.xpm and /usr/share/menu/ubiquity, right?
[21:11] <knome> andrzejr, yep, we definitely need to be in touch with nick as well
[21:11] <xnox> knome: "xubuntu-core" might make sense as a seed one includes, given that there are multiple flavours basing on top off xubuntu. E.g. common bits between Studio and Xubuntu can be placed into xubuntu-core, or "xfce-core"
[21:11] <Unit193> xnox: There really is a difference though, if you install using apt-get, you will pull in a ton of useless deps because you don't get the nice blacklist, so you rather have to install without recommends.
[21:11] <xnox> knome: e.g. edubuntu has a few seeds - for core stuff, for server and desktop.
[21:12] <knome> xnox, that's not exactly what we are after, but... that's a valid point i suppose
[21:12] <knome> xnox, would be probably more like the edubuntu stuff, without thinking what ubuntu studio wants too much
[21:13] <xnox> knome: Unit193: oh I see. So in edubuntu they have: edubuntu-desktop for the "core" stuff and then additional components via "edubuntu-desktop-physics", -math, -education, etc.... since not everyone would want everything.
[21:14] <xnox> and then some e.g. install edubuntu + edubuntu-physics, or edubuntu & -whatever.
[21:14] <knome> xnox, a bit like that, but reverse; the usual installed component would be -desktop, and those who want a minimal installation could install just -core instead
[21:14] <xnox> knome: boot edubuntu installer, it's quite different from other flavours. And let's one to add/remove components.
[21:14] <knome> (which would still ship a usable desktop, but with less stuff)
[21:14] <knome> xnox, yeah, i've seen that
[21:15] <knome> xnox, i believe that's what ubuntu studio wants actually
[21:15] <xnox> knome: quite, so you might customize / fork edubuntu ubiquity plugin to select component & default to -desktop and optionally remove / fallback to -core only.
[21:15] <xnox> knome: right, i might put them that way.
[21:15] <knome> that, or the other option is that it's just a metapackage that's installable from the minimal iso, for those who know what they are doing.
[21:16] <xnox> knome: if you do split -core and -desktop, a small tweak will be needed to make it "top-level" metapage and then e.g. netbook / minimal.iso can offer Xubuntu Core & Xubuntu Full.
[21:16] <knome> mhm
[21:16] <xnox> knome: right, that should be fine as well.
[21:16] <knome> that's what we're pondering now
[21:17] <xnox> knome: or we can even spin Core images which might even fit on a smaller CD / bussiness-card cd.
[21:17] <xnox> knome: well you do need to start with splitting what's core and what's desktop. and then add it to seeds branch (but not -meta package) and look at the germinate output to see how big the difference is.
[21:18] <xnox> At that point, you might add it as a package in your -meta and then figure out if you want to ship it on images and how.
[21:18] <knome> xnox, yyyyep.
[21:18] <xnox> Cause e.g. if -core ends up being 100MB you might go for mini.iso, if it ends up 400MB you might would want to roll a desktop.iso
[21:19] <knome> we most probably do not want another ISO
[21:19] <knome> and i doubt -core would end up being 100MB either..
[21:19] <Unit193> Not in my tests, no. :/
[21:19] <knome> or generally either
[21:19] <xnox> ok. then your -desktop will need to be a strict supper-set of core, or ship the extra packages that are in -core and not in -desktop on the cdrom pool/
[21:19] <knome> after all, we want to make it a usable desktop
[21:20] <xnox> cause e.g. ubiquity livefs does _not_ have oem-config. it gets installed from the package pool on the cd when needed ;-)
[21:20] <xnox> knome: i remember puppy-linux was a <<30MB usable graphical desktop.
[21:20] <knome> well, the oem config didn't work for us when we last tested it, so... :P
[21:20] <knome> but we share the ubuntu core. not possible...
[21:21] <Unit193> xnox: But yeah, any chance of getting /usr/share/pixmaps/ubiquity.xpm and /usr/share/menu/ubiquity in ubiquity-frontend-gtk or somesuch?
[21:21] <xnox> knome: ok, that was just an example. E.g. ndiswrapper is a .deb in the cdrom package pool and is not actually installed by default, but it is available of the desktop CD.
[21:21] <knome> i mean, i wouldn't mind, but...
[21:21] <xnox> Unit193: yeah easy, just do a merge proposal against lp:ubiquity
[21:21] <xnox> Unit193: and i'll take it.
[21:21] <knome> Unit193, \o/
[21:21] <Unit193> xnox: Fantastic!  Got a default image I can/should convert rather than ask ochosi for one? :P
[21:22]  * xnox just assumes that nobody cares about .xpm & menu's anymore. If xubuntu does then fine.
[21:22] <Unit193> It generally slips my mind too, unless something breaks.
[21:22] <xnox> Unit193: it should be the ubiquity.svg as it's in the branch and/or ubuntu-default theme. It's quite generic "instlaler" looking icon.
[21:23] <Unit193> Cool.
[21:24] <Unit193> (Trick is doing it without breaking something.)
[21:25] <xnox> Unit193: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/humanity-icon-theme/trusty/view/head:/Humanity/apps/48/ubiquity.svg
[21:26] <xnox> Unit193: that's ubiquity icon to use as source.
[21:26] <Unit193> Great, will do.
[21:26] <xnox> Unit193: i think it might be in ubiqutiy source, it's best if you add debian/rules which takes ubiquity.svg and converts to .xmp at build time.
[21:26] <Unit193> ./data/icons/32x32/apps/ubiquity.svg ?
[21:27] <Unit193> (I'd use 32 as Debian menu policy wants that.)
[21:27] <xnox> Unit193: yeap /data/ubiquity.svg
[21:27] <Unit193> Right, my bad.
[21:28] <xnox> Unit193: .svg is actually size indepenant, but xmp does need size specified.
[21:28] <xnox> Unit193: 32x32 looks ugly =) so I tend to do bigger than that ;-)
[21:28] <knome> xpm too.
[21:29] <Unit193> xnox: Understandable, and I could technically do that, but I was going to just try and follow policy. :P
[21:48] <Unit193> xnox: Hrm, not sure how best to handle the menu file...  data/Makefile.am is designed for .desktop files and /usr/share/applications/  Icon is a simple imagemagick convert.
[21:50] <xnox> Unit193: usually people just write menu file by hand
[21:50] <xnox> Unit193: and it can be installed by debian/ubiquity-frontend-gtk.install
[21:50] <xnox> Unit193: or better by dh_installmenu
[21:50] <xnox> Unit193: see $ man dh_installmenu
[21:51] <Unit193> xnox: Ah, wasn't sure if you wanted the RELEASE var.
[21:52] <xnox> Unit193: call it ubiquity without RELEASE for now.
[21:52] <Unit193> xnox: You mean Ubuntu? ;)
[21:52] <xnox> Unit193: RELEASE substitution happens on cdimage during image build, and placed on the desktop.
[21:52] <Unit193> Ah.
[21:53] <xnox> Unit193: and we are not putting menu file on the desktop.
[21:53] <xnox> Unit193: use something genering like "Ubuntu Installer" or "Ubiquity Installer"
[21:54] <Unit193> Gotcha.
[21:55] <Unit193> xnox: And just to confirm, you don't want to install with 'ubiquity' and have ubiquity itself figure out gtk_ui or not?
[21:56] <xnox> Unit193: huh, no. it needs to be installed as "ubiquity" menu item xmp in the "ubiquity-frontend-gtk" package.
[21:56] <xnox> Unit193: we are not going to use menu items on kde, and it will need a different one anyhow.
[22:14] <Unit193> Man, there's not a good way to test this...
[22:28] <Noskcaj> My comments to the meeting: 1. I'll try and get motu or xubuntu-dev next month, assuming people think i'm ready. 2. Xubuntu is definately using too much memory, thunar, xchat and bluetooth are the ones i've seen. 3. We did well in saucy minus the indicator issue. We really need to fix that this month so we've got plenty of time to fix all that. 
[22:29] <brainwash> the printer-applet uses much memory too
[22:29] <brainwash> and it's not even visible anymore, or?
[22:31] <Noskcaj> brainwash: Open the task manager and see how much blueman has. before i disabled it, it said 40mb and i had never used bluetooth
[22:34] <brainwash> it's not even installed anymore
[22:34] <brainwash> got rid of it long long time ago
[22:46] <Unit193> xnox: Back from food, http://paste.openstack.org/show/49580/ look sane?  I can't build it so not as tested as I'd like, it may not be doing what I want.
[22:47] <xnox> Unit193: why can you not build it?
[22:48] <xnox> Unit193: no that looks wrong. build-depends are generated from a script in d-i/ folder something like "update-control" i think.
[22:48] <xnox> $ mk-sbuild trusty
[22:48] <xnox> $ change into it, apt-get source ubiquity
[22:48] <xnox> apply patch and do a debuild
[23:25]  * skellat is not amused he missed the meeting earlier today due to having to orchestrate getting an automobile fixed...and assumes it wasn't what was meant in "service orchestration" in those Juju talks...
[23:34] <Unit193> Well if we assume the [18:48:16] < xnox> Unit193: no that looks wrong. build-depends are generated from a script in d-i/ folder something like "update-control" i think.
[23:35] <Unit193> Bah, lag.  If we assume that works, this builds then.