Re: [Elementary-dev-community] Hi!
On Thu, Sep 25, 2014 at 7:20 AM, Erasmo Marín erasmo.ma...@gmail.com wrote: Also, the guys at shotwell are accepting patches and contributions, but they are not extending shotwell any more, so you have better chances to get your branch accepted here, and photos is a more active project. I'm not sure how Shotwell can be accepting patches and contributions and yet contributors not have a good chance of their branch being accepted. Your logic is specious. If you contribute to Shotwell, your branch and patches have as good a chance as anywhere of being accepted. Yorba has high interest in the community growing Shotwell. We do not blow off contributions. If anything, we're eager to accept them. Also know that your work on Shotwell will be available for all GNOME Desktops, including Ubuntu, Fedora, Mint, and more. No matter what's said here, Shotwell remains the most-used photo manager in Linux today. -- Jim -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Hi!
There's a lot of Shotwell is dead talk out there, which isn't true. I would love it if more contributors would throw patches our way; it doesn't help if people are saying Don't bother, Yorba's dropped Shotwell. We've done a lot of hard work on Shotwell, now we're asking the community to step up and contribute too. -- Jim On Thu, Sep 25, 2014 at 1:24 PM, Erasmo Marín erasmo.ma...@gmail.com wrote: Hi Nelson, sorry if I make it sound like if you are not interested in community, I'm sure you are, It's just my opinion of how it looks from outside. Photos is changing a lot in the trunk branch, so looks more open to big changes in the future (gui and functionally), while shotwell looks more like a finished product, very stable. Looks like both projects are in different steps in the software life cycle. Also, you make a point. Shotwell is available in more distributions, like Ubuntu, and that's attractive for contributors too. I don't want to start a fight or something like that :). Both projects can benefit each other. Greetings and sorry for my English if I did any mitsake. El sep 25, 2014 2:43 PM, Jim Nelson j...@yorba.org escribió: On Thu, Sep 25, 2014 at 7:20 AM, Erasmo Marín erasmo.ma...@gmail.com wrote: Also, the guys at shotwell are accepting patches and contributions, but they are not extending shotwell any more, so you have better chances to get your branch accepted here, and photos is a more active project. I'm not sure how Shotwell can be accepting patches and contributions and yet contributors not have a good chance of their branch being accepted. Your logic is specious. If you contribute to Shotwell, your branch and patches have as good a chance as anywhere of being accepted. Yorba has high interest in the community growing Shotwell. We do not blow off contributions. If anything, we're eager to accept them. Also know that your work on Shotwell will be available for all GNOME Desktops, including Ubuntu, Fedora, Mint, and more. No matter what's said here, Shotwell remains the most-used photo manager in Linux today. -- Jim -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Picking Up Shotwell Development
Hello everyone, I just want to add to Daniel's announcement that I'm pleased to see elementary take up this torch and run with it. Shotwell is an important piece of software for me, both personally (as someone who devoted many hours to crafting it) as well as speaking as a Yorban. As Daniel mentioned, I'll be available to discuss the how's and why's behind Shotwell's code and design and offer any guidance I can. I don't want to impose as a guiding hand and tell people how things should be done. I will say that most decisions we made with Shotwell involved weighing alternatives as well as taking input from our users and confronting technical limitations. Please feel free to ask to consult me! Chances are we here at Yorba know about the problem and have some insight about related pitfalls. Although slightly out-of-date, I do recommend anyone diving into Shotwell take a look at our architecture overview: https://wiki.gnome.org/Apps/Shotwell/Architecture I've also subscribed to the Pantheon Photos bug list and will probably be chiming in from time to time with notes. I think this move is beneficial to elementary, Yorba, and our collective users. Here's to the future of photo management on the Free Desktop! -- Jim On Fri, Jan 24, 2014 at 12:13 PM, Daniel Foré dan...@elementaryos.org wrote: Hey Team, I’ve been talking to Jim Nelson (President of Yorba) about Shotwell for a while now and here’s the quick and dirty: Shotwell needs a new maintainer. Ubuntu has the Gallery app, Fedora has GNOME photos, and Yorba just doesn’t have the resources anymore to maintain Shotwell. Their focus is on Geary. So that pretty much leaves us or an unknown to take up the mantel. Jim seems really excited about the idea of Shotwell becoming a part of our community. He thinks we have the talent and the vision to bring it up to date and make it into a really great app. But there’s a small caveat: Yorba recently joined the GNOME development community. So officially, development is done in GNOME git and bugzilla and their wiki, etc. Which is obviously not ideal for us. Enter the solution: After some discussion with Jim, we think the best course of action is for elementary to fork Shotwell. I’ve taken the liberty of setting up a launchpad page for Pantheon Photos. It is currently maintained by elementary-apps team, but I think we’ll want to create a Pantheon Photos team as Jim wants to stay in the loop on development, but we don’t want to spam him with all the other elementary apps stuff. Firstly, I know that this is a big responsibility to take on. I think as a community, we can do it. Having Photos in launchpad and under the umbrella of the elementary apps team will allow us a lot more freedom for casual involvement with the code base. Not to mention, Jim has already stated that he is available to answer anyone’s questions or give guidance regarding how Shotwell’s code is structured, things to watch out for, etc. I think this is going to be a really positive move for our photos app and I’m looking forward to working with all of you on building a really great Photos experience in elementary OS. -- Best Regards, Daniel Foré elementaryos.org -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] App Center Status
Speaking of the Elementary App Center, has there been any discussion about leveraging some of the work that Richard Hughes has done for the GNOME Software Center? -- Jim On Tue, Oct 1, 2013 at 5:05 PM, z...@zaneswafford.com z...@zaneswafford.com wrote: Hey Guys, I'm looking to make an application using the Vala / Gtk / Granite stack and was wondering about the status of the Elementary App Center. I've seen the launchpad page and article about it that was posted back in March. Has there had been further discussion or groundwork laid-out in regards to selling commercial software? Is there a guess at the ETA? Thanks for any and all assistance, - Zane -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Donate to Yorba
Hey guys, We're doing an all-or-nothing campaign, like Kickstarter. IndieGoGo does offer a flexible funding model, but as you pointed out, they eat a larger chunk if you don't make the goal. See http://support.indiegogo.com/entries/20566503-Fixed-vs-Flexible-Funding I can answer any other questions as well! -- Jim On Mon, Mar 25, 2013 at 1:21 PM, Cassidy James cass...@elementaryos.org wrote: They get the money no matter what (unlike Kickstarter). The difference is the fee that IndieGoGo takes: 4% of the donations if the goal is reached, 9% if it's not. Source: http://www.indiegogo.com/indiegogo-faq On Mar 25, 2013 3:18 PM, Daniel Foré dan...@elementaryos.org wrote: As far as I know, they only get the money if they make $100k Yea I was also thinking somewhere in the realm of $100 On Mon, Mar 25, 2013 at 1:15 PM, David Gomes da...@elementaryos.org wrote: 100,000$ is a lot of spaghetti! I didn't even know we (elementary) had money, but if so, I don't see why we shouldn't donate something like 50-100$. I don't know indiegogo works, but do they also get the money if they don't make 100,000$? I'm afraid that they won't get 100,000$, even though I'd like that very much. On Mon, Mar 25, 2013 at 8:12 PM, Daniel Foré dan...@elementaryos.org wrote: Hey everyone, Yorba just launched their crowdfunding campaign on IndieGoGo. As you all know, we ship two of their apps default, so we definitely owe them in terms of making our desktop complete and functional. I'm wondering if we shouldn't donate (as elementary) to Yorba's campaign? And if so, how much? Here's the link to their IndieGoGo page: http://www.indiegogo.com/projects/geary-a-beautiful-modern-open-source-email-client Please share it and feel free to donate on your own as well :) Best Regards, Daniel Foré elementaryos.org -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Best Regards, Daniel Foré elementaryos.org -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Granite and Geary
I apologize for the overdue response, we've been busy here with Shotwell and Geary and, as you may've heard, the crowdfunding campaign we'll be starting shortly. Victor, I hope you're still up for taking on this project. I should tell you, today I've removed Granite support from Geary. As you can see, it wasn't much: http://redmine.yorba.org/projects/geary/repository/revisions/45aca6d22cfcbebe2bfc526d6c346b81bdd908df Looking over the suggestions so far in this conversation, I think Welcome Screen is a good starting point, with one caveat. Geary today already has a Welcome dialog that allows the user to type in their email particulars and get started. Would the Granite Welcome Screen replace this or simply be shown before our Welcome dialog? The one nice thing about Welcome Screen is (I think) there's an easy way to hook this into the application, so it should be fairly effortless. We're pretty darn busy around here, but I do want to get started on this. Victor, I recommend cloning our git repo on your local machine (or github, or Launchpad, or wherever you like, I suppose) and begin hacking on Geary to add the Welcome screen. I suggest the following steps: 1. Add a ./configure option to enable Granite support, i.e. --enable-granite-support. Look at --enable-ref-tracking to see how to do this. 2. Again using ref tracking as a model, add GRANITE_SUPPORT to the valac command-line if the configure flag is set. This means we can use #if GRANITE_SUPPORT (or whatever name we pick) in the code. 3. Create a src/client/granite directory. 4. Create a geary-granite-application.vala file in that directory. Add it to the CMakeLists.txt file so it's built with the client code. 5. GearyGraniteApplication should subclass GearyApplication. The entire class should be surrounded by #IF GRANITE_SUPPORT. 6. In src/client/main.vala, instantiate GearyGraniteApplication rather than GearyApplication using #if again. This is my general game plan. With this basic framework in place, you can start hanging Granite-specific code off of GearyGraniteApplication. In the future, as hooks may be needed, GearyApplication (or its other classes) can be modified to suit your needs. When Elementary builds Geary, their packaging should use the flag you've added. If all works well, we'll have a Granite-enabled Geary application. Does this sound good? Let me know! Feel free to ping me if you have questions. It might take a while, but I'll do my best to get back to you. -- Jim On Tue, Feb 26, 2013 at 11:33 PM, Victor victoredua...@gmail.com wrote: Hi Jim, Sorry for the late response! In regard to your question, I would like to start working on the welcome screen because it's easier to implement and doesn't require adding many new abstractions. I'd also work on Granite to add the features needed by Geary, as I had already mentioned in the respective issue/ticket. Adding code to have Geary use Granite's Source List (A.K.A. sidebar) implies a lot of work, since the APIs are very different. You can have a look at Granite's API here: http://pastebin.ubuntu.com/5559185/. Being the developer who implemented Granite's Source List, I know how to make Geary's sidebar have an elementary-like look on top of your current API, and I'm already familiar with Geary/Shotwell's Sidebar implementation, but I doubt this is the approach you want elementary to take here. Before jumping into coding I would like to have a technical discussion regarding the design implications of these changes in order to gather all your opinions and suggestions. I know that you are very busy, and I don't want to take a lot of time away from you. So, is there any specific time when I can meet you up, introduce myself, and discuss this? Have a nice day and thank you for your time, Victor. On Thu, Feb 21, 2013 at 6:08 PM, Jim Nelson j...@yorba.org wrote: Hi Victor, No one else has come forward, so it looks like you have the field! I don't think more than 2 days a week are necessary here. Mostly it's about maintaining a few slight changes to the code, not a big overhaul. Let's start by discussing what Granite changes you (or the Elementary team) want to see in Geary. We can prioritize those and go from there. These are the outstanding Granite tickets in our Redmine tracker: About Box - http://redmine.yorba.org/issues/6089 Welcome Screen - http://redmine.yorba.org/issues/6090 DecoratedWindow for composer - http://redmine.yorba.org/issues/6112 I'm sure there's more, this is just a starting list. Anyone want to pitch in more ideas? -- Jim On Sat, Feb 9, 2013 at 12:34 PM, Victor victoredua...@gmail.com wrote: Nice suggestions Jim. This champion will need to check in from time to time, either adding additional Granite support or patching Geary to work with changes to the Granite API I would not like to assume this responsibility alone, but I'd definitely like to contribute
Re: [Elementary-dev-community] Granite and Geary
Hi Victor, No one else has come forward, so it looks like you have the field! I don't think more than 2 days a week are necessary here. Mostly it's about maintaining a few slight changes to the code, not a big overhaul. Let's start by discussing what Granite changes you (or the Elementary team) want to see in Geary. We can prioritize those and go from there. These are the outstanding Granite tickets in our Redmine tracker: About Box - http://redmine.yorba.org/issues/6089 Welcome Screen - http://redmine.yorba.org/issues/6090 DecoratedWindow for composer - http://redmine.yorba.org/issues/6112 I'm sure there's more, this is just a starting list. Anyone want to pitch in more ideas? -- Jim On Sat, Feb 9, 2013 at 12:34 PM, Victor victoredua...@gmail.com wrote: Nice suggestions Jim. This champion will need to check in from time to time, either adding additional Granite support or patching Geary to work with changes to the Granite API I would not like to assume this responsibility alone, but I'd definitely like to contribute; count on me for this. I am only available two days per week though: Wednesday and Thursday. On Thu, Feb 7, 2013 at 6:03 AM, Hakan Erduman ha...@erduman.de wrote: Hello Jim, First, I'm not involved in the development of granite, midori or any elementary project. As a bystander and developer I wonder why you did not try to reap the experiences of the midori project first. Midori pre-dates elementary and yet there is full integration - I wonder how they achieved it and so should you, I think. Secondly, as a fellow developer of a small and notoriously underpowered free software project, I used to track every ubuntu release and found that a six month cycle is often too narrow. Tracking the LTS releases only is a very sound decision of the elementary project, I think. Please consider the decision. Just my $0.02, no offence meant. Regards, Hakan Jim Nelson schrieb am 06.02.2013 22:16: Hello all, I'm Jim Nelson, executive director of Yorba and technical lead of Geary. I've been communicating a little bit with Daniel about the future of Geary. He asked I share my thoughts with all of you. First of all, I'm excited that Geary is the default mail app for Elementary, the first distro to adopt, which is always an honor. It also represents the kind of risk-taking that smaller distros will take, and I appreciate that. However, as much as Yorba values what Elementary is bringing to the open desktop, we can't target Geary solely for it. More specifically, I'm uncomfortable targeting Geary for Granite. The Granite API seems to be fluid right now. Yorba's policy for all our apps is to build on the current release of our dependencies, as well as the prior release, in the GNOME six-month cycle. In practice, this means depending on the libraries in the current release of Ubuntu and the prior one. For example, right now Geary builds on Precise and Quantal. (It may build on older versions, but we don't guarantee that.) At some point in this cycle we'll move to Raring. Geary *may* build on Precise indefinitely, but if we need something in a library that wasn't available in Precise, then so be it. This model means that our users don't have to be using the absolute latest-and-greatest, but also means we can take advantage of more-or-less the newest stuff. It also means we don't fill our code base with conditionally-compiled patches to support newer library features while maintaining support for older ones. Another policy Yorba adheres to is that we want trunk (master) to build, always. This is quite important to me. So here's our conundrum: Geary today has a sliver of Granite support #ifdef'd in. It compiles under Precise but not Quantal due to some deprecated symbols. I know more work on Granite is coming, which means Geary will fall farther and farther behind without active maintenance. And we do have a number of requests for additional Granite support. The umbrella ticket for that work is at http://redmine.yorba.org/issues/6088 We don't want that to happen. We also don't want to fill Geary with a lot of conditional compilation code to support Granite. So, as I said: a conundrum. What I'm proposing is for a member of the Elementary community to step forward as a Geary champion: someone to actively work on a Granite version of Geary. I propose doing that via two tried-and-true techniques of modern software development: object-oriented code and distributed source control. To break it down: * We'll work with this champion to refactor the Geary client in such a way that subclasses can hook into various events and provide Granite-specific UI elements over generic GTK elements. * This champion will write the Vala code that subclasses Geary's client and calls Granite. * Where this code lives is up for discussion. One path is for this champion to fork Geary (i.e. on Launchpad) and add the Granite code to the fork. Another
[Elementary-dev-community] Granite and Geary
Hello all, I'm Jim Nelson, executive director of Yorba and technical lead of Geary. I've been communicating a little bit with Daniel about the future of Geary. He asked I share my thoughts with all of you. First of all, I'm excited that Geary is the default mail app for Elementary, the first distro to adopt, which is always an honor. It also represents the kind of risk-taking that smaller distros will take, and I appreciate that. However, as much as Yorba values what Elementary is bringing to the open desktop, we can't target Geary solely for it. More specifically, I'm uncomfortable targeting Geary for Granite. The Granite API seems to be fluid right now. Yorba's policy for all our apps is to build on the current release of our dependencies, as well as the prior release, in the GNOME six-month cycle. In practice, this means depending on the libraries in the current release of Ubuntu and the prior one. For example, right now Geary builds on Precise and Quantal. (It may build on older versions, but we don't guarantee that.) At some point in this cycle we'll move to Raring. Geary *may* build on Precise indefinitely, but if we need something in a library that wasn't available in Precise, then so be it. This model means that our users don't have to be using the absolute latest-and-greatest, but also means we can take advantage of more-or-less the newest stuff. It also means we don't fill our code base with conditionally-compiled patches to support newer library features while maintaining support for older ones. Another policy Yorba adheres to is that we want trunk (master) to build, always. This is quite important to me. So here's our conundrum: Geary today has a sliver of Granite support #ifdef'd in. It compiles under Precise but not Quantal due to some deprecated symbols. I know more work on Granite is coming, which means Geary will fall farther and farther behind without active maintenance. And we do have a number of requests for additional Granite support. The umbrella ticket for that work is at http://redmine.yorba.org/issues/6088 We don't want that to happen. We also don't want to fill Geary with a lot of conditional compilation code to support Granite. So, as I said: a conundrum. What I'm proposing is for a member of the Elementary community to step forward as a Geary champion: someone to actively work on a Granite version of Geary. I propose doing that via two tried-and-true techniques of modern software development: object-oriented code and distributed source control. To break it down: * We'll work with this champion to refactor the Geary client in such a way that subclasses can hook into various events and provide Granite-specific UI elements over generic GTK elements. * This champion will write the Vala code that subclasses Geary's client and calls Granite. * Where this code lives is up for discussion. One path is for this champion to fork Geary (i.e. on Launchpad) and add the Granite code to the fork. Another path is for this code to live in the Yorba repo and is activated via a configure switch. (Yes, this is conditional compilation, but the idea is to conditionally compile in *files*, not fill the existing files with #if's.) We're doing something similar to support Ubuntu's Messaging Menu and Unity task bar. * Elementary will need to build Geary in a PPA that enables this configure switch. * This champion will need to check in from time to time, either adding additional Granite support or patching Geary to work with changes to the Granite API. If the code lives on in the Yorba repo, we'll take those patches more or less as-is. In other words, this champion (and, by extension, Elementary) is taking responsibility for this code. The result of these steps, and the goal of this email, is to (a) make Geary a full-fledged member of the Elementary desktop, (b) keep Geary working on other desktops where Granite is not installed or is an older version, and (c) allow Elementary to make rapid changes to Geary so it represents Elementary's latest efforts. This above is a proposal and not set in stone. Comments and questions are welcome. Thanks, -- Jim -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Geary
Ah, that makes sense. I was trying to add a second team/user as a bug supervisor for Geary. I created a Yorba Bug Team and added yorba and rabbitbot-a. I think we're good to go. Thanks! -- Jim On Mon, Sep 17, 2012 at 12:59 PM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: Hi Jim, Yes, there is, though it's not obvious. You can set a bug supervisor (person or team) for Geary project at its bugs page, see attached screenshot (I've used a project over which I have control as a sample). See https://help.launchpad.net/Bugs/YourProject#Bug_supervisors for details on bug supervisor's privileges. I recommend creating a Yorba bug management team with ~yorba and ~rabbitbot-a as the only members. Such setup has proven to be quite flexible and future-proof here at elementary. 2012/9/17 Jim Nelson j...@yorba.org Hi Sergey, I've activated Geary's bugs on Launchpad. I went through the process of adding Rabbitbot-a to the Yorba team just to see what kind of fine-grained control I would have, but it appears there's not much -- it's either Admin or Approved, and I can't focus it as a bug maintainer specifically on Geary, but apparently on all Yorba projects and PPA. Is there some way to make rabbitbot-a a bug maintainer specifically for Geary? -- Jim On Fri, Sep 14, 2012 at 1:06 PM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: Thanks Jim! I've noticed the Geary project in Launchpad still doesn't have bug tracking enabled; you'll have to enable it at https://bugs.launchpad.net/geary to give Apport a place to submit the reports to. Since crash bugs are private by default, the maintainer of https://launchpad.net/geary should be set to https://launchpad.net/~yorba so that you can access the generated reports; at the moment only Eric can do that (CC'd). Assuming you'll use our crash retracers, you'll also have to add https://launchpad.net/~rabbitbot-a to the team set as bug supervisor (or maintainer, if bug supervisor is not set) of the Launchpad project if you wish to receive crash reports from systems other than elementary OS. -- Sergey Shnatsel Davidoff OS architect @ elementary -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Geary
Sergey, I know this has been a while, but I've been fighting fires and fixing bugs and had to put this off. I've committed your patches and they should be available in our next daily build. http://redmine.yorba.org/issues/5696 http://redmine.yorba.org/issues/5697 Thanks! -- Jim On Wed, Aug 22, 2012 at 5:28 AM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: 2012/8/22 Eric Gregory e...@yorba.org Apport's traces could be quite helpful. We do have a PPA for daily builds for Geary and Shotwell. Would that help? How do we enable it? The daily build PPA is here, if that helps: https://launchpad.net/~yorba/+archive/daily-builds/ First of all, you'll need to make debugging symbols for Geary available from the PPA in addition to the stripped binary. In Debian/Ubuntu they're shipped in a separate -dbg package (e.g. geary-dbg). I've attached a patch that adds the geary-dbg package and also bumps debhelper version requirement to 8, as instructed by lintian. (By the way, I wrote an automated script for adding -dbg packages when we were enabling Apport in elementary. You can find at https://code.launchpad.net/~elementary-os/elementaryos/packaging-scripts) Second, you will need two config files for Apport: /usr/share/apport/package-hooks/source_geary.py and /etc/apport/crashdb.conf.d/geary-crashdb.conf (attached; generator script available from https://code.launchpad.net/~elementary-os/elementaryos/apport-hooks branch). On a stable system such as 12.04 you'll also need the user to manually enable Apport crash reporting by undoing this change: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/precise/apport/ubuntu/revision/1948#etc/apport/crashdb.conf On elementary OS dailiy builds or on Ubuntu 12.10 it's not needed. This will enable crash submission, but that's just a half of the hunt. Most users don't have debugging symbols installed. Even if they do have some installed, it's not the whole dependency tree of an app. And even getting the whole tree is not completely sufficient for nontrivial reasons which I won't list here. Because of this crash reports need post-processing, or so-called retracing. Apport's retracer collects all required debugging symbols and extracts human-readable data from the core dump submitted with the crash report. Apport also has a component called crash-digger that scrapes LP bug reports and feeds all unretraced ones to the retracer, so the process is completely automated. However, there are several gotchas here. Obviously, somebody has to run crash-digger. Moreover, crash-digger should be invoked often, because if a PPA update is issued before a crash is retraced, most likely it will be impossible to retrace the crash. Apport-retrace does not support cross-architecture retracing, so there should be two instances of crash-digger, either on two machines (for i386 and amd64), or on an amd64 machine, with one instance placed in an i386 chroot. Apport-retrace needs some configs too, see man apport-retrace and our config dir as a real-life example: https://code.launchpad.net/~elementary-os/elementaryos/apport-retrace-sandbox Apport-retrace and crash-digger should be run from an Ubuntu 12.10 machine or a bzr checkout, because elementary is (surprisingly) the first non-Canonical party to adopt Apport, and prior to our adoption it hardcoded some Ubuntu-specific values and didn't support retracing crashes for LP other than Ubuntu. Running it from bzr checkout is explained here: https://bugs.launchpad.net/apport/+bug/1003506/comments/15 Crash-digger doesn't have a manpage, but I've documented its typical invocation as used in elementary, you can see it here: https://docs.google.com/document/d/16bUZqrSudlVt7Z7gAafS15U-ZlmvhdSMpLEL1wcatGg/edit#heading=h.v15mmt4if3m3 We already run two (amd64 and i386) instances of retracer, so if you're OK with adding our bot to bug supervisors group of Geary project in Launchpad (or getting crash reports only from elementary OS installations), you can simply use our retracer and not mess with the setup. Though our retracer is just me running crash-digger on my home PCs from time to time. 2012/8/21 Daniel Fore dan...@elementaryos.org Report bugs: http://redmine.yorba.org/projects/geary/issues Before you ask, if you can't find the Report a bug button, it's OK, because there's none. To report a bug you'll have to create an account (the old-school yet-another username/password pair - there's no OpenID or OAuth support), confirm it via email (my email confirmation was considered spam by Gmail; if it seems to get stuck, look in spam), re-enter the username and password to log in, then the navigate to Issues tab and click New issue. The New issue button won't be there unless you're logged in. Thanks Christian for showing it to me, I'd have never found it myself. I wonder how users of Yorba apps manage to figure it out... 2012/8/21 Daniel Fore dan...@elementaryos.org Check out the wiki for more:
