X.org glossary (Was Re: Announcing the Next Ubuntu Hug Day! - April 02 2009)

[Bryce Harrington]

Ever wondered why your pipe-A underruns and your EQ overflows?  These
and other cryptic X.org error terms now have a handy glossary available
from the Ubuntu-X wiki, put together with Jesse Barnes' help for all you
bug triagers:

  https://wiki.ubuntu.com/X/Glossary

See you for Hug Day Thursday!

Bryce

On Mon, Mar 30, 2009 at 03:54:25PM -0400, Pedro Villavicencio Garrido wrote:
> Fellow Ubuntu Triagers!
> 
> This week's HugDay target is *drum roll please* xorg-server and 
> xserver-xorg-video-intel!
>  * 49 New bugs need a hug.
>  * 103 Incomplete bugs need a status check.
>  * 81 Confirmed bugs need a review.
>  * 16 Bugs with patches that need to be reviewed.
>  
> Bookmark it, add it to your calendars, turn over those egg-timers!
>  * April 02 2009
>  * https://wiki.ubuntu.com/UbuntuBugDay/20090402
> 
> Can't stress it enough: everyone can help!
> 
> Have some time? Triage boogz! I won't be upset if you get a headstart~ ;)
> Have a blog? Blog about Hugday!
> Have some screen space? Open #ubuntu-bugs and keep an eye out for
> newcomers in need.
> Have minions? Teach THEM to triage for you! :)
> 
> Wanna be famous? Is easy! remember to use 5-A-day so if you do a good
> work your name could be listed at the top 5-A-Day Contributors in the
> Ubuntu Hall of Fame page!
> 
> Make a difference; we will be in #ubuntu-bugs (FreeNode) all day and
> night, and will be ready to answer your questions about how to help.
> 
> If you're new to all this, head to
>  http://wiki.ubuntu.com/Bugs
> 
> Have a nice day,
> 
> pedro.
> 
> 
> -- 
> ubuntu-devel-announce mailing list
> ubuntu-devel-annou...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce

-- 
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: Introducing apport-collect: attach apport hook information to existing bugs

[Bryce Harrington]

Hi Martin,

This is a very cool feature.  I notice that it sends a separate email
for each file attached.  Any chance it could be modified to attach all
the files in one go, so only one email is produced?

Bryce

On Thu, Feb 19, 2009 at 02:03:26PM +0100, Martin Pitt wrote:
> Hello Ubuntu developers and bug triagers,
> 
> Apport has supported hooks to collect package specific information for
> crash reports and bug reports submitted through Apport [1] for a long
> time.
> 
> A long standing request [2] was to provide a tool which provides the
> same functionality for already existing bugs. I. e. if a submitter
> reported a bug against xorg directly through the Launchpad UI, you can
> now ask him to run
> 
>   apport-collect 12345
> 
> (with 12345 being the bug number, obviously). This will check all
> source packages in the bug tasks, run all their apport hooks, and
> upload the collected information back to the bug report.
> 
> It uses launchpadlib for authentication.
> 
> The tool has a manpage, and I also added it to [3].
> 
> Enjoy, and please let me know about any problems by filing bugs
> against apport.
> 
> Thank you,
> 
> Martin
> 
> [1] with ubuntu-bug or Help -> Report a Bug for GNOME applications
> [2] https://bugs.launchpad.net/ubuntu/+source/apport/+bug/124338
> [3] https://wiki.ubuntu.com/Apport#Tools
> -- 
> Martin Pitt| http://www.piware.de
> Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)



> -- 
> ubuntu-devel-announce mailing list
> ubuntu-devel-annou...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce


-- 
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: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions

[Bryce Harrington]

On Mon, Nov 10, 2008 at 08:13:52PM -0500, Mackenzie Morgan wrote:
> On Mon, 2008-11-10 at 17:05 -0800, Bryce Harrington wrote:
> > > However, I am beginning to think that all the cases I know are i945 -  
> > > execpt for the aforementioned old laptop about which - frankly - I don't  
> > > care at all :) So perhaps "my" bug will solve most of the other ones  
> > > regarding VGA out.
> > 
> > Possibly.  VGA out issues tend to be extremely HW-specific.  I could
> > believe there could be a VGA out issue affecting just 945 chips.  That
> > said, I haven't seen the issue on the spare 945 laptop I have on hand.
> 
> The issue doesn't affect all 945 chips.  Mine isn't affected.  There are
> multiple different chips in existence labeled 945, however.  From
> drivers/gpu/drm/i915/i915_drv.h:
> 945G: 2772
> 945GM: 27A2
> 945GM: 27AE

Yes, this is quite likely.  And indeed, quite often they're unique not
only to the chip PCI ID, but also the subsystem vendor PCI ID.  In other
words, the chip itself may be fine, but the issue came into being when
the chip was integrated onto the motherboard and wired to the VGA port.

The subsystem vendor PCI ID can be found in the 'lspci -vvnn' output, as
the second line after the VGA device PCI line.

> Maybe only one of these three is affected?
> 
> I do have to wonder if it is more likely to affect upgrades than clean
> installs, as well.

Certainly it's possible, if the user had stray configuration in their
xorg.conf.  But usually users doublecheck that stuff before they file a
bug report, so most VGA issues I've dealt with have been legitimate
video driver issues.

Bryce

-- 
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: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions

[Bryce Harrington]

On Mon, Nov 10, 2008 at 11:14:34PM +, Vincenzo Ciancia wrote:
> I have done all my best for that bug - sometimes really struggling to  
> gather debug information in time before e.g. sending the laptop out. As  
> soon as I have a monitor at hand I will keep on. But my laptop is not  
> the only one. Problem is that most people in academia won't even bother  
> to set up ubuntu - fancy to report a bug - if it cannot enable their vga  
> out. Don't want this to look like a bug which will be quickly fixed and  
> it's only waiting for me. This problem existed since gutsy at least and  
> I cannot be the only one experiencing it.  If so I am sorry for noise - I  
> feel like intel is being said to be the "most free-software friendly  
> hardware vendor" while they are not caring about finalising their video  
> driver, and making at least decent their wifi one. I have been  
> recommending intel hardware for first and I regret having done that.  

Mmm, there is some truth amongst your points, but it seems clear that
the path to attaining a solution here is open to your hands.  I see you
have some strong passions on this topic, and would suggest they'd be
most productively channeled into working with Intel to solve it.

I'd also suggest calibrating your expectations on FOSS-friendliness.
Compared with how unfriendly other vendors are, Intel does indeed good
marks, but it doesn't mean they're perfect, just that they're the rare
good guy in a room full of rogues.

> However, I am beginning to think that all the cases I know are i945 -  
> execpt for the aforementioned old laptop about which - frankly - I don't  
> care at all :) So perhaps "my" bug will solve most of the other ones  
> regarding VGA out.

Possibly.  VGA out issues tend to be extremely HW-specific.  I could
believe there could be a VGA out issue affecting just 945 chips.  That
said, I haven't seen the issue on the spare 945 laptop I have on hand.

Bryce



-- 
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: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions

[Bryce Harrington]

On Mon, Nov 10, 2008 at 09:50:22PM +, Vincenzo Ciancia wrote:
> 
> > Regarding -i810, indeed there are a few remaining corner cases where
> > there are issues (mostly with old 8xx-era chips that Intel provides only
> > limited support for), and I've discussed a lot of these with Intel.  But
> > I can't really speak on your issue without knowing the specifics of your
> > case.  LP#?
> > 
> > Bryce
> 
> You should know them very well :) In fact you were "assigned" to the
> case  some point in time between winter and spring, or at least these
> were the words of somebody on the ubuntu-devel-discuss mailing list.

I wasn't assigned, but I did work on your bug around that time, and
found it to be an upstream bug so forwarded it.

> Various problems (my laptop broke twice for example, and now I don't
> have a monitor at all as I am abroad for a month) delayed the solution
> of the bug which is now active and waiting for me to find an external
> monitor for me (here in UK they are lots picky with their stuff).
> However I see vga out problems consistently on intel cards. On an older
> laptop with centrino I can enable vga out but then I can't get back... I
> have to reboot the system to get the LCD on again). On many new sony
> vaio laptops at my department in Pisa, they have the problem that the
> screen output does not come out (I will check this in detail when back
> in Pisa and add those models to my bug report). The lp bug is here:
> 
> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/137234
> 
> and the upstream discussion you can follow from the link.

Yes, and looks like upstream is wishing for you to gather some
additional information for them.

Also it seems you're using 945 graphics, so you fall in none of the
corner cases I alluded to earlier.  Upstream will give you full support
on -intel, if you can please supply them with the info they need.

> Thanks in any case, since you helped a lot here.

No prob,
Bryce

-- 
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: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions

[Bryce Harrington]

On Mon, Nov 10, 2008 at 10:13:25AM +, Vincenzo Ciancia wrote:
> John McCabe-Dansted ha scritto:
> 
> > OTOH hand this means that the drivers together cover more than 85%.
> > Would it perhaps be worth making both drivers easily available on the
> > same kernel?
> > 
> > I guess ideally we would scan the CVS automatically compiling each
> > module, and identify the exact revision that caused the regression.
> > 
> 
> In the case of intel, that would have meant letting us the choice to use 
> "i810" for xorg and "ipw3945" for wifi also in hardy and intrepid. 
> "i810" does not recognise my card anymore if I try to use it manually. 
> Intel has deprecated both drivers but someone should go there and ask 
> them why they maintain their linux driver at a much lower level than 
> their windows ones. If official representatives of ubuntu go there we 
> have some chances.

Are you asking why Intel would devote more support resources to the side
with more marketshare that makes much more money for them?  ;-)


Regarding -i810, indeed there are a few remaining corner cases where
there are issues (mostly with old 8xx-era chips that Intel provides only
limited support for), and I've discussed a lot of these with Intel.  But
I can't really speak on your issue without knowing the specifics of your
case.  LP#?

Bryce

-- 
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: [ubuntu-x] Fwd: Wacom tablets, TabletPC and Xorg support for Ubuntu 9.04 (Jaunty)

[Bryce Harrington]

