[Buildroot] X11 component versions

[Buildroot] X11 component versions

[Nicolas Dechesne]

hi there,

i was wondering if there is any policy regarding how/when X11
components are being upgraded in BR. at the moment some pieces seem a
little old (xserver is from b/o 2011, libdrm is from e/o 2010...)
perhaps most BR population might not be using X11, but i might be
wrong.

i expect that upgrading all x11 components is not a trivial task...
and I was thinking that we could at least try to bring up all
components corresponding to the R7.7 [1] release which was done
earlier this year...

i would appreciate your thoughts on this!

thx

nicolas


[1] : http://xorg.freedesktop.org/releases/X11R7.7/

[Buildroot] X11 component versions

[Will Wagner]

On 04/02/2013 09:44, Nicolas Dechesne wrote:
> hi there,
>

snip

> i expect that upgrading all x11 components is not a trivial task...
> and I was thinking that we could at least try to bring up all
> components corresponding to the R7.7 [1] release which was done
> earlier this year...

I have a set of patches for doing just that, just not had a chance to 
get back to it and tidy them up for submission.

It's still on my list of things to do, hopefully I'll find some time for 
it soon.

Regards
Will


-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] X11 component versions

[Nicolas Dechesne]

On Mon, Feb 4, 2013 at 11:45 AM, Will Wagner <will_wagner@carallon.com> wrote:
> I have a set of patches for doing just that, just not had a chance to get
> back to it and tidy them up for submission.
>
> It's still on my list of things to do, hopefully I'll find some time for it
> soon.

nice. if you have a 'not-yet-ready' branch somewhere, i can look at
it, and test. I am primarily interesting in trying it on Pandaboard,
and in that process I can package the xf86-video-omap X11 driver as
well (which was what I wanted to do initially, until i realized that
X11 in BR was too old ;-)

[Buildroot] X11 component versions

[Will Wagner]

On 04/02/2013 10:56, Nicolas Dechesne wrote:
> On Mon, Feb 4, 2013 at 11:45 AM, Will Wagner <will_wagner@carallon.com> wrote:
>> I have a set of patches for doing just that, just not had a chance to get
>> back to it and tidy them up for submission.
>>
>> It's still on my list of things to do, hopefully I'll find some time for it
>> soon.
>
> nice. if you have a 'not-yet-ready' branch somewhere, i can look at
> it, and test. I am primarily interesting in trying it on Pandaboard,
> and in that process I can package the xf86-video-omap X11 driver as
> well (which was what I wanted to do initially, until i realized that
> X11 in BR was too old ;-)
>

You can find my work on updating to x11r7.7 on gitorious at
https://gitorious.org/willw-buildroot/willw-buildroot/commits/remotes/gitorious/x11r7.7 


It is now based on a much older buildroot version and needs a lot of 
work to update.

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

[Buildroot] X11 component versions

[Thomas Petazzoni]

Will, Nicolas,

On Mon, 04 Feb 2013 11:11:36 +0000, Will Wagner wrote:

> You can find my work on updating to x11r7.7 on gitorious at
> https://gitorious.org/willw-buildroot/willw-buildroot/commits/remotes/gitorious/x11r7.7 
> 
> It is now based on a much older buildroot version and needs a lot of 
> work to update.

Also you could look at the support/scripts/xorg-release script I added
some time ago. For each X.org component, it compares the version we
have in Buildroot with the version available in a certain X.org
release (currently X11R7.7).

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] X11 component versions

[Nicolas Dechesne]

On Mon, Feb 4, 2013 at 12:11 PM, Will Wagner <will_wagner@carallon.com> wrote:
> You can find my work on updating to x11r7.7 on gitorious at
> https://gitorious.org/willw-buildroot/willw-buildroot/commits/remotes/gitorious/x11r7.7
>
> It is now based on a much older buildroot version and needs a lot of work to
> update.

thanks. i am starting to look at what you've done (and rebase on
master). however I don't understand how you came up with the large
list of 'removed' components [1].

some comments:
 - why did you remove any of the xapp_xxx components? these one are
generally not included in the X11 R7.x releases, and are released
separately. i don't understand why we should remove them from BR
during a X11 version upgrade
 - i agree with your list of removed drivers (xdriver_xxx)
 - I agree that the following components were removed during R7.4 to
R7.5 migration:
font-bitstream-speedo-1.0.0.tar.gz
fontcacheproto-0.1.2.tar.gz
libXfontcache-1.0.4.tar.gz
 - for everything else, i don't know why you removed them.

cheers

nico



[1] : $ git log --oneline
master..remotes/will/remotes/gitorious/x11r7.7  | grep removed | awk
'{print $2}'
xapp_xinit:
xproto_xf86rushproto:
xproto_printproto:
xproto_fontcacheproto:
xfont_font-bitstream-speedo:
xcb-util:
xlib_lixXprintUtil:
xlib_libXprintAppUtil:
xlib_libXp:
xlib_libxkbui:
xlib_libXfontcache:
xlib_liboldX:
xdriver_xf86-video-xgixp:
xdriver_xf86-video-xgi:
xdriver_xf86-video-tseng:
xdriver_xf86-video-suntcx:
xdriver_xf86-video-sunleo:
xdriver_xf86-video-suncg3:
xdriver_xf86-video-suncg14:
xdriver_xf86-video-sisusb:
xdriver_xf86-video-s3virge:
xdriver_xf86-video-s3:
xdriver_xf86-video-rendition:
xdriver_xf86-video-i740:
xdriver_xf86-video-chips:
xdriver_xf86-video-apm:
xdriver_xf86-input-aiptek:
xdriver_xf86-input-acecad:
xapp_xvidtune:
xapp_xstdcmap:
xapp_xsm:
xapp_xsetpointer:
xapp_xsetmode:
xapp_xprehashprinterlist:
xapp_xplsprinters:
xapp_xmore:
xapp_xmh:
xapp_xmessage:
xapp_xman:
xapp_xmag:
xapp_xlsfonts:
xapp_xlogo:
xapp_xload:
xapp_xkbprint:
xapp_xgc:
xapp_xfsinfo:
xapp_xfs:
xapp_xfontsel:
xapp_xfd:
xapp_xf86dga:
xapp_xeyes:
xapp_xedit:
xapp_xdm:
xapp_xditview:
xapp_xdbedizzy:
xapp_xclock:
xapp_xclipboard:
xapp_xcalc:
xapp_xbiff:
xapp_viewres:
xapp_twm:
xapp_showfont:
xapp_scripts:
xapp_rstart:
xapp_rgb:
xapp_oclock:
xapp_listres:
xapp_ico:
xapp_fstobdf:
xapp_fslsfonts:
xapp_fonttosfnt:
xapp_editres:
xapp_bitmap:
xapp_beforelight:
xapp_appres:

[Buildroot] X11 component versions

[Nicolas Dechesne]

On Mon, Feb 4, 2013 at 9:40 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Also you could look at the support/scripts/xorg-release script I added
> some time ago. For each X.org component, it compares the version we
> have in Buildroot with the version available in a certain X.org
> release (currently X11R7.7).

ouch.... nice scripts! i think i was just re-doing them locally ;-)
thanks for pointing this out.

especially because it explains why Will was trying to remove all the
components mentioned in my previous email.

i would tend to say that the scripts is wrong when it 'recomments'
'remove from buildroot'. It looks like you check only for the
components in the 'src/everything' folder, however as I said in my
previous email, some components are generally not included in the
release, like the applications.

[Buildroot] X11 component versions

[Thomas Petazzoni]

Dear Nicolas Dechesne,

On Mon, 4 Feb 2013 21:49:50 +0100, Nicolas Dechesne wrote:

> especially because it explains why Will was trying to remove all the
> components mentioned in my previous email.
> 
> i would tend to say that the scripts is wrong when it 'recomments'
> 'remove from buildroot'. It looks like you check only for the
> components in the 'src/everything' folder, however as I said in my
> previous email, some components are generally not included in the
> release, like the applications.

Yes, I am not sure what to do with the applications. Some of them
appear to be part of X.org releases, but not all of them. Not sure what
to do about these.

Do you have a suggestion?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] X11 component versions

[Nicolas Dechesne]

On Mon, Feb 4, 2013 at 10:30 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Yes, I am not sure what to do with the applications. Some of them
> appear to be part of X.org releases, but not all of them. Not sure what
> to do about these.
>
> Do you have a suggestion?

well, what i would say is:
 - for apps included in X11 release, take them all
 - for other apps, it's a 'distro' choice to include it... so I would
