3:10 a.m.
On Tue, 2006-10-17 at 10:08 -0500, Tom 'spot' Callaway wrote:
On Tue, 2006-10-17 at 05:32 -0500, Callum Lerwick wrote:
> On Mon, 2006-10-16 at 09:52 +0200, Hans de Goede wrote:
> > What I was trying to say with the above message is that if someone else
> > is willing to have the discussion for a package here and if the outcome
> > is that the package is ok for Extras then I'm more then happy to move it
> > to Extras including putting it through review (again as all packages in
> > dribble are already reviewed).
>
> I'll do it! (I used various Atari STs from 1987 to 1997...)
>
> On Mon, 2006-10-16 at 12:36 +0530, Rahul Sundaram wrote:
> > I believe the rule of thumb here is that if we have freely
> > redistributable "data" that runs on these emulators, we can include
the
> > emulator in extras. In other words, the question to ask yourself, is
> > there any legal and Free software uses for the emulators?
>
>
> Since there's GPL ROMs available[1], and the commonly used FreeMiNT
> kernel is apparently a mix of GPL and BSD[2], and most anything open
> source has been ported, and even packaged into RPMs[3], seems to me any
> Atari ST series emulator should be okay in Extras. ARAnyM can even run
> Linux/68k[4].
>
> Anyone disagree? Do we need a FESCo blessing?
No disagreement here. This is fine for Fedora.
Well, though I agree to you, I think
you are about to construct a
precedence, which longs for an explanation, which probably should be
reflected to the package guidelines:
This case clearly violates:
http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement
and also is not covered by
http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware
These ROMs aren't a linux system's firmware, these are a foreign
system's firmware, to be interpreted by an interpreter (emulator).
Ralf
9:42 a.m.
New subject: Announcing Dribble a new addon repo for Fedora Extras users
>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> This case clearly violates:
RC> http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement
Except that it's firmware.
RC> and also is not covered by
RC> http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware
It seems to me that it is.
"Some applications and drivers require binary-only firmware to
function."
OK, this is an application (an emulator) which requires the host
system's binary firmware in order to function.
"The files are non-executable (note: this means that the files cannot
run on their own, not that they are just chmod -x)"
Check.
"The files are not libraries."
Check.
"The files are standalone, not embedded in executable or library code."
Check.
"Explicit permission is given by the owner to freely distribute
without restrictions (this permission must be included, in "writing",
with the files in the packaging)"
Check.
"The files must be necessary for the functionality of open source code
being included in Fedora."
Check.
I assume you disagree with one or more of these, but I'm not sure which.
RC> These ROMs aren't a linux system's firmware, these are a foreign
RC> system's firmware, to be interpreted by an interpreter (emulator).
Precisely. Are you drawing the distinction between firmware that is
executed by hardware that that which is executed by emulated hardware,
perhaps?
- J<
10:08 a.m.
New subject: Announcing Dribble a new addon repo for Fedora Extras users
On Wed, 2006-10-18 at 09:42 -0500, Jason L Tibbitts III wrote:
>>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> This case clearly violates:
RC> http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement
Except that it's firmware.
C.f. below: I am questioning the separation between "firmware" and
"binary".
RC> and also is not covered by
RC> http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware
It seems to me that it is.
"Some applications and drivers require binary-only firmware to
function."
OK, this is an application (an emulator) which requires the host
system's binary firmware in order to function.
"The files are non-executable (note: this means that the files cannot
run on their own, not that they are just chmod -x)"
Check.
Only a matter of mime-types, resp. of the way an emulator is being
launched.
"The files are not libraries."
Check.
Irrelevant. Traditional libraries (ar-archives) are just a form of
packaging.
"The files are standalone, not embedded in executable or library
code."
Check.
Irrelevant, implementation detail.
Such images can easily be transformed between different representations.
Technically it doesn't matter if they are loaded from external files
into memory or are directly embedded into a application's memory.
"Explicit permission is given by the owner to freely distribute
without restrictions (this permission must be included, in "writing",
with the files in the packaging)"
Check.
ACK.
"The files must be necessary for the functionality of open
source code
being included in Fedora."
Check.
ACK.
I assume you disagree with one or more of these, but I'm not sure
which.
RC> These ROMs aren't a linux system's firmware, these are a foreign
RC> system's firmware, to be interpreted by an interpreter (emulator).
Precisely. Are you drawing the distinction between firmware that is
executed by hardware that that which is executed by emulated hardware,
perhaps?
Absolutely not. I am not questioning allowing such binaries (I am all
for it), I am questioning the Fedora Packaging Guidelines.
I consider the separation of firmware from "other binaries" inside of
the FPG to be nonsensical and the criteria above to be nonsensical, and
wish we (FPC) were able to find better criteria.
Consider, an emulator's "firmware" from a Linux's system's
perspective
is not any different from other "binary shipped applications" to be run
on an interpreter.
Ralf
11:13 a.m.
New subject: Announcing Dribble a new addon repo for Fedora Extras users
On Wed, Oct 18, 2006 at 05:08:23PM +0200, Ralf Corsepius wrote:
I consider the separation of firmware from "other binaries"
inside of
the FPG to be nonsensical and the criteria above to be nonsensical, and
wish we (FPC) were able to find better criteria.
I think the package group's mandate is about *how* to package, not
*what* to package and whether it's legal, endagers Fedora sponsors, is
in the spirit of Fedora etc.
E.g. these goals are set from a higher instance and we just provide
matching guidelines. IMO we shouldn't redefine objectives, this needs
to be escalated to <your board here>. Especially if something isn't
spelled out in the current objectives as clear as the
position/distinction towards firmwares and other non-source binaries.
--
Axel.Thimm at ATrpms.net
12:03 a.m.
New subject: Announcing Dribble a new addon repo for Fedora Extras users
On Wed, 2006-10-18 at 18:13 +0200, Axel Thimm wrote:
On Wed, Oct 18, 2006 at 05:08:23PM +0200, Ralf Corsepius wrote:
> I consider the separation of firmware from "other binaries" inside of
> the FPG to be nonsensical and the criteria above to be nonsensical, and
> wish we (FPC) were able to find better criteria.
I think the package group's mandate is about *how* to package,
ACK.
not
*what* to package and whether it's legal, endagers Fedora sponsors, is
in the spirit of Fedora etc.
This questions lurking inside of this topic are "how" questions:
* "How to package package-fragments source ship/require in binary form"
* "When to consider rebuilding from sources not useful".
The FPG it tries to narrow this problem to a set of precedences of
exception on "what" (firmware), but actually doesn't cover these
questions above, except that it wants packagers "to build everything
from sources".
E.g. these goals are set from a higher instance and we just provide
matching guidelines. IMO we shouldn't redefine objectives, this needs
to be escalated to <your board here>. Especially if something isn't
spelled out in the current objectives as clear as the
position/distinction towards firmwares and other non-source binaries.
The later half of your sentence is what I consider not to be clear.
Technically, firmware blobs are "download images", i.e. a container of
arbitrary format with arbitrary contents, just like floppy disks images,
CDROM images, tarballs or ar-archives.
Do you note how the FPG criteria manage to miss the topic?
Ralf
6:55 a.m.
New subject: Firmwares, roms and who decides on packagable items
On Thu, Oct 19, 2006 at 07:03:01AM +0200, Ralf Corsepius wrote:
> I think the package group's mandate is about *how* to
package,
ACK.
> not *what* to package and whether it's legal, endagers Fedora
> sponsors, is in the spirit of Fedora etc.
This questions lurking inside of this topic are "how" questions:
* "How to package package-fragments source ship/require in binary form"
* "When to consider rebuilding from sources not useful".
The FPG it tries to narrow this problem to a set of precedences of
exception on "what" (firmware), but actually doesn't cover these
questions above, except that it wants packagers "to build everything
from sources".
> E.g. these goals are set from a higher instance and we just provide
> matching guidelines. IMO we shouldn't redefine objectives, this needs
> to be escalated to <your board here>. Especially if something isn't
> spelled out in the current objectives as clear as the
> position/distinction towards firmwares and other non-source binaries.
The later half of your sentence is what I consider not to be clear.
Technically, firmware blobs are "download images", i.e. a container of
arbitrary format with arbitrary contents, just like floppy disks images,
CDROM images, tarballs or ar-archives.
Do you note how the FPG criteria manage to miss the topic?
What I'm trying to say is that we need to get told what is allowed to
be packaged or not. Some here consider roms for emulators firmware,
others not, and depending on that we can or cannot apply existing
rules about firmwares. Instead of fighting over definitions let's just
ask our parents to decide on roms of emulators.
Just to present the hyperbole: Next somone packages filesystem images
for qemu and argues that these are firmwares, too. I wouldn't want to
be arguing against or in favour of that, we need clear a list of clear
exceptions to open source items.
Or a more down-to-earth example: madwifi argues that the closed source
part of it is like firmware for various reasons (I'm not trying to
support or not that view, just giving examples).
So, as a dump package engineer, who's job is to craft technical
guidelines on *how* to package stuff, I want to get the set of
packagable items from management. :)
--
Axel.Thimm at ATrpms.net
6392
days inactive
6393
days old
packaging@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Axel Thimm -
Jason L Tibbitts III -
Ralf Corsepius