Re: Fwd: Re: Why no Opera?

[Roberto C . Sánchez]

On Sun, Sep 30, 2007 at 01:55:05PM -0500, [EMAIL PROTECTED] wrote:
> Roberto C. Sánchez wrote:
> > For that, you will have to ask the ftp masters and the security team.  I
> > am not in a position to speak to their official stance in terms of what
> > requirements they might have for software like opera to be in Debian and
> > the Debian Policy manual does not enumerate them either.
> 
> The security team gives no support for contrib and non-free packages[1].
> 
I know.  However, supporting and permitting are two different things.
Like it or not, there is an association of Debian being "involved" to
some degree or another in the software in contrib and non-free.  Not
everyone understands that non-free is not really part of Debian.  That
said, even if everyone understood that perfectly, I don't think that the
security team and/or the FTP masters would be thrilled about permitting
software in non-free that is very buggy.  That was the point I was
trying to make.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Fwd: Re: Why no Opera?

[atomo64+debian]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Roberto C. Sánchez wrote:
> For that, you will have to ask the ftp masters and the security team.  I
> am not in a position to speak to their official stance in terms of what
> requirements they might have for software like opera to be in Debian and
> the Debian Policy manual does not enumerate them either.

The security team gives no support for contrib and non-free packages[1].

> 
> Regards,
> 
> -Roberto
> 

[1] http://www.debian.org/security/faq#contrib

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

iD8DBQFG//EUYy49rUbZzloRAo26AJoDnUVE4RM1TrxytaaqfVTULuk5/wCeLgzr
bcNcW7F/4f4Fqkj0QG5Rg+8=
=hobb
-END PGP SIGNATURE-


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

Re: Fwd: Re: Why no Opera?

[Magnus Holmgren]

On Sunday 09 September 2007 19:19, David Given wrote:
> Ben Finney wrote:
> [...]
>
> > It would behoove you to at least put significant effort into
> > what everyone here agrees would be the best way to get Opera working
> > well with Debian and other free software operating systems.
>
> I'd take issue with that statement. Opera don't owe Debian anything;
> they're packaging their software as Debian packages for their users, not
> for us. If anything, they're doing us a favour by using our package format.
> That's their right. It's their software, they own it, they can do whatever
> they like with it. *We* get no say in that matter.

On the other hand, Opera isn't asked to make their browser free software _for 
Debian_, but for their users. Debian is not an end, but a means.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)

  "Exim is better at being younger, whereas sendmail is better for 
   Scrabble (50 point bonus for clearing your rack)" -- Dave Evans


pgpdQoN9Vx9te.pgp
Description: PGP signature

Re: Fwd: Re: Why no Opera?

[David Given]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ben Finney wrote:
[...]
> It would behoove you to at least put significant effort into
> what everyone here agrees would be the best way to get Opera working
> well with Debian and other free software operating systems.

Mmf.

I'd take issue with that statement. Opera don't owe Debian anything; they're
packaging their software as Debian packages for their users, not for us. If
anything, they're doing us a favour by using our package format. That's their
right. It's their software, they own it, they can do whatever they like with
it. *We* get no say in that matter.

So they're not behoven to do *anything* other than what they want to do. We
can offer suggestions, but that's all they are.

I'd suggest that because it strongly benefits us if Opera continues to listen
to our suggestions, it would not be a good idea not to attempt to throw our
weight around --- we don't have any...

- --
┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ───
│
│ "There does not now, nor will there ever, exist a programming language in
│ which it is the least bit hard to write bad programs." --- Flon's Axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG5Csgf9E0noFvlzgRApTHAJ9x5wL/ZwEwzO89zHBS8at5UrtAjACePLp2
hQWJbrYCcRo7DOk6zrx0pVA=
=BI5s
-END PGP SIGNATURE-

Re: Fwd: Re: Why no Opera?

[Ben Finney]

Edward Welbourne <[EMAIL PROTECTED]> writes:

> Bernd:
> > if opera would be come open-source, I'd be willing to co-maintain
> > and check packages - it would be worth the work. But I'm not
> > willing to spend my free time on closed source if there's no
> > really good reason to do so.
> 
> I'm afraid this humble coder isn't about to sway that argument; for
> the present, Opera remains closed, all I can do is make life easier
> for users.

You are much closer to being able to sway that argument than we: you,
after all, are directly associated with the people who can make that
decision. It would behoove you to at least put significant effort into
what everyone here agrees would be the best way to get Opera working
well with Debian and other free software operating systems.

