Bug#851539: Stretch RC1 netinst installer prompts for additional CDs

2017-01-15 Thread Josh Triplett
On Mon, Jan 16, 2017 at 01:13:13AM +, Steve McIntyre wrote:
> On Sun, Jan 15, 2017 at 04:53:26PM -0800, Josh Triplett wrote:
> >Package: installation-reports
> >Severity: normal
> >
> >I tried doing an install with a Stretch RC1 netinst CD.  Worked fine,
> >except that later in the install, right before asking about an apt
> >mirror, the installer asked about scaning additional CDs.  Previous
> >versions of the netinst installer haven't asked that question; normally
> >only the full-CD installers ask that.
> 
> This is a deliberate change, yes. It makes the firmware netinsts more
> useful now, for example...

I thought that firmware had a separate prompting mechanism, triggered by
the detection of missing firmware?  If the installer notices missing
firmware, it prompts for separate firmware media.

- Josh Triplett



cdebconf_0.220_i386.changes ACCEPTED into unstable

2017-01-15 Thread Debian FTP Masters


Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 16 Jan 2017 06:47:22 +0100
Source: cdebconf
Binary: cdebconf cdebconf-gtk libdebconfclient0 libdebconfclient0-dev 
cdebconf-udeb cdebconf-priority libdebconfclient0-udeb cdebconf-text-udeb 
cdebconf-newt-udeb cdebconf-gtk-udeb
Architecture: source i386 all
Version: 0.220
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 cdebconf   - Debian Configuration Management System (C-implementation)
 cdebconf-gtk - Gtk+ frontend for Debian Configuration Management System
 cdebconf-gtk-udeb - Gtk+ frontend for Debian Configuration Management System 
(udeb)
 cdebconf-newt-udeb - Newt frontend for Debian Configuration Management System 
(udeb)
 cdebconf-priority - Change debconf priority (udeb)
 cdebconf-text-udeb - Plain text frontend for Debian Configuration Management 
System (udeb)
 cdebconf-udeb - Debian Configuration Management System (C-implementation) 
(udeb)
 libdebconfclient0 - Debian Configuration Management System (C-implementation 
library)
 libdebconfclient0-dev - Development files for cdebconf
 libdebconfclient0-udeb - Debian Configuration Management System 
(C-implementation) (udeb)
Changes:
 cdebconf (0.220) unstable; urgency=medium
 .
   [ Updated translations ]
   * Bulgarian (bg.po) by Damyan Ivanov
Checksums-Sha1:
 aec7e5104d5982a6ae70a15a93ee5825199957b5 2662 cdebconf_0.220.dsc
 d011d2d31d27eebfddf1e26157c07c3414e61970 272180 cdebconf_0.220.tar.xz
 82d437c1b06b8ed2d9d6d6f66269adca278c1370 229694 cdebconf-dbgsym_0.220_i386.deb
 5bf9559ab0e4e67078865d0a6a8efbde2a506f9d 94802 
cdebconf-gtk-dbgsym_0.220_i386.deb
 83838f651610b6b55f748fec131b3bc20f74 32126 
cdebconf-gtk-udeb_0.220_i386.udeb
 15ca8683ef5ac60eb3eee8c106f9783284412fa2 75556 cdebconf-gtk_0.220_i386.deb
 2aced1de43a02a5b9e6c88814e697c23a04b5740 21340 
cdebconf-newt-udeb_0.220_i386.udeb
 f0ae6138bf62e3a5b46a530a1f06271dbbba38d2 3152 cdebconf-priority_0.220_all.udeb
 1002cff01dd44b20af07d229a2e0e4051b183a51 25100 
cdebconf-text-udeb_0.220_i386.udeb
 022d7e528c16843906d048439a6624b5f216f483 82100 cdebconf-udeb_0.220_i386.udeb
 88029ad8301ee5b996d3dec35107665c79c70e44 12767 cdebconf_0.220_i386.buildinfo
 52a90d4ab715050f0030794b64b873df4d7c506f 183350 cdebconf_0.220_i386.deb
 d789ece0f6b56c454eb1d5515845b595eede0881 5462 
libdebconfclient0-dbgsym_0.220_i386.deb
 31bb378fa1ee4896c9377e7e1e150ca3599330c8 52208 
libdebconfclient0-dev_0.220_i386.deb
 c50161764a9892eb980281e13ee1ec580b5efa0b 3294 
libdebconfclient0-udeb_0.220_i386.udeb
 2544bc8c48c13304711a0ae368417032378791bd 47760 libdebconfclient0_0.220_i386.deb
Checksums-Sha256:
 b1500394e7e44f0c6a8e476d9997593624ab9de6528ca83b4ab16aa7dc3c040f 2662 
cdebconf_0.220.dsc
 219f67671868d8ef06b39ae81b9ede335cfff104294ff9745cf7642bb7a336c1 272180 
cdebconf_0.220.tar.xz
 5e78be70d6394a7559c3fe92721de3cbed01490da5d07667eef8a57c9744370b 229694 
cdebconf-dbgsym_0.220_i386.deb
 53a5d908087aca57501ac0a190b332905e40036331ad71dfae9eb893df6f580a 94802 
cdebconf-gtk-dbgsym_0.220_i386.deb
 3c18c16e633410a1b4215520ea130e5807d2364d93812171d294e7bb3c6a5ecf 32126 
cdebconf-gtk-udeb_0.220_i386.udeb
 555b1427d7f765fa6b2f2d07b2814d46e07417cb2946e85f9236e4ef1d7844ed 75556 
cdebconf-gtk_0.220_i386.deb
 7dcb53be0aa42b408087c01fec94f71068ee8fd9c346fe46911d6c368c0b0a5f 21340 
cdebconf-newt-udeb_0.220_i386.udeb
 dc8b5b14ce5db2cdb63d0540a0d83b5fcfcc6d11eca7834c2736e31e8d8f9bb7 3152 
cdebconf-priority_0.220_all.udeb
 6e6af4cf660907842e756aa7e920771a33e97a0529e6a4c63aa9bb381a8e9730 25100 
cdebconf-text-udeb_0.220_i386.udeb
 6d7443ce5c1b6a44c4c8242ff61eb55ab91e660b7800c0a572de774c4b2029ff 82100 
cdebconf-udeb_0.220_i386.udeb
 36bd8169d5ae1f3e8623937caa5647206f6e27750d1821288c9a841c4ba9a4e1 12767 
cdebconf_0.220_i386.buildinfo
 2c8facaf9a06dee79faa0a78d51df6efabc366a1a88a310f03809f2362ffd609 183350 
cdebconf_0.220_i386.deb
 1017026805a34154d1ecfcb359ad2710338028acf6b4baacf186935b91b34252 5462 
libdebconfclient0-dbgsym_0.220_i386.deb
 270979eaa015ae29b83e6698bfdea0e67dec07d41984de93e4467a7d0cb56e56 52208 
libdebconfclient0-dev_0.220_i386.deb
 350b1f1b21d70affac50a2def034856454895734bafd663070704309ed530aa9 3294 
libdebconfclient0-udeb_0.220_i386.udeb
 8c4918a23aff3ec633f48e1f1c689bcfdfbe2dd42cf885d1eb7a878182886cb8 47760 
libdebconfclient0_0.220_i386.deb
Files:
 00292a546bab1c33162d617474819781 2662 utils optional cdebconf_0.220.dsc
 2941a40a22a61ddf5180f1db475866b5 272180 utils optional cdebconf_0.220.tar.xz
 3de644e73785873c4d82880ccfcb4dc9 229694 debug extra 
cdebconf-dbgsym_0.220_i386.deb
 4d6acbe328645c09b95d4068094abefe 94802 debug extra 
cdebconf-gtk-dbgsym_0.220_i386.deb
 5b012f45087b5ceda6a31cd0ebb81473 32126 debian-installer optional 
cdebconf-gtk-udeb_0.220_i386.udeb
 99621cc01172e5837eaafd6f98f8ec46 75556 admin extra cdebconf-gtk_0.220_i386.deb
 89a7cc3477664f37f77fb567e98f4932 21340 debian-installer optional 

hw-detect_1.121_i386.changes ACCEPTED into unstable

2017-01-15 Thread Debian FTP Masters


Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 16 Jan 2017 07:11:05 +0100
Source: hw-detect
Binary: hw-detect ethdetect disk-detect driver-injection-disk-detect archdetect
Architecture: source i386 all
Version: 1.121
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 archdetect - Hardware architecture detector (udeb)
 disk-detect - Detect disk drives (udeb)
 driver-injection-disk-detect - Detect OEM driver injection disks (udeb)
 ethdetect  - Detect network hardware and load kernel drivers for it (udeb)
 hw-detect  - Detect hardware and load kernel drivers for it (udeb)
