Quoting Russ Allbery (2017-03-09 04:24:09)
> Adam Borowski writes:
>
> > I'd like to discuss (and then propose to -policy) the following
> > rule:
>
> > # Libraries which don't provide a convenient means of conditionally
> > # loading at runtime (this includes most libraries for languages
> >
On Thu, Mar 9, 2017 at 11:48 AM, Michael Biebl wrote:
> out of the box. Unfortunately we don't have a well supported mechanism
> which would install such hardware-enablement packages when the hardware
> is plugged in.
Is the AppStream hardware support stuff not well supported in the desktops?
ht
Am 09.03.2017 um 04:24 schrieb Russ Allbery:
> Adam Borowski writes:
>
>> I'd like to discuss (and then propose to -policy) the following rule:
>
>> # Libraries which don't provide a convenient means of conditionally loading
>> # at runtime (this includes most libraries for languages such as C),
Ian Jackson writes:
> Adam Borowski writes ("Depends/Recommends from libraries"):
>> I'd like to discuss (and then propose to -policy) the following rule:
>>
>> # Libraries which don't provide a convenient means of conditionally loading
>> # at runtime (this includes most libraries for languages
Adam Borowski writes:
> I'd like to discuss (and then propose to -policy) the following rule:
> # Libraries which don't provide a convenient means of conditionally loading
> # at runtime (this includes most libraries for languages such as C), SHOULD
> # NOT declare a "Depends:" or "Recommends:"
Adam Borowski wrote:
> I'd like to discuss (and then propose to -policy) the following rule:
>
> # Libraries which don't provide a convenient means of conditionally loading
> # at runtime (this includes most libraries for languages such as C), SHOULD
> # NOT declare a "Depends:" or "Recommends:" re
Adam Borowski writes ("Depends/Recommends from libraries"):
> I'd like to discuss (and then propose to -policy) the following rule:
>
> # Libraries which don't provide a convenient means of conditionally loading
> # at runtime (this includes most libraries for languages such as C), SHOULD
> # NOT
Hi, mortals and paultag!
I'd like to discuss (and then propose to -policy) the following rule:
# Libraries which don't provide a convenient means of conditionally loading
# at runtime (this includes most libraries for languages such as C), SHOULD
# NOT declare a "Depends:" or "Recommends:" relati
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: golang-github-bluebreezecf-opentsdb-goclient
Version : 0.0~git20160515.0.539764b-1
Upstream Author : Jianwei Shi
* URL
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: golang-github-smartystreets-go-aws-auth
Version : 0.0~git20160722.0.2043e6d-1
Upstream Author : Michael Whatcott
* URL
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: golang-github-quobyte-api
Version : 0.0~git20160913.0.bf713b5-1
Upstream Author : Quobyte Inc.
* URL : https://gi
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: golang-github-exponent-io-jsonpath
Version : 0.0~git20151013.0.d6023ce-1
Upstream Author : Exponent Labs
* URL :
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: golang-github-renstrom-dedent
Version : 1.0.0+git20150819.3.020d11c-1
Upstream Author : Peter Renström
* URL : ht
Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta
* Package name: ruby-psych
Version : 2.2.4
Upstream Author : Aaron Patterson
* URL : https://github.com/ruby/psych
* License : Expat
Programming Lang: Ruby, C, Java
Description : A libyaml wrapper
❦ 8 mars 2017 12:41 +0100, Adam Borowski :
> [1]. I'm curious what mail clients support page feeds; for example pine (the
> BSD-but-proprietary one) allowed \e through unmolested, which allowed for
> colour on the nice side and (via terminal backtalk) security issues on the
> non-nice.
Gnus su
Sean Whitton writes ("Re: Non-free RFCs in stretch"):
> Could you explain why you want to do this with metapackages, rather than
> extending the definition of an archive section so that non-free and
> contrib may be more finely divided up? The various implementation
> problems that have been raise
On Wed, Mar 08, 2017 at 09:09:13AM +0100, Joerg Jaspert wrote:
>
> > we have human ftpmasters
>
> You sure? When did u last check? How thouroughly?
>
>
^[1]
>
> Not good enough, I'm sure.
Right! Forgot at least paultag; not sure about the divine rank or species
of the rest of you, my bad.
Hi,
This is all useful information. My mail was meant to explain the
process.
All these answers should be integrated in [1] before starting the
official
discussion period with project members.
[1]
https://wiki.debian.org/DebianTaiwan/ocf.tw/TrustedOrganizationCriteria
On 2017-03-08 03:33,
> we have human ftpmasters
You sure? When did u last check? How thouroughly?
Not good enough, I'm sure.
--
bye, Joerg
19 matches
Mail list logo
