Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Tobias Frost]

On Fri, Apr 05, 2024 at 09:49:58PM +0200, Aurelien Jarno wrote:
> On 2024-04-04 22:38, Bill Allombert wrote:
> > On Thu, Apr 04, 2024 at 01:22:19PM -0700, Russ Allbery wrote:
> > > I'm not sure what I think about that.  We have a general escape hatch
> > > already for non-free packages in Policy 2.2.3 that says they may not fully
> > > comply with Policy, which may be sufficient. 
> > 
> > But precisely, we _do_ want non-free packages that are built on the 
> > autobuilders
> > to comply with this requirement. So we do not want 2.2.3 to apply in that
> > specific case. It seems cleaner to say that the requirement only apply if
> > Autobuild: yes is declared.
> 
> If we go that route, here is a proposed alternative patch:
> 
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -338,7 +338,8 @@
>  For example, the build target should pass ``--disable-silent-rules``
>  to any configure scripts.  See also :ref:`s-binaries`.
>  
> -For packages in the main archive, required targets must not attempt
> +Except for packages in the non-free archive with the ``Autobuild``
> +control field unset or set to ``no``, required targets must not attempt
>  network access, except, via the loopback interface, to services on the
>  build host that have been started by the build.

Seconded as well. 

(I think the other version is fine too; Another thought: Can't (some) non-free
non-autobuildable be tought not do download at build time? I think it should 
be encouraged to download only if there is no other way…)

-- 
tobi

> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://aurel32.net


signature.asc
Description: PGP signature

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free

[Tobias Frost]

On Wed, Apr 03, 2024 at 10:58:37PM +0200, Aurelien Jarno wrote:
> Hi,
> 
> On 2024-04-03 12:37, Philipp Kern wrote:
> > Hi,
> > 
> > On Tue, Apr 02, 2024 at 06:58:35AM +0200, Aurelien Jarno wrote:
> > > On 2024-04-02 09:21, Sean Whitton wrote:
> > > > Hello,
> > > > 
> > > > On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote:
> > > > 
> > > > > The debian policy, section 4.9, forbids network access for packages in
> > > > > the main archive, which implicitly means they are authorized for
> > > > > packages in contrib and non-free (and non-free-firmware once #1029211 
> > > > > is
> > > > > fixed).
> > > > >
> > > > > This gives constraints on the build daemons infrastructure and also
> > > > > brings some security concerns. Would it be possible to extend this
> > > > > restriction to all archives?
> > > > 
> > > > We need to know if this is going to break existing packages and allow
> > > > some input from their maintainers.  Are you able to prepare a list of
> > > > the affected packages?
> > > 
> > > Fair enough. I can work on that, but help would be welcome as my
> > > resources are limited.
> > 
> > I did a test rebuild of contrib, non-free and non-free-firmware packages
> > in sid with both stable sbuild schroot and unshare backends and could
> > not find a difference in build success (i.e. what failed failed in both,
> > what succeeded succeeded in both).
> 
> Thanks Philipp. Following that result, please find a patch proposal: 
> 
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -338,9 +338,9 @@
>  For example, the build target should pass ``--disable-silent-rules``
>  to any configure scripts.  See also :ref:`s-binaries`.
>  
> -For packages in the main archive, required targets must not attempt
> -network access, except, via the loopback interface, to services on the
> -build host that have been started by the build.
> +Required targets must not attempt network access, except, via the
> +loopback interface, to services on the build host that have been started
> +by the build.
>  
>  Required targets must not attempt to write outside of the unpacked
>  source package tree.  There are two exceptions.  Firstly, the binary
> 
> Regards
> Aurelien

LGTM, Seconded.

> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://aurel32.net




signature.asc
Description: PGP signature

Bug#941198: In support of mandatory unit files

[Tobias Frost]

Am Samstag, den 07.12.2019, 17:12 -0800 schrieb Russ Allbery:
> Tobias Frost  writes:
> 
> > JFTR, I maintain gmedia-resurrect and in this package I failed
> > despite
> > trying to create a systemd unit file with equal functinality as the
> > init.d script*.  So for this package the proposoal would lead to
> > regressions for the users.
> 
> A Policy should means that if there is some stronger reason (such as
> that
> adding a unit file would introduce new bugs), there is nothing
> requiring
> you to do so.  It indicates that not having a unit file is a bug, but
> it's
> just a bug, and Debian packages are not expected to be bug-
> free.  Other
> bugs may be more important.

