Re: Going ahead with non-free-firmware

[Stefano Zacchiroli]

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 was indeed a mild
preference for non-free/firmware, because that names better captures the
fact that /firmware is indeed a sub-part of "non-free" rather than
something new. There was also concerns that introducing something
*separate* wouldn't fly with the social contract, which explicitly
mentions main/contrib/non-free whereas it does *not* mention
non-free-firmware. In that sense "just" allowing to select a sub part of
non-free wouldn't be a problem, whereas introducing something new might
be.

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 changes needed w.r.t. the
status quo. From other messages in this thread I understand this is
actually not going to be the case. Which would be problematic and also a
little bit disturbing. Is really no technical way to easily allow to
have packages in multiple (sub-)parts of the archive?

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: support for merged /usr in Debian

[Tom H]

On Wed, Jan 6, 2016 at 12:03 AM, Philipp Kern  wrote:
> On 2016-01-04 11:30, Marc Haber wrote:
>>
>> Please also notice that this is the only option for ExecStart in
>> systemd units. Well played, Lennart.
>
> Similarly skeleton-based init scripts use the full path as well. It helps if
> you can stat() it. Which, I guess, you could by extension by using "which"
> and the like. On the other hand init scripts are supposed to be runable in
> "env -i". Now, what would the PATH be for systemd to use? My skeleton-based
> init scripts ship their own PATH (yay, duplication and decentral
> configuration). I can see how you would want to use EnvironmentFile for
> that. But then, why not simply override ExecStart? And even then I don't see
> the point. (One reply would be "to reuse the distro-provided commandline
> arguments", which is fair, but you are already redirecting the path to the
> binary from the default anyway and are not using the distro one.)
>
> You can continue to childishly blame Lennart for everything, but that might
> cause others to stop taking you seriously. Which isn't really what you
> deserve.

Lennart didn't even say that he wanted to get rid of "EnvironmentFile=".

>From the same-named thread on systemd-devel@:

--- 8< ---
1)
I probably should never have added EnvironmentFile= in the first place.

2)
I think EnvironmentFile= was a mistake, and I explained why. But then
again, I am not planning to remove it, and I never suggested that.
--- >8 ---

He advocated the use of drop-ins, as you (Philipp) do.

There's one daemon (that I use) where this is a PitA; nfsd and its
associated executables. It would mean having to edit multiple units
rather than two files on Debian/Ubuntu and one file on Gentoo/RHEL.

Re: support for merged /usr in Debian

[Tom H]

Off-list.

On Wed, Jan 6, 2016 at 1:38 PM, Ansgar Burchardt  wrote:
>
> What is the advantage of having a optional-merged-/usr?

Imagine the opposition if this had been proposed as a non-optional change!

(BTW, I'll take this opportunity to thank you for two of your recent
proposals, the re-work of the list of packages to be installed by
default and the re-naming of the security suite. Thanks!)

Re: support for merged /usr in Debian

[Tom H]

Sorry. Not meant for list. :(

On Sun, Jan 10, 2016 at 9:59 AM, Tom H  wrote:
> Off-list.
>
> On Wed, Jan 6, 2016 at 1:38 PM, Ansgar Burchardt  wrote:
>>
>> What is the advantage of having a optional-merged-/usr?
>
> Imagine the opposition if this had been proposed as a non-optional change!
>
> (BTW, I'll take this opportunity to thank you for two of your recent
> proposals, the re-work of the list of packages to be installed by
> default and the re-naming of the security suite. Thanks!)

Re: Re: support for merged /usr in Debian

[Eric Valette]

Russ Allbery writes:


For one specific example, it's become quite clear over the past year that
systemd has achieved the same status as abortion debates in US politics.
Not only is it clear that we will *never* stop arguing about systemd,
opposition to or support of systemd has turned into a tribal identity
marker for at least some people.


Your example comparing systemd debate vs abortion debate is definitively 
insane : abortion is a philosophical debate that mainly roots whether 
you believe or not in god, which is not something that can be argued on 
its technical merits, or the fundamental compatibility problem it 
causes. The only point were your comparison makes sense is that 
communication by both opponent and proponent could have been better and 
less hostile (at least here in France).


Part of what ian said (copied below for ref), that has not been done 
with systemd is definitively the root cause of all the systemd debate



I think that people who want to change Debian should take care to:

  - Communicate respectfully;
  - Ensure technical interoperability between different
 approaches and different tools;
  - Carefully plan necessary transitions;
  - Approach change in a consensual manner;
  - Particularly, avoid hostile acts like publicly declaring
 other people's code or configurations dead or unsupported.


I have been criticizing systemd introduction in this newgroup/mailing 
lists because, at the beginning, it did break nearly all my systems, 
whereas it should not had:


	1) when you find /proc/config.gz and you know that some feature are 
