[gentoo-dev] Re: New gnome and kde subprofiles
Theo Chatzimichos posted on Tue, 30 Mar 2010 03:35:19 +0300 as excerpted: > The change is now committed, please test and report any problems. Thanks [x-posted to desktop and devel, announce pruned] I noticed the news item when I updated my netbook image yesterday. =:^) FWIW, my workstation uses the amd64/no-multilib profile, which doesn't have a desktop subprofile, and I based the netbook's setup on that, so at least as of yesterday, while I saw the news item, it didn't seem to affect anything here (I didn't bother switching to the kde specific subprofile). I use -avNuD on all my updates, so would have seen any --newuse, had they occurred. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] New gnome and kde subprofiles
The change is now committed, please test and report any problems. Thanks -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt Teams blog.tampakrap.gr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Proxying and bugzilla
On 03/29/2010 11:47 PM, René 'Necoro' Neumann wrote: > So I am asking whether there would be a solution to allow people like me > to have full bugzilla rights on packages they are in charge for. > Just gave you editbugs privileges, further instructions will follow per mail/irc. -- Regards, Christian Ruppert Gentoo Linux Developer and Bugzilla Admin Fingerprint: 9B50 01DF E873 A0E4 126D 6C16 8B17 B68E 7FAE 7D38 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] google summer of code ideas
abhik, this is gentoo-dev. please take this to gentoo-soc, instead. thanks, sebastian
Re: [gentoo-dev] Proxying and bugzilla
On Mon, Mar 29, 2010 at 11:47:07PM +0200, René 'Necoro' Neumann wrote: > 1) Have an implicit restriction, i.e. give them full rights (where > "full" just means: everything they need for handling their bugs), but > make a policy, that they are only allowed to use this for their > packages. In other words: Enforce the correct usage by "legal" ways > instead of teachnically. We've got this available already. The bug to track permissions is here: http://bugs.gentoo.org/show_bug.cgi?id=236218 Ask the developer who is proxying for you to please file a bug to devrel, and they will update that tracking page when they grant you editbugs privileges. > 2) Enforce the restriction technically. I do not know how this could be > done in bugzilla - perhaps by having "proxy-herds", i.e. one herd for > each proxied package and only give the user the full rights, if a bug is > assigned to a herd he is a member of. I've wondered before about giving privileges based on the summary line, but I haven't given it much thought beyond that. I think that would probably be more useful than proxy herds, because 'herds' are just actually mail aliases with user accounts in Bugzilla. > Some sort of "bugzilla quiz" which needs to be taken by the maintainer > might be useful in both cases. +1 on that idea too. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[gentoo-dev] Proxying and bugzilla
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
currently I am a maintainer for two packages -- and as a non-gentoo-dev
being proxied by guys who are.
Now a disadvantage of this position are the restricted rights in
bugzilla. In case a bug is filed for one of my maintained packages I
have to ask one of my proxies for each step ("could you mark this as a
dupe?", "could you mark this as fixed?", etc.). This is quite cumbersome
and puts just some load on the devs (which should have been avoided by
the proxy-solution in the first place).
So I am asking whether there would be a solution to allow people like me
to have full bugzilla rights on packages they are in charge for.
Two possibilities come to my mind:
1) Have an implicit restriction, i.e. give them full rights (where
"full" just means: everything they need for handling their bugs), but
make a policy, that they are only allowed to use this for their
packages. In other words: Enforce the correct usage by "legal" ways
instead of teachnically.
This approach is probably easier in terms of bureaucracy but might be
seen as dangerous.
2) Enforce the restriction technically. I do not know how this could be
done in bugzilla - perhaps by having "proxy-herds", i.e. one herd for
each proxied package and only give the user the full rights, if a bug is
assigned to a herd he is a member of.
The disadvantage is here, that there is quite some overhead of managing
a bunch of "proxy-herds".
Some sort of "bugzilla quiz" which needs to be taken by the maintainer
might be useful in both cases.
I'd be glad to hear some other opinions.
- - René
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuxH9sACgkQ4UOg/zhYFuAvogCfflrqjFg6iMq6OGEfp7Z4NHXS
ERUAnAonFFHRlGRYuKVSL12Vb2WinSAr
=1DOx
-END PGP SIGNATURE-
[gentoo-dev] google summer of code ideas
Respected sir, i had seen your project ideas and i am interested to wrok on some of them like wed applications,java integration.i am an expert advanced programming designer in java with knowledge of c,c++ and web designing with html,ccc,php and java script.so how can i proceed with my application,when i can talk regarding my proposal.please reply me. thank you. your's obediently, kolipey abhishek, sophomore, computer science and engineering, Indian Institute of Technology Kanpur.
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Monday 29 of March 2010 09:30:38 Peter Volkov wrote: > В Вск, 28/03/2010 в 07:47 +0200, Maciej Mrozowski пишет: > > No, seriously - given the fact that some of my packages were even > > stabilized without contacting me (app-misc/hal-cups-utils, > > app-admin/system-config- printer-common) > > If you know packages are broken why they were not hardmasked? If they > have no problems what why it was bad idea to mark them stable? They are not broken, they're just not suitable. It's like stabilizing gcc-2.95 now, even when it won't work with some recent KDE/boost. hal-cups-utils is not a problem system-config-printer-common-1.1.13 is as it's being used by maybe incompatible now system-config-printer-kde from testing arch (I've raised those deps now), besides I wanted to wait for polkit-1 with this package (otherwise dbus "newprinternotifications" can be received only by root or require tweaking dbus conf to work out of the box . That's why kde- base/system-config-printer-kde and kde-base/printer-applet were intentionally left out from KDE-4.3.3 stabilization list. -- regards MM
Re: [gentoo-dev] misc packages up for grabs
El mar, 23-03-2010 a las 21:40 +, Jeremy Olexa escribió: > I will be moving these to maintainer-needed in a few days. I no longer use > them and have little motivation to fix incoming bugs. Don't bother to ask, > just feel free to change metadata.xml to yourself. > > Thanks, > Jeremy ... > > sys-apps/preload > No longer use, a few open bugs. > I will take this one Best regards signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] List of User projects
René 'Necoro' Neumann wrote: > Am 28.03.2010 10:30, schrieb Luis Francisco Araujo: >> himerge > > Hey :P - you are a gentoo dev :P > > I think probably most of the app-portage category falls in here (as > portage is the only "gentoo-specific" thing one can develop stuff for): > > eix, etc-proposals, gpytage, ... But himerge is not an official Gentoo project. So I guess it falls into the category of "user developed projects" :P -- Luis F. Araujo "araujo at gentoo.org" Gentoo Linux
Re: [gentoo-dev] List of User projects
On 29 March 2010 09:31, Alistair Bush wrote: > ps. I must say that its a little sad that so far there has been much more > effort put into nitpicking than actually populating the list (working towards > the goal). The problem is that it isn't very clear what exactly the goal is, and what the criteria for inclusion are. Once you clarify the goal and the criteria and ask for which packages should be included on that basis, I think you'll get the answers you're looking for. Cheers, -- Ben de Groot Gentoo Linux Qt project lead developer
Re: [gentoo-dev] List of User projects
On Mon, Mar 29, 2010 at 08:31:32PM +1300, Alistair Bush wrote: > > > ps. I would like the packages to be specifically for gentoo, but there > > > are exceptions to this. as an example openrc (and even paludis to a > > > degree). If you think that there is a package not specifically > > > targetting gentoo that deserves a mention please make it clear why. > > > > I'm a bit torn by this proposal; on the one hand, a shout out is nice- > > from a career angle it certainly would've been useful for getting > > some attention/exposure when I first was starting out. > > > > Not really my aim. Im not planning on listing ppl, just there work. Might > not even put a url pointing to it. Ok, that clarifies things a bit- I initially misinterpreted your proposal as more then an external contributors list. > Currently I am taking this from Mon, 29 March 19:42 NZ DST. So pkgcore is > external, and you are a community member so your in the list. I don't want > to bring a whole pile of history into it. Will pkgcore have its own gentoo > project, or be considered as part of a gentoo project? Im guessing not > anyway. Honestly hadn't thought about pkgcore's status in reference to my regaining +w, so I'd assume it'll remain status quo- externally hosted. > ps. I must say that its a little sad that so far there has been much more > effort put into nitpicking than actually populating the list (working towards > the goal). Which sums up gentoo pretty much. So lets highlight this part a > little more Note I'm generally overly specific, intent isn't to rip your proposal to tiny little shreds - I actually like the idea, it just didn't seem clear if the idea was to focus was on interesting packages and what they do (regardless of dev/non-dev origin) or if your intent was to focus on non-dev contributions. I'm *personally* more interested in the former (I like reading about cool projects, regardless of who created it), but your intent seems more the latter, which is fair enough since you'll be the one doing the work. additions to your list: * porthole (Brian Dolbec) * cfg-update (nfc who wrote it, but it was at least at one point a reasonably common alternative to etc-update) * deltup: John J. Whitney, the infra. is maintained on gentooexperimental by blackace. Notable mainly since it's the only working delta compression setup for distfiles.. still active last I knew, also. Those are just a couple of the portage ones I can think of at this hour- will update w/ more as I get time cheers- ~harring pgpavmU1mDXx5.pgp Description: PGP signature
Re: [gentoo-dev] RFC: changing ssl use flag descriptions and unify behavior
On Sunday 28 March 2010 02:03:43 Doug Goldstein wrote: > On Sat, Mar 27, 2010 at 9:54 AM, Petteri Räty wrote: > > See this thread for background: > > http://archives.gentoo.org/gentoo-dev/msg_0673a33fe75961e510872fd2c1044ce > > d.xml > > > > I think we should go through all the ssl use flag using packages and > > unify the use flag descriptions and behavior to the following standing > > policy (handed down probably): > > > > 1) packages always have the general ssl use flag to control whether to > > enable ssl at all > > 2) If the package supports multiple backends then there's use flags for > > gnutls, openssl or nss. EAPI 2 use defaults will be used to > > communicate upstream defaults if any. If they are all turned of > > select the default (ssl being on). > > > > No objections and I will open a tracker a week from now and let's see > > who joins up to go through packages and open bugs. > > I seriously hate changing USE flags for the sake of changing use > flags. i dont really think USE=ssl is changing. it has always been "enable SSL support". unfortunately, because this is usually done via openssl, some maintainers thought the flag was the same thing as "use openssl". so any package that is changing is most likely because is currently using USE=ssl incorrectly, or not respecting it at all (which is also incorrect). -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] List of User projects
On Mon, Mar 29, 2010 at 08:31:32PM +1300, Alistair Bush wrote: > I'm quite happy to consider the corner cases, and will probably include a > vast majority of them. Initially I don't even believe I will have a fully > complete list of all the projects the fit nicely into my criteria. Thats why > you have one of those nice statements that says. catalyst, genkernel, hwdata, livecd-tools were originally in-house, just like the parts of baselayout that became openrc, but have moved outside. I maintain some interesting/useful scripts: http://dev.gentoo.org/~robbat2/scripts/ - earch - perl-bump complex conf.d/net configurations: http://dev.gentoo.org/~robbat2/conf.d-net/ I wrote genflags: http://dev.gentoo.org/~robbat2/genflags/ It's now mostly dead, good only for historical research. "Managed Portage", taking stacked profiles to their extreme: http://dev.gentoo.org/~robbat2/managed-portage-0.01.tar.bz2 Unfortunately my patchsets and documentation for using Gentoo on SGI Visual Workstation 320 (visws320) and the XXS1500 MIPS system are very out of date. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] List of User projects
> > diffball (the basis of y'alls delta compression for tarball > snapshots, progenitor of tarsync used by emerge-*webrsync, etc). > Thank you Brian for that pkg, its appreciated. My apologies if the rest is a little less kind. > > ps. I would like the packages to be specifically for gentoo, but there > > are exceptions to this. as an example openrc (and even paludis to a > > degree). If you think that there is a package not specifically > > targetting gentoo that deserves a mention please make it clear why. > > I'm a bit torn by this proposal; on the one hand, a shout out is nice- > from a career angle it certainly would've been useful for getting > some attention/exposure when I first was starting out. > Not really my aim. Im not planning on listing ppl, just there work. Might not even put a url pointing to it. > That said, it has some issues with it: > > * it'll wind up being a fairly subjective list leading to some > debates nobody really wants to be involved in (nice euphemism for > flamewars). Well I suppose it would be my project, therefore I would make the call. ppl can flame all they like really. Personally I don't find them a very good way to communicate, would probably miss what they were flaming about anyway. > *) the criteria seems to be external projects that are gentoo > specific, aparently by non-devs/ex-devs. This raises some questions > as to what happens for when it's created by a dev externally (pkgcore > went external a long while before I became an exdev), and what > happens when the author becomes a dev (I'll be getting my gentoo-x86 > +w back soon enough). Firstly that is very good news. Currently I am taking this from Mon, 29 March 19:42 NZ DST. So pkgcore is external, and you are a community member so your in the list. I don't want to bring a whole pile of history into it. Will pkgcore have its own gentoo project, or be considered as part of a gentoo project? Im guessing not anyway. I'm quite happy to consider the corner cases, and will probably include a vast majority of them. Initially I don't even believe I will have a fully complete list of all the projects the fit nicely into my criteria. Thats why you have one of those nice statements that says. "While we have attempted to list all package/projects etc we are sure we have missed some, please contact .. if you believe we have missed something blah de blah blah" > *) PMS was started outside of gentoo, and maintained outside gentoo > for a long while. Now it's a gentoo project. A shout out there > would've been warranted (spec work isn't exactly sexy, regardless of > any extra baggage that came w/ PMS), but at what point does it > suddenly fall off this list? Isn't this a bit too bikesheddy. If someone, from now, were to create a project and then have it added to the list before they become a dev then good on them. The project would not be removed. Even if it died. In fact the list would never be cleaned. It may be updated to represent the state of the project, but that project would be there for as long as the page was. (and probably longer the way ppl index the interwebs). > *) kind of the packagekit connundrum- at least for pkgcore/paludis, > they were written to support multiple distros/formats internally. Yes > they've got traction w/in gentoo, but at what point is it no longer a > gentoo specific thing, and more of a "it gained it's first traction in > gentoo" ? Openrc I'd argue is in the same boat- yes it can be used > elsewhere, but right now we're the owns extracting the most benefit > from it. Well I would suggest that a major part of the functionality of both those pkg's are directed towards supporting gentoo. Even if both supported 5-10 completely different distro's that did not resemble gentoo in the slightest I would still put them on the list. Compare this with kmyfirewall that had a single dialog that allowed to be set "gentoo specfic" executable paths which would not be on the list. > *) it slights the tools that started w/in gentoo's vcs; consider > scanelf . Very useful tool deserving some credit, but it would be > exempted under these rules. Life ain't always perfect. And that goes both ways. This isn't a list to thank developers for their effort, make another thread if you want that. It also doesn't slight that project in the slightest. > > Instead, if the purpose is a "thanks", why not every once in a while > put up a news item discussing the tools in question? Such an > approach allows folk to focus in on whatever is useful/interesting > (regardless of origination) and give the same 'thanks' angle and > public exposure for the author in question. Well I was considering this as well. But first before we do this we would need to actually know what packages there are. Therefore this thread. Unless we do all packages from a to z. - Alistair ps. I must say that its a little sad that so far ther
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
В Вск, 28/03/2010 в 07:47 +0200, Maciej Mrozowski пишет: > No, seriously - given the fact that some of my packages were even stabilized > without contacting me (app-misc/hal-cups-utils, app-admin/system-config- > printer-common) If you know packages are broken why they were not hardmasked? If they have no problems what why it was bad idea to mark them stable? > * solely up to the package maintainers to stabilize application on arches > they're using or on any arch if package is arch-agnostic (optionally, but > preferably with some peer review from other project members or arch team > members). In general package maintainer should avoid to stabilize the packages he worked on as one of the arch team's goal was to have second eyes on package before it goes stable. > Role of arch teams would be decreased to peer review and solving KEYWORD > requests. > > It's really freaking silly to wait months for stabilization of some random > php/perl library that's known to work. Why wait? amd64 team requested help and every developer who tested package on stable profile is allowed to mark package stable. For rare archs it's possible configure search filters to avoid stabilization requests. -- Peter.
