Packaging nouveau

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Packaging nouveau

Vincent Bernat-3
Hi!

There is currently an ITP to package nouveau:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418889

However, Matthew seems to not have  time yet to package nouveau. I would
like to help a bit.

nouveau  needs  an up-to-date  mesa  (7.3.0)  that  we already  have  in
Debian. It  also needs an up-to-date  libdrm (current git,  2.3.0 is not
ok) that we don't have in Debian. Moreover, from libdrm, we should build
"nouveau-kernel-source".  And at least,  there is  the driver  part that
should be built and it seems quite easy.

The  hard part is  libdrm. I  have tried  to work  from the  current git
repository on  alioth, but the  modifications done in  debian-* branches
look quite strange to me. If  I look at the diff between debian-unstable
and  upstream-unstable (or -experimental,  they are  almost in  sync), I
discover  that  some  directories  are  removed  (bsd-core,  linux-core,
scripts).  Current  git  of  libdrm  now  uses  symbolic  links  between
shared-core and linux-core.

Because  of  this  combination,  I  have difficulties  to  simply  merge
upstream-experimental   (updated   with   HEAD   from   upstream)   into
debian-experimental.    I    am   not   good   enough    with   git   to
succeed.  Moreover,  when a  file  has been  removed  and  has not  been
changed, it is  removed and I need the content of  linux-core to be able
to build nouveau-kernel-source package. Therefore, I am a bit stuck.

What  is the  proper way  to handle  this with  git? Would  it be  OK to
restore the full content of upstream into libdrm?

Thanks.
--
BOFH excuse #375:
Root name servers corrupted.

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Julien Cristau-6
On Sun, May 11, 2008 at 15:44:08 +0200, Vincent Bernat wrote:

> nouveau  needs  an up-to-date  mesa  (7.3.0)  that  we already  have  in
> Debian. It  also needs an up-to-date  libdrm (current git,  2.3.0 is not
> ok) that we don't have in Debian. Moreover, from libdrm, we should build
> "nouveau-kernel-source".  And at least,  there is  the driver  part that
> should be built and it seems quite easy.

I'm not sure mesa 7.0.3 will be enough.  You might need a snapshot of
master instead.

> The  hard part is  libdrm. I  have tried  to work  from the  current git
> repository on  alioth, but the  modifications done in  debian-* branches
> look quite strange to me. If  I look at the diff between debian-unstable
> and  upstream-unstable (or -experimental,  they are  almost in  sync), I
> discover  that  some  directories  are  removed  (bsd-core,  linux-core,
> scripts).  Current  git  of  libdrm  now  uses  symbolic  links  between
> shared-core and linux-core.

Right, the debian branch of libdrm removes the kernel-side parts (we
don't need them, and they aren't in libdrm tarballs).  If you need them
back in your branch, 'git checkout upstream/master
{bsd,linux,shared}-core' should do what you want (and the same for any
other files you need too).

> Because  of  this  combination,  I  have difficulties  to  simply  merge
> upstream-experimental   (updated   with   HEAD   from   upstream)   into
> debian-experimental.    I    am   not   good   enough    with   git   to
> succeed.  Moreover,  when a  file  has been  removed  and  has not  been
> changed, it is  removed and I need the content of  linux-core to be able
> to build nouveau-kernel-source package. Therefore, I am a bit stuck.
>
Don't do that in the libdrm package.  Call it drm-snapshot or something
similar.  Build the kernel part and the library from that one.
Be careful that the libdrm ABI in master is incompatible with 2.3.0.

Cheers,
Julien


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Vincent Bernat-3
OoO En  ce début d'après-midi ensoleillé  du dimanche 11  mai 2008, vers
15:55, Julien Cristau <[hidden email]> disait:

>> nouveau  needs  an up-to-date  mesa  (7.3.0)  that  we already  have  in
>> Debian. It  also needs an up-to-date  libdrm (current git,  2.3.0 is not
>> ok) that we don't have in Debian. Moreover, from libdrm, we should build
>> "nouveau-kernel-source".  And at least,  there is  the driver  part that
>> should be built and it seems quite easy.

