Re: Bug#501190: ITP: moonlight -- open source implementation of Microsoft Silverlight

[Robert Millan]

On Mon, Oct 06, 2008 at 11:08:38PM +0100, Jo Shields wrote:
> 
> You're absolutely right, it's a clone, albeit one officially endorsed by
> those being cloned. My package description is sourced from a
> debian-multimedia package, I'll post a replacement to the ITP shortly.

Thanks.

> However, one
> observation - official Silverlight *does* run on multiple platforms
> (Windows or Mac), just not on Linux or other *nixes. Moonlight is
> officially endorsed & help given to Moonlight developers to help get
> more platforms supported.

Right, and Moonlight is not Silverlight, and since Silverlight is a moving
target it won't be fully compatible with it anytime soon.  Being endorsed
hasn't changed that so far.

> >   - If you want to use ffmpeg, please clarify the legal situation wrt 
> > license
> > incompatibility mentioned by Moonlight's authors in:
> > 
> >   http://tirania.org/blog/archive/2007/Sep-05.html
> > 
> > which appears to have prevented them from using ffmpeg, and forced them
> > into licensing blobs from Microsoft.  Unfortunately they aren't very
> > explicit about what the problem is, but it is certain there is one, so
> > please find that out, and have it discussed in debian-legal.
> 
> Novell don't want to distribute a Moonlight linked against FFmpeg, and
> make themselves targets for patent trolls like the MPEG-LA. That's fair
> enough really

It is (IMO).  But their statement doesn't seem to speak about patents:

  "We are unable to redistribute this code commercially due to licensing 
conflicts."

Though, this ITP is not the best place to discuss legal issues.  I'm just
pointing out possible sources of trouble.  Please, bring this up in
debian-legal, and have the discussion referred to from here.

> > [1] In
> > http://groups.google.com/group/tiraniaorg-blog-comments/browse_thread/thread/2a07b8b50038d8c8/d582162af2d63d57
> > de Icaza states that you need to "get/download Moonlight from Novell
> > which will include patent coverage"
> > [2] http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx
> 
> I don't see how possible but unclaimed patents would make moonlight in
> Debian more dangerous than any software such as wine, linux, samba, OOo,
> ntfs-3g, etc.

Unclaimed patents are precisely the reason we don't have any MPEG encoders
in Debian (see http://techliberation.com/2006/05/11/mpeg-patent-thicket/).

Besides, I don't recall OOo authors saying you must download OOo from Sun
or otherwise you will be endangered, like de Icaza asserted [1].

And I don't recall Microsoft having a web page where it regulates what you
can and can't do explicitly with OOo.

To summarize:

  - $author claims you should download the software from them in order to
enjoy "protection" from patents owned by $this_troll.
  - $this_troll has a web page explicitly dictating what you can and can't
do with $this_software.
  - You want Debian to dismiss all claims because you believe they're not
"more dangerous" than those in wine, linux, samba, OOo or ntfs-3g.

It doesn't sound convincing to me.  And apparently it didn't sound convincing
to others either (e.g. http://fedoraproject.org/wiki/ForbiddenItems#Moonlight).

Would you please bring this up in debian-legal so a proper discussion can be
held?

[1] 
http://groups.google.com/group/tiraniaorg-blog-comments/browse_thread/thread/2a07b8b50038d8c8/d582162af2d63d57

> Upstream are also aware of any concerns we have, and 
> are trying to clear things up where possible.

(offtopic) If I may make a suggestion, tell them to use GPLv3.  It was
purposely designed to solve this kind of problem.

> ** Note, apologies to debian-devel@ for the offtopic nature of these
> messages, my reply is aimed at debian-devel only for mailing list
> archive purposes **

It is standard practice to CC debian-devel in new ITPs.  Though, as I said
for legal discussions please use debian-legal, and afterwards link to the
discussion from here.  You can start a discussion there by pointing to
this ITP.

Thanks

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: List of RC-buggy source packages by maintainer/uploader

[Lucas Nussbaum]

On 07/10/08 at 06:34 +0100, Adam D. Barratt wrote:
> On Tue, 2008-10-07 at 05:56 +0200, Lucas Nussbaum wrote:
> > On 06/10/08 at 18:36 -0500, Raphael Geissert wrote:
> > > Lucas Nussbaum wrote:
> [...]
> > > > Steve Langasek <[EMAIL PROTECTED]>
> > > >firmware-nonfree (U)
> > > >mklibs (U)
> > > >openldap (U)
> > > >php5 (U)
> > > 
> > > Steve stepped down from php's maintenance a couple of uploads ago (he is 
> > > no
> > > longer in Uploaders even in the version in lenny); looks like a bug
> > > somewhere in UDD.
> > 
> > I'm not sure how dd-list really works. I just ran dd-list to generate
> > the per-maintainer list.
> 
> It runs "apt-cache showsrc" (which doesn't include Steve here for php5
> on sid).

It does for me, because I still have php5 5.2.5-3+lenny2 in my apt
cache. I'll run apt-get update before dd-list next time.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: Test Debian : Release Goals, Point release, Foo-n-Half...

[Franklin PIAT]

On Sun, 2008-10-05 at 18:10 +0200, Michael Banck wrote: 
> On Sun, Oct 05, 2008 at 06:02:17PM +0200, Franklin PIAT wrote:
> > The page could have an "Expert" subpage (or let's name it kamikaze, so
> > people don't get impressed by the name ;)
> 
> Frankly, I'm not sure why to have distributions in there at all.

I've further rephrased to something like "system running DebianTesting
falls in this category"

> Clearly, SELinux issues etc. in stable won't get fixed anymore.


That's where wiki pages can be useful (a kind of "Knowledge base").


> Giving people advice on how to test stuff on testing makes sense 
> to me, but we can safely assume unstable users would be able to
> use those hints transparently. 

If we say  something in Unstable section, it is implicitly unsuitable
for Testing...

> In the end, enabling SELinux on testing or unstable is probably roughly
> the same risk, and overloading that page with major advice for running
> testing and/or unstable and their trade-offs looks like diluting the
> message to me.

... and the sections now starts with "Same as above".

BTW, I have re-introduced a "DD Development System", which could/should
list Squeeze release-goals candidates that needs testing.

Franklin


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

Re: List of RC-buggy source packages by maintainer/uploader

[Rafael Laboissiere]

* Lucas Nussbaum <[EMAIL PROTECTED]> [2008-10-06 21:28]:

> Debian Octave Group <[EMAIL PROTECTED]>
>octave-vrml

Fixed in version 1.0.6-3, which was uploaded to unstable and unblocked by
luk.  Should be in testing in three days from now.

-- 
Rafael


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

Re: List of RC-buggy source packages by maintainer/uploader

[Josselin Mouette]

Le lundi 06 octobre 2008 à 21:28 +0200, Lucas Nussbaum a écrit :
> maximilian attems <[EMAIL PROTECTED]>
>linux-2.6 (U)

There are old talks about a possible solution, but none of the
maintainers is answering.

> Dave Beckett <[EMAIL PROTECTED]>
>cairo

Fix is ready, but needs d-i team approval and release team approval
given the impact of the change.

> Bastian Blank <[EMAIL PROTECTED]>
>xen-3 (U)

I’m discussing the issue with upstream and it seems likely to be
resolved soon.

> Simon Horman <[EMAIL PROTECTED]>
>heartbeat

Most likely a user error.

> Joerg Jaspert <[EMAIL PROTECTED]>
>cdrkit

Most likely a user error.

> Josselin Mouette <[EMAIL PROTECTED]>
>epiphany-browser

One bug needs help, the other may be the same showing up in another way.

> Michael Vogt <[EMAIL PROTECTED]>
>synaptic

The bug is definitely important but maybe not RC.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Ben Finney]

Reinhard Tartler <[EMAIL PROTECTED]> writes:

> The best reference for patent enforcments I have is
> http://www.mpegla.com/news.cfm.
> 
> However none of those lawsuits are comparable to debian, becuase:
> 
>  a) debian/spi is a non-profit organisation
>  b) debian does not sell hardware

