Mutter / GNOME Shell are no longer covered by the GNOME MRE

[Christopher James Halse Rogers]

Hello all!

It has been brought to the SRU team’s attention that mutter has 
landed a significant new feature in the 46.1 point release¹.


The GNOME MicroReleaseException policy historically exists on the basis 
that the GNOME release and testing process broadly matches SRU policy, 
so duplicating that process by performing a full SRU review on GNOME 
point releases would be unnecessary work. Since mutter no longer 
appears to have the same understanding of that process as we do, mutter 
SRUs will not be covered by the GNOME MRE going forward.


Mutter & GNOME Shell point releases may still be acceptable under the 
normal micro release process; this can be checked on a case-by-case 
basis.


(This notification may also be found on Ubuntu Discourse: 
https://discourse.ubuntu.com/t/mutter-gnome-shell-are-no-longer-covered-by-the-gnome-mre/45218/1)


¹: Specifically, explicit sync support 
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3300.




--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Fw: MRE request: virtualbox

[Christopher James Halse Rogers]

Hi there!

Sorry for the delay in addressing this.

This does seem like Virtualbox fits well enough in the HWE category (and 
probably has sufficient upstream testing) for special SRU treatment.


I've taken the liberty of reworking the wiki page 
https://wiki.ubuntu.com/VirtualboxUpdates to make it easy to review and 
accept Virtualbox SRU bugs. I've done this to the best of my 
understanding, but you're the domain expert, so please check my work :)


Particularly: it's my understanding that this does *not* require any 
special coordination with the kernel - the Ubuntu kernel contains 
Virtualbox guest driver modules, but these are upstream kernel modules, 
and the Ubuntu kernel build does not build virtualbox-dkms modules at 
kernel-build time¹


I've also marked a couple of places (with ***s) where the test case 
instructions were not clear to me. The intent with test case 
documentation is that it should be detailed enough that anyone reading 
the bug could perform the steps and we could be confident that they have 
exercised the expected tests.


Specifically, the questions I had were:

* instructions for installing/removing the guest additions from the iso 
pack (or pointers to documentation for that)


* What the “various other tests” are - you mention changing 
configuration and vboxmanage?


* Do we need to verify that installing virtualbox guest packages 
*outside* a VM does not interfere with the system? There seems to have 
been at least one bug raised about that in the past.


Sorry again for the delay,

Chris Halse Rogers (SRU team member)


¹: Unlike, for example, zfs-dkms, where the kernel build process pulls a 
specific version of the zfs-dkms package from the archive, builds it, 
and includes the built modules in a package.


On 15/9/23 20:23, Gianfranco Costamagna wrote:

Hello, I found that an MRE request was acked in 2015 for virtualbox, but since 
then, the workflow has changed a lot, so
I'm asking again for an MRE exceptiom related to virtualbox.
I already created the wiki page with the process, I will try to update it to 
match the current expectation criteria

https://wiki.ubuntu.com/VirtualboxUpdates

thanks for considering it

G.






- Messaggio inoltrato -

Da: Martin Pitt 
A: "costamagnagianfra...@yahoo.it" 
Cc: "technical-bo...@lists.ubuntu.com" ; 
"secur...@ubuntu.com" 
Inviato: mercoledì 4 novembre 2015 alle ore 02:26:02 CET
Oggetto: Re: MRE request: virtualbox


Hello Gianfranco,

Gianfranco Costamagna [2015-10-29 18:50 +0100]:

I would like to apply for a micro release exception for Virtualbox


Since [1] we actually did away with (most) explicit MREs, and adjusted
the SRU policy to generalize those.

[1] 
https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-September/001152.html


Upstream:

   - Micro releases happen from low-volume stable branches,
     approximately once every two months.

   - Stable branches are supported with bug fixes for some years
(normally 5 years + 6 months or more).

   - Upstream commits are reviewed by members of the Virtualbox Server
     Engineering team.

   - All commits to stable branches are evaluated wrt. potential
     regressions and signed off by the Virtualbox team.

   - Unit tests and regression tests are run on multiple platforms per
     push to the source code repository. In addition, there are more
     extensive test suites run daily and weekly.

   - Each micro release receives extensive testing between code freeze
     and release. This includes the full functional test suite,
     performance regression testing, load and stress testing and
     compatibility and upgrade testing from previous micro and
     minor/major releases.

   - Tests are run on all supported platforms (currently amd64 and i386).


This satisfies the current policy, so this looks fine for SRUing.

Martin






--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Request MRE approval for PostgreSQL

[Christopher James Halse Rogers]

On Thu, Jan 25 2024 at 14:59:27 -0500, Sergio Durigan Junior 
 wrote:

On Tuesday, January 23 2024, Christopher James Halse Rogers wrote:


 On Thu, Jan 18 2024 at 11:21:18 -0500, Sergio Durigan Junior
  wrote:

 On Thursday, January 18 2024, Christopher James Halse Rogers wrote:


  On Wed, Jan 17 2024 at 21:09:58 -0500, Sergio Durigan Junior
   wrote:

  On Wednesday, January 17 2024, Christopher James Halse Rogers
 wrote:


   Hi there!

  Hey, Chris,
  Thanks for the review.


   On Sat, Jan 13 2024 at 00:08:35 -0500, Sergio Durigan Junior
wrote:

   Hello,
   In the same spirit as Christian's formal request for an SRU
   exception
   for open-vm-tools, Athos and I would like to formally request
 the
   approval of the PostgreSQL MRE wiki page.
   We (the Server team) have been doing such MREs for a number 
of

  years
   now, but it came to our attention recently that we don't
 actually
  have
   the MRE policy for PostgreSQL formally defined in a wiki 
page,

 as
  is
   usual for more recent packages.
   I don't know much about the history behind why such page 
doesn't

   exist,
   but we would like to fix it by proposing the following 
document:

 https://wiki.ubuntu.com/PostgreSQLUpdates

   It looks like a good documentation of current practice, and
  current
   practice looks (mostly) good.
   A couple of questions:
   * Checking the PostgreSQL policy, they say that a 
pg_dump/restore

 cycle between minor updates is *normally* not needed. Has it
  *ever*
 been needed in the past? Presumably we would not take such 
an

  update
 (at least, not under this MRE)?

  Athos and I have been doing this MRE for a bit more than a year
 now,
  and
  so far we have never seen a situation where a pg_dump/restore 
cycle

  was
  needed.  I'm Cc'ing Christian, who used to handle the MREs 
before

  us, in
  case he knows something more.


   * I notice a number of the updates are of the form “Fix FROB
  index. If
 you have any FROB indexes, you must run FROBINATE REINDEX to
 get
  the
 fixes”. How do we notify users of this? It's in the
 changelog,
  which
 is not nothing, and a debconf notice would be *way* too
 disruptive. Is there anywhere else we should be pushing such
  “you
 really should check this” notifications?
  That's a good question.  My default answer for such scenarios 
tends

  to
  be "let's put it in a d/NEWS file", but I appreciate the fact
 that not
  everybody will have apt-listchanges installed.  Nonetheless, 
maybe
  that's a good compromise between having the entries buried in 
the

  changelog vs. having a debconf notice.  WDYT?

  Ooooh, yes. d/NEWS would definitely be an improvement!

 Cool.
 Just to clarify: does this mean that this request is approved
 pending
 the d/NEWS addition to the wiki page?


 I'd like an answer to the other question before approving - what
 happens if a pg_dump/pg_restore cycle *is* required across a minor
 update. Presumably the answer is “that update will not fall under 
this
 MRE”, but we should document both that decision and how we expect 
to

 pick up when this would apply.


OK, that is a good question.

I thought about it yesterday, and my answer here pretty much aligns 
with

what you expected.  But let me give a little bit of context first.

It's important to say that, to the best of my knowledge, there has 
*not*

been any PostgreSQL minor release that required a pg_dump/pg_restore
cycle ever since we started doing these MREs.  And that, I believe, is
for a good reason: upstream must know that they would be shooting
themselves in the foot in case they required such drastic measure from
their users.  And I must say that upstream seems pretty reasonable to
me, given my interactions with them for the past 3 years (give or 
take).
So, IMHO, the chances of us seeing such a requirement in a minor 
release

are very, very low.

On top of that, let me assure you that Athos and I (and the whole 
Server
team, if I'm being honest) would straight out refuse to proceed with 
the

MRE if we saw a breaking change/operation like this being required.
There is just no way to guarantee the data integrity of our users'
databases in such case, so having this being part of a LTS release is 
a

no-no from our standpoint.

Therefore, in a nutshell: if PostgreSQL upstream ever requires a
pg_dump/pg_restore cycle to be performed as part of a minor release
update, then that update will not fall under this MRE.

 Once that has a satisfactory answer, yes, it looks good to approve 
to

 me.


Hopefully my answer is enough, but please let me know if you'd like 
more

details.

BTW, I will take the liberty of updating the wiki page to reflect the
answer above, and also to include the d/NEWS requirement as previously
discussed.


That looks good to me now; approved. I'll update the 
StableReleaseUpdates page.


Thanks!
Chris



--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe 

Re: Requesting an SRU exception approval for open-vm-tools

[Christopher James Halse Rogers]

On Wed, Jan 24 2024 at 15:50:21 +0100, Christian Ehrhardt 
 wrote:

On Wed, Jan 17, 2024 at 7:45 AM Christopher James Halse Rogers
 wrote:


 Hello! Sorry for the delayed response.

 On Mon, Jan 8 2024 at 12:23:56 +0100, Christian Ehrhardt
  wrote:
 > Hi,
 > after formerly (pre 2018) people often reporting issues of not 
having
 > an LTS that could work fully well with the latest VMware we have, 
now

 > for more than five years, done regular backports of open-vm-tools.
 > But a recent misunderstanding between Steve and myself has 
identified
 > that we missed to put this down clearly enough as a properly 
approved

 > "special case".
 >
 > To be fair - In the past, AFAIK, we have not always done/needed 
such

 > exceptions for things that go to SRU under "other safe cases" [1],
 > but this case is not so much "safe" as more "a usually accepted 
kind

 > of risk for platform enablement". And since it caused
 > misunderstanding let us document this now, to avoid the same
 > misunderstanding to happen again in the future.
 >
 > Hence I've created [2] as a wiki page documenting this case.
 > I would now ask the SRU team for a review, discussion and 
hopefully
 > eventually sign-off to acknowledge this case and add its link to 
the

 > known special cases [3].

 This broadly looks sensible, and open-vm-tools is a reasonable
 (virtual)-HWE case.


Thanks,
today I wondered about missing an answer, only to get help finding [1]
and in turn finding this in my spam folder.
So much for the reasons behind my extra week of delay to answer this.


 I've taken the liberty of reorganising the wiki page to stick a
 "Process" section up the top, and added some extra process verbiage.


Thanks, any order that works better for you works for me as well.


 Please take a look and check that what I've moved around and added
 still makes sense and captures what you need.


Yeah it is ok to focus on what matters and have most down there in
"Past context" as you put it.

 There's an open question there, too - at what point after (or 
before?)
 a release do we first consider a backport of the open-vm-tools 
package?


Yeah, I see you also added that as "Question" in the wiki.
Answering here and updating it there ...

In our experience we usually aimed for that to be 6 weeks (but often
ended up with a bit more until we found the time).
I think we can state 6 weeks in the exception, and if it takes more
time to get prepared there is no harm to it.

Was there anything else you needed to consider this approvable?


That was my only question. I approve this MRE, and will update the SRU 
page accordingly.







--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Request MRE approval for PostgreSQL

[Christopher James Halse Rogers]

On Thu, Jan 18 2024 at 11:21:18 -0500, Sergio Durigan Junior 
 wrote:

On Thursday, January 18 2024, Christopher James Halse Rogers wrote:


 On Wed, Jan 17 2024 at 21:09:58 -0500, Sergio Durigan Junior
  wrote:
 On Wednesday, January 17 2024, Christopher James Halse Rogers 
wrote:



  Hi there!

 Hey, Chris,
 Thanks for the review.


  On Sat, Jan 13 2024 at 00:08:35 -0500, Sergio Durigan Junior
   wrote:

  Hello,
  In the same spirit as Christian's formal request for an SRU
  exception
  for open-vm-tools, Athos and I would like to formally request 
the

  approval of the PostgreSQL MRE wiki page.
  We (the Server team) have been doing such MREs for a number of
 years
  now, but it came to our attention recently that we don't 
actually

 have
  the MRE policy for PostgreSQL formally defined in a wiki page, 
as

 is
  usual for more recent packages.
  I don't know much about the history behind why such page doesn't
  exist,
  but we would like to fix it by proposing the following document:
https://wiki.ubuntu.com/PostgreSQLUpdates

  It looks like a good documentation of current practice, and
 current
  practice looks (mostly) good.
  A couple of questions:
  * Checking the PostgreSQL policy, they say that a pg_dump/restore
cycle between minor updates is *normally* not needed. Has it
 *ever*
been needed in the past? Presumably we would not take such an
 update
(at least, not under this MRE)?
 Athos and I have been doing this MRE for a bit more than a year 
now,

 and
 so far we have never seen a situation where a pg_dump/restore cycle
 was
 needed.  I'm Cc'ing Christian, who used to handle the MREs before
 us, in
 case he knows something more.


  * I notice a number of the updates are of the form “Fix FROB
 index. If
you have any FROB indexes, you must run FROBINATE REINDEX to 
get

 the
fixes”. How do we notify users of this? It's in the 
changelog,

 which
is not nothing, and a debconf notice would be *way* too
disruptive. Is there anywhere else we should be pushing such
 “you
really should check this” notifications?

 That's a good question.  My default answer for such scenarios tends
 to
 be "let's put it in a d/NEWS file", but I appreciate the fact that 
not

 everybody will have apt-listchanges installed.  Nonetheless, maybe
 that's a good compromise between having the entries buried in the
 changelog vs. having a debconf notice.  WDYT?


 Ooooh, yes. d/NEWS would definitely be an improvement!


Cool.

Just to clarify: does this mean that this request is approved pending
the d/NEWS addition to the wiki page?


I'd like an answer to the other question before approving - what 
happens if a pg_dump/pg_restore cycle *is* required across a minor 
update. Presumably the answer is “that update will not fall under 
this MRE”, but we should document both that decision and how we 
expect to pick up when this would apply.


Once that has a satisfactory answer, yes, it looks good to approve to 
me.


Cheers,
Chris



--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Request MRE approval for PostgreSQL

[Christopher James Halse Rogers]

On Wed, Jan 17 2024 at 21:09:58 -0500, Sergio Durigan Junior 
 wrote:

On Wednesday, January 17 2024, Christopher James Halse Rogers wrote:


 Hi there!


Hey, Chris,

Thanks for the review.


 On Sat, Jan 13 2024 at 00:08:35 -0500, Sergio Durigan Junior
  wrote:

 Hello,
 In the same spirit as Christian's formal request for an SRU
 exception
 for open-vm-tools, Athos and I would like to formally request the
 approval of the PostgreSQL MRE wiki page.
 We (the Server team) have been doing such MREs for a number of 
years
 now, but it came to our attention recently that we don't actually 
have
 the MRE policy for PostgreSQL formally defined in a wiki page, as 
is

 usual for more recent packages.
 I don't know much about the history behind why such page doesn't
 exist,
 but we would like to fix it by proposing the following document:
   https://wiki.ubuntu.com/PostgreSQLUpdates


 It looks like a good documentation of current practice, and current
 practice looks (mostly) good.

 A couple of questions:

 * Checking the PostgreSQL policy, they say that a pg_dump/restore
   cycle between minor updates is *normally* not needed. Has it 
*ever*
   been needed in the past? Presumably we would not take such an 
update

   (at least, not under this MRE)?


Athos and I have been doing this MRE for a bit more than a year now, 
and
so far we have never seen a situation where a pg_dump/restore cycle 
was
needed.  I'm Cc'ing Christian, who used to handle the MREs before us, 
in

case he knows something more.

 * I notice a number of the updates are of the form “Fix FROB 
index. If
   you have any FROB indexes, you must run FROBINATE REINDEX to get 
the
   fixes”. How do we notify users of this? It's in the changelog, 
which

   is not nothing, and a debconf notice would be *way* too
   disruptive. Is there anywhere else we should be pushing such 
“you

   really should check this” notifications?


That's a good question.  My default answer for such scenarios tends to
be "let's put it in a d/NEWS file", but I appreciate the fact that not
everybody will have apt-listchanges installed.  Nonetheless, maybe
that's a good compromise between having the entries buried in the
changelog vs. having a debconf notice.  WDYT?


Ooooh, yes. d/NEWS would definitely be an improvement!



--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Request MRE approval for PostgreSQL

[Christopher James Halse Rogers]

Hi there!

On Sat, Jan 13 2024 at 00:08:35 -0500, Sergio Durigan Junior 
 wrote:

Hello,

In the same spirit as Christian's formal request for an SRU exception
for open-vm-tools, Athos and I would like to formally request the
approval of the PostgreSQL MRE wiki page.

We (the Server team) have been doing such MREs for a number of years
now, but it came to our attention recently that we don't actually have
the MRE policy for PostgreSQL formally defined in a wiki page, as is
usual for more recent packages.

I don't know much about the history behind why such page doesn't 
exist,

but we would like to fix it by proposing the following document:

  https://wiki.ubuntu.com/PostgreSQLUpdates


It looks like a good documentation of current practice, and current 
practice looks (mostly) good.


A couple of questions:

* Checking the PostgreSQL policy, they say that a pg_dump/restore cycle 
between minor updates is *normally* not needed. Has it *ever* been 
needed in the past? Presumably we would not take such an update (at 
least, not under this MRE)?


* I notice a number of the updates are of the form “Fix FROB index. 
If you have any FROB indexes, you must run FROBINATE REINDEX to get the 
fixes”. How do we notify users of this? It's in the changelog, which 
is not nothing, and a debconf notice would be *way* too disruptive. Is 
there anywhere else we should be pushing such “you really should 
check this” notifications?


Ta,
Chris Halse Rogers



--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Requesting an SRU exception approval for open-vm-tools

[Christopher James Halse Rogers]

Hello! Sorry for the delayed response.

On Mon, Jan 8 2024 at 12:23:56 +0100, Christian Ehrhardt 
 wrote:

Hi,
after formerly (pre 2018) people often reporting issues of not having 
an LTS that could work fully well with the latest VMware we have, now 
for more than five years, done regular backports of open-vm-tools. 
But a recent misunderstanding between Steve and myself has identified 
that we missed to put this down clearly enough as a properly approved 
"special case".


To be fair - In the past, AFAIK, we have not always done/needed such 
exceptions for things that go to SRU under "other safe cases" [1], 
but this case is not so much "safe" as more "a usually accepted kind 
of risk for platform enablement". And since it caused 
misunderstanding let us document this now, to avoid the same 
misunderstanding to happen again in the future.


Hence I've created [2] as a wiki page documenting this case.
I would now ask the SRU team for a review, discussion and hopefully 
eventually sign-off to acknowledge this case and add its link to the 
known special cases [3].


This broadly looks sensible, and open-vm-tools is a reasonable 
(virtual)-HWE case.


I've taken the liberty of reorganising the wiki page to stick a 
"Process" section up the top, and added some extra process verbiage. 
Please take a look and check that what I've moved around and added 
still makes sense and captures what you need.


There's an open question there, too - at what point after (or before?) 
a release do we first consider a backport of the open-vm-tools package?




--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Please remove src:glusterfs-11.0 from mantic-proposed, see #2035127 and #2031905

[Christopher James Halse Rogers]

On Tue, Sep 12 2023 at 13:54:00 -0300, Andreas Hasenack 
 wrote:

Hi,

could someone please remove src:glusterfs-11 (and its binary builds)
from mantic-proposed?

I previously asked on irc[1], but have now filed a separate bug[2]
speficically for this removal.


1. 








2. 



Thanks for the reminder. I've now done this. Enjoy your samba rebuild!

Is it deliberate, or an oversight¹, that samba migrated out of 
proposed with a freshly-unsatisfiable Recommends?


¹: Or a “not yet important enough to spend the effort fixing”.




-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: MRE request for OpenVPN

[Christopher James Halse Rogers]

Hi Lena,

On Tue, Jun 6 2023 at 10:25:15 -0700, Lena Voytek 
 wrote:

Hi Chris,

Thank you for looking into this!

On Thu, Jun 1, 2023 at 5:56 PM Christopher James Halse Rogers 
 wrote:

Hi Lena,

 Sorry this has taken so long for someone to get to. Review below:

 On Mon, Feb 27 2023 at 13:25:25 -0700, Lena Voytek
  wrote:
 > Hello,
 >
 > I would like to request a Microrelease Exception for the OpenVPN
 > package in Ubuntu Jammy and Focal. I created a wiki page 
containing

 > relevant information here:
 >
 > https://wiki.ubuntu.com/OpenVPNUpdates

 This is a well-written and usefully-detailed MRE process proposal.

 My only question to pin down in the proposal would be exactly what
 releases we'll be considering. Certainly releases in the Full stable
 support category; presumably also releases made in old-stable 
support.

 Would we also be expecting to pull in snapshots in the git-tree-only
 support timeframe under this MRE?
The MRE would ideally support full stable and old stable since both 
support versioned releases, source tarballs, and provide fixes that 
may otherwise not be added by the security team. I think the git-tree 
only lifecycle should be ignored unless a relevant bug fix is 
provided in which case it should be added through the normal SRU 
process. I updated the document to show this.


 > Having an MRE would allow us to take advantage of OpenVPN's stable
 > release policy, providing many existing bug fixes to Focal and 
Jammy,

 > which are using 2.4.x and 2.5.x respectively.
 >

 After having a bit of a browse of the 2.6 release branch, I'm not
 entirely happy that OpenVPN's understanding of “stable release”
 matches the SRU policy.

 *Most* of the patches on that branch look like either fixes we want 
or
 changes to code we don't care about (Windows, *BSD, etc), but 
there's a

 thread of patches to DCO which seem to be feature additions at least
 one of which¹ modifies user-visible behaviour in
 backwards-incompatible ways. This is helpfully called-out in the 
2.6.2

 release notes², under “User visible changes”, but this suggests
 that we'll *at least* need a process like the for proposed bind9
 exception where someone explicitly checks the release notes and 
calls

 out anything that might be a problem.
I think this is a reasonable case for checking through release notes 
and announcements to see if there are any problematic changes. I've 
drafted an additional section, process item, and template item in the 
document, similar to my changes to bind9.


 The 2.5 release branch looks better in this regard, although a 
sampling
 there includes a commit³ which includes “Regression warning: 
shared

 secret setups are left out of the backoff logic.” in the commit
 message (and nothing in the release notes), and at least one new
 feature commit (implementing auth-token-user⁴).
Luckily the auth-token-user addition is already in Jammy, but this 
would otherwise be a good example of a feature to note for discussion 
prior to uploading a new release. This is the same case for 
connect-retry backoff modification commit, which does change behavior 
slightly to fix timeout issues (bug #1010). It is unfortunate that 
the note does not show up in the release notes though. I also don't 
see any other instances of a regression warning statement in a commit 
message in the repository.


 I lack the context to decide whether or not these regressions are
 concerning and whether these new features are really bug fixes⁵, 
but
 with the context I have I'm not sure that a standing MRE for 
OpenVPN is

 appropriate.

 I note that 2.4.x (in Focal) has already dropped out of *all* 
support

 categories. An SRU to update to Focal to 2.4.12 still might be
 appropriate - the degree of testing, both upstream and in-archive,
 appears good - and that one-off upload would be the only result of 
this

 MRE for Focal anyway.
I agree that Focal should be a one-time upload to get up to date with 
2.4. I've made it more explicit in the document.


I've floated this with some of the rest of the SRU team, and I think 
I'm going to (narrowly) reject this MRE request.


That said, I'm only rejecting a blanket MRE here. The test plan you've 
documented on https://wiki.ubuntu.com/OpenVPNUpdates is good, updates 
to OpenVPN would be valuable, and upstream seems *mostly* trustworthy 
(although a little less trustworthy than bind9).


I'm not saying that we shouldn't update Focal to 2.4.12. I think that 
we *should* update Focal to 2.4.12 - that looked like a pretty safe set 
of changes - and I would accept such an SRU. I'd also be happy to 
consider 2.5.9 for Jammy, although I'm less confident there.


Upstream microreleases of OpenVPN can be considered for SRUing (as for 
*all* packages!), but I think we should keep the additional friction of 
“here are the changes, and why they are safe” SRU review rather 
than presume upstream microreleases are safe.




 It's *also* quite possible that 

Re: Symbols files for C++ libraries for Ubuntu main

[Christopher James Halse Rogers]

On Fri, Jun 9 2023 at 12:10:07 -0700, Steve Langasek 
 wrote:

Hi Seb,

On Fri, Jun 09, 2023 at 02:27:02PM +0200, Sebastien Bacher wrote:
 I would like to ask if there is any chance the MIR team would 
reconsider
 their position on the topic (at least until the day we have a 
somewhat

 working solution we can use)?



 which also included those types of changes



 - _Znam@Base 2.0~b2-0ubuntu3
 + _Znaj@Base 2.0~b2-0ubuntu4
 +#MISSING: 2.0~b2-0ubuntu4# _Znam@Base 2.0~b2-0ubuntu3


 I personally don't understand why we have those symbols existing on 
armhf
 which don't exist on amd64. Nor why _Znam@Base is becoming 
_Znaj@Base nor

 how we are supposed to handle such cases


Passing them through c++filt may help explain:

$ echo _Znam@Base | c++filt
operator new[](unsigned long)@Base
$ echo _Znaj@Base | c++filt
operator new[](unsigned int)@Base
$

There are various C++ functions whose signature will change based on 
the

architecture word length.

.symbols files support various kinds of globbing etc to be able to 
express
this logically (e.g., you could say '_Zna[mj]@Base' instead of 
listing two

different symbols as optional), but as you've found, it's an onerous,
iterative process to identify all the ways C++ symbols vary across
architectures and then encode this in a .symbols file.  And in this 
case,
the symbol isn't part of the library's public ABI anyway, this is 
just a

function from the base C++ library!

 4. doing those tweaks need to be done manually since it's not only 
applying
 the diff but also adding optional keyword at places, I got one 
wrong and it

 failed to build again



 add one more symbol specific to risvc
 
http://launchpadlibrarian.net/647875197/libcupsfilters_2.0~b2-0ubuntu6_2.0~b2-0ubuntu7.diff.gz


Yep.

 I understand the motivation for wanting a symbol file but I agree 
with what
 Robie, what's the benefit. In that case we spent a few hours to end 
up with
 a .symbols which as over 150 '(optional)' entries, that doesn't 
protect us
 much better than just not having a .symbols or using -c0 but still 
has a

 high cost.


I wouldn't say that it doesn't protect you.  It's a pain to set up 
initially
and as you note, you can even have to do further fix-ups as a result 
of
toolchain changes, as the set of template functions and other C++ 
sugar from
outside of the library that gets exported as ELF symbols can change.  
It

DOES have a high cost, but in the end it provides the same level of
protection against accidental ABI breakage as it does for C libraries.

It would be nice to have better consistent tooling around ABI 
checking for
C++ libraries.  I think the KDE team had some tools around automating 
the
generation of symbols files - it does require two passes, first to 
build on
all archs and then to merge the results.  But in principle that's 
better

than whack-a-mole.

We could also consider using abi-compliance-checker instead of 
symbols files
for C++ libraries.  There is a dh-acc debhelper addon, but I've never 
used
it.  We are currently using abi-compliance-checker for the ABI 
analysis of
armhf for the move to 64-bit time_t; it's unmaintained upstream, but 
it does
seem to work pretty well - the vast majority of issues we've 
encountered
with it, when trying to run it over the entire Ubuntu archive, have 
been due
to header files that #include headers from packages they don't depend 
on, or
collections of headers that can't all be included together.  Both of 
these
are issues of much less significance when it's the maintainer doing 
the
work.  It would require the same sort of two-pass setup process as 
the KDE

tools, though, and if it has to be done per-arch (probably), it's more
awkward to set up because a-c-c .dump files aren't ascii that you can 
scrape
from the build logs of failed builds - but it might be a more 
reliable tool

over the long term than dpkg-gensymbols for C++ libraries.


In the Mir (not MIR ☺) team we've periodically been annoyed by 
maintaining symbols files for C++¹, and have experimented with both 
abi-compliance-checker and abigail. None of those experiments have 
ended up sticking, though, for reasons which I'm not fully aware of. 
Alan Griffiths and Michał Sawicz did most of that investigation; I'll 
see if they can help shed light on problems we encountered.


If we *can* get (one of) the ABI checking tools working they'll be more 
valuable than a symbols file anyway, as they actually check that ABI 
didn't change rather than just that the symbol strings in the DSO match.


¹: and we're playing on *easy* mode, where we, as upstream, use a 
linker script to export only symbols we intend to export.




Downside: symbols files also let you track what version of a package a
symbol was added in, which lets packages' versioned dependencies on
libraries be no stricter than actually necessary.


I don't speak for the MIR team, I have no objection to them relaxing 
the
requirement of .symbols files for C++ libraries in main.  Just 
offering 

adsys SRU

[Christopher James Halse Rogers]

There's an Jammy/Lunar adsys SRU¹ in the queue at the moment, and I 
think it needs bringing to up to the list for discussion.


The changelog looks like approximately 9 months of normal feature 
development. The diff against Jammy is >3MB in size (due largely to 
significant vendored-dependency churn it seems). The relevant part of 
SRU policy - “Other safe cases”² - allowing feature addition, says 
“If existing software needs to be modified to make use of the new 
feature, it must be demonstrated that these changes are unintrusive, 
have a minimal regression potential, and have been tested properly”. 
It looks like adsys is well tested, but I'm not sure about these being 
minimal changes or with minimal regression potential ☺.


It's true that we've done a wholesale backport of adsys 0.9.2³ to 
Jammy in the past; however, in that case the changes were mostly listed 
bugfixes or FTBFS fixes, and the feature addition was shipping a 
*Windows* binary.


I'm writing this to ubuntu-release@ for two main reasons:

1. It seems valuable to include adsys updates in LTS releases; however, 
I'm not sure that the scope of changes (and seeming criticality of the 
system - “failures might prevent users from logging in” seems 
pretty bad) falls under the existing delegation of power from the Tech 
Board to the SRU team.
2. There's a *lot* of vendored code churn, and from the SRU perspective 
I have no information as to whether that's appropriate. I understand 
that the Go ecosystem does not follow our ideas of stable releases and 
there's a real tension here - it's a huge amount of work to vet 
dependency updates, and such updates are *likely* to include bug fixes. 
I don't think “we just update all our vendored dependencies each SRU 
to whatever upstream is most recently shipping” is an appropriate 
standard, though. I'm not sure what *is* the right balance, though.


So, in summary: I have two questions - does this exceed SRU authority, 
and need Tech Board approval, and what level of justification is there 
for wide ranging vendored code updates in the SRU?.



¹: https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/2020682
²: https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
³: 
https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/1982351/comments/10




--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: MRE request for OpenVPN

[Christopher James Halse Rogers]

Hi Lena,

Sorry this has taken so long for someone to get to. Review below:

On Mon, Feb 27 2023 at 13:25:25 -0700, Lena Voytek 
 wrote:

Hello,

I would like to request a Microrelease Exception for the OpenVPN
package in Ubuntu Jammy and Focal. I created a wiki page containing
relevant information here:

https://wiki.ubuntu.com/OpenVPNUpdates


This is a well-written and usefully-detailed MRE process proposal.

My only question to pin down in the proposal would be exactly what 
releases we'll be considering. Certainly releases in the Full stable 
support category; presumably also releases made in old-stable support. 
Would we also be expecting to pull in snapshots in the git-tree-only 
support timeframe under this MRE?



Having an MRE would allow us to take advantage of OpenVPN's stable
release policy, providing many existing bug fixes to Focal and Jammy,
which are using 2.4.x and 2.5.x respectively.



After having a bit of a browse of the 2.6 release branch, I'm not 
entirely happy that OpenVPN's understanding of “stable release” 
matches the SRU policy.


*Most* of the patches on that branch look like either fixes we want or 
changes to code we don't care about (Windows, *BSD, etc), but there's a 
thread of patches to DCO which seem to be feature additions at least 
one of which¹ modifies user-visible behaviour in 
backwards-incompatible ways. This is helpfully called-out in the 2.6.2 
release notes², under “User visible changes”, but this suggests 
that we'll *at least* need a process like the for proposed bind9 
exception where someone explicitly checks the release notes and calls 
out anything that might be a problem.


The 2.5 release branch looks better in this regard, although a sampling 
there includes a commit³ which includes “Regression warning: shared 
secret setups are left out of the backoff logic.” in the commit 
message (and nothing in the release notes), and at least one new 
feature commit (implementing auth-token-user⁴).


I lack the context to decide whether or not these regressions are 
concerning and whether these new features are really bug fixes⁵, but 
with the context I have I'm not sure that a standing MRE for OpenVPN is 
appropriate.


I note that 2.4.x (in Focal) has already dropped out of *all* support 
categories. An SRU to update to Focal to 2.4.12 still might be 
appropriate - the degree of testing, both upstream and in-archive, 
appears good - and that one-off upload would be the only result of this 
MRE for Focal anyway.


It's *also* quite possible that 2.5.9 might be an appropriate SRU for 
Jammy. I'm just not confident (at the moment) that we can delegate the 
“this is an appropriate SRU” decision entirely to OpenVPN upstream, 
which is what a standing MRE effectively is.



Thank you for considering this request. Please let me know if you need
any additional information.

Lena Voytek



If there's additional context you can provide that negates my concerns, 
or if you think we can propose a half-way process (like that proposed 
for bind9), feel free to update us.


Chris Halse Rogers

¹: 
https://github.com/OpenVPN/openvpn/commit/321b04fac8d254fe884472109042d8fb83d7
²: 
https://github.com/OpenVPN/openvpn/commit/3577442530eb7830709538a2e21282b98a97d4f2
³: 
https://github.com/OpenVPN/openvpn/commit/d8dee82f1129ac6d3e4bcdc867726f5d64798dc7
⁴: 
https://github.com/OpenVPN/openvpn/commit/d38d6d08558e2f52cc9bcdc928ca9c4fca61
⁵: At least *some* of the DCO fixes appear to be infrastructure for 
fixing security flaws.




--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Req: thermald special case

[Christopher James Halse Rogers]

Hi!

On Mon, Sep 26 2022 at 10:57:48 +0800, Koba Ko  
wrote:

hi,
may I have an update for the thermald?

Thanks
Koba Ko

On Tue, Sep 20, 2022 at 1:24 PM Koba Ko  wrote:


 hi,
 for thermald, it's necessary upgrade thermald to 2.5.0 for jammy,
 For some issues, it's almost the same with 2.5.0 after backporting 
the needed.

 please kindly approve for thermald,
 here's the wiki of thermald
 https://wiki.ubuntu.com/StableReleaseUpdates/thermald

 Thanks
 Koba Ko


It's not entirely clear to me what you want to do here.

If you need to fix some bugs in Jammy, and updating to thermald 2.5.0 
is basically the same as applying all the patches you'd need, then you 
can just upload 2.5.0 and justify it in the SRU bug.


A wiki page such as you've drafted would be necessary if you want to 
get an on-going special process for SRUing thermald. I'm not sure 
that's necessary - it seems to have generally been possible to 
cherry-pick any necessary hardware enablement in the past without too 
much issue.


Has something changed in thermald maintenance that suggests we're going 
to need to regularly take new upstream releases rather than 
cherry-picking hardware enablement patches as necessary?




--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: systemd-oomd issues on desktop

[Christopher James Halse Rogers]

On Mon, Jun 13 2022 at 14:18:53 +0200, Lukas Märdian 
 wrote:

Am 10.06.22 um 12:17 schrieb Sebastien Bacher:

Le 10/06/2022 à 11:40, Julian Andres Klode a écrit :

The bug reports we see show that systemd-oomd is working correctly:
The browser gets killed, the system remains responsive without 
having

become unresponsive as would be the usual case.


It might be working 'correctly' but is not perceived as such by 
users. I've seen regular complains from users since the release 
stating that their browser or code editor got closed in front on 
them without warning, on a machine they had been using for years 
with the same configuration and software without issue.


They might be getting short in resources but in practice they never 
experienced a sluggish system due to it and just see the feature as 
buggy.


I agree with Julian in that systemd-oomd in general seems to be 
working as expected. Its purpose is all about jumping in _before_ a 
system reaches its point of no return and unresponsive swapping death.


Therefore, I feel like we should not increase the recommended 
"SwapUsedLimit=90%" default much higher, i.e. option (1), as that 
could lead to situations where it's already too late to clear some 
memory and thus defeat the purpose of having sd-oomd.



OTOH, receiving those bug reports shows that sd-oomd is not yet 
properly optimized either, killing people's "important" applications 
first (such as the browser). Especially, if the browser applies some 
memory monitoring on its own to discard/unload unused tabs and free 
up memory, as suggested by Olivier.



The option (3) recommended by Nick, could be one viable option in the 
Ubuntu context (only 1G swap available) for the time being, until we 
can have a proper upstream solution (using notifications and hooks) 
[1]. Thanks for bringing this up with the upstream developers, Michel!


I wonder if we could use a more selective approach, though, using 
"OOMScoreAdjust=" in the systemd.exec environment (i.e. Gnome-Shell 
launcher in Ubuntu's context, as sd-oomd is currently only enabled on 
Ubuntu Desktop) [2], to reduce the probability of certain "important" 
apps being killed first, e.g. by maintaining an allow-list of such 
apps.


Of course we do not want to introduce different classes of apps 
randomly, but would need to come up with a proper policy of which 
apps would be eligible to have a lower "OOMScoreAdjust" value. I feel 
like having individual mechanisms on the application layer to keep 
memory consumption under control, such as a browser's tab unloading, 
could be a fair eligibility criteria.


I'm not sure the extent to which this would be acceptably backported to 
22.04, but I understand that we actually have all the infrastructure in 
place so that GNOME Shell could adjust the *foreground* application's 
OOM score.


systemd-oomd has generally been a great improvement on my 16GiB RAM + 
2GiB swap laptop, turning ~1/day hard lockups due to OOM conditions 
into something being relatively-cleanly terminated, but it would be 
nicer still if it could preferentially kill Evolution chugging along in 
the background rather than the Firefox window I'm currently using (or 
terminal window I'm currently compiling in).


That, and a notification that an OOM condition was averted and 
 was killed to avoid it would be a significant improvement 
in behaviour.


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [Packaging] Repackaged DisplayCAL as Dummy Package

[Christopher James Halse Rogers]

(Losing some context because I was apparently not subscribed)

> > The justification for this is that the chromium-browser package
currently
> > installs the snap of chromium. This is no different, except that it
adds a
> > the flathub repository (the defacto-default repository for flatpak)
if
> > necessary whereas only one snap repository exists (by design).

My understanding was that the chromium-browser dummy-package was to
migrate people who currently have the chromium-browser package
installed to the snap, so the desktop team could stop maintaining the
actual chromium-browser deb.

Since the displaycal package doesn't appear to exist in any Ubuntu
release that Launchpad tracks, I don't think we need to migrate any
existing users of displaycal?

On the other hand, if you want to install displaycal by default in the
Ubuntu Studio flavour, then I'm not sure that seeding a package that
adds the flathub remote and installs the flatpak in preinst is going to
work to do that. I'm not entirely familiar with Ubiquity, but my
understanding is that does a file-copy from the live instance + some
post-processing rather than actually going through a dpkg install
process. That means the preinst wouldn't be run on the installing
system, but is instead presumably run during germinate on one of the
livecd builders. I would not expect the livecd builders to have access
to flathub (or any host outside of the LP build infrastructure).

For default-installed snaps we appear to have an explicit seeding
process, and snapd has a concept of seeded snaps. Perhaps what should
be done is to make an equivalent process for seeding flatpaks?


-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Packaging policy discussion: After=network-online.target

[Christopher James Halse Rogers]

On Thu, May 13 2021 at 17:34:58 +0100, Dimitri John Ledkov 
 wrote:

On Thu, May 13, 2021 at 4:12 PM Steve Langasek
 wrote:


 Hi there,

 On Wed, May 12, 2021 at 05:52:07PM +1000, Christopher James Halse 
Rogers wrote:
 > There's an nfs-utils SRU¹ hanging around waiting for a policy 
decision on
 > use of the After=network-online.target systemd unit dependency. 
I'm not an
 > expert here, but it looks like part of my SRU rotation today is 
starting the

 > discussion on this so we can resolve it one way or another!

 > I am not an expert in this area, but as I understand it, the 
tradeoff here

 > is:
 > 1. Without a dependency on After=network-online.target there is 
no guarantee
 > that the network interface(s) will be usable at the time the 
nfs-utils unit
 > triggers, and nfs-utils will fail if the relevant ntwork 
interface is not

 > usable, or
 > 2. With a dependency on After=network-online.target nfs-utils 
will reliably
 > start, but if there are any interfaces which are configured but 
do not come

 > up this will result in the boot hanging until the timeout is hit.

 > In mitigation of (2), there are apparently a number of default 
packages
 > which already have a dependency on After=network-online.target, 
so boot

 > hanging if interfaces are down is the status quo?

 From one of the comments in the bug report, I gathered that systemd 
upstream
 (who, specifically?) was taking a position that distributions 
should not use
 After=network-online.target.  I think this is entirely unhelpful; 
the target
 exists for this purpose, it is not required for systemd internally 
to get

 the system up but exists only for other services to depend on.

 There are risks of services not starting on boot because the 
network-online
 target is not reached.  However, that is not the same thing as a 
"hung
 boot", because other services will still start on their own, and 
things like
 gdm and tty don't depend on network-online.target, *unless* you're 
in a
 situation where you've introduced a dependency between the 
filesystem and
 network-online.  This is possible when we're talking about nfs, 
because the
 same system might both export nfs filesystems and mount them from 
localhost.

 But I'm not sure it should block this specific change.

 > The obvious thing to do here would be to follow Debian, but as 
far as I can
 > tell there is not currently a Debian policy about this - the best 
I can find
 > is an ancient draft of a best-practises-guide² suggesting that 
pacakages
 > SHOULD handle networking dynamically, but if they do not MUST 
have a

 > dependency on After=network-online.target

 > As far I understand it, handling networking dynamically requires 
upstream

 > code changes (although maybe fairly simple code changes?).

 It does require upstream code changes; not always simple.  And it's 
not
 always *correct* to make upstream code changes instead of simply 
starting
 the service when the system is "online"; you can find a number of 
examples
 in Ubuntu of services that it only makes sense to start once your 
network is

 "up" - e.g. apt-daily.service, update-notifier, whoopsie, ...


 There are issues with the network-online target, to be sure.  There 
is not a

 clear definition of the target, and there have definitely been
 implementation bugs in what does/does not block the target.  I've 
had
 discussions with the Foundations Team in the past about this but it 
has yet

 to result in a specification.

 My working definition of what network-online.target SHOULD mean is:

  - at least one interface is up, with routes
  - all interfaces which are 'optional: no' (netplan sense) are up
- including completion of ipv6 RA and ipv4 link-local if enabled 
on the

  interface
  - there is a default route for at least one configured address 
family
  - attempts to discover default routes for other configured address 
families

have completed (success or fail)
  - DNS is configured

 Thinks that must not block the network-online target:
  - interfaces that are marked 'optional: yes'
  - address sources that are listed in 'optional-addresses' for an 
interface

  - default route for an address family for which no interfaces have
addresses

 At least historically, neither networkd nor NetworkManager has 
fulfilled
 this definition.  It would be nice to get there, but the first step 
is

 having some agreed definition such as the above so that we can treat
 deviations as bugs.



If netplan.io can implement that would be nice. I.e. either
synthetically (i.e. by generating a service unit on the fly that calls
systemd-networkd-wait-online with extra arguments specifying all the
non-optional interfaces) , or by creating a new binary which is
"netplan-wait-online" which will be wanted by network-online.target
and perform all of the above.

 > It seems unlikely that, whatever 

Packaging policy discussion: After=network-online.target

[Christopher James Halse Rogers]

Hello everyone,

There's an nfs-utils SRU¹ hanging around waiting for a policy decision 
on use of the After=network-online.target systemd unit dependency. I'm 
not an expert here, but it looks like part of my SRU rotation today is 
starting the discussion on this so we can resolve it one way or another!


I am not an expert in this area, but as I understand it, the tradeoff 
here is:
1. Without a dependency on After=network-online.target there is no 
guarantee that the network interface(s) will be usable at the time the 
nfs-utils unit triggers, and nfs-utils will fail if the relevant ntwork 
interface is not usable, or
2. With a dependency on After=network-online.target nfs-utils will 
reliably start, but if there are any interfaces which are configured 
but do not come up this will result in the boot hanging until the 
timeout is hit.


In mitigation of (2), there are apparently a number of default packages 
which already have a dependency on After=network-online.target, so boot 
hanging if interfaces are down is the status quo?


The obvious thing to do here would be to follow Debian, but as far as I 
can tell there is not currently a Debian policy about this - the best I 
can find is an ancient draft of a best-practises-guide² suggesting 
that pacakages SHOULD handle networking dynamically, but if they do not 
MUST have a dependency on After=network-online.target


As far I understand it, handling networking dynamically requires 
upstream code changes (although maybe fairly simple code changes?).


It seems unlikely that, whatever we decide, we'll immediately do a full 
sweep of the archive and fix everything, so it looks like our choice is 
between:


1. The long-term goal is to have no After=network-online.target 
dependencies in default boot (stretch goal: in main). Whenever we run 
into a package-fails-if-network-is-not-yet-up bug, we patch the code 
and submit upstream. Over time we audit existing users of 
After=network-online.target and patch them for dynamic networking, as 
time permits.


2. We don't expect to be able to reach no After=network-online.target 
dependencies in the default boot, so it's not a priority to avoid them. 
Whenever we run into a package-fails-if-network-is-not-yet-up bug, we 
add an After=network-online.target dependency.


Option (1) seems to be the technically superior option (and is 
recommended by systemd upstream³), but appears to require more work. I 
have limited insight into how much work that would be; someone from 
Foundations or Server probably needs to weigh in on that.


Option (2) seems to be formalisation of the status-quo, so would seem 
to be less work.


Let the discussion begin!

¹: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1918141
²: 
https://github.com/ajtowns/debian-init-policy/blob/master/systemd-best-practices.pad

³: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: System setting for changing modifier keys?

[Christopher James Halse Rogers]

On Wed, Nov 26, 2014 at 5:45 AM, Barry Warsaw ba...@ubuntu.com wrote:
Are there any plans to make changing modifier keys more human 
friendly in

Vivid (unity8 perhaps)?

AFAICT, the only way to change modifier keys (e.g. swap control and 
caps lock,
remap left  right alt) is to use the tried and true xmodmap, but 
this is far

from user friendly.


What's even worse is that this isn't the best place to do this - what 
you really want to do is set


XKBOPTIONS=compose:menu,ctrl:nocaps

in /etc/default/keyboard; then this is applied everywhere, even VTs.


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

SRU team PSA - verifying your own SRU uploads

[Christopher James Halse Rogers]

Hi all!

Some time ago the SRU team announced that it's perfectly ok to verify
your own SRU uploads.

We *prefer* an unrelated verification, as it's so easy to accidentally
have some cruft hanging around accidentally fixing things.

But we prefer even more strongly to not have SRUs hanging around in
*-proposed forever, unloved, and representing work done that's not
benefiting users.

We now have a bot sweeping the SRU bugs in *-proposed commenting when a
package has been waiting to be verified for 90 days. Feel free to treat
this as a trigger to do a (real!) self-verification.

Chris Halse Rogers


signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Should gir1.2-gudev-1.0 depend on libgudev-1.0?

[Christopher James Halse Rogers]

On Tue, Mar 26, 2013 at 8:12 AM, Andreas Hasenack 
andr...@canonical.com wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Apologies if this was already discussed in this mailing list.

I got a bug filed against landscape-client today
(https://bugs.launchpad.net/landscape-client/+bug/1159997) complaining
that it wouldn't start on Raring unless libgudev-1.0-0 is installed.

I checked and it seems that on Oneiric, Precise and Quantal
gir1.2-gudev-1.0 pulls in libgudev-1.0, but not on Raring. And
landscape-client depends on gir1.2-gudev-1.0.

So, before I add an explicit dependency for libgudev-1.0 in
landscape-client in Raring, I thought I should ask if gir1.2-gudev-1.0
dropped the dependency on libgudev-1.0 by mistake or on purpose.



Yes, gir1.2-gudev-1.0 should pull in libgudev-1.0; this would be a 
packaging bug in gir1.2-gudev-1.0.



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu-x] xorg package set update for lts

[Christopher James Halse Rogers]

On Mon, 2012-11-12 at 11:50 +0100, Maarten Lankhorst wrote:
 Hey,
 
 Could the xorg package set be updated to include the following packages, for 
 the lts point release?
 
 libdrm-lts-quantal
 mesa-lts-quantal
 xorg-server-lts-quantal
 xorg-lts-quantal
 
 and a wildcard xf86-*-lts-quantal xserver-xorg-*-lts-quantal
 
 same with s/quantal/raring/ would be nice too, but probably overboard at this 
 point. :-)
 
 
 
 Lets get more into details now, since I think most technical issues have been 
 worked out now, so
 I think this can be uploaded soon after verifying it works locally.
 
 Needs to be updated in precise, for building:
  apt, for switching stacks https://launchpad.net/bugs/1062503
  x11proto-gl, from quantal for xserver
  x11proto-dri2, from quantal for xserver
  x11proto-randr, from quantal for xserver
  wayland, from quantal for mesa 9.
 
 New unrenamed packages for precise:
  llvm-3.1, from version from quantal, used by mesa 9.
 
 -
 
 All the -lts-quantal packages are autogenerated, by running the lts-stack 
 script from:
 
 https://code.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools
 
 Currently I use 'lts-stack' on quantal to download all packages, and rerun it 
 again on
 precise from same directory to generate the binaries.
 
 Special cases:
 
 libdrm - weird case to rename, really special case, see lts-libdrm-rename
  all sonames have been renamed to start with libkms_ltsq or libdrm_ltsq, for 
 example
  libdrm_ltsq_radeon.so.1 and libdrm_ltsq.so.2.
  libdrm_nouveau1a has been killed by the rename script.

