Re: salsa web server broken?

[Alexander Wirt]

Am Fri, May 24, 2024 at 11:23:44AM +0200 schrieb Vincent Lefevre:
> Is the salsa web server broken?
> 
> The display of https://salsa.debian.org/python-team/packages/fail2ban
> is completely wrong, and https://salsa.debian.org/ gives an
>
We are in maintenance. 

Alex
 

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

[Alexander Wirt]

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

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

Alex

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 06 Jan 2020, Ulrike Uhlig wrote:

> Hi formorer,
> 
> > On 28.12.19 18:16, Alexander Wirt wrote:
> >> On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> >> I am sure there are many ways to help the team and it is not just
> >> about Salsa/Gitlab admin stuff, but also about creating structure in
> >> the team, triaging issues, spreading best practices for users and
> >> helping the most advanced users to grow into admins of Salsa etc.
> >> Right now we don't even have any kind of salsa-related discussion
> >> list on lists.debian.org. Thus I wanted to raise discussion on
> >> debian-devel. In my opinion Salsa is becoming a very central piece of
> >> the Debian infrastructure and it should have more attention on
> >> debian-devel and from the project leader.
> 
> > We are working on it and after my holidays are over I will plan
> > another sprint for improving salsa.
> 
> >From your replies to emails in this thread I was wondering: do you mean
> that the Salsa team does not need, or does not want, help? Or does not
> need, or want, help outside of a sprint?
That basically means: yes we probably need help. But it also means that
getting help should be done in a coordinated way, like introducing one or two
team members during a sprint. Getting someone new involved always means
overhead and should happen when there is time for such overhead. In my
experience sprints are ideal for it. I also talked to some people about
getting them involved in salsa, but there will also be a call for help. 

I / we plan to add at least one global admin and maybe one or two assistants
that help with "user" support. 

We just need some time to plan and coordinate those things (around christmas
is really a bad timing for such discussions)

Alex

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 06 Jan 2020, Sam Hartman wrote:

> >>>>> "Alexander" == Alexander Wirt  writes:
> 
> Alexander> For everything else: we are working on it. 
> 
> I just want to confirm that part of the things that you are working on
> is documenting the issues.  At a number of points you've talked about
> how people are misunderstanding the issues or are thinking it's simply
> more CPU etc.
> 
> That's all doubtless true.
> But part of being in a community is communicating with that community.
> People would almost certainly be more understanding if they had more
> information.
just for the record, I am doing all of this in my spare time and I prefer to
decide on my own what is in my queue and what the priority is. And yes, I do
prefer to fix things instead of documenting what needs to get fixed. 

And if everyone would behave sane instead of st* flame wars, insulting each
other and so on (it was a listmaster month to forget) my motivation to work
with that specific community would be a lot better. 

And for everyones sake: when announcing CI support we told everyone that the
ressources are limited and everyone should play nice with the CI. 

As often, other people decided to make the CI and the runners a quasi
standard, adding it to their workflows and so on. Now everyone is surprised
if things are as we always told everybody. What a surprise. 

Thanks for listening. 

Alex



signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Wed, 01 Jan 2020, Otto Kekäläinen wrote:

> Hello!
> 
> ti 31. jouluk. 2019 klo 14.55 Alexander Wirt (formo...@debian.org) kirjoitti:
> > On Mon, 30 Dec 2019, Bernd Zeimetz wrote:
> > > Also, if resources are an issue: I've offered several times to see if I
> > > can get some k8s resources for gitlab runners, but never got a reply.
> > > Not even a no.
> > It is not a problem on the runner side.
> >
> > And as said, we are working on the other problems until we can improve
> > something in that part.
> 
> If it is not a problem on the runner side and you don't need more
> runner resources, what is the reason the runner is capped at 1h?
> MariaDB is a huge beast and building it and running all tests take
> 1,5h for completely valid reasons (also note we have ccache on
> Salsa-CI so re-builds are much faster).
We updated the timeout to three hours. However, if that leads to problems on
salsa side we will have to set it back. So please ensure not to create too
much load / jobs that use that extended limit. 

For everything else: we are working on it. 

Alex

Accepted ipvsadm 1:1.31-1 (source amd64) into unstable

