Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 2005-07-18 at 13:18 -0400, Luis Villa wrote: I'm assuming that if I keep pushing this and making it more useful someone is going to eventually give me/gnome a faster box to do it on. :) (and then we get into the fun world of -j ;) I think the UCC can do something to provide number crunching power... just as soon as we work out how to cool it. Of course, most of our spare CPU power is currently in the form of Alpha CPUs, but I guess that would check that our code was also 64-bit clean. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Wed, 2005-08-03 at 08:27 -0400, Luis Villa wrote: I think the UCC can do something to provide number crunching power... just as soon as we work out how to cool it. Of course, most of our spare CPU power is currently in the form of Alpha CPUs, but I guess that would check that our code was also 64-bit clean. As long as you can get a modern OS on it that has modern tools, I'm fine with whatever :) That is remarkably easy. We've been trying to get 6 of them running as an OpenSSI cluster, but that has been stalled for time. We could set them up to run independently. The only problem I forsee is that since cvs.gnome.org it is no longer on a network we consider to be free traffic, someone will get a bill. Is there any chance of container getting an internet2 link again? --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
Hi, On Mon, 2005-07-18 at 14:34 -0400, Matthias Clasen wrote: On Mon, 2005-07-18 at 20:23 +0200, Ikke wrote: On Mon, 2005-07-18 at 13:28 -0400, Luis Villa wrote: I think the advantages of adding make distcheck are bigger than the disadvantages. OK, but what are they? :) Making sure people doing anonymous cvs checkouts will at any time be able to build the package they co, not running in major autotool problems just before a release tarball should be made,... I think that ensuring that make distcheck works at release time is the maintainers responsibility. It is only important that it works at the time the release is made. There is little value in being pestered about every time a checkin temporarily breaks make distcheck, e.g. because a new symbol was added without adding it to gtk.symbols. I think I'm with Matthias on this - make distcheck shows plenty of issues that aren't going to affect anyone in reality, and no maintainer wants to be pestered every day about the latest random thing that's gotten screwed up. If people want to distribute snapshots from CVS, then make dist will do fine. If the resulting tarball can't be built, then *they* can report *that* issue. That's going to involve a lot less problems reported and maintainers can be confident that by fixing the issues they're actually doing something useful. Cheers, Mark. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 18 Jul 2005, Alan Horkan wrote: On Mon, 18 Jul 2005, Ikke wrote: Date: Mon, 18 Jul 2005 21:42:09 +0200 From: Ikke [EMAIL PROTECTED] To: Behdad Esfahbod [EMAIL PROTECTED] Cc: Luis Villa [EMAIL PROTECTED], desktop-devel-list@gnome.org Subject: Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi] On Mon, 2005-07-18 at 15:29 -0400, Behdad Esfahbod wrote: One way to go about is to require all involved modules to have an RPM .spec file, and jhbuild can be instructed to build and install RPMs, but most probably this will not be accepted practice in GNOME. Or am I wrong? Seriously, then I want ebuilds provided for every package too. Nah, just kidding. Personally I don't think this is a good idea, as it would give one distribution a higher state than others, which is not what we want (I guess?) Supporting Autopackage wouldn't adversely affect or favour any particularly distribution and it would in fact produce packages widely usable by a whole variety of distributions. There is no Autopackage based distribution yet (nor is there likely to be). What about ximians former build tool, what's it called again? Something with monkey iirc. That was at least able to produce debs. kr, Chipzz AKA Jan Van Buggenhout -- UNIX isn't dead - It just smells funny [EMAIL PROTECTED] Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Tue, 19 Jul 2005, Mark McLoughlin wrote: I think I'm with Matthias on this - make distcheck shows plenty of issues that aren't going to affect anyone in reality, and no maintainer wants to be pestered every day about the latest random thing that's gotten screwed up. If people want to distribute snapshots from CVS, then make dist will do fine. If the resulting tarball can't be built, then *they* can report *that* issue. That's going to involve a lot less problems reported and maintainers can be confident that by fixing the issues they're actually doing something useful. I don't quite agree here. 'make distcheck' mainly checks things like building in a different directory, or from readonly source base, which are quite useful to packagers and distro people. And the point is that, if a package passes make distcheck, then any future break would be a one-line fix of adding a file to the Makefile or something like that. If fixing it is a bigger problem, like redoing part of the build system in another way, then that would better be fixed sooner than just before the release. Cheers, Mark. --behdad http://behdad.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Tue, 2005-07-19 at 10:37 -0400, Dan Winship wrote: On Mon, 2005-07-18 at 16:06 -0400, Luis Villa wrote: On 7/18/05, Andrew Sobala [EMAIL PROTECTED] wrote: On Mon, 2005-07-18 at 15:54 -0400, Colin Walters wrote: What's so difficult about jhbuild? Couldn't we make just make it easier (such as having jhbuild autodetect stuff in /usr and adjust PKG_CONFIG_PATH)? Processing power. Time. Also... Could we just package up the results of the jhbuild in a dumb, completely mechanical way, such that installing the packages would be exactly equivalent to running jhbuild? ie, it wouldn't replace or conflict with your existing GNOME packages, it would just install everything into its own special prefix. And we could have a single less-dumb package that tweaked your vendor gdm configuration to add a jhbuild gnome session. This sounds like a pretty good idea. Of course, there will likely be few, very large packages. I dunno if that matters much though. Even if they were finegrained you really need to update to the whole release to get good testing. The naming of the packages could also be such that there is no chance of conflicting with your vendor gnome, current version or later installed. If we managed to create debuginfo packages we could get nice stack traces in reports from these builds too. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a scarfaced crooked gangster in drag. She's a sarcastic green-skinned bodyguard with a birthmark shaped like Liberty's torch. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
Dan Winship wrote: Could we just package up the results of the jhbuild in a dumb, completely mechanical way, such that installing the packages would be exactly equivalent to running jhbuild? ie, it wouldn't replace or conflict with your existing GNOME packages, it would just install everything into its own special prefix. And we could have a single less-dumb package that tweaked your vendor gdm configuration to add a jhbuild gnome session. Are you suggesting to package the entire build as a single package, or separate packages for each module? In the latter case, you'd need to know about some post-install commands to run after install (e.g. registering gconf schemas, rebuilding icon caches, etc). It might be an issue for former case too. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On 7/19/05, Jeff Waugh [EMAIL PROTECTED] wrote: quote who=Luis Villa shrug If we're going to throw massive tarballs over the wall, might as well add the extra few megs and just make them debug from the start, no? Luis (noting that he has no idea if this would actually *work*) This has been done a few times in the history of GARNOME. It works fine, tho it's easier to build blobs for particular distros than attempt to ship just one blob. We go to far up and down the stack now to do that. :-) Yeah, figured it would have to be per-distro*. With a little help from vmware or something along those lines that should be too hard to automate. Luis * I'm still a monkey at heart; the solution is *always* to build per distro. ;) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
quote who=Luis Villa Yeah, figured it would have to be per-distro*. With a little help from vmware or something along those lines that should be too hard to automate. That'll be slow. Use a chroot. :-) - Jeff -- OSCON 2005: August 1st-5th http://conferences.oreillynet.com/os2005/ All this self-centred cock-handling is totally where it's at. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On 7/19/05, Dan Winship [EMAIL PROTECTED] wrote: On Tue, 2005-07-19 at 11:31 -0400, Luis Villa wrote: On 7/19/05, Alexander Larsson [EMAIL PROTECTED] wrote: The naming of the packages could also be such that there is no chance of conflicting with your vendor gnome, current version or later installed. I think Dan was suggesting (and certainly it is easier to produce) something that isn't a package at all, just a tarball of binaries and magic files, built into /opt/. Real packages have a few benefits: * Can be installed with tools that the user is more likely to be familiar with (and in particular, can be easily installed with GUI tools on many distros) * Easy to remove, easy to upgrade without worrying about there being cruft left behind But they don't need to be good packages in terms of integrating with the rest of the distro. These are the sort of packages that can be produced in 10 seconds given a tarball and a perl script. oh, oh. hadn't thought of that. Hrm, yeah, probably doable. [Note that if done well, I don't actually think distributing packages that conflict with your vendor GNOME is a problem, given proper warning labels all over the place.] That requires more distro-specific smarts though, Oh, of course. That's why this task drove Jacob insane. :) Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Tue, 2005-07-19 at 12:01 -0400, Luis Villa wrote: On 7/19/05, Dan Winship [EMAIL PROTECTED] wrote: On Tue, 2005-07-19 at 11:31 -0400, Luis Villa wrote: On 7/19/05, Alexander Larsson [EMAIL PROTECTED] wrote: The naming of the packages could also be such that there is no chance of conflicting with your vendor gnome, current version or later installed. I think Dan was suggesting (and certainly it is easier to produce) something that isn't a package at all, just a tarball of binaries and magic files, built into /opt/. Real packages have a few benefits: * Can be installed with tools that the user is more likely to be familiar with (and in particular, can be easily installed with GUI tools on many distros) * Easy to remove, easy to upgrade without worrying about there being cruft left behind But they don't need to be good packages in terms of integrating with the rest of the distro. These are the sort of packages that can be produced in 10 seconds given a tarball and a perl script. oh, oh. hadn't thought of that. Hrm, yeah, probably doable. I have a patch against JHBuild that will create packages of GNOME. It's by no means perfect and isn't even complete yet, but it's getting there. I mentioned it earlier in this thread: http://mail.gnome.org/archives/desktop-devel-list/2005- July/msg00398.html I've only tried creating the packages on FC4, but the patch should work just as well on other distros and could be easily modified to work on non-RPM based distros. The resulting packages all install (there were a few hickups, but nothing serious). The Gnome that results from installing these packages however is not runnable. This is likely due to the things that James mentioned in another mail: http://mail.gnome.org/archives/desktop-devel-list/2005- July/msg00424.html I would very much like to get this to the point where it can actually produce installable packages of all of GNOME (or essentially anything that is built with JHBuild). The packages which are currently being produced install to /opt/gnome2 and have names that won't conflict with any distribution-supplied names (ie glib2-jhbuild, evolution-jhbuild, etc.) Naming them this way means that getting rid of them all should be as simple as 'rpm -qa | grep jhbuid | xargs rpm -e'. The version number is just the date that they were built. There is also dependency information that I am generating from the module set. So, the gtk+- jhbuild package depends on the glib2-jhbuild package, etc. Oh, and there are no *-devel packages or anything, everything that a module installs gets packaged together. There would probably need to be one more package which does the post-install things that James mentions, installs a .jhbuildrc file somewhere, installs a GDM session file, etc. I'll try to spend some time this week and see if I can get this thing to a point where it is useful. --Mark. [Note that if done well, I don't actually think distributing packages that conflict with your vendor GNOME is a problem, given proper warning labels all over the place.] That requires more distro-specific smarts though, Oh, of course. That's why this task drove Jacob insane. :) Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On 7/18/05, Elijah Newren [EMAIL PROTECTED] wrote: On 7/18/05, Luis Villa [EMAIL PROTECTED] wrote: P.S. It was suggested that I should 'make distcheck' in tinderbox. Opinions? Luis is cool for doing all this tinderbox work. Heh. Thank James mostly; he wrote the code and I'm just whining obsessively. Sane? Insane? Does it matter? I think it'd be useful, though I'm betting libwnck fails and I'll be unable to fix it (I wasn't able to last time I tried, but thankfully people smarter than I are handling the releases...) Let me ask the question in a more detailed fashion: * would it be useful? It was suggested to me that it would make snapshotting easier (since things would be basically guaranteed to build in a packagable fashion), but are there reasons past that? * would it be feasible? I'm not going to test something if it is (1) likely to be broken 90% of the time and (2) james and thomas are the only people with enough skills to fix the problems. Nor does forcing all maintainers to learn more auto* seem like a reasonable use of anyone's time. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 2005-07-18 at 13:03 -0400, Luis Villa wrote: On 7/18/05, Elijah Newren [EMAIL PROTECTED] wrote: On 7/18/05, Luis Villa [EMAIL PROTECTED] wrote: P.S. It was suggested that I should 'make distcheck' in tinderbox. Opinions? Luis is cool for doing all this tinderbox work. Heh. Thank James mostly; he wrote the code and I'm just whining obsessively. Sane? Insane? Does it matter? I think it'd be useful, though I'm betting libwnck fails and I'll be unable to fix it (I wasn't able to last time I tried, but thankfully people smarter than I are handling the releases...) Let me ask the question in a more detailed fashion: * would it be useful? It was suggested to me that it would make snapshotting easier (since things would be basically guaranteed to build in a packagable fashion), but are there reasons past that? * would it be feasible? I'm not going to test something if it is (1) likely to be broken 90% of the time and (2) james and thomas are the only people with enough skills to fix the problems. Nor does forcing all maintainers to learn more auto* seem like a reasonable use of anyone's time. It would certainly make tinderbox builds much slower, since e.g. distchecking gtk requires building the docs. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On 7/18/05, Matthias Clasen [EMAIL PROTECTED] wrote: On Mon, 2005-07-18 at 13:03 -0400, Luis Villa wrote: On 7/18/05, Elijah Newren [EMAIL PROTECTED] wrote: On 7/18/05, Luis Villa [EMAIL PROTECTED] wrote: P.S. It was suggested that I should 'make distcheck' in tinderbox. Opinions? Luis is cool for doing all this tinderbox work. Heh. Thank James mostly; he wrote the code and I'm just whining obsessively. Sane? Insane? Does it matter? I think it'd be useful, though I'm betting libwnck fails and I'll be unable to fix it (I wasn't able to last time I tried, but thankfully people smarter than I are handling the releases...) Let me ask the question in a more detailed fashion: * would it be useful? It was suggested to me that it would make snapshotting easier (since things would be basically guaranteed to build in a packagable fashion), but are there reasons past that? * would it be feasible? I'm not going to test something if it is (1) likely to be broken 90% of the time and (2) james and thomas are the only people with enough skills to fix the problems. Nor does forcing all maintainers to learn more auto* seem like a reasonable use of anyone's time. It would certainly make tinderbox builds much slower, since e.g. distchecking gtk requires building the docs. I'm assuming that if I keep pushing this and making it more useful someone is going to eventually give me/gnome a faster box to do it on. :) (and then we get into the fun world of -j ;) Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 2005-07-18 at 13:28 -0400, Luis Villa wrote: I think the advantages of adding make distcheck are bigger than the disadvantages. OK, but what are they? :) Making sure people doing anonymous cvs checkouts will at any time be able to build the package they co, not running in major autotool problems just before a release tarball should be made,... Ikke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 2005-07-18 at 15:22 -0400, Luis Villa wrote: On 7/18/05, Behdad Esfahbod [EMAIL PROTECTED] wrote: On Mon, 18 Jul 2005, Luis Villa wrote: build/distribute daily snapshots like we used to. Not sure if that is worth the admitted pain of nagging/etc., especially since ATM no one is offering to build daily snaps. I'm willing to do daily tinderbox builds with distcheck and all, as soon as you check in your hacks (in jhbuild, right?) and I don't get a notice from the maintainers of facilities I'll be using. We're not lacking people doing tinderboxing.[1] The thing we're really missing (which has always been more important than tinderboxing, IMHO) is for someone to build daily rpms and debs for popular distributions, so that 'average' users can use rug, yum, or apt to run CVS HEAD every day. What's so difficult about jhbuild? Couldn't we make just make it easier (such as having jhbuild autodetect stuff in /usr and adjust PKG_CONFIG_PATH)? signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 18 Jul 2005, Luis Villa wrote: We're not lacking people doing tinderboxing.[1] The thing we're really missing (which has always been more important than tinderboxing, IMHO) is for someone to build daily rpms and debs for popular distributions, so that 'average' users can use rug, yum, or apt to run CVS HEAD every day. One way to go about is to require all involved modules to have an RPM .spec file, and jhbuild can be instructed to build and install RPMs, but most probably this will not be accepted practice in GNOME. Or am I wrong? Luis [1] Though ATM it is just me, and doing it on other platforms (solaris, bsd, gcc4, -j 1) would be great. --behdad http://behdad.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 2005-07-18 at 15:22 -0400, Luis Villa wrote: We're not lacking people doing tinderboxing.[1] The thing we're really missing (which has always been more important than tinderboxing, IMHO) is for someone to build daily rpms and debs for popular distributions, so that 'average' users can use rug, yum, or apt to run CVS HEAD every day. It's also quite difficult, because you have to deal with all the postinst stuff which may change without warning. And how to deal with that varies between packages. Oh, and it's worthless unless someone's tinderboxing too :) Because if they're not, the build is guaranteed to fail. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 18 Jul 2005, Ikke wrote: Date: Mon, 18 Jul 2005 21:42:09 +0200 From: Ikke [EMAIL PROTECTED] To: Behdad Esfahbod [EMAIL PROTECTED] Cc: Luis Villa [EMAIL PROTECTED], desktop-devel-list@gnome.org Subject: Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi] On Mon, 2005-07-18 at 15:29 -0400, Behdad Esfahbod wrote: One way to go about is to require all involved modules to have an RPM .spec file, and jhbuild can be instructed to build and install RPMs, but most probably this will not be accepted practice in GNOME. Or am I wrong? Seriously, then I want ebuilds provided for every package too. Nah, just kidding. Personally I don't think this is a good idea, as it would give one distribution a higher state than others, which is not what we want (I guess?) Supporting Autopackage wouldn't adversely affect or favour any particularly distribution and it would in fact produce packages widely usable by a whole variety of distributions. There is no Autopackage based distribution yet (nor is there likely to be). I think there is some benefit to having developers in control of their packages because they sure aren't going to want to have to maintain mulitple different RPMs and they would insist on a greater level of compatibility from RPM bases distributions. A Gnome LiveCD full of Autopackages could be very interesting. (but this is all theoretical and it would require developers to create the necessary autopackage specifications which mostly do not exist yet so I'll say no more) Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On 7/18/05, Behdad Esfahbod [EMAIL PROTECTED] wrote: On Mon, 18 Jul 2005, Luis Villa wrote: build/distribute daily snapshots like we used to. Not sure if that is worth the admitted pain of nagging/etc., especially since ATM no one is offering to build daily snaps. I'm willing to do daily tinderbox builds with distcheck and all, as soon as you check in your hacks (in jhbuild, right?) and I don't get a notice from the maintainers of facilities I'll be using. We're not lacking people doing tinderboxing.[1] The thing we're really missing (which has always been more important than tinderboxing, IMHO) is for someone to build daily rpms and debs for popular distributions, so that 'average' users can use rug, yum, or apt to run CVS HEAD every day. Luis [1] Though ATM it is just me, and doing it on other platforms (solaris, bsd, gcc4, -j 1) would be great. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 2005-07-18 at 13:41 -0400, Matthias Clasen wrote: I think the advantages of adding make distcheck are bigger than the disadvantages. In the end, being able to do make a tinderbox with make distcheck and CFLAGS+=-Wall -Werror -pedantic -ansi would be so cool ;-) -Wall -ansi -pedantic -Werror is not going to fly. See e.g. http://bugzilla.gnome.org/show_bug.cgi?id=310175 Then we got some work to do ;-) IMHO these CFLAGS force devs to write cleaner (and sometimes even more secure) code, which is a good thing :-) Ikke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On 7/18/05, Andrew Sobala [EMAIL PROTECTED] wrote: On Mon, 2005-07-18 at 15:54 -0400, Colin Walters wrote: On Mon, 2005-07-18 at 15:22 -0400, Luis Villa wrote: On 7/18/05, Behdad Esfahbod [EMAIL PROTECTED] wrote: On Mon, 18 Jul 2005, Luis Villa wrote: build/distribute daily snapshots like we used to. Not sure if that is worth the admitted pain of nagging/etc., especially since ATM no one is offering to build daily snaps. I'm willing to do daily tinderbox builds with distcheck and all, as soon as you check in your hacks (in jhbuild, right?) and I don't get a notice from the maintainers of facilities I'll be using. We're not lacking people doing tinderboxing.[1] The thing we're really missing (which has always been more important than tinderboxing, IMHO) is for someone to build daily rpms and debs for popular distributions, so that 'average' users can use rug, yum, or apt to run CVS HEAD every day. What's so difficult about jhbuild? Couldn't we make just make it easier (such as having jhbuild autodetect stuff in /usr and adjust PKG_CONFIG_PATH)? Processing power. Time. Also... HD space. (my jhbuild root takes up roughly as much space as all the rest of my OS combined.) Detection/installation of dependencies. Having to use 'cvs up' to find out if there are new modules. Installation of the correct .desktop files for gdm and sessions. Regular problems with builds that fail from 'make clean.' Finally, distinct evidence that we had way more HEAD users when we packaged things than now, when we don't. :) Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
Dnia 18-07-2005, pon o godzinie 13:28 -0400, Luis Villa napisał: In the end, being able to do make a tinderbox with make distcheck and CFLAGS+=-Wall -Werror -pedantic -ansi would be so cool ;-) Would definitely love to have a 'secondary' tinderbox run with pedantic/wall/werror turned on so that those are so inclined can chase those things down. I thought -ansi -pedantic was synonymous to -useless? Cheers, Maciej -- Being really good at C++ is like being really good at using rocks to sharpen sticks. (Thant Tessman) Maciej Katafiasz [EMAIL PROTECTED] http://mathrick.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
Alan Horkan wrote: Supporting Autopackage wouldn't adversely affect or favour any particularly distribution and it would in fact produce packages widely usable by a whole variety of distributions. There is no Autopackage based distribution yet (nor is there likely to be). Note that autopackage is just another package management system. Yup The only reason that it doesn't favour any particular distro is that no one uses it, as opposed to other package management systems. Yeah, I suppose I should have added a smiley face to that :) I think there is some benefit to having developers in control of their packages because they sure aren't going to want to have to maintain mulitple different RPMs and they would insist on a greater level of compatibility from RPM bases distributions. The issue of distribution differences is not related to use of RPM. If you want to integrate well with the underlying OS, you'll probably need some distro specific changes. True but I think developers would be a lot more reticent in making any changes they could possibly avoid. There are issues where distros have used different package naming, which would've been nice to avoid, but that is certainly not the only issue. These things are always more complicated than they look. A Gnome LiveCD full of Autopackages could be very interesting. For a live CD, the package management system is not really that interesting. The software is all installed on the system image you boot into. I was thinking you'd try Gnome and then upgrade your computer from the same LiveCD but I suppose now that i think about it further you would have to include everthing twice to allow for that. - Alan H. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On 7/18/05, Ikke [EMAIL PROTECTED] wrote: On Mon, 2005-07-18 at 15:29 -0400, Behdad Esfahbod wrote: One way to go about is to require all involved modules to have an RPM .spec file, and jhbuild can be instructed to build and install RPMs, but most probably this will not be accepted practice in GNOME. Or am I wrong? Seriously, then I want ebuilds provided for every package too. Nah, just kidding. Personally I don't think this is a good idea, as it would give one distribution a higher state than others, which is not what we want (I guess?) We want more testing. If that means accepting that some distros are used more than others, then so be it. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
Behdad Esfahbod wrote: One way to go about is to require all involved modules to have an RPM .spec file, and jhbuild can be instructed to build and install RPMs, but most probably this will not be accepted practice in GNOME. Or am I wrong? This is not practical, especially with so many incompatible RPM distributions out there. Plus the distros would just have to throw the spec files in the trash and use their own anyway. Plus there's debian-based distributions. Ubuntu unstable has unstable gnome versions, incidentally, though they're not build nightly as that would be painful for everyone involved (imagine having to pull many megs of updates every day). It'd be really nice if RPMs and DEBs had a way of supporting patching existing installs without downloading whole new packages. -Rob ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On 7/18/05, Rob Adams [EMAIL PROTECTED] wrote: Behdad Esfahbod wrote: One way to go about is to require all involved modules to have an RPM .spec file, and jhbuild can be instructed to build and install RPMs, but most probably this will not be accepted practice in GNOME. Or am I wrong? This is not practical, especially with so many incompatible RPM distributions out there. Plus the distros would just have to throw the spec files in the trash and use their own anyway. Plus there's debian-based distributions. Ubuntu unstable has unstable gnome versions, incidentally, though they're not build nightly True so far. :) as that would be painful for everyone involved (imagine having to pull many megs of updates every day). We did it before 2.0, and on a typical day had several thousand downloads of the complete gnome stack every day. The resulting depth and breadth of testing is something we've been missing ever since it stopped. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On 7/18/05, Matthias Clasen [EMAIL PROTECTED] wrote: On Mon, 2005-07-18 at 20:23 +0200, Ikke wrote: On Mon, 2005-07-18 at 13:28 -0400, Luis Villa wrote: I think the advantages of adding make distcheck are bigger than the disadvantages. OK, but what are they? :) Making sure people doing anonymous cvs checkouts will at any time be able to build the package they co, not running in major autotool problems just before a release tarball should be made,... I think that ensuring that make distcheck works at release time is the maintainers responsibility. It is only important that it works at the time the release is made. While I generally agree, I think there is some value in being able to build tarballs and hence easily build packages between releases- I feel strongly we'd have a more stable project if we could easily build/distribute daily snapshots like we used to. Not sure if that is worth the admitted pain of nagging/etc., especially since ATM no one is offering to build daily snaps. There is little value in being pestered about every time a checkin temporarily breaks make distcheck, e.g. because a new symbol was added without adding it to gtk.symbols. FWIW, note that in this particular example, the test occurs in make check, which I have gotten the impression most people feel should pass constantly- but maybe I'm wrong here? Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
Colin Walters wrote: What's so difficult about jhbuild? Couldn't we make just make it easier (such as having jhbuild autodetect stuff in /usr and adjust PKG_CONFIG_PATH)? jhbuild is pretty damned difficult. Whenever I want to get a jhbuild going on a machine it invariably requires about a day of troubleshooting various problems, expecially on amd64. It requires installing like 5 different versions of automake. There's a point where you have to go into the installed version of a package and symlink a directory down to itself because of a problem with make install, then run the installer again. There's the perennial *win32*.h thing with libxslt where you get merge conflicts on every other update. And of course, often it doesn't build at all. -Rob ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 2005-07-18 at 20:24 +0200, Ikke wrote: On Mon, 2005-07-18 at 13:41 -0400, Matthias Clasen wrote: I think the advantages of adding make distcheck are bigger than the disadvantages. In the end, being able to do make a tinderbox with make distcheck and CFLAGS+=-Wall -Werror -pedantic -ansi would be so cool ;-) -Wall -ansi -pedantic -Werror is not going to fly. See e.g. http://bugzilla.gnome.org/show_bug.cgi?id=310175 Then we got some work to do ;-) IMHO these CFLAGS force devs to write cleaner (and sometimes even more secure) code, which is a good thing :-) You didn't even read that bug report, obviously! But beyond that '-ansi -pedantic' have a really wrong meaning. They mean, to both GCC and the compiler: Turn off all extensions beyond the C89 standard GLib has a lot of intelligence to detect and use features and extensions when available and to replace them when not available. GCC suddenly claiming it doesn't know about extensions that it *does* know about will, not surprisingly, cause things to break. Sometimes you can hack around this, but it's generally just stupid to waste time doing so. Regards, Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 2005-07-18 at 15:22 -0400, Luis Villa wrote: On 7/18/05, Behdad Esfahbod [EMAIL PROTECTED] wrote: On Mon, 18 Jul 2005, Luis Villa wrote: build/distribute daily snapshots like we used to. Not sure if that is worth the admitted pain of nagging/etc., especially since ATM no one is offering to build daily snaps. I'm willing to do daily tinderbox builds with distcheck and all, as soon as you check in your hacks (in jhbuild, right?) and I don't get a notice from the maintainers of facilities I'll be using. We're not lacking people doing tinderboxing. The thing we're really missing (which has always been more important than tinderboxing, IMHO) is for someone to build daily rpms and debs for popular distributions, so that 'average' users can use rug, yum, or apt to run CVS HEAD every day. Luis I spent some time trying to make this happen a few weeks back. I basically started hacking into jhbuild and ended up with something that could create RPMs of the whole gnome stack and the RPMs were mostly installable (some packages claiming the same file, maybe some help index file). However, starting the gnome that resulted from the RPMs was not as successful. I basically ran 'make install DESTDIR=some_temp_folder', scanned the temp_folder getting a list of all of the files that were installed, created a spec file from that and built the package. I also generated dependencies based on the module's requirements in the module set. The packages weren't of high quality as far as packages go, but they would install all of the files. I'm still not terribly sure why this didn't work out. There has to be some fundamental thing that I'm missing. -- Mark Drago signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 2005-07-18 at 13:15 -0400, Matthias Clasen wrote: On Mon, 2005-07-18 at 13:03 -0400, Luis Villa wrote: On 7/18/05, Elijah Newren [EMAIL PROTECTED] wrote: On 7/18/05, Luis Villa [EMAIL PROTECTED] wrote: P.S. It was suggested that I should 'make distcheck' in tinderbox. Opinions? Luis is cool for doing all this tinderbox work. Heh. Thank James mostly; he wrote the code and I'm just whining obsessively. Sane? Insane? Does it matter? I think it'd be useful, though I'm betting libwnck fails and I'll be unable to fix it (I wasn't able to last time I tried, but thankfully people smarter than I are handling the releases...) Let me ask the question in a more detailed fashion: * would it be useful? It was suggested to me that it would make snapshotting easier (since things would be basically guaranteed to build in a packagable fashion), but are there reasons past that? * would it be feasible? I'm not going to test something if it is (1) likely to be broken 90% of the time and (2) james and thomas are the only people with enough skills to fix the problems. Nor does forcing all maintainers to learn more auto* seem like a reasonable use of anyone's time. It would certainly make tinderbox builds much slower, since e.g. distchecking gtk requires building the docs. Matthias I think the advantages of adding make distcheck are bigger than the disadvantages. In the end, being able to do make a tinderbox with make distcheck and CFLAGS+=-Wall -Werror -pedantic -ansi would be so cool ;-) Ikke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On 7/18/05, Ikke [EMAIL PROTECTED] wrote: On Mon, 2005-07-18 at 13:15 -0400, Matthias Clasen wrote: On Mon, 2005-07-18 at 13:03 -0400, Luis Villa wrote: On 7/18/05, Elijah Newren [EMAIL PROTECTED] wrote: On 7/18/05, Luis Villa [EMAIL PROTECTED] wrote: P.S. It was suggested that I should 'make distcheck' in tinderbox. Opinions? Luis is cool for doing all this tinderbox work. Heh. Thank James mostly; he wrote the code and I'm just whining obsessively. Sane? Insane? Does it matter? I think it'd be useful, though I'm betting libwnck fails and I'll be unable to fix it (I wasn't able to last time I tried, but thankfully people smarter than I are handling the releases...) Let me ask the question in a more detailed fashion: * would it be useful? It was suggested to me that it would make snapshotting easier (since things would be basically guaranteed to build in a packagable fashion), but are there reasons past that? * would it be feasible? I'm not going to test something if it is (1) likely to be broken 90% of the time and (2) james and thomas are the only people with enough skills to fix the problems. Nor does forcing all maintainers to learn more auto* seem like a reasonable use of anyone's time. It would certainly make tinderbox builds much slower, since e.g. distchecking gtk requires building the docs. Matthias I think the advantages of adding make distcheck are bigger than the disadvantages. OK, but what are they? :) In the end, being able to do make a tinderbox with make distcheck and CFLAGS+=-Wall -Werror -pedantic -ansi would be so cool ;-) Would definitely love to have a 'secondary' tinderbox run with pedantic/wall/werror turned on so that those are so inclined can chase those things down. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
You didn't even read that bug report, obviously! Actually, I did read it, which does not imply I agree with the final conclusion. But beyond that '-ansi -pedantic' have a really wrong meaning. They mean, to both GCC and the compiler: Turn off all extensions beyond the C89 standard Which implies the code will compile with almost C every compiler around. I'm not saying these flags should be used in release builds... GLib has a lot of intelligence to detect and use features and extensions when available and to replace them when not available. GCC suddenly claiming it doesn't know about extensions that it *does* know about will, not surprisingly, cause things to break. Of course you should be using C99 and other extensions when the target host supports these. But this doesn't take away the fact the code should also compile on hosts that do not support these extensions. I guess nowadays all tinderbox builds are done on GCC 3.3/3.4/4.0 platforms? Sometimes you can hack around this, but it's generally just stupid to waste time doing so. I'll STFU in this discussion from now on, appareantly I haven't got the knowledge or I'm not in the correct position to spread around my thoughts. G'night, Ikke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 2005-07-18 at 19:24 +0200, Ikke wrote: I think the advantages of adding make distcheck are bigger than the disadvantages. In the end, being able to do make a tinderbox with make distcheck and CFLAGS+=-Wall -Werror -pedantic -ansi would be so cool ;-) -Wall -ansi -pedantic -Werror is not going to fly. See e.g. http://bugzilla.gnome.org/show_bug.cgi?id=310175 Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 2005-07-18 at 15:13 -0400, Behdad Esfahbod wrote: On Mon, 18 Jul 2005, Luis Villa wrote: build/distribute daily snapshots like we used to. Not sure if that is worth the admitted pain of nagging/etc., especially since ATM no one is offering to build daily snaps. I'm willing to do daily tinderbox builds with distcheck and all, as soon as you check in your hacks (in jhbuild, right?) and I don't get a notice from the maintainers of facilities I'll be using. behdad You might want a separate list to send failure notices too, because lots of them will happen, especially in the beginning. desktop-devel would be flooded I think. Ikke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