Hm. I obviously wasn't clear about what I was thinking here. I was
expecting libdrm.so.2 → libdrm.so.2ltsq. That (should be) just a matter
of changing the version passed through to libtool, and shouldn't require
futzing with anything else - things linking with -ldrm will pick up the
right library.

 
 mesa - slightly easier, can no longer directly link with -ldrm* so scripts 
 are used
  to fix those makefiles up. libosmesa6 and libgl1-mesa-dri-experimental are 
 not rebuilt
  by the rename script.
 

...which might make this easier.

Since it seems you've already sorted out the libdrm_lts* problems its
probably not worth the effort to re-do this. Sorry about that!




-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Re: System compositor progress

[Christopher James Halse Rogers]

On Wed, 2012-07-11 at 18:04 +1200, Robert Ancell wrote:
 Hi,
 
 We're now at the point where the system compositor [1] is starting to
 work. Any brave souls who want to start playing with this can have a
 look at the instructions in the blueprint. Obviously THIS IS HIGHLY
 EXPERIMENTAL, so play at your own risk! In saying that, early feedback
 is most welcome and anyone who wants to hack on this contact Chris
 (RAOF) and I and we can point you at code to play with.
 

The PPA linked there will not work quite yet; it's missing a build of
mesa (and then of weston  xserver). This should be soon; just as soon
as mesa actually builds :)