keep the one we have already, here I assume there must be a reason why
they are there in BR already... and we can add new ones as needed...

another question: do we really want to have 100+ patches to upgrade to
R7.7, or should we make 1 commit that bumps all components (and
remove/add the relevant ones)? I am asking because i think that any
'commit' in between the 100+ patches could put BR in a bad state.. Of
course if we upgrade just 1 specific component later on (before R7.8
is made) then it can be made 'manually', but for large release
upgrade, maybe 1 commit makes sense..

your xorg-release script is really nice, we could even have the script
update the recipe ;-)

[Buildroot] X11 component versions

[Arnout Vandecappelle]

On 04/02/13 22:37, Nicolas Dechesne wrote:
> another question: do we really want to have 100+ patches to upgrade to
> R7.7, or should we make 1 commit that bumps all components (and
> remove/add the relevant ones)? I am asking because i think that any
> 'commit' in between the 100+ patches could put BR in a bad state.. Of
> course if we upgrade just 1 specific component later on (before R7.8
> is made) then it can be made 'manually', but for large release
> upgrade, maybe 1 commit makes sense..

  I certainly prefer a single tested patch than 100 patches where the 
intermediate steps have not been tested.

  The server should perhaps be a separate patch, because it probably 
needs changes in the configure options as well. But then again, this 
could leave the tree in an unbuildable state...

  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] X11 component versions

[Thomas Petazzoni]

Dear Nicolas Dechesne,

On Mon, 4 Feb 2013 22:37:36 +0100, Nicolas Dechesne wrote:

> well, what i would say is:
>  - for apps included in X11 release, take them all
>  - for other apps, it's a 'distro' choice to include it... so I would
> keep the one we have already, here I assume there must be a reason why
> they are there in BR already... and we can add new ones as needed...

We have two choices:

 * Move those apps outside of package/x11r7, so that package/x11r7 only
   contains packages that are part of official X11R7 releases. But we
   already have things like the x86-input-tslib package that is in
   package/x11r7, but is in fact not a X.org project at all.

 * Add additional exceptions for those applications in the xorg-release
   script, just to make the output of this script more meaningful.

I also feel like we have a lot of those old xapp_<something> and that
not many of them are actually useful beyond a good old xeyes to test
that your X.org server runs and that the mouse is working, and possibly
a few tools like xapp_xev and stuff like that.

But really, who cares about xman, xmh, xbiff, xcalc and similar things?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] X11 component versions

[Nicolas Dechesne]

On Mon, Feb 4, 2013 at 11:06 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>  I certainly prefer a single tested patch than 100 patches where the
> intermediate steps have not been tested.
>
>  The server should perhaps be a separate patch, because it probably needs
> changes in the configure options as well. But then again, this could leave
> the tree in an unbuildable state...

+1 for 1 big patch.

i will look into that, hopefully with Will, and hopefully we can
upgrade soon , at least before R7.8 ;-)

[Buildroot] X11 component versions

[Nicolas Dechesne]

On Mon, Feb 4, 2013 at 11:24 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> We have two choices:
>
>  * Move those apps outside of package/x11r7, so that package/x11r7 only
>    contains packages that are part of official X11R7 releases. But we
>    already have things like the x86-input-tslib package that is in
>    package/x11r7, but is in fact not a X.org project at all.

this seems a better option indeed. i will try to cook a patch for
that. i assume something like packages/x11apps should be a good
package name, or perhaps x11_xorg_apps to make the distinction between
apps from x.org and any other app that would use X11..

>
>  * Add additional exceptions for those applications in the xorg-release
>    script, just to make the output of this script more meaningful.
>
> I also feel like we have a lot of those old xapp_<something> and that
> not many of them are actually useful beyond a good old xeyes to test
> that your X.org server runs and that the mouse is working, and possibly
> a few tools like xapp_xev and stuff like that.
>
> But really, who cares about xman, xmh, xbiff, xcalc and similar things?

sure, once we are done with the migration, we can remove unused apps.

[Buildroot] X11 component versions

[Peter Korsgaard]

