[gentoo-dev] Re: The importance of test suites
On Sun, 21 Feb 2010 10:11:25 +0100
"Paweł Hajdan, Jr." wrote:
> On 2/21/10 5:08 AM, Ryan Hill wrote:
> > I have one simple request. When you make a non-trivial change to an ebuild
> > -
> > a patch, a version bump, anything that can effect the behaviour of the
> > package - please run the test suite.
>
> Yeah, on my dev box I just run with FEATURES="test" all the time. Then
> it's impossible to forget it. And I also catch failures in other packages.
>
> Maybe it should get more exposure in the developer docs?
It's enabled by default in the developer profiles, so either devs aren't using
them or they're explicitly disabling it.
> By the way, for packages that fail the test suite and refuse to disable
> it, I change the env locally so that FEATURES=-test (via /etc/portage/env).
I used to do exactly that but it has a big disadvantage. There are
particular packages where I want to disable the test USE flag simply because
it pulls in a ton of unwanted dependencies. This can't be done with env
files; it's force {en,dis}abled by the global FEATURES setting (even
package.use doesn't override it).
Luckily, you can kill two birds with one stone by using a little trick buried
deep in the make.conf manpage: masking the test USE flag for a particular
package disables the test suite /even if that package doesn't have a test USE
flag/.
$ head -n5 /etc/portage/profile/package.use.mask
dev-db/virtuoso-server test
dev-java/commons-clitest
dev-libs/boost test
dev-libs/ppltest
dev-util/subversion test
--
fonts,by design, by neglect
gcc-porting, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
Re: [gentoo-dev] upcoming problem? new-style virtuals and USE deps
On 02/22/2010 10:46 AM, Robin H. Johnson wrote: > So I've started to see the proliferation of manual || structures for USE deps, > where virtuals would normally be used, but it seems that either USE deps from > the virtuals aren't propogated down to the packages themselves, or developers > aren't aware of said propagation. > > DEPEND="... > || ( > >=dev-db/mysql-5.0.76-r1[embedded?,-minimal] > >=dev-db/mysql-community-5.0.77-r1[embedded?,-minimal] > ) > ..." > > dev-db/mysql-community will be dropped later this year, however before then > there will be 3 other variants added, all of which need to go into > virtual/mysql: > dev-db/mysql-cluster > dev-db/mariadb > dev-db/mysql-ourdelta > > Suggestions on the actual problem source, and potential solutions welcome? There was a bug in
[gentoo-dev] upcoming problem? new-style virtuals and USE deps
So I've started to see the proliferation of manual || structures for USE deps, where virtuals would normally be used, but it seems that either USE deps from the virtuals aren't propogated down to the packages themselves, or developers aren't aware of said propagation. DEPEND="... || ( >=dev-db/mysql-5.0.76-r1[embedded?,-minimal] >=dev-db/mysql-community-5.0.77-r1[embedded?,-minimal] ) ..." dev-db/mysql-community will be dropped later this year, however before then there will be 3 other variants added, all of which need to go into virtual/mysql: dev-db/mysql-cluster dev-db/mariadb dev-db/mysql-ourdelta Suggestions on the actual problem source, and potential solutions welcome? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] The importance of test suites
On 2/22/10 2:01 PM, Gilles Dartiguelongue wrote: > Le dimanche 21 février 2010 à 10:53 +0100, "Paweł Hajdan, Jr." a écrit : >> $ tree /etc/portage/env >> /etc/portage/env >> |-- app-portage >> | `-- portage-utils.env >> |-- dev-libs >> | |-- boost.env >> | `-- libevent.env >> |-- dev-python >> | `-- pygtk.env > > pygtk should succeed, it does or did last time I touched it. Please > report. Still fails for me (https://bugs.gentoo.org/245103). Please note I'm running x86, so this is with dev-python/pygtk-2.14.1-r1 and not the latest version). >> |-- dev-scheme >> | `-- guile.env >> `-- sys-devel >> |-- binutils.env >> `-- libtool.env > > libtool was fixed by diego a couple of weeks ago, it's probably not > needed anymore. This still fails for me on x86 stable, https://bugs.gentoo.org/293758. Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] New eclass for x11 packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dne 22.2.2010 16:50, Michael Haubenwallner napsal(a):
>
>
> Tomáš Chvátal wrote:
>> Dne 22.2.2010 11:50, Michael Haubenwallner napsal(a):
>>> PS: Just a suggestion what an ebuild could do in this case:
>>> src_prepare() {
>>> xorg-2_src_prepare --force-eautoreconf
>>> }
>> SNAPSHOT="yes" xorg-2_src_prepare
>>
>> ^ this does not fit your needs? It does exactly what you want :]
>
> Uhh, this doesn't look like the "clean" way and depends on
> exakt knowledge how xorg-2_src_prepare works - shouldn't
> eclasses provide something like an "intuitive API" to some
> degree, especially if they are "new"?
>
> However - I'll continue looking into the eclass impl details...
>
> /haubi/
I was just asking, not implying that it is best solution :]
Feel free to provide some patches to make it more intuitive, i am too
busy this week and i wont probably do any gentoo work expect applying
submitted patches :]
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuCqUwACgkQHB6c3gNBRYc2LACghRaSmPl+kccp/DHNPBa3Q6v6
xnEAoLoM0EmpUIS2ZF8CISVPLOuFmWRD
=wx2f
-END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New eclass for x11 packages
Tomáš Chvátal wrote:
> Dne 22.2.2010 11:50, Michael Haubenwallner napsal(a):
>> PS: Just a suggestion what an ebuild could do in this case:
>> src_prepare() {
>> xorg-2_src_prepare --force-eautoreconf
>> }
> SNAPSHOT="yes" xorg-2_src_prepare
>
> ^ this does not fit your needs? It does exactly what you want :]
Uhh, this doesn't look like the "clean" way and depends on
exakt knowledge how xorg-2_src_prepare works - shouldn't
eclasses provide something like an "intuitive API" to some
degree, especially if they are "new"?
However - I'll continue looking into the eclass impl details...
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
Re: [gentoo-dev] Pending mask of Qt3 and MythTV
On 02/22/2010 12:25 AM, Ben de Groot wrote: If no action is taken soon, we see no other way than to protect the users by masking the complete mythtv package. We hope this won't be necessary. Agreed none of the options are nice. The mythtv wiki isn't a bad resource, how about this for a news item (I can commit if there are no objections - and be gentle as I just parsed the GLEP - also posted to the bug 299222): Title: MythTV 0.22 Upgrade Database Corruption Author: Richard Freeman Content-Type: text/plain Posted: Revision: 1 News-Item-Format: 1.0 Display-If-Installed: Due to an incompatibility between MythTV 0.21 and the default Gentoo MySQL configuration, it is likely that long-time MythTV users will have databases with a mixture of locale encodings. If you upgrade to 0.22 without following these directions carefully, you could end up with a database that contains errors that are extremely difficult to fix. Please see the MythTV Upgrade Guide for instructions: http://wiki.mythtv.org/wiki/Fixing_Corrupt_Database_Encoding Be sure to save a database backup before upgrading. Also, be sure to upgrade any other clients/backends you are using to 0.22 at the same time. The upgrade instructions need to be followed once per database - individual client/backend upgrades do not require these steps.
Re: [gentoo-dev] [RFC] New eclass for x11 packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dne 22.2.2010 11:50, Michael Haubenwallner napsal(a):
>
> PS: Just a suggestion what an ebuild could do in this case:
> src_prepare() {
> xorg-2_src_prepare --force-eautoreconf
> }
SNAPSHOT="yes" xorg-2_src_prepare
^ this does not fit your needs? It does exactly what you want :]
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuCksgACgkQHB6c3gNBRYdg1gCgt5MdaHdYiwrNQp8RlXAStjRt
9EQAn3ds4jUA+9iT0zm8FFBgbQa2n6d5
=5ret
-END PGP SIGNATURE-
Re: [gentoo-dev] The importance of test suites
Le dimanche 21 février 2010 à 10:53 +0100, "Paweł Hajdan, Jr." a écrit : > On 2/21/10 10:40 AM, Thilo Bangert wrote: > > "Paweł Hajdan, Jr." said: > >> By the way, for packages that fail the test suite and refuse to disable > >> it, I change the env locally so that FEATURES=-test (via > >> /etc/portage/env). > > > > how many packages do you have in there? i usually just do it manually, so > > i dont have easily available stats on how many packages are affected. > > I don't have a lot: > > $ tree /etc/portage/env > /etc/portage/env > |-- app-portage > | `-- portage-utils.env > |-- dev-libs > | |-- boost.env > | `-- libevent.env > |-- dev-python > | `-- pygtk.env pygtk should succeed, it does or did last time I touched it. Please report. > |-- dev-scheme > | `-- guile.env > `-- sys-devel > |-- binutils.env > `-- libtool.env libtool was fixed by diego a couple of weeks ago, it's probably not needed anymore. -- Gilles Dartiguelongue Gentoo
Re: [gentoo-dev] The importance of test suites
On 2/21/10 10:11 AM, "Paweł Hajdan, Jr." wrote: > On 2/21/10 5:08 AM, Ryan Hill wrote: >> I have one simple request. When you make a non-trivial change to an ebuild - >> a patch, a version bump, anything that can effect the behaviour of the >> package - please run the test suite. > > Yeah, on my dev box I just run with FEATURES="test" all the time. Then > it's impossible to forget it. And I also catch failures in other packages. I just noticed that FEATURES="test" is enabled by default in the developer profile, with some other features that make portage more strict. It also looks like the developer profile is not mentioned in the developer docs. What would you think about better advocating usage of the developer profile among developers? Looks like many problems would disappear simply because the maintainer of a given package would hit the problem first (and fix it before it gets into portage). Paweł Hajdan jr signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] gentoo-news repository
> On Thu, 8 Oct 2009, Markos Chandras wrote: > On Thursday 08 October 2009 13:57:40 Alex Alexander wrote: >> On Thu, Oct 8, 2009 at 12:08, Ulrich Mueller wrote: >>> Some devs have complained about the directory structure in the >>> gentoo-news being too complicated. News item files are currently >>> found in a third-level subdirectory: >>>/MM/-MM-DD-itemname/ >>> On the rsync side the year and month subdirs are absent: >>>metadata/news/-MM-DD-itemname/ >>> After discussion with zmedico (who is maintaining the repo->rsync >>> script) I propose to remove the month subdirs at least, and >>> possibly also the year dirs. This change would be invisible to >>> users, who see only the rsync side. >>> Opinions? >> Sounds good, although it could get a bit crowded if we remove /, >> unless we remove really old items (like >= 2 years old). > Crowded? I don't think so :) > The number of news items is quite small, so I think we can afford > having them all in the same folder Coming back to this: Seems that there is consensus to remove the month subdirectories. So I have moved everything up by one directory level, news items now live in: /-MM-DD-itemname/ The rsync-gen.sh script has been updated by Zac who will also take care of GLEP 42. Ulrich
Re: [gentoo-dev] [RFC] New eclass for x11 packages
Tomáš Chvátal wrote:
> Hi,
> we prepared new eclass for x11 packages that should be used as
> replacement for x-modular.eclass.
> Prefix support done.
There's one thing I don't find addressed yet:
When some patch[1] necessary for some (prefix-) platform has to touch
configure.ac or Makefile.am, rendering eautoreconf mandatory on
*each* platform, there's no way to tell xorg-2_reconf_source() to
do the eautoreconf instead of elibtoolize *unconditionally*.
We had to have libXaw.ebuild do the eautoreconf unconditionally[2] after
x-modular_src_unpack() - which just did elibtoolize on some platforms,
causing elibtoolize to get run twice, resulting in bug#232820 [3].
Even if libXaw doesn't need those patches any more it seems,
there's no reason such patches won't become necessary again.
[1]
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/x11-libs/libXaw/files/libXaw-1.0.5-darwin.patch?rev=37037
[2]
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/x11-libs/libXaw/libXaw-1.0.6.ebuild?rev=49677#L43
[3] http://bugs.gentoo.org/show_bug.cgi?id=232820
/haubi/
PS: Just a suggestion what an ebuild could do in this case:
src_prepare() {
xorg-2_src_prepare --force-eautoreconf
}
--
Michael Haubenwallner
Gentoo on a different level
Re: [gentoo-dev] Build system output verbosity, e.g. cmake
Am Sonntag, den 21.02.2010, 19:36 +0100 schrieb Fabian Groffen: > Hi all, > > Inspired by the recent poppler move from autoconf to cmake for its > build system, the following. > > Given that poppler didn't compile on at least two arches, I found that > cmake is pretty much terse in its output, especially when errors are > encountered. Often it is important to know how the compiler or linker > was invoked, to be able to (quickly) resolve the issue at hand. Cmake > doesn't seem to report such call by default, it needs VERBOSE=1 to be > set in the environment in order to do so. > > I recently proposed to enable this by default for cmake, but got some > negative feedback for that. Hence, I'd like to know the opinion of more > people on the issue. > > In the past we have had verbose build systems, that printed a lot of > messages. Portage even analyses this output to look for common > problems. Newer buildsystems (like cmake), or just newer insights (like > gnustep makefiles, linux kernel, git, ...) suppress more messages > leading to reduced output. > > - should we leave defaults of build systems as is, keeping some very > verbose and others very terse? > - should we always enable verbosity such that we can analyse logs, both > by Portage as well as in bugs when something apparently went wrong? > - should make the output level consistent for all build systems? > > I think verbosity is useful when debugging problems. Portage's --jobs > feature nicely allows to hide the "ugly" output (even with --jobs=1), > still storing the log for when something goes wrong, while eliminating > the need to look at it all the time. > > So what do you think? Pros, cons? > Please always enable verbose (as in "show the actual gcc command line call") output unless a build system shows the complete call in case it failed. Being able to attach the build log without the need to first rerun the merge process with some flag set to get the full output is easier for the user and therefore a good thing. Leave the output mangling to the package manager. Cheers, Tiziano -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 smime.p7s Description: S/MIME cryptographic signature
