[gentoo-dev] One-Day Gentoo Council Reminder for December
This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tuesday 09 December 2008 12:13:40 pm Petteri Räty wrote: Robert R. Russell wrote: My personal opinion on this matter is pick one of the following: 1) perform the bugfix without a version bump and remain at the current EAPI version 2) perform the bugfix with a version bump and remain at the current EAPI version 3) perform the bugfix with a version bump and upgrade to the latest EAPI Options 1 and 2 are how most updates are done, the user can mask the latest version or upgrade. Option 3 allows the user to continue using the previous version while they decide to update to a portage version that supports the new EAPI. The current policy states that ebuilds should only be bumped if the installed files change. Changing EAPI from 1 to 2 has no effect outside the vdb so the current policy means developers should use option 3. There was a bug in stable Portage when EAPI 2 went in the tree that made Portage stack trace but that's a problem with Portage not with the policy in general. I would prefer that option 3 be made policy because I run several ~arch packages that either don't have a stable version (kradio) or have a feature that I need (gentoo-sources), and will not be pushed to stable immediately for various reasons from lack of maintainer time to everybody says it conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, and xorg). Why should we prefer making it a little bit easier for stable users over making ~arch users needlessly recompile stuff? Regards, Petteri My answer is a simple example from my own system. My current system uses a motherboard that is around 6 months old and is only correctly supported by the latest ~arch gentoo-sources. The add on video card, a 1 to 2 year old nvidia card, works great with x11-drivers/xf86-video-nv-2.1.12 as long as I am using the latest ~arch xorg-x11. The internal video card isn't even recognized by the xf86-video-intel drivers except the ~arch versions. Even some of the packages I use for school work such as kile have bugfixes and other improvements between the versions in stable and ~arch that are important to getting work done. The ability to selectively upgrade only the specific packages needed to get a working system is a major strength for Gentoo. Why should I have to run more packages from ~arch than I absolutely need to? We all know that upgrading more software than absolutely necessary will result in bad things happening to a computer. The easiest solution to the problem with ~arch having the only working versions of some packages is to get more of those packages stabilized. But, we all know that the manpower required simply doesn't exist.
Re: [gentoo-dev] EAPI 2 policy for portage tree
Robert R. Russell wrote: My answer is a simple example from my own system. My current system uses a motherboard that is around 6 months old and is only correctly supported by the latest ~arch gentoo-sources. The add on video card, a 1 to 2 year old nvidia card, works great with x11-drivers/xf86-video-nv-2.1.12 as long as I am using the latest ~arch xorg-x11. The internal video card isn't even recognized by the xf86-video-intel drivers except the ~arch versions. Even some of the packages I use for school work such as kile have bugfixes and other improvements between the versions in stable and ~arch that are important to getting work done. The ability to selectively upgrade only the specific packages needed to get a working system is a major strength for Gentoo. With all of these problems, it sounds like in your case, our stable tree isn't living up to our hopes. *This* is the problem you should be bringing to our attention, instead of complications with portage and EAPI. I looked up your email address on bugzilla, hoping to find at least 5 bug reports, one for each of the problems you describe above. I could only find one (and even that one doesn't really make clear the fact that the current stable has problems which is affecting your schoolwork). Please could you fix that? Thanks! Daniel
Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db
On 23:35 Tue 09 Dec , Federico Ferri wrote: Donnie Berkholz wrote: As I mentioned on IRC, I think this isn't a very general use case (given the existence of --resume, --keep-going, etc.) so code to accomplish it the point was not resuming my emerge because the laptop hung. was more like: tracking which compiler built which package or vice-versa would be better put into a custom portage bashrc than into portage proper. yes, that makes sense. it could be an external tool, like revdep-rebuild is, which queries compiler by pkg, and eventually rebuilds packages (not) matching a certain compiler. but to accomplish this, an information about the compiler (in the pkg record) should be there. something like /var/db/pkg/cat/pkg/COMPILER The point is solving the right problem in the right way. It seems like you're starting with a solution you've picked and are working backward to find a good use case problem for it. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpscJAIgNKtr.pgp Description: PGP signature
Re: [gentoo-dev] EAPI 2 policy for portage tree
why offlist? Robert R. Russell wrote: Stabilization reports for ~xorg-x11 and the ~xf86-video-intel drivers aren't likely to go any where given the number of issues people are asking about on the forums But the important thing is that you notify the maintainers that you're in trouble. That may encourage them to focus more on the remaining blockers. But at the very minimum it makes them aware, and it serves as documentation for others who may hit the same problem. and the time taken to fix even simple bugs like this one https://bugs.gentoo.org/show_bug.cgi?id=227895 You can't judge the whole of Gentoo on your experience with one bug. It is also not an excuse for not filing the bugs, even if they take a while to get fixed. A user reporting the problem is just as significant as a developer fixing it. A more accurate guide to what the devs want on a filed bug report or a reply to a bug report( patches to the ebuilds, patches to the software, and the like) would help me out in giving the devs what they need or want. Suggestions appreciated. My advice would be, if something is broken, then file a bug (after doing some sanity checking to attempt to confirm it's not your fault, and nobody else has filed it). As far as the kile stabilization report, what priority do stabilization reports need? Do I need to give exact details on what doesn't work in the old version compared to the new version, which is unlikely because I can't even remember the problem that forced an upgrade? I wouldn't bother with the priority field. But information on the benefits and importance of stabling is important. Give developers motivation to fix the bug, by describing what problems the stabilisation solves. The end of school will also help with the bug filling rate going up in the next week or so. Great! Daniel
Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official
On 15:35 Mon 01 Dec , Joe Peterson wrote: However, what I see as perhaps a missing piece is more conceptual: the important connection between the valuable info in the emerge logs (and their somewhat transient default nature) and what a user looks for when he/she has a problem with a package. Yes, users will realize this as they use Gentoo (and will start paying more attention to logs as a result), so I don't think it's a huge problem, but what this particular user said to me made me think that there is, perhaps, an opportunity to improve the situation. Based on the rarity of me seeing this reported as a problem, I'm inclined to think it says more about this user than about our system. I don't think it's our responsibility to put documentation everywhere someone might conceivably look for information. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpA5SJMEiu40.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
On 19:08 Mon 17 Nov , Tobias Scherbaum wrote: That would people require to use common sense. The past has shown that people tend to have different views of what common sense might be in a given case. Therefore policy in that aspect needs to be as clear and understandable as possible to avoid unnecessary discussions. I'd rather say people need to figure out common sense so we don't need to document hundreds of pages of every tiny detail. It seems like the vast majority of people don't have a problem with figuring this stuff out. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpGiqkpi749i.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
On 13:13 Mon 10 Nov , Mark Loeser wrote: Instead of addressing archs as being slackers or not, this addresses it as a more granular layer of looking at ebuilds. Thanks to Richard Freeman for the initial proposal that I based this off of. Please give me feedback on this proposal, if you think it sucks (preferably with an explanation why), or if you think it might work. I'm not convinced why this needs to happen, because there's no reasoning behind it here. There needs to be rationale for why this should happen with pros and cons. dang mentioned a few pros from the maintainer side, the arch team ones are pretty easy to come up with. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgppmEnIvSt8K.pgp Description: PGP signature
Re: [gentoo-dev] An official Gentoo wiki
On 10:44 Wed 12 Nov , Michael Hammer wrote: * Mark Loeser [EMAIL PROTECTED] [081112 00:46]: What issues do you see with having a wiki? Pages of poor quality with wrong informations. The wiki already exists and is popular, so these already happen. Even if it's not official it says gentoo and people will associate it with their Gentoo experience regardless of whether we host it. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpTJ8aNJkR7r.pgp Description: PGP signature
Re: [gentoo-dev] An official Gentoo wiki
On 16:52 Tue 11 Nov , Joe Peterson wrote: As for Wikipedia, there is always the fear that the info will be incorrect, but time has shown that wikis tend to be very accurate and get corrected quickly when not. A page's likelihood of correctness is roughly inversely proportional to its popularity. Try a specialized topic outside of computers, and there may well be errors that only an expert will catch -- others will just be deceived. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpVthBP3nkdD.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for December
On 14:47 Mon 01 Dec , Ciaran McCreesh wrote: Please give the OK on the following, assuming no objections crop up before then: * [RFC] Label profiles with EAPI for compatibility checks (revised) http://archives.gentoo.org/gentoo-dev/msg_930f58fcebcbbcbe523c001f2c825179.xml * EAPI change: Call ebuild functions from trusted working directory http://archives.gentoo.org/gentoo-dev/msg_5ba467bbd5a0820e040210683702a67f.xml * RFC: DEFINED_PHASES magic metadata variable http://archives.gentoo.org/gentoo-dev/msg_8c34d8efbc0d31ab28c517403dc83f62.xml These things, plus updates on the bugs council@ is CC'd on, will compose our agenda. FWIW, I'm fine with all 3 of the above. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpBiYHU6tuDi.pgp Description: PGP signature
[gentoo-dev] New FFMPEG will be stabilized and unsupported packages removed from tree.
Maintainers, please see http://tinderbox.dev.gentoo.org/misc/rindex/media-video/ffmpeg and check if your package is compatible with latest FFMPEG in tree. If it's not, you still have few weeks time to fix your package. Otherwise it will be wiped from tree by treecleaners and media herds. Also, if you have redudant/unused versions here, please clean up. app-cdr/k3b-0.12.17:ffmpeg app-cdr/k3b-1.0.3:ffmpeg app-cdr/k3b-1.0.4:ffmpeg app-cdr/k3b-1.0.4-r1:ffmpeg app-cdr/k3b-1.0.5:ffmpeg app-cdr/k3b-1.0.5-r1:ffmpeg app-cdr/k3b-1.0.5-r3:ffmpeg app-cdr/k9copy-1.2.3-r2 app-mobilephone/bitpim-1.0.5 app-mobilephone/bitpim-1.0.6 dev-libs/DirectFB-extra-1.1.0:ffmpeg dev-php5/ffmpeg-php-0.5.2.1 dev-php5/ffmpeg-php-0.5.3 dev-util/bugle-0.0.20071009:ffmpeg dev-util/bugle-0.0.20080303:ffmpeg dev-util/bugle-0.0.20080803:ffmpeg games-arcade/stepmania-3.9:ffmpeg games-misc/jugglemaster-0.4:ffmpeg media-gfx/album-3.10:ffmpeg media-gfx/album-3.13:ffmpeg media-gfx/album-4.02:ffmpeg media-gfx/blender-2.43-r3:ffmpeg media-gfx/blender-2.48a-r2:ffmpeg media-gfx/blender-2.48a-r3:ffmpeg media-libs/gegl-0.0.20:ffmpeg media-libs/libquicktime-1.0.3:ffmpeg media-libs/libquicktime-1.1.0:ffmpeg media-libs/mediastreamer-2.1.0:video media-libs/mlt-0.2.4-r2:ffmpeg media-libs/mlt-0.2.4-r2:ffmpeg media-libs/mlt-0.3.2:ffmpeg media-libs/opencv-1.0.0-r1:ffmpeg media-libs/panda3d-1.5.2:ffmpeg media-libs/xine-lib-1.1.15-r1 media-plugins/alsa-plugins-1.0.15:ffmpeg media-plugins/alsa-plugins-1.0.16:ffmpeg media-plugins/alsa-plugins-1.0.17-r1:ffmpeg media-plugins/alsa-plugins-1.0.18:ffmpeg media-plugins/gst-plugins-ffmpeg-0.10.4-r1 media-plugins/gst-plugins-ffmpeg-0.10.5 media-plugins/gst-plugins-ffmpeg-0.10.6 media-plugins/mytharchive-0.20.2_p14807 media-plugins/mytharchive-0.20.2_p14877 media-plugins/mytharchive-0.21_p17105 media-plugins/mytharchive-0.21_p17948 media-plugins/mytharchive-0.21_p18355 media-plugins/vdr-audiorecorder-0.1.0_pre6 media-plugins/vdr-dxr3-0.2.6 media-plugins/vdr-dxr3-0.2.7 media-plugins/vdr-dxr3-0.2.7.2007 media-plugins/vdr-dxr3-0.2.7.20080308 media-plugins/vdr-dxr3-0.2.8 media-plugins/vdr-graphtft-0.1.18_alpha media-plugins/vdr-graphtft-0.1.21_alpha media-plugins/vdr-image-0.2.7-r1 media-plugins/vdr-image-0.2.7.26 media-plugins/vdr-osdpip-0.0.10 media-plugins/vdr-osdpip-0.0.8-r1 media-plugins/vdr-osdpip-0.0.8-r2 media-plugins/vdr-osdpip-0.0.9 media-plugins/vdr-pcd-0.9 media-plugins/vdr-softdevice-0.4.0 media-plugins/vdr-softdevice-0.4.0.20070711 media-plugins/vdr-softdevice-0.4.0.20070711-r1 media-plugins/vdr-softdevice-0.4.0.20080120 media-plugins/vdr-softdevice-0.5.0 media-plugins/vdr-softdevice-0.5.0-r1 media-plugins/vdr-softdevice-0.5.0.20080922 media-plugins/vdr-softplay-0.0.2.20060815 media-plugins/vdr-softplay-0.0.2.20070730 media-plugins/vdr-softplay-0.0.2.20080421 media-sound/aqualung-0.9_beta9_p1:ffmpeg media-sound/audacity-1.3.6:ffmpeg media-sound/cmus-2.2.0:wma media-sound/gnusound-0.7.4:ffmpeg media-sound/moc-2.5.0_alpha2:ffmpeg media-sound/moc-2.5.0_alpha3-r1:ffmpeg media-sound/moc-2.5.0_alpha3-r2:ffmpeg media-sound/mpd-0.14_beta1:ffmpeg media-sound/mpd-0.14_beta2:ffmpeg media-sound/picard-0.10-r1:ffmpeg media-sound/picard-0.10-r2:ffmpeg media-sound/picard-0.11:ffmpeg media-sound/potamus-0.9 media-sound/soundkonverter-0.3.4:ffmpeg media-sound/soundkonverter-0.3.6:ffmpeg media-sound/soundkonverter-0.3.8:ffmpeg media-sound/sox-14.0.1:ffmpeg media-sound/sox-14.1.0:ffmpeg media-sound/sox-14.2.0:ffmpeg media-sound/transkode-0.7:ffmpeg media-tv/nuvexport-0.4_p20060918 media-tv/nuvexport-0.4_p20061203 media-tv/xdtv-2.2.0-r1:ffmpeg media-tv/xdtv-2.4.0:ffmpeg media-video/cinelerra-20080717 media-video/dv2sub-0.3:kino media-video/dvbcut-0.5.4-r1 media-video/dvd-slideshow-0.7.5 media-video/dvd-slideshow-0.8.0 media-video/dvdrip-0.98.6:ffmpeg media-video/dvdrip-0.98.7:ffmpeg media-video/dvdrip-0.98.8:ffmpeg media-video/dvdrip-0.98.8-r1:ffmpeg media-video/dvdrip-0.98.8-r2:ffmpeg media-video/dvdrip-0.98.8-r3:ffmpeg media-video/dvdrip-0.98.9:ffmpeg media-video/ffmpeg2theora-0.21 media-video/ffmpeg2theora-0.22 media-video/ffmpegthumbnailer-1.2.5 media-video/ffmpegthumbnailer-1.3.0 media-video/gpac-0.4.4-r1:ffmpeg media-video/jubler-3.4.1 media-video/jubler-3.9.0 media-video/jubler-3.9.6 media-video/kdenlive-0.5 media-video/kino-1.2.0 media-video/kino-1.3.0 media-video/kino-1.3.1 media-video/lives-0.9.1 media-video/lives-0.9.5 media-video/lives-0.9.5_pre3 media-video/lives-0.9.7 media-video/lives-0.9.8.12 media-video/lives-0.9.8.5 media-video/lives-0.9.8.6 media-video/motion-3.2.10.1:ffmpeg media-video/motion-3.2.11:ffmpeg media-video/mpeg4ip-1.5.0.1-r1:mp4live+ffmpeg media-video/mpeg4ip-1.5.0.1-r1:player+ffmpeg media-video/mpeg4ip-1.5.0.1-r5:mp4live+ffmpeg media-video/mpeg4ip-1.5.0.1-r5:player+ffmpeg media-video/nemesi-0.4.0 media-video/nemesi-0.5.0 media-video/nemesi-0.5.1 media-video/nemesi-0.5.2 media-video/nemesi-0.5.3 media-video/noad-0.6.0-r9:ffmpeg media-video/tovid-0.30-r2 media-video/tovid-0.31