Well, I was responding to a mail that suggested to make unit files
mandatory (which I read as then RC-buggy) and suggesting some lines
later to drop support for the sysv-generator and in this case it is
quite moot that policy can be ignored because I fear that once
unit files would become mandatory that would be used as an argument to
drop support for the generator. 

> That said, if you'd like help with this, I or someone else following
> this
> thread may be willing to take a look and figure out a way to
> replicate the
> init script behavior.  It's normally possible to handle /etc/default
> conffiles in systemd units, although it can be a little complicated.

Sure, help fir that would be nice. Thanks for the offer.
(Probably should have an own bug for that.) Nethertheless, this is the
line that causes my problems and needs to be transferred:
https://salsa.debian.org/debian/gmrender-resurrect/blob/master/debian/gmediarender.default#L8

-- tobi

Bug#941198: In support of mandatory unit files

[Tobias Frost]

On Wed, Dec 04, 2019 at 07:03:09PM +0100, Simon Richter wrote:
> Hi,
> 
> chiming in as I've been pointed to this bug: I agree with Ansgar in that
> adding unit files does not hurt sysvinit support in the least, provided we
> still get to ignore them.
> 
> I'd even be in favour of making them mandatory (i.e. upgrading the lintian
> warning to an error), and I don't see how the GR outcome would affect the
> question of whether we want to ship unit files in packages, so I'd be fine
> with going ahead with this change even while the GR is still running.
> 
> As long as we support sysv-rc, init scripts will have to remain mandatory
> as well, though.
> 
> IMO, an ideal outcome would be that systemd can completely ignore any init
> scripts from Debian packages, i.e. the compatibility generator, if
> installed, would only have to generate units for init scripts that didn't
> come from a package, and default installations would not include this
> generator.

JFTR, I maintain gmedia-resurrect and in this package I failed despite trying
to create a systemd unit file with equal functinality as the init.d script*.
So for this package  the proposoal would lead to regressions for the users.
 
> The same should be done for cron files vs timer units -- ideally, we'd get
> to a state where cron files can be completely ignored by systemd because it
> is a bug to not have a timer unit with the same settings. That would allow
> systemd users to get rid of the spurious wakeups as well, which I'd
> consider a major win.
> 
>Simon

* I do not have currently the amount of spoons avialable to explain the details,
but it has to do with the confile in /etc/default needed to be read by the unit
file and parsed into daemon parameters.

Bug#843966: developers-reference-fr: translation update

[Tobias Frost]

Am 18. November 2018 14:38:02 GMT+02:00 schrieb Holger Wansing 
:
>Hi Jean-Paul and Tobias,

(...)

>@Tobias: maybe you received an answer from Jean-Paul via PM?

No, I did not get a response
>
>
>Holger

Bug#911650: [developers-reference] usage of dh_strip conflicts with debhelper documentation

[Tobias Frost]

Hi Josheph,

On Mon, Oct 22, 2018 at 07:31:58PM -0700, Joseph Herlant wrote:
> Package: developers-reference
> Version: 3.4.21
> Severity: normal
> 
> Hi,
> 
> Based on the man page of dh_strip[1], "the `--dbg-package` option is a
> now special purpose option that you normally do not need" which
> contradicts with the paragraph 6.7.9. )Best practices for debug
> packages) of the developers reference.
> 
> If I understand correctly we should say smoething like the wiki [3] says:
> If you use debhelper/9.20151219 or newer in Debian, it will generate
> debug symbol packages (as -dbgsym) for you with no additional
> changes to your source package.
> If you want to transition from a former -dbg package to a -dbgsym
> package you might want to look into the dh_strip's switch
> --dbgsym-migration=pkgname-dbg (<< currentversion~)' switch.
> 
> Am I correct assuming that it's the right thing to recommend?
> 
> If yes, I'll go ahead and do a merge request for that.

I think that would be great; my (related) merge request 
https://salsa.debian.org/debian/developers-reference/merge_requests/7
misses the information what to do when you mirgrate from manual to
automatic debug packages.
If you could extend this MR, that would be great ;-) TIA!

Cheers, 
tobi

Thanks a lot!

