Re: SPAM

[Stephen Kitt]

On Mon, 6 Mar 2017 11:15:23 -0500, Christopher Clements 
wrote:
> On Mon, Mar 06, 2017 at 05:01:40PM +0100, Philip Hands wrote:
> >However, because the spam meaasges are created by copying most of the
> >headers from a genuine list mail, when you reply to such a message, it
> >turns up on our lists, and looks like it might even be a reply to a real
> >thread (until you notice that the body of the message they were replying
> >to has never previously been seen on the list).  
> 
> Wow.
> This is the exact reason I sign all my messages.
> 
> Thanks for proving that I'm not _overly_ paranoid!

Signatures don't protect you in this case, because they only cover the
message body, not even the headers.

This also means that signing *everything* isn't necessarily a good idea: if
you sign a re-usable message body, anyone can re-send that body and your
signature with different headers (different subject, different apparent
sender and recipients) and a different envelope (different real sender and
recipients).

Regards,

Stephen


pgpJRqBOKqbyL.pgp
Description: OpenPGP digital signature

Re: systemd, ntp, kernel and hwclock

[Vincent Lefevre]

On 2017-02-28 20:01:52 +0100, Carsten Leonhardt wrote:
> Daniel Pocock  writes:
> 
> > On 27/02/17 21:26, Ben Hutchings wrote:
> >> But ntpd is also known to have a large amount of code written
> >> without as much regard for security as one would hope.  It seems
> >> like an unnecessary risk for most systems.
> 
> > Thanks for that security tip, I'm tempted to get rid of some ntpd
> > instances now, however a few more questions come to mind before I rush in:
> 
> Have a look at openntpd, that's coded with security in mind.

But this doesn't apply to the Debian version, as documented. And it
is buggy. I had to remove it from my machine because it did more harm
than solving problems.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: systemd, ntp, kernel and hwclock

[Vincent Lefevre]

On 2017-03-05 03:52:33 +, Ben Hutchings wrote:
> I would also expect that users running command-line tools to set the
> time, such as ntpdate, have enough technical understanding to
> distinguish the system clock and RTC.

And what's worse is that by default, ntpdate is run automatically from
/etc/network/if-up.d, so that the date could become incorrect without
a control from the user.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844520

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#857037: ITP: node-querystring -- Node's querystring module for all engines.

[Rahulkrishnan R A]

Package: wnpp
Severity: wishlist
Owner: Rahulkrishnan R A 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-querystring
  Version : 0.2.0
  Upstream Author : Irakli Gozalishvili 
* URL : https://github.com/Gozala/querystring
* License : Expat
  Programming Lang: JavaScript
  Description : Node's querystring module for all engines.
  .
 Node.js is an event-based server-side JavaScript engine.


-- 
Regards,

Rahulkrishnan R A

Bug#857038: ITP: golang-github-fatih-structs -- Utilities for Go structs

[Henti Smith]

Package: wnpp
Severity: wishlist
Owner: Henti Smith 
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org

* Package name: golang-github-fatih-structs
  Version : 0.0~git20170103.0.a720dfa-1
  Upstream Author : Fatih Arslan
* URL : https://github.com/fatih/structs
* License : Expat
  Programming Lang: Go
  Description : Utilities for Go structs

 Structs contains various utilities to work with Go (Golang) structs. It was
 initially used to convert a struct into a map[string]interface{}.
 With time other utilities for structs have been added.  It's basically a
high
 level package based on primitives from the reflect package.


-- 
--

Bug#857040: ITP: rpc -- A golang foundation for RPC over HTTP services.

[Henti Smith]

Package: wnpp
Severity: wishlist
Owner: Henti Smith 
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org

* Package name: rpc
  Version : 0.0~git20160927.0.22c016f-1
  Upstream Author : Gorilla web toolkit
* URL : https://github.com/gorilla/rpc
* License : BSD-3-clause
  Programming Lang: Go
  Description : A golang foundation for RPC over HTTP services.

 gorilla/rpc is a foundation for RPC over HTTP services, providing access
 to the exported methods of an object through HTTP requests.


