Bug#1077043: ITP: python-aiohttp-fast-zlib -- Accelerates aiohttp by replacing zlib with faster alternatives (isal or zlib-ng), improving performance, especially for websocket connections.

[Josh Santos]

Package: wnpp
Severity: wishlist
Owner: Josh Santos 
X-Debbugs-Cc: debian-devel@lists.debian.org, josh@santos.cloud

* Package name: python-aiohttp-fast-zlib
  Version : 0.1.1
  Upstream Contact: J. Nick Koston 
* URL : https://github.com/bdraco/aiohttp-fast-zlib
* License : Apache-2.0
  Programming Lang: Python
  Description : Replaces usage of zlib in aiohttp with a faster drop-in 
replacement. 

  zlib is a bottleneck for aiohttp, especially for websocket connections. 
aiohttp-fast-zlib replaces usage of zlib in aiohttp with isal or zlib-ng which 
are drop-in faster replacements in most cases.

This library is a dependancy of Home Assistant, the Python smart home platform.
The Debian Python team intends to maintain this.

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

[Simon Richter]

Hi,


More metapackages will make transitions harder though, I believe we want
to avoid that.



In what way would transitions become harder?


The alternatives system has "manual" and "automatic" modes for each 
group, these would probably correspond to "manually installed" and 
"automatically installed".


The latter can only happen if there is also a "defaults" package that 
pulls in the metapackage we currently designate as default, and the 
"defaults" package must allow the dependency to be fulfilled by any of 
the choices. APT will prefer not to uninstall packages if it doesn't 
have to.


As a result, any user will stick to whatever was default when they 
installed the package, even if they have not explicitly expressed a 
preference, until that option is no longer available -- the same happens 
with the alternatives system only in manual mode, which is an explicit 
choice -- and when it happens, the alternatives system will explicitly 
tell the user that their choice is no longer available and the setting 
has reverted to automatic mode.


The only way to speed up a transition is to add an explicit hard 
dependency somewhere and override the user's choice -- which then adds 
an installation ordering constraint that might be the exact opposite of 
the order we want.


   Simon

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

[Luca Boccassi]

On Thu, 28 Dec 2023 at 03:01, Simon Richter  wrote:
>
> Hi,
>
> On 12/28/23 04:28, Luca Boccassi wrote:
>
> > if you want to activate a new alternative, you have to download a new
> > package that provides it anyway, so there's no difference. Subsequent
> > switches will use the cached package, and if you have issues
> > downloading a 3 kilobytes metapackage then just ensure the cache is
> > never cleared.
>
> More metapackages will make transitions harder though, I believe we want
> to avoid that.

In what way would transitions become harder?

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

[Simon Richter]

Hi,

On 12/28/23 04:28, Luca Boccassi wrote:


if you want to activate a new alternative, you have to download a new
package that provides it anyway, so there's no difference. Subsequent
switches will use the cached package, and if you have issues
downloading a 3 kilobytes metapackage then just ensure the cache is
never cleared.


More metapackages will make transitions harder though, I believe we want 
to avoid that.


   Simon

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

[Hakan Bayındır]

Metapackage approach is not the same for many reasons. 

First, I have seen Debian installations which doesn’t have internet access, but 
setup with many alternatives of the same application (e.g.: Java). 

Moreover, apt automatically purges its cache after a successful transaction.

As I said in my previous message, many things from browsers to pagers are 
configured over alternatives subsystem, and this will create tons of headache 
over many edge cases. 

Lastly, a user may have sudo privileges for update-alternatives, to switch 
stuff around if things prove to be problematic (e.g.: again Java, compilers, 
etc.) without having package management privileges (e.g.: remotely managed 
developer workstation).

Alternatives work fine as-is. Fiddling with it only open more can of worms down 
the line. It’s there for a reason to begin with. 

Cheers,

H.
Sent from my iPhone

> On 27 Dec 2023, at 22:29, Luca Boccassi  wrote:
> 
> On Sun, 24 Dec 2023 at 22:48, Stephan Seitz  
> wrote:
>> 
>> Am So, Dez 24, 2023 at 10:06:09 +0100 schrieb Gioele Barabucci:
>>> After the installation there would be no /usr/bin/gpg. Once the user
>>> installs, say, ggp-is-gnupg then /usr/bin/gpg will point to
>>> /usr/bin/gpg-gnupg. Users (and scripts) are still free to install the
>> 
>> And if you want to change it, you have to download and install a new
>> package (and remove another) instead of using a local command
>> (update-alternatives) that doesn’t need an internet connection?
> 
> if you want to activate a new alternative, you have to download a new
> package that provides it anyway, so there's no difference. Subsequent
> switches will use the cached package, and if you have issues
> downloading a 3 kilobytes metapackage then just ensure the cache is
> never cleared.
> 

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

[Luca Boccassi]

On Sun, 24 Dec 2023 at 22:48, Stephan Seitz  wrote:
>
> Am So, Dez 24, 2023 at 10:06:09 +0100 schrieb Gioele Barabucci:
> >After the installation there would be no /usr/bin/gpg. Once the user
> >installs, say, ggp-is-gnupg then /usr/bin/gpg will point to
> >/usr/bin/gpg-gnupg. Users (and scripts) are still free to install the
>
> And if you want to change it, you have to download and install a new
> package (and remove another) instead of using a local command
> (update-alternatives) that doesn’t need an internet connection?

if you want to activate a new alternative, you have to download a new
package that provides it anyway, so there's no difference. Subsequent
switches will use the cached package, and if you have issues
downloading a 3 kilobytes metapackage then just ensure the cache is
never cleared.

Re: Deprecation of /etc/alternatives?

[Teemu Likonen]

* 2023-12-25 13:26:40+0100, ans...@43-1.org wrote:

> On Mon, 2023-12-25 at 09:29 +0200, Teemu Likonen wrote:
>> I hope not. For example, as a user it is nice to execute a single
>> command (update-alternatives) to get a high priority alternative for
>> "editor". I use my locally built /usr/local/bin/emacs as the editor.

> Users should just set the VISUAL environment variable.

I mean as a user (not developer) of Debian.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: Deprecation of /etc/alternatives?

[Ansgar]

On Mon, 2023-12-25 at 09:29 +0200, Teemu Likonen wrote:
> * 2023-12-23 15:34:49+0100, Gioele Barabucci wrote:
> > While we are on the topic of alternatives, I hope to see the
> > maintscript-based /etc/alternatives paradigm deprecated in favor of
> > the package-based X-is-X paradigm introduced by `python-is-
> > python3`.
> 
> I hope not. For example, as a user it is nice to execute a single
> command (update-alternatives) to get a high priority alternative for
> "editor". I use my locally built /usr/local/bin/emacs as the editor.
> 
>     /etc/alternatives/editor -> /usr/local/bin/emacs

Users should just set the VISUAL environment variable.

Alternatives are the wrong tool to set user preferences as they can
only be set globally and only by root.

(editor-is-emacs has the same problem of course...)

Ansgar

Re: Deprecation of /etc/alternatives?

[Teemu Likonen]

* 2023-12-23 15:34:49+0100, Gioele Barabucci wrote:

> While we are on the topic of alternatives, I hope to see the
> maintscript-based /etc/alternatives paradigm deprecated in favor of
> the package-based X-is-X paradigm introduced by `python-is-python3`.

I hope not. For example, as a user it is nice to execute a single
command (update-alternatives) to get a high priority alternative for
"editor". I use my locally built /usr/local/bin/emacs as the editor.

    /etc/alternatives/editor -> /usr/local/bin/emacs

Building custom deb packages, so that they play nicely together with
official packages, is more difficult for users. "update-alternatives" is
just one command.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

[Hakan Bayındır]

However, shoehorning X-is-X to apt for replacing alternatives is a very 
unoptimal (and even backwards) approach, because it’s not only for simple 
applications. Some of the daily alternatives I see are:

- x-www-Browser
- java (and the whole toolchain)
- editor
- vi
- pager
… The list goes on and on.

Alternatives provides a very elegant and usable way for handling multiple 
installed applications. Yet it adds a bit of packaging overhead, but it’s not 
that complicated, and is one of the neat parts of Debian.

I think it’s fine as-is, and it’s an essential part of machinery for Debian. If 
there are some shortcomings, which I failed to bump into while working with it, 
it can be improved, but I’m very against of its removal.

Cheers, 

Hakan

> On 24 Dec 2023, at 12:06, Gioele Barabucci  wrote:
> 
> On 24/12/23 08:54, Alastair McKinstry wrote:
>>> While we are on the topic of alternatives, I hope to see the 
>>> maintscript-based /etc/alternatives paradigm deprecated in favor of the 
>>> package-based X-is-X paradigm introduced by `python-is-python3`.
>>> 
>> They have different use-cases.  alternatives allows for co-installability 
>> (and importantly - co-"buildability" with dependencies). the X-is-X 
>> guarantees essentially the opposite.
> 
> I don't see X-is-X as a different use case when it comes to applications: 
> both gnupg and sq-chameleon-gnupg could be installed at the same time.
> 
> After the installation there would be no /usr/bin/gpg. Once the user 
> installs, say, ggp-is-gnupg then /usr/bin/gpg will point to 
> /usr/bin/gpg-gnupg. Users (and scripts) are still free to install the other 
> package and use /usr/bin/gpg-sq. The only Conflicts: here would be between 
> gpg-is-gnupg and gpg-is-sq-chameleon.
> 
> Regards,
> 
> -- 
> Gioele Barabucci
> 

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

[Stephan Seitz]

Am So, Dez 24, 2023 at 10:06:09 +0100 schrieb Gioele Barabucci:
After the installation there would be no /usr/bin/gpg. Once the user 
installs, say, ggp-is-gnupg then /usr/bin/gpg will point to 
/usr/bin/gpg-gnupg. Users (and scripts) are still free to install the 


And if you want to change it, you have to download and install a new 
package (and remove another) instead of using a local command 
(update-alternatives) that doesn’t need an internet connection?


Sorry, this is bullshit. -100.

Stephan

--
|If your life was a horse, you'd have to shoot it.|

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

[Gioele Barabucci]

On 24/12/23 08:54, Alastair McKinstry wrote:
While we are on the topic of alternatives, I hope to see the 
maintscript-based /etc/alternatives paradigm deprecated in favor of 
the package-based X-is-X paradigm introduced by `python-is-python3`.


They have different use-cases.  alternatives allows for 
co-installability (and importantly - co-"buildability" with 
dependencies). the X-is-X guarantees essentially the opposite.


I don't see X-is-X as a different use case when it comes to 
applications: both gnupg and sq-chameleon-gnupg could be installed at 
the same time.


After the installation there would be no /usr/bin/gpg. Once the user 
installs, say, ggp-is-gnupg then /usr/bin/gpg will point to 
/usr/bin/gpg-gnupg. Users (and scripts) are still free to install the 
other package and use /usr/bin/gpg-sq. The only Conflicts: here would be 
between gpg-is-gnupg and gpg-is-sq-chameleon.


Regards,

--
Gioele Barabucci

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

[Alastair McKinstry]

On 23/12/2023 14:34, Gioele Barabucci wrote:

On 22/12/23 00:40, Daniel Kahn Gillmor wrote:

If you're asking about using /etc/alternatives or something like that to
provide some sort of generic swapping capability, or a dpkg Provides:,
such that /usr/bin/gpg on some systems would point toward the
"chameleon", i would want to see some significant archive-wide testing
done before we even consider inflicting that on our normal users.


While we are on the topic of alternatives, I hope to see the 
maintscript-based /etc/alternatives paradigm deprecated in favor of 
the package-based X-is-X paradigm introduced by `python-is-python3`.


They have different use-cases.  alternatives allows for 
co-installability (and importantly - co-"buildability" with 
dependencies). the X-is-X guarantees essentially the opposite.


This becomes key if we have two different approaches desired or needed 
simultaneously: eg the adios parallel I/O library builds for both 
openmpi and mpich variants of MPI; different variants preferred for 
different architectures.


Regards

Alastair McKinstry




--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

[Luca Boccassi]

On Sat, 23 Dec 2023 at 18:43, Gioele Barabucci  wrote:
>
> On 22/12/23 00:40, Daniel Kahn Gillmor wrote:
> > If you're asking about using /etc/alternatives or something like that to
> > provide some sort of generic swapping capability, or a dpkg Provides:,
> > such that /usr/bin/gpg on some systems would point toward the
> > "chameleon", i would want to see some significant archive-wide testing
> > done before we even consider inflicting that on our normal users.
>
> While we are on the topic of alternatives, I hope to see the
> maintscript-based /etc/alternatives paradigm deprecated in favor of the
> package-based X-is-X paradigm introduced by `python-is-python3`.
>
> In this scenario gnupg will ship gpg as /usr/bin/gpg-gnupg, while
> sequoia-chameleon-gnupg will ship its gpg as /usr/bin/gpg-sq. Then the
> user can decide to install gpg-is-gnupg or gpg-is-sequoia (with the
> distro-wide preference expressed setting the appropriate Recommends in
> gnupg or sequoia-chameleon-gnupg).
>
> Regards,

Yes, that would be very nice, all those moving parts make the
installation/upgrade processes so unnecessarily difficult and error
prone. It's a maintenance nightmare that I'd be very happy to stop
having to deal with anymore.

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

[Joerg Jaspert]

On 17086 March 1977, Gioele Barabucci wrote:

While we are on the topic of alternatives, I hope to see the 
maintscript-based /etc/alternatives paradigm deprecated in favor of 
the 
package-based X-is-X paradigm introduced by `python-is-python3`.


In this scenario gnupg will ship gpg as /usr/bin/gpg-gnupg, while 
sequoia-chameleon-gnupg will ship its gpg as /usr/bin/gpg-sq. Then the 
user can decide to install gpg-is-gnupg or gpg-is-sequoia (with the 
distro-wide preference expressed setting the appropriate Recommends in 
gnupg or sequoia-chameleon-gnupg).


Ugh no, and have tons of near-empty packages for no good reason and also 
make local admins life harder.


--
bye, Joerg

Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

[Gioele Barabucci]

On 22/12/23 00:40, Daniel Kahn Gillmor wrote:

If you're asking about using /etc/alternatives or something like that to
provide some sort of generic swapping capability, or a dpkg Provides:,
such that /usr/bin/gpg on some systems would point toward the
"chameleon", i would want to see some significant archive-wide testing
done before we even consider inflicting that on our normal users.


While we are on the topic of alternatives, I hope to see the 
maintscript-based /etc/alternatives paradigm deprecated in favor of the 
package-based X-is-X paradigm introduced by `python-is-python3`.


In this scenario gnupg will ship gpg as /usr/bin/gpg-gnupg, while 
sequoia-chameleon-gnupg will ship its gpg as /usr/bin/gpg-sq. Then the 
user can decide to install gpg-is-gnupg or gpg-is-sequoia (with the 
distro-wide preference expressed setting the appropriate Recommends in 
gnupg or sequoia-chameleon-gnupg).


Regards,

--
Gioele Barabucci

Accepted glx-alternatives 1.2.2 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 05 Jan 2023 00:30:08 +0100
Source: glx-alternatives
Architecture: source
Version: 1.2.2
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers 
Changed-By: Andreas Beckmann 
Changes:
 glx-alternatives (1.2.2) unstable; urgency=medium
 .
   * Add salsa-ci.yml.
   * Collect more information for bug reports.
   * Bump Standards-Version to 4.6.2. No changes needed.
Checksums-Sha1:
 6ae69b3b5bcd5eaf1b5a30d908307d3f01524f4f 2048 glx-alternatives_1.2.2.dsc
 bbef9bb8e254859d4e277049f99badc402b45e2e 14340 glx-alternatives_1.2.2.tar.xz
 c692b97ae39ba749744ff4e87e7aacd0134c00c6 5655 
glx-alternatives_1.2.2_source.buildinfo
Checksums-Sha256:
 7861e50b7e690970aef8d042800b0fc08895745e6ab89aafa2a423b46fd7cfc4 2048 
glx-alternatives_1.2.2.dsc
 7cfd4e852fe1b98eef8b2eed4504c127788b9e0b6bd7f3311541989c7f3ce1d2 14340 
glx-alternatives_1.2.2.tar.xz
 4dbae01f632e62990b02378804b7f9cc08e5b0c318e55e1a36b2ef83f012ee7f 5655 
glx-alternatives_1.2.2_source.buildinfo
Files:
 2e54644652bfb87a32cc746ba5d554e9 2048 contrib/libs optional 
glx-alternatives_1.2.2.dsc
 2f9f2176cfde8cc656de4875edff513a 14340 contrib/libs optional 
glx-alternatives_1.2.2.tar.xz
 76f8c112a09fa0b5ad0bda255589fa65 5655 contrib/libs optional 
glx-alternatives_1.2.2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAmO2DHgQHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCMAPD/9VxH58SIWCJJn2zjJTAF7MDTjggOLSXGIx
dBkeJgWMqQ60DQ92nyQd3GVqkgWOaYOW4AYDOCtbXcBykGvLLLAuUmB4z1LcQB1x
ixDq0SdxIEJiQzI625o3Y0mRM9HCtDB/5CeMrDi1UMiCDXQ6L8y4z6NKzUbaqyxa
3tJnrxP5u062USZFvvRkSPciM9JwL2biBCm5wN45BJmZoMqB/8J9vfv/HPs+p/z4
AUssx1L8WI7l7uAojmJOd1kVy2KqNPndMJVU699IFLE5TZmras5cYDbyC3MLdEz4
ZrthvsAtspu2mpRiTNKlR9aH8YwWMaaIorGbdEE0tq40mWPtY0PVROx6s7eBaoCF
lVn6XcbdDCJMY9TIhC1lsR9iFhleMxoOvFFXRMdKGuRJx1jnMWeOpUhlUmQl8X1u
qhPqS3M4y2vH3dG3pHR59Hbhfj1CMyDCox68UnpJ9ZMw6VloMZK7auO791pjMVgQ
ReRbY6HQYwWcyyvaVmD6sfk40W1Kyhx/MGwcekXl9yYRYRkPWqLYapz3nODU+xBD
Nj7/FmkBuvNW4Tte6YbpID0hw01do2uAPuaaXKteUKBciEv0Z3Xc9GTRGP9e1zFz
0bhnSsNMMyqzLIr800gV829fXEoMDSen8ACb7Wcun/7d/2MKa8/v5Rcnd3IoR9v4
3140mHayOg==
=xHIN
-END PGP SIGNATURE-

Accepted puppet-module-voxpupuli-alternatives 3.0.0-5 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 05 Jan 2022 11:14:46 +0100
Source: puppet-module-voxpupuli-alternatives
Architecture: source
Version: 3.0.0-5
Distribution: unstable
Urgency: medium
Maintainer: Debian OpenStack 
Changed-By: Thomas Goirand 
Changes:
 puppet-module-voxpupuli-alternatives (3.0.0-5) unstable; urgency=medium
 .
   * Clean-up update-alternatives handling.
Checksums-Sha1:
 036ab91865344289dcfbb5bfa0881dfe574ac7c2 2303 
puppet-module-voxpupuli-alternatives_3.0.0-5.dsc
 1903c618bd4f76706067dbbf25680d42973ef13b 2120 
puppet-module-voxpupuli-alternatives_3.0.0-5.debian.tar.xz
 6981b85b0ca435175b0c847f0676c41946c3c325 7152 
puppet-module-voxpupuli-alternatives_3.0.0-5_amd64.buildinfo
Checksums-Sha256:
 790950e7e22eff5a2bdd6ba38b03150b5706ca154007c1feb4a6e21c516c2fdf 2303 
puppet-module-voxpupuli-alternatives_3.0.0-5.dsc
 830080ec0932e8904b115083f4d1e6e8bfe1fa1d329e517659ee5389a1a63c72 2120 
puppet-module-voxpupuli-alternatives_3.0.0-5.debian.tar.xz
 778bd4836c45e4794018276bc7d2f4185798ccbf6f7fd97b7b598ace9d07c2d7 7152 
puppet-module-voxpupuli-alternatives_3.0.0-5_amd64.buildinfo
Files:
 07b650457b7aa7588edeeafa18f54745 2303 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-5.dsc
 b9b32228d9b2fcea541d424c0b7256ea 2120 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-5.debian.tar.xz
 90b88213176cc27a2593c81fc20de1fd 7152 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-5_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEoLGp81CJVhMOekJc1BatFaxrQ/4FAmHVb80ACgkQ1BatFaxr
Q/5nbg//RwZxXlmoGWfI+9hqELm5ZqTEmsv92EBSjBCnjMNpPyCQ55qOr53f/73j
c2RhOI7XJd32/w6VwR+xOhjjuUM1Wlv40AUPy69bBjGUsetLOP6wCDjxZRv7K3MS
fDsAt2SjUvCz+v6lduW7Lo7EriubIhaCzObO2NEEUu6WK7FfnreR1QInW1ddsjaO
Eq7N3+y1DLQBashVttNt/kBN9+aexUsmLmo6nJ3+KujA/l5rRQLjfgZcuZqchkyg
FSmhjbK5GgzVMrjKwS2RROOyD7WiOiIc3jHgzHtRzIw7UiEIV31j9Mh32RudqDRz
zIz6ttoRt2UPJ26F/0iMMfJ8Nvt02FEJW06eQSppLT8UfBylGXUhOygLcaSgtjyS
+Y88lY55ii4OwJD5JJ3l2ist7cFZVfDuwsZW7KUPRFc94lCwleSkIXLRG1LYavNt
YwZ0wph5dXewDYylVIA+kaR4vl2i8dbQGQvPCw3N8gH8q5JDBx/6AQaVD36aU8Hy
2o1LnfiQr4pYFKELYh8RPfRXSoI2ipLQuXOnFrn8DBB4CStft+np6U1Gko24GGwB
qCP6bTHPZG8hBytXWO55AGutD4NCPc8e54xM9LNj8ZBIuesQClN5dHOxedQIm8WF
SBKdMHKEpq+RGluL2ixSR0TWE6qpCZZ70fp94HzPjPLDx3UjZ+I=
=2kBo
-END PGP SIGNATURE-

Accepted glx-alternatives 1.2.1 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 01 Oct 2021 23:06:54 +0200
Source: glx-alternatives
Architecture: source
Version: 1.2.1
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers 
Changed-By: Andreas Beckmann 
Closes: 993338
Changes:
 glx-alternatives (1.2.1) unstable; urgency=medium
 .
   * glx-diversions: After initial setup of the diversions, install a minimal
 alternative to the diverted files s.t. libGL.so.1 etc. are not missing
 until glx-alternative-mesa processes its triggers.  (Closes: #993338)
   * Bump Standards-Version to 4.6.0. No changes needed.
Checksums-Sha1:
 7648bee21ea3e089f4c6309564091aa24387a9be 2048 glx-alternatives_1.2.1.dsc
 321e853b2a0e6a876b11780660b94620816cdcd1 14092 glx-alternatives_1.2.1.tar.xz
 f850e5ae26db295ee0a79a072be5ec3e6a4e03fd 5559 
glx-alternatives_1.2.1_source.buildinfo
Checksums-Sha256:
 1f0e3db3d8d14dbc6d2ad0e50721087af63ed89a8d084fe48e89d58150a901c4 2048 
glx-alternatives_1.2.1.dsc
 1e4068629fce14e9414f52b9057be5adbe5d5012dfff228bc8c6cdf12df4848d 14092 
glx-alternatives_1.2.1.tar.xz
 3a8043d9e3c3cd8db67c4312aa7823ccb701f35140adcf34df432d089ad6dd22 5559 
glx-alternatives_1.2.1_source.buildinfo
Files:
 14d29d4b0ef0acd5aa7010b1eae69734 2048 contrib/libs optional 
glx-alternatives_1.2.1.dsc
 b2f4b6c9abc32d5d01a88a2427d06f98 14092 contrib/libs optional 
glx-alternatives_1.2.1.tar.xz
 bf1a25be6b35ec39684097ccc4dd4260 5559 contrib/libs optional 
glx-alternatives_1.2.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAmFXe40QHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCKh+D/0T8oV0KsKGwjoRMEGea4WeGD6O+Z1NMbnc
FRytO4GQ2en1s1bon4mHl2meUXfaa9oOa2k6/+it95QiukGbpApMfl4W/bWf/p/1
sVcC3Zgn+c+mGvQE+E3xz8OoMtBtlXy9bZe21k7LajDUKd2213fOp2SNuU56gEcb
TrxZim/pYcMnzMPaF2Jct7em5fRWppw9dLimhKXkEQOBdZc24Jr0cUqDRY5lS9AR
IHrMW8bsGz4+CSW/JIU1UMWZHp3B/iaM+nfRDsE9Zg1yzlEsGs6NHJ2ikdbb+xBN
uNXKDNtk+vyfn9aomoqF3SBxLMX1Q0BMLlOahauKJhKLxwBj5dKi+8NehMxwVX9e
BrYgKhqwCNtN6OJI1CT0kJeE+iH1gDoQm6MDgR15IgtZLNl2mY5YoLxoS+/LRFac
BjM6JMENFUSGHD/eGIKJzIXhtSk6drj4X4aeqzRnl1CX8BCVvCI+tZuMqskOa+3K
tu4qA0miL21oxxF/1H1zgaKtDJA5GXo80vMyImVRjxLf4AdV4mK2SS6wpwzoOV5D
Sy9aIaVBZ2GI0kQRjKGhgAWGorpb0S2ut1imdWrjddXAUZLMC+VPloAn9DzkBwA8
S2xfW3kYQaN6P2NKnGEDO03WDCCJgQevrSxeMF32XGUxp0opd5dOkAH6p6RWb/tx
vmFbO1arZA==
=gPx+
-END PGP SIGNATURE-

Re: /usr/bin/open now in use through the alternatives system.

[Stig Sandbeck Mathisen]

Josh Triplett  writes:

> Ignoring the server-provided MIME type and doing content-sniffing is a
> historical bug that browsers such as IE have had, and that has caused
> *many* problems (including security problems).
> [...]

Lots of good points.

I had thankfully forgotten about how IE had its own rules about how to
display things it downloaded, but of course it would still be relevant.
(https://web.archive.org/web/20110930155122/http://msdn.microsoft.com/en-us/library/ms775147.aspx)

-- 
Stig Sandbeck Mathisen
Debian Developer

Re: /usr/bin/open now in use through the alternatives system.

[Holger Levsen]

On Mon, Dec 28, 2020 at 01:22:16AM +, Holger Levsen wrote:
> I agree, an "open" program should ask to the server what the media type of the
> URL is, and pass it to the default program able to handle it.

I also wish it were that simple.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

In Europe there are people prosecuted by courts because they saved other people
from drowning in the  Mediterranean Sea.  That is almost as absurd  as if there
were people being prosecuted because they save humans from drowning in the sea.


signature.asc
Description: PGP signature

Re: /usr/bin/open now in use through the alternatives system.

[Josh Triplett]

Stig Sandbeck Mathisen wrote:
>>> Le Sat, Oct 10, 2020 at 04:27:17AM +0900, Charles Plessy a écrit :
 Since `eog http://example.com/image.png` will open the image,
 shouldn't an "open" program ask to the server what the media type
 of the URL is, and pass it to the default program able to handle
 it, instead of just visualising in the browser ?
>
> I would much rather trust the local "file" command and magic database
> instead. The remote server will most likely return a proper content
> type, but trusting remote servers to influence which command to open the
> file locally will have an impact on security.

Ignoring the server-provided MIME type and doing content-sniffing is a
historical bug that browsers such as IE have had, and that has caused
*many* problems (including security problems).

For instance, some sites may restrict the types of files allowed for
upload, and then serve those files with appropriate MIME types saying
how they should be interpreted. Content-sniffing leaves users vulnerable
to attacks like "This looks enough like a PNG to fool the site's PNG
validation, but if you ignore the PNG MIME type you can subsequently
interpret it as a different file type"; that can lead to security
issues.

It'd be reasonable to have an *option* to say "ignore MIME type, sniff
locally instead" (together with some mechanisms to ensure that such
sniffing will never run untrusted code), to help with broken sites that
serve everything as text/plain or application/octet-stream. But I don't
think that option should be the default.

Now, all that said, we'd need more than just a MIME type to figure out a
local program capable of opening an URL; we'd need a MIME type and the
knowledge that a program can (and should) accept a remote URL.

Re: /usr/bin/open now in use through the alternatives system.

[Stig Sandbeck Mathisen]

Charles Plessy  writes:

> I went ahead and uploaded to Sid mime-support version 3.68, which
> provides /usr/bin/open as a symbolic link to /usr/bin/run-mailcap
> using the alternatives system, at a priority of 30. I welcome other
> alternatives.

This is good news. Thank you. :)