> Thanks
> Joseph
> 
> 1. https://manpages.debian.org/unstable/debhelper/dh_strip.1.en.html
> 2. https://www.debian.org/doc/manuals/developers-reference/ch06.html
> 3. https://wiki.debian.org/DebugPackage
> 


signature.asc
Description: PGP signature

Bug#908867: developers-reference: Updated German translation

[Tobias Frost]

Control: tags -1 +pending

MR has been merged.

Bug#907535: Let's start salvaging packages! -- draft text now available

[Tobias Frost]

Control: tags -1 pending
 
Merge-Request has been merged.

Bug#818850: developers-reference: two chapters regarding the 'default' field

[Tobias Frost]

Source: developers-reference
Followup-For: Bug #818850
Control: tags -1 patch

MR: https://salsa.debian.org/debian/developers-reference/merge_requests/8

Please review and if necessary just edit in the MR (or let me know what
you'd like to see changed) 

-- 
tobi


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#907665: developers-reference: Section 6.7.9 about dbg packages outdated

[Tobias Frost]

Control: tags -1 patch

I've wrote some kind of draft for the dbgsyms... Please
make sure to review the language and conten ;-)
(and edit directly in the MR if you want)

MR 
https://salsa.debian.org/debian/developers-reference/merge_requests/7

-- 
Cheers,
tobi

Bug#908890: developers-reference: As alioth is gone, replace references to Salsa

[Tobias Frost]

Package: src:developers-reference
Severity: normal
Tags: patch

I found during the translation to German that there are a few references
to alioth, but at this service is no longer, those references needs
updating.

MR: https://salsa.debian.org/debian/developers-reference/merge_requests/6

Please note that this MR needs reviewing, language and contentwise.
For example I'm not sure if section 4.12 should be deleted completly or
(like in the MR) described as past service…

Cheers,
-- 
tobi

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#908867: developers-reference: Updated German translation

[Tobias Frost]

Package: src:developers-reference
Version: 3.4.20
Severity: normal
Tags: patch

Please see the merge request 
https://salsa.debian.org/debian/developers-reference/merge_requests/3

(As soon as the salvaging MR is merged, I will also translate this)

Cheers,
-- 
tobi

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#907605: developers-reference: Alioth references in README-contrib

[Tobias Frost]

Control: tags -1 pending

On Thu, 30 Aug 2018 08:20:19 +0200 Tobias Frost >  
> I've preaded this MR for it:
> https://salsa.debian.org/debian/developers-reference/merge_requests/2
> 
MR is merged. (Thanks Raphaël!)

-- 
tobi

Bug#879863: developer-reference conflicts with Policy on priority "extra" vs "optional"

[Tobias Frost]

Control: tags -1 pending

MR has been merged.

Bug#907535: Let's start salvaging packages! -- draft text now available

[Tobias Frost]

Control: tags -1 patch

Merge-Request: 
https://salsa.debian.org/debian/developers-reference/merge_requests/5

--
Tobi

Bug#907666: developers-reference: (partially) updating the German translations

[Tobias Frost]

Package: developers-reference-de
Severity: minor
Tags: patch

Translating some previously untranslated sentences and checking other
which were marked fuzzy. Note that this is not complete, poedit says
there are still 115 tasks open... (I will time permitting, work a bit on
them the next few days and update the MR accordingly.)

Please see the MR here: 
https://salsa.debian.org/debian/developers-reference/merge_requests/3

-- 
tobi

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

developers-reference-de depends on no packages.

Versions of packages developers-reference-de recommends:
pn  debian-policy  

Versions of packages developers-reference-de suggests:
pn  doc-base  

Bug#907665: developers-reference: Section 6.7.9 about dbg packages outdated

[Tobias Frost]

Source: developers-reference
Severity: normal
Tags: patch

As we now have Automatic Debug Symbol package, I think most of the
section could be deleted and replaced to the references on the Wiki.

The attached patch does that…

-- 
tobi

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk
index 6f05ece..6a85f23 100644
--- a/best-pkging-practices.dbk
+++ b/best-pkging-practices.dbk
@@ -1795,58 +1795,32 @@ it in its official location).
 
 
 Best practices for debug packages
+
 