Many recipients of Debian do meet one or both of those descriptions.

The DFSG require the works distributed in Debian be free for all
recipients of Debian, not just for the Debian project.

-- 
 \“The restriction of knowledge to an elite group destroys the |
  `\   spirit of society and leads to its intellectual |
_o__)impoverishment.” —Albert Einstein |
Ben Finney


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Reinhard Tartler]

Ben Finney <[EMAIL PROTECTED]> writes:

> Reinhard Tartler <[EMAIL PROTECTED]> writes:
>
>> The best reference for patent enforcments I have is
>> http://www.mpegla.com/news.cfm.
>> 
>> However none of those lawsuits are comparable to debian, becuase:
>> 
>>  a) debian/spi is a non-profit organisation
>>  b) debian does not sell hardware
>
> Many recipients of Debian do meet one or both of those descriptions.

I'd say they are still a minority.

> The DFSG require the works distributed in Debian be free for all
> recipients of Debian, not just for the Debian project.

This issue not about 'freeness', the DFSG does not talk about patent or
other restrictions at all. If that were true, we wouldn't have
introduced the non-US section for crypto-export regulated software.

If my analysis and judgement is corrent, it therefore seems most
sensible to me (and upstream!) to introduce a new archive section for
free software (ffmpeg is perfectly 100% free software) that are subject
to MPEG LA patent lawsuit threats. We could of course use 'non-free' as
interim solution, but this would not be in accordance to our policy of
judging software.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: List of RC-buggy source packages by maintainer/uploader

[Julien Cristau]

On Mon, Oct  6, 2008 at 21:28:51 +0200, Lucas Nussbaum wrote:

>xorg (U)

#500228 and #500231 (which want to be merged, I think) shouldn't be RC,
I'll downgrade.

>xorg-server (U)
>xserver-xorg-video-glint (U)
> 
#488669 and #500358 are the same, kernel changes in the sparc64 pci code
broke X; I don't plan to do anything about that, but if somebody cares
the easiest fix would probably be to revert the kernel changes.
#493887 sounds like it's not a regression, so should probably be
downgraded.

Cheers,
Julien


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

Bug#501450: ITP: libeventmachine-ruby -- Event-driven I/O library for high-performance threaded network programming

[Daigo Moriwaki]

Package: wnpp
Severity: wishlist
Owner: Daigo Moriwaki <[EMAIL PROTECTED]>


* Package name: libeventmachine-ruby
  Version : 0.12.2
  Upstream Author : Francis Cianfrocca 
* URL : http://rubyeventmachine.com/
* License : GPL, Ruby's License
  Programming Lang: Ruby
  Description : Event-driven I/O library for high-performance threaded 
network programming

 EventMachine implements a fast, single-threaded engine for arbitrary network
 communications. It's extremely easy to use in Ruby. EventMachine wraps all
 interactions with IP sockets, allowing programs to concentrate on the
 implementation of network protocols. It can be used to create both network
 servers and clients. To create a server or client, a Ruby program only needs
 to specify the IP address and port, and provide a Module that implements the
 communications protocol. Implementations of several standard network protocols
 are provided with the package, primarily to serve as examples. The real goal
 of EventMachine is to enable programs to easily interface with other programs
 using TCP/IP, especially if custom protocols are required.


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (90, 'unstable'), (1, 
'experimental')
Architecture: i386 (i686)



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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Josselin Mouette]

Le mercredi 08 octobre 2008 à 00:07 +1100, Ben Finney a écrit :
> Reinhard Tartler <[EMAIL PROTECTED]> writes:
> 
> > However none of those lawsuits are comparable to debian, becuase:
> > 
> >  a) debian/spi is a non-profit organisation
> >  b) debian does not sell hardware
> 
> Many recipients of Debian do meet one or both of those descriptions.
> 
> The DFSG require the works distributed in Debian be free for all
> recipients of Debian, not just for the Debian project.

Depending on your country, software distributed in Debian may or may not
be free. For example some gore games are believed to be forbidden to
redistribute in Germany. Similarly, there would be restrictions on
redistribution of MPEG encoder in the US. But not in Europe.

It has been already suggested to resurrect the non-us archive for such
cases, but this is not even necessary, since it is not a problem for us
to distribute such software from the US.

At the very least, we could distribute them in a specific "patented"
section, with rules similar to non-free, and that we’d only mirror in
countries where it is not a problem.

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Reinhard Tartler]

Holger Levsen <[EMAIL PROTECTED]> writes:

> On Tuesday 07 October 2008 09:03, Robert Millan wrote:
>> Unclaimed patents are precisely the reason we don't have any MPEG encoders
>> in Debian (see http://techliberation.com/2006/05/11/mpeg-patent-thicket/).
>
> Wrong. We dont have mpeg encoders in Debian because those patents are being 
> enforced.

Can you please backup that claim?

The best reference for patent enforcments I have is 
http://www.mpegla.com/news.cfm.

However none of those lawsuits are comparable to debian, becuase:

 a) debian/spi is a non-profit organisation
 b) debian does not sell hardware

I therefore don't think that we have any evidence that would backup your
claim.  I asked ftp-master several time for clarification on this point,
however I have not been given ANY answer on this topic. If someone has
more details, please followup on [1] and/or [2].

[1] 
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2008-September/002040.html
[2] 
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2008-September/002066.html


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: Bug#501190: ITP: moonlight -- open source implementation of Microsoft Silverlight

[Robert Millan]

On Tue, Oct 07, 2008 at 11:05:58AM +0200, Holger Levsen wrote:
> Hi,
> 
> On Tuesday 07 October 2008 09:03, Robert Millan wrote:
> > Unclaimed patents are precisely the reason we don't have any MPEG encoders
> > in Debian (see http://techliberation.com/2006/05/11/mpeg-patent-thicket/).
> 
> Wrong. We dont have mpeg encoders in Debian because those patents are being 
> enforced.

If by "enforcement" you mean a claim specifically addressed at someone
committing infringement, then no, it isn't being enforced simply because
nobody was brave enough to commit infringement.

If by "enforcement" you mean an effect that can be archieved with open
legal threats, then yes, there's an enforcement that prevents others (e.g.
Fedora or Ubuntu) from distributing it.

Of course, since we're a a non-profit we could test our luck anyway.  It
most likely won't mean anything for *us*, but it will certainly mean our
corporate users will have less confidence on the legal safety of our product.

This begs the question, what do we actually *gain* in compensation for this
risk?  For example, Moonlight wasn't able to play the Chinese Olympics online
videostreams(and even more so without the non-free codecs).  Is there something
Moonlight can do for our users that they weren't able to do before?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Robert Millan]

On Tue, Oct 07, 2008 at 03:44:47PM +0200, Josselin Mouette wrote:
> 
> It has been already suggested to resurrect the non-us archive for such
> cases, but this is not even necessary, since it is not a problem for us
> to distribute such software from the US.
> 
> At the very least, we could distribute them in a specific "patented"
> section, with rules similar to non-free, and that we’d only mirror in
> countries where it is not a problem.

While we are at it, would be nice to have a section for DMCA-impaired software
such as libdvdcss.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Holger Levsen]

Hi Reinhard,

On Tuesday 07 October 2008 12:11, Reinhard Tartler wrote:
> Can you please backup that claim?

Well, no and yes ;-)

You confirm it yourself, but then say its not comparible. I only said that 
those patents are being enforced, which they are. (I didnt mention whether 
thats comparible or not.)

And no, because I only repeated what one ftpmaster told me, after talking to 
him after reading ffmpeg-debians README.


regards,
Holger


pgp2N4T6jmzZD.pgp
Description: PGP signature

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Reinhard Tartler]

Robert Millan <[EMAIL PROTECTED]> writes:

>> At the very least, we could distribute them in a specific "patented"
>> section, with rules similar to non-free, and that we’d only mirror in
>> countries where it is not a problem.
>
> While we are at it, would be nice to have a section for DMCA-impaired software
> such as libdvdcss.

How about this:

 - introduce a new section 'patented'
 - packages in 'patented' must fulfill the requirements of the dfsg
 - source packages in 'main' may produce binaries in 'patented'
 - binary packages in 'main' must not depend on packages in 'patented'
 - source packages in 'main' may build-depend on packages in 'patented'
 - source and binary packages in 'patented' may depend on package on
   both 'main' and 'patented'
 - source packages in 'patented' must not produce binaries in 'main'
 - packages in 'contrib' and 'non-free' may additionally depend on packages
   in 'patented'

This may sound complicated, but would be helpful for e.g. the xine-lib
source package:

 - all binary packages of ffmpeg would go to 'patented'
 - the source package 'xine-lib' would produce most binary package in 'main'
 - the binary package 'libxine1-ffmpeg' would go to 'patented'

Distributors (and archive administrators) that fear lawsuits from the
MPEG LA could then easily stop mirroring 'patented', but still have a
usable section 'main'.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: List of RC-buggy source packages by maintainer/uploader

[Michael Meskes]

On Mon, Oct 06, 2008 at 09:28:51PM +0200, Lucas Nussbaum wrote:
> Michael Meskes <[EMAIL PROTECTED]>
>acpid (U)

AFAICT acpid in Lenny is RC-bug free. But maybe the list was created before the 
package migrated.

>citadel (U)

Unstable version is fine but waiting for migration.

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Didier Raboud]

Reinhard Tartler wrote:

> Robert Millan <[EMAIL PROTECTED]> writes:
> 
>>> At the very least, we could distribute them in a specific "patented"
>>> section, with rules similar to non-free, and that we’d only mirror in
>>> countries where it is not a problem.
>>
>> While we are at it, would be nice to have a section for DMCA-impaired
>> software such as libdvdcss.
> 
> How about this:
> 
>  - introduce a new section 'patented'
>  - packages in 'patented' must fulfill the requirements of the dfsg
>  - source packages in 'main' may produce binaries in 'patented'
>  - binary packages in 'main' must not depend on packages in 'patented'
>
>  - source packages in 'main' may build-depend on packages in 'patented'

This is problematic for a self-buildable main everywhere, no ?

>  - source and binary packages in 'patented' may depend on package on
>both 'main' and 'patented'
>  - source packages in 'patented' must not produce binaries in 'main'
>  - packages in 'contrib' and 'non-free' may additionally depend on
>  packages
>in 'patented'

Sounds good for the rest...

Regards, 

OdyX

-- 
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


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

Re: List of RC-buggy source packages by maintainer/uploader

[Sven Joachim]

On 2008-10-07 11:26 +0200, Michael Meskes wrote:

> On Mon, Oct 06, 2008 at 09:28:51PM +0200, Lucas Nussbaum wrote:
>> Michael Meskes <[EMAIL PROTECTED]>
>>acpid (U)
>
> AFAICT acpid in Lenny is RC-bug free. But maybe the list was created before 
> the package migrated.

Hm?  It was you who upgraded the severity of #487815 to serious just six
days ago.  Which was correct, IMO.

Sven


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

Internet.Com Format Error

[Internet.com]

Sorry, your email containing an attachment can not be distributed through
Internet.Com discussion lists.

The only acceptable format for posting to isp-australia is ASCII
Text, with NO attachments.

Please, re-send your post to continue your discussion on
isp-australia.


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

Re: List of RC-buggy source packages by maintainer/uploader

[Nico Golde]

Hi Reinhard,
* Reinhard Tartler <[EMAIL PROTECTED]> [2008-10-07 13:09]:
> Lucas Nussbaum <[EMAIL PROTECTED]> writes:
> 
> > Reinhard Tartler <[EMAIL PROTECTED]>
> >xine-lib (#498243)
> 
> Needs help. That report is a security report from ocert. The full report
> can be seen here: http://www.ocert.org/analysis/2008-008/analysis.txt
> 
> all fixes from 1.1.15 are backported to debian's 1.1.14 package already,
> what is missing are issues 3A-3G.

Can you make the patch available somewhere? Last time I 
looked at the there were some fixes in the code that didn't 
actually fix the vulnerability.

Cheers
Nico
-- 
Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


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

Re: List of RC-buggy source packages by maintainer/uploader

[Alexander Reichle-Schmehl]

Hi!

Luk Claes schrieb:
>>> Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]>
>>>gem
>> This was fixed by an NMU, but can't transition to testing due to dependency 
>> on
>> libquicktime 2:1.0.3+debian-2. What to do in cases like this?
> 
> Contact the release team to see if it's possible to unblock the
> dependency or if an upload to tpu is preferred.
> 
> In this case, please upload to testing-proposed-updates.

A fixed packages has already been uploaded to tpu (as dato had asked for).


Best regards,
  Alexander



signature.asc
Description: OpenPGP digital signature

Re: List of RC-buggy source packages by maintainer/uploader

[Daniel Leidert]

Am Montag, den 06.10.2008, 21:28 +0200 schrieb Lucas Nussbaum:
> On 06/10/08 at 18:44 +0200, Alexander Reichle-Schmehl wrote:

[..]
> Debian XML/SGML Group <[EMAIL PROTECTED]>
>sgml-base

http://bugs.debian.org/477751 - Some time ago I already asked to tag
this bug `lenny-ignore' but did not get any answer. The bug is about how
the whole system works. I'm planning to change/improve the design and
behaviour of the catalog system in Debian after Lenny. But it was too
late for Lenny.

