Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
Ciaran McCreesh wrote: | Which means you won't be able to satisfy your preemptive | requirement. Not at all. You can warn users repeatedly, but there comes a point when trying to warn them any further becomes futile. Then what is the point of this GLEP? Instead, just warn people through existing intrastructure, which is cheap from an engineering perspective because everything is already there in place, and don't think of implementing all kinds of extras just to warn a user one extra time, since trying to warn them any further becomes futile anyway. The motivation of your GLEP is based solely on the assumption that critical news is not effectively delivered to the user, however, the GLEP implicitly introduces this critical news, so how can it be ignored by users? It's not there. If you don't plan to solve the requirements you state yourself, either don't state them, or make clear you will not satisfy them for what reason. To me it looks as if you just would like to remove the 'preemptive' requirement because it suggests some behaviour that you don't (plan to) implement. And hence, you should also rewrite the motivation to reflect your statement in the quote above. I like the idea of the GLEP, since it will be helpful for many users I think, but the grounds on which and the reasons why should be valid points, IMHO. I also think that the idea comes very close to things proposed and or desired by many users that would like to have all the einfo messages being sent out to them, or accumulated after portage has done it's compiling. See the respective super bug and ml discussions on it. Hence, the GLEP itself doesn't differentiate itself, is not defined to be generic enough or reusable, should include configurability and, last but not least as I mentioned before, should be grounded in valid points. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Release: webapp-config v1.11 - call for testers
Stuart Herbert wrote: Hi, I've just released webapp-config v1.11 into the Portage tree. It Stuart, have you had a chance to look at Bugzilla Bug 101234 regarding webapp-config-1.11-r1 recently? It was opened on 2005-08-03 and there seems to have been no progress on resolving it since it was opened. Thanks. -Kevin -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
Jason Stubbs wrote: I seem to be repeating myself... What's an example of repository-specific non-package-specific news? Why does `emerge --changelog` not suffice for package-specific news? a) maintainers don't put important news in their changelogs. there are a few exceptions. gregkh's udev bumps, for example, always come with an explanation of what changes have been made and what to watch out for. but mostly all the info you're going to get is Version bump., if that. b) there's no way to separate the wheat from the chaff. while i could (and usually do) emerge every update with -l, it's not something anyone with a life would do. the signal to noise ratio is very low, and not many people are going to go through reading the changelogs for every package on the odd chance that there might be some important nugget of info they need to know. combine this with a) and you'd have better luck playing the lottery than getting pertinent information that specifically applies to you. c) it's a passive system the user has to actually make an effort to retrieve this news. we _already_ have a number of different sources that they could be getting important info from. another is not what's needed. what we're looking for is a proactive solution where the news is dropped at their feet below a bigass neon arrow saying READ ME. d) news isn't necessarily package-based. news items could be based on a user's profile, language preference, architecture, USE flags, etc. there could also be general news to the entire community about global changes in Gentoo. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP ??: Critical News Reporting
Nathan L. Adams wrote: Just keep in mind that portage is supposed to be non-interactive and most users like it that way. (Although the countdown when cleaning out old packages kinda breaks that idea, but I digress.) This must be some definition of the word interactive i'm not aware of. ;) Displaying something on the screen for a user to read is not interaction. So just make sure that the scheme doesn't involve forcing the user to notice anything during a 'normal' non-interactive emerge in order for it to be effective. Thats why I keep pushing having a nice GuideXML version in a central location like http://errata.g.o/ and just having emerge output a summary and a link (however/at what point/with what mechanism you decide to actually have portage output it). Forcing the user to see it is exactly the point. There are already many sources for news that the user can go to. We don't need another. And while the idea of having portage give the user a summary and link is a step in the right direction, it'd be even nicer if the message itself was available without an internet connection (ie. kept in the tree). --de. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sat, 2005-11-05 at 13:58 +0100, Grobian wrote: A lot Gentoo users I know read gentoo-announce and the GWN. But *many* more don't. That's what we learned from the Apache package refresh, and what we've also learned from the PHP5 work. Works fine for me. What works for you is irrelevant to this conversation. What matters is getting news out to 100% of our userbase - or as near to that as possible. Saying that it works for you, and so there isn't a problem, isn't a useful contribution. The GLEP *is* targetted at a certain group of people It is targeted at every single Gentoo user. Without exception or discrimination. What the GLEP does is twofold: 1. Suggest special (**important**) news items to be accepted within Gentoo, and them being stored somewhere 2. Desparately push this news to users, because it seems that they don't read information which is not available (yet! see 1). The information was available via several sources, but this did not reach a wide enough audience. As a result, we're proposing a new mechanism for delivering news - one that we believe will be much more successful. So thank you for letting me realise that this GLEP should be splitted in two. No thanks. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
Stuart Herbert posted [EMAIL PROTECTED], excerpted below, on Sun, 06 Nov 2005 20:37:14 +: On Sat, 2005-11-05 at 13:58 +0100, Grobian wrote: A lot Gentoo users I know read gentoo-announce and the GWN. But *many* more don't. That's what we learned from the Apache package refresh, and what we've also learned from the PHP5 work. While I agree with the point you make, I don't believe the apache upgrade issues were announced on the announce list. The news in the tree thing is a good idea, IMO, but it'll take some time to implement. Earth changing (for some Gentoo users) announcements can and should go to announce -- that's what it's there for. If I'm wrong about the apache upgrade, and it /was/ on announce, and I just forgot about seeing it /there/ as I had already seen it discussed here, which I /do/ remember, great! I just don't recall seeing it there, and tho I don't run apache myself, am of the opinion changes as big as those described for apache /should/ have been on announce. -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
On Sun, 06 Nov 2005 14:38:47 -0700 Duncan [EMAIL PROTECTED] wrote: | While I agree with the point you make, I don't believe the apache | upgrade issues were announced on the announce list. The news in the | tree thing is a good idea, IMO, but it'll take some time to | implement. Earth changing (for some Gentoo users) announcements | can and should go to announce -- that's what it's there for. Why should every user have to sign up to be spammed with irrelevant GLSAs and news items for packages which they do not use? -- Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpdc639kxuBP.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sun, 06 Nov 2005 09:33:50 +0100 Grobian [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | | Which means you won't be able to satisfy your preemptive | | requirement. | | Not at all. You can warn users repeatedly, but there comes a point | when trying to warn them any further becomes futile. | | Then what is the point of this GLEP? Instead, just warn people | through existing intrastructure, which is cheap from an engineering | perspective because everything is already there in place, and don't | think of implementing all kinds of extras just to warn a user one | extra time, since trying to warn them any further becomes futile | anyway. The current warning levels we have are insufficient. This GLEP proposes a new system for warnings which will be far harder to accidentally ignore. There are, however, limits to how far we can reasonably go before we make the solution worse than the problem. -- Ciaran McCreesh : Gentoo Developer (Anti-XML, anti-newbie conspiracy) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpAG3JaHAolH.pgp Description: PGP signature
Re: [gentoo-dev] GLEP ??: Critical News Reporting
On Fri, 4 Nov 2005 22:50:42 +0100 Jan Kundrát [EMAIL PROTECTED] wrote: On Friday 04 of November 2005 02:50 Lance Albertson wrote: After reading through the heated thread, I have yet to see your valid point of pushing xml for such a simple task. All I have seen is two 3rd grade kids arguing over a swing set. Please give some calm reasons for your opinion instead of voicing things in such a heated manner. Making assumptions about someone else's opinions gets you no where. Well, my point is that our GLSAs and the associated code already handles stuff very similar to the `emerge --news` idea, namely: a) displaying info only for users having affected package b) support for arch-specific issues c) version-specific messages d) instructions on how to make a workaround and how to fix the problem permanently All of these steps are more or less trivial, there is little to no gain in reusing glsa related code. Moving the relevant code from glsa.py to some other location would be more work that rewriting these parts. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. pgpDzaq8lgkwl.pgp Description: PGP signature
[gentoo-dev] use.defaults ( auto-use )
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Could we by chance, mandate some sort of comment field in that file not unlike package.mask? I usually like to know the reason why these flags are being switched on. Certainly there are some flags that I don't mind and there are others where I just have to wonder why the hell it's in use.defaults in the first place. I'm also a bit worried that things were placed in there a while ago and are no longer needed, may also be a good idea to date the entries. - -Alec Warner (antarus) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ278wWzglR5RwbyYAQIauA//bRjPMeA001oaclmvIYT7i+dDUPbsSW0O xm+4hF1rKj6ip9VyQJyNXAMvh858ZdgNAmQxUlA62fMQFXmvz/KgRKgteeIgHztW vp7PnbW0hN3vTRiGXkOgsZJoDxoqVLcdcup0sN3EmEyOofwjHNPH7WGnn/hj4g3d XcS8TB2wWsA9lTJUV3+Jh9ZYt2ou6Qg6Nyruz9C8AKTWQWfPd3CCb/840nFIHBvy ehZcSg+oAmGQMxaIRN4GnaHwkWlz3BP7qcn6mEBdPxMKM0H3elN/uKcT+RiPr86m Hw+H0zdofxp2UEyHi81iOJT2ndxqKORUHcZZ39AnGeMCmp777j6tcTwqGuaTqmKX Y1ievL9MyYp8jQleT9CPOIJmeMAiJzZXXwHS+i0o+FAWezzDB1byi5TSuzFGHPPn OBZsRgdrre/q3KuPqVGzr0KLy2YJYw1G0/3dMvDaokAn1XGm50RzP+nFkE5fLbtQ /IMgj9iNFLSR/TOe2X9vYzyZMMCfoptC03RCUZVyqM5h92ghOjQzLX8Qw8Wr39Kf KWHyg9eQKsHfioKZFGKsT623QaL0BzNuRpScbzXk89J9sdGGZIXGYE/ScQD74UAe 96GZl6wiex31DSByf8npKmbos4ez7GIYg1IV6rQSWgVOwamumesustDZfWY/UhtR 71CNIE1d3kk= =wtV6 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 Critical News Reporting Round Two
On Sunday 06 November 2005 13:38, Duncan wrote: I don't believe the apache upgrade issues were announced on the announce list. For the record, it was sent to the announce list on 2004-12-24. Message-Id: [EMAIL PROTECTED] Subject: [gentoo-announce] Apache packages refresh on 8th January 2005 pgpEpoIKfKkeT.pgp Description: PGP signature
Re: [gentoo-portage-dev] handling config stuff in portage (for package compression, etc)
On Sat, 5 Nov 2005 20:58:57 -0600
Jason Pepas [EMAIL PROTECTED] wrote:
So, I have been going over how class config works in portage, but I
am still unsure of where to fit in the changes I would need.
I suppose I'll lay out the structure of what I had in mind and ask
y'all for advice.
Compression would be supported in a modular fashion. The following
config options would be supported for each type of compression:
ZEXT - the compression filename extension
TZEXT - the binary package filename extension
ZCOMPRESS - the command used to compress a file
ZDECOMPRESS - the command used to uncompress a file
ZFILTER - command used to compress in a pipeline
ZUNFILTER - command used to uncompress in a pipeline
ZRECOMPRESS - should files already compressed using another method be
uncompressed and then recompressed using the preferred method? (ie, if
manpages are shipped as foo.1.gz and you want foo.1.bz2)
I really don't like this Z prefix, should rather be
PORTAGE_COMPRESS_{EXT,BINEXT,COMPRESSCOMMAND,...}
(avoid env namespace pollution a IMO a lot cleaner)
For example, if Z=bzip2, a file would be sourced (bzip2.sh), which
would contain the these settings:
ZEXT=bz2
TZEXT=tbz2
ZCOMPRESS=bzip2
ZDECOMPRESS=bunzip2
ZFILTER=bzip2
ZUNFILTER=bunzip2
ZRECOMPRESS=no
Why this indirection? Just for convienience or are there technical
reasons? If it's just convienience then you don't need this, just
utilize the source command in make.conf. Anyway, there is no place for
one-letter vars in make.*
The following subsystems would source one of these files to get
their settings:
PKG_
DOC_
MAN_
INFO_
possibly others.
So, if PKG_Z=bzip2, bzip2.sh would be read to set PKG_ZEXT,
PKG_TZEXT, PKG_ZCOMPRESS, etc.
Why are those vars needed? Can't they be directly derived from the
global ones?
As these module files are sourced, individual config options could be
overridden via values in the environment. For example, if I wanted
gzip used across the board, but I wanted different levels of
compression for man pages and packages, I could do this in make.conf:
Z=gzip
PKG_ZCOMPRESS=gzip --best
MAN_ZCOMPRESS=gzip --fast
Somehow this part looks like overengineering to me. Doesn't seem worth
to introduce 7*4=28 new vars just for this.
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
pgpw5V5iOCAyQ.pgp
Description: PGP signature
Re: [gentoo-portage-dev] branches/2.0 moved to trunk
On Sun, Nov 06, 2005 at 05:40:26PM +0900, Jason Stubbs wrote: I've moved trunk/ to branches/2.1-experimental/ and branches/2.0 to trunk/. Make sure to update before doing any changes... i thought 2.1 / trunk was dead ? why not just punt it and be done ? -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] branches/2.0 moved to trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: On Sun, Nov 06, 2005 at 05:40:26PM +0900, Jason Stubbs wrote: I've moved trunk/ to branches/2.1-experimental/ and branches/2.0 to trunk/. Make sure to update before doing any changes... i thought 2.1 / trunk was dead ? why not just punt it and be done ? -mike IIRC, people are still backporting things... I was going to look at confcache and porting it to 2.0... if I ever find the time and subsequent motivation ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ266+WzglR5RwbyYAQJ8QA//TvHlyjct0mwXDjqm0jRjFQfUuyyQ46UC vR2CMnYgUMwnljsx3bbhecNczy5o6cwLMvsPEq4MthDJm3AUmlHNkLrj/+ZySpDM IC0/ZzJcFIf9kOXzNOV7lWCJUU/118UIM6I/eaxj5LJCENJZ2BzVTRTgozFJuoaX xKgOr1M6JCd0sMGFfclnwdoI8qjIFxV+gYS9qzhAhWN4T/NtdTFfbyNIso0pgVtD OG8T0pKetsrz/5WU/YuUs0EqEC+KaZH8H0n8YFAF+q90NnjRwJjAefrU0AhgYeml ZX8ZUhFMXVCfs7iXaPLNwcYp5HA5mbTBp8Oi5H6vjkJFl6bZ5CQE91SqseyW6ZZR T+cgxzO7WG5bJ72FQJbzjXgGHrtZfODoolgQPE1+uO+Z6bKWH0EK3hQpvXOFX680 oqAZGnzD42Yi5t8EVF7yHRPNU3r99EnbZBGl1xKnRWJnBIHd6tqRizubuoxkolwP aQjWN6OwLnVJ/t5JSe7axVJJlggS7Dr1+1Fi7Cx5EIxviJbbxmwjc0bgl/s8mVJZ ew8dFuyXTBqBc+qPC9phRnhisp/xH0R9OzoiTp/4Da7bR49AU5AWUEEwhiUzziiq N6XNQKVpD0db41gKhvXDUNs2czXhfeKpUz/woAPr2+QUkHVHGFFtedVlh4Y1Cxyg Zy48JG1SWUM= =TWpq -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] branches/2.0 moved to trunk
On Sun, Nov 06, 2005 at 09:24:58PM -0500, Alec Warner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: On Sun, Nov 06, 2005 at 05:40:26PM +0900, Jason Stubbs wrote: I've moved trunk/ to branches/2.1-experimental/ and branches/2.0 to trunk/. Make sure to update before doing any changes... i thought 2.1 / trunk was dead ? why not just punt it and be done ? IIRC, people are still backporting things... I was going to look at confcache and porting it to 2.0... if I ever find the time and subsequent motivation ;) i'm backporting things to 2.0 from trunk only because i didnt know trunk was dead ... otherwise, i think people are backporting from savior/3.0, not from trunk/2.1 -mike -- gentoo-portage-dev@gentoo.org mailing list