Changes:
 hw-detect (1.121) unstable; urgency=medium
 .
   [ Cyril Brulebois ]
   * Update firmware-map as of 2017-01-15.
Checksums-Sha1:
 df6d3a1dda88132914103dc8b68c1db468aac3bf 2021 hw-detect_1.121.dsc
 71b1d7b37b10af176c15e1d07979b18cffeb25e4 187104 hw-detect_1.121.tar.xz
 50414944b58f856ca9014177320efbdd6794ed86 2688 archdetect_1.121_i386.udeb
 2235df5991d030e063e5bfeb4edc36b922df02ff 24304 disk-detect_1.121_i386.udeb
 ed6c92a9c2d0a9983fdf5fa179971004e298fb60 13496 
driver-injection-disk-detect_1.121_all.udeb
 fad2db1e40488206410b49212062199234b0c8cd 30936 ethdetect_1.121_all.udeb
 31c6b3939e46321edd98b4e3e2abea92b64f4469 5741 hw-detect_1.121_i386.buildinfo
 507a2c393b181bdb9e2714e296cf4bf2a19b3ab3 119874 hw-detect_1.121_i386.udeb
Checksums-Sha256:
 f0dee5cd830dafab807b28ecac66404566a3ff0678502f14fd8274e66591da0b 2021 
hw-detect_1.121.dsc
 f6c6f769b49cf427c8a7519de7a3585f9be70397fd5581e82d4a1ef4ec2f10b6 187104 
hw-detect_1.121.tar.xz
 1c956be8f9fcee98ca01e6f8f5ef05d95b49891b43a7c027c9c373518f7ab04c 2688 
archdetect_1.121_i386.udeb
 171d046a796700cd35e67cc8c7b50a997f6be336dcc1a84a48dc593127131b4f 24304 
disk-detect_1.121_i386.udeb
 e2bf054f8fd8e79b8e11d7338338b375354c1a1936aeb0cb5ceaba90a0521745 13496 
driver-injection-disk-detect_1.121_all.udeb
 50167c407cf5f18a21a6f62161b1ee7322819cbefc21d8418901169839643bf3 30936 
ethdetect_1.121_all.udeb
 2db2c14ca49d51c1973b8c70a30eea410396876beded99872e7e132776db69d3 5741 
hw-detect_1.121_i386.buildinfo
 e55566da7e8ce890627819f90c81ae4d1c20fc2ef44f3c06ec2fca340abcd9a1 119874 
hw-detect_1.121_i386.udeb
Files:
 d3cc576dd23b46042bb437658ad0cc88 2021 debian-installer standard 
hw-detect_1.121.dsc
 406e82682d19de3be8fb6688cae60c89 187104 debian-installer standard 
hw-detect_1.121.tar.xz
 48cd1459df4125d3c0f65fe2ad892537 2688 debian-installer standard 
archdetect_1.121_i386.udeb
 e47149c560f0c55d342672e209489507 24304 debian-installer optional 
disk-detect_1.121_i386.udeb
 f9cf078d6a6f91ceb5c5d14b23c1c8ba 13496 debian-installer optional 
driver-injection-disk-detect_1.121_all.udeb
 8ef990434bc6602553d96266846902b1 30936 debian-installer optional 
ethdetect_1.121_all.udeb
 85298ed3a7632baf96adb6da622f9902 5741 debian-installer standard 
hw-detect_1.121_i386.buildinfo
 7f270a1c355853b2e7bc2ea2411f9dc6 119874 debian-installer standard 
hw-detect_1.121_i386.udeb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJYfGdKAAoJEIcvcCxNbiWorSgP/j5egpixgAnzrg7iwk8js9uL
J2NoElGNwxe+YdNhvXCs0BiXCRHS5s5HuGCYQn4a+JPWdziWl6Afy4Ps1rvuMc2T
6DNk9YsiOwG0boIrWTMHtRAADZ2EytNeUv4bc+AwewLhFJujjtDiORmSWmcDGEJW
QLRzkZg2uTi5YgeQvHCgQPd2NZqRWSt06i1TpD0FaMonZy2AFuienJxaSqzF9a9A
SCibt3pNbPjq9oBQI5ZDfVsRg0DkWLtvf6JuGHhPwNnveCHR4aJFAiOuxrdluUUQ
MSeFvcG/pHCv7r1RTi0zA8ZK5r4l4jmgrZjm9wzTBqee1DljzeKL3uqY81r3Tpn5
RooWvWTSNhLW1v5SvmA4+OHipIVEjtySGfqwrZ3QjGLcaJCeMaCOYFcqszDvmgT3
j9MwSU76fqrZ/CfVGegrXAKb747dFJ5A4Xv8cDTh0sTrXgE+NZpwtFt/RBz9Xbje
ZttigIDwyu3WGXmgGpG/OEfwb1sIbPPW31bY0q686qFwEDzJBvVnUswOx/okN6iv
byH8jK5/ZyhgmdC9AyDs3eCCxgNHOYFaOhNBr/TYvCcCIJ/qZ+Z/dnAECADQWDO6
zlfcuAu7wCSY5Rl1I82kRhuA0Je5dJA4Xz3UNuIKid7/DnMlDus5myUD5vzE2P8o
3RuWYGg1gTaPE+Ef0OZ8
=lrXl
-END PGP SIGNATURE-


Thank you for your contribution to Debian.



Processing of hw-detect_1.121_i386.changes

2017-01-15 Thread Debian FTP Masters
hw-detect_1.121_i386.changes uploaded successfully to localhost
along with the files:
  hw-detect_1.121.dsc
  hw-detect_1.121.tar.xz
  archdetect_1.121_i386.udeb
  disk-detect_1.121_i386.udeb
  driver-injection-disk-detect_1.121_all.udeb
  ethdetect_1.121_all.udeb
  hw-detect_1.121_i386.buildinfo
  hw-detect_1.121_i386.udeb

Greetings,

Your Debian queue daemon (running on host usper.debian.org)



Processing of cdebconf_0.220_i386.changes

2017-01-15 Thread Debian FTP Masters
cdebconf_0.220_i386.changes uploaded successfully to localhost
along with the files:
  cdebconf_0.220.dsc
  cdebconf_0.220.tar.xz
  cdebconf-dbgsym_0.220_i386.deb
  cdebconf-gtk-dbgsym_0.220_i386.deb
  cdebconf-gtk-udeb_0.220_i386.udeb
  cdebconf-gtk_0.220_i386.deb
  cdebconf-newt-udeb_0.220_i386.udeb
  cdebconf-priority_0.220_all.udeb
  cdebconf-text-udeb_0.220_i386.udeb
  cdebconf-udeb_0.220_i386.udeb
  cdebconf_0.220_i386.buildinfo
  cdebconf_0.220_i386.deb
  libdebconfclient0-dbgsym_0.220_i386.deb
  libdebconfclient0-dev_0.220_i386.deb
  libdebconfclient0-udeb_0.220_i386.udeb
  libdebconfclient0_0.220_i386.deb

Greetings,

Your Debian queue daemon (running on host usper.debian.org)



netcfg_1.141_i386.changes ACCEPTED into unstable

2017-01-15 Thread Debian FTP Masters


Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 16 Jan 2017 05:56:00 +0100
Source: netcfg
Binary: netcfg netcfg-static
Architecture: source i386
Version: 1.141
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 netcfg - Configure the network (udeb)
 netcfg-static - Configure a static network (udeb)
Changes:
 netcfg (1.141) unstable; urgency=medium
 .
   [ Samuel Thibault ]
   * Revert work around for bug #769189, it is now fixed.
Checksums-Sha1:
 90169c40e1d736c5bbeb98743ae2b6b51d0d1c9b 1893 netcfg_1.141.dsc
 b1af238c52dbfce5c8308758c23ef8c9ca16b9c9 391936 netcfg_1.141.tar.xz
 6bdd7f030ae4043e6e0432a2ef7a54b5ae6522e2 343376 netcfg-static_1.141_i386.udeb
 a88f553772d2a97f2d9394c456642a90cc3e336f 5071 netcfg_1.141_i386.buildinfo
 d3ba548cf98f629893dd5933758ead141ce9774b 439310 netcfg_1.141_i386.udeb
Checksums-Sha256:
 57bc37c6f02e25815d823b13982493277bc3ccc72539915900ee46965cd5bf9c 1893 
netcfg_1.141.dsc
 9d70a88bc90087b7c251ef06b8ca49d69a20280426519af248cbce0e94381a40 391936 
netcfg_1.141.tar.xz
 4d91321e194ae03f45042cf608b6915f88c2176f8aaa21dd5fe0b2c1b5a8e6ad 343376 
