Re: [gentoo-dev] devfs is dead, let's move on
On Saturday 09 July 2005 00:25, Greg KH wrote: I.o.w. is it still necessary to have RC_DEVICE_TARBALL=yes as a default or can we move to a pure udev system and change the default to no. I've been running my boxes successfully with no since the option showed up just fine :) Same over here on all boxes maintained by me (21 with different hardware). Using the tarball creates a lot of unnecessary clutter in /dev If all ebuilds/enough ebuilds don't need to have the tarball, I would say change the default and let all users enjoy the pure udev ride. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New MySQL doc
On Tuesday 12 July 2005 06:38, Chris White wrote: Here's the initial devspace draft of the new MySQL draft I've been working on: http://dev.gentoo.org/~chriswhite/mysql.html Comments, etc are welcome. This is a very good guide! Thanks a lot!! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Devconference archives
On Monday 15 August 2005 05:25, Corey Shields wrote: Archive links for the complete morning and afternoon sessions are at http://devconference.gentoo.org -Corey Hi Corey (and IU), Thanks a lot! Is it possible to download the media-files instead of streaming? This makes it a lot easier to skip/replay some parts of the session. Regards, Michiel. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] dts useflag
On Thursday 18 August 2005 05:29, Georgi Georgiev wrote: maillog: 18/08/2005-03:03:40(+0200): Diego 'Flameeyes' Pettenò types media-video/mplayer:dts - Enables libdts (5.1 surround sound audio) support I'll commit this tomorrow, when I'll be sure it's ok after an awake check. If nobody is against this, I'll also make dts useflag global (using ffmpeg/mplayer's description). I am certain that I have watched DVDs that had DTS audio with 7 channels. Yup, DTS (or DD) doesn't say anything about how much channels are being used, lots of media use DTS or DD and only have 2 channels. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
On Friday 21 October 2005 04:56, Mike Frysinger wrote: On Thursday 20 October 2005 10:49 pm, Dan Meltzer wrote: Why single out this one? ones system will not break irreperbly without a cxx compiler, it'll just cause a another recompile to get it to work after breakage if the person is using -* (which has already been said to be hackish and ill-advised, so doom on them! it will actually if you build gcc w/out C++ support that means no libstdc++ no libstdc++ means python on most boxes is now broken no python means no emerge how exactly are you going to re-emerge gcc then ? oh, you cant ... -mike Can you think of a situation where this is desired? If not, why not remove the cxx IUSE and always build the C++-component? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
On Wednesday 02 November 2005 02:29, Brian Harring wrote: On Tue, Nov 01, 2005 at 10:16:35PM +, Ciaran McCreesh wrote: | How will it handle GLSAs then? [1] gentoolkit != portage. Correct. Course, also incorrect. A plan for handling GLSA's from portage (emerge --security) was announced some time ago. Is this still planned (i.o.w. portage handling xml)? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
On Saturday 05 November 2005 06:08, Jason Stubbs wrote: Why does `emerge --changelog` not suffice for package-specific news? From a user/sys.admin point of view let me give you an example; I maintain quite a lot Gentoo-systems. For me it's impossible to read _every_ changelog for minor release changes. For example not so long ago Apache was upgraded from 2.0.54-r15 to 2.0.54-r31. For me as a user/sys.admin based on versionnumbers this is a minor change. However the changes were rather extensive (e.g. reorganization of conf.files). When these changes occur I want to be informed _before_ I start emerge and I think that this information should be _pushed_ to users/sys.admins instead of _pulled_ from external sources (forums, website, mailinglist, etc. or changelogs). If changelogs could be extended with a priority flag and emerge would notify me when a high priority changelog is applicable to my system then this would be just fine for me. Basically all I want is; Notification that new relevant news items will be displayed via the ``emerge`` tool in a similar way to the existing configuration files need updating messages: :: * Important: 3 config files in /etc need updating. * Type emerge --help config to learn how to update config files. * Important: there are 2 security advisories released for installed packages. * Type emerge --security to see the details. * Important: there are 5 unread news items. * Type emerge --help news to learn how to read news files. If this is possible by extending the changelog I'm a happy users/sys.admin. I don't care if I need to type emerge --news or emerge --changelog as long the information is pushed. Disclaimer; I'm not 100% sure that the versionnumbers from Apache mentioned above are exact the real world examples, but you get the idea. Regards, -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stepping aside...
On Friday 23 December 2005 16:44, Sven Vermeulen wrote: Hi all It is with deep regret that I want to inform you about my decision to step down from the position of Gentoo Documentation lead. I just want to say thank you very much for the outstanding work you (and the rest of the GDP-team) have done. I think that the quality and quantity of the things done by the GDP-team is something that a lot of projects can only dream about. (open en closed source software) Bedankt! I will remain a member of the Gentoo Documentation Project, hacking away at guides such as that bootstrapping one and the Gentoo Handbook, but I hand the coördination over to Xavier Neys who was virtually leading the GDP anyway and does seem to find a good balance between real-life and Gentoo-life :) I wish Xavier good luck and a lot of fun with the (formalization of) new role within the GDP. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2006-12-24 23:59 UTC
On Tuesday 26 December 2006 02:04, Robin H. Johnson wrote: The attached list notes all of the packages that were added or removed from the tree, for the week ending 2006-12-24 23h59 UTC. Removals: x11-misc/emerald-themes 2006-12-20 01:00:59 tsunam Additions: x11-themes/emerald-themes 2006-12-19 21:22:56 tsunam Thanks, is it possible to adjust the script and separate category moves? Thanks again. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Saturday 21 July 2007 16:36:03 Roy Marples wrote: This is just a heads up for getting baselayout-2 stable. Next week I plan to put baselayout-2.0.0_rc1 into the tree without any keywords and it will be removed from package.mask (keeping the current alphas masked though). Arch teams will then be pinged on a bug to keyword baselayout-2. Well, that's about it. It's been a fun journey making baselayout-2 and we're almost at the end of this road :) Thanks Roy Hereby a friendly reminder that gcc-config should be keyworded as well, current gcc-config isn’t compatible with baselayout-2. According to Mike gcc-config-1.4.0 is compatible with baselayout-2. (doesn’t work on my system, but I haven’t investigated yet). -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Downgrading glibc?
On Fri, Feb 11, 2011 at 1:27 PM, Diego Elio Pettenò flamee...@gmail.com wrote: Il giorno ven, 11/02/2011 alle 13.06 +0100, Sebastian Pipping ha scritto: If anyone considers masking glibc 2.13 for now: please take my vote. It should have been masked _beforehand_, masking it now is going to cause more trouble. Given this situation; it is desirable for future Portage/EAPI to be able to create a deptree depending on whether an atom is already installed or not? With this functionality it is possible to mask a package-without-downgrade-path again for systems that haven't the new atom installed yet. It should be used as little as possible of course, but for situations like this the damage can be limited to as few systems as possible.
[gentoo-portage-dev] generating ._cfg0000_foo multiple times between --sync
Hi guys, I wonder why the default behaviour of portage is to generate ._cfg_foo files only one time after a --sync. For example I have done the following; - emerge --sync - emerge baselayout --oneshot -v ._cfg_foo files are created so I can use dispatch-conf to select which one I want to update after a while I want to reset more files to the default value so I do; - emerge baselayout --oneshot -v this time ._cfg_foo files are not created When I do emerge --sync again and emerge baselayout --oneshot -v then ._cfg_foo files are created again, however for me this is not preferred, because I want to keep my current tree. I remember vaguely that there is a setting to enable generation of ._cfg_foo files always, however I have searched on my system, forums and google, but I'm unable to find it. If actually this setting exists you might want to enable it by default, but definitely document it better. IMHO portage should always behave the same whether you just synced or not. What do you guys think? b.t.w I'm using portage-2.1_pre7-r5 Regards, Michiel. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Re: generating ._cfg0000_foo multiple times between --sync
On Saturday 15 April 2006 18:51, Duncan wrote: man emerge, search on --noconfmem, or emerge --help. Both the usual places one looks for documentation on command line options for a Unix command cover it. That seems decent documentation to me, as I didn't remember what the option was either as I've never needed to use it, but I found it relatively quickly when I needed to, and had looked over the manpage before when learning about emerge and portage, so was aware the command existed if needed. While making this a feature so the user can change the default might be debatable, the stated purpose and default seem sensible to me. Meanwhile, if you want that for your default, it's simple enough to do with a shell alias, or using the new EMERGE_DEFAULT_OPTS var in make.conf. I have looked through the manpage and emerge --help, can't believe that I overlooked it twice. Thanks for your help/reply!! Regards, Michiel. -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] globally disable use expand
Hi guys, If I'm not mistaken, behaviour in portage changed recently. USE=-* in make.conf disabled use expand as well. Now use expand stays enabled. What is the proper way to disable it globally? I couldn't find anything in the documentation. Thanks! Regards, Michiel. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] globally disable use expand
On Sunday 01 October 2006 16:24, Marius Mauch wrote: USE=-* never disabled USE_EXPAND by default (such behavior would have led to interesting problems). What is the proper way to disable it globally? I couldn't find anything in the documentation. Thanks! If your really want to do that you can set USE_EXPAND=-* in make.conf. Marius Thanks for your reply. I only updated portage before I noticed this behaviour, but it was the change in profile(s) that triggered this. -- gentoo-portage-dev@gentoo.org mailing list
