Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 14 January 2014 18:11, William Hubbs willi...@gentoo.org wrote: On Tue, Jan 14, 2014 at 05:43:57PM -0500, Michael Orlitzky wrote: On 01/14/2014 05:33 PM, William Hubbs wrote: On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote: On 01/14/2014 04:37 PM, William Hubbs wrote: 2. I would like to see the policy below applied to all arch's [2]. [ ] Yup [X] Nope The reverse of this would be to let maintainers stabilize on all arch's after 90 days, then they are allowed to remove all but the latest stable version. This isn't good though because maintainers would be stabilizing packages on arch's where they can't test. The stable tree is significantly behind because the arch teams are so short staffed, and this prooposal is an attempt to fix that. It's attempting to fix a headache with a bullet. The arch teams are lagging behind, you're annoyed, I get it. Give 'em hell. But don't break stable to make a point. For users, both options are worse than the status quo. The first option would start reverting things back to ~ and users would have to unmask them. The second option would introduce new things to stable which may not be stable due to not being tested on the arch. The second option is worse than the first imo, that's why I didn't propose it first. The status quo is not good, because we are forced to keep old, and potentially buggy, versions of software around longer than necessary. William I think the simplest short-term solution might be to add teams that are looking for ArchTesters to the Staffing Needs page on the wiki and promote that page like crazy. I'd be more likely to do a lot more stabilizations if it wasn't just me going on my experience and running through the AT procedures myself (they're also a bit lengthy if you follow them properly, which I prefer to). I do feel some arches should be a bit deprecated. Not quite as severely other arches the council deprecated a few months back, but something. Also, to ease the burden on Arches, it'd be nice if the maintainer would do some of the archtesting work on all their available arches rather than making the AT's/arch teams do it...For example, almost everyone who has a amd64 system, can easily make a x86 chroot (or VM) to test in. Another option (and I don't mean to step on any toes or call anyone out here, these are just examples) may be to just deprecate stabilizing certain software. Packages such as the stuff in app-vim/ or app-emacs/ or some games or some scientific software. For the editor plugins, most people do not get them from the package manager I feel and a Vim plugin requires almost as much arch testing work as a new version of grep, for example...
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
I'm a nobody, but +1 from me. On 10 December 2013 16:33, Lars Wendler polynomia...@gentoo.org wrote: Am Tue, 10 Dec 2013 21:55:05 +0100 schrieb Pacho Ramos pa...@gentoo.org: https://bugs.gentoo.org/show_bug.cgi?id=197625#c14 This has reminded me that maybe we should switch to cronie from vixie-cron as default and recommended cron provider in Handbook. Last time I checked, vixie-cron upstream was died while cronie forked it fixing some bugs :/ What do you think? +1 from me (as the package maintainer of cronie I cannot vote differently here :P) -- Lars Wendler Gentoo package maintainer
[gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
On 1 July 2013 10:41, Tom Wijsman tom...@gentoo.org wrote: Hello Please reply to gentoo-dev in case ML daemon changes Reply-To. ### TL; DR ### By introducing feature patches which menu options are disabled by default to genpatches, we can deduplicate *-sources maintainers as well as large groups of users work. By introducing a distribution section in the menuconfig, we can provide options that enable minimal Gentoo requirements by default (DEVTMPFS, making Gentoo systems bootable since an udev release a long time ago) and other distribution stuff. I really like this idea. geek-sources has appealed to me massively the past few months, but i didn't want to risk stability and go with a kernel from a unofficial overlay. I can not wait to see this in gentoo-sources and I fully support this idea.
Re: [gentoo-dev] Evaluating a new malloc()
On 26 February 2013 16:37, Maciej Mrozowski reave...@gmail.com wrote: On Tuesday 26 of February 2013 11:44:31 Rich Freeman wrote: On Tue, Feb 26, 2013 at 11:35 AM, Alec Warner anta...@gentoo.org wrote: I see a *HUGE* reason. glibc ships with ptmalloc. If you think they should use jemalloc, talk to them. Don't just do it in Gentoo. Certainly I think it would be far more productive to talk to the glibc maintainers first. You mean productive like below? ;) http://sourceware.org/bugzilla/show_bug.cgi?id=11261 Ulrich Drepper: Stop reopening. There is a solution for people who are stupid enough to create too many threads. No implementation will be perfect for everyone. The glibc implementation is tuned for reasonable programs and will run much faster than any other I tested. Merge of jemalloc upstream is likely never going to happen. regards MM It could happen. Ulrich Drepper is no longer in charge of Glibc and he's barely involved in the development at all recently from what i've heard/seen.
Re: [gentoo-dev] Re: [gentoo-dev-announce] RFC: Graveyard project
On 14 February 2013 16:55, Rick Zero_Chaos Farina zeroch...@gentoo.orgwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/14/2013 04:31 AM, Ben de Groot wrote: Hi guys and girls, We hereby announce the formation of the Graveyard project [1]. It aims to provide users with an overlay for packages removed from portage. Users are expressly invited to partake in this project, to help maintain the graveyard overlay [2]. We will also help organize a central space to host distfiles that are no longer mirrored by Gentoo and have a broken upstream link. We use the #gentoo-dev-help channel on Freenode for coordination, as well as our project space on the wiki [3]. What exactly is wrong with the current cvs attic space? I've salvaged old ebuilds and it was a completely painless process. Things that have been treecleaned were not just haphazardly removed, there is typically very good (often security or complete build failure related) reasons for this to happen. Running an overlay of old, outdated, unbuildable, security vulnerable software... I know there is no formal process for rejecting a gentoo project but even this idea makes me want to get council approval for an extension to the gentoo project guidelines. If users want to salvage things from the cvs attic and put them into SUNRISE after fixing them up I'm fine with it, but the whole idea of this is bad for gentoo developers, bad for gentoo users, bad for gentoo image, I just don't see a single advantage to this and so many disadvantages. Please, this needs to not happen. Thanks, Zero Please feel free to join us! 1: http://www.gentoo.org/proj/en/graveyard/ 2: https://github.com/gentoo/graveyard 3: https://wiki.gentoo.org/wiki/Project:Graveyard -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHV1tAAoJEKXdFCfdEflK36YP/j3nXMjBUChv4a/HRVRZbK0P gEPxljhHLueKpebZfZWG2i/G5RoYT5QTzDpi146+xcKxYxypjnY4EfA3O5erXN7g rF2j8Ij8Xn4OprxDr+3+l3ojAbr+AMsyteU7jQiXEccN0n/8bDLJ1WaKa+hgy46u pWP7zm+Mi2S2ZYHuDgH7HbVadC1fyD7IB9heRXdfwuPT6lPA1pgu/jOibMZog2Uh DJlBx1emDyXt3k/noyFuDiumfNdRAwg6BegrWBuQHFNk0m8ZYiYxuuYFic/a8aRh Yz0MHsZC+FQd4dx3aDkrHNLJLszWHjyrn9shgtVp7aVu/T3rM9H2BHOZCC00ZtHC sLkMP69167YaE3UToxAA7eHQpylDBa/maJTHGFZVnz5mV8SzeOjX4ikDkfwNEUuS LpblNRZHuTDLnDWY6SJWFDK++JDqtAnPXWLAEDqEfEluMC76MVbTdhqjqvNBN8zQ lMjPTmQ/lihKR4a6LsCCkspmlEv6o4pKqWjghytqDAJuqsA1rIgKaInUPvOfCkCR 5Azl1KyIWL8oUA2OrhZdDvRd4hUlt3mJSEBcx6HC4Oj2NwtmM16zBwSJc3WKt7JC irk6D2gunFef8z1tcs/SE51lKnW+pFYIMbhyvWtumszZx/dLhu5t78KQe/8vLHnI S0R5VGULwVZkKVtSiRQK =mjOM -END PGP SIGNATURE- IMO, all these reasons are solved by the statement: This is why it will be an OVERLAY and there will be no stable packages even if they were stable in the tree before masking for removal. Packages that have tons of security issues or do not build whatsoever will obviously not be added (unless someone wants to give us a patch or 2 to solve those problems). Sunrise is the wrong place for stuff that still works. Sunrise is about stuff incoming to the tree (hopefully eventually) not outgoing from the tree. The reason for this overlay is for packages like: media-tv/ivtv and net-wireless/at76c503a which seem to be masked for removal because they're deprecated and likely still work. Perhaps a user is having problems with the driver that replaced either of these and is still using th old one since it works fine for his hardware. There are tons of good reasons to keep old packages around, yes a few possible bad ones as well, but that's the case with almost anything.
Re: [gentoo-dev] Packages up for grabs for dagger lack of time
On 5 February 2013 12:57, Pacho Ramos pa...@gentoo.org wrote: sys-apps/paludis I'll take this one (paludis) (currently at work, can't edit metadata for ~7 hours)
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On 1 January 2013 16:46, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 01/01/2013 22:29, Tony Chainsaw Vroon wrote: That sounds like a clear win. If it has survived the tinderboxing there likely isn't much to hold you back. As non-contentious topics sometimes end up with no replies at all... consider 48 hours of radio silence an implicit yes. It didn't survive. I'm not sure if all the bugs have been fixed now but at some point I had to stop the tinderboxing because it was hitting package failures, and then it was fixed for next version — which was difficult to test. So I would veto this _for the moment_. (I'd be happy to run another test _after_ the glibc-2.17 one.) -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ I was unaware that the tinderbox run hadn't finished. I definetly think it should be fully run through with pkgconf before we fully consider switching the virtual. All the bugs that have been found were fixed, last i checked, only 2 were not verified fixed, but I could not reproduce and after ~2 months of asking people to verify whether the bugs still existed on pkgconf-0.8.9, no one had replied with the results of a test, so i closed them. If you could run it through the tinderbox again Diego, that would be great and we can finish evaluating based on those results.
[gentoo-dev] Switching order of packages in virtual/pkgconfig
I would like to propose a switch of the order of DEPENDs in virtual/pkgconfig to make dev-util/pkgconf[pkg-config] the default choice for new installations. dev-util/pkgconf has less external dependencies, is lighter and is faster than dev-util/pkgconfig while being now 100% compatible This switch has already been made by Funtoo, Alpine Linux and FreeBSD with very little in the way of ill effects recently from any of those 3 camps. There are no more pending bugs against pkgconf (and Diego did a tinderbox run with it a while back) in Gentoo. pkgconf also has a upstream that is more than happy to work with us specifically (or anyone for that matter) and I (a Gentoo developer) am one of the upstream developers. If this is approved, I will make the change in ~2 weeks. I'm not planning on making a news item because users should notice little difference. Thanks Jeff
Re: [gentoo-dev] What did we achieve in 2012? What are our resolutions for 2013?
On 31 December 2012 09:17, Ben de Groot yng...@gentoo.org wrote: Happy New Year to all of you! Looking back at 2012, I wonder what we consider our achievements for this past year. What is the state of Gentoo? How have we brought it forward and improved it this past year? And what do we want to see in the coming year? How can we make Gentoo more awesome in 2013? I will add my own thoughts later. I first would like to hear from you. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin For starters, I think the state of Gentoo isn't too bad. Yes, there are a few more maintainer-needed packages than we'd like to see, but MOST packages are well maintained, we're keeping arch pretty stable and up-to-date and working well for most arches and even ~arch isn't too broken. Portage is working better than it ever has and EAPI=5 is in full swing. I wish we could get started on stabilising gcc-4.6.x, but i suppose there are still A BIT too many packages that need to be fixed with it (though nothing really critical now that we've fixed the GRUB bug). The biggest thing that has changed in Gentoo in the past year in my opinion is mindshare. I think we are back in the public's mindshare. Mostly with good advocacy, a bit with good publicity and even a bit with bad publicity (eudev haters, i'm looking at you...but i suppose the old saying There's no such thing as bad publicity applies here a bit). It hasn't really resulted in too many new developers or contributors but from what i've seen, it's resulted in A LOT of new users. For 2013, I don't really think much needs to be done. Mostly just keep the status quo. It would be nice to see the git migration happen in 2013, i'm sure that will spur many new contributors. I'd like to see preserve-libs (either in its current state or fully driven by subslots) enabled by default in 2013. Also, of course, i'd like to see more developers come on board in 2013. It's really difficult to sum up the past year and the future because, over the year, i've seen so many things in Gentoo that i've said That's so cool in regards to, but i wouldn't put it on a list of the biggest improvements of the year.
Re: [gentoo-dev] Cleaning tree of outdated packages
On 13 December 2012 17:57, Mike Gilbert flop...@gentoo.org wrote: On Thu, Dec 13, 2012 at 1:59 PM, Jory A. Pratt anar...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/13/2012 12:48 PM, Tomáš Chvátal wrote: But there is one big ass but. We have some packages that were stabilised last time few year back and they provide multiple testing versions on top of that. Who is the one to deterimine which one should go stable and which to get rid of? We had some humble tryouts to create automatic stabilisation request which didn't turn out exactly well as most of the maintainers had to actually do more work ;-) It is always up to the maintainer/herd as to when a package goes stable. But to keep ebuilds for ex. gcc around for over 5 years is just insane. Keep packages around that have been replaced with a newer package is just insane. Yes the newer package has to move to stable first, but we should be cleaning the tree up to only support what we really and truly are gonna support. Do we really want to try and use gcc-2.95 to build kernel-3.7? I highly doubt it would even work. I am sure that some people find it very handy to have old gcc ebuilds around. It might come in handy for testing. It doesn't matter if they can't compile the latest kernel. If someone files a bug for that, it gets closed as invalid; no big deal. So long as the maintainers keep them working, I see no problem with old ebuilds in the tree. I tend to agree with this sentiment. I keep several old audacious (for example) ebuilds around because the current audacious upstream broke a useful feature in newer releases and refuses to fix it, hence why i feel the need to keep audacious 2.x ebuilds around. I'm going to also keep both audacious 3.2.x and =3.3.x around since =3.3 is GTK3-only and (like me) there ma be some GTK3 haters out there who want to stay away from it. There are good reasons for keeping old ebuilds in the tree. It may seem crufty if you're just looking at the tree, but they'll be a blessing when you truly need them. Part of why I love being a Gentoo users is that if something's broken in a release, I can almost always install either an older or newer version and have my problems fixed in 5 minutes.
Re: [gentoo-dev] libxul.so in gentoo
On 21 October 2012 18:14, Jauhien Piatlicki jpiatli...@gmail.com wrote: Hi, May be a stupid question, but Both firefox and thunderbird have xul library. Before there was a separate package xulrunner in the tree, but as Mozilla does not provide it as a separate package now (as far as I remember) both firefox and thunderbird use there own libxul.so. It seems this is the same library (Or am I wrong?). So may be it could be splitted into a separate package? (The reason is its compilation takes a lot of time on week machines and compiling it one time would be better than twice). Also as far as I can see xulrunner is splitted into a separate package in Debian and at least Iceweasel uses it. Jauhien AFAIK, building Firefox and Thunderbird (and let's throw Seamonkey in there while we're at it) against a shared libxul is considered unsupported by upstream, which is why we do not do it. If compile times of mozilla products are annoying for you, feel free to try the -bin variants instead (firefox-bin, thunderbird-bin, seamonkey-bin). The dependencies aren't too crazy, they work pretty well, they get stabilised at the exact same time as the source packages and I try to bump them as quickly as or quicker than the source builds.
Re: [gentoo-dev] CIA replacement
Well nenolod has written a CIA - Irker proxy that (I believe) takes commit messages designed to go to CIA and makes irker read them and such, but i haven't looked into it: https://github.com/nenolod/irker-cia-proxy On 1 October 2012 11:21, Rafael Goncalves Martins rafaelmart...@gentoo.org wrote: Hi Ben, On Mon, Oct 1, 2012 at 5:14 AM, Ben de Groot yng...@gentoo.org wrote: Since CIA.vc is dead [1], I think we should be looking into a replacement service, or host our own [2]. Is infra already looking into this? 1: http://shadowm.rewound.net/blog/archives/245-CIA.vc-is-dead.html 2: http://www.donarmstrong.com/posts/switching_to_kgb/ Maybe someone with good cvs knowledge can contribute a hook for irker [1], so we can have #gentoo-commits flooding our irc clients again! :) [1] http://www.catb.org/esr/irker/ Best regards. -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency
On 31 August 2012 11:05, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 31/08/12 10:56 AM, Alexis Ballier wrote: Michał Górny mgo...@gentoo.org wrote: I believe that the more important direction here is to make development *easier*, not harder. Adding the same DEPENDs over and over again to every single package is at least frustrating. Similarly frustrating would be if those 'reduced systems' had to rebuild gcc every time they wanted to compile something... oh wait, they would have to bootstrap it every time. you would achieve it better by adding pkgconfig to DEPEND in eutils.eclass than putting it in @system since in the latter case it would also be a RDEPEND of everything basically And realistically that's where the DEPEND should be anyways, IMO -- appended by the eclass where the function is that uses it. If this means prune_libtool_files() gets separated out of eutils and put in its own eclass (so that all the eutils inheritors don't suddenly need virtual/pkgconfig unnecessarily), then so be it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBA0rMACgkQ2ugaI38ACPB8dgD8CsXPJvPDjI3111dXT/z+gGUM q8wTmMYqR2zVJasZMJQA/25de5bSofnwk4fXlCwPEFJ3Tu9rtCFRAx+q95oGFkad =GWHe -END PGP SIGNATURE- Also, I think that before many of these large changes happen, pkgconf should become the default choice for the virtual. I'm sure embedded or server users don't need/want Glib on their systems.
Re: [gentoo-dev] Any official position from Gentoo about systemd, mdev and udev-static ?
On 28 August 2012 12:59, Matthew Thode prometheanf...@gentoo.org wrote: On 08/28/2012 10:35 AM, Sylvain Alain wrote: Hi everyone, I don't want to start a flamewar on that subject, but I would like to know if there's any official position about the current situation. I saw on the forum this thread : https://forums.gentoo.org/viewtopic-t-934678-highlight-.html and maybe it could be part of a solution to have OpenRC and udev together. So, is there any developments lately ? Thanks ! d2_racing Maybe something to get at least some general direction from council, though probably too technical. -- -- Matthew Thode (prometheanfire) I think this issue is currently in far too murky of a state to get any well-informed issue from the council. Perhaps when the issues get hammered out a bit more, but not currently.
Re: [gentoo-dev] Opinion against /usr merge
On 17 July 2012 21:17, Richard Yao r...@cs.stonybrook.edu wrote: On 07/17/2012 08:46 PM, Rich Freeman wrote: If we don't do anything, then lots of stuff moves to /usr. I think that is what you're missing. The /usr move basically starts happening on its own automatically if we DON'T do much. This is because upstream is the one pushing it. Which upstream is pushing this? So far, only RedHat wants this and their ability to get various upstreams to try to force it is rather limited. The only upstream where I have seen any indication that this could be forced is systemd. Forgetting that GNOME is mostly managed by RedHat employees, OpenSuSE and Mageia tend to follow RedHat's leadI can probably go on if I cared to do more research.
Re: [gentoo-dev] New Manifest Hashes
The change has been made. Please remember to cvs up metadata/layout.conf and update portage (if necessary) before committing. Thanks
[gentoo-dev] New Manifest Hashes
As of Wednesday, July 4, 2012 at approximately 10:00 UTC, the manifest hashes used on the gentoo-x86 tree will change to SHA256 SHA512 WHIRLPOOL. To facilitate this change, developers MUST be using at least portage-2.1.10.49 (or portage-2.2_alpha89), or, if your dev-lang/python is built with USE=-ssl, portage-2.1.10.51 (or portage-2.2_alpha95) or later is required. For users, if they are on a older portage, it will gracefully downgrade. For developers, however, not using a supported version will cause tree inconsistencies. Developers will also need to make sure they cvs up metadata/layout.conf (or cvs up the entire tree) after this change occurs before making any commits. Thanks
Re: [gentoo-dev] Packages up for grabs due volkmar being unable to maintain them because of lack of time
On 16 June 2012 03:52, Pacho Ramos pa...@gentoo.org wrote: The following packages are now orphan: app-emulation/playonlinux app-emulation/vboxgtk dev-libs/xmlrpc-epi dev-util/bam media-libs/pnglite media-video/miro net-misc/plowshare Feel free to get them Thanks media-video/miro taken :)
Re: [gentoo-dev] RFC: Enable FEATURES=userpriv usersandbox by default?
On 29 May 2012 12:27, hasufell hasuf...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/2012 05:23 PM, Rich Freeman wrote: On Tue, May 29, 2012 at 10:57 AM, hasufell hasuf...@gentoo.org wrote: I am against too many defaults. It's documented and people can activate it. I'm already annoyed by pre-set stuff like cups in releases/make.defaults. While universal agreement is a bit much to hope for, I just wanted to point out that fewer defaults is really just an illusion. There is ALWAYS a default, anytime you have an option. The default might be one thing, or it might be another, but there is ALWAYS a default. My thinking is that our defaults should generally reflect the most mainstream or least-surprising behavior, especially where there are upstream projects. in the case of portage, we are the upstream, so we should do whatever is most useful and least obnoxious to our users. If you're running something other than a generic desktop/server, there will always be a need to tweak things. Rich Well then let my clarify: I'm against too many pre-set (meaning activated) features/useflags. That's probably a seperate discussion, but I myself would expect the _default_ profile/config to have almost nothing activated. No useflags, no features etc. That may imply that this default is broken, but it takes more time to do reverse-configuration while looking for things that someone considered sane and has set for your convenience. I discovered this the first time I set up a blank chroot and got a load of stuff pulled in by some trivial emerges. Some set by already mentioned releases/make.defaults and similar, some set by ebuilds etc. What you do with other profiles is a completely different topic, because I'm not forced to use them. means: I don't like the fact that I have to set FEATURES=-foobar or USE=-foobar That should almost never be the case (unless I set some globally and unset some locally or use desktop-profiles etc). am I offtopic already? Hope you got the point though. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPxPkHAAoJEFpvPKfnPDWzejcH/3g1VGmSRHufoQMHUpi6X1x3 31pNy2Q+SKxo4voy5Y1/mt+0lKGrhyDq6npmBY+7n5RlhdKrn8J3VyQ7HQ1jBGiS nEdSVb6BCHtFeWWWYRo6efooQFsGT+6NOFQgX/xXXgk9Ndzk8LtURGp8oP0oucNt YWfhDruoUzJXRyIMP9u6SbbDVXOnYVP+WUniNJ855l2Q1jg5lrwE6f6dD7wsbtyp 3PGBEtMqX9nAtzFZ8blUHngyrMP9J/GcJ3OVQkLXla7WBCWLqKlN0pIIiVqe2L5V 45MPQ/Muhyy0JUKLmLJLvx/2c+1I4mCt1lrfZNNN3zhepnjZSLn/uiGZk3JVEQs= =KNF8 -END PGP SIGNATURE- I disagree with this. I think Gentoo should be about SANE defaults. If you want a minimal system, you can turn off all the USE flags and/or FEATURES and/or use the standard (not desktop/) profile. SANE defaults like FEATURES=userpriv usersandbox are optimal for probably 90% of users and if you're not one of those 90%, there'll be a news item, just turn them off...
Re: [gentoo-dev] news item: Portage's config-protect-if-modified feature is enabled by default
On 17 May 2012 23:56, Michał Górny mgo...@gentoo.org wrote: On Thu, 17 May 2012 14:44:42 -0700 Zac Medico zmed...@gentoo.org wrote: I'd like to commit this news item on 2012-05-21. See previous discussion here: http://archives.gentoo.org/gentoo-dev/msg_7fe557809defad4faca2ee5c6e52d134.xml Hmm, I think your should elaborate more on what the effects will be to the final user. -- Best regards, Michał Górny I'm not sure there's a great need. Users are generally pretty smart. They just don't like change. :P
Re: [gentoo-dev] new virtual/pkgconfig to support lighter alternatives
I didn't mention this last night (probably because I was EXTREMELY tired), but the entire gentoo-x86 tree has been converted to the virtual (Y!!! *kermitflail*). As long as you don't use any overlays, you should now be able to switch your pkgconfig implementation to pkgconf[pkg-config] or pkg-config-lite with no problems. Please give them (mainly pkgconf) a try and see if everything works. :D
Re: [gentoo-dev] new virtual/pkgconfig to support lighter alternatives
On 2 May 2012 12:06, Mike Frysinger vap...@gentoo.org wrote: On Sunday 29 April 2012 18:11:58 Mike Frysinger wrote: the canonical pkg-config is getting fat. it requires glib-2. it runs pkg- we've got an implementation in perl (i'm not interested in), but there is also pkg-config-lite and pkgconf. they should be compatible with the canonical pkg-config. they aren't yet in the tree, but will be once we agree on this topic. pkg-config-lite and pkgconf are in the tree now, and there is a virtual/pkgconfig which allows for these three packages (with the default remaining the same). i think the migration process will be: - if you want to do the grunt work of converting random packages, go for it - i'll update repoman to warn about packages depending on dev-util/pkgconfig and suggest the virtual instead -mike If anyone would like to help me converting random packages/categories, it would be GREATLY appreciated. This is difficult work and it has literally taken up almost all of my free time for the past 2 days or so, but I have well over half the tree converted. just dev-util/pkgconfig - virtual/pkgconfig and if the dev-util/pkgconfig is versioned, i've been dropping the version since 0.26 is the only fd.o version in the tree and the alternatives are all 0.26 compatible. Here's the list i've been working off of: http://qa-reports.gentoo.org/output/genrdeps/dindex/dev-util/pkgconfig (It's not the most up-to-date, but it works well enough.) I am willing to finish this myself, but as I said, help would be greatly appreciated. Thanks
Re: [gentoo-dev] new virtual/pkgconfig to support lighter alternatives
On 30 April 2012 02:16, Michał Górny mgo...@gentoo.org wrote: On Mon, 30 Apr 2012 00:08:34 -0400 Mike Frysinger vap...@gentoo.org wrote: On Sunday 29 April 2012 18:40:00 Jeff Horelick wrote: On 29 April 2012 18:11, Mike Frysinger vap...@gentoo.org wrote: the canonical pkg-config is getting fat. it requires glib-2. it runs pkg- config when building. glib-2 requires pkg-config. whee. for our normal systems, this isn't a big deal. but we'd like to enable a lighter alternative for embedded/alternative systems. as such, i'd like to introduce a virtual/pkgconfig that allows for selection of simpler (but compatible) implementations. we've got an implementation in perl (i'm not interested in), but there is also pkg-config-lite and pkgconf. they should be compatible with the canonical pkg-config. they aren't yet in the tree, but will be once we agree on this topic. any comments ? I'd just like to say, i'm also an Atheme project member and I have authorisation from nenolod (the primary pkgconf developer) to make changes and stuff, so I can upstream any changes necessary to make pkgconf work for us. that sounds really good. i sent you some patches ;). however, it's missing pkg.m4. any thoughts on that ? Maybe we should provide it independently in some other package. Considering the implementations are supposed to be compatible, the .m4 file should work fine with all of them. And we'll create same configure files independently of which impl particular user uses. -- Best regards, Michał Górny Well since the 3 primary implementations (fd.o pkg-config, pkg-config-lite and pkgconf-0.2) now provide it, I don't see a huge use for a seperate package. Also, the pkg.m4 used by all 3 seems to be identical so...
Re: [gentoo-dev] new virtual/pkgconfig to support lighter alternatives
On 30 April 2012 14:27, Samuli Suominen ssuomi...@gentoo.org wrote: On 04/30/2012 01:11 AM, Mike Frysinger wrote: the canonical pkg-config is getting fat. it requires glib-2. it runs pkg- config when building. glib-2 requires pkg-config. whee. for our normal systems, this isn't a big deal. but we'd like to enable a lighter alternative for embedded/alternative systems. as such, i'd like to introduce a virtual/pkgconfig that allows for selection of simpler (but compatible) implementations. [1] pkgconf is not compatible as per Comment #5 of bug 413849. needs to follow same version scheme as f.d.o's pkg-config. not compatible != wrong. There is NO CASE in which a developer would hit this bug and customize their check in a way that would make it only work with fd.o pkg-config. In *EVERY* real-world case, the pkgconf behaviour would work just as well or better.
Re: [gentoo-dev] new virtual/pkgconfig to support lighter alternatives
On 29 April 2012 18:11, Mike Frysinger vap...@gentoo.org wrote: the canonical pkg-config is getting fat. it requires glib-2. it runs pkg- config when building. glib-2 requires pkg-config. whee. for our normal systems, this isn't a big deal. but we'd like to enable a lighter alternative for embedded/alternative systems. as such, i'd like to introduce a virtual/pkgconfig that allows for selection of simpler (but compatible) implementations. we've got an implementation in perl (i'm not interested in), but there is also pkg-config-lite and pkgconf. they should be compatible with the canonical pkg-config. they aren't yet in the tree, but will be once we agree on this topic. any comments ? -mike I'd just like to say, i'm also an Atheme project member and I have authorisation from nenolod (the primary pkgconf developer) to make changes and stuff, so I can upstream any changes necessary to make pkgconf work for us.
Re: [gentoo-dev] new virtual/pkgconfig to support lighter alternatives
On 30 April 2012 00:08, Mike Frysinger vap...@gentoo.org wrote: On Sunday 29 April 2012 18:40:00 Jeff Horelick wrote: On 29 April 2012 18:11, Mike Frysinger vap...@gentoo.org wrote: the canonical pkg-config is getting fat. it requires glib-2. it runs pkg- config when building. glib-2 requires pkg-config. whee. for our normal systems, this isn't a big deal. but we'd like to enable a lighter alternative for embedded/alternative systems. as such, i'd like to introduce a virtual/pkgconfig that allows for selection of simpler (but compatible) implementations. we've got an implementation in perl (i'm not interested in), but there is also pkg-config-lite and pkgconf. they should be compatible with the canonical pkg-config. they aren't yet in the tree, but will be once we agree on this topic. any comments ? I'd just like to say, i'm also an Atheme project member and I have authorisation from nenolod (the primary pkgconf developer) to make changes and stuff, so I can upstream any changes necessary to make pkgconf work for us. that sounds really good. i sent you some patches ;). however, it's missing pkg.m4. any thoughts on that ? -mike The patches look pretty good. As far as the solution for pkg.m4...I just gave it a second look and noticed it's GPLv2+ which means the license is compatible with pkgconf's (I thought it was GPLv3, which would've meant it wasn't compatible)...We'll work on getting those patches and the pkg.m4 in the tree and getting a 0.2 release rolled out in the next day or 2.
Re: [gentoo-dev] Unstabling a package
On 19 February 2012 21:46, Doug Goldstein car...@gentoo.org wrote: Any specific procedure to unstable a package? Specifically MythTV. While there's a lot of user interest in the package, there's just not enough dev help with the package to really keep it up to snuff to what could be considered stable. Its woefully behind and I'd just be happier to drop the current stable and bump everything as unstable. -- Doug Goldstein While i'm not willing to maintain mythtv myself (as I don't use it (anymore)) or join the herd, what about contacting upstream as they already have their own overlay [1] and see if they'd like to proxy maintain the official Gentoo packages, sort of. [1] https://github.com/MythTV/packaging/tree/master/Gentoo JD
