]] 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
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-
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
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
---
>> 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 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
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 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
[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 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
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
> >
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
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
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
> 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:
> > 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
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
> >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 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
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, 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
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
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
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
> - 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
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
> 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
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
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
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
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
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
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
34 matches
Mail list logo