I've used "open" as an alias for "xdg-open" for a long time. This
command would probably also be appropriate as an alternative for "open".

> At the moment the manual page of open is simply the one of
> run-mailcap, but I plan to provide a specific one. Given the lack of
> answer to my previous email (quoted below), I have not implemented URL
> support in /usr/bin/run-mailcap.
>
>> Le Sat, Oct 10, 2020 at 04:27:17AM +0900, Charles Plessy a écrit :
>> >
>> > May I ask you for extra information on how important is it to
>> > support URLs, and if anything beyond file:/, http:// and https://
>> > would need to be supported ?
>> ...
>> > Also, can you give me a pointer to an explanation of what file:/
>> > URLs are useful for ? I read RFC 8089, but still did not get the
>> > point.

When handling various methods for fetching content, being explicit about
the scheme ("This is a file") is more robust than being implicit ("As a
last resort, this will be regarded as a file"). Using "file" a default
scheme makes sense if nothing else is specified.

File URIs may be returned by other applications. When using "tracker
search" to search the content of my local files, all results are
returned with "file:///" URIs. Being able to pipe that output to "open"
would be awesome.

>> > Since `eog http://example.com/image.png` will open the image,
>> > shouldn't an "open" program ask to the server what the media type
>> > of the URL is, and pass it to the default program able to handle
>> > it, instead of just visualising in the browser ?

I would much rather trust the local "file" command and magic database
instead. The remote server will most likely return a proper content
type, but trusting remote servers to influence which command to open the
file locally will have an impact on security.

-- 
Stig Sandbeck Mathisen
Debian Developer

Re: /usr/bin/open now in use through the alternatives system.

[Holger Levsen]

Dear Charles,

thanks for driving this.

On Mon, Dec 28, 2020 at 08:15:45AM +0900, Charles Plessy wrote:
> I went ahead and uploaded to Sid mime-support version 3.68, which
> provides /usr/bin/open as a symbolic link to /usr/bin/run-mailcap using
> the alternatives system, at a priority of 30.  I welcome other
> alternatives.

yay!

> I also changed the behaviour of run-mailcap so that, when run as `open`,
> it will not replace the file with a temporary copy when its name needs
> to be escaped.  As a consequence, there is no redundancy between the
> `see` and `open` commands.

yay!

> At the moment the manual page of open is simply the one of run-mailcap,
> but I plan to provide a specific one.  Given the lack of answer to my
> previous email (quoted below), I have not implemented URL support in
> /usr/bin/run-mailcap.

yay!

> > Le Sat, Oct 10, 2020 at 04:27:17AM +0900, Charles Plessy a écrit :
> > > 
> > > May I ask you for extra information on how important is it to support
> > > URLs, and if anything beyond file:/, http:// and https:// would need
> > > to be supported ?
> > ...
> > > Also, can you give me a pointer to an explanation of what file:/ URLs
> > > are useful for ?  I read RFC 8089, but still did not get the point.
> > ...
> > > Since `eog http://example.com/image.png` will open the image,
> > > shouldn't an "open" program ask to the server what the media type of
> > > the URL is, and pass it to the default program able to handle it,
> > > instead of just visualising in the browser ?

I agree, an "open" program should ask to the server what the media type of the
URL is, and pass it to the default program able to handle it.
 
Thanks, again!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

There are no jobs on a dead planet.


signature.asc
Description: PGP signature

/usr/bin/open now in use through the alternatives system.

[Charles Plessy]

[Please CC me, I am not subscribed]

Dear all,

I went ahead and uploaded to Sid mime-support version 3.68, which
provides /usr/bin/open as a symbolic link to /usr/bin/run-mailcap using
the alternatives system, at a priority of 30.  I welcome other
alternatives.

I also changed the behaviour of run-mailcap so that, when run as `open`,
it will not replace the file with a temporary copy when its name needs
to be escaped.  As a consequence, there is no redundancy between the
`see` and `open` commands.

At the moment the manual page of open is simply the one of run-mailcap,
but I plan to provide a specific one.  Given the lack of answer to my
previous email (quoted below), I have not implemented URL support in
/usr/bin/run-mailcap.

> Le Sat, Oct 10, 2020 at 04:27:17AM +0900, Charles Plessy a écrit :
> > 
> > May I ask you for extra information on how important is it to support
> > URLs, and if anything beyond file:/, http:// and https:// would need
> > to be supported ?
> ...
> > Also, can you give me a pointer to an explanation of what file:/ URLs
> > are useful for ?  I read RFC 8089, but still did not get the point.
> ...
> > Since `eog http://example.com/image.png` will open the image,
> > shouldn't an "open" program ask to the server what the media type of
> > the URL is, and pass it to the default program able to handle it,
> > instead of just visualising in the browser ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#512717: marked as done (project: Should have alternatives for graphical su and sudo (x-su, x-sudo?))

[Debian Bug Tracking System]

Your message dated Tue, 28 Jul 2020 15:49:32 +0200
with message-id <3c01488b7eb950a27837934382bd1bab3b58096a.ca...@43-1.org>
and subject line Re: project: Should have alternatives for graphical su and 
sudo (x-su, x-sudo?)
has caused the Debian Bug report #512717,
regarding project: Should have alternatives for graphical su and sudo (x-su, 
x-sudo?)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
512717: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512717
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: project
Severity: wishlist


It'd be nice if packages which depend on gksu, gksudo, ksudo, etc could use a 
unified alternative (e.g. x-su for su-like and x-sudo for sudo-like graphical 
frontents to su and sudo) so that one was not required to install e.g. parts of 
gnome just because a package depends on gksu (there are a few packages for 
which gksu pulls in more of gnome than if one leaves out gksu and uses ktsuss 
or ksudo (for instance)).

I'm not sure the appropriate place for this bug, so I put it on project for 
someone more knowledgable to reassign.

Thanks,

Daniel

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


--- End Message ---
--- Begin Message ---
On Thu, 22 Jan 2009 22:20:37 -0500 Daniel Dickinson wrote:
> It'd be nice if packages which depend on gksu, gksudo, ksudo, etc
> could use a unified alternative

I think graphical programs are supposed to use policykit to handle
privilege escalation (with pkexec for running specific programs).  So
an abstraction layer around gksu (which is no longer in the archive)
and others is probably no longer useful.

Ansgar--- End Message ---

Accepted glx-alternatives 1.2.0 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 02 Jul 2020 22:31:56 +0200
Source: glx-alternatives
Architecture: source
Version: 1.2.0
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers 
Changed-By: Andreas Beckmann 
Changes:
 glx-alternatives (1.2.0) unstable; urgency=medium
 .
   * Build for arm64.
   * Switch to debhelper-compat (= 13).
   * Bump Standards-Version to 4.5.0. No changes needed.
Checksums-Sha1:
 42c873dd57fb5409afd205964cc0633605e4cade 2048 glx-alternatives_1.2.0.dsc
 9ff38fdef236a29df6161242a80d63299c65a808 13912 glx-alternatives_1.2.0.tar.xz
 1f048b45fb76cbbe0f4455452f8a8912d3df492d 5267 
glx-alternatives_1.2.0_source.buildinfo
Checksums-Sha256:
 fa5460967901a9b62450d441abffe042c68618ca800f7203f958e1c873b3e2fe 2048 
glx-alternatives_1.2.0.dsc
 1abe0a4fb3f01f8cefeda3961e42590990ce0daecff299705dd393be0e3cbd18 13912 
glx-alternatives_1.2.0.tar.xz
 887a7f09fffe12630d6873368a4f8286102359f416e670dbea86990bbc3ffab2 5267 
glx-alternatives_1.2.0_source.buildinfo
Files:
 76599f462b38050da9d0445858a3f475 2048 contrib/libs optional 
glx-alternatives_1.2.0.dsc
 4b309e2ea8064f82e0c260c971a388e7 13912 contrib/libs optional 
glx-alternatives_1.2.0.tar.xz
 bc3ad167ae8141e5e3ed95f98ec9028c 5267 contrib/libs optional 
glx-alternatives_1.2.0_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAl7+RJgQHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCABvD/9K8jxaTP5U08zC0+LlaNguX40DpNQ+S1V8
buDNg8vngC9Pok/YD060Xr51sk+ox/urnyfGiiGek+9aSQGZ8XAeMO202BB0yRo0
TSeZjQtAnbEH1+QfDapXFF+0dzGw54QUX5uu1Utxfc32s0PnAawaIo7XjGBwn01o
ys5I+4MIfKmSL2/lbiYF0BLXiEZXaAYKd1P8J+BZjCVYheS2akeEenULtj75byVF
Rwik+5ujXvDaXgGVxf9D4yYZkSt3p+0S+hibPbfcrb94YkwAKxXqytG31ChKJNXt
j0RSI9bctxWie+fWTniMjTJzv6Asi/eyqHAq7ZSUZcELZxN1E/kyfV8GOjXP8Kb3
VilmM4NNXIbGpc6z3kNh9DQ1YlrgOwPO+z6mZ3JL7a79Pw/5SEq5V0MQbINGnT/j
eI+8BMzdYPB1tgsgeuQ01EyHUw8o1MMp08ZnjX5+RB41e7A7n50oGOtUWsJzOF/h
/ZcioFsTCl7+v6ZYrSvzpdam0z5NNP0CG1PTjsaFbeTZpNxZG/9ag2GEwZgMx1cr
eD2dcIm13SBo88VpvCPqsZ1RHDBms+UT6eMJT0rvTIegicvh/VPKOXtqel7qjA03
iHuYjGsaQCq8Q4/UW9Mij9qb6Mw3UWdsV+e2Cmu8Bblr3LTC7SIj4agvlVn7d7at
HrFqQJfV8Q==
=7/wW
-END PGP SIGNATURE-

Accepted puppet-module-voxpupuli-alternatives 3.0.0-4 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 24 Mar 2020 12:12:01 +0100
Source: puppet-module-voxpupuli-alternatives
Architecture: source
Version: 3.0.0-4
Distribution: unstable
Urgency: medium
Maintainer: Debian OpenStack 
Changed-By: Thomas Goirand 
Changes:
 puppet-module-voxpupuli-alternatives (3.0.0-4) unstable; urgency=medium
 .
   * Depends on puppet, not puppet-common.
Checksums-Sha1:
 cc97e351410c5ba366700c60c0bd5ceb14ed9714 2303 
puppet-module-voxpupuli-alternatives_3.0.0-4.dsc
 58c3be9750b801c0519206e54823e9ed86fe442d 2116 
puppet-module-voxpupuli-alternatives_3.0.0-4.debian.tar.xz
 e1a2a10f37dc5e9d6421cba73d01ed22c8af4805 6545 
puppet-module-voxpupuli-alternatives_3.0.0-4_amd64.buildinfo
Checksums-Sha256:
 bcfad07027c65e3bf313458d7120ea8f233324863fa1312ce137767a6a58ad78 2303 
puppet-module-voxpupuli-alternatives_3.0.0-4.dsc
 3149f6ecf3b6bca6e8b0c21787623383d80289a0d21f02eca2b780184c12f0bb 2116 
puppet-module-voxpupuli-alternatives_3.0.0-4.debian.tar.xz
 805f4b5a352f14f04c1f1099f1cc912c266f10904d98390ef2531bd638bae9b2 6545 
puppet-module-voxpupuli-alternatives_3.0.0-4_amd64.buildinfo
Files:
 0b5a106ec5344da24910e25766fbbba6 2303 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-4.dsc
 568c7e1a7ce2a77d58014df7a5a778b6 2116 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-4.debian.tar.xz
 cd82cdad1b1202830b6b913cf86c1bc0 6545 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-4_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEoLGp81CJVhMOekJc1BatFaxrQ/4FAl556y8ACgkQ1BatFaxr
Q/4EfBAAmkav+t6inVJg2NOK4Vy2qDjLxt5gQJrb+r3tH/9HtlJIQvXN2t8mgNV7
tMQX4fGPEjqYS6maNWFob3prg3lDq92MAEd6/s07jfAyS/ljesyE92gsnzq4NRCU
UehAKSWKM0lW68a2xvNvfCLF77bKqSyiCZJgYkE8YyYDtX8FJiL7T2m/oTwbtAVC
oLMMSiMVaV1DxFUj5M8KclOTF/CG1x3s60cG0WtP8cIH13QQb/BLZlpPeAFiTkWw
2Gaa4eYe7jq9WSmoRl0er6nq88Y0kUeph+iHpHuJMDXLpti6P8da0QVA0RIvpwp+
fNLguiRdqjdv5aFtBtQEyASODhlKmlHsJsQ+EqHQDD2KVVASVkNy51vrCAcFrJvE
xMzfZcTVv3vIhh82/egN0EJ0rINLQOtJWUFnJhTHkQ0n6u15enksIYQkCROWiE7u
Hmtl8M6+pv+bVyiPxtObyQKC4rsrcUJ5xzLW4/JiIkuPe+6dFKeGNOaDJl4M2Bjy
AUqOG6qAo5HJRrFdYYGURpFEBpv6AoXgjTFyYAwI4XDMu7uATam7s/GvePxSgnLp
IckACSbUYv+b6pnGCqTdLNsYikW4Ix1geChZe+LbZhXNIlidkmhXJg06inJp7JEZ
1bqPovf+aHm6FMSV2md4RrtZXkpZUDx3xn5e4LyBcnlYSjk/5Es=
=94fA
-END PGP SIGNATURE-

Accepted puppet-module-voxpupuli-alternatives 3.0.0-3 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 10 Feb 2020 11:43:55 +0100
Source: puppet-module-voxpupuli-alternatives
Architecture: source
Version: 3.0.0-3
Distribution: unstable
Urgency: medium
Maintainer: Debian OpenStack 
Changed-By: Thomas Goirand 
Changes:
 puppet-module-voxpupuli-alternatives (3.0.0-3) unstable; urgency=medium
 .
   * Add puppet-common and puppet-module-puppetlabs-stdlib as depends, create
 the /usr/share/puppet/modules folder on install.
Checksums-Sha1:
 217b9eef0bad3ec28e2acbc179d3da09b01144b1 2303 
puppet-module-voxpupuli-alternatives_3.0.0-3.dsc
 e7d2688c152c527fb3d3a8106deab33d151b2324 2088 
puppet-module-voxpupuli-alternatives_3.0.0-3.debian.tar.xz
 33d89b05221b24047461ececb222e0568cf63571 6620 
puppet-module-voxpupuli-alternatives_3.0.0-3_amd64.buildinfo
Checksums-Sha256:
 62c369ed8292d0ab9a54377c07b94388f98dc253b8d35ed41cd133836cc061f4 2303 
puppet-module-voxpupuli-alternatives_3.0.0-3.dsc
 1be85bb3b364c8b46eb270f5233698eb1d6ff55db0f138d03829de479f79ab97 2088 
puppet-module-voxpupuli-alternatives_3.0.0-3.debian.tar.xz
 9771005a3fb2ad49224d4cacf3666c126b23b4dd83072e78a0b83d59fd3939ba 6620 
puppet-module-voxpupuli-alternatives_3.0.0-3_amd64.buildinfo
Files:
 05d5bd3eeb627931b4ae790fa2f2b2ab 2303 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-3.dsc
 2f6ba312455f53b321aff5c56f5100ff 2088 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-3.debian.tar.xz
 3f63e36cdb0277b16150953cc5b8450d 6620 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-3_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEoLGp81CJVhMOekJc1BatFaxrQ/4FAl5BNLIACgkQ1BatFaxr
Q/5S5RAAnR3RNZFs9JhCSIyS23W8Ijqnk5fJviy7axCXG+gVaOCHtyu3vC56VfSU
cpueNI+8VI+MlX58qrYdWdO8062gJOVL9pZpwBGmdgJ58LO7LXEENwmJV02elMeP
SEPsK8N5XOReVPj2bQXVhLcETXr1054sG6Mq7gODPD7r/9EgLamg2mNOHtM5d8CX
724Mv4DCzjhwLm0qS4Mk7ok1rMdgXqXZGrtm10VVrDkLPIB7Z1xUtPDg1tmeNGxR
EsJk4k8o+MAJqb5iYg3axG1TBA0z4ThN13P8sbSb23E1ruegGd2RZzXSJY4U6Kw9
uwp2tfIntykQQL38l1vhJxUSEcsTdy2HzbIML4lVEhoTJ2fjS/g1A5QDWaPPd630
cP2btoJqF/W7LV7hao5reBYCmIodwu60Fxz7jS2VYo34SoO2R1nuwIuHf4ffRCX6
pLUTlFJn+Du9Py+qSadaXa5H8KcqFBgUnnYhbDxhlx9GYNFPuN7nVXqnW5I3h/5n
dt8/cGnTG/S6th8OiHPq6Q+3X2O+HNTjT4P26/VZ2kg8DslTrN/GHq7ZqfwcG906
Oa4GPyaSZfLvZVPzfYO8WNDuzErqVrX829/Kpw2ngIpA2Y0Zi0fEshPip4FS6rJc
Vo+3axO8/lghEYk31zt356ReKgFg/C4F2OSZVx0HFPpNikdEHOg=
=UWHi
-END PGP SIGNATURE-

Accepted puppet-module-voxpupuli-alternatives 3.0.0-2 (source) into unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 02 Feb 2020 12:33:09 +0100
Source: puppet-module-voxpupuli-alternatives
Architecture: source
Version: 3.0.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian OpenStack 
Changed-By: Thomas Goirand 
Changes:
 puppet-module-voxpupuli-alternatives (3.0.0-2) unstable; urgency=medium
 .
   * Added Adrien Thebo in d/copyright.
Checksums-Sha1:
 c9f5eeb16c2e7e94e68190adca0e2ea689023cfe 2303 
puppet-module-voxpupuli-alternatives_3.0.0-2.dsc
 e0ce3851506e1ec5a90c2b243deebba14f5ea7c7 2008 
puppet-module-voxpupuli-alternatives_3.0.0-2.debian.tar.xz
 b7ea9893e00dd358f38d687fa5ab037cb46554a4 6606 
puppet-module-voxpupuli-alternatives_3.0.0-2_amd64.buildinfo
Checksums-Sha256:
 2f6099eced544d528f957f7436b2efec421b283aff2c7015c317102401fbf50d 2303 
puppet-module-voxpupuli-alternatives_3.0.0-2.dsc
 fb71e4a3ef257ee0ffbd8f7678435c40b7a35d360a44211cad4e02a9eff1544d 2008 
puppet-module-voxpupuli-alternatives_3.0.0-2.debian.tar.xz
 0cb024723017a54fc6abe477143bd361d901ef1a81404a97ca66ff71e394f203 6606 
puppet-module-voxpupuli-alternatives_3.0.0-2_amd64.buildinfo
Files:
 6c27ba8108c126b92dc6a6a35299322a 2303 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-2.dsc
 81f7e9378e388729ffd50eb8fc3d1f1e 2008 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-2.debian.tar.xz
 dda4e88dd89b0ca0786fb294a567674c 6606 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEoLGp81CJVhMOekJc1BatFaxrQ/4FAl42s70ACgkQ1BatFaxr
Q/4YYQ/8DVuYt6ewKwp5gTsgoUYoGpneIodAo1AkayBdB6+00lW7Z/lZzU+ByKCZ
vN6BHI1Q7vVlo+/0T9wqpKrGJafYBwrldMnsmaiz/kJ8Fy1iyV4oQofk8gVqdmAD
WRt4pF/FDDq8egPGvvopYlNEpvpofM98KeX6bO8REtvPPirCgov/m1nkxw/Sz2y/
azlBWK5zpIQhLpm7cPccsnmiBGXobYVqHBHD7RAGTjXoylHLsRe8N9l87qFn/0ip
RW+ICdU4S2Q1NH1KLa5MX0q/4lw9/LfVW0/IuzQcncotF4WJNMiH+VCASTBBpNVR
jT5RkkZmsVGT9PLclvnLdNOvfswXsETEzeIns8Pwlkzsy5HC05S2OS+18euX21PX
M5neTjThS45vMsnOR5jZR8lMkAwHVAsBNdA0OqGj2qbPw5qeGOQxKnX+T34kDEUF
o3kJqjmyoVEAxOVCBqEtkaonB/WubGQ0aAT1It9+Opzd2KrojXV01H3zMkyCOFCj
XZlyurBnfz6tgQw2rfjybURz3NvsWmL+zIPeDTKqYo9JuL39CCS+vDrI6cvX12KJ
la70u1v7tkj4UGQbe93HsquwJWGaEEjHDHG8p0NY7eYx5C21M/wpRYeCnR+I1G4a
b7ouHoetfVcq+VpYQEdw8RgmjokT10hUYxTUf0j7O583OV+8gto=
=Ta2Z
-END PGP SIGNATURE-

Accepted puppet-module-voxpupuli-alternatives 3.0.0-1 (source all) into unstable, unstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 19 Nov 2019 11:20:57 +0100
Source: puppet-module-voxpupuli-alternatives
Binary: puppet-module-voxpupuli-alternatives
Architecture: source all
Version: 3.0.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian OpenStack 
Changed-By: Thomas Goirand 
Description:
 puppet-module-voxpupuli-alternatives - Puppet resource for managing Debian 
alternatives
Closes: 945070
Changes:
 puppet-module-voxpupuli-alternatives (3.0.0-1) unstable; urgency=medium
 .
   * Initial release (Closes: #945070).
Checksums-Sha1:
 9c7c531280acda89840beee58cf4e50213d12dd6 2303 
puppet-module-voxpupuli-alternatives_3.0.0-1.dsc
 a058af20e1499bcdd28e7838c80c8fd79ceea151 20004 
puppet-module-voxpupuli-alternatives_3.0.0.orig.tar.xz
 d452524c34b3163d8bfee281d64f35dd5927d772 1948 
puppet-module-voxpupuli-alternatives_3.0.0-1.debian.tar.xz
 30c9b0df8133901e535b21c9b0625edb65475b34 13444 
puppet-module-voxpupuli-alternatives_3.0.0-1_all.deb
 31d38a3478851a8e4b2c567e1281917f33c20741 6555 
puppet-module-voxpupuli-alternatives_3.0.0-1_amd64.buildinfo
Checksums-Sha256:
 28935541382cf88329d30de88b1069040bf338ef5f6653dd3099aacc1787e83f 2303 
puppet-module-voxpupuli-alternatives_3.0.0-1.dsc
 ec4b7eeb5aacf282bcd48236b79d4dca6bcf349636d205bbf9e819966e1a0b8b 20004 
puppet-module-voxpupuli-alternatives_3.0.0.orig.tar.xz
 2f2fd197c200d686a18eee8beaf3535dc5d35b59f96643dac825280120583387 1948 
puppet-module-voxpupuli-alternatives_3.0.0-1.debian.tar.xz
 9d9f425fc157368a0e2edde1dabaf57c94295e11ca97240be17ba78bd1128e23 13444 
puppet-module-voxpupuli-alternatives_3.0.0-1_all.deb
 4e42e7295d341391a83c4901b2d4feea5a8d59f94763fe830f4621ba832ab823 6555 
puppet-module-voxpupuli-alternatives_3.0.0-1_amd64.buildinfo
Files:
 44aff6b427a52959026beeaaab8eb5a4 2303 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-1.dsc
 4fc816295648058a0f892c995d56f674 20004 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0.orig.tar.xz
 31db62e884d82cc3b2e2525f710dc53f 1948 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-1.debian.tar.xz
 e75ec69348e89ce7ce5c14caab602ae0 13444 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-1_all.deb
 0f51567c98795f7ca113930105717b33 6555 admin optional 
puppet-module-voxpupuli-alternatives_3.0.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEoLGp81CJVhMOekJc1BatFaxrQ/4FAl4XR9wACgkQ1BatFaxr
Q/61yRAAgmD67jz9sdp0Bl9xVY028CcMr9zcKe7yUUbYi1ka+9fl7aKf1mL8eCM2
oU6tNi1VliGp/kmp9YpcefaXsPylwyKTIwzrREDkANE3CkCUVHQoM1DgibDva4wa
eAop37ZIJot/YMs23pkZIFAYL9R1HZ7XhtBu7VNjMWRvYzmbSrfUDDEtjjysOQOc
++kFwI+9F/fG3SihdSPmJkezt2YlqmNUz3KFsEA86FyaY/zhsPGx5ysPbUZ2f1JS
s/3jQFB3EVutzvSXrCvqmB85O2yo7rNplnGm38lto+WciDMvyYisebnPQ0ZW9fdi
JWx7HvNPaY7B6fSlVg4z89+2G85+I200L+xtrsNveHlemE2+TX79DGB+fdXmcF3U
jy3qvyfOxvQgsVRHCx7KaBl8qyqmajCEGA5E3Qr+I0VS9DMfkj8nLGUfkEv5hOwQ
d+oQBGx/ziC0uEqUp897CeH64G7dZ1Wu7kSDQvRysQa1royv+lckj4Kae+wXF3+i
WavmO9DyE6jI2kHruA+/IEOOjw9iFL8Qma2CydqDOpTtAaPJyryjqcB5AdHlXQRD
yrGrsu8xRMsJzS/6iyFevyJblK5i1IXeWnhAiOp5FfkeK9xkbo1CHXMrPQXahZ1o
5vhCP7XjBwU2ltMwWnHtEJo89s4kfLNTNiYHmM2VmS+i9YvVPBE=
=KtMY
-END PGP SIGNATURE-

Bug#945070: ITP: puppet-module-voxpupuli-alternatives -- Puppet resource for managing Debian alternatives

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-voxpupuli-alternatives
  Version : 3.0.0
  Upstream Author : Voxpupuli
* URL : https://github.com/voxpupuli/puppet-alternatives
* License : Apache-2.0
  Programming Lang: Python
  Description : Puppet resource for managing Debian alternatives

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This Puppet module provides a Puppet resource that manages Debian alternatives
 symlinks, which a user normally maintains through the shell command
 update-alternatives.

Accepted glx-alternatives 1.1.0 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 14 Nov 2019 03:38:25 +0100
Source: glx-alternatives
Architecture: source
Version: 1.1.0
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers 
Changed-By: Andreas Beckmann 
Changes:
 glx-alternatives (1.1.0) unstable; urgency=medium
 .
   * Build for ppc64el.
   * update-glx: Move manpage to section 8.
   * Bump Standards-Version to 4.4.1. No changes needed.
Checksums-Sha1:
 d55434e5fc80ce70f2b3a8489db58458c33cccf4 2018 glx-alternatives_1.1.0.dsc
 00c8ab17afbb29f316b60d7735f21567110ef27b 13852 glx-alternatives_1.1.0.tar.xz
 8622c107ff030e78ce45bae840985b4c8fa1d871 5305 
glx-alternatives_1.1.0_source.buildinfo
Checksums-Sha256:
 91ffc378986e9ee484191572f1d3a21e216fc028b3fba004a3888e03fa7bd950 2018 
glx-alternatives_1.1.0.dsc
 65e75ab23c18df406ed20b1d56df011522be648d8f8b5fa0540f2d22a9f7344b 13852 
glx-alternatives_1.1.0.tar.xz
 cc1dafe3d8a57f5f98c2697790c0c1f99fe1c984cdaef4dfab5fed3c52f0cb78 5305 
glx-alternatives_1.1.0_source.buildinfo
Files:
 c2987399e13a239f0833c7699f919b01 2018 contrib/libs optional 
glx-alternatives_1.1.0.dsc
 9a1771ee57f18fb2d832414a6ebaad5c 13852 contrib/libs optional 
glx-alternatives_1.1.0.tar.xz
 005759de097412e1dfc59276ac268645 5305 contrib/libs optional 
glx-alternatives_1.1.0_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAl3MvzQQHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCFELD/0TygKHhDQtnuoMho9z7JHL2nYix7a+DPsV
HtKY8zZHcw3NZnDUoUCF3GC1Ej2l84pwf/BCEdQO93t7FJ8Z/M300uRu95vA+kb8
jZbP999lXdr/lZGdP6LDoue/ibk+5LdkHvZowlvBzG/6XzjXX9sNarHJzPxahaG9
Qxaz3DJjocyvc4jTV+Cww2SMCwoA/B0qOij+LnT5e8xpkJVZubj5tKLRG7BeA5uP
k6fvpGDqHeIgpmP4qr6m6kQFEhtfc47zdt4OofNkeiUETx96Wv9xr8JlFbLYOC0n
QeTua1MTQWiTdZXzfuS+sGK73zUdPEDc8WOA1rtG7uu1y7UDVFcp7DXFcS55InI/
ZFNDMff8Ggk64Vy2GCwwJ6TGiwq+8XMdoIAAWVgKKFmM+5h34qks9Vf1I7bcydet
xzsunQAtB6XeQc+UoyntmnPrKdRNVC8puY9cKUTGJcKKSDWntLntzo/Rp9yBf+oW
bvNaAJfoKAAlW9VeNGE2TtH7k6b+jsZdUApdY/1cexVoM8ePVyI7sOEfhmhAJBz4
HiSYI6OMStq6dXusKozCyH/ExU9XXorvBHQA7LhbYrMLb9Cj/QIEz5YSeiRvlNK6
EUlZUKXasj69A5lg1D4YfA1DYKnTB9tKQzLWekbrBhZVAVDaYNYiN+dQBZr0d5Z5
dA/PYsi87A==
=F5uN
-END PGP SIGNATURE-

Re: sbuild: do not fail when there are alternatives

[Aurelien Jarno]

On 2019-07-20 07:58, Johannes Schauer wrote:
> No it does not block this. The sbuild configuration variable
> $resolve_alternatives or the command line option --resolve-alternatives allows
> one to enable or disable that sbuild only uses the first alternative.
> 
> As Gregor also correctly wrote, the problem is not sbuild but how sbuild is
> configured on the buildds.

This is indeed something configurable at the wanna-build level.

> You might want to re-assign the bug to the buildd admins if you really want to
> propose that the handling of alternatives is changed.

This is done on purpose in order to provide stable features over time.
If a package build-depends on foo | bar and foo is temporarily
uninstallable (for example due to a transition or a version mismatch
between arch:all and arch:any) bar will be used instead, possibly
disabling some features in the package. In the file & libseccomp
example, it means seccomp support might be silently disabled.

Note that for backports, alternatives are considered, as the above is
very unlikely to happen.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Re: sbuild: do not fail when there are alternatives

[Johannes Schauer]

Hi,

Quoting Geert Stappers (2019-07-20 07:50:11)
> On Fri, Jul 19, 2019 at 11:28:36PM -0300, gregor herrmann wrote:
> > On Sat, 20 Jul 2019 00:21:10 +0200, Christoph Biedl wrote:
> > 
> > > * Centralize the list of supported archs in the seccomp packages. By
> > >   either creating an empty libseccomp-dev for the archs where seccomp
> > >   is not supported, or by creating a "libseccomp-dev-dummy" for these.
> > >   In the latter case package maintainers would have to do a one-time
> > >   change of the build dependency into "libseccomp-dev |
> > >   libseccomp-dev-dummy" and can focus on other issues then.
> > 
> > AFAIK this won't work because sbuild on the buildds is configured to
> > only use the first alternative from a list of build dependencies.

Yes it will work. Please read Christoph's proposal again. There is an "or" in
the second sentence.

A solution that either produces an empty libseccomp-dev package or a
libseccomp-dev-maybe package which either does or doesn't depend on
libseccomp-dev, depending on the architecture will work perfectly fine with
sbuild as it is configured on the buildds.

> Reported as bug.
> 
> Not checked if it already was reported before.
> Not checked if it really fails when it can't find
> the first alternative from list of build dependencies.
> 
> Thing is that sbuild _might_ be blocking
> a nice way to cope with libraries that are not available
> on all architectures.

No it does not block this. The sbuild configuration variable
$resolve_alternatives or the command line option --resolve-alternatives allows
one to enable or disable that sbuild only uses the first alternative.

As Gregor also correctly wrote, the problem is not sbuild but how sbuild is
configured on the buildds.

You might want to re-assign the bug to the buildd admins if you really want to
propose that the handling of alternatives is changed.

Thanks!

cheers, josch


signature.asc
Description: signature

sbuild: do not fail when there are alternatives

[Geert Stappers]

Package: sbuild


Previous-Subject: Re: seccomp woes
Original-To: debian-devel@lists.debian.org

On Fri, Jul 19, 2019 at 11:28:36PM -0300, gregor herrmann wrote:
> On Sat, 20 Jul 2019 00:21:10 +0200, Christoph Biedl wrote:
> 
> > * Centralize the list of supported archs in the seccomp packages. By
> >   either creating an empty libseccomp-dev for the archs where seccomp
> >   is not supported, or by creating a "libseccomp-dev-dummy" for these.
> >   In the latter case package maintainers would have to do a one-time
> >   change of the build dependency into "libseccomp-dev |
> >   libseccomp-dev-dummy" and can focus on other issues then.
> 
> AFAIK this won't work because sbuild on the buildds is configured to
> only use the first alternative from a list of build dependencies.

Reported as bug.

Not checked if it already was reported before.
Not checked if it really fails when it can't find
the first alternative from list of build dependencies.

Thing is that sbuild _might_ be blocking
a nice way to cope with libraries that are not available
on all architectures.

Context at https://lists.debian.org/debian-devel/2019/07/msg00405.html


Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: PGP signature

Accepted glx-alternatives 1.0.0 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 14 Apr 2019 09:11:12 +0200
Source: glx-alternatives
Architecture: source
Version: 1.0.0
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers 
Changed-By: Andreas Beckmann 
Changes:
 glx-alternatives (1.0.0) unstable; urgency=medium
 .
   * glx-alternative-nvidia: Add Breaks against nvidia-legacy-304xx-driver,
 xserver-xorg-video-nvidia-legacy-304xx, nvidia-legacy-304xx-alternative
 to ensure the obsolete legacy version from stretch gets removed during
 upgrades to buster.
   * Drop versioned constraints that are satisfied in wheezy.
Checksums-Sha1:
 15d9a8ffa59b770c41a60a13094fd0d06760f9e3 1978 glx-alternatives_1.0.0.dsc
 baaf3a162c3ca3c2b9b64689cd52ae35bf5ef3bf 13772 glx-alternatives_1.0.0.tar.xz
 4e4a52ada2ac7fb4dbaf5c146156bbf0f8e450dd 5089 
glx-alternatives_1.0.0_source.buildinfo
Checksums-Sha256:
 abeb89d57ac4e45498bbdd53bf10e6f4040eb1dfb2f423c04ae0fc5c9a2ef784 1978 
glx-alternatives_1.0.0.dsc
 613a8d03b8f16a842714c29aacf82d682a82540acc1f5bad6f92c473e74180c3 13772 
glx-alternatives_1.0.0.tar.xz
 fa67b8b434d529ee22b6cbe70184defd9613184ede57ab13d9b6da031560c894 5089 
glx-alternatives_1.0.0_source.buildinfo
Files:
 0470f1fdd1dd77a6407ecd350be12d2e 1978 contrib/libs optional 
glx-alternatives_1.0.0.dsc
 fd38cd2706c8b6d14574bd1adcffe2c8 13772 contrib/libs optional 
glx-alternatives_1.0.0.tar.xz
 9d0ea256de73132d314c704631228e0d 5089 contrib/libs optional 
glx-alternatives_1.0.0_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAlyy36UQHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCHIwEACGYLiAAl35pDO/ufUKY3fRAn6GaljI5SHL
sr+Fsqera8mnyspGEupeR0hVtQiyHfHy9YA+hxzEMoXUXsY3+AeaR2X1wljEFivy
KNGLZeYwFpgO4ORG21NiDW4v+KYR+VdFL39OR4Y++/LeR05ZAVK4hibHiFZjjzRz
VwJSIReI0w+qpwXE0mGRfgY4jR+JPCYU+DYJIs0s31IX2MQJkcfIksR26P9/FuoT
kXbQRthSWUeETIdnLhCJlGtiokivs3QYrbC2Y5vL6rQuQuIHQzeCxs+Spp4+bRG/
k0nA4qj0L46PBig5OAbJvNnWIznlY8+08qnpd0DEKLeltBl5vKs/fC4O9GjWUhid
D9sx1g+utS+H75SseanuVriVaTg/8VV7lE79o1Qj9e5+XaSf+ScLDy3AEgwhlfHi
gpsNhU5IoVFctslu6ITorZmOLEfiCNYAmlUkQLJXEUYdXB+RtQ2n/Ax++mdpnXZv
8Y8YjhuITsAeAmXH5mhIxCLNyuq3mybhWnQ8AjAYPz3Zq916SSGi1x15UeHmksZS
za1Jy19LXSEzvGsimzAkh58KjsOOimDJaZvOoR6Kxhwr7Eg3ZDxvP1/KxN9NrrRF
C/HqSwWmXzTZ7zSbZw2BVEbWItonatWe0XF8SiaV5xekZMWBXs6/S7M8urjXVwYM
Z0aY3APN1w==
=imEP
-END PGP SIGNATURE-

Re: Is multiple-layers of alternatives a good thing to users?

[Mo Zhou]

Hi Guus,

On Mon, Feb 04, 2019 at 07:55:41AM +0100, Guus Sliepen wrote:
> >  libblis.so.2 libblis2 #MINVER#
> 
> If the ABI and API are the same for all variants, a much better
> solutions seems to me to have a single libblis2 that can switch at
> runtime between the different variants, perhaps using an environment
> variable to decide. That would require some support from upstream
> though.

Yes, I agree that such support is better. Actually the libmkl-rt library
from intel-mkl (non-free) supports the feature you said[1], and its
quite convenient. However for the BLIS upstream I think they don't have
enough fund and energy to develop such a feature. Based on that,
the current solution looks good enough.

[1] Env var MKL_THREADING_LAYER={intel,gnu,tbb,sequential}
allows to to switch threading model among libiomp5, libgomp,
libtbb2, and none.

Re: Is multiple-layers of alternatives a good thing to users?

[Guus Sliepen]

On Mon, Feb 04, 2019 at 06:07:55AM +, Mo Zhou wrote:

> My updated version, all variants are co-installable now:
> 
>  Package: libblis2-openmp,  Provides: libblas.so.3, libblis.so.2
>  Package: libblis2-pthread, Provides: libblas.so.3, libblis.so.2
>  Package: libblis2-serial,  Provides: libblas.so.3, libblis.so.2
>  Package: libblis2 (meta),
>  Package: python3-numpy,Depends: libblas.so.3
> 
> The meta package is still necessary because of symbols/shlibdeps.
> Different threading variants have the same ABI/API, so the
> dependency template is written as
> 
>  libblis.so.2 libblis2 #MINVER#

If the ABI and API are the same for all variants, a much better
solutions seems to me to have a single libblis2 that can switch at
runtime between the different variants, perhaps using an environment
variable to decide. That would require some support from upstream
though.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Re: Is multiple-layers of alternatives a good thing to users?

[Mo Zhou]

Hi Ian and Thibaut,

Inspired by Thibaut's comment, I worked out a good solution for
the co-installation problem, which only results in a single layer
of alternatives.

Thibaut's proposed layout:
>   Package: libblis2-openmp,  Provides: libblas.so.3, libblis.so.2
>   Package: libblis2-pthread, Provides: libblas.so.3, libblis.so.2
>   Package: libblis2-serial,  Provides: libblas.so.3, libblis.so.2
>   Package: python3-numpy,Depends: libblas.so.3

My updated version, all variants are co-installable now:

 Package: libblis2-openmp,  Provides: libblas.so.3, libblis.so.2
 Package: libblis2-pthread, Provides: libblas.so.3, libblis.so.2
 Package: libblis2-serial,  Provides: libblas.so.3, libblis.so.2
 Package: libblis2 (meta),
 Package: python3-numpy,Depends: libblas.so.3

The meta package is still necessary because of symbols/shlibdeps.
Different threading variants have the same ABI/API, so the
dependency template is written as

 libblis.so.2 libblis2 #MINVER#

instead of e.g.

 libblis.so.2 libblis2-openmp #MINVER#

On Sun, Feb 03, 2019 at 09:34:08PM +, Ian Jackson wrote:
> In general coinstallability is a good thing.
> ...
> This would mean that the user could choose a different library for
> "programs which wanted BLAS" and "programs which wanted BLIS" but I
> don't think that is a problem ?
> ...
> I agree that multiple layers of alternatives indirection is
> undesirable.  But I think these libraries can be made coinstallable
> without that.

My initial design of package layout is hierarchical. Inspired by
the comments I found the above solution after a rethink. BLIS
packaging has been updated and I'm testing it now.

Thank you for comments.

Re: Is multiple-layers of alternatives a good thing to users?

[Ian Jackson]

Mo Zhou writes ("Is multiple-layers of alternatives a good thing to users?"):
> A user suggested[1] that the 6 variants[2] of BLIS should be
> co-installable. However, making them co-installable would result in
> multiple layers of alternatives in the update-alternatives system and
> will possibly confuse users, as discussed in [3]. I wrote this mail
> in case anyone has a better solution so we will have a chance to fix[1].
> 
> Tacking the three 32-bit variants as examples, we will have the
> following alternative chain if the 3 variants were made co-installable:
> 
>   Package: libblis2-openmp,  Provides: libblis.so.2
>   Package: libblis2-pthread, Provides: libblis.so.2
>   Package: libblis2-serial,  Provides: libblis.so.2
>   Package: libblis2 (meta),  Provides: libblas.so.3,  Depends: libblis.so.2,
>   Package: python3-numpy,Depends: libblas.so.3
> 
>   numpy asks for libblas.so.3
> -> libblas.so.3 is an alternative pointing to libblis2
> -> libblis.so.2 is an alternative pointing to any one of the three 
> variants

In general coinstallability is a good thing.

I don't understand why the multiple levels of alternatives are
inevitable.  Why could each of the variants not provide both an
alternative option for libblas.so.3, and separately one for
libblis.so.3 ?

This would mean that the user could choose a different library for
"programs which wanted BLAS" and "programs which wanted BLIS" but I
don't think that is a problem ?

(Getting there from here is left as an exercise to the reader...)

> Such layout not only makes the packaging more difficult to maintain, but
> also makes it harder for the user to understand what BLAS backend is
> actually invoked.

I agree that multiple layers of alternatives indirection is
undesirable.  But I think these libraries can be made coinstallable
without that.

HTH.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Is multiple-layers of alternatives a good thing to users?

[Mo Zhou]

Hi devel,

A user suggested[1] that the 6 variants[2] of BLIS should be
co-installable. However, making them co-installable would result in
multiple layers of alternatives in the update-alternatives system and
will possibly confuse users, as discussed in [3]. I wrote this mail
in case anyone has a better solution so we will have a chance to fix[1].

Tacking the three 32-bit variants as examples, we will have the
following alternative chain if the 3 variants were made co-installable:

  Package: libblis2-openmp,  Provides: libblis.so.2
  Package: libblis2-pthread, Provides: libblis.so.2
  Package: libblis2-serial,  Provides: libblis.so.2
  Package: libblis2 (meta),  Provides: libblas.so.3,  Depends: libblis.so.2,
  Package: python3-numpy,Depends: libblas.so.3

  numpy asks for libblas.so.3
-> libblas.so.3 is an alternative pointing to libblis2
  -> libblis.so.2 is an alternative pointing to any one of the three 
variants

Such layout not only makes the packaging more difficult to maintain, but
also makes it harder for the user to understand what BLAS backend is
actually invoked. So my current solution is only allowing one instance
of the three variants installed on the system, i.e. every one of the
three variants conflicts with each other.  Drew and Sébastien agreed
with the choice to make the variants conflict to each other. So I
personally tend to leave the bug[1] unresolved.

However if anyone comes up with a better idea or solution, or believes
that multiple layers of alternatives are fine, we could discuss about it
and try to address the co-installability issue[1].

As a side note, different variants of BLIS are co-installable on Fedora,
but they come with different SONAMEs and there is no any mechanism
similar to update-alternatives at all.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919272
[2] 6 variants = (32-bit index, 64-bit index) x (openmp, pthread, serial)
[3] https://lists.debian.org/debian-science/2019/01/msg7.html

Accepted glx-alternatives 0.9.1 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 27 Jan 2019 08:03:20 +0100
Source: glx-alternatives
Architecture: source
Version: 0.9.1
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers 
Changed-By: Andreas Beckmann 
Changes:
 glx-alternatives (0.9.1) unstable; urgency=medium
 .
   * Switch to debhelper-compat (= 12).
   * Bump Standards-Version to 4.3.0. No changes needed.
Checksums-Sha1:
 7ff50fe3a227575ced37e1ec9effe081aa6e4156 1978 glx-alternatives_0.9.1.dsc
 fd273fb61714ac677daf908da34d3812e2a6c65e 13532 glx-alternatives_0.9.1.tar.xz
 43ca2af28e7be7a1d499178cc90c1b1e2fbc707b 5400 
glx-alternatives_0.9.1_source.buildinfo
Checksums-Sha256:
 884e1cef7f52415bd37735c32436ea08a307ca55c492b80c09bb9038911bcda9 1978 
glx-alternatives_0.9.1.dsc
 cee9ac30d1b37292a582fa780cab359c60b974cb011efaee68d179113b89d42f 13532 
glx-alternatives_0.9.1.tar.xz
 2ed58ed0fe6b2c124eb5bd99874f47dc8a7529eb6a840e3d9f60f145d56f789a 5400 
glx-alternatives_0.9.1_source.buildinfo
Files:
 394c71c2c7efa532239333d15f827f70 1978 contrib/libs optional 
glx-alternatives_0.9.1.dsc
 b12f5d176c1db3b5c602ba9857ba9f73 13532 contrib/libs optional 
glx-alternatives_0.9.1.tar.xz
 515839ee19bfb967d45136352bdd4874 5400 contrib/libs optional 
glx-alternatives_0.9.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAlxNWCkQHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCOkgD/0eTqJ2XuGcho0KVfadd4lhPNHLvZ04oyYP
JMx8qn+tQV0mtbj0ERqlqKE6sN9qilnuZL87J+9Gnxnt+afof1ghtaLOLDvxG4/a
ULuqIf6Bopd06hBFcMoLBXCkq5oYJ3yvvwLHbgjQvEqX43l2WQ9BThTCBAYthRPH
1FX8Lt0eu8Rn67f65ff9oyUzCOLAcKOV3MmVzioDkErxtapi88ocTo8WnqnXGvZ9
SRKMo9R8jbCdhNXN42OwrQVcDGjQ+uCpFdPENu9d4mhEZySjZPvnqosr+BDdZjaZ
1sTS+CIxFmSWZPEuxUMDtFyyWdIPXS/4tX9JYaM2sSfMMs7BS+R6LzeMPq+ivSE1
qzCtaE3ZqatWdh82ICzTg5oR2RTfHJoCul5BKVyNwKvrCrcrIuMVd0xO7FOFirlE
1fd+iAqd8gR8Hpt/SJe/Xf0Bmt2T7hw28kXjdrVZQow1ySjqpp5tDaOMHmOVitjX
MNsqBIZFeCk/PNJ/BRFcfAOR3hyF6/rM36l8iIh3cMP0txnuGu/XoDydczH1t4Ae
xAa+FQAA4U1pOIiA73NX2WX0vYSStk+GKL7+uNMKqMjH+6zzojGYBUXDsvn82jh9
EM+/nL6pXfMZWEblQw8ED3u6EQlD6+ye/M0lu3MBGzmoVRGp8Vn0fYPDEzyPghmv
Wt7Yb4C3zQ==
=h/HI
-END PGP SIGNATURE-

Re: Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives

[Sean Whitton]

Hello,

On Mon 24 Dec 2018 at 05:37pm -0300, Felipe Sateler wrote:

> I (not speaking for the whole team), have no objection to this patch.
> However, it was pointed out to me that virtual packages require policy
> updates[1], first starting as a debian-devel discussion. So I'm starting
> this now
>
> The proposed virtual packages are:
>
> logind: a org.freedesktop.login1 D-Bus API implementation
> default-logind: should be provided by the distributions default logind
> provider (currently pam-systemd)
>
> Background: currently libpam-systemd provides two features currently used
> by third parties: one is the necessary hooks to start the systemd
> implementation of login1. The second is hooking up the systemd --user
> service manager. This virtual package attempts to disentangle the two so
> that packages that only require logind can use an alternative
> implementation.
>
> Adam/other elogind maintainers, please clarify/improve wording if this was
> somehow inaccurate.

There seems to be a consensus (and this is not really controversial), to
please file a bug against Policy with a patch to the virtual package
list for seconding.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives

[Tollef Fog Heen]

]] Felipe Sateler 