[Alexander Wirt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 05 Jan 2020 21:33:49 +0100
Source: ipvsadm
Binary: ipvsadm ipvsadm-dbgsym
Architecture: source amd64
Version: 1:1.31-1
Distribution: unstable
Urgency: medium
Maintainer: Alexander Wirt 
Changed-By: Alexander Wirt 
Description:
 ipvsadm- Linux Virtual Server support programs
Changes:
 ipvsadm (1:1.31-1) unstable; urgency=medium
 .
   * [950ed21] New upstream version 1.31
   * [e35ba70] Refresh patch
   * [5639279] Bump standards version
Checksums-Sha1:
 2256d3014b65eb73ddaef496d4dc328baca30388 1898 ipvsadm_1.31-1.dsc
 2d6fa5fe01f8aa9dd4fc272855c8fc12aea3c06b 50389 ipvsadm_1.31.orig.tar.gz
 5078dad0f7358c4d123dacbeedf4ac78f1ef3570 14264 ipvsadm_1.31-1.debian.tar.xz
 7a67819c91616552052947c75c0416a533f79229 28392 ipvsadm-dbgsym_1.31-1_amd64.deb
 2c9610612d7e7107798a6d1c2333ca90918314cc 5755 ipvsadm_1.31-1_amd64.buildinfo
 14cb006d092d63e6fe57801cbba76e3e9cdc8168 41368 ipvsadm_1.31-1_amd64.deb
Checksums-Sha256:
 de4950dfbb0ae18fbb75a4ee797d7455cd9ada4709a4408b28d02a9894283470 1898 
ipvsadm_1.31-1.dsc
 7276bcf214f31051188b2e44f11029e57303f37e54126e517000c1b2123a6d4e 50389 
ipvsadm_1.31.orig.tar.gz
 5e996a891641a63164ce8c270f7942e1beca30ba0f0f09cdc0e42b461abadcee 14264 
ipvsadm_1.31-1.debian.tar.xz
 b42ea5092e902ebac8ef4c79ea8443fb42e3c73c6d58982c92b0469a4699f1a7 28392 
ipvsadm-dbgsym_1.31-1_amd64.deb
 58763f787590b7e8285fc2d3ff55adea533c83d32f0572e2891267fbd19b494a 5755 
ipvsadm_1.31-1_amd64.buildinfo
 ba0b75653672105c2ce60a4560b3bbd3c267bac2fda979f4b7812bff97a0fe94 41368 
ipvsadm_1.31-1_amd64.deb
Files:
 2d60edd0573a09cad8e0b9b1b40f9d0b 1898 net optional ipvsadm_1.31-1.dsc
 c0c22a127cefa71a031046aa089cc656 50389 net optional ipvsadm_1.31.orig.tar.gz
 7bdc12294beb76385fe3ce5ec10b83e0 14264 net optional 
ipvsadm_1.31-1.debian.tar.xz
 c43acaff982da7f2497e6a647e95aa93 28392 debug optional 
ipvsadm-dbgsym_1.31-1_amd64.deb
 21d36c188c71e5e9044e246d13d2a399 5755 net optional 
ipvsadm_1.31-1_amd64.buildinfo
 117df27a16716549aa2eadaa952d91b9 41368 net optional ipvsadm_1.31-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEbjlmweHRXblz0FtJHkX4yp3iOxYFAl4SSLkACgkQHkX4yp3i
Oxb01Q/9HydEaFeWdk1Nlpu7SKu+BffyP5hNNtOkaESxu74KCqjlXMqjfPqI2ZOx
RIjSnB0OdvcdUmQkPyRvP7HL3WHB6SQARBK/z8sX0o2SIOj42Xkb/46kMwSYESA7
0HLEx+8mjpjYy70cR7ZT1gHIJSOXk9cgMqNkZ3VlMPs4ELXMxRDXO2zh+Ji6bUlb
vFaJLIXbhP1HdC0gjU4Q2T7W4EhQG5M3sFfzXBhiIc4rSoXl/LY8PrepsbiXKyjH
7sbKomQB9RZ8CbANat5Hyo+uVklwSTj32MvN6C0sPq+hApnYguqFhps8BJQVj6Wh
DK1qpx9ZwYWWtCZpwXugnQer55dH6K5k1y1McrwwiVc9vzJ3ZNyD+xmDQLqtxNom
C0+N4y6hTxrhBc1gXtC4XqG/7QcsJ92PxoWxheKYIj4pk9FdnvVdrlWDTYIXBorL
OxLCV/5OwBIXr6IFiBdA4GCEDc9F17Yrr7eNWT85n67Ibg/ww5p4LlmR9l2vatDo
MZclU+cZUwDeYEcGwSzqFiHqmZDnHNFtcTIVqQMKx8NuWscdql23I5h8mRCXkReN
yVCfX6ieALbIEq3WtRXFmPmuxar+A/F+A+wB2dZBFdkP6XIWyqQeur0GHi78DQek
v0vuK4wUokUTTOztX3mw9bfJwgrBpbVlkbHtTsRRCJ2Oru8r198=
=TIQO
-END PGP SIGNATURE-

Accepted keepalived 1:2.0.19-1 (source amd64) into unstable

[Alexander Wirt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 05 Jan 2020 18:45:43 +0100
Source: keepalived
Binary: keepalived keepalived-dbgsym
Architecture: source amd64
Version: 1:2.0.19-1
Distribution: unstable
Urgency: medium
Maintainer: Alexander Wirt 
Changed-By: Alexander Wirt 
Description:
 keepalived - Failover and monitoring daemon for LVS clusters
Closes: 775868 859142 878241 931617 940036 942182 947472
Changes:
 keepalived (1:2.0.19-1) unstable; urgency=medium
 .
   * [3e69686] New upstream version 2.0.19 (Closes: #947472)
 - fixes execution of scripts with /bin/sh (Closes: #931617)
 - fixes configuration parsing for SMTP sections (Closes: #859142)
 - fixes stuck in receive queue (Closes: #942182)
 - close netlink in checker (Closes: #775868)
 - fix infinite loop when tracker script times out (Closes: #940036)
 - fix loading of libipset (Closes: #878241)
   * [6a81734] Move to debhelper(-compat) 12
   * [02d9f5d] Bump standards version
   * [239c70f] Fix location of the ip_vs header file
   * [495b6e5] Disable dbus create instance feature
   * [ec5c22c] Enable iptc support
Checksums-Sha1:
 ee4bce546944cbc31b1e07cfb0b88976e398 2091 keepalived_2.0.19-1.dsc
 42c4ba1ae53acdd72f0f73ba275ae884f3ff73bb 1025062 keepalived_2.0.19.orig.tar.gz
 42564b5fd9a48c432076922702f49c0ad3395682 10820 
keepalived_2.0.19-1.debian.tar.xz
 60e7f0b2736fea4e813a334773896657177aa2e1 912124 
keepalived-dbgsym_2.0.19-1_amd64.deb
 77d8c5de13ebd1048649acec7a77f0b8f978499d 7981 
keepalived_2.0.19-1_amd64.buildinfo
 4f2fed8c53acabc7f72dc28bd6de52bab21528b1 523004 keepalived_2.0.19-1_amd64.deb
Checksums-Sha256:
 b20037249f7a48fc4ccffcf5e28545f733b5d71576c2da21ef7fc79200333742 2091 
keepalived_2.0.19-1.dsc
 0e2f8454765bc6a5fa26758bd9cec18aae42882843cdd24848aff0ae65ce4ca7 1025062 
keepalived_2.0.19.orig.tar.gz
 bbb0eaf620901aaec4cd82c07839ba88d529380c9290eafa9a15eef41337d7ea 10820 
keepalived_2.0.19-1.debian.tar.xz
 9eb59e6690dfcbeff7412fc46eeefbfc9070f89a9228903efcbfcbed50979048 912124 
keepalived-dbgsym_2.0.19-1_amd64.deb
 5aa0a94cc8a7641690ed646bcdb0005afbb794e4bcd48a892327c24b9af09edc 7981 
keepalived_2.0.19-1_amd64.buildinfo
 35d83745f6b912f6f23748557048952d61c7fda8781ae5bff92ee450738deedf 523004 
keepalived_2.0.19-1_amd64.deb
Files:
 7817d8b440a75ec232a6051d03a9a8bd 2091 admin optional keepalived_2.0.19-1.dsc
 df670e0904d4e48e72ccc8409ad9c6de 1025062 admin optional 
keepalived_2.0.19.orig.tar.gz
 17f859811d9735fb5bb02359e201bf66 10820 admin optional 
keepalived_2.0.19-1.debian.tar.xz
 1f2e93d221196bc1b3bc4b8d7f34a0fc 912124 debug optional 
keepalived-dbgsym_2.0.19-1_amd64.deb
 087df2fce5309ced0161f70981ebd285 7981 admin optional 
keepalived_2.0.19-1_amd64.buildinfo
 200cab35e2e853dff2194f9fc320fca6 523004 admin optional 
keepalived_2.0.19-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEbjlmweHRXblz0FtJHkX4yp3iOxYFAl4SQUIACgkQHkX4yp3i
OxZVnQ//dQp0h/2/EjEATC2hPcvZ7QHeWtJiquvzSO9QYfthXgjNhhfPZoqV6tUQ
x5IlqtO3NV0YCzfndq2ZoP97HAx11ow7XyzoZ1QrxLqagcYrufnM9c9gVJ9BJ1bM
4mC+/WbaNetQNA5Ml/RKvOFvLrWdoouTuWMzLLytRtHpgIHudqgpiYRr4yMQirIv
ruwC47w2R1cn5aBT3rKQbsLc0TSuGFx2yOGfWf28dX0nATYB/y5eIAvx7w9dQG63
PlKsex+cEqRiR/Ri3DE9XLjHcW+con+Ab2uorcdE2ApAYc99XmaJHLvDdar3yvdg
xkdJ10K6XvE3sqjVVXUpuV4Fvg2corx/lTaTWcVAdrr2Bq156ABGTtkf4qA24xgN
1iipjbSs4lcw4IP6ZMXQPn6R2TKZWtJ8OzoJHhbT+XVOmf8+LIb3IgMeMN71gy2z
Met96g2okws8VThykDMRcdZpC1xDsZalNPVN0M4EvD4KGFwndBVYJIkmcBsAZXI1
ogMrYrqYHtnVwDgeJsHBvA4KI8qqfBECTQEcuh9Mu6EYMroadY24W9BJcu7+7gxw
0d5NXNH2CtG6cY+qGakf6+ctvA3EGK1BQbZuy0u4vtRz+HjWmPGaLb5/VwkLBxQK
sJrVkdMvGsfUSHy8cElJF5ZSmudn/0YecYkes5q3a5z4EAPGGYI=
=I2I/
-END PGP SIGNATURE-

Accepted ferm 2.5-1 (source all) into unstable

[Alexander Wirt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 04 Jan 2020 11:58:53 +0100
Source: ferm
Binary: ferm
Architecture: source all
Version: 2.5-1
Distribution: unstable
Urgency: medium
Maintainer: Alexander Wirt 
Changed-By: Alexander Wirt 
Description:
 ferm   - maintain and setup complicated firewall rules
Closes: 774927 912536 929416
Changes:
 ferm (2.5-1) unstable; urgency=medium
 .
   * Add support for .xz files
   * Convert to debsrc 3.0
   * Fix watch expression
   * New upstream version 2.5
 - support for iptables in /usr/sbin (Closes: #912536)
 - use legacy tools if available (Closes: #929416)
   * bump standards version
   * Add ${misc:Pre-Depends} to controlfile
   * Escape $ in HERE doc (Closes: #774927)
   * Move to debhelper-compat
Checksums-Sha1:
 2d965ed5af5be448f339f02915a9ef15fd7c6582 2050 ferm_2.5-1.dsc
 5d984b27139c1c2c5ce04d3e2ead1d85656f9f94 74052 ferm_2.5.orig.tar.xz
 a9ce191e4ea33cfac756115f6bd455b6856a21f7 833 ferm_2.5.orig.tar.xz.asc
 77a9f75fcfd225897adb792e825405c142106f25 19804 ferm_2.5-1.debian.tar.xz
 303953feae9748059ae7579b8189e35ea4c9a8c2 114104 ferm_2.5-1_all.deb
 5a5e508aa5fa5aa58ed6056ce3815d56f2312626 5402 ferm_2.5-1_amd64.buildinfo
Checksums-Sha256:
 779166af3fcea80647dd8744bb3e1e00f9aeec66e9be141bbdbef1a3fd5a775c 2050 
ferm_2.5-1.dsc
 17082d4569b0e157d01638f9b6050418ab200cc0b3c08cdbbe30c29be365b853 74052 
ferm_2.5.orig.tar.xz
 fd530093dea32574d1ea252e13735aadd1bf78e437c0cf221780050adfd981fb 833 
ferm_2.5.orig.tar.xz.asc
 c565aae420e2c4b57aa3ee0a2694cb3730cf83c1c7e67541a7de4e3a7aaf3889 19804 
ferm_2.5-1.debian.tar.xz
 d8494a63ca356ed9806b1383cdfb04ef8ee590e151839d5b0f8572b218204aab 114104 
ferm_2.5-1_all.deb
 2c00cd11fa8581fbce45146623177d69c206235ab0c5d365ff47842cf048fda4 5402 
ferm_2.5-1_amd64.buildinfo
Files:
 a13423e5a667d0aff05c04690b6ec9fe 2050 net optional ferm_2.5-1.dsc
 82865ef1bc6d3e3c8b8f5dab4e10c6f7 74052 net optional ferm_2.5.orig.tar.xz
 4f702b483d07cf8157526b2187bbde65 833 net optional ferm_2.5.orig.tar.xz.asc
 d3a932aa9ddc9a743ad30ea7735ff3e5 19804 net optional ferm_2.5-1.debian.tar.xz
 d8dc0a4ac58e3a4081b2d23f411a1e42 114104 net optional ferm_2.5-1_all.deb
 9c5756857cf9da155524e876cb6248d8 5402 net optional ferm_2.5-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEbjlmweHRXblz0FtJHkX4yp3iOxYFAl4QhYEACgkQHkX4yp3i
Oxa5Sw/+OnJ5YIaDmK2ZTOfzd6+GStd1ik82yS+jq8Lkz1vmi1tkyLWv8ytW6txg
fMSp9O2DBPkU6AXZnQ/KhLs8ifk3yRv2lPP7ILgGuEMHJ6ahmyY7tE6GIitWv5fz
9D6uDTwvDdqiZp7P1OGD64X/e04H0v0vVgRuYdV3HA2fum3FJ0PfMJ9NpeFzJA65
aAHxiR1oBkWhk6h6R2ya3+Lp/ehVV4/3LggbWVHpxRiKOmb5WyvAbRmFsY7880qZ
ydqBMDFHAnaNIGUJ3PGrDwstAZyKqpAc12xZ+aquyNdKqJuiaEoUXC3SCALy6VWe
4iov2QtpAn+Kyivay0sV7ZIZOpgsge3zVekikxpq+4H9NCCox87xRgKalpBfjcmh
OcKg1HlEGs62dAJEg6qwa5RZON1fmGWc5LicWzEYMRxbt/eiiU5N+Jqvk2H2CU4p
qSYmuyk5bamjC2VdTYbrpGOgSEJrJ3VVijghy4lFWjjj5uPTQw6C8Xqnq1IPDRpi
Fag2FSts/DtkuECUX2JHiVWvgbbRioz4+FHuCuUKmfnKzX24UeCqfnBGmuZfPKgM
NZOLVy4KnKzm4m8jGVwye1CJBbjpqzBeAYjXqYxszHdlH5vuL+HRZWb3HdyUGboB
BByD9/rg4XS+T4IGsH9YBzmo1TUwbGBXAbNYgv2pye7J/Q0ZDBk=
=xJU8
-END PGP SIGNATURE-

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 30 Dec 2019, Bernd Zeimetz wrote:

> 
> 
> On 12/30/19 11:29 AM, Raphael Hertzog wrote:
> > I don't think that salsa-ci is particularly problematic in terms of
> > "efficiency". With the exception of the LXC usage, there's not much
> > that can be "cut" to save resources.
> 
> Also, if resources are an issue: I've offered several times to see if I
> can get some k8s resources for gitlab runners, but never got a reply.
> Not even a no.
It is not a problem on the runner side. 
 
And as said, we are working on the other problems until we can improve
something in that part. 

Alex

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 30 Dec 2019, Raphael Hertzog wrote:

> On Sat, 28 Dec 2019, Alexander Wirt wrote:
> > On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> > 
> > > Hello!
> > > 
> > > I've seen many times before statements like these so I'd like to raise
> > > some discussion around the topic:
> > > 
> > > pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> > > > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > > > > The Salsa CA pipeline is recommended.
> > > >
> > > > For this I need to use my veto as Salsa admin.  With the CI people we
> > > > have to work through too much problems first.
> > The salsa ci pipeline itself has some problematic implementation details
> > waldi lined out in the past. Afaik nothing changed, we had several reports
> 
> This is not really true:
> https://salsa.debian.org/salsa-ci-team/pipeline/issues?scope=all=%E2%9C%93=opened_username=waldi
> 
> Out of 12 issues reported by waldi, 8 have been fixed/closed.
> 
> Among the remaining ones:
> 
> - https://salsa.debian.org/salsa-ci-team/pipeline/issues/93
>   (usage of LXC for autopkgtest)
>   is likely the most problematic one even though you never explained
>   what's the real issue... yeah it's virtualization over virtualization
>   and it downloads a root tarball to do its work, but is this worth than
>   downloading a docker image? It uses more resources than direct execution
>   of autopkgtest but it hasn't broken anything so far?
that second level of virtualisation caused problems where people told us they
are not able to do things in their ci jobs. 

*snip*

> > where people telling us things are not possible on our runners. In the end
> > most of them turned out to be limitations of salsa ci. Salsa ci is also
> > not very efficent, therefore the veto. 
> 
> Claims like "salsa ci is not very efficient" are not actionable. Bugs like
> those above are more useful but you should at least take the time to
> respond to queries of people, otherwise no progress can be made.
> 
> I don't think that salsa-ci is particularly problematic in terms of
> "efficiency". With the exception of the LXC usage, there's not much
> that can be "cut" to save resources.
Thats probably true, but if it is inefficent and may cause problems on our
current architecture / ressources - that can't get fixed easily - a veto is
the only thing we have. 

> > We are working on it and after my holidays are over I will plan another
> > sprint for improving salsa. 
> 
> \o/

Alex - forgive the shortness, I am on vacation


signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Thu, 26 Dec 2019, Otto Kekäläinen wrote:

> Hello!
> 
> I've seen many times before statements like these so I'd like to raise
> some discussion around the topic:
> 
> pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > > The Salsa CA pipeline is recommended.
> >
> > For this I need to use my veto as Salsa admin.  With the CI people we
> > have to work through too much problems first.
The salsa ci pipeline itself has some problematic implementation details
waldi lined out in the past. Afaik nothing changed, we had several reports
where people telling us things are not possible on our runners. In the end
most of them turned out to be limitations of salsa ci. Salsa ci is also
not very efficent, therefore the veto. 

> There seems to be a conflict between the Salsa admins and users of
> Salsa: the more Salsa is used, the bigger becomes the maintenance
> burden and the more computing resources Salsa needs. There is however
> no inherent growth feedback loop in the system that would increase
> maintenance commitments as usage commitments grow. In economic terms
> one could say that the Salsa admins don't profit from maintaining
> Salsa and as demand grows there is nothing that grows the supply at
> the moment.
> 
> The reason for Salsa popularity to grow all the time is simply because
> it is such a brilliant service and many Debian Developers and aspiring
> new contributors love to use it. Personally I've had all my packages
> on Salsa since early 2018 and I would never want to go back to the mix
> of Github and Alioth I used before. Using Gitlab-CI is nowadays an
> inherent part of my packaging workflow to test contributions before
> merging them and to do QA before uploads. Any disruptions to Salsa
> basically grinds by packaging work to a halt[1], it is so central for
> me nowadays.
> 
> Since Salsa was officially launched in 2018 there has not been any [2]
> new members to the Salsa admins group [3]. Alexander, Joerg and
> Bastian have done a great job maintaining our Gitlab installation. The
> software suite is a beast and keeping it running well is a major
> effort in itself.
> 
> They need help going forward. The sentiment of restricting vital use
> of Salsa is a sign of them trying to keep things under control. But
> Salsa usage needs to grow, as that is good for Debian as a project.
> For the Debian project I think it would be a priority to find more
> resources to the Salsa admin team. I think that would be the ultimate
> solution to the current conflict.
For more performane salsa would need a proper redesign by moving it from its
monolithic system to a more distributed system. In fact we are already
talking about it for some time. But in fact you - the users - should not
think that everything is as easy as just adding some cpus, disks or workers.
Things are often more complicated and - in the end - everything should be
maintainable by DSA too. 

> Personally I cannot commit to maintain Salsa, unfortunately. If Salsa
> is out of computing resources I can however help find more sponsors
> for public runners. But I have the understanding that Google has
> donated plenty of cloud computing time and the root cause is not in
> lack of computing resources, but in the human scalability aspects of
> Salsa operations.
in fact thats only partially true. 

We are working on it and after my holidays are over I will plan another
sprint for improving salsa. 

Things are not always as easy as it seems.

Alex


signature.asc
Description: PGP signature

Re: When acting as a service admin, it's official, no really.

[Alexander Wirt]

On Wed, 09 Oct 2019, Sam Hartman wrote:

> >>>>> "Alexander" == Alexander Wirt  writes:
> 
> Alexander> On Sun, 15 Sep 2019, Jonas Meurer wrote:
> >> Sam Hartman: >>>>>> "Bastian" == Bastian Blank 
> >> writes:
> >> > 
> >> > Bastian> Hi Sam
> >> > Bastian> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman 
> wrote:
> >> > >> The Salsa CA pipeline is recommended.
> >> > 
> >> > Bastian> For this I need to use my veto as Salsa admin.  With
> >> the CI > Bastian> people we have to work through too much
> >> problems first.
> >> > 
> >> > [...]  > I'll remove it from the next version.
> >> 
> >> Please don't. It would be a shame if we would *not* recommend to
> >> use the awesome Salsa CI pipeline for automated continuous
> >> testing of package development. I applaud the Salsa-CI's team for
> >> their effort, it's a huge step forwart for Debians QA standards.
> >> 
> >> I also honestly appreciate all the hard work that the Salsa
> >> admins put into running Salsa, but it's absolutely not acceptable
> >> how they try to missuse the power of their role by behaving as
> >> Salsa dictators.
> Alexander> They? Since noone Cced me, I wasn't even aware of this
> Alexander> discussion.
> 
> Alexander> So please don't they unless it is something offical from
> Alexander> the team (such things will not hidden in a long thread).
> 
> I'm sorry, but Bastian's statement was inherently official.
> He was a Salsa Admin, saying something that could only be said in his
> official role.
> When I took it as an official statement and acted on it, he thanked me
> rather than correcting me that it was only his personal opinion.
> 
> It's reasonable for the project to take it that way; many people did.
> 
> It was on Bastian to communicate appropriately within the team.  If that
> didn't happen, that's an internal team matter.
If we want to announce something, we announce it. Until we do something like
this: of course there can be a (temporary) veto. You can't expect us to allow
things that will break the service for everybody without stepping in. That
doesn't mean that such things are final decisions or the we don't work with
people to improve/fix things. 

Bastians communication is sometimes a bit shorter or more direct than it
should be. If you are unsure about things - talk to the team and not
something hidden in some threads (salsa-admin@ or IRC).

Alex

Re: Git Packaging Round 2: When to Salsa

[Alexander Wirt]

On Sun, 15 Sep 2019, Jonas Meurer wrote:

> Sam Hartman:
> >> "Bastian" == Bastian Blank  writes:
> > 
> > Bastian> Hi Sam
> > Bastian> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > >> The Salsa CA pipeline is recommended.
> > 
> > Bastian> For this I need to use my veto as Salsa admin.  With the CI
> > Bastian> people we have to work through too much problems first.
> > 
> > [...]
> > I'll remove it from the next version.
> 
> Please don't. It would be a shame if we would *not* recommend to use the
> awesome Salsa CI pipeline for automated continuous testing of package
> development. I applaud the Salsa-CI's team for their effort, it's a huge
> step forwart for Debians QA standards.
> 
> I also honestly appreciate all the hard work that the Salsa admins put
> into running Salsa, but it's absolutely not acceptable how they try to
> missuse the power of their role by behaving as Salsa dictators.
They? Since noone Cced me, I wasn't even aware of this discussion. 

So please don't they unless it is something offical from the team (such
things will not hidden in a long thread).

Alex



signature.asc
Description: PGP signature

Re: salsa.debian.org partially down

[Alexander Wirt]

On Fri, 16 Aug 2019, Raphael Hertzog wrote:

> Hi,
> 
> On Fri, 16 Aug 2019, gregor herrmann wrote:
> > From what I know, this what not a "foolish user action" but an action
> > by a dedicated maintainer who enabled salsa-ci for all packages
> > ("projects") of a specific team; so they used a service advertised by
> > the salsa and salsa-ci teams. That this service doesn't work as
> > advertised or at least doesn't work for the amount of packages a
> > medium-sized team might have is deplorable and needs some action but
> > I don't see any reason for calling this action itself foolish.
> 
> +1
> 
> FWIW, I did the same for Kali linux on 500 packages which are
> hosted on https://gitlab.com/kalilinux/packages/ and it generated that many
> pipelines as well without any significant issue.
> 
> Obviously, gitlab.com has certainly much more resources behind it
> than salsa but I believe that we should be able to just do that without
> bringing salsa to its knees. It's quite common to do mass-update to many
> repositories with "mr" and that would generate just as many pipelines
> too.
> 
> I understand that the Salsa admins will have to find ways to grow the
> available resources and so far they did a very good job on this level,
> (except the part where they always express their grumpyness in a way that
> is hostile to many users) so I'm confident that they will find solutions.
> 
> They already moved most of the work to external Google VM to make the service
> scale (at the start it was running entirely on the few dedicated
> runners). Same for storage of many artifacts/log files.
> 
> When we looked into replacing FusionForge, GitLab was not necessarily
> their preference (at least for formorer IIRC) but they listened to the
> feedback from DD on this level and it's pretty clear (at least to me)
> that the GitLab CI features are the reason why many DD voted for GitLab.
> 
> So, indeed, we should not blame users because they enable CI, we selected
> GitLab because of those features.
> 
> In summary: thank you Salsa admins and keep up the good work! (And try to be
> less grumpy)
I am a bit surprised, from the first day on we said that there are limited
ressources for ci and that you should be nice to the service. Thats even
documented: 

"We mean that. Really. Be nice to the server. At some point in the future we 
hope to add some dedicated Runners servers - Sponsors welcome! ;)"

And we mean it that way, so don't be surprised if we tell you that you
overload things. We are always improving things, but anyhow, there are
limits - as it is for every other service within debian. 

So please, please don't tell me what you expect and so on. Just be happy that
it works so well.

Alex



signature.asc
Description: PGP signature

Re: salsa.debian.org partially down

[Alexander Wirt]

On Fri, 16 Aug 2019, Daniel Leidert wrote:

> Am Freitag, den 16.08.2019, 08:58 +0200 schrieb Alexander Wirt:
> > On Fri, 16 Aug 2019, gregor herrmann wrote:
> 
> [..]
> > > From what I know, this what not a "foolish user action" but an action
> > > by a dedicated maintainer who enabled salsa-ci for all packages
> > > ("projects") of a specific team; so they used a service advertised by
> > > the salsa and salsa-ci teams. That this service doesn't work as
> > > advertised or at least doesn't work for the amount of packages a
> > > medium-sized team might have is deplorable and needs some action but
> > > I don't see any reason for calling this action itself foolish.
> > 
> > All our services have somewhat limited ressources and need to work for all
> > developers. To be honest: I do expect from everyone, using any of our
> > (debian) services, to think before doing things like that. Be it sending a
> > few thousand mails to our mailing lists, creating a few thousand jobs on
> > salsa, uploading a few thousand packages, creating a few thousand bugs. 
> 
> I'm with Gregor on this one. I can expect our services not to be forced into
> their knees, just be increasing the workload (hint: queue).
> 
> Gitlab has a configuration to limit how many jobs can be run concurrently. The
> user's action might not have been optimal, but it has shown, that the current
> setting is not optimal either. So I think it's best, not to blame the user, 
> but
> adjust our Gitlab configuration, announce the changes, point out how to skip
> pipelines [1] and move on.
And as I said, you will always find ways to ddos a service (that does not
mean the user was foolish, intended to do it or is even to blame for that). 

But yeah go ahead: write documentation. 

Alex


signature.asc
Description: PGP signature

Re: salsa.debian.org partially down

[Alexander Wirt]

On Fri, 16 Aug 2019, gregor herrmann wrote:

> On Wed, 14 Aug 2019 08:39:22 +0100, Ian Jackson wrote:
> 
> > Alexander Wirt writes ("Re: salsa.debian.org partially down"):
> > > It is already recovered. We will investigate where we can extend the
> > > ressources. But some misusages (like requesting >1300 merge requests via 
> > > API
> > > on a big project, that in consequence run >1300 ci jobs, that...) can't be
> > > solved regardless on how many resources we add. 
> > Thanks for the reports from you and Bastian.  Thanks also for having
> > the energy and effort to deal with this kind of thing.  It's annoying
> > when a thing you're responsible for breaks because of foolish user
> > action, and then you have to scramble to fix it.
> 
> From what I know, this what not a "foolish user action" but an action
> by a dedicated maintainer who enabled salsa-ci for all packages
> ("projects") of a specific team; so they used a service advertised by
> the salsa and salsa-ci teams. That this service doesn't work as
> advertised or at least doesn't work for the amount of packages a
> medium-sized team might have is deplorable and needs some action but
> I don't see any reason for calling this action itself foolish.

All our services have somewhat limited ressources and need to work for all
developers. To be honest: I do expect from everyone, using any of our
(debian) services, to think before doing things like that. Be it sending a
few thousand mails to our mailing lists, creating a few thousand jobs on
salsa, uploading a few thousand packages, creating a few thousand bugs. 

Alex



signature.asc
Description: PGP signature

Re: salsa.debian.org partially down

[Alexander Wirt]

On Tue, 13 Aug 2019, Hector Oron wrote:

> Hello,
> 
> Missatge de Bastian Blank  del dia dt., 13 d’ag.
> 2019 a les 11:51:
> >
> > Hi folks
> >
> > salsa.debian.org is partially down for now.  Especially everything that
> > concerns Salsa CI.
> >
> > Someone decided to inject a few thousand CI jobs using Salsa CI
> > yesterday evening.  Since then the system is not longer at 50% load, but
> > at a 100%.  It turns out that the configured amount of concurrency in CI
> > builds can't be handled by the current available system resources.
> >
> > This now affects all user access to salsa.debian.org.  So we disabled
> > access to all the Salsa CI stuff for now, which will make everything
> > using it fail.
> >
> > We have to discuss first how we can go forward.
> 
> Those are very bad news. I hope that can be recovered soon. If you
> need more resources to be able to handle more jobs or longer timeouts,
> please let DPL know so more resources can be added.
It is already recovered. We will investigate where we can extend the
ressources. But some misusages (like requesting >1300 merge requests via API
on a big project, that in consequence run >1300 ci jobs, that...) can't be
solved regardless on how many resources we add. 

Alex
 

Re: how to handle upstream orig tarball with git-lfs reference files?

[Alexander Wirt]

On Mon, 12 Aug 2019, Andrej Shadura wrote:

> Hi,
> 
> On Sun, 11 Aug 2019 at 14:57, Daniel Leidert  wrote:
> >
> > Am Sonntag, den 11.08.2019, 07:26 +0200 schrieb Andrej Shadura:
> > > On Sun, 11 Aug 2019, 04:18 Drew Parsons,  wrote:
> > > > We have the policy of not pulling files from the internet at build time,
> > > > which is probably a good policy to maintain.  Does it mean we want to
> > > > configure salsa or some other part of debian infrastructure to provide a
> > > > git-lfs service?  Maybe salsa can already do it, in which case a HOWTO
> > > > on wiki.debian.org would be useful.
> 
> > > Salsa already supports git-lfs, it's just not enabled by default.
> 
> > Git LFS is actually enabled on all our projects without user interaction. 
> > IMHO
> > you are wrong.
> 
> I had to enable it just last week on one of the projects of mine.
It is available for every project, but it doesn't make sense to enable it
unconditionally on every project. We - the salsa admins - recommend using
git-lfs for big files. 

Alex
 

Re: Debian, so ugly and unwieldy!

[Alexander Wirt]

On Fri, 07 Jun 2019, Wookey wrote:

> On 2019-06-07 17:24 +0200, Adam Borowski wrote:
> > * CSD is still a thing.  No, your special program shouldn't get to ignore
> >   system theme, put controls in wrong order, miss some controls, not respond
> >   to minimize/etc if it's currently busy, etc.  Consistency not one-off
> >   designs.
> 
> What is CSD?
client side decoration: 
https://en.wikipedia.org/wiki/Client-Side_Decoration

Alex


signature.asc
Description: PGP signature

Re: Salsa migration from foo-guest to foo [was: Bits from the DPL (May 2019)]

[Alexander Wirt]

On Fri, 07 Jun 2019, Thomas Goirand wrote:

> On 6/5/19 4:08 PM, Norbert Preining wrote:
> > This should be
> > completely independent from what one can do on salsa.
> > So I propose that whatever one's level within Debian is, it should not 
> > change the status on salsa.
> 
> I also find it surprising that the "feature" from Alioth that one has to
> completely recreate everything from an account foo-guest to just foo.
> Can't this be addressed in another way? It's *very* annoying on both
> directions (ie: non-dd -> dd or dd -> non-dd).
We will probably start doing that when we have a proper usermanagement tool
for guests in place. 

Alex
 

Re: Bits from the DPL (May 2019)

[Alexander Wirt]

On Thu, 06 Jun 2019, Sam Hartman wrote:

> > "Bastian" == Bastian Blank  writes:
> 
> Bastian> Hi Sam
> Bastian> On Thu, Jun 06, 2019 at 11:57:41AM -0400, Sam Hartman wrote:
> >> However, it's a lot easier to get a foo-guest account on salsa
> >> than it is to get a foo guest account in Debian LDAP.
> 
> Bastian> A guest account in Debian LDAP does not get a Salsa
> Bastian> account, at least not an usable one.  Currently only users
> Bastian> in the Debian group are allowed.
> 
> No, but my understanding is that basically anyone on the internet can go
> sign up for foo-guest at salsa.
> 
> >> There are transitions like someone retiring from the project
> >> where we actually would be delighted if they continued to use
> >> salsa in some capacity.
> 
> Bastian> The largest technical problem with that is providing the
> Bastian> user with a valid e-mail address.  Apart from that we need
> Bastian> DSA to properly define states in LDAP.
> 
> OK, that's useful input.
> I do feel we're talking past each other here though.
> 
> Norbert and some other folks said they wanted salsa to behave
> differently.
> 
> Alex jumped in and said "salsa doesn't work that way."
> Sure, we all know that.
> And yet, salsa and really all of Debian can change if we want them to
> and the right we are willing to do the work.
No, I said why salsa works the way it works. If you want a special state for
"not so really disabled accounts" salsa isn't the right place to implement
that. 

Btw. nobody ever came to us and said "Hey, that account is disabled, are
there any options to behave differently". So the steps are: define how those
"not so really disabled" account should behave, implement them in udldap and
then we can adjust the syncer.

Alex



signature.asc
Description: PGP signature

Re: Bits from the DPL (May 2019)

[Alexander Wirt]

On Wed, 05 Jun 2019, Adrian Bunk wrote:

> On Wed, Jun 05, 2019 at 10:14:50AM -0400, Sam Hartman wrote:
> > > "Norbert" == Norbert Preining  writes:
> > 
> > Norbert> I would propose something else: Debian rights are defined
> > Norbert> by presence/absence of a GPG key in certain key rings. This
> > Norbert> should be completely independent from what one can do on
> > Norbert> salsa.  So I propose that whatever one's level within
> > Norbert> Debian is, it should not change the status on salsa.
> > 
> > Well, developers are also granted rights in the debian group on salsa,
> > and that is tied to whether you are currently a developer.
> 
> But personal rights (including own repositories) do not.
If a @debian.org account is disabled in udldap it gets of course disabled in
salsa. 

Alex

Re: Bits from the DPL (May 2019)

[Alexander Wirt]

On Thu, 06 Jun 2019, Andreas Tille wrote:

> On Wed, Jun 05, 2019 at 10:14:50AM -0400, Sam Hartman wrote:
> > > "Norbert" == Norbert Preining  writes:
> > 
> > Norbert> I would propose something else: Debian rights are defined
> > Norbert> by presence/absence of a GPG key in certain key rings. This
> > Norbert> should be completely independent from what one can do on
> > Norbert> salsa.  So I propose that whatever one's level within
> > Norbert> Debian is, it should not change the status on salsa.
> > 
> > Well, developers are also granted rights in the debian group on salsa,
> > and that is tied to whether you are currently a developer.
> 
> I fully agree with Norbert.  You might argue that a developer who was
> removed from the keyring could write a script and do some harm on all
> git repositories in the debian group to take some "revenge" for becoming
> expelled.  I see no practival relevance for such a scenario.  As far as
> I understood Norberts case it was not intended to block him from
> contributing - but removing his permissions on salsa made it very hard
> for him to contribute.
> 
> I do not have any idea whether there is an easy technical implementation
> for Norberts suggestion but I'm in favour of it.
The whole group is basically ldap controlled. And in fact salsa didn't
removed any permission. The account was disabled in LDAP and therefore
disabled on salsa (which makes perfectly sense in my eyes). So unless you
create a new account state in ldap I don't see any good solution for changing
the current behaviour. Of course we want to also disable @debian.org accounts
when they are disabled in (ud)ldap.

Alex
 

Tell me about your salsa experience

[Alexander Wirt]

Hi, 

I was invited to be a speaker at the drupal con to talk about the 
evolution of tooling in open source projects [1]. I will take part
in a panel together with other open source projects like Gnome
or Drupal, we talk about about the past - the tool we used, its history
and so on. Then we want to talk about the evolution of our tools, the
challenges and how the way we work changed together with the tool we
introduced. 

Thats where you come in, please tell me how tools like salsa, alioth, 
git, tracker and so on changed to way you work. I want to know everything,
the good, the bad and so on. 

Thanks in advance

Alex

P.S. I will be in Seattle from 6th april to 11th april, in Portland just for
the evening of the 11th. Next is nearby yosemite from 12th to 15th and at
least San Francisco from 15th to 22nd. If you want to meet for a beer, please
get in touch with me. I am also willing to give a talk about Debian and/or 
Salsa in Seattle or S.F.. 

[1] 
https://events.drupal.org/seattle2019/sessions/gathering-open-source-projects-discuss-evolving-their-tools


signature.asc
Description: PGP signature

Re: Removal of linux-base from jessie-backports broke Xen upstream CI

[Alexander Wirt]

On Thu, 14 Feb 2019, Ian Jackson wrote:

> Firstly, thanks for taking the time to read what I wrote.  (Thanks
> also for Sam for his helpful perspective.)
> 
> 
> Stepping back a bit, and firmly putting my `user' hat on:
> 
> My aim was to share my experience, because I guess the point of
> jessie-backports (and of much of what we do in Debian) is to help
> Debian's users.  In this case I was a user who had something go wrong,
> but I was in the unusually fortunate situation of being able (due to
> my personal skills, my support network, and my available time) to
> diagnose the problem and write up a report.
> 
> I did this because I thought it would be worthwhile seeing if Debian
> thought there was anything here to be learned, about how to better
> support some of its users.  If those responsible for these services
> don't think so, then, well, as users we get what we pay for.
> 
> If those responsible for -backports don't value this kind of feedback
> then of course next time I can not write it up as a learning
> opportunity for Debian.  I can just work around it instead.
So let me rephrase as an admin. You - the user - ignored three announcements
about the deprecation and the change of the metapackage handling of the
linux-image package, but you want us to send more even more announcements to
get you better informed? I don't get it, what distinguishes those explicit
removal announcements from the other announcements you ignored? 

Alex - backports ftpmaster 


signature.asc
Description: PGP signature

Re: Removal of linux-base from jessie-backports broke Xen upstream CI

[Alexander Wirt]

On Wed, 13 Feb 2019, Ian Jackson wrote:

> Alexander Wirt writes ("Re: Removal of linux-base from jessie-backports broke 
> Xen upstream CI"):
> > Jessie backports doesn't exist anymore. For some time now. It is already on
> > its way to archive.d.o. 
> 
> Thanks are due to to folks on #debian-uk who pointed out this
> announcement (from June!) that I missed;
>   https://lists.debian.org/debian-backports-announce/2018/07/msg0.html
And https://lists.debian.org/debian-backports/2018/06/msg00052.html 
and https://lists.debian.org/debian-backports/2017/06/msg00055.html

Alex


signature.asc
Description: PGP signature

Re: Removal of linux-base from jessie-backports broke Xen upstream CI

[Alexander Wirt]

On Wed, 13 Feb 2019, Ian Jackson wrote:

> Introduction
> 
> 
> I would like to recount a situation.  I'm not sure where, if anywhere,
> the root bug(s) lie, but I am inclined to say that a big part of the
> problem was a change to the contents of jessie-backports.  I would be
> interested to hear what the backports team and ftpmaster have to say;
> in particular, if anyone knows the answers to my questions below.
> 
> My tentative conclusions are that:
> 
> 1. Packages should not be removed from foo-backports just because a
> similar package is in foo-security, because there are situations where
> a host may have been relying on the package being in foo-backports and
> a similar (even, newer) package being in foo-security is not
> sufficient.
> 
> 2. Cruft removal in stable releases, including in -backports, should
> perhaps be done with care/caution/announcement or something.
Jessie backports doesn't exist anymore. For some time now. It is already on
its way to archive.d.o. 

And I don't think we should inform everybody for a simple maintenance task
like crufting. 

Alex

Re: Proposal: Repository for fast-paced package backports

[Alexander Wirt]

On Wed, 26 Dec 2018, Dominik George wrote:

> > >If there are other issues to solve than the lifespan of the package
> > >version, they must be solved in another way.
> > 
> > I agree with you, it is the best outcome. But when people with power
> > (-backports ftp masters) are not willing to consider it, we have to go
> > with plan B, which is less than ideal, but can move things forward.
> 
> Plan B in this case are PPAs. If you want to engage in that idea, please
> do separately from the -volatile idea.
> 
> > >> As I said, gitlab was not about manpower. This new repo is completly
> > >against
> > >> our vision of what backports is. Therefore we don't want it within
> > >the
> > >> backports suite. 
> > >
> 
> > If people argue both ways, how can we answer? Either it adds more work
> > for -backports team or it does not. Some people say its not fair to
> > add more load while ftp masters say its not about load.
> 
> As Alex laid out, it's mostly just the -backports team handling the NEW
> queue. So all of this really is independent from -backports, if another
> NEW queue is added (which I do not think is the best idea, but still
> possible).
> 
> But, I do not think it is possible to start -volatile completely
> independently. I am pretty certain there is enough man power to handle
> it as a new suite, but on the other hand I am also certain there is not
> enough manpower to operate a compelte set of seperate services for it.
as said, we are also guests on the ftpmaster services. They are the people to
ask. The NEW queue is just a minor detail of a suite. 

Alex



signature.asc
Description: PGP signature

Re: Proposal: Repository for fast-paced package backports

[Alexander Wirt]

On Wed, 26 Dec 2018, Pirate Praveen wrote:

> 
> 
> On 2018, ഡിസംബർ 26 10:15:35 PM IST, Dominik George  
> wrote:
> >No. The dpendencies of gitlab not being accepted into backports right
> >now is an entirely different issue. I am repeating myself: This
> >proposal
> >is not intended to ease the life of maintainers whose packages qulify
> >for -backports. The only difference between -backports and -volatile in
> >this draft proposal is that -volatile can take packages that are not in
> >testing due to the exact one reason that hey have a shorter lifespan.
> >No
> >single other thing qualifies a package for -volatile if it is not
> >qualified for -backports.
> >
> >If there are other issues to solve than the lifespan of the package
> >version, they must be solved in another way.
> 
> I agree with you, it is the best outcome. But when people with power 
> (-backports ftp masters) are not willing to consider it, we have to go with 
> plan B, which is less than ideal, but can move things forward.
> 
> >On Wed, Dec 26, 2018 at 04:32:28PM +0100, Alexander Wirt wrote:
> >> As I said, gitlab was not about manpower. This new repo is completly
> >against
> >> our vision of what backports is. Therefore we don't want it within
> >the
> >> backports suite. 
> >
> 
> If people argue both ways, how can we answer? Either it adds more work for 
> -backports team or it does not. Some people say its not fair to add more load 
> while ftp masters say its not about load.
> 
> If it does not add extra load, then I don't see why it can be kept out of 
> -backports when it qualifies except for being a dependency of -volatile. They 
> say it does not match with their vision. So what option is left for us? We 
> have to take their word for it and move forward without inconveniencing them. 
> I don't think -backports ftp masters is going to accept this proposal (from 
> the responses we already received), so I can live with all dependencies in 
> -volatile.
Jftr, we never said anything about dependencies. If it qualifies for
backports, I don't see any reason for not having those deps in backports. We
never questioned that topic. If it qualifies: great. If not, please don't
upload it. 

A package qualifies for backports if: 

- it adds new features
- wasn't available before
- is in testing
- will receive support for the lifetime of the backports suite

so things like npm are perfectly fine for backports. And we never said
anything for libs, even if they are "standalone" (nothing in backports is
using those libs). 

The main problem with gitlab was: from our perspective several hundred
packages only had one uploader (to backports, other suites don't count) and
we wanted to minimize the risk of being alone with hundreds of unmaintained
backports. 

We solved that problem (by getting more people responsible for the backports)
and accepted it. 

Alex
 

Re: Proposal: Repository for fast-paced package backports

[Alexander Wirt]

On Wed, 26 Dec 2018, Dominik George wrote:

> > I don't want backports to contain things are are not suited for a
> > release.
> 
> That's why we are doing all this. It is NOT about anything to backports.
> It is about adding something new that uses the same RULES as backports,
> with a slight diversion, and thus can also make use of infrastructure
> already there for backports. Neither being economic with manpower and
> machines nor trying to be a good neighbour by adhering to the same rules
> means to change or add anything to -backports.
And I said I think it should start independently to prove its worth the work. 
And it isn't backports infrastructure. It is ftpmaster's, we are just users.
We can't even add anything, even if we want to. The only things we control
are the NEW queue of the backports-suites ( a new suite with have its own
queue) and the website (which also doesn't fit for the new suite). So imho
addressing this as a backports topic is just wrong. 

Alex



signature.asc
Description: PGP signature

Re: Proposal: Repository for fast-paced package backports

[Alexander Wirt]

On Wed, 26 Dec 2018, Dominik George wrote:

> Hi,
> 
> On Wed, Dec 26, 2018 at 03:05:55PM +0100, gregor herrmann wrote:
> > (Can we keep this on one mailing list, please? /me restricts this to
> > -devel)
> 
> No. This has the potential of keeping people who are directly impacted
> by this proposal out of the loop.
> 
> > And besides that, I think the more universal answer is
> > bikesheds/PPAs/you-name-it instead of yet-another-suite.
> 
> Absolutely not. It might be an answer, but to an entirely different
> question. This proposal is about providing packages under the same
> rules, policies and QA as any other package in Debian, built in the same
> trustworthy manner. This is something a PPA does not do.
> 
> To stay with the gitlab example: I would very much like to see some
> people (including the company I work at, two organisations I am
> otherwise involved with,…) use packages from Debian. This is mostly
> about trust - it is a very useful policy to limit the entities to trust
> for software distribution if you run production systems, especially when
> they handle third-party data. Debian is such an entity - while there are
> many people working in it, it is a body with defined procedures and
> standards that can be relied upon. Debian telling users to add a PPA to
> their trusted entities that is managed by some person alone, be they a
> DD or not, defeats this entirely.
> 
> On Wed, Dec 26, 2018 at 08:29:17PM +0530, Pirate Praveen wrote:
> > The -backports team does not want the dependencies of gitlab to be in
> > -backports even though it meets the criteria for backports. So we will
> > end up adding it to volatile. Now if some one else wants the same in
> > -backports, they will have to repeat the process.
> > 
> > Take nodejs or npm for example, which I backported now. In buster the
> > -backports team does not want it in backports if I'm doing it for
> > gitlab, even though they satisfy the requirement for -backports. So we
> > will end up uploading these to volatile, if someone else wants it in
> > -backports, they will have to do it again.
> > 
> > It is one way (volatile can use -backports, but -backports can't use
> > volatile). I'm fine with that if people don't want our work for volatile
> > not added to -backports.
> > 
> > Dominik,
> > 
> > I think we can go ahead with volatile as separate suite and take
> > packages from -backports if exist but add all new dependencies to -volatile.
> > 
> > This,
> > 
> > "Dependencies on other packages in volatile should be avoided if
> > possible. Especially, dependencies of the package that also need
> > backporting must not be added to volatile just because they are
> > dependencies — every dependency that is needed to be backported to
> > support the volatile package must be considered on its own and in all
> > but unprobable edge cases be maintained as a formal backport. Obviously,
> > the unprobable edge case occurs when the package depends on another
> > package that also fully qualifies for volatile, as described above."
> > 
> > should be changed to,
> > 
> > "Dependencies of the package that also need backporting must be added to
> > volatile."
> 
> No. The dpendencies of gitlab not being accepted into backports right
> now is an entirely different issue. I am repeating myself: This proposal
> is not intended to ease the life of maintainers whose packages qulify
> for -backports. The only difference between -backports and -volatile in
> this draft proposal is that -volatile can take packages that are not in
> testing due to the exact one reason that hey have a shorter lifespan. No
> single other thing qualifies a package for -volatile if it is not
> qualified for -backports.
And this is also solved. I emptied the NEW queue two or three days ago. If
there are dependencies missing the backports wasn't tested, which sucks. 

> If there are other issues to solve than the lifespan of the package
> version, they must be solved in another way.
> 
> On Wed, Dec 26, 2018 at 04:32:28PM +0100, Alexander Wirt wrote:
> > As I said, gitlab was not about manpower. This new repo is completly against
> > our vision of what backports is. Therefore we don't want it within the
> > backports suite. 
> 
> Alexander, please don't get me wrong, but have you read the full
> proposal by now and considered it, independent of the gitlab story? I am
> pretty certain you did not did that yesterday before starting to object
> it - not because of your argumentation, but because reading,
> understanding, considering and challenging it and then writing your
> reply is s

Re: Proposal: Repository for fast-paced package backports

[Alexander Wirt]

On Wed, 26 Dec 2018, Pirate Praveen wrote:

> 
> 
> On 2018, ഡിസംബർ 26 2:16:07 AM IST, Dominik George  
> wrote:
> >Heisann, alle sammen,
> >
> >as announced in the recent thread about maintaining, I hereby propose a
> >repository that allows making “backports” of packages available to
> >users
> >of the stable distribution, if those packages cannot be maintained in
> >testing and backported in the usual way. If you are interested in what
> >lead up to that, please see bug #915050. I will give a short summary of
> >it here.
> >
> >
> >Reasons for having a special place for some packages
> >
> >
> >(You may want to skip this part if you are familiar with the
> >situation.)
> >
> >As all developers know (but passers-by may not), for software to enter
> >the Debian archive, it is always uploaded to the unstable distribution,
> >then migrates to testing (hopefully ;)), which is at some point
> >snapshot
> >and made the new stable release. From there on, maintainers have two
> >obligations: Firstly, keep the package in stable good and secure, e.g.
> >by uploading security fixes for it once they become available upstream,
> >or even backport fixes themselves. Secondly, provide the package in
> >unstable with updates and ensure its migration, to keep it ready for
> >the
> >next stable release.
> >
> >Now, for some software packages, this process is problematic, because
> >upstream may have another idea about software lifecycles. Concerning
> >the
> >GitLab example, upstream provides security fixes for three months for
> >their stable releases. Backporting fixes from newer versions is very
> >hard or impossible because the massive amounts of changes to the
> >software in every new versions. This is something that also affects
> >other packages, like Mozilla Firefox, which has a firefox package in
> >unstable, and a separate firefox-esr package, with the ESR version of
> >Firefox. Only the latter migrates to testing.
> >
> >Users of Debian honour it for its stability, but as an agile software
> >lifecycle is adapted by more and more very popular software packages,
> >not being able to install these packages in the trusted, well-known
> >fashion through the official apt repositories is becoming more and more
> >of a drawback.
> >
> >It can easily be assumed that the normal release and maintenance cycle
> >of Debian stable will not change, which is very good, so we should find
> >a way to still provide such software as described above to users.
> >
> >
> >Why backports is not enough
> >===
> >
> >This also is well-known, but for completeness: Formal backports in
> >stable-backports are required to be direct backports from testing, and
> >are a stepping stone within the upgrade from stable to stable+1. Thus,
> >a
> >version of a package that is not in testing can never be in
> >stable-backports.
> >
> >
> >Name of the new repository
> >==
> >
> >In the past, the name “volatile” was used for a similar repository, but
> >with a different scope (limited to data packages for things like virus
> >scanners). I will thus use the working title volatile throughout this
> >proposal, although this may change.
> >
> >Other ideas: fastlane, unsupported
> >
> >(Please feel free to add other ideas.)
> >
> >
> >Requirements for a package to go into stable-volatile
> >=
> >
> >The new volatile proposal is not intended to ease life for package
> >maintainers who want to bypass the migration and QA requirements of the
> >regular stable lifecycle, so special need must be taken to ensure only
> >packages that need it go into volatile. I want to summarise the
> >requirements like so:
> >
> >- The package must be maintained in unstable, like every other package.
> > - The package must not be in testing, and care must be taken for the
> >   package not to migrate to testing.
> > - Regular maintenance for the lifetime of stable must be impossible
> >   or unnecessarily hard, and this requirement should be assessed in
> >   a verifiable manner, e.g. referring to upstream’s lifecycle model.
> > - There must be notable need for the package. Like for backports, user
> >   requests might be an indicator.
> > - Should the package be removed from unstable, it must also be removed
> >   from volatile.
> > - Should the package begin to migrate to testing again, it must
> >   be moved to stable-backports.
> >
> >Before starting to maintain a volatile package, the maintainer shall
> >seek consent (or doubt) on debian-devel.
> >
> >
> >Building packages and package dependencies
> >==
> >
> >Packages for volatile are built the same way as formal backports, only
> >that the source is taken from unstable rather than testing. In
> >particular:
> >
> > - Changes shall be kept as small as possible.
> > - The package is rebuilt against stable.
> >- The package may depend 

Re: Proposal: Repository for fast-paced package backports

[Alexander Wirt]

On Tue, 25 Dec 2018, Dominik George wrote:

> > We already told you to build your own repo.
> 
> You should probably start with identifying the senders of mail
> correctly ☺. I am not the gitlab maintainer (and will never be).
https://lists.debian.org/debian-backports/2018/12/msg00028.html

This wasn't about gitlab. 

> 
> > Imho you should start the same way backports started - outside of
> > debian.
> > Prove that it works and integrate into Debian later.
> 
> I would agree with you if it were a big change - however, the proposal
> has a very low impact, if not none at all, on existing stuff. In
> contrast to what you seem to believe (accuse people of…), this proposal
> is about helping Debian as a whole, not forcing a certain package into
> the distribution. gitlab only serves as an example of why it is useful.
> The Debian infrastructure already supports everything that is needed to
> implement this, and starting with parallel infrastructure would probably
> mean that it will fail because this requires a single person spending
> time and money to maintain the infrastructure (which is otherwise
> already there), and to make it really work, this is a low (think of
> buildds, etc.).
> 
> In any case, I do not see why you would fight the fact that someone
> makes a detailed proposal. A proposal can be accepted or denied, of
> course, but your tone implies you think noone should have made the
> proposal i nthe first place.
> 
> Please don't fight people wanting to help based on your opinion about a
> prior case around gitlab.
I don't fight against it. I just want to keep it away from backports, thats
not the same. 

Alex



signature.asc
Description: PGP signature

Re: Proposal: Repository for fast-paced package backports

[Alexander Wirt]

On Tue, 25 Dec 2018, Dominik George wrote:

> Heisann, alle sammen,
> 
> as announced in the recent thread about maintaining, I hereby propose a
> repository that allows making “backports” of packages available to users
> of the stable distribution, if those packages cannot be maintained in
> testing and backported in the usual way. If you are interested in what
> lead up to that, please see bug #915050. I will give a short summary of
> it here.
> 
> 
> Reasons for having a special place for some packages
> 
> 
> (You may want to skip this part if you are familiar with the situation.)
> 
> As all developers know (but passers-by may not), for software to enter
> the Debian archive, it is always uploaded to the unstable distribution,
> then migrates to testing (hopefully ;)), which is at some point snapshot
> and made the new stable release. From there on, maintainers have two
> obligations: Firstly, keep the package in stable good and secure, e.g.
> by uploading security fixes for it once they become available upstream,
> or even backport fixes themselves. Secondly, provide the package in
> unstable with updates and ensure its migration, to keep it ready for the
> next stable release.
> 
> Now, for some software packages, this process is problematic, because
> upstream may have another idea about software lifecycles. Concerning the
> GitLab example, upstream provides security fixes for three months for
> their stable releases. Backporting fixes from newer versions is very
> hard or impossible because the massive amounts of changes to the
> software in every new versions. This is something that also affects
> other packages, like Mozilla Firefox, which has a firefox package in
> unstable, and a separate firefox-esr package, with the ESR version of
> Firefox. Only the latter migrates to testing.
> 
> Users of Debian honour it for its stability, but as an agile software
> lifecycle is adapted by more and more very popular software packages,
> not being able to install these packages in the trusted, well-known
> fashion through the official apt repositories is becoming more and more
> of a drawback.
> 
> It can easily be assumed that the normal release and maintenance cycle
> of Debian stable will not change, which is very good, so we should find
> a way to still provide such software as described above to users.
> 
> 
> Why backports is not enough
> ===
> 
> This also is well-known, but for completeness: Formal backports in
> stable-backports are required to be direct backports from testing, and
> are a stepping stone within the upgrade from stable to stable+1. Thus, a
> version of a package that is not in testing can never be in
> stable-backports.
> 
> 
> Name of the new repository
> ==
> 
> In the past, the name “volatile” was used for a similar repository, but
> with a different scope (limited to data packages for things like virus
> scanners). I will thus use the working title volatile throughout this
> proposal, although this may change.
> 
> Other ideas: fastlane, unsupported
> 
> (Please feel free to add other ideas.)
> 
> 
> Requirements for a package to go into stable-volatile
> =
> 
> The new volatile proposal is not intended to ease life for package
> maintainers who want to bypass the migration and QA requirements of the
> regular stable lifecycle, so special need must be taken to ensure only
> packages that need it go into volatile. I want to summarise the
> requirements like so:
> 
>  - The package must be maintained in unstable, like every other package.
>  - The package must not be in testing, and care must be taken for the
>package not to migrate to testing.
>  - Regular maintenance for the lifetime of stable must be impossible
>or unnecessarily hard, and this requirement should be assessed in
>a verifiable manner, e.g. referring to upstream’s lifecycle model.
>  - There must be notable need for the package. Like for backports, user
>requests might be an indicator.
>  - Should the package be removed from unstable, it must also be removed
>from volatile.
>  - Should the package begin to migrate to testing again, it must
>be moved to stable-backports.
> 
> Before starting to maintain a volatile package, the maintainer shall
> seek consent (or doubt) on debian-devel.
> 
> 
> Building packages and package dependencies
> ==
> 
> Packages for volatile are built the same way as formal backports, only
> that the source is taken from unstable rather than testing. In
> particular:
> 
>  - Changes shall be kept as small as possible.
>  - The package is rebuilt against stable.
>  - The package may depend on packages in stable, stable-backports or 
> stable-volatile.
> 
> Dependencies on other packages in volatile should be avoided if
> possible. Especially, dependencies of the package that 

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

[Alexander Wirt]

On Tue, 18 Dec 2018, Pirate Praveen wrote:

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

Alex



signature.asc
Description: PGP signature

Accepted keepalived 1:2.0.10-1 (source) into unstable

[Alexander Wirt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 30 Nov 2018 21:20:05 +0100
Source: keepalived
Binary: keepalived
Architecture: source
Version: 1:2.0.10-1
Distribution: unstable
Urgency: high
Maintainer: Alexander Wirt 
Changed-By: Alexander Wirt 
Description:
 keepalived - Failover and monitoring daemon for LVS clusters
Closes: 810347 830196 900260 902978 909697 914393
Changes:
 keepalived (1:2.0.10-1) unstable; urgency=high
 .
   * [3b99bf9] Update vcs headers to salsa
   * [f697779] New upstream version 2.0.2
   * [c97cc19] Enable dbus instance and json output support
   * [27c6d55] syslog is now socket activated
   * [7e2267b] Move to dh11
   * [d0bf9db] there is not systemd sequence in dh11
   * [903a5a0] dh-autoreconf dep is not needed anymore with dh11
   * [c4996bd] Priority extra got replaced by optional
   * [822da17] Remove obsolete patches
   * [1c36cdc] New upstream version 2.0.10
 - Fix overflow in extract_status_code (CVE-2018-19115)
   Closes: #914393, #900260
 - Improve garp refresh handling (Closes: #810347)
 - Improve config parser (Closes: #909697)
   * [990c014] Improve keepalived service (Closes: #902978, #830196)
Checksums-Sha1:
 c611f5fb693d49f2aaac1ef1d6d7ebdfcd56b314 2054 keepalived_2.0.10-1.dsc
 c0b62f6d20a4a322e4bd67b4ae447bb842c28c4c 927631 keepalived_2.0.10.orig.tar.gz
 5e3bc91f4bcbb39067e8a4283c82cb14f09896ba 10124 
keepalived_2.0.10-1.debian.tar.xz
 ec9e27ed8ea868d1e35118fb6a81027cc4a0f6e8 7638 
keepalived_2.0.10-1_amd64.buildinfo
Checksums-Sha256:
 e9b03181b770cee745d6b27e9827b20d1e241b73cd8193d50d872bafa09006ba 2054 
keepalived_2.0.10-1.dsc
 40e0e55afed9ca313d621a9c5878579696fafb5504dab521aadaf20ba6e7f597 927631 
keepalived_2.0.10.orig.tar.gz
 882e4d76ec1dea0aa865f092956ced5be0950e419681700ad70162635d230c05 10124 
keepalived_2.0.10-1.debian.tar.xz
 dfc65817bd9ead59fee18bf0adfa37b75e7fb024b4c7b4985cb1ad1d4762a0d9 7638 
keepalived_2.0.10-1_amd64.buildinfo
Files:
 ffc64cfd50834d6025f571617ff7131d 2054 admin optional keepalived_2.0.10-1.dsc
 ac93d7eb5b69a9fbf7494fcf27b39ccf 927631 admin optional 
keepalived_2.0.10.orig.tar.gz
 5196b8fba5962d72eda10925c88c7f36 10124 admin optional 
keepalived_2.0.10-1.debian.tar.xz
 aef5c84d1e23a54ea8887639aba7aa2e 7638 admin optional 
keepalived_2.0.10-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEbjlmweHRXblz0FtJHkX4yp3iOxYFAlwBnx8ACgkQHkX4yp3i
OxYEEA//dEXQ7ny9CCaadLccLkbkkAkSss0JvxOYl3eTQFWh+neIwC8Nv/zbGJpF
cG4Mc5J1kTMAlv96gQq7JzdKY/qEc0z6LY+gi1oYLX6Um6/tO9cb4+dc/tz/PGY7
9l9+TfToByJ1J1T1biBv7T2vIwvF9umRctRmH5Sx7hBPSe+J/aut0zl8FgS+ezH6
DPPCL6Suwxiy8g9vjMdAcPKvHNyAq3ubW5YXKVhEvy+M2g4Q2Q7eqEsnQk0Odsb+
ArfyXPo4n7+v2zVZsQU9hdYObz9TFXfvOGAsXyPdcTCtyBkAdL7NKjBeZXhHfQ3X
lJfEcz4fFjTjZRzD0w3BT4h7BOjvKEzClB4sLLESztsQkcPb2JjpZ/J3ZJhEN74n
E1m3vhLku67RRY1cqsfVihL+vLa103e49aOp3505LSegmZH/oOx6sa8Pz0cBAJzk
dwy5p7jCcbPp6oqjTSzRUxeMI4ksBhClAi3x63eECErWOLANGt0ov6AIr6RIZetR
LIhk66qwZWT0iAEhw0LEWF59vSJwbdtQZOqHOnojZ7lYZMTEVn3fdYaNu01JuM2L
yKQ+mjOVyw6zmFkftiqtcNv+1foWJkTkOk4+1lSrh/lOxOI8mS0Qws+ZfSl74X4Z
hf4VFSULlEcyHpw5hz+nfAAzI/OmuggdHLnV5924osAUI71as5I=
=IpF7
-END PGP SIGNATURE-

Re: I resigned in 2004

[Alexander Wirt]

On Sun, 11 Nov 2018, Adam Borowski wrote:

> On Sun, Nov 11, 2018 at 07:50:55PM +0100, Vincent Bernat wrote:
> > Then, they should click on the button they are asked to click. This
> > takes far less time than a long (and discourteous) rant.
> 
> Yeah... you walk out without a word, and are upset if people still care
> about you?  MW acted like an ass here.
> 
> > I know you have good intention in trying to improve the MIA process, but
> > I think[*] this sends the wrong message to the current volunteers: you
> > can act as professionally as you can, you will still get criticism from
> > a few people on some minor details. Can we spare our volunteers more
> > carefully than rude people?
> 
> That's expected.  The work of a mortician (MIA is basically this) is
> unpleasant, and having people lash at you just for doing it is the norm
> rather than an exception.
> 
> I see no way to make Mattia's work safe from being yelled at.  Anything we
> say here won't get to people MIA interacts with, and if any of us gets
> MIA-but-alive, we'd long since forgotten how we're supposed to behave
> (as apparently customs are different at wherever MW worked at these years).
> So I hope you'll grit your teeth and keep going.  You may end up as grumpy
> as formorer -- but, notably, he still hasn't stopped his thankless unpaid
> work.  Yes, every time you contact him about a list issue you get a reply
> in a tone so uncheery it can sour the milk in a cow, but what's admirable
> is that he _keeps getting shit done_.
I am not nearly as grumpy as you think. I usually don't have much time, which
is the reason for my answers often being as short as possible. There is also
the language barrier of "german english" that sounds more rude than english
spoken by a native. 

I apologize if my answers sound more rude than they should.

Alex



signature.asc
Description: PGP signature

Re: salsa irker bot moved to ssl

[Alexander Wirt]

On Thu, 23 Aug 2018, Raphael Hertzog wrote:

> On Thu, 23 Aug 2018, Alexander Wirt wrote:
> > > A simple SQL update query would save us a lot of time. Thank you for
> > > considering it.
> > Sure, do you have the query? And please ensure not to affect bots
> > running on other networks. 
> 
> I don't have any gitlab instance where to make test so this is untested
> and based on some output provided by Pierre-Elliot Bécue. But I believe
> that this should do the trick.
> 
> UPDATE services SET properties = REPLACE(properties, 
> 'irc://irc.oftc.net:6697', 'ircs://irc.oftc.net:6697')
> WHERE properties LIKE '%ruprecht.snow-crash.org%' and type = 'IrkerService';
> 
> Run it in a transaction and check the result on some sample entries before
> and after the update command and commit if you are happy.
> 
> properties seems to be JSON data in a text field and it contains the
> IRC URI multiple times.
done, thanks. Please check in your settings if all is fine now. 

Alex



signature.asc
Description: PGP signature

Re: salsa irker bot moved to ssl

[Alexander Wirt]

On Thu, 23 Aug 2018, Raphael Hertzog wrote:

Hi,

> On Sun, 29 Jul 2018, Alexander Wirt wrote:
> > in the face of the current spam attacks I implemented CertFP for my 
> > irker instance. I also updated the default irc link in gitlab. However,
> > it is possible that every project using the bot has to migrate the server
> > setting to ssl. So if you miss messages from salsa bot, please check that 
> > you
> > use ircs://irc.oftc.net:6697/ as server setting in the irker integration.  
> 
> Can't you do a global update in the gitlab database to replace the old
> default value with the new default value ?
> 
> I just noticed that we're lacking notifications for most of our packages
> in the pkg-security-team and the setup script we used[1] does not include
> the IRC URI explicitly so it would have to be fixed first and then I would
> have to rerun it on all our repositories.
> 
> A simple SQL update query would save us a lot of time. Thank you for
> considering it.
Sure, do you have the query? And please ensure not to affect bots
running on other networks. 

Alex


signature.asc
Description: PGP signature

Re: Specs? Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)

[Alexander Wirt]

On Mon, 20 Aug 2018, Jeremy Stanley wrote:

> On 2018-08-20 20:05:42 +0200 (+0200), Alexander Wirt wrote:
> > On Mon, 20 Aug 2018, Thomas Goirand wrote:
> [...]
> > > Could you please at least define what is "some of the large data stores"
> > > and explain where it is configured in Gitlab? A possible pointer to the
> > > Gitlab documentation would probably help as well.
> > I find it very frustrating that you expect us to tell you where the docs 
> > are. 
> > However: 
> > 
> > https://docs.gitlab.com/ee/administration/repository_storage_paths.html
> > https://docs.gitlab.com/ee/workflow/lfs/lfs_administration.html#storing-lfs-objects-in-remote-object-storage
> > https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template#L176
> > https://salsa.debian.org/salsa/salsa-ansible/compare/e709949d0e174f9503b757c95cebee79f0ffe9b0...aafc7392e90efc21fa7e1858eee214029b29764c
> > 
> > its all there. 
> 
> Part of the open-core challenge I'm afraid. I already spoke with one
> "cloud" service provider last week who was willing to follow up to
> this thread with an offer to donate whatever storage types are
> needed, but we couldn't find documentation explaining supported
> storage options for Gitlab *CE* (note the "ee" in those
> documentation URLs, they're the same ones I already found). Is it to
> be assumed, generally, that Gitlab's Enterprise Edition
> documentation is also appropriate for Community Edition deployments?
https://docs.gitlab.com/ce/administration/repository_storage_paths.html

if you can replace ee with ce in the url it is also valid for ce. 
jftr afaik gitlab uses fog[1] for cloud storage, maybe that knowledge helps. 

Alex

[1] https://github.com/fog/fog


signature.asc
Description: PGP signature

Re: Specs? Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)

[Alexander Wirt]

On Mon, 20 Aug 2018, Thomas Goirand wrote:

> On 08/20/2018 11:40 AM, Alexander Wirt wrote:
> > On Mon, 20 Aug 2018, Ulrike Uhlig wrote:
> > 
> >> Hi!
> >>
> >> Bastian Blank:
> >>> On Sat, Aug 18, 2018 at 11:34:53PM +0200, Thomas Goirand wrote:
> >>>> Ok, I'm getting in touch with the DSA team to see how it can be done.
> >>>> Let's see first if we have hardware, and then how I can help for the
> >>>> setup and maintenance.
> >>>
> >>> If you want to do something, please show us the plan _before_ you are
> >>> implementing anything.  We have to vet that it is actually usable for
> >>> the purpose.  So just running in one direction does not help your case.
> >>
> >> Has the Salsa team redacted specs prior to implementing the current
> >> cloud storage solution? If yes, where can these specs be found?
> >> If you haven't redacted such specs, would you be willing to provide
> >> those somewhere, even in a keywordish manner? Otherwise, is there any
> >> technical documentation (or as a fallback: code & manifests) about this
> >> implementation publicly accessible?
> >>
> >> Having such documents might help avoid running in the wrong direction
> >> and would also allow to gather more overall insight.
> > No, but gitlab is open source, you should find all the specs you need in the
> > docs. 
> > 
> > Alex
> 
> Alex,
> 
> We do run a Gitlab instance at $work, so I may be able to try on a local
> setup before affecting all of Debian. However, I'd appreciate a bit of
> pointers. I've asked numerous questions, and so far got zero answer.
> 
> Since you've configured it, you probably know where its done. Having a
> quick look at the documentation over here:
> https://docs.gitlab.com/ce/administration/
> 
> I haven't find in the TOC something that looks relevant.
> 
> The only info I have from you is:
> 
> > We will also start moving some of the large data stores with public
> > accessible files off to Google Cloud storage.  Using an external
> > storage allows us to store a much larger amount of data in our GitLab
> > instance. All access to it will be proxied, without providing user
> > identifying data to the storage provider.
> 
> Could you please at least define what is "some of the large data stores"
> and explain where it is configured in Gitlab? A possible pointer to the
> Gitlab documentation would probably help as well.
I find it very frustrating that you expect us to tell you where the docs are. 
However: 

https://docs.gitlab.com/ee/administration/repository_storage_paths.html
https://docs.gitlab.com/ee/workflow/lfs/lfs_administration.html#storing-lfs-objects-in-remote-object-storage
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template#L176
https://salsa.debian.org/salsa/salsa-ansible/compare/e709949d0e174f9503b757c95cebee79f0ffe9b0...aafc7392e90efc21fa7e1858eee214029b29764c

its all there. 

Alex
 

Re: Specs? Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)

[Alexander Wirt]

On Mon, 20 Aug 2018, Ulrike Uhlig wrote:

> Hi!
> 
> Bastian Blank:
> > On Sat, Aug 18, 2018 at 11:34:53PM +0200, Thomas Goirand wrote:
> >> Ok, I'm getting in touch with the DSA team to see how it can be done.
> >> Let's see first if we have hardware, and then how I can help for the
> >> setup and maintenance.
> > 
> > If you want to do something, please show us the plan _before_ you are
> > implementing anything.  We have to vet that it is actually usable for
> > the purpose.  So just running in one direction does not help your case.
> 
> Has the Salsa team redacted specs prior to implementing the current
> cloud storage solution? If yes, where can these specs be found?
> If you haven't redacted such specs, would you be willing to provide
> those somewhere, even in a keywordish manner? Otherwise, is there any
> technical documentation (or as a fallback: code & manifests) about this
> implementation publicly accessible?
> 
> Having such documents might help avoid running in the wrong direction
> and would also allow to gather more overall insight.
No, but gitlab is open source, you should find all the specs you need in the
docs. 

Alex

Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)

[Alexander Wirt]

On Sat, 18 Aug 2018, Thomas Goirand wrote:

> On 08/18/2018 07:42 AM, Alexander Wirt wrote:
> >> I also don't understand why we're not attempting to build a Ceph cluster
> >> at UBC. Why not?
> > go ahead. if it works well we can switch to it. 
> > 
> > Alex
> 
> Ok, I'm getting in touch with the DSA team to see how it can be done.
> Let's see first if we have hardware, and then how I can help for the
> setup and maintenance.
Of course we also need docker. You will have to ensure that everythings work
with gitlab, that its performant enough and you will have to maintain it.
Otherwise we won't switch. 

Alex

Re: Notification of merge requests on Salsa

[Alexander Wirt]

On Sat, 18 Aug 2018, Rene Engelhard wrote:

> Hi,
> 
> On Fri, Aug 17, 2018 at 11:13:11PM -0400, Jacob Adams wrote:
> > I’m sure I’m not the only one to have missed a merge request for a while 
> > thanks to the lack of notifications, but also we don’t want DDs inboxes 
> > flooded with every merge request in the Debian group. 
> > 
> > My concern is that newcomers will have their merge requests ignored when 
> > maintainers are not emailed. I see no workable solution as yet, so I’ll 
> > have to look more into this and come back to this thread when I find one. 
> 
> One workaround is
> 
> $ reportbug 
> Severity: whatever
> Tags: patch
> 
> (and mention the PR)
> 
> Did that in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904457
> for
> https://salsa.debian.org/installer-team/tasksel/merge_requests/2
> (where I thought this happened. no idea whether installer-team has MR
> notifications on or not.)
As said: a team can't enforce that. Its a user setting. 

alex
 

Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)

[Alexander Wirt]

On Fri, 17 Aug 2018, Thomas Goirand wrote:

> On 08/17/2018 10:52 AM, Andrey Rahmatullin wrote:
> > On Fri, Aug 17, 2018 at 08:27:00AM +, Ulrike Uhlig wrote:
> >> While I understand the simplicity of using $company's cloud storage, I'd
> >> rather not rely on some external company and in particular not on this
> >> one. This company does not exactly represent what I would call ethical,
> >> non-proprietary, and decentralized.
> > Is that a problem?
> > 
> >> Are there no partners that would kindly provide such storage to Debian
> >> (Gandi?). 
> > Are they ethical, non-proprietary, and decentralized?
> 
> To me, none of the above.
> 
> On 08/17/2018 11:30 AM, Yao Wei wrote:
> > Still, it is up to their implementation how we can access their
> > storage, and as long as we can access it with free software
> > (JavaScript stuff could be a pitfall though) it shouldn't be too much
> > problem for us.
> 
> I very much do not agree with this. The full software stack used by the
> provider *MUST* be free as well. I have made a full talk at Debconf
> explaining why it is important, I would appreciate if you could have a
> look to the video.
> 
> On 08/17/2018 03:46 PM, Ulrike Uhlig wrote:
> > I feel like we're currently balancing on a thin cobweb of fait
> > accompli.
> 
> I very much agree with this, and I kind of feel we're all gamed into
> using Salsa, and then it moves to using non-free solutions. And I'm not
> even going back to the previous thread where Alexander wrote he would
> *never* switch to a packaged solution. That one as well, is an
> unilateral decision.
> 
> > Should we make it known and visible to people who use Salsa that some
> > of their data might be stored at a 3rd party company? Is this a
> > consent issue?
> 
> It's more than this, unfortunately. After we've all been invited to
> migrate to Salsa, and all spent time on it, now it's partly non-free. If
> I knew it would go this way, it's possible that I would have chosen
> another place to host my Debian work. Possibly self-hosting it.
> 
> On 08/17/2018 03:46 PM, Ulrike Uhlig wrote:
> > Have Salsa maintainers enabled the least invasive privacy features for
> > this service?
> 
> Do you really trust this? I don't...
> 
> Also, have we ever thought that Google is completely banned in China?
> Can users in China access the data? If it's direct access to things
> hosted by Google, then the answer is probably that it's also blocked.
> 
> On 08/17/2018 03:49 PM, Alexander Wirt wrote:
> > why should gandi be better? Do you have access to all of their source
> > code (managementfrontend, storagebackend, billingbackend and so on?)
> >
> > Unless debian is doing the whole thing on its own, we are out of luck.
> >
> > Alex
> 
> As I mentioned in my talk at Debconf18, there's 18 listed public cloud
> providers using OpenStack here:
> 
> https://www.openstack.org/marketplace/public-clouds/
> 
> OVH, CloudWatt, Rackspace, Vexxhost, and also probably the company I
> work for (Infomaniak) are potential candidates for sponsoring storage,
> and all of them are using free-software hosting platforms.
> 
> I also don't understand why we're not attempting to build a Ceph cluster
> at UBC. Why not?
go ahead. if it works well we can switch to it. 

Alex
 
P.S. I will not react to the other nonsense in that mail. 

Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)

[Alexander Wirt]

On Fri, 17 Aug 2018, Ulrike Uhlig wrote:

> Hi!
> 
> Jonas Meurer:
> > Am 13.08.2018 um 20:36 schrieb Alexander Wirt:
> >>> Hrmpf! I have to say that I was somewhat surprised by this announcement.
> >>> To be honest, I don't like the idea of making our infrastructure as a
> >>> project rely on closed and proprietary systems like Google Cloud. Isn't
> >>> it important to us as a project anymore to run our infrastructure on
> >>> free software and under our own control? [1]
> >>> We don't rely on it. There will be a backup on debian infastructure so
> > that
> >> we will be able to change to different providers at every time. 
> > 
> > That's good to know!
> 
> > Your explanation definitely helps with understanding the rationale
> > behind your decision to switch to Google Cloud for some storage. And if
> > Salsa indeed has I/O problems already, it's much appreciated that you do
> > something about it. Again, thanks for this.
> 
> Ack.
> 
> > I just wonder why we don't consider and prefer free solution (either by
> > running an own external storage or by using free software cloud
> > providers) over the proprietary ones. In my eyes, this conflicts with
> > our social contract and with prioritizing Free Software. That's, why I
> > brought it up here.
> > 
> > What do others think about it?
> 
> Thanks for bringing it up, Jonas! I absolutely agree with your reasoning
> and I also think that it conflicts with Debian's Social Contract; hence
> I'd like to see this discussed before silently implementing such a thing.
> 
> While I understand the simplicity of using $company's cloud storage, I'd
> rather not rely on some external company and in particular not on this
> one. This company does not exactly represent what I would call ethical,
> non-proprietary, and decentralized.
> 
> Are there no partners that would kindly provide such storage to Debian
> (Gandi?). Sometimes this may take more time, and be harder to implement.
> It might be more expensive, and that's exactly the point: whenever
> something is free, you've become the product.
why should gandi be better? Do you have access to all of their source code
(managementfrontend, storagebackend, billingbackend and so on?) 

Unless debian is doing the whole thing on its own, we are out of luck. 

Alex

Re: Notification of merge requests on Salsa

[Alexander Wirt]

On Thu, 16 Aug 2018, Jacob Adams wrote:

Hi, 

> I've just discovered that by default, salsa.d.o does not inform project
> owners of merge requests opened against their projects. This seems like
> a poorly chosen default, as it is quite easy to completely miss when a
> user opens a merge request, unless one checks salsa regularly.
> 
> Should we try to change this default?
> I would imagine that most of us do debian work primarily via email so
> having salsa support that workflow by default would be much appreciated.
> 
> I suppose the next step is to open an issue against salsa support but I
> wanted to see if there was consensus that this would be a welcome change
> first.
Of course they do, if you configure notifications properly. Thats a user 
setting, we
can't provide a default as admins. And I am of sure you don't want to get
informed about every pull request on every project in the debian/ namespace. 

Alex



signature.asc
Description: PGP signature

Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)

[Alexander Wirt]

On Mon, 13 Aug 2018, Jonas Meurer wrote:

> Hello,
> 
> Am 11.08.2018 um 16:20 schrieb Bastian Blank:
> > We will do maintenance on salsa.debian.org today, 2018-08-11, between
> > 1600 and 1800 UTC.
> > 
> > We will upgrade the GitLab instance to 11.1.4.
> 
> Thanks a ton for all your maintenance work for salsa. It's a huge
> improvement for packaging and team maintenance work to have salsa around!
> 
> > We will also start moving some of the large data stores with public
> > accessible files off to Google Cloud storage.  Using an external storage
> > allows us to store a much larger amount of data in our GitLab instance.
> > All access to it will be proxied, without providing user identifying
> > data to the storage provider.
> 
> Hrmpf! I have to say that I was somewhat surprised by this announcement.
> To be honest, I don't like the idea of making our infrastructure as a
> project rely on closed and proprietary systems like Google Cloud. Isn't
> it important to us as a project anymore to run our infrastructure on
> free software and under our own control? [1]
We don't rely on it. There will be a backup on debian infastructure so that
we will be able to change to different providers at every time. 

Additionally its only subsidiary data. Git is and will be only on debian
infrastructure. If you don't use lfs or ci, you are safe (whatever safe
means). 

But using gce allows us to to support use cases different use case than just
git (like lfs, build artificats, build logs and so on) without consuming IO
on debian infrastructure (we are already seeing IO problems on high traffic). 

Hope that helps

Alex


signature.asc
Description: PGP signature

Accepted ipvsadm 1:1.29-1 (source amd64) into unstable

[Alexander Wirt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 05 Aug 2018 09:21:46 +0200
Source: ipvsadm
Binary: ipvsadm
Architecture: source amd64
Version: 1:1.29-1
Distribution: unstable
Urgency: medium
Maintainer: Alexander Wirt 
Changed-By: Alexander Wirt 
Description:
 ipvsadm- Linux Virtual Server support programs
Closes: 649106 788345 808950 814348 903935
Changes:
 ipvsadm (1:1.29-1) unstable; urgency=medium
 .
   * [b30c9aa] New upstream version 1.29
 (Closes: #903935)
   * [f33b1cc] Bump standards version
   * [06cf313] Priority extra is now optional
   * [28cd1fe] Bump to dh11
   * [776e7b4] package doesn't build with parallel
   * [a3d3994] Add gitlab-ci file
   * [b82b9b0] Add snapshot changelog
   * [c1c00d7] Add homepage field
   * [4af29a6] Remove trailing whitespace
   * [8cdf09c] I found even more whitespace
   * [8f39cde] Verify gpg sig on upstream tarball
   * [0e9779f] use specific GPL version in copyright
   * [07d28a4] Remove obsolete lintian override
   * [6a7e974] We don't use dpatch anymore, kick README.source
   * [98911a8] Add override file - we don't have a changelog
   * [aa1dc89] Fix syncid on daemon invocation (Closes: #649106, #788345, 
#808950)
   * [7695a4a] Add a patch to enhance weight parameter to INT_MAX.
 Thanks to Francois Lallart  (Closes: #814348)
Checksums-Sha1:
 65190ed90f1accb1205f5d902f0623059e932028 1898 ipvsadm_1.29-1.dsc
 759017db7108c0392ab0ff2c102d3ef322ad93a8 46115 ipvsadm_1.29.orig.tar.gz
 a49e5071e42983a1d4078777bd7b0517cda30b01 14296 ipvsadm_1.29-1.debian.tar.xz
 3f5d15e1e97b6c91fb0dd9199b3253b5dbb132ba 26748 ipvsadm-dbgsym_1.29-1_amd64.deb
 e63a759b779d2902f57d48f1366eb47c96236b85 6021 ipvsadm_1.29-1_amd64.buildinfo
 35a388665aa203f0ffb3b089b213edf208450fab 39244 ipvsadm_1.29-1_amd64.deb
Checksums-Sha256:
 ff03bb214580c223fd9074d619a44c9c63aff3546411c5089d50525651d2a7f2 1898 
ipvsadm_1.29-1.dsc
 99ed8ce998b719de2f7b3a52ef28b38a4a016a5a05da772acfd75e64511a4c17 46115 
ipvsadm_1.29.orig.tar.gz
 bd398bcc4f906327204c676c942bc8d1e53b0d0ca461bcf237961f44cb904c70 14296 
ipvsadm_1.29-1.debian.tar.xz
 92e13f3329845b3aa6e28118ef5efcdd7e0f82f691ed4da9f06defe05a91f77f 26748 
ipvsadm-dbgsym_1.29-1_amd64.deb
 884369a65a335c95dc08c6cb7aa8b8671a2ff7afe99f108198b34fce5c5127f7 6021 
ipvsadm_1.29-1_amd64.buildinfo
 3cf067f441a16e353e17b93c51306b5ba01a195fdebbe603bfb8e2e9c9b142aa 39244 
ipvsadm_1.29-1_amd64.deb
Files:
 1735552dfd9a05703cde487698da0ad9 1898 net optional ipvsadm_1.29-1.dsc
 92dc0fb785177feda32ec2f17cc9d132 46115 net optional ipvsadm_1.29.orig.tar.gz
 bdc4713fc793533506ef967feaac44ca 14296 net optional 
ipvsadm_1.29-1.debian.tar.xz
 f976a67dc680398e6a943b4555d05f5c 26748 debug optional 
ipvsadm-dbgsym_1.29-1_amd64.deb
 d2711a4a254a591747d1e0fe5b5c1efe 6021 net optional 
ipvsadm_1.29-1_amd64.buildinfo
 193e771433c0470515e1df900eeaf2cb 39244 net optional ipvsadm_1.29-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEbjlmweHRXblz0FtJHkX4yp3iOxYFAltmv14ACgkQHkX4yp3i
OxZWgg//Wpknp5se1NVnZU1839sMaMbcbK4Y9IgvOhd+xqxz91DZ/0toSHCe0gW4
rKhnetO4nM3X/kp2ZJgPpRnH41SZo5ctVOcsz1POt0XqtVc8Pvd5FS1Y3dBVOIJK
AaYMgxsXpXMUZ53lhQMAbpDuxcwuTj4Ou2Dx1UejimuELJPFXLz+9G/S5vDOGX07
8GShLTzVdNoWHJM1zLx1+42YrvkBmtLpGrRo4YI5gW8k+YEgR3gGCDexFpzqdhzJ
05LRMnuaijMFV1fDm3suw+MeHRaJVyWGDUX2xPBpDcSK+nShkNAsoZpoL/djDwZ3
H4HWcF60DUSOEkQ6o1BWIII/T4a/FxUgC1pYhSSFU8+KAIrOLx2u4LLjxeEJTuCW
nIAjz9hmq81SiJQKraFhcA8qFVr2odmSU6+PXM0yYxGITav/D/iQlM0T5tKJrbcD
NiFXZOz9c/LWF8acXrkV1IohsNv5HV9oaOkOoZ0EZEweagaIy62samAFY1n0pq9E
njEGHQivozE/6AvWogSmHgZMRMoL29ZhvOOvAmrbwmQsD8BxW2JgzYP01gaOoJmk
7As+DHoItYZ39Px1TnJmnfQWHWzDBIieGVQNzLnzGJdE5JxdWXtvG0zaDp09248x
UgiD2arzAn+kug6CQwvYjKXVLc1MGLOQe2mOqP3jbEog8bYOo2E=
=EhhS
-END PGP SIGNATURE-

salsa irker bot moved to ssl

[Alexander Wirt]

Hi, 

in the face of the current spam attacks I implemented CertFP for my 
irker instance. I also updated the default irc link in gitlab. However,
it is possible that every project using the bot has to migrate the server
setting to ssl. So if you miss messages from salsa bot, please check that you
use ircs://irc.oftc.net:6697/ as server setting in the irker integration.  

Thanks

Alex


signature.asc
Description: PGP signature

Re: Test message

[Alexander Wirt]

On Sun, 29 Jul 2018, Jonathan Busby wrote:

> I have been having problems posting to this mailing list so I'm using
> pobox.com instead of my Gmail to see if that helps as per the listmaster's
> suggestion.
Ehm, you asked about "getting" mails, not about sending mails to the list.
Therefore I didn't checked that. 

Alex
 

Re: Please remove your obsolete repos from alioth *NOW*

[Alexander Wirt]

On Tue, 12 Jun 2018, Wouter Verhelst wrote:

Hi Wouter, 
> On Wed, May 30, 2018 at 10:24:33AM +0200, Alexander Wirt wrote:
> > Hi, 
> > 
> > we still have 175GiB git repos left on alioth. Please remove them asap.
> 
> Life has been busy recently, and I didn't see this message until now.
> 
> I guess that alioth has been shut down by now.
> 
> Is it still possible for me to go in and remove repositories that are no
> longer needed?
Thanks for coming back to us, but unfortunately it is now to late. The
process of archiving is done.

> If not, then meh, never mind, but I thought I'd ask first.

Thanks for asking!

Alex
 

Re: Debian 10 please update gimp to 2.10....

[Alexander Wirt]

On Mon, 11 Jun 2018, DutchGigalo wrote:

> Debian 10 (buster) please update gimp to 2.10   
Debian 10 isn't even released. That packages are missing is expected and not
a reason for sending mails. 

Alex

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Alexander Wirt]

On Mon, 11 Jun 2018, أحمد المحمودي wrote:

> On Mon, Dec 25, 2017 at 11:45:37AM +0100, Alexander Wirt wrote:
> > Collab-maint
> > 
> > 
> > If you want to allow other Debian Developers to work on your packages or 
> > software, you can create projects within the
> > **Debian** group. Every Debian Developer has write access to projects 
> > created in this group.
> > If you create a project within the Debian group, you are implicitly 
> > welcoming all DDs to contribute directly to the project.
> > 
> > Guest users can only be added to individual projects with the Debian group, 
> > but not to the entire Debian group. This is different to the policy for the 
> > collab-maint group on Alioth.
> ---end quoted text---
> 
> I am not a DD, anf I was working on some  projects under collab-maint on 
> Alioth. Should I create those projects (that weren't migrated) under 
> **Debian** group (which I cannot find on salsa btw), or should I create 
> those projects under my own namespace ?
Look harder: https://salsa.debian.org/debian

And you can do whatever you like more. 

Alex




signature.asc
Description: PGP signature

Re: its dead jim - alioth is gone

[Alexander Wirt]

On Mon, 11 Jun 2018, Paul Wise wrote:

> On Mon, Jun 11, 2018 at 9:41 AM, أحمد المحمودي wrote:
> 
> > What  has happened to the data in users' home directories ?
> 
> The data will still be available until the VM is deleted.
> The public_git directories are in the alioth archive:
Which will happen soon, if you miss something you should be fast. 

Alex
 

Re: Renew SSO Cert (was: its dead jim - alioth is gone)

[Alexander Wirt]

On Wed, 06 Jun 2018, kaliko wrote:

> Hi,
> 
> First, thanks Alexander and everyone involved in alioth/salsa migration!
> 
> Le 05/06/2018 à 21:49, Alexander Wirt a écrit :
> > […]
> > Whats left?
> > 
> > […]
> > - deploy the new sso.debian.org backend
> 
> What are the plans regarding the new sso.debian.org backend?
> In particular for non-DD or DM profiles that need to renew their cert?
You can still login to sso. During gsoc we are currently developing a
new frontend/backend. 

Alex
 

Re: concerns about Salsa

[Alexander Wirt]

On Tue, 05 Jun 2018, Dmitry Smirnov wrote:

> On Tuesday, 5 June 2018 3:45:42 PM AEST Alexander Wirt wrote:
> > We don't have root.
> 
> That actually makes sense... I didn't realize that Salsa is locked so tightly 
> that even you don't have root access... That makes things much harder than it 
> should be...
> 
> Do you think there will be a potential to move services to containers, 
> probably on "rkt" runtime[*] ?
No idea, managing the hosts itself is DSA area. 

Alex



signature.asc
Description: PGP signature

Re: concerns about Salsa

[Alexander Wirt]

On Tue, 05 Jun 2018, Dmitry Smirnov wrote:

> On Monday, 4 June 2018 10:08:00 PM AEST Alexander Wirt wrote:
> > It just doesn't packages - which were just not available at the
> > time we needed them (the available package were several major versions
> > behind).
> 
> IMHO it should have create enough incentive to (help) updating gitlab package 
> and then use it.
> To me it was perfectly OK to use older GitLab up until newer package became 
> available...
Your choice, I prefer recent versions without security problems. 

Alex



signature.asc
Description: PGP signature

Re: concerns about Salsa

[Alexander Wirt]

On Tue, 05 Jun 2018, Dmitry Smirnov wrote:

> On Monday, 4 June 2018 11:25:41 PM AEST Alexander Wirt wrote:
> > Please don't expect us to ever switch to packages - that will not happen.
> 
> That's an interesting statement. Why?
> 
> Do you think Praveen did all the enormous effort of packaging GitLab for 
> nothing? Do you reckon that packaging software adds no value?
The effort is not for us. Do you think we did all the effort for a proper
administration for nothing? 

> 
> I understand trade-off between stability of a package versus convenient 
> volatility of git repository that you can patch at your own discretion.
> Yet I think that official Debian service ideally should be based on official 
> Debian package and that service administrators should be working together 
> with package maintainers, helping each other.
> 
> It is not viable to install everything from git. So how would you chose when 
> to use packages and when to use git?
> 
> What about "gitaly"? This particular component of GitLab is written in Golang 
> and it needs to be built from source. Why do you compile "gitaly" from source 
> Gentoo-style instead of using properly built Debian package?
Because we want to react fast, without dsa. We don't have root. 
> 
> What makes Salsa so special to say that using properly packaged components 
> from "main" is inappropriate?
Its not special, most services are run like that.

> "This will not happen" is a strong statement. Is packaging software for 
> Debian so hopeless that there is nothing GitLab maintainers could ever do to 
> make you change your mind and embrace work of fellow Debian developers?
Unless the ways services are run on DSA managed hosts changes, we will not
move to packages. 

Alex


signature.asc
Description: PGP signature

Re: concerns about Salsa

[Alexander Wirt]

On Mon, 04 Jun 2018, Thomas Goirand wrote:

> On 06/04/2018 12:29 PM, Dmitry Smirnov wrote:
> > GitLab is the right technology for us and a good improvement comparing to 
> > Alioth.
> > 
> > I think it is great that we've chosen GitLab as successor to Alioth but how 
> > would it make you feel if you were told that Salsa is not running on Debian?
> > 
> > That's how I feel... Specifically I'm concerned how GitLab is installed on 
> > Salsa.
> 
> Hi Dmitry,
> 
> I very much share your feeling, though there's one major blocker atm:
> the NEW queue. Pirate Praveen uploaded lots of node packages which are
> needed for gitlab, and it's still waiting for approval. Until that's
> done, then there wont be any up-to-date Gitlab package in Debian. And
> really, version 10.x is so much nicer than 8.x. Of course, not having
> 12.x in Unstable prevents it from having an official Stretch backport...
> 
> At the same time, I have sympathy for both the FTP masters: that's A LOT
> of packages to review, and the Salsa admins: when they've set the Salsa
> service online, there wasn't all of this packaging available, and they
> needed it ASAP.
> 
> Let's just hope that all of this goes fast in the right direction so
> that the situation is fixed.
Please don't expect us to ever switch to packages - that will not happen. 

Alex

Re: concerns about Salsa

[Alexander Wirt]

On Mon, 04 Jun 2018, eamanu15 wrote:

> El lun., 4 de jun. de 2018 a la(s) 09:08, Alexander Wirt <
> formo...@debian.org> escribió:
> 
> > On Mon, 04 Jun 2018, eamanu15 wrote:
> >
> > > I think it's a low blow to us.
> > >
> > > I think this should have been known from the beginning. We need each of
> > the
> > > Debian projects, intervene the Debian itself.
> > >
> > > Why don't start a new Debian project similar to GitLab, but based on
> > Debian
> > > OS.
> > of course it was all known and announced in advance and it is running on
> > debian. It just doesn't packages - which were just not available at the
> > time
> > we needed them (the available package were several major versions behind).
> >
> 
> Ah ok, So Salsa is running on a Debian server?
Of course.

Alex

Re: concerns about Salsa

[Alexander Wirt]

On Mon, 04 Jun 2018, Ian Jackson wrote:

> Dmitry Smirnov writes ("concerns about Salsa"):
> > Imagine my surprise when I've found that Salsa is not using our own
> > GitLab package at all.
> 
> Salsa is hardly the first Debian production service to not be running
> the packaged version of its primary application, and it won't be the
> last.  ftp.debian.org isn't running the packaged version of dak.
> 
> Even my own git.dgit.d.o isn't running the packaged version of
> dgit-infrastructure; it executes out of a git clone.  (I took the
> trouble to implement `dgit clone-dgit-repos-server' and the
> corresponding server end so make sure that the source code for the
> server is always public.)
> 
> > I would understand if there were no choice but Salsa admins clearly
> > chosen to discard GitLab package in favor of vendor binaries
> 
> However, I hope it's not running vendor-provided binaries.  That would
> be quite poor IMO and a big departure from our normal practice.  Are
> you sure that that is the case ?
We use git. 
https://salsa.debian.org/salsa/ansible


Alex

Re: concerns about Salsa

[Alexander Wirt]

On Mon, 04 Jun 2018, eamanu15 wrote:

> I think it's a low blow to us.
> 
> I think this should have been known from the beginning. We need each of the
> Debian projects, intervene the Debian itself.
> 
> Why don't start a new Debian project similar to GitLab, but based on Debian
> OS.
of course it was all known and announced in advance and it is running on
debian. It just doesn't packages - which were just not available at the time
we needed them (the available package were several major versions behind). 

Alex

Re: Please remove your obsolete repos from alioth *NOW*

[Alexander Wirt]

On Thu, 31 May 2018, Herbert Fortes wrote:

> Hi,
> 
> > On Wed, May 30, 2018 at 10:41:21PM +0200, Adam Borowski wrote:
> > > On Wed, May 30, 2018 at 06:30:20PM +0200, Alexander Wirt wrote:
> > > > There it doesn't make sense to keep anything on alioth which is also on
> > > > salsa. Everything else gets archived for historical purposes.
> > > > Every repo that is on salsa and alioth will just waste ressources on the
> > > > archive host.
> 
> I did a QA for pygresql and put it on salsa[0]. But when
> I tried to ssh git.debian.org I got a warning and "Permission
> denied".
> 
> [0] - https://salsa.debian.org/debian/pygresql
git.debian.org is no more, you can access the remaining stuff of the host at
moszumanska.debian.org

Alex

Re: Please remove your obsolete repos from alioth *NOW*

[Alexander Wirt]

On Wed, 30 May 2018, Adam Borowski wrote:

> On Wed, May 30, 2018 at 06:30:20PM +0200, Alexander Wirt wrote:
> > There it doesn't make sense to keep anything on alioth which is also on
> > salsa. Everything else gets archived for historical purposes. 
> > Every repo that is on salsa and alioth will just waste ressources on the
> > archive host.
> 
> I admit I haven't been keeping track at all of repositories touched, which
> were:
> * copied by me from alioth to salsa
> * copied by someone else from alioth to salsa, then I pointed the metadata
> * I helped a non-DD create a repository on salsa to move a repo from
>   elsewhere (usually from a random place on alioth)
> 
> Thus, perhaps it could be better to run a script to see if a given repo has
> been copied to salsa.
Good idea, write one and use it. 

Alex
 

Re: Please remove your obsolete repos from alioth *NOW*

[Alexander Wirt]

On Wed, 30 May 2018, Sean Whitton wrote:

Hi Sean, 

> On Wed, May 30 2018, Alexander Wirt wrote:
> 
> > we still have 175GiB git repos left on alioth. Please remove them
> > asap.
> 
> Thank you for your efforts in this area.
> 
> I take it we should leave repos on alioth when their Vcs-* headers have
> not been updated in unstable?  Or are you saying that as many repos as
> possible should be removed (i.e. all those that have been migrated to
> salsa, whether or not they've been uploaded), because the archival
> address is going to be different anyway?
> 
> What I'm asking is, what exactly is the meaning of 'obsolete'?  I looked
> at your previous d-d-a posting and it does not really say.  It would be
> great if you could make your request a little more precise.
> 
> > 282.1MiB [## ] /debconf-share.git
> 
> I don't know who is responsible for this repo, but it is used to power
> the videos archive, IIRC.  So it should probably be archived until the
> person who runs that service wakes up :)
> 
> > 1.4GiB [ ] /pkg-mozext
> 
> Just to note that the pkg-mozext repos *should* be archived rather than
> moved to salsa -- they are for xul- extensions, but our new group is for
> webext- extensions only.  This is because xul- extensions will only work
> for a few more months.  But we should keep the git history archived
> somewhere.
Every repo on alioth will get archived and disabled on the weekend. Alioth is
gone at the end of the weekend. 

There it doesn't make sense to keep anything on alioth which is also on
salsa. Everything else gets archived for historical purposes. 
Every repo that is on salsa and alioth will just waste ressources on the
archive host.

So *please* delete everything that has been migrated other services.

I hope that makes things clearer.

Alex
 


signature.asc
Description: PGP signature

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

[Alexander Wirt]

On Wed, 30 May 2018, Chris Lamb wrote:

Hi, 

> > I am not a kindergarten teacher. I will just stop answering mails here. 
> 
> You must know I have the greatest of respect for the tireless work you
> have done and continue to do so as part of the migration from Alioth
> to salsa.
> 
> You are actually not privy to the number of times I have mentioned
> this both internally and externally to the Project, including to those
> working at GitLab itself. Indeed, it is one of the real delights of
> being the Project Leader to be able to extoll and promote the work
> done by its developers.
> 
> However, I cannot help feel that (at least appearing!) to be little
> more cordial in your communications over the past day or so would be
> more productive and actually reflect your actual personality better.
> 
> I understand that you are only human and thus have finite amount of
> time and energy to exert on what you perceive to be trivial and
> obvious responses. But if you are human too, then so are your fellow
> developers who — like all homo sapiens — ask dumb questions at times,
> rely a little too much on others, tend to skim-read, etc. etc.
> 
> If you would like specific examples (and my associated humbly-offered
> suggestions), I would be very happy to discuss that privately with you
> at your convenience.
You are completly right. Thats why I said I will stop answering questions
here. This will help me to come down.

Alex
 

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

[Alexander Wirt]

On Wed, 30 May 2018, Ian Jackson wrote:

> Alexander Wirt writes ("Re: remote: GitLab: LFS objects are missing. Ensure 
> LFS is properly set up or try a manual "git lfs push --all"."):
> > Alex - fed up with explaining the same things again and again and again
> 
> Debian contributors are not, by and large, stupid or lazy.  If you
> find that many Debian contributors are making similar mistakes then
> probably this is probably because of factors in their environment.
> 
> In this particular case, that environment is Salsa.  If course there
> will always be mistakes and people will overlook things.  But if you
> find that you are having to explain similar things over and over again
> then it probably means that your user interfaces or documentation are
> not sufficiently good.
> 
> A better approach, when someone asks a question you think is answered
> in the docs, is to ask in a friendly way, something like this:
I am not a kindergarten teacher. I will just stop answering mails here. 

Alex
 

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

[Alexander Wirt]

On Wed, 30 May 2018, Ian Jackson wrote:

> Alexander Wirt writes ("Re: remote: GitLab: LFS objects are missing. Ensure 
> LFS is properly set up or try a manual "git lfs push --all"."):
> > Alex - fed up with explaining the same things again and again and again
> 
> Debian contributors are not, by and large, stupid or lazy.  If you
> find that many Debian contributors are making similar mistakes then
> probably this is probably because of factors in their environment.
in fact its mostly andreas. 

> In this particular case, that environment is Salsa.  If course there
> will always be mistakes and people will overlook things.  But if you
> find that you are having to explain similar things over and over again
> then it probably means that your user interfaces or documentation are
> not sufficiently good.
He don't read the documentation. Especially the part about "where to find
support". In fact he knows about it, he just ignores it. 

> 
> A better approach, when someone asks a question you think is answered
> in the docs, is to ask in a friendly way, something like this:
Thats the part of again and again. I *KNOW* that andreas knows about the
support channels, he just ignores it. 

> 
>   Can you tell me where you looked for the answer, or where
>   you looked for contact information, before asking your question
>   here on debian-devel ?
> 
>   Your question seems to me to be answered here:
>  https://whatever
>   but perhaps that page wasn't sufficiently discoverable, or maybe
>   it wasn't clear enough ?
> 
>   We want to improve the UI and the documentation so that people
>   more easily find the information they need.  (And of course to
>   reduce our own workload!)  So suggestions for improvement would
>   be very welcome.
> 
> Personally when I make some kind of bug report or support request I
> try to anticipate this kind of question.  The result is often
> suggestions for improvements to docs, or docs visibility.  (Since
> everything we rely on is Free Software, we can always change things to
> make life smoother for users, and less burdensome for service
> operators...)
> 
> Ian.
> 
> -- 
> Ian JacksonThese opinions are my own.
> 
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
> 

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

[Alexander Wirt]

On Wed, 30 May 2018, Andreas Tille wrote:

> Hi again,
> 
> On Wed, May 30, 2018 at 07:50:01AM +0200, Alexander Wirt wrote:
> > > > Your repo has lfs disabled. You should enable it. 
> > > 
> > > How can I do this?
> > > I've just found[1]:  "Your administrator only need to enable the LFS 
> > > option."
> > *seufz* we enabled it, but as you can guess it needs to get enabled per 
> > repo.
> > 
> > Settings -> Permissions -> Git Large File Storage
> 
> Thanks for the hint.  I would not call "Permissions" the obvious place to
> look for this and my web search did not uncover this, sorry.
> 
> Unfortunately it does not work yet:
> 
> 
> gatk(master) $ git push
> Counting objects: 4599, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (4453/4453), done.
> Writing objects: 100% (4599/4599), 64.56 MiB | 462.00 KiB/s, done.
> Total 4599 (delta 811), reused 1 (delta 0)
> remote: Resolving deltas: 100% (811/811), completed with 1 local object.
> remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try 
> a manual "git lfs push --all".
> To salsa.debian.org:med-team/gatk.git
>  ! [remote rejected] master -> master (pre-receive hook declined)
>  ! [remote rejected] pristine-tar -> pristine-tar (pre-receive hook declined)
>  ! [remote rejected] upstream -> upstream (pre-receive hook declined)
>  ! [remote rejected] upstream/4.0.4.0 -> upstream/4.0.4.0 (pre-receive hook 
> declined)
> error: failed to push some refs to 'g...@salsa.debian.org:med-team/gatk.git'
> gatk(master) $ git lfs push --all
> Specify a remote and a remote branch name (`git lfs push origin master`)
> gatk(master) $ LC_ALL=C git lfs push origin master
> Locking support detected on remote "origin". Consider enabling it with:
>   $ git config 
> lfs.https://salsa.debian.org/med-team/gatk.git/info/lfs.locksverify true
> LFS upload missing objects: (0/246), 0 B | 0 B/s  
>   
>
>   (missing) src/test/resources/large/NA24385.vcf.gz 
> (f3326d552a86197e1d8fbfee2941f6b8684f7b31bfab9730f953401566066e2b)
>   (missing) 
> src/test/resources/large/VQSR/ALL.wgs.indels_mills_devine_hg19_leftAligned_collapsed_double_hit.sites.20.1M-10M.vcf
>  (48f0bdac467ee4d618e6425c0989a344e5d8523baaf5016e92ef246c4311c58b)
>   (missing) src/test/resources/large/VQSR/g94982_b37_chr20_1m_10m.vcf.gz.tbi 
> (97a7c779a82a4e3aea8de77a4e9bda68909d489e3c0553399c1e9affbba6c0d8)
>   (missing) 
> src/test/resources/large/cnv_somatic_workflows_test_files/wgs-no-gc.pon.hdf5 
> (b916357182a024e126b7754e41d134e67e26d6328538eee8865ac264c981ab04)
>   (missing) src/test/resources/large/mutect/dream_synthetic_bams/tumor_2.bam 
> (9d9ce1ff6c68429befeef11b9626a959af109aa99a637f89d2abf643ab524ffb)
>   (missing) 
> src/test/resources/large/mutect/dream_synthetic_bams/normal_1.bam.bai 
> (369eed4192701e4abd5a9be1e4d308ce46232983812a854a847465ab7a2fc2a5)
>   (missing) 
> src/test/resources/large/mutect/dream_synthetic_bams/tumor_1.bam.bai 
> (566ede9346c4260d7810e112bd4f4892ab1aaa37f5b20ebf4b3ba0fe83db2993)
> Uploading LFS objects:   0% (0/246), 0 B | 0 B/s, done
>   (missing) src/test/resources/large/gvcfs/combined.gatk3.7.g.vcf.gz.tbi 
> (403996681f4a0622236a45c71a63ba8c3594664e379cde16efd10f5f598499ff)
> ...
>   (missing) src/test/resources/large/VQSR/snpRecal.vcf 
> (a9c2535862d234fd09c5978c00a6127caa079989158a93cb13a2356911c561bb)
>   (missing) 
> src/test/resources/large/cnv_germline_workflows_test_files/SM-74P2T_20xy-downsampled.bam
>  (7cfbe031257a12d39c460a775bd22b6713130b9a45f6976df7e7b1c7950a268b)
>   (missing) src/test/resources/large/VQSR/g94982_b37_chr20_1m_10m.vcf.tbi 
> (3540c3ec7d15607a541b5ccf51c8cc60d03d826c5abbd866f4573d2694a86e9f)
>   (missing) 
> src/test/resources/large/funcotator/gencode.v19.chr_patch_hapl_scaff.chr3.gtf 
> (3e935c5ac87020a90689b86f9a6ca5f05c24736528f550ea54a0c84772c6fdd3)
>   (missing) 
> src/test/resources/large/cnv_somatic_workflows_test_files/wes-do-gc.pon.hdf5 
> (b9c1b28743e4569379f987d5eeebc5393467fd2fc981c85475873b219576dfa4)
>   (missing) 
> src/test/resources/large/cnv_somatic_workflows_test_files/human_g1k_v37.chr-20.truncated.dict
>  (604e04600e644864c34e2fce42241febac0f0be062223a66e88499fca1c55147)
>   (missing) 
> src/test/resources/large/cnv_somatic_workflows_test_files/SM-74NEG-v1-chr20-downsampled.deduplicated.cram.crai
>  (fc99f68bcc0a4fc1ff3a240ad64d62fa8bfd31ecdc11d326107a5e1ec969ccca)
>   (missing) 
> src/test/resources/large/mutect/dream_synthetic_bams/normal_4.bam.bai 
>

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

[Alexander Wirt]

On Wed, 30 May 2018, Geert Stappers wrote:

> On Wed, May 30, 2018 at 11:19:14AM +0200, Alexander Wirt wrote:
> > On Wed, 30 May 2018, Andreas Tille wrote:
> > > Hi again,
>  
>   :-)
> 
> 
> > > On Wed, May 30, 2018 at 07:50:01AM +0200, Alexander Wirt wrote:
> > > > > > Your repo has lfs disabled. You should enable it. 
> > > > > 
> > > > > How can I do this?
> > > > > I've just found[1]:  "Your administrator only need to enable the LFS 
> > > > > option."
> > > > *seufz* we enabled it, but as you can guess it needs to get enabled per 
> > > > repo.
> > > > 
> > > > Settings -> Permissions -> Git Large File Storage
> > > 
> > > Thanks for the hint.  I would not call "Permissions" the obvious place to
> > > look for this and my web search did not uncover this, sorry.
> > > 
> > > Unfortunately it does not work yet:
> > use the support tracker and I will look after it when I have time.
> 
> Where is that support tracker?
> 
> (It feels strang to report "salsa is broken" at Salsa itself.)
(sorry thats complete nonsense, if the webfrontend would be broken at all.
yes - use IRC. But thats not the case here). 

there are several options to find it: 

1) read my announcements: 
https://lists.debian.org/debian-devel-announce/2018/01/msg4.html
2) press help on salsa: https://salsa.debian.org/help
3) check the wiki https://wiki.debian.org/Salsa/Doc#Support

> 
> > debian-devel is not on the list of salsa supportchannels.
>  
> Even multiple suportchannels for salsa.
> What are the preferred top three?
For all longer taking things of course tickets. 

> In other words
> How cool would it be if the "not here" would have travelled with
>  at URL you find a list of salsa supportchannels
How cool would it be if people would use their heads. I can only tell people
where the door is, but they have to use it on their own. 

Alex - fed up with explaining the same things again and again and again 
 

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

[Alexander Wirt]

On Wed, 30 May 2018, Andreas Tille wrote:

> Hi again,
> 
> On Wed, May 30, 2018 at 07:50:01AM +0200, Alexander Wirt wrote:
> > > > Your repo has lfs disabled. You should enable it. 
> > > 
> > > How can I do this?
> > > I've just found[1]:  "Your administrator only need to enable the LFS 
> > > option."
> > *seufz* we enabled it, but as you can guess it needs to get enabled per 
> > repo.
> > 
> > Settings -> Permissions -> Git Large File Storage
> 
> Thanks for the hint.  I would not call "Permissions" the obvious place to
> look for this and my web search did not uncover this, sorry.
> 
> Unfortunately it does not work yet:
use the support tracker and I will look after it when I have time.
debian-devel is not on the list of salsa supportchannels.

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

[Alexander Wirt]

On Wed, 30 May 2018, Andreas Tille wrote:

> Hi,
> 
> On Tue, May 29, 2018 at 11:35:00PM +0200, Alexander Wirt wrote:
> > > I intend to push a new version of gatk[1] which contains some large
> > > files.  I imported the new upstream package the usual way.  But if I
> > > want to push I get:
> > > 
> > > (master) $ LC_ALL=C git push
> > > Counting objects: 4599, done.
> > > Delta compression using up to 4 threads.
> > > Compressing objects: 100% (4453/4453), done.
> > > Writing objects: 100% (4599/4599), 64.56 MiB | 1.09 MiB/s, done.
> > > Total 4599 (delta 811), reused 1 (delta 0)
> > > remote: Resolving deltas: 100% (811/811), completed with 1 local object.
> > > remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or 
> > > try a manual "git lfs push --all".
> > > To salsa.debian.org:med-team/gatk.git
> > >  ! [remote rejected] master -> master (pre-receive hook declined)
> > >  ! [remote rejected] pristine-tar -> pristine-tar (pre-receive hook 
> > > declined)
> > >  ! [remote rejected] upstream -> upstream (pre-receive hook declined)
> > >  ! [remote rejected] upstream/4.0.4.0 -> upstream/4.0.4.0 (pre-receive 
> > > hook declined)
> > > error: failed to push some refs to 
> > > 'g...@salsa.debian.org:med-team/gatk.git'
> > > 
> > > 
> > > I installed git-lfs locally and tried the command above but it seems it
> > > is really needed remotely on Salsa.  Am I missing something or is there
> > > some action needed?
> > Your repo has lfs disabled. You should enable it. 
> 
> How can I do this?
> I've just found[1]:  "Your administrator only need to enable the LFS option."
*seufz* we enabled it, but as you can guess it needs to get enabled per repo.

Settings -> Permissions -> Git Large File Storage
 
Alex

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

[Alexander Wirt]

On Tue, 29 May 2018, Andreas Tille wrote:

> Hi,
> 
> I intend to push a new version of gatk[1] which contains some large
> files.  I imported the new upstream package the usual way.  But if I
> want to push I get:
> 
> (master) $ LC_ALL=C git push
> Counting objects: 4599, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (4453/4453), done.
> Writing objects: 100% (4599/4599), 64.56 MiB | 1.09 MiB/s, done.
> Total 4599 (delta 811), reused 1 (delta 0)
> remote: Resolving deltas: 100% (811/811), completed with 1 local object.
> remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try 
> a manual "git lfs push --all".
> To salsa.debian.org:med-team/gatk.git
>  ! [remote rejected] master -> master (pre-receive hook declined)
>  ! [remote rejected] pristine-tar -> pristine-tar (pre-receive hook declined)
>  ! [remote rejected] upstream -> upstream (pre-receive hook declined)
>  ! [remote rejected] upstream/4.0.4.0 -> upstream/4.0.4.0 (pre-receive hook 
> declined)
> error: failed to push some refs to 'g...@salsa.debian.org:med-team/gatk.git'
> 
> 
> I installed git-lfs locally and tried the command above but it seems it
> is really needed remotely on Salsa.  Am I missing something or is there
> some action needed?
Your repo has lfs disabled. You should enable it. 

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

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
 

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: [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: [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

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

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