Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Taking a step back, what I'm objecting to here is that I think
Russ> people are implicitly extending the definition of a source
Russ> package to include the VCS and implicitly assuming that we're
Russ> going to require people to use a VCS, but are not saying that
Russ> explicitly.  (To be fair, Ian *is* saying that explicitly,
Russ> which I think makes everything clearer and more
Russ> straightforward, and lets us have an argument on the merits.
Russ> But I think the merits of a *requirement*, as opposed to a
Russ> recommendation, are weak as currently framed, without a bunch
Russ> more work to use standardized Git branch layouts and
Russ> facilities for global changes.)

Russ> We have to decide if the VCS used for maintaining a Debian
Russ> package is in scope for our policies and procedures or not.
Russ> Currently, it is not, so telling people what Git hosting
Russ> service they can use is out of scope in exactly the same way
Russ> that we don't tell people what text editor they use to change
Russ> Debian packaging files.

With my facilitator hat on.
What I'm hearing is that

* Today we're not making the VCS in scope for requirements, but we are
  for recommendations.  I don't know if that means it is in scope for
  policies and procedures: often policies and procedures include
  recommendations as well as requirements.  I don't think anyone is
  proposing that it be in scope for debian-policy as edited by the
  policy editors.

* A number of people have talked about moving toward the VCS being
  something that very much is in scope for requirements.  Things like
  mandating that work be done in Git and moving toward Git as the
  preferred source format.  I don't think Ian is alone in that eventual
  goal.  So I think it is fair to have that in your mind in these
  discussions as something we might eventually do.  I have not tried to
  judge consensus on whether we're hoping to do that some day: it is not
  immediate enough that judging that consensus would be valuable.  I'll
  note that some people like Scott have spoken against such a change.
  So that might happen some day or it might not.

* I think the concern you raise about people just removing the vcs-*
  fields is a blocking objection to forbidding non-free services.  Which
  is to say even if everyone were supporting the idea of forbidding
  non-free services we'd need to have a better answer to that objection
  than has been presented so far to have an informed consensus.

* But that objection ends up not mattering.  We do not have a rough
  consensus to forbid non-free services.

I'm putting together a blog post on Debian's history with non-free
software and services as part of making Debian.
To spoil that post a bit, here are some things I think people who are
unhappy about the use of Github and other non-free services can do:

* Work to understand why people are using Github.  From my past
  experience developing this sort of understanding works better when not
  combined with strong persuasion.  So given their strongly expressed
  opinion, Thomas and Ian might not be the best choice for actually
  interviewing Github users.

* If gaps are identified try and fill them.  For example if more than
  just Norbert are looking for a platform that is under control of a
  wider group than Debian, perhaps the wider free software community
  could benefit from some free Git service that has well established and
  trusted governance.

* Work on documenting and simplifying bidirectional mirroring between
  Salsa and Github.  Provide tools to make that easy to setup.
  

NVIDIA proprietary driver with linux-rt and Wayland

[Yoann LE BARS]

Hello everybody out there!

I am using Debian 10:

$ cat /etc/debian_version
10.1

I am running the real-time kernel from standard distribution 
repositories:

$ uname -a
Linux petra 5.2.0-0.bpo.2-rt-amd64 #1 SMP PREEMPT RT Debian
5.2.9-2~bpo10+1 (2019-08-25) x86_64 GNU/Linux

I have a NVIDIA graphical controller:

$ lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX
750 Ti] (rev a2)

To help Nouveau team, they ask to install the proprietary driver. Also,
for my video editing work, proprietary driver is more efficient. The
problem is, by default proprietary driver does not compile for real-time
kernel. But it appears some people using Archlinux have found some way
to compile NVIDIA proprietary driver for real-time kernem:

https://aur.archlinux.org/packages/nvidia-rt/
https://aur.archlinux.org/packages/nvidia-96xx-dkms/

Also, there may be some way to make it run Wayland.

So, here is my questions: is there any work done on Debian side to make
NVIDIA proprietary driver working on Linux-rt? To make it run Wayland?
How can I help?

Best regards.

-- 
Yoann LE BARS
http://le-bars.net/yoann/
Diaspora* : yleb...@framasphere.org

Re: Git Packaging Round 2: When to Salsa

[Jonas Meurer]

Sam Hartman:
>> "Bastian" == Bastian Blank  writes:
> 
> Bastian> Hi Sam
> Bastian> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> >> The Salsa CA pipeline is recommended.
> 
> Bastian> For this I need to use my veto as Salsa admin.  With the CI
> Bastian> people we have to work through too much problems first.
> 
> [...]
> I'll remove it from the next version.

