Re: Auto-update for sid? Auto-backport?

[Wouter Verhelst]

On Thu, Nov 16, 2017 at 07:06:39PM +, Simon McVittie wrote:
> On Thu, 16 Nov 2017 at 17:02:00 +, Holger Levsen wrote:
> > On Thu, Nov 16, 2017 at 05:53:40PM +0100, Wouter Verhelst wrote:
> > > Yes; and semver.org is a formalized system for version numbering stuff.
> > > If upstream has committed to it (and does not make mistakes), then the c
> > > versions in the above example MUST (in the RFC definition of that word)
> > > only contain bugfixes, and no interface changes.
> >  
> > oh shiny! thanks for pointing out semver.org!
> 
> Semantic versioning is not a panacea: it assumes that a developer can
> know in advance whether changes are a compatibility break or not. In
> simple cases where a bug fix or a new feature never causes any unintended
> regressions, that's easy; but if there were no regressions, then we'd
> all run unstable on servers.

There are certainly problems with assigning the correct
semver-compatible version number in some environments, as you point out.
That's also part of why there are multiple revisions of semver itself, I
would assume.

However, those are upstream's problems, not ours; and given that
upstream tries to do the right thing, we can infer from a version number
which changes are expected, and whether it's a good idea.  I could
imagine a policy which would do something along the following lines,
given a X.Y.Z semver-compatible version number:

- if X changes, automatically file a bug but don't do anything
- if Y changes, try to rebuild the package and run any tests (if
  available); post the result to the BTS, but don't upload.
- if Z changes, try to rebuild the package. If autopkgtests exist, run
  them; if they don't fail, upload. If no tests exist, build, but don't
  upload. If uploading, file an "automatic upload happened" bug in the
  BTS, marked release-critical, so that the package won't auto-migrate
  unless someone has at least tested the package in a real-world
  scenario.

There will still be risks; there are always risks. In this context, and
with that policy, however, I think that they are minimized and
acceptable.

(I could imagine that if the package was involved in a transition, the
release managers would also not like it if the package was
auto-uploaded; having the script that implements the above look at the
transitions configuration before trying any upload might be helpful to
avoid that)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#881991: ITP: python-asgi-ipc -- ASGI channel layer that uses POSIX shared memory IPC

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-asgi-ipc
  Version : 1.4.2
  Upstream Author : Django Software Foundation 
* URL : https://github.com/django/asgi_ipc/
* License : BSD_3-clause
  Programming Lang: Python
  Description : ASGI channel layer that uses POSIX shared memory IPC

An ASGI (Asynchronous Server Gateway Interface) channel layer that uses POSIX
shared memory IPC as its backing store (only works between processes on the same
machine).
.
You'll need to instantiate the channel layer with a path prefix to create IPC
objects underneath; any channel layers with the same prefix will talk to each
other as long as they're on the same machine.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAloOz8YRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WrcPQf/VK8F7t1QKOjPkKYKw6aBcESyo8PYB3TT
Ns4GMmbGeisG575ApbtedcIxMztQMyXL9Fv0PA/MCnz9yZtjJgKvOehIKwPOYdLO
f+LuJGl1qnFX2Z5DseuU99sfpi7v8eOJzfmhOIS9zrGraN0zZFSFyReshjFQ1bHn
Qan2zC3238fWtJrKMbpiw2WU64dt4/41uvDcqPYxrZvnBSDMkYkdBHBHnHxc02J1
7cn17UHzfcbVFgPaKLtEpbrXMU3dQFXltoVsgfr0g4CHUp4nmH7iQ7noSWgigMRt
TrlpxLg21NbnBm2yQNGoHv8UCIsslaZXgKON/3qSpOGNwbkibhaoqQ==
=hjQv
-END PGP SIGNATURE-

Bug#881992: ITP: ruby-guard -- Commandline to easily handle events on file system modifications

[HIGUCHI Daisuke (VDR dai)]

Package: wnpp
Severity: wishlist
Owner: "HIGUCHI Daisuke (VDR dai)" 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: ruby-guard
  Version : 2.14.1
  Upstream Author : Thibaud Guillaume-Gentil 
* URL : https://github.com/guard/guard
* License : MIT
  Programming Lang: Ruby
  Description : Commandline to easily handle events on file system 
modifications