On Mon, Nov 10, 2008 at 05:47:38PM +0100, Lo?c Martin wrote:
> > 2) update the linux wacom driver to the latest (even beta) release. 
> 
> I think it's already the case, Intrepid use the beta driver 0.8.1.4, and
> Jaunty uses the 0.8.1.6. 0.8.1.4 has a bug that severly affect some
> users (input freeze when the pen touch the screen), thus the threads
> where everybody is advise to compile the drivers (not necessary, see
> https://help.ubuntu.com/community/Wacom/LatestDriver ) even when it's
> just an xorg.conf problem.
> 
> However, we could stress the importance of SRU updates, but from my
> experience the sync between ubuntu packages and upstream has been quite
> good since Feisty.

> For Intrepid and 0.8.1.6, there's
> https://bugs.launchpad.net/ubuntu/+source/wacom-tools/+bug/291908 which
> we could use for an SRU. Anyone taking care of that? My last SRU was for
> Gutsy, I could try and find again what the steps are, but it took one
> month and a half for just a single dependency addition to an universe
> package - no source change, and I can already see Jaunty releasing
> before an SRU from a non-developer was be accepted.

The process is written at https://wiki.ubuntu.com/StableReleaseUpdates

If you would do steps 2.1, 2.2, and 2.4, I can take care of all the
other steps.

If you're comfortable doing some coding/patch work, doing step 2.3 as
well would be a huge help and would speed this process along
considerably.  If not, I can try to fit it in my todo list but I'm
pretty swamped so may not be able to get to it very soon.

> Having an UI to configure wacom devices is a really good idea. You can
> have a look at wacomcpl for ideas for options and how it works.
> Actually, developing an UI wouldn't just be a stopgap mesure for Jaunty
> if Xorg & wacom don't get HAL/wacom sorted out in time, since your UI
> could as well output the configuration in xorg.conf or in 10-wacom.fdi.

Cool, Loic can we ask you to draw a quick mockup of one or two ideas on
how it could work and be laid out?  A scanned in paper sketch would be
fine, or if you want to get fancy then done up in Gimp or Glade would be
great.  I think this would be helpful to code to, if we do go this
route.

Bryce

-- 
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: Very bad status of hardware (especially wifi) support in ubuntu, due to the too many accumulated regressions

[Bryce Harrington]

On Sun, Nov 09, 2008 at 03:53:55PM -0500, Scott Kitterman wrote:
> On Sunday 09 November 2008 15:07, Vincenzo Ciancia wrote:
> ...
> > network. Some of them work in a release, some of them in another. In the
> > end, you never see your laptop "just working" in a single release.
> 
> Oddly enough, for me, my Dell Latitude D430 laptop (not one of the ones that 
> is pre-sold with Ubuntu) has 'just worked' in Gutsy, Hardy, and Intrepid.  
> 
> I don't doubt you've had problems, but it's not safe to over-generalize.

Agreed about over-generalizing.

That said, I do like generalizing.  :-)  I think there is a cyclical
thing in FOSS, where you have some legacy thing that works 80%, and
upstream decides to get that last 20% it requires a major rewrite.  They
expect it to get to 90-95%, so distros adopt it, but when the dust
settles it works at just 85%...

...and unfortunately the 15% it doesn't cover is different than the 20%
the legacy system didn't cover, and that 15% is rightfully pissed that
they are seeing a regression when things worked so well before.

Bryce

-- 
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: Ubuntu 8.10 significantly slower than previous versions

[Bryce Harrington]

Whoops, I thought you were talking about the recent article about -intel
performance on x45 chips.  But I see you're actually talking about an
earlier article about Ubuntu performance in general:
http://www.phoronix.com/vr.php?view=13022

Note that in that article they looked only at the proprietary -nvidia
driver's performance, and did not find any noteworthy regressions in
that.  So depending on what video driver you're using, it may not have
much relevance to your issue.

Bryce

On Thu, Nov 06, 2008 at 03:58:51PM +0100, mr wrote:
> Hi,
> 
> According to the recent benchmarking article by Phoronix, the previous two
> releases of Ubuntu are significantly slower than Feisty Fawn. In some cases
> this can be seen as up to 50% performance drop with certain desktop tasks.
> 
> I can confirm that this is true in that my girlfriends desktop used to be
> quite capable of playing a 1080p x264 video but since upgrading to gutsy and
> then hardy it has become unwatchable, even mplayer reports that "YOUR
> COMPUTER IS TOO SLOW"
> 
> I think that the reasons behind this reduction in performance across the
> board needs some serious investigation and work done to reverse this trend.
> At the moment I am faced with either running an old distro or upgrading
> hardware.
> 
> Any discussion on this is welcome :)
> 
> Thanks,
> 
> Alan
> 
> Phoronix article:
> http://www.phoronix.com/scan.php?page=article&item=ubuntu_bench_2008&num=1

> -- 
> 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: Ubuntu 8.10 significantly slower than previous versions

[Bryce Harrington]

On Thu, Nov 06, 2008 at 03:58:51PM +0100, mr wrote:
> Hi,
> 
> According to the recent benchmarking article by Phoronix, the previous two
> releases of Ubuntu are significantly slower than Feisty Fawn. In some cases
> this can be seen as up to 50% performance drop with certain desktop tasks.
> 
> I can confirm that this is true in that my girlfriends desktop used to be
> quite capable of playing a 1080p x264 video but since upgrading to gutsy and
> then hardy it has become unwatchable, even mplayer reports that "YOUR
> COMPUTER IS TOO SLOW"
> 
> I think that the reasons behind this reduction in performance across the
> board needs some serious investigation and work done to reverse this trend.

Indeed, half the reason I suggested Phoronix do these tests is to
stimulate more investigation into performance issues.  We've had
anecdotal evidence of performance reductions since Gutsy at least, and
Phoronix presented a good opportunity to get some solid numbers.

I've spoken with upstream about -intel performance previously.  They've
indicated their focus is on the current git version of the driver, and
so would ask that anyone wishing to provide feedback on performance to
first run the git-head version of the driver.  This would enable the
user to update and give swift feedback to the developers on any
performance changes they are experimenting with.

Beyond that, I'd encourage anyone wishing to help improve -intel
performance on Ubuntu to join the ubuntu-x mailing list to discuss it in
additional detail.

Bryce


-- 
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: Input Device Commented Out Lacks documentation

[Bryce Harrington]

Great, thank you Dan!

On Thu, Nov 06, 2008 at 12:37:59AM -0500, Dan Colish wrote:
> Hey Bryce,
> 
> Not at all, I'm still converting my current xorg over to fdi, maybe my notes
> will be helpful. Mappings look fairly straight forward and I found a good
> thread in the forums that elaborates more on the subject.
> http://ubuntuforums.org/showthread.php?t=948154
> 
> Dan
> 
> On Thu, Nov 6, 2008 at 12:31 AM, Bryce Harrington <[EMAIL PROTECTED]>wrote:
> 
> > Hi Dan,
> >
> > Would you mind going ahead and sketching this documentation in?
> > http://wiki.ubuntu.com/X/Config/Input
> >
> > Bryce
> >
> > On Thu, Nov 06, 2008 at 12:21:45AM -0500, Dan Colish wrote:
> > > I think there should be a link placed in the xorg document when
> > > update-manager comments out an input device to the new fdi documentation.
> > It
> > > is hard to find that page in the wiki if you're not familiar with the
> > > details of the project. It is also frustrating to not know the proper way
> > to
> > > configure a system when the methods of configuration change.
> > >
> > > --Dan
> >
> > > --
> > > 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: Input Device Commented Out Lacks documentation

[Bryce Harrington]

Hi Dan,

Would you mind going ahead and sketching this documentation in?
http://wiki.ubuntu.com/X/Config/Input

Bryce

On Thu, Nov 06, 2008 at 12:21:45AM -0500, Dan Colish wrote:
> I think there should be a link placed in the xorg document when
> update-manager comments out an input device to the new fdi documentation. It
> is hard to find that page in the wiki if you're not familiar with the
> details of the project. It is also frustrating to not know the proper way to
> configure a system when the methods of configuration change.
> 
> --Dan

> -- 
> 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: Sony VAIO monitor not recognized

[Bryce Harrington]

On Sat, Oct 25, 2008 at 07:31:48PM -0500, Ron E. VanNimwegen wrote:
> Anyone else run into this problem?

Have you looked in launchpad?

Bryce

-- 
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: State of xserver-xorg-video-nv

[Bryce Harrington]

If you have a patch from upstream that you can confirm fixes the issue,
I can take a look, but otherwise you're a bit too late for intrepid
which is already into RC freeze.

You're right that there's lots of -nv bugs; I've upstreamed several in
recent weeks but they seem not to get attention upstream.  On the other
hand, -ati and -intel bugs do seem to get productive attention upstream,
so I've focused my energies more towards those.

If you would be willing to lend some time to assist with triaging and
upstreaming -nv, I can provide mentoring.  Pop into #ubuntu-x on IRC and
flag me down.

As to your particular bug, you're missing some important details needed
for troubleshooting.  See http://wiki.ubuntu.com/X/Reporting for tips on
what to include in X bug reports.

Bryce

On Thu, Oct 23, 2008 at 09:47:49PM +0200, Mark Schouten wrote:
> Hi there,
> 
> I would like to request some extra attention for the
> xserver-xorg-video-nv package. There are quite a number of bugs, and one
> of them is buggin' me. :)
> 
> The bug is:
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nv/+bug/275029
> 
> I get a 800x600 resolution when using nv. I'm not sure why, logging and
> config is attached to the bug. I just managed to get into 'failsave'
> which had a good resolution. So now I configured use of the Vesa driver
> in xorg.conf, and resolution is ok now.
> 
> Please have a look at this, if there's still time. If input is needed,
> feel free to contact me.
> 
> Regards,
> 
> Mark Schouten
> https://launchpad.net/~mark-prevented
> 
> 
> 
> -- 
> 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: Subversion bug

[Bryce Harrington]

You should use launchpad to report bugs, not this mailing list.
For more guidance on how to report bugs, please see:

 https://help.ubuntu.com/community/ReportingBugs

Bryce

On Fri, Oct 17, 2008 at 11:09:59AM +0300, Viacheslav Chumushuk wrote:
> Hello.
> 
> I think You have bug at ubuntu's subversion package.
> We have three ubuntu machines and they have the same error.
> Here is it:
> 
> [EMAIL PROTECTED] www] $ svn checkout
> svn+ssh://[EMAIL PROTECTED]/home/repos/repository/portal4/trunk
> Password:
> /libexec/ld-elf.so.1: Shared object "libaprutil-1.so.2" not found,
> required by "svnserve"
> svn: Connection closed unexpectedly
> [EMAIL PROTECTED] www] $
> 
> Software version:
> Ubuntu 8.04 last updated at 17.10.2008 11:07
> subversion Version: 1.4.6dfsg1-2ubuntu1
> libaprutil1 Version: 1.2.12+dfsg-3
> 
> Best regards, Viacheslav Chumushuk.
> 
> -- 
> 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: bugs

[Bryce Harrington]

This is not the right place to report bugs.  Please use launchpad.

Also, when reporting bugs, please find and follow the bug guidelines for
the thing you're reporting bugs against.  For the linux kernel,
guidelines are at:

 https://wiki.ubuntu.com/KernelTeamBugPolicies

More info on debugging other components are found here:

 https://wiki.ubuntu.com/DebuggingProcedures

Bryce


On Thu, Oct 09, 2008 at 04:38:25PM -0400, Evan Billy wrote:
> Here are some bugs I have found in the kernel (if it helps)
> 1. my sound is crackly, when a sound is supposed to play it just plays
> crackles
> 2. the new kernel has some kind of booting problem or error on my computer;
> it displays what it is doing and I have to press enter multiple times to get
> it started.
> 3. The new network manager wont work for me. It worked when i upgraded, but
> now it will not recognize my Internet connection.
> 
> 
> -Evan

