lubuntu-qa team mailing list archive

[Phill Whiteside <PhillW@xxxxxxxxxx>]

Hi Adam and PPC guys,

I'm going to give you the honest truth. We are now too late to sort the
issues out.

I know that some of these bugs go back a long while, some are recent. I
cannot see any help in my complaining to SABDFL over what has occurred
after the changes after A3.

I propose that PPC follows...


> (23:14:36) xxxx: That mail's very long and rambling, and doesn't really
> give me any concise statement of "this is broken; this is how we propose
> fixing it".
> (23:15:13) phillw: Thinking about this some more, the KMS option
> shouldn't be the default option on the live/desktop ISOs.  The
> crashes/freezes with radeon can take some time to appear.  It is quite
> conceivable that they could occur in the middle of re-partitioning, which
> would be bad.
> (23:15:13) phillw:
> (23:15:13) phillw: The more you think about, the more appealing the
> Debian way of doing things is: Just rely on the user to add video=ofonly if
> they want KMS.  This is basically what the boot message says to do at the
> moment anyway, although it doesn't explicitly mention KMS.
> (23:15:39) phillw: what do you need from Debian for the fix to be
> proposed?
> (23:16:28) xxxx: You implied earlier that there was a patch to the driver
> and/or kernel as an option, not just the command-line change.
> (23:18:13) phillw: did you read the email? He accepts that he was
> probably mistaken on a previous fix?
> (23:18:50) phillw: Like I said, up until bug 1058641 I was happy for
> radeonfb just to be removed.  This is even though I was responsible for
> having it put back (along with aty128) into 12.04 -
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/949288 . Incidentally, can I ask the kernel people was there a reason
> why CONFIG_FB_ATY was missed off.....something I probably should of done
> that at the time?!  Sorry!  I don't know anything about Mach64/Rage cards,
> particularly their current state in 12.10....will they use fbdev too now?
> Can ubuntu-x confirm?
> (23:23:32) xxxx: So, uhm. Reading through that bug, two things jump out.
> video=ofonly isn't the default, and only when setting this option do things
> go pear-shaped.
> (23:24:01) xxxx: The fix for it is, currently, a custom Xorg.conf, or a
> custom radeonfb command-line. Neither of those can be done automatically
> for the user in any sane fashion.
> (23:24:46) xxxx: If real code fixes for this can't be found in time, I
> think the people really familiar with the issue need to sit down and write
> some CLEAR release notes we can include for people about how to work around
> this.
> (23:26:54) phillw: so, we're pretty screwed? sorry to use that word. If
> we can get release notes out, I'll support them & then we can look at a fix
> as a matter of urgency... would that be okay from the guy who is liasion
> between -release and -kernel?
> (23:28:18) xxxx: I think release noting is the only sane way forward
> here, other than fixing the actual bug. We can't be writing out custom X
> config files for everyone, nor custom framebuffer inits based on the
> resolution and refresh rate they may want.
> (23:29:19) phillw: As we are too late to fix the bug, would you object to
> release notes?
> (23:29:56) phillw: well, bugs...
> (23:31:27) xxxx: I don't object to release notes, no. This is what
> they're for. In this case, though, the instructions for "how to find your
> video card and write a custom X config" and "how to switch to using
> framebuffer-only graphics, and configure your kernel command-line
> appopriately" are a bit long for a release note, so nice, clear,
> step-by-step instructions on a wiki page would be great, and then a release
> note that briefly describes the problem and points to said wi
> (23:33:23) phillw: Oh, do not worry about that! I'm also a wiki person,
> to get a set of steps in for new people will be clear 1., 2., etc...


So, can I ask that you good people get the wiki area up for the release
notes? We will go battle on in 13.04 :)

For kernel & -x, the PPC team will be looking for the fix. Thanks for
sticking with this arch :)

Regards,

Phill.

On 7 October 2012 22:59, Colin Watson <cjwatson@xxxxxxxxxx> wrote:

> [Please could you use line-wrap in your mails?  They're very difficult
> to read this way in my mail client ...]
>
> On Sun, Oct 07, 2012 at 12:38:05PM +0100, o jordan wrote:
> > I am keen too to get proper fixes and that is why bugs have been
> > raised against all the appropriate packages.  However, a lot of the
> > problems are long term ones, for example
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/725580 .  Some
> > though are recent e.g.
> >
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1058641
> > .  The problems are not PowerPC specific, but the difference is
> > non-PowerPC hardware has better fallback options, for example the vesa
> > or proprietary drivers.  Neither of these things are available on
> > PowerPC.  My proposal is just to create a useable fallback option,
> > something that isn't automatically available at the moment on PowerPC
> > for some nouveau users.
>
> I'm sorry.  I know you're trying to get this fixed and I'm sympathetic.
> But I don't want to end up in a position where I break something else as
> a result, and I'm simply not willing to be held responsible for that
> since this is not a field I understand well.
>
> I'm not asking that you get the kernel or X teams to apply a proper fix,
> necessarily.  All I'm asking is that you get somebody from those teams
> to ack the proposed changes to the boot menu; that way I can have some
> confidence that they won't cause some other problem that I have no way
> to predict.
>
> Get a member of the kernel or X teams to sign off on a proposed boot
> menu change, and I'll apply it.  It would help if this could be as brief
> as possible - while I appreciate that you've gone to a lot of effort to
> provide many bug references, I'm afraid I simply don't have time to read
> through lots of bugs on linux and xserver-xorg-*, given that this is not
> my field and so it takes a lot of energy to understand long
> back-and-forth threads!  The longer the mails, the less likely I am to
> manage to absorb anything beyond the third paragraph or so, given how
> much I have to do before the 12.10 release.  I think this may go for the
> other developers in question - you really need to be as concise as you
> can.
>
> I'm afraid I am finding the long e-mails on many different but related
> subjects frustrating and impossible to absorb properly.
>
> > On previous versions of *Ubuntu I believe you could still use ubiquity
> > in 16 colours.  Now it doesn't even work in 256 colours
> > https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1040544 .
> > Presumably the problem is in whatever widgety thing it uses.
>
> Any problem with this is certainly in some underlying toolkit and should
> almost certainly not be assigned to ubiquity.
>
> > I think you could replicate the problem on non-PowerPC hardware by
> > forcing a 8 bit colour depth.
>
> This would be a good thing for somebody to test directly, then.
>
> Cheers,
>
> --
> Colin Watson                                       [cjwatson@xxxxxxxxxx]
>



-- 
https://wiki.ubuntu.com/phillw