tag:debian.2.n7.nabble.com,2006:forum-971570Nabble - Debian Devel2019-09-15T06:28:20Ztag:debian.2.n7.nabble.com,2006:post-4569345Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-15T04:18:08Z2019-09-15T04:18:08ZWouter Verhelst
On Sun, Sep 15, 2019 at 01:16:26AM +0200, Thomas Goirand wrote:
<br/>&gt; On 9/15/19 12:06 AM, Scott Kitterman wrote:
<br/>&gt; &gt; There's nothing that requires you to interact with a VCS repository that you
<br/>&gt; &gt; don't care to.
<br/>&gt;
<br/>&gt; But I do care about using Git, and interacting with other DDs using it.
<br/><br/>Cool.
<br/><br/>&gt; However, basically, what you're saying is that, for those who care about
<br/>&gt; not using non-free platforms, we should just not do that anymore, as
<br/>&gt; it's not required anyway.
<br/><br/>No.
<br/><br/>If this were about a non-free Subversion hosting service, then yes, I'd
<br/>agree. But we're talking about git here, which is a distributed VCS
<br/>service.
<br/><br/>If you don't want to deal with a non-free hosting service, you can:
<br/><br/>- Clone the git repository.
<br/>- Push it to the free git hosting service of your choice.
<br/>- Push a branch to that git hosting service with the changes you wish to
<br/>&nbsp; make.
<br/>- Use git request-pull to send a pull request to the maintainer.
<br/><br/>(Alternatively, if using salsa, for the first two steps you can use the
<br/>&quot;mirror repository&quot; feature of GitLab)
<br/><br/>&gt; That's simply not fair: I care more about software freedom, and
<br/>&gt; therefore, I'd be left aside, not being able to use Git when
<br/>&gt; interacting with others.
<br/><br/>Except you're not.
<br/><br/>The above will require that the maintainer on the non-free hosting
<br/>service do some more work, yes; that's correct. However, &quot;git
<br/>request-pull&quot; will explain to that maintainer how to do that work, and
<br/>it's their own fault for using a non-free service to begin with.
<br/><br/>--
<br/>To the thief who stole my anti-depressants: I hope you're happy
<br/><br/>&nbsp; -- seen somewhere on the Internet on a photo of a billboard
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569335Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-15T04:10:35Z2019-09-15T04:10:35ZWouter Verhelst
On Sun, Sep 15, 2019 at 12:01:24AM +0200, Thomas Goirand wrote:
<br/>&gt; It is a real life experience that I had to touch horribly maintained
<br/>&gt; packages by unknown contributors, with Vcs-Git:
<br/>&gt; <a href="https://github.com/" target="_top" rel="nofollow" link="external">https://github.com/</a>&lt;foo&gt;/&lt;bar&gt;, missing commits not matching the
<br/>&gt; archive, and no response from the maintainer to the BTS (even for RC
<br/>&gt; bugs). The last occurrence of this was pyroute2, which I pushed into the
<br/>&gt; DPMT (and still no reply from that past maintainer). I hate seeing this,
<br/>&gt; and don't want this anymore, though it happens again, and again, and
<br/>&gt; again. So, the only way to get out of this is enforcement, like it or not..
<br/><br/>I resent the implication that Vcs-Git: pointing to github.com implies
<br/>badly maintained packages.
<br/><br/>Badly maintained packages can also have a Vcs-Git: pointing to
<br/>gitlab.com or salsa.d.o. Same for ignored bugs in the BTS, unresponsive
<br/>maintainers, or incomplete git repositories. None of this has anything
<br/>to do with the git hosting service in use.
<br/><br/>Enforcing things can help in avoiding those issues, but then make sure
<br/>you enforce the correct thing. &quot;Stuff must not point to github.com&quot; is
<br/>not that.
<br/><br/>Instead, we could make it policy that:
<br/>- incomplete git repositories should be considered an RC bug
<br/>- RC bugs in the BTS will get your package removed from Debian
<br/>- Badly maintained packages will result in RC bugs
<br/>- unresponsive packagers will get their packages removed from them.
<br/><br/>Luckily we already do most of those.
<br/><br/>--
<br/>To the thief who stole my anti-depressants: I hope you're happy
<br/><br/>&nbsp; -- seen somewhere on the Internet on a photo of a billboard
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569322Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?2019-09-15T03:25:13Z2019-09-15T03:25:13ZAmir H. Firouzian
Debian doesn't add ESNI Record into it's Name Server.
<br/><br/>Check here (ONLINE dig):
<br/><a href="https://toolbox.googleapps.com/apps/dig/#TXT/" target="_top" rel="nofollow" link="external">https://toolbox.googleapps.com/apps/dig/#TXT/</a><br/><br/>Check these two domains:
<br/>_esni.debian.org
<br/>_esni.cloudflare.com
<br/><br/>On Sun, Sep 15, 2019 at 5:31 AM Paul Wise &lt;<a href="/user/SendEmail.jtp?type=node&node=4569322&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt; wrote:
<div class='shrinkable-quote'><br/>&gt;
<br/>&gt; On Sun, Sep 15, 2019 at 5:48 AM Anthony DeRobertis wrote:
<br/>&gt; &gt; On 9/13/19 7:05 AM, Simon Richter wrote:
<br/>&gt; &gt; &gt;
<br/>&gt; &gt; &gt; Mandatory Encrypted SNI with no fallback option -- everything else can be
<br/>&gt; &gt; &gt; circumvented easily.
<br/>&gt; &gt; &gt;
<br/>&gt; &gt; &gt; This is a game that we should not play, really. It raises the cost of
<br/>&gt; &gt; &gt; running a service on the Internet so only big players can afford to do so.
<br/>&gt; &gt;
<br/>&gt; &gt; Does it? I haven't personally deployed it yet anywhere, but when I
<br/>&gt; &gt; briefly looked into it, it appears to require adding a DNS record &amp; some
<br/>&gt; &gt; web server config. If anything, it appears to be harder to do if you're
<br/>&gt; &gt; a big player (e.g., making sure your DNS servers always return matching
<br/>&gt; &gt; ESNI and A/AAAA records, even when you have geo-targeted DNS — so much
<br/>&gt; &gt; easier when you only have one server.)
<br/>&gt;
<br/>&gt; Does anyone know if any software in Debian supports ESNI records?
<br/>&gt;
<br/>&gt; Looking at the RFC draft, it sounds like adding ESNI records to
<br/>&gt; debian.org would basically duplicate the DANE records debian.org
<br/>&gt; already has..... sigh
<br/>&gt;
<br/>&gt; <a href="https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1" target="_top" rel="nofollow" link="external">https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1</a><br/>&gt; <a href="https://serverfault.com/questions/976377/how-can-i-set-up-encrypted-sni-on-my-own-servers" target="_top" rel="nofollow" link="external">https://serverfault.com/questions/976377/how-can-i-set-up-encrypted-sni-on-my-own-servers</a><br/>&gt;
<br/>&gt; --
<br/>&gt; bye,
<br/>&gt; pabs
<br/>&gt;
<br/>&gt; <a href="https://wiki.debian.org/PaulWise" target="_top" rel="nofollow" link="external">https://wiki.debian.org/PaulWise</a><br/>&gt;
</div><br/>
tag:debian.2.n7.nabble.com,2006:post-4569321Re: Git Packaging Round 2: When to Salsa2019-09-15T03:23:48Z2019-09-15T03:23:48ZMarc Haber-3
On Sun, 15 Sep 2019 00:04:14 +0200, Guillem Jover &lt;<a href="/user/SendEmail.jtp?type=node&node=4569321&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt;
<br/>wrote:
<div class='shrinkable-quote'><br/>&gt;On Sat, 2019-09-14 at 13:07:09 +0200, Marc Haber wrote:
<br/>&gt;&gt; On Fri, 13 Sep 2019 13:05:20 -0700, Sean Whitton wrote:
<br/>&gt;&gt; &gt; On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:
<br/>&gt;&gt; &gt; &gt; How about documenting that branches prefixed with &quot;wip&quot; can be force
<br/>&gt;&gt; &gt; &gt; pushed any time and people pulling from those branches should be
<br/>&gt;&gt; &gt; &gt; expected to handle that?
<br/>&gt;&gt; &gt;
<br/>&gt;&gt; &gt; This would be useful.
<br/>&gt;&gt; &gt;
<br/>&gt;&gt; &gt; I would already assume any branch prefixed with 'wip' might be rebased
<br/>&gt;&gt; &gt; myself, but others might be surprised.
<br/>&gt;&gt;
<br/>&gt;&gt; I would like to have this documented somewhere so that people dont get
<br/>&gt;&gt; surprised. I am not particularly fond of the wip-prefix though and
<br/>&gt;&gt; would appreciate better suggestions.
<br/>&gt;
<br/>&gt;I think the common prefixes for these are pu/ and next/? These are
<br/>&gt;also documented somehow in the gitworkflows(7) man page.
</div><br/>The definition of those prefixes doesn't contain language like &quot;might
<br/>be rebased and force-pushed any time&quot;.
<br/><br/>Greetings
<br/>Marc
<br/>--
<br/>-------------------------------------- !! No courtesy copies, please !! -----
<br/>Marc Haber &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &quot; Questions are the &nbsp; &nbsp; &nbsp; &nbsp; | Mailadresse im Header
<br/>Mannheim, Germany &nbsp;| &nbsp; &nbsp; Beginning of Wisdom &quot; &nbsp; &nbsp; |
<br/>Nordisch by Nature | Lt. Worf, TNG &quot;Rightful Heir&quot; | Fon: *49 621 72739834
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569294Re: Git Packaging Round 2: When to Salsa2019-09-15T01:23:06Z2019-09-15T01:23:06ZBastian Blank
On Sun, Sep 15, 2019 at 09:57:15AM +0200, Bastian Blank wrote:
<br/>&gt; On Fri, Sep 13, 2019 at 12:00:37PM -0400, Sam Hartman wrote:
<br/>&gt; &gt; &nbsp; &nbsp; Bastian&gt; For this I need to use my veto as Salsa admin. &nbsp;With the CI
<br/>&gt; &gt; &nbsp; &nbsp; Bastian&gt; people we have to work through too much problems first.
<br/><br/>After thinking about it again, let's rephrase this. &nbsp;I hope this is
<br/>better.
<br/><br/>| As Salsa admin, I object the inclusion of Salsa CI into the
<br/>| recommendation.
<br/><br/>Regards,
<br/>Bastian
<br/><br/>--
<br/>&nbsp; &nbsp; &nbsp; &nbsp; &quot;Life and death are seldom logical.&quot;
<br/>&nbsp; &nbsp; &nbsp; &nbsp; &quot;But attaining a desired goal always is.&quot;
<br/>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -- McCoy and Spock, &quot;The Galileo Seven&quot;, stardate 2821.7
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569290Re: Git Packaging Round 2: When to Salsa2019-09-15T01:09:38Z2019-09-15T01:09:38ZAnsgar
Anthony DeRobertis writes:
<div class='shrinkable-quote'><br/>&gt; On 9/12/19 8:57 AM, Ansgar wrote:
<br/>&gt;&gt; I don't see much value in this requirement (besides additional work).
<br/>&gt;&gt; One should look at the repository anyway whan planning to do changes
<br/>&gt;&gt; (to match the existing style used); one would naturally see how files
<br/>&gt;&gt; are organized. &nbsp;We already had tons of packages shipping a
<br/>&gt;&gt; README.source stating &quot;this packages uses quilt, ...&quot; before which I
<br/>&gt;&gt; also didn't find very valuable; this seems pretty similar.
<br/>&gt;
<br/>&gt; Working with packages downstream it's nice to have that
<br/>&gt; documented. E.g., needing to patch something for a weird site
<br/>&gt; requirement, or backport a fix that isn't a big deal for anyone else
<br/>&gt; (so likely wouldn't qualify for a stable update), etc. Not everyone
<br/>&gt; who wants to modify a package is familiar with the multitude of ways
<br/>&gt; of maintaining packages.
</div><br/>As long as you only need to touch the more trivial parts of the package
<br/>and not the upstream source. &nbsp;There are many more ways to organize
<br/>upstream sources; more conventions (for different programming
<br/>languages); more workflows; code style conventions; ...
<br/><br/>Most of the variance in Debian packaging is much less than what one
<br/>would encounter outside of the packaging-specific bits.
<br/><br/>Ansgar
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569291Re: Git Packaging Round 2: When to Salsa2019-09-15T00:57:15Z2019-09-15T00:57:15ZBastian Blank
On Fri, Sep 13, 2019 at 12:00:37PM -0400, Sam Hartman wrote:
<br/>&gt; &nbsp; &nbsp; Bastian&gt; For this I need to use my veto as Salsa admin. &nbsp;With the CI
<br/>&gt; &nbsp; &nbsp; Bastian&gt; people we have to work through too much problems first.
<br/>&gt; What I am hearing you say is that right now, as service admins, you
<br/>&gt; cannot support the CI pipeline being used that widely. &nbsp;I confirm that's
<br/>&gt; absolutely a call you get to make as a service adminand that forms a
<br/>&gt; blocking objection to recommending that now.
<br/>&gt; I'll remove it from the next version.
<br/><br/>Thanks.
<br/><br/>&gt; Are there additional resources either the salsa admins or the salsa CI
<br/>&gt; team needs to move forward to a place where you'd both feel comfortable
<br/>&gt; recommending Salsa CI?
<br/><br/>We need to sit down and disuss between the admins first what we exactly
<br/>require and where we want to go in the future, which is some sort of a
<br/>problem right now.
<br/><br/>But basically the Salsa CI stuff needs to reduce the resource usage in
<br/>various stages as Salsa simply lacks them.
<br/><br/>Salsa is also in a weird state. &nbsp;It's both a large and a small GitLab
<br/>installation. &nbsp;This is source of a lot of those problems.
<br/><br/>It is large. &nbsp;Salsa is one of the largest public accessible GitLab
<br/>instances. &nbsp;The only other I know, git.drupalcode.com, which contains
<br/>more projects, is technically a GitLab, but is only used as git web
<br/>interface.
<br/><br/>It is small. &nbsp;Salsa is a let's lump all together installation, without
<br/>any real separation in terms of resource usage. &nbsp;This means that
<br/>problems in one part quickly break others as well.
<br/><br/>&gt; Beyond that though, I think the term &quot;veto&quot; here tends to shut down
<br/>&gt; discussion in a way that is not good for the project.
<br/><br/>Yeah, it sounded wrong too, but I failed to find something different.
<br/><br/>&gt; I think it's fine for you to veto something today. &nbsp;But I'd encourage
<br/>&gt; you to do that in a manner that does not shutdown discussion about the
<br/>&gt; future while still being firm about what part of that future you're
<br/>&gt; interested in bringing about.
<br/><br/>I don't want to shut up any discussion. &nbsp;It's just that we have not yet
<br/>managed to talk through the last outage, which was caused directly by
<br/>the Salsa CI and how it does things.
<br/><br/>Regards,
<br/>Bastian
<br/><br/>--
<br/>You can't evaluate a man by logic alone.
<br/>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -- McCoy, &quot;I, Mudd&quot;, stardate 4513.3
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569269Re: should Debian add itself to https://python3statement.org ?2019-09-14T22:40:14Z2019-09-14T22:40:14ZDrew Parsons
On 2019-09-12 22:46, Drew Parsons wrote:
<div class='shrinkable-quote'><br/>&gt; <a href="https://python3statement.org/" target="_top" rel="nofollow" link="external">https://python3statement.org/</a>&nbsp;is a site documenting the projects which
<br/>&gt; are supporting the policy of dropping Python2 to keep Python3 only.
<br/>&gt;
<br/>&gt; The site is designed for python packages specifically, to have only
<br/>&gt; Python3 supported by end of 2020.
<br/>&gt;
<br/>&gt; But it seems to me it would be in the spirit of the site to add
<br/>&gt; Debian's pledge to remove Python2 (we are currently in the middle of
<br/>&gt; doing just that).
<br/>&gt;
<br/>&gt; Is this a thing that we want to do as a project, to add Debian to
<br/>&gt; <a href="https://python3statement.org/" target="_top" rel="nofollow" link="external">https://python3statement.org/</a>&nbsp;?
</div><br/><br/>Thanks all for the discussion.
<br/><br/>Looks like we don't have consensus for listing on python3statement.org. &nbsp;
<br/>As a whole-system distribution, we're running on a different timeframe
<br/>to the individual python packages.
<br/><br/>But in any case, the process of removing python2 packages from Debian is
<br/>underway. By end of 2020 we might be able to judge whether it will be a
<br/>Release Target for bullseye.
<br/><br/>Drew
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569249Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T19:28:03Z2019-09-14T19:28:03ZPirate Praveen-3
<br/><br/>On 2019, സെപ്റ്റംബർ 15 12:57:08 AM IST, Sean Whitton &lt;<a href="/user/SendEmail.jtp?type=node&node=4569249&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt; wrote:
<div class='shrinkable-quote'><br/>&gt;Hello Pirate,
<br/>&gt;
<br/>&gt;On Sun 15 Sep 2019 at 12:27AM +0530, Pirate Praveen wrote:
<br/>&gt;
<br/>&gt;&gt; That is not going to happen, instead we need to adapt ourselves to
<br/>&gt;&gt; this fast paced development and fasttrack.debian.net is a step in
<br/>&gt;that
<br/>&gt;&gt; direction.
<br/>&gt;
<br/>&gt;It's not just a matter of adapting workflows -- without real stable
<br/>&gt;releases, however good your workflows are, packaging GitLab and
<br/>&gt;administering GitLab installations demands more of people's time than
<br/>&gt;it
<br/>&gt;would if there were real stable releases.
<br/>&gt;
<br/>&gt;Real stable releases are freedom-enhancing when they free up people's
<br/>&gt;time to work on other stuff.
</div><br/>Well, gitlab is not the only git based collaboration platform out there. I'm sure some of the alternatives will have a longer release cycle compatible with Debian stable releases. Those who care about it can certainly contribute to those and promote them. The fast paced development also means it brings out new features faster and apparently many people take that tradeoff currently with gitlab (not just Debian, other Free Software projects like gnome, KDE are either moved or moving to gitlab).
<br/><br/>Also if there is a strong interest in LTS releases, gitlab is Free Software and others can maintain backports of security releases.
<br/>--
<br/>Sent from my Android device with K-9 Mail. Please excuse my brevity.
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569230Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?2019-09-14T18:00:33Z2019-09-14T18:00:33ZPaul Wise via nm
On Sun, Sep 15, 2019 at 5:48 AM Anthony DeRobertis wrote:
<div class='shrinkable-quote'><br/>&gt; On 9/13/19 7:05 AM, Simon Richter wrote:
<br/>&gt; &gt;
<br/>&gt; &gt; Mandatory Encrypted SNI with no fallback option -- everything else can be
<br/>&gt; &gt; circumvented easily.
<br/>&gt; &gt;
<br/>&gt; &gt; This is a game that we should not play, really. It raises the cost of
<br/>&gt; &gt; running a service on the Internet so only big players can afford to do so.
<br/>&gt;
<br/>&gt; Does it? I haven't personally deployed it yet anywhere, but when I
<br/>&gt; briefly looked into it, it appears to require adding a DNS record &amp; some
<br/>&gt; web server config. If anything, it appears to be harder to do if you're
<br/>&gt; a big player (e.g., making sure your DNS servers always return matching
<br/>&gt; ESNI and A/AAAA records, even when you have geo-targeted DNS — so much
<br/>&gt; easier when you only have one server.)
</div><br/>Does anyone know if any software in Debian supports ESNI records?
<br/><br/>Looking at the RFC draft, it sounds like adding ESNI records to
<br/>debian.org would basically duplicate the DANE records debian.org
<br/>already has..... sigh
<br/><br/><a href="https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1" target="_top" rel="nofollow" link="external">https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1</a><br/><a href="https://serverfault.com/questions/976377/how-can-i-set-up-encrypted-sni-on-my-own-servers" target="_top" rel="nofollow" link="external">https://serverfault.com/questions/976377/how-can-i-set-up-encrypted-sni-on-my-own-servers</a><br/><br/>--
<br/>bye,
<br/>pabs
<br/><br/><a href="https://wiki.debian.org/PaulWise" target="_top" rel="nofollow" link="external">https://wiki.debian.org/PaulWise</a><br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569222Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T17:14:15Z2019-09-14T17:14:15ZAlexis Murzeau-3
<br/><br/>On September 15, 2019 1:20:38 AM GMT+02:00, Scott Kitterman &lt;<a href="/user/SendEmail.jtp?type=node&node=4569222&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt; wrote:
<div class='shrinkable-quote'><br/>&gt;&gt; Besides this, there's something else I don't understand. How much
<br/>&gt;effort
<br/>&gt;&gt; is it to use a free software based platform? It's not as if Github
<br/>&gt;was
<br/>&gt;&gt; so much nicer than Gitlab (at least not anymore). What is it that
<br/>&gt;people
<br/>&gt;&gt; hate about Gitlab so much, that they feel like they must use some
<br/>&gt;&gt; non-free platform, even if they know some of us will hate it?
<br/>&gt;
<br/>&gt;I don't know. &nbsp;I don't use GitHub except as needed to support
<br/>&gt;collaboration
<br/>&gt;with others that use it. &nbsp;I think that 7% is too large a number just to
<br/>&gt;assume
<br/>&gt;there's not a reason.
</div><br/>Speaking for myself, I'm currently using github as git repository for streamlink because salsa wasn't there when I started its packaging, and I was already familiar with it.
<br/>I could have swithed over to salsa before but didn't. For sure, I don't mind about switching now and probably will do.
<br/>I consider salsa as a comparable alternative to github functionality wise now, with the benefit that the git repo used for package development being internal to debian (in constrast to lost VCS of old packages that got lost)
<br/><br/>Now that there is salsa, I guess many package could move to it.
<br/><br/>Maybe a reason to use github, is travis.ci that can be used with github only IIRC. But I'm not using that functionality with debian package repository anymore in my case. Salsa gitlab's CI can be an alternative but for me debci is sufficient. and I run sbuild before pushing/releasing a version.
<br/><br/>--
<br/>Alexis Murzeau
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569221Bug#820036: marked as done (Boot and installation support for Secure Boot systems)2019-09-14T17:12:03Z2019-09-14T17:12:03ZDebian Bug Tracking System
Your message dated Sat, 14 Sep 2019 18:12:31 +0100
<br/>with message-id &lt;<a href="/user/SendEmail.jtp?type=node&node=4569221&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt;
<br/>and subject line Re: Boot and installation support for Secure Boot systems
<br/>has caused the Debian Bug report #820036,
<br/>regarding Boot and installation support for Secure Boot systems
<br/>to be marked as done.
<br/><br/>This means that you claim that the problem has been dealt with.
<br/>If this is not the case it is now your responsibility to reopen the
<br/>Bug report if necessary, and/or fix the problem forthwith.
<br/><br/>(NB: If you are a system administrator and have no idea what this
<br/>message is talking about, this may indicate a serious mail system
<br/>misconfiguration somewhere. Please contact <a href="/user/SendEmail.jtp?type=node&node=4569221&i=1" target="_top" rel="nofollow" link="external">[hidden email]</a>
<br/>immediately.)
<br/><br/><br/>--
<br/>820036: <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820036" target="_top" rel="nofollow" link="external">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820036</a><br/>Debian Bug Tracking System
<br/>Contact <a href="/user/SendEmail.jtp?type=node&node=4569221&i=2" target="_top" rel="nofollow" link="external">[hidden email]</a> with problems
<br/><br />Package: general
<br/>Severity: important
<br/><br/>Most new desktop/laptop PCs cannot run Debian without the firmware
<br/>being reconfigured to disable Secure Boot. &nbsp;This is a known problem
<br/>that is being worked on, but it hasn't so far been properly recorded
<br/>in the BTS.
<br/><br/>This is a tracking bug which will be marked as blocked by more
<br/>specific bugs in the packages that need changes. &nbsp;Please don't try to
<br/>'tidy it up' by reassigning it - this issue requires changes in many
<br/>packages and by several teams.
<br/><br/>Ben.
<br/><br/>-- System Information:
<br/>Debian Release: stretch/sid
<br/>&nbsp; APT prefers unstable
<br/>&nbsp; APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
<br/>Architecture: amd64 (x86_64)
<br/>Foreign Architectures: i386
<br/><br/>Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
<br/>Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
<br/>Shell: /bin/sh linked to /bin/dash
<br/>Init: systemd (via /run/systemd/system)
<br/><br />Version: 10.0
<br/><br/>All the necessary pieces were included in the buster release.
<br/><br/>Ben.
<br/><br/>--
<br/>Ben Hutchings
<br/>If you seem to know what you are doing, you'll be given more to do.
<br/><br/><br/><!--start-attachments--><div class="small"><br/><img src="http://debian.2.n7.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (849 bytes) <a href="http://debian.2.n7.nabble.com/attachment/4569221/0/signature.asc" target="_top" rel="nofollow" link="external">Download Attachment</a></div><!--end-attachments-->
tag:debian.2.n7.nabble.com,2006:post-4569217Re: Git Packaging Round 2: When to Salsa2019-09-14T16:58:17Z2019-09-14T16:58:17ZAnthony DeRobertis
On 9/12/19 8:57 AM, Ansgar wrote:
<br/>&gt; I don't see much value in this requirement (besides additional work).
<br/>&gt; One should look at the repository anyway whan planning to do changes
<br/>&gt; (to match the existing style used); one would naturally see how files
<br/>&gt; are organized. &nbsp;We already had tons of packages shipping a
<br/>&gt; README.source stating &quot;this packages uses quilt, ...&quot; before which I
<br/>&gt; also didn't find very valuable; this seems pretty similar.
<br/><br/><br/>Working with packages downstream it's nice to have that documented.
<br/>E.g., needing to patch something for a weird site requirement, or
<br/>backport a fix that isn't a big deal for anyone else (so likely wouldn't
<br/>qualify for a stable update), etc. Not everyone who wants to modify a
<br/>package is familiar with the multitude of ways of maintaining packages.
<br/><br/>dgit makes this a lot better, though.
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569214Processed: unblock 820036 with 8210882019-09-14T16:45:04Z2019-09-14T16:45:04ZDebian Bug Tracking System
Processing commands for <a href="/user/SendEmail.jtp?type=node&node=4569214&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>:
<br/><br/>&gt; unblock 820036 with 821088
<br/>Bug #820036 [general] Boot and installation support for Secure Boot systems
<br/>820036 was blocked by: 821307 823003 820052 821084 821054 820129 820041 820038 821055 821088 820008 820010
<br/>820036 was not blocking any bugs.
<br/>Removed blocking bug(s) of 820036: 821088
<br/>&gt; thanks
<br/>Stopping processing here.
<br/><br/>Please contact me if you need assistance.
<br/>--
<br/>820036: <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820036" target="_top" rel="nofollow" link="external">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820036</a><br/>Debian Bug Tracking System
<br/>Contact <a href="/user/SendEmail.jtp?type=node&node=4569214&i=1" target="_top" rel="nofollow" link="external">[hidden email]</a> with problems
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569210Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T16:27:35Z2019-09-14T16:27:35ZThomas Goirand-3
On 9/14/19 9:30 PM, Pirate Praveen wrote:
<br/>&gt; We have packaged many core build tools like webpack, rollup, gulp, grunt etc which makes it easier to build many JavaScript libraries from source
<br/><br/>Thanks a lot for that very useful work!
<br/><br/>Thomas
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569209Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T16:20:38Z2019-09-14T16:20:38ZScott Kitterman-5
On Saturday, September 14, 2019 7:16:26 PM EDT Thomas Goirand wrote:
<div class='shrinkable-quote'><br/>&gt; On 9/15/19 12:06 AM, Scott Kitterman wrote:
<br/>&gt; &gt; On Saturday, September 14, 2019 6:01:24 PM EDT Thomas Goirand wrote:
<br/>&gt; &gt;&gt; On 9/14/19 6:59 AM, Balasankar &quot;Balu&quot; C wrote:
<br/>&gt; &gt;&gt;&gt; So will the GR be
<br/>&gt; &gt;&gt;&gt; &quot;You must not do any sort of contribution to Debian using non-free
<br/>&gt; &gt;&gt;&gt; software/hardware&quot;
<br/>&gt; &gt;&gt;&gt;
<br/>&gt; &gt;&gt;&gt; or
<br/>&gt; &gt;&gt;&gt;
<br/>&gt; &gt;&gt;&gt; &quot;You can use anything you want to contribute to Debian, but there should
<br/>&gt; &gt;&gt;&gt; be a way for other people to contribute to your work in Debian without
<br/>&gt; &gt;&gt;&gt; compromising on their freedom&quot; ? (This translates to my words in the
<br/>&gt; &gt;&gt;&gt; beginning of this reply - patches over BTS must not be rejected by a
<br/>&gt; &gt;&gt;&gt; maintainer)
<br/>&gt; &gt;&gt;
<br/>&gt; &gt;&gt; Of course, the later. I don't care if a contributor is using Debian in a
<br/>&gt; &gt;&gt; VM running on Windows, as long as he/she doesn't force me to do the
<br/>&gt; &gt;&gt; same. That's the same spirit with using a non-free Git platform.
<br/>&gt; &gt;
<br/>&gt; &gt; What you proposed sounded a lot like the former to me and apparently
<br/>&gt; &gt; others.
<br/>&gt; Indeed. Sorry for this (to you, and to all others that wrongly
<br/>&gt; understood what I meant).
<br/>&gt;
<br/>&gt; &gt;&gt; It is a real life experience that I had to touch horribly maintained
<br/>&gt; &gt;&gt; packages by unknown contributors, with Vcs-Git:
<br/>&gt; &gt;&gt; <a href="https://github.com/" target="_top" rel="nofollow" link="external">https://github.com/</a>&lt;foo&gt;/&lt;bar&gt;, missing commits not matching the
<br/>&gt; &gt;&gt; archive, and no response from the maintainer to the BTS (even for RC
<br/>&gt; &gt;&gt; bugs). The last occurrence of this was pyroute2, which I pushed into the
<br/>&gt; &gt;&gt; DPMT (and still no reply from that past maintainer). I hate seeing this,
<br/>&gt; &gt;&gt; and don't want this anymore, though it happens again, and again, and
<br/>&gt; &gt;&gt; again. So, the only way to get out of this is enforcement, like it or
<br/>&gt; &gt;&gt; not.
<br/>&gt; &gt;
<br/>&gt; &gt; The Vcs-foo is there as an aid to finding additional information about the
<br/>&gt; &gt; package. &nbsp;There's no requirement to deal with it when you are NMUing. &nbsp;NMU
<br/>&gt; &gt; diffs go to the BTS. &nbsp;End of story.
<br/>&gt;
<br/>&gt; Respectfully: this sounds like a non-sense to me. I completely fail to
<br/>&gt; understand the logic behind what you just wrote. As, seemingly, you're
<br/>&gt; not the only one with that point or argumentation, I need more
<br/>&gt; enlightenment.
<br/>&gt;
<br/>&gt; If we aren't supposed to use the VCS fields, why do we even have them at
<br/>&gt; all? Shouldn't we just get rid of them completely in Debian then? What's
<br/>&gt; the point to advertise about some kind of Git repository, if we're not
<br/>&gt; supposed to use them? If you're using Git alone, for yourself only, why
<br/>&gt; at all publish the repository then?
<br/>&gt;
<br/>&gt; &gt; There's nothing that requires you to interact with a VCS repository that
<br/>&gt; &gt; you don't care to.
<br/>&gt;
<br/>&gt; But I do care about using Git, and interacting with other DDs using it.
<br/>&gt; However, basically, what you're saying is that, for those who care about
<br/>&gt; not using non-free platforms, we should just not do that anymore, as
<br/>&gt; it's not required anyway. That's simply not fair: I care more about
<br/>&gt; software freedom, and therefore, I'd be left aside, not being able to
<br/>&gt; use Git when interacting with others.
<br/>&gt;
<br/>&gt; Besides this, there's something else I don't understand. How much effort
<br/>&gt; is it to use a free software based platform? It's not as if Github was
<br/>&gt; so much nicer than Gitlab (at least not anymore). What is it that people
<br/>&gt; hate about Gitlab so much, that they feel like they must use some
<br/>&gt; non-free platform, even if they know some of us will hate it?
</div><br/>I don't know. &nbsp;I don't use GitHub except as needed to support collaboration
<br/>with others that use it. &nbsp;I think that 7% is too large a number just to assume
<br/>there's not a reason.
<br/><br/>Also, consider that if we prohibit Vcs-foo that point at non-free services
<br/>like GitHub what the likely result will be. &nbsp;I suspect that people who are
<br/>using such services are doing it for a reason they consider sufficient (or they
<br/>woulnd't be doint it). &nbsp;
<br/><br/>Given that, I'd expect that the rational response to such a rule would be to
<br/>delet the Vcs-foo from the package and carry on using the non-free service.
<br/><br/>How does that help make Debian better?
<br/><br/>Scott K
<br/><br/><br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569205Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T16:16:26Z2019-09-14T16:16:26ZThomas Goirand-3
On 9/15/19 12:06 AM, Scott Kitterman wrote:
<div class='shrinkable-quote'><br/>&gt; On Saturday, September 14, 2019 6:01:24 PM EDT Thomas Goirand wrote:
<br/>&gt;&gt; On 9/14/19 6:59 AM, Balasankar &quot;Balu&quot; C wrote:
<br/>&gt;&gt;&gt; So will the GR be
<br/>&gt;&gt;&gt; &quot;You must not do any sort of contribution to Debian using non-free
<br/>&gt;&gt;&gt; software/hardware&quot;
<br/>&gt;&gt;&gt;
<br/>&gt;&gt;&gt; or
<br/>&gt;&gt;&gt;
<br/>&gt;&gt;&gt; &quot;You can use anything you want to contribute to Debian, but there should
<br/>&gt;&gt;&gt; be a way for other people to contribute to your work in Debian without
<br/>&gt;&gt;&gt; compromising on their freedom&quot; ? (This translates to my words in the
<br/>&gt;&gt;&gt; beginning of this reply - patches over BTS must not be rejected by a
<br/>&gt;&gt;&gt; maintainer)
<br/>&gt;&gt;
<br/>&gt;&gt; Of course, the later. I don't care if a contributor is using Debian in a
<br/>&gt;&gt; VM running on Windows, as long as he/she doesn't force me to do the
<br/>&gt;&gt; same. That's the same spirit with using a non-free Git platform.
<br/>&gt;
<br/>&gt; What you proposed sounded a lot like the former to me and apparently others.
</div><br/>Indeed. Sorry for this (to you, and to all others that wrongly
<br/>understood what I meant).
<br/><div class='shrinkable-quote'><br/>&gt;&gt; It is a real life experience that I had to touch horribly maintained
<br/>&gt;&gt; packages by unknown contributors, with Vcs-Git:
<br/>&gt;&gt; <a href="https://github.com/" target="_top" rel="nofollow" link="external">https://github.com/</a>&lt;foo&gt;/&lt;bar&gt;, missing commits not matching the
<br/>&gt;&gt; archive, and no response from the maintainer to the BTS (even for RC
<br/>&gt;&gt; bugs). The last occurrence of this was pyroute2, which I pushed into the
<br/>&gt;&gt; DPMT (and still no reply from that past maintainer). I hate seeing this,
<br/>&gt;&gt; and don't want this anymore, though it happens again, and again, and
<br/>&gt;&gt; again. So, the only way to get out of this is enforcement, like it or not.
<br/>&gt;
<br/>&gt; The Vcs-foo is there as an aid to finding additional information about the
<br/>&gt; package. &nbsp;There's no requirement to deal with it when you are NMUing. &nbsp;NMU
<br/>&gt; diffs go to the BTS. &nbsp;End of story.
</div><br/>Respectfully: this sounds like a non-sense to me. I completely fail to
<br/>understand the logic behind what you just wrote. As, seemingly, you're
<br/>not the only one with that point or argumentation, I need more
<br/>enlightenment.
<br/><br/>If we aren't supposed to use the VCS fields, why do we even have them at
<br/>all? Shouldn't we just get rid of them completely in Debian then? What's
<br/>the point to advertise about some kind of Git repository, if we're not
<br/>supposed to use them? If you're using Git alone, for yourself only, why
<br/>at all publish the repository then?
<br/><br/>&gt; There's nothing that requires you to interact with a VCS repository that you
<br/>&gt; don't care to.
<br/><br/>But I do care about using Git, and interacting with other DDs using it.
<br/>However, basically, what you're saying is that, for those who care about
<br/>not using non-free platforms, we should just not do that anymore, as
<br/>it's not required anyway. That's simply not fair: I care more about
<br/>software freedom, and therefore, I'd be left aside, not being able to
<br/>use Git when interacting with others.
<br/><br/>Besides this, there's something else I don't understand. How much effort
<br/>is it to use a free software based platform? It's not as if Github was
<br/>so much nicer than Gitlab (at least not anymore). What is it that people
<br/>hate about Gitlab so much, that they feel like they must use some
<br/>non-free platform, even if they know some of us will hate it?
<br/><br/>Cheers,
<br/><br/>Thomas Goirand (zigo)
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569201Re: tag2upload (git-debpush) service architecture - draft2019-09-14T15:53:34Z2019-09-14T15:53:34ZGuillem Jover
On Thu, 2019-08-01 at 16:22:19 +0100, Sean Whitton wrote:
<div class='shrinkable-quote'><br/>&gt; On Thu 01 Aug 2019 at 02:35PM +02, Guillem Jover wrote:
<br/>&gt; &gt; This argument seems very counter-intuitive. This assumes a
<br/>&gt; &gt; Debian-archive-centric world-view, where most of the heavy lifting is
<br/>&gt; &gt; delegated to some external service. But the reality is that most
<br/>&gt; &gt; maintainers, and other external parties handling Debian sources do
<br/>&gt; &gt; need to handle actual source packages. Requiring people to setup an
<br/>&gt; &gt; equivalent to the Debian archive + dgit service + tag2upload &quot;locally&quot;
<br/>&gt; &gt; just so that they can reduce their cognitive load, seems to be pretty
<br/>&gt; &gt; much the opposite to the above stated goal TBH.
<br/>&gt;
<br/>&gt; Hmm, I'm not sure all that local setup would be needed. &nbsp;You can start
<br/>&gt; with `dgit clone` and work from there.
</div><br/>That was my point. This only works as long as there's such package in
<br/>the Debian archive. A Debian source package does not imply it will be
<br/>in Debian. There are many parties that do use and work with these too.
<br/>Ranging from local packages of unpublished stuff, packages for public
<br/>things not intended for Debian, packaging overlays from third-parties,
<br/>etc.
<br/><br/>&gt; More generally, I think we should aim to replace the use of source
<br/>&gt; packages in all those places too, but there are lots of unsolved
<br/>&gt; problems there. &nbsp;I don't think anyone knows what things are going to
<br/>&gt; look like.
<br/><br/>The more I've been considering this the more I think this would be a
<br/>monumental mistake. I'm pondering about a new workflow proposal where
<br/>I'll expand on this.
<br/><br/>Thanks,
<br/>Guillem
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569196Re: Git Packaging Round 2: When to Salsa2019-09-14T15:22:07Z2019-09-14T15:22:07ZGuillem Jover
On Sun, 2019-09-15 at 00:37:00 +0530, Pirate Praveen wrote:
<br/>&gt; On 2019, സെപ്റ്റംബർ 15 12:35:18 AM IST, Holger Levsen &lt;<a href="/user/SendEmail.jtp?type=node&node=4569196&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt; wrote:
<br/>&gt; &gt; I guess because according to <a href="https://trends.debian.net/#vcs-hosting" target="_top" rel="nofollow" link="external">https://trends.debian.net/#vcs-hosting</a><br/>&gt; &gt; there's *still*, today, almost 10000 source packages in unstable which
<br/>&gt; &gt; declare they are maintained in git on alioth.
<br/>&gt; &gt;
<br/>&gt; &gt; I wouldn't call that (part) a success.
<br/>&gt;
<br/>&gt; Don't they get redirected to salsa?
<br/><br/>Not by default, no. And given how the migration was planned, I don't
<br/>see how that would be even possible.
<br/><br/>&nbsp;* There was no automatic migration, so something that was
<br/>&nbsp; &nbsp;previously in alioth might not even be in salsa yet (or ever).
<br/>&nbsp;* When people migrated the repos, they might have used a different
<br/>&nbsp; &nbsp;group name (say from collab-maint/ to debian/), or placed them
<br/>&nbsp; &nbsp;in the personal space, or changed the repo names or used the same
<br/>&nbsp; &nbsp;team but adapting it to the new team namespace policies.
<br/>&nbsp;* git:// URLs would and do not redirect anyway.
<br/><br/>But, if the maintainers have done the migration already, they can
<br/>always add the redirections manually via:
<br/><br/>&nbsp; <a href="https://salsa.debian.org/salsa/AliothRewriter" target="_top" rel="nofollow" link="external">https://salsa.debian.org/salsa/AliothRewriter</a><br/><br/>Thanks,
<br/>Guillem
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569194Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T15:17:47Z2019-09-14T15:17:47ZAlf Gaida
<br/>On 15.09.19 00:05, Russ Allbery wrote:
<br/><div class='shrinkable-quote'><br/>&gt; We have more agreement here, although there are a lot of details hidden in
<br/>&gt; what &quot;forcing&quot; really means. &nbsp;But there's a huge space between &quot;don't
<br/>&gt; force other people to use non-free software to contribute to Debian&quot; and
<br/>&gt; &quot;forbid using non-free software within the Debian project.&quot;
<br/>&gt;
<br/>&gt; I feel like I can say with a very high degree of confidence that we're not
<br/>&gt; going to do the latter. &nbsp;For instance, we're not going to stop using Intel
<br/>&gt; and AMD processors in the Debian project, even though they are full of
<br/>&gt; non-free software. &nbsp;So whatever policy stance you're aiming for here needs
<br/>&gt; to be a lot more nuanced than how you're presenting it.
<br/>&gt;
</div>Thank you Russ for your insightful words - it's like a beacon in the
<br/>night and let me try to trust debian at all more than i do right now. To
<br/>be honest about, i have not much trust in anyone, but your posts over
<br/>the last decade helped me to build something like that.
<br/><br/><br/>Thanks Alf
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569192Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T15:06:20Z2019-09-14T15:06:20ZScott Kitterman-5
On Saturday, September 14, 2019 6:01:24 PM EDT Thomas Goirand wrote:
<div class='shrinkable-quote'><br/>&gt; On 9/14/19 6:59 AM, Balasankar &quot;Balu&quot; C wrote:
<br/>&gt; &gt; But it shouldn't matter to the project that I do my packaging work in
<br/>&gt; &gt; GitLab.com or GitHub.com because as far as Debian is concerned, as long
<br/>&gt; &gt; as others can contribute without having an account in that service - I
<br/>&gt; &gt; should not be forbidden using them. That is, if I come in and say &quot;I
<br/>&gt; &gt; won't accept any patches submitted over BTS, but only GitHub PRs&quot;, the
<br/>&gt; &gt; project has every right to kick the package out of Debian or fork it.
<br/>&gt; &gt; But as long as I continue supporting people using BTS, I should be fine
<br/>&gt; &gt; using whatever I want as my primary platform.
<br/>&gt;
<br/>&gt; Could you explain why you'd have VCS fields then, if not to advertise
<br/>&gt; what the addres of your Git? Isn't this an invitation to use the
<br/>&gt; platform you're pointing at, as a mean to modify your package?
<br/>&gt;
<br/>&gt; &gt; So will the GR be
<br/>&gt; &gt; &quot;You must not do any sort of contribution to Debian using non-free
<br/>&gt; &gt; software/hardware&quot;
<br/>&gt; &gt;
<br/>&gt; &gt; or
<br/>&gt; &gt;
<br/>&gt; &gt; &quot;You can use anything you want to contribute to Debian, but there should
<br/>&gt; &gt; be a way for other people to contribute to your work in Debian without
<br/>&gt; &gt; compromising on their freedom&quot; ? (This translates to my words in the
<br/>&gt; &gt; beginning of this reply - patches over BTS must not be rejected by a
<br/>&gt; &gt; maintainer)
<br/>&gt;
<br/>&gt; Of course, the later. I don't care if a contributor is using Debian in a
<br/>&gt; VM running on Windows, as long as he/she doesn't force me to do the
<br/>&gt; same. That's the same spirit with using a non-free Git platform.
</div><br/>What you proposed sounded a lot like the former to me and apparently others.
<br/><br/>&gt; It is a real life experience that I had to touch horribly maintained
<br/>&gt; packages by unknown contributors, with Vcs-Git:
<br/>&gt; <a href="https://github.com/" target="_top" rel="nofollow" link="external">https://github.com/</a>&lt;foo&gt;/&lt;bar&gt;, missing commits not matching the
<br/>&gt; archive, and no response from the maintainer to the BTS (even for RC
<br/>&gt; bugs). The last occurrence of this was pyroute2, which I pushed into the
<br/>&gt; DPMT (and still no reply from that past maintainer). I hate seeing this,
<br/>&gt; and don't want this anymore, though it happens again, and again, and
<br/>&gt; again. So, the only way to get out of this is enforcement, like it or not.
<br/><br/>The Vcs-foo is there as an aid to finding additional information about the
<br/>package. &nbsp;There's no requirement to deal with it when you are NMUing. &nbsp;NMU
<br/>diffs go to the BTS. &nbsp;End of story.
<br/><br/>There's nothing that requires you to interact with a VCS repository that you
<br/>don't care to.
<br/><br/>If a maintainer is non-responsive to bugs/patches in the BTS, it doesn't
<br/>matter where the Git repository is.
<br/><br/>Scott K
<br/><br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569188Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T15:05:10Z2019-09-14T15:05:10ZRuss Allbery-2
Thomas Goirand &lt;<a href="/user/SendEmail.jtp?type=node&node=4569188&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt; writes:
<br/>&gt; On 9/14/19 1:03 AM, Russ Allbery wrote:
<br/>&gt;&gt; Thomas Goirand &lt;<a href="/user/SendEmail.jtp?type=node&node=4569188&i=1" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt; writes:
<br/><br/>&gt;&gt;&gt; Sorry, WHAAAT ? That's shocking to read this from the DPL. &nbsp;Are you
<br/>&gt;&gt;&gt; sure you didn't do a mistake in this sentence?
<br/><br/>&gt;&gt;&gt; There's absolutely no problem within the Debian project to forbid
<br/>&gt;&gt;&gt; using non-free software.
<br/><br/>&gt;&gt; I use a computer with non-free firmware
<br/><br/>&gt; This has nothing to do with what I wrote, and you know it.
<br/><br/>I don't know anything of the sort. &nbsp;I do my Debian development on a host
<br/>running non-free software. &nbsp;You said, right up above, that within the
<br/>Debian project we should forbid using non-free software. &nbsp;Maybe that's not
<br/>what you *meant*, but that's what you *said*.
<br/><br/>&gt;&gt; and push my packaging repositories
<br/>&gt;&gt; to (among other places) GitHub.
<br/><br/>&gt; As long as you push to Github *for yourself* (ie: not in order to share
<br/>&gt; the repository with other people form the Debian community),
<br/><br/>I use GitHub to share with anyone who uses GitHub. &nbsp;I don't make them sign
<br/>some sort of statement saying they're not members of the Debian community
<br/>before they're allowed to use GitHub. &nbsp;If other people in Debian want to
<br/>use GitHub rather than Salsa or my own Git server to clone my packages or
<br/>even to submit PRs, I don't care, and am happy to take contributions from
<br/>all of those channels.
<br/><br/>If you weren't intending to challenge that, that's fine, but what you said
<br/>is that this should be forbidden, and that doesn't make sense to me.
<br/><br/>&gt; that's fine. But forcing it to others is not acceptable.
<br/><br/>We have more agreement here, although there are a lot of details hidden in
<br/>what &quot;forcing&quot; really means. &nbsp;But there's a huge space between &quot;don't
<br/>force other people to use non-free software to contribute to Debian&quot; and
<br/>&quot;forbid using non-free software within the Debian project.&quot;
<br/><br/>I feel like I can say with a very high degree of confidence that we're not
<br/>going to do the latter. &nbsp;For instance, we're not going to stop using Intel
<br/>and AMD processors in the Debian project, even though they are full of
<br/>non-free software. &nbsp;So whatever policy stance you're aiming for here needs
<br/>to be a lot more nuanced than how you're presenting it.
<br/><br/>--
<br/>Russ Allbery (<a href="/user/SendEmail.jtp?type=node&node=4569188&i=2" target="_top" rel="nofollow" link="external">[hidden email]</a>) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;<a href="http://www.eyrie.org/~eagle/" target="_top" rel="nofollow" link="external">http://www.eyrie.org/~eagle/</a>&gt;
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569187Re: Git Packaging Round 2: When to Salsa2019-09-14T15:04:14Z2019-09-14T15:04:14ZGuillem Jover
On Sat, 2019-09-14 at 13:07:09 +0200, Marc Haber wrote:
<div class='shrinkable-quote'><br/>&gt; On Fri, 13 Sep 2019 13:05:20 -0700, Sean Whitton wrote:
<br/>&gt; &gt; On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:
<br/>&gt; &gt; &gt; How about documenting that branches prefixed with &quot;wip&quot; can be force
<br/>&gt; &gt; &gt; pushed any time and people pulling from those branches should be
<br/>&gt; &gt; &gt; expected to handle that?
<br/>&gt; &gt;
<br/>&gt; &gt; This would be useful.
<br/>&gt; &gt;
<br/>&gt; &gt; I would already assume any branch prefixed with 'wip' might be rebased
<br/>&gt; &gt; myself, but others might be surprised.
<br/>&gt;
<br/>&gt; I would like to have this documented somewhere so that people dont get
<br/>&gt; surprised. I am not particularly fond of the wip-prefix though and
<br/>&gt; would appreciate better suggestions.
</div><br/>I think the common prefixes for these are pu/ and next/? These are
<br/>also documented somehow in the gitworkflows(7) man page.
<br/><br/>Thanks,
<br/>Guillem
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569182Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T15:01:27Z2019-09-14T15:01:27ZAlf Gaida
Thomas Goirand &lt;<a href="/user/SendEmail.jtp?type=node&node=4569182&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt; wrote:
<br/>&gt; As long as you push to Github *for yourself* (ie: not in order to
<br/>&gt; share the repository with other people form the Debian community),
<br/>&gt; that's fine. But forcing it to others is not acceptable.
<br/>&gt;
<br/>&gt; Thomas Goirand (zigo)
<br/>Thomas - what you want to achive?
<br/><br/>Right now i'm affraid of you and others who share your opinion: There
<br/>will something happend as result:
<br/>* i will consider that my view on debian was just false
<br/>* i will move all my packaging to github or gitlab - the service don't
<br/>&nbsp; matter, but it will make sure that i can have my workflow after the
<br/>&nbsp; GR
<br/>* it will not hurt debian directly, because i will mirror the repo's to
<br/>&nbsp; salsa
<br/>* there will be nice improvements in sense of my workflow coming with
<br/>&nbsp; it: i will only accept github PRs - nothing else. I will only use
<br/>&nbsp; github issues - because after such a descision i will suspspect the
<br/>&nbsp; debian bts as not trustworthy
<br/><br/>at all - i will have my packaging in a safe haven - and don't have to
<br/>care how nuts the outcome of a GR will be. Hey - if you really want it
<br/>that way, you layed out the first few meters of the new debian road.
<br/><br/>Before i forget - if your plans happend, i will be verbose about - with
<br/>every contributor who will left debian alone after me. Promised.
<br/><br/>Before there are false assumtions that i'm searching any consensus in
<br/>this unbelivable bullshit - no - i don't. I'll &nbsp;only stepping aside
<br/>and see debian and debians ideas die. An cry silently. Thats all.
<br/><br/>Alf
<br/><br/><br/><br/>--
<br/>Alf Gaida
<br/>BDBF C688 EFAD BA89 5A9F &nbsp;464B CD28 0A0B 4D72 827C
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569183Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T15:01:24Z2019-09-14T15:01:24ZThomas Goirand-3
On 9/14/19 6:59 AM, Balasankar &quot;Balu&quot; C wrote:
<br/>&gt; But it shouldn't matter to the project that I do my packaging work in
<br/>&gt; GitLab.com or GitHub.com because as far as Debian is concerned, as long
<br/>&gt; as others can contribute without having an account in that service - I
<br/>&gt; should not be forbidden using them. That is, if I come in and say &quot;I
<br/>&gt; won't accept any patches submitted over BTS, but only GitHub PRs&quot;, the
<br/>&gt; project has every right to kick the package out of Debian or fork it.
<br/>&gt; But as long as I continue supporting people using BTS, I should be fine
<br/>&gt; using whatever I want as my primary platform.
<br/><br/>Could you explain why you'd have VCS fields then, if not to advertise
<br/>what the addres of your Git? Isn't this an invitation to use the
<br/>platform you're pointing at, as a mean to modify your package?
<br/><div class='shrinkable-quote'><br/>&gt; So will the GR be
<br/>&gt; &quot;You must not do any sort of contribution to Debian using non-free
<br/>&gt; software/hardware&quot;
<br/>&gt;
<br/>&gt; or
<br/>&gt;
<br/>&gt; &quot;You can use anything you want to contribute to Debian, but there should
<br/>&gt; be a way for other people to contribute to your work in Debian without
<br/>&gt; compromising on their freedom&quot; ? (This translates to my words in the
<br/>&gt; beginning of this reply - patches over BTS must not be rejected by a
<br/>&gt; maintainer)
</div><br/>Of course, the later. I don't care if a contributor is using Debian in a
<br/>VM running on Windows, as long as he/she doesn't force me to do the
<br/>same. That's the same spirit with using a non-free Git platform.
<br/><br/>It is a real life experience that I had to touch horribly maintained
<br/>packages by unknown contributors, with Vcs-Git:
<br/><a href="https://github.com/" target="_top" rel="nofollow" link="external">https://github.com/</a>&lt;foo&gt;/&lt;bar&gt;, missing commits not matching the
<br/>archive, and no response from the maintainer to the BTS (even for RC
<br/>bugs). The last occurrence of this was pyroute2, which I pushed into the
<br/>DPMT (and still no reply from that past maintainer). I hate seeing this,
<br/>and don't want this anymore, though it happens again, and again, and
<br/>again. So, the only way to get out of this is enforcement, like it or not.
<br/><br/>Thomas Goirand (zigo)
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569180Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?2019-09-14T14:48:13Z2019-09-14T14:48:13ZAnthony DeRobertis
On 9/13/19 7:05 AM, Simon Richter wrote:
<br/>&gt;
<br/>&gt; Mandatory Encrypted SNI with no fallback option -- everything else can be
<br/>&gt; circumvented easily.
<br/>&gt;
<br/>&gt; This is a game that we should not play, really. It raises the cost of
<br/>&gt; running a service on the Internet so only big players can afford to do so.
<br/><br/>Does it? I haven't personally deployed it yet anywhere, but when I
<br/>briefly looked into it, it appears to require adding a DNS record &amp; some
<br/>web server config. If anything, it appears to be harder to do if you're
<br/>a big player (e.g., making sure your DNS servers always return matching
<br/>ESNI and A/AAAA records, even when you have geo-targeted DNS — so much
<br/>easier when you only have one server.)
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569177Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T14:40:36Z2019-09-14T14:40:36ZThomas Goirand-3
On 9/14/19 1:03 AM, Russ Allbery wrote:
<br/>&gt; Thomas Goirand &lt;<a href="/user/SendEmail.jtp?type=node&node=4569177&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt; writes:
<br/>&gt;
<br/>&gt;&gt; Sorry, WHAAAT ? That's shocking to read this from the DPL.
<br/>&gt;&gt; Are you sure you didn't do a mistake in this sentence?
<br/>&gt;
<br/>&gt;&gt; There's absolutely no problem within the Debian project to forbid using
<br/>&gt;&gt; non-free software.
<br/>&gt;
<br/>&gt; I use a computer with non-free firmware
<br/><br/>This has nothing to do with what I wrote, and you know it.
<br/><br/>&gt; and push my packaging repositories
<br/>&gt; to (among other places) GitHub.
<br/><br/>As long as you push to Github *for yourself* (ie: not in order to share
<br/>the repository with other people form the Debian community), that's
<br/>fine. But forcing it to others is not acceptable.
<br/><br/>Thomas Goirand (zigo)
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569167Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T14:19:18Z2019-09-14T14:19:18ZAdam Borowski-3
On Sat, Sep 14, 2019 at 01:02:03PM +0200, Bastian Blank wrote:
<br/>&gt; On Sat, Sep 14, 2019 at 12:16:43PM +0200, Adam Borowski wrote:
<br/>&gt; &gt; And, despite a massive amount of efforts from you and others, packaged
<br/>&gt; &gt; gitlab is not fit for Salsa use. &nbsp;It hasn't also ever been in a stable
<br/>&gt; &gt; release of Debian, despite being around since a year before Stretch's
<br/>&gt; &gt; freeze.
<br/>&gt;
<br/>&gt; And even if there is a package, how do you plan to ask DSA to use it and
<br/>&gt; run this service themselves? &nbsp;Hint, as we told a hundred times before:
<br/>&gt; Salsa runs on a DSA controlled machine, _without_ root.
<br/><br/>Yet you use packaged exim, packaged postgres, packaged 1000-3000 other
<br/>pieces of software on a typical machine. &nbsp;Those packages are good out of the
<br/>box. &nbsp;They're stable and reliable. &nbsp;Heck, you even use packaged git itself,
<br/>and it provides far far more functionality than a web interface to a small
<br/>subset of it.
<br/><br/>And teams maintaining big important pieces manage to do their work despite
<br/>limited manpower. &nbsp;It's just Gitlab and such that have a ridiculously bad
<br/>complexity-to-functionality ratio.
<br/><br/>I thus stand by my point: I don't believe Gitlab will last, at least barring
<br/>some large-scale changes. &nbsp;We've been there with Alioth.
<br/><div class='shrinkable-quote'><br/>&gt; Let's compare it with other solutions:
<br/>&gt;
<br/>&gt; ## GitLab unicorn application
<br/>&gt;
<br/>&gt; * Ruby gems included directly: 199
<br/>&gt; * Ruby gems included recursive: 333
<br/>&gt; * node.js modules included directly: 113
<br/>&gt; * node.js modules included recursive: 1760
<br/>&gt;
<br/>&gt; Of the Ruby gems, 6 are from GitLab itself and are maintained separate.
<br/>&gt;
<br/>&gt; With the listed software available everything is built from source.
<br/>&gt;
<br/>&gt; ## gitea
<br/>&gt;
<br/>&gt; * Go modules included: 122
<br/>&gt; * node.js dependent projects vendored: 21
<br/>&gt;
<br/>&gt; I assume the vendored stuff can be rebuild using this:
<br/>&gt;
<br/>&gt; * node.js modules included directly: 8
<br/>&gt; * node.js modules included recursive: 516
<br/>&gt;
<br/>&gt; ## pagure
<br/>&gt;
<br/>&gt; * Python modules required directly: 70
<br/>&gt; * node.js dependent projects vendored: 16
</div><br/>## sr.ht
<br/><br/>* unpackaged Python modules: 8
<br/>* node.js modules directly: 0
<br/>* node.js modules recursively: 0
<br/><br/>It's in alpha stage, and uses a heathen snake-lover language I don't know,
<br/>but it's an example of a non-node.js implementation; engineering customs in
<br/>the node.js ecosystem are what I naively guess is the culprit here.
<br/><br/><br/>But, it's not a place for discussing alternate implementations (yet?), the
<br/>big question is: is Gitlab a sturdy enough foundation to _mandate_ or even
<br/>strongly recommend it for Debian workflows. &nbsp;My response is a strong &quot;no&quot;.
<br/><br/><br/>Meow!
<br/>--
<br/>⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
<br/>⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
<br/>⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
<br/>⠈⠳⣄⠀⠀⠀⠀ etc), let the drink age at least 3-6 months.
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569131Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T12:30:37Z2019-09-14T12:30:37ZPirate Praveen-3
<br/><br/>On 2019, സെപ്റ്റംബർ 14 3:46:43 PM IST, Adam Borowski &lt;<a href="/user/SendEmail.jtp?type=node&node=4569131&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt; wrote:
<br/>&gt;On Sat, Sep 14, 2019 at 09:37:00AM +0530, Pirate Praveen wrote:
<br/>&gt;&gt; I will also support such a GR. &nbsp;I started packaging gitlab so we
<br/>&gt;don't
<br/>&gt;&gt; have to compromise on ease of use compared to github.
<br/>&gt;
<br/>&gt;And, despite a massive amount of efforts from you and others, packaged
<br/>&gt;gitlab is not fit for Salsa use. &nbsp;It hasn't also ever been in a stable
<br/>&gt;release of Debian, despite being around since a year before Stretch's
<br/>&gt;freeze.
<br/><br/>And the huge amount of work we put in to maintain gitlab is improving the base package quality of Debian, especially nodejs. We have packaged many core build tools like webpack, rollup, gulp, grunt etc which makes it easier to build many JavaScript libraries from source (we had to reverse engineer the build process before these were packaged, look at d3-format and jquery for example). rails is another example which is useful beyond gitlab. Also all the new people who joins gitlab team strengths the underlying ruby, js and golang teams.
<br/><br/>I think I have to repeat these in regular intervals in -devel and probably a better way is to add it to gitlab wiki page and share link.
<br/>--
<br/>Sent from my Android device with K-9 Mail. Please excuse my brevity.
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569130Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T12:27:08Z2019-09-14T12:27:08ZSean Whitton
Hello Pirate,
<br/><br/>On Sun 15 Sep 2019 at 12:27AM +0530, Pirate Praveen wrote:
<br/><br/>&gt; That is not going to happen, instead we need to adapt ourselves to
<br/>&gt; this fast paced development and fasttrack.debian.net is a step in that
<br/>&gt; direction.
<br/><br/>It's not just a matter of adapting workflows -- without real stable
<br/>releases, however good your workflows are, packaging GitLab and
<br/>administering GitLab installations demands more of people's time than it
<br/>would if there were real stable releases.
<br/><br/>Real stable releases are freedom-enhancing when they free up people's
<br/>time to work on other stuff.
<br/><br/>--
<br/>Sean Whitton
<br/><!--start-attachments--><div class="small"><br/><img src="http://debian.2.n7.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (847 bytes) <a href="http://debian.2.n7.nabble.com/attachment/4569130/0/signature.asc" target="_top" rel="nofollow" link="external">Download Attachment</a></div><!--end-attachments-->
tag:debian.2.n7.nabble.com,2006:post-4569126dgit violating best practices? (Re: Git Packaging Round 2: When to Salsa)2019-09-14T12:24:15Z2019-09-14T12:24:15ZHolger Levsen-2
On Thu, Sep 12, 2019 at 02:57:09PM +0200, Ansgar wrote:
<br/>&gt; (Using dgit to upload packages is sadly incompatible with best
<br/>&gt; practices around packaging.)
<br/><br/>I'm genuinly curious: why do you say so? Which practices does it
<br/>violate?
<br/><br/><br/>--
<br/>cheers,
<br/>&nbsp; &nbsp; &nbsp; &nbsp; Holger
<br/><br/>-------------------------------------------------------------------------------
<br/>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;holger@(debian|reproducible-builds|layer-acht).org
<br/>&nbsp; &nbsp; &nbsp; &nbsp;PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
<br/><!--start-attachments--><div class="small"><br/><img src="http://debian.2.n7.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (849 bytes) <a href="http://debian.2.n7.nabble.com/attachment/4569126/0/signature.asc" target="_top" rel="nofollow" link="external">Download Attachment</a></div><!--end-attachments-->
tag:debian.2.n7.nabble.com,2006:post-4569122Re: Git Packaging Round 2: When to Salsa2019-09-14T12:07:00Z2019-09-14T12:07:00ZPirate Praveen-3
<br/><br/>On 2019, സെപ്റ്റംബർ 15 12:35:18 AM IST, Holger Levsen &lt;<a href="/user/SendEmail.jtp?type=node&node=4569122&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt; wrote:
<div class='shrinkable-quote'><br/>&gt;On Fri, Sep 13, 2019 at 11:30:51AM +0530, Pirate Praveen wrote:
<br/>&gt;&gt; On 2019, സെപ്റ്റംബർ 13 1:06:13 AM IST, Marc Haber
<br/>&gt;&lt;<a href="/user/SendEmail.jtp?type=node&node=4569122&i=1" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt; wrote:
<br/>&gt;&gt; &gt;alioth.debian.org, anyone? That one went away pretty fast.
<br/>&gt;&gt; I wonder why people keep repeating this.
<br/>&gt;
<br/>&gt;I guess because according to <a href="https://trends.debian.net/#vcs-hosting" target="_top" rel="nofollow" link="external">https://trends.debian.net/#vcs-hosting</a><br/>&gt;there's
<br/>&gt;*still*, today, almost 10000 source packages in unstable which declare
<br/>&gt;they
<br/>&gt;are maintained in git on alioth.
<br/>&gt;
<br/>&gt;I wouldn't call that (part) a success.
</div><br/>Don't they get redirected to salsa?
<br/>--
<br/>Sent from my Android device with K-9 Mail. Please excuse my brevity.
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569121Re: Git Packaging Round 2: When to Salsa2019-09-14T12:05:18Z2019-09-14T12:05:18ZHolger Levsen-2
On Fri, Sep 13, 2019 at 11:30:51AM +0530, Pirate Praveen wrote:
<br/>&gt; On 2019, സെപ്റ്റംബർ 13 1:06:13 AM IST, Marc Haber &lt;<a href="/user/SendEmail.jtp?type=node&node=4569121&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt; wrote:
<br/>&gt; &gt;alioth.debian.org, anyone? That one went away pretty fast.
<br/>&gt; I wonder why people keep repeating this.
<br/><br/>I guess because according to <a href="https://trends.debian.net/#vcs-hosting" target="_top" rel="nofollow" link="external">https://trends.debian.net/#vcs-hosting</a>&nbsp;there's
<br/>*still*, today, almost 10000 source packages in unstable which declare they
<br/>are maintained in git on alioth.
<br/><br/>I wouldn't call that (part) a success.
<br/><br/><br/>--
<br/>cheers,
<br/>&nbsp; &nbsp; &nbsp; &nbsp; Holger
<br/><br/>-------------------------------------------------------------------------------
<br/>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;holger@(debian|reproducible-builds|layer-acht).org
<br/>&nbsp; &nbsp; &nbsp; &nbsp;PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
<br/><!--start-attachments--><div class="small"><br/><img src="http://debian.2.n7.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (849 bytes) <a href="http://debian.2.n7.nabble.com/attachment/4569121/0/signature.asc" target="_top" rel="nofollow" link="external">Download Attachment</a></div><!--end-attachments-->
tag:debian.2.n7.nabble.com,2006:post-4569119Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github2019-09-14T11:57:48Z2019-09-14T11:57:48ZPirate Praveen-3
<br/><br/>On 2019, സെപ്റ്റംബർ 14 3:46:43 PM IST, Adam Borowski &lt;<a href="/user/SendEmail.jtp?type=node&node=4569119&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>&gt; wrote:
<br/>&gt;On Sat, Sep 14, 2019 at 09:37:00AM +0530, Pirate Praveen wrote:
<br/>&gt;&gt; I will also support such a GR. &nbsp;I started packaging gitlab so we
<br/>&gt;don't
<br/>&gt;&gt; have to compromise on ease of use compared to github.
<br/>&gt;
<br/>&gt;And, despite a massive amount of efforts from you and others, packaged
<br/>&gt;gitlab is not fit for Salsa use. &nbsp;It hasn't also ever been in a stable
<br/>&gt;release of Debian, despite being around since a year before Stretch's
<br/>&gt;freeze.
<br/><br/>I don't think looking at our current stable release cycle as holy standard for evaluating a software is the right approach. Backports was evolved to cater to a different need, it was not official when it was started. Similarly we now have <a href="http://fasttrack.debian.net" target="_top" rel="nofollow" link="external">http://fasttrack.debian.net</a>&nbsp;being setup which includes gitlab.
<br/><br/>&gt;Looking at the number and complexity of packages needed solely for
<br/>&gt;gitlab,
<br/>&gt;I'd say that they'll collapse the moment you get busy with other tasks.
<br/><br/>I understand this risk, that is the reason why I make sure more people join the team maintaining gitlab. I'm always mentoring new people and if you look at the tracker.debian.org for gitlab and dependencies, you will see more names uploading packages now. If you look at last 10 uploads of gitlab, 5 of it was not done by me. Initially gitlab inc was funding only me to work on gitlab packaging, now they fund me, Sruthi and Abhijith.
<br/><br/>Earlier the gitlab package backports were only available from my people.debian.org repo which only I had access to. Now 3 people have access to fasttrack.debian.net already and the last upload was not done by me.
<br/><div class='shrinkable-quote'><br/>&gt;This doesn't say anything good about Gitlab's design.
<br/>&gt;
<br/>&gt;(I'm quite obviously not bashing you, but your upstream.)
<br/>&gt;
<br/>&gt;I don't trust Gitlab's prolonged support. &nbsp;Let's let it prove itself by
<br/>&gt;being a part of a couple of stable releases -- and _then_ we can build
<br/>&gt;upon
<br/>&gt;its foundation. &nbsp;That'd be a time frame already much accelerated
<br/>&gt;compared to
<br/>&gt;other core software projects.
</div><br/>That is not going to happen, instead we need to adapt ourselves to this fast paced development and fasttrack.debian.net is a step in that direction.
<br/><br/>&gt;Until then, I'll use git (which has greatly proven itself) but strongly
<br/>&gt;refuse any ties to any particular platform.
<br/>&gt;
<br/>&gt;
<br/>&gt;Meow!
<br/><br/>--
<br/>Sent from my Android device with K-9 Mail. Please excuse my brevity.
<br/><br/>
tag:debian.2.n7.nabble.com,2006:post-4569098Re: Git Packaging Round 2: When to Salsa2019-09-14T10:44:44Z2019-09-14T10:44:44ZInaki Malerba
On 13/9/19 15:20, Bastian Blank wrote:
<br/>&gt; For this I need to use my veto as Salsa admin. &nbsp;With the CI people we
<br/>&gt; have to work through too much problems first.
<br/><br/>If there are _too much problems_ I think you should, at least,
<br/>communicate with us.
<br/><br/>Besides two issues[0][1] reported some time ago -which are both waiting
<br/>for your feedback- nobody has reached us. You are more than welcome to
<br/>write us so we can talk about the best way to continue.
<br/><br/>Forbidding something you don't like without further explanation doesn't
<br/>seem to be the best way to go (applies to all Salsa matters).
<br/><br/><br/>On 13/9/19 18:00, Sam Hartman wrote:
<br/>&gt; I'll remove it from the next version.
<br/><br/>I hope we can discuss this a bit further. There's a lot of work invested
<br/>on the project and the main goal is to increase Debian's workflow quality.
<br/><br/>&gt; On 13/9/19 18:00, Sam Hartman wrote:
<br/>&gt; Are there additional resources either the salsa admins or the salsa CI
<br/>&gt; team needs to move forward to a place where you'd both feel comfortable
<br/>&gt; recommending Salsa CI?
<br/><br/>It would be great to find a way to discuss things between Salsa admins
<br/>and users. It's been one way only so far.
<br/><br/><br/>Thanks.
<br/><br/><br/>0_ <a href="https://salsa.debian.org/salsa-ci-team/pipeline/issues/93" target="_top" rel="nofollow" link="external">https://salsa.debian.org/salsa-ci-team/pipeline/issues/93</a><br/>1_ <a href="https://salsa.debian.org/salsa-ci-team/pipeline/issues/94" target="_top" rel="nofollow" link="external">https://salsa.debian.org/salsa-ci-team/pipeline/issues/94</a><br/><br/>--
<br/>- ina
<br/><br/>