> -- 
> 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: Intrepid amd64 Live CD beta testing

[Bryce Harrington]

On Fri, Oct 03, 2008 at 09:05:54PM +0200, Lo?c Martin wrote:
>   Thanks. With Xorg.0.log I managed to troubleshot the problem - seems 
> like the LiveCD can't run with 2 monitors plugged on an Nvidia card, 
> even when one of the two isn't on. Since my Cintiq was disconnected, and 
> the control box was unplugged, I discarded it, but as long as the 
> DVI>DVI cable is connected, it manages to pick it up.
> 
> I've marked my bug report as a dupe 
> (https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/210340, install 
> failure if 2 both monitors are active)

Thanks; actually I'll probably dupe the other one to yours since your
report has the better troubleshooting info.

Bryce


-- 
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: Intrepid amd64 Live CD beta testing

[Bryce Harrington]

On Fri, Oct 03, 2008 at 08:23:34PM +0200, Lo?c Martin wrote:
> Lo?c Martin a ?crit :
> > Bryce Harrington a ?crit :
> >> Btw, you can also report X bugs more easily now by running this command:
> >>
> >>   ubuntu-bug xorg
> >>
> >> This will automatically gather all the necessary troubleshooting files,
> >> launch your web browser, and open the bug in launchpad.
> >>
> > Thanks (however I've just finished it :( ).
> > 
> > Does it work in command line mode (since I can't use X on the Beta)?
> > 
> > Lo?c
> 
> By the way, is it possible to attach multiple files at a time on 
> Launchpad? I'm getting sick of waiting for the page to reload ;)

No, not through the web interface.  I raised this issue with kiko at the
last sprint, and it sounded like multi-attachment functionality would be
feasible to add, so I'm keeping my fingers crossed.

Bryce


-- 
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: Intrepid amd64 Live CD beta testing

[Bryce Harrington]

On Fri, Oct 03, 2008 at 08:18:01PM +0200, Lo?c Martin wrote:
> > Btw, you can also report X bugs more easily now by running this command:
> > 
> >   ubuntu-bug xorg
> > 
> > This will automatically gather all the necessary troubleshooting files,
> > launch your web browser, and open the bug in launchpad.
> > 
> > Bryce
> > 
> > 
> Thanks (however I've just finished it :( ).
> 
> Does it work in command line mode (since I can't use X on the Beta)?

There is an apport-cli tool which works similarly, but it still requires
firefox for placing the bug report itself, which of course requires an X
session.  Maybe pitti can give a better answer.

Of course, as long as you have a web connection, you could run X from a
different system (setting xhost/DISPLAY appropriately).

Bryce


-- 
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: Intrepid amd64 Live CD beta testing

[Bryce Harrington]

On Fri, Oct 03, 2008 at 08:47:40AM -0700, Brian Murray wrote:
> On Fri, Oct 03, 2008 at 02:41:34PM +0200, Lo?c Martin wrote:
> > Hi,
> > 
> > While previous Intrepid amd64 Live CD works perfectly, the Beta one 
> > released yesterday doesn't manage to configure properly X on my computer 
> > (Nvidia 7900GS 256Mo PCIe, Iiyama Prolite B2403WS through VGA port). The 
> > screen has vertical colored bars (green/gray/yellow) and going to the 
> > console, killing gdm, dpkg-reconfigure xserver-xorg blocks at the end 
> > (starting X from another console doesn't work :
> > No screens found.
> > 
> > I'd like top report in Launchpad, but I'm not sure what I should report 
> > it against. Also, is there any special tags (except of course 
> > regression-potential) for the Beta?
> 
> Bug reports regarding X can generally be filed against the 'xorg'
> package, and if necessary they will be moved to the correct package by
> the Ubuntu X team.  Additionally, you'll want to include your
> '/etc/X11/xorg.conf' file and '/var/log/Xorg.0.log' from the Live CD.
> You can find out more about debugging X at
> http://wiki.ubuntu.com/X/Debugging.

>From the description of the problem, I would first guess the video
driver is at fault.  But Brian's right - file against xorg and we'll
move it where it needs to go.

Btw, you can also report X bugs more easily now by running this command:

  ubuntu-bug xorg

This will automatically gather all the necessary troubleshooting files,
launch your web browser, and open the bug in launchpad.

Bryce


-- 
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: Wiki lost forms (was Foundations team meeting minutes, 2008-09-10)

[Bryce Harrington]

On Fri, Sep 12, 2008 at 12:00:39AM +0100, (``-_-) -- Fernando wrote:
> Ol?? Colin e a todos.
> 
> On Thursday 11 September 2008 14:23:36 Colin Watson wrote:
> >   * lose two hours of work to the wiki deciding not to accept my new page, 
> > my browser not saving my form contents, and me not thinking to save the 
> > content somewhere else before hitting 'Save Changes'
> 

Sympathies; that happened to me once.  Then I switched to using gedit
for composing the minutes and pasting into the wiki after.

Bryce

-- 
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: Boot-time improvements

[Bryce Harrington]

On Wed, Sep 10, 2008 at 10:01:49AM +0100, Matthew Paul Thomas wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Jonathan Carter (highvoltage) wrote on 09/09/08 19:31:
> >...
> > 1. Attempt to get an X server up much sooner
> >...
> 
> See also .

Most of those changes were pushed upstream, and so are included in
Hardy; most of the remainder will be in Intrepid.  One or two changes
may not be upstream yet, but the fedora patches are on my todo list to
review if I have time.  Kernel-based modesetting is dependent on GEM
work being done, which I mentioned earlier in this thread, and might be
a jaunty thing.  The stuff still on their todo list will be nice, but I
don't know how much savings they'll bring.

Bryce


-- 
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: Boot-time improvements

[Bryce Harrington]

On Tue, Sep 09, 2008 at 08:31:33PM +0200, Jonathan Carter (highvoltage) wrote:
> Hi
> 
> Some systems have been really successful at making it *appear* as if the 
> system starts up faster. In my opinion, where the system can't be made 
> to boot faster, it should be made to appear so.

We're right on the cusp of having GEM and kernel modesetting in Ubuntu
(definitely by Intrepid+1).  Probably best to wait and see how all that
shakes out, as it should improve the boot up speed/smoothness
considerably.

Bryce

-- 
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: Bugs marked incomplete

[Bryce Harrington]

On Tue, Sep 02, 2008 at 08:04:43AM +0100, Chris Coulson wrote:
> Unfortunately, some triagers do just close bugs when they are marked ready
> to expire, without actually checking whether the reporter provided the
> requested information. I have re-opened one such report recently, although I
> don't want to share the bug report number publicly on the mailing list
> without contacting the triager first.

As you apparently gathered, that is certainly possible but generally
incorrect.  Discussing it with the triager is the right approach.

If the reporter provided the information requested, then the bug should
not be closed as expired - it should either be moved to
Confirmed/Triaged, or additional questions asked and left at Incomplete
(with the counter reset).

Bryce

-- 
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: Bugs marked incomplete

[Bryce Harrington]

On Tue, Sep 02, 2008 at 01:54:21AM +0200, Wouter Stomp wrote:
> On Mon, Sep 1, 2008 at 11:44 PM, Bryce Harrington <[EMAIL PROTECTED]> wrote:
> > First, afaik automatic-expiration is not enabled for Ubuntu.  It tracks
> > when bugs will expire but doesn't close them without human action.
> >
> 
> Ok, so what does expiring mean then?

Auto-expiration is a Launchpad feature that can be enabled on a
per-project (but not per-source) basis.  So, some non-Ubuntu Launchpad
using projects may have it flipped on.  Ubuntu made the decision that
auto-expiring bugs was not desireable, so in Ubuntu the "expires in X
days" is more of just a hint for triagers and reporters.

> > So... I think this isn't a problem.  If you could show a (recent)
> > example where something in Ubuntu got expired this way, that'd be worth
> > knowing about.
> >
> 
> No I don't :-) (although if I remember right it did happen to some of
> my bugs a while ago) I guess I misunderstood the expiring concept.
> Thanks for explaining.

Sure.  There was a brief period a while ago when this was turned on by
default for Ubuntu, which may be what you remember.  AFAIK all bugs that
were closed due to this, were reopened.

Bryce

-- 
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: Bugs marked incomplete

[Bryce Harrington]

On Mon, Sep 01, 2008 at 11:32:20PM +0200, Wouter Stomp wrote:
> Hello,
> 
> Bugs that are marked incomplete and subsequently get a reply from the
> original reporter often stay in the incomplete status. This means they
> automatically get closed even though the needed info was provided. I
> think it would be a good idea to automatically change the status to
> new once a new comment is made on an incomplete bug.

First, afaik automatic-expiration is not enabled for Ubuntu.  It tracks
when bugs will expire but doesn't close them without human action.

Second, even if automatic-expiration were enabled, IIRC it is configured
to distinguish between ones that have received a reply vs. those that
don't.

So... I think this isn't a problem.  If you could show a (recent)
example where something in Ubuntu got expired this way, that'd be worth
knowing about.

Bryce


-- 
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: Problem with hotkey-setup

[Bryce Harrington]

Hi Travis,

Sounds like you're looking for the keyboard troubleshooting section of
the wiki:  

https://wiki.ubuntu.com/X/Troubleshooting#Problem involves missing support for 
some keyboard keys

On Thu, Aug 21, 2008 at 05:17:41AM +1000, Travis Place wrote:
> Hi all,
> 
> First of all, im not on the mailing list, so please post replies to my 
> address.
> 
> I have been tracking down a problem on my (K)Ubuntu installs for a few days, 
> and found out what the issue is..
> 
> Basically, on my HP DV2839TX laptop, if i press the button to disable/enable 
> the touchpad, the event XF86Launch0 is triggered, and this causes KMilo (in 
> kubuntu) and something else (cant remember the name) in Ubuntu to crash. This 
> then stops all my other "extra" keys on my laptop from working. I believe the 
> problem lies in hotkey-setup, and my laptop seems to use 'hp.hk' file.
> 
> Also, of all the buttons on this laptop, 2 have never worked (in Ubuntu or 
> Kubuntu) and they are the 'Quickplay' and 'DVD' buttons.
> 
> So i guess, my question is, how can I a) aid in getting this issue resolved 
> for this model laptop, and change the event trigged on pressing certain 
> buttons b) do it myself.
> 
> Thanks in advance,
> Travis Place (wishie)
> 
> -- 
> 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: git 1.6

[Bryce Harrington]

On Thu, Aug 21, 2008 at 02:40:11PM -0500, Nehemiah Dacres wrote:
> will git-core 1.6 be available in hardy Hedron repositories soon or will we
> have to wait till intrepid Ibex because this is a LTS release?

Hardy is updated only to fix bugs, not bring in new packages.  At your
option you can add the hardy-backports repo and pull newer versions of
packages from there.  You can also put in a request for a new git-core
in hardy-backports if you wish.  See wiki.ubuntu.com for details.

Bryce

-- 
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: Backtracing, Invalidated Bugs and Quality

[Bryce Harrington]

On Wed, Aug 20, 2008 at 10:20:38AM -0400, Paul Smith wrote:
> Also, it seems to me that if you tell someone their bug is "invalid"
> that doesn't inspire them to come back with more information or send
> more bugs in the future.  On the other hand, if you mark the bug as
> "need help" or similar, then they know what they need to do next time.
> It's more encouraging than discouraging.

I don't know about everyone else, but I always close such bugs with a
statement such as, "Please check with a newer version of Ubuntu, and
don't hesistate to reopen it with the additional requested info if it
still occurs."

>From my experience users seem to have no problem re-opening bugs (often
erroneously!)

In any case, closing old expired bugs that haven't received a response
is pretty standard operating procedure all across open source.  Else
you'd be drowning in bug reports and not be able to identify the good
ones, that can be solved.

Bryce

-- 
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: Automatic fsck

[Bryce Harrington]

On Tue, Aug 12, 2008 at 11:15:05AM +0100, Matt Zimmerman wrote:
> On Mon, Aug 11, 2008 at 02:09:19PM -0700, Bryce Harrington wrote:
> > On Mon, Aug 11, 2008 at 11:52:25AM +0100, Matt Zimmerman wrote:
> > > == Filesystem checking / AutoFsck ==
> > > 
> > > A suggestion was made to the technical board that Ubuntu could be smarter
> > > about how and when it performs filesystem integrity checks (fsck).
> > > 
> > > Decision: This should be discussed more widely in the developer community
> > > Action: Scott to start a thread on ubuntu-devel/-discuss
> > 
> > I find the autofsck to be most notable on my laptop, perhaps because I
> > reboot it more frequently, and because it usually chooses to autofsck at
> > some inopportune time.  I don't know if laptop harddrives need fsck more
> > than desktop's, but I wouldn't mind seeing the frequency be reduced for
> > laptops.
> > 
> > Alternatively, maybe the autofsck could be made to take a few more
> > factors into account, such as total run time since last fsck, total
> > absolute time since last fsck, drive age, etc.
> 
> Total run time sounds like an interesting one to watch.
> 
> Some of the other ideas which have been proposed are:
> 
> Run fsck during shutdown (when the user isn't expecting to be able to use
> the system for a while anyway) rather than at startup.
> https://blueprints.launchpad.net/ubuntu/+spec/prompt-for-fsck-on-shutdown
> 
> Allow fsck to be easily skipped.  This was implemented in 8.04 as part of
> https://blueprints.launchpad.net/ubuntu/+spec/usplash-polish
> 
> Skip fsck when running on battery.  Also implemented in 8.04 as part of
> https://blueprints.launchpad.net/ubuntu/+spec/usplash-polish

More smaller partitions would be another option (with corresponding
trade-offs).  Or two partitions - one small one requiring frequent
fsck's, and a large one that needs fsck'd only occasionally.

Bryce

-- 
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: Minutes from the Technical Board, 2008-07-15

[Bryce Harrington]

On Mon, Aug 11, 2008 at 11:52:25AM +0100, Matt Zimmerman wrote:
> == Filesystem checking / AutoFsck ==
> 
> A suggestion was made to the technical board that Ubuntu could be smarter
> about how and when it performs filesystem integrity checks (fsck).
> 
> Decision: This should be discussed more widely in the developer community
> Action: Scott to start a thread on ubuntu-devel/-discuss

I find the autofsck to be most notable on my laptop, perhaps because I
reboot it more frequently, and because it usually chooses to autofsck at
some inopportune time.  I don't know if laptop harddrives need fsck more
than desktop's, but I wouldn't mind seeing the frequency be reduced for
laptops.

Alternatively, maybe the autofsck could be made to take a few more
factors into account, such as total run time since last fsck, total
absolute time since last fsck, drive age, etc.

Bryce

-- 
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: Touchpad issues

[Bryce Harrington]

On Mon, Aug 04, 2008 at 10:51:23AM -0500, Robert Easter wrote:
> Hello.
> 
> What plans, does anyone know, are there for accommodating the Elantech 
> touchpads?  The current Synaptics drivers  won't touch them, and the 
> mouse drivers (only other option) leave the touchpad generally unstable

Have you tried evdev?

Bryce

-- 
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: xserver-xorg-core intrepid 2:1.4.99.905-0ubuntu4 missing librecord.so (Record module)

[Bryce Harrington]

On Thu, Jul 31, 2008 at 05:51:39PM -0400, Chris wrote:
> Bryce Harrington wrote:
>> On Thu, Jul 31, 2008 at 03:46:20PM -0400, Chris wrote:
>>> Bryce Harrington wrote:
>>>> On Thu, Jul 31, 2008 at 01:24:00PM -0400, Chris wrote:
>>>>> I'm a developer and require it for my own software.   I went into 
>>>>> the package and enabled it & rebuilt for the time being.
>>>>>
>>>>> Isn't there some software in Ubuntu that requires it?
>>>>> Xwindow application automated testing?
>>>>> Video recording of the desktop?  (I think this one just grabs the cursor)
>>>>> Debugging an app?
>>>>>
>>>>> I guess they disable it for security purposes.
>>>> 
>>> http://www.sandklef.com/xnee/
>>> I believe xnee uses XRecord (the headers refer to it).  So I think 
>>> the  xorg record module should be enabled during the build.
>>
>> Got a debdiff to send me?
>
> This debdiff enables the RECORD extension.

Thanks Chris, sponsored and uploaded to Intrepid.

Bryce

> diff -u xorg-server-1.4.99.905/debian/changelog 
> xorg-server-1.4.99.905/debian/changelog
> --- xorg-server-1.4.99.905/debian/changelog
> +++ xorg-server-1.4.99.905/debian/changelog
> @@ -1,3 +1,11 @@
> +xorg-server (2:1.4.99.905-0ubuntu5) intrepid; urgency=low
> +
> +  * debian/rules:
> +Added --enable-record.  By default, xorg-server does not build the 
> +RECORD extension.  Added the record module (for Xnee and other purposes).
> +
> + -- Chris Nasho <[EMAIL PROTECTED]>  Thu, 31 Jul 2008 17:26:00 -0400
> +
>  xorg-server (2:1.4.99.905-0ubuntu4) intrepid; urgency=low
>  
>* debian/rules:
> diff -u xorg-server-1.4.99.905/debian/rules 
> xorg-server-1.4.99.905/debian/rules
> --- xorg-server-1.4.99.905/debian/rules
> +++ xorg-server-1.4.99.905/debian/rules
> @@ -49,6 +49,7 @@
>--enable-xtrap \
>--enable-glx-tls \
>--enable-dmx \
> +  --enable-record \
>--enable-vfb \
>--enable-kdrive \
>--enable-xephyr \


-- 
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: xserver-xorg-core intrepid 2:1.4.99.905-0ubuntu4 missing librecord.so (Record module)

[Bryce Harrington]

On Thu, Jul 31, 2008 at 03:46:20PM -0400, Chris wrote:
> Bryce Harrington wrote:
>> On Thu, Jul 31, 2008 at 01:24:00PM -0400, Chris wrote:
>>> Hi,
>>> I'm a developer and require it for my own software.   I went into the 
>>> package and enabled it & rebuilt for the time being.
>>>
>>> Isn't there some software in Ubuntu that requires it?
>>> Xwindow application automated testing?
>>> Video recording of the desktop?  (I think this one just grabs the cursor)
>>> Debugging an app?
>>>
>>> I guess they disable it for security purposes.
>>> 
>>
>> There was a discussion at the last XDC about modules with security
>> issues.  I don't recall offhand if this particular one was on that list
>> but am guessing that to be the cause of the current settings.
>>
>> I've no opinion myself; you're the first I've heard ever mention using
>> it.
>>
>> Bryce
>>
>>   
> http://www.sandklef.com/xnee/
> I believe xnee uses XRecord (the headers refer to it).  So I think the  
> xorg record module should be enabled during the build.
>
> Chris

Got a debdiff to send me?

Bryce

-- 
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: xserver-xorg-core intrepid 2:1.4.99.905-0ubuntu4 missing librecord.so (Record module)

[Bryce Harrington]

On Thu, Jul 31, 2008 at 01:24:00PM -0400, Chris wrote:
> Timo Aaltonen wrote:
> > On Sat, 26 Jul 2008, Chris wrote:
> >
> >> Hello,  during the package build of xserver-xorg-core it does not
> >> --enable-record=yes.   I think it should, right?  The default 
> >> disables it.
> >
> > True, xorg-server 1.5 does not build it by default. Where do you need it?
> >
> > t
> >
> Hi,
> I'm a developer and require it for my own software.   I went into the 
> package and enabled it & rebuilt for the time being.
> 
> Isn't there some software in Ubuntu that requires it?
> Xwindow application automated testing?
> Video recording of the desktop?  (I think this one just grabs the cursor)
> Debugging an app?
> 
> I guess they disable it for security purposes.

There was a discussion at the last XDC about modules with security
issues.  I don't recall offhand if this particular one was on that list
but am guessing that to be the cause of the current settings.

I've no opinion myself; you're the first I've heard ever mention using
it.

Bryce

-- 
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: Did we really release 8.04?

[Bryce Harrington]

On Tue, Jul 15, 2008 at 09:16:04AM +0100, Matt Zimmerman wrote:
> On Mon, Jul 07, 2008 at 12:10:45PM +0300, Rakotomandimby Mihamina wrote:
> > Matt Zimmerman wrote:
> >> If you were unaware that this was going on, perhaps we could do a better 
> >> job
> >> of communicating this type of effort with the public.
> >
> > I would suggest a kind of summary of bugs (and their progression) on the  
> > front page of the ubuntu (and derivated) website.

The release notes contain a listing of known issues.

I've also been attempting to keep a short list of highlight issues just
for X.org drivers (https://wiki.ubuntu.com/X/Drivers), but honestly
things change so quickly it's impossible to keep such summaries
accurately up to date.

Bryce



-- 
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

Milestones report

[Bryce Harrington]

On Fri, Jul 11, 2008 at 11:07:59AM +0100, Matthew Paul Thomas wrote:
> Bryce Harrington wrote on 07/07/08 21:55:
> > On Mon, Jul 07, 2008 at 10:52:44PM +0300, Timo Jyrinki wrote:
> >> I'm not sure if it is even possible to sort bugs by the amount of
> >> duplicates?
> > 
> > Yes it is; in fact I have a script I'm going to make available soonish
> > which lets you do this with milestoned bugs.

Here's the new milestone bugs report:

 http://people.ubuntu.com/~bryce/Milestones/milestones_current.html

This gives a view of all of the milestones, and is sortable by a variety
of criteria including #dupes, #subscribers, #comments, age, etc.
It's cronned to update 4 times per day.

I've also included all the "later" milestoned bugs.  I suspect a good
bit of them could be obsolete, or if not perhaps need to be
re-milestoned.  (Maybe something Henrik's team would like to take a look
at?)

Bryce

-- 
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: Feature Request: Better partitioning wizard

[Bryce Harrington]

On Tue, Jul 08, 2008 at 02:28:58PM +0300, Steve Goodman wrote:
> I just got a new computer and wanted to try Ubuntu 8.04 on it. It was very
> easy to install and I got up and running pretty quickly.

Welcome to Ubuntu.  :-)

> So here's my request: The partitioning wizard that I was presented with
> during installation gave me two options: automatic and manual. I knew
> nothing about partitioning or about different Linux file systems when I
> installed, so I just did automatic. Since then I have read that a good
> practice is to have a partition for the OS + apps and a separate partition
> for user data (HOME).  So I request that you make the partitioning wizard
> guide me through that. It doesn't make sense that you only give the options
> of automatic or full manual without any kind of explanation or guidance
> unless you make "automatic" conform to best practices. I think something
> better would be to add an option that is not full automatic, but provides me
> with guidance, unlike the manual.

With partitioning, there is always a trade-off between providing more
flexibility by exposing more options, and risking scaring off a user who
knows nothing about partitioning (nor wishes to know).  I suspect the
current approach is designed for maximal simplicity for the latter type
of users.  It's true that splitting home from OS+apps has advantages,
but this approach presupposes at least a modest level of understanding
of what partitions are.

Adding an intermediary option between auto and manual does sound like it
would be handy.  I suspect one reason this isn't done currently is
because when we build ISOs we have to test them very thoroughly, and a
guided option would require significantly more testing effort than
either auto or manual, since there'd be additional steps involved.

> Now I'm trying to figure out how to
> repartition my drive to align with this practice, and I hope I won't have to
> reinstall everything. (Any guidance on this subject would make me very
> appreciative.)

First back up everything you want to keep to a USB key, CDRW, or spare
harddrive.  This probably includes everything under /home.

You may be able to resize the existing partition to shrink it, then
create a new partition and copy the files over.  If not, or if something
goes wrong, you can do a fresh reinstall, and then copy the files from
the USB stick.

For further advice, you might find http://answers.launchpad.com/ to be
of value.  Good luck!

Bryce

-- 
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: LTS and release methodology

[Bryce Harrington]

On Mon, Jul 07, 2008 at 11:14:59PM +0100, Alexander Jones wrote:
> 2008/7/7 Bryce Harrington <[EMAIL PROTECTED]>:
> > Frequently upstream decides $TECH is too horribly broken, so they create
> > $TECH+1 which is often a from-scratch rewrite, which often means trading
> > one set of bugs for another.  Unfortunately, upstream then takes the
> > step of dropping all ongoing support for $TECH (sometimes even making
> > the $TECH+1 incompatible with $TECH; or support for new hardware is
> > added only to $TECH+1 not $TECH; or bug reports we upstream get closed
> > as "plz reproduce with $TECH+1"), leaving us in a "damned if we do,
> > damned if we don't" situation.  At least, when we "do", upstream will
> > share the damnation load with us.  ;-)
> 
> It makes me wonder whether synchronised planning for a major cycle
> every 2 years would be a good idea to pitch.

I think you've arrived at a point Shuttleworth has been making for some
time now.  ;-)
 