-A debug package is a package with a name ending in -dbg, that contains
-additional information that gdb can use.  Since Debian 
binaries are stripped by
-default, debugging information, including function names and line numbers, is
-otherwise not available when running gdb on Debian 
binaries.  Debug packages
-allow users who need this additional debugging information to install it,
-without bloating a regular system with the information.
-
-
-It is up to a package's maintainer whether to create a debug package or not.
-Maintainers are encouraged to create debug packages for library packages, since
-this can aid in debugging many programs linked to a library.  In general, debug
-packages do not need to be added for all programs; doing so would bloat the
-archive.  But if a maintainer finds that users often need a debugging version
-of a program, it can be worthwhile to make a debug package for it.  Programs
-that are core infrastructure, such as Apache and the X server are also good
-candidates for debug packages.
-
-
-Some debug packages may contain an entire special debugging build of a library
-or other binary, but most of them can save space and build time by instead
-containing separated debugging symbols that gdb can find 
and load on the fly
-when debugging a program or library.  The convention in Debian is to keep these
-symbols in 
/usr/lib/debug/path, where
-path is the path to the executable or library.  For
-example, debugging symbols for /usr/bin/foo go in
-/usr/lib/debug/usr/bin/foo, and debugging symbols for
-/usr/lib/libfoo.so.1 go in
-/usr/lib/debug/usr/lib/libfoo.so.1.
-
-
-The debugging symbols can be extracted from an object file using 
-objcopy --only-keep-debug.  Then the object file can be 
stripped,
-and objcopy --add-gnu-debuglink used to specify the path
-to the debugging symbol file. 
- objcopy 1
- explains in detail how this works.
-
-
-The dh_strip command in debhelper supports creating debug
-packages, and can take care of using objcopy to separate
-out the debugging symbols for you.  If your package uses debhelper, all you
-need to do is call dh_strip --dbg-package=libfoo-dbg, and
-add an entry to debian/control for the debug package.
+A debug package is a package that contains additional information that
+gdb can use.  Since Debian binaries are stripped by
+default, debugging information, including function names and line
+numbers, is otherwise not available when running gdb
+on Debian binaries.  Debug packages allow users who need this additional
+debugging information to install it, without bloating a regular system
+with the information.
 
+
 
-Note that the debug package should depend on the package that it provides
-debugging symbols for, and this dependency should be versioned.  For example:
+Previously is was up to a package's maintainer whether to create a debug
+package or not. You can still find those manually generated debug
+packages, whose package names generally ended with -dbg.
+
+However, since end of 2015 manually generating dbg packages are
+depreciated and has been replaced largely by automatic debug symbol
+generation, which will generate packages with names ending with -dbgsym.
+
+If you want to migrate your legacy -dbg package, please read
+https://wiki.debian.org/AutomaticDebugPackages;> here ,
+if you want to use the dbgsym packages, you can find instructions
+https://wiki.debian.org/HowToGetABacktrace;> here .
+
 
-
-Depends: libfoo (= ${binary:Version})
-
 
 
 Best practices for meta-packages

Bug#172892: best practices for CVS package handling

[Tobias Frost]

On Mon, 1 Jun 2015 15:59:30 +0900 Hideki Yamane 
wrote:
> control: tags -1 wontfix
> 
> Hi,
> 
>  Probably it was useful when reported in 2002, but we're in 2015 and
>  CVS was gone. so I'll tag wontfix for it.

Should we just close the bug?

Bug#907605: developers-reference: Alioth references in README-contrib

[Tobias Frost]

Package: src:developers-reference
Severity: minor
Tags: patch

Dear developers-reference maintainers,

there is still a reference to alioth in the file README-contrib.

I've preaded this MR for it:
https://salsa.debian.org/debian/developers-reference/merge_requests/2

Cheers,
-- 
tobi

Bug#907535: Let's start salvaging packages! -- draft text now available

[Tobias Frost]

Subject: developers-reference: Announcement for adding "Package Salvaging" 
process to dev-ref
Source: developers-reference
Severity: normal

Dear dev-ref maintainers,

as you've probably saw on -dev, I'm currently working to implement the
Package Salvaging process. The discussion is still ongoing but planed to
be closed on Saturday, September 1st. You can find the discussion here:

The thread starts at:
https://lists.debian.org/debian-devel/2018/07/msg00453.html,

You can find the proposal and call for discussion here:
https://lists.debian.org/debian-devel/2018/08/msg00277.html

