[00:33] http://lists.debian.org/debian-devel/2013/06/msg00720.html scary. 1200 exploitable bugs in wheezy. [00:36] well [00:36] its not clear that there are 1200 bugs [00:36] they're reporting the same library crash in every consuming application. [00:36] It might be 5 bugs. [00:36] dunno yet. [00:43] lifeless: given the number of different packages, that would have to be 5 glibc bugs then though, which would hardly make it any better. [00:48] sure === alex_abreu is now known as alex-abreu [01:01] they aren't all in libraries, here's one that was well and truly our fault: https://lists.ubuntu.com/archives/apparmor/2013-June/003927.html === asac` is now known as asac [04:36] Good morning [04:37] attente: I noticed missing menus in gtimelog and my pygtk test application [04:45] pitti: Good morning. [04:55] pitti: I presume the reason umockdev doesn't have a testbed_add_from_file because no-one's wanted it yet? :) [04:56] RAOF: by and large, yes; I was using add_from_string() [05:05] That's what I'll do. But I'll probably read it from a file, because it's quite big :) [05:09] RAOF: yeah, and umockdev-run does just that [05:10] RAOF: if it's more convenient, I'm happy to add an add_from_file, which will then just pass along any errors as GError [05:10] Yeah, it'd be more convenient. [05:11] We're highly likely to be adding significant numbers of significantly-attributed mock udev devices. [05:28] RAOF: mostly for input, I presume? or do you mock anything else? [05:29] drm, too. [05:30] Device detection, monitor hotplug. [05:30] Although the tense is wrong; *currently* we don't mock anything :) [05:49] RAOF: I filed https://github.com/martinpitt/umockdev/issues/15 as a reminder [05:50] Awesomesauce. [06:27] pitti: Hm. There's no way to destroy a umockdev object from C? [06:27] The Vala class has a destructor; I'm surprised that doesn't get translated to something C-callable. [06:30] RAOF: it's a normal GObject, so you just g_object_unref() it [06:30] RAOF: the destructor gets translated into a normal GObject _dispose() (or maybe _finalize()) [06:30] Ah, that makes sense. [06:31] but one usually doesn't call those directly [07:13] RAOF, will gdm work under XMir? [07:16] darkxst: Not without patches, but that's because gdm isn't really under X now. [07:17] RAOF, well the rendering side of things is... [07:17] But XMir *is* X, so gdm will happily start X as normal. [07:17] darkxst: Oh, yeah. [07:18] So, the answer to ‘will my $X11 client work under XMir’ is “yes”. [07:18] RAOF: btw, do you think that we can expect this patched Xorg going quickly to saucy once we resolved the minor issues around Mir to enter distro? [07:18] RAOF: if you can nuke the separate mir thread xmir would become a lot more acceptable :-) [07:18] mlankhorst: Oh, I'd *love* libmirclient to give me an fd. I think we might be doing that, too. [07:18] RAOF, so when gdm tries to launch a new X server, is it launching X or Xmir [07:19] I assume the latter would require patches? [07:19] darkxst: If it doesn't pass -mir $SESSION_ID to /usr/bin/Xorg, it's starting X. [07:19] Technically, even if it *does* pass [07:19] Technically, even if it *does* pass -mir $SESSION_ID to /usr/bin/Xorg it's starting X :) [07:20] RAOF: I don't think it does atm, though [07:21] mlankhorst: Right. At the moment we're all threads, all the time. I think tvoss_ is amenable to also exporting an eventfd, which should get rid of the annoying thread-to-eventloop hack. [07:22] \o/ [07:22] RAOF: I was thinking something like pulse mainloop [07:22] it may not be perfect, but it's understood [07:22] darkxst: Correct. If you wanted to use XMir+unity-system-compositor from gdm you'd need to patch gdm to (a) start unity-system-compositor, (b) pass the appropriate arguments to X, and (c) send session-switching commands to unity-system-compositor. [07:22] and if you don't want a separate thread you don't need to, afaik [07:22] RAOF, yup, but it will take until next week, my plate is kinda full at this point [07:23] it was awesome for wine, where I do need a separate thread, but I need to create the thread in wine itself [07:24] mlankhorst, the idea is to expose run, run_one, poll, poll_one and have an fd that signals when there is work to do [07:25] tvoss_: yeah pulseaudio does something like that [07:25] mlankhorst, ack, will look into it beginning of next week [07:32] RAOF: ignoring me? :p [07:32] RAOF, ok, that doesnt seem really bad.... but I also guess it wouldnt actually end up being that straight forward [07:32] didrocks: ? [07:32] 09:18:18 didrocks | RAOF: btw, do you think that we can expect this patched Xorg going quickly to saucy once we resolved the minor issues around Mir to enter distro? [07:33] Oh! Yes [07:33] baby [07:33] RAOF, what about further down the track though, when gnome moves to wayland. Would it be possible to have Mir system compositor and Wayland Session Compositor in harmony? [07:39] didrocks: Yes. You don't need anything from me for that to happen except an upload of a patched xserver to the archive, right? [07:39] darkxst: That's less clear; basically what it requires is for GNOME's compositor to have a Mir backend. [07:40] RAOF, that won't happen [07:40] good morning desktopers [07:40] hi seb128 [07:40] I like how opensource dev keep stating that things won't happen [07:40] RAOF: that's my understanding for now. I do expect surprises of course, but I trust at least your side ;) [07:40] when anyone can come and make them happen [07:40] salut seb128 [07:40] RAOF, or to be more clear, a wayland backend rendering to Mir [07:40] darkxst: No. I don't mean for GNOME's compositor to be built on Mir; I mean for GNOME's compositor to be able to run under Mir. Like how Weston can currently run under Weston. [07:41] hey didrocks, tvoss, RAOF, darkxst [07:41] seb128, hey [07:41] tvoss: Except of course that's a misunderstanding of what Wayland *is* [07:41] RAOF, exactly ;) [07:41] There are no ‘Wayland backends’, because Wayland is not a display server. [07:41] RAOF, for sure [07:42] darkxst, I'm curious, do you see any technical issue preventing the GNOME compositor from talking to Mir? [07:43] * RAOF wonders if we could come up with a nomenclature that accurately described the state of things [07:43] tvoss, I don't know a whole lot about the deeper workings of mutter [07:43] darkxst, ah, okay, I thought you were referring to a technical issue when saying that it won't happen [07:43] darkxst: AIUI mutter builds on clutter, which already has a perfectly servicable pluggable backend system. [07:44] but as I understand it, Wayland+X is enough of a pain, that its really unlikely they would add Mir into the mix [07:44] so much of those comments a just direct reaction against change/something different that some people planned... [07:44] Eh. Almost all the pain is in having the abstraction in the first place. Adding an extra target, while certainly annoying, is only incrementally annoying. [07:45] RAOF, +1, and the exercise of adding another target helps in shaping the abstraction layer [07:45] I think the pain in switching away from X is that everything is entangled there for historic reasons [07:45] not sure how realistic it will get to run GNOME on !GNOME-OS over time anyway [07:45] RAOF: diagrams generally help by experience, people can dive to the level they want [07:45] they hard depends on their login manager, they increasingly depends on systemd, they are going to depends on wayland [07:46] didrocks, but RAOF is right, the nomenclature is emphasiizing misunderstandings [07:46] swapping desktops easily is becoming a thing of the past [07:46] tvoss: not disagreeing with this :) [07:46] when your desktop is tied to an init system, a login manager, a display server, etc ... and different desktops pick different techs for all of those you actually end up have distro specific desktops [07:47] ok, just one MIR remaining (liborcus) for Sweetshark, that will wait some hours :p [07:47] * didrocks adds to the confusion on purpose, it's Friday! ;) [07:49] seb128, it actually sounded like they weren't entirely against getting lightdm working with gnome-shell [07:50] * tvoss wonders why a session has to make assumptions from where it was started [07:50] tvoss, it doesn't, until it uses the greeter from the login manager as lock screen... [07:50] tvoss, under gnome, authentication for lock screens etc, is piped to gdm [07:51] darkxst, seb128 wouldn't that be solved more elegantly with a common interface implemented by both gdm and lightdm? [07:51] it would, robert_ancell tried to add a gdm compatible greeter to lightdm [07:51] but I'm not sure he finished, he got busy with Mir :p [07:52] seb128, where is the interface defined? [07:55] tvoss, I'm not sure, the GNOME guys didn't really spec it or made it public/documented ... robert_ancell would know better, I think he just looked a the gdm [07:55] seb128, interesting [07:57] tvoss, https://github.com/robert-ancell/gnome-shell-lightdm [07:57] seb128, okay [07:57] seb128, thx [07:57] yw [07:58] seb128, are you aware of any attempts to standardize the dbus interfaces here? [07:58] no [07:58] I think everyone has been focussing on making their desktop work with the components they picked [07:58] and nobody went out of the way to spend time trying to standardize things or making them swappable [07:59] sure, but the main issue is the authentication channel, gnome-shell renders the lock screen [08:01] hey, happy friday [08:01] in fact gnome-shell also renders the gdm login screen, but that is largely irrelavant for the lightdm use case. [08:02] Laney, hey, happy friday to you too! [08:02] Laney, hi, I am up to happy weekend here :) [08:02] :P [08:03] but you have unhappy monday before me so ;-) [08:04] Laney, usually that is tired monday.... but oh well! [08:05] btw I finally fell off my bike the other day :( [08:05] while trying to look at the map I forgot I was clipped in and tried to put my foot on the floor [08:05] bad idea [08:06] Laney, I fell too, in the dark..... huge bruised and a bit of lost skin... but ready for another weekend! [08:07] MTB in the dark is probably a little dangerous ;( [08:07] yes, yes indeed [08:08] although we don't have much choice, its getting dark by about 5.30pm now === vrruiz_ is now known as rvr [10:05] oh [10:07] since when does launchpad automatically adds packages/lines to bugs when you use "lp: #nnn" to an upload? [10:07] e.g https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1194844 [10:07] Ubuntu bug 1194844 in Ubuntu UI Toolkit "[ListItem.SingleControl] Does not respect the default inner margins" [Medium,Confirmed] [10:07] didrocks, is that launchpad or your daily release magic? [10:07] comment #4 and #5 [10:08] it's a bit funny, that's a toolkit bug [10:08] I just add " *until bug ... is fixed in the ui toolkit" for reference to my comment [10:08] the daily magic added the lp # reference for that bug [10:09] then something added the sources to the bug [10:09] too much magic ;-) [10:10] seb128: that's launchpad :) [10:10] hum [10:10] ubuntu-system-settings-online-accounts and ubuntu-system-settings [10:10] it's quite nice, we got bitten quite often by bugs don't getting closed because of component mismatches between source uploaded and bug [10:10] 2 different packages? [10:10] yes [10:11] online-account is a standalone source [10:11] ah [10:11] you wrote: [10:11] (until bug [10:11] #1194844 is fixed in the ui toolkit) [10:11] so it's been detected as a bug [10:11] and added LP: … [10:11] right [10:11] see the FAQ ;) [10:11] yeah, I got that part [10:11] what confuses me is that something did "also affect ubuntu-system-settings-online-accounts" on the bug [10:12] and set that to fix released on upload [10:12] where in the past uploads on the wrong source would just go to /dev/null [10:12] ah, the also affect is daily release :p [10:12] if it detects bugs to close [10:12] it's opened the components [10:12] ok, so not launchpad [10:12] opening* [10:12] I see ;-) [10:12] yep [10:12] didrocks, thanks [10:12] as a lot of upstreams just opens the upstream bugs [10:12] makes things easier to track [10:12] that makes sense === MacSlow is now known as MacSlow|lunch [11:54] http://forums.mozillazine.org/viewtopic.php?f=23&t=2722493 [11:54] * Laney sniggers [11:59] Laney, O_o [12:02] * xnox likes the 2015 design a lot [12:02] let's vendor patch it in now to be ahead of the curve [12:03] chrisccoulson: ^ make it so [12:03] ubuntu - flatter than apple ! [12:20] does 'signon' need to do an automatic snapshot every day? [12:21] nothing needs to [12:21] but that's the purpose of daily releases [12:21] if there is a commit it's released [12:21] that's try for the whole unity stack [12:21] why? [12:21] but there aren't commits AFAIK https://code.launchpad.net/~online-accounts/signon/trunk [12:22] I don't mind daily releases when minor things change [12:22] seems like a bug [12:22] didrocks, ^ [12:22] oh [12:23] ignore the "oh" [12:23] seems like it think it's own changes are the changes to release again. [12:23] looks like that has been happening a lot! [12:24] pitti, hi [12:24] pitti, which menus are missing from gtimelog? [12:24] yeah, there is a bug somewhere which leads it to think there is a new change to land when there is none [12:25] attente: there is no global menu for it, it has an integrated menu [12:25] attente: hey, how are you? [12:26] I get a global menu for it here but it suffers from the same bug as virt-manager [12:26] pitti, i'm good, and you? [12:26] pitti, my experience is the same as Laney [12:26] attente: I'm well, thanks [12:27] attente: I don't think it's just me, fginther noticed the same [12:27] pitti, do you have integrated menus for any gtk2 app? e.g inkscape or xchat? [12:27] attente: or rather, autopilot-gtk has a test which assumes that the GtkMenuItems are visible [12:27] pitti, you guys maybe don't have the -gtk2 installed? [12:27] yeah maybe you miss unity-gtk2-module [12:27] attente: and it succeeds on saucy, but fails on raring because global menu was working there [12:28] attente, seb128: gtimelog and my test program are both gtk3 and GI [12:28] let's not worry about old gtk2 stuff [12:28] oh, I though that was still gtk2 [12:28] pitti, do you test on raring? [12:28] (don't do that) [12:28] seb128: test what? [12:28] seb128: global menus were working fine on raring, yes [12:28] "it succeeds on saucy, but fails on raring b" [12:28] saucy works? [12:29] seb128: that was my ap-gtk test case which assumed builtin menus [12:29] I fixed the test now to use UBUNTU_MENUPROXY=0 [12:29] can you summarize what work where? [12:29] but that's just how I noticed it, and that it's not just me [12:29] so the summary is: [12:29] - gtimelog had a global menu until raring [12:29] - gtimelog has an integrated (non-global) menu in saucy [12:29] and that looks like a regression to me [12:29] unless there was some policy change or so [12:30] should not [12:30] it works for me (but with the quit item labeled "gtk-quit") [12:30] is u-g-m even available under raring? [12:30] no, ignore raring, I think he's saying that it was working with dbusmenu there [12:31] yes, it was [12:31] the issue is that saucy doesn't work for him [12:31] ah, sorry [12:31] which I can't confirm (out of the "quit" item being wrong labelled) [12:31] the regression in saucy is that some programs don't have a global menu any more, with gtimelog being one example [12:31] good morn, pitti, seb128 [12:31] hey desrt [12:31] desrt, hey, happy friday to you! [12:31] friday :D [12:32] that calls for a coffee to celebrate [12:32] attente, seb128: so maybe fginther and I both have some new package not installed? [12:32] pitti, could be, but it wouldn't be working for any gtk3 app if that was the case [12:32] I guess the underlying mechanics have changed for the global menu? [12:32] right, it's a .so loaded by gtk [12:32] which relies on the env to list it [12:33] but that's true for any app [12:33] that wouldn't explain some apps working and some not [12:33] maybe someone is scrubbing the env? [12:33] chpe tried to do this.... [12:33] well, the same software works for Laney or I [12:33] huh [12:33] i've got the global menu as well.. [12:34] debugging required I guess... [12:34] maybe they got crafty and added exceptions for the usernames who were likely to be packaging it :) [12:34] haha [12:34] pitti, you have the issue on your box, where other gtk3 apps work fine and starting apps the same way? [12:34] seb128: yes [12:34] actually, no [12:34] pitti: does it hide the local menu bar, or is it still shown? [12:34] if I launch gedit from a termina, it also has a builtin menu [12:35] pitti, env | grep GTK [12:35] $ env|grep GTK [12:35] GTK_MODULES=overlay-scrollbar [12:35] buggy [12:35] pitti never logs out/in :) [12:35] so he misses the new envvar :p [12:35] ah... [12:35] seb128: but when I launch gedit from dash, I also get a builtin menu [12:35] OH [12:35] so gedit and gtimelog both have the bug, regardless of whether I launch from dash or terminal [12:35] this _is_ chpe's fault [12:35] pitti, see /etc/X11/Xsession.d/80... [12:35] desrt: I boot my machine every day [12:36] gnome-terminal at some point was scrubbing those environment variables [12:36] it's not related to g-t [12:36] and of course anything you launch from the terminal is a subprocess of the terminal [12:36] for i in /usr/lib/*/gtk-2.0/2.10.0/menuproxies/libappmenu.so [12:36] seb128: ^ that looks gtk2 specific [12:36] pitti, that's deprecated [12:36] pitti: ah sorry. i misread your previous statement about the dash [12:37] pitti: what's $UBUNTU_MENUPROXY? [12:37] $ echo $UBUNTU_MENUPROXY [12:37] libappmenu.so [12:37] that's wrong [12:37] you seems to be missing the conffile for the new unity menus [12:37] grep -r UBUNTU_MENUPROXY /etc/ [12:37] /etc/X11/Xsession.d/80appmenu-gtk3:export UBUNTU_MENUPROXY="libappmenu.so" [12:37] I think maybe 80unity-gtk-module is wrong [12:37] it should just overwrite it [12:38] it seems like he doesn't have it installed... [12:38] $ dpkg -S /etc/X11/Xsession.d/80appmenu-gtk3 [12:38] appmenu-gtk3:amd64: /etc/X11/Xsession.d/80appmenu-gtk3 [12:38] pitti, that's the old stuff, that's deprecated [12:38] did it depend on some unity/gtk thing which got removed? [12:38] pitti, do you have the file Laney just mentioned? [12:38] look /in/ the file [12:39] ah, wait, it should do that right [12:39] Laney, it seems like he's missing the conffile [12:39] or the -common package that includes it [12:39] yeah [12:39] but that's weird, why would menu work from unity then? [12:39] no, I don't have that [12:40] pitti, dpkg -l | grep unity-gtk [12:40] seb128: perhaps that's still using the old dbusmenu stuff? [12:40] which package ships that file? [12:40] pitti, I made gtk2/3 conflict on the old stuff [12:40] pitti, dpkg -l | grep unity-gtk [12:40] indicator-appmenu Recommends them [12:40] unity-gtk-module-common [12:40] so ... you could easily not have gotten it [12:40] seb128: nothing [12:41] pitti, that's your issue, recommends didn't get installed [12:41] pitti, does apt-get --fix-recommends (or whatever that option is called) try to install them? [12:41] * seb128 googles [12:41] --fix-policy --install-recommends [12:41] pitti, ^ === MacSlow|lunch is now known as MacSlow [12:42] that wants to remove appmenu-gtk appmenu-gtk3 and install a gazillion packages [12:42] great [12:42] i thought we had a hard Depends on unity-gtk-module-common? [12:42] "we"? [12:42] no, unity recommends the menu stuff [12:42] because some people want to opt out [12:43] seb128: installing unity-gtk-module-common doesn't remove the appmenu stuff, though [12:43] so we let them uninstall those without removing unity [12:43] pitti, that's ok, it has a conffile that override the appmenu one [12:43] I don't think it matters if it's not removed as u-g-m will take over [12:43] but shouldn't installing unity-gtk23-module force the installation of the -common? [12:43] pitti, we needed that anyway because uninstall != purge [12:43] attente: he didn't have any of it [12:43] if there was an easier way for users to opt out of the global menu then you could make it a depends [12:44] there is an easy way [12:44] change the env variable [12:44] done [12:44] does gtk ignore not found GTK_MODULES? [12:44] not sure, it might throw warning at those [12:44] seems you get a warning ... that file ought to check if the libraries exist then [12:44] Laney: yes, you only get a warning [12:45] well I think dconf is more user-friendly (because it can be a GUI) than messing with environment variables [12:45] right, we should probably add that [12:45] yeah, doesn't seem like u-g-m has any bad dependencies [12:45] file a bug? :) [12:46] like overlay scrollbars have a dconf key :) [12:46] gsettings [12:46] but yeah [12:47] we can maybe add it to gsettings-desktop-schemas :p [12:47] * seb128 hides [12:47] lol [12:47] lol [12:48] * jbicha adds goa dependencies everywhere [12:49] dont forget ubuntu touch ! [12:49] :P [12:50] ogra_, oh, he started there, don't worry [12:50] ah, phew [12:50] :) [12:50] ogra_, GNOMers are eager to get GTK on the device ;-) [12:50] hehe [12:50] (even if it can't get to the screen (yet)) [12:50] XMir might help [12:50] yep [12:51] and who wouldnt want to run evolution on a 4" screen ! [12:52] (in desktop mode at 1080p resolution indeed( [12:52] sounds like the converged way [12:53] needs more whitespace padding :) [12:55] seb128: you said that debian has super-up-to-date gnome these days.... [12:55] i'm seeing only 3.4? [12:56] desrt, http://www.0d.be/debian/debian-gnome-3.8-status.html [12:56] desrt, do you run debian stable? ;-) [12:56] is that sid? [12:56] seb128: i don't run debian anything... was just looking into your claims the other day [12:57] desrt, http://packages.qa.debian.org/nautilus [12:57] technically saucy has more GNOME 3.8 than sid because Debian has transitions that take weeks [12:57] seb128: jbicha: I would say there is a diff between trunk and the source package, ken should investigate I guess (and looking at those :p) [12:57] desrt, experimental for 3.8 atm, though they are moving pieces to unstable [12:58] didrocks, is that flagged somewhere? shouldn't the stack be blocked with manual approval required for those? [12:58] * desrt always gets confused with stable kinda-stable (next), unstable (sid), super-unstable (experimental?), ultra-mega-unstable (testing?) [12:58] what's next? [12:58] desrt, well, experimental was used as an unstable because debian was frozen for 6 months for their release [12:58] desrt, they are getting stuff back to unstable but didn't go too crazy, they do transition decoupled and in order [12:58] seb128: hum, why? the diff means "something changed", it's how it detects there is something to release [12:58] desrt, so it takes a bit of time [12:59] but in that case, it seems that the source package produced by bzr bd -S and trunk is different [12:59] seb128: and where does testing fit in? [12:59] didrocks, I though "packaging changes" would block the publishing for review? [12:59] and that's a packaging bug [12:59] seb128: there is no packaging change, right? [12:59] I thought you diffed the to-be-uploaded source package and the archive [12:59] didrocks, sorry, I misread your "diff between trunk and the source package" [12:59] Laney: no, we diff trunk with the archive [13:00] Laney: I thought this week we can do a 2 stage thing, but we'll have in that case bugs like this spawning [13:00] mmm [13:00] desrt, testing is a transitionnal pocket ... but before release they freeze unstable mostly and transition bits ready from that small set [13:01] seb128: so experimental is the most-unstable one [13:01] thanks :) [13:01] experimental is optional [13:01] desrt, yes stable < testing < unstable < experimental [13:01] for both developers and users [13:01] you don't even get packages from it automatically if you enable it [13:01] Laney: creating the source package needs a pbuilder chroot to be cleaned, it's not something we can do for the 233 components right now without killing the machine [13:02] hence the diff between trunk (ignoring .bzr*/ + diff we ignore) and the archive source [13:02] desrt, stable is like ubuntu stable, testing is like the unstable release nowadays (with extra delay), unstable is like unstable-proposed (where stuff get uploaded, they migrate to testing if they are not breaking the world), experimental is sort of ppa land [13:02] * desrt really likes the ppa model [13:03] debian's getting something like that [13:03] lovely! [13:03] even with 'official' PPAs [13:03] which will be cool [13:03] PPAs are perhaps the coolest of the canonical inventions [13:03] and I think semi-automatic migration from them to the archive [13:03] I wish debian would get ddebs :p [13:03]