Nightly builds?

[David Gerard-2]

I've noticed a few old video chipsets are dropping off the edge of Xorg.

This is entirely understandable - Xorg has too few developers
desperately trying to drag the 1990s code base into the twenty-first
century and there are very few testers for the ancient chips. So many
of them have broken, and no-one much notices until the distros release
that version of X. No-one wants this to happen, but it does.

e.g. Ubuntu 9.10 is fantastic on current chips. (Typing this on my new
work Portege R600. Wobbly windows a go go!) But old stuff is showing
breakage, and it's unlikely to be fixed.

The one thing that occurs to me is: make testing of git head much
easier. Much, much easier.

1. Nightly builds. Did wonders for Mozilla. Binary of main supported
architectures (linux/i386, opensolaris, whatever someone will be able
to commit to build nightly). Download and run. Report bugs.
2. Make the source build easier, so people will build and run it from
source for the more obscure platforms.

1. requires build server, web server and bandwidth resources. 2.
requires polishing and debugging and making it very easy for people to
just keep up with X with a git pull.

Ideas? Is this pointing toward something useful?

(I'm not a coder myself or I'd be bashing on 2., but I do like
reviving crusty old machinery.)


- d.
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Alan Coopersmith]

David Gerard wrote:
> 1. Nightly builds. Did wonders for Mozilla. Binary of main supported
> architectures (linux/i386, opensolaris, whatever someone will be able
> to commit to build nightly). Download and run. Report bugs.

Already done, but much more often than just once a night:
        http://tinderbox.freedesktop.org/

--
        -Alan Coopersmith-           alan.coopersmith@...
         Sun Microsystems, Inc. - X Window System Engineering

_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Mikhail Gusarov-3]

Twas brillig at 19:34:33 05.11.2009 UTC-08 when Alan.Coopersmith@... did gyre and gimble:

 >> 1. Nightly builds. Did wonders for Mozilla. Binary of main supported
 >> architectures (linux/i386, opensolaris, whatever someone will be
 >> able to commit to build nightly). Download and run. Report bugs.

 AC> Already done, but much more often than just once a night:
 AC> http://tinderbox.freedesktop.org/

I think what David wants is nightly builds which produce binaries to be
downloadable and testable by users.

--
  http://fossarchy.blogspot.com/


_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Tormod Volden]

On Fri, Nov 6, 2009 at 2:27 AM, David Gerard <dgerard@...> wrote:
> I've noticed a few old video chipsets are dropping off the edge of Xorg.

> The one thing that occurs to me is: make testing of git head much
> easier. Much, much easier.
>
> 1. Nightly builds. Did wonders for Mozilla. Binary of main supported
> architectures (linux/i386, opensolaris, whatever someone will be able
> to commit to build nightly). Download and run. Report bugs.

For Ubuntu there is the xorg-edgers PPA (personal package archive)
which have done exactly this for years:
https://launchpad.net/~xorg-edgers

It is even easier than "download" because users can subscribe to it as
a normal package repository (although we do not really recommend this
for everyone) and get their daily crack through the "Update Manager".

> 2. Make the source build easier, so people will build and run it from
> source for the more obscure platforms.

In the xorg-edgers team code section, there are scripts (for Debian
family distros) to simplify building the whole stack from git and wrap
it in Debian packages with no git or dpkg skills needed.

> (I'm not a coder myself or I'd be bashing on 2., but I do like
> reviving crusty old machinery.)

Testing is very welcome. Typically users with newer material are the
most keen users of the PPA since they often gain new features and
higher performance. Those with older material unfortunately do not
have the same incentive to keep trying the latest software. As an
example the release of Ubuntu 9.10 exposed many issues for users with
old ATI hardware which had not been reported before. On the other
hand, the PPA is very popular among users with Intel hardware (because
the quality of the driver in Ubuntu 9.04 reached a point where it
could only improve) so we get instant feedback almost at a per-commit
basis.

Tormod
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Rémi Cardona-3]

Le 06/11/2009 08:48, Tormod Volden a écrit :
>> 1. Nightly builds. Did wonders for Mozilla. Binary of main supported
>> architectures (linux/i386, opensolaris, whatever someone will be able
>> to commit to build nightly). Download and run. Report bugs.