So: May I tag it lenny-ignore?

Regards, Daniel


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

Re: [Pkg-xen-devel] Xen status in lenny?

[Paul van der Vlis]

Thomas Viehmann schreef:
> Hi,
> 
> Pasi Kärkkäinen wrote:
>>> Next try: http://194.39.182.225/debian/xen/try4.
>> Hmm.. these packages are not available anymore? 
>> URL changed? 
> Your local Debian sid mirror, e.g. package
> xen-linux-system-2.6.26-1-xen-amd64.

Strange, I don't see the packages in packages.debian.org, but I see them
in bugs.debian.org. I also don't saw them yesterday in the new queue. If
somebody wants them, I can put the amd64 packages somewhere on a server.

I am running the packages as dom0 since they where released (the amd64
version), I don't saw stability problems. I would like to help test them
better, but I need some help: my xenbr device does not start.

With regards,
Paul van der Vlis.




-- 
http://www.vandervlis.nl/


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Reinhard Tartler]

Didier Raboud <[EMAIL PROTECTED]> writes:

>>  - source packages in 'main' may build-depend on packages in 'patented'
>
> This is problematic for a self-buildable main everywhere, no ?

This means that buildds would need to add both 'main' and 'patented' to
their sources.list, right.

Do you see a particular problem with requiring that?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: Bug#501190: ITP: moonlight -- open source implementation of Microsoft Silverlight

[Holger Levsen]

Hi,

On Tuesday 07 October 2008 09:03, Robert Millan wrote:
> Unclaimed patents are precisely the reason we don't have any MPEG encoders
> in Debian (see http://techliberation.com/2006/05/11/mpeg-patent-thicket/).

Wrong. We dont have mpeg encoders in Debian because those patents are being 
enforced.


regards,
Holger


pgpWvIE4bWtWn.pgp
Description: PGP signature

Re: List of RC-buggy source packages by maintainer/uploader

[Samuel Thibault]

> win32-loader 

Waiting for loadlin, waiting for yasm, for which a patch just got
commited upstream.

Samuel


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

Re: List of RC-buggy source packages by maintainer/uploader

[Emilio Pozuelo Monfort]

> Debian GNOME Maintainers <[EMAIL PROTECTED]>
>libgda3 (U)

libgda3 has been fixed in unstable with high urgency. Needs unblocking.

> Debian Python Modules Team <[EMAIL PROTECTED]>
>matplotlib

Seems to be fixed in t-p-u, but hasn't migrated to testing yet. [1] says
"Unblock request by luk ignored due to version mismatch". Is that normal?

[1] http://packages.qa.debian.org/m/matplotlib.html

> Python Applications Packaging Team <[EMAIL PROTECTED]>
>mercurial

Fixed in unstable by the Security Team, unblocked, not built in s390.

Cheers,
Emilio


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

Re: List of RC-buggy source packages by maintainer/uploader

[Michael Meskes]

On Tue, Oct 07, 2008 at 12:11:49PM +0200, Sven Joachim wrote:
> >>acpid (U)
> >
> > AFAICT acpid in Lenny is RC-bug free. But maybe the list was created before 
> > the package migrated.
> 
> Hm?  It was you who upgraded the severity of #487815 to serious just six
> days ago.  Which was correct, IMO.

Argh, silly me. I just looked at my list of open bugs, but this one is listed
as pending and thus I missed it. Sorry.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Holger Levsen]

