Re: [gentoo-dev] New Dev: markusle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lisa Seelye wrote: | We have quantum chemistry and molecular dynamics packages? Sure we do. I've been maintaining most of them, and it's been great to see more packages showing up recently (and more help, too). Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDa6r2XVaO67S1rtsRAiNNAJwPALcjGxlWpLuFzRO3CaFQNUVvLwCfX2MI GGnnp06yeZB6ZiMnZm+FwBI= =lwy4 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Creation and handling of virtual/tar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Diego 'Flameeyes' Pettenò wrote: | What I want to hear is if anyone has good reasons to not allowing | choosing the tar command between the two compatible alternatives (both | works fine with portage). If nobody has reasons, I'll be back in a | couple of days with eclass, modified ebuilds, and if I can find time to | learn about it an eselect module to select a generic "tool" (tar only | in this moment). Sure. What's the point? What benefit does one tar have over the other? How is bsdtar more capable in any situation than gnutar? Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDb5tMXVaO67S1rtsRAj9vAKDA7OQ3FCDDEHSExLuF5zll19EbtACgpSkq KY35vUu27fks6SktZ5gUEnk= =6Mlg -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.defaults and pointless commits
Jakub Moc wrote: would someone more competent explain to me, why - this feature even exists It makes sense to enable support for packages you have installed. This should be the default behavior, and it should require manually disabling. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Distcc and SLP - request for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lisa Seelye wrote: | With bug 80219 a user posted a patch for OpenSLP support with Distcc | based off of the 2.18.3-r7 ebuild. I can't seem to make it work so I'm | going to ask the dev mail list to see if anyone else can test and make | it work. Perhaps I simply lack the SLP knowledge. | | At this time the ebuild and patch are not in CVS so you'll have to | download the ebuild and patch and digest them. | | Please test if you can and post to the bug with your findings. Out of curiosity, why isn't this patch just being sent upstream for incorporation there? Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgNCgXVaO67S1rtsRAvlwAJ99s/FwPZZaZj2yGvbkJSLoq48L1ACgwyhR xukNRYu/5rxE2wOqfSWrgfI= =NzDe -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Distcc and SLP - request for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lisa Seelye wrote: | On Sun, 2005-11-20 at 11:38 -0800, Donnie Berkholz wrote: |>Out of curiosity, why isn't this patch just being sent upstream for |>incorporation there? | | | It is, but there hasn't been much work on Distcc this year. Our policy for X is that if upstream won't accept it, we won't either. Perhaps you'd be interested in adopting that and convincing the reported to get upstream interested? Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgPyVXVaO67S1rtsRAjksAJ4x0liIbHCV0Qej5oHsNHIlfFoWuwCgtHtU qMneOCpCbBsblthSnbCxtj4= =Oj3W -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Distcc and SLP - request for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ned Ludd wrote: | On Sun, 2005-11-20 at 14:45 -0800, Donnie Berkholz wrote: |>Our policy for X is that if upstream won't accept it, we won't either. |>Perhaps you'd be interested in adopting that and convincing the reported |>to get upstream interested? | | | Your policy for X is somewhat questionable Donnie as it puts us in a | catch 22. You wont accept patches unless they came from upstream and | upstream wants some testing or to put it off till a later date..It's a | continuing heartache dealing with X when something could of been fixed | months ago. Upstream CVS is the location for testing, not distros. Distributions should have a _more_ stable version of packages than unreleased CVS, not less. In addition, we're in the business of packaging source, not maintaining source. Taking on maintainance of all the source we package is unrealistic and is not why I do Gentoo. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgYelXVaO67S1rtsRAq6lAJ9aINu0FvPT9k+gYYXeRinsm6Ua/ACfb2bD yKSOWhYljy2aCMVOfz0aaRo= =nsW6 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Modular X porting: dependency changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Because portage treats the default virtual differently than I was previously led to believe, everybody who's ported a package to modular X so far will need to make a small change. It's really easy, but it might take a bit of time to go through your packages. Here's the change: "virtual/x11" -> "<=x11-base/xorg-x11-6.99" This is because portage doesn't do a sanity check for the PROVIDES flag on the default provider of a virtual. Thanks for your time, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgjMVXVaO67S1rtsRAoJqAKDkyxtwzvqeYuuOntKldJWsOIcl6wCgspF9 /R1BEbiiQ34/KHsDag1LOlE= =uZeU -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Diego 'Flameeyes' Pettenò wrote: | On Monday 21 November 2005 21:50, Donnie Berkholz wrote: | |>Here's the change: |>"virtual/x11" -> "<=x11-base/xorg-x11-6.99" | | Is this the last change? :) | Just to make sure, I received the broken pieces of the "old" method, so I | don't really want to take them from the new one, too ;) That will be purely determined by whether people encounter problems with this change as well. =) I hope every change is the last change, as far as this is concerned. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgjgTXVaO67S1rtsRAkA2AJ9wBAGokTmbB8jB6lFgD32bxc6dKwCg9lNx oxrzqHzVV2WFH1NDXMiubZM= =Tz53 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carsten Lohrke wrote: | On Monday 21 November 2005 21:50, Donnie Berkholz wrote: | |>Here's the change: |> "virtual/x11" -> "<=x11-base/xorg-x11-6.99" | | | virtual/x11 isn't xorg for all profiles. Perhaps the relevant people (macos?) could get in touch with me, and we can figure out what needs to happen. It may be that we'll need to add x11-base/apple-xfree into the || list as well. Using the virtual is not an option right now, because of the previously mentioned bug. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgo1uXVaO67S1rtsRAjUZAKD3FlAeF06+xM6a8P7IzNMyD/GkQACguyFQ 1thol8iy6VRTRo0uaKWzogI= =4pdd -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joshua Baergen wrote: | If the list keeps growing maybe we should consider a GLEP 37-style | solution, like was suggested by Jason. It would allow us to make any | further changes that are required (agreed, hopefully none) without | having to change a bunch of packages in the tree. OK, we might as well look into it to see whether it's something we can get going within the next 2 weeks, which is about when 7.0 will be released. Jason, could you help us out? I CC'd you to make sure you'd read this. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgr4EXVaO67S1rtsRAleBAKDy8lXNdP8H1YHtzpYUsawqI+f95wCgp7r9 MlA9+EqCkvNyKcafSsKJwcc= =Ike6 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
Doug Goldstein wrote: I thought GLEP 37 was a way out kind of thing. Like several months if not a year before it can be done. I figured about the same, but https://bugs.gentoo.org/show_bug.cgi?id=112896#c16 begs to differ. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
Jakub Moc wrote: *Now* I hope I've finally been sarcastic enough to justify the incredibly pissed-off tone you've shown in your previous reply. I've not exactly seen any flames or name calling here, and I'm not the one to blame for the fact that you're feeling overloaded. Jump back in when you are in more constructive mood. With this level of irritation caused by anyone who does not jump happily on stage1 grave, the debate lacks any sense. Bleh... I hope you realize that pissing people off is a really terrible way to get them to change their minds. It's more of a way to make them lose motivation and quit doing what they're doing entirely. Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Around 425 non-existent packages in p.mask?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luis F. Araujo wrote: | So, i wrote a script to try to get a list of those orphaned entries, | and it looks like there are more than 400 packages/ebuilds which are still | listed in p.m but that don't exist in the tree anymore. | (A bunch of them from the KDE herd btw) It would be really helpful if your script could retain the category. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDg+qMXVaO67S1rtsRArJ7AKDprOrVrLoIYT2K+ryGSb0J1wtuAACgvsWz CPBMqGGMnpL3xDkI4FFAS00= =JXGU -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Napier wrote: | The contents of the uppermost menu are to sites that are outside the | www.gentoo.org website. They will stay in this location. They are green | to contrast with the purple background to ensure that colorblind and | other visually impaired people can see it. Green is the compliment to | purple so I am baffled that people think the combination is not | attractive. The particular shade of green on wwwredesign is hideous and reminiscent of bile, nausea or mucus. The green found in the upper-left corner of www.gentoo.org looks much better and would be greatly preferable. It also is brighter and would contrast better with the dark purple background, to increase accessibility. | Summary and authors are important and should be prominently displayed | before the actual content. On the current design they are on the right | in a tiny column that wraps every two words. This is unacceptable. These | items will stay at the top for now unless someone can come up with a | place to put them that makes sense, looks good, allows the summary to be | seen on top and not below the content (because a summary should be above | the content otherwise why have a summary if you have to scroll past the | content to see it?). The handbook is the only page that has a large list | of authors and authors only appear on the first page so this should not | be a problem. You've given good reasoning for including the summary at the beginning, but not the authors. Or perhaps it's impossible to split them, given how the XML works? Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDhBMzXVaO67S1rtsRAk4HAKDetpDW+7Egod7/YLEG1rqc3FKq/gCgoGCp aQaUv4B+f4ezYPqZtsAtvPY= =1cGG -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: | These packages do not need shadow (though the system might, but that's | outside my scope) once they are installed, only to install. However, it | is not needed to build. What *DEPEND is correct? It fits into RDEPEND (oddly enough), since binpkgs will need it as well and they don't get DEPEND stuff. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDhMWnXVaO67S1rtsRAv4RAJ45Wsjoz4wBzpjI+Tw3S7LAdw7NXACguR4H 9kHmi0rLZHbd69kQZlZNTW4= =GfzO -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: | That is what I thought. I was just wondering if there were some other | *DEPEND that I wasn't aware of that fit the bill of "needed for | installing from a package but not needed afterwards". It doesn't | *really* matter since shadow is in "system" on any machine this would | affect anyway, but you get my thinking. /me begins clamoring for IDEPEND (install-time deps). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDhNNUXVaO67S1rtsRAodMAJ0ZxD7gWiRU7r1SggpH/Bgd7NZ4mACg2N8Y onOzQzXwd/6hrO7+acpLonQ= =qGhH -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] enewuser/enewgroup getting their own eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Brix Andersen wrote: | I've read the initial post a couple of times now, and I still don't | get it. | | Could somebody please clarify how this differs from DEPEND? Because DEPEND is only needed for the actual build (src_* functions). With binary packages, all the pkg_* functions are run but DEPEND packages are not required to be installed. So anything external run in a pkg_* function must be in RDEPEND because it cannot be just in DEPEND, and those are the only two options. Does that help? Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDhNkEXVaO67S1rtsRAgpEAJ9R9k6mFV4qJXCs86OR6ENDNJgq+gCeKesw hEdAKjFvheFx0rJFkRLFYso= =+Df3 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Maintainer's guides?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Diego 'Flameeyes' Pettenò wrote: | Possible solutions I thought of: | | 1) have every herd controlled by a project This should be the goal already, and all herds should be looking to either join or create a project, in conjunction with other herds. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDigitXVaO67S1rtsRAj3MAJ0e94IaRqF3QAlQDBeKU/AJtw1J9ACfZHRf 6PiASl9wYGQ59dQ8HNXTG6I= =80iT -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lina Pezzella wrote: | I would want to know exactly how many keywords would be dropped with | this solution. I would hate to see something that is working perfectly | fine having support dropped due to syntax troubles in an ebuild... Portage's lack of sanity checks is completely unrelated to syntax troubles. As far as progress on this issue, we're looking into adopting glep 37 and creating a virtual/x11 ebuild to address this. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDjrDGXVaO67S1rtsRAg6KAKC6JnjB8FFilBiDqoIanbtEueYInwCdH08t pUwf5CGiYrFd0v56Q2pZK9E= =BSLt -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Modular X: ABI breakage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, With 7.0rc3 that's been entering the tree last weekend, there was an ABI change in libdrm and subsequent bump from .so.1 to .so.2. This means you'll need to run revdep-rebuild after upgrading, otherwise you'll get problems from 3D just not working to packages being unable to find libGL. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDlJa9XVaO67S1rtsRAuI2AKDSLVDRspxgWLrdI0iE9Ag8vWIQxwCgxScG aXLBBBq/eUUJBRUjX9FWK6c= =BR8x -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-core] DOWNTIME ANNOUNCEMENT bugs.gentoo.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeffrey Forman wrote: | On Tue, 2005-12-06 at 00:48 -0500, Jeffrey Forman wrote: |>This is just an 7-8 hour warning for the coming downtime of |>bugs.gentoo.org for upgrade. I plan to upgrade bugzilla the morning |>(EDT) of December 7th. I plan on alotting 30 minutes for the upgrade, |>although those in the past who have suffered through my upgrades, know |>they have gone much quicker if I do not hit any issues. I will send out |>a one hour reminder before bugs.g.o comes down. At the time of the |>upgrade, I will bring down our current buzilla, backup the database, |>copy over the new install, run some sanity checks, and then open it back |>up to the world. | | | HERE IS YOUR ONE HOUR WARNING I guess next time, it would be nice to have the correct date in the original email. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDlZ1lXVaO67S1rtsRAucoAJ4yS9uYrUNZtnZ4JEvcFvdhuOchBQCgz9cU 1bTeWm1tAG6QEqkuvsme130= =uCfv -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | As far as progress on this issue, we're looking into adopting glep 37 | and creating a virtual/x11 ebuild to address this. I've just committed virtual/x11 to the tree. See https://bugs.gentoo.org/show_bug.cgi?id=112896 if you run into any problems with it. It won't work properly with macos yet because they use a "fake" package, so they'll have to hang on to virtual/x11 in the profiles. I plan to remove the virtual/x11 definition from base/virtuals in a couple of days, because this should provide a full (and non-broken) replacement. To return to the original issue, this means the "virtual/x11" remains the correct way to specify modular dependencies and "<=6.99" should not be used. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDlpdFXVaO67S1rtsRAjhcAKDNT1Y+SeZvx6pXxHk5MC4Fr4nxhgCeNw1e HAXKaKYVrFbfipv0taBqLJ4= =RNhi -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Stubbs wrote: | On Wednesday 07 December 2005 17:03, Donnie Berkholz wrote: | |>Donnie Berkholz wrote: |>| As far as progress on this issue, we're looking into adopting glep 37 |>| and creating a virtual/x11 ebuild to address this. |> |>I've just committed virtual/x11 to the tree. See |>https://bugs.gentoo.org/show_bug.cgi?id=112896 if you run into any |>problems with it. |> |>It won't work properly with macos yet because they use a "fake" package, |>so they'll have to hang on to virtual/x11 in the profiles. | | | It should work if the listed package matches what the macos profiles have in | package.provided... Please do try adding the section and running repoman, then, from an x86 profile. |>I plan to remove the virtual/x11 definition from base/virtuals in a |>couple of days, because this should provide a full (and non-broken) |>replacement. | | | This can be easily tested in advance by adding the following: | | # cat /etc/portage/profile/virtuals | virtual/x11 -* Well, I've already tested locally by just removing the line from base/virtuals. But yes, that does sound like a nice, non-overwritable way to do it. =) Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDlyPtXVaO67S1rtsRAunBAJoD0hJmFdnrxGghdpusrvGqHXgAIACdESjv Kwx4QY+EOdteHzyXaxrfzYE= =xrrk -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Getting your apps ported to modular X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm planning on porting every installed app on my system to modular X, starting in the next couple of days. This means I will be committing to many of your applications, libraries, etc. If you don't trust my ability to do this or otherwise don't want me touching your app, please email me off-list. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDlzWiXVaO67S1rtsRAj8UAJ93vZGrhn/zM5TCMigzI8iH7KkPhgCgxeEF R65Nny/Zu3uTAZpb1FsdBEc= =A4gU -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Getting your apps ported to modular X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | I'm planning on porting every installed app on my system to modular X, | starting in the next couple of days. This means I will be committing to | many of your applications, libraries, etc. | | If you don't trust my ability to do this or otherwise don't want me | touching your app, please email me off-list. For your benefit, here's my world file. You can determine whether your app's in the list by replacing yours with it, then running 'emerge -ep world'. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDlzepXVaO67S1rtsRAg7LAJsGEHpWe8PKXVtWk+pg3l7lYLg6FgCfdM7H /LCgrs1Wnskju21pVwaXG3U= =36oE -END PGP SIGNATURE- app-text/docbook-sgml-dtd x11-libs/libSM app-forensics/chkrootkit app-shells/bash-completion app-office/dia x11-proto/xineramaproto x11-apps/xkbprint app-portage/portage-utils media-fonts/font-adobe-utopia-75dpi x11-apps/ico app-office/tpp x11-libs/Xaw3d media-fonts/font-misc-misc x11-proto/xf86miscproto app-misc/colordiff x11-apps/xeyes app-text/sgml-common app-admin/syslog-ng x11-libs/libdrm x11-libs/libXt dev-util/darcs x11-libs/libXv x11-misc/makedepend x11-libs/libXprintUtil media-fonts/font-bh-lucidatypewriter-75dpi x11-libs/libXi mail-filter/spamassassin app-portage/splat media-gfx/gimp-print app-admin/pydf dev-util/anjuta x11-apps/xfd x11-apps/xdm x11-apps/xconsole x11-apps/xrandr x11-proto/resourceproto games-fps/americas-army app-portage/porthole media-fonts/font-mutt-misc x11-libs/libXxf86dga x11-proto/fontcacheproto net-misc/curl media-video/ffmpeg x11-apps/xdriinfo app-misc/pax-utils app-text/ghostscript-afpl app-pda/gnupod app-text/rman sci-libs/acml dev-util/meld media-fonts/font-bitstream-type1 x11-proto/xf86bigfontproto x11-apps/xload net-print/foomatic-db-engine app-misc/beagle media-fonts/font-schumacher-misc sys-fs/udev media-libs/freeglut media-libs/mesa x11-apps/scripts app-text/docbook-sgml x11-misc/glx-utils dev-lang/f2c app-editors/mlview app-forensics/rkhunter x11-apps/luit x11-apps/rstart net-misc/logjam app-office/magicpoint app-crypt/seahorse media-plugins/gst-plugins-faad x11-apps/xprehashprinterlist media-video/mplayer app-doc/autobook media-sound/rhythmbox x11-apps/xrx app-text/docbook-xml-dtd x11-drivers/xf86-video-savage media-gfx/gthumb media-fonts/font-adobe-100dpi dev-python/gnome-python-extras media-video/kino app-admin/superadduser cross-sparc-unknown-linux-gnu/glibc media-fonts/font-bh-lucidatypewriter-100dpi app-text/docbook-xml-simple-dtd x11-misc/xrestop x11-apps/fslsfonts x11-misc/xcompmgr x11-apps/xstdcmap app-admin/gamin media-fonts/font-ibm-type1 app-portage/esearch x11-proto/dmxproto x11-apps/xsetpointer dev-util/subversion media-plugins/gst-plugins-ogg x11-apps/oclock dev-python/pygtk app-admin/sudo sci-chemistry/gamess media-sound/ogg2mp3 media-fonts/font-screen-cyrillic x11-apps/xvinfo sci-chemistry/mpqc media-sound/easytag x11-libs/libXxf86vm x11-apps/xhost net-analyzer/nessus dev-util/bazaar x11-apps/bitmap net-im/gaim dev-util/dialog net-misc/netkit-telnetd x11-misc/xkbdata x11-apps/xdpyinfo dev-util/gquilt x11-libs/libXTrap net-print/ink media-fonts/font-sun-misc www-client/mozilla-firefox x11-libs/pango net-print/foomatic-filters sci-chemistry/molmol x11-proto/xf86vidmodeproto app-editors/bluefish x11-misc/transset media-sound/alsa-utils x11-apps/xlsfonts x11-apps/xwud app-admin/gentoo-bugger media-libs/tiff media-plugins/xmms-xf86audio sys-kernel/linux-headers x11-apps/xphelloworld x11-libs/libXdamage sys-devel/crossdev x11-apps/rgb app-text/evince x11-apps/xmodmap net-analyzer/etherape net-www/apache x11-apps/xset app-office/planner x11-themes/xmms-themes media-sound/alsa-headers net-misc/tightvnc dev-util/screem x11-libs/libXfont media-fonts/font-sony-misc x11-libs/libXp x11-libs/libXext x11-libs/libXpm media-libs/libpng dev-lang/mono net-misc/drivel games-misc/typespeed x11-wm/fluxbox media-fonts/font-util x11-libs/libfontenc x11-libs/libXfixes app-cdr/gcombust x11-proto/fixesproto x11-proto/trapproto app-pda/gtkpod x11-proto/compositeproto x11-libs/libXvMC x11-libs/libXprintAppUtil app-cdr/gnomebaker net-irc/irssi x11-libs/libXmu x11-terms/clusterssh x11-apps/xclipboard sci-libs/mmdb media-sound/xmms x11-apps/xedit app-office/openoffice-bin x11-libs/libXres x11-proto/evieext app-misc/alexandria app-portage/epm gnome-base/control-center media-sound/mp3gain x11-libs/libXft app-portage/gentoolkit-dev media-fonts/font-bh-75dpi dev-util/gazpacho net-analyzer/nmap x11-proto/recordproto media-libs/freetype games-puzzle/mindless x11-apps/xbiff x11-themes/gentoo-xcursors media-fonts/encodings mail-client/mozilla-thunderbird x11-apps/xwd media-plugins/gst-plugins-lame x11-apps/xf86dga games-fps/ut2003-demo sys-apps/hal media-fonts/font-xfree86-type1 net-analyzer/dnstracer dev-util/pkgconfig app-text/xpdf net-dns/dnsmasq x11-apps/xprop x11-apps/xfontsel app-admin/webapp-config app-office/gnumeri
Re: [gentoo-dev] Getting your apps ported to modular X
Ciaran McCreesh wrote: So is there now a safe, correct way of specifying modular X dependencies that will actually work? It will work when I pull the virtual/x11 from base/virtuals this weekend. Until then, it will wrongly think xorg-x11-7 ebuilds provide the virtual. See my recent post on the other modular thread, "Modular X porting: dependency changes." Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Getting your apps ported to modular X
Donnie Berkholz wrote: For your benefit, here's my world file. You can determine whether your app's in the list by replacing yours with it, then running 'emerge -ep world'. It was pointed out that I worded this poorly. Rather than replacing, you should back up your own file, copy mine in, then replace it with your backup when you finish. If you've already overwritten your world file without understanding what you were doing, try regenworld. Also, here's a generated list of things from my world file that depend on X, again not produced by me: app-admin/gkrellm-2.2.5 app-text/ghostscript-7.07.1-r8 gnome-base/gnome-libs-1.4.2 gnome-base/libglade-0.17-r6 gnome-base/libgtop-2.10.2 gnome-extra/zenity-2.10.1 media-gfx/xloadimage-4.1-r4 media-libs/giflib-4.1.4 media-libs/glut-3.7.1 media-libs/gst-plugins-0.8.10 media-libs/imlib-1.9.14-r3 media-libs/imlib2-1.2.0-r2 media-libs/libmpeg2-0.4.0b media-libs/libsdl-1.2.8-r1 media-libs/smpeg-0.4.4-r7 media-plugins/xmms-alsa-1.2.10-r2 media-plugins/xmms-crossfade-0.3.8 media-plugins/xmms-esd-1.2.10-r1 media-plugins/xmms-extra-0.1 media-plugins/xmms-fmradio-1.5 media-plugins/xmms-mad-0.8 media-plugins/xmms-mpg123-1.2.10-r1 media-plugins/xmms-oggre-0.3 media-plugins/xmms-status-plugin-1.0 media-plugins/xmms-vorbis-1.2.10-r1 media-sound/xmms-1.2.10-r15 net-misc/rdesktop-1.4.1 net-www/netscape-flash-7.0.61 www-client/links-2.1_pre18 x11-base/xorg-x11-6.8.2-r6 x11-libs/gtk+-1.2.10-r11 x11-libs/gtk+-2.6.10-r1 x11-libs/libwnck-2.10.3 x11-libs/libxklavier-2.0 x11-libs/pango-1.8.1-r1 x11-libs/startup-notification-0.8 x11-libs/vte-0.11.15 x11-misc/xscreensaver-4.22-r4 x11-plugins/gkrellmms-2.1.21 x11-terms/xterm-204 x11-wm/metacity-2.10.3 You can probably count on all of those getting dep changes. Other things may as well, if they link statically or are binary. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
Donnie Berkholz wrote: I plan to remove the virtual/x11 definition from base/virtuals in a couple of days, because this should provide a full (and non-broken) replacement. Done. I will probably do similar for the other x11 virtuals (particularly xft) soon, assuming this doesn't break too badly. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Eclass subdirectory for x-modular.eclass
Joshua Baergen wrote: In an attempt to patch all driver packages automatically, I've modified x-modular.eclass to do something along the lines of what elibtoolize does for its patching. However, this would require the storage of a patch for x-modular.eclass, which I would intend to place in a subdirectory of eclass (my current choice is x-modular-files). Am I allowed to create this subdirectory, or does this break policy/anything else I'm unaware of? To be more clear for people who aren't familiar with elibtoolize -- it has a subdirectory eclass/ELT-patches/ that it keeps its patches in. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Modular X update
AREAS WE NEED HELP WITH: 1) Porting applications to modular X 2) Fixing descriptions for the vast majority of modular packages. OK, it seems like we've now got issues resolved related to the new virtual/x11 package. Despite all the eyes that looked at it and all the publicity on lists and elsewhere, we still missed the lack of stable keywords in it, which caused some issues when the default virtual was pulled from the base profile. Thanks to axxo and flameeyes for dealing with this while I was at lunch. Here's roughly how it all works: 1) Users with xorg-6.x installed will continue along happily, because 6.x PROVIDES virtual/x11 on their systems. 2) Users with no X installed will pull in the virtual/x11 package because there is no longer a default virtual. 3) Users with xorg-7.x installed will need all their packages updated for modular dependencies. There is a porting guide at http://dev.gentoo.org/~spyderous/xorg-x11/porting_to_modular_x_howto.txt -- go ahead and run through it for your favorite packages, and file bugs to their maintainers with the updated dependencies. One note for porting to modular: binary packages will require a script using ldd instead of one checking the compilation log. Petteri Räty has kindly made one available at http://dev.gentoo.org/~betelgeuse/scripts/checkdeps -- it depends on portage-utils. While packages are being ported to modular X, you will be unable to upgrade any unported packages (so likely your 'world') without an entry in /etc/portage/profile/virtuals that emulates virtual/x11 using an installed package, e.g.: virtual/x11 x11-base/xorg-x11 assuming you have the xorg-x11-7 metabuild installed. I hope that covers pretty much everything right now. Thanks for your patience, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X update
Martin Schlemmer wrote: Will need to do something about the default glu/opengl/xft virtuals as well ... (you probably did not forget this, just double checking ...) Yep. From an email I sent in the past 24 hours: Donnie Berkholz wrote: > Done. > > I will probably do similar for the other x11 virtuals (particularly > xft) soon, assuming this doesn't break too badly. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for media-video/dvdrip
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: | so the video herd policy is to remove packages until you're left with | a small enough subset of packages you can handle ? Quite a contrast with the x11 herd policy: to add packages until there's 10x more than you can reasonably maintain. Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDmjyaXVaO67S1rtsRAr7VAKCq5foXqAx4TLOdNTaeKj0SfJD/IQCg+3uV ipUhVuCqZVlbncxS7cenWSk= =GKgY -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X update
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben Skeggs wrote:
| Am Freitag, den 09.12.2005, 23:12 + schrieb Donnie Berkholz:
|
|>2) Users with no X installed will pull in the virtual/x11 package
|>because there is no longer a default virtual.
|
| A user in #gentoo-amd64 ran into issues with this that I reproduced in a
| chroot. On a new install, with no X installed you end up with messages
| saying that virtual/x11 is blocking x11-base/xorg-x11-6.8.2-r6.
|
| ie, Here's what happens when you attempt to merge aterm:
| http://members.iinet.net.au/~darktama/aterm_merge.log
|
| I'm not an expert, but the xorg-x11 ebuild has "!virtual/x11" in
| DEPEND/RDEPEND, could this be why?
Already been fixed some hours ago.
|>I hope that covers pretty much everything right now.
|
| When porting ebuilds to modular, how do we intend on handling the other
| x11 virtuals in DEPEND/RDEPEND? I'm assuming that we modify it so that
| the modular dependencies depend directly on media-libs/mesa etc, and
| leave virtual/opengl as the alternative?
|
| Or should I just wait until the real virtual/{opengl,xft,glu,glut}
| ebuilds exist before touching packages that need them?
The other ones should just stay the same as they are. virtual/x11 was
different because it was one virtual covering something that split into
hundreds of separate packages. But xft, opengl, glu are just changing
<=xorg-x11-6.99 into libXft, mesa, mesa respectively so that will
require no porting work, just more true "virtual" packages to be added.
Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDm3onXVaO67S1rtsRAjYFAJ9RHctg7zg8z8e/Ia+SFT7qbapP9QCg6qW+
6Jt04OupayM0ENoiM6GCL3Q=
=ZWXJ
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Modular X: New dep-finder scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've just updated the two dependency-finding scripts for libraries and includes. The library one should get significantly faster because of some optimizations on grepping the log; it also works better (less false positives) in most cases. The include one splits out deps found from relative versus absolute includes. It also shows reasons why some headers may not be included in the calculation. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDnNSDXVaO67S1rtsRAsxkAKDjU6smRhuUlYBKrd+w4czfnbnCRwCg67Wd wO+AKQcVu6ICh3ycwr67BQ0= =1H2Q -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Getting your apps ported to modular X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | I'm planning on porting every installed app on my system to modular X, | starting in the next couple of days. This means I will be committing to | many of your applications, libraries, etc. I've finished roughly half today -- I'm 13,400 lines into the 26,300 lines of my original emerge -Dpd world output. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDnUF3XVaO67S1rtsRAmFtAJ9vJkj0qZWdW9Smjjri1uDyY3dhdACgjS9t dI3wQT6FYNXWG9uBAR0LSFE= =9JGB -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Creating a Sketeton System
George Prowse wrote: yes but if you extracted a stage on to an already built system you would not only have the the mess there that you wanted to get rid of but also all your config files would revert back to older versions and you'd lose any changes made. ... because i'd rather not use depclean but also depclean doesn't get rid of the configs left by any packages, for instance: if i had xfce on my system before and i did emerge -C xorg-x11 && emerge depclean xfce would be wiped off but if i emerged xfce again there would still be modified parts that would use the options i selected on the previous version. It really sounds like you're contradicting yourself here. You don't want your config files overwritten, but you don't want your config files used when you remerge the packages? Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Getting your apps ported to modular X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | I'm planning on porting every installed app on my system to modular X, | starting in the next couple of days. This means I will be committing to | many of your applications, libraries, etc. I am pleased to announce I've just finished porting my system to modular X. My system now does a clean emerge -Dp world with modular X installed and no virtual/x11. Now it would be great if some more of you could do the same with your systems. (Of course, remember to check before committing.) I've seen great effort going into this from other people in the past couple of weeks as well (and earlier!). The main mistake I've seen while going through packages other people have ported is redundant dependencies. For example, libXt RDEPENDs on libSM and libICE so we don't need to also include them. I use an emerge - -ep $foo | grep lib[SIX] to check for possibly redundant dependencies. Keep up the good work! Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDn7fgXVaO67S1rtsRApOOAKCr4CHMPUczV9GoFopJGlK1EWjzbACffQ0D kuqlCBSqia3YnPn4KO4bcq4= =SPGl -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Optimizing performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Lauer wrote: | On Thu, 2005-12-15 at 07:43 -0700, Duncan wrote: |>This really belongs on user, or perhaps on the appropriate purposed list, |>desktop or hardened or whatever, not on devel. That said, some |>comments... (I can't resist. ) | | -user has the risk of many "use teh -fomglol flag, it si teh fast0r" ;-) | hardened doesn't have much to do with performance (although I'd be | interested what impact - if any - the different security features have!) ~From http://www.gentoo.org/main/en/lists.xml -- gentoo-performance Discussions about improving the performance of Gentoo Although it was a bit quiet last time I was subscribed to it. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDoZC3XVaO67S1rtsRAvIhAKDOq5aL7mSWi4sv1Qvmvn/woVLKMwCgp5xG ap+Fg5bDbSF9ZcvGnS7ysuY= =0vj5 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Binary packages in the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Loeser wrote: | Mark Loeser <[EMAIL PROTECTED]> said: | |>So, everyone that has a binary package in the tree, I would appreciate it if |>you could put the sys-libs/libstdc++-v3 depend into your package if |>necessary. | | | Well, you can tell I didn't exactly think about this too much beforehand, | since its been brought to my attention a virtual would probably be best for | this, so we would handle the || ( gcc-3.3.* libstdc++ ) inside of the | virtual. I'll make one later unless anyone has strong objections to this for | people to use in DEPEND, instead of writing the `or` dep out. Feel free to ping me if you're interested in making a new-style virtual. Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDpvphXVaO67S1rtsRAn6xAKCjTkdTfy3LllQCfXNic+EJh7k/HQCgjxoM KWzSBeT7yz/lcAnIQnMZqrA= =3Mx6 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Viability of other SCM/version control systems for big repo's
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I know some of you have done research on how gentoo-x86 converts over to other systems besides CVS such as SVN, arch, etc. But I can't find the info anywhere in my archives. Could whoever's got it, post it? I'm particularly interested in hearing about CVS, SVN, mercurial, bazaar, darcs. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDpw2YXVaO67S1rtsRAo3aAJ99o9SxpAsgGow3zSGcHu5hXZ13rwCgsXKl DD25pAKELMogICmdH5dSvhY= =bWsH -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Commiting of ~arch virtual/* ebuilds causes deptree issues
Jakub Moc wrote: the virtual/ thingy broke the deptree again with virtual/libstdc++ (see Bug 116253), essentially the same issue like with virtual/x11. These virtuals need to go straight stable if any of their RDEPEND atoms is stable for a particular arch. Shouldn't it be the reverse? Rather, they need to go stable if anything depending on them is stable. IOW, it doesn't matter if an ~arch virtual depends on stable packages. It matters if stable packages depend on an ~arch virtual. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
Donnie Berkholz wrote: I know some of you have done research on how gentoo-x86 converts over to other systems besides CVS such as SVN, arch, etc. But I can't find the info anywhere in my archives. Could whoever's got it, post it? I'm particularly interested in hearing about CVS, SVN, mercurial, bazaar, darcs. I've downloaded a copy of the gentoo-x86 repo and will run tests myself. Please advise me as to exactly which tests you would like to see, beyond whatever I feel like doing. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Annoying X.Org tarball naming (and how to deal with it)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd appreciate some ideas better than what I've come up with so far to deal with the very strange X.Org release naming. When modular tarballs are part of a full X.Org release (7.0, 7.1, etc), then they are named PN-PV-XORG_RELEASE.tar.(gz|bz2) and S matches. When modular tarballs are independently released outside a full X.Org release, they are named the standard way -- PN-PV.tar.(gz|bz2), same for S. Dealing with this all in an automated fashion in x-modular.eclass is somewhat difficult, and here's what I've come up with: A variable (XORG_PV), set by the ebuild, to tell _which_ release it's part of when it is part of a full release. If it's set, that means (1) it is part of a full release and (2) indicates which release it's part of. What does this mean for the future? All modular X ebuilds that are part of a full release will require XORG_PV to be set. All modular X ebuilds that aren't part of a full release will not require anything new. I'm doing it this way because I expect there to be more packages that aren't part of a full release than ones that are. Please give me your input on this. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDqjr2XVaO67S1rtsRAhlPAKCMvjj82U6sNPpVYsUOnKOsRwAF4QCgibKM Ccs1TnSQbXI66BVpf4P8Ed4= =NFr1 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Annoying X.Org tarball naming (and how to deal with it)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ferris McCormick wrote: | On Wed, 2005-12-21 at 21:34 -0800, Donnie Berkholz wrote: | What does this mean for the future? All modular X ebuilds that are part | of a full release will require XORG_PV to be set. All modular X ebuilds | that aren't part of a full release will not require anything new. I'm | doing it this way because I expect there to be more packages that aren't | part of a full release than ones that are. | | Please give me your input on this. | | |> Seems fine to me. I hope you are right in your assumption about |> packages in full releases. Even if I'm wrong, it's a matter of setting a single variable, and it will always have to be set for all non-7.0 releases either way (assuming ~ I'd default to 7.0) so they know which release they're part of. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDqsULXVaO67S1rtsRAo67AKCJ3f5HARANAoYdmKmD50aBMRZowgCeLggq 6Bab1dfkAH7OhpxleZiYZIQ= =88ec -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] elog file reader
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I hacked up a quick script this morning to handle the new elog scripts
in 2.1. Perhaps some of you can make use of it or help me improve it.
Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDqt2XXVaO67S1rtsRAlzuAJwJooVqex46LHMYcYTDx40kUn6/WgCgrlgr
KUC845ELqhXHZ5ZNs6PkUbQ=
=Z5KJ
-END PGP SIGNATURE-
#!/bin/bash
# This is a script to read portage log items from einfo, ewarn etc, new in the
# portage-2.1 series.
#
# Author: Donnie Berkholz <[EMAIL PROTECTED]>
# Set PORTAGE_TMPDIR
PORTAGE_TMPDIR=$(portageq envvar PORTAGE_TMPDIR)
# Set up select prompt
PS3="Choice? "
select_loop() {
ANY_FILES=$(/usr/bin/find ${PORTAGE_TMPDIR}/elogs/ -type f)
if [[ -z ${ANY_FILES} ]]; then
echo "No log items to read"
break
fi
echo
echo "This is a list of portage log items. Choose a number to view that
file."
echo
# Pick which file to read
select FILE in ${PORTAGE_TMPDIR}/elogs/*; do
case ${REPLY} in
q)
echo "Quitting"
QUIT="yes"
break
;;
*)
/usr/bin/less ${FILE}
read -p "Delete file? [y/N] " DELETE
case ${DELETE} in
q)
echo "Quitting"
QUIT="yes"
break
;;
y|Y)
/usr/bin/rm -f ${FILE}
SUCCESS=$?
if [[ ${SUCCESS} = 0 ]]; then
echo "Deleted ${FILE}"
else
echo "Unable to delete
${FILE}"
fi
;;
# Empty string defaults to N (save file)
n|N|"")
echo "Saving ${FILE}"
;;
*)
echo "Invalid response. Saving
${FILE}"
;;
esac
;;
esac
break
done
}
until [[ -n ${QUIT} ]]; do
select_loop
done
Re: [gentoo-dev] Annoying X.Org tarball naming (and how to deal with it)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | I'd appreciate some ideas better than what I've come up with so far to | deal with the very strange X.Org release naming. | | When modular tarballs are part of a full X.Org release (7.0, 7.1, etc), | then they are named PN-PV-XORG_RELEASE.tar.(gz|bz2) and S matches. When | modular tarballs are independently released outside a full X.Org | release, they are named the standard way -- PN-PV.tar.(gz|bz2), same for S. Through working with upstream and other distributors, we've come to the conclusion that having upstream provide both versioned and unversioned tarballs is the best solution and avoids this issue entirely. Take-home point: When upstream does annoying crap, talk to them about it. And when they disagree, find some friends and talk to them again. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDq3XGXVaO67S1rtsRAtDPAJ0dfkHjlHM7HXm4+yriap0Va7LLOQCfVQOF EBuHuJq5oF+TvRyfemchAkg= =+bQu -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Optimizing performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul de Vrieze wrote: | On Thursday 15 December 2005 16:50, Donnie Berkholz wrote: |>gentoo-performance Discussions about improving the performance of Gentoo |> |>Although it was a bit quiet last time I was subscribed to it. | | | I still am. The last message is from last august. And that was about someone | wanting to unsubscribe the wrong way. The last proper message was from July | 4th. That clearly means everybody thinks Gentoo's performance is great and feels no need to discuss it. =) Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDrDWsXVaO67S1rtsRAt/oAKCBfnZ+RN+rit/SIy8PgMxf8fagIACePVaX km6UtHuIbO3jqm2r4EVmcJA= =wIaL -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] X.Org 7.0 Release
Greg KH wrote: For those of us who want to try modular now, where's the pointer to how to do this (I can't seem to find it in the archives, sorry...) I've been meaning to get it into guidexml and make it a real project doc for a while now (and the accompanying porting guide), but haven't had time. Anybody who wants to help out by doing this is quite welcome to do so. I'm taking off for a week, so Josh will be taking care of your X. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] X.Org 7.0 Release
Joshua Baergen wrote: As many of you no doubt have noticed, spyderous and I finished bumping the modular packages to the newly released 7.0, which includes many changes and bug fixes since 6.8.2. Over the next few weeks we'll be finalizing licenses and other necessities. To whoever has been using modular for awhile: please let us know of any issues you currently have, or had during upgrading. What's this mean for everybody who maintains X-using applications? Well, 7.0 will probably come out of package.mask in a month at most, so that's how long you have to either get your apps ported or suffer with them being broken on ~arch systems. That's the stick end of this; I provided the carrot a while back and didn't get many takers. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ChangeLogs and rsync time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: | See the part that I said "make sense to take out". What you described is | a perfect example of something that needs to stay. All I'm getting at is | that minor things that the package maintainer thinks isn't important to | keep in the active changelog, should be able to be removed. I'm not | implying to blindly remove changelog entries solely based on the fact | that those ebuilds are in the attic. Common sense would play here. This is a nice idea in theory, but that means maintainers will have to sit around reading the whole ChangeLog and editing it. That directly takes away from real development time, for how much benefit? The tradeoff isn't worth it to me. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuguVXVaO67S1rtsRAsiBAKD0aLpFFyDmv26vLbEA9Hh4X8UGGgCg6GIT EPVU6pfW2IiFPDNGrtJX45g= =zVFO -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: | Mike Frysinger wrote: | | |>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. | | | Gentoo has been missing some kind of direction/goal for some time now. | Looking back at the last two years, what are the major | changes/accomplishments that we have done? Granted, I know there has | been great strides in improvement in some things, but I really wonder | about any ground breaking enhancements. | | Since the council is the closest representation to a leader we have, I'd | like to ask if they can come up with some kind of global goals for 2006 | and beyond. You don't need to come up with goals by this meeting if you | haven't had time, but at least by the February meeting. Each group can | have their own goals, but we lack any overall binding goals or | direction. We've brought on numerous devs in the past year, and I have | yet to see a huge improvement in QA or anything else. Numbers aren't | everything. If anything, it makes it harder to maintain good QA. Why don't we start at a smaller level and see where we get? In other words, we can build the big picture goals from where our projects and subprojects are going. Now that projects can be freely created, I see no reason that any herd or any developer in Gentoo cannot be part of a project. Each project could come up with its goals and directions, and we could see how (or whether) they fit together. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDug0zXVaO67S1rtsRAmUJAJsHZs+tP0ERWd2Y/TpxPLvCAVWuugCfXCyC G3ppfRUH0AcSNyqUnFs8c/Q= =400/ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Stelling wrote: | My point is, either you have to generalize each project's goal to a real | triviality or you have to define a goal which doesn't match some | project's goals. Conclusion: Let it be. Not necessarily. I just wrote on my blog [1] about this, and got a constructive comment [2], which I'll talk a little about. Here's one example of a global goal: Reduce the learning curve of Gentoo and increase its usability. This goal would involve a number of projects: - - Releng would work to ensure that installing Gentoo is as easy as possible. - - The documentation team would continue working to make its docs easy to follow and find. - - The installer project (as part of releng) will continue making Gentoo faster/easier to install. - - The portage team could conduct usability studies of portage (perhaps with the help of openusability.org?). - - Similar goes for some GUI / curses interfaces to configuration files and portage itself, such as porthole, ufed, etc. - - Others Thanks, Donnie 1. http://www.livejournal.com/users/spyderous/68149.html 2. http://www.livejournal.com/users/spyderous/68149.html?thread=117301#t117301 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDurQ4XVaO67S1rtsRAsMPAKDlw3hGO4IAoJeAt1Wm8GHQB59gnQCg/cjr BcwZe7U/8N+eHlv8UoeXiC0= =er6e -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: | On Tue, 03 Jan 2006 09:28:24 -0800 Donnie Berkholz | <[EMAIL PROTECTED]> wrote: | | Here's one example of a global goal: Reduce the learning curve of | | Gentoo and increase its usability. | | That goal is silly and oxymoronic. Reduced learning curve decreases | usability. I disagree. I see that something _could_ become less usable as people remove more and more features to make it easier to learn, but that's certainly not a requirement. As the saying goes, make the common tasks easy and the uncommon ones possible. Making common tasks easier doesn't necessarily decrease usability of the whole. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDur3pXVaO67S1rtsRAguaAKCissKCx8hf4t/k5rwMzcKPPWSDEQCfY9j6 txotNc7h1K+vcOw8iJEnBWU= =G95t -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: | As a prime example, I strongly believe that making Gentoo "as easy as | possible" can only come about by reducing its usability. If there is a | large number of choices, no matter how well documented, it isn't easy | for a beginner. The only way I can see to make installing Gentoo "as | easy as possible" is by removing choice and functionality to the point | of it being a few clicks of the mouse and everything being done for you. | The problem is that anything that is stated generally can be taken to an | extreme. If you say "as easy as possible" then I think unattended | identical installations for all Gentoo machines. After all, what's | easier than that? | | I would *never* agree to this, nor force any member of any project that | I am a part of to participate in such an endeavour, so you now already | have at least one person opposed to it. Would action be taken against | me? Who knows. The point is that we do not get paid. You cannot force | volunteers to do things they do not want to do. This isn't about forcing you to do things a certain way. It's about if somebody asked you to make Gentoo easier to learn and use, what would you do as part of releng? How would you do it? Perhaps you would have to make some sort of choice of usability over easy to learn, or vice versa. That's your decision. The council would just suggest what it would like to see happen to Gentoo. You're focusing too much on forcing people to do this or that. Why wouldn't you want to make Gentoo easier to use, or learn how to use? That's my question. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDutcLXVaO67S1rtsRAqS6AKDGtHunoKyN9xgqhU1e9ouDOcMcSQCg0JBX hhruT2HR4kqknDsXn8d4mXA= =AgU5 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Stelling wrote: | Donnie Berkholz wrote: |> - - Releng would work to ensure that installing Gentoo is as easy as |> possible. | | | This is very vague too. Easy for who? Easy for a user who is too lazy to | read docs and doesn't have any experience or easy for a sysadmin with | plenty of experience trying to setting up Gentoo on a cluster with >100 | boxes? I think this makes it pretty clear that there is not simply one | implementation referring to one idea, but I'm afraid that these 'goals' | could be misused to force a common direction instead of having multiple | efforts addressing the same idea in different ways. I'm guessing that the vast majority of our users have Gentoo installed on one or a few computers, and are typical hobbyists. That's who I would target with making things easier, while trying to avoid regressions in the other cases. That could certainly use some research though. | |> - - The portage team could conduct usability studies of portage (perhaps |> with the help of openusability.org?). | | | 'to conduct usability studies' sounds great, but it's IMHO not much | more. I don't need studies to point out annoying things from a user | perspective, I'm a user myself. Sure, feedback is good, but we already | get feedback, in the form of bug reports. OK, but you're one user. Maybe you are very unusual and 99 out of 100 other Gentoo users would do things totally differently. | How do e.g. arches fit into this scheme? Yeah, sure, they make Gentoo | easier to use because they keyword stuff. Great. I'm really glad | somebody tells me why I am doing the stuff I've been doing for more than | a year. | | So, the 'easy to learn/use' goal might be a goal that quite some | projects already are trying to attain, but it really isn't *THE* goal | for Gentoo, is it? Who said we can only have one goal? Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDute0XVaO67S1rtsRAmhBAJwJ5m7jXuhutvQmBr+5pJZOL6LX0gCg/1zJ +XPdMpWHtIA6bLg3n/7e000= =36So -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: | All of those of course are true. I guess I'm thinking more in the large | picture of things. Retiring non-active devs isn't something I'd exactly | call 'ground breaking' :-). I know there are things being worked on now | that will probably be in that category. I was mainly looking at the long | term flow of ground breaking progress we've made. Sure, we've made lots | of great improvements, but I'm concerned that we have too many | subprojects all working in their little world and no one really looking | over the whole project making sure things flow together well. There's no | one out there who's responsibility is to track all these subprojects and | make sure things are flowing right. Shouldn't that be the council's job? | I dunno, I just get the impression that people fear having a goal to | work on and would rather just let things work out in a random way (like | they have been for a while now). I'm not wanting to take the fun out of | this, but I feel more structure and less redtape would help make us move | forward faster and better. More structure and less red tape ... How do those two work together? I feel like they're connected -- a more structured organization will have more bureaucracy and more red tape. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuuAIXVaO67S1rtsRAuEtAJ0c+WO0EGbIURhk+LQFl/sKp938/wCdFqJU i8ID3a3B/FoAq1FVFzlNjLw= =OxkM -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] X.Org 7.0 Release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg KH wrote: | On Mon, Jan 02, 2006 at 01:56:03PM +0530, Shyam Mani wrote: | |>[2] http://www.gentoo.org/doc/en/modular-x-howto.xml | | | You mean: | http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml | right? Yeah we decided to move it to within the desktop project. Thanks for pointing this out. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuzOHXVaO67S1rtsRAhq1AJ4lk4D/OZ0REuBywJbpzr6xiV8BdACfdKcn uOd7fYtD/wR4LMLggze8G+M= =afP7 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SLOTs and libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Lauer wrote: | Hi all, | | I recently ran into an interesting problem: | | One app I have seems to trigger a bug in Python 2.4, so I want to use it | with Python 2.3 | But, as it imports a few python modules I can't use it - the modules | only get installed to the most recent Python version. | | From a portage dependency p.o.v it is satisfied - $program needs Python | 2.3 and (among others) PyCrypto, but PyCrypto is only available in | Python 2.4 and fails to import in 2.3 | | Now I'm wondering - is there a sane way of handling this that doesn't | forcefully remove python 2.4? | e.g. could python modules be installed to multiple python versions? How | do others (ruby, perl, ...) handle it? For the moment I've "solved" that | by package.masking python 2.4, unmerging it and rebuilding all Python | modules - less than optimal ... Many programs have configure options for where the python module directory is, or which python version they're using. If not, move the files around manually in src_install(). sci-chemistry/sparky installs for python 2.3 only. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvAAKXVaO67S1rtsRApdSAJ4kwf5XROsGKrH7dSl0kjU/HfkguQCdHBUT Kkd7jOjHz+9Q9HcfpQBr+yM= =csaK -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kurt Lieber wrote: | On Thu, Jan 05, 2006 at 12:39:05AM -0500 or thereabouts, Alec Warner wrote: |>The Gentoo Installer is an interesting project, not only for the |>graphical frontend, but for the Distro-sponsored Network installer that |>is being worked on. | | | I agree, but it's been "in development" for...I dunno..almost two years now | I think and it's still not released. I'm not slamming the -installer team | -- I think they're a great bunch of guys, but it does point to our | inability to execute. It's actually had a 0.1 and 0.2 release. See http://www.gentoo.org/proj/en/releng/installer/. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvLvYXVaO67S1rtsRAjVOAJ99w3kjejDBM5owoRS5WaHQT1YiBwCgtuR9 hBfLXu/MgZr9FqNCHflEuMo= =IEXy -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: regular project updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: | Funny enough... I was working on this and forgot to send it out. | | I was planning on posting it also on the Release Engineering page, but | need to turn it into GuideXML first. Might want to run it through spellcheck first. Saw at least 1 typo. Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvW8IXVaO67S1rtsRAuUxAJ4o6zv4fjRpbzcf0s8faNXnrncwXgCeIVmI rEJohkAVFsRS9DDGtQSSPj4= =xjbU -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: | As seen from the discussion earlier this week, I don't think Gentoo has | the proper open-mindness to create a proper enterprise distro. There are | too many things that would get in the way of Gentoo proper to make it | work right. I agree with Duncan that the best route is an outside | project so that they don't have the constraints of Gentoo proper. Trying | to inflict the ideals of an enterprise distro into Gentoo right now will | be an uphill battle the whole way. Just look at all the comments made | from my thread earlier. You cannot make an enterprise distro without | focus or direction and a leader. You'll be stuck in committee decisions | all the time. As a couple people have alluded to, there's very little stopping anyone from essentially creating a sub-distribution as part of a server TLP. Particularly if it doesn't affect the work of other people if they aren't interested, and you can get infra to agree to whatever you need. You can treat the lead of your server TLP as this single corporate-style leader if you want. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvrnzXVaO67S1rtsRAhS7AJwJHeT0meNdqhSzCBgBue57wGGK2QCfcxzn ngITehzzU+XMBrUC0z18uoM= =Iwzg -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Portnoy wrote: | On Fri, Jan 06, 2006 at 01:37:45AM -0700, Duncan wrote: | |>What word to use in place of "distribution", when one wants to include the |>BSDs and other "non-distributions" as well, other than |>Linux/BSD[/*ix]][/OSX], or simply *ix... *IS* there such a term? |> | | | Well we could say "meta operating system" if we wanted to be really | stupid, or we could just admit that we don't have to make a bunch of | anal terminology nerds happy and continue on using sane naming Hey, we could be like Yoper and call ourselves GentooOS! Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvrsKXVaO67S1rtsRAgWlAJ0aZu8IlPoNANBi6VeKOfr0EBHEzgCgwEuT LYABrSmTYV3EEq6QdYJvOTo= =FRpL -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuilds creating mountpoints
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefaan wrote: | I don't use pmount myself, but my guess is that /media is just a | directory that contains mountpoints, and which remains at all time | writeable for root. /afs is not writeable when mounted, just like | /dev/cdrom etc... That's actually not the case; I've never gotten around to filing a bug for it, but I mount my /media read-only (so I don't accidentally delete all my music) and pmount dies every time. Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDwEzQXVaO67S1rtsRAuNjAKDo9elzOyfHgIn3Ifnz1Q24se2pzACg9h6f TuvFF6IyGs1vtq02p1x3sLc= =7jNI -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stuart Herbert wrote: | I agree that some cleaning is needed (and some of my packages are | desperate for it!), but I'm totally opposed to this idea. I think the | idea of shutting up shop for three months (presumably with a "closed | for refurbishment" sign on the door) would let down our users who rely | on us for regular package updates, and would be a massive PR disaster. | Cleaning is something that has to happen all the time; it needs to be | a natural and sustainable part of what we do every day. I inferred "new packages" to be actual new packages and not updates to existing packages already in the tree. That's considerably less dramatic than what you're saying. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDwH9yXVaO67S1rtsRAlhzAKDtYLmNH1988nv+t6AXs8EBXCGL2ACgunH5 YuqWmn3xVX2Z4548LhL7arA= =INQ6 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo "Stable" Portage/Releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Muraco wrote: | Another thing that I don't like, is the feel of this method does seem | "offical" enough.. mostly because portage is not 'stable'-aware, Its | just using a stripped down tree. What do you want then? If an entire standalone tree distributed by Gentoo doesn't feel official enough, what will? Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDwSWAXVaO67S1rtsRAo7rAJ9YAf+Z3UUsshKfURP71lKqL5PjLwCdGcem czZJv0hCE0XbT9pjjZOtaiY= =GdT8 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Projects and simple guides
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Vermeulen wrote: | We have already received many bugs for documentation in /proj/* which is | not GDPs. I had no issue with this as I hoped this would be a transient | state where the documentation is eventually handed over to the GDP so that | both the project /and/ GDP can further maintain the documents. Seems like what would be useful is a metadata.xml-type thing for guides, so they're assigned properly. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDw1oVXVaO67S1rtsRAi0EAJ0YOQHsMazZb0fxWfU6uvQNQ6Dk9gCgtKr3 SlWUS940a1n4/YPr1Tfq0hw= =S+yA -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Projects and simple guides
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: | What if instead of having proj/en we did herd/en on www? Of course, that | doesn't help the whole "GuideXML is hard" bit. I like the idea of using | RST, but it doesn't seem very scalable at this time. Maybe, instead of | that, we created some kind of development site for herds (maybe | herds.g.o). Could be a place where herds put up status updates, specific | docs, draft docs, etc. Once things get established on that site, docs | could get moved to GDP if it were logical to do. Really every herd should be either part of a project or in the process of creating a new one for themselves by now. There's no excuse, since the block on creating new projects disappeared. | Now that leaves us to unofficial docs from users. I'm not sure where to | put that. A public wiki poses a whole slew of issues I don't think we | have enough staff to manage. But relying on gentoo-wiki isn't exactly | the best avenue either. Having a site like this is like having another | 'team' similar to the forums trying to maintain order/facts. There needs | to be another solution that doesn't require as much effort on our part. | I sadly can't think of an answer. I guess the real question is, is this | that much of a problem/issue? Are there any wikis with the same kind of spam-protection that a lot of blogging software has, such as the crazy-looking picture you have to type the word from, and required registration with a valid email address? The combination of those two would do a lot to deter automated spamming, although a determined person could still do damage if they're sitting in front of the computer. Some wiki's also support ACLs, which could help in this respect. For example, xorg.freedesktop.org has some pages that are "immutable" and can only be edited by a few people. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDw1qBXVaO67S1rtsRAsGhAJ4yjLfL7pk5hqCQgkKeoB7KQ1bd/QCggRx/ u4bFgzcQEHAZKYcOac3+3d4= =F9Jt -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Projects and simple guides
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: | Donnie Berkholz wrote: | |>Lance Albertson wrote: |>| What if instead of having proj/en we did herd/en on www? Of course, that |>| doesn't help the whole "GuideXML is hard" bit. I like the idea of using |>| RST, but it doesn't seem very scalable at this time. Maybe, instead of |>| that, we created some kind of development site for herds (maybe |>| herds.g.o). Could be a place where herds put up status updates, specific |>| docs, draft docs, etc. Once things get established on that site, docs |>| could get moved to GDP if it were logical to do. |> |>Really every herd should be either part of a project or in the process |>of creating a new one for themselves by now. There's no excuse, since |>the block on creating new projects disappeared. | | | The question I ask is ... does every herd have a project it fits under? | I doubt it. And if it doesn't, is it really considered a project? Or is | that just a generic name given now? I guess a see a distinction between | herds and projects that our current documentation url layout doesn't | cover it well. To me, it should have its own herd/fooherd layout | (example being www.gentoo.org/herd/en/netmon). Otherwise you're going to | confuse our users into thinking that herds are projects when they're | really just herds. Granted, some herds may be just a project, but I'm | mainly after the herds that have no real project to fit under. | | I understand the block was lifted for projects, but that doesn't mean | herds should all should fit underneath proj/. I agree. What I meant is that herds should be grouping together to form new projects if they don't fit in an existing one; not that they should create one project per herd. | I think we should open up | a similar space just for herds. I disagree -- they should all be able to fit into some project. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDw2znXVaO67S1rtsRAo7hAKC2yYmsZdDV0AUxf8H8ucXdI4GH8wCgzrIm itfdvfs5OSPLiEj13RmMxzs= =BdR+ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Projects and simple guides
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: | Chris Gianelloni wrote: |>I think that would be a wonderful idea. What would we do about herds |>that are a project? Simply throw in a redirect under the herd name to |>the project name? |> | | | Unless they already reside inside the /proj level, I don't want to get | into the habit of managing a bunch of redirects. The key thing here is | that we have a clear place to look for such herds. If they are a | project, then keep them in the project area. I don't want to get into the habit of inconsistency and finding herds in two different locations. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDw++4XVaO67S1rtsRAtIfAKDZPEEEzLluxkyRM71M9OAe8EnJXwCgozai OXmV2IwAJX0Is2MmFl2Ists= =oSxG -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Projects and simple guides
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: | But herd != project. They are two distinct things. There are a couple of | cases where they both are the same, but others where it isn't. For | example, what project would netmon fit under? They aren't actively | trying to create a specific idea inside of gentoo. To me that's one | thing that defines a project from a herd. A herd mainly deals with | organizing a group of ebuilds. I don't see how you can label every herd | into a project. Probably a networking project with net-*. Perl and other languages could form a language project, or development tools to suck up most of dev-* herds, or something like that. etc etc.. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDw++9XVaO67S1rtsRAii7AJ4jTsCv29MXxzWN9CHczOtcYQXVFgCgmZJz ONyKdUODFsNVSH2uB+Ly40Q= =dD+e -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Projects and simple guides
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | I don't want to get into the habit of inconsistency and finding herds in | two different locations. To clarify, add an "either" onto the end of that. | Thanks, | Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDw/EvXVaO67S1rtsRAgB/AKD2yimcsyeTaBBu1fjHbHoFFM5pvgCgm77O yLqqUtWWPdqOY7AV2dMQIas= =KdiE -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] a plea for testing help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg KH wrote: | Well, it's not a Gentoo specific plea, but a Linux kernel plea. I've | created a new kernel tree, git-sources, that tracks the upstream | development kernel tree every day (not the raw git tree, but the nightly | snapshots of it.) | | If you want to help out with kernel development testing, please run | these kernels and let us know if you have problems with them. I'm | especially interested in finding out if any existing userspace programs | need updating to work properly, as the alsa/udev/whatever tie is pretty | strong to the kernel these days, and we (Gentoo) needs to keep on top of | it. Hi Greg, Where should people file bugs on this? Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDw/yiXVaO67S1rtsRAneXAKCBW3UGyw4As5p/OP8wUH5ZMZyKvQCgroax XRzXrURCN7bp+3pTb+uUS64= =A/F3 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] a plea for testing help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg KH wrote: | On Tue, Jan 10, 2006 at 10:27:46AM -0800, Donnie Berkholz wrote: |>Where should people file bugs on this? | | | To quote the einfo text that is shown when you install this kernel: | This kernel is not supported by Gentoo due to its unstable and | experimental nature. If you have any issues, try a matching | vanilla-sources ebuild -- if the problem is not there, please | contact the upstream kernel developers at http://bugme.osdl.org | and on the linux-kernel mailing list to report the problem so it | can be fixed in time for the next kernel release. | | Does that seem acceptable? Might be worth saying if the problem _is_ in vanilla-sources, they should file a Gentoo bug instead. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxAoIXVaO67S1rtsRAiu6AKDE3WeD7aH3G2g6+f+wmnB3x50LkwCg4Fb7 PrqBmZ8PeYfAv70V0V+DvDY= =Mq+c -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Projects and simple guides
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stuart Herbert wrote: | Don't you think that maybe you're trying to bash square pegs into | round holes just for the sake of some sort of order that perhaps | doesn't actually benefit anyone at all? | | Where did the requirement that a herd has to be part of a larger | project come from? GLEP 39's crystal clear that we don't need a | project to cover every peice of work that Gentoo devs do. Herds | aren't even mentioned in there :) | | Why not just let herds carry on creating entries under /proj/en/? If | they're part of a larger project, that project can just link to the | herd's page. Our directory structure doesn't have to reflect a | biological classification tree :) I think having some sort of hierarchical structure does benefit people. Not in the least because the "leads" can take care of any bureaucracy or red tape that may come up to affect anybody in their project. Having a person like this for a number of herds rather than a single herd just seems like an intuitively good idea to me. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxK1CXVaO67S1rtsRAmN7AJ43jB+CAm4SifWonJ22TL5yD0C2mACfZ8Za 6ZEJB2pLW4H4S3QUtyAJ0Rs= =m8JK -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC - new category dev-tos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sanchan wrote: | Alexandre Buisse wrote: | |>I don't know TinyOS, but I assume it is a "toy OS", like minix and many others. |>What about a dev-toyos category? It could be great to have some other |>toy OS, including the one I have been working on (funk, see |>http://home.gna.org/funk/), but also, if licences allow it, plan9, |>minix3, coyotos, l4 and so on. |> |>I do not have ebuilds for any of them but could help make some if people |>agree that it could be useful. | | | from: http://tinyos.net/special/mission | | TinyOS is an open-source operating system designed for wireless embedded sensor | networks. Sounds like it might fit into dev-embedded. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDyURnXVaO67S1rtsRAt4hAJ9vWFf1li2sHIliVCjOT21uNc1NfACfXLSR OcFQQ4Prg8Noq2nWehUNLpU= =3oKm -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some LaTeX news
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexandre Buisse wrote: | Hi, | | for all of you who have been using latex on gentoo, here are some news | on what is currently happening. | | First of all, we have a new tetex (tetex-3.0_p1). It should have hit the | mirrors this morning. This is not an official release from upstream | (that would be 3.1) but a snapshot of their development tree that | corrects some bugs with the autotools (see bug #113024). If we manage to | solve the etex related problems (all the "Fatal error: I'm stymied"), it | could be a good candidate for stabilisation. What will you do if upstream decides to release 3.0_p1? Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDyUSsXVaO67S1rtsRAnhFAJ4mQcVC77arwGW+VZy11MKYJMrc5wCbBdev cSjhO/eRlHhpV/XQSE+wFTo= =eklZ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC - new category dev-tos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: | yes, but fbsd is a self hosting env, tinyos is not | | i wish there was a way we could convey the embedded aspect (embed-tos ?), but | dev-tos works for me Why stuck on "tos" -- Just spend the other 3 letters and make it tinyos at least, so people can figure out what it actually is. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDyUXUXVaO67S1rtsRAoW4AKC2InuVIDk5/VPRuavRbXORIdQuyQCfUG8F 7ZYdb3T9bg2AJzvZG6pOf6Q= =By+g -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New local use "binfilter" for app-office/openoffice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Proschofsky wrote: | Hi everyone, | | I've added a new local use flag called "binfilter" to | app-office/openoffice. This enables building support for legacy | StarOffice 5.x file formats. My advice: Only build with this, if you | really need it, this will add considerably to the overall build time. "binfilter" is a very non-obvious name for what it does to anyone unfamiliar with the build system. Why not call it "staroffice"? Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDzAkLXVaO67S1rtsRAk26AKCAawXu8s7ZlMoewYQfdayr+LMiQgCgvOol 63I6aojzD+t4LUgZLXCVQAI= =aQyF -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Find apps not ported to modular X
I hacked together a script this afternoon to find any packages that are not yet ported to modular X. It will only work on systems _with modular X installed_. This is because it works by using emerge to check for blockers, then resolving those blockers down to a single package. Try it out and let me know how it works. If you want to watch it at work and have confidence that it didn't freeze or anything, add "set -o xtrace" up near the top. For my Athlon 2000+, it takes about 1.5 minutes to track down 2 packages in my 650-package world file. If you find bugs, please report them with a patch attached. If you can't come up with a patch, definitely include your world file so others can try to reproduce. Thanks, Donnie find_broken_modular_package.sh Description: application/shellscript signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Find apps not ported to modular X
Donnie Berkholz wrote: I hacked together a script this afternoon to find any packages that are not yet ported to modular X. It will only work on systems _with modular X installed_. This is because it works by using emerge to check for blockers, then resolving those blockers down to a single package. Here's a small enhancement to take an optional category name as an argument to check packages in that category instead of whatever's installed on your system. For example: [EMAIL PROTECTED] ~ $ ./find_broken_modular_package.sh app-accessibility app-accessibility/brltty app-accessibility/dasher app-accessibility/gnome-mag Thanks, Donnie find_broken_modular_package.sh Description: application/shellscript signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Find apps not ported to modular X
Donnie Berkholz wrote: Donnie Berkholz wrote: I hacked together a script this afternoon to find any packages that are not yet ported to modular X. It will only work on systems _with modular X installed_. This is because it works by using emerge to check for blockers, then resolving those blockers down to a single package. Here's a small enhancement to take an optional category name as an argument to check packages in that category instead of whatever's installed on your system. And here's a list, with herds and maintainers, of a loop across each category in PORTDIR. This should be a fairly comprehensive list of every app not yet ported. Feel free to sort by herd with `sort -k2 broken_modular_maintainers.txt` or whatever field you prefer, or regenerate it differently. Maintainer info added with this one-liner: for i in $(app-accessibility/brltty accessibility dmwaters app-accessibility/dasher gnome-accessibility none app-accessibility/gnome-mag gnome-accessibility none app-arch/pdv app-cdr/nero none wschlich app-crypt/scsign crypto dragonheart app-dicts/kannadic cjk usata app-dicts/wnn-ldic cjk none app-editors/lfhex none dragonheart app-editors/peacock text-markup none app-editors/qemacs emacs none app-editors/wily app-editors/xemacs xemacs xemacs app-editors/xemacs-gtk app-editors/xvile app-editors/zoinks none genone app-emacs/imaxima emacs none app-emacs/uim-el cjk emacs none app-emacs/yc cjk none app-i18n/canfep cjk none app-i18n/canna cjk none app-i18n/canuum cjk none app-i18n/chinput cjk none app-i18n/fbiterm cjk none app-i18n/fcitx cjk none app-i18n/freewnn cjk none app-i18n/gtkimprime cjk none app-i18n/iiimf-canna cjk none app-i18n/im-canna cjk none app-i18n/im-freewnn cjk none app-i18n/kimera cjk none app-i18n/kinput2 cjk none app-i18n/minichinput cjk none app-i18n/scim cjk none app-i18n/scim-anthy cjk none app-i18n/scim-canna cjk none app-i18n/scim-chinese cjk none app-i18n/scim-cvs cjk none app-i18n/scim-hangul cjk none app-i18n/scim-m17n cjk none app-i18n/scim-pinyin cjk none app-i18n/scim-prime cjk none app-i18n/scim-qtimm cjk none app-i18n/scim-skk cjk none app-i18n/scim-tables cjk none app-i18n/scim-uim cjk none app-i18n/scim-wnn cjk none app-i18n/skim cjk none app-i18n/skkinput cjk none app-i18n/uim cjk usata app-i18n/uim-fep cjk none app-i18n/uim-kdehelper cjk none app-i18n/uim-svn cjk none app-i18n/unicon cjk none app-i18n/x-unikey cjk pclouds app-misc/jogmouse app-misc/joy2key app-misc/livecd-tools livecd none app-misc/multimon app-misc/oneko app-misc/sonypid app-misc/tkpasman app-misc/twin none vapier app-misc/worker none none app-misc/wyrd none maintainer-needed app-office/lyx cjk text-markup none app-office/openoffice-ximian-bin openoffice none app-office/plan none none app-office/pointless app-office/texmacs text-markup none app-office/texmaker text-markup none app-pda/qtopia-desktop-bin pda nerdboy app-text/cedilla none none app-text/clara none spock app-text/dvibook text-markup none app-text/dvipdfm text-markup none app-text/flpsed text-markup none app-text/ghostview app-xemacs/ada app-xemacs/apel xemacs xemacs app-xemacs/auctex app-xemacs/bbdb app-xemacs/build app-xemacs/calc app-xemacs/calendar app-xemacs/cc-mode app-xemacs/clearcase app-xemacs/cookie app-xemacs/crisp app-xemacs/c-support app-xemacs/debug app-xemacs/dictionary app-xemacs/dired app-xemacs/docbookide app-xemacs/ecb app-xemacs/ecrypto app-xemacs/edebug app-xemacs/edict app-xemacs/ediff app-xemacs/edit-utils app-xemacs/edt app-xemacs/efs app-xemacs/egg-its app-xemacs/eieio app-xemacs/elib app-xemacs/emerge app-xemacs/eshell xemacs xemacs app-xemacs/ess xemacs xemacs app-xemacs/eudc app-xemacs/footnote app-xemacs/forms app-xemacs/fortran-modes app-xemacs/frame-icon app-xemacs/fsf-compat xemacs xemacs app-xemacs/games app-xemacs/gnats app-xemacs/gnus xemacs xemacs app-xemacs/haskell-mode app-xemacs/hm-html-menus app-xemacs/ibuffer app-xemacs/idlwave app-xemacs/igrep app-xemacs/ilisp xemacs xemacs app-xemacs/jde xemacs xemacs app-xemacs/latin-unity app-xemacs/leim app-xemacs/liece app-xemacs/locale app-xemacs/lookup app-xemacs/mailcrypt app-xemacs/mail-lib xemacs xemacs app-xemacs/mew app-xemacs/mh-e app-xemacs/mine app-xemacs/misc-games app-xemacs/mmm-mode xemacs xemacs app-xemacs/mule-base xemacs xemacs app-xemacs/mule-ucs xemacs xemacs app-xemacs/net-utils xemacs xemacs app-xemacs/ocaml app-xemacs/os-utils app-xemacs/pc app-xemacs/pcl-cvs app-xemacs/pcomplete app-xemacs/perl-modes xemacs xemacs app-xemacs/pgg app-xemacs/prog-modes app-xemacs/psgml xemacs xemacs app-xemacs/psgml-dtds xemacs xemacs app-xemacs/ps-print xemacs xemacs app-xemacs/python-modes app-xemacs/reftex app-xemacs/rmail app-xemacs/ruby-modes app-xemacs/sasl app-xemacs/scheme app-xemacs/semantic app-xemacs/sgml app-xemacs/sh-script app-xemacs/sieve app-xemacs/skk app-xemacs/slider app-xemacs/sml-mode app-xemacs/sounds-au app-xemacs/sounds-wav app-xemacs/speedbar app-xemacs/strokes app-xemacs/supercite app-xemacs/texinfo
Re: [gentoo-dev] Find apps not ported to modular X
Donnie Berkholz wrote: And here's a list, with herds and maintainers, of a loop across each category in PORTDIR. This should be a fairly comprehensive list of every app not yet ported. Today's update, synced as of about an hour ago, along with the script to generate everything if you want to do so on your own. Thanks, Donnie app-accessibility/brltty accessibility dmwaters app-accessibility/dasher gnome-accessibility none app-accessibility/gnome-mag gnome-accessibility none app-arch/pdv app-cdr/nero none wschlich app-crypt/scsign crypto dragonheart app-dicts/kannadic cjk usata app-dicts/wnn-ldic cjk none app-editors/lfhex none dragonheart app-editors/peacock text-markup none app-editors/qemacs emacs none app-editors/wily app-editors/xemacs xemacs xemacs app-editors/xemacs-gtk app-editors/xvile app-editors/zoinks none genone app-emacs/imaxima emacs none app-emacs/uim-el cjk emacs none app-emacs/yc cjk none app-i18n/canfep cjk none app-i18n/canna cjk none app-i18n/canuum cjk none app-i18n/chinput cjk none app-i18n/fbiterm cjk none app-i18n/fcitx cjk none app-i18n/freewnn cjk none app-i18n/gtkimprime cjk none app-i18n/iiimf-canna cjk none app-i18n/im-canna cjk none app-i18n/im-freewnn cjk none app-i18n/kimera cjk none app-i18n/kinput2 cjk none app-i18n/minichinput cjk none app-i18n/scim cjk none app-i18n/scim-anthy cjk none app-i18n/scim-canna cjk none app-i18n/scim-chinese cjk none app-i18n/scim-cvs cjk none app-i18n/scim-hangul cjk none app-i18n/scim-m17n cjk none app-i18n/scim-pinyin cjk none app-i18n/scim-prime cjk none app-i18n/scim-qtimm cjk none app-i18n/scim-skk cjk none app-i18n/scim-tables cjk none app-i18n/scim-uim cjk none app-i18n/scim-wnn cjk none app-i18n/skim cjk none app-i18n/skkinput cjk none app-i18n/uim cjk usata app-i18n/uim-fep cjk none app-i18n/uim-kdehelper cjk none app-i18n/uim-svn cjk none app-i18n/unicon cjk none app-i18n/x-unikey cjk pclouds app-misc/jogmouse app-misc/joy2key app-misc/livecd-tools livecd none app-misc/multimon app-misc/oneko app-misc/sonypid app-misc/tkpasman app-misc/twin none vapier app-misc/wyrd none maintainer-needed app-office/lyx cjk text-markup none app-office/openoffice-ximian-bin openoffice none app-office/pointless app-office/texmacs text-markup none app-office/texmaker text-markup none app-pda/qtopia-desktop-bin pda nerdboy app-text/cedilla none none app-text/clara none spock app-text/dvibook text-markup none app-text/dvipdfm text-markup none app-text/flpsed text-markup none app-text/ghostview app-xemacs/ada app-xemacs/apel xemacs xemacs app-xemacs/auctex app-xemacs/bbdb app-xemacs/build app-xemacs/calc app-xemacs/calendar app-xemacs/cc-mode app-xemacs/clearcase app-xemacs/cookie app-xemacs/crisp app-xemacs/c-support app-xemacs/debug app-xemacs/dictionary app-xemacs/dired app-xemacs/docbookide app-xemacs/ecb app-xemacs/ecrypto app-xemacs/edebug app-xemacs/edict app-xemacs/ediff app-xemacs/edit-utils app-xemacs/edt app-xemacs/efs app-xemacs/egg-its app-xemacs/eieio app-xemacs/elib app-xemacs/emerge app-xemacs/eshell xemacs xemacs app-xemacs/ess xemacs xemacs app-xemacs/eudc app-xemacs/footnote app-xemacs/forms app-xemacs/fortran-modes app-xemacs/frame-icon app-xemacs/fsf-compat xemacs xemacs app-xemacs/games app-xemacs/gnats app-xemacs/gnus xemacs xemacs app-xemacs/haskell-mode app-xemacs/hm-html-menus app-xemacs/ibuffer app-xemacs/idlwave app-xemacs/igrep app-xemacs/ilisp xemacs xemacs app-xemacs/jde xemacs xemacs app-xemacs/latin-unity app-xemacs/leim app-xemacs/liece app-xemacs/locale app-xemacs/lookup app-xemacs/mailcrypt app-xemacs/mail-lib xemacs xemacs app-xemacs/mew app-xemacs/mh-e app-xemacs/mine app-xemacs/misc-games app-xemacs/mmm-mode xemacs xemacs app-xemacs/mule-base xemacs xemacs app-xemacs/mule-ucs xemacs xemacs app-xemacs/net-utils xemacs xemacs app-xemacs/ocaml app-xemacs/os-utils app-xemacs/pc app-xemacs/pcl-cvs app-xemacs/pcomplete app-xemacs/perl-modes xemacs xemacs app-xemacs/pgg app-xemacs/prog-modes app-xemacs/psgml xemacs xemacs app-xemacs/psgml-dtds xemacs xemacs app-xemacs/ps-print xemacs xemacs app-xemacs/python-modes app-xemacs/reftex app-xemacs/rmail app-xemacs/ruby-modes app-xemacs/sasl app-xemacs/scheme app-xemacs/semantic app-xemacs/sgml app-xemacs/sh-script app-xemacs/sieve app-xemacs/skk app-xemacs/slider app-xemacs/sml-mode app-xemacs/sounds-au app-xemacs/sounds-wav app-xemacs/speedbar app-xemacs/strokes app-xemacs/supercite app-xemacs/texinfo app-xemacs/text-modes xemacs xemacs app-xemacs/textools app-xemacs/time app-xemacs/tm app-xemacs/tooltalk app-xemacs/tpu app-xemacs/tramp app-xemacs/vc app-xemacs/vc-cc app-xemacs/vhdl app-xemacs/view-process app-xemacs/viper app-xemacs/vm app-xemacs/w3 app-xemacs/xemacs-base xemacs xemacs app-xemacs/xemacs-devel app-xemacs/xemacs-eterm app-xemacs/xemacs-ispell app-xemacs/xemacs-packages-sumo none none app-xemacs/xslide app-xemacs/xslt-process xemacs xemacs app-xemacs/zenirc dev-ada/adabindx ada none dev-ada/adaopengl ada none dev-cpp/gtkglextmm gnome-mm none dev-do
Re: [gentoo-dev] Find apps not ported to modular X
Sebastian Bergmann wrote:
Donnie Berkholz schrieb:
dev-php/PECL-imagick php none
This package only has
DEPEND="${DEPEND} >=media-gfx/graphicsmagick-1.0.0"
listed as its dependencies.
Ah, yes. It will also catch whether anything in the dependency tree of
any app is broken, not just the app itself. Having an app working
requires fixing the entire dep tree of that app.
[EMAIL PROTECTED] genomics $ emvp PECL-imagick
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[blocks B ] x11-libs/libXft (is blocking x11-base/xorg-x11-6.8.99.15-r4)
[ebuild UD] x11-base/xorg-x11-6.8.99.15-r4 [7.0] USE="bitmap-fonts%
font-server% opengl% pam% truetype-fonts% type1-fonts% xv% -3dfx% -cjk%
-debug% -doc% -insecure-drivers% -ipv6% -minimal% -nls% -nocxx% -sdk%
-static% -xprint" 0 kB
[ebuild N] virtual/x11-6.8 0 kB [3]
[ebuild N] media-gfx/graphicsmagick-1.1.6-r1 USE="X gs jpeg lcms
png tiff truetype wmf xml2 -doc -jbig -jp2 -lzw -perl" 4,843 kB
[ebuild N] dev-php/PECL-imagick-0.9.11 67 kB
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Find apps not ported to modular X
Donnie Berkholz wrote: I hacked together a script this afternoon to find any packages that are not yet ported to modular X. It will only work on systems _with modular X installed_. This is because it works by using emerge to check for blockers, then resolving those blockers down to a single package. Try it out and let me know how it works. If you want to watch it at work and have confidence that it didn't freeze or anything, add "set -o xtrace" up near the top. For my Athlon 2000+, it takes about 1.5 minutes to track down 2 packages in my 650-package world file. If you find bugs, please report them with a patch attached. If you can't come up with a patch, definitely include your world file so others can try to reproduce. My current script seems to miss some things. The reason this happens is that the group of applications they're emerged in also contains some app that breaks the emerge, perhaps because it's in package.mask or isn't keyworded at least ~x86. Broken emerges don't get far enough to produce blocking output, so it's falsely assumed to be a success for that group. marienz suggested an idea for error handling last night, and I'll work to figure something out. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Find apps not ported to modular X
Donnie Berkholz wrote: My current script seems to miss some things. The reason this happens is that the group of applications they're emerged in also contains some app that breaks the emerge, perhaps because it's in package.mask or isn't keyworded at least ~x86. Broken emerges don't get far enough to produce blocking output, so it's falsely assumed to be a success for that group. marienz suggested an idea for error handling last night, and I'll work to figure something out. OK, I've got this fixed. Suddenly there are 1037 unported apps instead of 500! How exciting. Here's the REAL current copy of the list, and the fixed script. Thanks, Donnie app-accessibility/brltty accessibility dmwaters app-accessibility/dasher gnome-accessibility none app-accessibility/gnome-mag gnome-accessibility none app-accessibility/gnopernicus gnome-accessibility none app-accessibility/gok gnome-accessibility none app-admin/modlogan none liquidx app-admin/otpcalc none taviso app-arch/dczip java none app-arch/pdv app-backup/bacula none fserb hadfield app-cdr/nero none wschlich app-crypt/scsign crypto dragonheart app-dicts/kannadic cjk usata app-dicts/wnn-ldic cjk none app-editors/cooledit none agriffis app-editors/elvis app-editors/emacs-cvs emacs none app-editors/fte none voxus app-editors/gmanedit app-editors/jasspa-microemacs emacs none app-editors/jed none liquidx app-editors/jove none seemant app-editors/lfhex none dragonheart app-editors/peacock text-markup none app-editors/qemacs emacs none app-editors/wily app-editors/xemacs xemacs xemacs app-editors/xemacs-gtk app-editors/xvile app-editors/zoinks none genone app-emacs/imaxima emacs none app-emacs/uim-el cjk emacs none app-emacs/yc cjk none app-emulation/bochs none lu_zero app-emulation/cedega wine none app-emulation/crossover-office-bin wine none app-emulation/crossover-office-pro-bin wine none app-emulation/e-uae none dholm app-emulation/fuse none bug-wranglers app-emulation/gxemul none kumba app-emulation/i8086emu dev-embedded dev-embedded app-emulation/pearpc none none app-emulation/point2play wine vapier app-emulation/spectemu app-emulation/spim none compnerd app-emulation/transgaming-fontinstaller wine none app-emulation/transgaming-mozctlinstaller wine none app-emulation/uae none dholm app-emulation/vice games none app-emulation/vmware-console vmware jmglov app-emulation/winesetuptk wine none app-emulation/winex-transgaming wine none app-emulation/xcopilot none none app-emulation/xtrs app-i18n/canfep cjk none app-i18n/canna cjk none app-i18n/canuum cjk none app-i18n/chinput cjk none app-i18n/fbiterm cjk none app-i18n/fcitx cjk none app-i18n/freewnn cjk none app-i18n/gtkimprime cjk none app-i18n/iiimf-canna cjk none app-i18n/im-canna cjk none app-i18n/im-freewnn cjk none app-i18n/kimera cjk none app-i18n/kinput2 cjk none app-i18n/minichinput cjk none app-i18n/scim cjk none app-i18n/scim-anthy cjk none app-i18n/scim-canna cjk none app-i18n/scim-chinese cjk none app-i18n/scim-cvs cjk none app-i18n/scim-hangul cjk none app-i18n/scim-m17n cjk none app-i18n/scim-pinyin cjk none app-i18n/scim-prime cjk none app-i18n/scim-qtimm cjk none app-i18n/scim-skk cjk none app-i18n/scim-tables cjk none app-i18n/scim-uim cjk none app-i18n/scim-wnn cjk none app-i18n/skim cjk none app-i18n/skkinput cjk none app-i18n/uim cjk usata app-i18n/uim-fep cjk none app-i18n/uim-kdehelper cjk none app-i18n/uim-svn cjk none app-i18n/unicon cjk none app-i18n/x-unikey cjk pclouds app-misc/cbtracker none none app-misc/cmatrix app-misc/jogmouse app-misc/joy2key app-misc/livecd-tools livecd none app-misc/multimon app-misc/oneko app-misc/sonypid app-misc/tkpasman app-misc/twin none vapier app-misc/wyrd none maintainer-needed app-office/imposter openoffice none app-office/lyx cjk text-markup none app-office/openoffice-ximian-bin openoffice none app-office/pointless app-office/texmacs text-markup none app-office/texmaker text-markup none app-pda/qtopia-desktop-bin pda nerdboy app-portage/portagemaster tools-portage none app-text/cedilla none none app-text/clara none spock app-text/dvibook text-markup none app-text/dvipdfm text-markup none app-text/flpsed text-markup none app-text/ghostview app-text/manedit none fuzzyray app-text/mftrace fonts text-markup none app-text/nopaste none agriffis app-text/pspresent none none app-text/tex-guy text-markup none app-text/xdvik cjk text-markup usata app-text/yudit app-xemacs/ada app-xemacs/apel xemacs xemacs app-xemacs/auctex app-xemacs/bbdb app-xemacs/build app-xemacs/calc app-xemacs/calendar app-xemacs/cc-mode app-xemacs/clearcase app-xemacs/cookie app-xemacs/crisp app-xemacs/c-support app-xemacs/debug app-xemacs/dictionary app-xemacs/dired app-xemacs/docbookide app-xemacs/ecb app-xemacs/ecrypto app-xemacs/edebug app-xemacs/edict app-xemacs/ediff app-xemacs/edit-utils app-xemacs/edt app-xemacs/efs app-xemacs/egg-its app-xemacs/eieio app-xemacs/elib app-xemacs/emerge app-xemacs/eshell xemacs xemacs app-xemacs/ess
Re: [gentoo-dev] Find apps not ported to modular X
Donnie Berkholz wrote: OK, I've got this fixed. Suddenly there are 1037 unported apps instead of 500! How exciting. Today's update.. down to 1012 packages. Donnie app-accessibility/brltty accessibility dmwaters app-accessibility/dasher gnome-accessibility none app-accessibility/gnome-mag gnome-accessibility none app-accessibility/gnopernicus gnome-accessibility none app-accessibility/gok gnome-accessibility none app-admin/modlogan none liquidx app-admin/otpcalc none taviso app-arch/dczip java none app-arch/pdv app-backup/bacula none fserb hadfield app-cdr/nero none wschlich app-dicts/kannadic cjk usata app-dicts/wnn-ldic cjk none app-editors/cooledit none agriffis app-editors/elvis app-editors/emacs-cvs emacs none app-editors/gmanedit app-editors/jasspa-microemacs emacs none app-editors/jed none liquidx app-editors/jove none seemant app-editors/lfhex none dragonheart app-editors/peacock text-markup none app-editors/qemacs emacs none app-editors/wily app-editors/xemacs xemacs xemacs app-editors/xemacs-gtk app-editors/xvile app-editors/zoinks none genone app-emacs/imaxima emacs none app-emacs/uim-el cjk emacs none app-emacs/yc cjk none app-emulation/bochs none lu_zero app-emulation/cedega wine none app-emulation/crossover-office-bin wine none app-emulation/crossover-office-pro-bin wine none app-emulation/e-uae none dholm app-emulation/fuse none bug-wranglers app-emulation/gxemul none kumba app-emulation/i8086emu dev-embedded dev-embedded app-emulation/pearpc none none app-emulation/point2play wine vapier app-emulation/spectemu app-emulation/spim none compnerd app-emulation/transgaming-fontinstaller wine none app-emulation/transgaming-mozctlinstaller wine none app-emulation/uae none dholm app-emulation/vice games none app-emulation/vmware-console vmware jmglov app-emulation/winesetuptk wine none app-emulation/winex-transgaming wine none app-emulation/xcopilot none none app-emulation/xtrs app-i18n/canfep cjk none app-i18n/canna cjk none app-i18n/canuum cjk none app-i18n/chinput cjk none app-i18n/fbiterm cjk none app-i18n/fcitx cjk none app-i18n/freewnn cjk none app-i18n/gtkimprime cjk none app-i18n/iiimf-canna cjk none app-i18n/im-canna cjk none app-i18n/im-freewnn cjk none app-i18n/kimera cjk none app-i18n/kinput2 cjk none app-i18n/minichinput cjk none app-i18n/scim cjk none app-i18n/scim-anthy cjk none app-i18n/scim-canna cjk none app-i18n/scim-chinese cjk none app-i18n/scim-cvs cjk none app-i18n/scim-hangul cjk none app-i18n/scim-m17n cjk none app-i18n/scim-pinyin cjk none app-i18n/scim-prime cjk none app-i18n/scim-qtimm cjk none app-i18n/scim-skk cjk none app-i18n/scim-tables cjk none app-i18n/scim-uim cjk none app-i18n/scim-wnn cjk none app-i18n/skim cjk none app-i18n/skkinput cjk none app-i18n/uim cjk usata app-i18n/uim-fep cjk none app-i18n/uim-kdehelper cjk none app-i18n/uim-svn cjk none app-i18n/unicon cjk none app-i18n/x-unikey cjk pclouds app-misc/cbtracker none none app-misc/cmatrix app-misc/jogmouse app-misc/joy2key app-misc/livecd-tools livecd none app-misc/multimon app-misc/oneko app-misc/sonypid app-misc/tkpasman app-misc/twin none vapier app-misc/wyrd none maintainer-needed app-office/imposter openoffice none app-office/lyx cjk text-markup none app-office/pointless app-office/texmacs text-markup none app-office/texmaker text-markup none app-pda/qtopia-desktop-bin pda nerdboy app-portage/portagemaster tools-portage none app-text/cedilla none none app-text/clara none spock app-text/dvibook text-markup none app-text/dvipdfm text-markup none app-text/flpsed text-markup none app-text/ghostview app-text/manedit none fuzzyray app-text/mftrace fonts text-markup none app-text/nopaste none agriffis app-text/pspresent none none app-text/tex-guy text-markup none app-text/xdvik cjk text-markup usata app-text/yudit app-xemacs/ada app-xemacs/apel xemacs xemacs app-xemacs/auctex app-xemacs/bbdb app-xemacs/build app-xemacs/calc app-xemacs/calendar app-xemacs/cc-mode app-xemacs/clearcase app-xemacs/cookie app-xemacs/crisp app-xemacs/c-support app-xemacs/debug app-xemacs/dictionary app-xemacs/dired app-xemacs/docbookide app-xemacs/ecb app-xemacs/ecrypto app-xemacs/edebug app-xemacs/edict app-xemacs/ediff app-xemacs/edit-utils app-xemacs/edt app-xemacs/efs app-xemacs/egg-its app-xemacs/eieio app-xemacs/elib app-xemacs/emerge app-xemacs/eshell xemacs xemacs app-xemacs/ess xemacs xemacs app-xemacs/eudc app-xemacs/footnote app-xemacs/forms app-xemacs/fortran-modes app-xemacs/frame-icon app-xemacs/fsf-compat xemacs xemacs app-xemacs/games app-xemacs/gnats app-xemacs/gnus xemacs xemacs app-xemacs/haskell-mode app-xemacs/hm-html-menus app-xemacs/ibuffer app-xemacs/idlwave app-xemacs/igrep app-xemacs/ilisp xemacs xemacs app-xemacs/jde xemacs xemacs app-xemacs/latin-unity app-xemacs/leim app-xemacs/liece app-xemacs/locale app-xemacs/lookup app-xemacs/mailcrypt app-xemacs/mail-lib xemacs xemacs app-xemacs/mew app-xemacs/mh-e app-xemacs/mine app-xemacs/misc-games app-xemacs/mmm-mode xemacs xemacs app-xemacs
Re: [gentoo-dev] Find apps not ported to modular X
Lares Moreau wrote: Could you post updates once a week(or two), similar to what [EMAIL PROTECTED] does with the aging ebuilds. I don't feel a play-by-play is necessary. I will be posting daily updates until it goes into ~arch, planned for Jan. 25. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Find apps not ported to modular X
Dan Meltzer wrote: Would you considder putting these daily updates on your devspace instead of sending a huge email daily? Nope. That puts the effort on these developers who haven't ported apps to actually go to my webspace and search around. On re-reading what you said, I could post a link to the list and keep that in my devspace. But I'm not going to stop the daily emails to the list. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Find apps not ported to modular X
Alec Warner wrote: Did you find another way to do those deps then? We haven't released 2.0.54 with that fixed yet... The drivers will continue to require manual emerging in ~arch until a fixed portage comes out, and the migration guide continues to document and support that method. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
Mike Frysinger wrote: - we will set sane debug defaults in the base profile: * DEBUG_CFLAGS=DEBUG_CXXFLAGS="-O -g" On gcc-4, even -O can make it really hard to track stuff. Might want -O0 instead. 4.1 gets even crazier. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Find apps not ported to modular X
Donnie Berkholz wrote:
Today's update.. down to 1012 packages.
Yesterday was pretty weak, only 9 packages got ported. We're at 1003 now.
Latest list:
http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_maintainers.txt.20060120
Documentation:
http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml
http://www.gentoo.org/proj/en/desktop/x/x11/porting-modular-x-howto.xml
Metabug:
http://bugs.gentoo.org/112675
If you can't figure out what needs to get done and you've already read
the docs, feel free to ask on the list or ping me on IRC.
And a list of the herds with 10 or more unported packages, generated with:
awk '{ print $2 }'
dev/public_html/broken_modular/broken_modular_maintainers.txt.20060120 |
sort | uniq -c | sort -n -r
204 games
91 desktop-dock
81 desktop-misc
49 cjk
43 gnustep
36 desktop-wm
34 sci
20 xemacs
18 video
18 sound
14 media-tv
10 text-markup
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Find apps not ported to modular X
You definitely made up for Thursday's performance yesterday by dropping the number of unported packages from 1003 to 917. I've posted a graph of our progress [1]. Keep up the good work of the past day, and the tree will be in great shape in time for modular X to enter ~arch. Latest list: http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_maintainers.txt.20060121 Herds and individuals with 10 or more unported packages: 196 games 139 (no metadata) 120 none (individual maintainer) 91 desktop-dock 49 cjk 43 gnustep 36 desktop-wm 32 sci 20 xemacs 18 video 18 sound 18 desktop-misc 17 vapier 14 media-tv 10 text-markup > Documentation: > http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml > http://www.gentoo.org/proj/en/desktop/x/x11/porting-modular-x-howto.xml > > Metabug: > http://bugs.gentoo.org/112675 > > If you can't figure out what needs to get done and you've already read > the docs, feel free to ask on the list or ping me on IRC. Thanks, Donnie 1. http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_progress.png (source for it is the .agr, for media-gfx/grace) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2
Marius Mauch wrote: > On Sun, 22 Jan 2006 14:45:34 -0500 > Mike Frysinger <[EMAIL PROTECTED]> wrote: > >> On Saturday 21 January 2006 23:12, Marius Mauch wrote: >>> Mike Frysinger wrote: On Sunday 15 January 2006 01:11, Mike Frysinger wrote: - we add an emerge flag (say '--debug-build') which adds "debug-build" to FEATURES >>> IMO this is pointless and redundant. >> its purpose is to handle cases where user wants to always have a >> package built in this manner (ferringb mentioned it as a possibility >> and someone else mentioned they would like it) > > I meant the option is redundant if it just triggers a feature setting, > as it's the same as `FEATURES=debug-build emerge foo` OK, where's my package.features and packages.cflags files then? I can do what I want through Mike's proposal, which is to build a specific collection of packages with debugging. I also don't need to duplicate the same list of packages in one file with FEATURES=nostrip and in another with debugging CFLAGS. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Find apps not ported to modular X
Yesterday's drop: 17 to 871. Not as impressive as Saturday, but not bad. Progress graph: http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_progress.png Latest list: http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_maintainers.txt.20060122 Herds and individuals with 10 or more unported packages: 190 games 136 (no metadata) 110 none (individual maintainer) Of these, 20 also have no individual maintainer listed 83 desktop-dock 48 cjk 43 gnustep 35 desktop-wm 28 sci 20 xemacs 18 video 18 sound 18 vapier 15 media-tv 10 text-markup Documentation: http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml http://www.gentoo.org/proj/en/desktop/x/x11/porting-modular-x-howto.xml Metabug: http://bugs.gentoo.org/112675 If you can't figure out what needs to get done and you've already read the docs, feel free to ask on the list or ping me on IRC. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Find apps not ported to modular X
Donnie Berkholz wrote: > Yesterday's drop: 17 to 871. Not as impressive as Saturday, but not bad. Sorry, that's 917. So it dropped by 36. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Unmasking modular X
Here's my proposal for dealing with modular X entering ~arch. Yes, some packages are going to break. But I intend to keep this to a minimum on packages people care about, as measured by the existence of an open porting bug. So here's my plan: Before modular X enters ~arch, I will ensure that all porting bugs blocking #112675 are closed. As new bugs are filed, I will ensure that they are closed within 2 days, giving their maintainers that long to respond and close it themselves. After 2 days, I, or other members of the x11 team and any volunteers, will jump in and fix it ourselves. Earlier tonight, I discussed with halcy0n our differing opinions of the need for modular X to enter ~arch and break trees for some ~arch users. In my opinion, this is acceptable and beneficial, as ~arch users should already be those willing to help out. It will assist in learning which of the still-unported apps are actually in use and help compile a possible list of tree removal candidates. halcy0n, on the other hand, feels that any breakage of the ~arch tree is anathema. Please contact me if you'd like to be one of these volunteers. Requirements: A) You have commit access to gentoo-x86, AND B) you're comfortable with the porting process OR are adept with ebuilds and would like to help It's my earnest hope that this proposal makes everyone happy, because I refuse to let modular X get old and rusty in package.mask while hundreds of unmaintained (or undermaintained, for whatever reason) applications hold it back. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
Ciaran McCreesh wrote: > On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz > <[EMAIL PROTECTED]> wrote: > | Here's my proposal for dealing with modular X entering ~arch. > > What's wrong with the original idea of just making any unported ebuild > pull in all of modular X (minus drivers)? Yes, it means that some > people will pick up unnecessary deps until all packages are ported, but > it avoids anyone having to see flashy red errors. The problem with that is that it removes all motivation to ever port the packages. They'll just stay that way forever, where forever means "until I threaten to remove that from the virtual," in which case we'll be in the same scenario we are now. Why? Because people have better things to do than fix stuff that isn't broken. Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Find apps not ported to modular X
Yesterday's drop: 871 to 867, a whopping 4. We need to do better than this! We're in the home stretch. Progress graph: http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_progress.png Latest list: http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_maintainers.txt.20060122 Herds and individuals with 10 or more unported packages: Almost the same as before. Documentation: http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml http://www.gentoo.org/proj/en/desktop/x/x11/porting-modular-x-howto.xml Metabug: http://bugs.gentoo.org/112675 If you can't figure out what needs to get done and you've already read the docs, feel free to ask on the list or ping me on IRC. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
Mike Doty wrote: > I think before you go forward with something like this you should give a > suitable period of warning, it's going to create a lot of bug work for > all of us. Have you seen my daily emails for the past week and a half? =) I have the feeling that it will create the most work for Jakub and whoever besides myself volunteers to help out with the porting. Most other groups, besides games, have very few packages, and if they're feeling lazy, they can just wait a day and get them fixed by us. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Unmasking modular X
Mark Loeser wrote: >>> On Mon, 23 Jan 2006 23:06:12 -0800 Donnie Berkholz >>> <[EMAIL PROTECTED]> wrote: >>> What's wrong with the original idea of just making any unported ebuild >>> pull in all of modular X (minus drivers)? Yes, it means that some >>> people will pick up unnecessary deps until all packages are ported, but >>> it avoids anyone having to see flashy red errors. >> The problem with that is that it removes all motivation to ever port the >> packages. They'll just stay that way forever, where forever means "until >> I threaten to remove that from the virtual," in which case we'll be in >> the same scenario we are now. Why? Because people have better things to >> do than fix stuff that isn't broken. > > It'd be nice if you reconsidered this as it will minimize any breakage that > may occur. Knowing that >800 packages are broken, and going to unmask it > knowing that just doesn't seem acceptable in my eyes. ~arch isn't meant to > be "things are known to be broken." It's meant to mean, we think all of this > is ready to be stable, which it certainly won't be in this case. No, it won't. It will just postpone the same breakage, as I said above. You haven't provided any logic or backup to your contrary statement, just said that somehow a large portion of the other 800 will magically get ported. Let me break this down again: of that 800, about 250 are unmaintained packages according to metadata.xml or lack thereof. About 200 are games. About 150 more belong to largely inactive herds. That's roughly 600 that we already know will not get ported in a timely fashion, if left to their maintainers, all because of lack of manpower. What do you propose to deal with them? All I've heard besides mine is proposals that delay the same breakage, not actually get anything fixed. Thanks, Donnie signature.asc Description: OpenPGP digital signature
