debian-installer-launcher_26_source.changes REJECTED

[Debian FTP Masters]

Version check failed:
Your upload included the source package debian-installer-launcher, version 26,
however testing already has version 26.
Uploads to unstable must have a higher version than present in testing.



===

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

Processing of debian-installer-launcher_26_source.changes

[Debian FTP Masters]

debian-installer-launcher_26_source.changes uploaded successfully to localhost
along with the files:
  debian-installer-launcher_26.dsc
  debian-installer-launcher_26.tar.xz

Greetings,

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

Re: Planning for d-i Stretch Alpha 9

[Cyril Brulebois]

Hi,

Cyril Brulebois  (2016-11-21):
> Ben Hutchings  (2016-11-20):
> > Yes, there will be an ABI bump in the next upload to unstable
> > (probably within the next week).
> 
> Thanks! I'll wait for that to happen & migrate to testing before
> preparing for the next d-i release.

FWIW linux migrated a few days ago so I'll start working on a release
as soon as my free time permits. Probably somewhen around Christmas.

As usual (sadly) I'm way behind reading/checking what happens on
debian-boot@ so feel free to mention specific things you would want me
to notice, through a mail cc'd to .


KiBi.


signature.asc
Description: Digital signature

Bug#839595: flash-kernel: Please add support for SolidRun Clearfog

[Martin Michlmayr]

I was just looking at this bug report and it seems Karsten was never
copied on Christoph's last email (see below).

* Christoph Egger  [2016-10-24 15:22]:
> Hi!
> 
> This seems to be the "new" default environment:
> 
> => printenv
> arch=arm
> baudrate=115200
> board=clearfog
> board_name=clearfog
> boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} 
> ${prefix}${script}; source ${scriptaddr}
> boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} 
> efi/boot/bootarm.efi; if fdt addr ${fdt_addr_r}; then bootefi 
> ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} 
> ${fdtcontroladdr};fi
> boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any 
> ${scriptaddr} ${prefix}extlinux/extlinux.conf
> boot_net_usb_start=usb start
> boot_prefixes=/ /boot/
> boot_script_dhcp=boot.scr.uimg
> boot_scripts=boot.scr.uimg boot.scr
> boot_targets=mmc0 usb0 pxe dhcp 
> bootcmd=run distro_bootcmd
> bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} 
> ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile 
> ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile 
> ${soc}-${board}${boardver}.dtb; fi; setenv efi_old_vci ${bootp_vci};setenv 
> efi_old_arch ${bootp_arch};setenv bootp_vci 
> PXEClient:Arch:00010:UNDI:003000;setenv bootp_arch 0xa;if dhcp 
> ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr 
> ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi 
> ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci 
> ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv 
> efi_old_arch;setenv efi_old_vci;
> bootcmd_mmc0=setenv devnum 0; run mmc_boot
> bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
> bootcmd_usb0=setenv devnum 0; run usb_boot
> bootdelay=3
> console=ttyS0,115200
> cpu=armv7
> devnum=0
> devplist=1
> devtype=mmc
> distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
> efi_dtb_prefixes=/ /dtb/ /dtb/current/
> fdt_addr_r=0x10
> fdt_high=0x1000
> fdtcontroladdr=3fb4ce58
> fdtfile=armada-388-clearfog.dtb
> initrd_high=0x1000
> kernel_addr_r=0x80
> load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} 
> ${prefix}${efi_fdtfile}
> mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run 
> scan_dev_for_boot_part; fi
> pxefile_addr_r=0x30
> ramdisk_addr_r=0x180
> scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; 
> for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run 
> scan_dev_for_scripts; done;run scan_dev_for_efi;
> scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env 
> exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do 
> if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run 
> scan_dev_for_boot; fi; done
> scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n 
> "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; for 
> prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} 
> ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; 
> fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} 
> efi/boot/bootarm.efi; then echo Found EFI removable media binary 
> efi/boot/bootarm.efi; run boot_efi_binary; echo EFI LOAD FAILED: 
> continuing...; fi; setenv efi_fdtfile
> scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} 
> ${prefix}extlinux/extlinux.conf; then echo Found 
> ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: 
> continuing...; fi
> scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} 
> ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot 
> script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: 
> continuing...; fi; done
> scriptaddr=0x20
> soc=mvebu
> stderr=serial@12000
> stdin=serial@12000
> stdout=serial@12000
> usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run 
> scan_dev_for_boot_part; fi
> vendor=solidrun
> 
> Environment size: 3819/65532 bytes
> 
> 
> -- 
> 9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
> Debian Developer | Lisp Hacker | CaCert Assurer

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