Please don't. It would be a shame if we would *not* recommend to use the
awesome Salsa CI pipeline for automated continuous testing of package
development. I applaud the Salsa-CI's team for their effort, it's a huge
step forwart for Debians QA standards.

I also honestly appreciate all the hard work that the Salsa admins put
into running Salsa, but it's absolutely not acceptable how they try to
missuse the power of their role by behaving as Salsa dictators.

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Russ Allbery]

Wouter Verhelst  writes:
> On Sun, Sep 15, 2019 at 01:16:26AM +0200, Thomas Goirand wrote:

>> However, basically, what you're saying is that, for those who care
>> about not using non-free platforms, we should just not do that anymore,
>> as it's not required anyway.

> No.

> If this were about a non-free Subversion hosting service, then yes, I'd
> agree.

Even if someone were using a non-free Subversion hosting service for their
personal convenience in maintaining the package, there's still the fact
that we don't mandate that maintainers use *any* particular tools to
maintain a package.  The source package as uploaded to the archive is the
basis of Debian development currently.

If someone wants to download the source package, edit it with a text
editor, build a new source package, and upload it without ever using a VCS
of any kind, they can.  Therefore, I think we need to apply an "as-if"
rule here.  If the impact on the archive is indistinguishable from someone
using no tools at all, I'm not seeing what *policy* someone would be
violating.

We could ask them to not use a Vcs-Svn field pointing to a non-free
hosting service on the grounds that it's advertising non-free software
(I've never been that fond of the FSF's stance on this sort of thing and
am dubious about us adopting it, but there's certainly a defensible
argument), but we should be aware that they could just delete the Vcs-Svn
field from the source package while changing nothing else about their
workflow and they're then entirely compatible with our policies.

Taking a step back, what I'm objecting to here is that I think people are
implicitly extending the definition of a source package to include the VCS
and implicitly assuming that we're going to require people to use a VCS,
but are not saying that explicitly.  (To be fair, Ian *is* saying that
explicitly, which I think makes everything clearer and more
straightforward, and lets us have an argument on the merits.  But I think
the merits of a *requirement*, as opposed to a recommendation, are weak as
currently framed, without a bunch more work to use standardized Git branch
layouts and facilities for global changes.)

We have to decide if the VCS used for maintaining a Debian package is in
scope for our policies and procedures or not.  Currently, it is not, so
telling people what Git hosting service they can use is out of scope in
exactly the same way that we don't tell people what text editor they use
to change Debian packaging files.

If we're going to bring it in scope, this implies a bunch of other things
that people may or may not want, which is why we need to talk about it
directly.  For instance, it implies that we'll have an acceptable list of
VCSes.  It also raises the question of what we expect to put in that VCS;
in other words, how is using a VCS any different than the Debian archive
right now?  What are we gaining by adding this requirement?  If someone
made all the changes they wanted to make between uploads as a single
commit, would that be acceptable?  If they made a lot of separate commits
and then did a squash rebase so that all the changes were a single commit,
would that be acceptable?

And if those are acceptable, note that dgit already reconstructs exactly
that sort of Git reopsitory from the archive.  So why does the maintainer
have to do anything different if dgit is already constructing that
archive?  What are we trying to accomplish by making policy here?

I think people aren't thinking through the implications of making this a
requirement rather than a recommendation, and the edge cases that we then
create.  It feels very knee-jerk: "non-free hosting is bad," without
thinking about whether that has any actual implications for the project or
for the workflows of other developers.

I'm assuming that the project *isn't* trying to go to the extent of
telling people they're not allowed to use non-free editors to make changes
to their Debian packages.  I think people need to consider whether they
want to create bugs that are resolvable by just deleting the Vcs-* fields
without making any other changes, and if that really achieves anything
meaningful for the project.

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

Bug#940329: (no subject)

[Andreas Noteng]

Package: wnpp
Severity: wishlist
Owner: Andreas Noteng 

* Package name: scantailor-advanced
  Version : 1.0.17~2019.08.16-1
  Upstream Author : 4lex4 <4le...@zoho.com> 
* URL : https://github.com/4lex4/scantailor-advanced/
* License : GPL3+
  Programming Lang: C++
  Description : Interactive post-processing tool for scanned pages

