Re: Launchpad Bug Filing Changes for Ubuntu + reporter's thoughts
On 2009-09-15 19:53, Brian Murray wrote : Hello everybody, As a part of the Increase Apport Adoption specification[1] we are going to kick off an experiment and redirect all of Ubuntu's /+filebug links in Launchpad to https://help.ubuntu.com/community/ReportingBugs. This change has been tested on staging.launchpad.net already and will be landing shortly on edge.launchpad.net(*). If you review the specification and the documentation bug reporters will be redirected to, you will notice that we spent a lot of time and energy on ensuring that we improve the quality of bugs when they are reported. The time many of us spend on triaging very incomplete bugs is not sustainable given the volume of bug reports. Having reporters use ubuntu-bug (apport more specifically) to report bugs will reduce many of these problems for us. ... Hello, Before trying to improve the quality of bug reports, I would wonder what happens to bugs that are perfectly reported already. Among many, an example of a developer's dream of a report is : Bug #233990 https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/233990. Instead of simply forwarding it to development, instead of these possibly asking the reporter for one more detail and/or test, and instead of its being a thing done, I was asked What is a bare linefeed?, Where is it? (in the message file I uploaded), What happens if you erase your config? and What happens if you pull your socks off before sending?. Every answer is in the message file. After 1.5 year, the report is said to be incomplete, marked for expiration 47 days ago, the bug is still well alive, and, of course, the reporter is frustrated and less a reporter. Even more so because many sites implement OpenID server but not client, a plain user cannot conceivably subscribe to tens of upstream sites and learn their specifics each time. Ubuntu's specialized people should cope with those administrative details, each in their specialized field, so that Launchpad be the single interface through which the user can dialog with the developer (or the other way round if you prefer :-)) Automatic peering(1) of messages between local and upstream case would do wonders. When that's not feasible, and if OpenID client were implemented in Launchpad, it would be easier for a developer to subscribe to Launchpad than for Ubuntu users to go there. Because any Ubuntu user meeting a problem can use Launchpad as a means of direct workaround and promise(2), it's better to have the problems documented in Launchpad than to have fed-up-with-it reporters go to other places directly. It's a silent thanks how many times hunting for any Linux information lands on the word Ubuntu. What you all are doing is amazing and it's my pleasure to [try to] be helpful. Thanks for your attention too. André. Text optimized for 17 to 190 characters wide display. (1) Never trust spelling checkers, I've had to add a r :-) (2) Many times my answer to there are more bugs than in Window was maybe, but look how fast you find the solution. Once, Microsoft had changed their so-called MSN server's behavior 3 days before to pest the world and some Ubuntu had found hours later than an alternative plugin for Pidgin was cocking a snook. -- 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
Stop the madness
Dear madam, sir, The fact that I'm using Ubuntu since version 6.06 is only a detail. But where is Ubuntu going today? I'm willing to beg to the programmers: please test your software!! Try to listen to your users!! It's nice to have the latest technology inside a distribution but what do I say to newbies when basic keywords like stability simply aren't there anymore? Now when there's finally a gab in the market to hurt Microsoft Ubuntu delivers Koala: alpha drivers, crashing applications, and so on and so on. Give a distribution the time to mature, listen to your big chief, even when it's for only time only: 1 distribution a year will bring quality software instead of buggy software like it is now !! You might see me as an idiot who thinks that this mail might change anything but remember that idiot's like are the promoters on the field. I think that what Ubuntu programmers or Ubuntu in general are working for them selves, something like a DJ who is playing his music for himself without he/she looking to the public where the music suppose to play for . Eventually the public will run away. Please don't start to use the Microsoft phrase: the problems will be solved in the next version!! Koala doesn't do anything good to Linux in general. Stop the ego's within the developers club , listen to the users!! Deliver quality, Regards Patrick Everix -- 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
Re: Stop the madness
Am 17.11.2009 um 12:19 schrieb patrick: Give a distribution the time to mature, listen to your big chief, even when it's for only time only: 1 distribution a year will bring quality software instead of buggy software like it is now !! I had some thoughts on this as well and came to the conclusion, the base system and applications should be decoupled. Currently, the major reason to upgrade to the latest is for getting recent versions of applications. Right now I'd be glad if I could run e.g. the latest VLC or AbiWord on last year's Ubuntu (Hardy). Hardy worked so well with my hardware while Jaunty asks me to do 5 minutes of manual tweaking until all subsystems are running. After each boot! Of course, I could compile packages manually from upstream sources, and I have to for some packages as the distributed one is broken or removed intentionally (kqemu). But that's not the intention of using a distribution, after all. There are some buddies providing PPA's across Ubuntu releases for popular applications and I appreciate that very much. Perhaps it's possible to extend that path and allow users to run modern applications on a matured base system (kernel, drivers, blank desktop, admin controls). Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ -- 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
Re: Stop the madness
Personally, I was ecstatic to try out Kernel Mode Setting. I was very happy with it...until I found out that it absolutely butchered the VGA console. Finding out that vgacon was not supported broke my heart. However, these decisions seem to have been made by the graphics guys up at high-on-the-geek-totem-pole positions on grounds of conflict. Seeing as I'm not prepared to give up my text-mode console, I promptly disabled mode-setting once I found out that there was absolutely no way around it. Ok, now that my off the side rant is taken care of... What about going the gentoo route and just having endless updates? What would be the merits/disadvantages in that case? I'll be happy to admit, perhaps with a tinge of shame, that even 6 months is too long. Whenever a new release comes out I am always antsy and want it badly. I guess you could call it asynchronous development, where version numbers levitate smoothly as new versions from upstream prove their worth. Just as an aside...if gentoo's customizability were combined with ubuntu's stellar package management and user friendliness I would consider it the perfect distro. On Wed, Nov 18, 2009 at 7:29 AM, Markus Hitter m...@jump-ing.de wrote: Am 17.11.2009 um 12:19 schrieb patrick: Give a distribution the time to mature, listen to your big chief, even when it's for only time only: 1 distribution a year will bring quality software instead of buggy software like it is now !! I had some thoughts on this as well and came to the conclusion, the base system and applications should be decoupled. Currently, the major reason to upgrade to the latest is for getting recent versions of applications. Right now I'd be glad if I could run e.g. the latest VLC or AbiWord on last year's Ubuntu (Hardy). Hardy worked so well with my hardware while Jaunty asks me to do 5 minutes of manual tweaking until all subsystems are running. After each boot! Of course, I could compile packages manually from upstream sources, and I have to for some packages as the distributed one is broken or removed intentionally (kqemu). But that's not the intention of using a distribution, after all. There are some buddies providing PPA's across Ubuntu releases for popular applications and I appreciate that very much. Perhaps it's possible to extend that path and allow users to run modern applications on a matured base system (kernel, drivers, blank desktop, admin controls). Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ -- 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 -- 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
Re: Stop the madness
patrick wrote: Dear madam, sir, I wonder about the wisdom of even trying to respond to an email that starts that way... Give a distribution the time to mature, listen to your big chief, even when it's for only time only: 1 distribution a year will bring quality software instead of buggy software like it is now !! What on Earth could lead anyone to think so? One annual release would possibly mean one fewer chaotic period each year, but there would be no likelihood of fewer bugs in the ultimately released product. I think that what Ubuntu programmers or Ubuntu in general are working for them selves, Of course they are! That's the cornerstone of FLOSS development. People work _for themselves_ on software that they want. There's nothing like enlightened self-interest. Please don't start to use the Microsoft phrase: the problems will be solved in the next version!! Koala doesn't do anything good to Linux in general. Stop the ego's within the developers club , listen to the users!! Deliver quality, I believe you have the problem _exactly_ backwards. Egos are good for FLOSS. It takes someone with ego to start a project. It takes ego to fork a project (not always good, but certainly not always bad). It takes a healthy dose of ego to devote _free_ time to doing something right - for other users - than to do it well enough for your own purposes. -- derek -- 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
Re: Stop the madness
On Wed, Nov 18, 2009 at 3:29 PM, Markus Hitter m...@jump-ing.de wrote: Am 17.11.2009 um 12:19 schrieb patrick: Give a distribution the time to mature, listen to your big chief, even when it's for only time only: 1 distribution a year will bring quality software instead of buggy software like it is now !! I had some thoughts on this as well and came to the conclusion, the base system and applications should be decoupled. Currently, the major reason to upgrade to the latest is for getting recent versions of applications. Right now I'd be glad if I could run e.g. the latest VLC or AbiWord on last year's Ubuntu (Hardy). Hardy worked so well with my hardware while Jaunty asks me to do 5 minutes of manual tweaking until all subsystems are running. After each boot! Of course, I could compile packages manually from upstream sources, and I have to for some packages as the distributed one is broken or removed intentionally (kqemu). But that's not the intention of using a distribution, after all. There are some buddies providing PPA's across Ubuntu releases for popular applications and I appreciate that very much. Perhaps it's possible to extend that path and allow users to run modern applications on a matured base system (kernel, drivers, blank desktop, admin controls). Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ Markus, I totally agree with you, standalone apps should not follow the same stable release updates policy as core packages like the kernel or system libraries. Wether we like it or not, this is something that works well on Windows, you can easily get the latest app version, if something breaks you more easily identify that the problem was with that particular upgrade, if it's too serious you just re-install the previous version. On Ubuntu you need to wait 6 months to get the new application, if you find a problem you can't easily identify the root cause beause a lot more was changed that could impact the app, installing the previous version is not easy. This is a serious problem, and the main motivation for the getdeb project, we provide current applications for the current release. Youd also have the ubuntu-backports project, but as far I can see they have a limited scoped. Best regards, -- João Luís Marques Pinto GetDeb Team Leader http://www.getdeb.net http://blog.getdeb.net -- 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
patch for fakeroot faked.c
we have discovered a fakeroot deadlock, and we've attached a
source-patch that solves the problem at our site.
the outward manifestation is that *faked* the client (in our case,
usually *chown -R ...*) appear to be deadlocked, with faked hanging at
listen() and the client hanging at read().
adding some debug-output (and writing to /dev/shm/ to cut down on the
timing differences), we discovered that some of the writes from the
client that were not full-length *struct fake_msg* buffers were being
accepted as such.
this would corrupt the stream, and everything later in the stream would
be off.
the cascading problem would be that process_msg() would get values for
functions to call that were out of bounds and skip them entirely. the
final result would be that the client would finish sending messages for
which it expected replies, and faked would have thrown all of its
messages away as invalid, and go back to listening for more.
the attached patch, when applied, should be pretty self-explanatory: if
the size of the buffer read is not of the appropriate size, then
continue back to the top of the loop and get just enough more from the
read to fill the buffer.
this solves the problem for us.
let us know if you need any further details, or what we might do in
order to help properly get this patch into a place where it can be
distributed.
++ kirk beitz
--- fakeroot/faked.c.orig 2007-10-07 17:25:31.0 -0700
+++ fakeroot/faked.c 2009-11-18 13:49:50.0 -0800
@@ -753,6 +753,8 @@ void process_msg(struct fake_msg *buf){
f= buf-id;
if (f = highest_funcid)
func_arr[f]((struct fake_msg*)buf);
+ else
+fprintf(stderr, FAKEROOT: ? process_msg() called w/invalid funcid==%d ?\n, f);
}
#ifndef FAKEROOT_FAKENET
@@ -953,11 +955,16 @@ static long int read_intarg(char **argv)
#ifdef FAKEROOT_FAKENET
static int get_fakem(struct fake_msg *buf)
{
+ size_t readlen = sizeof(struct fake_msg);
+ uint8_t* readbuf = (uint8_t*)buf;
while (1) {
-ssize_t len;
+ssize_t len = read(comm_sd, readbuf, readlen);
-len = read(comm_sd, buf, sizeof (struct fake_msg));
-if (len 0)
+if (debug)
+ fprintf(stderr, FAKEROOT: get_fakem(): read(%d, 0x%xp, %d ): len == %d\n,
+ comm_sd, readbuf, readlen, len);
+
+if ((readlen-=len) == 0)
break;
if (len == 0)
@@ -966,6 +973,11 @@ static int get_fakem(struct fake_msg *bu
if (errno == EINTR)
continue;
+if (len 0) {
+ readbuf += len;
+ continue;
+}
+
fail(read);
}
--
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
Here lies the responsiblity
Well we've certainly seen a few problems with Karmic. I have reports from new or upgrading users of crashing applications etc. So here is what I see as the major problem. Ubuntu has had such good success that to many people, Ubuntu and Linux are one and the same thing. Ubuntu = Linux and Linux = Ubuntu. Canonical now has the responsibility, yes let me say that again, Canonical has a responsibility, to the entire Linux world, to be very careful with what they put out. Now I have no problem with releasing Karmic but please, for all the rest of us, including other distributions and companies that have worked hard over many years to promote Linux, MARK IT AS DEVELOPMENT. Karmic has some great stuff in it and I applaud the developers but it has done nothing good for Linux on the desktop in the eyes of new and upgrading users not to mention the media. Canonical, you have the power, accept responsibility. Save the usable releases to well debugged versions. Make this crystal clear to all the media as well. Cheers -- George Farris george.far...@viu.ca Vancouver Island University As Open Source continues to explode, and as we continue to see such huge growth and success as it spreads across the world and into different industries, we all need to remember that the raw ingredients that make this happen are enthusiastic, smart, decent people, and I for one feel privileged to spend every day with these people. Jono Bacon -- 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
Insufficiencies in Karmic's battery behavior
Karmic's adoption of DeviceKit-Power and the latest Gnome-Power-Manager has changed the way the GUI reports remaining battery time. The old method built a profile of how long, on average, it took for each percentage point of the battery to be depleted. From that, it could estimate fairly accurately, given the user's average use pattern, how long the battery would last. This was a huge step up from the old way of reporting the battery remaining time reported by the BIOS, which didn't take battery charge/discharge profiles into account and relied on current power draw measurements, leading to unstable results. Now, we've gone back. We do profile the battery in terms of how far off it is from the BIOS-reported remaining time, but this brings us back to the problem with traditional BIOS-reported remaining times: the reported time remaining can change drastically based on current usage. While adapting to what the user seems to be doing can be a good thing, this method leads to things like 3-minute YouTube videos or slightly long compression operations causing a large drop in estimated battery time when in fact it really won't have much of an impact in the long run, and the estimated time goes back up immediately after the operation is over. In my experience, the Jaunty behavior of profiling the battery and ignoring brief spikes in power usage produced a much more useful, accurate estimation of the remaining battery life. The current behavior leads to an almost completely useless metric -- I've attached two screenshots taken during normal usage that illustrate fairly vividly the problem with Karmic's behavior: a) the estimated time should always go down, never go up, and b) it should be a smooth line. Note that in the screenshots, the line goes up and down, in one case dropping down by an entire hour and then going back up. http://img188.yfrog.com/img188/6031/screenshotpowerstatisti.png http://img188.yfrog.com/img188/2706/screenshotpowerstatistiy.png -- 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
Re: Insufficiencies in Karmic's battery behavior
Karmic's adoption of DeviceKit-Power and the latest Gnome-Power-Manager has changed the way the GUI reports remaining battery time. Possibly relevant to this discussion is a widely me tooed' bug report on the battery time estimate flat out not happening in Karmic: https://bugs.launchpad.net/bugs/444881 To keep the thoughts flowing, I have a question: Is there a performance / power efficiency gain from not querying the battery as frequently as gnome-power-manager used to? Thanks, Dylan McCall -- 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
Re: Stop the madness
On Wed, 2009-11-18 at 22:24 +, patrick wrote: Dear madam, sir, The fact that I'm using Ubuntu since version 6.06 is only a detail. But where is Ubuntu going today? I'm willing to beg to the programmers: please test your software!! They do test their software, but the fact is that their testing is limited to hardware that they actually own, and software that they actually use. This is where you come in. You see, you likely have a unique hardware and software combination. If you can test late alpha and beta releases and report bugs, the developers can find out what doesn't work for you. It's no coincidence that the people who tested Karmic when it was in development are mostly quite happy with the system. I am. Try to listen to your users!! It's nice to have the latest technology inside a distribution but what do I say to newbies when basic keywords like stability simply aren't there anymore? Now when there's finally a gab in the market to hurt Microsoft Ubuntu delivers Koala: alpha drivers, crashing applications, and so on and so on. We're always hurting Microsoft. Software doesn't become stable through just being around; it becomes stable through people using it, reporting bugs and contributing patches. In this day and age, nothing really matures until some time after it gets packaged for Ubuntu. Think of the bigger picture as well. The next Ubuntu release is an LTS, supported for 3 years on the desktop and 5 years on the server. If Karmic was a conservative, behind-the-times release, then Lucid would be too - and if there's one thing you don't want in a product that will be around for 3 years, it's to be totally obsolete even before release. Karmic includes a lot of new stuff, so it can be stabilised through active use in time for Lucid. Lucid will not be a ground-breaking release, but a competitively modern distribution that will last the test of time. -- 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