> I tend to think (perhaps unfoundedly) that we have this problem where,
> rarely are more than a few parts of the platform truly stable and
> ready to receive ISV investment at any one time.

It seems like with FOSS, the only stable code is obsolete, unmaintained
code.  ;-)

More seriously, it seems that the decisions relating to new techs are
made fairly early on, like around alpha-1/2/3.  That is the optimum time
to make go/no-go decisions on new techs because it costs little to rip
them out.  After about alpha-4/5, we've become fairly invested and
change is possible but hard.  By -beta it's almost too late, as
disabling the new feature could impose as many problems as it'd solve.

Ideally, testing effort levels should parallel this, with heaviest
testing occurring during those early phases, and be targeted exactly to
the newest introduced functionality, so we can make well-informed
go/no-good decisions.  Unfortunately, merging and testing have an
inverse relationship - most testing gets done after -beta, precisely
when major changes are the hardest to make, and we end up looking for
low-risk workarounds and ways to paper over issues.

Bryce

-- 
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: LTS and release methodology

[Bryce Harrington]

On Mon, Jul 07, 2008 at 06:04:14PM +0100, Matt Zimmerman wrote:
> > Stability in software
> > Why is it that 8.04 “LTS” has such a wave of new features and new
> > versions of software that have not been time-tested to be stable? LTS
> > releases (meant to be exceptionally stable) should not have so many
> > additions to its feature set.
> 
> We didn't choose Firefox 3 because we wanted the latest features---quite the
> opposite!  While Firefox 2 may have been more mature at the time of release,
> it's also nearing two years of age and is scheduled for mothballing in
> December, just eight months after Ubuntu 8.04.
> 
> With Ubuntu Desktop LTS scheduled for three years of maintenance, Firefox 3
> was the only reasonable choice, paradoxical though it may seem.  If you've
> read the source code for Firefox security patches, you'll understand why!
> 
> While the initial version we included may have had some rough edges, we're
> in better shape for the long term by staying aligned with Mozilla.

