Re: [gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
Duncan wrote: ... ++ - I can only add the saying With freedom comes great responsibility.. Maybe the python herd could maintain a little status page which covers informations like: - Estimated python 3 compatibility in respect to the packages in the main tree. - Recommendations if installing makes sense or not (e.g. package X gains feature Y with python 3). - Recommendations if setting python 3 as system engine makes already sense or not. This way gentoo can give its users the tools needed to make a good decision if python 3 makes sense on his system. For me as a user I need more time to study if an action makes sense than implementing said action (e.g. locally masking python 3 - It would not be the first time masking a package). If one isn't into python, it gets even more complicated. J_M
[gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
On 03/19/2010 08:26 PM, Alec Warner wrote: On Fri, Mar 19, 2010 at 8:13 AM, Nikos Chantziarasrea...@arcor.de wrote: You guys always make easy decisions so complicated. :P Masking a package is not complicated. Yes, that's why all the heated debates about Python 3 exist, because it's all so simple. It *is* simple, but you don't want it to be.
[gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
fre 2010-03-19 klockan 05:13 -0500 skrev Dale: Because, when I installed gcc 4.3, I could then unmerge the old gcc. That's why I didn't complain about that. With python, we still have to have the current version plus the new version which is not being used at all. That was if you did not use qemu that did *not* compile or run with a gcc never then gcc-3 for a couple of years... Also search for gcc-porting in b.g.o and guess what: there are many packages that fits this description for gcc, qemu was just a special case since for it it actually took YEARS before upstream released a version that worked with gcc-4, most other packages is often easier to patch (since it is mostly compile-time brokenness related to headers or other small fixes) and our awesome toolchain guys helps fixing it up before it hits ~arch.
Re: [gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
On 03/20/2010 02:56 AM, Jean-Marc Hengen wrote: Duncan wrote: ... ++ - I can only add the saying With freedom comes great responsibility.. Maybe the python herd could maintain a little status page which covers informations like: - Estimated python 3 compatibility in respect to the packages in the main tree. That would be easy enough to generate from dependencies. Surely there are some dependencies that need to be updated, but that shouldn't be much work. For example, I've already updated the cracklib and libxml2 deps to indicate lack of python3 support. - Recommendations if installing makes sense or not (e.g. package X gains feature Y with python 3). - Recommendations if setting python 3 as system engine makes already sense or not. This way gentoo can give its users the tools needed to make a good decision if python 3 makes sense on his system. For me as a user I need more time to study if an action makes sense than implementing said action (e.g. locally masking python 3 - It would not be the first time masking a package). If one isn't into python, it gets even more complicated. I would advise people to go ahead and install it as long as they can spare a little disk space and cpu time. Anybody who is tight on those resources should feel free to mask it (and the dependency resolver will certainly notify you if this is not feasible in your case). Honestly, I don't see a need for lots of data analysis here, but maybe some people just like that kind of thing. -- Thanks, Zac
[gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
I have a question related to this: If I have package X which supports python2 and python 3, and I install it without python3 installed it will only install python2-files (i.e. /usr/lib/python2.x/*), right? What happens if I later install packages Y that is only python3, and relies on the python3 parts of package X? Can this happen and how will the PM handle that (reemerge package X installing the python3 parts or fail to compile package Y due to missing python module)?
Re: [gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
2010-03-20 13:51:37 Peter Hjalmarsson napisał(a): I have a question related to this: If I have package X which supports python2 and python 3, and I install it without python3 installed it will only install python2-files (i.e. /usr/lib/python2.x/*), right? What happens if I later install packages Y that is only python3, and relies on the python3 parts of package X? Can this happen and how will the PM handle that (reemerge package X installing the python3 parts or fail to compile package Y due to missing python module)? As the news item says, you should run python-updater after installation of Python 3.1. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Packages pulling in python-3*, also they dont require it
2010-03-20 01:51:44 Duncan napisał(a): So let's just recognize that it's not a perfect situation, create a news item saying that python-3 will soon (give a date) be unmasked, and suggest that users not needing it may wish to package.mask it themselves, with a link to documentation with specific instructions and a bit more detail on why they might wish to mask it and under what circumstances they might not. I'd suggest an unmasking date 30 days after the release of the news item. Python 3 is not masked. The discussion is about stabilization. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Qt3 mask breaks significant science packages
BdG == Ben de Groot yng...@gentoo.org writes: BdG On 14 March 2010 06:09, James Cloos cl...@jhcloos.com wrote: BdG == Ben de Groot yng...@gentoo.org writes: BdG Abandoned packages do not belong in the portage tree. Nonsense. That attitude only servers to harm the user base. BdG You're wrong. It serves to protect our users from potentially BdG broken and vulnerable packages. Any user who needs *that* much hand-holding will use a binary dist, not a source dist. BdG It ascertains a Quality Assurance level that we and our users can BdG be comfortable with. No, it does not. The user base for a build-locally-from-source dist wants wider access, not just a few packages. Leaving them in does not. BdG It does, as it opens the users up to unknown security BdG vulnerabilities and increasing brokenness as bugs are BdG not addressed. Removing the ebuilds does not help that even one bit. IF they do not use those programs, they are not harmed even if there is some (real) vulnerability -- and don't forget that most of the vulnerability claims are for things which will never happen in practice. (Which is not to suggest that upstreams shouldn't code defensively, just that not every warning is critical enough to loose sleep over.) BdG If Gentoo would stop caring about QA, then we'd be wasting BdG our time working on making this a better distro. Removing ebuilds is not in itself QA. It does not in itself improve quality. There has to be a real reason to remove. Removing a leaf package which has been replaced by its upstream, whether by a simple rename or by a complete re-implementation or anywhere inbetween, is a good call. Removing a widely-used, well-designed and well-managed library and everything which depends on it, just because upstream has stopped dealing with bug reports against that version, is not. The likelyhood that any significant issues remain in qt3 is small. The relevant apps work, have been working and will continue to work. I will not begrudge the kde team for wanting to support only kde4. Dropping kde3 in favour of kde4 is just an upgrade. But dropping qt3 even though packages exist which depend on it and have not been ported to qt4 (and it *is* a /port/, *not* an /upgrade/) is simply the wrong thing to do. It is also OK to mask -- but not necessarily remove -- a package with a truly exploitable bug; moreso if the package is itself security-related. That means real exploits in the wild, real attempts to do harm. The so-called qa team has been acting too robotically. It needs to show more common sense and better judgement. Worry about the real problems, not the trivial. Work to fix packages, not to murder them. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
[gentoo-dev] Add LDFLAGS=-Wl,--hash-style=gnu to developer profile's make.defaults
The amount of bugs concerning ebuilds that ignore LDFLAGS suggests that this would be a good idea, b/c it seems a many maintainers are completely unaware that their ebuilds do not respect LDFLAGS - so I guess this needs more visibility. P.S. If you wonder why this flag then check /usr/lib/portage/bin/misc-functions.sh ;) Cheers, DN. signature.asc Description: PGP signature
Re: [gentoo-dev] How about a monthly bumpday?
On 03/19/10 13:36, Peter Volkov wrote: В Срд, 10/03/2010 в 05:08 +0100, Sebastian Pipping пишет: How about a monthly bumpday? Good idea, but it should follow our policy to inform maintainers _in advance_: e.g. on first bumpday to work on bumps and notify maintainer about this work by attaching final ebuild to the version bump bug with clear message that you are going to bump and, _next month_ on bumpday it's Ok to commit this ebuild to the tree. Just picking bugs and bumping them straight to the tree without knowing why maintainer haven't done that yet is a bad idea. Agreed. However, am I the only one who wouldn't start doing an ebuild _before_ okay or timeout? Chances are too high to work for the trashcan. I recommend a plain post of this text to an affected bug: I hereby request this bug and package to be opened to non-maintainer bumps. Unless this bug is closed before April's bumpday (2010-04-17) or any of the maintainer objects I may take the liberty of bumping this package from April's bumpday on. Sebastian
Re: [gentoo-dev] Add LDFLAGS=-Wl,--hash-style=gnu to developer profile's make.defaults
On Sun, 21 Mar 2010 00:46:38 +0100 Doktor Notor notordok...@gmail.com wrote: The amount of bugs concerning ebuilds that ignore LDFLAGS suggests that this would be a good idea, b/c it seems a many maintainers are completely unaware that their ebuilds do not respect LDFLAGS - so I guess this needs more visibility. does it work on non glibc/non linux systems? Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Add LDFLAGS=-Wl,--hash-style=gnu to developer profile's make.defaults
On Saturday 20 March 2010 19:46:38 Doktor Notor wrote: The amount of bugs concerning ebuilds that ignore LDFLAGS suggests that this would be a good idea, b/c it seems a many maintainers are completely unaware that their ebuilds do not respect LDFLAGS - so I guess this needs more visibility. remind me again why this matters ? binutils has been defaulting to hash- style=both for quite a while now. -mike signature.asc Description: This is a digitally signed message part.