I'll send a follow up mail for our intrepid system-compositites when
it's all bedded down.


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: System compositor progress

[Christopher James Halse Rogers]

On Wed, 2012-07-11 at 18:04 +1200, Robert Ancell wrote:
 Hi,
 
 We're now at the point where the system compositor [1] is starting to
 work. Any brave souls who want to start playing with this can have a
 look at the instructions in the blueprint. Obviously THIS IS HIGHLY
 EXPERIMENTAL, so play at your own risk! In saying that, early feedback
 is most welcome and anyone who wants to hack on this contact Chris
 (RAOF) and I and we can point you at code to play with.
 

This is now ready to roll, for intel, nouveau, and radeon. Intel is most
tested, and should essentially work; nouveau and radeon are less tested.

amd64 packages of weston are still publishing: you need at least
0.89.0~system-compositor4-0~raof3.

Other than that, go to town!

Chris


-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: Merging SRU and release team, leaving

[Christopher James Halse Rogers]

On Mon, 2012-05-21 at 17:08 +0100, Iain Lane wrote:
 Hey,
 
 On Mon, May 21, 2012 at 10:24:02AM +0200, Martin Pitt wrote:
  […]
  Before we flip the switch and add ~ubuntu-release to ~ubuntu-sru, I'd
  like to discuss two things for a bit:
  
   * Bug mail: u-sru gets tons of bug mail. A lot of it is irrelevant
 for the SRU team itself, but it still needs to be scanned for
 regression reports and testing feedback (when you should update the
 verification-needed tag to -done).
  
 When we merge the teams, the whole release team will get that mail,
 which is unnecessary. It would be enough if one or two people get
 it and are responsible for watching the mail traffic, it's not
 necessary for reviewing uploads or moving packages to -updates as
 long as you check the tail of the bug report before doing so.
 
 Is it necessary to read this as incoming email rather than just
 reviewing the bug activity when processing from pending-sru? I guess
 maybe then you wouldn't catch bad updates in -proposed which nobody tags
 v-failed? Does this happen a lot?
 
   * Rotation: With the entire release team now (potentially) doing
 reviews of the stable upload queues, it might be prudent to have a
 kind of roster (similar to the archive admin of the day) rather
 than hoping that someone else will do it. If there are five
 people available, we could empty the queues and do the -proposed →
 -updates promotion every day, and it should not take more than 15
 minutes every day.
 
 I wonder if pending-sru could be augmented to aid with processing a bit,
 by floating packages which are ready to be acted on to the top, like
 
   - v-done SRUs  7 days
   - v-failed SRUs
   - Uploads waiting in UNAPPROVED
 
 So that it's not such a slog to get a bit of SRU processing done and
 there's less chance of things being dropped. I don't know that every one
 of us will be able to volunteer enough time to be on regular duty.
 AFAICT the Archive Days thing has pretty much gone away now, probably
 because the team was organised well enough that it was unnecessary. I
 hope the same would happen for SRUs too.
 
 Looking at pending-updates now for the first time properly, there are a
 ton of bugs there that it seems are stalled and have been for quite some
 time. It's a bit overwhelming, but I guess that most of the entries are
 just stalled bugs. Can they be hidden by default? It doesn't seem that
 the SRU team is really going to do anything about them.

I agree with Steve; this is a failure of our process. I was talking with
Martin at UDS about this, and we thought that a script to detect such
uploads and ping the bug for testing, followed by removal from -proposed
would be a good start here.

Additionally, I said that I should be able to find the time to write
such a script at some point.

  
  Finally, with me moving into a new role from June on [2] and being in
  stable+1 team this month, I'd like to step down from both the release
  and SRU teams. I'll still be available for mentoring, questions, and
  the odd can you urgently review this actions, but not doing
  milestone releases or regular SRU work any more.

Your new gig sounds extremely interesting, congratulations again!


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

[ubuntu-x] LTS Xorg backports package set

[Christopher James Halse Rogers]

Hi all!

One of the things which still needs to be decided is the full set of
packages that we'll need to backport in order to take the 12.10 X stack
to 12.04.

Bryce has a prototype backport script in xorg-pkg-tools¹ which gets a
list of package mappings from a lookup table². I think this list is
currently a bit pessimistic, and could be trimmed, but I'd like everyone
to have a look at my reasoning.

Things which are unrelated 3rd party dependencies I think could go:

libdbus-1-dev
libgcrypt-dev
libselinux1-dev
* Stable upstream. I don't think the X stack is likely to start
depending on new features
libhal-dev
* Unmaintained upstream, in Universe.  There won't *be* new
features for the X stack to depend on.
libudev-dev
* Not as stable upstream, but I don't think the X stack is
likely to start requiring new features here. It is closely tied
to the kernel, though, so the kernel backport might require a
new udev anyway.


Protocol libraries which I don't think the xfree86 server uses, but are
used by the other weird servers - xdmx, xephyr, etc:

libdmx-dev
libxext-dev
libxfixes-dev
libxi-dev
libxinerama-dev
libxmu-dev
libxmuu-dev
libxpm-dev
libxrender-dev
libxres-dev
libxt-dev
libxtst-dev
libxv-dev
* Some of these may end up being required for xorg-gtest
integration tests; those tests are likely to be testing new
protocol, and hence require the new libs.  We can just turn
those tests off, though.

Libraries used by the main xfree86 DDX build, but without a versioned
dependency.  I think these also do not need to be backported, as long as
we can add extra packages to the backports set if they end up being
required.

libx11-dev
libxau-dev
libxaw7-dev
libxdmcp-dev
libxfont-dev
libxkbfile-dev


¹: https://code.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/
²:
http://bazaar.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/view/head:/lts-pkg-mapping.txt


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Re: [ubuntu-x] latest xinput/multitouch support?

[Christopher James Halse Rogers]

On Wed, 2012-03-14 at 15:03 +0100, Aljoša Mohorović wrote:
 i've installed 12.04 beta1 (+dist-upgrade) and i'm looking for the
 latest xinput2.2 library/api but it looks like 1.x is available.
 any way i can get the latest xinput?

libxi is what you're after.  It's (roughly) the latest version; it
supports Xi 2.2.  That is the latest API.


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Re: cpufreqd as standard install?

[Christopher James Halse Rogers]