I'm filing this bug report to make you aware of it, along with the
announcement that I will start finalizing the text on the weekend to be
able to provide a merge request shortly afterwards. My original timeline
was proposed in this message [1] , but I might not need the "adaption
period", as the input received was only on typos and grammar, not asking
for changes with regards to the process, so atm I think I ll be able to
come up with the patch to final discussion on Sunday, if that does not
change. (so this would accelerate the timeline by one week)

[1] https://lists.debian.org/debian-devel/2018/08/msg00207.html

Cheers,
-- 
tobi



signature.asc
Description: PGP signature

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

[Tobias Frost]

On Sat, Dec 30, 2017 at 12:24:19AM +, Simon McVittie wrote:
> On Fri, 29 Dec 2017 at 22:24:23 +0100, Markus Koschany wrote:
> > Am 29.12.2017 um 00:06 schrieb Jonathan Nieder:
> > I had to split the game into four digestible pieces (which are in total
> > 1.2 GB large). My original idea was to duplicate the copyright file for
> > all three data packages but back then this proposal has been harshly
> > rejected on debian-mentors (when I wasn't a DD yet) because the
> > copyright file would have mentioned files which are not part of a
> > specific source package.
> 
> For what it's worth, when I discussed splitting openarena-data with the
> ftp team (and then uploaded the split parts through NEW), they didn't
> object to the copyright files being identical, with each source package
> listing some copyright holders and licenses that actually only exist
> in the other source packages from the same group.
> 
> However, I can see that d-mentors wouldn't like that: people sponsoring
> random packages (that they themselves aren't necessarily involved or
> interested in) will tend to assume that this particular package doesn't
> deserve to be a special case, because 95% of the time it doesn't. Making
> pragmatic decisions like "this is not what I'd usually do, but in this
> case it makes more sense" requires enough context to understand the
> costs and benefits that apply.

Yes, cost/benefit should be considered (and was in this case).  But
please, one should not only evaulate _their_ cost but also the cost this
creates on other parties. The goal should be to reduce the overall
cost-sum.

For example, this particular issue was causing literally thouesands of
lintian stuff, so basically rasing the noise level far above the signal.
And it would have been easily fixed, as d/copyright was script-generated
and the script could have a check implemented to filter the output to
the respective packages.

> smcv
> 

Bug#737796: may be use the newly proposed License-grant field

[Tobias Frost]

On Mon, Sep 18, 2017 at 02:15:54PM +0200, Dominique Dumont wrote:
> Hi
> 
> Since the licence text shown in the original report mention "At the 
> discretion 
> of the user of this library,  this software may be licensed under the terms 
> of 
> ..." , I'm wondering if this would better fit in the new License-Grant field 
> [1].
> 
> Thoughts ?

I like this new feature and would be in favour making it real.

-- 
tobi

 
> All the best
> 
> [1] https://bugs.debian.org/786470
> -- 
>  https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
> http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org
> 

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Tobias Frost]

Am Freitag, den 04.08.2017, 22:46 +0200 schrieb Bill Allombert:
> On Fri, Aug 04, 2017 at 11:59:40AM -0700, Don Armstrong wrote:
> > > An O: bug means that it is confirmed that the package is
> > > orphaned, and
> > > gives permission to everyone to adopt the package immediately.
> > 
> > So just file an an Intent-To-Orphan bug. [This why I suggested to
> > file
> > the bug against the package, and not against wnpp.]
> > 
> > In N days, the bug can be filed against 
> 
> Nowadays orphaning is done by reuploading the package with the
> maintainer set to the QA group rather than using a O: wnpp bug.

NO. Simply NO. 
That behaviour would be really rude. 

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Tobias Frost]

Am Donnerstag, den 03.08.2017, 12:44 -0400 schrieb Sean Whitton:
> Hello Tobias,
> 
> Thank you for writing about this bug from the MIA team's perspective,
> which is very relevant to resolving this.
> 
> On Thu, Aug 03, 2017 at 08:44:36AM +0200, Tobias Frost wrote:
> > Some remarks / questions I do not see adressed:
> > - If you have not a name on some task human nature tends toward
> > that nonone
> > feels responsible at all. Like the German (fun) expansion of TEAM:
> > Toll, Ein
> > Anderer Machts (Great, someone else it taking care)
> 
> In most teams, this happens anyway -- I would take this as an
> argument
> against team maintenance more generally.
> 
> > - MANY team homepages are not updated or do not even exist. I think
> > before
> > droping the requirement to have human uploaders this needs to be
> > fixed by
> > policy and it must be RC(?) bug if the team homepage is
> > outdated/absent/inaccurate. The infomation about the teams *must*
> > be in a way
> > that it can be easily found/parsed.
> > - There is currently no way to map a person to a team or to map a
> > team to a
> > list of members -- if you need accurary. This is especially true
> > for teams
> > that are smaller. - - When someon is going e.g MIA, we need to know
> > which
> > teams are involved to trigger them.
> 
> For teams on alioth, would you find the list of team members on the
> alioth project insufficient?

