Re: man-db without cache update (no cron or systemd *.timer)
On Mon, Oct 20, 2014 at 3:24 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 20.10.14 15:08, Matthew Miller (mat...@fedoraproject.org) wrote: On Mon, Oct 20, 2014 at 08:56:19PM +0200, Lennart Poettering wrote: But again, I am not sure I understand what is going on here. Is systemd now optional in Fedora? I guess to some degree everything is optional in one way or another. It's certainly the init system we are using. I think the context is in cases where the packages are used without an init system, systemd or otherwise — the main case being single-process (or at least single-parent-process) application containers. (I'm also looking forward to systemd as a process manager inside e.g. Docker for more sophisticated multi-process applications which for whatever reason want to be in the same container, but that's a different use case.) While I can see the reason why you want this I really find this quite dubious in general. Much of our stack relies on /run and all those other facilities, of our general execution environment to be properly initialized, cleaned up and maintained. We do this with tmpfiles snippets, early-boot services, cron jobs, timer units, and so on and so on. Just saying no to these things, ignoring them and not executing them will only get you so far. It also creates in a way a new execution environment, unless you perfectly replicate the execution environment from your container manager, knowing all components in play, including all libraries and whatever else. A container is _absolutely_ a new execution environment, and the whole advantage of it, to most users, is that it's more lightweight than a complete virtualized OS environment, partly because you do not have to load an entire operating system. There is enough abstraction to make running a distinct set of packages (even a different distro/version) reasonable, but with the luxury of not having to deal with network setup, filesystem checks and mounts, initialization of cgroups, and all those other fun things, because a combination of systemd, docker, and other host services have done all the work. And things like logging the output of the service, restarting it if it crashes, etc. can easily be taken care of by making a systemd unit for the container in the *host* OS. I'm not sure what to make of your comment about knowing all component in play, including all libraries and whatever else, because that seems to indicate that you are worried about dependency closure inside the container, which is the responsibility of whomever built the container. Assuming they did so in a sane way with a package management system, they will be fine from that standpoint. If you really intend to make Fedora in general workable without providing support for tmpfiles bits, without cron jobs, without timer units, without setting up the execution environmnt the same way as on a classic Fedora boot, then please make this a clear goal of Fedora. But just trying to add this through the backdoor sounds wrong. First, I would say that the community has rammed this requirement right through the front door. People _are_ running things this way. This is not some theoretical future feature; it's an adaptation to existing use cases. Second, things like tmpfile cleanup and log rotation are not requirements for a service to function. This is why, for example, none of the many packages which put file in /etc/logrotate.d/ actually require logrotate. Sure, it's nice if it's there, but a user is also free to come up with their own procedure for rotating logs, or to not rotate them at all. I would be interested to know some other concrete examples of concerns about the execution environment that would actually impact the functionality of a service in a container. I won't claim that such things don't exist, but tmpfile clean-up and log rotation are poor examples, IMHO. Honestly though, I really don't think this is really such a good idea. You make things much more complicated for developers that way. We *want* developers to make use of the OS services we provide after all. It makes the system more uniform and more accessible to our admins and users. If you take the vast majority of the facilities that we provide for software away, then very little remains, you devalue the OS itself. We are not taking these things away. Matt even mentioned that he would like to see us provide containers with systemd inside them as an option, but it will necessarily be a more heavyweight option than the current use case which has become so common, and it will be uninteresting to many users. The value in these OS services of which you speak are significant in the host OS, which has to manage the orchestration of many containers in this new world. For the developer (who is *not* a sysadmin) the value of these services is quite minimal. They want to build an app, and run the app, and to have as little concern as possible for the
Re: [ACTION REQUIRED][FINAL NOTICE] Retiring packages for Fedora 21 v4
On Jul 2, 2014 11:33 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Jul 01, 2014 at 07:55:42PM +0200, Till Maas wrote: The following packages are orphaned or did not build for two releases and will be retired when Fedora (F21) is branched, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life According to https://fedoraproject.org/wiki/Schedule branching will occur on 2014-07-08. The packages will be retired starting 2014-07-04. If you intend to claim a package, please take it now. Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Package(co)maintainers === [...] mule orphan, tspauld98 The upstream developer turned up on devel last week wishing to maintain this package. He is not a packager yet. Can it be saved? I noticed this yesterday and took it back for now. (Alternatively, perhaps it could do with a re-review ...) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mule Orphaned Package
On Mon, Jun 30, 2014 at 1:54 AM, Christopher Meng cicku...@gmail.com wrote: How many patches needed for the latest mule? Are these[1] merged already? I'm not sure how many of those will be needed. Several of them were for building the old version of mule against newer dependencies (like spring 3.1), and newer versions of mule already support the newer deps. Other patches (like the one to disable spring-jms) were because certain deps were missing from Fedora, and can be removed if the dep is now present in the distro. Andy [1]---http://pkgs.fedoraproject.org/cgit/mule.git/tree/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mule Orphaned Package
On Sun, Jun 29, 2014 at 10:59 AM, tspaul...@yahoo.com tspaul...@gmail.com wrote: Hi All, I'm a mule developer and fedora user. Recently, I noticed that the version of mule packaged with fedora is not only very behind the current upstream version but it is also orphaned. I'd like to take over maintaining the packaging of mule on fedora if there are no objections. This was originally my package; it was packaged as part of the effort to get Eucalyptus into Fedora a few releases ago, and at the time I packaged something close to what upstream Eucalyptus code bundled as a dependency. Thankfully, Eucalyptus updated most of their dependencies in 4.0, so there should be nothing depending on the old version now. Andy Thanks, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Attempting to contact three unresponsive maintainers
On Jun 18, 2014 5:28 PM, Kevin Fenzi ke...@scrye.com wrote: Greetings, we've been told that the email addresses for three package maintainers are no longer valid. I'm starting the unresponsive maintainer policy to find out if they are still interested in maintaining their packages (and if so, have them update their email addresses in FAS). If they're not interested in maintaining or we can't locate them I'll have FESCo orphan the packages so that others can take them over. If you have a way to contact any of these maintainers, please let them know that we'd appreciate knowing what to do with their packages. Thanks! Maintainers: * tgraf - former email address tg...@redhat.com https://admin.fedoraproject.org/pkgdb/packager/tgraf/ Point of contact: 3 Co-maintainer:2 Watched: 0 * sadmac - former email address cdah...@redhat.com https://admin.fedoraproject.org/pkgdb/packager/sadmac/ Point of contact: 1 Co-maintainer:0 Watched: 1 If you still haven't located cdahlin, wwoods can probably help. * ssp - former email address sandm...@redhat.com https://admin.fedoraproject.org/pkgdb/packager/ssp/ Point of contact: 39 Co-maintainer:254 Watched: 0 If we don't hear anything in a week, we will be removing their acls and will need to find new point of contacts, etc. Thanks, kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Trimming (or obsoleting) %changelog?
On Tue, Apr 16, 2013 at 9:25 PM, Dan Fruehauf malko...@gmail.com wrote: Hey, I tend to be against trimming. I was just looking at the binutils changelog (goes back to 1997): $ rpm -q --changelog binutils | wc -c 54984 That's around 50K, and compressed (RPMs are compressed): $ rpm -q --changelog binutils | gzip | wc -c 15552 15K is nothing. Really. I like to see the whole history of a package, it's nice and fun. Perhaps other packages has larger changelogs. I guess common sense is what we should use, but generally speaking I'd say don't trim, as it doesn't really matter and it's cleaner to have a full changelog, rather than a story which starts somewhere in the middle. Just out of curiosity, what packages have huge changelogs? A lot of them are the ones you'd expect -- toolchain-related packages that have been around forever like gcc, gdb, glibc. SELinux related packages have pretty huge changelogs, too. I think the winner for greatest changelog growth rate is likely rhc (the OpenShift client): over 350 entries in less than two years. :-) Andy BR Dan Fruehauf. On Mon, Apr 15, 2013 at 10:43 PM, Rex Dieter rdie...@math.unl.edu wrote: Richard Hughes wrote: Is there any guidance as when to trim %changelog down to size? Some packages have thousands of lines of spec file dating back over 15 years which seem kinda redundant now we're using git. To me, common sense dictates that it's perfectly ok to trim the length of the changelog as long as items that are relevant to the current release are kept intact. Use your best judgement where that position lies. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages in need of new maintainers UPDATED LIST
On Fri, Oct 5, 2012 at 1:32 PM, Jon Ciesla limburg...@gmail.com wrote: -- Forwarded message -- From: Przemek Klosowski przemek.klosow...@nist.gov Date: Fri, Oct 5, 2012 at 12:06 PM Subject: Re: Packages in need of new maintainers To: devel@lists.fedoraproject.org On 10/03/2012 02:23 PM, Jon Ciesla wrote: As a result of FESCO ticket 952*, Lubomir Rintel's 200+ packages are in need of new maintainers. Under normal circumstances we'd simply orphan them all, but given the large number we want to handle this in a more orderly fashion. Please reply to the list with any requests for ownership changes, and I'll complete them on a first-come, first-served basis Could you do an updated list of packages that are still looking for owners? I'll take these java packages: derby -- Relational database implemented entirely in java ezmorph -- Object transformation library for Java jcommon -- JFree Java utility classes jfreechart -- Java chart library joda-time -- Java date and time API json-lib -- JSON library for Java rhino -- JavaScript for Java tagsoup -- A SAX-compliant HTML parser written in Java testng -- Java-based testing framework xom -- XML Pull Parser xpp3 -- XML Pull Parser -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION NO LONGER REQUIRED] Retired packages for F-17
On Mon, Feb 6, 2012 at 3:09 PM, Bill Nottingham nott...@redhat.com wrote: As stated eariler, the following packages have been retired in F-17 (and therefore rawhide), due to either failing to build, or not having maintainers. ... junit4 ... Whoa there.. .this one wasn't in any of the previous emails... perhaps it was orphaned very recently? It's a BuildReq for most of the java universe, so probably best to give people one more shot at claiming it, if possible. --Andy Have a nice day. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2012-01-23 at 18UTC)
On Mon, Jan 23, 2012 at 7:27 AM, Kevin Fenzi ke...@scrye.com wrote: On Mon, 23 Jan 2012 09:26:26 +0100 Vít Ondruch vondr...@redhat.com wrote: Dne 23.1.2012 03:40, Cole Robinson napsal(a): Hi Kevin, I filed a feature page 2 Fridays ago that's been sitting in ReadyForWrangler since: https://fedoraproject.org/wiki/Features/OpenStack_Horizon Anything I can do to get that on track for discussion/approval? There are also a couple other openstack features that are similarly lying in wait AFAICT (page owners cc'd): https://fedoraproject.org/wiki/Features/OpenStack_Quantum https://fedoraproject.org/wiki/Features/OpenStack_using_Qpid Thanks! Cole Hi Kevin, I would also like to see reviewed our Ruby 1.9.3 [1] feature submission, since it is blocking our progress. Vit [1] https://fedoraproject.org/wiki/Features/Ruby_1.9.3 It seems our feature wrangler was/is not only traveling, but sick and didn't get these moved. Until this morning. ;( Since feature freeze is tomorrow, I'd like to see us finish all of them that are now correctly in ready for fesco or we could do some in a special session, or just next week. #758 F17 Feature : Eclipse Juno - https://fedoraproject.org/wiki/Features/EclipseJuno #759 F17 Feature: Opa - https://fedoraproject.org/wiki/Features/Opa09 #760 F17 Feature: Internationalization support for additional Indian languages - http://fedoraproject.org/wiki/Features/Additional_Indic_Langs #761 F17 Feature: DNSSEC on workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations #762 F17 Feature: Eclipse Juno - https://fedoraproject.org/wiki/Features/EclipseJuno #763 F17 Feature: Ext4 support beyond 16T - https://fedoraproject.org/wiki/Features/F17Ext4Above16T #764 F17 Feature: Haskell Platform 2011.4 - https://fedoraproject.org/wiki/Features/HaskellPlatform2011.4 #765 F17 Feature: New Features of IPA v3 - https://fedoraproject.org/wiki/Features/IPAv3NewFeatures #766 F17 Feature: Java 7 - https://fedoraproject.org/wiki/Features/Java7 #767 F17 Feature - New mkdumprd for kdump - https://fedoraproject.org/wiki/Features/NewMkdumprd #768 F17 Feature: Virtualization Sandbox - https://fedoraproject.org/wiki/Features/VirtSandbox #769 F17 Feature: numad (Non-Uniform Memory Alignment Daemon) - https://fedoraproject.org/wiki/Features/numad #771 F17 Feature: OpenStack Quantum - https://fedoraproject.org/wiki/Features/OpenStack_Quantum #772 F17 Feature: OpenStack using Qpid - https://fedoraproject.org/wiki/Features/OpenStack_using_Qpid #773 F17 Feature: Ruby 1.9.3 - https://fedoraproject.org/wiki/Features/Ruby_1.9.3 #774 F17 Feature: SELinux Deny Ptrace - https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace #775 F17 Feature: PrivateTmp services - https://fedoraproject.org/wiki/Features/ServicesPrivateTmp kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Sorry to be running right up against the deadline, but I just got the green light last week to move ahead with Eucalyptus in the F17 timeframe, so I've set my feature to ReadyForWrangler https://fedoraproject.org/wiki/Features/Eucalyptus --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
I have taken these packages: avalon-framework avalon-logkit bcel bsf jakarta-commons-httpclient On Fri, Jan 13, 2012 at 2:37 PM, Bill Nottingham nott...@redhat.com wrote: Bill Nottingham (nott...@redhat.com) said: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 17. If these packages are not claimed, they will be retired before we branch off of rawhide on February 7. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Java 7 for Fedora 16
On Wed, Aug 3, 2011 at 6:00 PM, Deepak Bhole dbh...@redhat.com wrote: * Douglas Myers–Turnbull dmyersturnb...@gmail.com [2011-07-25 20:53]: I was planning to do this myself .. glad you started it :) I can take over the Feature and doing all the work if you're fine with it... Please do! The only work I've done (literally) is on the feature page, but feel free let me know if you need anything from me. Hi Douglas, Thank you once again for creating the page. I have started updating it and will add docs and other links tomorrow: https://fedoraproject.org/wiki/Features/Java7 For anyone and everyone interested, a Java 7 build is now available in the Fedora 16. I will build for rawhide in the coming days as well: http://koji.fedoraproject.org/koji/buildinfo?buildID=257034 Cheers, Deepak After some discussion on #fedora-java over the past 24 hours, I was asked to continue the discussion here regarding the implications of openjdk 6 and 7 coexisting in F16. Right now, java packages are being built for F16 using openjdk 7, and if they are built without target=1.6, they will fail to load under openjdk 6. (One simple example of this is xalan, see https://bugzilla.redhat.com/show_bug.cgi?id=733686 ). Some possible solutions proposed over IRC: 1) Blacklist openjdk 7 from build roots for f16 -- this means that it doesn't get tested very well, though. 2) Ensure all java packages use target=1.6 -- there's no standard way to do this across ant, mvn, javac, etc. though. You could check for 1.7 bytecode at the end of a build, but packages would still need to be individually fixed. 3) Drop openjdk 6 from F16 entirely It was also mentioned that Fedora is beginning to include some packages which build much more cleanly on openjdk 7 than they do on 6, so enforcing openjdk 6-only build roots might break some things. Other suggestions are welcome. I don't have a strong opinion about this, just a strong interest in having a sane Java environment in F16. Thanks, --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: build dependency loop in guava / gwt
I talked to jlaska about this, but his response was: I maintain a gwt package in a private repo since it's a %buildrequires for autotest. However, I've given up on attempting to package the world of java just since it's way beyond my skill level. so in it's current state, it contains a slew of bundled JARs that would never be accepted as an official Fedora package. so my original question about how to handle the guava-gwt dependency loop still stands. --Andy On Thu, Aug 4, 2011 at 1:32 PM, Andy Grimm agr...@gmail.com wrote: I did see a spec file at http://jlaska.fedorapeople.org/ , but it didn't look functional. That page is much more informative, thanks! On Thu, Aug 4, 2011 at 11:06 AM, Johannes Lips johannes.l...@googlemail.com wrote: Hi, are you aware of the effort James Laska already put into this? http://fedoraproject.org/wiki/User:Jlaska/autoqa_package_dependencies If you already have talked to him, forget about this e-mail ;-) -Johannes On Thu, Aug 4, 2011 at 4:43 PM, Andy Grimm agr...@gmail.com wrote: Hi, everyone. I'm looking into packaging gwt (Google Web Toolkit) 2.3 and guava r09. In this new version (unlike Fedora's current version r05), the full guava build requires gwt. gwt, of course, requires guava to build. So, I'm looking at doing the following: * build guava without guava-gwt (so that gwt is not required for the build) * build gwt (which has a whole pile of other problems, but that's for another day) * build guava-gwt as a completely separate package, using essentially the same upstream source as the guava package Is this the accepted way to go about this? or should I actually be using a bootstrap guava package to build gwt, and then rebuild guava with a guava-gwt subpackage (thus leaving a build dependency loop). --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
build dependency loop in guava / gwt
Hi, everyone. I'm looking into packaging gwt (Google Web Toolkit) 2.3 and guava r09. In this new version (unlike Fedora's current version r05), the full guava build requires gwt. gwt, of course, requires guava to build. So, I'm looking at doing the following: * build guava without guava-gwt (so that gwt is not required for the build) * build gwt (which has a whole pile of other problems, but that's for another day) * build guava-gwt as a completely separate package, using essentially the same upstream source as the guava package Is this the accepted way to go about this? or should I actually be using a bootstrap guava package to build gwt, and then rebuild guava with a guava-gwt subpackage (thus leaving a build dependency loop). --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: build dependency loop in guava / gwt
I did see a spec file at http://jlaska.fedorapeople.org/ , but it didn't look functional. That page is much more informative, thanks! On Thu, Aug 4, 2011 at 11:06 AM, Johannes Lips johannes.l...@googlemail.com wrote: Hi, are you aware of the effort James Laska already put into this? http://fedoraproject.org/wiki/User:Jlaska/autoqa_package_dependencies If you already have talked to him, forget about this e-mail ;-) -Johannes On Thu, Aug 4, 2011 at 4:43 PM, Andy Grimm agr...@gmail.com wrote: Hi, everyone. I'm looking into packaging gwt (Google Web Toolkit) 2.3 and guava r09. In this new version (unlike Fedora's current version r05), the full guava build requires gwt. gwt, of course, requires guava to build. So, I'm looking at doing the following: * build guava without guava-gwt (so that gwt is not required for the build) * build gwt (which has a whole pile of other problems, but that's for another day) * build guava-gwt as a completely separate package, using essentially the same upstream source as the guava package Is this the accepted way to go about this? or should I actually be using a bootstrap guava package to build gwt, and then rebuild guava with a guava-gwt subpackage (thus leaving a build dependency loop). --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Issues with preupgrade F15B?
On Fri, May 13, 2011 at 9:10 AM, Philip A. Prindeville philipp_s...@redfish-solutions.com wrote: On 05/13/2011 12:44 AM, Frank Murphy wrote: On 13/05/11 05:24, Philip A. Prindeville wrote: snip I'm not seeing any interest in resolving this, so I'm going to go ahead with a yum update instead. Too bad, the problem was 100% reproducible, so it might have been a good source of information into this problem. -Philip Did you file a bugzilla report? It's not clear what to file it against. FWIW, I just tried to upgrade my laptop and got the same problem. I'm going to debug a little bit and see what I can find. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Issues with preupgrade F15B?
Correction, it looks like it was indeed impatience on my part. On May 13, 2011 3:21 PM, Andy Grimm agr...@gmail.com wrote: On Fri, May 13, 2011 at 9:10 AM, Philip A. Prindeville philipp_s...@redfish-solutions.com wrote: On 05/13/2011 12:44 AM, Frank Murphy wrote: On 13/05/11 05:24, Philip A. Prindeville wrote: ... FWIW, I just tried to upgrade my laptop and got the same problem. I'm going to debug a little bit and see what I can find. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self (Re)Introduction
Hello, all. A brief bio on me: I started using Red Hat Linux in college in 1997. I spent half a decade as a Linux sys admin, and long ago I used to lurk in #redhat and #fedora giving tech support to new users. I first met some of these fine Fedora folks at FUDCon 2005. I finally signed up to be a Fedora contributor while at Ingres in 2007, but that didn't go quite as I expected, and I never submitted packages for review. I left Ingres for rPath, where I spent four years doing support and sustaining engineering for rPath Linux, Conary, and other rPath software; related to that, I've run Foresight Linux on my laptop for a while, so I'm still catching up on some the changes in the world of Fedora since 2007. This month, I joined Eucalyptus as a release engineer, and Garrett Holmstrom and I plan to co-maintain various Eucalyptus-related packages and their dependencies. I also hope to make other contributions as time permits. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
