Re: Debian event pre FOSDEM?

2019-11-17 Thread Steve McIntyre
Holger wrote:
>
>so at dc19 we came up with the idea of having a Debian event pre- or
>post-FOSDEM, an event like DebCamp or maybe a bug squashing party, so
>mostly self/unorganized.
>
>The only thing we would need is suitable room, and probably someone
>paying for it.
>
>And we'd need to agree on the dates. There's a ruby sprint after FOSDEM
>in Paris, so I suppose we should go with before FOSDEM.

There's also the SFC-organised Copyleft Conf on the Monday:

  https://2020.copyleftconf.org/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.



Accepted gitlab-workhorse 8.8.1+debian-2 (source) into unstable

2019-11-17 Thread Pirate Praveen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 17 Nov 2019 15:06:19 +0530
Source: gitlab-workhorse
Architecture: source
Version: 8.8.1+debian-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team 

Changed-By: Pirate Praveen 
Changes:
 gitlab-workhorse (8.8.1+debian-2) unstable; urgency=medium
 .
   * Reupload to unstable (gitlab in unstable cannot be supported meaningfully)
Checksums-Sha1:
 821d02a75971f0428c1b117f2321307ba2408b45 2991 
gitlab-workhorse_8.8.1+debian-2.dsc
 b92ccb52b38651f1a0f61bc98a62f6cca79e1291 4216 
gitlab-workhorse_8.8.1+debian-2.debian.tar.xz
 f29bb14adf9c2d65d0673c2c33f22384d358da8c 5278 
gitlab-workhorse_8.8.1+debian-2_source.buildinfo
Checksums-Sha256:
 ef5f70a7d4c0cf93c443319ed9f9b6f43c644d84d203840325021bf23ac5ab11 2991 
gitlab-workhorse_8.8.1+debian-2.dsc
 4261445c624723c91cb68449a0e9e53a932234dbd2909b42617d56cdd18dd95a 4216 
gitlab-workhorse_8.8.1+debian-2.debian.tar.xz
 2d26c5bbf2a0ada789e745571c3dfcee502e7ea04c8d5d6d74668f9fb603ae54 5278 
gitlab-workhorse_8.8.1+debian-2_source.buildinfo
Files:
 6c2ca3fb8cf5cd6f54753436ab9e0255 2991 httpd optional 
gitlab-workhorse_8.8.1+debian-2.dsc
 0c2fdb1edd5fea3659591d18a4e5b2f5 4216 httpd optional 
gitlab-workhorse_8.8.1+debian-2.debian.tar.xz
 41e1e4a6d2230d66c77cddf7888d6747 5278 httpd optional 
gitlab-workhorse_8.8.1+debian-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/OFtr184QaN6dPMgC3aSB2Kmt4UFAl3RFn8ACgkQC3aSB2Km
t4UuqQ/9HcMv+PjvzW1DuegrCO+MbzUZeO+JO+ypgIaTbyVi3JfRRF+LwlodXgrR
JpymzOPJc/YmaFbWfYGoiLV0wV/r6iOKmchEV9l8Ax++XCiGpu45pV7CRRGumAsc
UOD+htLFCHVLlqBeSg8QDJvRyjGkpugnGgxoLNe5lPsK1IgvQLBPP9CmL6GlcprL
YZhl80Lr5k9/YTeB/XZ3pMiqNxcz3wX+YnB4MoXXUC2/CZf4UUCeOB/IgWI5cH4b
TBXJ4e9leuuYqQ7Mxpz7SxQGy9EEsziuCsKE/Qr4BDLKQMXtjf4eubd2aedVSwSj
6pEApZOWf7siF48jyM63hRoosRTysrON5Y3t7d680S48c4UHset4a5j7/fKvf15o
MsAvWFpmFnCg0TJLzjaZtd6WPXjfuVRhNp5k3KpS6kuYNqaYAHXACupXfwNPSl/F
Cx23e2CwJsFQQFhEM1djJWDUH9TH4+PaEy/dOe/YU4yQFIE6biB1alSqT+0LHtQ5
MwXB4DiebTKg/DmKOYoq84nwsiLvsZWOhppyHbFIww/tHHBcSxG23yVQ0KaVSDc6
pO9NgqEDN662d0rhY4UUAZxV/PXXPPyWK2oJbCHH8pe4XdtPG0QbQB1HZr6Z0LgJ
p3dpG32AydL4MS5RUmaodnnu565c6lzTO1Y7k4HCkVK54cP64zc=
=GljM
-END PGP SIGNATURE-



Re: Debian event pre FOSDEM?

2019-11-16 Thread Paulo Henrique de Lima Santana
Hi Holger,

This year the video team sprint was at Linux Belgium.
https://www.linuxbe.com/

I think video team uses there every year.

Best regards,

On 16/11/2019 12:12, Holger Levsen wrote:
> hi,
> 
> so at dc19 we came up with the idea of having a Debian event pre- or
> post-FOSDEM, an event like DebCamp or maybe a bug squashing party, so
> mostly self/unorganized.
> 
> The only thing we would need is suitable room, and probably someone
> paying for it.
> 
> And we'd need to agree on the dates. There's a ruby sprint after FOSDEM
> in Paris, so I suppose we should go with before FOSDEM.
> 
> One idea would be to do it in the Brussels hackerspace, if they are
> still in the same place as they were this year I think it would fit.
> Does anyone have contacts to them and could ask?
> 
> Anybody willing and able to go hunting for a suitable place in Brussels?
> I believe this should happen *now* as people already started to book their
> travels...
> 
> 

-- 
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Debian Developer
Diretor do Instituto para Conservação de Tecnologias Livres
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450



signature.asc
Description: OpenPGP digital signature


Accepted texstudio 2.12.16+debian-1 (source amd64 all) into unstable

2019-11-16 Thread Tom Jampen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 16 Nov 2019 20:13:54 +0100
Source: texstudio
Binary: texstudio texstudio-dbgsym texstudio-doc texstudio-l10n
Architecture: source amd64 all
Version: 2.12.16+debian-1
Distribution: sid
Urgency: medium
Maintainer: Tom Jampen 
Changed-By: Tom Jampen 
Description:
 texstudio  - LaTeX Editor
 texstudio-doc - LaTeX Editor (doc)
 texstudio-l10n - LaTeX Editor (localization)
Changes:
 texstudio (2.12.16+debian-1) unstable; urgency=medium
 .
   * Merging upstream version 2.12.16+debian.
   * Regenerating 01-removed-upstream-files.patch.
   * Adding 05-cleanup-appdata.patch in order to remove non-official
 AppStream tag from upstream appdata.xml.
   * Adding texstudio.appdata.xml to copyright file.
   * Mentioning new translations (br, sv) in control file.
   * Removing no longer needed dh_strip override for dbgsym-migration in
 rules file.
   * Removing no longer needed option --parallel from rules file.
   * Removing no longer present option --fail-missing from dh_install in
 rules file.
   * Switching to debhelper compat level 12.
   * Adding override for dh_missing to rules file.
   * Updating to standards version 4.4.1, no changes needed.
   * Adding false positive privacy-breach warning to lintian overrides.
   * Rebuilding upstream tarball without:
 - conflicting debian directory
 - conflicting .gitignore file
 - unused src/hunspell directory
 - unused src/pdfviewer/include_win32 directory
 - unused src/pdfviewer/include_win32_qt5 directory
 - unused src/quazip directory
 - unused qt translations
 - unused travis-ci directory and .travis.yml file
 - unused dictionary and thesaurus files
 - unused utilities/TexTablet directory
 - unused poppler-data directory
Checksums-Sha1:
 19ebee73f5ee61809b09c15df6f140f041bfdb4f 2081 texstudio_2.12.16+debian-1.dsc
 0dbf9073bfb2a4f129cd22e261261fac28b5625e 8504164 
texstudio_2.12.16+debian.orig.tar.xz
 202feea698dd77c9c74d9c797d180c21c58ed7d9 60892 
texstudio_2.12.16+debian-1.debian.tar.xz
 46dda11d6b498765ef15fe52a0864f2cd2e68341 31759804 
texstudio-dbgsym_2.12.16+debian-1_amd64.deb
 64dbd6fbf2107a2feb57b8c1cc61180a442885c9 2230044 
texstudio-doc_2.12.16+debian-1_all.deb
 5cbf87cb43659cc8fc87a1f0e91b80ba28912b91 698524 
texstudio-l10n_2.12.16+debian-1_all.deb
 14c5d425878a3fa2565d664b3e9275da58f4d2ca 12871 
texstudio_2.12.16+debian-1_amd64.buildinfo
 97e4f695f3f4da856d22457e225ed33b4c629987 5459084 
texstudio_2.12.16+debian-1_amd64.deb
Checksums-Sha256:
 080d9c707a7c58e178bafebe7821bd61e9eaee59400970eb1920153e7aa324d8 2081 
texstudio_2.12.16+debian-1.dsc
 63c1978106e134dee3f329478a895a82ef84cd6c7d2d8577108265f21659 8504164 
texstudio_2.12.16+debian.orig.tar.xz
 3b0bb8e546f80c7f8002f36607f0279c3558ade5795fda304c81218986ba06c2 60892 
texstudio_2.12.16+debian-1.debian.tar.xz
 32b6458c0f942d7088f655648bfb06b63b2943d97c2c5f1578e5bbb0c1780448 31759804 
texstudio-dbgsym_2.12.16+debian-1_amd64.deb
 23e2473ef06198a91a1a9cd3bf2fa921c2de4bc73e2efaef249bdb4cc55f83ff 2230044 
texstudio-doc_2.12.16+debian-1_all.deb
 55cd745adedab3219a63ff54e9733797f2e9db6d8b50b76d8e11f99ce3faaa56 698524 
texstudio-l10n_2.12.16+debian-1_all.deb
 9c9dba5cbaebf9ae0ff09dfa640bfcc354e63feb5746f9bd659a7347ac15d649 12871 
texstudio_2.12.16+debian-1_amd64.buildinfo
 4a8aff338c9ad457d3ea853be202d23eee330ecdae796b50cb4ad3e85a40837b 5459084 
texstudio_2.12.16+debian-1_amd64.deb
Files:
 91cdae3cb58e200c07ca9eb261e20d63 2081 editors optional 
texstudio_2.12.16+debian-1.dsc
 5e82213e40260d4b6fa6426e060bdf57 8504164 editors optional 
texstudio_2.12.16+debian.orig.tar.xz
 4eddab5b03542100ed68d7165a6d12d1 60892 editors optional 
texstudio_2.12.16+debian-1.debian.tar.xz
 9bc7355ca81b4ce28e966d9e9abd8c1f 31759804 debug optional 
texstudio-dbgsym_2.12.16+debian-1_amd64.deb
 378a4c30afa585f63ed08258391f29b0 2230044 doc optional 
texstudio-doc_2.12.16+debian-1_all.deb
 e0eb21915877afaa9c828916fc01f507 698524 localization optional 
texstudio-l10n_2.12.16+debian-1_all.deb
 e71db9c8ee360c2d52b1fff625d7521a 12871 editors optional 
texstudio_2.12.16+debian-1_amd64.buildinfo
 26fafa5b286938233aa1775d331f870b 5459084 editors optional 
texstudio_2.12.16+debian-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEnpMtHgsxz4UK/Hmebz5hUxY+BXcFAl3QWdMUHHRvbUBjcnlw
dG9ncmFwaHkuY2gACgkQbz5hUxY+BXdtvA/9HRwLP1RB978PplrutGu8eESUy6ZM
SoLP0CVC+sgHlDDMM4IxSW8zGpXV9hOyyfMRuXHC0Vj399zYuLj/e4VTc8Ohn7sq
tl1MkdnQkntnHaOMP75042YrBa2PvwGI6R3dUhWnWrrVsGFgkyY1Ei12Of+sTd/c
EGy8WXkldqgANu0A6xjx7w8GPEAj3Bq3S0YClGv1BmTcPmX9y6RP2amqOuLVkwcl
fcH+1SnK8/7WioYGaX6K6fIZ0LkAlZVsdqYNE2o7F2yFQNK+1zQn4aO99e7djJv2
18SvKeTnUhzFR/thNG8teyfw1zIcw9ezxIy4M/yt2erxodR9fvR3yrZ4c9wjA3XZ
Ess4nRG8ws1S4niGjy3tNnI2yK/SNl3AElrqCUE0DT5qXd5ThY1EHhnH4LM/ngRY
UA5Pq1eF/cwWc2gmtq/mScoYGDpJYg0hTLdAiP3wCd5RhVo668JgK6qX2GlTGmU2
ALycon5LlxttAvYk4lNLqZb0WSrohPXbh74I7o784HnLsb1epwqjciCgH+MMfhJ8
YGVf/j3vioE0HRoPnJWjILqVT5N1+BIgVCcMMF/9pCiu7u8k9g/xRH

Re: Debian event pre FOSDEM?

2019-11-16 Thread Holger Levsen
hi,

context for hsbxl.be folks:

On Sat, Nov 16, 2019 at 02:12:25PM +, Holger Levsen wrote:
> so at dc19 we came up with the idea of having a Debian event pre- or
> post-FOSDEM, an event like DebCamp or maybe a bug squashing party, so
> mostly self/unorganized.
> 
> The only thing we would need is suitable room, and probably someone
> paying for it.
> 
> And we'd need to agree on the dates. There's a ruby sprint after FOSDEM
> in Paris, so I suppose we should go with before FOSDEM.
> 
> One idea would be to do it in the Brussels hackerspace, if they are
> still in the same place as they were this year I think it would fit.
> Does anyone have contacts to them and could ask?
> 
> Anybody willing and able to go hunting for a suitable place in Brussels?
> I believe this should happen *now* as people already started to book their
> travels...
 
so I was just made aware of
https://lists.fosdem.org/pipermail/fosdem/2019q4/002944.html where the
Brussels hackerspace (HSBXL) offered their space
(https://media.hsbxl.be/intro.webm) for groups like us.

Assuming this offer still stands, I believe a group of Debian
enthusiasts would like to come by from Wednesday to Friday before
FOSDEM. Do you think that would be possible so that we can "officially"
start planning this?

I suppose that would mean creating a wiki page and collecting info who
will be attending so that we all have a better idea what will be
happening there. Assuming that FOSDEM attracts *many* Debian developers
(more than 100?) I'd expect at least 23 people showing up on Wednesday
(though wouldn't be surprised about less, it's a work week after all) and
maybe 42 on Friday... and as I remember the space from this FOSDEM I
think even 42+23 people would fit.

What do you think, can we, shall we, do this?


-- 
cheers,
Holger

-------
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature


Debian event pre FOSDEM?

2019-11-16 Thread Holger Levsen
hi,

so at dc19 we came up with the idea of having a Debian event pre- or
post-FOSDEM, an event like DebCamp or maybe a bug squashing party, so
mostly self/unorganized.

The only thing we would need is suitable room, and probably someone
paying for it.

And we'd need to agree on the dates. There's a ruby sprint after FOSDEM
in Paris, so I suppose we should go with before FOSDEM.

One idea would be to do it in the Brussels hackerspace, if they are
still in the same place as they were this year I think it would fit.
Does anyone have contacts to them and could ask?

Anybody willing and able to go hunting for a suitable place in Brussels?
I believe this should happen *now* as people already started to book their
travels...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature


Accepted debian-security-support 2019.11.16 (source) into unstable

2019-11-16 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 16 Nov 2019 11:00:08 +0100
Source: debian-security-support
Architecture: source
Version: 2019.11.16
Distribution: unstable
Urgency: medium
Maintainer: Holger Levsen 
Changed-By: Holger Levsen 
Changes:
 debian-security-support (2019.11.16) unstable; urgency=medium
 .
   * Add chromium to security-support-ended.deb9.
   * d/rules: update to NEXT_VERSION_ID=11.
Checksums-Sha1:
 9b615677001afd261248bcb79db2c5a70a150585 1857 
debian-security-support_2019.11.16.dsc
 366d1f97fdf4f0b9e37f7f9683b6cfb72edb5e34 30872 
debian-security-support_2019.11.16.tar.xz
 80b60ff07b183b4d1b4072a8fb63cfd86ab07fb7 6329 
debian-security-support_2019.11.16_source.buildinfo
Checksums-Sha256:
 aa1d8f12d176a83cf5a384265411695f9d67cfb52b2e8f67260236a89be7dc24 1857 
debian-security-support_2019.11.16.dsc
 37df85f156990e3275e3ff5ef47a432e8349976a1e8da3b4591605cae2b8e979 30872 
debian-security-support_2019.11.16.tar.xz
 c9cf2440c715b1f6768f0dbf1ae686cb31eb2ca5c7c3be716be5ea8eaca7178a 6329 
debian-security-support_2019.11.16_source.buildinfo
Files:
 1a317d183ed38e2ef1eaafc32afde7e3 1857 admin optional 
debian-security-support_2019.11.16.dsc
 d16623b1e4ef2bf72265c9a3f5271dcf 30872 admin optional 
debian-security-support_2019.11.16.tar.xz
 3ca3cccb2d72206dd4211adc5bfd5b7f 6329 admin optional 
debian-security-support_2019.11.16_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl3PyNoACgkQCRq4Vgaa
qhz+0Q//UX4diVQhejP86qXR2u4pQRbmOjACU0DxzXO1JMmxjC4USNsVQDHKyKpC
5+wX/UjOYh57BzpeUlyC249RMm8xHv7N5zoQaWOvIAf0+sgjMt7rF/cghWciGERJ
ZWnzmW32wK0TS8IqZTy8vngnO1LT1idXouYKfl7zA547v/Lh6KNsMTqAVT+rG48K
eWphjJGlpU0MGOTZEGRHk8JRL8ewqC5GVb+CXSSU9tqvq+XWsuucjL/Y0Xs5AOk6
78uUKcqONSG4VITilTlcxS6RGo82OtBsjuhvBpInDeG9GzH7I4pfOa0eYA7isrwO
trb3UoSLFRHs5UORoZjuVugJx6TjvdRz3jMQ4w56P/KudiR13LwOaADftINIUwZL
w7g7I9u2z1OFAHsdCV5cMLf7L2M212XlCvdWYOeFOn9+LrJHSRnePohx77qdzgqO
haalyR4laVHSe7532N0Pc5NzZGQoqo72kLPvi7HZUNSMjP0kkBt8cFccaI3jD4Xl
BuKGZlZ5Dc1qEKgk1pvVJkXSLS83yn70VF9qCpdwAkFI/jXmHy9P8lng/yFT8T4a
2gKQy1uELDCZU+AdkrjeIKwoYmJyKoFt9xl+o6QrG07lq3Xfz07hc13Del2bj+mv
hq4vUXrJ/ounItnvLKwWthPRGtYR1Ut5yBm3k1O6vU/zjq0St0M=
=V5oM
-END PGP SIGNATURE-



Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

2019-11-15 Thread Bernd Zeimetz



On 11/11/19 6:30 PM, Theodore Y. Ts'o wrote:
> Yes, and that's why I use debian/master instead of debian/buster or
> debian/bullseye.  :-)
> 
> When I do create debian/buster (once it became the stable branch), the
> first thing I did after I branched off debian/buster from
> debian/master was to edit debian/gbp.conf was to have:
> 
> debian-branch=debian/buster
> 
> I only do this when I need to do the first stable backport of a
> serious/security bug, such that I have to create the debian/buster
> branch in the first place.  So it hasn't been all that annoying for
> me.

+1
I do pretty much similar things in my repositories, and I neither want
people to mess with the way I choose branch names nor do NMUers want do
have to figure out which branch to use for what.
debian/gbp.conf is perfect for that, so please maintain it. It is very easy!

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



Accepted debian-security-support 2019.11.15 (source) into unstable

2019-11-15 Thread Roberto C. Sanchez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 15 Nov 2019 09:17:07 -0500
Source: debian-security-support
Architecture: source
Version: 2019.11.15
Distribution: unstable
Urgency: medium
Maintainer: Holger Levsen 
Changed-By: Roberto C. Sanchez 
Changes:
 debian-security-support (2019.11.15) unstable; urgency=medium
 .
   * Team upload.
   * Add libqb to security-support-ended.deb8.
Checksums-Sha1:
 fe45b573cd45b997db22fa7b279127ac059eef07 1857 
debian-security-support_2019.11.15.dsc
 aee1b798dc828a0176e14d989270abca2551d57f 30644 
debian-security-support_2019.11.15.tar.xz
 a56798b39eafcc29c5112ad78089dbae61600e62 6555 
debian-security-support_2019.11.15_amd64.buildinfo
Checksums-Sha256:
 9198ff6d6f0f43ed16858cff31a680ac7644e0ec90faefbbe2c96079afbe2a3a 1857 
debian-security-support_2019.11.15.dsc
 8809de43d2340947ac1bdce11c2359383b09004528051dbdfbb7b14ed3d0e904 30644 
debian-security-support_2019.11.15.tar.xz
 205148111e9a632c57f5069d8af652352761cab374a727ba13a41d70777461af 6555 
debian-security-support_2019.11.15_amd64.buildinfo
Files:
 45bbac5aeaea194fdceb4c1dba9b 1857 admin optional 
debian-security-support_2019.11.15.dsc
 681ba944f385b4a804bbfd89f5d4284d 30644 admin optional 
debian-security-support_2019.11.15.tar.xz
 9dbe796dd9dfdcde90346fba1285e0f2 6555 admin optional 
debian-security-support_2019.11.15_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEz9ERzDttUsU/BH8iLNd4Xt2nsg8FAl3OtjcACgkQLNd4Xt2n
sg/e5Q/+IQ3WDqstKaT5kcWLRNFYma6mhD0i5A7jY3EcJTqIw/MlWKFv+3tdZ5/I
3PmJZpr4zZwu4VPsh9+d2R2Pj5kicTDeflrza0pQBUQ3FP1Y1iOMuqwMT1auydwC
jVdE2eQ/3v3IDOLlQteLm/nUBNPGCEzaYmhNPTLe/zewRXXkNfEfW+QrIxuid92U
SsMyN9/j78CB4uVakwpGMBfJKK0E5yfUp6ApQgcObmoCGTbvtjv5qI7kjS1bKxSf
6iiIBS7g1FDqZchibgiHw7ATGEpXGz1Fzl0oy79jbMA13Ql9cWEE576CArNvUQ7I
EhX6cE0ZY5K6kI0K7sfoBGtlHdmPEjIoPLZoYPU7Ibf+vqyf7Y5R3KiJfaROvNNC
rjuFD+gj0w2cXhZn4PY8N76TMtmzoWSDIEAtr3TNnskGqacH1MKKycfH09cvWBUs
hp1k178oX2+MNOq5IJW9A0O9irqLVFa33FKgDWOTVviR2u/XT6oC6QklRSEsg6Ni
subTqa72XdO79MyqoX/DUG391JijmnvPYx6Q+cR77Kpk/0uP7dWIb3wb175wKqJe
zaVng9QaZvX/uewTiz12o3HYxzKiSyxywQRESzzNdqCAnqnUDU887GLBWF4UcdoO
xT6NjfQt5+xMpmPvdPkfTs+U3XqP/hOBpc9sO+qI/5Yr+aznmRQ=
=18Mf
-END PGP SIGNATURE-



Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

2019-11-14 Thread Thomas Goirand
On 11/14/19 1:59 AM, Jeremy Bicha wrote:
> Let me try to be more specific. Many packages are maintained by people
> who use gbp. Many packages have pristine-tar branches but do not have
> "pristine-tar = True" set. When I work on one of these packages (and I
> work on many packages with many maintainers), I need to have
> "pristine-tar = True" set in my ~/.gbp.conf. However, when I then want
> to work on an OpenStack package, I have to change my user config to
> set "pristine-tar = False".

No you don't. The only think you need is the orig tarball form the
archive in your build path.

Cheers,

Thomas Goirand (zigo)



Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

2019-11-14 Thread Simon McVittie
On Wed, 13 Nov 2019 at 19:59:07 -0500, Jeremy Bicha wrote:
> Let me try to be more specific. Many packages are maintained by people
> who use gbp. Many packages have pristine-tar branches but do not have
> "pristine-tar = True" set. When I work on one of these packages (and I
> work on many packages with many maintainers), I need to have
> "pristine-tar = True" set in my ~/.gbp.conf. However, when I then want
> to work on an OpenStack package, I have to change my user config to
> set "pristine-tar = False". This is a very manual process and I'm
> likely to make a mistake.

I think it's worth emphasizing that the options for which this is
valuable are exactly the options that affect interoperability with other
maintainers, or to put it another way, that affect what you commit.

For example, pristine-tar, debian-branch, upstream-branch and
upstream-vcs-tag affect what `gbp import-orig` does, so they need to be
the same for anyone who plans to import new upstream releases. I think
that means they make sense in d/gbp.conf for the reasons Jeremy stated.

If you prefer to use ignore-branch instead of debian-branch then that's
your choice, or perhaps your team's, and if you use that option then
maybe you don't need debian-branch; but when you import a new upstream
release you're not on the upstream branch, so `gbp import-orig` still
needs to know where the upstream-branch is.

Conversely, tarball-dir, export-dir and builder are personal preference
or local system configuration, and should not appear in d/gbp.conf, only
in ~/.gbp.conf or .git/gbp.conf. The first few packages I maintained with
git in Debian did have tarball-dir and export-dir in d/gbp.conf, mimicking
the way svn-buildpackage's directory properties worked; but that was a
bug, which I believe has now been fixed in everything I still maintain.

smcv



Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

2019-11-13 Thread Jeremy Bicha
On Tue, Nov 12, 2019 at 5:23 AM Thomas Goirand  wrote:
> On 11/11/19 12:50 PM, Jeremy Bicha wrote:
> > It is absolutely not possible to set the correct
> > pristine-tar=True/False in ~/.gbp.conf to work with your packages
> > (which avoid pristine-tar) and the vast majority of gbp packages in
> > Debian which do use pristine-tar. Those settings are specific to the
> > workflow for that repo, and everyone using that repo needs to use
> > those same settings to avoid issues.
>
> I don't think what you wrote above is correct. None of the options you
> mentioned are mandatory. If GBP doesn't see the use of pristine-tar, it
> will assume that we're using an upstream tag, which is fine.
> ...
> Besides this, nobody is forced to use gbp. Just typing "sbuild" to build
> a package is also perfectly valid. So why adding preferences for one set
> of tooling, when there's many alternatives? It doesn't make sense.