required for systemd, you could check before installing it and avoid 
removing sysv init system even if mots pelple do use distribution kernel 
(without /proc/config.gz you can write program that will check features 
via system calls).
	2) as it started to depend on libraries located in /usr, it did break 
on my system with no initrd, and different / and /usr and it did break 
my system at least 5 or six times before stabilizing. I suggested to add 
a script to make sure sysdemd binary does not link with /usr located 
libraries to detect this before crashing people installations,


So this are clear example were simple technique could have been used to 
avoid breaking installed systems. It does cost a bit more effort but 
would have generated far less heated debate and meybe even les work at 
the end.


Now I do see benefits of systemd (boot faster) but the lack of easiness 
to define user modifiable parts (/etc/defaut/pkg) and things that are 
better left as the maintainer wants is still complicated and if you need 
to directly change default /lib/systemd/system/pkg.service its 
overridden during upgrade...


I have nas machines running debian without screen, video output, that 
have been installed via network and do not have easy way to repartition, 
not access to bootlodaer to install a different initrd, nor to repair 
other than soldering a serial line, so saying you should merge / and 
/usr or it may break and you will be on your own makes me less than 
happy. I thinks you can understand that.



I'll say it again: enthusiasm is fragile.  If we slap down excited people
every time they make intemperate comments out of enthusiasm, we lose SO
MUCH energy.  And I don't think we can afford to lose that much energy
from the project.


Agreed. But making transition smooth, may not cost that much and could 
preserve motivated people against hostile reactions if their changes 
breaks people habits/systems. So having a policy like Ian did propose 
for making fundamental changes may at the end avoid loosing energy..


--eric

Re: Going ahead with non-free-firmware

[Fabrice Aeschbacher]

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 changes needed w.r.t. the
> status quo.

this would be very appreciated indeed.

Cheers,
Fabrice

Re: Re: support for merged /usr in Debian

[benjamin barber]

I agree, one is about a person's right to not be forced to have something
that they aren't able to support and will cause their life difficulty, the
other is about abortion

> Your example comparing systemd debate vs abortion debate is definitively
insane : abortion is a philosophical debate that mainly roots whether you
believe or not in god, which is not something that can be argued on its
technical merits, or the fundamental compatibility problem it causes. The
only point were your comparison makes sense is that communication by both
opponent and proponent could have been better and less hostile (at least
here in France).
>

Re: support for merged /usr in Debian

[Marc Haber]

On Sun, 10 Jan 2016 09:53:52 +0100, Tom H  wrote:
>On Wed, Jan 6, 2016 at 12:03 AM, Philipp Kern  wrote:
>Lennart didn't even say that he wanted to get rid of "EnvironmentFile=".
>
>>From the same-named thread on systemd-devel@:
>
>--- 8< ---
>1)
>I probably should never have added EnvironmentFile= in the first place.
>
>2)
>I think EnvironmentFile= was a mistake, and I explained why. But then
>again, I am not planning to remove it, and I never suggested that.
>--- >8 ---
>
>He advocated the use of drop-ins, as you (Philipp) do.

Yes. But two of his militant fanbois suggested in the following that
the option should be removed because of Lennarts reasoning. In the
following, one of them said that if the option will be removed in the
future, it would be "our" because "we" had been using the option
"wrong" and have thus "forced lennart" to remove it since we refused
to be "educated" about "proper" use of systemd.

This is what got me furious. I am not here to be educated. I am here
to use software. What is the business of the systemd community to tell
me how I am to do my work?

Lennart is not always at fault. He has his problems with differing
opinions, but at least his reasoning is usually sound. The bigger
problems are his followers, most of them emulating his social behavior
because they think it's fine (I think the word is "role model"), but
without being this technically brilliant.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Bug#810600: ITP: minimap -- tool to find approximate mapping positions between long sequences

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: minimap
  Version : 0.2 
  Upstream Author : Heng Li 
