On Fri, 2016-01-15 at 14:07 +0100, Marco d'Itri wrote:
> On Jan 15, chrysn wrote:
>
> > Right now microcode does not fit in that middle ground from either 1)
> > (because no DMA to protect us) nor 2) (because things work without as
> > well). If, at some future point in time, CPUs do require micr
On Jan 15, chrysn wrote:
> Right now microcode does not fit in that middle ground from either 1)
> (because no DMA to protect us) nor 2) (because things work without as
> well). If, at some future point in time, CPUs do require microcode
> updates, we might need to revisit this.
CPUs *do* require
On Mon, Jan 11, 2016 at 09:34:07AM -0800, Nikolaus Rath wrote:
> On Jan 09 2016, Dominic Hargreaves wrote:
> > I think the *policy* for this section should be firmware, as defined
> > as code not executing on the main CPU, or something like that.
>
> Uh, so intel-microcode is still out?
From th
On 11/01/16 at 10:49 +0100, Stefano Zacchiroli wrote:
> On Mon, Jan 11, 2016 at 05:43:45PM +0800, Paul Wise wrote:
> > On Mon, Jan 11, 2016 at 5:23 PM, Ansgar Burchardt wrote:
> > > So you don't want another component, but something that looks like a
> > > component in some places only? I.e. it be
On Mon, 2016-01-11 at 10:49 +0100, Stefano Zacchiroli wrote:
> On Mon, Jan 11, 2016 at 05:43:45PM +0800, Paul Wise wrote:
> > On Mon, Jan 11, 2016 at 5:23 PM, Ansgar Burchardt wrote:
> > > So you don't want another component, but something that looks like a
> > > component in some places only? I.e
On Jan 09 2016, Dominic Hargreaves wrote:
> I think the *policy* for this section should be firmware, as defined
> as code not executing on the main CPU, or something like that.
Uh, so intel-microcode is still out?
Description: Processor microcode firmware for Intel CPUs
This package contains
On Mon, Jan 11, 2016 at 6:18 PM, Ansgar Burchardt wrote:
> I'm pretty sure we don't want to do so in the main archive though as we
> don't want to ship even more (large) indices.
The idea there was smaller cut-down indicies so that not all clients
need to download the (large) full indicies and st
Paul Wise writes:
> On Mon, Jan 11, 2016 at 5:23 PM, Ansgar Burchardt wrote:
>> So you don't want another component, but something that looks like a
>> component in some places only? I.e. it behaves like a component in that
>> it gets its own Packages (and Sources?) indices, but it has neither it
On Mon, Jan 11, 2016 at 05:43:45PM +0800, Paul Wise wrote:
> On Mon, Jan 11, 2016 at 5:23 PM, Ansgar Burchardt wrote:
> > So you don't want another component, but something that looks like a
> > component in some places only? I.e. it behaves like a component in that
> > it gets its own Packages (a
On Mon, Jan 11, 2016 at 5:23 PM, Ansgar Burchardt wrote:
> So you don't want another component, but something that looks like a
> component in some places only? I.e. it behaves like a component in that
> it gets its own Packages (and Sources?) indices, but it has neither its
> own area in pool/ n
Stefano Zacchiroli writes:
> On Mon, Jan 11, 2016 at 09:52:08AM +0100, Ansgar Burchardt wrote:
>> dak doesn't really like having a package in multiple components: the
>> layout of pool/ requires that the files would have to be duplicated.
>> Then dak only knows that a "binary package" belongs to a
On Mon, Jan 11, 2016 at 09:52:08AM +0100, Ansgar Burchardt wrote:
> dak doesn't really like having a package in multiple components: the
> layout of pool/ requires that the files would have to be duplicated.
> Then dak only knows that a "binary package" belongs to a suite, not to
> a given (suite,
On Mon, Jan 11, 2016 at 4:52 PM, Ansgar Burchardt wrote:
> And gives problems: the "Section" field has either just the ${section}
> or ${component}/${section}. If component now also has a "/" in it,
> there will likely be bugs. I don't think aesthetic reasons call for
> this breakage if we can a
Stefano Zacchiroli writes:
> On Sat, Jan 09, 2016 at 08:48:25PM +, Steve McIntyre wrote:
>> Are we sure on the name? Previous commenters have suggested that
>> "non-free/firmware" might be better. I understand that may be more
>> awkward to implement in terms of directories... :-)
>
> If my re
On Mon, Jan 11, 2016 at 08:25:21AM +0100, Philipp Kern wrote:
> I kept suggesting the same, but thought that it'd need a GR because of
> "non-free" and "contrib" being listed explicitly in DFSG §5. Happy to
> see that this wasn't actually necessary. :)
One of the points of the non-free/firmware na
On Sat, Jan 09, 2016 at 09:15:45PM +0100, Marco d'Itri wrote:
> On Jan 09, Dominic Hargreaves wrote:
> > On Sat, Jan 09, 2016 at 11:51:08AM +0100, Ansgar Burchardt wrote:
> > > I think there was consensus to introduce the non-free-firmware section
> > > and move the non-free firmware blobs there.
On Jan 11, Paul Wise wrote:
> FYI: there are people out there who are still angry at ESR/OSI for
> hijacking the term "open source" to mean essentially the same thing as
> "Free Software" instead of what they used it for; anything with
> publicly released source code.
Actually it is the other way
On Sun, Jan 10, 2016 at 9:03 PM, Bas Wijnen wrote:
> On Sun, Jan 10, 2016 at 02:09:24AM +0100, Philippe Cerfon wrote:
>> On Sun, Jan 10, 2016 at 1:11 AM, Josh Triplett wrote:
>> > "open" does not mean "has source available"; "Open Source" is defined
>> > here: http://opensource.org/osd . (That lin
On 09/01/16 23:22, Philippe Cerfon wrote:
> For non-open, the definition is quite clear: all or some of the
> sources are no available.
If the question you're trying to answer is "is this safe?", then I don't
think source-available (and hence auditable) vs source-unavailable (and
hence not auditab
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Jan 10, 2016 at 02:09:24AM +0100, Philippe Cerfon wrote:
> On Sun, Jan 10, 2016 at 1:11 AM, Josh Triplett wrote:
> > They will if people care as much about that separation as they do about
> > separating firmware.
>
> Which effectively still
2016-01-10 9:27 GMT+01:00 Stefano Zacchiroli :
> But an important part of the above reasoning in favor of
> non-free/firmware was that user enabling explicitly non-free in the
> sources.list and *not* enabling non-free/firmware would get the non-free
> firmware anyhow. I.e., no regressions or chang
On Sat, Jan 09, 2016 at 08:48:25PM +, Steve McIntyre wrote:
> Are we sure on the name? Previous commenters have suggested that
> "non-free/firmware" might be better. I understand that may be more
> awkward to implement in terms of directories... :-)
If my recalling is correct, at the BoF there
On Sun, Jan 10, 2016 at 1:11 AM, Josh Triplett wrote:
> They will if people care as much about that separation as they do about
> separating firmware.
Which effectively still means, that it won't happen for exactly those
reasons I gave you before.
While following the lists, I've noted that sever
On Sat, Jan 9, 2016 at 11:00 PM, Ansgar Burchardt wrote:
> Just in non-free-firmware. This means users will have to update their
> sources.list, but they will have to do so anyway[1].
Hmm, that is going to be annoying. It also seems strange because
non-free firmware is a subset of all non-free r
On Sun, Jan 10, 2016 at 12:22:28AM +0100, Philippe Cerfon wrote:
> On Sat, Jan 9, 2016 at 11:47 PM, Josh Triplett wrote:
> > Not true at all. A future change to build a more fine-grained version
> > of non-free could happen just as easily with or without this change.
>
> I don't agree.
> If ther
On Sat, Jan 9, 2016 at 11:47 PM, Josh Triplett wrote:
> Not true at all. A future change to build a more fine-grained version
> of non-free could happen just as easily with or without this change.
I don't agree.
If there is now lots of effort put into adding another suite, people
will probably n
Philippe Cerfon wrote:
> Ansgar Burchardt wrote:
> > I think there was consensus to introduce the non-free-firmware
> > section
> > and move the non-free firmware blobs there. I'm wondering what we
> > need
> > to do next?
>
> While it's good that at least something happens it's really sad and
>
And btw:
Even if Debian doesn't want to do the non-open thing now or perhaps
generally doesn't want to allow people to opt-out of closed source
software while keeping other non-free software, then the name
non-free-firmware seems to break the current naming, doesn't it?
main
contrib
non-free
These
Ansgar Burchardt wrote:
> I think there was consensus to introduce the non-free-firmware
> section
> and move the non-free firmware blobs there. I'm wondering what we
> need
> to do next?
While it's good that at least something happens it's really sad and
kinda disturbing to see that a more narro
Matthias Klump wrote:
>
>I wonder if we should widen the scope of a "non-free-firmware"
>component a little, to "anything non-free you sometimes unfortunately
>need to make your hardware usable".
>
>This would mean having a "non-free-hardware" section instead, which
>could possibly also include non
On Sat, Jan 09, 2016 at 11:51:08AM +0100, Ansgar Burchardt wrote:
>Hi,
>
>I think there was consensus to introduce the non-free-firmware section
>and move the non-free firmware blobs there. I'm wondering what we need
>to do next?
>
>Besides the ftp team setting the new section up, I expect the ins
On Jan 09, Matthias Klumpp wrote:
> I wonder if we should widen the scope of a "non-free-firmware"
> component a little, to "anything non-free you sometimes unfortunately
> need to make your hardware usable".
> This would mean having a "non-free-hardware" section instead, which
> could possibly a
2016-01-09 21:15 GMT+01:00 Marco d'Itri :
> On Jan 09, Dominic Hargreaves wrote:
>
>> On Sat, Jan 09, 2016 at 11:51:08AM +0100, Ansgar Burchardt wrote:
>> > I think there was consensus to introduce the non-free-firmware section
>> > and move the non-free firmware blobs there. I'm wondering what w
On Jan 09, Dominic Hargreaves wrote:
> On Sat, Jan 09, 2016 at 11:51:08AM +0100, Ansgar Burchardt wrote:
> > I think there was consensus to introduce the non-free-firmware section
> > and move the non-free firmware blobs there. I'm wondering what we need
> > to do next?
> I applaud this call for
On Sat, Jan 09, 2016 at 11:51:08AM +0100, Ansgar Burchardt wrote:
> I think there was consensus to introduce the non-free-firmware section
> and move the non-free firmware blobs there. I'm wondering what we need
> to do next?
I applaud this call for action; I'd certainly be an enthusiastic
user.
Paul Wise writes:
> On Sat, Jan 9, 2016 at 6:51 PM, Ansgar Burchardt wrote:
>> I think there was consensus to introduce the non-free-firmware section
>> and move the non-free firmware blobs there. I'm wondering what we need
>> to do next?
>
> I have a question about the implementation; will non-f
Ansgar Burchardt (2016-01-09):
> I think there was consensus to introduce the non-free-firmware section
> and move the non-free firmware blobs there. I'm wondering what we need
> to do next?
>
> Besides the ftp team setting the new section up, I expect the installer
> would need changes to enabl
On Sat, Jan 9, 2016 at 6:51 PM, Ansgar Burchardt wrote:
> I think there was consensus to introduce the non-free-firmware section
> and move the non-free firmware blobs there. I'm wondering what we need
> to do next?
I have a question about the implementation; will non-free firmware be
in non-fre
Hi,
I think there was consensus to introduce the non-free-firmware section
and move the non-free firmware blobs there. I'm wondering what we need
to do next?
Besides the ftp team setting the new section up, I expect the installer
would need changes to enable it instead of non-free when non-free
39 matches
Mail list logo
