=== LordOfTime is now known as LordOfTime|EC2 === TheMuso` is now known as TheMuso === NotAww is now known as Aww [04:46] Good morning [05:07] Good morning! [05:10] pitti: Do you regularly run umockdev tests under valgrind? It seems to generate a *lot* of ‘possibly lost’ [05:10] RAOF: I haven't so far; I guess I should start to do so [05:11] RAOF: yesterday I fixed a bug about leaking an udev_device in uevent synthesis [05:11] (pointed out by alf) [05:11] It might not be your fault; g_type_register_fundamental shows up a lot. [05:11] RAOF: otherwise I'm aware of leaking the fdmaps in the preload, as there is no obvious way when to clean them up [05:12] RAOF: do you get leaks in the "client" application (running under the preload lib), or from the test suite (using the umockdev API)? [05:12] presumably the latter, but the former probably also has some leaks [05:12] Actually, I'm doing both in the same process. [05:12] the preload doesn't use glib, though [05:13] RAOF: anyway, using valgrind sounds like a good idea [05:34] hey Mirv! today, I'll let you for the stacks that needs manual publication? I need to catch up on other work today :) [05:38] RAOF: btw, did you run with G_DEBUG=gc-friendly ? in standard mode, glib's slice allocator will confuse the hell out of valgrind [05:39] RAOF: actually, I think it's G_SLICE=always-malloc [05:39] * RAOF tries [05:42] hm, why don't I get a valgrind report [05:45] ah, it uses LD_PRELOAD itself, so I need to swap this around [05:46] I don't see alf's reported udev_device leak, though [05:47] "valgrind --leak-check=full make check" gives me a leak in make, but nothing else [05:48] pitti: Whereas I still get a whole bunch of possibly-lost even with G_SLICE=always-malloc [05:49] RAOF: right, I think I know what's wrong; umockdev-run sests LD_PRELOAD instead of extending it, fixing now [05:49] I'm trying to run the test suite through valgrind, which ought to report at least one known leak (I reverted the fix) [05:49] Heh. And I'm seeing that because I don't actually use umockdev-run [05:55] RAOF: ok, I see those as well now [05:55] Excellent. [05:56] vala_main(), some g_param_type bits in gobject_init_ctor, etc. [05:56] they go away with G_SLICE=debug-blocks G_DEBUG=gc-friendly [05:56] didrocks: ok, will check [05:56] RAOF: ^ [05:58] RAOF: hm, umockdev_testbed_clear() was added in 0.2.6 already and is in saucy [05:58] RAOF: but I indeed don't get that in devhelp, I'll investiage [06:00] RAOF: argh, forgot to add those to the doc index, sorry [06:00] Heh. [06:00] something to add to the test suite, too [06:01] it's a shame that gtk-doc doesn't play along well with automake 1.13 any more [06:17] RAOF: do the above help? [06:18] pitti: They didn't seem to. [06:18] RAOF: I added a "make check-valgrind" target now, and I don't get the gobject-y leaks with those [06:18] I do get leaks from ioctl_tree* [06:18] ‘LD_PRELOAD=libumockdev-preload.so.0 G_SLICE=debug-blocks G_DEBUG=gc-friendly valgrind --leak-check=full bin/unit-tests --gtest_filter=UdevWrapper\*’ is what I'm running. [06:19] that looks fairly similar to mine [06:19] G_SLICE=debug-blocks G_DEBUG=gc-friendly LD_LIBRARY_PATH=.libs/ LD_PRELOAD=libumockdev-preload.so valgrind --leak-check=full --show-possibly-lost=no -q tests/test-umockdev-vala [06:19] Ah, you're not showing possibly lost. [06:20] ah, no [06:20] That's what I've been seeing. [06:20] I get tons of possibly lost in glib's slab allocator [06:21] RAOF: https://wiki.gnome.org/Valgrind might help, there are some suppression files there [06:22] hm, all pretty old, though === geser_ is now known as geser [07:07] good morning [07:11] salut jibel! [07:11] Bonjour didrocks ! [08:00] g'morning [08:01] Laney, howdy [08:01] hey Laney, seb128! [08:01] good morning everyone ;-) [08:01] didrocks, lut [08:01] how are you guys? [08:01] I've been looking for holiday apartments in lyon/grenoble ;-) [08:01] trying to use tricks to recover some emails [08:02] didrocks, still fighting with lost emails? are they still on the server? [08:02] seb128: they are only locally [08:02] seb128: spent until 11PM yesterday for that :( [08:02] :-( [08:02] going to push you over gmail? [08:03] seb128: I just hate thunderbird a little bit more, yeah :) [08:03] weird bug though [08:03] seb128: I would use gmail if they enable filtering over X- headers [08:03] maybe with google apps script, this would be possible [08:03] you can probably do without it, at least for bugmails [08:04] since the reason is stated in full text at the bottom for the email as well [08:04] well, I tried first at filtering on other things for bugmails [08:04] you can probably filter on that [08:04] but the sentence is changing so much… [08:04] ok... [08:04] if you are the direct assignee [08:04] or assignee because of the team is [08:04] and other stuff… [08:04] it's a mess filtering on this [08:05] at least, I have an idea to recover inbox, sent mails and ML [08:06] I'm suddenly glad I leave mine on the server ... [08:06] it's still really weird that a bug went to delete emails like that [08:06] Laney, well, that's imap, is there any other way? [08:06] yep, like if the settings "remove all emails > 30 days" was set [08:07] (but at least, it didn't compact the folders automatically) [08:07] didrocks, you use imap? [08:08] yep [08:08] yeah, really weird :/ [08:09] didrocks, did you try asking #is if they have backups they can restore? [08:09] seb128: well, I guess this will loose my recent emails in that case [08:09] right [08:09] but you could try to copy those locally [08:09] then ask #is if they can restore the backups [08:10] I'm doing something similar, but the other way around with a fake pop account [08:27] seb128: looks like RAOF is ok with flipping the switch on x1.14 now [08:28] mlankhorst, great! [08:28] so do itt [08:28] RAOF, confirming? [08:28] Yup, should be ok. [08:28] mlankhorst, well, check with didrocks' team since that needs to synchronize with unity [08:28] RAOF, mlankhorst: thanks [08:28] mlankhorst: did you fix the issue of the transition? [08:29] like not being able upgrade xorg 1.14 without taking the new unity? [08:29] didrocks: I still feel it's a bad to have an interdependency between the 2 [08:29] idea* [08:30] mlankhorst: it's not an interdependency, the new xorg breaks old unity, we should avoid people having half an update [08:30] breaking them silently is worse [08:31] didrocks: I feel if anything it should be a conflicts in unity then for xserver-xorg-core < 1.14 [08:32] you can retro-actively change old unity versions [08:32] can't* [08:32] yeah, if people don't take the latest upgrade, they would be broken in a bad transitions [08:32] what's the issue have the new xorg using a Breaks on old unity? [08:32] Breaks seems ok to me [08:32] I told you, the only correct way is the Breaks [08:32] you can drop it after saucy [08:32] ok [08:32] mlankhorst: on the other hand, unity will dep on a new library, right? [08:33] so we can't force newer unity with old xorg? [08:33] yeah I added an explicit depends for that [08:34] excellent, so both ways are handled [08:34] I saw that Mirv just published unity [08:34] so then once xorg is in proposed, we can get brandon's branch merged [08:34] running the tests [08:34] and publish [08:34] I'll add a breaks in xserver for old libxi/libxfixes too then [08:34] Mirv: mind taking care of that ^ (sil2100 did try last week, but the timing was bad) [08:34] mlankhorst: I think it makes sense, yeah [08:37] good morning everyone [08:37] chrisccoulson, hey, how are you? [08:38] hi seb128, i'm good thanks. and you? [08:38] hey chrisccoulson! [08:38] hi didrocks [08:38] chrisccoulson, I'm good thanks [08:39] * didrocks almost finished to hate thunderbird :p [08:39] ah, or maybe no… [08:40] "a folder with this name already exists, please choose another one" [08:40] but I just clicked on "delete"! [08:42] didrocks, it still exists in the mailbox unless you've removed it from the trash as well (assuming you haven't done that yet) [08:43] chrisccoulson: no, the trash was automatically emptied on exit, so it's removed [08:43] chrisccoulson: but the mails were still on the files, I had to recover them by faking a pop account [08:44] and now copying from one to the other one [08:45] didrocks: ok, but which brandon's branch exactly? [08:46] Mirv: bschaefer (without typos \o/) [08:46] I only saw lp:~brandontschaefer/unity/show-desktop-fix as being proposed for unity [08:46] Laney, just for info I looked at your background's panel MR, I'm going to add some comments but not approve it since Ive questions similars to yours ... I would like Ken or some of the UITK guys to comment as well (especially if we use that one as an example on how to do things for other plugins) [08:46] ah, branch [08:47] hum, not that one [08:47] not which brandon, yes, but branch :) [08:47] seb128: yeah good, I thought I'd put it up for discussion [08:47] Mirv: I would say https://code.launchpad.net/~brandontschaefer/unity/move-pointer-barrier-to-xi-1.6.99.1 [08:48] yeah, just saw that, on hold currently. ok.. [08:50] Mirv: it's on hold due to new xorg needed I guess :) [08:50] chrisccoulson: ok, done by the file system directly, much more effective :) [08:51] I think I finally recovered my most important emails and ML \o/ [08:51] didrocks: I'm testing if I can grab libxi/xfixes from debian unstable atm [08:52] I'll monitor when the xorg gets in [08:52] mlankhorst, do you have everything ready for upload otherwise? [08:53] seb128: I was doing some final checks, and noticed that the libxi/fixes were missing the security updates, instead of doing another manual merge I'm looking if the versions from debian unstable work [08:53] in which case we'd be in sync with debian again too [08:53] mlankhorst, ok [08:54] mlankhorst, let me know if you need help for uploads [08:55] seems they build.. testing [08:57] seb128: is there a tool to pull debian packages completely unmodified and stuff them in a ppa? [08:57] mlankhorst, not that I know of, maybe Laney knows a trick though [08:59] mlankhorst: seb128: yes, backportpackage should let you do this [08:59] IIRC anyway [09:01] mlankhorst: try: backportpackage -s unstable -d saucy -u ppa:mlankhorst/ppa mycoolpackage [09:01] you can put -b -B sbuild/pbuilder in there too to test-build locally before uploading [09:03] Laney: that adds a string to version number :( [09:05] what's wrong with that? [09:05] that's what you want for PPA uploads isn't it? [09:05] it's meant to be copied to -proposed [09:05] if it's a sync you can easily re-copy it [09:06] infact if it's a sync you can use copy-package instead of backportpackage to put it in your PPA [09:06] sorry, forgot about that one [09:06] that's from bzr branch lp:ubuntu-archive-tools [09:26] Laney: thanks, copy package works [09:26] np [09:26] I didn't give you the invocation because it's pretty hard to remember :P [09:26] that's why it took so long to respond [09:26] ./copy-package -d debian -s sid --to-distribution=ubuntu --to-suit=saucy --to-ppa=canonical-x --to-ppa-name=x-staging libxfixes [09:27] that's probably the tool to use to copy it from the ppa to proposed too [09:27] seems to have ignored the thing --tos-uit due to typo, meh :p [09:27] at least it builds in saucy so I don't care [09:28] yeah you probably want --to-suite=saucy-proposed ... [09:30] mlankhorst, so, what is missing at this point to be able to start uploading? [09:31] seb128: I need to know the final version number of the first unity that will support the pointer barriers, so I can add the breaks to xorg-server [09:31] you can do <= current-one? [09:31] mlankhorst, didrocks said they would bump the changelog, so << 7.0.2 [09:31] ok [09:31] Laney, that doesn't work fine with daily releases [09:32] didrocks, ^ can you confirm << 7.0.2? [09:32] why? [09:32] yep 7.0.2 [09:32] oh the hard lock got me applications back in the home lens [09:32] Laney, well, I guess it works if you make sure you coordinate unity patch landing [09:33] Laney, but it's easier to bump changelog that to play "guess the daily that will land with the patch" [09:33] ok, final breaks will be [09:33] unity (<< 7.0.2), [09:33] libxfixes3 (<< 1:5.1), [09:33] libxi6 (<< 2:1.7.1.901), [09:33] +1 [09:34] waiting on the builds to xi/xfixes builds to finish, then I'll upload the final xorg-server [09:34] great === vrruiz_ is now known as rvr [09:35] mlankhorst, let me know when the xorg side is ready, I will try the ppa with a custom unity build locally and then we can upload xorg [09:35] ok [09:35] thanks [09:39] you should be able to test the unity build already, just make sure it has a break on xserver-xorg-core << 2:1.14, and a hard depends on the libxi/libxfixes in the x-staging ppa (and corresponding -dev packages) [09:40] mlankhorst, well, I want to test the ppa once it's in "ready for upload" state, but it will have a break on unity << 7.0.2 so I will need that version of unity [09:52] seb128: server build incoming, then [10:02] seb128: it should be ok to test as soon as it's uploaded [10:02] mlankhorst, "uploaded"? you mean it's done building, it needs to be published? [10:02] oh, that's fast [10:02] * mlankhorst was getting a drink [10:03] oops I messed up the dep [10:03] :-( [10:04] retry [10:24] seb128: up for a little bit of NEWing (gnome-desktop-testing)? [10:24] Laney, can do [10:24] sweet [10:24] * Laney goes to upload [10:30] chrisccoulson: Wow I knew firefox were creating an os I didn't realise it would be landing in Ubuntu. Firefox== your friendly event based init daemon :) http://ubuntuone.com/7F7dydbxHaYWMOO0L6TKPI [10:36] have spent the day playing with the FF phone, nice to hold it, nice size phone, very clunky OS . [10:37] have you tried ubuntu touch before so you can compare ? [10:50] would comparing to other $70 phones would show that it's not that clunky after all? [10:51] I haven't tried any FF OS phone yet, althouh saw one live [10:53] seb128: the xorg side should be correct now [10:55] ogra_: I have and it's a lot more intuitive. [10:55] cool [10:55] but that was also on the same phone I use daily [10:55] ugh, out of space [10:55] but having hardware dedicated to it is a nice thing [10:56] definitely [10:56] * ogra_ is sure we'll get there too [10:56] but I kept wanting to swipe and do stuff and it's not what I'd expect [10:56] h indeed [10:56] heh [10:56] good few folks have them here [10:56] here being Florence at europython [10:57] seb128: ok, it should be there now (gnome-desktop-testing in NEW) [10:57] * Laney just built glib including testsuite and forgot to actually include the patch ... [11:00] Laney, hi :) [11:00] Laney, i noticed you touch gnome-bluetooth, were there reports like that yet http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712774 [11:01] Debian bug 712774 in gnome-bluetooth "gnome-bluetooth - abort() on unknown values" [Grave,Fixed] [11:02] ricotz: didn't hear of any [11:02] check LP bugs? [11:03] Laney, havent found a LP bug yet [11:04] Found in version gnome-bluetooth/3.8.0-1 [11:04] we don't have that yet [11:04] Laney, i am hitting it with the current saucy version [11:05] ok, well it has a fixed version there [11:05] triggered by the kernel update to 3.10, 3.8.x worked fine [11:05] maybe you could see if we can take that [11:05] or find the fix and cherry-pick it [11:06] or maybe even updating gnome-bluetooth to 3.8.x? [11:07] yeah, i am currently building it while dropping the consolekit dep [11:07] ricotz, https://blueprints.launchpad.net/ubuntu/+spec/desktop-gnome-3-8 states [11:07] " * gnome-bluetooth [11:07] - Drops fallback applet [11:07] - Drops nautilus-sendto plugin [11:07] - Soname bump [11:07] - Not really needed yet" [11:07] [11:07] so updating seems it's not on the current roadmap [11:07] seb128, right [11:08] finding the change which suppose to fix it then === MacSlow is now known as MacSlow|lunch [11:09] don't really have an opinion on those issues [11:09] the transition isn't big [11:14] Laney, the issue is not so much the transition that the fact it's another update that "features" drop of functionnalities some users use, with no benefit behind [11:14] there is no soname bump [11:15] sure - I don't know what features are in the new version [11:15] new gnome-bluetooths will also likely start pulling bluez5 soon when we want to stay on 4 [11:15] and I'd be happy to receive advice on the other things from ubuntu gnome [11:15] well, it's the Ubuntu GNOME guys who wrote the comments I copied before [11:15] anyway I've no strong opinion on the update, it just seems work for getting nothing but complains back [11:16] so I'm not going to spend time on it, but I'm not going to block others if somebody wants to do it ;-) [11:16] seb128, bluz5 isnt needed for 3.8, but for 3.9.x [11:16] same, but you know the drill when we start missing bug fixes [11:16] ricotz, right, that's why I used futur tense :p [11:16] but yeah the feature drop is enough reason if you care about those [11:16] we sort of care about sendto I think [11:17] we didn't update that one either for similar reasons [11:17] does gnome just not have that feature any more? [11:17] ok [11:18] just to confirm, using the newer gnome-bluetooth fixes this (fatal) error here [11:20] Laney, i presume something like https://git.gnome.org/browse/gnome-bluetooth/commit/?h=gnome-3-8&id=a6ecb2b31f7298041d13a4dd57635a5e40c852bb would fix it [11:20] biab, lunch [11:20] Laney, enjoy ;-) [11:20] ricotz: give it a go [11:28] seb128: can you give the xorg ppa a go? [11:28] Laney, shrug, you could make new packages dh9 instead of cdbs :p (or is pkg-gnome still set on cdbs?) [11:28] mlankhorst, yep [11:47] seb128, Laney, http://paste.debian.net/plain/14122 [11:48] ricotz, thanks [11:49] mlankhorst, where do I find unity with the barrier patch updated? [11:51] seb128, yw [11:52] seb128: oh i thought you were creating one [11:52] hold on [11:53] mlankhorst, I tried, I applied the diff from https://code.launchpad.net/~brandontschaefer/unity/move-pointer-barrier-to-xi-1.6.99.1/+merge/150175 to the current saucy version but that fails to build :/ [11:53] seb128: it should build correctly with the versions in the xorg ppa [11:54] is that rebased on current trunk? [11:54] brb needs to reboot, my laptop is swapping [11:54] mlankhorst, hi [11:54] g'day mate [11:55] mlankhorst, will the xserver package officially gain the xwayland module besides xmir [11:55] I'm not aware of any plans to do so at the moment [11:56] mlankhorst, i see, would be a nice step though [11:56] mlankhorst, i think i saw a rebased version for 1.14 somewhere [11:57] more importantly I do not think the x team is willing to support it at this point :-) [11:58] it would make some people happier ;) [11:59] but of course finally landing 1.14 with the new barriers would be nice [11:59] ricotz: of course, because then it's not their problem [11:59] :P [11:59] while this unity part is blocking updates for edgers in this regard [12:00] mlankhorst, i am counting me in here ;) [12:01] (ah it was a rebase for 1.15) [12:02] back [12:02] If it's upstream I don't see any issues with enabling it, but accepting the xwayland patches means having to support it separately now, I don't see that happening.. [12:03] mlankhorst, so, is there an unity branch with the barrier work on top of trunk somewhere? [12:03] mlankhorst, absolutely, i am hoping it will get merged [12:04] seb128: I tested the patch from debian/patches in https://launchpad.net/~canonical-x/+archive/x-staging/+files/unity_7.0.0daily13.06.24-0ubuntu2.diff.gz [12:04] mlankhorst, thanks [12:04] but only against the 7.0.1 in saucy atm [12:05] the current saucy version is a daily from trunk made yesterday [12:05] so it should be current === MacSlow|lunch is now known as MacSlow === ChrisTownsend1 is now known as ChrisTownsend === greyback is now known as greyback|lunch [12:47] mlankhorst, ok, I found my problem with the unity build [12:47] "/usr/include/X11/extensions/XInput2.h:173:22: error: conflicting declaration ‘typedef unsigned int BarrierEventID’ [12:47] typedef unsigned int BarrierEventID; [12:47] " [12:47] mlankhorst, you need to update the b-d on libfixes as well, not only libxi [12:48] seb128: yeah, but that's for unity [12:49] seb128: besides if you had xorg-server from the ppa installed the wrong versions shouldn't be installing [12:49] installed* [12:49] mlankhorst, I don't, I can't install it without removing unity because of the breaks :p [12:50] which is why I want to rebuild in the first place [12:50] seb128: but yeah the build-deepends for unity need fixing [12:55] seb128: yeah that packaging style is to fit in with pkg-gnome :( [12:56] good morning! [12:58] seb128: but hey if you didn't upgrade out of fear of breaking unity, I would say the thing did its job :P === greyback|lunch is now known as greyback [13:00] Laney, did they say they want to keep this style or did you just assume they want (NEWed in any case) [13:00] mlankhorst, right, but now I would like to test both so we can upload xorg if things work :p [13:00] desrt, good morning to you! [13:01] seb128: the former - it's one of those arguments that I didn't really want to have [13:01] and thanks [13:01] yw [13:01] s/former/latter/ [13:01] let me ask on #debian-gnome [13:05] seb128: happy wednesday [13:06] desrt, thanks ;-) [13:07] larsu: are you following the thread about OnlyShowIn? I'd like your opinion on it. [13:07] the KDE guys seem to be lining up in the 'remove it' column [13:11] desrt, so much hate [13:11] seb128: hm? [13:11] desrt: I'm for removing it as well. Currently compiling a list of apps who use OnlyShowIn=MessagingMenu (that's the only argument *for* it at the moment) [13:11] seb128: actually I think the debate is very productive [13:12] * larsu wishes we had a searchable web service with all .desktop files from the archive [13:13] desrt, people cheering about dropping harmless use of desktop fields... [13:13] larsu, I couldn't care less either way, seems like arguing on details nobody cares about [13:13] seb128: well, their point is that these fields are not harmless [13:13] larsu, sure, GNOME hates customisation and consider anything that let distro change the behaviour as an issue... [13:14] same storing as allowing panels in g-c-c [13:14] seb128: this is only about additional desktop actions [13:14] not about desktop files themselves [13:14] desrt, same story... [13:14] damit, packages.ubuntu.com errors out on contents search :'( [13:15] seb128: not really... nobody is proposing removing OnlyShowIn on desktop files [13:15] seb128: if you have an opinion about this you should state it on the list [13:15] desrt, I've the opinion that it's there, doesn't hurt and can be useful [13:15] I don't care enough to enter into an argument though [13:15] seb128: it's currently hurting, though [13:15] it's not [13:16] it is. transmission is a good example. [13:16] it's hurting GNOME because they are late and they are not in OnlyShowIn [13:16] yeah, it's fine when GNOME screw us [13:16] but they are late on something and need some patches it's not fine... [13:16] seb128: so people should make webpages that OnlyShowIn=IE;Firefox;Chrome;Opera; [13:16] and if someone else is 'late' to the browser game, too bad for them? [13:16] why do we have OnlyShowIn= to start with? [13:16] seb128: i'm sorry -- but this has nothing to do with GNOME [13:16] if that's such a crappy idea? [13:17] seb128: that's exactly what people are asking.... [13:17] desrt, well, your complain is "transmission didn't add GNOME to their OnlyShowIn" [13:17] seb128: didn't add anyone except Unity, really [13:17] desrt, you just said it was not about dropping OnlyShowIn drom .desktop, but then you say it's of no use... [13:17] the KDE people seem to be against this more strongly than jasper is... [13:18] seb128: OnlyShowIn for desktop files as a whole is useful for when those desktop files are desktop components [13:18] I don't see how that's different from .desktop files [13:18] ie: they come as part of GNOME [13:18] you have the same issue for ql [13:18] it's difficult to imagine _part_ of a desktop file being shipped as part of a project [13:18] you can't have features that are desktop specific [13:18] like "open in the dash" [13:18] that wouldn't make sense in gnome-shell [13:18] seb128: if you have arguments, _please_ put them on the list [13:18] not in a side conversation on IRC [13:19] otherwise you don't get to complain when the decision is made against you [13:19] well, the decision will be made against me whatever I think or argue about [13:20] seb128: why do you think that? [13:20] pathetic prophecy [13:20] larsu, because that's how things have been going for over a year [13:21] seb128: desrt and I are trying to fix that... [13:25] seb128: please write to the list. in the amount of time you've spent discussing this on IRC you could have had an email [13:26] larsu, desrt: sorry, I will just trust you guys to do what's right there, I just don't feel like going into another (stupid) argument on lists on why it should be able to told apart a GNOME and an Unity session, seems GNOME guys disagree and I had too many of this discussion recently [13:26] seb128: if you read the list, so far it's one gnome guy saying "why do we have this?" and three KDE guys saying "ya... let's get rid of it" [13:27] desrt, the discussion started off list with "let's drop that", which you argued again, which is why we have the email [13:27] if it wasn't for you they would just have went "screw that field [13:27]