Xorg is not your standard application. In nearly all distros, X is
configured differently, with different paths, etc. So even if we did do
binary builds, it would be much harder for users to actually "download
and run".

And now that X drivers are being trimmed down in favor of kernel
drivers, that only makes things more complex.

> For Ubuntu there is the xorg-edgers PPA (personal package archive)
> which have done exactly this for years:
> https://launchpad.net/~xorg-edgers

In Gentoo, we have the x11 overlay which provides "live" packages.
Whenever the user builds one of our "live" packages, the code is fetched
from git and completely rebuilt. And with a single command, users can
rebuild all "live" packages.

As far as testing is concerned, both our approaches are extremely easy
for end-users and completely integrated with the distro's package manager.

>> 2. Make the source build easier, so people will build and run it from
>> source for the more obscure platforms.

My answer to that would be build.sh or jhbuild. All the info is written
down in the wiki [1].

Sure it could probably be easier, but it's not like there's nothing at
all. But building from source _is_ tricky and you have to have some
prior knowledge before building large source trees like Xorg.

Cheers,

Rémi
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[David Gerard-2]

2009/11/6 Tormod Volden <lists.tormod@...>:
> On Fri, Nov 6, 2009 at 2:27 AM, David Gerard <dgerard@...> wrote:

>> 1. Nightly builds. Did wonders for Mozilla. Binary of main supported
>> architectures (linux/i386, opensolaris, whatever someone will be able
>> to commit to build nightly). Download and run. Report bugs.

> For Ubuntu there is the xorg-edgers PPA (personal package archive)
> which have done exactly this for years:
> https://launchpad.net/~xorg-edgers


That's perfect :-D

(At least for those of us using Ubuntu ;-)


- d.
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[David Gerard-2]

2009/11/6 Rémi Cardona <remi@...>:
> Le 06/11/2009 08:48, Tormod Volden a écrit :

>>> 1. Nightly builds. Did wonders for Mozilla. Binary of main supported
>>> architectures (linux/i386, opensolaris, whatever someone will be able
>>> to commit to build nightly). Download and run. Report bugs.

> Xorg is not your standard application. In nearly all distros, X is
> configured differently, with different paths, etc. So even if we did do
> binary builds, it would be much harder for users to actually "download
> and run".
> And now that X drivers are being trimmed down in favor of kernel
> drivers, that only makes things more complex.


Indeed, there is that. Hmm.


>>> 2. Make the source build easier, so people will build and run it from
>>> source for the more obscure platforms.

> My answer to that would be build.sh or jhbuild. All the info is written
> down in the wiki [1].
> Sure it could probably be easier, but it's not like there's nothing at
> all. But building from source _is_ tricky and you have to have some
> prior knowledge before building large source trees like Xorg.


Yeah. But if I can build gcc or KDE with a few shell commands (more
than configure && make && make install, but it's still pretty easy),
the problem of making it easier is not infeasible.

(Of course, then there's the problem of reliable cross-compilation, so
you can build it quickly on a modern machine for your old crusty one
... but that'll come next.)


- d.
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Johannes Truschnigg]

On Friday 06 November 2009 09:19:35 David Gerard wrote:
> 2009/11/6 Tormod Volden <lists.tormod@...>:
> > On Fri, Nov 6, 2009 at 2:27 AM, David Gerard <dgerard@...> wrote:
> > […]
> > https://launchpad.net/~xorg-edgers
> > […]

Does the Ubuntu infrastructure allow third parties for easy creation of
bootable live media, whilst incorporating packages like those from the PPA?
It'd be awesome to have a slim, up-to-date live environment with the newest
bits of the Linux kernel and Xorg around for testing, without modifying one's
local setup too much (or at all), don't you think?
--
with best regards:
- Johannes Truschnigg ( johannes@... )

www: http://johannes.truschnigg.info/
phone: [phone]
jabber: johannes.truschnigg@...

Please do not bother me with HTML-eMail or attachments. Thank you.


_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Christopher Lightfoot]

Hi,

On top of that is there anywhere/one within the community that has
some sort of hardware test centre - how does hardware testing take
place? Is it something only done by developers if they have the
hardware or only done by clients using log dumps?

