[02:47] ping jono? [02:47] nekohayo, hey [02:48] hey there, I was curious about something regarding the pitivi MIR... I never really got an answer whether it was possible or not for pitivi to go past the 18th's feature freeze deadline or not [02:48] (maybe I didn't ask the proper people or clearly enough) [02:48] I'd just like to know if this is an option available [02:49] or if it really really has to be done within the next 2 days [02:49] so wondering if you have any idea regarding that [02:54] isn't pitivi in main already? [02:55] it appears it is [02:55] dobey, yes, but it's an old version [02:55] at least, apt thinks it is, and it was installed when i upgraded to lucid [02:55] (that's the problem) [02:56] many bugs are fixed in the dev version, and we'd like to at least have basic crossfade transitions in [02:56] * dobey thinks it was a noble goal, but perhaps poor timing, to include pitivi by default [02:57] perhaps [02:58] if it can't be done it could be postponed to lucid+1, but if it can be squeezed with crossfade transitions, that could do it [02:59] emdash is working on easy crossfading transitions, but I'm hesitant to say it would be completed in the next 48 hours [03:01] maybe rickspencer3 would know :) [03:01] maybe [03:01] what's up? [03:01] * rickspencer3 has no scrollback [03:02] rickspencer3, http://pastebin.com/d133bc4c [03:02] * rickspencer3 braces for rickroll [03:02] :) [03:03] nekohayo, what do you mean about going past feature freeze? [03:03] we typically do lots of bug fixing and tweaking past feature freeze, but stop adding features [03:03] a freeze exception [03:03] hm [03:03] (but there are exceptions) [03:03] what are you wanting to do? [03:04] crossfades and transitions? [03:04] we'll I'm just evaluating the options, 'cause 0.13.3 is old now, but 0.13.4 is not yet out the door [03:04] ah [03:04] these are indeed tough calls to make [03:04] there are many users struggling with weird bugs that are absent from the git version [03:04] when is 13.4 currently scheduled to be ready? [03:05] we often update to a later version after freeze [03:05] that's the thing, I'm not sure; https://bugzilla.gnome.org/buglist.cgi?product=pitivi&target_milestone=0.13.4 [03:05] <-- could help seeing the bugs remaining [03:05] but if there are risky new features in the newest release, we sometimes dig up [03:05] patches from upstream to fix bugs in what we've got [03:05] so, I guess "it depends" [03:06] well the git version is more stable/dependable than the 0.13.3 release, from my experience [03:06] hmmm [03:06] well, we certainly can evaluate which is the right version to go with [03:07] if there is a high probability that 13.4 will be ready well before we release Lucid, it may be a good idea [03:07] to just update to it now [03:07] * rickspencer3 adds to list of topics for desktop team meeting tomorrow [03:08] limited to this feature set it would be possible IMHO (but no fancy poney-shaped wipe transitions) [03:08] yeah [03:08] so yeah bring it up to the meeting and do tell me what happens [03:08] tbh, I'm more interested in the bug fixes, but some basic transitions would be good as well ;) [03:08] methinks that https://bugzilla.gnome.org/show_bug.cgi?id=579230 could be implemented in time for lucid since emdash is currently working on it [03:08] Gnome bug 579230 in transitions "easy crossfading transition of overlapping clips" [Enhancement,Assigned] [03:09] ok [03:09] and it's the absolute priority feature for the next release (I "settled" for it :) [03:09] just not user that it would be done in 2 days [03:09] Hrmm. the 'anonymous' access to the LP API is annoyingly annoying [03:09] s/user/sure/ [03:09] nekohayo, what's you gut tell you about readiness for Lucid? [03:09] (regarding pitivi of course ;) ) === jjardon_afk is now known as jjardon [03:10] hrmm [03:10] what date must it be ready for, before april first I assume huh [03:11] * rickspencer3 checks release schedule\ [03:11] my understanding of the situation is that once we get those easy crossfades implemented, and maybe that I kick the devs' butts so that they merged 2-3 patches on those bug reports, the release could be done [03:11] rickspencer3: my gut feeling is that something like pitivi is a pretty big change to be bringing into an LTS, without it having been part of the default install prior to LTS. but maybe the code in git is stable-ish now. [03:12] basically, all the features need to be in by next Tuesday, though officially this Thur is the cut off [03:12] dobey, you're not entirely wrong on this, I'd say. On the other hand, I've been worrying a bit about the LTS Thing [03:12] otoh, maybe the visibility will make pitivi contributors appear in droves :) [03:12] Then it's fixing bugs up until we ship [03:13] 3 years is a long time to be supporting unstable software :) [03:13] hm hm [03:13] nekohayo: is there a PPA with the git pitivi in it? [03:13] dobey, there is, since a few days [03:13] * TheMuso can't believe rickspencer3 is in here on his day/evening off. :p [03:13] * nekohayo searches for it [03:13] Lets make it stable if we can [03:14] http://rowinggolfer.blogspot.com/2010/02/pitivi.html [03:14] it's a good product that users like [03:14] TheMuso: freezes can be at rather inopportune times :) [03:14] dobey: yeah I am aware of that, but a day off is a day off. :) [03:14] I'll be off in a few [03:14] nekohayo: get kenvandine to use that version for a bit then. I *know* he was having issues with pitivi :) [03:15] I was just online wokring on some of my side projects [03:15] dobey, it wasn't pitivi that was the problem [03:15] his problem was that the gtk-recordmydesktop was not encoding files correctly [03:15] rickspencer3: ah [03:15] rickspencer3: ok. i didn't know if he got it resolved or not :) [03:16] he didn't, but the bug is not in pitivi [03:16] well, garbage files are garbage files. probably can't really fix the files i guess. but good to know where the problem is [03:18] TheMuso: eh, I worked today too. trying to get all the ubuntu one client stuff 'done' for feature freeze [03:19] kenvandine, get your crack right there. [03:19] https://launchpad.net/~rowinggolfer/+archive/pitivi-unstable [03:19] depends on the gstreamer-developers PPA [03:19] aah, that good old recordmydesktop [03:19] I'll feel the pain again when I'll have to make a pitivi 0.13.4 screencast. [03:19] nekohayo, just fyi, we are scheduled to make the pitivi go/no go descion for beta 2, I think [03:20] oops, beta 1, I mean [03:22] dobey: fair enough [03:24] dobey, /me has more hopes in gnome-shell becoming the new decent screencasting tool than recormydesktop ever being fixed :| [03:26] Eh. I wish I could get interest and help on my project. I don't really have time to work on it though. [03:27] recordmydesktop is yours? [03:29] no [03:29] deskscribe is [03:30] * nekohayo searches [03:30] it doesn't do video recording yet, but i want it to [03:30] launchpad.net/deskscribe :) [03:30] oh I see [03:32] I've been tempted to resurrect the compiz video recording plugin just to get good screencasts [03:33] seems using recordmydesktop with compiz requires something better than 2Ghz C2D and intel X3100 graphics [03:33] * nekohayo just found out https://bugzilla.redhat.com/show_bug.cgi?id=525155 [03:33] this may explain my recent troubles with r-m-d in karmic [03:33] bugzilla.redhat.com bug 525155 in recordmydesktop "Theora is broken in Rawhide" [Medium,Closed: errata] [03:33] but it doesn't explain the "broken" theora frames (https://sourceforge.net/tracker/?func=detail&aid=2827013&group_id=172357&atid=861428) [03:34] bleh [03:34] Error: Sourceforge bug 2827013 not found [03:37] with istanbul and recordmydesktop being abandonned, my only hope is gnome shell [07:03] Good morning [07:08] hllo === kermiac_ is now known as kermiac [08:10] good morning [08:10] bonjour didrocks [08:12] hey pitti [08:15] asac: did someone mention the GtkCellRendererSpinner to you yesterday btw? [09:03] good morning everyone [09:03] hey chrisccoulson, good morning [09:03] hey pitti, how are you? [09:04] I'm great, thanks! how about you? [09:04] * pitti is packaging upower [09:04] i'm quite tired this morning. my girlfriend is not very well, so i had quite a restless night [09:04] are we migrating to upower this cycle? [09:04] uh, I hope she'll get well soon [09:05] chrisccoulson: yes, I'd like to (same as udisks) [09:05] will make backporting patches much easier [09:05] cool! [09:05] or running backports [09:05] i subscribed to the bugs in udisks already [09:05] hey chrisccoulson pitti [09:05] hey seb128 [09:05] and I already did some bug fixes in upstream trunk which the OEM team is waiting on :) [09:07] HR have arranged a leaving interview here with me on friday morning [09:07] right at the same time my breakfast arrives! [09:08] hey chrisccoulson, seb128 [09:08] hey didrocks [09:08] bonjour seb128 [09:09] chrisccoulson, way to finish a week! [09:09] chrisccoulson, hope your gf get better too btw [09:09] thanks :) [09:09] hello didrocks, pitti [09:12] hey chrisccoulson, I saw your message or yesterday this mornig, what so I do so? comment the missing symbols ? [09:13] hey baptistemm - the missing symbol was never part of the public API, so it's not an issue that it is no longer exported in the new version [09:17] so I just need to remove it from the .symbols file before the building and that's it [09:18] baptistemm: yeah, that will work [09:21] baptistemm: the removed symbol was never included in any public headers [09:22] so i assume that they exported it by accident [09:22] seb128: do you have a minute to source NEW upower? (it's just a package rename) [09:22] pitti, sure [09:22] seb128: merci! [09:23] de rien! [09:23] chrisccoulson, by accident means a bug in dpkg-gensymbols (osrry I have now knowledge about symbol export) [09:23] baptistemm: the exported symbols is controlled by upstream [09:24] i think they ship a symbols file to control that [09:24] what does dpkg-gensymbols to knwo public symbols, does it scan *.h files? [09:24] *scans* [09:25] baptistemm: dpkg-gensymbols scans for symbols exported by a library (using nm, I think) [09:25] baptistemm: http://people.redhat.com/drepper/dsohowto.pdf [09:25] thanks [09:25] that has a good section of how to control symbols exported by shared libraries [09:27] section 2.2 "Export Control" [09:32] pitti, do you need shlibs when you use .symbols? [09:33] seb128: no, you don't [09:33] pitti, ok, because upower has one in the rules? [09:33] DEB_DH_MAKESHLIBS_ARGS_libdevkit-power-gobject1 = -- -v1:$(DEB_VERSION) [09:33] you mean this? [09:33] yes [09:34] seb128: without that, dpkg-makeshlibs drops the epoch from debian/libdevkit-power-gobject1.symbols and complains about the file having totally changed [09:34] it gets confused because it gets the package version from debian/changelog usually [09:34] ah I see [09:35] but debian/rules adds an epoch to the devkit-power-* stuff [09:35] (which we need, because 0.9 < 011 [09:35] we can drop the libdevkit-power-gobject* bits at some point when everything got ported to libupower-glib [09:37] pitti, ok makes sense, looks good, newed [09:37] seb128: merci [09:37] de rien [10:09] what is working on nm-applet there? [10:09] what -> who [10:10] I got the lazy icon loading change done yesterday evening and waiting for upstream review [10:10] I would appreciate review and sponsoring from somebody working on nm-applet if we want that in lucid for alpha3 now [10:11] seems the packaging is using source in git and I'm not sure how to deal with it too [10:11] asac, ^? [10:11] Vcs-Bzr: https://code.launchpad.net/~network-manager/network-manager-applet/ubuntu.head [10:11] oh, it's not that one? [10:12] seb128: I'm happy to help out with git stuff, by now I got fairly familiar with it (*sigh*) [10:12] pitti, let me look again [10:13] I though that was in git I'm not sure why now === kermiac is now known as kermiac_ [10:15] pitti, ok, I think I got confused, I will work on the update now [10:15] still a review from somebody else would be welcome once that is done ;-) [10:15] o/ [10:15] pitti, thanks [10:17] seb128: our packaging doesnt use git [10:17] its the branch pitti pointed to [10:17] asac, yeah I got confused apparently [10:18] seb128: get me the patch you want reviewed [10:18] seb128: already submitted upstream? [10:18] asac, https://bugzilla.gnome.org/show_bug.cgi?id=609134 [10:18] Gnome bug 609134 in nm-applet "should do lazy loading for icons" [Normal,New] [10:18] asac, the current change on this bug [10:18] startup time? [10:18] asac, yes... [10:18] lazy icon loading [10:18] ie not loading 35 icons for animation when not needed [10:19] + the vpn ones when not using a vpn [10:19] etc [10:19] btw - do you have any idea why are fields in debian/control called Vcs-Bzr: Vcs-Git: instead of (for example) Vcs-Ubuntu: Vcs-Debian? [10:20] seb128: ok. doesnt look bad on first glance. i assume you want that to be prepatched in our packaging? [10:20] asac, I've no strong opinion, I'm fine waiting a few days for dan to comment upstream [10:21] pitti, ^ how much do we want that one in for alpha3? [10:21] ok. if you say its ok to wait, i can poke him to give his review too [10:22] seb128: there are some indentation style changes [10:22] like here: [10:22] +nma_icon_check_and_load (const char *name, GdkPixbuf **icon, NMApplet *applet, [10:22] +gboolean fallback) [10:23] right [10:23] asac, do you want a lp bug for that? [10:23] not needed if you dont need it ;) [10:23] ok good [10:23] less work ;-) [10:24] tell me if you want that up today for a3 [10:24] seb128: I don't consider it a blocker for alpha-3, it doesn't have any functional change [10:24] seb128: so if it's easier to get in after alpha-3, fine [10:25] k [10:25] i will let cyphermox commit this to our branch ... so it gets in daily [10:25] asac, wait [10:25] there is another change required [10:25] I'm on it [10:26] seb128: ok. let me know. [10:28] note to myself: never work directly in quilt with bzr bd-do… to much chance to exit 0 before quilt refresh… [10:31] didrocks - oops ;) [10:32] did you lose much work? [10:32] asac, http://people.canonical.com/~seb128/nm-applet.debdiff [10:32] chrisccoulson: yesterday's evening work on force refreshing cache [10:32] asac, one distro patch needed to be updated for the change [10:33] chrisccoulson: but that's ok, 30 min to redo it when you know what to do :) [10:33] asac, that one should be good to use [10:36] asac, also can we get it to use automake1.10 instead of .9? ;-) [10:39] didrocks: hang on [10:39] didrocks: if you exit bd-do, it doesn't wipe anything [10:39] didrocks: it's still in ../build-tree/gnome-desktop-/ [10:39] just go back there and diff/hack/copy [10:39] pitti: yes, but this morning, I've redone a bzr-do [10:40] bd-do* [10:40] or presumably quilt diff/quilt refresh [10:40] ah, you lose then :( [10:40] right [10:40] it's ok, I've rewrite it now [10:40] I launched nm on the old bin to see I didn't forget anything [10:40] didrocks: using the image_serialize bits? [10:41] pitti: to force the caching? no, I use some part of the libgnome-desktop API [10:41] didrocks: no, to write the cache [10:41] didrocks: right now you are storing a .jpg? [10:41] pitti: I didn't changed that yet [10:41] ah, ok [10:42] why does that need to be changed? [10:42] pitti: I'm storing in the same format than the original file, why? [10:42] didrocks: mclasen suggested using this serializing API, which is even faster (avoids decoding the jpg, etc.) [10:42] might be worth a try [10:43] pitti: right, I just want to finish my WI before alpha3, we can change that later, right? [10:43] brb, trying gnome-keyring update [10:43] didrocks: sure [10:43] pitti: I still have this 2D/3D thing that was added last week on netbook-launcher [10:44] pitti: so, finishing the command line, postinst is ready and then, go to the other task [10:48] asac, bluez will have a fixed release about API breakage [11:36] ok, work lost again… [11:37] didrocks, how did you do that? [11:38] seb128: this time I really don't know. I quilt add Makefile.am to include the file in the build [11:38] refresh then… [11:38] quilt pop -a [11:38] exit 0 [11:38] and then, I only see the Makefile.am in the patch, no more source file [11:39] * didrocks get stressed [11:39] didrocks: why would you expect anything else than Makefile.am if you didn't add anything else? [11:39] pitti: I added before the other file [11:39] pitti: refresh, exit 0, and so on [11:40] I obviously did something wrong, but can't find what now [11:40] so, I will rewrote for the third time the file, out of quilt + bzr, and then, copy to it [11:40] didrocks: don't rewrite the file, it should still be in ../build-area/dir/ [11:40] DON'T do bzr bd-do now! [11:41] pitti: I saw that the file wasn't there when I did bzr bd which failed logically as no source file there [11:41] so, too late [11:41] urgh [11:41] well, first time, 1h, second time 30m, third time 15min? [11:41] perhaps copy the file to your home dir right before doing the patch building [11:41] pitti: I will work in my home dir this time :) [11:42] * didrocks start timer [11:42] I seldomly do patches in bzr bd-do and quilt these days [11:42] but still, it shouldn't be that hard :) [11:43] I don't understand what was wrong this time. I know for yesterday's mistake and it's all my fault. But today… [11:43] well, let's go back to it [11:44] baptistemm: great. so when thats out we can update ;) [11:44] baptistemm: how happy were they about this incident? [11:46] asac, Apparently holtman already fixed on saturday night that on git after I had a look there. [11:46] but he didn't send an ack on IRC for that [11:46] yeah. [11:47] so it didn't really care my mail :) [11:47] s/it/he/ [11:47] asac, should I wait next really or push bluez with the fix [11:47] baptistemm: i dont see a reason to make an early push [11:48] bluez releases often enough [11:48] hey, they wasn't any really for a month :) [11:48] s/really/release/ doo [11:49] right. if they dont release in one or two weeks, lets request a release to unbreak api [11:49] holtman said a release will be pushed soon [11:59] seb128: hey, I have an update for the humanity-icon-theme package (lp:~ubuntu-art-pkg/humanity/release) can you upload it when you get a chance? [12:02] ok, redone. /me triple backups it [12:05] kwwii, ok [12:11] ah found it, I quilt add after adding the file the tree [12:13] well that should make it ignore your change [12:14] but not drop other changes [12:14] like that doesn't explain the "editing makefile.am dropped source changes" [12:17] well, right, I don't know what I did wrong. This time, I have it, let's build the package. Too much thing for a tiny script a little postinst call :/ [12:21] kwwii, impressive list of bugs closed by this update mr wimer ;-) [12:22] seb128: hehe, thanks go to vish (I only made on of those icons!) [12:22] vish: ^ (well done!) [12:25] vish, good work! [12:26] kwwii, there is no upstream tarball right? [12:26] kwwii, ie usually it's just built from bzr [12:27] seb128: yepp [12:27] ok, good [12:29] kwwii, ok, I'm uploading that, can you change the bzr to have "0.5.1" as version? [12:29] kwwii, since you don't have a diff.gz you don't need an ubuntu revision [12:30] kwwii, just delete the "-0ubuntu1" in the changelog [12:31] it seems that bug 434316 is back (at least for me, not every time bug if I use system for a while it shows up eventually) - have it been reported already? [12:31] Launchpad bug 434316 in empathy "Useless black bar in notification area visible" [Low,Fix released] https://launchpad.net/bugs/434316 [12:31] s/bug/but [12:31] kklimonda, are you sure it's due to empathy? [12:31] seb128, if I kill empathy line goes away [12:32] ok, so I don't know [12:36] djsiegel, so the hundredpapercut you pointed yesterday is not really one === MacSlow is now known as MacSlow|lunch [12:36] djsiegel, you don't usually need password storage since once a share is mounted it will stay mounted for the session [12:37] djsiegel, and on the smb case it's done this way because sometime you need different credentials to have write access to some shares [12:37] djsiegel, and if you were automatically using the default password you would break those usecases [12:38] djsiegel, let me know if you disagree there or need extra details [12:38] (that's from a discussion with upstream today) [13:02] seb128: yes, will do [13:14] kwwii: seb128: thanks :) [13:16] I need to know as well what display the user is on too (so that gdk_init succeed). /proc/{pid}/environ or is there a nicer way? [13:17] didrocks - consolekit? [13:18] chrisccoulson: in a postinst script? is it easy to call? [13:18] didrocks: eww [13:18] hmmmm, i'm not too sure [13:18] what are you trying to do? [13:18] didrocks: aren't you looking for running gnome-settings-daemon processes anyway? [13:18] didrocks: you could just fish it out of /proc/pid/env [13:19] pitti: right, hence my proposal. I was asking if there was a nicer way [13:19] $ xargs -0n1 < /proc/$$/environ |grep ^DISPLAY [13:19] DISPLAY=:0.0 [13:19] didrocks: not to my knowledge [13:20] ok, will use that so. Thanks :) [13:20] gosh, how hackish; well, sabdfl always wins :) [13:21] pitti: yeah, was not that easy… a lot of time for tiny result… [13:23] * hyperair wonders if it's okay to be running some graphical program from within a postinst [13:24] surely all kinds of strange things can happen during installation, like X crashing or something that will cause the postinst to fail spectacularly? [13:24] hyperair: it's not running a graphical soft, just need X for gdk getting things [13:24] didrocks: what if the upgrade was done without X running? [13:25] hyperair: g-s-d will not run so [13:25] seb128: ah, with yesterday's update teh sound indicator started working \o/ so it wasn't due to a bad PPA [13:25] ah [13:26] kenvandine: does the power indicator still have a chance to land this week? or should we postpone to beta-1? [13:30] kenvandine: (I'm a bit nervous about that TBH; unlike gnome-volume-control-applet, gnome-power-manager is a huge piece of code to replace..) [13:31] eh? gnome-power-manager's getting replaced? [13:33] pitti, there is a gpm port to the indicator system waiting in launchpad [13:33] ah, it's a patch, not a rewrite [13:33] it's gpm patch for now apparently yes [13:37] tseliot, bryceh: given that the "Fix logic in patches 104 and 105 to correctly select -nvidia when appropriate" work item was postponed, would it be correct to postpone "Auto-config nvidia: Identify logic in jockey which inserts configuration into xorg.conf and create analogous logic in xserver" as well? [13:37] ISTR that you didn't want to do that kind of magic in lucid? [13:38] pitti: yes, I think we should definitely postpone it. I don't think I will have the time to implement it any time soon [13:39] not in time for Lucid [13:39] tseliot: ack, will do [13:39] ok [13:41] tseliot: what about bug 258038? [13:41] Launchpad bug 258038 in fglrx-installer "Look into feasibility of using an alternatives system rather than diversions" [Wishlist,Fix committed] https://launchpad.net/bugs/258038 [13:42] I haven't followed using the alternatives system for fglrx [13:42] is that even necessary? [13:42] i. e. does fglrx also divert libGL and the like? [13:42] it seemed much less intrusive to me [13:43] pitti: g-s-d pushed, postinst and bin on it [13:43] pitti: that's fixed. I have already worked on that together with superm1, we pushed the changes to the upstream git. I will pull them when AMD releases an fglrx driver which works with Lucid's xserver [13:43] pitti: as gnome-desktop hasn't been sponsored yet with fixed quality cache. I will try to do the change about serializing now [13:44] pitti: currently the package is not installable and doesn't contain our changes. [13:44] didrocks: \o/ [13:47] didrocks, do you need gnome-desktop sponsoring? [13:48] seb128: hum, there is one version waiting, but as I'll erase the changes and saving with serializing the pixbuf, this will go away, so no need now, thanks :) [13:48] ok [13:48] just hackish g-s-d needs :) [13:49] didrocks, oh please don't do that for g-s-d [13:49] don't patch makefile.am with a new source [13:49] you should rather put your .c in the debian dir [13:49] and call gcc in the changelog to build it [13:49] oh really? I saw that for gdmsetup and other packages [13:50] gdmsetup is code we try to get upstream [13:50] didrocks: it's fine to do that in your upstream patch, of course [13:50] your change has nothing to do with g-s-d code [13:50] and it forces us to keep running autoreconf [13:51] there was already one autoreconf file, but yes, I put the .c in the debian dir, and call gcc in control [13:51] (we need it for other changes right now but still we try to get away from those not to add new ones) [13:51] rules* [13:51] ok [13:51] well my opinion [13:51] didrocks, maybe do that for now and revisit after ff [13:51] what you did work but will be extra work over time I feel [13:51] we can clean that later though [13:52] didrocks, "that" being what you commited now [13:52] ok, I'll prefer if we can change that after FF :) [13:52]