Bug#845779: flash-kernel: flashkernel uses mkimage -A arm on arm64

[Martin Michlmayr]

* Heinrich Schuchardt  [2016-11-26 16:54]:
> I want to get the Hardkernel Odroid C2 supported by flash-kernel.
> 
> It is a 64bit system.
> 
> Unfortunately in file /usr/share/flash-kernel/functions the functions
> mkimage_kernel() and mkimage_initrd() both call mkimage with argument
> 
>  -A arm .
> 
> This is incorrect. On 64bit arm systems you have to use
> 
>  -A arm64 .
> 
> Otherwise neither u-boot nor the kernel can read the images.

Your latest patch looks fine to me but I'm wondering why this is
needed in the first place.

On modern devices, we no longer wrap the kernel and initrd into an
u-boot image, but we boot it directly using bootz (arm) or booti
(arm64).

I see there's also one "mkimage -A arm" call to generate the boot
script.  Is that's what causing you the problem?

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

Bug#806926: Bug#766400: installation-reports: [armhf] Netgear ReadyNAS104 report

[Martin Michlmayr]

Hi Uwe,

Can you review your old Netgear ReadyNAS 102/104 patch for
flash-kernel and apply them?

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

Bug#836679: flash-kernel: cannot configure kernel 4.7 with new flash-kernel

[Martin Michlmayr]

* Ian Campbell  [2016-10-01 08:29]:
> > Looking at the code, all uses of find_dtb_file() check for the result
> > and produce an error if the file doesn't exist, so maybe we should
> > just move the error messages into find_dtb_file().  Then we could
> > tell
> > the user where we were looking.
> > 
> > Ian, any comments?
> 
> Nope, sounds sensible to me!
> 
> Looks like handle_dtb() doesn't produce an error if the file doesn't
> exist -- but it probably should. Need to take care in the postrm.d case
> (where the file might legitimately not be there) though -- fortunately
> it looks like the result of find_dtb_file isn't actually used in that
> half of the if, so it could probably be moved.

Sorry for the delay (again!).  I finally looked into this again.
I came up with the patch below and I get:

> Using DTB: XXXarmada-370-seagate-personal-cloud.dtb
> Couldn't find DTB XXXarmada-370-seagate-personal-cloud.dtb in 
> /usr/lib/linux-image-4.9.0-rc8-armmp or /etc/flash-kernel/dtbs

So that part looks good.

But then I get:

> Installing  into 
> /boot/dtbs/4.9.0-rc8-armmp/XXXarmada-370-seagate-personal-cloud.dtb
> cp: cannot stat '': No such file or directory

It seems the exit called from find_dtb_file() doesn't exit the whole
program.  I know this is normal because it's called in a subshell, but
flash-kernel itself does a "set -e" so I thought any exit should
trigger the whole script to stop.

Ian, any idea?

Here's the patch so far:

diff --git a/functions b/functions
index e050269..acc1a33 100644
--- a/functions
+++ b/functions
@@ -249,7 +249,7 @@ get_dtb_name() {
;;
esac
if [ -n "$dtb_name" ] ; then
-   echo "DTB: $dtb_name" >&2
+   echo "Using DTB: $dtb_name" >&2
fi
 }
 
