[00:21] <eliasps> darkxst here are the debdiffs from debian syncs: http://people.ubuntu.com/~eliasps/files/debdiffs/ . Let me know if they are ok. Thank you.
[01:36] <darkxst> eliasps, they are correct, though its probably just as easy to to list which packages can be sync'ed
[01:36] <darkxst> eliasps, clutter can be sru'ed into wily
[01:39] <darkxst> eliasps, can you prepare a bug and paperwork for that?
[01:39] <darkxst> see https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
[01:41] <eliasps> darkxst I'm willing to, but I do need to read the documentation to be sure to understand it and do it right.
[01:48] <darkxst> eliasps, its worth learning, all updates into wily will now require SRU's
[01:49] <eliasps> darkxst, no worries. I'm eager to learn those stuff to get more familiar with this aspect of Ubuntu. So I'll do the reading.
[01:57] <darkxst> eliasps, great!
[01:59] <darkxst> eliasps, just let me know when its ready and I will sponsor for you
[02:00] <eliasps> darkxst Ok, I'll let you know as soon as I'm done!
[04:13] <berglh> are do-release-upgrades working
[04:25] <darkxst> berglh, should be working, atleast not heard of any problems
[04:27] <berglh> okay, i'll apt-get upgrade first
[04:27] <berglh> and give it a crack
[04:27] <berglh> i figure i'm doing something wrong
[04:33] <berglh> highway to the danger zone
[04:53] <darkxst> anyone able to verify the gdm update in trusty-proposed?
[04:53] <darkxst> https://bugs.launchpad.net/ubuntu-gnome/+bug/1315442/comments/15
[05:08] <berglh> darkxst: it works
[05:08] <berglh> it's noticeably snappier for some reason
[05:13] <darkxst> a few people have been mentioning that
[05:14] <mgedmin> hm, is the gjs-console crash going to be a daily event now?
[05:15] <mgedmin> oh right, I re-enabled the "weather" search
[05:21] <berglh> mgedmin: welcome to the bleeding edge
[05:22] <berglh> not sure that i like the new gnome 3.16 top bar/menu separator line
[05:22] <berglh> i think it's cause it's different
[05:23] <berglh> i'll probably just get used to it
[05:23] <mgedmin> my 1st reaction to 3.16 wasn't very positive, but I got used to it
[05:24] <berglh> i think cause it's such a high contrast to the adwaita theme colours it's noticeable
[05:25] <mgedmin> the rather very square blue-on-gray buttons threw me initially
[05:25] <mgedmin> ok, let's say I'd like to reproduce the gjs-console crash under valgrind
[05:26] <mgedmin> I probably want debug symbols
[05:26] <berglh> in 15.04 my background change throughtout the day never worked
[05:27] <berglh> the draw time on context menus is a lot shorter
[05:35] <mgedmin> wait, the crash is from gjs-console running stuff in /usr/share/gnome-documents/js
[05:36] <berglh> for what it's worth i had the same crash
[05:36] <mgedmin> so probably unrelated to the weather search provider
[05:36] <berglh> does it only happen on startup?
[05:36] <mgedmin> it happens when I hit <super> and start typing to launch an app
[05:36] <mgedmin> http://pad.lv/1432098
[05:40] <darkxst> mgedmin, if you can reproduce it under gdb, then grab gjs_dumpstack
[05:40] <mgedmin> it's memory corruption; I'd rather reproduce it under valgrind
[05:40] <darkxst> valgrind won't work if its a JS bug though
[05:41] <mgedmin> I don't think JS can cause memory corruption; it's probably in some C library that JS calls into
[05:41] <darkxst> oh that is the tracker crash
[05:44] <darkxst> cancellable=0x2
[05:44] <mgedmin> uh, how can I dbus-monitor gnome-shell's search chatter
[05:45] <mgedmin> (for me the crash is about free() finding a corrupt 'next' pointer)
[05:46] <mgedmin> ah!  thank you gnome-terminal's builtin search
[05:46] <darkxst> yes, but it is crashing running the sparql query
[05:48] <mgedmin> hm
[05:49] <mgedmin> of course I'm having difficulties reproducing the crash
[05:49] <mgedmin> hey, so uh how does dbus-monitor work?
[05:49] <mgedmin> if I run dbus-monitor destination=org.gnome.Documents, should I see stuff?
[05:49] <darkxst> dbus-monitor --sesion
[05:49] <mgedmin> because if I run dbus-monitor without any arguments, I see
[05:49] <mgedmin> method call time=1445578894.367018 sender=:1.27 -> destination=org.gnome.Documents serial=1274 path=/org/gnome/Documents/SearchProvider; interface=org.gnome.Shell.SearchProvider2; member=GetInitialResultSet
[05:49] <mgedmin> and way too may other junk
[05:51] <darkxst> you might need to set destination and interface
[05:54] <mgedmin> dbus-monitor path=/org/gnome/Documents/SearchProvider works
[05:54] <mgedmin> destination is numeric, now, for some reason
[05:55] <darkxst> can you get the full sparql query and try run that manually? (the one in the trace is truncated)
[05:56] <mgedmin> I'll see what I can do
[05:57] <mgedmin> yes!  repro'd!
[05:58] <mgedmin> terminal 1: gnome-documents --gapplication-service
[05:58] <mgedmin> terminal 2 (within 10 seconds of 1st command): dbus-send --print-reply --dest=org.gnome.Documents /org/gnome/Documents/SearchProvider org.gnome.Shell.SearchProvider2.GetInitialResultSet array:string:"search"
[06:00] <mgedmin> I've got gdb
[06:00] <mgedmin> (but no debug symbols installed yet)
[06:01] <mgedmin> why is gjs-dbgsymn only available for i386???
[06:02] <darkxst> no idea
[06:04] <darkxst> you probably only need glib, tracker symbols etc
[06:07] <mgedmin> uh, what's the command to tell gdb to load symbols that I've just installed?
[06:07] <darkxst> they get loaded automatically when you run
[06:08] <mgedmin> I guess this reproduces easily
[06:10] <mgedmin> I don't see the sparql query in the stack trace: http://paste.ubuntu.com/12900524/
[06:11] <darkxst> its in another thread
[06:11] <darkxst> t a a bt
[06:12] <mgedmin> http://paste.ubuntu.com/12900528/
[06:13] <mgedmin> all threads look rather idle to me
[06:15] <mgedmin> haha I accidentally launched gnome-documents under valgrind without the --gapplication-service flag
[06:16] <mgedmin> valgrind found some things to complain about: http://paste.ubuntu.com/12900543/
[06:17] <mgedmin> ha ha, search succeeds if I run gnome-documents under valgrind
[06:18] <mgedmin> with valgrind errors: http://paste.ubuntu.com/12900547/
[06:19] <mgedmin> libmozjs-24-0v5-dbgsym is also i386-only
[06:22] <mgedmin> Invalid write of size 1 in tracker_parser_unaccent_nfkd_string in function_sparql_unaccent
[06:32] <mgedmin> tracker has two implementations of each
[06:32] <mgedmin> gdb tells me these are used:
[06:32] <mgedmin> https://github.com/GNOME/tracker/blob/3ab7ca19c48052868020452ba0bf504984d63ac4/src/libtracker-data/tracker-db-interface-sqlite.c#L666
[06:32] <mgedmin> https://github.com/GNOME/tracker/blob/ab77180c736d4de8a2b710d0e010807bd4b51c3a/src/libtracker-common/tracker-parser-libunistring.c#L162
[06:33] <mgedmin> I guess valgrind tells me u8_normalize(UNINORM_NFKD, "10", 2, NULL, &written) mallocs a 2-byte array and copies "10" into it (written == 2)
[06:34] <mgedmin> and then tracker_parser_unaccent_nfkd_string(zOutput, &written) helpfully writes a '\0' past the end of the allocated buffer
[06:40] <mgedmin> commented on upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=746195#c6
[07:01] <andy___> Hiya. Is there a reason why ubuntuGNOME 15.10  doesn't pack gnome3.18 with it?
[07:04] <mgedmin> yes: not enough time between the gnome 3.18 release date and ubuntu-gnome 15.10 release date to get it in, with the few volunteers that are working on ubuntu gnome
[07:04] <mgedmin> you can get gnome 3.18 from the staging ppa
[07:05] <mgedmin> otoh I'm curious why gedit is stuck at version 3.10 (!)
[07:05] <mgedmin> for nautilus 3.14 the reason was "3.16 breaks too many ubuntu patches"
[07:05] <mgedmin> is ubuntu patching gedit too?
[07:05] <andy___> Oh okay so it's due to practical reasons, not because of safety or whatever
[07:06] <andy___> because the staging ppa warned me that i could break serious stuff
[07:52] <darkxst> mgedmin, does it help if you drop the addition of null on end of string? I have a suspicion they not meant to be null terminated strings, since always passing the lengths around
[07:53] <mgedmin> wheee system monitor: http://imgur.com/BuIIPLk
[07:53] <darkxst> gedit is the same deal, needs UI patches for CSD and menus
[07:53] <darkxst> I think -desktop team may just give up and go with the CSD version for X though
[07:55] <mgedmin> that big gray area in my screenshot is a SearchBar!
[07:55] <darkxst> lol, where is the search UI?
[07:57] <mgedmin> http://imgur.com/BuIIPLk
[07:58] <mgedmin> ok, scary thing: gtk+ inspector shows a GtkBox with three children: GtkSearchBar (expand=FALSE fill=TRUE), GtkScrolledWindow (expand=TRUE fill=TRUE) and GtkRevealer for the action bar at the bottom (expand=FALSE fill=TRUE)
[07:58] <mgedmin> if the searchbar is expand=FALSE, why is it so big?
[08:04] <mgedmin> https://bugzilla.gnome.org/show_bug.cgi?id=755818
[08:04] <mgedmin> should be fixed in 3.18.0.1
[08:05] <mgedmin> debian testing has 3.18.0.1-1
[08:06] <darkxst> mgedmin, k, will sync
[08:07] <mgedmin> thanks!
[08:11] <mgedmin> (oops I realized I pasted the same imgur link twice; 2nd was supposed to be http://imgur.com/KsxNbwo)
[08:22] <darkxst> mgedmin, done
[08:34] <darkxst> mgedmin, hmm, can't reprodice the crash under jhbuild
[08:35] <darkxst> I just get lots of (gnome-documents:12623): Tracker-CRITICAL **: tracker_parser_unaccent_nfkd_string: assertion '*str_length > 0' failed messages but no crash
[08:43] <darkxst> mgedmin, may be caused by a corrupt index
[09:16] <mgedmin> did you try valgrind?
[09:17] <mgedmin> my gdb shows that function_sparql_unaccent() gets called multiple times
[09:17] <mgedmin> with strings that probably come from document titles?
[09:17] <mgedmin> the 1st one I saw was "10", then I saw a couple of "", then I got bored
[09:18] <mgedmin> those assertion failures oh my
[09:18] <mgedmin> I think tracker_parser_unaccent_nfkd_string: assumes *str_length includes the trailing \0
[09:18] <mgedmin> but libunistring's data model is strings with an explicit length and without a trailing \0
[09:24] <mgedmin> I wonder if it's something special about strings of length 2?
[09:24] <mgedmin> maybe it's strings of length that is a power of 2?
[09:24] <mgedmin> because memory allocators pad
[09:25] <mgedmin> and if you write the \0 into the padding, that probably won't destroy malloc's internal structures
[09:25] <mgedmin> hm, maybe it's not the 2-length string that causes the crash?  it's just the 1st that valgrind detects
[09:30] <darkxst> mgedmin, if that was causing the crash, it would only be seen once most likely
[09:30] <mgedmin> btw tracker didn't crash when I ran it under valgrind
[09:30] <mgedmin> I don't know if valgrind discards invalid writes or what
[09:30] <darkxst> though I do think tracker is wrong to add the \0
[09:30] <darkxst> yes valgrind ignores them
[09:31] <darkxst> well keeps running
[09:31] <mgedmin> I'm worried about the eventual recipients of that string: do they expect a trailing \0?
[09:31] <mgedmin> in this case it's sqlite, and it receives char* + a length
[09:31] <mgedmin> libunistring is a bit vague: https://www.gnu.org/software/libunistring/manual/libunistring.html#In_002dmemory-representation
[09:31] <mgedmin> u8_normalize: https://www.gnu.org/software/libunistring/manual/libunistring.html#index-u8_005fnormalize-723
[09:32] <mgedmin> UTF-8 strings: https://www.gnu.org/software/libunistring/manual/libunistring.html#Unicode-strings
[09:32] <mgedmin> "there are two variants"
[09:32] <mgedmin> I'm guessing u8_normalize is the 2nd: pointer and number of units (not bytes! but for UTF-8 units are bytes)
[09:32] <mgedmin> so no trailing NUL
[09:34] <mgedmin> https://www.sqlite.org/capi3ref.html#sqlite3_value_blob
[09:35] <mgedmin> "If the result is a BLOB or UTF-8 string then the sqlite3_column_bytes() routine returns the number of bytes in that BLOB or string"
[09:35] <mgedmin> -- https://www.sqlite.org/capi3ref.html#sqlite3_column_blob
[09:35] <darkxst> I didnt look too deeply, but usually when functions require passing around str_lengths, they don't expect nul terminated strings
[09:35] <mgedmin> "The values returned by sqlite3_column_bytes() and sqlite3_column_bytes16() do not include the zero terminators at the end of the string. For clarity: the values returned by sqlite3_column_bytes() and sqlite3_column_bytes16() are the number of bytes in the string, not the number of characters."
[09:35] <mgedmin> yeah, I'm just doing due diligence
[09:36] <mgedmin> now: are there any other callers of tracker_parser_unaccent_nfkd_string() in the tracker codebase?
[09:36] <mgedmin> do those callers expect a trailing \0?
[09:36] <mgedmin> git grep says: no other callers
[09:36] <mgedmin> but there are two implementations
[09:36] <mgedmin> and two call sites (in two different implementations of function_sparql_unaccent)
[09:38] <mgedmin> the 2nd call site relies on the NUL terminator!
[09:38] <mgedmin> https://www.sqlite.org/capi3ref.html#sqlite3_result_blob
[09:38] <darkxst> mgedmin, two implementations, because there are two unicode interfaces
[09:38] <darkxst> libunicode and mozilla's icu
[09:39] <mgedmin> "If the 3rd parameter to the sqlite3_result_text* interfaces is negative, then SQLite takes result text from the 2nd parameter through the first zero character."
[09:40] <darkxst> libunistring is the prefered one though
[09:40] <mgedmin> oh but wait two different tracker_parser_unaccent_nfkd_string implementations too
[09:40] <mgedmin> one works in UTF-16, one works in UTF-8
[09:41] <mgedmin> the UTF-16 needs the trailing NUL, the UTF-8 shouldn't do it
[09:41] <mgedmin> wait, I was wrong when I said there was only one caller
[09:41] <mgedmin> process_word_uchar also calls tracker_parser_unaccent_nfkd_string impl
[09:42] <darkxst> that will just abstract the backend away
[09:43] <mgedmin> so, process_word_utf8 also calls tracker_parser_unaccent_nfkd_string()
[09:43] <darkxst> although its all build time ifdefs so shouldnt need that
[09:43] <mgedmin> does it rely on a trailin NUL?
[09:44] <mgedmin> yes
[09:44] <mgedmin> ok, I think this patch has a chance of being correct: http://paste.ubuntu.com/12901327/
[09:50] <darkxst> process_word_utf8 already nul-terminates the string before the tracker_parser_unaccent_nfkd_string() call
[09:50] <mgedmin> but _unaccent_() makes the string shorter
[09:51] <mgedmin> in which case the NUL needs to be moved to an earlier position
[09:51] <mgedmin> git patch with a commit message (but still untested): http://paste.ubuntu.com/12901358/
[09:51] <mgedmin> I've imported the source tree produced by pull-lp-source into a local git repo because I don't know proper tools
[09:56] <darkxst> mgedmin, why the change in the assertion?
[10:01] <darkxst> it doesnt make much sense to accept a zero length string
[10:01] <darkxst> if you don't have a jhbuild setup, the easiest way to test is use a quilt patch against the ubuntu packaging
[10:09]  * mgedmin uploads patch to https://bugzilla.gnome.org/show_bug.cgi?id=746195#c7
[10:12] <darkxst> mgedmin, but still why the change in the assertion (g_return_val_if_fail)? otherwise I think it looks ok
[10:14] <mgedmin> I lost network access
[10:14] <mgedmin> did you not see my explanation, or was it too unclear?
[10:14] <mgedmin> are there channel logs?
[10:14] <mgedmin> !logs
[10:15] <mgedmin> ok, it didn't make it
 because an empty NUL-terminated string would be { '\0' }, so str_length == 1
[10:15] <mgedmin>  but since there's no NUL, an empty string has str_length == 0
[10:15] <mgedmin>  and there's no reason an empty string cannot be unaccentified
 no crash!
[10:15] <mgedmin>  a few Gjs-WARNING **: JS ERROR: TypeError: cursor is null: http://paste.ubuntu.com/12901418/
[10:15] <mgedmin>  valgrind is happy too!
[10:15] <mgedmin>  well, those use of unitialized value warnings in libmozjs
[10:16] <mgedmin> I have jhbuild, but I wasn't sure I could use it
[10:16] <mgedmin> so I built a local deb based on the wily source
[10:17] <mgedmin> oh, right, irclogs lag a lot, so maybe I was too hasty in assuming my explanation didn't make it?
[10:17] <darkxst> I didnt get it first time around
[10:19] <darkxst> mgedmin, its crap, if you really want to accept empty strings drop the assertion
[10:20] <mgedmin> wait, it's a size_t?  oops, unsigned ;D
[10:21] <mgedmin> ah, gsize, but still unsigned
[10:22] <mgedmin> how do I use git with debian packages without going insane?
[10:23] <darkxst> gbp
[10:23] <mgedmin> any blog posts/short tutorials?
[10:24] <darkxst> gbp import-dsc <package.dsc>
[10:25] <darkxst> if you want to do upstream patches there is 'gbp pq' that converts the quilt queue into a git branch
[10:25] <darkxst> gbp buildpackage to build the source
[10:26] <darkxst> I do everything in that
[10:26] <darkxst> expect upstream work, is usually done in jhbuild much faster iteration on builds ;)
[10:27] <mgedmin> step 0: pull-lp-source -d tracker wily
[10:27] <mgedmin> 'gbp pq' fails with gbp:error: No action given.
[10:28] <mgedmin> gbp pq import, I guess
[10:29] <darkxst> yes, they are just the commands, you need options also  ;)
[10:29] <darkxst> I use this script, after gbp import-dsc <debian.dsc>
[10:29] <darkxst> http://pastebin.com/MpejZQU6
[10:30] <darkxst> gives me a debian branch and an ubuntu branch
[10:35] <darkxst> (and falls back to pull-lp-source if there is no packaging branch on bzr)
[10:37] <mgedmin> thank you!
[10:38] <darkxst> mgedmin, the ddeb indexes are broken appparently pitti is looking into it
[10:38] <mgedmin> yeah, I complained on #ubuntu-devel
[10:38] <darkxst> ok
[10:39] <mgedmin> v2 of the patch: https://bugzilla.gnome.org/show_bug.cgi?id=746195#c9
[10:46] <mgedmin> uh, can pull-lp-sources pull sources from PPAs?
[10:49]  * mgedmin realizes he built a tracker 1.4.1-1ubuntu2mg1
[10:50] <darkxst> no
[10:51] <darkxst> pull-lp-source will get 1.4.1-1ubuntu2 form archives
[10:52]  * mgedmin is sad
[10:53] <darkxst> you chdist if you want to pull from ppa's
[10:54] <darkxst> s/you/use/
[10:56] <darkxst> anyway patch is probably ok, would probably be cleaner if _unaccent_ didnt get called with empty strings, but wait and see what martyn says on that
[10:56] <mgedmin> -ETOOMANYTOOLS
[10:56] <mgedmin> calling u8_normalize on empty string is probably also redundant?
[10:56] <darkxst> that may be, but chdist is very useful
[10:56] <Ketsuban> Is there a reason there's no GNOME Builder package available for 15.10?
[10:57] <darkxst> Ketsuban, it will be on gnome3-staging at some point
[10:58] <mgedmin> gnome-builder 3.18.0-0ubuntu1~wily4 is there already
[11:00] <darkxst> mgedmin, I didnt look at the code for u8_normalize, does is just shortcut on an empty string?
[11:00] <mgedmin> AFAIU libunistring is a GNU library, which means it's not on github
[11:01] <darkxst> it will be on git somewhere!
[11:01] <mgedmin> https://codesearch.debian.net/results/package:libunistring%20u8_normalize/page_0
[11:01] <mgedmin> wheeee http://sources.debian.net/src/libunistring/0.9.3-5.2/lib/uninorm/u8-normalize.c/?hl=33#L33
[11:02] <mgedmin> no short-circuiting: http://sources.debian.net/src/libunistring/0.9.3-5.2/lib/uninorm/u-normalize-internal.h/
[11:07] <mgedmin> ha ha icon sizing is a hard problem: http://imgur.com/O96xsgv
[11:10] <darkxst> I thought they unbroke that, guess not
[11:10] <mgedmin> looks like https://bugzilla.gnome.org/show_bug.cgi?id=738467
[11:10] <mgedmin> hm, it's old!
[11:11] <darkxst> yeh, I thought they fixed the lack of force-scaling
[11:11] <darkxst> since it broke legacy icons all over the place
[11:12] <darkxst> I gtg anyway
[11:12] <mgedmin> o/
[11:12] <mgedmin> gvim is often THE LARGEST ICON EVER, but it's properly force-scaled in system-monitor
[11:12] <mgedmin> maybe some icons are exactly the right size to be a bit too large but sneak in under the limit?
[11:17]  * darkxst sleeps now
[12:38] <mgedmin> waah exciting new bugs
[12:44] <mgedmin> gnome-contacts crashed for no reason
[12:44] <mgedmin> oh, in the search provider
[12:44] <mgedmin> segvanalysis: "Skipped: missing required field Disassembly"
[12:44] <mgedmin> DAMN YOU APPORT
[12:45] <mgedmin> I had a bug open about this
[13:18] <jokx> Hi, a little question : I've installed Ubuntu-Gnome Wily + ppa:gnome3-team/gnome3, but Eye-Of-Gnome and Evince show me an horrible menu in place of the normal header bars ... I think that modification is done for Unity, but for gnome user : is there a way to recover un-patched application ?
[13:20] <jokx> Or at least : removing that menu et get back the normal header-bars ?
[14:38] <eliasps> darkxst how do I describe a testcase for clutter's sru in the bug report, also a regression potential.
[14:39] <eliasps> I saw some bug reports with similar requests and they don't have those subjects on the description.
[14:56] <eliasps> darkxst there is also a depencency issue for clutter and wily: libcogl-dev doesn't meet the required version
[15:28] <ricotz> darkxst, hi, I am going to copy the gnome3-staging wily pocket to xenial
[16:14] <eliasps> I'll test the syncs in a personal PPA before sending you them for uploading in staging.
[17:50] <guruprasad> I have been using Debian unstable (with the GNOME desktop environment) as a rolling release for the past 2 years without any issues. Recently there are many transitions happening in Debian unstable and upgrading regularly may not be such a good idea. So I just thought I could try Ubuntu flavours again (after using Ubuntu for 5 years prior to Debian)
[17:51] <guruprasad> I am thinking about trying Ubuntu GNOME which will help with continuity but I am not keen about waiting till the next release for the latest and greatest
[17:52] <guruprasad> So is there a way to use Ubuntu GNOME as a semi-stable (at least not as unstable as Debian unstable) rolling distro?
[21:02] <guest231015> Why has the logo changed to a Shazam like logo?