Re: Git Packaging Round 2: When to Salsa
> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Git Packaging Round 2: When to Salsa"):
>> Discussion Comments ---
Ian> ...
>> I realize that not everyone wants all developers to have push
>> access to their packages. If you have a firm idea about that,
>> then this recommendation is not for you. I also realize that by
>> starting by recommending the debian group I'm recommending a more
>> permissive maintainership model closer to low threshhold NMU than
>> only NMU my packages after explicit confirmation. I think that
>> the dh discussion supports the conclusion that we are OK with
>> that as a project *as a recommendation*. If a maintainer doesn't
>> like that level of openness, that's fine. My take though is that
>> when recommending what to do to people who do not have
>> preconceived ideas, more open policies like the debian group and
>> low threshhold NMUs are in alignment with the project.
Ian> I absolutely have no problem with recommending this as a
Ian> practice to the individual maintainer who doesn't know better.
Ian> However, for this practice to be useful:
Ian> 1. The maintainer's git repository branch format must be
Ian> documented. Otherwise another contributor has to guess. This
Ian> could be done either by doing maintainer uploads with dgit
Ian> (since recent versions of dgit include the maintainer branch
Ian> format information in the git tags), or perhaps by writing
Ian> something in README.source.
Makes sense.
My take is discussion on debian-devel strongly supports making it easier
to figure out what branch format people are using.
Ian> 2. We need to have a shared understanding of when people may
Ian> push to branches in the debian/ repository. I think you are
Ian> proposing that the answer be "if you do an NMU". I would
Ian> support this but it is a change to current practice. We also
Ian> need to understand how this relates to the recommendation to
Ian> NMU to DELAYED.
I'm not proposing a change to current practice.
I *think* that the documented practice may not be in alignment with
what happens.
That is, it seems like Debian developers are much more conservative in
how they use the debian group than is permitted by the wiki.
I use the debian group for my packages.
My experience has been that sometimes people push obvious things like
changelog cleanups without asking. Sometimes I get merge requests.
People will sometimes push fixes to areas of the code they have been
working on especially after I encourage them to do so.
Yes, I could have just given permission to push. I probably would not
have done so in the instances in question.
I understand this is one person's experience not actual data.
I think in this discussion we can recommend that interested parties
revisit the wiki documentation and see how it matches to reality after
running with the debian group for a few years.
I did do a bit of looking at data.
In my unstable sources.list, there are 17863 source packages that
include salsa.debian.org in the vcs-git. Of those, 2192 are in the
debian group.
That's the largestsingle group; perl-team (next) comes in at 1417.
The debian group is larger than all the individual accounts used on
salsa combined according to vcs-git in unstable.
So, what I'm seeing is that most people maintain packages in teams.
When they choose to maintain packages not in an explicit team, the
debian group is the dominant choice.
That choice is common enough that we have a strong presumption that it
actually works for people. If it were a complete mess of people pushing
without thinking or considering consequences we'd be hearing about it
more.
My take is that I think I have sufficient support for my original
recommendation on using debian at this point. Adding Ian's
recommendation that you need to document the branch format makes sense.
Revisiting what current practice is for the debian group and how that
interacts with NMUs and delayed also makes sense.
I don't think we need to block on that happening. I do not plan to lead
that discussion: I don't think I have time.
As always, continued feedback welcome; this is where I see things at
this point in the discussion.
--Sam
Re: Git Packaging Round 2: When to Salsa
Sam Hartman writes: > > I did do a bit of looking at data. > In my unstable sources.list, there are 17863 source packages that > include salsa.debian.org in the vcs-git. Of those, 2192 are in the > debian group. > That's the largestsingle group; perl-team (next) comes in at 1417. > > The debian group is larger than all the individual accounts used on > salsa combined according to vcs-git in unstable. Sure, but there's a lot of inertia from collab-maint on alioth when it was the promoted / only-sensible option. I'd guess that most collab-maint packages were ported to the debian group. d
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
> "Ian" == Ian Jackson writes: Ian> No-one should be asked to interact with a non-free service, as Ian> part of contributing to Debian. Ian> Note I say "no-one should be asked". It is not enough, for me, Ian> for there to be a "plan (b)" route. Ie, it is not OK for a Ian> maintainer to advertise a github repo as preferred, or to ask Ian> for PRs on github, even if an alternative or mirror, or Salsa, Ian> or the BTS are also advertised. Ian> This is for two reasons: firstly, this is a matter of Ian> principle. Our mission is free software. Free software needs Ian> free tools. We should not be advertising or encouraging the Ian> use of non-free tools. I agree that many people in the project want us to work hard to avoid encouraging non-free tools. I agree that's a significant consideration. Ian> Secondly, there is a practical problem if a maintainer (even a Ian> solo maintainer) chooses to regard a nonfree service as Ian> primary. If another person comes along and wants to help out Ian> with that package, they will either have to also tolerate using Ian> the nonfree service, or they will have to try to persuade the Ian> maintainer to abandon their existing hosting or tools (and Ian> maybe the maintainer's existing workflow, if the nonfree tools Ian> are significantly different). For me that is wholly Ian> unacceptable. I agree that this can be a consequence of using non-free tools. I believe those involved in the discussions around this issue have considered this consequence. >> If the use of a non-free service is preventing an active member >> of our community from contributing to a team, the team should >> work to find a solution so that member can contribute >> effectively. Ian> This is no good as an answer. Ian> In practice imprecations to a team (or a maintainer) to "find a Ian> solution so that a Debian contributor can contribute Ian> effectively" will be useless because: Ian> (i) Even having to ask this question already makes the new Ian> contributor seem awkward, puts them at a social disadvantage, Ian> and perhaps annoys people. Ian> (ii) We lack workable enforcement mechanisms for this kind of Ian> imprecation. (Because we lack *any* workable enforcement Ian> mechanisms to deal with obstructive maintainer behaviours.) Ian> (iii) Even if everyone has good will, and or even if we had Ian> excellent and proportionate and swift enforcement mechanism, Ian> there will inevitably be a delay and hassle and friction. I agree that these are problems you can run into. Ian> ... >> Using non-free services for Debian packaging is not recommended >> but is permitted. Ian> I strongly disagree with this, or at least, with what seems to Ian> me to be the obvious implication. It is also contrary to our Ian> current practice. Unfortunately, I believe you are in the rough when judging rough consensus on this issue. This was discussed fairly recently on debian-project; my take is that Thomas Goirand represented a position roughly the same as your own. My reading of that discussion is that: 1) there are significant problems we'd run into if we forbid non-free tools in Debian work 2) There was not sufficient support in that discussion to do so anyway 3) There are significant problems that come up when non-free tools are used. The problems enumerated were similar to the problems you describe above. More over your claim that this is not our current practice runs counter to facts. Of the 26,480 packages in my unstable sources with a vcs-git, 1836 are on github. 7% seems much more consistent to me with "NOT Recommended" than "forbidden." I think you would take exception if I said that dgit (940 packages in my unstable sources--about half the github count) ran counter to current practice. Yes, that is comparing apples to oranges on a number of levels. My point is that there is a significant fraction of our developers who do use github and that it seems to be a current practice. That said, I'm really confused that your message didn't get any response before now. Considering how sharp some of the responses were on -project, I don't know how to take this. Were people not responding because the -project discussion was so recent, they didn't see a need to rehash it? Were people not responding because -devel has a very different audience and everyone here agrees with you? In terms of next steps. I'd recommend that you read the -project discussion. Your arguments here are not responsive to several of the counters brought up in that discussion. Obviously you may disagree with the trade offs expressed, but it would be valuable for you to consider the points made in that discussion. Even so, based on that discussion and the active use of github, my take is that we do not have a rough consensus to forbid non-free servic
Re: Git Packaging Round 2: When to Salsa
On Thu, 2019-09-12 at 08:14 -0400, Sam Hartman wrote: > Ian> 1. The maintainer's git repository branch format must be > Ian> documented. Otherwise another contributor has to guess. This > Ian> could be done either by doing maintainer uploads with dgit > Ian> (since recent versions of dgit include the maintainer branch > Ian> format information in the git tags), or perhaps by writing > Ian> something in README.source. > > Makes sense. > My take is discussion on debian-devel strongly supports making it easier > to figure out what branch format people are using. I don't see much value in this requirement (besides additional work). One should look at the repository anyway whan planning to do changes (to match the existing style used); one would naturally see how files are organized. We already had tons of packages shipping a README.source stating "this packages uses quilt, ..." before which I also didn't find very valuable; this seems pretty similar. If dgit provides a program to figure this out, people interested in obtaining the information automatically can just extract and use that. (Using dgit to upload packages is sadly incompatible with best practices around packaging.) Ansgar
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
Sam Hartman writes ("Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github"):
> Unfortunately, I believe you are in the [wrong] when judging rough
> consensus on this issue.
>
> This was discussed fairly recently on debian-project; my take is that
> Thomas Goirand represented a position roughly the same as your own.
> My reading of that discussion is that:
Thomas was making a lot of much stronger assertions about what should
be done.
> More over your claim that this is not our current practice runs counter
> to facts. Of the 26,480 packages in my unstable sources with a vcs-git,
> 1836 are on github. 7% seems much more consistent to me with "NOT
> Recommended" than "forbidden."
Blimey. I didn't realise that.
I think this does not demonstrate that I am wrong about project's
overall opinion about this. I am confident that a GR to forbid this
would succeed.
It just demonstrates that we have few working enforcement mechanisms
against contributors who violate our norms.
> Even if there is not rough consensus to forbid non-free services, I'd
> welcome help documenting the concerns that can come up.
I think this is a question of Debian's core values.
Given the current situation, with 7% of packages in violation of what
I see as a key norm, it seems that this cannot be resolved via a
consensus process.
We should resolve this with a GR. Something like:
Subject: Free Software Needs Free Tools
No Debian contributor should be expected or encouraged, when working
to improve Debian, to use non-free tools. This includes proprietary
web services. We will ensure this, insofar as it is within Debian's
collective control.
For example, Vcs-Git fields in source packages must not refer to
proprietary git code management systems. Non-Debian services are
acceptable here so long as they are principally Free Software.
We encourage all our upstreams to use Free/Libre tools.
We recognise that metadata in Debian which describes the behaviour
of those outside our community, for example fields which refer to
upstream source management systems, may (in order to be accurate)
still need to refer to proprietary systems.
Ian.
--
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: Git Packaging Round 2: When to Salsa
> "Ansgar" == Ansgar writes: Ansgar> On Thu, 2019-09-12 at 08:14 -0400, Sam Hartman wrote: Ian> 1. The maintainer's git repository branch format must be Ian> documented. Otherwise another contributor has to guess. This Ian> could be done either by doing maintainer uploads with dgit Ian> (since recent versions of dgit include the maintainer branch Ian> format information in the git tags), or perhaps by writing Ian> something in README.source. >> >> Makes sense. My take is discussion on debian-devel strongly >> supports making it easier to figure out what branch format people >> are using. Ansgar> I don't see much value in this requirement (besides Ansgar> additional work). One should look at the repository anyway Ansgar> whan planning to do changes (to match the existing style Ansgar> used); one would naturally see how files are organized. I actually find it annoying to figure out which branch format something is. I do the work you suggest, but automation or documentation would help me as a developer.
Re: Git Packaging Round 2: When to Salsa
Sam Hartman writes: >> "Ansgar" == Ansgar writes: > > Ansgar> On Thu, 2019-09-12 at 08:14 -0400, Sam Hartman wrote: > Ian> 1. The maintainer's git repository branch format must be > Ian> documented. Otherwise another contributor has to guess. This > Ian> could be done either by doing maintainer uploads with dgit > Ian> (since recent versions of dgit include the maintainer branch > Ian> format information in the git tags), or perhaps by writing > Ian> something in README.source. > >> > >> Makes sense. My take is discussion on debian-devel strongly > >> supports making it easier to figure out what branch format people > >> are using. > > Ansgar> I don't see much value in this requirement (besides > Ansgar> additional work). One should look at the repository anyway > Ansgar> whan planning to do changes (to match the existing style > Ansgar> used); one would naturally see how files are organized. > > I actually find it annoying to figure out which branch format something > is. > I do the work you suggest, but automation or documentation would help me > as a developer. I just went through a batch of 240+ team uploads (because *sigh* no arch-all bin:NMUs). I can confirm it's annoying to have to figure the the git workflows involved when working at even this modest scale. If we're not going to enable people to work on multiple packages, then I (still) don't really see the point of the Debian salsa team. d
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
On Thu, Sep 12, 2019 at 02:07:52PM +0100, Ian Jackson wrote: > I think this does not demonstrate that I am wrong about project's > overall opinion about this. I am confident that a GR to forbid this > would succeed. For what is worth, I would vote against such a GR. I'm extremely uncomfortable reading what you wrote. I consider you one of the leading actors of the current discussion on improving/cleaning/redesigning default workflows in Debian, and I respect you as such. I see you keep pushing things with a strong cohercive slant rather than working on creating useful and attractive infrastructure to make everyone's work easier. I wish this work would be grounded instead on an acknowledgement and acceptance of the, imperfect, diverse, yet still valid status quo. Thankfully I still consider it to be so, with the exception of the occasional frightening cohercive twist in some of your mails. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Git Packaging Round 2: When to Salsa
Ansgar writes ("Re: Git Packaging Round 2: When to Salsa"):
> If dgit provides a program to figure this out, people interested in
> obtaining the information automatically can just extract and use that.
It is not possible to figure out the branch format automatically
given just the maintainer branch.
> (Using dgit to upload packages is sadly incompatible with best
> practices around packaging.)
Using dgit to upload packages is best practice.
Ian.
--
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.
should Debian add itself to https://python3statement.org ?
https://python3statement.org/ is a site documenting the projects which are supporting the policy of dropping Python2 to keep Python3 only. The site is designed for python packages specifically, to have only Python3 supported by end of 2020. But it seems to me it would be in the spirit of the site to add Debian's pledge to remove Python2 (we are currently in the middle of doing just that). Is this a thing that we want to do as a project, to add Debian to https://python3statement.org/ ? Drew
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
Enrico Zini writes ("Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github"):
> On Thu, Sep 12, 2019 at 02:07:52PM +0100, Ian Jackson wrote:
> > I think this does not demonstrate that I am wrong about project's
> > overall opinion about this. I am confident that a GR to forbid this
> > would succeed.
>
> For what is worth, I would vote against such a GR.
> I'm extremely uncomfortable reading what you wrote.
I'm sorry to hear that.
> I see you keep pushing things with a strong cohercive slant rather
> than working on creating useful and attractive infrastructure to
> make everyone's work easier.
The latter is what I am trying to do. I'm sorry that the opposite is
occuring.
> I wish this work would be grounded instead on an acknowledgement and
> acceptance of the, imperfect, diverse, yet still valid status quo.
For me, my opposition to github has nothing to do with my desire to
improve Debian's workflows.
I am indeed trying to improve Debian's workflows by providing better
options. Options that I hope people will voluntarily adopt, and that
will become more officially recommended - but *not* mandatory.
On the other hand, my opposition to github is like my opposition to
the inclusion of software in main which automatically and without
adequate user permission downloads and runs proprietary binary DRM
code. Or like the arguments we've had over the lack of proper source
code for some javascript and machine language programs. Software has
been blocked from Debian, and valuable contributors discouraged, as a
result.
Should we also tolerate these freedom problems as an "imperfect,
diverse, yet still valid status quo" ? Is it unjustifiably "coercive"
to block non-free software from Debian main ?
I guess one lesson I should perhaps learn is that it is difficult for
me in particular to push on these kind of software freedom issues when
they are entangled with workflow issues, because of inevitable
confusion/conflation/whatever.
So maybe I should leave the "Free Software Needs Free Tools"[1]
advocacy to others. I do still think it's important.
[1] https://mako.cc/writing/hill-free_tools.html
> Thankfully I still consider it to be so, with the exception of the
> occasional frightening cohercive twist in some of your mails.
Well, thanks for the rebuke. I hope I have clarified my thinking and
please do the same again in future. (Or, indeed, right now, if you
think this message is still frightening...)
Regards,
Ian.
--
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: should Debian add itself to https://python3statement.org ?
Drew Parsons writes ("should Debian add itself to https://python3statement.org
?"):
> https://python3statement.org/ is a site documenting the projects which
> are supporting the policy of dropping Python2 to keep Python3 only.
That statement is a *pledge* to drop support for python2 by the end of
2020. Have we in fact made such a pledge ? I think I may have missed
the memo that python2 would be removed from bullseye.
I did some searching and found this
https://lists.debian.org/debian-python/2019/07/msg00080.html
which is a sane-looking transition plan but doesn't seem to have a
timeframe and doesn't seem to contemplate removal of the actual
python2 interpreter.
FTAOD I don't have an opinion about whether bullseye *should* ship
without python2. Obviously dropping it would not be desirable from
users' pov, but maintaining an ancient thing by ourselves would not be
desirable either. I think I trust the Debian Python team to make that
tradeoff.
But we need to be clear what's going on and communicate early. If
python2 is going out of bullseye then there are a lot of bugs that
should probably be marked rc fairly soon...
thanks,
Ian.
--
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: should Debian add itself to https://python3statement.org ?
On Thu, 2019-09-12 at 16:01 +0100, Ian Jackson wrote:
> Drew Parsons writes ("should Debian add itself to
> https://python3statement.org ?"):
> > https://python3statement.org/ is a site documenting the projects which
> > are supporting the policy of dropping Python2 to keep Python3 only.
>
> That statement is a *pledge* to drop support for python2 by the end of
> 2020.
FWIW, that proposed ending date is 2020-01-01, ~110 days from now.
-Jim P.
Re: should Debian add itself to https://python3statement.org ?
Jim Popovitch writes ("Re: should Debian add itself to
https://python3statement.org ?"):
> On Thu, 2019-09-12 at 16:01 +0100, Ian Jackson wrote:
> > Drew Parsons writes ("should Debian add itself to
> > https://python3statement.org ?"):
> > > https://python3statement.org/ is a site documenting the projects which
> > > are supporting the policy of dropping Python2 to keep Python3 only.
> >
> > That statement is a *pledge* to drop support for python2 by the end of
> > 2020.
>
> FWIW, that proposed ending date is 2020-01-01, ~110 days from now.
It says
| the following projects have pledged to drop support for Python 2.7
| no later than 2020, coinciding with the Python development team's
| timeline for dropping support for Python 2.7.
which is rather ambiguous.
If we do interpret it to mean 2020-01-01, I doubt there is any
realistic chance of us making that, even if we decide we want to.
Ian.
--
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: should Debian add itself to https://python3statement.org ?
On Thu, 2019-09-12 at 16:14 +0100, Ian Jackson wrote:
> Jim Popovitch writes ("Re: should Debian add itself to
> https://python3statement.org ?"):
> > On Thu, 2019-09-12 at 16:01 +0100, Ian Jackson wrote:
> > > Drew Parsons writes ("should Debian add itself to
> > > https://python3statement.org ?"):
> > > > https://python3statement.org/ is a site documenting the projects which
> > > > are supporting the policy of dropping Python2 to keep Python3 only.
> > >
> > > That statement is a *pledge* to drop support for python2 by the end of
> > > 2020.
> >
> > FWIW, that proposed ending date is 2020-01-01, ~110 days from now.
>
> It says
>
> | the following projects have pledged to drop support for Python 2.7
> | no later than 2020, coinciding with the Python development team's
> | timeline for dropping support for Python 2.7.
>
> which is rather ambiguous.
I agree, that site seems, by-design, to avoid the obvious issue that the
Python Developers have stated (in lots of places) that they will stop
supporting Python 2x on 2020-01-10 (search for "python2 eol")
> If we do interpret it to mean 2020-01-01, I doubt there is any
> realistic chance of us making that, even if we decide we want to.
I agree, it's a time waster to even try. The issue really comes down
to: will DDs support python2 security releases through bullseye's eol.
-Jim P.
Bug#940121: ITP: sphinxcontrib-svg2pdfconverter -- Sphinx SVG to PDF Converter Extension
Package: wnpp Owner: Gianfranco Costamagna Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: sphinxcontrib-svg2pdfconverter Version : 0.1.0 Upstream Author : 2018-2019 by Missing Link Electronics, 2018-2019 by Stefan Wiehler * URL : https://github.com/sephalon/sphinxcontrib-svg2pdfconverter/ * License : BSD-2 Programming Lang: Python Description : Sphinx SVG to PDF Converter Extension This extension converts SVG images to PDF in case the builder does not support SVG images natively (e.g. LaTeX). . Internally, either Inkscape or rsvg-convert from libRSVG as a more lightweight alternative is used to convert images. . This package contains the Python 3.x module. I need this package to fix nbsphinx RC bug #939492 due to new pandoc currently in unstable. Cheers, Gianfranco
Re: should Debian add itself to https://python3statement.org ?
Hi Drew, https://release.debian.org/transitions/html/python2-rm.html Given the current progress it looks not easy to make a promise. If some upstream happen to lag behind the schedule of python3 migration, we'll just stuck there for a while. On 2019-09-12 14:46, Drew Parsons wrote: > https://python3statement.org/ is a site documenting the projects which > are supporting the policy of dropping Python2 to keep Python3 only. > > The site is designed for python packages specifically, to have only > Python3 supported by end of 2020. > > But it seems to me it would be in the spirit of the site to add > Debian's pledge to remove Python2 (we are currently in the middle of > doing just that). > > Is this a thing that we want to do as a project, to add Debian to > https://python3statement.org/ ? > > Drew
Re: should Debian add itself to https://python3statement.org ?
On 12.09.19 17:01, Ian Jackson wrote:
Drew Parsons writes ("should Debian add itself to https://python3statement.org
?"):
https://python3statement.org/ is a site documenting the projects which
are supporting the policy of dropping Python2 to keep Python3 only.
That statement is a *pledge* to drop support for python2 by the end of
2020. Have we in fact made such a pledge ? I think I may have missed
the memo that python2 would be removed from bullseye.
I did some searching and found this
https://lists.debian.org/debian-python/2019/07/msg00080.html
which is a sane-looking transition plan but doesn't seem to have a
timeframe and doesn't seem to contemplate removal of the actual
python2 interpreter.
FTAOD I don't have an opinion about whether bullseye *should* ship
without python2. Obviously dropping it would not be desirable from
users' pov, but maintaining an ancient thing by ourselves would not be
desirable either. I think I trust the Debian Python team to make that
tradeoff.
But we need to be clear what's going on and communicate early. If
python2 is going out of bullseye then there are a lot of bugs that
should probably be marked rc fairly soon...
it's communicated here:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2removal;users=debian-pyt...@lists.debian.org
derived from
https://release.debian.org/transitions/html/python2-rm.html (not perfect, we are
still missing bug reports).
it's way too early to mark all of these as RC.
No, it's not yet decided if Python2 will be part of bullseye. But the python
command and the unversioned python packages won't be part of bullseye.
thanks,
Ian.
Re: should Debian add itself to https://python3statement.org ?
On Thu, 12 Sep 2019 16:01:54 +0100 Ian Jackson wrote: > That statement is a *pledge* to drop support for python2 by the end of > 2020. Have we in fact made such a pledge ? I think I may have missed > the memo that python2 would be removed from bullseye. > ""He's dead, Jim" (Doctor Leonard McCoy) > I did some searching and found this > https://lists.debian.org/debian-python/2019/07/msg00080.html > which is a sane-looking transition plan but doesn't seem to have a > timeframe and doesn't seem to contemplate removal of the actual > python2 interpreter. It doesn't really matter. In fact python2 is dead for years, if we start now to make a plan we are years to late. The timeframe is _now:. > FTAOD I don't have an opinion about whether bullseye *should* ship > without python2. Obviously dropping it would not be desirable from > users' pov, but maintaining an ancient thing by ourselves would not be > desirable either. I think I trust the Debian Python team to make that > tradeoff. I have an opinion. If we define stable following Jack Cohen, python2 can stay forever - if you forgOt: There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen > But we need to be clear what's going on and communicate early. If > python2 is going out of bullseye then there are a lot of bugs that > should probably be marked rc fairly soon... We can't do better now - planning of the removal and preparation for would been a task for the buster release cycle - this chance is gone. But is is no reason to remove dead things now. And the last reminder is the python clock: Let me copy and paste the content of https://pythonclock.org/ at the time of writing: > Hell, yes, Python 2.7 will retire in... > 0 > Years > 3 > Months > 19 > Days > 4 > Hours > 59 > Minutes > 44 > Seconds > > > What's all this, then? > Python 2.7 will not be maintained past 2020. Originally, there was no > official date. Recently, that date has been updated to January 1, > 2020. > This clock has been updated accordingly. My original idea was to throw > a Python 2 Celebration of Life party at PyCon 2020, to celebrate > everything Python 2 did for us. That idea still stands. (If this > sounds > interesting to you, email pythonclock...@gmail.com). > > Python 2, thank you for your years of faithful service. > > Python 3, your time is now. > > How do I get started? > If the code you care about is still on Python 2, that's totally > understandable. Most of PyPI's popular packages now work on Python 2 > and 3, and more are being added every day. Additionally, a number of > critical Python projects have pledged to stop supporting Python 2 > soon. > To ease the transition, the official porting guide has advice for > running Python 2 code in Python 3. > Only another harsh comment: So what do you expect - i kown this page from the beginning. If it is surprising for the Debian project that these guys are serious about it we really should adjust the perception of the environment around us. I for myself have two important python2 projects that are not migrated right now - and i will migrate them if really needed because it is no fun to do so - so it depends on Debian - but i'm dead without both projects, so i'm in fact prepared, only to lazy to do it now. > thanks, > Ian. > Cheers Alf -- Alf Gaida BDBF C688 EFAD BA89 5A9F 464B CD28 0A0B 4D72 827C
Re: should Debian add itself to https://python3statement.org ?
Hi, On 12-09-2019 17:01, Ian Jackson wrote: > But we need to be clear what's going on and communicate early. Yes, not on the front page, but there is (first bullet): https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#deprecated-components Paul signature.asc Description: OpenPGP digital signature
Re: should Debian add itself to https://python3statement.org ?
On Sep 12, Alf Gaida wrote: > It doesn't really matter. In fact python2 is dead for years, if we > start now to make a plan we are years to late. The timeframe is _now:. Dead for who? As long as somebody will be interested in maintaining python2 it will not be dead. I maintain some packages which have been abandoned by their upstream maintainers 20 years ago and they are fine. I am not a python users, but as long as somebody will continue to maintain it in Debian we have no reason to remove it no matter what the upstream maintainers would like. -- ciao, Marco signature.asc Description: PGP signature
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On Mon, 9 Sep 2019 00:38:03 +0200, Adam Borowski wrote: >With local DNS: >* the target server knows about you (duh!) >* the ISP can read the destination of every connection > [reading the DNS packets, reading the IP header, reading SNI header] >* the ISP can block such connections > [blocking DNS packets, blocking actual connection] >* DNSSEC forbids falsifying DNS > >With DoH: >* the target server knows about you (duh!) >* the ISP can read the destination of every connection > [reading the IP header, reading SNI header] >* the ISP can block such connections > [blocking actual connection] >* Cloudflare can read the destination of every connection > [they serve the DNS...] >* Cloudflare can falsify DNS¹ >* Cloudflare can block connections > [blocking or falsifying DNS response] > >So currently DoH is strictly worse. Will DOH break corporate web apps that are accessed over a VPN (and thus only resolvable via the local resolver)? Or has Mozilla catered for that? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: should Debian add itself to https://python3statement.org ?
On 2019-09-12 16:22, Marco d'Itri wrote: > On Sep 12, Alf Gaida wrote: > >> It doesn't really matter. In fact python2 is dead for years, if we >> start now to make a plan we are years to late. The timeframe is _now:. > Dead for who? As long as somebody will be interested in maintaining > python2 it will not be dead. Agreed. there are already python2 forks such as: https://github.com/naftaliharris/tauthon It may sound funny but I don't hope any python2 stuff get back with a new name after the python2 removal. But, it could happen if some people is willing to support and maintain... How should Debian react if someone submitted an ITP for python2 forks, such as the tauthon above?
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
On Thu, 12 Sep 2019 08:47:49 -0400 Sam Hartman wrote: > That said, I'm really confused that your message didn't get any > response before now. Considering how sharp some of the responses > were on -project, I don't know how to take this. Were people not > responding because the -project discussion was so recent, they didn't > see a need to rehash it? Were people not responding because -devel > has a very different audience and everyone here agrees with you? That's really easy: Most people aviod harsh or sharp answers, i'm not. And to be honest, i don't really understand all the discussions about git. It's just a tool - and most of the time misused in debian. Not that i'm the biggest git expert on earth - i'm only a happy user for ten years now. And the ten years include bitbucket, github, gitlab, gitblit, gitea, gitolite, gerrit and so on - so it is totally irrelevant to some extend where things are hosted, it remains git in the very end. Regarding the workflow and participation - it might be a problem that one need an account for github or other non-free services - it's easy: No account, no participation, bad luck. In one thing Ian is right: Debian packages should not be hosted on non-free services. I would go a step further: No Debian package must be hosted outside of debian. Period. Problem solved. That would prevent problems like the ones with debian live hosted by Progress Linux, LXDE packaging hosted on https://git.lxde.org (broken for some month now) and so on. Would really make sense, but is a different story. Another though: If we start not to allow packaging on non free services and using non-free tools - what would be next: Considering projects that use non-free services like github or bitbucket as non-free - in this case please drop the whole LXQt from debian, we will continue to use github.com in near future and are not planning a change right now. Cheers Alf -- Alf Gaida BDBF C688 EFAD BA89 5A9F 464B CD28 0A0B 4D72 827C
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Re: Git Packaging Round 2: SHOULD Not or
Ian> MUSt NOT Github"):
>> Unfortunately, I believe you are in the [wrong] when judging
Ian placed the word "wrong" in my mouth replacing the word "rough" from
my original mail. I disagree with that characterization of what I said
in the strongest possible terms. Judging consensus is not about finding
right or wrong; it is not about a moral judgment at all. Judging
consensus is about finding agreement (or its lack). When I say that Ian
is in the rough, I mean that I think there is not a perfect consensus on
the issue, and that Ian holds an view that is inconsistent with what
consensus exists. I'm also implying by that statement that the
discussion is not ongoing; that we've reached a good enough
approximation of consensus to move on even though some people wish we
had reached a different conclusion.
>> More over your claim that this is not our current practice runs
>> counter to facts. Of the 26,480 packages in my unstable sources
>> with a vcs-git, 1836 are on github. 7% seems much more
>> consistent to me with "NOT Recommended" than "forbidden."
Ian> Blimey. I didn't realise that.
Ian> I think this does not demonstrate that I am wrong about
Ian> project's overall opinion about this. I am confident that a GR
Ian> to forbid this would succeed.
Ian> It just demonstrates that we have few working enforcement
Ian> mechanisms against contributors who violate our norms.
>> Even if there is not rough consensus to forbid non-free services,
>> I'd welcome help documenting the concerns that can come up.
Ian> I think this is a question of Debian's core values.
Ian> Given the current situation, with 7% of packages in violation
Ian> of what I see as a key norm, it seems that this cannot be
Ian> resolved via a consensus process.
Ian> We should resolve this with a GR. Something like:
This sounds like a discussion that would be better on debian-project.
I'll try and move it there, quoting your draft text.
--Sam
Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
Sam Hartman writes ("Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github"):
> Ian Jackson writes:
>
> > Sam Hartman writes ("Re: Git Packaging Round 2: SHOULD Not or
> > MUSt NOT Github"):
> >> Unfortunately, I believe you are in the [wrong] when judging
>
> Ian placed the word "wrong" in my mouth replacing the word "rough" from
> my original mail. I disagree with that characterization of what I said
> in the strongest possible terms.
I'm sorry, I genuinely thought you had made a typo. The sentence
Unfortunately, I believe you are in the rough when judging rough
consensus on this issue.
didn't make sense to me. I should have stared at it for longer and
then maybe I would have seen what you meant.
>When I say that Ian is in the rough, I mean that I think there is
> not a perfect consensus on the issue, and that Ian holds an view
> that is inconsistent with what consensus exists.
Thanks for the explanation.
Ian.
--
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: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On Tue, Sep 10, 2019 at 07:46:57PM +0200, Marco d'Itri wrote: > On Sep 09, Adam Borowski wrote: > > > With DoH: > > * the target server knows about you (duh!) > > * the ISP can read the destination of every connection > > [reading the IP header, reading SNI header] > > * the ISP can block such connections > > [blocking actual connection] > Well, no. They cannot without significantly more expensive hardware to > do DPI and a *totally different* legislative framework. > (Source: I have been dealing with government-mandated censorship in > Italy for ~15 years, both at technical and policy levels.) I don't understand how blocking by IP would be any more expensive than blocking by DNS. It's _cheaper_: you read a field in the IP header instead of doing it in a higher level DNS server. > > * Cloudflare can falsify DNS¹ > You can use DNSSEC over DoH. If implemented. > You obviously consider Mozilla's choices of trusted resolvers (currently > Cloudflare, hopefully others too in the future) a bigger privacy risk > for generic users (the one who use the browser defaults) than their ISP, > I disagree. Currently you need to trust the ISP; with DoH you need to trust both the ISP and Cloudflare. Unless you tunnel all the data over DNS (iodine), you need to contact your actual destination over open network. > I still believe that generic users are better served by deploying more > censorship-resistant protocols than by worrying that Cloudflare (or > whoever else) would violate the privacy requirements mandated by > Mozilla. Sure, but DoH is less censorship-resistant not more. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Your snowflakes have nothing on my socks drawer. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
How to give back a build
The package I uploaded yesterday failed to build[1]. In the buildd, 2 of 1000+ tests failed. Of course, I built in a clean sbuild for sid before I uploaded it, and the same package built fine on the newer Ubuntu distros on launchpad. So I'm hoping it was just a glitch, and I'd like to retry the build, but my search engine foo is failing me. How can I give back the build? Or will it retry automatically? Regards Jeff [1] https://buildd.debian.org/status/logs.php?arch=all&pkg=gscan2pdf&ver=2.5.6-1 signature.asc Description: OpenPGP digital signature
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
Adam Borowski writes: > On Tue, Sep 10, 2019 at 07:46:57PM +0200, Marco d'Itri wrote: >> Well, no. They cannot without significantly more expensive hardware to >> do DPI and a *totally different* legislative framework. >> (Source: I have been dealing with government-mandated censorship in >> Italy for ~15 years, both at technical and policy levels.) > > I don't understand how blocking by IP would be any more expensive than > blocking by DNS. It's _cheaper_: you read a field in the IP header instead > of doing it in a higher level DNS server. >From the top of my head I can think of several reasons: - For IP-level blocking you need to implement blocking in more places instead of a central place (DNS); also more data needs to be processed in total. Block lists are generally not public and access to them might need different restrictions (for legal reasons). - IP-level blocking leads to more overblocking (anything sharing the same IP); this causes legal problems. So Marco's arguments seem reasonable. >> > * Cloudflare can falsify DNS¹ >> You can use DNSSEC over DoH. > > If implemented. It's probably easier to use DNSSEC with DoH as you avoid broken resolvers at ISP or customer routers that don't speak DNSSEC or not even proper DNS. I've encountered customer routers that knew only about `A` RRs and lied about `PTR` which breaks stuff in interesting ways... Ansgar
Re: How to give back a build
On Thu, 2019-09-12 at 19:02 +0200, Jeff wrote: > The package I uploaded yesterday failed to build[1]. In the buildd, 2 > of 1000+ tests failed. Of course, I built in a clean sbuild for sid > before I uploaded it, and the same package built fine on the newer > Ubuntu distros on launchpad. So I'm hoping it was just a glitch, and > I'd like to retry the build, but my search engine foo is failing me. > > How can I give back the build? If you're a DD, then you can use the service described in https://debblog.philkern.de/2019/08/alpha-self-service-buildd-givebacks.html Otherwise e-mail debian-wb-team@lists.d.o and request the give-back. That is the address listed in https://release.debian.org/wanna-build.txt , which is the first Google hit for "debian give back" for me. > Or will it retry automatically? > Nope. Regards, Adam
Re: How to give back a build
Hello, Jeff, le jeu. 12 sept. 2019 19:02:15 +0200, a ecrit: > How can I give back the build? Please read the Misc Developer News on d-d-a :) https://lists.debian.org/debian-devel-announce/2019/08/msg3.html Samuel
Re: How to give back a build
On 2019-09-12 Jeff wrote: > The package I uploaded yesterday failed to build[1]. In the buildd, 2 of > 1000+ tests failed. Of course, I built in a clean sbuild for sid before > I uploaded it, and the same package built fine on the newer Ubuntu > distros on launchpad. So I'm hoping it was just a glitch, and I'd like > to retry the build, but my search engine foo is failing me. > How can I give back the build? https://lists.debian.org/debian-devel-announce/2019/08/msg3.html
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On Thu, Sep 12, 2019 at 06:26:34PM +0200, Marc Haber wrote: > Will DOH break corporate web apps that are accessed over a VPN (and > thus only resolvable via the local resolver)? Or has Mozilla catered > for that? Please see https://wiki.mozilla.org/Trusted_Recursive_Resolver. network.trr.mode=2 seems to configure what you want. DoH needs to be able to bootstrap anyway. Bastian -- Youth doesn't excuse everything. -- Dr. Janice Lester (in Kirk's body), "Turnabout Intruder", stardate 5928.5.
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
Then you should ask why we have ICANN in the first place! PS: https://en.wikipedia.org/wiki/OpenNIC On Sun, Sep 8, 2019 at 11:01 PM Ondřej Surý wrote: > > Hi, > > I haven’t found any discussion on the topic (although I haven’t searched very > hard and only looked for DoH and DNS keywords in the BTS), but since Mozilla > plans to enable DoH to CloudFlare by default to US based users: > https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/ > I would rather see an explicit statement. I would be very surprised with > Debian’s usual stance regarding the users’ privacy that we would not consider > this as a privacy violation, but again I am not Firefox maintainer in Debian > and I would rather hear from them than speculate on my own. > > Thanks, > Ondřej > -- > Ondřej Surý
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
What? How did you manage to go from me suggesting disabling DoH by default to CloudFlare in Firefox without explicit user consent to an attack on ICANN? But I guess that this alternative DNS root nonsense will just never die, so I should not be really surprised. -- Ondřej Surý > On 12 Sep 2019, at 19:45, Amir H. Firouzian wrote: > > Then you should ask why we have ICANN in the first place! > > PS: https://en.wikipedia.org/wiki/OpenNIC > >> On Sun, Sep 8, 2019 at 11:01 PM Ondřej Surý wrote: >> >> Hi, >> >> I haven’t found any discussion on the topic (although I haven’t searched >> very hard and only looked for DoH and DNS keywords in the BTS), but since >> Mozilla plans to enable DoH to CloudFlare by default to US based users: >> https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/ >> I would rather see an explicit statement. I would be very surprised with >> Debian’s usual stance regarding the users’ privacy that we would not >> consider this as a privacy violation, but again I am not Firefox maintainer >> in Debian and I would rather hear from them than speculate on my own. >> >> Thanks, >> Ondřej >> -- >> Ondřej Surý
Re: should Debian add itself to https://python3statement.org ?
On Thu, Sep 12, 2019 at 09:30:09AM -0700, Mo Zhou wrote: > How should Debian react if someone submitted an ITP for python2 > forks, such as the tauthon above? "Go ahead but don't interfere with other packages, including the Python 3 interpreter and the Python 3 modules, and we won't maintain tauthon modules or the packaging infrastructure for them". Note: this is a private opinion, not the opinion of DPMT as a whole. -- WBR, wRAR signature.asc Description: PGP signature
Re: Git Packaging Round 2: When to Salsa
On Sun, 08 Sep 2019 17:35:10 -0400, Sam Hartman wrote: >* Use a public repository where in-progress and ongoing work are > available to the public. Do not just push when you release. I would liket to have a recommendation about git push --force in that case. I frequently do rebase --interactive to sort and bring structure in my commit histories, which would need a force push in case a commit which is part of a rebase was already pushed. To avoid this; I frequenly push only after releasing. How about documenting that branches prefixed with "wip" can be force pushed any time and people pulling from those branches should be expected to handle that? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Git Packaging Round 2: When to Salsa
On Sun, 08 Sep 2019 22:05:17 -0700, Russ Allbery wrote: >Sean Whitton writes: >> On Sun 08 Sep 2019 at 05:35PM -04, Sam Hartman wrote: > >>> You are encouraged to mirror your repository to Salsa so that people can >>> find more of the Debian packaging in one place. > >> Hmm, if the Vcs-* are set correctly, what's the value of mirroring to >> salsa? (I don't object in the least; just wondering about the value.) > >Higher chance that the repository won't go away. For instance, the >primary home of all of my packaging repositories is on my own Git server >and will continue to be because I like to have my own personal control >over such things, but it's in the project's best interest for me to mirror >them to Salsa so that if I suddenly make millions of dollars and decide I >just want to read books and stop running online services, the repositories >don't become inaccessible. alioth.debian.org, anyone? That one went away pretty fast. -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: How to give back a build
On 12/09/2019 19:08, Adam D. Barratt wrote: > If you're a DD, then you can use the service described in > https://debblog.philkern.de/2019/08/alpha-self-service-buildd-givebacks.html Thanks to those who replied so quickly. The instructions worked a treat. Regards Jeff signature.asc Description: OpenPGP digital signature
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
Le September 12, 2019 4:52:47 PM UTC, Adam Borowski a écrit : >On Tue, Sep 10, 2019 at 07:46:57PM +0200, Marco d'Itri wrote: >> On Sep 09, Adam Borowski wrote: >> >> > With DoH: >> > * the target server knows about you (duh!) >> > * the ISP can read the destination of every connection >> > [reading the IP header, reading SNI header] >> > * the ISP can block such connections >> > [blocking actual connection] >> Well, no. They cannot without significantly more expensive hardware >to >> do DPI and a *totally different* legislative framework. >> (Source: I have been dealing with government-mandated censorship in >> Italy for ~15 years, both at technical and policy levels.) > >I don't understand how blocking by IP would be any more expensive than >blocking by DNS. It's _cheaper_: you read a field in the IP header >instead >of doing it in a higher level DNS server. I don't think it is, actually. Disregarding the legal framework part, only looking at the technical aspect of things, when you do it with DNS, you just have to create a local version of the zone that has be censored and distribute it normally on your resolvers, for instance. Anyway you do a high level modification in a high level service. Request will go through your DNS infrastructure the way it's intended to. However, reading IP headers on routers to block a particular destination is not how network are designed to operate. It's not as cheap a function you'd think, because it means either being able on the customer router, or close to it, and those aren't usually designed to filter that way, or you make sure all traffic pass by a filtering router at some point - which means dedicated hardware with the traffic load involved. This is usually complicated in a large ISP context: networks are huge and evolved over time ; and they weren't designed for censorship to begin with, there was this thing called Net Neutrality... ;) Cheers, -- nodens
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
Hi, On Thu, Sep 12, 2019 at 06:52:47PM +0200, Adam Borowski wrote: > > I still believe that generic users are better served by deploying more > > censorship-resistant protocols than by worrying that Cloudflare (or > > whoever else) would violate the privacy requirements mandated by > > Mozilla. > Sure, but DoH is less censorship-resistant not more. The idea for resilience is "too big to block". When Domain Fronting still worked with Google, people used this to circumvent censorship because blocking it would have required blocking Google, so cooperation from Google was necessary to implement effective censorship. For the same reason, a lot of political activism is taking place on Github, who have a smaller target market than Google and have fewer staff exposed in hostile political environments, so they can manage threats by restricting employees' travel. The same will apply to services also hosted on a big CDN, and I believe that is the business model behind providing this service in the first place -- pull international activists onto CloudFlare. I expect this to bring a marked improvement for a short time, followed by the realization at CF that they exist by the kind permission of nation-state actors that are very interested in strategic Internet choke points. To put it bluntly: CloudFlare has, as a consequence of their business model, too many employees and assets bound in various jurisdictions. Their censorship resilience is going to be limited to countries where they do not have a local presence. They already need to be able to return different results depending on the client's IP address, otherwise they break anycast or split horizon based load balancing for everyone whose DNS they do not control themselves. This mechanism will be used to limit the scope of governmental censorship requests to the appropriate geographic area. To be honest, my feeling is that CloudFlare management are not believing this to be political at all -- it's a technical solution that improves service for their own customers and degrades service for non-customers (because it breaks traditional geo-based load balancing), so of course they are going to do this. They have a history of ignoring context, and the fallout will be interesting to watch. In the meantime, we have a responsibility towards our users to not expose them to unnecessary risks. I'm fairly sure that a plugin to control the DoH setting from the navigation bar will pop up shortly. I'd be in favour of installing it by default (keep in mind: we are also "too big to block", so we're in the position to give software that is useful for activists an install base that makes it hard to identify activists by having the software installed). Simon
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On Sun, Sep 08, 2019 at 11:17:13PM +0200, Marco d'Itri wrote: > On Sep 08, Ondřej Surý wrote: > > > I would rather see an explicit statement. I would be very surprised > > with Debian’s usual stance regarding the users’ privacy that we would > > not consider this as a privacy violation, but again I am not Firefox > > maintainer in Debian and I would rather hear from them than speculate > > on my own. > I think that this is a privacy enhancement, since it prevents some major > ISPs from spying on users DNS queries. Except all they need to do is return NXDOMAIN on the "use-application-dns.net" domain, and Presto! they can spy on their users again. https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https So no, DoH defeats people who run wireshark, but it does not "prevent some major ISPs from spying". If a "major ISP" wants to spy, it just needs to tell Firefox "hey, that DoH feature? Please just disable it," and it's back in business. Meanwhile, Firefox' default sends everything to the other side of the Internet without the user's consent. How does that improve privacy? > When it will be enabled in other countries it will prevent > government-mandated (or "encouraged") censorship. Nope. See above. > It would be a terrible signal if Debian decided to disable an > anti-censoship feature provided by an upstream vendor. Except DoH is *not* an anti-censorship feature. It is a feature that provides a net reduction in privacy. CloudFlare says that it won't read your DNS requests -- scout's honour! -- but even if that's true and we can believe it, there's no reason to assume it will continue to do so forever, past any potential future acquisitions or CEO changes. Mozilla really missed the ball on this one. OpenBSD already made the necessary changes to Firefox. I think we should, too. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard signature.asc Description: PGP signature
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On Tue, Sep 10, 2019 at 07:56:48PM +0200, Julien Cristau wrote: > On Tue, Sep 10, 2019 at 08:24:03 +0200, Ondřej Surý wrote: > > > > On 9 Sep 2019, at 15:31, Bjørn Mork wrote: > > > > > > I for one, do trust my ISPs a lot more than I trust Cloudflare or > > > Google, simply based on the jurisdiction. > > > > While I still strongly agree with you on this one (even though I think all > > major ISPs here are scumbags, especially the incumbent), I still strongly > > think we should not have this debate here, and we should turn this around > > the usual Debian policy - to not send data to 3rd party without explicit > > user > > content and defaulting to not doing so. > > > How is this worse than what we're already doing by default, namely > sending the same data to whoever happens to be on the network, in > addition to whoever happened to be listed in an unauthenticated dhcp > response? (Which, if you're lucky, is your ISP, aka a 3rd party.) The major difference is that third party is someone you've got a contractual relation with. If you're talking to CloudFlare, you don't. Good luck calling CloudFlare support when something goes wrong. -- 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: How to give back a build
On Thu, Sep 12, 2019 at 07:02:15PM +0200, Jeff wrote: > The package I uploaded yesterday failed to build[1]. In the buildd, 2 of > 1000+ tests failed. Of course, I built in a clean sbuild for sid before > I uploaded it, and the same package built fine on the newer Ubuntu > distros on launchpad. So I'm hoping it was just a glitch, and I'd like > to retry the build, but my search engine foo is failing me. > > How can I give back the build? > > Or will it retry automatically? You ask the wanna-build maintainers, or the build maintainers of the architecture in question. There's the debian-wb-team mailinglist where such requests can be sent. -- 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: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On Sep 12, Wouter Verhelst wrote: > Except all they need to do is return NXDOMAIN on the > "use-application-dns.net" domain, and Presto! they can spy on their > users again. They need to have a government to compel then to do it, which is not obvious. And then Mozilla will disable that (you can read this clearly in their announcement) and figure out a different strategy. > Meanwhile, Firefox' default sends everything to the other side of the > Internet without the user's consent. How does that improve privacy? Not really "to the other side": Cloudflare's resolvers are highly anycasted. -- ciao, Marco signature.asc Description: PGP signature
Bug#940140: ITP: node-es-to-primitive -- Pure javascript implementation of ToPrimitive algorithm
Package: wnpp Severity: wishlist Owner: Bastien Roucariès Package name: node-es-to-primitive Version : 1.2.0 Upstream Author : Jodan Harband URL : https://github.com/ljharb/es-to-primitive/ License : expat Programming Lang: javascript Description : Pure javascript implementation of ToPrimitive algorithm This package provides a ponyfill for ToPrimitive algorithm, thus converting of JavaScript object to a primitive value. In JavaScript a primitive is data that is not an object and has no method. There are seven primitive data type: string, number, bigint, boolean, null, undefined and symbol. . Node.js is an event-based server-side JavaScript engine.
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On Thu, Sep 12, 2019 at 11:43:33PM +0200, Marco d'Itri wrote: > On Sep 12, Wouter Verhelst wrote: > > > Except all they need to do is return NXDOMAIN on the > > "use-application-dns.net" domain, and Presto! they can spy on their > > users again. > They need to have a government to compel then to do it, which is not > obvious. That's not in the announcement. In fact, it also allows for "opt-in parental controls", which has nothing to do with governments. > And then Mozilla will disable that (you can read this clearly > in their announcement) and figure out a different strategy. The announcement does indeed mention that, yes. I sincerely doubt they'll actually do that, though, unless more than, say, 50% of the networks they measure end up disabling things. Of course that's just a matter of personal opinion. > > Meanwhile, Firefox' default sends everything to the other side of the > > Internet without the user's consent. How does that improve privacy? > Not really "to the other side": Cloudflare's resolvers are highly > anycasted. I admit to using some hyperbole here, but the point was that your data is being sent to a partner of the software you happen to be using, without you having a contractual relationship with them. If your bank did that, you'd yell that it's improper. So why is a browser allowed to do so? Don't get me wrong; I applaud Mozilla for trying to make encrypted DNS the default. I just don't think they're going about it the right way. -- 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: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On 2019-09-12 22:27:39 +0200 (+0200), Simon Richter wrote: [...] > The idea for resilience is "too big to block". > > When Domain Fronting still worked with Google, people used this to > circumvent censorship because blocking it would have required > blocking Google, so cooperation from Google was necessary to > implement effective censorship. [...] > I'd be in favour of installing it by default (keep in mind: we are > also "too big to block", so we're in the position to give software > that is useful for activists an install base that makes it hard to > identify activists by having the software installed). Note that by way of counterargument, Google and its services have been blocked in mainland China by the Great Firewall for nearly a decade now, so I question whether there is really such a thing as "too big to block." -- Jeremy Stanley signature.asc Description: PGP signature
Work-needing packages report for Sep 13, 2019
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1307 (new: 2) Total number of packages offered up for adoption: 153 (new: 0) Total number of packages requested help for: 53 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: golang-gopkg-flosch-pongo2.v3 (#940030), orphaned yesterday Description: Django-syntax like template-engine for Go Installations reported by Popcon: 2 Bug Report URL: https://bugs.debian.org/940030 python-medusa (#939642), orphaned 5 days ago Description: Framework for implementing asynchronous servers Installations reported by Popcon: 268 Bug Report URL: https://bugs.debian.org/939642 1305 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 153 packages are awaiting adoption. See https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: autopkgtest (#846328), requested 1016 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: autodeb-worker debci-worker Installations reported by Popcon: 1185 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 2909 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 714 Bug Report URL: https://bugs.debian.org/642906 broadcom-sta (#886599), requested 612 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1777 Bug Report URL: https://bugs.debian.org/886599 cargo (#860116), requested 884 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 1214 Bug Report URL: https://bugs.debian.org/860116 cyrus-sasl2 (#799864), requested 1450 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin claws-mail-attach-remover claws-mail-attach-warner (108 more omitted) Installations reported by Popcon: 199899 Bug Report URL: https://bugs.debian.org/799864 dee (#831388), requested 1154 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-dev zeitgeist-core Installations reported by Popcon: 45838 Bug Report URL: https://bugs.debian.org/831388 developers-reference (#759995), requested 1839 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 8315 Bug Report URL: https://bugs.debian.org/759995 devscripts (#800413), requested 1444 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero autodeb-worker brz-debian bzr-builddeb customdeb debci debian-builder (32 more omitted) Installations reported by Popcon: 12236 Bug Report URL: https://bugs.debian.org/800413 docker.io (#908868), requested 362 days ago Description: Linux container runtime Reverse Depends: golang-docker-dev golang-github-containers-storage-dev golang-github-fsouza-go-dockerclient-dev golang-github-google-cadvisor-dev golang-github-samalba-dockerclient-dev kubernetes-node subuser whalebuilder Installations reported by Popcon: 2215 Bug Report URL: https://bugs.debian.org/908868 ed (#886643), requested 612 days ago Description: classic UNIX line editor Reverse Depends: apt-cacher libdebbugs-perl opensmtpd sn Installations reported by Popcon: 16494 Bug Report URL: https://bugs.debian.org/886643 ejabberd (#767874), requested 1774 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib ejabberd-mod-cron ejabberd-mod-default-contacts ejabberd-mod-default-rooms ejabberd-mod-deny-omemo ejabberd-mod-filter ejabberd-mod-grafite ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml (10 more omitted) Installations reported by Popcon: 447 Bug Report URL: https://bugs.debian.org/767874 fbcat (#565156), requested 3529 days ago Description: framebuffer grabber Install
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
// send from my mobile device Jeremy Stanley 于 2019年9月13日周五 06:51写道： > On 2019-09-12 22:27:39 +0200 (+0200), Simon Richter wrote: > [...] > > The idea for resilience is "too big to block". > > > > When Domain Fronting still worked with Google, people used this to > > circumvent censorship because blocking it would have required > > blocking Google, so cooperation from Google was necessary to > > implement effective censorship. > [...] > > I'd be in favour of installing it by default (keep in mind: we are > > also "too big to block", so we're in the position to give software > > that is useful for activists an install base that makes it hard to > > identify activists by having the software installed). > > Note that by way of counterargument, Google and its services have > been blocked in mainland China by the Great Firewall for nearly a > decade now, so I question whether there is really such a thing as > "too big to block." > -- > Jeremy Stanley > I share the same concern. And please note that cloudflare doesn't have pop in China mainland, and in some ISP from China, the latency can be more than 200ms(http://mping.chinaz.com/?host=1.0.0.1). >
Re: Git Packaging Round 2: When to Salsa
On Thu, 2019-09-12 at 15:37:49 +0100, Ian Jackson wrote:
> Ansgar writes ("Re: Git Packaging Round 2: When to Salsa"):
> > (Using dgit to upload packages is sadly incompatible with best
> > practices around packaging.)
>
> Using dgit to upload packages is best practice.
I'm sorry, but "best practice" according to who? The dgit maintainers?
Thanks,
Guillem
Re: Git Packaging Round 2: When to Salsa
On 2019, സെപ്റ്റംബർ 13 1:06:13 AM IST, Marc Haber wrote: >alioth.debian.org, anyone? That one went away pretty fast. I wonder why people keep repeating this. This was migrated to salsa and also archived, so nothing was lost. This was a planned move to a better solution (gforge was unmaintained), there was enough time to move things around. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#940153: ITP: mockery -- mock code autogenerator for Golang
Package: wnpp Severity: wishlist Owner: Dmitry Smirnov X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package name: mockery Version: 0.0~git20181123 Upstream Author: Opinionated Architecture License: BSD-3-clause URL: https://github.com/vektra/mockery Vcs-Browser: https://salsa.debian.org/go-team/packages/mockery Description: golang-github-stretchr-testify-dev Description: mock code autogenerator for Golang Mockery provides the ability to easily generate mocks for golang interfaces. It removes the boilerplate coding required to use mocks. signature.asc Description: This is a digitally signed message part.