The lists on alioth are hardly accurate. Also, as you say:

> I agree this doesn't help with teams that do not use alioth but are
> based around a mailing list.

This and in combination that team information is not in an defined
location makes it quite hard to find useful, accurate information.
Not mentioning that there is no way to do an lookup in which teams
someone is; so there is no way to trigger them to act when e.g someone
has left the project and did not clean up after them.

Some time ago I did some spring cleaning going over DDs that have
retired but still in the Maintainer/Uploader fields: There were quite a
 lot "team maintained" packages where the team did not recognize that
the (sole) Uploader wasn't there anymore and the packages were
bitrotting. Without the Uploader field there would have been excactly
zero change to find those packages and get them back into maintainance
again. 

 
> As Adrian said, it's not clear what an alternative to Uploaders would
> be for this purpose.  But I'm not sure that Uploaders is much use,
> either, because in so many teams it's simply not kept up-to-date.

Removing the requirement won't help here either; It would just mask
this fact and makes it harder for other parties to detect this.

I think the "how can I contact somone on the team" could be fixed, like
(brainstomring) e.g by a Team-Contact field in d/control with an human
contact and formalizing requirements on a Team so that they are allowed
to drop the Uploaders -- if they fulfill this requirements. One
requirement could be e.g  that the team has a site on the Wiki and we
need some central place to record the team members and a mandatory
enrollment process (like the yearly team member ping that the perl team
does, AFAIK)

> > - Not in all teams it is working tha everyone is looking at every
> > package.
> > During the lipng transistion I filed many bugs on team-managed
> > packages which
> > were never answered
> 
> Right, but having some random team members listed in Uploaders:
> doesn't help.

This is not the point I wanted to make: In my experience if there is
NOT a name tacked to an task, the likelyhood of noone will feel
responsible and the task not done is very high. 

> > - We have already the problem about "partially MIA" -- people
> > holding several
> > pacakgages but neglecting several of them. Currently we have no
> > real measures
> > of taking care of the neglected one, MIA team wise. This will be
> > amplified
> > when there is no human responsible person named.
> 
> Could you explain further how this would amplify the problem?  I
> agree
> that this is a serious problem, but I don't see how this change would
> amplify it.

Relates to the "if there is no name attached to a task" thing explained
above. 
Also mind that we really do not have processes at hand to handle those
situations. The MIA team has already now no actual power on "partially
MIA" situations, but in the past it often helped to write a nice mail.
If I write to the anonymity of a team mailing list, I guess those mails
will be more easily ignored.

-- 
tobi 

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Tobias Frost]

Am 2. August 2017 23:48:15 MESZ schrieb Sean Whitton :
>Hello,
>
>Here is an updated diff for this bug, against the docbook version of
>the policy manual.
>
>I've also included a purely informative change which emphasises that
>packages that are team maintained in name only should be orphaned
>properly, with their maintainer field set to the QA team.  This is
>already current best practice, but it's worth emphasising, because one
>might fail to orphan a package on the grounds that "someone else on the
>team might fix it", which is not true of a lot of teams.
>
>This purely informative change came out of a discussion at DebCamp with
>h01ger, gregoa and David Bremner.  We are CCing -devel because we want
>to determine if there remains, in 2017, a consensus that we should not
>drop this requirement.  We think that recent objections in the bug are
>about implementation details, rather than a concern to retain humans in
>the uploaders field.
>
>diff --git a/policy.xml b/policy.xml
>index 3daa532..4731507 100644
>--- a/policy.xml
>+++ b/policy.xml
>@@ -1128,13 +1128,6 @@
> described in .
>   
>   
>-If the maintainer of the package is a team of people with a
>shared
>-email address, the Uploaders control field
>must
>-be present and must contain at least one human with their
>personal
>-email address.  See  for the
>syntax
>-of that field.
>-  
>-  
>   An orphaned package is one with no current maintainer.  Orphaned
>   packages should have their Maintainer control
> field set to Debian QA Group
>@@ -1149,6 +1142,12 @@
>   
> 
>   
>+  
>+This includes packages with a group of people or team in the
>+Maintainer control field.  They should be
>+orphaned if the team is not actively maintaining the package.
>+  
>+
> 
> 
> 
>@@ -3448,13 +3447,6 @@ endif
>Maintainer field, and multiple entries must be comma separated.
> 
> 
>-  This is normally an optional field, but if the
>-  Maintainer control field names a group of
>-  people and a shared email address, the
>-  Uploaders field must be present and must
>-  contain at least one human with their personal email
>address.
>-
>-
> The Uploaders field in debian/control can
>   be folded.
> 