@@ -561,18 +561,25 @@ android_flash() {
 }
 
 find_dtb_file() {
+   local dtb
case "$dtb_name" in
/*)
-   echo "$dtb_name"
+   dtb="$dtb_name"
+   if [ ! -f "$dtb" ]; then
+   error "Couldn't find $dtb"
+   fi
;;
*)
-   local dtb=$(find /etc/flash-kernel/dtbs -name $dtb_name 
2>/dev/null | head -n 1)
+   dtb=$(find /etc/flash-kernel/dtbs -name $dtb_name 2>/dev/null | 
head -n 1)
if [ -z "$dtb" ]; then
dtb=$(find /usr/lib/linux-image-$kvers -name $dtb_name 
2>/dev/null | head -n 1)
fi
-   echo $dtb
+   if [ ! -f "$dtb" ]; then
+   error "Couldn't find DTB $dtb_name in 
/usr/lib/linux-image-$kvers or /etc/flash-kernel/dtbs"
+   fi
;;
esac
+   echo $dtb
 }
 
 handle_dtb() {
@@ -580,9 +587,8 @@ handle_dtb() {
return
fi
 
-   local dtb=$(find_dtb_file)
-   local dtb_name=$(basename $dtb_name)
if [ "x$FK_KERNEL_HOOK_SCRIPT" = "xpostrm.d" ] ; then
+   local dtb_name=$(basename $dtb_name)
rm -f "/boot/dtbs/$kvers/$dtb_name"
 
# This was the old name we installed under. We
@@ -606,26 +612,24 @@ handle_dtb() {
rmdir --ignore-fail-on-non-empty /boot/dtbs
fi
else
-   if [ -e "$dtb" ]; then
-   echo "Installing $dtb into /boot/dtbs/$kvers/$dtb_name" 
>&2
-   mkdir -p /boot/dtbs/$kvers/
-   cp "$dtb" "/boot/dtbs/$kvers/$dtb_name.new"
-   backup_and_install \
-   "/boot/dtbs/$kvers/$dtb_name.new" \
-   "/boot/dtbs/$kvers/$dtb_name"
-
-   # Historically we installed the dtb as
-   # dtb-$kvers, keep it around as an alternative
-   # for now. Useful for platforms which do not
-   # set ${fdtfile}
-   ln -nfs "dtbs/$kvers/$dtb_name" "/boot/dtb-$kvers"
-
-   # This can be used along with the unversioned
-   # vmlinuz+initrd.gz e.g. as a fallback option
-   ln -nfs "dtbs/$kvers/$dtb_name" "/boot/dtb"
-   else
-   error "Couldn't find $dtb"
-   fi
+   local dtb=$(find_dtb_file)
+   local dtb_name=$(basename $dtb_name)
+   echo "Installing $dtb into /boot/dtbs/$kvers/$dtb_name" >&2
+   mkdir -p /boot/dtbs/$kvers/
+   cp "$dtb" "/boot/dtbs/$kvers/$dtb_name.new"
+   backup_and_install \
+   "/boot/dtbs/$kvers/$dtb_name.new" \
+   "/boot/dtbs/$kvers/$dtb_name"
+
+   # Historically we installed the dtb as
+   # dtb-$kvers, keep it around as an alternative
+   # for now. Useful for platforms which do not
+   # set ${fdtfile}
+   ln -nfs "dtbs/$kvers/$dtb_name" 

Bug#789886: linux-image-3.2.0-4-kirkwood: Couldn't find /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb

[Martin Michlmayr]

It seems I never applied this patch because I was waiting for Ian to
review it.

Ian, do you have some time to look at the proposed patch?

* Martin Michlmayr  [2016-08-05 19:46]:
> * Jesse Adelman  [2015-06-20 20:35]:
> > When I upgrade this package on my Debian Wheezy Sheevaplug, I get this 
> > error:
> > 
> > Couldn't find /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb
> 
> > Full log:
> > 
> > flash-kernel: installing version 3.2.0-4-kirkwood
> > Generating kernel u-boot image... done.
> > Taking backup of uImage.
> > Installing new uImage.
> > Generating initramfs u-boot image... done.
> > Taking backup of uInitrd.
> > Installing new uInitrd.
> > Couldn't find /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb
> > dpkg: error processing package flash-kernel (--configure):
> >  subprocess installed post-installation script returned error exit status 1
> 
> Sorry for the delay in responding to this bug.  I believe I know what
> the issue is.  I've copied Ian Campbell who knows the code best.
> 
> Ian, I've attached a proposed patch below.  Do you agree with the
> logic described or am I missing something?
> 
> The log also shows:
> 
> > update-initramfs: Generating /boot/initrd.img-3.2.0-4-kirkwood
> > /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb not found
> > /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb not found
> 
> I'm not sure where this is from but it seems isn't not causing an
> actual error.
> 
> 
> Only create DTB boot file on kernels that require DTB
> 
> Boot-DTB-Path can be specified to install the DTB to a file.  Some
> machines, such as the SheevaPlug, contain both a DTB-Append-From and
> a Boot-DTB-Path.
> 
> If DTB-Append-From is set, a verson check is performed to see if the
> DTB is required and dtb_append is set to "yes" or "no" accordingly.
> However, there is no version check for Boot-DTB-Path.  This can lead
> to errors that the DTB couldn't be found on older kernels (i.e. older
> than the version specified in DTB-Append-From).
> 
> Arguably, DTB-Append-From and Boot-DTB-Path together don't make sense
> (why would you append the DTB _and_ install it to /boot), but it's
> possible that users rely on this behaviour.
> 
> Therefore, only honour Boot-DTB-Path if $dtb_append is not "no".  If
> it's "yes" or empty, we want to install the DTB to Boot-DTB-Path.
> But if $dtb_append is "no", it means we're on an old kernel without
> DTBs.
> 
> diff --git a/functions b/functions
> index 368cbf2..c4ef6a3 100644
> --- a/functions
> +++ b/functions
> @@ -939,7 +939,7 @@ case "$method" in
>   boot_script="$tmpdir/boot.scr"
>   backup_and_install "$boot_script" "$boot_script_path"
>   fi
> - if [ -n "$boot_dtb_path" ]; then
> + if [ -n "$boot_dtb_path" ] && [ "$dtb_append" != "no" ]; then
>   boot_dtb_path="$boot_mnt_dir/$boot_dtb_path"
>   boot_dtb=$(find_dtb_file)
>   if [ ! -f "$boot_dtb" ]; then
> 
> -- 
> Martin Michlmayr
> http://www.cyrius.com/

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

Bug#847267: Updating the discover-data Uploaders list

[Gaudenz Steinlin]

Package: discover-data
Version: 2.2013.01.11
Followup-For: Bug #847267

Please also remove myself from the uploaders list. I have not done any
work on the package in recent years.

Thanks,
Gaudenz

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

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

discover-data depends on no packages.

Versions of packages discover-data recommends:
ii  pciutils  1:3.5.2-1

discover-data suggests no packages.

-- no debconf information

Bug#848424: Please remove me from uploaders

[Gaudenz Steinlin]

Package: discover
Version: 2.1.2-7
Severity: wishlist

Please remove my name from the uploaders filed. I haven't done any work
on this package for years. As I have been removed from the pkg-discover
alioth group I cannot do this myself.

Thanks,
Gaudenz

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

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

Versions of packages discover depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.24-8
ii  libdiscover2   2.1.2-7
ii  libexpat1  2.2.0-1
ii  libusb-0.1-4   2:0.1.12-30

discover recommends no packages.

Versions of packages discover suggests:
ii  lsb-base  9.20161125

-- debconf information excluded

Re: daily (weekly?) builds of d-i manual

[Baptiste Jammet]

Bonjour, 

Dixit Holger Wansing, le 15/12/2016 :

>Today, I performed a "non-local" build, which means files have been
>uploaded to alioth, and https://d-i.alioth.debian.org/manual/ has been
>updated. 
>
>Yeah!!!
>
>I intend to build the manual periodically again now.
>Not daily, as the svn repo may indicate, but something like once per
>week.

Great, thanks a lot !

Baptiste


pgpZWsBFs9IPi.pgp
Description: OpenPGP digital signature