Guard automates various tasks by running custom rules whenever file or
directories are modified.
It's frequently used by software developers, web designers, writers and other
specialists to avoid mundane, repetitive actions and commands such as
"relaunching" tools after changing source files or configurations.

Features:
 * File system changes handled by our awesome Listen gem.
 * Support for visual system notifications.
 * Huge eco-system with more than 220 Guard plugins.
 * Tested against Ruby 2.2.8, 2.3.5, 2.4.2, JRuby & Rubinius.

-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEECynYjkLmt2W42OpQeDlhndQ5Zo4FAloO1XIPHGRhaUBkZWJp
YW4ub3JnAAoJEHg5YZ3UOWaOAPEQALWOIKAte5mT20c91/YePVwh0Zk2FaTgTm0K
GO1IUILSAwCiQZDqsIYmJVt5qg6y1bipqiBbSwA5ACIZTL+DOjpls2uOTwp2K50W
IgtugG6l637QgPpjGccodgdsmOU483S1pMqeTTUmMQfxt1lWwLWWchbaEWPvgNVv
RXGwJphRX/r37/qNG44jdHDHPzYuwjyr7dz4CZUgRlupxCmv29sD2S7S+B6pcRtD
iUfRPuMBfS8ZgsbejbmDolCMafNZRCMSD+nB4qgHfQVdFmZie8e1kPNq1MtJUz4O
oovPrCu38UIYh3vjEw/EReMmNZMyGxtK5giM5YPFza3e32gGuJRpO2xr3G/L0PMN
OqOq/Zqa9mbo3/nVGNVu6JFfHCSePBI1nepqdW6wMKBdKlg2cNqctzaK90hOTEn4
PnzzEufadFnIfeZ72yjkz7ru63UxOsuRaXxBR/6UpwkIs4Y37FPYYuTdyTJ0i5aX
82raEM2eZPVpJh+3zSQPBIs6OaUJ+oJUxqpcazm9haUDERYhBwNpup8o5RyAOLwp
H2uZqbQplar9xQWhuGSKUMWFlRSv+3nJ0ReCQNBB3LkZTyh5p4EouImEbQqYdc2z
o4aUH2BpbTi0jJlJ3V7/14pDLYpexxdnDE/FvXQllUiHs6mzK9CC88+6Z2BEBPGy
L7WzQ91w
=ZFRq
-END PGP SIGNATURE-

Bug#882000: ITP: ruby-guard-compat -- Tools for developing Guard compatible plugins

[HIGUCHI Daisuke (VDR dai)]

Package: wnpp
Severity: wishlist
Owner: "HIGUCHI Daisuke (VDR dai)" 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: ruby-guard-compat
  Version : 1.2.1
  Upstream Author : Cezary Baginski 
* URL : https://github.com/guard/guard-compat
* License : MIT
  Programming Lang: Ruby
  Description : Test helper for testing custom Guard plugins

This library provides a test helper for testing custom Guard plugins.

It is required by various Guard plugins.


-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEECynYjkLmt2W42OpQeDlhndQ5Zo4FAloO6xEPHGRhaUBkZWJp
YW4ub3JnAAoJEHg5YZ3UOWaOmkEQALICvqhjymh5S4NTsQ3C/RxyB1uxjTL7lv3W
KBHxQKqwKHqAg9f2xQ/4oyrgDuvggsRxMc/k5sixuFQVRSuge+jt2Bi0i5CSG42f
a7jyBp4V00mAChVwKjKDCglRatk9cA8MNYz+mZNguOQlznPzY1NvF3JtX0/DHwxs
FbxhQQMfA2hMa2ii+vW9qo2ijVBF3OsWUaUe5SWvpi3RGPESI02zGJtUBgEI02yR
KcOgjoUcWiliJQvy6DYuJUBgCIz3Eck/+ktG+teVEo8fxxMCaYhorKLIOcojv3wL
f+lD1KEMlKd9H8ZUEM8+RIUu5Me+5rVE+45yTCW1IeoaPsobGTIRgKhDyZ0VyE32
c9qcjJVvCK5dIrImAVu6nRkanhmxVhbbup6IrlGclDaSK42yCh713ROIyFPR8D+H
gc3ZIOIRD4cnwS40LavWS8El4TqPDJinvOkbRxk/JVEb7rUuC0Fl+mFUc3ECtvhD
TJ65nh8x1eSjHK/uZyMgE9R4qFYaLKqN+i1847MeNZy0cIrthk5/3ZjzVuwJG9rw
9u9u+Li2z0VQmwkr6GaFIOxFrOzv9EoYmLDLGBTThGT5/DZbAldH9qoqBS3Ch7Ai
CPuQ003y/ao5sChrszO0Hf0qQcB33CwIpRhe0DHr9q0E0h8L7W3/AxPrExKBYkm6
UPk8qhvk
=Isaq
-END PGP SIGNATURE-