Dear all,

(Please appologize the brevity, I don't have the time needed to word that
properly)

Well, I still think that not having a human explicitly named as in charge of
the package is not good and will cause more damage than it will bring
benefits.
(Disclaimer: My view is biased with my actitivies in the MIA team)

Some remarks / questions I do not see adressed:
- If you have not a name on some task human nature tends toward that nonone
feels responsible at all. Like the German (fun) expansion of TEAM: Toll, Ein
Anderer Machts (Great, someone else it taking care)
- MANY team homepages are not updated or do not even exist. I think before
droping the requirement to have human uploaders this needs to be fixed by
policy and it must be RC(?) bug if the team homepage is
outdated/absent/inaccurate. The infomation about the teams *must* be in a way
that it can be easily found/parsed.
- There is currently no way to map a person to a team or to map a team to a
list of members -- if you need accurary. This is especially true for teams
that are smaller. - - When someon is going e.g MIA, we need to know which
teams are involved to trigger them.
- Not in all teams it is working tha everyone is looking at every package.
During the lipng transistion I filed many bugs on team-managed packages which
were never answered
- We have already the problem about "partially MIA" -- people holding several
pacakgages but neglecting several of them. Currently we have no real measures
of taking care of the neglected one, MIA team wise. This will be amplified
when there is no human responsible person named.

--
tobi

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#798476: debian-policy: don't require Uploaders

[Tobias Frost]

Am Freitag, den 08.07.2016, 17:36 +0200 schrieb Christian Hofstaedtler:
> * Julien Cristau  [160708 15:31]:
> > for some time I've been uploading packages with Maintainer set to a
> > mailing list and no Uploaders field.  In cases where some package
> > kind
> > of fit within a team, but noone cares specifically about that
> > individual
> > package, I feel it's better than setting Maintainer to the Debian
> > QA
> > Group, which policy currently says is required, since the team will
> > get
> > bug mail, and any updates to the package will probably come from
> > the
> > team anyway.  So I'd like to see this requirement relaxed.
> 
> I also want to see this. It makes lots of sense, especially for
> teams maintaining very large numbers of packages. Honestly, the
> individual package does not carry heavy weight in some of those
> teams. 

Mmm, In theory you're right. However in practice see also some
downsides. For at least some teams it is not very clear who is member
of it and on especially smaller teams it is sometimes quite unclear if
the team exists at all. 
Especially in such it will then be lots harder to actually detect an
orphaned package and this might even deter some person taking over the
package. 

> At the same time, many packages carry old Uploaders,
> including names of people that have long been known to be MIA, and
> are kept there only to avoid setting an empty Uploaders field.

Which makes this information invisible to people outside of the team. 

> These packages are clearly not not-maintained (teams care about
> them), so orphaning or assinging to Debian QA Group would make no
> sense whatsoever.

YMMV. That requires a hell of discipline in the team. 
There are many teams that take quite great care about the packages, but
others do not so well (or even existing only on paper anymore). 

>From my short time as MIA member I can tell it is already hard enough
to find persons being MIA; to track complete teams will be lot harder.
(
e.g the question who is actually a team member is sometimes hard to
answer from outside)

IMHO if the team commits to maintain that package it shouldn't be too much 
strain to add an explict carer too, is it? 

> (Also, as far as I'm aware, the large teams are
> all very open for anybody to join.)