netcfg-static_1.141_i386.udeb
 1d719b90426ce4511990064c524613650eaecb7c0a21257f855f1ceb9db1705b 5071 
netcfg_1.141_i386.buildinfo
 0121fa3a06f7cc19d0cda4c2e4f168b275daeb3dd09cd8f29baf8db0d76e4289 439310 
netcfg_1.141_i386.udeb
Files:
 c20a646ede39bd596c0cf5563fecb33b 1893 debian-installer optional 
netcfg_1.141.dsc
 71e8c7e8050a8854d034d8a1cc6eb681 391936 debian-installer optional 
netcfg_1.141.tar.xz
 7fbc0ad2471ea757bdb10fd31f57533c 343376 debian-installer optional 
netcfg-static_1.141_i386.udeb
 b285719442cc97cf5e2759fe7ef494c5 5071 debian-installer optional 
netcfg_1.141_i386.buildinfo
 c8ca98e3a2add10a959799eb8cf6072f 439310 debian-installer optional 
netcfg_1.141_i386.udeb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJYfGMdAAoJEIcvcCxNbiWowG4P/08mawmuQxUe/BnzjVrb+O+m
kJPUipY+/u+D/xv0Hy1BWOgG/4SbXysRn6TuL7k9AHoUr9iEa7JOazwi2CoLBxox
QaR40pQP/xaBjWlfsB0msMioUwP5w0/s3Ppu/i+db9KLXe4Ek+txl43MMohNgMCc
FnivRUeqs6RMOpc6V3rbLOkBW/Y166faCL1rarYD8ljkfzbYC+BcyUnLj33RdUvm
404AH2jDcc104l+BlS+Ja4ZdPxeF2dOioUomL9cOiJ1K+BFetpUQCNlR0HFUnyzR
u0XCSGVoshGrZjuqmOCrTgDR5uC4Py+SmX/mcQ6Ifn5MMJLgRtGo+LPo2YWeao4L
T8nzxliojnu02vCBeZoJ0U7kNTkPUPZQG2Nt0gWUa6R52zOcMDTMmMomGD8e+iTs
5KflXVYf/xNfCndUQSR7yRlFvF9oeNMNX9mHYGb60q5pzPGNv3xHyRO1z3S4lkR0
DJ9RaTU499geib9lvnTk6Y22+F/a6d2r9L/aPcc3fuQHS29CZzsxAcxnzL5ASXs6
FnVMops6qekL5SWHbL4u4I+bXjwlz+Lcx0H3CgngAZoHJMTnjDoUc3FYn4+Zisye
d6Yl1tzrnr7cPxre+K9vN4OOycOuq8iRhjJIlk15nlA93HBS2+hK1Yy/cSThRPrA
E4cW9rn5soGcst1tZXMz
=BDoq
-END PGP SIGNATURE-


Thank you for your contribution to Debian.



Processing of netcfg_1.141_i386.changes

2017-01-15 Thread Debian FTP Masters
netcfg_1.141_i386.changes uploaded successfully to localhost
along with the files:
  netcfg_1.141.dsc
  netcfg_1.141.tar.xz
  netcfg-static_1.141_i386.udeb
  netcfg_1.141_i386.buildinfo
  netcfg_1.141_i386.udeb

Greetings,

Your Debian queue daemon (running on host usper.debian.org)



kernel-wedge_2.96_i386.changes ACCEPTED into unstable

2017-01-15 Thread Debian FTP Masters


Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 15 Jan 2017 08:01:17 +0100
Source: kernel-wedge
Binary: kernel-wedge
Architecture: source all
Version: 2.96
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 kernel-wedge - udeb package builder for Debian-Installer
Changes:
 kernel-wedge (2.96) unstable; urgency=medium
 .
   [ Cyril Brulebois ]
   * Fix “strength” typo in kernel-wedge manpage, thanks to victory.
Checksums-Sha1:
 a5184e7fdabf59fb83ec13c3b3c1db5d7180dfed 1673 kernel-wedge_2.96.dsc
 1f1abc2a02291d6265ede9decbd8b5e8d487c2a7 38380 kernel-wedge_2.96.tar.xz
 07c207fc22818ae385bb717998eadca8e256c1de 39968 kernel-wedge_2.96_all.deb
 0cb1ab4c3a2ded1008fa0b9016c9474323d97f9d 4563 kernel-wedge_2.96_i386.buildinfo
Checksums-Sha256:
 b1cbec759e960fa946d4d87f3bb011092f06a4bda45438a287b8f54476f3ac12 1673 
kernel-wedge_2.96.dsc
 5e36a984d8d4a5b84f14611a7cc7f4b9e491a5377f6dc7200821f09fc78398f1 38380 
kernel-wedge_2.96.tar.xz
 07fbbb551d0e629bf2902f8ffb2404f9c7b4ec5aeb4f35d88a028d23811e8870 39968 
kernel-wedge_2.96_all.deb
 3a8c0484b0715b71ff7785583438dc9b940babe6bde200a7cefb52687e954440 4563 
kernel-wedge_2.96_i386.buildinfo
Files:
 c0f5c69bf0770ca90a280cbafb629030 1673 utils optional kernel-wedge_2.96.dsc
 1f59f5418c9037c2a4b4551ab8ab77b8 38380 utils optional kernel-wedge_2.96.tar.xz
 aa4b3dbc54f409cc670c1517348b9e8b 39968 utils optional kernel-wedge_2.96_all.deb
 d7b703f00697ebc42e98e8677e61016b 4563 utils optional 
kernel-wedge_2.96_i386.buildinfo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJYfF4vAAoJEIcvcCxNbiWo67EP/iVsLug5L1agdHRmV44e+/1S
Q8h6qpf/LKZwQTSsJl6mEvGBSpkDSKOYj/nTInQzQZVRkmZPTiRyD/lrNszIVone
apFUU2CZqg7pB2ephWgkr0QtoaoYNV7ttYZKZQexaUqROwdYYm3gPDH5QncEsx1D
1g4S0mdJk5vO2REb9/mlRJx50foNAsBX9vD8nkAeJBb5pmC2yKQXh4JiDhBawt2F
vtUdaA7uZtH964HZkMYsYqcgeseiPTlDt+Ng1VukPkftRQpP+8RHqlFe6p3xCR4p
64gPoDdrqJvtP/LWIdbIOj14L/KZ0Rg2Ly4lSOlJLcUlaTD4uJBEb4fYaHmHf7OH
j/VbJKRJ8JYOJhq8s/YYF+sum14ymlW9St+MpzQvf9VtlY3DPUuIUU30ZQstyj1e
+DgDZg12K7hTtd9UP+AoJY4S+/aC5MiSj2rT0wLuNQ/mUV9GVguUGc5teRue8Zic
6/JMqvB7BHc8k353vMXy1zo6Bg4fG5LjjrAHGon5I91mW70BYc1dEpW0ElVtgum/
PF8fuUQRjGoOsLVPMLnn+v5WBWUq+IoxQ3fpM6JAUZ5SGEknr+xHY+twb0kyIZhM
pfpvOejCham/7C+LmxN7cIbapiR6mdS9UrMbgN7a38PoZO8KZUi4TVBaQLj6ODln
naEjE4qbIrxsmNMC1tH8
=mMyL
-END PGP SIGNATURE-


Thank you for your contribution to Debian.



Processing of kernel-wedge_2.96_i386.changes

2017-01-15 Thread Debian FTP Masters
kernel-wedge_2.96_i386.changes uploaded successfully to localhost
along with the files:
  kernel-wedge_2.96.dsc
  kernel-wedge_2.96.tar.xz
  kernel-wedge_2.96_all.deb
  kernel-wedge_2.96_i386.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)



Bug#851526: Please provide command-line option to disable ipv6

