Bug#1004335: ITP: python-tcolorpy -- apply true color for terminal text

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-tcolorpy
  Version : 0.1.1
  Upstream Author : Tsuyoshi Hombashi 
* URL : https://github.com/thombashi/tcolorpy/
* License : Expat
  Programming Lang: Python
  Description : apply true color for terminal text

 tcolopy is a Python library to apply true color for terminal text. It supports
 foreground and background color in addition to styles like "bold", "italic",
 etc.

I intend to maintain it as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmHvwIwRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wqr0wf/UaUCVQG+9UhaEE9qZoI1YoruqjHO3ehg
W9rtiLxuSaOVQQnKe8mBlMSQu/Ivpo9gu/Zg5hAYwo8vKn6foSwX84t/6rXSlYXn
A42Pfc7yrfw9q981T/ko5F8AUeq05Q9fT6P2ZyxZRB9c70zg33AWD4oa5ct8uFOO
kGe7RQE2oSJPUPZGf47T5kpvtxyR2kituM20QAiCrr2ncmMhuWR6Ka4jIW3lJWio
o/Opne3cJFO5AL5ORTDRON+ltvdHCA4mmLzvRWqtotCahlm6XeU9F0osJBnVCtQZ
Y8cNhgn4RtKWyMdiMOzXtQlUoY158UUkOp7tzL84Cze5qxXGudW/mg==
=f2X9
-END PGP SIGNATURE-

UDD upstream importer seems to fail randomly for sf.net

[Andreas Tille]

Hi,

when checking UDD dashboard for the Debian Med team[1] I see lots of

   debian/watch: uscan returned an error: In debian/watch no matching files for 
watch line http://sf.net/

expressions.  I suspect that this affects all packages hosted at
SourceForge.  When running uscan manually on my local machine uscan
works nicely for at least five examples I've checked.  It seems there
are circumstances when the UDD importer just fails while the watch file
is perfectly OK?

I checked UDD (mirror) for success and failure when scanning
http://sf.net/ watch files:

udd=> SELECT sf_success, count(*) from (select source, case when warnings like 
'In debian/watch no matching files for watch line%' THEN 'Fail' ELSE 'Success' 
END as sf_success from upstream where watch_file like '%http://sf.net/%') as 
tmp group by sf_success ;
 sf_success | count 
+---
 Success|   731
 Fail   |   544

I wanted to check the packages of Debian Med team and got:

udd=> select source, watch_file, case when warnings like 'In debian/watch no 
matching files for watch line%' THEN 'Fail' ELSE 'Success' END as sf_success 
from upstream where watch_file like '%http://sf.net/%' and source in (select 
distinct source from sources where maintainer_email = 
'debian-med-packag...@lists.alioth.debian.org' and release = 'sid') order by 
sf_success, source;
  source   |  
watch_file  | sf_success 
---+--+
 amide | # See uscan(1) for format  
 +| Fail
   |
 +| 
   | # Compulsory line, this is a version 3 file
 +| 
   | version=3  
 +| 
   |
 +| 
   | http://sf.net/amide/amide-(1.*)\.tgz   
 +| 
   |
  | 
 codonw| version=4  
 +| Fail
   | opts="uversionmangle=s/_/./g" \
 +| 
   | http://sf.net/codonw/CodonWSourceCode_([0-9_]+)\.tar\.gz   
 +| 
   |
  | 
 ctn   | version=4  
 +| Fail
   | opts=dversionmangle=s/([~\+]dfsg)// \  
 +| 
   |   
http://sf.net/mirctn/mirctn-(\d[\d\.]+)\.(?:tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) 
  +| 
   |
  | 
 emboss-explorer   | version=4  
 +| Fail
   | http://sf.net/embossgui/emboss-explorer-(.*)\.tar\.gz  
 +| 
   |
  | 
 fis-gtm   | version=4  
 +| Fail
   | http://sf.net/fis-gtm/fis-gtm-V(\d\.\d-\d+[A-F]*)\.tar\.gz 
 +| 
   |
  | 
 fsa   | version=4  
 +| Fail
   | opts="repacksuffix=+dfsg,dversionmangle=s/\+dfsg//g" \ 
 +| 
   |   
http://sf.net/fsa/f

Re: Back to the topic of changed binary named (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))

[Stephan Lachnit]