>>>>> "Nicolas" == Nicolas Dechesne <ndec13@gmail.com> writes:

 Nicolas> hi there,

 Nicolas> i was wondering if there is any policy regarding how/when X11
 Nicolas> components are being upgraded in BR. at the moment some pieces
 Nicolas> seem a little old (xserver is from b/o 2011, libdrm is from
 Nicolas> e/o 2010...)  perhaps most BR population might not be using
 Nicolas> X11, but i might be wrong.

 Nicolas> i expect that upgrading all x11 components is not a trivial
 Nicolas> task...  and I was thinking that we could at least try to
 Nicolas> bring up all components corresponding to the R7.7 [1] release
 Nicolas> which was done earlier this year...

Our X11 packages were updated to the 7.6 release relatively recently
(September). Any help in updating to 7.7 would be appreciated.

Also see ./support/scripts/xorg-release for an overview of what packages
needs to be updated.

-- 
Bye, Peter Korsgaard

[Buildroot] X11 component versions

[Thomas Petazzoni]

Dear Nicolas Dechesne,

On Mon, 4 Feb 2013 23:45:50 +0100, Nicolas Dechesne wrote:

> this seems a better option indeed. i will try to cook a patch for
> that. i assume something like packages/x11apps should be a good
> package name, or perhaps x11_xorg_apps to make the distinction between
> apps from x.org and any other app that would use X11..

I am not quite sure about this solution, because it means that all
packages that are not part of official X.org releases would have to be
moved away from the package/x11r7 directory. For example, the tslib
driver I pointed, but they are also other X.org drivers that could be
added in the future and that are not part of official X.org releases.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] X11 component versions

[Jesper Birksø Bækdahl]

Hi guys

Nicolas Dechesne <ndec13@...> writes:
>
> On Mon, Feb 4, 2013 at 12:11 PM, Will Wagner <will_wagner@...> wrote:
> > You can find my work on updating to x11r7.7 on gitorious at
> >
https://gitorious.org/willw-buildroot/willw-buildroot/commits/remotes/gitorious/x11r7.7
> >
> > It is now based on a much older buildroot version and needs a lot of
work to
> > update.
>
> thanks. i am starting to look at what you've done (and rebase on
> master). however I don't understand how you came up with the large
> list of 'removed' components [1].
>
> some comments:
>  - why did you remove any of the xapp_xxx components? these one are
> generally not included in the X11 R7.x releases, and are released
> separately. i don't understand why we should remove them from BR
> during a X11 version upgrade
>  - i agree with your list of removed drivers (xdriver_xxx)
>  - I agree that the following components were removed during R7.4 to
> R7.5 migration:
> font-bitstream-speedo-1.0.0.tar.gz
> fontcacheproto-0.1.2.tar.gz
> libXfontcache-1.0.4.tar.gz
>  - for everything else, i don't know why you removed them.
>

I have tried to rebase the x11r7.7 patches on master. I chose not to remove
all app components for the reasons mentioned by Nicolas Dechesne.

As this is my first time contributing to buildroot, I don't know the
procedures when dealing with this many patches at once, so for now I have
just pushed my version of the branch to:
https://bitbucket.org/baekdahl/buildroot/src/b8db03aa6921/?at=x11r77

Hope someone will take a look.

Regards, Jesper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130312/84d32c98/attachment.html>

[Buildroot] X11 component versions

[Arnout Vandecappelle]

  Hi Jesper,

On 03/12/13 09:52, Jesper Birks? B?kdahl wrote:
[snip]
> I have tried to rebase the x11r7.7 patches on master. I chose not to
> remove all app components for the reasons mentioned by Nicolas Dechesne.
>
> As this is my first time contributing to buildroot, I don't know the
> procedures when dealing with this many patches at once, so for now I have
> just pushed my version of the branch to:
> https://bitbucket.org/baekdahl/buildroot/src/b8db03aa6921/?at=x11r77

  Thank you for your work. Clearly, nobody has taken a look yet :-). It 
is probably better to post the patch series to the list after all. You 
will most likely only get feedback on the first few patches, but there's 
no problem with that, right? Posting a long patch series only has the 
disadvantage of a bit more patchwork cleanup work.

  Here are some pointers about what we like to see in patches:

- Use git send-email to send them.

- Make sure all of them are Signed-off-by you, even if you didn't author 
them (just put your Sob under the original author's; cfr. Peter's Sob's 
in the git log).

- In patches which have been submitted before, add a changelog (under the 
Sob lines, separated by ---).

- Add an introductory e-mail (with git send-email --compose) explaining 
what the series is about, and indicating which parts you're less sure of 
and would like to get feedback on.


  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F