Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
This is just a metabug for the request to remove Gnome 1.x from the tree. Please link all the bugs against Gnome 1.x packages as blockers of this bug.
I am currently working towards this task.
What are the motives to remove gtk use flag from net-misc/unison and if removed, what will be the default behavior? It DEPENDs in >=dev-ml/lablgtk-2.2 for all but 2.9.1-r1 versions and all versions RDEPEND on net-misc/gtk2-ssh-askpass.
Please do not create lists on this bug, I will be keeping the official list at http://compnerd.org/~compnerd/files/gnome-1.txt . Thanks for your understanding.
What dev-util/glade-2 doing in the package removal list for Gnome 1.x? dev-util/glade-2 is GTK+2 app.
Sorry there were a misunderstanding from my side :) dev-util/glade binary is named glade-2.
Quick look to media-sound/grip homepage (http://www.nostatic.org/grip/grip-download.shtml) shows that: ------------------------- To use Grip, you must have: * The Gnome2 desktop ... ------------------------- It seems not dependend on gnome1.
Yes, grip-3.3.x has no required dependencies on gnome1. The ebuild contains a dependency on libghttp:, ie gnome-base/libghttp but this is bogus - probably just leftovers from an ancient grip ebuild. Take out that dependency and grip builds fine - no gnome1 required.
I really need gnome-libs 1.x to stay for one of my scientific apps. Porting to GTK-2 is not an option to do in this time frame because it's in progress by upstream and it's a very complex application that interfaces with Guile libraries that only use GTK-1 as well. I don't mind accepting some of the maintenance burden for gnome-libs.
Hi, I have two corrections to the list: games-emulation/generator optionally depends on gtk1; I'll be submitting an ebuild to remove that app-emulation/vice-1.20 does not depend on gtk1 any longer. previous versions do
(In reply to comment #8) > I really need gnome-libs 1.x to stay for one of my scientific apps. Porting to > GTK-2 is not an option to do in this time frame because it's in progress by > upstream and it's a very complex application that interfaces with Guile > libraries that only use GTK-1 as well. > > I don't mind accepting some of the maintenance burden for gnome-libs. > You need gnome-libs 1.x or gtk1 ? Scientific application I use also use gtk1 and this library is a must for me have
sci-chemistry/coot uses x11-libs/gtk-canvas, which uses gnome-libs.
(In reply to comment #8) > I really need gnome-libs 1.x to stay for one of my scientific apps. Porting to > GTK-2 is not an option to do in this time frame because it's in progress by > upstream and it's a very complex application that interfaces with Guile > libraries that only use GTK-1 as well. > > I don't mind accepting some of the maintenance burden for gnome-libs. > Same problem here. I think that gtk1 can be in the tree without gnome 1.4 :-/ Thanks a lot
Do you guys not read anything in this bug? Comment #7: Grip-3.3.x DOES NOT require gnome-1.4. The ebuild contains a bogus dependency on libghttp which is not required. And yet, it has been package.masked Go ahead, remove it. But doing so on reasoning that it is dependent on gnome 1.4 is BS
(In reply to comment #7) > Yes, grip-3.3.x has no required dependencies on gnome1. The ebuild contains a > dependency on libghttp:, ie > gnome-base/libghttp > but this is bogus - probably just leftovers from an ancient grip ebuild. Take > out that dependency and grip builds fine - no gnome1 required. > I would for this reason strongly consider keeping grip in. In my opinion it's one of the better front-ends for ripping in a graphical environment, or does anyone have a pointer to a better front-end?
Folks, move the grip debate to Bug 155428 if you really can't resists. This is a tracker bug, not a grip one.
This is also supposed to be a bug where one can dispute the gnome-1 package list. At least that is what we were being told: http://forums.gentoo.org/viewtopic-t-514782.html Quote: How to dispute the resolution: 1) You can comment on bug #154102
Please, DON'T REMOVE grip from the tree. It doesn't depend on gnome-1.x and it works fine for me. Thanks
(In reply to comment #17) > Please, DON'T REMOVE grip from the tree. It doesn't depend on gnome-1.x and it > works fine for me. Which part of Comment #15 did you miss? :(
(In reply to comment #18) > (In reply to comment #17) > > Please, DON'T REMOVE grip from the tree. It doesn't depend on gnome-1.x and it > > works fine for me. > > Which part of Comment #15 did you miss? :( > What part of Comment #16 did you miss?
In the future, can gentoo package maintainers please do the USE flag removal FIRST before starting to mask packages? I ask because I did an emerge sync and have quite a number of the packages in the USE flag removal section emerged with "gnome" useflag and without manually adding each of those packages into my package.use file, or removing "gnome" entirely from my USE flags I am now stuck with package masking errors when trying to update. I meant to make this comment on the bug a while ago, but I assumed that it just made sense and that's what would have happened.
(In reply to comment #20) > In the future, can gentoo package maintainers please do the USE flag removal > FIRST before starting to mask packages? Sure, we'd love to, if we had a working way to find them which doesn't take half day or more for one run. Many people spent hour of work checking for the dependencies and it went wrong because of a bug in a package that's used for these checks. And many people spent hours of their time late at night to fix the tool as fast as possible. Thanks for understanding.
*** Bug 155509 has been marked as a duplicate of this bug. ***
emerge -uDpv world resulted in masked package output for gdk-pixbuf. ======================================================================== These are the packages that would be merged, in order: Calculating world dependencies / !!! All ebuilds that could satisfy ">=media-libs/gdk-pixbuf-0.2.5" have been masked. !!! One of the following masked packages is required to complete your request: - media-libs/gdk-pixbuf-0.22.0-r5 (masked by: package.mask) # Saleem Abdulrasool <compnerd@gentoo.org> (16 Nov 2006) # GNOME 1.x Removal Mask (15 Dec 2006) For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. (dependency required by "x11-themes/redhat-artwork-0.243-r1" [ebuild]) !!! Problem resolving dependencies for x11-themes/redhat-artwork !!! Depgraph creation failed. ============================================================================ AFAIK, gdk-pixbuf doesn't depend on gnome-1.x, and redhat-artwork is NOT masked. from the gdk-pixbuff-0.22.0 tarball README: ============================================================================= To install the gdk-pixbuf library, you will want to have the following libraries installed: libpng 1.0.3 ; ls -l /usr/lib/libpng.so.2.* http://www.cdrom.com/pub/png ftp://swrinde.nde.swri.edu/pub/png/src zlib 1.1.3 ; ls -l /usr/lib/libz.so.* http://www.cdrom.com/pub/infozip/zlib ftp://swrinde.nde.swri.edu/pub/png/src libjpeg v6b ; ls -l /usr/lib/libjpeg.so.6* http://www.ijg.org/ ftp://ftp.uu.net/graphics/jpeg/ libtiff v3.4 ; ls -l /usr/lib/libtiff.so.* http://www.sgi.com/fun/freeware/graphics.html ftp://ftp.sgi.com/graphics/tiff/
(In reply to comment #21) > (In reply to comment #20) > > In the future, can gentoo package maintainers please do the USE flag removal > > FIRST before starting to mask packages? > > Sure, we'd love to, if we had a working way to find them which doesn't take > half day or more for one run. Many people spent hour of work checking for the > dependencies and it went wrong because of a bug in a package that's used for > these checks. And many people spent hours of their time late at night to fix > the tool as fast as possible. Thanks for understanding. > I understand that not all packages are going to be caught. However, in this case, the document at http://compnerd.org/~compnerd/files/gnome-1.txt had a good chunk of the known ones listed when I first visited that URL over a week ago. I'm not trying to be an ass, but just suggesting that since these were known, why not take care of them ahead of time?
Andy, we're all volunteers. We all contribute. If you knew about the issue before hand it was your responsibility to speak up and to contribute to the project which you clearly benefit from. You might not be trying to be an ass but you're sure coming across as one.
(In reply to comment #25) > Andy, we're all volunteers. We all contribute. If you knew about the issue > before hand it was your responsibility to speak up and to contribute to the > project which you clearly benefit from. You might not be trying to be an ass > but you're sure coming across as one. > I'm not trying to get into a pissing match and if I appear to be starting one I apologize. This is my last word on this. I didn't know about the issue before hand because it didn't happen yet. I thought about it, and assumed that's how it would have been handled and didn't bother. Next time I will. But since I didn't, I wanted to make the suggestion for the next time something similar occurs. That's all. Nothing more, nothing less.
gnome-base/libghttp depends only on virtual/libc, as such I don't see a reason to remove this due to GNOME-1.x removal. Related to that: * media-sound/orpheus can remain in the tree in a way that it continues to support cddb (see bug 156193); * net-fs/intersync doesn't have to be removed due to GNOME-1.x removal; * dev-perl/HTTP-GHTTP could remain, but becomes superfluous once the older versions of dev-perl/AxKit (that dep on HTTP-GHTTP) are removed from the tree, so I don't see a point in keeping dev-perl/HTTP-GHTTP, given there there is CPAN.
*** Bug 154202 has been marked as a duplicate of this bug. ***
Please unmask mandrake-artwork: http://bugs.gentoo.org/show_bug.cgi?id=156702 Thanks
/\ _`\ /\__ _\ /\ _`\ \ \ \L\ \ \/_/\ \/ \ \ \L\ \ \ \ , / \ \ \ \ \ ,__/ \ \ \\ \ __ \_\ \__ __\ \ \/ __ \ \_\ \_\/\_\/\_____\/\_\\ \_\/\_\ \/_/\/ /\/_/\/_____/\/_/ \/_/\/_/
