Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
William Hubbs wrote: The reason the split happened is pretty straight forward, and every other justification for continuing it was come up with after the fact. I keep hearing this, but I really don't see how it's relevant. I'm sure you'll find lots of things in your life that you use for some purpose other than what they were originally invented for¹, and there's no reason why /usr should be any different. All that matters is whether or not the newer reasons for having separate /usr actually provide a benefit. [1] http://en.wikipedia.org/wiki/Coca-Cola#19th_century_historical_origins
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
William Hubbs wrote: And I would argue that the maintenance cost of having separate /usr in a general sense is much higher than the benefit it provides. That's a legitimate point (not that I necessarily agree or disagree as I'm not the one who's tried to make it work) - perhaps I should have acknowledged that it's still a trade-off. I'm just trying to get rid of the meme that whatever benefits do exist somehow don't count because they weren't planned in the original Unix design.
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
Rich Freeman wrote: [...] and the point that many things break in namespaces without the symlink, since /etc/mtab does not reflect the state of the namespace. The latter in particular seems like a pretty fundamental limitation - the very concept of /etc/mtab is that mounts are global, and the design of linux is that mounts are NOT global. If only someone would invent some sort of kernel feature that could make the name /etc/mtab refer to different files in different processes
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
Rich Freeman wrote: However, FWIW, linux namespaces cannot be used to have only a single file appear differently to different processes. Mount namespaces can only operate at the directory level. So to work around that limitation we insist that everyone change how their systems are set up, and still have to reintroduce mtab under a different name (utab, hidden away under /run) because /proc/self/mounts *doesn't* contain everything that's supposed to be in mtab after all? If someone decides they want to use, say, different DNS servers in different namespaces, should we make the kernel store the server IP addresses, add a /proc file that dumps them out in the expected format, and demand that everyone replace their /etc/resolv.conf with a symlink to /proc/self/resolv.conf? Or maybe, if people want namespaces, they can implement them properly, in which case it becomes literally a self-solving problem.
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
Mike Gilbert wrote: This is a horrible example. /etc/resolv.conf is a configuration file for code that lives entirely in userspace. Of course it makes no sense to shove that into the kernel. My point is that it's silly to have a hard-coded special case in the kernel for mtab, especially if it doesn't do the job properly and requires an extra utab file, when the general solution could work for any file and wouldn't require any changes when the namespace feature isn't in use.
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
Patrick McLean wrote: This is not true. Bind mounts can be performed on a single file, and bind mounts are part of mount namespaces. Granted the target file _must_ exist (it could be a dead symlink, or a symlink to /dev/null) before performing the bind mount. Well that's even better then. :-)
Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?
On 1 May 2013 02:52, Ryan Hill dirtye...@gentoo.org wrote: Then the person implementing the code for Paludis is either a monkey or a robot*. *or both (?!) Alternative possibilities include ninja, zombie and wizard.
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
On 13 September 2012 06:48, Ulrich Mueller u...@gentoo.org wrote: On Thu, 13 Sep 2012, Brian Harring wrote: For SANDBOX_*, while that's a PM internal, that's a bit of a grey zone; regardless, we can actually address that via extending the sandbox functions a bit: addwrite [-r|--remove] pathway # for example, to do a removal. It's nice to be able to do local SANDBOX_WRITE=${SANDBOX_WRITE} and then allow bash to restore the old value at the end of the function, regardless of how it exits. It's not the end of the world to lose this, but it would be a bit of a shame IMHO - having to do it manually seems a little error-prone. For instances where the sandbox needs to be turned off for a command- we do the same thing we did w/ nonfatal; sandboxless the command and args To start the bikeshedding: For some reason I associate less (the pager) in a sandbox with this. ;-) Maybe nosandbox or sandboxoff? sansbox? *flees*
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On 10 September 2012 15:48, William Hubbs willi...@gentoo.org wrote: All, I have a regression in OpenRc wrt netplugd [1]. In researching this program, I have found that it and ifplugd, which is the alternative, have been unmaintained for years. Also Debian has declared netplugd to be obsolete in favor of ifplugd. The page referenced on the bug that says so appears to be talking about a different package than the one we have in the tree - they have different authors stated, and also, for the one we have the package is called netplug, with the executable called netplugd, whereas for the one declared obsolete the package itself is called netplugd. Does anyone have any thoughts about whether we should keep OpenRC support for one or both of these? There are a few options for this functionality (that I'm aware of): 1) netplug: never used it so no particular comments. 2) ifplugd: what I'm using now. I can't remember if there's a particularly good reason why I chose it, but I suspect it might have been for the audio feedback it provides when it detects a connection or disconnection. This probably isn't compelling enough by itself to keep the package if we'd otherwise want to remove it, but it is quite nice. 3) wpa_supplicant: supposed to be able to do this even for wired interfaces, but I just did some experimenting and it seems broken - it thinks the cable is plugged in even when it isn't. 4) dhcpcd: not sure when it was introduced, but current dhcpcd can detect when the link goes up and down, and request/renew its lease when it comes up. The only wrinkle that I can see here is that, if no ifplugd/netplug/wpa_supplicant is configured, OpenRC waits for it to receive a lease when starting the interface, rather than allowing it to background itself. So for dhcpcd, it might be enough to just make OpenRC aware that it doesn't need to wait for a lease when starting the interface. Keeping at least one of the other options working would still be required for other DHCP clients if they don't have similar functionality, or non-DHCP situations where it's necessary to do some sort of reconfiguration when the network is (dis)connected (such as OpenRC's arping module), assuming anyone cares about those of course. Thanks, William [1] https://bugs.gentoo.org/show_bug.cgi?id=427088
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Ian Stakenvicius wrote: Technically it could, but the issue here would be what you are going to do with a has_version check on an IUSE_RUNTIME dep -- the package should do filesystem-identical installs no matter what status of IUSE_RUNTIME flags, so whatever one would do with a has_version check would have to not change any part of the build or installation. In principle it would be used for more or less the same thing as it would in a dependency, i.e. check whether the runtime-only dependencies for that feature are satisfied - the difference being that the package can specify arbitrary if-yes and if-no behaviours, rather than just fail the dependency resolution or not. (Modulo the problem being discussed in this subthread, that a no answer isn't reliable.) For example, some tool used during the build might have a slow mode that always works, and a fast mode that requires some other program to be installed and that has to be requested explicitly. So the package that uses the tool might want to do something like src_compile() { if has_version dev-util/buildtool[fast]; then buildtool --fast else buildtool fi }
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Marien Zwart wrote: Possible solutions: a) automatically rewrite the dep as postscript? ( app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) There may be more than one version of docmangler, with a postscript flag with different effects (IUSE_RUNTIME or full IUSE, different dependencies). That means this kind of rewriting would have to be done based on the dependencies of the docmangler installed at the time this package gets built, which seems like entirely too much magic, and... To clarify, I meant rewrite the dep in docmangler itself, and not necessarily on disk in the VDB or wherever, just in memory when parsing it. But as I said, I don't like that idea anyway, I just mentioned it for completeness. b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make sense in that case to disallow them in !foo-style conditionals in the dependencies of the package itself, as that could cause similar paradoxes) this seems generally impossible, as the same USE flag may be IUSE_RUNTIME in only some versions of docmangler. True. We could declare that in situations like that the developer just needs to be more careful, but then it's not that much better than c) c) don't address it in the spec itself, and require people to manually write the dep in the blocker form if it's required I would be in favor of leaving this up to the writer of the coolapp ebuild, especially as if docmangler is currently using a full USE flag for postscript this is already currently broken. Well, in theory if it's a normal USE flag then disabling it should actively remove the Ghostscript support from docmangler, even if Ghostscript happens to be installed, but maybe it doesn't always work out that way.
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Michał Górny wrote: Hello, A simple solution to a program long-unsolved. In GLEP form. Just a couple of minor points/nitpicks: 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE, should REQUIRED_USE be re-verified: a) for every dep resolution b) when the package is involved in the resolution for some other reason (not necessarily being reinstalled, just when the resolver has some reason to look at it) c) something else? I think b) should be sufficient (and probably easier to implement), but is there any reason why it wouldn't be? 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of package B being disabled, but it's unlikely to be useful. To make this more concrete, a fictional but vaguely plausible example: app-text/docmangler: # links to poppler to handle PDFs, and can use Ghostscript for # PostScript support if available IUSE=postscript IUSE_RUNTIME=postscript DEPEND=app-text/poppler RDEPEND=${DEPEND} postscript? ( app-text/ghostscript ) app-misc/coolapp: IUSE=doc # if Ghostscript is installed, docmangler uses it for both # PostScript and PDF files, but Ghostscript misrenders our PDFs DEPEND=doc? ( app-text/docmangler[-postscript] ) Here, the [-postscript] dep would force the user to disable that flag, but it wouldn't do much good because Ghostscript would still be installed. This doesn't happen with regular USE flags because (if the ebuild is written correctly) disabling the flag removes the feature even if its dependencies happen to be installed. Possible solutions: a) automatically rewrite the dep as postscript? ( app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make sense in that case to disallow them in !foo-style conditionals in the dependencies of the package itself, as that could cause similar paradoxes) c) don't address it in the spec itself, and require people to manually write the dep in the blocker form if it's required d) something else? a) is pretty icky IMHO, especially if the flag pulls in multiple packages. I could live with either b) or c), but b) is less flexible and c) leaves a potential trap for the unwary. Any opinions?
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Michał Górny wrote: On Thu, 21 Jun 2012 20:05:46 +0100 David Leverton levert...@googlemail.com wrote: 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE, should REQUIRED_USE be re-verified: a) for every dep resolution b) when the package is involved in the resolution for some other reason (not necessarily being reinstalled, just when the resolver has some reason to look at it) c) something else? Well, I don't understand the difference between a) and b) in your case Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and that I have it installed and then modify one of the flags it uses in my configuration, but don't run any PM commands. Then suppose I install a Gnome package. Normally installing a Gnome package wouldn't require the PM to go anywhere near kde-meta, but being strict about revalidating REQUIRED_USE would require it to look through every installed package, just in case any have IUSE_RUNTIME and REQUIRED_USE set, for every installation command. Is that necessary? but the idea is that REQUIRED_USE should be re-verified if either enabled USE flag list or REQUIRED_USE changes. Would that mean the enabled USE flag list should be updated in the VDB every time REQUIRED_USE is checked, even when the package isn't being reinstalled? I think it would probably be easier to just recheck REQUIRED_USE, without trying to figure out whether any of the IUSE_RUNTIME flags were changed, it's just a question of how eager we want to be. 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of package B being disabled, but it's unlikely to be useful. To make this more concrete, a fictional but vaguely plausible example: Possible solutions: a) automatically rewrite the dep as postscript? ( app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make sense in that case to disallow them in !foo-style conditionals in the dependencies of the package itself, as that could cause similar paradoxes) c) don't address it in the spec itself, and require people to manually write the dep in the blocker form if it's required d) something else? Good observation. I think b) is the best solution since forced removal of random dependencies is a very bad idea (and misuse of blockers). One case that I forgot to mention before: if some package does something like if has_version app-text/docmangler[postscript]; then # ... else # ... fi Here, again, the else branch can lead to incoherent results as it can't assume that the postscript flag being disabled means Ghostscript isn't installed, and this one can't be forbidden by restricting the allowed dep forms. I think we'd have to just say don't do that then
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Michał Górny wrote: No, of course not. Otherwise, every package manager run would practically require it to re-validate all packages in the tree (possibly not only installed ones). Package manager must ensure the flags are valid when package is in the graph. I would think of IUSE_RUNTIME as a last-step action where packages were in the graph for rebuild already but the rebuild is disabled as being unnecessary. That's what I thought, was just making sure we're on the same page. No, the USE flag list in vdb may be updated every time the package gets into the graph with changed runtime flags. I don't consider that necessary, however. Just a nice backwards compatibility feature for other applications looking at vdb. 'K Well, as I see it restricting is more of a policy than a technical requirement. As long as we're clear on which it is, and what restrictions if any the PM can/should impose... But in the current form, the spec doesn't allow passing IUSE_RUNTIME flags to has_version() so we're on the safe side :P. True. Do we want to keep it that restrictive?
Re: [gentoo-dev] multiprocessing.eclass: doing parallel work in bash
Mike Frysinger wrote: exec {mj_control_fd}${mj_control_pipe} I'll have to remember that feature, but unfortunately it's new in bash 4.1, so unless we're giving up 3.2 as the minimum for the tree : $(( ++mj_num_jobs )) Any reason not to do just (( ++mj_num_jobs )) ? : $(( --mj_num_jobs )) : $(( ret |= $? )) Same.
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
Greg KH wrote: No one forces you to use any of this software if you do not want to. There are lots of other operating systems out there, feel free to switch to them if you do not like the way this one is working out, no one is stopping you. Or alternatively, the people who hate Unix could move to some other OS that suites them better, rather than trying to destroy what everyone else is perfectly happy with.
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
Zac Medico wrote: Isn't it presumptuous to say that they hate Unix? Maybe their vision of how they'd like Unix to be is just different from yours? If how they'd like Unix to be goes so blatantly against its fundamental design principles then I think it's reasonable to say that they hate it.
Re: [gentoo-dev] Chromium bundled code
Luca Barbato wrote: On 03/05/12 16:18, Mike Frysinger wrote: you need to think bigger. Chromium supports joystick inputs (which come and go) for playing games in the browser, so udev makes sense. So is it using libudev to get that information? I guess would be possible to patch it out, probably dbus would cover that base as well. (As soon I have some time I might dabble with a dbus integration for mdev) If it really is just for joysticks etc it might be worth seeing if it can be made to use XInput instead. Maybe upstream had a specific reason not do it that way in the first place, but in general, X apps really shouldn't be touching the input devices directly.
Re: [gentoo-dev] Chromium bundled code
Mike Frysinger wrote: On Friday 04 May 2012 15:25:58 David Leverton wrote: If it really is just for joysticks etc it might be worth seeing if it can be made to use XInput instead. Maybe upstream had a specific reason not do it that way in the first place, but in general, X apps really shouldn't be touching the input devices directly. why require X ? :) -mike I wasn't aware that Chromium on Linux supported anything else (and at least the current ebuild has hard deps on X libraries), but when it is running on X it ought to follow X conventions, even if it does something else in other circumstances.
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
Zac Medico wrote: So, here's a description of the whole algorithm that I'd use: [snip] I think the following is equivalent, but simpler and more general since it doesn't have to mention details like ** and friends that aren't currently in PMS, and doesn't assume that the rule for handling KEYWORDS is simply does it contain at least one of the accepted values? (plus handling of ** etc). (For example, I can imagine something like accept the package if it has amd64, or if it has both ~amd64 and x86 being potentially useful for some people, although I don't think it's implemented anywhere at the moment.) 1) Pretend that all stable keywords in the package's KEYWORDS are replaced with the corresponding ~arch ones 2) If this would result in the package being masked by keywords (I forget the exact terminology Portage uses, but I'm sure you know what I mean), then apply the masks/forces from package.use.stable.*
Re: [gentoo-dev] Happy 10th birthday (in advance)
On 30 March 2012 14:25, Samuli Suominen ssuomi...@gentoo.org wrote: Back to year 2009? http://www.gentoo.org/news/20091004-gentoo-10-years.xml That never stopped anyone before http://en.wikipedia.org/wiki/Final_Fantasy_X-2
Re: [gentoo-dev] Packages up for grabs due iluxa retirement
On 19 March 2012 06:05, Samuli Suominen ssuomi...@gentoo.org wrote: dev-cpp/cppserv would need working dev-cpp/sptk and we have none: http://bugs.gentoo.org/show_bug.cgi?id=402149#c9 the only working versions got marked as obsolete by upstream due to undisclosed reasons whatever that means Not that I personally care, but it seems like this could be solved by just removing fltk support, rather than nuking it completely.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 18:56, Zac Medico zmed...@gentoo.org wrote: Whatever the arguments may be, the whole discussion boils down to the fact that the only people who seem to have a problem are those that have a separate /usr partition and simultaneously refuse to use an initramfs. I wonder if it might help to go through the benefits of having a separate /usr, and see whether they still work when /usr is mounted by initramfs. Hopefully that would either demonstrate that the initramfs approach is fine, or reveal a concrete problem with it so we can start talking about solutions. (For the record, I don't have a separate /usr, but mainly because when I've been setting up machines I've been too lazy to either 1) figure out how much space to allocate to each partition, or 2) learn how to use lvm so I don't have to worry so much about getting it right the first time. I'd prefer for the option to stay available, but not as strongly as some people do.) To start us off, the benefit that I'm mainly interested in (for potential future use, as stated above), and I realise this is probably pretty far down the list overall, is that OpenRC can run fsck at shutdown instead of boot for non-/ filesystems, so as long as / is small there won't be huge boot delays. I imagine using initramfs wouldn't affect this, as by the time the system's shutting down it shouldn't matter how /usr got mounted originally. It might be affected if fsck etc got moved to /usr as has been mentioned, but if that happened OpenRC would probably have to be modified to remount it readonly at shutdown rather than unmount it, and presumably that would allow the fsck to occur. Would anyone else like to continue with their own favourite separate-/usr reason?
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 21:04, Greg KH gre...@gentoo.org wrote: Haveing a separate /usr is wonderful, and once we finish moving /sbin/ and /bin/ into /usr/ it makes even more sense. See the /usr page at fedora for all of the great reasons why this is good. My point was examine, in detail, whether separate-/usr-with-initramfs has any disadvantages compared to separate-/usr-without-initramfs. Either it has, in which case we have a concrete argument against requiring initramfs (albeit possibly one that can be fixed), or it hasn't, which should hopefully convince at least some people to accept it.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 22:51, Greg KH gre...@gentoo.org wrote: Oh, that's simple, separate-/usr-without-initramfs will not work and will not be supported :) See, it's this we're doing it this way because we know best and we say so that upsets people. I'm trying to encourage everyone to get to the core reasons for having a separate /usr in the first place (not all of which are guaranteed to be mentioned on any specific wiki page), and logically analyse the potential disadvantages of using an initramfs in each situation. It may turn out that there are no disadvantages after all, but the analysis is still important, not only to make sure that we're making the right decision, but also to persuade everyone else that it's the right decision. Again, the fact that it works for some people today is pure luck, and odds are, it really isn't, but it's really hard to determine this given that the init system they are using doesn't provide a good feedback loop for this type of thing. Maybe it would be worth improving the init system to do so? Or maybe it wouldn't because using an initramfs is easier and has no drawbacks, but see above.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 23:44, Greg KH gre...@gentoo.org wrote: Oh, and somehow consensus will work? No, sorry, it will not. No, logical analysis will, as I said in the rest of my post which you conveniently ignored - either we conclude with evidence that there are no issues, which should settle the matter for reasonable people, or we discover that there are, in which case they have to be dealt with one way or another. I really don't see how anyone can object to that, unless they're worried they won't like the result How about the basic FACT that today, such systems do not work This is debatable at best. You can keep screaming but bluetooth won't work! until you're blue in the face, but that's not relevant at all to people who don't use bluetooth. and are not supported by a wide range of packages we support today. Isn't such support being removed by the same people who keep arguing that it's already not supported? That's like cutting half your employees' pay, and then insisting that you have to choice but to cut the other half's pay as well, in order to be fair. Yes, some people are lucky in that their systems don't have those packages, but others are not. The simple I use a bluetooth keyboard is one such example. People who only have a bluetooth keyboard can set their systems up in such a way that it works, just like how people who have / on lvm can set their systems up in such a way that that works. That's not in itself a reason to force it on everyone. It is strange to watch people somehow think that if they complain enough, or feel strongly enough, something is going to change here to make this basic fact go away. If by the basic fact you mean that plenty of people are quite happy doing what's worked just fine for years, then yes.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 23:47, Zac Medico zmed...@gentoo.org wrote: It's more about what we're _not_ doing that what we're doing. Clearly something must have changed in udev 181 to make /usr-without-initramfs not work anymore, and someone must have done something to make that change happen, unless udev has aquired the ability to evolve by itself.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 15 March 2012 00:45, Zac Medico zmed...@gentoo.org wrote: You're pointing your finger at udev, but the udev change is just a symptom of a more general shift away from supporting the / is a self-contained boot disk that is independent of /usr use case. OK, so there are multiple instances of people not not doing anything rather than just one. I think that supports my point more than it refutes it.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Mar 8, 2012 3:29 PM, Zac Medico zmed...@gentoo.org wrote: Something like DEPEND=foo bar is also valid bash, and yet we don't allow that either because foo bar does not contain valid dependency atoms. There's a bit of a difference between caring about the value of a variable and caring about what syntax was used to assign it
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 7 March 2012 21:07, Alexis Ballier aball...@gentoo.org wrote: As i understand it, $PM will need to try the regexp tingy on any ebuild anyway, guess the EAPI then source the ebuild with the right sourcer to get the real EAPI and compare it. Not exactly... the idea with proposal 2) is that the header comment becomes the One True Way to set the EAPI, so it wouldn't be guessing as such, and ebuilds wouldn't be allowed to change it during sourcing any more than they can redefine PV or the like. As mentioned, 2b) still risks a mismatch between the header and the assignment, but hopefully that would be temporary and the assignments could be dropped eventually. (And I'd suggest that the header EAPI is still considered authoritative if present - the mismatch check should probably be a hard error, or if not it should generate a warning and use the header value. There should be minimal if any risk of this changing behaviour for any existing ebuild, since existing ebuilds almost certainly won't match the chosen header syntax.) As for my opinion, I would prefer 2a), or 2b) as a second choice. IMHO it's much simpler and cleaner to come up with a strict, well-defined header format than to try and work within (an arbitrarily restricted version of) bash syntax.
Re: [gentoo-dev] new virtual/yacc
On Aug 8, 2011 12:22 AM, Mike Frysinger vap...@gentoo.org wrote: virtual/yacc which has || ( sys-devel/bison dev-util/yacc ). No dev-util/byacc?
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
On Saturday 30 July 2011 14:55:23 Samuli Suominen wrote: Someone mentioned NFS mount on /usr. Do we have other reasons? How many users that might be? From /etc/conf.d/fsck, seems like a reason to keep the / FS as small as possible to reduce the amount of time spent waiting during boot: # fsck_shutdown causes fsck to trigger during shutdown as well as startup. # The end result of this is that if any periodic non-root filesystem checks are # scheduled, under normal circumstances the actual check will happen during # shutdown rather than at next boot. # This is useful when periodic filesystem checks are causing undesirable # delays at startup, but such delays at shutdown are acceptable. fsck_shutdown=YES
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
On Saturday 30 July 2011 18:38:55 Rich Freeman wrote: On Sat, Jul 30, 2011 at 1:20 PM, David Leverton From /etc/conf.d/fsck, seems like a reason to keep the / FS as small as possible to reduce the amount of time spent waiting during boot: Well, that only really has a benefit if the system can do something useful between the time that root is mounted and /usr is mounted, which is probably a no. Not quite sure what you mean there... I meant that OpenRC lets you move non-/ fscks to shutdown, but you still have to wait for / to be checked during boot whenever it's due, so it's good to have it small so you don't have to wait too long.
Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo
On 6 October 2010 10:20, Luca Barbato lu_z...@gentoo.org wrote: We discussed that to death, you are wrong abusing overlinking in your pet project and what you were asking for is exactly the as-needed behaviour. Clearly you have no clue what you're talking about here.
Re: [gentoo-dev] Re: .la files and their future on Gentoo
On 5 October 2010 23:38, Enrico Weigelt weig...@metux.de wrote: And for Distros, it doesnt make sense to try to support anything imaginable. Not breaking things that already work would be a decent compromise. I'm now working in embedded area (where static linking is quite common) for about 10yrs, and pkg-config has proven quite well here. (packages that dont provide .pc-descriptor yet, simply have to be fixed to do so ;-p). Libtool, on the other hand, always had been a nightmare. What about things that don't use pkg-config? If you say we don't support that, modify it to use pkg-config, does that mean you're willing to make Gentoo incompatible with Linux in general? (That question isn't just about .la files, it applies to any change versus upstream that affects interfaces between components.) Just to reiterate, I'm not trying to block anything here. I'm just asking for a small override so people with use-cases you (in general, not a specific person) haven't thought of can be happy. It doesn't have to be officially supported or anything. Is that really so unreasonable?
Re: [gentoo-dev] .la files and their future on Gentoo
On 2 October 2010 20:54, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: Given the recent activity around .la files and conflict about how to deal with them, I propose we discuss this issue in this mailing list, and take this issue to the council. That way, we can make a global decision, taking into account all the arguments for and against, find a balance, opt for a policy, inform users and developers about it and move on. While I do agree that the underlying problem we're trying to solve is worth solving, I do have a couple of small concerns about how it's being done. The first is that it seems people are judging whether a particular .la file is needed by checking whether anything currently in the tree needs it, but this doesn't take into account anything that /isn't/ in the tree yet. The second is that removing .la files everywhere makes it hard for people to experiment with alternative solutions, as testing an alternative would require modifying all the affected ebuilds to stop removing them. (And yes, I am interested in doing so myself, although time constraints mean it might not happening.) Would it be too much trouble to have a standardised variable that means .la files should be kept? It maybe /shouldn't/ be exposed as a USE flag because very few people will need it, but if it's easy to implement (maybe by having an eutils function to do the removal, checking the variable first) it would remove any objections I could imagine. As I said, these are minor points, and I wouldn't expect people to go to great effort to satisfy them. Just something to consider.
Re: [gentoo-dev] .la files and their future on Gentoo
On 3 October 2010 14:20, Richard Freeman ri...@gentoo.org wrote: Such a solution would also have the virtue of allowing the use of USE dependencies. So, you would only install the .la files from a particular library if another package actually needed them. Packages could also have USE defaults as seems logical to their maintainers and distro policy. That's a good point - I did suggest not putting it in USE to avoid cluttering things up for the sake of a use case that most people won't need, but being able to do USE deps would be nice. Maybe a USE_EXPAND_HIDDEN variable could be a compromise, but that itself could be confusing when a package wants to enable a flag that doesn't appear to exist. It probably depends on how often such a dep would actually be needed - I suspect not very often. Where this would get complex is if we want more than all-or-nothing resolution. The simplest USE approach would be to have it toggle all the .la files in the package. However, if you have 5 files that are essential, and 5 that are likely nothing but trouble it will be harder to manage that while still allowing full control. I guess careful use of local flags might work, in combination with some sane policy. I'm not sure if this is a use case that is even worth worrying about... I think that's unlikely to be a problem, but yes, local flags or the like could be used if it ever does come up.
Re: [gentoo-dev] .la files and their future on Gentoo
On 3 October 2010 15:29, Luca Barbato lu_z...@gentoo.org wrote: I think the simpler solution is that if it needs .la, before reaching the tree it has to be fixed... What I'm not keen about that is that using the .la files isn't really broken - if libfoo uses libtool, and some other software uses libfoo's .la files in a way that works with the upstream version of libfoo, then it ought to work with Gentoo's libfoo too. (This gets into arguments about what sorts of changes are appropriate for a distribution to make, versus being left to upstream.) Also, not every piece of software that people might want to use is going to go into the main tree - people can use Gentoo to develop their own software (and might have their own ideas (or their company/project's ideas) about what parts of libtool it's appropriate to rely on), use packages from overlays, compile other people's software outside the package management system, run precompiled binaries, etc. Again, from here I'm sure you can have a big discussion about whether libraries in the tree exist only to support applications in the tree, or whether they're products (for want of a better word) in their own right. Again, maybe not earth-shatteringly important issues, but I do think these should at least be considered when deciding the policy.
Re: [gentoo-dev] New eclass: scons.eclass
2010/8/22 Michał Górny gen...@mgorny.alt.pl: src_compile() { scons \ $(scons-use unicode) \ $(scons-use gnutls ssl gnutls openssl) \ ${MAKEOPTS} || die # expands into: # scons unicode={1|0} ssl={gnutls|openssl} -jN || die } It might be slightly nicer to have an escons function that adds the modified MAKEOPTS to the command line and calls die by itself. Besides making it easier to use, that would provide a single place to add additional functionality (perhaps an EXTRA_ESCONS user variable analogous to EXTRA_ECONF, for example).
Re: [gentoo-dev] RFC: Reviving GLEP33
On 12 August 2010 08:51, Ben de Groot yng...@gentoo.org wrote: Exactly. This is Gentoo. Let Exherbo devs go develop their own distro and stop trying to interfere with Gentoo. It is time the council puts a definite stop to GLEP 55. I've already discussed this with you, but it seems you still don't get it. People are not defined as Gentoo people or Exherbo people. I can't speak for anyone else, but I am a sentient being with enough mental capacity to be interested in more than one thing at once - in other words, being an Exherbo developer doesn't in any way interfere with wanting to see Gentoo improve. There is no activity from Exherbo trying to push anything on Gentoo, there is only Gentoo users contributing ideas towards developing the distribution.
Re: [gentoo-dev] RFC: Reviving GLEP33
On 5 August 2010 04:27, Brian Harring ferri...@gmail.com wrote: If an EAPI adds a new global function that cannot set/influence EAPI, PM's that don't support that EAPI will spit complaints about 'missing command' during sourcing- however the PM will still see the EAPI value is one it knows it doesn't support, and act accordingly. You're suggesting a system based around ebuilds running commands that don't exist and ignoring the errors, which is a pretty blatant hack. While I don't think it's /absolutely/ out of the question, as I said earlier, I can see why some people would exclude it from consideration entirely.
Re: [gentoo-dev] RFC: Reviving GLEP33
On 2 August 2010 12:11, Brian Harring ferri...@gmail.com wrote: On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote: Hi folks, I've been told that my use of eblits in dev-lang/php is something I should get rid of as soon as possible. Suggested alternative by ferring: use elibs. There's a couple of hundred lines of repeated metadata between php-5.3.2 and php-5.3.3 - not identical, but similar enough that there would be gains from factoring it out, and elibs won't help with that. Am I understanding correctly in that you didn't use an eclass to avoid cluttering up the main eclass directory with something specific to this one package? If so, it sounds like what you really want is per-package eclasses (maybe with elibs as well to hold the non-metadata code), which aren't covered by GLEP33 but ought to be easy enough to add. There's a caveat here; imagine one of the current PM's processing an EAPI=4 (or whatever) ebuild that uses elib- specifically there will be a global scope function invocation of a function that doesn't exist. In the past, a minority of folk have raised complaints about this- it was never stated as best I know, but my assumption looking back is that it was due primarily to paludis getting pissy about ebuilds outputing anything during metadata sourcing I can't speak for other people who may have complained, but it seems to me that for ebuilds to be calling non-existent commands is fairly obviously wrong, even if the consequences happen to be benign - not the end of the world, but something that ought to be avoided if possible. (As far as paludis goes, it's more stdout that it used to get upset about than stderr.) Managers should implementat that functionality; orthogonal to it, we've got a few options for how to deal with an EAPI=4 ebuild being metadata sourced by a =EAPI3 PM (meaning, there will be a command not found spat to stderr during sourcing): [...] Regarding the stuff about other standalone repositories, I don't think it's a big deal to require them to carry a small amount of extra stuff (only if they actually start using elibs in any case), considering all the profiles, eclasses etc that they'd need anyway. Overlays based on the main Gentoo tree would be fine without any effort. (For the record, +1 for GLEP55 from me, but the reasons for and against don't need to be repeated yet again.) My suggestion? Split this into two, elibs, and eclass refactoring. Per-package eclasses would be beneficial IMHO regardless of the other eclass stuff from 33, might be worth thinking about those as another item (consistent with the existing design plans of course) if the rest isn't going to happen soon.
Re: [gentoo-dev] RFC: Reviving GLEP33
On 2 August 2010 22:40, Matti Bickel m...@gentoo.org wrote: On 08/02/2010 08:16 PM, David Leverton wrote: If so, it sounds like what you really want is per-package eclasses (maybe with elibs as well to hold the non-metadata code), which aren't covered by GLEP33 but ought to be easy enough to add. It's actually covered by GLEP33: http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring I interpreted that more as a way to organise the global eclasses, but yes, it could be used for per-package stuff too. I'd still prefer to have the eclasses next to the ebuilds they're meant to be used by, but that's just a detail (and as I say, could easily be added to the GLEP if anyone else wants it).
Re: [gentoo-dev] versionator.eclass: convert to eshopts_{push,pop}
On 19 July 2010 20:43, Mike Frysinger vap...@gentoo.org wrote: On Monday, July 19, 2010 03:38:39 Ciaran McCreesh wrote: On Sun, 18 Jul 2010 20:17:45 -0700 Alec Warner wrote: Can we do away with all the extra foo return bullshit and just set a trap? trap eshopts pop RETURN ? That strikes me as a horribly fragile way of doing things that's bound to come back and screw things up at some point... nifty in theory, but i'm inclined to agree with Ciaran -mike Is something like the below function too hideous (not massively tested, but it seems to work)? Usage is something like: [dlever...@shiny-one ~] $ foo() { shopt -p extglob; } [dlever...@shiny-one ~] $ eshopts_need foo -s extglob [dlever...@shiny-one ~] $ shopt -p extglob shopt -u extglob [dlever...@shiny-one ~] $ foo shopt -s extglob [dlever...@shiny-one ~] $ shopt -p extglob shopt -u extglob eshopts_need() { [[ $# -ge 1 ]] || die eshopts_need needs at least one argument local func=$1 shift local opts=( $...@} ) if [[ $1 == -[su] ]] ; then eval _eshopts_need_shopt_$(declare -f $func) eval $func() { local old=\$(shopt -p) $(declare -p opts) shopt \\${op...@]}\ _eshopts_need_shopt_$func \\...@\ local status=\$? eval \\$old\ return \$status } else eval _eshopts_need_set_$(declare -f $func) eval $func() { local old=\$- $(declare -p opts) set \\${op...@]}\ _eshopts_need_set_$func \\...@\ local status=\$? set +\$- set -\$old return \$status } fi }
Re: [gentoo-dev] versionator.eclass: convert to eshopts_{push,pop}
On 19 July 2010 21:30, Mike Frysinger vap...@gentoo.org wrote: i imagine this might be useful in some scenarios, but i think the more common usage is to enable things inline. otherwise, the exported API would need to be wrapped internally like: get_all_version_components() { eshopts_need _get_all_version_components -s extglob } It's meant to work to just define get_all_version_components with the assumption that extglob will be enabled, and then call eshopts_need in global scope right after. although, the method we have now also allows for disabling of shopts before calling `die`. not sure if that's important, but i think it's better to disable before all exit/termination points. That's a reasonable point. so unless their is a consumer now we can point to in the tree, i'm inclined to leave this alone. Fair enough. there are already eshopts_push/pop funcs that accomodate more things than the usage here, but i imagine you did it this way just to make testing in your shell easier -mike It was supposed to support everything the existing functions do (not everything demonstrated in the example for brevity), but I might have missed something.
Re: [gentoo-dev] versionator.eclass: convert to eshopts_{push,pop}
On 19 July 2010 22:11, Mike Frysinger vap...@gentoo.org wrote: you mean the people who want to use get_all_version_components would have to change their invocation to go through eshops_need ? otherwise i dont follow what you mean. You define the function, then call eshopts_need immediately afterwards, and it sets up the wrapper automatically. You can then call get_all_version_components as normal.
Re: [gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On 5 July 2010 14:01, Peter Hjalmarsson x...@rymdraket.net wrote: 1. (A t-shirt saying 2 + 2 = 5. For this joke to work you have to know how to round numbers, and that 2 can be rounded from everything between 1,5 and 2,4, and that 4,8 rounds to 5. And it is still correct math.) You said yourself that it's a joke, and yet somehow you don't seem to understand what that means
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Monday 28 June 2010 02:09:44 Nirbheek Chauhan wrote: Hello everyone, I'm sure at least half of you are thinking Oh no, not this again..., and I agree. However, I'm /also/ thinking Why the heck haven't we done this yet? [...] /If/ you're¹ going to insist on doing this, could you please at least do it in a way that's easy for users to disable? (Profile LDFLAGS as the subject line says obviously qualifies, but there's also been talk of creating gcc-config profiles, modified specs etc.) That way people can choose according to their own preferences for correctness versus convenience etc. [1] Whoever does it, not specifically Nirbheek
Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Tuesday 29 June 2010 09:46:52 Alex Alexander wrote: If the community feels their choice, albeit not perfect, will help the project, you have to respect that. That is, if you want to be part of the community :) I see your point to some extent, but the concern is that such decisions might sometimes get made according to who's best at ignoring technical objections rather than what's the best thing to do. It has happened before, although in that case the change was made first, and then when the issue was brought up it got basically ignored for so long that it would be pointless to fix. It would be worrying if things like that started to happen more often. In any case, as mentioned in my other mail, if this particular change is done in a way that's optional for the user, I personally won't be /too/ upset if the rest of you want to do unspeakable things to your systems ;-).
Re: [gentoo-dev] Tone in Gentoo
On Saturday 19 June 2010 22:03:31 Ben de Groot wrote: It is about whether Gentoo wants to keep around people [...] who continually attack others Considering the number of attacks directed towards Paludis developers (and sometimes users), and lack of corresponding punishment, I can only assume the answer is yes.
Re: [gentoo-dev] Tone in Gentoo
On Saturday 19 June 2010 23:01:33 Patrick Lauer wrote: you're actively stepping in the way of moving fists to complain that people punch you. Stop doing that. You mean banning trolls is an invitation for you to snip the trolling and publicly accusing me of banning them on a whim? (excerpt from http://www.gentooexperimental.org/~patrick/weblog/archives/2008-03.html#e2008-03-31T20_31_17.txt) So things are starting to look quite toasty. The nice paludis people even keep the bad vibes away: [17:12:44] *** Mode #paludis +b *...@gentoo/user/FamousToaster by dleverton [17:13:11] *** Mode #paludis +b d0pamin...@* by dleverton [17:13:15] -* dleverton has kicked fragalot from #paludis (bye bye) [17:13:19] -* dleverton has kicked D0pamine from #paludis (bye bye) [17:13:35] *** Mode #paludis -o dleverton by dleverton followed by 17:19 rane i'm a gentoo developer relations project member 17:19 fragalot Hi. :) 17:20 rane and i want to inform you that if you continue to behave the way you did on #paludis, your gentoo/user cloak will be removed Behaving that way meaning joining the channel and saying Hi ? Wow, that's great. So I must really recommend to users never to go near that place as they will have firebreathing dragons on their behind within minutes. Or asking for opinions on a technical issue is a form of trolling? http://www.gentooexperimental.org/~patrick/weblog/archives/2008-05.html#e2008-05-03T22_15_54.txt There's plenty more, but I don't think it would be productive to try and track down everything.
Re: [gentoo-dev] Tone in Gentoo
On Saturday 19 June 2010 23:05:25 Domen Kožar wrote: http://xkcd.com/386/ s/wrong/attacking me in public/ and it might be closer.
Re: [gentoo-dev] pkg_pretend USE validation and VALID_USE alternative
On Thursday 01 April 2010 19:39:43 Dror Levin wrote: Here's another suggestion: how about we don't impose any ridiculous constraints on development and keep this discussion on the technological side of the original proposal? It's not ridiculous to expect to have a new EAPI in a reasonable amount of time. Other features are already done, so holding them back until this one is complete would itself be placing constraints on developers who have a use for the other features.
Re: [gentoo-dev] Re: Marking bugs for bugday?
On Sunday 07 March 2010 04:30:55 Sebastian Pipping wrote: What I wonder now is: - Will it work with our very instance of Bugzilla? The security team uses (or at least has used in the past) flags on Gentoo Bugzilla. - Can certain flag states be required when searching? It looks like you need to use the Advanced Searching Using Boolean Charts section on the search page - you can select Flag, is equal to, and type the flag name/state, for example Assigned_To? for one of the above-mentioned security flags. Note that the normal search fields still apply, so you need to deselect all the options in the Status list before that particular example will produce any results. - Can we get their current value out using ctype=rdf output I don't think you can with the RDF, but the XML button on the search results page includes the flags (and a whole lot of other information), so if you're going to rewrite the bugday software anyway you could consider using that instead, if it would give sufficient benefit. It seems that if you're requesting it programmatically you'd have to do the search, get the bug IDs and explicitly pass them to the XML generator, though, which makes things a little more awkward.
Re: [gentoo-dev] Re: Marking bugs for bugday?
On Saturday 06 March 2010 15:26:10 Ioannis Aslanidis wrote: Well, I personally would prefer to have two keywords at least, one for candidates and another for confirmed bugs. This sounds like the sort of thing Bugzilla's flags mechanism is for. http://www.bugzilla.org/docs/2.22/html/flags-overview.html
Re: [gentoo-dev] [RFC] New eclass for x11 packages
On Thursday 18 February 2010 22:33:42 Tomáš Chvátal wrote: [[ ${PN} == util-macros ]] || DEPEND+= =x11-misc/util-macros-1.3.0 [[ ${PN} == font-util ]] || DEPEND+= =media-fonts/font-util-1.1.1-r1 Do non-fonts really need font-util there? Looks like that sets up a nice circular dependency. [[ -e ./configure.ac ]] eautoreconf || ewarn Unable to autoreconf the configure script. Things may fail. That'll ewarn if configure.ac doesn't exist at all. Doesn't eautoreconf die anyway if it fails, and if not, is it a good idea for failures to only give a warning?
Re: [gentoo-dev] [RFC] New eclass for x11 packages
On Thursday 18 February 2010 23:16:54 Tomáš Chvátal wrote: That || die is not for eautoreconf [[ -e something ]] somethingexists || somethingisnotexisting For your behaviour it would have to look like this [[ -e something ]] { somethingexists || die if the commands failed ; } Do you mean that it's /supposed/ to ewarn if configure.ac doesn't exist? Do you expect that to happen for X.org packages that have a configure script at all? (Which IIRC is all of them; if there are any that don't have a configure, there's obviously no reason to worry about not being able to rebuild it.)
Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3
On Sunday 17 January 2010 20:38:48 Petteri Räty wrote: With GLEP 42 and proper logging of e* messages I think we shouldn't annoy users any more with ebeep or epause so attached is a patch only defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to keep these around for EAPI 3? If not I will apply the attached patch. The eclass-manpages comments should be updated too.
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote: What all this has to do with the fact that they are just build dependencies? Just wondering. They're not just build dependencies. They're required to use the library in a certain way, namely to compile other programs against it. As long as we don't have compile-against dependencies, the only correct way to express that is RDEPEND (and also DEPEND because they're /also/ needed to build the library itself).
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Monday 28 December 2009 21:04:01 Fabio Erculiani wrote: To me you are saying that DEPEND would work just fine. No? Setting the proto as DEPEND for the library wouldn't work because a user could install the library, remove every DEPEND-only package and legitimately expect the library to continue working, including being able to build other programs against it. Putting the proto in DEPEND for every package that uses the library isn't good because (unless the package references the proto directly) the fact that the proto is needed is an internal detail of the library, that might even change between versions, and packages using the library shouldn't have to know about it.
Re: [gentoo-dev] mtime preservation
2009/11/26 Brian Harring ferri...@gmail.com: This discussion in generall is daft. No package can rely on nanonsecond resolution for installation because the most common FS out there (ext3) does *second* level resolution only. As such, I can pretty much gurantee there is *zero* packages out there that require nanosecond resolution for installation. It's possible that a package might assume that *if* nanosecond timestamps were available on the build filesystem, then they can do nanosecond comparisons on the installed filesystem. That would be a rather questionable assumption, and I'm not sure what we could do about packages that do require that, but that's why we discuss things, right? To find solutions? It's an academic discussion, and pointless. We don't mandate the filesystems PMS implementations are run on- as such we cannot make a gurantee to ebuilds that nanosecond resolution is available. It's daft to encode in the spec NS resolution when it's essentially impossible to gurantee it If we're not going to insist on preserving nanoseconds as far as possible, then package managers should be required to explcitly clear the nanoseconds part. Otherwise we'll get situations where a package works on the maintainer's machine, because it happens to use a package manager, filesystem setup, configuration etc that happens to cause nanoseconds to be preserved accurately, but it randomly and mysteriously fails for users. This is especially a concern in this case because a maintainer can easily have no idea that he's accidentally relying on nanoseconds being preserved - it's not something the ebuild requests explicitly, and if the timestamps happen to be set on his machine as the package expects, it'll just work without any indication that there was a potential issue. I'm honestly not sure why we're having this discussion beyond the python sucks angle. Because some of us want to find a correct solution, not just one that no-one's complained about yet in the context of the few filetypes that are currently known to benefit from preservation. Shocking, I know.
Re: [gentoo-dev] mtime preservation
2009/11/26 Brian Harring ferri...@gmail.com: Why is this one special? Two out of three do this already, and it works. You mean two out of three blatently ignored long-standing behaviour and added a new feature without discussion or an EAPI bump. Paludis doesn't preserve mtime You mean Paludis carefully emulated Portage behaviour, and is now somehow being blamed for the whole matter, to the extent that people are trying to use threats (to the effect of 'I'm going to deliberately break packages for Paludis users) to try to get their way in the discussion. and it's approach to randomly resetting mtimes There's nothing random about it. Files' mtimes are reset to the current time while being merged, just as Portage did for years.
Re: [gentoo-dev] mtime preservation
On Thursday 26 November 2009 13:21:43 Brian Harring wrote: It was always on the todo to convert portage over to preserving mtime- this long predates PMS and even EAPI. Like, for example, use deps? Yet somehow we managed to introduce those in a new EAPI, instead of retroactively adding them to all EAPIs. Why should mtimes be different? Beyond that, I presume your intention is to stir things up I suppose you have the right to presume whatever you want. It's a bit ironic really. Y'all didn't want mtime in there so it was left unspecified. Now you're complaining that portage changed it's behaviour (2+ years after the fact) as an arguement against adding mtime preservation into the next eapi. I'm certainly not arguing against adding it, I just want it to be done properly, and I'm expressing distaste at people trying to blame Paludis for the fact that it's not as easy as some people want it to be. I mean paludis doesn't preserve mtimes. People aren't going out of their way to break paludis (and claiming so is just trolling). I don't think anyone's talking about changing packages purely for the sake of break Paludis and for no other reason, but people have been talking about making changes that they know will break Paludis. (Whether they've actually done so is a different question, but the talk, and people blaming Paludis both when it behaves differently from Portage and when we've taken care to make it behave the same as Portage only for Portage to randomly change, are quite irritating.) Just because portage did something for a few years, does not make it right (this is something the PMS folk have been claiming since day one). So... that arguement is invalidated by your own statements. PMS tries to document Portage behaviour as long as it's not clearly unreasonable and unspecifiable. Discarding mtimes is suboptimal behaviour, yes, but it's coherent enough that it can't be considered a blatent bug. Much like the lack of use deps in older EAPIs.
Re: [gentoo-dev] FEATURES use or misuse?
On Tuesday 03 November 2009 15:48:03 Patrick Lauer wrote: To quote: FEATURES is a portage specific package manager configuration variable not specified in PMS and cannot reliably be used in ebuilds or eclasses. This has been the Portage team's position for years, since long before there were PMS and other package managers. See http://bugs.gentoo.org/show_bug.cgi?id=82513#c16 for example.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in xfce-base/xfconf: ChangeLog xfconf-4.6.1.ebuild
On Monday 05 October 2009 23:20:10 Ciaran McCreesh wrote: You probably will see some remarks about commit it, and let everyone else deal with the mess for years to come being the long-established Gentoo tradition, however. Not to mention accuse anyone who disagrees with you of being a troll.
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
On Friday 04 September 2009 16:01:41 Rémi Cardona wrote: For instance, I'm still working on migrating all the X11 packages to the MIT license (mainly for cleaning purposes), but in fact, each and every package should have its own license file (like today) because the MIT license requires that we acknowledge all major contributions to the code. Therefore, using a template like ${PORTAGE}/licences/MIT does is probably not a good idea from a legal point of view. Is that really a problem? I admit to not being around for the original design decisions, but I would assume that the purpose of having LICENSE in ebuilds is to tell users what licence the package is under (whether or not it's accurate is a different matter), and the purpose of having the licences themselves in the tree is so that it's easy for users to look them up and decide whether they want to accept the conditions or not. For that purpose, the exact list of credits is irrelevant. Also, I'm not a lawyer, but I would think that the licence's requirement for credit is satisfied by the credits being included in the source code - it doesn't require acknowledgement when merely talking about the software or stating the fact that it's under a particular licence, just when distributing it.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sunday 23 August 2009 03:39:52 Arfrever Frehtes Taifersar Arahesis wrote: /etc/make.profile is by default a symlink to appropriate profile directory in ${PORTDIR}/profiles. Again, a detail of how Portage is configured. PMS only covers profiles that are in repositories - it's up to the package manager how to deal with ones that are elsewhere.
Re: [gentoo-dev] profiles/info_pkgs
On Sunday 23 August 2009 18:28:46 Ulrich Mueller wrote: ... still contains the following entries: app-admin/eselect-compiler dev-util/confcache Both packages were punted about two years ago, so maybe it's time to clean up? Ulrich confcache is still available in masterdriverz's overlay (although it was recently removed from the layman list, since he retired a while back), and ¹ (a Bugzilla search for bugs opened in the last year with confcache listed in emerge --info output) indicates that a few people still have it installed, or at least have in the near past, so I'd suggest keeping that one for now. On the other hand, a similar search for eselect-compiler returns no results, so it's probably OK to drop it. [1] http://bugs.gentoo.org/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=long_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=emailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=creation_tstype0-0-0=greaterthanvalue0-0-0=2008-08-23field0-1-0=longdesctype0-1-0=substringvalue0-1-0=dev-util%2Fconfcachefield0-2-0=longdesctype0-2-0=regexpvalue0-2-0=dev-util%2Fconfcache%3A+*[0-9]
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sunday 23 August 2009 01:26:24 Chip Parker wrote: So, Ciaran, if your personal reference implementation of PMS fails miserably when using this methodology, your argument that I won't be or am not affected by your attempt at changing portage is invalid. If you'd like to test for yourself, I'll be more than happy to tar up both my /etc/paludis and /etc/managed-portage for you. You're still talking about /etc, which is still unaffected by PMS. If Paludis doesn't support a feature in /etc that you want to use, then feel free to file a bug. If Portage supports that feature in /etc, there's no reason why it needs to stop doing so, regardless of what it does or doesn't accept in the tree.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Sunday 23 August 2009 02:10:36 Chip Parker wrote: They're the same thing. It doesn't matter if the profiles directory is in located in /tmp or in /usr/local/portage, the behavior of paludis *still* doesn't support the feature that these profiles depend on and portage still *HAS* since before PMS was submitted to this list as an RFC in August of 2006. The behaviour of Paludis doesn't matter as far as your own /etc goes, because you (presumably) don't use Paludis. You're free to use whatever's supported by your own favourite package manager. Additionally, there isn't a way to define in paludis where the profiles actually exist outside of the repository configuration files, which means that in your mind, they're one and the same. You can read minds now? The actual reason why the profile is configured in the repository configuration file is that the profile used by a particular repository's packages is a parameter to that repository. Not that that's relevant to what you do in your own /etc, as I said above.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
2009/8/21 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org: Portage documentation has been properly fixed (and the fix will be released in next version) and this feature can now be used in 10.0 profiles. No. Changing the documentation does not retroactively change existing EAPIs.
[gentoo-dev] EAPI 3 and nonfatal die
In EAPI 3, most commands and functions provided by the package manager automatically call die if they fail. There's also a new nonfatal function that can be used to suppress this behaviour: by prefixing a function/command call with nonfatal, the automatic die behaviour is suppressed during the executation of that function/command. The difficulty here is that it's not clear what nonfatal should do to explicit die and assert calls. On the one hand, if nonfatal does suppress these functions, then nonfatal can be usefully used with eclass functions - silly hypothetical example: # eclass escons() { scons $...@} || die scons failed } # ebuild nonfatal escons || do_something_else On the other hand, it could be risky to change the behaviour of existing functions like that: do_foo() { cd foo || die cd failed # something that would be dangerous if run in some other directory } If called as nonfatal do_foo and the cd failed, do_foo /wouldn't/ return a failure code - it would proceed with the rest of its body and wreak all manner of havoc. One way around this would be to add either an option to die to explicitly tell it to respect nonfatal, or an alternative die function. This would allow eclasses to choose to respect nonfatal when it's safe to do so, but without changing existing behaviour. The disadvantage of this is that it would require changes to all eclass functions that could potentially use it, plus the slight ugliness of making them handle older EAPIs as well. Another option would be to make die respect nonfatal by default, and add an option that doesn't. This wouldn't require changes to eclasses that want the nonfatal behaviour, but it would require some care to make sure that it was used when necessary. A potential advantage of this over the previous solution is that if the force option is implemented with an environment variable, it can be used regardless of EAPI - the previous example could be changed to something like do_foo() { cd foo || DIE_FORCE=1 die cd failed # something that would be dangerous if run in some other directory } Does anyone have any opinions on which of the four options (#1 make die respect nonfatal, #2 make die always die, #3 add a new die variant that respects nonfatal, #4 make regular die respect nonfatal, and add a new variant that doesn't) we should go with? We should definitely get this resolved and agreed on before EAPI 3 is finalised.
[gentoo-dev] Re: EAPI 3 and nonfatal die
On Friday 21 August 2009 21:56:41 David Leverton wrote: A potential advantage of this over the previous solution is that if the force option is implemented with an environment variable, it can be used regardless of EAPI ...except that the previous solution could use an environment variable too, of course.
Re: [gentoo-dev] [RFC] [EAPI=3] Add approprietly prefixed values of IUSE_* variables to IUSE
On Sunday 05 July 2009 03:33:54 Arfrever Frehtes Taifersar Arahesis wrote: I would like to suggest that values of IUSE_* variables (whose names end with values of USE_EXPAND variable), after prefixing with lower-cased names of appropriate variables included in USE_EXPAND, should be automatically added to IUSE variable. USE_EXPAND is set in the profiles, so it can't be used during metadata generation. It's a zero-cost feature implemented in the attached patch, so including it in EAPI=3 (after temporary unlocking of list of features of EAPI=3) wouldn't delay implementing support for EAPI=3 in Portage. http://www.gentoo.org/proj/en/council/meeting-logs/20090409-summary.txt
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
On Monday 01 June 2009 05:25:06 Jorge Manuel B. S. Vicetto wrote: Hello fellow developers and users. Nominations for the Gentoo Council 2009/2010 are now open for the next two weeks (until 23:59 UTC, 14/06/2009). I would like to nominate dirtyepic, as he has repeatedly shown himself to be quite sane and competent.
Re: [gentoo-dev] Re: Re: Re: The fallacies of GLEP55
On Sunday 24 May 2009 21:40:57 Steven J Long wrote: Hmm way to go putting thoughts in my head that aren't there. Yes, that sums you up quite nicely.
Re: [gentoo-dev] Re: GLEP 55 updated
2009/5/18 Steven J Long sl...@rathaus.eclipse.co.uk: David Leverton wrote: 2009/5/17 Ben de Groot yng...@gentoo.org: I think the way eapi-2 was introduced into the tree wasn't particularly problematic. I think there might be a misunderstanding here. Ciaran means functions provided by the package manager that ebuilds can call during metadata generation, for example built-in versionator-like functionality, not new phase functions like src_prepare and src_configure. Ugh. Firstly versionator is a piece of bloated crap that should have died a long time ago; all it does is stop Gentoo newbs learning the basics[1] of their implementation language, which leaves them open to nonsensical arguments about printf -v (glad you finally learnt that one, btw.) Yes, it should have died a long time ago, that's why we're talking about adding equivalent built-in functionality. Please try to keep up. (And it's always amusing to see your bizarre delusions about what I do and don't know.) Secondly, please explain fully and clearly, but concisely, why we can't simply state that EAPI=NN allows the ebuild to use the EAPI functions in global scope. Because by the time the package manager knows the EAPI and is in a position to provide the appropriate functions, the ebuild will have already tried to use them. Bear in mind that you have to deal with the case of the mangler which can get EAPI from an ebuild without sourcing, as portage currently can, I believe. Interesting Relaxing that restriction strikes me as much saner than relaxing all the other restrictions which make interoperability easier. (Frankly, I'm amazed at having to state that to people trusted to write a specification. Follow up to -project on this point please, as it's about process, not technique.) You're amazed that people trusted to write a specification don't already know what strikes you as much saner? Believe it or not, the world does not revolve around you and your opinions.
Re: [gentoo-dev] Re: The fallacies of GLEP55
On Sunday 17 May 2009 08:29:31 Patrick Lauer wrote: I thought we had agreed that (1) with GLEP55 you have to source the ebuild anyway (whereas the other proposal allows to just parse it to get at the EAPI value) and (2) you can cache it sanely so that performance isn't the issue? You don't /have/ to source the ebuild to get the EAPI for GLEP 55. That section is only there to cover corner cases that some people wanted to be well-defined, and it could easily be removed if the consensus is that that isn't a problem. On the other hand, it could equally well be added to whatever alternative solution you might suggest. Consider the case where you have a foo-1.2.ebuild-4, and in the contents of the file it sets EAPI=5. What should that mean? There are three possibilities that I can think of: 1) It's illegal, don't do that. Then there's no need to source the file to find the EAPI, because the corner case should never happen, and if it does, the behaviour can be left undefined. 2) It's legal, and the ebuild has EAPI 4. Then there's no need to source the file to find the EAPI, because the EAPI in the filename always wins. 3) It's legal, and the ebuild has EAPI 5. This requires sourcing the ebuild to find the EAPI, and it's what GLEP 55 currently says. Now consider the alternative fixed-format ^EAPI= suggestion. What if we have a foo-1.2.ebuild, that sets EAPI=4 at the top, and then sets EAPI=5 further down? What should that mean? The same three possibilities apply here as in the GLEP 55 case. If you think it should be illegal, or that it should mean EAPI=4, then there's no need to source the ebuild just to find the EAPI. If you think it should mean EAPI=5, then you do need to source the ebuild, exactly the same as in GLEP 55. Either way, this isn't a valid reason to choose the fixed-format alternative over GLEP 55, because the same concerns do or do not apply to both.
Re: [gentoo-dev] GLEP 55 updated
2009/5/17 Ben de Groot yng...@gentoo.org: Ciaran McCreesh wrote: On Sun, 17 May 2009 23:17:57 +0200 Ben de Groot yng...@gentoo.org wrote: 2. Add new global scope functions in any sane way This is a valid use case, as seen by the eapi-2 update. But the way this is currently handled by portage (advising to upgrade the package manager) works. So I don't see a need to change the file extension for this reason. It means we can't start using those new global scope functions until we're sure that everyone's going to be upgraded, because users get extremely upset if they start seeing that kind of message. Isn't that a given anyway? I think the way eapi-2 was introduced into the tree wasn't particularly problematic. I think there might be a misunderstanding here. Ciaran means functions provided by the package manager that ebuilds can call during metadata generation, for example built-in versionator-like functionality, not new phase functions like src_prepare and src_configure.
Re: [gentoo-dev] The fallacies of GLEP55
On Saturday 16 May 2009 10:27:51 Marijn Schouten (hkBst) wrote: How is it possible to do these things encoded in the filename? For the export example, it's just a matter of using a different bash syntax from what the magic regex expects, which is completely irrelevant if it goes in the filename instead. For the versionator one, you would change the extension at the same time that you changed the version, removing the need to modify the file contents. But the point isn't that we want to be able to do those things. The point is that if the EAPI is in the filename, it's blatantly obvious that it has to be static, but adding strange and unintuitive restrictions on which shell constructs can be used is, well, strange and unintuitive.
Re: [gentoo-dev] Re: The fallacies of GLEP55
On Saturday 16 May 2009 13:14:23 Duncan wrote: I mean, for the longest time, the main (among many) boosting claim seemed to be that the speed difference between in-file and in-filename made the former prohibitive in practice. No, performance was never the point of GLEP 55. People like to talk about it because, as we all know, Gentoo is for ricers, but it's not relevant and never has been, except to the extent that we don't want to make performance worse than it is now. The argument was originally made that a simple highly specified EAPI= declaration in the file itself was too restrictive of all the ways it could be specified now -- until it began to be pointed out every time the argument was made that the filename method was very similarly restricted. No, no-one has ever claimed that the restricted EAPI= method is bad because they /want/ to be able to set it using weird bash tricks. The problem is that, if it appears as a bash assignment you /can/ set it using weird bash tricks, and making the PM's own parsing accept a subset of what can happen when the ebuild /is/ eventually sourced is going to make a mess. I'd argue no, it's no more unintuitive than any other format definition choice. It's the basic format definition, using the long accepted method of magic values at a magic location to define the format version. That's very basic definitional, restricted only to the degree necessary for practical application of the definition. Therefore, it's not unintuitive, or at least, certainly no more so than arbitrarily defining it to be in the filename instead, because intuitive now gets defined by the format definition at an extremely basic level, well below the level at which all the intuitive or not fancy stuff gets addressed. The format definition at an extremely basic level is bash, which has no such restrictions. For comparson, another alternative that some people have suggested is putting it in a specially formatted comment. This avoids the issue I mentioned because bash doesn't try to parse those at all, so the only rules are those that specify what format the comment should be in. On the other hand, this isn't backwards compatible with current package managers.
Re: [gentoo-dev] The fallacies of GLEP55
On Friday 15 May 2009 02:42:33 George Prowse wrote: Having countered those four points I guess you agree with the other five then. Over 50% success rate (by your definition) is hardly being ignorant or trolling In that case we can assume that Patrick agrees with all my counterpoints, since he hasn't responded to my email at all.
Re: [gentoo-dev] Re: Re: The fallacies of GLEP55
On Friday 15 May 2009 21:06:13 Steven J Long wrote: In practical terms, this is a useless proposal. It rightly got trashed last year. No, it did not get trashed, despite some people's attempts to make their side sound more popular than it really is. Some people like the idea, some don't, and people have put forward various arguments in both directions. If it were really as widely hated as you claim (presumably with the implication that the people who still support it are horrible and evil for even thinking about it) then it wouldn't still be under discussion.
Re: [gentoo-dev] The fallacies of GLEP55
On Thursday 14 May 2009 19:06:51 Patrick Lauer wrote: For quite some time (over a year, actually) we've been discussing the mysterious and often misunderstood GLEP55. [http://www.gentoo.org/proj/en/glep/glep-0055.html] We agree on the latter adjective, if nothing else. The proposed solution to a problem that is never refined, in short, is to add the EAPI into the ebuild filename to make things easier. Which is a rather unsubstantiated idea that doesn't really add up if you look at it ... and it adds some artifacts that we've been laughing about for a decade because microsoft did the exact same thing (binding the executable-ness of a file to the filename). I wonder where people get this strange delusion that only Windows uses file extensions for anything? Here's just some of the theories in support of GLEP55 that have been thrown at me, and a few words to show how they are not really issues: You need to know the EAPI to parse the ebuild to find the EAPI Obviously that's not true, because somehow we manage at the moment. Because we haven't yet introduced any changes that would break it. And if one does a small restriction (which doesn't restrict current behaviour because all in-tree ebuilds currently fit within this limitation) it becomes trivial again: Let EAPI be defined as (the part behind the = of) the first line of the ebuild starting with EAPI= As long as ebuilds remain shell-like this is not much of a restriction, It's an arbitrary, magical restriction that doesn't follow from the general rules of the language that ebuilds are written in - you said it yourself, shell-like. printf -v EAPI 1 is perfectly valid shell (at least if we decide to allow bash 3.1 features), and has the same effect as EAPI=1 under the rules of the shell, but it's not compatible with your new rule. You need to parse the ebuild and its eclasses to find the EAPI! See above, and eclasses shouldn't change EAPI anyway. It leads to lots of strange effects and is implicitly impossible with GLEP55 anyway, so it might be easier to just declare it invalid. With GLEP 55 it's naturally invalid, and can't possibly be assumed to be valid. If you keep the assignment-like syntax but disallow it in eclasses, it's an extra weird restriction. It's slower! The theory here being that a stat() is needed if it is encoded in the filename, but a stat() followed by an open() to parse it from the file. Well then, just cache it! You can use the mtime to check the cache validity (which means you do a stat() anyway, so with glep55 caching it is actually slower!), and then you have to parse the ebuild anyway for the other metadata. So the extra cost of finding the EAPI is ... what extra cost? The only case when it is actually slower is when there is no cache because then you have to parse the ebuild. But that degenerate case will only hit some overlay users and people like developers that can wait .3 seconds longer. And ... uhm ... to extract other metadata like DEPENDS you'll have to parse it anyway. And people say Gentoo users are ricers... the whole speed argument is a strawman, relevant only to the extent that we don't want to make things noticeably slower than they are already. You claim that GLEP 55 does that, but this claim seems to be based on the assumption that without it there would be no need to parse the filename in any way, which clearly isn't true. But we need to be able to change things in the future! Well then. Once we have identified such an issue we can do the changes. Until then it's not even clear if there are such changes, so why should we break current known and predictable behaviour to satisfy a need we don't even have? Make a structured proposal defining a concrete problem in unambiguous terms, list all the ways to solve this issue, including advantages and disadvantages, and we can get it voted on and ratified within a month. The same thing happened when EAPI itself was introduced. EAPI support was committed to Portage in late September 2005, but the first new EAPI in mainstream Gentoo was introduced in early October 2007, just over two years later. That's clearly not an argument for rejecting a compatibility mechanism. It's also not necessary to start putting EAPI in the filename as soon as it's approved. The Council could easily state that once we need to make a change that requires a stronger mechanism than EAPI is currently, we'll do it like this - no need to reject it, or keep maybeing it for eternity. Of course, there's at least one GLEP 55-scope change that people want already, to the extent that they're making up hacks to work around the lack of it, namely per-package eclasses. I would hope that everyone agrees that a package manager-supported mechanism would be far preferably (I know that vapier does). We want to change the versioning rules! Why do you want that, and what do we gain from it? Aside from -scm (below), there are
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
On Sunday 10 May 2009 04:23:25 Nirbheek Chauhan wrote: 1. It was a paludis bug, of course paludis --info came in handy (are you trying to jest? ;p) It's most likely not a Paludis bug; do you really think that no-one's ever tried to compile Qt4 on amd64 with Paludis until now? I'm guessing a misconfiguration, but we'll have to wait for the real paludis --info output (NOT emerge --info, because that doesn't say anything about the Paludis configuration) to be sure. 2. You found it useful because you knew the syntax, and where to look for what -- it is relevant to you. Not to everyone else It's useful and relevant if and only if it contains information that helps diagnose the problem. In the likely event that it's a misconfiguration, that applies to paludis --info, but probably not emerge --info, unless he made the same mistake with both. 3. Also, last comment on the bug: The emerge --info and paludis --info I reported above are from the wrong machine. I'll update the results on Monday when I get back to the correct machine. It is a Xeon W5580 cpu which should be compiling as x86_64. I believe the bug is real. Sorry for the confusion. Oops? =p If anything, that's a point in favour of tanderson's argument. If the --info the user had posted had been right, then both the paludis and emerge output are equally useful, because they both indicate that it isn't an amd64 system at all. On the other hand, if it turns out that on the correct system, Paludis is misconfigured and Portage isn't, then only paludis --info will help.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild
On Sunday 10 May 2009 09:58:22 Ryan Hill wrote: On Sun, 10 May 2009 02:00:17 -0600 Ryan Hill dirtye...@gentoo.org wrote: You can't test FEATURES in an ebuild. It's portage-specific. Actually, am I right? Yes. (http://bugs.gentoo.org/show_bug.cgi?id=239671#c10 gives a better approach for this particular problem.) There's a crapload of stuff in the tree doing things like this and worse with FEATURES. Welcome to Gentoo.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild
On Sunday 10 May 2009 13:47:45 Ben de Groot wrote: What do you expect? He's an exherbo dev, only here to criticize Gentoo and gloat over its perceived failings. It's pretty hilarious that you think you know anything about me.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild
On Sunday 10 May 2009 14:02:48 Nirbheek Chauhan wrote: It's even more hilarious that you expect to fix Gentoo's problems by bitching about them. Same to you as I said to yngwin.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild
On Sunday 10 May 2009 14:02:57 Ben de Groot wrote: Just your activity on Gentoo channels (IRC, ML, etc), which is what my assessment is based on. Nothing I've ever done anywhere, in Gentoo channels or elsewhere, in any way implies that I'm only here to criticize Gentoo and gloat over its perceived failings.
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thursday 09 April 2009 19:06:16 Nirbheek Chauhan wrote: dev-lang/python So, wait, you want to depend on specific slots of python and keep them around, and manage all their related bugs? Isn't that exactly the opposite of what python upstream suggests, and *ALL* distros do? If you install a Python library for Python x.y, even if the library itself can support other versions, then the installed package depends on Python x.y, period. Using := is simply acknowledging that fact. It doesn't mean you have to keep x.y around for all time, but it does mean that the package manager knows what needs to be reinstalled before x.y can safely be removed. @preserved-libs. More generic, a low-level catch-all for library breakages, and more convenient for users (rebuild as and when possible, not *right now* lest everything break). More generic? @preserved-libs knows about Python now? And the whole point of slotting is that you can keep old versions installed, so you don't need to rebuild dependent packages right now.
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
2009/4/1 Mike Frysinger vap...@gentoo.org: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. I would like the Council to discuss the matter of Portage repeatedly changing behaviour in ebuild-visible ways without an EAPI bump or even an announcement that anything changed. Notable examples include .lzma support in unpack (bug 207193), the change in pkg_* phase ordering (bug 222721) and the preservation of timestamps during merge (bug 264130). It is quite frustrating to spend considerable effort determining Portage's behaviour and matching it in Paludis, only to find a few months later that Portage changed and now users are getting broken packages if not broken systems because ebuilds are starting to rely on the new rules. (The /really/ hilarious part is that certain people then accuse /us/ of being uncooperative and not caring about compatibility.) This needs to be dealt with if Gentoo is ever going to take the idea of PMS, or indeed EAPI itself, at all seriously.
Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support
On Sunday 08 March 2009 05:22:03 Donnie Berkholz wrote: FYI, using EXPORT_FUNCTIONS before inherit, as this patch caused x-modular.eclass to do, is broken in current portage releases. Zac said he would change this to be consistent with the lack of any ordering restriction in the PMS. Thanks to Tomáš Chvátal for tracking down this tricky bug! Better to ask for PMS to be clarified. All existing package managers do EXPORT_FUNCTIONS in more or less the same way, so changing it shouldn't happen without an EAPI bump.
Re: [gentoo-dev] USE dependencies
On Sunday 04 January 2009 16:48:38 Nirbheek Chauhan wrote: On the contrary, the reverse of what you say is true. A simple grep of the tree showed that: In how many of those ebuilds would the long form be use1? ( cat/pkg[use2] ) rather than use1? ( cat/pkg[use2] ) !use1? ( cat/pkg ) ? Obviously I didn't look through all the hits, but the former seems quite common, and any possible shortcut would only save a few characters.
Re: [gentoo-dev] Flags to punt (including: kerberos USE flag)
On Monday 03 November 2008 04:29:34 Nirbheek Chauhan wrote: Why not use EAPI=1 for those ebuilds and turn the flag on by default? Well, as I said, it seems more sensible to me to set the default once, instead of once for each ebuild. I don't particularly care, though, just making sure people know why it was there in the first place, and if they still want to change it, so be it.
Re: [gentoo-dev] Flags to punt (including: kerberos USE flag)
On Saturday 01 November 2008 02:44:50 Josh Saddler wrote: emboss - Seriously. Who needs the European Biology Open Software Suite on a *desktop* oriented system? That flag is only used by a few sci-biology packages, so if you don't have any of those installed, it doesn't matter whether the flag is on or off. IIRC the argument for having it on was that the majority of people who /do/ use those packages will want it. I suppose one could say that it should be set in IUSE or profile package.use instead, but IMHO, if there are enough packages using it to justify making it a global flag in the first place, and all of them need the same default, it makes sense to set the default globally (*cough*ocamlopt*cough*).
Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability
On Saturday 01 November 2008 20:57:17 Gordon Malm wrote: I'd like to get distcc added as one of the FEATURES we are able to RESTRICT. Regardless of whether it's a good idea or not, does it fix all the known issues if the ebuild sets DISTCC_HOSTS=localhost in the environment?
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild
On Wednesday 15 October 2008 10:33:22 Steve Long wrote: Here you go (this is on an old machine, so you'll get much quicker times if you try this at home): [EMAIL PROTECTED] ~]$ echo $(run) #!/bin/bash P='some-crap/god-i-hate-asshats' I do hope that that isn't directed at anyone in particular. for ((i=0;i10;i++)); do echo /usr/share/doc/${P}/examples /dev/null; real 11.25 real 9.24 So that's what, on the order of 20 microseconds faster for each iteration? This is a purely stylistic issue, same as the braces with variable expansions. You're free to write your own code however you like, but harassing other people to do things your favourite way with no practical benefit is just going to annoy everyone.
Re: [gentoo-dev] Making built_with_use die by default with EAPI 2
On Saturday 20 September 2008 18:15:27 Alexis Ballier wrote: I can think of checks like: - foo is a dep/rdep of bar - foo has a plugin like architecture - bar will work with minimal foo - most people will expect some features in bar that come with foo's plugins - we might want to display warnings for the most useful features - having useflags in bar for each of foo's useflags doesn't seem wise If you mean something like built_with_use cat/foo coolfeature || ewarn bar will be more useful if you rebuild cat/foo with USE=coolfeature then you can use has_version 'cat/foo[coolfeature]' || ... instead. By the way, how will the --missing option of built_with_use be handled by eapi 2? Not at all.
Re: [gentoo-dev] EAPI-2
On Thursday 11 September 2008 21:06:48 Doug Goldstein wrote: Tobias Scherbaum wrote: Luca Barbato wrote: I don't see any problems with it. +1 Tobias +1 Since this latest version hasn't generated any noticeable disagreement, could the Council please formally vote on it at the next meeting?
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Monday 08 September 2008 08:48:23 Vaeth wrote: But it doesn't do this well Those of us who have actually been using it say it does.