[00:56] <doko> vorlon: already building
[00:57] -queuebot:#ubuntu-release- New: accepted ghmm [amd64] (noble-proposed) [0.9~rc3-5.1ubuntu3]
[00:57] -queuebot:#ubuntu-release- New: accepted ghmm [armhf] (noble-proposed) [0.9~rc3-5.1ubuntu3]
[00:57] -queuebot:#ubuntu-release- New: accepted ghmm [riscv64] (noble-proposed) [0.9~rc3-5.1ubuntu3]
[00:57] -queuebot:#ubuntu-release- New: accepted ghmm [arm64] (noble-proposed) [0.9~rc3-5.1ubuntu3]
[00:57] -queuebot:#ubuntu-release- New: accepted ghmm [s390x] (noble-proposed) [0.9~rc3-5.1ubuntu3]
[00:57] -queuebot:#ubuntu-release- New: accepted ghmm [ppc64el] (noble-proposed) [0.9~rc3-5.1ubuntu3]
[00:58] <doko> also started a local build, dh_makeshlibs exits after the first error ...
[01:13] <vorlon> doko: comparing your debdiff to mine I expect a build failure, and also it's not clear to me the symbols you've marked as optional should be optional as opposed to arch-specific.  I'm going to go ahead and upload my version
[01:21] <doko> vorlon: these are all template instantiations ...
[01:31] <vorlon> doko: 'sandbox::localtime_override(long const*)@Base' <- this is not a template
[01:31] <vorlon> maybe it shouldn't be exported, but it's not a template
[01:31] <vorlon> anyway the missing symbol was definitely part of the ABI
[01:31] <vorlon> QtWebEngineCore::ProfileAdapter::determineDownloadPath(QString const&, QString const&, long const&)@Base
[01:32] <doko> which already is marked as optional
[02:21] -queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [amd64] (noble-proposed/universe) [1:24.04.19] (lubuntu, ubuntustudio)
[12:09] <jbicha> mwhudson: We suspect that new vala will fix ftbfs for evolution-data-server, folks & telepathy-glib. Will sync from Unstable later today
[13:19] <LocutusOfBorg> vorlon, libfm/menu-cache are chickening and egging
[13:20] <LocutusOfBorg> but libfm can be built without menu-cache with stage1 profile
[13:21] <LocutusOfBorg> (appstream-glib/boinc are fixed)
[14:55] -queuebot:#ubuntu-release- New binary: kronosnet [amd64] (noble-proposed/main) [1.28-2ubuntu1] (i386-whitelist, ubuntu-server)
[14:55] -queuebot:#ubuntu-release- New binary: kronosnet [i386] (noble-proposed/main) [1.28-2ubuntu1] (i386-whitelist, ubuntu-server)
[14:56] -queuebot:#ubuntu-release- New binary: kronosnet [s390x] (noble-proposed/main) [1.28-2ubuntu1] (i386-whitelist, ubuntu-server)
[14:57] -queuebot:#ubuntu-release- New binary: kronosnet [ppc64el] (noble-proposed/main) [1.28-2ubuntu1] (i386-whitelist, ubuntu-server)
[14:58] -queuebot:#ubuntu-release- New binary: kronosnet [armhf] (noble-proposed/main) [1.28-2ubuntu1] (i386-whitelist, ubuntu-server)
[15:00] -queuebot:#ubuntu-release- New source: dfx-mgr (noble-proposed/primary) [2023.2-0ubuntu1]
[15:00] -queuebot:#ubuntu-release- New binary: kronosnet [arm64] (noble-proposed/main) [1.28-2ubuntu1] (i386-whitelist, ubuntu-server)
[15:18] -queuebot:#ubuntu-release- New binary: kronosnet [riscv64] (noble-proposed/main) [1.28-2ubuntu1] (i386-whitelist, ubuntu-server)
[15:54] -queuebot:#ubuntu-release- Unapproved: software-properties (xenial-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (desktop-core, ubuntu-server)
[15:57] <jbicha> dpkg was merged over the weekend to include Debian's -Werror=implicit-function-declaration . Do we want to revert that at this point for noble?
[15:59] <jbicha> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
[16:15] <juliank> jbicha: I think this is a very important feature and I'm surprised this was not on by default in Ubuntu, it seems important to ensuring correctness of the t64 transiton
[16:27] <jbicha> it's just going to trigger lots of ftbfs that aren't directly related too
[16:31] <Eickmeyer> ubuntu-release: VERTY LOUD PING w.r.t. bug 2058161: Ubuntu MATE is requesting help moving to ubuntu-desktop-provision for their new installer and has requested my help. Need an FFe ack ASAP so I can get started on the work! ******
[16:31] -ubottu:#ubuntu-release- Bug 2058161 in ubuntu-mate-meta (Ubuntu) "FFe: Switch installer to ubuntu-desktop-provision" [Critical, New] https://launchpad.net/bugs/2058161
[16:47] <seb128> juliank, as an example (which I guess triggered the question from Jeremy), gnome-control-center started to fail to build in noble
[16:47] <seb128> https://launchpad.net/ubuntu/+source/gnome-control-center/1:46.0-0ubuntu1/+build/27938036
[16:48] <juliank> Yes that's an unrelated build failure because it happens to not return time_t, but if it did return time_t you'd have silently broken gnome-control-center on armhf
[16:49] <seb128> juliank, unrelated to?
[16:49] <juliank> unrelated to t64
[16:49] <juliank> sorry
[16:49] <juliank> the flag was added in Debian to ensure that t64 is reasonably safe
[16:50] <juliank> imagine if it was cc_common_get_time()  or something returning a time_t
[16:50] <seb128> right, Jeremy wasn't asking about t64 though but about that flag being default now on other archs
[16:50] <vorlon> LocutusOfBorg: the stage1 changes to debian/control in libfm are a bit eyebrow-raising, but let's see
[16:50] <seb128> juliank, whatever the rational is, that's an
[16:51] <seb128> that's a
[16:51] <juliank> seb128: But arguably it makes no sense to only enable that on armhf
[16:51] <seb128> - change which has an impact on buildability of other packages
[16:51] <seb128> - landed post feature freeze and doesn't seem to have related Ffe attached
[16:51] <vorlon> juliank, jbicha: enabling it on armhf means there will be build failures on armhf, possibly of packages we can afford to jettison the armhf binaries of.  enabling it on all archs means build failures on all archs
[16:51] <seb128> - hasn't been announced
[16:53] <seb128> it doesn't seem unreasonable to question whether that change is right, if it is wanted it feel like it should have been at least announced and that we might need another archive test rebuild to see the impact? (or did we just get unluck that one of the first desktop package to get uploaded fails to build due to it?)
[16:53] <vorlon> I am going to be posting to ubuntu-devel-announce today about chucking armhf binaries out
[16:54] <vorlon> we simply do not have time/capacity to fix all of these
[16:54] <vorlon> and as a corollary, I think it does make sense to not error on implicit declarations on the 64-bit archs
[16:55] <vorlon> seb128: the reason for the change to dpkg in Debian is that it's a surprise to maintainers when their packages which don't use time_t now ftbfs on 32-bit archs ony
[16:55] <vorlon> only
[16:56] <vorlon> but I think the calculus in Ubuntu now is different given the release deadline
[16:56] <juliank> +1
[16:56] <vorlon> LocutusOfBorg, doko: ^^ you probably want to be aware of this discussion
[16:56] <seb128> vorlon, I understand the rational, it's still the kind of change I would expect to require a ffe to land at this stage of this cycle
[16:56] <seb128> or at minimal to be announce on the devel list
[16:57] <vorlon> LocutusOfBorg: ok well the trivial stage1ification of libfm ftbfs? https://launchpad.net/~canonical-foundations/+archive/ubuntu/archive-bootstrap/+build/27938214
[16:57] <seb128> but yeah, if it's armhf only and we decide to start removing binaries when needed on that arch that lowers the impact...
[16:57] <seb128> ups
[16:58] <vorlon> seb128: we should consider -Werror=no-implicit-function-declarations required for armhf; without it you get misbuilds when using time_t-sensitive glibc functions
[16:58] <vorlon> and on armhf it didn't land post-FF
[16:58] <vorlon> (it landed as part of the time_t change)
[16:59] <seb128> ack, I still wonder how many packages it's going to impact... we didn't get a test rebuild with that flag before the transition did we?
[17:02] <vorlon> we did not
[17:02] -queuebot:#ubuntu-release- New binary: halide [amd64] (noble-proposed/universe) [17.0.1-1] (no packageset)
[17:03] -queuebot:#ubuntu-release- New: accepted halide [amd64] (noble-proposed) [17.0.1-1]
[17:04] <juliank> just remove the entire desktop on armhf, problem solved :)
[17:07] <vorlon> that's not necessarily the wrong answer. But the line between "desktop" and "not desktop" is blurry, and we have to start at the edges of the graph and be pragmatic
[17:08] <vorlon> the largest complaints will probably be from raspi users who want to be able to upgrade even if it's unsupported, but yo, you don't even have a kernel, what are you doing
[17:09] <vorlon> ok how did this build locally, I definitely don't have distutils installed in my test build env :| https://launchpad.net/ubuntu/+source/mongo-cxx-driver-legacy/1.1.3-3.3ubuntu1/+build/27938257
[17:18] <LocutusOfBorg> thanks vorlon for highlighting
[17:18] <LocutusOfBorg> of course we can revert dpkg change, or reduce to armhf only
[17:18] <LocutusOfBorg> indeed we discussed this, but not *that* deep when we agreeded to merge dpkg
[17:19] <jbicha> bdmurray: GNOME is preparing their 47 schedule. Any chance we can get a draft 24.10 schedule to compare?
[17:20] <LocutusOfBorg> seb128, the discussion was somewhere above, like 5 days ago, but turned out the merge was a little bit more trickier due to MoM failing to do some proper job in keeping the delta from proposed pocket (and my simplification of delta in newer release)
[17:27] <LocutusOfBorg> vorlon, maybe the gtk-doc-tools shouldn't be !stage1?
[17:32] <LocutusOfBorg> yeah adding it works
[17:32] <LocutusOfBorg> sadly I can't upload on that ppa :/
[17:33] -queuebot:#ubuntu-release- Unapproved: initramfs-tools (jammy-proposed/main) [0.140ubuntu13.4 => 0.140ubuntu13.5] (core, i386-whitelist)
[17:37] <Eickmeyer> ubuntu-release: VERTY LOUD PING w.r.t. bug 2058161: Ubuntu MATE is requesting help moving to ubuntu-desktop-provision for their new installer and has requested my help. Need an FFe ack ASAP so I can get started on the work! ******
[17:37] -ubottu:#ubuntu-release- Bug 2058161 in ubuntu-mate-meta (Ubuntu) "FFe: Switch installer to ubuntu-desktop-provision" [Critical, New] https://launchpad.net/bugs/2058161
[17:44] <juliank> this change makes britney use all-proposed for noble armhf until beta: https://code.launchpad.net/~juliank/britney/+git/britney2-ubuntu/+merge/462607
[17:44] <juliank> the similar patch has just landed in autopkgtest-cloud's request.cgi for requesting retries - they will get all-proposed=1 set automatically even if not specified
[17:44] <juliank> (on armhf noble)
[17:44] <juliank> I expect this to land shortly and then things will improve a bit in terms of not getting wrong stuff scheduled :)
[17:51] -queuebot:#ubuntu-release- New source: involflt (noble-proposed/primary) [0.1.0-0ubuntu6]
[17:52] <LocutusOfBorg> release team please NBS-cleanup libnode108t64 (all archs)
[18:28] <juliank> the britney change has been merged now, all future uploads and retries will use all-proposed on noble armhf.
[18:28] <juliank> all-proposed will stop being enabled on beta day
[18:30] <Eickmeyer> ubuntu-release: VERTY LOUD PING w.r.t. bug 2058161: Ubuntu MATE is requesting help moving to ubuntu-desktop-provision for their new installer and has requested my help. Need an FFe ack ASAP so I can get started on the work! ******
[18:30] -ubottu:#ubuntu-release- Bug 2058161 in ubuntu-mate-meta (Ubuntu) "FFe: Switch installer to ubuntu-desktop-provision" [Critical, New] https://launchpad.net/bugs/2058161
[18:37] <vorlon> LocutusOfBorg: gtk-doc-tools> thanks, I've added that back in
[18:41] <vorlon> LocutusOfBorg: ftr NBS cleanup requires archive admins rather than the release team. Anyway, doing a round of -proposed NBS cleanup now
[18:43] <vorlon> LocutusOfBorg: libfm built, I'll copy menu-cache over to that ppa in a bit to finish the bootstrap
[18:52] <Eickmeyer> vorlon: Thanks for the FFe. This is my priority over the next couple of days, expect an urgent MP for livecd-rootfs.
[19:21] <seb128> LocutusOfBorg, backlog of this channel isn't a proper way to communicate late changes to the members of the projects...
[19:22] <seb128> LocutusOfBorg, my point is that if you change a default compiler flag in dpkg at the end of the cycle there should at minimal go with a FYI email to -devel and/or equivalent post to discourse
[19:56] <Eickmeyer> vorlon: This was easy to layer; they already had a minimal seed. https://code.launchpad.net/~eeickmeyer/livecd-rootfs/+git/livecd-rootfs/+merge/462626
[19:57] <vorlon> Eickmeyer: I have an itch that I want to refactor the livecd-rootfs code for all of the ubuntu-desktop-installer flavors to reduce the code duplication; would you like me to land that before or after your change?
[19:58] <Eickmeyer> vorlon: Can we do after? That way it's just one more flavor to 86 from that duplication.
[19:59] <vorlon> ok
[20:00] <Eickmeyer> vorlon: As an aside, I looked at Budgie's and it's still way more than necessary since they're not doing a legacy install anymore.
[20:10] <vorlon> LocutusOfBorg, doko: a straight revert, but eyes welcome: https://launchpad.net/ubuntu/+source/dpkg/1.22.6ubuntu3 (also, I missed reverting the test case oops)
[20:22] <vorlon> why does perl make you count your tests, that's such a dumb convention
[20:23] <seb128> Eickmeyer, vorlon, so with mate switching can we drop the ubiquity gui installer? (keeping the oem-setup part still)
[20:27] <Eickmeyer> seb128: Yeah, once I can land the change in the seed/meta. I'm blocked by not being part of ~ubuntu-mate-dev. Working on that.
[20:30] <Eickmeyer> seb128: I think we'll also need to push out another spin of `ubiquity-slideshow-ubuntu` since it has some generic wording changes on Edubuntu's part. Also, I think `oem-setup` needs a no-change-rebuild because the slideshows have a major graphical glitch.
[20:49] <vorlon> seb128: I was going to double-check whether all flavors had moved
[20:50] <vorlon> Eickmeyer: core-dev can land seed changes for ubuntu-mate-dev
[20:51] <vorlon> but the previous livecd-rootfs didn't migrate because of failing autopkgtests, let's see
[20:52] <vorlon> seb128, Eickmeyer: I still see ubiquity in ubuntu-unity
[20:53] <arraybolt3> vorlon: ack, I did a ton of work to fix that yesterday and am trying to fix it up ASAP
[20:53] <arraybolt3> Got swallowed by an insane workload on multiple fronts and it kept me very delayed
[20:54] <vorlon> 379s The $BUILDSTAMP variable is empty
[20:54] <arraybolt3> (r.e. ubiquity on Ubuntu Unity)
[21:01] <vorlon> ok well I'm going to go refactor this code then
[21:01] <vorlon> meanwhile I have pinged utkarsh and philroche about the autopkgtest regressio
[21:14] <ItzSwirlz> vorlon: what will I need to get nemo (and then cinnamon) out of the proposed pocket and into -release
[21:14] <ItzSwirlz> I know cjs has a build failure
[21:36] <vorlon> Eickmeyer: why have we ended up saying not to put casper in the live layer for all of these flavors, which don't have casper in their live seed?
[21:36] <vorlon> Eickmeyer: only ubuntucinnamon, ubuntu, ubuntustudio, and xubuntu appear to have it seeded
[21:37] <vorlon> ItzSwirlz: nemo's own autopkgtest is failing?
[21:38] <vorlon> ItzSwirlz: and cinnamon-desktop shows failing autopkgtests for cinnamon-control-center: https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#cinnamon-control-center https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#cinnamon-desktop
[21:38] <vorlon> ItzSwirlz: it will *also* block on our ability to get new glib2.0 through for the armhf time_t transition, but the above are all nemo/cinnamon-specific issues to be resolved
[21:40] <ItzSwirlz> cinnamon-control-center, nemo are failing
[21:40] <ItzSwirlz> and cjs
[21:41] <vorlon> Eickmeyer: ah because it's being added in the livecd-rootfs code later <grump>
[21:43] <Eickmeyer> vorlon: Correct.
[21:44] <vorlon> Eickmeyer: ok. it doesn't look like it's being added there for all flavors either; I'm going to do an audit and raise MPs against seeds as needed
[21:45] <Eickmeyer> vorlon: FWIW, I have it *pending* for mate. Also, FWIW, I'm not a core-dev (yet), hence can't land these changes on my own to the mate seed.
[21:45] <vorlon> yes, but you can point me at it and I can merge
[21:45] <Eickmeyer> vorlon: Ah, fair.
[21:51] <Eickmeyer> vorlon: https://code.launchpad.net/~eeickmeyer/ubuntu-seeds/+git/ubuntu-mate/+merge/462637
[21:52] <Eickmeyer> After that, I can do a meta update with no issues.
[23:29] <LocutusOfBorg> thanks vorlon !
[23:29] <LocutusOfBorg> btw vorlon doko abseil from Debian experimental works on 32bit with time64_t
[23:30] <LocutusOfBorg> maaaaaaaaaaaybe syncing it is better than disabling tests
[23:30] <LocutusOfBorg> (discussed in debian-release too)
[23:30]  * LocutusOfBorg will not sync it, sleep time


