Re: [gentoo-dev] Fwd: Retiring...
Carlos Silva wrote: I'm really sorry to leave you guys but my current life isn't compatible with working on Gentoo. Live is too busy to give Gentoo the time it deserves. I really liked to work with all of you. I'll try to contribute as much as possible via bugzzie. If anyone need any kind of help/information from me, just contact me to this email... Thanks for your help with everything, please pop in from time to time Daniel -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] dedicated USE-flag is inconsequent and confusing
Hi! Jan Kundrát said this topic belongs to the mailinglist. You can find the related bug-report here: http://bugs.gentoo.org/show_bug.cgi?id=221967 Content: From the name of the USE-flag, you could expect different things: 1. It stands for 'dedicated server', which would mean, that this USE-flag does enable support for a dedicated server. (That means also that you would expect, that you have in both cases the whole GUI; and with enabled USE-flag you get additionally the dedicated server.) 2. It stands for 'dedicated only', which means, all the GUI part is skipped. (That means you would expect, that you have in both cases the whole GUI and the dedicated server; and with enabled USE-flag you get only the dedicated server but not the GUI.) From the description, it seems, that there is even a third case where you have either only the GUI or only the dedicated server (something you would not except at all). After all my experiences with USE-flag, I would expect, that a USE-flag which does not contain the name no or only does only add a specific feauture but does not remove anything. Therefore I expected the first case when I saw this USE-flag for the first time and a lot of ebuilds also use it like this. Though the second case seems still also valid for me. The third case doesn't make sense at all for me. (Is there really any ebuild with this behaviour? If so, this should be fixed.) Anyway, the behaviour of the USE-flag should be consequent. The whole sense of USE-flags is to define the behaviour of ebuilds. And normally you define the USE-flags globally for your system. If there are USE-flags which behave different on each ebuild, they don't make sense. For example, on my desktop system, I want to have the first behaviour for all ebuilds (I want to have both the game itself and the dedicated server). I have enabled the dedicated USE-flag globaly and it works good for most games I use. Though, I always need to make some exceptions for some games which is annoying and should not be. On my server, I want to have the possibility to get only the dedicated server but not the GUI. For some own ebuilds, I introduced the USE-flag 'dedicated-only' for this. To fix the problem, there should be two different USE-flags. One should do the first behaviour (something like 'dedicated' or 'dedicated-server' or 'server') and another for the second (something like 'dedicated' or 'nogui' or 'dedicated-only' or 'server-only'). The important thing is to not have a USE-flag with different behaviours. So, what do you think? Greetings, Albert -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: LaTeX documentation
Hi, Andrey Grozin [EMAIL PROTECTED]: By the way, while investigating this question, I found quite a few packages which still depend on virtual/tetex, while, probably, virtual/latex-base would be better (in some of them, the USE flag tetex then should become latex). Some suspects are: Not necessarily USE=latex, see bug 196745. virtual/tetex should phase out, I try to work on it here and there, but I appreciate some help, of course. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: Bug wrangling
Diego 'Flameeyes' Pettenò wrote: Donnie Berkholz [EMAIL PROTECTED] writes: Would it be possible to add the tree categories as products and the packages as components thereof? It makes moving a bug from one package to another quite a complex task though, as it requires two confirmation screens... and trust me that happens often enough. Shouldn't that just be scripted via pybugz? A GUI for that would be nice; perhaps as a pida[1] module. Frankly it appals me that y'all have so much time to write bash scriptlets and none to develop tools for your own use. Plus that would work fine if we had a bugzilla for ebuilds only, but would you really mix categories together with Infra, Portage, Gentoo Hosted Projects, ... ? Who cares? It's more organisation than you have now, and as I understand Duncan's suggestion it's first about adding a category above pkgs within Ebuilds foo (though I think he mixed up interface and tables a bit, sorry Duncan ;) Tree is the most fundamental work, besides portage. I guess a tag cloud would be nice tho. No reason you can't build associated metadata webapps on another host (cf beandog's portage postgres db[2].) [1] http://pida.co.uk/ [2] http://packages.larrythecow.org/ there's a FF plugin at: http://mycroft.mozdev.org/download.html?name=larrythecow -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [RFC] global useflags
server -- never did get a rational explanation of what it breaks. and now USE defaults work there's simply no excuse imo. I note openldap in 2008.0 profile uses minimal which has *always* been acknowledged as the wrong way to build a client installation, despite its long-standing use in mysql. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Bug wrangling
Steve Long [EMAIL PROTECTED] writes: It makes moving a bug from one package to another quite a complex task though, as it requires two confirmation screens... and trust me that happens often enough. Shouldn't that just be scripted via pybugz? A GUI for that would be nice; perhaps as a pida[1] module. Frankly it appals me that y'all have so much time to write bash scriptlets and none to develop tools for your own use. I like Bugzilla for the very reason I can look, comment and in general manage bugs with decency without needing client software beside a webbrowser, and I'm rarely without a webbrowser, heck, I had one at hand even while I was hospitalised (not in the ICU though, that was boring). Anything that requires me an extra software is something that I'm more likely _not_ going to use. Plus that would work fine if we had a bugzilla for ebuilds only, but would you really mix categories together with Infra, Portage, Gentoo Hosted Projects, ... ? Who cares? Uh, I do, as I tend to report a lot of bugs and I don't want to have to use the find command of my browser to see where the heck should I report it. Don't even get me started on template bugs that I use to mass-report problems. And probably most users would find the huge and long product list to choose from most likely confusing. Users can't get it right already with the short list we have, reporting bugs on Bugzilla product which have nothing to do with Bugzilla... -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpLxXSM4xO5z.pgp Description: PGP signature
[gentoo-dev] Re: Bug wrangling
Diego 'Flameeyes' Pettenò wrote: Steve Long [EMAIL PROTECTED] writes: It makes moving a bug from one package to another quite a complex task though, as it requires two confirmation screens... and trust me that happens often enough. Shouldn't that just be scripted via pybugz? A GUI for that would be nice; perhaps as a pida[1] module. Frankly it appals me that y'all have so much time to write bash scriptlets and none to develop tools for your own use. I like Bugzilla for the very reason I can look, comment and in general manage bugs with decency without needing client software beside a webbrowser, and I'm rarely without a webbrowser, heck, I had one at hand even while I was hospitalised (not in the ICU though, that was boring). Anything that requires me an extra software is something that I'm more likely _not_ going to use. OK so you'd like a webapp version as well. [EMAIL PROTECTED]: Users regularly offer help in this kind of area, simply because they use the same interfaces as the devs, only for it to fall at the second or third dev they interact with, if they're lucky. ] Plus that would work fine if we had a bugzilla for ebuilds only, but would you really mix categories together with Infra, Portage, Gentoo Hosted Projects, ... ? Who cares? Uh, I do, as I tend to report a lot of bugs and I don't want to have to use the find command of my browser to see where the heck should I report it. Don't even get me started on template bugs that I use to mass-report problems. And probably most users would find the huge and long product list to choose from most likely confusing. Users can't get it right already with the short list we have, reporting bugs on Bugzilla product which have nothing to do with Bugzilla... Yeah but the point of hierarchy is so that you do one step at a time (if you want) via category - package or just file the way you're used to. We're still only talking about a small part, in data structural terms, of bugzilla's schema, however much storage is allocated to the base level bugs. Keeping existing workflow would seem to be a requirement. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] show binhosts as repository
On 14-05-2008 00:45:10 +0200, Marius Mauch wrote: On Mon, 12 May 2008 20:53:35 +0200 Fabian Groffen [EMAIL PROTECTED] wrote: The following patch shows the url to the binhost in an emerge -av as repository name, instead of unknown. Unfortunately the patch doesn't store the binhost url, such that portage can't show where the package comes from when unmerged. Not sure if this is the right thing to do, or if the reponame in those cases should be the one from the source repo that was used to generate those binary packages. Not saying that the binhost name here is useless, quite the opposite, just a bit concerned about mixing different things here. The idea behind it is that the repo_name of the binhost is not necessarily useful. In many cases it will contain the default repo_name value, since people just create binpkgs with a standard Portage install. I agree it is a hack. Perhaps a combination of the repo_name and its url would be the best. -- Fabian Groffen Gentoo on a different level -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] Repoman subversion support
2008-05-14 00:32 Marius Mauch [EMAIL PROTECTED] napisał(a): Merged in r10325 with some minor changes (removed the 'svn update' bit until someone remembers why exactly it's there During committing, only files, which are being committed, are being updated, so `svn up` is certainly a good idea. Please add it.