On Sat, 2012-03-03 at 03:16 -0500, John Moser wrote:
 On 03/03/2012 12:13 AM, Phillip Susi wrote:
  On 02/29/2012 04:40 PM, John Moser wrote:
  At full load (encoding a video), it eventually reaches 80C and the
  system shuts down.
 
  It sounds like you have some broken hardware.  The stock heatsink and 
  fan are designed to keep the cpu from overheating under full load at 
  the design frequency and voltage.  You might want to verify that your 
  motherboard is driving the cpu at the correct frequency and voltage.
 
 
 Possibly.
 
 The only other use case I can think of is when ambient temperature is 
 hot.  Remember server rooms use air conditioning; I did find that for a 
 while my machine would quickly overheat if the room temperature was 
 above 79F, and so kept the room at 75F.  The heat sink was completely 
 clogged with dust at the time, though, which is why I recently cleaned 
 and inspected it and checked all the fan speed monitors and motherboard 
 settings to make sure everything was running as appropriate.
 
 In any case if the A/C goes down in a server room, it would be nice to 
 have the system CPU frequency scaling kick in and take the clock speed 
 down before the chip overheats.  Modern servers--for example, the new 
 revision of the Dell PowerEdge II and III as per 4 or 5 years ago--lean 
 on their low-power capabilities, and modern data centers use a 
 centralized DC converter and high voltage (220V) DC mains in the data 
 center to reduce power waste because of the high cost of electricity.  
 It's extremely likely that said servers would provide a low enough clock 
 speed to not overheat without air conditioning, which is an emergency 
 situation.
 
 Of course, the side benefit of not overheating desktops with inadequate 
 cooling or faulty motherboard behavior is simply a bonus.  Still, I 
 believe in fault tolerance.
 
  I currently have cpufreqd configured to clock to 1.8GHz at 73C, and move
  to the ondemand governor at 70C.
 
  This need for manual configuring is a good reason why it is not a 
  candidate for standard install.
 
 
 I've attached a configuration that generically uses sensors (i.e. if the 
 program 'sensors' gives useful output, this works).  It's just one core 
 though (a multi-core system reads the same temperature for them all, as 
 it's per-CPU); you can easily automatically generate this.
 
 Mind you on the topic of automatic generation, 80C is a hard limit.  It 
 just is.  My machine reports (through sensors) +95.0C as Critical, but 
 my BIOS shuts down the system at +80.0C immediately.  Silicon physically 
 does not tolerate temperatures above 80.0C well at all; if a chip claims 
 it can run at 95.0C it's lying.  Even SOD-CMOS doesn't tolerate those 
 temperatures.
 
 As well, again, you could write some generic profiles that detect when 
 the system is running on battery (UPS, laptop) and make appreciable 
 adjustments based on how much battery life is left.

To restrict the maximum frequency when on battery / low battery?  The
last analysis I've seen, by Matthew Garrett, was that the most
power-efficient way to run modern CPUs is to have them run as fast as
possible - in order to do the pending work in the shortest possible time
- then drop down to a low-power C-state.

Thermal management is a different matter, and one which *should* be
handled reasonably currently - either by the BIOS or by the kernel's
ACPI subsystem.  Restricting the CPU clock is not one of the things this
will currently do, though.

I recall when this has been brought up before the consensus has been
that a robust solution would need to be implemented in the kernel, as
there's no guarantee that userspace code will be run in time.  Talking
to the ARM guys at Plumbers 2011 it seems like this is something they'll
be tackling.





signature.asc
Description: This is a digitally signed message part
-- 
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: cpufreqd as standard install?

[Christopher James Halse Rogers]

On Mon, 2012-03-05 at 21:10 -0500, Phillip Susi wrote:
 On 03/05/2012 08:10 PM, Christopher James Halse Rogers wrote:
  To restrict the maximum frequency when on battery / low battery?  The
  last analysis I've seen, by Matthew Garrett, was that the most
  power-efficient way to run modern CPUs is to have them run as fast as
  possible - in order to do the pending work in the shortest possible time
  - then drop down to a low-power C-state.
 
 This is incorrect.  Lower frequency ( coupled with lower voltage )
 provides less power per instruction.  You may be confusing some of his
 writing about the p4clockmod driver, which doesn't actually lower the
 cpu voltage or frequency, but rather just forces the cpu to HLT as if
 it were idle for part of the time.  This does not give better
 efficiency, which is why he patched that driver to refuse to bind to
 the ondemand governor.
 

Less power per instruction, or less power per instruction amortized over
the run-time?  My understanding was that hitting the low C-states was
such a huge power win that the increased power per instruction was
offset by the longer C-state residency¹.

¹: http://www.codon.org.uk/~mjg59/power/good_practices.html


signature.asc
Description: This is a digitally signed message part
-- 
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: cpufreqd as standard install?

[Christopher James Halse Rogers]

On Mon, 2012-03-05 at 21:39 -0500, Phillip Susi wrote:
 On 03/05/2012 09:19 PM, Christopher James Halse Rogers wrote:
  Less power per instruction, or less power per instruction amortized over
  the run-time?  My understanding was that hitting the low C-states was
  such a huge power win that the increased power per instruction was
  offset by the longer C-state residency¹.
  
  ¹: http://www.codon.org.uk/~mjg59/power/good_practices.html
 
 That's the article that I was thinking of that is mostly about the
 p4clockmod driver.  Using it means you have the same power per
 instruction, but also are spending less time in the deeper C states,
 and so is bad.  With correct frequency management, the lower power per
 instruction of the lower frequencies outweighs the reduced time in the
 lower C states.  There probably still is an optimal point somewhere
 between the min and max frequency where you get the benefit of both
 lower power per instruction when executing instructions, without
 giving up too much time in the lower C states, but finding that
 balance is tricky and highly hardware and load specific.  My current
 CPU operates from 1600 to 3301 MHz ( where the last 1 MHz just enables
 turbo boost ).  Disabling that turbo boost state would probably
 provide the most savings in power power per instruction with minimal
 loss of deep C6 time.  At 1600 MHz with a load that keeps that
 frequency mostly busy very well may be more effi
  cient at 
 one of the intermediate frequencies, but figuring out which is tricky.
 One thing is almost certain: it isn't 3301 MHz.  Of course, a load
 that keeps 1600 MHz rather busy would trigger the ondemand governor to
 shift to one of the intermediate frequencies anyway, so the default
 situation is probably quite near optimal.  Load spikes that would
 cause the ondemand governor to shift to 3301 ( turbo boost ) would be
 best disabled when on battery power, but I believe that many laptops
 have proper ACPI bios that does disable turbo boost when on battery
 power, so we're good there too.
 

I think we might have wildly different interpretations of that article.
The third paragraph is:

“C states offer significant power savings, but cannot be entered when
the CPU is executing instructions. The best power savings can be
obtained by running the CPU as fast as possible until any outstanding
work is completed and then allowing the CPU to go completely idle. The
powersave governor will extend the time taken to complete the work and
reduce the amount of time spent idle. 

On any modern CPU the benefit of carrying out the work at a lower clock
and voltage will be outweighed by the loss of the idle time.

In almost any workload, powersave will consume more energy than any
other option.”

And has:

“Summary: Use ondemand. Conservative is a valid option for processors
that take a sufficiently long time to switch performance states that
ondemand will not work.”

There's a *separate* dot-point about not using p4clockmod, but I read
that as entirely separate.

Of course, that was written in 2008; IIRC this is before the age of
turbo mode, so that might change the conclusions.



signature.asc
Description: This is a digitally signed message part
-- 
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] gallium version of i915_dri.so

[Christopher James Halse Rogers]

On Fri, 2012-02-10 at 09:11 -0800, Bryce Harrington wrote:
 On Fri, Feb 10, 2012 at 04:13:50PM +0100, erwin wrote:
  
  On Fri, 10 Feb 2012 16:31:57 +0200, Timo Aaltonen tjaal...@ubuntu.com
  wrote:
   (please use the mailing list mentioned on the maintainer field of the
   package)
   
   On 10.02.2012 15:51, erwin wrote:
   
   Hi Timo,
   
   I noticed the following line in the changelog for
   libgl1-mesa-dri-experimental in the xorg edgers ppa:
   
   Drop the dri-alternates driver search path, and don't ship
   gallium version of i915_dri.so for now
   
   Could you tell me why you stopped shipping the gallium version of
   i915_dri.so? I used this to get OpenGL2 support on my netbook (some
  games
   require it). Is there anything I can do to get it back in?
   
   Nope, don't remember why I dropped it. Maybe just that the package had
   enough issues to get it built, and it was getting on the way.
  
  Any chance of getting it back in? I'd be happy to help with any issues,
  could you point me in the right direction?
 
 I understood that this was no longer being maintained upstream, thus the
 frequent build issues.

I'm pretty sure i915g is being actively maintained and developed; IIRC
the ChromeBooks use i915g.  It is, as Erwin says, more featureful than
i915.

i965g is indeed unmaintained and (as far as I'm aware) never did
anything much more than lock up the GPU.

Chris


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

X transition time!

[Christopher James Halse Rogers]

Hey all!

It's that time of the cycle again - the time to switch to a new X
server, when the Ubuntu-X team conspires to break everyone's system for
a day or so while the archive settles back into consistent state.

But wait!  This time we're trying out a new method for X transitions
that should entirely remove the breakage. The full X stack has been
staged in a PPA, everything is built against it, and we're preparing to
copy that wholesale to the archive.

There should not be any time when the archive is in an inconsistent
state.  In fact, you shouldn't notice anything much, apart from a large
number of upgrades. This includes users of the proprietary nvidia and
fglrx drivers, with the exception of users of nvidia-96 (for extremely
old cards).

While the Ubuntu-X team has tested the packages and upgrades to the
packages, we obviously can't cover everything.  Please be on the lookout
for X problems in the next couple of days.

Thanks!
Chris


signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu-x] Smoke testing of Precise X server bits

[Christopher James Halse Rogers]

On Fri, 2012-01-20 at 03:01 +0100, Chase Douglas wrote:
 Hi all,
 
 We have everything ready (almost) for the upload of the X server into
 Precise. It includes X server 1.11 plus the input stack from 1.12. It
 also includes a bunch of interdependent packages that would break if you
 were only to update your X server. Here's the known issues with the PPA:
 
 * No utouch-geis support, which means most of your gestures won't work
   - Will be fixed by feature freeze
 * Multitouch in Qt from indirect devices (e.g. trackpads) is broken
   - Will be fixed in next Qt upload *after* we push these packages
 * Qt is still building for armel, so don't test this on armel yet
 * A security hole will kill your screen saver if you type
   Ctrl+Alt+KP_Multiply
   - Will be fixed in xkeyboard-config upload in the next couple hours

This is now fixed.


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Re: [ubuntu-x] Smoke testing of Precise X server bits

[Christopher James Halse Rogers]

On Fri, 2012-01-20 at 03:01 +0100, Chase Douglas wrote:
 Hi all,
 
 We have everything ready (almost) for the upload of the X server into
 Precise. It includes X server 1.11 plus the input stack from 1.12. It
 also includes a bunch of interdependent packages that would break if you
 were only to update your X server. Here's the known issues with the PPA:
 
 * No utouch-geis support, which means most of your gestures won't work
   - Will be fixed by feature freeze
 * Multitouch in Qt from indirect devices (e.g. trackpads) is broken
   - Will be fixed in next Qt upload *after* we push these packages
 * Qt is still building for armel, so don't test this on armel yet
 * A security hole will kill your screen saver if you type
   Ctrl+Alt+KP_Multiply
   - Will be fixed in xkeyboard-config upload in the next couple hours

This is now fixed.


signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [Desktop12.04-Topic] Handling Failure Gracefully

[Christopher James Halse Rogers]

On Tue, 2011-10-25 at 09:56 -0400, Robert Ancell wrote:
 Late topic...
 
 In the real world there are always going to be failures, triggered by
 things like software bugs, hardware failures and misconfiguration. 
 Ubuntu should where possible handle common failures and provide
 predictable feedback to the user that the system is broken.
 
 I think we have the intention that most of this should work already, but
 it would be good to check we've worked out the right failures to handle
 and to methodically test they all work in 12.10.
 
 Some common failure cases and what should happen:
 - Failure to start X server - Run failsafe X server
 - Failure to start any X server - Show error on text console
 - Failure to start greeter - Run X server with error message
 - Failure to start session - Return to greeter with error message
 - Failure of compiz/unity during session - restart compiz/unity
 - Failure to start application - show error message
 - ...

Yes.  This is an important aspect of system robustness that I don't
think we've generally paid a lot of attention to.

At the last UDS(?) Bryce and I got together with Colin Watson and
discussed a subset of this problem - around what kernel options the GRUB
recovery mode should set, and when recordfail (to automatically show the
GRUB menu next boot) should be cleared.

I'd be very interested in having a broader discussion about this.


signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Korean users: request for comments on switch to ttf-nanum fonts

[Christopher James Halse Rogers]

Hi all!

In bug #836430¹ (and associated merge proposals) we have a request to
switch the default fonts for Korean locales from ttf-unfonts-core to
ttf-nanum.  It seems that ChromeOS and OS X are both using these fonts.

All the pieces are ready to make this change, but I'm not a native
Korean speaker and so I'd like to ensure that this change has broad
support before it's made.

If no-one has any objections to this change I propose that it be made in
2 weeks, after everyone's back from UDS.  That should give interested
parties long enough to raise any problems.  If people do have objections
to the change then they should be resolved first, obviously.

¹: https://bugs.launchpad.net/bugs/836430


signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Korean users: request for comments on switch to ttf-nanum fonts

[Christopher James Halse Rogers]

Hi all!

In bug #836430¹ (and associated merge proposals) we have a request to
switch the default fonts for Korean locales from ttf-unfonts-core to
ttf-nanum.  It seems that ChromeOS and OS X are both using these fonts.

All the pieces are ready to make this change, but I'm not a native
Korean speaker and so I'd like to ensure that this change has broad
support before it's made.

If no-one has any objections to this change I propose that it be made in
2 weeks, after everyone's back from UDS.  That should give interested
parties long enough to raise any problems.  If people do have objections
to the change then they should be resolved first, obviously.

¹: https://bugs.launchpad.net/bugs/836430


signature.asc
Description: This is a digitally signed message part
-- 
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: Python startup time (was: Brainstorming for UDS-P)

[Christopher James Halse Rogers]

On Tue, 2011-09-27 at 01:08 +0200, Benjamin Drung wrote:
 Am Montag, den 26.09.2011, 13:48 +0200 schrieb Sebastien Bacher:
  Le vendredi 23 septembre 2011 à 21:56 +0100, Allison Randal a écrit :
   Hi all,
   
   While we're all in the final preparations for Oneiric, it's round about
   that time in the cycle to start thinking about plans for the next cycle.
   What's on your mind?
  
  Some desktopish suggestions:
  
  - Boot and desktop performances (boot time, memory usage, power
  consumption)
 
 Moving applications from Python 2 to Python 3 will increase the startup
 time. I wrote a little script that runs n times hello world programs and
 takes the time. That reveals a startup time increase of factor two
 between Python 2 and 3. Running the hello world programs 100 times on my
 system with an Core i5 takes following time (in seconds):
 
 C:   0.04
 D:   0.14
 Haskell: 0.22
 Bash:0.23
 CShell:  0.25
 Perl:0.27
 PHP: 0.81
 Python:  1.54
 Python3: 3.22
 Ruby:0.28
 Shell:   0.10
 ZShell:  0.22
 C#:  2.55

If we cared sufficiently about C# startup time, I suspect we could cut
this significantly by doing AOT compilation on install, same as we
byte-compile python.

Perhaps I should try some benchmarking…


signature.asc
Description: This is a digitally signed message part
-- 
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

gnome-desktop3 string freeze exception request

[Christopher James Halse Rogers]

Bug https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/824099
requests a string freeze exception request for gnome-desktop3's XRandR
support.  The workaround for this bug requires that gnome-desktop
refuses to configure a multi-head display with a size exceeding
GL_MAX_TEXTURE_SIZE when Unity is running.  This requires a new error
message in gnome-rr-config.c, which will be shown to the user,
explaining why their configuration request has been rejected and what
they can do about it.

Thanks,
Chris Halse Rogers.

-- 
ubuntu-translators mailing list
ubuntu-translators@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators

Language Chooser at Login 3: The Choosening (or: Keyboard Selector)

[Christopher James Halse Rogers]

Rovanion in #ubuntu-devel brought to me a problem that's related to the
lack of language selector - we also don't have a keyboard selector.  I
don't think I've seen this discussed before, and I think it should be
addressed.

The problem description here is:
You have a multi-user system with multiple keymaps.  This could be
dvorak/qwerty, or latin/cyrillic is apparently common.  Different users
can then have passwords using different keymaps, which means that
unity-greeter needs to be able to understand this.

Either unity-greeter would need to cache each user's keymap and
automatically switch keymap for the password field, or use something
like the keyboard indicator in the greeter.


signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Patch pilot report: 2011/08/02

[Christopher James Halse Rogers]

Today's patch piloting involved lots of poking other people but I feel
was nonetheless productive:

https://bugs.launchpad.net/ubuntu/+source/apt-offline/+bug/819514
 • ACK'd sync, subscribed archive.  Contributor transitioned package to
dh_python2 in Debian, this is sync back to Ubuntu.
https://bugs.launchpad.net/ubuntu/+source/gnote/+bug/819532
 • ACK'd new-upstream-version sync.

https://code.launchpad.net/~hypodermia/ubuntu/oneiric/compiz/fix-for-bug-301174/+merge/64632
 • Bell sound should follow XDG sound theme
 • Discussed with Sam Spillsbury in #ayatana; it'll either get merged
then fixed or fixed then merged.

https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/388904
 • UI Disagreement with upstream
 • Specific patch seems to have problems; 
 • Sent email to desktop list to begin discussion on whether we want to
carry this as a distro-patch.




signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Patch Pilot report, 2011/07/26

[Christopher James Halse Rogers]

I tried to do a sweep of the “Needs Fixing” branches in the hope of
quickly knocking out some of the noise.  Of course, it always takes
longer than you think…

https://code.launchpad.net/~pro-mathesh812004/ubuntu/oneiric/scim-tables/oneiric/+merge/64119
• Set status to In Progress, noted what the submitter needed to do to
get the merge back on the queue.
• Asked about the “All rights reserved” copyright statement on the
submitted tables.

https://code.launchpad.net/~fougner/ubuntu/oneiric/kdepim/fix-for-791635/+merge/65073
• Checked out the upstream status; there's some ongoing discussion.
• Set to In Progress

https://code.launchpad.net/~dpolehn-gmail/ubuntu/oneiric/pxlib/fix-755924-use-pkg-config/+merge/65151
• Last Needs Fixing review has not been responded to.
• Set to In Progress

https://code.launchpad.net/~neonofneophyte/ubuntu/oneiric/notification-daemon/fix-for-557887/+merge/65720
• Cosmetic issue in the description of notification-daemon.
• Patch was sent upstream to Debian a month ago, still sitting in the
BTS.  Made minor fixes to the packaging, and uploaded.

https://code.launchpad.net/~elmo/ubuntu/oneiric/libstomp-ruby/bug-707317/+merge/67463
• Marked as In Progress - this looks like it'll be uploaded to Debian
and then synced back, so doesn't need to be on the queue.

https://code.launchpad.net/~pali/ubuntu/oneiric/pulseaudio/pulseaudio/+merge/67286
• Marked as In Progress - previous Needs Fixing review comments correct
and not yet addressed

https://code.launchpad.net/~vanvugt/ubuntu/lucid/nvidia-graphics-drivers/fix-627022/+merge/66255
• Upload looks good, pinged Alberto for an ACK as he manages the
restricted drivers




signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Very odd issue, dead spots on screen

[Christopher James Halse Rogers]

On Sun, 2011-07-10 at 22:04 -0400, John Moser wrote:
 I can't click links or pictures or highlight text...
 
 so I unmaximize Chrome, move it, and then click it.
 
 Can't highlight in any other app either ... it's that rectangle of the
 screen, it's like there's an invisible window overlayed and I can't
 click or right click through it.
 
 I don't know how to diagnose this.
 

If you run “xwinprop -all” from a terminal and click on the dead area of
the screen you'll probably find there's an InputOnly window, probably
also with the OverrideRedirect flag set.  If you're lucky it will have
set _NET_WM_PID so you'll be able to work out the pid, and hence
program, which owns it.

This can sometimes be caused by compiz stacking bugs.  It's generally
not an X issue; the server is just doing what's been asked of it.

Chris


signature.asc
Description: This is a digitally signed message part
-- 
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: Call for testing: LightDM

[Christopher James Halse Rogers]

On Wed, 2011-06-08 at 11:01 +0200, Milan Bouchet-Valat wrote:
 Le mercredi 08 juin 2011 à 01:09 -0700, Bryce Harrington a écrit :
  Boiling Matt's post down this is what I'm reading:
  
1. NIH
2. It doesn't start a GNOME session
3. Doesn't have arbitrary shiny stuff like slidy effects
4. Auto-update when users are created or deleted
5. Accessibility functionality UI
6. Gratuitously drawing a clock
7. Handle power policy via gnome-power-manager rather than via upower
  
  #1 yeah but whatever.  #2 seems like a feature unless proven otherwise.
  #3 who cares.  #4 ok, fair point, seems minor though.  #5 important, but
  I think already under development.  #6 yeah right.  #7 huh?
 As I see it, the problem is that when you'll have brought back
 accessibility, power and sound management, you'll essentially have
 started a GNOME session or an equivalent, losing a good part of the
 lightweight. Maybe I'm wrong, though - history will surely tell.
 
I think there's a fundamental difference between “start a full GNOME
session and blacklist stuff that in inappropriate for a login screen”
and “start the bits of a full GNOME session that a login screen needs”.

GDM apparently chooses the first route, which is why the recent security
advisory where you could start a web-browser from the GDM screen with
GDM's credentials can occur :).




signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: gnome-panel as a fallback

[Christopher James Halse Rogers]

On Mon, 2011-06-06 at 09:46 +0200, Didier Roche wrote:
 On lun., 2011-06-06 at 02:18 -0400, Eric Appleman wrote:
  Hi, I was wondering under which circumstances the GTK3 gnome-panel can 
  be used as a fallback for Unity or GNOME-Shell.
 
 Hi Eric,
 
 We are trying to build a coherent environment for ubuntu and GNOME
 upstream experience.
 
 Consequently, the plan (and what's already in oneiric) is:
 * Unity and Unity-2d are installed on the CD, Unity-2d being the
 fallback of Unity. In addition, each one have a separate session in gdm
 (and probably will have in lightdm as well) to start them directly.
 
 Note that this will be the case for finale only if we can have the full
 unity-2d accessibility stack working in time.
 
 * gnome-shell and gnome-panel are available in the repository.
 gnome-panel can be installed separately from gnome-shell and each one
 have as well a separate session in gdm/ligthdm to start them directly.
 gnome-panel is the fallback of gnome-shell. (gnome-shell pulls
 gnome-panel).
 
 
  
  I'd like to know if Unity 2D will also be used for for FailsafeX sessions.
 
 Not sure about that one as different people means different things about
 FailsafeX sessions. if it's session without 3D acceleration, right,
 that's what is already the case in oneiric. FailsafeX as no driver has
 been able to be loaded/X can't start (bulletproof X), that's more a
 question for the Xorg guys :)
 

My initial thought would be that FailsafeX should use whatever fallback
would be otherwise used; Unity2D if Unity is the user's default, GNOME
classic if Shell is the user's default.

If Unity2D is unacceptably slow or likely to be broken with VESA then
that should be revisited.  IMO FailsafeX should give the user as
comfortable experience as possible for them to try to work out what went
wrong and fix it.  That's likely to be the default fallback session.



signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: [Oneiric-Topic] GTK3/GNOME3

[Christopher James Halse Rogers]

