Re: Removing lvm and crypto from rootfs
Are you sure flash-kernel got called by update-initramfs (it should on wheezy). How did you configure u-boot? Maybe you're passing a root parameter via u-boot. Yeah, I checked all that. After trying *really* hard to figure out how the initramfs hooks for lvm2 and cryptsetup work I ended up chrooting into the rootfs and doing apt-get purge cryptsetup lvm2 dropbear. That removed all the hooks in /usr/share/initramfs-tools. After that I did update-initramfs -u again and all was ok.
Re: recommend a netbook for Debian deployment?
On Wed, Nov 6, 2013 at 10:55 PM, Luc Verhaegen l...@skynet.be wrote: On Wed, Nov 06, 2013 at 10:32:01PM +, Luke Kenneth Casson Leighton wrote: On Wed, Nov 6, 2013 at 7:08 PM, Mikhail Ramendik m...@ramendik.ru wrote: yeees, that CPU Card runs debian. first thing i installed when i got it :) Cool. But I guess the A10 GPU (Mali400) is pretty basic compared to the aforementioned PowerVR? we're using the A20 which is dual-core, but yes it is. part of the issue there is that the moron in charge of MALI at ARM - the one who thinks he's god - doesn't actually know what he's talking about, and hasn't bothered to do any software optimisation of the parts of the MALI libraries that run on the actual ARM cores. luc verbeghen did a _really_ simple memory-management system in limadriver and got a *whopping* 30% performance increase *above* what MALI can do on the exact same hardware. and that's *without* having done any other special kinds of optimisations. I am not sure who luc verbeghen is, or where he found this 30% increase. ha ha :) thanks for correcting my ever-fault memory mr verhaegen :) l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDxiPgUujOwvo4Ct7Lw92E=nvdit9gr0bxjhueyj6n+...@mail.gmail.com
Re: Debian 7.0 on Dreamplug basic installation and booting system external sd card
Hey Sorry for being late to the party, thanks for waiting for me! :-) On Sat, Nov 02, 2013, Martin Michlmayr wrote: On most platforms flash-kernel generally prefers to mount the device dynamically, for those sorts of reasons. At least that's how I remember one of the f-k folks explaining it to me. No, that's not very common at all (although I see there are two other devices now that do this). The most common way is either to write directly to flash (for machines that boot from flash), or to put the files under /boot, under the assumption that /boot is where the device boots from (and d-i has checks to make sure this is the case, although d-i cannot check for everything). So let's tackle cases one by one. First something to keep in mind is that for many platforms there is a factory installed U-Boot and a Debian one is available; at the moment, the assumption of which U-Boots are supported are not clearly documented, except on the (nice) web pages from Martin or other Google juice. Concerning devices with flash storage (assuming there is an initrd and perhaps even DTB flash partition and that the Debian kernel and initrd will git in the stock partitions...), it's best to just write the files there, no need to write an interim file to /boot that is going to be ignored anyway. So flash-kernel should just generate the kernel (potentially with machine-id prepended, dtb appended, u-boot wrapping etc.) and initrd in /tmp, write them to flash, and remove the tmp files. Concerning devices where U-Boot grabs boot files from a filesystem, there are many variations in different platforms. Usually, the factory default is to read files from a hardcoded U-Boot device name and filesystem type, e.g. fatload mmc 0 uImage. In some slightly more clever U-Boot configs, there is some kind of scanning (either for a boot script or for a kernel image) in the form of iterate over all MMCs, then iterate over all partitions, then iterate over all filesystems and try to load file xyz. There are three issues with these setups; first, this is all very fragile, with a lot of variation and doesn't allow fancy things like reading kernel/initrd from RAID, LVM, LUKS etc. or filesystems not supported by U-Boot. Second, some U-Boot hardcode the filesystem type or only support dumb filesystems such as FAT or ext2. This is problematic because keeping ext2 mounted might result in unrecoverable corruption if the device crashes with unsynced changes (since U-Boot doesn't know how to deal with a filesystem that needs fsck-ing) and because sometimes we have symlinks in /boot. Third, the boot location is often space constrained and don't allow piling up old kernels. e.g. a 40MB MMC partition but you've piled up 5 kernels. With this in mind, I initially opted to list actual boot devices in the flash-kernel database (Boot-Device: /dev/sda1) using the expected factory-supported / Debian-supported/recommended U-Boot boot device. This would be mounted temporarily, only relevant files would be updated there, and then it would be unmounted. This avoided the filesystem corruption issue, avoided the symlink issue and avoided the limited space issue nicely. The long-term plan was to allow overriding the Boot-Device: by the end-user (and Ian's patches allow this, albeit I'm afraid they bind us to keep the database format backwards-compatible forever) and to also offer a mode where this would be computed based on /boot. If people think it's too late to change the behaviour now, I think it would be good to at least add a simple message like Creating boot files on /dev/sdaX to make it cleaer what's going on. Improved log was a good idea; I've just added one now (1e53a60); maybe we can work on improved use cases; perhaps we want some /etc/flash-kernel/boot-device override file that could be an UUID=, a LABEL= or a /dev pathname (much like fstab) that would be created by users or by flash-kernel-installer? Which devices would this be particularly useful on right now and what formats do we want to support first and foremost? How do we detect the device U-Boot will look after? Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131107164352.ga12...@bee.dooz.org
Re: Bug#728975: linux: [ARM] CONFIG_OABI_COMPAT harmful (slower, unsafe, breaks at least seccomp and audit)
(ccing debian-arm) On Thu, 2013-11-07 at 16:42 +, Ben Hutchings wrote: On Thu, Nov 07, 2013 at 10:46:37AM -0200, Henrique de Moraes Holschuh wrote: Package: linux Severity: normal Tags: security Please refer to: https://lkml.org/lkml/2013/11/5/448 https://lkml.org/lkml/2013/11/6/633 The issue is not yet closed in LKML, but basically OABI_COMPAT enabled seems to be a danger: at least seccomp and audit should not be used with OABI, and to top it off it is not free as far as performance goes, either: a fair amount of added complexity, and an extra D-cache miss on every syscall. AUDITSYSCALL cannot be enabled if OABI_COMPAT is enabled. I wasn't aware of the problem with seccomp mode 2 but I agree it's serious. I doubt there's any significant demand for OABI_COMPAT and I already disabled it for some of the size-constrained armel flavours. I'll wait for input from the ARM porters, but I think it would be reasonable to disable it for the rest. I agree (mostly replying just for the CC to the ARM porters). Ian -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1383843245.3189.18.ca...@kazak.uk.xensource.com
Re: Qt5 switching qreal from float to double on arm*
On Thursday 07 November 2013 18:18:18 you wrote: On Sat, Nov 02, 2013, Lisandro Damián Nicanor Pérez Meyer wrote: Hi! Starting from Qt 5.2.0 (most probably from rc1 and definitely not from beta1 currently in experimental) Qt5 will switch qreal from float to double on arm*. We have the option to keep some archs in float by passing a compilation parameter. I've done so for armel and sh4, so only armhf will switch to double. Of course we are still on time to discuss this, and this is the reason of this mail. What do you think WRT the above changes? First, thanks a lot for the heads up on this. Thank you too for replying :) qreal being float instead of double on ARM was the source of a bunch of work for ARM porters in the past; now I have these worries/questions: * switching it back might imply some new porting work (in the case where the patches were something #if ARM use float #else use double); this might be particularly painful if armel and armhf have different definitions. Maybe there's a nice define #QREAL_IS_FLOAT or something to help with this. Don't forget we are talking about *just* Qt5 here, *not* Qt4. We only have 3 apps building against Qt5 right now. If apps switch to Qt5 they will surely find some bumps, so this can be managed. * what about arm64? sounds like this one should be double from the start; not sure what it is right now I have not added any provisions to arm64, so with the next 5.2.0 [rc/final] upload it will switch to double. We are still on time if something needs a fix here. * when you say you've changed armel and sh4 to keep using float, is this Debian-specific? Not sure we want a delta with upstream on this kind of stuff. Would it not work at all to use double, or would it just be slow? I'd rather have it slow for people using big software on slow arches rather than keeping a delta; it sounds like we do a SONAME transition no matter what anyway Now this *will* be messy. I have asked upstream [0] and so far haven't got any explicit reply from other distro's maintainers. [0] http://lists.qt-project.org/pipermail/development/2013-November/014017.html But, according to [1]: I should also point out that this option now allows selecting qreal to be float on other platforms, besides ARM. That's why I'm still spamming debian-ports ;) [1] http://lists.qt-project.org/pipermail/development/2013-November/014017.html So: - We don't know yet what other distros are going to do. - If we decide to do the change in Qt5, it will be *without* soname bump. Yes, I know many of you will think of this as **ugly**, but so far means 3 binNMUs per arch. Now if this is not acceptable, then no change will be made, because I won't change Qt5's SONAME. * what's the point in qreal anyway? can't we just switch everything to float or double? sounds like software should know what kind of level of precision it needs in the first place; e.g. if it's a scale in some UI, then either float or double is enough, but it's not an arch specific decision I really don't know, it was already there when I started using Qt back in Qt3's final days ;-) But I *do* know that if people want it gone, they will need to wait until Qt6 and provide the necessary patches :-/ Hope that helps, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Qt5 switching qreal from float to double on arm*
On Thursday 07 November 2013 18:55:31 Loïc Minier wrote: On Thu, Nov 07, 2013, Lisandro Damián Nicanor Pérez Meyer wrote: - We don't know yet what other distros are going to do. IMO we shouldn't have distro-specific patching for this kind of stuff; it seems to commonly impact apps (which should be using qreal instead of assuming qreal is double) way too commonly, and we want binaries to be compatible between distros, so diverging from upstream seems a really bad idea. The problem is the can of worms it has been opened: now we have the *chance* to choose, so ideally we need maintainers from most distros cooperating to keep SONAME and ABI the same. Let's hope maintainers from other distros stand up. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Qt5 switching qreal from float to double on arm*
On Thu, Nov 07, 2013, Lisandro Damián Nicanor Pérez Meyer wrote: - We don't know yet what other distros are going to do. IMO we shouldn't have distro-specific patching for this kind of stuff; it seems to commonly impact apps (which should be using qreal instead of assuming qreal is double) way too commonly, and we want binaries to be compatible between distros, so diverging from upstream seems a really bad idea. - If we decide to do the change in Qt5, it will be *without* soname bump. Yes, I know many of you will think of this as **ugly**, but so far means 3 binNMUs per arch. Now if this is not acceptable, then no change will be made, because I won't change Qt5's SONAME. Well, it's kind of ugly but we could take this hit once and go through a binary transition with a package name change, or some kind of other transition trick. Not pretty and breaks compat between binaries built against old lib and new lib, but things in Debian will be ok. Also, as you note, not too many things are using Qt5 yet; might be a good time to get this right. Likely something the release team would be able to advise on, I would guess. I really don't know, it was already there when I started using Qt back in Qt3's final days ;-) Eh ok; if you get the chance to ask, that would be helpful to know when porting apps; perhaps it's something to bring up upstream in issues faced by distros kind of chatters :-) -- Loïc Minier -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131107175531.ga25...@bee.dooz.org
Re: Bits from the Release Team (Jessie freeze info)
Am 29.10.2013 17:48, schrieb Ian Jackson: (Mind you, I have my doubts about a process which counts people promising to do work - it sets up some rather unfortunate incentives. I guess it's easier to judge and more prospective than a process which attempts to gauge whether the work has been done well enough.) As an example I remember having received several complains from e.g. the GCC maintainers in regards to the state of gcc on various ports[1]. Here I would suspect a patch would be sufficient without needing to actually NMU gcc to get the fix in. There are also stuff like the port concerns from DSA that attention. Right. that's not enough. GCC has some primary and some secondary release architectures. Toolchain support for primary architectures in Debian should be waived, for the secondary and other architectures, Debian needs somebody who is maintaining the relationship between Debian and upstream. Surprisingly this is the case for many non-release Debian architectures like kfreebsd, the Hurd, alpha, hppa, m68k, but not for Debian release architectures like s390, sparc, ia64 and mips*. So we really need somebody to care about this, where the port is considered a secondary citizen or no citizen, or we should demote a port to the ports archive. Matthias -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527c2170.8020...@debian.org