I suspect this situation holds true throughout nearly all open source
projects.  I run into the same dilemma myself a lot in X.org.
Frequently upstream decides $TECH is too horribly broken, so they create
$TECH+1 which is often a from-scratch rewrite, which often means trading
one set of bugs for another.  Unfortunately, upstream then takes the
step of dropping all ongoing support for $TECH (sometimes even making
the $TECH+1 incompatible with $TECH; or support for new hardware is
added only to $TECH+1 not $TECH; or bug reports we upstream get closed
as "plz reproduce with $TECH+1"), leaving us in a "damned if we do,
damned if we don't" situation.  At least, when we "do", upstream will
share the damnation load with us.  ;-)

Bryce

-- 
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: Did we really release 8.04?

[Bryce Harrington]

On Mon, Jul 07, 2008 at 10:52:44PM +0300, Timo Jyrinki wrote:
> 2008/7/7 Emmet Hikory <[EMAIL PROTECTED]>:
> >  While we all tend to be busy much of the time, perhaps there are ways
> > that we can improve the view of bugs in need of attention, or
> > otherwise help understand which bugs are likely to be perceived as
> > painful to users at release time.
> 
> I think the single most needed feature in Launchpad regarding this
> would be the possibility for voting, as done in bugzilla.

I don't know if I necessarily agree with this.  Voting may feel good
from a user perspective and certainly couldn't hurt, but we already have
good ways of measuring user interest in particular bugs.  For instance,
Brian Murray captures bugs with many subscribers (which I link to from
http://people.ubuntu.com/~bryce/Xorg/status_current.html).  Proposing a
bug as a milestone is another extremely effective way of ensuring a
developer looks at a bug in time for a release - they might not actually
accept the milestone, but at least they will review the bug and consider
next steps for it.  The QA team is also quite responsive if you bring a
bug to their attention via mail, irc, etc.  For example, Leann maintains
a list of priority bugs for the Linux kernel that are closely tracked.

With voting, I would worry that we'd see all the usual problems with
gaming voting systems.  Someone might file a stub bug "Ubuntu crashes
randomly" with no details, post something like "plz vote this bug if u
want ubuntu to never crash again", and accumulate +10,000 votes to it.

And to the contrary, consider a bug that 100 people experience and each
submit as separate bug reports because they don't recognize that they're
each having the same bug (the recently fixed xcb-related issues would be
a good example of this, where it was the quantity of separate reports
that made it a priority).

> I'm not sure if it is even possible to sort bugs by the amount of
> duplicates?

Yes it is; in fact I have a script I'm going to make available soonish
which lets you do this with milestoned bugs.

> That's another measurement, though less certain since it already
> requires some capable Launchpad user to have browsed through the
> issue. Out of the ordinary users able to file a bug and use Launchpad,
> only a few really are interested enough to do actual
> triaging/searching/marking.

I like these measurements a lot more than voting because they're direct
correlations.  A bug with a lot of comments, or a lot of subscribers, or
a lot of dupes are all indications that lots of people would like to see
the issue addressed.

Triaging activity is also a hugely valuable direct correlation to
priority.  I also like that it serves as a reward to triaging activity -
if you experience a bug, and in filing it notice a bunch of unmarked
dupes, and then go through and dupe them together, summarize things, and
improve bug descriptions, then this work ought to serve to help flag the
resulting bug report as important.  An example of this that pops into
mind was Paul Dufresne's work on weird font sizes[0] - a hugely common
problem many people reported that required a slew of separate
hw-specific fixes to the -intel driver (LP: #151311).

I know you and a lot of people on this list do exactly this kind of work
all over Ubuntu, and it makes a huge difference.  We need more people
doing this.

Bryce

0:  
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/107320/comments/39

-- 
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: Did we really release 8.04?

[Bryce Harrington]

On Tue, Jul 08, 2008 at 12:25:40AM +0900, Emmet Hikory wrote:
> Scott Kitterman wrote:
> Setting up an automatic install / upgrade / remove / purge tester
> would be good, perhaps using piuparts or similar infrastructure,
> although this requires considerable resources in terms of local
> storage and processing power.  There are likely also several other
> automatable targets in terms of package state or archive consistency
> that would benefit from additional tools to track them.
> 
> > I'm not certain, however, that we need more bugs.  We need better bugs and 
> > we
> > need more fixes.  Suggestions?

I'd like to emphasize this point.  If you're trying to make water flow
through a piping system, you might first try turning up the incoming
flow, but eventually you need to switch to bigger pipes.

Ubuntu has seen huge growth in popularity, and I believe this is the
primary source of increased bug report flow.  More early testing would
be helpful in initiating this flow earlier on in the development cycle,
but what we really need is to increase the pipe size downstream so we
get an increased flow of fixes out the end.

> In recent times there seems to be some disconnect between the
> presence of bugs and the presence of developers working on these bugs.

>From user comments I often get the sense that if only we could get the
attention of "Those Developers" to work on bugs instead of whatever
other obscure work they're doing, these bugs wouldn't be a problem.  But
"those developers" are really us right here.  Some of us work for
Canonical, more are Ubuntu community members such as members of this
list, and the vast bulk are general community members in upstreams,
other distros, etc.

Unfortunately, there's a limited number of developers in existance.  We
can definitely improve things somewhat via better upstreaming of bugs,
however we run the risk of saturating the upstreams if we merely shifted
all of our unprocessed bug work there.

Ultimately I think the true solution is to increase the pipe flow by
increasing the number of people doing development work.  I am a strong
believer that those of us who *are* developers have a duty to find ways
to help other people become developers.  I feel the old adage applies,
"Give a man a fish, he'll eat for a day; teach a man to fish, he'll eat
for a lifetime."

So I would encourage looking at ways we can help the average bug
reporter take on more of the work of troubleshooting the bugs they
find.  After all, they by definition already have the necessary
equipment and environment for doing the testing.  The first step is to
have good, detailed documentation to make the process as 'paint by
numbers' as possible for them - I've been making attempts at doing this
via docs at http://wiki.ubuntu.com/X/, and by improving the description
section of frequently encountered bugs.  Second is to remove major
hurdles that are inhibiting them, such as to enable them to test against
recent git versions (which upstream often asks for), provide packages of
test versions, etc.

> We should also be better about chasing bugs that are fixed.  There
> are a number of bugs marked fixed upstream, or fixed in Debian, or
> with patches.  There are plenty of others for which there are good
> fixes in Fedora, SuSE, Gentoo, etc.  At least in those cases where we
> can track that a given bug exists in Ubuntu and a fix is available, we
> ought assiduously chase these: the more quickly we can go from a fix
> being available somewhere to a fix being available in Ubuntu, the more
> likely we are to be informed of a fix being available somewhere, and
> the better chance we have of a relatively small number of bugs.

Yes.  A huge part of my week-to-week work the past few months has been
exactly this.  I've scripted a few bits and pieces of my procedure, and
I dream of a day where the bulk of the process could be automated into a
web script.  User pastes in a git ID, which churns and spits out a .deb;
user installs, tests, and says, "This fixed it"; this triggers a
workflow bug for a developer to review and ok the integration of the
fix.  In addition to saving a lot of developer time, this would
eliminate most of the cycles between user / bug triager / developer that
make bug fixes take so long to produce.

Bryce

-- 
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: The non-evil graphics card

[Bryce Harrington]

On Wed, Jun 25, 2008 at 05:07:05PM +1000, Christopher Halse Rogers wrote:
> On 6/25/08, Markus Hitter <[EMAIL PROTECTED]> wrote:
> >  probably some of you already read that statement of kernel developers
> >  about the opening of graphics drivers:  >  www.linuxfoundation.org/en/Kernel_Driver_Statement>
> >
> >  Currently I'm using Intel's integrated graphics (G965, G31), but I'm
> >  about to upgrade to a "real" graphics card.
> >
> >  Which vendor should I prefer (or stay with the G31) in order to
> >  support proper open source graphics drivers? Is there a
> >  contraindication if I want to use CUDA-like technologies (I'm doing
> >  FEA, CFD) ?
> >
> For high-performance graphics cards you're pretty much limited to ATI
> or nVidia.  This makes the choice nice and easy: ATI/AMD have released
> specs, and employ at least one Xorg developer.  nVidia have done
> neither, and (unsurprisingly) haven't responded to nouveau's
> request(s) for documentation.

As a slight correction, actually Aaron Plattner, the current maintainer
of the open source -nv driver, has been employed by nVidia for a while
now.  (I couldn't say whether he has other duties at nVidia besides
maintain -nv or if it is his full time job.)

But I would concur that -ati seems to be a good bit further along than
-nv at present.


In fact, while -ati still has a ways to go before it's a suitably
complete replacement for -fglrx, it's been making such good progress
that I think we can reasonably foresee a day when we start talking about
moving -fglrx out of main over to multiverse or something.

Bryce



-- 
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: [packaging] LSB Package API

[Bryce Harrington]

On Sun, Jun 22, 2008 at 01:34:31PM -0700, Dan Kegel wrote:
> On Sun, Jun 22, 2008 at 11:02 AM, Denis Washington <[EMAIL PROTECTED]> wrote:
> > I don't think this is a corner case at all. For one thing, propietary
> > applications might just don't play a role _because_ there is no really
> > good distribution method for them - the typical chicken-and-egg problem.
> > (I'm not saying this is the only reason, but an important one.) We're
> > just not giving them an easy method of cross-distro integration. I think
> > providing this is important.
> 
> Sure, and that's why I support the LSB.
> Has everybody else given up on it?

I've probably missed part of this discussion, but wanted to inject one
anecdote.

Stand-alone binary package installers are nothing particular novel or
new; I'd gained experience using one, Autopackage, with Inkscape several
years ago.

Inkscape was virtually unknown at the time, so Autopackage gave us a
significant benefit of providing users a way to quickly get Inkscape on
distros that didn't yet include Inkscape.

Before Autopackage we would maintain our own .deb and .rpm rules and
specs, and we hoped Autopackage would obsolete that in favor of having a
"Universal Installer".  Yet that really never came to be.


First, Inkscape became recognized by distros, and they took over
handling our packaging work for us.  Meanwhile, the Autopackage
developers (who had been subsidizing us by maintaining the .autopackage
file for us), turned maintenance over to us.  So on the one hand we were
seeing our team workload *reduce* by relying on
packaging-system-specific stuff, and *increase* by using autopackage.

You might argue that it's different for proprietary software since
distros wouldn't adopt them.  Yet look at Xara, Flash, Opera,
proprietary Java, and so on to see that they can and do (to the level
they're able anyway).


Second, while in theory Autopackage promised "100% easy install,
anywhere", it was not without problems.  The issue always seemed to be
with low level dependencies that varied just subtly enough to break on
one distro or another.  So you ended up doing per-distro testing anyway
(and couldn't count on help from the distro once you figured out the
bug).

I think this is an important point to not dismiss by saying, "The design
wasn't as good as ours is", or "it just needed more testing", or
whatever.  The sad truth is that getting this to work 100% requires
invalidating Murphy's Law.  It's a broad fronted fight against entropy.

I felt like we had tried to change our support from N distros to 1, yet
ended up with N+1.


Third, as Inkscape grew we had to account for more dependencies.
Typically, there'd already be .rpm and .deb packages for them, but we'd
be stuck having to do the autopackage packaging work ourselves.

Now, you might think such an issue is irrelevant for proprietary
software since they'd be packaged with all dependencies already
included.  Yet consider dependencies beyond just dynamic libraries.
Consider if the app wants to interface with external programs or tools
(imagemagick, java, sqlite, ...) or to shared data repositories
(openclipart, fonts, etc.)

Eventually, you find yourself having to do a lot of work that distros
already take care of.


Anyway, to sum up, as much as I loved the idea of autopackage and helped
to advocate it, I really don't think the idea of a "universal installer"
is viable.  In the end it's a lot less effort to just collaborate with
each of the distros and have packaging optimized for each.  And I think
efforts put into creating yet more universal installer techs maybe
better invested in helping bring the existing packaging systems better
into consistency with one another, or establishing "best practices"
documents.

Bryce


-- 
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: about a crash after the lastest upgrade to this date

[Bryce Harrington]

Known issue - please see bugs #185311 and #87947.

On Fri, Jun 20, 2008 at 12:25:21AM +0200, Brahim LARCHET wrote:
> hello 
> 
> i get a bugg 
> on ubuntu the lastest ubuntu with openoffice 
> 
> [EMAIL PROTECTED]:~$ oowriter 
> [EMAIL PROTECTED]:~$ Locking assertion failure.  Backtrace:
> #0 /usr/lib/libxcb-xlib.so.0 [0x7f09c334697c]
> #1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_lock+0x15) [0x7f09c3346a15]
> #2 /usr/lib/libX11.so.6 [0x7f09c7010323]
> #3 /usr/lib/libX11.so.6(XCreateWindow+0x44) [0x7f09c7007d54]
> #4 /usr/lib/libgdk-x11-2.0.so.0(gdk_window_new+0x395) [0x7f09c2ef0c05]
> #5 /usr/lib/libgtk-x11-2.0.so.0 [0x7f09be57f4c8]
> #6 /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x10f) 
> [0x7f09c2384bcf]
> #7 /usr/lib/libgobject-2.0.so.0 [0x7f09c2398386]
> #8 /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x875) 
> [0x7f09c239a0d5]
> #9 /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83) [0x7f09c239a483]
> #10 /usr/lib/libgtk-x11-2.0.so.0(gtk_widget_realize+0x77) 
> [0x7f09be570957]
> #11 /usr/lib/openoffice/program/libvclplug_gtk680lx.so 
> [0x7f09be92876d]
> #12 /usr/lib/openoffice/program/libvclplug_gtk680lx.so 
> [0x7f09be92916a]
> #13 /usr/lib/openoffice/program/libvclplug_gtk680lx.so 
> [0x7f09be92982b]
> #14 /usr/lib/openoffice/program/libvclplug_gtk680lx.so 
> [0x7f09be901f64]
> #15 /usr/lib/openoffice/program/libvcl680lx.so [0x7f09ca8ad4ed]
> #16 /usr/lib/openoffice/program/libvcl680lx.so [0x7f09ca842322]
> #17 
> /usr/lib/openoffice/program/libvcl680lx.so(_ZN9TabDialogC2EP6WindowRK5ResId+0x5f)
>  [0x7f09ca87f1cf]
> #18 /usr/lib/openoffice/program/libsvx680lx.so [0x7f09b676d084]
> #19 /usr/lib/openoffice/program/libsvx680lx.so [0x7f09b6941db4]
> [EMAIL PROTECTED]:~$ 
> 
> 
> [EMAIL PROTECTED]:~$ OOO_FORCE_DESKTOP="gnome" oowriter 
> [EMAIL PROTECTED]:~$ Locking assertion failure.  Backtrace:
> #0 /usr/lib/libxcb-xlib.so.0 [0x7fdb2fdfa97c]
> #1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_lock+0x15) [0x7fdb2fdfaa15]
> #2 /usr/lib/libX11.so.6 [0x7fdb33ac4323]
> #3 /usr/lib/libX11.so.6(XCreateWindow+0x44) [0x7fdb33abbd54]
> #4 /usr/lib/libgdk-x11-2.0.so.0(gdk_window_new+0x395) [0x7fdb2f9a4c05]
> #5 /usr/lib/libgtk-x11-2.0.so.0 [0x7fdb2b0334c8]
> #6 /usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x10f) 
> [0x7fdb2ee38bcf]
> #7 /usr/lib/libgobject-2.0.so.0 [0x7fdb2ee4c386]
> #8 /usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x875) 
> [0x7fdb2ee4e0d5]
> #9 /usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83) [0x7fdb2ee4e483]
> #10 /usr/lib/libgtk-x11-2.0.so.0(gtk_widget_realize+0x77) 
> [0x7fdb2b024957]
> #11 /usr/lib/openoffice/program/libvclplug_gtk680lx.so 
> [0x7fdb2b3dc76d]
> #12 /usr/lib/openoffice/program/libvclplug_gtk680lx.so 
> [0x7fdb2b3dd16a]
> #13 /usr/lib/openoffice/program/libvclplug_gtk680lx.so 
> [0x7fdb2b3dd82b]
> #14 /usr/lib/openoffice/program/libvclplug_gtk680lx.so 
> [0x7fdb2b3b5f64]
> #15 /usr/lib/openoffice/program/libvcl680lx.so [0x7fdb373614ed]
> #16 /usr/lib/openoffice/program/libvcl680lx.so [0x7fdb372f6322]
> #17 
> /usr/lib/openoffice/program/libvcl680lx.so(_ZN9TabDialogC2EP6WindowRK5ResId+0x5f)
>  [0x7fdb373331cf]
> #18 /usr/lib/openoffice/program/libsvx680lx.so [0x7fdb23221084]
> #19 /usr/lib/openoffice/program/libsvx680lx.so [0x7fdb233f5db4]
> [EMAIL PROTECTED]:~$ 
> 
> 
> 
> 
> But with 
> 
> SAL_USE_VCLPLUGIN="gen" oowriter  
> 
> it works fine 
> 
> 
> 
> according to a VCL dev   the problem comes from libgtk or libX11
> 
> 
> 
> 
> hope it will help 
> 
> 
> 
> 
> 
> -- 
> 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: Making Canonical's/Ubuntu's contributions more visible

[Bryce Harrington]

On Thu, Jun 12, 2008 at 01:29:29PM +0200, Thomas Novin wrote:
> On Mon, 2008-05-19 at 14:00 +0200, Przemysław Kulczycki wrote:
> > One of the often accusations against Ubuntu is that it only takes from 
> > other projects (Debian, Red Hat, Novell/Suse...) and doesn't give back 
> > anything. Ubuntu should make it more visible for others to see what does 
> > it contribute to upstream/floss community.
> > Red Hat and Novell have websites listing their contributions to free 
> > software:
> 
> I just read an interesting article on Phoronix and while looking at the
> contributors you can see that Ubuntu/Canonical isn't mentioned at all.
>
> http://www.phoronix.com/scan.php?page=article&item=x_server_contributors&num=1
> 
> (go to page 3,4)

On page 1, Canonical is mentioned.  It seems Daniel's contributions were
all credited to Nokia, although a portion of them must have been done
while he worked for Canonical.

Also note they're measuring only the xserver there.  The vast bulk of
the bugs (and the area I focus mostly) are in the drivers.

Bryce

-- 
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: [ubuntu-marketing] Making Canonical's/Ubuntu's contributions more visible

[Bryce Harrington]

On Wed, Jun 04, 2008 at 11:11:05PM +0800, John McCabe-Dansted wrote:
> On Tue, May 27, 2008 at 6:20 PM, Bryce Harrington <[EMAIL PROTECTED]> wrote:
> >> It could perhaps make things even easier for developers, but thats
> >> another kettle of fish.
> >
> > I'd be interested in hearing your further thoughts on this.  (I've had
> > my own thoughts on this, but would love to see other's ideas.)
> 
> Well the development aspects of Ubuntu aren't as polished as the
> end-user facing applications. Unlike firefox and OO, pbuilder and
> make-kpkg don't really "just work".
> 
> In principle, developing could be as simple as doing "dev edit
> " finding whatever you wanted to change, perhaps
> changing a constant like MAX_COL from 80 to 160 in your favourite
> editor, doing a "dev test-sandbox", and perhaps a "dev install".
> Perhaps then there could be
> run a simple "dev share" command which would the developer to, at
> their leisure, annotate each of their patches and upload them
> somewhere others could re-use and comment on them.

I think you're onto some good ideas here.

This probably sounds odd, but the thing that "sold" me on Ubuntu/Debian
over gentoo and emerge was of all things 'apt-get source'.  I use that a
gazillion times a month, and I love how easy it makes it to get in and
poke at stuff.

You're definitely right that the steps involved in creating a package
once you've got the source is not as straightforward as it could be for
a newb (I've got it in finger muscle memory now, but the first few weeks
were tough).  It would be awesome if there was a simplified workflow
something like: 

1.  $ apt-get source foo

2.  $ cd foo; #hack hack

Allow the user to edit the code tree directly, no worries about
patch systems, etc.

3.  $ sudo apt-get build

Run from within the source tree, this wrappers all the work of
generating a patch from the current source tree's changes and adding
it to the package's patch management system (or adding a patch
management system if one doesn't exist), running debuild, set up a
pbuilder environment if needed, run pbuilder to produce the
(unsigned) debs, and place them in the parent directory.

Would be nice to not have to run it as root, but not sure that
there's an easy way of running pbuilder as non-root.

4.  $ apt-get share [bug id | package-name]

Like you mention, presents user with a list of their outstanding
patches applicable for the given bug or package (or all in the
system), prompts for annotation, allows gpg-signing, and uploads to
the appropriate place.  Maybe a PPA, or maybe sending directly to a
Launchpad bug ID, with request to add to ubuntu and/or debian.

Of course, the above paints over a huge amount of implementational
complexity.  Perhaps this could only be achieved for certain well-formed
packages. 

Bryce

-- 
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: hardy release freeze, coming soon to an archive near you

[Bryce Harrington]

On Sun, Jun 01, 2008 at 06:26:38PM +0200, Vincenzo Ciancia wrote:
> Il giorno gio, 10/04/2008 alle 13.59 -0700, Steve Langasek ha scritto:
> > 
> > >
> > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/137234
> > 
> > > because it always worked before gutsy, and it is a pity that when I
> > go
> > > around the world at conferences, instead of showing my shiny ubuntu
> > > desktop and make good publicity to it, I have to say that ubuntu
> > breaks
> > > my vgaout hence I want someone else's laptop (no, I don't reboot in
> > > windows, that would be too bad publicity for myself :) ).
> > 
> > Thanks, I've asked one of the X developers to follow up with you on
> > this.
> 
> Any news on this one? I didn't receive any reply on that bug for a long
> time.

It needs tested against a git version of the driver and forwarded
upstream if it still occurs.

Bryce


-- 
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: Reusing old specs

[Bryce Harrington]

On Sun, May 04, 2008 at 11:59:30PM +0200, Przemys??aw Kulczycki wrote:
> Hi!
> I have a suggestion for development of Intrepid Ibex.
> The Ubuntu's blueprints page currently lists over 2000 specs.
> https://blueprints.launchpad.net/ubuntu
> Some of them are implemented, but not marked as such.
> Some of them have been deferred, but are not marked as such.
> Some of them became obsolete.
> And finally some of them might be good for Ubuntu 8.10, at least after  
> some cleanups.
> Maybe a separate spec should be created to cleanup old specs?
> Good but old ideas shouldn't be forgotten nor stopped in the middle.

It does seem some cleanup could be beneficial.  In going through the
blueprints looking for Xorg-related ones, I've assembled a list of ones
that look like Duplicate/Obsolete ones here:

  http://wiki.ubuntu.com/X/Blueprints


Hopefully now that we have brainstorm.ubuntu.com, that will serve as a
better forum for raw ideas, and blueprints will become used less for
that and more for detailed proposals.

Bryce

-- 
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: Ubuntu boot speed fall in Hardy

[Bryce Harrington]

On Sat, May 10, 2008 at 10:58:12AM +0100, Sitsofe Wheeler wrote:
> I've noticed that Ubuntu's boot speed seems to have taken a fall in
> Hardy. Anecdotally I believe that Gutsy was the fastest but from a
> viewable stats perspective the fall can be seen in Feisty versus Hardy
> on
> https://wiki.ubuntu.com/BootCharting#head-dca0372aa8fd490a9717ad0c72c9b400c236a581
>  
> While not as slow as other distros it is a shame to see things slow down a 
> bit.

It's curious Fedora 9 showed such poor results compared with Ubuntu (and
compared with Fedora 8), given that they are listing fast Xorg boot as a
feature.  http://fedoraproject.org/wiki/Features/OneSecondX

I'll be interested to see if the fast Xorg boot stuff in the upcoming
Xorg 1.5 will boost our boot numbers, or if the Xorg boot time just gets
lost in the noise.

Bryce


-- 
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: Suggestion to make remote recovery easier

[Bryce Harrington]

On Tue, May 06, 2008 at 06:39:25PM +0100, Andrew Sayers wrote:
> I've now updated the page that Pedro kindly started at
> https://wiki.ubuntu.com/Recovery/Remote - this includes all the ideas
> I've got so far.  This is my first Ubuntu development thing, so yes, any
> help very much appreciated!

Well then welcome aboard!  :-)

