Re: Goals for F13?
On 01/06/2010 05:35 PM, Mike McGrath wrote: So F13 is underway, we should get our list of F13 goals together. So what would you like to see (and will be working on) for F13? For example, I know Jon and Dennis are working on the mail man migration. The major features include: 1) Getting virt_web into Fedora 2) download.fedoraproject.org (based on boot.kernel.org) Oh... who's working on this? -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Goals for F13?
On 01/06/2010 05:48 PM, Mike McGrath wrote: On Wed, 6 Jan 2010, Jeroen van Meeuwen wrote: On 01/06/2010 05:35 PM, Mike McGrath wrote: So F13 is underway, we should get our list of F13 goals together. So what would you like to see (and will be working on) for F13? For example, I know Jon and Dennis are working on the mail man migration. The major features include: 1) Getting virt_web into Fedora 2) download.fedoraproject.org (based on boot.kernel.org) Oh... who's working on this? Right now just me - http://publictest8.fedoraproject.org/boot/gpxe.iso boot from that. The larger goal is to get people using it, raise awareness of it and prove it's a viable solution. I'm interested in working on it with you -from the composing side as well. I'm assuming I'm gonna need to read up a lot, is there a Fedora reference page somewhere or would we need to create one still? -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Goals for F13?
On Wed, 6 Jan 2010 11:09:56 -0600 (CST), Mike McGrath mmcgr...@redhat.com wrote: On Wed, 6 Jan 2010, Jeroen van Meeuwen wrote: I'm interested in working on it with you -from the composing side as well. I'm assuming I'm gonna need to read up a lot, is there a Fedora reference page somewhere or would we need to create one still? not yet, I'm going to put a features page together shortly but ping me in #fedora-admin. I can make sure to get you access to the bits and what's going on. It should be fairly easy to put together, at a minimum 1 new package in Fedora though I think a couple of others would be useful. And it was fairly easy ;-) For those interested: - https://bugzilla.redhat.com/show_bug.cgi?id=553055 - http://www.kanarip.com/custom/f12/SRPMS/gpxe-0.9.9-2.src.rpm -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Goals for F13?
On 01/07/2010 12:34 AM, Todd Zullinger wrote: Jeroen van Meeuwen wrote: And it was fairly easy ;-) For those interested: - https://bugzilla.redhat.com/show_bug.cgi?id=553055 $ curl -I http://www.kanarip.com/custom/SPECS/gpxe.spec HTTP/1.1 403 Forbidden Date: Wed, 06 Jan 2010 23:33:18 GMT Grmbl that's what I get for using a restrictive umask on my laptop :/ Fixed now. -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: (huge) Ruby packaging changes
On 12/22/2009 06:36 PM, Ville Skyttä wrote:
On Tuesday 22 December 2009, Jeroen van Meeuwen wrote:
- Use the alternatives system to point to one stack or the other for the
system default stack (think standalone applications).
Not that I'm anywhere near an expert in ruby matters, but I have some (bad)
experience with alternatives, so:
Neither am I an expert in Ruby, I'm just the maintainer of the package
(partly in company time, which is just wow!). My primary point was to
have the switching of stacks be available for standalone applications
(such as puppet, facter or other Ruby programs installed in
%{_bindir}/%{_sbindir}) that use #!/usr/bin/ruby, so that we don't have
to create a specific version of all those programs for each ruby stack,
and the user could choose - but shouldn't have to.
If this means running different individual applications with different
stacks/stack versions, I strongly suggest reconsidering using the
alternatives
system for that. Alternatives is for (easily) changing the system default
stack, not at all for changing per-application ones.
Being able to switch to a different stack would only be supported on a
per-system basis, but of course a single program can
#!/usr/bin/ruby-1.8.6 if it really wanted to.
FWIW, the ability would primarily be intended to be available for
developers.
And getting it right is
not an easy task. FWIW in fact I'd recommend not doing any alternatives
stuff
unless there are very strong, valid reasons for doing so. We have an example
with the current Java alternatives system in Fedora which in my opinion no
longer has any real benefits but rather has a negative net effect and it'd be
good to start planning for getting rid of it altogether.
The beast that is Java ;-) A very successful example where alternatives
is used heavily is of course a system's mail stack. I think it can be
done right, but the question is how.
On the other hand, if I got your intent right, environment-modules might be
something to look into here.
Care to explain the term environment-modules for me please?
-- Jeroen
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
(huge) Ruby packaging changes
Hi there, Not that anything is set in stone yet, but I wanted to give you a heads-up on packaging changes in Ruby that we (the Ruby SIG) are trying to figure out. The ultimate goal is to make Fedora the best development platform out there no matter what it is exactly you target. Core features of the current plan are: - Use the alternatives system to point to one stack or the other for the system default stack (think standalone applications). - Enable running multiple different versions of the Ruby stack on one system (e.g. 1.8.5, 1.8.6, 1.9.1 and possibly 1.8.7 and 1.9.2), as these versions are still pretty current (think Enterprise Linux), pretty easily maintainable (once we do it right) and very much needed -in special cases :P If you're interested in it's developments, which are targeted for Fedora 13, may I invite you to the Ruby SIG mailing list for a more detailed discussion? The Ruby SIG mailing list is at: https://admin.fedoraproject.org/mailman/listinfo/ruby-sig/ One particular message of interest may be: http://lists.fedoraproject.org/pipermail/ruby-sig/2009-December/33.html Cya soon! -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [FOSDEM'10] Community infrastructure talk
That's all nice and dandy, but not much of a topic to discuss no matter what your thoughts are. When it concerns how and through what mirror your data is available to your consumers you also have entirely different motives compared to making sure your *own* infrastructure runs fashionably well. If it were up to me, I have zero interest in discussing this specific topic presented as such. -- Jeroen Frederic Hornain fhorn...@gmail.com wrote: Dear *, FYI, Ralph from CentOS community is going to so a talk about infrastructure. *Hi, I'd like to propose a talk/discussion panel around mirror infrastructure management: - How are new mirrors accepted? - How do you administer / attend to the database of mirrors? - How are mirrors checked for freshness? - How do you work with Geo localization? As before. I can tell something about how the CentOS project is doing this, but I see this more as a panel, where other distributions also talk shortly about how they manage their mirrors and then things can be discussed. This also should be interesting for other projects taking care of their own mirrors (maybe someone from a large project might add to that discussion, too). Regards, Ralph * As you have got the same problems, If you are interested to join him in this talk and have discussion/brainstorming about it feel free to contact me.* * Best Regards Frederic* ;) * On Tue, Dec 15, 2009 at 10:10 AM, Frederic Hornain fhorn...@gmail.comwrote: Dea Thanks a lot On Mon, Dec 14, 2009 at 10:52 PM, Jeroen van Meeuwen kana...@kanarip.comwrote: On 12/14/2009 10:46 PM, Jeroen van Meeuwen wrote: On 12/14/2009 09:36 PM, Frederic Hornain wrote: Dear *, Would someone be interested to make a talk on Fedora Community infrastructure at FOSDEM'10 - Belgium -? * FedoraCommunity, opensourced LaunchPad, Bugzilla extensions, etc... BTW, as the rule have changed at FOSDEM, you will do your talk with other distributions on the same subject. Thanks for your time and your help. Sure, here's a candidate! I already asked permission from our fearless leader; [22:51:30] kanarip mmcgrath, that is, if you'll let me go tete-a-tete with other distributions on the topic of infrastructure ;-))) -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -- - Fedora-ambassadors-list mailing list fedora-ambassadors-l...@redhat.com Olpc mailing list olpc-o...@laptop.org -- - Fedora-ambassadors-list mailing list fedora-ambassadors-l...@redhat.com Olpc mailing list olpc-o...@laptop.org ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Major dns issues
On 12/14/2009 10:27 AM, Mike McGrath wrote: So I woke up today and we're still having dns issues on at least one of my hosts. Could everyone that has access please do a dig fedoraproject.org on all their hosts and tell me if any of them cannot resolve? I'm fine from 7 different locations in the Netherlands (including +trace), but not from the U.S. (digging on unity04.fedoraunity.org at server 64.122.217.133). -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [FOSDEM'10] Community infrastructure talk
On 12/14/2009 09:36 PM, Frederic Hornain wrote: Dear *, Would someone be interested to make a talk on Fedora Community infrastructure at FOSDEM'10 - Belgium -? * FedoraCommunity, opensourced LaunchPad, Bugzilla extensions, etc... BTW, as the rule have changed at FOSDEM, you will do your talk with other distributions on the same subject. Thanks for your time and your help. Sure, here's a candidate! -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [FOSDEM'10] Community infrastructure talk
On 12/14/2009 10:46 PM, Jeroen van Meeuwen wrote: On 12/14/2009 09:36 PM, Frederic Hornain wrote: Dear *, Would someone be interested to make a talk on Fedora Community infrastructure at FOSDEM'10 - Belgium -? * FedoraCommunity, opensourced LaunchPad, Bugzilla extensions, etc... BTW, as the rule have changed at FOSDEM, you will do your talk with other distributions on the same subject. Thanks for your time and your help. Sure, here's a candidate! I already asked permission from our fearless leader; [22:51:30] kanarip mmcgrath, that is, if you'll let me go tete-a-tete with other distributions on the topic of infrastructure ;-))) -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [RFC] unified i386/x86_64 install media.
On 11/25/2009 08:38 AM, Nicu Buculei wrote: Instead of this I would pretty much like to have the normal install DVD being full (4GB, instead of 3.0-3.3GB as now), so when installing a computer I have more content on local media and less stuff to get from online sources, resulting in a shorter time until the computer is fully usable. You might want an Everything spin ;-) -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On 11/25/2009 03:26 AM, Seth Vidal wrote: On Tue, 24 Nov 2009, Matthew Miller wrote: So would this mean one disk with two repositories on it, or is everything mashed together all in one repository? it'd be easy to have two sets of repodata in two different dirs pointing to the same set of pkgs. On 11/25/2009 07:28 AM, Jesse Keating wrote: Two repos, but with hardlinks. I doubt ISO9660 can deal with hardlinks, but I have to admit I've never really tried (I did try once and gave up pretty quickly I recall). Also, the way I understand this works, you can just include x86_64 packages in the one repository... When the system boots 32-bit (kernel, userland, etc, using syslinux 3.72+ ifcpu64.c32 which I have not yet been able to get to work yet) the x86_64 packages won't show up in the available packages, 'cause of how YUM does something with a list of compatArchs, right? -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On 11/25/2009 03:39 PM, James Antill wrote: On Wed, 2009-11-25 at 13:18 +0100, Jeroen van Meeuwen wrote: Also, the way I understand this works, you can just include x86_64 packages in the one repository... You can but that will break x86_64, because i386 will need i386 packages that x86_64 must not have as multilib. I understand that, I think, but, if you start out saying you're x86_64, why or how does it ever come to selecting the i?86 version of a package over the x86_64 version of a package? I'm just assuming YUM takes x86_64 over i?86 any time (best match arch or something), unless specifically told otherwise? As Seth said, you can have one giant directory of packages and just different repodata pointing to subsets. Yeah, I know. Sounds perfectly feasible. Yet $me curious. As Jesse said you could also use hardlinks/symlinks in the x86_64 repo. Or you could even create three repos. i386, x86_64 and i386-common (not that I think that will be better than the other two options). And noarch, and noarch! ;-) -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Creating a trusted sha256sum.exe binary for verifying *-CHECKSUM files on Windows
On 11/24/2009 05:25 PM, Jesse Keating wrote: On Tue, 2009-11-24 at 10:33 -0500, Todd Zullinger wrote: (I really don't want to maintain the mingw32-sha256sum package for Fedora, as it's just a quick and dirty hack to built a small subset of of coreutils for Windows.) Thoughts? Well, if you have to use a tool from the project, to verify other bits from the project, the verification just became a lot less trusted. If you don't trust the bits you got from the project, why would you trust the tool the project gives you to verify the bits? Here use this tool to verify our bits. Trust us, we swear! While this is completely true for, say winxpsp2.iso vs. m$-md5um.exe, mind that the sources to sha256sum.exe are actually available and can be verified on a completely verifiable stack one does already trust (verifiable except for x86 CPU inaccuracy of course). If not the transparency helps to boost the trustworthiness, or if that's not trustworthy enough, then how does one verify a binary rpm actually comes from the source that is shipped alongside with it, not to even mention gnupg shipped by Fedora against RPMs shipped by Fedora. Then, if trust was anything worth being concerned about why would you even need a .exe in the first place? For all you know the OS itself makes the .exe say OK or NOT OK in very, very arbitrary ways you can't verify. The goal is, of course, to verify the .iso against what is listed as it's sha256sum. Whether the tools ultimately come from the same source doesn't matter. It should, though, be advisable to not include the sha246sum.exe on the mirrors, and only serve the file over http over ssl. -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Permission for an off-site copy of CVS
On 11/23/2009 06:12 AM, Jon Stanley wrote: In an effort to work on the cvs side of https://fedorahosted.org/packagedb/ticket/165 I'd like to have an offsite copy of cvs1:/cvs/pkgs to test on. Being that this is in violation of our security policy (http://infrastructure.fedoraproject.org/csi/security-policy/en-US/html/EndUser-Standard-Introduction.html) and requires written permission, I'm asking for that permission here :) I just need two sysadmin-main members to +1 it, and I'll rsync it off tomorrow or so, Just curious, what part of the policy does a local copy from a public rsync location conflict with? ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Permission for an off-site copy of CVS
On 11/23/2009 05:18 PM, Jeroen van Meeuwen wrote: On 11/23/2009 06:12 AM, Jon Stanley wrote: In an effort to work on the cvs side of https://fedorahosted.org/packagedb/ticket/165 I'd like to have an offsite copy of cvs1:/cvs/pkgs to test on. Being that this is in violation of our security policy (http://infrastructure.fedoraproject.org/csi/security-policy/en-US/html/EndUser-Standard-Introduction.html) and requires written permission, I'm asking for that permission here :) I just need two sysadmin-main members to +1 it, and I'll rsync it off tomorrow or so, Just curious, what part of the policy does a local copy from a public rsync location conflict with? Having pressed Ctrl+Enter before I was done typing the message, I wanted to ask whether it was something I was missing, or something other then cvs1:/cvs/pkgs/ that conflicted with the security policy? Kind regards, -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Permission for an off-site copy of CVS
On 11/23/2009 06:27 PM, Mike McGrath wrote: On Mon, 23 Nov 2009, Jeroen van Meeuwen wrote: On 11/23/2009 05:18 PM, Jeroen van Meeuwen wrote: Just curious, what part of the policy does a local copy from a public rsync location conflict with? Having pressed Ctrl+Enter before I was done typing the message, I wanted to ask whether it was something I was missing, or something other then cvs1:/cvs/pkgs/ that conflicted with the security policy? Not everything under /cvs/pkgs/ world readable, in particular: /cvs/pkgs/CVSROOT/admin/ Aha! Thanks Mike ;-) -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Suitability of Python for daemon processes
On 10/25/2009 11:51 PM, Mike McGrath wrote: With all my babbling I forgot to mention we do already run python daemons in Fedora Infrastructure. Func is one, TurboGears (though it's wrapped in mod_wsgi) and one that we wrote ourselves[1] is our mirrorlist server. It's the backend that powers: http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-11arch=i386 And koji.fedoraproject.org, no? And translation is going through Django these days? -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Suitability of Python for daemon processes
On 10/26/2009 12:37 AM, Mike McGrath wrote: On Mon, 26 Oct 2009, Jeroen van Meeuwen wrote: On 10/25/2009 11:51 PM, Mike McGrath wrote: With all my babbling I forgot to mention we do already run python daemons in Fedora Infrastructure. Func is one, TurboGears (though it's wrapped in mod_wsgi) and one that we wrote ourselves[1] is our mirrorlist server. It's the backend that powers: http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-11arch=i386 And koji.fedoraproject.org, no? Yes but I think it's more along the lines of a python script that gets called when a page gets loaded, it doesn't actually run statefully like our tg apps do. But the backend does run python foo, right? And translation is going through Django these days? That's true, django is another one we run. I bet there's a few more sitting around that we haven't thought of yet :) I bet too ;-)) -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Fedora-livecd-list] launch anaconda kickstart from running livecd
On 10/15/2009 08:03 PM, Peter Scheie wrote: From a running Centos liveCD (minimal) I want to launch anaconda with a kickstart file. Right now we build a small ISO using isolinux that loads the kernel and points it to the kickstart file on an HTTP server (ks=http://blah.blah.blah/ks.cfg). But I want to gather some info from the user and test some networking connections before launching anaconda, thus the need for the liveCD. I've got anaconda included in the livecd and I can call it, but when I try to pass --kickstart=http://blah.blah.blah/ks.cfg, it says 'no method specified'. So, I added -m http:// with a path to the repos we use with our regular installer, but while anaconda starts, it starts asking questions about language, keyboard, etc., meaning it's not reading the kickstart file. This seems more like an anaconda question then a livecd question, don't you think? -- Jeroen -- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: [Fedora-livecd-list] Building LiveCDs for Fedora from CentOS
harry.dev...@faa.gov wrote: We have our development servers here where I work that are running CentOS 5.2 64-bit on them. One of our projects has a LiveCD that we build and provide. It is currently built on a Fedora 8 PC that I have but we'd like to move to Fedora 11 or 12. What I'd like to do is put the Fedora 11 RPMs on our server, run createrepo to create a repository, and use livecd-creator on that server to build the Fedora 11 LiveCD. Is this approach possible? Are there any gotchas I need to be aware of if it is possible? The LiveCD is a 32-bit implementation BTW. You will run into a SquashFS major version bump incompatible between Fedora on the live media and CentOS on the server. You should use a Fedora release greater then or equal to Fedora 11 on the build host, even though you can still host the repositories used on the EL-5 server. -- Jeroen -- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: [Fedora-livecd-list] livecd-iso-to-pxe problem
Alan Pevec wrote: On Thu, Sep 24, 2009 at 3:03 PM, Francesco Crippa fcri...@byte-code.com wrote: Hi guys, I've got a problem with the script livecd-iso-to-pxe... It creates the right files (under /tftboot directory) but I can't pxeboot a machine with this configuration. During the pxeboot, initrd is loaded and kernel starts the execution, but it looks like it can't run (or find) the init process... Have you ever got this problem before? Unfortunately I haven't got any error message to show you (just kernel logs on the console during the boot... but without error... just the kernel, no messages from init script...). I'm using fedora11 Le me know if you know a solution for this problem Seems like the issue we had with oVirt Node PXE boot on F11 - https://www.redhat.com/archives/ovirt-devel/2009-June/msg00136.html Try livecd-iso-to-pxeboot from our patched RPM http://ovirt.org/repos/ovirt/11/x86_64/livecd-tools-024-1ovirt.fc11.x86_64.rpm Can you, and will you, send this upstream (to me for example?). -- Jeroen -- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: Pungi exact package version
On 09/26/2009 11:47 PM, Julian Aloofi wrote: Am Samstag, den 26.09.2009, 23:26 +0200 schrieb Jeroen van Meeuwen: Pungi does not support selecting exact package nevra in the %packages manifest of a kickstart, but Revisor does; use --kickstart-nevra I guess you mean --kickstart-exact-nevra, or is this equivalent? Oops, yes, I mean --kickstart-exact-nevra. -- Jeroen -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Pungi exact package version
On 09/23/2009 10:24 PM, Thomas S Hatch wrote: I am building an auto install iso for some repeated, specialized deployments and I have run into a problem. I am building them with pungi and using the latest packages from fedora 11, but a bug in the 2.6.30 kernel seems to be preventing me from installing from cdrom. Anaconda fails to find the cdrom drive on the hardware I am using (IBM hs22 bladecenter). The problem is fixed by using a 2.6.29 kernel. So I was hoping that I could build my installer iso with pungi, and the updates repository, but exclude the latest kernel so a 2.6.29 kernel is used. Is this possible without maintaining a modified local copy of the updates repository? Pungi does not support selecting exact package nevra in the %packages manifest of a kickstart, but Revisor does; use --kickstart-nevra -- Jeroen -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [Errno 10] No child processes
On 09/14/2009 03:45 AM, À wrote: Hi, xiao li This is very normally error. FWIW, I have this error on Fedora 11 regularly, too. Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Broken dependencies in Fedora 11 - 2009-07-28
On 07/28/2009 03:29 AM, Michael Schwendt wrote: The following packages in the repository suffer from broken dependencies: For those that had not noticed, rubygem-rails-2.3.3 requires rubygem-rack whatever-is-available-now, so... -- Jeroen == The results in this summary consider Test Updates! == package: rubygem-rails-2.3.2-3.fc11.noarch from fedora-updates-testing-11-i386 unresolved deps: rubygem(activesupport) = 0:2.3.2 rubygem(activeresource) = 0:2.3.2 rubygem(activerecord) = 0:2.3.2 package: rubygem-rails-2.3.2-3.fc11.noarch from fedora-updates-testing-11-ppc unresolved deps: rubygem(activesupport) = 0:2.3.2 rubygem(activeresource) = 0:2.3.2 rubygem(activerecord) = 0:2.3.2 package: rubygem-rails-2.3.2-3.fc11.noarch from fedora-updates-testing-11-ppc64 unresolved deps: rubygem(activesupport) = 0:2.3.2 rubygem(activeresource) = 0:2.3.2 rubygem(activerecord) = 0:2.3.2 package: rubygem-rails-2.3.2-3.fc11.noarch from fedora-updates-testing-11-x86_64 unresolved deps: rubygem(activesupport) = 0:2.3.2 rubygem(activeresource) = 0:2.3.2 rubygem(activerecord) = 0:2.3.2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies in Fedora 11 - 2009-07-28
On 07/28/2009 03:29 AM, Michael Schwendt wrote: The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: rubygem-actionpack-2.3.2-1.fc11.noarch from fedora-11-i386 unresolved deps: rubygem(activesupport) = 0:2.3.2 These will be resolved with the next build of rubygem-actionpack (building now). -- Jeroen package: rubygem-actionpack-2.3.2-1.fc11.noarch from fedora-11-ppc unresolved deps: rubygem(activesupport) = 0:2.3.2 package: rubygem-actionpack-2.3.2-1.fc11.noarch from fedora-11-ppc64 unresolved deps: rubygem(activesupport) = 0:2.3.2 package: rubygem-actionpack-2.3.2-1.fc11.noarch from fedora-11-x86_64 unresolved deps: rubygem(activesupport) = 0:2.3.2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On 07/28/2009 12:14 AM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 28 Jul 2009, Rahul Sundaram wrote: On 07/28/2009 03:14 AM, David Cantrell wrote: I've been doing that for Jeroen. He's submitting patchsets for review and I've built at least a few anaconda updates for him. He is currently testing updates for F-11 and when that's ready, he'll submit the patches for review for anaconda and we can do an update. That's good news. Thanks for doing it. Are these test packages available publicly? You'll have to ask Jeroen how he handles testing. Once he has a patchset suitable for an F-11 update, he submits it for review and then we go from there. The idea being that once we roll the update for F-11, he'll be ready to pick it up and make images. There a source repository online at: - git://git.kanarip.com/anaconda, or - http://git.kanarip.com/?p=anaconda There's two YUM repositories online, and public; - http://www.kanarip.com/anaconda/ - stable - http://www.kanarip.com/anaconda-devel/ - unstable The testing is handled by our very adequate friends in the test team of Fedora Unity. Furthermore, by the time the updates are available in the official upstream repository, the product has already hit the streets. It's the rest of the world that needs the update to be available in the official repositories; I can do what I want wrt. the Fedora Unity Re-Spins. However, I'm also upstream for that one other utility people use to Remix, Re-Spin, whathaveyou. To have them ask me again and again and again why things don't work, or why things can't be fixed, made me ship the stable anaconda fixes repository in every default Revisor configuration. Now, I've requested anaconda commit access for stable branches since like forever, since the anaconda team does not want to touch these anymore, I've offered to be on the receiving end of bugs for these branches, so it wouldn't hit the upstream developers, I've requested GIT commit access years ago in order to be able to work with the upstream developers, but so far only David Cantrell and Hans de Goede are willing to help me. David pushes out an update to anaconda every now and then, and Hans reviews lists of commits I'm thinking about cherry-picking from rawhide to the stable fX-branch -because frankly that's all I do until I'm allowed to sink my teeth in it. -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On 07/27/2009 10:21 PM, Jeremy Katz wrote: Regenerating the images is expensive -- it requires effort on the part of the developers doing fixes, release engineering doing builds with the fixes, QA testing the fixes, infrastructure (mirrors) carrying a significant amount more bits[1], ... Hey, that's funny. That's what I do. With a little help from my friends. -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-10
On 07/10/2009 09:04 PM, Jon Stanley wrote: 18:08:49jds2001 #topic Feature - extended lifecycle (...snip...) 18:15:31jwb jds2001, we have majority vote to move to the Board I'm interested to know what the follow-up on this would be; Is it added to the board's agenda? Also, I would appreciate if the verdict goes in the ticket; https://fedorahosted.org/fesco/ticket/180 Thanks! Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/07/2009 06:39 PM, Jesse Keating wrote: On Tue, 2009-07-07 at 16:24 +0200, Jeroen van Meeuwen wrote: If you take into account that the proposal concerns security fixes only, then every update has to be labeled a security update (and preferably have some kind of CVE/bug# attached??). We would need to think about a policy for that, agreed. Yeah, if you pick the line at say critical then every update would have a CVE, or would be bundled in bodhi with the package that had the CVE. So say webkit needs updating due to a CVE, you would bundle all the dependent packages in the same update, and the whole update itself would have the CVE listing, and would have just once announcement. +1, my thoughts exactly. The measure of success is particularly hard to state in figures. Just thinking about some measures of success though, it would include; - increased participation from the Fedora side of things - continuous flow of security updates (and bugs against EOS releases solved) - increased consumption and maybe there's more. Number of subscriptions to an announcement / errata type of mailing list maybe? Number of subscriptions to a ELC SIG mailing list? Could go by time it takes to get a CVE discovered/fixed, how many are slipping through, karma on the updates, or just mirrormanager hits on the repos. Agreed, these certainly are measurables. Might be a little harder to get some figures on, but we'd have to figure it out at some point anyway. * A timeline to go with the above to review for success/failure Here's where the initial proposed extension of 6 months kicks in. I would say our first review is what is now called Alpha freeze -the milestone where Features are checked for their readiness -whether this proposal ends up being an actual feature or not. I would think 6 months might be a little too short. Why not give it a year? 6 months would be what we can commit to now, right now, to extend the life cycle of one Fedora release with. Depending on those results, and it's success, we might be able to 1) extend the life cycle a little more, and/or 2) take on a second release's extended life cycle. * A responsible body behind the effort to make regular reports to FESCo/Board This is not up to me ;-) I guess we'll hear from FESCo, on whether they think this is a feature, on whether they think this is in their mandate, on whether they think this has to go to the Board. You're driving the feature, but don't want to be responsible for the feature? odd? Yes, I'm driving the feature. That doesn't mean I'm in a position to say anything definitive ;-) I'm not elected, chosen, endorsed, unique in this initiative, or anything else, I'm just driving it. Even if I were to be assigned a leading position within whatever governance body should govern this feature/initiative, I'd not be in control -like I said before though; different subject ;-) If, supposedly, FESCo (or the Board) says hell yeah (or just 'yes', which would do) to the initiative, then I suppose we put our jewels on the table and determine the final shape and form of the project. Who is going to track and discover the security issues? To be determined. Could be delegated to a (dedicated?) small(er) group of people within the SIG (to be set up) -maybe the not-so-technical??, or could be a responsible of each individual participating. Ok, so long as your aware that somebody or somebodies will need to monitor the entire package set for CVEs (something we're probably missing to some extent already). And so this has to be resolved from a Fedora Project wide perspective rather then just be assigned to the people that co-incidentally said security fixes only. This can not and will not ever be a measurable against the ELC feature if the Fedora Project itself does not have the same or similar procedures approved and implemented. If we miss out on a few, or many, then we're bad. If the Fedora Project misses out on just as much, then we're good, within the bad, bad Fedora Project. Even though a Fedora release is much less likely to have security issues linger around for a while due to frequent updates being available for virtually any given application, the Fedora Project sets the standard in this case, not vice-versa ;-) -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/07/2009 02:30 AM, Josh Boyer wrote: Is there a reason any of that can't be done as a secondary arch-like effort? Nope. Not as far as I can see. I've already pointed out why it's painful to keep EOL releases around. You didn't really address those, and you seemed to have grouped them into minimal infrastructure effort. I didn't touch on package signing earlier, but that is another potential hurdle. Let me put is this way: None of the items I have listed are show-stoppers or insurmountable. However, unless someone comes forward with _concrete_ proposals on how to approach them and actual _people_ willing to work on it, they won't change. I don't think that is an undue burden to having this approved by a governing committee, whether it be FESCo or the Board. It's as simple as that. I think Jeroen understands that, and he seems to really want constructive criticism on the proposal. So I'll be happy to wait and see what comes of this. +1 to all of the above. Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/07/2009 12:37 AM, Kevin Fenzi wrote: On Tue, 07 Jul 2009 00:18:51 +0200 Kevin Koflerkevin.kof...@chello.at wrote: Patrice Dumas's proposal failed because he wasn't provided with the required infrastructure (and he was unable to come up with it himself, which I can't blame him for). That was the time before last. The last one was in Feb by Scott Williams. I guess it just quietly faded out. Scott Williams was also required to build up his own infrastructure, which frankly is too much overhead in order to be able to start up the rest of it. Without a concrete group of people large enough to make this wory saying that they are signing up to do that work, I don't have high hopes for this succeeding in the long run. We'd just need some minimal infrastructure effort, one person willing to do the pushes (like you're doing for the supported releases) and everything else would be as is, if somebody wants something fixed, they'll have to push the fix, if nobody cares, it won't be fixed. It isn't supported after all. And no QA, if it breaks, you get to keep the pieces. Again, it's unsupported, that means what it means. I still think it's better than not getting any security fixes at all. I think it is worse. It causes people to have an expectation that something will get security updates, and when it doesn't happen and they get compromised, they will not be very happy. The same goes for current releases, don't you think? Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/07/2009 12:29 AM, Toshio Kuratomi wrote: On 07/06/2009 03:07 PM, Jesse Keating wrote: Bugzilla spam. If we keep the release open for random bug filing, we have no good way of telling bugzilla that only specific users should get bugs for specific releases of Fedora. Ownership is at a product level, not at the product version level. So maintainers will get all the spam, and have to forward it along to whomever is handling security updates. This one could be solved by having a separate component in bugzilla like Fedora Legacy, however that does move into a space that is visible to end users. Bug triage could probably move bugs from normal Fedora to Fedora Legacy if people were reporting against the correct version but incorrect product. For the Bugzilla gurus out there, to what extent is Bugzilla capable to Assign a bug to the owner of a package for a certain branch? Say I file a bug against foo in Fedora 8 now, and have ownership of the foo package in PackageDB... would the owner of the foo package in Fedora !8 branches be spammed with the Bugzilla report? Would it end up in his/her assigned list? I guess the example here is EPEL, which has a separate product Fedora EPEL in Bugzilla, no? I guess it would be doable to add a product Fedora End-Of-Sales or something (please avoid the Legacy or LTS names). -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/07/2009 12:07 AM, Jesse Keating wrote: On Sat, 2009-07-04 at 23:58 +0200, Jeroen van Meeuwen wrote: I wanted to draw your attention to a feature I've proposed for Fedora 12, mysteriously called Extended Life Cycle. You can find more details at https://fedoraproject.org/wiki/Features/Extended_Life_Cycle When we talked at Berlin some of the details were a bit different, and I'll get to some of what I talked about there later in this email. First off, I think this is different from Fedora Legacy, or has potential to. Legacy had a few very key fail points. 1) it was opt in. Users had to know about it and actively enable it. 2) it was completely done outside of the Fedora infrastructure. 3) Fedora's popularity was very hit and miss, the type of people that would best use a Legacy like service were too burned to give any Red Hat related offering a shot. 4) RHEL4 (and its clones) were new enough for most of the people that would use this service, and thus they went that way. A longer Fedora sounds really great now, particularly because EL 5 and its clones are rather long in the tooth. How good it will sound once EL6 is out is a different matter. I think the popularity will wax and wane as the EL release cycles go. Like with anything else, though FY2010 is the right moment to start with, it has to grow organically and it will, or it won't, regardless of whether the timing is excellent -we would only need to take into account the release of EL6 from the perspective of expectations from our side. I think for this to succeed as an effort, which there is some folks whom state a need, I think there needs to be a few key things. * Automatic use. Users shouldn't have to opt-in to something different, they should have to do nothing and continue to get the updates. +1, no change on the consumer side may be required in order to have the ELC feature succeed. * A clarification of security updates. Will local denial of service (aka crash bug) be fixed? Local root escalation? Remote denial of service? Remote escalations? The amount of updates you will have to do will change dramatically based upon what level of security updates you want to target. http://www.redhat.com/security/updates/classification/ may help and may be familiar to the type of users you are targeting. I'll look into these details and try and elaborate on what I find -on the Feature page, so that this is (more) clear. Like I said before, I'm not in control and this is (going to be) a group effort so things may turn out a little different but we need to think about it anyway, so let's give it a shot beforehand. Thanks! * All or nothing. Either updates for whatever class you clarify from above will be provided for all packages, or none. There can't be any vagueness here. All, +1 * A way to prevent updates that do not match the above from being pushed. Ambiguity in what can be expected can cause confusion and fear. I realize that we have ambiguity during the normal release cycle and that is maintainer driven, but an extended support effort like this should clarify what will be offered. If you take into account that the proposal concerns security fixes only, then every update has to be labeled a security update (and preferably have some kind of CVE/bug# attached??). We would need to think about a policy for that, agreed. Without a guarantee for stable ABI/API or stable major/minor version numbers though some updates may have to be pushed as part of the dependency stack for a given security bug fix -or not. I guess we'll need to describe how this should be tackled exactly. * A measure of success. Some way that you can decide whether or not the Feature has been a success and should be continued, or whether it is a failure and shot not be continued, or should be attempted in some other way The measure of success is particularly hard to state in figures. Just thinking about some measures of success though, it would include; - increased participation from the Fedora side of things - continuous flow of security updates (and bugs against EOS releases solved) - increased consumption and maybe there's more. Number of subscriptions to an announcement / errata type of mailing list maybe? Number of subscriptions to a ELC SIG mailing list? * A timeline to go with the above to review for success/failure Here's where the initial proposed extension of 6 months kicks in. I would say our first review is what is now called Alpha freeze -the milestone where Features are checked for their readiness -whether this proposal ends up being an actual feature or not. * A responsible body behind the effort to make regular reports to FESCo/Board This is not up to me ;-) I guess we'll hear from FESCo, on whether they think this is a feature, on whether they think this is in their mandate, on whether they think this has to go to the Board. Who is going to track and discover the security
Re: Feature proposal: Extended Life Cycle Support
On 07/07/2009 01:06 AM, Kevin Fenzi wrote: On Mon, 06 Jul 2009 20:20:50 +0200 Jeroen van Meeuwenkana...@kanarip.com wrote: Reading it on a question-mark per question-mark basis though, I think the feature page answers half of the half-posed questions. Anyway: - a bunch fas names? Approximate number? A bunch right now is approximately 25, including the people I've seen being enthusiastic in this thread or in private conversations. This doesn't mean I have 25 people lined up to do the actual work though, but for a single thread and some private communication (not fully exposed and not started yet), I think ~25 people is a strong start. When this comes up there is always A bunch of people who want this, but they never seem to want to sign up to do the work. Do you have such people ready to go to work? I can personally guarantee 1 FTE of work backing up this proposal for 6 months of extended life cycle support. - Are there any Corporations that specifically asked for this? Would they be willing to provide any resources to the effort? The demand is there..., the offerings... not so much. Maybe there's a trick to get sponsoring for something that does not and may not exist yet because approval is pending, that I don't know about. Care to share? Well, I would say gather your group, show that there is an active group of people ready to work on this and you will have a lot less skepticism. I personally look at the last time this came up. As far as I know the group had 1 meeting, nothing ever happened. Nothing ever got out, true. Some things did happen, such as building a large part of the infrastructure needed. It didn't live up to it's full potential though, agreed. I fear you are going to have to show some great setup and activity before people are going to take this seriously. :( What the conditions are for anyone out there to take this seriously or not, realistically, isn't my problem. I can't satisfy everybody in every aspect as you'll undoubtedly understand, but I can make sure valid concerns are addressed or taken into account prior to a decision being made on whether to allow this within and through the Fedora Project (as a Feature?). I should also note that I can not just share information on people interested or willing to do the work with you all, since I do not know or control their desired level of privacy. Either they step up and make themselves known to the world during one of these conversations, or they keep silent and you will never hear from then until after the discussion and the final decision -for whatever reason, I don't know. I'm sorry, but I choose to not be the one deciding whether people can opt-in later, at any given point, or whether they opt-in because I share their personal information. Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F10 anaconda incompatible with current F10 yum - WTF
On 07/02/2009 05:31 PM, Xavier Toth wrote: It's a one liner. --- anaconda-11.5.0.12/yuminstall.py.orig 2009-06-30 09:05:19.0 -0500 +++ anaconda-11.5.0.12/yuminstall.py2009-06-30 09:06:03.0 -0500 @@ -575,8 +575,7 @@ YumSorter.getReposFromConfig(self) # Override this method so yum doesn't nuke our existing logging config. -def doLoggingSetup(self, debuglevel, errorlevel, syslog_indent=None, - syslog_facility=None): +def doLoggingSetup(self, *args, **kwargs): pass def doConfigSetup(self, fn='/tmp/anaconda-yum.conf', root='/'): Ted Regrettably, 11.5.0.12 is the wrong version for Fedora 10; you need 11.4.1.63. 11.5.0.12 is the Fedora 11 series and might therefor have different disturbing effects on composing media. I'm building a new version of anaconda for Fedora 10, if you're interested let me know. -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 5 Jul 2009 22:13:07 +0100, Christopher Brown snecklif...@gmail.com wrote: Honestly, I'm impressed by your persistence but I think simply trying to re-instate Fedora Legacy (which it sounds like this is what you are trying to do) is doomed to permanent failure. I love your argumentation behind this statement; Why do you think it's doomed exactly? Is it reasoning following the past Fedora Legacy initiatives (and failure), or is there anything new? -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, 06 Jul 2009 02:03:01 +0200, Kevin Kofler kevin.kof...@chello.at wrote: Jeroen van Meeuwen wrote: Whether 6 months of additional availability of security updates is going to help, and to what extend, we'll have to see. Compared to the current situation, that'll give an environment 7 months to upgrade beyond the moment that we now call End-Of-Life for a given release and 3 releases to choose from -certainly a lot more time then 1 month and 2 releases to choose from. They already have 7 months of time to move to the next version. It's just if they absolutely want to skip a version that they only have 1 month. True, but consider that moving to Fedora N+1 requires one to reconsider within 6 months. As such I'd say choosing the Fedora N+1 option when Fedora N+2 does not meet ones needs or expectations and one decides to put off on upgrading to Fedora N+2, leaves them with a one month upgrade opportunity after Fedora N+3's GA after all, and so is not exactly without penalty. Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, 06 Jul 2009 10:27:43 +0100, David Woodhouse dw...@infradead.org wrote: On Sun, 2009-07-05 at 17:52 +0200, Jeroen van Meeuwen wrote: As described on the Feature page, but if there's any specific questions about the reasoning on there I'll be happy to answer those questions. I had read the feature page, in which you claim that a three-year cycle disqualifies the distribution(s) as desktop Linux distributions. I didn't see any justification for that assertion, especially given that you're simultaneously claiming that a 13-month lifetime isn't long _enough_ for you. Hold on... Realistically, the current 13 month life cycle is about 7-8 months too long for me personally as I upgrade to rawhide anywhere between Beta and GA everywhere I can ;-) This extended life cycle feature is not to support my own needs and/or expectations. The longer (3 year approx.) release cycle doesn't necessarily disqualify a distribution for desktop environments, but for some environments that have a desire to run newer software. The shorter life cycle (~13 months) however is a major downside to many businesses -in my experience. You've conveniently dodged the question of what lifetime you _do_ want to provide, by saying 'yet to be determined'. But you must have _some_ idea, if you're so sure that 13 months is too short and 36 months is too long. As the page says, at: https://fedoraproject.org/wiki/Features/Extended_Life_Cycle#Notes my initial thoughts are 6 months extra (~19 months total). This will give us enough time to establish whether this is successful (although not meeting it's full potential success after this short a period of time), and whether this is sustainable. How much work would it take, to make it possible for us to still ship updates for a release which has officially reached EOL? Does the sky fall on our heads if we don't push the 'Kill F-9' button in koji and bodhi precisely 1 month after the F-11 release? Overall, roughly estimated, it'll take 1 FTE to do all the work involved. Whether that is one person doing all the work (including patching, building, maintaining infra, pushing, signing, etc, etc..), or 80 people doing all kinds of various stuff, doesn't matter; It'd still come down to approximately 1 FTE. As a first step, perhaps we try that -- still officially state that the release is EOL and should not be used, but _allow_ interested people like Jeroen (and the original package owners, _if_ they are so inclined) to continue to build and push updates, instead of forcibly cutting off builds and updates as we do at the moment. As suggested on the wiki page, we rename EOL to End-Of-Support (EOS), only to make a given release EOL after the period of time we decide to provide security updates for. Of course, not renaming EOL to EOS does not block anything from moving forward. That _isn't_ something we would publish as a 'feature' though -- it would strictly _unofficial_, although you'd be permitted to use the Fedora infrastructure for it. If it turns out that there _is_ enough interest and the interested people are _actually_ keeping on top of security fixes etc., then maybe we could consider officially admitting that it happens, and _then_ publishing it as a 'feature'. And/or extending it to more than one extra release. But those are all questions for the future. If it doesn't take too much infrastructure work, I see no reason why we shouldn't let them _try_. It doesn't hurt Fedora at all, does it? Thank you, Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, 6 Jul 2009 07:11:30 -0400, Josh Boyer jwbo...@gmail.com wrote: No, the sky does not fall. There are a few hurdles though. 1) Master mirror space. This used to be an issue, in that we had to move older releases to alt.fp.o in order to make space for the new release. I believe we still do that, so either the yum.repo.d config files for the EOL release would need to be changed, or we'd have to grow a lot more mirror space. 2) Update push times. It takes 3+ hours to mash f9-updates right now. Keeping that time duration in the official updates pushing for an EOL release would be really annoying. Particularly since we are already going to hit some major time hurdles as F10 and F11 age and definitely when we add F12. These are very valid constraints/concerns which I've added to the Feature wiki page. This is stuff I like to hear ;-) It doesn't work that way in practice. If it is allowed, it is official. You have to coordinate downtimes, End-of-Life-After-Death times, etc. The minute it's disabled early for one reason or another (space, time constraints, etc) people will cry foul even if it was unofficial. This (downtimes, etc) is why initially, I wanted the period of time between EOS and EOL to match a release cycle. I guess these dependencies make it a little more required to stick with periods of time equal to the release-cycle of a Fedora release. If it turns out that there _is_ enough interest and the interested people are _actually_ keeping on top of security fixes etc., then maybe we could consider officially admitting that it happens, and _then_ publishing it as a 'feature'. And/or extending it to more than one extra release. But those are all questions for the future. I would encourage people to run this as a secondary architecture. CVS still remains open for commits. You could just have a secondary koji hub for the builds. It that's the solution to problems (to be) set forth, then so be it. I would love to have it as part of the primary infrastructure but then again it's no blocker. If it doesn't take too much infrastructure work, I see no reason why we shouldn't let them _try_. It doesn't hurt Fedora at all, does it? There is minimal pain, yes. Mostly to infrastructure and rel-eng. What I don't immediately see is the benefit to Fedora overall. Is it you question the benefit given in the paragraph on the Feature page, or ...? Thanks, Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, 6 Jul 2009 16:25:08 +0100, Christopher Brown snecklif...@gmail.com wrote: 2009/7/6 Jeroen van Meeuwen kana...@kanarip.com: On Sun, 5 Jul 2009 22:13:07 +0100, Christopher Brown snecklif...@gmail.com wrote: Honestly, I'm impressed by your persistence but I think simply trying to re-instate Fedora Legacy (which it sounds like this is what you are trying to do) is doomed to permanent failure. I love your argumentation behind this statement; Why do you think it's doomed exactly? Is it reasoning following the past Fedora Legacy initiatives (and failure), or is there anything new? That plus the fact that you have Red Hat, the major backers of Fedora, producing a distribution that is geared towards long term support for their clients. Hence any initiative to increase the length of time Fedora is supported will not (I believe) receive anything more than lip service from RH. I completely understand that and it makes financial sense. lip service doesn't translate very well but I think I got the clue; If you're saying that Red Hat would choose to not support this initiative for whatever their reasons, may be, then so be it. I can't control what they do and I wouldn't want to. I can control however what I do with or without Red Hat's blessing. I was simply trying to identify what the requirements are for LTS on Fedora. I think simply saying Fedora needs LTS is doomed as the past has proved. Those that forget the past are doomed to repeat it. - George Santayana I'm too eager to respond with similar phrases as put onto the Feature wiki page; if the difference between the long term support model for RHEL and an extended life cycle model for Fedora isn't clear enough, then how can I explain the added value of a commercial company backing it's product, stable API/ABI offerings, hardware and software certifications, a phone number, the differences between 7 years or 19 months, desktop environments vs. enterprise solutions, prolonged availability of security updates (only!) vs. prolonged application support (including security updates), and the difference between 19 months and 3 years? The sooner Fedora gets out of its identity crisis the better. I wholeheartedly agree, but it's a completely different discussion. Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Mon, 6 Jul 2009 13:56:43 -0400, Bill Nottingham nott...@redhat.com wrote: Kevin Fenzi (ke...@scrye.com) said: - The issue I have with this plan (and the others very like it) is that if you say we will just do updates for the things we have people willing to do updates it means the entire end of life distro is not covered and the likelyhood of an outstanding security issue is quite high. There is a chicken and egg issue here where unless there is enough coverage we shouldn't do it, but we can't find out if there is enough coverage without doing it. Doing it in such a way that it fails just gives everyone a bad name and feeling, IMHO. - An indeterminate time is also bad IMHO. How can these corporations plan if they don't know how much time you are adding here? These two are my big concerns - doing this badly is worse than not doing it, IMO. When it comes to user's security, I don't want to give promises we can't keep, or leave them in a bind. This has been addressed in another response to the quoted message from Kevin. Other notes: - while F9 updates may be 3+ hours, F11 updates is currently *14-15* hours, and there aren't as many updates now as there will be; that number will only go up. (Yay deltarpms!) The support of deltarpms within the extended life cycle is something that can be (re-)considered. - You don't provide API/ABI guarantees. Which means you're signing up for more work than you might want if you're pushing updates to Firefox/xulrunner. (And if you're not providing updates for that for the desktop, it's not worth starting.) Thanks for the heads-up. - You state that the only reason that makes upgrading the distribution a requirement is the continuous availability of security updates. This implies that you're fine with the feature set of an older distribution after a while; but you don't want something like RHEL or CentOS. Is it just the 'RHEL is sort of old in the tooth right now' sort of philosophy? Because by your metrics, a RHEL released now (or in 3 months, or whatever) would be fine. The or whatever is sorta funny... (1) The opt-in upgrade every 3 years or every 6 months is a *major* difference. (2) The required upgrade every 7 years or every year is a *major* difference. At point 1 where RHEL is released, it might be fine. At point 2 where Fedora N+1 is released RHEL gets old. You have another 4 (!) Fedora releases (do I hear anyone say ~20 features each?) coming your way to make you appreciate the more rapid release cycle; if only you didn't hate the rapid required upgrade cycle as much... Now, if one could opt-in to upgrade every 6 months for a longer period of time, say 19 months instead of 13 months (leaving 7 or 1 month(s) respectively to upgrade to N+1 or N+2, as said before), then I foresee greater adoption and thus potentially greater participation. Also, just going back to original first principles: http://fedoraproject.org/wiki/Objectives Fedora is not interested in having a slow rate of change, but rather to be innovative. We do not offer a long-term release cycle because it diverts attention away from innovation. Long term support, in general, goes against the directly objectives of the project. If it's felt that extending the life cycle a *specific, measureable amount* would be of more benefit to the project, that's probably a board issue, not a FESCo issue. I've heard before it does not feel like a Feature. I guess it'll be up to FESCo to decide on whether or not to make a decision on this, or to relay the issue to the Board? -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/06/2009 09:19 PM, Bill Nottingham wrote: Jeroen van Meeuwen (kana...@kanarip.com) said: These two are my big concerns - doing this badly is worse than not doing it, IMO. When it comes to user's security, I don't want to give promises we can't keep, or leave them in a bind. This has been addressed in another response to the quoted message from Kevin. OK. When you state in the feature page: Note that the following items may only apply to those that opt-in on ELC support that implies that it would not apply to every package. Or are you referring to 'users who opt-in to use ELC'? Between packages and maintainers, only maintainers are in a position to opt-in. Also, just going back to original first principles: http://fedoraproject.org/wiki/Objectives Fedora is not interested in having a slow rate of change, but rather to be innovative. We do not offer a long-term release cycle because it diverts attention away from innovation. Long term support, in general, goes against the directly objectives of the project. If it's felt that extending the life cycle a *specific, measureable amount* would be of more benefit to the project, that's probably a board issue, not a FESCo issue. I've heard before it does not feel like a Feature. I guess it'll be up to FESCo to decide on whether or not to make a decision on this, or to relay the issue to the Board? Probably, yes. But this is why I think the specific amount of extension is a good idea to state - it makes the proposal more actionable. And it is proposed, it's just not everywhere in the text: https://fedoraproject.org/wiki/Features/Extended_Life_Cycle#Notes -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 5 Jul 2009 06:20:38 + (UTC), Matej Cepl mc...@redhat.com wrote: Jeroen van Meeuwen, Sun, 05 Jul 2009 01:30:46 +0200: On Sun, 05 Jul 2009 01:13:14 +0200, Julian Aloofi To be honest, I think environments that work like that won't use Fedora anyway if it wasn't supported for at least three, let's say two and a half, years. Having to agree with your general statement -not necessarily the exact period- I think neither of us can commit to extending even a single release's life cycle to that extent right now. We'll have to start somewhere, as you'll agree, and so we're thinking of starting out here; 3 releases to maintain in parallel, for those that opt-in, excluding EPEL (which has long term support in all it's aspects already). The problem I have with this whole project is that nobody explained me well, why you folks interested in this don't join CentOS project? NIH? The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. Does that make sense? Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On 07/05/2009 12:12 PM, Jos Vos wrote: On Sun, Jul 05, 2009 at 12:03:05PM +0200, Jeroen van Meeuwen wrote: The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. I don't completely agree that desktops tend to need to run the latest and greatest (when we're talking about business desktops), but desktops (especially also when talking about laptops because of HW compatibilities) need newer software than RHEL offers, based on now 3 year old base versions of most packages (except Firefox and a few others). Agreed, I exaggerated a little there ;-) What I meant is they tend to need to run the latest and greatest *compared* to servers, and as you said, especially laptops and newer hardware. -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 05 Jul 2009 11:39:44 +0100, David Woodhouse dw...@infradead.org wrote: On Sun, 2009-07-05 at 12:03 +0200, Jeroen van Meeuwen wrote: The CentOS project, or it's upstream, has a release cycle of approximately three years -not a steady release cycle of three years but that's what it turns out to be. This disqualifies the distribution(s) as desktop Linux distributions, as desktops tend to need to run the latest and greatest for as far the latest and greatest lets them. Does that make sense? As a standalone observation, perhaps -- some desktop users often don't want old, stagnant code; they'd prefer the latest bells and whistles. But it makes no sense when considered in conjunction with your apparent desire for an old, stagnant version of Fedora. What makes you think it would be any different? As described on the Feature page, but if there's any specific questions about the reasoning on there I'll be happy to answer those questions. -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 5 Jul 2009 00:22:41 +0200, Ralf Ertzinger fed...@camperquake.de wrote: Hi. On Sat, 04 Jul 2009 23:58:52 +0200, Jeroen van Meeuwen wrote I wanted to draw your attention to a feature I've proposed for Fedora 12, mysteriously called Extended Life Cycle. Is it that time of the year again? BINGO! The first response spawns a dead branch to this thread, congratulations! -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 05 Jul 2009 01:13:14 +0200, Julian Aloofi julian.fedorali...@googlemail.com wrote: https://fedoraproject.org/wiki/Features/Extended_Life_Cycle reads: Say a desktop environment runs Fedora 9 today, then within a month after Fedora 11 is released, the user can choose to either upgrade to Fedora 10 (N+1), or Fedora 11 (N+2). This is not considered a suitable amount of time for corporate desktop environments, where projects need to be defined, testing needs to be performed, resources have to be alocated, etc, before any of the actual work can be done. To be honest, I think environments that work like that won't use Fedora anyway if it wasn't supported for at least three, let's say two and a half, years. Having to agree with your general statement -not necessarily the exact period- I think neither of us can commit to extending even a single release's life cycle to that extent right now. We'll have to start somewhere, as you'll agree, and so we're thinking of starting out here; 3 releases to maintain in parallel, for those that opt-in, excluding EPEL (which has long term support in all it's aspects already). People hate work, and it would be a lot of work to maintain 5 or even six parallel versions of Fedora. Maybe something like a Fedora LTS version is more likely to be a success. While of course we'd never call it LTS, and while LTS has a very much different value proposition then what is in the current proposal (LTS is just too hard to start with at this moment), the 13 months we have now is most definitely not suitable for corporate environments. Whether 6 months of additional availability of security updates is going to help, and to what extend, we'll have to see. Compared to the current situation, that'll give an environment 7 months to upgrade beyond the moment that we now call End-Of-Life for a given release and 3 releases to choose from -certainly a lot more time then 1 month and 2 releases to choose from. I doubt whether the first six months will meet it's full potential in terms of success since the feature will need to be known to consumers, and just having it available does not make environments use Fedora all of a sudden. That too needs time to settle. Also, I should mention that in my experience, businesses that do choose Fedora despite the requirement of one upgrade per year, tend to upgrade within month 7-9 of a given release as long as you give them the full details on how to make it easier on themselves; (Revisor, optional) - Cobbler - Puppet. But hey, I like the idea behind it, let's see how it develops. Thanks ;-) I'm sure this will be continued ;-) -- Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Fedora-livecd-list] auto-biarch (x86_64 + i686) LiveDVD patch + ISO
On 06/23/2009 06:14 PM, Bruno Wolff III wrote: On Tue, Jun 23, 2009 at 10:22:07 -0400, Bill Nottinghamnott...@redhat.com wrote: Jeroen van Meeuwen (kana...@kanarip.com) said: So yeah, the problem we get with i386/x86_64 hybrids is more that we would reduce the available size to either of the Live images to half a CD or half a DVD. Some of our spins fit on half a DVD, but not half a CD. If some spins have separate media for each arch, and others do not, then that may work confusing. That said though, I don't think we've had this kinda thing discussed or decided upon... so it's a good point ;-) I think it's safe to assume that attempting to fit any 'real' biarch spin on CD would be a futile exercise. DVD shouldn't be an issue for the non-Games live spins yet, should it? A biarch rescue image would be useful. For some kinds of recoveries you need to use a rescue image matching the arch of the system you are trying to fix. I got bit by this during the F11 devel cycle. This would actually fit on a CD, too. I'm interested in exploring this. Would this most suitably fit within the Fedora Project as a spin, or maybe something else (a Fedora 12 Feature??)? -Jeroen -- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: How To Start Puppet
On 06/17/2009 11:49 PM, Robert L Cochran wrote: I just installed puppet, meaning puppet.noarch 0.24.8-1.fc11 puppet-server.noarch 0.24.8-1.fc11 On Fedora 11 x86_64. I then began following instructions at this website: http://reductivelabs.com/trac/puppet/wiki/SimplestPuppetInstallRecipe and I'm now at Step Three: start the Puppetmaster. For a Fedora installation, can I just do: su -c 'service puppetmasterd start' Well, that is if 'service' is in your path. The necessary user and group account though has been created by the RPM. -Jeroen -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Do we need split media CDs for F12?
On Tue, 16 Jun 2009 16:11:11 -0700, Jesse Keating jkeat...@redhat.com wrote: On Wed, 2009-06-17 at 01:01 +0200, Jeroen van Meeuwen wrote: The question is not *if* Fedora Unity would take on that burden, the question is whether upstream will let us. Upstream accepts reasonable patches. It happens all the time. Of course, what also happens all the time is multiple attempts to get the patches right and a lot of back and forth between the patch submitter and upstream, until consensus on the patch is reached. This also happens within the people with commit access. It's just like any other upstream. Dear Jesse, you yourself do not accept patches beyond what you then, at that moment, think are applicable use-cases of Fedora Project Release Engineering only to work something up yourself two weeks later. We've also seen upstream reject very reasonable patches -that were in the upstream repo already, authored by @redhat.com of course- be cherry-picked to another branch for whatever reason I've offered to help with (some QA concerns for one). -Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Tue, 16 Jun 2009 16:15:54 -0700, Jesse Keating jkeat...@redhat.com wrote: On Wed, 2009-06-17 at 00:30 +0200, Jeroen van Meeuwen wrote: Your signature promotes freedom^2 but this pisses you off? The reasoning behind it is what irks me. It really seems to come down to I'm just going to do it so neener neener neener :p Whether or not it is a good idea to continue to produce them, you don't care, you're just going to do it anyway. Great way to run a project. If by this you mean my judgement is not influenced by whether *you* think it is or is not a good idea, then you are absolutely right. I honestly don't care whether or not it's influenced by what I think. I just wish you project put some thought and effort into discovering why people ask for or download split CDs other than just shutting off your brain at They asked for it. What users ask for is not always what they really want, often they just don't know of better alternatives. Instead of watching users gleefully bash a nail in using a round rock, you might instead teach them about a hammer and improve their life. Rather then patronizing the users that come to us asking for CD media, saying they don't know what they want, we provide what they ask for. You think of that as a thoughtless process but then again I'm used to you saying things like that about me, I grew a thick skin over the years. If by better alternatives you mean net-install, please do realize not everyone has a network infrastructure or fast internet connection. If by better alternatives you mean LiveCDs, please note that these do not allow one to upgrade the existing Fedora installation, nor do they allow as much flexibility in configuration during the installation procedure. -Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Tue, 16 Jun 2009 16:48:07 -0700, Jesse Keating jkeat...@redhat.com wrote: On Wed, 2009-06-17 at 01:37 +0200, Jeroen van Meeuwen wrote: Dear Jesse, you yourself do not accept patches beyond what you then, at that moment, think are applicable use-cases of Fedora Project Release Engineering only to work something up yourself two weeks later. Yes, if I didn't like the patch, or how it was done, I didn't accept it. Just like any other upstream. Did I use your exact code when I did it myself two weeks later? Probably not. Oh no, you certainly did not. What I meant is that first you reject a patch because it's not within the scope of rel-eng and then two weeks later all of a sudden it *is* within the scope of rel-eng but you neglect the fact that a patch is in your mailbox somewhere. You did not say I don't like the patch or This should be done differently, you said this is not going to be in pungi because rel-eng has no use for it. We've also seen upstream reject very reasonable patches -that were in the upstream repo already, authored by @redhat.com of course- be cherry-picked to another branch for whatever reason I've offered to help with (some QA concerns for one). And they're well within their right, as an upstream project, to reject such things. Just because the patch works great on one branch doesn't mean it'll work the same on another. They are the ones to decide that. This is how opensource development works. Please do not put words in my mouth and please consider stopping to patronize me like that. I did not say they are not within their rights. I do say they are/were wrong to do so, and that is my opinion. I'm going to leave it at that or this is just going to have to become another thread. -Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Tue, 16 Jun 2009 17:56:58 -0700, Jesse Keating jkeat...@redhat.com wrote: Something else not terribly unreasonable, instead of split CD media, a single CD offered that is netinst.iso plus the contents of @core and @base if it'll fit on a CD. Then they can do whatever custom install they want, and add packages after install, either from a DVD media or from a local mirror, or from the Internet. That's exactly what Fedora Unity is about to release for Fedora 11. -Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Sun, 14 Jun 2009 14:34:37 -0700, Jesse Keating jkeat...@redhat.com wrote: On Sun, 2009-06-14 at 17:54 +0200, Jeroen van Meeuwen wrote: If Fedora Unity's motivation to continue a service to the community -at it's own expense, not yours- is holding you and the other teams hostage, call S.W.A.T. If it was just Fedora Unity's expense that'd be one thing. But it's not. Upstream anaconda is still going to have to deal with split media bugs and code. Compose tools are still going to have to handle split media cases (createrepo being a notable one). QA is still going to have to test this install method or else be faced with scrambling to fix stuff when Fedora Unity goes to make them. That's not what happened during the Fedora 7 and Fedora 8 release cycles. I really don't mind making split media, if there is a real hard need for it. I wish that Fedora Unity would do the legwork to ensure there really is a need for split CDs that isn't being met by our other offerings before claiming that split CDs are a hard need. Fedora Unity is not going to do the legwork to ensure you continue to make split media. Somebody else is going to need to figure out whether it is worthy of the corporate resources being spent at it. Like I said before, Fedora Unity can do it, has a proven track record showing to be able to do it and, if the Fedora Project decides to not ship split media anymore, will do it, regardless of how valuable you or anyone else outside Fedora Unity thinks it is. The question is however, how well is the Fedora Project willing to let us cooperate within and through the Fedora Project? Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Sun, 14 Jun 2009 18:20:09 +0200, Jeroen van Meeuwen kana...@kanarip.com wrote: On Sun, 14 Jun 2009 08:37:41 -0700, Jesse Keating jkeat...@redhat.com wrote: On Sun, 2009-06-14 at 03:30 -0500, King InuYasha wrote: A script that takes the DVD image to produce the CD versions would basically require extracting the whole DVD image and then generating new ISOs from that tree. Maybe mirrors could do it if you want to save space on the main server or whatever. That only serves to complicate matters for the users. Good chunks of our users have a hard enough time figuring out what to download, how to burn it, and how to install it. Adding in some weird script to take a DVD.iso file and split it into many smaller files isn't going to help matters, and certainly doesn't improve things for anaconda/qa/releng. This to me sounds like there's two separate problems; 1) Users might not know what to download 2) We might put resources into something that isn't used as much as we would have hoped. I'm not sure whether one single solution is appropriate for both problems. Looking at a potential cause for the discrepancy in the numbers; Look at how we offer CDs at http://fedoraproject.org/en/get-fedora I can't find them linked directly anywhere as opposed to the DVD which is directly linked from the main page. There's one explanation for the higher DVD download numbers... Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ruby-sqlite3 conflicts with rubygem-sqlite3-ruby
On Mon, 15 Jun 2009 13:37:14 +0900, Mamoru Tasaka mtas...@ioa.s.u-tokyo.ac.jp wrote: Michael Schwendt wrote, at 06/15/2009 03:52 AM +9:00: https://bugzilla.redhat.com/472621 https://bugzilla.redhat.com/472622 Reported in Nov 2008. Is it really that difficult to fix it? No, but I have not had the time to do it yet. Well, actually these two packages are _the same_ (currently versions of rpms on Fedora are different, however) The difference is that ruby-sqlite3 creates non-gem ruby module, while rubygem-sqlite3-ruby creates ruby gem. Curret ruby packaging guideline says that [1] Packaging for Gem and non-Gem use If the same Ruby library is to be packaged for use as a Gem and as a straight Ruby library without Gem support, it must be packaged as a Gem first. And we have the way and allow to create non-gem ruby module (rpm) packages as a subpackage of a package based on rubygem. So for this case ruby-sqlite3 srpm must be obsoleted by rubygem-sqlite3-ruby srpm and ruby-sqlite3 binary rpm should be created as the subpackage of rubygem-sqlite3-ruby. And the ruby-sqlite3 package (as in the separate entity in CVS etc.) has to be obsoleted. I have had it on my TODO list for a while now, it's about time I tackle it. Beat me to it if you will, I know I'll not be able to fix this in the next 4 days. Thanks in advance! -Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Ideas for Fedora Planet site
On Mon, 15 Jun 2009 11:00:02 -0400 (EDT), Seth Vidal skvi...@fedoraproject.org wrote: On Mon, 15 Jun 2009, Valent Turkovic wrote: I have a few ideas and suggestions on how to improve Fedora Planet site, please tell me what do you think about them. 1. Search - currently there isn't any search on Fedora Planet. Fedora bloggers have great posts and are a really valuable resource, searching through their greats posts with tipstricks would be a real benefit to everybody. Then setup an rss feed reader. Liferea, google reader, etc, etc. They all have a search feature. Thunderbird has one, too, in case you want to take this offline. 2. Previous posts - sometimes I'm way from the PC for days, and some times I have extra free time, it would be nice to be able to catch up with previous Fedora Planet posts by looking at previous post. Currently there is only one page of posts that is really rapidly updated, and if you miss some great post it is lost in the internet tubes forever ;) See above. Same here. -Jeroen -- Fedora-websites-list mailing list Fedora-websites-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-websites-list
Re: Do we need split media CDs for F12?
On Sun, 14 Jun 2009 15:34:19 +, Jesse Keating jkeat...@redhat.com wrote: On Sun, 2009-06-14 at 14:53 +, Robert 'Bob' Jensen wrote: I appreciate the clarification from you and Matt on the request. As you know Jesse my, and Unity's, goal has been for a while has been to get Fedora in to the hands of as many people as possible with the least amount of pain. That is why we make the Re-Spins, it was why we made the original Live media. I know and understand the extra man hours required to properly test all the different varieties of media. As I said Unity will produce CDs for those that need/want them should RE or whoever decides that it is impractical for Fedora Project to continue producing them. Another compromise I am sure that would work for us is if you produced them, handed them off to us for testing and distribution. My (mostly unfounded) worry is that Fedora Unity is reacting to requests without investigating the reasoning behind the request. Think of this as the Henry Ford problem. If all Henry Ford did was produce what his customers asked for, all we'd have right now is fast horses. What we need to be doing is investigating why these people think they need split CDs, to be certain that there is no other offering within the Fedora universe that satisfies their needs. Just producing it, somebody will download it, because they know no better, so having numbers that say somebody wanted it isn't enough in my book, and right now, I feel that the anaconda, qa, releng teams are being held hostage by Fedora Unity due to blanket claims of if Fedora Project does not produce them Fedora Unity will. If Fedora Unity's motivation to continue a service to the community -at it's own expense, not yours- is holding you and the other teams hostage, call S.W.A.T. -Jeroen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Sun, 14 Jun 2009 08:37:41 -0700, Jesse Keating jkeat...@redhat.com wrote: On Sun, 2009-06-14 at 03:30 -0500, King InuYasha wrote: A script that takes the DVD image to produce the CD versions would basically require extracting the whole DVD image and then generating new ISOs from that tree. Maybe mirrors could do it if you want to save space on the main server or whatever. That only serves to complicate matters for the users. Good chunks of our users have a hard enough time figuring out what to download, how to burn it, and how to install it. Adding in some weird script to take a DVD.iso file and split it into many smaller files isn't going to help matters, and certainly doesn't improve things for anaconda/qa/releng. This to me sounds like there's two separate problems; 1) Users might not know what to download 2) We might put resources into something that isn't used as much as we would have hoped. I'm not sure whether one single solution is appropriate for both problems. I'm also not sure the numbers that Matt has are reflecting the actual foot-print of users that require CD media, as our numbers show things differently[1]. Regrettably, we have no numbers on the Jigdo releases. I know Matt's numbers are accurate, but put in context, isn't this only redirect links such as http://download.fedoraproject.org/pub/fedora/linux/releases/11/Fedora/iso/disc1.iso like shown on http://fedoraproject.org/get-fedora/ ? Are we not missing out on *a lot* of downloading users that navigate to their mirror of preference directly? For Fedora Unity, this is considered a service to those in the community that need it. It's most definitely not considered the most efficient balance between corporate resource investments and user satisfaction. Whether it be 3 or a million smiles we get in return for doing split media, I don't care. Split media will continue to exist anyway; I release split dual-layer DVD images with the Everything Spin. Whether as such Fedora Unity is putting the pressure on the people that would rather drop the split media, I don't know. All I'm saying is that if the Fedora Project won't, we will. We've been down that path before and we all know it's pretty painless[2]. If the Fedora Project considers to no longer release split CD media, would the Fedora Project then also consider allowing Fedora Unity (members) to continue servicing those that request or even require split CD media? If that is too much to ask from a anaconda/qa/releng perspective, would the Fedora Project maybe consider finally allowing those from Fedora Unity that do it anyway, to do it *via* the Fedora Project? Kind regards, Jeroen van Meeuwen -kanarip [1] http://spinner.fedoraunity.org:6969 [2] If not, please show me where it isn't. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Sun, 14 Jun 2009 14:58:36 + (UTC), Robert 'Bob' Jensen b...@fedoraunity.org wrote: - King InuYasha ngomp...@gmail.com wrote: A script that takes the DVD image to produce the CD versions would basically require extracting the whole DVD image and then generating new ISOs from that tree. Maybe mirrors could do it if you want to save space on the main server or whatever. I think Bradley was suggesting something that the user could use to create CDs from an expanded DVD. I believe that revisor can do this pretty easily for users that already have an existing Fedora or EL install, kanarip will be speaking up on this I hope now that he is home. Revisor can do this very easily, but it's a hidden feature (not exposed in the GUI, barely documented, blabla) It's called --reuse, which allows you to not rebuild the installer images, but instead reuse existing installer images. You would point it at a mounted DVD, configure a repository pointing to the DVD, and voila, you can do anything you like with it. This is what I use to create the Everything spins too; I just change the package payload, but do not change the installer images. Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mobile phone + password = 2 factor auth?
On 05/26/2009 05:44 PM, Till Maas wrote: On Tuesday 26 May 2009 15:50:49 Seth Vidal wrote: I was changing some settings with my mobile phone company and in order to change my password they made me use what looks a lot like 2 factor auth: something I know: my current password something I have: my phone I logged in with my current password - then they txt'd me a temporary password which I had to type in to verify I was me. Which got me to wondering - if most people have a mobile phone and/or have access to one - why couldn't we use that as the second factor for our auth? A problem with phones is, that they are typically not as secure as hardware tokens. Users can install custom software on them. Also the phone may be compromised via bluetooth. It might be even possible to directly access text messages via bluetooth or maybe also wifi nowadays. Although this is entirely true, my bank sure considers my phone safe enough to send me one-time transaction confirmation codes that are only valid with the existing session. So, to hack this, you would need access to my phone as well as my current session. -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
FUDCon and Linked-In
I thought I'd try something new (or at least something I hadn't seen before): For those of you on Linked-In, please consider expressing your interest in FUDCon 2009, or let your network know that you are attending: http://events.linkedin.com/FUDCon-EMEA-2009/pub/75904 Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: [Fedora-livecd-list] Reconstructor
On Tue, 19 May 2009 15:18:54 -0400, Bryan Kearney bkear...@redhat.com wrote: I am sure folks have seen this: http://reconstructor.aperantis.com What I thouhgt was interesting (besides making a pretty ui) was starting with an existing livecd iso. May speed up the process a bit in some places... dont know. livecd-tools (and the pretty Revisor UI) have a feature to base a compose off of another LiveCD since... like... the beginning of either of these projects... or at least since midst 2007. Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: Why would I want Fedora?
On 05/15/2009 07:14 AM, Rahul Sundaram wrote: On 05/15/2009 10:36 AM, Jeroen van Meeuwen wrote: I would like to object to the image of Fedora merely being an alternative, especially in the context of being an alternative to Microsoft Windows. If anything, Microsoft Windows is a very sad (or humorous) alternative to Linux. Well, the point of describing it that way is the end users don't necessarily understand the idea of an operating system but most people would know what Windows is. By describing it as a alternative, you get the basic idea across. Try explaining to a non technical person, what Linux is. I hear you. I do not necessarily think the description needing an update is wrong, I just wanted to emphasize that positioning Fedora as an alternative to Microsoft Windows is the wrong way to go in my opinion. Most users actually don't know what Windows is either. They just know they have Foo here, and thus want Foo there. From that perspective, it's almost like the Apple community; once you're hooked, you're hooked, whether you know what it is or how it works doesn't matter. Then there's those that do look a little further and those probably do know what an operating system is -although they might not (yet) realize that Operating System Microsoft Windows. Regardless, previous two paragraphs barely add to the discussion ;-) I think the Fedora Project is stronger in it's advocacy, then it is in user-perspective expectation management. I also think the Fedora Project is stronger in it's development edge/focus, thriving Free Software innovation by early adoption and being a platform (often? most?) used by upstream developers, yada yada, blabla, insert other things here, then it is in spreading Linux out there. That being said, of course it doesn't mean we shouldn't attempt to improve that situation and what I'm saying is I don't think the angle we should take at that is by positioning Fedora as an alternative to Microsoft Windows. Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Why would I want Fedora?
On 05/15/2009 08:03 AM, Jeroen van Meeuwen wrote: I also think the Fedora Project is stronger in it's development edge/focus, thriving Free Software innovation by early adoption and being a platform (often? most?) used by upstream developers, yada yada, blabla, insert other things here, then it is in spreading Linux out there. Reading this back I may have been a little careless leaving out the fact that in spreading Linux we're not entirely doing a bad job, given the recent amount of exposure generated with the numbers we could honestly come up with ;-) These numbers in fact say we're the greatest in spreading Linux, but the question that comes to my mind is; Do we, or did we, attract these users / achieve this large install-base because we keep true to our original cause resulting in a product they want to and choose to use, or is it because we market Fedora so well it just so happens to be installed on so many machines (although many users might actually not care that it's Fedora)? --Jeroen -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Why would I want Fedora?
On 05/15/2009 02:57 AM, Rahul Sundaram wrote: Hi I helped write what is described in the front page of what Fedora is for. To quote from http://fedoraproject.org Fedora is a Linux-based operating system that showcases the latest in free and open source software. ... While I think what follows after that is still useful, perhaps we can start with something like: Fedora is a free alternative to proprietary operating systems like Microsoft Windows and provides a easy and powerful graphical environment, office suite, games and more. It is a secure and virus-free experience with brand new releases full of major improvements every six months all for free. I would like to object to the image of Fedora merely being an alternative, especially in the context of being an alternative to Microsoft Windows. If anything, Microsoft Windows is a very sad (or humorous) alternative to Linux. --Jeroen -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: How to creating install images by koji ?
On 05/08/2009 04:14 AM, À wrote: http://fedoraproject.org/wiki/Koji has said that koji can creating install images , but I have not find cmd yet . did anyone can help me ? I think the terminology used here is a little off... Kojid as a daemon is actually responsible for triggering an application called 'mock' using all the correct parameters and configuration for a certain type of build. As such, it is responsible (through mock) for creating the clean build chroot and triggering the build of a RPM package, not necessarily for creating the installer images that make a set of CDs or the DVD perform the installation of Fedora. Hope this helps, Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: How to generate a .template and .jigdo from an iso image?
On 05/08/2009 08:35 AM, Marcelo M. Garcia wrote:
Hi
I read the man page. It says that I have to specify only one of the
options -i, -j or -t. OK. If I use only -i, my template has the
same size of image, then there is no point in using jigdo. There must be
something more.
My question is how Fedora generates the .template with only 11.1M? The
command jigdo-file -i CentOS-5.3-i386-bin-DVD.iso it's not enough.
Attached is the script Fedora Unity uses to jigdofy it's Re-Spins. Note
the function jigdofy() in the top that may just help you get the
syntax right.
Note the double slash in the two directories passed to the jigdo-file
make-template command, which functions as a delimiter for jigdo-file,
so that in the --label parameter, we can 'label' the path and then
attach a URI (--uri) to be used in the resulting .jigdo file instead.
$1 is the (fully qualified) path to the .iso image,
$2 is the base architecture for the .iso image (i386, x86_64 or ppc in
our case), and
${version} is the Fedora $releasever (9 or 10 right now).
Also note that /data/os/distr/fedora is a local, full mirror and that
/data/os/archive/fedora is a local, full archive (with package files
that have been removed from the mirror because for example they've
expired and have been superseeded by another update to said package).
Kind regards,
Jeroen van Meeuwen
-kanarip
jigdofy_everything.sh
Description: Bourne shell script
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Revisor article on PCPlus
We're used to thinking of Linux distributions being set in stone. They're either KDE or Gnome, use a certain kernel and bundle certain applications. But this doesn't have to be the case. If you find yourself making the same adjustments each time you install a new distribution, it's worth creating your own customised version. Revisor is a tool that lets you do just this, and in this tutorial, we'll show you how... Read more: http://www.pcplus.co.uk/node/3020 Please digg: http://digg.com/linux_unix/Tutorial_Build_Your_Own_Linux_Distro_With_Fedora Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Slogan, redux
On 04/23/2009 10:48 PM, Mathieu Bridon (bochecha) wrote: Let it ROAR That's actually nice ! Is « roar » an action verb in english ? If so, it could be nice to use it as the main verb of the sentance, something like « Roar with pleasure » (but with something other than « pleasure », it's a Linux distribution, not an orgasm, Actually I bet there's people that disagree with you here. even though some might have weird sexual perversions :) Here too, but those I hope are different people... -Jeroen -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
NLUUG Filesystems Storage (May 7th)
Hello, I'm sending you this announcement because it's a very interesting event organized by the Dutch UUG, on the subject of Filesystems Storage, with key people giving keynotes and sessions amongst which is the core developer of ext4. Kind regards, Jeroen van Meeuwen -kanarip == Every bit counts. From a single byte to billions of images, from one line of text to a gigantic tangled semantic web of documents, from clay tablets to 3D holographic memory, storage and the means to organize storage have always been important to humanity. Never underestimate the bandwidth of a station wagon full of tapes, it was said; a sailboat crossing the Atlantic still manages rates of a little over 1GB/s end-to-end. A petabyte of storage weighs about as much as a small car, but a large physics experiment can fill that up in less than a week. The modern rate of data production and amount of data storage --and crucially also data search and retrieval-- have pushed the limits of computer storage and the traditional file system further and further back. The NLUUG Spring Conference 2009 focuses on storage and the means to organise it: file systems, physical storage, connections and search. The keynote speaker at the conference will be Ted Ts'o, author of the ext4 file system in Linux and CTO of the Linux Foundation. Other subjects at the conference are DRBD, desktop search and ZFS. The conference is in conference center 'De Reehorst' in Ede, The Netherlands. Information about the full programme and registration can be found at the conference website: http://www.nluug.nl/events/vj09/index.html As always members of NLUUG and sister organisations as well as students get a hefty discount. -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: mergerepos of f10 x86_64 release and updates does not contain perl or some other packages?
On Tue, 17 Mar 2009 12:08:43 -0400, Mike Bonnet mi...@redhat.com wrote: Steve Traylen wrote: Note the main box I am working on is 32 bit F10 box which may be relevant and the reason why only subsequently the i386 build works? You can't use a x86_64 chroot on a i386 box, nothing in the chroot will run. I suspect rpm is preventing installation of x86_64 packages on a i386 host. I think it's YUM that does not include the x86_64 in the pkgSack (using yum.rpmUtils.arch.getArchList() over rpmUtils.arch.getBaseArch()). Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: This Weekend?
Jack Aboutboul wrote: Hey Guys, I was wondering if anyone had anything interesting they planned on doing over the weekend and whether anyone needs help. The Dutch are getting together and see how they can improve the Fedora community in the Netherlands March 7th. Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: [Fedora-livecd-list] What to do if a package requires fedora-logos?
Christoph Wickert wrote: Am Mittwoch, den 04.03.2009, 22:51 +0200 schrieb مؤيد السعدي: use system-logs which will be either generic-logos or fedora-logos if the icon needed by lxde is not provided by generic-logos, file a bug report against generic-logos This will take too much time and it wont help me anyway because of 2. 2. Even if I provide a neutral icon ether in system-logos or in my package itself, I need to specify the icon with it's full path. in both cases the needed icon should be provided by both generic-logos or fedora-logos let's say generic-logos should provide a desktop independent icon for main menu in less famous desktops And how would this help me? Let's say we include icon-panel-menu.png also in generic-logos, what do we gain? I still need an absolute path like in /usr/share/icons/Bluecurve/24x24/apps/icon-panel-menu.png. I'm not sure why that would not be feasible. Right now, generic-logos also ships /usr/share/kde4/apps/ksplash/Themes/SolarComet/1280x1024/logo.png You can just ship anything that is in fedora-logos, because the packages conflict (through an explicit Conflicts: RPM header), or am I missing something? If I don't specify the full path it is not predictable which size the panel chooses. I guess, from a very distant point of view, this is the real bug. XFCE had a similar problem at some point when F10 was in rawhide later they provide the icon, Yes, and it nearly took a wohle release until they finally shipped the icon in system-logos. :( I think generic-logos is open for provenpackagers like yourself. You can log the bug and fix it. Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: Revisor (or Anaconda?) spin - unable to install on i586
Martin Langhoff wrote: On Thu, Feb 26, 2009 at 9:46 PM, Jeroen van Meeuwen kana...@kanarip.com wrote: If I gave you some 2.1.4 revisor packages to test on Fedora 9 (I'm not sure they work but there have been no major changes), are you able to test them? Yes. My only 'compat' concern is with anaconda. If they expect anaconda smarts that aren't there... Well, Revisor (by means of the version-specific buildinstall scripts in /usr/lib/revisor/scripts/) on Fedora 10 is able to compose Fedora 9, and only changes in things -like squashfs major version mismatches (like right now between a Fedora 9+ and an EL-5 station) may cause issues. The Revisor version itself... shouldn't cause all that many issues. If you want a quick try you can do: autoreconf -v ./configure make rpm in the source tree. Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Revisor (or Anaconda?) spin - unable to install on i586
Martin Langhoff wrote: On Tue, Feb 24, 2009 at 3:12 PM, Martin Langhoff martin.langh...@gmail.com wrote: Are you planning on updating the F-9 or F-11 packages with it? Hi Jeroen, - is there a revision coming on the F-9 or F10 branches? I'm planning a release for F-10. - can you check whether the F-9 package (2.1.1-7) matches what's in git? From what I can see, it doesn't, so I can't build a local rvisor pkg I can trust :-/ ... The packages releases are always behind the GIT repo, because the packages get created from what is in the GIT repo (at some point). If I gave you some 2.1.4 revisor packages to test on Fedora 9 (I'm not sure they work but there have been no major changes), are you able to test them? Kind regards, Jeroen -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Red Hat Fedora Linux 10 nears 1 million user mark
Rahul Sundaram wrote: Hi, Two things: 1) Should we get reporters to stop calling it Red Hat Fedora? Yes. Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Revisor (or Anaconda?) spin - unable to install on i586
Martin Langhoff wrote: On Tue, Feb 17, 2009 at 3:17 AM, Jeroen van Meeuwen kana...@kanarip.com wrote: Can you maybe send me a log file with both Revisor as well as YUM set to debuglevel 9? Hi Jeroen, last week you mentioned the logs made sense... any news on this track? Did this evolve into a different thread subject and I missed it...? Hi Martin, did I forget to reply with a commit code? Sorry! I did this commit http://git.fedorahosted.org/git/?p=revisor;a=commitdiff;h=c76d857046e931121ab8241a268fd921dfa8960a to prevent F9 and above to end up with no allarch packages being selected. Could you test this and see if it helps? Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Revisor (or Anaconda?) spin - unable to install on i586
Martin Langhoff wrote: On Mon, Feb 16, 2009 at 2:52 PM, Jeroen van Meeuwen kana...@kanarip.com wrote: Since your first mail, I've tried to reproduce this. I have no problems producing installation media with both openssl.i386 and openssl.i686 in the RPM payload (Packages/ directory) - with either respin mode or without, which I was thinking may have been the issue. This however is using a fresh git clone off of master, not the released version of Revisor on Fedora 9. We are not using respin mode, we're creating it from scratch... Like I said either with or without respin mode, both openssl.i386 and openssl.i686 are pulled into the RPM payload. Can you maybe send me a log file with both Revisor as well as YUM set to debuglevel 9? For Revisor, that's --debug 9, for YUM that's debuglevel= in the appropriate configuration file in /etc/revisor/conf.d/ Thanks, Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Revisor (or Anaconda?) spin - unable to install on i586
Martin Langhoff wrote: Hi Jeroen, we have revisor on F-9 ignoring the requested arch and building the spin based on the host arch only - is this a known issue? The revisor-made spin we have doesn't work on i586 :-/ more details below... On Sun, Feb 15, 2009 at 10:58 AM, Martin Langhoff martin.langh...@gmail.com wrote: the olpc XS spin is hitting a problem installing on i586s (and that includes our own XO). The problem seems to be well known -- anaconda composes based on the arch of the build host rather than on the arch requested, as described in: https://fedorahosted.org/revisor/wiki/AnacondaUpdates#TheUnabletoInstalloni586Example2 The revisor conf says architecture=386, yet we are getting _only_ openssl i686 on the iso, which won't get installed on 586, so everything breaks on the (partially installed) machine. I'm away from my buildbox today -- Jerry's been testing and reports that pungi-driven composes also put an openssl-i386 on the iso, while revisor-driven composes don't. So it sounds like the problem is perhaps in how revisor drives anaconda? Any hints or ideas? It seems to be a well known problem...? (the compose host is a Fedora-9 box, that follows updates.newkey) Hi Martin, Since your first mail, I've tried to reproduce this. I have no problems producing installation media with both openssl.i386 and openssl.i686 in the RPM payload (Packages/ directory) - with either respin mode or without, which I was thinking may have been the issue. This however is using a fresh git clone off of master, not the released version of Revisor on Fedora 9. Are you composing Live media by any chance? I can see how there is no .i386 version of openssl installed. Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: cgit to replace gitweb?
seth vidal wrote: On Fri, 2009-02-13 at 15:49 -0500, Bill Nottingham wrote: Well, a URL that was: /git/?p=initscripts.git;a=commitdiff;h=252c7c1bf9779dbdba94abe47350c866ba8ca421 is now (in the test instance): /cgit/initscripts.git/commit/?id=252c7c1bf9779dbdba94abe47350c866ba8ca421 We may be able to do a rewriterule? for the simple cases, sure. I doubt we'll be able to do all the tag/branch cases easily.. How about the old location is kept intact for a while while we attempt to gain some statistics on it's usage? -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Calendaring system?
Adam Williamson wrote: Hi, guys. Uh, quick intro for those who see the redhat.com and wonder who I am - I'm Adam Williamson. I'm new in the Fedora QA department here at RH, my job is to drive community involvement in Fedora QA. I came over from Mandriva where I was the community manager. I'll be working from my home in Vancouver, Canada. I'm new on the list so this may have come up before, in which case apologies :). Something I thought would be nice to have for QA community is a public calendar system where dates of events like test days can be published. Obviously it's silly for me personally or the QA team to take on the job of hosting a calendar server, but it was suggested that it would be a good project for the infrastructure team, and other groups within Fedora could probably benefit from it. Does it sound like a good idea? Anyone want to have a go? Or is there something already, that I don't know about? Thanks! I've not seen anything in this thread yet, so it may have been mentioned before; MediaWiki has a couple of calendering plugins that will allow days to be allocated; I looked into this for our meeting schedule but since none of them include any times for appointments I found it to be useless. Nonetheless, it could be worthwhile for allocating Test days and Events -and things of the sort. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Calendaring system?
Clint Savage wrote: On Mon, Feb 9, 2009 at 12:36 PM, Jeroen van Meeuwen kana...@kanarip.com wrote: Adam Williamson wrote: Hi, guys. Uh, quick intro for those who see the redhat.com and wonder who I am - I'm Adam Williamson. I'm new in the Fedora QA department here at RH, my job is to drive community involvement in Fedora QA. I came over from Mandriva where I was the community manager. I'll be working from my home in Vancouver, Canada. I'm new on the list so this may have come up before, in which case apologies :). Something I thought would be nice to have for QA community is a public calendar system where dates of events like test days can be published. Obviously it's silly for me personally or the QA team to take on the job of hosting a calendar server, but it was suggested that it would be a good project for the infrastructure team, and other groups within Fedora could probably benefit from it. Does it sound like a good idea? Anyone want to have a go? Or is there something already, that I don't know about? Thanks! I've not seen anything in this thread yet, so it may have been mentioned before; MediaWiki has a couple of calendering plugins that will allow days to be allocated; I looked into this for our meeting schedule but since none of them include any times for appointments I found it to be useless. Nonetheless, it could be worthwhile for allocating Test days and Events -and things of the sort. Kind regards, Jeroen van Meeuwen -kanarip I think the point I'm continuing to make is that it should support caldav or something similar. The protocol defines a protocol, so the client applications themselves shouldn't matter, but we do need to have a way to communicate with the calendar server. My intention isn't to discount MediaWiki or Zikula as a possible platform for a calendaring client, but to say that the features you suggest are not what we're after here. Instead I'd say that those two applications could push/pull data from the calendar server (using caldav). The events listed in the caldav server can be manipulated by these other applications and probably through an API which could include Access Control Lists based upon FAS rights. I can see this being a bit of an undertaking, but it can really benefit the Fedora Project as a whole. As I stated in my previous email, I've got a draft up of all the features we'd like to see (it's pretty empty right now) and I'll probably go ahead and list some of this email there. But for those of you who are interested in helping me get that wiki page more complete, feel free to visit: https://fedoraproject.org/wiki/User:Herlo/Fedora_Calendar_Project_Desired_Features_(Draft) Keep the thoughts coming, I want to see this project succeed! Dude, I'm sorry I even brought it up. Good luck! -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: get Fedora puppet modules
Mike McGrath wrote: On Thu, 5 Feb 2009, Fabrizio Buratta wrote: Hi all! Is it possible to get the fedora infrastructure puppet modules? If so, how to get them? We don't currently publish them but we have plans to. If you're interested in specific modules let me know and I can make sure to get them to you. The main issue is ensuring they're properly sanatized. We used to store passwords in configs and manifests way back when. Also we do some things in a messy way still, I'd hate to give people the idea that its the right way to do it :) Could the effort of cleaning them up be aligned with development on commonly available modules, such as puppetmanaged.org (potentially move/copy the git repos for each module to fedorahosted infra?). Not only would I be very happy if that happens, it'd also mean a little more involvement in development of the Fedora Infra modules from my side. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Change request
Hey,
I'd like the following patch to be applied. It fixes the redirects for
RPM-GPG-KEY files for secondary arches not to be redirected to
/pub/fedora-secondary/, so that Jigdo's can find the files.
Kind regards,
Jeroen van Meeuwen
-kanarip
commit b240e804a23e4171d21de19f0de0ec4b34586654
Author: Jeroen van Meeuwen kana...@puppet1.fedora.phx.redhat.com
Date: Tue Dec 30 01:02:00 2008 +
Fix the rewrite for secondary architectures.
The rewrite caused GPG keys in primary architecture install trees
matching the name of a secondary architecture to be rewritten to
secondary-archs.
diff --git a/configs/web/download.fedoraproject.org/rewrite.conf
b/configs/web/download.fedoraproject.org/rewrite.conf
index 63f2e45..adc7a3c 100644
--- a/configs/web/download.fedoraproject.org/rewrite.conf
+++ b/configs/web/download.fedoraproject.org/rewrite.conf
@@ -4,8 +4,8 @@ RequestHeader set CP-Location /mirrormanager
RewriteEngine On
-RewriteCond %{REQUEST_URI} ^/pub/fedora/linux/.*ia64.* [OR]
-RewriteCond %{REQUEST_URI} ^/pub/fedora/linux/.*sparc.*
+RewriteCond %{REQUEST_URI} ^/pub/fedora/linux/.*[/]+ia64.* [OR]
+RewriteCond %{REQUEST_URI} ^/pub/fedora/linux/.*[/]+sparc.*
RewriteRule ^/pub/fedora/linux/(.*) /pub/fedora-secondary/$1
RewriteRule ^/(.+)$
balancer://mirrorsCluster//mirrorlist?path=$1redirect=1 [P]
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Update revisor
Frank Murphy wrote: Jeroen van Meeuwen wrote: You may be interested in participating in our Test Team even if only you report your upgrade from Fedora 8 went good or bad. http://lists.fedoraunity.org/pipermail/test-team/2009-January/000304.html Kind regards, Jeroen van Meeuwen -kanarip Hi Jeroen, I would like to get involved with Unity testing. Will be getting a couple of boxes purely for that. What I was wondering is, (similar to previous poster) Is if in co-operation with PackageKit. If the Unity disks could be used as a formal u\g path, for the freemedia program. (As Unity states it is not officially sponsored, as a result of which we cannot avail of them in that situ.) But if they could be seen as a viable u\g, along with official Disk? We can move this to Amb-list if you fell it more appropriate. Hi Frank, I'm not sure I understand exactly what you mean, but here it goes; As far as the Fedora Unity Re-Spins is concerned, co-operation with PackageKit stretches as far as the co-operation between PackageKit and General Availability media (the media officially released and distributed by the Fedora Project). The FreeMedia program has been using some of the Fedora Unity Re-Spins in the past, so it might be possible for anyone to obtain the Fedora Unity Re-Spins through the FreeMedia program -if they offer them. If they do not offer the Fedora Unity Re-Spins, one might request them explicitly but the FreeMedia program may choose to not ship Fedora Unity Re-Spins. Now, I don't know what you mean by u\g, but the Fedora Unity Re-Spins are tested extensively for different types of installations, and different types of upgrades as well. So, if u\g means upgrade; yes, the Fedora Unity Re-Spins are viable media to perform upgrades with. I hope that answers your questions, but if not, don't hesitate ;-) Kind regards, Jeroen van Meeuwen -kanarip -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Introduction Teb (Zikula / Documentation project)
Teb (Zikula NL) wrote: Hi all, I have just subscribed to both the fedora-infrastructure-list and the fedora-docs-list to keep you (and myself) updated about the documentation project. Hello Arjen, good to hear we have another Dutchman on board ;-) Welkom! Kind regards, Jeroen van Meeuwen -the Other Dutchman ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Update revisor
Terry Polzin wrote: My goal is to respin a DVD image with all the updates and then upgrade from it. Doing this makes the upgrade process faster as after the first boot you don't spend several hours updating. It is not clear what configuration files, (and I am sure that there is more than one that needs to be modified) to provide the ability to build a new and updated F10 image. I am reluctant to build a new image on my one laptop which is running F10 as something possibly KDE4 is sucking resources away even though this is a laptop with (an older) 2ghz CPU. Revisor possibly needs the ability to download updated config files from the mirrors. You do not want Revisor version in Fedora 8 to spin the Fedora 10 media you are going to use to upgrade. Fedora Unity is working on a Fedora 10 Re-Spin as we speak (in fact, I am working on it while I'm typing this, and Fedora Unity's Test Team will take over as soon as I publish the product somewhere). You may be interested in participating in our Test Team even if only you report your upgrade from Fedora 8 went good or bad. http://lists.fedoraunity.org/pipermail/test-team/2009-January/000304.html Kind regards, Jeroen van Meeuwen -kanarip -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Automating hosted projects?
Stephen John Smoogen wrote: Fedora Unity and Cooperation KDE- Gnome might raise some eyebrows but would not be easy to auto-sanity-check. /me raises one or two eyebrows... I see we're being used as an example but I'm not sure I understand what you're saying ;-) Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Why puppet uses config instead of configs?
susmit shannigrahi wrote: Hi, In puppet when we add a new file, we use this lines in the .pp files: source = 'puppet:///config/web/applications/FreeMedia-error.html', where as the actual location of the file (FreeMedia-error.html) is [sus...@puppet1 puppet]$ find -name FreeMedia-error.html ./configs/web/applications/FreeMedia-error.html So the source in the .pp file should be 'puppet:///configs/web/applications/FreeMedia-error.html' Why this discrepancy? Just curious... The [config] fileserver mount may point to /path/to/configs/, which would allow this discrepancy to exist. If you are going to change anything, maybe consider using [files] vs. /path/to/files/ since that name for the mount appears to be most commonly used. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Interview with HSIB
Hey there, I was interviewed by HowSoftwareIsBuilt.com a few weeks ago; the interview's transcript is online now; http://howsoftwareisbuilt.com/2008/12/21/interview-with-jeroen-van-meeuwen-fedora-project-vice-president-fedora-emea/ Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Pungi 2.0 in F9
Bryan Kearney wrote: My goal is to not re-write the logic in these other tools (appliance-creator, punci, virt-convert, ec2-converter, etc) but rather to make a controlled use of them since the output of one becomes the input to another. To achieve this, the code basically replaces the command line bits of the tools.. not the underlieing libraries. In the case of Pungi, this distinction was less clear then with the other tools... which is why I think the API changed so much from 1.2.X to 2.X The one thing you are using from pungi is the gathering of the source RPM's, am I right? -Jeroen -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: [Fedora-livecd-list] [PATCH] Few tab issues to get it running
[EMAIL PROTECTED] wrote: From: Bryan Kearney [EMAIL PROTECTED] --- imgcreate/kickstart.py |2 +- tools/livecd-creator| 26 -- 2 files changed, 13 insertions(+), 15 deletions(-) mode change 100644 = 100755 tools/livecd-iso-to-disk.sh I finally came around to applying this diff; I've pushed the update to EPEL-5 testing. Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Re: Revisor / yum odd error with f9 updates.newkey repo: Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386
Connie Sieh wrote: On Tue, 14 Oct 2008, Jeroen van Meeuwen wrote: Martin Langhoff wrote: Right now, revisor can build a pristine F9 installer CD but cannot build a F9 + updates installer CD. The problem appears by merely enabling the additional repo in the stock F9 config files that ship with Revisor. It has also been reported elsewhere: https://fedorahosted.org/genome/ticket/28 The error is Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386 even though the updates.newkey repo clearly has the full set of glibc-* packages at 2.8-8 Fedora Unity has just released a Re-Spin of Fedora 9 + updates, and we have not seen this problem. I installed this respin and then tried to rebuild fedora 9 + updates on this respin and got this glibc error. Like I said there was an error in selecting packages that I fixed in Revisor. FWIW, also, this should be a warning, not an error and it should definitely not be fatal. I tend to let Revisor exit out if something is serious enough or fatal for the compose. Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: revisor - strange regression with comps-cleanup misplaced...
Martin Langhoff wrote: After 2 weeks of not building the XS build, I built it again today. It didn't want to build. Running with --debug 10 the output ends with... Running command: /usr/bin/xsltproc --novalid -o /var/tmp/revisor-pungi/0.5/xs-f9-i386/comps.xml /usr/share/revisor/comps/comps-cleanup.xsl /var/tmp/revisor-pungi/0.5/xs-f9-i386/comps.xml Extra information: /var/tmp/revisor-rundir False None Got an error from /usr/bin/xsltproc (return code 4) xsltproc's manpage says that 4 means trouble parsing the stylesheet. I tried to look at/usr/share/revisor/comps/comps-cleanup.xsl and it wasn't there. It was a directory higher. this fixed the problem: sudo ln -s /usr/share/revisor/comps-cleanup.xsl /usr/share/revisor/comps/comps-cleanup.xsl Fixed in GIT, thanks. Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Revisor / yum odd error with f9 updates.newkey repo: Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386
Martin Langhoff wrote: Right now, revisor can build a pristine F9 installer CD but cannot build a F9 + updates installer CD. The problem appears by merely enabling the additional repo in the stock F9 config files that ship with Revisor. It has also been reported elsewhere: https://fedorahosted.org/genome/ticket/28 The error is Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386 even though the updates.newkey repo clearly has the full set of glibc-* packages at 2.8-8 Fedora Unity has just released a Re-Spin of Fedora 9 + updates, and we have not seen this problem. Nevertheless I dug through the code and found a little discrepancy, now having resolved the issue (in GIT). Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New Anaconda for F9?
William F. Acker WB2FLW +1-303-722-7209 wrote: Was this intentional? Very cool! Completely intentional. Lots of minor bugfixes, anaconda builds again on up-to-date systems, and some additional significant Fedora 9 secondary architecture fixes were applied as well. Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: New Anaconda for F9?
Isamar Maia wrote: Where can I find a stage2.img image with this bugfixes already applied ? Not on any official Fedora Project location, the install tree is not going to be rebuilt by the Fedora Project as far as existing releases is concerned. However, the Fedora Unity Project is about to release one of it's infamous Re-Spins which include a new rebuilt stage2.img as well. However, this Re-Spin will first need to pass our testing before we release it. Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