On Fri, 2011-04-08 at 09:12 +1000, Robert Ancell wrote:
 On 04/07/2011 05:59 PM, Martin Pitt wrote:
  Hello all,
 
  kind of obvious topic, but next cycle we'll need to move to GTK3 and
  GNOME3. Aside from the obvious update the package versions, I see
  the following particular challenges:
 
   * Review our patches, and be rather aggressive about removing those
 which are intrusive and which we have carried for ages without
 upstream acceptance. Of course there are also still patches which
 we haven't even proposed upstream, these should be discussed in
 bugzilla.gnome.org.
 
   * Port pygtk2 apps to PyGI with GTK3. The biggest ones are
 ubiquity and software-center, but there is also quite a long tail
 of smaller upstream software.
 
   * Discuss GTK3 theming with UX/design. Our current murrine based
 Humanity theme doesn't work with GTK3.
 
  I expect that this will bind a lot of developer capacity next cycle,
  but at the same time it's very important that we do this to not lose
  track with GNOME.
 
  Martin
 One issue we need to tackle is the use of clutter.  Applications are
 moving towards using clutter (e.g. cheese) and my experience with
 clutter has been:
 - Requires good 3D support
 - Has never seemed to work well for me...
 
 We need to work out early if we can have a hard dependency on clutter or
 not, and what happens if you can't run clutter applications.
 

As discovered with enabling cairo's GL backend in bug #725434¹, if a lot
of apps pick up dependencies on clutter it will have a non-trivial
impact on memory usage on the nvidia binary drivers.

Not much that we can do about it, but it's another thing to consider.

[1]:
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/725434


signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: IronPython and Mono are very old. How can we get an update?

[Christopher James Halse Rogers]

On Fri, Apr 8, 2011 at 2:31 AM, Vernon Cole vernondc...@gmail.com wrote:
 On Thu, Apr 7, 2011 at 6:26 AM, chalserog...@gmail.com
 chalserog...@gmail.com wrote:
 [...]
 Mono's upstream 2.10 release page suggests that they're shipping both
 IronPython and IronRuby in the main mono distribution, but looking at
 the source I can't find it, so I'm not sure what's happening there.

 IronPython and IronRuby are now building from the same source.
  https://github.com/IronLanguages/main

 Regardless, Mono 2.10.1 is now available in Debian experimental, and
 so will be available early on in the Oneiric (what will become Ubuntu
 11.10) development cycle.  Since we're very close to the end of the
 Natty cycle upgrading to 2.10.1 presents too big a regression risk to
 pull it in this time.

 What needs to be done is to update the dlr-languages² source package.
 This is maintained by the pkg-cli-libs team in Debian, and we sync it
 across from there.  As we're well after Natty feature freeze, updating
 in Natty would require a Feature Freeze exception¹.  As there seems to
 be only one package with a(n optional) dependency on IronPython in the
 archive it *might* be possible to get an FFe and have the new package
 in the Natty release, it would be more reasonable to aim for Oneiric.

 One can RUN IronPython 2.7 on Mono 2.6.7, but not BUILD it,
 http://ironpython.codeplex.com/wikipage?title=IronPython%20on%20Mono
 So I'm not sure how well an FFe would work.

Oh.  Yeah, that's not going to work then!

 I'm assuming that the
 build engine runs on the same Mono version as the release?

Yes.  The policy is that everything in the archive has to be built by
tools in the archive.


  Perhaps we will need to maintain a .NET 2.0 compatible binary of IPy
 on the IronPython site until well after Debian releases with Mono 2.10
 under the hood.


Debian stable is going to have Mono 2.6.7 until the next release,
which is likely to be about 2 years away.  There's likely to be a
backport done, though, so it should (eventually) be reasonably easy
for Debian users to have Mono 2.10.  Ubuntu 11.10 will have Mono 2.10,
Ubuntu 11.04 won't - but, again, is likely to get *some* sort of
backport, even through a PPA.  Whether that makes it worth maintaining
a 2.0-compatible IPy is up to you :).

 If you'd like help in the mechanical process of updating the package,
 the Ubuntu packaging guide³ has a good rundown, or feel free to ask -
 IRC #debian-cli on oftc.net is friendly and generally active.  Since
 it looks like dlr-languages is one of the more complex things to
 package, I could probably find the time to update it in the next month
 or so if you're not comfortable with the process.

 ¹: https://wiki.ubuntu.com/FreezeExceptionProcess
 ²: http://git.debian.org/?p=pkg-cli-libs/packages/dlr-languages.git;a=summary
 ³: https://wiki.ubuntu.com/PackagingGuide

 Okay, I just looked at the link, and would require a month or so for
 me to figure out how to do it. I have been a bit hesitant about
 changing things I don't understand, ever since I crashed the Internet
 in several neighboring states by incorrectly updating a gateway
 router. (Long story, and the Internet was much smaller then.) So, yes,
 please make those changes when you can.  :-)

Well, we'd be reviewing and sponsoring your changes, so if you *did*
break the Internet again it'd be our fault :).


 Make sure that the source is coming from github, not codeplex.
 I'll see that the build patches get into a new tarball, They are now
 in the git trunk but not backported to the 2.7 maintenance branch yet.
 How often do you fetch a new tarball?

As often as the maintainer feels like it.  For well maintained
packages (here's where you can come in ☺) that's generally once per
upstream release, unless there's some problem - like it not being
buildable against Mono 2.6.7 :).

There's a certain amount of impedance mismatch between Debian and
predominantly-Windows upstreams like Iron*, but that's something that
can largely be worked around.  The biggest problem is probably the
different IronPython/IronRuby release schedules which mean we can't
have IronPython 2.7 and IronRuby 1.0 unless we have two different
source packages, and even then there's the problem of the shared DLR
component.

-- 
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: IronPython and Mono are very old. How can we get an update?

[Christopher James Halse Rogers]

On Sun, 2011-03-20 at 18:28 -0600, Vernon Cole wrote:
 Chris:
 Thanks for the detailed information. That was pretty much what I was
 looking for. It makes everything make sense.
 
 I had tried downloading the mono source and rebuilding -- what an
 error!  I've spent most of my morning removing the new, broken mono
 and replacing the stock version. Ugh!

Hm.  I should have linked http://apebox.org/wordpress/linux/370/ which
is a description of how to do a parallel mono install in a way that
works with the Debian CLI policy and tools.


signature.asc
Description: This is a digitally signed message part
-- 
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: Call for Natty Feedback!

[Christopher James Halse Rogers]

On Tue, 2011-03-01 at 13:51 -0800, Bryce Harrington wrote:
 On Tue, Mar 01, 2011 at 04:18:22PM -0500, Sean McNamara wrote:
  5. Stability has been poor in my experience; I run into X crashes from
  time to time doing fairly mundane stuff that doesn't trigger a crash
  with Gnome2.
 
 Can you provide a bug # (with a full backtrace if possible)?  I'm
 putting a priority on following up on xserver segfaults.
 
 (Actually there are no public X crash bugs open against natty at the
 moment, so I wonder that what you're seeing is not actually an xserver
 segfault.  Regardless, it should be investigated.)
 
  6. Multi-monitor seems totally broken somehow... on a 1024x768 laptop
  with a 1680x1050 VGA LCD attached, I get no menus and no indication
  that Unity is aware of windows on the large external LCD. And the
  left-side menu doesn't come up at all anymore. It seems like there is
  an empty space above the top of my laptop's screen where my mouse can
  go, but there is nothing up there -- I configured (using the
  xrandr-based Monitors applet) the big monitor to be to the right of
  the laptop LCD.
 
 The first half of that could be unity's handling of multi-head, which I
 agree seems like it needs more QA.
 
 The second half, regarding blank spaces where the mouse gets lost, is a
 long standing known X.org issue (bug #389519).  (There's been a patch
 proposed but it's not upstream yet.)

There's a patch series for this and pointer barriers (which Unity might
want to use, too, for the BDB + multihead) on the xorg-devel mailing
list.  The crtc-clamping works and if we really wanted it the patch is
relatively safe and could be FFe'd.  The pointer-barriers need protocol
changes, and I'd be hesitant to include them before the protocol has
been finalised.


signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: build-from-branch into the primary archive

[Christopher James Halse Rogers]

On Thu, 2011-02-24 at 09:20 +0100, Martin Pitt wrote:
 Steve Langasek [2011-02-19 11:48 -0800]:
  That sounds reasonable to me.  How do you gpg sign a tag in bzr?  I've never
  seen any information about this in the UDD documentation.
 
 Neither have I, I'm eager to learn whether and how that works as well.
 But I think it's a prerequisite to maintain the current GPG strength
 security.

bzr sign-my-commits (unsurprisingly!) adds a GPG signature to all the
commits you've made in the branch, and there's an option exposed in the
bzr configuration capplet in bzr-gtk to always sign your commits.

I'm not aware of any way of signing a tag, although simply requiring all
top-level commits to the Ubuntu branch be GPG-signed would probably be
sufficient.

Chris



signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: HDMI and automatically hardware recognition

[Christopher James Halse Rogers]

I see Luke has taken the audio half of this, as for the video part…

On Tue, 2011-02-08 at 13:36 +0100, Yann Santschi wrote:
 Hi everybody ! I just found one point that can really be improved in
 future releases of Ubuntu. In a first time I will explain how I found
 it, in a second time what I think about and the third point (the most
 important), a proposition to get rid of this lack...
 
 I got Ubuntu because I was worried about Windows (it's slow, it has a
 lot of glitches,...). With Ubuntu I can work without complications,
 until today... I bought a TV and wanted to connect it through HDMI
 cable. I configured my nvidia-settings and chose digital audio ouptut.
 It works fine, but...
 Every time I reconnect my TV, I must :
 - Manually detect connected screens
 - Set the correct screen settings
 - Change audio output to digital
 Every time I disconnect my TV, I must :
 - Set the correct screen settings (before disconnecting)
 - Change audio output to analog (otherwise laptop speakers don't work).
 In Windows, it works automatically in the most cases (sometimes not,
 it's just another Windows glitch...).
 

This is a combination of the nvidia-settings tool not being integrated
into GNOME, the binary nvidia drivers not supporting the standard XRandR
interface for monitor configuration, and no-one investing the time to
make the standard GNOME display tools talk the proprietary NV-CONTROL
protocol.

If we had the code, we could fix the nvidia drivers - indeed, this
*should* Just Work™ with the open-source nouveau drivers, and does for
me.  If convenience is more important than raw 3D performance you may
find the nouveau drivers to be better for you.

Of course, there's also the chance that hotplug detection won't work for
your system with the nouveau drivers, but at least in that case we've
got a chance of fixing it.

 I think that it's a pain for end-users (in this case I am) to have to
 always (re)set these damn settings to watch a movie, to connect a
 projector, to connect the external display. I know that's possible to
 script that, but as an end-user, I just don't want to : I want to use
 my computer and not to configure it all the time. When I connect my
 usb flash drive, it's automatically mounted and ready-to-use. Why it
 isn't the same with external displays ?
 
 A way to fix this problem, is to create something such as an hardware
 profile that contains settings and when a new display and/or audio
 output are detected (I think it's possible to detect a hardware
 change), a window / widget asks the user if he want's to apply saved
 settings or if he want's to set new settings.
 
 What do you think about that ?

I think that what you actually want is for things to work automatically,
like with USB, rather than have a pop up window.  :)

This is how it works for drivers which support XRandR and generate
hotplug events right now - if you plug in a monitor, it will be set up
the same way as it was last time, or if it hasn't been plugged in before
it will have a sensible default set up.  The big 3 - ati, intel, nouveau
- all have the capabilities to do this.

Similarly for audio (although I'm less familiar with the hardware
capabilities here) - if we see an HDMI audio device is connected, and
totem starts playing a movie, sending that stream over the HDMI
connection is a good default.


signature.asc
Description: This is a digitally signed message part
-- 
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-x] [Fwd: Handling server / drivers dependencies]

[Christopher James Halse Rogers]

Hey, all!

For those of you not subscribed to the Debian X list, Cyril Brulebois
has just written a little documentation about where the Debian
dependency information between the Xserver and driver packages is going.

Forwarding the initial mail, containing a link to the alioth
documentation.
---BeginMessage---
Cyril Brulebois k...@alioth.debian.org (01/02/2011):
  index.mdwn  |4 +
  reference/dependencies.mdwn |  131 
 
  xsf.css |5 +
  3 files changed, 140 insertions(+)
 
 New commits:
 commit dfb93d750512f99ecbbe8e7d97db97acb6641505
 Author: Cyril Brulebois k...@debian.org
 Date:   Tue Feb 1 13:34:52 2011 +0100
 
 dependencies: New reference document.

I tried to summarize both upstream and debian aspects of server /
drivers dependencies. It's currently just a draft which aims at
summarizing where we want to go (rather than where we came from) and
how to do so; also the current state should be pretty obvious to
anyone having an apt cache handy, so I skipped talking about that. :)

Tweaks to xorg-server + sample driver updates will be pushed to
repositories under users/kibi/pkg-xorg probably, for discussion /
review before pushing to the main repositories.

The draft document is available online:
  http://pkg-xorg.alioth.debian.org/reference/dependencies.html

KiBi.


signature.asc
Description: Digital signature
---End Message---


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Re: GNOME session saving dropped in natty

[Christopher James Halse Rogers]

On Sat, 2011-01-22 at 03:09 -0500, Jacky Alcine wrote:
 On 01/21/2011 01:14 PM, Bryce Harrington wrote:
  On Fri, Jan 21, 2011 at 07:36:55AM -0800, Rick Spencer wrote:
  On Fri, 2011-01-21 at 16:16 +0100, Martin Pitt wrote:
  Vishnoo [2011-01-21 20:41 +0530]:
  Is there a bug filed for this, which we could follow?
  I don't think we should bother. Session saving can't ever be perfect.
  You won't ever get back things like your unsaved current documents,
  undo buffers, network connections (chat), etc, and those are much more
  interesting than the position of your windows (not that GNOME would or
  could ever get that right even). I think this has always been a
  half-baked misfeature.
 
  For proper session saving/restoring there is suspend and hibernate.
  Well, there is suspend. Hibernate does not exactly work perfectly for
  many peole.
  Nor does suspend...  ;-)
 
 Is there a way of flashing the loaded applications in memory and all of
 those handles to disk and just loading it back?
 

You've pretty much just described “hibernate”.  When it works, that is
☺.


signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: [ubuntu-x] New X stack in xorg-edgers

[Christopher James Halse Rogers]

On Fri, 2011-01-14 at 14:02 -0800, Bryce Harrington wrote:
 Thanks Felix.  Weird we didn't bang into that problem on our machines,
 but Chris is uploading rebuilds for these drivers presently.
 
 We'll send a notice once these are corrected.
 

Corrected, via a combination of rebuilds, a new wacom upstream version,
and (temporarily) dropping -siliconmotion and -openchrome from
xserver-xorg-video-all.

The proprietary fglrx and nvidia drivers obviously don't work against
this new Xserver.  Due to packaging bugs, they *also* won't prevent the
upgrade going through, leaving a non-functioning X until they are
removed.

Please remove the fglrx or nvidia drivers before testing.

If you're not using a proprietary driver, -siliconmotion, or
-openchrome, xorg-edgers is good to go.


 Bryce
 
 On Fri, Jan 14, 2011 at 04:13:48PM -0500, Felix Kuehling wrote:
  Hi Bryce,
  
  The PPA is still not usable:
  
  xserver-xorg-video-siliconmotion, openchrome and vmware are broken
  (still depend on the old xorg-video-abi-8.0).
  
  If I try to remove them, other packages break due to unresolved
  dependencies:
  
* xserver-xorg-video-all depends on xserver-xorg-video-*
* xserver-xorg depends on xserver-xorg-video-all
* xserver-xorg-core depends on xserver-xorg-video-all
  
  In the end the only way to resolve the broken dependencies is to not
  update at all or completely uninstall Xorg.
  
  Similar story on the input side with xserver-xorg depending on
  xserver-xorg-input-all depending on xserver-xorg-input-wacom, which is
  broken due to a dependency on an old xorg-input-abi-11.0.
  
  Regards,
Felix
  
  On Fri, 2011-01-14 at 15:54 -0500, Bryce Harrington wrote:
   We're going to be moving natty to its new X stack within the next week
   or two.  This includes snapshots for the upcoming xserver 1.10 and mesa
   7.10, along with some new driver bits.  Currently this stack is
   available in xorg-edgers, and maps well to what we'll be uploading
   shortly.
   
   You can help us pre-test these bits by installing xorg-edgers on your
   systems at this time.  Our testing has shown it to be quite stable, but
   the devil's in the corner cases when it comes to X, so your testing will
   help us get a head's start on making it work better for your HW.
   
   1.  The PPA is available at:
   
   https://launchpad.net/~xorg-edgers/+archive/ppa
   
   2.  Here's a simple way to install:
   
   sudo add-apt-repository ppa:xorg-edgers/ppa
   sudo apt-get update
   sudo apt-get upgrade
   
   Then reboot your system to get to the new bits.
   
   3.  If you want to go back to stock Ubuntu, there is a corresponding
   ppa-purge tool:
   
   sudo ppa-purge xorg-edgers
   sudo apt-get update
   sudo apt-get upgrade
   
   4.  If you happen to find bugs, you can report them the usual way:
   
 ubuntu-bug xorg
   
   Include a photo of the screen if appropriate (e.g. screen corruption).
   
   Thanks,
   Ubuntu X Team
   
   
  
  -- 
   _Felix Kuehling
   \ _  |   MTS Software Development Eng.
   /|_| |   SW-Linux Base Gfx
  |__/ \|   T 905.882.2600 x8928
  
  
  
  -- 
  Ubuntu-x mailing list
  ubunt...@lists.ubuntu.com
  Modify settings or unsubscribe at: 
  https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
 




signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Maverick - Natty upgrade, unity, gnome-panel and windowmanager's party…

[Christopher James Halse Rogers]

On Fri, 2010-11-26 at 11:22 +0100, Didier Roche wrote:
 On ven., 2010-11-26 at 10:10 +1100, Christopher James Halse Rogers
 wrote:
  On Tue, 2010-11-23 at 12:52 +0100, Didier Roche wrote:
   Hey fellow desktopers,
   
  [snip]
   2.2.2 So, we can think the other way around: only run gnome-panel when
   needed and not setting it as a required_components by default in the
   default sessions but still on the gnome classic session (this can be
   done as well as sessions adds some additional gconf paths).
   - 2.2.2.1 if unity runs, nothing to do, no flipping
   - 2.2.2.2 if unity can't run, we need to launch gnome-panel. That's
   currently done as a compiz plugin (and the code is executed even if
   opengl compiz can't be run on that hardware). So, we can launch
   gnome-panel, BUT there is no way to set it dynamically as a required
   component without making heavy changes to gnome-session: basically, what
   gnome-session doesn't launch, it doesn't know what it is, so we need
   some kind of libbamf library to match the .desktop file or whatever so
   that I can add to my yesterday hack a way to set it as a
   required_component dynamically.
  
  If you're already adding a dbus call to set required_component
  dynamically, can't you get gnome-session to also start that component
  when it's added as a required_component?
  
 
 Unfortunately not, because it has to match /Client and /Apps (if you
 look at d-feet, it should be obvious). However, if you launch
 gnome-panel from the command-line or from another process, it doesn't
 get an id (and every --sm-client-id doesn't seem to work) matching it to
 its desktop file, hence the fact we should use libbamf for it, but can
 be a little bit overkill :-).
 
 One idea from seb's after discussing on IRC will be to launch
 gnome-panel by gnome-session using a dbus call. That can works, just
 have to see how hard it is to hook this in gnome-session.

Yeah, this is what I meant; have gnome-session start gnome-panel when
you add gnome-panel as a required component.

If Seb's already brought it up, good.  Great minds think alike ;).



signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: Maverick - Natty upgrade, unity, gnome-panel and windowmanager's party…

[Christopher James Halse Rogers]

On Tue, 2010-11-23 at 12:52 +0100, Didier Roche wrote:
 Hey fellow desktopers,
 
[snip]
 2.2.2 So, we can think the other way around: only run gnome-panel when
 needed and not setting it as a required_components by default in the
 default sessions but still on the gnome classic session (this can be
 done as well as sessions adds some additional gconf paths).
 - 2.2.2.1 if unity runs, nothing to do, no flipping
 - 2.2.2.2 if unity can't run, we need to launch gnome-panel. That's
 currently done as a compiz plugin (and the code is executed even if
 opengl compiz can't be run on that hardware). So, we can launch
 gnome-panel, BUT there is no way to set it dynamically as a required
 component without making heavy changes to gnome-session: basically, what
 gnome-session doesn't launch, it doesn't know what it is, so we need
 some kind of libbamf library to match the .desktop file or whatever so
 that I can add to my yesterday hack a way to set it as a
 required_component dynamically.

If you're already adding a dbus call to set required_component
dynamically, can't you get gnome-session to also start that component
when it's added as a required_component?



signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: [ubuntu-x] [Retitled] i830 support

[Christopher James Halse Rogers]

On Sat, 2010-10-02 at 08:29 -0600, Gordon Schumacher wrote:
 On 09/22/2010 06:55 PM, Christopher James Halse Rogers wrote:
  On Wed, 2010-09-22 at 10:27 -0600, Gordon Schumacher wrote:

  On 09/20/2010 05:07 PM, Bryce Harrington wrote:
  
  Aha, gotcha.  I *suspect* the calls are already coded up in the 8xx
  driver code.  If there's anything missing, then it should be possible to
  cargo-cult from the 9xx code.  On the plus side, if you get stuck with
  any API stuff, the Intel developers are friendly and can be reached on
  irc or mail pretty readily.


  I also have some contacts at Intel now, albeit in entirely the wrong
  group; they might be able to pass me along to someone though.
 
  Also, I think I know in broad strokes what it is that broke video for
  me.  I seem to remember that once upon a time, there were two drivers
  one could load for the i830 - the current driver, or the old i810 driver
  (which is still there).  The current driver never worked for me, but the
  i810 driver did.  That doesn't work anymore, but I might be able to
  cargo-cult the older i810 driver code that supported the i830 into the
  new driver.
  
  Hm.  That reminds me of bug a freedesktop.org bug¹ that I thought
  applied to i810, but seems to actually apply to (some) i830s.  If that
  turns out to be your bug then there's a lot of information on that bug,
  including prospective patches.

 
 Um.  So... the release candidate works *perfectly* for me, with respect
 to video: no freaky text mode flicker, no X-shift in the installer... it
 all just works.
 
 That will make it a little hard to debug :)
 
 What changed from Lucid?
 

We stopped trying to load the Intel X driver and just use fbdev instead
on your hardware. :)