> I'm not sure mesa 7.0.3 will be enough.  You might need a snapshot of
> master instead.

You are right. Current git snapshot need more recent libdrm.
--
BOFH excuse #189:
SCSI's too wide.

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Vincent Bernat-3
OoO Vers la fin de l'après-midi  du dimanche 11 mai 2008, vers 16:42, je
disais:

>>> nouveau  needs  an up-to-date  mesa  (7.3.0)  that  we already  have  in
>>> Debian. It  also needs an up-to-date  libdrm (current git,  2.3.0 is not
>>> ok) that we don't have in Debian. Moreover, from libdrm, we should build
>>> "nouveau-kernel-source".  And at least,  there is  the driver  part that
>>> should be built and it seems quite easy.

>> I'm not sure mesa 7.0.3 will be enough.  You might need a snapshot of
>> master instead.

> You are right. Current git snapshot need more recent libdrm.

To summarize,  to push xserver-xorg-video-nouveau  into experimental, we
need:
 - libdrm git snapshot
 - mesa git snapshot

Moreover, libdrm git snapshot will generate a module source package that
will generate nouveau.ko and drm.ko. The latest one is incompatible with
the one in current Debian kernel (2.6.25) and will override it.

At  least, they  need to  be kept  in  sync as  long as  nouveau is  not
releasing. This seems a bit too much even for experimental. Maybe things
will get settled when a new libdrm will be released.
--
BOFH excuse #151:
Some one needed the powerstrip, so they pulled the switch plug.

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Julien Cristau-6
On Sun, May 11, 2008 at 17:20:56 +0200, Vincent Bernat wrote:

> To summarize,  to push xserver-xorg-video-nouveau  into experimental, we
> need:
>  - libdrm git snapshot

drm. not just libdrm.

>  - mesa git snapshot
>
> Moreover, libdrm git snapshot will generate a module source package that
> will generate nouveau.ko and drm.ko. The latest one is incompatible with
> the one in current Debian kernel (2.6.25) and will override it.
>
> At  least, they  need to  be kept  in  sync as  long as  nouveau is  not
> releasing. This seems a bit too much even for experimental. Maybe things
> will get settled when a new libdrm will be released.

I think it's fine for experimental, as long as the packager is aware
that it'll need quite some work to keep all the bits together, not just
the initial packaging.
I don't expect things to settle down this year, FWIW.

Cheers,
Julien


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Vincent Bernat-3
OoO Lors  de la soirée  naissante du dimanche  11 mai 2008,  vers 17:29,
Julien Cristau <[hidden email]> disait:

> I think it's fine for experimental, as long as the packager is aware
> that it'll need quite some work to keep all the bits together, not just
> the initial packaging.
> I don't expect things to settle down this year, FWIW.

I  have  packaged   drm-snapshot  which  creates  libdrm2,  libdrm2-dev,
libdrm2-dbg  and nouveau-kernel-source.  I am  now looking  at packaging
mesa. Unfortunately, nouveau  development is not done in  7.0 branch, it
is not even  done in the same repository. This  means another new source
package.

Maybe, I should rename binary package  to state that they should be used
only  with   nouveau.   I  mean,   if  someone  installs   libdrm2  from
experimental, it will break every  X video driver, except nouveau. Those
packages will provide, replace and conflict with the original packages.

Thanks.
--
BOFH excuse #44:
bank holiday - system operating credits  not recharged

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Julien Cristau-6
As I said in a previous message, libdrm changed ABI incompatibly between
2.3.0 and current master.  That means you MUST NOT provide libdrm2.

Cheers,
Julien


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Vincent Bernat-3
OoO La  nuit ayant  déjà recouvert  d'encre ce jour  du dimanche  11 mai
2008, vers 23:02, Julien Cristau <[hidden email]> disait:

> As I said in a previous message, libdrm changed ABI incompatibly between
> 2.3.0 and current master.  That means you MUST NOT provide libdrm2.

They did not assign  a new library number yet. I won't  take the risk to
try to guess if it  will be libdrm3 or libdrm2.4. Moreover, nouveau/mesa
repository   don't  compile   (it   seems  to   compile  libGLU   before
libGL). Managing  a different branch of mesa  is far too much  for me. I
think that  I will wait a bit  before trying again, at  least until mesa
related nouveau development join back official mesa repository.
--
 /*
  * Hash table gook..
  */
        2.4.0-test2 /usr/src/linux/fs/buffer.c

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Julien Cristau-6
On Sun, May 11, 2008 at 23:42:23 +0200, Vincent Bernat wrote:

> OoO La  nuit ayant  déjà recouvert  d'encre ce jour  du dimanche  11 mai
> 2008, vers 23:02, Julien Cristau <[hidden email]> disait:
>
> > As I said in a previous message, libdrm changed ABI incompatibly between
> > 2.3.0 and current master.  That means you MUST NOT provide libdrm2.
>
> They did not assign  a new library number yet. I won't  take the risk to
> try to guess if it  will be libdrm3 or libdrm2.4. Moreover, nouveau/mesa
> repository   don't  compile   (it   seems  to   compile  libGLU   before
> libGL). Managing  a different branch of mesa  is far too much  for me. I
> think that  I will wait a bit  before trying again, at  least until mesa
> related nouveau development join back official mesa repository.

I haven't looked at the nouveau repo, but using mesa master you can tell
configure exactly what you want to build (in your case, libGL and the
nouveau dri driver) so that shouldn't be too difficult hopefully.
Although if that's too much of a burden, you probably only need mesa for
3d, and the driver should work just fine for 2d using the drm driver and
the ddx?

Cheers,
Julien


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Vincent Bernat-3
OoO En  cette nuit  nuageuse du  lundi 12 mai  2008, vers  01:51, Julien
Cristau <[hidden email]> disait:

>> They did not assign  a new library number yet. I won't  take the risk to
>> try to guess if it  will be libdrm3 or libdrm2.4. Moreover, nouveau/mesa
>> repository   don't  compile   (it   seems  to   compile  libGLU   before
>> libGL). Managing  a different branch of mesa  is far too much  for me. I
>> think that  I will wait a bit  before trying again, at  least until mesa
>> related nouveau development join back official mesa repository.

> I haven't looked at the nouveau repo, but using mesa master you can tell
> configure exactly what you want to build (in your case, libGL and the
> nouveau dri driver) so that shouldn't be too difficult hopefully.
> Although if that's too much of a burden, you probably only need mesa for
> 3d, and the driver should work just fine for 2d using the drm driver and
> the ddx?

I need  at least the  dri driver. I  will try again  to see what  is the
problem today.
--
panic("IRQ, you lose...");
        2.2.16 /usr/src/linux/arch/mips/sgi/kernel/indy_int.c

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Vincent Bernat-3
In reply to this post by Julien Cristau-6
OoO La  nuit ayant  déjà recouvert  d'encre ce jour  du dimanche  11 mai
2008, vers 23:02, Julien Cristau <[hidden email]> disait:

> As I said in a previous message, libdrm changed ABI incompatibly between
> 2.3.0 and current master.  That means you MUST NOT provide libdrm2.

I  did not  mess with  library  soname, instead  I just  make a  package
libdrm2n instead and I have  modified shlibs to reflect the change. This
means  that I  still  ship  libdrm.2.3.0 (I  replace  and conflict)  but
packages  that build  using this  libdrm  will depends  on libdrm2n  (>>
2.3.0). Is it ok?

On another topic, I am now able  to compile mesa. That was not easy. ;-)
So, I  have a  mesa-nouveau source package  that builds the  same binary
packages    than   mesa    in   unstable.    I   need    to    work   on
xserver-xorg-video-nouveau now. And test the whole thing.

