Re: Bits from the Release Team (Jessie freeze info)

[Matthias Klose]

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

Re: Qt5 switching qreal from float to double on arm*

[Loïc Minier]

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: Qt5 switching qreal from float to double on arm*

[Lisandro Damián Nicanor Pérez Meyer]

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*

[Lisandro Damián Nicanor Pérez Meyer]

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] 


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] 


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*

[Loïc Minier]

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.

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.

* what about arm64?  sounds like this one should be double from the
  start; not sure what it is right now

* 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

* 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


Thanks again for raising this!

-- 
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/20131107171818.gb12...@bee.dooz.org

Re: Bug#728975: linux: [ARM] CONFIG_OABI_COMPAT harmful (slower, unsafe, breaks at least seccomp and audit)

[Ian Campbell]

(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: Debian 7.0 on Dreamplug basic installation and booting system external sd card

[Loïc Minier]

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: recommend a netbook for Debian deployment?

[Luke Kenneth Casson Leighton]

On Thu, Nov 7, 2013 at 4:41 AM, Luc Verhaegen  wrote:

> As for netbooks, that format is not too popular right now, so the cheap
> chinese sweatshops are not churning many out. Lkcls tablet project is
> turning out to be quite a lot of painstaking work, and taking much
> longer than anyone expected.

 *grind, teeth-gnashing*.  me included.  the silver lining is that the
ATSAM4 is a far-superior embedded controller and could well cost us
less as well.

 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/capweedyebzfb5ognu0vkt-hfu4kajde3_argfmvta8xt5yu...@mail.gmail.com

Re: recommend a netbook for Debian deployment?

[Luke Kenneth Casson Leighton]

On Wed, Nov 6, 2013 at 10:55 PM, Luc Verhaegen  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  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: Removing lvm and crypto from rootfs

[Björn Wetterbom]

>
> 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.