Hi,

On Tuesday 07 October 2008 16:44, Reinhard Tartler wrote:
>  - packages in 'patented' must fulfill the requirements of the dfsg

I dont think we should support the obsolete, useless & wrong patent system by 
doing this.

Also, something must patented in which / how many of the 160 juristrictions on 
this planet (to apply for this category)? 

Is (hearsay of) a patent claim enough or does it have to be court proven?

Remeber the progress bar patent?

This is a road to nowhere.


regards,
Holger



pgpi5AjdH177N.pgp
Description: PGP signature

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Paul Wise]

On Tue, Oct 7, 2008 at 10:07 PM, Robert Millan <[EMAIL PROTECTED]> wrote:

> While we are at it, would be nice to have a section for DMCA-impaired software
> such as libdvdcss.

Presumably they couldn't be distributed from ftp-master (which is in the USA)?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Michael Banck]

On Tue, Oct 07, 2008 at 05:54:22PM +0200, Holger Levsen wrote:
> Hi,
> 
> On Tuesday 07 October 2008 16:44, Reinhard Tartler wrote:
> >  - packages in 'patented' must fulfill the requirements of the dfsg
> 
> Also, something must patented in which / how many of the 160 juristrictions 
> on 
> this planet (to apply for this category)? 

"How do you tell if a piece of software violates a patent? Run wc -l on
the source; if the number is greater than 1000, it probably does."
-- Nat Friedman


Michael


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

Re: List of RC-buggy source packages by maintainer/uploader

[Luk Claes]

Emilio Pozuelo Monfort wrote:
>> Debian GNOME Maintainers <[EMAIL PROTECTED]>
>>libgda3 (U)
> 
> libgda3 has been fixed in unstable with high urgency. Needs unblocking.

unblocked

>> Debian Python Modules Team <[EMAIL PROTECTED]>
>>matplotlib
> 
> Seems to be fixed in t-p-u, but hasn't migrated to testing yet. [1] says
> "Unblock request by luk ignored due to version mismatch". Is that normal?
> 
> [1] http://packages.qa.debian.org/m/matplotlib.html

Yes, quite normal when the t-p-u version has migrated: my hint doesn't
match the version in unstable.

Cheers

Luk


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Didier Raboud]

Reinhard Tartler wrote:

> Didier Raboud <[EMAIL PROTECTED]> writes:
> 
>>>  - source packages in 'main' may build-depend on packages in 'patented'
>>
>> This is problematic for a self-buildable main everywhere, no ?
> 
> This means that buildds would need to add both 'main' and 'patented' to
> their sources.list, right.
> 
> Do you see a particular problem with requiring that?

Yes...

If I am in a country where the usage of the "patented" repo is forbidden for
whatever reason, I could (legally) not rebuild the whole "main" myself.

And if I understand the DFSG correctly, for each package in "main", I should
be able to get access to the full source code needed for its build. This
could not be realised if I can't access to "patented" for legal reasons.

Regards,

OdyX

-- 
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Reinhard Tartler]

Didier Raboud <[EMAIL PROTECTED]> writes:
>> Do you see a particular problem with requiring that?
> Yes...
>
> If I am in a country where the usage of the "patented" repo is forbidden for
> whatever reason, I could (legally) not rebuild the whole "main" myself.

"Usage" is generally not the problem with that software. For the case
we're discussing here "selling" and in a broader, more concrete form
"distributing" is.

> And if I understand the DFSG correctly, for each package in "main", I should
> be able to get access to the full source code needed for its build. This
> could not be realised if I can't access to "patented" for legal
> reasons.

Wrong. The DFSG is about the lincense of the software, it does not say
anything about patents. Moreover, the DFSG does not even talk about
archive sections.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Reinhard Tartler]

Holger Levsen <[EMAIL PROTECTED]> writes:

> On Tuesday 07 October 2008 16:44, Reinhard Tartler wrote:
>>  - packages in 'patented' must fulfill the requirements of the dfsg
>
> I dont think we should support the obsolete, useless & wrong patent
> system by doing this.

I fully agree with you in principle. The 'restricted' idea is basically
a convenience service for our users and distributors. OTOH our the
current approach is to put our heads in the sand and pretend that we are
too gutless to even distribute them in non-free.

I therefore see the 'restricted' idea as a compromise which addresses at
least some of the concerns that ftp-master *might* raise.

However as they don't reply to my questions, I can only guess what the
concerns might be.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Gunnar Wolf]

Michael Banck dijo [Tue, Oct 07, 2008 at 06:14:23PM +0200]:
> > Also, something must patented in which / how many of the 160 juristrictions 
> > on 
> > this planet (to apply for this category)? 
> 
> "How do you tell if a piece of software violates a patent? Run wc -l on
> the source; if the number is greater than 1000, it probably does."
> -- Nat Friedman

For positive proof, I'd buy it - but we must remember logical
fallacies can be derived from there. If wc > 1000, it surely violates
a patent. If wc <= 1000, it might violate a patent anyway.

#!/usr/bin/perl
# 472-byte qrpff, Keith Winstein and Marc Horowitz
#<[EMAIL PROTECTED]>
# MPEG 2 PS VOB file -> descrambled output on stdout.
# usage: perl -I  qrpff
# where k1..k5 are the title key bytes in least to most-significant
#order

s''$/=\2048;while(<>){G=29;R=142;if((@a=unqT="C*",_)[20]&48){D=89;_=unqb24,qT,@
b=map{ord
qB8,unqb8,qT,[EMAIL PROTECTED];s/...$/1$&/;Q=unqV,qb25,_;H=73;O=$b[4]<<9
|256|$b[3];Q=Q>>8^(P=(E=255)&(Q>>12^Q>>4^Q/8^Q))<<17,O=O>>8^(E&(F=(S=O>>14&7^O)
^S*8^S<<6))<<9,_=(map{U=_%16orE^=R^=110&(S=(unqT,"\xb\ntd\xbz\x14d")[_/16%8]);E
^=(72,@z=(64,72,G^=12*(U-2?0:S&17)),H^=_%64?12:0,@z)[_%8]}(16..271))[_]^((D>>=8
)+=P+(~F&E))[EMAIL PROTECTED],@a}';s/[D-HO-U_]/\$$&/g;s/q/pack+/g;eval


-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Britney error with the gossip package?

[Neil Williams]

On Tue, 07 Oct 2008 20:25:12 +0200
Norbert Tretkowski <[EMAIL PROTECTED]> wrote:

>From #501423: FTBFS in lenny: Unsatisfiable build-dependency:
libloudmouth1-dev(inst 1.4.0-1 ! >= wanted 1.4.1)

> Am Dienstag, den 07.10.2008, 18:57 +0100 schrieb Neil Williams:
> > Migration to testing happens automatically from unstable, you should
> > have received notification of the migration, there is no approval
> > needed.
> 
> Not during a freeze, where an exception is required.

Oops. Got my dates wrong. Sorry.

Freeze: Sun, 27 Jul 2008 16:00:53 +0200
http://lists.debian.org/debian-devel-announce/2008/07/msg7.html
 
The gossip upload was made:
Date: Sun, 03 Aug 2008 16:52:40 +0200

It migrated Fri, 03 Oct 2008 16:39:16 +

There's no sign of a request on the debian-release mailing list (Sep or
Oct 08).

I'm assuming there are records of unblocks beyond the mailing list
archive?

> I uploaded gossip and loudmouth to unstable, and wanted to ask for an
> approval, but then an RC bug was filed against loudmouth, that's why I
> didn't ask for approval yet.
> 
> > Are you saying that gossip should be removed from testing and therefore
> > removed from the release?
> 
> No. But we now really need a fix for the loudmouth RC bug.

As that bug doesn't affect testing, it is not exactly a priority for
bug fixes prior to the release.

Is it worth investigating why britney got it wrong and whether
gossip 1:0.30-1 can be reinstated?

$ rmadison libloudmouth1-0

libloudmouth1-0 |1.4.0-1 |   testing | alpha, amd64, arm,
armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
libloudmouth1-0 |1.4.2-1 |  unstable | alpha, amd64, arm,
armel, hppa, hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390,
sparc

How did gossip migrate with Build-Depends on a version of
libloudmouth1-0 that still does not exist in Lenny?

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpYd08iXPBOy.pgp
Description: PGP signature

Re: Britney error with the gossip package?

[Adam D. Barratt]

On Tue, 2008-10-07 at 20:21 +0100, Neil Williams wrote:
> $ rmadison libloudmouth1-0
> 
> libloudmouth1-0 |1.4.0-1 |   testing | alpha, amd64, arm,
> armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
> libloudmouth1-0 |1.4.2-1 |  unstable | alpha, amd64, arm,
> armel, hppa, hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390,
> sparc
> 
> How did gossip migrate with Build-Depends on a version of
> libloudmouth1-0 that still does not exist in Lenny?

britney only considers installability, not buildability.

That is to say, if package A depends on "B (>= 2)" then an appropriate
version of B must (in the absence of hints to the contrary) exist in
testing, but if A /build/-depends on "B (>= 2)" then britney does not
care whether B exists in testing at all, yet alone with the correct
version.

Regards,

Adam


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Loïc Minier]

On Tue, Oct 07, 2008, Reinhard Tartler wrote:
>  - introduce a new section 'patented'
>  - packages in 'patented' must fulfill the requirements of the dfsg
>  - source packages in 'main' may produce binaries in 'patented'
>  - binary packages in 'main' must not depend on packages in 'patented'
>  - source packages in 'main' may build-depend on packages in 'patented'
>  - source and binary packages in 'patented' may depend on package on
>both 'main' and 'patented'
>  - source packages in 'patented' must not produce binaries in 'main'
>  - packages in 'contrib' and 'non-free' may additionally depend on packages
>in 'patented'

 What about packages which need non-free software packages to work
 (contrib) and infringe actively enforced patents?  This would mean a
 contrib-patented component.  What about patents which are enforced only
 in some countries?  What about patents only applicable in some
 countries (e.g. a patent in France)?

 Perhaps instead of trying to come with a hierarchical classification,
 we should simply expose what we know about patents and any other
 distribution issue in a machine readable way.

 What a bout a debian/distribution or debian/copyright2 file which would
 expose patents information?  e.g.:
Country: fr
Patent numbers: 1234, 5678
Distribution-allowed: no
Usage-allowed: yes
Risk of prosecution[company, gvt, non-profit]: yes
Risk of prosecution[user]: no
 etc.

-- 
Loïc Minier


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

Re: Britney error with the gossip package?

[Neil Williams]

On Tue, 07 Oct 2008 20:42:07 +0100
"Adam D. Barratt" <[EMAIL PROTECTED]> wrote:

> On Tue, 2008-10-07 at 20:21 +0100, Neil Williams wrote:
> > $ rmadison libloudmouth1-0
> > 
> > libloudmouth1-0 |1.4.0-1 |   testing | alpha, amd64, arm,
> > armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
> > libloudmouth1-0 |1.4.2-1 |  unstable | alpha, amd64, arm,
> > armel, hppa, hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390,
> > sparc
> > 
> > How did gossip migrate with Build-Depends on a version of
> > libloudmouth1-0 that still does not exist in Lenny?
> 
> britney only considers installability, not buildability.

Maybe it should - after all, in the phase prior to a release, the
ability to build the entire release from source *is* important. To me,
this is precisely what Britney should be able to avoid - gossip
migrated (irrespective of what happened with the unblock, this could
easily happen between releases too) in a condition that would not
build from source in testing.

This would not have been a problem if gossip had been held back from
testing migration (with or without a freeze or unblock).

