Re: [gentoo-dev] Re: Concerns about WIPE_TMP change
On Saturday 19 January 2008, Olivier Galibert wrote: > On Sat, Jan 19, 2008 at 10:18:35PM +, Duncan wrote: > > Richard Freeman <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], > > > I think that this would probably warrant an elog. Sure, anybody who > > > knows the "correct" way to admin unix doesn't put anything important in > > > /tmp - but educating our users before blowing away their data isn't a > > > bad thing. We shouldn't assume our users are idiots, but this is an > > > obscure enough piece of admin knowledge that I think that users will be > > > impacted by the change. > > > > Obscure? It's the directory name (says another with both /tmp and /var/ > > tmp on tmpfs). How much less obscure can you get than announcing it > > every time the path is referenced or specified? Who could reasonably > > argue that tmp doesn't mean tmp? > > Tmp has never meant "erase at restart", because restarts are often not > predictable. Tmp has sometimes meant things like "erased after a > week", or "erased when space gets low", but never "erased after > restart" which is just unusable. dont know where you get this "unusable" business from. ive never had a problem with it and ive been using WIPE_TMP since i introduced it which has been over a year (maybe two or three). nor has it been a problem for everyone who mounts /tmp as a tmpfs. nor anyone else who uses /tmp correctly. > Frankly, if I'm writing a long email (which mutt stores in /tmp) and a > powerloss makes it gone even if I was saving it from time to time > while I was writing it, I'll get annoyed. Severely annoyed. i dont know what sort of magic you think is going on behind the scenes. there is no guarantee that mutt will write every byte after you type it, flush the I/O buffer, and make sure it gets synced to the disc. or that the kernel has actually synced it to the disk. or that the disk has actually written it out of its own I/O buffer to the drive. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]
Stefan de Konink <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 20 Jan 2008 00:17:55 +0100: > ...very offtopic but how are you all compiling stuff like firefox on a > ram disk. Or is 8GB of ram very cheap suddenly? Well, tmpfs is swap-backed if necessary. That's one of its strengths. And no, 8 gig of at least registered memory (what my Opterons use) isn't cheap -- I paid >$1000 for mine a year or so ago, but it sure is nice, combined with a dual dual-core system (Opteron 290s, upgraded ~4 months ago from 242s). MAKEOPTS="-j20 -l12" keeps things from getting too out of hand. It'll sometimes use 3 gigs or so of app memory (and about the same tmpfs it appears), but not too bad. I ran -j (unlimited jobs) for awhile, and it's fun to see the jobs climb to several hundred, but even with 16 gigs 4-way striped swap, the system goes draggy at that and >10 gigs into swap. Keeping it to ~12 jobs means responsiveness stays reasonable, at least with the new 2.6.24 user based scheduling and the portage user kept to the same or half the share of my regular user. Swap seldom gets used, and if it does, it's only a few megs of the apps I don't use much anyway (/proc/sys/vm/swappiness set to 100 so it flushes apps, not cache, to swap, as apps and the main system are on raid-6 so only two-way striped while swap is 4-way striped). Nice system to run Gentoo on. =8^) Using ccache, recompiling the updated kde4-svn daily is only ~2 hours or so, during which the system remains pleasantly usable. =8^) -- 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 -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Alec Warner schreef: >> But who compiles firefox? :) Probably everyone that noticed that the segmentation faults coming from the precompiled versions are annoying? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkpfdYH1+F2Rqwn0RCjLoAJ9dA6BN/2011ed1IFZ9aabPqoRtFQCeJAsF w8Pf3sgIwIyDQwQNY/O6t10= =PqIa -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]
On 1/19/08, Stefan de Konink <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Duncan schreef: > > Richard Freeman <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], > > excerpted below, on Sat, 19 Jan 2008 07:55:53 -0500: > > > > Obscure? It's the directory name (says another with both /tmp and /var/ > > tmp on tmpfs). > > ...very offtopic but how are you all compiling stuff like firefox on a > ram disk. Or is 8GB of ram very cheap suddenly? 8gb is very cheap. But who compiles firefox? :) > > > Stefan > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.7 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHkoUjYH1+F2Rqwn0RCiGcAKCFWHbUfmXHA6OJ47owQ23ACpfMFwCfVqFf > tQ5D4kN+U2Oxs8WjaCl8FP0= > =5UKn > -END PGP SIGNATURE- > -- > gentoo-dev@lists.gentoo.org mailing list > > -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Concerns about WIPE_TMP change
Olivier Galibert wrote: Tmp has never meant "erase at restart", because restarts are often not predictable. Tmp has sometimes meant things like "erased after a week", or "erased when space gets low", but never "erased after restart" which is just unusable. >> POSIX wrote: /tmp A directory made available for applications that need a place to create temporary files. Applications shall be allowed to create files in this directory, but shall not assume that such files are preserved between invocations of the application. Frankly, if I'm writing a long email (which mutt stores in /tmp) and a powerloss makes it gone even if I was saving it from time to time while I was writing it, I'll get annoyed. Severely annoyed. It's just another bug of the FHS that shoule be ignored. The only one you would have to get annoyed at is yourself. Every spec out there says you don't store persistent info on /tmp. Use /var/tmp if you want to keep things between boots. That's why it's there. :P -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Concerns about WIPE_TMP change
On Sat, Jan 19, 2008 at 10:18:35PM +, Duncan wrote: > Richard Freeman <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], > excerpted below, on Sat, 19 Jan 2008 07:55:53 -0500: > > > I think that this would probably warrant an elog. Sure, anybody who > > knows the "correct" way to admin unix doesn't put anything important in > > /tmp - but educating our users before blowing away their data isn't a > > bad thing. We shouldn't assume our users are idiots, but this is an > > obscure enough piece of admin knowledge that I think that users will be > > impacted by the change. > > Obscure? It's the directory name (says another with both /tmp and /var/ > tmp on tmpfs). How much less obscure can you get than announcing it > every time the path is referenced or specified? Who could reasonably > argue that tmp doesn't mean tmp? Tmp has never meant "erase at restart", because restarts are often not predictable. Tmp has sometimes meant things like "erased after a week", or "erased when space gets low", but never "erased after restart" which is just unusable. Frankly, if I'm writing a long email (which mutt stores in /tmp) and a powerloss makes it gone even if I was saving it from time to time while I was writing it, I'll get annoyed. Severely annoyed. It's just another bug of the FHS that shoule be ignored. OG. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Duncan schreef: > Richard Freeman <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], > excerpted below, on Sat, 19 Jan 2008 07:55:53 -0500: > > Obscure? It's the directory name (says another with both /tmp and /var/ > tmp on tmpfs). ...very offtopic but how are you all compiling stuff like firefox on a ram disk. Or is 8GB of ram very cheap suddenly? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkoUjYH1+F2Rqwn0RCiGcAKCFWHbUfmXHA6OJ47owQ23ACpfMFwCfVqFf tQ5D4kN+U2Oxs8WjaCl8FP0= =5UKn -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Concerns about WIPE_TMP change
Richard Freeman <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 19 Jan 2008 07:55:53 -0500: > I think that this would probably warrant an elog. Sure, anybody who > knows the "correct" way to admin unix doesn't put anything important in > /tmp - but educating our users before blowing away their data isn't a > bad thing. We shouldn't assume our users are idiots, but this is an > obscure enough piece of admin knowledge that I think that users will be > impacted by the change. Obscure? It's the directory name (says another with both /tmp and /var/ tmp on tmpfs). How much less obscure can you get than announcing it every time the path is referenced or specified? Who could reasonably argue that tmp doesn't mean tmp? Never-the-less, an elog wouldn't hurt, and the implementation cost is pretty low as well, so I'd say just elog it. That way, there's two warnings to point to instead of just one (the name of the dir), for the inevitable complaints. -- 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 -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Concerns about WIPE_TMP change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Mike Frysinger schreef: > i can add an elog, but the arguments for not turning it on by default are far > from convincing Please, only do this, and I'll stop about this subject. :) So something like *beep*beep*beep* /tmp will now by default cleaned upon restart, this behavior is configurable in /etc/conf.d/bootmisc. For more permanent temporary storage use /var/tmp. For more information about /tmp look at: http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkmzDYH1+F2Rqwn0RCvVLAJ95si3oUVrzvmvhyozzYcqf58UJEwCfYCz7 Ieark6Y+rPn+Q7NKH9ZB8lU= =xkJy -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Upcoming Infra maintenance/downtimes: anon{cvs,svn,git}, archives, bouncer, overlays
On 19-01-2008 15:50:09 -0500, Mike Frysinger wrote: > i'm not suggesting you *not* provide the proper svn:// and git:// ones. i'd > always use those myself when possible (as performance is a ton better as ive > seen many times). i'm suggesting we provide both and tell people to use > svn:// and git://, but if you're behind a stupid firewall, there is also > http:// available. I know of at least two cases where people have to go through a (corporate) firewall, so I fully second this suggestion. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Concerns about WIPE_TMP change
On Saturday 19 January 2008, Stefan de Konink wrote: > Mike Frysinger schreef: > > On Saturday 19 January 2008, Roy Marples wrote: > >> On Sat, 2008-01-19 at 02:48 +0100, Stefan de Konink wrote: > >>> In my opinion WIPE_TMP should be in the same state > >>> as RC_PARALLEL_STARTUP. > >> > >> That's a fair point. > > > > how ? these two options are not related in the slightest. > > Because both options should be enabled manually under the presumption if > one knows what one is doing. Potential dataloss vs Potential boot > problems, I think that is the same ball park. as Roy points out, parallel startup is stabilized which means it will be enabled by default WIPE_TMP had already been moved to yes by default in baselayout-2, i just got tired of waiting i can add an elog, but the arguments for not turning it on by default are far from convincing -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Concerns about WIPE_TMP change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Mike Frysinger schreef: > On Saturday 19 January 2008, Roy Marples wrote: >> On Sat, 2008-01-19 at 02:48 +0100, Stefan de Konink wrote: >>> In my opinion WIPE_TMP should be in the same state >>> as RC_PARALLEL_STARTUP. >> That's a fair point. > > how ? these two options are not related in the slightest. Because both options should be enabled manually under the presumption if one knows what one is doing. Potential dataloss vs Potential boot problems, I think that is the same ball park. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkmWYYH1+F2Rqwn0RCsuKAJ9JYYk75AU0DkmDKV7nS/MPdeNLRACeIaIl jZnOJaxMD4MnO0wGS4JnZSk= =fK5B -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Upcoming Infra maintenance/downtimes: anon{cvs,svn,git}, archives, bouncer, overlays
On 1/19/08, Mike Frysinger <[EMAIL PROTECTED]> wrote: > using https:// to secure your data here is the wrong way to go. if you have a > man-in-the-middle attacking you, they can do a lot more than inject crap into > your syncs, some of which you wouldnt even notice. for the topic at hand, > this topic does not matter i think. The https solves man-in the middle for svn/git sync. There is an option for rsync people (not to use it): http://bugs.gentoo.org/show_bug.cgi?id=130039 Best Regards, Alon Bar-Lev. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Concerns about WIPE_TMP change
On Saturday 19 January 2008, Roy Marples wrote: > On Sat, 2008-01-19 at 02:48 +0100, Stefan de Konink wrote: > > In my opinion WIPE_TMP should be in the same state > > as RC_PARALLEL_STARTUP. > > That's a fair point. how ? these two options are not related in the slightest. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Upcoming Infra maintenance/downtimes: anon{cvs,svn,git}, archives, bouncer, overlays
On Friday 18 January 2008, Robin H. Johnson wrote: > On Sat, Jan 19, 2008 at 12:26:44AM +0200, Alon Bar-Lev wrote: > > On 1/18/08, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > On Thursday 17 January 2008, Robin H. Johnson wrote: > > > > anonvcs.gentoo.org: anoncvs, anonsvn, anongit > > > > - Anonymous SVN is changing from http:// to svn:// [1] > > > > overlays.gentoo.org [3]: > > > > - Anonymous SVN is changing from http:// to svn:// > > > > > > i'd point out that http:// syncing is usable from behind firewalls > > > while svn:// is not ... while this does not affect me personally, it's > > > something to keep in mind. > > > -mike > > > > Just wanted to note this too... I am one of the affected ones... > > I think that it is very important to have http, and even https for > > formal resources. > > git://, svn://, rsync:// or ssh+X:// are inaccessible for a large > > group of users. > > My core concern with the SVN http://, was the crappy performance it > provided compared to svn://. The main rsync tree has never been > available for iterative syncing via http://, just had tarball snapshots > and deltas instead. i'm not suggesting you *not* provide the proper svn:// and git:// ones. i'd always use those myself when possible (as performance is a ton better as ive seen many times). i'm suggesting we provide both and tell people to use svn:// and git://, but if you're behind a stupid firewall, there is also http:// available. > > Also using none secured protocols, exposes users to man-in-the-middle > > attacks. > > The existing http:// had this problem already, it's not a new one. > git:// and svn:// do both have patches around adding support for adding > TLS. This however just adds overhead, I really need to finish the > tree-signing work I was doing, as that protects the content better (MITM > is still possible on SSL without it, just a lot harder as an attacker > has to deal with the SSL stream first). using https:// to secure your data here is the wrong way to go. if you have a man-in-the-middle attacking you, they can do a lot more than inject crap into your syncs, some of which you wouldnt even notice. for the topic at hand, this topic does not matter i think. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
On Sat, 19 Jan 2008 16:24:53 +0100 "Denis Dupeyron" <[EMAIL PROTECTED]> wrote: > On Jan 19, 2008 2:07 PM, Tiziano Müller <[EMAIL PROTECTED]> wrote: > > Your oppinion? > > Would this be the right time to discuss about moving other variables > to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those > hardly change and if they ever do we can restrict them to specific > versions. I know there could be technical hurdles, but what do you > think of the idea at least ? At least LICENSE is no go, since the package manager needs it. Having DESCRIPTION and HOMEPAGE available to the package manager even when XML goes splat is probably useful too... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] rgb file specification
On Sat, Jan 19, 2008 at 05:43:18PM +, Ferris McCormick wrote:
> This is random musing based based on perhaps my own problems.
> I need a local color.file to see well what I have going on, and
> current xorg ignores that. Thus, at every build, there is in
> oscolor.c a "constant" I must change from 1 to 0.
While I don't have any need for your specific change, I do have the same
problem with some other unrelated patches for unrelated packages. Instead
of manually changing the code for every version bump, you can set up your
bashrc to define a post_src_unpack function, which checks if
${CATEGORY}/${PN} == x11-base/xorg-server, and if so, applies the patch.
solar's old bashrc which does this is still found at
, and I've put up the function as
I'm using it at .
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: rgb file specification
Ferris McCormick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This is random musing based based on perhaps my own problems. > I need a local color.file to see well what I have going on, and > current xorg ignores that. Thus, at every build, there is in > oscolor.c a "constant" I must change from 1 to 0. > I don't understand why this is an issue for "every build"; surely a patched ebuild in local overlay is trivial? It's only a quick sed -i line added. > This is frustrating, especially since the fix is completely trivial > on a USE or configure flag. As best as I can tell, xorg people have > ignored my request, although it it is real. > > I am asking if anyone cares if one can give a local rgb file or not, > or if I am stuck with "fixing" every update so that it will take mine > so that I can see it. Perhaps no one cares but me. Well, so be it, > but it slows down xorg-server testing (or upgrading) for me because I > have to keep changing that file by hand. I'm really tired of > fixing this trivial thing by hand. > Fair enough for upgrades, it might be worth adding to the ebuild; I certainly agree user control of rgb is worth having. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] rgb file specification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is random musing based based on perhaps my own problems. I need a local color.file to see well what I have going on, and current xorg ignores that. Thus, at every build, there is in oscolor.c a "constant" I must change from 1 to 0. This is frustrating, especially since the fix is completely trivial on a USE or configure flag. As best as I can tell, xorg people have ignored my request, although it it is real. I am asking if anyone cares if one can give a local rgb file or not, or if I am stuck with "fixing" every update so that it will take mine so that I can see it. Perhaps no one cares but me. Well, so be it, but it slows down xorg-server testing (or upgrading) for me because I have to keep changing that file by hand. I'm really tired of fixing this trivial thing by hand. Regards, - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel, Userrel) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHkjbaQa6M3+I///cRAm3NAJ4oWcvMcAYSn+MxAg+RBNiRAC6+AACghTHr QvlQV65GYVva2FHttZmnyQU= =HzFW -END PGP SIGNATURE- éí¢^¾X¬¶È Ú(¢¸&j)b b²
[gentoo-dev] Last rites: dev-java/jsx
+# Petteri Räty <[EMAIL PROTECTED]> (19 Jan 2008) +# Commercial application for which the devs don't have +# licenses. Lagging behind in versions. If you want to +# see this maintained contact [EMAIL PROTECTED] for paying +# us a license. Otherwise in junkyard after 30 days. +dev-java/jsx + Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] list masked for removal
Stefan Schweizer wrote: # Stefan Schweizer <[EMAIL PROTECTED]> (19 Jan 2008) # Project abandoned. Masked for removal, bug 206105 sys-apps/list Phew I thought this meant the gentoo-dev list was masked for removal -- Hey I just woke up, it's funny!! -- Fieldy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Upcoming Infra maintenance/downtimes: anon{cvs,svn,git}, archives, bouncer, overlays
Robin H. Johnson kirjoitti: On Fri, Jan 18, 2008 at 06:41:44PM +0100, Christian Faulhammer wrote: 2. Trac doesn't scale well enough, as users of the existing overlay machine have noted performance problems before. Being replaced with ViewVC and as yet undecided which Wiki application. Am I right that Wiki content is not migrated? We do want to migrate the content, either by just putting up static snapshots, or actively moving it. dokuwiki is a contender at the moment, because the Java guys already use it, and I have a personal interest in MediaWiki (as I've hacked on that codebase before) - but either way, this is quite a way further down my list of things to do, at least 2 weeks away at this point. We do? Regards, Petteri -- Gentoo/Java project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml
Mark Loeser wrote:
> Tiziano Müller <[EMAIL PROTECTED]> said:
>>
>> Current state: "Deferred"
>> Wanted state: "Accepted/Implemented" (at least by me)
>
> Yea, this sounds like a good thing from reading over the GLEP, unless
> I'm missing some glaring problems with it.
>
>> Open questions from last discussion (March 2006):
>> - Is it possible/should it be possible to have more than one
>> entry?
>
> Yea, agree.
>
>> - Is recording an upstream-status (active/inactive) a good idea?
>> Possibilities:
>> An element: {active/inactive}
>> An attribute: ...
>
> Definately. We have several packages in the tree that once they become
> broken, we'd have to start developing ourselves. This will help the
> treecleaner project as well so they can tell if a package has several
> open bugs and upstream is inactive, its a very good candidate for
> getting booted from the tree.
>
>> - Is an additional element needed to link to upstream docs
>
> Sounds reasonable.
>
>> - Must the type of be controlled/listed/checked?
>
> I'd say we should come up with a good list to start with. We can come
> up with updates to the allowed values at a later date, but I do think we
> should keep this under control.
Ok, agreed.
Where should we keep that list?
Something like "gentoo-x86/metadata/dtd/upstream-tags.dtd" ?
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] list masked for removal
# Stefan Schweizer <[EMAIL PROTECTED]> (19 Jan 2008) # Project abandoned. Masked for removal, bug 206105 sys-apps/list -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml
Denis Dupeyron wrote: > On Jan 19, 2008 2:07 PM, Tiziano Müller <[EMAIL PROTECTED]> wrote: >> Your oppinion? > > Would this be the right time to discuss about moving other variables > to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those I'd rather like to see it in a new thread since it involves changes to the PMS. > hardly change and if they ever do we can restrict them to specific > versions. I know there could be technical hurdles, but what do you > think of the idea at least ? But it ties the ebuild closer to the metadata and if you get an ebuild without HOMEPAGE, DESCRIPTION and LICENSE you don't have any information about the package. I'd say that those vars are the minimal needed information for a package and should therefore being kept in the ebuild itself. But a longer description or a description in a different language can always be kept in metadata.xml as it is possible already. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Ebuild quiz and staff quiz updated to reflect mailing list changes
Regards, Petteri [EMAIL PROTECTED] ~/proj-en/devrel/quiz $ cvs diff Index: ebuild-quiz.txt === RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/quiz/ebuild-quiz.txt,v retrieving revision 1.8 diff -u -r1.8 ebuild-quiz.txt --- ebuild-quiz.txt 1 Aug 2007 20:10:29 - 1.8 +++ ebuild-quiz.txt 19 Jan 2008 15:39:12 - @@ -1,11 +1,12 @@ Ebuild development quiz -Revision 1.2 - 10 April 2007 +Revision 1.3 - 19 January 2008 Answer in whatever length necessary for completeness. Review documentation. Consult your mentor if you're unable to locate answers. *** Organizational structure questions -1. When is it appropriate to post to gentoo-core rather than gentoo-dev? +1. When is it appropriate to post to the following mailing lists: gentoo-core, + gentoo-dev, gentoo-dev-announce, gentoo-project? 2. Who should be contacted with complaints about specific developers or projects? Index: staff-quiz.txt === RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/quiz/staff-quiz.txt,v retrieving revision 1.6 diff -u -r1.6 staff-quiz.txt --- staff-quiz.txt 1 Aug 2007 20:10:29 - 1.6 +++ staff-quiz.txt 19 Jan 2008 15:39:12 - @@ -1,11 +1,12 @@ Non-ebuild staff quiz -Revision 1.3 - 10 April 2007 +Revision 1.4 - 19 January 2008 Answer in whatever length necessary for completeness. Review documentation. Consult your mentor if you're unable to locate answers. *** Organizational structure & policy questions -1. When is it appropriate to post to gentoo-core rather than gentoo-dev? +1. When is it appropriate to post to the following mailing lists: gentoo-core, + gentoo-dev, gentoo-dev-announce, gentoo-project? 2. Who should be contacted with complaints about specific developers or projects? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
On Jan 19, 2008 4:24 PM, Denis Dupeyron <[EMAIL PROTECTED]> wrote: > On Jan 19, 2008 2:07 PM, Tiziano Müller <[EMAIL PROTECTED]> wrote: > > Your oppinion? > > Would this be the right time to discuss about moving other variables > to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those > hardly change and if they ever do we can restrict them to specific > versions. I know there could be technical hurdles, but what do you > think of the idea at least ? > I'm not sure about HOMEPAGE and DESCRIPTION, but I think LICENSE should be per-ebuild variable. A license change is not so strange (GPL-3, double licensing the source, or adding new artwork licensed with a more restrictive license). Moreover, a license change does not need to be retroactive, so using a global variable in metadata.xml could lead to accidentally show a wrong license for old versions. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
On Jan 19, 2008 2:07 PM, Tiziano Müller <[EMAIL PROTECTED]> wrote: > Your oppinion? Would this be the right time to discuss about moving other variables to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those hardly change and if they ever do we can restrict them to specific versions. I know there could be technical hurdles, but what do you think of the idea at least ? Denis.
Re: [gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml
On Jan 19, 2008 4:13 PM, Tiziano Müller <[EMAIL PROTECTED]> wrote:
> >> Possibilities:
> >> An element: {active/inactive}
> >
> > Status of what? seeing you have proposed a upstream-status and a
> > maintainer status. what else is there left to status :P
> There will be a tag within the , not the
> same as our already existing
>
> But the question I tried to express (probably not clear enough) is:
> Should (if at all) the status being tracked for or for
> (within upstream).
>
> As an example "dev-libs/xmlwrapp": The original maintainer is inactive, but
> there is a new one who took the package to sourceforge and it's not a fork
> since the original maintainer agreed up on this. Should such a case be
> tracked at all?
>
I think we don't want to track if previous maintainer is active or
not, or if it's changed. In your example, the important data is "who
is the current maintainer and how to contact him" and "is she
active?". Keeping an entry for the old maintainer as inactive when
there's a new one is not like an useful piece of info.
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
��í¢^�X��� ��(��&j)b�b�
[gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml
Alistair Bush wrote:
>
>
> Tiziano Müller wrote:
>> Current state: "Deferred"
>> Wanted state: "Accepted/Implemented" (at least by me)
>>
>> Open questions from last discussion (March 2006):
>> - Is it possible/should it be possible to have more than one
>> entry?
>
> Yes
>
>> - Is recording an upstream-status (active/inactive) a good idea?
> Maybe, leaning to No.
>
> What about packages that have multiple slots, e.g php-4, php-5? one
> slot could be inactive the other not, does that make upstream active?
Well, upstream for php-4 is not inactive (it still exists but answers with
a "won't fix" if you report a bug for php-4).
But there might be a case that there are two maintainers of different
branches of a software. Doesn't seem like a common case, does it?
Nevertheless: ideas?
>
>> Possibilities:
>> An element: {active/inactive}
>
> Status of what? seeing you have proposed a upstream-status and a
> maintainer status. what else is there left to status :P
There will be a tag within the , not the
same as our already existing
But the question I tried to express (probably not clear enough) is:
Should (if at all) the status being tracked for or for
(within upstream).
As an example "dev-libs/xmlwrapp": The original maintainer is inactive, but
there is a new one who took the package to sourceforge and it's not a fork
since the original maintainer agreed up on this. Should such a case be
tracked at all?
>
>> An attribute: ...
> No. As i'm pretty sure that every inactive maintainer won't go around
> updating their packages metadata.xml
Not talking about the existing tag, sorry.
>
>> - Is an additional element needed to link to upstream docs
> Interesting. what about the situation where upstream documentation sucks
> but there is a "better" resource provided by a third party, could we
> link to that? e.g. http://tldp.org for bash is an excellent resource
> Multiple doc links?
> could provide
> that. Only concern I see is that this could relate to an endorsement of
> thirdparty websites, which may change negatively ( porn on tldp.org ) or
> my just become outdated.
>
> Actually without the multiple official/unofficial doc tags I would have
> to say No. as 99% of the time it would just be "${HOMEPAGE}/doc" or
> there would be a big fat link from the homepage and therefore would be
> of no real benefit.
Hmm, good point. Maybe we have to narrow the specification for to only
point to package maintainer info?
Since it can also change between versions, slots, etc...
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml
Santiago M. Mola wrote: > On Jan 19, 2008 2:07 PM, Tiziano Müller <[EMAIL PROTECTED]> wrote: >> >> Current state: "Deferred" >> Wanted state: "Accepted/Implemented" (at least by me) > > The GLEP should be updated. "Motivation" section does not seem to > justify the changes. IMO Meatoo [1] (and its hipothetical rewrite > using Doapspace [2]) would be the right tool to detect version bumps. > Maybe metadata.xml should contain a Freshmeat or DOAP entry so meatoo > could get more automation. Unfortunately not all projects update their Freshmeat entry. But you're right about the motivation: The point "It will reduce the time spent by developers trying to find how to contact upstream." should get more attention. Maybe it should even be split into two proposals: "New upstream tags to store maintenance upstream info" and "Add upstream tags to be able to store upstream version info" (or something like this, I'm sure you get the idea). -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
Tiziano Müller wrote:
Current state: "Deferred"
Wanted state: "Accepted/Implemented" (at least by me)
Open questions from last discussion (March 2006):
- Is it possible/should it be possible to have more than one
entry?
Yes
- Is recording an upstream-status (active/inactive) a good idea?
Maybe, leaning to No.
What about packages that have multiple slots, e.g php-4, php-5? one
slot could be inactive the other not, does that make upstream active?
Possibilities:
An element: {active/inactive}
Status of what? seeing you have proposed a upstream-status and a
maintainer status. what else is there left to status :P
An attribute: ...
No. As i'm pretty sure that every inactive maintainer won't go around
updating their packages metadata.xml
- Is an additional element needed to link to upstream docs
Interesting. what about the situation where upstream documentation sucks
but there is a "better" resource provided by a third party, could we
link to that? e.g. http://tldp.org for bash is an excellent resource
Multiple doc links?
could provide
that. Only concern I see is that this could relate to an endorsement of
thirdparty websites, which may change negatively ( porn on tldp.org ) or
my just become outdated.
Actually without the multiple official/unofficial doc tags I would have
to say No. as 99% of the time it would just be "${HOMEPAGE}/doc" or
there would be a big fat link from the homepage and therefore would be
of no real benefit.
Alistair
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
Tiziano Müller <[EMAIL PROTECTED]> said:
>
> Current state: "Deferred"
> Wanted state: "Accepted/Implemented" (at least by me)
Yea, this sounds like a good thing from reading over the GLEP, unless
I'm missing some glaring problems with it.
> Open questions from last discussion (March 2006):
> - Is it possible/should it be possible to have more than one
> entry?
Yea, agree.
> - Is recording an upstream-status (active/inactive) a good idea?
> Possibilities:
> An element: {active/inactive}
> An attribute: ...
Definately. We have several packages in the tree that once they become
broken, we'd have to start developing ourselves. This will help the
treecleaner project as well so they can tell if a package has several
open bugs and upstream is inactive, its a very good candidate for
getting booted from the tree.
> - Is an additional element needed to link to upstream docs
Sounds reasonable.
> - Must the type of be controlled/listed/checked?
I'd say we should come up with a good list to start with. We can come
up with updates to the allowed values at a later date, but I do think we
should keep this under control.
--
Mark Loeser
email - halcy0n AT gentoo DOT org
email - mark AT halcy0n DOT com
web - http://www.halcy0n.com
pgpPXq07yrA1j.pgp
Description: PGP signature
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
On Jan 19, 2008 2:07 PM, Tiziano Müller <[EMAIL PROTECTED]> wrote: > > Current state: "Deferred" > Wanted state: "Accepted/Implemented" (at least by me) The GLEP should be updated. "Motivation" section does not seem to justify the changes. IMO Meatoo [1] (and its hipothetical rewrite using Doapspace [2]) would be the right tool to detect version bumps. Maybe metadata.xml should contain a Freshmeat or DOAP entry so meatoo could get more automation. Anyway, I don't know how much would take the new version of meatoo. Pythonhead, could you give us some news about it? Or it's just planned for the long-term future? [1] http://meatoo.gentooexperimental.org/ [2] http://blog.doapspace.org/ -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
[gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
Current state: "Deferred"
Wanted state: "Accepted/Implemented" (at least by me)
Open questions from last discussion (March 2006):
- Is it possible/should it be possible to have more than one
entry?
- Is recording an upstream-status (active/inactive) a good idea?
Possibilities:
An element: {active/inactive}
An attribute: ...
- Is an additional element needed to link to upstream docs
- Must the type of be controlled/listed/checked?
My answers to this:
- yes
- yes. Remark: do we need to specify when upstream has to be marked as
active/inactive or can we use our common sense ?
- yes.
- not yet. Can be defined later.
Your oppinion?
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Concerns about WIPE_TMP change
Mark Loeser wrote: Should an elog statement been put into the ebuild...maybe. I leave that up to the maintainer to decide what is important enough to be logged, and they clearly thought this wasn't in this case. I think that this would probably warrant an elog. Sure, anybody who knows the "correct" way to admin unix doesn't put anything important in /tmp - but educating our users before blowing away their data isn't a bad thing. We shouldn't assume our users are idiots, but this is an obscure enough piece of admin knowledge that I think that users will be impacted by the change. Doesn't impact me one way or another - in my case both /tmp and /var/tmp are tmpfs filesystems. However, I do have a few longer-duration "temp" folders on my system that get cleaned by tmpreaper but is used for stuff that is nice to keep around a little longer. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Concerns about WIPE_TMP change
On Sat, 2008-01-19 at 02:48 +0100, Stefan de Konink wrote: > In my opinion WIPE_TMP should be in the same state > as RC_PARALLEL_STARTUP. That's a fair point. Luckily, the all the Gentoo init scripts that all my computers use are now at the stage where we could easily flick parallel startup on by default and expect it to work just fine. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] New public relations lead: dberkholz
Hi all, I've just talked to Christel, who was the public relations [1] lead, and we've agreed that because of changing priorities and time, I'll take over her duties as PR lead. If you have any comments about this, please email our mail alias, [EMAIL PROTECTED] You may commence blaming me for our PR failures and praising me for any successes. If you have any suggestions for how we could improve, please email [EMAIL PROTECTED] or join #gentoo-pr on IRC. One major problem I want to improve is transparency of development through making our homepage reflect what we're doing. This may simply involve more frequent news postings, but it could also involve some redesign. Anyone who's been involved in work on the Gentoo website in the past, please get in touch. Thanks, Donnie 1. http://www.gentoo.org/proj/en/pr/ -- gentoo-dev@lists.gentoo.org mailing list
