Re: Confusing our users - who is supporting LTS?

[Jonathan Dowland]

On Sat, Oct 27, 2018 at 09:41:43AM +0200, Wouter Verhelst wrote:

On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo wrote:

I meant that we would say that stable is supported by the security team.
And instead of saying that Jessie was supported by the LTS team, we
would say supported by Freexian.


I would object to that, on the grounds that even though Freexian is
currently the only company paying people to do LTS support, we should
not encourage the idea that they have a monopoly on doing that.


In my view, that is a situation we could address at the time that we had
more than one company doing LTS work. Until that time, I don't think
it's a problem. It's consistent with our listing of consultants, and
addresses the problems of the official-ness-or-not of LTS that are why
this thread started.


If some other company decides that they are not happy with Freexian,
then they are currently able to just start their own competing project
and do things differently. This is a good thing.


They would still be able to do so even if we were listing Freexian as
being the only entity supporting LTS (which is a statement of current
fact after all): I don't think the hypothetical competing company would
be too bashful to ask us to update the website. And we could pre-empt
the situation by making a clear statement as to the project's position
on listing Freexian (essentially codifying what I'm writing here,
somewhere)

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Confusing our users - who is supporting LTS?

[Adam Borowski]

On Fri, Nov 02, 2018 at 11:36:11AM +0800, Paul Wise wrote:
> On Thu, Nov 1, 2018 at 2:18 AM Holger Levsen wrote:
> 
> > ... and that's what I meant when I said not much has changed: what was
> > bad about about the idea of Debian paying people I still think is bad
> > today. And I don't think I'm alone here.
> 
> I also agree with Debian not paying members for their contributions.
> 
> > Money is a cause of friction (at best) and as such I firmly believe it's
> > better we keep money/paying contributors out of Debian *itself*.
> 
> I note that we are paying Outreachy interns using Debian funds. I
> personally do not have a problem with this as long as it remains a
> mechanism for growing the community rather than paying insiders.

I disagree, in both cases.

Debian should not pay anything through an organization that has race, gender
and nationality discrimination as its core purpose.  Accepting code produced
this way is acceptable (as would be contributions from anyone), but
providing monetary support for such ideology is not something I can speak of
positively.