Two minor typos.

> The proposed virtual packages are:
> 
> logind: a org.freedesktop.login1 D-Bus API implementation

«an org…»

> default-logind: should be provided by the distributions default logind 
> provider (currently pam-systemd)

distribution's.

Otherwise, this looks like a good idea to me.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives

[Adam Borowski]

On Mon, Dec 24, 2018 at 05:37:56PM -0300, Felipe Sateler wrote:
> On Sat, Dec 22, 2018 at 5:33 PM Adam Borowski  wrote:
> > Could you please either take this patch or propose a different approach?
> > I have received no feedback other than a brief unconclusive remark on IRC.
> 
> Sorry for the radio silence. Let's try to remedy that.

Thank you for moving this forward!

> > opt-in for every depender on libpam-systemd
> 
> This is a good feature of the proposal: it requires explicit opt-in by
> reverse dependencies.

> > Thus: if package X and Y need APIs that elogind provides, they'd be changed
> > to:
> > Depends: default-logind | logind
> > while package Z that needs a "bring-me-pink-pony" function will not.
> 
> I (not speaking for the whole team), have no objection to this patch.
> However, it was pointed out to me that virtual packages require policy
> updates[1], first starting as a debian-devel discussion. So I'm starting
> this now

Right.  In the meantime, you can test using libpam-elogind-compat which is
a hack that Provides: a real package.  This lacks the opt-in effect, but
outside of packaging metadata should work the same.

> The proposed virtual packages are:
> 
> logind: a org.freedesktop.login1 D-Bus API implementation
> default-logind: should be provided by the distributions default logind
> provider (currently pam-systemd)
> 
> Background: currently libpam-systemd provides two features currently used
> by third parties: one is the necessary hooks to start the systemd
> implementation of login1. The second is hooking up the systemd --user
> service manager. This virtual package attempts to disentangle the two so
> that packages that only require logind can use an alternative
> implementation.

Not sure if it's worth noting that the Provides must, and Depends can, be
versioned.  This allows requiring a certain level of the API.

> Adam/other elogind maintainers, please clarify/improve wording if this was
> somehow inaccurate.

Looks good to me, thank you!


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives

[Felipe Sateler]

Hi,

On Sat, Dec 22, 2018 at 5:33 PM Adam Borowski  wrote:

> Hi!
> Could you please either take this patch or propose a different approach?
> I have received no feedback other than a brief unconclusive remark on IRC.
>

Sorry for the radio silence. Let's try to remedy that.


> The clock for Buster is ticking; to get any testing we'd need to act soon.
> Not only this approach has been proposed by one of systemd maintainers
> (granted, more as a brainstorming than a definitive proposal from your
> team)
> but it also has seen actual testable packages since January.
>
> I admit that my own testing was extremely uneven -- mostly restricted to
> environments I personally use -- but as the idea is opt-in for every
> depender on libpam-systemd, packages no one claims to have tested simply
> won't be usable without systemd.  Just like they're right now.
>

This is a good feature of the proposal: it requires explicit opt-in by
reverse dependencies.


>
> Thus: if package X and Y need APIs that elogind provides, they'd be changed
> to:
> Depends: default-logind | logind
> while package Z that needs a "bring-me-pink-pony" function will not.
>

I (not speaking for the whole team), have no objection to this patch.
However, it was pointed out to me that virtual packages require policy
updates[1], first starting as a debian-devel discussion. So I'm starting
this now

The proposed virtual packages are:

logind: a org.freedesktop.login1 D-Bus API implementation
default-logind: should be provided by the distributions default logind
provider (currently pam-systemd)

Background: currently libpam-systemd provides two features currently used
by third parties: one is the necessary hooks to start the systemd
implementation of login1. The second is hooking up the systemd --user
service manager. This virtual package attempts to disentangle the two so
that packages that only require logind can use an alternative
implementation.

Adam/other elogind maintainers, please clarify/improve wording if this was
somehow inaccurate.

[1]
https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

-- 

Saludos,
Felipe Sateler

Accepted glx-alternatives 0.9.0 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 17 Dec 2018 23:30:30 +0100
Source: glx-alternatives
Binary: update-glx glx-diversions glx-alternative-mesa glx-alternative-nvidia
Architecture: source
Version: 0.9.0
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers 
Changed-By: Andreas Beckmann 
Description:
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
 update-glx - utility for switching the GLX implementation
Changes:
 glx-alternatives (0.9.0) unstable; urgency=medium
 .
   * glx-alternative-nvidia: Add alternative for libglxserver_nvidia.so
 which replaced libglx.so in the 410 driver series.
   * Switch to debhelper-compat (= 11).
   * Update Lintian overrides.
Checksums-Sha1:
 ef0454e2f6bff7e04fd748bdce175745ab4e5ece 1978 glx-alternatives_0.9.0.dsc
 6f852d0eab47e47870dbef43be825c204e4d55f1 13516 glx-alternatives_0.9.0.tar.xz
 e515118a6a870c6ffe1fd79f5d8746a065f19b20 5370 
glx-alternatives_0.9.0_source.buildinfo
Checksums-Sha256:
 383263569852f58c4d980479f8d09e70f1db2cd6241a332591aaf15a6501d7f5 1978 
glx-alternatives_0.9.0.dsc
 b2ee0961dedafdb2681c2fc9e254a0287c9adff4d56a0e58ce4eafa02949bb37 13516 
glx-alternatives_0.9.0.tar.xz
 dcfbc894b3286df5978f17406f3fc4f4e6a731226471878f8f07be413b17df2d 5370 
glx-alternatives_0.9.0_source.buildinfo
Files:
 6775c4239f3f4a8b6e32cdd213d530cc 1978 contrib/libs optional 
glx-alternatives_0.9.0.dsc
 54807c965e09274057251e887c6d1a4f 13516 contrib/libs optional 