Let me try to be more specific. Many packages are maintained by people
who use gbp. Many packages have pristine-tar branches but do not have
"pristine-tar = True" set. When I work on one of these packages (and I
work on many packages with many maintainers), I need to have
"pristine-tar = True" set in my ~/.gbp.conf. However, when I then want
to work on an OpenStack package, I have to change my user config to
set "pristine-tar = False". This is a very manual process and I'm
likely to make a mistake.

Ideally, packages maintained by someone who wants to consistently use
pristine-tar will have that set in debian/gbp.conf and the minority of
maintainers who don't will have that set in debian/gbp.conf too.

While you could use sbuild to build gnome-calculator for instance, you
do have to use gbp to **maintain** gnome-calculator -- especially when
packaging new versions. That is because gnome-calculator is
team-maintained by the Debian GNOME team and we have guidelines for
how our packages are maintained [1]. To make life easier for
contributors, we enforce as many of those guidelines as possible in
debian/gbp.conf.

Similarly, you have guidelines for how OpenStack packaging updates and
bugfixes are handled and it seems to me like it would make a whole lot
more sense for you to explicitly "forbid" pristine-tar from being used
in your packages, as long as you are the maintainer and you believe
that pristine-tar is unsuitable for those packages.

[1] https://wiki.debian.org/Gnome/Git

Thanks,
Jeremy Bicha



Accepted debian-installer-utils 1.133 (source) into unstable

2019-11-13 Thread Holger Wansing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 13 Nov 2019 22:18:44 +0100
Source: debian-installer-utils
Architecture: source
Version: 1.133
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Holger Wansing 
Changes:
 debian-installer-utils (1.133) unstable; urgency=medium
 .
   * Team upload
 .
   [ Updated translations ]
   * Amharic (am.po) by leela
   * Croatian (hr.po) by gogogogi
Checksums-Sha1:
 c9a2c8b49b5e4cc835d06577ac25387bd1eb412f 2231 debian-installer-utils_1.133.dsc
 bde203b2156e82479e4a4a00d2c68cf50b5c021e 99316 
debian-installer-utils_1.133.tar.xz
 51eb4eac49c79116e842757bf821950f549a8e4c 7067 
debian-installer-utils_1.133_amd64.buildinfo
Checksums-Sha256:
 1ead7c7ff0f421cd9dff5aee69a9ff04f3a26e187fa3c88ca33a54e873a72e82 2231 
debian-installer-utils_1.133.dsc
 d5d4e1b5cfe72a581361e0fa21203e74906b3e3c9f780ad299a7d686a6fc1c98 99316 
debian-installer-utils_1.133.tar.xz
 4baa2ddd849ac6ce8ca9e13189eda733b4c82e2efe1bf6c7b33d8ac6514c90f7 7067 
debian-installer-utils_1.133_amd64.buildinfo
Files:
 505acfd0717c79c6dbd9893c0bb41ae8 2231 debian-installer standard 
debian-installer-utils_1.133.dsc
 50790e12c37b9de8b3af289665610b6c 99316 debian-installer standard 
debian-installer-utils_1.133.tar.xz
 6c3db8ba7efa9e8ee75f1e3668f61733 7067 debian-installer standard 
debian-installer-utils_1.133_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJJBAEBCAAzFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAl3MdcQVHGh3YW5zaW5n
QG1haWxib3gub3JnAAoJEFnxh8oVbrB2NBAP/RW3z4zwjRfOhy7Dydrq14aEy6BZ
OnUkDYUpmb9ZK80ggLdDyti7MnsOK7IjDCc+MuvRg+bimRQi6P74GqJNeDlNxHY2
oMr99KtQQEvb5oxrwXXHj5KEo1R2xvE0oGQxXpDFOoerZm9bk5Qm7sOgbk2IUL1U
v/qY1fjSlesz0pZwz3mdQCEr4VO/js/dTNjbe7g6cBrsATtHwj/fwEoabDMWbuXm
5Ok8sjv7pvNiXjuaRiPYua6ffiJtA1peIthPTxDfUqVkQNrypzzcigIq4R1xULzy
tC1WKCvBiN1BkipBVdICqiZZBPRyRZAGVcNRvL7G1NbFqK/4/2rhX3XIlThUBaHU
tEAoROF1uwPQQIGpNrcxSsdn5eHuaGirjDFvfQ9Bs4r6khyDMeQrtz+zKkMF/cgl
BO0Mm7xps0soXMviFILRhc3KXhQByCmMfbY7n8Yx49bvhzSGRV7woWgXQdvSV75x
gUtOU4pzGAQsymm5HeujIbwJ23poSMieN/va4PfzB87xNfm46E//JcAN681sTXAa
IYGTVrSTj6yNoatC7IG3Q9gwlFU37F/B6mgvQBnyDfEOjN7Zd0q+us+lBiNpx6bD
4iz9yYEfXCQdy37nF0vt+Kz49/E+eePJjOsocETAIsoJGxif1rDJQJ4Qaomi4D+X
6BusE4mrMx8PPa9P
=cWhH
-END PGP SIGNATURE-



Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

2019-11-13 Thread Thomas Goirand
On 11/13/19 1:53 PM, Andreas Tille wrote:
> Except for not agreeing with your opinion about pristine-tar I agree that
> debian/gbp.conf is frequently not very helpful and flooded with unneeded
> options sometimes.  It really makes sense to use ~/.gbp.conf instead.

This was the single and only point I was trying to make, and I wasn't
trying to convince anyone about anything else! :)

Cheers,

Thomas Goirand (zigo)



Re: please avoid writing useless/annoying stuff in debian/gbp.conf

2019-11-13 Thread Russ Allbery
Andreas Tille  writes:

> From time to time I hear this statement.  I can confirm that in all
> teams I'm working on pristine-tar belongs to the team policy and I never
> experienced in those > 2000 packages I've touched any problem with this.
> For me this makes some statistically relevant set which makes me believe
> that blaming pristine-tar to be broken in many ways is exaggerating and
> should not become a reason to force standard options that would really
> break pristine-tar.

My understanding is that most of the problems with pristine-tar come with
time.  If the tarballs and delta files are created and then read by
software versions reasonably close in time to each other, it generally
works.  The more obscure or ancient the versions of tar and xz were, or
the more options were used, to create the tarballs, the more likely that
if you go back to oldstable and try to recreate the tarballs, you may have
problems.

I'm personally fine with that as a pristine-tar user since I consider it a
convenience rather than a primary data store.  If it works, I don't have
to go find the upstream tarball.  If it doesn't work, I can download the
upstream tarball from the archive and use it directly, and all that
pristine-tar failing costs me is some time.

-- 
Russ Allbery (r...@debian.org)  



Re: please avoid writing useless/annoying stuff in debian/gbp.conf

2019-11-13 Thread Andreas Tille
On Mon, Nov 11, 2019 at 11:37:06AM -0800, Russ Allbery wrote:
> "Theodore Y. Ts'o"  writes:
> 
> > Yes, and that's why I use debian/master instead of debian/buster or
> > debian/bullseye.  :-)
> 
> > When I do create debian/buster (once it became the stable branch), the
> > first thing I did after I branched off debian/buster from debian/master
> > was to edit debian/gbp.conf was to have:
> 
> > debian-branch=debian/buster
> 
> > I only do this when I need to do the first stable backport of a
> > serious/security bug, such that I have to create the debian/buster
> > branch in the first place.  So it hasn't been all that annoying for me.
> 
> +1 this is my approach too.

I fully agree that

debian-branch=debian/RELEASE
debian-branch=debian/RELEASE-backports

is in the (partly unwritten) team policy of all teams I know for
backports and security updates.  Otherwise it is master (sometimes
debian/master).

Kind regards

   Andreas.

-- 
http://fam-tille.de



Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

2019-11-13 Thread Andreas Tille
On Tue, Nov 12, 2019 at 11:23:08AM +0100, Thomas Goirand wrote:
> 
> If you're rebuilding a package which is already in the archive, you're
> supposed to take the .orig.tar.xz from the archive, and if not, you're
> supposed to generate it with git archive (or with the shortcut for that
> command: ./debian/rules gen-orig-xz). Either ways, you don't need to set
> pristine-tar to do that.

... but there are teams that rely successfully on pristine-tar which
solves the problem you describe at least to my experience perfectly.
 
> I also think this should become the default too:
> no-create-orig = True

Please don't.
 
> because otherwise, you easily get a generated wrong file, which will not
> be the same as the archive one (because pristine-tar is broken in many
> ways, as many of us know already).

>From time to time I hear this statement.  I can confirm that in all
teams I'm working on pristine-tar belongs to the team policy and I never
experienced in those > 2000 packages I've touched any problem with this.
For me this makes some statistically relevant set which makes me believe
that blaming pristine-tar to be broken in many ways is exaggerating and
should not become a reason to force standard options that would really
break pristine-tar.

> Besides this, nobody is forced to use gbp. Just typing "sbuild" to build
> a package is also perfectly valid. So why adding preferences for one set
> of tooling, when there's many alternatives? It doesn't make sense.

Except for not agreeing with your opinion about pristine-tar I agree that
debian/gbp.conf is frequently not very helpful and flooded with unneeded
options sometimes.  It really makes sense to use ~/.gbp.conf instead.

Kind regards

  Andreas. 

-- 
http://fam-tille.de



Accepted debian-edu-config 2.11.9 (source) into unstable

2019-11-13 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 13 Nov 2019 10:07:29 +0100
Source: debian-edu-config
Architecture: source
Version: 2.11.9
Distribution: unstable
Urgency: medium
Maintainer: Debian Edu Developers 
Changed-By: Holger Levsen 
Closes: 944450
Changes:
 debian-edu-config (2.11.9) unstable; urgency=medium
 .
   [ Wolfgang Schweer ]
   * share/debian-edu-config/tools/kerberos-kdc-init:
 - Update kdc.conf content from template shipped with the krb5-kdc package.
   This fixes the recently broken Kerberos setup.
   * Replace workaround for rootCA certificate integration (both firefox-esr and
 thunderbird 68.2.x) with a nowadays recommended setup: (Closes: #944450)
 - Add policy file share/firefox-esr/distribution/policies.json.
   This makes sure that the Debian-Edu_rootCA.crt file gets installed as
   trusted certificate for firefox-esr and thunderbird.
   The policy also forces the Debian Edu startpage to be shown (instead of
   the Firefox one) at first launch; the Firefox privacy page is available
   via a second tab.
 - Drop share/debian-edu-config/{installs.ini,profiles.ini,profiles.ini.ff}.
   These files are no longer required.
 - Adjust related tools:
   + share/debian-edu-config/tools/gosa-create
   + share/debian-edu-config/tools/create-user-nssdb
   + share/debian-edu-config/tools/update-cert-dbs
   + ldap-tools/ldap-debian-edu-install
 - Adjust Makefile.
   * Drop workaround now that Squid bug #911325 has been fixed:
 - Remove share/debian-edu-config/squid.resolvconf
 - Adjust Makefile and cf3/cf.workarounds.
Checksums-Sha1:
 5e5b1f52ea50ccc22c3a4378a560017b54aab5a5 1914 debian-edu-config_2.11.9.dsc
 762f51a21163a29f913009a1aa6d6966d999ae94 340448 debian-edu-config_2.11.9.tar.xz
 b9ce2dc961381ca6bafa8f8d87202947a2f77cb9 5283 
debian-edu-config_2.11.9_source.buildinfo
Checksums-Sha256:
 417bb9830ab36099e616d1c42685825a8cd38e7752d87f59cfd09fe25efbbd11 1914 
debian-edu-config_2.11.9.dsc
 84462a8a28955718ddff665d9d6ca5970ba983ad68ffaae0aa45d2c256fa022d 340448 
debian-edu-config_2.11.9.tar.xz
 070706fe0b047e594cd6785c886444aeadd5bf5203ca522dd93d0184eaccc7cf 5283 
debian-edu-config_2.11.9_source.buildinfo
Files:
 2ca7e9b314587e669b52d876d5cba7df 1914 misc optional 
debian-edu-config_2.11.9.dsc
 60dd757c49f7d6db735cf56f466bb975 340448 misc optional 
debian-edu-config_2.11.9.tar.xz
 72f9e662cf7633310b9424128d4349d1 5283 misc optional 
debian-edu-config_2.11.9_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl3LyUMACgkQCRq4Vgaa
qhyFoRAAgUSNHA13BgbpejuwO5jgzwFhps/pkwh+3Hks/PiN2YQQGfSl/sTwSqCU
LHw8vnWJU1i/bj8rIb6Mo449DyRARdQJZyUNPAPWgPbOOJpA1n19TzgxBlPAuAW+
iMxj4rJOZJpJL6T6HzYFxokpi4B3uUJfH/VI2NezlWpE8qQp+V+80ioQrPFTdAk5
aifdDEbd8aomAgmVRbY3DCF641MF7n7e8DL9VZXR9mohQf+8SaJahEFiw9FYCqrI
mkXOQJcTjSHzSZQ7o6tWLBhBCYZuEr9xEEOsg4wQCrUNWv5dwBwYtTflCdtV9b4S
Y80AaUgZ0uG0zR9dSed9NObHrtrEqquNxfnwL0UwfUw9Ctqd5TD4ig2QxdoMQg80
4LXFBInqKAuk1ubT1MuTwF3A+FedRW7lOGBqdneWYR5143SmdIfLOoXabhVn//jv
/QOwn7f5CEVKjgzYGGmzdo4ckbzuYxb0uvDe5zG6l0iLRJf+dC/qopF17IxgSqGL
iNX7vACEL0aybMvLBu3lB8B/Gk0W5GAcVbNIjFXL07yWBNXKLqf1e6OGnt/wanVf
PeRJ9WK4TQU4HRZEvSPFOXhq6wB0Q62T9kmauAzXAgvnLdQsqfdZqq//0DsBVjXW
V5jChP9yLlMXX6dsvJkE3L/lPz2BbNo1F1Sh3jyPFB6GHPM11/c=
=1ZRF
-END PGP SIGNATURE-



Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

2019-11-12 Thread Thomas Goirand
On 11/11/19 12:50 PM, Jeremy Bicha wrote:
> On Mon, Nov 11, 2019 at 2:59 AM Thomas Goirand  wrote:
>> On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote:
>>> On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote:
>>>>
>>>> Please, *never* do that. It's generally a very bad idea to write
>>>> anything to debian/gbp.conf. It's as if you were adding your text editor
>>>> preferences in the package. Instead, please prefer writing in ~/.gbp.conf.
>>>
>>> I keep most of my git-buildpackage settings which are specific to my
>>> developer environment in ~/.gbp.conf.  However, there are some gbp
>>> settings which are specific to the repository set up, and those I
>>> think, IMHO, *are* appropriate for debian/gbp.conf.  For example:
>>>
>>> [DEFAULT]
>>> pristine-tar = True
>>> upstream-tag='v%(version)s'
>>> debian-branch=debian/master
>>
>> The first 2, yes. The last one, it's my opinion that it's useless, and
>> that you only need it because "ignore-branch = True" isn't the default
>> in git-buildpackage. It's ok as long as you always keep the same
>> packagig branch, but if, like in my team, we need a new branch name
>> every 6 months, and for 400+ repositories, then keeping the branch name
>> declared in debian/gbp.conf becomes super annoying (as it forces one to
>> change the "debian-branch" each time).
> 
> Could you please add debian/gbp.conf back to your packages? As I
> understand it, I think your preferred settings would look something
> like this:
> 
> [DEFAULT]
> ignore-branch = True
> pristine-tar = False
> 
> [buildpackage]
> sign-tags = True
> 
> [dch]
> multimaint-merge = True
> 
> [import-orig]
> upstream-tag = %(version)s
> 
> [pq]
> patch-numbers = False
> 
> 
> 
> It is absolutely not possible to set the correct
> pristine-tar=True/False in ~/.gbp.conf to work with your packages
> (which avoid pristine-tar) and the vast majority of gbp packages in
> Debian which do use pristine-tar. Those settings are specific to the
> workflow for that repo, and everyone using that repo needs to use
> those same settings to avoid issues.

Hi Jeremy,

I don't think what you wrote above is correct. None of the options you
mentioned are mandatory. If GBP doesn't see the use of pristine-tar, it
will assume that we're using an upstream tag, which is fine.

If you're rebuilding a package which is already in the archive, you're
supposed to take the .orig.tar.xz from the archive, and if not, you're
supposed to generate it with git archive (or with the shortcut for that
command: ./debian/rules gen-orig-xz). Either ways, you don't need to set
pristine-tar to do that.

So, as I wrote, the only single thing you need, is:
ignore-branch = True

and it is my view that it should be good to have it become the default.

I also think this should become the default too:
no-create-orig = True

because otherwise, you easily get a generated wrong file, which will not
be the same as the archive one (because pristine-tar is broken in many
ways, as many of us know already).

Besides this, nobody is forced to use gbp. Just typing "sbuild" to build
a package is also perfectly valid. So why adding preferences for one set
of tooling, when there's many alternatives? It doesn't make sense.

Cheers,

Thomas Goirand (zigo)



Re: please avoid writing useless/annoying stuff in debian/gbp.conf

2019-11-11 Thread Russ Allbery
"Theodore Y. Ts'o"  writes:

> Yes, and that's why I use debian/master instead of debian/buster or
> debian/bullseye.  :-)

> When I do create debian/buster (once it became the stable branch), the
> first thing I did after I branched off debian/buster from debian/master
> was to edit debian/gbp.conf was to have:

> debian-branch=debian/buster

> I only do this when I need to do the first stable backport of a
> serious/security bug, such that I have to create the debian/buster
> branch in the first place.  So it hasn't been all that annoying for me.

+1 this is my approach too.

-- 
Russ Allbery (r...@debian.org)  <https://www.eyrie.org/~eagle/>



Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

2019-11-11 Thread Theodore Y. Ts'o
On Mon, Nov 11, 2019 at 08:58:42AM +0100, Thomas Goirand wrote:
> >> Please, *never* do that. It's generally a very bad idea to write
> >> anything to debian/gbp.conf. It's as if you were adding your text editor
> >> preferences in the package. Instead, please prefer writing in ~/.gbp.conf.
> > 
> > I keep most of my git-buildpackage settings which are specific to my
> > developer environment in ~/.gbp.conf.  However, there are some gbp
> > settings which are specific to the repository set up, and those I
> > think, IMHO, *are* appropriate for debian/gbp.conf.  For example:
> > 
> > [DEFAULT]
> > pristine-tar = True
> > upstream-tag='v%(version)s'
> > debian-branch=debian/master
> 
> The first 2, yes. The last one, it's my opinion that it's useless, and
> that you only need it because "ignore-branch = True" isn't the default
> in git-buildpackage. It's ok as long as you always keep the same
> packagig branch, but if, like in my team, we need a new branch name
> every 6 months, and for 400+ repositories, then keeping the branch name
> declared in debian/gbp.conf becomes super annoying (as it forces one to
> change the "debian-branch" each time).

Yes, and that's why I use debian/master instead of debian/buster or
debian/bullseye.  :-)

When I do create debian/buster (once it became the stable branch), the
first thing I did after I branched off debian/buster from
debian/master was to edit debian/gbp.conf was to have:

debian-branch=debian/buster

I only do this when I need to do the first stable backport of a
serious/security bug, such that I have to create the debian/buster
branch in the first place.  So it hasn't been all that annoying for
me.

Cheers,

- Ted



Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

2019-11-11 Thread Jeremy Bicha
On Mon, Nov 11, 2019 at 2:59 AM Thomas Goirand  wrote:
> On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote:
> > On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote:
> >>
> >> Please, *never* do that. It's generally a very bad idea to write
> >> anything to debian/gbp.conf. It's as if you were adding your text editor
> >> preferences in the package. Instead, please prefer writing in ~/.gbp.conf.
> >
> > I keep most of my git-buildpackage settings which are specific to my
> > developer environment in ~/.gbp.conf.  However, there are some gbp
> > settings which are specific to the repository set up, and those I
> > think, IMHO, *are* appropriate for debian/gbp.conf.  For example:
> >
> > [DEFAULT]
> > pristine-tar = True
> > upstream-tag='v%(version)s'
> > debian-branch=debian/master
>
> The first 2, yes. The last one, it's my opinion that it's useless, and
> that you only need it because "ignore-branch = True" isn't the default
> in git-buildpackage. It's ok as long as you always keep the same
> packagig branch, but if, like in my team, we need a new branch name
> every 6 months, and for 400+ repositories, then keeping the branch name
> declared in debian/gbp.conf becomes super annoying (as it forces one to
> change the "debian-branch" each time).

Could you please add debian/gbp.conf back to your packages? As I
understand it, I think your preferred settings would look something
like this:

[DEFAULT]
ignore-branch = True
pristine-tar = False

[buildpackage]
sign-tags = True

[dch]
multimaint-merge = True

[import-orig]
upstream-tag = %(version)s

[pq]
patch-numbers = False



It is absolutely not possible to set the correct
pristine-tar=True/False in ~/.gbp.conf to work with your packages
(which avoid pristine-tar) and the vast majority of gbp packages in
Debian which do use pristine-tar. Those settings are specific to the
workflow for that repo, and everyone using that repo needs to use
those same settings to avoid issues.

On the other hand, there are some developer-level preferences like
export-dir and "pbuilder = True". Those should not be in the repo's
debian/gbp.conf but they should be in ~/.gbp.conf .

Thanks,
Jeremy Bicha



Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

2019-11-10 Thread Thomas Goirand
On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote:
> On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote:
>>
>> Please, *never* do that. It's generally a very bad idea to write
>> anything to debian/gbp.conf. It's as if you were adding your text editor
>> preferences in the package. Instead, please prefer writing in ~/.gbp.conf.
> 
> I keep most of my git-buildpackage settings which are specific to my
> developer environment in ~/.gbp.conf.  However, there are some gbp
> settings which are specific to the repository set up, and those I
> think, IMHO, *are* appropriate for debian/gbp.conf.  For example:
> 
> [DEFAULT]
> pristine-tar = True
> upstream-tag='v%(version)s'
> debian-branch=debian/master

The first 2, yes. The last one, it's my opinion that it's useless, and
that you only need it because "ignore-branch = True" isn't the default
in git-buildpackage. It's ok as long as you always keep the same
packagig branch, but if, like in my team, we need a new branch name
every 6 months, and for 400+ repositories, then keeping the branch name
declared in debian/gbp.conf becomes super annoying (as it forces one to
change the "debian-branch" each time).

Cheers,

Thomas Goirand (zigo)



Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

2019-11-10 Thread Theodore Y. Ts'o
On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote:
> 
> Please, *never* do that. It's generally a very bad idea to write
> anything to debian/gbp.conf. It's as if you were adding your text editor
> preferences in the package. Instead, please prefer writing in ~/.gbp.conf.

I keep most of my git-buildpackage settings which are specific to my
developer environment in ~/.gbp.conf.  However, there are some gbp
settings which are specific to the repository set up, and those I
think, IMHO, *are* appropriate for debian/gbp.conf.  For example:

[DEFAULT]
pristine-tar = True
upstream-tag='v%(version)s'
debian-branch=debian/master

If you are going to be cloning the e2fsprogs repository and wanting to
use gbp-buildpackage, you *will* want to use these settings, and
putting them in ~/.gbp.conf doesn't work well, since they won't apply
for all packages that they might want to build.

Regards,

- Ted



Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

2019-11-10 Thread Thomas Goirand
On 10/5/19 7:48 PM, Attila Szalay wrote:
> I added the "pbuilder-options = --source-only-changes" option to the
> [buildpackage] part of the debian/gbp.conf

Please, *never* do that. It's generally a very bad idea to write
anything to debian/gbp.conf. It's as if you were adding your text editor
preferences in the package. Instead, please prefer writing in ~/.gbp.conf.