[01:03] <ArneGoetje> pitti: typo. it's iain-farrell. Will change it later, when LP is out of read-only mode again.
[01:33] <rickspencer3> aaarg
[01:34] <rickspencer3> stupid read only launchpad ate the work items I added
[01:34] <rickspencer3> and I didn't save my work :(
[01:34] <rickspencer3> pitti, looks like I failed to get the work items on, I'll do it tomorrow
[01:36] <fagan> rickspencer3: ouch
[01:38] <bryce> bummer
[01:38]  * fagan is using vb at the moment which I hear rickspencer3 had some hand in making :)
[01:38] <rickspencer3> fagan, nah, not really
[01:39] <rickspencer3> I worked on the Visual Studio shell for a while starting in '98
[01:39] <rickspencer3> and did a lot of work with C# language V2 and the Visual Studio editor
[01:39] <rickspencer3> all as a usability engineer
[01:39] <fagan> rickspencer3: Oh cool
[01:40]  * fagan is just doing a crappy college project and would prefer to be using quickly
[01:40] <rickspencer3> lol
[01:40] <rickspencer3> of course
[01:48] <rickspencer3> hah
[01:48] <rickspencer3> launchpad emailed me a diff before it blew away my changes
[01:49] <rickspencer3> still read only though, I'll add 'em back tomorrow
[01:49] <rickspencer3> good night all, see you tomorrow
[01:50]  * Amaranth starts thinking extreme for compiz
[01:51] <fagan> Amaranth: how extreme?
[01:51]  * fagan is going to miss wobbly windows when gnome-shell comes in
[01:51] <Amaranth> load these plugins: core,move,resize,place,decoration,animation,ccp,gnomecompat,text,commands,wall,snap,expo,staticswitcher,regex,workarounds,fade,session
[01:52] <Amaranth> no more scale, zoom, dbus, etc
[01:52] <Amaranth> I'd cut expo from the defaults too, actually
[01:52] <Amaranth> perhaps regex so long as our default settings don't use it
[01:52] <Amaranth> then you can get rid of text too
[01:52] <fagan> Amaranth: well cutting stuff that isnt used is always good :)
[01:52] <Amaranth> and you end up with a crappy metacity
[01:53] <Amaranth> fagan: I just cut everything that the metacity compositor doesn't implement
[01:53] <fagan> metacity is awesome
[01:53] <fagan> :)
[01:54] <Amaranth> Except we'd need an extra level in Visual Effects if we did this
[01:54] <Amaranth> Because Extra should then change it back to what we were using before
[01:54] <fagan> and it should be called awesome
[01:54] <Amaranth> But in that case I dunno how much it'd actually help because we'd still have the plugins installed which means ccp reads the data for them and loads the gconf settings for them
[01:54] <bryce> fagan, only if the monitor physically shakes when you use it
[01:55] <fagan> bryce: I think thats compiz's drunk mode
[01:55] <Amaranth> I really hope splitting up the plugins into separate packages and only installing what we use gets compiz fast enough to keep it in
[01:55] <Amaranth> because if I have to backport the 0.9 plugin system upstream is going to hang me
[01:56] <fagan> Amaranth: Well if gnome-shell is ready for lucid+1 then this will more than likely be the last release of compiz in ubuntu
[01:56] <Amaranth> fagan: From what I've heard I sort of doubt that
[01:56] <Amaranth> fagan: Probably lucid+2
[01:57]  * fagan doesnt think it will be ready for another year
[01:57] <fagan> lucid+3 at the latest
[01:57] <Amaranth> at which point I start throwing together bits from XFCE and GNOME 2.x and make my own spin using compiz :)
[01:57] <Amaranth> oh, and gnome-do/docky :)
[01:58] <fagan> Amaranth: http://shanefagan.com/2009/12/03/more-gnome-shell-messing-from-me/
[01:58] <fagan> :)
[01:58] <fagan> docky + gnome-shell
[01:58] <Amaranth> eh
[01:59] <Amaranth> gnome-shell still feels too much like it's getting in my way
[01:59] <fagan> I like it, plus when you get used to the super key its very easy
[01:59] <Amaranth> and I disagree with the architecture
[02:00] <Amaranth> It would not have been nearly as difficult as they say to have gnome-shell and mutter be separate
[02:00] <Amaranth> If they did that I could make it work with compiz in no time
[02:00] <Amaranth> But when I asked about it they told me to go use XFCE. I then worked on XFCE for a couple months and got commit access :P
[02:01] <fagan> Id say it wouldnt take a lot of work to get it using compiz but since shell is using clutter the window manager could use it
[02:01] <fagan> Amaranth: I think when shell is released lots of distros are going to stay with panel
[02:01] <Amaranth> The thing that makes me wonder if we're going to see gnome-shell used at all is the lack of 3D drivers for everything
[02:02] <Amaranth> What do you use if gnome-shell can't run?
[02:02] <fagan> Metacity?
[02:02] <Amaranth> The funny thing is gnome-shell/mutter is dropping non-3D users while compiz git works right now without compositing and xrender compositing is planned
[02:03] <Amaranth> fagan: So we have to ship metacity, gnome-panel, and friends forever but they are completely unmaintained. Awesome.
[02:03] <bryce> why do they call it 'gnome-shell' anyway?
[02:03] <bryce> what is shelly about it?
[02:03] <fagan> bryce: its a new UI shell for gnome
[02:03] <Amaranth> I dunno, they keep using the term "desktop shell"
[02:03] <fagan> it makes sense
[02:04] <Amaranth> I know Windows calls the explorer process a "shell" so I guess they get it from there
[02:04] <bryce> huh
[02:05] <fagan> All I know is that we need a redesign weather or not gnome-shell is right is debatable but at least its something new
[02:06] <fagan> Panel is very dated
[02:06] <bryce> I would just like something which behaves itself when I do xrandry things
[02:08] <fagan> I just want something a little more fault tolorent than panel. If panel crashes it trys to start itself again but if its a major crash it keeps trying to start again and makes the desktop completely unusable
[02:09] <fagan> panel is a pain when it crashes
[02:10] <bryce> ick
[02:11] <fagan> I think the crash problem is solved (slightly) by gnome shell not allowing applets embedded in the panel
[02:14] <fagan> bryce Amaranth I would like if we just shipped ubuntu netbook edition as the default desktop because its a lot sleeker and a lot more stable than shell
[02:16] <Amaranth> fagan: Every app marked to be restarted automatically by the session does that
[02:16] <Amaranth> when working on some nautilus patches I actually exhausted the number of connections I could have to the X server due to nautilus restarting and crashing over and over and apport showing a dialog for each crash
[02:16] <fagan> Amaranth: I know but its a real pain if you have a segfault
[02:16] <Amaranth> had to restart X to fix it
[02:17] <bryce> let's port UNE to Wayland :-)
[02:17] <fagan> Wayland?
[02:17] <Amaranth> wayland is awesome :)
[02:17] <Amaranth> and actually still needs a "compositor"
[02:17] <Amaranth> It does most of the work itself though so what it really needs is an app to implement effects
[02:18] <fagan> Whats wayland?
[02:18] <Amaranth> a display server written from scratch to take advantage of things like gallium, KMS, GEM, etc
[02:19] <fagan> ah
[02:20] <bryce> fagan, http://www.phoronix.com/scan.php?page=article&item=xorg_wayland&num=1
[02:20] <Amaranth> it's fast, small, and completely flicker free
[02:20] <Amaranth> oh, and everything is client side
[02:21] <bryce> Amaranth, have you run it?
[02:21] <Amaranth> the server just composites pixmaps together and blits them
[02:21] <Amaranth> bryce: nah, never got a chance to get it all setup
[02:21] <Amaranth> bryce: Looks like you could do it in vmware or qemu now though
[02:21] <bryce> I'm working on getting it packaged
[02:21] <bryce> (off and on)
[02:21] <fagan> bryce: awesome
[02:22] <fagan> x.org is starting to look a little out of date
[02:22] <bryce> starting?
[02:22] <Amaranth> eh, wayland is an experiment, really
[02:22] <Amaranth> If anything you'll end up running wayland but all your apps will be running in rootless X servers
[02:23] <bryce> actually X.org is refactoring itself slowly towards modernity
[02:23] <Amaranth> or wayland will run under X and let you do neat transitions for user switching
[02:23] <Amaranth> bryce: Right, I was saying if wayland gets used at all by a wide audience that'll be how
[02:24] <bryce> Amaranth, yep, that's my thought too
[02:24] <Amaranth> wayland would help with boot times though ;)
[02:24] <bryce> definitely
[02:24] <bryce> another use case I could imagine is for really limited functionality devices
[02:24] <Amaranth> hurry up and package it so we can switch :D
[02:24] <bryce> like maybe some of the arm stuff
[02:24] <Amaranth> gotta shave those seconds
[02:25] <bryce> hey I found out that my failsafe-x mode boots X in <1 sec
[02:25] <bryce> so if we all just switch to vesa...
[02:25] <ajmitch> no thanks
[02:25] <Amaranth> ooh
[02:26] <ajmitch> though I did barely notice for awhile that my desktop was using nv instead of nvidia
[02:26] <bryce> ajmitch, wow interesting
[02:26] <Amaranth> ajmitch: If you don't use compiz you probably won't notice at all when you're using nouveau
[02:26] <bryce> ajmitch, well we'll break that for you once we get nouveau in
[02:26] <Amaranth> Except things will actually be fast
[02:26] <ajmitch> Amaranth: I only noticed when I tried to turn compiz on :)
[02:27] <Amaranth> nouveau 2D acceleration is amazing
[02:27] <bryce> dinner... bbl
[02:27] <ajmitch> perhaps I was just used to my desktop being slow anyway
[02:27]  * fagan uses the nvidia proprietary drivers
[02:27] <lifeless> compiz? is african for 'make-my-desktop-laggy'  ?
[02:27]  * lifeless bites his sarcastic fingers
[02:27] <fagan> lifeless: but it looks nicer
[02:28] <fagan> and notify-osd fades a lot better
[02:28] <fagan> and alt+tab looks nicer
[02:28] <lifeless> yes, but I like being able to alt-tab quickly
[02:28] <Amaranth> nouveau makes using the metacity compositor pleasant
[02:28] <fagan> and dont forget wobbly windows
[02:28] <Amaranth> lifeless: It's pretty fast here...
[02:28] <ajmitch> Amaranth: but will it play world of warcraft in wine yet? :)
[02:29] <Amaranth> ajmitch: depends
[02:29]  * fagan loves wobbly windows and misses them when he is in windows land
[02:29] <Amaranth> you need the exact same chip and such as the developer who got it working, basically
[02:29] <ajmitch> I doubt that the memory management of nouveau's 3d driver is adequate for wow
[02:30] <Amaranth> did you beat WoW yet?
[02:30] <ajmitch> that would require me spending far too much time on it
[02:30] <ajmitch> so 'no thanks' :)
[02:31] <fagan> Amaranth: Some guy got all but one achievement
[02:31] <fagan> That dude must have 0% life
[02:31] <fagan> He must be able to kick everyones ass
[02:32]  * fagan gos back to making the single worst program ever made
[02:32] <fagan> (college VB project)
[02:33] <ajmitch> do you feel dirty yet?
[02:34] <fagan> ajmitch: I feel like I just ran threw a ditch
[02:34] <ajmitch> heh
[02:34] <fagan> plus its 2.30
[02:34] <fagan> am
[02:34] <fagan> the project is due in 12.30 hours
[02:35] <fagan> and I have barely anything done
[02:35] <ajmitch> good luck, and you should ignore irc for a few hours :)
[02:35] <fagan> ajmitch: I know im just on a tea break
[02:35] <fagan> Plus I have taxi driver in the backround
[02:35] <fagan> So im happy
[07:30] <pitti> Good morning
[07:34] <fagan> morning
[08:04] <fagan> hmmmmm
[08:05] <fagan> I found a little bug in open office thats just for the Irish local
[08:05] <fagan> We should be using the UK dictionary instead of not using any
[08:32] <chrisccoulson> good morning everyone
[08:39] <seb128> good morning here
[08:42] <chrisccoulson> good morning seb128
[08:43] <seb128> hey chrisccoulson
[08:44] <chrisccoulson> how are you today?
[08:45] <seb128> good, you?
[08:45] <chrisccoulson> yeah, not too bad thanks. glad it's friday :)
[08:53] <seb128> hum
[08:53] <seb128> my pc is beeping again today
[08:54] <seb128> ie loud and annoying speaker sound
[09:02] <seb128> ok
[09:03] <seb128> it's half pitti's fault half mine on this one
[09:03]  * seb128 fixes now
[09:03] <pitti> ?
[09:03] <seb128> pitti, you didn't commit your libgnome change to bzr
[09:04] <seb128> and I didn't notice the revision was not there when merging
[09:04] <seb128> so the "turn bell off" got dropped
[09:04] <pitti> oops, I'm sorry
[09:04] <seb128> np
[09:04] <seb128> we really need hooks to check that the bzr version match the archive one
[09:04] <seb128> I forget to push sometimes too...
[09:05] <chrisccoulson> i've been caught out before by people forgetting to push too :)
[09:05] <chrisccoulson> although, i should check the versions match too
[09:23] <seb128> hum
[09:24] <seb128> bryce, pitti: the xorg syncs breaked installability for gtk...
[09:24] <seb128> libxi
[09:24] <pitti> oh darn, how?
[09:24] <seb128> depwait on libx11-dev (>= 2:<IP_ADDRESS>)
[09:24] <seb128> and we have
[09:24] <seb128> “libx11” 2:1.2.2-1ubuntu1 source package in Ubuntu
[09:24] <seb128> pitti, things don't build because our libx11 is too old
[09:25] <seb128> we are sort of in the middle of a transition
[09:25] <pitti> -> #u-devel
[09:25] <seb128> nothing desktopish build now
[09:33] <pitti> I need to disappear for some 2 hours
[09:34] <pitti> bbl
[09:34] <seb128> pitti, see you later
[09:34] <seb128> maybe archive will be fixed by time you come back ;-)
[09:45] <seb128> hey Keybuk
[09:47] <Keybuk> hey
[10:46] <seb128> ok, let's try the daily dist-upgrade and look at login
[10:48] <seb128> bbl
[12:16] <pitti> seb128: should bug 460535 be assigned to slomo instead of you?
[12:33] <sabdfl> seb128: want to talk about the bottom panel piece, i can chat now if you want
[12:35] <seb128> re
[12:36] <seb128> just back from lunch
[12:36] <chrisccoulson> pitti - did you mean to assign bug 491162 to ubuntu-desktop (or desktop-bugs?)
[12:36] <seb128> hey sabdfl
[12:36] <seb128> pitti, ^
[12:36] <pitti> hey sabdfl
[12:36] <seb128> sabdfl, was your concern about the 2 bars against 1? or about a particular applet?
[12:37] <pitti> sabdfl: so the original idea was to drop some of the less popular applets and the starters, and merge the two panels (an idea which has been thrown around for a loong time already, but we never got to it)
[12:37] <pitti> this particularly helps with smaller screens like laptops
[12:38] <pitti> so you want to keep the two panels?
[12:38] <pitti> chrisccoulson: I didn't assign it in the first place; not sure whom to give it to yet
[12:39] <chrisccoulson> pitti - ah, you're right, it was bryce i think. i thought it was you because i only got an e-mail when you changed the milestone (and not when it was assigned)
[12:39] <chrisccoulson> sorry ;)
[12:41] <seb128> pitti, does it need to be assigned at all?
[12:41] <pitti> or unmilestoned
[12:42] <seb128> pitti, it will be in the next upstream version so in lucid
[12:42] <pitti> I gave Keybuk a quick ping, so far I don't understand it at all yet, I'm afraid
[12:42] <pitti> seb128: oh, you mean gstreamer, sorry
[12:42] <pitti> seb128: we just usually fix SRUs in the dev release first, that's why I milestoned it
[12:42] <seb128> yes
[12:42] <seb128> I prefer to stay on sync with Debian
[12:43] <seb128> I'm fine being assigned to it
[12:43] <seb128> milestone for beta rather if you want
[12:43]  * pitti moves to alpha-2
[12:43]  * fagan thinks 2 panels are nice
[12:43] <Keybuk> seb128, pitti: I replied on ubuntu-devel
[12:43] <Keybuk> I'd rather not touch that line right now
[12:43] <pitti> Keybuk: thanks
[12:43] <Keybuk> because you might hide the problem
[12:44] <Keybuk> I get failure to start gdm right now most boots ;)
[12:44] <Keybuk> and I can definitely say it's not that line
[12:44] <Keybuk> because I can debug upstart, and it says that match is TRUE :p
[12:44] <Keybuk> there's certainly a bug because you removed the "and started hal"
[12:44] <Keybuk> I've had a few failures where gdm runs out of respawns
[12:44] <Keybuk> but that's not it either
[12:44] <Keybuk> so far my *theory* is that the framebuffer (graphics) device shows up
[12:44] <Keybuk> but X wants the DRM device
[12:45] <Keybuk> and that hasn't shown up yet
[12:45] <Keybuk> and again, you run out of respawns
[12:45]  * pitti hopes the answer isn't "put back hal" :)
[12:46] <pitti> I take it the "on hal" just delayed the startup far enough for the fb to get active?
[12:46] <pitti> s/fb/drm/
[12:48] <Keybuk> no
[12:48] <Keybuk> X genuinely needs HAL :p
[12:48] <Keybuk> you didn't fix that
[12:48] <pitti> Keybuk: ... at it
[12:48] <Keybuk> bryce could upload X with those patches, of course
[12:48] <pitti> the libraries were synced last night
[12:48] <Keybuk> :D
[12:48] <tjaalton> we are close..
[12:49] <Keybuk> HAL MUST DIE!
[12:49] <pitti> those are needed first
[12:49] <tjaalton> pitti: reminds me, two more syncs; libxcb and libxtst
[12:49] <tjaalton> and libxvmc
[12:49] <pitti> tjaalton: don't bother about filing bugs; doing right now
[12:49] <pitti> tjaalton: experimental or unstable?
[12:50] <tjaalton> pitti: done already :) libxcb - unstable, libxtst - exp, libxvmc - unstable
[12:50] <Keybuk> pitti: I think we're just genuinely missing something
[12:50] <Keybuk> it's on my plate to debug
[12:50]  * fagan hugs pitti for killing hal hitman style
[12:50] <Keybuk> and will probably look into that next week during alpha 1 freeze
[12:51] <pitti> tjaalton: synced; can you please close the bugs?
[12:51] <tjaalton> pitti: yep, on it
[12:51] <tjaalton> thanks
[12:51] <pitti> thanks to you
[13:09] <pitti> Riddell: want to add some Kubuntu bits to https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus for today's release team meeting?
[13:34] <sabdfl> erk
[13:35] <sabdfl> i got drawn into something else
[13:35] <sabdfl> we do have a design plan to get to one panel, but in order to do that we have to provide substitutes for the functions in the bottom panel today
[13:35] <sabdfl> those will likely be here for 10.10, but not 10.04
[13:36] <sabdfl> i don't want two panels, but I don't want to bastardise the top panel either, and in the interim the plan is to live with two till we have good solutions
[13:36] <pitti> sabdfl: we thought to move the task switcher into the top panel
[13:36] <pitti> sabdfl: ok, that's fine
[13:37] <pitti> sabdfl: having two panels isn't actually a speed issue, we just thought that when we are at reducing the applets anyway, we can just as well get to that
[13:37] <pitti> but let's defer that then
[13:37] <sabdfl> ok thanks
[13:38] <sabdfl> with Unity, trash is in Places, the "what's running" is handled by the launcher, and desktop reveal is part of task switching
[13:38] <pitti> so those two should stay, too?
[13:57] <seb128> pitti, the plan we had was to move task list and workspace switcher to the one bar
[13:57] <seb128> and drop trash (which is in nautilus places anyway) and show desktop button
[13:58] <seb128> we changed the clock to not display the date too
[13:58] <seb128> that made the one panel fit ok on small screens and reduce some login load due to the extra applets we cleaned
[13:59] <seb128> ups
[14:00] <seb128> sabdfl, ^
[14:00] <seb128> pitti, sorry that was not for you ;-)
[14:00] <istaz> sabdfl: pitti doest it mean 10.10 won't be using gnome-shell by default?
[14:01] <seb128> istaz, that has not been discussed yet, gnome-shell is not ready for that let's see how it goes in the next 6 months
[14:01] <istaz> ok
[14:02] <seb128> istaz, right now gnome-shell works only on machines with fast graphic and compositing and has no fallback and we will need to solve that issue anyway
[14:02] <seb128> istaz, but that's discussions for next cycle
[14:03] <seb128> in any case we will need to figure something for installs which don't allow running gnome-shell
[14:03] <istaz> I will be quite happy if you are still going to provide support for my older computer which won't support gnome-shell :)
[14:03] <seb128> see ;-)
[14:31] <tedg> kenvandine: Could you set up the bustle data collector to start with the session start so then we could get all the dbus traffic to align with the bootcharts?
[14:31] <kenvandine> baybe
[14:31] <kenvandine> maybe
[14:31] <kenvandine> i haven't looked at it yet
[14:32] <kenvandine> i am still trying to get that patch into gtk :/
[14:32] <kenvandine> with 2.19.1 it fails make check...
[14:32] <kenvandine> so fixing those tests now
[14:32] <tedg> kenvandine: I went to the session at GCDS on it, and it's cool.  I'm not sure how to put it "really early" into gnome session though.
[14:32] <kenvandine> tedg, yeah, i'll look at that
[14:32] <kenvandine> unless seb128 wants to take a stab at it on the target hardware :)
[14:33] <kenvandine> i also want to use it to look at gwibber
[14:33] <tedg> kenvandine: Don't do that, it'll make you cry ;)
[14:33] <seb128> kenvandine, hey, how is empathy 2.29 going btw?
[14:33] <seb128> kenvandine, I don't know how to do this dbus thing
[14:34] <kenvandine> seb128, haven't touched it yet... soon though :)
[14:34] <kenvandine> seb128, i haven't looked at bustle yet
[14:34] <kenvandine> well, read about it
[14:34] <seb128> ok, me neither
[14:34] <tgpraveen11> Hi all
[14:34] <kenvandine> seb128, i need to get the docs building for the app indicators too
[14:34] <tedg> seb128: http://www.willthompson.co.uk/bustle/  basically  "bustle-dbus-monitor >foo.bustle" will basically dump all the stuff off the session bus into "foo.bustle"
[14:34] <seb128> and I'm busy with other changes
[14:34] <tgpraveen11> Sup guys?
[14:34] <seb128> I'm fine doing testing but I'm too busy to learn what to do
[14:35] <seb128> ie give me instructions or look for somebody else
[14:35] <kenvandine> seb128, this gtk patch has turned into a pile of work :/
[14:35] <kenvandine> seb128, i'll figure out a way to make it start early and you can just do it :)
[14:35] <seb128> kenvandine, I was expected it to be some work indeed
[14:35] <seb128> kenvandine, ok thanks
[14:36]  * kenvandine finally moved the actually building of gtk to another box... so at least my laptop doesn't overheat, this weekend i really need to take it apart and check it out
[14:36] <kenvandine> maybe a lose heat sink or something
[14:36] <kenvandine> loose
[14:37]  * kenvandine thinks evolution filtering has gotten way slower
[15:04] <seb128> tedg, just curious why do you ask us to get those dbus infos where you could get those?
[15:04] <seb128> tedg, you don't get the cpu use on your box?
[15:05] <seb128> chrisccoulson_g1, chrisccoulson: what delay did you investigate exactly? the one before or after gnome-settings-daemon?
[15:05] <seb128> or both?
[15:05] <chrisccoulson> seb128 - before gnome-settings-daemon
[15:05] <seb128> http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091203-1.png
[15:06] <seb128> the delay before compiz is 2 seconds there
[15:06] <seb128> 1 before g-s-d
[15:06] <seb128> one after g-s-d
[15:06] <chrisccoulson> Keybuk - if a process loads at boot, and then at some point calls execvp() and turns in to something else, what process name will be shown in bootchart (or does it get a new line)?
[15:07] <seb128> I'm wondering what is the 1 second between seahorse and compiz
[15:07] <Keybuk> chrisccoulson: the second process name I think
[15:07] <Keybuk> it may be the first
[15:08] <chrisccoulson> seb128 - that delay is just g-s-d loading isnt it?
[15:08] <tedg> seb128: I don't get as much.  But I haven't run a bootchart.  I wasn't looking at the bustle data as much for just me, I thought it'd be useful for the desktop optimization in general.
[15:08] <chrisccoulson> Keybuk - thanks. i've been looking at the 1 second delay in gnome-session. I know where most of it is wasted now, but there is still a small amount unexplained
[15:08] <chrisccoulson> but then i just realised something :)
[15:09] <chrisccoulson> actually, no, what i realised only applies to my own setup, as i have seahorse-agent installed
[15:09] <chrisccoulson> :(
[15:09] <chrisccoulson> seahorse-agent starts up and then calls execvp() and runs gnome-session
[15:10] <seb128> chrisccoulson: I don't know there is no color in the bar during that second
[15:10] <Keybuk> right
[15:10] <seb128> which is weird
[15:10] <Keybuk> bootchart can be confusing here
[15:10] <Keybuk> sometimes it helps to get the tgz and regenerate the bootchart with --no-prune
[15:10] <Keybuk> then you get a whole load more detail
[15:10] <chrisccoulson> Keybuk - that's what I thought. so, i'm not sure gnome-session is _really_ gnome-session for some of that time:)
[15:10] <seb128> Keybuk, btw do you still have daily measures?
[15:10] <chrisccoulson> but i could be clutching at straws ;)
[15:11] <seb128> Keybuk, could you remember me the url?
[15:12] <chrisccoulson> seb128 - yeah, it's wierd that there is no colour. what i need to do is some profiling in g-s-d really to work out how long it really holds the session up for
[15:12] <chrisccoulson> but i haven't got around to that yet:)
[15:12] <Keybuk> seb128: http://people.canonical.com/~scott/daily-bootcharts/  ?
[15:13] <chrisccoulson> i'm trying to get gconf to start early, but it's more difficult than i thought, as it needs the session bus
[15:13] <chrisccoulson> but, i'm sure i can make it work :-/
[15:13] <seb128> Keybuk, thanks
[15:13] <seb128> Keybuk, weird I don't have similar numbers
[15:13] <rickspencer3> didrocks, thanks for getting the work items into the quickly blueprints
[15:13] <Keybuk> seb128: smaller with?
[15:14] <seb128> Keybuk, http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091203-1.png
[15:14] <seb128> Keybuk, it's over one second difference
[15:14] <Keybuk> seb128: are you running with any patches?
[15:14] <Keybuk> or PPAs etc.?
[15:14] <seb128> not that I know about
[15:14] <seb128> but I don't reinstall the box
[15:14] <seb128> I dist-upgrade daily
[15:15] <Keybuk> your X starts much faster
[15:15] <Keybuk> you're into the session by 10s
[15:15] <Keybuk> oh
[15:15] <Keybuk> no
[15:15] <Keybuk> so I am
[15:16] <Keybuk> ah
[15:16] <seb128> hum
[15:16] <Keybuk> I see
[15:16] <Keybuk> jockey-gtk
[15:16] <Keybuk> pitti: is that still not fixed?
[15:16] <seb128> ah right
[15:17] <seb128> Keybuk, thanks
[15:17] <Keybuk> because mine are fresh installs every time, I get jockey penalty on that boot
[15:17] <Keybuk> I also don't see dkms on yours, do you have the bcmwl thing installed?
[15:17] <seb128> are we supposed to measure standard boot or first boot after install?
[15:17] <seb128> first boot after install probably has some other extra work
[15:18] <seb128> like gnome-panel writting their config etc
[15:18] <Keybuk> this is second boot
[15:18] <Keybuk> which is why the jockey-gtk confuses me
[15:18] <Keybuk> I allow a first boot for everything to sort itself out
[15:18] <seb128> I don't think I've bcmwl installed no
[15:18] <Keybuk> that could be it too I guess
[15:18] <Keybuk> will grab pitti when he returns
[15:18] <seb128> ok
[15:19] <pitti> argh, that
[15:19] <Keybuk> :D
[15:24] <sabdfl> seb128, i don't think we can drop trash, though we could probably improve performance (like do lazy detection of whether there's anything in the trash)
[15:25] <seb128> sabdfl, ok, I had the impression it was not so useful since you can open from nautilus easily but I've no strong opinion
[15:26] <seb128> sabdfl, the other reason to reduce the number of applet is that each one has a start cost for gnome-panel
[15:27] <seb128> sabdfl, we should have a look to that anyway but that will go down to the bonobo use at some point and we can't replace that easily
[15:28] <seb128> though the one slowing login most now is the indicator message one
[15:33] <sabdfl> seb128: jump on Ted for that :-)
[15:33] <sabdfl> he promised me he'd make it *blindingly* fast
[15:34] <sabdfl> so, hold him to that
[15:34] <seb128> right, I've annoying him for a few days about it now ;-)
[15:34] <seb128> I've -> I'm
[15:35] <pitti> sabdfl: we make the trash applet so fast that you won't even see it!
[15:37] <seb128> ;-)
[15:40] <rickspencer3> lol
[15:40] <chrisccoulson> seb128 - we could add trash to the places menu, couldn't we?
[15:40] <rickspencer3> for trash, I was thinking that we could cache the current icon (full or empty) and then not init the trash until the user clicks on it
[15:40] <pitti> that wouldn't make too much sense to me
[15:40] <pitti> the sense for having it on desktop is to be a drag'n'drop target
[15:40] <seb128> chrisccoulson: wouldn't solve the issue we would still start the backend to display the icon
[15:41] <pitti> otherwise it's easier to just press delete or right-click
[15:41] <rickspencer3> but the problem with trash, as I understand it, is the init function to get the icon
[15:41] <chrisccoulson> ah, i wasn't aware
[15:41] <chrisccoulson> seb128 - if it was in the places menu, you wouldn't have to start the backend until you opened the menu
[15:41] <rickspencer3> I would think 99.99% of the time the state would be the same as when the user logged off last
[15:41] <seb128> rickspencer3, wouldn't work, the trash is supposed to update when you select an icon on the desktop and press del
[15:41] <pitti> seb128: however, I don't have a trash applet, and gvfsd-trash is still running; I suspect that nautilus starts it anyway
[15:41] <rickspencer3> I don't want it to be so that when the user clicks on menu it doesn't open immediately
[15:42] <rickspencer3> that's not really a good expereince
[15:42] <seb128> right
[15:42] <chrisccoulson> pitti - yeah, nautilus will start it when you move something to trash
[15:42] <seb128> anyway it doesn't cost so much on the stock install since the trash is empty
[15:42] <seb128> it costs for users who have things in the trash
[15:42] <rickspencer3> seb128, so can't the trash just init at hat point?
[15:43] <seb128> it could I guess
[15:44] <rickspencer3> seb128, I think that logic could probably be used by UNE, so could be a double win, desktop and netbook users would benefit
[15:45] <didrocks> rickspencer3: y/w :) (I told you yesterday that I'll work on that this afternoon ;))
[15:46] <didrocks> I have to run away, have a nice week-end!
[15:46] <rickspencer3> bye bye didrocks
[15:46] <rickspencer3> thanks again
[15:47] <seb128> didrocks, have fun
[15:47] <rickspencer3> kenvandine, where does gwibber store credentials currently?
[15:53] <kenvandine> keyring i think
[15:54] <kenvandine> eww... gconf
[15:54] <kenvandine> that needs to be fixed
[16:07] <gorgapor>  how would I find out where the gnome-terminal color schemes are located, like tango, rxvt, xterm, linux console, etc? I'm sure they are some xml file somewhere, but I can't find them
[16:11] <dobey> kenvandine: yeah, i think i convinced segphault that we should store that stuff in keyring at uds
[16:16] <kenvandine> dobey, good
[16:16] <chrisccoulson> seb128 - the latest GDM has debugging on by default now, and dumps loads of stuff in syslog
[16:16] <chrisccoulson> do we want to switch that off?
[16:16] <chrisccoulson> (it might mess up the bootchart numbers) ;)
[16:17] <seb128> yes
[16:17] <seb128> or new gnome-icon-theme uploaded
[16:18] <seb128> we didn't have an icon cache for the gnome icon theme
[16:18] <seb128> I noticed while tracing nautilus
[16:18] <seb128> it was opening some 360 times the outdated cache there
[16:18] <seb128> seems to win almost one second
[16:18] <seb128> we are around 11 seconds for desktop now
[16:19] <rickspencer3> nice
[16:19] <chrisccoulson> awesome :)
[16:19] <pitti> seb128: *hug*
[16:19] <rickspencer3> 7 seconds to go
[16:20] <seb128> thank you guys ;-)
[16:20] <seb128> the bottleneck will be gnome-panel at some point
[16:20] <seb128> it takes longer than 4 seconds of cpu to start
[16:22] <rickspencer3> hmmm
[16:23] <rickspencer3> maybe we can cache images of gnome panel and defer loading them until the user clicks on them
[16:23]  * rickspencer3 just kidding
[16:23] <seb128> it has quite some blanks in middle though
[16:23] <seb128> let's see what robert_ancell figure
[16:23] <seb128> he said he would investigate slowness there
[16:23] <seb128> not for the blanks specifically but for gnome-panel
[16:25] <vuntz> seb128: gnome-panel is blocking the login for 4 seconds?
[16:25] <vuntz> seb128: or it's active during 4 seconds?
[16:26] <pitti> AFAICS it uses 4 blocks of CPU, 6 seconds together
[16:26] <seb128> vuntz, time between gnome-panel start and stop of loading for it is some 11 seconds
[16:26] <pitti> but spread out across 11 seconds
[16:27] <vuntz> seb128: would be nice to see the impact of out-of-process applets (remove them), and in-process applets (also remove them), and the the applications menu (remove it) :-)
[16:27] <seb128> using a plain color background spare a 1 to 2 second cpu use for nautilus
[16:27] <vuntz> just to know what is expensive
[16:27] <seb128> vuntz, most applets are around 0.3 seconds
[16:27] <seb128> or less
[16:27] <seb128> the menu one is around 2 seconds
[16:27] <seb128> or less now with gnome-menus caching
[16:28] <seb128> let me do some new charts about those
[16:28] <seb128> vuntz, I'm wondering if there the 0.3 seconds is basically the bonobo ping-pong cost
[16:28] <vuntz> well, the interesting part would be "what's left when you remove everything from the panel" :-)
[16:28] <vuntz> does it take 5 seconds?
[16:29] <seb128> I'm just doing that one now
[16:29] <seb128> it's booting
[16:29] <vuntz> lovely, thanks!
[16:29] <seb128> you're welcome ;-)
[16:29] <vuntz> rickspencer3: you're lucky to have good slaves like seb128 ;-)
[16:30] <vuntz> lalala
[16:30] <seb128> lol
[16:30] <rickspencer3> vuntz, I think you have that relationship backward
[16:31] <seb128> vuntz, empty panel uses cpu for 1 second
[16:33] <seb128> http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091204-5.png
[16:33] <seb128> let's add the clock and then the other in process in order
[16:35] <vuntz> rickspencer3: heh
[16:36] <vuntz> seb128: cool, that's a good data point. Still way too much, but I was afraid it'd be more ;-)
[16:39] <seb128> vuntz, http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091204-7.png
[16:39] <seb128> that is only the clock
[16:39] <seb128> and it's already interesting
[16:39] <seb128> you have loading
[16:39] <seb128> over a second of nothing
[16:40] <seb128> and then not so busy use
[16:40] <pitti> seb128: http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091204-5.png
[16:40] <seb128> ie doing some things for a while
[16:40] <pitti> -> SHIP IT
[16:40] <pitti> :)
[16:40] <seb128> pitti, ;-)
[16:40] <vuntz> seb128: waiting for e-d-s, I'd guess
[16:40] <pitti> seb128: this still has gvfsd-trash
[16:40] <pitti> I think nautilus just starts it
[16:40] <seb128> pitti, right
[16:41] <seb128> vuntz, could we delay that until menu opening?
[16:41] <seb128> ie first click
[16:41] <pitti> oh, doesn't it?
[16:41] <seb128> vuntz, that would also avoid the "something ask for keyring password at login"
[16:42] <vuntz> seb128: "let me click, hrm, why do I have to wait for one second for the click to work?"
[16:42] <pitti> it seems to me that the first click on the clock takes ages
[16:42] <seb128> seems that happens when you are private calendars
[16:42] <pitti> I guess since it's talking to google cal, etc.
[16:42] <seb128> vuntz, couldn't you start init on mouseover?
[16:42] <vuntz> maybe, yeah
[16:42] <vuntz> in all cases, it should be delayed in some way
[16:42] <pitti> well, at least until everything else is ready
[16:42] <seb128> that should be quick enough to not have that issue
[16:42] <pitti> no reason not to start pulling calendars when the panel/nautilus are set?
[16:44] <rickspencer3> bryce, hi, are you available at 10:30 for the bughugger call?
[16:44] <seb128> vuntz, is there any extra work if weather is on?
[16:45] <seb128> seems to be half of that if I toggle those off...
[16:45] <seb128> those = weather and temperature options there
[16:45] <seb128> I would assume those would not add anything if there is no location set though
[16:46] <vuntz> seb128: yeah, the weather does some stuff, obviously
[16:46] <seb128> vuntz, but I've no location...
[16:47] <vuntz> hrm, interesting :-)
[16:48] <pitti> doesn't it default to "Eiffel Tower, Paris, France" if you don't have one set?
[16:48]  * vuntz wishes he had more time to look at all this :/
[16:48] <vuntz> pitti: nah. I live in Grenoble!
[16:49] <vuntz> that's a bit too visible to put by default, though ;-)
[16:49] <seb128> hum
[16:49] <seb128> http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091204-9.png
[16:49] <seb128> only the menus
[16:49] <seb128> it's still using quite a bit even with caching
[16:49] <seb128> and there is this long blank
[16:49] <seb128> I'm wondering if that's due to the 2 cores being busy
[16:49]  * seb128 removed nautilus from session
[16:53] <seb128> hum no
[16:53] <seb128> vuntz, that's weird, it does load, then sit there doing nothing for a some seconds and then start loading the menu
[16:54] <seb128> I'm wondering what is the some seconds about
[16:54] <vuntz> the menu is loaded in the idle loop
[16:54] <seb128> well it's idle
[16:54] <seb128> ie no activity
[16:54] <vuntz> it might be using 0.1% of the cpu to, say, draw itself on the screen
[16:55] <seb128> I'm wondering if we should build the menu in an agressive way
[16:55] <seb128> rather than during idle
[16:58] <seb128> Amaranth, hello
[16:59] <seb128> Amaranth, any chance you would upload that 1 liner compiz today?
[16:59] <seb128> Amaranth, we are sort on waiting on that for 3 days now...
[16:59] <seb128> or tell me if you are too busy I can do it
[17:02] <chrisccoulson> hmmm, i can't access my folder at people.ubuntu.com. i get a permission denied error :-/
[17:03] <chrisccoulson> seb128 - i might ask you to test some things i'm currently experimenting with shortly, if that's ok
[17:07] <seb128> chrisccoulson: sure
[17:09] <chrisccoulson> seb128 - i've patched gconfd now to parse the sources when it loads, rather than waiting for a client to read a value. i'm hoping that with the gnome-session changes, and the g-s-d change i'm about to do, that the sources can be parsed without delaying the rest of the session
[17:09] <chrisccoulson> but i don't know how well that's going to work yet ;)
[17:10] <chrisccoulson> seb128 - the patched gnome-session build you tested for me the other day loads g-s-d almost instantly btw
[17:10] <chrisccoulson> when you look at http://people.ubuntu.com/~chrisccoulson/gnome-session-startup-time/tests/seb128-dellmini-lucid-20091130-6-gnome-session-improvement.png
[17:11] <seb128> right
[17:11] <chrisccoulson> gnome-session _really_ starts in line with dbus-launch there
[17:11] <seb128> we just moved the gconf delay on that one
[17:11] <chrisccoulson> seb128 - yeah, that's what i'm working on to avoid now
[17:11] <seb128> btw do you think we could land your other optimization in lucid?
[17:11] <seb128> the dkpower one
[17:11] <chrisccoulson> seb128 - yeah, i can do that
[17:11] <seb128> did you send it upstream btw?
[17:11] <seb128> thanks
[17:13] <chrisccoulson> seb128 - do you want me to do that GDM change too? (to switch off debugging)
[17:13] <seb128> please
[17:40] <seb128> chrisccoulson: ok, I think the g-s-d 1 second delay is due to the xrandr option
[17:40] <seb128> or at least half of it
[17:41] <seb128> I'm wondering if it's doing some xorg queries it could avoid if there is no config on disk to apply anyway
[17:43] <chrisccoulson> yeah, i'm not too sure yet, as I've not done much with g-s-d.
[17:43] <chrisccoulson> it does start all the plugins before the rest of the session starts loading though
[17:44] <chrisccoulson> i was going to patch it to load xrandr and xsettings (hardcoded, to avoid reading from gconf), and then let the rest of the session start whilst it loads the other plugins (using gconf)
[17:44] <chrisccoulson> but that will mean that users would never be able to unload xrandr/xsettings, but i'm not sure how much that matters really
[17:45] <seb128> I doesn't I would say
[17:45] <chrisccoulson> thats the next thing on my list to work on anyway :)
[17:46] <chrisccoulson> after GDM is uploaded
[17:49] <pitti> seb128: jockey fix uploaded now
[17:49] <pitti> should avoid calling jockey
[17:49] <pitti> (except at first boot)
[17:49] <seb128> pitti, thanks
[17:50] <seb128> I didn't have jockey on my charts but scott did
[17:52] <chrisccoulson> cool, gdm uploaded now
[17:52] <chrisccoulson> time for some g-s-d hacking now
[17:55] <seb128> https://bugzilla.gnome.org/show_bug.cgi?id=586276 is interesting
[18:03] <chrisccoulson> seb128 - i can possibly have a look at that too, if we think that xrdb is too heavy
[18:04] <seb128> would probably be nice to clean but that's probably not the main issue we have now
[18:34] <seb128> chrisccoulson: http://mail.gnome.org/archives/performance-list/2009-April/msg00000.html
[18:35] <seb128> that might interest you as a reading
[18:38] <chrisccoulson> seb128 - thanks, i'll take a look at that shortly
[18:39] <seb128> http://mail.gnome.org/archives/performance-list/2009-March/msg00001.html too
[18:41] <bryce> rickspencer3, http://bryceharrington.org/X/Data/
[18:42] <seb128> there is an interesting comment in this one
[18:42] <seb128> the login only need a part of the schemas and value
[18:42] <seb128> which leads to wonder if the xml could be splitted
[18:42] <seb128> one part read before loading in a quicker way or something
[18:43] <seb128> chrisccoulson: http://mces.blogspot.com/2008/11/improving-login-time-part-2-gnome.html too
[18:57] <halfline> chrisccoulson: hey, so i'm looking at bug 598476
[18:58] <halfline> chrisccoulson: trying to figure out under what conditions this problem happens
[18:58] <halfline> i haven't been able to reproduce at all...
[18:58] <halfline> chrisccoulson: do you think you could get a trace with --sync ?
[18:58] <chrisccoulson> halfline - it wasn't reproducible all the time, even for me
[18:59] <halfline> right, but you'd think i would be able to make it reproducible 100% of the time by adding a sleep in the right place
[18:59] <chrisccoulson> halfline - there'a already a trace with --sync on the bug report
[19:00] <halfline> oh Trace 218314 IS with sync?
[19:00] <chrisccoulson> it is :)
[19:00] <halfline> ohhh yea, i guess XFreePixmap wouldn't normally cause a roundtrip
[19:01] <halfline> i'm basically just trying to get a good understanding on this issue, because it's probably going to have to go to vendor-sec etc as a CVE
[19:02] <chrisccoulson> i need to have a quick look at the code again, because it's been a while since i looked at it
[19:03] <halfline> it's all very strange for me because...
[19:03] <halfline> that gdk_pixmap_finalize is happening in end_implicit_paint
[19:03] <halfline> which makes me think it's the double buffer pixmap
[19:03] <halfline> but that's not going to cause an X error
[19:06] <pitti> good night everyone, have a nice weekend
[19:11] <halfline> chrisccoulson: yea i'm definitely confused.  frame 6 in the trace is just calling XFreePixmap on a pixmap created from the local X connection...
[19:12] <halfline> it's not like a foreign pixmap or anything...
[19:13] <halfline> chrisccoulson: actaully
[19:13] <halfline> chrisccoulson: look at the XID passed to XFreePixmap
[19:13] <halfline> that's a bogus number
[19:14] <chrisccoulson> hmmm, i'm confused as well now :) Where would the bogus number come from?
[19:16] <halfline> it's the xid field of the gdk pixmap object
[19:16] <halfline> so i think we must be dealing with some sort of memory corruption here
[19:16] <chrisccoulson> i am confused now then. i thought i understood it before
[19:17] <chrisccoulson> but the change we've got in ubuntu seems to fix it completely :-/
[19:17] <halfline> right
[19:18] <halfline> but i wonder if it's because of a side effect of code churn
[19:18] <halfline> or changes the timings or something
[19:18] <halfline> don't get me wrong your patch looks reasonable regardless
[19:18] <halfline> i just want to understand this issue and its implications
[19:18] <chrisccoulson> yeah, it would be nice to understand it fully
[19:19] <chrisccoulson> i'll try and take a look at it again at some point, but i won't get a chance tonight
[19:21] <halfline> cool
[19:21] <halfline> i'm going to run it through valgrind and see if it says anythign
[20:15] <bigon> what are the project for emapthy geolocalisation support? will lucid have map and geoclue support?
[20:17] <bryce> does bzr have an equivalent to git show?
[20:17] <bryce> e.g. I'd like to do `bzr show 321`
[20:17] <bryce> bzr diff -r 321 doesn't quite do it
[20:18] <bigon> bzr diff -c ?
[20:18] <bryce> bigon, aha thanks
[20:36] <dobey> bryce: or diff -r 1..2
[20:41] <bryce> dobey, ah, I tried -r 1:2 but it didn't like that
[21:50] <Amaranth> gah
[21:50] <Amaranth> I would have done a compiz upload if launchpad hadn't been down for 12 hours instead of 90 minutes
[21:56] <rickspencer3> bryce, looks like you json isn't quite valid, at least according to python json module
[21:57] <bryce> rickspencer3, oh?  I generated it using simplejson fwiw
[21:57] <rickspencer3> would it be hard to format the pages so that they are on long list of dictionaries?
[21:57] <rickspencer3> hmm
[21:57] <bryce> rickspencer3, shouldn't be hard, no
[21:58] <rickspencer3> is simplejson python?
[21:58] <bryce> currently they're formatted to be readible
[21:58] <bryce> yeah
[21:58] <bryce> import simplejson as json
[21:58] <rickspencer3> well, I think the change would be the page would start with "[", and each }{ would be },{
[21:58] <bryce> ...
[21:59] <bryce> print json.dumps(records, indent=4)
[21:59]  * rickspencer3 tries simplejson
[21:59]  * rickspencer3 assumes it's loads
[21:59] <bryce> which json file in particular are you looking at?
[22:00] <rickspencer3> http://www2.bryceharrington.org:8080/X/Data/upgrade.json
[22:01] <rickspencer3> picked at random
[22:01] <bryce> ok
[22:01] <bryce> yep that one is generated by simplepython
[22:02] <rickspencer3> ValueError: Extra data: line 11 column 1 - line 78 column 1 (char 217 - 1708)
[22:02] <rickspencer3> I am assuming this is caused by finding the } and then WAIT, there's more???
[22:02] <rickspencer3> I'll try fidling with the format a bit
[22:03] <rickspencer3> but I've done lots of json on web clients, so I'm pretty sure this is it
[22:03] <bryce> ohhh
[22:03] <bryce> I see what's wrong
[22:03] <rickspencer3> ?
[22:03] <bryce> I am not printing out the entire structure, but looping over each element and printing a json for it
[22:03] <rickspencer3> right
[22:03] <rickspencer3> so pack them into a list and dump that
[22:03] <rickspencer3> then I can slurp it in
[22:04] <bryce> right, should be easy to fix, hang on
[22:04] <rickspencer3> tx
[22:09] <bryce> there we go, fixed
[22:09] <bryce> try now
[22:09]  * rickspencer3 tries
[22:10] <bryce> most of the rest of the json files will update over the next hour
[22:10] <bryce> the upstream reports will update overnight; I opted not to hammer upstream's bugzilla more frequently than that ;-)
[22:10] <rickspencer3> [{'status': 'Confirmed', 'tags': ['upgrade'], 'importance': 'Wishlist', 'title': 'New upstream 173.14.18 available', 'package': 'nvidia-graphics-drivers-173', 'id': 361856}, {'status': 'Confirmed', 'tags': ['upgrade'], 'importance': 'Undecided', 'title': '[lucid] New nvidia 190.42 driver available', 'package': 'nvidia-graphics-drivers-180', 'id': 404135}, {'status': 'New', 'tags': ['merge', 'upgrade'], 'importance': 'Undecided',
[22:10] <rickspencer3> 'title': 'Please merge nvidia-settings 185.18.31-1 (main) from Debian unstable (contrib)', 'package': 'nvidia-settings', 'id': 417410}, {'status': 'New', 'tags': ['upgrade'], 'importance': 'Undecided', 'title': 'Please update xfs to 1.1.0 version', 'package': 'xfs', 'id': 414272}, {'status': 'Confirmed', 'tags': ['8.10', 'intrepid', 'sis', 'upgrade', 'x.org'], 'importance': 'Undecided', 'title': 'after upgrade to 8.10 (new x.org)
[22:10] <rickspencer3>  SiS driver is not working well (issue with color depth?)', 'package': 'xserver-xorg-video-sis', 'id': 291294}]
[22:10] <rickspencer3> bryce, at your leisure
[22:11]  * Amaranth uploads new compiz that does not depend on compiz-fusion-plugins-extra
[22:11] <rickspencer3> we would factor bug gravity into a separate module so that we can use that on the server
[22:11] <rickspencer3> would = should
[22:11] <bryce> ok
[22:12] <rickspencer3> I'll try to do that while you are out next week
[22:12] <bryce> yeah I'm presently working on extracting brian's code to get a listing of team bugs
[22:12] <Amaranth> so according to seb128 my last two uploads of compiz should have shaved 2.5 seconds off login time :)
[22:13] <rickspencer3> I've got it so that you can add URL search and now the json parsing is working ;)
[22:13] <bryce> btw, xserver 1.7 is still on track for getting in by alpha-1 but it's currently blocked waiting on a few things being done in debian.  Timo's going to keep working on it next week
[22:13] <bryce> rickspencer3, sweet :-)
[22:13] <rickspencer3> so I'll get it loaded into the bugpane next (probably this weekend)
[22:13] <rickspencer3> bryce, great about 1.7 (and thanks to timo)
[22:14] <rickspencer3> I
[22:14] <rickspencer3> it occurs to me that the "Add a URL" UI needs to be a management console thingy, that's take me like 20 minutes to do with couchgrid!
[22:14]  * rickspencer3 steps away from computer for an hour or so
[22:16] <rickspencer3> bryce, btw, the gravity system is in LaunchpadUtils.py in lp:bughgger if you want to give it a whack
[22:17] <bryce> ok will do
[22:17] <rickspencer3> no worries if you don't get to it though
[22:17] <bryce> I just got "team-pkg-list <team>" done
[22:17] <rickspencer3> I'll just stub it out if you don't
[22:17] <bryce> now to see if I can pull some desktop stuff :-)
[22:17] <rickspencer3> sweet!
[22:17] <bryce> need to figure out what everyone's team names are now
[22:17]  * rickspencer3 will try when he gets back
[22:17] <rickspencer3> that's canonical-desktop-team
[22:18] <bryce> aha
[22:18] <rickspencer3> there's code for that in bughugger
[22:18] <rickspencer3> I'll check when I get back
[22:18] <rickspencer3> bryce ... have a great and fun holiday if I don't catch you before you leave today
[22:18] <bryce> ok
[22:19] <bryce> yeah I'll be on later
[22:27] <Amaranth> whee, compiz _still_ fails to build on armel
[22:27] <Amaranth> but the armel buildd is apparently idle because it told me immediately after uploading
[22:28] <Amaranth> still KDE junk
[23:02] <bryce> rickspencer3, if you're back yet... which format do you prefer?
[23:02] <bryce> 1.  Data/<team>/<query>.json
[23:03] <bryce> 2.  Data/<query>/<team>.json
[23:03] <bryce> 3.  Something else...
[23:03] <bryce> fwiw, I've got #1 coded up currently for 'upgrade' bugs:  http://www2.bryceharrington.org:8080/X/Data/