Scan Tailor is an interactive post-processing tool for scanned pages. It
performs operations such as page splitting, deskewing, adding/removing
borders, and others. You give it raw scans, and you get pages ready to be
printed or assembled into a PDF or DJVU file. Scanning, optical character
recognition, and assembling multi-page documents are out of scope of this
project.

The current scantailor package in Debain is removed from stable and
testing due to it blocking QT4-removal (#875176). The project is not
dead upstream, but development is going slow. Scantailor Advanced is a
fork that uses QT5, and also includes some extended features.

Bug#940318: ITP: lwt-log -- Lwt-friendly logging library

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 

* Package name: lwt-log
  Version : 1.1.1
  Upstream Author : Shawn Wagner and Jérémie Dimino
* URL : https://github.com/ocsigen/lwt_log
* License : LGPL-2.0+
  Programming Lang: OCaml
  Description : Lwt-friendly logging library

 Lwt_log is a Lwt-friendly logging library. The library is split into
 two ocamlfind packages. The "basic" lwt_log includes Unix log
 destination support, such as files and syslog, and
 Lwt_daemon. lwt_log.core is the pure-OCaml part of lwt_log, suitable
 for targeting JavaScript in the browser, or elsewhere where Unix is
 not available.

This is a new dependency of lambda-term and obus.

It will be maintained in ocaml-team.

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Balasankar "Balu" C]

Hi,

On 15/9/19 3:31 AM, Thomas Goirand wrote:
> On 9/14/19 6:59 AM, Balasankar "Balu" C wrote:
>> But it shouldn't matter to the project that I do my packaging work in
>> GitLab.com or GitHub.com because as far as Debian is concerned, as long
>> as others can contribute without having an account in that service - I
>> should not be forbidden using them. That is, if I come in and say "I
>> won't accept any patches submitted over BTS, but only GitHub PRs", the
>> project has every right to kick the package out of Debian or fork it.
>> But as long as I continue supporting people using BTS, I should be fine
>> using whatever I want as my primary platform.
> 
> Could you explain why you'd have VCS fields then, if not to advertise
> what the addres of your Git? Isn't this an invitation to use the
> platform you're pointing at, as a mean to modify your package?

My understanding is that it is an additional avenue for people to get
more details about a package, how it is managed, and/or to contribute to
the work. It does not automatically override BTS as a place to file
issues or contribute patches to. That is still there.

> 
>> So will the GR be
>> "You must not do any sort of contribution to Debian using non-free
>> software/hardware"
>>
>> or
>>
>> "You can use anything you want to contribute to Debian, but there should
>> be a way for other people to contribute to your work in Debian without
>> compromising on their freedom" ? (This translates to my words in the
>> beginning of this reply - patches over BTS must not be rejected by a
>> maintainer)
> 
> Of course, the later. I don't care if a contributor is using Debian in a
> VM running on Windows, as long as he/she doesn't force me to do the
> same. That's the same spirit with using a non-free Git platform.

Thanks for clarifying - from reading your initial mail what I understood
was that you meant the former. I stand corrected in my understanding.

> 
> It is a real life experience that I had to touch horribly maintained
> packages by unknown contributors, with Vcs-Git:
> https://github.com//, missing commits not matching the
> archive, and no response from the maintainer to the BTS (even for RC
> bugs). 

Isn't this why we have an NMU process (for the package and an MIA
process for the maintainer). Personally, I consider Debian archive and
BTS as the single source of truth for any package in Debian - yet.

Regards
Balu

Re: Git Packaging Round 2: When to Salsa

[Balasankar "Balu" C]

Hi,

On 15/9/19 1:27 PM, Bastian Blank wrote:

>> Are there additional resources either the salsa admins or the salsa CI
>> team needs to move forward to a place where you'd both feel comfortable
>> recommending Salsa CI?
> 
> We need to sit down and disuss between the admins first what we exactly
> require and where we want to go in the future, which is some sort of a
> problem right now.
> 
> But basically the Salsa CI stuff needs to reduce the resource usage in
> various stages as Salsa simply lacks them.
> 
> Salsa is also in a weird state.  It's both a large and a small GitLab
> installation.  This is source of a lot of those problems.

[With both my GitLab employee hat and Debian Developer hat on]
Let me know if I can help in any way. :)

> 
> It is large.  Salsa is one of the largest public accessible GitLab
> instances.  The only other I know, git.drupalcode.com, which contains
> more projects, is technically a GitLab, but is only used as git web
> interface.

There's also GitLab.com, but I understand what you meant. :)

Regards
Balu

Re: Git Packaging Round 2: When to Salsa

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

