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
 

Re: Want to make salsa advertise contact and source code details [and 1 more messages]

[Alexander Wirt]

On Fri, 25 May 2018, Ian Jackson wrote:

> Alexander Wirt writes ("Re: Want to make salsa advertise contact and source 
> code details [and 1 more messages]"):
> > It was a decision by the team to disallow any patch that is not
> > really really needed for function. Please submit your patch
> > upstream.
> 
> I see.  I'm afraid I strongly disagree with this decision, for
> practical reasons, and because of its rationale.  In any case, IMO
> this patch is required for the important function of giving Salsa
> users access to the appropriate contact channels and source code
> reference.
I think that they should use the official docs - or the help button. 
  
> I am sure that my patch would be rejected by upstream.  As I have it,
> it is not suitable for upstream because it hardcodes the Debian
> information.  I obviouslyu do not want to spend the time to redevelop
> the configurable version (like the proprietary version of gitlab has)
> when you have said you will rejected it, and it would also almost
> certainly be rejected by upstream.
Did you asked them? 

 
> Can you please tell me what you think the appropriate path or venue is
> for me to pursue this diagreement ?
Get in contact with upstream and ask them about including the feature in CE. 

Alex

Re: Want to make salsa advertise contact and source code details

[Alexander Wirt]

On Fri, 25 May 2018, Geert Stappers wrote:

> On Fri, May 25, 2018 at 02:54:17PM +0200, Alexander Wirt wrote:
> > On Fri, 25 May 2018, Ian Jackson wrote:
> > > 
> > > 
> > > But, I find this response worrying.  It makes me wonder whether Salsa
> > > is in fact really Free Software, for Debian.  I don't want to suck
> > > energy out of the Salsa team, but:
> > > 
> > > Free Software is not only a question of licences and legal
> > > permissions.  Software is free for a particular user or group of users
> > > if those users can, in practice, exercise the four freedoms, including
> > > modifying it and using the modified version.  (And yes, that means
> > > software freedom can be a matter of degree rather than an absolute,
> > > because it matters how easy it is to exercise one's freedoms.)
> > > 
> > > IMO if we cannot, in practice, modify gitlab as used in Salsa, even to
> > > make simple changes, then it is not free software for us.
> > 
> > Its not a matter of free software, but a matter of us having to support 
> > those
> > patches - which is something we don't want to do. 
> 
> Not knowing who is "we", but the thing I want to says is
> 
> 
>   Do not ask for a lighter load,
>   but ask for more shoulders to carry the load.
This is not about shoulders, but about lessons learned with alioth. 

alex
 

Re: Want to make salsa advertise contact and source code details [and 1 more messages]

[Alexander Wirt]

On Fri, 25 May 2018, Ian Jackson wrote:

> Alexander Wirt writes ("Re: Want to make salsa advertise contact and source 
> code details [and 1 more messages]"):
> > > Can you point me to the source code for Salsa's gitlab instance,
> > > please ?
> > https://salsa.debian.org/salsa/gitlab-ce
> 
> I think I see where to make the change.  How should I test it ?
> 
> If I am right the file that needs to be changed very small, and has
> not been edited at all since September.  In the last year there were
> two conflicting edits, but they were trivial to resolve.  If this
> turns out to be a problem for you then I am happy for you to drop this
> change each time this happens, and I will resolve the conflict myself
> and send a new MR.
It was a decision by the team to disallow any patch that is not really really 
needed
for function. Please submit your patch upstream. 

Alex
 

Re: Want to make salsa advertise contact and source code details [and 1 more messages]

[Alexander Wirt]

On Fri, 25 May 2018, Ian Jackson wrote:

> Quoting my own other mail for more context:
> 
> Ian Jackson writes ("Re: Want to make salsa advertise contact and source code 
> details"):
> > Alexander Wirt tells me that that feature is "EE only", ie AIUI
> > that the Gitlab company have kept that feature proprietary.
> > 
> > That means our choices are:
> ...
> > (ii) Implement the footer as a hardcoded change, where the footer is
> >not configurable but is simply in the source code to our version.
> > 
> > (iii) Leave things as they are, with no references to what the service
> >is, who runs it, how to report issues, and to its source code.
> 
> Alexander Wirt writes ("Re: Want to make salsa advertise contact and source 
> code details"):
> > Its not a matter of free software, but a matter of us having to
> > support those patches - which is something we don't want to do.
> 
> I don't understand what "support" you think my proposed change
> ((ii), above) would need, that would be too difficult.
Every patch you have is a pain in the ass. You have to adapt and support it
for every version.

> I don't know how often you update from upstream but I doubt the merge
> conflicts will be frequent or difficult, and if it's a simple
> statically-determined footer then there are few moving parts to go
> wrong.
at least twice a month. 


> Can you point me to the source code for Salsa's gitlab instance,
> please ?
https://salsa.debian.org/salsa/gitlab-ce

Alex

Re: Want to make salsa advertise contact and source code details

[Alexander Wirt]

On Fri, 25 May 2018, Ian Jackson wrote:

> Sean Whitton writes ("Re: Bug#864354: Bug #864354 in  marked as 
> pending"):
> > Thank you for advocating on behalf of users who are not in a position to
> > use the web form, Ian.
> 
> Thanks for your support, Sean.  I have submitted:
> 
>  https://salsa.debian.org/salsa/webhook/merge_requests/7
>Improve emails slightly
> 
>  https://salsa.debian.org/salsa/support/issues/77
>Please provide web page footer on every page with service information
> 
> In response to the latter, Alexander Wirt writes:
> 
>   Unless this is possible without patching, this will not happen.
> 
> I have no idea whether it is possible without patching.  It seems like
> the kind of feature that would probably already be present and, if
> not, the kind of feature that upstream would probably be happy to
> take.  Failing that, there must surely be some nearly equivalent thing
> that can be done.
> 
> Perhaps someone who knows the gitlab codebase, and/or Ruby, better,
> would like to take a look ?
> 
> 
> But, I find this response worrying.  It makes me wonder whether Salsa
> is in fact really Free Software, for Debian.  I don't want to suck
> energy out of the Salsa team, but:
> 
> Free Software is not only a question of licences and legal
> permissions.  Software is free for a particular user or group of users
> if those users can, in practice, exercise the four freedoms, including
> modifying it and using the modified version.  (And yes, that means
> software freedom can be a matter of degree rather than an absolute,
> because it matters how easy it is to exercise one's freedoms.)
> 
> IMO if we cannot, in practice, modify gitlab as used in Salsa, even to
> make simple changes, then it is not free software for us.
Its not a matter of free software, but a matter of us having to support those
patches - which is something we don't want to do. 

Alex

[DRE-maint] ruby-fog-core_1.45.0-2~bpo9+1_amd64.changes REJECTED

[Alexander Wirt]

Not in testing



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


___
Pkg-ruby-extras-maintainers mailing list
Pkg-ruby-extras-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers

Re: Move packages from alioth to salsa

[Alexander Wirt]

On Thu, 17 May 2018, Geert Stappers wrote:

> On Mon, May 14, 2018 at 07:36:53PM +0200, Alexander Wirt wrote:
> > On Mon, 14 May 2018, Geert Stappers wrote:
> > > On Fri, May 11, 2018 at 11:04:13AM +0200, Jörg Frings-Fürst wrote:
> > > > 
> > > > please can someone move my packages from alioth to salsa.
> > > > 
> > > >  * https://anonscm.debian.org/cgit/collab-maint/argyll.git
> > > >  * https://anonscm.debian.org/cgit/collab-maint/bitz-server.git
>[ ... 24 repos ... ]
> > > >  * https://anonscm.debian.org/cgit/collab-maint/xtrkcad.git
> > > > 
>[ ... 1 repo manually ... ]
> > > > Many thanks.
> > >  
> > > And many repositories need to be done.
> > > On thursday noon have I time for.
> > > 
> > > Having URLs to scripts (and their documention) to automate this
> > > would be a nice to have.
> > > 
> > Several of such scripts exist and they should get used, especially the 
> > import
> > feature. 
> > 
> > for example: https://salsa.debian.org/mehdi/salsa-scripts
> > https://salsa.debian.org/satta/salsa-migration-tools
> > https://wiki.debian.org/Salsa/AliothMigration#Using_a_single_Python_script
> > 
> 
> | $ hostname
> | paddy
> | $ git config --list | grep origin.url
> | remote.origin.url=https://salsa.debian.org/anarcat/alioth-migration
> | $ # reading documation and source
> | $ ./migrate-repo
> | usage: migrate-repo [-h] [-v] [-d] [--loglevel LOGLEVEL] [--syslog [SYSLOG]]
> | [--logfile LOGFILE]
> | path salsa_path
> | migrate-repo: error: too few arguments
> | $ ./migrate-repo collab-maint/argyll  debian/argyll
> | ERROR: local repository not found: collab-maint/argyll
> | $ 
> 
> Am I indeed supposed the run the script on the shell of the git server?
> (Please confirm if so, Please provide additional information if not )
yes.

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

[DRE-maint] ruby-attr-encrypted_3.1.0-1~bpo9+1_amd64.changes REJECTED

[Alexander Wirt]

Not in testing. 



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


___
Pkg-ruby-extras-maintainers mailing list
Pkg-ruby-extras-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers

[pkg-go] golang-go.crypto_0.0~git20180513.94e3fad-1~bpo9+1_amd64.changes REJECTED

[Alexander Wirt]

Not in testing, testing has 1:0.0~git20180322.88942b9-1



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: Gitlab API question: Fetching group ID works not reliably

[Alexander Wirt]

On Tue, 15 May 2018, Andreas Tille wrote:

> Hi,
> 
> I'm using the following script to fetch the group ID of a salsa team:
> 
> #!/bin/sh
> 
> SALSA_URL="https://salsa.debian.org/api/v4;
> SALSA_TOKEN="MYSECRETTOKEN"
> 
> SALSA_GROUP="med-team"
> #SALSA_GROUP="science-team"
> #SALSA_GROUP="r-pkg-team"
> 
> SALSA_GROUP_ID=$(curl --silent -f -XGET --header "PRIVATE-TOKEN: 
> $SALSA_TOKEN" "$SALSA_URL/groups?all_available=false" | jq ".[] | 
> select(.path == \"$SALSA_GROUP\") | .id")
> 
> echo "ID=$SALSA_GROUP_ID"
Sorry this is inefficient. If you know the name of the group, query the group
directly. 

Don't do it that way, that wastes a lot of ressources. 

SALSA_GROUP_ID=$(curl -s -f -XGET --header "PRIVATE-TOKEN: $SALSA_TOKEN" 
"$SALSA_URL/groups/$SALSA_GROUP" | jq '.id')

Alex

Re: Move packages from alioth to salsa

[Alexander Wirt]

On Mon, 14 May 2018, Geert Stappers wrote:

> On Fri, May 11, 2018 at 11:04:13AM +0200, Jörg Frings-Fürst wrote:
> > 
> > Hello,
> > 
> > please can someone move my packages from alioth to salsa.
> > My Username on both systems are jff-guest.
> > 
> >  * https://anonscm.debian.org/cgit/collab-maint/argyll.git
> >  * https://anonscm.debian.org/cgit/collab-maint/bitz-server.git
> >  * https://anonscm.debian.org/cgit/collab-maint/cil.git
> >  * https://anonscm.debian.org/cgit/collab-maint/dmidecode.git
> >  * https://anonscm.debian.org/cgit/collab-maint/downtimed.git
> >  * https://anonscm.debian.org/cgit/collab-maint/fast-cpp-csv-parser.git
> >  * https://anonscm.debian.org/cgit/collab-maint/foomatic-filters.git
> >  * https://anonscm.debian.org/cgit/collab-maint/gcstar.git
> >  * https://anonscm.debian.org/cgit/collab-maint/gnome-pie.git
> >  * https://anonscm.debian.org/cgit/collab-maint/ipmitool.git
> >  * https://anonscm.debian.org/cgit/collab-maint/ipmiutil.git
> >  * https://anonscm.debian.org/cgit/collab-maint/libhx.git
> >  * https://anonscm.debian.org/cgit/collab-maint/libmongo-client.git
> >  * https://anonscm.debian.org/cgit/collab-maint/libonig.git
> >  * https://anonscm.debian.org/cgit/collab-maint/libunistring.git/
> >  * https://anonscm.debian.org/cgit/collab-maint/mailgraph.git
> >  * https://anonscm.debian.org/cgit/collab-maint/mwc.git
> >  * https://anonscm.debian.org/cgit/collab-maint/psocksxx.git
> >  * https://anonscm.debian.org/cgit/collab-maint/sane-backends.git
> >  * https://anonscm.debian.org/cgit/collab-maint/sane-frontends.git
> >  * https://anonscm.debian.org/cgit/collab-maint/scons.git
> >  * https://anonscm.debian.org/cgit/collab-maint/scons-doc.git
> >  * https://anonscm.debian.org/cgit/collab-maint/shotwell.git/
> >  * https://anonscm.debian.org/cgit/collab-maint/simple-scan.git
> >  * https://anonscm.debian.org/cgit/collab-maint/uriparser.git
> >  * https://anonscm.debian.org/cgit/collab-maint/xbase64.git
> >  * https://anonscm.debian.org/cgit/collab-maint/xtrkcad.git
> > 
> 
> There is now https://salsa.debian.org/debian/dmidecode
> Account jff-guest has developer role.
> 
> The Salsa repo is empty, it waits for 
> 
>   cd existing_repo
>   git remote rename origin old-origin
>   git remote add origin g...@salsa.debian.org:debian/gpp.git
>   git push -u origin --all
>   git push -u origin --tags
> 
> 
>  
> > Many thanks.
>  
> And many repositories need to be done.
> On thursday noon have I time for.
> 
> Having URLs to scripts (and their documention) to automate this
> would be a nice to have.
> 
> 
> The above in others words:
>  * seen the request
>  * willing to do the work
>  * made a start
>  * would like to the others automated
>  * will the next few days be travelling
>  . upon return will need to start search the scripts
>  * that is point where help is welcome
Several of such scripts exist and they should get used, especially the import
feature. 

for example: https://salsa.debian.org/mehdi/salsa-scripts
https://salsa.debian.org/satta/salsa-migration-tools
https://wiki.debian.org/Salsa/AliothMigration#Using_a_single_Python_script

Alex
 

Re: Move packages from alioth to salsa

[Alexander Wirt]

On Fri, 11 May 2018, Mattia Rizzolo wrote:

> On Fri, May 11, 2018 at 11:55:33AM +0200, Arturo Borrero Gonzalez wrote:
> > @Mattia, he seems to be looking for something similar to collab-main 
> > (Debian/?)
> 
> Right, key being *seems*, I'd rather not speculate :)
> Also, there are conceptual differences (in particular about
> collaboration that is now made clear) between collab-maint and the
> salsa's Debian group:
> https://wiki.debian.org/Salsa/Doc#Namespace_concepts_.28Users.2C_Teams.29
> https://lists.debian.org/debian-devel-announce/2017/12/msg3.html
> (stuff that you all should have read by now…)
Thats not a difference. It was just made clearer than before.

Alex



signature.asc
Description: PGP signature

Re: Membership of the debian-gis-team on Salsa (Was: salsa.debian.org (git.debian.org replacement) going into beta)

[Alexander Wirt]

On Mon, 07 May 2018, Martin Landa wrote:

> 2018-05-07 22:46 GMT+02:00 Martin Landa :
> >> May  7 20:28:08 godard/godard postfix/smtp[8573]: 04FB6A0693: 
> >> to=, 
> >> relay=mailly.debian.org[2001:41b8:202:deb:6564:a62:52c3:4b72]:587, 
> >> delay=1.8, delays=0.01/0/1.1/0.7, dsn=2.0.0, status=sent (250 OK 
> >> id=1fFmjw-0006RH-FL)
> 
> this I received:
> 
> Received: from salsa.debian.org (localhost [IPv6:::1]) by
> godard.debian.org (Postfix) with ESMTP id 04FB6A0693 for
> ; Mon,
>   7 May 2018 20:28:07 + (UTC)
> 
> ->
> 
> """
> 
> Hello, Martin Landa!
> 
> The password for your GitLab account on https://salsa.debian.org has
> successfully been changed.
> 
> If you did not initiate this change, please contact your administrator
> immediately.
> """
> 
> But I am still not able to login with new password which has been
> confirmed. I have tried several times with different passwords. Ma
then it should work, it does for everyone else - and you are sure you are
using the right username (martinl-guest) and the right password?

Alex
 

Re: Membership of the debian-gis-team on Salsa (Was: salsa.debian.org (git.debian.org replacement) going into beta)

[Alexander Wirt]

On Mon, 07 May 2018, Alexander Wirt wrote:

> On Mon, 07 May 2018, Martin Landa wrote:
> 
> > Hi,
> > 
> > 2018-05-07 7:21 GMT+02:00 Sebastiaan Couwenberg <sebas...@xs4all.nl>:
> > > You need to add your SSH key in your profile:
> > >
> > >  https://salsa.debian.org/profile/keys
> > 
> > unfortunately not able to login in. I tried several times to reset my
> > password, it seems not to work. I even got confirmation:
> > 
> > """
> > Hello, Martin Landa!
> > 
> > The password for your GitLab account on https://salsa.debian.org has
> > successfully been changed.
> > 
> > If you did not initiate this change, please contact your administrator
> > immediately.
> > """
> > 
> > But I am still not able to login in with the new password.  It's not
> > clear to me who is "my" administrator.
> operator here, you called me? Whats your username? 
Found it:

May  7 20:28:08 godard/godard postfix/smtp[8573]: 04FB6A0693: 
to=<landa.mar...@gmail.com>, 
relay=mailly.debian.org[2001:41b8:202:deb:6564:a62:52c3:4b72]:587, delay=1.8, 
delays=0.01/0/1.1/0.7, dsn=2.0.0, status=sent (250 OK id=1fFmjw-0006RH-FL)

Talk to your mail admin.

Alex
 

Re: Membership of the debian-gis-team on Salsa (Was: salsa.debian.org (git.debian.org replacement) going into beta)

[Alexander Wirt]

On Mon, 07 May 2018, Martin Landa wrote:

> Hi,
> 
> 2018-05-07 7:21 GMT+02:00 Sebastiaan Couwenberg :
> > You need to add your SSH key in your profile:
> >
> >  https://salsa.debian.org/profile/keys
> 
> unfortunately not able to login in. I tried several times to reset my
> password, it seems not to work. I even got confirmation:
> 
> """
> Hello, Martin Landa!
> 
> The password for your GitLab account on https://salsa.debian.org has
> successfully been changed.
> 
> If you did not initiate this change, please contact your administrator
> immediately.
> """
> 
> But I am still not able to login in with the new password.  It's not
> clear to me who is "my" administrator.
operator here, you called me? Whats your username? 

alex - salsa administrator
 

Re: Salsa Questions

[Alexander Wirt]

On Wed, 02 May 2018, Jörg Frings-Fürst wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hello,
> 
> some questions about salsa:
> 
> - - Becomes salsa the permissions as an open system like Alioth or does
> it stay so steady?
> 
> The background to the question is that at the moment I can not even
> draw attention to the one project that has already moved to Salsa
> because of "Permission denied (publickey)".
after some discussion on debian-devel, some questions from me:

a) why is this on -devel, I am pretty sure it is not listed as a support
channel for salsa 
b) what do you really mean with your question? 
c) about which project are you talking?
d) what exactly are you trying? 

Alex

Re: Salsa Questions

[Alexander Wirt]

On Wed, 02 May 2018, Jörg Frings-Fürst wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hello,
> 
> some questions about salsa:
> 
> - - Becomes salsa the permissions as an open system like Alioth or does
> it stay so steady?
eh? 
by default all web created projects are public. 

> 
> The background to the question is that at the moment I can not even
> draw attention to the one project that has already moved to Salsa
> because of "Permission denied (publickey)".
This is a bug by the admins of those project. 

Alex - impressed by the sound of those questions
 

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#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
 

Re: [alioth deprecation] Please remove your unused and/or migrated repositories

[Alexander Wirt]

On Sat, 28 Apr 2018, Holger Levsen wrote:

> On Fri, Apr 27, 2018 at 08:55:43AM +0200, Alexander Wirt wrote:
> > please remove your old, unused repos on alioth, so that we don't have to
> > archive them. 
> > 
> > For darcs, bzr and mecurial do this until 2018-05-09 for all other VCS until
> > 2018-05-16. 
> 
> does that mean git.debian.org starts becoming unusable (as a git server) on
> 2018-05-16?
> 
> (and sorry if this is obvious to you, it's not obvious to me...)
No, as announced in my timeline [1] that will happen later. 

But I will do a first rsync run during Hamburg, it helps when as much
obsolete data is gone at that time. 

Alex



signature.asc
Description: PGP signature

Re: Debian Med SVN and Git on Alioth removed (Was: [alioth deprecation] Please remove your unused and/or migrated repositories)

[Alexander Wirt]

On Fri, 27 Apr 2018, Andreas Tille wrote:

> Hi,
> 
> On Fri, Apr 27, 2018 at 08:55:43AM +0200, Alexander Wirt wrote:
> > please remove your old, unused repos on alioth, so that we don't have to
> > archive them. 
> 
> I've done so since I think there is nothing of any value remaining on
> Alioth.
> 
> However there are some remaining repositories in /git/debian-med where
> I'm lacking permissions.  The according users are quite inactive these
> days.  Alexander, feel free to clean up this dir completely.
Ok, will do. Thanks for the hint.

Alex

Re: [Alioth-staff-replacement] alioth deprecation - next steps

[Alexander Wirt]

On Fri, 27 Apr 2018, Mike Gabriel wrote:

> Hi,
> 
> On  Do 26 Apr 2018 10:52:41 CEST, Alexander Wirt wrote:
> 
> > On Thu, 26 Apr 2018, Andrej Shadura wrote:
> > 
> > > On 26 April 2018 at 10:21, Alexander Wirt <formo...@formorer.de> wrote:
> > > > On Thu, 26 Apr 2018, Andrej Shadura wrote:
> > > >
> > > >> On 17 April 2018 at 13:00, Alexander Wirt <formo...@debian.org> wrote:
> > > >> > Hi,
> > > >> >
> > > >> > as you should be aware, alioth.debian.org will be decommissioned with
> > > >> > the EOL of wheezy, which is at the end of May. The replacement for
> > > >> > the main part of alioth, git, is alive and out of beta, you know it
> > > >> > as salsa.debian.org. If you did not move your git repository yet,
> > > >> > hurry up, time is running out.
> > > >> >
> > > >> > The other important service from the alioth set, lists, moved to a
> > > >> > new host and is now live at https://alioth-lists.debian.net [1].
> > > >> > All public list archives moved over too and will continue to exist
> > > >> > under the old URL.
> > > >> >
> > > >> > ## decommissioning timeline
> > > >> >
> > > >> > 01.05.18:  DISABLE registration of new users on alioth. Until
> > > an improved SSO (GSOC Project, see [2]) is ready, new user
> > > registrations
> > > >> >needed for SSO services will be handled manually.
> > > More details on this will follow in a seperate announcement.
> > > >> > 10.-13.05.18: darcs, bzr and mercurial repositories will be
> > > exported as tarballs and made available readonly from a new archive
> > > host,
> > > >> >   details on that will follow.
> > > >> > 17.-20.05.18: During the Mini-DebConf Hamburg any existing cron
> > > jobs will be turned off, websites still on alioth will be disabled.
> > > >> > 31.05.18: All remaining repositories (cvs, svn and git) will be
> > > archived similar to the ones above.
> > > >> >   The host moszumanska, the home of alioth, will go offline!
> > > >>
> > > >> Could the steps including taking VCS repos offline be offset by at
> > > >> least two months? There are too many packages not yet migrated to
> > > >> Salsa or to Git in general, and completing that by the end of May is
> > > >> putting too much pressure on the maintainers.
> > > > Nope, we announced that months, if not years ago.
> > > 
> > > That doesn’t seem like a reasonable reply. What was announced is one
> > > thing, but the plans have to be adjusted to the reality, which is that
> > > you cannot switch off the VCS hosting by the end of May.
> 
> > It is. The plans were announced, I blocked the dates (I am even on vacation
> > for that) and the system is EOL with end of may. It will go down then.
> 
> Migrating Git repos from Alioth to Salsa is doable for most packaging teams
> in a day or two (the Javascript team migrated 1024 packages on one day)...
> 
> However, as one of the late bummers, I'd also love to have Vcs services
> available with read-only status for some more time. But, alas.
in fact they are read-only, just not directly usable. 

Alex



signature.asc
Description: PGP signature

Re: [alioth deprecation] Please remove your unused and/or migrated repositories

[Alexander Wirt]

On Fri, 27 Apr 2018, Arturo Borrero Gonzalez wrote:

> On 27 April 2018 at 11:07, Alexander Wirt <formo...@debian.org> wrote:
> > On Fri, 27 Apr 2018, Arturo Borrero Gonzalez wrote:
> >
> >> On 27 April 2018 at 08:55, Alexander Wirt <formo...@debian.org> wrote:
> >> > Hi,
> >> >
> >> > please remove your old, unused repos on alioth, so that we don't have to
> >> > archive them.
> >> >
> >> > For darcs, bzr and mecurial do this until 2018-05-09 for all other VCS 
> >> > until
> >> > 2018-05-16.
> >> >
> >>
> >> Hey!
> >>
> >> Could you please provide some hints of what buttons to press in order
> >> to delete the repos?
> > No buttons - and exact details depend on how you created the repo and the
> > type of repo. Just remove them from disk (rm).
> >
> 
> My first try was from the alioth web panel. I could only deselect the
> code repo plugin in the 'Tools' section.
> 
> If we should jump into a machine and `rm -rf` something, please share
> concrete details so we don't nuke something else by mistake :-P
> I'm not familiar with the alioth backstage, sorry for that.
Goodness. Depending on your vcs it is in /$vcs/$groupname/$reponame, you
know, the path you are usually pushing too. 

Alex

Re: [alioth deprecation] Please remove your unused and/or migrated repositories

[Alexander Wirt]

On Fri, 27 Apr 2018, Arturo Borrero Gonzalez wrote:

> On 27 April 2018 at 08:55, Alexander Wirt <formo...@debian.org> wrote:
> > Hi,
> >
> > please remove your old, unused repos on alioth, so that we don't have to
> > archive them.
> >
> > For darcs, bzr and mecurial do this until 2018-05-09 for all other VCS until
> > 2018-05-16.
> >
> 
> Hey!
> 
> Could you please provide some hints of what buttons to press in order
> to delete the repos?
No buttons - and exact details depend on how you created the repo and the
type of repo. Just remove them from disk (rm). 

Alex
 

Re: [icinga-users] Host dependency for icinga agent hosts

[Alexander Wirt]

On Thu, 26 Apr 2018, Florian Lohoff wrote:

> On Thu, Apr 26, 2018 at 02:02:34PM +0200, Alexander Wirt wrote:
> > > Okay - Waiting for debmon then ...
> > There won't be any further updates from my side, some company killed all my
> > motivation and none of them is still working on debmon, regardless that they
> > can if they want.
> 
> Sad to hear - it was my source for following icinga2 development more
> closely than a new release every 2 years by debian.
> 
> Thanks for doing the work so far ... It was a pleasure.
Thanks for your kind words, I also had other plans for the service. But
sometimes things evolve in a different direction than expected.

Alex



signature.asc
Description: PGP signature
___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

Re: [Alioth-staff-replacement] alioth deprecation - next steps

[Alexander Wirt]

On Thu, 26 Apr 2018, Andrej Shadura wrote:

> On 26 April 2018 at 10:21, Alexander Wirt <formo...@formorer.de> wrote:
> > On Thu, 26 Apr 2018, Andrej Shadura wrote:
> >
> >> On 17 April 2018 at 13:00, Alexander Wirt <formo...@debian.org> wrote:
> >> > Hi,
> >> >
> >> > as you should be aware, alioth.debian.org will be decommissioned with
> >> > the EOL of wheezy, which is at the end of May. The replacement for
> >> > the main part of alioth, git, is alive and out of beta, you know it
> >> > as salsa.debian.org. If you did not move your git repository yet,
> >> > hurry up, time is running out.
> >> >
> >> > The other important service from the alioth set, lists, moved to a
> >> > new host and is now live at https://alioth-lists.debian.net [1].
> >> > All public list archives moved over too and will continue to exist
> >> > under the old URL.
> >> >
> >> > ## decommissioning timeline
> >> >
> >> > 01.05.18:  DISABLE registration of new users on alioth. Until an 
> >> > improved SSO (GSOC Project, see [2]) is ready, new user registrations
> >> >needed for SSO services will be handled manually. More 
> >> > details on this will follow in a seperate announcement.
> >> > 10.-13.05.18: darcs, bzr and mercurial repositories will be exported as 
> >> > tarballs and made available readonly from a new archive host,
> >> >   details on that will follow.
> >> > 17.-20.05.18: During the Mini-DebConf Hamburg any existing cron jobs 
> >> > will be turned off, websites still on alioth will be disabled.
> >> > 31.05.18: All remaining repositories (cvs, svn and git) will be archived 
> >> > similar to the ones above.
> >> >   The host moszumanska, the home of alioth, will go offline!
> >>
> >> Could the steps including taking VCS repos offline be offset by at
> >> least two months? There are too many packages not yet migrated to
> >> Salsa or to Git in general, and completing that by the end of May is
> >> putting too much pressure on the maintainers.
> > Nope, we announced that months, if not years ago.
> 
> That doesn’t seem like a reasonable reply. What was announced is one
> thing, but the plans have to be adjusted to the reality, which is that
> you cannot switch off the VCS hosting by the end of May.
It is. The plans were announced, I blocked the dates (I am even on vacation
for that) and the system is EOL with end of may. It will go down then. 

Alex

Re: [Alioth-staff-replacement] alioth deprecation - next steps

[Alexander Wirt]

On Thu, 26 Apr 2018, Andrej Shadura wrote:

> On 17 April 2018 at 13:00, Alexander Wirt <formo...@debian.org> wrote:
> > Hi,
> >
> > as you should be aware, alioth.debian.org will be decommissioned with
> > the EOL of wheezy, which is at the end of May. The replacement for
> > the main part of alioth, git, is alive and out of beta, you know it
> > as salsa.debian.org. If you did not move your git repository yet,
> > hurry up, time is running out.
> >
> > The other important service from the alioth set, lists, moved to a
> > new host and is now live at https://alioth-lists.debian.net [1].
> > All public list archives moved over too and will continue to exist
> > under the old URL.
> >
> > ## decommissioning timeline
> >
> > 01.05.18:  DISABLE registration of new users on alioth. Until an improved 
> > SSO (GSOC Project, see [2]) is ready, new user registrations
> >needed for SSO services will be handled manually. More details 
> > on this will follow in a seperate announcement.
> > 10.-13.05.18: darcs, bzr and mercurial repositories will be exported as 
> > tarballs and made available readonly from a new archive host,
> >   details on that will follow.
> > 17.-20.05.18: During the Mini-DebConf Hamburg any existing cron jobs will 
> > be turned off, websites still on alioth will be disabled.
> > 31.05.18: All remaining repositories (cvs, svn and git) will be archived 
> > similar to the ones above.
> >   The host moszumanska, the home of alioth, will go offline!
> 
> Could the steps including taking VCS repos offline be offset by at
> least two months? There are too many packages not yet migrated to
> Salsa or to Git in general, and completing that by the end of May is
> putting too much pressure on the maintainers.
Nope, we announced that months, if not years ago.

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#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
 

Re: Completed: lists.alioth.debian.org migration

[Alexander Wirt]

On Fri, 20 Apr 2018, Adam Borowski wrote:

> On Fri, Apr 20, 2018 at 09:24:48AM +0200, Raphael Hertzog wrote:
> > On Fri, 20 Apr 2018, Christoph Biedl wrote:
> > > On the other hand I fully agree doing dozens or hundreds of uploads just
> > > because an address out of my control became invalid is a huge waste of
> > > ressources that are better spent elsewhere. However, that's why
> > > alioth-lists was created.
> > 
> > We have switched to a common mailing list on lists.debian.org:
> > https://lists.debian.org/debian-security-tools/
> > 
> > But this list should not get bug reports and usual package maintainance
> > mail. It's a discussion list between team members.
> 
> A lot of other teams are in this situation.  And no one seems to know what
> are we supposed to do.  So the results are quite... random.
> 
> For example, on my packages:
> 4 have Debian Fonts Task Force 
> 1 has Debian Desktop Theme Team 
> 2 (in NEW) have debian-fo...@lists.debian.org
> 
> The first four are traditional, and just became buggy as that list has been
> migrated to l.d.o rather than not-yet-then-announced alioth-lists (which is,
> as I understand, only a temporary measure).  I need to fix those.
> 
> The next one, has only the human name matching, with some crap as e-mail. 
> Most tools match by the latter, thus this scheme doesn't seem to work.  I'll
> change it as soon as anyone tells me _what_ to switch to.
> 
> The last two have a good working maintainer address, but violate the rules
> for l.d.o lists (as you say, these shouldn't get maintainership mails).
That "requirement" doesn't exist. What we said is: we don't want
maintainership **only** lists. If you have a combined discussion and
maintainership mail list thats fine. 

Alex - Debian Listmaster
 

Re: alioth deprecation - next steps

[Alexander Wirt]

On Wed, 18 Apr 2018, Alexander Wirt wrote:

> On Tue, 17 Apr 2018, Bill Allombert wrote:
> 
> > On Tue, Apr 17, 2018 at 10:31:58PM +0100, James Clarke wrote:
> > > Even the wiki page you linked there states that GitLab "allows extra
> > > files to be attached to the tag".
> > 
> > But it does not say how.
> > Research shows that while gitlab has plan to implement the feature, it is
> > not actually implemented yet.
> https://salsa.debian.org/formorer/testrepo/tags/0.1
> you can btw. just add a release not and attach files to that release note. 
If bored you can even automate that:

# curl --header "PRIVATE-TOKEN: $TOKEN" -q -X POST --form 
"file=@/tmp/stupidfile2" 
'https://salsa.debian.org/api/v4/projects/formorer%2Ftestrepo/uploads' 
2>/dev/null | jq '.'
   
{
  "alt": "stupidfile2",
  "url": "/uploads/eed5461d41fbce6b2b865eaf5a201290/stupidfile2",
  "markdown": 
"[stupidfile2](/uploads/eed5461d41fbce6b2b865eaf5a201290/stupidfile2)"
}

# curl --header "PRIVATE-TOKEN: $TOKEN" -q -X POST -F "tag_name=2.0" -F 
'description=* 
[stupidfile2](/uploads/eed5461d41fbce6b2b865eaf5a201290/stupidfile2)' 
'https://salsa.debian.org/api/v4/projects/formorer%2Ftestrepo/repository/tags/2.0/release'

 {"tag_name":"2.0","description":"* 
[stupidfile2](/uploads/eed5461d41fbce6b2b865eaf5a201290/stupidfile2)"}%

which results in: 

https://salsa.debian.org/formorer/testrepo/tags 

Re: alioth deprecation - next steps

[Alexander Wirt]

On Tue, 17 Apr 2018, Bill Allombert wrote:

> On Tue, Apr 17, 2018 at 10:31:58PM +0100, James Clarke wrote:
> > Even the wiki page you linked there states that GitLab "allows extra
> > files to be attached to the tag".
> 
> But it does not say how.
> Research shows that while gitlab has plan to implement the feature, it is
> not actually implemented yet.
https://salsa.debian.org/formorer/testrepo/tags/0.1
you can btw. just add a release not and attach files to that release note. 

Alex
 

Re: alioth deprecation - next steps

[Alexander Wirt]

On Tue, 17 Apr 2018, Bill Allombert wrote:

> On Tue, Apr 17, 2018 at 11:10:56PM +0200, Alexander Wirt wrote:
> > On Tue, 17 Apr 2018, Bill Allombert wrote:
> > 
> > > On Tue, Apr 17, 2018 at 01:00:56PM +0200, Alexander Wirt wrote:
> > > > Hi,
> > > > 
> > > > as you should be aware, alioth.debian.org will be decommissioned with
> > > > the EOL of wheezy, which is at the end of May. The replacement for
> > > > the main part of alioth, git, is alive and out of beta, you know it
> > > > as salsa.debian.org. If you did not move your git repository yet,
> > > > hurry up, time is running out.
> > > > 
> > > > The other important service from the alioth set, lists, moved to a
> > > > new host and is now live at https://alioth-lists.debian.net [1].
> > > > All public list archives moved over too and will continue to exist
> > > > under the old URL.
> > > 
> > > What about the most basic service, the download page ?
> > > (like <https://alioth.debian.org/frs/?group_id=101016>)
> > > 
> > > According to 
> > > <https://wiki.debian.org/Alioth#Deprecation_of_Alioth>
> > > there is no equivalent on salsa.
> > > 
> > > git tags are not a suitable alternative because true release tarballs
> > > include files generated by autotools (among others) that are not in
> > > git, and git tags tarballs are not signed (signed tags is an different
> > > concept).
> > > 
> > > This unfortunately makes salsa unsuitable as a project homepage.
> > Create a gitlab-ci job, build your files and provide them under a gitlab
> > page. So you are wrong, salsa can work as it. 
> 
> This is a very convoluted and resource-heavy process, and this does not
> solve the signature problem (a gitlab-ci job cannot create the signature
> file without the private key).
> 
> I do not think this is a solution.
You are the first one in two years mentioning this "needed" service. It can't
be that important than and it least for me its too late now. But feel free to
step in and provide a replacement. 

Alex

Re: alioth deprecation - next steps

[Alexander Wirt]

On Tue, 17 Apr 2018, Bill Allombert wrote:

> On Tue, Apr 17, 2018 at 01:00:56PM +0200, Alexander Wirt wrote:
> > Hi,
> > 
> > as you should be aware, alioth.debian.org will be decommissioned with
> > the EOL of wheezy, which is at the end of May. The replacement for
> > the main part of alioth, git, is alive and out of beta, you know it
> > as salsa.debian.org. If you did not move your git repository yet,
> > hurry up, time is running out.
> > 
> > The other important service from the alioth set, lists, moved to a
> > new host and is now live at https://alioth-lists.debian.net [1].
> > All public list archives moved over too and will continue to exist
> > under the old URL.
> 
> What about the most basic service, the download page ?
> (like <https://alioth.debian.org/frs/?group_id=101016>)
> 
> According to 
> <https://wiki.debian.org/Alioth#Deprecation_of_Alioth>
> there is no equivalent on salsa.
> 
> git tags are not a suitable alternative because true release tarballs
> include files generated by autotools (among others) that are not in
> git, and git tags tarballs are not signed (signed tags is an different
> concept).
> 
> This unfortunately makes salsa unsuitable as a project homepage.
Create a gitlab-ci job, build your files and provide them under a gitlab
page. So you are wrong, salsa can work as it. 

Alex
 

Re: alioth deprecation - next steps

[Alexander Wirt]

On Tue, 17 Apr 2018, Holger Levsen wrote:

Hi Holger, 

> Alexander, thanks for the update on the alioth migration!
> 
> On Tue, Apr 17, 2018 at 01:00:56PM +0200, Alexander Wirt wrote:
> > 17.-20.05.18: During the Mini-DebConf Hamburg any existing cron jobs will 
> > be turned off, websites still on alioth will be disabled.
> 
> we currently use https://reproducible.alioth.debian.org/blog/ and this
> address has been spread wide and far. Do you think it would be possible
> to redirect reproducible.alioth.debian.org on the DNS level to say,
> blog.reproducible-builds.org?
This is probably possible by talking to DSA. 

Alex



signature.asc
Description: PGP signature

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

Re: Receiving emails from the debian-outreach list

[Alexander Wirt]

On Wed, 04 Apr 2018, Thomas Levine wrote:

> A diligent applicant has made me aware that I am not receiving emails
> sent to debian-outreach, and I have not managed to find a support avenue
> for the Debian mailing lists. Can someone check my registration on the
> mailing list to see what might be wrong?
listmaster@l.d.o 

you are not subscribed to any list: 
1 formorer@bendel ~ % checklists thomaslevine.com
1 formorer@bendel ~ %
> 
> As the present email demonstrates, I can send emails for distribution
> to the list.
Sending has nothing to do with receiving. 

Alex
 

Re: Fwd: [Ticket#2018033089000104] Ticket Created: [SECURITY] [DLA 1332-1] libvncserver security update

[Alexander Wirt]

On Sat, 31 Mar 2018, Abhijith PA wrote:

> Hello.  
> I received this mail after sending DLA.  Is it something set up by our 
> sponsors ?  Or spam.
Such autoresponders are not allowed on l.d.o. I unsubscribed the user from
all lists. 

Alex - Debian Listmaster

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
 

Re: managing mentors email lists

[Alexander Wirt]

On Fri, 30 Mar 2018, Balram Pariyarath wrote:

> is it advisable to create a slack team for Debian Mentors so that we can
> have all conversions regarding our activities there. It'll also serve as a
> asynchronous channel so that if somebody cannot make it at right time, they
> can check back things later. We could maintain a separate channel for
> announcements and different projects so that everything is sorted and
> clear.
You mean an IRC channel. We don't use slack. 

Alex

Re: GSoC proposal on wiki page?

[Alexander Wirt]

On Tue, 27 Mar 2018, Raden Muaz wrote:

> Hi. I have uploaded my proposal on GSoC dashboard page.
> Do I also need to create debian wiki page showing the same proposal?
No thats not needed anymore, having the proposal in the GSoC frontend is
enough.

Alex - GSOC Admin

Re: feedback on calendar database of social event and conferences proposal

[Alexander Wirt]

On Tue, 27 Mar 2018, Doğukan ÇELİK wrote:

> Hi,
> 
>  
> 
> I just upload my drafts to gsoc dashboard. Is that possible to having
> feedback for this proposal too ?
> 
>  
> 
> http://web.itu.edu.tr/celikd/gsoc/proposal-calendar.pdf
jftr, this project doesn't have a mentor and will probably not happen.

Alex
 

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Alexander Wirt]

On Sat, 24 Mar 2018, Ole Streicher wrote:

> Joerg Jaspert  writes:
> > packages.d.o/packagename and you are there. Nothing else needed.
> 
> packages.d.o does not provide a canonical URL for the repository.
> 
> It is even more difficult: I have first to select the package name, then
> select the distribution, go to the tracker.d.o, and select one of the
> VCS links.
> 
> Also tracker.d.o does not have a canonical URL for this (which would IMO
> be a more natural place): I can't just do a 
> 
> git clone https://tracker.debian.org/<>/vcs
> 
> or put
> 
> Vcs-Browser: https://tracker.debian.org/<>
> 
> into d/control (and be safe against future changes of the location).
> 
> > Even independent of the underlying vcs, not hardcoded to git or one
> > provider of hosting it.
> 
> Given the fact that nobody strongly questioned the limitation of
> salsa.d.o to git (and therefore the requirement to migrate from other
> VCSs), I would have no objection against git.d.o -- if using
> programmatically (f.e. via Python) you anyway rely on the specific VCS
> API.
Unfortunately that will never work properly for git:// or ssh+git://

Alex
 

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Alexander Wirt]

On Thu, 22 Mar 2018, Andreas Tille wrote:

> On Thu, Mar 22, 2018 at 12:56:30PM +0100, Alexander Wirt wrote:
> > > 
> > > On the other hand the current timing does not allow for a probably
> > > complex implementation and a http redirect which is even implemented[2]
> > > can help to relax the situation we are currently facing.  I admit I
> > > expected the kind of response since it seems related but my posting was
> > > targetting to help for the next couple of monthes and not for discussing
> > > something that will hopefully implemented in the next couple of years.  
> > This was not was you were asking for. The temporary workaround is there (the
> > redirector), but that doesn't mean your vcs entries are right. The lintian
> > check is right.
> 
> Or rather lintian reflects the current status that was forced by the
> Alioth to Salsa migration.  May be somebody can explain me in very
> simple words why we can not point anonscm.d.o to salsa.d.o once Alioth
> is shut down.
Because it wouldn't work. URLs wouldn't magically work and on the other hand
the redirector will just stop working. 

Alex 

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Alexander Wirt]

On Thu, 22 Mar 2018, Andreas Tille wrote:

> Hi Lars,
> 
> On Thu, Mar 22, 2018 at 12:47:44PM +0200, Lars Wirzenius wrote:
> > On Thu, 2018-03-22 at 09:58 +0100, Andreas Tille wrote:
> > > I admit I do not agree with this and it was discussed here before.  Can
> > > we please agree that anonscm.debian.org remains a valid URL and stop
> > > starting another round of package uploads for the sake of changing Vcs
> > > fields.
> > 
> > I'm repeating myself, but could we please find another way to store
> > this information than in the source package?
> 
> I agree (and others did as well)
> 
> > I'd like to see all of
> > the following stored somewhere else than the source package:
> > 
> > * Maintainer, Uploaders
> > * Vcs-*
> > * Homepage
> > * debian/watch
> 
>  * debian/upstream/*
>(see Wiki[1])
>  
> > Possibly also Section and Priority.
> > 
> > All of the above can change and it's silly to have to make a source
> > upload to change them. They also easily get out of date and so are
> > likely out of date for a stable release.
> > 
> > I envision a service, metadata.debian.org, with a suitable
> > authenticated API to allow Debian package maintainers to update the
> > information, and having tracker.debian.org, dak, and other parties
> > fetch the data from metadata service, for inclusion in, say, Packages
> > files.
> 
> I think there is some general agreement about this.
> 
> > I think this would be a better thing to spend time on than talking
> > again about keeping anonscm around.
> 
> On the other hand the current timing does not allow for a probably
> complex implementation and a http redirect which is even implemented[2]
> can help to relax the situation we are currently facing.  I admit I
> expected the kind of response since it seems related but my posting was
> targetting to help for the next couple of monthes and not for discussing
> something that will hopefully implemented in the next couple of years.  
This was not was you were asking for. The temporary workaround is there (the
redirector), but that doesn't mean your vcs entries are right. The lintian
check is right. We expect you to fix those entries with the next upload and
thats where the check is coming in. And by the way: I implemented the
redirector especially for you.

Alex

P.S. There will be a longer answer from someone of the alioth team, I am just
too tired to explain that all again. 

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

[Alexander Wirt]

On Thu, 22 Mar 2018, Andreas Tille wrote:

> Hi,
> 
> today I realised the lintian warning:
> 
> W: libbpp-core source: vcs-deprecated-in-debian-infrastructure vcs-git 
> https://anonscm.debian.org/git/debian-med/libbpp-core.git
> N: 
> N:The specified Vcs-* field points to an area within the *.debian.org
> N:infrastructure but refers to a version control system that has been
> N:deprecated.
> N:
> N:After 1st May 2018, Debian will not offer hosting for any version
> N:control system other than Git and the Alioth service will become
> N:read-only in May 2018. Packages should migrate to Git hosting on
> N:
> N:For further information about salsa.debian.org, including how to add
> N:HTTP redirects from alioth, please consult the Debian Wiki.
> N:
> N:Refer to
> N:https://lists.debian.org/debian-devel-announce/2017/08/msg8.html and
> N:https://wiki.debian.org/Salsa for details.
> N:
> N:Severity: normal, Certainty: certain
> N:
> N:Check: fields, Type: binary, udeb, source
> N: 
> 
> 
> I admit I do not agree with this and it was discussed here before.  Can
> we please agree that anonscm.debian.org remains a valid URL and stop
> starting another round of package uploads for the sake of changing Vcs
> fields.
> 
> I could live with severity of "pedantic" for the lintian issue, thought.
> However, I have not seen any argument why anonscm.d.o can not survive
> the shutdown of Alioth and remain what it was when it was invented: A
> generic Vcs URL for Debian packages no matter on what hostname the
> packages really reside.
That was announced several times and it will not reside. 

Alex
 

Re: Tools for communication, coordination and project management

[Alexander Wirt]

On Mon, 19 Mar 2018, Daniel Pocock wrote:

> 
> 
> On 10/03/18 07:37, Alexander Wirt wrote:
> > On Sat, 10 Mar 2018, Dashamir Hoxha wrote:
> > 
> >> On Thu, Mar 8, 2018 at 4:38 AM, Jaminy Prabaharan <jamin...@gmail.com>
> >> wrote:
> >>
> >>>
> >>> Seperate GitHub for debian-gsoc looks like better idea for the project
> >>> management.
> >>>
> >>
> >> I have created an organization on GitHub: https://github.com/debian-gsoc
> >>>
> >>> If someone would like to give it a try, please send me your GitHub
> >> username, so that I can invite you.
> > don't call it debian. 
> > 
> 
> 
> I met with Dashamir in Tirana and had a brief look at what he tried to
> do with Github.
> 
> He has put a lot of time and thought into this and while it is not what
> many mentors want to use, I feel that it is also really important in an
> outreach program to assume that many of the people coming into the
> program, which may include both students and mentors, have exposure to a
> wide range of tools and may consider upgrading to things that are more free.
> 
> This thread is one of the reasons I created the wiki page mentioned in
> another thread, but I feel it can also provide some closure for this
> thread and help in future rounds:
> 
> https://wiki.debian.org/Teams/Outreach/Tools
That doesn't change anything about that thing not being "Debian". 

Alex
 

Re: Is there any policy for user accounts doing automatic updates on Salsa

[Alexander Wirt]

On Sun, 11 Mar 2018, Andreas Tille wrote:

> Hi,
> 
> I had the idea to create a repository inside the r-pkg group which
> should receive automatic updates (created from an UDD query).  My idea
> was to create some dedicated account that gets commit permissions to
> this project.  I'd like to use this dedicated account since I want to
> run this job on some remote server where I do not really like to drop
> my SALSA_TOKEN.
> 
> Is there any specific policy for such accounts and what do you think
> about the idea in general.
In short: don't do this and use deploy keys. 

Thanks
Alex
 

Re: Tools for communication, coordination and project management

[Alexander Wirt]

On Sat, 10 Mar 2018, Dashamir Hoxha wrote:

> On Thu, Mar 8, 2018 at 4:38 AM, Jaminy Prabaharan 
> wrote:
> 
> >
> > Seperate GitHub for debian-gsoc looks like better idea for the project
> > management.
> >
> 
> I have created an organization on GitHub: https://github.com/debian-gsoc
> >
> > If someone would like to give it a try, please send me your GitHub
> username, so that I can invite you.
don't call it debian. 

Alex

Re: [icinga-users] Need you help

[Alexander Wirt]

On Fri, 09 Mar 2018, kanny goud wrote:

> Can you tell me ..Is there any tool for direct migration
Nope.

Alex

___
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users

Re: Tools for communication, coordination and project management

[Alexander Wirt]

On Thu, 08 Mar 2018, Dashamir Hoxha wrote:

> On Thu, Mar 8, 2018 at 7:19 AM, Alexander Wirt <formo...@formorer.de> wrote:
> 
> > On Thu, 08 Mar 2018, Jaminy Prabaharan wrote:
> >
> > > We could request all mentors to manage their projects there.
> > I will step done as admin if we will start to use github as official
> > solution.
> >
> > And I will probably also reject my gsoc proposal in that case.
> >
> 
> I don't know what an "official solution" is, but of course I would not
> support
> an official solution if it may upset somebody.
> 
> We may suggest the mentors to manage their projects on GitHub, if they wish,
> instead of requesting them to do so.
you should not even suggest it. We should suggest an open source solution,
preferably one we run on our own infra.

Alex

Re: Tools for communication, coordination and project management

[Alexander Wirt]

On Thu, 08 Mar 2018, Jaminy Prabaharan wrote:

> Hi,
> 
> Seperate GitHub for debian-gsoc looks like better idea for the project
> management.
> 
> We could request all mentors to manage their projects there.
I will step done as admin if we will start to use github as official
solution. 

And I will probably also reject my gsoc proposal in that case.

Alex

[Python-modules-team] androguard_3.1.0~rc2-1~bpo8+1_amd64.changes REJECTED

[Alexander Wirt]

That version is not in stable. Source for old-stable backports is always stable.
Otherwise you are looking for -sloppy



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: A proposal for improving transparency of the FTP NEW process

[Alexander Wirt]

On Sun, 04 Mar 2018, Thomas Goirand wrote:

> On 03/02/2018 01:00 PM, Gert Wollny wrote:
> > Since ftp-master also sometimes sends messages like "I let it pass for
> > now, but please fix it with the next upload", using the package issue
> > tracker would also be a way to keep track of these minor issues.
> 
> For this, we have the BTS. If the issue is RC, it will prevent shit from
> migrating. Salsa's issue tracker doesn't have this feature.
> 
> Also, I would really have preferred if Salsa's issue tracker feature was
> simply removed/desactivated, because every other day, there's someone
> proposing to replace debbug with it. Thanks but no thanks. One place is
> enough to look into. If you wish to write somewhere, the ITP bug is the
> correct place to go.
Every project/group can disable it at will. But it makes sense for some
things (like the salsa support tracker). So the answer is no for global
disabling it. 

Alex

Re: salsa SSH fingerprint

[Alexander Wirt]

On Wed, 28 Feb 2018, Alberto Luaces wrote:

> Hello,
> 
> I am unable to find a place where the SSH fingerprint of salsa is shown.
> I want to compare it with the one displayed when I try to push some
> changes.
Just for the record weasel (thanks weasel!) implemented sshfp records [1] for 
salsa. If you use a
validating resolver tell your ssh to use them to get validation
(VerifyHostKeyDNS). 

Alex

[1]  host -t SSHFP salsa.debian.org
salsa.debian.org has SSHFP record 4 1 676B02929DC7908278BCEE876EA0F1640B8264E0
salsa.debian.org has SSHFP record 1 2 
F3C03414B13A6DF37A3296B81774EC3E28D92E7C003667CA8E17D884 33820A70
salsa.debian.org has SSHFP record 4 2 
3800F7A464B070E0C8B61C45FB3211BCF4D9F1408901823BE44E365C 37C6AFCE
salsa.debian.org has SSHFP record 1 1 EAA6C147FACF35BC49946D9E8B90E2235C7DA361
 


signature.asc
Description: PGP signature

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
 

Re: Spam targeting nnn-done@bugs.d.o

[Alexander Wirt]

On Sun, 25 Feb 2018, Sebastian Andrzej Siewior wrote:

> On 2018-02-21 10:53:49 [-0800], Don Armstrong wrote:
> > We basically already do this with our ZIPFILE, MSWORD, and ZIPCOMPRESSED
> > rules:
> > 
> > https://salsa.debian.org/debbugs-team/antispam/spamassassin_config/blob/master/common/virus_spam#L115
> > 
> > Speaking on behalf of owner@, we're always looking more assistance in
> > creating better SA rules. Our configuration is publicly available.[1]
> > [I've just started moving it from alioth to salsa, so the git urls will
> > change slightly.]
> 
> I get here a 404 after it asked me to login. Is it restricted to the
> debbugs-team? I see debbugs and bugscan, no antispam.
> Would it work to rescrict the done/close-@ even more? Like to pgp-signed
> messages only? I'm not asking for a valid DD signatures or so - just any
> signature will do.
The repo moved to 
https://salsa.debian.org/debian-listmasters/spamassassin_config

Alex
 

Re: Raising the problem of Debian Single Sign On + Alioth (again)

[Alexander Wirt]

On Sun, 25 Feb 2018, Paul Wise wrote:

> On Sun, Feb 25, 2018 at 2:46 AM, Alexander Wirt wrote:
> 
> > I do really hope that we can have a good backend for guestuser and dm
> > authorisation and authentiction at the end of the summer. Something like
> > ud-ldap that can serve us for the next years.
> 
> Will this mean that the guest users in db.d.o will move elsewhere?
For me guest user are the users named -guest. ud-ldap wise they are guest
accounts in the ud-ldap. Therefore I don't think anything will change (unless
DSA thinks it would be a good idea to use the new backend).

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

Re: Raising the problem of Debian Single Sign On + Alioth (again)

[Alexander Wirt]

On Fri, 23 Feb 2018, Enrico Zini wrote:

Hi Enrico,

> > > Are there other ways in stretch of getting apache to authenticate
> > > against gitlab?
> > I would wait for the gsoc project. And on the alioth sprint, several people
> > decided against using salsa as backend for sso, but the other way round. 
> > So please don't.
> 
> Please do not switch Alioth off, nor disable creation of new accounts on
> alioth, until then. Being able to get a SSO certificate as a non-DD is
> currently a required step to become a DD.
Please don't get me wrong, that decision was a team decision done at the
spring (and I didn't even voted for it) - however I stand behind such team
decisions and follow them like they are my own. 

I think I owe you some reasoning. It was decided that relying again on a
service wouldn't be the best idea if the would have to move to some other
solution - the whole fun would start again. We also took into account that
the may be another implementation of a git service. We decided that the best
solution would be another new, authorative backend for guest users and dms,
that can work independently of the service. 

However, I hoped that someone else would take care about that new hypothetic
service/backend. Appearently that wasn't the case, until yesterday noone
expressed interest in *doing* the work. Therefore I decided that I should
take care about it and started the gsoc project (I even applied as admin to
ensure it will really happen). I also invited you to take part in the project
- the response wasn't very enthusiastic. 

I do really hope that we can have a good backend for guestuser and dm
authorisation and authentiction at the end of the summer. Something like
ud-ldap that can serve us for the next years. 

I still hope that you will join us in that mission. 

Alex


signature.asc
Description: PGP signature

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

Re: Status Debian Single Sign On + Alioth replacements

[Alexander Wirt]

On Fri, 23 Feb 2018, Geert Stappers wrote:

> On Fri, Feb 23, 2018 at 09:44:16PM +0100, Alexander Wirt wrote:
> > On Fri, 23 Feb 2018, Geert Stappers wrote:
> > > El 23/02/18 a las 20:51, Laura Arjona Reina escribió:
> > > > El 23/02/18 a las 19:42, Geert Stappers escribió:
> > > > > I went to Debian wiki, searched for 'SSO'
> > > > > and got https://wiki.debian.org/Salsa/SSO
> > > > >
> > > > > Would that be the proper place to track status of Debian Single Sign 
> > > > > On?
> > > > 
> > > > I've just created https://wiki.debian.org/SSO
> > > > redirecting to https://wiki.debian.org/DebianSingleSignOn
> > > > 
> > > 
> > > Thanks. Updated 
> > >  ( info at  
> > > https://wiki.debian.org/Services/DebianSingleSignOn?action=diff=8=7
> > >  )
> > 
> > sso isn't a task of alioth. Syncing the user database to sso ldap is, sso
> > will continue working after alioth is gone. Maybe just without guest users. 
> >  
> 
> New text
>  ( 
> https://wiki.debian.org/Services/DebianSingleSignOn?action=diff=10=9
>  )
> Server ''Alioth'' had several tasks,
> including providing a place where new users can create an account.
> Those Alioth -guest account where sync to the SSO server.
> Alioth tasks went to various servers.
> The New Maintainer process leans on the incoming -guest accounts.
> There needs be a ''service'' that can ''feed'' SSO with new accounts.
yes, thanks a lot. 

Alex
 

Re: Status Debian Single Sign On + Alioth replacements

[Alexander Wirt]

On Fri, 23 Feb 2018, Geert Stappers wrote:

> On Fri, Feb 23, 2018 at 08:53:59PM +0100, Laura Arjona Reina wrote:
> > El 23/02/18 a las 20:51, Laura Arjona Reina escribió:
> > > El 23/02/18 a las 19:42, Geert Stappers escribió:
> > > 
> > >>
> > >> I went to Debian wiki, searched for 'SSO'
> > >> and got https://wiki.debian.org/Salsa/SSO
> > >>
> > >> Would that be the proper place to track status of Debian Single Sign On?
> > >>
> > > 
> > > The page is https://wiki.debian.org/DebianSingleSignOn
> > > I've just redirected https://wiki.debian.org/SSO redirecting to there.
> > 
> > I wanted to say: I've just created https://wiki.debian.org/SSO
> > redirecting to https://wiki.debian.org/DebianSingleSignOn
> > 
> 
> Thanks. Updated 
>  ( info at  
> https://wiki.debian.org/Services/DebianSingleSignOn?action=diff=8=7 
> )
sso isn't a task of alioth. Syncing the user database to sso ldap is, sso
will continue working after alioth is gone. Maybe just without guest users.  

Alex
 

Re: Raising the problem of Debian Single Sign On + Alioth (again)

[Alexander Wirt]

On Fri, 23 Feb 2018, Jonathan McDowell wrote:

> On Fri, Feb 23, 2018 at 06:54:29PM +0100, Alexander Wirt wrote:
> > On Fri, 23 Feb 2018, Enrico Zini wrote:
> > > On Fri, Feb 23, 2018 at 03:49:06PM +0100, Alexander Wirt wrote:
> > > > > Are there other ways in stretch of getting apache to
> > > > > authenticate against gitlab?
> > > > I would wait for the gsoc project. And on the alioth sprint,
> > > > several people decided against using salsa as backend for sso, but
> > > > the other way round.  So please don't.
> > > 
> > > Please do not switch Alioth off, nor disable creation of new
> > > accounts on alioth, until then. Being able to get a SSO certificate
> > > as a non-DD is currently a required step to become a DD.
> 
> > Then the dd process should get fixed, not making again something to a
> > backend which isn't meaned like that (we had the same problem with
> > alioth and debconf).
> 
> Like it or not Alioth provides more services than just hosting
> repositories. One of these is authentication. Enrico has made a
> concerted effort to work out how Salsa can be used in a similar manner
> as Alioth to provide that authentication behaviour, with as little
> effort on the part of all concerned as possible, and your response is
> that you don't want Salsa to be used for that.
> 
> This is absolutely the Salsa team's choice to make, but you have to
> accept that as a result once Alioth is turned off there will be no way
> for prospective DMs or DDs to authenticate to nm.debian.org.
thats nonsense. alioth clearly showed that in the past, noone knows that
better than me. Because we would have to support it. 

> The attitude of "well nothing to do with us, the NM team should sort it
> out" is not appreciated.
Thats nonsense, I am working on an sso replacement for some time, since
nobody stepped in when we asked for it. 

Alex



signature.asc
Description: PGP signature

Re: Status Debian Single Sign On + Alioth replacements

[Alexander Wirt]

On Fri, 23 Feb 2018, Geert Stappers wrote:

> On Fri, Feb 23, 2018 at 07:32:24PM +0100, Alexander Wirt wrote:
> > On Fri, 23 Feb 2018, Geert Stappers wrote:
> > > On Fri, Feb 23, 2018 at 06:54:29PM +0100, Alexander Wirt wrote:
> > > > On Fri, 23 Feb 2018, Enrico Zini wrote:
> > > > > Please do not switch Alioth off, nor disable creation of new accounts 
> > > > > on
> > > > > alioth, until then. Being able to get a SSO certificate as a non-DD is
> > > > > currently a required step to become a DD.
> > > > Then the dd process should get fixed, not making again something to a 
> > > > backend
> > > > which isn't meaned like that (we had the same problem with alioth and
> > > > debconf).
> > > > 
> > > 
> > > Mmm, there was something with lemon and LDAP   ... websearch ... yes 
> > > found it.
> > > 
> > >  https://lemonldap-ng.org/start
> > > 
> > > Text from that webpage
> > > 
> > > LemonLDAP::NG is an open source Web Single Sign On (WebSSO), Access
> > > Management and Identity Federation product, written in Perl and
> > > Javascript.
> > > 
> > > LemonLDAP::NG is a free software, released under GPL license.
> > > 
> > > LemonLDAP::NG is the first SSO software deployed in French
> > > administrations. It can handle large-scale organization (tested with
> > > hundreds of thousands users). Many private firms use it too.
> > > [ https://lemonldap-ng.org/references ]
> > > 
> > > How much would it fill our needs??
> > Yes, thats already in the process of the gsoc project.
> > It is very high ranked on my list, however it is just a frontend, there is a
> > backend missing and its management (something that manages ldap). 
> 
> I went to Debian wiki, searched for 'SSO'
> and got https://wiki.debian.org/Salsa/SSO
> 
> Would that be the proper place to track status of Debian Single Sign On?
I don't think so, alsa will be a consumer of sso - not the provider, therefore 
it should
have its own namespace

Alex



signature.asc
Description: PGP signature

Re: Raising the problem of Debian Single Sign On + Alioth (again)

[Alexander Wirt]

On Fri, 23 Feb 2018, Geert Stappers wrote:

> On Fri, Feb 23, 2018 at 06:54:29PM +0100, Alexander Wirt wrote:
> > On Fri, 23 Feb 2018, Enrico Zini wrote:
> > > On Fri, Feb 23, 2018 at 03:49:06PM +0100, Alexander Wirt wrote:
> > > 
> > > > > Are there other ways in stretch of getting apache to authenticate
> > > > > against gitlab?
> > > > I would wait for the gsoc project. And on the alioth sprint, several 
> > > > people
> > > > decided against using salsa as backend for sso, but the other way 
> > > > round. 
> > > > So please don't.
> > > 
> > > Please do not switch Alioth off, nor disable creation of new accounts on
> > > alioth, until then. Being able to get a SSO certificate as a non-DD is
> > > currently a required step to become a DD.
> > Then the dd process should get fixed, not making again something to a 
> > backend
> > which isn't meaned like that (we had the same problem with alioth and
> > debconf).
> > 
> 
> Mmm, there was something with lemon and LDAP   ... websearch ... yes found it.
> 
>  https://lemonldap-ng.org/start
> 
> Text from that webpage
> 
> LemonLDAP::NG is an open source Web Single Sign On (WebSSO), Access
> Management and Identity Federation product, written in Perl and
> Javascript.
> 
> LemonLDAP::NG is a free software, released under GPL license.
> 
> LemonLDAP::NG is the first SSO software deployed in French
> administrations. It can handle large-scale organization (tested with
> hundreds of thousands users). Many private firms use it too.
> [ https://lemonldap-ng.org/references ]
> 
> How much would it fill our needs??
Yes, thats already in the process of the gsoc project.
It is very high ranked on my list, however it is just a frontend, there is a
backend missing and its management (something that manages ldap). 

Alex

Re: Raising the problem of Debian Single Sign On + Alioth (again)

[Alexander Wirt]

On Fri, 23 Feb 2018, Enrico Zini wrote:

> On Fri, Feb 23, 2018 at 03:49:06PM +0100, Alexander Wirt wrote:
> 
> > > Are there other ways in stretch of getting apache to authenticate
> > > against gitlab?
> > I would wait for the gsoc project. And on the alioth sprint, several people
> > decided against using salsa as backend for sso, but the other way round. 
> > So please don't.
> 
> Please do not switch Alioth off, nor disable creation of new accounts on
> alioth, until then. Being able to get a SSO certificate as a non-DD is
> currently a required step to become a DD.
Then the dd process should get fixed, not making again something to a backend
which isn't meaned like that (we had the same problem with alioth and
debconf).

Alex



signature.asc
Description: PGP signature

Re: Raising the problem of Debian Single Sign On + Alioth (again)

[Alexander Wirt]

On Fri, 23 Feb 2018, Enrico Zini wrote:

> On Sun, Feb 11, 2018 at 10:08:31PM +0800, Boyuan Yang wrote:
> 
> > From a user (non-DD)'s perspective, current best plan should be the 
> > integration
> > with Salsa GitLab user database. Works on such implementation are surely 
> > needed
> > though.
> 
> Well yes, work is needed, that much has always been clear.
> 
> At SnowCamp[1] I gave it a try with the help of aurel32.
> 
> Integrating sso.debian.org with $THING is simple as long as apache can
> authenticate against $THING. sso.debian.org's codebase just trusts
> apache's REMOTE_USER variable, and actual authentication is done at
> apache level. This means that the sso.debian.org codebase does not need
> to have access to ldap and other authentication backends.
> 
> We tried deploying libapache2-mod-auth-openidc to authenticate against
> gitlab, but that ended up in submitting https://bugs.debian.org/891224
> 
> Are there other ways in stretch of getting apache to authenticate
> against gitlab?
I would wait for the gsoc project. And on the alioth sprint, several people
decided against using salsa as backend for sso, but the other way round. 
So please don't.

Alex



signature.asc
Description: PGP signature

Re: What can Debian do to provide complex applications to its users?

[Alexander Wirt]

On Wed, 21 Feb 2018, Vincent Bernat wrote:

>  ❦ 21 février 2018 07:07 +0100, Alexander Wirt <formo...@debian.org> :
> 
> > No, backports doesn't have official security support in the meaning that
> > the team is tracking and looking after security issues in backports.
> > Nevertheless every backporter has to care about security, we do expect that
> > uploaders care about their packages - this does of course include security
> > support.
> 
> The net result for our users is that backports should not be expected to
> be up-to-date with security. It took me approximately one minute to go
> through latest DSA to find an example: Exim in backports is
> 4.89-2+deb9u1~bpo8+1. 4.89-2+deb9u2 has been uploaded in
> December. 4.89-2+deb9u3 has been uploaded in February.
yes, you are completely right. The maintainers responsibility was to upload
this package which he didn't. I just wanted to make the parameters of the
"best effort approach" clear. 

Alex


signature.asc
Description: PGP signature

Re: What can Debian do to provide complex applications to its users?

[Alexander Wirt]

On Tue, 20 Feb 2018, Vincent Bernat wrote:

>  ❦ 20 février 2018 09:05 +0200, Arto Jantunen  :
> 
> >> Moreover, backports do not accept security patches. You can only push a
> >> version in testing (or unstable). Notably, if the version in testing is
> >> not easily backportable (because of new dependencies), you may wait
> >> quite some time before you get a security update.
> >
> > Also not true. You can request an exception to this for your security
> > update, but you do need to communicate about this with the backports
> > team before uploading.
> 
> Also? What was not true? The Debian Backports FAQ?
> 
> The exception you mention is not documented. It is also likely to just be
> rejected:
>  
>  
> http://lists.alioth.debian.org/pipermail/pkg-roundcube-maintainers/2017-November/002070.html
> 
> And the backport team has been pretty clear this is not the right way to
> maintain backports:
> 
>  https://lists.debian.org/debian-backports/2017/05/msg00059.html
That does mean we don't want that packages are "maintained" that way in
backports. For a one time security patch, you can always ask for an
exception. But this is just to give the maintainer more time to update the
backport with the new version from testing/unstable. 

So speaking as one of the backports ftpmasters:

No, backports doesn't have official security support in the meaning that
the team is tracking and looking after security issues in backports.
Nevertheless every backporter has to care about security, we do expect that
uploaders care about their packages - this does of course include security
support.

For some specific security problem, you can always talk with us about an
(short living) exception to give the maintainer more time and keep our users
save. 

What we don't want is people maintaining packages in that way in backports. 
Source of backports are testing/stable (for old-stable-backports) and in some
times (security) unstable. We do expect that every package follows those
suites. If a maintainer doesn't want/can this, backports is the wrong
place for maintaing that package.

Hope that helps

Alex - Backports ftp-master



signature.asc
Description: PGP signature

Re: Extended Long Term Support for Wheezy

[Alexander Wirt]

On Tue, 20 Feb 2018, Vincent Bernat wrote:

>  ❦ 20 février 2018 18:10 +0100, Raphael Hertzog  :
> 
> >> some of the LTS sponsors are looking to extend the support period of
> >> Debian 7 Wheezy (from a few months up to a full year).i
> >
> > FWIW, I published a blog post with more details about how it will
> > work from the sponsor's point of view:
> > https://raphaelhertzog.com/2018/02/20/time-to-join-extended-long-term-support-for-debian-7-wheezy/
> 
> Limiting ELTS access to sponsors seem quite incompatible with using any
> Debian resource for that. Is that really the meaning of the last
> paragraph?
It its true, please stop to use any debian resources.

Thanks

Alex



signature.asc
Description: PGP signature

Re: Serious issue found while visiting your website

[Alexander Wirt]

On Tue, 20 Feb 2018, 積丹尼 Dan Jacobson wrote:

> DP> I visited your website and found that your website has been diagnosed 
> with many coding issues,
> 
> Yeah like letting all that spam in to this mailing list.
> 
> I bet they don't even need to subscribe.
Of course not. We are an open project. But there is only one thing being more
worse than a spammer, someone answering to spam. 

Alex

Re: admin team and delegation status, volunteers?

[Alexander Wirt]

On Mon, 19 Feb 2018, Daniel Pocock wrote:

Hi, 

being the new one here (first time as administrator of an org), I can't say
much about the real workload of the admins. However I will try my best to
add some input. I also can't say anything about outreach. 

> Nicolas and Sylvestre both resigned and gave us plenty of warning to
> update the delegation[1]
> 
> Molly put out a call[2] for names to put in the GSoC application but it
> wasn't clear if that was a call for people to be part of the new
> delegation or just the urgent request to fill out the form.
I don't care being part of an upcoming delegation, I think gsoc is too
important to leave it behind. 

> The DPL also mentioned it in bits[3] but as far as I know, this comment
> means he was just responding to queries about the process and is not
> actively talking to potential candidates.
> 
> Four people, including Molly and myself are in the GSoC system as
> administrators now, our names haven't been announced and personally I'm
> a bit cautious about not wanting to declare myself an administrator or
> pre-empt the new delegation unless there is consensus about the way the
> team is formed and how it wants to work.
> 
> As mentioned in the other thread, this is something we need to clear up
> before deciding how many projects and how to prioritize projects.
Ack, that would be good. 
> 
> Personally, whether I take an active role as admin may impact the way I
> respond to student inquiries for my projects so it is also important to
> clear up before the end of February.
> 
> Based on my experience as a previous admin (Ganglia) and mentor, I feel
> that a bigger admin group is needed to preserve organizational memory
> between rounds and cope with all the deadlines (there are many more
> deadlines for admins than mentors), maybe 3-5 admins in the GSoC system
> and at least 2 separate admins to Outreachy (because it happens twice
> per year and has lots of little differences that you can easily trip up on)
I would prefer to be involved in gsoc only.

> Having many admins in any team brings new problems but one potential
> solution is using the Kanboard as used by the DebConf team and
> discussed[4] in another thread on this list.  If both mentors and admins
> use a single Kanboard (or equivalent) it will be much easier for people
> to move around between roles and share the burden, avoiding burn-out,
> making vacations and other things easier during the summer.  Admins and
> backup mentors need to be able to drop into a project at any stage if
> the main mentor has an accident or something and using a common tool
> like that can make it more seamless.
Some kind of tool is probably a good idea, but I am unsure which one is the
right. Hopefully one of the more experienced admins has a good idea. 

> Another question is whether or not we want to have any policy on admins
> acting as mentors - if there are only 2 admins then it is harder for
> them to mentor due to admin workload but if we operate with a large
> admin group then it may be possible for some to mentor.  Then there are
> questions about the conflict of interest if we have to choose between
> projects.
I applied as an admin to make sure that my project will get realized, so I
can only speak for myself when I say: I would step down as admin if I
wouldn't be able to mentor my project otherwise. 

> How do other people feel about the current status, including those of
> you who are also listed in the GSoC system as admins today?
> 
> Who would potentially want to be an admin, would it be more attractive
> to you if the team was bigger and the workload distributed more?
Distributing workload is usally a good idea :). Another option would be to
limit the number of slots we request, if we don't have that much students (or
only the really promising ones) the workload will also be smaller. 

Just my 2 cents

Alex



signature.asc
Description: PGP signature

Re: Discussing Successor of Debian SSO Service

[Alexander Wirt]

On Sun, 18 Feb 2018, Dashamir Hoxha wrote:

> On Sun, Feb 18, 2018 at 11:38 PM, Alexander Wirt <formo...@formorer.de>
> wrote:
> 
> > On Sun, 18 Feb 2018, Dashamir Hoxha wrote:
> >
> > > On Sun, Feb 18, 2018 at 10:21 PM, Himanshu Shekhar <
> > > himanshushekhar...@gmail.com> wrote:
> > > >
> > > >
> > > > After going through the list, Keycloak <https://keycloak.org> was
> > > > something which impressed me. I shall give it a try sometime.
> > > >
> > >
> > > In my opinion, this should be the objective of your GSoC project: trying
> > > 2-3 of them and deciding which one works best for Debian.
> > Such an evaluation is done in a few days, I would expect more than just an
> > evaluation.
> >
> 
> Be creative and add more ingredients to it. For example:
> - Implementing (installing) the selected solution.
> - Integrating it with other Debian services that need SSO.
> - Migrating the data from the existing SSO solution to the new one.
> 
> For this maybe you have to get involved the current SSO maintainer
> as a mentor of the project.
He didn't wanted to, but we are in contact. 

Alex

Re: Discussing Successor of Debian SSO Service

[Alexander Wirt]

On Sun, 18 Feb 2018, Dashamir Hoxha wrote:

> On Sun, Feb 18, 2018 at 10:21 PM, Himanshu Shekhar <
> himanshushekhar...@gmail.com> wrote:
> >
> >
> > After going through the list, Keycloak  was
> > something which impressed me. I shall give it a try sometime.
> >
> 
> In my opinion, this should be the objective of your GSoC project: trying
> 2-3 of them and deciding which one works best for Debian.
Such an evaluation is done in a few days, I would expect more than just an
evaluation. 

lex

Re: Discussing Successor of Debian SSO Service

[Alexander Wirt]

On Sat, 17 Feb 2018, Dashamir Hoxha wrote:

> Maybe you should contact the project mentors, in order to get a feedback.
> 
> Anyway, trying to build a SSO service from scratch, in 3 months, is a huge
> task even for an expert, let alone a student.
> I have done it a few years ago (in Drupal7) so I know how difficult it is.
> The libraries that you mention are not enough.
you should not do something from scratch, but to provide the glue between
things already doing the right thing. 

> I would suggest that you try some existing implementions and select one of
> them.
> For example have a look at this list:
> https://en.wikipedia.org/wiki/List_of_single_sign-on_implementations
Of course. 

> > I am Himanshu Shekhar [1], an undergrad from IIIT-Allahabad, India.
> > I am studying Information Technology, am a polyglot programmer (prefers
> > Python, Golang and JavaScript) and have interned at SocialCops[2] (a
> > data-intelligence company) as a backend engineer last summer.
> >
> > I've been going through ideas proposed for GSOC'18 and stepped on this one.
> >
> > My institute requires me to use LDAP for authenticating on all sorts of
> > portals required. Being one of the mentors and coordinators at the
> > technical society of the institute, there are times where I have to
> > integrate some kind of portal to LDAP which I personally find horrible
> > because it is not HTTP and has a lot of restrictions from the campus proxy
> > server and firewall.
> >
> > As a result of this, I have been wanting to develop a generic SSO server
> > which can be deployed at website/premise without any hassle, something
> > which takes a config file for user database structure, some parameters and
> > does rest of the work over HTTP.
> >
> > ** What I pictured is an *open-source replica of Google Login* [3], with
> > same features - a central service which you have configured with the
> > information to collect for users who sign up and provide and applications
> > can use the service to authenticate and get the user's basic information.
> > The authorization part - scoping, limitations, is up to the client
> > application. The SSO server does authentication, and authorization is up to
> > the application server.
> >
> > Also, as a hobby project, I've been developing an API using Go and Gin
> > where I have implemented auth using JWT tokens [4] (both access and refresh
> > tokens), which is extremely simple in structure.
> > It does just one work - authenticating the required user from it's
> > database.
> >
> > Talking about the GSOC project, there are certain Oauth2 libraries for
> > Python, Golang, JavaScript which can be used to create the required service
> > over the top of it. I have listed the required links [5]  at the end of
> > this email.
> >
> > Is this similar to what you have pictured for Debian and this GSOC?
> > Please let me know. I would be really happy to work on something which I
> > have been passionately wanting to make.
> >
> > References:
> >
> > [5] Oauth2 libraries :
> >   Python : https://github.com/oauthlib/oauthlib
> >has implementations for Flask, Django, Bottle, Pyramid (mentioned
> > in Readme).
> >
> >   Golang :
> > Hydra : https://github.com/ory/hydra
> > Osin : https://github.com/RangelReale/osin
> >
> > [1] Himanshu Shekhar
> >   Github: https://github.com/himanshub16
> >   LinkedIn : https://linkedin.com/in/himanshub16
> >
> > [2] SocialCops : https://socialcops.com
> >
> > [3] Google Login : https://developers.google.com/
> > identity/sign-in/web/sign-in
> >
> > [4] JWT : https://jwt.io
> >
> > Regards,
> > Himanshu Shekhar
> >

Re: Mentors of GSoC-2018

[Alexander Wirt]

On Tue, 13 Feb 2018, Dashamir Hoxha wrote:

Hi,

> I think that co-mentors should also be invided as mentors on the GSoC
> platform, isn't it?
> If so, than please send an invitation to su...@medhas.org, co-mentor of
> freedombox-container, because it seems that I don't have permission to send
> invitations.
You are right, invitation send. 

Thanks for bringing this up

Alex

Re: Raising the problem of Debian Single Sign On + Alioth (again)

[Alexander Wirt]

On Sun, 11 Feb 2018, Boyuan Yang wrote:

> Hello all,
> 
> I just recalled that an issue was left behind during the Alioth ->
> Salsa migration:
> sso.debian.org 's Alioth account integration with Alioth platform. This 
> service
> seems to have no migration plan (yet) and will break many other stuff
> once Alioth
> is down.
> 
> Digging through the history, I found several places that once hold
> some related discussion:
> 
> * Alioth Sprint 2017:
> 
>   https://gobby.debian.org/export/Sprints/AliothSuccessors2017/Minutes
> 
> * Thread from debian-devel back on 2017-08:
> 
>   https://lists.debian.org/debian-devel/2017/08/msg00465.html
> 
> From a user (non-DD)'s perspective, current best plan should be the 
> integration
> with Salsa GitLab user database. Works on such implementation are surely 
> needed
> though.
so you volunteer to do that? great!

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
 

Re: debian single sign-on, alioth certificate creation or/and move to salsa ?

[Alexander Wirt]

On Wed, 07 Feb 2018, shirish शिरीष wrote:

> Dear all,
> 
> I just discovered the call to proposals have been announced. While I
> did make a new certificate manually on alioth as the old one was about
> to be expired.
> 
> I did see and have also made an account on salsa.debian.org but
> haven't been able to discover if semi-automated certification is also
> on salsa cards or not.
> 
> I do see that salsa/gitlab has provision to add ssh and gpg keys in
> account preferences but nothing about certificate creation.
> 
> https://salsa.debian.org/profile/preferences
> 
> 
> 
> https://sso.debian.org/
> 
> still points to alioth.debian.org for certification which works for
> now. Are there plans to keep alioth for SSO for this debconf cycle or
> are the certificates going to moved on to salsa sooner than later.
> 
> It is possible there is a roadmap somewhere I just don't know about
> it. I did see and notice the migration of lists from alioth to
> lists.debian.org .
> 
> Look forward to having some understanding about it.
> 
> I did look at 
> http://lists.alioth.debian.org/pipermail/alioth-staff-replacement/Week-of-Mon-20180101/000110.html
> which tells some of the steps being undertaken but no comment on the
> SSO service. Maybe it will happen 2, 2.5 years down the line.
> 
> Can somebody who knows tell us what if any plans are there for the SSO 
> service ?
There aren't any yet. I created a gsoc project for replacing/enhancing the
current sso solution. Unless someone comes up with anything, the guest
backend for ssl will die. 

Alex
 

Re: "Split config" into multiple files

[Alexander Wirt]

On Thu, 01 Feb 2018, Jonathan Sélea wrote:

> >
> >> I’m not sure if amavis will allow you to do an include as you are 
> >> suggesting. Someone else can maybe chime in on that. Have you considered 
> >> using opendkim instead of amavis to accomplish this? This will give you 
> >> the separate file functionality you are looking for.
> >>
> > The config is perl, you can do whatever you want and perl allows. 
> >
> > Alex
> 
> Did not know that, and I dont know perl either.
> So I could theoretically include configs in a catalogue?
Yes. The debian package for example already splits the amavis config. 

Alex



signature.asc
Description: PGP signature

Re: "Split config" into multiple files

[Alexander Wirt]

On Thu, 01 Feb 2018, Dino Edwards wrote:

> I’m not sure if amavis will allow you to do an include as you are suggesting. 
> Someone else can maybe chime in on that. Have you considered using opendkim 
> instead of amavis to accomplish this? This will give you the separate file 
> functionality you are looking for.
> 
The config is perl, you can do whatever you want and perl allows. 

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

Re: Default page view for salsa repositories

[Alexander Wirt]

On Mon, 22 Jan 2018, Alex Mestiashvili wrote:

> On 01/18/2018 12:15 PM, Alexander Wirt wrote:
> > On Thu, 18 Jan 2018, Arturo Borrero Gonzalez wrote:
> > 
> >> On 18 January 2018 at 11:15, Alex Mestiashvili <ames...@rsh2.donotuse.de> 
> >> wrote:
> >>> Hi All,
> >>>
> >>> while browsing through salsa.debian.org packages I got a feeling that
> >>> displaying upstream's Readme by default is not exactly relevant to
> >>> Debian packages. I guess it would make more sense do display
> >>> d/Readme.source if available or d/changelog instead.
> >>> Or even something more advanced like tracker.debian.org for a package...
> >>> A repository owner should be able to override this setting of course.
> >>>
> >>
> >> +1
> > Feel free to create an upstream issue asking for such a setting. 
> > 
> > Alex
> >  
> > 
> 
> Depending on the version of salsa's gitlab, this MR might be applicable
> for debian/changelog:
> 
>  https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16550
> 
> The issue on the gitlab's tracker:
> 
>  https://gitlab.com/gitlab-org/gitlab-ce/issues/42272
Then lets hope it gets accepted :)

Alex
 

Re: Google Summer of Code 2018

[Alexander Wirt]

On Sun, 21 Jan 2018, mollydb wrote:

> I mmissed this on the application before! We need 2-5 administrators for
> the application. Who else wants to be one?
Count me in. 

Alex
 

Re: Updating the Maintainer field in preparation for Alioth's shutdown?

[Alexander Wirt]

On Sat, 20 Jan 2018, Holger Levsen wrote:

> On Sat, Jan 20, 2018 at 10:29:44AM +, Dominic Hargreaves wrote:
> > The February date is indeed now very soon and it's unlikely we would
> > have this in place in time. However my understanding from the alioth
> > admins is that this wasn't a hard deadline and was proposed before there
> > was a suggestion to have a transitional service, so I hope that they
> > will be able to continue service until we are able to announce a
> > transition plan, at the latest by the end of April (when alioth
> > itself will be shut down).
> 
> I'd hope so too and would be very happy about some confirmation as well.
as I already said several times on several channels: now that there is
someone taking over list.a.d.o it is their job to define dates. The old dates
were proposals and noone (me included) cared enough to define something
fixed. 

But: I/we won't run alioth longer than the end of LTS. Around two weeks
before EOL I will start to archive all discontinued services and get alioth
into some read-only state.

Alex



signature.asc
Description: PGP signature

Re: Default page view for salsa repositories

[Alexander Wirt]

On Thu, 18 Jan 2018, Arturo Borrero Gonzalez wrote:

> On 18 January 2018 at 11:15, Alex Mestiashvili  
> wrote:
> > Hi All,
> >
> > while browsing through salsa.debian.org packages I got a feeling that
> > displaying upstream's Readme by default is not exactly relevant to
> > Debian packages. I guess it would make more sense do display
> > d/Readme.source if available or d/changelog instead.
> > Or even something more advanced like tracker.debian.org for a package...
> > A repository owner should be able to override this setting of course.
> >
> 
> +1
Feel free to create an upstream issue asking for such a setting. 

Alex
 

Re: salsa access as debian maintainer

[Alexander Wirt]

On Mon, 15 Jan 2018, Nico Schlömer wrote:

> Thanks for the quick reply.
> 
> >  unless DM information is available in udldap.
> 
> I'm not familar with udldap. Is this something where I or someone else
> should take action?
Debian Maintainers are not the Debian usermanagement system. Therefore we
can't create users based on that. Therefore you will have to stick to a
-guest user and ask for push rights on repos in debian/

Alex

Re: salsa access as debian maintainer

[Alexander Wirt]

On Mon, 15 Jan 2018, Nico Schlömer wrote:

Hi,

> I'm a Debian maintainer and the projects I'm working with have recently
> been moved from alioth to salsa. It seems that right now only Debian
> _developers_ have a login to salsa. Is this something that will change in
> the future or should I make a new account (and live with -guest :(). Will I
> have to re-apply for push rights to the respective repos?
This will not change unless DM information is available in udldap.

Alex

Re: Salsa Beta - Updates

[Alexander Wirt]

On Tue, 09 Jan 2018, Norbert Preining wrote:

Hi Norbert, 

> > we wanted to give you some updates and news about our salsa beta.
> 
> Thanks for the update, but I would like to know about the "beta" status.
> In your first announcement email you mentioned that library resets are
> possible etc etc, which would obliterate any move from alioth to salsa.
From the experience of the last weeks I think we can say that they won't
happen. 

> Can we nowadays reasonably be sure that salsa as is continues, and thus
> actually lock down alioth and only use salsa?
Locking down alioth will not happen soon. The migration process will probably
take a few months. 

Alex
 

Re: Ssh access on salsa denied

[Alexander Wirt]

On Mon, 08 Jan 2018, Alberto Luaces wrote:

> Alexander Wirt writes:
> 
> > On Sun, 07 Jan 2018, Andreas Tille wrote:
> >
> >> Hi,
> >> 
> >> I verified in the web interface on Salsa that my public ssh key
> >> from alioth was imported and to be very sure I uploaded it again.
> >> Unfortunately this does not changed anything
> >> 
> >>$ ssh -i ~/.ssh/id_rsa_debian2 ti...@salsa.debian.org
> >>ti...@salsa.debian.org: Permission denied (publickey).
> >> 
> >> The authentication log of the web interface does not mention any
> >> failed attempts.
> >> 
> >> Am I missing something?
> > Alioth doesn't have ssh access for users. All access hapens via git+ssh of
> > the git user. 
> 
> Unless I am missing something, yes you can access Alioth through ssh,
> that's the way some of us create new git repositories:
My bad, that should have been "salsa" users, as this request was about salsa
- which doesn't allow ssh. 

Alex