On the other hand, using some funds for an activity vital for a good part of
the users which doesn't find enough volunteers, while controversial, is not
fundamentally bad.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road?  For thousands of years, the
⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the
⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk.  To where it came
⠈⠳⣄ together with silk (judging by today's amber stalls).

Re: Confusing our users - who is supporting LTS?

[Wouter Verhelst]

On Fri, Nov 02, 2018 at 08:58:47AM +, Jonathan Dowland wrote:
> On Sat, Oct 27, 2018 at 09:41:43AM +0200, Wouter Verhelst wrote:
> > On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo 
> > wrote:
> > > I meant that we would say that stable is supported by the security team.
> > > And instead of saying that Jessie was supported by the LTS team, we
> > > would say supported by Freexian.
> > 
> > I would object to that, on the grounds that even though Freexian is
> > currently the only company paying people to do LTS support, we should
> > not encourage the idea that they have a monopoly on doing that.
> 
> In my view, that is a situation we could address at the time that we had
> more than one company doing LTS work.

Yes, but then there's the important matter of wording.

A hyptothetical "Extended Debian support by Freexian" is a product of
Freexian that just happens to use Debian infrastructure.

In contrast, a just as hypothetical "Extended Debian support by the ED
team (financially supported by Freexian)" is a product of Debian that
just happens to be supported by Freexian.

I would be fine with something along the lines of the latter, but not
the former.

(the exact wording that we end up deciding on may be different, but you
get the point).

> Until that time, I don't think it's a problem.

I think that if we end up writing something which "assigns" LTS to
Freexian, then the possibility that some other company doing LTS work
diminishes. That is not something I want to see happening.

[...]
> > If some other company decides that they are not happy with Freexian,
> > then they are currently able to just start their own competing project
> > and do things differently. This is a good thing.
> 
> They would still be able to do so even if we were listing Freexian as
> being the only entity supporting LTS (which is a statement of current
> fact after all): I don't think the hypothetical competing company would
> be too bashful to ask us to update the website. And we could pre-empt
> the situation by making a clear statement as to the project's position
> on listing Freexian (essentially codifying what I'm writing here,
> somewhere)

Yes, that'd definitely be necessary.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Confusing our users - who is supporting LTS?

[Andrej Shadura]

On Fri, 2 Nov 2018 at 10:15, Adam Borowski  wrote:
>
> On Fri, Nov 02, 2018 at 11:36:11AM +0800, Paul Wise wrote:
> > On Thu, Nov 1, 2018 at 2:18 AM Holger Levsen wrote:
> >
> > > ... and that's what I meant when I said not much has changed: what was
> > > bad about about the idea of Debian paying people I still think is bad
> > > today. And I don't think I'm alone here.
> >
> > I also agree with Debian not paying members for their contributions.
> >
> > > Money is a cause of friction (at best) and as such I firmly believe it's
> > > better we keep money/paying contributors out of Debian *itself*.
> >
> > I note that we are paying Outreachy interns using Debian funds. I
> > personally do not have a problem with this as long as it remains a
> > mechanism for growing the community rather than paying insiders.
>
> I disagree, in both cases.
>
> Debian should not pay anything through an organization that has race, gender
> and nationality discrimination as its core purpose.  Accepting code produced
> this way is acceptable (as would be contributions from anyone), but
> providing monetary support for such ideology is not something I can speak of
> positively.
>
> On the other hand, using some funds for an activity vital for a good part of
> the users which doesn't find enough volunteers, while controversial, is not
> fundamentally bad.

You can extend this logic and claim it’s fundamentally bad to help
people in need, since that is discrimination on the fact of being in
need. In other words, helping someone who’s in a worst position
because of been previously and currently being discriminated against,
while being sort of discriminative (e.g. helping that person and not
someone who’s not been discriminated against), it fundamentally a good
thing, as it helps people and brings things into balance.

Your logic is flawed, just accept it already.

-- 
Cheers,
  Andrej

Re: Confusing our users - who is supporting LTS?

[Antonio Terceiro]

On Fri, Nov 02, 2018 at 08:58:47AM +, Jonathan Dowland wrote:
> On Sat, Oct 27, 2018 at 09:41:43AM +0200, Wouter Verhelst wrote:
> > On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo 
> > wrote:
> > > I meant that we would say that stable is supported by the security team.
> > > And instead of saying that Jessie was supported by the LTS team, we
> > > would say supported by Freexian.
> > 
> > I would object to that, on the grounds that even though Freexian is
> > currently the only company paying people to do LTS support, we should
> > not encourage the idea that they have a monopoly on doing that.
> 
> In my view, that is a situation we could address at the time that we had
> more than one company doing LTS work. Until that time, I don't think
> it's a problem. It's consistent with our listing of consultants, and
> addresses the problems of the official-ness-or-not of LTS that are why
> this thread started.
> 
> > If some other company decides that they are not happy with Freexian,
> > then they are currently able to just start their own competing project
> > and do things differently. This is a good thing.
> 
> They would still be able to do so even if we were listing Freexian as
> being the only entity supporting LTS (which is a statement of current
> fact after all): I don't think the hypothetical competing company would
> be too bashful to ask us to update the website. And we could pre-empt
> the situation by making a clear statement as to the project's position
> on listing Freexian (essentially codifying what I'm writing here,
> somewhere)

It was said in this same thread that Freexian is already not the only
company paying people to do LTS work. See



signature.asc
Description: PGP signature

Bug#911411: general: Computer freezes after suspend/hibernate

[Adam Nieścierowicz]

I have exactly the same problem.

If I can do some test let me know.

Kernel: 4.18.0-1-rt-amd64

Debian Release: buster/sid

-- 
---
Pozdrawiam
Adam Nieścierowicz




signature.asc
Description: OpenPGP digital signature

Re: New tool for salsa

[Xavier]

Le 28/10/2018 à 23:06, Xavier a écrit :
> Le 28/10/2018 à 19:38, Jochen Sprickerhof a écrit :
>> Hi Xavier,
>>
>> thanks for doing this, it looks awesome :).
> 
> Thanks ;-)
> 
>> Would it make sense to split this into a Gitlab part and a Salsa only
>> part? There are already a number of Gitlab tools (even in Debian) and
>> commands like search_user sound rather generic, so maybe it would make
>> sense to add them to those tools instead (I haven't checked if they
>> provide similar commands already).
> 
> Salsa is based on common Devscripts::* library. Splitting it will be a
> sort of fork. Anyway, any default values can be overridden in a file
> (using --conf-file) so you can have a configuration file for each Gitlab
> instance.
> 
>> * Xavier  [2018-10-28 11:44]:
>>> A point must be decided: for now it is called simply "salsa". Like
>>> "bts", it's a bit generic but nice, short and clear; but it can be used
>>> to manage any GitLab instance.
>>
>> +1 for salsa.
>>
>> Speaking of it, I'm still looking for a hub like tool for Gitlab, most
>> of the time I only need hub fork and hub pull-request. Is there a tool
>> in Debian with this functions for Gitlab?
> 
> I'm going to insert this.