Bug#882008: ITP: guard-shell -- Guard plugin for running shell commands

[HIGUCHI Daisuke (VDR dai)]

Package: wnpp
Severity: wishlist
Owner: "HIGUCHI Daisuke (VDR dai)" 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: guard-shell
  Version : 0.7.1
  Upstream Author : Joshua Hawxwell 
* URL : https://github.com/guard/guard-shell
* License : MIT
  Programming Lang: Ruby
  Description : Guard plugin for running shell commands

Guard plugin to run shell commands when files are altered.

With this plugin, when a file changes it does something in a shell or ruby.
It simply executes the block passed to watch if a change is detected,
and if anything is returned from the block it will be printed.

-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEECynYjkLmt2W42OpQeDlhndQ5Zo4FAloO+aYPHGRhaUBkZWJp
YW4ub3JnAAoJEHg5YZ3UOWaO2wUP/3X/pZ9sTibIzOUjPLSk8hUFSC7HtTjgpYXO
qnl2reVJTOZwo29u8Q0BvcklfkH+sF+B45e7vtGUv/4ff8QcyprTu4UwaNOHfArG
uoVlRY8HoAvcneSLylC8a/qqZLN1RNtRdfr92b+yhIMY1ViVK29Utr/0FZhOufas
nco4Mpp18SMEmpVuNChQNs+gbSzyDtv15eWWAI9Ox1W2nT70aIXsNrf/YWKpTqkF
6xjBKawcwePaZET/VkQ55wVwXkVplWoIr8FoALn5BQVnuKG58BcD1ULH5DQKiI3P
97Pf1va29FkCES2BDIJB1l709rp4nfHgO5EOQdzSxzVSfj8xaHEqbF5Pg5uQd2Fe
sn1sbSq/1Ry+4gkb1WwHiZR8kt2ujWuIiYo8JHK0XFDVm2Zalxk8PFfOco7pI3XG
hasarP40IZSyqUef+qC4uAc99y7GvAJOoUT/EbMLaRtjrfRy8Bnj9rjM1PWdCc2D
xjlqIIq4DlDS/uHgzMnsW8IBWpzjX8qCb4OiKUPplfpLqNV1YF37UYBMY/pT/m2T
F48Kadz5Qk8PcyQI19jYAta98FisauBqaGUoFDXWvqEAczCh12L3WD1K6okrjHPw
ROQ8w0DyoStWYgkRwJamDdspuKv20h1PCqrTbeDZCXi6NiXZc6QeOh3JGenh4+cl
/k6LAoEF
=G0gN
-END PGP SIGNATURE-

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

intrigeri:
> The next upload of the linux-image packages will "Recommends: apparmor".

Done ⇒ AppArmor is now enabled by default in sid.
Let the experiment begin!

Now is time to report and fix bugs. To make sure they are on the radar
of the AppArmor team, please apply the relevant usertag:

  https://wiki.debian.org/AppArmor/Reportbug