glx-alternatives_0.9.0.tar.xz
 c48b467ed7df47508954442adf9db7e5 5370 contrib/libs optional 
glx-alternatives_0.9.0_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAlwYI9QQHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCGUOEACVLNx/2F/DErwT/kcGJ3gTvGBQ4Z6+ADh5
9KhdQkgtvw4X1aLkYbxyfm8Yx+WzA8/sLk+UfD/v/XC5O31l9nh8M8xU+AD78p9I
rymx97km8V3u8PYKxOC961PasszrC3C131rCmU9DymD2nmNEFqJu+PXyO7ZWHLAS
m+hS3xW6TLUHAsta+YHIEABAsri8bOE3SRQVeDKhaoNZ1D74M7FdXZBfVlCr9xnb
dfBbPSpM5JrhPh8+h8AjJ3Y4i334AiIOrt4NrD8S/qZqLdsa5fUUVn2fbYdJCenv
9ScXNFecVbggouXXrGOp9aYZyQ8et8bZ3NCy+ISH1EH78O1TX51SwqGzaFc2a11I
hvDO9E3vgCrMKgoY7yxlWNXRKatrQRpX7TX5QdgzL4Ij3+FFCggijzWHhzcecCiC
yuswDtPjxXC7J0MJDoprTVM/xYMUKteJa+zip5ev/HaFqN+cozUeDfOLTd/5DfoJ
AZ1N63X5iT136RjHdn10/fGttQ3NgPPhPAYpnhyZkGqFh9LC9RvfGJE+KmQyGz51
IHow4fq1ynC6w04YMRi0WcfIGWgHYr8FGinNFbIzwUbikSW2zQmmgyUt9B1WDu17
F8iEfARM3P+ZThbH6vDTwqSHnJbv6ZVCBzye9kWLjGvw2Q6W+JvyRCM737BTYXat
vJrBhTHpWw==
=MmDX
-END PGP SIGNATURE-

Accepted glx-alternatives 0.8.8 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 05 Sep 2018 12:04:55 +0200
Source: glx-alternatives
Binary: update-glx glx-diversions glx-alternative-mesa glx-alternative-nvidia
Architecture: source
Version: 0.8.8
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers 
Changed-By: Andreas Beckmann 
Description:
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
 update-glx - utility for switching the GLX implementation
Closes: 905908
Changes:
 glx-alternatives (0.8.8) unstable; urgency=medium
 .
   * glx-diversions: Put all packages that had shared libraries diverted into
 triggers-awaited state to ensure the triggers in glx-alternative-mesa
 setting up the glx alternative get processed earlier.  (Closes: #905908)
   * Bump Standards-Version to 4.2.1. No changes needed.
Checksums-Sha1:
 edbd13e7b53ada812d1ec9eb80385a3e985fbcfc 1973 glx-alternatives_0.8.8.dsc
 869d567f6d674ca17da92084e9d6b56b48fd0156 13416 glx-alternatives_0.8.8.tar.xz
 3b3760b3344b89d1557b2af79a87169fc6d92ea8 5552 
glx-alternatives_0.8.8_source.buildinfo
Checksums-Sha256:
 0c1b38b8e902e183fec584dbf0e90b6217f25c27e95c6a86d6b0d5a1c47bf755 1973 
glx-alternatives_0.8.8.dsc
 723cc528f673ff9895ed8a568dae7f31f526dca34ae62a7ac84040a4d9943b25 13416 
glx-alternatives_0.8.8.tar.xz
 20e2ed8bc4b3b4c40515249fcd29d7fe59f12ed5f969f15339947528b7a67936 5552 
glx-alternatives_0.8.8_source.buildinfo
Files:
 80d77eeb7f7b23e7d1cb57a0ce52aebb 1973 contrib/libs optional 
glx-alternatives_0.8.8.dsc
 bff0f462d1005540884ed7898686fcc7 13416 contrib/libs optional 
glx-alternatives_0.8.8.tar.xz
 081009b23df145a1d2a42d1f4385e44b 5552 contrib/libs optional 
glx-alternatives_0.8.8_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAluPxyQQHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCE+/D/90w5K7pJGCiyxEwjhCHyDT9Tm94AF+1uJM
g08S4BxwNNBGUGnt+HVNhUOLeKkigrr8t/+w7gbOHSN9Ivcsqx7mSF81uTRuZNgV
0jA6wbkElRs9cdPLL66VXGMP+oVJ+iP1kSIlH1Mknd0UzTJhA8ph+78P9ofCq4d7
2+95C2CHLo7OtUhdBuLMVqFePrxiuSOEzLBXOoVKJdAUkAnHDp7qwBNrmMHmBrH8
vbbGryjnAS90+njkma9p39XetbUIk0saNBoO0eM6fEL/mTVVZAyEol2DypS4xrSV
cPJBuzI9WAnsxvBoBudOHuSzkiwj69QXB9KAbbRJo5mlpd/sFcJ5xVlf6vkb8qkp
f14tm6u/E3qy+Da94b3+vS8AzdMptkh4SoIm4jQUbIFm6OBB7IhNmMiYAuokxMTy
V2AJoMFIgiHpMdwnfMqj2vxrsauoGvcYZ32ifmXvWgPlkJqPopGRD1U1BiNsP98e
jncvaIuQ63x93vAtpVsvgicq1Fv8B+QUkkYKHQwXreMqF5SFiw0SbYBkoAoTTzU2
2Bc2+JVRyxgkJtaHH4k70B+dirIoK84ie6ssAGQs705IITjTJmyLy9uvyGfgsbBe
sW/Tmq1VW/mqZygV0TJ33vslbakWlr2kjlapi2BWRXtGPVw07rJFowdg4gXZ6QKY
/WcoTPui3Q==
=ObsI
-END PGP SIGNATURE-

Accepted glx-alternatives 0.8.7 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 31 Jul 2018 17:27:59 +0200
Source: glx-alternatives
Binary: update-glx glx-diversions glx-alternative-mesa glx-alternative-nvidia
Architecture: source
Version: 0.8.7
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers 
Changed-By: Andreas Beckmann 
Description:
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
 update-glx - utility for switching the GLX implementation
Changes:
 glx-alternatives (0.8.7) unstable; urgency=medium
 .
   * Update validation of the diverted libGL.so symlink.
Checksums-Sha1:
 3c8812c019c2a016abc69eb4b33a2a168594bb35 1973 glx-alternatives_0.8.7.dsc
 bd5b9af2ed31aaffeed80752cf67e828a70440bb 13244 glx-alternatives_0.8.7.tar.xz
 b7ec509f40bfdb31b8bc17ca8ae38dc5f331dcfd 5546 
glx-alternatives_0.8.7_source.buildinfo
Checksums-Sha256:
 f5e348cc1646133cd758c5ca6bcd027b916226827b20499791831fcb351b9ccb 1973 
glx-alternatives_0.8.7.dsc
 28bb7508720d3cf484da83f37ded4fd6a821818ccdcb52b116139b53189a8598 13244 
glx-alternatives_0.8.7.tar.xz
 be5efb8bc632c74035a1a24833d6332906bce0fee64774caf8f3146604516493 5546 
glx-alternatives_0.8.7_source.buildinfo
Files:
 bbb04350a387d6a0034a4e0e035c23c6 1973 contrib/libs optional 
glx-alternatives_0.8.7.dsc
 6864722fe72822cc0be022cd2dfe0bb7 13244 contrib/libs optional 
glx-alternatives_0.8.7.tar.xz
 fca7cba0ad17aa4297ef54d3c516106e 5546 contrib/libs optional 
glx-alternatives_0.8.7_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAltggmQQHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCLfCD/9Xc88nkKwoQwfUqPHmZhE3ziauY3cdc/n0
f2wZW8GG+rMCLs5W624JpXqW+Vt3LQby4PlSIbMrWf1Ou4TQsLl/7wnhvdPUjnRG
+CVYoA7sE8nxHkQJAzjV3haThaXbWGsVC1NJTmpAW0DX4uDqrnSHJr4PbWwVcEYr
MjaVIADPcZXs7BBYOdIgFtZZAFVH49gguFmd35yMkCRcEy1DisFqKXNMTP0+x8my
I2LUKsXr8PMTvxs3EKSQYqvLFsexJwlS9g7eqyoxMA9Zsz+PIi2B8u4PldFrSiuA
LK2p5CaTSHEdLDkbReub4lF4xTf9i3A8TuhGQGGnPzS5b/13UiesovLSJ2twa+XA
4EkWMORGB/V+ZRsnxtww3cEEKaXx2xlWdr8P/xNcUWCK1ThwzI7a9TPJ7N/rnGUK
Xy5X3vl37TzoWptAqH1LA4/TuK6du+EpVdvnTkCPGcO3mPfPimVGXsYINoz9onlw
nor5MWr6lsBgPD9HdsANalOfb3ZJTEuQnbZp8G85z+AXsj9QTz9T8uC5KDdj2YVI
uT/QBmGHoehiI09uUT8jx4b6BEInbRXb5GieeG3vRBRa181w2a2NHzXDPALSwMD4
Ycs/aL//XMvbIuCXhwNJp4L91NFSm3qoHuFIdCVNam+eNww/Q5jcVIigfJjM8WbY
acwgpOqdqw==
=/2RW
-END PGP SIGNATURE-

Accepted glx-alternatives 0.8.6 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 26 Jul 2018 13:55:24 +0200
Source: glx-alternatives
Binary: update-glx glx-diversions glx-alternative-mesa glx-alternative-nvidia
Architecture: source
Version: 0.8.6
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers 
Changed-By: Andreas Beckmann 
Description:
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
 update-glx - utility for switching the GLX implementation
Closes: 904486
Changes:
 glx-alternatives (0.8.6) unstable; urgency=medium
 .
   * glx-alternative-mesa: libGLX_mesa.so.0 is not diverted and therefore not
 an indicator to install the alternative.  (Closes: #904486)
Checksums-Sha1:
 4aa14dde500291bd04e20c68278e0b41bb1aa448 1973 glx-alternatives_0.8.6.dsc
 aeee6b4658a72f24f9b27e9dd419bc5f9c84b4f6 13224 glx-alternatives_0.8.6.tar.xz
 8604efe0f998903fc99693a9640b808cc71f2ab0 5565 
glx-alternatives_0.8.6_source.buildinfo
Checksums-Sha256:
 de454208fe0f2de7214f4cc156e9a9ed6dd299762d36494dcafe522ed99c01b6 1973 
glx-alternatives_0.8.6.dsc
 f45d946aad33b0bb922efbbad4195e343f02a914dc8833073480bf52ed09c3c1 13224 
glx-alternatives_0.8.6.tar.xz
 d9263072e28eb6f7bf15b4ae7a84e314e26fa7e083070a4529b05ea02163fc16 5565 
glx-alternatives_0.8.6_source.buildinfo
Files:
 aecbb492f83f7ea17edcac90053384e4 1973 contrib/libs optional 
glx-alternatives_0.8.6.dsc
 77768f6259f9f16b8e6459d8213c0f34 13224 contrib/libs optional 
glx-alternatives_0.8.6.tar.xz
 532e1fa14c5869117289ade6bfc7d3e9 5565 contrib/libs optional 
glx-alternatives_0.8.6_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAltZuOcQHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCMPPEACESn5Hud4gywbD1N/xZY7S+W6nsuQYK1Gn
vYjO19uM9zB77fIajMdnG8OfgOu/8Uk+04PXxcYg1hx3ARLaiYhg78ix8zsL+ppr
MsRKu4Mx0JL8liB1pfROBbusX9E1twCe4D/9a4TBjpUhl5sglzyZLKTp3bvqSBmj
Oka5ZlHssvsC8NBgTZfNQvi3se9V0xuZ+vTVcoyPeV5bXDnu+B9ZpDNil8QhtTul
a3djW8Gudzixy1H4Cvsvu2EMYhsaaAnKFxQxnz3bzrW1qOwq6TU5Ke9wM5xrOE+c
7Y1Jr5j48EZKx8N2iWdvFM74BfjHGCJzyKycQHizaJg0/TZ2GZWtGEhb6XUOvNAA
d6pKZtDBOcn/qHwHp53ZUIv8TpuYVFgRL20Ti2NzC5HD6luSR0POn2nl9Fx7iItJ
MtkwdQsVFG9Zhha5SyQOyICVAyiBUAMyBw3VbZyLLhwcFf6iTwaiszav7IhSnF5Y
p0fZhFTIpG6ltsJmQAkKi5H5oreh+INJTMLxR9uryj4EXaYMbo7dh5k1HudozzIz
OVilRmojkImcwz7iliUYTFyOofcs1o11SswLM8uZQsK0fG7XAnswRsWwuA1CVCsf
tF6o2kQUs4DZpShrFQYq05b/xoSxUTu9iMTcs8ETxLOu3tXV7Gngl4ljY0iWiM/h
KndE1N9o9w==
=MhhS
-END PGP SIGNATURE-

Accepted glx-alternatives 0.8.5 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 18 Jul 2018 19:30:23 +0200
Source: glx-alternatives
Binary: update-glx glx-diversions glx-alternative-mesa glx-alternative-nvidia
Architecture: source
Version: 0.8.5
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers 
Changed-By: Andreas Beckmann 
Description:
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
 update-glx - utility for switching the GLX implementation
Changes:
 glx-alternatives (0.8.5) unstable; urgency=medium
 .
   * Avoid confusing diagnostic message if no nvidia alternative is available.
Checksums-Sha1:
 27e0758fa8cf9091cb0012ea3253b749994ae8bb 1973 glx-alternatives_0.8.5.dsc
 1688841693f38f039afa582744b016efa5c5a86e 13172 glx-alternatives_0.8.5.tar.xz
 6398dbdd1aa6d819b2f1ecd9afe2a6364931c59f 5438 
glx-alternatives_0.8.5_source.buildinfo
Checksums-Sha256:
 88f1193b11b68189e199a3412c9d3367accd5c4f1dae9ebce7f07ca1bf1bf59d 1973 
glx-alternatives_0.8.5.dsc
 2910dc54ce5d883d84eb757e372f2376f3d0921048960bc27d687e774ca21163 13172 
glx-alternatives_0.8.5.tar.xz
 551d6da073526b3a503d62219b9aff2ddbf491ff357f8b5bfd19969196467bfe 5438 
glx-alternatives_0.8.5_source.buildinfo
Files:
 18b48cc04f80cb4e5ca5a035916039cd 1973 contrib/libs optional 
glx-alternatives_0.8.5.dsc
 7e53d74f6986ed03e32294ac29cf3abf 13172 contrib/libs optional 
glx-alternatives_0.8.5.tar.xz
 45b12d923d1f6b6c182e8bb0a145c3c4 5438 contrib/libs optional 
glx-alternatives_0.8.5_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAltPexIQHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCPBfD/9LLaNgAtStSBZdm4KvkAwAePmJcJtDd8SY
J3IW50BFls82y87BXZwKSVVoIEcv5Y0HaHRFcPu9Hl6VVS1HdMB+mNSbflMDa/B5
m6eaW16OyilVmzIZB8D77qA4IAyICVaYNVXv8CxV4mUpXOQqOFaHL7XSoSrWs4pO
ZFGoagcas8PRoq7VZK4gIfwzVa2QDw6gaZTcpDh2QFtWLvxzlF9Szg76P9pC4cWy
E0rG+RW2BS7odDHsVW+QY3XxOnWboJa50KvuTJeXT+N/Btyhu1DUWVB8jegkvxVn
X/WXHiPWmzHMkrFBHIWpFeVYkK+T0balfDmwbwh9DPVSzp6F85vn3aCzapoY4ozu
uuiRwHGIhf5MbBSnh4CkcKAzJLEeHPKQq5wyhMpgSTvX67Iw7nEE6WaGVT9wxDzQ
7u+kw52ZRDv300oa/+O7uW5at9IeZUEKJE6f4GDJ59LMMlKQdCH/xt+es8JxE0hv
hO6JlMJRT3yh4JfiIaAHFyejMYgsGZ1koLK8OFn4r0VnhDM8yp26FuGir2HYjTGE
XR1Ju87Xy6AcbbMMePdhbmZpu2PlUX0yym4dWZx3IlUgzSlim1ArslGE04FnmUBn
Fznt9ZJPMhG4Frc7/BL5hyYFe0EKN6T47tK36pV5+YF3Vo5IulDF83379shGriDt
MeBNKtmRiQ==
=u7xv
-END PGP SIGNATURE-

Accepted glx-alternatives 0.8.4 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 16 Jul 2018 16:26:25 +0200
Source: glx-alternatives
Binary: update-glx glx-diversions glx-alternative-mesa glx-alternative-nvidia
Architecture: source
Version: 0.8.4
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers 
Changed-By: Andreas Beckmann 
Description:
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
 update-glx - utility for switching the GLX implementation
Changes:
 glx-alternatives (0.8.4) unstable; urgency=medium
 .
   * Add diversion and alternative for libGLX_indirect.so.0.
   * Bump Standards-Version to 4.1.5. No changes needed.
Checksums-Sha1:
 9a6d5e01fadbd28a4515022d8ad0beb940abedf5 1973 glx-alternatives_0.8.4.dsc
 7213eb7d68bf6a566e5e0d57d8558c4f4521dd48 13116 glx-alternatives_0.8.4.tar.xz
 40987eb39acd4c2e75f4baf8c4f8fd8ab8639acd 5485 
glx-alternatives_0.8.4_source.buildinfo
Checksums-Sha256:
 da0711befa902e6dfebd678925b536d3ea92fedbe0dd55902d15fbd55dc7ae85 1973 
glx-alternatives_0.8.4.dsc
 c74cdb2811fc53aba2701b942dbb4fdf9150f9db76dc1bbfafb26a39c3ab5984 13116 
glx-alternatives_0.8.4.tar.xz
 8d141bb09242fe66b305625fdc04ce1fe80e117612d5535ec95471ec83979029 5485 
glx-alternatives_0.8.4_source.buildinfo
Files:
 7cf5bc833bcbc9fb107c9023b561ba64 1973 contrib/libs optional 
glx-alternatives_0.8.4.dsc
 f53c2a5a7f271bd59af3bd3d1df42ff2 13116 contrib/libs optional 
glx-alternatives_0.8.4.tar.xz
 e232b548cc255a0f3d30e39a20be2655 5485 contrib/libs optional 
glx-alternatives_0.8.4_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAltMrHEQHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCLIWD/0SWihAngjHi6PHTa0W7BbcHSWvUzQzvmhG
LDs+s7NeI5IkvRcZZc9JSdmlSZzt/S4/r+/5RhVCTkLRC2QxVazy1qQmqKbj8vJh
i8pRYHoQi+yDK5uY0SCh3bcnAaP6RpjGBhAodxAXnAQnP5K9IKyi+V3euGJUzH3F
roHEbxaU28hLN6azZ1MmBSeSNXMmmY18Qn8vst+Momg4B+fSlqFgkp3z97drpaS7
oD+vs1OVp8RsFs/dS1b1TxnMSfcwVoNSGYu/ap0jmWIHb59sY3ulx3FEEbq+CVvf
CZzBwY3XubTvK0/yYqxxa1CZFkTrgjXmCi/T7eIGPDgNfzw7Cokc+7y0oUlzLDlM
6als5nbJLy47x4hZodalRtGzIUM9r8bhKGE7rCMOAn789riOcHWb9DRafD9ajGgL
OulBnnAIxBJDYVZeUE7t706Wo+c1tMU5a8JaYTrUC/sdoccDlutxYcnyXfKVb1Vo
G5SdENWQnWSrs2V8Apc4SCHXb1mEG0ZjgER5TS9+LrqANTGkoqojmejp+XGCEFom
H7SEGYY/mNJtU3rIOQErL5HVN8nkfdddpqIIj+4vl5mvoUgiokLbKWNLGKHF9+BB
9jVu66PyqlG4fBk9gTSUDNqT2JX/bcddzxWNk3Ll/IR5wZG+Ca6A706c/TfppFES
emhj9/gLDg==
=HWdB
-END PGP SIGNATURE-

Re: Kanboard and alternatives for mentoring

[Tollef Fog Heen]

]] Daniel Pocock 

> Even if DSA didn't grant access to the instance you run now, would it be
> considered easier for you to support extra, identical instances of RT
> rather than supporting Kanboard or alternatives?

That depends on what the alternatives are, but I think that's unlikely.
We'd like somebody else to run the service since we already have plenty
enough to do and there's no real reason for it to be something that
needs to be provided by DSA.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Kanboard and alternatives for mentoring

[Daniel Pocock]

On 21/02/18 20:39, Tollef Fog Heen wrote:
> ]] Daniel Pocock 
> 
>> Another possibility: DSA already run RT and there is a Kanban
>> extension[3] for it.
> 
> I doubt we're interested in making the RT setup generally available for
> people to create and sign up for queues and such.
> 
> (Speaking with a DSA hat, but not for all of DSA as we have yet to
> discuss it.)
> 


Even if DSA didn't grant access to the instance you run now, would it be
considered easier for you to support extra, identical instances of RT
rather than supporting Kanboard or alternatives?

Regards,

Daniel

Re: Kanboard and alternatives for mentoring

[Tollef Fog Heen]

]] Daniel Pocock 

> Another possibility: DSA already run RT and there is a Kanban
> extension[3] for it.

I doubt we're interested in making the RT setup generally available for
people to create and sign up for queues and such.

(Speaking with a DSA hat, but not for all of DSA as we have yet to
discuss it.)

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Kanboard and alternatives for mentoring

[Daniel Pocock]

(please reply on debian-devel unless your reply is very specific to one
of the other teams)

Hi all,

I wanted to share this discussion with the wider community as Kanboard
has appeared in two different teams (DebConf and Outreach) and it also
relates to (or potentially duplicates) the functionality of other tools
like the BTS or the RT system used by DSA...


On 21/02/18 14:05, Antonio Terceiro wrote:
> On Tue, Feb 20, 2018 at 11:40:00PM -0500, Louis-Philippe Véronneau wrote:
>>> - we probably need to get some feedback from DebConf team, they already
>>> discuss[1] it, maybe somebody will be willing to comment in this thread.
>>>  Two specific questions for DebConf team: are you happy with Kanboard or
>>> might you use another solution for 2019?  Do you see a possibility of
>>> running a shared instance of it or do you really want your instance to
>>> be DebConf only?
>>
>> I've been using KanBoard for a while now, both for DebConf and for my
>> job. I'm also the one doing most of the admin work for the
>> kanban.debian.net instance at the moment.
>>
>> I can't speak for the DC19 folks, but I like KanBoard a lot. The main
>> developer is doing a lot of work and KanBoard keeps improving. The
>> available plugins are nice too. Overall, it seems like a mature project.
>>
>> We are currently in the process of migrating the kanban.debian.net
>> instance to DSA infrastructure. DSA has been very responsive and the
>> only reason this has not been done yet is that I don't have a lot of
>> spare time these days.
>>
>> At the moment, this instance is hosted on the personal server of an
>> ex-dc17 team member, and thus not suitable for massive usage.
>>
>> Once migrated to DSA infra, I have plans to make it available to the
>> whole Debian project. I have to talk with DSA about it, but as I see it,
>> the easiest path would be to use the Gitlab plugin and to let people
>> authenticate using their salsa.debian.org account.
>>
>> If I had to give an ETA on this, I would say it should be done in 3
>> months? My university semester will be over and I should be a DD by
>> then, making it easier for DSA to give me access to a VM.
> 
> FTR, gitlab supports kanban boards for repositories where issues are
> enabled. maybe using salsa for kanban boards would be an avenue worth
> exploring instead of maintaining yet another service, since salsa is
> already being maintained anyway.
> 
> of course, KanBoard being a specialized tool, it probably has more
> features and is way better than the gitlab kanban. or maybe, the gitlab
> kanban is Good Enough™ for most uses.
> 


Duplication of effort in maintaining these things could be an issue.

Does the issue tracker in Gitlab duplicate the BTS functionality?  That
could be a reason not to enable it and simply run Kanboard for
activities that don't really intersect with the BTS content.

On the other hand, in the Outreach world (GSoC and Outreachy), there may
be cases where an intern is working on some issues tracked in the BTS as
well as some standalone issues.  For example, on Renata's board[2], we
create tasks for small things like asking for feedback from the Moin-dev
mailing list, that isn't a task that would go in the BTS.

Another possibility: DSA already run RT and there is a Kanban
extension[3] for it.

As mentioned in my blog recently, I would also like to encourage a
student to develop a GUI that can interface to multiple[4] issue
trackers (BTS, RT, etc) and aggregate the issues in a single Kanban view
on the desktop.

Regards,

Daniel


2. https://wiki.debian.org/RenataDAvila
3. https://github.com/nixcloud/rt-extension-kanban
4.
https://danielpocock.com/worlds-largest-kanban-board-with-free-software-communities

Accepted glx-alternatives 0.8.3 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 02 Feb 2018 01:57:38 +0100
Source: glx-alternatives
Binary: update-glx glx-diversions glx-alternative-mesa glx-alternative-nvidia
Architecture: source
Version: 0.8.3
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
 update-glx - utility for switching the GLX implementation
