[08:47] <pitti> Good morning
[08:48] <didrocks> Guten Morgen pitti, how are you?
[08:49] <pitti> I'm great, thanks! Slept quite long :/
[08:49] <didrocks> pitti: it means that you needed it :)
[08:54] <pitti> didrocks: an old friend of mine visited me yesterday, and we talked until 0:30
[08:54] <didrocks> pitti: ok, that explains it then!
[08:54]  * didrocks asked for a rebuild of libcompizconfig at 0:30 yesterday :)
[08:55] <rodrigo_> morning
[08:55] <didrocks> (epic battle with cmake which decides "ohhh no glib-2.0.pc"? Let's give it a chance… But I'll forget all the other CFLAGS just for you!)
[08:56] <kklimonda> didrocks: with autotools you wouldn't have this problem! ;)
[08:56] <kklimonda> good morning
[08:56] <didrocks> I scratches my head to see why -I<blablabl> beetwen the first and second build (without any change) disappeared
[08:56] <didrocks> hey rodrigo_
[08:56] <kklimonda> hey rodrigo_ :)
[08:56] <didrocks> kklimonda: I know, tell that to upstream :)
[08:57] <kklimonda> oh, nice - I've just somehow managed to link my application against both gtk+ 2.0 and 3.0..
[08:58] <rodrigo_> kklimonda, heh, and no crashes?
[08:58] <kklimonda> rodrigo_: it didn't even start ;)
[08:58] <rodrigo_> :)
[08:58] <kklimonda> it prints a nice error message and quits..
[09:47] <didrocks> pitti: did you try to enable "gnomecompat" extension in ccsm?
[09:47] <didrocks> pitti: just to know if it pulls all your shortcuts :)
[09:47] <pitti> didrocks: should I? I never really used ccsm or changed compiz effects/plugins
[09:47] <didrocks> pitti: I'll change the default if you confirm it works
[09:48] <pitti> didrocks: is that the simple-ccsm package?
[09:48] <pitti> or compizconfig-settings-manager?
[09:49] <didrocks> pitti: no, compizconfig-settings-manager
[09:49] <pitti> didrocks: do I need to run compiz while using ccsm?
[09:49] <didrocks> simple-ccsm, we should maybe remove it, it's not ported to 0.9, will see
[09:49] <didrocks> pitti: no, you don't need to
[09:49] <pitti> didrocks: say the word, and I'll kill it :)
[09:50] <didrocks> pitti: let's wait for next week (unity release unity release unity release…) so that I can search over the compiz forum to see if something is working on porting it
[09:50] <pitti> ok, activated, starting compiz
[09:51] <didrocks> (alt + F2 at least, should work)
[09:51] <pitti> didrocks: Alt+F2 works again, but none of the others, like ctrl+alt+2 to switch workspaces, or Ctrl+Alt+T for terminal
[09:51] <didrocks> pitti: ok, that was my gut feeling
[09:51] <didrocks> ctrl + alt + T?
[09:51] <didrocks> it's working there
[09:52] <didrocks> oh no, it's not
[09:52]  * didrocks shouldn't fallback to metacity because of nvidia :)
[10:04] <mvo> hey didrocks - i noticed you work on the gsetting conversion for update-notifier, is there a eta? I want to do a upload soonish and it would be nice to coordindate
[10:06] <didrocks> mvo: I think I'll have some time next week to work on that, is that ok with you (like eta eow)?
[10:06] <didrocks> mvo: sorry, but compiz + unity delayed a lot my others tasks :)
[10:06] <mvo> didrocks: no worries, just wanted to ensure that we don't stomp each others foots
[10:06] <mvo> didrocks: again, no problem :)
[10:07] <mvo> didrocks: I have some vague memories that compiz can do this to people ;)
[10:07]  * mvo hugs didrocks
[10:07]  * didrocks hugs mvo
[10:07] <didrocks> mvo: after that, you're never the same, isn't it? :)
[10:08] <pitti> hey mvo, good morning; feeling better?
[10:11] <mvo> pitti: yeah, I got some medicine now (the paper says a sideeffect of taking it might be  euphoria  - I look forward to this ;)
[10:12] <pitti> lol
[10:12] <didrocks> mvo: take care :)
[10:15] <mvo> thanks didrocks
[10:31] <ronoc> bl8: ping ping
[11:39] <panaggio> yerterday I've added ubuntu-desktop ppa to my sources.list and after that compiz started giving me some headaches I have not expected
[11:40] <panaggio> now I've been trying to triage all the packages installed, so that I can go back to my old configuration, but I couldn't manage it yet =(
[11:41] <panaggio> I already have the "old" compiz, compiz-core, compiz-fusion-pligins-main and compiz-fusion-plugins-extra
[11:42] <panaggio> but I just can't figure out which other packages I have to reinstall =(
[11:43] <didrocks> panaggio: look at https://launchpad.net/~ubuntu-desktop/+archive/ppa/+packages if you click on the package arrows, you will see the binary package list
[11:43] <didrocks> panaggio: and keep in mind that ppa are not officially supported :)
[11:44] <panaggio> I know :) I just like to test things and report bugs when possible
[11:45] <didrocks> panaggio: did you report bugs on compiz?
[11:45] <panaggio> but my desktop got kinda useless after I've tried to get things right =(
[11:45] <didrocks> panaggio: I see that the ppa is working for some people :)
[11:45] <didrocks> weird
[11:45] <panaggio> not yet
[11:46] <panaggio> I broke everything in here. That's not ppa's fault =P
[11:46] <didrocks> panaggio: oh ok
[11:53] <panaggio> it seems I've missed libdecoration. Restarting to see if it was just this one
[11:55] <panaggio> omg. It wasn't even necessary :D
[11:55] <nessita> good morning crowd!
[11:58] <nessita> hey didrocks, were you able to take a look to the new package I linked yesterday?
[11:59] <didrocks> nessita: I don't have access to your branch
[11:59] <didrocks> nessita: hey :)
[11:59] <nessita> didrocks: oh
[12:00] <nessita> didrocks: how can I make it public?
[12:00] <didrocks> nessita: I have no idea about how launchpad is dealing with private branch TBH
[12:00] <didrocks> nessita: maybe ask on #launchpad ?
[12:01] <nessita> right
[12:02] <panaggio> didrocks: thanks for the help! :)
[12:02] <didrocks> panaggio: yw :)
[12:08] <nessita> didrocks: I'm not getting any answer yet, so in the mean time I'll push to lp:~nataliabidart/+junk/ubuntuone-control-panel_natty-release
[12:12] <nessita> didrocks: can you access that one?
[12:13] <didrocks> nessita: yes, I can access that one. I will do the review once we push unity to the ppa
[12:13] <didrocks> nessita: but it can take more time than expected, so maybe Monday at the latest :)
[12:13] <didrocks> sorry for the delay
[12:13] <nessita> didrocks: no rush, I need to run some errands
[12:13] <nessita> didrocks: thanks a lot!
[12:13] <didrocks> nessita: you're welcome!
[12:22] <chrisccoulson> no seb128 today?
[12:28] <pitti> chrisccoulson: nothing on the holiday calendar - perhaps a yet unapproved swap day
[12:30] <chrisccoulson> pitti - ah, ok. i'm having a bit of difficulty with my nearly-gconf-free firefox, and i think it's because of shared-mime-info
[12:36] <mterry> pitti, if seb128 is out, could you mayhaps upload https://code.launchpad.net/~mterry/launchpad-integration/gtk3/+merge/40486 for me?
[12:37] <mterry> rodrigo_, I looked at libsocial and the .27 tarball has gtk-doc.make in the toplevel.  Are you working from git?
[12:37] <rodrigo_> mterry, no, a tarball, but I took the package from universe, which was getting the code from git, so maybe I left something
[12:38] <mterry> rodrigo_, http://ftp.gnome.org/pub/GNOME/sources/libsocialweb/0.25/  -- has gtk-doc.make in it
[12:38] <rodrigo_> mterry, yes
[12:38] <rodrigo_> mterry, can you have a look at the debian/rules, to see if there's some get-from-git leftover?
[12:39]  * mterry looks
[12:40] <mterry> rodrigo_, there's certainly a get-orig-source target in the universe debian/rules...
[12:41] <rodrigo_> mterry, yes, I removed that
[12:42] <mterry> rodrigo_, and your tarball has gtk-doc.make in it?
[12:42] <rodrigo_> hmm, I think so, got it from http://ftp.gnome.org/pub/GNOME/sources/libsocialweb/0.25/, but let me recheck
[12:43] <didrocks> pitti: he is having a swap day, right
[12:43] <rodrigo_> mterry, yes, it does
[12:43] <mterry> rodrigo_, so something is deleting it?  (unless it's in the toplevel and you're *still* getting the error)
[12:44] <mterry> rodrigo_, if it's been deleted, I'd start over with a fresh untarring and copy the debian directory over
[12:44] <rodrigo_> ok
[12:48] <rodrigo_> mterry, hmm, in fact, build-area/libsocial...../ also has no configure, so dh_auto_clean is removing them?
[12:49] <mterry> rodrigo_, possibly, but if you're starting from a tarball, you actually probably don't need to autoreconf, do you?  was there a specific reason to do so (i know you had to when it was a git tarball...)
[12:50] <rodrigo_> mterry, no, just because the configure was removed, it seems by dh_auto_clean
[12:50] <rodrigo_> ok, so I'll clean all those rules
[12:51] <mterry> rodrigo_, dh_auto_clean may have cleaned it via dh_autoreconf_clean if you had that rule going
[12:51] <rodrigo_> possibly, yes
[12:55] <rodrigo_> mterry, ah, there's a debian/clean file, listing all stuff to clean
[12:56] <mterry> rodrigo_, oh!  Huh.
[12:56] <mterry> rodrigo_, including gtk-doc.make  :)
[12:57] <mterry> rodrigo_, that whole file can be dropped.  It's a manual version of dh_autoreconf_clean (which you aren't even using now)
[12:57] <rodrigo_> ok
[12:58] <rodrigo_> mterry, ok, but there's still a patch that touches configure.ac, so what should I do?
[12:58] <mterry> rodrigo_, oh there is?  then use dh-autoreconf
[12:58] <mterry> rodrigo_, but you still don't want that debian/clean file
[12:58] <rodrigo_> in which rule?
[12:59] <mterry> rodrigo_, you converted it to dh7, right?  then use dh --with autoreconf $@ in the main rule
[12:59] <rodrigo_> yeah, removed debian/clean
[12:59] <rodrigo_> ok
[13:00] <rodrigo_> aclocal: couldn't open directory `m4': No such file or directory
[13:03] <rodrigo_> mterry, without the --with asutoreconf it works
[13:03] <mterry> rodrigo_, guh, bad upstream package
[13:03] <mterry> rodrigo_, is the configure.ac patch intrusive?  It could just patch configure directly if it's a small change
[13:04] <mterry> hmm, yeah, it would probably expand to a lot of code in configure that you'd have to add in.  not impossible, but less clean
[13:05] <rodrigo_> not much -> http://pastebin.ubuntu.com/530682/
[13:05] <rodrigo_> but yeah, it expands to a lot of code
[13:07] <mterry> rodrigo_, what if...  you put the following near the top of debian/rules:
[13:07] <mterry> export ACLOCAL = true
[13:07] <mterry> to skip it...
[13:07] <rodrigo_> ok, trying
[13:08] <rodrigo_> it complains about the invalid argument the patch adds
[13:08] <rodrigo_> ok, what I'm going to do is to prepare the patch for upstream
[13:09] <mterry> rodrigo_, invalid argument?
[13:09] <rodrigo_> yes, the patch adds a new configure argument, and debian/rules uses it, so ./confiogure complains about it not being valid
[13:10] <mterry> rodrigo_, interesting.  so sounds like configure didn't get regenerated...
[13:10] <rodrigo_> yes
[13:10] <mterry> I wouldn't think ACLOCAL would skip that
[13:12] <mterry> rodrigo_, i wonder if you couldn't just 'mkdir m4' in debian/rules
[13:12] <mterry> rodrigo_, if it's a simple error-check for the existence of the directory
[13:13] <mterry> like in override_dh_auto_configure or something
[13:14] <rodrigo_> no, same thing
[13:14] <rodrigo_> but I'm looking at the patch, and really not sure we need it
[13:14] <mterry> it says m4 directory doesn't exist?
[13:14] <rodrigo_> mterry, no, wrong argument to configure
[13:14] <mterry> (you should get rid of the ACLOCAL = true bit)
[13:15] <mterry> that was just to skip aclocal, but hopefully the m4 directory existing will also let aclocal continue
[13:15] <rodrigo_> yes, done
[13:15] <rodrigo_> all works if I enable the ./autogen.sh bit
[13:15] <didrocks> pitti: do you have some time for a puzzling build issue?
[13:17] <mterry> rodrigo_, dh-autoreconf wasn't enough?
[13:17] <rodrigo_> hmm
[13:17] <mterry> rodrigo_, because their tarball doesn't even have an autogen.sh
[13:18] <pitti> didrocks: re; what's up?
[13:18] <didrocks> pitti: njpatel and I are fighting for quite some time on the FTBFS on Nux in the ppa
[13:18] <didrocks> pitti: http://launchpadlibrarian.net/59036593/buildlog_ubuntu-natty-i386.nux_0.9.2-0ubuntu1_FAILEDTOBUILD.txt.gz
[13:19] <didrocks> (look for re/NSystemGNU.h:37:18: fatal error: glib.h: No such file or directory)
[13:19] <didrocks> pitti: obviously, it misses  -I/usr/lib/glib-2.0/include
[13:19] <pitti> didrocks: because of the missing -Is?
[13:19] <didrocks> right
[13:19] <didrocks> however NuxGraphics/Makefile.am has the right cflags
[13:20] <didrocks> and it's working fine locally
[13:20] <pitti> hm, nux doesn't even seem to exist, is that a PPA?
[13:20] <didrocks> also, libglib*-dev is included as you can see in the previous lines
[13:20] <didrocks> pitti: yeah, it's a new toolkit for unity
[13:20] <didrocks> pitti: lp:~unity-team/nux/packaging
[13:20] <didrocks> pitti: I checked on the local build, and I have the -I… njpatel too
[13:21] <didrocks> (NUX_GRAPHICS_CFLAGS is the flag you are looking for)
[13:21] <didrocks> and in PKG_CHECK_MODULES, it has glib-2.0
[13:24] <pitti> didrocks: did you check building the actually uploaded source, or just from the branch?
[13:24] <didrocks> pitti: I tried dpkg-source -x .dsc and build it, right
[13:24] <didrocks> and it worked as well :/
[13:25] <pitti> building here; for some reason it ignores -j4
[13:26] <didrocks> weird… I don't think last time I checked the source there was something for that
[13:26] <Sir_Konrad> can I install Compiz on Unity now? :P
[13:27] <didrocks> Sir_Konrad: will depend when we get nux building, see ^
[13:27] <Sir_Konrad> didrocks, the topic?
[13:28] <pitti> didrocks: the Makefile.am looks a bit strange to me, but I'll let this build first
[13:28] <didrocks> Sir_Konrad: no, I ignore the join/quit, so not sure if you followed the conversation
[13:28] <pitti> libnux_graphics_@NUX_API_VERSION@_la_SOURCES = \
[13:28] <Sir_Konrad> didrocks, yeah I just joined about 15 seconds ago.
[13:28] <pitti>   $(source_cpp) \
[13:28] <pitti>   $(source_h)
[13:28] <pitti> ah, I missed that one
[13:29] <pitti> didrocks: hm, indeed it builds fine here as well
[13:30] <didrocks> pitti: and we are building a .ccp, so it's not an issue with CPPFLAGS
[13:30] <didrocks> pitti: I've updated and tried to build as well (even if I didn't see anything which can be interfering from yesterday)
[13:30] <didrocks> and it built :/
[13:31] <didrocks> pitti: you tried the package as well, not the bzr branch?
[13:31] <pitti> didrocks: building from branch
[13:31] <pitti> I don't know where the .dsc is :)
[13:31] <didrocks> pitti: ok, but in any case, I still have the terminal opened with the build from .dsc
[13:31] <didrocks> can still have a try to confirm I'm not crazy (or just a little bit)
[13:32] <didrocks> ok, even erasing my dsc there and taking them from the ppa :)
[13:32] <didrocks> let's ensure I get everything like the ppa
[13:33] <pitti> ./NuxGraphics/Makefile:NUX_GRAPHICS_CFLAGS = -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12
[13:33] <pitti> looks fine to me
[13:33] <didrocks> yeah, that's what I checked too :/
[13:33] <pitti> didrocks: did you try rebuilding this?
[13:33] <didrocks> pitti: "this"?
[13:33] <pitti> just to rule out a silly glitch somewhere?
[13:33] <pitti> didrocks: the PPA build
[13:34] <didrocks> pitti: yeah, I tried 20 minutes ago
[13:34] <didrocks> pitti: first build was at 11AM
[13:34] <didrocks> and it failed in both i386 and amd64
[13:34] <didrocks> I just try rebuilding on i386 though, but well…
[13:34] <pitti> didrocks: hm, perhaps a pbuilder is in order then
[13:34] <pitti> for reproducing the issue
[13:34] <pitti> it's obviously not helpful to stare at local Makefiles which work
[13:34] <didrocks> my pbuilder was broken the other day, but I can see if pbuilder update works today
[13:35] <pitti> I see no autoreconfiscation in the log
[13:35] <didrocks> no, we don't do that :)
[13:36] <didrocks> most of the time, I patch upstream and make a new tarball, much easier and less error-prone
[13:36] <didrocks> (for unity & co)
[13:36] <pitti> and the MAINTAINER_CFLAGS are present as well, so it's not a shortcut in the substitution
[13:36] <pitti> $(NUX_GRAPHICS_CFLAGS) is just empty
[13:36] <pitti> didrocks: right, but sometimes it happens when you have weird time stamps, and you b-dep on autotools-dev
[13:36] <didrocks> waiting the end of the local build with .dsc and *tar redowloaded and then… will try pbuilder
[13:37] <didrocks> pitti: oh right, but I think I tweaked MAINTAINER_CFLAGS to do the right thing there
[13:40] <pitti> didrocks: configure.ac has PKG_CHECK_MODULES ... xxf86vm
[13:40] <pitti> didrocks: but /usr/lib/pkgconfig/xxf86vm.pc has Name: Xxf86vm
[13:41] <pitti> I suppose that's not the reason?
[13:41] <didrocks> pitti: hum, maybe that can infer to it
[13:41] <didrocks> pitti: do you remembered I blame CMake this morning?
[13:41] <didrocks> blamed*
[13:41] <pitti> no, I didn't see that
[13:42] <pitti> didrocks: configure.ac looks fine otherwise, the various NUX_* substitutions all look the smae
[13:42] <pitti> didrocks: just that the thing that's different from NUX_GRAPHICS is this xxf86vm thingy
[13:42] <didrocks> one sec, l2010-11-12 09:55:53     didrocks        (epic battle with cmake which decides "o
[13:42] <didrocks> hhh no glib-2.0.pc"? Let's give it a chance… But I'll forget all the other CFLAG
[13:42] <didrocks> S just for you!)
[13:42] <didrocks> maybe it's related to that ^
[13:42] <didrocks> like "I can't find one, let's forget the CFLAGS"
[13:42] <pitti> didrocks: oh, nux -> c'est la cmake?
[13:43] <pitti> I don't see a cmake file anywhere
[13:43] <didrocks> pitti: no, but it looks it's the same symptom
[13:43] <didrocks> I was blaming CMake, but the cause is maybe something else
[13:43] <rodrigo_> mterry, yay, seems to work
[13:43] <didrocks> like pkgconfig or whatever
[13:43] <pitti> didrocks: so, I have no idea about this I'm afraid; perhaps just try a build with using Xxf86vm?
[13:43] <mterry> rodrigo_, yay!
[13:43] <rodrigo_> mterry, mkdir'in the m4 dir though
[13:43] <didrocks> pitti: yeah, I'll try that and push it there
[13:44] <mterry> rodrigo_, eh, that's a forgivable grossness, as it *should* be in upstream tarball
[13:44] <pitti> didrocks: let me know if you need score bumping or so
[13:44] <didrocks> pitti: sure, one sec :)
[13:45] <rodrigo_> mterry, yes
[13:51] <didrocks> pitti: it's already building, no need to score then :)
[14:00]  * rodrigo_ -> lunch
[14:00] <didrocks> pitti: it failed… but in any case: libxxf86vm-dev: /usr/lib/pkgconfig/xxf86vm.pc
[14:00] <didrocks> (I should have checked before)
[14:00] <pitti> didrocks: yes, but the "Name:" in the file is capitalized
[14:01] <kenvandine> pitti, didrocks: can one of you sponsor lp:~ken-vandine/ubuntu/maverick/x264/maverick-proposed
[14:01] <kenvandine> i had asked seb128 back when i pushed this... but i guess he forgot :)
[14:01] <kenvandine> didrocks, i suspect you are busy :)
[14:01] <pitti> kenvandine: can do
[14:01] <kenvandine> pitti, thx
[14:01] <didrocks> pitti: right, but configure fails with the capital letter
[14:03] <pitti> didrocks: oh, interesting; so perhaps it doesn't like the inconsistency there
[14:03] <Sarvatt> PKG_CHECK_MODULES should look for lowercase, and it should add -lXxf86vm from that
[14:03] <didrocks> pitti: but why only on buildd and not locally?
[14:04] <pitti> didrocks: NFC :(
[14:04] <geser> need all panel applets need porting to libpanel-applet-3-0 to show up on the panel again?
[14:11] <didrocks> pitti: do you get your pbuilder working? it's still broken here
[14:11] <didrocks> I have a bunch of: ind: File system loop detected; `./proc/1/task/1/cwd/sys/devices/platform/reg-dummy/subsystem/devices/i8042/serio0/subsystem/devices/serio1/input/input8/subsystem/input0/device/subsystem/devices/LNXSYSTM:00/device:00/PNP0A03:00/device:01/physical_node/sub
[14:12] <pitti> didrocks: I don't have a pbuilder
[14:12] <didrocks> I have that only for natty, my maverick pbuilder is working fine…
[14:16] <njpatel> didrocks, pitti is it possible to get the build dir off LP where the build failed?
[14:16] <njpatel> didrocks, pitti I think inspecting the produced makefiles is the only way to figure out that's going on
[14:17] <didrocks> getting the Makefile on it can be useful
[14:17] <didrocks> njpatel: we checked the local one is ok, but yeah, getting the one on the buildd will be helpful, maybe
[14:18] <pitti> njpatel: certainly; but that needs lamont
[14:18] <njpatel> makefile and the configure
[14:18] <pitti> njpatel: I agree
[14:18] <didrocks> ok, I'm trying to recreate a natty pbuilder, the maverick one worked there…
[14:20] <didrocks> oh oh, can reproduce \o/
[14:20] <didrocks> NUX_GRAPHICS_CFLAGS =
[14:20] <didrocks> NUX_GRAPHICS_LIBS = -pthread -lgdk_pixbuf-2.0 -lm -lgobject-2.0 -lgmodule-2.0 -lpng12 -lgthread-2.0 -lrt -lglib-2.0 -lGL -lGLEW -lGLEWmx -lXxf86vm
[14:20] <didrocks> what's the… !!!
[14:21] <njpatel> didrocks, wow
[14:21] <didrocks> in every Makefile, btw
[14:21] <didrocks> all the other CFLAGS is ok
[14:22] <njpatel> how the hell can that happen?
[14:22] <didrocks> so, there is a missing dep that empty the CFLAGS
[14:22] <pitti> didrocks: pkg-config failure theN?
[14:22] <didrocks> pitti: seems that
[14:22] <njpatel> pitti, that's what I thought, but it would happen on normal natty too?
[14:22] <didrocks> let me try pkg-config on that manually in the chroot
[14:22] <njpatel> didrocks, missing depend causing it?
[14:22] <didrocks> njpatel: if that's a missing .pc dep, maybe not
[14:22] <njpatel> right
[14:22] <didrocks> same idea :)
[14:22] <didrocks> njpatel: but not direct one, one from an install -dev package
[14:23] <didrocks> njpatel: I check nux build-dep, all is correct
[14:24] <didrocks> http://paste.ubuntu.com/530720/ \o/
[14:24] <didrocks> pitti: njpatel ^^
[14:24] <didrocks> so missing dep on libgl*-dev it seems
[14:24] <Sarvatt> didrocks: libxext?
[14:24] <kenvandine> pitti, also... just a reminder, please don't forget the gwibber maverick SRU
[14:24] <Sarvatt> oh beat me to it
[14:25] <didrocks> I install libxext-dev in the chroot and try to rebuild
[14:25] <njpatel> didrocks, oh god :)
[14:25] <didrocks> njpatel: not his fault for that :)
[14:26] <didrocks> NuxGraphics/Makefile:NUX_GRAPHICS_CFLAGS = -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12
[14:26] <didrocks> sounds better :)
[14:28] <njpatel> yes!
[14:28] <didrocks> Sarvatt: you mean, libxext missing dep is already known?
[14:33] <mvo> didrocks: hey, a quick quesiton/bugreport. it appears that if oneconf is instaled on s-c launch people will get a "please log into u1" dialog. can we make this a bit more subtle?
[14:33] <bcurtiswx> test: System-->Administration-->Time and Date  try to unlock it to make changes (I can not)
[14:33] <mvo> didrocks: I'm happy to submit a bugreport if you are busy currently
[14:33] <didrocks> mvo: at start?
[14:33] <Sarvatt> I saw it as Requires.private in the .pc and I just started shipping the generated gl.pc from the dri build instead of from the swrast build recently (since thats where that libGL is from), will fix up the libgl1-mesa-dev deps for the next upload
[14:33] <mvo> didrocks: yes
[14:33] <didrocks> mvo: yeah, a bug report, so that I can check, thanks :)
[14:33] <mvo> 2010-11-12 15:28:39,984 - root - DEBUG - oneconf: refresh hosts
[14:34] <didrocks> mvo: oh yes, in the terminal, that will change as I'll use u1sso (it was the binding from u1preferences which made that)
[14:34] <didrocks> mvo: but a bug report will be fine :)
[14:34] <didrocks> Sarvatt: ok, I'm making a quick fix in ubuntu for building nux then
[14:35] <mvo> didrocks: the message is not the problem, the dialog is ;) i.e. it should not pop it up unless the user requests the feature explicitely
[14:36] <mvo> hey tremolux
[14:36] <bcurtiswx> tremolux, where in Boston?
[14:36] <mvo> didrocks: bug #674537 (just fyi)
[14:36] <ubot2> Launchpad bug 674537 in oneconf (Ubuntu) "triggers u1 login dialog on fresh install (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/674537
[14:36] <tremolux> hey mvo!
[14:36] <mvo> didrocks: and not urgent (at all) :)
[14:37] <didrocks> mvo: thanks :)
[14:37] <tremolux> bcurtiswx: I'm in Action, about 20 miles outside of Boston
[14:38] <bcurtiswx> tremolux, hmm, idk where that is.. my bro lives in Malden
[14:38] <tremolux> bcurtiswx: sorry, Acton  :)
[14:39] <bcurtiswx> tremolux, i was just up there for Halloween.  I have relatives in Northboro and Malden
[14:39] <tremolux> bcurtiswx: ah yeah, I know Northboro well
[14:40] <tremolux> bcurtiswx: pretty around here at Halloween-time, isn't it?  it's been a great autumn
[14:41] <bcurtiswx> tremolux, absolutely.  I love fall.. and winter. I grew up in Rochester, NY.  so winters anywhere else aren't that extreme :)
[14:42] <didrocks> mvo: I think the dialog popup is related to a recent change in u1preferences api, last time I check, it didn't :) but well, as I'll move to u1 sso, the issue won't be there
[14:42] <bcurtiswx> can anyone test the following please: system-->admin-->time and date  and try unlocking it to change it
[14:42] <bcurtiswx> i can't for some reason
[14:46] <pitti> bcurtiswx: confirmed in natty
[14:47] <mvo> thanks didrocks
[14:47] <bcurtiswx> pitti, OK thx.  What package should a bug for that be filed under?  Would anyone want to be assigned to that?
[14:48] <pitti> bcurtiswx: gnome-system-tools; but it's going to go away in natty
[14:48] <bcurtiswx> pitti, hmm.  I can just wait for that to go away then.  What's replacing it?
[14:49] <pitti> bcurtiswx: time and date will just be dropped, you can change it in the panel applet
[14:49] <pitti> user & groups has a replacement in gnome-control-center 3
[14:49] <pitti> (so I heard)
[14:49] <pitti> for time and date, the alternative is system-config-date
[14:50] <bcurtiswx> pitti, how do I change it in panel applet? this may be my dumb question of the half hour
[14:50] <pitti> I packaged that during maverick for an OEM project, and it's a lot smaller than g-s-t
[14:50] <pitti> bcurtiswx: hm, it used to be possible, anyway
[14:50] <pitti> bcurtiswx: so, you can set the time zones and locations there
[14:51] <bcurtiswx> yup
[14:51] <pitti> I guess I never actually set the time, since ntpdate is doing that
[14:51] <bcurtiswx> pitti, OK then my issue is my times an hour behind what it should be..
[14:51] <bcurtiswx> but my location is set correctly
[14:51] <pitti> wrong time zone?
[14:52] <Sarvatt> didrocks: sorry about that, I fixed up the libgl1-mesa-dev depends in debian experimental and it'll be in the next upload in a few days after we do a merge
[14:52] <pitti> bcurtiswx: what does "date" say?
[14:52] <bcurtiswx> in terminal?
[14:52] <pitti> yes
[14:52] <bcurtiswx> Fri Nov 12 08:52:39 EST 2010
[14:52] <bcurtiswx> should be EDT
[14:52] <bcurtiswx> were in daylight savings
[14:53] <pitti> bcurtiswx: what's /etc/timezone for you?
[14:53] <didrocks> Sarvatt: no worry. I was just puzzled by the issue and as my natty pbuilder is broken, debugging was just horrible :) fix pushed to natty and look forward to your next merge :)
[14:53] <bcurtiswx> America/New_York
[14:53] <pitti> bcurtiswx: indeed, DST ended this Sunday, right?
[14:53] <bcurtiswx> yes, this past sunday
[14:53] <pitti> $ TZ=America/New_York date
[14:53] <pitti> Fr 12. Nov 09:53:45 EST 2010
[14:54] <pitti> looks like tzdata bug
[14:54] <pitti> tremolux: ^ did you happen to hear about that?
[14:55] <pitti> looks like America/ has eternal summer time now
[14:55] <pitti> bcurtiswx: would you mind filing a bug about this, please? seems we need to fix that in all stable releases
[14:55] <pitti> bcurtiswx: (against tzdata)
[14:55] <tremolux> pitti: oh, nope, I didn't
[14:56] <bcurtiswx> OK, anyone to be assigned?
[14:56] <pitti> tremolux: could you look into that?
[14:57] <tremolux> pitti: yep
[14:57] <pitti> zdump -c 2011 -v America/New_York
[14:57] <pitti> that looks entirely backwards
[14:57] <pitti> America/New_York  Sun Nov  7 05:59:59 2010 UTC = Sun Nov  7 01:59:59 2010 EDT isdst=1 gmtoff=-14400
[14:57] <pitti> America/New_York  Sun Nov  7 06:00:00 2010 UTC = Sun Nov  7 01:00:00 2010 EST isdst=0 gmtoff=-18000
[14:57] <pitti> $ TZ=America/New_York date -d 'now - 2 weeks'
[14:57] <pitti> Fr 29. Okt 10:57:30 EDT 2010
[14:57] <pitti> $ TZ=America/New_York date
[14:57] <pitti> Fr 12. Nov 09:57:39 EST 2010
[14:58] <pitti> hm, wait
[14:58] <pitti> does the "D" mean "daylight saving" or does the "S" mean "summer time"?
[14:58] <bcurtiswx> yeah, we lose an hour.. not gain one
[14:58] <tremolux> pitti: yeah, it's fine isn't it?  (scratching my head)
[14:58] <pitti> maybe I'm just misinterpreting the abbreviations here
[14:58] <pitti> tremolux: so the gmtoff looks correct
[14:59] <pitti> seems I'm just misinterpeting the meaning of EST vs. EDT
[14:59] <pitti> right, so it's "S"tandard vs. "D"aylight
[14:59] <pitti> so zdump is correct
[15:00] <tremolux> pitti: http://wwp.greenwichmeantime.com/time-zone/usa/eastern-time/
[15:00] <tremolux> pitti: yep, it's correct
[15:00] <pitti> bcurtiswx: according to http://www.timeanddate.com/worldclock/city.html?n=179 it _is_ 10 am for you..
[15:00] <bcurtiswx> pitti, this is correct
[15:00] <pitti> tremolux: ok, sorry for the confusion; we use CET vs. CEST, wehre the "S" is "summer time"
[15:01] <bcurtiswx> my comp says 9:00AM right no
[15:01] <bcurtiswx> now*
[15:01] <bcurtiswx> yesterday it had the right time though
[15:01] <pitti> bcurtiswx: does it get better with sudo ntpdate ntp.ubuntu.com ?
[15:01] <pitti> perhaps something else changed the internal clock
[15:02] <bcurtiswx> i did that and the timestamp says 10:02, but my clock never changed
[15:03] <tremolux> bcurtiswx: prolly have to wait for the next minute bump...
[15:03] <bcurtiswx> now it did
[15:03]  * bcurtiswx shrugs
[15:03] <tremolux> sunspots  :)
[15:03] <bcurtiswx> was there something in the updates yesterday that would have caused the issue
[15:04] <bcurtiswx> tremolux, im a space physicist .. no sunspots yet :P
[15:04] <tremolux> bcurtiswx: haha
[15:06] <tremolux> bcurtiswx: there was a tzdata update yesterday, but no changes to America/New_York and in fact no changes at all for 2010
[15:07] <bcurtiswx> tremolux, seems to be the 2nd instance of my computer being "special".. it's probably just me :D
[15:07] <tremolux> bcurtiswx: heh
[15:08] <bcurtiswx> tremolux, pitti: thanks for the help :)
[15:08] <tremolux> bcurtiswx: sure np!  that was a strange one
[15:09] <mvo> will anyone mind if I do a no-change upload of python-gtk2 for the py2.7 transition?
[15:10] <pitti> mvo: why? current package already has 2.7 bits
[15:10] <mvo> pitti: hm, then my mirror is outdated
[15:10] <pitti> -rw-r--r-- 1 root root 2777032 2010-11-03 04:38 /usr/lib/pyshared/python2.7/gtk-2.0/gtk/_gtk.so
[15:10] <pitti> mvo: I have 2.22.0-0ubuntu1
[15:11] <kenvandine> pitti, thx for the sponsoring, can you also get gwibber out of binNEW?
[15:12] <pitti> kenvandine: for natty?
[15:12] <kenvandine> yes
[15:12] <pitti> (still reviewing SRUs)
[15:12] <kenvandine> ok
[15:12] <kenvandine> i split all the plugins into separate packages
[15:12] <kenvandine> so we can reduce how many we include by default :)
[15:12] <pitti> yay you
[15:13]  * kenvandine is very pleased to finally have done that
[15:15] <bcurtiswx> kenvandine, did you still need guinea pigs for gwibber fixes?
[15:16] <kenvandine> sort of... problem is we need a considerable chunk of users to update before we know for sure
[15:16] <kenvandine> but... based on what facebook said, this should reduce our DB queries by roughly 266 million per day :)
[15:16] <kenvandine> bcurtiswx, the update is actually very low risk, just removes an operation that isn't actually useful anymore
[15:17] <kenvandine> so to verify it, you just need to confirm "Replies" is no longer listed under facebook
[15:17] <bcurtiswx> kenvandine, does 266 million get us out of being limited?
[15:17] <kenvandine> i really should
[15:18] <bcurtiswx> kenvandine, PPA that I can DL from?
[15:18] <bcurtiswx> desktop-team?
[15:18] <kenvandine> it is in -proposed
[15:18] <kenvandine> maverick and lucid
[15:18] <bcurtiswx> im using natty ;)
[15:18] <kenvandine> ah... not in natty yet :)
[15:19] <kenvandine> but you can try the dailies if you want
[15:19] <bcurtiswx> kenvandine, natty soon though?
[15:19] <kenvandine> natty was my lowest priority, since it should have the lowest number of users
[15:19] <kenvandine> yeah
[15:19] <kenvandine> once it gets out of binNEW i'll look into merging some other fixes and doing another release
[15:19] <kenvandine> maybe monday
[15:19] <kenvandine> or over the weekend
[15:20] <bcurtiswx> kenvandine, great :)
[15:20] <kenvandine> the biggest change to gwibber in a long time has been sitting in binNEW all week :)
[15:20] <kenvandine> i am anxious to get more people testing that, it is the plugin split
[15:21] <kenvandine> and much better error handling
[15:23] <bcurtiswx> i'm anxiously awaiting.  I'm anxious to see how all the transitions to compiz-unity and GTK3 go (once things start building with it)
[15:41] <Amaranth> didrocks: I think we need to rethink how we handle compiz crashing
[15:41] <Amaranth> I naively ported the shell script mechanics but hooking in to SIGSEGV kind of breaks apport
[15:42] <didrocks> Amaranth: yeah, I think we should revisit the apport script
[15:42] <Amaranth> didrocks: No no, apport isn't even getting called
[15:42] <didrocks> Amaranth: for intance, if there is unity, we should file the bug against unity I guess
[15:42] <Amaranth> Because compiz doesn't actually crash
[15:42] <didrocks> Amaranth: oh, you mean the general crashing?
[15:42] <Amaranth> It launches metacity
[15:42] <didrocks> Amaranth: hum, it crash if there is a plugin which crash, isn't it?
[15:43] <didrocks> Amaranth: well, right now, I can get no decorator very easily :)
[15:43] <didrocks> and no metacity
[15:43] <Amaranth> That's your decorator crashing maybe
[15:43] <Amaranth> Either that or you've already removed that part of the patch
[15:43] <didrocks> Amaranth: not really, it's when a plugin crash (not only at start)
[15:43] <Amaranth> But what we should really do is make gnome-session restart compiz
[15:44] <didrocks> Amaranth: yeah, that's part of my plan, with writing a compiz new plugins
[15:44] <Amaranth> We had some issues with it way back when but that was actually a bug in compiz as well, we just overreacted
[15:44] <didrocks> Amaranth: the plugin will do the detection at start
[15:44] <Amaranth> Err
[15:44] <didrocks> Amaranth: with that, we can set compiz as a required component
[15:44] <Amaranth> We're already doing the detection
[15:44] <didrocks> Amaranth: yeah, but as a plugin enables us to do interesting thing
[15:44] <Amaranth> "set compiz as a required component"?
[15:45] <Amaranth> How does moving the check into a plugin get you anything
[15:45] <didrocks> Amaranth: like, "can you start unity? no, can you still start compiz + gnome-panel, can you start metacity?"
[15:45] <didrocks> Amaranth: sam agreed that a plugin was cleaner that this detection at start patch
[15:45] <Amaranth> Sam thinks everything should be a plugin
[15:46] <didrocks> Amaranth: I quite agree on that one, so that we don't enforce everyone to have the detection if they don't want
[15:46] <didrocks> and then, compiz will be set as a required component to gnome-session
[15:46] <Amaranth> Err, you realize launching metacity will close compiz, right?
[15:47] <Amaranth> If we don't handle that correctly gnome-session will start it again
[15:47] <didrocks> Amaranth: of course, why?
[15:47] <didrocks> Amaranth: you can tell gnome-session "register/unregister than one"
[15:48] <didrocks> we discussed that with vuntz at UDS
[15:48] <Amaranth> Are you talking about the session management X protocol or some new gnome-session thing?
[15:49] <didrocks> gnome-session interns I guess, I didn't look at yet, but vuntz told me it's possible with gnome-session
[15:51] <Amaranth> cool I've got compiz in an infinite loop
[15:51] <Amaranth> Luckily before it loaded any plugins
[15:52] <didrocks> urgh
[15:52] <Amaranth> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[15:53] <Amaranth> arg I have no dbgsym package for it
[15:53] <didrocks> Amaranth: is it the one with the glib mainloop?
[15:53] <Amaranth> I dunno, latest package in natty
[15:54] <Amaranth> It seems reproducible, I've killed it and started again, same thing happened
[15:56] <didrocks> Amaranth: the -dbgsym package aren't accessible?
[15:56] <Amaranth> don't have the repo added yet :)
[15:57] <didrocks> Amaranth: in any case, what do you think in the compiz ppa to produce files with debug symbols unstripped?
[15:57] <didrocks> s/files/deb
[15:57] <didrocks> will be faster when moving fast
[15:57] <Amaranth> dang, dbgsym is ubuntu1, ubuntu2 isn't available yet
[15:58] <Amaranth> didrocks: works for me
[15:59] <didrocks> Amaranth: btw, I've replaced zoom by ezoom
[16:00] <Amaranth> wow this is a long backtrace
[16:00] <Amaranth> seems to be a deadlock, I thought the kernel caught that and killed the process
[16:00] <Amaranth> top of the stack is __pthread_mutex_lock, anyway
[16:01] <didrocks> Amaranth: waow, so surely related to the glib patch
[16:01] <Amaranth> oh, perhaps it's because I'm using the gconf backend for settings
[16:01] <didrocks> oh, I didn't tested that layout yet
[16:01] <didrocks> I'm still with the ini backend
[16:01] <Amaranth> well, it was working but I don't think I'd tested with the glib patch
[16:02] <Amaranth> yeah, it seems both compiz and the gconf backend are trying to pump the mainloop
[16:02] <didrocks> more than possible that it's the cause :)
[16:02] <didrocks> ok, bad then
[16:02] <Amaranth> yeah, they end up blocking each other
[16:02] <Amaranth> core is waiting for results from the backend, backend is spinning on the mainloop lock
[16:03] <didrocks> Amaranth: ok, something to see with smspillaz/dbo
[16:03] <njpatel> kenvandine, !
[16:03] <njpatel> kenvandine, is there anyway through libgwibber to get to the tweet stream as a model?
[16:04] <kenvandine> njpatel, not yet
[16:04] <njpatel> kenvandine, was planning to work on the gwibber-gtk stuff tonight would love to have some actual data
[16:04] <njpatel> ah, okay,
[16:04] <kenvandine> sorry :)
[16:04] <njpatel> np :)
[16:04] <kenvandine> i wanted to libdee working first
[16:04] <kenvandine> right now the data is just a pile of json
[16:04] <njpatel> ah, of course,
[16:05] <kenvandine> njpatel, but.. if you can just make it work with a dee model, with dummy data on the other side
[16:05] <kenvandine> that would rock
[16:05] <kenvandine> since that is what i plan to expose... once i can use it in python
[16:05] <njpatel> yeah, will just use DeeSequence model for now
[16:05] <kenvandine> njpatel, so just make the stream view display that
[16:05] <kenvandine> great
[16:06] <njpatel> yep
[16:06] <kenvandine> what is the difference? DeeSequence and DeeSharedModel?
[16:06] <Amaranth> didrocks: Yeah, there are no dbgsym packages for the gconf backend but I'm 100% certain it's stuck in processEvents
[16:06] <Amaranth> while (g_main_context_pending(NULL)) g_main_context_iteration(NULL, FALSE);
[16:06] <njpatel> kenvandine, DeeModel is the interface, DeeSequenceModel is the local one that implements it (if I'm recalling the name right) and DeeSharedModel is the remote on that implements it
[16:07] <njpatel> kenvandine, so we only deal with sequence for now, but it's like a two line change to make it work with shared, as the stream won't know what DeeModel it's using
[16:08] <kenvandine> oh... i might understand now :)
[16:08] <kenvandine> i need to get that working in gwibber-service so i can play
[16:08] <didrocks> Amaranth: sounds logical, can you try to switch to the ini backend just for a test?
[16:09] <njpatel> the local one is just 'cos gtk/glib doesn't really have a nice model, GSquence is nice, but has a crazy API
[16:09] <njpatel> so dee-sequence wraps gsequence into something sane
[16:10] <Amaranth> didrocks: Simple fix, the ccp plugin only tells the gconf plugin to run that if the glib plugin isn't loaded
[16:10] <Amaranth> didrocks: So we need to toss out that flag and delete the glib plugin :)
[16:10] <didrocks> Amaranth: well, we need to be smarted in the futur :) I think people will still want to get their gnome keybindings
[16:10] <didrocks> I know pitti is really eager of that :)
[16:11] <Amaranth> didrocks: Right, the glib plugin exists to pump the mainloop for the only gconf plugin
[16:11] <Amaranth> didrocks: But now glib is internal so we don't need that plugin and we don't need the gconf ccp backend to try to pump the mainloop
[16:11] <Amaranth> basically I just need to toss out that part of the code
[16:11] <didrocks> Amaranth: so, the gconf plugin needs to be updated to be able to speak to both? or maybe the glib plugin should be removed if the glib mainloop is being to be the default, not sure…
[16:12] <didrocks> Amaranth: agreed
[16:12] <Amaranth> didrocks: It just doesn't need to worry about the mainloop at all, core is handling it now
[16:13] <didrocks> Amaranth: it's still not in the main branch, we should coordinate with sam for that (it's still a separate branch), but in theory, I completely agree
[16:14] <Amaranth> didrocks: I'm trying to do so now in #compiz-dev :)
[16:14] <didrocks> Amaranth: hum? I don't have an autojoin there?
[16:14] <didrocks> something is broken in my weechat config :)
[16:16] <rickspencer3> didrocks, kenvandine hey guys, I was thinking about trying out the compiz-based unity today, is the PPA set up?
[16:16]  * rickspencer3 is on holiday todasy
[16:17] <kenvandine> didrocks, not yet
[16:17] <rickspencer3> kenvandine, was that "not yet" for me?
[16:18] <kenvandine> whoops :)
[16:18] <didrocks> rickspencer3: will be soon, we are fighting since this morning on getting things in shape
[16:18] <didrocks> rickspencer3: now, it's just a matter of waiting the buildds
[16:18] <kenvandine> rickspencer3, funny... i was specifically trying to not mention didrocks, didn't want to distract him
[16:18] <rickspencer3> sweet
[16:18] <kenvandine> i guess thinking about that made me type it :)
[16:18] <rickspencer3> haha
[16:18] <didrocks> kenvandine: thanks man :)
[16:18] <rickspencer3> kenvandine, for the rest of the day, your job is to not think of the number 42
[16:19] <kenvandine> haha
[16:19] <kenvandine> 424242
[16:19] <rickspencer3> okays, maybe I'll check in later
[16:19]  * rickspencer3 back to the non-grind
[16:19] <didrocks> rickspencer3: btw, if you didn't see that, now Quickly and the natty build-system has a full prototype to install in /opt
[16:19] <kenvandine> rickspencer3, enjoy
[16:19] <rickspencer3> didrocks, I saw, yah
[16:19] <rickspencer3> it's sweet
[16:19] <kenvandine> didrocks, oh... awesome
[16:20] <didrocks> kenvandine: just needs some testing, as I don't want everyone to not be able to install python apps :)
[16:20] <didrocks> so, for brave people: https://launchpad.net/~didrocks/+archive/ppa on natty
[16:22] <kenvandine> i was just fighting with autotools trying to figure out how to deal with something that installs in /opt
[16:22] <kenvandine> just == at UDS
[16:22] <didrocks> kenvandine: well, this will only work with python :)
[16:22] <kenvandine> yeah
[16:23] <kenvandine> bummer :)
[16:23] <didrocks> kenvandine: but it handles all the bytecompile at install time and symlinks generation
[16:23] <kenvandine> cool
[16:24] <dbarth__> hey, is it me or there is no release meeting this week?
[16:41] <rickspencer3> dbarth__, no release meeting
[16:41] <rickspencer3> (so far as I know)
[16:58] <pitti> starting next week
[17:01] <dbarth__> ok, thanks
[17:05] <didrocks> vish: nautilus will show the desktop in natty, you can close your bug :)
[17:06] <vish> didrocks: which bug? the papercut bug or the ATI bug?
[17:06] <didrocks> vish: the compiz papercut
[17:07]  * kenvandine -> lunch
[17:08] <vish> didrocks: i'm a bit confused when you say "close".. or did you mean *not* show
[17:09] <didrocks> vish: no, nautilus will draw the desktop icons in natty, and your bug was about to change the wording of a compiz plugin for that?
[17:10] <vish> didrocks: nah, not to change the wording.. :)  but to fix the behavior
[17:10] <didrocks> vish: ok, just so you know that the desktop icons will be shown in natty :)
[17:11] <vish> didrocks: cool, thanks. :)
[17:11] <vish> so i'll re-confirm the bug..
[17:13] <didrocks> ok :)
[17:13] <didrocks> thanks to you :)
[17:14] <ronoc> bl8 ping
[17:28] <icekk> I installed ubuntu desktop on my netbook, is there a tool i can use to strip it down a little and make it faster?
[17:31] <didrocks> icekk: for support issue, please, head to #ubuntu
[17:31] <icekk> hmm its not a support issue is it
[17:31] <icekk> its more like a feature
[17:31] <icekk> :D
[17:32] <devildante> didrocks: typing !support is better :)
[17:32] <didrocks> !support | icekk
[17:32] <ubot2> icekk: The official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org
[17:32] <didrocks> !topic
[17:32] <ubot2> Please read the channel topic whenever you enter, as it contains important information. To view it at any time after joining, simply type /topic
[17:32] <didrocks> hum, it doesn't display the topic?
[17:32] <icekk> dirocks, whats this chan for? development?
[17:32] <didrocks> icekk: this channel is for developping ubuntu
[17:32] <didrocks> icekk: right :)
[17:33] <icekk> like kernal level?
[17:33] <icekk> or overall?
[17:33] <didrocks> icekk: here, it's desktop as #ubuntu-desktop intend :)
[17:33] <icekk> yeah, does that mean the development is related to OS development strictly?
[17:33] <icekk> or any type of ubuntu desktop dev?
[17:34] <didrocks> icekk: the OS, there is #ubuntu-app-devel I think for developping applications on ubuntu
[17:34] <icekk> that's pretty cool, is the OS itself written in c?
[17:35] <didrocks> icekk: it's the OS as the applications, all what you can install in ubuntu
[17:36] <didrocks> "the distribution" is the correct term
[17:37] <icekk> If I wanted to run command line linux on an embedded device, are there distributions geared toward embedded devices?
[17:37] <icekk> or just run a stripped down version of ubuntu-desktop
[17:42] <bl8> ronoc: pong
[17:42] <ronoc> bl8, hey
[17:51] <geser> does someone know why some of my panel applets don't appear in my panel anymore in natty? do they need porting to the new libpanel-applet-3-0?
[17:54] <pitti> have a nice weekend everyone, good night!
[18:31] <chrisccoulson> w00t, gsettings support in firefox built, finally \o/
[18:35] <mvo> chrisccoulson: nice! is there a guide for python too? i have some python stuff that need fixing
[18:36] <chrisccoulson> mvo - i'm not sure if there is any guide for python
[18:43] <mterry> mvo, I *think* that if you want to use gsettings, you have to switch to gobject-introspection first
[18:47] <mvo> mterry: thanks, *mehh* that sounds not like a friday evening project ;)
[18:48] <mterry> :)
[19:12] <bcurtiswx> is there a way to build from pbuilder and test the build from in there (like a chroot) ?
[19:13] <bcurtiswx> hmm, prob a motu question. sry
[19:49] <nerus> james_w: Hi
[19:49] <james_w> hi nerus
[19:49] <nerus> I saw this http://www.jonobacon.org/2010/11/11/3048/
[19:50] <nerus> am I talking to the right person ? ;)
[19:50] <james_w> nerus, you want jasoncwarner
[19:51] <nerus> james_w: oh okay :)
[19:51] <james_w> he's apparently not here right now
[19:51] <nerus> I guess he is not around
[19:51] <nerus> yep
[19:51] <nerus> thanks very much
[19:51] <nerus> i will come again later in the day tomorrow
[19:51] <nerus> :)
[20:40] <bratsche> Anyone around who is very familiar with GI and Python stuff who can help me for a few minutes?
[20:41] <bratsche> Trying to make some GI binding and it doesn't seem to be working as I want.
[21:37] <mclasen> pitti: have you done the media-player-info 11 release ?


[11:21] <czajkowski> also if anyone would like to learn about MongoDB, there is a free class on it over the coming weeks, self paced and you get  acert at the end of it . https://education.mongodb.com/courses/10gen/M101P/2013_November/about
[11:24] <zmoylan-len> nice
[11:26] <czajkowski> yeah
[11:26] <czajkowski> self paced means you can try it at your own pace which is nice
[11:29] <slashbel> maybe silly question (as i have yet to be sold the idea) but what has mongo got to offer that the likes of mysql/postgres cannot provide?
[11:29]  * slashbel rarely touches databases these days
[11:39] <ebel> slashbel: usually much more scale.
[11:39] <ebel> slashbel: and in theory if you like json-y things
[11:39] <ebel> (though most web apps /should/ have proper db migrations...)
[11:40] <ebel> (I /think/)
[11:42] <slashbel> aye
[11:55] <ebel> y'know, it's like asking "python vs. ruby" :P different types of software
[11:56] <ebel> slashbel: remember, sometimes ACID databases (like MySQL/postgreSQL) can do *too* much
[11:56] <ebel> transactions, etc. *can* slow things down when you don't need transactions
[11:57] <ebel> If you *don't care* about consistancy & atomicity, then you can get speed benefits from ignore them and forcing the app writer to do it.
[11:58] <ebel> Like C++ vs Java. If you don't care about memory management, and are happy with forcing the app developer to deal with it, you can get speed benefits from not including it.


[14:25] <jokerdino> mterry: heh it's alright.
[14:25] <jokerdino> the point of our site is to provide good quality answers and if the current answers aren't good enough, adding your awesome answer is so much encouraged.
[14:26] <jokerdino> you did just that, and i already upvoted you!
[14:58] <dpm> jokerdino, thanks for providing the first answer, though, that was really helpful already. I chose Mike's one in the end, as it provided more info. But yours is useful to understand what the "share" part means, which wasn't clear to me before
[15:00] <jokerdino> you're welcome, sir :)
[15:00] <jokerdino> you both sound apologetic that you have to unaccept my answer and accept his. i have no worries about that.
[15:01] <jokerdino> so.. yeah
[15:02] <jokerdino> http://askubuntu.com/questions/98692/how-to-add-support-for-the-global-menu-to-a-python-non-gtk-non-qt-app
[15:02] <jokerdino> ^that question has a nice bounty on. and definitely a good place to document relevant stuff. please do advertise it a bit more..
[15:42] <dpm> jokerdino, done :)
[15:43] <jokerdino> thanks :)
[17:24] <akk> I'm confused about developer.ubuntu.com and the ubuntu software center.
[17:24] <akk> The software center seems to be showing me the same apps I can get with apt-get from standard repos ...
[17:24] <akk> but developer.u.c is for a process that gets apps into some other, less blessed, repository, isn't it?
[17:25] <akk> (Was hoping I'd understand this better after UDS, but I still don't.)
[18:02] <morten771> yes regardless what repositories you have, you should allways be able to install them with apt-get or synaptic or so... but I don't know about ubuntu software center, is it complete? (have all applications, or only selected ones?)
[20:04] <JanC> akk: I think there is currently only one app in USC for 12.04 that cae in through the d.u.c. process
[20:04] <JanC> *that came in*
[20:06] <JanC> it's named 'leds'
[20:08] <akk> Right, I guess most of the apps are only approved for 11.10?
[20:09] <akk> In case anyone's lurking and wondering, it turns out it's the "extras" repository
[20:09] <JanC> certainly more than 1
[20:09] <akk> and can be searched with aptitude using the origin "LP-PPA-app-review-board"
[20:09] <JanC> indeed
[20:10] <JanC> I think the app reviews for 12.04 were delayed somewhat because of the release & then UDS
[20:10]  * akk will be blogging this since it doesn't seem to be written up anywhere
[20:11] <akk> also how to package python apps since that isn't really documented either
[20:12] <JanC> akk: maybe you can contribute that to the developer site even (or offer your blog post for them as a start after you published it)
[20:13] <akk> I'd be happy to help write docs for the developer site.
[20:13] <akk> It's pretty confusing now -- it looks very welcoming until you start trying to actually do anything. :)
[20:13] <JanC> I think 'dpm' is responsible for that site, but he's not in here right now


[11:02] <[drnathanfurious> wow, really strange behavior with the 'time' command... can anyone confirm
[11:02] <[drnathanfurious> in the man page it says you can do
[11:02] <[drnathanfurious> time -f "%E real,%U user,%S sys" ls -Fs
[11:02] <[drnathanfurious> to format output
[11:02] <rww> try #ubuntu?
[11:02] <[drnathanfurious> whoah, where the f am i
[11:02] <[drnathanfurious> oic
[11:02] <[drnathanfurious> sorry
[11:06] <erUSUL> [drnathanfurious: if you only use time you use the bash built in time. « help time »
[11:07] <rww> erUSUL: we sorted it out in #ubuntu :)
[14:17]  * nhandler added a slightly more detailed version of AlanBell's suggested factoid
[14:20] <persia> !marketplace ?
[14:21] <bazhang> !marketplace


[14:42] <lotuspsychje> lordcirth: did someone found your zsync answer yet?
[14:42] <lordcirth> lotuspsychje, you mean my ZFS question? No
[14:42] <lotuspsychje> weirdy
[15:43] <lordcirth> However, freeze is in 2 days, so I'm guessing the answer is "no".