Thanks in advance, and sorry for any inconvenience it may cause (e.g.
the AppArmor policy for Thunderbird has various issues in sid; all of
those I'm aware of are fixed in experimental already).

Cheers,
-- 
intrigeri

Re: Auto-update for sid? Auto-backport?

[Guido Günther]

Hi,
On Wed, Nov 15, 2017 at 04:43:17PM +0100, Steffen Möller wrote:
> Hello,
> 
> my QA page or our blend's task page (like
> https://blends.debian.org/med/tasks/bio-ngs) regularly informs me about
> updates that should be performed to packages I alone maintain or (more
> likely) with the help of my blend. The updates are often (but now
> always, admittedly) easy to do.
> 
> I would really like to see updates performed in some automated fashion.
> Maybe into a different section of Debian like sid-auto? The problem with
> that obviously is the missing scrutiny by the human maintainer, so it
> cannot go straight into sid. Or can it? Maybe with an auto-created bug
> report against the package so it does not auto-migrate into testing?

What I have started to do is having jobs that run once a day uscan,
rebase patches, build in pbuilder, run autopkgtests via pbuilder's
autopkgtest hook[1] (to be put into a Jenkins instance).

That's about 99% of the busy work since I know in advance which packages
will need work (because patches no longer apply, tests fail or lintian
reports errors) while others can be uploaded right away after more
manual testing (if they don't have excessive test suites). Would that
help already? if so we could look into making this more usable to
others.

> A similar situation I see with backports. Most commonly all that is
> needed is a recompilation. Would an automation of that process be
> acceptable? Would it be acceptable for packages that offer some means of
> automated testing and are in backports already?
> 
> Many thanks for your opinions
> 
> Steffen
> 

[1]: /usr/share/doc/git-buildpackage/examples/gbp-try-ff

Re: Auto-update for sid? Auto-backport?

[Adrian Bunk]

On Wed, Nov 15, 2017 at 04:43:17PM +0100, Steffen Möller wrote:
> Hello,
> 
> my QA page or our blend's task page (like
> https://blends.debian.org/med/tasks/bio-ngs) regularly informs me about
> updates that should be performed to packages I alone maintain or (more
> likely) with the help of my blend. The updates are often (but now
> always, admittedly) easy to do.
> 
> I would really like to see updates performed in some automated fashion.
> Maybe into a different section of Debian like sid-auto? The problem with
> that obviously is the missing scrutiny by the human maintainer, so it
> cannot go straight into sid. Or can it? Maybe with an auto-created bug
> report against the package so it does not auto-migrate into testing?
>...

We do have DDs who seem to consider "maintaining" their packages to 
consist only of uploading the latest upstream versions and perhaps
look at RC bugs in their packages (sometimes not even that).
IMHO such people are a disgrace for Debian.[1]

Such disgrace maintainers could be replaced with a script
that automatically uploads the latest upstream version.

But who will actually maintain the packages?

Testing before uploading has already been mentioned.

There might also be a "Caveats" section in the upstream
release announcement that should be read and implemented
e.g. in the package dependencies or NEWS.Debian.

An upload is also a good opportunity to check whether there
are fixable lintian warnings.

If the new upstream version does FTBFS everywhere except amd64,
the maintainer is supposed to fix or at least forward this in
a timely manner.

And the maintainer is also supposed to handle all other incoming bugs.

Automated updates for non-leaf packages could also force other people
to fixup the mess they created, e.g. an automatic upload of a broken 
library package at the first day of the month-long summer vacation
of the maintainer would not be good timing.


The part you want to automate is some variant of
  uscan && dpkg-buildpackage && dput
if done manually.[2]

If you want to automate that it is fine, but the majority of maintainer 
work on a new upstream version is what happens after the automated part 
or if the automated part fails. And this maintainer work should happen 
before the package hits users in sid.


> Many thanks for your opinions
> 
> Steffen

cu
Adrian

[1] I am not talking about teams maintaining popular packages
where the team simply lacks enough people for handling all
incoming bugs
[2] exact commands vary depending on personal preferences

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Auto-update for sid? Auto-backport?

[Sean Whitton]

Hello Adrian,

On Fri, Nov 17 2017, Adrian Bunk wrote:

> We do have DDs who seem to consider "maintaining" their packages to
> consist only of uploading the latest upstream versions and perhaps
> look at RC bugs in their packages (sometimes not even that).  IMHO
> such people are a disgrace for Debian.[1]

Why are such a people a disgrace?  So long as they do not refuse the
requests of people with more time on their hands to adopt the package,
aren't they just doing what they can, which is strictly better than the
package receiving no work at all?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#882035: ITP: r-cran-fastica -- GNU R package for ICA and Projection Pursuit

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-fastica
  Version : 1.2-1
  Upstream Author : J L Marchin, C Heaton and B D Ripley
* URL or Web page : https://cran.r-project.org/package=fastICA
* License : GPL (>= 2)
  Description : GNU R package for ICA and Projection Pursuit

This package is a new build-dependency of the existing package r-cran-fgarch
we have had in Debian for a decade.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Auto-update for sid? Auto-backport?

[Paul Gevers]

Hi Sean,

On 17-11-17 20:35, Sean Whitton wrote:
> Why are such a people a disgrace?  So long as they do not refuse the
> requests of people with more time on their hands to adopt the package,
> aren't they just doing what they can, which is strictly better than the
> package receiving no work at all?

Not if this is the intended way of maintaining the package the moment
the ITP is filed. Than Debian is most often better off without the
package IMHO.

Paul



signature.asc
Description: OpenPGP digital signature

Re: Auto-update for sid? Auto-backport?

[Sean Whitton]

Hello,

On Fri, Nov 17 2017, Paul Gevers wrote:

> On 17-11-17 20:35, Sean Whitton wrote:
>> Why are such a people a disgrace?  So long as they do not refuse the
>> requests of people with more time on their hands to adopt the
>> package, aren't they just doing what they can, which is strictly
>> better than the package receiving no work at all?
>
> Not if this is the intended way of maintaining the package the moment
> the ITP is filed. Than Debian is most often better off without the
> package IMHO.

Agreed, but it's not clear that Adrian was referring to this case.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#882038: ITP: libclone-choose-perl -- Choose appropriate clone utility (Perl library)

[Damyan Ivanov]

Package: wnpp
Severity: wishlist
Owner: Damyan Ivanov 

* Package name: libclone-choose-perl
  Version : 0.008
  Upstream Author : Jens Rehsack ,
Stefan Hermes 
* URL : https://metacpan.org/release/Clone-Choose
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Choose appropriate clone utility (Perl library)

Clone::Choose checks several different modules which provides a clone()
function and selects an appropriate one.

A clone() function is useful for creating copies of complex nested data 
structures.

The default preference is

Clone

Storable

Clone::PP

This list might evolve in future.

The package is a new dependency of libhash-merge-perl and will be maintained 
under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

[j...@debian.org: Bug#870635: mutt package is not using the official mutt tarball]

[Jonathan Dowland]

[ I screwed up CCing this in the first place ]

- Forwarded message from Jonathan Dowland  -

Date: Fri, 17 Nov 2017 16:46:21 +
From: Jonathan Dowland 
To: Antonio Radici 
Cc: 870...@bugs.debian.org, Kevin McCarthy 
Subject: Bug#870635: mutt package is not using the official mutt tarball
User-Agent: NeoMutt/20170113 (1.7.2)

debian-devel@lists.debian.org
Bcc: Subject: Re: Bug#870635: mutt package is not using the official mutt 
tarball

Reply-To: In-Reply-To: <2017074105.iz5bje4kgkl3q...@cherubino.dyne.org>

CCing -devel because I think this might be of wider interest.

On Sat, Nov 11, 2017 at 07:41:05AM +, Antonio Radici wrote:

Sorry for the delay, my plan of action is to stop packaging neomutt with this
name, I'll create a new neomutt package (TBD by end of the month) and I'll think
if there is the need of a transitional package, the problem of a transitional
package is that mutt won't be packaged as mutt in stretch. To prevent that from
happening we will need two packages (mutt and neomutt) from two different
upstream sources.

So far the only thing which is certainly going to happen is the creation of the
neomutt package, then I could package the newest mutt as 'mutt' and think about
whether mutt needs to become a transitional package (which in that case will
remove mutt).


I think there are a facts you should seriously consider before
continuing with this approach.

Firstly, the existing package is neomutt, but called mutt. So the
existing package users are neomutt users, and the existing reported bugs
are bugs in neomutt. (The wisdom of having moved the package *to*
neomutt at this point is irrelevant, because it has happened whether we
like it or not.) If you are suggesting that the package name "mutt" is
going to be real "mutt" in future, then what happens to existing
users? What are their expectations? Do you reassign all existing bugs to
a new neomutt package name? Do you attempt to triage all bugs to figure
out whether they apply to one, the other, or both? Would users who are
using neomutt features not find the change to be a regression from their
point of view?

Secondly, is there a need for both mutt and neomutt in Debian? Our
mission is not to package every piece of software on earth, but to build
a useful operating system. Is there sufficient distinction between the
two, from a user's perspective, that there is a genuine need for both in
the archive? (Of course, the distinction is very important for the
authors of the software. But that's not the same thing.) For enough
users to justify the work? I've been a daily mutt (and now neomutt) user
in Debian for nearly 20 years, and I don't think there is.

Thirdly, let's look honestly at how well the existing package maintenance
is working. This particular issue was raise in late June[1], and you
said at the time that'd you have come up with a transition plan within a
couple of weeks[2]. For my pet neomutt bug[3] (which coincidentally I
reported at around the same time) you expected to have the patch applied
shortly, possibly even within a week[4], but it remains unfixed.

I am not trying to criticise your personal contributions to Debian. We
are all volunteers, and we all do what we can and nobody should expect
more from us than we are prepared or able to give. I am extremely
grateful for the work you have done and continue to do. But I think it's
important to communicate as realistically as possible what we are able
to do. I am very guilty of getting this wrong, and over-promising and
under-delivering for my own efforts in Debian. I simply wish to point
out that the existing Mutt packaging team appears to be stretched. It
seems to me that having two mutt packages to manage is only going to
make this situation much worse.

[1] https://marc.info/?l=mutt-users&m=149886522430053&w=2
[2] https://marc.info/?l=mutt-users&m=149889708628480&w=2
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866366
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866366#24


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

- End forwarded message -

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Auto-update for sid? Auto-backport?

[Steffen Möller]

Dear all,

On 15.11.17 16:43, Steffen Möller wrote:
> [question about how to realise auto-updated packages]
>

Thank you tons for all your nice and constructive ideas, experiences and
comments.

My (biased) impression is that there is a majority in favour of some
automation to become an option for routine package maintenance. We just
do not know how this should look. But we do know that this is dangerous
to have and by no means applicable to packages of all sorts and the
maintainer and the maintainer's responsibilities shall not be circumvented.

I do not know how to best proceed. Shall we collect more emails for a
week and I (or preferably some less biased observer) then summarise(s)?
If the positive vibes I have felt are kept up then I propose the
individuals running relevant services in/around Debian (ftpmasters, web,
backports, mentors, ...) determine what team then takes that summary to
transform it into a white paper that proposes steps to address so we
eventually have something to have a vote about?!

Best,

Steffen

Re: Auto-update for sid? Auto-backport?

[Jeremy Bicha]

On Fri, Nov 17, 2017 at 7:00 PM, Steffen Möller  wrote:
> If the positive vibes I have felt are kept up then I propose the
> individuals running relevant services in/around Debian (ftpmasters, web,
> backports, mentors, ...) determine what team then takes that summary to
> transform it into a white paper that proposes steps to address so we
> eventually have something to have a vote about?!

Why don't you (or someone) work on an opt-in service to help automate
everything *except* for the actual upload to Debian part? Since that's
the part that is controversial and complicated to set up in a trusted
way. I don't think you need a vote to work on implementing and
offering the rest.

Thanks,
Jeremy Bicha

Re: Let's enable AppArmor by default (why not?)

[Ben Caradoc-Davies]

On 18/11/17 14:34, Ben Caradoc-Davies wrote:

On 18/11/17 04:27, intrigeri wrote:

Thanks in advance, and sorry for any inconvenience it may cause (e.g.
the AppArmor policy for Thunderbird has various issues in sid; all of
those I'm aware of are fixed in experimental already).
Where "various issues" means no thunderbird external helpers work under 
xfce. Not a single one, as far as I can tell. And there goes another 
one: what happened to my .signature? I have filed as many bugs as I can 
given the time available. I will file one more for the missing 
.signature, and then I am disabling apparmor.


aa-complain thunderbird does not work (see #882047), so I used 
"systemctl mask apparmor.service" followed by a reboot. Ah, that is much 
better (#882048):


--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Let's enable AppArmor by default (why not?)

[Ben Caradoc-Davies]

On 18/11/17 04:27, intrigeri wrote:

Thanks in advance, and sorry for any inconvenience it may cause (e.g.
the AppArmor policy for Thunderbird has various issues in sid; all of
those I'm aware of are fixed in experimental already).


Where "various issues" means no thunderbird external helpers work under 
xfce. Not a single one, as far as I can tell. And there goes another 
one: what happened to my .signature? I have filed as many bugs as I can 
given the time available. I will file one more for the missing 
.signature, and then I am disabling apparmor.