Bug#988484: Bug#974678: ITP: openh264 -- H.264 encoding and decoding
> "Bastian" == Bastian Germann writes: Bastian> There are H.264 patents that are applicable. I do not know Bastian> how the existing H.264 implementations in Debian handle Bastian> this, e.g. x264 or ffmpeg. According to the legal FAQ, Bastian> these seem to be ignored. I suspect you meant to say that there are H.264 patents that may be applicable and that Debian should evaluate this risk using its normal proocesses and policies for looking at software patents. THOSE PROCESSES DO NOT INVOLVE debian-legal. Discussing patents in a public forum may result in speculative communication--like the assertion above where you said that patents are applicable and where you probably meant to say that the patents may be applicable--being produced in response to allegations of patent infringement. That harms Debian. Thus, we have a policy that we discuss patents only in privileged communication. See https://www.debian.org/legal/patent and if you are concerned about a specific patent risk, write to pate...@debian.org. signature.asc Description: PGP signature
Re: RFC: endorse debian-mentors as entrance to our infrastructure projects
Paul, it's really cool to see that you are open to this. I wonder whether it might be a good idea to write down which infrastructure services people in the mentors community are most able to help with. I don't want to discourage people from for example asking dak questions, but it might be valuable to indicate that for example we have better coverage of LDAP than dak (assuming that's true). I find setting expectations helps avoid frustration. --Sam
Re: RFS: libapache2-mod-auth-kerb -- Apache2 module to authenticate connections using Kerberos
ms419 == ms419 [EMAIL PROTECTED] writes: ms419 mod-auth-kerb is a terrific Apache module to authenticate ms419 connections using Kerberos; it even supports GSSAPI ms419 negotiation (SPNEGO) - ie. single sign on authentication ms419 using Apache2 Kerberos! ms419 I repackaged mod-auth-kerb for Apache2 added some more ms419 documentation: ms419 http://cgi.sfu.ca/~jdbates/moin/moin.cgi/KerberosApacheModule I understand people want this. I'm really somewhat swamped now and the openafs and krb5 packages have been taking priority. Some stuff has also come up at work recently. I will get to evaluating a patch sitting in the BTS, I'm just not doing so as quickly as I'd like. If A Debian developer familiar with the Kerberos stuff wants to volunteer to evaluate the patches, they should contact me. --Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: building a sponsored package
Colin == Colin Watson [EMAIL PROTECTED] writes: Colin I think that would be appropriate. Colin Exactly what are the intended semantics of Maintainer: and Colin Changed-By: in the .changes file (not the .dsc)? In Colin particular, when sponsoring a package, which field in the Colin .changes should contain the name of the uploader and which Colin the name of the sponsored developer? Maintainer should contain the name of the NM applicant so he/she gets bugs. changed-by should contain the name of the sponsor. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: building a sponsored package
Colin == Colin Watson [EMAIL PROTECTED] writes: Colin I think that would be appropriate. Colin Exactly what are the intended semantics of Maintainer: and Colin Changed-By: in the .changes file (not the .dsc)? In Colin particular, when sponsoring a package, which field in the Colin .changes should contain the name of the uploader and which Colin the name of the sponsored developer? Maintainer should contain the name of the NM applicant so he/she gets bugs. changed-by should contain the name of the sponsor.
Re: Integration of debian/ scripts in packages
Michèl == Michèl Alexandre Salim [EMAIL PROTECTED] writes: Michèl Hello, A general observation of Unix programs in general - Michèl a lot more of them come with RPM spec files, even Michèl generates them automatically from a spec.in file, than Michèl with debian scripts. A lot of this has to do with the relative value of doing so. An RPM outside of the Redhat archive is more common than a deb outside of the Debian archive. Debian is willing to accept most DFSG free packages into its archive, so users can get a good approximation of all the Debian software available by looking at what is in unstable. RPM-based distributions tend to be more selective about what they accept. Thus, a user is going to be just as likely to go to the original author as to their distribution to find software. As a Debian user, I will tend to go to Debian before the original author. If there is a debian directory, I am likely to find it already in Debian and never get to the original author's site. Note that Debian directories outside of Debian have dubious utility. Really only the maintainer should be editing debian/changelog, but yet if debian/changelog doesn't match the version of software, then siginifacnt problems may result..
Re: Integration of debian/ scripts in packages
Michèl == Michèl Alexandre Salim [EMAIL PROTECTED] writes: Michèl The reason I raise this issue in the first place is Michèl actually a notion that it would be nice for users wanting Michèl bleeding-edge software to update from CVS and just run Michèl debian/rules binary or dpkg-buildpackage, the same way Michèl they can rpm -tb package.tar.gz currently (granted, most Michèl of the time one thing or another is broken. Especially the Michèl changelog - rather incredible). And if you come up with a clean solution for the changelog issue, I agree this is worth doing. If you do that, please let me know what your solution is.
Re: Integration of debian/ scripts in packages
Michèl == Michèl Alexandre Salim [EMAIL PROTECTED] writes: Michèl Hello, A general observation of Unix programs in general - Michèl a lot more of them come with RPM spec files, even Michèl generates them automatically from a spec.in file, than Michèl with debian scripts. A lot of this has to do with the relative value of doing so. An RPM outside of the Redhat archive is more common than a deb outside of the Debian archive. Debian is willing to accept most DFSG free packages into its archive, so users can get a good approximation of all the Debian software available by looking at what is in unstable. RPM-based distributions tend to be more selective about what they accept. Thus, a user is going to be just as likely to go to the original author as to their distribution to find software. As a Debian user, I will tend to go to Debian before the original author. If there is a debian directory, I am likely to find it already in Debian and never get to the original author's site. Note that Debian directories outside of Debian have dubious utility. Really only the maintainer should be editing debian/changelog, but yet if debian/changelog doesn't match the version of software, then siginifacnt problems may result.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
