On Wed, 06 Jun 2018 at 10:28:53 +0530, Pirate Praveen wrote:
> ruby-state-machines and ruby-state-machines-activemodel should go
> together and even when autopkgtest for the version is unstable passed,
> instead of reducing the age, it is considered a regression because
> autopkgtest for the versio
Package: wnpp
Severity: wishlist
Owner: Phil Morrell
* Package name: firefox-syncserver
Version : 1.8.0
Upstream Author : Mozilla Corporation
* URL : https://github.com/mozilla-services/syncserver
* License : MPL-2.0
Programming Lang: Python 2
Description
On Thursday 03 May 2018 02:39 AM, Paul Gevers wrote:
> It is the intention that in the (far) future regressions will become
> blocking for migration, but until then the added age will probably be
> raised over time as a semi-block.
>
> There is one important note to make here on how to go about re
On June 4, 2018 6:27:13 PM GMT+05:30, Bastian Blank wrote:
> However, we actually pull in some external
>binaries, for node, yarn and go.
Newer versions of node and go are available via stretch-backports.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Tue, 2018-06-05 at 15:44 +0100, Ian Jackson wrote:
> Packages are great for software which you can just install and use
> without much fuss. That is often true for mature software. But for
> services which are less mature, and more complex, and which have more
> tentacles, the admin is likely
On 2018-06-05 23:15, Simon McVittie wrote:
> NetworkManager supports PPPOE (e.g. ADSL), and cellular modems (3G, etc.)
> via ModemManager. It doesn't support the analogue dial-up modems that
> were popular 10-20 years ago. I don't think the major NM alternatives
> (wicd, ConnMan etc.) support those
On Tue, 05 Jun 2018 at 21:46:37 +0200, Sebastian Andrzej Siewior wrote:
> wvstreams has a RC bug due to the openssl transition. There seems not to
> be any upstream activity, the last commit on github was from 2011. It
> has one reverse dependency which is wvdial.
> wvdial itself saw its last uploa
Package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: node-istanbul
Version : 0.4.5
Upstream Author : Krishnan Anantheswaran
* URL : https://github.com/gotwarlost/istanbul#readme
* License : BSD-3-C
Package: iso-codes
Severity: wishlist
Version: 3.75-1
X-Debbugs-CC: debian-devel@lists.debian.org
I've been thinking about technical solutions to help the country list
bug[1] and the following possibility came to mind:
- define a virtual package with a name like "country-codes"
- src:iso-codes
Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta
* Package name: rake-ant
Version : 1.0.4
Upstream Author : Charles Oliver Nutter
* URL : https://github.com/jruby/rake-ant
* License : EPL-2.0
Programming Lang: Ruby
Description : Ant tasks and in
I'm forwarding this to d-devel@ to reach a broader audience since my
initial email received no feedback.
Hi,
wvstreams has a RC bug due to the openssl transition. There seems not to
be any upstream activity, the last commit on github was from 2011. It
has one reverse dependency which is wvdial.
w
On Tue, Jun 05, 2018 at 10:24:20AM -0700, Russ Allbery wrote:
> My personal experience is that there is an interesting cycle of scale
> here.
[...]
This entire email is roughly what I was trying to say, only (as usual
for Russ) much more clearly put. Thanks.
> More broadly, one useful way to thi
Chris Lamb wrote:
> Given that we forgot to mention this issue at least once, I would like
> to create a bug in the BTS for it.
>
> This would have the advantages of being a good place to store the
> latest status as well as being a convenient way to link others to it.
I went ahead and filed th
Colin Watson writes:
> My experience has been that if I'm working on a complex service then I
> want as little friction as possible for the fast-moving stuff that I'm
> working on directly and so often end up deploying that straight from git
> or whatever, but that I prefer to use packages for ev
Bastian Blank writes ("Re: concerns about Salsa"):
> On Mon, Jun 04, 2018 at 12:54:32PM +0100, Ian Jackson wrote:
> > Salsa is hardly the first Debian production service to not be running
> > the packaged version of its primary application, and it won't be the
> > last. ftp.debian.org isn't runnin
Package: wnpp
Owner: Lev Lamberov
Severity: wishlist
* Package name: gitlab-ci-mode-el
Version : 20180306.1
Upstream Author : Joe Wreschnig
* URL or Web page : https://gitlab.com/joewreschnig/gitlab-ci-mode
* License : GPL-3+
Programming Lang: Emacs Lisp
Description
Pierre-Elliott Bécue writes ("Re: concerns about Salsa"):
> Le lundi 04 juin 2018 à 12:54:32+0100, Ian Jackson a écrit :
> > In practice, I have found that it is much easier to deploy a
> > production service directly from its git tree. This makes it much
> > easier to make changes.
>
> I've alwa
Nicolas Braud-Santoni writes ("Re: Bug#899299: libu2f-udev: Post-inst script
should make udev reload rules"):
> On Sun, Jun 03, 2018 at 06:20:03PM +0100, James Cowgill wrote:
> > Running a command from another package in postinst only requires a
> > normal Depends - not a Pre-Depends.
>
> OK. I
Colin Watson writes ("Re: concerns about Salsa"):
> On Tue, Jun 05, 2018 at 02:37:16PM +0200, Pierre-Elliott Bécue wrote:
> > I wonder then, if a lot of people prefer deploy a service from
> > upstream's git repo/cookbooks, what is the purpose of packaging?
> > Who would benefit from it and who sho
Wookey writes ("Re: concerns about Salsa"):
> Buildds don't run the packaged version either, and this contributes to
> it being much harder than it should be to set up local buildd
> infrastructure. There are good reasons for this from the admin's POV,
> but the side-effects are signifcant and I'd
Quoting Pierre-Elliott Bécue :
I've always found otherwise, ie that packaged stuff makes the administrator
of a service spare a lot of time.
Same here, but it's a matter of taste and requirement diversity.
I wonder then, if a lot of people prefer deploy a service from upstream's
git repo/cook
On Tue, Jun 5, 2018 at 2:37 PM, Pierre-Elliott Bécue wrote:
> Le lundi 04 juin 2018 à 12:54:32+0100, Ian Jackson a écrit :
>>
>> In practice, I have found that it is much easier to deploy a
>> production service directly from its git tree. This makes it much
>> easier to make changes.
>
> I've alw
On Tue, Jun 05, 2018 at 02:37:16PM +0200, Pierre-Elliott Bécue wrote:
> Le lundi 04 juin 2018 à 12:54:32+0100, Ian Jackson a écrit :
> > In practice, I have found that it is much easier to deploy a
> > production service directly from its git tree. This makes it much
> > easier to make changes.
>
Le mardi 05 juin 2018 à 17:48:47+0500, Andrey Rahmatullin a écrit :
> On Tue, Jun 05, 2018 at 02:37:16PM +0200, Pierre-Elliott Bécue wrote:
> > I wonder then, if a lot of people prefer deploy a service from upstream's
> > git repo/cookbooks, what is the purpose of packaging? Who would benefit from
On Tue, Jun 05, 2018 at 02:37:16PM +0200, Pierre-Elliott Bécue wrote:
> I wonder then, if a lot of people prefer deploy a service from upstream's
> git repo/cookbooks, what is the purpose of packaging? Who would benefit from
> it and who should use package-distros?
Yes, it's a more and more importa
Le lundi 04 juin 2018 à 12:54:32+0100, Ian Jackson a écrit :
> > Aren't we sending a wrong message that packaging is not important?
>
> In practice, I have found that it is much easier to deploy a
> production service directly from its git tree. This makes it much
> easier to make changes.
I've
On 2018-06-05 00:12, Wookey wrote:
On 2018-06-04 21:52 +, Clint Adams wrote:
On Mon, Jun 04, 2018 at 12:54:32PM +0100, Ian Jackson wrote:
> Salsa is hardly the first Debian production service to not be running
> the packaged version of its primary application, and it won't be the
> last. ft
On Tuesday, 5 June 2018 6:08:50 PM AEST Ansgar Burchardt wrote:
> Though I admit golang is a crappy language to support given one has to
> rebuild everything all the time there is a security update. Just
> imagine libc (or worse: linux) was written in Go and there was a
> security update: just reb
Dmitry Smirnov writes:
> On Tuesday, 5 June 2018 5:11:31 PM AEST Ansgar Burchardt wrote:
>> rkt is neither in testing nor stable...
>
> Unfortunately... However it is a static Golang binary with minimum external
> run-time dependencies which makes it possible to reasonably safely install
> rkt on
On Tuesday, 5 June 2018 5:11:31 PM AEST Ansgar Burchardt wrote:
> rkt is neither in testing nor stable...
Unfortunately... However it is a static Golang binary with minimum external
run-time dependencies which makes it possible to reasonably safely install
rkt on Stretch straight from "unstable"
Dmitry Smirnov writes:
> Do you think there will be a potential to move services to containers,
> probably on "rkt" runtime[*] ?
rkt is neither in testing nor stable...
> [*]: Because Docker sucks...
Does rkt then suck more because it depends on docker stuff (at least in
Debian)? *scnr*
Ansgar
31 matches
Mail list logo
