Re: I'd like to discuss how difficult it is to add a third party repository

2007-05-26 Thread Ming Hua
On Fri, May 25, 2007 at 03:03:36PM -0700, Scott Ritchie wrote:
 
 But what about the GPG key?  Do they still need to add that with a
 terminal command?

There are GUI tools for manipulating GPG keys for APT as well, the one I
know is gui-apt-key, written in GTK-perl.

Ming
2007.05.26

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


Draining the font swamp (Matt Zimmerman)

2007-05-26 Thread mike corn

What I'm concerned with in this thread is the experience of an average user,
who cares very little about fonts, just wants their applications to
work, and be able to display readable text in their language.  We want to
have the simplest, cleanest infrastructure to provide this.


This is the challenge for any complex application. Provide simple defaults for 
ordinary or casual usage, but allow access to the complexity if wanted. Too few 
developers think about this.




-- 
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: Draft procedure for processing the Universe Sponsor Queue

2007-05-26 Thread Adrien Cunin
Hi,

Le samedi 26 mai 2007 à 09:16 +0900, Emmet Hikory a écrit :
 * Why set In Progress and self-assign when beginning a review
 
 This acts as both a marker that the bug is under review (to
 prevent duplication of work), and sends a stock message to bug
 subscribers, which message is easily translated, does launchpad
 support native-language status messages in the future.  The effort
 involved in marking In Progress and self-assigning is no more than
 that of leaving a comment indicating one is currently reviewing it,
 and does not clutter the comment thread.

You say self-assigning when beginning a review, but I guess the sponsor
will stay assigned once the bug is closed. See below why I don't agree
with that. IMO adding a comment is enough, if you think you will need
some time to review.
So far, when sponsoring, I've self-assigned the bug when it's a bug
requesting sponsoring, for example the merge bugs.
When it's an actual bug that have been picked by a contributor, who
attached a debdiff, I let him assigned. Why? because the real person who
fixed the bug is not me, I just check the sanity of the debdiff and
upload. Letting people assigned to the bugs also makes easier for them
to keep track of what bugs they have been working on (useful for eg.
MOTU application :)). We keep the contributor in the Changed-By field
when uploading, so why not keep him as bug assignee?
Btw, but it's probably off-topic, I wonder why sync requests' Changed-By
field is set to the developer who ACKed the sync, and not to the
contributor who requested it.

 * Why use Fix Committed rather than Fix Released when the upload occurs
 
 When an upload happens, the fix is not actually released, just
 submitted to the archive.  It is the responsibility of the sponsored
 to watch the builds, and if they fail, adjust the package to build or
 request a give-back from the buildd administrators.  Once the package
 is built and released on all architectures, the bug should be marked
 Fix Released.

I agree and would like to add another point: during freeze times (I mean
when the archive is frozen for release, not UVF or FF freeze), an upload
may not be approved before a few hours, so Fix *committed* is
absolutely right here.

 As sponsors will remain the Assignee of the bug, they
 may check up to make sure that those they have sponsored are closing
 their bugs by using their +assignedbugs page.

For that part, as I said above, I would prefer keeping the contributor
as the assignee of the bug, so: if the contributor is someone who have
already been sponsored a few times, he will know that he has to change
the status to Fix released once the package is built; if the
contributor is new to the process, you can just add a note about that in
your comment.

-- 
Adrien Cunin aka Adri2000


signature.asc
Description: Ceci est une partie de message	numériquement signée
-- 
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: [USN-464-1] Linux kernel vulnerabilities

2007-05-26 Thread Thilo Six
Hello

The kernel security update [USN-464-1] is missing s.th.

$ sudo aptitude show linux-generic | grep depend
Depends: linux-image-generic, linux-restricted-modules-generic

$ sudo aptitude show linux-image-generic | grep depen
Depends: linux-image-2.6.20-15-generic
^^

from USN:
Ubuntu 7.04:
  linux-image-2.6.20-16-generic2.6.20-16.28
 ^^

$ sudo aptitude update
$ aptitude dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B of archives. After unpacking 0B will be used.

$ apt-cache policy linux-generic
linux-generic:
  Installed: 2.6.20.15.14
  Candidate: 2.6.20.15.14

$ apt-cache policy linux-image-generic
linux-image-generic:
  Installed: 2.6.20.15.14
  Candidate: 2.6.20.15.14

HTH Thilo
-- 
i am on Ubuntu 2.6 KDE
- some friend of mine

gpg key: 0x4A411E09


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