One of the most common complaints I hear when reporting problems is
the developer doesn't have the hardware to test that particular
chipset or graphics card or cpu etc - how difficult would it be to set
up a central hub of hardware that is used solely for testing open
source projects? I realise everyone always argues about sharing these
things but surely that's a better position to be in than not having
the hardware to test against at all.

Basically people should either by able to donate money or hardware and
receive some sort of badge or something to make them feel good and
somebody just sets up combinations of machines that just then sit
there and test code; every night the latest build is downloaded and
ran against some fixed test on all the variations of graphics cards or
whatever and the results are returned.

The other approach is some form of distributed testing that users can
opt-in to do that doesn't break their current system but does an
accurate test on their hardware; I know screen savers are old hat but
is there any way you could put together something that when their
machine is idle gets the latest build and runs some tests against
their card or hardware and reports back.

Chris


On Fri, Nov 6, 2009 at 1:27 AM, David Gerard <dgerard@...> wrote:

> I've noticed a few old video chipsets are dropping off the edge of Xorg.
>
> This is entirely understandable - Xorg has too few developers
> desperately trying to drag the 1990s code base into the twenty-first
> century and there are very few testers for the ancient chips. So many
> of them have broken, and no-one much notices until the distros release
> that version of X. No-one wants this to happen, but it does.
>
> e.g. Ubuntu 9.10 is fantastic on current chips. (Typing this on my new
> work Portege R600. Wobbly windows a go go!) But old stuff is showing
> breakage, and it's unlikely to be fixed.
>
> The one thing that occurs to me is: make testing of git head much
> easier. Much, much easier.
>
> 1. Nightly builds. Did wonders for Mozilla. Binary of main supported
> architectures (linux/i386, opensolaris, whatever someone will be able
> to commit to build nightly). Download and run. Report bugs.
> 2. Make the source build easier, so people will build and run it from
> source for the more obscure platforms.
>
> 1. requires build server, web server and bandwidth resources. 2.
> requires polishing and debugging and making it very easy for people to
> just keep up with X with a git pull.
>
> Ideas? Is this pointing toward something useful?
>
> (I'm not a coder myself or I'd be bashing on 2., but I do like
> reviving crusty old machinery.)
>
>
> - d.
> _______________________________________________
> xorg mailing list
> xorg@...
> http://lists.freedesktop.org/mailman/listinfo/xorg
>

_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Tormod Volden]

On Fri, Nov 6, 2009 at 10:21 AM, Johannes Truschnigg
<johannes@...> wrote:

> On Friday 06 November 2009 09:19:35 David Gerard wrote:
>> 2009/11/6 Tormod Volden <lists.tormod@...>:
>> > On Fri, Nov 6, 2009 at 2:27 AM, David Gerard <dgerard@...> wrote:
>> > […]
>> > https://launchpad.net/~xorg-edgers
>> > […]
>
> Does the Ubuntu infrastructure allow third parties for easy creation of
> bootable live media, whilst incorporating packages like those from the PPA?
> It'd be awesome to have a slim, up-to-date live environment with the newest
> bits of the Linux kernel and Xorg around for testing, without modifying one's
> local setup too much (or at all), don't you think?

In the xorg-edgers code tree (under Branches) there is a live-cd
script for remastering a Ubuntu live CD with the xorg-edgers packages
and new kernels. We do not roll out ISOs regularly yet though. One
current issue that although a second PPA [1] from the Ubuntu kernel
team provides daily kernel snapshot builds, it does not include the
aufs patches needed by the live CD. But we have started talking with
them about having kernels with aufs and for instance drm-next pulled
in. Note also that xorg-edgers is an independent community project,
but Canonical offers the PPA infrastructure for us and anyone else
wanting to do things like this. Hopefully they will offer to also host
ISO remastering and downloads if we get that going, since personally I
do not have the hardware/bandwidth for this.

Also phoronix.com has a live CD [2] including recent Xorg bits and
their PTS benchmarking suite.

Tormod

[1] https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
[2] http://www.phoronix-test-suite.com/?k=pts_desktop_live
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Simon Thum-2]