It would also be very helpful if you could keep us appraised of any
response that you have in this area; otherwise a negative result looks
to us exactly the same as no attempt at all.

-- 
 \  "I would rather be exposed to the inconveniences attending too |
  `\ much liberty than those attending too small a degree of it."  |
_o__)  -- Thomas Jefferson |
Ben Finney


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

Re: Fwd: Re: Why no Opera?

[Edward Welbourne]

> I am not seeking for a violation of some license.
I didn't think you were.

> It is "missed opportunities" for optimisation that I am after.
That's what I understood you to mean.

> You have the source, you seek for them :o)
I really don't think there's anything that fits the bill.

> Please consider to maintain and/or co-maintain some free packages
> for the distribution and become a DD.
I have asked my boss whether we can treat the time I'd need for this
as my training budget allocation; I'll see how that goes ;-)

And thank you for the offer to be sponsor - I'll have a look at the
work-needing page to see if I find something that appeals,

Eddy.


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

Re: Fwd: Re: Why no Opera?

[Steffen Moeller]

On Friday 07 September 2007 11:18:18 Edward Welbourne wrote:
> > Can we still hope that there are requests from the Opera developers that
> > a certain set of LGPL libraries are out there that should be distributed
> > with Debian (which they are currently not or in a "wrong" version or
> > missing patches) that would help to further reduce the footprint of the
> > non-inspectable closed-source bits of the Opera Debian package?
>
> Since we dynamic link everything - except for the Qt in our
> opera-static package - we simply use the dependency mechanisms in the
> Debian package system to ensure the presence of the libraries on which
> we depend, all of which are present in standard debian packages
> already.  So I don't think there's anything that fits your description
> above.  Again, if you believe otherwise, I'd be interested to know.

I am not seeking for a violation of some license. It is "missed opportunities" 
for optimisation that I am after. You have the source, you seek for them :o)

> > Or are there free tools you are developing with that should be part
> > of Debian?
>
> Again, all the tools we use in development are present in Debian
> already.  In fact, in practice, the Unix team would not think of using
> any tool *not* in Debian, simply because most of us use Debian boxes
> as our main work-stations ;^)

This sounds all very Debian-friendly to me. Please consider to maintain and/or 
co-maintain some free packages for the distribution and become a DD. It 
should not distract you much or at all from the work you are doing anyway. 
The DD application procedure may be perceived to take long when measured with 
the wall clock, the brain tick time should be negligible for you, so don't 
shy away, please.

Cheers,

Steffen




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

Re: Fwd: Re: Why no Opera?

[Edward Welbourne]

> Can we still hope that there are requests from the Opera developers that a 
> certain set of LGPL libraries are out there that should be distributed with 
> Debian (which they are currently not or in a "wrong" version or missing 
> patches) that would help to further reduce the footprint of the 
> non-inspectable closed-source bits of the Opera Debian package?

Since we dynamic link everything - except for the Qt in our
opera-static package - we simply use the dependency mechanisms in the
Debian package system to ensure the presence of the libraries on which
we depend, all of which are present in standard debian packages
already.  So I don't think there's anything that fits your description
above.  Again, if you believe otherwise, I'd be interested to know.

> Or are there free tools you are developing with that should be part  
> of Debian?

Again, all the tools we use in development are present in Debian
already.  In fact, in practice, the Unix team would not think of using
any tool *not* in Debian, simply because most of us use Debian boxes
as our main work-stations ;^)

Eddy.


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

Re: Fwd: Re: Why no Opera?

[Edward Welbourne]

> One thing which would help is if you made use of the Bugs: filed in
> debian/control.  That is you do something like this:

> Bugs: mailto:[EMAIL PROTECTED]

ah !  OK, thanks for that ... packaging script revised :-)

> This allows people to send bug reports to you directly using the
> reportbug tool,

I'd sort of assumed Maintainer was used for that !

Eddy.


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

Re: Fwd: Re: Why no Opera?

[Lionel Elie Mamane]

On Fri, Sep 07, 2007 at 10:54:06AM +0200, Edward Welbourne wrote:

>> This allows people to send bug reports to you directly using the
>> reportbug tool,

> I'd sort of assumed Maintainer was used for that !

It is, but not in a way that is useful to you, only useful for
packages in Debian proper (or in the contrib / non-free sections of
our mirror network). By default, bug reports are sent to the Debian
bug tracking system, who does indeed send a copy of the report to the
Maintainer. But only for packages it knows about, that is those in
Debian; it takes the Maintainer field of the most recently uploaded
version of the package from its own database, not from the package as
installed on the machine the bug report was made from.

Bug reports against packages not part of Debian are, I believe,
returned with a message like "I don't know anything about package
FOO, can't take a bug for it.". Or maybe they are filed in the
"general" category, I'm not sure.

-- 
Lionel


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

Re: Fwd: Re: Why no Opera?

[Steffen Moeller]

On Friday 07 September 2007 08:10:47 Lionel Elie Mamane wrote:
> On Fri, Sep 07, 2007 at 12:11:24AM +0200, Edward Welbourne wrote:
> > Lionel Mamane:
[...]
> This was written under the assumption that you statically-linked to
> LGPL libraries, not only Qt. As you now inform me this is not the
> case, my statement has no base anymore.

Can we still hope that there are requests from the Opera developers that a 
certain set of LGPL libraries are out there that should be distributed with 
Debian (which they are currently not or in a "wrong" version or missing 
patches) that would help to further reduce the footprint of the 
non-inspectable closed-source bits of the Opera Debian package? Or are there 
free tools you are developing with that should be part of Debian?

If so, then it would seem approrpiate to learn about these as "requests for 
packaging" (RFPs) to the Debian bug tracking system.  If Operaners felt like 
developing Debian packages for those missing pieces themselves, then an
"Interest to Pack" (ITP) report should be submitted. The "reportbug" tool in 
Debian knows this all, just say "reportbug wnpp". New missing Debian packages 
for Opera would also seem like a brilliant opportunity for paid (!) Opera 
developers to also develop into Debian developers (http://nm.debian.org).

Cheers,

Steffen


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

Re: Fwd: Re: Why no Opera?

[Lionel Elie Mamane]

On Fri, Sep 07, 2007 at 12:11:24AM +0200, Edward Welbourne wrote:
> Lionel Mamane:
>>> Roberto Sánchez:

 One possible solution would be for Opera to produce a "source"
 package of unlinked binary object files.  This would allow relinking
 against new versions of the libraries (at least in most cases)
 without the need for access to the source.

>>> This is already legally required anyway, assuming you link with LGPL
>>> code: section 6 of LGPL 2.1.

> LGPL 2.1 Section 6.b allows for us to

> b) Use a suitable shared library mechanism for linking with the
> Library. (...)

> and we use shared linkage for the most part.  Even the opera-static
> package only statically links Qt (...); everything else is
> shared-linked.

> So my understanding of the legal angle is that providing unlinked
> binaries isn't required - please explain why, if you disagree.

This was written under the assumption that you statically-linked to
LGPL libraries, not only Qt. As you now inform me this is not the
case, my statement has no base anymore.

-- 
Lionel


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

Re: Fwd: Re: Why no Opera?

[Roberto C . Sánchez]

On Fri, Sep 07, 2007 at 12:11:24AM +0200, Edward Welbourne wrote:
> 
> These are roughly the arguments I've used in the past to avoid
> pressure to "simplify" our packaging by changing to static linking
> (which would save us having to address issues of compatibility with
> diverse versions of GNU/Linux).  The cost is that we have to keep
> ourselves up-to-date with existing systems, which increases the number
> of distinct builds we have to make (and package and ship).  We have
> the opera-static version (which static-links Qt, but dynamic-links
> everything else) so that we can support those on very old versions of
> GNU/Linux; and I don't like the security (or footprint) angle on that,
> but it's the best we can think of to do for folk who don't upgrade
> their core systems.
> 
It seems like you have made a sensible choice in offering both.  After
all, in a free market one must offer what the customer wants or risk
losing the customer altogether.

> >> > However, in the event that there is an update which makes the
> >> > library non-binary compatible, then there is another problem.  That
> >> > is, apps linking against it must be recompiled.  With a non-free
> >> > product like opera, there would be [no] ability for some well-meaning
> >> > Debian Developer to NMU the package (since there is no source) or
> >> > for a binNMU to take place if that could fix the problem.
> 
> I'm not sure what a binNMU is.  As for the NMU problem, for the

A binNMU is simply a rebuild that is triggered by archive admins.  That
is, no source changes are required just a recompile.  This is often the
case with library transitions so that all the packages that depend on an
old library can be recompiled to depend on the new library.  In the past
this required an actual upload, but nowadays they can just trigger it
without an upload.  Any package you see with a +b1, +b2 or something
like that at the end of the Debian version has been binNMU'd.

> foreseeable future, I have to live with opera being non-free, which
> means we have to carry the burden of responding in a timely manner to
> such ABI-incompatible changes.  Naturally, [EMAIL PROTECTED] would be
> grateful for any notification of such problems, when they arise.
> 
One thing which would help is if you made use of the Bugs: filed in
debian/control.  That is you do something like this:

Bugs: mailto:[EMAIL PROTECTED]

This allows people to send bug reports to you directly using the
reportbug tool, which is the preferred tool for submitting bug reports
against Debian packages.  That field above will indicate to reportbug
that the report needs to go to that address instead of the Debian BTS
address.

> >> > One possible solution would be for Opera to produce a "source"
> >> > package of unlinked binary object files.  This would allow relinking
> >> > against new versions of the libraries (at least in most cases)
> >> > without the need for access to the source.
> 
> >> This is already legally required anyway, assuming you link with LGPL
> >> code: section 6 of LGPL 2.1.
> 
> LGPL 2.1 Section 6.b allows for us to
> 
> b) Use a suitable shared library mechanism for linking with the
> Library.  A suitable mechanism is one that (1) uses at run time a
> copy of the library already present on the user's computer system,
> rather than copying library functions into the executable, and (2)
> will operate properly with a modified version of the library, if
> the user installs one, as long as the modified version is
> interface-compatible with the version that the work was made with.
> 
> and we use shared linkage for the most part.  Even the opera-static
> package only statically links Qt (for which we have a separate license
> from TrollTech, independent of its availability under GPL or QPL);
> everything else is shared-linked.
> 
> So my understanding of the legal angle is that providing unlinked
> binaries isn't required - please explain why, if you disagree.
> 

I believe he was referring to this paragraph from the Preamble:

 For example, if you distribute copies of the library, whether
 gratis or for a fee, you must give the recipients all the rights
 that we gave you.  You must make sure that they, too, receive or
 can get the source code.  If you link other code with the library,
 you must provide complete object files to the recipients, so that
 they can relink them with the library after making changes to the
 library and recompiling it.  And you must show them these terms so
 they know their rights.

I think that the intent is that user should be able to make non-binary
compatible changes to the library and still relink the non-free work
against the new library.

> >> ... Putting it in a Debian "source package"
> >> would only put it in a most convenient form for your users.
> 
> Using shared linkage gets the end-user as much ability to replace
> libraries (including the X libraries, under BSDoid licenses) as
> 

Re: Fwd: Re: Why no Opera?

[Edward Welbourne]

Lionel:
>> (Explicitly CCing Edward in the assumption he's not subscribed to this
>> list.
Thank you - I am, indeed, not subscribed.
It would actually be best if you could address me as
[EMAIL PROTECTED], so that various of my colleagues see the
discussion, too.

>> ... The message I'm answering to is at
>> http://lists.debian.org/debian-devel/2007/09/msg00145.html . I'd like
>> to be CCed an followups, although subscribed.)

Thanks for the link - and I largely agree with much that's said in
that - see below.

Roberto:
>> > Static linking is considered bad because it is a security
>> > nightmare. You now have extra copies of library code floating
>> > around. Dynamic linking is what the security team likes since it
>> > means that you only update the code once for the whole system.
...
>> > Additionally, static linking destroys any memory utilization benefit of
>> > library code. (...)

Agreed.

These are roughly the arguments I've used in the past to avoid
pressure to "simplify" our packaging by changing to static linking
(which would save us having to address issues of compatibility with
diverse versions of GNU/Linux).  The cost is that we have to keep
ourselves up-to-date with existing systems, which increases the number
of distinct builds we have to make (and package and ship).  We have
the opera-static version (which static-links Qt, but dynamic-links
everything else) so that we can support those on very old versions of
GNU/Linux; and I don't like the security (or footprint) angle on that,
but it's the best we can think of to do for folk who don't upgrade
their core systems.

>> > However, in the event that there is an update which makes the
>> > library non-binary compatible, then there is another problem.  That
>> > is, apps linking against it must be recompiled.  With a non-free
>> > product like opera, there would be [no] ability for some well-meaning
>> > Debian Developer to NMU the package (since there is no source) or
>> > for a binNMU to take place if that could fix the problem.

I'm not sure what a binNMU is.  As for the NMU problem, for the
foreseeable future, I have to live with opera being non-free, which
means we have to carry the burden of responding in a timely manner to
such ABI-incompatible changes.  Naturally, [EMAIL PROTECTED] would be
grateful for any notification of such problems, when they arise.

>> > One possible solution would be for Opera to produce a "source"
>> > package of unlinked binary object files.  This would allow relinking
>> > against new versions of the libraries (at least in most cases)
>> > without the need for access to the source.

>> This is already legally required anyway, assuming you link with LGPL
>> code: section 6 of LGPL 2.1.

LGPL 2.1 Section 6.b allows for us to

b) Use a suitable shared library mechanism for linking with the
Library.  A suitable mechanism is one that (1) uses at run time a
copy of the library already present on the user's computer system,
rather than copying library functions into the executable, and (2)
will operate properly with a modified version of the library, if
the user installs one, as long as the modified version is
interface-compatible with the version that the work was made with.

and we use shared linkage for the most part.  Even the opera-static
package only statically links Qt (for which we have a separate license
from TrollTech, independent of its availability under GPL or QPL);
everything else is shared-linked.

So my understanding of the legal angle is that providing unlinked
binaries isn't required - please explain why, if you disagree.

>> ... Putting it in a Debian "source package"
>> would only put it in a most convenient form for your users.

Using shared linkage gets the end-user as much ability to replace
libraries (including the X libraries, under BSDoid licenses) as
supplying the linkable binaries - if the ABI changes, they'd need a
new linkable component from us in any case, and otherwise their
replacement shared library will still work.

If I've missed something crucial, please enlighten me !

Roberto again:
> Right.  My point was that distributing it in such a fashion might
> address some of the concerns (though not all, of course) about having
> something like Opera even in non-free.

It would help me if you could enumerate those concerns.

Eddy.


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

Re: Fwd: Re: Why no Opera?

[Roberto C . Sánchez]

On Thu, Sep 06, 2007 at 02:27:25PM +0200, Lionel Elie Mamane wrote:
> (Explicitly CCing Edward in the assumption he's not subscribed to this
> list. The message I'm answering to is at
> http://lists.debian.org/debian-devel/2007/09/msg00145.html . I'd like
> to be CCed an followups, although subscribed.)
> 
> On Wed, Sep 05, 2007 at 09:38:14AM -0400, Roberto C. Sánchez wrote:
> > On Wed, Sep 05, 2007 at 03:16:07PM +0200, Steffen Moeller wrote:
> >> On Wednesday 05 September 2007 13:23:46 Edward Welbourne wrote:
> 
> >>> I'm confused.  Pierre appears to be saying "static is bad", Bruce
> >>> "closed must be static".
> 
> >> There are multiple views on this.
> 
> > The problem runs a little deeper than that.
> 
> > Static linking is considered bad because it is a security
> > nightmare. You now have extra copies of library code floating
> > around. Dynamic linking is what the security team likes since it
> > means that you only update the code once for the whole system.
> > However, in the event that there is an update which makes the
> > library non-binary compatible, then there is another problem.  That
> > is, apps linking against it must be recompiled.  With a non-free
> > product like opera, there would be ability for some well-meaning
> 
> Roberto meant "would *not* be ability", I presume.
> 
Quite right.  My brain works faster than I can type.

> > Debian Developer to NMU the package (since there is no source) or
> > for a binNMU to take place if that could fix the problem.
> 
> (That is in the context of a security problem in a library,
> naturally.)
> 
> > Additionally, static linking destroys any memory utilization benefit of
> > library code. (...)
> 
> > One possible solution would be for Opera to produce a "source"
> > package of unlinked binary object files.  This would allow relinking
> > against new versions of the libraries (at least in most cases)
> > without the need for access to the source.
> 
> This is already legally required anyway, assuming you link with LGPL
> code: section 6 of LGPL 2.1. Putting it in a Debian "source package"
> would only put it in a most convenient form for your users.
> 
Right.  My point was that distributing it in such a fashion might
address some of the concerns (though not all, of course) about having
something like Opera even in non-free.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Fwd: Re: Why no Opera?

[Lionel Elie Mamane]

(Explicitly CCing Edward in the assumption he's not subscribed to this
list. The message I'm answering to is at
http://lists.debian.org/debian-devel/2007/09/msg00145.html . I'd like
to be CCed an followups, although subscribed.)

On Wed, Sep 05, 2007 at 09:38:14AM -0400, Roberto C. Sánchez wrote:
> On Wed, Sep 05, 2007 at 03:16:07PM +0200, Steffen Moeller wrote:
>> On Wednesday 05 September 2007 13:23:46 Edward Welbourne wrote:

>>> I'm confused.  Pierre appears to be saying "static is bad", Bruce
>>> "closed must be static".

>> There are multiple views on this.

> The problem runs a little deeper than that.

> Static linking is considered bad because it is a security
> nightmare. You now have extra copies of library code floating
> around. Dynamic linking is what the security team likes since it
> means that you only update the code once for the whole system.
> However, in the event that there is an update which makes the
> library non-binary compatible, then there is another problem.  That
> is, apps linking against it must be recompiled.  With a non-free
> product like opera, there would be ability for some well-meaning

Roberto meant "would *not* be ability", I presume.

> Debian Developer to NMU the package (since there is no source) or
> for a binNMU to take place if that could fix the problem.

(That is in the context of a security problem in a library,
naturally.)

> Additionally, static linking destroys any memory utilization benefit of
> library code. (...)

> One possible solution would be for Opera to produce a "source"
> package of unlinked binary object files.  This would allow relinking
> against new versions of the libraries (at least in most cases)
> without the need for access to the source.

This is already legally required anyway, assuming you link with LGPL
code: section 6 of LGPL 2.1. Putting it in a Debian "source package"
would only put it in a most convenient form for your users.

> However, I tend to be in agreement with others on this list that the
> best solution would be a Free software release of Opera.

AOL, obviously ;-)

-- 
Lionel


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

Re: Fwd: Re: Why no Opera?

[Hamish Moffatt]

On Thu, Sep 06, 2007 at 10:21:14AM +0200, Edward Welbourne wrote:
> > you can at least use linda and lintian (-iI) to check your packages,
> > that should help a lot.
> 
> Indeed - I've been using lintian, and linda's on my set of things to
> try during my next binge of package work.

How about amd64 packages?


thanks,
Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: Fwd: Re: Why no Opera?

[Edward Welbourne]

> you can at least use linda and lintian (-iI) to check your packages,
> that should help a lot.

Indeed - I've been using lintian, and linda's on my set of things to
try during my next binge of package work.

Eddy.


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

Re: Fwd: Re: Why no Opera?

[Bernd Zeimetz]

Hi,
> That's one of the (too many) things I've got on my todo list - get
> myself trained as a proper Debian developer.  For the moment, I just
> have some scripts (mostly inherited, I've only had time to clean them
> up so far) that do the packaging mostly right; the scripts know more
> about Debian packaging than I do, though.  Tollef Fog Heen directed me
> to http://www.debian.org/doc/manuals/maint-guide/ when he was my
> Ubuntu contact, so I guess I should familiarize myself with that
> before asking for a sponsor !
>   

you can at least use linda and lintian (-iI) to check your packages,
that should help a lot.

Cheers,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: Fwd: Re: Why no Opera?

[Roberto C . Sánchez]

On Wed, Sep 05, 2007 at 04:43:09PM +0200, Hendrik Sattler wrote:
> Zitat von "Roberto C. Sánchez" <[EMAIL PROTECTED]>:
> >Dynamic linking is what the security team likes since it means that you
> >only update the code once for the whole system.  However, in the event
> >that there is an update which makes the library non-binary compatible,
> >then there is another problem.  That is, apps linking against it must be
> >recompiled.
> 
> That's what ABIs are for. If a new version of a library breaks an  
> application that uses the not-changed API as intended, it is the  
> library that needs to use a new soname.
> The package dependencies will indicate the needed libraries. Library  
> packages in Debian should reflect the soname, thus the package name  
> changes when the soname changes. No problem, then.
> 
I understand that.  The point I was trying to get at is that in such
cases Debian tries to minimize the proliferation of many versions of
libraries in the archive.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Fwd: Re: Why no Opera?

[Edward Welbourne]

Steffen:
>> So, the Debian community would have someone (and sadly only one) who can 
>> inspect your source and fix issues that arise. The benefit I see for Opera 
>> is 
>> a further decreased footprint.
Bernd:
> if opera would be come open-source, I'd be willing to co-maintain and
> check packages - it would be worth the work. But I'm not willing to
> spend my free time on closed source if there's no really good reason to
> do so.

I'm afraid this humble coder isn't about to sway that argument; for
the present, Opera remains closed, all I can do is make life easier
for users.  I entirely appreciate that I can't expect help improving
our closed packages, but any help that *is* volunteered would make one
more package be a bit closer to conforming to Debian's standards.
We've had some very welcome help from the Ubuntu folks, who are
largely responsible for the improvements between 9.23 and 9.50, and
I'll be reviewing the remaining issues (two of my nine outstanding
packaging bugs are Debian-specific) when I have time.

Steffen:
> For a closed source release it would be lovely if you had a Debian  
> developer amongst your Opera developers who can upload packages to  
> the distribution.

That's one of the (too many) things I've got on my todo list - get
myself trained as a proper Debian developer.  For the moment, I just
have some scripts (mostly inherited, I've only had time to clean them
up so far) that do the packaging mostly right; the scripts know more
about Debian packaging than I do, though.  Tollef Fog Heen directed me
to http://www.debian.org/doc/manuals/maint-guide/ when he was my
Ubuntu contact, so I guess I should familiarize myself with that
before asking for a sponsor !

Eddy.


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

Re: Fwd: Re: Why no Opera?

[Hendrik Sattler]

Zitat von "Roberto C. Sánchez" <[EMAIL PROTECTED]>:

Dynamic linking is what the security team likes since it means that you
only update the code once for the whole system.  However, in the event
that there is an update which makes the library non-binary compatible,
then there is another problem.  That is, apps linking against it must be
recompiled.


That's what ABIs are for. If a new version of a library breaks an  
application that uses the not-changed API as intended, it is the  
library that needs to use a new soname.
The package dependencies will indicate the needed libraries. Library  
packages in Debian should reflect the soname, thus the package name  
changes when the soname changes. No problem, then.


HS

Re: Fwd: Re: Why no Opera?

[Bernd Zeimetz]

Hi,
> So, the Debian community would have someone (and sadly only one) who can 
> inspect your source and fix issues that arise. The benefit I see for Opera is 
> a further decreased footprint.
>
>   

if opera would be come open-source, I'd be willing to co-maintain and
check packages - it would be worth the work. But I'm not willing to
spend my free time on closed source if there's no really good reason to
do so.

Cheers,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: Fwd: Re: Why no Opera?

[Roberto C . Sánchez]

On Wed, Sep 05, 2007 at 03:16:07PM +0200, Steffen Moeller wrote:
> 
> On Wednesday 05 September 2007 13:23:46 Edward Welbourne wrote:
> 
> > I'm confused.  Pierre appears to be saying "static is bad", Bruce
> > "closed must be static".  We have both static and shared packages, so
> > you can take your pick, but which is the one the official Debian
> > repository wants ?
> There are multiple views on this. Everyone is confused, the minimal confusion 
> is probably on your side since you can see the source. The 
> Non-Opera-Debianers can only guess about it all  and remain confused. For 
> efficiency we want it all dynamic, for safety it is probably static.
> 
The problem runs a little deeper than that.

Static linking is considered bad because it is a security nightmare.
You now have extra copies of library code floating around.  The security
team is not particularly happy about this sort of thing.  Especially in
something non-free to which they do not have source-level access.

Additionally, static linking destroys any memory utilization benefit of
library code.  That is, if I have an app that dynamically links to
libfoo and another app also uses the same library, but is static linked,
then the second app will cause a copy of the code to be loaded.  On low
resource machines (which is one of Opera's targets), I would consider
that bad.

Of course, the advantage is that the release engineers would be assured
of the versions of the libraries used from the point of release.

Dynamic linking is what the security team likes since it means that you
only update the code once for the whole system.  However, in the event
that there is an update which makes the library non-binary compatible,
then there is another problem.  That is, apps linking against it must be
recompiled.  With a non-free product like opera, there would be ability
for some well-meaning Debian Developer to NMU the package (since there
is no source) or for a binNMU to take place if that could fix the
problem.

One possible solution would be for Opera to produce a "source" package
of unlinked binary object files.  This would allow relinking against new
versions of the libraries (at least in most cases) without the need for
access to the source.

However, I tend to be in agreement with others on this list that the
best solution would be a Free software release of Opera.

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Fwd: Re: Why no Opera?

[Steffen Moeller]

Dear Edward,

many thanks for joining in.

On Wednesday 05 September 2007 13:23:46 Edward Welbourne wrote:

> > Opera could offer an apt repository for the .deb
>
> We already do :-)
> Here's the line from my /etc/apt/sources.list:
>
> deb http://deb.opera.com/opera/ testing non-free

I was pointed to it by others on the list and have indicated it on this wiki 
page http://wiki.debian.org/UnofficialRepositories

> There are two packages available (for each of several configurations):
> opera is the shared-linkage version, opera-static is the
> statically-linked version.  The former comes in two flavours; .5 for
> sarge and .6 for etch onwards.  Things older than sarge are the reason
> for the static version.  With any luck, Claudio (one of the other
> parties to [EMAIL PROTECTED]) can add more detail on what's behind
> that ...

this sounds all very reasonable to me.

> > On Tuesday 28 August 2007 06:46:47 Bruce Sass wrote:
> >> On Mon August 27 2007 05:33:05 pm Romain Beauxis wrote:
> >> > Le Tuesday 28 August 2007 00:17:40 Bruce Sass, vous avez écrit :
> >> > > On Mon August 27 2007 04:05:24 pm Pierre Habouzit wrote:
> >> > > > And it's no way we will accept the statically linked version
> >> > > > in Debian.
> >>
> >> Of course, obviously---for software where there is a choice, but for
> >> software which can not be built from source because it is closed or not
> >> redistributable once modified (which seems to be the case with Opera),
> >> putting a statically linked version into the archive sounds like the
> >> correct solution.
>
> I'm confused.  Pierre appears to be saying "static is bad", Bruce
> "closed must be static".  We have both static and shared packages, so
> you can take your pick, but which is the one the official Debian
> repository wants ?
There are multiple views on this. Everyone is confused, the minimal confusion 
is probably on your side since you can see the source. The 
Non-Opera-Debianers can only guess about it all  and remain confused. For 
efficiency we want it all dynamic, for safety it is probably static.

> I should also note that the existing Opera packages have not been very
> lintian-compliant.  The new 9.50 release (we recently released an
> alpha) shall deploy my re-write of the scripts that do packaging: this
> fixes many of the deficiencies you'll find in packages up to 9.23, but
> I'd greatly appreciate guidance on how to improve what 9.50 does !
The ultimate solution of course would be an Open Source release. Though you'd 
certainly do that if you wanted to and others on this list probably will 
remind you of this idea anyway. So I will be quiet about it :)

For a closed source release it would be lovely if you had a Debian developer 
amongst your Opera developers who can upload packages to the distribution. 
This way, he could make sure that all the LGPL libraries that you may be 
shipping as part of your binary distribution appear as Debian packages 
themselves. Together with the other DDs he would have ensure that those 
libraries that are already in the distribution are working with Opera. And 
finally, he could prepare binary uploads of your package for the non-free 
section.

So, the Debian community would have someone (and sadly only one) who can 
inspect your source and fix issues that arise. The benefit I see for Opera is 
a further decreased footprint.

For an involvement of the community in the packaging of your latest versions I 
do not see how this would be possible without any knowledge about how Opera 
is working internally and about what libraries it uses. But this list is 
certainly the right one for technical issues, be it for packages aiming at 
your separate repository or for Debian's main one.

Best regards

Steffen

Re: Fwd: Re: Why no Opera?

[Edward Welbourne]

Hi debian-devel,

> The web of trust gave me Mr Johan Herland as the only member of strong set 
> and I took the freedom to place him on the CC line.

Johan forwarded you to me.  For reference, dpkg -s, or the package's
control file, would have told you:

Maintainer: Opera Packaging Team <[EMAIL PROTECTED]>

> Opera could offer an apt repository for the .deb

We already do :-)
Here's the line from my /etc/apt/sources.list:

deb http://deb.opera.com/opera/ testing non-free

There are two packages available (for each of several configurations):
opera is the shared-linkage version, opera-static is the
statically-linked version.  The former comes in two flavours; .5 for
sarge and .6 for etch onwards.  Things older than sarge are the reason
for the static version.  With any luck, Claudio (one of the other
parties to [EMAIL PROTECTED]) can add more detail on what's behind
that ...

> On Tuesday 28 August 2007 06:46:47 Bruce Sass wrote:
>> On Mon August 27 2007 05:33:05 pm Romain Beauxis wrote:
>> > Le Tuesday 28 August 2007 00:17:40 Bruce Sass, vous avez écrit :
>> > > On Mon August 27 2007 04:05:24 pm Pierre Habouzit wrote:
>> > > > And it's no way we will accept the statically linked version
>> > > > in Debian.

>> Of course, obviously---for software where there is a choice, but for
>> software which can not be built from source because it is closed or not
>> redistributable once modified (which seems to be the case with Opera),
>> putting a statically linked version into the archive sounds like the
>> correct solution.

I'm confused.  Pierre appears to be saying "static is bad", Bruce
"closed must be static".  We have both static and shared packages, so
you can take your pick, but which is the one the official Debian
repository wants ?

I should also note that the existing Opera packages have not been very
lintian-compliant.  The new 9.50 release (we recently released an
alpha) shall deploy my re-write of the scripts that do packaging: this
fixes many of the deficiencies you'll find in packages up to 9.23, but
I'd greatly appreciate guidance on how to improve what 9.50 does !

Thanks for mirroring our package,

Eddy.


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