> Then we can add a page to the help wiki, describing how to create a user
> for port-forwarding, how to create an SSH-only user, and how to make
> that user an administrator.  That would give intermediate users all the
> tools they need to set up a permanent remote help relationship that they
> can tune to their particular needs.

One other thing to consider is configuring an external router for the
ssh traffic, in case of routers that lock out ssh traffic.

> Help with managing a system is an interesting use case, but I'm not sure
> if we want to be targeting it with this particular solution.  I agree
> that sane defaults with powerful configuration is a good approach for
> users that know what the configuration options mean, but newbies with a
> broken system should be asked as few questions as possible (especially
> when they're paying for a long-distance phone call).  Also, I think
> you're talking about an ongoing remote help relationship, rather than an
> emergency one shot thing.

It's occurred to me that most of my non-technical friends and family who
use Linux, have a semi-formal relationship with their "tech guy"
(usually me, but not always).  I don't think this is unique to Linux -
most of these people bugged me with Windows questions before converting
(and indeed, a large part of their motivation to switch was me saying,
"Hey, I'd like to help, but honestly my windows knowledge is diminishing
since I no longer use it.")

So I've wondered if things like remote restore / remote management could
enable Ubuntu to expand further.  I know I have friends and folks out of
town I could move over to Linux if it were simpler to set them up for
remote operations.

> 1) Rather than create a "remote-recovery" user on the recovery machine,
> why not just let the expert log in as root?  Given all the other
> security measures, it wouldn't be any less secure, and would avoid the
> need to have a password kicking about.

Hmm, this sounds dangerous.
 
> 2) Experts that have just finished a remote recovery session are
> probably the best people there are for providing high quality bug
> reports.

