Bug#844579: console-setup: CyrAsia font missing Kazakh letter

2016-11-16 Thread Baurzhan Muftakhidinov
Package: console-setup

Version: 1.153

Dear maintainers,

Recently I loaded CyrAsia font in console, and have noticed
that it misses one Kazakh letter:

Ұ U+04B0 Cyrillic Capital Letter Straight U with Stroke
ұ U+04B1 Cyrillic Small Letter Straight U with Stroke

I checked these codes in
https://anonscm.debian.org/cgit/d-i/console-setup.git/tree/Fonts/fontsets/CyrAsia.256

Could you please add these to CyrAsia font definition?

Thanks,



Bug#844519: Stretch Alpha 8 Installation Failure

2016-11-16 Thread Michael Owen
On Wed, 16 Nov 2016 15:20:47 +0100 Cyril Brulebois  wrote:
> Hi Michael,
>
> Michael Owen  (2016-11-16):
> > Package: installation-reports
> >
> > Stretch Alpha 8 Installation Failure
> >
> > Boot method: netinst, both Alpha 8 and Daily Build
> > Image version: Alpha 8
> > Date: Multiple times, multiple machines, multiple drives
> >
> > Machine: Gigabyte GA-G31M-ES2K
> > Dell Inspiron 3847
> > Processor: Intel Core2 Duo 7800 (Gigabyte)
> > Intel i3 4th Generation (Dell)
> > Memory: 4 GB DDR2 (Gigabyte)
> > 8 GB DDR3 (Dell)
> > Partitions: sda1 full drive, sda5 (Gigabyte)
> > sda1 and sda5 (Dell)
> > (multiple configurations testing, including full drive single
> > partition)
> >
> > Output of lspci -knn (or lspci -nn):
> >
> > Base System Installation Checklist:
> > [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> >
> > Initial boot: [O]
> > Detect network card: [O]
> > Configure network: [O]
> > Detect CD: [O]
> > Load installer modules: [O]
> > Detect hard drives: [O]
> > Partition hard drives: [O]
> > Install base system: [E]
> > Clock/timezone setup: [O]
> > User/password setup: [O]
> > Install tasks: [ ]
> > Install boot loader: [ ]
> > Overall install: [E]
> >
> > Comments/Problems:
> > Installation fails on base system install with the following error
message:
> > /lib/partman/choose_partition/60partition_tree/do_option: line 88
> > then it states
> > /lib/partman/active_choices/copy/choices: not found
> > then it states
> > debootstrap error 127
> >
> >  > and ideas you had during the initial install.>
> >
> > I get the identical error on both machines and in all possible
> > configurations. The two copies of netinst were full download of
> > netinst and a daily obtained with jigdo with good checksum.
> > The only thing in common between the machines is both have Intel
> > processors with Intel graphics but the Dell is much later version.
>
> Dailies are going to hit #844458 I suppose.
>
Hi Cyril
Yep, I got a hybrid CD 2 times, before all the files were distributed. I
downloaded again and found differences in the file, mainly in the
installer Readme "Archive: unstable" now shows "Archive: stable". So it
must have taken a while for the files to distribute. My hybrid netinst
had "Debian 9" in the upper right corner. That's gone now.

Thanks,
Mike



Processed: tagging 844549

2016-11-16 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 844549 + pending
Bug #844549 [rootskel] network-console broken: no screen to be resumed matching 
sh
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
844549: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844549
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#844549: network-console broken: no screen to be resumed matching sh

2016-11-16 Thread Martin Michlmayr
* Samuel Thibault  [2016-11-16 23:03]:
> But AIUI the intent was to have screen in ssh connections too.

I'm not sure what the intent was.  I assume you're right because Roger
didn't exclude screen from the network-console images.  Personally,
I'm not sure I see the point of screen in that case because you can
always open a second SSH connection and open a terminal, but I don't
have strong feelings either way if there's an advantage of having
screen in such cases.

> I'm also thinking that we perhaps want to add -x when resuming a
> session, so that somebody can connect trough ssh several times ?

Yes because right now I get this when I open a 2nd connection:

debug1: Sending env LC_COLLATE = C
There is a screen on:
1356.network(11/16/16 23:24:12) (Attached)

Apart from this, the patch works for me.

-- 
Martin Michlmayr
http://www.cyrius.com/



Bug#844549: network-console broken: no screen to be resumed matching sh

2016-11-16 Thread Samuel Thibault
Hello,

Martin Michlmayr, on Wed 16 Nov 2016 12:07:07 -0800, wrote:
> I believe below is the right fix, i.e. start screen when screen exists and
> when we're on serial or when we're NOT on network.

But AIUI the intent was to have screen in ssh connections too.

We could have the case where d-i is first started with the serial
console, running through screen, and enable the network console, which
we'd also want to run through screen.

I'd thus say that we rather want the attached changes, to have one
screen session per terminal type.

I'm also thinking that we perhaps want to add -x when resuming a
session, so that somebody can connect trough ssh several times ?

Samuel
diff --git a/src/lib/debian-installer.d/S70menu 
b/src/lib/debian-installer.d/S70menu
index 7b35fac..2549e29 100644
--- a/src/lib/debian-installer.d/S70menu
+++ b/src/lib/debian-installer.d/S70menu
@@ -14,11 +14,11 @@ else
if [ -x "$screen_bin" -a \( "$TERM_TYPE" = network -o "$TERM_TYPE" = 
serial \) -a "$TERM" != dumb ]; then
# there's GNU/screen binary, run menu in it.
# call this script again with in GNU/screen, possibly in UTF-8 
mode
-   SCREEN_OPT=""
+   SCREEN_OPT="-S $TERM_TYPE"
[ -n "$TERM_UTF8" ] &&
SCREEN_OPT="$SCREEN_OPT -U"
-   [ -d /var/run/screen/S-root -a -e /var/run/screen/S-root/* ] &&
-   SCREEN_OPT="-r" # If GNU/screen is already 
started, just resume it
+   [ -d /var/run/screen/S-root -a -e 
/var/run/screen/S-root/*.$TERM_TYPE ] &&
+   SCREEN_OPT="-r $TERM_TYPE"  # If GNU/screen 
is already started, just resume it
set +e
$screen_bin $SCREEN_OPT sh -c 'printf "\033k%s\033\\" installer 
; /lib/debian-installer/menu'
EXIT=$?


Bug#844549: network-console broken: no screen to be resumed matching sh

2016-11-16 Thread Martin Michlmayr
* Ben Hutchings  [2016-11-16 21:15]:
> >     rm -f $font
> > -   if [ -x "$screen_bin" -a \( "$TERM_TYPE" = network -o "$TERM_TYPE" = 
> > serial \) -a "$TERM" != dumb ]; then
> > +   if [ -x "$screen_bin" -a \( "$TERM_TYPE" != network -o "$TERM_TYPE" = 
> > serial \) -a "$TERM" != dumb ]; then
> 
> This makes the comparison with 'serial' redundant; the condition will
> be equivalent to:
> 
> [ -x "$screen_bin" -a "$TERM_TYPE" != network -a "$TERM" != dumb ]
> 
> Is that really what we want?

Oh, good point.

I think that's what we want but I'm not sure.  Maybe Roger can
comment.  In his old code, there was also a $NETBOOT_SCREEN variable
which afaict wasn't set set anywhere.

-- 
Martin Michlmayr
http://www.cyrius.com/



Bug#844549: network-console broken: no screen to be resumed matching sh

2016-11-16 Thread Ben Hutchings
On Wed, 2016-11-16 at 12:07 -0800, Martin Michlmayr wrote:
> Package: rootskel
> Version: 1.119
> Severity: serious
> Tags: patch
> 
> Several users have reported to me that the network-console images are
> broken.
> 
> Commit ec6d3c3d79 (Move screen support) moved the screen support
> around and also changed the logic of when screen is used.
> Unfortunately, that change broke all network-console images which now
> lead to:
> 
> installer@192.168.0.102's password:
> There is no screen to be resumed matching sh.
> Connection to 192.168.0.102 closed.
> 
> This is because d-i is already running in screen on the serial console but
> it's active and can't be resumed.
> 
> I believe below is the right fix, i.e. start screen when screen exists and
> when we're on serial or when we're NOT on network.
> 
> Samuel, Roger, does that look correct?
> 
> diff --git a/src/lib/debian-installer.d/S70menu 
> b/src/lib/debian-installer.d/S70menu
> index 7b35fac..14cad7f 100644
> --- a/src/lib/debian-installer.d/S70menu
> +++ b/src/lib/debian-installer.d/S70menu
> @@ -11,7 +11,7 @@ if [ -x "$bterm" ] && [ -e "$font" ] && [ -n "$TERM_UTF8" ] 
> && [ -n "$TERM_FRAME
>   set -e
>  else
>   rm -f $font
> - if [ -x "$screen_bin" -a \( "$TERM_TYPE" = network -o "$TERM_TYPE" = 
> serial \) -a "$TERM" != dumb ]; then
> + if [ -x "$screen_bin" -a \( "$TERM_TYPE" != network -o "$TERM_TYPE" = 
> serial \) -a "$TERM" != dumb ]; then

This makes the comparison with 'serial' redundant; the condition will
be equivalent to:

[ -x "$screen_bin" -a "$TERM_TYPE" != network -a "$TERM" != dumb ]

Is that really what we want?

Ben.

>   # there's GNU/screen binary, run menu in it.
> >     # call this script again with in GNU/screen, possibly in UTF-8 
> > mode
> >     SCREEN_OPT=""
> 
-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at
once.


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


Bug#844549: network-console broken: no screen to be resumed matching sh

2016-11-16 Thread Martin Michlmayr
Package: rootskel
Version: 1.119
Severity: serious
Tags: patch

Several users have reported to me that the network-console images are
broken.

Commit ec6d3c3d79 (Move screen support) moved the screen support
around and also changed the logic of when screen is used.
Unfortunately, that change broke all network-console images which now
lead to:

installer@192.168.0.102's password:
There is no screen to be resumed matching sh.
Connection to 192.168.0.102 closed.

This is because d-i is already running in screen on the serial console but
it's active and can't be resumed.

I believe below is the right fix, i.e. start screen when screen exists and
when we're on serial or when we're NOT on network.

Samuel, Roger, does that look correct?

diff --git a/src/lib/debian-installer.d/S70menu 
b/src/lib/debian-installer.d/S70menu
index 7b35fac..14cad7f 100644
--- a/src/lib/debian-installer.d/S70menu
+++ b/src/lib/debian-installer.d/S70menu
@@ -11,7 +11,7 @@ if [ -x "$bterm" ] && [ -e "$font" ] && [ -n "$TERM_UTF8" ] 
&& [ -n "$TERM_FRAME
set -e
 else
rm -f $font
-   if [ -x "$screen_bin" -a \( "$TERM_TYPE" = network -o "$TERM_TYPE" = 
serial \) -a "$TERM" != dumb ]; then
+   if [ -x "$screen_bin" -a \( "$TERM_TYPE" != network -o "$TERM_TYPE" = 
serial \) -a "$TERM" != dumb ]; then
# there's GNU/screen binary, run menu in it.
# call this script again with in GNU/screen, possibly in UTF-8 
mode
SCREEN_OPT=""

-- 
Martin Michlmayr
http://www.cyrius.com/



Transporte de Carga de Puertos y Distribución Nacional

2016-11-16 Thread Luis Arriaga - Gerente Comercial
[1] web

[2] nuestros servicios

 forum

[3] contacto

servicios ofrecidos
transmaquina
transporte de carga y alquiler de maquinaria

estimados srs.


quedamos a sus ordenes como proveedores serios y motivados a prestarles un 
excelente servicio en toda venezuela.

en caso de necesitar servicios de:

transporte de carga
alquiler de maquinaria de construcción
alquiler de grúas telescopicas
tansporte de carga extradimensionada
transporte de cemento a granel

reciban un cordial saludo,

luis arriaga
gerente comercial
[4] ven...@transmaquina.com.ve
0424-1362899

[5] www.transmaquina.com.ve

[6] visitar página web

información adicional

cobertura geográfica
prestamos servicios en toda venezuela , ya que trabajamos como aliados en las 
principales ciudades del país.

venta de equipos
prestamos el servicio de venta de equipos. nos encargamos de publicidad de 
venta de camiones, gandolas, maquinaria, grúas y montacargas.
este mensaje fue enviado a t...@test.com por gerencia comercial - luis arriaga
caracas, miranda, venezuela, caracas, miranda  1070, venezuela

cancelar suscripción| administre su suscripción| remitir email| reportar abuso


 References:

1. u=5f04de7
2. u=5f04de7
3. u=5f04de9
4. mailto:ven...@transmaquina.com.ve
5. u=5f04dea
6. u=5f04deb

This message was sent to debian-boot@lists.debian.org by 
vent...@transmaquina.com.ve

You can modify/update your subscription via the link below.

Unsubscribe from all mailings
http://lt.bmetrack.com/c/su?e=A57143=717D3=F60F96B=qbP7iSxRpnAbUS2Pd6XhhwODfNw3Y4%2FbUKEtWoQMMiA%3D=A0B1114


Caracas, Miranda, Venezuela, Caracas, Miranda  1070, Venezuela

Email Marketing
BenchmarkEmail.com
 [http://lt.bmetrack.com]


Bug#844458: bootstrap-base: if debootstrap_script is unset, DEBOOTSTRAP_SCRIPT is set to a directory, breaking the install

2016-11-16 Thread Philip Hands
Cyril Brulebois  writes:

> Control: severity -1 serious
> Control: tag -1 - d-i
>
> Philip Hands  (2016-11-16):
>> Package: bootstrap-base
>> Version: 1.166
>> Severity: important
>> Tags: d-i patch
>> 
>> While testing the daily images, I get this:
>> 
>>   
>> https://jenkins.debian.net/view/lvc/job/lvc_debian-testing-daily/516/artifact/results//00:03:05___gui___minimal___VT__.png
>
> Screenshots don't make it easy/possible to search inside bug reports (and
> mails), and triage bug reports, so it would be nice to include messages
> directly there.

My apologies -- I became over-excited by the fact that this bug was
found by cucumber running on jenkins.debian.net (which is a first!).
I was effectively trying to give it credit.

For posterity (and because at some point that screenshot will probably
get deleted) it said:

=-=-=-=-
  /Base system installation error/

  The debootstrap program exited with an error (return code 127)

  Check /var/log/syslog or see virtual console 4 for details.
=-=-=-=-

(looking at syslog didn't actually shed a great deal of light though,
since it referenced a line number that didn't really indicate the cause
of the problem, or even the file where the error had occured, so rather
than quote all that, I just jumped straight to fixing the bug.  That
being the case, the screenshot was really only there as evidence that
there was a problem, rather than being very useful for diagnosis)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature


Bug#844458: bootstrap-base: if debootstrap_script is unset, DEBOOTSTRAP_SCRIPT is set to a directory, breaking the install

2016-11-16 Thread Philip Hands
Philip Hands  writes:

> Tianon Gravi  writes:
>
>> On 15 November 2016 at 15:36, Philip Hands  wrote:
>>> This seems to have resulted from the recent change to bootstrap-base to
>>> allow the script to be specified only as the codename, but which is not
>>> checking whether the debconf variable is actually set.
>>>
>>> This commit should therefore fix the problem:
>>>
>>>   http://deb.li/iUtYi
>>>
>>> I've applied that change to a broken image by hand, and it does solve the 
>>> problem.
>>
>> Doh, sorry I missed this edge case!
>>
>> For what it's worth, the proposed change looks legit to me. :)
>
> Glad yo like it, but on re-examination, I'm not so sure -- should the
> concatenated path not also be checked to see if it exists?

So, the previous code was:

  db_get base-installer/debootstrap_script
  DEBOOTSTRAP_SCRIPT="$RET"
  if [ ! -e /usr/share/debootstrap/scripts/"$DEBOOTSTRAP_SCRIPT" ]; then
error "debootstrap script '$DEBOOTSTRAP_SCRIPT' doesn't exist"
  fi

which throws an error if base-installer/debootstrap_script is set to a
path that does not exist, but does not throw an error if it is unset (as
long as the /usr/share/debootstrap/scripts/ directory exists).

It seems to me that the commit message for a8b68f8e should have been
"Allow absolute paths ..." because the code already dealt with
codenames, since it was already checking for the existence of:

  /usr/share/debootstrap/scripts/"$DEBOOTSTRAP_SCRIPT"

Looking at the debootstrap code, if this is unset, then there is no $4
so we're going to get the script set to "$DEBOOTSTRAP_DIR/scripts/$1"
(where $1 is the suite), possibly with .$VARIANT added if set.  This
seems to be the default behaviour.

If the debconf variable was set to an absolute path, then I guess the
old code would break, since it unconditionally prefixed the path before
checking for existence.  If it were set to the suite name, then the test
in bootstrap-base.postinst would pass, but debootstrap would then have a
suite name as the script, so the:

  if [ ! -e "$SCRIPT" ]; then

test would fail, so I'm guessing this code never worked.  Is that
actually right?

In light of all that, I think that this commit actually does the right
thing, and is rather more obvious than my previous attempt:

  http://deb.li/3IOXc

(but I still need to test it...)

Cheers, Phil.

P.S. I used the   if ... && [ "$RET" ]   style test because it's
also in use for the variant setting, and in the unlikely event that
base-installer/debootstrap_script were unset, it would still do the
right thing, rather than throwing an error becuase of the set -e.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature


Bug#806273: use grub-mount as the sole source of partition probes (disable kernel readonly mounts)

2016-11-16 Thread Emmanuel Kasper
changes since v1:
 * do not fallback on dangerous read only kernel mounts if grub-mount is
missing, just exit with error



>From 34a2c247fa08d4e01aa08b5b75977c66d71df4f8 Mon Sep 17 00:00:00 2001
From: Emmanuel Kasper 
Date: Tue, 15 Nov 2016 14:52:23 +0100
Subject: [PATCH v2] use grub-mount as the sole source of partition probes
 (disable kernel readonly mounts)

the read only kernel mounts of os-probes caused various data corruption in virtual machines
and exported block devices due to the following chain of event:

 1. os-prober tries to mount via grub-mount each block device as seen from /sys/block
 2. in case of iscsi exported block devices or virtualization environment, such
 a block device could be a whole disk image with a partition table
 3. since grub-mount expects a filesystem superblock but encounters a partition table
 it fails and then give hand to
 4. kernel read only mounts, calling the function ro_partition
 5. the ro_partition function sets the block device readonly via blockdev --setro
 6. a number of kernel mounts are attempted via various kernel modules
 7. the block device is set to readwrite

now when I/O happened on the iscsi initiator or virtual machines between 5-7
the blocks cannot be flushed to the block device since it has been
locked  by os-prober. This causes a filesystem error and the filesystem to be
remounted read only.

since grub-mount is now available on all the platforms debian supports
we assume we can disable the risky behaviour without losing too much os-prober functionnality

grub-mount has also now support for all filesystems which the kernel knows,
the exception being QNX
---
 debian/control   |  2 +-
 os-probes/common/50mounted-tests | 27 +++
 2 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/debian/control b/debian/control
index 10459bd..ac307f5 100644
--- a/debian/control
+++ b/debian/control
@@ -22,7 +22,7 @@ Package: os-prober
 Architecture: any
 Section: utils
 Priority: extra
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, grub-common
 Description: utility to detect other OSes on a set of drives
  This package detects other OSes available on a system and outputs the
  results in a generic machine-readable format.
diff --git a/os-probes/common/50mounted-tests b/os-probes/common/50mounted-tests
index 561163b..8e1c87f 100755
--- a/os-probes/common/50mounted-tests
+++ b/os-probes/common/50mounted-tests
@@ -47,25 +47,20 @@ fi
 
 mounted=
 if type grub-mount >/dev/null 2>&1 && \
-   type grub-probe >/dev/null 2>&1 && \
-   grub-mount "$partition" "$tmpmnt" 2>/dev/null; then
-	mounted=1
-	type="$(grub-probe -d "$partition" -t fs)" || true
-	if [ "$type" ]; then
-		debug "mounted using GRUB $type filesystem driver"
-	else
-		debug "mounted using GRUB, but unknown filesystem?"
+   type grub-probe >/dev/null 2>&1; then
+	if grub-mount "$partition" "$tmpmnt" 2>/dev/null; then
+		mounted=1
+		type="$(grub-probe -d "$partition" -t fs)" || true
+		if [ "$type" ]; then
+			debug "mounted using GRUB $type filesystem driver"
+		else
+			debug "mounted using GRUB, but unknown filesystem?"
 		type=fuseblk
+		fi
 	fi
 else
-	ro_partition "$partition"
-	for type in $types $delaytypes; do
-		if mount -o ro -t "$type" "$partition" "$tmpmnt" 2>/dev/null; then
-			debug "mounted as $type filesystem"
-			mounted=1
-			break
-		fi
-	done
+	echo "Cannot find grub-mount (Try installing grub-common)" >&2
+	exit 1
 fi
 
 if [ "$mounted" ]; then
-- 
2.1.4



Bug#844519: Stretch Alpha 8 Installation Failure

2016-11-16 Thread Cyril Brulebois
Hi Michael,

Michael Owen  (2016-11-16):
> Package: installation-reports
> 
> Stretch Alpha 8 Installation Failure
> 
> Boot method: netinst, both Alpha 8 and Daily Build
> Image version: Alpha 8
> Date: Multiple times, multiple machines, multiple drives
> 
> Machine: Gigabyte GA-G31M-ES2K
>  Dell Inspiron 3847
> Processor: Intel Core2 Duo 7800 (Gigabyte)
>Intel i3 4th Generation (Dell)
> Memory: 4 GB DDR2 (Gigabyte)
> 8 GB DDR3 (Dell)
> Partitions: sda1 full drive, sda5 (Gigabyte)
> sda1 and sda5 (Dell)
> (multiple configurations testing, including full drive single
> partition)
> 
> Output of lspci -knn (or lspci -nn):
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [O]
> Detect CD:  [O]
> Load installer modules: [O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[E]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Install tasks:  [ ]
> Install boot loader:[ ]
> Overall install:[E]
> 
> Comments/Problems:
> Installation fails on base system install with the following error message:
> /lib/partman/choose_partition/60partition_tree/do_option: line 88
> then it states
> /lib/partman/active_choices/copy/choices: not found
> then it states
> debootstrap error 127
> 
>and ideas you had during the initial install.>
> 
> I get the identical error on both machines and in all possible
> configurations. The two copies of netinst were full download of
> netinst and a daily obtained with jigdo with good checksum.
> The only thing in common between the machines is both have Intel
> processors with Intel graphics but the Dell is much later version.

Dailies are going to hit #844458 I suppose.

Are you getting the exact same error with Stretch Alpha 8? That would be
rather curious since the above mentioned bug should only be in code
available in unstable, rather than testing.

It'd be nice to get a full /var/log/syslog from such an installation
attempt (feel free to compress it so that it doesn't get munged by
mailing list software).


KiBi.


signature.asc
Description: Digital signature


Bug#844458: bootstrap-base: if debootstrap_script is unset, DEBOOTSTRAP_SCRIPT is set to a directory, breaking the install

2016-11-16 Thread Cyril Brulebois
Control: severity -1 serious
Control: tag -1 - d-i

Philip Hands  (2016-11-16):
> Package: bootstrap-base
> Version: 1.166
> Severity: important
> Tags: d-i patch
> 
> While testing the daily images, I get this:
> 
>   
> https://jenkins.debian.net/view/lvc/job/lvc_debian-testing-daily/516/artifact/results//00:03:05___gui___minimal___VT__.png

Screenshots don't make it easy/possible to search inside bug reports (and
mails), and triage bug reports, so it would be nice to include messages
directly there.

> which after looking into it, seems to be caused by the fact that the
> debootstrap_script one would hope to be used is not actually set, but
> instead it is set to the directory that contains the scripts.
> 
> This seems to have resulted from the recent change to bootstrap-base to
> allow the script to be specified only as the codename, but which is not
> checking whether the debconf variable is actually set.
> 
> This commit should therefore fix the problem:
> 
>   http://deb.li/iUtYi
> 
> I've applied that change to a broken image by hand, and it does solve
> the problem.

Bumping severity to make sure this version doesn't reach testing.


KiBi.


signature.asc
Description: Digital signature


Processed: Re: Bug#844458: bootstrap-base: if debootstrap_script is unset, DEBOOTSTRAP_SCRIPT is set to a directory, breaking the install

2016-11-16 Thread Debian Bug Tracking System
Processing control commands:

> severity -1 serious
Bug #844458 [bootstrap-base] bootstrap-base: if debootstrap_script is unset, 
DEBOOTSTRAP_SCRIPT is set to a directory, breaking the install
Severity set to 'serious' from 'important'
> tag -1 - d-i
Bug #844458 [bootstrap-base] bootstrap-base: if debootstrap_script is unset, 
DEBOOTSTRAP_SCRIPT is set to a directory, breaking the install
Removed tag(s) d-i.

-- 
844458: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844458
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#844519: Stretch Alpha 8 Installation Failure

2016-11-16 Thread Michael Owen
Package: installation-reports

Stretch Alpha 8 Installation Failure

Boot method: netinst, both Alpha 8 and Daily Build
Image version: Alpha 8
Date: Multiple times, multiple machines, multiple drives

Machine: Gigabyte GA-G31M-ES2K
 Dell Inspiron 3847
Processor: Intel Core2 Duo 7800 (Gigabyte)
   Intel i3 4th Generation (Dell)
Memory: 4 GB DDR2 (Gigabyte)
8 GB DDR3 (Dell)
Partitions: sda1 full drive, sda5 (Gigabyte)
sda1 and sda5 (Dell)
(multiple configurations testing, including full drive single
partition)

Output of lspci -knn (or lspci -nn):

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[E]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[E]

Comments/Problems:
Installation fails on base system install with the following error message:
/lib/partman/choose_partition/60partition_tree/do_option: line 88
then it states
/lib/partman/active_choices/copy/choices: not found
then it states
debootstrap error 127



I get the identical error on both machines and in all possible
configurations. The two copies
of netinst were full download of netinst and a daily obtained with jigdo
with good checksum.
The only thing in common between the machines is both have Intel
processors with Intel graphics
but the Dell is much later version.



partman-partitioning_114_i386.changes ACCEPTED into unstable

2016-11-16 Thread Debian FTP Masters


Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 16 Nov 2016 06:47:57 +0100
Source: partman-partitioning
Binary: partman-partitioning
Architecture: source i386
Version: 114
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 partman-partitioning - Partitioning operations for partman (udeb)
Closes: 815916
Changes:
 partman-partitioning (114) unstable; urgency=medium
 .
   [ Viktor Mihajlovski ]
   * In case a disk is identified as type=dasd, make sure to preserve
 this in the disk label. (Closes: #815916)
 Requires partman-base 190.
Checksums-Sha1:
 55b1f28ed758b2c23cabb1fdac3a5ef50d842c85 1680 partman-partitioning_114.dsc
 6de42f2519d84f8e7908d2ebc67dbe44d310c78a 175972 partman-partitioning_114.tar.xz
 a215a5e150ea4c13585e5357d3fdc2f486efecca 4596 
partman-partitioning_114_20161116T074137z-f219f2d0.buildinfo
 d0befd640b7c59586f6cd6533643a3a4576d2830 189420 
partman-partitioning_114_i386.udeb
Checksums-Sha256:
 79dfaef08d79375adcf254c8b2d22fe453896e5220d37fbb64c5a202a14233c7 1680 
partman-partitioning_114.dsc
 adc6428127b8d6f8485a7a6e265a4ff2298b851d4fd0ffb805d804441e630cb8 175972 
partman-partitioning_114.tar.xz
 3d31f1ff3760835e63a05e921e08350c53fc08cb87e6a9cfb702e14aa1a3a208 4596 
partman-partitioning_114_20161116T074137z-f219f2d0.buildinfo
 7dd8ef3a9a07898d43c7d5611166b942fcb4110af02011c0d1a2021123b63314 189420 
partman-partitioning_114_i386.udeb
Files:
 72fa9d67caa5123e99be6f04aebdf0f3 1680 debian-installer optional 
partman-partitioning_114.dsc
 c20eef15df5d4e32dd75558b61870d80 175972 debian-installer optional 
partman-partitioning_114.tar.xz
 f219f2d0f2681a32f8b077b9ddf214e5 4596 debian-installer optional 
partman-partitioning_114_20161116T074137z-f219f2d0.buildinfo
 a6c2a21068b6af95688fa635d2ee91ff 189420 debian-installer optional 
partman-partitioning_114_i386.udeb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJYLA8uAAoJEIcvcCxNbiWob9MQAIcknJsicHwxO1+Nn+D0NlhR
2U/Gj0eNfgx0CacfNyAWB2o5vLCULi60ZU5vE9ao1C4Zg1TXhBKvHi3fEAdoknky
47dE2KtYePiQp7RXDeFmNsN7TpvYx4XopVKhLSZ6t5fjnP1R1C7YzmVKui+Z72sU
8y2CPU+hFD1ta8Ubywpd2yAZwhiNpDAgNYSvH4Bhg7Jng32i3Na5gZ0CCA9YxKSm
tcrYE9AA7wvmRBNH8Yy+LYF40tffJ0UCcOcKrLSCNnGyRAGkSP2NafTIORlybJPG
e5C5fKkr2Mo0q0sfyDebw6X5a7F/AGLejndyEle77HZq9UuEx1TG+wlC6ShapcQx
LIOsFh3PbZi01yy3s+MHr7hzo9cZnk4oazCzWHfsMhdtvW41B6i9KPD/ZD1vxJxK
XyH+4m2reD//84PDuULS928NgqBRXGvo/GOoubvBACr9rla5AQ1ro0PW3gAQDxy+
+FlBht75vKKeYtYh68LVhIhztTiobcBvZCtP5i2jZtzCSg/dBdyk9PgVewBSgYFI
0v3fVzftroYBR2+CPDVAqd0KZDBcEzSbuCnBeGUY0K346mAy/nsnqdwRjOrxy35P
u9OiWz7MhWJsm8Mv0dRtnoLRuFdhFAdmtBYHd51Wt4IOXRJyOLJ/S5CxI5Q5h9TB
VaY5sPl/W9IZcQIAHVq9
=wo8c
-END PGP SIGNATURE-


Thank you for your contribution to Debian.



Bug#815916: marked as done (Failure to create empty partition table on s390 DASD)

2016-11-16 Thread Debian Bug Tracking System
Your message dated Wed, 16 Nov 2016 09:21:00 +
with message-id 
and subject line Bug#815916: fixed in partman-partitioning 114
has caused the Debian Bug report #815916,
regarding Failure to create empty partition table on s390 DASD
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.)


-- 
815916: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815916
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: partman-partitioning
Version: 111
Severity: important
Tags: d-i patch
X-Debbugs-CC: debian-s...@lists.debian.org, brueck...@linux.vnet.ibm.com

Dear Maintainer,

when I try to create an empty partition table on a DASD, the
partitioning code instructs parted to write an msdos label instead of a
dasd label to the disk. This is effectively destroying the volume
metadata rendering the disk unusable. The disk can only be recovered by
low level formatting.

This is caused by the default label determination logic in
partman-partitioning/lib/disk-label.sh which only uses the architecture
to decide which default label to use.
We can't switch that unconditionally to dasd, because we would break
SCSI (and most of virtio) partitioning.

The suggested patches make sure the disk type is respected and the
appropriate label type is used:
Patch 1 is for d-i/partman-base and stores the disk label type in
/var/lib/partman/devices//label, which will be dasd for natively
attached DASDs as well as virtio attached DASDs in KVM.
Patch 2 is a change in d-i/partman-partitioning and uses the stored
label type to determine the proper partition table format (only when
executing on s390).

Thanks for your consideration.

-- 

Kind Regards
   Viktor Mihajlovski

>From 6d71c4fb3eb679a5df4e1aa3028f0e6d6ec5df19 Mon Sep 17 00:00:00 2001
From: Viktor Mihajlovski 
Date: Tue, 23 Feb 2016 15:23:21 +0100
Subject: [PATCH] parted_devices: Add disk label type to device directory

At least for s390 the default disk label type is device
dependent. We record the current disk label type in the
/var/lib/partman/devices/ for later retrieval.

Signed-off-by: Viktor Mihajlovski 
---
 init.d/parted| 2 ++
 parted_devices.c | 7 +--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/init.d/parted b/init.d/parted
index 81cdafc..6f96b07 100755
--- a/init.d/parted
+++ b/init.d/parted
@@ -87,6 +87,7 @@ if [ ! -f /var/run/parted_server.pid ]; then
 		device=$1
 		size=$2
 		model=$3
+		label=$4
 
 		# Skip mtd (not supported by parted) and mmcblk odities
 		case "${device#/dev/}" in
@@ -130,6 +131,7 @@ if [ ! -f /var/run/parted_server.pid ]; then
 		printf "%s" "$device" >$dev/device
 		printf "%s" "$size" >$dev/size
 		printf "%s" "$model" >$dev/model
+		printf "%s" "$label" >$dev/label
 
 		# Set the sataraid flag for dmraid arrays.
 		if type dmraid >/dev/null 2>&1 && \
diff --git a/parted_devices.c b/parted_devices.c
index de15355..4fc64c7 100644
--- a/parted_devices.c
+++ b/parted_devices.c
@@ -76,6 +76,7 @@ is_floppy(const char *path)
 void
 process_device(PedDevice *dev)
 {
+	PedDisk *disk;
 	if (dev->read_only)
 		return;
 	if (is_cdrom(dev->path) || is_floppy(dev->path))
@@ -84,10 +85,12 @@ process_device(PedDevice *dev)
 	if (strstr(dev->path, "/dev/ramzswap") != NULL ||
 	strstr(dev->path, "/dev/zram") != NULL)
 		return;
-	printf("%s\t%lli\t%s\n",
+	disk = ped_disk_new(dev);
+	printf("%s\t%lli\t%s\t%s\n",
 	   dev->path,
 	   dev->length * dev->sector_size,
-	   dev->model);
+	   dev->model,
+	   disk->type->name ? disk->type->name : "unknown");
 }
 
 int
-- 
1.9.1

>From 38daa8b0d78607139aa66b225ae9c4ab04daf3be Mon Sep 17 00:00:00 2001
From: Viktor Mihajlovski 
Date: Tue, 23 Feb 2016 15:33:45 +0100
Subject: [PATCH] create_new_label: Use correct label for DASDs

Requires an updated partman-base. In case a disk is indentified
as DASD, make sure that the default disk label is "dasd".

Signed-off-by: Viktor Mihajlovski 
---
 lib/disk-label.sh | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lib/disk-label.sh b/lib/disk-label.sh
index b24f4a8..167f3c3 100644
--- a/lib/disk-label.sh
+++ b/lib/disk-label.sh
@@ -118,7 +118,13 @@ default_disk_label () {
 	ppc64el)
 		echo gpt;;
 	s390|s390x)
-		echo msdos;;
+		if [ -e ./label ]; then
+		disklabel=$(cat label)
+		fi
+		if [ "$disklabel" != dasd ]; then
+		disklabel=msdos
+		fi
+		echo $disklabel;;
 	sh4)
 		echo msdos;;
 	sparc|sparc64)
-- 
1.9.1


Processing of partman-partitioning_114_i386.changes

2016-11-16 Thread Debian FTP Masters
partman-partitioning_114_i386.changes uploaded successfully to localhost
along with the files:
  partman-partitioning_114.dsc
  partman-partitioning_114.tar.xz
  partman-partitioning_114_20161116T074137z-f219f2d0.buildinfo
  partman-partitioning_114_i386.udeb

Greetings,

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



debootstrap_1.0.87_i386.changes ACCEPTED into unstable

2016-11-16 Thread Debian FTP Masters


Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 16 Nov 2016 06:47:27 +0100
Source: debootstrap
Binary: debootstrap debootstrap-udeb
Architecture: source all
Version: 1.0.87
Distribution: unstable
Urgency: high
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 debootstrap - Bootstrap a basic Debian system
 debootstrap-udeb - Bootstrap the Debian system (udeb)
Closes: 796189 844221
Changes:
 debootstrap (1.0.87) unstable; urgency=high
 .
   [ Julien Cristau ]
   * Default to split /usr again, as merged-/usr breaks dpkg-shlibdeps
 (closes: #844221).
 .
   [ Riku Voipio ]
   * remove scratchbox2 support (closes: #796189)
Checksums-Sha1:
 e817e83772e37f11dc9b63fb10ba10fb6e96d416 1777 debootstrap_1.0.87.dsc
 1869a70482119c1616e0332117d21735b3384909 65875 debootstrap_1.0.87.tar.gz
 a4a6b11c7411a23e4fb18790d92f5b2961c6da2f 18924 debootstrap-udeb_1.0.87_all.udeb
 1c1f4b42cfdf6a972061f94bb7e8cf2ffce72447 4791 
debootstrap_1.0.87_20161116T055108z-355da9aa.buildinfo
 deb9e849da6ab5d9461f2673193cfb6f04474cba 66220 debootstrap_1.0.87_all.deb
Checksums-Sha256:
 e6161875b958b9e1133a32ec734eb7e54e4d48ed3dceccefd8c815ce34f19d80 1777 
debootstrap_1.0.87.dsc
 e48c931b8c0a4981c580db1a85418177bf62f18320a376aefbc7910e1f1fb3aa 65875 
debootstrap_1.0.87.tar.gz
 784f5754f3287ae80715d9100a4ed04e7895be5f7b81b7b2295d335dd69d79fb 18924 
debootstrap-udeb_1.0.87_all.udeb
 96000167397211d0f33e4b5bfb0ae2572cf40b053cb498c2a82c9c0f4b558919 4791 
debootstrap_1.0.87_20161116T055108z-355da9aa.buildinfo
 a5f2d34a8f7bd28bb983024409a08f78725be8cddaef9af4734993e78df3b1fb 66220 
debootstrap_1.0.87_all.deb
Files:
 7fbbf28549a3d76e5072b2850fa755ff 1777 admin extra debootstrap_1.0.87.dsc
 50c04a3f08b146c210d61721b4cf4284 65875 admin extra debootstrap_1.0.87.tar.gz
 a784b02ef9f04a6706201fecb141a8e3 18924 debian-installer extra 
debootstrap-udeb_1.0.87_all.udeb
 355da9aa28b909d5659eb5bf7b2de786 4791 admin extra 
debootstrap_1.0.87_20161116T055108z-355da9aa.buildinfo
 36dfb524118e75581441d644b525f4ba 66220 admin extra debootstrap_1.0.87_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJYLA0rAAoJEIcvcCxNbiWomwoP/19UlZVqH2eHxilg8DhNWBXu
EsU45cRATxu+BXQAoGe9uE/gUqva9nJ3JNhCB45Nxz9liqlZPtbgBhObMxGTpdve
I55RqOl9+f4f6Gabl3Hwc6cI/NqVw5pAkAgaMrGl8XTm1RWjCwuYPlWBhpy2SEku
TUvclrsLE9Jnw+7GbgPMR7/XvP8nLzUqCojgOWspFrL/0UtXfMw64t6HLRAfBRlN
8wUtD3vIfqkyoTrQXUakJXwMqvjne9fmWDumg6iRd6Jne3lj76br99adirlAjDqA
jerd5Sm/uaY2W9z+SAgsYg6wIo2c0oEra/l+EbUYneF1yAvFEHr2KyqI4FqSkUXZ
GhEKKf1CMFgfFOEqyl81HAqCWvmJVGvnudCs9sS5BDptkfp/GiN0jsiGERnyG2tE
8lIFchZxYueO5i6oI3r+YBdTSX/jdBVLF+hT8n3edIJVE+7ryoRc2hnSLHt6sAiP
ewSj6DA3GEooPeAcycqV3vfLc/YLL/btduCxIbHnyFTRQW8zFJ01GYWzboT41B+m
AA8LQEp6MIrKhY8hjClu9ZVie5HT+FyxtNUh7IPlhq6xCWSWwDXpXuAU0leUeCQq
KxOB3fEuw2XTYYXGgUEeh6L0BPd1VAPwNq1hY1Ko9IPPYY8xIZjGCq17wAlBnCrv
QTox4oWfIfDB5NSJHkEu
=+GuZ
-END PGP SIGNATURE-


Thank you for your contribution to Debian.



Processing of debootstrap_1.0.87_i386.changes

2016-11-16 Thread Debian FTP Masters
debootstrap_1.0.87_i386.changes uploaded successfully to localhost
along with the files:
  debootstrap_1.0.87.dsc
  debootstrap_1.0.87.tar.gz
  debootstrap-udeb_1.0.87_all.udeb
  debootstrap_1.0.87_20161116T055108z-355da9aa.buildinfo
  debootstrap_1.0.87_all.deb

Greetings,

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