Re: [gentoo-dev] UTF-8 in GLEP56 use flags?
Ben de Groot wrote: The xml header in each metadata.xml states that the content is UTF-8 encoded, and any XML parser has to be able to handle this. Also, when used literally in xml, the 5 special characters ' cause a well-formedness error, as far as I know. You're wrong, it's absolutely safe to use ' and in element contents. You might have to escape them when in attribute value, though -- example: foo bar=baz quot; test/ That's because the XML parser would have no way of telling if the is supposed to terminate the attribute value or not. of using the apostrophe. So in my opinion, if we want to use xml, we should use unicode properly. In my opinion, there's absolutely no benefit in using fancy characters everywhere, just because it's allowed by the XML spec. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
On Wed, 01 Oct 2008 09:37:25 -0700 Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Hill wrote: On Mon, 29 Sep 2008 22:31:46 -0700 Zac Medico [EMAIL PROTECTED] wrote: Can package.use syntax be extended to allow set entries? @compiz-fusion -gnome kde kde4 Perhaps, but we need to clarify how that sort of setting will affect nested sets. For example, if @compiz-fusion contains nested sets, would those USE settings apply to the nested sets as well? Will nested sets be allowed to have independent USE settings from the sets that nest them? Maybe a nested set could inherit the USE flag settings of its parent set unless it has its own entry in package.use. Though what happens if a package is in both sets which have conflicting flags in package.use? I would say that the nested set has to have priority. If not, I can easily imagine people getting confused when their USE settings for a set are being applied to all but one or two packages. It seems to me that the most logical approach would be to do some sort of incremental stacking, similar to the way that USE flags stack in the profiles. Suppose that we have the following settings in package.use: @kde-metafoo bar @kdeedu-meta -foo If the flags are stacked incrementally, analogously to the way that they are stacked in profiles, then the above setting would apply the foo and bar flags to all of @kde-meta except for the @kdeedu-meta subset which would only have bar applied since foo has been disabled incrementally. Does this approach seem reasonable? From a lowly users perspective, I would say this is more intuitive. It fits with the expected policy of the closest flag to the package taking precedence... Rob. signature.asc Description: PGP signature
[gentoo-dev] Testing is not a valid reason to package.mask
# Gen 2 Developer [EMAIL PROTECTED] (`date`) # Masked for testing. =rofl-cat/omgpkg-ver Please people, if you want to get something tested, then don't mask it. If you find that you cannot commit an ebuild because of badly keyworded dependencies, then drop the relevant keywords and file a bug report with a KEYWORDREQ. Kind regards, JeR
Re: [gentoo-dev] Testing is not a valid reason to package.mask
On Thu, 2 Oct 2008 22:24:35 +0200 Jeroen Roovers [EMAIL PROTECTED] wrote: # Gen 2 Developer [EMAIL PROTECTED] (`date`) # Masked for testing. =rofl-cat/omgpkg-ver Please people, if you want to get something tested, then don't mask it. If you find that you cannot commit an ebuild because of badly keyworded dependencies, then drop the relevant keywords and file a bug report with a KEYWORDREQ. Lest I forget, the exception being that a particular version should never ever go stable, in which case the masking reason should still be different. In that case you would still not mark it as masked for testing - what I wanted to clarify is that the mask reason isn't valid if you want stuff to get tested, as it prevents exactly that from happening. Kind regards, JeR
Re: [gentoo-dev] Testing is not a valid reason to package.mask
On Thu, Oct 2, 2008 at 3:30 PM, Jeroen Roovers [EMAIL PROTECTED] wrote: On Thu, 2 Oct 2008 22:24:35 +0200 Jeroen Roovers [EMAIL PROTECTED] wrote: # Gen 2 Developer [EMAIL PROTECTED] (`date`) # Masked for testing. =rofl-cat/omgpkg-ver Please people, if you want to get something tested, then don't mask it. If you find that you cannot commit an ebuild because of badly keyworded dependencies, then drop the relevant keywords and file a bug report with a KEYWORDREQ. Lest I forget, the exception being that a particular version should never ever go stable, in which case the masking reason should still be different. In that case you would still not mark it as masked for testing - what I wanted to clarify is that the mask reason isn't valid if you want stuff to get tested, as it prevents exactly that from happening. I would argue that overlays are a bigger barrier to testing than being masked for testing At least they are exposed to the entire Gentoo population if they are p.masked in the tree. Additionally, there are use cases for p.masking for testing in the tree, especially if you have users testing it for you. There shouldn't be a limit to the amount of self-QA that we provide to protect the users, if so deemed necessary. Just saying... -Jeremy
Re: [gentoo-dev] Testing is not a valid reason to package.mask
On Thu, Oct 2, 2008 at 1:24 PM, Jeroen Roovers [EMAIL PROTECTED] wrote: # Gen 2 Developer [EMAIL PROTECTED] (`date`) # Masked for testing. =rofl-cat/omgpkg-ver Please people, if you want to get something tested, then don't mask it.If you find that you cannot commit an ebuild because of badly keyworded dependencies, then drop the relevant keywords and file a bug report with a KEYWORDREQ. So you have made two comments. 1) 'Package.mask not for testing.' 2) 'If you cannot commit an ebuild due to badly keyworded deps; file bugs to get them fixed.' I agree with 2 but not with 1. If pmask is not for testing...what is it for? -Alec Kind regards, JeR
Re: [gentoo-dev] Testing is not a valid reason to package.mask
Alec Warner wrote: If pmask is not for testing...what is it for? UT GOTY and nvidia-drivers, of course! signature.asc Description: OpenPGP digital signature
[gentoo-dev] proj/en/perl/outdated-cpan-packages.xml automatic update
Hi Folks, To help out the perl team, I converted their up2date-ng script running to be purely automatic from cvs.g.o now, it will run daily at 01h52 UTC. If you touch up2date_package.altname or up2date_package.mask please give me a shout so I can ensure updated copies on the server. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp4PiToLqgm4.pgp Description: PGP signature
Re: [gentoo-dev] proj/en/perl/outdated-cpan-packages.xml automatic update
On Thu, Oct 02, 2008 at 06:20:57PM -0700, Robin H. Johnson wrote: Hi Folks, To help out the perl team, I converted their up2date-ng script running to be purely automatic from cvs.g.o now, it will run daily at 01h52 UTC. If you touch up2date_package.altname or up2date_package.mask please give me a shout so I can ensure updated copies on the server. And something is broken with CPAN, just in time for us :-). Manually browsing give me: http://search.cpan.org/~rjbs/Email-MessageID-1.400/ But using CPAN itself gives me: Email::MessageID 1.351 R/RJ/RJBS/Email-MessageID-1.351.tar.gz Fun... Anybody have a CPAN contact? -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpUVhf5o1oe0.pgp Description: PGP signature
Re: [gentoo-dev] Testing is not a valid reason to package.mask
On Thu, 2 Oct 2008 17:56:39 -0700 Alec Warner [EMAIL PROTECTED] wrote: If pmask is not for testing...what is it for? The name says it all - to prevent people from automatically emerging stuff, even when ACCEPT_KEYWORDS=~arch is set. First you try for the new version: # emerge -va www-client/opera which doesn't work (it gives you the current version!). Then you try with a specific version: # emerge -va =www-client/opera-9.6* which gives you a good reason to either unmask or not unmask: !!! All ebuilds that could satisfy =www-client/opera-9.6* have been masked. !!! One of the following masked packages is required to complete your request: - www-client/opera-9.60_pre2440 (masked by: package.mask) /keeps/gentoo/portage/profiles/package.mask: # Jeroen Roovers [EMAIL PROTECTED] (26 Aug 2008) # www-client/opera snapshots are masked. Please read # http://my.opera.com/desktopteam/blog/ - www-client/opera-9.60_pre2436 (masked by: package.mask) - [...] If it merely says that the masking is for testing (and especially if testing takes many months and apparently takes place in secret) the whole point is lost on the people who have come so far and still want to press on - they'll simply ignore your warning against testing. There are various valid reasons, but testing means you want to expose stuff, not hide it. There's simply no way you'd package.mask something, and at the same time explain you want it tested. Because you're preventing most ~arch systems from getting automatically widely exposed to the stuff you're intending to get tested. Even saying that it would kill puppies would be more valid. Just be honest and tell people what is going on. Tell them that if they use Opera snapshots, they shouldn't care about losing mail or experience frequent crashes while browsing. Anything really, just don't tell them you're testing or you find yourself excluding them from the party with a really bad excuse. Kind regards, JeR
Re: [gentoo-dev] Testing is not a valid reason to package.mask
On Friday 03 of October 2008 04:14:54 Jeroen Roovers wrote: On Thu, 2 Oct 2008 17:56:39 -0700 Alec Warner [EMAIL PROTECTED] wrote: If pmask is not for testing...what is it for? The name says it all - to prevent people from automatically emerging stuff, even when ACCEPT_KEYWORDS=~arch is set. First you try for the new version: # emerge -va www-client/opera which doesn't work (it gives you the current version!). Then you try with a specific version: # emerge -va =www-client/opera-9.6* which gives you a good reason to either unmask or not unmask: !!! All ebuilds that could satisfy =www-client/opera-9.6* have been masked. !!! One of the following masked packages is required to complete your request: - www-client/opera-9.60_pre2440 (masked by: package.mask) /keeps/gentoo/portage/profiles/package.mask: # Jeroen Roovers [EMAIL PROTECTED] (26 Aug 2008) # www-client/opera snapshots are masked. Please read # http://my.opera.com/desktopteam/blog/ - www-client/opera-9.60_pre2436 (masked by: package.mask) - [...] If it merely says that the masking is for testing (and especially if testing takes many months and apparently takes place in secret) the whole point is lost on the people who have come so far and still want to press on - they'll simply ignore your warning against testing. Same way one may see masked by missing keyword note and interprete as not for your arch... So a quick note in p.mask can say it is for testing purposes, so user can choose either to install it or not. There are various valid reasons, but testing means you want to expose stuff, not hide it. There's simply no way you'd package.mask something, and at the same time explain you want it tested. Because you're preventing most ~arch systems from getting automatically widely exposed to the stuff you're intending to get tested. I don't think it's ok. ~arch isn't training ground. It's supposed to work, so asking arch teams to keywords packages that are not supposed to work isn't good. Even saying that it would kill puppies would be more valid. Just be honest and tell people what is going on. Tell them that if they use Opera snapshots, they shouldn't care about losing mail or experience frequent crashes while browsing. Anything really, just don't tell them you're testing or you find yourself excluding them from the party with a really bad excuse. This is the place i agree with you. Anyway i think package still should be p.masked with good explanation of why it is masked. -- Cheers, Dawid Węgliński
Re: [gentoo-dev] Testing is not a valid reason to package.mask
On Fri, 3 Oct 2008 04:23:33 +0200 Dawid Węgliński [EMAIL PROTECTED] wrote: I don't think it's ok. ~arch isn't training ground. It's supposed to work, so asking arch teams to keywords packages that are not supposed to work isn't good. We have a testing branch and a stable branch, defined by the KEYWORDS variable in the ebuilds. Package.masking stuff saying you're testing is at the least uninformative and highly confusing and unfriendly to would-be testers when in the very same context this already means something different (namely, it's been too short a while, wait one or two months for this version to go stable, as the ~arch keywords would suggest). The same term shouldn't be used to denote two ways of masking ebuilds, but that's beside the point of providing good reasons to package.mask ebuilds. Even saying that it would kill puppies would be more valid. Just be honest and tell people what is going on. Tell them that if they use Opera snapshots, they shouldn't care about losing mail or experience frequent crashes while browsing. Anything really, just don't tell them you're testing or you find yourself excluding them from the party with a really bad excuse. This is the place i agree with you. Anyway i think package still should be p.masked with good explanation of why it is masked. Welcome to the starting point of this thread! ;-) Kind regards, JeR
[gentoo-dev] Re: proj/en/perl/outdated-cpan-packages.xml automatic update
* Robin H. Johnson [EMAIL PROTECTED]: On Thu, Oct 02, 2008 at 06:20:57PM -0700, Robin H. Johnson wrote: To help out the perl team, I converted their up2date-ng script running to be purely automatic from cvs.g.o now, it will run daily at 01h52 UTC. Thanks. If you touch up2date_package.altname or up2date_package.mask please give me a shout so I can ensure updated copies on the server. And something is broken with CPAN, just in time for us :-). Manually browsing give me: http://search.cpan.org/~rjbs/Email-MessageID-1.400/ This version was released yesterday. But using CPAN itself gives me: Email::MessageID 1.351 R/RJ/RJBS/Email-MessageID-1.351.tar.gz It's in here: Last-Updated: Fri, 03 Oct 2008 00:26:55 GMT Email::MessageID 1.400 R/RJ/RJBS/Email-MessageID-1.400.tar.gz
Re: [gentoo-dev] Re: proj/en/perl/outdated-cpan-packages.xml automatic update
On Fri, Oct 03, 2008 at 07:33:11AM +0200, Torsten Veller wrote: * Robin H. Johnson [EMAIL PROTECTED]: On Thu, Oct 02, 2008 at 06:20:57PM -0700, Robin H. Johnson wrote: To help out the perl team, I converted their up2date-ng script running to be purely automatic from cvs.g.o now, it will run daily at 01h52 UTC. Thanks. If you touch up2date_package.altname or up2date_package.mask please give me a shout so I can ensure updated copies on the server. And something is broken with CPAN, just in time for us :-). Manually browsing give me: http://search.cpan.org/~rjbs/Email-MessageID-1.400/ This version was released yesterday. But using CPAN itself gives me: Email::MessageID 1.351 R/RJ/RJBS/Email-MessageID-1.351.tar.gz It's in here: Last-Updated: Fri, 03 Oct 2008 00:26:55 GMT Email::MessageID 1.400 R/RJ/RJBS/Email-MessageID-1.400.tar.gz If you look at the commits that the script made, some of the CPAN mirrors had Email-MessageID-1.400 in the index, but others didn't. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