Possibly, and a good point, although I'm not sure any special handling
for bug reporting is needed for these kinds of people.

Bryce


-- 
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: Making apt-get powercut-proof

[Bryce Harrington]

On Mon, May 05, 2008 at 08:57:36PM +0100, Andrew Sayers wrote:
> A friend of mine was upgrading to Hardy, and (so far as we can tell)
> there was a power cut while it was halfway through, which left his
> system in a not-especially-useful state.  I think the best solution is
> to have a /etc/init.d/{apt-get|dpkg} script that checks for
> half-finished installs, and restarts them if necessary.  If so, which
> (or both) would be better, and is there anyone here that knows enough
> about the two to suggest a complete set of commands that need to be run?
>  Also, is this something we should be doing in an Ubuntu-specific way
> (e.g. from X), or should I take this idea to Debian?

Another use case (which I've run into a few times) is if you are doing
the upgrade unattended, it pauses for confirmation about a change to a
config file, and [battery runs out | wife turns off computer | system
locks up due to a suspend/resume bug].

I don't recall exactly what apt commands I needed to get things going
again.  In one particularly nasty case, network manager had been left in
some sort of weird inconsistent state and I couldn't get it to connect
to the network, so ended up having to do a bunch of low level wireless
network hackery to get it going again.  I suspect that was atypical, but
it makes me wonder if power failures during certain packages could be
much worse than others...

Anyway, making upgrades more resilient to being restarted in the middle
would be quite welcomed.

Bryce

-- 
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: synaptics driver for xorg: new feature

[Bryce Harrington]

On Tue, Apr 29, 2008 at 02:20:17PM -0700, Ted Gould wrote:
> On Tue, 2008-04-29 at 19:02 +0200, Oliver Grawert wrote:
> > unlikely since it requires SHMConfig enabled by default in xorg which we
> > wont do by default since it rips open quite a security hole (everyone,
> > even remotely logged in people can change the trackpad settings for the
> > locally logged in user). 
> 
> It seems like if it grabbed the information from XRandR instead of
> getting it through the xorg.conf file.  He is modifying the driver, I'm
> not sure if it can touch other parts of X.

Not sure what information you're referring to, but if it's the current
rotation, that isn't written to Xorg.0.log (nor obviously to xorg.conf
unless it's a statically configured rotation, which wouldn't be relevant
here anyway).

