[00:09] ochosi: I don't think so [00:09] ochosi: see http://media.cdn.ubuntu-de.org/wiki/attachments/00/17/UG1304-Install11.png for example [00:09] (ubuntu gnome) [00:09] that is ubuntu gnome? [00:09] right [00:09] well you can always check whether metacity or mutter check for other flags [00:09] for showing/hiding the maximise button [00:10] there is also no.. uhm.. menu button? [00:10] the "v" on the left side [00:10] maybe we could hide that too [00:13] sure we could [00:13] but it's a minor issue, fixing the black background and the missing panel is more important [00:13] the panel hasn't been there for ages and we haven't received a single bugreport about it, so i'd still tend to call it minor [00:14] wishlist [00:15] I don't know how it would work anyway [00:15] a blank panel + indicator-plugin? [00:15] And super simple to fix, I just did... [00:16] tell us more [00:17] It's not really a "fix" so much as to figure out why it's not enabled. [00:18] what does it enable? [00:18] panel with default configuration? [00:21] Unit193: the suspense... [00:21] ochosi: I'm looking into the black screen bug, shush. [00:21] :D [00:21] * ochosi keeps quiet [00:22] * Unit193 vomits. [00:22] I just turned it into a bright green screen bug. [00:22] hihi [00:22] well done! [00:23] do you actually debug it? [00:23] xfsettingsd seems to get stuck or crash [00:23] so it does not load xfdesktop [00:29] i don't think xfdesktop gets loaded by settingsd, but rather session [00:30] but that should be possible to unriddle [00:32] it just feels like someone else (ubuntu guys) should solve the puzzle [00:33] wow, upower0.99 is definitely slower at recognising when i plug in my ac adapter.. [00:33] or just use a simple method to draw a background [00:33] not sure, there could always be a regression in xfdesktop [00:34] anyway. night all! [00:34] good night [00:36] https://sigma.unit193.net/dm xfsettingsd normally has some more errors too, but there you go. [01:18] Well it's all functioning, but does it matter how I got it? :P [01:45] Right, so I suppose I should link to what I have, even if not pretty: Found this: http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/4258 and ended up "fixing" the problem with http://paste.openstack.org/show/cOc2Q8RI2KhuWhZoWNgd/ --sm-client-disable isn't technically needed, but it's nice. Last bit of course does the panel, but we should find out why it's disabled first. [04:38] ochosi: One thing to note, if we hear back from the desktop team as to why the panel was disabled, and decide to go ahead with it we'll change it for UbuntuStudio and presumably Mythbuntu too. [07:41] Unit193: nice work, the diff seems to make sense [07:42] i've pinged away in #u-desktop about it [07:42] we'll see what comes of it [07:42] morning ochosi [07:42] morning elfy [07:43] good to hear the meeting time works for you :) [07:43] heh [07:43] not that there's much for me to say [07:45] @irc_savvy_folks (knome?): can we somehow quantitatively evaluate with which clients users connect to #xubuntu? i was just wondering whether we can create an empirical basis for deciding whether to keep xchat out of our seed or not [07:45] ochosi: Error: "irc_savvy_folks" is not a valid command. [07:47] hrrm, something in vivid broke my bluetooth keyboard :'( [07:47] "k" is now interpreted as "2" and "l" as "1" [07:47] makes it hard to type with it [07:49] you'll know how really annoyed I got with that ibus issue in trusty now then :p [07:51] muahahaha [07:51] found the "fix" in a forum-thread from 2011: "turn your numlock switch off on laptop's keyboard" :D [07:52] so for some reason, having numlock enabled makes the keyboard think it is a numpad [08:45] elfy: i guess in your call for testing for the panel you really need to explain what intelligent hiding is. seems i have to explain this to people time and time again to be sure... [08:53] Unit193: nice work, just tested [08:53] the a11y options from the panel indicator don't work, so we might be missing some things there in the seed, but other than that it's premium stuff [08:54] just so that everyone knows what we're talking about: http://www.zimagez.com/zimage/screenshot-2014-12-10-095440.php [08:56] Unit193: my suggestion is that you file a merge-request against ubiquity with the changes that fix xfdesktop first, then we send an email to the studio and myth guys about the panel [08:59] the ubiquity panel is still a bit ugly though, i'll have to see whether/how it can be themed... [09:04] yuck, it's using a pixmap as background [09:32] Unit193: erhhm, i guess we need to either paint the bg in ubiquity with something like feh or consider restricting xfdesktop somehow. at least if we think that creating additional workspaces or this is problematic: http://www.zimagez.com/zimage/screenshot-2014-12-10-103126.php [09:32] you can't launch much, mostly xfce4-settings stuff [09:34] you could also consider it an easter egg i guess [09:34] or a way to test the theming of ubiquity [09:43] ochosi, that would require doing CTCP queries for each person who joins the channel [09:50] knome: hm, i thought that at least pidgin appended some "purple" somewhere in the user string and that webirc users were easy to detect based on username, so i guess i assumed the same would be true for xchat somehow [09:53] it can set the username, but you can most definitely override that [09:54] or it can even set the realname as purple... [09:54] and tbh, you can fake even the CTCP version reply... [09:54] or simply hide it [09:54] yeah sure [09:54] but that it has to be [09:55] 11:54 CTCP VERSION reply from ochosi: irssi v0.8.15 - running on Linux x86_64 [09:55] i guess we could ask freenode-staffers as they keep internal statistics [09:59] or create a poll. interacting with the community is a good thing [10:00] Unit193: finally some good news :) [10:00] poll represents a userbase that is willing to fill in a form, ctcp queries represent anybody who is not hiding/spoofing their ctcp version, which is likely a bette representation [10:01] yeah, but will freenode share this data? [10:01] not every xubuntu user joins our channels [10:01] of course not. [10:02] brainwash: just for the fun of the info, changing the window manager theme in ubiquity back and forth seems to remove the maximize button ;) [10:02] i don't know if freenode will share the data (or if they even have channel-specific data), but technically it wouldn't be a problem to catch the data ourself, if it was socially ok to do that [10:02] ochosi: that's strange :D [10:04] ochosi: the menu button "v" can be only removed via a custom xfwm config (menu button layout), or? [10:04] yes [10:04] we could also create a special wm-theme just for ubiquity [10:05] ;) [10:05] with a custom button layout we could hide the menu button + strange max button [10:06] ok, so freenode no longer collects this sort of data and they have scrapped all the older/existing stats [10:06] too many problems with making sense of it [10:06] (e.g. clients that re-connect a lot skewing the distribution) [10:54] hey guys, whats up? [10:59] ochosi: No idea how it did it before, so I may be going the entirely wrong direction. [11:01] Hah, and I was either about to mp or poke about that artwork thing you just pushed. :P [11:09] hey bluesabre [11:09] Unit193: yeah, one of the few commits to -artwork each cycle ;) [11:10] i guess there is little harm in loading xfdesktop, but yeah, i think it just used to be a gsettings-key and then ubiquity took care of painting the background itself [11:10] bluesabre: Read any backlog on the black stuff? [11:10] maybe that would still work if it wasn't for that line to paint it black [11:10] ochosi: Nope. [11:10] Unit193: could you try to just remove the black line ^? [11:10] oh [11:10] you tried that then :) [11:11] About the first one, also made sure it did something: < Unit193> I just turned it into a bright green screen bug. [11:11] oh right [11:11] weird, why bright green though... [11:12] Not really, not if you s/black/green/ [11:12] i guess we could also use xsetroot to set the background to a pixmap [11:13] which would be our wallpaper [11:13] Not as-is. [11:13] but might have to poke xnox about that [11:13] ochosi: UbuntuStudio is a-ok with the panel, fwiw. [11:13] ah nice [11:13] ok, so only mythbuntu to contact then [11:13] And xsetroot won't do it, not a bitmap. [11:13] do you know anyone there? [11:14] ehm, that suggests otherwise: http://lesstif.sourceforge.net/doc/super-ux/g1ae01e/chap1-7e.html [11:14] (-bitmap flag) [11:14] Tried that. [11:15] xpm too? [11:15] png is the only one I tried. [11:16] something like ['xsetroot', '-xpm', '/lib/plymouth/themes/xubuntu-logo/wallpaper.png'], [11:16] xsetroot: bad bitmap format file: /usr/share/xfce4/backdrops/xubuntu-wallpaper.png [11:16] or -pixmap [11:16] I didn't try any others with that, went on to figure out what was going on. [11:19] if we installed xloadimage we could use "xsetbg /path/to/file.jpg" [11:19] Or we could just use feh, since the support is already there. :P [11:19] i don't have serious reservations against using xfdesktop, it just seems a li'l overkill [11:19] right, feh [11:19] that would only have to be installed, right? [11:20] So basically, if we don't like xfdesktop, then we could just add that to the live seed. [11:20] What does bluesabre think? :D [11:20] yeah, what does he think indeed [11:21] i guess if we show the panel btw, i guess i'll submit a MR against ubiquity to add our own panel background. the one provided suuuucks [11:21] (I'd actually prefer to just have a plain css background, but well) [11:23] That's a lot of guessing. And re: know anyone in US, zeque was the one I poked, he's the you of US. [11:25] but know anyone in mythbuntu was my question :) [11:26] from their website it doesn't seem obvious who is who [11:26] haven't caught up yet [11:26] can I get a quick summary of where we are? [11:27] ok [11:27] Unit193 fixed our black screen installer problem [11:27] nice [11:27] and he added in a panel for the ubiquity session [11:27] that shows indicators [11:27] a11y, network, sound [11:28] using xfdesktop is generally cool, but overpowered: http://www.zimagez.com/zimage/screenshot-2014-12-10-095440.php [11:28] we could also try to disable all clicks on the desktop with xfconf switches though [11:28] or install feh [11:28] and this ^ is where you come in :) [11:28] Well, I did something that would technically work yes. [11:29] gotcha [11:29] Since he's the lead dev, he'll want to see http://paste.openstack.org/show/5tdMtrpbA1MNLZCPtzqQ [11:29] well, I'm generally in favor of having the installer use less memory [11:30] with feh [11:30] and that may balance with including the panel [11:30] well the panel is sorta independent [11:30] i would go for including that either way [11:30] agreed [11:30] it's baked into ubiquity and just displays some indicators [11:30] (although i don't get why date/time can't be there..) [11:31] I see now [11:31] so that fixes the issue with the defunct xfsettingsd ? [11:31] Yes, but it was restricted from being shown for some reason... [11:31] bluesabre: Not quite, no. [11:31] ah [11:32] Unit193: those reasons might be historical though, like no support for indicators in xubuntu [11:32] You just end up with two. :P [11:32] lol [11:32] At least one works... [11:33] I'd be in favor of swapping with feh for rendering the desktop at install time... it worked for me at least twice [11:33] I never said I was the best to figure it out, just started wondering about it. :P [11:33] that's the only way we'll ever figure it out, so keep up the good work :) [11:33] +1 [11:34] ok, let's try feh next then [11:34] actually the whole ubiquity session is sorta for nothing anyway... [11:34] we could just always start xubuntu's live mode and open ubiquity via autostart [11:35] then you have maximum flexibility/a11y [11:35] [11:35] heh [11:35] a weird xml namespace that has that tag. [11:35] the only benefit i see is the reduced mem usage i guess [11:35] ...which might be good in some cases [11:36] cool, let me know if you need anything from me... need to head to work now [11:36] knome: yeah, i think many browsers don't display that tag ;) [11:36] actually i don't know how much less the ubiquity session uses [11:36] especially with the indicators loaded [11:36] Unit193: ^ any clue? [11:36] bluesabre: So there is actually a change that needs done in ubiquity itself or not? [11:36] well xhtml is just a specific xml namespace... you can technically create a namespae that allows that tag ;) [11:37] ochosi: No idea about that xml namespace, nope. [11:37] gah :) [11:37] Unit193: yes, I have the details in that bug report (wherever it is) [11:37] the (visual) interpretation is up to the application that parses the namespace ;) [11:37] bluesabre: Wasn't sure if the line numbers changed, but cool. [11:37] Unit193: mem usage comparison!! (stop messing with me, i'm hungry for lunch!!) [11:37] haha. :) [11:38] bluesabre: will we see you @meeting tomorrow? [11:38] Unit193: if yes, not by much... ubiquity doesn't change often [11:38] marco support. [11:38] ochosi: no can do, will be starting my commute then [11:38] bluesabre: oh crap. alrighty then. we'll talk another time [11:39] will try to update the agenda when I get home tonight [11:39] and tackle a few tasks [11:39] bluesabre: OK, thanks. Bye. [11:39] Seeya guys [11:39] hf! [11:41] knome: what do you think of replacing the "current" wallpaper in vivid with a generic "devel/inprogress" wallpaper each cycle? [11:41] so at the beginning of cycle, bump plymouth-text and swap wallpapers to devel so it's visually clear that it's not utopic anymore [11:41] (could be the same devel wallpaper each cycle) [11:42] works for me [11:42] as far as i'm concerned, it could even be a solid color until we land the wallpaper [11:44] but i don't mind it being something else either, can design one [11:44] i mean "design"... lay out something that looks better than a solid color :) [11:44] ^ [11:44] :) [11:44] sounds good to me [11:45] you can add a work item for me [11:45] got to run soon [11:45] okeydokey [11:45] done [11:50] noticed, ta [11:50] shower, brb [11:51] And I do know a bot that CTCPs version checks people, and does even remember people for a while so it doesn't hit the same people that often. [11:52] right, we'd need pre-14.10 and post 14.10 stats i guess [11:53] Right, give me a time machine and I'll get right on that. [11:54] * ochosi hands over a time machine to Unit193 [11:54] And that'd be the last time you saw me. :P [11:55] go back and punch bill gates in the dick [11:56] AgAu: That's entirely uncalled for. [12:04] ochosi, there's a discrepancy between your mail to the ML and the https://wiki.ubuntu.com/Xubuntu/Meetings, regarding the hour of the meeting [12:05] is it to be at 18:00 or 22:00 ? [12:06] slickymasterWork: thanks, i'll update it (the link is correct though ;)) [12:07] if the wiki weren't so slow, it'd be done already... [12:07] cause i hit "save" like a minute ago or so [12:07] lol, want me to update the team calendar, or will you do it? [12:07] calendar should be fine i think [12:07] no it's not :P [12:08] it's 10 PM = 22.00 UTC [12:08] yeah, that's correct [12:08] 22utc is the correct time [12:08] ok, i'm going now [12:08] see you later [12:08] seeya knome [12:08] 17:00:00 EST [12:09] oh, I thought you were saying that 18:00 was the correct hour [12:09] (hello and goodbye slickymasterWork :)) [12:09] bbabl [12:09] have fun knome [12:09] you also ochosi [12:11] ochosi: mark bug 1401075 as dupe of bug 1347272 ? [12:11] bug 1401075 in xfce4-power-manager (Ubuntu) "xfce4-power-manager icon not shown, settings don't open" [Undecided,New] https://launchpad.net/bugs/1401075 [12:11] bug 1347272 in xfce4-volumed (Ubuntu) "Several XFCE applications appear unresponsive after communicating with a daemon" [High,Triaged] https://launchpad.net/bugs/1347272 [12:14] according to the latest comments in the second report, people want fixes for trusty [12:15] Because it's an "LTS" [12:16] we should care more about trusty, but it's not possible I guess [12:17] sru'ing or backporting various fixes [12:53] ochosi: not quite what I was getting at - do we assume people can take responsibility for upgrading panel only from the staging ppa? if they install it and update/grade they'll get new mousepad etc too :) [13:08] elfy: providing the right instructions, they won't get a mousepad upgrade. and yeah, providing simple revert-instructions will be necessary too [13:09] So, add PPA, sudo apt-get install xfce4-panel, test, ppa-purge. [13:10] I guess that'll do [13:11] I'm running it now, but I don't use hiding, so it's a bit pointless. [13:11] but doing it that way people won't be testing constantly - so we'd be unlikely to see any odd bugs that might show up [13:36] elfy: yeah, you can mention that it'd be good to just use it for a few days [13:36] technically, there shouldn't be any new bugs in that panel version [13:38] Unit193: could you package the xfpm 1.4.2 release for trusty so we can copy it to the 4.12 PPA? [13:38] i'd just copy over the one from -staging, but since it's a snapshot [13:39] ochosi: Going to update the rest for trusty/utopic too? [13:40] the rest? [13:45] referring to xfwm4 and all the other updates? [13:46] generally it'd be nice to get all those into the 4.12 PPA [13:46] but my focus for now was to provide xfpm1.4, because it's a rather big jump there [13:47] OK [13:49] http://paste.openstack.org/show/xP1npdsAEFyRtTWxhxJJ/ Generally. [13:51] wait, xfdesktop hasn't been backported yet? [13:51] i was pretty sure a newer version of it was in trusty already [13:52] so if you can/want, i'd update: xfwm4, xfdesktop, xfce4-settings, xfce4-session, parole, libxfce4ui, xfpm [13:57] Unit193, bluesabre: just got the OK from superm1 (mythbuntu) on adding the panel to ubiquity-dm with xfwm4 [14:01] !info xfdesktop4 trusty [14:01] xfdesktop4 (source: xfdesktop4): xfce desktop background, icons and root menu manager. In component universe, is optional. Version 4.11.6-1ubuntu1 (trusty), package size 131 kB, installed size 525 kB [14:01] right, so .6 [14:01] i guess .8 won't hurt [14:49] !info xfdesktop4 trusty-proposed [14:49] xfdesktop4 (source: xfdesktop4): xfce desktop background, icons and root menu manager. In component universe, is optional. Version 4.11.8-0ubuntu0.1 (trusty-proposed), package size 134 kB, installed size 545 kB [14:51] stuck in -proposed, because someone tested it, noticed that there is some regression/breakage and marked it as "verification failed" [14:53] https://bugs.launchpad.net/ubuntu/+source/xfdesktop4/+bug/1365965/comments/4 [14:53] Launchpad bug 1365965 in xfdesktop4 (Ubuntu Trusty) "[MRE] Please update xfdesktop4 to 4.11.8 in Trusty" [Undecided,Fix committed] [14:55] will it be stuck forever? no one seems to provide additional feedback === brainwash_ is now known as brainwash [16:16] anyone using vivid and locking screen - does it work? [16:17] I can test it elfy, if you'll give a few seconds to end the install of our staging ppa [16:19] ok, I've set it to 10 seconds [16:19] slickymasterWork: no - just lock the screen from whisker please [16:19] ah, ok [16:20] yeaps, it's working [16:20] must be local then - thanks slickymasterWork :) [16:20] np elfy [16:36] ochosi: you can g+ that now https://lists.ubuntu.com/archives/xubuntu-devel/2014-December/010498.html [16:36] pleia2: could you socialise it more please :D [16:39] so far the Intelligently option is working quite well [16:56] knew I should have read the thing again before sending it === GridCube is now known as GrinchCube [16:58] * drc looks around and finds Max cowering in the corner. [17:02] elfy, so far the Intelligently option is working quite well [17:03] ochosi: ok - so is this a bug with intelligent hiding, have window maximised - rollup the window - panel stays hidden [17:05] I can confirm that [17:07] thanks slickymasterWork [17:09] ochosi, i'll twitter that if that's ok with you [17:10] hi sidi [17:10] or if you have a Xfce version [17:10] hi elfy [17:10] pleia2: As requested (a long time ago in 'net-time :) http://www.dedoimedo.com/computers/xubuntu-utopic.html [17:14] elfy: as long as the window is overlapping the panel it's fine [17:18] ochosi: no it's not - I have panel at bottom, window was alt+6'd - vert max, panel hides, rollup title bar - panel remains hidden [17:21] interesting [17:21] let me try that then [17:22] so maximize a window, then roll it up? [17:22] elfy, ochosi i think basically there are cases where you forget to update, i dont know what the code architecture looks like but it's probably good to watch too many events than not enough [17:22] ochosi: yea - but obviously you need panle at the bottom [17:22] Hey, concerning my place in Xubuntu development team... I love you guys, but I found that Xubuntu doesn't suit my day to day productivity needs... There are some issues (though pretty minor) that have just added up, and escalated... Xubuntu unfortunately is not the most stable of Linuxes, so I am thinking of switching to a more stable, rolling release... I still will help you to improve Xubuntu though, and translate if you g [17:22] uys want to. [17:22] or is it because the geometry you get from a rolled up window is incorrect? [17:23] sidi: my guess would be that wnck size isn't updated when rolling up [17:23] but anyway, let me first reproduce it [17:23] of course we want to etwarrior [17:24] ochosi, elfy, I'm facing that issue with the panel at the top [17:24] Xubuntu is good, and I thought about just switching to plain Ubuntu even, but that distro is just too mainstream... I believe in helping "smaller branches." [17:24] slickymasterWork: well with panel on top it's obvious, cause the window will be in the way of the panel [17:24] slickymasterWork: not sure how that would work tbh - rolling it up - and the title bar would still be at the top where the panel is [17:24] elfy: i can reproduce [17:24] drc, that owl wallpaper is very very cool. [17:25] ochosi: ok - I'll report it then :) [17:25] of course, don't mind silly slickymasterWork guys :P [17:25] duh [17:25] slickymasterWork: :) [17:26] np slickymasterWork [17:26] My other problem guys, is the fact that I am such a newbie to Linux... it's a bit stressful to me to always have to research how to fix something in Linux, whereas I am more familiar with Mac OS for instance... but I wanted to switch to Linux for a couple reasons... my Mac had a tendency to freeze if too many system resources were used up, and the software was pricey. Linux is open-source for the most part... and it has a go [17:26] od ability to compress RAM usage, and system resources. [17:27] I guess I'll take this in off-topic, since this is strictly development talk, sorry. [17:28] etwarrior: np, and thanks! :) [17:28] elfy: we have that disabled in xubuntu by default though, right? [17:28] yea - but I undisable it as I use it a lot :) [17:29] ok cool [17:29] that's exactly the kind of testing i wanted [17:29] even though i hate that there is yet another bug [17:29] woohoo :) [17:29] yea - that sucks - but better to find them early than late I guess :) [17:30] exactly [17:30] so thanks [17:30] welcome ofc :) [17:31] xfce 11371 [17:31] xfce bug 11371 in Panel "Intelligent Hiding: Panel stays hidden with rolled up window" [Normal,New] https://bugzilla.xfce.org/show_bug.cgi?id=11371 [17:32] ok cool [17:33] ok - also replied to the dev thread so others know how we'd like it done [17:44] yeah, crap, i think i see the problem [17:44] guess i have to figure that out with ofourdan [17:52] elfy: shared [17:54] pleia2: thanks :) [17:56] ochosi: well at least you can see it - all I'd be able to see is the result of what you see :D [18:02] ochosi: quick question - do you see the 'dekstop freeze' issue when deleting things from desktop in vivid? [18:25] * pleia2 adds link from drc to http://xubuntu.org/press/ [18:27] knome: thoughts on this one? http://mylinuxexplore.blogspot.com/2014/11/xubuntu-1410-utopic-unicorn-review.html [19:27] pleia2, well at least it looks somewhat comprehensive, so why not [19:28] k [20:15] bluesabre: the logind-handle-lid-switch property is set to "false" via xubuntu-default-settings. the logic behind it was inverted in xfpm 1.4 I think. so, is it still OK to set this value via default-settings in utopic/vivid? [20:16] could be the reason, why people are seeing the blackscreen issue in 14.10 again [23:37] evening folks [23:39] ahoy bluesabre [23:39] hey ochosi [23:39] you're still around! :O [23:39] yeah, why not ;) [23:39] brainwash: was thinking we flipped it... will check into that. [23:39] i mean even ofourdan is active again, it seems the world is coming to an end soon [23:40] so why sleep? [23:40] :) [23:40] I'm sorry to say that I don't think I am going to partake in helping with the development of Xubuntu... I was shown an article that is quite disturbing regarding Ubuntu and Canonical... [23:40] https://www.gnu.org/philosophy/ubuntu-spyware.html [23:41] oh geez, is that FUD still circulating? [23:41] It is such a nice community here, and it's a shame that Canonical is doing that... [23:41] ObrienDave: Of course it is. [23:42] let's see, it's on the internet, therefore it must be true ROFL [23:42] This isn't the first time I've heard about Canonical in the present state of Ubuntu... [23:43] Canonical is the sponsor of Ubuntu.. [23:43] Then I was shown this article by another fellow, and unfortunately it distrubs me. [23:43] bluesabre: any chance we can make some apps remain plugged into settings-manager? (mugshot, light-locker-settings, menulibre) [23:43] instead of popping out that is [23:43] Unit193, Canonical are the people who make Ubuntu, are they not? [23:44] so, no one else tracks usage, cookies don't exist, anything else i missed? ROFL [23:44] humm, mind to take this to #ubuntu-fud guys? [23:44] this is the devel channel... [23:45] ochosi: not sure... all three of those are gtk3 [23:45] Yeah, but I was just saying because I was interesting in helping the community... I may not be part of the team now.. [23:45] right, could be that that's a problem... [23:45] etwarrior: how is re-posting an article that is disregarding of the community helping the furthering or development of xubuntu? [23:46] etwarrior: there are no plans in the near future to remove the "ubuntu" portion of "Xubuntu" :) [23:46] Because I was just letting you know that I think I may "step down." [23:46] yeah, but you already let us know earlier today for different reasons. but thanks. case closed. [23:47] ok, but if you wish to continue contributing to xfce, feel free to join development efforts in arch/fedora/suse :) [23:47] ...etc [23:47]