Closes: 879041
Changes:
 glx-alternatives (0.8.3) unstable; urgency=medium
 .
   * Divert libGL.so.1.7.0, libGLESv1_CM.so.1.2.0, libGLESv2.so.2.1.0,
 libEGL.so.1.1.0 that will be used by the next libglvnd upstream release.
   * Update validation of the diverted libGL.so.1 symlink.  (Closes: #879041)
Checksums-Sha1:
 dc0bb53ec9bca9d5dab5fac8e690e2a7db3924bc 1973 glx-alternatives_0.8.3.dsc
 633595be16433be04b9267148686fbdf5a212acc 12972 glx-alternatives_0.8.3.tar.xz
 b3a8ff49a41e72add260750c6463ea9e4f9799a1 5249 
glx-alternatives_0.8.3_source.buildinfo
Checksums-Sha256:
 17c144eb423309c3329298719043a2375e028e7c33be81648eedd499853799cf 1973 
glx-alternatives_0.8.3.dsc
 0752ba89ef7763637f1ad9caa0d8a731c509a0f969dbccef3f18547c6c2feddc 12972 
glx-alternatives_0.8.3.tar.xz
 40db2d2c568e4cae58ccf6cdb69b4aee26e50b09be7e49c22c6cb21a7e42a9c7 5249 
glx-alternatives_0.8.3_source.buildinfo
Files:
 46022166e7253fe13799fa56acf7e6d5 1973 contrib/libs optional 
glx-alternatives_0.8.3.dsc
 64479ffd5cfc6fe700abb56f188829ff 12972 contrib/libs optional 
glx-alternatives_0.8.3.tar.xz
 e2ad92d53f771fbce8cd754090edaf83 5249 contrib/libs optional 
glx-alternatives_0.8.3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAlpzvd4QHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCIiOD/9QTRohqATiuZG0KI1LALTtiy192f0ED9OZ
WrzrvFOKYF7gtgdz8jjr0sMVm/Hlb4KFBIhDByOYIQj1cgXvR8k20bqhi0mHkvha
6QJUP5YpxxechU7jZ3hE/EeW4JrQ6xiPqj6CnZtTqq2l9emhtgIiPASI9pzuN8ZT
puvK5viIhERnkJ9WtC56Ndv/+nrGU5uz9+QnR0qglrRQATeEIEhuWds8JaAXeDXC
xolQO9vMq2tom4wFwUdXzPN9dkXHeRTlfve8stluPeorDiil0rcUnoU6yQWsEoCp
DTxVrWew5beR+grp92T7haOgZWcWii9QvegiGzC89VNBefpLfo45ky+Pa2dQ9U91
73ZJbbkUHObG/n6Mke8DH7emhYxOL64zGMVgTMLNd5ErH7RknTlirwfB0g+BOGed
vNWxitMjfQgr0mZwInPeVS03EYhENPPgz4UZFX6FOQINfZXyVzuZPxZlvHnkXgs6
DhyohjN2sBu1InKjNPNlppKQroPLu27wMKPPjlQRL2EJCGDaxCW012mL/oeyOxus
LrFm1kKk2ko/6MJBkLENvvcRdGcrrdAm2OhrjgVWC443NMjYwidu3A2V0o8OskWa
kQ4ewzGLQ2nanRlWsiubRt3vXqiQ/q4hfqyuGsEM7u3BxcIzupXKQ6b4B1zhCtPU
Y1DnKHizVg==
=eX8D
-END PGP SIGNATURE-

Accepted glx-alternatives 0.8.2 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 26 Jan 2018 21:51:10 +0100
Source: glx-alternatives
Binary: update-glx glx-diversions glx-alternative-mesa glx-alternative-nvidia
Architecture: source
Version: 0.8.2
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
 update-glx - utility for switching the GLX implementation
Closes: 888461
Changes:
 glx-alternatives (0.8.2) unstable; urgency=medium
 .
   * Remove support for MESA libraries in /usr/lib//mesa/, the libs
 never moved there.
   * Remove support for libGLcore.so.1 and libnvidia-tls.so.1 alternatives,
 only needed for 173xx and older legacy drivers.
   * glx-alternative-nvidia: Provide the libnvidia-cfg.so.1 alternative for
 bumblebee and cuda-only users.  (Closes: #888461)
   * Bump Standards-Version to 4.1.3. No changes needed.
   * Switch to debhelper compat level 11.
   * Switch Vcs-* URLs to salsa.debian.org.
Checksums-Sha1:
 07c2ae0ca2611ad76a5183f4aa42859bdd8dfde3 1973 glx-alternatives_0.8.2.dsc
 b0276cb673953d3d8cadb441443b1f793b4046b4 12796 glx-alternatives_0.8.2.tar.xz
 341f07abc2f20d782c9e77970db3f3c911090c29 5294 
glx-alternatives_0.8.2_source.buildinfo
Checksums-Sha256:
 8e1fef554581d726127cadbde2ef66cc78a41c9d764498ad7eccb402d019b3a9 1973 
glx-alternatives_0.8.2.dsc
 654ca61ad38facdf25f564d04e2629871d4a10c44af93c276d8f9d63ae6f11b3 12796 
glx-alternatives_0.8.2.tar.xz
 609482f73e20ff58f43163f62a0664f9201c9c66af9a941bf4810c9967bf6017 5294 
glx-alternatives_0.8.2_source.buildinfo
Files:
 196c56a3dfb2dcea4d980e972a76edf6 1973 contrib/libs optional 
glx-alternatives_0.8.2.dsc
 88c0a32b7a73194f5d31077979390502 12796 contrib/libs optional 
glx-alternatives_0.8.2.tar.xz
 7fa3b7479d6a3e04cdbc60aa9e53bd11 5294 contrib/libs optional 
glx-alternatives_0.8.2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAlprlT4QHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCGwmEACH0ghZ5SSCuVUsGTAzJAetQ1llTDCus68M
JevgsAyckjcAdJB6Ay+zgWfS9gxFDrimCpRMM22Of6asWblZwiYsLE4FOQJrkKWC
KzL4QKnmx+lT+PIcc9O3zYOfTIU5Dq/eZKeSDzGeu66huizBnS5/Y8AIDewcgl4A
oKaxzH7Q2VqzD0nbpkNFX9bKjScOiOg4OUqXACC9NaI0C0IGMRqnK1fud6tFQhI3
JWa4abZIh1ZsoaesHRvsV0AR21ivW0T14HBhTWyMTgO3Q0qTwLLTHFufPnQVtUXu
1aWWiuQU9+02vJesmj6/PP6EmKM6DBvu3UWsKaKjsIqHXroj1Nmc/6h3PjRGZb6H
8SC+2RFaMkuppNhdJdVxeJutzHAqiRlnjqAA7CnVNlpDrmEmat+KsWG1oghIxNou
Exh8Yri+Zsf0tcpXwCu3lJo2AfpFIhjsHuse8rzcD+/pifd4Ex/PyojtqzdzHmE3
d7fOtmmfHX88XBqLu3bqk8zEKWBT/F2oXLERkepTb775cgaazNcsu+wo5i1ogQEA
Nqm362srikhZnC3vV9WUGFWoR3BDcV/e5MlaHR8OVsqm1ZUG0q16W/0CTkvWeLRP
BeAXS5/9xCu7qLmp+MejggrW/E5uBSu5otIriQnQQ7Usj90XwuRDuaK7ddSt8Ati
2UYZ/ThyQQ==
=WyzE
-END PGP SIGNATURE-

Accepted glx-alternatives 0.8.1 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 17 Nov 2017 06:00:23 +0100
Source: glx-alternatives
Binary: update-glx glx-diversions glx-alternative-mesa glx-alternative-nvidia
Architecture: source
Version: 0.8.1
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
 update-glx - utility for switching the GLX implementation
Changes:
 glx-alternatives (0.8.1) unstable; urgency=medium
 .
   [ Andreas Beckmann ]
   * Bump Standards-Version to 4.1.1. No changes needed.
   * Set Rules-Requires-Root: no.
   * Refresh debian/copyright from dh_make templates.
 .
   [ Russ Allbery ]
   * Remove myself from Uploaders.
Checksums-Sha1:
 d8fb524e781e26db25daa6bf16ebda47f7294607 1987 glx-alternatives_0.8.1.dsc
 cdd4580f44e56e1e2df869c7a19943f1a2ff400f 12724 glx-alternatives_0.8.1.tar.xz
 63b1af63d817cf5e12d75c2faa6e73bb321f2947 5274 
glx-alternatives_0.8.1_source.buildinfo
Checksums-Sha256:
 fb6c72c7a3d325bb8c4de0aabe85a5657a018f5e90e6bcea1489d34c38544d9d 1987 
glx-alternatives_0.8.1.dsc
 0e144411df9b47f23d26cc41f23ad39ac7e2697cb210d7e2826df05f4fc58d7f 12724 
glx-alternatives_0.8.1.tar.xz
 2966497fe2ece1cf1c0306025f3063aadeb2b4459b34074f6bf55a52447872ea 5274 
glx-alternatives_0.8.1_source.buildinfo
Files:
 6751ef0c63f6f1055dbf16816e2fe728 1987 contrib/libs optional 
glx-alternatives_0.8.1.dsc
 9c68e6ae37eca6a305303c15267b4f7a 12724 contrib/libs optional 
glx-alternatives_0.8.1.tar.xz
 bb4b8f085ff0814c18a6dd1b99d3133c 5274 contrib/libs optional 
glx-alternatives_0.8.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEE6/MKMKjZxjvaRMaUX7M/k1np7QgFAloObXoQHGFuYmVAZGVi
aWFuLm9yZwAKCRBfsz+TWentCOl2D/9Vh/tC8ViPsgFwmZMj3Wmp4QduilXeXELq
e7cnov+Ea0OfQcE3EXWJXj/iZZzj5MhbvHG4y+11Cvjzk1lI/sZYJZUpPA0fwj1G
AN8ZX6VacFS5MjJduGRi+W27fm2mHmX8WPgi+PJn8gfz2X3Ej6uxOO7E70YUe9Jo
Zlzrnt/QxuIWZQRHR+8EzpRxalTavycsEf40tpo1b3BFBSVPdo2cvHwKgAsGIkHk
R78ilT7VCMDf+DhFO4o2Ehha6RWW2yIdxiaaxP1fnOlYLfVaREaPmRDeMpbs9LYJ
63J7sGLBaLHKGOt1816PFWy2hEZpVk0PcZNZ/wl7GWUrl0w4klHYayiClJ15/3Jr
59sC4jnnGvlzVJIWDSLMwG+kXAodlWawwZ0to1ha5ddhVDdlfeOq2Oqv6dT2Gh6N
nvtb1H3Mk776ogm7+tkie6dJLbl/HiajPTJ/Y2ZlHVWtD+INBcAJFk9FN0yki2ke
tMJNw6F/XAQ5nSeuxU8VtMvCoNCDnOxkf60YagZ9Ywb2X76XtAQChUiFCKC08iJw
VTm+mRqUzi0M2LZOZ2n8CWGmRTXl49iYFN/ZEefv6QmtwC/qJpgMkomgZ9ZVwFNX
hiO05boMtcySbQa2V6wGaANbkyRFdhgTI3pShTEAcURHExfk0EM5qkjaVrE+8ltU
vuIC8KvsuA==
=pJaf
-END PGP SIGNATURE-

Accepted glx-alternatives 0.8.0 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 13 Aug 2017 07:51:40 +0200
Source: glx-alternatives
Binary: update-glx glx-diversions glx-alternative-mesa glx-alternative-nvidia
Architecture: source
Version: 0.8.0
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
 update-glx - utility for switching the GLX implementation
Changes:
 glx-alternatives (0.8.0) unstable; urgency=medium
 .
   [ Andreas Beckmann ]
   * glx-diversions: Divert libGL.so.1.0.0 as shipped by libgl1 from
 src:libglvnd.
   * glx-alternative-nvidia: Preliminary support for libGL.so.1 from libglvnd.
   * Use explicit interest-await triggers.
   * Drop glx-alternative-fglrx.
   * Switch to debhelper compat level 10.
   * Bump Standards-Version to 4.0.1. No changes needed.
   * Update Lintian overrides.
 .
   [ Luca Boccassi ]
   * Add manpage for update-glx.
Checksums-Sha1:
 2249136bddee9dde8c641f3dd9cf6a4d052c7809 1979 glx-alternatives_0.8.0.dsc
 306e1f5517665fdaf89aa1a0dbbfc93072620992 12388 glx-alternatives_0.8.0.tar.xz
 cd219938c90b636f4e53626ea79d206a6e51d2f5 5113 
glx-alternatives_0.8.0_source.buildinfo
Checksums-Sha256:
 f58c49bad45351d3f35df47f1fed3cc2bf06947f4ed668e39882d5d144e8017e 1979 
glx-alternatives_0.8.0.dsc
 5b3eb8acba1e0f224452bb537f23cfa961b0e77e542ff98813002c26297ff83c 12388 
glx-alternatives_0.8.0.tar.xz
 9d65812f11cb12a808a89ab5f2789109b1d17994b340c61ec2baf3239846f8a8 5113 
glx-alternatives_0.8.0_source.buildinfo
Files:
 71457df598e7d819cefb8f3e335e247d 1979 contrib/libs optional 
glx-alternatives_0.8.0.dsc
 a40790825ce29e5a457c828556f64491 12388 contrib/libs optional 
glx-alternatives_0.8.0.tar.xz
 02eb917a580a602c4bad34bafe1c18cd 5113 contrib/libs optional 
glx-alternatives_0.8.0_source.buildinfo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJZj+owAAoJEF+zP5NZ6e0IjecP/Am8mv3sqjTSqUfnj9qQfyYe
8vx3ijGG8GGgPB4d5jVAIe+pjz5regPpWcVCVdE0GKgr9i3pAr+KpVaAZgBAL49r
AiYo+GNmvuE5K09WAl3qRElRiRH69VX65c+uTuHeZF2a07h7gESl2ck2IgblcISU
TCDgM/elq1wy6BJxvOa0G61PVhTSI+eDNPAuuXkrWMEVjdCmLCWa40IzDN+mP+/+
krczx97Stpu7764Pxc8MhJMp5CqUp58tA8KMdMj/IHhPfVUlBh16YK0bYnThP+v5
NHkiYipnAIGkMqUkTG+gbhWZ6xgYBe7bLui/Pw2FHS8YM1OOg9ei6YZduW3Jmit0
YRW5yj6HZGwWA8nMybyiLB1sB86HDCeSKDBZmwKonjDtk5pk6t1orPL8bVo3dK0L
SCRh+Eqm/LzH2EenWGzHz2a5/VmU6aqwIqtToSeRTtQe8EHU3GVmoDU13Q2iGtrZ
y3f/HNDIjxnbVLtdG0POyoX5LMUy2OoqbBHmCNt3SheIJdk+1unjOzZxhlEPyp+y
YrA+wVWT+ilMFlBwNH4+Jb4rATWKRCLYXh0hrvJY04zsBiBG2ZQBRmklAhxp6VcI
9Axw6F8hhw8kSTDTevLOA+Qdolq2Vzofr19ymeXPzvqBox2CWK9FpwWPztzcTtzK
2B5cuGV4+aAADjzUjQm7
=3LAD
-END PGP SIGNATURE-

Re: gitlab alternatives for a debian instance (was Re: manpages.debian.org has been modernized!)

[Scott Kitterman]

On Sunday, February 05, 2017 10:05:13 AM Pirate Praveen wrote:
> On ഞായര്‍ 05 ഫെബ്രുവരി 2017 04:07 രാവിലെ, Jonathan Dowland wrote:
> > I'm getting deja vu, this has all been discussed already on -devel in
> > recent months, please check the archives for further details, I'm fairly
> > sure people are already working on this (Pirate Praveen was at least).
> 
> Just for the record, we are blocked by
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844943 (otherwise the
> packaging is mostly complete)

And that is waiting for upstream (and probably will be for some time).  
Integration with the current version of html5lib may not be possible.  I think 
it's likely we'll lose python-bleach for this cycle (and thus django-html-
sanitizer - which I maintain).  Don't hold your breath.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: gitlab alternatives for a debian instance (was Re: manpages.debian.org has been modernized!)

[Pirate Praveen]

On ഞായര്‍ 05 ഫെബ്രുവരി 2017 04:07 രാവിലെ, Jonathan Dowland wrote:
> I'm getting deja vu, this has all been discussed already on -devel in
> recent months, please check the archives for further details, I'm fairly
> sure people are already working on this (Pirate Praveen was at least).

Just for the record, we are blocked by
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844943 (otherwise the
packaging is mostly complete)

You can always check
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829046 for the current
status.



signature.asc
Description: OpenPGP digital signature

gitlab alternatives for a debian instance (was Re: manpages.debian.org has been modernized!)

[Jonathan Dowland]

On Sat, Feb 04, 2017 at 02:14:20PM +0100, Stig Sandbeck Mathisen wrote:
> I've noted the presence of gogs (https://gogs.io/) and pagure
> (https://pagure.io/pagure), which look to be completely free projects,
> but haven't tried any of them yet.  https://rocketgit.com/op/doc/compare
> has a comparison matrix, but with bits missing from all other than
> rocketgit, which I didn't know about before I found that matrix.

I'm getting deja vu, this has all been discussed already on -devel in
recent months, please check the archives for further details, I'm fairly
sure people are already working on this (Pirate Praveen was at least).

If there's anything further to discuss on this topic can we at least
set an appropriate Subject: going forward?
 

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Bug#840361: ITP: fonts-pt-astra -- metric-compatible Times New Roman and Arial alternatives

[Andrew Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrew Shadura <andre...@debian.org>

* Package name: fonts-pt-astra
  Version : 20160928
  Upstream Author : ParaType Inc
* URL : http://astralinux.com/fonts.html
http://www.paratype.ru/cinfo/news.asp?NewsId=3469
http://astralinux.com/ofl.html
* License : OFL 1.1
  Description : metric-compatible Times New Roman and Arial alternatives

PT Astra Serif and PT Astra Sans are metric-compatible replacements
for Times New Roman and Arial fonts. PT Astra family of fonts have
been developed by ParaType Inc for AstraLinux distribution.

Accepted glx-alternatives 0.7.4 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 09 Oct 2016 10:42:21 +0200
Source: glx-alternatives
Binary: update-glx glx-diversions glx-alternative-mesa glx-alternative-nvidia
Architecture: source
Version: 0.7.4
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
 update-glx - utility for switching the GLX implementation
Closes: 803793 807148
Changes:
 glx-alternatives (0.7.4) unstable; urgency=medium
 .
   * glx-alternative-nvidia: Bump some Breaks to account for newer
 nvidia-driver(-legacy-*) releases in stretch.  (Closes: #803793)
   * glx-diversions: Depend on glx-alternative-mesa (and not the other way
 around) to ensure we never end up with diversions but no alternatives.
 (Closes: #807148)
   * Stop using dh_installdocs --link-doc and clean up symlinks on upgrade.
Checksums-Sha1:
 3b53a3d25b0a978c8f280794178e2b3dbc138f43 1978 glx-alternatives_0.7.4.dsc
 f7c9714f2e694f0c3ffa4318e70d44ed1dd0e8a0 12496 glx-alternatives_0.7.4.tar.xz
Checksums-Sha256:
 ccf82c1c50aa66cb983bdc4d6844f73374cb8e26896ee1996387f58b008979b9 1978 
glx-alternatives_0.7.4.dsc
 1ee0983a7d4ae723148915ea629a4834670f4c439007d7a1fd9cb81f827413f7 12496 
glx-alternatives_0.7.4.tar.xz
Files:
 f6cd4f922372af6f46edc693b27eff9d 1978 contrib/libs optional 
glx-alternatives_0.7.4.dsc
 c4a0fcee88be9c1e866bebf9aa0274a9 12496 contrib/libs optional 
glx-alternatives_0.7.4.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJX+gPIAAoJEF+zP5NZ6e0I1BwP/RoyQTNdNGJxzYzXuHK/Bfny
y/DMi5SRnoOr+0RkSNpxGI+k6200cbTkCd8uTOJuSkte6A5kn1OrX63VjSTM4H88
ffBCzdva3xn0WD0uK6ly7UZPFWm3CYmybo16HwtPbz7OYQm0oQisEf7iLdCl8IoT
xg9YD7r9kGR/g9gEy7uMrrNXeqRWA99C0vc9gcXRoO4cZaTWSd9ETU+rvFL4dQkr
dgythsHXkyzF/Wg/OeY7Iq+WC2UleGhkV6kObdkgWpWeO5taZ1aQ+PWTDgGPRLOg
CzMX0iyIcPYvUL76+A2eCLGMfvrSptD3+bLDy5DO1YPa1EW9K6VjOSVStaZRrMY/
kyu/KJ+g1Ou6rXzp4m427e3oxT/C+7CFoZvkuqURsyatmrYkRMicpQShNV/vSaDs
X6BvDq7uBr11yjKmNsMbSJZyvaOfCQbSga1QOqJGh9qhtz/8z6Swcxz2kzOxr8UV
uq49Imgn2HjyqkVEm9UV9hqqw9RXO6Ug8LdtMX3FsPPtSxhA9eEMyGf5g8qrivsK
cfLA6QbhPVVixqfMzgzAR9VNN5p4+pf+IQc+NnLAMGbMs/nyg9h4mvUMLhD+55cN
EWyzWzdMIun8m4UxZujeISP2jBnQnG+bdwZ54nJ0BHXHSbHex14H7RxRUxCYunrv
zYiqDxd2UaxMogU6tC+/
=NHrT
-END PGP SIGNATURE-

Accepted glx-alternatives 0.7.3 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 09 Jun 2016 14:18:40 +0200
Source: glx-alternatives
Binary: update-glx glx-diversions glx-alternative-mesa glx-alternative-nvidia
Architecture: source
Version: 0.7.3
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
 update-glx - utility for switching the GLX implementation
Changes:
 glx-alternatives (0.7.3) unstable; urgency=medium
 .
   [ Andreas Beckmann ]
   * Bump Standards-Version to 3.9.8. No changes needed.
   * *.postinst: Activate the ldconfig trigger, don't run ldconfig.
   * Stop building glx-alternative-fglrx.
   * Update Lintian overrides.
 .
   [ Luca Boccassi ]
   * glx-alternative-nvidia.postinst: Activate restart-bumblebeed trigger,
 to stop it erroring out when libglx and the nvidia kernel module
 change while it's running.
Checksums-Sha1:
 7f3e8ec98287d4e0fbacae706ed31bb418aa69bb 1978 glx-alternatives_0.7.3.dsc
 43e017a4000a905f81dbbce8e607d2f569114a40 12276 glx-alternatives_0.7.3.tar.xz
Checksums-Sha256:
 38f7edf9a4456a9cfee967a14ee31f90d97d58b175705aa340536f1a12054b27 1978 
glx-alternatives_0.7.3.dsc
 dfb4046091f189e35a4d65b7fe22c58bf8432675b69f2a3378233106333f9f62 12276 
glx-alternatives_0.7.3.tar.xz
Files:
 07aa94f43f34f78b3c4167823703d38d 1978 contrib/libs optional 
glx-alternatives_0.7.3.dsc
 ab2016cca50e14907f3b3a0ed193aefa 12276 contrib/libs optional 
glx-alternatives_0.7.3.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJXWWJeAAoJEF+zP5NZ6e0IUPYP/RCRJ6e3iVfnQ+MOfl0iAc2W
Dg8KqNF82texRQqfZpQBlXmNV1wgJILNwirpWI9wU1zZ+xiHMr7LwIWi61xagZVO
KIZ40KAvB90C77Nkpa58dUALEsmC7T6Tc9xcd4S5uDIHKl1+g1t8F/Sp8YMRChze
gC2CF+k/WRb2mVHK1WvtQpFAscdnrYauo1hVkiOUVRF0CSNherpKwcusNyzWm15x
ERIGmRZyffnZ1j2D2hB4zI5eYGFbclyIZYtAkE9YbQs27IVOdaRzBZ2kVJ5zqBcp
eeeADJ0b+kjdx3InyWV2HWJxVwWAl3vr8yePbnTi3csvpVDw9ooSuKYpxQTfTWPI
nQ1/9oCT0uLNa5gBUSduyjO8o/GI/Dg2Zmj5rDP1NL0USIcNGQz+pIfcjZ63bbSz
cGcrQVLkIuHSCD/LO7wC6Khm7WQOwK0p9xzmItYpmq6fy/nx60K5oAV/Xt06dSSK
voCbcP0DDqg+edimCjWQ+XtRnmawWqHTPs1RhI9aWnJyJ4mJxpWvSDSQW0le/Z5G
q870v5esdMi/6TFiCEJ4s/NXfzZvlytrYKgRackWiJyVg8WXZmZ3KGmj2JuGzrjk
7aeipQl3OSd+0zrwu7Ce3TzuIEyqGQePuXUCHvwcBMfPo6mLNE0Pa/rF2QA50hIF
aRxxugEES+0Botnw/8Rv
=oM0b
-END PGP SIGNATURE-

Accepted glx-alternatives 0.7.2 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 10 Mar 2016 20:32:29 +0100
Source: glx-alternatives
Binary: update-glx glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source
Version: 0.7.2
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
 update-glx - utility for switching the GLX implementation
Changes:
 glx-alternatives (0.7.2) unstable; urgency=medium
 .
   * glx-alternative-nvidia: Bump some Breaks to account for newer
 nvidia-driver(-legacy-*) releases in jessie.
   * Drop Breaks against packages predating wheezy.
   * Update Vcs-Git URL.
   * Bump Standards-Version to 3.9.7. No changes needed.
Checksums-Sha1:
 a74319c144db93a3d9e8b263c3be5f3daed30f01 2072 glx-alternatives_0.7.2.dsc
 68c7ff2ebe3f635170d69a5f7b1973a1d2bfffae 12076 glx-alternatives_0.7.2.tar.xz
Checksums-Sha256:
 a929caea2b311de72e90fa372dbac5fd1179266b3c047f27ec67f8a8219808f1 2072 
glx-alternatives_0.7.2.dsc
 94165cf9d30acd8f00fa78e56ac505e93bd3ad839a6a038ddb501cc9cf6a1521 12076 
glx-alternatives_0.7.2.tar.xz
Files:
 76aa4f62351e92f3bd82d1b0d0376695 2072 contrib/libs optional 
glx-alternatives_0.7.2.dsc
 3fc3f434c22ba84e53c3b57f00056dbc 12076 contrib/libs optional 
glx-alternatives_0.7.2.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJW4c0GAAoJEF+zP5NZ6e0Ib28P/3mlvzkwJm5T6X+hNvLs3MPa
W2uv8UgRAshzCoyYRdecUgmRHNm1xOfDNewkfVQb1piDU9L4Cch490fS8wPIxfBP
OnPVyKZdC2GeePuzQgI8kdzLyW9bMTobOY6j70BCBF6U1vLyp0/Qf8l8APMBu3KL
tvBhtHOXqfMkOz/O/CHaSpGP8MTcCSlWe+fOiBkAp+7ibhomEYizCJFXsFoyFQSQ
hEveoxN21VCkTBfDbUFpnPnyRQjd2NERX7SszWhm4hUKusLK1BLagBynMqYzS/M5
wlD+POMQ+iKxcYjhJi/QD51StXDSvmwhw52cNx9oOlnfpbjOuWeMrvtltvx9TPpD
C9+wjVE10oBQLDfmuPpPx8K4qAKAxiyOUTYa+BRNOJzFmf/MA0IMf2Ek6IsEvgtP
HXqPcKvnDS0U+P17z7KAKgxk6dDn+7mzT+mJZSNa+7H4QH6yQa4rEaP02uxGnEVT
yW2jYUq0Hh+JGmrt92CBd3M83VTOoZ0pXE36RqKk5sGBcFJ/BEH8UlNp+RI1TPlM
clOeUMO/eQyRtYV2+Ltnn3XDaCm3d27E/l1jltqyYrNj4cnxKvLzh5Rj2UDU+26w
0cPkku72Ri9zUdAIQhSRhs7+hmcZS0+BW+aeXG5Ofk2SRFmmXuYJfdUT5p7QXxLu
gmNIIfroe4x5AG2+TKh1
=lZ4z
-END PGP SIGNATURE-

Accepted glx-alternatives 0.7.1 (source amd64) into unstable, unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 12 Nov 2015 18:20:00 +0100
Source: glx-alternatives
Binary: update-glx glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source amd64
Version: 0.7.1
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
 update-glx - utility for switching the GLX implementation
Closes: 789167 804328
Changes:
 glx-alternatives (0.7.1) unstable; urgency=medium
 .
   * update-glx: New utility and package to simplify switching between
 different glx implementations. In addition to reconfiguring the
 alternatives this triggers further actions that may be needed to complete
 the switch.  (Closes: #789167)
   * glx-alternative-*: Depend on update-glx.
   * glx-alternative-nvidia, update-glx: Play some ping-pong with no-await
 triggers to (hopefully) defer alternatives setup until after the nvidia
 alternative has been setup by nvidia{,-legacy-*}-alternative.
 (Closes: #804328)
   * glx-alternative-nvidia: Raise priority of the /usr/lib/nvidia/bumblebee
 alternative from 95 to 125 if bumblebee-nvidia is installed.
Checksums-Sha1:
 b5c5312ca8974085949af5e1398aa23bb2ef6151 2066 glx-alternatives_0.7.1.dsc
 00e7ad03f5480f25b891c4e7ce2de44a8c5bed4a 12196 glx-alternatives_0.7.1.tar.xz
 18e44e7c2e44410acf4ce26034925eafe47dabea 3832 
glx-alternative-fglrx_0.7.1_amd64.deb
 55fe9a002a8a14b62b244806bd72318c20ec04d4 3168 
glx-alternative-mesa_0.7.1_amd64.deb
 980932bdfbbdf9ca1642f434df905342088566fa 4322 
glx-alternative-nvidia_0.7.1_amd64.deb
 79f4e7dca7b051a62442a33fa2c110abdd963c7e 10042 glx-diversions_0.7.1_amd64.deb
 1d8128453b6ff6f30663d99c961a3862fbf8ebb2 2690 update-glx_0.7.1_amd64.deb
Checksums-Sha256:
 38136c5a8f5366eb1b4962338e930b30c517c3ef4cec9de4963c00541df60dd0 2066 
glx-alternatives_0.7.1.dsc
 95473156b0eb4f8305483fca3a2ad950248326e2f9bf056e3a4bacc74eb77452 12196 
glx-alternatives_0.7.1.tar.xz
 5386ebcd86a3d86d666ea527e736d29f131d6ddd89b63da5cb173b7ab2e44668 3832 
glx-alternative-fglrx_0.7.1_amd64.deb
 d0dde95c28ed46266a7665cc57f6c2cb4b1a72e1597bd2226da5e83156f9d5f5 3168 
glx-alternative-mesa_0.7.1_amd64.deb
 7a32e8213f49a78f4a15a0c8ac11cba36342720d5752e726320a2d4c8ba3ce0c 4322 
glx-alternative-nvidia_0.7.1_amd64.deb
 a2791c679d794c99552a57714fe5ec80121fb9da6800f0dfaeda2b629e6cc75c 10042 
glx-diversions_0.7.1_amd64.deb
 24cbc3c44874ee4b9d6c634f71454b4495cca0c23b5171a0270f735f11f995e4 2690 
update-glx_0.7.1_amd64.deb
Files:
 0172a402a9d9182aedc056c181d5be24 2066 contrib/libs optional 
glx-alternatives_0.7.1.dsc
 d952ced2200faa30f3bd0ad4ac5ec274 12196 contrib/libs optional 
glx-alternatives_0.7.1.tar.xz
 1e25a15f161d58763255b94c590005f1 3832 contrib/libs optional 
glx-alternative-fglrx_0.7.1_amd64.deb
 3b1a07372795db38c38b89cf201bb54d 3168 contrib/libs optional 
glx-alternative-mesa_0.7.1_amd64.deb
 fa00f6ae127d158df6638d0080613173 4322 contrib/libs optional 
glx-alternative-nvidia_0.7.1_amd64.deb
 cd6e1b08c159ea952ee5f63eb103af4a 10042 contrib/libs optional 
glx-diversions_0.7.1_amd64.deb
 d5534e7a0ae1274cdcfb644297fb01a3 2690 contrib/x11 optional 
update-glx_0.7.1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWRMsRAAoJEF+zP5NZ6e0IvZYP/3l+Cdif/Nx2IWKYbC6OXdxy
+jCLAM7IiVCEifs8DfLpaCl5kjUFdIvhTTsg2VwnSsBdBHzmhbJsFrj/+xQlgnf4
vvfR7mPxM07qElP0R8P+usrrCgSJ7M9zoGDCvLsj7QZ20ZzI+NOr90wdNBG3MGbw
DZDCNDhT2UBHyiey25MMRYKjXIUB3IUhLD/PbPXtPa0zQfk+urbwPI3gcINNFfKM
CmFs6GP/oMyZ2I/lHn5cpjxFK1HnrhgT5qtJCr9BNj1Vn/2aaxwfd2PsXBWPt6Wo
SCT4aFGV8i1uUa3Xc0//6j9zhBwCIHu00wZGeQBwwMsLlsy7ZyLabhg1hr47e9yu
BXj5HTZzaSeUhcBQ9X1aYdqYvSnb3TgjEA3se/BwfryYqqBEbIL1mbBGfj2OFasr
BA+UA2YfC6SyA6zLRUCBf4+1vIBCRGlLVK1L6UOmUZxcwnC7sb8rkW75KYjX/WID
uI+X/5xbWkMoz8ScbaB54rTcP3eIDJPzQddUGhu6md5YvgWNrNlA03D0224ldo7E
v0bnu2hzc70Qk7YLlKXKG1MJES4ITZ52mc/qMV8rBRu76EDLk+DSKOxFjAkeNZs7
DEQ5I2rnxUEHenzWHe2dQYVGRknMGyKc+KDJ8h3HGDa193WIHV6OtiUnoyGZa9pl
/Rta00dSK7dg812n3GTM
=GZfW
-END PGP SIGNATURE-

Accepted glx-alternatives 0.7.0 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 02 Nov 2015 11:41:59 +0100
Source: glx-alternatives
Binary: glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source
Version: 0.7.0
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
Closes: 802597 803557
Changes:
 glx-alternatives (0.7.0) unstable; urgency=medium
 .
   * glx-diversions: Reduce dpkg-divert verboseness.  (Closes: #802597)
   * fglrx-blacklists-radeon.conf: Blacklist amdgpu, too.  (Closes: #803557)
Checksums-Sha1:
 ae8390916640e9160fb0e0b880d0053cb5ededea 1995 glx-alternatives_0.7.0.dsc
 d20192047b71f820f32c21a2cbf138c9b350e6a8 10948 glx-alternatives_0.7.0.tar.xz
Checksums-Sha256:
 93de148a535d568430a8742886c27792c55c137fea089182de153b2f0da635ee 1995 
glx-alternatives_0.7.0.dsc
 2bc171d87112b21705ba1863b711304be859c3e4858b5cfefccef401d0208516 10948 
glx-alternatives_0.7.0.tar.xz
Files:
 e6e65f5a416e990ae25b1fe965f4195c 1995 contrib/libs optional 
glx-alternatives_0.7.0.dsc
 a6086fa79920c62de86c385df4991e75 10948 contrib/libs optional 
glx-alternatives_0.7.0.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWNz8xAAoJEF+zP5NZ6e0IOsIP/1CRlA8HBb1kiUzcHBZga817
H8kgNMCBAq/2xsqhehArd6ZyvwztfYEifN90DLRlphtXU3QhwPr8CLOFmyA5hIDH
6HOF4j5p+RhGRmny+IghL0XsfkReYagsGzgGrb5jO+D0Lt1z7enT3M/g+u0a4Bf9
pDIcBNHQz1JsTeak2whbpbyUK1M+U5u8Gasja8QQnykRsIKiyblo3dIrTvoAye4T
9QDZsL0nE+MDfLmx50AZ+F4lA1oloTNQiXQxWD7VS354LGEP1zkCiiAC0Zdf/M55
3aE2s18LU3QAdV2Pz4dvmv3j03bWT+sBEp6W+g/pnwwoEtNuUvwyIE+84NXOXXm0
3FnXnQDGkhHT/CoRhc3f2xzrs+MAeIjrpUmBiVWkNK9EivZwuMYalCPO/i4NFeY1
tjcOZAMhQQbE6UjCxaEecaHjdOE79uEKHm6uLhUFRy+VIjDcG07D1Sq2njxeQaIK
6uVHqlgCTePFtVMzVZdbfxj0b4GNHF/WdHGK+nAEW0Yr2jYr3xVT07A+Stc3joC3
3lMjNTWWxCtVxXDRgaza+KX3zwHUOsPpVVI9OYGExi69UB31TK3JDCXQzosrouLx
XkkZC/orDPXMclavqwWeA+xwymCdfk2F1QZTVn3q/p1u7TqmXvYpfEkDTIxyD7HF
SimFNyDhF7KYhVYcZE4P
=Y3xb
-END PGP SIGNATURE-

Accepted glx-alternatives 0.6.93 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 21 Oct 2015 03:06:43 +0200
Source: glx-alternatives
Binary: glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source
Version: 0.6.93
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
Changes:
 glx-alternatives (0.6.93) unstable; urgency=medium
 .
   * Drop the NEWS, use Breaks: bumblebee-nvidia (<< 3.2.1-10~) instead.
Checksums-Sha1:
 a5c25f9634a00852506a2f78eccad0899cbc07cc 1999 glx-alternatives_0.6.93.dsc
 8182cecbf3cf5466a31017dc385147d4867ca510 10888 glx-alternatives_0.6.93.tar.xz
Checksums-Sha256:
 17f901b1a01d7a69891028bef31fca7bda7ab248ee2cdc73b8d6b3f1fce7d29f 1999 
glx-alternatives_0.6.93.dsc
 c40308c9500c0814d438d0d2bf9abe821554338f45bea677156a691613385a94 10888 
glx-alternatives_0.6.93.tar.xz
Files:
 25de16e03171299cd9c5cb1a258ffd3e 1999 contrib/libs optional 
glx-alternatives_0.6.93.dsc
 6714070c9c9387837d9ca05ffa6fc45e 10888 contrib/libs optional 
glx-alternatives_0.6.93.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWJvDdAAoJEF+zP5NZ6e0ID+4P/0lQcHWSqyDaLkCvXVcgWwSy
BA3fFKh/tNy6meqUHEt3tBO5FJSpfscSfJZicVzMzYWXvIylOOftysICJsGLmUpn
Hrzf5LfOF8YfCgA2OnNFIak29IWJoLs9ZdY7Quy74k8/MP7JwEdA+aFYNCZUnnvP
m+09BgzKR4liJdDytYGOJmpmS/+mgMAVZi74+I/VYOQLPoswfQlj3Qcf6Fhy+Knl
FGXuZzjw/cpP/86bQgcXi4/nJtTmx6XR5Iv7gOTZvm+Uiij9qtjdoziSWWVlxyYD
4srEPy+N7d/kN8jQHwdq+TpLyezn4Oa70mRH4WlGSOQL5Op92WtVbqVgpo1MAxhi
6RcTgjdelqsYWw2DaD6EJRlSsm6wjbrozRkga1YLJ5mOL5s2NeNDdANHuNjfySjw
slD6ddbVO1QXnxN382aPbNW0bqvbBONaiX3h9jgXbuYvacRkLpDMVgWfq0vGuknX
bmEVPdAU4QLNPb6H3neDF2UNjwfAhASttlgbu3pSiWXgJKNk9wu6tvCM3q2xAXON
BxJG1nj+Dw8CsgwuRKG4SeWiLAyrLemz6YwTRL2Q7hF5/qcAGREO8bw+1oEW1uUp
hNUVojVKTv7CjSUi5N+A+QZWwdgbP8ijz+jqhigfdXUEvGP81aNDcKBeLIeHJYjH
ORBp9qFkVAnx94VG/6O8
=Vd4H
-END PGP SIGNATURE-

Accepted glx-alternatives 0.6.92 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 19 Oct 2015 12:10:39 +0200
Source: glx-alternatives
Binary: glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source
Version: 0.6.92
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
Closes: 802246
Changes:
 glx-alternatives (0.6.92) unstable; urgency=medium
 .
   * glx-alternative-nvidia: Add a second alternative
 "/usr/lib/nvidia/bumblebee" that combines the nvidia kernel driver module
 with the MESA libGL as it is needed by hybrid graphics with bumblebee.
   * Add NEWS entry about bumblebee config changes.  (Closes: #802246)
Checksums-Sha1:
 ef598fb9c093978fb78c9d79424fcbd8ab02f2c0 1999 glx-alternatives_0.6.92.dsc
 d9341e95c1a27863537d55fb2b1917224d217d60 10920 glx-alternatives_0.6.92.tar.xz
Checksums-Sha256:
 5bff452063f652387bf9b407fd5ac7e7da20bbdae3b4db886a994be18ea27cf2 1999 
glx-alternatives_0.6.92.dsc
 dd6e7c8b809dc5bede9b590cc62a69a859379fb503336ce221215f8d75629e43 10920 
glx-alternatives_0.6.92.tar.xz
Files:
 8031e61f83a98fad6da431148ceaa3a8 1999 contrib/libs optional 
glx-alternatives_0.6.92.dsc
 604dec919916740519b71285bc0c2285 10920 contrib/libs optional 
glx-alternatives_0.6.92.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWJMMlAAoJEF+zP5NZ6e0IvU4QAI8Eej7Hb2a1Z7QzeZkoioIq
LaYLH2jEaWTd1mop8gtMMgHgxgkY9Be024AB0xBKcKuHBE/GRuHz/iwok6zPgbq2
HWhn3hNQdBovQb75Ma4FqSgIyLtpW8OiFdwS+/or60AraBgiWpJMc/JUHPMbErLt
C/mrlJY38dy8dPQyEnJATTaUlbxhcRiBJTITHf6wF7A8DuR7lrUgp/blfFOiXgbT
UDgWAHoNi3DDSwZDDE3pel3T+9pUAkZggTIOl6P3bB7fzNXxtrep60xpcwJqY/3Q
KHPdQdkMCMO4Tq51sAYth0QbWbcvlOLQS827XJ77iP388EnVZy8zZVc817LrE/ig
XW/dmjzKrqFkIJvLrNhhGfLvJj15mQ8IhaVm3rTWWMiiEW778F7xoPzmJ5ZTAf/i
iWpz40N+QbyYG/gZB+FOPhtdkH6XAiwRhJIk4g1R4Nhz5WuAM2K2AjkWdnWL5+v+
k0mei4Bz1c0j7FYURyCe1I5rk6WjTIhZW22Cr5wc0v16LfWbtSgm6Ismy7f++AMY
4jHS5GkMHb9saCNfp+OvB+RuhjbEx/MVtRRPITnvXpCNYG/nHYPzLnQ7dzn2Ro+2
PKtEa5yJZFjfNyCiEv/L7D3PUhbhnfaXdfwO8pvSunHq3kjUWVLFOirK3SarrKH4
cZokBJNuqUIS6iiRaj48
=g9v6
-END PGP SIGNATURE-

Accepted glx-alternatives 0.6.91 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 15 Oct 2015 15:50:39 +0200
Source: glx-alternatives
Binary: glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source
Version: 0.6.91
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
Closes: 799948 801330
Changes:
 glx-alternatives (0.6.91) unstable; urgency=medium
 .
   * glx-alternative-nvidia: Do not ship nvidia-drm-outputclass.conf, moved to
 xserver-xorg-video-nvidia.
   * glx-alternative-nvidia: Do not ship nvidia-blacklists-nouveau.conf and
 nvidia-load.conf, moved to nvidia-kernel-support.
   * glx-alternative-nvidia: Provide slave alternatives for
 - /usr/share/X11/xorg.conf.d/nvidia-drm-outputclass.conf
 - /etc/modprobe.d/nvidia-blacklists-nouveau.conf
 - /etc/modprobe.d/nvidia.conf
 - /etc/modules-load.d/nvidia.conf
   * Upload to unstable.  (Closes: #799948, #801330)
Checksums-Sha1:
 6c0851692a700c1731fda424ac6af7cd67351f06 1999 glx-alternatives_0.6.91.dsc
 44d464868c1aa9d3570b355e7c071afda8d3722d 10588 glx-alternatives_0.6.91.tar.xz
Checksums-Sha256:
 f66a705dc06d9a16bb5d682dc61770b9797871ed6e4dd23da4931669c57aa538 1999 
glx-alternatives_0.6.91.dsc
 8a68798bf54265003b3e3a50c2c63aa098ce237f9962fbe484a5b17332b8f55d 10588 
glx-alternatives_0.6.91.tar.xz
Files:
 1eda6071fa2f374b4573cd9a49b1c4dd 1999 contrib/libs optional 
glx-alternatives_0.6.91.dsc
 284f495e29872c47b56db444a9db0a16 10588 contrib/libs optional 
glx-alternatives_0.6.91.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWH7ASAAoJEF+zP5NZ6e0I0acP/1YkAcdbUAr5bGjEOFln3vGI
ImryANIrOitS1KAiIQdLU84pdnG0RCjghdvVtSbaTkjlHOAbSmNROYLZfmJNSHSz
2iuqotdfMvs8QgmOlQ0ECW9xP1MbLLLZHh/ktDOUTmlT+FTdT2sIGBTUGWjMMklT
zJL/mHVHpnIXxR82zawuxy5UHgp6YRBNF5nMAmtv1EPV01MHNlZkgClNyxMOdJD9
ewBnJvoVgDUm4UGGqIpk3Jz+55g4QgvdGPQb7diN9gJvZQtPKgSLLFUaRZt5cVlP
2bzBQVDoMUsXzWqCLuPlN8rfLgPBL5+FdoPXG1TgF2tTyD5LLNnyl4gFwkecz6iL
1RrJyh7hlwIcqMYewdmmq1xJo+ovpl+aJl4hg7b+dpNDk+6fo2Zyg87NvhSC1dzU
nakFaUlpyw/W5HpKIAs81Yes9CVAmPJo3b7Cpr5rxoTzFl/8N2xvjXseE4nZkcJ/
/PluiqjjNsvXfn8TTjOggrH3gxQOfHtaQvv7ydsIMZVzH5u2K5iftXT5Vz/j9QuB
Cpkn5z39/icfHYIa6TGhRSD9N4WMxSiUhnE9h85e1tyEuccKytr8yrY+4kkMnwBL
cclx/o5sb4izLMiB/+yax1ayruYTUK1I1ukxu4MSJTTQwECRJFDlvSXGHifaPSVL
PqsYDUhDLvOCidiDoKnB
=GV6F
-END PGP SIGNATURE-

Accepted glx-alternatives 0.6.1 (source) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 05 Oct 2015 21:43:25 +0200
Source: glx-alternatives
Binary: glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source
Version: 0.6.1
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
Closes: 795262 799948
Changes:
 glx-alternatives (0.6.1) unstable; urgency=medium
 .
   * glx-alternative-nvidia: Enable the alternative for headless CUDA setups,
 too, which primarily need the nouveau blacklist.  (Closes: #795262)
   * Temporarily disable the nvidia-drm-outputclass.conf slave alternative.
 (Closes: #799948)
   * Use devref's 'pathfind' instead of 'test -x /ab/solute/path'.
Checksums-Sha1:
 e38c4f8148890f81ef2b2c6a5531576f96c3a510 1995 glx-alternatives_0.6.1.dsc
 1955ff32e975e7f94a58264fd909aa013ba6f69b 10640 glx-alternatives_0.6.1.tar.xz
Checksums-Sha256:
 993ff7614ad46bf6b2934c59760547e714d7784ba3128e1914bfecf05f7bf36a 1995 
glx-alternatives_0.6.1.dsc
 419b629178322754b885731ed0f4b8ff6f160707ae27837a40849191aab6eca3 10640 
glx-alternatives_0.6.1.tar.xz
Files:
 dd74e4be878b99bdb186eb34892ed717 1995 contrib/libs optional 
glx-alternatives_0.6.1.dsc
 a2b072027458491eda2f0eba06461f21 10640 contrib/libs optional 
glx-alternatives_0.6.1.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWEtOuAAoJEF+zP5NZ6e0IyicP/32fYxZ59Op9QhiNAmPIK3gs
JLpnGTSMHURwKgMYAf1KZf6lOjhsCAimFoxXE/4fEYoFooyQMLT2OKO1vqhWTxSK
5D1oBlfFTFO0vmTb32JRaaXFkzOJJyNAsCj47n9g3cpzqqWfIT0cikMzxCwCfQwg
u24egzbAmWdVf3/RZQ+R5GyPM1YF1citv1yjKZWqTJGG3Z8D38D2LeW3Dv6oeQdX
v57+u21Ktg32vX23Y2I7rFURRC7pJ+daWza7wUkt2qdM/R5TjZf3LWMkH+rjsgmF
1TH5WUuBmas6UGVEfynNxSrxvJSKDgyBPu3djoutokzjiQhzrVBZFJsmBwKEJ3/Y
wtGtSMVIyLOymzzDlE772g1uGnhdpyEVTtr3gfziIkeYw9JquOqYqMWw9dmCWueE
4lnPPvyj3/2eiw8qbwNmqa6apprZpeioOCzMCNHxKCIz4xFGF/qGI+WSvob3rjXc
EFyzoieHdpm0+0FdI5d5aixk7Vtl5O8jjMrFmTGOEtWanBcsbNBk3xJJ1c6Qf+fI
jIyLcndKBgKCdidsZMEzSp6EVx0IWAIJXrhI9FjX0NaK+wqFsDd2BgDqOyPnewNe
a0WP2rz7et8LhyV27xFko+Ejq2KSWCj+XT0O4WupKSr08Wkmfhqa4056Ys2husq+
IQ8kBJu4vmvqnZ42l39M
=j6Br
-END PGP SIGNATURE-

Accepted glx-alternatives 0.6.90 (source) into experimental

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 05 Oct 2015 22:04:50 +0200
Source: glx-alternatives
Binary: glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source
Version: 0.6.90
Distribution: experimental
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
Changes:
 glx-alternatives (0.6.90) experimental; urgency=medium
 .
   * Re-enable nvidia-drm-outputclass.conf slave alternative. (Reopens #799948)
   * Upload to experimental.
Checksums-Sha1:
 75993c77d629d5a4dc14e7a0e2d670b91ba5c34d 1999 glx-alternatives_0.6.90.dsc
 88684991a9e82cf4c266075220ac868d96c1801b 10716 glx-alternatives_0.6.90.tar.xz
Checksums-Sha256:
 3a9fcf03ecf11543eb17204cde15e35661fc42bb9f5d104c67f3dd5c8148d40d 1999 
glx-alternatives_0.6.90.dsc
 f831ad7507acde95b060dceaafabc1f56505f0526f26522b057f89c960c6f792 10716 
glx-alternatives_0.6.90.tar.xz
Files:
 b2bcd7357865dd82f6de39f5dd84070b 1999 contrib/libs optional 
glx-alternatives_0.6.90.dsc
 6e83d9dd4d72bad9b4ab8954c699ec41 10716 contrib/libs optional 
glx-alternatives_0.6.90.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWEtjwAAoJEF+zP5NZ6e0I7VoP/0Cu07MniZO4IyOsC5f/eo/x
dV8r5rpH1WJDRfCEmBz9Z4GdhRyN1iZ3e1m22FFtvlWsvtV5EmMNQrWDzcelCN0I
ByTdwmtFnm5+A865XXGB4vFpdg70cTSnjSVhyY5Mg3Dh1JhbHBWyQwmihv24Pa4R
9wO0Bv1XM3kgoUNfmty69WSwDz3SomNYBSzBqq1R2RfMpAF0qNcxCwfv6qNRWGQs
tv4QkR3qX3mXC3fZScy5eAlD9KkfghzNyIVWzCBYbxDWvZ2ZH6h1LCLlUm7Vg8zX
aGNWlfrme/0AJ7GV7DS8y2r4DlBD3Dg9SY/lEJJscvpSEoRlUFS1COOEOeYX4K3O
ZCimRJl+7qte4ZIhATyD8xoEetO0V8M5suma8XahShafn5SXQRdWj1eP4FYMP26u
PwQb4QEFfrOjE12bkCYkDbGfrBpn9g3S2ueNgycZ4aEHQOHVHWjJC6pq8m/7rh34
UtTDJcPtE531jX6hAL9JSEXJM+VTz/0kDYW/PJP8GTlPWazscuSNMlrDtuoLxjLA
ZtdwBxfwR2P/0j06omAxVQSqFPmO2Uc6Q9vKgqJNH8fzu7z2Utx5j3mMVSxFPtfi
CeSFCJE6BEwOWcYSg47x1sohR2x1jYGy8eRp1uAgYeBZqbImw9qbO3ChWuO0dlV0
ytFiDzXRnDaKxnooAABQ
=OT0f
-END PGP SIGNATURE-

Accepted glx-alternatives 0.6.0 (source amd64) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 24 Sep 2015 02:05:26 +0200
Source: glx-alternatives
Binary: glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source amd64
Version: 0.6.0
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-de...@lists.alioth.debian.org>
Changed-By: Andreas Beckmann <a...@debian.org>
Description:
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
Changes:
 glx-alternatives (0.6.0) unstable; urgency=medium
 .
   * glx-alternative-nvidia: Support Xorg autoconfiguration without xorg.conf
 via /usr/share/X11/xorg.conf.d/nvidia-drm-outputclass.conf.
 Therefore enable loading the kernel module automatically via
 /etc/modules-load.d/nvidia-load.conf.
   * Convert package repository from SVN to GIT.
Checksums-Sha1:
 28842b29068fb7d903e64ee02d44fc913d639978 1995 glx-alternatives_0.6.0.dsc
 cedf0a6e959bfc3fcec84e082d856865133b5ed7 10408 glx-alternatives_0.6.0.tar.xz
 f22a69e4c5c461fba9f654b474ab3120366e96e5 3818 
glx-alternative-fglrx_0.6.0_amd64.deb
 538aa6bae106bb6d670bbddf63d3d225adb485dd 3156 
glx-alternative-mesa_0.6.0_amd64.deb
 87bd708a2d98d20304d5db6d716b0ceb5dc8fa2d 3950 
glx-alternative-nvidia_0.6.0_amd64.deb
 d19beba4276d6d3f106166d01eac1daefc489d61 9266 glx-diversions_0.6.0_amd64.deb
Checksums-Sha256:
 aeb0ea069323a8090f406170ce65b4910883e547e9740e70ae5a5e24859f167d 1995 
glx-alternatives_0.6.0.dsc
 fef4de497811c894f721977e497b91f90bc8b3b82562d527f90175a1afeff384 10408 
glx-alternatives_0.6.0.tar.xz
 030304a378a0fe0adc502a11d1d39f76712437a83d074650a606eab24776a589 3818 
glx-alternative-fglrx_0.6.0_amd64.deb
 bbc860b67303d7f47880dcee4f08d21746db774e9a0ded8ddf836e0af814acd2 3156 
glx-alternative-mesa_0.6.0_amd64.deb
 56f9e9fdccf0a8d45d7bb3939bf7e6037fcf81a9f2335feab07adcdc08b39fb5 3950 
glx-alternative-nvidia_0.6.0_amd64.deb
 ae89c2fdf750e112d26cade52bff660b298217a1b517b342c5f7413f0f238e9e 9266 
glx-diversions_0.6.0_amd64.deb
Files:
 f053e971864d574d2448048e94674d93 1995 contrib/libs optional 
glx-alternatives_0.6.0.dsc
 fb0b3fde4c59ce1523e8a817508dfc23 10408 contrib/libs optional 
glx-alternatives_0.6.0.tar.xz
 62c1c8e10c05a7ee17fba1e4ec4e1756 3818 contrib/libs optional 
glx-alternative-fglrx_0.6.0_amd64.deb
 2e39b15920164937b0c4f87a585be802 3156 contrib/libs optional 
glx-alternative-mesa_0.6.0_amd64.deb
 62db84487c7f6693068097da26cc2075 3950 contrib/libs optional 
glx-alternative-nvidia_0.6.0_amd64.deb
 1cf4e9dd8275db6cd598af008b4fcb04 9266 contrib/libs optional 
glx-diversions_0.6.0_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWA0nJAAoJEF+zP5NZ6e0IY0MP+wcs4N74xH/p6FNEUF8A4wt4
mTUWqCSLjR+4sSw4khGnMAkvOlxHMqGR1nvaxTaPti6PjP/3naY+Flw5Mg/ki6+R
fPvYL80m4md/ETFmR4NeVMYQ5BfSF1j6nx099zrYK3CoLrb221QiGaEAvSY7OzCu
EhbRemTtou/8+x8Z1iKjVOeuNZpzX6q+7sfiDaB3MO6fJBCO5Iz2tZLobccfY+Tg
ik05RhvgtDTakK1PC+tV1N0vvb78hiz683zcJ4mKqAOGuJeNApA9fBEXhqUJdbWc
IC0uQmU0CalHpOy7pWNmlPiHaaQRZ9Q+cIHu3eMpo/PN3qZphkY0fTf3W0TnH9Pc
E3maNFJKwUvOtdszxJb2E4TcTqLRss5Bwp0F+OR86Lg4U0Utw0/VzKqd8Knr4uj2
gEJPZYrghZ3lfXJ/caXb1leiZiK3H/Lle6n6WtI+l9JprGydgXOQoAkOPRKEabH6
6hqvvLOXTnyPB/a/iPsO3jPoyA612h17v5UoilVyFajJcEjYu39x9gjQ6didZJ7z
CtWfM3D0ooMgvV0D8Ht0Uo4YRw+l1kVddKCvyDxXYwPrUG3fAtRMY8sl3xSMKgOP
7AYI8BNDUaygYgH8r+eaCSqF6xQ0FmA6qLU4WUH+pcvxxdWzi6SbPpDIh7zMBHU9
Ov3ef8PJbgJY2H/YE05U
=q8FJ
-END PGP SIGNATURE-

Re: Bug#757941: static linking: alternatives for glibc?

[Aurelien Jarno]

reassign 754813 libc6
reassign 757941 libc6
forcemerge 754813 757941
severity 754813 important
retitle 754813 libc6 version 2.19 breaks NSS loading for static binaries
forwarded 754813 https://sourceware.org/bugzilla/show_bug.cgi?id=17250
tag 754813 + upstream
thanks

On Tue, Oct 07, 2014 at 09:58:04AM +0400, Michael Tokarev wrote:
 07.10.2014 08:34, Steve Langasek wrote:
 []
  Was the removal of gethostby* APIs from the static glibc intentional?
  
  Yes.  It's the nsswitch problem.  The behavior of those APIs is controlled
  by the nsswitch mechanism (specifically the hosts configuration), which is
  inherently dynamic and doesn't support static linking.
  
  It nevertheless is expected to work when the corresponding NSS modules are
  present.  It's not truly static, but the dynamic loading from static libc is
  supported.
 
 When a statically linked app calls getaddrinfo() (it is getnameinfo not
 gethostbyname), the call immediately returns host not found, try again,
 without any attempt to load anything or look for other files.
 
 This is with jessie glibc.  With wheezy's glibc it worked when the right
 nss modules are presnt (iirc anyway -- I know it worked, I didn't check
 _how_ it worked).
 
  So bug #757941 should be reassigned to glibc, instead of claiming that this
  is somehow expected glibc behavior.
  
  Perhaps glibc upstream would be willing to restore them?
  
  It would be nice, but I doubt you'll make much progress.  Lots of people
  have complained about this over the years.
  
  At issue here is a glibc regression, not the standard complaints about
  static glibc being not truly static.
 
 Regression or not, but there are several other problems here.
 

This is a regression introduced in 2.19 by the following commit:

| commit 0d23a5c1b1908700d25b7e3c6cece148e19dded4
| Author: Maciej W. Rozycki ma...@codesourcery.com
| Date:   Fri Jan 31 17:51:31 2014 +
| 
| [BZ #16046] Static dlopen correction fallout fixes.
| 
| Fixes to address issues from BZ #15022 resolution, as follows:
| 
| * TLS updates to csu/libc-tls.c -- we now have a proper main map, so
|   there's no longer a need to create a separate fake one to keep TLS
|   structures,
| 
| * random updates to elf/dl-close.c -- LM_ID_BASE is now a valid name
|   space ID for static executables as well, so assert that we don't
|   unload the main map.  Similarly dl_nns isn't supposed to be 0 for
|   static executables anymore,
| 
| * actual BZ #16046 fix to elf/dl-iteratephdr.c -- the dl_iterate_phdr
|   special function for static executables isn't needed anymore, provided
|   that l_phdr and l_phnum members of the main map have been properly
|   initialized (done in _dl_non_dynamic_init in elf/dl-support.c now),
| 
| * ld.so.cache loader update to elf/dl-load.c --
|   GL(dl_ns)[LM_ID_BASE]._ns_loaded is now always initialized in static
|   executables so can become the fallback loader map to check for
|   DF_1_NODEFLIB, provided that the l_flags_1 member of the main map has
|   been properly initialized (done in elf/dl-support.c now); this also
|   ensures previous semantics elsewhere in elf/dl-load.c,
| 
| * matching updates to elf/dl-support.c -- to complement the two fixes
|   above.

This is actually the same bug than #754813, as all NSS functions are
affected, including DNS resolver or getpwuid. I am therefore merging the
bugs.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141021104729.gy...@hall.aurel32.net

Accepted glx-alternatives 0.5.1 (source amd64) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 22 Oct 2014 01:05:56 +0200
Source: glx-alternatives
Binary: glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source amd64
Version: 0.5.1
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org
Changed-By: Andreas Beckmann a...@debian.org
Description:
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
Closes: 766169
Changes:
 glx-alternatives (0.5.1) unstable; urgency=medium
 .
   * glx-alternative-{fglrx,nvidia}: Fall back to MESA for each EGL/GLES
 library individually.  (Closes: #766169)
Checksums-Sha1:
 932dabe064764777c0352a74636c2474d60de25a 2013 glx-alternatives_0.5.1.dsc
 d37a5ab72acfb8d6b8d143ead3458a777d9434c6 10188 glx-alternatives_0.5.1.tar.xz
 e2d5392ee9b36121fe7c8e244ca32156c96aaebb 9432 glx-diversions_0.5.1_amd64.deb
 496e324d4ac9295798766bb901abb2c44cf26243 3488 
glx-alternative-mesa_0.5.1_amd64.deb
 cddff38d36b022f782d82b10fc4e8134731e1520 3804 
glx-alternative-nvidia_0.5.1_amd64.deb
 c24da5df32aca449e4a430d9fed4b41caa20fb26 4114 
glx-alternative-fglrx_0.5.1_amd64.deb
Checksums-Sha256:
 71c8bda9ad0fb03f53c59558b957e22c09be1a6a4eb5f24d59d774f103d1b996 2013 
glx-alternatives_0.5.1.dsc
 ed11f5f4b25ebf41ad2a65622cded3470aa8db3b21803b549b3aebe10ff0e37a 10188 
glx-alternatives_0.5.1.tar.xz
 de65300299d2b06466a174af0b28c77ef7ca3c3b636ff4ee57933e1a237eb3d2 9432 
glx-diversions_0.5.1_amd64.deb
 7fd7ad08d97bf44cec0e07e23ef18bdf68a223e3364a7da9f76a2c92c49b545f 3488 
glx-alternative-mesa_0.5.1_amd64.deb
 4985595cebaf43f94143f09c9867af7a96e72d11d984573a0a4028921217a18a 3804 
glx-alternative-nvidia_0.5.1_amd64.deb
 282e89ad682c8fa65dd4487f664553471525980aebeea3cb789683bde613976c 4114 
glx-alternative-fglrx_0.5.1_amd64.deb
Files:
 9c191c037be91ade140c0aba08a59e10 2013 contrib/libs optional 
glx-alternatives_0.5.1.dsc
 5c675a2d70ac2b0999ed4250a4e9925b 10188 contrib/libs optional 
glx-alternatives_0.5.1.tar.xz
 25ae868a454374ac32f0b42ac370a5e1 9432 contrib/libs optional 
glx-diversions_0.5.1_amd64.deb
 7a07904681be0eea96862e91a7441b67 3488 contrib/libs optional 
glx-alternative-mesa_0.5.1_amd64.deb
 100445c1222c84518d65f5e0dd1f536c 3804 contrib/libs optional 
glx-alternative-nvidia_0.5.1_amd64.deb
 682b9fa08b38bb12d6bffe0cb0d320cd 4114 contrib/libs optional 
glx-alternative-fglrx_0.5.1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJURuegAAoJEF+zP5NZ6e0IiVEP/2FMpkBp+gTJw4ca4rIEfW0k
RBdTUZem1LbcOhZA2EnLOB0r6gJ5yGiw48FPLa1oIfx/rYfTHvgA/bHSRALW6zBt
X3wlWS5ntPFfA//s+lp1JmsTdpH6nEIzR87Pjs8jVCX4nkyHx5O8KYqoMscrgk/c
LMFcpCW7R85RMgUGPoJ6o5IFwW595+swQ2Be2WYSAGJZCdhp1eqt2ohAaDGTS+xR
qkolAtp82DHuBu90mntWlJYh0ALMjxRXzZIr6bD1xWs4eCtE0NGF1BTrkhA4Nc+u
NJGM7wc/eQbcplpIb2f7EtMExsM5HGzqch7RbWezHMII4D3mk44+xLyLQ1ApDrRl
OmGHvTMV9GFJMFLy76CcebCxbNzrx/HBKo8Qr1jRToahThqHQu7Kr+QDhYPMsNJ3
LxlEtVd9M7W4IRbEoihZ921N2ND5C7jnLqrJ2FmsEFRY0W9GzPTLCHPMWcWsrdS7
37FVt7cY/sqwMRQIsHSCGAxz9gW3RfClpmBqzgCElo7BXuIdC9Cnus5zy4O8yeJF
XLidFIRJsGj90YfFdX5wnGmQYEdjCUsNzDTZR/PeyZuX+QXe/6jOQotq/TlaZckf
hew4xv4ByXMrzY7vPbEl3kSRaBWHNaOvQwia9crcpxocIa70+8WOGmamAhtEHveg
ckCDsdzdXqOseCsgAumR
=OwZk
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xgj26-0005gl...@franck.debian.org

Accepted glx-alternatives 0.5.0 (source amd64) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 20 Oct 2014 10:49:00 +0200
Source: glx-alternatives
Binary: glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source amd64
Version: 0.5.0
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org
Changed-By: Andreas Beckmann a...@debian.org
Description:
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
Closes: 765793
Changes:
 glx-alternatives (0.5.0) unstable; urgency=medium
 .
   * glx-diversions: divert libEGL.so*, libGLESv1_CM.so*, libGLESv2.so*.
   * MESA, NVIDIA: Add alternatives for libEGL.so*, libGLESv1_CM.so*,
 libGLESv2.so*.  (Closes: #765793)
   * glx-alternative-mesa: Use a script to generate triggers.
   * Bump Standards-Version to 3.9.6. No changes needed.
Checksums-Sha1:
 b5841d5b2e15fdcfe0c8c7ac004553f71defafe4 2013 glx-alternatives_0.5.0.dsc
 ccab9fd4147f62e6dba90c1776553fe5969a9b72 1 glx-alternatives_0.5.0.tar.xz
 17b350d614e82f16b319e1cf45af63cee9e8fa55 9366 glx-diversions_0.5.0_amd64.deb
 c6eb8232011365828758c53fba65713eec953d37 3486 
glx-alternative-mesa_0.5.0_amd64.deb
 96a61acc40d64d68706265bbee6dfb29edbfbe1b 3662 
glx-alternative-nvidia_0.5.0_amd64.deb
 65f1e1bbf3d0f3b87cd4a924d1f846d35d448792 4032 
glx-alternative-fglrx_0.5.0_amd64.deb
Checksums-Sha256:
 eedc323414139514f5725c77f176dea272a35999d1324a1f0cc8289967b4d494 2013 
glx-alternatives_0.5.0.dsc
 37ed923edf92b0fe2231dfc030aa1dfd75a174f91af5f7c5f5fc39b9ed57c212 1 
glx-alternatives_0.5.0.tar.xz
 4f45592166c9af977b688dffc1770894ae2af07f09a22ddc6e094f62eb766b4b 9366 
glx-diversions_0.5.0_amd64.deb
 9c6cc70e99fe88fcc70aba187cd208adee4724da8a6c5070296f90c3e58c6fe4 3486 
glx-alternative-mesa_0.5.0_amd64.deb
 263cc7df47e3861406e998660875f68e875b9ba6833ebc156aa5e99a4291a1cd 3662 
glx-alternative-nvidia_0.5.0_amd64.deb
 ba71c4734a4541a834cb2a259bcea0fedad856b883604c288cf8153fdf2ab78a 4032 
glx-alternative-fglrx_0.5.0_amd64.deb
Files:
 6b3f17732b5fd22718bd3d3566db3ba7 2013 contrib/libs optional 
glx-alternatives_0.5.0.dsc
 083757882f925eb65333bd0acc1e5d04 1 contrib/libs optional 
glx-alternatives_0.5.0.tar.xz
 229cc75125fdfc8eecfe11d00467a2df 9366 contrib/libs optional 
glx-diversions_0.5.0_amd64.deb
 884c4cc2a92fc258bc40aa504a6e4238 3486 contrib/libs optional 
glx-alternative-mesa_0.5.0_amd64.deb
 a11192819f0e91592d6ec97d8e1a2adc 3662 contrib/libs optional 
glx-alternative-nvidia_0.5.0_amd64.deb
 ab793c650cc7fdc8b148c9d9d341ca57 4032 contrib/libs optional 
glx-alternative-fglrx_0.5.0_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJURM22AAoJEF+zP5NZ6e0IRAMQAKCLMdPnSO9N+Yyp3FqfRuff
Oy00rk7BOa9guSIGXdGNh7JGuC8nHUUBSAeyYijadCL608sLLdN0eznE9rzhY2mx
QQhjCPc/suZMrenwgpP+h8vMggCEZvn4Xvj4LuoW9fGbzLJKRYgVH8ql03l9SSnQ
lRobwoDTwDqI4ckdnRPcrwkIxx0I/qUemTyIaeykmlph2UVAwvYOB6tVQG7Kz358
aDaMvmRwpwsNedIhwjYn4Bsnz1L3B+fgBs4rAl9kECj5vXtSuo7ohJL7w0VjKJGZ
9Zgdn3FgoCtzFJM6tty4XT14rjNQQALzYssBTNrJ6Ek+kcFmNDTz0LSAbtOekr/t
eGj7ekrGnWMXXnKAXfCAlZOOE3eriOUSSDtVvjGKEwxXouRzA3CggT2PiB8z/1nC
aVzWsrNtgTNGIPKqDwMKY4jMdmeKRxZp3kNP1i+QgXiqsz48PzDdgbXgnJarxHOZ
6wDGO5Wyq3ZqBnCydFLXjb9GX4pk0Cg8OGW8ufJWDTvSHj62kEvylT7weBmTg2va
KhC6pWFNjeU5Eix8dMKcz2Ufqm0CvZuFXPlJyfLMZ0Zgg9s+aa+J/e3q1KYoMB+S
M5aiFfYyUNSWGSdDObeDmR6MFsKzGjKQrEdSyIIM514T8PQZ191sCtNgw28PLff2
JA8MGMemuGVVPWhVJes2
=B/Rc
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xg9ex-0004e7...@franck.debian.org

Re: Bug#757941: static linking: alternatives for glibc?

[Paul Wise]

On Tue, Oct 7, 2014 at 1:58 PM, Michael Tokarev wrote:

 apps becomes huge in size

I wonder if LTO would help with the size issues, theoretically all the
code from the static glibc that isn't used by busybox-static would be
stripped out of the resulting binaries.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6GSXuq5xuM92anbNW=d9lzfu2spef+1a7og4n3u+uw...@mail.gmail.com

Re: Bug#757941: static linking: alternatives for glibc?

[Julian Taylor]

On 07.10.2014 08:07, Paul Wise wrote:
 On Tue, Oct 7, 2014 at 1:58 PM, Michael Tokarev wrote:
 
 apps becomes huge in size
 
 I wonder if LTO would help with the size issues, theoretically all the
 code from the static glibc that isn't used by busybox-static would be
 stripped out of the resulting binaries.
 

this is already the case with regular static linking, you don't need LTO
to remove unused code, the compiler only uses those objects from that
archive that are required to resolve all symbols.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543397bc.6020...@googlemail.com

Re: Bug#757941: static linking: alternatives for glibc?

[Matthias Urlichs]

Hi,

Julian Taylor:
 this is already the case with regular static linking, you don't need LTO
 to remove unused code, the compiler only uses those objects from that
 archive that are required to resolve all symbols.
 
… remove _some_ unused code. Lots of code the linker pulls in from gcc will
never be called. For instance, it doesn't _know_ that none of your printf
statements contain '%f', so it adds the heap of code required to print
floats regardless.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141007151707.gc3...@smurf.noris.de

static linking: alternatives for glibc?

[Michael Tokarev]

Hello.

For a very long time, we had a busybox variant which is linked statically,
for rescue or other similar purposes (for those who don't know, busybox
provides minimal implementations of varios system utilities so can be used
almost alone as a replacement for whole (minimal) system).

But with jessie, for one, all network name resolution (gethostby* etc APIs)
don't work anymore, because glibc does not provide them instatic libraries.
So usual network utilities in busybox does not anymore, they just return
`host not found' (unless you use IP addresses).

So I was thinking about alternatives for glibc in this context.  For busybox
it should be easy on one hand, because it does not depend/use anything else,
just libc and busybox itself; but difficult on another because busybox
uses a wide range of libc functions (especially low-level kernel interfaces).

So, I tried uclibc.  Just to discover that debian does not have binary
uclibc packages, only uclibc-source.  Tried to build uclibc from source
during busybox build, but this is a bit hackish, and does not exactly
work right: uclibc readme says it needs whole toolchain, including gcc
and binutils, to build applications against the library, which is quite
a bit overkill.  Trying naive approach, by contructing a minimal .specs
file for gcc, - but I don't know enough of gcc internals to write one,
I weren't able to make it to work.  And I don't know which probs this
approach will have on all interesting architectures debian supports.

Next alternative was dietlibc which has binaries.  But it turned out
that busybox does not build with it, too much stuff is missing from
dietlibc, and large patch is needed (for either dietlibc or busybox)
for things to start working.

Another alternative was musl, it provides libraries and it is almost
sufficient to build busybox.  But unfortunately it does not build on
all architectures where I'd like to build busybox-static.  Also, it
does not provide rpc which is used for nfs mount functionality in
busybox.

So basically, I'm back to square one.  Maybe I can build busybox-static
against musl on those architectures where musl is present, and use
old glibc way on those where musl does not exist.  But that'd be
non-practical (but on the other hand, the most demanding and practical
platform for busybox-static is x86 anyway, where musl exists).

Another similar question is qemu -- qemu-user-static package.  It is
built statically to be able to use it in a foreign chroot without
worrying much about dependencies.  It too can benefit from some
more static-friendly libc (if not only to save space), but this
case is a bit more tricky: qemu ises glib heavily, and I'm not
sure libglib.a can be linked with anything but glibc.

Thoughts?

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5432b4db.8060...@msgid.tls.msk.ru

Re: static linking: alternatives for glibc?

[Paul Wise]

On Mon, Oct 6, 2014 at 11:27 PM, Michael Tokarev wrote:

 But with jessie, for one, all network name resolution (gethostby* etc APIs)
 don't work anymore, because glibc does not provide them instatic libraries.
 So usual network utilities in busybox does not anymore, they just return
 `host not found' (unless you use IP addresses).

Was the removal of gethostby* APIs from the static glibc intentional?
Perhaps glibc upstream would be willing to restore them?

 So basically, I'm back to square one.  Maybe I can build busybox-static
 against musl on those architectures where musl is present, and use
 old glibc way on those where musl does not exist.  But that'd be
 non-practical (but on the other hand, the most demanding and practical
 platform for busybox-static is x86 anyway, where musl exists).

Seems reasonable to pursue this concurrently with getting glibc
upstream fixed. Then you could use musl on platforms where it exists
for reduced size and glibc elsewhere.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6gbuoyh+0rxqf1-rbry2m1wtd0gzjqvxd0udwfhvud...@mail.gmail.com

Re: static linking: alternatives for glibc?

[Russ Allbery]

Paul Wise p...@debian.org writes:
 On Mon, Oct 6, 2014 at 11:27 PM, Michael Tokarev wrote:

 But with jessie, for one, all network name resolution (gethostby* etc
 APIs) don't work anymore, because glibc does not provide them instatic
 libraries.  So usual network utilities in busybox does not anymore,
 they just return `host not found' (unless you use IP addresses).

 Was the removal of gethostby* APIs from the static glibc intentional?

Yes.  It's the nsswitch problem.  The behavior of those APIs is controlled
by the nsswitch mechanism (specifically the hosts configuration), which is
inherently dynamic and doesn't support static linking.

 Perhaps glibc upstream would be willing to restore them?

It would be nice, but I doubt you'll make much progress.  Lots of people
have complained about this over the years.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761fwfw3y@hope.eyrie.org

Re: static linking: alternatives for glibc?

[Steve Langasek]

reassign 757941 src:glibc
affects 757941 busybox-static
thanks

On Mon, Oct 06, 2014 at 07:32:17PM -0700, Russ Allbery wrote:
 Paul Wise p...@debian.org writes:
  On Mon, Oct 6, 2014 at 11:27 PM, Michael Tokarev wrote:

  But with jessie, for one, all network name resolution (gethostby* etc
  APIs) don't work anymore, because glibc does not provide them instatic
  libraries.  So usual network utilities in busybox does not anymore,
  they just return `host not found' (unless you use IP addresses).

  Was the removal of gethostby* APIs from the static glibc intentional?

 Yes.  It's the nsswitch problem.  The behavior of those APIs is controlled
 by the nsswitch mechanism (specifically the hosts configuration), which is
 inherently dynamic and doesn't support static linking.

It nevertheless is expected to work when the corresponding NSS modules are
present.  It's not truly static, but the dynamic loading from static libc is
supported.

So bug #757941 should be reassigned to glibc, instead of claiming that this
is somehow expected glibc behavior.

  Perhaps glibc upstream would be willing to restore them?

 It would be nice, but I doubt you'll make much progress.  Lots of people
 have complained about this over the years.

At issue here is a glibc regression, not the standard complaints about
static glibc being not truly static.

-- 
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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Bug#757941: static linking: alternatives for glibc?

[Michael Tokarev]

07.10.2014 08:34, Steve Langasek wrote:
[]
 Was the removal of gethostby* APIs from the static glibc intentional?
 
 Yes.  It's the nsswitch problem.  The behavior of those APIs is controlled
 by the nsswitch mechanism (specifically the hosts configuration), which is
 inherently dynamic and doesn't support static linking.
 
 It nevertheless is expected to work when the corresponding NSS modules are
 present.  It's not truly static, but the dynamic loading from static libc is
 supported.

When a statically linked app calls getaddrinfo() (it is getnameinfo not
gethostbyname), the call immediately returns host not found, try again,
without any attempt to load anything or look for other files.

This is with jessie glibc.  With wheezy's glibc it worked when the right
nss modules are presnt (iirc anyway -- I know it worked, I didn't check
_how_ it worked).

 So bug #757941 should be reassigned to glibc, instead of claiming that this
 is somehow expected glibc behavior.
 
 Perhaps glibc upstream would be willing to restore them?
 
 It would be nice, but I doubt you'll make much progress.  Lots of people
 have complained about this over the years.
 
 At issue here is a glibc regression, not the standard complaints about
 static glibc being not truly static.

Regression or not, but there are several other problems here.

First of all, glibc wasn't really intended to be used for static linking --
apps becomes huge in size and if it still tries to load nss modules or
other things, it means static isn't really static, it wont work that well
if your system is damaged (rescue purposes of busybox-static).

Other libcs exists which are intended to be used statically from the
ground up (uclibc, dietlibc, musl) and which works well in this context
and provides more than enough to be really useful and small.  That's
exactly why I used the subject I used: because I want to find a good
alternative to glibc, alternative which is intended for such use case.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543380ec.1070...@msgid.tls.msk.ru

Accepted glx-alternatives 0.4.2 (source amd64) into unstable

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 27 Sep 2014 19:55:06 +0200
Source: glx-alternatives
Binary: glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source amd64
Version: 0.4.2
Distribution: unstable
Urgency: medium
Maintainer: Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org
Changed-By: Andreas Beckmann a...@debian.org
Description:
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
Closes: 735047
Changes:
 glx-alternatives (0.4.2) unstable; urgency=medium
 .
   * glx-alternative-fglrx: Do not use fglrx-libglx.so in igpu mode.
 (Closes: #735047)
   * Bump Standards-Version to 3.9.5. No changes needed.
Checksums-Sha1:
 51dd52e68f1b7dd4210c5a161349f65bc29b26e3 2010 glx-alternatives_0.4.2.dsc
 54d6b28afcdba3e4a881fcb68f94f5d60deb1649 9668 glx-alternatives_0.4.2.tar.xz
 7772ebc8f7a5013e60b686a7ae033ef6a8819e5c 9036 glx-diversions_0.4.2_amd64.deb
 37b5fdb354ba9b09e9aa9fcbab2e690808ab571e 3072 
glx-alternative-mesa_0.4.2_amd64.deb
 a4ceb9656c757315e14359cc17d7d81a5e178b76 3652 
glx-alternative-nvidia_0.4.2_amd64.deb
 c9f1616ea8b4c151c13f4dbbbec4b7b9f4694fb5 3972 
glx-alternative-fglrx_0.4.2_amd64.deb
Checksums-Sha256:
 d59f444d6d7543fc293e8f9c46a617e2811b627c3d49c7f6138186ee43530c47 2010 
glx-alternatives_0.4.2.dsc
 da89844d535acde0001d984ea0f4d66c70f009996d63e95301d4abf278b6dc66 9668 
glx-alternatives_0.4.2.tar.xz
 de832e204babd42664c582424566058459c4cb687be2ee50e1a41fafe1157661 9036 
glx-diversions_0.4.2_amd64.deb
 ec11efef86d23c5d5f1ff386719b4e5f2618b695761d4e120fac3a6a4bb99454 3072 
glx-alternative-mesa_0.4.2_amd64.deb
 c056bd3cc3eb1d8bc77d9c12253f8fe897310d2f3d21f022203bb8125ee0e2d8 3652 
glx-alternative-nvidia_0.4.2_amd64.deb
 bc8dc3b42c891036e2679ab3bbbd8850723ef6fed57b701b39c6710ef615d4fc 3972 
glx-alternative-fglrx_0.4.2_amd64.deb
Files:
 20fcc659c269992640bcfd7d17b38d1e 9036 contrib/libs optional 
glx-diversions_0.4.2_amd64.deb
 074ef2666acefc6f9662666a3edbcb3f 3072 contrib/libs optional 
glx-alternative-mesa_0.4.2_amd64.deb
 298c92450aa8cdc7361fd04ff15e76e4 3652 contrib/libs optional 
glx-alternative-nvidia_0.4.2_amd64.deb
 3860ea78c41cf817eb72ccbfeb6c7dac 3972 contrib/libs optional 
glx-alternative-fglrx_0.4.2_amd64.deb
 3b8af8340f45c4ad44638ecb46e6a349 2010 contrib/libs optional 
glx-alternatives_0.4.2.dsc
 08637d618cbe020fcdde3ba457a540e7 9668 contrib/libs optional 
glx-alternatives_0.4.2.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUJvqnAAoJEF+zP5NZ6e0Ipo4QAJ1FxAOXr1K1I4N3ad92sBio
G62fbZyA10iO/jQsrXtRmOJs4hjlb8PndYylJD4KHGWkj1Dfv+403l8w42MHOWa0
igxsjUYNqnsLMxQ8lakbgv+zgYjnmfyIng0hD6TqETHEcbuJD3PNQsU5TgGz8SfP
qmoyCt2DidNNyGlkgX+4IyJteMojHHjTOoWk4buMS3Kq1EnKnkPvyenghu4Guh+B
NiQ480i/BeB2GQfx6hTnfUF4VddXM7Csqgu3+m2yloht1WsGsrstbyJv3B/XkZlP
DhbkhlqgTOS9UlOab9yc5a83btnS1CpguMIxhWpaK/5xyizuiMF6oAV+CZxxo3fK
FVz7HuWpxSYCUKpYNVwr3riwEbyCFuTiF9eULL7tnUm14f3s4Po3KvbQmoZzRr3p
Bkgo9aidaKKd1E0h4xM7S6M8Atc7vZKk9AVC5Oj7me1fQpbZj5Jt+eAdaOLUl5wX
yW4xxGb883BS1J75Z4gsyP2LlQ53CsZLPVDQ9uRIVweWO0jo7mgUppBiVskalUCE
vrhWv/o2lTWj3Nt++IG53oIFhTrkjNZ8RXVCkibelo6XYRC5iTi2SolpI/2gENln
nnWgmsCQg+I4xYPkgV1P3qle59NOiRLFFSGMfOsvQXHsgIBvFrBf++ckqPqF2y8t
bbXeoSkUv+Kv//S1vsCo
=m2FD
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xxwln-0001a3...@franck.debian.org

Re: llvm-defaults vs update alternatives

[Thorsten Glaser]

Sylvestre Ledru sylvestre at debian.org writes:

  Build systems that ignore those environment variables are broken and
  need to be fixed.
 
 Yes, but we have plenty of packages not honoring CC, CXX or CLFAGS.

Yes, but I have a GCC patch (in MirBSD) that can make such builds
fail, by adding a non-standard option to CFLAGS whose lack can,
depending on an environment variable, cause an error or warning.

Then just rename cc/gcc to debian-gcc and set $CC to that, so
that invoking just cc or gcc will also fail, et voilà.

I invented this patch after we had real trouble with lots of
packages not honouring CFLAGS in MirPorts, and it has made its
way via FreeWRT to OpenWrt and other systems already… (although
I did not cover the C++ case, it is easy to add).

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/loom.20140624t104244-...@post.gmane.org

Re: llvm-defaults vs update alternatives

[Vincent Danjean]

On 22/06/2014 11:47, Christian Hofstaedtler wrote:
 update-alternatives gives the user a choice,

My remark is not directly related to this problem (perhaps, in fact)
but update-alternatives does *not* give the user a choice.
It give the *admin* a choice.
You must be root to run update-alternatives and the choice affects
all users of a system. If you are in a multiuser environment (or
want to support such one), update-alternatives is not a solution.

I would be very pleased if update-alternatives can work for users,
at least for most packages. But it is another discussion.

  A+
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53a81048.7020...@free.fr

Re: llvm-defaults vs update alternatives

[Christian Hofstaedtler]

* Sylvestre Ledru sylves...@debian.org [140622 00:50]:
 Currently, LLVM default binaries are managed by the llvm-defaults package
 (similar to gcc-defaults).
 To sum up, we have binaries like /usr/bin/llvm-nm-X.Y. llvm-defaults
 provides symlinks /usr/bin/llvm-nm to the actual binaries.
 Usually, I manage 3 versions of LLVM in parallel (currently, 3.3, 3.4 
 snapshot).
 
 I saw various complains from users (example:
 https://bugs.launchpad.net/bugs/991493 ) to switch to the
 update-alternatives mechanism. This would allow a quick and global
 switch from a LLVM version to another.

update-alternatives gives the user a choice, which implies that you
can no longer rely on the one specific configuration you would have
chosen ('the recommended configuration').
This basically means that you must test with all possible
configurations (LLVM versions), including those that no longer exist
in a given distribution (users may keep old packages that provide
alternative options).

The pain we've seen in the ruby packages suggests that using
update-alternatives is a bad idea if you have a 'recommended'
choice, as it will change over time and (enough) installed systems
will not follow suit.

I'd strongly recommend against using update-alternatives for
llvm-config.

  C.
-- 
 ,''`.  Christian Hofstaedtler z...@debian.org
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



pgpGjCJU6W5fT.pgp
Description: PGP signature

llvm-defaults vs update alternatives

[Sylvestre Ledru]

Hello,

Currently, LLVM default binaries are managed by the llvm-defaults package
(similar to gcc-defaults).
To sum up, we have binaries like /usr/bin/llvm-nm-X.Y. llvm-defaults
provides symlinks /usr/bin/llvm-nm to the actual binaries.
Usually, I manage 3 versions of LLVM in parallel (currently, 3.3, 3.4 
snapshot).

I saw various complains from users (example:
https://bugs.launchpad.net/bugs/991493 ) to switch to the
update-alternatives mechanism. This would allow a quick and global
switch from a LLVM version to another.

I must admit that I am not sure what to do here.
I see values in both solutions.

Any opinions on the subject?

Cheers,
Sylvestre


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53a5b6e7.1050...@debian.org

Re: llvm-defaults vs update alternatives

[Vincent Bernat]

 ❦ 21 juin 2014 18:46 +0200, Sylvestre Ledru sylves...@debian.org :

 Currently, LLVM default binaries are managed by the llvm-defaults package
 (similar to gcc-defaults).
 To sum up, we have binaries like /usr/bin/llvm-nm-X.Y. llvm-defaults
 provides symlinks /usr/bin/llvm-nm to the actual binaries.
 Usually, I manage 3 versions of LLVM in parallel (currently, 3.3, 3.4 
 snapshot).

 I saw various complains from users (example:
 https://bugs.launchpad.net/bugs/991493 ) to switch to the
 update-alternatives mechanism. This would allow a quick and global
 switch from a LLVM version to another.

I don't think alternatives should be used for versioning. For example,
we don't use alternatives for gcc, neither for Python. We would start
getting errors about package X does not compile on my system or
module Y does cannot be compiled.

In the bug report, I just see that some upstreams didn't account for
multiple versions installed. But since it is something that exists for a
long time to choose the C compiler (and some other tools), I think they
will eventually adapt.
-- 
Test programs at their boundary values.
- The Elements of Programming Style (Kernighan  Plauger)


signature.asc
Description: PGP signature

Re: llvm-defaults vs update alternatives

[Paul Wise]

On Sun, Jun 22, 2014 at 12:46 AM, Sylvestre Ledru wrote:

 Any opinions on the subject?

There is already the CC (and CXX etc) environment variable to select
the compiler, they should use that.

Build systems that ignore those environment variables are broken and
need to be fixed.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6gs1wuumai1pdlazrnatm8gulqgn-756dg4c-vl3rk...@mail.gmail.com

Re: llvm-defaults vs update alternatives

[Sylvestre Ledru]

On 21/06/2014 19:19, Paul Wise wrote:
 On Sun, Jun 22, 2014 at 12:46 AM, Sylvestre Ledru wrote:

 Any opinions on the subject?
 There is already the CC (and CXX etc) environment variable to select
 the compiler, they should use that.
I am not talking about Clang but LLVM here. LLVM itself ships some binaries:
https://packages.debian.org/sid/amd64/llvm-3.4/filelist
About Clang, I am planning to keep on matching what is done with gcc.


 Build systems that ignore those environment variables are broken and
 need to be fixed.

Yes, but we have plenty of packages not honoring CC, CXX or CLFAGS.

Sylvestre


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53a63dea.8050...@debian.org

Bug#751675: ITP: libstring-print-perl -- module providing (s)printf alternatives

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann gre...@debian.org
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libstring-print-perl
  Version : 0.15
  Upstream Author : Mark Overmeer
* URL : https://metacpan.org/release/String-Print
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module providing (s)printf alternatives

String::Print inserts values into (translated) strings.  It provides printf()
and sprintf() alternatives via both an object oriented and a functional
interface.


signature.asc
Description: Digital Signature

Accepted glx-alternatives 0.4.1 (source amd64)

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 24 Oct 2013 03:08:49 +0200
Source: glx-alternatives
Binary: glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source amd64
Version: 0.4.1
Distribution: unstable
Urgency: low
Maintainer: Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org
Changed-By: Andreas Beckmann a...@debian.org
Description: 
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
Changes: 
 glx-alternatives (0.4.1) unstable; urgency=low
 .
   * glx-alternative-fglrx: Add a second alternative /usr/lib/fglrx/igpu that
 combines the fglrx driver module with the MESA libGL as it is needed by
 hybrid graphics in igpu mode.
Checksums-Sha1: 
 5cfbf7f3de5d8572bab965ec8eea42a4343ac261 1946 glx-alternatives_0.4.1.dsc
 fc70b16ece762a3c6c250ba35d03cc23a41065b1 10490 glx-alternatives_0.4.1.tar.gz
 7740344a3a88a4d639cf7e1fb65ccefc6b518aae 8794 glx-diversions_0.4.1_amd64.deb
 8411a533cb32b20ab1153cd94b4a5efcf17f60b6 2852 
glx-alternative-mesa_0.4.1_amd64.deb
 bb045a03f29f818421d832801af2603a859d8a20 3438 
glx-alternative-nvidia_0.4.1_amd64.deb
 80868f3b0f4a9dbd99c4d69aac626e8025379767 3714 
glx-alternative-fglrx_0.4.1_amd64.deb
Checksums-Sha256: 
 631d4b21fda8c8bcfe9c509904033b64abe91cec22ee34f394e5f6d03f3f9ac8 1946 
glx-alternatives_0.4.1.dsc
 681b51ff4253f2d9b022743676fdc9539ca4ee3555dbc4d7511f743d49fc169d 10490 
glx-alternatives_0.4.1.tar.gz
 2fc80b890f01244e943408e17741e20e7c966c3a9a5e40fbed2e293b7cf9c57d 8794 
glx-diversions_0.4.1_amd64.deb
 d0d197c3ec1a2268014ce5d43253d0c498ec597aa548d11b93b34f74a4aebf9c 2852 
glx-alternative-mesa_0.4.1_amd64.deb
 0be68ae6822f8919cb1d47622e8cda2d37427fba205eab5255a8c37379be849f 3438 
glx-alternative-nvidia_0.4.1_amd64.deb
 fdac493ac7f67a9e2ad9e79f6a8969e428935994baa9892b11ae863ea1ad874a 3714 
glx-alternative-fglrx_0.4.1_amd64.deb
Files: 
 94ba1c3019dcd6e1fc92f9390d432474 1946 contrib/libs optional 
glx-alternatives_0.4.1.dsc
 a2a168ed82188c728c0ea38e3f7f86b5 10490 contrib/libs optional 
glx-alternatives_0.4.1.tar.gz
 4a730e085183bc38b5c4985846bed1e7 8794 contrib/libs optional 
glx-diversions_0.4.1_amd64.deb
 e1d1a77a51216518ea4d688a10031aaf 2852 contrib/libs optional 
glx-alternative-mesa_0.4.1_amd64.deb
 4b1dbc7bb1a6934f9ec31920e3ac5eff 3438 contrib/libs optional 
glx-alternative-nvidia_0.4.1_amd64.deb
 0b16a596e3c5326966d0a3b2535df49f 3714 contrib/libs optional 
glx-alternative-fglrx_0.4.1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJSaHPJAAoJEF+zP5NZ6e0IIvwP/R3HGftVMxW0cVhW+sLpfGr2
J5xRWKZiv3lDLtjT7FpmbSSz72m5AbSrvoOqobmmc/KTmhF2wrNSLU1NR/FnHM8j
Dtyq9tTytzkHX6a2PLiv/OqT1MHgtBFmyhqYZLYzuvsgOrLLhbWH+ne2ZfaDQkcO
TX/8WlBrcD5vU1RYIx4LjzAetz5wjKmsScYyxO2OS2qxxOdz9YzhVVkQjWGd16Ui
eXqWy3L3K61/fhof6wGQdxZH+czTIX7J5dPAG4kAMCNOn+eMCeVo2rms2+leQ4Ej
LkBTUE30LSlSO5Hjn00q4fQpaiAIaDtUwKG1eOsnoEAVOrR+2jvqcxKA6g+IG9rw
luMglrxPg7QblVUu0BqWcZCYQzVUyZQwlgphI2xdyNECPt5NO80D1NC79OedgvN1
RxDq2tsIHzB0y4bQvhKdUyaLFVSXIA9+GT6GyqbNX/oFDa5YJcw5yCieWdemmVfQ
2SCIqVE51/OGSdbWqbneGnAEYSBTgWI8zCZYTl45ynrc778ICZJByRiiGHBG3ZUJ
nvO4eH6kZPjRoALaJSAFXC32AYZJZaD3++OkbhMo/wbnX6AI0GmAAoSYQRsU4gYq
xUyaZnCD5Sb4XYLhz9YXN/d02yXg3D8cH6TALJN9u/jKFaXUnijoiAWWuzXGL5FK
Qro9rMERgsKYjfFdXrVd
=aynb
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1vz9za-0001m4...@franck.debian.org

Accepted glx-alternatives 0.4.0 (source amd64)

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 17 Aug 2013 06:11:06 +0200
Source: glx-alternatives
Binary: glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source amd64
Version: 0.4.0
Distribution: unstable
Urgency: low
Maintainer: Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org
Changed-By: Andreas Beckmann a...@debian.org
Description: 
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
Closes: 712304
Changes: 
 glx-alternatives (0.4.0) unstable; urgency=low
 .
   * Accept libGL.so.1.2.0 (from MESA 9.x) as a valid target of the diverted
 libGL.so.1 symlink.  (Closes: #712304)
   * Add triggers for arm-linux-gnueabihf, too.
   * Upload to unstable.
Checksums-Sha1: 
 47c644587e3de1875d01e6b413377b9f087d1563 1946 glx-alternatives_0.4.0.dsc
 ddf7985a5f3411d0e2b326e7ed9d3ecf114f98aa 10311 glx-alternatives_0.4.0.tar.gz
 a481512d40de5fcce84af1ec6c05181a24780fab 8706 glx-diversions_0.4.0_amd64.deb
 747a2cbad39d410d14e05e9f2640c17d57bfddc1 2846 
glx-alternative-mesa_0.4.0_amd64.deb
 b84aee090ac3273d2ff5f4f0e07b66c95ca6b60a 3440 
glx-alternative-nvidia_0.4.0_amd64.deb
 a0d3c93aec46107d839109fd498442184d0c5902 3610 
glx-alternative-fglrx_0.4.0_amd64.deb
Checksums-Sha256: 
 10539a40759fc7d77178db06345b9d7a8518acf7176dea8be791d1fc9ed688c8 1946 
glx-alternatives_0.4.0.dsc
 38aa5fccad3866ded21b1d8729de53c7541f14b64db2a03ba386a05445ea54e8 10311 
glx-alternatives_0.4.0.tar.gz
 34034b8104225551c9c08fcb60bac69e99cb43c670d65ec527f2d03e8660e1e1 8706 
glx-diversions_0.4.0_amd64.deb
 f5bab4c32c587aed81d6ee99e4048057264872308dcfd02bb31ad0aa7cbc100a 2846 
glx-alternative-mesa_0.4.0_amd64.deb
 549c74ebe4acdf1d99216a1a7e0467b56f7fb0e602b82f3df0feed7f803c5825 3440 
glx-alternative-nvidia_0.4.0_amd64.deb
 f29de6f454f12611359459eb6916b459ddb0c7e6cde4215241aa3b06cb7f7564 3610 
glx-alternative-fglrx_0.4.0_amd64.deb
Files: 
 82f00c918259ccfc2e879779afed4b26 1946 contrib/libs optional 
glx-alternatives_0.4.0.dsc
 70d6c4955ade4e2012a458e4db43a64f 10311 contrib/libs optional 
glx-alternatives_0.4.0.tar.gz
 3cdf0cc2fb850fac074b624eea421721 8706 contrib/libs optional 
glx-diversions_0.4.0_amd64.deb
 3e05284c3b4839481f6c8db8017247b5 2846 contrib/libs optional 
glx-alternative-mesa_0.4.0_amd64.deb
 875638d577d133e91b5b3bc50a42d295 3440 contrib/libs optional 
glx-alternative-nvidia_0.4.0_amd64.deb
 9cfdf4dcddbd9cecb8a71fec38beb9b2 3610 contrib/libs optional 
glx-alternative-fglrx_0.4.0_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJSDvkIAAoJEF+zP5NZ6e0IqvoP/0dn8Gc6GsixJsdmzoy+hZTE
pCWMub2C/sU2xCMeSf1ViHmyU+NsYX0CY1uzSF82rbRJEBXen47HYXUZJ/JKZMfw
QbBnN9/EOcfLNP7kAXD6IULqYFbN2zwDB9Gs8q3tQsX1irym/snqRR6KzHuV41e/
lhNvIb7CnOgdO8v8fZiYpgkouKIB+SrHFsdtcwOznI0fK2/Jhm/POAWUmssBXYuw
k5Q8dsqWlHy0pvoqu4+eSP02kjLh9fIfzZDqz6WGqPIQfDeY+M/71JkcUkvPNJ3/
Svr43448q1Rij8hy2R2o0NXBxloGiwk9ElarUaCfTC7aMzbF98kvfxwPQ2/T2JiU
idb7eEghm387sEVuNj0ISQHiS7HBv9V48Vo3vPEbn05kMiDwwKHul0yzG5iJy1wM
SzfYykl8hox6TDWiGBWH7Bh7C3Q+kmUaNHBzyOiw/CXZXOw/R5jkWnakLFqfMqRG
MuIAeYONgxr0nRl1lT443kDCROZWvvwEEk9mIfMPLp0ruSQU7faAieIxN6mxzhSO
EKI1jUmcFMRO9718XTdzMpA9IStnpgIk+sNgJs7BwFw8XEMDP6gPiJbv/GdbGvMU
jJSPzcSY6B6GiKd/0NhOWtadDrapqOEElyM0W5u9FjFCDVh7rI4GMmSQGZ47FT7J
zbLJH8aJaslRpu295rre
=6gyS
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1vaycc-ec...@franck.debian.org

Accepted glx-alternatives 0.3.90 (source amd64)

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 16 Jul 2013 11:58:19 +0200
Source: glx-alternatives
Binary: glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source amd64
Version: 0.3.90
Distribution: experimental
Urgency: low
Maintainer: Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org
Changed-By: Andreas Beckmann a...@debian.org
Description: 
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
Changes: 
 glx-alternatives (0.3.90) experimental; urgency=low
 .
   * Add arm-linux-gnueabihf support and enable building on armhf.
   * Upload to experimental.
Checksums-Sha1: 
 edd562bd8f5077633111ac9cd88c4280f9d34a16 1950 glx-alternatives_0.3.90.dsc
 08bfdd1e327471c36860456cc6123dd40cfb37d7 10280 glx-alternatives_0.3.90.tar.gz
 db1af6e646795a8d04f1c248bd364e97e7c3bc56 8798 glx-diversions_0.3.90_amd64.deb
 8a2c0858d3da2aa43bc9ba6afa5525bc4bd42d30 2718 
glx-alternative-mesa_0.3.90_amd64.deb
 972844478a3ef39d05df25585de3c9f733fe755d 3406 
glx-alternative-nvidia_0.3.90_amd64.deb
 dc0f65caff1961856218b3af385def40a13be7aa 3562 
glx-alternative-fglrx_0.3.90_amd64.deb
Checksums-Sha256: 
 43c27b3cf553ad8687686bb9a40ba6f034b058d63685bb292ba74f28db4c719f 1950 
glx-alternatives_0.3.90.dsc
 b57312eea0f8497b14ccc71ce9569e11f6160dcb02ddbfcdecc4690bf8aa3420 10280 
glx-alternatives_0.3.90.tar.gz
 e3ab5cc482510f0d89db7aef0bdfed85ae4cd15c323baa2e13a3d88ccf362b6d 8798 
glx-diversions_0.3.90_amd64.deb
 9235df463b37364fe52b70daa33e87bf22bf2178387a422e4bb29ec08c4e4b03 2718 
glx-alternative-mesa_0.3.90_amd64.deb
 6bc10d280518246f52c611ef90133ddbb53b671e8e12d18536d50ffa5e23f92e 3406 
glx-alternative-nvidia_0.3.90_amd64.deb
 67c5262da4085443ae07b8734a98ce12fbb0b494d9dfc50024983de0a851cf82 3562 
glx-alternative-fglrx_0.3.90_amd64.deb
Files: 
 0e7e877a271da5b78aa4152d8ef7f8e7 1950 contrib/libs optional 
glx-alternatives_0.3.90.dsc
 f75cfbf52965fcba841229dbf34093bf 10280 contrib/libs optional 
glx-alternatives_0.3.90.tar.gz
 422392b4141b86f81f1705ad7f8accf3 8798 contrib/libs optional 
glx-diversions_0.3.90_amd64.deb
 bf2901b93c01629a3991966268caa364 2718 contrib/libs optional 
glx-alternative-mesa_0.3.90_amd64.deb
 f188e0ac3cbab10c47022154526177d3 3406 contrib/libs optional 
glx-alternative-nvidia_0.3.90_amd64.deb
 641d79a31ac4f8d2bab65f6bffe0eb6a 3562 contrib/libs optional 
glx-alternative-fglrx_0.3.90_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJR5RzkAAoJEF+zP5NZ6e0IAI0P/R6ZmjZ6BQiSoNoKi0EqDKLM
O7/h0OgPXINvdkP1zgNg7EfYS4iRSfigbLSBqFhkKEKnuOZipNYDd05Am3uoR11s
MFluclfK9Ok7Z4tFcrKCTVwTzAZn02teZitwRxjI+n3SdQyj68EJ2GHu0uWBxGpr
hon8WH9RArd1zJh3giayBhXXbCqM0DKzImrRNCoQJPPDXBLbFdgce2KZomVUjmu0
vGZLRDunajBBMeaxCRLypDQLZBk2wPL5o3Ensin5GU3njXWKnhYxQ1CXMoBR0LD7
877csKuJlTi2HJmiVWdDxOueqlaTQQuROCeRdFWueI0prLaSM/mGx9pHkP/q4e3Y
muS6wffgGRcajcj75qCUxhCETZj3fOT7/WVJLSIF/8fJw6UYxFehDBfx6xJQppcS
t8zKrFuZkrHXn8EAMryqUvqDf3M0RD7ju7LKGhxRC18oiVPtDivHefXxOjDAKRFa
TbhUUi7hO8QpQaCEmNYmN1kltZzKzWoFvROZJDG2cjlMpKoehALjQ/K6oJyIjxS4
9MQAqjdLeOW2VmYlEu6WqiDf4yZRTktJU84rAimpbGuB7MAqA6UOV8mEhVU9l2jk
NkC7LrLsNPJLlWaxf2qzYyUL0aIOpbgmzGRX1rVOYLyzZ+JYbaFGJhrJPmkBdozE
hwGjVA87C2cUJkGRprAg
=Xpje
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1uz2la-0003za...@franck.debian.org

Accepted glx-alternatives 0.3.0 (source amd64)

[Andreas Beckmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 05 May 2013 15:25:15 +0200
Source: glx-alternatives
Binary: glx-diversions glx-alternative-mesa glx-alternative-nvidia 
glx-alternative-fglrx
Architecture: source amd64
Version: 0.3.0
Distribution: unstable
Urgency: low
Maintainer: Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org
Changed-By: Andreas Beckmann a...@debian.org
Description: 
 glx-alternative-fglrx - allows the selection of FGLRX as GLX provider
 glx-alternative-mesa - allows the selection of MESA as GLX provider
 glx-alternative-nvidia - allows the selection of NVIDIA as GLX provider
 glx-diversions - prepare for using accelerated GLX implementations from GPU 
vendor
Closes: 704914
Changes: 
 glx-alternatives (0.3.0) unstable; urgency=low
 .
   * glx-diversions: Divert libGL.so.1.2.0 from MESA 9.x.  (Closes: #704914)
   * Drop maintainer script parts intended for updates from versions predating
 wheezy.
   * Use canonical Vcs-* URLs.
   * Bump Standards-Version to 3.9.4. No changes needed.
   * Switch to debhelper 9.
   * Update my email address and remove DMUA.
   * Upload to unstable.
Checksums-Sha1: 
 3fcd10fff1a0713ba0b373f0a1d3907042a91fdd 1940 glx-alternatives_0.3.0.dsc
 d730dbf1dcf4a8b119f1132b74d648932a4e5835 10216 glx-alternatives_0.3.0.tar.gz
 c8f273febe6b29de21aaa431d5ec9f6ad25dbc7c 8978 glx-diversions_0.3.0_amd64.deb
 1ac3a4bf184f1451081c50eb77a09f4cae8da6c5 2708 
glx-alternative-mesa_0.3.0_amd64.deb
 b811dcbc04aae34a20dcc68350253999ea9f032f 3396 
glx-alternative-nvidia_0.3.0_amd64.deb
 194a64f26020816d754a4c44b08d7b729aeef22a 3548 
glx-alternative-fglrx_0.3.0_amd64.deb
Checksums-Sha256: 
 8b80e46266a2352b08f33a779d6c14071caa6a85257ecfcf4d145a0dbb3d91ce 1940 
glx-alternatives_0.3.0.dsc
 f7528acd2bbfe2a31cace9f94a78283b59cb738bf0fa01a581a4e632a396b07d 10216 
glx-alternatives_0.3.0.tar.gz
 fcdc2026b774874cdc3467a7c328580e6b09edf19e8c5e171ff73982ca8f24e0 8978 
glx-diversions_0.3.0_amd64.deb
 e92ba09ccf29df611a91a7de999ba6bbaa57b3aa838ed75d719f2ad5c92500f5 2708 
glx-alternative-mesa_0.3.0_amd64.deb
 9aa1eecc24bec16d1fa5f655cecaccd41dbc7ff7f26be7d3d905ae605598e503 3396 
glx-alternative-nvidia_0.3.0_amd64.deb
 ec1e1f25940e63a7d1afef20d7145a61752b460c559035c81e4f86c14ff916b9 3548 
glx-alternative-fglrx_0.3.0_amd64.deb
Files: 
 c76dc707c6d73f8eb0a2409eed8919f8 1940 contrib/libs optional 
glx-alternatives_0.3.0.dsc
 c5da0912c71fa97a0c2aa5e2b6fec0d4 10216 contrib/libs optional 
glx-alternatives_0.3.0.tar.gz
 17538be109f797d41cc9a6f36a01cda2 8978 contrib/libs optional 
glx-diversions_0.3.0_amd64.deb
 3f6d183b331a39aa297474f4302c49cb 2708 contrib/libs optional 
glx-alternative-mesa_0.3.0_amd64.deb
 671691b01ed064137c66e4bb46a74704 3396 contrib/libs optional 
glx-alternative-nvidia_0.3.0_amd64.deb
 5196d59356884120f5101bf9840c3acd 3548 contrib/libs optional 
glx-alternative-fglrx_0.3.0_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJRhmRyAAoJEF+zP5NZ6e0IMzIP/im6Rnra1iQZgAh/p8+kP61l
4AgjqWrcMM5UtDsXIXU1zW0bqNscbWl4VuklQLtFRvd+pRgx2oIkJ2T5jlqsTKn9
6ejnsIBnJ8BFTWtlfp3Lf5NwlzNdj19R+ep8WNeGk90bX30ZrhrNg8oVzCt2TJVh
Z2oayLYTrCcJCnnW3Zu7P2rWXu/JXr6mgX5Q36UXGo7IRdvOtgxyUr9nr324Cxvw
ay3eryo8gQn0TLQ9N0h6h1PEaTTucCK6SLYiKwYJpk6K6M4RvdP51Lcyg3lK8E+R
LWR160v6OdP3R7/NRoBMsG4UNLYQ7GdvDAiiuwEwYg6+Ues0ViJxmLnqji2/tfZp
YGzVcox7BPx/LaPMDy7j5U8LnMP5WAnaKyqqd6gdAD69Onbvslz1XUZOTmwKg3pV
hqwSJ6Rs5ZIKwn3BmlzuJqN/rKGloTipSPOks+turbXqqiF73QpoNHIehofypYbx
wuRyIKS3jEolObhdZDzOUK7qG+1nOTgOAvOKXyjyqD8fL4s3wS2YA905VHAwyGVO
qbOjT1Xdfn3O1229VIJJnoWoEUtXFDcy3FfP5VI53j1SihJLUV1+3e+VU6bxc8a/
p7XdQIWwO9kquK19WNKJdv/7bbW2zNUGGLtGsD8OOaVU4gHmGoVM6xyTMUMXD4G+
yfXeAqPobvPz66vs0Wh7
=K+vv
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1uz0uc-0005dy...@franck.debian.org