However, I agree the trackpad behavior while rotated can be quite
confusing, but I think Ogra's right that this needs to be solved at a
different level.

If someone files a bug or blueprint about this, let me know and I can
inquire upstream about it.

Bryce

-- 
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: Configuring X with multiple drivers available

[Bryce Harrington]

On Fri, Apr 25, 2008 at 02:22:57PM +0200, Przemys??aw Kulczycki wrote:
> Hi!
> AFAIK, in Hardy the new display configuration tool doesn't allow to  
> choose a driver for your graphics card.

The new Screen Resolution tool does graphics changes dynamically via
Xrandr, without modifying the xorg.conf.  Changing graphics drivers
requires modifying the xorg.conf, which is why the new tool lacks this
capability.

If you mostly just want to select between -ati and -fglrx, or -nv and
-nvidia, you should probably be looking at Jockey and EnvyNG.

Bryce


-- 
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: Brainstorm ML and Ubuntu's own summer of code?

[Bryce Harrington]

Btw, I've itemized a few ideas for some Ubunt-X projects here:
https://wiki.ubuntu.com/X/Projects

On Thu, Apr 24, 2008 at 12:29:45PM -0700, Bryce Harrington wrote:
> Hi Nicolas,
> 
> This sounds like a great idea, let us know if you get strong interest
> from students to participate, I'd be happy to mentor for Xorg oriented
> tasks.
> 
> Bryce
> 
> On Thu, Apr 24, 2008 at 09:17:28PM +0200, Nicolas Deschildre wrote:
> > Hi!
> > 
> > [You are receiving this mail because either you are suscribed to the
> > ubuntu-devel-discuss/ubuntu-qa ML or you are registered as a moderator
> > in Ubuntu Brainstorm]
> > 
> > Hardy is now out, and the UDS and FOSScamp are next. The ideas at the
> > Ubuntu Brainstorm website will, or will not be a great source of
> > inspiration during these events, we will see.
> > 
> > Meanwhile, if you are interested as an Ubuntu developer to discuss how
> > to make the website more efficient for you, to discuss its mechanism,
> > or if you are interested as a Brainstorm moderator to comment your
> > tools, please join the new Brainstorm Mailing list at
> > https://launchpad.net/~brainstorm-dev.
> > 
> > I would also like to take this opportunity to introduce an idea that I
> > see as a natural follow-up to the Brainstorm website: an event similar
> > to the Google Summer of Code, that would be launched every development
> > cycle. Basically the concept would be similar to GSoC except that the
> > motivation factor would not be money but the fact that the
> > contribution would be included in Ubuntu's next version (granted it is
> > completed on time). The event would cover Ubuntu "extensions", and
> > involves coding, but also packaging, documentation, i18n,  A
> > proposed schedule would be: selection of tasks at the UDS, one month
> > for the "pupils" selection process, and the time remaining before
> > feature freeze to complete the tasks. Finally, to make potential
> > contributors benefit from it, the "pupils" would be asked to put
> > online a "report" where they would explain how they worked.
> > That's a rough idea yet that I'd like to discuss at the FOSScamp if
> > people are interested. Please comment :)
> > 
> > Nicolas
> > 
> > -- 
> > 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

-- 
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: Brainstorm ML and Ubuntu's own summer of code?

[Bryce Harrington]

Hi Nicolas,

This sounds like a great idea, let us know if you get strong interest
from students to participate, I'd be happy to mentor for Xorg oriented
tasks.

Bryce

On Thu, Apr 24, 2008 at 09:17:28PM +0200, Nicolas Deschildre wrote:
> Hi!
> 
> [You are receiving this mail because either you are suscribed to the
> ubuntu-devel-discuss/ubuntu-qa ML or you are registered as a moderator
> in Ubuntu Brainstorm]
> 
> Hardy is now out, and the UDS and FOSScamp are next. The ideas at the
> Ubuntu Brainstorm website will, or will not be a great source of
> inspiration during these events, we will see.
> 
> Meanwhile, if you are interested as an Ubuntu developer to discuss how
> to make the website more efficient for you, to discuss its mechanism,
> or if you are interested as a Brainstorm moderator to comment your
> tools, please join the new Brainstorm Mailing list at
> https://launchpad.net/~brainstorm-dev.
> 
> I would also like to take this opportunity to introduce an idea that I
> see as a natural follow-up to the Brainstorm website: an event similar
> to the Google Summer of Code, that would be launched every development
> cycle. Basically the concept would be similar to GSoC except that the
> motivation factor would not be money but the fact that the
> contribution would be included in Ubuntu's next version (granted it is
> completed on time). The event would cover Ubuntu "extensions", and
> involves coding, but also packaging, documentation, i18n,  A
> proposed schedule would be: selection of tasks at the UDS, one month
> for the "pupils" selection process, and the time remaining before
> feature freeze to complete the tasks. Finally, to make potential
> contributors benefit from it, the "pupils" would be asked to put
> online a "report" where they would explain how they worked.
> That's a rough idea yet that I'd like to discuss at the FOSScamp if
> people are interested. Please comment :)
> 
> Nicolas
> 
> -- 
> 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

Wacom config hacks (was: An example of how things should *not* be done)

[Bryce Harrington]

> Please anybody, don't take this e-mail personally.

In general, if you need to preface emails with this statement, it's
probably a clue you should do more fact checking.

Also, note that there is a ubuntu-x@ mailing list specifically for X
issues that would be more effective to bring up X issues on.

> Regarding the wacom enabled/disabled by default issues, by googling
> better, I found the culprit:
>
> https://bugs.launchpad.net/ubuntu/+source/wacom-tools/+bug/42553

No.  That bug was mostly cosmetic IMHO, aside from the .xsession-errors
file growth in Kubuntu.  Note there were dozens of other similar bug
reports that derived from this issue.  In fact, a lot of users confused
the wacom errors in their Xorg logs for the cause of their (unrelated) X
problems.  The bug that actually motivated this change was #83860 from
Henrik Omma.  I talked with him at length about the pros/cons of this
change, but given that the "fix" for tablets was an ugly hack, and that
it was only needed for a small subset of tablet users anyway (who could
still uncomment the entries in xorg.conf to enable it), and that it
resulted in a completely unusuable Ubuntu for users needing accessible
login, we decided it was better to go with the current approach.

In theory, input-hotplug would have been available for Hardy, but that
turned out to be less mature than expected.

> and then Bryce himself *disabled* wacom setup *without* using his own
> patch to conditionally re-enable the setup in xorg whenever
> /dev/input/wacom exists. I can't know why.  There is no apparent
> reason for this choice, that was just a quick decision to close the
> bug.

Not sure how you missed it, but I was quite explicit in the bug you
reference in stating why my patch was not viable: "However, as others
point out in this and other wacom threads, this [patch] obviously would
break things for wacom users who did not have their wacom attached when
they [install] the system..."

So your patch and mine would just "accidentally" work, if the user
happened to have the tablet attached during installation.

Bryce



-- 
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: mulimonitor on intel using displayconfig-gtk (was Question on multi-head Dapper->Hardy upgrades)

[Bryce Harrington]

On Thu, Feb 14, 2008 at 10:45:16PM +, (``-_-) -- Fernando wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Thursday 07 February 2008 19:11:26 Bryce Harrington wrote:
> > Alright, I think I can modify displayconfig-gtk when in BPX mode to not
> > offer to set up multi-head (which it would do incorrectly).  
> > 
> > Bryce
> 
> On Gutsy I could pretty use without any issues, two monitors (either cloning 
> or extended desktop) by setting them up with displayconfig-gtk.
> But since I upgraded to Hardy, It wont even detect my Intel 855 (using the 
> new generic Intel driver, but i810 also wont work).
> Any tips on how can I set multimonitor?
> grandr aint all that good, either (clicking on the monitor icons makes it 
> crash).
> 

displayconfig-gtk relies on use of Xinerama for doing multi-monitor.
The -i810 driver uses Xinerama; -intel uses Xrandr.

displayconfig-gtk determines your driver by parsing it from xorg.conf;
recent upstream changes make dexconf no longer list the driver (although
I think Timo restored that for Ubuntu recently).  There is no mechanism
provided by Xorg to list the current driver, except booting X with no
config and scanning Xorg.0.log to see what it picked.  (Upstream prefers
going in a direction where less is included in xorg.conf anyway.)

Presently, the way to set up dual-monitor on Intel graphics hardware is
to use the xrandr command line tool.  For instance, this is the line I
put in my .xprofile:

  xrandr --output VGA-0 --auto --left-of DVI-0 --auto

See `man xrandr` for more info.

Alternately, you can configure your xrandr setup in your xorg.conf.  For
details on doing this, here is a pretty good resource:

   http://www.thinkwiki.org/wiki/Xorg_RandR_1.2

(It would be nice to have a doc like this but specific to Ubuntu
available from wiki.ubuntu.com).

Obviously, in either case the user is having to do some un-Ubuntu-ish
manual configuration work, which has been our intent to get away from.
In essense, what we need is a tool like displayconfig-gtk, but that uses
xrandr rather than Xinerama, and does its configuration "live" with
xrandr, instead of by modifying xorg.conf.  Ideally, like with
displayconfig-gtk, it would be helpful to implement in a split
frontend/backend fashion where the backend is window-system independent
and includes the bulk of the functionality, so it would be easy for
someone to make a Qt-ified version of the frontend for Kubuntu.
Further, it would be nice to implement this in a way that it would be
acceptable to upstreams, so we can share the maintenance load.

With the above goals in mind, I've taken a shot at implementing a tool
derived from libxrandr, xrandr, and gnome-control-center's display
capplet:  http://bryceharrington.org/drupal/display-config-0

I've only had 2 weeks so far working on it, but I hope to post a test
version by next week, once I have it functioning properly.  (Currently
it's applying the changes properly, but then the monitors lose sync.)

RedHat is also working on a gui xrandr config tool, but taking a
different approach; not sure what to make of it yet.

Bryce

-- 
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