-- 
--

ITP: thonny -- Python IDE for beginners

[Aivar Annamaa]

Package: wnpp
Severity: wishlist
Owner: Aivar Annamaa 

* Package name: thonny
  Version : 2.1.0
  Upstream Author : Aivar Annamaa
* URL : http://thonny.org
* License : MIT
  Programming Lang: Python
  Description : Python IDE for beginners

Thonny is a simple Python IDE with features for learning programming 
(statement and expression stepping, live variables, syntax assistance, 
etc). Please see homepage for illustrated list of features. It's 
developed in University of Tartu, Estonia.


It requires only Python 3.4 or later and Tkinter.

Version 2.1.0 will be released by the end of March and I also hope to 
finish the package by then.


I'm not Debian Devoloper, so I'll need a sponsor as well.

best regards,
Aivar Annamaa

Re: Non-free RFCs in stretch

[Ian Jackson]

Philip Hands writes ("Re: Non-free RFCs in stretch"):
> I presume this issue arises because people (myself included) dislike the
> fact that in order to install some RFCs and/or GNU documentation one has
> to flick a switch that also opens the door to some thoroughly
> proprietary software.

This is indeed a bad problem.  I would like to be able to install
firmware for my wifi card, and GNU manuals, and the Common Lisp
hyperspec installer, and so on.  This is despite agreeing with the
classification of these things as non-free (or indeed contrib).

> I suppose it might be possible that we (as a project) could agree to
> some of these subsets being easier and/or harder to enable, and thus
> allow the FSF to feel more cheerful about the way we look at the world.

I have a suggestion for how this could be done.

We give each reason-why-a-package-might-be-nonfree-or-contrib
a name in the package namespace.  I'm going to call these packages
antimetapackages.

Each package in non-free or contrib must Recommend all the
antimetapackages which apply.

Sometimes a wrongness is a special case of another kind of wrongness.
In that case the more specific antimetapackage Recommends the less
specific one, and real packages can Recommend only the more specific.

We use Recommends because these are all policy decisions which the
user may wish to override on an individual basis.

All of these metapackages should live in contrib, because they
themselves contain nothing nonfree.  Installer packages in contrib
should be classified according to the thing they download, not the
content of the package itself.

With pattern match pinning, or other tooling, it then becomes possible
for a user to be specific about which compromises they which to make.

For example:

   Package: make-doc
   Recommends: nonfree-gfdl-invariant
   Section: non-free/doc

   Package: nonfree-gfdl-invariant
   Recommends: nonfree-documentation
   Section: contrib/antimetapackages
   Description: Problems with the GNU Free Documentation Licence