On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille  wrote:
>
> However, my point was that I want to know what policy ftpmaster applies
> to new binary names and to focus on this topic.  I really want to know
> that policy of ftpmaster and I really would like to see that documented
> and I'm afraid that thread is drifting away from the original topic
> that I will not get any answer on this.
>
> So again: I see a conflict in my interpretation of the mail[1] (original
> posters again in CC) which suggests "an auto-approver" and what I'm
> currently observing and I would be really happy if we can document the
> policy for changed (and new) binary names of existing source packages.

Since I feel my mail went lost in the discussion, here again my opinion:

Option C. New binary packages where the src is already in Debian can
still go through NEW for sanity checks, but do not require a
d/copyright review. These packages should be checked with priority
since they should be quick to review. Same goes for source packages
renames.

Instead, I suggest starting a "d/copyright review lottery" working
group with the goal to review the d/copyright of every package in
testing if changed since the last stable release, especially before
the next stable release. I would personally join this endeavor and
help to write tools to keep track of which packages are "eligible" for
the lottery.
This offloads a lot of work from the ftp-masters and in making regular
d/copyright reviews for all packages split among project members
should also increase the quality of these.

On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille  wrote:
>
> To give another example which has nothing todo with ABI changes:
> Currently I'm afraid of splitting some Arch: all data from some
> Arch: any package since I'm simply afraid of the changed package
> sticking long in new queue.  I know this is bad - but I consider
> users waiting for package updates worse.

On Mon, Jan 24, 2022 at 7:49 PM Theodore Y. Ts'o  wrote:
>
> As far as I know, ftpmaster requires a long, laborious review every
> single time there is a new binary package released.  As a result, it
> strongly disincentivizes maintainers from packaging up new releases
> because it's a pain in the posterior.  A while back, people asked me I
> could update f2fs-tools, and it was shortly before the release freeze,
> and even though there was apparently security fixes involved that
> would be fixed in the latest version of f2fs-tools, I knew there would
> be no point, since there was no way the package would squirt out the
> review pipeline before the release freeze.
>
> Even if it isn't formal policy, the long delay has happened enough
> times that I just assume it will be there, and it influences my
> behavior accordingly.

These are just two examples where the delay of updates in the NEW
queue affects the quality of a package or a Debian release - while it
should do the opposite. I'm sure there are many more, I'm not a DD for
a long time but I heard the "won't make improvement xyz because of the
NEW queue" argument regularly. IMHO if there is not a sudden increase
of review time from the ftp-masters, something needs to be done before
packages start losing quality due to NEW.

Regards,
Stephan

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Andreas Tille]

Am Mon, Jan 24, 2022 at 06:50:17PM -0500 schrieb Theodore Y. Ts'o:
> 
> So could the Release Team figure out a way to automatically rebuild
> packages that have source dependencies on static libraries?
> 
> This would solve the problem of new binary packages causing a full
> ftpmasters policy review of packages, at least for those who need to
> create new binary packages each time SONAME gets bumped.

If I were a member of the release team I would wait until this thread
might uncover some statement by ftpmaster whether this full review
is actually intended or the waiting time is rather caused by the lack
of an appropriate automatic tool that needs to be written.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Phil Morrell]

On Mon, Jan 24, 2022 at 01:49:19PM -0500, Theodore Y. Ts'o wrote:
> On Mon, Jan 24, 2022 at 08:15:30AM +0100, Andreas Tille wrote:
> > 
> > its surely an interesting topic how to avoid binary name changes and its
> > also interesting to discuss ABI changes and workarounds.
> > 
> > However, my point was that I want to know what policy ftpmaster applies
> > to new binary names and to focus on this topic.
> 
> As far as I know, ftpmaster requires a long, laborious review every
> single time there is a new binary package released.  As a result, it
> strongly disincentivizes maintainers from packaging up new releases
> because it's a pain in the posterior.
> 
> Even if it isn't formal policy, the long delay has happened enough
> times that I just assume it will be there, and it influences my
> behavior accordingly.

I like the earlier thread idea of de-coupling the copyright review
(eventually of NEW entirely? but for now, just bin NEW) from "the other
checks and balances". Ultimately, a mistake in debian/copyright *can* be
just considered a bug with priority determined just like any other, so
long as it is still legal for Debian to distribute. However, this is an
issue whenever upstream ships a new source file, not when a new binary
is added, so I hope that good maintainers do their due diligence on new
upstream releases.