You should be able to degrade your experience (in some ways, gaining
features in others) back to Lucid by manually selecting the Intel driver
in xorg.conf (see https://wiki.ubuntu.com/X/Bugs/Mavericki8xxStatus for
instructions).

If that still doesn't get you back to Lucid's behaviour, yay!  Magical
kernel fairies have come in and fixed everything!


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Re: [ubuntu-x] gnome-settings-daemon: the new Xserver?

[Christopher James Halse Rogers]

On Thu, 2010-09-30 at 23:41 +0200, Tormod Volden wrote:
 Hi,
 Over the last years the autodetection abilities of the Xserver has
 been improved to the point that in most cases X detects all screen
 connected and chooses the best resolution available, with no
 configuration needed. However, on the Ubuntu desktop another friend
 increasingly wants to have a say: The gnome-settings-daemon and its
 magic use of xrandr. g-s-d has been useful to let the user choose his
 own screen settings and let them be remembered over sessions. But now
 it wants to overrule the Xserver even in the default configuration,
 before the user even gets a chance to configure anything.
   
 One of the latest changes (gnome_settings_daemon 2.31.91-0ubuntu3)
 introduced more xrandr manipulation (turn on external screens by
 default) and caused a family of regressions like 643118 and 640807. I
 have a couple of issues with this change:
 1) It was pushed into Maverick just before Final Freeze, without
 explanation, without reference to any bug it may fix. I know that
 gnome packages are exempted from upload freeze rules, but I think that
 is to allow upstream bug fixes to flow in, and not to lightly add
 Ubuntu changes.
 2) If external screens need to be enabled for some reason, why
 shouldn't the Xserver do it instead? This smells of plastering and
 workarounds to me. And do for example Xubuntu and Kubuntu users not
 want the same display modes by default?
 
I was under the impression that this is actually the logical conclusion
of the drive to strip required configuration from X, and the “mechanism,
not policy” philosophy.

Determining what to do on monitor hotplug, now that clients actually
*get* hotplug events, seems like it should be done in the desktop
environment.  It's a policy decision that's probably user-specific.

 Note that although (2) reveals my personal opinion, it is not meant
 rhetorically, I have not been following closely lately and have missed
 out on much information. A changelog bug reference would probably have
 helped :) What is exactly the way we want this to work, both as in
 user experience and in the strategics of distributing logic between
 Xserver and g-s-d? Also, is this well coordinated and communicated
 between X team and gnome/desktop team?
 

g-s-d should probably be smarter about not needlessly changing settings,
but I think that g-s-d *should* be in charge of resolution policy.

I think we might want to have a multi-head discussion at UDS with the
design team and the various desktop teams to work out the user
experience we want.

 I am sure some of the reported bugs boil down to bugs in the graphic
 drivers and that the above g-s-d changes would otherwise have been
 fine, but this is a minefield to be treaded carefully, especially in
 these days of KMS migration.
 
 Tormod
 




signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Re: maverick radeon 6.13.2 SRU?

[Christopher James Halse Rogers]

On Thu, 2010-09-30 at 10:56 -0700, Bryce Harrington wrote:
 On Thu, Sep 30, 2010 at 02:47:02PM +0100, Daniel J Blueman wrote:
  What is the consensus an SRU for the radeon 6.13.2 Xorg driver in Maverick?
  
  http://lists.x.org/archives/xorg-driver-ati/2010-September/017206.html
  
  It is probably too late to ship with the media, so is eligible for a
  post-release update, right?
 
 No, the SRU team has typically been strictly against doing new upstream
 versions of video drivers as SRUs, so ubuntu-x usually does not do this.

I've also seen some IRC reports of this driver release dramatically
reducing performance under KDE, although that's somewhat of an anecdote
at this point.


signature.asc
Description: This is a digitally signed message part
-- 
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] i8xx, again!

[Christopher James Halse Rogers]

On Wed, 2010-09-08 at 09:42 -0400, Eric Appleman wrote:
 On 09/06/2010 05:34 AM, Christopher James Halse Rogers wrote:
  On Mon, 2010-09-06 at 04:52 -0400, Eric Appleman wrote:
  Is Option 2 the shadow framebuffer approach that Chris suggested?
 
  - Eric
 
  No.  As I mentioned in the preamble, that branch still has some
  problems.  We also can't reasonably ship a branch of the intel X driver.
 
  Option 2 is basically “let KMS bring up a bare framebuffer, and use the
  dumb X framebuffer driver to draw to it”.
 
  fbdev has even fewer features than vesa - it doesn't do modesetting *at
  all*.  It'll just use the resolution that the kernel picked on boot.
 Oh wow. This is going to be more troublesome than I thought. Is there 
 really no courage in the ubuntu-x team to harass the Release Drivers for 
 special freeze exemptions to get the proper fixes in? We have a month 
 and yet we're already admitting defeat.

This would be easier if there *were* proper fixes.  There's a very large
kernel patch that touches infrastructure shared by all Intel drivers
that (mostly) fixes one of the big problems on the i855 chipset, and
does nothing for i845 users or i830 users.

There are a couple of -intel X driver branches seeking to address this,
the most recent of which (Chris Wilson's shadow branch) is not a lot
more than fbdev + modesetting support.  There's no 3D, and no 2D
acceleration there as far as I understand it.

 
 For the past few years, most notably with the KMS/GEM/UXA/DRI2 
 transition and the move from -i810 to -intel, whenever a serious 
 regression is discovered you guys have a tendency to throw up your arms 
 and say  it, we'll handle it in the next dev cycle and bodge 
 together a rather unsavory workaround.
 

Yeah.  It's a balancing act.  We want to provide the best experience for
the most users, which means we want the new shiny, but without
regressing support for older hardware.  It's been hard.

 User experience is everything. I have a fond memory of how miserably 
 Hardy and Jaunty ran on my Intel graphics.
 
 My $0.02.
 
 - Eric




signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Re: [ubuntu-x] i8xx, again!

[Christopher James Halse Rogers]

On Mon, 2010-09-06 at 04:52 -0400, Eric Appleman wrote:
 Is Option 2 the shadow framebuffer approach that Chris suggested?
 
 - Eric
 

No.  As I mentioned in the preamble, that branch still has some
problems.  We also can't reasonably ship a branch of the intel X driver.

Option 2 is basically “let KMS bring up a bare framebuffer, and use the
dumb X framebuffer driver to draw to it”.

fbdev has even fewer features than vesa - it doesn't do modesetting *at
all*.  It'll just use the resolution that the kernel picked on boot.


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

[ubuntu-x] Xserver 1.9 transition

[Christopher James Halse Rogers]

Summary for the impatient:

A new X server is soon to be uploaded which requires all the
drivers to be rebuilt.  Be careful when upgrading in the next few
days.


As promised earlier in the cycle, we've got the second X server
transition coming up.  This will take us to X server 1.9, which features
improvements to startup time, some memory usage improvements, and many
DRI2 fixes.

The 1.9 server has a new input and video ABI which means existing driver
packages will break.

The server needs to be uploaded first so the new drivers build against
the correct ABI, which means that there will be a period where safe
upgrades will have held-back packages.  The dependencies should ensure
that you won't accidentally get a non-working combination of X server
and drivers, but be careful if an upgrade wants to remove X packages.

Happy testing!


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Xserver 1.9 transition

[Christopher James Halse Rogers]

Summary for the impatient:

A new X server is soon to be uploaded which requires all the
drivers to be rebuilt.  Be careful when upgrading in the next few
days.


As promised earlier in the cycle, we've got the second X server
transition coming up.  This will take us to X server 1.9, which features
improvements to startup time, some memory usage improvements, and many
DRI2 fixes.

The 1.9 server has a new input and video ABI which means existing driver
packages will break.

The server needs to be uploaded first so the new drivers build against
the correct ABI, which means that there will be a period where safe
upgrades will have held-back packages.  The dependencies should ensure
that you won't accidentally get a non-working combination of X server
and drivers, but be careful if an upgrade wants to remove X packages.

Happy testing!


signature.asc
Description: This is a digitally signed message part
-- 
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: Maverick graphics driver updates?

[Christopher James Halse Rogers]

On Thu, 2010-07-08 at 11:05 +0100, Daniel J Blueman wrote:
 At present in Maverick repositories, we have:
 
 mesa 7.8.1
 xserver-xorg-video-radeon 6.13.0
 xserver-xorg-video-intel 2.11.0
 xserver-xorg-video-nouveau 0.0.16+git20100518
 
 Does it make sense to move to mesa 7.8.2, intel 2.12.0, radeon 6.13.1
 and potentially a newer nouveau snapshot as early as possible, to
 maximise exposure?

These are all planned - in fact, we additionally plan to move to mesa
7.9 and Xserver 1.9.

A launchpad bug won't speed this process.  You're welcome to help,
though - come and say hi in #ubuntu-x!

I was hoping to get Xserver 1.9 in first.  All the drivers will need a
rebuild after this anyway, so it's a good time to update them.

Chris Halse Rogers


signature.asc
Description: This is a digitally signed message part
-- 
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-x] Common bug tags between the X and kernel teams

[Christopher James Halse Rogers]

A fairly large percentage of bugs that get reported against X now end up
being kernel bugs thanks to KMS.  As users cotton on to this shift there
will likely be more bugs reported against the kernel which are actually
an X bug, too.

In X land we've got a rich set of tags¹ set up for describing the
various forms of common brokenness.  Some of these obviously don't apply
to the kernel side of things, some obviously do.

On the kernel side we have a much smaller set of tags² mainly organised
around subsystems.  There's also a single lonely “xorg-needs-kernel-fix”
tag which looks like it could painlessly be folded into the
kernel-graphics tag.

In the X team we've found the wider set of tags quite useful, as we're
generally pretty reluctant to merge bugs by duplicating them unless
exactly the same hardware is involved.  These bugs often get fixed as
group, however - particularly bugs tagged edid and backlight, but also
others - and having the richer tags makes it easier to find bugs to ask
for re-testing.

As we'll be exchanging bugs with more regularity I thought it would be
useful to check that we're on the same page, and to work out a common
set of tags if the kernel team feel they'd be valuable.

[1]: https://wiki.ubuntu.com/X/Tagging 
[2]: https://wiki.ubuntu.com/Kernel/Tagging


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Upcoming X breakage

[Christopher James Halse Rogers]

Summary for the impatient:

A new X server is about to be uploaded which requires all the
drivers to be rebuilt.  Be careful when upgrading in the next few
days.


So far in Maverick X has been a relatively sedentary beast, not much
changed from Lucid.  It's time for X to get a bit more interesting…

We're going to be merging the new 1.8 X server and associated drivers
from Debian over the next couple of days.  This server has a new input
and video ABI, which means existing driver packages will break.

The server needs to be uploaded first so the new drivers build against
the correct ABI, which means that there will be a period where safe
upgrades will have held-back packages.  The dependencies should ensure
that you won't accidentally get a non-working combination of Xserver and
drivers, but be careful if an upgrade wants to remove X packages.

There will be another X transition later in the Maverick cycle when we
switch to X server 1.9.  I'll send out a similar notice then, too.

Happy testing!


signature.asc
Description: This is a digitally signed message part
-- 
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: i915 - kms - lucid - dri(?) problem

[Christopher James Halse Rogers]

It's highly likely that you're seeing bug 541511[1] or one of it's many
duplicates.  There's a kernel patch that *probably* fixes this getting
close to being applied upstream, so the hope is that we can fix this in
an SRU.

 [1]
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/541511


signature.asc
Description: This is a digitally signed message part
-- 
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: [RFC] MP3 player management via Rhythmbox etc.

[Christopher James Halse Rogers]

On Thu, 2010-04-29 at 14:37 -0400, John Moser wrote:
 On Thu, Apr 29, 2010 at 2:31 PM, Brandon Holtsclaw
 m...@brandonholtsclaw.com wrote:
  I use Rhythmbox.  I don't care about Amarok, or whatever.  This will
  be framed for Rhythmbox; as for Kubuntu and whatever else, just cry
  Feature Parity until someone duplicates work solving the same
  problem again.
 
  No need. In this case, Amarok since 1.4-ish has handled media players
  both generic and branded ones ( even media cards ) in this way, I think
  this will be one of those rare cases where the shoes of feature parity
  are reversed :)
 

This has also been (mostly) supported in Rhythmbox[1]  Banshee for
quite some time, via the .is_(audio|media)_player file.  I'd guess that
Amarok is also reading these files?  I'm more familiar with Banshee than
Rhythmbox, but I'm fairly sure both will detect removable storage with
an .is_(audio|media)_player file as a generic DAP, and support the “drag
a playlist to the DAP” workflow you're after.

There's currently no tool I know of to generate the .is_(audio|
media)_player file, but I believe this would be a pretty simple Nautilus
extension to write.

The more advanced parts of your proposed interface - transcode when
space is tight, multiple policies for transcoding, etc, would need to be
implemented, but the basics should work right now.


[1] live.gnome.org/Rhythmbox/FAQ


signature.asc
Description: This is a digitally signed message part
-- 
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: Kernel bug in Intel driver

[Christopher James Halse Rogers]

On Fri, 2010-04-16 at 09:54 +0100, Mark Ellse wrote:
 Also, what about this one, which freezes graphics on a large number of
 Intel boards? (Is Intel a small, insignificant manufacturer whose
 products are not a priority?)
 
 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/456902
 
I'm not entirely sure what more you expect from that bug - it's
importance high, has had an upstream developer participating, and an
awesome member of the x-swat team providing PPA testing packages.  The
fact that it remains unfixed is not due to any lack of work on it!

The X team have been monitoring this, and other similar problems - the
i8xx chips have not had a good time of Lucid.  As you see on that bug
there has been lots of work upstream to isolate and fix the cause.  

Tracking the various upstream bugs you'll see that there have been a
number of false starts, but it looks like there *might* be a fix soon.
That fix won't be going into Lucid's release, as it's a big patch which
touches code for all the Intel cards, and hence might introduce new
problems in the i9xx chips.  If all goes well, this might make it into
lucid-updates and 10.04.1.

Because of the serious stability issues i845 and i855 users have been
reporting we're testing disabling both 3D and KMS on these chips.  If
feedback shows that this still isn't stable, we've got a fallback plan
to switch to vesa on those cards, which has been reported stable.
That's a serious functionality regression, but might be necessary to
provide a sufficiently stable desktop.  In this case, users will be able
to manually enable the -intel driver, KMS, and 3D if they wish - these
bugs are incredibly timing-specific, with some setups crashing almost
immediately after starting X, and others crashing less than once a week.


signature.asc
Description: This is a digitally signed message part
-- 
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: Gthumb as default image viewer?

[Christopher James Halse Rogers]

On Sun, 2010-03-14 at 21:42 +0200, Otto Kekäläinen wrote:
 su, 2010-03-07 kello 12:09 -0800, Rick Spencer kirjoitti:
  On Sun, 2010-03-07 at 12:06 -0800, Rick Spencer wrote:
   On Sun, 2010-03-07 at 21:02 +0200, Otto Kekäläinen wrote:
The thread ended up in that F-Spots view one image in folder -mode
should have basic editing capabilities included. Unfortunately in Lucid
this does still not exist, and I really think that EOG should be
replaced with GThumb to give users even the basic functions (that are
even found in Windows XP).
   It's coming. Please review the work items.
  
 [..]
  https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-default-apps
  
  [raof] f-spot: provide save button and drop instant saving: DONE
  [raof] f-spot: provide undo in edit mode: TODO
  [raof] f-spot: provide next/prev buttons in view mode: TODO
 
 Thanks, I just tested it and it is definately an improvement. I'd still
 hope that the F-Spot edit mode would also contain functions to rotate
 images. There are rotate buttons in EOG, but it would be a better user
 experience to have all edit functions in one view (=the F-Spot edit
 view).

There's the existing “straighten” tool, which allows for a small degree
of rotation to make the horizon horizontal, and there are 90° rotation
buttons - like in EOG - on the toolbar.  You may not have the toolbar
enabled, however, which means you'll also be missing the “undo” button.

It might be a good idea to ignore the user's preferences and
unconditionally enable the toolbar on startup in View mode.



signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: Review of featured applications

[Christopher James Halse Rogers]

On Fri, 2010-03-26 at 03:32 +, Shane Fagan wrote:
 On Fri, 2010-03-26 at 14:22 +1100, Robert Ancell wrote:
  On 26/03/10 14:05, Shane Fagan wrote:
   - Remove Eclipse
   - Huge download
   - Only supports Java out of the box
   - The Eclipse brand is strong enough that it doesn't need promoting

   Im going to go out on the limb and suggest we replace it with
   Monodevelop it supports mono,java,python,valaetc although require
   the user to install the support for each language.
  
  My review of all the supplied IDEs showed MonoDevelop to appear to be 
  the easiest to use, but:
  - I've never used an IDE for any significant period of time
  - I didn't use any of the proposed IDEs to do more that write a hello 
  world program.
  
  We need to consider what sort of user clicks on featured applications 
  and which users would benefit from the suggested IDE.
  My experience of IDE users is:
- They're generally passionate users who have a preferred IDE (much 
  like text editors for non-IDE programmers).  So by suggesting an IDE 
  we're targeting people who haven't already chosen an IDE.
- IDEs tend be a part of a developer package.  If we suggest 
  MonoDevelop will users link well to documentation and the developer 
  community?  Or will it just be a fancy text editor/compiler?
  
  Saying it in a simpler way:
  - Will an IDE encourage people to learn programming?
  - Will opportunistic developers be able to use it to complete their 
  desired project?
  - Will experienced developers find the suggested IDE helpful or will 
  they already use their existing IDE/do the research themselves?
  
  
 Well no it wouldnt encourage people to learn programming. 
 Hmmm I dont think there is any good python IDE for the opportunistic
 developer.
 I dont think many experienced developers use IDEs too much. The ones I
 know in development companies use eclipse (or different flavors of
 eclipse) or text editors. I use netbeans in college but for python I use
 gedit. 

I think Python (and dynamic languages in general) are just really hard
to do good IDEs for, for roughly the same reason that it's hard to do
static fault analysis, at least in general.  In some ways I think it's a
semi-deliberate trade-off - python is much easier to write, but needs to
*be* written.  In the same way that python much easier to unittest, but
needs to be unittested (more than languages with a static type system,
compilers, etc).

IDEs with decent code completion are a joy to work in.  I'd be much less
productive hacking on C# code in emacs than in MonoDevelop.


