gmane.linux.mandrake.cooker.devel

Re: Re: Packaging Qt (4) for Embedded Linux...

Matthew Dawkins — 2012-05-23T12:24:13


Well you need an armv7hl (I believe that's the correct extension) board to
start with. That would be the Pandaboard or something similiar and an
install. I think PCPA and myself used chroots to build in. PCPA messed more
with v7 and compat binaries, while all my work and interest was more in
armv5te.

The problem is this. If no dedicated space is given for hosting and syncing
the rpms, then it's quite worthless to start up again. The other part was
to organize some way to build packages also built on cooker.

Matt

Re: Re: Packaging Qt (4) for Embedded Linux...

Alexander Khryukin — 2012-05-23T10:24:30

2012/5/23 Franck Bui <franck.bui< at >mandriva.com>



any solution or wiki how to build arm7 packages?

Re: Re: [RPM] cooker main/release mkinitrd-6.0.93-24

Oden Eriksson — 2012-05-23T08:58:41

onsdagen den 23 maj 2012 09.26.39 skrev  Franck Bui:

My experience with update-alternatives is that it's very fragile, this is why 
I proposed to fix it "manually".

If you want a fail safe fix, fix it "manually" and permanently.

If you want a fragile fix depending on erratic behaviour of urpmi and update-
alternatives, do nothing.

Re: Packaging Qt (4) for Embedded Linux...

Franck Bui — 2012-05-23T07:41:38


This repo should contain more armv7l packages and some of them have been
also updated:

     http://mes5devel.mandriva.com/~fbui/ports/cooker/armv7l/media/

It was based on pcpa initial port but I cleaned it up and added some new
packages for my need.

There's also a armv7h repo on kenobi that pcpa did, you should ask him
if you want more info.

Re: [RPM] cooker main/release mkinitrd-6.0.93-24

Franck Bui — 2012-05-23T07:26:39


Can't we do the following instead:

  - rename mkinitrd to mkinitrd-mkinitrd
  - mkinitrd-* provide "mkinitrd"
  - teach urpmi what is the distro preference for resolving "mkinitrd" dep
  - use update-alternatives so one can still override the distro preference

I'm not sure if the 3rd item is possible at all though.

Re: [RPM] cooker main/release mkinitrd-6.0.93-24

Franck Bui — 2012-05-23T07:18:51


why not ?

I'm using it on my 2010.2.

Re: Packaging Qt (4) for Embedded Linux...

Franck Bui — 2012-05-23T06:56:44

[...]


FWIW, that's how the kernel package was done one year ago: having one
src.rpm to generate all binary kernel flavours (and probably other
tools), ie "one source package to rule them all".

As you said, it's getting ugly pretty quickly IMHO, making hard to
improve, maintain the .spec.

Another way to handle that, and that's the scheme used by the kernel
packages now, is to ship the kernel source within a dedicated package
and all bin kernel flavours (in fact all packages generated from the
kernel source actually:  headers, tools etc...) are "build requiring"
the kernel source package.

So the source is maintained in one place and each derivated package
has its own .spec, which should be fairly simple at this point.

Re: grub2 and configuration tools for it

Dmitry Mikhirev — 2012-05-23T04:25:55

В Tue, 22 May 2012 09:26:23 -0400
Chris Tanner <christopher.tanner< at >sympatico.ca> пишет:


nokms option is usually required when you use proprietary video driver,
like nvidia or fglrx, that does not support kms. I suppose, the best
solution should be modifying XFdrake to handle kernel options.
Unfortunately, bootloader configurators are unable to guess what driver
you are using.

Re: Packaging Qt (4) for Embedded Linux...

Jeffrey Johnson — 2012-05-23T04:10:57

On May 22, 2012, at 11:50 PM, Andrey Bondrov <pulfer-cooker< at >list.ru> wrote:


All "normal" depsolvers cannot distinguish between multiple
provides: there is no basis for "preference" available that
makes any sense.

Yes there are attempts including "priorities" and adjusting
the search path through repositories and another attempts to
try to capture "preference".

None of the attempts are worth a damn, all the attempts are
nearly impossible to test for reliability, and are rather awkward
to use and configure.


A one time build cost isn't representative of much of anything.

Most packages are coming from distro vendors with factory build systems,
with mirror infrastructure, and attempts at automated QA.

Adjusting a recipe to conform to needs to build within
limited VM resources is a different problem than making
the build easy to maintain.

There are too many rebuilds these days for not much
purpose other than adjusting metadata to handle increasingly
exotic corner cases reported by users.

A periodic sche

Re: Packaging Qt (4) for Embedded Linux...

Andrey Bondrov — 2012-05-23T03:50:46

23.05.2012 14:11, Jeffrey Johnson пишет:

I mean I'm interested in libqtgui4 and libqteqtgui4 Provides. If both 
packages provide libQtGui.so.4, isn't it potentially dangerous? It's not 
about "buggy" depsolvers, it's about "normal" depsolvers.


My criteria is mostly local and build system's resources. If build fails 
on "unpackaged files found" or some new rplmint errors, it's better to 
waste 1-4 hours on rebuild than 2-8 hours. And sometimes not 1 but 2 
rebuilds are needed to resolve all issues. Not a big deal for people who 
have Core i7 with 8 Gb RAM. But quite a pain for people like me who 
build packages inside Virtual Box installations with one of E8400 cores 
and 1 Gb RAM dedicated. And for people who won't be able to build 
anything while build system is blocked by Qt4 builds.

So personally I'd prefer to prepare Qt/X11 package update and then sync 
all changes with Qt/E package. But I don't insist.

gcc 4.4.3 -> 4.4.7 update possibility for 2010.2

Andrey Bondrov — 2012-05-23T03:17:16

What do you think, can we push gcc 4.4.3 -> 4.4.7 update to 2010.2 
main/updates?

Re: Packaging Qt (4) for Embedded Linux...

Jeffrey Johnson — 2012-05-23T03:11:38

On May 22, 2012, at 11:09 PM, Andrey Bondrov wrote:


The term "safe" obscures the mechanism and the failure modes.

E.g. blaming the assertions for "buggy" depsolvers and packagers rather misses
the point …


You claim "better" without stating your criteria precisely.

My minority/contrary POV sea its easier to maintain one large
*.spec file carefully than multiple *.spec files haphazardly.

BUt when you get into bloaty multiple duplications of nearly -- but not quite --
identical software, perhaps its easier to cut-n-paste cookie-cutter recipes
rather than attempting something intelligent or creative or "risky" (in
the sense that it isn't identical to every other linux distro on the planet).

hth

73 de Jeff

Re: Packaging Qt (4) for Embedded Linux...

Andrey Bondrov — 2012-05-23T03:09:39

23.05.2012 6:46, Bernhard Rosenkränzer пишет:

Is it safe? Won't it lead to installing wrong packages as Requires?


IMHO, separate SRPMs are better solution. Qt4 spec is very big already 
and making it 2 times bigger doesn't sound good. And yes, doubling Qt4 
build time will be quite a pain because it already builds for few hours 
in general.

Re: Packaging Qt (4) for Embedded Linux...

Jeffrey Johnson — 2012-05-23T01:50:27

On May 22, 2012, at 6:21 PM, Bernhard Rosenkränzer wrote:


Not exactly "working" on ARM because that is not the tasks I am asked to perform
by manglement.

The package files are available through UL but ithere's too many duplicates
and too much history to make any sense: a release never appeared (was proposed for 11/11/11)
because of zero interest from Mandriva occupied with coming out
of bankruptcy, and only modest interest from Andrew Shubin of ROSA,
who believes that "desktop" package mixture is too bloaty on ARM
(Shubin isn't/wasn't wrong, just you gotta start someplace).

I tried … fairly hard actually … for months. *shrug*


The panda boards were already hooked up to either Mandriva iurt/jurt build system by Bogdano
and pcpa: this involved a VPN into a chroot (which makes my head hurt *a lot*) but
was functional even if a bit slow (so I was told).

pcpa did an enormous amount of "heavy lifting" on armv7: my interest(s) at the time
were understanding care-and-feeding of mock in Fedora.

There has

Fwd: Re: Packaging Qt (4) for Embedded Linux...

Bernhard Rosenkränzer — 2012-05-22T22:21:23

Reposting, didn't get through last time because I was using another sender

On 05/22/2012 11:06 PM, Jeffrey Johnson wrote:

That's great! While I knew you had some ARM devices floating around, I
didn't know you (or anyone else) were working on the ARM port since the
files never appeared anywhere and they disappeared from the last
location I knew.

Can we somehow get this hooked up to the build system?

ttyl
bero

Re: Packaging Qt (4) for Embedded Linux...

Jeffrey Johnson — 2012-05-22T21:06:56

On May 22, 2012, at 4:48 PM, Bernhard Rosenkränzer wrote:


Good for you!

You do realize that I have ~24 ARM devices < at >jbj.org including:
6 pandaboards (1 is a 4460)
2 dreamplugs
All of the panda boards have 2 TB seagate drives and 16GB SD cards.
The 2 dreamplugs have 1TB eSata drives.

And there is certainly later than cooker-20110901.tar.gz littering the disks.

The lights go blinking while ROSA and Mandriva figure their "business" issues …
… and I attempt a "content addressable" specspo replacement for package i18n ...

*shrug* Its a job mon ...

73 de Jeff

Re: Packaging Qt (4) for Embedded Linux...

Bernhard Rosenkränzer — 2012-05-22T20:48:20

I have a spare quad-core arm board floating around - and a tarball of an 
older port (cooker-armv7l-20110901.tar.xz) -- unless someone has 
something newer, I'm planning to revive that (and, most importantly, 
automatically build new Cooker packages so it doesn't end up being far 
behind the rest of the world again).

ttyl
bero

Re: Packaging Qt (4) for Embedded Linux...

Jeffrey Johnson — 2012-05-22T19:51:56

On May 22, 2012, at 3:46 PM, Bernhard Rosenkränzer wrote:


POI: What ARM port?

73 de Jeff

Packaging Qt (4) for Embedded Linux...

Bernhard Rosenkränzer — 2012-05-22T19:46:01

Hi,
I'd like to package Qt for Embedded Linux (not only for the ARM port, 
but also because it can be rather useful on a desktop too - e.g. to 
create a graphical tool to configure X if it fails to start up).

There's a couple of things that don't have a very nice solution though - 
let's see if we can find a consensus on how to resolve those (if I don't 
receive any feedback, I'll go ahead with what I think is the best way to 
go -- so complain now or never ;) ).

- The sonames for Qt/E are the same as those for Qt/X11 - not a problem 
in the
   filesystem because we can install them in a different directory, but 
theoretically,
   both packages should have the "lib{64,}qtgui4" package name.
   Proposal: Make the package name reflect the filesystem location a bit 
and go for
   lib{64,}qteqtgui4 or something similar)
   Alternatives:
   - lib{64,}qtgui4-qte
   - Forget about the normal naming policy and just build a qte package

- Since Qt/E and Qt/X11 are built from the same source these days, it 
would be

Re: [RPM] cooker main/release mkinitrd-6.0.93-24

Matthew Dawkins — 2012-05-22T18:34:59


*shouldn't*

Re: [RPM] cooker main/release mkinitrd-6.0.93-24

Matthew Dawkins — 2012-05-22T18:34:39



What ever the fix is, it should include tools that require perl to
bootstrap the system.