Re: [gentoo-dev] extending existing EAPI semantics
Brian Harring wrote: One thing I'll note is that the .ebuild-$EAPI approach isn't the end all fix to versioning extensions that y'all represent it as. Essentially, what .ebuild-$EAPI allows is additions to version comparison rules, no subtractions. Each new $EAPI *must* be a superset of previous $EAPIs. Uhh... no. Just like how older package managers which don't understand how to read the EAPI from a filename suffix would basically ignore the new ebuilds, any package manager that can, but doesn't recognize the eapi of the new one, will just ignore it. It won't ever try to figure out its version or anything, it'll just do nothing. Also, there is absolutely no reason for all future EAPIs to be a superset of old eapis. While paludis (and presumably pkgcore and portage, I'm not as familiar with their code) has implemented EAPI=1 as a few additions to EAPI=0, there is no reason that gentoo might not decide to have EAPI=9000 some day, complete with artificial intelligence that completely obsoletes USE flags, or some such thing (it's late, I know the analogy sucks). -- Mike Kelly -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
Mike Auty wrote:
The speed issues aren't really a concern, since the GLEP suggests that
the ebuild must be sourced anyway. The GLEP allows for a .ebuild-2 file
to contain EAPI="1".
Wrong. From the GLEP: "note that one should *never* explicitly set both
EAPIs to different values."
Basically, you don't set the post-source EAPI. It is only supposed to be
used when the pre-source EAPI cannot be determined. This is entirely for
backwards compatability with EAPI={0,1}. Once people start using
suffixed EAPIs, EAPI should not (probably "must not") be set in the
ebuild. Sure, because of how the algorithm works, people could
potentially do both, but the GLEP makes it pretty clear that they shouldn't.
--
Mike Kelly
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 27
On Thu, 10 Apr 2008 16:35:36 -0400 Doug Goldstein <[EMAIL PROTECTED]> wrote: > How does everyone feel about the proposed layout and syntaxes of GLEP > 27? > > Do we want to revisit this GLEP with an updated GLEP or status quo? > > http://www.gentoo.org/proj/en/glep/glep-0027.html This was my SoC project a few years back. I have the code mostly done, minus some more sanity checks, unit tests, testing by folks, and patch to jam it into portage (should be trivial for someone who knows portage's code, which I don't). The project is called Creandus, and you can find it at: http://creandus.pioto.org/ -- Mike Kelly -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Improving use.desc
While you're at it, I think almost everything in desc/video_cards.desc, desc/input_devices.desc, and a few more, could use some attention. In particular, things like nv vs. nvidia are quite confusing. I usually end up reading the xorg-server ebuild when I want to makes sense of it, which defeats the point of video_cards.desc altogether. Also, things like desc/userland.desc have all their variables starting with "USERLAND setting for" which is about as useful as having every use.desc line start with "USE setting for". That said, the various alsa*desc files, and some others, are well documented, and would serve as a good example for the others. -- Mike Kelly -- [EMAIL PROTECTED] mailing list
[gentoo-dev] So long Gentoo...
For many reasons, I'm choosing to take my leave from Gentoo at this time. While this was in part brought on by the recent discussions about the mailing lists, it's related to many other things as well. Mainly, I don't have the motivation that I used to have to work on Gentoo. I feel like my efforts are being stymied by the lack of overall technical progress and direction in the project. I'm not abandoning open source altogether; I'll still be working on a few projects here and there. I'll still be around on IRC if I'm needed for anything. I regret not having fully completed my GLEP-27 implementation, but my code is still available for anyone who wants to do the few remaining bits (mainly, incorporate it with portage, and patch shadow to allow it to work on an alternate /etc/passwd,shadow,group etc). I have a few helpful scripts for Vim maintenance that I can give to whomever wants them (nelchael probably, don't if anyone else is going help him out). Also, my apologizes to anyone else that I had said I would help out. If you still need me, you can track me down on IRC and I can at least give you some pointers (but probably not much in the way of code). As for SoC this year, I'll still be available to mentor as much as I can, on IRC and by email. Best of luck with Gentoo. -- Mike Kelly <[EMAIL PROTECTED]> http://blog.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] ML changes
Mike Doty wrote: We're going to change the -dev mailing list from completely open to where only devs can post, but any dev could moderate a non-dev post. devs who moderate in bad posts will be subject to moderation themselves. in addition the gentoo-project list will be created to take over what -dev frequently becomes. there is no requirement to be on this new list. This will probably remove the need for -core(everything gets leaked out anyway) but that's a path to cross later. We're voting on this next council meeting so if you have input, now would be the time. Here's my input: Hell no. I might post something more detailed later, but that's the gist of it. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Packages with same name was -> Conversion of Emacs virtual packages
On Thu, 17 May 2007 00:37:23 +0200 Thilo Bangert <[EMAIL PROTECTED]> wrote: > > > It isn't different. That's the problem. If you have two packages > > > with the same name, you have the same problem. > > > > On that note I would hope the vim/vi peeps would rename. > > app-vim/ant > > and app-vim/sudo That's getting the axe in a few weeks. > > IMHO app-vim/ant should really be app-vim/vim-ant or something other > > than just ant. > > or app-vim/sudo-syntax and app-vim/ant-syntax as there already are a > number of ebuilds following that scheme... Well, sudo and ant aren't syntax plugins, so that wouldn't make any sense. Also, we're keeping the same names that the upstream script writers use, just as we do everywhere else in Gentoo. The whole point of having category names is so that we can have two packages w/ the same name and not have issues. -- Mike Kelly -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites: app-vim/doxygen-syntax
On Sat, 14 Apr 2007 19:56:04 -0400 Mike Kelly <[EMAIL PROTECTED]> wrote: > A modified version of app-vim/doxygen-syntax-1.15 is already included > in vim7, no point in keeping this around. See Bug #174637. Scheduled > for removal in 30 days. And it's gone... -- Mike Kelly signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-vim/sudo
Not a very good or useful script, has an open bug (#158231), not really worth fixing. To be removed in 30 days. -- Mike Kelly signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-vim/doxygen-syntax
A modified version of app-vim/doxygen-syntax-1.15 is already included in vim7, no point in keeping this around. See Bug #174637. Scheduled for removal in 30 days. -- Mike Kelly signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] *DEVELOPMENT* mail list, right?
Michael Cummings wrote: > So, fellow devs, what's new with development? Hmm, well, recently I've been working on some bug fixes for eselect (mostly related to automake headaches), doing the occasional bump to vim and friends when there seems to be a useful new patch out (although additional help w/ vim would be appreciated), and hacking together some random scripts. I've kinda been lapsing in the past few weeks, though; need to finish up this job and get back to school. A few other things I want to try and do: - Help dberkholz with autofoo magic for ltsp (sorry I've slacked so long on this, I'll have more time to dig into it in a month). - Help work on some of the targets we have now for eselect 1.1.x (all of which probably need some more discussion before they're coded). - Document vim-related ebuild maintenance stuff, in the hopes of lowering the barrier of entry for folks, as well as making / improving a few scripts to make ebuild maintenance easier. -- Mike Kelly signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
Alec Warner wrote: > The fact that Gentoo can continue with the codebase is irrelevant. I > think moreso the fact that a particular Package Manager would be the > 'Gentoo Package Manager' means in my mind that Gentoo is responsible for > said Package Manager. If someone were to slip evil code into said Package > Manager and Gentoo released it; that would be bad. > > Note that with Portage, Gentoo could pull svn access for any individuals > who commit such code. Gentoo have no gaurantee of that with an externally > managed Manager as Gentoo has no control over the source repositories. > > If, by your comment above, Gentoo should maintain it's own branch of said > package manager to insulate itself from issues such as the security issue > defined above; well I think that may be one way to address the problem > presented by Seemant. Come on, that's a bogus argument. By that logic, we should be maintaining our own branches of, say, sys-apps/shadow, since we don't control the upstream CVS repository. I think something that's installed in the base "system" set would also be perceived as something that Gentoo is responsible for, since we ship it in our stage tarballs, the basic building blocks of a Gentoo system. -- Mike Kelly signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Cultural Differences (was: Suggestion: INVALID -> NOCHANGE in bugzilla)
On Sun, 25 Mar 2007 02:21:46 +0200 Alin Năstac <[EMAIL PROTECTED]> wrote: > Christopher Sawtell wrote: > > In which case it must be a feature, so why not use the keyword > > FEATURE? > > Why would we need a keyword for that? We already have "enhancement" > as a possible value of the severity field. I think he was making a joke there (along the lines of the saying, "It's not a bug, it's a feature!"). Sadly, this just goes to show how people need to be more careful in their wording in a community like ours with people coming from so many different cultures. Or maybe people need to lighten up a bit more, I don't really know which. Anyone have any further suggestions how we as a community can avoid this sorta confusion from in-jokes, idioms, etc? It seems to be happening very often now-a-days (or maybe I'm just paying more attention than I used to). -- Mike Kelly -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposed addition to the Social Contract
Darn, there go Piotocorp's plans of buyout... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 24 Mar 2007 09:30:55 -0700 Mike Doty <[EMAIL PROTECTED]> wrote: > Yes. pioto's proposal is weak. You mean Piotr, right? He's a different person from me. -- Mike Kelly -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] dont use `which` in ebuilds
On Tue, 13 Mar 2007 01:14:54 +0100 Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: > Also there are some occurences in eclasses: > ./eclass/vim-doc.eclass: >vim=$(which vim 2>/dev/null) > ./eclass/vim-doc.eclass: >[[ -z "$vim" ]] && vim=$(which gvim 2>/dev/null) > ./eclass/vim-doc.eclass: >[[ -z "$vim" ]] && vim=$(which kvim 2>/dev/null) > ./eclass/vim.eclass: > export ac_cv_prog_STRIP="$(which true ) faking strip" Fixed. -- Mike Kelly -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New eclass: gkrellm-plugin
On Thu, 8 Mar 2007 12:34:59 -0600 Jim Ramsay <[EMAIL PROTECTED]> wrote: > Petteri Räty wrote: > > Jim Ramsay wrote: > > > ECLASS="gkrellm-plugin" > > > INHERITED="$INHERITED $ECLASS" > > > > No need to set INHERITED yourself any more either. Ciaran already > > pointed out ECLASS. > > Indeed, thanks for that! > > They just appeared automagically when I did 'vim foo.eclass' I > wonder where that comes from... That comes from the app-vim/gentoo-syntax package, in the plugin/newebuild.vim file. I'll have that fixed in the next release of gentoo-syntax. -- Mike Kelly -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Some council topics for March meeting (plus glep27)
On Sat, 3 Mar 2007 06:00:32 -0800
Brian Harring <[EMAIL PROTECTED]> wrote:
> Thats off the top of the head, and just the stuff I've had on hold
> for EAPI=1. Would expect user/group management (glep27 off the top
> of the head) would be on the radar also, although thats firmly in
> pioto's court.
Hmm, since I was mentioned here, I guess I'll respond.
My glep 27 implementation is essentially complete, though without
making some changes to PAM and shadow, it won't really function for
ROOT!=/ with a GNU userland. Because of this, I don't really deem it
ready for general use yet.
I want my final code to be complete and done in the correct way, so
rather than just having it hack away at ${ROOT}/etc/passwd and what
not, I want to take the time to patch PAM and shadow. This isn't
something I really have the time right now to dive into (I'm working 6
days a week), but I hope to have the time to dive into it in a few
more months when I leave my current job and go back to school.
Back on topic, though. I don't see how having this spec drafted in part
by non-developers is such an issue. The council doesn't have to accept
this document as official, and they can always request changes be made.
So, how does it matter if one of the people who has a strong interest
in writing this isn't currently a Gentoo developer? I'd say we should
be glad, since it means that developers can spend more time on their
other projects and not have to worry about doing the grunt work of
writing this spec. And, just because people are working on writing this
spec doesn't mean other folks can't go and write their own.
--
Mike Kelly
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: alternatives.eclass and ecompress
Christian Faulhammer wrote:
> Fine. If I have a slotted package, every slot having
> ${PN}.foo-${SLOT}.1.gz and I want people to be able to call `man
> ${PN}`, how should that be done?
You could look at eselect-vi[1] for how it handles this case,
specifically the set_man_symlink() function.
[1]
http://sources.gentoo.org/viewcvs.py/eselect/trunk/modules/vi.eselect?view=markup
--
Mike Kelly
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo standard UIDs
José González Gómez wrote: > Is there anywhere I can find the list of standard UIDs/GIDs used in Gentoo? There is / was such a list in CVS[1] at some point, thought it is far from complete or current. > I also took a look at > http://devmanual.gentoo.org/ebuild-writing/users-and-groups/index.html, and > there they say that you shouldn't hard code the UID/GID, so does enewuser > use some kind of algorithm to keep the new UID/GIDs in a given range? Can I > be sure that a UID generated by enewuser won't collide with some range I > reserve for non system users? You can pass -1 as the uid parameter to enewuser. In this case, it will search for the first free uid between 101 and 999, inclusive. This will be much nicer / easier to do once I finish my[2] GLEP 27[3] implementation... [1] http://sources.gentoo.org/viewcvs.py/gentoo-src/eid_database/ [2] http://soc.pioto.org/ [3] http://www.gentoo.org/proj/en/glep/glep-0027.html -- Mike Kelly signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: www-client/mozilla[-bin]
On Sun, 28 Jan 2007 18:03:49 +0100
Christian Heim <[EMAIL PROTECTED]> wrote:
> On Saturday, 27. January. 2007 13:22:56 Petteri Räty wrote:
> > Raúl Porcel wrote:
> > > # Raúl Porcel <[EMAIL PROTECTED]> (27 Jan 2007)
> > > # Masked for removal 26 Feb 2007, bug 135257, security issues
> > > # Replaced by www-client/seamonkey[-bin]
> > > www-client/mozilla
> > > www-client/mozilla-bin
> >
> > How about not breaking the tree?
> >
> > !!! All ebuilds that could satisfy "www-client/mozilla" have been
> > masked. !!! One of the following masked packages is required to
> > complete your request:
> > - www-client/mozilla-1.7.13 (masked by: package.mask)
>
> What about the rest of the portage error ? At least it could be used,
> to fix (well sort of) it :)
I think he just has www-client/mozilla in his world file. From what
I see, nothing in tree still depends on www-client/mozilla{,-bin}.
There's just a block against it by www-client/seamonkey.
--
Mike Kelly
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Big change ideea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marijn Schouten wrote: > 3) security. When installing a package, it only has write access to its > own directory. I'm guessing they do this with ACLs. > > So we have this cool package manager which supports 1) and 2), but not > 3) I think, and they have almost no package manager, but it supports 1), > 2) and 3). Gentoo has this feature, too. It's provided by a package called sys-apps/sandbox. It's a dependency of portage on all glibc and uclibc systems (so, it's part of any standard Gentoo/Linux install). It prevents packages from touching anything outside of their build directory, or an image directory where it is installed before portage merges the files into the live filesystem. - -- Mike Kelly -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (MingW32) iD8DBQFFgzZKokMzJ47YCzoRAh/RAJsHLn4hd0EyoirGWtrzpWJi2EpprwCgpkBU 8zgguiyibYouS6F2X96Ser8= =IhAp -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] vim syntax global use flag
On Sat, 21 Oct 2006 10:21:37 -0400 "Caleb Cushing" <[EMAIL PROTECTED]> wrote: > I was thinking a while back (dangerous) ;-). That it would be a good > idea to have a global use flag for all packages that have related vim > syntax ebuilds. say I set the use flag (let's call it vim-syntax) for > pam, then it would pull app-vim/pam-syntax, there are I think at least > 20 syntax ebuilds. Sounds good to me, too. I've opened Bug #152275[1] to track this. At first glance, looks like the following 12 packages are affected: x11-libs/gtk+ : app-vim/gtk-syntax (also applies to gimp, gnome, etc) sys-fs/udev : app-vim/udev-syntax (syntax for udev rules files) net-misc/cfengine : app-vim/cfengine-syntax (syntax for cfengine config files) app-admin/conky : app-vim/conky-syntax net-misc/dhcp : app-vim/dhcpd-syntax app-doc/doxygen : app-vim/doxygen-syntax dev-ruby/eruby : app-vim/eruby-syntax x11-wm/fluxbox : app-vim/fluxbox-syntax net-analyzer/nagios : app-vim/nagios-syntax net-misc/ntp : app-vim/ntp-syntax sys-libs/pam : app-vim/pam-syntax sys-libs/libselinux : app-vim/selinux-syntax [1] http://bugs.gentoo.org/show_bug.cgi?id=152275 -- Mike Kelly signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 27: Revisited (aka dynusers/creandus)
On Tue, 3 Oct 2006 13:46:03 -0400 Mike Kelly <[EMAIL PROTECTED]> wrote: > On Tue, 03 Oct 2006 08:09:08 -0400 > Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > > You missed games-* (yes, all of them) via the games.eclass, but I'm > > sure there's a couple more eclasses that do user/group modification. > > Oops, I forgot to account for eclasses. I'll redo my script and run it > again later to account for that. The script has been re-written and run again, results are posted[1]. The script itself is in my svn repo[2]. This most recent run gives a total of 992 ebuilds, from a total of 511 different packages all currently using enewuser or enewgroup. Not counting the games-* ebuilds (which all are using the same line from games.eclass), that's 657 ebuilds, from a total of 245 packages. The tree at the time of this run has 24854 ebuilds from 11578 packages. So, while that looks like a lot of affected packages at first glance, it's only about 4% of the tree. [1] http://dev.gentoo.org/~pioto/creandus/enewusergroup-pkgnames.txt [2] http://svn.pioto.org/viewvc/creandus/scripts/scantree-enewusergroup.bash -- Mike Kelly signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide
On Wed, 04 Oct 2006 10:27:17 -0400 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > > - Project status reports once a month for every project > > > > Totally agree on this one! > > OK. > > I'll give you Release Engineering's "status reports" for September, > October, and November: > > September: taking a well-deserved break > October: taking a well-deserved break > November: taking a well-deserved break Well, in the past, I've found that even getting brief reports like that is very helpful when I've been running meetings. It's just generally good to know that folks are alive and such, and a brief "Hi, we're still here" kinda report every month is nice for that. Just a quick email before the meeting works fine. Also, it gets everyone in the habit of giving reports, so that they remember to report when something new happens. > I don't *want* to drown projects in bureaucracy and paperwork. I want > them to *accomplish* things, instead. Sending a brief "All's well with releng" email isn't exactly what I would call "drowning in bureaucracy". -- Mike Kelly signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 27: Revisited (aka dynusers/creandus)
On Tue, 3 Oct 2006 00:44:57 -0400 Mike Kelly <[EMAIL PROTECTED]> wrote: > On Mon, 02 Oct 2006 21:28:21 -0700 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > > I'd prefer that the format be key=value for easier use by bash, as > > pretty much everything else in profiles is bash. > > Only issue I can think of is that we'd have to be sure to pick key > names that don't conflict with bash variables like UID and SHELL, > which shouldn't really be that hard, so I'm sure there had to be some > stronger reason to not make it shell variables... I'll dig through > logs and try to figure out what it was. Well, I couldn't find anything in my IRC logs, all I could find is that I switched away from using the key="value" stuff at r10 in my svn repo, on 5 July (it's now at r213). No one else I talked to remembered why the switch was done in the first place, so I'm just going to change the format back to key="value", like bash variables. Unlike most other variables in profiles, though, I am keeping these with all lowercase variable names, e.g. uid="5". I'll update the documentation in my dev space tomorrow. -- Mike Kelly signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 27: Revisited (aka dynusers/creandus)
On Tue, 03 Oct 2006 10:20:53 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > beside the syntax, as pointed by Donnie, it looks ok. > I guess could be possible extract automagically from the current tree > the data and create the datafile from it, isn't it? Yeah, it should be. I'm writing up a few scripts now to do that, along with one to let me file bugs with maintainers of packages that need porting (I won't run that one for a while still). -- Mike Kelly signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 27: Revisited (aka dynusers/creandus)
On Tue, 03 Oct 2006 08:09:08 -0400 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > I have a list of all packages in the tree that currently use either > > of those functions[2]. If you maintain one of these packages, I'd > > especially appreciate your feedback. > > You missed games-* (yes, all of them) via the games.eclass, but I'm > sure there's a couple more eclasses that do user/group modification. Oops, I forgot to account for eclasses. I'll redo my script and run it again later to account for that. > What about applications that aren't tied to a profile? How do they > work? Well, user management is inherently tied to the userland which is being used, which is in turn tied to the profiles (default-linux, default-bsd, etc). Settings which are userland-agnostic (like default uids, member groups, GECOS comment fields), would be in the settings for the base/ profile. > Doesn't this increase the size of the profiles pretty > dramatically? I don't think it makes that much of a size difference. Most of this information is now duplicated over many enewuser/group lines in many different ebuilds. With this system, ebuilds just need to have a EUSERS and EGROUPS variable defined listing the users/groups needed. > Does it need to be tons and tons of small files, or can > we get away with a set of larger files with some sort of header? > > As you can see, this changes very little, but reduces the number of > small files in the portage tree. Is this necessary? Who knows? Will > it makes syncs slightly faster? Not a clue. I'm just throwing out an > idea. Hmm, parsing that would be a more difficult task for my scripts (which are just basic bash code doing some greps). Also, it seems like the many small files are easier to maintain. I don't know enough about rsync to know how it would affect efficiency, though. It's something I'll try and look into further. > Anyway, this looks really good. =] Thanks! -- Mike Kelly signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 27: Revisited (aka dynusers/creandus)
On Mon, 02 Oct 2006 21:28:21 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > Mike Kelly wrote: > > All the files are handled like other files in cascading profiles. > > Each line in the file is either a shell-style comment, or of the > > form: "key: value". The keys are: uid, shell, home, groups, > > comment, and gid. > > I'd prefer that the format be key=value for easier use by bash, as > pretty much everything else in profiles is bash. I would as well, since my code is written written in bash and that would make it easier on me. I had tried to do it that way before, but some folks suggested changing it to what it is now, although I really forget why. Only issue I can think of is that we'd have to be sure to pick key names that don't conflict with bash variables like UID and SHELL, which shouldn't really be that hard, so I'm sure there had to be some stronger reason to not make it shell variables... I'll dig through logs and try to figure out what it was. -- Mike Kelly -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 27: Revisited (aka dynusers/creandus)
On Tue, 03 Oct 2006 00:09:11 -0400 Alec Warner <[EMAIL PROTECTED]> wrote: > Mike Kelly wrote: > > Summarized, the format is: > > > > For each profile dir (e.g. profiles/base, profiles/default-linux, > > etc), a new subdirectory, called accounts is created as necessary. > > Inside that is a file called defaults, containing default uid/gid > > ranges, shells, etc for the given profile. Also, there are two > > directories, user/ and group/, which contain files named after the > > users and groups to be added. Those files contain more specific > > uid/gid info, etc. > > I hope to god they cascade like everything else ? > > All the files are handled like other files in cascading profiles. Yes, they do. Sorry, I guess I didn't word that clearly enough. > Also I don't see why we would have this in the profiles as opposed to > somewhere in /etc/? Because, first of all, this data must exist before a package is installed (so, it can't be part of the package itself). It shouldn't just be in some creandus-data package because all this is closely linked with the tree, and should be maintained by the individual package maintainers. Also, some specifics of the settings for users and groups are somewhat profile-specific (see below). > Have people expressed an interest in per-profile mangling of uid/gid ? That isn't as important as, say, properly setting the default shell on a per-profile basis. I mainly see stuff being set in the base, hardened, and default-* profiles, not in say the default-linux/x86/2006.1/server/ profile specifically. Only time I can see wanting to mangle uid/gid per profile is if this gets adopted for managing even the system users currently provided in the default /etc/passwd and /etc/group files, where some variance has to happen for each USERLAND. For example, there isn't a root group on FreeBSD, just a wheel group. -- Mike Kelly -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GLEP 27: Revisited (aka dynusers/creandus)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, As some of you may know, I spent this past summer working on an implementation of GLEP 27[1]. While my scripts aren't quite ready for production use yet, I wanna get the ball rolling by asking devs who maintain packages that use the current enewuser() and enewgroup() functions from eutils.eclass to document their desired account settings in one central location. I have a list of all packages in the tree that currently use either of those functions[2]. If you maintain one of these packages, I'd especially appreciate your feedback. The proposed storage format[3] is what my scripts (creandus, formerly known as dynusers) currently use. To me, the format seems simple and sane enough, but I would definitely appreciate any and all feedback on it, since it's much easier for me to change it now than to change it later. Summarized, the format is: For each profile dir (e.g. profiles/base, profiles/default-linux, etc), a new subdirectory, called accounts is created as necessary. Inside that is a file called defaults, containing default uid/gid ranges, shells, etc for the given profile. Also, there are two directories, user/ and group/, which contain files named after the users and groups to be added. Those files contain more specific uid/gid info, etc. All the files are handled like other files in cascading profiles. Each line in the file is either a shell-style comment, or of the form: "key: value". The keys are: uid, shell, home, groups, comment, and gid. The main point of this thread is to get lots of feedback and, hopefully, acceptance of this proposed format. As this is basically what is already outlined in GLEP 27, I don't think a new GLEP is in order, but if others do, I'll draft one. The main webpage for my Summer of Code project[4] has links to more information about the project in general, and there are some posts on my blog[5] regarding it. [1] http://www.gentoo.org/proj/en/glep/glep-0027.html [2] http://dev.gentoo.org/~pioto/creandus/enewusergroup-pkgnames.txt [3] http://dev.gentoo.org/~pioto/creandus/doc/datafiles.html [4] http://soc.pioto.org/ [5] http://blog.pioto.org/category/dynusers/ - -- Mike Kelly -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFIdHzokMzJ47YCzoRAoBYAJ0drAJrxAMx3p9g5jrnTwQu9mePaQCggV6Y SpIBoDGFUJ6J0xBNdWANqtc= =2P1l -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Last rites for $package ...
On Thu, 28 Sep 2006 22:28:27 +0200 Enrico Weigelt <[EMAIL PROTECTED]> wrote: > An solution could be an database of packages scheduled for > removal. But this database has to be maintained. And it doesn't > seem that there's someone who's interested in doing this extra work. As I understand it, every one of these package removals is first package.masked for 30 days before the ebuilds are actually removed. So, the user has a month in which to do something about this. When they sync and try to update any time during that month, they will see a message, telling them that that package is scheduled for removal, and pointing them at the relevant bugs in bugzilla. So, isn't package.mask already that "database"? Or am I missing something? -- Mike Kelly -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: seeds, GLEPs, and projects
On Thu, 21 Sep 2006 21:43:16 + (UTC) "Peter" <[EMAIL PROTECTED]> wrote: > That's a laugh! Problem is that no devs seem to get approved in a > timely fashion. And, any potential devs would be rather turned off by > the goings on here. You guys seem to try and stifle innovation at > every turn -- trying to turn Gentoo into GLEPtoo. Instead of > progress, you have arguments. Instead of innovation, you have > arguments. Instead of new blood, you lose people. Hi, not so. I've just joined on as a dev, my recruitment process happened in a timely fashion. After I passed all my quizzes, I became a dev. I think we also had at least 3 other new folks in the past few weeks, and maybe 1 person leaving. While getting fresh blood is a good thing, you've gotta be sure that the new blood is up to snuff. That takes some time. There's nothing to stop them from contributing before they're "official." Hey, look at what the other Summer of Code-ers and I did over the past few months. Some of us have become devs, others haven't, but we all made sizable contributions to Gentoo development. -- Mike Kelly signature.asc Description: PGP signature
Re: [gentoo-dev] Project Sunrise resumed again (was Resignation)
On Mon, 31 Jul 2006 00:13:45 -0700 Joshua Jackson <[EMAIL PROTECTED]> wrote: > There is a lot of irony in this entire discussion. We are actually > talking about going against what the heck part of the reason this > project was started. Are we seriously that *can't find the word I'm > looking for* idiotically to not see that we're arguing over not > allowing a user a choice in what they want to do. That we are so high > and mighty that we automatically know what is better for the user then > they themselves know? Who defined us as the ones to make that choice > for someone else, when we are supposedly about allowing choice. > > That is the issue at hand at the core of this. Its called choice. > People can choose to use a separate program to download the sunrise > overlays. That separates it entirely from the core tree itself. A > disclaimer for checking out could be added that is prominent that will > warn that these are a service provided to the community from the > community. That those who have gone through the "developer mentorship" > will continue to work on the core of the heart of gentoo, allowing us > to focus and make the product so much better and quicker that you'll > be blindsided with the new improved product. We'll have a rebirth so > to speak. > > Bloody, I mean seriously...think about what it is we are arguing over, > and then remember what gentoo is, why you came to it in the first > place. That will probably tell you where it should go. Speaking as a user of Gentoo in general, and as a small contributor to Sunrise, I don't think your argument about "choice" really is relevant. Since Gentoo is licensed under the GPL-2, end users can always choose to do whatever the heck they want. They can make their own overlays, patch packages to no tomorrow, and use whatever packages they wish on their system. As I understand it, the real goal is to let users get a taste of what ebuild development is supposed to be like, and to give them a lot of guidance and a chance to get their draft work peer reviewed. This is something they could always /choose/ to do, either by visiting the #gentoo-dev-help channel on freenode, posting a new ebuild on bugzilla, the forums, etc. The Sunrise project is just trying to focus entirely on ebuilds, while most of the above have other primary focuses. I /think/ the issues some folks are taking with the project are: * It's dangerous to have this sort of thing "officially" affiliated with Gentoo because it has the potential to cause unforeseen breakage. For example, an ebuild in the tree may have a flag for ./configure which wasn't explicitly disabled but which will now auto-set itself on when a certain package from Sunrise was installed. This /could/ cause some breakage which is very difficult for someone trying to help a user submitting a bug to recreate, and create some wasted time and general frustration on both sides. In general, many wish to change the image of Gentoo being the "ricer" OS, and in some ways this project has that sort of air about it. * The design of the project, people involved, whatever, isn't conducive to it achieving its desired goal (helping train users in proper ebuild development). I think the point about not having involvement from the relevant herds or arch teams is related to this as well.I don't have enough experience to judge this point at all. Speaking just as myself, I think that, if I were to choose to use some ebuild from Sunrise other than the one I wrote myself, I would be careful and wouldn't scream to hard if something broke. I don't know what others would do. I think that the project does have some merit and seeks to achieve a worthy goal. I don't know, however, if it is the best option available, or the best execution. -- Mike Kelly signature.asc Description: PGP signature
[gentoo-dev] GLEP 27 - API Specs
Hi, Attached is a draft of my API spec for my GLEP 27 implementation (user/group management for package managers). Any feedback would be appreciated. The latest version of this document can also be found in my subversion repository[1]. Thanks! [1] http://soc.gentoo.org/viewcvs.py/*checkout*/glep0027/trunk/dynusers/API -- Mike Kelly "Happiness adds and multiplies as we divide it with others." This is a sketch of the basic "API" for interfacing with the dynusers scripts. There are several different tasks which these scripts must do: 1. Maintain a database of users and groups that have been added by the scripts. These databases contain a newline separated list of package identifiers (name and version, usually), which mainly serves to tell the scripts when a user is no longer used by any package on the system. Database actions should all go through the db.sh script. This can be invoked in 2 different modes: db.sh add dbtype pkgname newname [root] Adds an entry to the database. dbtype is one of user or group, pkgname is a unique package identifier (category, name, and version), newname is the name of the user or group to be added. The optional parameter, root, defines the system root to install into. If not provided, it is assumed to be /. db.sh del pkgname [root] Removes all instances of pkgname from the database. This is what is run when a package is removed, or upgraded (the old version needs to be removed from the database). The optional parameter, root, is the same as above. 2. Add any users or groups requested by a new package to the system. At the same time, the database should be updated. This action is performed by the add.sh script. It should be run once, before the package is unpacked, compiled, or installed. It is invoked as follows: add.sh "new users list" "new groups list" pkgname userspace [root] "new users list" - a single parameter, a space-separated list of new users to be added for this package. "new groups list" - same as above, only for groups. pkgname - a unique identifier for the package about to be installed (category, name, and version). userspace - a unique identifier of the userspace we are running in. This is something of the form USERLAND-ELIBC. For example, most GNU/Linux systems would specify GNU-glibc, while FreeBSD-based systems would use BSD-FreeBSD. root - an optional parameter, defines the system root to install into. If not provided, assumes /. 3. Revert any changes made if an install fails. This is done by calling install_fail.sh with the same arguments as add.sh. It will know what needs to be done to clean up from itself (i.e. roll back the database, remove any unnecessary users or groups, etc). 4. Display information about the managed users and groups, including which ones may be safely removed, and offer the operator a way to remove them elegantly (meaning cleaning up the database as well as removing them from the system). This is handled by the users.eselect script. signature.asc Description: PGP signature
Re: [gentoo-dev] nss_* and system users
On Fri, 16 Jun 2006 12:16:52 +0200 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: > On Friday 16 June 2006 05:03, Mike Frysinger wrote: > > nss is glibc-only, so such a solution would be inadequate > Actually this is one of the strange and rare cases that's not only > glibc's. FreeBSD can use nss too :) > Also, it seems that Solaris uses the same /etc/nsswitch.conf as well. I don't know about Darwin, though, as I don't have access to a machine. -- Mike Kelly signature.asc Description: PGP signature
[gentoo-dev] nss_* and system users
Hi, As part of my original plans for my GLEP27 implementation, I was going to have my scripts automatically add the users requested by a package (for example, the cron user), to all the passwd backends listsed in /etc/nsswitch.conf. However, in consultation with some folks, it seems that what may be more desirable is to just add users/groups to the local files/compat backends instead, and not make any changes to the remote databases. Does anyone have any strong notion of any cases where it would be excessively bad for the package manager to try adding to, say, the nss_nis backend in addition to the nss_files backend, or cases where that would be a strongly desired behavior? -- Mike Kelly signature.asc Description: PGP signature
[gentoo-dev] GLEP 27 Proposal - Feedback Requested
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I'm Mike Kelly, one of the SoC-ers. I'll be working on GLEP 27 for the summer. Right now I'm looking for some basic feedback on my proposal. In particular, I know that at one point there was a push for the user info files to be XML, but I think it may be easier to implement them as simple shell variable files (like /etc/conf.d/*), since my plan was to write the core of the implementation in shell (e.g. as an eclass). My proposal is available at: <http://www.pioto.org/~pioto/gentoo/soc2006/glep27-proposal.txt>. Any feedback would be appreciated; I wanna get things started on the right foot. Thanks! - -- Mike Kelly "Happiness adds and multiplies as we divide it with others." -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEe7wEokMzJ47YCzoRAps/AJ9pET/7BBjwiouJeIeVLPj91Dau0wCeM+jH KyJjXcpv2jMwBvNZjvYqr3w= =b+Bf -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
