On Fri, Nov 4, 2016 at 2:47 AM, Steve McIntyre wrote:
> * it will be a different experience compared to what people will get
>when installing Debian normally, using d-i / debootstrap.
That should be fixed in d-i IMO.
> To solve the issue and provide security updates by default, I'm
> propos
Package: wnpp
Severity: wishlist
Owner: Free Ekanayaka
* Package name: constantly
Version : 15.1.0
Upstream Author : Amber Brown
* URL : https://github.com/twisted/constantly
* License : MIT
Programming Lang: Python
Description : Symbolic constants in
On Tue, 2016-11-01 at 22:54 +0200, Adrian Bunk wrote:
> I do not see any reason for waiting instead of sending the binNMU
> request right now.
I didn't see any movement on the dpkg front so I went ahead and did so:
#843139.
Thanks,
Ian.
Hello,
On Thu, 03 Nov 2016, Ian Jackson wrote:
> % Reusing this is tempting because an epoch separator can never
> follow `.', so any `%' after any `.' would unambiguously mean
> `escape for dot rather than colon'. But in principle `.' can
> occur at the start of the version,
On Fri, Nov 4, 2016 at 1:43 AM, Ian Jackson
wrote:
> I'm concerned that we are setting up a situation where:
>
> * A maintainer (or interested party) for a package which peripherally
>uses openssl;
> * Gets an RC bug report;
> * Is threatened with autoremoval;
> * Does not really know ho
Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> We have defined simple "readable" mappings for the common cases that
> we encounter frequently. Now if we need mappings for silly things
> that we don't encounter, I would suggest to use something easily
> reversible and extendable.
My pr
On 04/11/16 10:53, Pau Garcia i Quiles wrote:
> As I requested a few days ago, please delay making OpenSSL 1.1.0 the
> default for 1 year (and even then, we should be checking the case
> where something links directly to one version of OpenSSL, and also
> links to something that dlopen's some othe
On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
> Hey folks,
>
> I'm in Seattle for the Debian Cloud sprint and it's going really
> well. I'll post a report in a few days summarising what we've
> done. But, in the meantime, there's something that has come up which I
> think merits
Package: wnpp
Severity: wishlist
Owner: Dominik George
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: gpxpy
Version : 1.1.1
Upstream Author : Tomo Krajina
* URL : http://www.trackprofiler.com/gpxpy/index.html
* License : Apache
Programming L
Guido Günther, 2016-11-04 12:26:51 +0100 :
[...]
> Please do. We should also enable needsrestart, whatmaps, checkrestart
> or similar to restart affected services after these upgrades otherwise
> the e.g. openssl update might go without effect until openssh, bind,
> get restarted manually or reb
Roland Mas, on Fri 04 Nov 2016 13:29:02 +0100, wrote:
> Guido Günther, 2016-11-04 12:26:51 +0100 :
> > Please do. We should also enable needsrestart, whatmaps, checkrestart
> > or similar to restart affected services after these upgrades otherwise
> > the e.g. openssl update might go without effect
Hi there!,
On Fri, 04 Nov 2016 12:26:51 +0100, Guido Günther wrote:
> On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
> > To solve the issue and provide security updates by default, I'm
> > proposing that we should switch to installing unattended-upgrades by
> > default (and enabli
2016-11-04 13:29 GMT+01:00 Roland Mas :
> Tangentially related: is there something similar for kernels? My
> monitoring setup currently compares the age of the most recent file in
> /boot with the uptime, but I feel there must be something more proper
> somewhere.
Unattended-Upgrades can also han
Quoting Guido Günther (2016-11-04 12:26:51)
> We should also enable needsrestart, whatmaps, checkrestart or similar
> to restart affected services after these upgrades otherwise the e.g.
> openssl update might go without effect until openssh, bind,
> get restarted manually or rebooted.
needres
On Fri, Nov 04, 2016 at 02:13:35PM +0100, Luca Capello wrote:
> I still think that a non-manual upgrade (i.e. an upgrade which has not
> been checked by a manual process, which means that a scripted upgrade is
> not part of it) should not be a default on any OS, but it seems I am the
> only one thi
On 14:13 Fri 04 Nov , Luca Capello wrote:
> I still think that a non-manual upgrade (i.e. an upgrade which has not
> been checked by a manual process, which means that a scripted upgrade is
> not part of it) should not be a default on any OS, but it seems I am the
> only one thinking like this.
On Fri, 04 Nov 2016, Ian Jackson wrote:
> Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> > We have defined simple "readable" mappings for the common cases that
> > we encounter frequently. Now if we need mappings for silly things
> > that we don't encounter, I would suggest to use some
Raphael Hertzog writes ("Re: DEP14 policy for two dots"):
> On Fri, 04 Nov 2016, Ian Jackson wrote:
> > My proposal is reversible. It does not need to be extensible.
>
> So what about "..."? Would it give ".#.#."?
Yes. I said (fixing my bug):
> Insert "#":
>- between each pair of adjacen
Steve McIntyre writes:
> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too) *unless* something else in the
> installation is already expected to deal with security updates.
Sounds l
On Fri, Nov 04, 2016 at 03:53:55PM +0200, Apollon Oikonomopoulos wrote:
> On 14:13 Fri 04 Nov , Luca Capello wrote:
> > I still think that a non-manual upgrade (i.e. an upgrade which has not
> > been checked by a manual process, which means that a scripted upgrade is
> > not part of it) should
On 16:07 Fri 04 Nov , Evgeni Golov wrote:
> On Fri, Nov 04, 2016 at 03:53:55PM +0200, Apollon Oikonomopoulos wrote:
> > While enabling unattended-upgrades by default is definitely a step
> > towards better security, it would be great if we could also provide
> > users/admins with an easy opt-ou
Hi!
* Steve McIntyre [2016-11-03 19:47:28 CET]:
> One of the topics that we've been talking about yesterday is automatic
> software upgrades of cloud images. Some of the cloud platform
> providers really want this so that unsophisticated / inexperienced
> users of Debian images on their plat
Package: wnpp
Severity: wishlist
Owner: Christoph Ender
* Package name: remglk
Version : 0.2.3
Upstream Author : Andrew Plotkin
* URL : http://eblong.com/zarf/glk/remglk/docs.html
* License : MIT
Programming Lang: C
Description : Remote-procedure-call
On Fri, Nov 4, 2016 at 9:13 AM, Luca Capello wrote:
>
> I still think that a non-manual upgrade (i.e. an upgrade which has not
> been checked by a manual process, which means that a scripted upgrade is
> not part of it) should not be a default on any OS, but it seems I am the
> only one thinking l
Package: wnpp
Owner: Ole Streicher
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org,debian-as...@lists.debian.org
* Package name: aravis
Version : 0.5
Upstream Author : Emmanuel Pacaud
* URL : https://github.com/AravisProject/aravis
* License : L
Package: wnpp
Severity: wishlist
Owner: Shanavas M
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-ignore-by-default
Version : 1.0.1
Upstream Author : Mark Wubben (https://novemberborn.net/)
* URL :
https://github.com/novemberborn/ignore-by-default#rea
Package: wnpp
Owner: Chiara Marmo
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org,debian-as...@lists.debian.org
* Package name: freeture
Version : 1.1
Upstream Author : Yoan Audureau
* URL : https://github.com/fripon/freeture
* License : GPL-3.0
Package: wnpp
Severity: wishlist
Owner: Filippo Giunchedi
* Package name: prometheus-blackbox-exporter
Version : 0.2.0+git20160930.6.8cf9605-1
Upstream Author : Prometheus Authors
* URL : https://github.com/prometheus/blackbox_exporter
* License : Apache-2.0
Package: wnpp
Severity: wishlist
Owner: Lev Lamberov
* Package name: elpa-ido-vertical-mode
Version : 0.1.6
Upstream Author : Steven Degutis
* URL : https://github.com/creichert/ido-vertical-mode.el
* License : GPL-3+
Programming Lang: Emacs Lisp
Descripti
X-Debbugs-Cc: debian-devel@lists.debian.org
Control: owner -1 !
Control: retitle -1 ITA: syslinux -- collection of bootloaders (DOS FAT and
NTFS bootloader)
On Mon, 16 Nov 2015 08:29:30 + Mattia Rizzolo wrote:
> Some information about this package:
>
> Homepage: http://www.syslinux.org/
> P
Hi,
in the Colis project (which aims at analyzing maintainer scripts) we
found 39 maintainer scripts in stable which do not start on #!. The
list is attached. Policy 6.1 says about maintainer scripts:
if they are scripts (which is recommended), they must start with the
usual #! convention.
A
On Fri, Nov 04, 2016 at 04:15:58PM +0100, Rhonda D'Vine wrote:
> In theory I'm all for it, but there definitely should be some more fine
> tuning for that. Please don't auto-restart varnish by needrestart, it
> puts a lot of load on the backend which might be a very bad idea. And
> the downtime
On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
>...
> * it will be a different experience compared to what people will get
>when installing Debian normally, using d-i / debootstrap. Most
>(all?) of our desktop environments already have some automatic
>notification of a
On Fri, Nov 04, 2016 at 09:22:02PM +0100, Ralf Treinen wrote:
> Hi,
Hi Ralf,
> in the Colis project (which aims at analyzing maintainer scripts) we
> found 39 maintainer scripts in stable which do not start on #!. The
> list is attached. Policy 6.1 says about maintainer scripts:
>
> if they ar
On 2016-11-04 21:22 +0100, Ralf Treinen wrote:
> Hi,
>
> in the Colis project (which aims at analyzing maintainer scripts) we
> found 39 maintainer scripts in stable which do not start on #!. The
> list is attached. Policy 6.1 says about maintainer scripts:
>
> if they are scripts (which is reco
On November 4, 2016 5:01:31 PM EDT, Adrian Bunk wrote:
>On Fri, Nov 04, 2016 at 09:22:02PM +0100, Ralf Treinen wrote:
>> Hi,
>
>Hi Ralf,
>
>> in the Colis project (which aims at analyzing maintainer scripts) we
>> found 39 maintainer scripts in stable which do not start on #!. The
>> list is att
On Fri, Nov 04, 2016 at 11:01:31PM +0200, Adrian Bunk wrote:
> On Fri, Nov 04, 2016 at 09:22:02PM +0100, Ralf Treinen wrote:
> > Hi,
>
> Hi Ralf,
>
> > in the Colis project (which aims at analyzing maintainer scripts) we
> > found 39 maintainer scripts in stable which do not start on #!. The
> >
On Fri, Nov 04, 2016 at 05:05:33PM -0400, Scott Kitterman wrote:
>
>
> On November 4, 2016 5:01:31 PM EDT, Adrian Bunk wrote:
> >On Fri, Nov 04, 2016 at 09:22:02PM +0100, Ralf Treinen wrote:
> >> Hi,
> >
> >Hi Ralf,
> >
> >> in the Colis project (which aims at analyzing maintainer scripts) we
>
On Fri, Nov 04, 2016 at 10:21:13PM +0100, Ralf Treinen wrote:
> On Fri, Nov 04, 2016 at 11:01:31PM +0200, Adrian Bunk wrote:
> > On Fri, Nov 04, 2016 at 09:22:02PM +0100, Ralf Treinen wrote:
> > > Hi,
> >
> > Hi Ralf,
> >
> > > in the Colis project (which aims at analyzing maintainer scripts) we
On Thu, Nov 03, 2016 at 10:49:30AM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> On jueves, 3 de noviembre de 2016 12:34:23 P. M. ART Tino Mettler wrote:
> > On Wed, Nov 02, 2016 at 14:02:52 -0300, Lisandro Damián Nicanor Pérez Meyer
> > wrote:
> >
> > [...]
> >
> > > Today we the Qt/KDE t
Ralf Treinen writes:
> in the Colis project (which aims at analyzing maintainer scripts) we
> found 39 maintainer scripts in stable which do not start on #!. The
> list is attached. Policy 6.1 says about maintainer scripts:
> if they are scripts (which is recommended), they must start with the
On 2016-11-04 15:03 -0700, Russ Allbery wrote:
> Ralf Treinen writes:
>
>> in the Colis project (which aims at analyzing maintainer scripts) we
>> found 39 maintainer scripts in stable which do not start on #!. The
>> list is attached. Policy 6.1 says about maintainer scripts:
>
>> if they are
On Fri, Nov 04, 2016 at 10:51:15PM +0200, Adrian Bunk wrote:
> Should Debian also default to automatically reboot?
>
> If the answer is "no", then nothing is a solution that does not also
> solve how to notify the user when a new security update of the kernel
> was automatically installed on his
On Fri, Nov 04, 2016 at 10:27:00PM +, Holger Levsen wrote:
> On Fri, Nov 04, 2016 at 10:51:15PM +0200, Adrian Bunk wrote:
> > Should Debian also default to automatically reboot?
> >
> > If the answer is "no", then nothing is a solution that does not also
> > solve how to notify the user when
Rhonda D'Vine wrote:
> * Steve McIntyre [2016-11-03 19:47:28 CET]:
> > One of the topics that we've been talking about yesterday is automatic
> > software upgrades of cloud images. Some of the cloud platform
> > providers really want this so that unsophisticated / inexperienced
> > users of Debian
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Mini Debian Conference Japan 2016
Call for proposals deadline is the end of next weekend Nov. 13 (Sunday).
Please submit your talk proposal, which main topic is about Debian. It is also
fine if anything related to the software running on Debian, o
Forwarding to debian-devel...
-- Forwarded message --
From: Paul Hardy
Date: Fri, Nov 4, 2016 at 4:38 PM
Subject: Bug#843207: ITP: man2texi -- man page to texinfo file converter
To: sub...@bugs.debian.org
Cc: Matt Kraai , "Nelson H. F. Beebe"
, Andreas Metzler
Package: wnpp
Se
Hi Ralf,
On Fri, Nov 04, 2016 at 09:22:02PM +0100, Ralf Treinen wrote:
> in the Colis project (which aims at analyzing maintainer scripts) we
> found 39 maintainer scripts in stable which do not start on #!. The
> list is attached. Policy 6.1 says about maintainer scripts:
>
> if they are scrip
On Fri, Nov 04, 2016 at 03:03:09PM -0700, Russ Allbery wrote:
> (We unfortunately don't have good language for this in Policy. Right now,
> the must/should distinction conflates two things: severity, and certainty.
> We used to have the same problem in Lintian and explicitly split severity
> and c
Holger Levsen writes:
> On Fri, Nov 04, 2016 at 03:03:09PM -0700, Russ Allbery wrote:
>> (We unfortunately don't have good language for this in Policy. Right
>> now, the must/should distinction conflates two things: severity, and
>> certainty. We used to have the same problem in Lintian and exp
On Sat, Nov 5, 2016 at 1:13 AM, Chiara Marmo wrote:
> Description : a vision library for genicam based cameras
It would be great if you could add some metadata about which hardware
is supported. By doing so, you will enable users to discover your
package when they plug in a new device supp
51 matches
Mail list logo
