Re: [gentoo-dev] PyXML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 10.5.2011 23:21, Arfrever Frehtes Taifersar Arahesis napsal(a): PyXML is dead: http://mail.python.org/pipermail/xml-sig/2004-November/010735.html http://mail.python.org/pipermail/xml-sig/2006-June/011545.html PyXML provides _xmlplus module, which replaces xml module (from standard library) at run time, which might result in various problems. I'm planning to implement the following solution: - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of this function will be necessary to use replace xml module with _xmlplus module. Python =2.7.1-r2:2.7 will be added to the tree in next week and will be temporarily package.masked. Later this change will be backported to new versions in older slots. - All packages, which use PyXML, will have to be patched to call xml.use_pyxml(). The following code should be added before first import of anything from xml module: import xml if hasattr(xml, use_pyxml): xml.use_pyxml() This code works with previous versions of Python, so no changes in dependencies are needed. Apart from not being developed is PyXML actualy broken so we can't wait for upstream [1] to migrate their packages? I see just one open bug for it when I search bugzilla. [1] http://qa-reports.gentoo.org/output/genrdeps/rindex/dev-python/pyxml -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3KZToACgkQHB6c3gNBRYeNkwCghH3dd0WwCKDJ7ugyvQ5t+wUB BIoAmQGPiM2lnsas0xvhogC5vb2BqaD4 =T/Sq -END PGP SIGNATURE-
[gentoo-dev] About the Qt 4.7.3 bump
Why did the bump to Qt 4.7.3 happen? AFAIK, it only contains Symbian changes, and Gentoo does not run on the Symbian platform.
Re: [gentoo-dev] About the Qt 4.7.3 bump
On Wed, May 11, 2011 at 02:05:16PM +0300, Nikos Chantziaras wrote: Why did the bump to Qt 4.7.3 happen? AFAIK, it only contains Symbian changes, and Gentoo does not run on the Symbian platform. http://qt.nokia.com/developer/changes/changes-4.6.3/ -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgprTJ2v1dz6e.pgp Description: PGP signature
Re: [gentoo-dev] About the Qt 4.7.3 bump
On Wed, May 11, 2011 at 02:05:16PM +0300, Nikos Chantziaras wrote: Why did the bump to Qt 4.7.3 happen? AFAIK, it only contains Symbian changes, and Gentoo does not run on the Symbian platform. Sorry wrong link http://qt.nokia.com/developer/changes/changes-4.7.3/ No big changes but yet again is labeled as bug-fix release -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgp0oLjGj4u3Q.pgp Description: PGP signature
[gentoo-dev] Re: About the Qt 4.7.3 bump
On 05/11/2011 02:11 PM, Markos Chandras wrote: On Wed, May 11, 2011 at 02:05:16PM +0300, Nikos Chantziaras wrote: Why did the bump to Qt 4.7.3 happen? AFAIK, it only contains Symbian changes, and Gentoo does not run on the Symbian platform. Sorry wrong link http://qt.nokia.com/developer/changes/changes-4.7.3/ No big changes but yet again is labeled as bug-fix release Yep, only for Symbian though. We already had the SSL certificate patch in 4.7.2-r1. I actually didn't look at the changelog itself, but at the Git diffs instead, where I saw that there were zero changes for non-Symbian (except the SSL patch). But now that it's in, it's in I guess. Nothing we can do about it :-)
Re: [gentoo-dev] About the Qt 4.7.3 bump
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 11.5.2011 13:05, Nikos Chantziaras napsal(a): Why did the bump to Qt 4.7.3 happen? AFAIK, it only contains Symbian changes, and Gentoo does not run on the Symbian platform. With this approach you could ask why we bump each kde release. As most of the apps does not change at all. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3KgeUACgkQHB6c3gNBRYfOHwCgln+yfvb45Qp8Eap23xBEY6mc giUAoINsKTdRS2p57/Uq6QbviE0vda1l =LfVr -END PGP SIGNATURE-
[gentoo-dev] Re: About the Qt 4.7.3 bump
On 05/11/2011 03:32 PM, Tomáš Chvátal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 11.5.2011 13:05, Nikos Chantziaras napsal(a): Why did the bump to Qt 4.7.3 happen? AFAIK, it only contains Symbian changes, and Gentoo does not run on the Symbian platform. With this approach you could ask why we bump each kde release. As most of the apps does not change at all. I don't know :-P Avoiding needless bumps was, IIRC, one of the reasons Gentoo uses split ebuilds. Anyway, I mentioned this because in the past, at least one time, a version bump for Qt was omitted exactly because there were no changes.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/inspircd: inspircd-1.1.19.ebuild inspircd-1.1.23.ebuild
On 05/11/2011 07:39 AM, Samuli Suominen (ssuominen) wrote: ssuominen11/05/11 12:39:52 Removed: inspircd-1.1.19.ebuild inspircd-1.1.23.ebuild Log: drop 2 oldest, fails to build with gcc-4.4 and openssl-1 (Portage version: 2.2.0_alpha31/cvs/Linux x86_64) Please make updating the ChangeLog a part of your new workflow, http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html
Re: [gentoo-dev] Automatic testing on Gentoo
On 05/10/2011 01:13 PM, Jorge Manuel B. S. Vicetto wrote: Hi. Another issue that was raised in the discussion with the arch teams, even though it predates the arch teams resources thread as we've talked about it on FOSDEM 2011 and even before, is getting more automatic testing done on Gentoo. I'm bcc'ing a few teams on this thread as it involves them and hopefully might interest them as well. Both Release Engineering and QA teams would like to have more automatic testing to find breakages and to help track when things break and more importantly *why* they break. To avoid misunderstandings, we already have testing and even automated testing being done on Gentoo. The first line of testing is done by developers using repoman and or the PM's QA tools. We also have individual developers and the QA team hopefully checking commits and everyone testing their packages. Furtermore, the current weekly automatic stage building has helped identify some issues with the tree. The tinderbox work done by Patrick and Diego, as well as others, has also helped finding broken packages and or identifying packages affected by major changes before they hit the tree. The use of repoman, pcheck and or paludis quality assurance tools in the past and present to generate reports about tree issues, like Michael's (mr_bones) emails have also helped identifying and addressing issues. Recently, we've got a new site to check the results of some tests http://qa-reports.gentoo.org/ with the possibility to add more scripts to provide / run even more tests. So, why more testing? For starters, more *automatic* testing. Then more testing as reports from testing can help greatly in identifying when things break and why they break. As someone that looks over the automatic stage building for amd64 and x86, and that has to talk to teams / developers when things break, having more, more in depth and regular automatic testing would help my (releng) job. The work for the live-dvd would also be easier if the builds were automated and the job wasn't restarted every N months. Furthermore, creating a framework for developers to be able to schedule testing for proposed changes, in particular for substantial changes, might (should?) help improve the user's experience. I hope you agree with more testing by now, but what testing? It's good to test something, but what do we want to test and how do we want to test? I think we should try to have at least the following categories of tests: * Portage (overlays?) QA tests tests with the existing QA tools to check the consistency of dependencies and the quality of ebuilds / eclasses. * (on demand?) package (stable / unstable) revdep rebuild (tinderbox) framework to schedule testing of proposed changes and check their impact * Weekly (?) stable / unstable stage / ISO arch builds the automatic stage building, including new specs for the testing tree as we currently only test the stable tree. * (schedule?) specific tailored stage4 builds testing of specific tailored real world images (web server, intranet server, generic desktop, GNOME desktop, KDE desktop, etc). * Bi-Weekly (?) stable / unstable AMD64/X86 LiveDVD builds automatic creation of the live-DVD to test a very broad set of packages * automated testing of built stage / CD / LiveDVD (KVM guest?) (CLI / GUI / log parsing ?) framework to test the built stages / install media and ensure it works as expected I don't have a framework for conducting some of these tests, including the stage/iso validation, but some of them can use the existing tools like the stage building and the tree QA tests. Do you have any suggestions about the automatic testing? Do you know of other tests or tools that we can and should use to improve QA on Gentoo? You might take a look at autotest from kernel.org. It's a Python based framework for automating testing. It's specific towards kernel testing, but could be modified for your needs. -- Jack Morgan Pub 4096R/761D8E0A 2010-09-13 Jack Morgan j...@bonayri.com Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: About the Qt 4.7.3 bump
Nikos Chantziaras posted on Wed, 11 May 2011 15:44:35 +0300 as excerpted: On 05/11/2011 03:32 PM, Tomáš Chvátal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 11.5.2011 13:05, Nikos Chantziaras napsal(a): Why did the bump to Qt 4.7.3 happen? AFAIK, it only contains Symbian changes, and Gentoo does not run on the Symbian platform. With this approach you could ask why we bump each kde release. As most of the apps does not change at all. I don't know :-P Avoiding needless bumps was, IIRC, one of the reasons Gentoo uses split ebuilds. Anyway, I mentioned this because in the past, at least one time, a version bump for Qt was omitted exactly because there were no changes. I have in fact wondered about just that. Back when the kde split ebuilds were being created, one of the big advantages was said to be that most kde bumps didn't actually change anything for most apps, and we could keep the same versions. But recently I've seen comments from the kde folks saying most don't, but we bump anyway, and I know everything does seem to be bumped. Is that simply because it's simpler to track everything at the same version, instead of having kdelibs at 4.6.3 and kmail, for instance, still at 4.6.0? (That was in fact one of my worries with the initial thinking, that it'd be difficult to know whether upstream had updated and gentoo/kde had problems with it for gentoo and hadn't updated, or whether upstream simply hadn't updated that package. When the versions are all synced with upstream regardless of changes, that's not an issue, even if it does mean much more useless building.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: About the Qt 4.7.3 bump
On Wed, May 11, 2011 at 02:20:36PM +, Duncan wrote: Nikos Chantziaras posted on Wed, 11 May 2011 15:44:35 +0300 as excerpted: On 05/11/2011 03:32 PM, Tomáš Chvátal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 11.5.2011 13:05, Nikos Chantziaras napsal(a): Why did the bump to Qt 4.7.3 happen? AFAIK, it only contains Symbian changes, and Gentoo does not run on the Symbian platform. With this approach you could ask why we bump each kde release. As most of the apps does not change at all. I don't know :-P Avoiding needless bumps was, IIRC, one of the reasons Gentoo uses split ebuilds. Anyway, I mentioned this because in the past, at least one time, a version bump for Qt was omitted exactly because there were no changes. I have in fact wondered about just that. Back when the kde split ebuilds were being created, one of the big advantages was said to be that most kde bumps didn't actually change anything for most apps, and we could keep the same versions. But recently I've seen comments from the kde folks saying most don't, but we bump anyway, and I know everything does seem to be bumped. Is that simply because it's simpler to track everything at the same version, instead of having kdelibs at 4.6.3 and kmail, for instance, still at 4.6.0? (That was in fact one of my worries with the initial thinking, that it'd be difficult to know whether upstream had updated and gentoo/kde had problems with it for gentoo and hadn't updated, or whether upstream simply hadn't updated that package. When the versions are all synced with upstream regardless of changes, that's not an issue, even if it does mean much more useless building.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman To my perspective, split ebuilds ease the integration of patches. You can patch a single ebuild and not have to rebuild everything else. But, when it comes to version bumps, I think it is more safe to bump everything. Do note that we apply patches more frequently than we do version bumps, so it is definitely worth the pain of having split ebuilds. Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgpB0nbRDRd57.pgp Description: PGP signature
[gentoo-dev] Re: About the Qt 4.7.3 bump
Markos Chandras posted on Wed, 11 May 2011 15:27:48 +0100 as excerpted: To my perspective, split ebuilds ease the integration of patches. You can patch a single ebuild and not have to rebuild everything else. But, when it comes to version bumps, I think it is more safe to bump everything. Do note that we apply patches more frequently than we do version bumps, so it is definitely worth the pain of having split ebuilds. That was another reason given, and it still makes sense, as does the safety of bumping everything together (no revdep-rebuild issues that way). Thanks for the reminder. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: About the Qt 4.7.3 bump
El 11/05/11 17:43, Duncan escribió: Markos Chandras posted on Wed, 11 May 2011 15:27:48 +0100 as excerpted: To my perspective, split ebuilds ease the integration of patches. You can patch a single ebuild and not have to rebuild everything else. But, when it comes to version bumps, I think it is more safe to bump everything. Do note that we apply patches more frequently than we do version bumps, so it is definitely worth the pain of having split ebuilds. That was another reason given, and it still makes sense, as does the safety of bumping everything together (no revdep-rebuild issues that way). Thanks for the reminder. =:^) Me be user. Me see that latest version of QT not in portage. Me open bug to ask for a bump. Not that all our users are stupid, but most of them don't know wether things changed or not between versions. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Automatic testing on Gentoo
On Wed, May 11, 2011 at 6:12 AM, Jack Morgan j...@bonyari.com wrote: On 05/10/2011 01:13 PM, Jorge Manuel B. S. Vicetto wrote: Hi. Another issue that was raised in the discussion with the arch teams, even though it predates the arch teams resources thread as we've talked about it on FOSDEM 2011 and even before, is getting more automatic testing done on Gentoo. I'm bcc'ing a few teams on this thread as it involves them and hopefully might interest them as well. Both Release Engineering and QA teams would like to have more automatic testing to find breakages and to help track when things break and more importantly *why* they break. To avoid misunderstandings, we already have testing and even automated testing being done on Gentoo. The first line of testing is done by developers using repoman and or the PM's QA tools. We also have individual developers and the QA team hopefully checking commits and everyone testing their packages. Furtermore, the current weekly automatic stage building has helped identify some issues with the tree. The tinderbox work done by Patrick and Diego, as well as others, has also helped finding broken packages and or identifying packages affected by major changes before they hit the tree. The use of repoman, pcheck and or paludis quality assurance tools in the past and present to generate reports about tree issues, like Michael's (mr_bones) emails have also helped identifying and addressing issues. Recently, we've got a new site to check the results of some tests http://qa-reports.gentoo.org/ with the possibility to add more scripts to provide / run even more tests. So, why more testing? For starters, more *automatic* testing. Then more testing as reports from testing can help greatly in identifying when things break and why they break. As someone that looks over the automatic stage building for amd64 and x86, and that has to talk to teams / developers when things break, having more, more in depth and regular automatic testing would help my (releng) job. The work for the live-dvd would also be easier if the builds were automated and the job wasn't restarted every N months. Furthermore, creating a framework for developers to be able to schedule testing for proposed changes, in particular for substantial changes, might (should?) help improve the user's experience. I hope you agree with more testing by now, but what testing? It's good to test something, but what do we want to test and how do we want to test? I think we should try to have at least the following categories of tests: * Portage (overlays?) QA tests tests with the existing QA tools to check the consistency of dependencies and the quality of ebuilds / eclasses. These are almost separate. I assume your intent was 'lets automate pcheck co. runs of gentoo-x86 and if we get that working we can add overlays from layman' which sounds fine to me ;) * (on demand?) package (stable / unstable) revdep rebuild (tinderbox) framework to schedule testing of proposed changes and check their impact I'd be curious what the load is here. We are adopting an on-demand testing infrastructure at work. Right now we have a continuous build but it is time-delta based and not event-based so it groups changes together which makes it hard to find what broke things. At work we only submit a few changes a day though, so we need a very small infrastructure to test each change. Gentoo has way more commits (at least one every few minutes on average, and then there are huge commits like KDE stablization...) What I'd recommend here is essentially some kind of control field in the commit itself (commitmsg?) that controls exactly what tests are done for that commit. * Weekly (?) stable / unstable stage / ISO arch builds the automatic stage building, including new specs for the testing tree as we currently only test the stable tree. I'm curious if you constantly build unstable..do you plan on fixing it? My understanding of Gentoo is that in ~arch something is always slightly broken and thats OK. I worry that ~arch builds may just end up being noise because they don't build properly due to the high velocity of changes. * (schedule?) specific tailored stage4 builds testing of specific tailored real world images (web server, intranet server, generic desktop, GNOME desktop, KDE desktop, etc). Again it would be interesting to have some kind of control field in my commits so when KDE is stable I could trigger a build of the 'KDE stage4' or whatnot. If we ever finish this gentoo-stats project it would be interesting to see what users are actually using as well. Do users use the defaults? Are the stage4's we are testing actually relevant? * Bi-Weekly (?) stable / unstable AMD64/X86 LiveDVD builds automatic creation of the live-DVD to test a very broad set of packages * automated testing of built stage / CD / LiveDVD (KVM guest?) (CLI / GUI / log
Re: [gentoo-dev] PyXML
2011-05-11 12:30:18 Tomáš Chvátal napisał(a): Dne 10.5.2011 23:21, Arfrever Frehtes Taifersar Arahesis napsal(a): PyXML is dead: http://mail.python.org/pipermail/xml-sig/2004-November/010735.html http://mail.python.org/pipermail/xml-sig/2006-June/011545.html PyXML provides _xmlplus module, which replaces xml module (from standard library) at run time, which might result in various problems. I'm planning to implement the following solution: - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of this function will be necessary to use replace xml module with _xmlplus module. Python =2.7.1-r2:2.7 will be added to the tree in next week and will be temporarily package.masked. Later this change will be backported to new versions in older slots. - All packages, which use PyXML, will have to be patched to call xml.use_pyxml(). The following code should be added before first import of anything from xml module: import xml if hasattr(xml, use_pyxml): xml.use_pyxml() This code works with previous versions of Python, so no changes in dependencies are needed. Apart from not being developed is PyXML actualy broken so we can't wait for upstream [1] to migrate their packages? PyXML provides code from 2004. Since then, there were many fixes in stdlib xml module. The following commands test code from xml module (which might be _xmlplus) and show problems when PyXML is installed: python2.7 -m test.test_minidom python2.7 -m test.test_pyexpat python2.7 -m test.test_sax -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] rfc: *_iface variables in openrc network scripts
All, we received a regression for openrc which prompted me to post this to the list to see what everyone thinks. The bug is http://bugs.gentoo.org/366905. Currently, we use one variable, config_$(INTERFACE), to configure the interfaces,. In the bsd world there are no issues, because there is only one configuration tool, ifconfig. However, in the linux world, there are two, ifconfig and iproute2, which have completely different command line syntax. Currently, we try to keep the syntax of config_* constant, which means that the scripts attempt to convert ifconfig syntax to iproute2, and the other way around. In my opinion, the best way to fix this, and the best way forward, would be to stop doing this. My plan is something like this: For the next openrc release, put in a warning that config_* is deprecated and advise the use of ifconfig_* or ipconfig_* depending on which interface handler is being used. Then, at some point in the future, remove support for config_*. Does anyone have any thoughts? Thanks, William pgpLLzZXA0gug.pgp Description: PGP signature
Re: [gentoo-dev] rfc: *_iface variables in openrc network scripts
Yeah I know I'm replying to my own message, but I also have another idea about this. Another option would be that for the next release we just stop parsing and use config_* but without trying to do any conversions. The disadvantage of this would be that people would have to change their /etc/conf.d/net files immediately after they upgrade or their network might not come up. It is true that this would be easier from a coding perspective, but would it be ok for the users? William pgp63q7CrBEDm.pgp Description: PGP signature
Re: [gentoo-dev] rfc: *_iface variables in openrc network scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12-05-2011 01:45, William Hubbs wrote: All, we received a regression for openrc which prompted me to post this to the list to see what everyone thinks. The bug is http://bugs.gentoo.org/366905. Currently, we use one variable, config_$(INTERFACE), to configure the interfaces,. In the bsd world there are no issues, because there is only one configuration tool, ifconfig. However, in the linux world, there are two, ifconfig and iproute2, which have completely different command line syntax. Currently, we try to keep the syntax of config_* constant, which means that the scripts attempt to convert ifconfig syntax to iproute2, and the other way around. In my opinion, the best way to fix this, and the best way forward, would be to stop doing this. My plan is something like this: For the next openrc release, put in a warning that config_* is deprecated and advise the use of ifconfig_* or ipconfig_* depending on which interface handler is being used. Then, at some point in the future, remove support for config_*. Does anyone have any thoughts? William, isn't that the whole point of the modules variable in the config file? One of the first things I do when configuring a new system is to edit /etc/conf.d/net and I start by adding modules=iproute2 to it. Thanks, William - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNyz9vAAoJEC8ZTXQF1qEPeu8P/39X4MPzqwNe0wb7yBBxTOhz bSCoWroD+NyU6WHWq/WumZBKugXhjQpxHr1QcXtckUJonVcwZz7bxuv6YzMqReOY 00bhYF4Ok2xpFrLlwNR5c+lRxNyOI4S8noglkGnNgnnEyCIP76fENdzMNu9viHhf 23bOUFBaNe0Bm8R7NLpntQcM4Ihk4aC7l60ffRC3/L0pRetPJeDjpTOKuooxsFKP Bms4ZgATtUziAkjcZ4z/u3hIbgvNwcQSlXS2OHfPCPpvxGKx9jpDkbnW4WL582h5 /SH4RF1pCFFyTwQ4LFZatftD/r/aOqO1CXlbroEDgNL79dE93Cjf1US3fiIDXHTu 5VNi/HabY9Mz13+HxUIvUxBGx7q3CUY2wpPpK0U5A+voxTlLF7W2rp/+QZZfwQXG TJVFOIwn/Egr4SUlD6ayS+tVFARIygjJhQCCiX1aTdWZ1k13wqg72DcGHnxQhdjd s83UI8FAaRh7CWX6/hfo+FxZ0oE+3V4kNN3Mjm1qB1bqCO+p98BwMGR+DQHRSOGU ue6pGQ5EKnrTqJ68aBkbDL3h56pOf5SKoIw71bCv0lXbDVTif3+IRveyUlEVy7Dp 7mmYLE49paCQkY0SDYhpi22TzBE/RGg9lNz8Zt3WG8tS1Lwg7I0Q1zKuVIdSEbsH tSfJWWzH8NE9731oTi35 =v/dl -END PGP SIGNATURE-