For that people need to know that that particular package is up for
adoption. That information would be harder to retrieve. 
However wnpp could be used as a tool here: Why not advertise 
using a RFA and telling there that the team has open positions?

Maybe we should dicsuss this on -devel to get more other views and
arguments too?

-- 
tobi

Bug#768292: debian-policy: please allow copyright file to refer to license text in separate files

[Tobias Frost]

 Package: debian-policy
 Severity: wishlist

 [X-Debbugs-Cc: ftpmas...@debian.org because I know the Policy maintainers
 don't actually control what is or isn't acceptable in the archive in this
 respect.]

 Some packages currently have stanzas like this in their copyright files:

 License: MPL-2.0
  The complete text of the Mozilla Public License 2.0 can be found in
  the `MPL-2.0' file in the same directory as this file.

 It is not clear to me whether Debian Policy allows this. I would like it
 to be specifically allowed, unless there is some good reason not to; if
 ftp-master tools like whatever tool generates
 https://ftp-master.debian.org/new.html need to be able to extract these
 files, it would be OK to prescribe some fixed naming convention, such as
 /usr/share/doc/${package}/${name}.license or (if they are also required
 to have a prescribed location in the source package)
 debian/${name}.license.

 One package that would benefit from this is adwaita-icon-theme. It currently
 has an 87K copyright file[1], mechanically generated from a Perl script[2]
 and four verbatim Creative Commons licenses[3] which are re-indented for
 copyright-format by the script. If I'd known it was OK to do so, I would
 much rather have shipped those four licenses as-is and just made the
 copyright file refer to them.

 If the licenses are allowed to be compressed (see also [4]) then
 so much the better.

 Regards,
 S

 [1]
 http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/adwaita-icon-theme/debian/copyright?revision=43390view=markup
 [2]
 http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/adwaita-icon-theme/debian/copyright.pl?revision=43390view=markup
 [3]
 http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/adwaita-icon-theme/debian/
 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491055


Hi Simon,

just maybe another datapoint, as recently there was a similar dicussion on
d-devel, the thread started as
https://lists.debian.org/debian-devel/2014/09/msg00704.html (difference: This
was a question brought up by Markus if it is sufficient to referencfe to the
common licenses)
Though I think this discussion did not end with some concrete conclusion...

-- 
tobi


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/4b96861160e7798487545418b4e039f3.squir...@isengard.geekcommandos.com

Re: Unclarity wrt unnamed licenses in debian/copyright / DEP5

[Tobias Frost]

On 24. September 2014 21:55:07 MESZ, Matthijs Kooijman matth...@stdin.nl 
wrote:
Hi Russ,

 The syntax requires some short name.  I think it's fine to just use
 something arbitrary that passes the syntax check, like
custom-license.
 That's what I do.
I'll do that, then. Since I have two custom licenses, I guess I should
be using custom-license-1 and custom-license-2, which is even more
ugly.

Would be better if using an empty license short name would imply the
license is custom and unique within the copyright file, but i guess
that's something for a future version of the spec. For now, I'll just
go
with some arbitrary names.

Thanks,

Matthijs

I usually try to use some speaking names, so that one already gets a clue 
about it
-- 
tobi


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/16d858a3-7b88-4e05-885d-f4df37bf6...@email.android.com

System breakage because of unpurged package

[Tobias Frost]

Hi!

Because of #459424, I am curious how/if this should be/is handled by
dependencies:

A package broke the system. A Suggestion of this packages conflictes
with an older version of this suggestion. However, the older version had
been removed previously, so the conflict is technically resolved. 
But as it was not purged, the config-files were still there. And the
presence of this config-files caused the breakage.

Thanks for enlighting me!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#402721: debian-policy: WISHLIST Please make clear, that conflicts should only be used when really necessary

[Tobias Frost]

Package: debian-policy
Version: 3.7.2.2
Severity: wishlist

Looking at #262257, as an exampple, there are packages which declares
conflicts for whatever reason. However, the reason is NOT, that thec
packages could not co-existent on the same system (For the example,
retchmail could be also installed with fetchmail -- they do not
interfere)

My wishlist-entry would be to clarify, tha conflicts should only be
used, if the packages won't do if both installed... (as the word
conflict implies. The reason the other package is doing the same, so
conflict on it to prevent both installed is -- IMHO -- not the
intention of conflicts

Thanks (especially for the very good work you're doing here)
Tobi






-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]