2017-01-15 Thread Ben Hutchings
On Sun, 2017-01-15 at 17:06 -0700, Nicholas D Steeves wrote:
> On Sun, Jan 15, 2017 at 02:43:45PM -0800, Josh Triplett wrote:
> > Package: netcfg
> > Severity: wishlist
> > 
> > netcfg provides an option to completely disable all automatic
> > configuration, but no option to disable ipv6 autoconfig (SLAAC) while
> > leaving DHCP enabled.  Putting ipv6.disable=1 on the kernel command line
> > will cause netcfg to realize the network has no ipv6, but only after
> > waiting a similar timeout for a link-local address, defeating the
> > purpose.
> > 
> > Please either detect disabled ipv6 and skip those steps, or provide a
> > command-line option to disable ipv6 in netcfg.
> > 
> > (Context: repeatedly testing preseed installs in a virtual machine, and
> > I don't want to keep waiting on ipv6 autoconfig timing out.)
> > 
> 
> From what I've read, ipv6.disable=1 hasn't been sufficient for quite
> some time, and one requires something like the following in
> /etc/sysctl.d/:
> 
> 00-disable-ipv6.conf:
> net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.lo.disable_ipv6 = 1

You read wrong.  ipv6.disable=1 does all that, and more.
(See https://kernel.org/doc/Documentation/networking/ipv6.txt)

Ben.

-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug


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


Bug#851539: Stretch RC1 netinst installer prompts for additional CDs

2017-01-15 Thread Steve McIntyre
On Sun, Jan 15, 2017 at 04:53:26PM -0800, Josh Triplett wrote:
>Package: installation-reports
>Severity: normal
>
>I tried doing an install with a Stretch RC1 netinst CD.  Worked fine,
>except that later in the install, right before asking about an apt
>mirror, the installer asked about scaning additional CDs.  Previous
>versions of the netinst installer haven't asked that question; normally
>only the full-CD installers ask that.

This is a deliberate change, yes. It makes the firmware netinsts more
useful now, for example...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross



Bug#851539: Stretch RC1 netinst installer prompts for additional CDs

2017-01-15 Thread Josh Triplett
Package: installation-reports
Severity: normal

I tried doing an install with a Stretch RC1 netinst CD.  Worked fine,
except that later in the install, right before asking about an apt
mirror, the installer asked about scaning additional CDs.  Previous
versions of the netinst installer haven't asked that question; normally
only the full-CD installers ask that.

- Josh Triplett



Bug#851537: Please support preseeding an empty domain to prevent prompting

2017-01-15 Thread Josh Triplett
Package: netcfg
Severity: wishlist

netcfg supports preseeding the domain via netcfg/get_domain, but
providing an empty values results in the installer still prompting.
Please consider providing a way to preseed an empty domain name, to
completely suppress the prompt for one.

Thanks,
Josh Triplett



Bug#851526: Please provide command-line option to disable ipv6

2017-01-15 Thread Nicholas D Steeves
On Sun, Jan 15, 2017 at 02:43:45PM -0800, Josh Triplett wrote:
> Package: netcfg
> Severity: wishlist
> 
> netcfg provides an option to completely disable all automatic
> configuration, but no option to disable ipv6 autoconfig (SLAAC) while
> leaving DHCP enabled.  Putting ipv6.disable=1 on the kernel command line
> will cause netcfg to realize the network has no ipv6, but only after
> waiting a similar timeout for a link-local address, defeating the
> purpose.
> 
> Please either detect disabled ipv6 and skip those steps, or provide a
> command-line option to disable ipv6 in netcfg.
> 
> (Context: repeatedly testing preseed installs in a virtual machine, and
> I don't want to keep waiting on ipv6 autoconfig timing out.)
>

From what I've read, ipv6.disable=1 hasn't been sufficient for quite
some time, and one requires something like the following in
/etc/sysctl.d/:

00-disable-ipv6.conf:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Cheers,
Nicholas


signature.asc
Description: Digital signature


Bug#385628: debian-installer: Should incite the user to use different password for root and for the initial user

2017-01-15 Thread Josh Triplett
Package: user-setup
Followup-For: Bug #385628

I'd rather not annoy users with such a prompt.  On a single-user system,
especially one using sudo for root access, using the same password for
both a user and root seems perfectly fine.  Only a multi-user system
where multiple people have root needs to worry about this.

- Josh Triplett

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#851526: Please provide command-line option to disable ipv6

2017-01-15 Thread Josh Triplett
Package: netcfg
Severity: wishlist

netcfg provides an option to completely disable all automatic
configuration, but no option to disable ipv6 autoconfig (SLAAC) while
leaving DHCP enabled.  Putting ipv6.disable=1 on the kernel command line
will cause netcfg to realize the network has no ipv6, but only after
waiting a similar timeout for a link-local address, defeating the
purpose.

Please either detect disabled ipv6 and skip those steps, or provide a
command-line option to disable ipv6 in netcfg.

(Context: repeatedly testing preseed installs in a virtual machine, and
I don't want to keep waiting on ipv6 autoconfig timing out.)



Bug#851514: Installer using virtio disk or CD-ROM fails to find itself

2017-01-15 Thread Josh Triplett
Package: installation-reports
Severity: normal

An installation on a virtual machine booting the installer from a virtio
disk or CDROM drive results in a "Detect and mount CD-ROM" failure ("No
common CD-ROM drive was detected.") after the language prompts.  To
reproduce this, try the following:

qemu-img create debian.img 10G
kvm -m 1G -drive 
file=debian-stretch-DI-rc1-amd64-netinst.iso,media=cdrom,if=virtio,format=raw 
-drive file=debian.img,if=virtio,format=raw



Re: [Openchrome-users] How to say No!! in a polite though ridiculous way

2017-01-15 Thread Tzafrir Cohen
On Fri, Jan 13, 2017 at 11:47:40PM +0100, Kevin Brace wrote:
> Hi Andreas,
> 
> Throw this in your xorg.conf
> 
> 
> Section "Module"
>   Load"vgahw"
> EndSection
> 
> 
> Other than that, your xorg.conf can be empty.
> I hope it works.

Thanks. Works for me. Debian Stretch. Before that I had to remove
openchrome.so. I put that content as
/usr/share/X11/xorg.conf.d/30-openchrome.conf and now it works fine.

For the record, the hardware in question:

00:01.0 VGA compatible controller: VIA Technologies, Inc. VX855/VX875 Chrome 9 
HCM Integrated Graphics (prog-if 00 [VGA controller])
Subsystem: VIA Technologies, Inc. VX855/VX875 Chrome 9 HCM Integrated 
Graphics
Flags: bus master, fast devsel, latency 32, IRQ 11
Memory at d800 (32-bit, prefetchable) [size=64M]
Memory at de00 (32-bit, non-prefetchable) [size=16M]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-

Debian packaging:

I would appreciate it if the Debian package could include such a file
(if it is harmless) or at least as an example. Or find a way to avoid
the extra configuration.

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend



Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot

2017-01-15 Thread permondes - sagen
Am Sonntag, den 15.01.2017, 12:39 +0100 schrieb Karsten Merker:
> On Sun, Jan 15, 2017 at 12:02:56PM +0100, permondes - sagen wrote:
> > Am Sonntag, den 15.01.2017, 11:47 +0100 schrieb Karsten Merker:
> 
> > > This points at a problem with either your u-boot version or your
> > > u-boot environment.  The oldest u-boot version that Debian has
> > > ever shipped for the Olinuxino A20 LIME as part of the official
> > > Debian-Installer images has been mainline u-boot v2014.10, and
> > > all mainline u-boot versions since v2014.10 provide a default
> > > environment that is compatible with this boot script.
> > > 
> > > Please note that u-boot keeps its old environment on upgrade by
> > > default, i.e. if you originally had e.g. some vendor-specific
> > > u-boot installed and upgraded to mainline u-boot later, this
> > > would have kept the environment from the vendor u-boot. You can
> > > reset the u-boot environment to its current default by running
> > > "env default -a; saveenv" at the u-boot command prompt.
> > > 
> > > HTH,
> > > Karsten
> > 
> > The device is being used as a FreedomBox, a flavour of Debian. They
> > provide an initial "live" image which is quite old actually. Updating to
> > the current version, which is done automatically during set-up, makes
> > this change of boot.scr, so I guess they switched to standard u-boot.
> 
> Not necessarily.  The boot.scr is generated by the flash-kernel
> package on every kernel update, but the u-boot in the boot area is
> not automatically updated with an update of the u-boot-sunxi
> package, so unless the people who have built the freedombox upgrade
> mechanism have explicitly implemented a function to update the
> u-boot in the boot area (which I doubt), you will probably still
> have whatever older u-boot version was used when building the
> original freedombox image.
> 
> > I would like to test the reset of the environment, how do I get into
> > u-boot prompt? I just have ssh access to the box, no serial, nor
> > keyboard or so.
> 
> Hm, that poses a problem.  The "normal" way is via serial console,
> or, if the u-boot version is relatively new, via a display
> connected to the HDMI port and a USB keyboard.  U-Boot isn't memory
> resident (except for the PSCI functions), i.e. once the Linux
> kernel is booted, there is no u-boot anymore with which one could
> interact directly.
> 
> What you could try is clobbering the area on the SD card in which
> u-boot stores the environment.  This results in a checksum mismatch
> and u-boot falls back to the integrated default environment.  On
> the LIME, the u-boot environment is stored on the SD card starting
> at offset 544kB from the start of the device, and is 128kB in size. 
> So on the LIME running
> 
> $ sudo dd if=/dev/zero bs=1k count=128 seek=544 of=/dev/mmcblk0
> 
> should overwrite the complete environment area with zeros,
> resulting in u-boot falling back to the built-in defaults. But
> without some form of console you still won't be able to see which
> version of u-boot is really installed (cf. my mail to debian-arm)
> and what exactly happens at boot time.  If you want to make sure
> that you have a current u-boot version installed, you can replace
> whatever version is currently on the SD card by running
> 
> $ sudo dd if=/usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin 
> of=/dev/mmcblk0 bs=1k seek=8
> 
> Doing all this "blind" without console is of course inherently
> dangerous, so make an image backup of your SD card that you can
> restore in case of problems before trying any of this.
> 
> HTH,
> Karsten

Hi Karsten,

this what I did:

to get a fresh boot.scr I used a command I got from the freedombox list
some time ago:
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

Then I zeroed the environment and copied the correct u-boot.

The devices booted, but I realized that boot.scr did not have the
correct content, so I copied the before mentioned boot script for
Allwinner SunXi-based devices over it and restarted the device. This
time, it did not boot afterwards. 

Copying back the previous boot.scr made it boot again. The environment
variables were the same as before. So I am back where I have been
before.

My understanding is, that this strange behavior is due to a transition
that happened in the Freedombox project. So I will ask them to provide
updated live images to start with a fresh and correct system instead of
wasting time and trying to solve this particular case. 

Thanks for your support anyway
Dietmar



Bug#820911: installation-report: Accessibility for visual impaired is broken,, High-Contrast Theme is no longer activated by shortcut

2017-01-15 Thread Samuel Thibault
Hello Alex,

Alex ARNAUD, on Thu 01 Dec 2016 14:56:08 +0100, wrote:
> - Change the Debian installation guide to help visual-impaired to
> activate the ncurse or graphical high-contrast theme.
> I'm not able to write it myself because the contrast of the first screen
> makes it completely unreadable for me.

Some text was added to the installation guide about the boot menu:

«
If you wish or need to add any boot parameters for either the installer
or the kernel, press Tab (BIOS boot), or 'e' then down arrow three times
then 'end' (UEFI boot). This will bring the boot command for the selected
menu entry and allow you to edit it to suit your needs. The help screens
(see below) list some common possible options. Press 'Enter' (BIOS boot)
or 'F10' (UEFI boot) to boot the installer with your options; pressing Esc
will return you to the boot menu and undo any changes you made.
»

Is this enough for your needs?

Samuel



Bug#851486: debian-installer: USB keyboard doesn't work on Banana Pi

2017-01-15 Thread Stephen Kitt
Package: debian-installer
Version: 20170112
Severity: normal
Tags: d-i

Dear Maintainer,

My Banana Pi's SD card got corrupted so I'm trying to re-install the
system. Following the instructions on
https://wiki.debian.org/InstallingDebianOn/Allwinner I downloaded the
bits from
http://ftp.uk.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/
and the resulting SD card boots fine. After applying the console
changes to output to HDMI, I can even see the installer — but the USB
keyboard doesn't work... It works in u-boot so the hardware would
appear to be OK.

Regards,

Stephen


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

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


Re: Debian Installer Stretch RC 1 release

2017-01-15 Thread Antoine Beaupré
Congratulations on the d-i team for the RC1 release. I recently sent a
succesful install report bug, and I am really happy with the work you
are doing.

I know how difficult and ungrateful this work can be, so I really
appreciate all the work your doing.

Keep it up!

A.
-- 
The survival of humans and other species on planet Earth in my view can
only be guaranteed via a timely transition towards a stationary
state, a world economy without growth.
 - Peter Custers



Bug#851429: installation-reports: mounting CD fails on qemu-system-aarch64

2017-01-15 Thread Adam Borowski
On Sun, Jan 15, 2017 at 01:12:53AM +, Steve McIntyre wrote:
> On Sat, Jan 14, 2017 at 10:34:18PM +0100, Adam Borowski wrote:
> >I'm afraid that regular arm64 d-i images fail to detect qemu's CD-ROM, and
> >there's apparently no way to direct it to load udebs from a network mirror
> >like mini.iso does.  On the other hand, installation with mini.iso works
> >well.
> >
> >The failing step is "Detecting hardware to find CD-ROM drives".
> >
> >CD=debian-stretch-DI-rc1-arm64-netinst.iso
> >NET="-net bridge -net nic"
> >
> >qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \
> > -bios /usr/share/qemu-efi/QEMU_EFI.fd -m 2048 $NET \
> > -drive file="$DISK",cache=writeback,index=0,media=disk,format=raw \
> > -drive file="$CD",cache=writeback,index=1,media=cdrom -boot d
> 
> I think the problem is with your setup. I've just booted that exact
> netinst image happily using
> 
> qemu-system-aarch64 -m 4G -cpu cortex-a57 -M virt -smp 8 -nographic
> -pflash AAVMF_CODE.fd -pflash AAVMF_VARS.fd -drive
> file=/scratch/iso/debian-stretch-DI-rc1-arm64-netinst.iso,id=cdrom,if=none,media=cdrom
> -device virtio-scsi-device -device scsi-cd,drive=cdrom -k en-gb
> -netdev user,id=eth0 -device virtio-net-device,netdev=eth0

Ie, virtio vs emulating a real piece of hardware.

The problem here, though, is that qemu picked a piece of hardware that's old
crap that's not expected in any physical arm64 gardware.  I guess it'd be
good to ask them to upgrade, like they did with the Cirrus card on x86.

Ordinarily I'd want you to support this "hardware" as QEMU is a major
platform (at least the one most available), but in this case, with the
extensive incantations required to get it running, requiring virtio might be
acceptable.  I refuse to say "arguments" rather than "incantations" as
the former is for specifying what the program should do and what you want
altered from reasonable defaults, rather than a massive ritual that needs to
be performed just to get basic functionality, with every piece involving
lengthy research and breakage/data loss if you skip it.  Like, my line lacks
a flash for storing EFI vars, meaning that it will install correctly (with
mini.iso), work when rebooted, even upon multiple reboots, then fail to work
anymore once you shut down qemu and start it again.

So I wonder what's the best way to proceed.  Probably documenting what's
needed might be a good step.

> and it's running the installer right now with udebs from the netinst
> iso. What version of qemu-efi are you using for
> /usr/share/qemu-efi/QEMU_EFI.fd?

0~20161202.7bbe0b3e-1 (current unstable and stretch).

-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11



Re: Debian Installer Stretch RC 1 release

2017-01-15 Thread Ole Streicher
On 15.01.2017 05:21, Cyril Brulebois wrote:
> The Debian Installer team[1] is pleased to announce the first release
> candidate of the installer for Debian 9 "Stretch".
> 
> 
> Important changes in this release of the installer
> ==
> 
>  * [...]
>  * As noted in the Stretch Alpha 6 release announcement, Debian Pure
>Blends appeared in the Software selection screen. Unfortunately,
>concerns voiced back then weren't worked on until after the freeze
>started, and a freeze isn't the time where critical screens should
>be revamped. Support was disabled accordingly.

Since this is still an open discussion in #846002, I would have
preferred if you would not try to force your own preference here before
the CTTE made its decision. IMO your solution is not in any way
cooperative and tries to make the CTTE decision useless.

I therefore would ask the CTTE to make a final decision about the
inclusion of the blends selection in the Stretch installer. In principle
these are *two* decisions:

1. Appearance of the blends in the installer:

Please decide, whether

 * the blends shall be shown in their current (alpha-8) form

 * The installer is extended to show the desktop and the blends only
   optionally (as propagated by Phil, and opposed by Cyril)

 * the blends should not appear in the Stretch installer at all.

2. Maintenance of the blends tasks appearing in the installer:

 * in a separate package maintained by the blends team

 * integrated into tasksel and maintained by d-i

 * be removed completely from the installation process

Best regards

Ole



Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot

2017-01-15 Thread Karsten Merker
On Sun, Jan 15, 2017 at 12:02:56PM +0100, permondes - sagen wrote:
> Am Sonntag, den 15.01.2017, 11:47 +0100 schrieb Karsten Merker:

> > This points at a problem with either your u-boot version or your
> > u-boot environment.  The oldest u-boot version that Debian has
> > ever shipped for the Olinuxino A20 LIME as part of the official
> > Debian-Installer images has been mainline u-boot v2014.10, and
> > all mainline u-boot versions since v2014.10 provide a default
> > environment that is compatible with this boot script.
> > 
> > Please note that u-boot keeps its old environment on upgrade by
> > default, i.e. if you originally had e.g. some vendor-specific
> > u-boot installed and upgraded to mainline u-boot later, this
> > would have kept the environment from the vendor u-boot. You can
> > reset the u-boot environment to its current default by running
> > "env default -a; saveenv" at the u-boot command prompt.
> > 
> > HTH,
> > Karsten
> 
> The device is being used as a FreedomBox, a flavour of Debian. They
> provide an initial "live" image which is quite old actually. Updating to
> the current version, which is done automatically during set-up, makes
> this change of boot.scr, so I guess they switched to standard u-boot.

Not necessarily.  The boot.scr is generated by the flash-kernel
package on every kernel update, but the u-boot in the boot area is
not automatically updated with an update of the u-boot-sunxi
package, so unless the people who have built the freedombox upgrade
mechanism have explicitly implemented a function to update the
u-boot in the boot area (which I doubt), you will probably still
have whatever older u-boot version was used when building the
original freedombox image.

> I would like to test the reset of the environment, how do I get into
> u-boot prompt? I just have ssh access to the box, no serial, nor
> keyboard or so.

Hm, that poses a problem.  The "normal" way is via serial console,
or, if the u-boot version is relatively new, via a display
connected to the HDMI port and a USB keyboard.  U-Boot isn't memory
resident (except for the PSCI functions), i.e. once the Linux
kernel is booted, there is no u-boot anymore with which one could
interact directly.

What you could try is clobbering the area on the SD card in which
u-boot stores the environment.  This results in a checksum mismatch
and u-boot falls back to the integrated default environment.  On
the LIME, the u-boot environment is stored on the SD card starting
at offset 544kB from the start of the device, and is 128kB in size. 
So on the LIME running

$ sudo dd if=/dev/zero bs=1k count=128 seek=544 of=/dev/mmcblk0

should overwrite the complete environment area with zeros,
resulting in u-boot falling back to the built-in defaults. But
without some form of console you still won't be able to see which
version of u-boot is really installed (cf. my mail to debian-arm)
and what exactly happens at boot time.  If you want to make sure
that you have a current u-boot version installed, you can replace
whatever version is currently on the SD card by running

$ sudo dd if=/usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin 
of=/dev/mmcblk0 bs=1k seek=8

Doing all this "blind" without console is of course inherently
dangerous, so make an image backup of your SD card that you can
restore in case of problems before trying any of this.

HTH,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.



Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot

2017-01-15 Thread permondes - sagen
Am Sonntag, den 15.01.2017, 11:47 +0100 schrieb Karsten Merker:
> On Sun, Jan 15, 2017 at 10:45:29AM +0100, permondes - sagen wrote:
> 
> > Package: flash-kernel
> > Version: 3.73
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > I am using an OLinuXino A20 LIME with arm. 
> > boot.scr used to have the following content (I removed the initial
> > non-readable characters) which let boot the device without issues:
> > 
> > setenv mmcpart 1
> > 
> > setenv mmcroot /dev/mmcblk0p2 ro
> > setenv mmcrootfstype btrfs rootwait fixrtc
> > setenv mmcrootflags subvol=@
> > 
> > setenv console ttyS0,115200n8
> > 
> > setenv kernel_file vmlinuz-4.8.0-2-armmp-lpae
> > setenv initrd_file initrd.img-4.8.0-2-armmp-lpae
> > setenv fdtfile sun7i-a20-olinuxino-lime.dtb
> > 
> > setenv loadaddr 0x4600
> > setenv initrd_addr 0x4800
> > setenv fdtaddr 0x4700
> > 
> > setenv initrd_high 0x
> > setenv fdt_high 0x
> > 
> > setenv loadkernel load mmc ${mmcdev}:${mmcpart} ${loadaddr}
> > ${kernel_file}
> > setenv loadinitrd load mmc ${mmcdev}:${mmcpart} ${initrd_addr}
> > ${initrd_file}\; setenv initrd_size \${filesize}
> > setenv loadfdt load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile}
> > 
> > setenv loadfiles run loadkernel\; run loadinitrd\; run loadfdt
> > setenv mmcargs setenv bootargs console=${console} root=${mmcroot}
> > rootfstype=${mmcrootfstype} rootflags=${mmcrootflags}
> > 
> > run loadfiles; run mmcargs; bootz ${loadaddr} ${initrd_addr}:
> > ${initrd_size} ${fdtaddr}
> > 
> > <-- end of file
> 
> To my knowledge Debian has never provided a boot script with this
> content as a part of its official flash-kernel releases.  Is this
> perhaps from some non-official Debian image that somebody else
> has produced, e.g. from some image provided by the hardware
> manufacturer or from some other project that uses Debian as its
> base but doesn't use Debian's normal mechanisms for handling the
> boot scripts?
> 
> Which u-boot version do you have installed? Can you provide the
> output of the "printenv" command at the u-boot prompt?
> 
> > The new content of that file is:
> > 
> > # boot script for Allwinner SunXi-based devices
> > 
> > # Mainline u-boot v2014.10 introduces a new default environment and
> > # a new common bootcmd handling for all platforms, which is not fully
> > # compatible with the old-style environment used by u-boot-sunxi.
> > # This script therefore needs to check in which environment it
> > # is running and set some variables accordingly.
> > 
> > # On u-boot-sunxi, this script assumes that ${device} and ${partition}
> > # are set.
> > 
> > # The new-style environment predefines ${boot_targets}, the old-style
> > # environment does not.
> > if test -n "${boot_targets}"
> > then
> >   echo "Mainline u-boot / new-style environment detected."
> >   # Mainline u-boot v2014.10 uses ${devtype}, ${devnum} and
> >   # ${bootpart} where u-boot-sunxi uses ${device} and ${partition}.
> >   # ${distro_bootpart} replaced ${bootpart} in u-boot v2016.01.
> >   if test -z "${device}"; then setenv device "${devtype}"; fi
> >   if test -z "${partition}${distro_bootpart}"; then setenv partition
> > "${devnum}:${bootpart}"; fi
> >   if test -z "${partition}"; then setenv partition "${devnum}:
> > ${distro_bootpart}"; fi
> > else
> >   echo "U-boot-sunxi / old-style environment detected."
> >   # U-boot-sunxi does not predefine kernel_addr_r, fdt_addr_r and
> >   # ramdisk_addr_r, so they have to be manually set. Use the values
> >   # from mainline u-boot v2014.10, except for ramdisk_addr_r,
> >   # which is set to 0x4430 to allow for initrds larger than
> >   # 13MB on u-boot-sunxi.
> >   setenv kernel_addr_r 0x4200
> >   setenv fdt_addr_r 0x4300
> >   setenv ramdisk_addr_r 0x4430
> > fi
> > 
> > if test -n "${console}"; then
> >   setenv bootargs "${bootargs} console=${console}"
> > fi
> > 
> > setenv bootargs  ${bootargs} quiet
> > 
> > 
> > image_locations='/boot/ /'
> > if test -z "${fk_kvers}"; then
> >setenv fk_kvers '4.8.0-2-armmp-lpae'
> > fi
> > 
> > if test -n "${fdtfile}"; then
> >setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
> > else
> >setenv fdtpath dtb-${fk_kvers}
> > fi
> > 
> > for pathprefix in ${image_locations}
> > do
> >   if test -e ${device} ${partition} ${pathprefix}vmlinuz-${fk_kvers}
> >   then
> > load ${device} ${partition} ${kernel_addr_r}
> > ${pathprefix}vmlinuz-${fk_kvers} \
> > && load ${device} ${partition} ${fdt_addr_r} ${pathprefix}${fdtpath}
> > \
> > && load ${device} ${partition} ${ramdisk_addr_r}
> > ${pathprefix}initrd.img-${fk_kvers} \
> > && echo "Booting Debian ${fk_kvers} from ${device} ${partition}..."
> > \
> > && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize}
> > ${fdt_addr_r}
> >   fi
> > done
> > 
> > <- end of file
> > 
> > Which does not allow the device to boot. 
> > None of the variables in that script is set in the current environment.
> 
> This points at a problem with 

Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot

2017-01-15 Thread Karsten Merker
On Sun, Jan 15, 2017 at 10:45:29AM +0100, permondes - sagen wrote:

> Package: flash-kernel
> Version: 3.73
> Severity: important
> 
> Dear Maintainer,
> 
> I am using an OLinuXino A20 LIME with arm. 
> boot.scr used to have the following content (I removed the initial
> non-readable characters) which let boot the device without issues:
> 
> setenv mmcpart 1
> 
> setenv mmcroot /dev/mmcblk0p2 ro
> setenv mmcrootfstype btrfs rootwait fixrtc
> setenv mmcrootflags subvol=@
> 
> setenv console ttyS0,115200n8
> 
> setenv kernel_file vmlinuz-4.8.0-2-armmp-lpae
> setenv initrd_file initrd.img-4.8.0-2-armmp-lpae
> setenv fdtfile sun7i-a20-olinuxino-lime.dtb
> 
> setenv loadaddr 0x4600
> setenv initrd_addr 0x4800
> setenv fdtaddr 0x4700
> 
> setenv initrd_high 0x
> setenv fdt_high 0x
> 
> setenv loadkernel load mmc ${mmcdev}:${mmcpart} ${loadaddr}
> ${kernel_file}
> setenv loadinitrd load mmc ${mmcdev}:${mmcpart} ${initrd_addr}
> ${initrd_file}\; setenv initrd_size \${filesize}
> setenv loadfdt load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile}
> 
> setenv loadfiles run loadkernel\; run loadinitrd\; run loadfdt
> setenv mmcargs setenv bootargs console=${console} root=${mmcroot}
> rootfstype=${mmcrootfstype} rootflags=${mmcrootflags}
> 
> run loadfiles; run mmcargs; bootz ${loadaddr} ${initrd_addr}:
> ${initrd_size} ${fdtaddr}
> 
> <-- end of file

To my knowledge Debian has never provided a boot script with this
content as a part of its official flash-kernel releases.  Is this
perhaps from some non-official Debian image that somebody else
has produced, e.g. from some image provided by the hardware
manufacturer or from some other project that uses Debian as its
base but doesn't use Debian's normal mechanisms for handling the
boot scripts?

Which u-boot version do you have installed? Can you provide the
output of the "printenv" command at the u-boot prompt?

> The new content of that file is:
> 
> # boot script for Allwinner SunXi-based devices
> 
> # Mainline u-boot v2014.10 introduces a new default environment and
> # a new common bootcmd handling for all platforms, which is not fully
> # compatible with the old-style environment used by u-boot-sunxi.
> # This script therefore needs to check in which environment it
> # is running and set some variables accordingly.
> 
> # On u-boot-sunxi, this script assumes that ${device} and ${partition}
> # are set.
> 
> # The new-style environment predefines ${boot_targets}, the old-style
> # environment does not.
> if test -n "${boot_targets}"
> then
>   echo "Mainline u-boot / new-style environment detected."
>   # Mainline u-boot v2014.10 uses ${devtype}, ${devnum} and
>   # ${bootpart} where u-boot-sunxi uses ${device} and ${partition}.
>   # ${distro_bootpart} replaced ${bootpart} in u-boot v2016.01.
>   if test -z "${device}"; then setenv device "${devtype}"; fi
>   if test -z "${partition}${distro_bootpart}"; then setenv partition
> "${devnum}:${bootpart}"; fi
>   if test -z "${partition}"; then setenv partition "${devnum}:
> ${distro_bootpart}"; fi
> else
>   echo "U-boot-sunxi / old-style environment detected."
>   # U-boot-sunxi does not predefine kernel_addr_r, fdt_addr_r and
>   # ramdisk_addr_r, so they have to be manually set. Use the values
>   # from mainline u-boot v2014.10, except for ramdisk_addr_r,
>   # which is set to 0x4430 to allow for initrds larger than
>   # 13MB on u-boot-sunxi.
>   setenv kernel_addr_r 0x4200
>   setenv fdt_addr_r 0x4300
>   setenv ramdisk_addr_r 0x4430
> fi
> 
> if test -n "${console}"; then
>   setenv bootargs "${bootargs} console=${console}"
> fi
> 
> setenv bootargs  ${bootargs} quiet
> 
> 
> image_locations='/boot/ /'
> if test -z "${fk_kvers}"; then
>setenv fk_kvers '4.8.0-2-armmp-lpae'
> fi
> 
> if test -n "${fdtfile}"; then
>setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
> else
>setenv fdtpath dtb-${fk_kvers}
> fi
> 
> for pathprefix in ${image_locations}
> do
>   if test -e ${device} ${partition} ${pathprefix}vmlinuz-${fk_kvers}
>   then
> load ${device} ${partition} ${kernel_addr_r}
> ${pathprefix}vmlinuz-${fk_kvers} \
> && load ${device} ${partition} ${fdt_addr_r} ${pathprefix}${fdtpath}
> \
> && load ${device} ${partition} ${ramdisk_addr_r}
> ${pathprefix}initrd.img-${fk_kvers} \
> && echo "Booting Debian ${fk_kvers} from ${device} ${partition}..."
> \
> && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize}
> ${fdt_addr_r}
>   fi
> done
> 
> <- end of file
> 
> Which does not allow the device to boot. 
> None of the variables in that script is set in the current environment.

This points at a problem with either your u-boot version or your
u-boot environment.  The oldest u-boot version that Debian has
ever shipped for the Olinuxino A20 LIME as part of the official
Debian-Installer images has been mainline u-boot v2014.10, and
all mainline u-boot versions since v2014.10 provide a default
environment that is compatible with this boot script.


Re: Uploading netcfg?

2017-01-15 Thread Samuel Thibault
Christian PERRIER, on Sun 15 Jan 2017 08:06:02 +0100, wrote:
> --- a/finish-install.d/97release-dhcp-lease
> +++ b/finish-install.d/97release-dhcp-lease
> @@ -7,5 +7,5 @@ pid=$(pidof udhcpc) || true
>  
>  if [ "$(pidof dhclient || true)" ]; then
> dhclient -r || true
> -   dhclient -1 -6 -r || true
> +   dhclient -6 -r || true
>  fi
> 
> I tend to be confident in Samuel's changes, but as we are in the
> release freeze, we should also be as conservative as we can wrt D-I
> changes.
> 
> Other advices? Should I build/upload or not?

The change is just a clean-up. The -1 option was needed due to the
previous isc-dhcp behavior which was hurting the hurd port (and not
linux and kfreebsd). Now that isc-dhcp fixed its behavior the -1 option
is not needed any more. It doesn't hurt either, though, so either way is
fine.

Samuel



Uploading netcfg?

2017-01-15 Thread Christian PERRIER
I resumed tracking of pending changes in git for D-I packages, after
the release of RC1.

I'll upload kernel-wedge that has a tricial fix to a manpage.

The only other pending change is the following in netcfg:

bubulle@kheops:~/src/debian/debian-installer/trunk/packages/netcfg(master) $ 
git show 8cd816f384ac3066e5aa2652cb399cd814e98f2c
commit 8cd816f384ac3066e5aa2652cb399cd814e98f2c
Author: Samuel Thibault 
Date:   Wed Jan 11 00:45:19 2017 +0100

Revert work around for bug #769189, it is now fixed

diff --git a/debian/changelog b/debian/changelog
index 450214d..b67718b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+netcfg (1.141) UNRELEASED; urgency=medium
+
+  * Revert work around for bug #769189, it is now fixed.
+
+ -- Samuel Thibault   Wed, 11 Jan 2017 00:42:38 +0100
+
 netcfg (1.140) unstable; urgency=medium
 
   [ Julien Cristau ]
diff --git a/finish-install.d/97release-dhcp-lease 
b/finish-install.d/97release-dhcp-lease
index 4a02076..27384d2 100755
--- a/finish-install.d/97release-dhcp-lease
+++ b/finish-install.d/97release-dhcp-lease
@@ -7,5 +7,5 @@ pid=$(pidof udhcpc) || true
 
 if [ "$(pidof dhclient || true)" ]; then
dhclient -r || true
-   dhclient -1 -6 -r || true
+   dhclient -6 -r || true
 fi

I tend to be confident in Samuel's changes, but as we are in the
release freeze, we should also be as conservative as we can wrt D-I
changes.

Other advices? Should I build/upload or not?


-- 




signature.asc
Description: PGP signature


Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot

2017-01-15 Thread permondes - sagen
Package: flash-kernel
Version: 3.73
Severity: important

Dear Maintainer,

I am using an OLinuXino A20 LIME with arm. 
boot.scr used to have the following content (I removed the initial
non-readable characters) which let boot the device without issues:

setenv mmcpart 1

setenv mmcroot /dev/mmcblk0p2 ro
setenv mmcrootfstype btrfs rootwait fixrtc
setenv mmcrootflags subvol=@

setenv console ttyS0,115200n8

setenv kernel_file vmlinuz-4.8.0-2-armmp-lpae
setenv initrd_file initrd.img-4.8.0-2-armmp-lpae
setenv fdtfile sun7i-a20-olinuxino-lime.dtb

setenv loadaddr 0x4600
setenv initrd_addr 0x4800
setenv fdtaddr 0x4700

setenv initrd_high 0x
setenv fdt_high 0x

setenv loadkernel load mmc ${mmcdev}:${mmcpart} ${loadaddr}
${kernel_file}
setenv loadinitrd load mmc ${mmcdev}:${mmcpart} ${initrd_addr}
${initrd_file}\; setenv initrd_size \${filesize}
setenv loadfdt load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile}