If that is agreed informally, then while a lottery review would be a
cool addition, it would not be a prerequisite to dropping its
requirement for sources which have already been accepted into the
archive once. This could be formalised via a GR empowering the FTP team.

That last has made me wonder if the ftp-master team could split the NEW
source queue into two phases, one where a copyright review is performed
and one where the other checks are. I can see pros and cons for either
way round these phases could be done, but one should feed into the
other. Presumably, that this has not already happened means there would
be little benefit because of context switching?


signature.asc
Description: PGP signature

Re: Back to the topic of changed binary named

[Phil Morrell]

On Tue, Jan 25, 2022 at 10:50:01AM +0100, Stephan Lachnit wrote:
> On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille  wrote:
> >
> > However, my point was that I want to know what policy ftpmaster applies
> > to new binary names and to focus on this topic.  I really want to know
> > that policy of ftpmaster and I really would like to see that documented
> > and I'm afraid that thread is drifting away from the original topic
> > that I will not get any answer on this.
> >
> > So again: I see a conflict in my interpretation of the mail[1] (original
> > posters again in CC) which suggests "an auto-approver" and what I'm
> > currently observing and I would be really happy if we can document the
> > policy for changed (and new) binary names of existing source packages.
> 
> Since I feel my mail went lost in the discussion, here again my opinion:

It's not been lost, there has been lots of discussion around the lottery
idea C, but in changing the email subject I believe Andreas is trying to
draw the distinction between the request to document *current* practice
and your subthread about possible improvements to the overall process.


signature.asc
Description: PGP signature

Re: UDD upstream importer seems to fail randomly for sf.net

[Mattia Rizzolo]

On Tue, Jan 25, 2022 at 10:36:52AM +0100, Andreas Tille wrote:
> Hi,
> 
> when checking UDD dashboard for the Debian Med team[1] I see lots of
> 
>debian/watch: uscan returned an error: In debian/watch no matching files 
> for watch line http://sf.net/
> 
> expressions.  I suspect that this affects all packages hosted at
> SourceForge.  When running uscan manually on my local machine uscan
> works nicely for at least five examples I've checked.  It seems there
> are circumstances when the UDD importer just fails while the watch file
> is perfectly OK?
> 
> I checked UDD (mirror) for success and failure when scanning
> http://sf.net/ watch files:
> 
> udd=> SELECT sf_success, count(*) from (select source, case when warnings 
> like 'In debian/watch no matching files for watch line%' THEN 'Fail' ELSE 
> 'Success' END as sf_success from upstream where watch_file like 
> '%http://sf.net/%') as tmp group by sf_success ;
>  sf_success | count 
> +---
>  Success|   731
>  Fail   |   544
…
> I admit I can not see any pattern inside the watch files - may be its
> just a "bad timing" effect.  Any ideas are welcome.

I blame the network, most likely just a temporary glitch *shrugs*.

With so many moving pieces it happens every so often...

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Services offered by Debian should be dogfooding the real packages on DSA hosts.

[Phil Morrell]

On Mon, Jan 24, 2022 at 10:31:01AM +0100, Sébastien Delafond wrote:
> 
> As part of an upcoming survey that we are preparing, we plan to ask
> Debian developers to rank, by order of importance, the most popular
> ideas of improvements for Debian.
> 
> That's where you come into play: it would be nice if you could share
> what are — according to you — the most important projects/improvements
> that Debian ought to make. You can share your ideas here by replying to
> this email, but it would be interesting to file them as new issues in
> the "grow-your-ideas" project and then reply here pointing to your new
> issue:

I have raised https://salsa.debian.org/debian/grow-your-ideas/-/issues/15

# The problem

If I had a magic wand, I would like to resolve the situation around
official instances of packaged servers being unable to dogfood their
packaging work. I think this sends the wrong message as "If it's not
good enough for Debian to use, why should I?".

# Actual situation

From what I've noticed in DebConf talks, it's explained by the fact the
service maintainers do not have root access on DSA machines. This leads
to either using upstream installation methods or deploying to non-DSA
machines. It seems to me that this is either a solved problem, or can be
made so, given it's similar to University provided computing resources.

# Expected situation

For (a simplified) example that I'm familiar with, matrix.debian.social
should be as trivial as `apt install matrix-synapse` plus a config file.
Going by the existing docs on apache vhosts and email, one possible
interface would be:

echo matrix-synapse >> /srv/foo.debian.org/packages/install
vi /srv/foo.debian.org/packages/etc/matrix-synapse/conf.d/social.yaml
sudo -u foo package-setup foo.debian.org

The permitted packages and config paths could even be managed by a
whitelist under the control of DSA to prevent a complete wildwest. The
important thing is that a service owner can make (certain) direct
changes without having to co-ordinate DSA approval.

# Additional information

I first wrote directly to debian-admin but that list isn't publicly
archived, so I'll only paraphrase the response I got:

* Installation + configuration can have a risk of privilege escalation
* DSA might be happy with MRs to the puppet setup for the simple cases
* There is no external testing on the current puppet code, holding back
  collaboration by non-DSA
* There have been small experiments with containerisation (IMO, that's
  abandoning the strength of Debian's *integration*)


signature.asc
Description: PGP signature

Bug#1004357: ITP: package-notes -- Tools to add packaging metadata to ELF files

[Luca Boccassi]

Package: wnpp
Severity: wishlist
Owner: "Luca Boccassi" 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: package-notes
  Version : 0.4
  Upstream Author : various
* URL : https://github.com/systemd/package-notes
* License : CC0-1.0
* Programming Lang: Shell and Python
* Description : Tools to add packaging metadata to ELF files

Tools to generate a linker script to add package metadata to the ELF
binaries being built. See:
https://systemd.io/COREDUMP_PACKAGE_METADATA/

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Vincent Bernat]

 ❦ 21 January 2022 09:51 -05, M. Zhou:

> I'd rather propose choice C. Because I to some extent understand
> both sides who support either A or B. I maintain bulky C++ packages,
> and I also had a little experience reviewing packages on behalf of
> ftp-team.

I didn't comment at first because I thought someone else would raise the
idea. But it seems people still like the idea of a NEW queue. Not me.
The NEW queue is a hindrance. I have stopped contributing to Python
stuff for this reason. Packaging something can take weeks because you
need to upload one package, wait for it to be reviewed, then package the
next one, etc. You could upload many packages at once, but it makes
testing and building more difficult. New contributors may just give up
by the time their first package is accepted. I think we have many
unmaintained packages for this reason (no real stats on my side, but
when a package is several versions late, it's usually a sponsored upload
or one of my packages).

I would propose that there should be a reputation system. You can get
points by uploading stuff without issues and lose them if there are
errors. If you have enough points, you can spend them to skip the check.
But someone would have to implement it and the team being understaffed
for whatever reason (and maybe not convinced by this system), I know
this won't be done (we don't have PPA because FTP team wants to
implement it but no time, we don't have autosigned packages because
nobody has time to implement it, etc).

For me, the copyright check is just a bad excuse. People upload
non-distributable stuff everywhere and it seems the world continue to go
round. What amount of non-distributable packages is stopped by the NEW
queue?

I think we should forego the NEW queue. If people want to check
packages, they can do it once they are in unstable with regular bugs.
Current checks are partly done by Lintian and I suppose people could
watch new Lintian warnings and detect bad packages quickly. This could
be done when src is not NEW as a test. People could loose their upload
rights if they are caught abusing the system (and get DM rights for some
selected packages instead). This could be opt-in if people find this
idea offensive.
-- 
Avoid temporary variables.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Jonas Smedegaard]

Quoting Vincent Bernat (2022-01-25 21:38:01)
> I didn't comment at first because I thought someone else would raise 
> the idea. But it seems people still like the idea of a NEW queue. Not 
> me. The NEW queue is a hindrance.

For the record, I don't "like" the NEW queue.

I don't like current copyright laws, and I suspect a fair amount of 
people involved in Free Software doesn't.

I just don't think the solution is to ignore copyright or licensing 
statements.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Vincent Bernat]

 ❦ 25 January 2022 21:51 +01, Jonas Smedegaard:

>> I didn't comment at first because I thought someone else would raise 
>> the idea. But it seems people still like the idea of a NEW queue. Not 
>> me. The NEW queue is a hindrance.
>
> For the record, I don't "like" the NEW queue.
>
> I don't like current copyright laws, and I suspect a fair amount of 
> people involved in Free Software doesn't.
>
> I just don't think the solution is to ignore copyright or licensing 
> statements.

I mentioned it. No need to ignore, just file regular bugs. I said:

> For me, the copyright check is just a bad excuse. People upload
> non-distributable stuff everywhere and it seems the world continue to
> go round. What amount of non-distributable packages is stopped by the
> NEW queue?
-- 
Use the "telephone test" for readability.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Russ Allbery]

Jonas Smedegaard  writes:

> I just don't think the solution is to ignore copyright or licensing
> statements.

That's not the goal.  The question, which keeps being raised in part
because I don't think it's gotten a good answer, is what the basis is for
treating copyright and licensing bugs differently than any other bug in
Debian?

The need for pre-screening was obvious when we had export control issues,
but my understanding is that those have gone away.  Are we working from
legal advice telling us that this pre-screening is required for some legal
purpose?  If so, is it effective for the legal purpose at which it is
aimed?  Is this system left over from old advice?  Have we checked our
assumptions recently?

NEW processing is a lot of friction for the project as a whole and a lot
of work for the ftp team.  If we were able to do less work at the cost of
a minimal increase in bugs, or at the cost of handling bugs a bit
differently, maybe that would be a good thing?

In other words, it's unclear what requirements we're attempting to meet
and what the basis of those requirements is, which makes it hard to have a
conversation about whether the current design is the best design for the
problem we're trying to solve.

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

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

[Erik Huelsmann]

Hi Russ,

> > I just don't think the solution is to ignore copyright or licensing
> > statements.
>
> That's not the goal.  The question, which keeps being raised in part
> because I don't think it's gotten a good answer, is what the basis is for
> treating copyright and licensing bugs differently than any other bug in
> Debian?

Sorry to barge in (not being a Debian dev): Having seen this
discussion go back and forth on the topic, I agree that this is the
question. However, after all these mails - including yours - I'm left
with: Posing the question is one thing, but getting it answered is
another. Is there anybody specifically more likely to have an answer
here than anybody else? And if so, is that person/group involved in
this discussion now? If not, shouldn't they be made aware of it?

> The need for pre-screening was obvious when we had export control issues,
> but my understanding is that those have gone away.  Are we working from
> legal advice telling us that this pre-screening is required for some legal
> purpose?  If so, is it effective for the legal purpose at which it is
> aimed?  Is this system left over from old advice?  Have we checked our
> assumptions recently?
>
> NEW processing is a lot of friction for the project as a whole and a lot
> of work for the ftp team.  If we were able to do less work at the cost of
> a minimal increase in bugs, or at the cost of handling bugs a bit
> differently, maybe that would be a good thing?
>
> In other words, it's unclear what requirements we're attempting to meet
> and what the basis of those requirements is, which makes it hard to have a
> conversation about whether the current design is the best design for the
> problem we're trying to solve.


-- 
Bye,

Erik.

Bug#1004367: ITP: golang-inet-netstack -- Pure Go network stack

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen 

* Package name: golang-inet-netstack
  Version : 0.0~git20211120.8aa80cf2-1
  Upstream Author : inet.af
* URL : https://github.com/inetaf/netstack
* License : Apache-2.0
  Programming Lang: Go
  Description : A pure Go network stack

 This is a "fork" of gvisor, extracting out just the "netstack" networking
 bits, which previously were self-contained at
 https://github.com/google/netstack.  Why?  Because gVisor's go.mod is 
 gigantic and causes problems to people trying to use it as a library.

Required by newer NNCP versions

Cloud team plans for cloud-hosted mirrors

[Ross Vandegrift]

Hello,

The cloud team wants to make folks aware of a possible change to the cloud
images.  The team plans to register a new domain, debian.cloud, for mirrors
inside of cloud provider infrastructure.  For such mirrors, sources.list will
look like:
  deb http://.debian.cloud/debian/ bullseye main

Hosting mirrors inside the cloud infrastructure provides users with faster,
cheaper access to the archive.  And since it saves the providers money, they're
often willing to provide the hosting infrastructure for free.  Our image build
process allows customizing sources.list with these mirrors when possible.  All
of this is great!

But some of the hostnames are controlled by the cloud providers.  Mostly, this
has happened when the name is assigned by a CDN.  This isn't optimal: if that
name ever changes, users with the old hostname will be unable to install
packages.

These names have been very stable.  But in some providers, they're tied to
cloud accounts.  This makes it impossible to move the mirror to another account
without losing the name.  And of course, for reasons [1], we need to move some
of these mirrors.