>>> 
>>> I would already assume any branch prefixed with 'wip' might be
>>> rebased myself, but others might be surprised.
>> 
>> I would like to have this documented somewhere so that people
>> dont get surprised. I am not particularly fond of the wip-prefix
>> though and would appreciate better suggestions.

Sean> Maybe just go ahead and add it to the salsa wiki page, if
Sean> no-one objects in this subthread for a few days?

Sean> rebasing/ wip/ tmp/ work/

That makes sense to me.  It sounds like documenting this has a path
forward and so I'm not tracking it further.

--Sam

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Wouter Verhelst]

On Sun, Sep 15, 2019 at 01:16:26AM +0200, Thomas Goirand wrote:
> On 9/15/19 12:06 AM, Scott Kitterman wrote:
> > There's nothing that requires you to interact with a VCS repository that 
> > you 
> > don't care to.
> 
> But I do care about using Git, and interacting with other DDs using it.

Cool.

> However, basically, what you're saying is that, for those who care about
> not using non-free platforms, we should just not do that anymore, as
> it's not required anyway.

No.

If this were about a non-free Subversion hosting service, then yes, I'd
agree. But we're talking about git here, which is a distributed VCS
service.

If you don't want to deal with a non-free hosting service, you can:

- Clone the git repository.
- Push it to the free git hosting service of your choice.
- Push a branch to that git hosting service with the changes you wish to
  make.
- Use git request-pull to send a pull request to the maintainer.

(Alternatively, if using salsa, for the first two steps you can use the
"mirror repository" feature of GitLab)

> That's simply not fair: I care more about software freedom, and
> therefore, I'd be left aside, not being able to use Git when
> interacting with others.

Except you're not.

The above will require that the maintainer on the non-free hosting
service do some more work, yes; that's correct. However, "git
request-pull" will explain to that maintainer how to do that work, and
it's their own fault for using a non-free service to begin with.

-- 
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: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Wouter Verhelst]

On Sun, Sep 15, 2019 at 12:01:24AM +0200, Thomas Goirand wrote:
> It is a real life experience that I had to touch horribly maintained
> packages by unknown contributors, with Vcs-Git:
> https://github.com//, missing commits not matching the
> archive, and no response from the maintainer to the BTS (even for RC
> bugs). The last occurrence of this was pyroute2, which I pushed into the
> DPMT (and still no reply from that past maintainer). I hate seeing this,
> and don't want this anymore, though it happens again, and again, and
> again. So, the only way to get out of this is enforcement, like it or not..

I resent the implication that Vcs-Git: pointing to github.com implies
badly maintained packages.

Badly maintained packages can also have a Vcs-Git: pointing to
gitlab.com or salsa.d.o. Same for ignored bugs in the BTS, unresponsive
maintainers, or incomplete git repositories. None of this has anything
to do with the git hosting service in use.

Enforcing things can help in avoiding those issues, but then make sure
you enforce the correct thing. "Stuff must not point to github.com" is
not that.

Instead, we could make it policy that:
- incomplete git repositories should be considered an RC bug
- RC bugs in the BTS will get your package removed from Debian
- Badly maintained packages will result in RC bugs
- unresponsive packagers will get their packages removed from them.

Luckily we already do most of those.

-- 
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)?

[Amir H. Firouzian]

Debian doesn't add ESNI Record into it's Name Server.

Check here (ONLINE dig):
https://toolbox.googleapps.com/apps/dig/#TXT/

Check these two domains:
_esni.debian.org
_esni.cloudflare.com

On Sun, Sep 15, 2019 at 5:31 AM Paul Wise  wrote:
>
> On Sun, Sep 15, 2019 at 5:48 AM Anthony DeRobertis wrote:
> > On 9/13/19 7:05 AM, Simon Richter wrote:
> > >
> > > Mandatory Encrypted SNI with no fallback option -- everything else can be
> > > circumvented easily.
> > >
> > > This is a game that we should not play, really. It raises the cost of
> > > running a service on the Internet so only big players can afford to do so.
> >
> > Does it? I haven't personally deployed it yet anywhere, but when I
> > briefly looked into it, it appears to require adding a DNS record & some
> > web server config. If anything, it appears to be harder to do if you're
> > a big player (e.g., making sure your DNS servers always return matching
> > ESNI and A/ records, even when you have geo-targeted DNS — so much
> > easier when you only have one server.)
>
> Does anyone know if any software in Debian supports ESNI records?
>
> Looking at the RFC draft, it sounds like adding ESNI records to
> debian.org would basically duplicate the DANE records debian.org
> already has. sigh
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1
> https://serverfault.com/questions/976377/how-can-i-set-up-encrypted-sni-on-my-own-servers
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>

