Re: [gentoo-dev] Monthly Gentoo Council Reminder for May
On Wed, 2 May 2007 22:00:05 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > What, people deliberately breaking policy that directly leads to > breaking stable and not having any working ebuilds for a package in > the tree, and then refusing to do anything about it is nothing? > > > the issue has been taken care of > > You have a conflict of interest in this one. What do other Council > members who aren't games team members think? > > > [to the detriment of users] > > How is not having broken packages committed straight to stable > detrimental to users? I maintain and play a game called Eternal Lands. I'm a Council member, but not part of the games team/herd. One of the problems games have with stable/unstable/testing/whatever keywords is that upstream changes things that in any other application just would not change. For example, the network protocol when talking to servers. EL is very version specific and when a new client is launched, around once every 6 months they change over right away. That means our users need the game right away. I used to commit EL straight to stable for this very reason, but now after a few Gentoo QA people bitched EL will never ever have a stable keyword. So instead I periodically have to let our users know how to unmask EL just so they can play their game. So no, in many cases NOT committing straight to stable CAN be detrimental to our users if all they want is a games machine. You could argue that they shouldn't be using Gentoo, but I would argue why should we discriminate? Thanks Roy DISCLAIMER: I've not read the bug mentioned as I've lost the email with it's number so I may just be talking out of my ass. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for May
On Thursday 03 May 2007, Roy Marples wrote: > DISCLAIMER: I've not read the bug mentioned as I've lost the email > with it's number so I may just be talking out of my ass. there's nothing of value in said bug so having not read it is OK -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Removing retired developers from project pages
Jan Kundrát wrote: > Petteri Räty wrote: >> -2006-05-02 >> +$DATE: $ > > Please revert all date changes you've made for following reasons: > > a) "$DATE: $" isn't expanded by CVS > b) Even if it was expanded, I won't be expanded to the -mm-dd format > c) Even if it was in -mm-dd format, it won't be fully usable by our > XSLT stylesheets as we can't handle "$Date 2007-05-02$", only "2007-05-02" Not exactly true. Look at http://www.gentoo.org/proj/en/portage/ where $Date: 2007/05/02 08:04:44 $ becomes "Updated May 2, 2007" Only handbooks would be affected, and only if there were mixed formats because dates of handbooks are sorted first and the latest is formatted later. That would be easy to change, but I don't think there's any demand for that. > d) We don't bump date automatically because some changes (typo fixes > etc) aren't important enough to warrant that. Indeed, that's why we do not use $Date$ inside the tag. For instance, if you fix a typo in a 2 year old file, you do not want to change the date because 1) the content did not change 2) you did not check whether the document is still valid today. If that's not a problem for you, there's no problem with using $Date$, just do not use $DATE$ :) Cheers, -- / Xavier Neys \_ Gentoo Documentation Project / /\ http://www.gentoo.org/doc/en/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for May
Roy Marples wrote: I maintain and play a game called Eternal Lands. I'm a Council member, but not part of the games team/herd. One of the problems games have with stable/unstable/testing/whatever keywords is that upstream changes things that in any other application just would not change. For example, the network protocol when talking to servers. EL is very version specific and when a new client is launched, around once every 6 months they change over right away. That means our users need the game right away. Thanks for the example, trust me if I tell you that we can understand the situation pretty well. I used to commit EL straight to stable for this very reason, but now after a few Gentoo QA people bitched EL will never ever have a stable keyword. I'm nearly sure that you always (at least) compile and run the new version in your box before you sent it to stable, didn't you? So, at least, you are able to say that it works in your case. So instead I periodically have to let our users know how to unmask EL just so they can play their game. There are always ways to educate users about how to use portage properly. So no, in many cases NOT committing straight to stable CAN be detrimental to our users if all they want is a games machine. You could argue that they shouldn't be using Gentoo, but I would argue why should we discriminate? Ehm, IMHO call it discriminate is a big hard. Are the gnome-2.18 or beryl users discriminated or they should be using something different to Gentoo? They only thing people have to do is use some ~arch branch packages, which isn't too difficult (in Gentoo). This is how I see it: Problem with keywording straight to stable is that arch teams are very zealous about our stable branch. We put a lot of time trying things to not fail in stable, and if an app is broken, we prefer to not force the users to compile and install another broken (or unknown to be broken) version and work to fix the current stable (patches or bumping) together with the maintainer. But if you send things, that you can't try, to stable, the qa baby jesus will cry if it fails, because nobody has taken care of even compile it in the arch :) Games are not part of core system, so IMHO, use the ~arch branch to have the latest cool version to enjoy, could be a good way to go for those el1te gam3rs. Thanks. -- Jose Luis Rivero <[EMAIL PROTECTED]> Gentoo/Doc Gentoo/Alpha -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] openssh sftplogging patch
On Tue, 14 Nov 2006 03:26:23 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Tuesday 14 November 2006 01:40, Rumi Szabolcs wrote: > > So here is a big PLEASE to keep/put back the sftplogging patch and > > the use flag in the openssh ebuild! > > no, get it upgraded upstream > -mike As I pointed out previously, the sftp logging functionality which has been integrated into the mainline openssh package is NOT the same as that of the sftplogging patch. In fact it is missing very important things! Michael Martinez has created a new patch against the recent openssh packages which adds the part of the sftplogging functionality that is still missing from upstream. All this is very important if you are going to run a file repository that is made available by sftp. Please take a look and please add it to the openssh ebuild: http://sftpfilecontrol.sourceforge.net/ Thank you! Best regards, Sab -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for May
On Thu, 03 May 2007 12:15:45 +0200 "José Luis Rivero (yoswink)" <[EMAIL PROTECTED]> wrote: > Ehm, IMHO call it discriminate is a big hard. Are the gnome-2.18 or > beryl users discriminated or they should be using something different > to Gentoo? They only thing people have to do is use some ~arch branch > packages, which isn't too difficult (in Gentoo). No no no. In my example we can only use one version of the game with the upstream servers. There is only 1 upstream server, we have to use it. So if it supports 6 archs and some of the arch teams take a few months to mark it stable then the chances are it will be out of date anyway and the "slacker arches" will never have a stable keyword. So remove the onus on slacker arches making games stable I just don't bother with the stable keyword for network games ever. Gnome-2.18 on the other hand is a desktop product with zero upstream interaction except with programs that have clearly defined protocols and are normally backwards compatible. Like say HTTP > > This is how I see it: > > Problem with keywording straight to stable is that arch teams are > very zealous about our stable branch. We put a lot of time trying > things to not fail in stable, and if an app is broken, we prefer to > not force the users to compile and install another broken (or unknown > to be broken) version and work to fix the current stable (patches or > bumping) together with the maintainer. Right, but if stable client version != stable usptream server version it cannot be used anyway, making the stable keyword here a bit of a joke. > But if you send things, that you can't try, to stable, the qa baby > jesus will cry if it fails, because nobody has taken care of even > compile it in the arch :) Well, that's up to the arch teams I guess. Lots of things fail randomly on g/fbsd because of a patch added to fix a linux bug. Maybe when we g/fbsd gets a stable branch then we'll come down on the linux developers like a ton of bricks :) Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for May
On Thu, 2007-05-03 at 08:11 +0100, Roy Marples wrote: > On Wed, 2 May 2007 22:00:05 +0100 > Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > What, people deliberately breaking policy that directly leads to > > breaking stable and not having any working ebuilds for a package in > > the tree, and then refusing to do anything about it is nothing? > > > > > the issue has been taken care of > > > > You have a conflict of interest in this one. What do other Council > > members who aren't games team members think? > > > > > [to the detriment of users] > > > > How is not having broken packages committed straight to stable > > detrimental to users? > > I maintain and play a game called Eternal Lands. I'm a Council member, > but not part of the games team/herd. > > One of the problems games have with stable/unstable/testing/whatever > keywords is that upstream changes things that in any other application > just would not change. For example, the network protocol when talking > to servers. EL is very version specific and when a new client is > launched, around once every 6 months they change over right away. That > means our users need the game right away. ok, agreed, this is a valid point. so i would suggest, that maintainers of games where this argument applies, come to special agreements with the arch teams - or just file bugreports like this: " although games-foo/lord-of-bar-2.4.6 has just been bumped, i would like to have it stable real soon, as upstream has changed the network protocol. i have x86 and amd64 hardware available, and can confirm, that the game works nice there; so, if no one objects, i'm gonna mark lord-of-bar-2.4.6 stable on x86 and amd64 in two days. i would also like to have a shiny sparc keyword, but have no hardware to test. so it would be highly appreciated if someone from the sparc team can give the game a try. " but committing straight to stable on arches where the package wasn't even tested is an absolute no-do for me. > DISCLAIMER: I've not read the bug mentioned as I've lost the email > with it's number so I may just be talking out of my ass. no, in fact you are the first one that comes up with a valid argument, why games sometimes should go to stable almost immediately. sad, but true... -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for May
Roy Marples escribió: On Thu, 03 May 2007 12:15:45 +0200 "José Luis Rivero (yoswink)" <[EMAIL PROTECTED]> wrote: Ehm, IMHO call it discriminate is a big hard. Are the gnome-2.18 or beryl users discriminated or they should be using something different to Gentoo? They only thing people have to do is use some ~arch branch packages, which isn't too difficult (in Gentoo). No no no. In my example we can only use one version of the game with the upstream servers. There is only 1 upstream server, we have to use it. Excuse me, Roy. I didn't get the point. Only one upstream server seems to make things much stricter and sounds quite reasonable to me the both ways you have used to handle it. IMHO, this is a good case where I'm sure arch teams could be happy to make an exception to the general rule. BTW, I think this is completely different to the situation being discussed. Thanks. -- Jose Luis Rivero <[EMAIL PROTECTED]> Gentoo/Doc Gentoo/Alpha -- [EMAIL PROTECTED] mailing list
[gentoo-dev] KDE 4 alpha 1 packages for Gentoo?
Dear people, In a few days KDE 4 alpha 1 will be released, and we would like to give as many people as possible the opportunity to have a look at the next generation linux desktop. Thus an article is being prepared to explain to people how they can obtain KDE 4 Alpha 1 packages. A Suse-based livecd exists, and packages will be available for Suse, Ubuntu, Debian, Fedora and OS X, but we haven't heard from the Gentoo community yet. So, as to ensure the article will be reasonable complete, we'd like to inquire if Gentoo will have Alpha 1 packages available to it's users. We thank you for any comments on this matter. Greetings, Jos Poortvliet (KDE-nl)
Re: [gentoo-dev] KDE 4 alpha 1 packages for Gentoo?
On Thursday 03 May 2007 9:12:35 am Jos Poortvliet wrote: > Dear people, > > In a few days KDE 4 alpha 1 will be released, and we would like to give as > many people as possible the opportunity to have a look at the next > generation linux desktop. Thus an article is being prepared to explain to > people how they can obtain KDE 4 Alpha 1 packages. A Suse-based livecd > exists, and packages will be available for Suse, Ubuntu, Debian, Fedora and > OS X, but we haven't heard from the Gentoo community yet. So, as to ensure > the article will be reasonable complete, we'd like to inquire if Gentoo > will have Alpha 1 packages available to it's users. > AFAIK, kde4 alpha one packages will be availible in the same overlay as the kde4 tech preview packages and the kde4 live svn packages, that is--the kde4 overlay. > We thank you for any comments on this matter. > > Greetings, > > > Jos Poortvliet > > (KDE-nl) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for May
On Thu, 2007-05-03 at 13:11 +0200, Matthias Langer wrote: > > ok, agreed, this is a valid point. so i would suggest, that maintainers > of games where this argument applies, come to special agreements with > the arch teams - or just file bugreports like this: > > " > although games-foo/lord-of-bar-2.4.6 has just been bumped, i would like > to have it stable real soon, as upstream has changed the network > protocol. i have x86 and amd64 hardware available, and can confirm, that > the game works nice there; so, if no one objects, i'm gonna mark > lord-of-bar-2.4.6 stable on x86 and amd64 in two days. i would also like > to have a shiny sparc keyword, but have no hardware to test. so it would > be highly appreciated if someone from the sparc team can give the game a > try. > " > I can't speak for all of sparc, of course, but generally we try to accommodate requests when the package developers explain the situation. In a case like Eternal Lands, it might turn out that the best solution would be always to keep it as ~sparc, but that would have the same effect in practice as a stable keyword, because anyone playing the game on sparc would know what was going on (I would think). The key here is the bug report, and at that point the friendly sparc developers would work with you. :) > but committing straight to stable on arches where the package wasn't > even tested is an absolute no-do for me. > > > DISCLAIMER: I've not read the bug mentioned as I've lost the email > > with it's number so I may just be talking out of my ass. > > no, in fact you are the first one that comes up with a valid argument, > why games sometimes should go to stable almost immediately. sad, but > true... > Regards, -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Looking for help with 2.6 kernel maintenance
Hi, I would like to help, I'm a normal user but I think the kernel It is a very interesting way to begin to know linux more thoroughly. -- Sergio D. Rodríguez Inclan -- http://zero.arcamo.org | [EMAIL PROTECTED] Linux User #446728 --> http://counter.li.org/ Fingerprint: 0C48 829A 40D0 27E7 3B2D D7C3 17A0 A0AF 3291 CFEE -- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rite app-misc/baobab
+# Daniel Gryniewicz <[EMAIL PROTECTED]> (3 May 2007) +# It's now part of gnome-utils; bug #176864 +app-misc/baobab Scheduled for removal June 2 2007 Daniel -- [EMAIL PROTECTED] mailing list
[gentoo-dev] sqlite maintainership
Apparently, sqlite needs a maintainer (see bug 176942). If no one objects, I'll take care of it... anything I should know before hand? Thanks guys Steve -- [EMAIL PROTECTED] mailing list
