Bug#773991: flash-kernel: Fails when mtdblock kernel module isn't loaded
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})
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
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})
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
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
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
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
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
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
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
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})
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
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
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
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
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 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. 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
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)
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
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
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
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
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
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 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 Järjestelmässä olevan vanhan GRUB-version korvaamiseksi on suositeltavaa muokata tiedostoa /boot/grub/menu.lst siten, että GRUB 2 ladataan olemassa olevista vanhoista GRUB-asetuksista. Tämä voidaan tehdä automaattisesti nyt. #. 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
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
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
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
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
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
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
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
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
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
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
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
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]
---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
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
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
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
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
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
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
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 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 Da zamenjate različico GRUB Legacy na vašem sistemu vam priporočamo, da se /boot/grub/menu.lst spremeni tako, da verižno naloži GRUB 2 iz vaše obstoječe namestitve GRUB Legacy. To dejanje lahko zdaj izvedete samodejno. #. 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: 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 Kakorkoli se odločite, stari MBR lahko kasneje vedno zamenjate z GRUB 2, če izvedete kot root sledeči ukaz: #. 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
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
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 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 Legacy 設定能載入 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 安裝到 MBR(主要開機記錄)之前,建議您能同意在 menu.lst 裡先 以 chainload 的方式啟動 GRUB 2,以確認新的 GRUB 2 設定能正常運作。 #. 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 不管您的決定為何,您可以隨時讓 GRUB 2 取代舊有的 MBR 影像檔利用 root 身份執行 以下指令: #. 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 套件正在升級。這個選單讓您選擇 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 如果您不
Bug#772924: [l10n] Updated Czech translation of grub2 debconf messages
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
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
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
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)
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)
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
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
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
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
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
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]
---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
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
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
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
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
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]
---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, 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. # 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
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]
---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
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
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)
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]
---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. 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. # 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 #. 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 дестесі жаңартылуда. Бұл мәзір сізге қай құрылғылар үшін grub- install автожөнелту қалайтыныңызды көрсетуге мүмкін қылады, егер ондай
Bug#772983: kirkwood kernel image is too big
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]
---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
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]
---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. 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. 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 #. 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 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
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
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
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)
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
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
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
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
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, 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. # 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 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:4001 msgid GRUB install devices: msgstr Ä®renginiai âGRUBâ diegimui: #. 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. #. 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
Bug#772771: grub2: [INTL:fr] French debconf templates translation update
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]
---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. 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_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
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
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: 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 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 Järjestelmässä olevan vanhan GRUB-version korvaamiseksi on suositeltavaa muokata tiedostoa /boot/grub/menu.lst siten, että GRUB 2 ladataan olemassa olevista vanhoista GRUB-asetuksista. Tämä voidaan tehdä automaattisesti nyt. #. 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 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
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
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
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
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
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
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
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
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
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, 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. # 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 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 #. 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 дестесі жаңартылуда. Бұл мәзір сізге қай құрылғылар үшін 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
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
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
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)
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
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
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