> That is to say, if package A depends on "B (>= 2)" then an appropriate
> version of B must (in the absence of hints to the contrary) exist in
> testing, but if A /build/-depends on "B (>= 2)" then britney does not
> care whether B exists in testing at all, yet alone with the correct
> version.

gossip does build against the version in testing *if* configure and
configure.ac is patched to downgrade the LOUDMOUTH_REQUIRED variable.

Presumably the build-dependency was increased for a bug fix
but the symbols appear unchanged and gossip is not using any new
symbols that may appear in the version of libloudmouth in unstable. The
binary gossip package does not specify that version of libloudmouth so
that is probably a bug in the gossip Debian packaging - an explicit
dependency should have been specified to ensure that the release of
libloudmouth containing the bug fix needed by gossip upstream was
actually available to gossip at runtime. That would have prevented
Britney migrating the package.

So this is a combination of bugs:

The gossip binary should have had an explicit dependency on
libloudmouth1-0 (>= 1.4.1) in debian/control.in that overrides the
value derived from dpkg_shlibdeps so that gossip users actually got the
benefit of the incremented Build-Depends.

Britney could be improved to act as a safety-net for packages that fail
to set such dependencies in order to prevent bigger problems, like this
one.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpC2jNWCWBLd.pgp
Description: PGP signature

Re: Britney error with the gossip package?

[Neil Williams]

On Tue, 7 Oct 2008 21:02:11 +0100
Neil Williams <[EMAIL PROTECTED]> wrote:

> > britney only considers installability, not buildability.
> 
> Maybe it should - after all, in the phase prior to a release, the
> ability to build the entire release from source *is* important. To me,
> this is precisely what Britney should be able to avoid - gossip
> migrated (irrespective of what happened with the unblock, this could
> easily happen between releases too) in a condition that would not
> build from source in testing.

Actually, maybe lintian can come to the rescue here - if the
Build-Depends version is higher than the shared library dependency
isn't that always going to be a problem?

The reverse is fine, of course, but Build-Depends >> shlibs would
appear to be a problem waiting to happen.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgp0GeWDjFN6V.pgp
Description: PGP signature

Re: Britney error with the gossip package?

[Marc 'HE' Brockschmidt]

Neil Williams <[EMAIL PROTECTED]> writes:
> I'm assuming there are records of unblocks beyond the mailing list
> archive?

The release team's hint files are available:
http://ftp-master.debian.org/testing/hints/

In this case:
testing/hints/luk:unblock gossip/1:0.31-1

We move hints that were done down (under the "finished" line) for
archiving purposes.

> How did gossip migrate with Build-Depends on a version of
> libloudmouth1-0 that still does not exist in Lenny?

britney does not, and never has, check build-dependencies.

Marc
-- 
BOFH #250:
Program load too heavy for processor to lift.


pgpyBEQNxDV2A.pgp
Description: PGP signature

Re: Britney error with the gossip package?

[Felipe Sateler]

Neil Williams wrote:

> On Tue, 7 Oct 2008 21:02:11 +0100
> Neil Williams <[EMAIL PROTECTED]> wrote:
> 
>> > britney only considers installability, not buildability.
>> 
>> Maybe it should - after all, in the phase prior to a release, the
>> ability to build the entire release from source *is* important. To me,
>> this is precisely what Britney should be able to avoid - gossip
>> migrated (irrespective of what happened with the unblock, this could
>> easily happen between releases too) in a condition that would not
>> build from source in testing.
> 
> Actually, maybe lintian can come to the rescue here - if the
> Build-Depends version is higher than the shared library dependency
> isn't that always going to be a problem?
> 
> The reverse is fine, of course, but Build-Depends >> shlibs would
> appear to be a problem waiting to happen.

Wasn't dpkg supposed to use max(shlibs, build-depends)? The rationale, IIRC, is
because a particular program might rely on a specific bugfix in a given version
of the library. Since bugfixes don't cause shlibs bumps, this was a way for the
maintainer to enforce the correct functioning of the program.

-- 

  Felipe Sateler


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

Re: Bug#501137: ITP: acerfand -- Control the fan of the Acer Aspire One

[Gunnar Wolf]

Matthew Garrett dijo [Sun, Oct 05, 2008 at 02:35:11AM +0100]:
> Gunnar Wolf <[EMAIL PROTECTED]> wrote:
> 
> >  Keeps the fan from spinning constantly in the noisy Acer Aspire
> >  One. Provides also tools to query several machine-specific EC
> >  registers
> 
> Be careful with this - it can't perform the locking used by the kernel 
> and firmware for EC access, so there's a risk of racing and trashing the 
> contents of other registers. This should really be implemented as a 
> kernel driver using either the hwmon or thermal interfaces and a generic 
> fan control daemon implemented on top of that.

Thanks for the information - Given this, I retract my intention to
package. And given that the package is already packaged and uploaded:
FTP-masters, please ignore/delete it.

Matthew, and out of personal curiosity (as I will probably continue to
use this, at least until something better comes along): What does the
danger amount to? Say, a random lock-up? Or will it lead to hardware
malfunction (or shorter lifespan)? I am currently setting the
fan-on threshold at 70C, the fan-off at 60C (the default settings for
acerfand) 

Thanks!

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


pgpV7A3c8ziby.pgp
Description: PGP signature

Re: Britney error with the gossip package?

[Josselin Mouette]

Le mardi 07 octobre 2008 à 17:13 -0400, Felipe Sateler a écrit :
> Wasn't dpkg supposed to use max(shlibs, build-depends)? The rationale, IIRC, 
> is
> because a particular program might rely on a specific bugfix in a given 
> version
> of the library. Since bugfixes don't cause shlibs bumps, this was a way for 
> the
> maintainer to enforce the correct functioning of the program.

It only does so for packages with symbol files. The shlibs system
doesn’t provide a mapping between shared library packages and
development packages, which .symbols files do.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Manoj Srivastava]

On Tue, Oct 07 2008, Reinhard Tartler wrote:

> Didier Raboud <[EMAIL PROTECTED]> writes:
>
>>>  - source packages in 'main' may build-depend on packages in 'patented'
>>
>> This is problematic for a self-buildable main everywhere, no ?
>
> This means that buildds would need to add both 'main' and 'patented' to
> their sources.list, right.
>
> Do you see a particular problem with requiring that?

Yes. I think main should remain self contained.  This is the
 same reason we have a contrib section -- packages in contrib can not be
 built with the software contained in main.

,[ Debian Technical Policy ]
| 2.2.1. The main category
| 
| 
|  Every package in _main_ must comply with the DFSG (Debian Free
|  Software Guidelines).
| 
|  In addition, the packages in _main_
| * must not require a package outside of _main_ for compilation or
|   execution (thus, the package must not declare a "Depends",
|   "Recommends", or "Build-Depends" relationship on a non-_main_
|   package),
`

I do not see why we should change this invariant to pander to
 software patents.

manoj
-- 
A motivational sign at work: "The beatings will continue until morale
improves."
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Ben Finney]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> Yes. I think main should remain self contained. This is the
>  same reason we have a contrib section -- packages in contrib can
>  not be built with the software contained in main.

s/can not be built/can not be built and installed/

It's necessary, but not sufficient, for the package to build from
‘main’: one of the example use cases for ‘contrib’ is “wrapper
packages or other sorts of free accessories for non-free programs”,
and ‘contrib’ is a haven for packages that, on *installation*,
download and install non-free software. Even if such a package can
itself be built from ‘main’, it's still not a candidate for inclusion
in ‘main’.

> I do not see why we should change this invariant to pander
>  to software patents.

Agreed, with the caveat of “software patents that are known to be
actively enforced”, to forestall the obvious argument about *every*
non-trivial program likely violating *some* patent.

-- 
 \  “Two rules to success in life: 1. Don't tell people everything |
  `\you know.” —Sassan Tat |
_o__)  |
Ben Finney


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Russ Allbery]

Loïc Minier <[EMAIL PROTECTED]> writes:

>  Perhaps instead of trying to come with a hierarchical classification,
>  we should simply expose what we know about patents and any other
>  distribution issue in a machine readable way.
>
>  What a bout a debian/distribution or debian/copyright2 file which would
>  expose patents information?  e.g.:
> Country: fr
> Patent numbers: 1234, 5678
> Distribution-allowed: no
> Usage-allowed: yes
> Risk of prosecution[company, gvt, non-profit]: yes
> Risk of prosecution[user]: no
>  etc.

I would be very uncomfortable trying to fill out something that specific.
It looks remarkably like legal advice that I'm not qualified to give or
judge.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#501137: ITP: acerfand -- Control the fan of the Acer Aspire One

[Matthew Garrett]

On Tue, Oct 07, 2008 at 05:30:12PM -0500, Gunnar Wolf wrote:

> Matthew, and out of personal curiosity (as I will probably continue to
> use this, at least until something better comes along): What does the
> danger amount to? Say, a random lock-up? Or will it lead to hardware
> malfunction (or shorter lifespan)? I am currently setting the
> fan-on threshold at 70C, the fan-off at 60C (the default settings for
> acerfand) 

It really depends on how the hardware is designed, but an example would 
be where the kernel ends up reading the incorrect register when checking 
the temperature and misinterprets it as requiring a critical thermal 
shutdown. Lockups are certainly possible, and it's just about 
conceivable that you could cause hardware damage - though that's a bit 
of a stretch.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Paul Wise]

On Wed, Oct 8, 2008 at 1:39 AM, Reinhard Tartler <[EMAIL PROTECTED]> wrote:

> I fully agree with you in principle. The 'restricted' idea is basically
> a convenience service for our users and distributors.

Such convenience services already exist (debian-multimedia.org,
debian-unofficial.org), Debian doesn't need to start one.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Reinhard Tartler]

"Paul Wise" <[EMAIL PROTECTED]> writes:

>> I fully agree with you in principle. The 'restricted' idea is basically
>> a convenience service for our users and distributors.
>
> Such convenience services already exist (debian-multimedia.org,
> debian-unofficial.org), Debian doesn't need to start one.

My proposal in Message-ID:
<[EMAIL PROTECTED]> is not feasibly
implemtable with services like debian-multimedia.org nor
debian-unofficial.org.

Moroever, collaboration with debian-multimedia.org is virtually
non-existant, and debian-unofficial.org is currently dead for all
practical reasons. Possibly we can revive the latter though; you can
follow the progress on the pkg-multimedia-maintainers mailing list.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight

[Reinhard Tartler]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

>> Do you see a particular problem with requiring that?
>
> Yes. I think main should remain self contained.  This is the
>  same reason we have a contrib section -- packages in contrib can not be
>  built with the software contained in main.

Depending on the requirements of ftp-master, which *seem* to think that
non-free were inappropriate for this kind of packages, my proposal tries
to address that by introducing a new archive section.

I am aware that this is against our current technical policy. If my
proposal indeed adresses the concerns correct and we can implement it
technically, we'd need to adjust the policy as well.


>I do not see why we should change this invariant to pander to
> software patents.

I also think we should just ship an unmodified ffmpeg in 'main' and be
done with it. So does upstream. Obviously ftp-master disagrees, see
debian/README.Debian in the current ffmpeg source package.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: Bug#500176: This bug is still around and release-critical

[Hideki Yamane]

Hi,

On Mon, 06 Oct 2008 15:46:11 +0200
Pierre Habouzit <[EMAIL PROTECTED]> wrote:
> > Agreed, that would be nice. While this is something to consider for
> > squeeze release goals, how do we solve the problem for lenny?
> 
> I see no proper fix, except using an /etc/default file, which is ugly.

 Using /etc/default/unbound is reasonable, I think. Some of daemon packages 
 (e.g. rsync) are not started by default because it is set in its /etc/default
 file.

 # Some Unbound users ask me "Will lenny include unbound package?" at
   Conference, Japan. So, if you allow me to fix this by using /etc/default, 
   I'll try it (but I think it is better that you'll do it because I'm not
   a good programmer ;-).

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp
 http://wiki.debian.org/HidekiYamane


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