Hi Martin:

On Thu, Nov 5, 2009 at 03:43, Martin Pitt <martin.pitt@ubuntu.com> wrote:

Mario Limonciello [2009-11-04 17:08 -0600]:

> I see three potential improvements to Jockey for this scenario.

>

> * *1. Have Jockey be able to work in an interactive frontend. *If the

> * *package install behavior is modified to query if the headers are yet

> * *available, then you can more nicely present this information to the user



What do you mean by "interactive frontend"? For debconf you mean?

I'm afraid that requires a rewrite of Jockey, since it's currently

frontend <-> dbus <-> backend <-> python-apt, so the backend doesn't

have X access. I'm afraid this isn't SRUable.

As i'm sure you are aware, there are other deficiencies with the way things are done now
1) Not being able to represent whether something failed to install or download

2) Not being able to ask to insert CD media if it's present there

As you said, this doesn't sound SRUable, but for Lucid perhaps the better solution is to use python-aptdaemon.* It can certainly provide more of this information more easily.


--
Mario Limonciello
superm1@gmail.com
Sent from Austin, Texas, United States
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Hi Steve:

On Thu, Nov 5, 2009 at 06:04, Steve Langasek <steve.langasek@ubuntu.com> wrote:



I wonder if a dpkg trigger wouldn't help here for lucid (not for SRU): each

dkms module package registers its interest in an appropriate file pattern,

and at the end of the corresponding dpkg run the trigger fires to try to do

the module compilation? *This would have the advantage that dpkg would then

have information about exactly which dkms packages failed to build, but I

haven't thought this through completely to be sure it's worth doing and

doesn't have any major design pitfalls.


Reading through your idea it tentatively sounds like a good way to help things out.* It doesn't even need to be a pattern though.* The dkms_autoinstaller script is able to query what has and hasn't been built yet, and try to build things.* So if a dpkg trigger is set up to just call it at the end as necessary, that would work too.


Bryce:

Have you assembled a spec for Lucid we can talk about at UDS to try to help clean up these problems?

Thanks,
--
Mario Limonciello
superm1@gmail.com

Sent from Austin, Texas, United States
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

On Thu, Nov 05, 2009 at 07:35:50AM -0600, Mario Limonciello wrote:
> > I wonder if a dpkg trigger wouldn't help here for lucid (not for SRU): each
> > dkms module package registers its interest in an appropriate file pattern,
> > and at the end of the corresponding dpkg run the trigger fires to try to do
> > the module compilation? This would have the advantage that dpkg would then
> > have information about exactly which dkms packages failed to build, but I
> > haven't thought this through completely to be sure it's worth doing and
> > doesn't have any major design pitfalls.

> Reading through your idea it tentatively sounds like a good way to help
> things out. It doesn't even need to be a pattern though. The
> dkms_autoinstaller script is able to query what has and hasn't been built
> yet, and try to build things. So if a dpkg trigger is set up to just call
> it at the end as necessary, that would work too.

It does have to be either a pattern, or an explicit trigger invocation from
the kernel package maintainer script; those are the ways dpkg knows which
triggers need to be called.

http://www.dpkg.org/dpkg/Triggers

And a file pattern would be preferable if it's possible, because that
doesn't require further coordination regarding the contents of the kernel
packages' maintainer scripts.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

On Thu, Nov 05, 2009 at 05:46:47AM -0800, Steve Langasek wrote:
> http://www.dpkg.org/dpkg/Triggers

Hmm, that seems to be a terrible link. Let's try

https://wiki.ubuntu.com/DpkgTriggers

instead.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Le jeudi 05 novembre 2009, Steve Langasek a écrit :
> It does have to be either a pattern, or an explicit trigger invocation from
> the kernel package maintainer script; those are the ways dpkg knows which
> triggers need to be called.
>
> http://www.dpkg.org/dpkg/Triggers

You should not refer to this page as documentation of the dpkg triggers.
The only reliable documentation is the one integrated in dpkg itself.
This blog entry is also interesting:
http://www.seanius.net/blog/2009/09/dpkg-triggers-howto/

Cheers,
--
Raphaël Hertzog -+- http://www.ouaza.com

Freexian : des développeurs Debian au service des entreprises
http://www.freexian.com

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

On Thu, Nov 05, 2009 at 07:29:04AM -0600, Mario Limonciello wrote:
> Hi Bryce:
>
> On Thu, Nov 5, 2009 at 01:44, Bryce Harrington <bryce@canonical.com> wrote:
>
> > Btw, in poking around in dkms.conf I noticed this:
> >
> > PACKAGE_VERSION="185.18.31"
> >
> > Shouldn't that be 185.18.36? Or am I misunderstanding the purpose of
> > this file?
> >
> > If you have encountered a scenario where that doesn't reflect the version
> installed, that's a bug for sure in the nvidia driver package you are
> working with, and I am certain there will be future problems on such a
> system.

No, this was just from the copy in the source package. Sounds like it
gets replaced by the one generated from dkms.conf.in so this dkms.conf
appears to just be a stray.

Thanks,
Bryce

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