setenv loadfiles run loadkernel\; run loadinitrd\; run loadfdt
setenv mmcargs setenv bootargs console=${console} root=${mmcroot}
rootfstype=${mmcrootfstype} rootflags=${mmcrootflags}

run loadfiles; run mmcargs; bootz ${loadaddr} ${initrd_addr}:
${initrd_size} ${fdtaddr}

<-- end of file

The new content of that file is:

# boot script for Allwinner SunXi-based devices

# Mainline u-boot v2014.10 introduces a new default environment and
# a new common bootcmd handling for all platforms, which is not fully
# compatible with the old-style environment used by u-boot-sunxi.
# This script therefore needs to check in which environment it
# is running and set some variables accordingly.

# On u-boot-sunxi, this script assumes that ${device} and ${partition}
# are set.

# The new-style environment predefines ${boot_targets}, the old-style
# environment does not.
if test -n "${boot_targets}"
then
  echo "Mainline u-boot / new-style environment detected."
  # Mainline u-boot v2014.10 uses ${devtype}, ${devnum} and
  # ${bootpart} where u-boot-sunxi uses ${device} and ${partition}.
  # ${distro_bootpart} replaced ${bootpart} in u-boot v2016.01.
  if test -z "${device}"; then setenv device "${devtype}"; fi
  if test -z "${partition}${distro_bootpart}"; then setenv partition
