Re: [@core] working definition for the minimal package set
On 11/16/2012 06:35 PM, Matthew Miller wrote: On Fri, Nov 16, 2012 at 09:06:03PM -0500, Scott Schmit wrote: On Fri, Nov 16, 2012 at 09:26:30AM -0800, Jesse Keating wrote: Tools outside of anaconda don't have to force @core, which opens those tools up to far more creative payloads. So where's that put kickstart? Or is the assumption that anyone who wants a more-minimal target won't be going that route? Many of the outside-of-anaconda tools use kickstart too; they just don't necessarily have the same rules for pulling in core automatically. I don't know if that's necessarily a great situation, since it means the same kickstart will do different things in different situations. This is kinda the point of breaking out pykickstart, so that other tools can make use of the kickstart file format and parsing utilities without having to drag in the rest of anaconda and anaconda's rules. In fact, pykickstart is all about the format and parsing. It's up to other tools to actually /act/ upon the data. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/11/2012 10:01 PM, Seth Vidal wrote: Jesse, To be fair - gnome/kde importing something into rawhide/branched that's not finished doesn't shut down everyone else's ability to test the distro I think it is disingenuous to talk about another distro using anaconda - b/c the only other one that does, directly, is rhel - and they're downstream of fedora, too. That doesn't mean things can be dictated - but it does mean that breaking/delaying fedora is not something that should be done lightly. I think holding anaconda to higher standards is not a ridiculous concept. For years the requirement for yum and rpm (even in rawhide) has been 'never commit something so broken it cannot be used to revert itself'. but I'm positive that this conversation is long past the point of productivity so... I can't disagree with this message. I'll also point out that we didn't have a lot of choices for F18. We could either leave the existing anaconda package there (which was completely broken) or import the partially functional newUI code base. We went with the option that would provide the most functionality, which was the newUI code base. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/12/2012 08:45 AM, drago01 wrote: And there was a third option ... port over the old anaconda to the F18 changes. (so you'd have less changes). Which would have taken just about as long to get working, and would delay the newui move further. But that's OK, you can keep banging that drum. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/12/2012 08:58 AM, drago01 wrote: How so? You'd have to just port over the other layers to work with the new stuff and in F19 focus on the UI. Now you had to do both at the same time with the same amount of man power. Changes in the dracut environment broke assumptions in the runtime environment. Code in newUI is different from old code in some of the same areas, which means doing the work twice instead of once. Not to mention porting forward all the other bits of F17's anaconda that doesn't work with F18's userland tools/apis. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 11/12/2012 05:25 PM, Matthew Miller wrote: On Mon, Nov 12, 2012 at 12:27:34PM -0800, Jesse Keating wrote: But there was a non-UI way. Does that no longer work? The non-UI way was kickstart. But you can't deselect (-) mandatory packages in a group. @core is primarily made up of mandatory packages. Huh. I could swear I've done that before and it worked. In any case, it is _certainly_ working with appliance-creator right now. :) appliance-creator may not force @core. The force of @core is an anaconda thing. This actually opens up another axis, here, so we could have one standard for mandatory packages (kernel+init, or up-to-yum+net) and a second level for default (up-to-yum+net, +ssh,cron,etc). Even without a UI exposed, the distinction between mandatory and deselectable is huge for kickstart, which I think is common for _most_ of our use cases. Yeah, that's a thing that probably could be done. Bug again I'd like some input from people who have made the switch to these packages being mandatory. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 06:23 PM, Kevin Kofler wrote: But they wouldn't be able to claim a misunderstanding as now and FESCo would have a standing for requesting a reversion. Plus, in this case, Anaconda isn't an upstream project in the first place, we are upstream. Fedora is just one of the downstream users of Anaconda. It is incorrect to assume that the upstream Anaconda development can be dictated solely by Fedora, any more than upstream RPM development can be dictated solely by Fedora. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Nov 10, 2012, at 11:21 AM, Kevin Kofler wrote: Jesse Keating wrote: Fedora is just one of the downstream users of Anaconda. It is incorrect to assume that the upstream Anaconda development can be dictated solely by Fedora, any more than upstream RPM development can be dictated solely by Fedora. If you want to be truly independent of Fedora, you need to do your development elsewhere and only import finished and fully working upstream releases into Rawhide (which need to be testable by Alpha and 100% complete by Beta), as for any other upstream project in the critical path. As long as you (ab)use Rawhide to do upstream development and alpha-testing in, Fedora WILL dictate how you do development. Sorry, that's not a hard requirement of any other upstream, and KDE/Gnome have frequently used snapshots in rawhide/branched. But nice try. --jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Minimal Core SIG -- please join if you're interested
On 11/09/2012 06:45 AM, Kamil Paral wrote: I wonder whether Core is a good word for Fedora Minimal installation SIG. Because currently the minimal installation uses @base yum group. @core group is included always, whether you want it or not. If you really want to have a_core_ system, you must use kickstart like this: %packages --nobase %end This isn't true anymore. --nobase doesn't do anything because there is no @base. It was renamed to @standard, and it's no longer selected by default in kickstart. Also, the minimal install (GUI or TUI) does %packages \n %end as well, only @core gets installed. So the result is the same as doing the kickstart. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 08:48 AM, Jóhann B. Guðmundsson wrote: No I assume everyone expected the Anaconda developers to handle that if not they would have asked for assistance in that regard and outlined the steps necessary to do so which I assume would have been minimal if necessary et all since I expect the installer to be able to work on packages in F16 or F17 or F18 for that matter hence the installer would be unchanged while the package set he is installing would only change. Is my assumption wrong in that regard as in the installer in F17 could not have been used and if so why? A significant amount of work had to be done to the newui code base (which was largely developed and tested on F17) to get it to work in an F18 environment. To get the F17 code base to work in an F18 environment would have taken even more work, and that would would have had to be done twice. Once for the F17 code base, once for the F18 code base. We just don't have that many developers, so newui would be delayed again, and we'd have to do the same thing again for F19. Meanwhile any feature that requires installer interaction would have to either be punted, or coded twice, and noted in a growing list of things to re-check after the newui cut over to ensure it didn't break the new feature. Anaconda is increasingly dependent upon the environment around it, which has a tendency to change in unexpected and weird ways between releases. Much of anaconda development work is reacting to subtle bugs that arise in previously working code, being detective to figure out what has changed in the environment and why and what the new rules on the ground are so that we can make things work again. We operate in a space that people don't think about, and that doesn't get any real attention on a running system. When people make changes to the pre-root environment they think it's fairly isolated and that changes can happen with impunity, because runtime will be fine. Runtime people make changes but think it's fine if their own stack continues to work with the change or their stack is updated to work with the change, but Anaconda is left broken. We are not plug-n-play. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 11:40 AM, Jóhann B. Guðmundsson wrote: Pointing out how the installer currently works does not change my opinion on the fact that if an installer ( any installer ) cannot run on his own bits isolated from the package set he is about install is a design flaw and is something that should be corrected ( from my pov ). I think you're talking about booting an F17 kernel, using an F17 content initrd and stage2 (F17 version dracut, systemd, udev, polkit, dbus, parted, lvm, ext/btrfs/xfs tools, glibc, yum, rpm, selinux, grub, etc...) and just point it at a newer repository of packages. While that has some obvious issues, like new hardware doesn't work with old kernel/syslinux/grub/udev/etc..., there are further issues as some configuration has to happen within the installed system, which means knowing how things like firewall config, network config, mount options, root auth configuration, selinux, bootloader config and so on. So no, it's not really possible to isolate the installer environment such that you can plug and play with different package sets and expect things to work. If you think this is some kind of design flaw, then knock yourself out redesigning it. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 12:19 PM, Bill Nottingham wrote: Matthew Garrett (mj...@srcf.ucam.org) said: Patches that cleanly decouple Anaconda from the entire software stack that it runs on top of would probably be received with open arms, but nobody who works on it has any idea how to implement them. In fact, this is what has been done in anaconda over the past couple of releases - Anaconda migrated from having its own boot and init infrastructure to using system-provided items such as dracut and systemd. But that's complicated work, and while you're doing that migration, you're doing a lot of arbitration as to what bits are in generic dracut, what bits are in generic systemd, and what bits remain in anaconda. And during that process, you are *very* tied to the version of the underlying system, until the work is fully complete and there is a defined separation of features into each layer. This, incidentally, also is why running the F17 installer on F19 isn't practical. Bill Not to mention that while making this migration and after, when system tools /change their api/ or /change their command line arguments/ it means that the installer is suddenly broken again. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 07:15 AM, Matthew Miller wrote: On Fri, Nov 09, 2012 at 09:30:14AM -0500, David Cantrell wrote: Wasn’t one of the advantages of VMs the fact that you can slice more small machines on one computer? Yes, that is an advantage, but that shouldn't be slicing up one computer in to multiple very underpowered smaller computers. Why not? That's incredibly useful. Just to cite similar complaints I see from time to time... It irritates me that people think it's a problem that in 2012 they can't install in a VM that is allocated with 256M of RAM. Allocate a reasonable amount, start over. Your host system for multiple VMs in 2012 should not have 1G of memory. What about my host system for 500 VMs? Use elastic allocation. It takes a lot of ram to say please depsolve these 40 packages which turns into install these 250 (minimal) packages. So in order to handle that kind of task (once), allocate a large amount of ram. Once that task is complete, the actual work the image will be doing may require a lot less ram, so you can scale down what you allocate to that guest. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 05:48 AM, Matthias Clasen wrote: I still think there would be room for shrinking both code base and the system dependencies if the installer focused on its core responsibility - getting the bits on disk. That is an important and very high-risk operation - why do we need to complicate the program doing it by also making it responsible for creating users, configuring firewalls, timezones, etc etc ? Those are all things that can (and imo should) be done in the much safer and easier-to-debug post-install environment. Because when you are only installing the minimal package set (which means no x) then the post-install configuration tools don't really exist to do those necessary steps, nor do people want to have an automated install, which then halts at first boot to prompt a user to configure a bunch of stuff necessary to make the machine work right. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 08:33 AM, Matej Cepl wrote: a) Why installer requires 2-4 times more memory than any other program running on my computer (and the software you use on it could be a good example of SOHO server)? Because anaconda links into a large amount of runtime stuff, that normally runs isloated and so it /looks/ like our memory usage is balooned, when in reality the entire system has balooned, we're just getting the blame. b) What awesome and breathtaking functionality I've got in anaconda since EL-5 that I have to pay for it with this increase of hardware requirements? (and let me remind you again about those 500 VMs) I don't think these question are in any way inappropriate or too offensive, are they? Hey it's free software. Feel free to take EL5's anaconda code base and make it work for F19. If it's good enough, maybe you can convince FESCo to replace anaconda with your project as the official installer for Fedora. I wish you luck! -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 06:56 AM, Alexander Bokovoy wrote: The simple fact that you are feeding kickstart file to a single entity does not mean this entity cannot outsource actual tasks to others and run them later, be it post-install phase in the actual installer's session or after (a simulated) reboot. Input interface change is not needed for backend changes. If all you are interested is 'one go' installer from perspective of the feeding kickstart files, it would still be the same. What anaconda is doing is taking that kickstart input and feed it into run-time tools in a way that those tools can do what we want them to do. Except those tools change over time, and their inputs change over time, so anaconda breaks over time just in trying to take data in one place and feed it into another. Isn't software fun? -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 08:57 AM, Jóhann B. Guðmundsson wrote: On 11/09/2012 04:43 PM, Jesse Keating wrote: While that has some obvious issues, like new hardware doesn't work with old kernel/syslinux/grub/udev/etc..., It's not like it always works in that area anyway Right, computers don't always work, so lets give up, and go shopping right? there are further issues as some configuration has to happen within the installed system, which means knowing how things like firewall config, network config, mount options, root auth configuration, selinux, bootloader config and so on. Last time I checked the configuration of those files have remained the same for years if we put that aside how is Anaconda supposed to be reverted in the future what's the plan you guys have here, which direction are you guys taking in regards to that? JBG The inputs to the tools doing the configuration of those tools has changed over time. We don't want to duplicate code by having our own pile of config parsers and writers, we want to rely on the same tools that userlands are using. As far as Anaconda reverted in the future, I'm confused as to when/where this became a requirement. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/08/2012 12:47 PM, Jóhann B. Guðmundsson wrote: On 11/08/2012 08:40 PM, David Lehman wrote: No. It is an inevitable consequence of the feature set demanded of the Fedora OS installer. If thing A must be able to set up and configure thing B and thing B changes in ways directly related to said configuration, how can you reasonably expect thing A to continue to be able to configure thing B without corresponding changes? Magic? I'm all for magic but I would expect specific configuration package(s) and or a configuration template tailored for the component being install which the installer might use or the package himself would simply do it post install. Are there any specific use case where that would not suffice? JBG You're focused on packages. How about filesystems? That stuff changes way more often than one would like. LVM? How often do we have to update the command line arguments we pass to do things? --force --force --noIreallymeanit BTRFS? That's all still in development so the tools are changing rapidly. What about actually getting packages into the filesystem. yum api changes with time, and our use of yum means we have to change our code to work with the API as well. Boot loaders? yeah, go ahead and install the grub package, see what it does in the %post scripts. Oh, you actually want to /configure/ the machine to boot? Well that takes work, work that has to change because /grub/ changes. I can keep going, but is it really necessary? -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 03:27 AM, Miloslav Trmač wrote: Well, perhaps thing B shouldn't have been changed incompatibly in the first place. I realize that's an ideal that is impossible to achieve, but we are rather cavalier about changing interfaces without adequate notification. I've been told that the F18 Anaconda work was for some time done on a single rawhide snapshot; after ~2 months the snapshot was updated - and it took weeks to get Anaconda working again against the new one. That sounds rather bad. Yes, anaconda is special, but it is not _that_ special; if updating for core platform changes (without any major known change happening in the mean time) requires weeks of work on anaconda, there will be other software that will require weeks of work to update. You won't find much disagreement in the installer team. Fedora changes, and it changes fast, and it changes without a lot of notice, cooperation, or coordination. Anaconda suffers a lot because of this, and Fedora users/testers suffer a lot because Anaconda breaks a lot. We are often the advanced scout who first encounters a major change. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 09:11 AM, Jóhann B. Guðmundsson wrote: Well the argue can be made that If you are doing a minimal install it kinda indicates you actually know what you are doing ( which means you will probably change whatever was set afterwards ) so the system should just default to use sane working defaults which should come with the relevant package when it's installed even set some default password. Pretty sure having a default root password in some package in Fedora is a non-starter. The point of doing an (automated) install (which can be minimal, or at least start with minimal and build upon that with only exactly the needed functionality) is so that you can do the install unattended, reboot the machine and put it into production, unattended. But if we continue to look at minimal install which post-install configuration files is Anaconda explicitly touching? root auth and firewall config are the main ones. Note that we don't have any UI for firewall config either, so not really a lot of code duplication. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 09:35 AM, Toshio Kuratomi wrote: On Fri, Nov 09, 2012 at 09:13:32AM -0800, Jesse Keating wrote: As far as Anaconda reverted in the future, I'm confused as to when/where this became a requirement. I think he's saying this because: 1) Features have a section for contingency plans. 2) In this particular case, we're slipping schedule because the NewUI feature has a point where there stopped being a contingency plan. We passed that point before being aware of all of these issues that need to be fixed in order to release Fedora. Being stricter about having viable contingency plans for features like this (ones that require coordination and can potentially block us if they aren't done/done correctly) is one possible way to address this type of situation in the future. Others are to alter the time-based release philosophy for certain features (We are going to have Feature X in Fedora 19. If it isn't ready, we're going to slip the release date until it is done.) To only let in a feature with no contingency plan only when it is code complete and can be evaluated outside of the Fedora tree first (anaconda devs state that they do not actually have the manpower to implement this style of solution). -Toshio - Note: I considered adding have a longer release cycle to the list of alternatives but it's not clear that we wouldn't still get into this situation (FESCo/releng/QA finding out at beta freeze that Feature X lacks certain capabilities that are considered essential while the team responsible for the feature had considered that it was something that could safely be put off until the next release. Being unable to revert the feature at that point and so having to code the missing capabilities on a rushed schedule at that point.) In that context the plan would have had to be do all the bring the code base forward into the next Fedora environment work twice. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 09:57 AM, Panu Matilainen wrote: Except that rpm (and yum) use a lot LESS memory these days than they did in the RHEL-5 era, which I think was used as a comparison here. That's not where all the memory has gone, quite the contrary. While that may be true, the amount of ram (free -m) used during an install *triples* when we get to the desolve and package install phase. In my most recent test the used number went from roughly 550m just before the packages step to 1645 during. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 11:32 AM, Matej Cepl wrote: On 2012-11-09, 17:06 GMT, Jesse Keating wrote: Because anaconda links into a large amount of runtime stuff, that normally runs isloated and so it /looks/ like our memory usage is balooned, when in reality the entire system has balooned, we're just getting the blame. Right, that looks possible. I still wonder why installer needs MORE memory than running server with couple of servers, Apache, MySQL, and some application servers (Zarafa, Status.net, dspam, wordpress)? But following in this argument would probably require more detailed analysis than I am willing and able to provide, so let me close this argument here. Matěj I don't think I'm necessarily disagreeing with you. I don't think anybody on the Anaconda team is happy with the current memory usage. That said, we've had very very very little time to pursue fixing this particular issue. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On 11/09/2012 12:05 PM, Toshio Kuratomi wrote: On Fri, Nov 09, 2012 at 09:35:42AM -0800, Jesse Keating wrote: On 11/08/2012 11:31 AM, Adam Williamson wrote: Yes. This is_absolutely_ a feature. A complete rewrite of a core and non-optional component cannot be done ad hoc without planning. One blindingly obvious reason for this in the current situation is that we're still thrashing around trying to figure out how to build and ship the initramfs that fedup needs. This is exactly the kind of thing that needs to go through the feature process so that the relevant groups - releng, infra - know about it. I don't believe they even knew about the problem until about two weeks ago. I think the unfortunate thing here is that we're trying to use Feature to handle cross team coordination. Why unfortunate? That is one of the two issues the Feature Process was created to address. If it's unfortunate because the two issues the feature process attempts to solve don't really have as much in common as once thought, that's cool and probably the number one thing that everyone would like to fix -- I'm just checking that you don't have some other idea in mind. Don't have anything else in mind. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide
On 11/07/2012 01:02 AM, Vít Ondruch wrote: Dne 7.11.2012 08:08, Dan Horák napsal(a): Jesse Keating píše v Út 06. 11. 2012 v 10:48 -0800: On 11/06/2012 03:35 AM, Vít Ondruch wrote: And rel-engs actively prohibits staging as much as they can [1], where it should be encouraged IMO. Vit [1] https://fedorahosted.org/rel-eng/ticket/4580 Additional tags have a high cost to the infrastructure and every user of said infrastructure. It creates more newRepo tasks which take significant time to complete, and since they are resource intensive only a few can be done at once. This means that newRepo tasks get delayed farther and people waiting for buildroot updates have to wait longer, and longer, and longer. This is why extra tags/roots are used sparingly for more intensive updates than what you're requesting here. but there is a solution - learn koji use multiple repos, in cases like this one you will have one repo that is tied to fX tag (large, but changed only when fedora changes) and another to the side tag (this will be very small one, can be changed more often), koji will then generate a mock config with 2 repos and you are done Dan In combination with https://admin.fedoraproject.org/pkgdb/acls/name/createrepo_c it would be outstanding. Vit If the solution was so simple, don't you think it would have been solved long ago? The majority of time isn't spent in the createrepo task, it's in the database queries to figure out through inheritance what all builds should be in that createrepo run. That's what puts stress on the entire system. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg / koji error
On 11/06/2012 11:34 AM, Tom Callaway wrote: Jesse, please review and apply these upstream and make a new update. Fixed comments. Other patch (fedpkg-1.10-use-nil-to-unset-distunset.patch) is fine as is. Tweaked and pushed. Building an update now. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide
On 11/04/2012 01:31 AM, Panu Matilainen wrote: Yeh, autoqa can't do a whole lot when its builds often intentionally dependencies break (eg soname bumps). Unless such builds were required to be done in a staging area - this is *possible* already but not much used. It'd have to be reasonably convenient for the developers though, IIRC this requires rel-eng intervention currently. The long term plan with AutoQA was to have a staging area. build - stage - AutoQA - rawhide. If your package passes autoqa, it goes into rawhide. If it fails, the dev can override and send it on anyway, or try again with a newer build. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 11/01/2012 07:32 AM, David Lehman wrote: On Thu, 2012-11-01 at 13:01 +, Jóhann B. Guðmundsson wrote: On 11/01/2012 12:22 PM, Michael Scherer wrote: Maybe having some kind of dependencies between feature could also be a idea. Anaconda requires dracut to not change, so we need a way to express this, and a way to avoid changes at the same time. The same goes for a python upgrade or lots of things. It would be good if any of the Anaconda developers could comment what external components can affect Anaconda and to what extend atleast if I'm not mistaken these external components can affect Anaconda Kernel Dracut Systemd NetworkManager Changes in comps/packaging group ( rpm/yum? ) lvm mdadm btrfs-progs e2fsprogs xfsprogs xvnc .. Basically anything in lorax's runtime-install.tmpl and all the deps therein can destabilize anaconda. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 10/31/2012 07:12 AM, Panu Matilainen wrote: Makes me wonder... were the anaconda developers and FESCo aware of the oncoming major changes to dracut? At least I failed to see anything obviously related to that on a quick skim through the f18 feature list. I think we had some idea that dracut would be switching to use systemd to run things, but what we didn't anticipate was the amount of fallout from that switch in our scripts. This was compounded by focusing on building newUI on top of F17 content because it was stable, rather than fighting the never ending slog of rawhide issues, so we didn't notice all the subtle ways things were breaking in rawhide until it was late in the game. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 10/31/2012 08:08 AM, Tom Lane wrote: My concern at this point is exactly that we're slipping a week at a time, rather than facing up to the*undeniable fact* that anaconda is not close to being shippable. If we don't have a workable contingency plan, I think the best thing to do would be to start slipping a month at a time. And drop the beta-freeze restrictions, until we reach a point where anaconda actually is beta quality. Other people have work they could usefully be getting done, except that they have to jump through these beta-freeze hoops --- which not incidentally are slowing down anaconda work too. It's insane that we are wasting time debating whether anaconda bugs are release blockers or beta blockers or only NTH, when any honest evaluation would recognize that the whole thing hasn't reached alpha quality yet, and*all* those bugs had better get fixed if we don't want F18 to permanently damage the reputation of Fedora. You can slip a month (or two) honestly, or you can fritter it away a week at a time, and ensure that as much of that time is unproductive as possible. There is not a third option. (Brooks'_Mythical_Man-Month_ has useful things to say about this sort of scheduling trap --- anybody who hasn't read it should.) Had I any say in the matter I would have strongly urged to not enter the beta freeze when we did. I also think it's counter-productive to getting things in shape, and mostly just makes a lot of people hate Anaconda because it's keeping the freeze going. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 10/31/2012 09:56 AM, Toshio Kuratomi wrote: * Jesse Keating, Jeremy Katz, and others who helped shape the current policy and theory of our release schedule felt that the 6 month release cycle was fine but that certain features were going to take longer to develop. Those would need to be developed and not enter into Fedora until they were close enough that they could be completed during that cycle. - No matter what we do to try and increase the development cycle within a release, there's always going to be issues that take longer than the release that we need to deal with. Perhaps, we just need to be better about making people follow this model. I'm not entirely sure what I felt then, but I'm certainly open to a longer release cycle. In fact I'm very much in favor of one, one that puts more time between feature complete and the actual alpha release. All too often we see features crash land right at the deadline, and any software that has to integrate across a lot of pieces (like anaconda) gets stuck trying to account for all these changes in a very limited time frame, only to be hindered quickly by a freeze process. I think we need to give developers more time for feature integration after the feature freeze. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On 10/31/2012 01:53 PM, Jóhann B. Guðmundsson wrote: The plan to remove rescue and text/serial install which we found out and convinced the Anaconda developers to bring back which they did... That's not accurate in the least. text/serial was lost when the switch to newUI was made. They just wouldn't work anymore. The original plan, the one that the anaconda team committed to, was having them back in place for F19. I joined the team and Martin and I got lucky in having enough time to quickly bang out a minimalist text interface, which I spent a little more time in to make sure it worked well over serial. We happened to get it done well ahead of time, but we never committed to having it at all for F18. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On 10/17/2012 11:32 AM, Chris Adams wrote: I would think the only sane way would be to just change the packaing, not actually build multiple kernels (or even multiple packages with kernels). For example, a kernel-minimal that has the kernel and the core modules loaded in most installs (e.g. filesystems like ext4 and NFS, dm, network support like ipv6 and iptables, and virtio-type drivers), a kernel-common that has the rest of the current contents of kernel (and probably obsoletes kernel), and then the current kernel-modules-extras. There will always be requests to move modules from -common to -minimal, and it shouldn't be a big fight (I would bet most requests would be pretty obvious). That already exists some for -modules-extras. You'd want to do it something like that. kernel-minimal as you say but with a Provides: kernel, kernel-common as you say. I'd introduce a third metapackage just kernel that requires both of those and implicitly Provides: kernel. Most people would just get the kernel metapackage when a transaction asks for something to provide kernel, but if you explicitly ask for kernel-minimal you'd get just the minimal. This would all be done from one kernel spec and built out at the same time. We've got a lot of new infrastructure coming for kernel builds and we don't want to make things even more complicated by having to do multiple rpm build runs. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On 10/17/2012 01:46 PM, David Malcolm wrote: Random worry about this: would this work OK with yum's keep the last 3 kernels around functionality? That's obviously something that would have to be tested if this is attempted. I'm not signing up for this work, I was just making a suggestion on how to structure the rpms that fell out of the kernel spec. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On 10/09/2012 07:25 PM, Simo Sorce wrote: Can't you just you reinstall a package without the nodocs switch/conf in place to get the docs land on disk ? You probably also have to skip the scripts, which can have some unintended consequences. Also it means downloading the entire package set, not just the ones with docs. And it means hoping all the packages you've installed are still available in whatever source you installed them from. Anyway, it's just not something I'd feel comfortable exposing in the anaconda UI. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On 10/09/2012 05:55 AM, john.flor...@dart.biz wrote: From: Jóhann B. Guðmundsson johan...@gmail.com I personally want to see the documentation releng/fesco has about what the default minimal set, what the process is to have something include,excluded from it and why the packages that exist in it are there in the first place. I too would very much like to see this as almost all of the (hundreds, soon to be thousands of) systems I manage start life as a minimal install and grow just enough to fit their role. I take minimal quite literally in that I believe it should be the absolute minimum to boot, login and install more atop of that, but only as needed. Anything beyond this is some use case, but minimal is minimal. -- John Florian And now we see why Anaconda did /not/ have a minimal option for a while. Minimal means different things. To some, it means an OS that boots, lets root log in, read man pages, use non-english languages, and add more packages with depsolving. To others it means an OS that boots and lets root login, and that's it. Others feel that minimal should be enough to give you a filesystem and runtime you can chroot into (but no kernel/bootloader). Right now, minimal is defined in comps, as a set of packages. Installing this group will depsolve and add more of course, which is controlled by the packages itself. Anaconda will add a few more things forcefully, such as a kernel and a bootloader and potential arch specific utilities, as well as authconfig and system-config-firewall-base in order to add the root user and configure the firewall. There are a couple places to make adjustment to what minimal is, comps and the packages. As for the things Anaconda adds, we're not too keen on having that be configurable. Anaconda is really meant to be creating bootable systems, not necessarily stripped down chroots. That said, we do have multiple install paths in Anaconda now, and it's not beyond the realm of imagination that there could be a mode that creates a chroot, optionally bootable, with a very trimmed down set. This would likely have to be driven by kickstart files, but does seem to dovetail a bit with the Arm effort, where installs are just blasting bits onto a SD card. Interested parties should take up this effort and run with it, the Anaconda team won't likely be spending any time on this for a while, if ever. We will however review patches and guide those wanting to work on it. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On 10/09/2012 05:50 PM, Chris Murphy wrote: On Oct 9, 2012, at 6:19 PM, Adam Williamson wrote: there's no simple 'install all those docs that got left out' command. That is icky. I would like a minimal install base with a docs add-on. Is this a possibility for newui anaconda in the F18 time frame? Choose your environment Choose your add-ons Minimal Install Documentation Alternatively, include the man files in the Standard add-on? Chris Murphy Anaconda isn't going to do that unless there is rpm support to re-docify yourself. To accomplish this right now, every package would have to split out a -docs subpackage with all the docs in it. Anaconda /might/ do what you want in the future, by way of kickstart commands, but that's not something we're going to expose in the UI. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can I best tie together cloud bugs in bugzilla?
On 09/20/2012 01:27 PM, Matthew Miller wrote: On Thu, Sep 20, 2012 at 12:25:46PM -0500, Jon Ciesla wrote: I could make at tracker bug (in that case, probably one per Fedora release). Or, maybe an alias that could be added to the CC line. What's the best approach? If it were me, I'd use a tracker bug. I see that there are a lot of such bugs under the 'distribution' component. The developer whiteboard is an option too, but unless someone comes up with a good reason why I shouldn't go with tracker bugs I think that's my preference. Tracker bugs get unwieldy after a bit and generate a ton of email. If you modify the tracker bug in any way, everybody on any dependent bug can get an email, and it can take a long time to chew through such changes. Also if you're on cc'd or assigned on the tracker bug and anything happens to any of the dependent bugs (that you are also cc'd or assigned or whatever on) you wind up getting two messages. One for the change to the dependent bug, and one from the tracker bug saying something happened to the dependent bug. Basically my use of tracker bugs filled my mailbox more than I wanted. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Alpha is hereby declared GOLD
On 09/17/2012 02:19 PM, Adam Williamson wrote: On Mon, 2012-09-17 at 16:37 -0400, G.Wolfe Woodbury wrote: On 09/17/2012 04:27 PM, Adam Williamson wrote: It's been suggested that we should stop using 'GOLD' when talking about Alpha and Beta, and I think this is right. Only final releases should be said to have gone 'gold' - this is how the term is generally understood, and using it for Alpha and Beta releases confuses people as to their status. Jaroslav, what needs to happen for the term not to be used for F18 Beta and future Alpha / Beta releases? I like the suggestion to use bronze then silver then gold It's cute, but I think might read a bit bizarre in isolation. 'Ready for testing' is terminally boring, but seems safe... Although that somewhat conflicts with our release candidates of Alpha/Beta that are also ready for testing. Also, the point of marking something as GOLD was that it's ready to be staged for distribution. GOLD meant Gold Master, that is the master copy was produced and sent off to the duplicators. Ready for testing doesn't quite embody that same idea. Completed seems to make some sense, the Alpha has been completed and is now being staged for release. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On 09/07/2012 02:36 PM, Matthew Garrett wrote: On Fri, Sep 07, 2012 at 11:54:03AM -0700, Jesse Keating wrote: Fedora 18 is basically closed for new feature work, and instead the focus needs to be on integration of the existing feature set and bugfixes. But as you state there is a large amount of time before F18 releases, which means new feature work would have to stall out for months. Instead, new feature work can begin for F19 and get ahead of the game. That's why F18 and F19 are divergent. That's why we went from a single line of development to two. This makes sense, but it runs directly against the current auto-inheritence behaviour. It's unsurprising that people end up with different opinions of the right thing to do here. I'm of the opinion that rawhide should be inheriting from the builds of the previous release, so long as there haven't been any builds directly on rawhide. I'm also of the opinion that the inheritance should happen as early as possible, eg as soon as the package is built, instead of waiting for a bodhi introduced delay. Rawhide works this way, the inheritance into rawhide should work this way too. Getting there is a little complicated due to how the fXX-updates-candidate - fXX-updates-testing - fXX tag dance works, but I'm confident smart people can figure that out if change is desired here. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Alpha Test Compose 5 (TC5) Available Now!
On 09/01/2012 01:34 AM, drago01 wrote: rantUnrelated to the alpha but the UI still looks very unpolished (ex: why does the installation screen still say PERSONALIZATION ) ? And Quit on the live image should not reboot the system but just close anaconda IMO. /rant It's (pre)Alpha software. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dependency bug wodim/genisoimage
On 09/02/2012 02:26 AM, Ian Malone wrote: There's also a: Skipping missing group 'base' at the start of the livecd-creator process. What repository are you pointing the install at? The base group should exist in the group metadata (comps). -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg build: Could not initiate build: Unknown build target: dist-rawhide
On 08/21/2012 12:24 PM, Dave Anderson wrote: Is there something I need to change so that a simple fedpkg build will work again? I believe you need a new version of fedpkg and pyrpkg. It should just be using rawhide instead of dist-rawhide. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] 2012-08-13 @ 15:00 UTC - Fedora QA Meeting
On 08/13/2012 03:38 PM, Carl G wrote: https://bugzilla.redhat.com/show_bug.cgi?id=847644 ? I missed that bug because it was filed against dracut instead of Anaconda. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad F17 install experiences: CentOS 6.3 vs. F17
On 08/09/2012 01:04 PM, Jos Vos wrote: --yesiknowwhatiamdoingbutitaketherisk ;-). I think you misspelled %pre :) -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Suggestion: Continuous mass rebuild
On 07/29/2012 10:38 AM, Richard W.M. Jones wrote: Currently we're doing a mass rebuild about every couple of releases, ie. once a year. Since Dennis Gilmore has written this rebuild script already, why don't we run the script more or less continuously? Obviously we could pace the builds so they happen for each package about once a month and don't overload Koji. Then we track packages that don't build, say, 3 times in a row, and file FTBFS bugs for them and after that prioritize fixing them or kick them out of the distro. Rich. Matt Domsch used to do this on the side, which is the right way to do it. If he's not doing it anymore, I would urge some concerned contributor to help setup the infrastructure to do it again. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Suggestion: Continuous mass rebuild
On 07/30/2012 12:02 PM, Seth Vidal wrote: On Mon, 30 Jul 2012, Jesse Keating wrote: On 07/29/2012 10:38 AM, Richard W.M. Jones wrote: Currently we're doing a mass rebuild about every couple of releases, ie. once a year. Since Dennis Gilmore has written this rebuild script already, why don't we run the script more or less continuously? Obviously we could pace the builds so they happen for each package about once a month and don't overload Koji. Then we track packages that don't build, say, 3 times in a row, and file FTBFS bugs for them and after that prioritize fixing them or kick them out of the distro. Rich. Matt Domsch used to do this on the side, which is the right way to do it. If he's not doing it anymore, I would urge some concerned contributor to help setup the infrastructure to do it again. There's been a lot of work to make it so we can do it ourselves. If anyone wants to help out on it I can point you to what we built. Until we get the new hw active we will be limited on where we can run, though. -sv I believe I misphrased my statement above. I'm not necessarily encouraging somebody to go outside the Fedora Infrastructure to do mass rebuild attempts. My goal was to encourage people to do it in a throw-away method, not an actual spec committing build bumping use of Koji. The rebuilds should be attempted outside of koji and without modifying the sources. If there is room to do that inside Fedora's Infrastructure, all the better. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On 07/27/2012 10:15 AM, Toshio Kuratomi wrote: For endusers, the date is more handy for seeing whether the package is based on newer or older upstream versions than the scm's hash. But do we specifically say what you're supposed to put in the date field? Is it the date the hash was created? The date the hash was added to a specific branch? The date the hash was checked out by the Fedora dev and built in the build system? The guidelines say at one place that the date used should be the date the snapshot was made, which can be pretty disconnected from the date the hash was created or merged. A date without clear rules or context is just meaningless digits. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On 07/27/2012 11:13 AM, Jon Ciesla wrote: If you can suggest a clarification of wording, it sounds like an EASYFIX for FPC. -J I would suggest just dropping the date field for SCMs that have a canonical revision identifier. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On 07/27/2012 11:29 AM, Toshio Kuratomi wrote: That's hyperbolic. A date tells you something meaningful even if it is specifying something that turns out to be a range of valid entries. I might not know if 20120106 is more recent code than 20110610 but I know that it isn't older code, for instance. No, you don't. All you know is that 20120106 is the date the checkout was made. The checkout could be code from 2 years ago, where as the checkout that was done on 20110610 was of code that was at the time brand new (and then later determined to be too full of errors to continue using). The date things were checked out is pretty meaningless. More context is needed, even on SCMs without a canonical revision identifier. You'd want to know what branch or tag the checkout was from. That kind of detail goes in the changelog, not shoved into the release string. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On 07/27/2012 11:29 AM, Jon Ciesla wrote: I'd agree, but git hashes don't do in sortable order. I mean, they do, but only Discordian sort. I'm not suggesting you have rpm sort on git hashes. The release string is required to have a numeric prefix before the date and/or git hash. I'm talking about removing the date part of it so that you still have a numeric prefix (e.g. 0.5) before the git hash. Ordering happens on the 0.X part, not on the git hash. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Thu, 2012-07-26 at 15:37 -0700, Adam Williamson wrote: The date is useful for making it immediately obvious how up-to-date a package is, I guess, but it has no really key function for differentiating builds any more.) It's not even that. With CVS you could have done a checkout of a tag which could be quite old compared to the day's date you did the checkout. Using the date somewhat assumes you're doing a checkout of HEAD, which isn't always the case. I'd move that embedding the date in there is of little use. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 updates broke anaconda PNG image handling
On 07/24/2012 02:14 PM, Jos Vos wrote: On Tue, Jul 24, 2012 at 12:52:27PM -0700, J. Randall Owens wrote: This shouldn't be a problem any longer, but just in case, check https://bugzilla.redhat.com/show_bug.cgi?id=821740 That synfigstudio package seems not to be included in the installer image. When I remove it from my repository, the problem stays exactly the same. There was a lorax issue at one point that was preventing the right mime cache files from making it into the image. http://koji.fedoraproject.org/koji/buildinfo?buildID=321935 was built to fix it, maybe you need to try composing with this lorax? -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 updates broke anaconda PNG image handling
On 07/24/2012 02:44 PM, John Reiser wrote: The bug referred to on that koji page, namely bug #825960, cannot be viewed by mere mortals. Please do what ever is necessary to make it viewable by anybody in Fedora. I'm not sure I can do that, but the gist of the problem is that /usr/share/mime/mime.cache was not retained in the squashfs.img , so mime was not able to tell what the file was. Same error message though. http://git.fedorahosted.org/cgit/lorax.git/commit/?id=3636fd58146768b07f8814d4aeab395876d93a82 that has the fix. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On 06/20/2012 09:57 AM, Adam Williamson wrote: On Wed, 2012-06-20 at 12:21 -0400, Bill Nottingham wrote: Simo Sorce (s...@redhat.com) said: Of course for this to work properly we need some level of integration between Network Manager and the DNS caching server so that the dynamic configurations can be pushed in/out when the related networks come up/down. Discuss. man NetworkManager.conf: ... dns=plugin1,plugin2, ... List DNS plugin names separated by ','. DNS plugins are used to provide local caching nameserver functionality (which speeds up DNS queries) and to push DNS data to applications that use it. Available plugins: dnsmasq this plugin uses dnsmasq to provide local caching name‐ server functionality. ... (Note: haven't tried this.) See also: http://blogs.gnome.org/dcbw/2010/09/23/dont-try-to-run-honey/ Been there since 2010. So I just gave this a try. Already had dnsmasq installed so I just edited the config file and restarted the NetworkManager service. Then connected to my VPN. It. Just. Works. Amazing! Not only does it just work for resolution, but it also works for multiple search domains. I can ping name and it'll try name.localdomain and I can also do name.subname and it'll find it at name.subname.workdomain. A+ -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On 06/19/2012 04:32 AM, Reindl Harald wrote: Am 19.06.2012 09:53, schrieb drago01: On Mon, Jun 18, 2012 at 12:41 PM, Matej Cepl mc...@redhat.com wrote: On 18/06/12 09:30, drago01 wrote: This would just result into stagnation while the competition invents much better wheels and leave us behind. Abstracting for the sake of discussion from the particular case of grub2 could you at least imagine new program which would be worse than the program it replaces? Sure. But a new program can as well be better then the one it replaces even if the other one has been in use for years. Not even trying to improve the old or replace it with something better that comes up means stagnation which is what I am objecting to.You have to make changes to go forward. but it is NIT better it is a config full of crap and script-code this is pervers - short time ago there was introduced systemd saying shell scripts are evil and directly after that we introduce a boot-loader with a configuration where each init-script ever existed was nice compared against CIONFIGURATION != SHELL-SCRIPT You seem to think we, the Fedora project, have any sort of sway as to how things get written in their various upstreams. We don't, except for very few cases. Our choices here with grub2 are A) continue using grub1 and continue working with diminishing resources to keep grub1 working in the new environments a boot loader will be needed in. B) consume what upstream gives us in the form of grub2. You seem to be advocating for option C) throw up your hands and yell THIS IS UNACCEPTABLE, and then what? -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 02:03 PM, Kevin Fenzi wrote: On Tue, 19 Jun 2012 14:00:46 -0700 Jesse Keating jkeat...@j2solutions.net wrote: On 06/19/2012 12:16 PM, Jóhann B. Guðmundsson wrote: In any case Kevin K. probably can comment on what landed the KDE distribution on the Relengs DVD and on the release blocker in the first place. Gnome and KDE were both on the release DVD/CDs since pre-Fedora. They were the only desktops on the release media of note. When we created Fedora Core and then Fedora Extras, KDE remained in Core to continue to be on the release media. When we merged Core and Extras KDE remained on the release DVD, partly because of historical status, and partly because of general sentiment that it was the #1 alternative desktop to the Gnome default. When the Release Blocking Desktops set was decided, it was likely based on what was on the DVD. I'll add to that to note that we now have Xfce, LXDE and Sugar all on the DVD. I've considered asking about making Xfce a blocking desktop, but I have no idea how the LXDE and Sugar communities are with helping testing, etc. It would mean added burden on QA folks to test more stuff, and added burden on maintainers of those desktops to create timely fixes for any blocker issues that come up. kevin Having a desktop be a blocking desktop also somewhat assumes you'll be getting QA volunteer time to run through your test cases, whereas when it's not blocking there isn't that assumption. The SIG can still create and validate their own test and release criteria, and propose something as a blocker, but it's not guaranteed to be accepted. At least that's how I see it from when I was involved in the release process. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 03:19 PM, Adam Williamson wrote: If an manpower to cover anything else then critical path became a concern we should fetch that manpower from the relevant SIG's community. Basically the plan was to reach out for example to the Gnome/KDE/XFCE/LXDE/Sugar community's to ask for assistant to cover their relevant part of required testing if that was the case. If you think about it who are better qualified and more willing to test those components other then the people that are using it on daily bases... This is fine in theory, but it doesn't hold up terribly well in practice. Just about every time we roll a TC/RC, I mail the lists for each desktop - GNOME, KDE, Xfce, LXDE, and Sugar - and ask for help in filling out the validation matrix. We get help fairly often for GNOME and KDE, and satellit_ usually covers Sugar, but we very rarely get anything for Xfce or LXDE. At which point you have to decide If nobody is willing to test it, can we really call it a blocker? or you just block the whole release until somebody comes along and tests it (usually yourself). Ultimatums that require people to do work don't often fly here in Fedora land. Ultimatums that are arranged in do this, or you lose that status tend to work better, because the failure case is easier to handle. They lose $status and life moves on. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]
On 06/19/2012 03:59 PM, Jef Spaleta wrote: On Tue, Jun 19, 2012 at 2:47 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Again anything that gets handed out at various events should be considered release blockers since the quality of that product reflects back at us as a community thus if an relevant SIG cannot cover it's own release testing apart from what we consider core and QA handles ( which in essence is what those spins build upon ) it should be removed from anything we officially hand out thus no longer be considered release blockers. At what point in the process would you place the go-no-go as to the release of a specific deliverable as an official spin? In an effort to not beatup an existing subgroup that is perhaps shorthanded I'll talk about a hypthetical situation. For the sake of argument lets assume I and a small group of heroic people were able to beat CDE into shape as a new fedora spin. Retro is the new hotness right... We get a spin out the door we get on the spins page for a release or twowe are rocking the world. And then for some reason on the next release we all fall behind and we don't keep up with the necessary integration changes. And CDE is just horribly broken for months. A lot of bugs get set as release blockers and we are pinged...but we just don't get the work done. At one point in the pre-release process does our Spin get culled from the herd and we are told..sorry..this release won't have a CDE spin? At what point does the QA and release team just punt? -jef We already have a go/ no go line built into the schedule. It's the Feature Freeze line. Things are supposed to be in a testable state by that point. If your desktop is so broken as to not even be testable, that's reason to drop it. I believe that's the transition from Alpha to Beta. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/02/2012 08:38 AM, Gregory Maxwell wrote: When I create a fork, respin, or remix of Fedora and distribute it to people it will not run for them like Fedora does without a level of fiddling which the people advocating this have made clear is entirely unacceptable. This is because Fedora will be cryptographically signing the distribution with keys these systems require and not sharing the keys with me. Fedora be doing this even with software that I wrote, enhancing it with a signing key only they have access too, making it much more useful on hardware where it is not otherwise, and not allowing me and or downstream recipients to enjoy the same improvements for their modified versions. What is unclear about this? You do realize that if you create a fork, respin, or remix that you will have packages on the system that are not signed by Fedora's GPG key, and your generated ISOs will not be signed by Fedora's GPG key? Worse, there is no amount of money you could pay Fedora to gain access to Fedora's GPG key, nor is there any infrastructure for Fedora's key to trust other keys. Fedora already takes software you wrote and enhances it by signing it with a (gpg) signing key, which makes it much more useful on hardware with Fedora installed where it is not otherwise. (Users would have to disable yum's gpg checking in order to install your unsigned package, or they would have to install /your/ gpg key and trust it in order to install the package signed with your key). Further, your product may not be hosted by our servers, and our mirrors. It will not be produced into physical media and brought to Fedora events to be handed out to users. There never was equal footing. The only Freedom you've lost is that now, in addition to the person-hours to do the work and monetary cost to host your bits or generate physical media, you have an additional cost if you wish to have your own cert that will be accepted out of the box by the next generation of PC hardware. You have as much equal footing as Fedora does to plunk down the $99 and play along in the PC sandbox. That's a better deal than Fedora's gpg signing setup. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/02/2012 09:24 AM, Gregory Maxwell wrote: (Users would have to disable yum's gpg checking in order to install your unsigned package, or they would have to install/your/ gpg key and trust it in order to install the package signed with your key). I distribute modified copies of Fedora's OpenSSL libraries, they're signed my by key not Fedora's. Users— even rather technically unsophisticated— install them without any difficulty. The install tools do not enforce that the files be signed, they do not have to install my key. Try for yourself, if you like:http://people.xiph.org/~greg/openssl/ My point here was that you don't enjoy equal footing with Fedora in this regard, today. User's have to do something /extra/ to get your software. They have to either disable GPG protection in yum, install your GPG key, or install the packages outside of yum. This is not unlike disabling Secure Boot or adding your key to Secure Boot. You have as much equal footing as Fedora does to plunk down the $99 and play along in the PC sandbox. So if I were to take, say, a GPLed compositing window manager and then I paid $99 for a license to embed a copy of commercial opengl special effects— which prohibited modification, reverse engineering, redistribution by unlicensed parties, and commercial use— then I started distributing this modified version... and I gave it to you and told you that you were free to pay $99 to play in the graphically-enhanced distribution sandbox, you'd think that was okay? That's a nice strawman you've built up there, however I'm quite unable to see what point you're trying to make here. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 08:30 AM, Gerry Reno wrote: The better solution would be for users for want SecureBoot to have to set it in the BIOS. It should be disabled by default. Windows is the OS with all the attack vectors open. Users of every other OS should not be hostage to this SecureBoot by default. You say this as if we have any control over this, whatsoever. The vast majority of PCs on the market are designed to run Windows. They come with Windows pre-installed. In order to come with Windows 8 pre-installed, they will have to enable secure boot at the factory. There is no stopping this. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How do you use fedpkg chain-build for released Fedorae?
On 05/31/2012 08:42 AM, David Howells wrote: Can anyone suggest how to do it right? You don't. chain-build only works on build targets that automatically self-update. Released fedora build targets do not do that. You have to either get your build shipped in updates (stable) or create a buildroot override in order to get that build into the buildroots. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stop the git abuse
On 05/22/2012 11:53 PM, Panu Matilainen wrote: Well, here's what I see after drop_caches=3 from 'strace -tt fedpkg verrel' on kernel.spec which is one of the most complicated specs in Fedora land: 09:09:06.928011 fedpkg exec 09:09:12.699345 python imports done 09:09:13.510192 rpm exec 09:09:15.345425 rpm exit 09:09:15.385441 fedpkg exit So by the look of things, 2/3 of the execution time is spent importing python modules. The rpm execution time is heavily dependent on what the spec actually does, eg in case of kernel.spec this includes ~50 fork+execs of shell, getconf and two python invocations from executing shell macros. From plain rpmspec parsing POV (shell macros aside), at top of callgrind charts sits the rpm bad performance hallmark pattern of repeated insert/delete, qsort and bsearch cycles (on macros). Changing the macros engine to use a hash table instead has been on my todo list for some time now, just not very high in the priorities as spec parse isn't exactly the most time-critical thing rpm does. OOps, I hope my message didn't come across as placing blame or throwing rpm under the bus. I suspected it was a spec much like the kernel that does a lot of complicated macro work to figure out things like name, version, release. Also, I meant it as something I can't do much about in fedpkg land. fedpkg does do a fair amount of python imports. I could probably move some of those around to be more lazy loaded when a property that requires them gets accessed, but that makes the code harder to manage. In practical usage on simple rpms, the amount of time I wait for verrel to return is so small as to not really interrupt my work flow. $ time fedpkg verrel pungi-2.11-2.fc18 real0m0.563s user0m0.437s sys 0m0.118s half of a second. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stop the git abuse
On 05/22/2012 12:33 AM, Jan Kratochvil wrote: True, I agree now. It is just so slow (0m2.693s now, 0m4.222s with drop_caches=3) I expected it waits for network. I bet if you traced it, the majority of time is waiting for rpm to return queries about the spec file. -- jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stop the git abuse
On 05/21/2012 06:08 AM, Thomas Moschny wrote: 2012/5/21 Simo Sorces...@redhat.com: Except we do not allow to rewrite history and push -f so you will never be able to squash everything. If koji/bodhi were able to tag successful builds within git, we would be able to allow rewrites, squash commits and the like at least for commits that never have been successfully build (or tagged). - Thomas re-writing history in a shared git repo is quite rude to all the people who have it cloned. Not something I'm going to support. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stop the git abuse
On 05/21/2012 08:34 AM, Matej Cepl wrote: I give you that, but do you see any alternative which would in let's say five years replaced git in Fedora? Five years is a long time in computer industry, but OTOH five years ago (plus how long it has been since we actually switched to git) it was IMHO obvious our CVS is doomed. Also, our CVS trees are still available, and for the most part all the CVS log messages are still available within git. Any migration from git to something else should follow that same path and retain the information. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stop the git abuse
On 05/21/2012 01:51 PM, Simo Sorce wrote: re-writing history in a shared git repo is quite rude to all the people who have it cloned. Not something I'm going to support. Nothing that can't be easily solved by a git pull --rebase most of the time. It's still not a path I would want to go down. Particularly when rebase will leave git tags dereferenced, and there is no code (plumbing, porcelain or otherwise) that will rebase the tags. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stop the git abuse
On 05/21/2012 08:17 PM, Jan Kratochvil wrote: On Mon, 21 May 2012 18:47:05 +0200, Stanislav Ochotnicky wrote: i.e. there was no empty line so git chucked them all into subject when generating mails. Now they do: line one - line two - line three There is primarily missing the first line: * Mon May 14 2012 Jan Kratochviljan.kratoch...@redhat.com - 7.4.50.20120120-46.fc17 So that the NVR- hash mapping needs to be done by 'fedpkg verrel' which (a) requires network connectivity contradicting GIT local repo, (b) is slow. Jan Hrm, in what way does it require network connectivity? gitbuildhash does require the network to hit the buildsystem, but I thought verrel was all offline. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/21/12 6:52 AM, Peter Jones wrote: On 03/21/2012 09:21 AM, Josh Boyer wrote: Except when people are forced to look at it, their solution was often ExcludeArch for PPC. As I said in the other thread, you cannot force people to care about an architecture they don't know or want to learn. That suggests we need a FTBFS-like nightly test that lets us know about new, unexpected ExcludeArches in the distro. This sounds like the perfect use case for a SCM feature I haven't had the time to work on. If all commit diffs are sent to a message bus by way of a git hook, then one consumer on the bus could be canning for additions of ExcludeArch. When these are discovered a bug could be filed automatically, or some group would get notified, basically something would happen, and we wouldn't depend on a human noticing the change or following policy to file a bug. In the short term, if this is something we see high value in tracking, we can just add another git hook to do this directly, rather than relying on a message bus. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/21/12 10:36 AM, Brendan Conoboy wrote: The main place I see ARM emulation being useful is in allowing any packager with an x86 host to boot a simulated ARM host to resolve build failures in their package. That's not ideal- ideal is every package owner has an ARM system they can use, but it's perhaps a starting point. If other people have feedback on this point I'd be interested to hear their take on it. I think a combination of ARM emulation and providing a network-accessible set of test machines will go along way toward giving packagers what they need and plan to update the proposal to say so, subject to the feedback we get on this point. Arm emulation would go a long way toward validating produced install images too. Those of us that validate x86 images depend heavily on KVM and the like. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: rpm 4.10.0 alpha to hit rawhide shortly
On 3/20/12 8:10 AM, Jonathan Dieter wrote: Ok, in F16 (and I'm assuming this is also true in Rawhide; unfortunately I don't have a Rawhide tree here to test), fedpkg is in the srpm-build group, and it requires pyrpkg which requires mock which requires createrepo which requires deltarpm. I don't know how easily we can clean up these dependencies. Do we need mock in the buildroot? If not, is it possible to split pyrpkg's mock functionality into a subpackage? We're working on a 'fedpkg-simple' which just provides the functionality needed to construct the srpm and nothing else, which will greatly reduce the deps pulled in. I'm not sure what the ETA is on this. Dennis? -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On 3/20/12 9:30 AM, Jon Masters wrote: Hi again, I want to thank you, and everyone else in FESCo for talking with us yesterday, and for looking over the proposal. Bear in mind, it's a work in progress. We intend to have broader conversations over the coming months and F18 is an optimistic goal. Nonetheless, I feel it is achievable (we've done many more disruptive things!) but we have also many points along the way at which we can back out, and remain SA. To address a few of these points...at least, I'll try :) First, just to repeat, we took the proposal to FESCo yesterday in the spirit of early and often, not in the spirit of final deliverable. Therefore, while it is true we've not yet reached out to everyone for input, that is because it is still a work in progress for us. We'll iterate based on feedback, and based upon yesterday and reaching out to other groups. On 03/20/2012 11:52 AM, Peter Jones wrote: 1) mechanisms need to be in place to get package maintainers access to fix arm-specific bugs in their packages So we have a tracker bug at the moment. Is that sufficient? If so, we obviously should make sure that it is included in the proposal docs that we have this in place and are using it. A tracker bug is certainly not sufficient. It would be for a SA, but not PA. Typically our users have a PA at their disposal, or failing that have ready access to a shared PA provided by the Fedora Project that they can log into and do their testing. Without ARM systems available for all the releases our maintainers have to support this is a non-starter. I will also note that having to resort to using a remote system because the arch isn't generally locally at a maintainer's disposal /is/ going to introduce a delay in getting bugs resolved and builds out the door. If the arch was ubiquitous in a way that lent itself to easy debugging and use that'd be a different matter, but I just don't see it as being there right now. 2) excludearch is not an option. This is fundamentally contrary to being a primary arch. In fact this is one of the defining characteristics of a secondary arch. Let's think about this some. ARM (32-bit) doesn't do Intel-style microcode, MCE, or many other things that x86 does. I don't think that means we should build packages that are x86-specific for ARM systems. We generally believe that we're starting from a point of good momentum, but there are some packages that won't ever be appropriate for ARM, and there are others where the FTBFS has been longstanding, or there are other (IMO valid) reasons why it might initially be Exclude. That doesn't mean that there would be many such cases. Nonetheless, I think it would be unreasonable to set the entry bar so high that there can be no things left to fix. That basically retains the x86 monopoly. Perhaps Peter can clarify or soften this requirement a bit. EXCLUDEARCH as a default action when a build fails on ARM is certainly not an option. What would help your situation is generating a few lists of packages. One list would be packages that you feel just don't make sense on ARM. Another list would be the FTBFS you mention. These lists can be debated and decided upon /before/ the migration to PA and the ExcludeArches can be in place before the switch is pulled. Once the switch is pulled, that's when excludearch is unacceptable without FESCo or such involvement, just like it is with the other primary arches. That's really a price of entry. 3) arm must be integrated to the formal release criteria Agreed. We'll need to figure that out. 4) when milestones occur, arm needs to be just as testible as other primary architectures So we have a new hire (hi Paul) who is looking at autoqa, and we're going to pull together as much as we can here. It would help me to know (and we're reaching out to QE separately - per my other mail) what you would consider testable to mean, in terms of what you'd want to see. I think what is meant here is that we have to be able to get the arm version of the rpms installed onto an appropriate host and be able to easily run the programs to ensure that things are working as expected, more than just It built, SHIP IT. Take a look at the release criteria we have currently have in place for alpha/beta/final. ARM will need to follow it or have something extremely similar. Granted the release criteria mostly involves the installation process, but it does include installs from live media. Installs /to/ a SD device and then booting said install to validate it could fit in there. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/20/12 8:58 AM, Brendan Conoboy wrote: I think the real question is, for the developers of on devel-list, how will longer builds for one arch than another affect your workflow? If builds on two architectures start at the same time, but one takes longer to finish than the other, how will that impact you? Right now you'll still be able to see and use the results of the faster build before the slower build completes, so are you materially impacted? You are materially impacted. AutoQA won't run until the entire build is complete. Updates cannot be prepared until the entire build is complete. Buildroots won't be updated with the build results until the entire build is complete. You won't know if your build /fails/ on the arch until it's done, etc... Having one arch significantly slower than the others absolutely creates material impact upon developers. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/20/12 11:18 AM, Brendan Conoboy wrote: We're starting now, that's what the secondary architecture is for. There's no need for ARM to be a primary architecture for Fedora to be ready for it. No, Fedora ARM started years ago. There comes a point where a secondary cannot continue to grow. To become more than it is, it needs the support and interest of the main Fedora community. We are reaching that point. That is why we are having this discussion. Honestly I've yet to see a succinct list of reasons why secondary arch is no longer good enough for the ARM effort, for at least the next few releases. I may have missed it in the flurry of emails and debate, anybody care to recap it for clarity? -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/20/12 8:37 AM, Tomas Mraz wrote: I do not like this requirement. This seems to be specifically provided to block the possibility to have ARM as a primary architecture if we do not want to support just one or two ARM platforms. I do not really see a problem in limiting platforms during rawhide development and branched development. Additional platforms could be enabled for final builds before the release freezes and for update builds. That just means those platforms are getting tested at the same time the rest of the distribution is, and then when you turn it on you suddenly find bugs that need to be fixed which invalidates testing done already. Playing the turn it on late game is a non-starter IMHO. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/20/12 9:38 AM, Brendan Conoboy wrote: I'm not sure how it would work, but if koji can be extended to distribute a single arch build across multiple systems where an identical srpm can be built with a koji-controlled set of flags, this would take care of the wide-breadth of kernels needing to be built. We've also had some success with distcc, but have not proposed using it as reproducability of builds becomes an issue. We had something like this where i586 and i686 were considered different arches, at least for the kernel, and those two builds would happen in parallel often on different machines. Perhaps the same could be done for the arm variants as well. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/20/12 11:50 AM, Brendan Conoboy wrote: On 03/20/2012 11:20 AM, Jesse Keating wrote: Honestly I've yet to see a succinct list of reasons why secondary arch is no longer good enough for the ARM effort, for at least the next few releases. I may have missed it in the flurry of emails and debate, anybody care to recap it for clarity? This was one of the points raised by FESCo yesterday, and it's a fine question that we'll be answering better, elsewhere, in due course. That said, where does this question lead? If we explain what we're trying to get to, will it somehow overcome the objections raised such as build system performance? For the sake of coherent discussion, let's assume that we have good reasons why we want to move to primary, and we can keep the subject on what the requirements are for doing so. The topic at hand isn't even ARM specific, it's just been prompted by us ARM aficionados. Again, I understand that there do need to be good reasons, that's just not the subject of this particular thread. So, other than build system performance, what are the requirements you'd like to see met? Knowing the reasons you want to upgrade to PA is important because it will help us judge whether or not the cost of the upgrade is worth the result, or whether or not the result could be obtained while still staying SA. I don't think promoting a SA to PA is something that can be generically covered, each such potential action needs to be looked at, discussed, weighed, measured, etc... To know whether or not we as a project should absorb the cost of promoting ARM to PA, we need to know what the benefit is, or what the expected benefit would be. As for the other requirements, I believe there are enough sub-threads hashing that out :) -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/20/12 11:54 AM, Brendan Conoboy wrote: Believe me, I want to target those CPUs, but no single proposal can include all the steps necessary to get there. Think of ARM-on-primary as the first of many steps designed to get us there. If you've ever climbed a mountain you'll know that the trick getting to the top is to put one foot in front of the other. This is just a step along the way. I hate analogies, but no, the first step is working out in a gym to make sure you're in fit enough shape to go up the mountain. SA is your gym, and from what I've seen in these threads I really don't think ARM is ready for the mountain yet. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/20/12 12:05 PM, Brendan Conoboy wrote: IIf there is some sane way to distribute a single armv7hl or armv5tel build across multiple builders that may be an interesting avenue to pursue (Sanity tbd by releng:-). The builders we expect to see this year have 4 cores, but if we could realistically do a 'make -j 32' and have 8 systems involved in any one package, that'd certainly take care of performance concerns for parallelizable builds. It's a neat idea, but making it work reliably is a proposal unto itself. Yeah, I see that as another rather large proposal. It could make some other build tasks go faster too, even on x86, but traditionally we've pushed away from that because of the complexity it presents and concerns of reproducible results. Then again this discussion was ages ago when the tech to do such things was youngish. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/20/12 12:14 PM, Brendan Conoboy wrote: On 03/20/2012 12:05 PM, Jesse Keating wrote: So if you're willing to live like that, I must ask again, what do you think you'll be getting out of being a primary arch? I'm willing to temporarily do better than secondary and worse than primary on the road to becoming primary. This is a huge transition- identifying the right path to make that transition is part of what this is about. The whole point of this thread is to establish requirements for promotion. Part of that discussion logically includes the steps to get there. Currently what I hear is be as good as x86 and you're there. That's not productive. There are legitimate issues with moving to PA so we're having this discussion to identify them and ultimately work through them. What does better than secondary arch mean to you? I'm really struggling here. We as a group have identified many of the roadblocks or pain points of bringing arm into primary arch. You're suggested solution in this sub-thread is effectively treating arm as secondary arch, and when asked about this, you've avoided the question, once again, of what it is you expect to get out of being primary arch. I'm really not sure how much more rational discussion we can have here. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/20/12 12:32 PM, Brendan Conoboy wrote: On 03/20/2012 12:19 PM, Jesse Keating wrote: What does better than secondary arch mean to you? I'm really struggling here. As an example, the same koji server handling x86 builds handling ARM builds. Only the koji hub would be the same, the arm builders would be different machines. This isn't all that different from having the primary hub trigger the arm hub to start a build on the arm builders. The same facilities providing power, cooling, storage. The PPC builders are there, or at least were at some point, why not propose moving some arm stuff there for the arm secondary arch effort? Subject to applicability, the same QE mechanisms being employed. I don't see SA/PA mattering as much here. It's up to QE what they want to take on and what they point automated tooling at. The same release schedule. That's set by you, as a secondary arch. Why not pin it to the Fedora release schedule and see how well you do? Comparable positioning on the Fedora downloads pages. That's a big ball of another issue there. That's a constant fight within the spins of the primary arch products, and from what I've seen, Arm products are more closely aligned with spins than anything else. That said, within the websites group perhaps there is room for a featured secondary arch, with high visibility. Having something to point to first would help. Primary and secondary are night-and-day different, it isn't just the integrated build system being disconnected, it's end-to-end. We as a group have identified many of the roadblocks or pain points of bringing arm into primary arch. What pain points have been described other than I am concerned about the impact of builds on the whole running slower than they do now? This is not a facetious question, this is really what we're trying to get from the thread. Did you just ignore the emails starting these two threads by mjg and pjones? I believe they outlined some very good requirements for getting a secondary arch into primary. These longer threads have been debating some of the finer points of those proposals. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/20/12 2:33 PM, Brendan Conoboy wrote: On 03/20/2012 01:03 PM, Jesse Keating wrote: As an example, the same koji server handling x86 builds handling ARM builds. Only the koji hub would be the same, the arm builders would be different machines. This isn't all that different from having the primary hub trigger the arm hub to start a build on the arm builders. So in principle, do you object to the same koji hub being used for ARM if ARM is still SA? I'm not really sure how to process that question. As a current secondary arch, the primary hub is still the trigger point for the vast majority of the builds that will happen for arm. A successful build on the primary hub will trigger (through koji-shadow) a build on the secondary arches. I'm sure you're (painfully) aware of this. I don't understand how the same koji hub could be used for arm while arm is still SA differently than above. The PPC builders are there, or at least were at some point, why not propose moving some arm stuff there for the arm secondary arch effort? ... I don't see SA/PA mattering as much here. It's up to QE what they want to take on and what they point automated tooling at. The sense I'm getting from your reply is that the PA/SA designation is almost decorative, that a secondary can do anything a primary can, except inhibit the progress of builds. Mostly. It'll take effort on the part of the secondary arch to engage these other parts of the Fedora project to convince them to pay attention to your arch. If you were a primary, they're essentially forced to care. Enticing them to care as a secondary arch goes a long long way to show that you're ready to be a primary arch and that the promotion would not cause much ripple effect. So, if the Fedora ARM team fixes all broken builds, brings in all the QE mechanisms, engages the Fedora system at every level of the organization, solves the the build time performance issue, and otherwise keep at it until we're functionally indistinguishable from PA, *then* it's time to have the PA/SA discussion. Is that right? That does seem right. Just like the old adage, dress for the job you want, not the one you have, or do the work for the promotion you want, and you'll earn the promotion, the same applies here. Show that the secondary arch can function well as a primary arch without significant burden to the rest of the project and then it's a much easier decision to make the promotion. Speaking for myself, I see most of these things as a benefit of membership in PA rather than prerequisites. Or more to the point, transitioning from SA to PA means doing all of these things, so it's really just an order of operations that needs to be agreed upon. doing all of these things doesn't happen magically just because the board/fesco grants that ARM is suddenly a primary arch. If we made arm a primary arch tomorrow, you'd still have to solve all the above issues, only now you've got hundreds of very angry developers who's workflow is now severely interrupted, and they're all calling for your head. Doesn't it make more sense to solve these issues /before/ doing the promotion? Figure out how to make the car go 60mph before taking it onto the freeway, else you'll piss off all the other cars on the freeway. That's set by you, as a secondary arch. Why not pin it to the Fedora release schedule and see how well you do? We're quite close, though clearly the QE is different. That said, within the websites group perhaps there is room for a featured secondary arch, with high visibility. Having something to point to first would help. Fair enough. Did you just ignore the emails starting these two threads by mjg and pjones? I believe they outlined some very good requirements for getting a secondary arch into primary. These longer threads have been debating some of the finer points of those proposals. On the contrary, mjg and pjones' emails are just the sort of constructive and thoughtful feedback I'm looking for. If the points they've raised (which they also raised yesterday) speak to everybody's concerns, then I'm happy to view them as the authoritative feedback of Fedora-devel for our planning purposes. On the other hand, if they've left anything out that should be considered in this plan, I'd like to see it. Fair enough, I honestly didn't think you had ignored it, and it was rude of me to suggest otherwise. I apologize for that. fedora-devel doesn't really have anything of the authoritative sort, we just have a lot of subscribers and opinions. Those opinions are usually considered by FESCo when FESCo makes a decision, and generally considered by those proposing something and asking for feedback on their way to a FESCo decision. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/20/12 5:14 PM, Adam Williamson wrote: But sure, in theory, we can do just about anything for a secondary arch that we do for a primary arch, I don't think there's any technical barrier to us doing update karma for ARM and test days for ARM and a release validation process for ARM and all the rest of it. It's just a question of motivation and personpower. My point is that the motivation and personpower can come independent of whether arm is a PA or an SA. As you say, no technical barrier. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: why are is subversion 1.7 for F16/F17 removed
On 3/12/12 12:59 PM, Reindl Harald wrote: I'm not sure. Install the build deps needed to rebuild the f17 SRPMs? they are NOT solveable for the available src.rpms on F16 that is why it makes me so crazy that once built and working packages are removed in the meantime don't do the testing on productive systems. Do the testing in a separate system (or in a VM) i DO testing in many virtual machines and tests was succesful how should i imagine that a F15 testing-version will it make even not in F16 while other packages are RELEASED as RC and even not updated after upstream-final (dbmail) Every package is different. While the subversion update required hand management to bring up to date, the dbmail may not have (note I do not know if this is true or not). You can't judge one package by another, upstream version numbers are practically meaningless, particularly when trying to compare behavior between two packages. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
On 2/28/12 12:58 AM, Vít Ondruch wrote:
If you say to Koji that it should checkout master at remote machine,
build a SRPM etc, why the Koji can't determine the proper %{?dist} at
remote machine? Why it takes the %{?dist} from local machine instead? It
makes no sense. It might work for other branches, but master is bit
different, so it should be handled differently.
For the pure build command case, sure, we let koji decide. In fact,
the way I've re-written the backend to fedpkg to make more use of python
properties and lazy loading, the build command may not actually try to
get this data. It's only the local commands that really matter.
--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
On 2/28/12 8:47 AM, Josh Boyer wrote: I was looking for a way to determine the behavior of the master branch (for the sake of dist values) without hitting the network, as that would break git's ability to work offline. The best I could come up with at the time this code was written was to check and see what other branches existed, and just increment the biggest one by one. I welcome suggestions for better ways to manage this. Didn't RHEL-CVS use a file in the local directory called 'branch'(?) I believe Fedora-CVS had the same. Except it needed to be updated at branch time, and fetched from the server across all checkouts. Makefile.common is what hid all that and nobody noticed because you had to be on the network to do anything with CVS anyway. Doing the same in git would still require a 'git pull' to get the updated file. Yep. Stale information in the branch file was one of the things I wanted to solve. Of course, I don't think I can solve it completely without requiring a network action, unless we move away from using master for rawhide and instead always have a specific branch for each release. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
On 2/29/12 1:25 PM, Tom Lane wrote:
Jesse Keatingjkeat...@redhat.com writes:
On 2/28/12 12:58 AM, VÃt Ondruch wrote:
If you say to Koji that it should checkout master at remote machine,
build a SRPM etc, why the Koji can't determine the proper %{?dist} at
remote machine? Why it takes the %{?dist} from local machine instead? It
makes no sense. It might work for other branches, but master is bit
different, so it should be handled differently.
For the pure build command case, sure, we let koji decide. In fact,
the way I've re-written the backend to fedpkg to make more use of python
properties and lazy loading, the build command may not actually try to
get this data. It's only the local commands that really matter.
Oh? In the complaint that started this thread, I showed an example of
launching fedpkg build in master branch and getting an fc17-candidate
result. That seems to me to prove that it isn't koji deciding.
Right, that's the way it is now, because I never went through with
hardcoding the target as 'dist-rawhide'. Once I do that, it may bypass
the block of code that looks at the branch names.
In the particular case here it was harmless, since I would've just gone
and built the identical SRPM in f17 a bit later anyway, and (I trust)
rawhide will inherit the new f17 package too.
I can see the argument why fedpkg srpm and friends should produce
similar results to what you get from fedpkg build, because I have lost
count of the number of times I've cursed the fact that it's impossible
to reproduce the koji build environment elsewhere. On the whole I'm not
attracted to introducing still another discrepancy compared to what
happens in local builds.
regards, tom lane
--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 2/24/12 12:10 PM, Ville Skyttä wrote: On 2012-02-23 20:06, Jesse Keating wrote: Could you help me figure out why path completion with ~/ isn't working in fedpkg, but with full paths it is? I assume there is something wrong in the (contributed) bash completion file. https://fedorahosted.org/fedpkg/ticket/3 Thanks. That just further confirms that bash completion syntax is strange and complicated, and I know very little about it :) -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
On 2/27/12 8:37 AM, Tom Lane wrote: Orion Poplawskior...@cora.nwra.com writes: On 02/27/2012 09:09 AM, Tom Lane wrote: WTF? Do I need to fix this, and if so how? git pull (to bring in the f17 branch and mark devel as f18) Hmm, that package indeed hadn't had f17 git pull'd yet. (I had scripted a git pull in all my package directories after the branch, but I think that it failed in this one due to uncommitted changes.) So you're saying that fedpkg's behavior depends on the existence of other, un-checked-out, branches in my local repo? This seems a tad ... unreliable. Not to say surprising. regards, tom lane I was looking for a way to determine the behavior of the master branch (for the sake of dist values) without hitting the network, as that would break git's ability to work offline. The best I could come up with at the time this code was written was to check and see what other branches existed, and just increment the biggest one by one. I welcome suggestions for better ways to manage this. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: master branch still invokes build in f17-candidate??
On 2/27/12 5:53 PM, Kevin Kofler wrote:
Jesse Keating wrote:
I was looking for a way to determine the behavior of the master branch
(for the sake of dist values) without hitting the network, as that would
break git's ability to work offline. The best I could come up with at
the time this code was written was to check and see what other branches
existed, and just increment the biggest one by one. I welcome
suggestions for better ways to manage this.
What was wrong with the good old dist-rawhide target? Making master always
use a rawhide target obviates the need of having to check out what n in
fn-candidate to build for.
Kevin Kofler
Because you still don't know what %{?dist} (and others) should be. What
does dist-rawhide mean? Well it could be .fc17, or it could mean
.fc18, which could make a big difference to conditionals within the spec
file.
Although the plan was at one time to make use of the dist-rawhide
target, I'm not sure what derailed that plan, and if possible we should
go through with that plan, but the above problem remains (it'd just come
into play less often).
--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Please create Fedora 17 in Bugzilla
On 2/17/12 12:43 AM, Dennis Gilmore wrote: I actually have no idea how to access that account. So saying that releng has access is a gross overstatement. There is an account that some people have access to use is a more correct statement. I believe my bugzilla account had the rights to create new releases. I didn't have to log into any other account, the rights were just granted to mine. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 2/19/12 3:43 AM, Ville Skyttä wrote: On 2012-02-18 20:26, Rahul Sundaram wrote: On 02/18/2012 11:05 PM, Ville Skyttä wrote: You can get the completion to work according to that preference with for example yum install ./fooTAB - anything that looks like a filesystem path triggers filename-only completion, otherwise we do both filenames and repos. That's atleast understandable but there seems to be a big slowdown when doing rpmlint tab completion as well. Not sure why. rpmlint footab is much slower with bash-completion installed. The same thing applies to rpmlint. Anything that looks like a file path gets treated as a file path and is quick; otherwise we need to look up both files and rpmdb, and even though it has been getting better, the latter unfortunately isn't that quick. Could you help me figure out why path completion with ~/ isn't working in fedpkg, but with full paths it is? I assume there is something wrong in the (contributed) bash completion file. https://fedorahosted.org/fedpkg/browser/src/fedpkg.bash -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 2/8/12 4:30 PM, Reindl Harald wrote: it is a very good idea because the overall quality of fedora would be improved if there would be a larger release-blocking to get the big changes fixed BEFORE alpha and in the meantime not involved maintainers could proceed fixing the tons of small bugs and polish the distribution at all - there are really neough rough corners involved in the last releases to work on that there is no need to proceed this way of releasing and starting alpha/beta with known broken things The entire point of having alpha/beta releases is to get wide testing without having everything perfect. If it were perfect, it'd be the release. So you have relaxed requirements for earlier stages of the release. In this case, anaconda upgrades is not a required functionality for the Alpha release. It is required however for Beta. We can go ahead with Alpha and get wider testing on everything else, while anaconda team and others work on the upgrade issue, and hope to have it fixed by Beta time. This is how software development works. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Need karma on fedpkg update for F15
Trying to get the fedpkg rewrite out into stable. Got karma for f16, still need enough karma to overcome earlier bad karma on earlier update versions for f15. https://admin.fedoraproject.org/updates/FEDORA-2011-15270 Thanks for helping! P.S. Could use the same for el6 if any of you are epel inclined. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Nov 21, 2011, at 1:53 PM, Jóhann B. Guðmundsson wrote: On 11/21/2011 09:25 PM, Michael Schwendt wrote: Unconvincing. To reassure ownership periodicially won't be sufficient. It would be just another button to click (like FAS password or cert renewal) and would not guarantee that the packages would be maintained properly and that tickets would be dealt with. A sign of life from a person does not imply that the person's packages are (well-)maintained. Well if people want more controversial proposal of sign of live that's relatively easier to accomplish. Revoke that maintainers package privileges for $next-release if he does not respond to bug reports in timely manner in GA releases and orphan his package. Arguable a bit drasting but at the same time far more effective clean up process. I cant image how much resources across the project have been spent on packages that no longer are being actively maintained but have not been removed from the distribution. Might be true. I agree with your concerns, just not with how you'd like to tackle the problem.;) I think the soft approach will still be more efficient then current implemented solution. The hard approach would certainly be the most efficient one and at the same time teach packager/maintainers a thing or two against their responsibility towards the community and least but not least towards our end user base and arguably it might be doing the relevant maintainers a favour as in they have not realised or have not come in terms with the fact that they no longer have the time to maintain their package(s) and that approach would serve as a bit of a wakeup call but as I mention some people might find that a bit of an harsh approach to the problem. I'm all ears for any solutions to the task at hand that you might have up your sleeve. JBG This has come up nearly every release cycle. Problem is that nobody can seem to agree on what an appropriate sign of life would be, no has made a serious FESCo proposal for a contrived sign of life. I don't think anybody disagrees (well maybe KKoffler) that unmaintained software should be discovered and ejected from the distro, the entirety of the problem lies how to discover (as well as side issues about what to do about maintainers that are active for one package, but completely ignore 3 others, etc…) So if you are serious about wanting this fixed, draft a proposal, figure out who's going to do the coding work, and bring it to FESCo. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Nov 21, 2011, at 2:29 PM, Jóhann B. Guðmundsson wrote: So who's ultimately responsible for making sure that packagers are following the current guidelines set by FPC releng? the community. You see, the problem with a volunteer community is that enforcement basically boils down to A) take away your commit access, and/or B) $somebody corrects the violation. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Nov 21, 2011, at 2:22 PM, Jóhann B. Guðmundsson wrote: So if you are serious about wanting this fixed, draft a proposal, figure out who's going to do the coding work, and bring it to FESCo. I would think this work directly falls under releng jurisdiction ( given that releng is ultimately responsible for the bits being shipped to end users and at the same time are the once most familiar with the inner packaging process ) in accordance with what FPC or FESCO decide. Unless you get the volunteer release engineers on board with doing the work, this is a non-starter. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New build of fedpkg (fedora-packager) coming to updates-testing / rawhide
On Nov 15, 2011, at 1:54 AM, Marek Goldmann wrote: I see the same issue with clone on F16: [goldmann@nightmare fedora]$ fedpkg clone appliance-tools Could not execute clone: must be type, not classobj [goldmann@nightmare fedora]$ rpm -q fedpkg fedpkg-1.5-1.fc16.noarch Downgrading to fedpkg-1.1-1.fc16.noarch helped. Somebody reported this when they didn't have the right ssl certs in place. With the newer fedpkg installed, can you do a fedpkg clone -v appliance-tools ? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Announcing the release of Fedora 16.
On Nov 14, 2011, at 3:38 PM, Adam Williamson wrote: On Tue, 2011-11-08 at 17:48 +0100, Gerd Hoffmann wrote: Hi, Fedora 16 is not science fiction. It is here right now: http://get.fedoraproject.org Hmm, no jigdo downloads any more? Releng say they dropped jigdo due to overwhelming indifference (the download numbers for the jigdo images were tiny). When releng agreed to do jigdo, the proponents of it promised better tooling in the near future to create the jigdo data. That tooling was never delivered, and the process to create jigdo data continues to be manual, arduous, error prone, and still difficult for clients to manage. While I wasn't part of the decision to drop it, I wholly support the decision. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: no rawhide images/
On Nov 14, 2011, at 10:24 AM, Dave Jones wrote: Looking at http://kojipkgs.fedoraproject.org/mash/rawhide-2014/logs/mash.log (and previous logs), I don't see any obvious message for why the images/ directory isn't being created in the composes. anyone have info on what's broken ? Dave We don't make images for Rawhide, we haven't for a number of releases now. Images only get turned on when we branch. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