signature.asc
Description: This is a digitally signed message part
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Call for Testing: Nouveau

[Christopher James Halse Rogers]

Hi all,

The drive towards stabilising Nouveau for a rocking Lucid LTS release
has resulted in large changes to the packaging stack.  Nouveau's kernel
module is now in the main kernel package, which fixes most of the
problems people have previously reported.  If you have previously tested
nouveau and found your VTs didn't work, or that plymouth splash didn't
work, or that you just got no display at all please test again with the
2.6.32-16 kernel.  If you've updated in the last day, you should already
have this kernel installed.  You can check which kernel you are running
by running “uname -r” from a terminal - it should print something like
“2.6.32-16-generic”.  The important bit is 2.6.32-16.

This work means that nouveau now has a lack of good bugs reported
against it.  I'm hoping that the fine testers of Ubuntu can rectify
this!  If you've got an nvidia graphics card, please try disabling the
restricted drivers and testing nouveau for a day.  Just using your
computer with the nouveau drivers and reporting any problems you
encounter will be useful, but if you want to test more systematically,
there's a list[1] of things to check on the wiki.

Filing a good bug is as simple as running “ubuntu-bug xorg” and
describing the problem you see, and how you can trigger it, in the
report.  The apport hooks will magically attach all the relevant logs
for you.

If you run into a bug and want to invest some extra effort to help get
it fixed, after reporting the bug you can test with a newer version of
Nouveau.  These packages are available in the xorg-edgers/nouveau PPA.  
Further instructions are on the wiki[2].

Your feedback is greatly appreciated.  Let's go find some bugs!

[1]: https://wiki.ubuntu.com/X/Testing/NouveauEvaluation
[2]:
https://wiki.ubuntu.com/X/Testing/NouveauEvaluation#upstreamtesting 


signature.asc
Description: This is a digitally signed message part
-- 
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: Lots of Kernel related brakage in Lucid (amd64)

[Christopher James Halse Rogers]

On Mon, 2010-03-15 at 05:09 +, Scott Beamer wrote:
 Just downloaded the latest nightly live CD and installed.
 
 After reboot computer freezes at splash screen.

This might be plymouth; see if hitting SysRq+Alt+k kills the splash
screen and brings up X.

 
 Reinstalled from a previous dialy Live CD (about a week old) and ran sudo 
 apt-get-update  sudo apt-get dist-upgrade.
 
 Rebooted, screen freeze again at Ubuntu splash screen.
 
 Rebooted and reverted to previous kernal and was able to log in just fine.
 
 On a related note
 
 Upgrding kernel-headers package to the latest causes apt/dpkg to lock up 
 while unpackaing.
 
 That took a lot of playing with to work around.
 
 Workaround for now is to remain with older Kernel version 2.6.32-15
 
 
 Hardware:
 
 ASUS Laptop
 Intel Core i5-430M CPU
 4GB of DDR3 1066MHz SDRAM
 500GB Hard Drive 
 NVidia GT325M Graphics Engine with 1GB DDR3 Dedicated VRAM (also Intel 
 Onboard GMA and sound).

Ah!  Someone's got some switchable graphics.  That's not going to be as
well-tested as other setups, so you might run into problems others
aren't seeing.

If you feel like some additional testing, the NouveauEvaluation wiki
page[1] has instructions for testing more recent upstream versions of
Nouveau.  There's at least one commit in there relevant to switchable
graphics.

Regardless of whether you test the newer nouveau, it would be useful if
you could file a bug on launchpad.  “ubuntu-bug xorg” will attach a
bunch of useful information.


[1]: https://wiki.ubuntu.com/X/Testing/NouveauEvaluation#upstreamtesting



signature.asc
Description: This is a digitally signed message part
-- 
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-x] Call for Testing: Nouveau

[Christopher James Halse Rogers]

Hi all,

The drive towards stabilising Nouveau for a rocking Lucid LTS release
has resulted in large changes to the packaging stack.  Nouveau's kernel
module is now in the main kernel package, which fixes most of the
problems people have previously reported.  If you have previously tested
nouveau and found your VTs didn't work, or that plymouth splash didn't
work, or that you just got no display at all please test again with the
2.6.32-16 kernel.  If you've updated in the last day, you should already
have this kernel installed.  You can check which kernel you are running
by running “uname -r” from a terminal - it should print something like
“2.6.32-16-generic”.  The important bit is 2.6.32-16.

This work means that nouveau now has a lack of good bugs reported
against it.  I'm hoping that the fine testers of Ubuntu can rectify
this!  If you've got an nvidia graphics card, please try disabling the
restricted drivers and testing nouveau for a day.  Just using your
computer with the nouveau drivers and reporting any problems you
encounter will be useful, but if you want to test more systematically,
there's a list[1] of things to check on the wiki.

Filing a good bug is as simple as running “ubuntu-bug xorg” and
describing the problem you see, and how you can trigger it, in the
report.  The apport hooks will magically attach all the relevant logs
for you.

If you run into a bug and want to invest some extra effort to help get
it fixed, after reporting the bug you can test with a newer version of
Nouveau.  These packages are available in the xorg-edgers/nouveau PPA.  
Further instructions are on the wiki[2].

Your feedback is greatly appreciated.  Let's go find some bugs!

[1]: https://wiki.ubuntu.com/X/Testing/NouveauEvaluation
[2]:
https://wiki.ubuntu.com/X/Testing/NouveauEvaluation#upstreamtesting 



signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Call for Testing: Nouveau

[Christopher James Halse Rogers]

Hi all,

The drive towards stabilising Nouveau for a rocking Lucid LTS release
has resulted in large changes to the packaging stack.  Nouveau's kernel
module is now in the main kernel package, which fixes most of the
problems people have previously reported.  If you have previously tested
nouveau and found your VTs didn't work, or that plymouth splash didn't
work, or that you just got no display at all please test again with the
2.6.32-16 kernel.  If you've updated in the last day, you should already
have this kernel installed.  You can check which kernel you are running
by running “uname -r” from a terminal - it should print something like
“2.6.32-16-generic”.  The important bit is 2.6.32-16.

This work means that nouveau now has a lack of good bugs reported
against it.  I'm hoping that the fine testers of Ubuntu can rectify
this!  If you've got an nvidia graphics card, please try disabling the
restricted drivers and testing nouveau for a day.  Just using your
computer with the nouveau drivers and reporting any problems you
encounter will be useful, but if you want to test more systematically,
there's a list[1] of things to check on the wiki.

Filing a good bug is as simple as running “ubuntu-bug xorg” and
describing the problem you see, and how you can trigger it, in the
report.  The apport hooks will magically attach all the relevant logs
for you.

If you run into a bug and want to invest some extra effort to help get
it fixed, after reporting the bug you can test with a newer version of
Nouveau.  These packages are available in the xorg-edgers/nouveau PPA.  
Further instructions are on the wiki[2].

Your feedback is greatly appreciated.  Let's go find some bugs!

[1]: https://wiki.ubuntu.com/X/Testing/NouveauEvaluation
[2]:
https://wiki.ubuntu.com/X/Testing/NouveauEvaluation#upstreamtesting 



signature.asc
Description: This is a digitally signed message part
-- 
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] Kernel v2.6.33 drm update

[Christopher James Halse Rogers]

On Sat, 2010-03-06 at 12:47 +, Andy Whitcroft wrote:
 On Fri, Mar 05, 2010 at 03:32:05PM -0800, Luis R. Rodriguez wrote:
  On Fri, Mar 5, 2010 at 2:54 PM, Timo Aaltonen tjaal...@cc.hut.fi wrote:
   On Fri, 5 Mar 2010, Bryce Harrington wrote:
  
   On Fri, Mar 05, 2010 at 06:56:11PM +, Andy Whitcroft wrote:
   We are therefore planning to upload a hybrid
   2.6.32 kernel containing the 2.6.33 drm backported.
  
   Btw, for bug report fiddling purposes, is there a reliable way to detect
   the drm version installed?  The drm version does not show up in uname -a
   of course, and `dmesg|grep drm|grep 2\.6\.33` returns nothing (at least,
   on nouveau).
  
   (Basically I want a way to automatically distinguish between bug reports
   that were tested with the new 2.6.33 drm vs those that won't, so we can
   prioritize our attentions accordingly.)
  
   Isn't the kernel abi enough for that? -16 has the backport, anything
   before that doesn't.
  
  Right but its still good to know a backport from which 2.6.33.y
 
 Fair point.  Right now we have v2.6.33 straight.  But I do see how we
 might want some finer grain record of the version.  I will look at where
 we can expose that.

For prior art, Nouveau's upstream build captures the output of
git-describe and displays it on module load.  Feeding the git
information into the kernel build  getting the other drm drivers to
display the same information shouldn't be too hard.


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Re: [ubuntu-x] Lost monitor at boot (was Re: Nouveau - remaining tasks.)

[Christopher James Halse Rogers]

On Tue, 2010-02-23 at 10:39 -0800, Bryce Harrington wrote:
 On Mon, Feb 22, 2010 at 01:38:37PM +1100, Christopher James Halse Rogers 
 wrote:
  Finally, I'm still seeing some reports on IRC of nouveau turning off the
  monitor on boot, leaving the system unusable.  I've done some
  investigation, and I've got a hypothesis: if vga16fb gets loaded first,
  it claims fb0 and everything dies a fiery death.  
 
 Are you able to reproduce this issue?  Is there a bug# for tracking?  If
 not, let's get a bug report in about it filed against
 linux-backports-modules.

On further investigation, I'm not able to reproduce this, and I haven't
heard any further complaints.  If this was a bug, I think it's been
fixed.


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Re: [ubuntu-x] Status of kernel X drivers

[Christopher James Halse Rogers]

On Thu, 2010-02-18 at 10:29 -0800, Bryce Harrington wrote:
 On Thu, Feb 18, 2010 at 02:57:18PM +0200, Timo Aaltonen wrote:
  On Thu, 18 Feb 2010, Christopher James Halse Rogers wrote:
   I'd suggest that we stick with our current libdrm  2.4.18, lbm-nouveau,
   and xserver-xorg-video-nouveau stack, and cherry pick  backport
   whatever fixes we want to grab.  In which case, as long as there's a
   2.6.33 drm in lbm, the nouveau stack is happy.
  
  2.4.18 has other fixes in it, so better to just revert the offending 
  commit with a patch, and then decide if the ABI bump is worth it. Less 
  work than pulling a number of patches on top of 2.4.17.
 
 I'd agree.  Plus it'll be easier to explain we're carrying 2.4.18 minus
 patch foo.
 
 Which is the commit(s) that needs reverted?

libdrm would need b496c63143e9a4ca02011582329bce2df99d9b7c and I think
also 88e8a8bbaf026aa10225880001ab7ca1c392168a reverted.

If we're comfortable with pulling from the nouveau kernel tree[1] for
linux-backports-modules-nouveau, then going over the API bump would
indeed make cherry-picking and backporting fixes easier.  The API bump
hasn't made it out of that tree yet, as far as I'm aware.

If we're additionally going to have lbm packages for intel and radeon
built from 2.6.34, I think it makes sense to pull from the nouveau tree
now, and later switch to the .34 tree when we pull the rest of the drm
drivers for lbm.

[1] http://cgit.freedesktop.org/nouveau/linux-2.6/



signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

[ubuntu-x] Call for testing: nouveau open-source nvidia driver

[Christopher James Halse Rogers]

We're aiming to ship Nouveau as the default driver for nVidia cards in
Lucid as a better nv.  Towards this end there are now packages ready
for wider testing in the xorg-edgers/nouveau PPA[1].

To test the nouveau drivers you just need to add the PPA with
“add-apt-repository ppa:xorg-edgers/nouveau”, update your package
lists, upgrade your packages and then install the
“xserver-xorg-video-nouveau” package from the PPA.  This should
install the needed packages: linux-backport-modules-nouveau for the
kernel module, nouveau-firmware, and xserver-xorg-video-nouveau for
the X driver.  The upgraded xserver-xorg-core should automatically use
the nouveau drivers without an xorg.conf, and the newer libdrm is also
needed.

All Lucid users can help with testing - if you don't have nvidia
hardware please test that it doesn't break your existing drivers.

Users with nvidia hardware should test that they get:
1) Kernel modesetting from early boot including a nice
native-resolution console.
2) The nouveau driver is automatically loaded by X without needing an
xorg.conf - this can be checked in /var/log/Xorg.0.log, as usual.
3) The nouveau driver generally works as well as nv - nouveau should
pick the correct resolution, dual-head should work, video should play
nicely, etc.

You should not expect to work:
 * The nvidia binary drivers.  The nouveau kernel module will bind to
the hardware and there is no mechanism for handing off to nvidia
kernel module.
 * 3D acceleration.  Brave souls can build mesa from source (and may
well find that they can run compiz), but we will not be shipping the
3D component in Lucid.

For the moment problems can be reported as replies to this mail - I'm
particularly interested in any situation where this breaks non-nvidia
hardware.

[1]: https://edge.launchpad.net/~xorg-edgers/+archive/nouveau

-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Re: Making Resolution Setting More User-Friendly

[Christopher James Halse Rogers]

On Tue, Jan 5, 2010 at 12:49 AM, Markus Hitter m...@jump-ing.de wrote:

 Am 01.01.2010 um 01:13 schrieb Craig Van Degrift:

 I have been troubled by how confusing it can be for new users of
 Ubuntu/Kubuntu/Xubuntu to get their old display hardware showing
 higher
 resolution.  I have attempted to write a WWW page that is designed
 to help
 these newbies as well as confused old-timers like myself.  Could
 anyone
 interested in helping with this look at

 http://yosemitefoothills.com/UbuntuLucidDisplayNotes.html

 and give me feedback.

 I have the same problem and solve it by putting something like this
 into /etc/X11/Xsession.d/45custom_xrandr-settings ($HOME/.Xsession no
 longer works):

 xrandr --newmode 1280x1024 SGI 134.400 1280 1296 1440 1688 1024
 1025 1028 1066 +hsync +vsync
 xrandr --addmode VGA1 1280x1024 SGI

 You can get the required numbers with PowerStrip, a tool for MS
 Windows.
You can also get them from the “cvt command.

I have toyed with the idea of adding this to a “Do you not see the
resolution you're after button in gnome-display-properties.  It would
actually be quite easy to implement, although I think it'd require
extending the xrandr plugin for gnome-settings-daemon a bit.

For added bonus points, it would talk to gdm's gnome-settings-daemon, too.

-- 
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-x] Nouveau: what's happening upstream, what it means for Lucid

[Christopher James Halse Rogers]

I've been following what's happening upstream with respect to nouveau,
and there have been a couple of interesting events.

Firstly, nouveau is now in staging in Linus' tree[1]. Commit id is
9764757932ce26f139332f89d1d3b815e4cc56ab.
So, for Lucid+1 it looks like we won't have to do anything special to
get nouveau.

For Lucid, we can do a number of things:
1) A nouveau module slightly older than the one pushed to Linus can
happily build  run against an almost-unmodified Lucid drm.ko.  This
option looks pretty safe, at least as far as breaking unrelated drm
drivers.  There's a proof-of-concept “nouveau-scratchpad branch of
Lucid's 2.6.32-7 kernel with the nouveau bits dropped in at
cooperteam.net/kernel-lucid-nouveau.git.  This will make it more
difficult to pull upstream bugfixes, but is the safest way to get an
in-kernel nouveau.ko.

2) We can try and pull nouveau from Linus' tree.  This is more
difficult, as it requires some changes in drm  ttm; specifically the
factoring out of displayport support into drm_kms_helper, and changes in
the ttm_placement APIs, which will affect i915 and radeon, respectively.

3) Do something different; either an out of tree backports module, or
keep updating the nouveau-kernel-source dkms package.

[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9764757932ce26f139332f89d1d3b815e4cc56ab


-- 
Ubuntu-x mailing list
Ubuntu-x@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-x

Re: [minor] Tray Tooltips

[Christopher James Halse Rogers]

On Tue, 2009-09-29 at 12:43 -0400, Brian Vidal wrote:
 If we look at the tooltips on the tray we will see a big inconsistency  
 between them.

This sounds like a good papercut candidate.  Consistency among the
default notification icons seems a worthy goal.

 
 I suggest to use to volume-applet way of displaying tooltips.
 
 
 Volume Applet
 bOut: xx%/b
 {volume in dB}
 {device name}
 
 nm-applet
 Network Manager
 
 bNetwork: {network name}/b
 {signal strengh} %
 Time connected: {uptime} or IP: {ip} or Speed: {speed}
 
 Power Manager
 gnome-power-manager
 
 bBattery: {batery} %/b
 Time available: {h} {m}
 Battery Status:  {capacity}% - Good.

Battery capacity might be a bit niche for a default tooltip!


signature.asc
Description: This is a digitally signed message part
-- 
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: [minor] Tray Tooltips

[Christopher James Halse Rogers]

On Tue, 2009-09-29 at 18:29 -0400, Brian Vidal wrote:
 On Tue, 29 Sep 2009 18:18:49 -0400, Christopher James Halse Rogers  
 r...@ubuntu.com wrote:
 
 So, should I fill a bug?
 or will *somebody* fix it without notice??

As this isn't a clear-cut case, I'd wait for further comments on this
idea and the design.  Once we have a clear sense of what we want, *then*
file bugs against the relevant packages.

 
  On Tue, 2009-09-29 at 12:43 -0400, Brian Vidal wrote:
  If we look at the tooltips on the tray we will see a big inconsistency
  between them.
 
  This sounds like a good papercut candidate.  Consistency among the
  default notification icons seems a worthy goal.
 
 
  I suggest to use to volume-applet way of displaying tooltips.
 
 
  Volume Applet
  bOut: xx%/b
  {volume in dB}
  {device name}
 
  nm-applet
  Network Manager
 
  bNetwork: {network name}/b
  {signal strengh} %
  Time connected: {uptime} or IP: {ip} or Speed: {speed}
 
  Power Manager
  gnome-power-manager
 
  bBattery: {batery} %/b
  Time available: {h} {m}
  Battery Status:  {capacity}% - Good.
 
  Battery capacity might be a bit niche for a default tooltip!
 
 
 -- 
 Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
 




signature.asc
Description: This is a digitally signed message part
-- 
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: How to put our new package (for free) into Karmic 9.10

[Christopher James Halse Rogers]

On Mon, 2009-07-27 at 12:10 +0200, Ilgis Ibragimov wrote:
 Hi,
 
 thank you for your kind answers. Please, see my answer below.
 
 Max Bowsher wrote: 
  Jonathan Carter (highvoltage) wrote:

   Hi Ilgis
   
   Ilgis Ibragimov wrote:
   
One small question regarding to our package. We have it right now as
sources, and we can provide as sources. However, it is highly desirable
to build many (about 10) different libraries for different platforms,
for example:
1. CPU AMD 32bit,
2. CPU AMD 64bit,
3. CPU Intel 32bit,
4. CPU Inter 64bit,
5. GPU NVIDIA 8xxx,
6. GPU NVIDIA 9xxx,
7. GPU NVIDIA 2xxx,
and probably some other minor things depending on amount of Cores in 
CPU.

We can provide binaries as well. Would you please, to tell me is the
REVU is the right place where I get an information how to organize the
package so that it provide only the best suitable version for user?
  
   I believe you will only need to upload the source package to REVU, from
   there the build server(s) should be able to build the the binary
   packages.
   
  
  REVU is a tool for publishing proposed source packages for review by
  MOTUs and the community - no automatic builds are performed on REVU uploads.
  
  REVU is definitely the right place to be publishing a new source package
  you would like advice and comments on, but asking specific questions
  either on this mailing list or on the #ubuntu-motu IRC channel is also
  advisable.
  
  In particular, why does your package need so many platform-variant
  builds? Mostly Ubuntu only differentiates between x86 and x86_64 CPU
  architectures.

 Our package is very processor dependent. It means we have several
 different algorithms depending on amount of CPU cores, or processor
 core and on the amount of L1/L2/L3 cache. It is really highly
 commercially tuned. We decide to share it in Ubuntu community, so, it
 is the main reason why we should build several versions depending on
 hardware. We may install CPU detector in sources, but it will force
 user to compile this package, that might be not very convenient.

I presume this detection isn't done at run-time for performance reasons?
I would naively expect the library to perform this detection once at
initialisation and from then on call into the appropriate
system-specific code, but there's probably a reason you aren't already
doing this.

As long as all these different build configurations can be manually
configured (ie: don't automatically tune for the system they're being
built on) it would be possible to build all these different binary
packages; it'll just be a bit of a pain.  Both for the packaging and for
the users.


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Fwd: [Ubuntu-gaming] AMD/ATI vs NVIDIA vs Intel

[Christopher James Halse Rogers]

On Sun, 2009-07-05 at 22:03 -0400, Danny Piccirillo wrote:
 Fwd'd. 
 
 -- Forwarded message --
 From: John Vivirito gnomefr...@gmail.com
 Date: Sun, Jul 5, 2009 at 21:37
 Subject: Re: [Ubuntu-gaming] AMD/ATI vs NVIDIA vs Intel
 To: ubuntu-devel-discuss@lists.ubuntu.com
 
 
 On 06/22/2009 09:36 AM, Remco wrote:
  On Sun, Jun 21, 2009 at 10:57 AM, Ryan Swartserjndest...@gmail.com
 wrote:
  Well, Intel adopting Moblin might see them becoming a much stronger
 Linux
  partner, but then again, you never know what clandestine things are
 going on
  in the background dealings (although moblin looks really cool now,
 so
  personally I'm glad about Intel's involvement).
 
  And I think Intel is heavily involved with the Xorg project. Aren't
 a
  couple of Intel guys leading the project now?
 
  Nvidia drivers have never given me trouble under Linux
 
  If you want to try the Nouveau drivers, you should install Fedora 11
  on a USB stick and add nouveau.modeset=1 to GRUB. That's a really
 easy
  way to test it, without messing up your Ubuntu install.
 
  Remco
 
 
 We have the free drivers in the following PPA
 deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu karmic main
 deb-src http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu karmic main
 Please let it be known the packages in this repo are not
 stable and may not work.
 Had to add that so people dont blame me when they fail
 to work :).
 I have nothing to do with those packages other than a user