* URL : https://github.com/lh3/minimap
* License : MIT
  Programming Lang: C
  Description : tool to find approximate mapping positions between long 
sequences

Minimap is an experimental tool to efficiently find multiple approximate
mapping positions between two sets of long sequences, such as between
reads and reference genomes, between genomes and between long noisy reads.
Minimap does not generate alignments as of now and because of this, it is
usually tens of times faster than mainstream aligners. 
It does not replace mainstream aligners, but it can be useful to simply
and quickly identify long approximate matches at moderate divergence among
a huge collection of sequences. For this task, it is much faster than most
existing tools.

This software will be maintained by the Debian Med Packaging team.

Bug#810602: ITP: argon2 -- memory-hard hashing function

[Luca Bruno]

Package: wnpp
Severity: wishlist
Owner: Luca Bruno 

* Package name: argon2
  Version : 0~20151206-1
  Upstream Author : D. Dinu, D. Khovratovich et al.
* URL : https://github.com/P-H-C/phc-winner-argon2
* License : CC0
  Programming Lang: C
  Description : memory-hard hashing function

 Argon2 is a password-hashing function that can be used to hash passwords
 for credential storage, key derivation, or other applications.
 .
 There are two main versions of Argon2: Argon2i and Argon2d.
 Argon2i is the safest against side-channel attacks, while Argon2d provides
 the highest resistance against GPU cracking attacks.
 .
 Argon2i and Argon2d are parametrized by:
  * A time cost, which defines the amount of computation realized and
therefore the execution time, given in number of iterations
  * A memory cost, which defines the memory usage, given in kibibytes
  * A parallelism degree, which defines the number of parallel threads

Re: Re: support for merged /usr in Debian

[Chris Bannister]

On Sun, Jan 10, 2016 at 10:56:21AM +0100, Eric Valette wrote:
> Russ Allbery writes:
> 
> >For one specific example, it's become quite clear over the past year that
> >systemd has achieved the same status as abortion debates in US politics.
> >Not only is it clear that we will *never* stop arguing about systemd,
> >opposition to or support of systemd has turned into a tribal identity
> >marker for at least some people.
> 
> Your example comparing systemd debate vs abortion debate is definitively
> insane : abortion is a philosophical debate that mainly roots whether you

Unbelievable!! What part don't you understand? He says it's "achieved
the same status", even I, understood at least that much. 

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

Re: Going ahead with non-free-firmware

[Bas Wijnen]

-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 means, that it won't happen for exactly those
> reasons I gave you before.

