Fwd: Building newer releases from SVN
Luca Boccassi
luca.boccassi at gmail.com
Sun Jul 24 22:12:45 UTC 2016
On Sun, 2016-07-24 at 23:53 +0200, Andreas Beckmann wrote:
> On 2016-07-24 23:17, Luca Boccassi wrote:
> > I've just tested 367, and after adding conflicts+replaces in
> > libglx0-glvnd-nvidia to libglx0-nvidia the upgrade is clean.
>
> I only cared for renames of packages I had actually uploaded to
> sid/experimental, but I'm not against providing a better upgrade
> experience for users of SVN builds :-) Thanks!
> Maybe we should use versions like 367.xx-1~svnYYYYMMDD in SVN to prevent
> mixing packages from different snapshots. (That would work at least for
> anything with a Depends: nvidia-alternative (= exactversion))
>
> > I've committed it since we have now quite a few users building from SVN
> > and at least one downstream distribution, SteamOS, so this will make
> > life easier for them. SteamOS in particular released the 367.27 drivers
> > from our branch a while ago.
>
> :-)
>
> > Also I've run a few things and all seems fine, both with glvnd's libGL
> > and with Nvidia's.
>
> Does switching work easily enough? Requires swapping packages. I don't
> plan to integrate this in the nvidia-alternative/glx-alternatives
> mechanism as an additional choice dimension (if it can be avoided).
Yes it was just a matter of installing libgl1-glvnd-nvidia-glx, and
everything worked as expected, the i386 package got pulled in
automatically too.
> > Also vulkaninfo output looks good, but I don't own
> > any Vulkan game unfortunately so I cannot do more tests.
>
> Would there be any such game available on steam?
I believe "The Talos Principle" has a Vulkan renderer.
And now that I googled for it, apparently Dota 2 has one too and it's
free, so I'll try and install that in the next few days and give it a
run.
> My next planned steps are:
> * wait for 352.79-10~bpo8+1 to enter backports
> * upload 355/358/361 to sid with 12 hours gaps to allow package autobuilds
> * upload 364/367 to experimental
> (hopefully within July, expecting to have not much time at the beginning
> of August)
Sounds good! Only one note, according to:
http://www.nvidia.com/object/unix.html
361 is already dead (despite the release last month), and 367 is the
long lived and 364 is the short lived branch. Should we try and push 367
too to unstable due to this?
> * backport legacy-304xx/340xx
>
> * continue working on gitification of nvidia-settings-* (66%done)
Nice! At some point I want to resume working on moving n-g-d to git. I
think Alioth supports git-annex, which can handle the big orig tarballs
like git LFS would (only metadata is downloaded on clone, full file only
on checkout of specific ref), so if that can work I think there can be a
usable and sane workflow.
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20160724/56d05ccd/attachment.sig>
More information about the pkg-nvidia-devel
mailing list