Rémi Cardona wrote:
> from git and completely rebuilt. And with a single command, users can
> rebuild all "live" packages.
Would you be so kind to explain what exactly you're talking about? I'd
be highly interested...

(Last time I checked, qlist didn't relate to overlays in any way.)

Thanks in advance,

Simon
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

On Friday 06 November 2009, Simon Thum wrote:

> Rémi Cardona wrote:
> > from git and completely rebuilt. And with a single command, users can
> > rebuild all "live" packages.
>
> Would you be so kind to explain what exactly you're talking about? I'd
> be highly interested...
>
> (Last time I checked, qlist didn't relate to overlays in any way.)
>
> Thanks in advance,
>

With portage-2.2 you can do:

$: emerge @live-rebuild

This rebuilds ALL 'live' (*-9999) packages currently installed on a Gentoo
system. So one strategy would be to install the live packages from the x11
overlay and rebuild them on a regular basis using the above command. The
beauty of this approach is that portage still keeps track of package
dependencies and rebuilds them in the right order.

HTH

Magnus


_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[David Gerard-2]

2009/11/6 Magnus Kessler <Magnus.Kessler@...>:

> With portage-2.2 you can do:
> $: emerge @live-rebuild
> This rebuilds ALL 'live' (*-9999) packages currently installed on a Gentoo
> system. So one strategy would be to install the live packages from the x11
> overlay and rebuild them on a regular basis using the above command. The
> beauty of this approach is that portage still keeps track of package
> dependencies and rebuilds them in the right order.


Ah, that's why we have dual quad-core processors these days ;-p


- d.
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Simon Thum-2]

Magnus Kessler wrote:

> On Friday 06 November 2009, Simon Thum wrote:
>> Rémi Cardona wrote:
>>> from git and completely rebuilt. And with a single command, users can
>>> rebuild all "live" packages.
>> Would you be so kind to explain what exactly you're talking about? I'd
>> be highly interested...
>>
>> (Last time I checked, qlist didn't relate to overlays in any way.)
>>
>> Thanks in advance,
>>
>
> With portage-2.2 you can do:
>
> $: emerge @live-rebuild
>
> This rebuilds ALL 'live' (*-9999) packages currently installed on a Gentoo
> system. So one strategy would be to install the live packages from the x11
> overlay and rebuild them on a regular basis using the above command. The
> beauty of this approach is that portage still keeps track of package
> dependencies and rebuilds them in the right order.

I guess there's nothing in it for lost souls still on portage 2.1?

If no, is it reasonably safe to upgrade?

Cheers,

Simon
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Wil Reichert]

On Sat, Nov 7, 2009 at 7:38 AM, Simon Thum <simon.thum@...> wrote:

> Magnus Kessler wrote:
>> On Friday 06 November 2009, Simon Thum wrote:
>>> Rémi Cardona wrote:
>>>> from git and completely rebuilt. And with a single command, users can
>>>> rebuild all "live" packages.
>>> Would you be so kind to explain what exactly you're talking about? I'd
>>> be highly interested...
>>>
>>> (Last time I checked, qlist didn't relate to overlays in any way.)
>>>
>>> Thanks in advance,
>>>
>>
>> With portage-2.2 you can do:
>>
>> $: emerge @live-rebuild
>>
>> This rebuilds ALL 'live' (*-9999) packages currently installed on a Gentoo
>> system. So one strategy would be to install the live packages from the x11
>> overlay and rebuild them on a regular basis using the above command. The
>> beauty of this approach is that portage still keeps track of package
>> dependencies and rebuilds them in the right order.
> I guess there's nothing in it for lost souls still on portage 2.1?
>
> If no, is it reasonably safe to upgrade?

If you want to stay with 2.1 -

emerge -1av `qlist -ICv | grep 9999 | sed -e "s/-9999*//" -e "s/-r[0-9]*//"`

Keep in mind '-9999' does not always mean live, i.e.
app-text/scrollkeeper-9999-r1 so you'll prolly get a couple extra
packages in there.

That said, I've had no issues running the latest portage 2.2 rc's.  As
long as you use quickpkg to grab a tbz2 of your current 2.1 install
the likelihood of you doing irreparable harm to your system is
minimal.

Wil
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg