Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu
* Package name: golang-github-grokify-html-strip-tags-go
Version : 0.0~git20180907.e9e4496-1
Upstream Author : John Wang
* URL : https://github.com/grokify/html-strip-tags-go
* License : BSD-3-clause
P
Package: wnpp
Owner: Nick Morrott
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org
* Package name: python-mbed-host-tests
Version : 1.4.4
Upstream Author : Przemyslaw Wirkus
* URL : https://github.com/ARMmbed/htrun
* Licen
On Wed, 2018-12-26 at 12:09 +, Colin Watson wrote:
> Unit tests can normally use some kind of temporary test harness
> instead of the full-blown init script, and that's usually the best
> first line of defence since it's typically simpler and faster.
>
> Of course it's also worth testing the i
On 12/25/18 3:46 PM, Dominik George wrote:
[...]
>
> Name of the new repository
> ==
>
> In the past, the name “volatile” was used for a similar repository, but
> with a different scope (limited to data packages for things like virus
> scanners). I will thus use the work
Hi,
> How to handle upgrades from stable to stable+1. Packages from backports
> upgrade with no issues as stable+1 contains the same packages already
> compiled for the stable+1.
As long as the package is in -volatile, it is not in stable+1, and
upgrades are ensured by the volatile maintainer. If
Hello,
On Mon 24 Dec 2018 at 05:37pm -0300, Felipe Sateler wrote:
> I (not speaking for the whole team), have no objection to this patch.
> However, it was pointed out to me that virtual packages require policy
> updates[1], first starting as a debian-devel discussion. So I'm starting
> this now
> For backports the general supportability assumption is that you provide a
> sane upgrade path from stable to the backports and from the backport to the
> next stable (optimally the same package). Once you take the presence of the
> stable package out of the mix, it becomes weird. How long do you
On 26/12/2018 19:31, Dominik George wrote:
- The package must not be in testing, and care must be taken for the
package not to migrate to testing.
So what would a user of testing do? Will there be a $codename-volatile[1]
suite for testing users? Or would they directly install unstable wi
> - Should the package begin to migrate to testing again, it must
>be moved to stable-backports.
>
> - Using the same ~bpo version namespace
Both of these poitns are there to *not* change anything about backports.
If a package stops qualifying for -volatile, and starts qualifying for
-backp
Dominik George wrote:
> Jonathan Nieder wrote:
>> 2. I am happy with the current charter of backports and I think it's
>> possible to move forward with fastpaced without having to change
>> that charter.
>
> Yep. That's exactly why the proposal changes nothing about -backports. I
> am sti
> > - The package must not be in testing, and care must be taken for the
> > package not to migrate to testing.
> So what would a user of testing do? Will there be a $codename-volatile[1]
> suite for testing users? Or would they directly install unstable with no
> other pre-release staging gr
Hi,
> 2. I am happy with the current charter of backports and I think it's
> possible to move forward with fastpaced without having to change
> that charter.
Yep. That's exactly why the proposal changes nothing about -backports. I
am still confused why Alex and you keep insisting that an
On 25/12/2018 21:46, Dominik George wrote:
Requirements for a package to go into stable-volatile
=
The new volatile proposal is not intended to ease life for package
maintainers who want to bypass the migration and QA requirements of the
regula
On Wed, 26 Dec 2018, Dominik George wrote:
> > >If there are other issues to solve than the lifespan of the package
> > >version, they must be solved in another way.
> >
> > I agree with you, it is the best outcome. But when people with power
> > (-backports ftp masters) are not willing to consid
Hi,
Pirate Praveen wrote:
> I agree with you, it is the best outcome. But when people with power
> (-backports ftp masters) are not willing to consider it, we have to
> go with plan B, which is less than ideal, but can move things
> forward.
Just to avoid this being thought of as an idiosyncrasy
On Wed, 26 Dec 2018, Pirate Praveen wrote:
>
>
> On 2018, ഡിസംബർ 26 10:15:35 PM IST, Dominik George
> wrote:
> >No. The dpendencies of gitlab not being accepted into backports right
> >now is an entirely different issue. I am repeating myself: This
> >proposal
> >is not intended to ease the li
> >If there are other issues to solve than the lifespan of the package
> >version, they must be solved in another way.
>
> I agree with you, it is the best outcome. But when people with power
> (-backports ftp masters) are not willing to consider it, we have to go
> with plan B, which is less than
On 2018, ഡിസംബർ 26 10:15:35 PM IST, Dominik George
wrote:
>No. The dpendencies of gitlab not being accepted into backports right
>now is an entirely different issue. I am repeating myself: This
>proposal
>is not intended to ease the life of maintainers whose packages qulify
>for -backports. Th
On Wed, 26 Dec 2018, Dominik George wrote:
> > I don't want backports to contain things are are not suited for a
> > release.
>
> That's why we are doing all this. It is NOT about anything to backports.
> It is about adding something new that uses the same RULES as backports,
> with a slight dive
> I don't want backports to contain things are are not suited for a
> release.
That's why we are doing all this. It is NOT about anything to backports.
It is about adding something new that uses the same RULES as backports,
with a slight diversion, and thus can also make use of infrastructure
alre
On Wed, 26 Dec 2018, Dominik George wrote:
> Hi,
>
> On Wed, Dec 26, 2018 at 03:05:55PM +0100, gregor herrmann wrote:
> > (Can we keep this on one mailing list, please? /me restricts this to
> > -devel)
>
> No. This has the potential of keeping people who are directly impacted
> by this proposal
Package: wnpp
Severity: wishlist
* Package name: postfix-mta-sts-resolver
Version : 0.2.4
* URL : https://github.com/Snawoot/postfix-mta-sts-resolver
* License : MIT
Programming Lang: python
Description : Daemon which provides TLS client policy for
Hi,
On Wed, Dec 26, 2018 at 03:05:55PM +0100, gregor herrmann wrote:
> (Can we keep this on one mailing list, please? /me restricts this to
> -devel)
No. This has the potential of keeping people who are directly impacted
by this proposal out of the loop.
> And besides that, I think the more univ
On Wed, 26 Dec 2018, Pirate Praveen wrote:
>
>
> On 2018, ഡിസംബർ 26 2:16:07 AM IST, Dominik George
> wrote:
> >Heisann, alle sammen,
> >
> >as announced in the recent thread about maintaining, I hereby propose a
> >repository that allows making “backports” of packages available to
> >users
> >
On Wed, Dec 26, 2018 at 02:35:19PM +0100, Dominik George wrote:
> >volatile is a very bad name for this because we've used it already for
> >something else.
> Well, I consider it more or less the same basic idea. The old and new ideas
> have more in common than not, with the only difference being
[As requested, keeping it to -devel only]
On 12/26/18 7:35 PM, Antonio Terceiro wrote:
> On Wed, Dec 26, 2018 at 01:04:44PM +0530, Pirate Praveen wrote:
>> If it has to be completely separate from -backports, it means some packages
>> will need to be maintained twice, even when they meet the crit
On 2018-12-26 15:05, gregor herrmann wrote:
> (Can we keep this on one mailing list, please? /me restricts this to
> -devel)
Agreed.
> And besides that, I think the more universal answer is
> bikesheds/PPAs/you-name-it instead of yet-another-suite.
IMHO, this is not the same. Both "volatile/fast
On Wed, 26 Dec 2018 13:07:07 +, Holger Levsen wrote:
(Can we keep this on one mailing list, please? /me restricts this to
-devel)
> On Wed, Dec 26, 2018 at 12:07:42AM +0100, Dominik George wrote:
> > I actually think volatile is a good name. After all, it's not so far from
> > the previous v
On Wed, Dec 26, 2018 at 01:04:44PM +0530, Pirate Praveen wrote:
> If it has to be completely separate from -backports, it means some packages
> will need to be maintained twice, even when they meet the criteria for
> backports fully, just because a package in volatile declare a dependency on
> t
>> I actually think volatile is a good name. After all, it's not so far
>from the previous volatile.
>
>volatile is a very bad name for this because we've used it already for
>something else.
Well, I consider it more or less the same basic idea. The old and new ideas
have more in common than not,
On Wed, Dec 26, 2018 at 12:07:42AM +0100, Dominik George wrote:
> I actually think volatile is a good name. After all, it's not so far from the
> previous volatile.
volatile is a very bad name for this because we've used it already for
something else.
--
cheers,
Holger
---
On Tue, Dec 25, 2018 at 08:52:19PM -0800, Kip Warner wrote:
> My package has an LSB friendly init.d script it distributes to manage
> the daemon it ships as a system service. I'd like to use it during unit
> testing so the daemon can be started, stopped, and various unit tests
> performed on it bet
Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler
Package name: slirp4netns
Version : git HEAD
Upstream Author : Akihiro Suda
URL : https://github.com/rootless-containers/slirp4netns
License : GPLv2+
Programming Lang: C
Description : User-
]] Felipe Sateler
Two minor typos.
> The proposed virtual packages are:
>
> logind: a org.freedesktop.login1 D-Bus API implementation
«an org…»
> default-logind: should be provided by the distributions default logind
> provider (currently pam-systemd)
distribution's.
Otherwise, this looks
34 matches
Mail list logo
