from:"Ian Campbell"

Bug#773991: flash-kernel: Fails when mtdblock kernel module isn't loaded

2015-01-02 Thread Ian Campbell

On Fri, 2015-01-02 at 11:09 +0100, Uwe Kleine-König wrote:
 Hello Ian,
 
  Uwe, any chance you could try this please:
 
  diff --git a/functions b/functions
  index d45a4e6..a7ff6de 100644
  --- a/functions
  +++ b/functions
  @@ -41,7 +41,11 @@ error() {
mtdblock() {
  local mtdname=$1
 
  -   sed -rn s,^mtd([^:]*).*\$mtdname\\$,/dev/mtdblock\\1,p $PROC_MTD
  +   local dev=`sed -rn s,^mtd([^:]*).*\$mtdname\\$,/dev/mtdblock\\1,p 
  $PROC_MTD`
  +
  +   modprobe -q mtdblock  udevadm settle --exit-if-exists=$dev || :
  +
  +   echo $dev
 I would have added the modprobe call only if the device doesn't exist, 
 but I guess that's only cosmetic.

modprobe will silently do nothing if the module is already loaded or is
builtin so not checking is fine plus is simpler. There's also a benign
TOCTOU race with checking for the device first (from something else
modprobing in parallel).

 I just installed flash-kernel 3.30 and as expected this one works fine.

Thanks.

 Sorry I didn't come around to test this earlier, I was AFK most of the 
 time around Christmas/new year. Thanks for your work on this bug.

No problem.

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774138: grub-efi-amd64: Update freeze with kernel oops for EFI (2.02~beta2-{18 - 19})

2014-12-31 Thread Ian Campbell

On Tue, 2014-12-30 at 21:32 +0100, Axel Angel wrote:
 @@ -7511,7 +7511,6 @@
  grub-install: info: executing efibootmgr --version /dev/null /dev/null.
  grub-install: info: executing modprobe -q efivars.
  grub-install: info: executing efibootmgr -c -d /dev/sda -p 1 -w -L debian -l 
 \EFI\debian\grubx64.efi.
 -
 -Could not prepare boot variable: No such file or directory
 -
 +efibootmgr: Could not set variable Boot: No such file or directory
 +efibootmgr: Could not prepare boot variable: No such file or directory
  Installation finished. No error reported.

Was this in the state where things crashed or the working state (but
with the second issue you mentioned occurring)?

[...]
 So, I tried many things and found that indeed the new version is not the
 source of the problem. In fact the system before the upgrade exhibits the
 same problem under a simple condition: when the system was resumed from
 disk. I found that everything is fine when it is freshly booted,
 whichever the version -18 or -19.

I think there is a pretty good chance that this is therefore a firmware
issue. I'd recommend the first thing to try would be to see if an
updated firmware is available for your system and if so then install it.

Your kernel stack trace shows that the CPU has tried to execute code
from a region of RAM which has been marked non-executable when calling
into the firmware. I'm not familiar enough with EFI to know if
responsibility for this lies with the firmware or the kernel and have a
feeling it might be the two in concert.

You might find that adding noexec=off to your kernel command line
worksaround this issue.

 I upgraded all the package again and reproduced my problem with -19.
 I have the kernel log when it crashed but not the log of grub-install
 because it froze immediately this time, I couldn't save it. I have a
 photo of the last lines nonetheless, that may help.
 
 Moreover it has been since a few months that efibootmgr didn't work
 properly for my motherboard. I noticed that since it broke, efibootmgr
 deletes every boot entries, moreover its own is not visible afterward. I
 had to place the grub binary myself into the generic location
 /boot/efi/EFI/BOOT/BOOTx64.efi to make my system boots, and it works.

Sounds like a firmware issue to me, if an upgrade doesn't help I'd
recommend to start by reporting against efibootmgr.

 I own a thinkpad x220 and indeed I don't suffer these problems. That
 means either one of these: as you said the firmware is bugged or the
 support for my MB is not fully complete.
 
 I am no expert on the matter, if you have any clue whether I should
 report it to an other package like efibootmgr or how can I find more
 informations?

Once you've updated the firmware I think I'd suggest starting by
reassigning this crash issue to the Linux package (I can help with the
mechanics of that if you need). The thing about the delete boot entries
probably ought to start with efibootmgr (I could clone this report, but
I think a fresh one dedicated to that issue would be better).

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764162: Regression with kernel 3.16.7-ckt2-1

2014-12-31 Thread Ian Campbell

On Wed, 2014-12-31 at 06:08 -0200, Rogério Brito wrote:
 unarchive 764162
 found 764162 3.16.7-ckt2-1
 notfound 764162 3.16.7-2
 thanks
 
 Hi.
 
 I have a Kurobox Pro that I use as a NAS and I was affected by the network
 corruption when the TSO was enabled in versions 3.16 before the version with
 the workaround on the mv643xx_eth (not having seen the code, from a user's
 perspective, this workaround was more like a fix than a dirty hack).

The workaround was just turning off the feature.

Please can you clarify which of these kernels did/didn't work (or for
which you have no data):
  * 3.16.7-1 (has the bug)
  * 3.16.7-2 (with the hack/workaround of disabling TSO by default)
  * 3.16.7-ckt2-1 (with the supposed proper fix, 2c2a9cb from
upstream, backported via the -ckt tree)

FWIW I am running 3.16.7-ckt2-1 on my kirkwood based ts-419 right now
and it seems fine. It's possible that your system has a separate issue
or is somehow more susceptible to the original (Which IIRC was cache
based, so could affect different platforms differently).

Please can you also confirm that flash-kernel has been run and is
picking up the correct kernel image, i.e. it hasn't installed an old
kernel for you or something like that. uname -v includes the actual
running version.

 Can we get a fix for this in time for jessie?

If one can be found of course we will try and apply it.

Since I can't reproduce it would be useful if you could take this issue
to the upstream developers who were involved in the original bug report
and work with them directly to find a cure.

If we can't find one then I suppose we will fall back to just disabling
TSO by default on these systems.

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774138: grub-efi-amd64: Update freeze with kernel oops for EFI (2.02~beta2-{18 - 19})

2014-12-31 Thread Ian Campbell

On Wed, 2014-12-31 at 12:08 +0100, Axel Angel wrote:

  You might find that adding noexec=off to your kernel command line
  worksaround this issue.
 
 I can give it a try. Question: isn't it dangerous to enable this flag in
 normal use? I guess so.

It's not really dangerous as such, there would be a slight decrease in
resistance to certain classes of security vulnerability is all.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773561: Installing xen-linux-system-amd64 on jessie fails

2014-12-30 Thread Ian Campbell

Hi Sydney,

Thanks for all the info. I'd like to have the initscript work sensibly
in this scenario at some point (not for Jessie though, it's too late
now) so I think we may as well keep this bug around to track that since
it already contains a bunch of useful information.

Thanks,
Ian.

On Tue, 2014-12-30 at 00:39 +0100, Sydney Meyer wrote:
 Hello Ian,
 
 i´ve tried to install xen-linux-system-amd64 on a VMware host again and 
 everything went fine. The Installation completes and i can boot into Xen und 
 boot up the Dom0.
 
 So, you were right. It seems to be a problem with the initscript, but as far 
 as i can tell, only when running xen under xen.
 
 To me, this specific issue is resolved, since the meta-package seems to 
 install just fine, apart when running under Xen, which would be another, 
 separate issue I think. 
 
 But then again, since Nested Virtualization is experimental on almost every 
 platform, this is no problem to me or to my usecase.
 
 Anyhow, if you still would like to take a deeper look, i'm happy to help out 
 whereever i can, otherwise, you can mark this bug as resolved.
 
 Cheers,
 S.
 
  On 30 Dec 2014, at 00:20, Sydney Meyer syd.me...@gmail.com wrote:
  
  
  On 23 Dec 2014, at 12:59, Ian Campbell i...@debian.org wrote:
  
  Control: reassign -1 xen-utils-common 4.4.1-6
  Control: retitle -1 /etc/init.d/xen fails when run in a guest, causing 
  postinst to fail.
  
  Seems like this issue is in the Xen packages not in the xen-linux-system
  metapackage, so reassigning.
  
  On Mon, 2014-12-22 at 23:01 +0100, Sydney Meyer wrote:
  On 22 Dec 2014, at 17:25, Ian Campbell i...@debian.org wrote:
  
  On Sat, 2014-12-20 at 20:46 +0100, Sydney Meyer wrote:
  Hello Ian,
  
  systemctl status xen.service gives:
  
  Thanks. Sadly these logs weren't as informative a I had hoped they would
  be :-/ (In case it's not clear: this is not your fault)
  
  root@jessie:/home/sydney# systemctl status xen.service
  ● xen.service - LSB: Xen daemons
  Loaded: loaded (/etc/init.d/xen)
  Active: failed (Result: exit-code) since Sat 2014-12-20 20:42:30 CET; 
  11s ago
  Process: 4796 ExecStart=/etc/init.d/xen start (code=exited, status=255)
  
  Dec 20 20:42:30 jessie xen[4796]: Starting Xen daemons: xenfs (warning).
  Dec 20 20:42:30 jessie systemd[1]: xen.service: control process exited, 
  code=exited status=255
  Dec 20 20:42:30 jessie systemd[1]: Failed to start LSB: Xen daemons.
  Dec 20 20:42:30 jessie systemd[1]: Unit xen.service entered failed 
  state.
  
  This basically says it failed, which isn't terribly helpful!
  
  I think it is complaining because it couldn't mount xenfs, but it
  doesn't say why.
  
  If you run /etc/init.d/xen start from the root command line does it
  say something more informative/useful?
  
  No, it fails and refers to systemctl/journalctl:
  
  OK.
  
  root@jessie:/home/sydney# /etc/init.d/xen start
  [] Starting xen (via systemctl): xen.serviceJob for xen.service 
  failed. See 'systemctl status xen.service' and 'journalctl -xn' for 
  details.
  failed!
  
  Could you also try running /usr/lib/xen-common/bin/xen-dir
  and /usr/lib/xen-common/bin/xen-toolstack by hand (also as root).
  
  root@jessie:/home/sydney# /usr/lib/xen-common/bin/xen-dir
  /usr/lib/xen-4.4
  
  root@jessie:/home/sydney# /usr/lib/xen-common/bin/xen-toolstack
  /usr/lib/xen-4.4/bin/xl
  
  Thanks, so it thinks it is running under Xen (which given what you say
  below makes sense).
  
  What (if anything) does mount -t xenfs xenfs /proc/xen report?
  Does /proc/xen exist?
  
  root@xen:/home/sydney# mount -t xenfs xenfs /proc/xen
  mount: xenfs is already mounted or /proc/xen busy
xenfs is already mounted on /proc/xen
  
  Yes, this particular output is from a Xen DomU with vmx enabled. The
  Dom0 is running Xen 4.4.1 compiled from source on a Debian Linux
  3.16.2 Kernel.
  
  Thanks, this would have been good to know up front. I suppose you are
  wanting to do some sort of nested virtualisation?
  
  actually no, this was just for testing purposes, I never expected the 
  Hypervisor to do any real work.
  
  You are likely the
  first to try this with the Debian packaging, and nested virt generally
  is considered tech preview upstream, so I'd expect there to be some
  wrinkles in doing this.
  
  By with vmx enabled I guess you mean with nestedhvm=1 in the guest
  cfg? Are you running this in a PV or HVM guest (I think HVM)? Can you
  post the dmesg from the kernel please, along with the guest cfg file.
  
  root@intel:/home/sydney# cat xencfg/xen.cfg
  name='xen'
  builder=hvm
  vnc=1
  vncdisplay=84
  vncpasswd=test
  keymap=de
  vcpus = 1
  memory = 2048
  hap=1
  nestedhvm=1
  disk= [
   'phy:/dev/vgssd/xen,xvda,w',
   ]
  vif= [
   'mac=00:16:3E:8B:84:CC,bridge=br0.6',
   ]
  
  
  
  root@xen:/home/sydney# journalctl -k --boot
  -- Logs begin at Mon 2014-12-29 23:55:59 CET, end at Mon 2014-12

Bug#767261: xen-netback changes in #767261 break Mini-OS netfront

2014-12-29 Thread Ian Campbell

On Mon, 2014-12-29 at 13:42 +0100, Martin Lucina wrote:
 However, I can't find a full final list of which fixes were backported.

FWIW they are in the source package in debian/patches/series.

 Given that the last traffic on #767261 was on November 9th, I suspect at
 least this upstream change from December 18 did NOT make it into the new
 linux-image package:
 
 xen-netback: support frontends without feature-rx-notify again
 26c0e102585d5a4d311f5d6eb7f524d288e7f6b7 [2]

Yes, I very much suspect this is needed too and will fix your problem.
I'll look into it shortly.

 I can't verify this 100% as I don't know where in the archive I can find
 the original 3.16.7-2 linux-image to downgrade to/compare the Debian diffs.

snapshot.debian.org has all historical versions of all packages.

 Should I reopen #767261 or file a new bug for this?

A new bug would be best please.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard

2014-12-29 Thread Ian Campbell

On Mon, 2014-12-29 at 10:17 +0800, Chen Baozi wrote:
  On Dec 28, 2014, at 17:08, Ian Campbell i...@debian.org wrote:
  
  On Fri, 2014-12-26 at 18:43 +0800, Chen Baozi wrote:
  
  With the attached patch applied, debian installer (tested with 
  network-console)
  can support OMAP5's ethernet driver and external MicroSD card.
  
  Note that I added related regulator  phy entries to files that mainly 
  writes
  the modules which use them, since there is no file dedicated to those
  modules.
  
  Do you know if phy-ti-pipe3 is used exclusively by USB or just only
  within the set of things used in the d-i context? Likewise the two
  regulators added to mmc?
 
 So far as I can tell from DTS, there are two types of modules use
 phy-ti-pipe3, which are ‘usb3’ and ‘sata’. But I am not quite sure
 how the hardware modules are connected.
 
 And pbias seems be only meaningful to mmc, and palmas relates to many
 other devices of the board.

Thanks. I think palmas is a candidate to be built in then. I'll do that.

I'm not entirely sure what to do about phy-ti-pipe3, you've added it to
usb-modules but I suppose SATA won't necessarily work if we do that. I
think I'd be inclined to build it in for now rather than make drastic
changes to the udebs for Jessie.
 
Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel

2014-12-29 Thread Ian Campbell

On Sun, 2014-12-28 at 23:02 -0600, Robert Nelson wrote:
On Sun, Dec 28, 2014 at 10:00 PM, Vagrant Cascadian vagr...@debian.org
wrote:
On 2014-12-28, Robert Nelson wrote:
On Sun, Dec 28, 2014 at 6:26 PM, Vagrant Cascadian vagr...@debian.org
wrote:
On 2014-12-28, Ian Campbell wrote:
OOI, do you know how broken the white is when booting with the black's
DTB? Completely unusable, missing some minor peripheral or somewhere in
the middle?
...
Oh you definitely don't want to run the wrong *.dtb on the black/white..

In u-boot the findfdt function will correctly set the fdtfile variable.

http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l176

Notice:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?id=2ba3549352277514a8e4790adff77a783ee1b9e2

IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI
transceiver after a dozen boots with an uSD card inserted because LDO
will be at 3.3V instead of 1.8.

Also the 'white' uses DDR2, while the 'black uses DDR3

Ok, so given that it might actually damage hardware to run with the
wrong dtb, I've written up a few UNTESTED patches to support multiple
DTB-Id entries:

* copy a .dtb file to /boot in addition to the /boot/dtb-${version}
file, named using the ${fdtfile} variable.

While reviewing I noticed one little gottcha.. This is more of a blame
squarely at u-boot..

imx targets use:

fdt_file

http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/wandboard.h;h=809017c5fe225278c87619e237fd0905b9c1dcf1;hb=HEAD#l140

omap targets use:

fdtfile

Isn't that awesome. ;)

According to u-boot's README imx is in the wrong here, since only
fdtfile is documented. I think f-k should follow that lead and only
worry about fdtfile, at least until we have a concrete reason to worry
about the imx one.

Ian.

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel

2014-12-29 Thread Ian Campbell

On Sun, 2014-12-28 at 20:00 -0800, Vagrant Cascadian wrote:
On 2014-12-28, Robert Nelson wrote:
On Sun, Dec 28, 2014 at 6:26 PM, Vagrant Cascadian vagr...@debian.org
wrote:
On 2014-12-28, Ian Campbell wrote:
OOI, do you know how broken the white is when booting with the black's
DTB? Completely unusable, missing some minor peripheral or somewhere in
the middle?
...
Oh you definitely don't want to run the wrong *.dtb on the black/white..

Is it dangerous both way around or only dangerous to boot the black dtb
on the white?

In u-boot the findfdt function will correctly set the fdtfile variable.

http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l176

Notice:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?id=2ba3549352277514a8e4790adff77a783ee1b9e2

IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI
transceiver after a dozen boots with an uSD card inserted because LDO
will be at 3.3V instead of 1.8.

Also the 'white' uses DDR2, while the 'black uses DDR3

Is white==am335x-bone.dts or is there a third unsuffixed variant too? (I
think the answer is no, but I'm not sure). I'm wondering if we should
try to upstream a patch to make the white also unambiguously identify
itself as such, by adding White to the model and the dts name.

Did we support Beaglebone* in Wheezy or is it all new in Jessie (IOW to
what extent can we fudge the upgrade path and just rip the plaster off
now).

[...]
These might be a bit invasive for this point in the release cycle, but
they also aren't terribly large patches... I can do some further
testing if it seems like the approach is worth pursuing at this point.

It is a little bit invasive, I was hoping not to be making large changes
(i.e. anything more than db updates) to f-k at this point. But perhaps
it is the best we can do.

Given the beaglebone specific findfdt which Robert links to above could
we add a check to bootscr.beaglebone which refuses to boot on a white?
(looks like we can look at $board_name directly).

Ian.

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773991: flash-kernel: Fails when mtdblock kernel module isn't loaded

2014-12-29 Thread Ian Campbell

On Fri, 2014-12-26 at 20:30 +0100, Uwe Kleine-König wrote:
 I wonder if flash-kernel should be smart enough to
 load the module itself.

I think it should.

I think all which is needed is to add modprobe -q mtdblock into the
mtdblock function. I believe anything which uses an mtdblock device
passes through that function to translate the name into a device node.

What do you think?

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773991: flash-kernel: Fails when mtdblock kernel module isn't loaded

2014-12-29 Thread Ian Campbell

On Mon, 2014-12-29 at 14:50 +0100, Ben Hutchings wrote:
 On Mon, 2014-12-29 at 13:24 +, Ian Campbell wrote:
  On Fri, 2014-12-26 at 20:30 +0100, Uwe Kleine-König wrote:
   I wonder if flash-kernel should be smart enough to
   load the module itself.
  
  I think it should.
  
  I think all which is needed is to add modprobe -q mtdblock into the
  mtdblock function. I believe anything which uses an mtdblock device
  passes through that function to translate the name into a device node.
  
  What do you think?
 
 You also need 'udevadm settle' to wait for the device nodes to appear.

Good point, thanks.

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774138: grub-efi-amd64: Update freeze with kernel oops for EFI (2.02~beta2-{18 - 19})

2014-12-29 Thread Ian Campbell

On Mon, 2014-12-29 at 11:30 +0100, Axel wrote:
 Package: grub-efi-amd64
 Version: 2.02~beta2-19
 Severity: important
 
 Dear Maintainer,
 
* What led up to the situation?
  Usual daily upgrade. Including grub-efi-amd64:
 2.02~beta2-18 - 2.02~beta2-19~i

(is ~i a typo here?)

The functional changes between -18 and -19 were pretty minor, just:
+  * Handle case insensitivity of VFAT filesystem on /boot/EFI when installing
+extra cpoy of grub-efi to the removable media path
+/boot/efi/EFI/BOOT/BOOT$ARCH.EFI (Closes: #773092)
+  * Make the force_efi_extra_removable debconf prompt only show up when
+configuring grub-*efi*. Closes: #773004
plus a boatload of translation updates.

The second on is obviously not the problem and since your debconf data
contains :
  grub2/force_efi_extra_removable: false
I think none of the code involved in the first case will be getting run
for you. So I think you are probably correct to consider other things
which have been upgraded as in your follow up.

Could you try running grub-install -v please.

Please could you also try downgrading this and some of the other
packages which you think might be at fault one at a time to see if you
can nail the culprit.

Another possibility is that the firmware is a bit b0rked wrt efivars
handling (I've heard some nasty things about some firmwares in this
regard) and its just a coincidence that this was the upgrade which
triggered it.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773991: flash-kernel: Fails when mtdblock kernel module isn't loaded

2014-12-29 Thread Ian Campbell

On Mon, 2014-12-29 at 13:58 +, Ian Campbell wrote:
 On Mon, 2014-12-29 at 14:50 +0100, Ben Hutchings wrote:
  On Mon, 2014-12-29 at 13:24 +, Ian Campbell wrote:
   On Fri, 2014-12-26 at 20:30 +0100, Uwe Kleine-König wrote:
I wonder if flash-kernel should be smart enough to
load the module itself.
   
   I think it should.
   
   I think all which is needed is to add modprobe -q mtdblock into the
   mtdblock function. I believe anything which uses an mtdblock device
   passes through that function to translate the name into a device node.
   
   What do you think?
  
  You also need 'udevadm settle' to wait for the device nodes to appear.
 
 Good point, thanks.

Uwe, any chance you could try this please:

diff --git a/functions b/functions
index d45a4e6..a7ff6de 100644
--- a/functions
+++ b/functions
@@ -41,7 +41,11 @@ error() {
 mtdblock() {
local mtdname=$1
 
-   sed -rn s,^mtd([^:]*).*\$mtdname\\$,/dev/mtdblock\\1,p $PROC_MTD
+   local dev=`sed -rn s,^mtd([^:]*).*\$mtdname\\$,/dev/mtdblock\\1,p 
$PROC_MTD`
+
+   modprobe -q mtdblock  udevadm settle --exit-if-exists=$dev || :
+
+   echo $dev
 }
 
 check_block_dev() {


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767261: xen-netback changes in #767261 break Mini-OS netfront

2014-12-29 Thread Ian Campbell

On Mon, 2014-12-29 at 12:56 +, Ian Campbell wrote:

  Should I reopen #767261 or file a new bug for this?
 
 A new bug would be best please.

Actually, no need for this, I've applied the fixes locally and am just
building them before pushing.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard

2014-12-29 Thread Ian Campbell

On Fri, 2014-12-26 at 18:43 +0800, Chen Baozi wrote:
 On Tue, Dec 23, 2014 at 7:44 PM, Ian Campbell i...@debian.org wrote:
  On Tue, 2014-12-23 at 16:27 +0800, Chen Baozi wrote:
  I have a glance at the kernel’s installer configs and tried the netboot
  without any modification. Some work should be done to make debian-installer
  support OMAP5 uEVM (e.g., ethernet driver etc).
 
  Right, those should be listed in e.g.
  debian/installer/armhf/modules/armhf-armmp/nic-modules.
 
  By waiting the kernel building with some initial attempted configs added,
  just one question to ask. I looked through the
  debian/installer/armhf/modules/armhf-armmp/, but it looks like none of
  files is about regulator modules. However, according to my previous
  experience, missing regulator driver modules is the main reason that
  the old debian kernel doesn’t support OMAP5 uEVM. How does debian-installer
  deal with this situation (if it does need extra regulator drivers 
  included?)
 
  Long term its a bit of an open question what we do wrt modules such as
  regulators, clocks, pinctrl etc.
 
  So far we have been a bit lucky: either such things are so central to
  the platform that it is acceptable (at least for now) to just build them
  into the main kernel binary by making them =y (e.g. CONFIG_I2C_S3C2410
  which is for the main power controller on arndale) or they are closely
  associated with some particular device and it makes sense to put them in
  that udeb (e.g. phy-exynos5250-sata in sata-modules, or phy-sun4i-usb in
  usb-modules).
 
  Eventually I expect that we will end up creating separate udebs for
  these things, but I'm hoping that we can defer that until at least
  Stretch to avoid needing to mess around with any more new packages for
  Jessie.
 
  If uEVM has some module which either shouldn't be built in or isn't
  obviously associated with a particular device let us know what it is and
  we can have a think about how best to approach it.
 
  One thing I've played with, and I'm not sure if this is acceptable or
  not, is to put core drivers which aren't =y into the kernel-image udeb
  itself. I'm not really sure if that's a good idea, we don't currently do
  this for anything AFAIK, but it's perhaps an option.
 
 With the attached patch applied, debian installer (tested with 
 network-console)
 can support OMAP5's ethernet driver and external MicroSD card.
 
 Note that I added related regulator  phy entries to files that mainly writes
 the modules which use them, since there is no file dedicated to those
 modules.

Here is what I went with (am build testing now, will push to svn once
done):

commit e05093889458a806352d3e281b2f20db098925fb
Author: Ian Campbell i...@debian.org
Date:   Mon Dec 29 14:36:47 2014 +

Updates to udebs for OMAP5432 uEVM support.

Based on a patch from Chen Baozi. Added pbias-regulator to mmc-modules and
ohci-omap3, ehci-omap and phy-omap-usb2 to usb-modules (dwc3-omap was 
already
present).

Enabled CONFIG_REGULATOR_PALMAS and CONFIG_TI_PIPE3 as builtin since they 
are
used by multiple subsystems.

diff --git a/debian/config/armhf/config.armmp b/debian/config/armhf/config.armmp
index 8781e59..62e512f 100644
--- a/debian/config/armhf/config.armmp
+++ b/debian/config/armhf/config.armmp
@@ -579,7 +579,7 @@ CONFIG_PCI_MVEBU=y
 ##
 CONFIG_OMAP_CONTROL_PHY=m
 CONFIG_OMAP_USB2=m
-CONFIG_TI_PIPE3=m
+CONFIG_TI_PIPE3=y
 CONFIG_TWL4030_USB=m
 CONFIG_PHY_EXYNOS5250_SATA=m
 CONFIG_PHY_SUN4I_USB=m
@@ -638,7 +638,7 @@ CONFIG_REGULATOR_TWL4030=y
 CONFIG_REGULATOR_VEXPRESS=m
 CONFIG_REGULATOR_PBIAS=m
 CONFIG_REGULATOR_TI_ABB=m
-CONFIG_REGULATOR_PALMAS=m
+CONFIG_REGULATOR_PALMAS=y
 
 ##
 ## file: drivers/rtc/Kconfig
diff --git a/debian/installer/armhf/modules/armhf-armmp/mmc-modules 
b/debian/installer/armhf/modules/armhf-armmp/mmc-modules
index 5718bd2..6ebd458 100644
--- a/debian/installer/armhf/modules/armhf-armmp/mmc-modules
+++ b/debian/installer/armhf/modules/armhf-armmp/mmc-modules
@@ -4,3 +4,4 @@ mmci
 omap_hsmmc
 sunxi-mmc
 dw_mmc-exynos
+pbias-regulator
diff --git a/debian/installer/armhf/modules/armhf-armmp/usb-modules 
b/debian/installer/armhf/modules/armhf-armmp/usb-modules
index 0828c55..f00b24f 100644
--- a/debian/installer/armhf/modules/armhf-armmp/usb-modules
+++ b/debian/installer/armhf/modules/armhf-armmp/usb-modules
@@ -3,7 +3,10 @@ phy-sun4i-usb
 dwc3-exynos
 dwc3-omap
 ohci-exynos
+ohci-omap3
 ehci-exynos
+ehci-omap
 phy-exynos-usb2
+phy-omap-usb2
 ci_hdrc_imx
 phy-mxs-usb



 
 Baozi.
 
 ---
 diff -Nru linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/mmc-modules
 linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/mmc-modules
 --- linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/mmc-modules
 2014-09-21 20:04:21.0 +
 +++ linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/mmc-modules
 2014-12-26 03:16:02.0 +
 @@ -4,3 +4,5 @@
  omap_hsmmc
  sunxi-mmc
  dw_mmc-exynos
 +pbias-regulator

Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel

2014-12-29 Thread Ian Campbell

On Mon, 2014-12-29 at 08:41 -0600, Robert Nelson wrote:
On Mon, Dec 29, 2014 at 7:13 AM, Ian Campbell i...@debian.org wrote:
On Sun, 2014-12-28 at 20:00 -0800, Vagrant Cascadian wrote:
On 2014-12-28, Robert Nelson wrote:
On Sun, Dec 28, 2014 at 6:26 PM, Vagrant Cascadian vagr...@debian.org
wrote:
On 2014-12-28, Ian Campbell wrote:
OOI, do you know how broken the white is when booting with the black's
DTB? Completely unusable, missing some minor peripheral or somewhere in
the middle?
...
Oh you definitely don't want to run the wrong *.dtb on the black/white..

Is it dangerous both way around or only dangerous to boot the black dtb
on the white?

A quick scan of the dtb's.. The microSD would be limited to 1.8v (3.3v
removed), so users could find themselves with a broken boot if they
booted am335x-boneblack on a classic bone.

I'm not as worried about boot failures as I am about setting fire to the
board. As I understand it:

Booting with am335x-boneblack.dtb on a Beaglebone White
= Might fail to boot
Booting with am335x-bone.dtb on a Beaglebone Black
= Might destroy the HDMI controller

So if we are going to err one way or another then always using boneblack
dtb is the safe option of the two. Which conveniently fits in with the
fact that we so far only support the Black, and it's the one everyone
has anyway.

Given all that I think it would be acceptable given the freeze etc to
just add the new name for the Black to the existing stanza.

In u-boot the findfdt function will correctly set the fdtfile variable.

http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l176

Notice:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?id=2ba3549352277514a8e4790adff77a783ee1b9e2

IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI
transceiver after a dozen boots with an uSD card inserted because LDO
will be at 3.3V instead of 1.8.

Also the 'white' uses DDR2, while the 'black uses DDR3

Officially by beagleboard.org they've always been called:

BeagleBone : am335x-bone.dtb
BeagleBone Black : am335x-boneblack.dtb

Unofficially, the community started calling the original BeagleBone as
the 'white' as the number of users with 'Black''s massively out number
the 'white'... Confusion entailed..

OK, so probably trying to make any changes at all would only make things
worse...

There's also the blue oem version, which is just the black with a
few oem changes, but uses the black's eeprom id...

Did we support Beaglebone* in Wheezy or is it all new in Jessie (IOW to
what extent can we fudge the upgrade path and just rip the plaster off
now).

The beaglebone's were not truly usable on mainline till v3.11-rc or
so, due to the edma/dma engine changes needed to support the mmc
interface.

OK, so we are only dealing with people running testing/sid and not
stable upgrades, which gives us some more options if we are really
stuck, but from the sounds of it we aren't really.

Ian.

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel

2014-12-29 Thread Ian Campbell

On Mon, 2014-12-29 at 08:48 -0800, Vagrant Cascadian wrote:
 On 2014-12-29, Ian Campbell wrote:
  Given the beaglebone specific findfdt which Robert links to above
 
 Several other ti platforms also use findfdt, FWIW.
 
 
  could we add a check to bootscr.beaglebone which refuses to boot on a
  white?  (looks like we can look at $board_name directly).
 
 Yes, that should work. The standard boot command runs findfdt before
 loading the boot script. So, something along these lines:

Thanks, lets go with this plus the one new line for the machine id then.
Was this snippet tested?

[...]

 Although, ideally, this case should be detected before the user reboots,
 so they can manually tweak /etc/flash-kernel/ to use a customized boot
 script.

Indeed, but that would be a lot more complex I think, so we won't be
able to make that work for Jessie, and if the BB White is rare anyway...

BTW, the flash-kernel currently in experimental can run a script to
obtain the DTB-Id. If it is possible to programatically spot the
difference between the various beagle boards then that might be one way
to approach it in the future.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774131: Missing kernel modules (mini.iso / Jessie / amd64)

2014-12-29 Thread Ian Campbell

On Mon, 2014-12-29 at 18:23 +0100, Andreas Meile wrote:
 Hello Ben
 
  You're using an old netboot image and this failure is expected.
 
 Thanks for your reply. I exactly supposed the same issue (obsoleted 
 mini.iso).
 
 The actual problem is not a developement issue, it's an issue that some 
 folders on the official FTP sources are not updated. For example the folder
 
 http://mirror.switch.ch/ftp/mirror/debian/dists/testing/main/installer-amd64/current/images/netboot/
 
 (same on any other mirror) still contains the obsolete mini.iso

This is, for better or worse, expected behaviour when using the
installer from the testing suite.

When a new kernel ABI propagates to testing then the installer is
invalidated until the next installer release, which may not follow for
some time depending on schedules etc.

The workaround during such periods is to use the daily installer builds
from http://d-i.debian.org/daily-images/ .

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767261: xen-netback changes in #767261 break Mini-OS netfront

2014-12-29 Thread Ian Campbell

On Mon, 2014-12-29 at 16:56 +0100, Martin Lucina wrote:
 i...@debian.org said:
  On Mon, 2014-12-29 at 12:56 +, Ian Campbell wrote:
  
Should I reopen #767261 or file a new bug for this?
   
   A new bug would be best please.
  
  Actually, no need for this, I've applied the fixes locally and am just
  building them before pushing.
 
 Thanks. I can test the packages once they're ready.

They are being uploaded to
https://people.debian.org/~ijc/tmp/linux/3.16.7-ckt2-2~xen0/ right now.
I've not booted them myself.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel

2014-12-29 Thread Ian Campbell

On Mon, 2014-12-29 at 12:56 -0800, Vagrant Cascadian wrote:
 On 2014-12-29, Ian Campbell wrote:
  On Mon, 2014-12-29 at 08:48 -0800, Vagrant Cascadian wrote:
  On 2014-12-29, Ian Campbell wrote:
   could we add a check to bootscr.beaglebone which refuses to boot on a
   white?  (looks like we can look at $board_name directly).
  
  Yes, that should work. The standard boot command runs findfdt before
  loading the boot script. So, something along these lines:
 
  Thanks, lets go with this plus the one new line for the machine id then.
  Was this snippet tested?
 
 I tested that it works on the BeagleBone Black, and also when board_name
 is set to A335BONE, it sleeps for 10 seconds and then exits, but I don't
 have a BeagleBone white to test with.

Good enough for me, thanks.

I've pushed the patch at the end to flash-kernel.git.

  BTW, the flash-kernel currently in experimental can run a script to
  obtain the DTB-Id. If it is possible to programatically spot the
  difference between the various beagle boards then that might be one way
  to approach it in the future.
 
 Robert Nelson pointed out that the BeagleBone white has 256MB of ram,
 and the BeagleBone Black all have 512MB of ram, so /proc/meminfo is a
 pretty reliable test:
 
   memtotal=$(awk '/MemTotal:/{print $2}' /proc/meminfo)
   test $memtotal -lt 30  echo white || echo black

Thanks, lets try and remember this if someone shows up asking for White
support...

Cheers,
Ian.

commit 053b567dd81a206bd478281d714298d5c71c24d1
Author: Ian Campbell i...@debian.org
Date:   Mon Dec 29 23:22:02 2014 +

Support for alternative machine name for BeagleBone Black.

The old name was ambiguous with the original BeagleBone (often called 
White),
detect if booting on a BeagleBone white and print an error since the DTB 
will
be wrong. We don't currently support the White. (Closes: #773890, which
contains full background).

diff --git a/bootscript/bootscr.beaglebone b/bootscript/bootscr.beaglebone
index a0e5121..1d079f8 100644
--- a/bootscript/bootscr.beaglebone
+++ b/bootscript/bootscr.beaglebone
@@ -1,4 +1,14 @@
-# boot script for BeagleBone
+# boot script for BeagleBone Black
+
+# BeagleBone white uses a different .dtb file, and flash-kernel is
+# currently unable to support multiple .dtb files.
+if test ${board_name} = A335BONE
+then
+  echo BeagleBone white detected, unsupported platform.
+  echo Exiting in 10 seconds...
+  sleep 10
+  exit
+fi
 
 setenv device mmc
 setenv partition ${bootpart}
diff --git a/db/all.db b/db/all.db
index 1d4686c..bed551c 100644
--- a/db/all.db
+++ b/db/all.db
@@ -581,6 +581,7 @@ Mtd-Initrd: ramdisk
 Bootloader-Sets-Incorrect-Root: yes
 
 Machine: TI AM335x BeagleBone
+Machine: TI AM335x BeagleBone Black
 Kernel-Flavors: armmp
 DTB-Id: am335x-boneblack.dtb
 Boot-Script-Path: /boot/boot.scr
diff --git a/debian/changelog b/debian/changelog
index 152b984..2095326 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,10 @@ flash-kernel (3.30) UNRELEASED; urgency=medium
 
   [ Ian Campbell ]
   * Support for TI OMAP5 uEVM board (Patch from Chen Baozi, Closes: #773255)
+  * Support for alternative machine name for BeagleBone Black. The old name was
+ambiguous with the original BeagleBone (often called White), detect if
+booting on a BeagleBone white and print an error since the DTB will be
+wrong. We don't currently support the White. (Closes: #773890)
 
   [ Karsten Merker ]
   * Add a machine db entry for the LinkSprite pcDuino3


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel

2014-12-29 Thread Ian Campbell

On Tue, 2014-12-30 at 00:37 +0100, Geert Stappers wrote:
  
  Support for alternative machine name for BeagleBone Black.
  
  The old name was ambiguous with the original BeagleBone (often called 
  White),
  detect if booting on a BeagleBone white and print an error since the 
  DTB will
  be wrong. We don't currently support the White. (Closes: #773890, which
  contains full background).
  
  diff --git a/bootscript/bootscr.beaglebone b/bootscript/bootscr.beaglebone
  index a0e5121..1d079f8 100644
  --- a/bootscript/bootscr.beaglebone
  +++ b/bootscript/bootscr.beaglebone
 
 euh
   git mv bootscript/bootscr.beaglebone{,black}

If/when White support is added it will likely be via this script and in
any case the script name is an internal implementation detail not
generally exposed to the user.

So I don't see the point in renaming.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel

2014-12-28 Thread Ian Campbell

On Fri, 2014-12-26 at 12:46 -0800, Vagrant Cascadian wrote:
 On 2014-12-26, Ian Campbell wrote:
  On Wed, 2014-12-24 at 12:42 -0800, Vagrant Cascadian wrote:
  The following patch adds an additional Machine entry for the more
  specific name. Not sure if there's a more elegant way to add an entry
  that's simply a duplicate of another entry with a different Machine id.
 
  It's permissible to have multiple Machine entries in a stanza, so if the
  only difference is that field then it's fine to just add a new one (a
  bunch of the kirkwood TS-xxx enties follow this pattern since they have
  a boardfile name and a DTB name).
 
 Ok, then I think we should simply add the second Machine entry to the
 same stanza...

Ack.

 Basically long-running inability to distinguish between the white and
 black models make this impossible to get right for both, but I believe
 there are far more BeagleBone Black systems in the wild, and is better
 supported out of the box. It would be better to require manual
 intervention on the BeagleBone white models than the other way around.

OK, if that's the case then lets do as you suggests and just add the new
entry. I'll do this at some point.

OOI, do you know how broken the white is when booting with the black's
DTB? Completely unusable, missing some minor peripheral or somewhere in
the middle?

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774060: [I18N:fi] Updated Finish translation of debconf templates

2014-12-28 Thread Ian Campbell

Package: src:grub2
Severity: wishlist
Tags: patch, l10n
Control: submitter -1 Timo Jyrinki timo.jyri...@iki.fi

---BeginMessage---
18.12.2014, 10:50, Ian Campbell kirjoitti:
11.12.2014, 21:59, Ian Campbell kirjoitti:
Please send the updated file to me, or submit it as a wishlist bug
against grub2.

Attached is the updated fi.po.

Thanks again.

I just wanted to check that you had seen the followup CFT, which I'm
afraid will have fuzzied the new translation:
...
It has been brought to my attention that the phrase EFI removable path in
the
previous English version is confusing and wrong and should really be EFI
removable media path. Therefore I am sending out an updated po file (see
attached) with this fixed.

I'm afraid this will have marked any existing translations as fuzzy.

Updated fi.po attached. Removed the fuzzies and adjusted the translation
a bit. I'm aware the upload was already done, so maybe for the next one.
As the translation is otherwise done, this is not hugely important.

Thank you for the translation enablement work!

-Timo

# Esko ArajÃ¤rvi e...@iki.fi, 2009, 2010.
# Timo Jyrinki timo.jyri...@iki.fi, 2012, 2014.
msgid
msgstr
Project-Id-Version: grub2\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-27 18:53+0200\n
Last-Translator: Timo Jyrinki timo.jyri...@iki.fi\n
Language-Team: Finnish debian-l10n-finn...@lists.debian.org\n
Language: fi\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
X-Poedit-Language: Finnish\n
X-Poedit-Country: FINLAND\n
X-Generator: Lokalize 1.0\n
Plural-Forms: nplurals=2; plural=(n != 1);\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Ladataanko ketjutettuna tiedostosta menu.lst?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr
GRUBin pÃ¤ivityskomentosarjat ovat lÃ¶ytÃ¤neet vanhoja GRUB-asetuksia
tiedostosta /boot/grub.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
It's recommended that you accept chainloading GRUB 2 from menu.lst, and
verify that the new GRUB 2 setup works before it is written to the MBR
(Master Boot Record).
msgstr
On suositeltavaa, ettÃ¤ hyvÃ¤ksyt GRUB 2:n ketjutetun lataamisen tiedostosta
menu.lst ja varmistat uusien GRUB 2 -asetusten toimivuuden ennen kuin
asennat ne pÃ¤Ã¤kÃ¤ynnistyslohkoon (MBR).

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
Whatever your decision, you can replace the old MBR image with GRUB 2 later
by issuing the following command as root:
msgstr
Riippumatta valinnasta vanha MBR voidaan korvata GRUB 2:lla myÃ¶hemmin
suorittamalla seuraava komento pÃ¤Ã¤kÃ¤yttÃ¤jÃ¤nÃ¤:

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr Laitteet joille GRUB asennetaan:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid
The grub-pc package is being upgraded. This menu allows you to select which
devices you'd like grub-install to be automatically run for, if any.
msgstr
grub-pc-pakettia pÃ¤ivitetÃ¤Ã¤n. TÃ¤stÃ¤ valikosta voit valita, mille laitteille
grub-install suoritetaan automaattisesti.

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid
Running grub-install automatically is recommended in most situations, to
prevent the installed GRUB core image from getting out of sync with GRUB
modules or grub.cfg.
msgstr
grub-install:n suorittaminen automaattisesti on suositeltavaa useimmissa
tilanteissa, jotta asennettu GRUB-ydin ei tulisi epÃ¤yhteensopivaksi GRUB-
moduulien tai grub.cfg:n kanssa.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid
If you're unsure which drive is designated as boot drive by your BIOS, it is
often a good idea to install GRUB to all of them.
msgstr
Jos et ole varma, mikÃ¤ asema on mÃ¤Ã¤ritelty kÃ¤ynnistysasemaksi koneen BIOS-
asetuksissa, on usein hyvÃ¤ ajatus asentaa GRUB kaikille asemille.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid
Note: it is possible to install GRUB

Bug#772921: grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2

2014-12-28 Thread Ian Campbell

On Sat, 2014-12-27 at 18:56 +0200, Timo Jyrinki wrote:
 18.12.2014, 10:50, Ian Campbell kirjoitti:
  11.12.2014, 21:59, Ian Campbell kirjoitti:
  Please send the updated file to me, or submit it as a wishlist bug
  against grub2.
 
  Attached is the updated fi.po.
  
  Thanks again.
  
  I just wanted to check that you had seen the followup CFT, which I'm
  afraid will have fuzzied the new translation:
 ...
  It has been brought to my attention that the phrase EFI removable path 
  in the
  previous English version is confusing and wrong and should really be EFI
  removable media path. Therefore I am sending out an updated po file (see
  attached) with this fixed.
 
  I'm afraid this will have marked any existing translations as fuzzy.
 
 Updated fi.po attached. Removed the fuzzies and adjusted the translation
 a bit. I'm aware the upload was already done, so maybe for the next one.
 As the translation is otherwise done, this is not hugely important.

Thanks. Since #772921 was already closed with the previous update I've
forwarded this to a new bug (actually, I did that before I noticed you
had CC'd #772921 here or I'd have probably cloned or reopened instead).
The new one is #774060.

 Thank you for the translation enablement work!

My pleasure.

Cheers,
Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard

2014-12-28 Thread Ian Campbell

On Fri, 2014-12-26 at 18:43 +0800, Chen Baozi wrote:
 On Tue, Dec 23, 2014 at 7:44 PM, Ian Campbell i...@debian.org wrote:
  On Tue, 2014-12-23 at 16:27 +0800, Chen Baozi wrote:
  I have a glance at the kernel’s installer configs and tried the netboot
  without any modification. Some work should be done to make debian-installer
  support OMAP5 uEVM (e.g., ethernet driver etc).
 
  Right, those should be listed in e.g.
  debian/installer/armhf/modules/armhf-armmp/nic-modules.
 
  By waiting the kernel building with some initial attempted configs added,
  just one question to ask. I looked through the
  debian/installer/armhf/modules/armhf-armmp/, but it looks like none of
  files is about regulator modules. However, according to my previous
  experience, missing regulator driver modules is the main reason that
  the old debian kernel doesn’t support OMAP5 uEVM. How does debian-installer
  deal with this situation (if it does need extra regulator drivers 
  included?)
 
  Long term its a bit of an open question what we do wrt modules such as
  regulators, clocks, pinctrl etc.
 
  So far we have been a bit lucky: either such things are so central to
  the platform that it is acceptable (at least for now) to just build them
  into the main kernel binary by making them =y (e.g. CONFIG_I2C_S3C2410
  which is for the main power controller on arndale) or they are closely
  associated with some particular device and it makes sense to put them in
  that udeb (e.g. phy-exynos5250-sata in sata-modules, or phy-sun4i-usb in
  usb-modules).
 
  Eventually I expect that we will end up creating separate udebs for
  these things, but I'm hoping that we can defer that until at least
  Stretch to avoid needing to mess around with any more new packages for
  Jessie.
 
  If uEVM has some module which either shouldn't be built in or isn't
  obviously associated with a particular device let us know what it is and
  we can have a think about how best to approach it.
 
  One thing I've played with, and I'm not sure if this is acceptable or
  not, is to put core drivers which aren't =y into the kernel-image udeb
  itself. I'm not really sure if that's a good idea, we don't currently do
  this for anything AFAIK, but it's perhaps an option.
 
 With the attached patch applied, debian installer (tested with 
 network-console)
 can support OMAP5's ethernet driver and external MicroSD card.
 
 Note that I added related regulator  phy entries to files that mainly writes
 the modules which use them, since there is no file dedicated to those
 modules.

Do you know if phy-ti-pipe3 is used exclusively by USB or just only
within the set of things used in the d-i context? Likewise the two
regulators added to mmc?

 
 Baozi.
 
 ---
 diff -Nru linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/mmc-modules
 linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/mmc-modules
 --- linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/mmc-modules
 2014-09-21 20:04:21.0 +
 +++ linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/mmc-modules
 2014-12-26 03:16:02.0 +
 @@ -4,3 +4,5 @@
  omap_hsmmc
  sunxi-mmc
  dw_mmc-exynos
 +pbias-regulator
 +palmas-regulator
 diff -Nru linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/usb-modules
 linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/usb-modules
 --- linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/usb-modules
 2014-12-23 08:10:49.0 +
 +++ linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/usb-modules
 2014-12-25 02:56:08.0 +
 @@ -1,8 +1,13 @@
  #include usb-modules
  phy-sun4i-usb
  dwc3-exynos
  ohci-exynos
  ehci-exynos
  phy-exynos-usb2
  ci_hdrc_imx
 +phy-mxs-usb

Ack to your followup comment on this one.

 +dwc3-omap
 +ohci-omap3
 +ehci-omap
 +phy-omap-usb2
 +phy-ti-pipe3
 


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel

2014-12-26 Thread Ian Campbell

On Wed, 2014-12-24 at 12:42 -0800, Vagrant Cascadian wrote:
 Package: flash-kernel
 Version: 3.28
 Severity: normal
 Tags: patch
 
 When running the 3.18 kernel from experimental on a BeagleBone Black,
 /proc/device-tree/model contains TI AM335x BeagleBone Black. With
 the 3.16 kernel from Jessie, it contains TI AM335x BeagleBone.
 
 The following patch adds an additional Machine entry for the more
 specific name. Not sure if there's a more elegant way to add an entry
 that's simply a duplicate of another entry with a different Machine id.

It's permissible to have multiple Machine entries in a stanza, so if the
only difference is that field then it's fine to just add a new one (a
bunch of the kirkwood TS-xxx enties follow this pattern since they have
a boardfile name and a DTB name).

I wonder though if the DTB-Id field should be different? I think not on
the basis that the difference is down to
git.kernel.org/linus/9a15fff05b702c3ea29ae64db0d3ff0355431eab 

If you can confirm that is the case I can easily sort that out as I
commit it. 

I wonder if 9a15fff ought to be backported to the kernel in Jessie and
correspondingly whether this flash-kernel change ought to happen in
Jessie too (otherwise I'd just put it in experimental for the rest of
the freeze).

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773901: [I18N:mr] Updated Marathi translation of debconf templates

2014-12-25 Thread Ian Campbell

Package: src:grub2
Severity: wishlist
Tags: patch, l10n
Control: submitter -1 sampada nakhare sampadanakh...@gmail.com
---BeginMessage---
Hi Ian,

The translated file is attached herewith please.

I request you to commit it to the repository.

Sorry for the slight delay!

best regards,
- Sampada

On 12/14/14, Ian Campbell i...@debian.org wrote:
 Hi,

 You are noted as the last translator of the debconf translation for
 grub2.

 Thank you to those of you who have already submitted translation updates.

 It has been brought to my attention that the phrase EFI removable path in
 the
 previous English version is confusing and wrong and should really be EFI
 removable media path. Therefore I am sending out an updated po file (see
 attached) with this fixed.

 I'm afraid this will have marked any existing translations as fuzzy.

 Please send the updated file to me, or submit it as a wishlist bug against
 grub2. If you have already translated this template and the above change
 does
 not invalidate your translation then please let me know and I will un-fuzz
 it
 for you.

 At the same time some minor tweaks have been made to the English grammar. I
 think these should not affect translations.

 The complete wdiff for the English updates vs last time is:
 8--
 Template: grub2/force_efi_extra_removable
 Type: boolean
 Default: false
 _Description: Force extra installation to the EFI removable {+media+} path?
  Some EFI-based systems are buggy and do not handle new bootloaders
 correctly.
  If you force {+an+} extra installation of GRUB to the EFI removable
 {+media+} path, [-it-]
  {+this+} should
  [-make sure-] {+ensure+} that this system will boot Debian correctly
 despite such a
  problem. However, [-this-] {+it+} may remove the ability to boot any other
 operating
  systems that also depend on this path. If so, you will need to [-ensure-]
 {+make sure+} that
  GRUB is configured successfully to be able {+to+} boot any other OS
 installations
  correctly.
 8--

 The deadline for receiving the updated translation is still
 Sun, 21 Dec 2014 19:58:50 +.

 Thanks in advance, and sorry for the inconvenience.

 Ian.





mr.po
Description: Binary data
---End Message---

Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard

2014-12-23 Thread Ian Campbell

On Tue, 2014-12-23 at 16:27 +0800, Chen Baozi wrote:
 I have a glance at the kernel’s installer configs and tried the netboot
 without any modification. Some work should be done to make debian-installer
 support OMAP5 uEVM (e.g., ethernet driver etc).

Right, those should be listed in e.g.
debian/installer/armhf/modules/armhf-armmp/nic-modules.

 By waiting the kernel building with some initial attempted configs added,
 just one question to ask. I looked through the 
 debian/installer/armhf/modules/armhf-armmp/, but it looks like none of
 files is about regulator modules. However, according to my previous
 experience, missing regulator driver modules is the main reason that
 the old debian kernel doesn’t support OMAP5 uEVM. How does debian-installer
 deal with this situation (if it does need extra regulator drivers included?)

Long term its a bit of an open question what we do wrt modules such as
regulators, clocks, pinctrl etc.

So far we have been a bit lucky: either such things are so central to
the platform that it is acceptable (at least for now) to just build them
into the main kernel binary by making them =y (e.g. CONFIG_I2C_S3C2410
which is for the main power controller on arndale) or they are closely
associated with some particular device and it makes sense to put them in
that udeb (e.g. phy-exynos5250-sata in sata-modules, or phy-sun4i-usb in
usb-modules).

Eventually I expect that we will end up creating separate udebs for
these things, but I'm hoping that we can defer that until at least
Stretch to avoid needing to mess around with any more new packages for
Jessie.

If uEVM has some module which either shouldn't be built in or isn't
obviously associated with a particular device let us know what it is and
we can have a think about how best to approach it.

One thing I've played with, and I'm not sure if this is acceptable or
not, is to put core drivers which aren't =y into the kernel-image udeb
itself. I'm not really sure if that's a good idea, we don't currently do
this for anything AFAIK, but it's perhaps an option.

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773561: Installing xen-linux-system-amd64 on jessie fails

2014-12-23 Thread Ian Campbell

Control: reassign -1 xen-utils-common 4.4.1-6
Control: retitle -1 /etc/init.d/xen fails when run in a guest, causing postinst 
to fail.

Seems like this issue is in the Xen packages not in the xen-linux-system
metapackage, so reassigning.

On Mon, 2014-12-22 at 23:01 +0100, Sydney Meyer wrote:
  On 22 Dec 2014, at 17:25, Ian Campbell i...@debian.org wrote:
  
  On Sat, 2014-12-20 at 20:46 +0100, Sydney Meyer wrote:
  Hello Ian,
  
  systemctl status xen.service gives:
  
  Thanks. Sadly these logs weren't as informative a I had hoped they would
  be :-/ (In case it's not clear: this is not your fault)
  
  root@jessie:/home/sydney# systemctl status xen.service
  ● xen.service - LSB: Xen daemons
Loaded: loaded (/etc/init.d/xen)
Active: failed (Result: exit-code) since Sat 2014-12-20 20:42:30 CET; 
  11s ago
   Process: 4796 ExecStart=/etc/init.d/xen start (code=exited, status=255)
  
  Dec 20 20:42:30 jessie xen[4796]: Starting Xen daemons: xenfs (warning).
  Dec 20 20:42:30 jessie systemd[1]: xen.service: control process exited, 
  code=exited status=255
  Dec 20 20:42:30 jessie systemd[1]: Failed to start LSB: Xen daemons.
  Dec 20 20:42:30 jessie systemd[1]: Unit xen.service entered failed state.
  
  This basically says it failed, which isn't terribly helpful!
  
  I think it is complaining because it couldn't mount xenfs, but it
  doesn't say why.
  
  If you run /etc/init.d/xen start from the root command line does it
  say something more informative/useful?
 
 No, it fails and refers to systemctl/journalctl:

OK.
 
 root@jessie:/home/sydney# /etc/init.d/xen start
 [] Starting xen (via systemctl): xen.serviceJob for xen.service failed. 
 See 'systemctl status xen.service' and 'journalctl -xn' for details.
  failed!
  
  Could you also try running /usr/lib/xen-common/bin/xen-dir
  and /usr/lib/xen-common/bin/xen-toolstack by hand (also as root).
 
 root@jessie:/home/sydney# /usr/lib/xen-common/bin/xen-dir
 /usr/lib/xen-4.4
 
 root@jessie:/home/sydney# /usr/lib/xen-common/bin/xen-toolstack
 /usr/lib/xen-4.4/bin/xl

Thanks, so it thinks it is running under Xen (which given what you say
below makes sense).

What (if anything) does mount -t xenfs xenfs /proc/xen report?
Does /proc/xen exist?

 Yes, this particular output is from a Xen DomU with vmx enabled. The
 Dom0 is running Xen 4.4.1 compiled from source on a Debian Linux
 3.16.2 Kernel.

Thanks, this would have been good to know up front. I suppose you are
wanting to do some sort of nested virtualisation? You are likely the
first to try this with the Debian packaging, and nested virt generally
is considered tech preview upstream, so I'd expect there to be some
wrinkles in doing this.

By with vmx enabled I guess you mean with nestedhvm=1 in the guest
cfg? Are you running this in a PV or HVM guest (I think HVM)? Can you
post the dmesg from the kernel please, along with the guest cfg file.

I don't have much experience with nested virt but AIUI there are some
caveats with running Xen on Xen, in particular it seems that the L1
hypervisor (see [0] for the terminology) can either be a xenbus client
of the L0 hypervisor or provide xenbus services to its own L2 guests,
but not both at the same time. I think that people generally disable PV
drivers on the L1 domain (e.g. with xen_platform_pci=1 in its config) so
that it is free to provide xenbus services to its own guests. It might
be that this isn't relevant to the issue you report here, but it might
have some bearing (and it worth trying to disable it).

[0] http://wiki.xenproject.org/wiki/Xen_nested

  I have also tested this on a VMware Fusion 7 Guest (HW Version 11).

And it fails in the same way? If so then that's interesting because I
wouldn't expect the kernel to discover that it was running on Xen under
those circumstances. I wonder if the initscript is confused because it
is running on any hypervisor at all not specifically Xen

Does /sys/hypervisor/type exist in all cases and what does it contain?

  Assuming you are running this on the dom0/host, have you booted into the
  hypervisor at this point or are you running bare-metal/native? (I
  suspect the latter).
 
 The VM was running native, i.e. the VM itself didn't boot into
 hypervisor mode.

My hypothesis is that because it is running as a guest on Xen something
is getting confused and thinking it is actually booting as a host on
Xen, but the vmware thing doesn't quite fit.

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773222: [RFR] po-debconf://grub2

2014-12-22 Thread Ian Campbell

Hi Manuel,

On Mon, 2014-12-15 at 20:10 +0100, Manuel Venturi Porras Peralta wrote:
 Reenvío por la corrección que han hecho desde arriba.
 
 Sent with the suggested changes of the fuzzy removable path and done 
 the propper translation according to these changes.

I'm just applying this update, but debconf-updatepo is reporting one of
the new translations as fuzzy (the longer one, Some EFI-based systems
are buggy ...).

I think that the differences to the English text don't affect the
translation so I plan to go ahead (probably uploading later today), but
I've attached the current es.po in case you have a chance to check it.
If it is OK to just unfuzzy just let me know and I'll make the change.

Thanks,
Ian.
# grub2 po-debconf translation to Spanish
# Copyright (C) 2007, 2009, 2010, 2011 Software in the Public Interest
# This file is distributed under the same license as the grub2 package.
#
# Changes:
#   - Initial translation
#   Maria Germana Oliveira Blazeticgermanaolivei...@gmail.com, 2007
#
#   - Updates
#   Gary Ariel Sandi Vigabriel gary@gmail.com, 2009
#   Francisco Javier Cuadrado fcocuadr...@gmail.com, 2009, 2010, 2011
# 	Manuel Venturi Porras Peralta vent...@openmailbox.org, 2014.
#
#   - Revisions
#   Innocent De Marchi tangram.pe...@gmail.com, 2010
#
# Traductores, si no conocen el formato PO, merece la pena leer la
# documentaciÃ³n de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
#   info -n '(gettext)PO Files'
#   info -n '(gettext)Header Entry'
#
# Equipo de traducciÃ³n al espaÃ±ol, por favor lean antes de traducir
# los siguientes documentos:
#
#   - El proyecto de traducciÃ³n de Debian al espaÃ±ol
# http://www.debian.org/intl/spanish/
# especialmente las notas y normas de traducciÃ³n en
# http://www.debian.org/intl/spanish/notas
#
#   - La guÃa de traducciÃ³n de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
#
msgid 
msgstr 
Project-Id-Version: grub2 1.99-5\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-11 23:57+0100\n
Last-Translator: Manuel \Venturi\ Porras Peralta venturi@openmailbox.
org\n
Language-Team: EspaÃ±ol; Castellano debian-l10n-span...@lists.debian.org\n
Language: es\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=2; plural=(n != 1);\n
X-Generator: Gtranslator 2.91.6\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Â¿Desea cargar secuencialmente desde el fichero Â«menu.lstÂ»?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr 
Los ficheros de Ã³rdenes han detectado durante la actualizaciÃ³n una 
configuraciÃ³n heredada de una versiÃ³n anterior de GRUB en Â«/boot/grubÂ».

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
In order to replace the Legacy version of GRUB in your system, it is 
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image 
from your existing GRUB Legacy setup. This step can be automatically 
performed now.
msgstr 
Con el fin de reemplazar la versiÃ³n anterior de GRUB en el sistema, se 
recomienda configurar Â«/boot/grub/menu.lstÂ» para que cargue GRUB 2 a partir 
de la configuraciÃ³n heredada de GRUB. Este paso se puede hacer de forma 
automÃ¡tica.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
It's recommended that you accept chainloading GRUB 2 from menu.lst, and 
verify that the new GRUB 2 setup works before it is written to the MBR 
(Master Boot Record).
msgstr 
Se recomienda que acepte cargarlo secuencialmente desde el fichero Â«menu.
lstÂ» y que compruebe el buen funcionamiento del nuevo GRUB 2, antes de 
instalarlo en el MBR (Â«Master Boot RecordÂ»).

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
Whatever your decision, you can replace the old MBR image with GRUB 2 later 
by issuing the following command as root:
msgstr 
Sea cual sea su decisiÃ³n, puede reemplazar mÃ¡s tarde la imagen del MBR 
anterior con GRUB 2 ejecutando como administrador (Â«rootÂ») la orden 
siguiente:

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr Dispositivos donde puede instalar GRUB:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid 
The grub-pc package is being upgraded. This menu allows you to select which 
devices you'd like grub-install to be automatically run for, if any.
msgstr 
Se estÃ¡ actualizando el paquete grub-pc. Si lo desea, este menÃº le permite 
escoger en quÃ© dispositivos quiere ejecutar automÃ¡ticamente grub-install.

#. Type: multiselect
#. Description
#:

Bug#773222: [RFR] po-debconf://grub2

2014-12-22 Thread Ian Campbell

On Mon, 2014-12-22 at 12:47 +0100, Manuel Venturi Porras Peralta wrote:
 first of all, thanks for your email. It is ok to submit this es.po
 because the fuzzy thing was EFI removable media. It hadn't the media
 word so it resulted in a wrong translation, but now it is fixed and
 media has been translated to medio, as it is in spanish.

Thanks for confirming, I'll mark the translation as non-fuzzy before
uploading.

 Just to be sure, the es.po file was in UTF-8, right?

I believe so, at least that is what the headers claim.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773255: Add TI OMAP5 uEVM board support db

2014-12-22 Thread Ian Campbell

Control: tag -1 +pending

On Sat, 2014-12-20 at 15:39 +0800, Chen Baozi wrote:
  On Dec 19, 2014, at 16:15, Ian Campbell i...@debian.org wrote:
  
  On Fri, 2014-12-19 at 13:38 +0800, Chen Baozi wrote:
  I’ve only booted the system by ‘bootz’ without initrd. If I load the raw
  initrd image (rather than ‘uInitrd”), when I use bootz, it would output:
  
  Wrong Ramdisk Image Format
  Ramdisk image is corrupt or invalid
  
  This is the reason that I’m still using bootm when initrd is needed.
  
  bootz requires you to give the filesize for the raw initrd. e.g.
  load $kernel_addr_r kernel
  load $fdt_addr_r
  load $ramdisk_addr_r
  bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
  
  The :${filesize} is what I mean, it is implicitly set by load (and
  similar commands) which is why initrd is loaded last in the above, so it
  doesn't get clobbered.
 
 Aha, the CONFIG_SUPPORT_RAW_INITRD is not defined by default when building
 u-boot with omap5_uevm_defconfig. That is why I used to fail booting with
 ‘bootz’.
 
 With the latest u-boot enabling CONFIG_SUPPORT_RAW_INITRD, the following
 db description works:
 
 Machine: TI OMAP5 uEVM board
 Method: generic
 U-Boot-Script-Name: bootscr.uboot-generic
 Boot-Script-Path: /boot/boot.scr
 Required-Packages: u-boot-tools
 DTB-Id: omap5-uevm.dtb

Thanks. I think this platform supports LPAE, so I added Kernel-Flavors:
armmp armmp-lpae, and Method defaults to generic so I omitted it,
resulting in:
Machine: TI OMAP5 uEVM board
Kernel-Flavors: armmp armmp-lpae
DTB-Id: omap5-uevm.dtb
U-Boot-Script-Name: bootscr.uboot-generic
Boot-Script-Path: /boot/boot.scr
Required-Packages: u-boot-tools

I've committed this to flash-kernel.git, and I'll upload around the time
the kernel side is uploaded.

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773714: unblock: grub2/2.02~beta2-19

2014-12-22 Thread Ian Campbell

Package: release.debian.org
Severity: normal
Tags: d-i
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package grub2

Version -18 added a fix for #767037 (workaround for buggy EFI implementations)
which included a new debconf template. -19 adds translations for the new
template (including a wording fix to the English) and fixes two issues with
that new funcitionality (one, #773092, is important, the other, #773004, is
fairly minor but quite irritating in practice).

I also added a README.source.

Note that this upload does not include the upstream translation updates
discussed in preapproval bug #773224, since there wasn't an obvious yes to that
question.

I've filtered the actual debian/po templates from the debdiff below
(filterdiff -p1 -x debian/po/\*).

diff -Nru grub2-2.02~beta2/debian/changelog grub2-2.02~beta2/debian/changelog
--- grub2-2.02~beta2/debian/changelog   2014-12-08 08:38:41.0 +
+++ grub2-2.02~beta2/debian/changelog   2014-12-22 11:55:53.0 +
@@ -1,3 +1,45 @@
+grub2 (2.02~beta2-19) unstable; urgency=medium
+
+  [ Steve McIntyre ]
+  * Handle case insensitivity of VFAT filesystem on /boot/EFI when installing
+extra cpoy of grub-efi to the removable media path
+/boot/efi/EFI/BOOT/BOOT$ARCH.EFI (Closes: #773092)
+  * Make the force_efi_extra_removable debconf prompt only show up when
+configuring grub-*efi*. Closes: #773004
+
+  [ Ian Campbell ]
+  * Improvements to English wording of new debconf template from Justin B Rye.
+  * Add debian/README.source.
+
+  [ Debconf translations ]
+  * [eu] Basque (Iñaki Larrañaga Murgoitio, Closes: #772946)
+  * [be] Belarusian (Viktar Siarheichyk, Closes: #773054)
+  * [pt_BR] Brazilian Portuguese (Adriano Rafael Gomes, Closes: #773682)
+  * [bg] Bulgarian (Damyan Ivanov, Closes: #772878)
+  * [cs] Czech (Miroslav Kure, Closes: #772924)
+  * [nl] Dutch (Frans Spiesschaert, Closes: 773637)
+  * [eo] Esperanto (Felipe Castro, Closes: #773096)
+  * [fi] Finish (Timo Jyrinki, Closes: #772921)
+  * [fr] French (Christian PERRIER, Closes: #772771)
+  * [de] German (Martin Eberhard Schauer, Closes: #773664)
+  * [el] Greek (Panagiotis Georgakopoulos, Closes: #773068)
+  * [he] Hebrew (Omer Zak, Closes: #773377)
+  * [is] Icelandic (Sveinn í Felli, Closes: #772922)
+  * [it] Italian (Luca Monducci, Closes: #773553)
+  * [kk] Kazakh (Baurzhan Muftakhidinov, Closes: #772916)
+  * [lt] Lithuanian (Rimas Kudelis, Closes: #773060)
+  * [pl] Polish (Łukasz Dulny, Closes: #772930)
+  * [ro] Romanian (Andrei POPESCU, Closes: #773349)
+  * [ru] Russian (Yuri Kozlov, Closes: #773211)
+  * [sl] Slovenian (Vanja Cvelbar, Closes: #773508)
+  * [es] Spanish (Manuel Venturi Porras Peralta, Closes: #773222)
+  * [sv] Swedish (Martin Bagge  Anders Jonsson, Closes: 773208)
+  * [th] Thai (Theppitak Karoonboonyanan, Closes: #773160)
+  * [zh_TW] Traditional Chinese (Vincent W. Chen, Closes: #773418)
+  * [tr] Turkish (Mert Dirik, Closes: #773666)
+
+ -- Ian Campbell i...@debian.org  Mon, 22 Dec 2014 11:55:33 +
+
 grub2 (2.02~beta2-18) unstable; urgency=medium
 
   [ Steve McIntyre ]
diff -Nru grub2-2.02~beta2/debian/config.in grub2-2.02~beta2/debian/config.in
--- grub2-2.02~beta2/debian/config.in   2014-12-07 16:41:50.0 +
+++ grub2-2.02~beta2/debian/config.in   2014-12-22 11:55:53.0 +
@@ -73,5 +73,9 @@
 
 db_input ${priority} grub2/linux_cmdline || true
 db_input medium grub2/linux_cmdline_default || true
-db_input low grub2/force_efi_extra_removable || true
+case @PACKAGE@ in
+  grub-*efi*)
+db_input low grub2/force_efi_extra_removable || true
+  ;;
+esac
 db_go
diff -Nru grub2-2.02~beta2/debian/.git-dpm grub2-2.02~beta2/debian/.git-dpm
--- grub2-2.02~beta2/debian/.git-dpm2014-12-08 08:38:08.0 +
+++ grub2-2.02~beta2/debian/.git-dpm2014-12-22 11:55:53.0 +
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-dfcbcb60e5428bcb87ba96011c7b7ab1b7891fa1
-dfcbcb60e5428bcb87ba96011c7b7ab1b7891fa1
+617a691e4a95e67967ca8b0c77c59d347df182d6
+617a691e4a95e67967ca8b0c77c59d347df182d6
 e8f07821cce1bd0ab6d5622c2a42440f15f4fd71
 e8f07821cce1bd0ab6d5622c2a42440f15f4fd71
 grub2_2.02~beta2.orig.tar.xz
diff -Nru grub2-2.02~beta2/debian/patches/grub-install-extra-removable.patch 
grub2-2.02~beta2/debian/patches/grub-install-extra-removable.patch
--- grub2-2.02~beta2/debian/patches/grub-install-extra-removable.patch  
2014-12-08 08:38:08.0 +
+++ grub2-2.02~beta2/debian/patches/grub-install-extra-removable.patch  
2014-12-22 11:55:53.0 +
@@ -1,4 +1,4 @@
-From dfcbcb60e5428bcb87ba96011c7b7ab1b7891fa1 Mon Sep 17 00:00:00 2001
+From 617a691e4a95e67967ca8b0c77c59d347df182d6 Mon Sep 17 00:00:00 2001
 From: Steve McIntyre 93...@debian.org
 Date: Wed, 3 Dec 2014 01:25:12 +
 Subject: Add support for forcing EFI installation to the removable media path
@@ -12,17 +12,17 @@
 
 Signed-off-by: Steve McIntyre 93...@debian.org
 
-Bug-Debian: https

Bug#773224: (preapproval) unblock: grub2/2.02~beta2-19

2014-12-22 Thread Ian Campbell

On Wed, 2014-12-17 at 20:15 +, Jonathan Wiltshire wrote:
 Control: tag -1 moreinfo
 
 On Mon, Dec 15, 2014 at 08:02:33PM +, Ian Campbell wrote:
  The main reason for asking for preapproval is I am trying to decide whether 
  to
  also include a fix for #771249 which is an update to the upstream 
  translations.
  Would that be acceptable or not?
 
 Tricky... how bad *are* the upstream translations? Is this just polish or
 are there some problems with them?

FYI, I've uploaded -19 without this set of changes (see #773714).

I'm still prepared to fix #771249 in another upload if it is deemed
acceptable, so not closing this bug myself.

Cheers,
Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773561: Installing xen-linux-system-amd64 on jessie fails

2014-12-22 Thread Ian Campbell

On Sat, 2014-12-20 at 20:46 +0100, Sydney Meyer wrote:
 Hello Ian,
 
 systemctl status xen.service gives:

Thanks. Sadly these logs weren't as informative a I had hoped they would
be :-/ (In case it's not clear: this is not your fault)

 root@jessie:/home/sydney# systemctl status xen.service
 ● xen.service - LSB: Xen daemons
Loaded: loaded (/etc/init.d/xen)
Active: failed (Result: exit-code) since Sat 2014-12-20 20:42:30 CET; 11s 
 ago
   Process: 4796 ExecStart=/etc/init.d/xen start (code=exited, status=255)
 
 Dec 20 20:42:30 jessie xen[4796]: Starting Xen daemons: xenfs (warning).
 Dec 20 20:42:30 jessie systemd[1]: xen.service: control process exited, 
 code=exited status=255
 Dec 20 20:42:30 jessie systemd[1]: Failed to start LSB: Xen daemons.
 Dec 20 20:42:30 jessie systemd[1]: Unit xen.service entered failed state.

This basically says it failed, which isn't terribly helpful!

I think it is complaining because it couldn't mount xenfs, but it
doesn't say why.

If you run /etc/init.d/xen start from the root command line does it
say something more informative/useful?

Could you also try running /usr/lib/xen-common/bin/xen-dir
and /usr/lib/xen-common/bin/xen-toolstack by hand (also as root).

 journalctl -xn gives:
 
 root@jessie:/home/sydney# journalctl -xn
 -- Logs begin at Sat 2014-12-20 20:40:10 CET, end at Sat 2014-12-20 20:42:30 
 CET. --
 Dec 20 20:42:27 jessie kernel: hfsplus: unable to find HFS+ superblock
 Dec 20 20:42:27 jessie kernel: qnx4: no qnx4 filesystem (no root dir).
 Dec 20 20:42:27 jessie kernel: You didn't specify the type of your ufs 
 filesystem

mount -t ufs -o 
 ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...

WARNING Wrong ufstype may corrupt your 
 filesystem, default is ufstype=old
 Dec 20 20:42:27 jessie kernel: hfs: can't find a HFS filesystem on dev xvda2
 Dec 20 20:42:27 jessie os-prober[4747]: debug: /dev/xvda5: is active swap

This made me wonder -- are you doing/installing this in a Xen guest
(domU)? From other evidence I don't think you are but I should check.

Assuming you are running this on the dom0/host, have you booted into the
hypervisor at this point or are you running bare-metal/native? (I
suspect the latter).

Thanks,
Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772924: [Fwd: Re: [UPDATED] grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2]

2014-12-21 Thread Ian Campbell


---BeginMessage---
On Sat, Dec 13, 2014 at 08:37:10PM +, Ian Campbell wrote:
[...]
 I'm afraid this will have marked any existing translations as fuzzy.

Hi Ian,

please find attached updated Czech (cs.po) translation.

Cheers
-- 
Miroslav Kure

# Czech translation of grub2 debconf messages.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the grub2 package.
# Miroslav Kure ku...@debian.cz, 2008 -- 2014
#
msgid 
msgstr 
Project-Id-Version: grub2\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-21 10:32+0100\n
Last-Translator: Miroslav Kure ku...@debian.cz\n
Language-Team: Czech debian-l10n-cz...@lists.debian.org\n
Language: cs\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Zavést přes menu.lst?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr 
Aktualizační skripty GRUBu rozpoznaly v /boot/grub nastavení pro předchozí 
verzi GRUBu (tzv. GRUB Legacy).

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
In order to replace the Legacy version of GRUB in your system, it is 
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image 
from your existing GRUB Legacy setup. This step can be automatically 
performed now.
msgstr 
Abyste na svém systému nahradili zastaralou verzi GRUBu, je doporučeno 
upravit /boot/grub/menu.lst tak, aby zavedl obraz GRUBu 2 pomocí stávajícího 
GRUB Legacy. Tento krok je nyní možné provést automaticky.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
It's recommended that you accept chainloading GRUB 2 from menu.lst, and 
verify that the new GRUB 2 setup works before it is written to the MBR 
(Master Boot Record).
msgstr 
Před instalací GRUBu 2 přímo do MBR (Master Boot Record) se doporučuje 
nejprve vyzkoušet zavedení GRUBu 2 skrze menu.lst a teprve po ověření, že 
vše funguje očekávaným způsobem, zkusit instalaci do MBR.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
Whatever your decision, you can replace the old MBR image with GRUB 2 later 
by issuing the following command as root:
msgstr 
Ať se rozhodnete jakkoliv, obraz v MBR můžete kdykoliv později nahradit 
GRUBem 2. Stačí jako root spustit následující příkaz:

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr Zařízení pro instalaci GRUBu:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid 
The grub-pc package is being upgraded. This menu allows you to select which 
devices you'd like grub-install to be automatically run for, if any.
msgstr 
Balík grub-pc se právě aktualizuje. Tato nabídka vám umožňuje zvolit 
zařízení, na kterých se má automaticky spouštět grub-install.

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid 
Running grub-install automatically is recommended in most situations, to 
prevent the installed GRUB core image from getting out of sync with GRUB 
modules or grub.cfg.
msgstr 
Automatické spouštění grub-install je ve většině případů doporučeno, protože 
tak předcházíte tomu, aby se obraz jádra GRUBu rozcházel s GRUB moduly nebo 
souborem grub.cfg.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid 
If you're unsure which drive is designated as boot drive by your BIOS, it is 
often a good idea to install GRUB to all of them.
msgstr 
Pokud si nejste jisti, který disk je v BIOSu označen jako zaváděcí, bývá 
často dobrým nápadem nainstalovat GRUB na všechny disky.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid 
Note: it is possible to install GRUB to partition boot records as well, and 
some appropriate partitions are offered here. However, this forces GRUB to 
use the blocklist mechanism, which makes it less reliable, and therefore is 
not recommended.
msgstr 
Poznámka: GRUB je možné instalovat také do zaváděcích záznamů jednotlivých 
oblastí, jejichž seznam zde vidíte. Tímto však donutíte GRUB, aby používal 
mechanismus zvaný blocklist, který je méně spolehlivý tudíž se nedoporučuje.

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:4001
msgid 
The GRUB boot loader was previously installed to a disk that is no longer 
present, or whose unique identifier has changed for some reason. It is 
important to make sure that the installed GRUB core image stays in sync with 
GRUB modules and grub.cfg. Please check again to make sure that GRUB is 
written to the appropriate boot devices.
msgstr

Bug#767037: Grub EFI fallback - patches for review

2014-12-21 Thread Ian Campbell

On Sat, 2014-12-20 at 09:45 +0100, David Härdeman wrote:
 one option that doesn't seem to have been considered would be to create
 a separate package (let's call it UEFIx) that installs an UEFI binary to
 EFI/boot/bootx64.efi. That binary could then do what the UEFI BIOS
 should've done (i.e. look at the EFI vars for bootorder, bootnext, etc
 and then go on to load the right bootloader).

Interesting idea, does this stub bootloader already exist, or is it
something someone would need to write? (Either way I think it's likely
too late for Jessie, but perhaps something to think about for Stretch)

I'd also have some worries about packages installing to /boot/EFI since
that is by definition going to be a VFAT filesystem and I'm not
confident that dpkg will work fully/safely without all the POSIX-ish
semantics (hardlinks, atomic updates and the like), might want to handle
that by installing via the postinst instead of shipping in /boot/EFI.

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773664: [I18N:de] Updated German translation of debconf templates

2014-12-21 Thread Ian Campbell

Package: src:grub2
Severity: wishlist
Tags: patch, l10n
Control: submitter -1 Martin Eberhard Schauer martin.e.scha...@gmx.de
---BeginMessage---

Hi Ian,
sorry for the late reply.

 You are noted as the last translator of the debconf translation for
 grub2.

I'm quite proud of this prominent contribution to Debian :-)

Unfortunately the two new strings did not get a review on 
debian-l10n-german.

But I had a second and a third glance at the translation.

Kind regards,
   Martin

# Translation of GRUB 2 debconf templates to German
# Copyright (C) Helge Kreutzmann deb...@helgefjell.de, 2007-2009.
#   Martin Eberhard Schauer martin.e.scha...@gmx.de,
#   2010, 2011, 2014.
# This file is distributed under the same license as the grub2 package.
#
msgid 
msgstr 
Project-Id-Version: grub2 1.98+20100710-2\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-21 18:29+0100\n
Last-Translator: Martin Eberhard Schauer martin.e.scha...@gmx.de\n
Language-Team: German debian-l10n-ger...@lists.debian.org\n
Language: de\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
X-Generator: Lokalize 1.0\n
Plural-Forms: nplurals=2; plural=n != 1;\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Aus Â»menu.lstÂ« laden (Chainload)?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr 
Die Upgrade-Skripte von GRUB haben eine Installation von Â»GRUB LegacyÂ« in /
boot/grub gefunden.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
In order to replace the Legacy version of GRUB in your system, it is 
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image 
from your existing GRUB Legacy setup. This step can be automatically 
performed now.
msgstr 
Um die Legacy-Version von GRUB auf Ihrem System zu ersetzen, wird die 
Anpassung von /boot/grub/menu.lst empfohlen, so dass GRUB 2 aus Ihrer 
bestehenden GRUB-Legacy-Konfiguration heraus geladen wird. Dieser Schritt 
kann jetzt automatisch vollzogen werden.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
It's recommended that you accept chainloading GRUB 2 from menu.lst, and 
verify that the new GRUB 2 setup works before it is written to the MBR 
(Master Boot Record).
msgstr 
Es wird empfohlen, dass Sie dem Laden von GRUB 2 aus menu.lst zustimmen und 
Ã¼berprÃ¼fen, dass Ihre neue Â»GRUB 2Â«-Installation funktioniert, bevor diese 
in den MBR (Master Boot Record) geschrieben wird.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
Whatever your decision, you can replace the old MBR image with GRUB 2 later 
by issuing the following command as root:
msgstr 
UnabhÃ¤ngig von Ihrer Entscheidung kÃ¶nnen Sie den alten MBR spÃ¤ter durch GRUB 
2 ersetzen. Geben Sie dazu als Â»rootÂ« den folgenden Befehl ein:

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr GerÃ¤te fÃ¼r die GRUB-Installation:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid 
The grub-pc package is being upgraded. This menu allows you to select which 
devices you'd like grub-install to be automatically run for, if any.
msgstr 
FÃ¼r das Paket grub-pc wird gerade ein Upgrade durchgefÃ¼hrt. In diesem MenÃ¼ 
kÃ¶nnen Sie auswÃ¤hlen, ob und fÃ¼r welche GerÃ¤te grub-install automatisch 
ausgefÃ¼hrt werden soll.

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid 
Running grub-install automatically is recommended in most situations, to 
prevent the installed GRUB core image from getting out of sync with GRUB 
modules or grub.cfg.
msgstr 
FÃ¼r die Mehrzahl der FÃ¤lle wird empfohlen, grub-install automatisch laufen 
zu lassen. So wird vermieden, dass das installierte GRUB-Image nicht zu den 
GRUB-Modulen oder grub.cfg passt.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid 
If you're unsure which drive is designated as boot drive by your BIOS, it is 
often a good idea to install GRUB to all of them.
msgstr 
Wenn Sie nicht sicher sind, welches GerÃ¤t das BIOS zum Booten benutzt, ist 
es oft eine gute Idee, GRUB auf allen GerÃ¤ten zu installieren.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid 
Note: it is possible to install GRUB to partition boot records as well, and 
some appropriate partitions are offered here. However, this forces GRUB to 
use the blocklist mechanism, which makes it less reliable, and therefore is 
not recommended.
msgstr 
Hinweis: Sie kÃ¶nnen GRUB auch in die Boot-BlÃ¶cke von Partionen schreiben.
Hier werden

Bug#773561: Installing xen-linux-system-amd64 on jessie fails

2014-12-20 Thread Ian Campbell

On Sat, 2014-12-20 at 00:57 +0100, Sydney Meyer wrote:
 Job for xen.service failed. See 'systemctl status xen.service' and 
 'journalctl -xn' for details.

Please can you provide the output of these two commands while in this
state.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773255: Add TI OMAP5 uEVM board support db

2014-12-19 Thread Ian Campbell

On Fri, 2014-12-19 at 13:38 +0800, Chen Baozi wrote:
 I’ve only booted the system by ‘bootz’ without initrd. If I load the raw
 initrd image (rather than ‘uInitrd”), when I use bootz, it would output:
 
 Wrong Ramdisk Image Format
 Ramdisk image is corrupt or invalid
 
 This is the reason that I’m still using bootm when initrd is needed.

bootz requires you to give the filesize for the raw initrd. e.g.
load $kernel_addr_r kernel
load $fdt_addr_r
load $ramdisk_addr_r
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

The :${filesize} is what I mean, it is implicitly set by load (and
similar commands) which is why initrd is loaded last in the above, so it
doesn't get clobbered.

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773309: CONFIG_PSTORE not enabled for arm64

2014-12-19 Thread Ian Campbell

On Thu, 2014-12-18 at 20:13 +, Leif Lindholm wrote:
 *grumble, accidental send*

:-)

 On Thu, Dec 18, 2014 at 08:08:31PM +, Leif Lindholm wrote:
 (I don't have an x86 EFI system available to poke around and answer
 these for myself).
 
 I'm wondering if we ought to figure out how to load it automatically
 independent of the pstore stuff, for all arches.

I'd be happy for it not to be autoloaded, as long as it was consistent
across architectures.
   
   I think (although I'm somewhat inferring some pieces) that the right
   answer here is to have something (mountkernfs.sh/systemd/pixies) mount
   efivarfs and to ignore the deprecated efivars thing on non-x86. The
   pstore stuff should be considered a separate feature request in its own
   right.
 
 Well, that was the actual thing I asked for in this bug, so let's keep
 the pstore aspect here.

Right.

   I could clone this bug and retitle+reassign the other half into a bug to
   handle the efi half, but TBH I think conflating the EFI variable access
   from userspace requirement with enabling pstore in the kernel is just
   going to end up causing confusion, so a separate report to get efivarfs
   mounted would probably be best.
 
 Fair point.
 Coming up.

Thanks.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773309: CONFIG_PSTORE not enabled for arm64

2014-12-19 Thread Ian Campbell

On Thu, 2014-12-18 at 20:08 +, Leif Lindholm wrote:
 On Thu, Dec 18, 2014 at 06:35:25PM +, Ian Campbell wrote:
Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what
pstore is, so sorry if this is a silly question).
   
   I am actually not concerned about pstore itself, but rather by the
   lack of similarity between platforms.
  
  Consistency is a worthwhile goal, but not at the expense of enabling
  legacy x86 junk on new architectures where it can never have any
  relevance. I don't know if pstore fits that bill, which is why I was
  asking about it.
  
  If pstore is going to be a useful thing on arm64 then of course we
  should enable it. We should *not* enable it purely to gain the side
  effect of loading efivars (the more so since as discussed below it seems
  like efivars itself is a legacy interface).
 
 pstore is not legacy nonsense (it's for storing system crash
 information persistently). I don't actively care only since I've also
 not heard anyone screaming for it.

Thanks, it does sound useful rather than legacy. Given what Ben said it
does seem like it would be worthwhile to enable.

 Ok, so I had a peek in codesearch.debian.net, to see what current
 users we have. elilo can be ignored, dracut probably doesn't matter
 (?), mdadm has it in platform-intel.c so still wouldn't matter, kernel
 doesn't matter and grub2 will work anyway.
 
 Which leaves us with the risk of out-of-tree software making use of it.

My inclination is towards suggesting that if people are running
out-of-tree software which needs the efivars interface then they should
arrange for it to be loaded themselves (e.g. by adding to /etc/modules).

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773508: [I18N:sl] Updated Slovenian translation of debconf templates

2014-12-19 Thread Ian Campbell

Package: src:grub2
Severity: wishlist
Tags: patch, l10n
---BeginMessage---
Hello,
here is the updated file.

Regards
Vanja

2014-12-11 20:59 GMT+01:00 Ian Campbell i...@debian.org:
Hi,

You are noted as the last translator of the debconf translation for
grub2. The English template has been changed, and now some messages
are marked fuzzy in your translation or are missing.
I would be grateful if you could take the time and update it.
Please send the updated file to me, or submit it as a wishlist bug
against grub2.

The deadline for receiving the updated translation is
Sun, 21 Dec 2014 19:58:50 +.

Thanks in advance,
Ian.

--
Vanja Cvelbar

Work: +39 040 3756456
FAX:+39 040 9890668
GSM: +39 348 2241352

Follow your Euro notes in their tracks
http://www.eurobilltracker.eu/?referer=63885

# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR EMAIL@ADDRESS, YEAR.
#
msgid
msgstr
Project-Id-Version: grub2\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-07 16:09+\n
PO-Revision-Date: 2014-12-19 11:34+0100\n
Last-Translator: Vanja Cvelbar cvel...@gmail.com\n
Language-Team: Slovenian s...@li.org\n
Language: sl\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=utf-8\n
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=4; plural=(n%100==1 ? 1 : n%100==2 ? 2 : n%100==3 || n%100==4 ? 3 : 0);\n
X-Poedit-Language: Slovenian\n
X-Poedit-Country: SLOVENIA\n
X-Poedit-SourceCharset: utf-8\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Verižno nalaganje iz menu.lst?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr Skript za nadgradnjo je zaznal namestitev GRUB Legacy v /boot/grub.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid It's recommended that you accept chainloading GRUB 2 from menu.lst, and verify that the new GRUB 2 setup works before it is written to the MBR (Master Boot Record).
msgstr Priporočamo vam, da sprejmete verižno nalaganje GRUB 2 iz datoteke menu.lst in preverite delovanje namestitve GRUB2 preden ga namestite na MBR (Master Boot Record).

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
#: ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr Namestitvene naprave za GRUB:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid The grub-pc package is being upgraded. This menu allows you to select which devices you'd like grub-install to be automatically run for, if any.
msgstr Nadgrajevanje paketa grub-pc. Ta meni vam omogoči izbiro naprav za katere želite samodejno zagnati grub-install.

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid Running grub-install automatically is recommended in most situations, to prevent the installed GRUB core image from getting out of sync with GRUB modules or grub.cfg.
msgstr V večini primerov je priporočen samodejni zagon grub-install, da preprečite neskladja med jedrom GRUBa in moduli ali grub.cfg.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
#: ../grub-pc.templates.in:4001
msgid If you're unsure which drive is designated as boot drive by your BIOS, it is often a good idea to install GRUB to all of them.
msgstr V primeru, da niste prepričani kateri pogon je označuje vaš BIOS za zagonskega, je ponavadi dobro, da namestite GRUB kar na vse.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
#: ../grub-pc.templates.in:4001
msgid Note: it is possible to install GRUB to partition boot records as well, and some appropriate partitions are offered here. However, this forces GRUB to use the blocklist mechanism, which makes it less reliable, and therefore is not recommended.
msgstr Opomba: GRUB je mogoče namestiti tudi na zagonski zapis razdelka. Primerni razdelki so na tem spisku. To pa

Bug#773508: grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2

2014-12-19 Thread Ian Campbell

On Fri, 2014-12-19 at 11:36 +0100, Vanja Cvelbar wrote:
 Hello,
 here is the updated file.

Thanks, I've forwarded to the BTS for tracking.

Did you see the updated Call-For-Translations which followed this one
(text below)? I'm afraid there were some changes to the English which
would have fuzzied the translation. If it doesn't affect you translation
please let me know and I'll unfuzzy it.

Ian.

 Hi,

 You are noted as the last translator of the debconf translation for
 grub2.

 Thank you to those of you who have already submitted translation updates.

 It has been brought to my attention that the phrase EFI removable path in 
 the
 previous English version is confusing and wrong and should really be EFI
 removable media path. Therefore I am sending out an updated po file (see
 attached) with this fixed.

 I'm afraid this will have marked any existing translations as fuzzy.

 Please send the updated file to me, or submit it as a wishlist bug against
 grub2. If you have already translated this template and the above change does
 not invalidate your translation then please let me know and I will un-fuzz it
 for you.

 At the same time some minor tweaks have been made to the English grammar. I
 think these should not affect translations.

 The complete wdiff for the English updates vs last time is:
 8--
 Template: grub2/force_efi_extra_removable
 Type: boolean
 Default: false
 _Description: Force extra installation to the EFI removable {+media+} path?
  Some EFI-based systems are buggy and do not handle new bootloaders correctly.
  If you force {+an+} extra installation of GRUB to the EFI removable 
 {+media+} path, [-it-]
  {+this+} should
  [-make sure-] {+ensure+} that this system will boot Debian correctly despite 
 such a
  problem. However, [-this-] {+it+} may remove the ability to boot any other 
 operating
  systems that also depend on this path. If so, you will need to [-ensure-] 
 {+make sure+} that
  GRUB is configured successfully to be able {+to+} boot any other OS 
 installations
  correctly.
 8--

 The deadline for receiving the updated translation is still
 Sun, 21 Dec 2014 19:58:50 +.

 Thanks in advance, and sorry for the inconvenience.

 Ian.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773418: [I18N:zh_TW] Updated Traditional Chinese translation of debconf templates

2014-12-18 Thread Ian Campbell

Package: src:grub2
Severity: wishlist
Tags: patch, l10n
---BeginMessage---
On Sat, Dec 13, 2014 at 12:37 PM, Ian Campbell i...@debian.org wrote:
Hi,

You are noted as the last translator of the debconf translation for
grub2.

Thank you to those of you who have already submitted translation updates.

It has been brought to my attention that the phrase EFI removable path in
the
previous English version is confusing and wrong and should really be EFI
removable media path. Therefore I am sending out an updated po file (see
attached) with this fixed.

I'm afraid this will have marked any existing translations as fuzzy.

Please send the updated file to me, or submit it as a wishlist bug against
grub2. If you have already translated this template and the above change does
not invalidate your translation then please let me know and I will un-fuzz it
for you.

At the same time some minor tweaks have been made to the English grammar. I
think these should not affect translations.

The complete wdiff for the English updates vs last time is:
8--
Template: grub2/force_efi_extra_removable
Type: boolean
Default: false
_Description: Force extra installation to the EFI removable {+media+} path?
Some EFI-based systems are buggy and do not handle new bootloaders correctly.
If you force {+an+} extra installation of GRUB to the EFI removable
{+media+} path, [-it-]
{+this+} should
[-make sure-] {+ensure+} that this system will boot Debian correctly despite
such a
problem. However, [-this-] {+it+} may remove the ability to boot any other
operating
systems that also depend on this path. If so, you will need to [-ensure-]
{+make sure+} that
GRUB is configured successfully to be able {+to+} boot any other OS
installations
correctly.
8--

The deadline for receiving the updated translation is still
Sun, 21 Dec 2014 19:58:50 +.

Thanks in advance, and sorry for the inconvenience.

Ian.

Attached is the updated translation.

Regards,

Vincent Chen

# Copyright (C) 2009 Tetralet
# This file is distributed under the same license as the grub2 package.
#
msgid
msgstr
Project-Id-Version: grub2\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-17 17:08-0800\n
Last-Translator: Vincent Chen vin...@gmail.com\n
Language-Team: Debian-user in Chinese [Big5] debian-chinese-big5@lists.
debian.org\n
Language: zh_TW\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr 是否使用來自 menu.list 的 chainload 項目？

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr GRUB 升級程式已在 /boot/grub 裡找到了 GRUB Legacy 的設定。

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
It's recommended that you accept chainloading GRUB 2 from menu.lst, and
verify that the new GRUB 2 setup works before it is written to the MBR
(Master Boot Record).
msgstr
在直接將 GRUB 2 安裝到 MBR（主要開機記錄）之前，建議您能同意在 menu.lst 裡先
以 chainload 的方式啟動 GRUB 2，以確認新的 GRUB 2 設定能正常運作。

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr GRUB 安裝裝置：

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid
Running grub-install automatically is recommended in most situations, to
prevent the installed GRUB core image from getting out of sync with GRUB
modules or grub.cfg.
msgstr
在大多情況下建議自動執行 grub-install，以必免 GRUB 核心影像和 GRUB 模組或
grub.cfg 拖步。

Bug#772924: [l10n] Updated Czech translation of grub2 debconf messages

2014-12-18 Thread Ian Campbell

Control: retitle -1 [i18n:cs] Updated Czech translation of grub2 debconf 
messages

On Fri, 2014-12-12 at 10:10 +0100, Miroslav Kure wrote:
 in attachement there is updated Czech (cs.po) translation of 
 grub2 debconf messages. Please include it with the package.

Thanks.

I just wanted to check that you had seen the followup CFT, which I'm
afraid will have fuzzied the new translation:

 You are noted as the last translator of the debconf translation for
 grub2.

 Thank you to those of you who have already submitted translation updates.

 It has been brought to my attention that the phrase EFI removable path in 
 the
 previous English version is confusing and wrong and should really be EFI
 removable media path. Therefore I am sending out an updated po file (see
 attached) with this fixed.

 I'm afraid this will have marked any existing translations as fuzzy.

 Please send the updated file to me, or submit it as a wishlist bug against
 grub2. If you have already translated this template and the above change does
 not invalidate your translation then please let me know and I will un-fuzz it
 for you.

 At the same time some minor tweaks have been made to the English grammar. I
 think these should not affect translations.

 The complete wdiff for the English updates vs last time is:
 8--
 Template: grub2/force_efi_extra_removable
 Type: boolean
 Default: false
 _Description: Force extra installation to the EFI removable {+media+} path?
  Some EFI-based systems are buggy and do not handle new bootloaders correctly.
  If you force {+an+} extra installation of GRUB to the EFI removable 
 {+media+} path, [-it-]
  {+this+} should
  [-make sure-] {+ensure+} that this system will boot Debian correctly despite 
 such a
  problem. However, [-this-] {+it+} may remove the ability to boot any other 
 operating
  systems that also depend on this path. If so, you will need to [-ensure-] 
 {+make sure+} that
  GRUB is configured successfully to be able {+to+} boot any other OS 
 installations
  correctly.
 8--

 The deadline for receiving the updated translation is still
 Sun, 21 Dec 2014 19:58:50 +.

 Thanks in advance, and sorry for the inconvenience.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772921: grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2

2014-12-18 Thread Ian Campbell

On Fri, 2014-12-12 at 10:19 +0200, Timo Jyrinki wrote:
 11.12.2014, 21:59, Ian Campbell kirjoitti:
  Please send the updated file to me, or submit it as a wishlist bug
  against grub2.
 
 Attached is the updated fi.po.

Thanks again.

I just wanted to check that you had seen the followup CFT, which I'm
afraid will have fuzzied the new translation:

 You are noted as the last translator of the debconf translation for
 grub2.

 Thank you to those of you who have already submitted translation updates.

 It has been brought to my attention that the phrase EFI removable path in 
 the
 previous English version is confusing and wrong and should really be EFI
 removable media path. Therefore I am sending out an updated po file (see
 attached) with this fixed.

 I'm afraid this will have marked any existing translations as fuzzy.

 Please send the updated file to me, or submit it as a wishlist bug against
 grub2. If you have already translated this template and the above change does
 not invalidate your translation then please let me know and I will un-fuzz it
 for you.

 At the same time some minor tweaks have been made to the English grammar. I
 think these should not affect translations.

 The complete wdiff for the English updates vs last time is:
 8--
 Template: grub2/force_efi_extra_removable
 Type: boolean
 Default: false
 _Description: Force extra installation to the EFI removable {+media+} path?
  Some EFI-based systems are buggy and do not handle new bootloaders correctly.
  If you force {+an+} extra installation of GRUB to the EFI removable 
 {+media+} path, [-it-]
  {+this+} should
  [-make sure-] {+ensure+} that this system will boot Debian correctly despite 
 such a
  problem. However, [-this-] {+it+} may remove the ability to boot any other 
 operating
  systems that also depend on this path. If so, you will need to [-ensure-] 
 {+make sure+} that
  GRUB is configured successfully to be able {+to+} boot any other OS 
 installations
  correctly.
 8--

 The deadline for receiving the updated translation is still
 Sun, 21 Dec 2014 19:58:50 +.

 Thanks in advance, and sorry for the inconvenience.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773255: Add TI OMAP5 uEVM board support db

2014-12-18 Thread Ian Campbell

On Wed, 2014-12-17 at 23:28 +0800, Chen Baozi wrote:
  On Dec 17, 2014, at 23:04, Ian Campbell i...@debian.org wrote:
  
  On Wed, 2014-12-03 at 12:18 +0800, Chen Baozi wrote:
  Package: flash-kernel
  Version: 3.28
  Severity: wishlist
  Tags: patch
  
  With the patch attached, TI OMAP5 uEVM board is supported.
  
  Thanks.
  
  +Machine: TI OMAP5 uEVM board
  +Method: generic
  +U-Boot-Kernel-Address: 0x80008000
  +U-Boot-Initrd-Address: 0x0
  +U-Boot-Script-Address: 0x0
  +U-Boot-Script-Name: bootscr.omap
  +Boot-Device: /dev/mmcblk1p1
  +Boot-Kernel-Path: uImage
  +Boot-Initrd-Path: uInitrd
  +Boot-Script-Path: boot.scr
  +Required-Packages: u-boot-tools
  
  A few questions about u-boot on this platform:
  
   * Does it support the bootz command?
 
 The default one shipped with the board, which I got last year, seems not.
 But I’m now using the latest upstream u-boot, which does support ‘bootz’.

Is updating u-boot on this platform safe? As in can you brick the system
or is it always recoverable?

Does it have an easily accessible serial console (i.e. no soldering or
magic hard to get cables required)?

   * Does it support loading from sensible (i.e. other than FAT and
 raw partitions) filesystems? (possibly via the generic load
 command)?
 
 My current upstream u-boot does support.

Good.

   * Is /dev/mmcblk1p1 normally mounted (perhaps on /boot) or is it a
 dedicated boot partition which is not normally mounted?
 
 This is the partition when people use the external Micro-SD card as the
 rootfs on the board. I configured my system (debian) to mount it
 automatically. When I was using the old kernel last year, this partition
 is recognised as /dev/mmcblk0p1. With more platform driver available,
 the /dev/mmcblk0p1 is now considered to be the on-board nand flash,
 which I never used. However, with the sata driver support now, one
 should be able to attach a normal sata hard disk and boot the system
 from it. But I haven’t tried that yet.

The Boot-Device field is intended for use on systems where the
bootloader is either dumb or inflexible, i.e. it expects a certain
partition to contain a FAT filesystem with a particular set of files
(referred to via Boot-*-Path) on it, probably with mkimage headers on
them.

That partition would not normally be mounted during normal operation but
is mounted on demand by flash-kernel to update the files. It is not
expected that Boot-Device points to the partition mounted on /boot or
anything like that (not normally at least).

For more capable systems where the bootloader supports loading from a
regular Linux fs, supports boot scripts and bootz etc we would prefer to
just use the files in /boot directly, i.e. no need for Boot-Device (and
in many case no need for Boot-*-Path either)

  Ultimately what I'm getting at is, can this platform use
  bootscr.uboot-generic? I'd like to try and default to that wherever
  possible for new platforms. (bootscr.omap predates all of the above
  facilities being generally available in u-boot AFAIK).
 
 Oh, I haven’t had tried the boot script. I just copy this field from
 OMAP4 Panda board, which is somehow similar as uEVM.

Right, they are similar but much older and therefore not as capable,
also I wouldn't be surprised if the Panda entry had bit rotted and no
longer works (the lack of a DTB-Id is suspicious...)

Anyhow, it sounds like bootscr.uboot-generic ought to work for this
platform, at least with the updated upstream u-boot. Can you give it a
go? I think you would just want:
Machine: TI OMAP5 uEVM board
Method: generic
U-Boot-Script-Name: bootscr.uboot-generic
Boot-Script-Path: /boot/boot.scr
Required-Packages: u-boot-tools

Perhaps with DTB-Id as discussed below.

  On a separate note, there is no DTB-Id field. Does this mean that the
  platform comes with a DTB in the firmware?
 
 No. The DTB is on the /boot too. I miss it because OMAP4 doesn’t
 include this field. I guess you mentioned it because it is useful
 for flash-kernel to generate the right bootscr.*?

If you specify DTB-Id then flash-kernel will copy that file from the
kernel package to /boot/dtb-`uname -r` (and to Boot-DTB-Path if you
specify it) where it can be picked up by the boot.scr.

If your platform supplies an FDT from somewhere else then you likely
don't want this, but not many platforms do that so chances are that you
do.

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773309: CONFIG_PSTORE not enabled for arm64

2014-12-18 Thread Ian Campbell

Control: severity -1 wishlist

On Wed, 2014-12-17 at 16:30 +, Leif Lindholm wrote:
 On Wed, Dec 17, 2014 at 02:57:17PM +, Ian Campbell wrote:
   Could we enable CONFIG_PSTORE for arm64 as well, please?
  
  Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what
  pstore is, so sorry if this is a silly question).
 
 I am actually not concerned about pstore itself, but rather by the
 lack of similarity between platforms.

Consistency is a worthwhile goal, but not at the expense of enabling
legacy x86 junk on new architectures where it can never have any
relevance. I don't know if pstore fits that bill, which is why I was
asking about it.

If pstore is going to be a useful thing on arm64 then of course we
should enable it. We should *not* enable it purely to gain the side
effect of loading efivars (the more so since as discussed below it seems
like efivars itself is a legacy interface).

  Is efivars needed only for efibootmgr or are there other reasons to want
  it?
 
 The /sys/firmware/efi/vars interface exported by efivars is actually a
 legacy api (efivarfs is the preferred one), but since it is still
 shipped, alignment across architectures would be desirable.

Enabling legacy stuff on new architectures by default is not inherently
desirable IMHO. It would be far better to use the new/proper stuff right
out the gate, at least by default.

 There may or may not currently be other users than efibootmgr.

I can see references in the efivars package (which provides libefivars,
which efibootmgr uses) to efivarfs. Which suggests to me that loading
efivars is not what is needed, but rather the automounting
of /sys/firmware/efi/vars is. That would need to be a bug against some
other package (the mountkernfs.sh providing one would be my best guess,
which may well be systemd these days via some other means, #744301 seems
related, although it goes further).

  (I don't have an x86 EFI system available to poke around and answer
  these for myself).
  
  I'm wondering if we ought to figure out how to load it automatically
  independent of the pstore stuff, for all arches.
 
 I'd be happy for it not to be autoloaded, as long as it was consistent
 across architectures.

I think (although I'm somewhat inferring some pieces) that the right
answer here is to have something (mountkernfs.sh/systemd/pixies) mount
efivarfs and to ignore the deprecated efivars thing on non-x86. The
pstore stuff should be considered a separate feature request in its own
right.

I could clone this bug and retitle+reassign the other half into a bug to
handle the efi half, but TBH I think conflating the EFI variable access
from userspace requirement with enabling pstore in the kernel is just
going to end up causing confusion, so a separate report to get efivarfs
mounted would probably be best.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773467: efikamx: linux-image-3.2.0-4-mx5 is not upgraded to linux-image-armmp (and that one doesn't work)

2014-12-18 Thread Ian Campbell

On Thu, 2014-12-18 at 19:13 +0100, Holger Levsen wrote:
 Package: src:linux,upgrade-reports
 Version: 3.16.7-ckt2-1
 Severity: important
 
 Dear maintainers,
 
 I've just upgraded my Genesi EfikaMX nettop from wheezy to jessie and the only
 package which wasn't upgraded was linux-image-3.2.0-4-mx5, so I had to install
 linux-image-armmp manually... I'm not really sure how to solve this sensibly,
 suggesting that linux-image-armmp should provide linux-image-3.2.0-4-mx5 seems
 strange. 

In the past we've done that via the metapackages, I thought via
linux-latest, but I can't see any evidence of that right now, so maybe
I'm confused..

But. I don't think any modern kernel supports the efika, it was removed
from the mainline kernel a while ago (summer 2012 it seems [0]) and was
therefore removed from the installer on that basis too[1]

 It didn't come back, will need to attach a serial console and see if I see
 anything useful there...

From what I gather this is not unexpected. I'm not sure why this
platform was removed upstream, but I expect lack of anyone willing to
maintain it and/or move it over to device tree might have been part of
it.

Around the time of the removal from the installer I did have a look
around for any plausible activity on that front and IIRC I didn't find
anything.

Sorry, I expect none of this was what you wanted to hear :-(

Ian.

[0]

commit c7c29b3aeb318b9efe3035cacf42800dfe2970f5
Author: Matt Sealey m...@genesi-usa.com
Date:   Wed Aug 1 12:49:30 2012 -0500

ARM: efikamx: remove Genesi Efika MX platform files from the tree

Delete the files that can no longer be built.

Signed-off-by: Matt Sealey m...@genesi-usa.com
Signed-off-by: Shawn Guo shawn@linaro.org

commit 56a12b3984a368b1feab41a77f58fe81cc6771bf
Author: Matt Sealey m...@genesi-usa.com
Date:   Wed Aug 1 12:49:29 2012 -0500

ARM: efikamx: remove Genesi Efika MX from the i.MX v6/v7 defconfig

No need to have Efika MX listed in the defconfig if it can't be built.

Signed-off-by: Matt Sealey m...@genesi-usa.com
Signed-off-by: Shawn Guo shawn@linaro.org

commit f60c99e22cae4d8761c86967a14e4621322c057e
Author: Matt Sealey m...@genesi-usa.com
Date:   Wed Aug 1 12:49:28 2012 -0500

ARM: efikamx: remove support for Genesi Efika MX from the build

Disable building for Efika MX boards by not having any configuration or
object file definitions.

Signed-off-by: Matt Sealey m...@genesi-usa.com
Signed-off-by: Shawn Guo shawn@linaro.org

[1] https://lists.debian.org/debian-boot/2014/04/msg00279.html


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773467: efikamx: linux-image-3.2.0-4-mx5 is not upgraded to linux-image-armmp (and that one doesn't work)

2014-12-18 Thread Ian Campbell

On Thu, 2014-12-18 at 20:20 +0100, Holger Levsen wrote:
 Hi Ian,
 
 thanks for the fast response!
 
 On Donnerstag, 18. Dezember 2014, Ian Campbell wrote:
  But. I don't think any modern kernel supports the efika, it was removed
  from the mainline kernel a while ago (summer 2012 it seems [0]) and was
  therefore removed from the installer on that basis too[1]
 
 thanks, I was looking for this information (as I saw in the jessie d-i beta1 
 release notes that support for efikamx was removed, but I couldn't really 
 find 
 out why..) and then I saw this in the linux debian/changelog  from 3.11.5-1 
 from October 2013:
 
   * [armhf] Remove mx5, omap and vexpress flavours. These are all supported
 by the multiplatform flavour.
 
 That sounded promising enough, so I gave upgrading a try...

Yeah, mx5 general still works (AFAIK), it's just the efika stuff which
has gone.

   It didn't come back, will need to attach a serial console and see if I
   see anything useful there...
 
 I wonder if I should still bother...

With (AFAIK) no DTB file in existence it'd be something of a miracle if
it worked I'm afraid :-(

  From what I gather this is not unexpected. I'm not sure why this
  platform was removed upstream, [...]
  Sorry, I expect none of this was what you wanted to hear :-(
 
 Indeed, but thanks for explaining!
 
 I'll guess I'll go with owning another brick then ;-)

I did look for non-mainline community/kernel support a while back, but
it might be worth having another look before putting it in the attic.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard

2014-12-17 Thread Ian Campbell

On Wed, 2014-12-17 at 15:10 +0800, Chen Baozi wrote:
 Hi Ian,
 
  On Dec 13, 2014, at 20:21, Ian Campbell i...@debian.org wrote:
  
  If you care about Debian Installer support then you should also check
  whether any of the newly added modules need to be added to the installer
  udebs (which you can mainly do via the module lists under
  debian/installer/armhf/modules/armhf-armmp/). I've added dwc3-omap to
  usb-modules already since that one seemed obvious.
 
 I haven't tried debian-installer on arm platform before. I guess people
 usually don’t use it as a CD/DVD installer image like x86 on arm?

I usually use netboot, others use hd-media from USB sticks etc.

 Any pre-built image for a quick test? Do I need to generate the image by
 myself?

There are daily installer images at
http://d-i.debian.org/daily-images/armhf/ but these are built from the
kernel etc in sid not from svn, i.e. don't yet include the changes to
enable uEVM, so until the kernel is next uploaded you would indeed need
to build d-i yourself.

That's not too hard: Take all the udebs from your kernel build (e.g.
from dcmd --udeb linux_..._armhf.changes) and put them in the
build/localudebs directory of the debian-installer.git. Then:
 make -C build build_netboot
etc. It doesn't (easily?) cross compile, so you will need an armhf host.

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773309: CONFIG_PSTORE not enabled for arm64

2014-12-17 Thread Ian Campbell

On Tue, 2014-12-16 at 17:52 +, Leif Lindholm wrote:
 Package: src:linux
 Severity: normal
 X-Debbugs-CC: i...@debian.org
 
 I noticed efivars was being automatically loaded on boot on my
 installed amd64 Jessie, but not on my arm64 Jessie. The
 installer/rescue image automatically loads it for both.
 Turns out on amd64, efivars is being pulled in as a dependency for
 efi_pstore, which is not built for arm64 since CONFIG_PSTORE is not
 enabled.
 
 Upstream, CONFIG_PSTORE is not enabled since CONFIG_MISC_FS is not
 enabled in the upstream defconfig. In debian, however, CONFIG_MISC_FS
 is enabled for all architectures, but CONFIG_PSTORE only for
 ia64/kernelarch-x86.
 
 Could we enable CONFIG_PSTORE for arm64 as well, please?

Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what
pstore is, so sorry if this is a silly question).

Any idea what causes efi_pstore to be loaded automatically?

Is efivars needed only for efibootmgr or are there other reasons to want
it?

(I don't have an x86 EFI system available to poke around and answer
these for myself).

I'm wondering if we ought to figure out how to load it automatically
independent of the pstore stuff, for all arches.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773255: Add TI OMAP5 uEVM board support db

2014-12-17 Thread Ian Campbell

On Wed, 2014-12-03 at 12:18 +0800, Chen Baozi wrote:
 Package: flash-kernel
 Version: 3.28
 Severity: wishlist
 Tags: patch
 
 With the patch attached, TI OMAP5 uEVM board is supported.

Thanks.

 +Machine: TI OMAP5 uEVM board
 +Method: generic
 +U-Boot-Kernel-Address: 0x80008000
 +U-Boot-Initrd-Address: 0x0
 +U-Boot-Script-Address: 0x0
 +U-Boot-Script-Name: bootscr.omap
 +Boot-Device: /dev/mmcblk1p1
 +Boot-Kernel-Path: uImage
 +Boot-Initrd-Path: uInitrd
 +Boot-Script-Path: boot.scr
 +Required-Packages: u-boot-tools

A few questions about u-boot on this platform:

  * Does it support the bootz command?
  * Does it support loading from sensible (i.e. other than FAT and
raw partitions) filesystems? (possibly via the generic load
command)?
  * Is /dev/mmcblk1p1 normally mounted (perhaps on /boot) or is it a
dedicated boot partition which is not normally mounted?

Ultimately what I'm getting at is, can this platform use
bootscr.uboot-generic? I'd like to try and default to that wherever
possible for new platforms. (bootscr.omap predates all of the above
facilities being generally available in u-boot AFAIK).

On a separate note, there is no DTB-Id field. Does this mean that the
platform comes with a DTB in the firmware?

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773377: [I18N:he] Updated Hebrew translation of debconf templates

2014-12-17 Thread Ian Campbell

Package: src:grub2
Severity: wishlist
Tags: patch, l10n
---BeginMessage---
Hello Ian,
Attached please find the modified he.po (rename back from grub2-he.po to
he.po).
If you got a modified he.po (based upon your 2014-12-13 E-mail) from
anyone else, you are welcome to disregard my contribution.

Regards,
--- Omer Zak



On Sat, 2014-12-13 at 20:37 +, Ian Campbell wrote:
 Hi,
 
 You are noted as the last translator of the debconf translation for
 grub2.
 
 Thank you to those of you who have already submitted translation updates.
 
 It has been brought to my attention that the phrase EFI removable path in 
 the
 previous English version is confusing and wrong and should really be EFI
 removable media path. Therefore I am sending out an updated po file (see
 attached) with this fixed.
 
 I'm afraid this will have marked any existing translations as fuzzy.
 
 Please send the updated file to me, or submit it as a wishlist bug against
 grub2. If you have already translated this template and the above change does
 not invalidate your translation then please let me know and I will un-fuzz it
 for you.
 
 At the same time some minor tweaks have been made to the English grammar. I
 think these should not affect translations.
 
 The complete wdiff for the English updates vs last time is:
 8--
 Template: grub2/force_efi_extra_removable
 Type: boolean
 Default: false
 _Description: Force extra installation to the EFI removable {+media+} path?
  Some EFI-based systems are buggy and do not handle new bootloaders correctly.
  If you force {+an+} extra installation of GRUB to the EFI removable 
 {+media+} path, [-it-]
  {+this+} should
  [-make sure-] {+ensure+} that this system will boot Debian correctly despite 
 such a
  problem. However, [-this-] {+it+} may remove the ability to boot any other 
 operating
  systems that also depend on this path. If so, you will need to [-ensure-] 
 {+make sure+} that
  GRUB is configured successfully to be able {+to+} boot any other OS 
 installations
  correctly.
 8--
 
 The deadline for receiving the updated translation is still
 Sun, 21 Dec 2014 19:58:50 +.
 
 Thanks in advance, and sorry for the inconvenience.
 
 Ian.
 


# translation of grub_debian_po_he.po to Hebrew
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
#
#
# Omer Zak w...@zak.co.il, 2010, 2012.
# Lior Kaplan kap...@debian.org, 2010, 2014.
msgid 
msgstr 
Project-Id-Version: grub_debian_po_he\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-17 18:35+0200\n
Last-Translator: Omer Zak\n
Language-Team: Hebrew kde-i18n-...@kde.org\n
Language: he\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
X-Generator: Lokalize 1.5\n
Plural-Forms:  nplurals=2; plural=(n != 1);\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr הטענה בשרשור מ-menu.lst?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr תסריטי העדכון של GRUB גילו הגדרות GRUB ישנות ב-‎‎/boot/grub.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
In order to replace the Legacy version of GRUB in your system, it is 
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image 
from your existing GRUB Legacy setup. This step can be automatically 
performed now.
msgstr 
כדי להחליף את גירסת GRUB הישנה במערכת שלך, מומלץ לשנות את ‎/boot/grub/menu.
lst כך שיבצע הטענה משורשרת של קוד האיתחול של GRUB 2 מהגדרות GRUB הישנות שלך. 
ניתן לבצע פעולה זו באופן אוטומטי עכשיו.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
It's recommended that you accept chainloading GRUB 2 from menu.lst, and 
verify that the new GRUB 2 setup works before it is written to the MBR 
(Master Boot Record).
msgstr 
מומלץ שתסכים להטענה משורשרת של GRUB 2 מ-menu.lst ותוודא שהגדרות GRUB 2 
החדשות עובדות עבורך, לפני שקוד האתחול נכתב ל-MBR (Master Boot Record)‎ שלך.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
Whatever your decision, you can replace the old MBR image with GRUB 2 later 
by issuing the following command as root:
msgstr 
לא משנה מהי החלטתך, ביכולתך להחליף יותר מאוחר את קוד האתחול הישן ב-MBR בקוד 
האתחול של  GRUB 2 ע\י מתן הפקודה הבאה כמשתמש-על:

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr התקנים להתקנת GRUB:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid 
The grub-pc package is being upgraded. This menu allows you to select which 
devices you'd like grub-install to be automatically run for, if any.
msgstr 
חבילת grub-pc משתדרגת כעת. תפריט זה מאפשר לך לבחור בהתקנים

Bug#773224: (preapproval) unblock: grub2/2.02~beta2-19

2014-12-17 Thread Ian Campbell

On Wed, 2014-12-17 at 18:12 -0400, David Prévot wrote:
 Le 17/12/2014 16:59, Ian Campbell a écrit :
  On Wed, 2014-12-17 at 20:15 +, Jonathan Wiltshire wrote:
  Control: tag -1 moreinfo
 
  On Mon, Dec 15, 2014 at 08:02:33PM +, Ian Campbell wrote:
  The main reason for asking for preapproval is I am trying to decide 
  whether to
  also include a fix for #771249 which is an update to the upstream 
  translations.
  Would that be acceptable or not?
 
  Tricky... how bad *are* the upstream translations? Is this just polish or
  are there some problems with them?
 
 The problem is they are incomplete and outdated: the upstream
 translation call happened after this version (2.02~beta2) was published,
 so all translations (as proposed in #771249) have been submitted
 upstream after this release.

Ah, I hadn't realised this.

 FWIW, the last patch proposed in #771249 was optimized WRT the size of
 the diff:

How was this optimization done? My thinking was that it would be better
for future updates to stick with the raw result of running linguas.sh,
but making a decision on a cleaned up diffstat lacking all the noise
would probably more helpful, so being able to rerun would be useful.

I notice that my previous cleanup attempt should have included ??_??.po
too, to reduce the noise from zh_CN.po, making the diffstat:

 ast.po   |   11 
 ca.po|  619 ++
 da.po|   28 
 de.po|  563 ++---
 eo.po|   16 
 es.po|  524 ++---
 fi.po|  778 +++
 fr.po|  244 --
 gl.po|   22 
 hu.po| 2429 +++
 id.po|  278 +-
 it.po|  596 ++---
 ja.po|   12 
 lt.po| 1493 +++---
 nb.po| 6429 +++
 nl.po|  629 ++
 pa.po|9 
 pl.po|  590 ++---
 pt_BR.po |  498 ++--
 ru.po|  529 ++---
 sl.po|   30 
 sv.po| 2658 +-
 tr.po|   38 
 uk.po|  232 --
 vi.po|  955 -
 zh_CN.po |   18 
 zh_TW.po |   20 
 27 files changed, 12585 insertions(+), 7663 deletions(-)

Which still differs from yours (includes a lot more translations for one
thing, but that might just be time having passed and more translations
being contributed)

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772946: [Fwd: Re: [UPDATED] grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2]

2014-12-16 Thread Ian Campbell


---BeginMessage---
HI Ian,

You can find fixed translation attached to this mail.

Thanks and best regards,

Dooteo

Jatorrizko mezua: lr., 2014-12-13 20:37 +, egilea: Ian Campbell
 Hi,
 
 You are noted as the last translator of the debconf translation for
 grub2.
 
 Thank you to those of you who have already submitted translation updates.
 
 It has been brought to my attention that the phrase EFI removable path in 
 the
 previous English version is confusing and wrong and should really be EFI
 removable media path. Therefore I am sending out an updated po file (see
 attached) with this fixed.
 
 I'm afraid this will have marked any existing translations as fuzzy.
 
 Please send the updated file to me, or submit it as a wishlist bug against
 grub2. If you have already translated this template and the above change does
 not invalidate your translation then please let me know and I will un-fuzz it
 for you.
 
 At the same time some minor tweaks have been made to the English grammar. I
 think these should not affect translations.
 
 The complete wdiff for the English updates vs last time is:
 8--
 Template: grub2/force_efi_extra_removable
 Type: boolean
 Default: false
 _Description: Force extra installation to the EFI removable {+media+} path?
  Some EFI-based systems are buggy and do not handle new bootloaders correctly.
  If you force {+an+} extra installation of GRUB to the EFI removable 
 {+media+} path, [-it-]
  {+this+} should
  [-make sure-] {+ensure+} that this system will boot Debian correctly despite 
 such a
  problem. However, [-this-] {+it+} may remove the ability to boot any other 
 operating
  systems that also depend on this path. If so, you will need to [-ensure-] 
 {+make sure+} that
  GRUB is configured successfully to be able {+to+} boot any other OS 
 installations
  correctly.
 8--
 
 The deadline for receiving the updated translation is still
 Sun, 21 Dec 2014 19:58:50 +.
 
 Thanks in advance, and sorry for the inconvenience.
 
 Ian.
 


# Basque translation for grub2
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
#
# Piarres Beobide p...@beobide.net, 2008.
# Iñaki Larrañaga Murgoitio doo...@zundan.com, 2008, 2009, 2010.
# Iñaki Larrañaga Murgoitio doo...@zundan.com, 2011, 2014.
msgid 
msgstr 
Project-Id-Version: grub2_2.02~beta2-18\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-16 09:10+0100\n
Last-Translator: Iñaki Larrañaga Murgoitio doo...@zundan.com\n
Language-Team: Basque debian-l10n-bas...@lists.debian.org\n
Language: eu\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
X-Generator: Lokalize 1.4\n
Plural-Forms: nplurals=2; plural=(n != 1);\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Kargatu menu.lst fitxategitik?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr 
GRUB eguneratzeko script-ek GRUB zahar baten konfigurazioa aurkitu dute /
boot/grub-en.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
In order to replace the Legacy version of GRUB in your system, it is 
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image 
from your existing GRUB Legacy setup. This step can be automatically 
performed now.
msgstr 
Sistemako GRUB zaharraren bertsioa behar bezala ordezkatzeko, gomendagarria 
da /boot/grub/menu.lst doitzea GRUB 2 dagoeneko instalatuta duzun GRUB 
zaharraren bidez kargatzeko. Urrats hau automatikoki egin daiteke orain.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
It's recommended that you accept chainloading GRUB 2 from menu.lst, and 
verify that the new GRUB 2 setup works before it is written to the MBR 
(Master Boot Record).
msgstr 
Gomendagarria da GRUB 2 menu.lst bidez kargatzea onartzea, eta GRUB 2-ren 
konfigurazioak zure beharrak betetzen dituela egiaztatzea MBRan (Master Boot 
Record) idatzi aurretik.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
Whatever your decision, you can replace the old MBR image with GRUB 2 later 
by issuing the following command as root:
msgstr 
Berdin dio zer erabakitzen duzun, MBRren irudi zaharra GRUB 2rekin ordeztu 
dezakezu supererabiltzaile (root) gisa honako komandoa exekutatuz:

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr GRUB instalatzeko gailuak:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid 
The grub-pc package is being upgraded. This menu allows you to select which 
devices you'd like grub-install to be automatically run for, if any.
msgstr 
grub-pc paketea

Bug#772983: kirkwood kernel image is too big

2014-12-16 Thread Ian Campbell

On Sun, 2014-12-14 at 19:26 +, Ben Hutchings wrote:
 I think it would be better to add an unconditional warning, rather than
 an error, when there is  1% free space left.  I realise this will be
 easy to ignore but it's still better than an unnecessary failure.

OK, makes sense. Here's what I'm currently running with, I'll push it
along with the size reduction stuff.

Ian.

commit 42c4d12d02edbf8ca065d4d21f8fdc668ec095cc
Author: Ian Campbell i...@debian.org
Date:   Mon Dec 15 21:25:38 2014 +

[armel] Warn if image size leaves less than 1% spare capacity in the flash.

This allows some slack for growth over the lifetime of a stable release.

diff --git a/debian/bin/buildcheck.py b/debian/bin/buildcheck.py
index 38241df..8cad299 100755
--- a/debian/bin/buildcheck.py
+++ b/debian/bin/buildcheck.py
@@ -172,6 +172,8 @@ class CheckImage(object):
 self.dir = dir
 self.arch, self.featureset, self.flavour = arch, featureset, flavour
 
+self.changelog = Changelog(version=VersionLinux)[0]
+
 self.config_entry_build = config.merge('build', arch, featureset, 
flavour)
 self.config_entry_image = config.merge('image', arch, featureset, 
flavour)
 
@@ -204,7 +206,20 @@ class CheckImage(object):
 out.write('Image too large (%d  %d)!  Refusing to continue.\n' % 
(size, value))
 return 1
 
-out.write('Image fits (%d = %d).  Continuing.\n' % (size, value))
+# 1% overhead is desirable in order to cope with growth
+# through the lifetime of a stable release. Warn if this is
+# not the case.
+usage = (float(size)/value) * 100.0
+out.write('Image size %d/%d, using %.2f%%.  ' % (size, value, usage))
+if size  value:
+sys.write('Too large.  Refusing to continue.\n')
+return 1
+elif usage = 99.0:
+out.write('Under 1%% space in %s.  ' % self.changelog.distribution)
+else:
+out.write('Image fits.  ')
+out.write('Continuing.\n')
+
 return 0
 
 
diff --git a/debian/changelog b/debian/changelog
index 6492cda..ae58576 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,6 +14,9 @@ linux (3.16.7-ckt2-2) UNRELEASED; urgency=medium
 OMAP5_DSS_HDMI, DISPLAY_ENCODER_TPD12S015, DISPLAY_CONNECTOR_HDMI,
 USB_DWC3_OMAP, EXTCON_PALMAS, TI_EMIF and DDR.
 Based on a patch from Chen Baozi (Closes: #772953)
+  * [armel] Change configuration to reduce kernel image size
+- Warn if image size leaves less than 1% spare capacity in the flash. This
+  allows some slack for growth over the lifetime of a stable release.
 
  -- Ben Hutchings b...@decadent.org.uk  Sat, 13 Dec 2014 11:45:48 +
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773222: [I18N:es] Updated Spanish translation of debconf templates

2014-12-15 Thread Ian Campbell

Package: src:grub2
Severity: wishlist
Tags: patch, l10n
---BeginMessage---

Reenvío por la corrección que han hecho desde arriba.

Sent with the suggested changes of the fuzzy removable path and done 
the propper translation according to these changes.


By the way, note me as the last translator, because Francisco Javier 
Cuadrado isn't in the list anymore.


Thanks.
--
Spanish Localization Team - Debian GNU/Linux
Free Software Foundation Associate Member
Manuel Venturi Porras Peralta
# grub2 po-debconf translation to Spanish
# Copyright (C) 2007, 2009, 2010, 2011 Software in the Public Interest
# This file is distributed under the same license as the grub2 package.
#
# Changes:
#   - Initial translation
#   Maria Germana Oliveira Blazeticgermanaolivei...@gmail.com, 2007
#
#   - Updates
#   Gary Ariel Sandi Vigabriel gary@gmail.com, 2009
#   Francisco Javier Cuadrado fcocuadr...@gmail.com, 2009, 2010, 2011
#	Manuel Venturi Porras Peralta vent...@openmailbox.org, 2014.
#
#   - Revisions
#   Innocent De Marchi tangram.pe...@gmail.com, 2010
#
# Traductores, si no conocen el formato PO, merece la pena leer la
# documentaciÃ³n de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
#   info -n '(gettext)PO Files'
#   info -n '(gettext)Header Entry'
#
# Equipo de traducciÃ³n al espaÃ±ol, por favor lean antes de traducir
# los siguientes documentos:
#
#   - El proyecto de traducciÃ³n de Debian al espaÃ±ol
# http://www.debian.org/intl/spanish/
# especialmente las notas y normas de traducciÃ³n en
# http://www.debian.org/intl/spanish/notas
#
#   - La guÃa de traducciÃ³n de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
#
msgid 
msgstr 
Project-Id-Version: grub2 1.99-5\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-07 16:09+\n
PO-Revision-Date: 2014-12-11 23:57+0100\n
Last-Translator: Manuel \Venturi\ Porras Peralta venturi@openmailbox.
org\n
Language-Team: EspaÃ±ol; Castellano debian-l10n-span...@lists.debian.org\n
Language: es\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=2; plural=(n != 1);\n
X-Generator: Gtranslator 2.91.6\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Â¿Desea cargar secuencialmente desde el fichero Â«menu.lstÂ»?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr 
Los ficheros de Ã³rdenes han detectado durante la actualizaciÃ³n una 
configuraciÃ³n heredada de una versiÃ³n anterior de GRUB en Â«/boot/grubÂ».

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
In order to replace the Legacy version of GRUB in your system, it is 
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image 
from your existing GRUB Legacy setup. This step can be automatically 
performed now.
msgstr 
Con el fin de reemplazar la versiÃ³n anterior de GRUB en el sistema, se 
recomienda configurar Â«/boot/grub/menu.lstÂ» para que cargue GRUB 2 a partir 
de la configuraciÃ³n heredada de GRUB. Este paso se puede hacer de forma 
automÃ¡tica.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
It's recommended that you accept chainloading GRUB 2 from menu.lst, and 
verify that the new GRUB 2 setup works before it is written to the MBR 
(Master Boot Record).
msgstr 
Se recomienda que acepte cargarlo secuencialmente desde el fichero Â«menu.
lstÂ» y que compruebe el buen funcionamiento del nuevo GRUB 2, antes de 
instalarlo en el MBR (Â«Master Boot RecordÂ»).

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
Whatever your decision, you can replace the old MBR image with GRUB 2 later 
by issuing the following command as root:
msgstr 
Sea cual sea su decisiÃ³n, puede reemplazar mÃ¡s tarde la imagen del MBR 
anterior con GRUB 2 ejecutando como administrador (Â«rootÂ») la orden 
siguiente:

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr Dispositivos donde puede instalar GRUB:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid 
The grub-pc package is being upgraded. This menu allows you to select which 
devices you'd like grub-install to be automatically run for, if any.
msgstr 
Se estÃ¡ actualizando el paquete grub-pc. Si lo desea, este menÃº le permite 
escoger en quÃ© dispositivos quiere ejecutar automÃ¡ticamente grub-install.

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid 
Running grub-install automatically is recommended in most situations, to 
prevent the installed GRUB core image from getting out of sync with GRUB 
modules or grub.cfg.
msgstr 
Se recomienda

Bug#773224: (preapproval) unblock: grub2/2.02~beta2-19

2014-12-15 Thread Ian Campbell

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock d-i

Version 2.02~beta2-18 (in Jessie, unblocked by #772959) added a new debconf
template.

A call for translations has been sent out which is has a deadline of the 21st,
I'd like to upload -19 the translations in. Hopefully soon after.

The main reason for asking for preapproval is I am trying to decide whether to
also include a fix for #771249 which is an update to the upstream translations.
Would that be acceptable or not?

Full disclosure, as you can see in #771249 there is some packaging faff
relating to the VCS but the eventual impact on the source package isn't so bad.
If anything I'd be going with the master-po-tp.org solution described in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771249#25 which is to move
the active translations to po-tp.org rather than messing around with the
baseline upstream branch as described earlier in the log.)

A diff is below, ignoring the *.po files themselves, and files which are copied
pristine from po=po-tp.org. I'm expecting the answer is no, but thought I
would ask.

I hope -19 will also contain the eventual fixes for #773004, #773092 (both
issue arising from the new stuff in -18), but I wouldn't expect you to
preapprove those without seeing them. (Just mentioning them for completeness)

This would need a d-i ack, I've CC-d Kibi and set the tag

Cheers,
Ian.

Diff based on contents of git+ssh://git.debian.org/git/pkg-grub/grub.git This is
just the bits associated with #771249.

$ git diff -M origin/master origin/people/ijc/master-po-tp.org  | filterdiff 
-p1 -x po-tp.org/\*.po | diffstat -p1
 Makefile.am|2 
 Makefile.util.def  |2 
 autogen.sh |4 
 configure.ac   |2 
 debian/.git-dpm|4 
 debian/changelog   |2 
 debian/clean   |1 
 debian/patches/po-tp.org--create.patch |16773 +++
 debian/patches/po-tp.org--orig.patch   |169479 
+
 debian/patches/po-tp.org--use.patch|  137 
 debian/patches/series  |3 
 debian/rules   |1 
 linguas.sh |8 
 po-tp.org/LINGUAS  |1 
 po-tp.org/POTFILES-shell.in|   18 
 po-tp.org/POTFILES.in  | 1262 
 po-tp.org/grub.pot | 6543 +
 tests/gettext_strings_test.in  |   12 
 tests/util/grub-shell.in   |2 
 19 files changed, 194238 insertions(+), 18 deletions(-)

unblock grub2/2.02~beta2-19

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773229: partman-base: partitioning should not offer emmc boot0, boot1 or rpmb partitions as possible installation targets

2014-12-15 Thread Ian Campbell

Source: partman-base
Version: 180
Severity: normal

I have an ARM board (Nvidia Jetson TK-1) which includes an on board eMMC. When
installing the list of devices to select for installation partitioning included
mmcblk1{boot0,boot1,rpmb}. (RPMB == Replay Protected Memory Block).

These are not normal partitions and should not be included. They are small (4M)
and have special hardware properties which makes them unsuitable for use. [0]
has a reasonable description of what they are, suffice it to say that they are
magic and shouldn't be messed with without care. They may not even be writable
via normal means. [1] has some more background.

lsblk says the following. sda is a SATA drive, mmcblk0 is a normal removable SD
card (where my install actually lives) and mmcblk1 is the one with the magic
partitions, which is soldered onto the board.

# lsblk 
NAME MAJ:MIN  RM   SIZE RO TYPE MOUNTPOINT
sda8:0 0 465.8G  0 disk 
├─sda1 8:1 0   243M  0 part 
├─sda2 8:2 0 462.7G  0 part 
├─sda3 8:3 0 1K  0 part 
└─sda5 8:5 0   2.9G  0 part 
mmcblk1rpmb  179:1024  0 4M  0 disk 
mmcblk1boot0 179:512   0 4M  1 disk 
mmcblk1boot1 179:768   0 4M  1 disk 
mmcblk0  179:0 0  14.5G  0 disk 
├─mmcblk0p1  179:1 0   243M  0 part /boot
├─mmcblk0p2  179:2 0  13.6G  0 part /
├─mmcblk0p3  179:3 0 1K  0 part 
└─mmcblk0p5  179:5 0   674M  0 part [SWAP]
mmcblk1  179:256   0  14.7G  0 disk 
├─mmcblk1p1  179:257   0 4G  0 part 
├─mmcblk1p2  179:258   0 4M  0 part 
├─mmcblk1p3  179:259   064M  0 part 
├─mmcblk1p4  179:260   0 4M  0 part 
├─mmcblk1p5  179:261   0 4M  0 part 
├─mmcblk1p6  179:262   0 4M  0 part 
├─mmcblk1p7  179:263   0 4M  0 part 
└─mmcblk1p8  179:264   0  10.6G  0 part 

I'm a bit confused why boot0/1 show up since parted already filters read only
devices (in parted_devices.c:process_device).

I'm not sure how to identify these magic devices other than by name.

Ian.

[0] 
http://www.ebv.com/fileadmin/design_solutions/php/download.php?path=fileadmin%2Fproducts%2FEBVuniversity%2F120912_Micron_e.MMC%2F120912_mic_emmc_Partitioning.pdf
[1] https://dev-nell.com/rpmb-emmc-errors-under-linux.html

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773233: linux: Packaging is not correctly enforcing ABI

2014-12-15 Thread Ian Campbell

Source: linux
Version: 3.16.7-2
Severity: serious
Justification: Not enforcing the ABI will potentially lead to mismatched 
modules, breakage of stable updates in Jessie etc

It appears that we are not currently correctly checking the ABI of kernels
against debian/abi/* at build time. buildcheck.py is reporting:
  Can't read ABI reference.  ABI not checked!  Continuing.

This can be seen in:
https://buildd.debian.org/status/fetch.php?pkg=linuxarch=amd64ver=3.16.7-1stamp=1415134305
https://buildd.debian.org/status/fetch.php?pkg=linuxarch=amd64ver=3.16.7-2stamp=1415320152
https://buildd.debian.org/status/fetch.php?pkg=linuxarch=amd64ver=3.16.7-ckt2-1stamp=1418093077

The ABI should have remained unchanged since 3.16.7-1 (when it was bumped to
4). However running ./debian/bin/abiupdate.py now results in:

 debian/abi/3.16.0-4/amd64_none_amd64 | 33 ++---
 1 file changed, 18 insertions(+), 15 deletions(-)

(similar for most arches and flavours).

The issue appears to be that buildcheck.py is looking for debian/abi/3.16-4,
while abiupdate.py is creating/updating 3.16.0-4.

The addition of .0 to the kernel version string happened in the same upload as
the switch to ABI 4. Looking at r21985 and r22132 it seems the intention was
for the ABI to include the .0. I've poked at buildcheck.py but haven#'t 6

If I add a symlink 3.16-4 - 3.16.0-4 then buildcheck.py finds the symbols and
complains of changes e.g. to iov_iter_get_pages.

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773060: [Fwd: Re: grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2]

2014-12-14 Thread Ian Campbell

---BeginMessage---
Thanks, it's much clearer now! Attaching an update, although I'm still
not sure how to localize it in a way that users would understand what
this option does as well. Perhaps an example that you gave me should be
given in that text as well?

Rimas

2014.12.13 22:48, Ian Campbell rašė:
The EFI removable media path is a per-arch path /EFI/BOOT/BOOT
$ARCH.EFI which EFI will use when booting removable media (usb sticks,
cdroms etc).

Some EFI implementations are buggy and require you to install the
bootloader (grub) to the removable media path even on non-removable
media (such as fixed HDDs etc). This template (and the associated
feature) is giving the user the option of installing an extra copy of
grub at the removable media path even on non-removable devices as a
workaround for those platforms.

HTH,
Ian.

On Sat, 2014-12-13 at 22:43 +0200, Rimas Kudelis wrote:
Hi,

still unsure: does EFI removable media path mean that the bootloader
will be installed into some removable (e.g. USB) drive, or something
else? Also, how is that path specific to EFI? Is it just some file that
will be put on the drive filesystem that EFI would later look for? Do
you maybe have an example of that path, which would make it clearer what
it is we're dealing with here?

Regards,
Rimas

2014.12.13 22:21, Ian Campbell wrote:
On Sat, 2014-12-13 at 22:06 +0200, Rimas Kudelis wrote:
Hi Ian,

here's an updated lt translation for Grub.
Thanks, I've forwarded to the BTS for tracking.

as a sidenote, even after reading both missing lines in English, I'm
still not sure what EFI removable path is or how to translate it.
It is normally called the removable media path, if that helps.

In fact I'm just about to send out a note to all translators about this,
since it is rather confusing.

Cheers,
Ian.

Regards,
Rimas

2014.12.11 21:59, Ian Campbell wrote:
Hi,

The deadline for receiving the updated translation is
Sun, 21 Dec 2014 19:58:50 +.

Thanks in advance,
Ian.

# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# Rimas Kudelis r...@akl.lt, 2012, 2014.
msgid
msgstr
Project-Id-Version: PACKAGE VERSION\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-14 10:37+0300\n
Last-Translator: Rimas Kudelis r...@akl.lt\n
Language-Team: Lithuanian komp...@konferencijos.lt\n
Language: lt\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=3; plural=(n%10==1 n%100!=11 ? 0 : n%10=2 (n%
10010 || n%100=20) ? 1 : 2);\n
X-Generator: Virtaal 0.7.1\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Paleisti grandininiu bÅ«du iÅ¡ âmenu.lstâ?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr
âGRUBâ atnaujinimo scenarijai aptiko senojo âGRUBâ konfigÅ«racinius failus â/
boot/grubâ aplanke.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
In order to replace the Legacy version of GRUB in your system, it is
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image
from your existing GRUB Legacy setup. This step can be automatically
performed now.
msgstr
Norint pakeisti senÄjÄ sistemoje esanÄiÄ âGRUBâ versijÄ, rekomenduojama
pirmiausia papildyti jos konfigÅ«racinÄ¯ failÄ â/boot/grub/menu.lstâ,
nurodant, kad ji paleistÅ³ âGRUB 2â grandininiu bÅ«du. Å Ä¯ Å¾ingsnÄ¯ galima
automatiÅ¡kai atlikti dabar.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
It's recommended that you accept chainloading GRUB 2 from menu.lst, and
verify that the new GRUB 2 setup works before it is written to the MBR
(Master Boot Record).
msgstr
PrieÅ¡ Ä¯raÅ¡ant âGRUB 2â Ä¯ disko paleidimo Ä¯raÅ¡Ä, rekomenduojama iÅ¡bandyti
grandininÄ¯ jos paleidimÄ iÅ¡ âmenu.lstâ ir Ä¯sitikinti, jog âGRUB 2â sÄranka
veikia tinkamai.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
Whatever your decision, you can replace the old MBR image with GRUB 2 later
by issuing the following command as root:
msgstr
Koks bebÅ«tÅ³ JÅ«sÅ³ sprendimas, vÄliau MBR turinÄ¯ galÄsite perraÅ¡yti âGRUB 2â
ar vÄlesne versija, ârootâ teisÄmis paleisdami komandÄ:

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in

Bug#773096: [I18N:eo] Updated Esperanto translation of debconf templates

2014-12-14 Thread Ian Campbell

Package: src:grub2
Severity: wishlist
Tags: patch, l10n
---BeginMessage---
Here it is, the updated file...

Regars,
Felipe

2014-12-13 20:59 GMT-02:00 Felipe Castro fef...@gmail.com:

 Oh, sorry, I just remarked it now, going to update it now...


 2014-12-13 20:54 GMT-02:00 Felipe Castro fef...@gmail.com:

 Hi, isn't this translation made through The Translation Project?

 2014-12-13 18:37 GMT-02:00 Ian Campbell i...@debian.org:

 Hi,

 You are noted as the last translator of the debconf translation for
 grub2.

 Thank you to those of you who have already submitted translation updates.

 It has been brought to my attention that the phrase EFI removable path
 in the
 previous English version is confusing and wrong and should really be EFI
 removable media path. Therefore I am sending out an updated po file (see
 attached) with this fixed.

 I'm afraid this will have marked any existing translations as fuzzy.

 Please send the updated file to me, or submit it as a wishlist bug
 against
 grub2. If you have already translated this template and the above change
 does
 not invalidate your translation then please let me know and I will
 un-fuzz it
 for you.

 At the same time some minor tweaks have been made to the English
 grammar. I
 think these should not affect translations.

 The complete wdiff for the English updates vs last time is:
 8--
 Template: grub2/force_efi_extra_removable
 Type: boolean
 Default: false
 _Description: Force extra installation to the EFI removable {+media+}
 path?
  Some EFI-based systems are buggy and do not handle new bootloaders
 correctly.
  If you force {+an+} extra installation of GRUB to the EFI removable
 {+media+} path, [-it-]
  {+this+} should
  [-make sure-] {+ensure+} that this system will boot Debian correctly
 despite such a
  problem. However, [-this-] {+it+} may remove the ability to boot any
 other operating
  systems that also depend on this path. If so, you will need to
 [-ensure-] {+make sure+} that
  GRUB is configured successfully to be able {+to+} boot any other OS
 installations
  correctly.
 8--

 The deadline for receiving the updated translation is still
 Sun, 21 Dec 2014 19:58:50 +.

 Thanks in advance, and sorry for the inconvenience.

 Ian.



# grub2 po-debconf translation to Esperanto
# Copyright (C) 2010, 2011, 2014 Software in the Public Interest
# This file is distributed under the same license as the grub2 package.
# Felipe Castro fef...@gmail.com, 2010, 2011, 2014.
#
msgid 
msgstr 
Project-Id-Version: grub2 2.02-18\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-13 21:14-0300\n
Last-Translator: Felipe Castro fef...@gmail.com\n
Language-Team: Esperanto debian-l10n-espera...@lists.debian.org\n
Language: eo\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
X-Generator: Poedit 1.6.10\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Ĉu ĉen-ŝargi (chainload) el menu.lst?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr 
Aktualigaj skriptoj de GRUB detektis agordon de la malaktuala GRUB en /boot/
grub.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
In order to replace the Legacy version of GRUB in your system, it is 
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image 
from your existing GRUB Legacy setup. This step can be automatically 
performed now.
msgstr 
Por anstataŭigi la malaktualan version de GRUB en via sistemo, oni 
rekomendas ke /boot/grub/menu.lst estu akomodita por ŝargi je ekŝarga bildo 
GRUB 2 el via ekzistanta agordo de malaktuala GRUB. Tiu ĉi paŝo povas esti 
aŭtomate farata nun.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
It's recommended that you accept chainloading GRUB 2 from menu.lst, and 
verify that the new GRUB 2 setup works before it is written to the MBR 
(Master Boot Record).
msgstr 
Oni rekomendas ke vi akceptu ĉen-ŝargi je GRUB 2 el menu.lst, kaj kontrolu 
ĉu via nova agordo de GRUB 2 bone funkcias antaŭ ol ĝi estu skribata al la 
MBR (Mastra Ekŝarga Registro).

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
Whatever your decision, you can replace the old MBR image with GRUB 2 later 
by issuing the following command as root:
msgstr 
Kia ajn estu via decido, per GRUB 2 vi povos poste anstataŭigi la malnovan 
bildon MBR, uzante la jenan komandon kiel root:

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr Aparatoj instalataj de GRUB:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid 
The grub-pc package is being upgraded. This menu allows you to select which

Bug#772930: [Fwd: Re: [UPDATED] grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2]

2014-12-14 Thread Ian Campbell


---BeginMessage---

Hi!

W dniu 13.12.2014 o 21:37, Ian Campbell pisze:

Please send the updated file to me, or submit it as a wishlist bug against
grub2.


Done.

Best regards,
Łukasz Dulny




pl.po.gz
Description: application/gzip
---End Message---

Bug#773092: grub-efi-amd64: grub efi installation failure

2014-12-14 Thread Ian Campbell

On Sun, 2014-12-14 at 13:51 +0530, Ritesh Raj Sarraf wrote:

Thanks for the report.

 grub-install: error: cannot open `/boot/efi/EFI/BOOT/BOOTX64.EFI': File
 exists.

The code uses GRUB_UTIL_FD_O_CREATTRUNC which == O_CREAT | O_TRUNC, to
open the destination file, so overwriting should be fine.

 Failed: grub-install --target=x86_64-efi --force-extra-removable

Perhaps you could run this by hand under strace (as root). Might give
some clue.

 Looking at that path:
 
 rrs@learner:~$ ls /boot/efi/EFI/BOOT/BOOTX64.EFI
 ls: cannot access /boot/efi/EFI/BOOT/BOOTX64.EFI: No such file or
 directory
 13:49 ♒♒♒   ☹  = 2  
 rrs@learner:~$ ls /boot/efi/EFI/BOOT/bootx64.efi 
 /boot/efi/EFI/BOOT/bootx64.efi*
 13:49 ♒♒♒  ☺ 

I wonder if this is a case-sensitivity thing (BOOTX64.EFI vs
bootx64.efi) and an oddity of vfat?

Steve, perhaps the answer is to remove the existing file first (which I
assume/hope due to the quirks of VFAT will work regardless of which case
is used).

Other EFI code doesn't bother, but in general it is dealing with paths
which we control, e.g. /boot/efi/EFI/Debian. /boot/efi/EFI/BOOT could be
expected to have stuff written by another OS in it I suppose.

 /dev/sda2 on /boot/efi type vfat
 (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro)

Did all of these options come from somewhere standard like d-i or did
you set them? I don't see them in current partman-efi.

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773092: grub-efi-amd64: grub efi installation failure

2014-12-14 Thread Ian Campbell

On Sun, 2014-12-14 at 16:47 +0530, Ritesh Raj Sarraf wrote:
 On 12/14/2014 04:00 PM, Ian Campbell wrote:
   /dev/sda2 on /boot/efi type vfat
   (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro)
  Did all of these options come from somewhere standard like d-i or did
  you set them? I don't see them in current partman-efi.
 
 
 It should have come by the installer.
 
 rrs@learner:/tmp$ cat /etc/fstab
 # /etc/fstab: static file system information.
 #
 # Use 'blkid' to print the universally unique identifier for a
 # device; this may be used with UUID= as a more robust way to name devices
 # that works even if disks are added and removed. See fstab(5).
 #
 # file system mount point   type  options   dump  pass
 /dev/mapper/LocalCrypt-ROOT /   ext4
 data=writeback,errors=remount-ro 0   1
 # /boot was on /dev/sda6 during installation
 UUID=33176b2c-e136-4c68-8a42-b11dfa8e052a /boot   ext4
 defaults0   2
 # /boot/efi was on /dev/sda2 during installation
 UUID=5C4B-9790  /boot/efi   vfatdefaults0   1
 /dev/mapper/LocalCrypt-SWAP noneswapsw  0
 0
 
 
 
 Based on the fstab comments, it looks like installer's.

Ah, yes, I forgot that /proc/mounts would include all the in-kernel
defaults but was looking at the d-i code to write /etc/fstab which
doesn't.

Ian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771249: Hacking pkg-grub/grub.git to allow po/* updates (Re: Bug#771249: Translation update)

2014-12-14 Thread Ian Campbell

On Sun, 2014-12-07 at 12:22 +, Ian Campbell wrote:
 Colin, since the below has a significant impact on the packaging git
 workflow I won't take it any further without your input...
 
 On Thu, 2014-11-27 at 19:06 -0400, David Prévot wrote:
  Please consider updating translations of grub2, as already provided by
  translators since upstream released 2.02~beta2.
 
 Sadly applying this patch is not as easy as it might seem, due to
 Tedious Packaging VCS Reasons(tm) :-/

I had another idea for how to solve this without messing around with
what the upstream branch contains, which is to create a parallel
po-tp.org and use that for the package build (this isn't too bad since
the po/* in git is basically a stub anyway).

I've pushed this to people/ijc/master-po-tp.org. IMHO this is more hacky
than the other solution but has the overriding benefit of not needing to
mess around with the meaning of upstream in git or the packaging
workflow and of being easily reversible.

I'm considering whether to upload something based on this approach in
-19 along with the updated debconf templates from the new EFI question
added in -18.

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772916: [Fwd: Re: [UPDATED] grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2]

2014-12-14 Thread Ian Campbell

---BeginMessage---
Hi,

I understood it as 'removable media', so I translated it right last time,
Now I just un-fuzzied these messages.

Thanks for your help

On Sun, Dec 14, 2014 at 2:37 AM, Ian Campbell i...@debian.org wrote:
Hi,

You are noted as the last translator of the debconf translation for
grub2.

Thank you to those of you who have already submitted translation updates.

I'm afraid this will have marked any existing translations as fuzzy.

At the same time some minor tweaks have been made to the English grammar. I
think these should not affect translations.

The deadline for receiving the updated translation is still
Sun, 21 Dec 2014 19:58:50 +.

Thanks in advance, and sorry for the inconvenience.

Ian.

# Kazakh translation for grub2.
# Copyright (C) 2010 The Grub team
# This file is distributed under the same license as the PACKAGE package.
# Baurzhan Muftakhidinov baurthefi...@gmail.com, 2010-2011.
#
msgid
msgstr
Project-Id-Version: master\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-14 20:02+0600\n
Last-Translator: Baurzhan Muftakhidinov baurthefi...@gmail.com\n
Language-Team: Kazakh kk...@googlegroups.com\n
Language: kk\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=1; plural=0;\n
X-Generator: Poedit 1.5.4\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr menu.lst ішінен тізбектей жүктелу керек пе?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr GRUB жаңарту скриптері /boot/grub ішінен орнатылған GRUB Legacy тапты.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
In order to replace the Legacy version of GRUB in your system, it is
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image
from your existing GRUB Legacy setup. This step can be automatically
performed now.
msgstr
GRUB Legacy нұсқасын алмастыру үшін, сіздің бар болып тұрған GRUB Legacy
орнатудың /boot/grub/menu.lst файлынан GRUB 2 жүктеушісін тізбектей жүктеуге
баптауға ұсынылады. Бұл қадам қазір автоматты түрде жасалуы мүмкін.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
It's recommended that you accept chainloading GRUB 2 from menu.lst, and
verify that the new GRUB 2 setup works before it is written to the MBR
(Master Boot Record).
msgstr
GRUB 2-ні menu.lst ішінен тізбектей жүктеуді қабылдау, және жаңа GRUB 2
орнатуы оны MBR (Басты жүктелу жазбасына) ішіне жазбас бұрын жұмыс
істейтінін тексеру ұсынылады.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
Whatever your decision, you can replace the old MBR image with GRUB 2 later
by issuing the following command as root:
msgstr
Шешіміңіз қандай болса да, кейін сіз әрқашан да ескі MBR бейнесін жаңа GRUB
2-мен ауыстыра аласыз, ол үшін root атынан келесі команда орындауыңыз керек:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid
The grub-pc package is being upgraded. This menu allows you to select which
devices you'd like grub-install to be automatically run for, if any.
msgstr
grub-pc дестесі жаңартылуда. Бұл мәзір сізге қай құрылғылар үшін grub-
install автожөнелту қалайтыныңызды көрсетуге мүмкін қылады, егер ондай

Bug#772983: kirkwood kernel image is too big

2014-12-14 Thread Ian Campbell

On Sat, 2014-12-13 at 18:09 +, Ben Hutchings wrote:
 On Sat, 2014-12-13 at 07:57 +, Ian Campbell wrote:
  On Fri, 2014-12-12 at 20:59 +, Ben Hutchings wrote:
 [...]
   I misread earlier - kirkwood is about 2.5 KB below the limit, not  1.
   Anyway, both kirkwood and orion5x have much less than 1% of growth room
   and ixp4xx has slightly less.  I think that some of the config changes I
   made in trunk should be applied to jessie/sid as well.
  
  I agree. I suppose you have some candidates in mind?
 
 Any of the things I disabled on trunk could reasonably be disabled on
 sid, except that I want to keep CONFIG_DEBUG_BUGVERBOSE enabled if
 possible.

In addition to what's in trunk I'll look at whether CONFIG_PCI_QUIRKS is
relevant on kirkwood, since according to the comment in config-reduced
it offers good bang for buck if it isn't needed (17K saving). USER_NS
might be a candidate too, especially if MEMCG and CHECPOINT_RESTORE is
going.

 kirkwood:  1606512   1613040   2097080   0.41 30.54

I think we are looking at limit of around 2076109 to give ourselves room
for 1% growth.

 orion5x:   1475936   1483632   1572792   0.52  6.56

Desired size is 1557064.

 Note that on sid, config-reduced applies to both ixp4xx and orion5x
 whereas on trunk it now applies to kirkwood and orion5x.

Noted.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772878: [Fwd: Re: [UPDATED] grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2]

2014-12-14 Thread Ian Campbell


---BeginMessage---
-=| Ian Campbell, 13.12.2014 20:37:14 + |=-
 It has been brought to my attention that the phrase EFI removable 
 path in the
 previous English version is confusing and wrong and should really be EFI
 removable media path. Therefore I am sending out an updated po file (see
 attached) with this fixed.
 
 I'm afraid this will have marked any existing translations as fuzzy.
 
 Please send the updated file to me, or submit it as a wishlist bug against
 grub2. If you have already translated this template and the above change does
 not invalidate your translation then please let me know and I will un-fuzz it
 for you.

Please un-fuzz the Bulgarian translation of the two affected templates 
(one for the title and one for the detailed description). The EFI 
removable path was indeed confusing and I had to search the Web for 
it. The translation considers my findings, that it is indeed EFI 
removable media path, or EFI path for removable media.

The other fixes in the English text also do not affect the Bulgarian 
translation.


Cheers,
dam


signature.asc
Description: Digital signature
---End Message---

Bug#772983: kirkwood kernel image is too big

2014-12-14 Thread Ian Campbell

On Fri, 2014-12-12 at 20:59 +, Ben Hutchings wrote:
 That implies we want to allow for about 1% growth
 from the size in the .0 release.

I'm considering something like this. What do you think?

diff --git a/debian/bin/buildcheck.py b/debian/bin/buildcheck.py
index a6f6f06..5bb815c 100755
--- a/debian/bin/buildcheck.py
+++ b/debian/bin/buildcheck.py
@@ -174,6 +174,8 @@ class CheckImage(object):
 self.dir = dir
 self.arch, self.featureset, self.flavour = arch, featureset, flavour
 
+self.changelog = Changelog(version=VersionLinux)[0]
+
 self.config_entry_build = config.merge('build', arch, featureset, 
flavour)
 self.config_entry_image = config.merge('image', arch, featureset, 
flavour)
 
@@ -206,7 +208,18 @@ class CheckImage(object):
 out.write('Image too large (%d  %d)!  Refusing to continue.\n' % 
(size, value))
 return 1
 
-out.write('Image fits (%d = %d).  Continuing.\n' % (size, value))
+# 1% overhead is desirable in order to cope with growth
+# through the lifetime of a stable release. Enforce that
+# development releases leave sufficient overhead.
+soft_value = value * 0.99
+if size  soft_value:
+out.write('Image has 1%% overhead (%d  %d).' % (size, 
soft_value))
+if self.changelog.distribution in [unstable, experimental, 
UNRELEASED]:
+out.write(' Refusing to continue.\n')
+return 1
+out.write(' Continuing.\n')
+
+out.write('Image fits (%d = %d, soft %d).  Continuing.\n' % (size, 
value, soft_value))
 return 0
 
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773054: [Fwd: Re: [UPDATED] grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2]

2014-12-14 Thread Ian Campbell

---BeginMessage---
On Sat, Dec 13, 2014 at 08:37:13PM +, Ian Campbell wrote:

previous English version is confusing and wrong and should really be EFI
removable media path. Therefore I am sending out an updated po file (see
attached) with this fixed.

I'm afraid this will have marked any existing translations as fuzzy.

At the same time some minor tweaks have been made to the English grammar. I
think these should not affect translations.

Actually I used some equivalent of the word media in the previous version of
the translation. :-) Anyway, I reworded it so that it seemed more correct and
attached.

# Belarusian translation of grub2 templates
# Copyright (C) 2009 respective translators (see below)
# This file is distributed under the same license as the grub2 package.
# Hleb Rubanau g.ruba...@gmail.com, 2009,
# Viktar Siarheichyk v...@eq.by, 2010, 2012, 2014.
# Viktar Siarheichyk v...@fsfe.org, 2014.
msgid
msgstr
Project-Id-Version: be\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-15 05:50+0300\n
Last-Translator: Viktar Siarheichyk v...@fsfe.org\n
Language-Team: Debian l10n team for Belarusian debian-l10n-
belarus...@lists.debian.org\n
Language: be\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=utf-8\n
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=3; plural=n%10==1 n%100!=11 ? 0 : n%10=2 n%10=
4 (n%10010 || n%100=20) ? 1 : 2;\n
X-Generator: Virtaal 0.7.1\n
X-Poedit-Language: Belarusian\n
X-Poedit-Country: BELARUS\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Ланцуговая загрузка з menu.lst?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr
Скрыпты абнаўлення GRUB выявілі папярэднюю версію GRUB, усталяваную ў /boot/
grub.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
In order to replace the Legacy version of GRUB in your system, it is
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image
from your existing GRUB Legacy setup. This step can be automatically
performed now.
msgstr
Каб замяніць папярэднюю версію GRUB у Вашай сістэме, пажадана выправіць
файл /boot/grub/menu.lst такім чынам, каб GRUB 2 загружаўся з існуючай
папярэдняй версіі GRUB. Зараз можна зрабіць гэтую наладку аўтаматычна.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
It's recommended that you accept chainloading GRUB 2 from menu.lst, and
verify that the new GRUB 2 setup works before it is written to the MBR
(Master Boot Record).
msgstr
Раім абраць ланцуговую загрузку GRUB 2 з menu.lst, і праверыць, што нанова
ўсталяваны GRUB 2 працуе, перад тым як усталёўваць яго ў галоўны загрузачны
запіс (MBR, Master Boot Record).

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
Whatever your decision, you can replace the old MBR image with GRUB 2 later
by issuing the following command as root:
msgstr
Як бы вы ні вырашылі, можна пазней замяніць стары вобраз MBR на GRUB 2, калі
выканаць як root наступныя каманды:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid
The grub-pc package is being upgraded. This menu allows you to select which
devices you'd like grub-install to be automatically run for, if any.
msgstr
x`Пакет grub-pc абнаўляецца. Гэтае меню дазваляе абраць, для якіх прыладаў
трэба, калі ўвогуле трэба, аўтаматычна запускаць grub-install.

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid
Running grub-install automatically is recommended in most situations, to
prevent the installed GRUB core image from getting out of sync with GRUB
modules or grub.cfg.
msgstr
У большасці выпадкаў рэкамендуецца запускаць grub-install аўтаматычна, каб
усталяваны асноўны вобраз GRUB заставаўся ў адпаведнасці з модулямі GRUB і
grub.cfg.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid
If you're unsure which drive is designated as boot drive by your BIOS, it is
often a good idea to install GRUB to all of them.
msgstr
Калі вы не пэўныя, якая прылада ў вашым BIOS прызначаная як галоўная, то
хутчэй за ўсё лепей будзе ўсталяваць GRUB на іх усіх.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid
Note: it is possible

Bug#773161: Reopening the bug

2014-12-14 Thread Ian Campbell

On Mon, 2014-12-15 at 14:34 +0700, Theppitak Karoonboonyanan wrote:
 Control: reopen -1
 
 Sorry for the confusion. Bug #773161 and #773160 were duplicated
 by mistake, as I took reportbug message wrongly as a failure.
 So, I merged them, before Ian closed one and tagged the other.
 The result is that they are both closed and tagged now.

Yes, sorry I hadn't spotted the merging when I did that.

 So, I'm reopenning the merged bug until it's really closed.

Thanks!

 Please just mention one of the bugs when closing it.

Sure.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772983: kirkwood kernel image is too big

2014-12-13 Thread Ian Campbell

On Fri, 2014-12-12 at 20:59 +, Ben Hutchings wrote:
  I had originally planned to switch QNAP over for 3.16 but it wasn't
  quite ready upstream (I've forgotten why). The board files went away in
  3.17 so in experimental (v3.18) appending is necessary. Once I've worked
  out some kinks with kirkwood in v3.18 I was planning to upload a
  corresponding flash-kernel which does appending for those platforms.
 
 In case you hadn't noticed, I've changed the size check in trunk so it
 can optionally include the size of the largest DTB.  That is somewhat
 pessimistic in that the largest DTB probably won't be used in
 conjunction with the smallest partition.

I had seen, I think it's a good idea despite the short comings. The size
difference between the smallest and largest DTB is only 14K so it's
pretty close either way.

To be more accurate we'd need to store the name of the dtb corresponding
to the smallest partition in the kernel source, making the (reasonable)
assumption that the second smallest partition is at least 14K larger
than the smallest. I don't know that it's worth it though.

 I enabled this for both
 kirkwood and orion5x, though now I think I should not have done so for
 orion5x.

I think you were right to do so even for orion5x (in trunk at least).

Right now there are only a small numbers of dtbs built on orion5x, and
they are all 8K. As upstream transitions from board files to dtb that
number (and the sizes) will grow, but it's not skewing our results too
much to check now.

At some point upstream will remove the board file support for orion5x,
so I think it is fine to start checking the sizes now even while we are
still on board files, so we are prewarned.

 [...]
 2094680  2097080
   2094680 + 10394 = 2105074  2097080
   
   The orion5x machine with the smallest known kernel partition is D-Link
   DNS-323, with 1572792 bytes space.  We currently have less than 1 KB
   to spare here.  Thankfully this machine is still supported by board
   code and doesn't need a DTB.  But if any of the other orion5x machines
   we intend to support have a similarly small kernel partition and
   require a DTB they will not work with this version.
  
  I don't know much about orion5x, but the flash-kernel db tells me that
  we don't currently append a dtb on any platform there.
  
  1k is rather tight though, even if appending isn't needed. A security
  update adding 1k of binary size wouldn't be totally out of the question
  and it would be unfortunate to have to start disabling features in a
  security update.
 
 Yes, you're right.  For comparison, this is what's happened over the
 course of wheezy stable updates:
 
3.2.41-2  3.2.63-2  limit growth%  growth limit%
 iop32x:1427968   1434632   1441784   0.47  0.97
 ixp4xx:1424696   1428920   1441760   0.30  1.20
 kirkwood:  1606512   1613040   2097080   0.41 30.54
 orion5x:   1475936   1483632   1572792   0.52  6.56
 
 They've grown by up to about 0.5% over the course of 20 months of a ~36
 month support period.  That implies we want to allow for about 1% growth
 from the size in the .0 release.  Thankfully they did all start with
 this much space.
 
 Currently in sid we have:
 
3.16.7-ckt2-1  limit growth limit%
 ixp4xx:14297121441760   0.84%
 kirkwood:  20944882097080   0.12%
 orion5x:   15682481572792   0.29%
 
 I misread earlier - kirkwood is about 2.5 KB below the limit, not  1.
 Anyway, both kirkwood and orion5x have much less than 1% of growth room
 and ixp4xx has slightly less.  I think that some of the config changes I
 made in trunk should be applied to jessie/sid as well.

I agree. I suppose you have some candidates in mind?

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773014: git-buildpackage: please support git submodules

2014-12-13 Thread Ian Campbell

Package: git-buildpackage
Version: 0.6.22
Severity: wishlist

The grub packaging git tree[0] uses a git submodule for the debian/grub-extras
directory. However git-buildpackage is unaware of this and ignores it, the
.debian.tar.xz ends up containing the directory itself but not its contents.

It would be really useful if gbp could support this scenario.

Thanks,
Ian.

[0] http://anonscm.debian.org/cgit/pkg-grub/grub.git/

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages git-buildpackage depends on:
ii  devscripts2.14.11
ii  git   1:2.1.3-1
ii  man-db2.7.0.2-4
ii  python2.7.8-2
ii  python-dateutil   2.2-2
ii  python-pkg-resources  5.5.1-1

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.73
ii  pristine-tar  1.32

Versions of packages git-buildpackage suggests:
ii  python-notify  0.1.1-4
ii  unzip  6.0-12+b1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#770912: initramfs-tools: Add xhci-pci to base modules (linux 3.18)

2014-12-13 Thread Ian Campbell

On Tue, 2014-11-25 at 01:23 -0500, Brian Campbell wrote:
 While trying out an upstream kernel build to debug another issue, I
 discovered that I couldn't enter any text at my disk encryption
 password prompt.  After bisecting, I discovered that this was due to a
 patch that split xhci-pci out into a separate module.  Sure enough,
 adding that to my initrd modules list allowed me to boot and decrypt
 on later kernels.
 
 This should be added to the standard base modules list to avoid anyone
 else running into this problem.

We should add xhci-plat-hcd.ko too I think.

NB, I'm in the process of adding these to the d-i udebs for 3.18 onwards too.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772771: grub2: [INTL:fr] French debconf templates translation update

2014-12-13 Thread Ian Campbell

On Sat, 2014-12-13 at 11:22 +0100, Christian PERRIER wrote:
 Quoting Ian Campbell (i...@debian.org):
  On Wed, 2014-12-10 at 23:22 +0100, Christian Perrier wrote:
   Package: grub2
   Version: N/A
   Severity: wishlist
   Tags: patch l10n
   
   Please find attached the french debconf templates update, proofread by the
   debian-l10n-french mailing list contributors.
   
   If you do not already use it, you might consider using the
   podebconf-report-po utility, which helps warning translators about
   changes when you modify some debconf templates in your packages.
  
  Thanks, I wasn't aware of this tool and was wondering if I was supposed
  to do something.
  
  Looking at podebconf-report-po it seems I could still use it to send out
  a request and link them all to this report with:
  podebconf-report-po --bts=772771
  I'm assuming you haven't already done so?
  
  If not then I'll send out a call for translations and collect them in
  this bug.
 
 As you had suggestions from other translators to slightly modify the
 templates.

I just CCd you on my reply to those suggestions. If it is decided to go
ahead and update the translations then I'll do as you asked.

Cheers,
Ian.

  Would you mind doing the following:
 
 - put my fr.po in place
 - change the templates with the new wording
 - run debconf-updatepo
 - send me (and to the bug report) the new fr.po file (which will have
 1 o2 fuzzy strings because of the change in English wording
 
 Then, I'll update my translation and send it back to the bug report.
 
 Many thanks in advance.
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard

2014-12-13 Thread Ian Campbell

Control: tags -1 +pending

On Mon, 2014-12-01 at 02:12 +0800, Chen Baozi wrote:
 With the patch attached, the OMAP5432 uEVM can be supported by the current
 unstable kernel.

Thanks, I've applied this to the debian-kernel svn tree for the next
unstable upload. For future reference the debian/config stuff is
supposed to be alphabetical by Kconfig path, so I've moved the things
you added around.

At some point (e.g. after upload, when this bug gets closed) please
could you update https://wiki.debian.org/DebianKernel/ARMMP with this
new platform.

After eyeballing the resulting .config diff I've also enabled the
following on top of what you did:
- CONFIG_PINCTRL_PALMAS
- CONFIG_GPIO_PALMAS
- CONFIG_RTC_DRV_PALMAS

If you care about Debian Installer support then you should also check
whether any of the newly added modules need to be added to the installer
udebs (which you can mainly do via the module lists under
debian/installer/armhf/modules/armhf-armmp/). I've added dwc3-omap to
usb-modules already since that one seemed obvious.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773014: git-buildpackage: please support git submodules

2014-12-13 Thread Ian Campbell

On Sat, 2014-12-13 at 12:58 +0100, Guido Günther wrote:
 On Sat, Dec 13, 2014 at 08:12:00AM +, Ian Campbell wrote:
  Package: git-buildpackage
  Version: 0.6.22
  Severity: wishlist
  
  The grub packaging git tree[0] uses a git submodule for the 
  debian/grub-extras
  directory. However git-buildpackage is unaware of this and ignores it, the
  .debian.tar.xz ends up containing the directory itself but not its contents.
  
  It would be really useful if gbp could support this scenario.
 
 Check the --git-submodules option.

Thanks, I must have searched the wrong manpage or typo-ed something,
because I can't explain how I missed it otherwise!

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773060: [I18N:lt] Updated Lithuanian translation of debconf templates

2014-12-13 Thread Ian Campbell

Package: src:grub2
Severity: wishlist
Tags: patch, l10n

---BeginMessage---
Hi Ian,

here's an updated lt translation for Grub.

as a sidenote, even after reading both missing lines in English, I'm
still not sure what EFI removable path is or how to translate it.

Regards,
Rimas

2014.12.11 21:59, Ian Campbell wrote:
Hi,

The deadline for receiving the updated translation is
Sun, 21 Dec 2014 19:58:50 +.

Thanks in advance,
Ian.

# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# Rimas Kudelis r...@akl.lt, 2012, 2014.
msgid
msgstr
Project-Id-Version: PACKAGE VERSION\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-07 16:09+\n
PO-Revision-Date: 2014-12-13 22:00+0300\n
Last-Translator: Rimas Kudelis r...@akl.lt\n
Language-Team: Lithuanian komp...@konferencijos.lt\n
Language: lt\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=3; plural=(n%10==1 n%100!=11 ? 0 : n%10=2 (n%
10010 || n%100=20) ? 1 : 2);\n
X-Generator: Virtaal 0.7.1\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Paleisti grandininiu bÅ«du iÅ¡ âmenu.lstâ?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
It's recommended that you accept chainloading GRUB 2 from menu.lst, and
verify that the new GRUB 2 setup works before it is written to the MBR
(Master Boot Record).
msgstr
PrieÅ¡ Ä¯raÅ¡ant âGRUB 2â Ä¯ disko paleidimo Ä¯raÅ¡Ä, rekomenduojama iÅ¡bandyti
grandininÄ¯ jos paleidimÄ iÅ¡ âmenu.lstâ ir Ä¯sitikinti, jog âGRUB 2â sÄranka
veikia tinkamai.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
Whatever your decision, you can replace the old MBR image with GRUB 2 later
by issuing the following command as root:
msgstr
Koks bebÅ«tÅ³ JÅ«sÅ³ sprendimas, vÄliau MBR turinÄ¯ galÄsite perraÅ¡yti âGRUB 2â
ar vÄlesne versija, ârootâ teisÄmis paleisdami komandÄ:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid
The grub-pc package is being upgraded. This menu allows you to select which
devices you'd like grub-install to be automatically run for, if any.
msgstr
Atnaujinamas âgrub-pcâ paketas. Å iame meniu galite pasirinkti, ar kuriems
nors Ä¯renginiams komanda âgrub-installâ turÄtÅ³ bÅ«ti paleidÅ¾iama automatiÅ¡kai.

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid
Running grub-install automatically is recommended in most situations, to
prevent the installed GRUB core image from getting out of sync with GRUB
modules or grub.cfg.
msgstr
Daugumoje atvejÅ³ rekomenduojama automatiÅ¡kai vykdyti âgrub-installâ, kad
bÅ«tÅ³ iÅ¡vengta neatitikimÅ³ tarp pagrindinio âGRUBâ atvaizdÅ¾io ir âGRUBâ
moduliÅ³ ar âgrub.cfgâ failo.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid
If you're unsure which drive is designated as boot drive by your BIOS, it is
often a good idea to install GRUB to all of them.
msgstr
Jeigu tiksliai neÅ¾inote, kurÄ¯ diskÄ kompiuterio BIOS laiko paleidimo disku,
galite Ä¯diegti âGRUBâ Ä¯ visus diskus â daÅ¾niausiai tai yra nebloga mintis.

Bug#772771: grub2: [INTL:fr] French debconf templates translation update

2014-12-13 Thread Ian Campbell

On Sat, 2014-12-13 at 11:22 +0100, Christian PERRIER wrote:
 As you had suggestions from other translators to slightly modify the
 templates. Would you mind doing the following:
 
 - put my fr.po in place
 - change the templates with the new wording
 - run debconf-updatepo
 - send me (and to the bug report) the new fr.po file (which will have
 1 o2 fuzzy strings because of the change in English wording
 
 Then, I'll update my translation and send it back to the bug report.

You've probably already seen the updated call for translations but here
it is as well.

Cheers,
Ian.

# translation of fr.po to French
# Translation of grub2 debconf templates to French
# Copyright (C) 2008-2010 Debian French l10n debian-l10n-fre...@lists.debian.org
# This file is distributed under the same license as the grub2 package.
#
# Christian Perrier bubu...@debian.org, 2007, 2008, 2009, 2010, 2011, 2014.
msgid 
msgstr 
Project-Id-Version: fr\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-10 23:21+0100\n
Last-Translator: Christian Perrier bubu...@debian.org\n
Language-Team: French debian-l10n-fre...@lists.debian.org\n
Language: fr\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
X-Generator: Lokalize 1.5\n
Plural-Forms: nplurals=2; plural=(n  1);\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Faut-il enchaÃ®ner le chargement depuis menu.lstÂ ?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr Une installation standard de GRUB a Ã©tÃ© dÃ©tectÃ©e dans /boot/grub.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
In order to replace the Legacy version of GRUB in your system, it is 
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image 
from your existing GRUB Legacy setup. This step can be automatically 
performed now.
msgstr 
Afin de remplacer cette installation, il est recommandÃ© de modifier /boot/
grub/menu.lst pour charger GRUBÂ 2 depuis l'installation standard de GRUB 
(Â«Â chainloadÂ Â»). Veuillez choisir si vous souhaitez effectuer cette 
modification.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
It's recommended that you accept chainloading GRUB 2 from menu.lst, and 
verify that the new GRUB 2 setup works before it is written to the MBR 
(Master Boot Record).
msgstr 
Il est recommandÃ© de choisir cette option pour pouvoir confirmer le bon 
fonctionnement de GRUBÂ 2 avant de l'installer directement sur le secteur 
d'amorÃ§age (MBRÂ : Â«Â Master Boot RecordÂ Â»).

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
Whatever your decision, you can replace the old MBR image with GRUB 2 later 
by issuing the following command as root:
msgstr 
Quel que soit votre choix, vous pourrez, plus tard, remplacer l'ancien 
secteur d'amorÃ§age par GRUBÂ 2 avec la commande suivante, exÃ©cutÃ©e avec les 
privilÃ¨ges du superutilisateurÂ :

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr PÃ©riphÃ©riques oÃ¹ installer GRUBÂ :

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid 
The grub-pc package is being upgraded. This menu allows you to select which 
devices you'd like grub-install to be automatically run for, if any.
msgstr 
Le paquet grub-pc est en cours de mise Ã  jour. Ce menu permet de choisir 
pour quels pÃ©riphÃ©riques vous souhaitez exÃ©cuter la commande grub-install 
automatiquement.

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid 
Running grub-install automatically is recommended in most situations, to 
prevent the installed GRUB core image from getting out of sync with GRUB 
modules or grub.cfg.
msgstr 
Il est en gÃ©nÃ©ral recommandÃ© d'exÃ©cuter grub-install automatiquement, afin 
d'Ã©viter la situation oÃ¹ l'image de GRUB est dÃ©synchronisÃ©e avec les modules 
de GRUB ou le fichier grub.cfg.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid 
If you're unsure which drive is designated as boot drive by your BIOS, it is 
often a good idea to install GRUB to all of them.
msgstr 
Si vous n'avez pas la certitude du pÃ©riphÃ©rique utilisÃ© comme pÃ©riphÃ©rique 
d'amorÃ§age par le BIOS, il est en gÃ©nÃ©ral conseillÃ© d'installer GRUB sur 
l'ensemble des pÃ©riphÃ©riques.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid 
Note: it is possible to install GRUB to partition boot records as well, and 
some appropriate partitions are offered here. However, this forces GRUB to 
use the blocklist mechanism, which makes it less reliable,

Bug#772922: [Fwd: Re: [UPDATED] grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2]

2014-12-13 Thread Ian Campbell

---BeginMessage---

No big deal, thanks for your effort.
Here's the update for Icelandic.

Sveinn

Þann lau 13.des 2014 20:37, skrifaði Ian Campbell:

Hi,

You are noted as the last translator of the debconf translation for
grub2.

Thank you to those of you who have already submitted translation updates.

It has been brought to my attention that the phrase EFI removable path in the
previous English version is confusing and wrong and should really be EFI
removable media path. Therefore I am sending out an updated po file (see
attached) with this fixed.

I'm afraid this will have marked any existing translations as fuzzy.

At the same time some minor tweaks have been made to the English grammar. I
think these should not affect translations.

The complete wdiff for the English updates vs last time is:
8--
Template: grub2/force_efi_extra_removable
Type: boolean
Default: false
_Description: Force extra installation to the EFI removable {+media+} path?
Some EFI-based systems are buggy and do not handle new bootloaders correctly.
If you force {+an+} extra installation of GRUB to the EFI removable {+media+}
path, [-it-]
{+this+} should
[-make sure-] {+ensure+} that this system will boot Debian correctly despite
such a
problem. However, [-this-] {+it+} may remove the ability to boot any other
operating
systems that also depend on this path. If so, you will need to [-ensure-]
{+make sure+} that
GRUB is configured successfully to be able {+to+} boot any other OS
installations
correctly.
8--

The deadline for receiving the updated translation is still
Sun, 21 Dec 2014 19:58:50 +.

Thanks in advance, and sorry for the inconvenience.

Ian.

# translation of grub_debian_po_is.po to Icelandic
# Copyright (C) 2010 Free Software Foundation
# This file is distributed under the same license as the GRUB package.
#
# Sveinn Ã Felli svei...@nett.is, 2010, 2011, 2012, 2014.
msgid
msgstr
Project-Id-Version: grub_debian_po_is\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2014-12-13 23:20+\n
Last-Translator: Sveinn Ã Felli s...@fellsnet.is\n
Language-Team: Icelandic translation-team...@lists.sourceforge.net\n
Language: is\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
\n
X-Generator: Lokalize 1.5\n
Plural-Forms: nplurals=2; plural=n != 1;\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr RaÃ°hlaÃ°a (chainload) Ãºr menu.lst?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr
UppfÃ¦rsluskriftur GRUB hafa fundiÃ° eldri uppsetningu GRUB Ã /boot/grub.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
In order to replace the Legacy version of GRUB in your system, it is
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image
from your existing GRUB Legacy setup. This step can be automatically
performed now.
msgstr
Til aÃ° skipta eldri uppsetningu GRUB Ãºt af kerfinu, Ã¾Ã¡ er mÃ¦lt meÃ° Ã¾vÃ aÃ° /
boot/grub/menu.lst sÃ© stillt til aÃ° raÃ°hlaÃ°a (chainload) GRUB 2 rÃ¦sidiskmynd
frÃ¡ Ã¾essari eldri uppsetningu Ã¡ GRUB. HÃ¦gt er aÃ° framkvÃ¦ma Ã¾etta skref
sjÃ¡lfvirkt nÃºna.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
It's recommended that you accept chainloading GRUB 2 from menu.lst, and
verify that the new GRUB 2 setup works before it is written to the MBR
(Master Boot Record).
msgstr
MÃ¦lt meÃ° Ã¾vÃ aÃ° Ã¾Ãº samÃ¾ykkir aÃ° raÃ°hlaÃ°a GRUB 2 Ãºr menu.lst, auk Ã¾ess aÃ° Ã¾Ãº
skoÃ°ir hvort nÃ½ja GRUB 2 uppsetningin virki fyrir Ã¾ig, Ã¡Ã°ur en Ã¾etta er
skrifaÃ° Ã¡ MBR rÃ¦sigeirann (Master Boot Record).

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
Whatever your decision, you can replace the old MBR image with GRUB 2 later
by issuing the following command as root:
msgstr
HvaÃ° svosem Ã¾Ãº Ã¡kveÃ°ur, Ã¾Ã¡ getur Ã¾Ãº sÃÃ°ar skipt gÃ¶mlu MBR myndinni Ãºt fyrir
GRUB2 meÃ° Ã¾vÃ aÃ° gefa eftirfarandi skipun (sem kerfisstjÃ³ri/root):

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr GRUB uppsetningartÃ¦ki:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid
The grub-pc package is being upgraded. This menu allows you to select which
devices you'd like grub-install to be automatically run for, if any.
msgstr
VeriÃ° er aÃ° uppfÃ¦ra grub-pc pakkann. Ãessi valmynd gerir Ã¾Ã©r kleift aÃ° velja
af hvaÃ°a tÃ¦kjum

Bug#773068: [I18N:gr] Updated Greek translation of debconf templates

2014-12-13 Thread Ian Campbell

Package: src:grub2
Severity: wishlist
Tags: patch, l10n
---BeginMessage---
Dear Ian
I completed the gaps and also proof read the file. I changed the phrase
φορτωτής εκκίνησης that was used for bootloader το πρόγραμμα
εκκίνησης since φορτωτής is the loader (in compilers) and
πρόγραμμα(=program as you might have figured out :P ) is the term we use
for everything that runs (including 'script'). On the other hand, it is
even more common to use the english term 'bootloader' and 'script' but I
followed the path of the previous translator and translated everything
except for names. Let me know if you prefer these or other terms to be
preserved in English. Any feedback is welcome.

Best wishes
Panagiotis Georgakopoulos
ECE Student @ NTUAthens

2014-12-13 22:37 GMT+02:00 Ian Campbell i...@debian.org:

Hi,

You are noted as the last translator of the debconf translation for
grub2.

Thank you to those of you who have already submitted translation updates.

It has been brought to my attention that the phrase EFI removable path
in the
previous English version is confusing and wrong and should really be EFI
removable media path. Therefore I am sending out an updated po file (see
attached) with this fixed.

I'm afraid this will have marked any existing translations as fuzzy.

Please send the updated file to me, or submit it as a wishlist bug against
grub2. If you have already translated this template and the above change
does
not invalidate your translation then please let me know and I will un-fuzz
it
for you.

At the same time some minor tweaks have been made to the English grammar. I
think these should not affect translations.

The complete wdiff for the English updates vs last time is:
8--
Template: grub2/force_efi_extra_removable
Type: boolean
Default: false
_Description: Force extra installation to the EFI removable {+media+} path?
Some EFI-based systems are buggy and do not handle new bootloaders
correctly.
If you force {+an+} extra installation of GRUB to the EFI removable
{+media+} path, [-it-]
{+this+} should
[-make sure-] {+ensure+} that this system will boot Debian correctly
despite such a
problem. However, [-this-] {+it+} may remove the ability to boot any
other operating
systems that also depend on this path. If so, you will need to [-ensure-]
{+make sure+} that
GRUB is configured successfully to be able {+to+} boot any other OS
installations
correctly.
8--

The deadline for receiving the updated translation is still
Sun, 21 Dec 2014 19:58:50 +.

Thanks in advance, and sorry for the inconvenience.

Ian.

# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
#
# Panagiotis Georgakopoulos pankge...@gmail.com 2014
# Emmanuel Galatoulas galax...@quad-nrg.net, 2010, 2012.
msgid
msgstr
Project-Id-Version: \n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-13 20:23+\n
PO-Revision-Date: 2012-08-17 14:44+0300\n
Last-Translator: pankgeorgpankge...@gmail.com\n
Language-Team: Greek debian-l10n-gr...@lists.debian.org\n
Language: el\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
X-Generator: Lokalize 1.4\n
Plural-Forms: nplurals=2; plural=(n != 1);\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Να γίνει αλυσιδωτή φόρτωση από το αρχείο menu.lst;

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr
Το πρόγραμμα αναβάθμισης του GRUB έχει εντοπίσει αρχεία ρύθμισης του GRUB
Legacy στον κατάλογο /boot/grub.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
In order to replace the Legacy version of GRUB in your system, it is
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image
from your existing GRUB Legacy setup. This step can be automatically
performed now.
msgstr
Για να αντικαταστήσετε την έκδοση Legacy του GRUB στο σύστημά σας,
συνιστάται η προσαρμογή του αρχείου /boot/grub/menu.lst ώστε να γίνεται η
φόρτωση μιας εκκινήσιμης εικόνας του GRUB 2 μέσα από την υπάρχουσα
διαμόρφωση του GRUB Legacy. Το βήμα αυτό μπορεί να πραγματοποιηθεί τώρα
αυτόματα.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
It's recommended that you accept chainloading GRUB 2 from menu.lst, and
verify that the new GRUB 2 setup works before it is written to the MBR
(Master Boot Record).
msgstr
Συνιστάται η αποδοχή της αλυσιδωτής φόρτωσης του GRUB 2 από το αρχείο menu.
lst και η επαλήθευση της λειτουργικότητας της νέας ρύθμισης του GRUB 2 πριν
αυτό εγγραφεί στο MBR (Master Boot Record).

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
Whatever your decision, you can replace the old MBR image with GRUB 2 later
by issuing the following command

Bug#772921: [I18N:fi] Updated Finish translation of debconf templates

2014-12-12 Thread Ian Campbell

Package: src:grub2
Severity: wishlist
Tags: patch
---BeginMessage---
11.12.2014, 21:59, Ian Campbell kirjoitti:
Please send the updated file to me, or submit it as a wishlist bug
against grub2.

Attached is the updated fi.po.

-Timo

# Esko ArajÃ¤rvi e...@iki.fi, 2009, 2010.
# Timo Jyrinki timo.jyri...@iki.fi, 2012, 2014.
msgid
msgstr
Project-Id-Version: grub2\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-07 16:09+\n
PO-Revision-Date: 2014-12-12 10:19+0200\n
Last-Translator: Timo Jyrinki timo.jyri...@iki.fi\n
Language-Team: Finnish debian-l10n-finn...@lists.debian.org\n
Language: fi\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
X-Poedit-Language: Finnish\n
X-Poedit-Country: FINLAND\n
X-Generator: Lokalize 1.0\n
Plural-Forms: nplurals=2; plural=(n != 1);\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr Ladataanko ketjutettuna tiedostosta menu.lst?

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid
Note: it is possible to install GRUB to partition boot records as well, and
some appropriate partitions are offered here. However, this forces GRUB to
use the blocklist mechanism, which makes it less reliable, and therefore is
not recommended.
msgstr
Huomaa: GRUB voidaan asentaa myÃ¶t osion kÃ¤ynnistystietoihin, ja joitain
sopivia osioita on ohessa tarjolla. TÃ¤mÃ¤ kuitenkin pakottaa GRUBin
kÃ¤yttÃ¤mÃ¤Ã¤n lohkoluettelomekanisia, mikÃ¤ tekee siitÃ¤ vÃ¤hemmÃ¤n luotettavan
eikÃ¤ ole suositeltavaa.

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:4001
msgid
The GRUB boot loader was previously installed to a disk that is no longer
present, or whose unique identifier has changed for some reason. It is
important to make sure that the installed GRUB core image stays in sync with
GRUB modules and grub.cfg. Please check again to make sure that GRUB

Bug#772922: [I18N:is] Updated Icelandic translation of debconf templates

2014-12-12 Thread Ian Campbell

Package: src:grub2
Severity: wishlist
Tags: patch
---BeginMessage---

Þann fim 11.des 2014 19:59, skrifaði Ian Campbell:

Hi,

You are noted as the last translator of the debconf translation for
grub2. The English template has been changed, and now some messages
are marked fuzzy in your translation or are missing.
I would be grateful if you could take the time and update it.
Please send the updated file to me, or submit it as a wishlist bug
against grub2.



Here's the updated po-file for Icelandic. Please commit for me.

Best regards,
Sveinn í Felli



Thanks in advance,
Ian.



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk



___
Translation-team-is p#243;stlistinn
translation-team...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/translation-team-is




# translation of grub_debian_po_is.po to Icelandic
# Copyright (C) 2010 Free Software Foundation
# This file is distributed under the same license as the GRUB package.
#
# Sveinn Ã Felli svei...@nett.is, 2010, 2011, 2012, 2014.
msgid 
msgstr 
Project-Id-Version: grub_debian_po_is\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-07 16:09+\n
PO-Revision-Date: 2014-12-11 23:20+\n
Last-Translator: Sveinn Ã Felli s...@fellsnet.is\n
Language-Team: Icelandic translation-team...@lists.sourceforge.net\n
Language: is\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
\n
X-Generator: Lokalize 1.5\n
Plural-Forms: nplurals=2; plural=n != 1;\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr RaÃ°hlaÃ°a (chainload) Ãºr menu.lst?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub.
msgstr 
UppfÃ¦rsluskriftur GRUB hafa fundiÃ° eldri uppsetningu GRUB Ã /boot/grub.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
In order to replace the Legacy version of GRUB in your system, it is 
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image 
from your existing GRUB Legacy setup. This step can be automatically 
performed now.
msgstr 
Til aÃ° skipta eldri uppsetningu GRUB Ãºt af kerfinu, Ã¾Ã¡ er mÃ¦lt meÃ° Ã¾vÃ aÃ° /
boot/grub/menu.lst sÃ© stillt til aÃ° raÃ°hlaÃ°a (chainload) GRUB 2 rÃ¦sidiskmynd 
frÃ¡ Ã¾essari eldri uppsetningu Ã¡ GRUB.  HÃ¦gt er aÃ° framkvÃ¦ma Ã¾etta skref 
sjÃ¡lfvirkt nÃºna.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
It's recommended that you accept chainloading GRUB 2 from menu.lst, and 
verify that the new GRUB 2 setup works before it is written to the MBR 
(Master Boot Record).
msgstr 
MÃ¦lt meÃ° Ã¾vÃ aÃ° Ã¾Ãº samÃ¾ykkir aÃ° raÃ°hlaÃ°a GRUB 2 Ãºr menu.lst, auk Ã¾ess aÃ° Ã¾Ãº 
skoÃ°ir hvort nÃ½ja GRUB 2 uppsetningin virki fyrir Ã¾ig, Ã¡Ã°ur en Ã¾etta er 
skrifaÃ° Ã¡ MBR rÃ¦sigeirann (Master Boot Record).

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid 
Whatever your decision, you can replace the old MBR image with GRUB 2 later 
by issuing the following command as root:
msgstr 
HvaÃ° svosem Ã¾Ãº Ã¡kveÃ°ur, Ã¾Ã¡ getur Ã¾Ãº sÃÃ°ar skipt gÃ¶mlu MBR myndinni Ãºt fyrir 
GRUB2 meÃ° Ã¾vÃ aÃ° gefa eftirfarandi skipun (sem kerfisstjÃ³ri/root):

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid GRUB install devices:
msgstr GRUB uppsetningartÃ¦ki:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid 
The grub-pc package is being upgraded. This menu allows you to select which 
devices you'd like grub-install to be automatically run for, if any.
msgstr 
VeriÃ° er aÃ° uppfÃ¦ra grub-pc pakkann. Ãessi valmynd gerir Ã¾Ã©r kleift aÃ° velja 
af hvaÃ°a tÃ¦kjum hÃ¦gt er aÃ° keyra grub-install sjÃ¡lfvirkt, ef Ã¾Ã¡ nokkrum.

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid 
Running grub-install automatically is recommended in most situations, to 
prevent the installed GRUB core image from getting out of sync with GRUB 
modules or grub.cfg.
msgstr 
MÃ¦lt er meÃ° Ã flestum tilfellum aÃ° keyra grub-install sjÃ¡lfvirkt, til Ã¾ess 
aÃ° koma Ã veg fyrir aÃ° uppsetta GRUB aÃ°almyndin hÃ¦tti aÃ° vera samstillt viÃ° 
GRUB-einingar eÃ°a grub.cfg stilliskrÃ¡na.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid 
If you're unsure which drive is designated as boot drive by your BIOS

Bug#772930: [I18N:pl] Updated Polish translation of debconf templates

2014-12-12 Thread Ian Campbell

Package: src:grub2
Severity: wishlist
Tags: patch, l10n
---BeginMessage---

W dniu 11.12.2014 o 20:59, Ian Campbell pisze:
 Please send the updated file to me, or submit it as a wishlist bug
 against grub2.

Hi,

I've translated both new messages. I hope they are correct.

Best regards,
Łukasz Dulny




pl.po.gz
Description: application/gzip
---End Message---

Bug#772983: kirkwood kernel image is too big

2014-12-12 Thread Ian Campbell

On Fri, 2014-12-12 at 18:12 +, Ben Hutchings wrote:
 Package: src:linux
 Version: 3.16.7-2
 Severity: serious
 
 The kirkwood and orion5x kernel images generally have to be installed
 in flash partitions with a fixed size.  Currently we check at build
 time that vmlinuz is small enough to fit.  However, these platforms
 now require Device Tree blobs, and the appropriate DTB must be
 appended to the kernel image in flash since the boot loader won't load
 it separately.
 
 The kirkwood machines with the smallest known kernel partition are
 QNAP TS-119/TS-219, with 2097080 bytes space.  We need to fit:
 
 -rw-r--r-- 1 ben ben 2094680 Nov  7 03:37 vmlinuz-3.16.0-4-kirkwood
 -rw-r--r-- 1 ben ben   10394 Dec  9 04:57 kirkwood-ts219-6281.dtb

We have not switched to dtb appending for the QNAP TS* platforms in
Jessie. The board support still existed in v3.16 and we still use it.

I had originally planned to switch QNAP over for 3.16 but it wasn't
quite ready upstream (I've forgotten why). The board files went away in
3.17 so in experimental (v3.18) appending is necessary. Once I've worked
out some kinks with kirkwood in v3.18 I was planning to upload a
corresponding flash-kernel which does appending for those platforms.

There are other kirkwood platforms with appending enabled in the flash
kernel db in Jessie. They are:

  * Buffalo Linkstation LS-CHLv2 (kirkwood-lschlv2.dtb)
  * Buffalo Linkstation LS-XHL (kirkwood-lsxhl.dtb)
  * D-Link DNS-320 NAS (Rev A1) (kirkwood-dns320.dtb)
  * LaCie Internet Space v2 (kirkwood-is2.dtb)
  * LaCie Network Space Max v2 (kirkwood-ns2max.dtb)
  * Globalscale Technologies Dreamplug (kirkwood-dreamplug.dtb)
  * Marvell GuruPlug Reference Board
(kirkwood-guruplug-server-plus.dtb)
  * (AKA Globalscale Technologies Guruplug Server Plus)
  * Marvell SheevaPlug Reference Board (kirkwood-sheevaplug.dtb)
  * (AKA Globalscale Technologies SheevaPlug)
  * Marvell eSATA SheevaPlug Reference Board
(kirkwood-sheevaplug-esata.dtb)
  * (AKA Globalscale Technologies eSATA SheevaPlug)
  * Plat'Home OpenBlocksA6 (kirkwood-openblocks_a6.dtb)
  * Seagate FreeAgent Dockstar (kirkwood-dockstar.dtb)

Of all those only D-Link DNS-320 NAS (Rev A1) has the Mtd-kernel
field, so all the others must boot from a filesystem not an raw MTD
partition.

Sadly the db doesn't record the mtd sizes for platforms, so I don't know
how much space that model has. kirkwood-dns320.dtb is 13199 bytes
though.

   2094680  2097080
 2094680 + 10394 = 2105074  2097080
 
 The orion5x machine with the smallest known kernel partition is D-Link
 DNS-323, with 1572792 bytes space.  We currently have less than 1 KB
 to spare here.  Thankfully this machine is still supported by board
 code and doesn't need a DTB.  But if any of the other orion5x machines
 we intend to support have a similarly small kernel partition and
 require a DTB they will not work with this version.

I don't know much about orion5x, but the flash-kernel db tells me that
we don't currently append a dtb on any platform there.

1k is rather tight though, even if appending isn't needed. A security
update adding 1k of binary size wouldn't be totally out of the question
and it would be unfortunate to have to start disabling features in a
security update.

 
 Ben.
 
 -- System Information:
 Debian Release: 8.0
   APT prefers unstable
   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
 'experimental')
 Architecture: i386 (x86_64)
 Foreign Architectures: amd64
 
 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
 Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 Init: systemd (via /run/systemd/system)
 
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772771: grub2: [INTL:fr] French debconf templates translation update

2014-12-11 Thread Ian Campbell

On Wed, 2014-12-10 at 23:22 +0100, Christian Perrier wrote:
 Package: grub2
 Version: N/A
 Severity: wishlist
 Tags: patch l10n
 
 Please find attached the french debconf templates update, proofread by the
 debian-l10n-french mailing list contributors.
 
 If you do not already use it, you might consider using the
 podebconf-report-po utility, which helps warning translators about
 changes when you modify some debconf templates in your packages.

Thanks, I wasn't aware of this tool and was wondering if I was supposed
to do something.

Looking at podebconf-report-po it seems I could still use it to send out
a request and link them all to this report with:
podebconf-report-po --bts=772771
I'm assuming you haven't already done so?

If not then I'll send out a call for translations and collect them in
this bug.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772799: po-debconf: podebconf-report-po --postpone should check for Mail::Box at the start not the end

2014-12-11 Thread Ian Campbell

Package: po-debconf
Version: 1.0.16+nmu3
Severity: wishlist

Using podebconf-report-po --postpone=foo took me through the entire process
before bailing at the end with:
The --postpone and --mutt options require the perl Mail::Box package. 
Please install the Debian libmail-box-perl package if you want to use these 
options.

It would have been more helpful to exit early when the option was given, before
walking me through the options and asking me to edit the text etc.

A couple of other minor usability points:

The prompt given at the end was Ready to send the emails, are you sure?
[y/N/e/?], which made me worry that --postpone wasn't working and it was going
to send the mails anyway. I suppose there isn't much point in prompting in
postpone mode, but if it is going to prompt it should be something like Read
to append the mails to $foo.

Secondly it would be nice to wrap that message to 80 characters.

Thanks,
Ian.


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armhf
armel

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages po-debconf depends on:
ii  gettext  0.19.3-1
ii  intltool-debian  0.35.0+20060710.1
ii  perl 5.20.1-2

Versions of packages po-debconf recommends:
ii  libio-compress-perl [libcompress-zlib-perl]  2.066-1
ii  libmail-sendmail-perl0.79.16-1
ii  perl [libcompress-zlib-perl] 5.20.1-2

Versions of packages po-debconf suggests:
ii  libmail-box-perl  2.117-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772800: po-debconf: podebconf-report-po --bts=NNNN doesn't produce Reply-To field

2014-12-11 Thread Ian Campbell

Package: po-debconf
Version: 1.0.16+nmu3
Severity: important

I ran:
podebconf-report-po --postpone=mbox --bts=772771
and it produced me an mbox where the text correctly referred to respecting the
reply-to and gave the bug number but the message headers themselves did not.
Here is the first mail in the mbox:

8-
From i...@debian.org Thu Dec 11 09:10:04 2014
From: Ian Campbell i...@debian.org
To: Omer Zak w...@zak.co.il,
 Hebrew debian-hebrew-com...@lists.alioth.debian.org
Subject: grub2 2.02~beta2-18: Please update debconf PO translation for the
 package grub2
X-Mail-Originator: podebconf-report-po 0.14
Content-Type: multipart/mixed; boundary==1418288999=
Content-Transfer-Encoding: 8bit
Message-Id: mailbox-18985-1418289004-71...@dagon.hellion.org.uk
Date: Thu, 11 Dec 2014 09:10:04 +
MIME-Version: 1.0
Status: RO
Content-Length: 23787
Lines: 326

--=1418288999=
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi,

You are noted as the last translator of the debconf translation for
grub2. The English template has been changed, and now some messages
are marked fuzzy in your translation or are missing.
I would be grateful if you could take the time and update it.
Please respect the Reply-To: field and send your updated translation to
772...@bugs.debian.org.

The deadline for receiving the updated translation is
Sun, 21 Dec 2014 09:09:57 +.

Thanks in advance,
8-

Ian.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armhf
armel

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages po-debconf depends on:
ii  gettext  0.19.3-1
ii  intltool-debian  0.35.0+20060710.1
ii  perl 5.20.1-2

Versions of packages po-debconf recommends:
ii  libio-compress-perl [libcompress-zlib-perl]  2.066-1
ii  libmail-sendmail-perl0.79.16-1
ii  perl [libcompress-zlib-perl] 5.20.1-2

Versions of packages po-debconf suggests:
ii  libmail-box-perl  2.117-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772809: [Pkg-xen-devel] Bug#772809: Update debian xendomains init and default to latest xen upstream

2014-12-11 Thread Ian Campbell

Control: retitle -1 xendomains: support admin configurable delay between 
starting guests

On Thu, 2014-12-11 at 11:52 +0100, Fabio Fantoni wrote:
 The more useful parameters when mainly windows domUs are used is
 XENDOMAINS_CREATE_USLEEP that I setted to 30 or 40 seconds on my systems
 to decrease the overload caused by windows startup (even if pv drivers
 are installed).

I've retitled to reflect the actual request being made here.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772771: grub2: [INTL:fr] French debconf templates translation update

2014-12-11 Thread Ian Campbell

On Thu, 2014-12-11 at 19:03 +0100, Christian PERRIER wrote:
 Quoting Ian Campbell (i...@debian.org):
 
  Looking at podebconf-report-po it seems I could still use it to send out
  a request and link them all to this report with:
  podebconf-report-po --bts=772771
  I'm assuming you haven't already done so?
 
 No, I haven't. This is not the common practice (to point translators
 to the same bug report) but I think it is OK if you prefer not having
 too many translations flowing in.

Thanks, I've done it without --bts since it is broken anyway (#772800).

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772916: [I18N:kk] Updated Kazakh translation of debconf templates

2014-12-11 Thread Ian Campbell

Package: src:grub2
Severity: wishlist
Tags: patch
---BeginMessage---
Hi,

Please find attached

Thanks

On Fri, Dec 12, 2014 at 1:59 AM, Ian Campbell i...@debian.org wrote:
Hi,

The deadline for receiving the updated translation is
Sun, 21 Dec 2014 19:58:50 +.

Thanks in advance,
Ian.

# Kazakh translation for grub2.
# Copyright (C) 2010 The Grub team
# This file is distributed under the same license as the PACKAGE package.
# Baurzhan Muftakhidinov baurthefi...@gmail.com, 2010-2011.
#
msgid
msgstr
Project-Id-Version: master\n
Report-Msgid-Bugs-To: gr...@packages.debian.org\n
POT-Creation-Date: 2014-12-07 16:09+\n
PO-Revision-Date: 2014-12-12 08:58+0600\n
Last-Translator: Baurzhan Muftakhidinov baurthefi...@gmail.com\n
Language-Team: Kazakh kk...@googlegroups.com\n
Language: kk\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=1; plural=0;\n
X-Generator: Poedit 1.6.9\n

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid Chainload from menu.lst?
msgstr menu.lst ішінен тізбектей жүктелу керек пе?

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
In order to replace the Legacy version of GRUB in your system, it is
recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image
from your existing GRUB Legacy setup. This step can be automatically
performed now.
msgstr
GRUB Legacy нұсқасын алмастыру үшін, сіздің бар болып тұрған GRUB Legacy
орнатудың /boot/grub/menu.lst файлынан GRUB 2 жүктеушісін тізбектей жүктеуге
баптауға ұсынылады. Бұл қадам қазір автоматты түрде жасалуы мүмкін.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
It's recommended that you accept chainloading GRUB 2 from menu.lst, and
verify that the new GRUB 2 setup works before it is written to the MBR
(Master Boot Record).
msgstr
GRUB 2-ні menu.lst ішінен тізбектей жүктеуді қабылдау, және жаңа GRUB 2
орнатуы оны MBR (Басты жүктелу жазбасына) ішіне жазбас бұрын жұмыс
істейтінін тексеру ұсынылады.

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid
Whatever your decision, you can replace the old MBR image with GRUB 2 later
by issuing the following command as root:
msgstr
Шешіміңіз қандай болса да, кейін сіз әрқашан да ескі MBR бейнесін жаңа GRUB
2-мен ауыстыра аласыз, ол үшін root атынан келесі команда орындауыңыз керек:

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid
The grub-pc package is being upgraded. This menu allows you to select which
devices you'd like grub-install to be automatically run for, if any.
msgstr
grub-pc дестесі жаңартылуда. Бұл мәзір сізге қай құрылғылар үшін grub-
install автожөнелту қалайтыныңызды көрсетуге мүмкін қылады, егер ондай
құрылғылар бар болса.

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid
Running grub-install automatically is recommended in most situations, to
prevent the installed GRUB core image from getting out of sync with GRUB
modules or grub.cfg.
msgstr
grub-install автожөнелту көп жағдайда ұсынылады, орнатылған GRUB өзегі және
модульдер не grub.cfg-мен үйлесімді болуы үшін.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid
If you're unsure which drive is designated as boot drive by your BIOS, it is
often a good idea to install GRUB to all of them.
msgstr
Егер сіз BIOS-та қай диск жүктелетін етіп орнатылғанын нақты білмесеңіз,
GRUB-ты дисктердің барлығына орнатуға да болады.

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid
Note: it is possible to install GRUB to partition boot records as well, and
some appropriate partitions are offered here. However, this forces GRUB to
use the blocklist mechanism, which makes it less reliable, and therefore is
not recommended.
msgstr
Ескерту: GRUB-ты бөлімнің жүктелу жазбасына да орнатуға болады, сәйкес
келетін бөлімдер тізімі төменде көрсетілген. Алайда, бұл әрекет GRUB-ты
блоктізімді қолдануға мәжбүрлетеді, яғни оның икемділігін төмендетеді, сол
үшін ұсынылмайды.

#. Type

Bug#772636: rxvt-unicode: memory leak in urxvtd

2014-12-09 Thread Ian Campbell

Package: rxvt-unicode
Version: 9.20-1+b1
Severity: important

Dear Maintainer,

I use urxvtd via urxvtd -q -o -f and there appears to be a memory
leak of some sort. The process (the child of the two processes which
result from the above) grows without bound until the OOM killer is
invoked and it is killed.

I restarted urxvtd yesterday morning because of this issue and today
it has grown to VIRT=365660K=366M and RES=275676K=269M, compared with
VIRT=99200K=96M and RES=16000K=15M just after I started it.

A urxvtd on another machine which was started on 22 November is
currently VIRT=875M and RES=235M.

I tried running under Valgrind, but urxvtd is sgid so Valgrind is
unable to run (if you know of a workaround for this I'll gladly try
again).

I've attached urxvtd-memory-A.txt and urxvtd-memory-B.txt which
are the output of sudo pmap -x 10599 10600 yesterday (when the
process was fresh) and today. The most striking difference is a bunch
of anon memory mappings in the child process. In particular:
+0222d000  242616  242616  242616 rw---   [ anon ]

The other machine (start 22 Nov) has a similarly large mapping:

01dee000  769092  218800  217920 rw---   [ anon ]

If you've any ideas for other techniques I could try in order to track
down what's going on I can try them.

Thanks,
Ian.


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages rxvt-unicode depends on:
ii  base-passwd   3.5.36
ii  libc6 2.19-11
ii  libfontconfig12.11.0-6.1
ii  libfreetype6  2.5.2-2
ii  libgcc1   1:4.9.1-16
ii  libgdk-pixbuf2.0-02.31.1-2+b1
ii  libglib2.0-0  2.42.0-2
ii  libperl5.20   5.20.1-1
ii  libstartup-notification0  0.12-4
ii  libx11-6  2:1.6.2-3
ii  libxft2   2.3.2-1
ii  libxrender1   1:0.9.8-1
ii  ncurses-base  5.9+20140913-1

Versions of packages rxvt-unicode recommends:
ii  fonts-vlgothic [fonts-japanese-gothic]  20140801-1
ii  ttf-dejavu  2.34-1

rxvt-unicode suggests no packages.

-- no debconf information
10599:   urxvtd -q -o -f
Address   Kbytes RSS   Dirty Mode  Mapping
00401240 256   0 r-x-- urxvtd
00735000   8   8   4 r urxvtd
00737000  44  40   8 rw--- urxvtd
00742000  76   4   4 rw---   [ anon ]
021eb000 132  68  68 rw---   [ anon ]
7fb1106b1000  44  44   0 r-x-- libnss_files-2.19.so
7fb1106bc0002044   0   0 - libnss_files-2.19.so
7fb1108bb000   4   4   4 r libnss_files-2.19.so
7fb1108bc000   4   4   4 rw--- libnss_files-2.19.so
7fb1108bd000  40  40   0 r-x-- libnss_nis-2.19.so
7fb1108c70002044   0   0 - libnss_nis-2.19.so
7fb110ac6000   4   4   4 r libnss_nis-2.19.so
7fb110ac7000   4   4   4 rw--- libnss_nis-2.19.so
7fb110ac8000  84  84   0 r-x-- libnsl-2.19.so
7fb110add0002044   0   0 - libnsl-2.19.so
7fb110cdc000   4   4   4 r libnsl-2.19.so
7fb110cdd000   4   4   4 rw--- libnsl-2.19.so
7fb110cde000   8   4   4 rw---   [ anon ]
7fb110ce  28  28   0 r-x-- libnss_compat-2.19.so
7fb110ce70002044   0   0 - libnss_compat-2.19.so
7fb110ee6000   4   4   4 r libnss_compat-2.19.so
7fb110ee7000   4   4   4 rw--- libnss_compat-2.19.so
7fb110ee8000  80  64   0 r-x-- libresolv-2.19.so
7fb110efc0002044   0   0 - libresolv-2.19.so
7fb1110fb000   4   4   4 r libresolv-2.19.so
7fb1110fc000   4   4   4 rw--- libresolv-2.19.so
7fb1110fd000   8   0   0 rw---   [ anon ]
7fb1110ff000 132  68   0 r-x-- libselinux.so.1
7fb22048   0   0 - libselinux.so.1
7fb11132   4   4   4 r libselinux.so.1
7fb111321000   4   4   4 rw--- libselinux.so.1
7fb111322000   8   0   0 rw---   [ anon ]
7fb111324000  20  20   0 r-x-- libXdmcp.so.6.0.0
7fb1113290002044   0   0 - libXdmcp.so.6.0.0
7fb111528000   4   4   4 rw--- libXdmcp.so.6.0.0
7fb111529000  12  12   0 r-x-- libXau.so.6.0.0
7fb11152c0002044   0   0 - libXau.so.6.0.0
7fb11172b000   4   4   4 r libXau.so.6.0.0
7fb11172c000   4   4   4 rw---

Bug#772636: rxvt-unicode: memory leak in urxvtd

2014-12-09 Thread Ian Campbell

On Tue, 2014-12-09 at 12:02 +, Ian Campbell wrote:
 I tried running under Valgrind, but urxvtd is sgid so Valgrind is
 unable to run (if you know of a workaround for this I'll gladly try
 again).

Shortly after hitting Send I had a small epiphany. I
copied /usr/bin/urxvt (nb not urxvtd) somewhere else, which dropped the
sgid and ran with -ut (which stops it trying to write to utmp, which I
suppose was the reason for the sgid).

The result of:
valgrind --leak-check=full --log-file=tmp/urxvt.valgrind tmp/urxvt -ut
and then immediately pressing Ctrl-D in the resulting window is
attached.

It shows quite a few definitely lost bytes in both libperl and
libfontconfig. I expect those would be accounted to the urxvtd process
if I were using it here and would accumulate with time.

I hope this is helpful. Next time I lose my urxvtd process I'll rerun it
under valgrind using a similar technique in the hopes that something
useful might show up.

Ian.
==30391== Memcheck, a memory error detector
==30391== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==30391== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==30391== Command: tmp/urxvt -ut
==30391== Parent PID: 29104
==30391== 
==30391== 
==30391== HEAP SUMMARY:
==30391== in use at exit: 255,466 bytes in 7,491 blocks
==30391==   total heap usage: 71,185 allocs, 63,694 frees, 14,205,218 bytes 
allocated
==30391== 
==30391== 7 bytes in 1 blocks are definitely lost in loss record 8 of 441
==30391==at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==30391==by 0x67B4DF1: Perl_safesysmalloc (in 
/usr/lib/x86_64-linux-gnu/libperl.so.5.20.1)
==30391==by 0x6847A05: Perl_bytes_from_utf8 (in 
/usr/lib/x86_64-linux-gnu/libperl.so.5.20.1)
==30391==by 0x678DE6C: Perl_pad_add_name_pvn (in 
/usr/lib/x86_64-linux-gnu/libperl.so.5.20.1)
==30391==by 0x6743D82: Perl_allocmy (in 
/usr/lib/x86_64-linux-gnu/libperl.so.5.20.1)
==30391==by 0x67756E5: Perl_yylex (in 
/usr/lib/x86_64-linux-gnu/libperl.so.5.20.1)
==30391==by 0x6789BC7: Perl_yyparse (in 
/usr/lib/x86_64-linux-gnu/libperl.so.5.20.1)
==30391==by 0x680C541: ??? (in /usr/lib/x86_64-linux-gnu/libperl.so.5.20.1)
==30391==by 0x6819343: Perl_pp_entereval (in 
/usr/lib/x86_64-linux-gnu/libperl.so.5.20.1)
==30391==by 0x67D2E45: Perl_runops_standard (in 
/usr/lib/x86_64-linux-gnu/libperl.so.5.20.1)
==30391==by 0x675C3E4: Perl_call_sv (in 
/usr/lib/x86_64-linux-gnu/libperl.so.5.20.1)
==30391==by 0x45682C: perl_watcher::invoke(char const*, sv*, int) (in 
/local/scratch/ianc/tmp/urxvt)
==30391== 
==30391== 8 bytes in 1 blocks are possibly lost in loss record 12 of 441
==30391==at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==30391==by 0x4C2AFCF: realloc (vg_replace_malloc.c:692)
==30391==by 0x624488D: g_realloc (in 
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0)
==30391==by 0x5FCE2A5: type_node_any_new_W (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==30391==by 0x5FD326C: g_type_register_static (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==30391==by 0x5FD7B01: g_type_plugin_get_type (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==30391==by 0x5FAD624: gobject_init_ctor (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==30391==by 0x400E9F9: call_init.part.0 (dl-init.c:78)
==30391==by 0x400EAE2: call_init (dl-init.c:36)
==30391==by 0x400EAE2: _dl_init (dl-init.c:126)
==30391==by 0x40011C9: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==30391==by 0x1: ???
==30391==by 0xFFF000292: ???
==30391== 
==30391== 8 bytes in 1 blocks are possibly lost in loss record 13 of 441
==30391==at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==30391==by 0x4C2AFCF: realloc (vg_replace_malloc.c:692)
==30391==by 0x624488D: g_realloc (in 
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0)
==30391==by 0x5FCE2A5: type_node_any_new_W (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==30391==by 0x5FD326C: g_type_register_static (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==30391==by 0x5FAF731: g_boxed_type_register_static (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==30391==by 0x5FAF8ED: g_value_array_get_type (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==30391==by 0x5FC05E4: _g_param_spec_types_init (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==30391==by 0x5FAD64A: gobject_init_ctor (in 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.0)
==30391==by 0x400E9F9: call_init.part.0 (dl-init.c:78)
==30391==by 0x400EAE2: call_init (dl-init.c:36)
==30391==by 0x400EAE2: _dl_init (dl-init.c:126)
==30391==by 0x40011C9: ??? (in /lib/x86_64-linux-gnu/ld-2.19.so)
==30391== 
==30391== 8 bytes in 1 blocks are possibly lost in loss record 14 of 441
==30391==at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==30391==by 0x4C2AFCF: realloc (vg_replace_malloc.c:692)
==30391

Bug#767037: Grub EFI fallback - patches for review

2014-12-08 Thread Ian Campbell

On Mon, 2014-12-08 at 01:36 +, Steve McIntyre wrote:
 The current package in sid (-17) is unblocked and I think ought to
 transition tomorrow (or perhaps Tuesday depending on TZ). I propose to
 upload -18 with this change shortly after that happens. Will you take
 care of the unblock request or at least provide me some text with the
 rationale etc.
 
 I'll ask for the unblock, and I'll also upload grub-installer the same
 day.

Upload == done.

 -17 included some patches from Colin to make the 32-bit linuxefi command
 work.
 
 Yup, saw that. I'm looking into 32-bit EFI stuff right now. Using a
 Mac atm *shudder*

Urk!

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771249: Hacking pkg-grub/grub.git to allow po/* updates (Re: Bug#771249: Translation update)

2014-12-07 Thread Ian Campbell

Colin, since the below has a significant impact on the packaging git
workflow I won't take it any further without your input...

On Thu, 2014-11-27 at 19:06 -0400, David Prévot wrote:
 Please consider updating translations of grub2, as already provided by
 translators since upstream released 2.02~beta2.

Sadly applying this patch is not as easy as it might seem, due to
Tedious Packaging VCS Reasons(tm) :-/

The pkg-grub git tree[0] uses git-dpm on-top of the upstream grub.git
tree, which does not include po/*.po, but those files are included in
the upstream tarball release (i.e. in our orig.tar.xz).

This unfortunately means that it is not possible to update po/* simply
using the normal git-dpm mechanisms.

I've attempted to workaround this as follows:

Create a new upstream-po branch, based on origin/upstream but with the
upstream released po files included (autogenerated stuff is direct from
linguas.sh):

$ git checkout -b upstream-po origin/upstream
$ cp ../grub2-2.02~beta2/po/*.po po/
$ cp ../grub2-2.02~beta2/po/LINGUAS po
$ (
autogenerated=en@quot en@hebrew de@hebrew en@cyrillic en@greek 
en@arabic en@piglatin de_CH
for x in $autogenerated; do
git rm po/$x.po
done
)
# Remove po/*.po and po/LINGUAS from .gitignore
$ git commit -a

Now rebase master onto this:

$ git checkout -b master-po origin/master
$ git-dpm record-new-upstream ../grub2_2.02~beta2.orig.tar.xz 
upstream-po
$ git-dpm rebase-patched
$ git-dpm dch Update git-dpm baseline to include upstream po files.

This results in a source package which differs only in the git-dpm noise
in debian/patches (hash changes) plus the changelog and debian/.git-dpm
as expected.

From here we can using the usual git-dpm checkout-patched/update-patches
routine to add an update-linguas.patch, which contains the result of
running linguas.sh.

I've pushed the results to /people/ijc/{upstream,master}-po in the
packaging git tree.

These branches do not include the followup patch from this bug to force
*.gmo to actually be updated, and I've not actually built binaries based
on it yet.

If we go ahead with this approach I'd suggest that upstream and
upstream-po ought to remain distinct in the packaging git tree, with the
former tracking pristine upstream and the latter adding the po files,
but to have a single master which is based on upstream-po (i.e. what is
currently called people/ijc/master-po).

It's possible this could also be solved with a second subcomponent
orig.tar containing an updated po subdirectory, or by debian/rules
machinery to update po/* from e.g. debian/upstream-po/* or something.
I've not tried either of those approaches, not sure if they are actually
realistic. I'll investigate them if you think it would be better.

Cheers,
Ian.

[0] http://anonscm.debian.org/cgit/pkg-grub/grub.git/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771905: unblock: grub2/2.02~beta2-17

2014-12-07 Thread Ian Campbell

On Sat, 2014-12-06 at 18:55 +0100, Ivo De Decker wrote:
 Control: tags -1 d-i
 
 Hi,
 
 On Wed, Dec 03, 2014 at 12:14:19PM +, Colin Watson wrote:
  On Wed, Dec 03, 2014 at 11:39:14AM +, Ian Campbell wrote:
   Please unblock package grub2
  
  Seconded.
 
 This needs the d-i ack.

Right, thanks, I knew to CC Kibi but not to add the tag.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767037: Grub EFI fallback - patches for review

2014-12-07 Thread Ian Campbell

Control: tag -1 +pending

On Wed, 2014-12-03 at 15:27 +, Steve McIntyre wrote:
 On Wed, Dec 03, 2014 at 09:42:20AM +, Ian Campbell wrote:
 On Wed, 2014-12-03 at 01:55 +, Steve McIntyre wrote:
  On Tue, Dec 02, 2014 at 08:36:31AM +, Ian Campbell wrote:
  On Mon, 2014-12-01 at 13:57 +, Steve McIntyre wrote:
  
  Starting with grub-install-fallback.patch:
  
   From e384e597914b6e1b1dcbf96ef6782cf9bcc2313b Mon Sep 17 00:00:00 2001
debian/patches/grub-install-extra-removable.patch | 115 
   ++
  
  Could you send this to grub-de...@gnu.org? Or at least provide a commit
  log for the upstream bit inline in the patch for whoever does end up
  forwarding it.
  
  Sure, no problem. I've added a header for now. As my stuff is
  intermingled with other changes in the Debian tree, I'm not sure how
  well that will work upstream...
 
 Ah yes, if it is dependent on other non-upstream stuff then probably no
 point sending off in isolation.
 
 ACK. It's not *functionally* dependent, but it's intermingled in the
 patches.
 
  Rebased patch V2 against current git master attached...
 
 Looks good to me.
 
 Cool. I don't (think I) have push access to the git repo, so if you
 could do the honours and apply, that would be lovely. :-)

Done, patches are now in pkg-grub/grub.git#master.

The current package in sid (-17) is unblocked and I think ought to
transition tomorrow (or perhaps Tuesday depending on TZ). I propose to
upload -18 with this change shortly after that happens. Will you take
care of the unblock request or at least provide me some text with the
rationale etc.

There are a boatload of updates to debian/po/*. How is that handled? I
committed the automated thing but am I supposed to prod some process
somewhere else too?

Anyway, I suppose there will need to be a second upload at some point
with the results of those translations. Perhaps that will be a good time
to fix #771249 too.

 I'm also wanting to get this into Jessie if we can, along with the
 32-bit EFI work that's next...!

-17 included some patches from Colin to make the 32-bit linuxefi command
work.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

< 1 2 3 4 5 6 7 8 9 10 >

501 - 600 of 1693 matches

Mail list logo