Merge lp:~ev/whoopsie/libwhoopsie into lp:whoopsie
| Status: | Merged |
|---|---|
| Merged at revision: | 495 |
| Proposed branch: | lp:~ev/whoopsie/libwhoopsie |
| Merge into: | lp:whoopsie |
| Diff against target: |
784 lines (+267/-81) (has conflicts) 17 files modified
.bzrignore (+5/-0) Makefile (+35/-7) debian/compat (+1/-1) debian/control (+24/-6) debian/copyright (+20/-2) debian/libwhoopsie-dev.install (+3/-0) debian/libwhoopsie0.install (+1/-0) debian/whoopsie.install (+3/-0) lib/libwhoopsie.pc (+13/-0) src/connectivity.c (+20/-3) src/identifier.c (+44/-5) src/identifier.h (+5/-4) src/monitor.c (+4/-0) src/tests/Makefile (+10/-10) src/tests/test_identifier.c (+25/-8) src/utils.c (+16/-1) src/whoopsie.c (+38/-34) Text conflict in debian/copyright |
| To merge this branch: | bzr merge lp:~ev/whoopsie/libwhoopsie |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Metrics | 2012-05-27 | Pending | |
| Canonical Foundations Team | 2012-05-27 | Pending | |
| Whoopsie Daisy hackers | 2012-05-27 | Pending | |
|
Review via email:
|
|||
Description of the Change
This branch factors out the identifier generation into a new library, libwhoopsie.
The motivation for this is to allow the preferences panel in gnome-control-
The metrics database and the hardware database will also need to generate this exact same identifier (so we can query across all three data sets), and it remains to be determined whether these will use the whoopsie binary to shovel data into their respective backend services.
libwhoopsie provides the following functions:
void whoopsie_
void whoopsie_
void whoopsie_
void whoopsie_
void whoopsie_
whoopsie_
Whoopsie is dynamically linked against libwhoopsie as part of this change. I also have a branch of activity-
Questions:
- Is libwhoopsie an acceptable name, or do we want to further generalize this?
- Should we push whoopsie_
I've also taken the opportunity to fix a few Lintian errors and have debhelper pass the more secure build options via dpkg-buildflags (which is does by default in dh 9). Sorry for the extra diff noise caused by this.
| James Hunt (jamesodhunt) wrote : | # |
- 513. By Evan on 2012-05-31
-
Fixes from James Hunt's review: print an error message if g_network_
monitor_ get_default fails. - 514. By Evan on 2012-05-31
-
Fixes from James Hunt's review: do not deference NULL pointers
- 515. By Evan on 2012-05-31
-
Fixes from James Hunt's review: future proof against g_build_filename returning NULL.
- 516. By Evan on 2012-05-31
-
Fixes from James Hunt's review: do not try to deference and print strings we know to be NULL.
Thanks for the thorough review!
On Wed, May 30, 2012 at 9:23 PM, James Hunt <email address hidden> wrote:
> - shouldn't lib/bson/* be in a separate package? (bug 1006500)
I'll take care of this in a separate merge, but thanks a bunch for
pointing it out.
> - might be worth adding assert() calls for all function arguments?
Fixed (r517).
> - src/connectivit
> - no g_print() if g_network_
Fixed (r513).
> - src/utils.
> - should check uploaded_file before using it with stat() since if
> change_
Fixed (r514).
> - src/whoopsie.c:
> - process_
> - need to check return of g_dir_open() before using 'dir' in g_dir_read_name().
g_dir_read_name will return NULL if it receives a NULL argument.
> - can g_build_filename() ever return NULL?
Fixed (r515).
> - use of crash_file when it is known to be NULL (mark_handled(
Fixed (r516).
> - crash_file is freed even if change_
Fixed by r516 as well.
Comments from Ted:
[16:00:19] <ev> I don't suppose I could have your eyes on https:/
[16:01:37] <ted> Meeting right now, but I can look after.
[16:01:44] <ev> thanks!
[16:43:04] <ted> Uhm, so what are your goals :-)
[16:43:18] <ted> There's a lot of things that glib libraries do like versioned API's
[16:43:33] <ted> That are handy, but chances are libwhoopsie won't be "that big"
[16:44:07] <ted> Also, you're not using autotools, eh?
[16:44:41] <ted> Makes some things a bit tricky.
[16:46:06] <ev> I *hate* autotools
[16:46:19] <ted> Heh
[16:46:20] <ev> I don't care about esoteric hardware or operating systems
[16:46:23] <ev> I want readable code
[16:46:30] <ted> Here's my libdbustest Makefile.am
[16:46:30] <ted> http://
[16:47:09] <ev> yeah, it looks clean, but dragons. If I change things and then it starts complaining about a missing brace.
[16:47:19] <ted> So then I end up with this at my pc file
[16:47:19] <ted> http://
[16:47:59] <ted> It's all clean, as long as you only use the right characters in the right place. What's wrong with doing things right? ;-)
[16:48:23] <ev> heh
[16:48:32] <ted> So, I don't know if you want the API versioned include directory
[16:48:46] <ted> If you do, I'd recommend moving the files to their own directory in the source tree as well.
[16:49:06] <ev> could you put that in the MP? :)
[16:49:20] <ted> Sure, but I guess my question more was: is that your goal? :-)
[16:49:21] <ev> I like having a record of these sorts of things
[16:49:39] <ev> having a versioned include directory?
[16:49:46] <ev> hmm
[16:49:57] <ev> I guess I can't imagine us ever wanting to allow parallel installation
[16:49:58] <ted> Yeah: /usr/include/
[16:50:20] <ev> which is presumably the use case for such things
[16:50:36] <ted> Yeah, it becomes a pain for folks like me that aren't coredev
[16:50:47] <ted> We get yelled at more for making things FTBFS :-)
[16:51:13] <ev> heh
[16:52:15] <ev> what do you mean by it being a pain for non-core dev? I don't see how not having parallel installation makes things FTBFS
[16:52:58] <ted> Because you have something like, let's say libmetrics depend on API version 1. So when version 2 gets uploaded, it breaks. Until libmetrics v2 gets uploaded.
[16:54:15] <ev> ahh
Comments from Colin and Steve:
[16:03:35] <slangasek> ev: why use c99 instead of $(CC)?
[16:03:58] <ev> slangasek: $(CC) with the c99 option?
[16:04:04] <slangasek> if you need to
[16:04:06] <cjwatson> Yeah, you should always use $(CC) for x-compiling support
[16:04:07] <ev> I do
[16:04:19] <slangasek> then yeah, especially now that there's a lib, $(CC) would be a good idea
[16:04:20] <ev> need to use c99 features, that is
[16:04:26] <cjwatson> (not that whoopsie wouldn't need more work for that)
[16:04:44] <slangasek> do you actually have to invoke gcc with -std=c99 to make use of c99 features?
[16:04:46] <cjwatson> no multiarch support?
[16:05:01] <slangasek> I thought you only have to do that to *disallow* code that's *not* c99-compliant
[16:05:02] <ev> ah yes - I hadn't considered that. I was more thinking to hell with people trying to run it under clang
[16:05:14] <cjwatson> we don't care about that for the rest of the distro ;-)
[16:05:19] <slangasek> right :)
[16:05:42] <ev> slangasek: if I run it without, it cries about variables defined in loop constructs
[16:05:43] <ev> if memory serves
[16:06:10] <slangasek> anyway, I'll try to send some more feedback on that merge request... would be good if others could as well
[16:06:15] <ev> thanks!
[16:06:18] <slangasek> it's just the addition of a shared library in C, it won't bite ;)
[16:06:21] <slangasek> anything else?
[16:06:53] <cjwatson> if you haven't already, you should nm -D the shared library to make sure only the symbols you absolutely need are exported
[16:07:21] <cjwatson> and in answer to your earlier question, you should link whoopsie dynamically against libwhoopsie rather than (effectively) shipping two copies
[16:07:53] <ev> cjwatson: ahhh, noted, thanks! dynamically link> thanks bunches for clarifying that. I couldn't find a good answer elsewhere.
[16:08:09] <cjwatson> there's basically hardly ever a good reason to link statically

Hi Evan,
Here are my review comments:
- shouldn't lib/bson/* be in a separate package? (bug 1006500) y.c:setup_ network_ route_monitor( ): monitor_ get_default( ) fails. c:already_ handled_ report( ): file_extension( ) fails, *either* call to free(uploaded_file) could cause a crash. existing_ files() crash_file) and g_print(..., crash_file)). file_extension( ) failed.
- might be worth adding assert() calls for all function arguments?
- src/connectivit
- no g_print() if g_network_
- src/utils.
- should check uploaded_file before using it with stat() since if
change_
- src/whoopsie.c:
- process_
- need to check return of g_dir_open() before using 'dir' in g_dir_read_name().
- can g_build_filename() ever return NULL?
- use of crash_file when it is known to be NULL (mark_handled(
- crash_file is freed even if change_