I discovered that xserver-xorg-core is  a reverse depends of libdrm2 and
therefore, I need  to recompile it. I suppose that  (if the packages hit
experimental one day) I will need to upload a binary only package.
--
# Okay, what on Earth is this one supposed to be used for?
        2.4.0 linux/drivers/char/cp437.uni

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Vincent Bernat-3
OoO  Pendant le  temps de  midi du  lundi 12  mai 2008,  vers  12:24, je
disais:

> On another topic, I am now able  to compile mesa. That was not easy. ;-)
> So, I  have a  mesa-nouveau source package  that builds the  same binary
> packages    than   mesa    in   unstable.    I   need    to    work   on
> xserver-xorg-video-nouveau now. And test the whole thing.

Well,  in fact,  I  did not  compile  nouveau_dri.so. It  seems that  my
version of libdrm  is not recent enough (or too  recent). For example, I
have error messages like that:

nouveau_fifo.c: In function 'nouveauFifoInit':
nouveau_fifo.c:101: error: storage size of 'fifo_init' isn't known
nouveau_fifo.c:110: error: 'DRM_NOUVEAU_FIFO_ALLOC' undeclared (first use in this function)

I give up for the moment.
--
 /*
  * We used to try various strange things. Let's not.
  */
        2.2.16 /usr/src/linux/fs/buffer.c

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Michel Dänzer-3
In reply to this post by Vincent Bernat-3
On Sun, 2008-05-11 at 22:57 +0200, Vincent Bernat wrote:

> OoO Lors  de la soirée  naissante du dimanche  11 mai 2008,  vers 17:29,
> Julien Cristau <[hidden email]> disait:
>
> > I think it's fine for experimental, as long as the packager is aware
> > that it'll need quite some work to keep all the bits together, not just
> > the initial packaging.
> > I don't expect things to settle down this year, FWIW.
>
> I  have  packaged   drm-snapshot  which  creates  libdrm2,  libdrm2-dev,
> libdrm2-dbg  and nouveau-kernel-source.

If you're going through the trouble of reviving DRM snapshot packages,
please don't make them nouveau specific. DRM snapshots are useful for
other drivers as well.


> Maybe, I should rename binary package  to state that they should be used
> only  with   nouveau.   I  mean,   if  someone  installs   libdrm2  from
> experimental, it will break every  X video driver, except nouveau.

Why is that?


--
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Vincent Bernat-3
OoO Pendant  le temps de midi du  mardi 13 mai 2008,  vers 12:20, Michel
Dänzer <[hidden email]> disait:

>> > I think it's fine for experimental, as long as the packager is aware
>> > that it'll need quite some work to keep all the bits together, not just
>> > the initial packaging.
>> > I don't expect things to settle down this year, FWIW.
>>
>> I  have  packaged   drm-snapshot  which  creates  libdrm2,  libdrm2-dev,
>> libdrm2-dbg  and nouveau-kernel-source.

> If you're going through the trouble of reviving DRM snapshot packages,
> please don't make them nouveau specific. DRM snapshots are useful for
> other drivers as well.

Hi Michel!

My attempt to  package drm-snapshot is nouveau specific  only for kernel
part. In  fact, it  would be easy  to create  XXXX-drm-kernel-source for
each available drm driver. Would it be worth the effort?

Moreover, I think  that nouveau is just too difficult  for me to package
now. It  seems that I wasn't able  to identify the correct  trees to use
since  my libdrm is  not compatible  with nouveau  dri driver  (which is
really odd). Is it still worth packaging drm snapshot?

I don't feel really motivated  maintaining snapshot of DRM and not using
it. :)

>> Maybe, I should rename binary package  to state that they should be used
>> only  with   nouveau.   I  mean,   if  someone  installs   libdrm2  from
>> experimental, it will break every  X video driver, except nouveau.

> Why is that?

Because ABI incompatibility is not versioned yet. The shipped library is
still  named   "libdrm.2.3.0.so"  while   it  is  not   compatible  with
it. Therefore, this should  break any xserver-xorg-video-*. This is pure
assumption, though.
--
BOFH excuse #39:
terrorist activities

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Michel Dänzer-3
On Tue, 2008-05-13 at 21:42 +0200, Vincent Bernat wrote:

> OoO Pendant  le temps de midi du  mardi 13 mai 2008,  vers 12:20, Michel
> Dänzer <[hidden email]> disait:
>
> >> > I think it's fine for experimental, as long as the packager is aware
> >> > that it'll need quite some work to keep all the bits together, not just
> >> > the initial packaging.
> >> > I don't expect things to settle down this year, FWIW.
> >>
> >> I  have  packaged   drm-snapshot  which  creates  libdrm2,  libdrm2-dev,
> >> libdrm2-dbg  and nouveau-kernel-source.
>
> > If you're going through the trouble of reviving DRM snapshot packages,
> > please don't make them nouveau specific. DRM snapshots are useful for
> > other drivers as well.
>
> Hi Michel!
>
> My attempt to  package drm-snapshot is nouveau specific  only for kernel
> part. In  fact, it  would be easy  to create  XXXX-drm-kernel-source for
> each available drm driver. Would it be worth the effort?

I'd just make it a single package for all drivers.


> Moreover, I think  that nouveau is just too difficult  for me to package
> now. It  seems that I wasn't able  to identify the correct  trees to use
> since  my libdrm is  not compatible  with nouveau  dri driver  (which is
> really odd). Is it still worth packaging drm snapshot?
>
> I don't feel really motivated  maintaining snapshot of DRM and not using
> it. :)

FWIW, it would be useful for

      * Drivers like mach64 or xgi which haven't been merged into the
        kernel yet.
      * Testing TTM/DRI2 functionality with intel drivers, though this
        will probably require at least rebuilding some of the other
        components, possibly from Git snapshots.
      * Generally testing DRM functionality not merged into the kernel
        yet (e.g. vblank-rework, support for newer ATI chips).

Also, building the Mesa Git master branch requires a libdrm snapshot.


> >> Maybe, I should rename binary package  to state that they should be used
> >> only  with   nouveau.   I  mean,   if  someone  installs   libdrm2  from
> >> experimental, it will break every  X video driver, except nouveau.
>
> > Why is that?
>
> Because ABI incompatibility is not versioned yet. The shipped library is
> still  named   "libdrm.2.3.0.so"  while   it  is  not   compatible  with
> it. Therefore, this should  break any xserver-xorg-video-*. This is pure
> assumption, though.

I don't think it should break anything we have packaged. The only
incompatibility I'm aware of is in the TTM related APIs, and I don't
think anything we have can use the version of those in 2.3.0 out of the
box anyway, and they're still in flux, so the soname probably won't
change at least until that settles down.


--
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Packaging nouveau

Vincent Bernat-3
OoO  En cette matinée  pluvieuse du  mercredi 14  mai 2008,  vers 10:40,
Michel Dänzer <[hidden email]> disait:

> FWIW, it would be useful for

>       * Drivers like mach64 or xgi which haven't been merged into the
>         kernel yet.
>       * Testing TTM/DRI2 functionality with intel drivers, though this
>         will probably require at least rebuilding some of the other
>         components, possibly from Git snapshots.
>       * Generally testing DRM functionality not merged into the kernel
>         yet (e.g. vblank-rework, support for newer ATI chips).

I can still  push what I have done in  pkg-xorg git repository. However,
since  I won't  use any  bit of  it,  it would  be difficult  for me  to
maintain (unless I succeed in running nouveau driver).

I can also  transform nouveau-kernel-module into drm-kernel-module. It's
easy.
--
panic("CPU too expensive - making holiday in the ANDES!");
        2.2.16 /usr/src/linux/arch/mips/kernel/traps.c

attachment0 (194 bytes) Download Attachment