Just an example: if someone is using pbuilder, and wants to add a new
binary to your package, then your debian/gbp.conf will be super
annoying, because in such case, we need to upload *with* binaries (as
source-only uploads aren't possible in the NEW queue).

Also, please remember that not everyone is using git-buildpackage, and
that nobody is ever, forced to do so, even when using git for packaging
(just calling plain sbuild works perfectly, for example).

A few years ago, we decided to *completely* remove all traces of
debian/gbp.conf inside the OpenStack team, and I very much enjoy this
choice. The only annoying bit, is that now, everyone *must* write in
~/.gbp.conf this:

[DEFAULT]
ignore-branch = True

By the way, it'd be nice if it became the default in git-buildpackage.
This missleads everyone into writing a debian/gbp.conf just in order to
tell git-buildpackage what branch to build with.

Cheers,

Thomas Goirand (zigo)



Accepted debian-edu 2.11.6 (source) into unstable

2019-11-09 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 10 Nov 2019 10:56:50 +0800
Source: debian-edu
Architecture: source
Version: 2.11.6
Distribution: unstable
Urgency: medium
Maintainer: Debian Edu Developers 
Changed-By: Holger Levsen 
Changes:
 debian-edu (2.11.6) unstable; urgency=medium
 .
   [ Wolfgang Schweer ]
   * debian/control.stub: (education-menus) Drop Depends on desktop-profiles.
 The menu reorganization is now managed via XDG; it applies for all users.
 The concept of group specific desktop icons is gone since a long time, too.
   * Remove no longer needed files debian-edu-menus.listing and 
menus/is-enabled.
   * Adjust debian/{education-menus.install,education-menus.postinst}.
   * debian/control: Update after running 'make dist'.
Checksums-Sha1:
 4466f5bde2df80f652c3f86b1bf21fb03d0f7db8 4768 debian-edu_2.11.6.dsc
 40346b1b491c5c239054c3d3ff8c80f3c85715cc 118956 debian-edu_2.11.6.tar.xz
 e56eca27ef919fe9c2544620d0dd10171fa6ae6b 6735 
debian-edu_2.11.6_source.buildinfo
Checksums-Sha256:
 73c86363906f48429f3f28e4aab263a43c1cb0d4675b71a7dad40b0a6d194b60 4768 
debian-edu_2.11.6.dsc
 0fbe5913b731a6e3cfee47db5bb64011dbcd3f0f8ee6347ea6634704f752c67c 118956 
debian-edu_2.11.6.tar.xz
 c6fc652d911d9bc837e03c65bd42586b66574fa82c2fc84510d34024d0f8ba18 6735 
debian-edu_2.11.6_source.buildinfo
Files:
 34d321305707eb21439b4fd17166658b 4768 metapackages optional 
debian-edu_2.11.6.dsc
 901e61ad140cd67bb55928ad7e5a6616 118956 metapackages optional 
debian-edu_2.11.6.tar.xz
 df793efc46d39f7a8b9bc86923a11fa4 6735 metapackages optional 
debian-edu_2.11.6_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl3HfSsACgkQCRq4Vgaa
qhyo2g//ekQMNXtigIvhCFjw410uQPvaoE9i5ICp5hYzdC3Esf2t9IGAQi4Qz7+5
kj6ez14djs3j1ECxij/OhQRbraiC9Wu1qMKdMOHlGqj+P8jRslfIoBpznfGELX4r
svCPwvC58ZEyw6i8WrVwC5wi1fcyG/4GM/SxUt+WgTHIJFoxYKEhThTjbNy4GZ2q
Z6Q4mvSyv5ox4BW5FNDroP7RxaR1BlXZKMjK2/v2me9QRxpz7rMPuk/1cEnzABJM
RHYOZ1tfCB/w1uMG29D5M4/I0otSzKklhZacpYIX4PTGlS/uyD0QIBjetcKQBQoI
K6MJBqbpUjhHMAoFrTTL12lXfgTwjXMDPEJa814IuYn5rxdukBuwcvn1rQfWhTog
Za25LleP1/WxgWFGYPIuSU+DOZ6JGl0Y9CifGnR546/lpzf7gaStbgROZ/mXGU9n
8b8AanL0u9P8igeCvyAIg41RdJyH1QS8aN17CpulYU50lwqlwqNlaCxtYMlykaRM
UjAAHqr6i0/KD/uEp8useNTgkx96/gaHStKSbROj+80x+BRGnjt3q/E4pnvbmPfO
dHWsRjJ4icGo8uWJXc5bQVijP40B/PnMsa0sC/KBPvC4QvRNsvfn7YbVZgyS1LJ/
C1YW0i96NdHvOMUeY7wyrSFD1EpX9cpA6nlUgaxmc23/Y+hzXFU=
=6Sii
-END PGP SIGNATURE-



Accepted gradle-debian-helper 2.1 (source) into unstable

2019-11-08 Thread Andrius Merkys
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 08 Nov 2019 08:05:55 -0500
Source: gradle-debian-helper
Architecture: source
Version: 2.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Java Maintainers 

Changed-By: Andrius Merkys 
Closes: 934729
Changes:
 gradle-debian-helper (2.1) unstable; urgency=medium
 .
   * Team upload.
   * Implementing support for dh_auto_test (Closes: #934729).
Checksums-Sha1:
 902c3f443823a9760ef0679d9833b5fd5d6b77e7 1815 gradle-debian-helper_2.1.dsc
 3410bad0c7c927b75a1fccd869b3c8e223d286c4 14868 gradle-debian-helper_2.1.tar.xz
 32e6f0d9c9c6681bd55e1a920fda12604e7a0cd3 14700 
gradle-debian-helper_2.1_source.buildinfo
Checksums-Sha256:
 3e35cd9abe0b638f51b904525364285c79899fbf24fc9ea625b03659eb0ed8ea 1815 
gradle-debian-helper_2.1.dsc
 8dc79a17e7101e01343677e964aa768218031a6a1f9066e3a8ec8181a8939218 14868 
gradle-debian-helper_2.1.tar.xz
 e4fa4c242c944bfd4b4978ee24f68a5e2fe62a83b550238a2c9856e1d9e8b636 14700 
gradle-debian-helper_2.1_source.buildinfo
Files:
 98b99a6a6846d78f595a8b7f276bdbf4 1815 java optional 
gradle-debian-helper_2.1.dsc
 b7e05f386b6faa20c7bbe85530f7f47a 14868 java optional 
gradle-debian-helper_2.1.tar.xz
 f7ac19efff83c6a9a0f2cef7831eace9 14700 java optional 
gradle-debian-helper_2.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEdyKS9veshfrgQdQe5fQ/nCc08ocFAl3FagESHG1lcmt5c0Bk
ZWJpYW4ub3JnAAoJEOX0P5wnNPKHTpgQAIKDxI+0rw92v6VsDlJ5mW0hX18f2ZKC
nefO84WhLtOa6T29TWQryrOr1ZgqG9BYmgv6v4z7R+CrdjjoOKFoFv5PNi2LCT9u
qqPjq5fOR5NwAEnoJg+ixYUXCQ9rbr/lQa4xuuQ7p1tmDqLQJnVYsJdwMtDTuLlp
atdEAQa7hPNaHBFrXxEwJw272MVUfolvyg5XQIwq+bu2my+t140aj/r7lw7apzPN
B2fI0f+UYGPfgqoVgXdLs6xSylJ+pXJ2J0j575R2BPRCd9ddaz68OI5cF8cxGx0z
BgR6yqOIK7gj/h4OAnWc//ENl3aJX3rg32rfUNehWA764Rl2YJOPAmrhkyL29cOP
fDSJUROYHKIdtQQtjHUbAa/pWJLCCX6dJ3WZ0oqRiyj84UKF3Try9xCIVJoCXBbz
vLpayUQrJvTUazfyqTSpf8jx74Mmf9aGvwTXXrFrLhCBE2MActFCjr/VxsR1OrRp
Jc5Tum353wjVRgzst66BhddljVGuRuYHBSnyeuhDaVOhEd+zDpy0DLvDY44Ipaom
QqUVkhw/XvqvIL/rLs2puRMfDZD0yfPZz6rIahQIG4I3MGNonunHY/CEkqa1luDv
HoaYkUf4t1QyAh2Pcu6OGhdIY+6wM9Fd9bfQsv9qS2ZHiIuFu4QfzugJ2+/QYYeR
ExYFUeCkVFfh
=TqQb
-END PGP SIGNATURE-



Accepted debian-ports-archive-keyring 2019.11.05 (source) into unstable

2019-11-05 Thread Aurelien Jarno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 05 Nov 2019 22:26:10 +0100
Source: debian-ports-archive-keyring
Architecture: source
Version: 2019.11.05
Distribution: unstable
Urgency: medium
Maintainer: Aurelien Jarno 
Changed-By: Aurelien Jarno 
Changes:
 debian-ports-archive-keyring (2019.11.05) unstable; urgency=medium
 .
   * Move the 2018 key (ID: 06AED62430CB581C) to the removed keyring.
   * Increase the expiration date of the 2020 key (84C573CD4E1AFD6C) by one
 year. Thanks to James Clark for the notice it was off by one year.
   * Add "Debian Ports Archive Automatic Signing Key (2021)
 " (ID: 5A88D659DCB811BB).
Checksums-Sha1:
 80a8461350d843cd73b7bb92da8194432691a4f4 1652 
debian-ports-archive-keyring_2019.11.05.dsc
 b53328dd0c4b40f3fe1394c37e51feea127b3a6b 28788 
debian-ports-archive-keyring_2019.11.05.tar.xz
 ca4bb9553860aa71ff0303458ab17b56e80cc5e0 11642 
debian-ports-archive-keyring_2019.11.05_source.buildinfo
Checksums-Sha256:
 5d7da805cb17aff471e7547ba5ad1d9224a265c67660b97a43334c32b137e034 1652 
debian-ports-archive-keyring_2019.11.05.dsc
 5bbda735c2ff3a24e8da52791968a5b6af0a1949f7802a6e2a4a37f0fa08257b 28788 
debian-ports-archive-keyring_2019.11.05.tar.xz
 69630200f410ffda64fde99f6e61d5bc0b90a29816b7cccaaec0fb1f05a2911c 11642 
debian-ports-archive-keyring_2019.11.05_source.buildinfo
Files:
 3badaefbc9fc246e1af3201fc54565cd 1652 misc optional 
debian-ports-archive-keyring_2019.11.05.dsc
 4af8841bcd8b673ab0ce138051970f13 28788 misc optional 
debian-ports-archive-keyring_2019.11.05.tar.xz
 3696e8d9cc811c6482c447d1b7f548d1 11642 misc optional 
debian-ports-archive-keyring_2019.11.05_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAl3B6PkACgkQE4jA+Jno
M2t7pQ/+LCw8A8D2/NmXFWF/8bbbElNeiGzJGa1l6GkuhODBzhPyKwNuNJtKL8Fh
n9EsLmG1KXGCMUoL1Hs3ZJWdjf3lwc4Bu0MjiirxT8LkILtE1JNbYq0iTzEK+KAX
VxbvSBPhsNPu/vXNI9DCe6p5SncgqV8ecWRR9hlkHSQ7tFktev4WFUaZnJ6AIzpq
LiX448I0m/dxNXu/KVhe4iCl4vCLaBIFrGKFlBO1WoEHOIjambDjzFhNzS8nyW2o
1YWh1jOLGTW07NAJUv1/UhO40jo1JKQQG4AMD7PHW2vyF6qdlRE9qgrUe+mmJcAn
iTWWfVgOfd1IIIo8LbzmY6+p5oEmT/XmTiS4+k2/UIggzW9HYe429FQpWtng/PCZ
8CY53w2EYZ3nUWQyIhAGKftv3cN63v5upp2MzFJ57SqHTX0iSfC+BexMZ6IYUvyW
mfeqZG+9R+FaLr/aT7ittxF/cw3MsP5cOxu9vnwcSWrQd8JjhON9KQ4CKVdY/DDp
zwurjkW0kyo0xpZldoVvfNCfpBJ7vny0BOuAqtSsG4Fg+P+eSHsD+1NCccOrfYNQ
bby+iB7423NPgRwm7OOB4Tm6yU3wJGO6kNXsKNdgyIVbxd/NAumvqS6cuAPnsqzW
h6IPI5IWfb5Bynem4RxhOcE6TQOo6BYHrzbphs+BohqBYFCBx0g=
=cV07
-END PGP SIGNATURE-



Accepted debian-edu-config 2.11.8 (source) into unstable

2019-11-04 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 04 Nov 2019 18:22:46 +0800
Source: debian-edu-config
Architecture: source
Version: 2.11.8
Distribution: unstable
Urgency: medium
Maintainer: Debian Edu Developers 
Changed-By: Holger Levsen 
Closes: 944013
Changes:
 debian-edu-config (2.11.8) unstable; urgency=medium
 .
   [ Wolfgang Schweer ]
   * Drop workaround for NFS related bug #930125 (fixed in firefox-esr 68.2.x):
 - Remove share/debian-edu-config/edu-firefox-nfs.
 - Adjust cf3/cf.workarounds and Makefile.
   * Adjustments for changed education menu re-structuring:
 - cf3/edu.cf: Re-define class 'Workstation' condition.
 - share/ltsp/plugins/ltsp-build-client/Debian-custom/032-edu-pkgs and
   debian/debian-edu-config.postinst: Drop desktop-profiles related code.
 - cf3/cf.finalize: Remove desktop-profiles related editing.
 - d/control: Drop Depends on desktop-profiles.
   * Cope with Firefox-ESR ini files that need to be different (as of version
 68.2.0esr) to further allow centralized configuration: (Closes: #944013)
 - Add share/debian-edu-config/profiles.ini.ff (Firefox-ESR profiles.ini).
 - Add share/debian-edu-config/installs.ini (now needed in addition for 
users
   that don't have a Firefox-ESR profile, i.e. new users).
 - Adjust share/debian-edu-config/tools/gosa-create which is used to copy
   the related Firefox-ESR ini files.
 - Ajust Makefile.
 - Adjust ldap-tools/ldap-debian-edu-install (fix for the first user).
Checksums-Sha1:
 bf8712dbf3ca7f950503a599580a123a322d03de 1914 debian-edu-config_2.11.8.dsc
 cdbaff88c787ba1a98f5d2035ef50bcbd810438d 340896 debian-edu-config_2.11.8.tar.xz
 6be94968fe577de49e768bcf383392c834b35745 5289 
debian-edu-config_2.11.8_source.buildinfo
Checksums-Sha256:
 d1818ec8a80ea29dabfc3b9bc218e41f089d44e455d2539a0f337776c2df7d5c 1914 
debian-edu-config_2.11.8.dsc
 df07a87064be8b529b0d034994293359ded8790e1cac26b76c69388421509801 340896 
debian-edu-config_2.11.8.tar.xz
 60ffb34d4dd60bd3e88307120f97e5e1c52127c2e1f40a238645a0008bc8dabf 5289 
debian-edu-config_2.11.8_source.buildinfo
Files:
 f041b05edba360225a207f32a8500a02 1914 misc optional 
debian-edu-config_2.11.8.dsc
 764637eb8170250978aa83134129fa90 340896 misc optional 
debian-edu-config_2.11.8.tar.xz
 68f04b01b113bdac0e43a86e2f70d572 5289 misc optional 
debian-edu-config_2.11.8_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl2//LgACgkQCRq4Vgaa
qhw6gg//YLnYW6UeWnnR9RzbEjNdZCAmqVtxq5Dv/9DH3NoO73Op1sFiIgWtgRgw
v+7sdp/vKgBDHsrTtd3tP0g9I0F9iA06UELzIObZ9RcUbaRr8YZVk6nVbsx7AYZc
wv18RFCYvy5wWLMBK2deqUdBf9tj2cLZ3u6RxrFOGidS1KZ838Pj1C0ft6f/wRwG
xR3rKno9oxOo3hVAIeWHHmDIM5yokVCz1eJHeHBiC6taRHseCSrQA6V53T9WhFbn
s2dguAplJjtiKhttvd4tq0HTYXvdXO20p88OgfZOXL+vn6cMW026pI/es4uRxZU0
59282D3OoqiRYWgXtDYR61ie5Y7zWjgkJ5G+VhxVRQO2CDrb+35m6C5lc8FcURUw
Fw4wLD6kD+1jpzFFJY4jJJ8phfM0pjQH+RGA86DjTBWafg062Ql7/KMAxmsXBTJX
nMhWhJYdRh/jqVqcLcqbM3tU9bdDO6xRvLHEVo8MTZxf8qCAJtUGgSKB48jC6w52
NDSm50KNY9tKCMV4UAA+NsIqlmJ2is1FZb80IdyI7AVtHsrVoaXt16zingRsHMDT
CLFZ4d80Y6JhboF2DNTbBq+XC7FNn4kjev6VFz0RsYK22iyhQqGQ3MPVPh/aTphS
0TtNiUv0tkj97FpJj9hu8lu90Iu8Y506shk98fijIJAAZyV5WJI=
=1wRM
-END PGP SIGNATURE-



Re: Debian testing daily build - no kernel modules..!!!

2019-11-03 Thread Geert Stappers
On Sun, Nov 03, 2019 at 03:56:11AM +0100, André Verwijs wrote:
> 
> 
> 
> Debian testing daily build has no kernel modules..!!!


Reason is having booted kernel version Y
and in archive available kernel modules are for version X.

This does happen  during development.
 

> daily build: 10-21-2019 still good


Mmm, that is more then a week ago.

In that week there was another report about simular inconvinence.
That was concluded with "so you just caught a bad moment"
( https://lists.debian.org/debian-boot/2019/10/msg00273.html )
 
I'm not aware if did work in the time inbetween the reports.
(The Lonnie Cumberland report and the André Verwijs report)


Please see this message as an invention for either reporting
"works for me" or "next day retry also failed".


> Dank U - Thank You

U bedankt voor het melden - Thanking you for reporting


Groeten
Geert Stappers
-- 
Leven en laten leven



Re: Présentation de Debian au Capitole du libre

2019-11-02 Thread David Prévot
Salut,

Le 02/11/2019 à 16:59, Jérémy Lal a écrit :
> https://i.stack.imgur.com/nLXu9.jpg
> mais j'ai pas trouvé le source

https://github.com/filhocf/infographics/tree/master/debian

La dernière version (3.0) est compatible avec les DFSG si j’en crois je
fichier LICENSE.

Amicalement

David



signature.asc
Description: OpenPGP digital signature


Re: Présentation de Debian au Capitole du libre

2019-11-02 Thread Jérémy Lal
https://i.stack.imgur.com/nLXu9.jpg
mais j'ai pas trouvé le source

Le sam. 2 nov. 2019 à 18:43, Xavier  a écrit :

>
>
> Le 02/11/2019 à 18:15, Baptiste Jammet a écrit :
> > Bonjour,
> >
> >> + Les rayons ne font pas tous l'objet du même soutien: l'étage "main"
> >> est soutenu, celui "backports" aussi, "contrib" et "non-free" non
> > Sauf erreur, contrib fait partie de Debian (mais dépend de non-free).
>
> Bonjour,
>
> non, à ma connaissance, seul "main" fait partie de Debian
>
> > Seul non-free n'est pas "soutenu".
> > Et les backports sont pris en charge par l'équipe backports.
>
> Non plus, les backports sont maintenus par les mainteneurs de paquets
>
> > Baptiste
> > (non inscrit à d-d-f)
> >
>
>


Debian testing daily build - no kernel modules..!!!

2019-11-02 Thread André Verwijs





Debian testing daily build has no kernel modules..!!!

daily build: 10-21-2019 still good









Dank U - Thank You

Twitter:
http://twitter.com/OpenSimFan

Facebook:
http://www.facebook.com/andre.verwijs

Instagram:
André Verwijs - Instagram <https://instagram.com/dutchglory



Re: Présentation de Debian au Capitole du libre

2019-11-02 Thread Xavier



Le 02/11/2019 à 18:15, Baptiste Jammet a écrit :
> Bonjour,
> 
>> + Les rayons ne font pas tous l'objet du même soutien: l'étage "main"
>> est soutenu, celui "backports" aussi, "contrib" et "non-free" non
> Sauf erreur, contrib fait partie de Debian (mais dépend de non-free).

Bonjour,

non, à ma connaissance, seul "main" fait partie de Debian

> Seul non-free n'est pas "soutenu".
> Et les backports sont pris en charge par l'équipe backports.

Non plus, les backports sont maintenus par les mainteneurs de paquets

> Baptiste
> (non inscrit à d-d-f)
> 



Re: Présentation de Debian au Capitole du libre

2019-11-02 Thread Baptiste Jammet
Bonjour,

>+ Les rayons ne font pas tous l'objet du même soutien: l'étage "main"
>est soutenu, celui "backports" aussi, "contrib" et "non-free" non
Sauf erreur, contrib fait partie de Debian (mais dépend de non-free).
Seul non-free n'est pas "soutenu".
Et les backports sont pris en charge par l'équipe backports.

Baptiste
(non inscrit à d-d-f)


pgpv2wUefRaHn.pgp
Description: Signature digitale OpenPGP


Accepted debian-security-support 2019.11.01 (source) into unstable

2019-11-01 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 01 Nov 2019 19:49:47 +0100
Source: debian-security-support
Architecture: source
Version: 2019.11.01
Distribution: unstable
Urgency: medium
Maintainer: Holger Levsen 
Changed-By: Holger Levsen 
Closes: 931376
Changes:
 debian-security-support (2019.11.01) unstable; urgency=medium
 .
   * Remove nodejs from security-support-limited as it is supported since the
 Buster release. Closes: #931376.
   * Add empty security-support-ended.deb11 file.
   * check-support-status.in: set DEB_NEXT_VER_ID=11.
Checksums-Sha1:
 b73c0a07f592df8b107ccad1a4c454b1276efbf5 1857 
debian-security-support_2019.11.01.dsc
 1b8743226525bd7796c76406706e7709a2f21ced 30732 
debian-security-support_2019.11.01.tar.xz
 205695b4e1c03abab1d26338dd087020b1187fe6 6331 
debian-security-support_2019.11.01_source.buildinfo
Checksums-Sha256:
 a211ec4a170b623731c57a65544d03c293c8af61c2a38fc3e9ff8ab865003553 1857 
debian-security-support_2019.11.01.dsc
 beb5a8b280634d6511c19dad8be4d359b59de9370ba39b1be368d640102310de 30732 
debian-security-support_2019.11.01.tar.xz
 946465eb5955a53a6acbd366ce07efc72a14757198f20e321fa35a5bec5cd5fc 6331 
debian-security-support_2019.11.01_source.buildinfo
Files:
 b8514fdb535371bb9bd0847423c7ed72 1857 admin optional 
debian-security-support_2019.11.01.dsc
 295d4e66dbc2b5ee8009e04adb6680a6 30732 admin optional 
debian-security-support_2019.11.01.tar.xz
 adcce1ee2d99902458e373bd9030b7e2 6331 admin optional 
debian-security-support_2019.11.01_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl28gpkACgkQCRq4Vgaa
qhw/0w//a1PGTsjqtI6H7h+ReMTS8JBydryxDY81sAgFXhbDt1y3P7v+KjXR9Brd
rrjB9FZrTnEVT/X0VNsyZqP4c2IJbQVyamNafxC5L5xMPbj67JI1QfzuEC4i+qHC
DuB2C1It+rQlKSbrovMwwqxBtcmh6LeCRaSoFyI7KdhgP5Jh9ySHoLXqsUqxLM4C
+/UTOQ6+gFICKWyCrZktal/S9d//rGFG1/y4rnxQotOOgAJfgjjHTTgZG83qaPLA
hxWtUoht+UVkDomizD6a5kuM2huyk+AgdSST2mYzM8QmrByAhPaynYl7MP4XtLUD
YaBspc5HVOm8cL2CmeK9aFa46ZZGk9k4BClGsem7O4EKp710lq4FDp+YDO4LMjmS
BfEXRzFUNIeJohKo2KVDos062oGHC1CWcasVFd0IU7gRDFhIrQ/UvfunMHKjYU+H
nAOVYvLmXYp9w4GJEZ5POihPHG7xkKte1vmnOX7s8vvia2TdeF2p9mBk9GamhZO4
Dr9NZ0RlbI4ngm1KqMhrX1lFE8yvp+11BxperWe2BukZvliw8gMQdNnxCo+LN58C
lG7UKo4AXDQ+LP1gTr922oAlCTTaqVS8ewDxx9y3pxz8moc75hMh3ThoEgg8MSwg
NisHzDwLF+NRluejNQnZObKq8T3KWWgSs8dNJolPx7tef3N/R9w=
=LpNk
-END PGP SIGNATURE-



Accepted debian-security-support 2019.10.31 (source) into unstable

2019-10-31 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 31 Oct 2019 21:30:17 +0100
Source: debian-security-support
Architecture: source
Version: 2019.10.31
Distribution: unstable
Urgency: medium
Maintainer: Holger Levsen 
Changed-By: Holger Levsen 
Closes: 931376 943365
Changes:
 debian-security-support (2019.10.31) unstable; urgency=medium
 .
   * Mark nodejs only suitable for trusted content. Closes: #931376.
   * Add nasm-mozilla and nodejs-mozilla to security-support-ended.deb8
 and security-support-ended.deb9 as they are only provided as build
 dependency for Firefox/Thunderbird >= 68. Closes: #943365.
   * Bump standards version to 4.4.1, no changes needed.
Checksums-Sha1:
 d301d059b02d82fc81fb3ea4351659b670979060 1857 
debian-security-support_2019.10.31.dsc
 191828759003da0beddf7efc720c816ded733918 30660 
debian-security-support_2019.10.31.tar.xz
 de151f1e9792001ff421120539a091ccf3307d00 6331 
debian-security-support_2019.10.31_source.buildinfo
Checksums-Sha256:
 6014986ae8c2813e9f33ef53358ac8b0a4a82b16242a20b94e341dd0db01fc6f 1857 
debian-security-support_2019.10.31.dsc
 e20e9ec34135bd268307e767a3680e02c02a73719957a024c6481ea4e254ed12 30660 
debian-security-support_2019.10.31.tar.xz
 30b26cbc614d0367085d2b40af185171ad9235c39de73d6eb0de5e5e594b5dfb 6331 
debian-security-support_2019.10.31_source.buildinfo
Files:
 47c571e5dece5f7d16b0d6e99bb9001e 1857 admin optional 
debian-security-support_2019.10.31.dsc
 2c451b7686b2587dc0333ae3e1e497a5 30660 admin optional 
debian-security-support_2019.10.31.tar.xz
 c03825e5ee85f19579d9ae06d5a622aa 6331 admin optional 
debian-security-support_2019.10.31_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl27RRUACgkQCRq4Vgaa
qhzfQQ/+K/Pmv57QDEUNphhPxoe1LUOoYYTC5DybWO8InWL7wmniO14wt/NyS573
2AaIc9UcAwWvNxZ1ncDjRlbEoAxN0sG+Tfdo/g/mRQ7ChJezOMwwgZZpNnrr6dbf
nOphh5Sj/jBGmSI0kEXtD3BTYKh1uta1yeapvP3ljsO/D1MLJvT7i3mGaYmgUL7L
mIOKJ9NAHNZMwR4lu8uOwodSMcwUoG0Q8AZP/1iZ2N3IqYvkdOacmXedjWvd7rLB
7UGucojasx+aTOvracmsRgI93g7+f7vH0lbucdvMrnxTpizve4zh0jKJjPrpaA5k
QlUxF703NXu/m7MIvJDhKpinfLatrJo82qABV8i0JtSi6EcBeeo8SQhofqd5dPdt
SXzdj06GhSfqoxGZ8SSSWz+49utQeVdjXvif4zlaNYvl8rsjH1zDUZ0jZD68JwNw
NNTZqKQvsNNJp2kJYxMjqCiDeQYs6kU6/VD8UMhiFp28cYeuJ5sDNkinZguET31F
h69yIxOqc3NU2q93UPxYslgxkMyIkIgzlOo5HL3BR9+bSr13+GdL8dibGBLiHm53
9nhJroPJKACGbdPCOecqKA0ZkL249g5wi9B0VihHrV1GynoI4iibqv+s8lKiiA1T
1obPGnNkE0B0cWCjVFwJShwoJmfpjSh4fsjhfqcegSd71XVwDh4=
=m+WJ
-END PGP SIGNATURE-



Accepted debian-edu 2.11.5 (source) into unstable

2019-10-31 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 31 Oct 2019 19:58:40 +0100
Source: debian-edu
Architecture: source
Version: 2.11.5
Distribution: unstable
Urgency: medium
Maintainer: Debian Edu Developers 
Changed-By: Holger Levsen 
Changes:
 debian-edu (2.11.5) unstable; urgency=medium
 .
   [ Wolfgang Schweer ]
   * tasks/main-server:
 - Replace icinga2-classicui with icingaweb2.
 - Replace debian-installer-10-netboot-{amd64,i386} with
   debian-installer-11-netboot-{amd64,i386}.
   * tasks/ltsp-server: Drop Recommends on ltsp-docs (no longer available).
   * debian/control: Update after running 'make dist'.
Checksums-Sha1:
 55c4694561f71a24129dadf17dcfdf578c28da0f 4768 debian-edu_2.11.5.dsc
 bad90945621cdba034b1d385b38114cabb6aa74b 119096 debian-edu_2.11.5.tar.xz
 fa9986d41a3bdf3ae1f4deff50264434d01313dc 6740 
debian-edu_2.11.5_source.buildinfo
Checksums-Sha256:
 5ccaf27f03a334ccc1ddf77bc3874a41008ae5b96b205265dff2daadfd575d76 4768 
debian-edu_2.11.5.dsc
 7bcff592baa6d3642d92a8ff359ac2d2a0598eefa2e99320bae21a09e974f6de 119096 
debian-edu_2.11.5.tar.xz
 d78c7821eb3c8c2dec0e2ba8d64126c3ac00a8ae956be868d85b0d1495b32e10 6740 
debian-edu_2.11.5_source.buildinfo
Files:
 7abe5c879c58ad066020eba9d5140cfa 4768 metapackages optional 
debian-edu_2.11.5.dsc
 b76c341b719842bc3d316bbdf8947e42 119096 metapackages optional 
debian-edu_2.11.5.tar.xz
 197257d0b680b7e0cd01d4f9f8c89354 6740 metapackages optional 
debian-edu_2.11.5_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl27Ly4ACgkQCRq4Vgaa
qhwhPw/+Ogx+f1NARCx4/clHJdpI0RAAJpS/LX2mdULGFsluOayISBwuH9+PWAIl
h7N8VN6jWsCtE7eKu3NDIZHmh1Fr9TSz5RtQGfvYlKtELKeki/YeZo2IbJyVOTU6
rZ1EA2wrJrjBfR6VvtC5Ed5po7vMV4CKZ8sCB0XhIdJ3sCDRPa7EXZjI/CT/5iPC
WDhVwnqLe/BQs6/HTQujCiRdvMfq6O1ECg27CNEMOsD/V78qbRSfDY+zXSGsa08A
wW6Q7YyOJFS1i19muNByGvxOpjXy5M/FFcs8ihb87I/8lMFrQfXPNjomQFItKKct
5J935QJsUjGN9iii8WPp3Z6TGefU7R2X2IVBL5KVdsWJeQSscPzlHevEZI4yYabc
iLOeZku2jP03rnVIcSsWYsbCOgwjCU3k22+itqO2VSB45glVgrtKGn/dKDFxKAbE
pIx+evE7LnUin7ln+e5we4vTSZROZcQE6Fb+FFvpPJcC3GJelUr2gnLO3CaiLwbH
YlUmO8IOSEVFObNHwpO/c2sotfOKjc01rm5UUJ6ch3yxziB+nW5s56SLDbidC2a4
3yNXnOtAb+n19m7dyjgnkfH+vaT0VkqDWw8knQvtzC2+WSztHYKHEdDWk9/ac44H
yDmow8H/6VFBXMNbfP5ag586n1f/vEMXrGd3hGuIQXN+NiEpOww=
=6z8d
-END PGP SIGNATURE-



Accepted debian-edu-doc 2.10.21 (source) into unstable

2019-10-31 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 31 Oct 2019 12:05:35 +0100
Source: debian-edu-doc
Architecture: source
Version: 2.10.21
Distribution: unstable
Urgency: medium
Maintainer: Debian Edu Developers 
Changed-By: Holger Levsen 
Changes:
 debian-edu-doc (2.10.21) unstable; urgency=medium
 .
   * Update Debian Edu ITIL manual from the wiki.
   * Update Audacity manual from the wiki.
   * Update debian/copyright from the wikis.
 .
   [ Translation updates ]
   * Buster manual:
 - Dutch: Frans Spiesschaert
   * Audacity manual:
 - new Portuguese (Portugal) translation: Manuela Silva
 - Polish: Damian Nadolski
 - Norwegian Bokmål: Allan Nordhøy
   * ITIL manual:
 - Norwegian Bokmål: Allan Nordhøy
 .
   [ Holger Levsen ]
   * Add Portuguese language as pt_PT in documentation/scripts/get_copyright.
Checksums-Sha1:
 9a2cd94bff40bc4b3bd525c5c8a72856d963e1f3 2700 debian-edu-doc_2.10.21.dsc
 193af1a8005ca6f841bebb6e00f32861f56f1f93 30610040 debian-edu-doc_2.10.21.tar.xz
 4fccfb5a95fac79d508f53a1618846c2d0dcf99e 5445 
debian-edu-doc_2.10.21_source.buildinfo
Checksums-Sha256:
 44e5e32da77fd8668f8026b18e96e987bdaf9d3beff96b12caea2932c0f7b42b 2700 
debian-edu-doc_2.10.21.dsc
 2339351158a9d0eea5e49bc0da2ac2432c369a8378ad773025b799b977c25883 30610040 
debian-edu-doc_2.10.21.tar.xz
 06191b1371eb6cbe6c93c76746a3365e4280f7e27d0c53707126fa0c887adb7a 5445 
debian-edu-doc_2.10.21_source.buildinfo
Files:
 903be0db71f91f21024768a4e501a93f 2700 doc optional debian-edu-doc_2.10.21.dsc
 e9979465d91bd9f6eee488cb43e212b6 30610040 doc optional 
debian-edu-doc_2.10.21.tar.xz
 39209be58d1ef6a2c4c16ae20a28c823 5445 doc optional 
debian-edu-doc_2.10.21_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl27LigACgkQCRq4Vgaa
qhzhlg//TzSvq0dEf4EUL5c0cnug5W51B1IHuCvG0v/G0aMNrPDo4+8ocstfX08k
E3lWoCC/TVvE3PGce05D50UFP8mmSgq5+auz5QBTKQs1S7FeeKhXyqx2+yVGRyGT
3VXoC2bFgsj5uCDbRHm0YvifYiWFdfr15mmcyy8WB0+sZ3y++4a41EuJqSw/BQ1o
E3oNuRPuX8aR1cTiKsF4XxBcw751AUMXwTzfo29dNPmj+BA9fzL1jVniaSbBnA65
jUbJsBT0eFcPI41t7+RZ1CfH0TvHMv1EUaPQwnMcNrfYEZPMxUcYMN9XP8shPvYv
6Kq/xuNwTRpRZfGy9tkb51SobxTRWccCUV1aVQZp0Rwlafyi4MyvkzYXBYX6hfCs
07PbQMLvTh9WNoZlhv7LxjcOZ8JlLTZukbKZTrJlfSAeeOPqW3/IPgRhKdRU+dxu
aZVMo+PSUrSrg5q7GbcRyqTuPCj9Nyr/7L+1h5VWdEZW3KEyFYTK7zNr7PPqQIBj
q3TV5wgy7BCblk2By1+SOQ9VBomdXY1Pz2TRM5yp6bPTjL1jJ1mKDi2IAhGOiw1G
ReQnEfRp2NK6ArRvb6FGIXWujCCkj1YyqCAF3BNZVGcyLFvMrtO9aATHDRT2TQp4
RG7ZAj/crnH62haq/3YbEFc3t4WUwQTsJVu3XGU9y+F25YvZZNQ=
=QITe
-END PGP SIGNATURE-



Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

2019-10-30 Thread Sean Whitton
Hello,

On Tue 29 Oct 2019 at 08:32AM +01, Tobias Frost wrote:

>> For example, you would not be able to do this:
>>git clone salsa:something
>>cd something
>>make some straightforward change
>>git tag# } [1]
>>git push   # }
>> Instead you would have to download the .origs and so on, and wait
>> while your machine crunched about unpacking and repacking tarballs,
>> applying patches, etc.
>
> 
> I'm missing a "and then I test my package to ensure it still works before
> upload" step…
>
> I wonder how someone should test their packages when they do
> not build it locally.
> And if they do (as they should), the advantages you line
> out are simply not there.
> 

If you use `dpkg-buildpackage -b` to do your local tests, then the
advantage of not having to go near any source packages remains.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Opera 12.16 on Debian 10 is not working

2019-10-30 Thread patrick . dreier

Dear Woman and Man!

Opera 12.16 on Debian 10 is not working.
http://ftp.opera.com/ftp/pub/opera/linux/1216/
How is the problem solved?

With kind greetings!



Re: Opera 12.16 on Debian 10 is not working

2019-10-30 Thread Sven Hoexter
On Wed, Oct 30, 2019 at 06:30:35PM +0100, Andrej Shadura wrote:
> Hi,
> 
> On Wed, 30 Oct 2019, 17:43 ,  wrote:
> 
> > Dear Woman and Man!
> >
> > Opera 12.16 on Debian 10 is not working.
> > http://ftp.opera.com/ftp/pub/opera/linux/1216/
> > How is the problem solved?
> >
> 
> Debian doesn't ship Opera.
> 
> Also, there's no need to send the same email in both English and German,
> just English is enough.

ACK.

And to answer the question, the statically linked binary from the
opera-12.16-1860.x86_64.linux.tar.xz does actually work.

I'm yet sure if this question was more trolling then anything else.
Nobody should browse the internet with a browser from 2013 in 2019.

Sven



Re: Opera 12.16 on Debian 10 is not working

2019-10-30 Thread Carsten Schoenert

Am 30.10.19 um 18:30 schrieb Andrej Shadura:

Hi,

On Wed, 30 Oct 2019, 17:43 , <mailto:patrick.dre...@gmx.net>> wrote:


Dear Woman and Man!

Opera 12.16 on Debian 10 is not working.
http://ftp.opera.com/ftp/pub/opera/linux/1216/
How is the problem solved?


Debian doesn't ship Opera.


Patrick is doing writing to -devel with various topics from time to time. :)

https://lists.debian.org/debian-devel/2019/06/msg00357.html
https://lists.debian.org/debian-devel/2019/06/msg00358.html
https://lists.debian.org/debian-devel/2019/06/msg00359.html
...
https://lists.debian.org/debian-devel/2019/06/msg00362.html
https://lists.debian.org/debian-devel/2019/08/msg00370.html

--
Regards
Carsten Schoenert



Opera 12.16 on Debian 10 is not working

2019-10-30 Thread patrick . dreier

Dear Woman and Man!

Opera 12.16 on Debian 10 is not working.
http://ftp.opera.com/ftp/pub/opera/linux/1216/
How is the problem solved?

With kind greetings!



Opera 12.16 auf Debian 10 funktioniert nicht

2019-10-30 Thread patrick . dreier

Sehr geehrte Damen und Herren!

Opera 12.16 auf Debian 10 funktioniert nicht.
http://ftp.opera.com/ftp/pub/opera/linux/1216/
Wie wird das Problem gelöst?

Mit freundlichen Grüssen!



Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

2019-10-29 Thread Ian Jackson
Helmut Grohne writes ("Re: Building Debian source packages reproducibly (was: 
Re: [RFC] Proposal for new source format)"):
> I think I'd trust the tag2upload service given the documentation you
> presented about it. I'm less faithful in all dgit installations being
> sane, sorry. We've run into too many builds in dirty chroots already.

That does make sense.  This is one of the ways that tag2upload is
better than dgit push.  (It is a shame that "integrity" concerns are
blocking integrity improvements.)

It would be possible to write a QA service which would verify Dgit
fields and automatically file RC bugs.  So far that hasn't seemed
necessary.

It would also be possible for dgit clone to verify the correspondence
itself, at the point where it honours the Dgit field.  Would that be a
useful feature for you ?  Of course it does mean downloading the
elements of the source package, which it currently doesn't need to do
if it finds a Dgit field, but there's no real difficulty.  (I wouldn't
make this the default!)

> > You do not need to talk to any random git servers.  The git tree is
> > available on a single official Debian server, the dgit git server.
> > The Dgit: field in the .dsc identifies the commitid.  The .dsc is of
> > course available via the signed apt repositories, as well as being
> > available from the ftpmaster data API.
> 
> I was not trying to imply dgit to be a random git server. Given that
> dgit (currently) only contains history for a fraction of packages, we
> still need to compare with Vcs-Git. Given enough time, dgit will have
> useful histories eventually.

Yes.  If tag2upload is deployed, I expect it to be very popular.

Until then Vcs-Git has all the problems you mention and many others
too: it is hard to reliably find the right tag (even the tag name is
not formally standardised!) and certainly nothing checks that the tag
corresponds in any particular way.  How it might correspond is
generally not even documented anywhere - at least, not anywhere
machine-readable.

> Hmm. I'm not sure whether I actually need the tag object. The commit id
> is what I really need. dak might need the tag object. I'll defer to
> others.

I think ftpmaster's concerns mean that dak would want the tag object
to redo the uploader identify verification, even though from my point
of view that would be a redundant check.  But it's simple to provide
the tag and there is some integrity improvement from doing so, so that
is what I am proposing.

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: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

2019-10-29 Thread Bastian Blank
Hi Didier

On Mon, Oct 28, 2019 at 10:05:11AM +0100, Didier 'OdyX' Raboud wrote:
> Of course, all of this can only work if we can have, or make the ".git to 
> .dsc" conversion reproducible; hence my query.

Now, please read the first mail of this thread again.  Yes, maybe parts
of it are unclear, but we are way past the "we need this conversion"
stage.

Maybe we can stop running in circles around this concept and design
solutions.

Bastian

-- 
Prepare for tomorrow -- get ready.
-- Edith Keeler, "The City On the Edge of Forever",
   stardate unknown



Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

2019-10-29 Thread Helmut Grohne
Hi Ian,

On Tue, Oct 29, 2019 at 12:54:57PM +, Ian Jackson wrote:
> I wonder if I have misunderstood you, because:
> 
> The tag2upload proposal is based on dgit, which already provides this.
> dgit indeed defines an isomorphism between source packages and git
> trees, and dgit clone gives a git branch that is thus-isomorphic to
> the .dsc.  This is fundamental to dgit's design.

I get that this is the intention, but I don't see that this property can
be safely assumed. I see the Dgit field as a hint. It says "this source
package should be equivalent to this commit" without any guarantees of
this actually being the case. I guess that for all uploads performed
thus far, this is indeed the case, but it is not a requirement validated
by dak or any other trusted (by me) entity. We could easily end up with
an upload where the commit id is accidentally different. Everything that
we can be gotten wrong, we will eventually get wrong.

> With `dgit push', the isomorphism is checked on the maintainer's
> machine during `dgit push'.  With tag2upload it is ensured by the
> tag2upload service.  (When the uploader didn't use dgit, dgit clone
> does a .dsc import, thus ensuring the isomorphism.)

I think I'd trust the tag2upload service given the documentation you
presented about it. I'm less faithful in all dgit installations being
sane, sorry. We've run into too many builds in dirty chroots already.

> > This property allows me to start from a git tree that is
> > authenticated by dak rather than a random git tree on a random git
> > server of questionable origin.
> 
> You do not need to talk to any random git servers.  The git tree is
> available on a single official Debian server, the dgit git server.
> The Dgit: field in the .dsc identifies the commitid.  The .dsc is of
> course available via the signed apt repositories, as well as being
> available from the ftpmaster data API.

I was not trying to imply dgit to be a random git server. Given that
dgit (currently) only contains history for a fraction of packages, we
still need to compare with Vcs-Git. Given enough time, dgit will have
useful histories eventually.

> It is true that this doesn't give you precisely the *tag* object -
> just the commit.  Adding the objectid of the tag object to the .dsc
> Dgit: field would be easy, if that would be helpful to you.  (Please
> file a wishlist bug against dgit if so.)  Alternatively, dak could
> publish the tag object (in a similar way to how it publishes binary
> buildinfos).

Hmm. I'm not sure whether I actually need the tag object. The commit id
is what I really need. dak might need the tag object. I'll defer to
others.

Helmut



Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

2019-10-29 Thread Ian Jackson
Helmut Grohne writes ("Re: Building Debian source packages reproducibly (was: 
Re: [RFC] Proposal for new source format)"):
> In other words, I want these formats (source package and tagged git
> tree) to be isomorphic (minus history). This requirement is too strong
> since not every source package will have a corresponding tag, but when
> there is a tag, I want to safely go from source package to tag and back
> again and arrive where I started from.

I wonder if I have misunderstood you, because:

The tag2upload proposal is based on dgit, which already provides this.
dgit indeed defines an isomorphism between source packages and git
trees, and dgit clone gives a git branch that is thus-isomorphic to
the .dsc.  This is fundamental to dgit's design.

With `dgit push', the isomorphism is checked on the maintainer's
machine during `dgit push'.  With tag2upload it is ensured by the
tag2upload service.  (When the uploader didn't use dgit, dgit clone
does a .dsc import, thus ensuring the isomorphism.)

> This property allows me to start from a git tree that is
> authenticated by dak rather than a random git tree on a random git
> server of questionable origin.

You do not need to talk to any random git servers.  The git tree is
available on a single official Debian server, the dgit git server.
The Dgit: field in the .dsc identifies the commitid.  The .dsc is of
course available via the signed apt repositories, as well as being
available from the ftpmaster data API.

It is true that this doesn't give you precisely the *tag* object -
just the commit.  Adding the objectid of the tag object to the .dsc
Dgit: field would be easy, if that would be helpful to you.  (Please
file a wishlist bug against dgit if so.)  Alternatively, dak could
publish the tag object (in a similar way to how it publishes binary
buildinfos).

Note that there are *two* tag objects: 1. the canonical view:
the dgit view tag, which is simply-isomorphic to the source package.
2. the maintainer tag, which is on the maintainer's branch and refers
to a commit in maintainer branch format.

With dgit push these are both made during dgit push with the
maintainer's key.  With tag2upload the canonical view tag is made by
the tag2upload service, because it is that service which performs the
maintainer->canonical conversion.

Each maintainer workflow defines a different mapping between
maintainer views and canonical views.  The (currently supported[1])
workflows are all isomorphisms.  So it is possible in principle to
reverse the maintainer->canonical transformation (if you know the
workflow, which can be found in the tags) but there is not currently
code to do that.  I don't get the impression, however, that this is a
thing you feel you need ?  (Some form of reverse transformation would
be needed to automatically and workflow-agnostically handle MRs whose
submitter is using the canonical view.)

> This backwards-connection seems to be missing thus far, but I do find it
> important for the reasons above. Adding it would easily allow dak to
> validate the signature on the tag.

So, I'm not sure I understand what you think is missing.

Ian.

[1] I think with monorepo workflows the maintainer->canonical
conversion is generally irreversible, because it discards information
about source packages other than the one in question.  This wouldn't
block MR processing because MRs are deltas and by definition the other
parts of the monorepo aren't edited in the MR.  It does mean you
couldn't reconstruct the whole monorepo given just the canonical view.

(Arguably this means that the .dsc representation of a source package
from a git monorepo is not a PFM.  See arguments on -legal and
-project, passim.  But the canonical view dgit branch does contain the
whole of the monorepo in its history, in a discoverable way, so
doesn't have this issue.)

-- 
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: Building Debian source packages reproducibly

2019-10-29 Thread Philipp Kern

On 2019-10-29 08:32, Tobias Frost wrote:

On Mon, Oct 28, 2019 at 05:53:00PM +, Ian Jackson wrote:

(...)


For example, you would not be able to do this:
   git clone salsa:something
   cd something
   make some straightforward change
   git tag# } [1]
   git push   # }
Instead you would have to download the .origs and so on, and wait
while your machine crunched about unpacking and repacking tarballs,
applying patches, etc.



I'm missing a "and then I test my package to ensure it still works 
before

upload" step…

I wonder how someone should test their packages when they do
not build it locally.
And if they do (as they should), the advantages you line
out are simply not there.



More abstractly we do not do that for binNMUs either. My main worry here 
is that we are designing a solution which still precludes sourceful 
no-change NMUs, which would actually be the correct solution for 
consistent versioning across all architectures. Ubuntu exclusively does 
those and I still struggle how we would build such a service in Debian 
without facing exactly the same concerns as tag2upload. Maybe if dak 
itself would do it?


Kind regards
Philipp Kern



Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

2019-10-29 Thread Tobias Frost
Hi Ian,

On Mon, Oct 28, 2019 at 05:53:00PM +, Ian Jackson wrote:

(...)
 
> For example, you would not be able to do this:
>git clone salsa:something
>cd something
>make some straightforward change
>git tag# } [1]
>git push   # }
> Instead you would have to download the .origs and so on, and wait
> while your machine crunched about unpacking and repacking tarballs,
> applying patches, etc.


I'm missing a "and then I test my package to ensure it still works before
upload" step…

I wonder how someone should test their packages when they do
not build it locally.
And if they do (as they should), the advantages you line
out are simply not there.


-- 
 tobi
 


signature.asc
Description: PGP signature


Accepted debian-gis 0.0.19 (source) into unstable

2019-10-29 Thread Bas Couwenberg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 29 Oct 2019 06:20:22 +0100
Source: debian-gis
Architecture: source
Version: 0.0.19
Distribution: unstable
Urgency: medium
Maintainer: Debian GIS Project 
Changed-By: Bas Couwenberg 
Changes:
 debian-gis (0.0.19) unstable; urgency=medium
 .
   * tasks/devel:
 - Drop python3-mapbox-vector-tile
   * tasks/remotesensing:
 - Drop python3-otb
   * tasks/web:
 - Change postgresql-11-pgrouting to postgresql-pgrouting
   * tasks/workstation:
 - Drop libgeo-point-perl
   * Bump Standards-Version to 4.4.1, no changes.
Checksums-Sha1:
 c03410e9b55cced1cc42cec1d204513f93c65273 2280 debian-gis_0.0.19.dsc
 ba8367c14e66714e5883f16d5447e4f662d55334 141300 debian-gis_0.0.19.tar.xz
 39ad6345f149641aab49a13ed7f6b07fdac1d81f 9285 debian-gis_0.0.19_amd64.buildinfo
Checksums-Sha256:
 125bda8ede294da11f189567118275c89c0b08239eb8f9e38ef50eb69acf8dea 2280 
debian-gis_0.0.19.dsc
 d0a9e5035fc6efd3c113c1155363ac029504c5050450c7c9cc59e98905f79bd3 141300 
debian-gis_0.0.19.tar.xz
 cc2b26d50cb7ae16b8b55ca7b031938ea78f4ffc20a210b1e79320b6c9680039 9285 
debian-gis_0.0.19_amd64.buildinfo
Files:
 115686f0b983e05e21e2a7b50b92d8cc 2280 misc optional debian-gis_0.0.19.dsc
 42d0326344b32a8147d1c1193f869700 141300 misc optional debian-gis_0.0.19.tar.xz
 24edcd6efa605b0adc03b5904d0005a2 9285 misc optional 
debian-gis_0.0.19_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEgYLeQXBWQI1hRlDRZ1DxCuiNSvEFAl2326kACgkQZ1DxCuiN
SvF7SRAArgjle1BdDAMu2HDGrKwBCQ+mXQrcYpLiuVey0PTOPxRDhvHdrcSLbWtg
6ru/LYG/pwdik2TQzcgv5cU9KLHd7cnjQ5Ftl17Os8txWGcbRpoo0JxWucONNyEO
IxFGCEittr37lN4C5MneBFkW52i91bWM6+Hi4YK09XNTu00bt29lLnLo8/1LZShL
HOhqfTNfX3SndBJbLvSWQnuX6wRaq8ggSjTyPBM1lXcpzSeoZ4OC1032oEnYICTg
rI9z67k4JMBZ6G2radirHaPgSownWQuHW+JcsCKtHdf2+BHoubiXnlVPouULQa4r
HwMdPxDkAADVVc7PTNh0SEyEHg9gw45DDo5mf122HTMhSRwff607ZoSCHsjtuREJ
1sesSsLp5HkPFowtwLtpr+zFwC40uE2FTPI8yptJ5fmHic0llq15LX7C+UD6MlFJ
eWra3+7+WVmJtFku9Hcm/39nylDbGx6kah+VohPuclbyJtBztyk3Lf2nVQuoN55r
iVPIn3RXZdf7YKJbz1mTaarPnsSHS3hNuMqzMHFA425QThBbBTj1HIksmzzfGoTJ
o56m2TaB3rTmpDQtWgZl+0xiEZmLtaGRjnJebrfaO9wfNwguMSc5zniSbPmI0ZGm
py7iKyPMfPD0+HfF6mZZ/W/5A39vRevM0vrkT1qX/JdAE0+m57o=
=Jdjy
-END PGP SIGNATURE-



Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

2019-10-28 Thread Helmut Grohne
Hi Ian,

On Mon, Oct 28, 2019 at 05:53:00PM +, Ian Jackson wrote:
> The sticking point, as I understand it, is that this still does not
> allow dak to verify that the *contents* of the .dsc were as intended
> by the uploading human. [0]
> 
> In the tag2upload proposal, the conversion from git tag to dsc is
> `merely' done by an official Debian service on an official Debian
> machine, and is `merely' fully reproducible and auditable.
> 
> But this is not good enough for some ftpmasters, who want that
> verification to be done *by dak*.  Various people attempted in the
> previous thread on this topic to find out *why* this is thought
> important, without apparent success.

I fear I'll have to side with "some ftpmasters" here. As a user, I also
want this verification work in both ways. Going from tag to upload is
insufficient in my view. What I want is "apt source" with history. This
is not debcheckout. I want the exact tree (tag) that matches unstable
including its git history in a way that exactly reproduces the build
failure seen on the source package.

In other words, I want these formats (source package and tagged git
tree) to be isomorphic (minus history). This requirement is too strong
since not every source package will have a corresponding tag, but when
there is a tag, I want to safely go from source package to tag and back
again and arrive where I started from. This property allows me to start
from a git tree that is authenticated by dak rather than a random git
tree on a random git server of questionable origin.

This backwards-connection seems to be missing thus far, but I do find it
important for the reasons above. Adding it would easily allow dak to
validate the signature on the tag.

Helmut



Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

2019-10-28 Thread Scott Kitterman



On October 28, 2019 5:53:00 PM UTC, Ian Jackson 
 wrote:
>Scott Kitterman writes ("Re: Building Debian source packages
>reproducibly (was: Re: [RFC] Proposal for new source format)"):
>> Effectively tag2upload would replace DAK as the entry point for
>> packages into the archive (the equivalent to the current source
>> package signature verification being the git tag signature
>> verification).  I don't think the discussion got to a point where a
>> path forward that was considered reasonable by both the tag2upload
>> developers and the FTP Masters was reached.
>
>The current tag2upload proposal includes providing dak with the signed
>git tag object so that it can re-verify the identity of the human DD
>who authorised the upload.
>
>The sticking point, as I understand it, is that this still does not
>allow dak to verify that the *contents* of the .dsc were as intended
>by the uploading human. [0]
>
>In the tag2upload proposal, the conversion from git tag to dsc is
>`merely' done by an official Debian service on an official Debian
>machine, and is `merely' fully reproducible and auditable.
>
>But this is not good enough for some ftpmasters, who want that
>verification to be done *by dak*.  Various people attempted in the
>previous thread on this topic to find out *why* this is thought
>important, without apparent success.
>
>It would be nice to be able to work around this objection somehow by
>writing more code.  Unfortunately, any alternative - such as that
>described by Didier earlier in this thread - has undesirable
>properties.  In particular, it does not seem that it would be possible
>to do anything along these lines without continuing to burden the
>developer's working system with a whole pile of messing about with
>tarballs and quilt and so on.
>
>For example, you would not be able to do this:
>   git clone salsa:something
>   cd something
>   make some straightforward change
>   git tag# } [1]
>   git push   # }
>Instead you would have to download the .origs and so on, and wait
>while your machine crunched about unpacking and repacking tarballs,
>applying patches, etc.
>
>With tag2upload all that work is done for you on the tag2upload
>service, which of course has a fast network connection - and you don't
>need to wait for it.
>
>Ian.
>
>[0] Currently, of course, this requirement is not achieved for
>existing git based uploads.  In practice, DDs use ad-hoc
>git-buildpackage runes on their local machine to convert git data into
>.dscs.  That conversion is not controlled, not reproducible, and not
>practically auditable.  I guess maybe those blocking tag2upload think
>it is sufficient that we can blame the DD if it is messed up or
>suborned ?
>
>[1] In practice with tag2upload you would use `git-debpush' instead of
>`git tag' + `git push' but this is a thin wrapper around `git tag' and
>does not involve downloads or indeed any network activity, etc.

And the talking past each other surely continues because I don't think that in 
any way answers the objections.  Repeating the same thing you've said before 
isn't going to close the communication gap.  I don't think it's possible to do 
so right now.  Also, I'm a mere FTP Assistant, so I'm not one of the ones you 
have to convince.

Scott K



Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

2019-10-28 Thread Ian Jackson
Didier 'OdyX' Raboud writes ("Building Debian source packages reproducibly 
(was: Re: [RFC] Proposal for new source format)"):
> Where I'm coming from is that we were discussing the tag2upload
> problem at miniDebConf Vaumarcus.  [...]

I appreciate your efforts to try to unstick all this.

> The hard part is not the packing and unpacking of the special tag; that's 
> mostly just strings massaging. But building the exact same source package in 
> different environments is harder than I expected.

Yes.  I have code to do it for tag2upload, though.  It's not released
yet because I stopped putting effort into this whole area after
getting discouraged.

> Of course, all of this can only work if we can have, or make the ".git to 
> .dsc" conversion reproducible; hence my query.
> 
> All-in-all; would this be a welcome mechanism?

I think by requiring the user to always have the tarballs on hand and
wait for them to be manipulated and maybe transferred, you are losing
a fair amount of the benefit of tag2upload.

But if you did want to do something along these lines, maybe you
should do it by adding code to git-debpush and the tag2upload service
rather than by reinventing the rest of the machinery ?

Regards,
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: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

2019-10-28 Thread Ian Jackson
Scott Kitterman writes ("Re: Building Debian source packages reproducibly (was: 
Re: [RFC] Proposal for new source format)"):
> Effectively tag2upload would replace DAK as the entry point for
> packages into the archive (the equivalent to the current source
> package signature verification being the git tag signature
> verification).  I don't think the discussion got to a point where a
> path forward that was considered reasonable by both the tag2upload
> developers and the FTP Masters was reached.

The current tag2upload proposal includes providing dak with the signed
git tag object so that it can re-verify the identity of the human DD
who authorised the upload.

The sticking point, as I understand it, is that this still does not
allow dak to verify that the *contents* of the .dsc were as intended
by the uploading human. [0]

In the tag2upload proposal, the conversion from git tag to dsc is
`merely' done by an official Debian service on an official Debian
machine, and is `merely' fully reproducible and auditable.

But this is not good enough for some ftpmasters, who want that
verification to be done *by dak*.  Various people attempted in the
previous thread on this topic to find out *why* this is thought
important, without apparent success.

It would be nice to be able to work around this objection somehow by
writing more code.  Unfortunately, any alternative - such as that
described by Didier earlier in this thread - has undesirable
properties.  In particular, it does not seem that it would be possible
to do anything along these lines without continuing to burden the
developer's working system with a whole pile of messing about with
tarballs and quilt and so on.

For example, you would not be able to do this:
   git clone salsa:something
   cd something
   make some straightforward change
   git tag# } [1]
   git push   # }
Instead you would have to download the .origs and so on, and wait
while your machine crunched about unpacking and repacking tarballs,
applying patches, etc.

With tag2upload all that work is done for you on the tag2upload
service, which of course has a fast network connection - and you don't
need to wait for it.

Ian.

[0] Currently, of course, this requirement is not achieved for
existing git based uploads.  In practice, DDs use ad-hoc
git-buildpackage runes on their local machine to convert git data into
.dscs.  That conversion is not controlled, not reproducible, and not
practically auditable.  I guess maybe those blocking tag2upload think
it is sufficient that we can blame the DD if it is messed up or
suborned ?

[1] In practice with tag2upload you would use `git-debpush' instead of
`git tag' + `git push' but this is a thin wrapper around `git tag' and
does not involve downloads or indeed any network activity, etc.

-- 
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: Debian and our frenemies of containers and userland repos

2019-10-28 Thread John Goerzen


On Mon, Oct 21 2019, Enrico Weigelt wrote:

> On 05.10.19 03:31, Paul Wise wrote:
>> On Fri, Oct 4, 2019 at 10:49 PM Enrico Weigelt wrote:
>>> On 24.07.19 08:17, Marc Haber wrote:
>>>
 Do we have a build technology that uses containers instead of chroots
 yet?
>>>
>>> Something like docker-buildpackage ?
>> 
>> AFAICT, docker-buildpackage doesn't exist 
>
> I'm pretty sure it does exist, since I wrote it :p
>
> https://github.com/metux/docker-buildpackage

I should also mention https://packages.debian.org/buster/debocker -
though I haven't used it.

John

>
>
> --mtx



Re: Building Debian source packages reproducibly

2019-10-28 Thread Sven Joachim
On 2019-10-28 10:05 +0100, Didier 'OdyX' Raboud wrote:

> Le mercredi, 23 octobre 2019, 15.49:11 h CET Theodore Y. Ts'o a écrit :
>> On Wed, Oct 23, 2019 at 11:18:24AM +1000, Russell Stuart wrote:
>> > On Tue, 2019-10-22 at 16:52 -0700, Russ Allbery wrote:
>> > > That seems excessively pessimistic.  What about Git makes you think
>> > > it's impossible to create a reproducible source package?
>> > 
>> > Has it been done?  Given this point has been raised several times
>> > before if it hasn't been done by now I think it's reasonable to assume
>> > it's difficult, and thinking that it's so is not excessively
>> > pessimistic.
>> 
>> Generating a reproducible source package given a particuar git commit
>> is trivial.  All you have to do is use "git archive".  For example:
>
> When talking about upstream projects, sure.
>
> But generating Debian source packages (.dsc and friends) from a
> `debian/master` (+ `pristine-tar`) reproducibly is not really, right?
>
> As far as I understand, `gbp buildpackage -S` is the closest we have, but so 
> far, I fail to get it to give me the bit-by-bit identical unsigned .dsc that 
> I'd like to get. What am I missing?

Assuming format 3.0 (quilt): timestamps and permissions of files under
the debian/ directory.  The permissions of files in the git repository
are different from user to user (mostly depending on their umask), and
are propagated to the debian.tar.xz.

When building from a fresh clone, timestamps of files in the
debian.tar.xz should be set to the date of the latest debian/changelog
entry, as dpkg-source will clamp their mtimes to that value.  But in an
existing git repository there will likely be files older than that, and
their random mtime also propagates to the debian.tar.xz.

Cheers,
   Sven



Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

2019-10-28 Thread Scott Kitterman
On Monday, October 28, 2019 9:45:36 AM EDT Theodore Y. Ts'o wrote:
> On Mon, Oct 28, 2019 at 10:05:11AM +0100, Didier 'OdyX' Raboud wrote:
> > Where I'm coming from is that we were discussing the tag2upload problem at
> > miniDebConf Vaumarcus. The heart of the problem is that FTP-Master are
> > (currently) not going to accept .dscs built reproducibly by a (even
> > trusted) service. tag2upload is built on the idea that a signed git tag
> > is the only needed thing (`git tag -s`) to trigger an upload, and that is
> > not going to fly currently.
> 
> Ah, now I understand the problem you're trying to solve; thanks for
> the context.
> 
> What are FTP Master's objections?  Given that they *do* accept a
> source-only upload, which is just a signed dsc plus the source/debian
> tarballs, I would presume all that would be necessary is 
> demonstate that we have tools which can reliably translate between a
> git commit and the dsc plus source tarball, and (b) that the git tree
> is stored in Debian project infrastructure so we can be assured that
> it can be stored with the same level of assurance as where we store
> the source tar files.
> 
> Do they have other concerns?  If so, what are they?  I would be
> surprised that it has anything at all to do with reliable builds,
> given the acceptance of source-only uploads today.

My recollection of the discussion is that they key (pun intended) factor is 
signed by who.  Currently all uploads are signed by an individual authorized 
to upload the package to the archive.  The tag2upload proposal is premised on 
such keys being replaced by a single service based signing key.

Effectively tag2upload would replace DAK as the entry point for packages into 
the archive (the equivalent to the current source package signature 
verification being the git tag signature verification).  I don't think the 
discussion got to a point where a path forward that was considered reasonable 
by both the tag2upload developers and the FTP Masters was reached.

There was a fair amount of discussion on this point in the tag2upload threads.

Scott K




Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

2019-10-28 Thread Theodore Y. Ts'o
On Mon, Oct 28, 2019 at 10:05:11AM +0100, Didier 'OdyX' Raboud wrote:
> Where I'm coming from is that we were discussing the tag2upload problem at 
> miniDebConf Vaumarcus. The heart of the problem is that FTP-Master are 
> (currently) not going to accept .dscs built reproducibly by a (even trusted) 
> service. tag2upload is built on the idea that a signed git tag is the only 
> needed thing (`git tag -s`) to trigger an upload, and that is not going to 
> fly 
> currently.

Ah, now I understand the problem you're trying to solve; thanks for
the context.

What are FTP Master's objections?  Given that they *do* accept a
source-only upload, which is just a signed dsc plus the source/debian
tarballs, I would presume all that would be necessary is (a)
demonstate that we have tools which can reliably translate between a
git commit and the dsc plus source tarball, and (b) that the git tree
is stored in Debian project infrastructure so we can be assured that
it can be stored with the same level of assurance as where we store
the source tar files.

Do they have other concerns?  If so, what are they?  I would be
surprised that it has anything at all to do with reliable builds,
given the acceptance of source-only uploads today.

> The hard part is not the packing and unpacking of the special tag; that's 
> mostly just strings massaging. But building the exact same source package in 
> different environments is harder than I expected.

Is there more than just (a) making sure the package can be built
reproducibly in the first place, and (b) the information in the
buildinfo file?

Of course, the big problem is that not all packages are currently set
up to be reproducibly built; for example if you try to compile using
Link Optimization (LTO), you're completely out of luck.  (I've since
dropped use of LTO to deal with this issue.)

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932098

But if it *is* reproducibly buildable, are there case where setting up
a build environment using the information in buildinfo not enough?

Cheers.

- Ted



Accepted debian-edu-config 2.11.7 (source) into unstable

2019-10-28 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 28 Oct 2019 13:10:12 +0100
Source: debian-edu-config
Architecture: source
Version: 2.11.7
Distribution: unstable
Urgency: medium
Maintainer: Debian Edu Developers 
Changed-By: Holger Levsen 
Closes: 943573
Changes:
 debian-edu-config (2.11.7) unstable; urgency=medium
 .
   [ Wolfgang Schweer ]
   * etc/ltspfs/mounter.d/edu-notify:
 Adjust for using notify2 instead of pynotify.
   * debian/control: Replace python-notify with python3-notify2. Closes: #943573
 Thanks to Jeremy Bicha.
   * debian/control: Add Depends on python3, thanks Lintian.
 .
   [ Holger Levsen ]
   * share/debian-edu-config/pam-nopwdchange.py: converted to python3 with
 python-modernize.
   * debian/control: Drop Depends on python.
Checksums-Sha1:
 c68495baefde4a38039f02186e74c4242f8cc976 1914 debian-edu-config_2.11.7.dsc
 d8b61715d7554440f91b66fafdd0d0132ed61591 340716 debian-edu-config_2.11.7.tar.xz
 2de522abbe5c4d69e5abefd3436f4de7f6b93e98 5291 
debian-edu-config_2.11.7_source.buildinfo
Checksums-Sha256:
 e162cb80f87e1ce07b377f7ba9d49818516d267aabece7a06fb54cc5953a65b1 1914 
debian-edu-config_2.11.7.dsc
 c76ae2aa7d3f9c5f99b40366cdb7293a7146bf797b8eb724f52fe52717d326f4 340716 
debian-edu-config_2.11.7.tar.xz
 5d574c42ad591f716ab0c8efabd3ee2f331cebcd56b01664e4f068791c85537c 5291 
debian-edu-config_2.11.7_source.buildinfo
Files:
 7fff346273cf0826f56a1df0143b8cdb 1914 misc optional 
debian-edu-config_2.11.7.dsc
 86faea8a610aac0aad279c69e64df0ed 340716 misc optional 
debian-edu-config_2.11.7.tar.xz
 fa1aec2aec0808c0e2420694932be36b 5291 misc optional 
debian-edu-config_2.11.7_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl222twACgkQCRq4Vgaa
qhxByxAAjjpgt4GpN+fJSP7F34mbLmvhALSecM/mC2wBT7VxnHxK9+RoDIi1YhRH
oS8l0+Qa3HMVft1gzxniqb+4/++3HDiO4MEJPu6bFecyktd4Wyu/4+GmUK2+e784
tlrXbouTTMP0gd88SvrRIG44ZlwIuQs4ZzaVlPNP7ddOeDHdJOidRCODj5vOJU2u
pyMFIOnDIXOvqdlp1Y5HJEfeY6D53swQnH+RtEXj4HNCwPpKbSWnJeDqBEmL1Lq0
rqOQAnAUbYPqjFjAVugpGziJ2SIXF7Q2Aw+DiyXAGEg5iV4O28S6p/tq2i7QmZmt
JhkwzYlYP1yPY+gexJaRslS7VZcHRW9d3MOh6/XXMluiHUnDWoT6gMWaHRlYTy0F
wU1A1j4tcQFzRtDPL+le+uXrPuUOxPPDJyKHcE9hYGVsPZ85CimaA6lJgw3lGkXZ
PkJdlH6DnPEUAtjJRGEa9gq0qM4AQfwXYihG4Kq1eI3VdRR4cqQvIj2jsPhSxyIF
ZQdayM1zXpEtJmZT4HCV+CO7N3vt0pqohD7z+XvaAVoU3OHMJvLP07irzHHEvbgM
zCQAkGysV2oalSNWXyEaLmKJUKHQB/O+KThXYsZ2BQVe70QV4bvXVam9ZsPtPD8X
P6bWbY5vOSyY3FwK169w45a2qFkVFoEzuwblyK1156Y9P7IugAs=
=FZOc
-END PGP SIGNATURE-



Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

2019-10-28 Thread Marek Mosiewicz
Hello,

In fact what can be important is problem of downloading artifacts
during build. At least in Java world given application can be small but
be dependant on many libs which are downloaded during build. Program
works, build is reproducible, but we can have no idea what it consist
of.

Best regards,
Marek Mosiewicz

W dniu pon, 28.10.2019 o godzinie 10∶05 +0100, użytkownik Didier 'OdyX'
Raboud napisał:
> Le mercredi, 23 octobre 2019, 15.49:11 h CET Theodore Y. Ts'o a écrit
> :
> > On Wed, Oct 23, 2019 at 11:18:24AM +1000, Russell Stuart wrote:
> > > On Tue, 2019-10-22 at 16:52 -0700, Russ Allbery wrote:
> > > > That seems excessively pessimistic.  What about Git makes you
> > > > think
> > > > it's impossible to create a reproducible source package?
> > > 
> > > Has it been done?  Given this point has been raised several times
> > > before if it hasn't been done by now I think it's reasonable to
> > > assume
> > > it's difficult, and thinking that it's so is not excessively
> > > pessimistic.
> > 
> > Generating a reproducible source package given a particuar git
> > commit
> > is trivial.  All you have to do is use "git archive".  For example:
> 
> When talking about upstream projects, sure.
> 
> But generating Debian source packages (.dsc and friends) from a
> `debian/master` (+ `pristine-tar`) reproducibly is not really, right?
> 
> As far as I understand, `gbp buildpackage -S` is the closest we have,
> but so 
> far, I fail to get it to give me the bit-by-bit identical unsigned
> .dsc that 
> I'd like to get. What am I missing?
> 
> (A little digresssion…)
> 
> Where I'm coming from is that we were discussing the tag2upload
> problem at 
> miniDebConf Vaumarcus. The heart of the problem is that FTP-Master
> are 
> (currently) not going to accept .dscs built reproducibly by a (even
> trusted) 
> service. tag2upload is built on the idea that a signed git tag is the
> only 
> needed thing (`git tag -s`) to trigger an upload, and that is not
> going to fly 
> currently.
> 
> The solution that seemed obvious during the discussion [0] is to
> instead rely 
> on a local tool to produce a git tag with significantly more metadata
> (such as 
> .dsc signature, _source.changes signature); and reconstruct the a
> signed set 
> of .dsc and _source.changes automatically (as last pipeline step in
> Gitlab 
> CI), which are then acceptable by the archive.
> 
> In other words, its "tag2upload", but with a reproducible way to:
> - build a source package on developer machine;
> - sign it locally;
> - create and push a special git tag
> Then, in a different environment (such as a GitLab CI pipeline step),
> given a 
> special git tag and a repository;
> - build the exact unsigned same source package
> - unpack the special git tag;
> - apply the signatures to get the exact same signed source packages;
> - dput to the archive.
> 
> The hard part is not the packing and unpacking of the special tag;
> that's 
> mostly just strings massaging. But building the exact same source
> package in 
> different environments is harder than I expected.
> 
> Some caveats:
> - Q: if you built and signed the source package locally, why not
> uploading?  
>   A: Because you might want to only upload _after_ automated tests,
> and in an 
>  unsupervised manner.
> - Q: If one can fit pgp signatures in a git tag; why not inlining the
> complete 
>  .dsc and _source.changes?
>   A: Indeed. You still need the debian.tar though.
> - Q: What about Dgit: in the .dsc, or buildinfo files?
>   A: Currently optional; could just be left out for a prototype.
> 
> Of course, all of this can only work if we can have, or make the
> ".git to 
> .dsc" conversion reproducible; hence my query.
> 
> All-in-all; would this be a welcome mechanism?
> 
> 
> OdyX
> 
> [0] It probably was already considered.



Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

2019-10-28 Thread Didier 'OdyX' Raboud
Le mercredi, 23 octobre 2019, 15.49:11 h CET Theodore Y. Ts'o a écrit :
> On Wed, Oct 23, 2019 at 11:18:24AM +1000, Russell Stuart wrote:
> > On Tue, 2019-10-22 at 16:52 -0700, Russ Allbery wrote:
> > > That seems excessively pessimistic.  What about Git makes you think
> > > it's impossible to create a reproducible source package?
> > 
> > Has it been done?  Given this point has been raised several times
> > before if it hasn't been done by now I think it's reasonable to assume
> > it's difficult, and thinking that it's so is not excessively
> > pessimistic.
> 
> Generating a reproducible source package given a particuar git commit
> is trivial.  All you have to do is use "git archive".  For example:

When talking about upstream projects, sure.

But generating Debian source packages (.dsc and friends) from a
`debian/master` (+ `pristine-tar`) reproducibly is not really, right?

As far as I understand, `gbp buildpackage -S` is the closest we have, but so 
far, I fail to get it to give me the bit-by-bit identical unsigned .dsc that 
I'd like to get. What am I missing?

(A little digresssion…)

Where I'm coming from is that we were discussing the tag2upload problem at 
miniDebConf Vaumarcus. The heart of the problem is that FTP-Master are 
(currently) not going to accept .dscs built reproducibly by a (even trusted) 
service. tag2upload is built on the idea that a signed git tag is the only 
needed thing (`git tag -s`) to trigger an upload, and that is not going to fly 
currently.

The solution that seemed obvious during the discussion [0] is to instead rely 
on a local tool to produce a git tag with significantly more metadata (such as 
.dsc signature, _source.changes signature); and reconstruct the a signed set 
of .dsc and _source.changes automatically (as last pipeline step in Gitlab 
CI), which are then acceptable by the archive.

In other words, its "tag2upload", but with a reproducible way to:
- build a source package on developer machine;
- sign it locally;
- create and push a special git tag
Then, in a different environment (such as a GitLab CI pipeline step), given a 
special git tag and a repository;
- build the exact unsigned same source package
- unpack the special git tag;
- apply the signatures to get the exact same signed source packages;
- dput to the archive.

The hard part is not the packing and unpacking of the special tag; that's 
mostly just strings massaging. But building the exact same source package in 
different environments is harder than I expected.

Some caveats:
- Q: if you built and signed the source package locally, why not uploading?  
  A: Because you might want to only upload _after_ automated tests, and in an 
 unsupervised manner.
- Q: If one can fit pgp signatures in a git tag; why not inlining the complete 
 .dsc and _source.changes?
  A: Indeed. You still need the debian.tar though.
- Q: What about Dgit: in the .dsc, or buildinfo files?
  A: Currently optional; could just be left out for a prototype.

Of course, all of this can only work if we can have, or make the ".git to 
.dsc" conversion reproducible; hence my query.

All-in-all; would this be a welcome mechanism?


OdyX

[0] It probably was already considered.

signature.asc
Description: This is a digitally signed message part.


Accepted ruby-debian 0.3.10 (source) into unstable

2019-10-25 Thread Antonio Terceiro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 25 Oct 2019 16:48:41 -0300
Source: ruby-debian
Architecture: source
Version: 0.3.10
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Extras Maintainers 

Changed-By: Antonio Terceiro 
Closes: 889651
Changes:
 ruby-debian (0.3.10) unstable; urgency=medium
 .
   [ Cédric Boutillier ]
   * Bump debhelper compatibility level to 9
   * Remove version in the gem2deb build-dependency
   * Use https:// in Vcs-* fields
   * Use https:// in Vcs-* fields
   * Bump Standards-Version to 3.9.7 (no changes needed)
   * Run wrap-and-sort on packaging files
 .
   [ Antonio Terceiro ]
   * Add basic Rakefile to run tests
   * testdsc: port to test/unit
   * t/testar.rb: port to test/unit
   * Rakefile: list legacy tests
   * Remove testall, unnecessary
   * t/testarchives: port to test/unit
   * t/testdep: port to test/unit
   * t/teststatus: port to test/unit
   * t/testdeb.rb: port to test/unit
   * debian/ruby-tests.rake: run tests during build
   * debian/rules: drop comment boilerplate
   * Drop ancient Provides/Replaces/Breaks for dpkg-ruby and libdpkg-ruby*
   * Bump Standards-Version to 4.4.1; no changes needed otherwise
   * Vcs-*: point at salsa.debian.org
   * Add Rules-Requires-Root: no
   * Add Testsuite: field
   * Add gemspec file and install using the Rubygems layout
 .
   [ Utkarsh Gupta ]
   * Add salsa-ci.yml
 .
   [ Sam Morris ]
   * Silence parser warnings about parentheses after method name
 (Closes: #889651)
Checksums-Sha1:
 afe9c1bbe58c3d85f3aeec97cdc67e649a8d5739 1753 ruby-debian_0.3.10.dsc
 241040f986cf249bc3a540b1c54c80db3da978b2 178980 ruby-debian_0.3.10.tar.xz
 795688ef34ab8feccdbe34c169e1f2bd05cae963 12607 
ruby-debian_0.3.10_source.buildinfo
Checksums-Sha256:
 65756a9efad5d58f6b9cd8c5d8da6c694395c2afea58374a858e3ffde5ecca70 1753 
ruby-debian_0.3.10.dsc
 47144fbf873512e331fae3253d960d79143ad3833d77ab5044ba0822ce33579e 178980 
ruby-debian_0.3.10.tar.xz
 582077a6ce7c23edf2457d7e0f5be6dab9f8a14be6347d665af6bd3bd8d44926 12607 
ruby-debian_0.3.10_source.buildinfo
Files:
 9313a60b850f587b976089fbfb607343 1753 ruby optional ruby-debian_0.3.10.dsc
 031a27c378fadd8c84a59f1c8376f353 178980 ruby optional ruby-debian_0.3.10.tar.xz
 6890417df96a9d3e3992f6a2d57834b9 12607 ruby optional 
ruby-debian_0.3.10_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEst7mYDbECCn80PEM/A2xu81GC94FAl2zVWUACgkQ/A2xu81G
C975Gw/9HOYbvHcoyKd2wIzdIWB0UH/nxTdPwFcqo62+ckXlb9wcHQjydSW7qWcx
cJVqgYdEBCDJWHLWz+IwKnbD3MWgqGWHytOgRUKBTaG3kJd4EU3yb9PCbW7aRfKA
MndTIitgcKuoYiVwqHSiOv9GaSck4mDYBPNSFcKhtlercrhg5Y0P2Pql8sj07YCh
axl+VF9Um4MXnj6CnAIeHUr4+pQqd7/3jtPbS9HjJlS5KlAn/5KCBcQ/AUskZhnm
1gMzONZ6EtCTJgVncxbs0NaMXWy2Np3pHepxfgxhPZipYk+Bf6Q57buF/jfzfaL0
GOt6oOUxB/d0AIQpEMpSPzXhWpiomjH5T0RBLZoZ6VR7luJeAh7FdB9wKfBTem6A
NsXi4cmYtwv6O9Dmv8QODlDHElwbhWgiDobiqtlrAnyz4VJDgGMZmzxgIRtEjFsN
Azu1AFBqIGPD5vlqKyED6J7LkHzQPnBN405Iw7Pelh+IL6VY+lN5T+wg/wHW3GX9
NvBx2CZLShoZIXnPkQYD0kMPYy0Qw1IJV+Tzlm+wsKNkZCBgwY4NXLTAu++a4O3L
u2O8HlqGt01ppXzO2kr7hPBBN9rjtZjBqHsSzvcYYF56T+p6s0CqV08WCSOVMj+Z
Sjte8IRMvrHpjVeaBVdHPn2mEysHrIrLAPojq4v2jAEbRK57RNw=
=6OgN
-END PGP SIGNATURE-



Re: Merge request friendly handling of debian/changelog

2019-10-25 Thread Guido Günther
Hi,
On Tue, Oct 22, 2019 at 07:35:55AM -0400, Sam Hartman wrote:
> I agree that better handling of things like debian/changelog is
> something we should focus effort on.
> 
> I think we can either  do something gbp dch like, possibly allowing
> commits to annotate whether and to what extent they should be included
> in changelog.

gbp dch has flags for that can be part of the commit message:

  Gbp-Dch: Ignore

and

  Gbp-Dch: Short

Cheers,
 -- Guido

> 
> Or  some code that knows how to merge changelogs
> 
> Or some file based approach like you discuss.
> 
> I think exploring options like these and getting experience would be
> great for Debian.
> 



Accepted lmbench 3.0-a9+debian.1-3 (source amd64 all) into unstable

2019-10-23 Thread Al Stone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 23 Oct 2019 21:46:19 -0600
Source: lmbench
Binary: lmbench lmbench-dbgsym lmbench-doc
Architecture: source amd64 all
Version: 3.0-a9+debian.1-3
Distribution: unstable
Urgency: medium
Maintainer: Al Stone 
Changed-By: Al Stone 
Description:
 lmbench- Utilities to benchmark UNIX systems
 lmbench-doc - Documentation for the lmbench benchmark suite
Changes:
 lmbench (3.0-a9+debian.1-3) unstable; urgency=medium
 .
   * SCCS files are no longer usable for building the package
Checksums-Sha1:
 4e15d6cddbb292ab45300bdfc48885ab5ba9eed2 1911 lmbench_3.0-a9+debian.1-3.dsc
 e15f507001628990b23609fed916af2269328da7 16184 
lmbench_3.0-a9+debian.1-3.debian.tar.xz
 89dc1332d90d20ce2170e9ee7de5de7a8f32eb53 53408 
lmbench-dbgsym_3.0-a9+debian.1-3_amd64.deb
 e2cd8bd8d2d674a62d0ea2b9d58da5df3e068ebd 190632 
lmbench-doc_3.0-a9+debian.1-3_all.deb
 0946e1a975dc086df22daf2f2490072ebdd0463a 7159 
lmbench_3.0-a9+debian.1-3_amd64.buildinfo
 5856c23c9a44532f119a1d819fb5b7b3e1893c7e 431664 
lmbench_3.0-a9+debian.1-3_amd64.deb
Checksums-Sha256:
 e7badeb568e266d242b67e0524dc72936a63e22e48325c66433f49fbe43656b0 1911 
lmbench_3.0-a9+debian.1-3.dsc
 35f7dc160db8586b7ff03a81a02bc81298872b9898921f9edd0d0903cda915ae 16184 
lmbench_3.0-a9+debian.1-3.debian.tar.xz
 5ef33d2c55c9f1128f6dedfc6f8ea4c79d3770ed9782026316742003fea00603 53408 
lmbench-dbgsym_3.0-a9+debian.1-3_amd64.deb
 93e654a9785e19537ef0d8e81749aef74394c11fc959fd48a2b9d3ea6b2b8456 190632 
lmbench-doc_3.0-a9+debian.1-3_all.deb
 6ce97ea8a24e8bb566263d2750645fae189b1a4741b035bab2fd5dfee4d0ea7c 7159 
lmbench_3.0-a9+debian.1-3_amd64.buildinfo
 6622d434f6223a3d2efa42b0749df13f14f2c10b6c353b8a754d716ead210079 431664 
lmbench_3.0-a9+debian.1-3_amd64.deb
Files:
 d4ec11f0d6675e22862c299c030ec59d 1911 non-free/admin optional 
lmbench_3.0-a9+debian.1-3.dsc
 d102b67957b2a56f86ec623ba0add507 16184 non-free/admin optional 
lmbench_3.0-a9+debian.1-3.debian.tar.xz
 d20affc96063e7193003e882d97eef2a 53408 non-free/debug optional 
lmbench-dbgsym_3.0-a9+debian.1-3_amd64.deb
 d11c160553176b60c594bf096d8428ad 190632 non-free/doc optional 
lmbench-doc_3.0-a9+debian.1-3_all.deb
 8531065811c1d2457c0f5c3da3baea1b 7159 non-free/admin optional 
lmbench_3.0-a9+debian.1-3_amd64.buildinfo
 7ca7ad953278cd30f8f54076841c4a2a 431664 non-free/admin optional 
lmbench_3.0-a9+debian.1-3_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEiclaKI7ZGQ+4GJLWUwywAtdhsWwFAl2xH0YACgkQUwywAtdh
sWx9QQ//StshVB71hX07pvomWrx6xujW7Er7eeINiZUeC39NV5JHgNplepcF2Kf5
PxfRw+8QgkVrsRyit0ml29eWQcWhr1FDBPlXBStM/asvJEwAyJH11P7zHIqqN3Ed
I1BKoI1ZbLy2355whwrQDnV4ZjxAIJdpvPGLe1hCYpOPgPbgaoFXWbBwI34Fy1Km
eAHLduEhOiHZqtfxtrk2qzg0qNKvs+kFgiv2jS9poAGyMdT5XME72+72LvyCqfZI
ym7onmAl+4YryVwer17MT3qSod357pSvxfJsQ72EwU7+C0fANLR15wuckaMI6YJs
FPUWiNEr2cwGE+BHeNuSBDOylWDg5VWSLqn0Q3wmXOW7fl9gpzElsFSTZnp6uMCO
QVulBNEqWDiTLHqTosI99xlIPfkwUonP+ze69muYoLeNNK8rJe4fap96XRAXYvri
XZ09RsGFW/smP6n3CSxYEE6Cxv/HCByZE3RUy9yaUe6cRhhc7qQejLYA4OZBJvFn
MEV+ehzpuD5D+I5sNYA0fyCfeIwijOfg1TbWUFV1AFT7d93w0ifuzTXE12GZPpuO
wjWWtp/5t59k7bruflRO9KpIbZ+IolCOFVxVz571/GguVGcLB8Yjq0cxSP6GjZAj
QvicVv2zYYaWycKjrivX67Xv7+27UArAme+OuoDVebc1zO7OIw4=
=347z
-END PGP SIGNATURE-



Accepted debian-cd 3.1.27 (source) into unstable

2019-10-23 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 23 Oct 2019 18:06:41 +0200
Source: debian-cd
Architecture: source
Version: 3.1.27
Distribution: unstable
Urgency: medium
Maintainer: Debian CD Group 
Changed-By: Holger Levsen 
Closes: 935546
Changes:
 debian-cd (3.1.27) unstable; urgency=medium
 .
   [ Samuel Thibault ]
   * Keep grub resolution in EFI boot, to avoid tiny fonts (closes: #935546).
 .
   [ Steve McIntyre ]
   * Update arch lists in build_all.sh, remove arches not in bullseye
   * Update ordering of checksumming in imagesums
 .
   [ Holger Levsen ]
   * contrib: Updated from setup.git/bullseye/.
   * d/control: Bump standards version to 4.4.1, no changes needed.
Checksums-Sha1:
 99757a07c44e5060d554de06040dae2047a51303 1741 debian-cd_3.1.27.dsc
 fcca83564267179fa2c7c0de2865bbd63abe0651 1164648 debian-cd_3.1.27.tar.xz
 d341e4da869c9b7f41ef9515c8eea093eb704113 5231 debian-cd_3.1.27_source.buildinfo
Checksums-Sha256:
 a827fab49f6b2aa3079f29525941dc505723a959be00b0fc59ee631b2be09b71 1741 
debian-cd_3.1.27.dsc
 4247a02e6b95ef43fda9272f9c1f5210bc2828dc8c0510263f9ee9594db7f98d 1164648 
debian-cd_3.1.27.tar.xz
 36908d40cec66087d2bb9e4001ab1d170befd4dcf6908b90afe096bb113114f1 5231 
debian-cd_3.1.27_source.buildinfo
Files:
 de0671c5e95292d2758414260901da67 1741 admin optional debian-cd_3.1.27.dsc
 fe548d80bbf6967cdd222c7d2e28d397 1164648 admin optional debian-cd_3.1.27.tar.xz
 9e954077aeb00cb9904c0c0f77c574b4 5231 admin optional 
debian-cd_3.1.27_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl2wewAACgkQCRq4Vgaa
qhy5ahAAn/YFx8Mnwe9R4XZPjKoBIrz+k9VdQWmk4s25WLuhPZSLn5Qig+BFd4TI
kQN5M5hgsbRPk1dE24422iZ9RuT85g7rOZ6NfbnD2wG7juplMKK/DxIxsejZZNoZ
rRCte581UA3zyrZHikoWOLz2hIS69UhCvjCcwGmJK4s5B0yy3IvozsjdnlTLyeKq
2Qv+r1e6LiJzv6AQIMDvxcjA5U37DOVYNqqWIP9uQXWJPFJ2QtaXZH4cpt/bcTcv
99oi6x+6vKV3NnZ8Jb7d7fc1GEFf7CKt7OOgzTLAyTAFUBOeV4wcsX7wazcHIS0C
XDzl+Zk31dkArWXCITyG0L/bySddAO50/1zvV88MP6HlZT0o2yIX8naNFRwOPx/c
Yx6vi4PBE67M3trBEYiDpIv6GDcwX50g3I4A0qOEBKeB0LrdOy/jMw4o/ftuixy8
L+neJAEvzZPo3Zh9n1rnxijWO5fqZqueoy3yVQKVQaEvHdBiHg+3jOB9yn641Ca5
S6dvusnC9Sjm2XllYTBdHIaMom8MHL3iHSYe+HV+Sb0iDv7YxPO6Z8ghQOUloXzY
R1+hQxMJ0LOcIYZ0E8qYYYWFi9Bbz2043fdbO9Dp0MK0nJM9vmXvv5O3s9BDXQ7P
Sy98O467E45OAeu5R8GcRp193jhrGZYtwdd182qC7Yf9eo93y6k=
=ZImT
-END PGP SIGNATURE-



Re: Merge request friendly handling of debian/changelog

2019-10-23 Thread Simon Richter
Hi,

On Tue, Oct 22, 2019 at 04:47:53AM +0200, Bastian Blank wrote:

> In Debian most people prefer to have changelog entries with all changes,
> so changes always contain a modification to debian/changelog.

It's worse than that: changelogs are supposed to contain the linear history
of the branch they are on, so the bug tracking system can determine fork
points and find out whether a particular bug is fixed in a particular
version.

> If we also start to use merge requests on Salsa, all those changes will
> contain modifications to debian/changelog, which will usualy conflict
> with each other.  Or worse, are applied to an old changelog entry.  This
> for example happens on the linux packaging project.

Yes, changelog merging needs to be special-cased with a tool that
understands the semantics, in the same way you are not presented with a
conflict resolution screen for the commit message when merging two branches
in a VCS.

Your proposal loses a bit of metadata in the VCS, because the changelog
entry is shown as having been created by the final release commit, and
backtracking through the VCS is made harder because of this. I'd consider
"git blame debian/changelog" to be a very useful tool.

   Simon



Accepted debian-edu-config 2.11.6 (source) into unstable

2019-10-23 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 23 Oct 2019 13:26:45 +0200
Source: debian-edu-config
Architecture: source
Version: 2.11.6
Distribution: unstable
Urgency: medium
Maintainer: Debian Edu Developers 
Changed-By: Holger Levsen 
Changes:
 debian-edu-config (2.11.6) unstable; urgency=medium
 .
   [ Wolfgang Schweer ]
   * cf3/cf.workarounds: Fix syntax.
   * testsuite/icinga: Adjust for moving from icinga to icinga2 and
 icinga2-classicui.
   * testsuite/ltsp: Adjust for reworked LDAP certificate setup.
   * testsuite/cups: Adjust for central ipp server.
Checksums-Sha1:
 0abe7253ae89fa83bd059c338959f6f926b6f927 1914 debian-edu-config_2.11.6.dsc
 94cc780553ea9262eb8374822820182b40cd82d5 340612 debian-edu-config_2.11.6.tar.xz
 3f3b9049581c8f95074c63d20796b61d4e2980ae 5271 
debian-edu-config_2.11.6_source.buildinfo
Checksums-Sha256:
 cd06748b496ebc107f37f157e9d9b6d715d0a570bb411e09296e765a45bf76ea 1914 
debian-edu-config_2.11.6.dsc
 5491fa2de3fc3a22ca3a9d33a9d3ab926affdaf42be92b78eca73e154f7ba614 340612 
debian-edu-config_2.11.6.tar.xz
 f8fb8962a6de44fc5340d93f29e5810cd73f130f1b32fea8cbd0a5177ef65a8a 5271 
debian-edu-config_2.11.6_source.buildinfo
Files:
 1436002fa0db4ab78dbcd9889793f580 1914 misc optional 
debian-edu-config_2.11.6.dsc
 763f8d5f61a6d15bd5d698e21db24753 340612 misc optional 
debian-edu-config_2.11.6.tar.xz
 32c2b07e064ef251d59c525f659f9d1a 5271 misc optional 
debian-edu-config_2.11.6_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl2wOZkACgkQCRq4Vgaa
qhz6UA/+JBFmoosf6wfdXFyt7/nFTYlTWxknriIHKUQFT8Y4Lj9KFkr8hO3MiMbi
R1QVIPcghT0RnHtOtARrz19EAYBQMOU7DLKceRMDu2elirDChRJzsWT/636M+ULV
9MEE1G+455QxNphsZ35yckRJ4qKOpPMp4WvTWWBMuLZwFxsCJo56P9PbnKeyqYZ+
c4knjvCfya3Elo6eZ9WgOvk3VQn3pN7DEWj6QAhRsq9d97u9tIsmIK6I6CdemSxT
LrJfyXs14fROeJ8O/ohPCIJ+yH1YQwVyr+D9tvw+Wk3PjdbqnhN6QBgQ7Auwmhfj
gB97N9r9xSqM4jemEvO6HDpFUepxXOwZZ8G4xDpr8l2KpGIjTty3PrZy/IEmylao
RcCC3Ju8gAT1rwBVa9fDLlpOtIHiI2FtW8mgqWsSznIvhiQw7uoodeL20xmA+qNn
1RiXaTSXZVoRcthoHIViXiIQgLFTX/sdphZxEhdS4Fh/64PONzqmYnWSCVms4+ia
sQUQqssyVJ+oJ8/Y90TkIyz1G4LRYSjcy5g4puiL0xoLMUZNEbVnpDUbfekpi2Br
73SA6q9lEsZcycp1iGcijvv7ddX6vVR1GzIbrnw8qYP/6hockRtANxFN0/a7A2ow
gNbXx1yRg3b+Dyc331GPMjmtWuf3nc4h5cV2F8pBklDuYBoQELg=
=nnxl
-END PGP SIGNATURE-



Re: Merge request friendly handling of debian/changelog

2019-10-22 Thread Jeremy Bicha
On Mon, Oct 21, 2019 at 11:06 PM Bastian Blank  wrote:
> There is "gbp dch", which ignores merge commits (so no really good for
> merge requests), but I don't consider it to have enough control over the
> content of the changelog.

Just set your merge settings per project to fast-forward.

Thanks,
Jeremy



Accepted gitlab-workhorse 8.8.1+debian-1 (source) into experimental

2019-10-22 Thread Utkarsh Gupta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 22 Oct 2019 18:01:42 +0530
Source: gitlab-workhorse
Architecture: source
Version: 8.8.1+debian-1
Distribution: experimental
Urgency: medium
Maintainer: Debian Go Packaging Team 

Changed-By: Utkarsh Gupta 
Changes:
 gitlab-workhorse (8.8.1+debian-1) experimental; urgency=medium
 .
   * New upstream version 8.8.1+debian
   * Fix package wrt cme
   * Bump Standards-Version to 4.4.0
   * Bump debhelper-compat to 12
Checksums-Sha1:
 466403f3a7a7754181861afb06a5d3053fdf2aff 3028 
gitlab-workhorse_8.8.1+debian-1.dsc
 7c2523f8fd36f93b446a5ab945741fcf5ee086fe 909100 
gitlab-workhorse_8.8.1+debian.orig.tar.xz
 395ca421dd8aa6d5892f9111a30a8f29a4002ccd 4192 
gitlab-workhorse_8.8.1+debian-1.debian.tar.xz
 2df987d286829595bfe77de9ca704519f130bbcd 9339 
gitlab-workhorse_8.8.1+debian-1_amd64.buildinfo
Checksums-Sha256:
 58c2807630b133068fa4aafa14c7d85534905165480e0b1256adcb5dcc13b662 3028 
gitlab-workhorse_8.8.1+debian-1.dsc
 e7bf91f6d41a165e39fc4903c8a578c5b19f6df8305141712559e02192502e6d 909100 
gitlab-workhorse_8.8.1+debian.orig.tar.xz
 104a616a2380b125c9989bc1e69d7c17a41e98db5bf04eca5c2702d626230a7e 4192 
gitlab-workhorse_8.8.1+debian-1.debian.tar.xz
 b00fe040a56caca986a9e91ed7b5fdfaf8a2194eb6357175abe3b289db376b09 9339 
gitlab-workhorse_8.8.1+debian-1_amd64.buildinfo
Files:
 a60a36a3dd4b4f7fd6ec5785c78b0864 3028 httpd optional 
gitlab-workhorse_8.8.1+debian-1.dsc
 d40bdd88623a6f56ec0e4d84a2c4eadb 909100 httpd optional 
gitlab-workhorse_8.8.1+debian.orig.tar.xz
 68bee59bee747014b909c6e6ec10e881 4192 httpd optional 
gitlab-workhorse_8.8.1+debian-1.debian.tar.xz
 5d5a3370e5603c5a1e93b349c2159d30 9339 httpd optional 
gitlab-workhorse_8.8.1+debian-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJPBAEBCAA5FiEEbJ0QSEqa5Mw4X3xxgj6WdgbDS5YFAl2u+LkbHGd1cHRhdXRr
YXJzaDIxMDJAZ21haWwuY29tAAoJEII+lnYGw0uW3HoP/RM6VpowJRxqm9UIx0Kh
MrXh0xsZLsyrRe8yuOJIC/O2JPqOT7YITYf3+xX5dcXJ9IVS3VpYf4e0H8A/bP7E
XespfXxe+kzzp0P6N/vBSyqCd7PQZtzx6bp8Dki9RR5LKm+mm4iqMAVak23qCtFq
t1QggQVLS/uh9bx8H/4JgvyVcQYYPQf/k0dmO1p54HsVXr1yK4P/RVsrwaAwqX0X
cGJ736axngEg5Qdvhj1n+FttcGeNxq6roZHVUdZNG/4kFdmsgJE1L6fshIH1RN3s
2WsrOPm9BWILSzZBKg5lWp+snpKbM9tjGwu5xVBYrA+AHHgAkfbjtQSpD64xdPlM
6bHzvKuS+ZuF44V6edC3EVho0xIzZYwiKKomC3Es7+okO6UHiD5tyTRSmm/SvTwW
tJlfeE1AezHfQ9LIniQu/oBCzHxBaSen/JzJqhJragXm10EoIYrneaOS6FEiIOCq
rEgDsPOrG+yHUL6SdDiBwulSLzgqfCeEOG81JLudFFxWd1GlWKx1dByx0IrOqrdk
/rX5vFiwfgLKkL++SVulvpmCuCZ+u4345dIP2oBsLwnZa2tOhsnko3UQEuoHq4lZ
iQK/8ry9+gadtJIgBt4PCRfEG6VN6BAQTNkBrxaCPbKD+nBo574NFLZUvNq3gZKu
Tg5B1EdKC1cNpC7O1qAsdltM
=0cq1
-END PGP SIGNATURE-



Re: Merge request friendly handling of debian/changelog

2019-10-22 Thread gregor herrmann
On Tue, 22 Oct 2019 07:35:55 -0400, Sam Hartman wrote:

> Or  some code that knows how to merge changelogs

dpkg-mergechangelogs(1) is a nice helper for some of the merge
situations.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature


Re: Merge request friendly handling of debian/changelog

2019-10-22 Thread Sam Hartman
I agree that better handling of things like debian/changelog is
something we should focus effort on.

I think we can either  do something gbp dch like, possibly allowing
commits to annotate whether and to what extent they should be included
in changelog.

Or  some code that knows how to merge changelogs

Or some file based approach like you discuss.

I think exploring options like these and getting experience would be
great for Debian.



Re: Merge request friendly handling of debian/changelog

2019-10-21 Thread Joseph Herlant
Hi Bastian,

Full disclaimer: I probably don't contribute often enough inside
Debian to be a reference on it but thinking about it I'm wondering if
it wouldn't be easier to do it another way.

On Mon, Oct 21, 2019 at 8:06 PM Bastian Blank  wrote:
> There is "gbp dch", which ignores merge commits (so no really good for
> merge requests), but I don't consider it to have enough control over the
> content of the changelog.

I honestly generally only use gbp dch (and I reformat sometimes its
output to make it prettier).
2 reasons for that:
* it avoids conflicts when you have several MR
* it also forces me to have more relevant commit messages. Most of the
time the changelog entry I've seen in the MR is the same as the commit
message anyway so gbp dch would generate the same output, you're just
doing extra work which is already automated inside gbp dch

On another point, it would be really nice if we could have a way to
squash merge requests to avoid having the merge commit every time
cluttering the git history. I know that github has it, which lets you
rework the final commit message if you feel like it's necessary and
that allows you, as a contributor to not have to squash and force push
after each feedback for example (that also adds the MR number
automatically which is nice). I'm pretty sure there's a way to do it
in gitlab I just haven't seen it available yet in salsa.

> The way that for example GitLab chooses in many locations is to create
> split files and merge them together in the final release process.  They
> now not only use that for the core software changelog[1], but also for
> stuff like release posts.

It looks like the same idea as the reno software that openstack uses:
https://github.com/openstack/reno
But doesn't it clutter a bit your tree for things that you're going to
get in your changelog anyway in the end?

> So one rough idea could be:
> - "dch $message" writes a dummy entry to debian/changelog if it does not
>   exist and the entry to debian/changelog-unreleased/$hash.
> - "dch --release" collects the snippets and creates one large entry.

Other though, could we instead not populate the changelog inside the
MR but have a script that takes a MR as input and merges the MR using
the title of the MR as short description and description of the MR as
long description? (yes it is kind of what a merge squash does on
github)
And then use gbp dch to take care of actually updating the changelog
when the release is actually ready?

Thanks,
Joseph



Merge request friendly handling of debian/changelog

2019-10-21 Thread Bastian Blank
Moin

In Debian most people prefer to have changelog entries with all changes,
so changes always contain a modification to debian/changelog.

If we also start to use merge requests on Salsa, all those changes will
contain modifications to debian/changelog, which will usualy conflict
with each other.  Or worse, are applied to an old changelog entry.  This
for example happens on the linux packaging project.

I don't think we already have a way to get around this?  Do we need
some?

There is "gbp dch", which ignores merge commits (so no really good for
merge requests), but I don't consider it to have enough control over the
content of the changelog.

The way that for example GitLab chooses in many locations is to create
split files and merge them together in the final release process.  They
now not only use that for the core software changelog[1], but also for
stuff like release posts.

So one rough idea could be:
- "dch $message" writes a dummy entry to debian/changelog if it does not
  exist and the entry to debian/changelog-unreleased/$hash.
- "dch --release" collects the snippets and creates one large entry.

Regards,
Bastian

[1]: https://docs.gitlab.com/ee/development/changelog.html
-- 
One does not thank logic.
-- Sarek, "Journey to Babel", stardate 3842.4



Re: Debian and our frenemies of containers and userland repos

2019-10-21 Thread Paul Wise
On Mon, 2019-10-21 at 18:58 +0200, Enrico Weigelt wrote:

> I'm pretty sure it does exist, since I wrote it :p
> 
> https://github.com/metux/docker-buildpackage

I couldn't find it in Debian so I incorrectly assumed, sorry.

In case you want to get it into Debian:

https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part


Re: Debian and our frenemies of containers and userland repos

2019-10-21 Thread Enrico Weigelt, metux IT consult
On 05.10.19 19:03, Bernd Zeimetz wrote:
 > For that, developers also need or want the
> latest shiniest software - which is something a distribution can't provide.

It can, but that needs different workflows and higher grade of
automation. (and of course wouldn't be so well tested)

Actually, I for python world I already did something: fully automatic
import and debianziation for pypi-packages. Yet experimental and part
of another tool (which I'm using for building customer specific
backport- and extra repos):

https://github.com/metux/deb-pkg/tree/wip/pypi

> I'm wondering if there is something Debian can do to be even more
> successful in the container world. 

You could use dck-buildpackage --create-baseimage to do that.
Feel free to create some target configs, and I'll be happy to add them.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287



Re: Debian and our frenemies of containers and userland repos

2019-10-21 Thread Enrico Weigelt, metux IT consult
On 07.10.19 13:17, Shengjing Zhu wrote:

> Why not have a repository for it, like dockerhub. So this becomes
> "pull latest build env", which saves lots of time("re-bootstrap" is
> still slow nowadays).

No idea how sbuild works these days (turned away from it aeons ago, as
I've found it too complicated to set up), but dck-buildpackage can do
both. It can try to pull an existing image for the given target, but
will bootstrap it when there isn't one.

IMHO, the best idea is treating images as nothing as a cache, and
having the build machinery bootstrap automatically when needed.

One thing on my 2do list for dck-buildpackage is keeping cache images
for dependency sets (eg. if the same package is rebuilt many times,
during development) - installing dependencies can eat up a lot of time.
(for now, this can be achieved manually, by configuring a target with
dependencies already installed - but I don't like manual things :o)

BTW: one important point w/ dck-buildpackage for me was being able
to specifiy what's in the image. I really prefer to have it really
minimal.



--mtx


-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287



Re: Debian and our frenemies of containers and userland repos

2019-10-21 Thread Enrico Weigelt, metux IT consult
On 05.10.19 18:25, Bernd Zeimetz wrote:

Hi,

> Having something that works with git-buildpackage would be really nice,

:)

> though. Even better if it would allow to use the k8s API to build things...

Patches are always welcomed :)

There're some problems to be solved for remote hosts (IMHO, k8s only on
local node doesn't make so much sense ;-)):

dck-buildpackage currently mounts some host directories (eg. local apt
repo and reflink'ed copy of the source tree) into the container. While
one could put docker nodes into a shared filesystem, that probably
wouldn't be so nice w/ k8s ...


--mtx


-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287



Re: Debian and our frenemies of containers and userland repos

2019-10-21 Thread Enrico Weigelt, metux IT consult
On 05.10.19 03:31, Paul Wise wrote:
> On Fri, Oct 4, 2019 at 10:49 PM Enrico Weigelt wrote:
>> On 24.07.19 08:17, Marc Haber wrote:
>>
>>> Do we have a build technology that uses containers instead of chroots
>>> yet?
>>
>> Something like docker-buildpackage ?
> 
> AFAICT, docker-buildpackage doesn't exist 

I'm pretty sure it does exist, since I wrote it :p

https://github.com/metux/docker-buildpackage


--mtx


-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287



Re: Wifi en debian

2019-10-20 Thread Jeremy Stanley
On 2019-10-20 18:32:00 -0400 (-0400), Peter Silva wrote:
[...]
> Debian is very principled about not including non-free software, but you
> can build an installation medium that includes the firmware so almost all
> wifi should work out of the box.
[...]

Or use the installation images available from
https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/
which have it baked in.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature


Re: Wifi en debian

2019-10-20 Thread Peter Silva
translation of spanish email:  disappointed wifi didn´t work out of the box
with Debian thinking wifi drivers are missing.

answer:

I don't think the drivers are the problem for wifi in Debian. Most, if not
all wireless chipsets have open source drivers which are included. The
problem is that many wireless chips require non-free firmware.  check out
the list here:

https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers

Debian is very principled about not including non-free software, but you
can build an installation medium that includes the firmware so almost all
wifi should work out of the box.  see here:

https://www.debian.org/releases/buster/amd64/ch06s04.en.html



On Sun, Oct 20, 2019 at 5:42 PM riber enyos  wrote:

> Queridos debianos,
> Estos días estoy probando diferentes distribuciones de linux. Entre ellas
> Debian. Creía que era una de las mejores, pero me he dado cuenta de que es
> la peor, según mis gustos.
> ¿Como puede ser, que una distribución del 2019 venga sin los drivers del
> wifi instalados??? De todas las distros, y he probado bastantes, Debian es
> la única que viene sin wifi. He buscado en internet, y la única solución
> que dan es conectarse por cable para configurar la wifi. Pero se supone,
> que si me conecto por wifi es porque no tengo la posibilidad de conectarme
> por cable. ¿Tan difícil es dejar instalados los drivers? Hasta en las más
> básicas y pobres distros te puedes conectar por wifi. La verdad es que no
> entiendo el motivo.
> ¿Sabrían decirmelo?
> Muchas gracias.
> Riber.
>


Wifi en debian

2019-10-20 Thread riber enyos
Queridos debianos,
Estos días estoy probando diferentes distribuciones de linux. Entre ellas
Debian. Creía que era una de las mejores, pero me he dado cuenta de que es
la peor, según mis gustos.
¿Como puede ser, que una distribución del 2019 venga sin los drivers del
wifi instalados??? De todas las distros, y he probado bastantes, Debian es
la única que viene sin wifi. He buscado en internet, y la única solución
que dan es conectarse por cable para configurar la wifi. Pero se supone,
que si me conecto por wifi es porque no tengo la posibilidad de conectarme
por cable. ¿Tan difícil es dejar instalados los drivers? Hasta en las más
básicas y pobres distros te puedes conectar por wifi. La verdad es que no
entiendo el motivo.
¿Sabrían decirmelo?
Muchas gracias.
Riber.


Accepted debian-installer-launcher 36 (source) into unstable

2019-10-20 Thread Holger Wansing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 20 Oct 2019 22:10:50 +0200
Source: debian-installer-launcher
Architecture: source
Version: 36
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Holger Wansing 
Changes:
 debian-installer-launcher (36) unstable; urgency=medium
 .
   * Team upload
 .
   [ Updated translations ]
   * Croatian (hr.po) by gogogogi
Checksums-Sha1:
 201addeceecb9830085aab82b327926d28351481 1689 debian-installer-launcher_36.dsc
 370737cf1be9c87c48d703a6d5ec62b2e8b1e686 44372 
debian-installer-launcher_36.tar.xz
 261534dcfb6c509f967c9459a644e364d30cd283 5576 
debian-installer-launcher_36_amd64.buildinfo
Checksums-Sha256:
 47a63f1276ff2864e74d676d5f7b1ad726f800aba28417db97a4df84e3daab7b 1689 
debian-installer-launcher_36.dsc
 c960cd6f93f2bcbc55c75b4966481fe60353944d77f6b666af5d85ff88902ecf 44372 
debian-installer-launcher_36.tar.xz
 edc32e1981d6c89d15d087b5f6e755f87044c8ac248c3365b1549fe7dc9aa6b9 5576 
debian-installer-launcher_36_amd64.buildinfo
Files:
 bb72ee6688089cb751e9fc55b65ebeee 1689 utils optional 
debian-installer-launcher_36.dsc
 216284860565b781251aa41dd75bae29 44372 utils optional 
debian-installer-launcher_36.tar.xz
 85a85307f3354891d573d9c693717ed8 5576 utils optional 
debian-installer-launcher_36_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJJBAEBCAAzFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAl2swmsVHGh3YW5zaW5n
QG1haWxib3gub3JnAAoJEFnxh8oVbrB29yYP/02QCFr6HG+KS1aXXHN8AmtfhZ9m
wLjzGioT4+cGaZMRBLvSeeR80goKkrYKtBzE3fWXlQDeYEPOhgg2D8XLv/y5olKp
Amzvzn4rA6ZgBDczz8hTQnmuo55ZiYdQuKUuYeI7d/rzGM+xFUYibryw2OYmXgkH
Lv0mQOn7AvJH2aJQLl7fFKi/ZYILV+Tp36RBrNmluEDtEXfGB555s4WnbH1ab8SV
6M7uty+++GwWN/5BLhKLZOvH/pzxoT9EbYm5P6JnCSeqSYP0C+Q+DZxUlWezqazX
NUxc5l0oWiDaNnKVFlIxLjEeIL3YoZIbieaFb/r82LPWRDLucOXsNNENuD+HOEj3
Mk/fJL3mLuQke6v/e0XFNw4Em3kpc542azdZPPo6lpI4eRWZ5vS4Td3wWSOrYMT8
d5z2rIFvJzBOofgr8yaJ26/w1NFmrqfIsbXG7h7QooSd8twPZtitQn/kKY6Xksk4
zFBYSdFE8ZcFbiXwCAg08wIHK4U/ZH1UMF6qE9aSjCNNfY9ld4A4KnEjQk51AGcl
RPhKGvL0SooNzo3gSdliKKsGVKhNQy8qbWRRjsLUmvqsR90GBkBKsjrtF9NXMuD3
X58PeqFo8iIp8kNZY1erleeOw2UWWtVe8z5sdUmHEtVPVJ+IalYQ3MyR0gXHnfSp
QC8NrXbLReqqErjA
=i9eW
-END PGP SIGNATURE-



Accepted debian-edu-doc 2.10.20 (source) into unstable

2019-10-20 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 20 Oct 2019 15:21:06 +0200
Source: debian-edu-doc
Architecture: source
Version: 2.10.20
Distribution: unstable
Urgency: medium
Maintainer: Debian Edu Developers 
Changed-By: Holger Levsen 
Changes:
 debian-edu-doc (2.10.20) unstable; urgency=medium
 .
   [ Translation updates ]
   * Buster manual:
 - Chinese (Simplified): Ma Yong
 .
   [ Holger Levsen ]
   * Bump standards version to 4.4.1, no changes needed.
   * Bump debhelper-compat to 12.
Checksums-Sha1:
 92893ecf1b97c51c48a23be0ab5ed5449e18989f 2700 debian-edu-doc_2.10.20.dsc
 3e8368fb824224a0449064b4d3d0255f2419ee76 30607428 debian-edu-doc_2.10.20.tar.xz
 ea8b6af45822c23fb90a874902d8e5493b92e156 5433 
debian-edu-doc_2.10.20_source.buildinfo
Checksums-Sha256:
 622d1969c2ae9d43011c9f77b8bd35b066cbfc460666a0e4eeab284cc4da2eb2 2700 
debian-edu-doc_2.10.20.dsc
 908a311d25f1a0623cf7c90730af25c8335b0a3f66fa5cd1cb54ad4595a17c91 30607428 
debian-edu-doc_2.10.20.tar.xz
 3b913dcda0b0a4ce282abfaa22d1484c63176c32e978c172c8ad645bfbc5a484 5433 
debian-edu-doc_2.10.20_source.buildinfo
Files:
 3930be45cfd33e9b3a620b0fc101dedf 2700 doc optional debian-edu-doc_2.10.20.dsc
 e1fe571dbe3515f9fa2f17e086bd8379 30607428 doc optional 
debian-edu-doc_2.10.20.tar.xz
 c006e716500bbd5fe7e1d2a6a8d9fe85 5433 doc optional 
debian-edu-doc_2.10.20_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl2sX9EACgkQCRq4Vgaa
qhxNWQ//bGujCjW8NQjtithpv5mQY/x5LZFjULymgi5jfgZGHcH/qacnMsfboHVr
McdQy25wqBjDqBtWL+w5nJunD4laMm8LZIZVXMnYNMPXnB1tl2Nmh49dvY20X6io
sivWegewdN28VK00xf/2TDqlEgPFJC/ZXhpCONVkrsQqLAlPJpicp1rqiVGbMSYr
81brgAJR5ef0rEUrs08et5NmMufRMjK1hjfU6b5elRg5X1VMCDMrYGmYVwL5WKrD
0XiNMD3xuyXEmiLCvuBonnkrqoVrWm9oyiRsDchsKCTTK93Sc+FWDhOMIzduYChG
xFYXbHKOpcffl057ZAf1Id5ylKGWT2uuzvmJ2jl1KYTFQ4R3OWX6E/9iibeMtaCc
EOpqNlFCUuXvFxmTyutKVncnefeXIVVEOL6BjF2j2jELI+SctdY7T0vsnyOGNEk5
pkNOI9DqSvgEdU3unZp4ZoEehGdGfA38lXpIAngDuRo0vRZIaiw2hmJkKYSA3Z2p
MMKFkNaHTc5hBeYA/H6UWT3NHWHOqeVsMoitZPhOYQeWWhdgU+QQ3p1IvZXaAArt
uhyAotYngv04xkIycbTG96hkDleqeeGva6WHgxOUlAKwhwe49F9+QWtZ1fW/KKQG
8z7Ouyzu6j//7EHnNCjV+hMRGCAhjpWRTUP06TaXtFh5MfvTv1U=
=Rdi7
-END PGP SIGNATURE-



Présentation de Debian au Capitole du libre

2019-10-19 Thread Jean-Philippe MENGUAL
Hello,

J'ai proposé au capitole du libre une présentation de Debian
volontairement orientée grand public, donc un peu hétérodoxe. Ca manque
d'exactitude lexicale et de rigueur terminologique, mais c'est fait
pour, via l'analogie du magasin de distribution.

Je vous soumets le premier jet (pleins de fautes je pense, mais je
corrigerai l'orthographe après):
https://salsa.debian.org/debian-france-team/workshop/slides-de-pr-sentation-de-debian

J'aimerais un avis et de l'aide pour:
- la conformité de ce que je dis à la sensibilité de notre communauté
- des remarques sur le format: je pense utiliser pandoc, mais je ne sais
pas si visuellement ce sera acceptable. Toute aide sera bienvenue sur le
format donc, et si ça demande que j'écrive beaucoup moins, je peux.
- des contributions graphiques: je pense rajouter des liens, mais si
vous avez des idées d'images, de photos, etc, pour illustrer, je prends.
Ca permetra put-être de moins écrire, je garderai l'écrit pour mon pitch

Merci à tous de votre aide et de vos retours

Amicalement,
Hello,


-- 
Jean-Philippe MENGUAL




Une information pour ceux qui veulent nous aider à promouvoir Debian

2019-10-19 Thread Jean-Philippe MENGUAL
Bonjour à tous,

Déjà pour présenter à ceux qui ne connaissent pas: Debian France est une
 asso française qui promeut Debian. Elle est administrée par des
dévelopeurs Debian, mais pas que (je suppose qu'elle est connue mais
bon, sait-on jamais s'il y a de récents et nouveaux DD).
En tant que Trust organization, Debian France, qui a plus de dix ans, a
des stands aux events français, organise des minidebconf, des meet-ups, etc.

Pour le parisiens, on peut contribuer ensemble à l'asso et à Debian tous
les jeudis dans les soirées de contribution au libre organisées par Parinux.


Pour ceux que ça intéresse, signalez-vous sur la liste
a...@france.debian.net ou ici et venez nous voir! On n'y est pas
toujours mais si on a du monde pourquoi pas.

Nous aimerions organiser deux thèmes d'ici novembre:
- la rédaction d'un flyer double sur "Contribuer à Debian" (difficile
tant c'est vaste) et "Aider Debian France". Toute compétence de comm,
graphime, etc est bienvenue à nos côtés.
- j'ai besoin d'aide pour monter une conf pour le Capitole sur le thème
Préenter Debian au grand public. Le concept que j'imagine repose sur
l'idée de préenter Debian comme un distributeur de logiciels, avec tout
ce que cela implique pour l'utilisateur et le contributeur. Mais j'aurai
besoin d'aide car je veux que ça soit fun. Je fais un mail spécifique
tout à l'heure.

J'en parle ici car cette présentation, volontairement hétérodoxe, je
voudrais m'assurer qu'elle ne choque personne du projet.

Amicalement,






[Doc] Deep Learning & Debian Development

2019-10-13 Thread Mo Zhou
Hi fellow devs,

FYI, I wrote a lengthy documentation that covers many
sub-topics about "Deep Learning & Debian Development":

  https://people.debian.org/~lumin/debian-dl.html

The topics in the document is associated to ~90% of my debian
activities. Here is the outline of the documentation, afterall
most people won't really read the lengthy texts:

== BEGIN OUTLINE ===

1. Deep Neural Network

  A brief and not quite mathematical explanation on what
  deep neural network is and how it works. This section
  also mentions the core components of a neural network
  implementation.

2. Deep Learning Framework

  Relation between DL framework and BLAS.
  Performance is a big issue. 

  2.1 SIMD

(1) Bump ISA Baseline for the whole system (SIMDebian)
(2) Build software locally (DUPR, Gentoo)
(3) GCC's FMV feature
(4) ld.so's "Hardware capability" feature

  2.2 Hardware Acceleration

(1) Nvidia CUDA. It is the dominating solution provider.
But its incooperative product license makes
everything boring in terms of volunteered work.
(2) AMD's fully-opensource counterpart ROCm/HIP. not
quite mature.

  2.3 Third-party software distributors

Anaconda. Not restricted by incooperative non-free
licenses. Has its own advantages.

  2.4 Deep learning framework implementations

Taxonomy: first generation, second generation.

First generation: features static graph, including
  Caffe, Theano, Torch(Lua), TensorFlow(v1)

Second generation: features dynamic graph and automatic
  differentiation, including PyTorch, TensorFlow (v2,
  or eager-execution mode).

Some practical packaging issues related to them.

Julia community also tried to provide some deep learning
frameworks.

3. Deep learning applications

  3.1 Data & pre-trained neural networks

you guys already know what I'm going to talk about in
this section.

  3.2 Software freedom and DFSG

ditto.

  3.3 Neural network reproducibility

todo (can be partially found in ML-Policy)

  3.4 Neural network releases and security

todo. Deep neural networks can be vulnerable, actually.
There is not a "CVE" for deep learning. (it's not time)

4. Ethics

  ...

5. Preliminary conclutions

  ...

== END OUTLINE ===

I didn't carefully polish section 3 because it fully overlaps
with the ML-Policy motivation. I still need some time to
sync the document and ML-Policy.

The link to the HTML document will always available as long
as people.d.o keeps online. My writing style is not suitable
for a wiki page.

[1] https://salsa.debian.org/lumin/people.d.o-lumin
Source code is available here. The source code of the
html files are the manually written HTML themselves.



Accepted breezy-debian 2.8.31 (source) into unstable

2019-10-13 Thread Jelmer Vernooij
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 13 Oct 2019 13:03:27 +
Source: breezy-debian
Architecture: source
Version: 2.8.31
Distribution: unstable
Urgency: medium
Maintainer: Debian Bazaar Maintainers 
Changed-By: Jelmer Vernooij 
Changes:
 breezy-debian (2.8.31) unstable; urgency=medium
 .
   * Fix compatibility with Breezy 3.1.
Checksums-Sha1:
 85ea78da4913c18291aaeffd6bde60949a61cc60 2152 breezy-debian_2.8.31.dsc
 b002edf6e3d9815f8a71e093060b1097dc829bc0 155156 breezy-debian_2.8.31.tar.xz
 e05a040583eb66435739d698261e93085228d39c 9699 
breezy-debian_2.8.31_amd64.buildinfo
Checksums-Sha256:
 b076467744ff767c54a9eeaf65ce27739ea1b6746da03b36a5caf2f214bf2d4c 2152 
breezy-debian_2.8.31.dsc
 d9b0d5f9eb99ec43c76b4555b9707dfc0042da90c6362b27e9c9c2a49032c908 155156 
breezy-debian_2.8.31.tar.xz
 748cea80a412a5bee920f0d24ced172523b2117e5a8abce570458881a9be2c67 9699 
breezy-debian_2.8.31_amd64.buildinfo
Files:
 2d9a43705867ba2aa16cc08b033841d5 2152 vcs optional breezy-debian_2.8.31.dsc
 68799da559180c9366ff0a9bf410ea4e 155156 vcs optional 
breezy-debian_2.8.31.tar.xz
 240903463bc894b385c36310ed0e8fac 9699 vcs optional 
breezy-debian_2.8.31_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEsjhixBXWVlpOhsvXV5wWDUyeI+gFAl2jITMACgkQV5wWDUye
I+jNgA//aQyLZHcVUs2n0+gWpmnMRLFmeGOKQRbmWpqlBFEQtvpL30j5Pp5YUhRg
DY7n3CGj69kJ+A183wXuwhRBZHAvQZL/NrK5bm0LywB2dOnNLZ5g4KmuXJ29y6K/
HotCLuP0aboLktH8ZwD23oJQCnRmZ5dPrX78jI3AjkT0MtEkeSxcs9xHC2bP6KOG
YxvKeRNBXhh5RDAVi0dNpDQ8cB3t9NpTYDszdlBM0FouB9ysK191rAHmS6yXcaa9
BAu1TPp7EXXFz7IxmNu3iOKiCs68o++WTMlidaRk+uNtmBLoSqg56YpKlBN5C7YB
SHntSZ/Nu9Z+GM4V8m93GhJeVavL/14eO2qgtvF4t1FijB5IOk5iyL0QNHz5wUg+
9rrgd5IdlNTY+UR5TDWtTflfHULIPFJsaeFNmNTWll0hNKQRc08Ze7GlCIJt3T5j
m48BdsceQDKYsD8wOBYzzN2VffObOgpqSEpCm+XwlSa8Ln9zuvtu0rp5z2fDSr05
CJn5KaEhJD2eOPTrt3JVRlwHev3OXZnWFPFimfiEztYXertGstCcSGJTlBbcjLTE
Xr7pEjB0XsaDsNwzVezfQUF8sWNmNzIMCxM4yovCQv7k1Ee+95CYUFTfX9LwBBiz
ahKSaZTkGW5tlAEmeNrg0JnDPqtUqDUER6Y0ZnGNJb4f8gUl5Nw=
=Q8P6
-END PGP SIGNATURE-



Accepted debian-edu-config 2.11.5 (source) into unstable

2019-10-13 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 13 Oct 2019 13:06:16 +0200
Source: debian-edu-config
Architecture: source
Version: 2.11.5
Distribution: unstable
Urgency: medium
Maintainer: Debian Edu Developers 
Changed-By: Holger Levsen 
Changes:
 debian-edu-config (2.11.5) unstable; urgency=medium
 .
   [ Wolfgang Schweer ]
   * share/debian-edu-config/passwords_stub.dat:
 - adjust after replacing icinga with icinga2 and icinga2-classicui.
   * Improve usage information and comments:
 - ldap-tools/debian-edu-ldap-install
 - share/debian-edu-config/tools/edu-ldap-from-scratch
Checksums-Sha1:
 05418018b5bbf9dbd539ca5653649681c6f1b141 1914 debian-edu-config_2.11.5.dsc
 321cffd3f7a9c5ce7a96c42139d78879f8e8b6d6 340476 debian-edu-config_2.11.5.tar.xz
 8075bbf5307b122d3b4a99f7ace5ebad68eb54b6 5276 
debian-edu-config_2.11.5_source.buildinfo
Checksums-Sha256:
 399b415e003d357f1d7be5609a918e031f05765cb4a4f2eac2da16323d8afe00 1914 
debian-edu-config_2.11.5.dsc
 9238daa7d809cf52b4e9dea57d0077de3a81729e6f53ddcf54ec0c84a8d644bb 340476 
debian-edu-config_2.11.5.tar.xz
 db95093cff75f0016b5470d2f3c31576b49db56cdf14a9f2399f9cbbc15cf16b 5276 
debian-edu-config_2.11.5_source.buildinfo
Files:
 7af3da922fe8d407c66324b31f9168db 1914 misc optional 
debian-edu-config_2.11.5.dsc
 b6af03eb989e3bfd0cd8b054b7189d46 340476 misc optional 
debian-edu-config_2.11.5.tar.xz
 833afb83f8b248102a72f99b0457fb0f 5276 misc optional 
debian-edu-config_2.11.5_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl2jCk8ACgkQCRq4Vgaa
qhx0dg/9Fn5oAPpyp/5XQvc7D70C/FSiKZC9QNYfXYQsQCJz7d9wU6hPZ5C4gDdU
A6ANEy5XJAcxdPiRYLLB/mZIStbf2J/8FrKQTTAaFUH+JBhSu8vektiIvqrrfMgd
Ih264jP851PHYTDde08s7oPj4glP/hNakrRuYHIWTeGdaKTya3Dv4TGvpfzKuDyO
AFOGcGe7cv3IZqXwbDdvrLfjTVYiTPdE0I3pQxB4ufMbmYvv0MnEzBNTQqdrJiyu
NCQf2RXTK3ko5YrGPun+FgnLdyVEQwljz3LrHFE3IGTEixKWw+GCQu2OaZbOKwLq
xQ81dfZTCbfkpYCta7SDT3gPl1vXj0m1kFLuTu5Y9Qm1cAJa80ONB7K8yEGWGtl9
WO1PMk4Nk7P8HNsiH+IHov+4cGWi8wZCWC79Ip8Fz0ySFcLwpsVXZOrZgn4I6edl
wlY6FncH07yVGfJclUYJkQUA8R2jVqybX1TvjAacKybkwiejyBrRr/i2y1A8im8L
KCAkPBUnQEjaSViXCvtwofMm8OVxLOj5vjrDEjF2rBlWsuLH9JFxFnZDs3q5S60p
7MMdYBBhD3Ew7BzRBAZ4cFwvnQxp0kwjFdHsdZl1Mr43cXnzII4LQci1amzk7r/D
EB+mN2vg5J/kfLmbrT/EVzfmcPLKTW1T7z0/QIo9ERfAA7oA2Uo=
=iFP4
-END PGP SIGNATURE-



Accepted debian-edu 2.11.4 (source) into unstable

2019-10-12 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 12 Oct 2019 15:17:01 +0200
Source: debian-edu
Architecture: source
Version: 2.11.4
Distribution: unstable
Urgency: medium
Maintainer: Debian Edu Developers 
Changed-By: Holger Levsen 
Changes:
 debian-edu (2.11.4) unstable; urgency=medium
 .
   [ Wolfgang Schweer ]
   * tasks/main-server: Add icinga2-classicui as icinga2 web frontend.
   * debian/control: Update after running 'make dist'.
Checksums-Sha1:
 2ac1c5facf7a998a794a965098822bf26c3af729 4768 debian-edu_2.11.4.dsc
 01ffca75f7c4e76dc935db7926d6e860c3e18f87 119072 debian-edu_2.11.4.tar.xz
 40a45911691834977fcffb24ffd6cf314778232a 6741 
debian-edu_2.11.4_source.buildinfo
Checksums-Sha256:
 2d75dbcdc2794c3c149779c9087020ec9118bd8f3146192e5ba9de43129c3437 4768 
debian-edu_2.11.4.dsc
 5721d30405fab6b194928d4fe90b4f275d5096232cb22dd5c021952727256952 119072 
debian-edu_2.11.4.tar.xz
 540361ca08936eb57ccd504dce1c2ece00ef3a914b20efdbbdb8f994ad5553d9 6741 
debian-edu_2.11.4_source.buildinfo
Files:
 e623564fd54e2edfdd7f5142dae05e86 4768 metapackages optional 
debian-edu_2.11.4.dsc
 476aa64d343336418bb4a01daadec988 119072 metapackages optional 
debian-edu_2.11.4.tar.xz
 8cb9b6247efe1b46926d0e6eea0c548b 6741 metapackages optional 
debian-edu_2.11.4_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl2h0ooACgkQCRq4Vgaa
qhzEaBAAp7u64jiCfJuCqL4gNxGypIPGUWpZ26OFB6AXKQOI2JjXVzUhq63dfRUZ
GpLBYGCDW26YEe0U5Jqu5E35DEaWw5X37xecm/cJf/8wHh7ctf9AV6bZQOKVBxJy
ynIpe4b7AmsGUOXXsqxe6+IDbJ+hYvFOnU286kxNi4clnDA8YPxi4ZrhSWwft/pb
ngGtsCzOpY55La8FOoHGBVeQxcxWJJPN7Kew4ZSB5D2kDAEytK2pKlmi6kw2+Htt
djyCvrK8SrL2rBVh4GkpnGnxN2E9E9Mu1a6t8xwCyX5rlE5bZ/0HMmKRNit1o9W5
215VNrATzqj0snS9OuNoN8hqyrWD5KXPYDGc84kPLeFWNnUvAz95NgCP5ZP+Hhuo
TTKBl3Na3ICYHuuGOIxLfdVxzkQmTf4OaoplLmnOUcijSJAi1kWJonfT22D0oLtC
DGd9rbyZ6YAv7Hysq2p0crxHZV+d70JRJQ3aVggySHuDMCT4fl/8W8qOd6PCCC8B
BZ/rN2Pzo2N5fvlzqpvsBWTpL1Cmd0MhOmlm1pWJfzLrWu3Cb+UT+mojI0QZBRnB
waQ/Qb6/3JyLfGPjWEG22rDijzea0RuYG9ePtJP00RDq72CfzuEwaIeJW9UsrO5y
BI1DiNwd+4EMrwFu5zSUTCE7j6OHmOuVWtEygHMB9AwDfphcdsc=
=3u1h
-END PGP SIGNATURE-



Accepted nmon 16m+debian-1 (source) into unstable

2019-10-12 Thread Salvatore Bonaccorso
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 12 Oct 2019 14:42:54 +0200
Source: nmon
Architecture: source
Version: 16m+debian-1
Distribution: unstable
Urgency: medium
Maintainer: Salvatore Bonaccorso 
Changed-By: Salvatore Bonaccorso 
Changes:
 nmon (16m+debian-1) unstable; urgency=medium
 .
   * New upstream version 16m+debian
   * debian/rules: Update filename to compile (sync with new upstream)
   * Declare compliance with Debian policy 4.4.1
Checksums-Sha1: 
 deca2f07210c7abe7af9c6d4beb8f340d2b2d600 1982 nmon_16m+debian-1.dsc
 4063649643f0d9f26aba7aec150027b07f32497c 64398 nmon_16m+debian.orig.tar.gz
 dfff1ffd476f46dce02cd9b3bc8582abe53beb18 4156 nmon_16m+debian-1.debian.tar.xz
Checksums-Sha256: 
 d866b3e1e3c99dfa7f3019b3dc65ad4cd4f6e9ad88e5d2dcec187f98ecfae4d6 1982 
nmon_16m+debian-1.dsc
 eed869b4b8e7f94f5d7882f10e157eaa5268cce50ec0c2e24e34dd3bd857e991 64398 
nmon_16m+debian.orig.tar.gz
 6400d83383516a06ad118af6d5514e3711b95021fe36575ac8d79571e31a70be 4156 
nmon_16m+debian-1.debian.tar.xz
Files: 
 0869549bd37c4764391162da01d8d278 1982 utils optional nmon_16m+debian-1.dsc
 0ea456b1dea68561ea2e3063ea893d2d 64398 utils optional 
nmon_16m+debian.orig.tar.gz
 25184e59e80e2b817135ae8131bb7a6b 4156 utils optional 
nmon_16m+debian-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQKmBAEBCgCQFiEERkRAmAjBceBVMd3uBUy48xNDz0QFAl2hyulfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2
NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQSHGNhcm5pbEBk
ZWJpYW4ub3JnAAoJEAVMuPMTQ89Et9wP/2CIJviSagugLbsLWfvHgd79mbbqsGPA
bSEod+s8GS+OCM924LFiS15/DLEZz7Y2FXJBynad61kFEMzo+F4unHptD/KFyD6M
jSp/3b/W/qf6uwzMT9BgVvaNp+rdVOyH0hPbaDPU2B+sItndccJlB2sbGVqBteuF
9mQgr+ShEozEaybks3HwVEjeT80ibmf9uivHsnDN5N1kxUt2C9NPkR7eCFFAkj4R
szo3514jUrJKJktRfFM9mzSoNifMXfPmMhqE2+vxFzpkBnHvIWNsNl9ny7B11Uf6
ldOOzqSzm5O6/P+1AOPxGh/l9gMw54i+VNkdyjgs3BezTCOjSxQJOws5ssyKl8SQ
GiDOSC9UOOlRVQefpxRNBvGj9C9d2hhGeqFHhhE//0mLwGkIHl/Ejvim/QoyGTar
XYGn4e2sxEbChep8o1RylINpgFpIakmDcx2+IQfWeWnzSJu3Bx4dwV2Ls3UJHhot
YeQSEA0KGDUqmgJa7qAxbKGORuzJilGe2of9NZtdZu5HEzjUQL8waYqK0/7A53Un
I8+miP3noiUiZnhLlI9dQxKJaJutn6o4znrUqIa49DXzIxKrhIHfhPq1B07XN6jK
KBfGPC71Wr5N4gcaTeXLLrbl5tTeeJM+C3mTIQjP7wnIz0pycPdxjblEvDp0LMtT
irmgkjw+8kRR
=r5/4
-END PGP SIGNATURE-



Accepted maven-debian-helper 2.4 (source) into unstable

2019-10-10 Thread Emmanuel Bourg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 10 Oct 2019 09:50:04 +0200
Source: maven-debian-helper
Architecture: source
Version: 2.4
Distribution: unstable
Urgency: medium
Maintainer: Debian Java Maintainers 

Changed-By: Emmanuel Bourg 
Changes:
 maven-debian-helper (2.4) unstable; urgency=medium
 .
   * mh_make:
 - The generated control file now specifies Standards-Version: 4.4.1
 - The generated control file now depends on debhelper-compat instead of
   debhelper, and the debian/compat file is no longer generated
 - The generated debian/watch files now uses the version 4
 - No longer support generating Ant based packages
 - No longer generate the javadoc by default
   * Added ossindex-maven-plugin to the ignored plugins
   * Standards-Version updated to 4.4.1
   * Switch to debhelper level 12
Checksums-Sha1:
 cff2cb2e18760ca12f8b628636311dfae01ad5a2 2044 maven-debian-helper_2.4.dsc
 1f4bcd0d363de4a9415f410a43aaf179ce0fc577 87080 maven-debian-helper_2.4.tar.xz
 67596e0cad7e2a443611200cd4f19e7bcf86eac9 12059 
maven-debian-helper_2.4_source.buildinfo
Checksums-Sha256:
 e54fde6b2d929154fc5bb340d2efd117813968008ce97d5bfcfd33b4229a38a4 2044 
maven-debian-helper_2.4.dsc
 0b5d83029f1ad9ce4c49f17add53b9c39cc2724f021b9954859fe55e7840b3a1 87080 
maven-debian-helper_2.4.tar.xz
 5e210536ba0fd49d6b8fdfc6683b8d170eba7356c479a14a5b265500df3ca0c5 12059 
maven-debian-helper_2.4_source.buildinfo
Files:
 b0f61d35f13978a08b28bce882d139c4 2044 java optional maven-debian-helper_2.4.dsc
 eef7f9728ee0ea2b9b0d9a1c146aeb81 87080 java optional 
maven-debian-helper_2.4.tar.xz
 325279fb207ee5ee247559e9feb7b337 12059 java optional 
maven-debian-helper_2.4_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEuM5N4hCA3PkD4WxA9RPEGeS50KwFAl2e420SHGVib3VyZ0Bh
cGFjaGUub3JnAAoJEPUTxBnkudCsCKcP/iwmhGZer+cqcHiMR9IVGq3Xfs8wxqm5
oAd3XpJkmhTnIELF3mBBkB71+DZsdZWuFAuQ4fwdjODc7k89ZXuenJ1mXzdu0lTD
DSoxn5QswNzFTRni5xRaQ0oB+4HYSXsoZLTM6qUWSz7GccNx3ZRnrYqs0ofgVV2e
Gqn+7B0qHB5bu9mtRR7Cd5yCtpL51U7+4EdrHUCeL8FGksGVFLXvG5y1NTgrZXtW
OZfqETrITn7TK7GyF38eBZ032J/fUIWOUGSLNL+hbDXP1Cb0n+QLNqDqfjEFnZo0
sMvmgShuYC8ZRmRCw6WLCTLf3IM/g4KL7LiMtCFvLETJhk7Rp/NGYSLZ8KKRxlUH
pY9+/pVxy92XHiI/oZ+A1GcFU41ZycJ2F6UeiQC3HAyxnrK3L9zyV7w3N6zJDcdJ
U5Bcnlbv2LW4CtKJDRFcuhVeo0htgOhw8wo8aXqUBrgaJmln9t8ThxFe+J0w2CS1
feOCN96H4qhUlebfEtdU38F38QM0YTc2RNgcfIuh3UrxIYZNGHs9dBRAVlE7oxuk
tu8HgnNeHmlqpf7dimTOmSi/jxk5oSEv6JWfJjvxSeY4cELTpwqwQB11aK2cVZEt
7YPBUXZyN5ddiLiBm1GAlxKtSGY6BUJwZ50gi4rDr+FsrJyRlTvmixBoa7X6204B
FdgD1XnfVkZX
=XdQD
-END PGP SIGNATURE-



Accepted debian-edu-config 2.11.4 (source) into unstable

2019-10-08 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 08 Oct 2019 14:47:06 +0200
Source: debian-edu-config
Architecture: source
Version: 2.11.4
Distribution: unstable
Urgency: medium
Maintainer: Debian Edu Developers 
Changed-By: Holger Levsen 
Changes:
 debian-edu-config (2.11.4) unstable; urgency=medium
 .
   [ Wolfgang Schweer ]
   * www/index* and www/*.po:
 - Adjust files after replacing icinga with icinga2 and icinga2-classicui.
 .
   [ Holger Levsen ]
   * etc/ltsp/ltsp-build-client.conf: target bullseye, not buster.
   * share/debian-edu-config/tools/debian-edu-bless: remove remaining
 references to EDUSUITE which were forgotten in a code cleanup in
 commit c6ef9d69 in 2016.
   * README: update reference to point to bullseye, not buster.
   * cf.workarounds: drop workaround for #922718 as the fixed xfce4-session
 package has made it into bullseye.
   * cf3/cf.squid: drop workaround for stretch -> buster upgrades as skipping a
 release when upgrading is not supported.
   * Drop share/debian-edu-config/tools/password-fix-squeeze-r0 for the same
 reason.
   * Drop stuff commented out in 2012 in ldap-bootstrap/root.ldif.
   * Drop (some) code for upgrades from before buster in
     debian/debian-edu-config.postinst and
     debian/debian-edu-config.maintscript.
Checksums-Sha1:
 ef6390778c423fdac26a50f5621b89a6a12bc4b9 1914 debian-edu-config_2.11.4.dsc
 10d1ccff2ff7731198d79abfc811dc91c110c6bb 341008 debian-edu-config_2.11.4.tar.xz
 7f79248442e6ce08664d6cb475665eeb3d30addd 5327 
debian-edu-config_2.11.4_source.buildinfo
Checksums-Sha256:
 b04f39cd780a6c2b928eb23a297baba508a462ddfc65531d273d8d5fa945cce7 1914 
debian-edu-config_2.11.4.dsc
 c1c09201bd421c0b78fef84bebe5f2717618c8610610a58c38fc63581021940c 341008 
debian-edu-config_2.11.4.tar.xz
 61a93257091e8755da275733892eb0a8224f15c5b938f0a203cc30132416fbd5 5327 
debian-edu-config_2.11.4_source.buildinfo
Files:
 a98f8721b9500e579db81e4e2d76b52b 1914 misc optional 
debian-edu-config_2.11.4.dsc
 147adb8ee9e61c78fd6817a6ba95fbed 341008 misc optional 
debian-edu-config_2.11.4.tar.xz
 3f634f564c9afd9e5959a9e44bc0fe03 5327 misc optional 
debian-edu-config_2.11.4_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl2chawACgkQCRq4Vgaa
qhwxrA/+MNHGAufi6vyNoDVA9fh1w4CbeY1aehANjb90cejyzU5aehEiyMJBHwLl
S0tjB/lYlPmWJnxHwrNqGaBvXKdQKIBMxFM4/7MWlyKQ14jcecUSFQ9gcFekGXJI
3OM3UPJJyWKVrruncba7cuvkk+38s4tam9UDhI28Uc2E2hPUfmVc/mt9ioCZktja
rCPEk88tp3h+gaidKa62ml7p2f+dEHD15eh7tJbAdAu1h+w2F1wrVa2PxolNrXER
mXJpX5heBML8+gMmb4bkJksn5lafmH5K18rc7l8mW2aMTnDmt7CNMWNXzB3Q5Zx0
jlVFkaTocU4pe9voP0dighX1tyW2qwmPDHuC2nfXI6hqj7BTA6z6QpkLbVzfY1Cf
y9J5ivoANrhe/Rz5SV3NwxQO7gXCuFDV0waCOGbkBIOprXfJdcg6s4BccV6ZQaTH
D/WTOOa8XiHkLmo9/DIYoS34tQd8I7yTRVp0j0Mrrdun02qLoo97qiuKtl4f+/Hv
35GiqHxKgTSn4/G2Bdl8bfRb5G0MzA9yIAaipGwMpgVWnvZxV4mYtjQs4ukN+Rtt
m24RxnL8Uv80xcC12/DhMFoy2Mo1/jIyEiQAep+IzZxTsufJPfOgu19swDJklg8W
AHTkrO1MZtcdjcD+tytn35vA0s+yg5qaM3I6XZ6tS15J82xrR00=
=2TLU
-END PGP SIGNATURE-



Accepted debian-edu-install 2.11.2 (source) into unstable

2019-10-08 Thread Holger Levsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 08 Oct 2019 11:28:45 +0200
Source: debian-edu-install
Architecture: source
Version: 2.11.2
Distribution: unstable
Urgency: medium
Maintainer: Debian Edu Developers 
Changed-By: Holger Levsen 
Changes:
 debian-edu-install (2.11.2) unstable; urgency=medium
 .
   [ Wolfgang Schweer ]
   * preseed-values/defaults.main-server:
 - Adjust preseeding after replacing icinga with icinga2 and
   icinga2-classicui (cgi is enabled by default).
 .
   [ Holger Levsen ]
   * d/control:
 - bump standards version to 4.4.1, no changes needed.
Checksums-Sha1:
 4b8976cafd4e61622c3addc7760c37efe6167d21 1991 debian-edu-install_2.11.2.dsc
 ea2084408e4cfab2da14f686c3986a33195af361 137740 
debian-edu-install_2.11.2.tar.xz
 b66263df1bcf5f3af1387ba8c4952e6dc7e7 5380 
debian-edu-install_2.11.2_source.buildinfo
Checksums-Sha256:
 bfa320d158d17a71484ca84502e01c3aa0b500aa2d8ebcceba731c01c8f5e0a2 1991 
debian-edu-install_2.11.2.dsc
 c4f7e67c97b4103629034451e24589a37a7ae70132f37f0f8c08602b64612d91 137740 
debian-edu-install_2.11.2.tar.xz
 c039f138a0a9c6b93f9beb0a13f1c2f52bf69df4a7e9bb325402af2650a14fd3 5380 
debian-edu-install_2.11.2_source.buildinfo
Files:
 3b2c7905cdb40754d9bf402bf0252080 1991 misc optional 
debian-edu-install_2.11.2.dsc
 f7357f9f671fc5d029d18045d0af7762 137740 misc optional 
debian-edu-install_2.11.2.tar.xz
 1d5046ef5bb54b7560e7a0f287b58812 5380 misc optional 
debian-edu-install_2.11.2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAl2cWakACgkQCRq4Vgaa
qhyqtQ/+ND5mWXFCOicn/bOzSEnAJuMWJJ0ymzgTq3QRHqGAks1rbhW95dOeJWB/
ZGv7PrZTsxbaSxrQvMjHpMYEj8BTFfxa+wBs9MAUu+yFAWwjtjND9CQ3+W4U4alV
su3zlQ/mE5q4RdNm7DxqMSizUjST2iRcHCA64zhH0m8DANV+U2VcNXOQ0nAumH4t
2iHm18Qqc6SeHxnDa8eBPmLjRtHTBdOkHe5jdrqXg9/HJibL1ulMJzmnWm8KD9PS
2UC5kBPUY3qMqJNg80B2p0ZFHImmU99LnPdv5OH1YSvKFz6BivOgZS2+JtoGwu2H
H15q98mhemdaWU4yBB87IUZ7UldPOc6XIq404D9rcRswoohSPy7+47qWbYS1rnSb
vIOhDS8KjALRPjxn/WBM0PZKOxTAR6kCya2PW7qORYaysO/rJDDxzWww9nk3jJtu
gqaq4bf6gNXKM1hPI1JRSfYtYvS14sOtKc1i1sJgqBpsc/WHV1QmlbpfI+PcwgoO
yrI+ZkwgY8WzlRSHxund0sI5ESdXo416SutK24A+UV2M7XcbuY1qVZkxnsrUMTo3
VavYiMUe8lkB/O0D1oQSo3V2hqxh72L8NKRii/7z+Ah6AXF9k2ZmDSNU3Q4cvCrt
cj5d/nfiiwT1Y29ZmHDePFn2FFgh0n0uHk+wxnbCbt+TDgqjAL8=
=hcwy
-END PGP SIGNATURE-



InstallBootstrap (was: Re: Debian and our frenemies of containers and userland repos)

2019-10-08 Thread Johannes Schauer
Hi,

Quoting Jonas Smedegaard (2019-10-08 10:30:45)
> Quoting Paul Wise (2019-10-08 02:35:14)
> > On Mon, 2019-10-07 at 11:29 +0100, Simon McVittie wrote:
> > > I think "re-bootstrap, don't upgrade" is an equally good principle for
> > > autopkgtest and sbuild? Both will be equally susceptible to accumulating
> > > cruft during upgrades that wouldn't have been there in a fresh 
> > > debootstrap,
> > > which is undesired if you want the invariant that you are 
> > > (building|testing)
> > > in "today's" minimal environment.
> > debootstrap uses a fair bit more time and resources than apt upgrade,
> > so I think that both are needed.
> This seems a good place to mention mmdebstrap as a speedier alternative to
> deboostrap.

while I certainly welcome use of my software, let me also use this opportunity
for a word of caution. One of the core reasons why I created mmdebstrap was to
create a proof-of-concept for the idea that it should at some point be possible
to create a chroot of Debian (or a derivative) without all the magic
instructions which currently live in debootstrap and cdebootstrap. Instead, all
necessary information should live in the packages themselves using the same
component-centric way of thinking we apply to other engineering decisions in
the distribution. An extended rationale can be found on the following wiki page
and in the bugs it links to in the first section:

https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap

But as of today, the problem is not solved. So that mmdebstrap works today (and
has been working in stable, testing and unstable for the past year) is
unfortunately more like happenstance than due to some ingenuity on the part of
mmdebstrap.

Thanks!

cheers, josch


signature.asc
Description: signature


Re: Debian and our frenemies of containers and userland repos

2019-10-08 Thread Jonas Smedegaard
Quoting Paul Wise (2019-10-08 02:35:14)
> On Mon, 2019-10-07 at 11:29 +0100, Simon McVittie wrote:
> 
> > I think "re-bootstrap, don't upgrade" is an equally good principle for
> > autopkgtest and sbuild? Both will be equally susceptible to accumulating
> > cruft during upgrades that wouldn't have been there in a fresh debootstrap,
> > which is undesired if you want the invariant that you are (building|testing)
> > in "today's" minimal environment.
> 
> debootstrap uses a fair bit more time and resources than apt upgrade,
> so I think that both are needed.

This seems a good place to mention mmdebstrap as a speedier alternative 
to deboostrap.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


"adt-virt-*" abstraction (was Re: Debian and our frenemies of containers and userland repos)

2019-10-08 Thread Holger Levsen
fwiw, src:piuparts also includes a (now) derived implementation of
"adt-virt-*"...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature


Re: Debian and our frenemies of containers and userland repos

2019-10-07 Thread Paul Wise
On Mon, 2019-10-07 at 11:29 +0100, Simon McVittie wrote:

> I think "re-bootstrap, don't upgrade" is an equally good principle for
> autopkgtest and sbuild? Both will be equally susceptible to accumulating
> cruft during upgrades that wouldn't have been there in a fresh debootstrap,
> which is undesired if you want the invariant that you are (building|testing)
> in "today's" minimal environment.

debootstrap uses a fair bit more time and resources than apt upgrade,
so I think that both are needed.

I don't want to be rebuilding sbuild/pbuilder chroots before each
package build, but an apt update and upgrade before each build starts
installing build-dependencies is reasonable.

At work we upgrade build containers interactively if needed, upgrade
them automatically daily and rebuild them from scratch weekly, this
feels like a reasonable compromise to me.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part


Accepted openstack-debian-images 1.37 (source) into unstable

2019-10-07 Thread Thomas Goirand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 05 Mar 2019 11:51:53 +0100
Source: openstack-debian-images
Architecture: source
Version: 1.37
Distribution: unstable
Urgency: medium
Maintainer: Debian OpenStack 
Changed-By: Thomas Goirand 
Changes:
 openstack-debian-images (1.37) unstable; urgency=medium
 .
   [ Thomas Goirand ]
   * Add vmnet option for non-bridge, non-vlan (ie: normal eth0) setup.
   * Add type=ovsbridge.
   * Remove euca2ools and aptitude from default.
   * Customize apt with nicer defaults.
   * Install lsb-release busybox-static and console-setup by default.
   * Set "lacp_rate=1 xmit_hash_policy=layer3+4" in /etc/modprobe.d/bonding.conf
 if we're using bonding (on top of already set "bonding mode=4").
   * Select deadline scheduler for all /dev/sdX drives (set using a udev rules
 file in /etc/network/interfaces/60-deadline-scheduler-to-all-sdx.rules).
   * Do not set console=ttySX if installing on a "qemu real hardware case".
   * Add support for raid1 setup on any pair of HDDs.
   * Add Octavia Amphora build script in the contrib folder.
   * Add || true when doing ovs-vsctl add-port, so that networking.service never
 fails because the port is already added in OVS.
   * Add an option to use only OVS interfaces.
   * Add an option for --tty-autologin.
 .
   [ Ondřej Nový ]
   * Use debhelper-compat instead of debian/compat.
Checksums-Sha1:
 6e277fbfc647c276eb047cb218b9b111fe1d1780 1758 openstack-debian-images_1.37.dsc
 8b89d42b2ad3b6ebd65b85306b0ae39046a6f012 30192 
openstack-debian-images_1.37.tar.xz
 943c4b746531f9ab5f2777276c0632ec8799df38 5522 
openstack-debian-images_1.37_amd64.buildinfo
Checksums-Sha256:
 2e619d98de3cdb6040e93ed48733451f6fde8f7d62e3942a6820cf488238280d 1758 
openstack-debian-images_1.37.dsc
 e4d1a63b9195d8d04ae8759fc9174a0eb47ad7f4d18622b3e6a50db2db5393b2 30192 
openstack-debian-images_1.37.tar.xz
 0fef63ca2017f300738ebc10576a55dac0d4c641fac4daaf12e7634a8ed96b25 5522 
openstack-debian-images_1.37_amd64.buildinfo
Files:
 bcc70dc6bdc0c9cd02da74675b336bce 1758 web optional 
openstack-debian-images_1.37.dsc
 33b33a416b34176cb558525eaa622548 30192 web optional 
openstack-debian-images_1.37.tar.xz
 373437bb2d23d05aff6bf95bf2105247 5522 web optional 
openstack-debian-images_1.37_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEoLGp81CJVhMOekJc1BatFaxrQ/4FAl2bLVMACgkQ1BatFaxr
Q/7Icw//R0uVDDQzGg5Dc/DA69/n7DPdL7JneaJhWalABPWk/9wCRDUtHkoqn6+N
eVS8A2aIh6e8tvb7e7x8GkoMSKM9+tfDUvYoe2LkEGiD4yWkVZfl1hlcDH68KOZQ
EQwG2kvnNUF9T5s/gkEkFqfZrs4o+3oA6D4nmUdj3zN+6mAjZetWxdh339He2rNC
QxpFfI0Q1HMSAE5DWFFoXCdengFdF8tgvwhJiGwjYV4EELxRfVrkBvRvaTpYw9q/
XugaEHPGrqYJZ0BuNiJ0Rxtjm2ehuX4PjLesSnzztfcV+fnmfV+vg4nqDyfVSh+x
jGP8JZtBKtpy6bda40Z6HF9Nod2rgVJk+3y+XDiPf+JdsQv7cCihDCvgy1ta/jAq
rSVqVL7zBGcigUZELfbbviw4N/iUbDgHydGS2/t0/s5qyWUSv01P8dnVLnIAHBlh
xUI2rgQ4WhKD7BLxrngn637xp5S5s5/vPj/OpF4jUZPPM/wAFW+O8afsgWU+u1XZ
myRuy0siXBRUo1+qGAPpULdZtgVbyuG71El2frUPJn9vxKpp+q/+1qa7Sjs+BJCw
qE7t8e7U1Y8WvFZMHxSuqvfS/Hg2w82oVJf8QpwNGk//tgwMzfCJzvFdkGZxa+sw
hvzJiNuz4CMB1/e99MPNZqE9KykI1Uo5fPVWR6RiVadz21crLZs=
=9Gn3
-END PGP SIGNATURE-



  1   2   3   4   5   6   7   8   9   10   >