Done in last commit. Example

  $ salsa fork node-mongodb
  $ cd node-mongodb
  $ git checkout -b fix-
  $ # Modify something
  $ git commit -a -m 'Fix something' -m 'Closes: #'
  $ salsa mr --mr-remove-source-branch

New MR is created using your last commit!

Many options available:
https://salsa.debian.org/yadd/devscripts/blob/devscripts-salsa-890594/scripts/salsa.pl#L405

Yo use salsa with another GitLab instance:
https://salsa.debian.org/yadd/devscripts/blob/devscripts-salsa-890594/scripts/salsa.pl#L513

>> (If you don't spit the salsa tool as proposed above, this would be a
>> nice addition. That's why I ask here.)

Done ;-)

>> Cheers Jochen

Cheers,
Xavier

Should libpam-elogind Provide libpam-systemd ?

[Ian Jackson]

Hi.

tl/dr: would this be wrong
   Package: libpam-elogind
   Provides: libpam-systemd
and should there be a Conflicts too ?

(emailing the systemd maintainers since that's Providing their package
 name, and also d-devel since I'm not sure what input others may have)


There's an active effort now to fix some of the problems that are
evident with sysvinit in buster.[1]  We are tackling the services
provided to (primarily) desktop sessions by systemd-logind, and
specifically pam_systemd.so which AIUI is part of the machinery for
arranging that console users get permission to do various things.

In stretch this was handled on many sysvinit systems by systemd-shim.
That is not really maintained - the version in sid right now is broken
- and its approach means that it keeps breaking and is awkward to fix.

In buster it looks like we are going to try to do this by using
elogind.  elogind is not in sid yet but we already have a half-working
prototype.

elogind provides a pam module to replace pam_systemd.so.  We are
considering having libpam-elogind.deb Provide libpam-systemd.

Is there some reason that would be a bad idea ?  Should it also
Conflict libpam-systemd ?

The alternative to this Provides would seem to be an MBF requesting
updates of all the dependencies.  (Maybe some other virtual package is
needed.)

(Our draft package ships libpam_elogind.so, but there are some
difficulties with pam configuration ending up referring to both
libpam_elogind.so and libpam_systemd.so and generating warnings, and a
few packages seem to explicitly refer to pam_systemd.so, for instance
lightdm's /etc/pam.d/lightdm-greeter.  If we can't resolve that we may
need to ship the pam module as libpam_systemd.so and that might
involve Replaces as well as Conflicts.)

We would be grateful to receive technical advice and opinions - and
corrections to any wrong assumptions.  To save my colleagues on d-i-d
having to come to debian-devel I will summarise the responses.

Thanks,
Ian.

[1] If you would like to come and help with improving Debian's
support for alternatives to systemd, please join this mailman list
  http://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-diversity

We are particularly in need of more `desktoppy' expertise.

-- 
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: New tool for salsa

[Xavier]

Le 02/11/2018 à 15:07, Xavier a écrit :
> Le 28/10/2018 à 23:06, Xavier a écrit :
>> Le 28/10/2018 à 19:38, Jochen Sprickerhof a écrit :
>>> Hi Xavier,
>>>
>>> thanks for doing this, it looks awesome :).
>>
>> Thanks ;-)
>>
>>> Would it make sense to split this into a Gitlab part and a Salsa only
>>> part? There are already a number of Gitlab tools (even in Debian) and
>>> commands like search_user sound rather generic, so maybe it would make
>>> sense to add them to those tools instead (I haven't checked if they
>>> provide similar commands already).
>>
>> Salsa is based on common Devscripts::* library. Splitting it will be a
>> sort of fork. Anyway, any default values can be overridden in a file
>> (using --conf-file) so you can have a configuration file for each Gitlab
>> instance.
>>
>>> * Xavier  [2018-10-28 11:44]:
 A point must be decided: for now it is called simply "salsa". Like
 "bts", it's a bit generic but nice, short and clear; but it can be used
 to manage any GitLab instance.
>>>
>>> +1 for salsa.
>>>
>>> Speaking of it, I'm still looking for a hub like tool for Gitlab, most
>>> of the time I only need hub fork and hub pull-request. Is there a tool
>>> in Debian with this functions for Gitlab?
>>
>> I'm going to insert this.
> 
> Done in last commit. Example
> 
>   $ salsa fork node-mongodb
>   $ cd node-mongodb
>   $ git checkout -b fix-
>   $ # Modify something
>   $ git commit -a -m 'Fix something' -m 'Closes: #'
>   $ salsa mr --mr-remove-source-branch
>
> New MR is created using your last commit!
>

Typo:

   $ salsa fork js-team/node-mongodb
   $ cd node-mongodb
   $ git checkout -b fix-
   $ # Modify something
   $ git commit -a -m 'Fix something' -m 'Closes: #'
   $ salsa mr --mr-remove-source-branch

The name "salsa" seems to have been accepted unanimously (2/2) and
therefore seems accepted ;-)

> Many options available:
> https://salsa.debian.org/yadd/devscripts/blob/devscripts-salsa-890594/scripts/salsa.pl#L405
> 
> Yo use salsa with another GitLab instance:
> https://salsa.debian.org/yadd/devscripts/blob/devscripts-salsa-890594/scripts/salsa.pl#L513
> 
>>> (If you don't spit the salsa tool as proposed above, this would be a
>>> nice addition. That's why I ask here.)
> 
> Done ;-)
> 
>>> Cheers Jochen
> 
> Cheers,
> Xavier
> 

Re: Should libpam-elogind Provide libpam-systemd ?

[Josh Triplett]

Ian Jackson wrote:
> tl/dr: would this be wrong
>Package: libpam-elogind
>Provides: libpam-systemd
> and should there be a Conflicts too ?

Please don't, no, for multiple reasons.

First, various packages followed the widely offered advice of using
libpam-systemd as the correct package to depend on if you need systemd
services, as it incorporated the appropriate alternatives on
systemd-sysv and systemd-shim. So packages depending on libpam-systemd
may depend on more aspects of systemd than just the pam module.

Second, based on experiences with systemd-shim, I would expect that
elogind will likely be *mostly* compatible with systemd's services, but
not necessarily perfectly compatible, especially when it comes to
current features. Using a Provides would make it more difficult for
packages to handle such compatibility issues.

Please instead just continue providing a separate pam module, please
*conflict* with libpam-systemd to avoid having debugging adventures
involving one interfering with the other, and please work with packages
that depend on libpam-systemd to add appropriate alternatives like
libpam-systemd | libpam-elogind if and *only* if they work with both.

Re: Should libpam-elogind Provide libpam-systemd ?

[Michael Stone]

On Fri, Nov 02, 2018 at 05:41:10PM +, Ian Jackson wrote:

Should it also Conflict libpam-systemd ?


Does it somehow prevent the admin from configuring one or the other in 
pam?



(Our draft package ships libpam_elogind.so, but there are some
difficulties with pam configuration ending up referring to both
libpam_elogind.so and libpam_systemd.so and generating warnings, and a
few packages seem to explicitly refer to pam_systemd.so, for instance
lightdm's /etc/pam.d/lightdm-greeter.  If we can't resolve that we may
need to ship the pam module as libpam_systemd.so and that might
involve Replaces as well as Conflicts.)


I'd rather see an additional module that just calls one of the two for 
automated config (or via alternatives?), and the ability to manually 
configure anything else.

Re: Should libpam-elogind Provide libpam-systemd ?

[Adam Borowski]

On Fri, Nov 02, 2018 at 05:41:10PM +, Ian Jackson wrote:
> tl/dr: would this be wrong
>Package: libpam-elogind
>Provides: libpam-systemd
> and should there be a Conflicts too ?

This has been briefly discussed before: it's a quite bad idea to have
provides with same name as a real package.  This works in Devuan where
there's no libpam-systemd, but in Debian we'd want something like:
Depends: default-logind | logind
or, if a specific version is needed:
Depends: default-logind (>= 3.14.15.926) | logind (>= 3.14.15.926)
(as suggested by smcv a while ago).

I even prepared a set of packages with that dependencies, although they're
badly outdated by now:
deb http://angband.pl/debian logind main
deb-src http://angband.pl/debian logind main
Key at:
https://angband.pl/debian/pool/main/k/kilobyte-archive-keyring/kilobyte-archive-keyring_3_all.deb
or:
wget -qO- https://angband.pl/deb/archive.html|apt-key add -

If you guys still think these deps are ok, tell me so and I'll refresh the
reverse dependencies in that repo.

> (emailing the systemd maintainers since that's Providing their package
>  name, and also d-devel since I'm not sure what input others may have)

Yeah.

> In stretch this was handled on many sysvinit systems by systemd-shim.
> That is not really maintained - the version in sid right now is broken
> - and its approach means that it keeps breaking and is awkward to fix.

It never worked for me, even when it was "maintained".  All -shim did was to
fulfill dependencies without actually bringing functionality such as suspend
/etc from the GUI.  For that you had to recompile the Utopia stack against
consolekit.  Elogind on the other hand does it ok.

> In buster it looks like we are going to try to do this by using
> elogind.  elogind is not in sid yet but we already have a half-working
> prototype.

Its packaging is tailored for Devuan where there's no systemd to deal with.
On the other hand they're doing necromancy with consolekit which seems to be
a waste of time to me.

> The alternative to this Provides would seem to be an MBF requesting
> updates of all the dependencies.  (Maybe some other virtual package is
> needed.)

I'm afraid this would be needed, per smcv's suggestion.

> (Our draft package ships libpam_elogind.so, but there are some
> difficulties with pam configuration ending up referring to both
> libpam_elogind.so and libpam_systemd.so and generating warnings, and a
> few packages seem to explicitly refer to pam_systemd.so, for instance
> lightdm's /etc/pam.d/lightdm-greeter.  If we can't resolve that we may
> need to ship the pam module as libpam_systemd.so and that might
> involve Replaces as well as Conflicts.)

I have yet to test newer packages, apologies for not having done that yet.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ A tit a day keeps the vet away.
⠈⠳⣄ 

Re: Should libpam-elogind Provide libpam-systemd ?

[Adam Borowski]

On Fri, Nov 02, 2018 at 03:39:10PM -0400, Michael Stone wrote:
> On Fri, Nov 02, 2018 at 05:41:10PM +, Ian Jackson wrote:
> > Should it also Conflict libpam-systemd ?
> 
> Does it somehow prevent the admin from configuring one or the other in pam?

Conflicts would greatly simplify packaging, but I'm afraid we need
coinstallability at least for upgrades.  With d-i installing systemd, the
user needs to be able to switch to sysvinit -- and, horrors, some might
want to go the other way.

It'd be damage to allow two loginds running at the same time, thus what
about:
* the "systemd" package starts its logind only if systemd is pid 1
* elogind starts its logind only if pid 1 is not systemd

That would handle runtime dependencies, I wonder how to handle them
apt-wise.  Alas, the only robust idea I have so far doesn't work with
multiarch, thus is worthless.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road?  For thousands of years, the
⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the
⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk.  To where it came
⠈⠳⣄ together with silk (judging by today's amber stalls).

Re: Should libpam-elogind Provide libpam-systemd ?

[Russ Allbery]

Adam Borowski  writes:

> Conflicts would greatly simplify packaging, but I'm afraid we need
> coinstallability at least for upgrades.  With d-i installing systemd,
> the user needs to be able to switch to sysvinit -- and, horrors, some
> might want to go the other way.

> It'd be damage to allow two loginds running at the same time, thus what
> about:
> * the "systemd" package starts its logind only if systemd is pid 1
> * elogind starts its logind only if pid 1 is not systemd

I may be missing some complexity here, but it feels as if there should be
a PAM module that determines which logind is running and then dispatches
the PAM calls to the appropriate module for the running logind.

-- 
Russ Allbery (r...@debian.org)   

Re: Should libpam-elogind Provide libpam-systemd ?

[Simon McVittie]

On Fri, 02 Nov 2018 at 12:20:55 -0700, Josh Triplett wrote:
> please work with packages
> that depend on libpam-systemd to add appropriate alternatives like
> libpam-systemd | libpam-elogind if and *only* if they work with both.

Yes, this. libpam-elogind is very unlikely to be enough to satisfy
dbus-user-session's dependency, for instance, unless elogind has taken
an excursion into systemd-like service management while I wasn't looking.

Some packages depending on libpam-systemd want logind's D-Bus and
libsystemd APIs, which elogind can mostly or entirely provide; policykit-1
is likely to be one of these.

Other packages depending on libpam-systemd want systemd --user, which
elogind can't provide, and which I'm reasonably sure people who don't
like systemd wouldn't want anyway (if you have a reason not to want
systemd managing system services as pid 1, then the same reason probably
applies equally to your per-user services).

smcv

Re: Should libpam-elogind Provide libpam-systemd ?

[Adam Borowski]

On Fri, Nov 02, 2018 at 10:22:58PM +, Simon McVittie wrote:
> On Fri, 02 Nov 2018 at 12:20:55 -0700, Josh Triplett wrote:
> > please work with packages
> > that depend on libpam-systemd to add appropriate alternatives like
> > libpam-systemd | libpam-elogind if and *only* if they work with both.
> 
> Yes, this. libpam-elogind is very unlikely to be enough to satisfy
> dbus-user-session's dependency, for instance, unless elogind has taken
> an excursion into systemd-like service management while I wasn't looking.

And for that reason dbus-user-session has Depends: systemd, which describes
this requirement just fine.  It runs systemd's user parts.  The rest of the
world has dbus-x11 which has some important features dbus-user-session
lacks, such as the ability to login multiple times.

A package whose very description says in its title:
"simple interprocess messaging system (systemd --user integration)"
depends on systemd, that's not surprising.  So as long as no dependency
chain forces it in, all is ok.

> Some packages depending on libpam-systemd want logind's D-Bus and
> libsystemd APIs, which elogind can mostly or entirely provide; policykit-1
> is likely to be one of these.
>
> Other packages depending on libpam-systemd want systemd --user, which
> elogind can't provide, and which I'm reasonably sure people who don't
> like systemd wouldn't want anyway (if you have a reason not to want
> systemd managing system services as pid 1, then the same reason probably
> applies equally to your per-user services).

Is there a package that wants something beyond logind, yet doesn't depend on
systemd itself?  I can't seem to find any obvious candidate.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road?  For thousands of years, the
⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the
⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk.  To where it came
⠈⠳⣄ together with silk (judging by today's amber stalls).

Re: Confusing our users - who is supporting LTS?

[Adam Borowski]

On Fri, Nov 02, 2018 at 12:45:17PM +0100, Andrej Shadura wrote:
> > I disagree, in both cases.
> >
> > Debian should not pay anything through an organization that has race, gender
> > and nationality discrimination as its core purpose.  Accepting code produced
> > this way is acceptable (as would be contributions from anyone), but
> > providing monetary support for such ideology is not something I can speak of
> > positively.
> 
> You can extend this logic and claim it’s fundamentally bad to help
> people in need, since that is discrimination on the fact of being in
> need.

...?  I don't see what not tolerating race discrimination has to do with
being against helping people.  Am I missing something?

Both helping people in need, and not promoting any race/etc over another are
pretty basic rules.  Both are important requirements for the society.  The
latter is not included (yet?) in any document of Debian proper (other for
depriving someone of the right to run a piece of software), but at least
DebConf's code of conduct says it clearly:

The following is a list of examples of behavior that is deemed highly
inappropriate and will not be tolerated at DebConf:
[...]
* unwarranted exclusion from conference or related events based on age,
  gender, sexual orientation, disability, physical appearance, body size,
  race, religion;

So I don't understand why you disagree so strongly with my want to have
similar rule for Debian proper.

> In other words, helping someone who’s in a worst position
> because of been previously and currently being discriminated against,
> while being sort of discriminative (e.g. helping that person and not
> someone who’s not been discriminated against), it fundamentally a good
> thing, as it helps people and brings things into balance.

This paragraph, can't parse.

> Your logic is flawed, just accept it already.

Can't argue with such a statement...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁ I was born a dumb, ugly and work-loving kid, then I got swapped on
⢿⡄⠘⠷⠚⠋⠀ the maternity ward.
⠈⠳⣄

Bug#912705: ITP: wsgiproxy2 -- A WSGI Proxy with various http client backends

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: wsgiproxy2
  Version : 0.4.5
  Upstream Author : Gael Pasgrimaud 
* URL : https://github.com/gawel/WSGIProxy2/
* License : MIT
  Programming Lang: Python
  Description : A WSGI Proxy with various http client backends

WSGI Proxy implementation that provides a WSGI shim and forwards request
over HTTP to another HTTP server.

(This is an optional dependency of python3-webtest)

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#912708: ITP: aiowsgi -- minimalist WSGI server implementation using async

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: aiowsgi
  Version : 0.0.7
  Upstream Author : Gael Pasgrimaud 
* URL : https://github.com/gawel/aiowsgi
* License : MIT
  Programming Lang: Python
  Description : minimalist WSGI server implementation using async

This package provides a simple Python implementation of the
WSGI interace using the waitress pure Python HTTP implementation.

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#912711: ITP: python-backports.os -- Backports of new features in Python's os module

[魏銘廷]

Package: wnpp
Severity: wishlist
Owner: Yao Wei (魏銘廷) 

* Package name: python-backports.os
  Version : 0.1.1
  Upstream Author : Pi Delport 
* URL : https://github.com/pjdelport/backports.os/
* License : PSF-2
  Programming Lang: Python
  Description : Backports of new features in Python's os module

Hi,

This package is a backports of the os.fsencode and os.fsdecode for older
Python.

This is a dependency for python-fs (2.1.1), and py3 version of this
package is considered not needed. 

This package should be maintained under DPMT.  The request of joining
the team has been sent.

Yao Wei


signature.asc
Description: PGP signature