Re: [gentoo-dev] updating GLEP 1
On 2011-03-09 19:11, Mike Frysinger wrote: +list. GLEPs are then reviewed at a Council meeting where it may be approved +or rejected outright, or send it back to the author(s) for revision. This Just a minor note; The sentence is written from the perspective of the GLEP, so the last part should probably be , or sent back to the author(s) for revision.
Re: [gentoo-portage-dev] Conflicting RDEPENDS
On Fri, May 29, 2009 at 01:36:20AM +0200, René 'Necoro' Neumann wrote: Package spam rdepends on =eggs-2. Package bacon rdepends on =eggs-1. So in theory there should be no way of installing them together (given that eggs is not slotted). This works if I try to install them in one go. !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: app-test/eggs:0 ('ebuild', '/', 'app-test/eggs-2', 'merge') pulled in by =app-test/eggs-2 required by ('ebuild', '/', 'app-test/spam-1', 'merge') ('ebuild', '/', 'app-test/eggs-1', 'merge') pulled in by =app-test/eggs-1 required by ('ebuild', '/', 'app-test/bacon-1', 'merge') It looks different, if spam is installed and I try to install bacon additionally: # emerge -1av bacon These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] app-test/eggs-1 [2] 0 kB [1] [ebuild N] app-test/bacon-1 0 kB [1] This second behavior looks wrong to me, as it downgrades the RDEPEND of spam and thus spam becomes unusable. Try: emerge -1av --complete-graph bacon Unless --complete-graph is specified emerge won't pull in the entire dependency graph, thus won't notice the dependency-spec of app-test/spam. Using -D combined with the world set when updating your system yields the same result as that also pulls in the entire dependency graph. Unless the entire dependency graph is pulled in emerge only tries to satisfy the dependencies of the packages given on the commandline, and since there's no connection between app-test/spam and app-test/bacon, and emerge doesn't do reverse deps when adding something to the dep-graph, it doesn't notice that app-test/bacon and app-test/spam has conflicting dependencies Using --complete-graph is noticably slower since it slows down dependency calculations, but it should (IMHO) really be the default since these conflicts shows _before_ anything breaks.
Re: [gentoo-portage-dev] Conflicting RDEPENDS
On Fri, May 29, 2009 at 11:33:31AM +0200, René 'Necoro' Neumann wrote: Patrick Börjesson schrieb: # emerge -1av bacon These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] app-test/eggs-1 [2] 0 kB [1] [ebuild N] app-test/bacon-1 0 kB [1] This second behavior looks wrong to me, as it downgrades the RDEPEND of spam and thus spam becomes unusable. Try: emerge -1av --complete-graph bacon Ok - this works ... IF spam is in world. If I installed spam with --oneshot, it won't work either. Why exactly would you want to use --oneshot for a leaf package that is not depended on by any other package in the world set? If spam IS depended on by any other package (recursively) in the world set, it will be pulled in by --complete-graph, but that's not the case here if i understand it correctly, thus it's a package that you explicitly wanted installed, thus it belongs in the world set, and you should thus not use --oneshot for it.
Re: [gentoo-portage-dev] paraller compile portage improvement (package number of threads mark)
On 2008-08-02 12:14, litlle girl uttered these thoughts: Iproved emerge command will be able to compile two or more packages (each 1 thread marked) at the same time (if this packages don't depend on each other). Then wait until compilation ends, and start multithread marked packages compilaton. Packages can be sort to compile one core/thread packages at the same time. This can be good solution until programers change code to multi thread compile. Functionality of the sorts have been included in =portage-2.2_rc2 http://planet.gentoo.org/developers/zmedico/2008/07/23/portage_parallel_builds -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpTt4Ge2yKzX.pgp Description: PGP signature
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On 2008-07-20 17:38, Peter Volkov uttered these thoughts: В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет: Which part of the 'Problem' section in the GLEP didn't you understand? Do you seriously consider not being able to add or change global scope functions in future EAPIs to be a non-issue, or were you ignoring those two bullet points? I've read all previous discussions but still miss answer to the question: Why is it impossible to state that .ebuild extension is for bash based ebuild make package manager get and filter EAPIs based on EAPI variable? Because that would still not allow global scope changes, because in order to get to know which EAPI the ebuild is written in, you have to actually source the ebuild, and by then it's too late. Unless you introduce some inane requirement that the EAPI variable has to be the first thing stated in the ebuild and force the PMs to extract that value before actually starting to parse the ebuild. Now, if _that's_ not an ugly solution, i don't know what is... You have to know _how_ to interpret an ebuild _before_ you actually start doing it. Note, I assume that we can do not backward-compatible changes in PM, we just need to wait enough time to start using it. But taking into account that the features that will make use of this GLEP55 are still not so evident I don't see any problem to wait. In any case I'd like to understand why should we start support this hell of extensions. Reasons for the change has been stated before, and the one i just explained is the main one so far as i know. -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpG4XHQmlNIp.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Council meeting summary for 10 July 2008
On 2008-07-16 14:50, Doug Goldstein uttered these thoughts: Tiziano Müller wrote: This also involves increasing the XML support in every package manager, which is not going to be a small undertaking. I'd say near to impossible in at least one case -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpA39JLVKzBB.pgp Description: PGP signature
Re: [gentoo-portage-dev] Connecting source and binary packages.
On 2008-07-16 14:12, Jason Cipriani uttered these thoughts: I have mozilla-firefox-bin installed, but when I update things that depend on firefox (such as epiphany), they attempt to get mozilla-firefox instead. How do I make emerge realize that I already have the binaries installed and don't need the source distribution? man portage, search for package.provided -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgppswH83ZlKS.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: auto-detection of unpack dependencies
On 2008-07-15 21:40, Tiziano Müller uttered these thoughts: Marius Mauch wrote: As a result of Cardoes earlier mail we talked a bit about possible solutions in #gento-portage, and I suggested to let portage automatically inject the deps based on SRC_URI pattern matching. A mapping of extensions and their unpack deps would be kept in the tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' [snip] So, is this something ebuild maintainers would like in general, or does such a feature cause you nightmares? Yes. I think that's something which should be done manually. Indeed, the correct solution would be to state the deps manually in each ebuild that requires the dep. But in this case it would mean adjusting the DEPEND string of pretty much the entire tree. Until such measures are stated required, this would be a good middle ground, no? The same thing would apply to gcc if all real depends were to be required in all ebuilds, but that would pretty much have to be manually stated since the PM wouldn't be able to judge that by automatic measures. This, on the other hand, can (at least partially) be handled automatically for the ebuild-devs on the PM side of things. Patrick B -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgp6ynNOqGBSu.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: RFC: auto-detection of unpack dependencies
On 2008-07-15 22:58, Tiziano Müller uttered these thoughts: Patrick Börjesson wrote: On 2008-07-15 21:40, Tiziano Müller uttered these thoughts: The same thing would apply to gcc if all real depends were to be required in all ebuilds, but that would pretty much have to be manually stated since the PM wouldn't be able to judge that by automatic measures. That's a different thing: A dependency on gcc just ensures that gcc is installed not that it is actually used to build a package. Not quite sure what you mean here. I'm just saying that if you want to go the route of stating all deps explicitly, you have to state in the ebuild (DEPENDS) that gcc is needed to build the package, if that's the case. I'm not against this at all (I'm not an ebuild-maintainer), i just gave an example for when there's no sane way for the PM to automatically inject a dependency. And for such a dependency we'd need new ways to express deps since gcc is only needed when building packages not when it gets installed from a binpkg. Portage (or whichever PM you want) uses it's own way of packaging binpkgs, so for it to be able to extract those binpkgs, a RDEPEND on the applications used for that specific task has to be stated in the _PM_ itself. It isn't the ebuild deciding which format it's gonna be packaged down into. I'm far from sure about this, but DEPENDS aren't really taken into consideration when installing from a binpkg, so stating (f.ex) gcc in DEPENDS wouldn't draw it in when you install the package from a binpkg. It is however known to the ebuild-maintainer and/or the PM which format the source is packaged in, so that's a sane thing to put in DEPEND, whether by manual editing of the ebuild/eclass, or by automation in the PM. Patrick B -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpXag0IuOJCu.pgp Description: PGP signature
Re: [gentoo-dev] [EMAIL PROTECTED]
On 2008-06-20 07:25, George Prowse uttered these thoughts: Ciaran McCreesh wrote: On Fri, 20 Jun 2008 00:17:56 +0400 Ivan Chernyavsky [EMAIL PROTECTED] wrote: Recently I've subscribed to this list because I thought this is the right way to start being involved in Gentoo development process --- I thought technical discussions are of most importance here. You are sadly mistaken... snip Once again, all accusations and no proof. How much _technical_ discussion have you seen on the list lately? -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpetu6ClyyzR.pgp Description: PGP signature
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On 2008-06-19 04:09, George Prowse uttered these thoughts: In the end, PMS is just a way for them to spread their own agenda and force it on both the developers and the users so maybe it would be best for all if paludis and it's developers were to concentrate on making paludis for a different distro. Trollix may be a good place to start... I'm pretty sure they have no leverage what so ever to force the Gentoo community into ANYTHING, so kindly lay off the exaggerations. If you're not happy with the way that PMS is developed, fork it. It's open source. That's the way open source development works; if you're not happy with something, fix it (iow, do the damn work yourself instead of complaining). I'm not a proponent for any side here, but i'm getting mighty fucking irritated of the personal attacks. I know it's impossible for some people, and it's probably an unreachable ideal, but could everyone just think a couple of extra seconds about the technical aspects instead of just lashing out because someone indirectly calls you an idiot when you mess up. -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpSHxqxHyegJ.pgp Description: PGP signature
Re: [gentoo-dev] -bash: no job control in this shell
On 2008-06-19 00:46, vinod kumar uttered these thoughts: I am geting this error when I login to my gentoo uml it becomes very difficult to stop any service. I am able to ssh into this uml from the host without any errors. Any idea how to turn the job control back on...? I have googled for couple of days in vain. please help me .. Sorry, but this list is not the right place for support. The gentoo-user mailing list is what you want. Patrick B -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgp5Ub5qZzKuE.pgp Description: PGP signature
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On 2008-06-19 18:32, Nirbheek Chauhan uttered these thoughts: On Thu, Jun 19, 2008 at 5:58 PM, Patrick Börjesson [EMAIL PROTECTED] wrote: On 2008-06-19 04:09, George Prowse uttered these thoughts: In the end, PMS is just a way for them to spread their own agenda and force it on both the developers and the users so maybe it would be best for all if paludis and it's developers were to concentrate on making paludis for a different distro. Trollix may be a good place to start... I'm pretty sure they have no leverage what so ever to force the Gentoo community into ANYTHING, so kindly lay off the exaggerations. The point is that their replies to the mailing list waste a lot of time and energy since people will *always* reply to them. Even if half the community decides (out of the half that hasn't unsubscribed or left because of them) not to reply to them, someone from the other half will reply, and the thread will again spiral downwards. So how is that the Paludis guys fault? If you don't even expect your guys (ie. official Gentoo Developers) to handle a conversation over a mailinglist in a decent manner, how can you expect that from anyone else? I recommend seeing (at least) the first 5-10 mins of http://video.google.com/videoplay?docid=-4216011961522818645 (posted by Roy Maples in this same thread) Oh, I watched the entire thing, thank you. And from it i came to the conclusion that the Paludis folk aren't the ones being more poisonous. Sure, Ciaran can be an asshat at times, but he also brings up valid points most of the time (and by most i mean extremely close to always). The closest point of the Identification part of that presentation that I could find applying to Ciaran would be Attempts to deliberately rile people, which doesn't even apply since he's personally insulting single individuals when he does it, and not the entire community. If you're not happy with the way that PMS is developed, fork it. It's open source. That's the way open source development works; if you're not happy with something, fix it (iow, do the damn work yourself instead of complaining). I completely agree. They should stop pushing it in everyone's faces. We all know PMS exists. When the developer community thinks it's ready, council will approve it. How exactly are they pushing it in everyone's faces? Actually, there's not much mension of PMS at all from the people actually working on PMS, but rather mension of EAPI. And that's when it's actually relevant. And EAPI _was_ deemed relevant quite a while back if i remember right (can't link to a specific discussion). And how exactly is the developer community going get to the point when they think it's ready without any discussion about it? I'm not a proponent for any side here, but i'm getting mighty fucking irritated of the personal attacks. I know it's impossible for some people, and it's probably an unreachable ideal, but could everyone just think a couple of extra seconds about the technical aspects instead of just lashing out because someone indirectly calls you an idiot when you mess up. The problem, of course, comes up when one side likes to mix technical replies with personal attacks[1][2][3][4][...]. 1. http://archives.gentoo.org/gentoo-dev/msg_23e836c773616f0e816f3c421900e1f1.xml 2. http://archives.gentoo.org/gentoo-dev/msg_3bb49516dc83b9f4d8f80a4e67fa7a84.xml 3,4,... Many many more. I don't intend to waste time searching for them. So you expect one side of the interraction (Ciaran in this case) to just sit silently and accept the insults, while he on the other hand can't say shit? Double standards anyone? -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpedeqowdikt.pgp Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
On 2008-06-10 15:50, Fernando J. Pereda uttered these thoughts: On 10 Jun 2008, at 15:46, Joe Peterson wrote: Also, I'm not sure reading XML is a problem at all - python has good libs for this already. Reading XML files is easy, but it makes certain codepaths much much slower. Not a good 'feature'. ... AND there's no requirement for the PM to be written in python or any other language currently in use. -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpuqnCKU4eqn.pgp Description: PGP signature
Re: [gentoo-dev] Re: Nominations for council
On 2008-06-05 15:34, Ryan Hill uttered these thoughts: On Thu, 5 Jun 2008 22:41:40 +0300 Samuli Suominen [EMAIL PROTECTED] wrote: Tue, 3 Jun 2008 05:52:35 + Ferris McCormick [EMAIL PROTECTED] kirjoitti: I think nominations are open. I nominate Then I'd like to nominate (mostly same ones again) flameeyes vapier dberkholz aballier ingmar just picking a random mail to reply to. gentoo-project people! this is why it exists. /analretentive Actually, it was stated in the originating mail (starting the nomination period) that All nominations must be sent to the gentoo-dev mailing list. -- () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpK9wR9gsaPV.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Gratuitous useflaggery (doc and examples)
On 2006-03-04 20:47, Ferris McCormick uttered these thoughts: On Sat, 4 Mar 2006, MIkey wrote: Ferris McCormick wrote: I misinterpreted what you wrote. I thought you meant physically included in the package, not installed from a binary package. I just completely read what looks like a reasonable request and turned it into nonsense without thinking about it, I guess. I am not so sure you misinterpreted me, because when I specify -doc and emerge -B a package, I don't want docs installed OR in the binary package that is generated. I want the behavior of USE flags to be consistent. If I set -ssl and generate a binary package for apache2, the packaged up libraries should not link with ssl libraries. The same should apply with -doc. That happens now, I believe. The following should all install the same thing: USE='-doc' emergeblah USE='-doc' emerge -b blah USE='-doc' emerge -B blah ; emerge -k blah USE='-doc' emerge blah; quickpkg blah; emerge -C blah; emerge -k blah Assuming all dependencies are satisfied. (The binary package is built from the image which is going to be installed and carries the USE flags with it. If the docs aren't there, they're not there. Or at least, the binary package carries the '-doc' use flag along with it so the docs won't be installed.) It seems that INSTALL_MASK works only at merge time, so that if you build a package at one machine (with INSTALL_MASK set to f.ex. /usr/share/doc) and install it on the same machine, you get the expected behaviour. But the INSTALL_MASK:ed directories and their contents are still present in the binary package since they're not filtered out until the merge-step. So if you then want to merge this package on a different machine, and forget to set INSTALL_MASK you still get everything originally present under /usr/share/doc installed. One might argue that INSTALL_MASK should apply for binary-package-building also, but so is not the case at the moment. Regards, Patrick Börjesson -- / () The ASCII Ribbon Campaign - against HTML Email \ /\ and proprietary formats. pgpzfuJqAI1ms.pgp Description: PGP signature
Re: [gentoo-portage-dev] Re: Plausible idea for GLEP 19?
On 06/01/22 17:47, Mikey wrote: On Sunday 22 January 2006 16:56, Marius Mauch wrote: That's not really what you want. -s updates might (will) be overlaid with version or revision bumps from time to time, for this to be of any use it has to happen at the resolver level (visiblity filter). Normal emerges would take -s2 over -r1 or -s1. The change is transparent when not in glsa-only mode. You didn't understand what I said. If you just play around with the output info you'll miss updates. How will I miss updates? Standard actions (system world) or myfiles would work the exact same as they do now, they just consider a new revbump specifier in the digraph calculation. The non-standard action that I am proposing, call it emerge glsa-only, would take the output from emerge -Du world and filter out anything from the resulting package list except for -s packages. I will only miss updates that are not strictly security related. If there is no security-only related update, i.e. I have to upgrade to the next version, glsa-check will report it and I will have to manually update. The problem with your reasoning is that portage only reports the highest upgrade (from it's point of view). So if you have package A-1.0 installed and two possible upgrades, say A-1.0-s1 and A-1.1, then portage will chose the highest of the two. So the output from that command would be: | These are the packages that I would merge, in reverse order: | | Calculating world dependencies ...done! | [ebuild U ] the-cat/A-1.1 [1.0] .. It will not output the following: | These are the packages that I would merge, in reverse order: | | Calculating world dependencies ...done! | [ebuild U ] the-cat/A-1.0-s1 [1.0] .. So you _will_ miss upgrades if you only filter the output of emerge in your solution and expect to get all security related upgrades relating to the package you're using. -- / Patrick Börjesson \ --- / () The ASCII Ribbon Campaign - against HTML Email \ /\ and proprietary formats. pgpMr3Pn7tZND.pgp Description: PGP signature
Re: [gentoo-portage-dev] Plugin framework
On 05/11/14 09:53, Brian Harring wrote: On Mon, Nov 14, 2005 at 10:38:28PM +0900, Jason Stubbs wrote: On Sunday 13 November 2005 11:57, Brian Harring wrote: Â filenames. OT, but return of the funky 'A's... Curious if others are seeing it, or if my nano/mutt setup just plain sucks. I don't see them in Jason's emails, but in your replies they're there... Don't know why, but maybe some sort of locale- or encoding-setting somewhere in your mutt config? -- Regards, Patrick Börjesson PGP signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21792A5D PGP fingerprint: 74AF D4EF 6BDE CF77 16BE 6A29 CDB8 7607 2179 2A5D () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpC5PDTTn8oK.pgp Description: PGP signature