Re: Git Packaging Round 2: When to Salsa

[Marc Haber]

On Sun, 15 Sep 2019 00:04:14 +0200, Guillem Jover 
wrote:
>On Sat, 2019-09-14 at 13:07:09 +0200, Marc Haber wrote:
>> On Fri, 13 Sep 2019 13:05:20 -0700, Sean Whitton wrote:
>> > On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:
>> > > 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?
>> >
>> > This would be useful.
>> >
>> > I would already assume any branch prefixed with 'wip' might be rebased
>> > myself, but others might be surprised.
>> 
>> I would like to have this documented somewhere so that people dont get
>> surprised. I am not particularly fond of the wip-prefix though and
>> would appreciate better suggestions.
>
>I think the common prefixes for these are pu/ and next/? These are
>also documented somehow in the gitworkflows(7) man page.

The definition of those prefixes doesn't contain language like "might
be rebased and force-pushed any time".

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

[Bastian Blank]

On Sun, Sep 15, 2019 at 09:57:15AM +0200, Bastian Blank wrote:
> On Fri, Sep 13, 2019 at 12:00:37PM -0400, Sam Hartman wrote:
> > Bastian> For this I need to use my veto as Salsa admin.  With the CI
> > Bastian> people we have to work through too much problems first.

After thinking about it again, let's rephrase this.  I hope this is
better.

| As Salsa admin, I object the inclusion of Salsa CI into the
| recommendation.

Regards,
Bastian

-- 
"Life and death are seldom logical."
"But attaining a desired goal always is."
-- McCoy and Spock, "The Galileo Seven", stardate 2821.7

Re: Git Packaging Round 2: When to Salsa

[Bastian Blank]

On Fri, Sep 13, 2019 at 12:00:37PM -0400, Sam Hartman wrote:
> Bastian> For this I need to use my veto as Salsa admin.  With the CI
> Bastian> people we have to work through too much problems first.
> What I am hearing you say is that right now, as service admins, you
> cannot support the CI pipeline being used that widely.  I confirm that's
> absolutely a call you get to make as a service adminand that forms a
> blocking objection to recommending that now.
> I'll remove it from the next version.

Thanks.

> Are there additional resources either the salsa admins or the salsa CI
> team needs to move forward to a place where you'd both feel comfortable
> recommending Salsa CI?

We need to sit down and disuss between the admins first what we exactly
require and where we want to go in the future, which is some sort of a
problem right now.

But basically the Salsa CI stuff needs to reduce the resource usage in
various stages as Salsa simply lacks them.

Salsa is also in a weird state.  It's both a large and a small GitLab
installation.  This is source of a lot of those problems.

It is large.  Salsa is one of the largest public accessible GitLab
instances.  The only other I know, git.drupalcode.com, which contains
more projects, is technically a GitLab, but is only used as git web
interface.

It is small.  Salsa is a let's lump all together installation, without
any real separation in terms of resource usage.  This means that
problems in one part quickly break others as well.

> Beyond that though, I think the term "veto" here tends to shut down
> discussion in a way that is not good for the project.

Yeah, it sounded wrong too, but I failed to find something different.

> I think it's fine for you to veto something today.  But I'd encourage
> you to do that in a manner that does not shutdown discussion about the
> future while still being firm about what part of that future you're
> interested in bringing about.

I don't want to shut up any discussion.  It's just that we have not yet
managed to talk through the last outage, which was caused directly by
the Salsa CI and how it does things.

Regards,
Bastian

-- 
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3

Re: Git Packaging Round 2: When to Salsa

[Ansgar]

Anthony DeRobertis writes:
> On 9/12/19 8:57 AM, Ansgar wrote:
>> 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.
>
> Working with packages downstream it's nice to have that
> documented. E.g., needing to patch something for a weird site
> requirement, or backport a fix that isn't a big deal for anyone else
> (so likely wouldn't qualify for a stable update), etc. Not everyone
> who wants to modify a package is familiar with the multitude of ways
> of maintaining packages.

As long as you only need to touch the more trivial parts of the package
and not the upstream source.  There are many more ways to organize
upstream sources; more conventions (for different programming
languages); more workflows; code style conventions; ...

Most of the variance in Debian packaging is much less than what one
would encounter outside of the packaging-specific bits.

Ansgar