If you're wanting to play with nouveau, the xorg-edgers' nouveau ppa[1]
is a fine place to start.

[1] https://edge.launchpad.net/~xorg-edgers/+archive/nouveau



signature.asc
Description: This is a digitally signed message part
-- 
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: Infrastructure vs. Interface

[Christopher James Halse Rogers]

On Thu, 2009-07-02 at 13:40 -0500, Patrick Goetz wrote:
...
snip
...
 One area where I agree that there is considerable room for improvement 
 and something that would have to be fixed in order for your idea to work 
 is package dependencies. Currently most people use stuff like debhelper 
 to build packages, which means AFAIK that dependencies are set against 
 the currently installed packages on the machine on which the package is 
 being built, which usually translates into dependencies that are 
 stricter than they need to be.  In the Real World(tm) I often find 
 myself working on a project where I must have feature X in application 
 Z, which is only available in version N+1, while version N is available 
 in the installed distro.  No problem; I go to the package pool for 
 distro-newer, grab version N+1 of application Z and try to dpkg -i it, 
 only to be told something like unmet dependencies:  this program 
 requires libncurses_5.7.1.2 and you only have libncurses_5.7.1.1 
 installed.  For reals?  Sorry, I'm skeptical.  Of course I can download 
 the source package and use dpkg-buildpackage, but at this point you lose 
 about 90%+ of whatever users were still left trying to solve their 
 problem in a somewhat sane fashion.

The premise here is inaccurate: packages don't pick up versioned library
dependencies based on the installed version.  The observation is
accurate, though - the versions can be unnecessarily strict.  

The versioned library dependency information is taken from the shlibs
file provided by the library package.  This is meant to have the version
bumped each time new interfaces are added - otherwise the dependency
would be incorrect.  This is unnecessarily strict, in that if the
application doesn't link to any of these new interfaces it still gets a
versioned dependency against the most recent package that added
interfaces.

dpkg has fairly recently grown a different dependency mechanism, based
on versioning the actual ABI symbols; that allows less conservative
versioning of dependencies while still providing correct dependencies.
This still requires manual work, and isn't mandatory, so not all
libraries are going to use symbol files anytime soon.


signature.asc
Description: This is a digitally signed message part
-- 
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: Replace PulseAudio with OSS v4?

[Christopher James Halse Rogers]

On Sat, 2009-06-20 at 01:47 -0400, Danny Piccirillo wrote:
 After reading this post on Insane Coding (via Slashdot) it seems that
 PulseAudio is actually a very bad choice in the long term due to
 horrible latency
[Data needed]
  and lower sound quality
[Data needed]
 and that we should work to use OSS v4. It's a long read but seems to
 be worth it. What do others think about this? 

That the blog post was long on verbiage and contained no data.  Also
that the author concentrated on the audio-mixing role of PulseAudio to
the exclusion of its other, in my opinion more interesting, features
such as audio hotplug.  Oh, and that the comments suggest that the OSSv4
kernel components would apparently require extensive work to be accepted
into mainline.

There may be value in considering OSS v4, but the foundation of that
consideration should be actual data.  I don't believe that blog post (a)
contained any data, or (b) made a particularly strong argument for OSS
v4 over ALSA.

Members of the audio-team may have more interesting and informed
contributions.


signature.asc
Description: This is a digitally signed message part
-- 
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: Replace Tomboy with Gnote?

[Christopher James Halse Rogers]

On Tue, 2009-06-16 at 23:32 -0400, Danny Piccirillo wrote:
 Let's all refrain from a mono flamewar. We all know where we stand (if
 you don't, look elsewhere to learn more!) and won't change anyone's
 opinion. 
 
 
 Anyways, someone on the forums started a discussion about this and i
 was wondering what you guys on the list though. There was a surprising
 amount of support and quite a few people seem to have already switched
 to Gnote. Reasons seem to be: improved integration, similar look,
 faster and uses less memory, and it's smaller (and for those who care,
 it doesn't require mono). Reasons against seem to be: lacking some
 features. There didn't seem to be much detail on any of the points on
 both sides though. 
 

There doesn't seem to be a lot of content here.
Questions that would need to be answered:
* Better integration with what?
* Faster - as measured by?  How much faster?  Will this remain when it
is feature-complete?
* Less memory - again, as measured by?  How much less?  Will this remain
when it is feature-complete?
* What features does it lack?

And additionally:
* How responsive is upstream?  
* How quickly are bugs fixed?
* Is upstream likely to be robust?
* Security flaws?

Without answers to these questions there's really nothing to discuss.
If you can provide some answers to these questions, there's a discussion
to be had and the tradeoffs can be weighed.  Otherwise there's no data,
and the discussion will revolve solely around posters objections to
Mono.


signature.asc
Description: This is a digitally signed message part
-- 
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: Gnome is falling behind in Karmic--

[Christopher James Halse Rogers]

On Sun, 2009-06-14 at 21:35 -0700, Dean Loros wrote:
 On 06/14/2009 09:11 PM, Dmitrijs Ledkovs wrote:
  2009/6/15 Dean Loros autocross...@gmail.com:

  Talking in the forums it has been noted that Gnome will be at 2.27-3 by
  mid this week...Whilst we are still at 2.26---I was wondering if there
  are problems with bringing the new stuff in?
 
  --
  Dean Loros
  Performance by Design Ltd.
  autocrosser at ubuntuforums.org
  
  Gnome follows major, odd/even releases. 2.27.3 will be 3 alpha
  milestone of a 27 UNSTABLE  EXPERIMENTAL release for developers. the
  2.27 series will eventually (somewhere in september) will become a
  STABLE 2.28 release.
 
  Karmic will ship with 2.28. If you really want to run 2.27.X gnome you
  can run Karmic Alpha's (currently at alpha 2). This Karmic Alpha is
  not production ready release either. So expect a lot of brekage,
  regressions and instability. Afterall it has new X.org kernel unstable
  Gnome and etc.
 
  We are not behind, we are using the latest stable 2.26 release of
  gnome in a stable release and playing around with experimental gnome
  in our development release.
 

 Yes--I do know all of the above--Have been with Ubuntu from Warty  have
 run the Garnome project many times several years ago--I am currently
 using Karmic  was looking thru Synaptic--hence my question.
 
 I have been testing software for over 10 years now---So I not afraid to
 run unstable or testing appsI was meerly curious---I see more 2.26
 gnome that I do 2.27..

Many GNOME components haven't actually released a tarball for 2.27.  As
far as a cursory browse of the actual tarballs goes [1], Karmic is
pretty much up to date with all the latest releases.  Evolution is the
only one that I've noticed behind.

[1] ftp://ftp.gnome.org/pub/gnome/desktop/2.27/2.27.2/sources/


signature.asc
Description: This is a digitally signed message part
-- 
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: GRUB 2 now default for new installations

[Christopher James Halse Rogers]

On Thu, 2009-06-11 at 09:20 +0200, Markus Hitter wrote:
 Am 10.06.2009 um 21:44 schrieb Lars Wirzenius:
 
  ke, 2009-06-10 kello 15:21 -0400, John Moser kirjoitti:
  Every argument for putting Grub or the kernel on a separate partition
  has been based around the idea that these files are somehow more
  important than, say, /bin/sh
 
  Putting the kernel (i.e., /boot) on a separate partition is often
  mandated by the BIOS not being able to read all of a large hard  
  disk. I
  have a motherboard from 2008 that has that problem, so it's not  
  ancient
  history, either.
 
 Additionally, if you have more than one installation of Ubuntu on the  
 same platter, you really want to share /boot with both installations.
 
 Not doing so means two /boot's, while you can address only one of  
 those in the master boot record. As /boot also contains kernels, you  
 end up booting grub from one partition and the kernel from the other  
 partition. Kernel install scripts can't deal with such a situation,  
 you end up sync'ing those two /boots manually after each update of  
 one of the kernels.
 
Kind of.  I don't have separate /boot partitions for my Karmic, Jaunty,
 Squeeze installs - grub2 + os-prober makes this work pretty well, but
it does require running update-grub2 in the Karmic install to update the
master grub.cfg.

It's a bit of a trade-off, really.  Not sharing /boot means a manual
step for non-Karmic kernel ABI updates, sharing /boot in my experience
results in contention for menu.lst.


-- 
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: GRUB 2 now default for new installations

[Christopher James Halse Rogers]

On Wed, 2009-06-10 at 23:35 +0200, Reinhard Tartler wrote:
 John Moser john.r.mo...@gmail.com writes:
 
  GRUB2 on its own partition is silly.  Like having a separate /boot.
 
 It is required for stuff like root on LVM, a configuration supported by
 the alternate installer.

This is news to my laptop, which is happily booting from /-on-LVM with
grub2.  That's one of the advantages of grub2.

As far as I'm aware, the alternate installer doesn't yet understand that
grub2 can happily handle /boot residing on an LVM volume and installs
LILO instead, but grub2 is quite happy to boot from LVM.


signature.asc
Description: This is a digitally signed message part
-- 
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: Current situation of amarok, and of latex tools

[Christopher James Halse Rogers]

On Mon, 2009-05-25 at 11:12 +0800, Christopher Chan wrote:
  That is not the case with OpenSolaris based ZFS root capable 
  installations. While the whole disk maybe taken up by a zfs pool, the 
  installation will create three at least zfs filesystems. ROOT/, 
  ROOT/opt, export, and export/home all exist on my OpenSolaris 
  installation. So all data is stored in the user's home directory is not 
  at all affected by upgrades or downgrades.
 

 
 ...I need more sleep and to get out of Hong Kong...my command of English 
 has gone down the drain.
 
 Allow me to retype that:
 
 That is not the case with OpenSolaris based ZFS root capable 
 installations. While the whole disk maybe taken up by a zfs pool, the 
 installation will create at least three zfs filesystems. ROOT/, 
 ROOT/opt, export, and export/home all exist on my OpenSolaris 
 installation. So all data is stored in the user's home directory and is not 
 at all affected by upgrades or downgrades.
 
So, what happens when, say, I upgrade to a new version of Evolution and
it decides to convert all its existing mailboxes to the new database
format on first run, and I later want to revert because of new bugs?  It
doesn't matter that I can roll back everything but /home to the previous
Evolution version - that mail is now essentially gone as far as the old
Evolution is concerned.

Alternatively, replace Evolution with MySQL or such.

This is what I understand to be the hard problem in *supporting* package
downgrades.


-- 
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: Current situation of amarok, and of latex tools

[Christopher James Halse Rogers]

On Mon, 2009-05-25 at 07:58 +0200, Vincenzo Ciancia wrote:
 Il giorno lun, 25/05/2009 alle 02.09 +0200, Markus Hitter ha scritto:
  
  Craft a system where people can switch back and forth between  
  different package versions. This update broke foo? - Report a bug  
  and switch foo back to the previous version - Damage gone, user
  happy.
 
 Using alpha (which I do very often, and this reminds me I have to
 download karmic) may lead to data loss. I recall a bug in the gnome
 control center (which was in ubuntu for a short while), where you'd
 loose your entire home directory in a single shot for a bug. I often
 synchronise data with a portable disk but I do not version it, so if I
 loose a directory and then synchronise without checking, I'm **.
 Yes, I should start using a different method.
 
 Crafting a safe testing environment ideally would mean to use a
 filesystem with snapshots. I do not know how difficult would be to
 implement snapshots in ubuntu but it seems that if it was easy we would
 already have those.
 
We do already have those - you want to look up LVM.  It's not as fancy
as ZFS, but it does copy-on-write snapshots just fine, if a little less
efficiently than you'd get with filesystem-level snapshots.  It also
lacks any form of swanky UI.


-- 
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: Current situation of amarok, and of latex tools

[Christopher James Halse Rogers]

On Mon, 2009-05-25 at 03:03 +0100, Dmitrijs Ledkovs wrote:
 2009/5/25 Christopher James Halse Rogers r...@ubuntu.com:
  Having some sort of roll back to previous package version button might
  be a nice idea, though it would need to be designed in such a way that
  made it clear there was no guarantee that it'd work.  I'm not sure
  whether we'd be doing users a favour here.
 
 
 There is a technology to do this but it's not GPL...
 
 OpenSolaris and Nexetra use ZFS which supports snapshots. Before each
 package installation transaction (i.e. one upgrade of N packages) they
 take a snapshot of a system, do the upgrade. If the user doesn't like
 it, they can rollback to any of the previous snapshots because they
 are available.

Won't that only be an acceptable solution if the user is willing to
throw away all the work they've done since the package upgrade?  ZFS is
cool and all, but this doesn't seem to address any of the hard parts of
why downgrades aren't supported now.


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

[Christopher James Halse Rogers]

On Tue, 2009-05-05 at 00:56 -0400, Lakshmanan MR wrote:
 hi,
 
 I am so interested in Ubuntu and i want to go and see whats under the
 hood. So i just want to tweek the ubuntu source code.. 

This is a common misunderstanding as to the role of Ubuntu - there isn't
really much Ubuntu source code, there's just the code of the various
upstream projects (GNOME - which is itself composed of many disparate
projects, the linux kernel, bzr, etc) that are shipped together to form
an Ubuntu install.

That said...
 Can you please help
 I want to.
 1. obtain the ubuntu source code (not the binaries) ..
for each package $PACKAGENAME:

apt-get source $PACKAGENAME

 2. build it myself .. 
cd $PACKAGEDIR;
debuild -us -uc

 3. make an iso image out of it .. 
I don't know this part of our infrastructure.  Someone else may pipe up.

 4. put it on a cd 
With your choice of CD writing software.

 5. boot my system with that cd and install it .
As you would any other Ubuntu CD.

That said, you probably don't actually want to do this.  If you want to
modify a particular piece of software, all you need to do is to get the
source package (apt-get source $PACKAGENAME), make your change, build it
(with debuild or dpkg-buildpackage), then install the package.


signature.asc
Description: This is a digitally signed message part
-- 
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: notify-osd specification: something is missing/changed?

[Christopher James Halse Rogers]

On Thu, 2009-03-19 at 21:03 -0400, Mackenzie Morgan wrote:
 On Thursday 19 March 2009 5:45:17 am Nicolò Chieffo wrote:
  I've seen that in notify-osd source there are some calls that contains
  the name blur. Does it blur for you? Maybe it's a problem of my
  video card...
 
 It can only do the dimming/blurring if you use a compositing window manager 
 like Compiz, or if you turn on compositing in KWin or Metacity.

I suspect that it can only blur while using Compiz (I don't remember
bumping into a blur plugin in kwin's kontrol kentre, and even if kwin
supports blur I'm not sure whether it uses the same X flags that compiz
uses).  This would also require Compiz's blur plugin to (a) be enabled,
and (b) be running on a card with enough features to support it.  There
are 3 blur modes and all but the MipMap one require pixel shaders
IIRC.  Your card may not have these.


signature.asc
Description: This is a digitally signed message part
-- 
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: notify-osd specification: something is missing/changed?

[Christopher James Halse Rogers]

On Fri, 2009-03-20 at 10:07 +0100, Nicolò Chieffo wrote:
 I don't think that compiz is required, because compiz blur plugin
 blurs everything, so it shouldn't be required the blur code in
 notify-osd, but only a composite window manager enabled.
 
 Can you tell me which video card you have and if it works for you
 (without the compiz blur plugin enabled)? Thanks.

From bubble.c:

/* the behind-bubble blur only works with the enabled/working compiz-plugin blur
 * by setting the hint _COMPIZ_WM_WINDOW_BLUR on the bubble-window */

Is this what you're after?  The actual Gaussian blur convolution appears
to only be used to draw the shadow, which seems reasonable to me - my
understanding is that blurring behind the window can only be performed
by the composite manager, since it's the only thing that actually knows
what's behind the window.


signature.asc
Description: This is a digitally signed message part
-- 
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: Reason for removing animation from Gnome login?

[Christopher James Halse Rogers]

On Fri, 2009-03-20 at 22:25 +0100, Ernst Persson wrote:
 Hi,
 
 I saw Scott removing animation from gnome login. What's the reason for
 that? I don't see any motivation or reference to a bugreport.
 It works very nice here and looks nice with all the nvidia drivers,
 nv, nouveau and nvidia.
 

In one of the comparative-startup-time threads it was mentioned that
these effects added ~2sec each to the startup time on someone's (I think
Scott's) system.

It might be good to have that documented somewhere, possibly the
changelog.


signature.asc
Description: This is a digitally signed message part
-- 
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

Dropping off the Internet

[Christopher James Halse Rogers]

Hello all,

I'm moving this weekend, and I'm unsure when my internet connection will
be re-established - it could be up to a month away, apparently.  I'll
probably get intermittent internet access during this time, but I won't
be around dependably and will be unable to do much work.  Please don't
block on me!

I don't think this should disrupt anybody too much: the work for the
mono 2.0 transition and evolution-sharp transition is done, and Iain
Lane (Laney) and Jo Shields (directhex) should be your go-to people for
anything new mono related.  Iain has acquired TIL status on Miro, and
has worked with the Debian maintainer to turn this into a sync.  There
should be a new gnome-do release soon, and this might be worth a FFe as
there are a bunch of bugfixes, performance improvements, and more
fleshed-out features, particularly for the dock interface.  I've sounded
Iain out for this.

The only other thing I touch particularly is the nouveau drivers.  Once
the next libdrm upload goes through, they should be syncable from Debian
experimental, as long as someone updates the nouveau-kernel-source
package.  If I were more confident in my net access, I'd ask for a
standing FFe for xserver-xorg-video-nouveau and nouveau-kernel-source,
but if no one else feels like keeping this up to date it won't be much
of a loss.

Thanks everyone, and I hope to be back online and working soon.


-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Metacity as a compositing manager

[Christopher James Halse Rogers]

On Mon, 2009-02-09 at 14:10 -0500, Danny Piccirillo wrote:
 Would it be a good idea to plan to use Metacity as the default
 compositing manager for Ubuntu instead of compiz in the future? 
 
 Compiz seems mostly unnecessary. If metacity was used, it would be
 easier on the machine and work for people who don't have the hardware
 for compiz. Anyone who wants all the exra effects can still install
 compiz, but for almost everyone, shouldn't metacity be fine? 

There are two problems here: the first is that Metacity's compositor is
_slower_ and more CPU intensive than Compiz for people with decent 3d
drivers (particularly nvidia users - the blob is great at 3d, not so
good at 2d).  For example, the alt-tab provided by Metacity's compositor
is significantly slower than Compiz's, at least for me.

The second is that Metacity's compositor is in no way feature-comparable
with Compiz.  I believe the 'scale' plugin is enabled in our default
compiz setup; this gives exposé-like functionality which is not provided
by Metacity, and is a _huge_ usability win.

The characterisation of Compiz as just about shiny effects is wrong.
The default plugin set also provides a better _window manager_ than
Metacity in many ways.


signature.asc
Description: This is a digitally signed message part
-- 
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