No, it's for the reason I gave: we're not anywhere near a consensus on what
would be good sections for a further split of the archive.  Everyone wants
something different.  You suggest that your split is supported by everyone, but
it isn't.  Many people don't care, some will even be opposed to it.  The same
is true for several other splits that some people might like to see (for
example "violates privacy", "intentionally crippled", or "contains
advertising").

You may wonder why firmware is so special that it does deserve a section right
now.  That's simple: at the moment, users with the "wrong" hardware need to
enable all of non-free if they want to install Debian.  There is a big
difference between someone saying "if I can't use this non-free program, I
don't want to use Debian" and "without this firmware, I am technically
incapable of using Debian".  The former we want to give an incentive to change
their mind, the latter is objectively correct and we can't do anything to
change it.

Your point is that some non-free things are not as bad as others.  This is
true.  However, there is no consensus on what is and what isn't "too much".
The only split on which we agree is free vs non-free.

And not only is there disagreement on which sections would be useful, the
options are also overlapping.  This means that a tag system is better than a
section system to solve this problem.  Just to be clear: the problem is that
people may want to install some software from non-free, but only if it follows
certain rules.  What those rules are is different for different people.  Your
preference is clear, but not shared by everyone.

If you think this is important and want to work on it, I suggest to do it in a
way that results in maximum support from others.  That means you shouldn't just
support the split you want, but other splits as well.  As I wrote, tags seem to
be the way to go.  What you would need to do:
- - Add debtags to differentiate the groups.
- - Patch apt to be able to use debtags filters, so the "wrong" packages will
  never be shown.

I think you should be able to find some people who want this as well, so you
don't have to do this alone.  Personally, I'm content with just non-free
(except for firmware), so I'm not going to work on this.

> - The name could be confusing, followed by some strange discussion of
> what open/free is.

This "strange discussion" is quite relevant however.  It demonstrates that
there is no agreement on how to split the archive.

> - That potentially other wishes for more non-free/* or non-open/*
> arise, which is however purely speculative as of now.

No, in the previous discussion several options came up.  There is no consensus.

> So let me perhaps ask more directly again:
> 1: Does Debian assume, that software for which the sources aren't
> publicly available can be generally trusted?

Debian doesn't have a shared opinion about that.  It's not about trust.  Debian
wants to make an operating system that is 100% free.  That is what the DFSG is
about, and that's the only thing we all agree on.

(Also, your next question assumes that saying "I don't trust things without
sources" implies "I do trust things with sources", which is incorrect.)

> If not:
> 
> 2: What would be the big disadvantages of allowing users to opt-in to
> software that is currently in "non-free" and has sources available,
> but opt-out of software which is currently in "non-free" as well, but
> doesn't have sources available (like for example steam)?

I don't like it personally, because it tells people "you can use some of
non-free, this part isn't so bad".  I prefer to send the message that free
software is what they should want to use.  That also gives authors more
incentive to choose a really free license (as opposed to "It'll get into the
almost-free section of Debian, which is good enough for me").

This is very personal though; others will have different opinions on this.
Again, there is no consensus.

> If none:
> 
> 3: What seems bad about the idea to solve this opt-in/opt-out via a
> suite like "non-free", "contrib", "main" (or are these called "archive
> areas" and not "suite"), especially when one considers the big
> advantage of that solution, namely that such software would then not
> even show up in the system?

They are called sections.  Suites are stable, testing, unstable.

The bad part is that this is very specific to the split you like, while others
want a different split.  A solution that would fix all of them at once would be
better.

> If nothing:
> 
> 4: Does it seam feasible to find a name for such "archive area", whic

Re: Going ahead with non-free-firmware

[Simon McVittie]

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 auditable) is necessarily the interesting distinction to make.

 is certainly not
source-available - we don't have the source files from which it was
compiled - but it's as safe to use as any other non-executable data package.

 contains firmware that
isn't source-available, but doesn't run on the main CPU (and hopefully
can't DMA out the main RAM).

Conversely, 
contains only Free Software (and is necessarily also source-available),
hence it's in contrib; but its entire purpose is to download executable
code that is not auditable, and based on historical experience, not safe
either.

S

Re: Re: Re: support for merged /usr in Debian

[Eric Valette]

On Sun, Jan 10, 2016 at 10:56:21AM +0100, Eric Valette wrote:

Russ Allbery writes:

>For one specific example, it's become quite clear over the past year that
>systemd has achieved the same status as abortion debates in US politics.
>Not only is it clear that we will *never* stop arguing about systemd,
>opposition to or support of systemd has turned into a tribal identity
>marker for at least some people.

Your example comparing systemd debate vs abortion debate is definitively
insane : abortion is a philosophical debate that mainly roots whether you


Unbelievable!! What part don't you understand? He says it's "achieved
the same status", even I, understood at least that much.


"Achieved the same status" BUT for totally different fundamental reasons 
so the reasoning is totally void. The analogy by itself, I let him the 
responsibility of comparing technical decisions to a matter of life or 
death


-- eric

Re: support for merged /usr in Debian

[Simon McVittie]

On 10/01/16 11:09, Marc Haber wrote:
> Yes. But two of his militant fanbois suggested in the following that
> the option should be removed

Unfortunately, any sufficiently large community seems to have people
whose contributions are not entirely (or sometimes not at all)
constructive. I'm sure there are people in and around Debian whose
opinions you wouldn't want to be associated with, and not every
community has someone as patient and diplomatic as Russ moderating its
discussions.

S

Re: support for merged /usr in Debian

[Eduard Bloch]

Hallo,
* Eric Valette [Sun, Jan 10 2016, 02:16:50PM]:
> >On Sun, Jan 10, 2016 at 10:56:21AM +0100, Eric Valette wrote:
> >>Russ Allbery writes:
> >>
> >>>For one specific example, it's become quite clear over the past year that
> >>>systemd has achieved the same status as abortion debates in US politics.
> >>>Not only is it clear that we will *never* stop arguing about systemd,
> >>>opposition to or support of systemd has turned into a tribal identity
> >>>marker for at least some people.
> >>
> >>Your example comparing systemd debate vs abortion debate is definitively
> >>insane : abortion is a philosophical debate that mainly roots whether you
> >
> >Unbelievable!! What part don't you understand? He says it's "achieved
> >the same status", even I, understood at least that much.
> 
> "Achieved the same status" BUT for totally different fundamental reasons so

Are they?

> the reasoning is totally void. The analogy by itself, I let him the
> responsibility of comparing technical decisions to a matter of life or
> death

Nonsense. You can see these patterns everywhere. The next thing coming
to my mind are holy wars about bike chain maintenance...

http://sheldonbrown.com/chains.html
> [And a comment from John Allen: the problem becomes religious because it 
> addresses mysteries of existence, life and death (of chains...) to which 
> there is no clear and obvious answer -- as long as the chain is exposed to 
> dirt.

Regards,
Eduard.

-- 
 kde und tastatur? passt doch nicht mit dem nutzerprofil
"windepp" zusammen :)

Bug#810619: ITP: python-ptk -- lexical analysis and parsing in Python, without code generation

[Nicolas Boulenguez]

Package: wnpp
Severity: wishlist
Owner: Nicolas Boulenguez 

* Package name: python-ptk
  Version : 1.2.0
  Upstream Author : Jérôme Laheurte 
* URL : https://bitbucket.org/fraca7/ptk
* License : LGPL-3
  Programming Lang: Python
  Description : lexical analysis and parsing in Python, without code 
generation

PTK is a LR(1) parser "generator" for Python. It is not actually a
"generator" in the sense that it doesn't output source code, using
Python's dynamic nature to build everything it needs at runtime
instead. Also, it supports asynchronous parsing.

Bug#810623: ITP: libdata-sah-normalize-perl -- Perl module to normalize Sah schema

[Lucas Kanashiroo]

Package: wnpp
Owner: Lucas Kanashiro 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libdata-sah-normalize-perl
  Version : 0.04
  Upstream Author : perlancar 
* URL : https://metacpan.org/release/Data-Sah-Normalize
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to normalize Sah schema

Data::Sah::Normalize often-needed functionality is split from the main
Data::Sah to keep it in a small and minimal-dependencies package.

This module allows to normalize clause set (hash) and Sah schema (scalar or
array).

The package will be maintained under the umbrella of the Debian Perl Group.


signature.asc
Description: PGP signature

Bug#810625: ITP: libperinci-sub-normalize-perl -- Perl module to normalize Rinci function metadata

[Lucas Kanashiroo]

Package: wnpp
Owner: Lucas Kanashiro 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libperinci-sub-normalize-perl
  Version : 0.15
  Upstream Author : perlancar 
* URL : https://metacpan.org/release/Perinci-Sub-Normalize
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to normalize Rinci function metadata

Perinci::Sub::Normalize normalizes and checks Rinci function metadata $meta
and returns a normalized metadata, which is a shallow copy of $meta. This is
done by normalize_function_metadata subroutine.

The package will be maintained under the umbrella of the Debian Perl Group.


signature.asc
Description: PGP signature

Bug#810653: ITP: libcgi-test-perl -- CGI regression test framework

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert 
Severity: wishlist

* Package name: libcgi-test-perl
  Version : 1.110
  Upstream Author : Alex Tokarev 
* URL : https://metacpan.org/release/CGI-Test
https://github.com/nohuhu/CGI-Test
* License : Artistic
  Programming Lang: Perl
  Description : CGI regression test framework

The CGI::Test framework is an answer to the CGI testing problem.

It is very difficult to perform testing of complex CGI scripts, which
handle multiple states and screens, and where a session involves
multiple interactions with the form.  The offline testing mode of the
CGI perl module reaches its limit there.

Hence CGI::Test, which acts as a "server" for CGI scripts and can run
them offline, outside of any real web server.  The framework offers
the infrastructure to analyze the data generated by CGI scripts,
extract the various widget information, and gives programmatic control
on them.

The framework can be used to easily "test" that the various expected
widget controls are there, without necessarily interacting with the
widgets.  You also have access to the raw HTML tree if you wish to
further inspect the generation.

The package will be maintained under the umbrella of the Debian Perl
Group.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Re: Going ahead with non-free-firmware

[Paul Wise]

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 link may look rather familiar,
>> > as the OSI based their definition on the DFSG.)
>>
>> Aside from any re-definitions/interpretations made by OSI respectively
>> the community, "open source" by the words alone means open source,
>> which doesn't imply any freeness, or whether it's copyleft or not.
>> See for example
>> https://www.gnu.org/philosophy/open-source-misses-the-point.html for
>> more thoughts on free vs. open.
>
> Wait, you are citing this to advocate using "open" to mean "non-free, but with
> source"?  Are you intentionally trying to cause maximum confusion?
>
>> Also just because the OpenSource community claims "open source" to
>> have the meaning which we all commonly assume, doesn't mean that this
>> belongs to us.
>
> The open source and free software communities have almost 100% overlap.  I'm
> pretty sure there is very broad consensus that we don't want to piss off
> everyone who says "open source", especially if there's no reason for it.

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.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Going ahead with non-free-firmware

[Marco d'Itri]

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 around: "open source" was intended to mean 
essentially the same thing as "Free Software".
If you feel like a free software historian you can have a look at the 
debian-private@ archive to see how the name was born and why.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Debian Installer Stretch Alpha 5 release

[Adam Wilson]

On Sun, 10 Jan 2016 23:39:35 +0100
Cyril Brulebois  wrote:

> The Debian Installer team[1] is pleased to announce the fifth alpha
> release of the installer for Debian 9 "Stretch".
> 
> 
> Important change in this release of the installer
> =
> 
>  * The i386 architecture now requires 686-class processors:
>https://lists.debian.org/debian-devel/2015/09/msg00589.html

Why not just call it i686 then, in the Arch style?

Re: Debian Installer Stretch Alpha 5 release

[Philipp Kern]

On Mon, Jan 11, 2016 at 07:41:10AM +0300, Adam Wilson wrote:
> On Sun, 10 Jan 2016 23:39:35 +0100
> Cyril Brulebois  wrote:
> > The Debian Installer team[1] is pleased to announce the fifth alpha
> > release of the installer for Debian 9 "Stretch".
> > 
> > 
> > Important change in this release of the installer
> > =
> > 
> >  * The i386 architecture now requires 686-class processors:
> >https://lists.debian.org/debian-devel/2015/09/msg00589.html
> Why not just call it i686 then, in the Arch style?

What exactly? Renaming Debian architectures is not really possible (it's
stored in filenames, previous releases need to be upgradeable, dpkg
needs to know about it). Even if we update single instances like the
path to the manual, that rather increases confusion given the mismatch
with the files and other bits like archive metadata.

Kind regards
Philipp Kern

Re: Going ahead with non-free-firmware

[Philipp Kern]

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.  I'm wondering what we need
> > > to do next?
> > I applaud this call for action; I'd certainly be an enthusiastic
> > user.
> Me too, it's too bad that it took almost 15 years to reach a consensus 
> over what I proposed at the time.

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. :)

Kind regards
Philipp Kern

Bug#810667: ITP: golang-github-prometheus-common -- Common libraries for Prometheus components

[Martín Ferrari]

Package: wnpp
Severity: wishlist
Owner: "Martín Ferrari" 

* Package name: golang-github-prometheus-common
  Version : 0+git20160104.0a3005b
  Upstream Author : The Prometheus Authors
* URL : https://github.com/prometheus/common/
* License : Apache-2.0
  Programming Lang: Go
  Description : Common libraries for Prometheus components

 * github.com/prometheus/common/log: Wraps https://github.com/Sirupsen/logrus
   in order to add line:file annotations to log lines, as well as to provide
   common command-line flags for Prometheus components using it.
 * github.com/prometheus/common/model: Shared data structures
 * github.com/prometheus/common/expfmt: Decoding and encoding for the 
exposition format
 * github.com/prometheus/common/route: A routing wrapper around
   https://github.com/julienschmidt/httprouter using `context.Context`

(Note that this package supercedes golang-github-prometheus-log, which I will
ask for removal after all its reverse-deps migrate to this package.)

Re: Going ahead with non-free-firmware

[Stefano Zacchiroli]

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 naming was precisely to make
it clear that it's just a subset of what is already mentioned in SC §5.
Introducing (what looks like) a new section would incur in the issue you
just mentioned.

I don't remember anyone proposing to highlight a specific subset of
non-free, rather then introducing a new archive area, in the discussions
of years ago, but maybe it's just me.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature