Bug#1071432: /recent no longer working for debian-devel-changes

[Alexander Wirt]

On Thu, May 23, 2024 at 02:04:38PM +0200, di dit wrote:
> The original bug seems to me to be fixed but there is another issue
> which as far as I know affects only:
>   https://lists.debian.org/debian-devel-changes/recent
> The message is:
>  name 'cmp' is not defined
> 
> I didn't open a new bug report becauseit is related to "cmp" too but
> maybe it is unrelated.
> 
Oh man, fixed. Thanks

Alex


signature.asc
Description: PGP signature

Bug#1071432: lists.debian.org: list archives: /recent no longer working

[Alexander Wirt]

On Sun, May 19, 2024 at 09:13:26AM +0200, Nis Martensen wrote:
> Package: lists.debian.org
> Severity: normal
> X-Debbugs-Cc: nis.marten...@web.de
> 
> Dear listmaster,
> 
> Trying to access
> https://lists.debian.org/debian-devel/recent
> no longer works, but gives an error:
> 
> cmp_idx_pages() missing 1 required positional argument: 'b'
> 
> This is not specific to the debian-devel archives, but applies to all
> lists I have tried. It used to work until yesterday or the day before.
Should work now, however the results are not up2date until we fixed the search.

But if it works for you, please close the bug. 

Alexander

Bug#1015930: lists.debian.org: Please create debian-livecoding

[Alexander Wirt]

On Sun, Jul 24, 2022 at 11:48:29AM +0200, Joenio Marques da Costa wrote:
> Package: lists.debian.org
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I would like to ask the creation of a new mailing list with the following
> details.
> 
> ** Name **
> 
> debian-livecoding

Sorry for the delay! But I created the list. See 
http://lists.debian.org/debian-livecoding

Thanks

Alex


signature.asc
Description: PGP signature

Bug#989125: lists.debian.org: Request a mailing list named "debian-loongarch64"

[Alexander Wirt]

Hi, 

> Rationale:We have a new architecture named loongarch64, We have alreadly
> compelted loongarch64 debian port in our local workspace. Now, We plane to 
> post
> it to debian for becomeing a offical debian port. We need a mailing list for
> Discussions on the loongarch64 port(s) of Debian.
> Name: debian-loongarch64
> Short description: Discussions on the loongarch64 port(s) of Debian.
> Long description:
> Discussions on the loongarch64 port(s) of Debian.
> For more information see: https://wiki.debian.org/loongarch64
> This list is not moderated; posting is allowed by anyone.
> 
> Subscription Policy: open
> Post Policy: open
> Web Archive : yes

I created your new list. 

https://lists.debian.org/debian-loongarch/

Thanks

Alex
 


signature.asc
Description: PGP signature

Bug#989125: lists.debian.org: Request a mailing list named "debian-loongarch64"

[Alexander Wirt]

Hi, 

I had a deeper look into this bug and is seems there are a bunch of unanswered 
questions. Also there
is no one seconding the list. Therefore I am not able to create this list by 
now. 

Alex
 


signature.asc
Description: PGP signature

Bug#1031510: Please open a new debian-puppet list

[Alexander Wirt]

tags 1031510 wontfix
thanks

Am Fri, Feb 17, 2023 at 03:02:50PM +0100 schrieb Thomas Goirand:
 
 Hi,

> We'd like to have a new debian-puppet list. Here's the answer to all the
> fields of the MailingLists/HOWTO_start_list page. Please do reach us at
> #debian-puppet if you need to.
> 
> Please note that the following DDs are behind this request (and I'm only
> the messager):
> - apoikos
> - pollo
> - lavamind
> - olasd
> - zigo
> 
> Name: debian-pup...@lists.debian.org
> 
> Rationale:
> The puppet team still uses an old Alioth list, and we'd like to move-on.
> We also need a space to be able to exchange ideas/work, and IRC isn't enough.

 there is probably some misunderstanding. lists.debian.org is not a replacement 
for alioth and it
 does not host team mailinglists. Unless you want a general discussion list 
about configuration
 management systems I will have to decline that request. 

The software and the team would just not be able to serve that request. 

Alex - Debian Listmaster
 


signature.asc
Description: PGP signature

Bug#1006427: New upstream version: 2.2.7

[Alexander Wirt]

Am Thu, Mar 10, 2022 at 07:40:14PM +0100 schrieb Vincent Bernat:
>  ❦  9 March 2022 12:37 +01, Alexander Wirt:
> 
> >> >> A new upstream version has been published. Would you mind if I take
> >> >> over the package? I work next to the upstream author and I am often
> >> >> badgered by the package being not up-to-date. :)
> >> 
> >> > I would be glad if you would take over. Unfortunately I am more or
> >> > less in management nowadays and less in maintaining clusters.
> >> 
> >> Thanks! Do you prefer I move the repository under the Debian namespace
> >> on Salsa or that I keep it under ipvs-team?
> 
> > Whatever you like more. It is yours, just tell me so that I will be
> > able to move the repo.
> 
> If you don't mind, can you move it to the Debian namespace?
Sure, done.

Alex


signature.asc
Description: PGP signature

Bug#1006427: New upstream version: 2.2.7

[Alexander Wirt]

Am Sat, Mar 05, 2022 at 08:13:50AM +0100 schrieb Vincent Bernat:
>  ❦  4 March 2022 10:47 +01, Alexander Wirt:
> 
> >> A new upstream version has been published. Would you mind if I take
> >> over the package? I work next to the upstream author and I am often
> >> badgered by the package being not up-to-date. :)
> 
> > I would be glad if you would take over. Unfortunately I am more or
> > less in management nowadays and less in maintaining clusters.
> 
> Thanks! Do you prefer I move the repository under the Debian namespace
> on Salsa or that I keep it under ipvs-team?
Whatever you like more. It is yours, just tell me so that I will be able to 
move the repo. 

Alex

Bug#1006427: New upstream version: 2.2.7

[Alexander Wirt]

Am Fri, Feb 25, 2022 at 11:30:02AM +0100 schrieb Vincent Bernat:

Hi Vincent, 

> Source: keepalived
> Version: 1:2.2.4-0.2
> Severity: wishlist
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hey!
> 
> A new upstream version has been published. Would you mind if I take
> over the package? I work next to the upstream author and I am often
> badgered by the package being not up-to-date. :)
I would be glad if you would take over. Unfortunately I am more or less in 
management nowadays and
less in maintaining clusters. 

Thanks for you help

Alex


signature.asc
Description: PGP signature

Bug#1001680: O: libmp3-info-perl -- Perl MP3::Info - Manipulate / fetch info from MP3 audio files

[Alexander Wirt]

Package: wnpp
Severity: normal
Control: affects -1 src:libmp3-info-perl

I intend to orphan the libmp3-info-perl package. That was a dependency
for mp3burn and I don't need it anymore.

The package description is:
 This Perl library gives a set of function for manipulating info tags in MP3
 files and retrieving technical information from them.
 .
 This package was formerly known as MPEG::MP3Info and still has a wrapper
 for applications that refer to it using the old name.
 .
 The Debian package also provides a simple tool for editing MP3 tags - mp3id.

Bug#1001679: O: libmail-verify-perl -- Utility to verify an email address

[Alexander Wirt]

Package: wnpp
Severity: normal
Control: affects -1 src:libmail-verify-perl

I intend to orphan the libmail-verify-perl package. I don't do much
Perl this days and even less things with email.

The package description is:
 Mail::Verify provides a function CheckAddress function for verifying
 email addresses. First the syntax of the email address is checked, then
 it verifies that there is at least one valid MX server accepting email
 for the domain. Using Net::DNS and IO::Socket a list of MX records (or,
 falling back on a hosts A record) are checked to make sure at least one
 SMTP server is accepting connections.

Bug#1001678: O: mp3burn -- burn audio CDs directly from MP3, Ogg Vorbis, or FLAC files

[Alexander Wirt]

Package: wnpp
Severity: normal
Control: affects -1 src:mp3burn

I intend to orphan the mp3burn package. The last time I burned an audio CD was 
more than 10 years ago. Time to let it go.

The package description is:
 mp3burn is a Perl script that allows you to burn audio CDs composed
 of MP3, Ogg Vorbis, or FLAC tracks without an intermediate file conversion
 to .cdr or .wav.
 The .mp3/.ogg/.flac files *are* converted using a decoder, but are
 written to FIFOs so they don't consume filesystem space during the burn.

Bug#905456: Please create new list debian-clojure

[Alexander Wirt]

Hi,

> On Wed, 10 Mar 2021 14:23:10 -0800 Elana Hashman  wrote:
> > On 2021-03-10 11:34, Alexander Wirt wrote:
> > > [...]
> > > Uh, oh. Yeah, please.
> >
> > There's been no objections since this email was last sent -- anyone on
> > the list who does not want to be migrated over to the new list, speak
> > now (privately emailing me) or forever hold your peace.
> 
> It's been a while since this^^, do you think we can proceed with the list
> creation/migration? Or are there still any blockers?
Ack, please send me the gpg encrypted list of subscribers and I will
provide the new list asap.

Thanks a lot

Alex

Bug#988464: New mailing list: debian-enterprise

[Alexander Wirt]

On Thu, May 13, 2021 at 04:33:47PM +0200, Mike Gabriel wrote:
> Package: lists.debian.org
> Severity: wishlist
> X-Debbugs-Cc: Raphael Hertzog , Sébastien Delafond 
> , Michael Prokop , Chris Hofstaedtler 
> , Christian Kastner 
> 
> Dear list admins,
> 
> Please provide a new discussion mailing list for people with focus on 
> enterprise usage of Debian.
> 
> Name: debian-enterprise (@lists.d.o)
> Rationale:
What about https://lists.debian.org/debian-enterprise/ ? 

Alex

Bug#986213: RM: ansible/2.9.16+dfsg-1.1

[Alexander Wirt]

On Wed, Mar 31, 2021 at 08:20:09PM +0200, Sebastiaan Couwenberg wrote:
> On 3/31/21 7:30 PM, Lee Garrett wrote:
> > Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried
> > getting the unit tests from 2.9.16 to work with python 3.9, but I had to 
> > give
> > up. I don't feel comfortable with maintaining such a large package over the
> > lifecycle of bullseye without unit tests, official py3.9 support, and 
> > security
> > support running out in a few months, so please remove ansible from bullseye.
> 
> Shipping bullseye without ansible is going to make many users unhappy.
> 
> Will you actively maintain the package in bullseye-backports instead?
And always remember, you can only update ansible in bpo with the version that
is in testing.

 
Alex

Bug#966088: It would be great to have debian-rust@l.d.o.

[Alexander Wirt]

On Wed, Jan 13, 2021 at 06:32:43PM +0100, Geert Stappers wrote:
> 
> Summary:  Gentle reminder
> 
> 
> Hello Listmasters,
> 
> 
> Today there was this on IRC in #debian-rust
> 
> 14:31 < metreo> is there some reason the rust team mailing list isn't shown 
> here:
> https://lists.debian.org/completeindex.html
> 14:38 < capitol> not that i know of
> 14:39 < metreo> k
> 14:58 < nikos> 'The lists.d.o list hasn't been created yet AFAIK
> 
> 
> Me did it trigger to write this email.
> 
> 
> What is blocking creation mailing  debian-rust@l.d.o.?
>  
> In other words: Please say what is needed to make it possible.
It would have been nice to have a proper subscription and so on. But
however I am working on it now. 

Alex

Bug#905456: Please create new list debian-clojure

[Alexander Wirt]

On Tue, Sep 22, 2020 at 10:04:39AM -0700, Elana Hashman wrote:
> On Tue, Sep 22, 2020 at 02:02:40PM +0200, Alexander Wirt wrote:
> > 
> > ehm, but you asked on the list if subscribers should get subscribed to
> > the new list? 
> 
> I did upon initial list request but it's been over a year. Would you
> like me to ask again? (The list should be CC'd so this is pretty
> transparent.)
Uh, oh. Yeah, please.

Alex - Debian Listmaster

Bug#980010: Please create a debian-i...@lists.debian.org list

[Alexander Wirt]

On Tue, Jan 12, 2021 at 11:31:39PM +0200, Adrian Bunk wrote:
> Package: lists.debian.org
> Severity: normal
> 
> Originally the list for discussing i386 specific issues
> was debian-devel, since i386 was the main architecture
> nearly everyone was using.
> 
> These days this main architecture nearly everyone is using
> is amd64 (and the debian-amd64 list has become low/no-traffic).
> 
> Please create a debian-i386 list for discussing i386 specific issues.
Please follow the instructions in
https://www.debian.org/MailingLists/HOWTO_start_list, especially get
some other people expressing interest and fill in the relevant fields,
like description and so on. 

Thanks

Alex

Bug#905456: Please create new list debian-clojure

[Alexander Wirt]

On Sun, Sep 20, 2020 at 02:38:39PM -0700, Elana Hashman wrote:
> On Thu, Sep 10, 2020 at 09:52:40PM +0200, Alexander Wirt wrote:
> > 
> > Sorry for joining late. Could you please upgrade the list of subscribers
> > and provide me with the archive of the old alioth list?
> 
> No problem. I'm attaching another encrypted dump of the subscriber list.
> 
> The archives are publicly available at
> https://alioth-lists.debian.net/pipermail/pkg-clojure-maintainers/
> 
> I'd just be downloading and attaching the gzips from the link above so
> hopefully this is enough... unfortunately as with most public mailing
> lists the archives are full of spam, not sure if there's any easy way to
> clean that.
ehm, but you asked on the list if subscribers should get subscribed to
the new list? 

Alex

Bug#946979: lists.debian.org: Have a mailing list archive for the JavaScript team.

[Alexander Wirt]

On Sat, Sep 12, 2020 at 03:45:56AM +0530, Utkarsh Gupta wrote:
> Hi Alexander,
> 
> On Fri, Sep 11, 2020 at 1:26 AM Alexander Wirt  wrote:
> > Please follow the instructions in 
> > https://www.debian.org/MailingLists/HOWTO_start_list
> > and provide me with the needed information (Name, Rationale,
> > Descriptions and so on).
> 
> If I'm understanding the guide correctly, from the "Moving existing
> mailing lists to lists.debian.org" section, I feel that I don't really
> need a name, rationale, and so on, right?
> Because we want to move away from the existing alioth-lists.d.net
> service to lists.d.o.
Of course you do. We do not move lists from alioth per se. 

Alex

Bug#946979: lists.debian.org: Have a mailing list archive for the JavaScript team.

[Alexander Wirt]

On Thu, Dec 19, 2019 at 12:35:18AM +0530, Utkarsh Gupta wrote:
> Package: lists.debian.org
> Severity: wishlist
> 
> Hiya,
> 
> The JavaScript team is still using the old archive (that is,
> alioth-lists.debian.net) which gets very messy and noisy since there are
> a lot (hundres each month) of auto-generated emails from the FTP Masters.
> Moreover, all the other teams have switched to
> lists.debian.org/debian-.
> 
> That said, I hereby request a slot for the JavaScript team, that is,
> debian...@lists.debian.org.
> Thank you :)
Please follow the instructions in 
https://www.debian.org/MailingLists/HOWTO_start_list
and provide me with the needed information (Name, Rationale,
Descriptions and so on). 

Alex

Bug#966088: mailinglist debian-r...@lists.debian.org

[Alexander Wirt]

On Wed, Jul 22, 2020 at 11:16:47PM +0200, Geert Stappers wrote:
> Package: lists.debian.org
> Severity: wishlist
> 
> 
> Hello Listmasters,
> 
> The rust packaging team is in need for a mailinglist for human
> interaction.
> 
> The ML pkg-rust-maintain...@alioth-lists.debian.net is getting more and
> more automated traffic due the succes of the team. Downside is the human
> messages are flooded. Hence this request.
> 
> 
> I volunteering for moderator of debian-r...@lists.debian.org or/and
> taking responseblity for this new mailinglist.
> 
> 
> If I recall correct is a request from a single person is not enough
> for getting an ML created. So I'll share the bugreportnumber
> with rust team members and ask for "votes" on this BR.
Please provide us with the information described in
https://www.debian.org/MailingLists/HOWTO_start_list (Description,
Category and so on). Unless you come up with at least 3 moderators we
will create the list as on open list (which we prefer anyhow).

Alex

Bug#905456: Please create new list debian-clojure

[Alexander Wirt]

Hi,

> I realize that alioth-lists.debian.net is only a temporary service and
> will be going away within the next couple of years[1]. It would be
> better to move the Clojure packaging list
>  sooner versus later.
> I'm currently the admin of that list.
> 
> This has been proposed as part of our team's overall Alioth
> migration[2].
> 
> The details...
> 
> Name: debian-cloj...@lists.debian.org
> Rationale: see above
> Short description: Clojure packages and maintenance
> Long description: Coordination of the maintenance of Clojure packages
> in Debian.
> Category: Developers
> Subscription Policy: open
> Post Policy: open
> Web Archive: yes
> Moving an existing list: Attachment has an encrypted list of current
> subscribers in the correct format (one email per line). I
> encrypted it for Alex's key as he is listed as responsible for
> list creation.[3]
Sorry for joining late. Could you please upgrade the list of subscribers
and provide me with the archive of the old alioth list?

Thanks in advance

Alex

Bug#969942: ITP: tty-share -- Terminal sharing over the Internet

[Alexander Wirt]

On Wed, Sep 09, 2020 at 07:56:51AM +, Holger Levsen wrote:
> On Wed, Sep 09, 2020 at 06:27:28AM +, Francisco Vilmar Cardoso Ruviaro 
> wrote:
> > * Package name: tty-share
> >   Version : 0.6.2
> >   Upstream Author : Vasile Popescu 
> > * URL : https://github.com/elisescu/tty-share
> > * License : Expat
> >   Programming Lang: Go
> >   Description : Terminal sharing over the Internet
> > 
> > tty-share is a very simple command line tool that gives remote access to a 
> > UNIX
> > terminal session.
> [...]
> > tty-share connects over a TLS connection to the server (runs at 
> > tty-share.com),
> [...]
> 
> this pretty much sounds like this should go into contrib, rather than Debian
> main. Or is there free server code as well?

https://github.com/elisescu/tty-server

Alex

Bug#905581: Mailing list for Salsa/Salsa-CI team

[Alexander Wirt]

On Thu, Apr 23, 2020 at 10:04:19AM +0300, Otto Kekäläinen wrote:
> Hello!
> 
> > Otto:
> > > The Salsa-CI discussions still have no mailing list to go to. Could
> > > you please create a mailing list for the team now?
> 
> > Alexander:
> > We told you which list to use.
> 
> The debian-ci list is about autopkgtest and the autopkgtest managers
Discussion list for the Debian CI projec
this list concentrates discussion around topics related to the Debian CI 
project: Debian CI itself, autopkgtest, debci (the codebase), autodep8, etc.

And basically it is our duty to say what the topic of a list is. And I
still think having two list doesn't make sense. 

> have explicitly said that it is not suitable for Salsa-CI discussions.
> If you look at the mail archive of debian-ci it is quite clear that
> the list is only about autopkgtest, not about Salsa or Lintian or blhc
> or piuparts or any other of the CI parts Salsa-CI contains, and
> forcing the two clearly separate groups together will not help
> productivity.
> 
> I suggest creating a general debian-salsa@ list for Salsa users and
> developers in general, or a separate Salsa-CI for the Salsa-CI team.
And if its not called salsa we will rename it and so on. No I think a
general list for such kind of topics is the way to go. 

Alex 

Bug#905581: Mailing list for Salsa/Salsa-CI team

[Alexander Wirt]

On Thu, Apr 23, 2020 at 09:42:22AM +0300, Otto Kekäläinen wrote:
> Hello!
> 
> The Salsa-CI discussions still have no mailing list to go to. Could
> you please create a mailing list for the team now?
We told you which list to use. 

Alex
 

Bug#953101: lists.debian.org: please create a new list abuse-rtc

[Alexander Wirt]

tags 953101 wontfix
thanks

On Wed, Mar 04, 2020 at 03:15:26PM +0100, gustavo panizzo wrote:
> Package: lists.debian.org
> Severity: wishlist
> 
> 
> Hello
> 
> I want to request a new list
> 
> - Name: abuse-...@lists.debian.org
> - Rationale: The list will be used as point of contact for abuse, security, 
> and
>  potentially other issues found by people using or interacting 
> with
>  Debian services managed by the RTC Team.
> - Short description: Abuse contact list for services managed by the RTC Team
> - Long description: $Rationale
> - Category: I really don't know
> - Subscription Policy: closed
> - Post Policy: open
> - Web Archive: yes
This is not what lists are for. You want dsa to create an alias or
something like that.
 
Alex

Bug#952397: listmasters join request

[Alexander Wirt]

On Mon, 24 Feb 2020, Geert Stappers wrote:

> On Mon, Feb 24, 2020 at 10:04:41AM +0100, Alexander Wirt wrote:
> > On Sun, 23 Feb 2020, Geert Stappers wrote:
> > > 
> > > Here Debian Developer  Geert Stappers, my wish is to join your team.
> > > 
> > > I have exprience in mailinglists as admin. For a Local Linux User Group
> > > and a running assosation I provide "mailman2"
> > You will have to get familiar with smartmail, a lot of perl and so on.
> > And probably have to forget anything you know about mailinglists. 
> 
>:-)
> 
> 
> > > My preferred MTA is Postfix.
> > We have postfix ;)
> > 
> > Are you still interested? 
> 
> Yes, I'm still interested in joining the listmasters team.
Great, we will talk about it in the team and how to get you involved if (and
I would expect that) the team agrees. 

Alex

Bug#952397: listmasters join request

[Alexander Wirt]

On Sun, 23 Feb 2020, Geert Stappers wrote:

> Package: lists.debian.org
> Severity: wishlist
> 
> 
> Hello Team  Listmasters,
> 
> 
> Here Debian Developer  Geert Stappers, my wish is to join your team.
> 
> I have exprience in mailinglists as admin. For a Local Linux User Group
> and a running assosation I provide "mailman2"
You will have to get familiar with smartmail, a lot of perl and so on. And
probably have to forget anything you know about mailinglists. 

> My preferred MTA is Postfix.
We have postfix ;)

Are you still interested? 

Alex


signature.asc
Description: PGP signature

Bug#593398: closing 593398

[Alexander Wirt]

close 593398 
thanks

I think thats not a bug in ferm, helper loading should be done by the kernel
itself.

Bug#935268: ferm: Ferm fails to properly install

[Alexander Wirt]

tags 935268 unreproducible
thanks

On Wed, 21 Aug 2019, David Venhoek wrote:

Hi,

> On a fresh debian 9 opencloud image system, after running apt update and apt 
> upgrade, trying to install ferm with
> ``/usr/bin/apt-get -y -o "Dpkg::Options::=--force-confdef" -o 
> "Dpkg::Options::=--force-confold" install ferm | tee /dev/null``
> results in the ferm service failing during the execution of the apt-get 
> command.
> 
> This results in ferm not being properly installable using tools like ansible.
Despite of installing ferm via ansible all the time I am not able to
reproduce your problem in a test environment: 

DEBIAN_FRONTEND="noninteractive" /usr/bin/apt-get -y -o 
"Dpkg::Options::=--force-confdef" -o "Dpkg::Options::=--force-confold" install 
ferm | tee /dev/null

The following NEW packages will be installed:
  ferm
Preconfiguring packages ...
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 0 
B/112 kB of archives.

 After this operation, 309 kB of additional disk space will be 
used.
Selecting 
previously unselected package ferm.
(Reading database ... 326357 files and directories currently installed.)
Preparing to unpack .../archives/ferm_2.4-1_all.deb ...
Unpacking ferm (2.4-1) ...
Setting up ferm (2.4-1) ...
Created symlink /etc/systemd/system/sysinit.target.wants/ferm.service → 
/lib/systemd/system/ferm.service.
Processing triggers for man-db (2.9.0-2) ...
Processing triggers for systemd (244-3) ...
root@lisa:~#

gives me a clean installation. 

Installation via ansible works fine: 

 -m apt -a "pkg=ferm state=present" localhost
localhost | CHANGED => {
"cache_update_time": 1578131047,
"cache_updated": false,
"changed": true,
"stderr": "",
"stderr_lines": [],
*snip*
"Preparing to unpack .../archives/ferm_2.4-1_all.deb ...",
"Unpacking ferm (2.4-1) ...",
"Setting up ferm (2.4-1) ...",
"Created symlink /etc/systemd/system/sysinit.target.wants/ferm.service 
-> /lib/systemd/system/ferm.service.",
"Processing triggers for man-db (2.9.0-2) ...",
"Processing triggers for systemd (244-3) ..."
]
}

I therefore need information on how to reproduce the problem in a clean test
environment.

Thanks

Alex

Bug#910673: Request for a new mailing list: debian-xen

[Alexander Wirt]

On Tue, 13 Aug 2019, Ian Jackson wrote:

> Alexander Wirt :
> > That list is still missing any other advocated speaking for the lists,
> > I would really prefer if at least Ian Jackson would speak up.
> 
> Hi.  I think this list would be a good idea.  Indeed, it was during an
> IRL conversation with me that I suggested to Knorrie that he request
> this list.
> 
> As Knorrie says, currently we are using an "alioth continuity" list
> (owned by me).  Obviously we want to migrate away from that.
> 
> I don't think we want to lose the list facility.  Xen is very
> complicated and we need somwhere to discuss things.  The archive is
> particularly important.
Thanks, I see the need for the list. Could you please send me the archive
(mbox) and the (encrypted) list of subscribers? 

 
Alex


signature.asc
Description: PGP signature

Bug#910673: Acknowledgement (Request for a new mailing list: debian-xen)

[Alexander Wirt]

On Wed, 31 Oct 2018, Hans van Kranenburg wrote:

> On 10/09/2018 06:09 PM, Debian Bug Tracking System wrote:
> > Thank you for filing a new Bug report with Debian.
> 
> Ping! :)
> 
> Is there anything else you want to know? We'd like to have this sorted
> out well beforehand getting into any trouble preparing for the Buster
> release.
That list is still missing any other advocated speaking for the lists, I
would really prefer if at least Ian Jackson would speak up.

Alex

Bug#905456: Please create new list debian-clojure

[Alexander Wirt]

On Sat, 04 Aug 2018, Elana Hashman wrote:

> Package: lists.debian.org
> Severity: wishlist
> 
> Hello!
> 
> I realize that alioth-lists.debian.net is only a temporary service and
> will be going away within the next couple of years[1]. It would be
> better to move the Clojure packaging list
>  sooner versus later.
> I'm currently the admin of that list.
> 
> This has been proposed as part of our team's overall Alioth
> migration[2].
> 
> The details...
> 
> Name: debian-cloj...@lists.debian.org
> Rationale: see above
> Short description: Clojure packages and maintenance
> Long description: Coordination of the maintenance of Clojure packages
> in Debian.
> Category: Developers
> Subscription Policy: open
> Post Policy: open
> Web Archive: yes
> Moving an existing list: Attachment has an encrypted list of current
> subscribers in the correct format (one email per line). I
> encrypted it for Alex's key as he is listed as responsible for
> list creation.[3]
That bug is still missing any other mails from interested people for that
list. Is that mail really consense? 

Alex



signature.asc
Description: PGP signature

Bug#905581: Mailing list for Salsa/Salsa-CI team

[Alexander Wirt]

On Mi, 17 Jul 2019, Otto Kekäläinen wrote:

> Hello!
> 
> There are now 10 people discussing "Licensing salsa-ci pipeline" in
> private thread that really should belong into a Debian mailing list.
> 
> Can you please create this list now?
> 
> If you think "debian-salsa-ci" is too small, then create a more
> generic "debian-salsa" list where also other Salsa usage and
> improvements can be discussed.
No, as I said I will create a debian-ci list as soon as I find time.

Alex

Bug#931634: lists.debian.org: Update description for debian-mentors@lists.d.o

[Alexander Wirt]

On Mon, 08 Jul 2019, Jonas Meurer wrote:

> Package: lists.debian.org
> Severity: normal
> 
> Hello,
> 
> as discussed on debian-project and debian-mentors [1], the scope of
> debian-mentors@lists.d.o was broadened to explicitely include questions
> regarding Debian infrastructure projects.
> 
> The DebianMentorsFaq already has been updated accordingly [2, 3]
> 
> To reflect this broadened scope, the description of the debian-mentors
> mailinglist on lists.debian.org should be changed to:
> 
> > *Helping newbie developers*
> > Newbie Debian contributors can seek help with packaging and infrastructure 
> > projects as well as other developer-related issues here.
> > 
> > This list is not meant for users' questions, but for new contributors'!
> > 
> > This list is not moderated; posting is allowed by anyone.
> > 
> > List FAQ: https://wiki.debian.org/DebianMentorsFaq
> > 
> > Posting address: debian-ment...@lists.debian.org
Did anyone ask those infrastructure projects? what are infrastructure projects?

Alex

Bug#929676: unblock: lintian/2.15.0

[Alexander Wirt]

On Thu, 30 May 2019, Chris Lamb wrote:

> Hi Ivo,
> 
> > > Please consider unblocking lintian 2.15.0 for buster (from 2.9.1). This
> > > was specifically requested in #929577 by Mattia Rizzollo:
> > 
> > This really should have been discussed in advance.
> 
> I completely agree. The problems simply did not occur to me as — as
> #929577 implies — it affects infrastructure that I am not involved
> with and thus I was not experiencing any issue.
> 
> >If you want to maintain the correct version ordering between
> > testing and backports, I suggest you don't do any new uploads to backports
> > before you get confirmation that the corresponding version will be accepted 
> > in
> > buster.
> 
> 100% noted.
Just for the record, lintian has an exception for backports. So please upload
whenever you like.  

Alex - Backports ftpmaster


signature.asc
Description: PGP signature

Bug#921663: Please add python-certbot update to jessie-backports

[Alexander Wirt]

On Mon, 11 Feb 2019, Brad Warren wrote:

> I agree with the concerns about updating python3-cryptography in jessie.
> 
> If we can’t update jessie, I’d ideally love to see the packages in 
> jessie-backports updated. Despite the announcement that jessie-backports was 
> discontinued ~6 months ago, tens of thousands of users and many more domains 
> continue to rely on these packages as I wrote earlier in this thread. It 
> would be great if a simple package upgrade was all they needed to do to 
> prevent their TLS configurations from breaking.
Its closed, we won't change it anymore and it will be (hopefully) archived
soon, then its even not available on the mirrors anymore.  

Alex - backports ftpmaster
 

Bug#876430: new list, with migration if possible

[Alexander Wirt]

On Thu, 31 Jan 2019, Hans-Christoph Steiner wrote:

> 
> We the Debian Android Tools Team want to have a regular Debian team
> list, to entirely replace the alioth list.  Just having a new list is
> good.  Migrating the archives would be wonderful.
>
I don't that specific maintainer list is suited for l.d.o. 

Alex - Debian Listmaster


signature.asc
Description: PGP signature

Bug#914732: Bug #914732: lists.debian.org: Request for new mailing list: debian-dug-muc

[Alexander Wirt]

On Tue, 29 Jan 2019, Michael Banck wrote:

> Ping?
its in my next round of list creations. 
> 

Bug#905581: lists.debian.org: Request for new mailing list: debian-salsa-ci

[Alexander Wirt]

On Tue, 08 Jan 2019, Agustin Henze wrote:

> Hi Alex,
> 
> On Wed, 2 Jan 2019 19:17:24 +0100 Alexander Wirt 
> wrote:
> > On Wed, 02 Jan 2019, Agustin Henze wrote:
> > 
> > > Hi formorer, I really appreciate your opinion but we still needing the
> > > mailing list.
> > Let me rephrase. I don't think that any other listmaster will create that
> > list. 
> > 
> 
> Mmm ok, I think the process is completely unclear then... You have the
> requirements written and I think the request followed them.
> 
> Could you explain me please how do you decide not creating the mailing
> list. What is the criteria? What area the objective reasons to decline
> the request?
> 
> In that way, we can decide what to do... If we ask a mailing list on
> riseup or try to fill the requirements because we really need it,
> otherwise I wouldn't be spending time here...
Following the procedure doesn't mean that we take every list. We decide on
several points:

- interest - are enough people interested in the list to make it worth the
  work
- topic - is it on topic? l.d.o is usually about debian et all, which means
  that for example a generic -ci list is on-topic whereas salsa-ci is by far
  too special. 
- operating costs - some lists need more attention than others

In general we want to provide a common listservice for generic topics
affecting the whole project. Every list needs ressources (technically and
resource wise), therefore we a picky on what we accept.

Alex

Bug#905581: lists.debian.org: Request for new mailing list: debian-salsa-ci

[Alexander Wirt]

On Wed, 02 Jan 2019, Agustin Henze wrote:

> Hi formorer, I really appreciate your opinion but we still needing the
> mailing list.
Let me rephrase. I don't think that any other listmaster will create that
list. 

So don't expect it. 

Alex



signature.asc
Description: PGP signature

Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing

[Alexander Wirt]

On Tue, 18 Dec 2018, Pirate Praveen wrote:

> [adding -devel to cc]
> 
> On 12/3/18 8:11 PM, Dominik George wrote:
> >> well, Debian is using gitlab!!! so this sentence has no sense. The
> >> problem here
> >> is that is a complex software that depends of a lot of pieces and it's
> >> not
> >> easy/possible to fit the definition. So, maybe we should create another
> >> category
> >> of software.
> > 
> > Yes, and that Debian officially uses GitLab, from a foreign source, without 
> > being able to support it in Debian, does make me feel ashamed for the 
> > project.
> > 
> >> maybe creating another kind of repo. debian-contributuions
> >> debian-blabla, whatever.
> >>
> > 
> > We had volatile, which, redefined properly, could help. I am trying to 
> > draft such a definition.
> 
> Did you get a chance to work on it?
> 
> I think it has to be an extension of backports with dependencies that
> fall within the backports criteria being maintained in backports and
> only packages that cannot be in backports maintained in volatile.
> 
> Original definition of volatile from https://www.debian.org/volatile/:
> "Some packages aim at fast moving targets, such as spam filtering and
> virus scanning, and even when using updated data patterns, they do not
> really work for the full time of a stable release. The main goal of
> volatile is allowing system administrators to update their systems in a
> nice, consistent way, without getting the drawbacks of using unstable,
> even without getting the drawbacks for the selected packages. So
> debian-volatile will only contain changes to stable programs that are
> necessary to keep them functional."
> 
> Proposed definition:
> "Some packages aim at fast moving targets, such as complex web based
> software with very small release cycles and new dependencies, they do
> not receive security support or bug fixes for the full time of a stable
> release. This means backporting targeted fixes are impossible.  The main
> goal of volatile is allowing system administrators to update their
> systems in a nice, consistent way, without getting the drawbacks of
> using unstable, even without getting the drawbacks for the selected
> packages. New dependencies introduced can be maintained in backports
> repository. So debian-volatile will be an extension of debian-backports,
> with dependencies that fall within the criteria maintained in
> debian-backports."
I don't think that -backports is the right suite. It should be something new,
with a new team.

Alex



signature.asc
Description: PGP signature

Bug#915517: ucspi-tcp: VCS repository is set to private

[Alexander Wirt]

On Thu, 06 Dec 2018, Dmitry Bogatov wrote:

> 
> [2018-12-04 12:48] Ansgar Burchardt 
> > Version: 1:0.88-4
> > Severity: normal
> > 
> > Vcs-* ist set to https://salsa.debian.org/debian/ucspi-tcp which is a
> > private repository.  Please make the repository publically accessible.
> 
> Confirmed. Problem is that both web-interface and API says that I am not
> authorized.
> 
> Added salsa-admin@d.o into CC. Maybe they would help.
Create a ticket please. The user broke it by just pushing the repo. 

Alex

Bug#914732: lists.debian.org: Request for new mailing list: debian-dug-muc

[Alexander Wirt]

On Mon, 26 Nov 2018, Michael Banck wrote:

> Package: lists.debian.org
> Severity: wishlist
> 
> Dear Listmasters,
> 
> Please create the Debian User Group list debian-dug-muc for the Munich
> local area user group, https://wiki.debian.org/LocalGroups/DebianMuc
> 
> The current list on teams.debian.net went AWOL when that mailservers'
> filesystem died several weeks ago and it seems that the teams.debian.net
> admins are not going to bring it back soon if at all.
> 
> We have been coordinating local Debian meetups in Debian on area-muc
> since 2006, but moving it over to lists.debian.org makes sense anyway.
> 
> Unfortunately, I do not have a full subscriber-list as that went down
> with teams.debian.net and I am not sure backups exist. I will attach a
> list of recent active members for initial subscription.
> 
> So in short:
> 
> Name: debian-dug-muc
> Short Description: Discussion/Annonce list for the Munich Debian
>Community
> Long Description: n/a
> Category: Other (DUG)
> Subscription Policy: open
> Post Policy: open
> Web Archive: yes
This request is missing seconders. 

Alex



signature.asc
Description: PGP signature

Bug#888747: keepalived: ip_vs not loading on initial startup

[Alexander Wirt]

severity 888747 wishlist
thanks

On Mon, 29 Jan 2018, Thomas Baetzler wrote:

> Package: keepalived
> Version: 1:1.3.2-1
> Severity: important
> 
> Dear Maintainer,
> 
> the required module ip_vs is not automatically loaded on startup which
> prevents keepalived from working after a reboot.
> 
> The service works as expected after a manual "systemctl restart keepalived".
> 
> A workaround is to add the following line to the service definition:
ip_vs is not required to run keepalived. It is perfectly valid to just use
the VRRP part instead of ipvs (in fact most of my customer setups don't use
ipvs). I therefore think its not the best idea to enforce loading of ipvs,
that would lead to problems on systems without ipvs (in the past at least the
debian system admins ran such systems).

Alex

Bug#914898: debootstrap, stretch-backports: Please disabled merged /usr by default

[Alexander Wirt]

On Wed, 28 Nov 2018, Ian Jackson wrote:

> Package: debootstrap
> Version: debootstrap/1.0.110~bpo9+1
> Severity: serious
> 
> In #914208 Simon McVittie writes:
> > [merge-/usr] is now the default in stretch-backports' debootstrap
> 
> As discussed on debian-devel, however, binary packages built on a
> merged-usr system are not installable on a non-merged-usr system.
> Obviously we would like ad hoc builds of packages from one stretch
> machine to be installable on other stretch machines.
> 
> I do not see any way in which this could be resolved for stretch.
> Accordingly, please urgently revert this change for stretch-backports.
> 
> Ian.
> 
> (I have CC'd debian-release@lists because this seems like it wants the
> attention of the stable release team.  I wasn't able to find a
> separate contact address for the stable release team here
>   https://www.debian.org/intro/organization
> and I have a vague memory that this is somehow the same list.  Please
> redirect me if I am wrong.)
I didn't followed the discussion, but the default should be the same as in
buster. I don't want debootstrap to behave different than in testing. 

Alex - Backports ftpmaster
 

Bug#913832: lists.debian.org: New mailing list: debian-runit

[Alexander Wirt]

On Sun, 18 Nov 2018, Dmitry Bogatov wrote:

> 
> [2018-11-15 20:31] Alexander Wirt 
> > On Thu, 15 Nov 2018, Dmitry Bogatov wrote:
> > 
> > > Package: lists.debian.org
> > > Severity: wishlist
> > > 
> > > Please create new mailing list.
> > > 
> > > name: debian-runit
> > > [...]
> > In my eyes this list is far too special for lists.debian.org.
> 
> Fine. Any suggestions, how to proceed? I believe there is no way to
> create list on @lists.alioth.debian.org (like used by debian haskell
> group).
I have no idea about the policy of the l.a.d.o follow up service, but you
should just ask them.

Alex
 

Bug#913832: lists.debian.org: New mailing list: debian-runit

[Alexander Wirt]

On Sat, 17 Nov 2018, Lorenz wrote:

> On Thu, 15 Nov 2018 20:31:21 +0100
> > On Thu, 15 Nov 2018, Dmitry Bogatov wrote:
> >>...
> > > Please create new mailing list.
> >> 
> > >  Currently I do maintain runit init system and related tools {dh-runit
> > >  and *-run packages} myself, but as contributors appear, there is need
> > >  in coordinating efforts and team maintainance.
> 
> Alexander Wirt  wrote:
> > In my eyes this list is far too special for lists.debian.org.
> 
> Hi Alexander,
> as a runit user and contributor I support Dmitry request for a dedicated
> mailing list.
> Currently available way to contribute to runit are
>* Open a bug/whishlist, possibly providing a patch
>* Contact the maintainer privately with mail (1 to 1 comunication)
>* pull request on salsa
> Contributions are scattered across these three, sometimes a mix happens,
> and it's difficult to have a clear idea of what's going on.
> See bug #912937, an example of mixed public/private comunication,
> with the chat going offtopic towards runit's overall state in Debian.
> 
> A dedicated mailing list can help avoid duplication and maybe gather
> some new contributors. There is not a huge list of topics to discuss,
> but all are relevant/low level stuff like
>  * How (when/if) to integrate runit with 'init-system-helpers'
>  * maybe discuss a template for runscripts
>  * if and how introduce runlevel support
>  * how to handle emergency shell
> Those things can easily break a system and one wants to avoid
> "try --> error --> retry" routine, some discussion before may help.
> 
> Finally, for packages like *-run scripts, there will be (hopefully) more
> than one contributor,
> could be handy to have a runit mailing list to set as maintainer with
> contributors as uploaders..
> Hope you can change your mind
Thats possible, but lists.debian.org is not for package maintenance lists. 

Alex

Bug#913832: lists.debian.org: New mailing list: debian-runit

[Alexander Wirt]

On Thu, 15 Nov 2018, Dmitry Bogatov wrote:

> Package: lists.debian.org
> Severity: wishlist
> 
> Please create new mailing list.
> 
> name: debian-runit
> rationale:
> 
>  Currently I do maintain runit init system and related tools {dh-runit
>  and *-run packages} myself, but as contributors appear, there is need
>  in coordinating efforts and team maintainance.
> 
> short description: runit init system maintainance discussion
> long description:
> 
>  Discussions of all issues, related to runit and related tools and its
>  integration with rest of Debian.
> 
> category: developers
> subscription policy: open
> post policy: open
> web archive: yes
In my eyes this list is far too special for lists.debian.org. 

Alex - Debian Listmaster
 

Bug#905581: lists.debian.org: Request for new mailing list: debian-salsa-ci

[Alexander Wirt]

On Sat, 10 Nov 2018, Agustin Henze wrote:

> Hi there, just pinging :).
I don't think a list for that specific topic makes sense. 

But that are just my 2 cent. 


> 
> On Mon, 6 Aug 2018 16:12:30 +0200 Agustin Henze  wrote:
> > Package: lists.debian.org
> > Severity: wishlist
> > 
> > Name: debian-salsa-ci *
> > Rationale: While building Salsa's CI pipeline for Debian developers,
> > maintainers and contributor in general[0] and we need a place where we can 
> > have
> > public discussions.
> > Short Description: Discussion list for the Debian Salsa's CI pipelines.
> > Long Description: Debian Salsa's CI pipeline discussion for the Debian 
> > Project
> > Category: Developers
> > Subscription Policy: Open
> > Post Policy: Open
> > Web Archive: Yes
> > 
> > * We already discuss with the debian-ci-team and we agreed that we have
> > different goals for now.
> > 
> > [0] https://salsa.debian.org/salsa-ci-team/pipeline/
> > 
> 
> 
> -- 
> TiN
> 





signature.asc
Description: PGP signature

Bug#905411: New list creation: debian-fundraising

[Alexander Wirt]

On Wed, 03 Oct 2018, Louis-Philippe Véronneau wrote:

> On 2018-10-03 1:30 p.m., Hanno 'Rince' Wagner wrote:
> > Hi Louis-Philippe!
> > 
> > On Wed, 29 Aug 2018, Louis-Philippe Véronneau wrote:
> > 
> >> Any news regarding the creation of this ML?
> >>
> >> I know you said 'This has to be discussed within the team.', but it's
> >> been a month and it's hard to go forward with this project if we don't
> >> have a platform to discuss on...
> > 
> > I am sorry that this has been delayed.
> > 
> >> Is the answer to our request of a closed ML from listmasters is a strait
> >> 'No'?
> > 
> > our experience is that closed lists make much more work than it is
> > worth. I do not know your reasoning for a closed list - just
> > confidentiality or more - but we would prefer an open list since this
> > is just easier to maintain.
> > 
> >> If that is the only blocker for the creation of that mailing list, I
> >> guess we can work on an open ML for now. I don't think we'll be dealing
> >> with sponsors directly for the next year anyway.
> > 
> > Okay, then If you agree to this, I can create that list without an
> > archive. so please confirm that the list can be open.
> > 
> > best regards, Hanno Wagner, Listmaster of the day
> > 
> 
> I don't think we will discuss confidential sponsor infos on that list
> for now, as we are only starting the process.
> 
> An open list without archive thus suits me just fine.
> 
> Thanks for your work maintaining the lists!
By the way, what differentates that list from debconf-sponsoring? Why do you
need two lists that do more or less the same? 

Alex



signature.asc
Description: PGP signature

Bug#817641: Bug#906637: RM: pytone -- ROM; RC-buggy; Unmaintained; Upstream dead

[Alexander Wirt]

merge 906598 906637
thanks

On Sat, 18 Aug 2018, Boyuan Yang wrote:

> Package: ftp.debian.org
> Severity: normal
> X-Debbugs-CC: formo...@debian.org
> 
> Dear FTP Masters,
> 
> As per the statement from package pytone's maintainer [1], please 
> remove package pytone from unstable archive.
> 
> This package is currently RC-buggy (debhelper v4 removal) and its 
> upstream is dead since 2010. The package also didn't receive any 
> maintainer upload since 2007.
> 
> Hi formorer, thank you for your previous clarification in #817641. I 
> am opening this RM bug to request the package removed. Feel free to 
> manipulate this bug if you find it necessary.
There is already 906598

Alex


signature.asc
Description: PGP signature

Bug#906598: RM: pytone -- ROM; Upstread and basically unmaintained

[Alexander Wirt]

Package: ftp.debian.org
Severity: normal

Hi, 

I failed to maintain pytone properly in the last years (last upload
2007) and its latest upstream version is nearly as old as the last
upload. There hasn't been any notable interest in pytone in the last
years, therefore we should probably just remove it. 

thanks

Alex

Bug#817641: pytone: Removal of debhelper compat 4

[Alexander Wirt]

On Sat, 18 Aug 2018, Boyuan Yang wrote:

Hi, 
> It seems that this package (pytone) maintained by you hasn't receive 
> any maintainer upload since 2007 (!). I'm wondering if you still have 
> time to deal with its RC bugs and upload new versions, or it might 
> better to submit RFA bugs / orphaning the package for QA purposes.
Um yeah, you are right. We should probably remove it from debian. Its last
upstream version is nearly as old as my last upload. 

alex



signature.asc
Description: PGP signature

Bug#905411: New list creation: debian-fundraising

[Alexander Wirt]

On Sat, 04 Aug 2018, Louis-Philippe Véronneau wrote:

> On 2018-08-04 18:58, Alexander Wirt wrote:
> >> Subscription Policy: closed, manual approval. We don't want random
> >> people to subscribe to this ML. This list will eventually be used to
> >> talk about confidential discussions we've had with sponsors.
> > in general I can say that we had bad experiences with such closes lists and
> > that we don't want them. This has to be discussed within the team. I also
> > think debian should be more transparent. 
> 
> By 'random', I meant people not part of the Debian project. Bad choice
> of language on my end, sorry.
users are also part of the project. 

> 
> Is there a way to make the subscription only available to DDs/DMs? I
> wouldn't mind that.
No, we don't have such a mechanism.

Alex
> 
> -- 
>   ,''`.
>  : :'  : Louis-Philippe Véronneau
>  `. `'`  po...@debian.org / veronneau.org
>`-
> 





signature.asc
Description: PGP signature

Bug#905411: New list creation: debian-fundraising

[Alexander Wirt]

On Sat, 04 Aug 2018, Louis-Philippe Véronneau wrote:

> Package: list.debian.org
> Severity: wishlist
> 
> Name: debian-fundraising
> 
> Rationale: We have a mailing list for the DebConf fundraising, but we
> have been talking about merging into a larger Debian fundraising team. A
> BoF at DebConf18 concluded we needed a space to talk about this some more.
> 
> Short description: Debian fundraising efforts
> 
> Category: Miscellaneous Debian
> 
> Subscription Policy: closed, manual approval. We don't want random
> people to subscribe to this ML. This list will eventually be used to
> talk about confidential discussions we've had with sponsors.
in general I can say that we had bad experiences with such closes lists and
that we don't want them. This has to be discussed within the team. I also
think debian should be more transparent. 

Alex



signature.asc
Description: PGP signature

Bug#901584: DMs' difficulties in uploading packages into Backports (Was: Re: Bug#901584 closed by Adam Borowski )

[Alexander Wirt]

On Fri, 15 Jun 2018, Boyuan Yang wrote:

> > -- Forwarded message --
> > From: Adam Borowski 
> > To: 901584-d...@bugs.debian.org
> > Cc:
> > Bcc:
> > Date: Fri, 15 Jun 2018 15:37:07 +0200
> > Subject: Re: Bug#901584: RFS: flameshot/0.5.1+git20180601-1~bpo9+1
> > On Fri, Jun 15, 2018 at 11:04:31AM +0800, Boyuan Yang wrote:
> > >   I am looking for a sponsor for my package "flameshot" into 
> > > stretch-backports.
> > >
> > >  * Package name: flameshot
> > >Version : 0.5.1+git20180601-1~bpo9+1
> >
> > It's an update, so it doesn't need to go through NEW, and you got DM rights.
> > So you should be able to upload it yourself...
> > I've done it this time, though.
> 
> According to https://backports.debian.org/Contribute/ :
> 
> "All Debian Developers (DD) can get their uid into the backports ACL.
> If you want to get include please open a ticket in the debian request
> tracker - please use the backports queue for the ticket."
> 
> [...]
> 
> "Debian Maintainers (DM) can also get their uid into the backports
> ACL. Please follow the instructions for Debian Developers."
> 
> "The Debian Maintainer needs to have upload rights for the specific
> package they want to upload to backports (the same right they need for
> uploading that package to unstable), otherwise the upload will not
> succeed."
> 
> That essentially means that a DM can only directly upload onto
> Debian's backports repositories if:
> 
> 1. That Debian Maintainer is granted DM upload right for the package;
> 
> 2. and that Debian Maintainer asks another Debian Developer to open an
> RT ticket to get the uid into the backports ACL and wait till the
> ticket is finished. Note that non-DDs have no access to RT system thus
> a sponsorship of RT ticket from other DDs is needed.

3. and another DD uploads the package to backports-new (DMs can't upload to
new). 

(and as stated otherwise you can open tickets by mail). 

Alex

Bug#900383: virtualbox-guest-additions-iso: Please use git-lfs on salsa

[Alexander Wirt]

reopen #900383
thanks

On Wed, 30 May 2018, Gianfranco Costamagna wrote:

> I enabled "very large storage" in gitlab settings, and did this in my repo:
> $ git lfs install
> 
> $ git lfs track "*.iso" 
> $ git config 
> lfs.https://salsa.debian.org/pkg-virtualbox-team/virtualbox-guest-additions-iso.git/info/lfs.locksverify
>  true
> 
> I hope this is enough to fix the issue, please reopen if I did anything wrong
Almost, thanks. But that doesn't add files already commited to lfs. Look into 
https://github.com/git-lfs/git-lfs/wiki/Tutorial#migrating-existing-repository-data-to-lfs
for migrating old data. 

It it worked your iso should have a small "lfs" icon next behind to its
filename, see my lfs test repo:

https://salsa.debian.org/formorer/lfs-test


Thanks

Alex

Bug#900383: virtualbox-guest-additions-iso: Please use git-lfs on salsa

[Alexander Wirt]

Package: virtualbox-guest-additions-iso
Severity: wishlist

Hi, 

your repo on salsa wastes a lot of space for your iso, please consider
using git-lfs on salsa. 

Thanks

Alex - on behalf of the salsa admins

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

Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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

virtualbox-guest-additions-iso depends on no packages.

Versions of packages virtualbox-guest-additions-iso recommends:
ii  virtualbox-5.2 [virtualbox]  5.2.8-121009~Debian~stretch

virtualbox-guest-additions-iso suggests no packages.

Bug#900260: New upstream version available (2.0.0)

[Alexander Wirt]

On Mon, 28 May 2018, Andras Korn wrote:

> Package: keepalived
> Version: 1:1.3.9-1
> Severity: normal
> 
> Hi,
> 
> keepalived 2.0.0 just came out. 1.3.9 is quite dated; there have been several 
> 1.4.x releases since its release.
> 
> Please package 2.0.0 or orphan the keepalived package if you lost interest.
I didn't lost interest, but the alioth deprecation used all my free time.
Alioth is gone in a few days and keepalived is nearly number one on my
package list. 

Alex

Bug#900135: [lists.debian.org] please provide debian-wine-digest

[Alexander Wirt]

On Sat, 26 May 2018, Jens Reyer wrote:

> Package: lists.debian.org
> Severity: normal
> 
> Hi,
> 
> thanks again for the quick setup of the new debian-wine mailinglist.
> 
> Now a user requested to read it as digest.  I've seen that a few other
> mailing lists are provided also in this form, e.g. debian-devel-digest.
> 
> Can you do the same for debian-wine?
Nope, we don't provide (new) digest lists anymore for some time now, they
mean a lot overhead and tbh your list is not big enough. 

Alex
 

Bug#876057: lists.debian.org: Request for new mailing list: debian-nvidia

[Alexander Wirt]

On Mon, 18 Sep 2017, Luca Boccassi wrote:

> Package: lists.debian.org
> Severity: wishlist
> 
> Name: debian-nvidia
> 
> Rationale:
> 
> Currently we use pkg-nvidia-devel on Alioth to discuss development
> related to the Nvidia drivers and their userspace stack (CUDA etc),
> both among developers and engaged users.
> For example, sometimes we have users who volunteer to test pre-upload
> new versions of the drivers and we use the mailing list to discuss the
> effort.
> We also use it among developers to coordinate effort, which often does
> not map directly to a bug. There are 4 active developers, and other
> less-active ones, at the moment.
> With the deprecation of Alioth we'd be missing a public equivalent, so
> we would like to request the creation of a debian-nvidia list, if
> possible.
I don't think it makes sense to create an nvidia specific mailinglist. If you
want some generic mailinglist for packaging and discussion about all gpus,
fine. 

Alex



signature.asc
Description: PGP signature

Bug#896811: [Pkg-nagios-devel] Bug#896811: stretch-pu: package icinga2/2.6.0-2+deb9u1

[Alexander Wirt]

On Tue, 01 May 2018, Felix Geyer wrote:

> Hi Bas,
> 
> On 24.04.2018 15:08, Bas Couwenberg wrote:
> > Hi Felix,
> > 
> > Thanks for caring about icinga2.
> > 
> > Please help maintain the package withing the Nagios team.
> > 
> > On 2018-04-24 14:59, Felix Geyer wrote:
> >> I'd like to upload this fix to stretch, debdiff is attached.
> > 
> > Please push your changes to the (to be created) stretch branch of the git 
> > repository:
> > 
> >  https://salsa.debian.org/nagios-team/pkg-icinga2
> 
> Sure thing.
> Since I don't have write access to the Git repo I opened
> https://salsa.debian.org/nagios-team/pkg-icinga2/merge_requests/1
You now have. 

Alex
 

Bug#896760: DDPO: add Salsa icon to VCS column

[Alexander Wirt]

On Tue, 24 Apr 2018, Daniel Pocock wrote:

> 
> 
> On 24/04/18 13:20, James McCoy wrote:
> > On Tue, Apr 24, 2018 at 10:27:47AM +0200, Daniel Pocock wrote:
> >> When looking at a long list of packages it is hard to see if any have
> >> been missed.  The VCS URLs don't make it obvious because sometimes the
> >> VCS has moved but there hasn't been a new upload of the package.
> > 
> > How would one detect that the VCS has moved if there hasn't been a new
> > upload?
> > 
> 
> 
> It may involve a couple of scripts:
> 
> - on alioth, a job that runs periodically and detects whether
> .git/description mentions salsa
No new jobs on alioth.
> 
> - on salsa, a job that checks the debian/changelog or debian/control in
> each repository to identify the name of the source package
No jobs on salsa. Salsa is not for cronjobs of any kind.  

Alex
 

Bug#894429: Please create new list debian-deepin

[Alexander Wirt]

On Mon, 09 Apr 2018, Yanhao Mo wrote:

> Hi Alexander,
> 
> I am a member of pkg-deepin.
> 
> Process porting all deepin softwares (include the whole Deepin Desktop
> Environment as well as deepin applications) are still active, and there
> are still a lot of work need to be done. As a work team(pkg-deepin team)
> we want our all packages under one umbrella to make the whole process easy
> to track. And we also need this list for communicate between our
> members, that will make our work easier. Although there are few messages
> now on pkg-deepin-de...@lists.alioth.debian.org now, but if the Deepin
> softwares gaining more debian users, we need a list for users seeking
> help from us conveniently. And if we lose it, we will have to pay
> much of extra attentions to find an workaround. That's painful. So
> since the coming of shutdown of Alioth we really need a new mail list
> to make our work still smoothly as before.
Alioth lists are not shutting down, there is a replacement for it.

Alex



signature.asc
Description: PGP signature

Bug#894429: lists.debian.org: Please create new list debian-deepin

[Alexander Wirt]

On Fri, 30 Mar 2018, Boyuan Yang wrote:

> Package: lists.debian.org
> Severity: wishlist
> X-Debbugs-CC: pkg-deepin-de...@lists.alioth.debian.org
> debian-chinese...@lists.debian.org
> 
> Debian Deepin Packaging Team would like to request a mailing list:
> debian-deepin for development purpose. The following is detail information:
> 
> 
> Name: debian-deepin
> 
> Rationale:
> 
>  Debian Deepin Packaging Team has been working to move softwares from Deepin
>  (a downstream derivative based on Debian) into Debian and maintain them.
>  Our ultimate goal is to port the whole Deepin Desktop Environment (DDE) into
>  Debian. The team has been using maillist on Alioth
>  (pkg-deepin-de...@lists.alioth.debian.org)  since its establishment. With the
>  shutdown of Alioth, we believe that the team should move its maillist under
>  lists.debian.org, just like other desktop environments in Debian.
I am not sure if this warrants its own list on l.d.o, but we will discuss
that.

alex
 

Bug#891744: Please change default values for $final_spam_destiny and $final_banned_destiny to D_DISCARD

[Alexander Wirt]

On Wed, 28 Feb 2018, Laurent Bigonville wrote:

> Le 28/02/18 à 14:36, Alexander Wirt a écrit :
> > On Wed, 28 Feb 2018, Laurent Bigonville wrote:
> > 
> > > Le 28/02/18 à 14:28, Alexander Wirt a écrit :
> > > > severity #891744 minor
> > > > thanks
> > > > 
> > > > On Wed, 28 Feb 2018, Laurent Bigonville wrote:
> > > > 
> > > > > Package: amavisd-new
> > > > > Version: 1:2.10.1-4
> > > > > Severity: important
> > > > > 
> > > > Hi,
> > > > > According to the RELEASE_NOTES:
> > > > > 
> > > > > - due to popular demand to reduce undesired and unintentional 
> > > > > backscatter,
> > > > > defaults for the settings $final_spam_destiny and 
> > > > > $final_banned_destiny
> > > > > were changed. Previously they both defaulted to D_BOUNCE, new 
> > > > > defaults
> > > > > are:
> > > > > 
> > > > >   $final_virus_destiny  = D_DISCARD;
> > > > >   $final_banned_destiny = D_DISCARD;
> > > > >   $final_spam_destiny   = D_PASS;
> > > > >   $final_bad_header_destiny = D_PASS;
> > > > > 
> > > > > I think that the defaults should be updated in debian as well.
> > > > > 
> > > > > I got my mail server banned from hotmail.com because of debian default
> > > > > value being D_BOUNCE.
> > > > This is more minor. The configuration is explicitly an example. If you 
> > > > run it
> > > > unaudited noone can help you. I find it more dangerous just to drop 
> > > > mails by
> > > > default, especially during the implementation of a proper policy it 
> > > > helps to
> > > > see that things get lost. However, it is not important.
> > > Well, spamming other people because you are generating DSN to random
> > > addresses seems quite bad(tm) by my book.
> > And people not reviewing example config on my.
> 
> Then please at least add a comment telling that using D_BOUNCE in production
> is actually dangerous and can lead to risks of people being banned from mail
> providers (hotmail/gmail/...) or generate spam to other people.
We will change it, I just disagreed on the severity.

Alex
 

Bug#891744: Please change default values for $final_spam_destiny and $final_banned_destiny to D_DISCARD

[Alexander Wirt]

On Wed, 28 Feb 2018, Laurent Bigonville wrote:

> Le 28/02/18 à 14:28, Alexander Wirt a écrit :
> > severity #891744 minor
> > thanks
> > 
> > On Wed, 28 Feb 2018, Laurent Bigonville wrote:
> > 
> > > Package: amavisd-new
> > > Version: 1:2.10.1-4
> > > Severity: important
> > > 
> > Hi,
> > > According to the RELEASE_NOTES:
> > > 
> > > - due to popular demand to reduce undesired and unintentional backscatter,
> > >defaults for the settings $final_spam_destiny and $final_banned_destiny
> > >were changed. Previously they both defaulted to D_BOUNCE, new defaults
> > >are:
> > > 
> > >  $final_virus_destiny  = D_DISCARD;
> > >  $final_banned_destiny = D_DISCARD;
> > >  $final_spam_destiny   = D_PASS;
> > >  $final_bad_header_destiny = D_PASS;
> > > 
> > > I think that the defaults should be updated in debian as well.
> > > 
> > > I got my mail server banned from hotmail.com because of debian default
> > > value being D_BOUNCE.
> > This is more minor. The configuration is explicitly an example. If you run 
> > it
> > unaudited noone can help you. I find it more dangerous just to drop mails by
> > default, especially during the implementation of a proper policy it helps to
> > see that things get lost. However, it is not important.
> 
> Well, spamming other people because you are generating DSN to random
> addresses seems quite bad(tm) by my book.
And people not reviewing example config on my. 

Alex

Bug#891744: Please change default values for $final_spam_destiny and $final_banned_destiny to D_DISCARD

[Alexander Wirt]

severity #891744 minor
thanks

On Wed, 28 Feb 2018, Laurent Bigonville wrote:

> Package: amavisd-new
> Version: 1:2.10.1-4
> Severity: important
> 
Hi,
> According to the RELEASE_NOTES:
> 
> - due to popular demand to reduce undesired and unintentional backscatter,
>   defaults for the settings $final_spam_destiny and $final_banned_destiny
>   were changed. Previously they both defaulted to D_BOUNCE, new defaults
>   are:
> 
> $final_virus_destiny  = D_DISCARD;
> $final_banned_destiny = D_DISCARD;
> $final_spam_destiny   = D_PASS;
> $final_bad_header_destiny = D_PASS;
> 
> I think that the defaults should be updated in debian as well.
> 
> I got my mail server banned from hotmail.com because of debian default
> value being D_BOUNCE.
This is more minor. The configuration is explicitly an example. If you run it
unaudited noone can help you. I find it more dangerous just to drop mails by
default, especially during the implementation of a proper policy it helps to
see that things get lost. However, it is not important. 

Alex
 

Bug#891333: [Pkg-nagios-devel] Bug#891333: new upstream (2.8.1)

[Alexander Wirt]

On Sat, 24 Feb 2018, Daniel Baumann wrote:

> Hi Alexander,
> 
> On 02/24/2018 05:45 PM, Alexander Wirt wrote:
> > want to maintain it?
> 
> for the last 5 years I only maintain a few[0] packages in Debian. In
> general I do not want to maintain more (as I did some years ago),
> however, icinga is quite important to me, so I'd like to volunteer for this.
> 
> I'll prepare an updated package and get it uploaded through my usual
> sponsor if this is alright with you.
> 
> > it is de facto without maintainer. 
> 
> Does this also extend to icingaweb2?
I would say more or less to whole pkg-nagios. 

You can just send me a patch and I will do the upload and add it to the git. 

Alex

Bug#891333: [Pkg-nagios-devel] Bug#891333: new upstream (2.8.1)

[Alexander Wirt]

On Sat, 24 Feb 2018, Daniel Baumann wrote:

> Package: icinga2
> Severity: wishlist
> 
> Hi,
> 
> it would be nice if you could upgrade icinga2 to the current upstream
> release (2.8.1).
want to maintain it? it is de facto without maintainer. 

Alex

Bug#889853: No way to adjust one's subscription preferences

[Alexander Wirt]

On Thu, 08 Feb 2018, 積丹尼 Dan Jacobson wrote:

> Package: lists.debian.org
> 
> On
> https://lists.debian.org/debconf-team/
> there is no way to adjust one's subscription preferences.
> Only a subscribe / unsubscribe button.
There aren't any other preferences. 

Alex
 

Bug#888545: lists.debian.org: Request for new mailing list: debian-sagemath

[Alexander Wirt]

On Fri, 26 Jan 2018, Tobias Hansen wrote:

> Package: lists.debian.org
> Severity: wishlist
> 
> Dear listmasters,
> 
> With the upcoming shutdown of alioth, the Debian SageMath Team [1] needs a
> new mailing list for discussions about the packaging effort.
there will be a lists.alioth replacement. Since we don't want maintainer only 
lists, it is probably a good idea to wait for it.

Alex

Bug#888273: Request for new mailing list: debian-calendar-project

[Alexander Wirt]

On Wed, 24 Jan 2018, Paulo Henrique de Lima Santana wrote:

> On Wed, 24 Jan 2018 15:07:40 +0100
> Alexander Wirt <formo...@debian.org> wrote:
> 
> > That doesn't justify a list on lists.debian.org. I will talk to my other
> > listmasters, but this is probably a wontfix. 
> 
> I had thought on lists.alioth.debian.org but it will be turn off, right?
There will be a replacement and we always communicated that lists.debian.org
is not a replacement for alioth. 

Alex



signature.asc
Description: PGP signature

Bug#888273: Request for new mailing list: debian-calendar-project

[Alexander Wirt]

On Wed, 24 Jan 2018, Paulo Henrique de Lima Santana wrote:

> Hi Alex,
> 
> On Wed, 24 Jan 2018 14:49:06 +0100
> Alexander Wirt <formo...@debian.org> wrote:
> 
> > Sorry, but I really don't think that this special small project warrants a 
> > whole list. What about debian-gsoc to discuss
> > all projects? 
> 
> I believe a unique list to all projects can be confuse.
> Now we have 5 people talking about this project.
That doesn't justify a list on lists.debian.org. I will talk to my other
listmasters, but this is probably a wontfix. 

Alex



signature.asc
Description: PGP signature

Bug#888273: Request for new mailing list: debian-calendar-project

[Alexander Wirt]

On Wed, 24 Jan 2018, Paulo Henrique de Lima Santana wrote:

> Package: lists.debian.org
> Severity: wishlist
> 
> Name:
> debian-calendar-project
> 
> Rationale:
> We would like to use a maling list to discuss between mentors,
> co-mentors and interns about the project: calendar database of
> social events and conferences.
> 
> This project is promoted in Outreachy and Google Summer of Code so
> it would be good to start building up an archive of discussions in a
> single place.
> 
> https://wiki.debian.org/Outreachy/Round15/Projects#Outreachy.2FRound15.2FProjects.2FSocialEventAndConferenceCalendars.A_calendar_database_of_social_events_and_conferences
> 
> Short description:
> This is the list used to discuss the calendar project.
> 
> Long description:
> This is the list used by mentors, co-mentors and interns of outreach to
> discuss the development of calendar database of social events and
> conferences.
Sorry, but I really don't think that this special small project warrants a 
whole list. What about debian-gsoc to discuss
all projects? 

Alex



signature.asc
Description: PGP signature

Bug#888136: lists.debian.org: Request for new mailing list: debian-pkg-security

[Alexander Wirt]

On Tue, 23 Jan 2018, Raphaël Hertzog wrote:

> Package: lists.debian.org
> Severity: wishlist
> 
> Name: debian-pkg-security
> 
> Rationale:
> 
> We merged the pkg-security (27 members) and forensics team (31
> members) while moving to salsa. We maintain more than 200 packages and
> need a place to discuss together (the salsa project already has 25
> members and we have many more -guest users that have to be added). The
> list will typically host:
> - discussions about new tools to package
> - request for sponsorship when a non-DD has prepared an updated
>   package
> - other internal discussions (policies, goals, etc.)
> 
> Short Description:
> 
> Packaging of security-related tools
> 
> Long Description:
> 
> Official mailing list of the Debian pkg-security team. This team is about
> packaging of security-related tools into Debian. The list hosts
> discussions between team contributors. Upstream authors of security tools
> and contributors of security-related Debian derivatives are welcome
> too.
> 
> More information about the team:
> https://wiki.debian.org/Teams/pkg-security
> 
> Category: developers
> 
> Subscription Policy: open
> 
> Post Policy: open
> 
> Web Archive: yes
After discussion the list is fine for me under a different name: 

debian-security-tools and a slightly revised description:

Short Description:
 
Packaging and usage of security-related tools on Debain
 
Long Description:
Mailinglist for discussion of issues, usage and packaging of security
related tools on Debian systems. 
.
This list is also the home of the pkg-security team.
More information about the team:
https://wiki.debian.org/Teams/pkg-security

Bug#884966: lists.debian.org: Add an onion address to every Debian address in every email by bots (if available in onion.debian.org)

[Alexander Wirt]

On Fri, 22 Dec 2017, TemTem wrote:

> Oh no, I fucking revealed my real name in my attachment. Can someone who has 
> access delete the attachment? Please, ASAP. I am very uncomfortable revealing 
> my real name especially in large communities like Debian. If you are reading 
> this, if you are kind, can you please don't open the attachment, for the sake 
> of my privacy? I promise, I will reupload the attachment (with my real name 
> censored). Thank you very much.

Bug#884573: RM: torbrowser-launcher/0.2.6-2~bpo8+1

[Alexander Wirt]

On Sun, 17 Dec 2017, Adam D. Barratt wrote:

> Control: reassign -1 ftp.debian.org
> 
> On Sun, 2017-12-17 at 14:15 +0900, Roger Shimizu wrote:
> > The old version of torbrowser-launcher cannot work properly anymore,
> > because it uses the embedded old key.
> > That's also the reason why it also missed the stretch release [0].
> > 
> > People want to use it in stable(jessie) should consider sloppy
> > backports [1].
> > 
> > So please kindly help to remove torbrowser-launcher/0.2.6-2~bpo8+1.
> > Thank you!
> > 
> > [0] https://bugs.debian.org/861744
> > [1] https://wiki.debian.org/TorBrowser#Debian_8_.22Jessie.22
> 
> The Release Team don't manage backports suites.
> 
> I'm not sure if removals from backports are handled by the FTP team or
> the backports team directly, so reassigning to the former for now.
directly. And as I already told those guys, the bugs don't belong in the bts,
but in the RT. 

Alex
 

Bug#882128: bulk subscription of a single address to multiple lists

[Alexander Wirt]

On Sun, 19 Nov 2017, Daniel Pocock wrote:

> Package: lists.debian.org
> Severity: wishlist
> 
> It would be useful to provide a way for a single person to quickly
> subscribe to multiple lists.
> 
> An example of this is for new participants in Outreachy and GSoC.
> 
> There could be a few different ways that people interact with this:
> 
> - on the web site, provide check boxes next to the list names, the user
> can choose multiple check boxes and be subscribed with a single
> confirmation email
> 
> - somebody (e.g. a GSoC mentor) can construct a URL that contains the
> names of multiple lists and send that URL to people through email or by
> placing the URL in the wiki.  When somebody clicks the URL, they see a
> list of the mailing lists they are going to join and they are asked to
> enter the email address they want to subscribe with.
like: https://www.debian.org/MailingLists/subscribe ?

Alex
 

Bug#878894: lists.debian.org: Request for migration of mailing list: debconf-announce

[Alexander Wirt]

tag 878894 moreinfo
thanks

On Tue, 17 Oct 2017, Daniel Lange wrote:

> Package: lists.debian.org
> Severity: wishlist
> 
> Name: debconf-announce
> 
> Rationale:
> As per 
> https://www.mail-archive.com/debconf-team@lists.debconf.org/msg14555.html 
> Task #2 and DSA RT #6925:
> We are migrating the DebConf mailing lists from locally run hardware / 
> software to DSA / listmasters.
> 
> Short description:
> Debconf Announcements
> 
> Long description:
> Important news about Debconf. This list is a *MUST* for everyone, organizer 
> or participant. Postings are moderated, discussion happens at 
> debconf-disc...@lists.debian.org
> 
> Category: Debconf
> 
> Subscription policy: open
> 
> Post policy: moderated
Who should be the moderator(s)?

What about old data or subscribers? 

Bug#876144: lists.debian.org: Request for new mailing list: pkg-gnupg-maint

[Alexander Wirt]

On Tue, 19 Sep 2017, Daniel Kahn Gillmor wrote:

> On Tue 2017-09-19 07:18:24 +0200, Alexander Wirt wrote:
> > This is one of the examples we will probably not accept,
> 
> thanks for the prompt response, Alex.
> 
> > but we will discuss that internally again.
> 
> If you decide to not accept it, where do you recommend for packaging
> teams to have team-specific conversations that are not specifically bug
> reports?
> 
> should we adopt non-debian channels or private mail for those
> discussions?  Or is there some other recommended approach?
I am not exactly sure about the best proposal yet. Do you really need a
mailinglist for that or would some kind of maintaineralias (via tracker)
work? We are currently working on ideas. l.d.o unfortunately isn't the right
place for such tiny (sorry) maintainer lists, our tools and manpower do not 
scale well. 

One of my ideas was to improve tracker.d.o and maybe provide some (external?)
service for archiving mails (similar to gmane) with hyperkitty (the mailman3
archiver). What do you think about it? Would the combination of tracker and
an archiver work for you? 

Thanks in advance
Alex


signature.asc
Description: PGP signature

Bug#876144: lists.debian.org: Request for new mailing list: pkg-gnupg-maint

[Alexander Wirt]

On Mon, 18 Sep 2017, Daniel Kahn Gillmor wrote:

> Package: lists.debian.org
> Severity: wishlist
> 
> pkg-gnupg-ma...@lists.alioth.debian.org currently mostly hosts bug
> reports, but it is also the maintainer address for the packages
> maintained by the GnuPG packaging team, and it hosts some discussion
> about packaging plans and questions, like the following:
This is one of the examples we will probably not accept, but we will discuss
that internally again.

Alex
 

Bug#872558: scripts and other tooling

[Alexander Wirt]

On Fri, 18 Aug 2017, Geert Stappers wrote:

> 
> from the minutes of the Alioth Successors sprint Hamburg 2017:
> 
>   TODO: can we prepare an automation for importing existing lists
>   (archive + subscribers; no settings) from alioth? <- formorer said
no, there won't be any kind of automation. Every list has to be checked on
its own. 

Alex
 

Bug#701200: ferm

[Alexander Wirt]

On Fri, 04 Aug 2017, Adam McKenna wrote:

> Alright I guess I'll have to take this to debian-security then, this may
> even warrant a CVE
I completly disagree, but lets see what -security says.

Alex

Bug#701200: ferm

[Alexander Wirt]

On Fri, 04 Aug 2017, Adam McKenna wrote:

> That makes no sense, if that's the case then why is a default ruleset
> provided for ipv4 but not ipv6?
> 
> More and more systems are running ipv6 these days and ferm users may not
> even know their systems are exposed in this way.
Thats why I fixed it, anyhow, any user should review the ruleset.

Alex

Bug#701200: ferm

[Alexander Wirt]

fixed 701200 2.4-1
thanks

On Fri, 04 Aug 2017, Adam McKenna wrote:

> tag 701200 security
> 
> This is not just a bug, this is a gaping security hole.  The default
> configuration is wide open on ipv6.
> 
> Please add, at a minimum, the following default rules for ipv6:
This was fixed in unstable with the latest upload. 
I don't think this justifies a stable update. 

I expect users to write their own ruleset.

Alex

Bug#774553: exim4: Do not scan outgoing mail for spam

[Alexander Wirt]

On Thu, 13 Jul 2017, Andreas Metzler wrote:

> On 2017-07-13 Alexander Wirt <formo...@debian.org> wrote:
> > On Thu, 13 Jul 2017, Marc Haber wrote:
> 
> >> On Thu, Jul 13, 2017 at 08:47:56AM +0200, Alexander Wirt wrote:
> >>> I am talking about the report:
> >>> X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up
> >>> entirely of whitespace (char 20 hex): X-Spam_report: ...T_ADDRESS@@
> >>> for details.  Content previ[...]
>  
> >> Just making sure, this is a report generated by Amavis on
> >> lists.debian.org, not on the bug reporter's exim, right?
> > No. Its generated by the spamd exim is calling. No amavis involved. It just
> > catches the broken header on arrival. 
> 
> What we are trying to point out is that exim does not add an
> "X-Amavis-Alert" header. Is your issue about a broken "X-Amavis-Alert"
> header or is it about an X-Spam_report that amavis does not like?
It is about Exim/Spamassassin adding non rfc conform headers. 

"No amavis involved. It just catches the broken header on arrival."

Please forget you ever heard amavis. 

Alex

Bug#774553: exim4: Do not scan outgoing mail for spam

[Alexander Wirt]

On Thu, 13 Jul 2017, Marc Haber wrote:

> On Thu, Jul 13, 2017 at 08:47:56AM +0200, Alexander Wirt wrote:
> > I am talking about the report:
> > X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up
> > entirely of whitespace (char 20 hex): X-Spam_report: ...T_ADDRESS@@
> > for details.  Content previ[...]
> 
> Just making sure, this is a report generated by Amavis on
> lists.debian.org, not on the bug reporter's exim, right?
No. Its generated by the spamd exim is calling. No amavis involved. It just
catches the broken header on arrival. 

Alex

Bug#774553: exim4: Do not scan outgoing mail for spam

[Alexander Wirt]

On Thu, 13 Jul 2017, Marc Haber wrote:

> On Thu, Jul 13, 2017 at 08:47:56AM +0200, Alexander Wirt wrote:
> > I am talking about the report:
> > X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up
> > entirely of whitespace (char 20 hex): X-Spam_report: ...T_ADDRESS@@
> > for details.  Content previ[...]
> 
> If this very header is generated in a non-rfc-conforming way, then it
> would be up to amavis to generate it correctly. Not an exim issue.
> 
> The presence of an X-Header does not make the message rfc-uncompliant.
> 
> > This does not belong to outgoing mail.
> 
> The configuration in question is not part of the default configuration.
> Only the local admin can judge what constitutes "outgoing" in the site
> context.
> 
> I am not opposed to the patch in question, but alas, it doesn't help.
This is not about amavis. Amavis is not involved. This is about
40_exim4-config_check_data which uses SpamAssassin with spamd. 

Alex

Bug#774553: exim4: Do not scan outgoing mail for spam

[Alexander Wirt]

On Thu, 13 Jul 2017, Marc Haber wrote:

> On Wed, Jul 12, 2017 at 10:59:22PM +0200, Alexander Wirt wrote:
> > On Sun, 04 Jan 2015, Andreas Metzler wrote:
> > > On 2015-01-04 Rainer Dorsch <m...@bokomoko.de> wrote:
> > > > Package: exim4
> > > > Version: 4.84-6
> > > > Severity: wishlist
> > > > Tags: patch
> > > 
> > > > Dear Maintainer,
> > > 
> > > > I am running exim since a few years and scanned incoming and
> > > > outgoing mails for spam, where outgoing does not make a lot of sense
> > > > or even hurts. 
> > > [...]
> > > 
> > > I tend to disagree here. - Scanning outgoing mails to avoid spreading
> > > viruses sent by infectected users makes sense.
> > jftr, it dies hurt to add the spamassassin report to outgoing mails. Those
> > mails does are rfc2822 conform any more. Debian listserver will discard such
> > mails. SA Report should not get added to mail leaving the server.
> 
> In which point does the adding of X-Headers violate RFC822?
> 
> Additionally, the patch given in this bug report will not help in the
> case where a message is accepted by exim as a relay from a permitted IP
> range as it will only exempt authenticated mail.
> 
> So, the question is, how do we determine that a message is "outgoing"
> not from exim's point of view, but from the _site's_ point of view.
> 
> In addition, the headers in question seem to be added by Amavis, not by
> exim, right?
I am talking about the report:
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up
entirely of whitespace (char 20 hex): X-Spam_report: ...T_ADDRESS@@
for details.  Content previ[...]

This does not belong to outgoing mail.

Alex

Bug#774553: exim4: Do not scan outgoing mail for spam

[Alexander Wirt]

On Sun, 04 Jan 2015, Andreas Metzler wrote:

> On 2015-01-04 Rainer Dorsch  wrote:
> > Package: exim4
> > Version: 4.84-6
> > Severity: wishlist
> > Tags: patch
> 
> > Dear Maintainer,
> 
> > I am running exim since a few years and scanned incoming and
> > outgoing mails for spam, where outgoing does not make a lot of sense
> > or even hurts. 
> [...]
> 
> I tend to disagree here. - Scanning outgoing mails to avoid spreading
> viruses sent by infectected users makes sense.
jftr, it dies hurt to add the spamassassin report to outgoing mails. Those
mails does are rfc2822 conform any more. Debian listserver will discard such
mails. SA Report should not get added to mail leaving the server.

Alex - with its listmaster hat on

Bug#867973: jessie-pu: package wordgrinder/0.5.1-1

[Alexander Wirt]

On Mon, 10 Jul 2017, Adam D. Barratt wrote:

> Control: tags -1 + moreinfo
> 
> On Mon, 2017-07-10 at 19:44 +, David Given wrote:
> > The version in jessie of my package WordGrinder is painfully old and has a
> > number of showstopping bugs (document corruption and loss of data). The next
> > available version in Debian is the version in stable, 0.6-3, which has fixed
> > these bugs and also contains major functionality improvements.
> > 
> > 0.6-3 builds on jessie out-of-the-box with no repackaging required, and so I
> > would like to propose the version from stable to be included in the next 
> > jessie
> > point release.
> 
> That sounds like you're looking for jessie-backports, rather than a
> stable update.
jessie-backports is not for fixing critical bugs like document corruption.
Those should really get fixed in stable (of course not with an upload of the
version in testing).

 
Alex - Backports ftpmaster

Bug#863802: severity of 863802 is wishlist

[Alexander Wirt]

severity 863802 wishlist
thanks

As discussed, I don't this is a bug.

Bug#864289: RM: schleuder/3.0.1-1

[Alexander Wirt]

On Tue, 06 Jun 2017, Georg Faerber wrote:

> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: rm
> Severity: normal
> 
> Hi all,
> 
> Please remove schleuder from stretch. It's not yet ready to be included
> in the stable suite; we plan to get it into s-bp soon.
Please remember that only packages available in testing can be uploaded to
backports.

Alex



signature.asc
Description: PGP signature

Bug#863864: [Pkg-nagios-devel] Bug#863864: release-notes: Document that nagios is not in stretch and how to switch to icinga (if that is possible)

[Alexander Wirt]

On Thu, 01 Jun 2017, Johannes Ranke wrote:

> Package: release-notes
> Severity: normal
> 
> I assume that switching to icinga is possible, but I am missing a hint in the
> release notes. Will icinga use nagios configuration files?
No, and those files are not fully compatible. 

You will have to do a manual migration.

Alex

Bug#863802: systemd unit breaks ferm in some setups in jessie->stretch upgrade

[Alexander Wirt]

On Wed, 31 May 2017, Moritz Muehlenhoff wrote:

> Package: ferm
> Version: 2.3-2
> Severity: grave
> 
> Ferm is broken in stretch for any rule set which contains resolve() 
> statements.
> (There might be others relying on network, didn't check). This got introduced
> in 2.3-2, which now uses a Wants:/Before: network-pre.target
> 
> In jessie, no systemd unit was provided and the sysvinit script translated to
> 
> # systemctl cat ferm
> # /run/systemd/generator.late/ferm.service
> # Automatically generated by systemd-sysv-generator
> 
> [Unit]
> SourcePath=/etc/init.d/ferm
> Description=LSB: ferm firewall configuration
> DefaultDependencies=no
> Before=sysinit.target
> After=network-online.target remote-fs.target
> Wants=network-online.target
>  
> But since ferm.service is now executed before the network is up, any rule
> containing a resolve() statement now leads to a ferm startup failure:
> 
> # journalctl -u ferm
> -- Logs begin at Wed 2017-05-31 10:53:35 UTC, end at Wed 2017-05-31 11:40:57 
> UTC. --
> May 31 10:53:38 ms-be2001 ferm[1038]: Starting Firewall: fermError in 
> /etc/ferm/conf.d/10_example line 4:
> May 31 10:53:38 ms-be2001 ferm[1038]: just.example.org
> May 31 10:53:38 ms-be2001 ferm[1038]: )
> May 31 10:53:38 ms-be2001 ferm[1038]:
> May 31 10:53:38 ms-be2001 ferm[1038]: )
> May 31 10:53:38 ms-be2001 ferm[1038]: <--
> May 31 10:53:38 ms-be2001 ferm[1038]: DNS query for 'just.example.org' 
> failed: query timed out
> May 31 10:53:38 ms-be2001 ferm[1038]:  failed!
> May 31 10:53:38 ms-be2001 systemd[1]: ferm.service: Main process exited, 
> code=exited, status=101/n/a
> May 31 10:53:38 ms-be2001 systemd[1]: Failed to start ferm firewall 
> configuration.
> May 31 10:53:38 ms-be2001 systemd[1]: ferm.service: Unit entered failed state.
> May 31 10:53:38 ms-be2001 systemd[1]: ferm.service: Failed with result 
> 'exit-code'.
>  
> I'm setting severity to "grave" since this breaks existing setups during the 
> update
> from jessie to stretch.
Which is funny. We had a bunch of bugs about ferm starting late where
everyone stated it should be up before the network is up. 

Someone should decide, which is not me. Therefore I don't think this is
grave.

Alex

Bug#861792: ITP: lr -- list files, recursively

[Alexander Wirt]

On Sun, 07 May 2017, Nicolas Braud-Santoni wrote:

> On Thu, May 04, 2017 at 08:53:27AM +0200, Alexander Wirt wrote:
> > On Thu, 04 May 2017, Nicolas Braud-Santoni wrote:
> > > 
> > > * Package name: lr
> > >   Version : 0.4
> >
> > Please don't (and this counts for your xr ITP too) add new two-letter 
> > binaries. 
> > This will just get everyone into trouble. 
> 
> What would be the rationale for this?
There are not enough two letter names for everyone. Therefore it is preferred
not to polute that namespace. 

Alex

Bug#861792: ITP: lr -- list files, recursively

[Alexander Wirt]

On Thu, 04 May 2017, Nicolas Braud-Santoni wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Nicolas Braud-Santoni 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> * Package name: lr
>   Version : 0.4
>   Upstream Author : Leah Neukirchen 
> * URL : https://github.com/chneukirchen/lr
> * License : MIT
>   Programming Lang: C
>   Description : list files, recursively
> 
> lr is a new tool for generating file listings,
> which includes the best features of ls(1), find(1), stat(1) and du(1).
> 
> It has a powerful and user-friendly filter syntax,
> sorting and formatting capabilities.
Please don't (and this counts for your xr ITP too) add new two-letter binaries. 
This will just get everyone into trouble. 

Alex