[00:06] rickspencer3: Good morning? [00:09] hey RAOF === gord_ is now known as gord [02:55] RAOF: What is the kernel command line flag to disable nouveau DKMS? [02:56] RAOF: s/dkms/kms/ [03:00] nomodeset ? [03:00] RAOF: nvm found it. Lifeless, retty much, nouveau.modeset=0 [03:01] xorg no longer supports non-kms nouveau, but thats not a problem for me atm [03:01] * TheMuso is trying to get more context for a maverick daily live CD kernel panic. === aganice_ is now known as aganice [04:44] TheMuso: The daily CD panic which happens really really early on in the boot? [04:47] RAOF: Yep, and I worked out why. [04:47] RAOF: casper is missing from all except i386. [04:47] * TheMuso digs further. [04:47] Hm. I thought I tried it _on_ i386. [04:53] RAOF: Hrm you may still have done so, I think the reason why its not on the latest live CD for amd64 is because the latest livefs FTBFS for amd64 due to broken packages. [04:54] So its fixed, and the latest livefs for i386 has casper [04:54] * TheMuso checks latest live CD for i386 to be sure. [05:00] Yep, i386 latest is ok. [05:00] So amd64 should sort itself out in due course. [05:04] Damn you evolution, stop eating all my ram. Chromium wants some, too! [05:05] lol [05:05] * TheMuso pats mutt. [07:36] good morning [07:37] Howbidie didrocks [07:38] hey RAOF, I'm fine, thanks, and you? [07:38] Pretty good. [07:39] Barring accidents there should be no electricians coming to prod anything in this house now for many years :) [07:42] heh cool [07:45] Come back evolution! There's lots of memory for you now. Please don't crash :( [07:48] heh [07:50] 3 apport reports. Total size: 650 MiB. [07:50] ouch [07:51] Hooray for adsl annex M. [07:54] My favourite backtrace is from btrfsck, though. You know a filesystem needs more cooking when it's consistency checker segfaults :) [07:55] RAOF: you are brave. [07:55] * RAOF is fully backed up [07:55] Still... [07:56] Not only fully backed up, but I have 3 other systems available. [07:56] Some of which aren't even running Maverick yet! [08:00] heh fair enough [08:00] * TheMuso never touches experimental filesystems. Touched reiserfs once, got burned, never again. [08:01] Didn't fsck.reiserfs have the charming tendency to find and merge b-tree-like files from filesystems it was checking, with hilarious consequences? [08:01] * RAOF never got bitten by that, but it _sounded_ fun :) [08:02] Don't know. [08:02] It was enough that I got burnt. [08:05] Yeah. Data loss is only fun if it's expected. === cassidy` is now known as cassidy [08:35] seb128: hi , Bug #372132 , was supposed to be scheduled for Karmic , but somehow feel under the radar.. could be get it milestoned for maverick, so that we dont miss it again? and who is working on it now, pitti switched it to the desktop team? [08:35] Launchpad bug 372132 in nautilus (Ubuntu) (and 1 other project) ""Create Document" Templates difficult to use (affects: 19) (dups: 5) (heat: 154)" [Wishlist,Triaged] https://launchpad.net/bugs/372132 [08:35] comment #36 seems to have been the discussed fix for the bug [08:35] vish, the issue is not to milestone it, it's to agree on what to change and how [08:35] ah , so needs design then? [08:36] yes [08:36] salut seb128 [08:36] lut didrocks [08:37] vish, we would need somebody to provide the templates to ship, ie mimetype and content [08:37] vish, there is also no way right now to set system templates so it would require nautilus code changes [08:38] vish, which upstream disagreed to do since they think letting a way for any software to install its template will lead to have every software installing one and making those pretty useless [08:39] seb128: hmm , ok. somehow comment #36 seemed like the final decision by the desktop team or rick [08:39] vish, as written it's a summary of what pitti and I agreed on being a reasonable way to do that it we were to do it [08:40] vish, still we don't have a decided list of templates nor the nautilus code changes to use a system template directory [08:41] seb128: cool , so is there anyone working on getting the templates list ready? [08:42] dunno, you should be the one telling me [08:42] nobody from the desktop team side at least [08:42] hmm .. [08:44] to be honest I'm not sure those templates are worth the time we spent arguing over it [08:44] upstream disagrees giving any way to install system templates [08:44] once you have those users have no way to opt things out [08:45] seb128: yeah , they fix suggested is kinda hacky :s [08:45] which means if I don't use some of the softwares the distro install templates for I have to get my templates listed polluted by those [08:45] seb128: why not just hide the option? [08:46] display only when user has some templates? [08:46] it doesn't solve the discoverability issue [08:46] ie most users will not figure that nautilus can do templates this way [08:48] seb128: its not like users are properly using templates now , let me get back to you on this. [08:48] thanks [08:51] vish, thanks [08:51] vish, right, they are not, we just need to know what we try to solve [08:52] vish, ie making that system easier to use or less confusing or...? [08:52] Good morning [08:53] hey pitti [08:53] how are you? [08:54] seb128: maybe you can un-assign the bug from the Canonical desktop team? and comment that on the bug , rickspencer3 and pitti's comments make it seem someone is working on it. [08:54] vish, done [08:54] seb128: thanks [08:55] seb128: bit tired, but ok otherwise; how are you? [08:56] pitti, still waking up but quite fine otherwise, morning is nice since it's not warm yet [08:56] on this part of the planet it is [08:57] right [08:57] pitti, you are on another part of the planet atm or that was just a comment? ;-) [08:58] seb128: about 800 km to the East of you, as usual :) [08:58] ;-) [09:00] bah, that gnome-menus cache starts annoying me [09:00] hey pitti [09:01] seb128: what's wrong with it? [09:02] pitti, we get quite some bugs from random packages or sysadmin scripts or whatever installing desktop in the directory which are masked by the cache since those don't know about the cache which is Ubuntu specific [09:03] but that's what /usr/local/ is for.. [09:03] it's hard to tell them "it's your fault, you should tell $distributor or $sysadmin to call that ubuntu specific cache update command" [09:04] hm, third-party packages would trigger the cache update, though? [09:04] pitti, seems for example chromium packages from the upstream chromium guys have the issue [09:04] pitti, some do hack in the maintainer scripts for example [09:04] where "packages" != "debs"? [09:05] the trigger should work for debs [09:05] see https://bugs.launchpad.net/bugs/598711 [09:05] Launchpad bug 598711 in gnome-menus (Ubuntu) "Missing menu entries in Lucid (affects: 1) (heat: 6)" [Low,Incomplete] [09:05] comment #5 [09:05] would it help to compare the timestap of the cache to the timestamp of the /usr/share/applications/ dir? [09:05] I was thinking about that [09:06] this wouldn't catch changes to the files, but additions/removals should be caught [09:06] but doing a touch on a .desktop doesn't change the directory timestamp it seems? [09:06] but yeah, I think the cache should be invalidated if it timestamp is older than the dir one [09:06] that's what the gtk icon cache does IIRC [09:08] pitti, bug #563968 [09:08] Launchpad bug 563968 in xdg-utils (Ubuntu) "newly added menus not visible (affects: 2) (heat: 55)" [Undecided,New] https://launchpad.net/bugs/563968 [09:09] as well [09:09] or bug #591135 [09:09] Launchpad bug 591135 in gnome-menus (Ubuntu) "Application menu do not update after a program installs (affects: 1) (heat: 239)" [Low,Incomplete] https://launchpad.net/bugs/591135 [09:10] hum, that one is a different issue [09:10] pitti, right, I think the timestamp thing would catch most issues [09:11] and it's quite cheap [09:11] I guess we already stat() the cache anyway in the code, so it's just one extra stat() for the dir [09:12] pitti, ok, I will open a bug about that an target it for lucid-updates [09:12] pitti, thanks ;-) [09:13] now that we have gvariant, it might also be nice/faster to use that instead [09:13] but I don't know how it compares speed-wise with g_key_file [09:13] pitti, are you still interested to do that and upstream the change this cycle? [09:14] not sure whether I'll have time, but I think I can at least do a performance comparison [09:14] conceptually, parsing an .ini file is much simpler than parsing an arbitrarily nested and datatype rich structure [09:14] ok, no hurry in any case [09:14] right [09:17] pitti: I had to disable the mutter desktop file patch to launch it in "Initialization" phase insead of "WindowManager" one (80_no_session_delay.patch). It created bug #599506 with gnome-keyring. Do you have any idea how we can fix this nicely? (so that mutter can be started before gnome-keyring is) [09:17] Launchpad bug 599506 in mutter (Ubuntu) "mutter doesn't position SSH_AUTH_SOCK to gnome-keyring value (affects: 1) (heat: 6)" [Medium,Fix released] https://launchpad.net/bugs/599506 [09:36] pitti: Good morning! If you've got a minute, I'd like to revisit the reasoning behing discarding ConsoleKit as a mechanism for ensuring /sys/class/drm/backlight/* is accessible to X. [09:37] Because I'm not familiar enough with ConsoleKit, and when talking about backlight and unpriviledged X various people have said “why not just use ConsoleKit”. [10:00] RAOF: because /sys is not a real file system, I don't think you can actually chmod those files? [10:00] I don't have it on my machine, but if you have it, perhaps try? [10:04] pitti: you probably miss this ^ (just before RAOF's question) [10:17] right, I had a freeze, so I probably missed some scrollback [10:17] RAOF: perhaps you can re-paste? [10:17] didrocks: or you mean I missed something else, unrelated to RAOF's question? [10:17] pitti: yeah, it was: [10:17] I had to disable the mutter desktop file patch to launch it in "Initialization" phase insead of "WindowManager" one (80_no_session_delay.patch). It created bug #599506 with gnome-keyring. [10:17] Launchpad bug 599506 in mutter (Ubuntu) "mutter doesn't position SSH_AUTH_SOCK to gnome-keyring value (affects: 1) (heat: 6)" [Medium,Fix released] https://launchpad.net/bugs/599506 [10:17] Do you have any idea how we can fix this nicely? (so that mutter can be started before gnome-keyring is) [10:18] (I just asked that before RAOF, double hilighting should have make it disappear ;)) [10:19] didrocks: ah, I see; now, it was worth a try.. [10:19] pitti: didn't we win something like 0.5s with this? [10:19] didrocks: it seems we need to start keyring before mutter then [10:19] yeah, not sure if we can order that in the same phase [10:19] didrocks: yes, we did; since unity is by and large the one and only process which burns a lot of CPU, and is the critical path, it needs to start as early as possible [10:20] but correctness > speed, of course [10:20] didrocks: the only other option that I see is to start keyring from Xsession.d/ and mutter in Initialization [10:20] hum, I'm also afraid that this side-effect can happen with other components [10:20] but WindowManager sounds fine [10:20] it'll still start before the other apps then [10:20] right [10:21] didrocks: it's probably best to do a current bootchart with that reverted change, and see whether it opened any CPU gaps [10:21] if it's still just one big block without gaps, it doesn't really matter [10:21] pitti: yeah, good idea. do you still have your autofoo CPU charts? (I only have an HD there) or maybe seb128 can do one on his spare time [10:21] pitti: ok, thanks a lot for your input :) [10:21] autofoo? [10:22] oh, I never had [10:22] that was Keybuk [10:22] oh, I was thinking you tried it at least once :) [10:22] didrocks: I currently have an OEM project on the Mini, but I guess I can install alpha-2 on the thing now [10:22] I just start my mini there and watch /var/cache [10:22] I can do charts, my mini is running maverick uptodate [10:22] didrocks: http://people.canonical.com/~pitti/bootcharts/daniel-maverick-20100622-1.png is not too old [10:23] pitti: looking at it, can be good to compare with last one [10:23] seb128: that will be awesome, thanks ;) [10:23] oh, can we start g-p-m in the apps phase instead of init? [10:23] i thought we did that already? [10:23] chrisccoulson: gpm is in init IIRC [10:23] on this chart X took quite long, and left a sizable CPU gap [10:24] didrocks, how did that happen? it's in the apps phase upstream? [10:24] chrisccoulson, didrocks: OTOH it's probably fine that way; at the sessino start we still have some CPU power left, at least on my chart [10:24] chrisccoulson: perhaps it was even me, trying to fill the CPU gap at session start :) [10:24] pitti - it will block the transition to the next phase though won't it? [10:24] there's not a whole lot of things which can run as the first thing, and gpm sonuds relatively independent [10:24] chrisccoulson: not sure, just that when I checked yesterday, just remember we got that :) [10:24] (g-p-m doesn't fork) [10:25] chrisccoulson: not sure; if it was me, I'm fairly sure I compared it before/after [10:25] we really need to put nm-applet on some more CPU diet, though [10:25] ah, ok [10:25] pitti - g-p-m should be better in the apps phase (remembering that it also activates upower) [10:25] it takes 70% of what mutter/unity needs [10:26] chrisccoulson: it would be nice if upower could start right at the session start [10:26] yeah, nm applet is really expensive [10:26] in the first second we still have one CPU free (mostly), but after that both cores are constantly busy [10:28] pitti: I can happily chmod those files, even though they're virtual. [10:28] RAOF: ah, I didn't know that; well, then it ought to work, although we can't use the already existing standard udev mechanism directly [10:29] (this only works for device files) [10:29] but it still sounds rather easy to do [10:29] with a script in /usr/lib/ConsoleKit/run-seat.d/ [10:29] * chrisccoulson goes to crawl back in to mozilla hole ;) [10:29] cleaner than adding a hack to udev-acl [10:29] chrisccoulson: good luck :) [10:29] * pitti pats chrisccoulson onto the back and hugs him [10:30] Aha. That's where the fun is! [10:30] * chrisccoulson hugs pitti too [10:31] didrocks, could you resync mutter on debian? [10:32] RAOF: so you could just drop a script there which does the chmod [10:32] didrocks, they don't have any real change out of a gir fix you did I think but g-s build-depends on the current revision and depwait due to it [10:32] pitti: Sounds nice and simple. Hurray. [10:32] RAOF: I don't know the arguments offhand, but perhaps just start with echoing $@ and `env` to a log file? [10:32] :) [10:33] seb128: sure [10:33] RAOF: but didn't gnome-power-manager git head get a polkitified helper for this, too? [10:33] didrocks, thanks [10:33] it completely dropped the hal bits [10:33] RAOF: or does X itself need to access that? [10:34] didrocks, no hurry you can update later on or tomorrow if you wait for other changes, would just be nice to have it for a2 if we can [10:34] pitti: X itself (or, rather, the intel DDX) needs to access it to provide the xrandr backlight interface. [10:34] seb128: no, I won't update to new mutter before a2 in any case, and I have spare cycle now, so doing it as long as I can :) [10:35] ok [10:35] didrocks, thanks [10:35] RAOF: ah, right; i. e. pretty much exactly what gpm has to do by itself if the xbacklight one isn't available [10:35] seb128: yw :) [10:37] pitti: Yup. The radeon and nouveau drivers know how to poke their hardware directly; the way Intel sell their chips means that they can't :) [10:38] Sarvatt, hey, interested to do the cairo 1.9.10 update? ;-) [11:13] so, our amd64 CD is oversized by 21 MB :-( [11:14] and both i386/amd64 alternates look similarly bad [11:14] any idea what we piled up? [11:14] I think that I discussed somethign like that with someone ("we temporarily need to add foo which will oversize"), but forgot the details [11:14] didrocks: ^ do you happen to remember? [11:14] or seb128 ^ [11:15] pitti, the discussion we had was about chromium on UNE [11:15] ah [11:15] pitti: yeah, pool/ contain more than 13 additional Mb [11:16] pitti: I don't know what control what's in pool [11:16] it's the live-ship and ship seeds [11:16] (for desktop and alternate respectively) [11:16] for netbook, for instance: http://paste.ubuntu.com/456825/ [11:17] I think amd64 should have a similar issue, the manifest are approximately the same last time I checked (2 weeks ago) [11:17] didrocks: that looks fairly unsurprising, though [11:17] it's 13 Mb at least (du -sh pool/) :) [11:18] additional* [11:18] didrocks: is that new? [11:18] pitti: happened shortly after A1 [11:18] we have always shipped some langpacks and some driver stuff, didn't we? [11:19] only four seed changes since a1 in Ubuntu, and they look harmless [11:19] we added bootchart and unclutter [11:19] pitti: it was even before seed change [11:19] pitti: I think something takes that in [11:19] (well, netbook-wise speaking) [11:20] I think it's impacted from maverick.ubuntu seed too, right? [11:20] * didrocks checks the seeds now, don't remember for live-ship and ship if that's special to netbook [11:20] and platform seeds didn't really changed either, so it must be new dependencies [11:21] pitti, I don't see an obvious change or component out of place in the manifest list [11:21] I guess some new version of softwares are taking extra space [11:21] * pitti starts with poking component-mismatches [11:32] didrocks: netbook-launcher wants to go to universe [11:32] didrocks: shouldn't we perhaps remove the package completely and have unity build a transitional package? [11:33] pitti: unity build a transitional package. so, it's just about remove netbook-launcher source package, right? [11:33] ah, right [11:34] o netbook-launcher: libnetbook-launcher-0 libnetbook-launcher-dev [11:34] and the libs [11:34] didrocks: unless someone else wants to continue to maintain it, of course (do I remember some conversation there?) [11:35] pitti: yeah, current statement is about removing it from now and reupload it if someone is interested. No candidate for now [11:35] alright, I'll remove it; thanks [11:35] LP doesn't forget, if we ever need the packages again :) [11:35] pitti: thanks :) [11:35] right [11:38] indicator-appmenu-tools: Depends: libdbusmenu-tools but it is not installable [11:38] E: Broken packages [11:38] any idea about that? [11:38] oh, it's in universe [11:38] * pitti moves indicator-appmenu-tools to universe as well [11:39] sorry for the noise [11:40] no, it's good to have some notes of what's happening for further learning ;) === DrPepperKid is now known as macslow|lunch [12:02] https://bugs.launchpad.net/ubuntu/+bug/599164 <-- does anyone know what package this bug belongs to, and the master bug, if any? [12:02] Launchpad bug 599164 in ubuntu "maverick daily build unknown user id (affects: 1) (heat: 6)" [Undecided,New] [12:18] ok, the new packages since a1 account for 6.2 MB [12:18] that still leaves 13 MB to be accounted for [12:20] pitti: did you include the pool/ directory in your new packages? the 13 MB is exactly the pastebin I put there before between desktop and netbook (I think it's the same for amd64 as the size is similarly the same) [12:20] I compared maverick alternates [12:20] they only have pool/, by and large [12:21] ok, dunno on alternates, just looked at live [12:21] the rest seems to be package growth [12:21] well, 13 MB is something… [12:25] didrocks: but why do you think those are new? [12:25] http://cdimage.ubuntu.com/releases/maverick/alpha-1/maverick-desktop-i386.list [12:26] the seeds didn't change at all wrt. ship* [12:27] pitti: I'm not telling they are new, I just made a diff to understand why the maverick desktop image and the netbook one were so different size speaking (as the diff to the manifest was just showing not so many differences) [12:28] pitti: that's where I saw that pool/ is taken much space on netbook (and I guess it should be the same on amd64 image as the size are relatively equivalent) [12:28] pitti: I don't say it's not things we didn't ship in previous release, just to understand the size difference between images [12:28] right, but they don't contribute to the growth if we already shipped them in a1 [12:29] it's by and large build-essential and some drivers which we put into ship [12:30] right, (I'm not sure all were shipped in a1), but still the size difference is big [12:31] maybe, we should diff the manifest between A1 and now? (if it's possible) to see if new packages were taken to main unexpectadely? [12:31] that's what I'm currently doing [12:31] I already compared the .list files for alternates [12:31] looking at .manifest diff for desktops now [12:32] but it's by and large the same set of changes [12:32] something just got radically bigger [12:41] hum :/ [12:42] pitti: we don't have a manifest-like file with package size I guess, isn't? [12:42] I'm currently investigating this [12:42] would be a nice addition :) === thekorn_ is now known as thekorn === macslow|lunch is now known as macslow [13:15] didrocks: wrote a script now -- http://pastebin.com/Jzt2EgDq [13:17] it's by and large build-essential and some drivers which we put into ship oops, and now with correct total added size: http://pastebin.com/3MU8aQm6 [13:18] pitti: much more sofisticated than the one I wrote some month ago (but lost in /tmp I think) [13:18] so this does confirm the 6 MB of added packages [13:18] pitti: I don't get why "Added packages" make that difference [13:18] didrocks: mostly new kernel [13:18] it's not clever enough to consider old/new kernel ABI as "changed" [13:18] pitti: if I try to add them manually, the size is approx 52-53 mB [13:18] MB [13:18] right [13:18] didrocks: it says 52.7 [13:19] TOTAL: +97.3 MB [13:19] gnome-icon-theme (Δ 5.2 MB - 2.28.0-1ubuntu1: 3.6 MB 2.30.3-1ubuntu1: 8.8 MB) [13:19] didrocks: use the second one; as I said, the first one had a bug [13:19] so it seems gnome-icon-theme is responsible for almost half of the growth in changed packages [13:20] oh ok, sorry, miss that [13:20] yeah, that sounds good so [13:20] so, gnome-icon-theme, samba/smbclient, and ghostscript [13:20] seb128, didrocks: can I delegate investigations of those to you? ^ [13:21] pitti, there is not much to investigate but I can check on g-i-t [13:21] I didn't think we should ship samba in the first place.. [13:21] seb128: that'd be great, merci [13:21] you're welcome [13:21] right samba seems to be an error [13:23] ship: * samba [amd64 i386] # for Windows filesharing and integration [13:23] hum [13:23] let's drop that [13:23] this will already buy back 7.5 MB [13:23] I'm puzzled [13:24] I know we changed nautilus-share to install samba when trying to share something [13:24] seb128: sure? [13:24] but samba seems to be there for ages [13:24] I mean, "yes we did, but how is that related"? [13:24] it's in ship, not installed by default [13:24] oh right [13:24] hmm [13:24] I'm getting confused [13:24] so why is it on the CD? [13:24] seb128: I only see it in netbook/ship, though, not in ubuntu [13:25] it shouldn't be on the alternates [13:26] but it is on lucid as well, hmm [13:26] seb128: oh, sorry, misread [13:26] of course it is in ship [13:27] bah [13:27] dropped [13:27] in netbook and buuntu [13:27] g-i-t we need somebody to work with upstream on that [13:27] there is nothing obviously wrong [13:27] seb128: icon number explosion? [13:27] out of trash.svg taking 1.9meg zipped [13:28] -EPARSE? [13:28] or some other [13:28] pitti, they have some svg icons taking 1, 2 or 3 meg each [13:28] urgh [13:28] those will take years to render [13:28] they went through a redesign of most their icons previous cycle [13:29] so they is no "drop that buggy file from the installed list" hack to do [13:30] somebody who knows about icon should work with them to get reasonable icons [13:30] vish, ^ [13:30] and it seems libanthy0 grew a new depends to anthy-common, which might be better suited as language-selector auto-install [13:30] heh, teach the unwashed upstream artists real icons [13:30] seb128: and we are probably shipping replacements for all of those anyway in our own theme? [13:31] good luck with that [13:33] pitti, I guess for most yes, but not everything [13:33] * pitti looks at ghostscript; 0.8 to 2.8 MB seems quite ridiculous [13:34] pitti, in fact those svg are sources, they built variants from it at runtime [13:34] so it's not trivial "fix some icons" [13:34] seb128: right, I'm saying perhaps we could get away with dropping the biggest 5 if we have replacements for them [13:34] it's just the number of icons with their quality leading to it [13:38] pitti: hmm , why are we shipping the svg? [they are just one canvas files , not needed for install] [13:39] actually , 2.30 has reduced the number of icons . :s [13:39] seb128: ^ [13:39] vish, we are not in fact I was starting from the source [13:39] cf what said before reconnecting [13:40] thats odd , the stock icons are now not being shipped with g-i-t , so that reduces a huge number of icons [13:41] vish, well the new gnome-icon-theme ships 6.5meg of 256x256 variants [13:41] where the old one didn't [13:42] the 256 px is just a replacement for the scalable 48 svg icons [13:44] let me investigate [13:49] vish, well the scalable dir was made of svg and 9meg ziped to 1.5meg [13:49] vish, the 256x256 dir is made of png files and 6.5meg zip to 6meg now [13:50] pitti, ^ [13:50] seb128, see your email for a message I sent you :-\ [13:50] hmm , yeah , i was just looking at that.. :s [13:50] ccheney, did I send an email? [13:50] ccheney, oh, sorry, misread, checking emails [13:50] seb128, ok [13:50] ccheney, ok, take care [13:50] seb128, thanks, hope to see you tomorrow :) [13:51] right [13:51] 2.28 is 3.6M download but a 20M install , while 2.30 is a ~13M install and a 8.4M download [13:52] not sure what can be done there.. [13:53] session restart brb [13:56] re [13:56] vish, pitti: right, I don't see any obvious change to win back space there in gnome-icon-theme [14:33] seb128: except dropping icons which we duplicate in our own theme, I figure? [14:35] pitti, right, but it's like 35k each icon, it feels like a lot of reviewing to break non default ubuntu themes [14:36] seb128: right, I just thought there were some really big ones [14:36] 3 to 8 MB does seem a little fat [14:36] in fact the one I spotted before are in the source and used to build other variants at build time [14:37] pitti, read backlog, the changed the scalable svg set which was taking 9meg but compressing to 1.5meg to a 6.5meg png dir [14:37] pitti, which compress to 6meg now [14:37] "the changed" -> "they changed" [14:37] seb128: what I don't understand is why it doesn't just ship the svgs as they are? [14:38] vish, ^ [14:38] pre-producing all those, where we would not ever use 95% of those seems like a waste to me? [14:39] pitti: the svg earlier were just single 48px icons , now the svg are what is called a one canvas svg , where the svg has icons from all sizes 16-256 [14:39] hence much larger and those svg cant be used [14:40] I thought the point of SVGs was to be vector graphics and thus you can scale them to whatever you want? [14:40] you certainly need some alternatives for the smaller sizes [14:42] vish, we are talking about the 256x256 icons shipped now where there was scalable svg ones before [14:42] vish, not about the source svg canvas [14:42] vish, why replacing the scalable svg by those? [14:42] seb128: pitti: the problem was they different styles used , the libsvg couldnt render svg properly. so they are shipping the 256 as png. [14:42] and they wanted to use one canvas , where all icons are in one file [14:42] but we hardly ever use those [14:42] 256x256, I mean [14:42] yup [14:43] and they seem to take the most space [14:43] the 256px icons wont be used anywhere as far as i can tell , those icons will probably be used at sizes 128px max [14:43] so why is there 6.5meg of those installed? [14:43] can we just drop this directory? [14:44] so we could perhaps drop all the 256 ones [14:44] you could, do that , only people will complain they dont have scalable icons [14:44] we did not ship anything larger than 32x32 in lucid [14:44] 48px was the max [14:45] and there was the scalable folder with 48px svg too [14:47] pitti: seb128 : maybe we can drop a few folders? [14:47] like the /status [14:47] or just all sizes > 64? [14:47] emotes [14:47] I don't feel qualified to decide on this [14:48] if those are there somebody somewhere decided they were bringing something I guess [14:48] it just seems like spending an awful lot of disk space for a diminishing return [14:48] people who like to scale their desktop icons to half the screen size or so [14:48] well I can see use for > 48x48 icons in normal use [14:49] ie compiz alt-tab switchers or similars [14:49] not sure what gnome-do etc do there [14:49] but that's why we have SVG [14:49] pitti: seb128: what can be alternately done is we can copy files from g-i-t to humanity[those which are missing] and drop g-i-t ;) [14:49] we don't have the scalables in that version [14:49] (also, we don't need all icons for those, just the app ones) [14:49] vish: that sounds like some effort as well, though? [14:49] pitti, there is no scalable dir in the new g-i-t [14:50] seb128: right, and that's what I don't understand [14:50] pitti: yeah .. [14:50] it's like a major step backwards [14:50] seb128: pitti: 256 is the new scalable folder [14:50] but it's made of png not svg [14:50] previously the icons would be scaled upwards , now they are scaled down [14:50] I though svg was scalable but I didn't know png was [14:51] vish: I thought previously it would just render the svg at the requested size? [14:51] seb128: well, any bitmap scales, just not very well :) [14:51] why is scaling down a png better than scaling a svg? [14:51] ^ in particular because the pngs were produced from those very SVGs [14:52] scaling is not the issue , the style that is used for the new icons is the problem , those svg dont get rendered properly during runtime [14:53] hence they are rendered as 256px png instead of 256px svg [14:53] buggy librsvg ;p [14:54] but how do they render correctly at build time then? [14:54] they don't "render" I guess [14:55] pitti: the new svg use a lot of blur and extra bling , that doesnt come out will with the librsvg.. for example take the places source svg , it will be rendered crappy [14:55] s/will/well [14:55] seb128: I thought they are produced from the svgs? [14:56] if you try to view any of the source svg in EOG , you will notice the problems [14:57] they are rendered with inkscape [14:57] pitti, hum, right, what vish and mclasen said [14:58] seb128: so perhaps we could split out all the 128 and 256 sizes into an extra package for people who want it? [14:58] ex of problems: accessories-dictionary.svg , accessories-graphics.svg ,folders.svg [14:59] I've difficulties to judge the impact and use of scalable icons but I guess they are useful [15:03] icons? [15:03] kwwii: yup , the new g-i-t is using up a lot of space :) [15:04] kwwii, http://pastebin.ubuntu.com/456902/ [15:04] kwwii, basically the scalable svg dir which compress nicely has been tradded for a 256x256 png dir which doesn't [15:06] * vish wonders how mpt is omnipresent ;) [15:07] seb128: I agree with the idea that if we have 128x128 SVGs we don't need 256x256 [15:08] * kwwii reads up [15:09] ahhh, if they are all one canvas files we'll need to do a bit of work (every time) to split them out [15:10] kwwii: now everything is one canvas [15:10] if we remove 256x256 we definitely need something scalable to replace it [15:11] seb128: sounds to me like you cannot remove the 256 without doing magic to the SVGs to get the right one out [15:11] in the long run, living with the size would be much easier :p [15:12] kwwii: that's a rather cheap excuse, though [15:12] we have to drop something else to make up for those 5 MBs, after all [15:12] and I'm inclined to say that the advantage of this 150% space increase is not all that big [15:12] pitti: right, I understand the problem, but as I've said above, if we don't get a scalable icon large enough we cannot remove 256x256 of hand [15:13] kwwii: right, understood [15:13] kwwii: where are those actually used? [15:18] you can probably drop actions , emblems , emotes , status folders , and save 3.1M , but then again there would always be problems somewhere ;p [15:18] the 256px sizes [15:18] right, we wouldn't need them in those large sizes, just the app ones [15:19] well not sure, those are scalable ones [15:19] ie they go be used in ie 48x48 if there is no 48x48 variant [15:19] or 96x96 or whatever [15:19] fix rsvg? :) [15:20] dropping 3 MB would help a bit already [15:20] hey desrt [15:20] hi [15:20] desrt: ultimately this seems to be the right answer, yes [15:20] hey desrt [15:20] hi seb [15:21] pitti: anywhere, theoretically...usually ont the desktop and nautilus [15:21] s/ont/on [15:29] kwwii, will, in practice would anybody notice if we drop those? [15:29] we can try and see :) [15:29] seb128: depending on which icons, yes [15:29] but a 256x256 emblem or action will hardly be missed IMHO [15:29] vish had a good suggestion for which ones to drop [15:29] pitti: exactly [15:29] a picture of this size is hardly an "icon" any more in the first place [15:29] there are quite a few we can remove [15:29] I only know the Alt+Tab switcher as an example of using such large pics [15:30] pitti: for people with vision problems, etc I doubt that [15:30] or large screens with high dpi [15:30] * rickspencer3 time to set up the team meeting page [15:30] oops [15:30] rickspencer3, hey [15:30] rickspencer3, you are late for this ;-) [15:30] seb128, be careful, I may decide I need to delegate this! [15:30] hehe [15:31] * seb128 hides [15:31] jeez, not seeing the date in the clock applet is a serious pita [15:31] rickspencer3, you made chrisccoulson leave! [15:31] hehe [15:31] seb128: so, seems we have a plan here? [15:31] smart man [15:32] pitti, right, will do that change [15:32] * pitti hugs seb128 [15:32] didrocks, I see you got to the meeting wiki first! [15:32] thanks dude [15:32] * seb128 hugs pitti [15:32] rickspencer3: I wasn't the first to be honest ;) [15:32] but you're welcome anyway [15:32] ah [15:32] rickspencer3, pitti was [15:33] well, you all did it wrong, I have to start over now [15:33] j/k [15:33] :p [15:33] tkamppeter, hi! [15:37] rickspencer3, hi [15:40] didrocks, do you plan to update clutter to 1.2.8? [15:40] didrocks, g-s build-depends on it... [15:40] seb128: argh, so close from A2? can we do that on Friday? [15:41] didrocks, I didn't say "now", I was rather asking if we didn't update yet for a reason [15:42] seb128: well, most of the time, clutter update makes crying dx team. I was planning for jumping 1.3 next week when alf__'s branch will be fixed with egl backend === cyphermox_ is now known as cyphermox [15:54] seb128: I'll have a look at the samba difference then [15:54] pitti, thanks [16:19] mvo, hi, it's been four months and we haven't heard anything from the Edubuntu folks about X-AppInstall-AlwaysOnTop [16:20] Shall we drop it, and invite them to ask us to design something better if they want it again later? [16:20] seb128: hm, both samba-common-bin and smbclient debdiffs are empty, the executables themselves just grew in the new version; I guess we have to live with that [16:20] mpt: downgrade to medium or even low [16:20] mpt: yes, thanks for following up on that [16:22] kenvandine_, hi! Just to let you know that Empathy 2.31.4 that I released today should have all the needed bits to turn the indicator applet to an Approver [16:23] seb128: who is assigned to do dailies for shell? and what milestone are you thinking about doing that? [16:24] cassidy, he's on holidays this week [16:24] jcastro, I've the work item and alpha3 [16:24] seb128, ah ok. I'll ping him next week then [16:25] cassidy, but thanks, once we get d-conf and tp-logger tested and in main I guess we will update [16:25] cool [16:25] seb128, we are the first main package who switched to d-conf? [16:27] cassidy, yes [16:27] cassidy, or maybe gnome-games did, but I doubt many users care about settings there [16:31] vish, kwwii: do we need scalable categories icons? [16:33] seb128: its sometimes used in the -shell or in certain control-center-like apps [tweak ui?] or something.. safer to leave it in [16:33] ok [16:50] seb128, chrisccoulson can you guys provide some information about where the FF update stands at the team meeting today? [16:50] rickspencer3, sure [16:50] thanks chrisccoulson [16:51] thanks chrisccoulson [16:52] i think i'm beginning to dislike epiphany ;) [16:54] lol [16:54] chrisccoulson: what an epiphany :) [16:54] * micahg hides [16:54] heh ;) [16:58] what is the maximum number of characters i can put in to the IRC channel at any one time (without my sentences being truncated)? [16:58] i'm just preparing some meeting notes [17:02] chrisccoulson: dunno, I usually try to 80 chars line wrapping [17:03] it over some hundred chars though [17:03] seb128 - thanks [17:15] chrisccoulson you can always remove all doubt by using pastebin [17:15] rickspencer3, i might do that, as I'll probably end up flooding the channgel ;) [17:15] s/channgel/channel/ [17:15] if you do that, seb will have to kick you [17:15] lol === macslow is now known as MacSlow|afk [17:16] ;-) [17:30] ArneGoetje, chrisccoulson, chrisccoulson_, didrocks, Riddell, tkamppeter, tremolux, everybody team meeting in 1 minute? [17:30] you bet [17:30] o/ [17:31] o/ [17:31] https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-06-29 [17:31] hey [17:31] alright, I'm going to kick it off, then seb128 is going to drive the rest of the agenda while I lurk [17:32] so, first, there are no open issues from last week [17:32] yeah! [17:32] ;-) [17:32] oops [17:32] * rickspencer3 adds mozilla update to agenda [17:33] alright, so next was ... [17:33] rickspencer3 availability [17:33] just an fyi ... [17:33] I'll be traveling this Thursday and Friday, so pretty much unreachable until Friday afternoon Eurotime [17:34] but I will be slammed with day 1 jet lag :/ [17:34] safe travels! [17:34] following 2 weeks, I will be based in Holland [17:34] so some time shifting in terms of when we can talk, etc... [17:34] (thanks pitti) [17:34] then I'll see you all in Prague!!! === cking is now known as cking-afk [17:35] in the meantime, please please please, feel free to ping me or reach out whenever you need anything [17:35] ok ... [17:35] seb128, can you rock the agenda from here? [17:36] yes [17:36] :) [17:36] hey everybody [17:36] ok, so kenvandine_ is on holidays [17:37] so I guess that means no partner update this week [17:37] I can tell you that appmenu landed in UNE on time for a2 [17:37] the new version has some crash issue though being investigated right now [17:38] so let's move on to next updates [17:38] Riddell, kubuntu update? [17:38] hi [17:39] hey tkamppeter [17:39] oh, seems no kubuntu update... [17:39] didrocks, UNE update? ;-) [17:39] yeah [17:39] so, UNE got places [17:40] \o/ [17:40] you can enjoy files and applications place now on UNE to browse recent files and be able to launch applications [17:40] coolness! [17:40] that means the infamous nautilus /usr/share/applications launcher has been moved [17:40] all is seeded by default in UNE (as well as the appmenu bar) [17:40] so please, feel free to test A2 image [17:41] nothing special in addition to that, zeitgeist is used as a backend for people not knowing it [17:41] I think that's for my part [17:42] (no no, really, nothing more :-)) [17:42] thanks didrocks [17:42] great work to you and to the unity team [17:43] I've been told Riddell is ready now ;-) [17:43] Riddell, hey [17:43] hi [17:43] Riddell, kubuntu update? ;-) [17:43] - new kubuntu council voted in, me, ScottK, neversfelde [17:43] - KDE SC 4.5 RC uploaded and compiled (except on arm, still going there) [17:43] - alpha 2 testing about to begin [17:43] - me and agateau and ncommander are at akademy next week [17:43] oh and 4.4.5 is about to be released by upstream, kubuntu ninjas have it ready in a PPA [17:43] nice [17:44] thanks for contributing to hijack the buildds after the firefox security builds yesterday :p [17:44] and enjoy akademy [17:44] where is it this year? [17:44] Finland, 'the country where I want to be' === cking-afk is now known as cking [17:45] lol [17:45] Riddell, thanks ;-) [17:45] 24 hours of sunlight, no sleep for the whole week [17:45] sounds like fun indeed! [17:45] ok, moving on [17:45] tremolux, hi [17:45] hi :) [17:45] tremolux, software-center update? ;-) [17:46] yep [17:46] Buy Something: Excellent progress this week by mvo and Michael Nelson on Software Center Agent API and implementation [17:46] Software Center Agent stub implementation is done, mvo is using it for development [17:46] mvo has branches in-progress for ubuntu-sso login and a webkit implementation begun for "I want to buy X" [17:46] UI Enhancements: Single-pane department screen done, alpha-2 targeted items complete [17:46] New Apps: RT ticket filed for new archive and sync, development continues using app-review-board PPA [17:46] (more) details on the wiki ;) [17:47] nice summary [17:47] I see a new s-c has been uploaded today I need to update and try that ;-) [17:47] yes, please! [17:47] I think it's got lots of good stuff, please try it if you can [17:47] tremolux, great work from you and mvo and others, keep rocking! [17:47] tremolux, thanks [17:47] seb128: thanks a lot :) [17:48] ok, that's not on the meeting agenda now, but... [17:48] chrisccoulson: hey ;-) [17:48] hi :) [17:48] chrisccoulson: ready to give an update on the firefox security update? [17:48] * mvo hugs tremolux [17:48] * tremolux hugs mvo [17:49] i am. there's quite a lot of text, so i put the notes on http://pastebin.ubuntu.com/456952/ for people to read [17:49] but, basically, we plan to do the hardy and lucid release today [17:49] oh, indeed [17:50] chrisccoulson: nice summary [17:51] what is "TCK" in that context exactly? [17:51] chrisccoulson: thanks for the heads-up, and wading through all of this [17:51] seb128: test suite [17:51] ok [17:51] yeah, the TCK is the java test suite [17:51] "test and certification kit" or so? [17:51] chrisccoulson: great work as pitti said [17:51] i'm told it takes a long time to run ;) [17:51] quite challenging to go through all those changes [17:51] pitti - yeah, something like that [17:52] so, hopefully it all goes smoothly :) [17:52] thanks chrisccoulson [17:52] let us know if you some help for remaining tasks or testing [17:52] thanks [17:52] out of interest, how much will we still need xulrunner in maverick? [17:52] ok, let's keep moving on [17:53] (in terms of yelp, epiphany, etc.) [17:53] in GNOME none I guess [17:53] (I'm asking because of UNE and chromium by default) [17:53] but desktopcouch needs it [17:53] but we know its upstream :) [17:53] or some part of it at least [17:53] pitti - for UNE, it's just yelp and desktop-couch [17:53] there is a work item in that spec to split xurlunner packaging [17:53] but desktop-couch only needs spidermonkey [17:53] is there no help for yelp/webkit? [17:53] s/help/hope/ [17:54] current yelp git uses webkit [17:54] pitti - yelp 3.0 will be webkit based, but will probably require gtk3 ;) [17:54] \o/ [17:54] I think we will switch to it this cycle [17:54] i've not kept up-to-date with that though [17:54] chrisccoulson: I think we will get some selected updates and get those to work on gtk2 [17:54] this one being on that list [17:54] ah, we won't ship gtk3 by default? [17:54] seb128 - yeah, we will need to get yelp done else chromium doesn't fit on the CD [17:55] (or i wouldn't expect it to fit) [17:55] ah, we have -20 MB left, no problem [17:55] pitti, no, we don't have gtk3 yet and we will need gtk3 variants for all gtk libraries, themes, etc [17:55] seb128: right, makes sense; thanks [17:55] dconf on the CD yet? [17:55] pitti, having 2 gtk stacks on the CD will be challenging [17:55] desrt, no [17:55] aw :( [17:56] desrt, it's getting tricky because we don't want gtk3 on the CD so we are not doing lot of GNOME updates [17:56] understood [17:56] ok, moving on [17:56] can't say i blame you [17:56] desrt, ;-) [17:57] desrt, we got empathy updated though so it will bring d-conf on the CD likely next week [17:57] scary. [17:57] desrt, it's one of those selected software we will make work on gtk2 for this cycle because we think it's worth the effort and upstream is wanting to make things easy if they can [17:57] ok, really move on [17:57] http://people.canonical.com/~pitti/workitems/maverick/canonical-desktop-team-maverick-alpha-2.html [17:57] we have alpha2 getting really close now [17:57] seems we are in shape [17:58] let's quickly review remaining work items and decide on what to do with those [17:58] ArneGoetje, hey [17:58] you still have 2 workitems on that list [17:58] ArneGoetje, do you think you will get them done in the next 2 days or should we move those to a3? [17:59] seb128: consider them moved to a3, they are not that important [17:59] ArneGoetje, can you update the spec and move them in the whiteboard? thanks [17:59] seb128: but I hope I will get them done sooner [17:59] ok [17:59] seb128: sure [17:59] well if they are not done by thursday please move those [18:00] they don't require any archive change so you still have some time before a2 [18:00] ArneGoetje, thanks [18:00] bryce_, hi, not sure if you are around? [18:00] I am [18:01] bryce_, you still have one a2 workitem, will you get to it? should it be moved to a3? [18:01] seb128, what is it? [18:01] bryce_, https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-video-bugs-in-the-kms-world [18:02] report for each driver [18:02] oh yeah, that can be bumped. it's sort of wishlist priority anyway [18:03] ok, should we move that to a3 then? [18:03] yeah [18:03] bryce_, moved to a3, thanks [18:03] didrocks, hey [18:03] didrocks, you still have 2 quickly workitems for a2 [18:04] yeah, the 2 quickly WI can be move for a3. I'm discussing with launchpad about how to avoid faking a browser [18:04] I guess you still have some day to get an upload in if you want since quickly is not on the default install [18:04] ok [18:04] but discussions… take time :) [18:04] didrocks, can you update the whiteboard to reflect that? [18:04] ok [18:04] seb128: sure [18:04] so that covers the wis for that meeting [18:05] next is http://people.canonical.com/~pitti/workitems/maverick/canonical-desktop-team-maverick-alpha-3.html [18:05] we did settle on targetting around the same number of workitems we get done this iteration [18:06] which should be around 79-80 right now [18:06] please try to make sure your workitems are in shape before alpha2 is released [18:06] since the alpha3 trend will start after alpha2 [18:06] try targetting around the same number of items you got done this iteration [18:06] with maybe some modulation depending of how much side work you had or think you will have [18:07] ie chrisccoulson was busy full time with firefox but will probably be able to get some work items done for the next iteration [18:07] yeah, i can't wait to actually start working on maverick ;) [18:07] if you have workload issues or questions feel free to ping me or rick [18:08] seems right now we are a bit over the count we should have [18:08] though chrisccoulson count as an extra member compared to a2 [18:09] so maybe let's try to drop some items so we are on shape and have a list of things we can deliver for a3 [18:09] [18:09] I think that's it from me [18:09] any comment, update? [18:09] question? [18:09] nothing for me :) [18:10] ok, seems not [18:10] oh, hang on [18:10] or yes [18:10] do we have major new features which we should mention in the tech notes for a2? [18:10] hum,unity? [18:10] appmenu [18:10] https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview [18:11] right, those two deserve a paragraph at least [18:11] "The GNOME base platform has been updated to the current 2.31 versions." [18:11] no it hasn't ;-) [18:11] oh, platform [18:11] ignore me [18:11] but yeah, we should get things on that [18:12] tremolux, mvo: maybe you guys could put some of the s-c changes there is there is anything you think are worth mentioning? [18:12] like the history log of installed packages (I like it) ;-) [18:12] didrocks, can you get UNE changes there? unity and appmenu at least? [18:13] seb128: sure, we already have this kind of modification somewhere, maybe just copy and paste will do it [18:13] seb128: I'll do it [18:13] didrocks, thanks [18:13] ok [18:13] seb128: hmm, let me think about it and also see what mvo thinks; I think the big changes are still in-progress and are not available as yet [18:13] much appreciated [18:13] Colin and I can clean up the language etc., but getting the facts there would be great [18:14] pitti, thanks for raising that topic ;-) [18:14] anything else? [18:14] seb128: oh yes, the history log is a good one :) [18:15] tremolux, ;-) [18:15] ok, seems we are done, let's wrap up [18:15] thanks everybody [18:15] thanks [18:15] thanks all [18:15] thanks everybody, good day all [18:16] thanks everyone [18:20] thanks everyone [18:20] thanks to pitti for coming back to help us release A2!!! === asac__ is now known as asac === MacSlow|afk is now known as MacSlow === bjf is now known as bjf[afk] [18:48] oi oi [18:49] chrisccoulson seb128, jono was suggesting that perhaps a quick update to @u-devel regarding firefox update might be appreciated by the community [18:49] thoughts? [18:50] too busy shipping I guess [18:50] rickspencer3, yeah, possibly. [18:51] although, the update will be announced in the usual manner for security updates [18:51] jdstrand is already working on publishing hardy [18:51] chrisccoulson, seb128 just a thought, I leave the decision in your hands [18:52] thanks jono [18:52] * rickspencer3 lunch -> break time [18:52] bbiab [18:52] is there a procedure in place for community members to escalate any issues from the update? [18:52] (not that i'm expecting there to be any) [18:52] chrisccoulson filing bugs? [18:52] np :) [18:53] I would suggest that you prepare to watch the bug tracker quite closely starting when the release goes out [18:53] rickspencer3, i was thinking more along the lines of "if there is a serious regression and i'm asleep", or something like that ;) [18:53] perhaps we can hand off to someone like robert_ancell [18:53] chrisccoulson ah [18:53] although i'm sure that situation won't arise ;) [18:53] * rickspencer3 looks for link [18:53] chrisccoulson: expect the unexpected :) [18:53] chrisccoulson; I can watch for stuff tonight :) [18:54] and releasing with a few days to the weekend makes it quite likely that i'll be able to catch issues anyway [18:54] micahg - cool [18:54] chrisccoulson https://wiki.canonical.com/HumanResources/Misc/DealingWithCrisis?action=show&redirect=DealingWithCrisis [18:54] do you have my cell-phone number? (just in case anything bad happens) [18:57] so, pie in the sky, dreamy stuff [18:57] ... [18:57] I wish we have the chromium system where only a few of the users got the initial update [18:57] and then a few more, etc... [18:58] so that if there are problems with an update, they are not so widespread [18:59] yeah, it would be nice to have that [18:59] okay, really stepping away this time [19:00] although, staging the updates should already be able to give that (on an opt-in basis) [19:00] we just don't get enough people opting in ;) === bjf[afk] is now known as bjf [19:14] https://edge.launchpad.net/ubuntu/+source/firefox-3.0/3.6.6+nobinonly-0ubuntu0.8.04.1 [19:14] \o/ [19:16] hey, what's the best way to use gtk from the git repositories under ubuntu? [19:17] chrisccoulson: congrats! [19:17] aganice: most would say jhbuild [19:17] i'm having dh_movelist trouble when i try to debuild glib: http://pastebin.com/7xNdhjGf [19:17] thanks [19:20] aganice: if you don't want to go through the jhbuild motions it's also reasonably easy to accomplish what you are trying to do by hand [19:20] since i think probably you just want to install glib and gtk, right? [19:21] desrt, so far, but jhbuild seems like a reasonable way to go about it since i'll likely need more. [19:22] desrt, is make/make install an appropriate way to go under a debian-based system? is that what you mean by "by hand"? [19:22] aganice: it's not exactly that simple... [19:22] awe: hi , for Bug #383404 , there is a small patch which fixes the problem , could you check it out? [19:22] Launchpad bug 383404 in notify-osd (Ubuntu) (and 3 other projects) "networkmanager passive notification wording needs to be changed (affects: 7) (dups: 1) (heat: 46)" [Undecided,Invalid] https://launchpad.net/bugs/383404 [19:22] the first thing you need to consider is where you want to install it [19:23] a standard 'configure/make/make install' will put it in /usr/local which means that your possibly-hacked-up version of gtk will be what your system uses [19:23] so if you mess something up, your entire system is more or less bricked [19:23] for this reason people tend to put it somewhere else like in /opt or just under your home directory... [19:24] i use /home/desrt/local for example [19:24] * mclasen always installs to /usr ... [19:24] mclasen is hardcore :) [19:25] mclasen, i imagine i'm more likely to break everything with my changes than you are :p [19:26] aganice: the disadvantage of putting it somewhere other than /usr or /usr/local is that there are about half a dozen environment variables that you need to setup in order for stuff to be able to 'find' the new versions you installed [19:26] but i'm working on backed up vms to limit cross-contamination of hacks [19:26] oh. nice. [19:26] /usr/local may be the easiest thing for you, then [19:26] yup [19:26] ya. so just checkout glib [19:27] ./autogen.sh make make install [19:27] then do the same for gtk [19:27] then you're good to go [19:27] excellent, thanks [19:28] it may be a good idea to 'sudo apt-get build-dep gtk+2.0' [19:28] since probably your system misses some of the other libraries you need [19:28] and on top of that you may find that you need automake, gtk-doc-tools, libtool, etc [19:28] should be reasonably easy to figure out, though [19:29] mclasen: gtk+ doesn't currnetly have any bleeding-edge dependencies except glib, right? [19:30] after amateur tries to update MLT to 0.5.6 i have left without ffmpeg modules and even ffpmeg is installed, kdenlive says that some not installed at all. also it says that some sound module is not installed. i spent all day to make "lines and dots" bug dissappear (white lines and dots - was promised to be fixed in MLT 0.5.5) and i couldn't make it, even worse - now modules "avformat module", "Quimage module", "Title module" are missing and reinstalli [19:30] it just grew a cairo 1.9.10 dep [19:30] ng of the program and ffmpeg does not helping. [19:30] help me please to make this thing work correctly. my skype is "woanerges", or write me here. please, bro's, come on, i need some support here! [19:30] white dots and lines examples: [19:30] http://kdenlive.org/sites/default/files/shot1_0.png [19:30] http://www.youtube.com/watch?v=nrFXr_bx2a0 [19:43] desrt, mclasen: got those, thank you very much for the help! [19:43] no prob [19:54] Z-RAY_: why are you spamming all channels? [19:56] hggdh: Z-RAY_ has been set to -q so he cant reply :D [19:56] oh, good, thanks vish [19:56] or is that +q .. === ayan_ is now known as ayan [20:11] does anyone know if lp bug 548652 is still a problem? [20:11] Launchpad bug 548652 in fedora (and 3 other projects) "menu mouse-scrolling broken, when themes enable gtk-auto-mnemonics (affects: 36) (dups: 8) (heat: 219)" [Unknown,Unknown] https://launchpad.net/bugs/548652 [20:11] i can't reproduce it. === zyga_ is now known as zyga [23:32] Good morning. [23:40] hi TheMuso :) [23:53] /c/c