Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 01:19:45 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: On 28-Mar-07, at 1:45 AM, Ciaran McCreesh wrote: Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? I certainly don't think so. A lot of people *switch* to Gentoo because of portage. Portage is a core part of our distro, and I don't see it being replaced for a long time to come. Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Firefox 1.5 series will get removed in 30 days
On Sun, Mar 18, 2007 at 05:03:37PM +0100, Raúl Porcel wrote: Hi, The mozilla team has decided that the www-client/mozilla-firefox[-bin]-1.5* series will get masked two weeks from now (18 Mar 2007), that is 1 April 2007. And will be removed after two weeks from that date, which will be 15 April 2007. Mozilla will drop support for that series from 24 April 2007 onwards. All arches have 2.0 series stable, so if you're using 1.5 you should migrate to 2.0. @GWN: Please include this in the next GWN. P.S: No, this is not an April fools joke :) Thanks. Did upstream stop releasing security updates for for 1.5? Because if they still support them, it would be nice to keep that supported for a little longer. 2.x just uses more memory here (I don't mean the page cache etc) and doesn't really offer any benefit to me. I use 1.5 with large page caches (fastback and similar stuff) and it still doesn't waste memory like the 2.x releases do. I don't really think i'm the only one: https://bugs.gentoo.org/show_bug.cgi?id=172621 I think that bug got interpreted the wrong way. No one expexted Gentoo to fix the issue. It was a simple request to not drop 1.5 yet because there are issues with 2.x Of course all this is only considerable if upstream still fixes security issues for 1.5, otherwise i agree that it's too much work to support it. Christian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Firefox 1.5 series will get removed in 30 days
Christian Birchinger kirjoitti: On Sun, Mar 18, 2007 at 05:03:37PM +0100, Raúl Porcel wrote: Hi, The mozilla team has decided that the www-client/mozilla-firefox[-bin]-1.5* series will get masked two weeks from now (18 Mar 2007), that is 1 April 2007. And will be removed after two weeks from that date, which will be 15 April 2007. Mozilla will drop support for that series from 24 April 2007 onwards. All arches have 2.0 series stable, so if you're using 1.5 you should migrate to 2.0. @GWN: Please include this in the next GWN. P.S: No, this is not an April fools joke :) Thanks. Of course all this is only considerable if upstream still fixes security issues for 1.5, otherwise i agree that it's too much work to support it. Christian If you read what you are quoting: Mozilla will drop support for that series from 24 April 2007 onwards. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Firefox 1.5 series will get removed in 30 days
On Thu, Mar 29, 2007 at 12:23:49PM +0300, Petteri Räty wrote: If you read what you are quoting: Mozilla will drop support for that series from 24 April 2007 onwards. That's still almost a month + the time no security issues appear. This would be still better. Christian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ANN: PMS public release
On Sun, 25 Mar 2007 02:33:50 +0100 Stephen Bennett [EMAIL PROTECTED] wrote: The first public draft of PMS is open for comment. The PDF is at http://dev.gentoo.org/~spb/pms.pdf Open issues that need to be addressed before submission to the Council are at [1]. Comments are welcomed, so long as people bear in mind: * PMS isn't the place to push through changes, and it's not an excuse for special interest groups to try to sneak in policy. PMS should only contradict Portage behaviour where Portage is doing something silly. PMS has to consider how things *are*, rather than how things should be. If you're looking to get something changed, wait until the EAPI-1 discussions that will no doubt take place at some point. * PMS doesn't specify coding style issues (this extends to things that aren't strictly speaking coding style, such as package names should be all lowercase where possible). Things like indenting are relevant to the devmanual, but have no effect upon a package manager. * One issue per bug, one bug per issue, and for the sanity of those of us who have to keep track of issues, try to keep feedback on bugzilla. For the curious, Paludis non-compliance is being tracked at [2]. So far as I'm aware, there's no central list for Portage or Pkgcore non-compliance. [1] http://tinyurl.com/2z58xn [2] http://paludis.pioto.org/trac/query?milestone=PMS+Compliance -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Firefox 1.5 series will get removed in 30 days
On Thu, 2007-03-29 at 11:50 +0200, Christian Birchinger wrote: On Thu, Mar 29, 2007 at 12:23:49PM +0300, Petteri Räty wrote: If you read what you are quoting: Mozilla will drop support for that series from 24 April 2007 onwards. That's still almost a month + the time no security issues appear. This would be still better. How is prolonging the inevitable better exactly? I understand some people's reluctance, but the Mozilla team *knows* they'll have to remove the 1.5 series sometime on or after April 24th, anyway. Why should they bother keeping it in the tree? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Firefox 1.5 series will get removed in 30 days
Chris Gianelloni wrote: On Thu, 2007-03-29 at 11:50 +0200, Christian Birchinger wrote: On Thu, Mar 29, 2007 at 12:23:49PM +0300, Petteri Räty wrote: If you read what you are quoting: Mozilla will drop support for that series from 24 April 2007 onwards. That's still almost a month + the time no security issues appear. This would be still better. How is prolonging the inevitable better exactly? I understand some people's reluctance, but the Mozilla team *knows* they'll have to remove the 1.5 series sometime on or after April 24th, anyway. Why should they bother keeping it in the tree? Because Portage sucks and it is oh so hard to add it into an overlay... /me runs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: New ALSA maintainers
Am Donnerstag, 29. März 2007 03:50 schrieb Steve Long: Daniel Drake wrote: I have suggested that herd support for the kernelspace side (alsa-driver) be slowly reduced, by redirecting users who file bugs against it to reproduce with the in-kernel drivers, and then let kernel handle the bug resolution. This will remove duplicated maintenance efforts. This is perfectly reasonable where it is a card with drivers in both, but alas-drivers supports a broader range of hardware, eg the echo audio cards (guess who has one ;) which have never been available in-kernel. Like those in sound/pci/echoaudio/ ? Which have been in there since the commit labelled: 2006-06-28 Giuliano Pochini [ALSA] Add echoaudio sound drivers I guess this is either point c) or point f) of Daniel's list. But he should probably add a bullet point g) Hasn't looked yet. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] get pci info in Linux?
Hi, experts! Who knows how can I get information about pci-device (for example, vendor and name of network card) without using /proc and /sys systems? Thanks for your time! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] get pci info in Linux?
Have you tried lspci from the pciutils package? -- Rob Lesslie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] get pci info in Linux?
Bilanchuk Vitaly kirjoitti: Hi, experts! Who knows how can I get information about pci-device (for example, vendor and name of network card) without using /proc and /sys systems? Thanks for your time! emerge pciutils and use lspci. This question would be better asked in our user oriented support channels like #gentoo or gentoo-user mailing list. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] get pci info in Linux?
On Thu, Mar 29, 2007 at 06:02:34PM +0300, Bilanchuk Vitaly wrote: Who knows how can I get information about pci-device (for example, vendor and name of network card) without using /proc and /sys systems? Seems you are looking for lspci from the package sys-apps/pciutils. Btw, as this doesn't seem to be a Gentoo development related question, please ask on the gentoo-user list, the forums or in #gentoo on IRC next time, but not here. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpycw3VGJqhn.pgp Description: PGP signature
[gentoo-dev] Last rites dev-java/javatar
+# Petteri Räty [EMAIL PROTECTED] (29 Mar 2007) +# -Last upstream release in 2003 +# -Not migrated to use from source sun-jaf +# -Does not support bzip2. +# Use app-arch/tar instead or if you need a java library use +# dev-java/commons-vfs. If you still use this for something, please mail +# [EMAIL PROTECTED] and we know that this is actively used and will give +# it the care it needs. Otherwise you can find it in our junkyard after 30 days. +dev-java/javatar signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: New ALSA maintainers
Steve Long wrote: This is perfectly reasonable where it is a card with drivers in both, but alas-drivers supports a broader range of hardware, eg the echo audio cards (guess who has one ;) which have never been available in-kernel. These were added to the kernel as of 2.6.18. But it is still an interesting point: how does bug handling work when the drivers are actually not in the kernel at all? I think the alsa herd would be expected to handle bugs here, although I'd readily help them out as I do for other external driver maintainers. I guess I'd like some assurance that as long as alsa-drivers supports hardware for which there are no kernel drivers, it will at least be available in the portage tree. Yes, I think we can promise that, provided that the drivers have some level of support upstream too. I did a quick check and it appears that right now, there are no drivers provided by alsa-driver which are not in the kernel source. It might be worth stripping duplicate drivers out of alsa-drivers altogether so that the two might even co-exist? Would eliminate the bug duplication in any event. This is something that can be considered later, although I have my doubts... Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] get pci info in Linux?
emerge pciutils and use lspci. This question would be better asked in our user oriented support channels like #gentoo or gentoo-user mailing list. I'm sorry. I need get info using C/C++. I know lspci using 4 methods in Linux - linux_sysfs, linux_proc, intel_conf1, intel_conf2 (man 8 lspci). But: linux_sysfs - using /sys system; linux_proc - using /porc system; intel_conf1, intel_conf2 - i don't know how it work; Who now how get this information using C/C++ without using lspci? Or, how works intel_conf1 and intel_conf2 methods that using by lspci? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On 29-Mar-07, at 2:26 PM, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 01:19:45 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: I certainly don't think so. A lot of people *switch* to Gentoo because of portage. Portage is a core part of our distro, and I don't see it being replaced for a long time to come. Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... Both portage and the tree. I don't deny the fact that portage isn't the best way of using the tree but it's a lot better than many of the package managers (think other distros) out there. In fact, I've hardly felt as if portage was limiting me in any way for the past 2 years or so. It just works, and that's a good thing (TM). Alternative package managers are also good for Gentoo as a whole, but I don't think replacing portage should be our top priority. We officially support portage, and will do so for quite some time to come. Cheers, -- Anant -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] get pci info in Linux?
On Thu, Mar 29, 2007 at 07:04:33PM +0300, Bilanchuk Vitaly wrote: emerge pciutils and use lspci. This question would be better asked in our user oriented support channels like #gentoo or gentoo-user mailing list. I'm sorry. I need get info using C/C++. Use the library provided by the lspci package, that is what it is there for. I know lspci using 4 methods in Linux - linux_sysfs, linux_proc, intel_conf1, intel_conf2 (man 8 lspci). But: linux_sysfs - using /sys system; linux_proc - using /porc system; What's wrong with using these interfaces? You can use sysfs and proc from a C/C++ program just fine... thanks, greg k-h -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] get pci info in Linux?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bilanchuk Vitaly napisał(a): emerge pciutils and use lspci. This question would be better asked in our user oriented support channels like #gentoo or gentoo-user mailing list. I'm sorry. I need get info using C/C++. I know lspci using 4 methods in Linux - linux_sysfs, linux_proc, intel_conf1, intel_conf2 (man 8 lspci). But: linux_sysfs - using /sys system; linux_proc - using /porc system; intel_conf1, intel_conf2 - i don't know how it work; Who now how get this information using C/C++ without using lspci? Or, how works intel_conf1 and intel_conf2 methods that using by lspci? I think You should ask on some C/C++ help channel or mailing list. - -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 46E89CD0 | `-' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGC/gm8nXYuEbonNARAsw9AKCh8kXcFjTehu0z6YJIYdNcoAHvUgCfTnSh G9Ees8zSLQ6AoXHAE5FE5lI= =Iuzr -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 22:46:14 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: On 29-Mar-07, at 2:26 PM, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 01:19:45 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: I certainly don't think so. A lot of people *switch* to Gentoo because of portage. Portage is a core part of our distro, and I don't see it being replaced for a long time to come. Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... Both portage and the tree. I don't deny the fact that portage isn't the best way of using the tree but it's a lot better than many of the package managers (think other distros) out there. Better than many other package managers isn't exactly a glowing commendation. When you consider the disadvantages associated with a source-based distribution, Gentoo has to do a lot better than that in order to be worthwhile -- and it only takes one package manager to be better to make Gentoo not worth using. The goal should be substantially better than any other package manager... In fact, I've hardly felt as if portage was limiting me in any way for the past 2 years or so. It just works, and that's a good thing (TM). Have a look at [1] and all the open Portage should... bugs. Would any of those improve the user experience for you? Can you think of other features of a similar nature that would make your life easier? That Portage works does not mean that it is anywhere near ideal... A few years ago Gentoo had some serious advantages over the competition. These days, Gentoo is at serious risk of being Red Queened by Ubuntu and Fedora. Providing the same thing that was provided two years ago isn't enough. If Portage can't deliver functionality that makes Gentoo competitive with where Ubuntu will be a year from now, Portage has to be replaced. [1]: http://ciaranm.org/show_post/95 -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] get pci info in Linux?
Use the library provided by the lspci package, that is what it is there for. Ok, thanks for you time. What's wrong with using these interfaces? You can use sysfs and proc from a C/C++ program just fine... sysfs and proc can be unexisting. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] get pci info in Linux?
On Thu, 2007-03-29 at 19:55 +0300, Bilanchuk Vitaly wrote: Use the library provided by the lspci package, that is what it is there for. Ok, thanks for you time. What's wrong with using these interfaces? You can use sysfs and proc from a C/C++ program just fine... sysfs and proc can be unexisting. Chances are you will need to directly communicate with the kernel via a module if proc and sys are not mounted. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: get pci info in Linux?
· Wernfried Haas [EMAIL PROTECTED]: On Thu, Mar 29, 2007 at 06:02:34PM +0300, Bilanchuk Vitaly wrote: Who knows how can I get information about pci-device (for example, vendor and name of network card) without using /proc and /sys systems? Seems you are looking for lspci from the package sys-apps/pciutils. Does lspci work without /sys and /proc? Alexander Skwar -- Everyone wants results, but no one is willing to do what it takes to get them. -- Dirty Harry -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 09:56 +0100, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 01:19:45 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: On 28-Mar-07, at 1:45 AM, Ciaran McCreesh wrote: Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? I certainly don't think so. A lot of people *switch* to Gentoo because of portage. Portage is a core part of our distro, and I don't see it being replaced for a long time to come. Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... Can you please stop taking cheap pot shots every chance you get. We all get it. You are not a fan of portage. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 11:57:36 -0700 Ned Ludd [EMAIL PROTECTED] wrote: Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... Can you please stop taking cheap pot shots every chance you get. We all get it. You are not a fan of portage. And that attitude is exactly why Gentoo is no better off than it was two years ago. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 20:06 +0100, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 11:57:36 -0700 Ned Ludd [EMAIL PROTECTED] wrote: Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... Can you please stop taking cheap pot shots every chance you get. We all get it. You are not a fan of portage. And that attitude is exactly why Gentoo is no better off than it was two years ago. You are being dismissive of the hard work others are doing. I find that downright offensive. You want to write a kickass package manager then by all means do it. But trying to make yourself look good by making others look bad is an underhanded trick. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 12:25:00 -0700 Ned Ludd [EMAIL PROTECTED] wrote: You are being dismissive of the hard work others are doing. I find that downright offensive. You want to write a kickass package manager then by all means do it. But trying to make yourself look good by making others look bad is an underhanded trick. This has nothing to do with the people. It's about the code. Not being able to make changes to a huge mess of spaghetti code doesn't imply any lack of talent in those who try... Please stop looking for excuses for interpreting something as offensive... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 21:02 +0100, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 12:25:00 -0700 Ned Ludd [EMAIL PROTECTED] wrote: You are being dismissive of the hard work others are doing. I find that downright offensive. You want to write a kickass package manager then by all means do it. But trying to make yourself look good by making others look bad is an underhanded trick. This has nothing to do with the people. It's about the code. Not being able to make changes to a huge mess of spaghetti code doesn't imply any lack of talent in those who try... Please stop looking for excuses for interpreting something as offensive... The correct reply should of been. I'm sorry I did not mean to offend anybody. I'll make an effort to not make any cheap shots -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Hi, Ciaran McCreesh wrote: Have a look at [1] and all the open Portage should... bugs. Would any of those improve the user experience for you? Can you think of other features of a similar nature that would make your life easier? Funny thing is: the only thing that I'd really care about are the USE deps. But to actually get those, it's not enough to use paludis, you'd have to have an ebuild tree that actually provides them. Then you'd get things like sane split up of monolith upstream packages, a way to implement multilib without binary packages, and other things I can't think of right now. Other things I want from Gentoo right now depend on factors other than the package manager, too; prebuilt packages, slow-moving tree, binary-breakage protection (and pre-upgrade notices of major changes). If you could cast a spell that got those features in, I'd happily wait 30 minutes for emerge -Duvat world... So to have an incentive to switch to paludis, it would have to be a supported Gentoo package manager, which drives what devs put into the tree. And to get there, it would have to get the masses to switch to paludis... So I think to get anywhere with all of this is to figure out ways to add the features to the tree without breaking portage (for the use flag dep example: let portage die on not matched use flag deps just like it does now in pkg_setup for the manual use flag checks; real support would of course mean reemerging the package in question with the right flags). And then, if portage really can't keep up with the pace of changes, alternatives would *have* to be considered. Am I making sense? That Portage works does not mean that it is anywhere near ideal... Nothing ever will be. :) Regards, Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 13:33:31 -0700 Ned Ludd [EMAIL PROTECTED] wrote: The correct reply should of been. I'm sorry I did not mean to offend anybody. I'll make an effort to not make any cheap shots That would have been a possible response. Another reasonable response would have been the one that he made, clarifying his original statement in case someone took offence where none was meant. If one reads the mails in a spirit of giving someone the benefit of the doubt rather than automatically thinking the worst, there's no reason this subthread needed to exist. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Ned Ludd wrote: The correct reply should of been. I'm sorry I did not mean to offend anybody. I'll make an effort to not make any cheap shots Man, stop playing the silly Ooh, we are all so fragile and offendable game. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 22:47:46 +0200 Thomas Rösner [EMAIL PROTECTED] wrote: Other things I want from Gentoo right now depend on factors other than the package manager, too; prebuilt packages A package manager that supports a better binary package format (split out local metadata would be a good start) combined with a third party binary provider could deliver that with no tree changes. Heck, it's even doable with Portage's binaries, although according to a Gentoo-based distribution that tried it, your 30 minutes would be optimistic for -uDpv world... binary-breakage protection Funnily enough... That one can be done without tree changes too via something we're calling reparenting. There're some vague suggestions of roughly how to do it at [1]. That Portage works does not mean that it is anywhere near ideal... Nothing ever will be. :) Probably not, but they could be a lot closer to it. [1]: http://paludis.pioto.org/trac/ticket/129 -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On 29-Mar-07, at 11:20 PM, Ciaran McCreesh wrote: Have a look at [1] and all the open Portage should... bugs. Would any of those improve the user experience for you? Can you think of other features of a similar nature that would make your life easier? That Portage works does not mean that it is anywhere near ideal... Sure it's not ideal and I acknowledge that. But portage is tied very closely to Gentoo for historical reasons, and it is not reasonable to expect an alternate package manager to replace it (not in the near future atleast). How about implementing the features you mention in portage? I know what your response would be though: portage is too much spaghetti code to even think about it. But guess what, if you do succeed in making a patch that adds a feature to portage, it'll be accepted faster than you think. Maybe, given the current situation, that is the best way to provide a better experience to the users you are so worried about; atleast for those users who don't want to try out package managers unsupported by Gentoo. A few years ago Gentoo had some serious advantages over the competition. These days, Gentoo is at serious risk of being Red Queened by Ubuntu and Fedora. Providing the same thing that was provided two years ago isn't enough. If Portage can't deliver functionality that makes Gentoo competitive with where Ubuntu will be a year from now, Portage has to be replaced. You are comparing Gentoo with the wrong distributions. Both Ubuntu and Fedora have people working on it 24x7, and they are being *paid* to do so. Gentoo is a community distribution which is entirely volunteer driven, and you can't expect it to match with the pace of commercial distributions such as the ones you mention. Debian is a distro you could compare with, and you'll have to accept the fact that they develop *for* the developers, much like Gentoo. So, really, I don't care if Ubuntu becomes more popular than Gentoo. Isn't it already?! Point is, the day when more than 50% of the devs feel we need a new package manager, will be the day a replacement will be made. Cheers, -- Anant -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 14:03 -0700, Ilya A. Volynets-Evenbakh wrote: Ned Ludd wrote: The correct reply should of been. I'm sorry I did not mean to offend anybody. I'll make an effort to not make any cheap shots Man, stop playing the silly Ooh, we are all so fragile and offendable game. Worry about yourself please. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Fri, 2007-03-30 at 03:07 +0530, Anant Narayanan wrote: Sure it's not ideal and I acknowledge that. But portage is tied very closely to Gentoo for historical reasons, and it is not reasonable to expect an alternate package manager to replace it (not in the near future atleast). Historical reasons aren't necessarily the correct reasons. I'd almost say that your sentence has officially heralded the age of Debianisation. How about implementing the features you mention in portage? I know what your response would be though: portage is too much spaghetti code to even think about it. Have you ever tried to add features to a frankenstein of a beast? What is the value to you in doing something like that? Isn't there more value in designing something based on what you've learned instead? We can all go all day about this and not convince each other, so please let's just drop this line of thinking. But guess what, if you do succeed in making a patch that adds a feature to portage, it'll be accepted faster than you think. Maybe, given the current situation, that is the best way to provide a better experience to the users you are so worried about; atleast for those users who don't want to try out package managers unsupported by Gentoo. What are you basing any of this on? Sounds like speculation that doesn't help anything. You are comparing Gentoo with the wrong distributions. Both Ubuntu and Fedora have people working on it 24x7, and they are being *paid* to do so. Gentoo is a community distribution which is entirely volunteer driven, and you can't expect it to match with the pace of commercial distributions such as the ones you mention. Debian is a distro you could compare with, and you'll have to accept the fact that they develop *for* the developers, much like Gentoo. Debian was never a distro that I thought we'd emulate, or should emulate. Turns out I was wrong, I suppose. So, really, I don't care if Ubuntu becomes more popular than Gentoo. Isn't it already?! Here we agree. I don't think Ciaran is arguing popularity either. He's arguing that the compelling case for using Gentoo is what's fading. There's a difference. Point is, the day when more than 50% of the devs feel we need a new package manager, will be the day a replacement will be made. I'm not entirely sure on your reasons for this statement. If developers' don't face any API changes, why should we have to have a political vote on which package manager gets dubbed the one true official one? Why should it be a popularity contest? Why can it not be a technical superiority issue? If there is a compelling set of technical reasons to replace portage, why ignore that set? Portage is more than the package manager. Its life comes from the portage _tree_. Portage is just the tool that is used to use that tree. If that tool is outdated (and let's be honest, it kind of is), then switching it is not actually a bad thing. In sum, I'm not sure I like this direction of basing technical things on political decisions. Thanks, Seemant signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: get pci info in Linux?
On Thu, Mar 29, 2007 at 08:52:29PM +0200, Alexander Skwar wrote: ?? Wernfried Haas [EMAIL PROTECTED]: On Thu, Mar 29, 2007 at 06:02:34PM +0300, Bilanchuk Vitaly wrote: Who knows how can I get information about pci-device (for example, vendor and name of network card) without using /proc and /sys systems? Seems you are looking for lspci from the package sys-apps/pciutils. Does lspci work without /sys and /proc? Try it and find out :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 29 Mar 2007 22:46:14 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: On 29-Mar-07, at 2:26 PM, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 01:19:45 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: I certainly don't think so. A lot of people *switch* to Gentoo because of portage. Portage is a core part of our distro, and I don't see it being replaced for a long time to come. Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... Both portage and the tree. I don't deny the fact that portage isn't the best way of using the tree but it's a lot better than many of the package managers (think other distros) out there. Better than many other package managers isn't exactly a glowing commendation. When you consider the disadvantages associated with a source-based distribution, Gentoo has to do a lot better than that in order to be worthwhile -- and it only takes one package manager to be better to make Gentoo not worth using. The goal should be substantially better than any other package manager... Quoting our Philosophy Page: 'The goal of Gentoo is to strive to create near-ideal tools. Tools that can accommodate the needs of many different users all with divergent goals. Don't you love it when you find a tool that does exactly what you want to do? Doesn't it feel great? Our mission is to give that sensation to as many people as possible.' I am unaware of any other goals currently present within Gentoo. I would imagine people have goals, projects have goals; but gentoo has none other that the one above. Now you can make the point that portage is not a 'near-ideal tool' and I'd agree for a large number of use cases; but at least you'd be making a point against something thats actually a goal for us instead of some made up goal like 'compete against Ubuntu/Fedora'. That said; people are working on it. You have been hearing that for years I know; most of that effort honestly became pkgcore (more or less). I'm not about to say 'just give portage more time' because that is a stupid statement to make. However I seriously doubt paludis or pkgcore is ready to take over management for our users. For being a badly designed application, portage has a large pair of shoes to fill. -Alec -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
I fail to understand why the portage developers would refuse to accept a patch that actually improves something (without causing major regressions i.e.). If they do refuse such a patch (for political reasons), then we have a serious problem. However, based on past experience with the portage developers, I doubt this would happen. Again, portage's lack of design isn't exactly conducive to accepting features. Having said that, it's taken this long to even get its behaviour documented (see PMS). Now that the spec exists, anyone can write a tool to reach the spec. I base that on the fact that all developers are more or less equally capable of making a technical decision. Maybe I am wrong. Less than 1% of gentoo developers interact directly with portage internals. So, provided the other 99% don't have to drastically switch how they interact with the development tool (and provided the users don't have to switch how they interact with the package manager), it doesn't matter much what's under the hood, does it? Surely, things like compatibility symlinks and such would go part of the ways to alleviating that sort of pain. As for being equal to the task of making the decision -- I'm certainly not. There are definitely developers who are more intimate with that area of development (even outside the portage team) whose opinions would weigh a lot heavier than mine, as an example. I wasn't indicating that a popularity contest should be held, because I trust the developers will cast their vote only after *technically* evaluating the options. I also don't think it's fair for a small minority of developers to make the switch on behalf of the rest of us, which is why I mentioned a number like 50%. An election is not always political ;) See above: not every developer is technically capable of evaluating the underpinnings of the tools we use. For most of us, those underpinnings do not matter. Agreed. But if so many of us do think that there are better package managers out there that do a magnificent job of utilizing the tree, then I fail to understand why no-one is seriously considering a switch? Well, you can take some of the QA people who actually use pkgcore and paludis based tools to do what they do. You can also take the fact that Gentoo developers are actively involving themselves in pkgcore and paludis developments. You can also consider the fact that the council has asked for the PMS in order to present the community with a clear picture of current behaviour, expected behaviour and future behaviour of the package management we have. From there, it's not a big jump to then choose an alternate as the one that most adheres to the spec and make that one official, surely? Just because there is no widespread concerted effort to switch does not mean that there is no impetus to switch or that nobody is considering it seriously. The fact is that people are, we're just all in the exploratory stage still. Ok, I'm sure a lot of us agree on the fact that portage is technically outdated and is Gentoo's own Frankenstein. Time for a replacement, but what do you think would be the repercussions of proposing something like that? If they are not catastrophic, might I initiate such a proposal? It's probably a little early to initiate such a proposal, seeing as the PMS is still undergoing review. Why don't we just let the current course of events continue, instead of trying to force any specific issue? I'm sure that if the council decides to initiate a project to seriously pursue replacing portage as the official package manager, they will take into account these repercussions of which you speak. At the very least, you can bring them up at that time. I'm probably not the most qualified to speak on this subject, but I assume Ciaran and Brian and their respective teams both have ways (or can quickly think them up) to make the transition easier, should it come up. But again, it's probably a little early in the game for that. Thanks, Seemant signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [soc] Python bindings for Paludis
snip See above: not every developer is technically capable of evaluating the underpinnings of the tools we use. For most of us, those underpinnings do not matter. I find the reasoning to be quite justified. It's probably a little early to initiate such a proposal, seeing as the PMS is still undergoing review. Why don't we just let the current course of events continue, instead of trying to force any specific issue? I'm sure that if the council decides to initiate a project to seriously pursue replacing portage as the official package manager, they will take into account these repercussions of which you speak. At the very least, you can bring them up at that time. I look forward to using a better package manager then :) Cheers, -- Anant -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seemant Kulleen wrote: I wasn't indicating that a popularity contest should be held, because I trust the developers will cast their vote only after *technically* evaluating the options. I also don't think it's fair for a small minority of developers to make the switch on behalf of the rest of us, which is why I mentioned a number like 50%. An election is not always political ;) See above: not every developer is technically capable of evaluating the underpinnings of the tools we use. For most of us, those underpinnings do not matter. True, and the underpinnings are not the only reason to switch. Should be also the user experience (speed, features) and that can be evaluated by every dev, or even users - it's what matters most for them, isn't it. Of course internal design is important for maintainability etc, but it's not all. It's probably a little early to initiate such a proposal, seeing as the PMS is still undergoing review. Why don't we just let the current course of events continue, instead of trying to force any specific issue? Yeah, I don't think it's now helpful to hear that portage sux and paludis can do $x and $y and $z, over and over again. Someone's little too early for an election campaign? - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGDKyhtbrAj05h3oQRAireAJ9c/9J0opR6X+IKKkQQHZHbqvO5wACfbjPn 97vZFLm5eFsdW23AHGW04uM= =WEo/ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [SoC] Idea for emerge
Take a look at porthole's cvs trunk branch. I am nearly finished getting things ready for the next testing release. It should work ok, still some bugs to work out, some code to finish. I have extended the dependency view for a package with a lot more info. I have also set it to follow the dependencies deeper (which already include use flags, both used and not used). A new feature also makes any dependency clickable to bring up a new window with that package's notebook detail. It also allows you to click it's dependencies for more popups, adjust use flags, keywords, etc.. The cli is great, but gui's are better at showing large groups of info like variable dependency graphs so you can get it right before you start the emerge. Great :). I'll probably test it tomorrow. P.S. If your looking for something to do, I can always use a hand :) especially on the portage/pkgcore interface side. Right now, I'm very busy, but I'll have a lot of spare time next week for 2 or 3 weeks. So, if you need some help... just ask ;) -- gentoo-portage-dev@gentoo.org mailing list
