Re: [gentoo-dev] IUSE and LINGUAS?
On Mon, 30 Jan 2006 06:17:36 +0100 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: | Also, as repoman complain about linguas_blabla not being a valid | useflags, all the linguas_* useflags should be listed in use.desc No, part of the point of USE_EXPAND is that they shouldn't. This is a repoman bug. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Make logrotate a global USE flag?
On Mon, 30 Jan 2006 07:15:57 +0100 Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: | It would be interesting to know how that happened for in the past | for /etc/bash_completion.d, which made a similar move iirc Have you any idea how slow bash is if you use all the completion files for every app with completion support? -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Make logrotate a global USE flag?
Thomas de Grenier de Latour wrote: > It would be interesting to know how that happened for in the past > for /etc/bash_completion.d, which made a similar move iirc Yes, it would. > (although real files went to /usr/share/something, whereas here i > would rather see them in etc because they are more likely to be > customized). Can add anywhere to CONFIG_PROTECT ... Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Make logrotate a global USE flag?
On Sun, 29 Jan 2006 13:51:29 -0800
Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> And any other "new" file in /etc you also want a USE flag
> introduced for? Sounds real scalable. Or is this just an
> exception from the rule?
Sure it's an exception. I make the difference beetween:
- usual /etc/ files: when they are new, they don't get used before
you start the service or whatever they are owned by. People know
that they should configure things before using them, and that's no
issue. And when they are not new, the changes get CONFIG_PROTECTed,
so there is no issue
- files in some /etc/something.d/: no issue when not new neither,
sure. But when they are new, they affect the existing configuration
of an already in use service with zero protection. It's exactly
like if a pkg_postinst function was doing some "cat new_chunk >>
/etc/something", which i sure you agree would be bad.
Another example of such issues is when i installed laptop-mode
tools for the first time: it messed my acpid configuration, because
it was adding in /etc/acpi/{events,actions}.d some handlers for
things i had already configured differently in my own scripts.
That's that kind of situation i would like to avoid when there are
simple ways to do it, and not any file installation to /etc.
--
TGL
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make logrotate a global USE flag?
On Sun, 29 Jan 2006 13:51:25 -0800 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > Thomas de Grenier de Latour wrote: > > Or again another one (a bit ugly imho tho): merge the files in > > an "/etc/logrotate.d.dist" directory, and add an eselect module > > to handle symlinks from "/etc/logrotate.d". > > What's ugly about this? I like it. > What i fear could be a bit ugly is transition of existing systems from the current setup (logrotate.d/files) to the eselect setup (logrotate.d/symlinks -> logrotate.d.dist/files). I don't really see how to automate that since it would require being able to make distinction beetween packages' files and users' files (to move the first ones but not the second ones), and i don't really like the idea to do that kind of nasty tricks in some pkg_*inst function or alike. That, and also the fast transition on ebuilds side would somehow need to happen all at the same time so that no ebuild continue to put real files in logrotate.d once a system is on an select setup. It would be interesting to know how that happened for in the past for /etc/bash_completion.d, which made a similar move iirc (although real files went to /usr/share/something, whereas here i would rather see them in etc because they are more likely to be customized). -- TGL -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] IUSE and LINGUAS?
After reading Donnie's interesting post about how to set VIDEO_CARDS and INPUT_DEVICES in xorg 7, I wondered for a while if LINGUAS should have the same treatment. Defining LINGUAS variable would be useful to allow people to know whether they are going to have special support for their language in a package, but it would also clutter the output quite a bit. I experimented locally with kdetv, that uses LINGUAS variable to condition .po files and documentation generation in a predictable way (as in, the ebuild has to know which languages are available beforehand anyway): [ebuild R ] media-tv/kdetv-0.8.8-r1 USE="-arts -debug -lirc -opengl -xinerama -zvbi" LINGUAS="it% -bg% -br% -ca% -cs% -cy% -da% -de% -el% -en_GB% -es% -et% -fi% -fr% -ga% -gl% -hu% -is% -lt% -mt% -nb% -nl% -pa% -pl% -pt% -pt_BR% -ro% -ru% -rw% -sr% [EMAIL PROTECTED] -sv% -ta% -tr% -zh_CN%" 0 kB What people think of this? Whatever decision is taken I think it should also be documented somewhere for people to use. Also, as repoman complain about linguas_blabla not being a valid useflags, all the linguas_* useflags should be listed in use.desc (consider that it would take a while, _if_ we decide to go this route, before all packages are updated to do this, but it's silly to pollute the use.local.desc file until 5 packages are using a given language); the descriptions need also to be accurate. (sorry missing signature, I've broken pinentry and waiting for it to be rebuilt by emerge -e world) -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Sunday 29 January 2006 20:50, Sven Köhler wrote: > >> I also noticed the "--oneshot" fix. > > > > i noted this already elsewhere in the thread > > > > dont you read all of the e-mails !? > > ??? > > I just wanted to say "Thank you" for both fixes. sorry i forgot the -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
>> I also noticed the "--oneshot" fix. > > i noted this already elsewhere in the thread > > dont you read all of the e-mails !? ??? I just wanted to say "Thank you" for both fixes. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
On Sunday 29 January 2006 20:37, Sven Köhler wrote: > >> You say, that it's the intended behaviour, that bootstrap.sh keeps the > >> crippled gcc 3.3 intact and as the default compiler. > > > > ive chatted with wolf and the real fix here is to change the 'emerge > > clean' at the end of bootstrap.sh into an 'emerge prune sys-devel/gcc' > > ... that way when you emerge a new SLOT-ed version of gcc, the old > > stripped down version in stage1 is automatically pruned > > I also noticed the "--oneshot" fix. i noted this already elsewhere in the thread dont you read all of the e-mails !? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: bootstrapping since gcc 3.4 is stable
>> You say, that it's the intended behaviour, that bootstrap.sh keeps the >> crippled gcc 3.3 intact and as the default compiler. > > ok, i looked into this some more and ran some tests ... > > long and short of it is that the behavior i discussed before applies only in > a > stage3 and beyond ... the gcc-config logic is specifically tweaked during > bootstrap and build (i.e. stage1 and stage2), thus everything i said wrt to > automatic switching of gcc has no bearing on this discussion > > ive chatted with wolf and the real fix here is to change the 'emerge clean' > at > the end of bootstrap.sh into an 'emerge prune sys-devel/gcc' ... that way > when you emerge a new SLOT-ed version of gcc, the old stripped down version > in stage1 is automatically pruned I also noticed the "--oneshot" fix. Thank you! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] NFP lack of progress
Brian Harring wrote: [Fri Jan 20 2006, 10:42:39AM CST] > Email's pretty simple- from where I'm sitting, there doesn't seem to > be any actual progress on trustees issues. That's a pretty good synopsis. > 1) Copyright assignment. Check the nfp archives, last comment is sep > 26th, seems to be totally dead. > http://news.gmane.org/gmane.linux.gentoo.nfp/ My understanding is that we do have a draft copyright assignment form prepared, but because any sane discussion about it involves allowing the legal types to interact with foundation members, the thought was that we needed a separate, private, opt-in list for discussion, and that was never set up, so nothing has moved on this issue. (Also, I believe that we are still waiting on hearing back from the legal folks as to what needs to be discussed on the private list, and what can be in public. After all, the document itself will need to be public eventually!) > 2) bylaws. They're proposed. About it. Last update to the bylaws > doc was 10/24/05, http://www.gentoo.org/foundation/en/bylaws.xml In principle, they need to be voted on. In reality, I'm in no hurry since we haven't been around very long to see if the proposed bylaws are really what we need. > 3) quarterly filings. We've got 2nd quarter '05 up > (04/01/05-07/30/05). Where's 3rd? 4th actually being worked upon? > I'm assuming the pages haven't been posted but the paperwork (whatever > there may be) has been handled. There actually is no paperwork (legally, that is), because our income is such that no paperwork is required. From an ethical standard, however, we of course should be posting that info. Cshields? 4) Relocating the NFP to Delaware. Dostrow is working on it, but there has been no progress to date. 5) Wildcard SSL certificate for infra (bug #117837). Kurt is pushing that through, and I assume it will pass. It's darn pricy, but it' not clear that there is really a good alternative. > Additionally, bank transfer is underway, but donnie is responsive on > it so not raising it as an issue. > 1) where we're _actually_ at on these issues. See above. > 2) who is working on what I'm supposed to be pushing people to get things done. It's been rather like pushing a rope (people are busy, real life interferes, and this stuff is amazingly boring), and all-in-all I've done a lousy job of it. During the last multiple months I've been spending most of my time trying to switch careers (which I've now done, starting tomorrow), so I also have not contributed much recently. I won't run again for the foundation, since it's now clear that IP and budget discussions bore me to tears, and I'm not doing a great job motivating people. > 3) what _exact_ issues are holding folks up. I would say that it's more an issue of nothing being sufficiently urgent to spur people to actually finish anything right now. > 4) what is being done to resolve the hold ups. Various people keep prodding the Trustees asking if anything is actually going to be done. I'm not sure that it's helping, but it certainly isn't hurting anything. > 5) What actual progress/work has been done thus far (no, don't need to > document something publically viewable like "wrote bylaws") > 6) A rough schedule of when things are going to be accomplished. Not > asking for hard figures, but if you're held up by X, I'd like to know > when you expect X to be done so we can gauge how things are going. I don't have a good answer here, since I believe that the hangups are all personal, not technical. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpfwDj4OoGQX.pgp Description: PGP signature
Re: [gentoo-dev] Make logrotate a global USE flag?
Thomas de Grenier de Latour wrote: > On Sat, 28 Jan 2006 18:58:52 -0800 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: > >> You want people to recompile the whole package to get another >> text file installed? > > When would one recompile a package just for that? Only case i can > think of is when someone who already has setup his apache / ftp / > database / whatever server suddenly discover what "logrotate" is > and thus decide to start using it, whereas until then he didn't > payed any attention to the flag each time it was listed by "emerge > -pv". That sounds rather unlikely, and i would say "too bad, be > more careful next time..." to such a sysadmin. Oh, that's really friendly. Too bad, so sad, you just have to spend 10 hours recompiling all your logrotate-using packages. > And anyway, this > user doesn't really have to recompile anything to fix his mistake: > he can still have a look on the ebuild to see that if the file he > is missing is available in $FILESDIR, or use "ebuild unpack" and > get it from the sources tree when it comes from upstream. I don't expect users to know ebuild syntax to install a package. That's a terrible assumption to make. If it's something in filesdir and you really insist on a USE flag, my preference would be that it's a separate package pulled in by a USE flag instead of requiring a recompilation. >> People who don't want it can set INSTALL_MASK. It should be >> installed by default and not switchable with a USE flag. > > USE flag is the only way to indicate that a package has logrotate > support, and that's important. Remember that files added to an > /etc/something.d/ directory are chunks of configuration merged > with the user's one. First time they are installed, they are just > like bypassing the etc-update protection. > I remember that, maybe 2 years ago, syslog-ng suddenly started to > install a logrotate.d file, with no USE flag. Sure i didn't > noticed it, until i saw that what i had already configured by hand > in a different file was not working has expected anymore. Ok, > that's just logs rotation, it doesn't hurt that much, but still, i > would have prefer it to be introduced along with a USE flag, so > that i can notice the change and decide whether i accept it and > adapt my configuration. And any other "new" file in /etc you also want a USE flag introduced for? Sounds real scalable. Or is this just an exception from the rule? Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Make logrotate a global USE flag?
Thomas de Grenier de Latour wrote: > Or again another one (a bit ugly imho tho): merge the files in an > "/etc/logrotate.d.dist" directory, and add an eselect module to > handle symlinks from "/etc/logrotate.d". What's ugly about this? I like it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: New category - sci-visualization
On Saturday 14 January 2006 15:01, Marcus D. Hanwell wrote: > I propose creating a new category, sci-visualization, to house scientific > visualization applications. There are at least 17 applications I have > identified which are already in the tree that could be moved. Many of them > are in media-gfx with photo applications etc. They are all taken care of by > the scientific application herd. Just to reply to myself as there were no objections I have now added this new category. All the scientific visualisation applications I could spot have been moved already. Only applications are intended to live there, and there are a couple I intend to add in the next few weeks. Hopefully this hasn't caused any problems for anyone. Thanks. pgp8cTVn8D295.pgp Description: PGP signature
Re: [gentoo-dev] Make logrotate a global USE flag?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Jan 29, 2006 at 07:46:30AM +, Ciaran McCreesh wrote: > We already had this discussion. It's not that it's another file, it's > that it's another file in /etc, which is backed up and requires > administrator attention on every upgrade. Packages shouldn't stick > stuff in /etc on a whim. If you are saying that things should not be put in /etc by a package automatically for optional features, I agree with you there, and that is why I support the "logrotate" and "xinetd" use flags. William -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD3SHrblQW9DDEZTgRAiGuAKCoHMY5glKY3Fdaev7cAbOLtSYuxACgtvNP pMJHIUa6gnkYYuayh8tnEZ4= =5d0V -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Status of openhbci in Gentoo
Hi, Due to some notes that I have binary files in the tree on some packages I used to maintain ages ago, I came to the fact that we still have openhbci in the tree. openhbci is a library for the german homebanking computer interface standard. It has been replaced by the much advanced aqbanking. We have three apps in the tree that use openhbci: lxbank - seems to be still in development, but the ebuild is outdated for ages and nobody ever cried about updated versions - so I just assume nobody uses it. aqmoney - commandline tool, not touched for ages, I assume the same gnucash <= 1.8.9 - Can be removed as soon as alpha marks aqbanking + deps + latest gnucash stable. Later gnucash-versions have switched to aqbanking. So, my suggestion is to remove openhbci, openhbci-plugin-ddvcard, lxbank, aqmoney and gnucash-1.8.9 soon. If anybody is still using openhbci / has reasons to continue doing so, please cry very loud NOW, else it will be removed. cu, -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber: [EMAIL PROTECTED] "Was berechtigt eigentlich jeden Computerbesitzer, ungefragt seine Meinung abzusondern?" Jean-Remy von Matt pgpdNaGgLhekk.pgp Description: PGP signature
Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)
On Wednesday 25 January 2006 02:26, Brian Harring wrote:
> On Tue, Jan 24, 2006 at 08:06:12PM -0500, Mike Frysinger wrote:
> > i would be ok with implementing the back end (i.e. FEATURES=debug-build)
> > but putting off the front end (i.e. emerge --debug-build)
>
> Front-end doesn't matter, it's the back-end that's the concern. Clean
> up the backend in stable, and it's fine- hence the "shelve it"; fix
> the backend instead of tagging it half way in.
what exactly is "half way" about the attached patch ?
-mike
Index: pym/portage.py
===
--- pym/portage.py (revision 2604)
+++ pym/portage.py (working copy)
@@ -1263,6 +1263,23 @@
if "usersandbox" in self.features:
self.features.remove("usersandbox")
+ if "debug-build" in self.features:
+ # the profile should be setting these, but just in case ...
+ if not len(self["DEBUG_CFLAGS"]):
+self["DEBUG_CFLAGS"] = "-g -O"
+self.backup_changes("DEBUG_CFLAGS")
+ if not len(self["DEBUG_CXXFLAGS"]):
+self["DEBUG_CXXFLAGS"] = self["DEBUG_CFLAGS"]
+self.backup_changes("DEBUG_CXXFLAGS")
+ # replace user vars with debug version
+ for var in ["CFLAGS","CXXFLAGS","LDFLAGS"]:
+self[var]=self["DEBUG_"+var]
+self.backup_changes(var)
+ # if user has splitdebug, the debug info will be auto saved for
+ # gdb, otherwise we want to keep the binaries from being stripped
+ if not "splitdebug" in self.features:
+self.features.append("nostrip")
+
self.features.sort()
self["FEATURES"] = " ".join(["-*"]+self.features)
self.backup_changes("FEATURES")
Index: pym/portage_const.py
===
--- pym/portage_const.py (revision 2604)
+++ pym/portage_const.py (working copy)
@@ -40,7 +40,7 @@
CONFIG_MEMORY_FILE = PRIVATE_PATH + "/config"
INCREMENTALS=["USE","USE_EXPAND","USE_EXPAND_HIDDEN","FEATURES","ACCEPT_KEYWORDS","ACCEPT_LICENSE","CONFIG_PROTECT_MASK","CONFIG_PROTECT","PRELINK_PATH","PRELINK_PATH_MASK"]
-STICKIES=["KEYWORDS_ACCEPT","USE","CFLAGS","CXXFLAGS","MAKEOPTS","EXTRA_ECONF","EXTRA_EINSTALL","EXTRA_EMAKE"]
+STICKIES=["KEYWORDS_ACCEPT","USE","CFLAGS","CXXFLAGS","LDFLAGS","DEBUG_CFLAGS","DEBUG_CXXFLAGS","DEBUG_LDFLAGS","MAKEOPTS","EXTRA_ECONF","EXTRA_EINSTALL","EXTRA_EMAKE"]
EBUILD_PHASES = ["setup","unpack","compile","test","install","preinst","postinst","prerm","postrm"]
EAPI = 0
Re: [gentoo-dev] Make logrotate a global USE flag?
Thomas de Grenier de Latour wrote: > On Sat, 28 Jan 2006 18:58:52 -0800 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: > >> You want people to recompile the whole package to get another >> text file installed? > > When would one recompile a package just for that? Only case i can > think of is when someone who already has setup his apache / ftp / > database / whatever server suddenly discover what "logrotate" is > and thus decide to start using it, whereas until then he didn't > payed any attention to the flag each time it was listed by "emerge > -pv". That sounds rather unlikely, and i would say "too bad, be > more careful next time..." to such a sysadmin. And anyway, this > user doesn't really have to recompile anything to fix his mistake: > he can still have a look on the ebuild to see that if the file he > is missing is available in $FILESDIR, or use "ebuild unpack" and > get it from the sources tree when it comes from upstream. > [snip] indeed, rephrasing what sayd before in the same thread: Mysql eclass will add a USE flag, local or global, "logrotate" for next versions of MySQL, not touching the old ebuilds. Run-time needed files will still live in $PORTDIR/dev-db/mysql/files, because their size is small, and they change seldom. Compile time needed files have been already moved in a separate SRC_URI fetched file. Unless we decide to drop totally "logrotate" use flag support. BTW hope this is not enough fuel to start another flamewar. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] coreutils: deprecated behavior not so deprecated
On 27-01-2006 08:44:14 -0500, Mike Frysinger wrote: > On Monday 23 January 2006 23:04, Mike Frysinger wrote: > > for those who dont know what i'm talking about, consider: > > tail -1 > > head -1 > > > > it would seem i lied about this (at least the first two still work) FYI: sort +0 doesn't work anymore. Not sure, but it seems to control the sorting order, sort +1 sorts reverse, all the rest normal. autofs uses this in the auto.net script, which causes the automounter to get broken. Bug #120403. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Jokey (Markus Ullmann)
Thanks guys ;) Seems we have some Mar[ck]us'es and also Joker and Jokey.. Sure will be fun ;) Tobias Scherbaum wrote: >... and once again a candidate for the one and only German conspiracy >:) What about german conspiracy meet up at fosdem? ;) Greets, Markus -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make logrotate a global USE flag?
On Sun, 29 Jan 2006 11:07:15 +0100 Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: > i would not appreciate to see it suddenly handling a new service > because a xinet.d file has been silently added by a new version > of an ebuild. Ok, i see all files i have installed in that dir have disable=yes, so they don't really hurt. Sorry about that, i should have check. That makes me think of a similar solution for logrotate if the USE flag must really go: merge only some completly commented files. This way you give control back to the user, while still helping him in his logrotate configuration. Or again another one (a bit ugly imho tho): merge the files in an "/etc/logrotate.d.dist" directory, and add an eselect module to handle symlinks from "/etc/logrotate.d". -- TGL -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make logrotate a global USE flag?
On Sat, 28 Jan 2006 18:58:52 -0800 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > You want people to recompile the whole package to get another > text file installed? When would one recompile a package just for that? Only case i can think of is when someone who already has setup his apache / ftp / database / whatever server suddenly discover what "logrotate" is and thus decide to start using it, whereas until then he didn't payed any attention to the flag each time it was listed by "emerge -pv". That sounds rather unlikely, and i would say "too bad, be more careful next time..." to such a sysadmin. And anyway, this user doesn't really have to recompile anything to fix his mistake: he can still have a look on the ebuild to see that if the file he is missing is available in $FILESDIR, or use "ebuild unpack" and get it from the sources tree when it comes from upstream. So no, i don't really see what the problem is here. (Sure, introducing the flag in an ebuild when doing a bump doesn't count as a "recompilation to get logrotate", since that's an update that the user will do anyway.) > People who don't want it can set INSTALL_MASK. It should be > installed by default and not switchable with a USE flag. USE flag is the only way to indicate that a package has logrotate support, and that's important. Remember that files added to an /etc/something.d/ directory are chunks of configuration merged with the user's one. First time they are installed, they are just like bypassing the etc-update protection. I remember that, maybe 2 years ago, syslog-ng suddenly started to install a logrotate.d file, with no USE flag. Sure i didn't noticed it, until i saw that what i had already configured by hand in a different file was not working has expected anymore. Ok, that's just logs rotation, it doesn't hurt that much, but still, i would have prefer it to be introduced along with a USE flag, so that i can notice the change and decide whether i accept it and adapt my configuration. INSTALL_MASK is not of any help against that: how does one know what to mask before it's too late? I use logrotate, i have the flag turned one, and i just can't mask the whole directory, because files i want files that i know are installed there (and want their updates). But next time a package gets added unconditional logrotate support (or i install one which already has it), it may randomly screw my own config again. As for xinetd, i don't use it so i don't really care, but i guess the same arguments could be used: if i was using it, i know i would not appreciate to see it suddenly handling a new service because a xinet.d file has been silently added by a new version of an ebuild. So, really, i currently see the USE flag as the only way to give users control over their /etc/something.d configurations. Or there should be a new config protection mechanism in portage to avoid auto-merge of some of the config files (something similar to CONFIG_PROTECT, like merging them as ._new0001_foobar when they don't exist yet, but with a different paths list, limited to /etc/*.d/ directories). But that's a different story... -- TGL. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Find apps not ported to modular X
The last drop: 498 to 465, a change of 33 -- adequate, but should be better since this was for close to three days. Progress graph: http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_progress.png Latest list: http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_maintainers.txt.20060128 Herds with 10 or more unported packages as of 1:30 PST (12 hours ago): 153 games 63 none (individual or no maintainer) 54 desktop-dock 33 (no metadata.xml) 30 desktop-wm 21 cjk 15 sci 14 video IRC: #gentoo-x Documentation: http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml http://www.gentoo.org/proj/en/desktop/x/x11/porting-modular-x-howto.xml Metabug: http://bugs.gentoo.org/112675 If you can't figure out what needs to get done and you've already read the docs, ask in #gentoo-x. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Make logrotate a global USE flag?
Marcelo Góes wrote: > >If INSTALL_MASK is the correct way to prevent logrotate stuff from >being installed, then those 8 ebuilds I mentioned earlier should drop >the USE flag and install it by default. That's probably easier to fix, >too. > > This cannot be done for squid, because this useflag selects the rotation method: logrotate or the native method (through a cron job). While it is easy to filter logrotate files through INSTALL_MASK, it isn't so for /etc/cron.* files. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: tcsh vs. csh, removal of the latter
On Saturday 28 January 2006 12:30, Marcelo Góes wrote: > On 1/28/06, Grobian <[EMAIL PROTECTED]> wrote: > > The question here now actually is: "is csh worth the hassle, or not?" > > My opinion is that it is not. > > csh_is_not_worth_it++; > It is causing trouble and not adding functionality. Unless there are > cases where tcsh is not backwards compatible, I say it is a good > riddance. i say kell it -mike -- gentoo-dev@gentoo.org mailing list
