Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wed, 2007-01-10 at 13:32 -0500, Mike Frysinger wrote: > On Wednesday 10 January 2007 13:03, Jakub Moc wrote: > > And RESTRICT=sandbox is still completely unneeded, > > commercial packages or not... We don't need to introduce a special > > RESTRICT because of two borked packages in the tree and we should not > > introduce any more packages borked in a similar way into the tree. > > for future reference, keep your replies on topic and stupid rants out > > this is what you should have said in the first place > > we need a real solution for emacs/gcl ... exporting SANDBOX_ON=0 is not the > answer > -mike Here's a real solution for gcl: http://bugs.gentoo.org/show_bug.cgi?id=161041#c7 Y'know, if even a tenth of the energy that went into this flame war had gone into solving the emacs sandbox breakage, I'm pretty sure that would have been fixed by now as well. Funny, that. Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: portage idea - auto embed user patches
On Thu, 2006-12-21 at 21:47 -0600, Steev Klimaszewski wrote: > Steve Long wrote: > > Alec Warner wrote: > >> http://dev.gentoo.org/~solar/bashrc > >> > >> At the bottom of solar's bashrc you will find some lines dealing with > >> AUTOPATCH, I don't see the bashrc.autopatch in his dev space, but you > >> can probably request it from him. > >> > > Would it be possible to post that to this list? Then we've all got a > > searchable record of the best practise. > > > try http://dev.gentoo.org/~solar/portage_misc Interesting, but fairly lightweight. Mine handles re-autotooling when appropriate and marking the autopatch stage as completed: http://sources.catmur.co.uk/svn/repos/gentoo/phase_hooks.d/post_src_unpack/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Beta versions should be slotable
On Mon, 2006-08-07 at 09:52 -0500, Andrew Gaffney wrote: > Edward Catmur wrote: > > Is it possible to get Portage (or ebuild) to build a package for > > installation into /opt? If not, how much work would that be? > > > > What would be great would be to have emerge --optinstall package, that > > installs the package into /opt/$PV and doesn't create a vdb entry... > > feasible? > > Possible, sure: > > emerge -B package > mkdir /opt/package > tar -C /opt/package -xjf /usr/portage/packages/All/package-ver.tar.bz2 Yeah, but the internals'd be screwy; hardcoded paths would point to the /-based locations. Maybe (in effect) passing --prefix=/opt/$P to configure? > Smart, not really. Using portage to install packages that are outside of > portage's control is kinda silly. If you want to do that, build it by hand or > use a pre-compiled package such as a RPM or DEB from the author's site. But using portage lets you use emerge's dependency resolution, build system (ccache, distcc, etc), plus Gentoo patches and other fixes. With a rpm or deb you don't have the faintest clue what you're getting... Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Beta versions should be slotable
On Mon, 2006-08-07 at 09:31 -0500, Mike Doty wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Noack, Sebastian wrote: > > Hi folks, > > > > I like to try bleeding edge beta versions. But I hate that if I will > > install for example the new firefox 2 beta via portage, it will unmerge > > the current stable version. I would prefer to have a stable version for > > daily work and the beta version for testing purposes at the same time on > > my system. Therefore I would propose to introduce a policy, which forces > > each ebuild with the suffix _alpha, _beta or _pre have to be slotable. > > > Not feasable. You have 2 possible ways of doing it though. one is to > use a chroot to test these things, and the other is to take a quickpkg > of the stable version and emerge -k when you're done testing the > bleeding edge stuff. Is it possible to get Portage (or ebuild) to build a package for installation into /opt? If not, how much work would that be? What would be great would be to have emerge --optinstall package, that installs the package into /opt/$PV and doesn't create a vdb entry... feasible? Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Masking practics
On Mon, 2006-08-07 at 15:01 +0200, Enrico Weigelt wrote: > Lets say, if I've, installed foo-1.1, and it gets masked due > some bug(s), but 1.0 isn't, I want to get informed with an big > fat warning, *before* anything actually done, ie. > > [...] > # WARNING: installed package foo-1.1 has been masked and would > # be downgraded: > # > [...] > > An fully-automatic downgrade should *never* downgrade anything. > This is too dangerous, because essential features can get lost. > Again, my bugzilla example: assuming 2.22 will be unmasked some > day and I installed it w/ postgres support. Now there are some > bugs found, but not fixed fast enough, so it gets masked. > I run an update w/o knowing that it downgrades, and my whole > bugzilla hosting is suddenly broken. That would not happen. bugzilla is a webapp and as such is fully SLOTted. Upgrades (and downgrades) are manual. Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [experiment] Sunrise try 2
On Sat, 2006-06-24 at 13:05 +0200, Luca Barbato wrote: > (from critics) > - What is wrong with the model (each point 2 lines at least, 4 at most) > - What you'd do as alternative as the criticized point ( 2 lines again) * Simplicity: The FAQ claims that Sunrise is simpler than Bugzilla. It is - for users. Contributing is a lot more involved than with Bugzilla; Sunrise is supposed to be about making contributing easier. - Admit this in the FAQ. Where possible, write svn wrappers to make the contributing process easier. * Security (from malicious contributors): Glad to see layman will only track the reviewed/ tree; still, anyone who checks out the sunrise/ tree (and has it in PORTDIR_OVERLAY) is vulnerable. - Remove from the examples any suggestion that one should check out the whole tree when contributing. Point out that one should not svn up sunrise/ as part of updating Portage. * Conflicts between contributors (technical): Alice adds an ebuild; Bob makes a change; Alice makes another change and discovers it conflicts with Bob's change in the repo. Alice has not used subversion and doesn't know how to resolve conflicts. - Document the subversion conflict resolution process. Advertise that you will be available on IRC to help with these types of problems. Explain to use "svn st -u" and "svn up" to sync before making changes. * Conflicts between contributors (social): Alice adds an ebuild; Bob makes a (maybe "obvious") change; Alice thinks the change is incorrect, and, feeling that the ebuild is her property, reverts the change. A revert war erupts. Many casualties. - Create a social structure to enable Alice and Bob to communicate and resolve their differences of opinion. Forums? Wiki? IRC? Bugzilla? I would argue there should be One True location for this to occur; /not/ bugzilla (bugspam); /not/ IRC (impermanence). * More to keep track of: With bugzilla you have a single URL, from which you receive threaded email updates. Sunrise adds /two/ svn directories plus whatever is used for discussion. - Create a summary page that links to bugzilla and discussions, and tracks versions and changes, and all other relevant information. Allow (require?) contributors to subscribe to email updates from the summary page. That's all for now. I might think of more. Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 10:28 +0200, Patrick Lauer wrote: > > > > Except that I can *look* at an ebuild without having to break out a > > > > subversion client currently. > > > See my answer in 3) > > See mine. ;] > Hmmm ... bugzilla. > Instead of a simple cvs up; cd /usr/local/portage/category/package I > need to search for ALL bugs with $name in it, look which one it is, > curse bugzilla for falling asleep again, see which attachments are > relevant, download them, curse bugzilla for falling asleep again, copy > them to my overlay, read the bugcomments to see if any special renaming > or directory structure is needed ... > > Hmmm. I think an overlay does have some advantages there ... Advantages? With bugzilla I: search for the bug, cc myself on it, download the relevant files, look over them, note a style error, try to merge it, fix a compilation bug, re-upload the fixed ebuild and patch to bugzilla with a comment to the ebuild author on their mistake. When an update hits my inbox I can go directly to the bug... With an overlay: search sunrice.gentoo.org for the package (no, I don't know category/name), sync that directory (no, I'm not syncing the whole sunrice tree), check it over, note some mistakes, compile it if I feel OK with it, it fails, I fix it - and what then? Where do I discuss the problems? How do I get my fixes to other users, considering the package is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will it be read? This seems like *raising* the barrier to entry to me... Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Fri, 2006-06-09 at 02:53 +0200, Stefan Schweizer wrote: > Stefan Schweizer wrote: > it is actually encouraged to update bugzilla when changes are made in the > overlay. Encouraged? If you leave it at that, people will forget, and things will get out of sync. At the very least you should supply per-package rss feeds and email subscriptions. Otherwise this will be a downgrade in functionality from the current bugzilla system. (Which I think is perfectly fine as it is.) > The ebuilds have a quality, repoman is required to be run. Also contributors > should be knowing what they are doing - they are submitting an ebuild to > the sunrise overlay, it needs to follow certain standards. And what if they do know what they're doing, and what they're doing is subverting Gentoo systems en masse? You're proposing to hand out commit access to anyone who makes a case on IRC; you have no way to tell that they aren't an attacker. Part of the reason becoming a dev is expensive is that it provides a barrier for attackers (and gives recruiters time to check that the candidate is who they claim to be). By using Gentoo resources for this project you're implying that the ebuilds can be trusted; hordes of users *will* sync with the sunrise overlay, giving an attractive target to attackers. (Or what if they're attacking overlays.gentoo.org itself? This stuff is shell code; some well-meaning person's going to source it at some point.) And similarly, Gentoo's reputation would be immeasurably damaged if an attacker succeeded in sneaking malicious code in. (Don't say you'll review it; can you review every line of a 20K gcc4-compatibility patch? Have you read the Underhanded C Contest?[1]) Ed [1] http://www.brainhz.com/underhanded/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thu, 2006-05-18 at 16:37 +0200, Paul de Vrieze wrote: > On Thursday 18 May 2006 16:03, Stephen Bennett wrote: > > On Thu, 18 May 2006 15:34:28 +0200 > > > > Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > > Requiring duplication of profiles for every package manager. > > > > It requires duplicating nothing. This is exactly why we have cascading > > profiles. > > Cascading profiles form a tree with N nodes. Some of these nodes are > abstract in the sense that they are not directly usable. Say that leaves > M possible profiles. To have paludis be on par with portage, each of > these M profiles would have a leaf added for paludis. The same holds for > pkgcore and for any other package manager. This would mean that we have > N+2M profiles. With a paludis and pkgcore toplevel profile this would > even be worse and amount to approximately 3N profiles. > > In the leaf version, all M paludis specific profiles are equal. But Paludis supports multiple inheritance. Would it be feasible to have Paludis users create /etc/make.profile as a directory, with /etc/make.profile/parent inheriting from both their chosen gentoo-x86 profile and a profile in the paludis tree? (I guess this looks like offering a technical solution to a political problem... sorry about that.) Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ACCESS DENIED during emerge
On Fri, 2006-04-28 at 14:01 -0700, Drake Wyrm wrote: > "A. Khattri" <[EMAIL PROTECTED]> wrote: > > Ah, I see now that the actual make install is trying to do this. > [snip] > > 1. So I need to set --enable-conf-install=no which also implies I need > >to override src_compile > > You shouldn't need to completely override src_compile for just that. All > you'd need to do is set EXTRA_ECONF appropriately. No, EXTRA_ECONF is for end-users to add their own cracktastic configure flags. Ebuilds should not set it. -- Ed Catmur -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] vim 7 beta
On Sat, 2006-03-25 at 13:28 +, Ciaran McCreesh wrote: > As of now, vim 7 alpha is unsupported and should no longer be used. For > those of you who don't think I'm a "security risk", there're vim 7 beta > ebuilds at: > > http://dev.gentoo.org/~ciaranm/tmp/vim-beta-overlay.tar.bz2 > > Note that this includes an eclass update, and eclasses and overlays > don't mix particularly nicely. If you don't know what you're doing, > don't use it. Nice. Minor issue: the tarball is not currently suitable for use as an overlay, because it doesn't include the completion, vimrc, xpm, .desktop files etc. in FILESDIR. Copying them over from the gentoo.org tree works. > The new vimrc should hopefully work nicely with TERM=gnome, but I don't > plan to install Gnome to find out (bug #122562). Yes, it works fine. Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: Gratuitous useflaggery (doc and examples)
On Sun, 2006-03-05 at 14:35 -0600, MIkey wrote:
> Mike Frysinger wrote:
> Regardless, I would rather see noman/nodoc/noinfo implemented in USE flags,
> so they can be applied package by package, implemented perhaps in something
> like dodoc/doman/doinfo/dohtml. In some cases I might actually want
> documentation for specific packages...
no{man,doc,info} is implemented within ebuild.sh, so you can
use /etc/portage/bashrc to set FEATURES="noman" on a per-package basis.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: /etc/rc.conf
On Sun, 2006-02-12 at 19:56 -0500, Forrest Voight wrote: > On 2/12/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > Forrest Voight wrote: > > > I was using an old gentoo system. Forget about KEYMAP. > > > But, what about UNICODE? That is related to KEYMAP and consolefont. > > > Shouldn't EDITOR and XSESSION be in a user-specific place? > > > > I guess you didn't really understand the code. They can be in a > > user-specific place. > > Then why can't it be in /etc/skel? Changing /etc/skel only affects new users. /etc/rc.conf affects all users that don't override it in their env. Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Mon, 2005-11-28 at 10:18 +0900, Georgi Georgiev wrote: > maillog: 27/11/2005-13:54:33(+0100): Diego 'Flameeyes' Pettenò types > > On Sunday 27 November 2005 00:10, Luca Barbato wrote: > > > It's great! > > > Make it a FEATURE default on for common profiles. > > +1, and it would be better if the FEATURES, instead of removing the > > generated > > files, would disable the building of them completely, mainly because "work" > > systems with limited CPU, RAM and HDD space would probably prefer not > > having > > to create and store them :) > > Wouldn't that break binary packages? I.e., if a binary package is built > on a system with FEATURES=-splitdebug and then merged on a system with > FEATURES=splitdebug the debug info would be missing. There's nothing to break. The only program that looks for debug symbols is gdb; if they're not there it does what it does currently; print "(no debugging symbols found)". Ed Catmur -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
On Sun, 2005-11-27 at 09:39 -0500, Dan Meltzer wrote: > On 11/27/05, Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> wrote: > > On Sunday 27 November 2005 00:10, Luca Barbato wrote: > > > It's great! > > > Make it a FEATURE default on for common profiles. > > +1, and it would be better if the FEATURES, instead of removing the > > generated > > files, would disable the building of them completely, mainly because "work" > > systems with limited CPU, RAM and HDD space would probably prefer not having > > to create and store them :) > > Err, maybe I am incorrect, but isn't it more "work" to ungenerate them > (using strip) then to just not install them? The debug info gets built into the binary by gcc. We copy out the debug info using objcopy --only-keep-debug, add a link with --gnu-debuglink and then remove it from the binary using strip. Without FEATURES=splitdebug the first two steps would be omitted, making it exactly the same as what happens now. So, no more work. Ed Catmur -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Split ELF Debug (default or not?)
On Sun, 2005-11-27 at 08:40 -0500, Ned Ludd wrote: > On Sun, 2005-11-27 at 15:09 +0200, Ivan Yosifov wrote: > > And one more thing. For proper debugging, don't I need the source to be > > present ? > > -g3 -ggdb embeds the source code in the debug info so I don't see the > point. It doesn't; at least not with gcc 3.4.4. It does embed function prototypes and macro definitions, though. Ed Catmur -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Split ELF Debug (default or not?)
On Sun, 2005-11-27 at 15:09 +0200, Ivan Yosifov wrote: > On Sun, 2005-11-27 at 07:24 -0500, Ned Ludd wrote: > > On Sat, 2005-11-26 at 13:20 -0600, R Hill wrote: > > > Ned Ludd wrote: > > > > Good afternoon, > > > > > > > > probably in portage-2.0.54 a patch will be added to emit split debug > > > > info. Having a split debug allows us to retain all the advantages of > > > > stripping executables while gaining the ability to properly debug > > > > executables in bfd aware programs. It's been in testing with a small > > > > hand full of devs and works quite well, but before it's pushed in we > > > > would like to get input from our devs & users. > > > > > > > > Would you be willing to give up space in $ROOT/usr/lib/debug for ELF > > > > executables by default in order to aid in better debugging by or do we > > > > want to only emit it when a FEATURE= is defined. > > > > > > How much space are we talking about? > > > > There is no fixed size here and depends on the number of packages you > > have and the CFLAGS passed to the programs you build. > > Naturally if you start building all your code with > > CFLAGS="-g3 -ggdb" your going to end up with a larger debug info. > > Of course I will be compiling with CFLAGS="-g3 -ggdb" :) > > The reason I don't do it now is because debug info: > > 1) makes binaries larger > 2) makes binaries slower ( in my experience ( may have to do with 1) ) > > And I don't ( not sure if anyone does ) care about any non-gdb debugger. > > So, can you give us a wild guess about the disk space ? How much does it > take on your system and how many packages do you have installed ? > > And one more thing. For proper debugging, don't I need the source to be > present ? I've been installing debug symbols and debug sources for a few weeks now, using bashrc hacks. I use "debugsymbols" and "debugsources" in FEATURES. At a rough estimate, debug symbols with -ggdb3 will add 60% to package sizes, and debug sources will add another 40%. So having this on by default will necessitate a repartition for many users. Ed Catmur -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for media-video/helixplayer
On Mon, 2005-11-21 at 21:43 +0100, Diego 'Flameeyes' Pettenò wrote: > On Monday 21 November 2005 21:15, Henrik Brix Andersen wrote: > > Please make a habit of always supplying a list of > > alternates/replacements when writing a "last rites" email - saves us > > someone having to ask: > Sorry, too used to know the media-video category by heart :| > > > What replaces it? > HelixPlayer is a simple player for Ogg Theora/Ogg Vorbis files, so you can > find at least three better replacements: media-video/vlc, xine and its > frontends and media-video/mplayer . > They might not be drop-in replacements, but it's not like helixplayer does > anything more for now. helixplayer handles some of the RealMedia transports and codecs better than any of the above; but for that you can use realplayer-10.0.6, which is the same codebase as helixplayer and has extra non-Free codecs - it's non-Free, but works on amd64 and x86, and anyone wanting to hack on the realplayer/helixplayer codebase will be using helixplayer pre2 cvs anyway. Ed Catmur -- gentoo-dev@gentoo.org mailing list