"${devnum}:${bootpart}"; fi
  if test -z "${partition}"; then setenv partition "${devnum}:
${distro_bootpart}"; fi
else
  echo "U-boot-sunxi / old-style environment detected."
  # U-boot-sunxi does not predefine kernel_addr_r, fdt_addr_r and
  # ramdisk_addr_r, so they have to be manually set. Use the values
  # from mainline u-boot v2014.10, except for ramdisk_addr_r,
  # which is set to 0x4430 to allow for initrds larger than
  # 13MB on u-boot-sunxi.
  setenv kernel_addr_r 0x4200
  setenv fdt_addr_r 0x4300
  setenv ramdisk_addr_r 0x4430
fi

if test -n "${console}"; then
  setenv bootargs "${bootargs} console=${console}"
fi

setenv bootargs  ${bootargs} quiet


image_locations='/boot/ /'
if test -z "${fk_kvers}"; then
   setenv fk_kvers '4.8.0-2-armmp-lpae'
fi

if test -n "${fdtfile}"; then
   setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
else
   setenv fdtpath dtb-${fk_kvers}
fi

for pathprefix in ${image_locations}
do
  if test -e ${device} ${partition} ${pathprefix}vmlinuz-${fk_kvers}
  then
load ${device} ${partition} ${kernel_addr_r}
${pathprefix}vmlinuz-${fk_kvers} \
&& load ${device} ${partition} ${fdt_addr_r} ${pathprefix}${fdtpath}
\
&& load ${device} ${partition} ${ramdisk_addr_r}
${pathprefix}initrd.img-${fk_kvers} \
&& echo "Booting Debian ${fk_kvers} from ${device} ${partition}..."
\
&& bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize}
${fdt_addr_r}
  fi
