[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-05-01 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2016-05-01 23:59 UTC. Removals: app-cdr/qmultirecord 20160427-11:39 kensington f753971 dev-libs/matrixssl20160426-08:31 bman ee33c72 dev-perl/text-template20160425-06:36 dilfridge 55980dc dev-perl/text-wrapper 20160425-06:46 dilfridge ef9ad51 dev-perl/tie-encryptedhash20160425-09:32 dilfridge 2a84c39 dev-perl/yaml 20160426-13:13 dilfridge 643cab3 dev-python/llvmmath 20160427-11:58 kensington 23f08e1 dev-python/llvmpy 20160427-11:59 kensington 2ed0fc2 dev-python/pykit 20160427-11:55 kensington 542b02b mail-client/claws-mail-acpi-notifier 20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-address_keeper 20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-archive20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-attachwarner 20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-att-remover20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-clamd 20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-fancy 20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-fetchinfo 20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-gdata 20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-gtkhtml20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-mailmbox 20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-newmail20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-notification 20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-pdf-viewer 20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-perl 20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-python 20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-rssyl 20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-spam-report20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-tnef-parse 20160428-10:56 polynomial-c 96d3be4 mail-client/claws-mail-vcalendar 20160428-10:56 polynomial-c 96d3be4 media-sound/shoutcast-server-bin 20160426-08:26 bman f707d40 media-sound/shoutcast-trans-bin 20160426-08:26 bman 8ebf8af net-irc/srvx 20160426-08:23 bman d7ec853 net-p2p/hx20160427-11:37 kensington 28f1ec3 sys-apps/rsbac-admin 20160428-00:35 blueness cf2cddd sys-kernel/rsbac-sources 20160428-00:33 blueness f038ddd www-apps/coppermine 20160426-08:29 bman 1aa3616 Additions: app-admin/yadm20160430-13:53 wraeth fe63884 app-emacs/basic-toolkit 20160424-20:44 ulm17b7d6b app-emacs/buffer-extension20160424-20:45 ulmb2c2bca app-emacs/cycle-buffer20160424-20:43 ulm6d2c182 app-emacs/revive 20160424-20:38 ulm7019e0e app-emacs/windows 20160424-20:41 ulm1066bc4 app-emulation/diskimage-builder 20160501-20:46 prometheanfire 50b3a09 app-emulation/docker-registry 20160425-07:45 zmedicoaa1eaea app-shells/mpv-bash-completion20160425-14:50 monsieurp 8b203a8 dev-java/jts-core 20160501-22:32 chewi 2310234 dev-libs/libarcus 20160412-20:11 idella4987453e dev-perl/Text-Template20160425-06:19 dilfridge 0ffc342 dev-perl/Text-Wrapper 20160425-06:38 dilfridge 34e51d7 dev-perl/Tie-EncryptedHash20160425-09:28 dilfridge ee32380 dev-perl/XML-RSS-LibXML 20160426-00:25 dilfridge 005f3a5 dev-perl/YAML 20160426-13:00 dilfridge ef40501 dev-python/dib-utils 20160501-20:41 prometheanfire 6d0a82b dev-python/dominate 20160425-22:16 idella4402a716 dev-python/flask-appconfig20160425-23:00 idella49d3f2a0 dev-python/flask-bootstrap20160425-23:09 idella4a6a5a81 dev-python/flask-debug20160425-23:06 idella40b4ba4e dev-python/flask-nav 20160425-22:58 idella4e871e51 dev-python/inflection 20160425-22:44 idella40db7939 dev-python/jaraco-stream 20160430-00:55 idella4dcdbc7d dev-python/rst-linker 20160430-00:52 idella40ed3a70 dev-python/uranium20160415-13:15 idella46a0fc3d dev-python/visitor20160425-22:23 idella44368f8a dev-qt/qtlocation 20160428-14:52
Re: [gentoo-dev] New gen-b0rk repository specifically for Q/A tools testing
On 02/05/16 00:53, Brian Dolbec wrote: > In order to further improve the chances of Q/A tools catching > errors. I have created a new repo (overlay) which will contain minimal > test case ebuilds. The idea is to have test case ebuilds to run > repoman code against. The outcome of these runs should be comparable > to pre-recorded output. In that way as more code changes are applied > as part of the stage3 re-write as well as new test cases and checks to > be added to it's capabilities. It should minimize the bugs introduced > in releases. > > Repoman does have some unit tests, but it is far from 100% coverage. > Also with the major structural changes that the code has been > undergoing, it is not always possible for the unit tests to be > compatible with the new code. > > This new repository is open to all Gentoo developers to contribute to. > All we ask is that you follow some simple common sense rules for adding > additional test ebuilds. > > The repo is located at: > > https://gitweb.gentoo.org/repo/proj/gen-b0rk.git/ > > Here is the README included in the base directory. > > This repository is for the primary purpose of testing Q/A tools like repoman. > > The ebuilds it contains are for testing specific areas of tests that are > performed as part of the normal operation of that Q/A tool. > > This repository is open to all Gentoo developers under the following rules: > > 1) The master branch is to remain the stable Q/A testing branch. > > 2) All ebuilds are to be minimal test cases. > > 3) All ebuilds in it are to have no more than 3 or 4 flaws to detect. >This makes it easier to spot errors during code development. Simply > running >repoman in a category should be enough to test everything the module tests. >This excludes some commit only checks which can be run in a local only > branch. > > 4) All category names are to represent the Q/A category being tested. > ie: > ebuild-test - tests various aspects of the ebuild repoman module > eclass-test - various eclass module tests > ... > > 5) like the category naming, the package naming will follow the test >being performed. >ie: >eclass-test/live-keywords - test the eclass module LiveEclassChecks >keywords check >ebuild-test/invalid - test for invalid package name detection > > 6) Profiles ... Not sure about this one, but probaly will have masters=gentoo >That should ensure it maintains co-ordination with the main gentoo repo. >All new or modified eclasses that affect pkg metadata should be validated > in >a branch. > > 7) New module development and test ebuilds will be done in a branch or > personal >repo and submitted to the gentoo-portage-dev email list for review and >approval to merge into master. >NOTE: This rule is lifted for the initial creation and population of > test ebuilds to use to test out the repoman code. An anouncemnt to > the gentoo-project email list will be made when this initial > population > period is being ended. > > 8) Signed commits only, also signed-pushes are mandatory > > 9) The metadata category will get files of validated output that can be used >to verify code changes in the various categories and repo wide runs. >Diffing the output, should help to verify code changes did not break > anything. > > 10) See rules 1-9 :-) > +1 be good to have somewhere central for this stuff :] signature.asc Description: OpenPGP digital signature
[gentoo-dev] New gen-b0rk repository specifically for Q/A tools testing
In order to further improve the chances of Q/A tools catching errors. I have created a new repo (overlay) which will contain minimal test case ebuilds. The idea is to have test case ebuilds to run repoman code against. The outcome of these runs should be comparable to pre-recorded output. In that way as more code changes are applied as part of the stage3 re-write as well as new test cases and checks to be added to it's capabilities. It should minimize the bugs introduced in releases. Repoman does have some unit tests, but it is far from 100% coverage. Also with the major structural changes that the code has been undergoing, it is not always possible for the unit tests to be compatible with the new code. This new repository is open to all Gentoo developers to contribute to. All we ask is that you follow some simple common sense rules for adding additional test ebuilds. The repo is located at: https://gitweb.gentoo.org/repo/proj/gen-b0rk.git/ Here is the README included in the base directory. This repository is for the primary purpose of testing Q/A tools like repoman. The ebuilds it contains are for testing specific areas of tests that are performed as part of the normal operation of that Q/A tool. This repository is open to all Gentoo developers under the following rules: 1) The master branch is to remain the stable Q/A testing branch. 2) All ebuilds are to be minimal test cases. 3) All ebuilds in it are to have no more than 3 or 4 flaws to detect. This makes it easier to spot errors during code development. Simply running repoman in a category should be enough to test everything the module tests. This excludes some commit only checks which can be run in a local only branch. 4) All category names are to represent the Q/A category being tested. ie: ebuild-test - tests various aspects of the ebuild repoman module eclass-test - various eclass module tests ... 5) like the category naming, the package naming will follow the test being performed. ie: eclass-test/live-keywords - test the eclass module LiveEclassChecks keywords check ebuild-test/invalid - test for invalid package name detection 6) Profiles ... Not sure about this one, but probaly will have masters=gentoo That should ensure it maintains co-ordination with the main gentoo repo. All new or modified eclasses that affect pkg metadata should be validated in a branch. 7) New module development and test ebuilds will be done in a branch or personal repo and submitted to the gentoo-portage-dev email list for review and approval to merge into master. NOTE: This rule is lifted for the initial creation and population of test ebuilds to use to test out the repoman code. An anouncemnt to the gentoo-project email list will be made when this initial population period is being ended. 8) Signed commits only, also signed-pushes are mandatory 9) The metadata category will get files of validated output that can be used to verify code changes in the various categories and repo wide runs. Diffing the output, should help to verify code changes did not break anything. 10) See rules 1-9 :-) -- Brian Dolbec pgpU8UI_wWO7k.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Dev retirement - Farewell message
On 05/01/2016 07:57 AM, José Fournier wrote: > Hi everybody, > > I have been a bit far from Gentoo for a rather long time now. I joined > Gentoo in 2013 and I used to be a translator for the French language. At > this time, I had to become a developer in order to be able to submit my > work in the previous documentation system – but in reality I am not a > developer at all. Nowadays, with the new wiki – which I can see grow > and improve day after day – it is no longer necessary for people like me > become a developer. > > At the beginning I could get a friendly and patient help from Sven > Vermeulen who introduced me and was my mentor for a while. I am very > grateful to him because it is not something obvious for someone who is > not a computer scientist to enter a world like the Gentoo Community and > Sven contributed a lot to make me feel at home. > > Recently, I decided to join the Fedora community to help as a translator > again. It a very different distribution and community but my previous > experience at Gentoo is very valuable. Arriving in this new home, I told > them all the good I think of the Gentoo distribution and of its people. > If there is one distribution which made me progress substantially in my > understanding of the Linux system, it is Gentoo, with no doubt. > > Before leaving your community, I want to wish you all the best and thank > you very much for your constant effort to make free and open source > software available to everyone. > > With kind regards > > José > > I never spoke with you, but totally agree that Gentoo's a great place to learn more about GNU/Linux as a whole. I'm sure many French users appreciated your work on the documentation, and I'm sure the people at Fedora will feel the same. Good luck out there! -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] metadata.dtd: Remove obsolete element per GLEP 68
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 1 May 2016 18:42:54 -0400 Göktürk Yüksek wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Michał Górny: > > On Sat, 30 Apr 2016 02:36:18 -0400 Göktürk Yüksek > > wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > >> > >> Michał Górny: > >>> On Thu, 28 Apr 2016 19:41:06 -0400 Göktürk Yüksek > >>> wrote: > >>> > -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > > Brian Dolbec: > > On Thu, 28 Apr 2016 15:39:05 -0400 Göktürk Yüksek > > wrote: > > > >> --- metadata.dtd | 5 + 1 file changed, 1 > >> insertion(+), 4 deletions(-) > >> > >> diff --git a/metadata.dtd b/metadata.dtd index > >> 7626a57..b608852 100644 --- a/metadata.dtd +++ > >> b/metadata.dtd @@ -3,7 +3,7 @@ >> pkgname CDATA ""> > >> > >> - >> > >> (maintainer|natural-name|longdescription|slots|use|upstream)* > >> )> + >> (maintainer|longdescription|slots|use|upstream)* )> > >> @@ > >> -13,9 +13,6 @@ explicit type) for Gentoo maintainers is > >> prohibited. --> >> (person|project|unknown) "unknown"> > >> > >> - - >> natural-name (#PCDATA) > >>> - > >>> > >> > > > > Isn't this almost obsolete? it's now xmlschema... And I > > hope to have the new repoman with it out this weekend :) > > Does GLEP 68 explicitly declare metadata.dtd obsolete? I see > that the example metadata.xml on the GLEP is missing DOCTYPE, > are we getting rid of those too? > >>> > >>> No, and I don't know. > >>> > >>> metadata.dtd is still required by many tools, and as such it > >>> makes sense to keep it. However, we may want to put some > >>> warning that it's not very strict, and allows major structural > >>> violations due to technical limitations. > >>> > >> After a discussion with ulm on IRC, we agreed that the following > >> makes sense: "the format of the metadata is defined in GLEP 68. > >> the syntax is defined in metadata.dtd. The xml-schema can be used > >> for stricter validation checks." If you have no objections, I > >> will update devmanual based on this description. > > > > What is the precise difference between 'format' and 'syntax' here? > > I'm no native English speaker, and I don't see any obvious split > > of responsibility between the two here, and I'm pretty sure this > > will be quite confusing for other people as well. > > > I admit that it is hard to make a clear distinction. When I look at > the GLEPs replaced by GLEP68, I see that they propose a change for > metadata.xml and explain how that affects metadata.dtd. GLEP34 has > "The DTD file would need to be updated to include the > element.", GLEP46 explicitly says "metadata.dtd should allow the use > of a upstream tag in metadata.xml.", GLEP56 points to #199788 which > required DTD to be patched. GLEP68 is rather vague as to how > metadata.dtd is affected. It doesn't say whether it should be updated > or if it has any role at all. > > GLEP68 provides a single human readable specification for the metadata > format. In that respect, however, the DTD along with the comments in > it is just as expressive, if not better: a developer can read through > the DTD and learn all the information contained in the GLEP, plus the > remote-id values which are not part of the specification for reasons > you stated earlier. And that was the reason why I used the term > "syntax": the DTD lists all the allowed elements, attributes, and > values for the metadata that should be used in conformance with the > GLEP . > > In the end, the DTD isn't much better than the GLEP as a human > readable document and does a worse job than the xsd as a machine > readable document for validation purposes. Once repoman switches to > the xml-schema, there would be no good use for it and I don't know > what should be done about the DTD. I think that until we figure it > out, we should keep it in sync with the GLEP and xsd. Can I trouble you and Michał to create some test ebuilds for repoman that break the rules in a way that properly tests repoman code? It'll be included in the new gen-b0rk repo which is specifically for repoman test ebuilds. I'll be sending out an email for it shortly. - -- Brian Dolbec -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJXJpDdXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNUQ3Qzc0RTA4MUNDNzBEQjRBNEFBRjVG QkJEMDg3Mjc1ODIwRUQ4AAoJEPu9CHJ1gg7YAWgQAJ/oebwzsbbieOlEZZaONiZr WPtpKY9en4Dgf2OLeLMbv3boQY71OVVJCdNbqfRHkeYPlIZLgYzoy+tWoh6lUJUS 91GJLVWNpm+OnD4ihc6/6YJW7SVXVv9Y6Ekm80lgWnm6EJZ5sczdvyvt3WzMciOD P0bzdFPJEDaktCZzMZJrmrjWv6SHEwnNinFpBKASS/G7CpS88z1Ts87hlRdzjidE Bpx+p1AVudS3WuQcqz/Tdu4QvNHRCm0ZM77XtNPVYl5ZAwAKn3rj8Nw+yZfLTjx9 ldv1n9k6vQoUi4kY/Icrj8FJOo7iWxm9whxh/5nUhcp8OgigsK7OiDyWaJ9+y5jP AJeoMqfCjQbsmUV8pxeNv2AB0CbvJ00/m9C5aET0T7m7LwqK7N5xTMWPk3OVRHlm
Re: [gentoo-dev] Reminder: ALLARCHES
On 05/01/2016 07:03 AM, Andreas K. Huettel wrote: > Am Sonntag, 1. Mai 2016, 15:32:27 schrieb Jeroen Roovers: >> On Sat, 30 Apr 2016 23:16:42 +0200 > > (For the record, hppa is definitely NOT the problem.) > Forgive me, I just pulled hppa out of the air as an example of a secondary, different arch. afaict nobody's really picking on a specific arch. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] metadata.dtd: Remove obsolete element per GLEP 68
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Michał Górny: > On Sat, 30 Apr 2016 02:36:18 -0400 Göktürk Yüksek > wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >> >> Michał Górny: >>> On Thu, 28 Apr 2016 19:41:06 -0400 Göktürk Yüksek >>> wrote: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Brian Dolbec: > On Thu, 28 Apr 2016 15:39:05 -0400 Göktürk Yüksek > wrote: > >> --- metadata.dtd | 5 + 1 file changed, 1 >> insertion(+), 4 deletions(-) >> >> diff --git a/metadata.dtd b/metadata.dtd index >> 7626a57..b608852 100644 --- a/metadata.dtd +++ >> b/metadata.dtd @@ -3,7 +3,7 @@ > pkgname CDATA ""> >> >> -> >> (maintainer|natural-name|longdescription|slots|use|upstream)* >> )> +> (maintainer|longdescription|slots|use|upstream)* )> >> @@ >> -13,9 +13,6 @@ explicit type) for Gentoo maintainers is >> prohibited. --> > (person|project|unknown) "unknown"> >> >> - - > natural-name (#PCDATA) >>> - >>> >> > > Isn't this almost obsolete? it's now xmlschema... And I > hope to have the new repoman with it out this weekend :) Does GLEP 68 explicitly declare metadata.dtd obsolete? I see that the example metadata.xml on the GLEP is missing DOCTYPE, are we getting rid of those too? >>> >>> No, and I don't know. >>> >>> metadata.dtd is still required by many tools, and as such it >>> makes sense to keep it. However, we may want to put some >>> warning that it's not very strict, and allows major structural >>> violations due to technical limitations. >>> >> After a discussion with ulm on IRC, we agreed that the following >> makes sense: "the format of the metadata is defined in GLEP 68. >> the syntax is defined in metadata.dtd. The xml-schema can be used >> for stricter validation checks." If you have no objections, I >> will update devmanual based on this description. > > What is the precise difference between 'format' and 'syntax' here? > I'm no native English speaker, and I don't see any obvious split > of responsibility between the two here, and I'm pretty sure this > will be quite confusing for other people as well. > I admit that it is hard to make a clear distinction. When I look at the GLEPs replaced by GLEP68, I see that they propose a change for metadata.xml and explain how that affects metadata.dtd. GLEP34 has "The DTD file would need to be updated to include the element.", GLEP46 explicitly says "metadata.dtd should allow the use of a upstream tag in metadata.xml.", GLEP56 points to #199788 which required DTD to be patched. GLEP68 is rather vague as to how metadata.dtd is affected. It doesn't say whether it should be updated or if it has any role at all. GLEP68 provides a single human readable specification for the metadata format. In that respect, however, the DTD along with the comments in it is just as expressive, if not better: a developer can read through the DTD and learn all the information contained in the GLEP, plus the remote-id values which are not part of the specification for reasons you stated earlier. And that was the reason why I used the term "syntax": the DTD lists all the allowed elements, attributes, and values for the metadata that should be used in conformance with the GLEP . In the end, the DTD isn't much better than the GLEP as a human readable document and does a worse job than the xsd as a machine readable document for validation purposes. Once repoman switches to the xml-schema, there would be no good use for it and I don't know what should be done about the DTD. I think that until we figure it out, we should keep it in sync with the GLEP and xsd. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJXJoZnAAoJEIT4AuXAiM4z1tsIAKj7/dBAQcsttsMxJbOlM4Ew GMiS4LK3/QZqlEM8ixL3otKptbWDhyJiB+c7cafyAamgFKGprWYnk2X+zFEfgmRw adjWjH4fwtS/AW/VFU4aeE4cYVOGF0ju0dh6ZO6bAYl4MJtcS5xVtRdDkIm3eacX OMjdzvuKgwYKiYxRu2AmCLS2+jExEj48mDEa9jPZMOb14xEljsRNjF76kPr6o8eG /XJ6t5o4+Ckkpwx4kckBUDtSj6ipuPz0SqwVrYLxhogwDas6E0h9BovGuaeLmgVM GYCXJzsetuWIvbRxJJhH9cTADjCwAt7SYGfdA72fknnmf0QZgScPjBnLUQSn2G4= =/CcU -END PGP SIGNATURE-
Re: [gentoo-dev] Reminder: ALLARCHES
On Sun, May 1, 2016 at 9:32 AM, Jeroen Roovers wrote: > And it means we're missing opportunities where "pure" interpreted > packages may test corner cases of the language implementation and find > bugs in (JIT or previously) "compiled" code. And that means we're > calling things "stable" that may expose such bugs that turn out not to > be corner cases at all and affect running systems in unpleasant ways. While this is a risk, I still think the cleanest solution here is to encourage maintainers to be aware of the packages they maintain and exercise the appropriate discretion when they think these corner cases exist and are important. Understanding the nuances of a package and how it works and how it is used is really a core purpose of having a maintainer in the first place. Of course no maintainer is perfect, but I think the upside is more than the downside here and as with anything we'll learn. -- Rich
[gentoo-dev] Dev retirement - Farewell message
Hi everybody, I have been a bit far from Gentoo for a rather long time now. I joined Gentoo in 2013 and I used to be a translator for the French language. At this time, I had to become a developer in order to be able to submit my work in the previous documentation system – but in reality I am not a developer at all. Nowadays, with the new wiki – which I can see grow and improve day after day – it is no longer necessary for people like me become a developer. At the beginning I could get a friendly and patient help from Sven Vermeulen who introduced me and was my mentor for a while. I am very grateful to him because it is not something obvious for someone who is not a computer scientist to enter a world like the Gentoo Community and Sven contributed a lot to make me feel at home. Recently, I decided to join the Fedora community to help as a translator again. It a very different distribution and community but my previous experience at Gentoo is very valuable. Arriving in this new home, I told them all the good I think of the Gentoo distribution and of its people. If there is one distribution which made me progress substantially in my understanding of the Linux system, it is Gentoo, with no doubt. Before leaving your community, I want to wish you all the best and thank you very much for your constant effort to make free and open source software available to everyone. With kind regards José
Re: [gentoo-dev] Reminder: ALLARCHES
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Sonntag, 1. Mai 2016, 15:32:27 schrieb Jeroen Roovers: > On Sat, 30 Apr 2016 23:16:42 +0200 > > "Andreas K. Huettel" wrote: > > just as a small reminder, to ease the load on all arch teams: > > > > If a stablerequest has the keyword ALLARCHES set, then > > * the first arch that tests successfully and stabilizes > > * can and *should* immediately stabilize for all requested arches! > > can => is allowed > should => may Well, that's roughly similar to "if I have bugedit permissions I should immediately assign a new bug to the correct maintainer". Yes I may choose not to do that, but then others may choose to see my actions as unproductive or obstructive. > > > Whether this keyword is set on a bug is decision of the package > > maintainer. > > > > For example, Perl team sets ALLARCHES normall for all pure-perl > > packages (i.e., no compilation / gcc involved). > > And it means we're missing opportunities where "pure" interpreted > packages may test corner cases of the language implementation and find > bugs in (JIT or previously) "compiled" code. And that means we're > calling things "stable" that may expose such bugs that turn out not to > be corner cases at all and affect running systems in unpleasant ways. No objections... The only "way out" is to have more arch testers. Apart from cloning Ago, what could we do to achieve that? (For the record, hppa is definitely NOT the problem.) Cheers, Andreas - -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJXJgzIXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkXjQQANo3Q1wTa1Kp5c8CatRn1w56 ntkd/lDdQSOoNbS4OnF219SStq4vgwCSsr1inSpa3fdaqwWekQfGyosNP2FHWTYH wM+t40zh0z+NUk/VcLRp8kSJBmYGav/si7jPNLu5s2wGwqqZILAEVhblFAF+3/Pe d0GBf090CFwcn1V86wNmxRNXcZKCgd1NwoQHpYY2rttNlEFUAlCcvCgX5uno1cBw IdY6upBbcAuGyKf0CP+ab85F6QMLHWLA6AajUZFbWsGAG1M1m0aK6SuxAfEAG58m 0iU5CZW8D/+z7thMaP9U/WEhuOFJkerhKOjQWSvf3zObhRWhtWK/3ns7GVE6QeL6 zq2fQYyTdTBv0eHu4r+W10CrRCq58BwBDnCTF1EzmWKrREqXsxnzypF3hSX+OOpM IbQ83RHSIarS5/KrMMVLeb+xobrYuwlekOwtv7Y2Uc2vbPsAY22C9avKqn+E+1MK L2OmFXpyx41O18vzIyXm3z+u0N2Ace9AchQAkkLfSEL/vfjCSS53ZHGh+teOgU3w yylmFQGIupol2PVV2r3ihCkeg1f78ljOYJ2+cZ7v0y5vR/DCAtDoQFTAy6im84Lu LwLJJ63FnB49M5L6zrTXlQCx5glaXvOjLjm8oUiT5o7samMpJbW9baVfzrtToK86 8HhL2kepBBSLGLNUiJTT =MPDf -END PGP SIGNATURE-
Re: [gentoo-dev] Reminder: ALLARCHES
On Sat, 30 Apr 2016 23:16:42 +0200 "Andreas K. Huettel" wrote: > just as a small reminder, to ease the load on all arch teams: > > If a stablerequest has the keyword ALLARCHES set, then > * the first arch that tests successfully and stabilizes > * can and *should* immediately stabilize for all requested arches! can => is allowed should => may > Whether this keyword is set on a bug is decision of the package > maintainer. > > For example, Perl team sets ALLARCHES normall for all pure-perl > packages (i.e., no compilation / gcc involved). And it means we're missing opportunities where "pure" interpreted packages may test corner cases of the language implementation and find bugs in (JIT or previously) "compiled" code. And that means we're calling things "stable" that may expose such bugs that turn out not to be corner cases at all and affect running systems in unpleasant ways. jer
Re: [gentoo-dev] Reminder: ALLARCHES
On 04/30/2016 07:26 PM, Rich Freeman wrote: > On Sat, Apr 30, 2016 at 8:53 PM, Daniel Campbell wrote: >> >> As you said, however, it's a choice of the maintainer. Things like Perl >> and Python may be less prone to this issue since they're meant to be >> portable. >> > > The concept is that the maintainer will only use this when this is the > case. The goal is to cut down on stabilization burden esp for minor > arches on stuff that should be arch independent. I don't think we > formalized a ton of rules - maintainers should know when it is safe to > use. > Okay, sounds great then. Sorry if I misunderstood. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
