[gentoo-dev] One-Day Gentoo Council Reminder for December

2008-12-10 Thread Mike Frysinger
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

2008-12-10 Thread Robert R. Russell
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

2008-12-10 Thread Daniel Drake

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

2008-12-10 Thread Donnie Berkholz
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

2008-12-10 Thread Daniel Drake

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

2008-12-10 Thread Donnie Berkholz
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

2008-12-10 Thread Donnie Berkholz
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

2008-12-10 Thread Donnie Berkholz
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

2008-12-10 Thread Donnie Berkholz
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

2008-12-10 Thread Donnie Berkholz
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

2008-12-10 Thread Donnie Berkholz
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.

2008-12-10 Thread Samuli Suominen
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