Since a migration is required, we'd like to adopt debian-controlled hostnames
in sources.list.  This way, we can never lose the hostnames that appear in
sources.list.

Our first choice would be a subzone of debian.org.  But we are not in DSA, and
haven't been able to get help with this request.  So in the interest of making
progress, a new domain is the simplest alternative.

I don't know when this work will be complete - hopefully, all of the new
infrastructure will be ready to go for the next stable release.

Thanks,
Ross

[1] - Briefly: some of Debian's cloud accounts are technically owned by
individual developers, or consulting houses that work on Debian.  
Unfortunately, we can't just transfer the accounts in question to SPI, since
some also host other things.  Thus the team has slowly been transitioning
workloads into new accounts owned by SPI.

Re: Cloud team plans for cloud-hosted mirrors

[Marc Haber]

On Tue, 25 Jan 2022 21:47:49 -0800, Ross Vandegrift
 wrote:
>The cloud team wants to make folks aware of a possible change to the cloud
>images.  The team plans to register a new domain, debian.cloud, for mirrors
>inside of cloud provider infrastructure.  For such mirrors, sources.list will
>look like:
>  deb http://.debian.cloud/debian/ bullseye main

Are the IP ranges of the Cloud Providers registered that badly that
deb.debian.org wouldn't reliably point to the mirrors inside the
provider's infrastructure? Or are the cloud providers' mirrors
differnet from what we expect from a Debian mirror?

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

Do we need to hide packages in NEW queue (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))

[Andreas Tille]

Am Tue, Jan 25, 2022 at 01:45:11PM -0800 schrieb Russ Allbery:
> Jonas Smedegaard  writes:
> 
> > I just don't think the solution is to ignore copyright or licensing
> > statements.
> 
> That's not the goal.  The question, which keeps being raised in part
> because I don't think it's gotten a good answer, is what the basis is for
> treating copyright and licensing bugs differently than any other bug in
> Debian?
> 
> The need for pre-screening was obvious when we had export control issues,
> but my understanding is that those have gone away.  Are we working from
> legal advice telling us that this pre-screening is required for some legal
> purpose?  If so, is it effective for the legal purpose at which it is
> aimed?  Is this system left over from old advice?  Have we checked our
> assumptions recently?

May be some intermediate step would be to not hide packages in NEW queue
but exposing them as an apt source.  If I'm correct this is not the case
since it had certain legal consequences for the project if code with
certain non-free licenses would be downloadable from some debian.org
address.  May be NEW could be considered as some kind of pre-non-free as
long as it is not checked and the legal consequences are not valid for
us any more.  But I'm not educated in international law - just asking
whether somebody might know better.

I'd consider it a big step forward to develop against packages from NEW
queue.  (And yes, *I* know how to help myself with a local mirror but
team wide development is something else.)
 
> NEW processing is a lot of friction for the project as a whole and a lot
> of work for the ftp team.  If we were able to do less work at the cost of
> a minimal increase in bugs, or at the cost of handling bugs a bit
> differently, maybe that would be a good thing?
> 
> In other words, it's unclear what requirements we're attempting to meet
> and what the basis of those requirements is, which makes it hard to have a
> conversation about whether the current design is the best design for the
> problem we're trying to solve.

I'm CCing debian-legal for this branch of the discussion (but I do not
read this list and think keeping debian-devel in the row is a good idea).

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Re: Cloud team plans for cloud-hosted mirrors

[Ross Vandegrift]

On Wed, Jan 26, 2022 at 07:25:18AM +0100, Marc Haber wrote:
> On Tue, 25 Jan 2022 21:47:49 -0800, Ross Vandegrift
>  wrote:
> >The cloud team wants to make folks aware of a possible change to the cloud
> >images.  The team plans to register a new domain, debian.cloud, for mirrors
> >inside of cloud provider infrastructure.  For such mirrors, sources.list will
> >look like:
> >  deb http://.debian.cloud/debian/ bullseye main
> 
> Are the IP ranges of the Cloud Providers registered that badly that
> deb.debian.org wouldn't reliably point to the mirrors inside the
> provider's infrastructure? Or are the cloud providers' mirrors
> differnet from what we expect from a Debian mirror?

deb.debian.org is served from fastly and AWS CDNs - so it's outside of most
cloud provider's infrastructure.

Ross