done

<- end of file

Which does not allow the device to boot. 
None of the variables in that script is set in the current environment.
As work-around I am currently copying a saved version of the former file
content to boot.scr.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 4.8.0-2-armmp-lpae (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  devio  1.2-1.2
ii  initramfs-tools0.126
ii  linux-base 4.5
ii  mtd-utils  1:2.0.0-1
ii  ucf3.0036

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2016.11+dfsg1-3

flash-kernel suggests no packages.

-- debconf information:
  flash-kernel/linux_cmdline: quiet


Dietmar



Bug#839747: marked as done (debian-installer-netboot-images: FTBFS in testing (no properly formatted SHA256 checksum lines found))

2017-01-15 Thread Debian Bug Tracking System
Your message dated Sun, 15 Jan 2017 10:00:24 +0100
with message-id <6099434.bgmakmr...@odyx.org>
and subject line Re: Bug#839747: debian-installer-netboot-images: FTBFS in 
testing (no properly formatted SHA256 checksum lines found)
has caused the Debian Bug report #839747,
regarding debian-installer-netboot-images: FTBFS in testing (no properly 
formatted SHA256 checksum lines found)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
839747: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839747
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:debian-installer-netboot-images
Version: 20150422+deb8u4.b1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep
   dh_testdir -i
   dh_update_autotools_config -i
   dh_auto_configure -i
   dh_auto_build -i
   dh_auto_test -i
 fakeroot debian/rules binary-indep
dh binary-indep
   dh_testroot -i
   dh_prep -i
   debian/rules override_dh_auto_install
make[1]: Entering directory 
'/<>/debian-installer-netboot-images-20150422+deb8u4.b1'

[... snipped ...]

Connecting to httpredir.debian.org (httpredir.debian.org)|5.153.231.35|:80... 
connected.
HTTP request sent, awaiting response... 302 Found
Location: 
http://ftp.eq.uc.pt/software/Linux/debian/dists/jessie-proposed-updates/main/binary-amd64/Packages.gz
 [following]
--2016-09-17 22:40:30--  
http://ftp.eq.uc.pt/software/Linux/debian/dists/jessie-proposed-updates/main/binary-amd64/Packages.gz
Resolving ftp.eq.uc.pt (ftp.eq.uc.pt)... 193.137.214.36
Connecting to ftp.eq.uc.pt (ftp.eq.uc.pt)|193.137.214.36|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 20 [application/x-gzip]
Saving to: 'amd64.Packages.gz'

 0K   100% 5.71M=0s

2016-09-17 22:40:30 (5.71 MB/s) - 'amd64.Packages.gz' saved [20/20]

amd64.Packages.gz: OK
--2016-09-17 22:40:30--  
http://httpredir.debian.org/debian/pool/main/d/debian-installer/debian-installer_20150422+deb8u4+b1_amd64.deb
Resolving httpredir.debian.org (httpredir.debian.org)... 128.31.0.66, 
5.153.231.35, 2001:41c8:1000:21::21:35
Connecting to httpredir.debian.org (httpredir.debian.org)|128.31.0.66|:80... 
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: 
http://ftp.eq.uc.pt/software/Linux/debian/pool/main/d/debian-installer/debian-installer_20150422+deb8u4+b1_amd64.deb
 [following]
--2016-09-17 22:40:31--  
http://ftp.eq.uc.pt/software/Linux/debian/pool/main/d/debian-installer/debian-installer_20150422+deb8u4+b1_amd64.deb
Resolving ftp.eq.uc.pt (ftp.eq.uc.pt)... 193.137.214.36
Connecting to ftp.eq.uc.pt (ftp.eq.uc.pt)|193.137.214.36|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 736654 (719K) [application/x-debian-package]
Saving to: 'debian-installer_20150422+deb8u4+b1_amd64.deb'

 0K .. .. .. .. ..  6% 1.11M 1s
50K .. .. .. .. .. 13% 2.84M 0s
   100K .. .. .. .. .. 20% 6.38M 0s
   150K .. .. .. .. .. 27% 8.54M 0s
   200K .. .. .. .. .. 34% 2.55M 0s
   250K .. .. .. .. .. 41%  130M 0s
   300K .. .. .. .. .. 48% 14.5M 0s
   350K .. .. .. .. .. 55% 10.7M 0s
   400K .. .. .. .. .. 62% 2.72M 0s
   450K .. .. .. .. .. 69% 93.0M 0s
   500K .. .. .. .. .. 76% 1.15M 0s
   550K .. .. .. .. .. 83% 2.44M 0s
   600K .. .. .. .. .. 90%  206M 0s
   650K .. .. .. .. .. 97%  247M 0s
   700K .. .  100%  233M=0.2s

2016-09-17 22:40:31 (3.83 MB/s) - 
'debian-installer_20150422+deb8u4+b1_amd64.deb' saved [736654/736654]

sha256sum: debian-installer_20150422+deb8u4+b1_amd64.deb.sha256sum: no properly 
formatted SHA256 checksum lines found
debian/rules:19: recipe for target 'get-images-amd64' failed
make[1]: *** [get-images-amd64] Error 1
make[1]: Leaving directory 

Bug#766914: user-setup: hardware access groups should not be default

2017-01-15 Thread Afif Elghraoui
Hello,

I had #849265 reported against adduser for this problem that exists in
d-i's user-setup. It also exists in adduser if the --add_extra_groups
flags is used (which is why I didn't reassign/merge), user-setup is
adding this groups directly.

See the bug log for 849265 [1], as well as my correspondence with
pkg-systemd [2].

Thanks and regards
Afif

1. http://bugs.debian.org/849265
2.
http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2017-January/013684.html

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name