[gentoo-dev] Last rites for sys-kernel-usermode-sources
# Daniel Gryniewicz d...@gentoo.org (13 Apr 2011) # Masked for removal in 30 days. Functionality is merged into and maintained in # the upstream kernel. Use any kernel (e.g. gentoo-sources) instead. sys-kernel/usermode-sources Daniel
Re: [gentoo-dev] Packages up for grabs: genstef gems special edition
On Mon, 2009-03-23 at 23:08 +0100, Peter Alfredsen wrote: Since genstef has been .away for some time, I arranged with him that I'd send a list of his ebuilds that need maintenance to be put up for grabs. This list contains all ebuilds that have no herd, at least one open bug and where genstef is the maintainer. net-misc/vde I'll take this one. Daniel
Re: [gentoo-dev] Re: bash-4.0 regression heads up (escaped semicolons in subshells)
On Sat, 2009-02-21 at 19:44 -0500, Mike Frysinger wrote: snip i'll tweak the eclasses to use quoting for now no one suggested doing any of this crap you're talking about. if you want to get all retarded, dont install the masked ebuild. i gave a heads up to people who might want to experiment so they wouldnt have to figure out weird errors. in the mean time, i tweaked a few common files so people wouldnt hit errors and could investigate even further. i guess in the future i simply wont post heads up so i dont have to listen to people whine about non-existent issues. I personally took the quoted line above to indicate that changes would be made to the tree. I can understand how confusion would occur. Dan
Re: [gentoo-dev] Proposal: disable python and perl USE flags in profile
On Tue, 2008-12-09 at 04:09 +0200, Petteri Räty wrote: Maciej Mrozowski wrote: Following advise from https://bugs.gentoo.org/show_bug.cgi?id=250179, I'm bringing it here. I think this is probably a good idea after EAPI 2 is stable and we eliminate built_with_use usage from the tree. I think having stuff build out of the box instead of dying in the middle of emerge outweighs pulling in some extra stuff with default settings. Regards, Petteri +1 Daniel
Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Mon, 2008-11-17 at 19:08 -0600, Ryan Hill wrote: On Mon, 17 Nov 2008 10:10:57 -0500 Daniel Gryniewicz [EMAIL PROTECTED] wrote: On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote: snip The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove the latest stable ebuild of an arch without the approval of the arch team or he/she will be fed to the Galrog. As long as the maintainer can pass off the maintenance of the (sometimes dozens) of ancient ebuilds that need to be kept around for that one arch to the arch team, and re-assign any resulting bugs to them, fine. Since when do we maintain ancient ebuilds kept around for an arch team now? Drop the other keywords and get on with your life. Since forever, at least in my experience. See below. Did you not read the first part of the suggestion? Yes. I was not objecting to this sequence. I was objecting to the MUST NOT NEVER EVER NOT EVEN A LITTLE BIT part. - maintainer files a stabilization request. - arch testers do their thing - arch teams gradually mark ebuild stable - maintainer pokes arm, sh, mips, ppc (only an example, relax) - mips reminds maintainer there is no stable mips keyword - ppc stables - maintainer waits - maintainer pokes arm, sh - maintainer waits - maintainer marks stable on arm, sh - maintainer removes ancient stable ebuilds that maintainer doesn't want to maintain anymore because everyone has a nice new stable ebuild. - maintainer goes out for a frosty beverage - Arch team comes back and says the new version doesn't work. - Maintainer is stuck maintaining the old version *forever*, at least potentially. Concrete example. Gnome was keyworded on an arch. A new version of gnome came out that needed hal. Hal did not work on said arch. For a long long time, we had to keep a very old version of gnome in the tree, just for that arch. This was a maintenance burden. Gnome is not just one or 2 packages. the idea is that arch teams are around to help the maintainer test on architectures the maintainer doesn't have. if the arch teams are unable or unwilling to help at the moment, that should not stop the maintainer from maintaining. also keep in mind that this only occurs after the arch teams have ample time to interject (which is why i suggested 90 days). if an arch team can't comment on a bug in 3 months (a simple i'd rather this not go stable until i can test it further should be enough) then they have IMO lost their opportunity to matter. This is not about arches just being slackers. This is about arches denying stable (or even ~) for some reason. If I cannot drop an old version of something just because the new version doesn't (and won't) work on an arch, that's really bad for me. Daniel
Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Tue, 2008-11-18 at 17:50 +, Ciaran McCreesh wrote: On Tue, 18 Nov 2008 11:57:23 -0500 Daniel Gryniewicz [EMAIL PROTECTED] wrote: This is not about arches just being slackers. This is about arches denying stable (or even ~) for some reason. If I cannot drop an old version of something just because the new version doesn't (and won't) work on an arch, that's really bad for me. What is the cost of keeping it there and not changing it? Assuming no one ever uses it? Just some sync bandwidth, emerge think time, and disk space. Not a lot. However, if people use it, and especially if they manage to get mixed versions of gnome with it (or new versions of apps built against it), then we get lots of bugs about it. Generally, we tend to get lots of interaction bugs about old versions of gnome. That's why we try to remove them. One of the biggest problems is packages not having the correct upstream deps, since upstream and most distros have moved on to new versions of gnome. There's no way we can catch those (since we, too, have moved on to new versions) and users find them and report them. Most users I've encountered don't do --deep upgrades, ever. I suppose a possible solution would be to de-keyword all those old versions for all other arches. That would reduce such reported bugs to users of the arch in question. It still leaves something unmaintained (and probably unmaintainable, except maybe on the target arch) in the tree marked as stable. That's a bad thing in-and-of itself. Daniel
Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Tue, 2008-11-18 at 15:18 -0600, Ryan Hill wrote: On Tue, 18 Nov 2008 11:57:23 -0500 Daniel Gryniewicz [EMAIL PROTECTED] wrote: On Mon, 2008-11-17 at 19:08 -0600, Ryan Hill wrote: On Mon, 17 Nov 2008 10:10:57 -0500 Daniel Gryniewicz [EMAIL PROTECTED] wrote: On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote: snip The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove the latest stable ebuild of an arch without the approval of the arch team or he/she will be fed to the Galrog. As long as the maintainer can pass off the maintenance of the (sometimes dozens) of ancient ebuilds that need to be kept around for that one arch to the arch team, and re-assign any resulting bugs to them, fine. Since when do we maintain ancient ebuilds kept around for an arch team now? Drop the other keywords and get on with your life. Since forever, at least in my experience. See below. Did you not read the first part of the suggestion? Yes. I was not objecting to this sequence. I was objecting to the MUST NOT NEVER EVER NOT EVEN A LITTLE BIT part. - maintainer files a stabilization request. - arch testers do their thing - arch teams gradually mark ebuild stable - maintainer pokes arm, sh, mips, ppc (only an example, relax) - mips reminds maintainer there is no stable mips keyword - ppc stables - maintainer waits - maintainer pokes arm, sh - maintainer waits - maintainer marks stable on arm, sh - maintainer removes ancient stable ebuilds that maintainer doesn't want to maintain anymore because everyone has a nice new stable ebuild. - maintainer goes out for a frosty beverage - Arch team comes back and says the new version doesn't work. - Maintainer is stuck maintaining the old version *forever*, at least potentially. See, here's your problem. If the arch team has issues and needs an old ebuild, the arch team is effectively the maintainer of that ebuild. Drop the other keywords if you like, and forget it exists. Leaving unmaintained ebuilds in the tree. If that's what people want, that's fine with me. Concrete example. Gnome was keyworded on an arch. A new version of gnome came out that needed hal. Hal did not work on said arch. For a long long time, we had to keep a very old version of gnome in the tree, just for that arch. This was a maintenance burden. Gnome is not just one or 2 packages. So you would rather have the ability to just drop the keywords on this arch and leave them and their gnome users up the creek? No. But I also don't want any policy that forbids me from ever removing that ebuild. Which is what the above is proposing. I don't want any kind of absolutes in policy. If you advocate absolutes in favor of the arch teams to the detriment of the maintainers, then the maintainers are going to ask for absolutes (such as I asked for above) in retaliation, and we'll have a thermonuclear meltdown. That's all. Honestly, I don't want to be a dick to the arch teams. I really don't. But I *also* don't want them (or policy) to be a dick to me. That's my whole point; that requirement of never removing the last stable ebuild, in shouting caps no less, is way too absolute, and is just going to piss people like me off. I think the whole policy should be more-or-less Don't be a dick. Take the other guy into account. Leave shouting-caps absolute requirements out of it. (For what it's worth, with my arch team hat on, I'm not in favor of letting anyone mark things stable on arches they can't test on. But that's a much lesser issue IMO than absolute prohibitions on removing ebuilds.) Daniel
Re: [gentoo-dev] zeroconf/avahi USE flag
On Tue, 2008-11-04 at 15:44 -0500, Doug Goldstein wrote: snip bonjour is Apple specific branding for zeroconf. This is another case that needs to be changed. zeroconf/avahi/howl/bonjour/mdnsresponder all need to be condensed. I agree. Let's just have zeroconf. Daniel
[gentoo-dev] Last rites for dev-cpp/{libbonobomm,libbonobouimm}
Nothing in the tree depends on the, they don't currently build, and the last upstream release was 2003. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites for dev-cpp/{libbonobomm,libbonobouimm}
On Tue, 2007-06-19 at 21:20 -0400, Daniel Gryniewicz wrote: Nothing in the tree depends on the, they don't currently build, and the last upstream release was 2003. Daniel Forgot: scheduled to be removed Jul 19; bug #182612 Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] QA issue: No stable skype in Tree
On Wed, 2007-06-13 at 17:36 +0100, Gustavo Felisberto wrote: A little background info: Right now there are three versions of net-im/skype in the tree: 1 - the 1.2 series (with a stable version) 2- the 1.3 series also with a stable version 3- the 1.4 series with a ~/hardmask version Also the skype license states that we cannot mirror it's files (this will be need later) The 1.4 series will have a version released soon that skype wants to become the standard stable version, it has many new features and better audio quality. snip Suggestions: 1- in the 19th remove skype 1.4 from the tree 2- Make 1.4 ebuilds empty and leave them on the tree and ewarn the users to use the unstable skype The first option will trigger portage errors and prompt users to open bugs until we have a stable 1.4, the second gives us a chance to explain the issue. Any alternatives? 3. Mask 1.4 on the 19th with a descriptive message. That should have the effect of 1 and 2, without breaking anything necessarily? Sounds like we have a lose-lose situation here, and the best we can do is make it not horrible. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New global use flag, xulrunner
On Wed, 2007-06-06 at 17:44 +0300, Samuli Suominen wrote: use.local.desc:dev-java/swt:xulrunner - Build native browser integration against xulrunner use.local.desc:dev-python/gnome-python-extras:xulrunner - Enable support for xulrunner instead of firefox use.local.desc:dev-util/devhelp:xulrunner - Enable support for xulrunner instead of firefox use.local.desc:gnome-extra/yelp:xulrunner - Enable support for xulrunner instead of firefox use.local.desc:media-video/totem:xulrunner - Enable support for xulrunner instead of firefox use.local.desc:net-news/liferea:xulrunner - Enable xulrunner as renderer in liferea use.local.desc:www-client/epiphany-extensions:xulrunner - Enable support for xulrunner instead of firefox use.local.desc:www-client/epiphany:xulrunner - Enable support for xulrunner instead of firefox List is likely to grow in future. Any objections? - Samuli Suominen ++ from gnome Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: stabilizing expat 2.0.0
On Fri, 2007-05-18 at 23:33 +0200, Christian Faulhammer wrote: Steve Long [EMAIL PROTECTED]: Carsten Lohrke wrote: the amd64 team is unresponsive on even trivial stabilisation request form the KDE team as well, lately. welp's been away ;) welp does not touch KDE packages... More importantly, I don't think anyone currently active on amd64 does touch KDE packages. Looking at changelogs, kugelfang is active (but not stabling amd64, it seems); wolf31o2 and cryos are away; lanius, absinthe, and jhuebel are no longer on amd64; that leaves malc, who hasn't done anything kde related since 2004, as far as I can see. I suspect the kde team and the amd64 team need to get together to find someone who can test KDE on amd64. Daniel -- [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
Re: [gentoo-dev] tests
On Tue, 2007-05-01 at 15:08 +0200, Piotr Jaroszyński wrote: Hello, There was some discussion about forcing/not forcing tests in EAPI-1, but there was clearly no compromise. Imho, tests are very important and thus I want to discuss them a little more, but in more sensible fashion. Firstly each test can be(not all categories are mutually exclusive): - not existant - non-functional - not runnable from ebuild - useful but unreasonable resource-wise - useful and reasonable resource-wise - necessary - known to partially fail but with a way of skipping failing tests - known to partially fail but with no easy way of skipping failing tests Is that list comprehensive? Secondly we must answer the question how precisely we want to distinguish them, so users/dev can choose which categories of tests they want to run. What comes to mind is: - run all tests - run only necessary tests - run only reasonable tests - don't run tests at all Again, is that list comprehensive? Don't forget tests that have heavy requirements to run. Many gnome tests, for example, need a virtual X to run, which puts a new set of DEPENDS requirements on your system. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] tests
On Wed, 2007-05-02 at 01:32 +0200, Marius Mauch wrote: I'd approach it a bit different: Before creating fixed classification groups I'd first identify the attributes of tests that should be used for those classifications. a) cost (in terms of runtime, resource usage, additional deps) b) effectiveness (does a failing/working test mean the package is broken/working?) c) importance (is there a realistic chance for the test to be useful?) d) correctness (does the test match the implementation? overlaps a bit with effectiveness) e) others? There is one serious problem with this: Who's going to do the work to figure all this out for the 11,000 odd packages in the tree? This seems like a *huge* amount of work, work that I have no plan on doing for the 100-odd packages I (help) maintain, let alone the 4-10 different versions of each package. I highly doubt other maintainers want to do this kind of work either. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] tests
On Wed, 2007-05-02 at 01:12 +0100, Stephen Bennett wrote: On Tue, 01 May 2007 19:46:56 -0400 Daniel Gryniewicz [EMAIL PROTECTED] wrote: There is one serious problem with this: Who's going to do the work to figure all this out for the 11,000 odd packages in the tree? This seems like a *huge* amount of work, work that I have no plan on doing for the 100-odd packages I (help) maintain, let alone the 4-10 different versions of each package. I highly doubt other maintainers want to do this kind of work either. Last I heard the intention was to tie it to the EAPI=1 bump, so that packages can be updated one by one as they move to the newer eapi. Current (ie EAPI=0) ebuilds will continue to function as they have done. Sure, but now you're requiring me to go through all that extra work if I want any of the benefits of EAPI=1. Or alternatively, dooming us to support EAPI=0 forever, since I don't want to do that work. Or, third option, is that everyone marks their packages as low priority tests, don't run them just to switch to EAPI=1, and we have no gain over what we have now. Honestly, tests are nice, but too many of them are broken upstream, and we are not (and should not be, IMO) in the position of fixing them all. If a developer wants to work with her upstream to fix the tests in her packages, great and more power to her. Most of us are swamped just supporting them, let alone fixing test cases. You really need an upstream who cares a lot about tests for the tests to be meaningful and work. Lots of upstreams don't currently care, and have inherited obsolete and (now) broken tests from previous maintainers. I think this thread in general overestimates the value of tests in packages. I think we will find, if we go through the effort, that more of them are useless and/or broken than are useful. My 2 cents. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] That time again...
On Wed, 2007-04-25 at 20:12 -0400, Michael Cummings wrote: Any other cool updates in the last few weeks? (it's been 20 days since the last time I started this thread - at this rate, we might make enough input to make Chris' job on the gwn easier). For Gnome, 2.18.1 is almost entirely in the tree, but still masked pending the unmasking of hal (which has one bug left, last I checked). 2.19.1 is going into the overlay slowly. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] forwarding a video
On Mon, 2007-03-05 at 12:18 +0100, Marijn Schouten (hkBst) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: no, i'm not directing this at any one person as i dont believe singling out any one person addresses anything in our case a video sent to out by a good mate http://video.google.com/videoplay?docid=-4216011961522818645 -mike what a nice flash website, If you'd bothered to look, there's a nice download link on the right that downloads as an avi. You don't even need flash installed. All you need to do is get past the tagging of the download as being for Windows/Mac. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: What do you think about removing gtk-1.2 theme engines from tree?
On Sun, 2007-02-25 at 21:31 -0600, Ryan Hill wrote: Andrej Kacian wrote: It makes sense slowly removing *applications* depending on gtk1. Themes should go last, along with gtk1 itself. Gtk1 is already ugly enough, do you want it to be even more ugly? Point, set, and match. Much as I hate gtk1, I agree with this. Leave the themes as long as they're working and there's apps. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] let's clear things up (was Slacker archs)
On Tue, 2007-02-20 at 08:11 -0500, Stephen P. Becker wrote: On Tue, 20 Feb 2007 01:35:32 + Ciaran McCreesh [EMAIL PROTECTED] wrote: It is widely perceived that Gentoo has a huge problem with slacker archs cluttering up the tree and making maintainers' work harder. Clearly, something needs to be done about this. snip Wow, I almost don't know where to begin. The amount of FUD, misinformation, and outright lies floating around all of this bullshit is astounding. snip again I'd like to chime in here, if I may, with some personal experience. I've been involved with arch keywording from both sides (being in the amd64 herd, and being the current gnome lead), and I have to say that it's definitely blown out of proportion. Yes, keyword bugs slip through the cracks. Some of my gnome keyword bugs hang around forever; sometimes, in my bug sweeps for amd64, I find keyword bugs that have been hanging around forever. It happens. However, there have been a number of cases recently for gnome where we wanted to punt old versions of gnome. We like to only keep 1-2 old versions around, so we remove whole sets of packages every 6-8 months. In this, we're probably close to unique. Many of these are newest keyworded versions on some arch or other. Generally, all the arches have been responsive to the problem, either by keywording newer versions, or by agreeing to drop keywords. Again, there's the odd case; but that seems to mostly be oversight. Summary: I don't see a real problem with any arch, mips included, either from the arch side or from the gnome side. There's more gnome cruft in the tree from us failing to clean intermediate versions up than there is from slacker arches. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GNOME 1.x and GNOME 1.x dependent package masking
On Sat, 2006-11-11 at 22:55 +0200, Alin Nastac wrote: Paul de Vrieze wrote: On Friday 10 November 2006 16:28, Daniel Gryniewicz wrote: On Fri, 2006-11-10 at 08:56 +0100, Marius Mauch wrote: Ok, the list definitely isn't accurate. If there is a legitimate reason to mask sylpheed-claws-1.x you also have to mask it's reverse deps. However I'm still waiting for the explanation why it is on that list. (I don't mind if it's masked for a good reason, but I need to know that reason). There is no immediate reason, of course. However, gtk+-1 and glib-1 will be removed as soon after the big cleanup as is feasible, and sylpheed-clasws-1.x is a gtk+-1 app, and therefore must go as well. I didn't generate the list, but my understanding was that it was intended to include all packages with a hard dep on gtk+-1, in addition to gnome 1.x. Gtk1 actually is broken for --as-needed. It's linking is broken thanks to a libtool which refuses to link against a non-installed libgdk. I think gtk+-1.2.10-r12 solved this problem. Hope you guys aren't seriously considering dropping gtk+1. As long as we have packages that depend on it (packages that has nothing to do with gnome herd/team), gtk+1 should stay in the tree. We (gnome) are not going to maintain gtk+-1. We would very much prefer it get removed. If some other person or group wants to maintain it, I guess it's fine with me; it will only cause Jakub and company headaches for re-assigning all the bugs that mistakenly get assigned to gnome. Note that maintaining it basically means being upstream, as there is no upstream for it. Daniel signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GNOME 1.x and GNOME 1.x dependent package masking
On Fri, 2006-11-10 at 08:56 +0100, Marius Mauch wrote: Ok, the list definitely isn't accurate. If there is a legitimate reason to mask sylpheed-claws-1.x you also have to mask it's reverse deps. However I'm still waiting for the explanation why it is on that list. (I don't mind if it's masked for a good reason, but I need to know that reason). There is no immediate reason, of course. However, gtk+-1 and glib-1 will be removed as soon after the big cleanup as is feasible, and sylpheed-clasws-1.x is a gtk+-1 app, and therefore must go as well. I didn't generate the list, but my understanding was that it was intended to include all packages with a hard dep on gtk+-1, in addition to gnome 1.x. Daniel signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Orphaned packages
On Mon, 2006-09-18 at 20:00 +0100, Gustavo Felisberto wrote: The list of orphans is: net-misc/blogtk I'll take blogtk. Daniel signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
On Wed, 2006-09-13 at 19:47 +0200, Benno Schulenberg wrote: Ciaran McCreesh wrote: * If no existing file with the intended target name exists, or if the existing file has identical content to the file to be installed, the file to be installed is installed as normal. I would much prefer new files to be treated as if replacing an existing zero length file. When something is installed into /etc, etc-update should alert me to this, because logically speaking a new configuration file is a big configuration change. Ideally the package manager would unconditionally respect the config protection area, and it should be up to tools like etc-update to (configurably) automerge new files and identical files, just like it can be configured to automerge trivial/comment changes. I disagree. If there is a sane default configuration for something (which is most things), I want it installed, so it works out of the box. I don't want to have to fiddle with config files to get sshd up and running. Obviously, if there's no sane default configuration (samba?), then the installed configuration shouldn't do anything. Daniel signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
On Sun, 2006-07-30 at 15:50 +0200, Paul de Vrieze wrote: On Friday 28 July 2006 20:51, Donnie Berkholz wrote: Robert Cernansky wrote: If I have some application that is not included in portage why I decide to make an ebuild? Because I hope that then it will be accepted and included to portage, so maintained by developers (big thanks for this). If I have to take care of package + ebuild + dependencies, I'll rather choose not to make an ebulid but compile package right from .tar.gz archive. Many people disagree with you here, that's why overlays exist. Somebody wants to use Portage to manage ebuilds that aren't yet in the actual tree. I'm one of those. Portage namely is also a package manager allowing what using the tarbal method does not: file tracking and deinstallation. Paul FWIW, my company uses Gentoo and overlays extensively to manage our workstations and testbeds. The packages we have are not suitable for inclusion in portage (for a number of reasons), and we have no intention of ever submitting them. Overlays are a *great* way of customizing a local network of boxes to be different than upstream Gentoo for whatever reason. I, personally, find this to be a more useful function than a place to hold ebuilds not-yet in portage (although, I do that also). -- Daniel Gryniewicz Gentoo AMD64 Team / Gentoo Gnome Herd / Gentoo Kernel Herd / Gentoo Printing Herd AMD64 Operational AT Lead signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Off with your heads!
On Thu, 2006-07-06 at 20:46 -0600, Steve Dibb wrote: @devs, If your blog is being aggregated on Planet Gentoo / Universe, it's time to send us a copy of your smiling face. I'm putting out a request for some hackergotchis. Really, you don't want just a few of us to have all the fun, do you? Here's mine. Daniel dang.png Description: PNG image signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Virtualization Herd
On Mon, 2006-07-03 at 22:28 +0200, Benedikt Böhm wrote: On Monday 03 July 2006 21:56, Nick Devito wrote: Okay, in that case, extend the vserver herd to include a larger range of virtualization stuff, including Xen, Bochs, and so on. It just seems more fitting to group those packages together. not really, bochs, qemu and vmware is emulation, merely used in virtualization environments uml and xen do run with VMMs and don't share anything with OpenVZ/Linux-VServer uml and xen could be integrated into the VPS project (with a different herd) but i don't know what their maintainers are thinking about this UML is not complicated or hard to maintain. I'm fairly happy maintaining it with the help of the kernel herd, and (being a linux kernel port) I think it really belongs in kernel, not in virtualization or vmm or vserver, or whatever. Maybe if there were some projects for full virtual server setups that could use xen or uml or vmware or ... as it's underlying hosting service, that could be useful, but just for maintenance, I don't think it's really necessary. I'm open to arguments in favor of such a project, tho, if people have real plans. Certainly, an easier way to generate and maintain root filesystems for UML would be nice. Daniel signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Virtualization Herd
On Mon, 2006-07-03 at 20:15 -0600, Nick Devito wrote: Generating root filesystems for UML and Xen are basically the same process. I've heard of domi, but, bleh, I never could get it to work. I usually just make my images in chroot, and that usually works well. But, since the images are *basically* the same, that means it would be possible to use the jailtime images, unless you are running on a 64-bit arch. Then, in that case, least with gentoo, running a 64-bit kernel and 32-bit userland doesn't work for long (first glibc (re)compile, and the whole thing borks out). I'm on amd64, as my primary arch. I generally use a chroot, as well, and have knocked up some scripts to help me, but a well-designed package to do it would be very helpful. Maybe I'll write one... Several patches just went into -mm to make UML work well as a 32-bit process on 64-bit arches, which would make the root image a pure 32-bit image. Daniel signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] sys-kernel/usermode-sources facing removal
On Sun, 2006-05-07 at 14:40 +0100, Daniel Drake wrote: Hi, I've been wrangling with usermode-sources maintenance for some time now, but I don't have any interest in it and have no clue how it works. Any volunteers? If not, this package will be removed in 30 days. It will be put in package.mask sometime over the next day or two due to the open security bugs. I'll take it over. I'm a UML user, both personally and for work. Daniel signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: shoving utils from xpdf to poppler...
On Wed, 2005-12-28 at 17:18 +0100, Carsten Lohrke wrote: Hi Daniel, what you've done breaks runtime dependencies, if not for other packages so at least for KDE. Such a change should be announced on the gentoo-dev mailing list before you do it. Also a tracking bug to coordinate stabilization of new ebuild revisions will be needed, once the changed ebuilds go stable. Moreover you're not free to put a 200k patch into cvs, 20k is the accepted maximum. It's not supposed to break runtime dependencies. Everything that was installed before is installed now, in the same location. I therefore didn't feel it should case problems and that it wouldn't require coordination. Could you please elaborate, possibly with a bug? I'll fix the patch. I didn't see repoman complain, but I may have just missed it. Sorry about that. Daniel signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] app-admin/gwcc being removed
On Thu, 2005-09-22 at 16:33 -0400, Daniel Gryniewicz wrote: Hi, all. app-admin/gwcc has security issues, and has been unmaintained upstream for 3 years. The Gnome herd is no longer interested in maintaining it. I've masked it, and will remove it in a couple of weeks, if no one steps forward to maintain it. Daniel Last call for gwcc. If no one steps up, I'll remove it in the next couple of days. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff
On Mon, 2005-09-12 at 19:53 -0400, Stephen P. Becker wrote: Let me clarify here. I'm not concerned about ATs having more privileges at all. I just want to know why if we're making them full developers for all intents and purposes, we don't go the extra step and get them commit access after a probationary period? It seems like this is supposed to be the end goal anyway. Basically, I feel like this GLEP goes outside the bounds of what I think of when somebody mentions the arch testers. Maybe it's just me though. -Steve For once agreeing with Ciaran, the less people who aren't seasoned developers with commit access the better? Some don't want commit access, most of them really don't need it. Those that want it can ask for it and take any requisite quizzes. You also have misunderstood my point. I've always been under the impression that ATs are regarded highly enough that they could easily become members of the dev team. With that in mind, *if* we are going to give them nearly every privilege an arch dev has anyway, why not go one step further and just make them an official arch dev and avoid unnecessary bloating of categories with respect to Gentoo dev-team membership? They don't even need commit access if they don't want it. We currently have developers without tree access already in any case. Should we reclassify those folks as well? You're somehow implying that being an AT is not as good as being a dev. My understanding is that this GLEP is supposed to make AT as good as being a dev, but with a different role, one that doesn't need commit access. If the people involved decide they want to become committing devs, it also make it easier to make that transition. If they don't want to commit, they can stay as an AT. Besides, if you want to get technical, our entire userbase are arch testers to some extent. They run Gentoo, report bugs, unmask packages locally, submit keywording requests to bugzilla, etc. The good users make Gentoo a good distribution by providing feedback on bugzilla. The very best of these folks are typically tapped for membership in arch teams. I agree. What the AT program has done for amd64, tho, is give us a base of users that have known skills (they were recruited and passed the ebuild quiz) and have a known process they follow for testing and marking bugs, so that the devs have a much easier time staying on top of keywording issues. We've basically said that we trust the ATs to know how to test a package, and we'll take their word for it that it works. It's been very useful for us, and we think it will be useful for others. Daniel (former AT) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 41: Making Arch Testers official Gentoo Staff
On Tue, 2005-09-13 at 00:05 +0100, Daniel Drake wrote: Simon Stelling wrote: This has been in the todo-list for quite a while, but finally it's done. I'm curious what you think of it. I'm curious how much change this would involve for the people involved. Perhaps you could explain how the current system works (I presume from reading the GLEP that they _don't_ currently have commit access and havent taken any quizzes)? How do they get their keywording work into the tree? Thanks, Daniel They don't have commit access (or any CVS access at all) but have taken the ebuild quiz, the first dev quiz. They have the ability to KEYWORD bugs in bugzilla, that the only special ability they get (other than voice in #-amd64-dev) currently. Daniel (former AT) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
On Thu, 2005-09-01 at 12:10 -0500, Grant Goodyear wrote: The recent discussion about having a real x86 arch team and combining the x86 and amd64 keywords was both interesting and provocative. Of course, this is the sort of thing that the GLEP system was meant for. Now that we have a new council that (I hope) will be active in approving or rejecting GLEPs, perhaps someone should be writing a GLEP about combining x86 and amd64? -g2boojum- Just out of curiousity, what makes people think that the amd64 team will sit still for having all of x86 foisted off on them? -- Daniel Gryniewicz Gentoo AMD64 Team -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: dang
On Sun, 2005-05-22 at 09:59 -0500, Homer Parker wrote: On Sun, 2005-05-22 at 00:57 -0500, Jason Huebel wrote: It's with pleasure that I announce a new developer: Dang. Dang has been working as an Arch Tester for AMD64 for a while now and has proven himself to be an asset to the team. So we felt it would be good to officially make him a developer. He'll be helping with amd64 bug squashing of course, along with helping out the gnome herd. Welcome dang! /me needs to recruit more ATs... But, that's ok.. Congratz Dan!!! Thanks, all. (And yes, I've heard all the jokes before... :) ) Daniel -- gentoo-dev@gentoo.org mailing list