This antimetapackage is a dependency for documentation,
under the GNU Free Documentation Licence, containing
invariant sections and/or front/back cover texts.
.
Debian considers such documentation non-free because it
cannot be freely modified.  (See the General Resolution in
[etc. etc]

   Package: doc-rfc-std
   Recommends: nonfree-nonmodifiable-standards
   Section: non-free/doc

   Package: nonfree-nonmodifiable-standards
   Recommends: nonfree-documentation
   Section: contrib/antimetapackages
   Description: Problems with modifiability of standards docs
This antimetapackage is a dependency for standards
documents which are freely redistributable, but which
do not freely permit modification outside the context
of the standards-setting process.
.
Debian consisders such standards documents non-free, because end
users are not free to make and document unofficial modified
versions of these standards and protocols.

   Package: hyperspec
   Section: contrib/doc
   Recommends: nonfree-documentation
   Description: The Common Lisp ANSI-standard Hyperspec
This is a installer package [...]

   Package: nonfree-documentation
This antimetapackage is a dependency for documentation
which is not considered Free by Debian, for a variety
of reasons.

   Package: nonfree-misc-nonfree
This antimetapackage is a dependency for non-free software
in Debian whose lack of freedom has not been classified, or
which is not covered by any more specific antimetapackage.

Politics: the set of antimetapackages, and which of them must be
Recommended when, is ultimately in case of dispute the responsibility
of ftpmaster, and enforced by appropriate (auto)REJECTs.  But normally
decisions will be made by the maintainers (of the antimetapackage
source package, and of individual non-free and contrib packages), with
the existing approach of audit and review from appropriately zealous
contributors.

Transition plan:

 1. Create the new metapackage, containing at least initially
nonfree-misc-nonfree and nonfree-misc-contrib.

 2. Change policy to require the new Recommends

 3. File RC bugs against:
 - any package in non-free with no antimetapackage Recommends
 - any package in contrib with noo antimetapackage Recommends
   and older Standards-Version

 4. Anyone who wants, as a user, to make a compromise, which is not
yet given a separate name, may propose this as a new
antimetapackage.  The antimetapackage maintainers will accede to
this request, and accept the appropriate patches, if the scope of
the proposed new antimetapackage seems clear.  Maintainers of the
affected packages should then expect patches to switch their
(applicable) antimetapackage Recommends to the new one.  The
antimetapackage source maintainers should probably help with
providing an MBF template for this.

(Packages in contrib which Depend on (o

Re: Non-free RFCs in stretch

[Adam Borowski]

On Tue, Mar 07, 2017 at 02:48:59PM +, Ian Jackson wrote:
> I have a suggestion for how this could be done.
> 
> We give each reason-why-a-package-might-be-nonfree-or-contrib
> a name in the package namespace.  I'm going to call these packages
> antimetapackages.
> 
> Each package in non-free or contrib must Recommend all the
> antimetapackages which apply.

Why Recommend rather than Depend?  The latter would allow a hard conflict
with everything with a specific kind of badness, which seems exactly like
the thing people here are looking for.

Thus, if I want for example to be free of AGPL (which for some reason is
allowed in main despite being neither Four Freedoms nor DFSG free), I ban
nonfree-agpl and there's no way it can sneak back in.

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!

Re: Non-free RFCs in stretch

[Ian Jackson]

Adam Borowski writes ("Re: Non-free RFCs in stretch"):
> On Tue, Mar 07, 2017 at 02:48:59PM +, Ian Jackson wrote:
> > I have a suggestion for how this could be done.
> > 
> > We give each reason-why-a-package-might-be-nonfree-or-contrib
> > a name in the package namespace.  I'm going to call these packages
> > antimetapackages.
> > 
> > Each package in non-free or contrib must Recommend all the
> > antimetapackages which apply.
> 
> Why Recommend rather than Depend?  The latter would allow a hard conflict
> with everything with a specific kind of badness, which seems exactly like
> the thing people here are looking for.

Did you see where I wrote:

  We use Recommends because these are all policy decisions which the
  user may wish to override on an individual basis.

The point being that it is for Debian to advise and inform users, but
ultimately the user should have the freedom to make their own
compromises.  So we should assist the user to implement their personal
policy.  But we mustn't _insist_ on the user following their own
policy as expressed, probably inaccurately, in our dependency system.

In practical terms, apt makes it very hard to maintain a system where
a Depends is violated.  Conversely it provides a good sticky door (in
the default configuration, at least) to avoid unintentional violation
of Recommends, but once a Recommends is violated it doesn't cause
further problems.

If the implementation in apt has too few configuration knobs to do the
right thing for all users (for example, users who want to run with
Recommends disabled by default), then I'm sure the apt authors would
accept patches.

In principle the same applies to Depends, but in the default
configuration the meaning of Recommends is closer to the desired
effect.

> Thus, if I want for example to be free of AGPL (which for some reason is
> allowed in main despite being neither Four Freedoms nor DFSG free), I ban
> nonfree-agpl and there's no way it can sneak back in.

I am uncomfortable with insisting that packages in main declare any
kind of negative thing like this.  Certainly if we have
antimetapackages referred to by packages in main, they shouldn't have
names like `nonfree-*'.  That would imply that Debian thinks the thing
is nonfree.

I would like to shelve this suggestion.  The concept of
antimetapackages can certainly be used this way from a technical point
of view, but I think the goal there is controversial.  Maintainers of
packages currently in main would probably resist the introduction of
antimetapackage tags.

Whereas the goal of enabling finer control over nonfree is, I think,
fairly uncontroversial.

So do you think we should proceed with that ?  After the use of
antimetapackges is established for contrib and non-free, and we have
gained some experience, you will of course be free to re-propose this.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Non-free RFCs in stretch

[Holger Levsen]

On Tue, Mar 07, 2017 at 04:40:15PM +, Ian Jackson wrote:
[...] 
> I would like to shelve this suggestion.  The concept of
> antimetapackages can certainly be used this way from a technical point
> of view, but I think the goal there is controversial.  Maintainers of
> packages currently in main would probably resist the introduction of
> antimetapackage tags.
> 
> Whereas the goal of enabling finer control over nonfree is, I think,
> fairly uncontroversial.

I'm not so sure whether this goal is uncontroversial, this is Debian… ;)

> So do you think we should proceed with that ?

Please not like this. while I *might* share the goal, I think this 
implementation is IMHO rather horrible. "antimetapackages" sounds unclear at
best and the whole concept is *way* too complicated.

plus, we have something complicated which can achieve the wanted effect today
already: apt pining.

I think Debian has better things to do than working on fine grained control
over non-free stuff. Obviously anybody is free to work on this, but I dont
think we should make our repositories, packages, policies and workflow s
much more complicated and harder to understand, for very little gain.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Non-free RFCs in stretch

[The Wanderer]

On 2017-03-07 at 11:40, Ian Jackson wrote:

> Adam Borowski writes ("Re: Non-free RFCs in stretch"):
> 
>> On Tue, Mar 07, 2017 at 02:48:59PM +, Ian Jackson wrote:
>> 
>>> I have a suggestion for how this could be done.
>>> 
>>> We give each reason-why-a-package-might-be-nonfree-or-contrib a
>>> name in the package namespace.  I'm going to call these packages 
>>> antimetapackages.
>>> 
>>> Each package in non-free or contrib must Recommend all the 
>>> antimetapackages which apply.
>> 
>> Why Recommend rather than Depend?  The latter would allow a hard
>> conflict with everything with a specific kind of badness, which
>> seems exactly like the thing people here are looking for.
> 
> Did you see where I wrote:
> 
>   We use Recommends because these are all policy decisions which the 
>   user may wish to override on an individual basis.
> 
> The point being that it is for Debian to advise and inform users,
> but ultimately the user should have the freedom to make their own 
> compromises.  So we should assist the user to implement their
> personal policy.  But we mustn't _insist_ on the user following their
> own policy as expressed, probably inaccurately, in our dependency
> system.
> 
> In practical terms, apt makes it very hard to maintain a system
> where a Depends is violated.  Conversely it provides a good sticky
> door (in the default configuration, at least) to avoid unintentional
> violation of Recommends, but once a Recommends is violated it doesn't
> cause further problems.

Can you provide an example of how, under your proposal, someone who
wants to - e.g. - forbid the installation of any nonfree-gfdl-invariant
packages would do so? I don't see any way to accomplish that based on
Recommends:, precisely because Recommends: can be overridden.

For "Depends: foo", I'd probably try to do it by pinning foo to priority
-1, or something along those lines - but such a pin would do nothing to
prevent packages which only Recommend foo.

I could see a possible way of doing this with Conflicts: or similar,
such that you just install the packages which the ones you want to
prohibit will conflict with - but trying to set up a suitable collection
of antimetapackages to be conflicted against seems like a recipe for
madness.

I hope I'm just missing something, because this looks like a very
interesting idea. With Recommends:, however, it looks like it would do
nothing more than potentially warn the user at install time that a
package which is about to be installed violates this particular freedom
condition - and that doesn't seem like enough of a benefit to be worth
the investment.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Non-free RFCs in stretch

[Adam Borowski]

On Tue, Mar 07, 2017 at 04:40:15PM +, Ian Jackson wrote:
> Adam Borowski writes ("Re: Non-free RFCs in stretch"):
> > On Tue, Mar 07, 2017 at 02:48:59PM +, Ian Jackson wrote:
> > > We give each reason-why-a-package-might-be-nonfree-or-contrib
> > > a name in the package namespace.  I'm going to call these packages
> > > antimetapackages.
> > > 
> > > Each package in non-free or contrib must Recommend all the
> > > antimetapackages which apply.
> > 
> > Why Recommend rather than Depend?  The latter would allow a hard conflict
> > with everything with a specific kind of badness, which seems exactly like
> > the thing people here are looking for.
> 
> Did you see where I wrote:
> 
>   We use Recommends because these are all policy decisions which the
>   user may wish to override on an individual basis.

The antimetapackage doesn't force anything on the user, its effect is only
"install this empty package to signal you're ok with this badness".
 
> In practical terms, apt makes it very hard to maintain a system where
> a Depends is violated.  Conversely it provides a good sticky door (in
> the default configuration, at least) to avoid unintentional violation
> of Recommends, but once a Recommends is violated it doesn't cause
> further problems.

Alas, currently Recommends are so out of whack that I tend to ignore them
rather than install around half of the time.  Thus, if you need to ignore a
Recommends for an unrelated reason, your wishes wrt allowing or not
something non-free would be accidentally disobeyed.

An empty metapackage with no (non-metapackage) depends of its own has no
effect on the system other than allowing potential dependers in.

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!

Re: Non-free RFCs in stretch

[Andrey Rahmatullin]

On Tue, Mar 07, 2017 at 04:53:34PM +, Holger Levsen wrote:
> I think Debian has better things to do than working on fine grained control
> over non-free stuff. Obviously anybody is free to work on this, but I dont
> think we should make our repositories, packages, policies and workflow s
> much more complicated and harder to understand, for very little gain.
Indeed, many (most?) Linux users would want to just enable non-free (for
their hardware stuff and maybe some other useful things) and don't bother
with details. They won't get any real problems because of that, after all.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Non-free RFCs in stretch

[Ian Jackson]

The Wanderer writes ("Re: Non-free RFCs in stretch"):
> Can you provide an example of how, under your proposal, someone who
> wants to - e.g. - forbid the installation of any nonfree-gfdl-invariant
> packages would do so? I don't see any way to accomplish that based on
> Recommends:, precisely because Recommends: can be overridden.

I had thought, when I posted earlier, that ...

> For "Depends: foo", I'd probably try to do it by pinning foo to priority
> -1, or something along those lines - but such a pin would do nothing to
> prevent packages which only Recommend foo.

... apt would still try to honour both the Recommends and the pin and
therefore reject attempts to install the unwanted package(s).
But it appears I was wrong :-/.

> I hope I'm just missing something, because this looks like a very
> interesting idea. With Recommends:, however, it looks like it would do
> nothing more than potentially warn the user at install time that a
> package which is about to be installed violates this particular freedom
> condition - and that doesn't seem like enough of a benefit to be worth
> the investment.

Yes.

Ian.

Re: Non-free RFCs in stretch

[Sean Whitton]

Dear Ian,

On Tue, Mar 07, 2017 at 02:48:59PM +, Ian Jackson wrote:
> I have a suggestion for how this could be done.
> 
> We give each reason-why-a-package-might-be-nonfree-or-contrib
> a name in the package namespace.  I'm going to call these packages
> antimetapackages.

It would be good if Debian was able to support these restrictions.

Could you explain why you want to do this with metapackages, rather than
extending the definition of an archive section so that non-free and
contrib may be more finely divided up?  The various implementation
problems that have been raised in this thread are all/mostly due to the
use of metapackages.

-- 
Sean Whitton


signature.asc
Description: PGP signature

"RoQA" RM bugs

[Sean Whitton]

Dear all,

Under current practices, must one be a member of the 'qa' UNIX group in
order to submit RM bugs for orphaned packages, using the "RoQA"
notation?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: "RoQA" RM bugs

[Mattia Rizzolo]

On Tue, Mar 07, 2017 at 03:05:42PM -0700, Sean Whitton wrote:
> Under current practices, must one be a member of the 'qa' UNIX group in
> order to submit RM bugs for orphaned packages, using the "RoQA"
> notation?

No.

For as long as RoQA go, everybody is QA.
(also, not being in the 'qa' unix group should not stop you from doing
"QA" :))

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: "RoQA" RM bugs

[Sean Whitton]

On Tue, Mar 07, 2017 at 11:08:33PM +0100, Mattia Rizzolo wrote:
> For as long as RoQA go, everybody is QA.

Thanks.

> (also, not being in the 'qa' unix group should not stop you from doing
> "QA" :))

Right, this part is clear from the conventions about QA uploads.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: "RoQA" RM bugs

[Michael Biebl]

Am 07.03.2017 um 23:11 schrieb Sean Whitton:
> On Tue, Mar 07, 2017 at 11:08:33PM +0100, Mattia Rizzolo wrote:
>> For as long as RoQA go, everybody is QA.
> 
> Thanks.

If I see a package which looks unmaintained, is possibly RC buggy and
doesn't look like worth keeping in Debian, I've filed RoAQ RM bugs in
the past myself. I CCed Maintainer/Uploaders asking them to speak up if
they disagree with the RM request (so far, for the RM bugs I've filed,
noone ever replied).

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: "RoQA" RM bugs

[Adam Borowski]

On Tue, Mar 07, 2017 at 11:08:33PM +0100, Mattia Rizzolo wrote:
> On Tue, Mar 07, 2017 at 03:05:42PM -0700, Sean Whitton wrote:
> > Under current practices, must one be a member of the 'qa' UNIX group in
> > order to submit RM bugs for orphaned packages, using the "RoQA"
> > notation?
> 
> No.
> 
> For as long as RoQA go, everybody is QA.

And it's worth stressing that in this case "everybody" means literally
"everybody".  Not just DDs and DMs.  Your grandma is.  Your cat is, if he
fancies writing a coherent bug report by walking on the keyboard.  I
wouldn't trust a RoQA by a dog, though, but that's why we have human
ftpmasters doing the actual removals.

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!

Bug#857099: ITP: golang-github-go-openapi-validate -- OpenAPI toolkit validation helpers

[Potter, Tim]

X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-go-openapi-validate
  Version : 0.0~git20160704.0.deaf2c9-1
  Upstream Author : OpenAPI Initiative golang toolkit
* URL : https://github.com/go-openapi/validate
* License : Apache-2.0
  Programming Lang: Go
  Description : OpenAPI toolkit validation helpers

The validate library is part of the OpenAPI Initiative and OpenAPI 
Specification, and consists
of various helper and utility functions used internally by other components of 
OpenAPI.

The OpenAPI Specification is a powerful definition format to describe RESTful 
APIs and
creates a RESTful interface for easily developing and consuming an API.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#857100: ITP: golang-github-go-openapi-runtime -- OpenAPI runtime interfaces

[Potter, Tim]

X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-go-openapi-runtime
  Version : 0.0~git20160704.0.11e322e-1
  Upstream Author : OpenAPI Initiative golang toolkit
* URL : https://github.com/go-openapi/runtime
* License : Apache-2.0
  Programming Lang: Go
  Description : OpenAPI runtime interfaces

The validate library is part of the OpenAPI Initiative and OpenAPI 
Specification, and consists
of classes and functions to be used in code generation when creating client- 
and server-side
implementations of REST interfaces.

The OpenAPI Specification is a powerful definition format to describe RESTful 
APIs and
creates a RESTful interface for easily developing and consuming an API.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#857101: ITP: golang-github-go-openapi-strfmt -- OpenAPI string formatting library

[Potter, Tim]

X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-go-openapi-strfmt
  Version : 0.0~git20160812.0.d65c7fd-1
  Upstream Author : OpenAPI Initiative golang toolkit
* URL : https://github.com/go-openapi/strfmt
* License : Apache-2.0
  Programming Lang: Go
  Description : OpenAPI string formatting library

Strfmt implements formatting and validation of various well-known string 
formats such as
IP and email addresses for use in other OpenAPI Specification libraries.

The OpenAPI Specification is a powerful definition format to describe RESTful 
APIs and
creates a RESTful interface for easily developing and consuming an API.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#857102: ITP: golang-github-go-openapi-loads -- OpenAPI Specification object model

[Potter, Tim]

X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-go-openapi-loads
  Version : 0.0~git20160704.0.18441df-1
  Upstream Author : OpenAPI Initiative golang toolkit
* URL : https://github.com/go-openapi/loads
* License : Apache-2.0
  Programming Lang: Go
  Description : OpenAPI Specification object model

This library implements the loading of OpenAPI specification documents from 
local or
remote locations.

The OpenAPI Specification is a powerful definition format to describe RESTful 
APIs and
creates a RESTful interface for easily developing and consuming an API.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#857103: ITP: golang-github-go-openapi-analysis -- OpenAPI Specification object model analyzer

[Potter, Tim]

X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-go-openapi-analysis
  Version : 0.0~git20160815.0.b44dc87-1
  Upstream Author : OpenAPI Initiative golang toolkit
* URL : https://github.com/go-openapi/analysis
* License : Apache-2.0
  Programming Lang: Go
  Description : OpenAPI Specification object model analyser

The OpenAPI analysis library implements analysts of an OpenAPI specification 
document
for easier reasoning about the content.

The OpenAPI Specification is a powerful definition format to describe RESTful 
APIs and
creates a RESTful interface for easily developing and consuming an API.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#857104: ITP: golang-github-go-openapi-errors -- Common error handling code for OpenAPI

[Potter, Tim]

X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-go-openapi-errors
  Version : 0.0~git20160704.0.d24ebc2-1
  Upstream Author : OpenAPI Initiative golang toolkit
* URL : https://github.com/go-openapi/errors
* License : Apache-2.0
  Programming Lang: Go
  Description : Common error handling code for OpenAPI

This library implements shared error handling code used throughout the various 
libraries
for the OpenAPI Specification.

The OpenAPI Specification is a powerful definition format to describe RESTful 
APIs and
creates a RESTful interface for easily developing and consuming an API.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: OCF.tw for Debian Trusted Organization

[陳昌倬]

On Mon, Mar 06, 2017 at 06:47:35PM +0100, Mehdi Dogguy wrote:
> I have gone through your page and here are my first remarks:
> - The bylaws are not in english and are not stored in a file (I see you use
>   a pad to share it). You may want to publish it on a webpage or a flat file
>   with a version or a date. Having it in english is not mandatory as some
>   countries enforce the use of local language for official documents, but
>   an english version will greatly help during the discussion.

ocf.tw said the pad needs permission to modify, and there is also a copy
in Ministry of the Interior, so maybe it can be treated as read-only.
As for version, ocf.tw will see if they can add version on top of the
document.

We also are working on translation.


> - Links to financial reports, annual meetings, past organized events are
>   important... but explaining the process is also needed. For example:
>   * How reimbursement are handled? In which currency?

The process likes any other company. It uses invoice or receipt to
reimbursement. The currency is TWD.

>   * What is the structure of ocf.tw? And how decisions are taken?

There are five non-paid board members, one of them is chair, and several
full-time / part-time administration staffs works on different projects.
It is a 3-tier flat structure with board member, project lead, and team
member.

ocf.tw operates in project-based. Board members find a project they are
interested in and help it. A project who needs ocf.tw help will be
managed by proposer. After approved by board meeting, ocf.tw will
provide administration help to manage assets (domain, fund, etc).
Sometimes, one board member will help to coordinate the resources.

All major decisions are discuss at the monthly meeting. Minor issues are
discussed online and will do it if no objection. It is similar to open
source community.


>   * Where and when reports are published?

The yearly reports are published in http://ocf.tw/, the following are
reports for 2015, and 2016, in Traditional Chinese:

* http://ocf.tw/report/2015/
* http://beta.ocf.tw/p/2016/

The donation report is in the following link. It is bi-monthly report
and is published in the next month (ex. Nov ~ Dec, 2016 report is
published in Jan, 2017).

* http://blog.ocf.tw/search/label/%E6%8D%90%E6%AC%BE%E5%BE%B5%E4%BF%A1

ps. As a donator, I received email for ocf 2016 report in Feb 24, 2017.

> - You can find at [2] current list of Debian Trusted Organizations. Each one
>   them has gone through the process and you can find the criteria link which
>   can be useful for inspiration or to better understand the nature of the
>   discussion that will occur.
> 
> [2] https://wiki.debian.org/Teams/Auditor/Organizations
> 
> If you need more help, please let me know.
> 
> Regards,
> 
> -- 
> Mehdi

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Re: OCF.tw for Debian Trusted Organization

[陳昌倬]

On Wed, Mar 08, 2017 at 10:33:50AM +0800, ChangZhuo Chen (陳昌倬) wrote:
> >   * Where and when reports are published?
> 
> The yearly reports are published in http://ocf.tw/, the following are
> reports for 2015, and 2016, in Traditional Chinese:
> 
> * http://ocf.tw/report/2015/
> * http://beta.ocf.tw/p/2016/
> 
> The donation report is in the following link. It is bi-monthly report
> and is published in the next month (ex. Nov ~ Dec, 2016 report is
> published in Jan, 2017).
> 
> * http://blog.ocf.tw/search/label/%E6%8D%90%E6%AC%BE%E5%BE%B5%E4%BF%A1
> 
> ps. As a donator, I received email for ocf 2016 report in Feb 24, 2017.

This email is for yearly report, not donation report.


-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Re: Non-free RFCs in stretch

[Tollef Fog Heen]

]] Sean Whitton 

> Could you explain why you want to do this with metapackages, rather than
> extending the definition of an archive section so that non-free and
> contrib may be more finely divided up?  The various implementation
> problems that have been raised in this thread are all/mostly due to the
> use of metapackages.

A package can only be in a single section.

I'd look at tagging the packages with debtags and doing a debtags search
on installed packages instead of faffing with metapackages.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Non-free RFCs in stretch

[Paul Wise]

On Wed, Mar 8, 2017 at 12:16 PM, Tollef Fog Heen wrote:

> A package can only be in a single section.

That wouldn't prevent adding subsetted Packages files:

deb http://ftp.debian.org/debian/ unstable main non-free/firmware non-free/docs

Types: deb
URIs: http://ftp.debian.org/debian/
Suites: unstable
Components: main non-free/firmware non-free/docs

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#857113: ITP: httplab -- An interactive web server

[Jack Henschel]

Package: wnpp
Severity: wishlist
Owner: Jack Henschel 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

  Package name: httplab
  Version : 0.1.0
  Upstream Author : Gustavo Chaín
  URL : https://github.com/gchaincl/httplab
  License : Expat
  Programming Lang: Go
  Description : An interactive web server

 HTTPLab lets you inspect HTTP requests and forge responses
 via an intuitive console user interface.
 .
 asciicast: https://asciinema.org/a/c613qjyikodunp72ox54irn2j

Packaging will be at 
https://anonscm.debian.org/cgit/pkg-go/packages/httplab.git/



signature.asc
Description: PGP signature