Re: The Packaging Guide Needs Your Help
Hi Jonathan, On Tue, Aug 02, 2011 at 12:24:56PM +0100, Jonathan Riddell wrote: The new Ubuntu Packaging Guide is nearing completion but needs your help. Browse it at http://developer.ubuntu.com/packaging/html/ Articles still to be written include -traditional packaging Does this refer to traditional packaging contents, or traditional packaging workflows? Or both? In either case, my first inclination is to question whether this is something we want included prominently in the packaging guide. It is a major downfall of our existing wiki documentation that it tries to document all possible ways that packages can be put together, thus leaving would-be developers with no guidance about how packages *should* be put together, and it's my fervent hope that the packaging guide will avoid this trap. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: Crash database requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/11/2011 12:32 PM, Rick Spencer wrote: On 08/11/2011 12:02 PM, Matthew Paul Thomas wrote: To this list I'd add: * It should be brainlessly easy for users to submit this data. Either a single Yes, submit this crash confirmation, or a check box to automatically submit these crashes. One of the features that the X team really desire out of this sort of database is how frequent is this kind of problem, which requires the widest possible sample space. With my proposed design it's two clicks to submit, then another click to dismiss the error message. Probably I should simplify it further. Would it not be possible for the user to opt in, and then have the reports submitted silently in the background on behalf of the user without bothering them at all? If I had a butler, I would be annoyed if he asked me to ok crash reports before he sent them in for me. I'd want to tell the butler just send the crash reports without bothering me about them. Cheers, Rick I think it is pretty common to ask your approval before sending any data to a 3rd party organization. I think it is also fine to have both a ignore future crashes and a always send without prompting selections. John =:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5Ds2kACgkQJdeBCYSNAAOvvwCeLJP9TbdnwGLAsk8gVo/qNWDa eEgAoL1ISWlkQY6xPoVC5OiJih9wHDdu =HV8m -END PGP SIGNATURE- -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SRUs for typo fixes in descriptions
On Thu, Aug 11, 2011 at 10:43:05AM +1200, Robert Collins wrote:
On Thu, Aug 11, 2011 at 10:23 AM, Robert Collins
robe...@robertcollins.net wrote:
On Thu, Aug 11, 2011 at 9:47 AM, Brian Murray br...@ubuntu.com wrote:
With regards to the volume of bug reports - since Maverick has been
released on 2010-10-10 there have been 8572 bugs reported using apport.
The same number for Lucid since 2010-04-29 is 17,949. I'd tell you the
number for Natty but Launchpad times out. However, with the two data
points we have I think there are enough bugs reported about stable
releases using apport to justify an SRU for an updated package hook in
most situations.
Whats the search you are using to determine this? If its tag based
then I can get a reasonable estimate via bugsummary for you quite
easily..
I chatted with Brian on IRC.
This is from staging - so a couple of weeks old:
select count(distinct bug) from (select bug from bugtag where
tag='natty' intersect select bug from bugtag where tag in
('apport-bug', 'apport-package', 'apport-crash')) as _tmp;
count
---
36344
Thanks for doing this but I really wanted the ones created since Natty
was released. Joining in the bugs table and using a datecreated of
greater than 2011-04-28 gets us 10,741 bugs.
--
Brian Murray
Ubuntu Bug Master
signature.asc
Description: Digital signature
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SRUs for typo fixes in descriptions
On Wed, Aug 10, 2011 at 04:42:31PM -0700, Bryce Harrington wrote: On Wed, Aug 10, 2011 at 02:47:51PM -0700, Brian Murray wrote: On Thu, Aug 04, 2011 at 07:28:24PM +0200, Sebastien Bacher wrote: On jeu., 2011-08-04 at 07:36 -0700, Brian Murray wrote: Do you have datas that showing that most of the bugs are coming from stable versions? I would rather think that most of the useful technical feedback is coming from unstable versions (we do turn apport off on stable series as well), stable user tend to report feedback (things they like or not, design issues, etc) rather than bugs than benefit from apport informations usually. With regards to the volume of bug reports - since Maverick has been released on 2010-10-10 there have been 8572 bugs reported using apport. The same number for Lucid since 2010-04-29 is 17,949. I'd tell you the number for Natty but Launchpad times out. However, with the two data points we have I think there are enough bugs reported about stable releases using apport to justify an SRU for an updated package hook in most situations. I can attest we do get a lot of bug reports post-release; X crashes and freezes in the release are of particular interest to me - they're high priorities to do SRUs for if we can pinpoint the problem and if it's sufficiently widespread. But Seb hits on a key phrase - useful technical feedback is coming from unstable versions. Post-release the volume of reports goes up but quality seems to go way down, so the value of post-release bug reports is a lot less to me than the pre-release ones. Still, with a well crafted apport hook you hardly need the user to write anything (and in fact I notice with GPU freezes, many people don't). Usually we just need to know answers to a few basic questions; I'm experimenting with having the apport hook ask those questions multiple choice, since few users think to provide the answers upfront - so far seems to be working well. Like Brian mentioned, I also am trying to build logic into the apport hooks to detect situations where reports would not be wanted (hardware we don't support, etc.), and have apport kick out early in those cases. (Perhaps having apport give the user some helpful direction, if it can be done without becoming too irritating.) In my mind the only issue with leaving apport automatic bug collection turned on post-release is that it could result in excessive volumes of dupe bug reports, and that's why I tend to favor the idea of aggregating them in a crash database. Whether or not apport should be left on post-release for crash reporting is independent of the original question which in my mind was: Should we provide Stable Release Updates for apport package hooks? I say aye. -- Brian Murray signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Package conflicts
I've recently updated apport so that package installation failures, bugs tagged apport-package, will now also be tagged 'package-conflict' in the event that are multiple packages dealing with the same file. I additionally went through all the existing apport-package bug reports and also tagged them 'package-conflict' where appropriate. -- Brian Murray Ubuntu Bug Master signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Error database requirements
On Thu, Aug 11, 2011 at 11:02:09AM +0100, Matthew Paul Thomas wrote: Christopher James Halse Rogers wrote on 09/08/11 06:37: On Mon, 2011-08-08 at 00:34 -0700, Bryce Harrington wrote: ... Here's a start... * The user should have some way to check back on the status of their crash report; e.g. have some report ID they can look at to see statistics and/or any associated bug #. This one will be tricky without weirding people out (what is this 'Launchpad' thing and why is it on my computer?), but I'm sure there's some way of making it subtle enough. Yeah, and in fact the use case I'm envisioning for this would be limited to semi-technical folk, so it could be as simple as just giving them some serial number on the Problem Reported dialog they can take note of and load manually later on. Even though relatively few people would use this feature, I think it's important. Too often with other crash database it feels like you're sending things to a black hole. By including a mechanism to allow users to check back, it also provides a (subtle) path for sufficiently motivated technical users to participate more actively in finding solutions. To this list I'd add: * It should be brainlessly easy for users to submit this data. Either a single Yes, submit this crash confirmation, or a check box to automatically submit these crashes. One of the features that the X team really desire out of this sort of database is how frequent is this kind of problem, which requires the widest possible sample space. With my proposed design it's two clicks to submit, then another click to dismiss the error message. Probably I should simplify it further. I've added all of these [requirements] to https://wiki.ubuntu.com/ErrorTracker. (Not saying that they're right or wrong, just as a base to work from.) Sweet, thanks for jumping into the design on this! In looking at it, a few items spring to mind we should discuss further: 1. Prior art in Linux? Aside from Breakpad, do any other distros or FOSS projects have crash reporting systems like this? 2. I notice the Windows crash reporter includes buttons to check for existing solutions. Is that something we'd like to consider as a requirement for this? 3. Privacy issues should probably be elaborated on further. 4. How do us developers want to interact with the gathered data? I.e., what should the graphs or tables look like? Bryce -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SRUs for typo fixes in descriptions
On Thu, Aug 11, 2011 at 11:22:31AM -0700, Brian Murray wrote: Whether or not apport should be left on post-release for crash reporting is independent of the original question which in my mind was: Should we provide Stable Release Updates for apport package hooks? I say aye. We did get sidetracked a bit. But I think the sidetrack showed that yes, there is potential utility with being able to do post-release updates. It appears one of the main complaints here is that updating the hooks ends up requiring updating the entire package, which can be excessive. For xorg, in part to help mitigate this particular issue, I split out the apport hooks into a separate package from xorg, which I named 'xdiagnose' to help convey to the user that the package is for diagnosing problems. xdiagnose is a relatively small package, and contains only troubleshooting tools; so, updates don't download gobs of stuff, and regression risks worst case is breaking diagnostic tools - a lot less worrisome than breaking X. I would suggest if there are other situations where a) we want to update apport hooks semi-liberally post-release, but b) the package they're attached to is overly large or risky to update, then it may make sense to consider breaking out the apport hooks to a separate package. Bryce -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SRUs for typo fixes in descriptions
On Thu, Aug 11, 2011 at 10:48:11PM +0200, Sebastien Bacher wrote: On jeu., 2011-08-11 at 11:22 -0700, Brian Murray wrote: Should we provide Stable Release Updates for apport package hooks? I say aye. Well I disagree, 95% of our users probably don't report bugs or want to know what a bug is and are impacted by the number and quantity of downloads such trivial changes create, is the cost really worth the benefit? Do we lack bugs we can work on? The problem is almost universally the *opposite*: we already have users enabling apport and reporting bugs when apport prompts them to without actually understanding what's going on with their system, and these bug reports are wasting the time both of the users and the triagers who are trying to sift through the incoming bug reports to find the real bugs that we should be working on. It's a rare apport hook that warrants an SRU, but there are some. If we know we have a large number of duplicates of a bug, for instance, which suggests that it also affects the experience of a large number of users, but we aren't getting the information that we need to triage and reproduce it, SRUing an apport hook may be the thing to do. Likewise, if we know users are commonly misconfiguring their system in a particular way (for instance, by removing grub-pc, installing grub, failing to configure their new bootloader at all, and then finding out there are problems when they try to install a new kernel), we don't want to receive bug reports from every user about this - instead, we should be automatically directing them to instructions on how to fix their system. Now if the grand plans for a crash database come to fruition, with support for remotely (and securely) instructing machines how to gather additional information, then there probably won't be a need for apport hook SRUing in the future. But that's the future - we're not there yet, and apport hooks despite their limitations are one of the best tools we have at our disposal for handling these kinds of issues. We should be sensitive to the gratuitous-update problem, but we should weigh this against the very real benefits of being better able to fix the bugs affecting our users. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SRUs for typo fixes in descriptions
On jeu., 2011-08-11 at 14:50 -0700, Steve Langasek wrote: The problem is almost universally the *opposite*: we already have users enabling apport and reporting bugs when apport prompts them to without actually understanding what's going on with their system, and these bug Those users should be able to install an apport-hooks package though no? -- Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Error database requirements
On Fri, Aug 12, 2011 at 6:52 AM, Bryce Harrington br...@canonical.com wrote: 1. Prior art in Linux? Aside from Breakpad, do any other distros or FOSS projects have crash reporting systems like this? There is LP's OOPS system, there is a google project for cross platform crashdump capturing, a django project called 'sentry' for web server error analysis (that has a cassandra backend I'm told) ... I suspect a plethora of small scale automated-gathering tools out there, but the only massive scale end-to-end one I know of is breakpad. 2. I notice the Windows crash reporter includes buttons to check for existing solutions. Is that something we'd like to consider as a requirement for this? Yes, but I think that should be done in future iterations - theres plenty of meat around just handling: - file anonymously - without uploading too much - or too little - handling offline situations - data storage and backend scaling - initial analysis facilities - dealing with privacy - allowing users to follow up on their report [if desired - note that Microsoft's tool *used* to do this, now they don't] 3. Privacy issues should probably be elaborated on further. 4. How do us developers want to interact with the gathered data? I.e., what should the graphs or tables look like? I suggest in a first pass we want a strong API - probably a map-reduce style in-the-cloud processing workflow, and use that to build a real web UI as well as adhoc queries and custom analysis. -Rob -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
to install pathan 1
Dear Ubuntu experts: I am on ubuntu10.04(kernel2.6.38-10) I search web about whether there is simple way in ubuntu to install pathan 1, but so far I can not get. Need your help. so, I also tried old way. I download pathan 1, but at first stage of configure, I got error -- my xercesc directory is in /usr/include/ and my pathan 1 directory contain the following files: root@eric-laptop:/home/eric/cppcookbook/ch14/download/libpathan-1.0# ls aclocal.m4docs Makefile runConfigure autotools examples Makefile.defs.in src configure lib objs util configure.in LICENSE.TXT READMEWin32Projects --at configure stage--- checking unicode support in flex... configure: error: not found. Pathan requires a version of flex supporting the -U (16-bit unicode) flag. but I already install flex need expert's help thanks a lot in advance, Eric -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
