library path
Hi all. I am currently working on an openmotif .spec which contains libs that are also part of the lesstif package. I am now planning to move them to /usr/lib/openmotif and wonder if it makes sense to place them in a subfolder like /usr/lib/openmotif/lib or directly into /usr/lib/openmotif. Best Regards Marcus -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: library path
On Tue, Jul 14, 2009 at 8:56 AM, Marcus Moellerm...@marcus-moeller.de wrote: Hi all. I am currently working on an openmotif .spec openmotif is being packaged at rpmfusion due to its license: http://bugzilla.rpmfusion.org/show_bug.cgi?id=461 -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Feature proposal: Rebootless Installer
Fedorans, Can you spare 50 or 100K? If you can spare 100K/700M in the forthcoming Fedora-12 LiveCD, I can provide you with a rebootless installation experience. http://fedoraproject.org/wiki/Features/RebootlessInstaller The short story is that you boot the LiveCD/USB, run the installation, and then, instead of rebooting into the installed OS, you are already looking at and using it. I just threw together a decent first pass at a feature page, with all the relevent info, as well as a couple links to youtube videos showing the complete user experience. Or, if you are the adventurous kind with an idle test system (obviously with no important unbacked up data), simply a) boot an f11-i686 livecd or usb, with an internet connection b) firefox http://viros.org/rebootless c) click the i386 rpm link, and submit to packagekit d) do any partitioning beforehand with fdisk, or whatever gui tool (is palimpsest really supposed to be able to repartition?) e) launch the new desktop icon f) run the installer, simply selecting target root/boot/swap partitions g) enjoy the coolness that is rebootless installation, and my gratitude for being one of the first, if not the second tester :) I would obviously love to see this in F12 even though it could use quite a bit of polish. It is fairly important that it go in sooner rather than later, as when unionfs percolates to fedora, this feature may no longer be technically possible. In the event the feature were wildly popular, and sticks around, obviously integration with anaconda would be next, i.e. simply a checkbox before beginning installation stating whether you want rebootless instead of traditional. In any event, I'd love to hear what people think. I suppose if space is the issue, it could even be a feature just getting the package into the fedora repos so that it could be advertised, with users just needing an internet connection, and not having to see a complaint about lack of signature on the package. But cmon, can you spare 100K? (50 of that is ego/logo I can probably part with :) peace... -dmc -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
NVR bugs in rawhide
I found 375 possibly wrong NVRs in rawhide. Can you check it an fix it, please? I'd like to file bugs for those which won't get fixed in couple weeks. Short explanation of detected errors follows: Release doesn't contain a %dist tag. - %dist is missing in Release: in spec - http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag Pre-release build's release should start with '0.'. - a pre-release build is detected with these patterns: test, alpha, beta, rc, [\.0-9]a[\.0-9], b[0-9]+, snap, pre, dev, build, bzr, cvs, svn, git, hg, trunk, branch - release should start with .0, but generally it can start with any number as long as it's bumped before each build. - http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages Release format can be wrong. Unknown non-numeric characters in release. - release contains characters different than dots and numbers does not match any of pre-release patterns - please report any detected false-positives Extra characters after %dist tag. - there should not be any characters after %dist - the only exception is a workaround for older releases to keep upgrade path: 2.fc10.1 2.fc11 - rawhide definitely shouldn't contain these - http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches abcde-2.3.99.6-8.src.rpm - Release doesn't contain a %dist tag. abicheck-1.2-22.src.rpm - Release doesn't contain a %dist tag. advancecomp-1.15-11.src.rpm - Release doesn't contain a %dist tag. agedu-0-1.r8442.fc12.src.rpm - Release format can be wrong. Unknown non-numeric characters in release. alliance-5.0-26.20070718snap.fc11.src.rpm - Pre-release build's release should start with '0.'. alsamixergui-0.9.0-0.5.rc1.fc11.2.src.rpm - Extra characters after %dist tag. alsa-tools-1.0.20-1.fc12.2.src.rpm - Extra characters after %dist tag. alt-ergo-0.8-5.fc12.1.src.rpm - Extra characters after %dist tag. aprsd-2.2.5-15.5.fc11.1.src.rpm - Extra characters after %dist tag. armacycles-ad-0.2.8.3-1.rc2.fc12.src.rpm - Pre-release build's release should start with '0.'. atmel-firmware-1.3-5.src.rpm - Release doesn't contain a %dist tag. atomix-2.14.0-6.1.src.rpm - Release doesn't contain a %dist tag. audacious-plugin-fc-0.3-3.src.rpm - Release doesn't contain a %dist tag. autofs-5.0.4-30.src.rpm - Release doesn't contain a %dist tag. automake15-1.5-26.src.rpm - Release doesn't contain a %dist tag. automake16-1.6.3-15.src.rpm - Release doesn't contain a %dist tag. automake17-1.7.9-12.src.rpm - Release doesn't contain a %dist tag. basesystem-10.0-2.src.rpm - Release doesn't contain a %dist tag. bbkeys-0.9.0-12.src.rpm - Release doesn't contain a %dist tag. bchunk-1.2.0-8.src.rpm - Release doesn't contain a %dist tag. blackbox-0.70.1-13.src.rpm - Release doesn't contain a %dist tag. blt-2.4-30.z.fc11.src.rpm - Release format can be wrong. Unknown non-numeric characters in release. bogl-0.1.18-16.src.rpm - Release doesn't contain a %dist tag. boinc-client-6.4.7-10.r17542svn.fc11.src.rpm - Pre-release build's release should start with '0.'. boswars-addons-2.5-2.src.rpm - Release doesn't contain a %dist tag. bouml-doc-4.3.2-2.src.rpm - Release doesn't contain a %dist tag. bwbar-1.2.3-4.src.rpm - Release doesn't contain a %dist tag. ca-certificates-2008-8.src.rpm - Release doesn't contain a %dist tag. cadaver-0.23.2-5.src.rpm - Release doesn't contain a %dist tag. camE-1.9-14.src.rpm - Release doesn't contain a %dist tag. castor-0.9.5-4.fc12.1.src.rpm - Extra characters after %dist tag. cdrdao-1.2.3-0.rc2.2.src.rpm - Release doesn't contain a %dist tag. checkgmail-1.13-4.svn20080730.fc11.src.rpm - Pre-release build's release should start with '0.'. chkconfig-1.3.42-1.src.rpm - Release doesn't contain a %dist tag. chrony-1.23-5.20081106gitbe42b4.fc12.src.rpm - Pre-release build's release should start with '0.'. clc-intercal-0-0.1.1._94._2.fc11.src.rpm - Release format can be wrong. Unknown non-numeric characters in release. clipper-2.1-7.20090522cvs.fc12.src.rpm - Pre-release build's release should start with '0.'. cluster-3.0.0-19.rc4.fc12.src.rpm - Pre-release build's release should start with '0.'. cmigemo-1.3-0.7.c_MIT.fc11.1.src.rpm - Extra characters after %dist tag. - Release format can be wrong. Unknown non-numeric characters in release. colordiff-1.0.8a-3.src.rpm - Release doesn't contain a %dist tag. color-filesystem-1-5.src.rpm - Release doesn't contain a %dist tag. compat-expat1-1.95.8-5.src.rpm - Release doesn't contain a %dist tag. compat-gcc-296-2.96-142.src.rpm - Release doesn't contain a %dist tag. compat-gcc-32-3.2.3-66.src.rpm - Release doesn't contain a %dist tag. compat-gcc-34-3.4.6-13.src.rpm - Release doesn't contain a %dist tag. compat-libgfortran-41-4.1.2-37.src.rpm - Release doesn't contain a %dist tag. compface-1.5.2-10.src.rpm - Release
Re: NVR bugs in rawhide
On Tue, Jul 14, 2009 at 10:21:13AM +0200, Daniel Mach wrote: I found 375 possibly wrong NVRs in rawhide. Can you check it an fix it, please? I'd like to file bugs for those which won't get fixed in couple weeks. Short explanation of detected errors follows: Release doesn't contain a %dist tag. - %dist is missing in Release: in spec - http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag The guideline you refer to says if you wish to use a single spec file So I don't see why not using %dist would be a bug if you don't wish to do that. Jakub -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On Tue, 2009-07-14 at 10:21 +0200, Daniel Mach wrote: Release doesn't contain a %dist tag. - %dist is missing in Release: in spec - http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag If you wish, so until now it hasn't been an error to not have one. Has this changed ? Pre-release build's release should start with '0.'. - a pre-release build is detected with these patterns: test, alpha, beta, rc, [\.0-9]a[\.0-9], b[0-9]+, snap, pre, dev, build, bzr, cvs, svn, git, hg, trunk, branch - release should start with .0, but generally it can start with any number as long as it's bumped before each build. But of course we also have post-release snapshot packages, so if alliance-5.0-26.20070718snap is a svn/cvs snapshot *post* 5.0 release then its be perfectly correct, right ? C. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On 14.07.2009 10:04, Douglas McClendon wrote: [...]In any event, I'd love to hear what people think. [...] I for one think rebooting after install is a very good thing, as only a full reboot makes sure the install (including boot loaders) was completely successful and works fine. Or IOW: I for one would be really annoyed if I'm doing a rebootless install and after hours of customizing and using it notice after a reboot that the install doesn't boot due to a broken boot-loader installation/configuration. Just my 2 cent. CU knurd -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Thorsten Leemhuis wrote: On 14.07.2009 10:04, Douglas McClendon wrote: [...]In any event, I'd love to hear what people think. [...] I for one think rebooting after install is a very good thing, as only a full reboot makes sure the install (including boot loaders) was completely successful and works fine. Also, one possible way to potentially mitigate this danger with yet another device mapper trick would be to- After installation, create a snapshot of the system disk(s), then boot them headlessly under qemu in some way that you could tickle them into proving that the bootloader worked (perhaps an init script that detects this type of test qemu run, and provides some output than can be caught). -dmc -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On Tue, 14 Jul 2009 10:21:13 +0200, Daniel wrote: I found 375 possibly wrong NVRs in rawhide. Can you check it an fix it, please? I'd like to file bugs for those which won't get fixed in couple weeks. Short explanation of detected errors follows: Release doesn't contain a %dist tag. - %dist is missing in Release: in spec Often on purpose. Not a bug. Extra characters after %dist tag. - there should not be any characters after %dist - the only exception is a workaround for older releases to keep upgrade path: 2.fc10.1 2.fc11 - rawhide definitely shouldn't contain these Should not or must not? http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches iniparser-3.0-0.1.b.fc12.src.rpm - Release format can be wrong. Unknown non-numeric characters in release. Not a bug. The .1 in 0.1 here is the portion of %release that is more significant than the parts following it. painstakingly, one would bump it with every change of the package, no matter whether the .b changes, too. - Pre-release build's release should start with '0.'. Too late to correct it (for many of the findings). And often they are not even an error, because with post-release (!) scm snapshots, upstream *and* packagers typically don't increase %version -- particulary not if the next official %version is not known yet. So, once the next final upstream release is made, %version will increase. And only then one can reset %release to 0 or 1. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On Tue, 2009-07-14 at 02:04 -0600, Douglas McClendon wrote: Can you spare 50 or 100K? If you can spare 100K/700M in the forthcoming Fedora-12 LiveCD, I can provide you with a rebootless installation experience. http://fedoraproject.org/wiki/Features/RebootlessInstaller The short story is that you boot the LiveCD/USB, run the installation, and then, instead of rebooting into the installed OS, you are already looking at and using it. I think this needs a lot more discussion before it's considered. As others have said, rebooting is often necessary with our current modus operandi and whether we like it or not, it is consistent. Besides, most people don't mind an *expected* reboot after they do a major upgrade. Me, I normally set aside a weekend for Fedora major upgrades anyway. It's not something I'm inclined to do without some planned downtime, since the last two times I've had an hour of fixing to do afterward. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
bchunk: dead package
https://fedorahosted.org/rel-eng/ticket/1977 bchunk is said to be obsolete, because shntool (also in Fedora) would be superior. If you disagree and find a good reason to adopt bchunk, please find a solution for the open ticket. Originally, I had sponsored Alan Olson (alano) when he wanted to take over this old package in Fedora. A deal that hasn't worked out this time. The single bugzilla ticket (#439661)is without a response/action since over a year. And attempts at contacting alano via private mail and bugzilla have been fruitless. As such, I've removed him from the FAS Packager group, too. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Jon Masters wrote: On Tue, 2009-07-14 at 02:04 -0600, Douglas McClendon wrote: Can you spare 50 or 100K? If you can spare 100K/700M in the forthcoming Fedora-12 LiveCD, I can provide you with a rebootless installation experience. http://fedoraproject.org/wiki/Features/RebootlessInstaller The short story is that you boot the LiveCD/USB, run the installation, and then, instead of rebooting into the installed OS, you are already looking at and using it. I think this needs a lot more discussion before it's considered. As others have said, rebooting is often necessary with our current modus operandi and whether we like it or not, it is consistent. Besides, most people don't mind an *expected* reboot after they do a major upgrade. I quite agree that more discussion is needed as it is considered. But my own biased opinion is that several days to a week and a half of flushing out issues here and on the feature talk page, should be sufficient to provide fesco members with enough confidence to approve this feature. Again, I emphasize that this is in a way akin to putting ext4 in f10. It was there, but a default user experience wouldn't touch the code. I think there is a justifiable place in fedora 12 for this experimental technology. Please elaborate on the necessary reboots that are part of the 'current modus operandi'. I can think of a few things, but nothing that would cause me concern that the feature would have any significant detrimental impact on the reception of and satisfaction with F12. I personally think the feature if advertised similarly to one which could lead to data corruption on the root filesystem (e.g. ext4 in f10), that it could overall be appreciated by some users, and be good press at the same time, IMNSHO... But absolutely, before fesco considers this, I do want all the potential gotchas and risks to be thoroughly vetted. I don't however think at all that the risks are such that this is too late a time to seriously propose this for F12. peace... -dmc -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On 2009/07/14 02:04 (GMT-0600) Douglas McClendon composed: [snip] http://viros.org/rebootless Doesn't kexec, which does a BIOS bypassing reboot, accomplish what you want? OpenSUSE's installer has had kexec_reboot=1 by default for a version or two (I think default started with 11.1): http://en.opensuse.org/Kexec http://en.opensuse.org/Linuxrc -- No Jesus - No peace , Know Jesus - Know Peace Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
Jakub Jelinek wrote: On Tue, Jul 14, 2009 at 10:21:13AM +0200, Daniel Mach wrote: I found 375 possibly wrong NVRs in rawhide. Can you check it an fix it, please? I'd like to file bugs for those which won't get fixed in couple weeks. Short explanation of detected errors follows: Release doesn't contain a %dist tag. - %dist is missing in Release: in spec - http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag The guideline you refer to says if you wish to use a single spec file So I don't see why not using %dist would be a bug if you don't wish to do that. Jakub Right, %dist is not mandatory in Fedora. But Fedora is upstream for RHEL and we'll probably consider this as a bug in RHEL once we import some Fedora packages. I think it's better to fix it upstream rather than do our local fixes. Why we do it? For example, you can't push a rpm signed with two different keys to Spacewalk channels (which happens when you use per-release signing keys). Therefore we have to make difference between NVRs and add %dist. I'll discuss possible Fedora NVR policy changes with spot. - daniel -- Daniel Mach dm...@redhat.com Release Engineering, Red Hat -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On Tue, 14 Jul 2009, Daniel Mach wrote: Right, %dist is not mandatory in Fedora. But Fedora is upstream for RHEL and we'll probably consider this as a bug in RHEL once we import some Fedora packages. I think it's better to fix it upstream rather than do our local fixes. It being required for rhel does not make it a fedora bug. If you want to fix it for YOUR packages, that's fine, but it's not everyone's problem. Why we do it? For example, you can't push a rpm signed with two different keys to Spacewalk channels (which happens when you use per-release signing keys). Therefore we have to make difference between NVRs and add %dist. But fedora doesn't use spacewalk and we don't have the above problem. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Felix Miata wrote: On 2009/07/14 02:04 (GMT-0600) Douglas McClendon composed: [snip] http://viros.org/rebootless Doesn't kexec, which does a BIOS bypassing reboot, accomplish what you want? OpenSUSE's installer has had kexec_reboot=1 by default for a version or two (I think default started with 11.1): http://en.opensuse.org/Kexec http://en.opensuse.org/Linuxrc No, from a user experience perspective, a kexec 'warm' reboot is still a reboot. There is AFAIK no user experience example to look to in comparison. Perhaps somewhere along the line people tried pivot_roots after installation, but short of this devicemapper trick, there was always the trouble that tied up file descriptors would prevent you from being able to eject the livecd. I could be wrong about that, or my interpretation of what kexec does (I've read about it often in LWN, but never knowingly used it). Your first link seems currently broken (database error), and the second doesn't really lead me to believe it is anything equivalent. I haven't used *suse that much recently so I can't be sure- Is it perhaps something where they have a very minimal partial installation, then start writing the minimal stuff to disk, kexec-reboot, and then set you up in system that is finishing installing while you use it? If so, one way to describe the major benefit of my rebootless installer, is that you get to boot the livecd/usb environment, *then use it as such*, and at your option, desire, and convenience, decide to permanently install the LiveOS you have just been using and configuring, to disk. And of course when done, just pop out the livecd/usb, and your are done... and free to leave your system with a continuingly increasing uptime :) peace... -dmc -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
Caolán McNamara wrote: On Tue, 2009-07-14 at 10:21 +0200, Daniel Mach wrote: Release doesn't contain a %dist tag. - %dist is missing in Release: in spec - http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag If you wish, so until now it hasn't been an error to not have one. Has this changed ? Nothing changed. See my reply to Jakub's email, please. Pre-release build's release should start with '0.'. - a pre-release build is detected with these patterns: test, alpha, beta, rc, [\.0-9]a[\.0-9], b[0-9]+, snap, pre, dev, build, bzr, cvs, svn, git, hg, trunk, branch - release should start with .0, but generally it can start with any number as long as it's bumped before each build. But of course we also have post-release snapshot packages, so if alliance-5.0-26.20070718snap is a svn/cvs snapshot *post* 5.0 release then its be perfectly correct, right ? C. That's a good point, I was never thinking about post-release snapshot packages, always just about pre-release ones. Thanks for catching that. - daniel -- Daniel Mach dm...@redhat.com Release Engineering, Red Hat -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On Tue, 14 Jul 2009 14:21:28 +0200, Daniel wrote: Release doesn't contain a %dist tag. - %dist is missing in Release: in spec Often on purpose. Not a bug. Can you be more specific, please? What's exactly the purpose? That %dist isn't used. There are various reasons why somebody may decide against using %dist. One example are noarch data packages that want to utilise koji build inheritance. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On 07/14/2009 08:48 AM, Jussi Lehtola wrote: %dist should be used always. As the person who invented %dist, I can assure you, this is false. In the specific situation where a new noarch package with relatively static content is being introduced, you have a few options: * Use %dist * Manually ensure that the upgrade ordering is sane (e.g. foo-1.2.3-1 (fc10), foo-1.2.3-2 (fc11), foo-1.2.3-3 (rawhide) * Only build in rawhide and let inheritance pull it in for future releases (doesn't work for past releases). Admittedly, I think using %dist is easier/saner, but it isn't mandatory. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads UP - PHP 5.3.0 in rawhide with new ABI/API.
TODO cups-php sipwitch-php-swig uuid-php php-eaccelerator php-suhosin Upstream has no new version ready. I do not know if there is any way to disable the package until a new version becomes available. OTHER TODO gr, Bart -- Bart Vanbrabant b...@vanbrabant.eu -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help on CMake usage (read gecko's libdir variable)
2009/7/13 Yuan Yijun bbbush.y...@gmail.com: Hi, The package chmsee used to need a patch to read libdir variable. The original patch can be found here https://bugzilla.redhat.com/attachment.cgi?id=303660 of https://bugzilla.redhat.com/427622 Now latest chmsee switched to use CMake instead. I cannot figure out how to apply such a patch. Anyone can help? problem solved. The patch is no longer necessary because of Gecko's API change: use GRE_GetGREPathWithProperties() and its param of type GREVersionRange to find correct path at runtime. Thanks! -- bbbush ^_^ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On Tue, 14 Jul 2009 15:48:11 +0300, Jussi wrote: On Tue, 2009-07-14 at 14:48 +0200, Michael Schwendt wrote: On Tue, 14 Jul 2009 14:21:28 +0200, Daniel wrote: Release doesn't contain a %dist tag. - %dist is missing in Release: in spec Often on purpose. Not a bug. Can you be more specific, please? What's exactly the purpose? That %dist isn't used. There are various reasons why somebody may decide against using %dist. One example are noarch data packages that want to utilise koji build inheritance. ... except that doesn't help anything. ?? Let me be more clear then. You don't need to drop %dist for koji build inheritance to work. It just looks much cleaner to inherit foo-1.0-1.noarch.rpm for all newer targets -- than to inherit foo-1.0-1.fc9.noarch.rpm and have users scratch their heads (even if release notes mention that packages with old dist tags may be found in a new dist release). %dist should be used always. No. Particulary for noarch data packages, using %dist bears an additional risk. Because it becomes possible to tag a package on multiple branches and break inheritance by building for more than the oldest branch. In other cases, for example, %dist suggests that a spec/src.rpm would be dist-independent and could simply be copied to multiple branches. That doesn't need to be true. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Hi, although (as others pointed out) a reboot may be necessary one way or the other, my opinion would be: Why not? Currently you are *forced* to reboot which now seems not to be a must have. So why not remove that force and allow the user to decide when to reboot? (Maybe one would like to install all available updates before he has to reboot *again* because kernel updates or stuff). So before any flaming starts: Please keep in mind that no one wants to *remove* reboot. ;) my 2ct christoph signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Christoph Höger wrote: Hi, although (as others pointed out) a reboot may be necessary one way or the other, my opinion would be: Why not? Currently you are *forced* to reboot which now seems not to be a must have. Thanks for the feedback. Glad to see somebody else can see the added value that doesn't obviously (to me) imply any negative consequence (except for the 100kb/700M space on the LiveCD). To respond to Rahul's response, I think you have it right. Currently, when doing an install of Fedora 11, without my installer, the user is 'forced' to reboot in order to start 'really' using the newly installed system. (see next paragraph for '' explanation) So why not remove that force and allow the user to decide when to reboot? (Maybe one would like to install all available updates before he has to reboot *again* because kernel updates or stuff). But to demonstrate a lack of bias, I will mention that you are currently able to do something like a chroot'd yum update on the installed system without rebooting, without my installer. But this also highlights the benefit- it's a lot more trivial and intuitive to update your system if it is the one running in front of you, than if it is one you have to mount and chroot, and probably even throw in some bindmounts to manage. So before any flaming starts: Please keep in mind that no one wants to *remove* reboot. ;) ;) peace... -dmc -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On Tue, 2009-07-14 at 15:37 +0200, Michael Schwendt wrote: %dist should be used always. No. Particulary for noarch data packages, using %dist bears an additional risk. Because it becomes possible to tag a package on multiple branches and break inheritance by building for more than the oldest branch. So, how do you do it without the %dist branch? AFAIK then you have to manually make sure that the EVR in F(N) is greater than that in F(N-1). Say I've built foo-1-1 in rawhide a year ago and thus the package is available now in F-10 and F-11. How do I update to foo-2-1 in both distros? In other cases, for example, %dist suggests that a spec/src.rpm would be dist-independent and could simply be copied to multiple branches. That doesn't need to be true. Yes, that is true. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Another thing to keep in mind that immediately post-installation there are going to be updates, which will at a minimum need desktop reset (fast reboot experience), or more likely system restart. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Colin Walters wrote: On Tue, Jul 14, 2009 at 4:04 AM, Douglas McClendondmc.fed...@filteredperception.org wrote: i.e. simply a checkbox before beginning installation stating whether you want rebootless instead of traditional. I don't think the installation process needs more questions. Also, off by default means it won't get testing and will eventually bitrot. I think we would only ever consider adding a checkbox (not a question) to anaconda, if the initial reception of the feature in, e.g. F12, was so positive that it justified it without requiring any advocacy on my part. It's unclear to me what your plan is for handling firstboot, which is a critical part of the OS setup. Now, we should probably move most of the current firstboot questions into anaconda. At a minimum, it'd be useful to ask them when you'd otherwise be staring at the image copying progress bar. I'll try to add this to the wiki. My intention was to start with the minimum possible for the first experimental release (f12, alpha freeze in 3 weeks). With the feature accepted, and me currently being unemployed, the minimum possible might actually be quite a bit though. My answer of course is the same as what you mentioned, they go into the installer. Honestly a create user, change rootpw, and similar complexity pages are not that difficult to add. It is also quite acceptable to move anything that can be done as 'regular system maintenance and reconfiguration' out of the installer. The whole philosophy of a LiveOS is that you boot in the most generic agnostic way possible, and let the user configure at runtime. I.e. it's actually a really good thing IMO to force the user to say use system-config-time or whatever to change the timezone. I know too many examples from personal experience, dating back to the days when you couldn't easily tab out system-config- how much of a pain it was to learn how to administer things that were done in the installer. Another issue that occurs to me is that the livecd user, besides not matching the target username, also has no password (and I believe won't have an encrypted gnome keyring), but this is different from the expected target installation. My long term ideal vision for this, would be to have gdm login accept an arbitrary user/pass instead of the autologin of liveuser, then that user/pass would be the initial user. Obviously with an option at install time to disable the mode subsequently, probably default on. Though possibly left off for people who want a very guest permissive system. For now, a simple addition to my installer already in my ROADMAP is a checkbox in the installer 'delete liveuser account upon logout'. So this looks technically cool, but there are a lot of problems to investigate and solve that it brings up. Thanks for the positive feedback, and I do agree. In response to some of the prior feedback, I already adjusted the wiki release notes to emphasize the experimental status. peace... -dmc -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Colin Walters wrote: Another thing to keep in mind that immediately post-installation there are going to be updates, which will at a minimum need desktop reset (fast reboot experience), or more likely system restart. I don't exactly get this. I might understand some negligible things. But historically I've often done -normal install, reboot -booted, logged in using everying, then a massive yum update, then I'd wait till it was absolutely convenient to logout of the desktop or reboot In fact, when I felt I needed to do it before my convenience, I generally regarded it as a pretty horrible bug. peace... -dmc -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On Tue, 2009-07-14 at 02:04 -0600, Douglas McClendon wrote:
Fedorans,
Can you spare 50 or 100K? If you can spare 100K/700M in the forthcoming
Fedora-12 LiveCD, I can provide you with a rebootless installation
experience.
http://fedoraproject.org/wiki/Features/RebootlessInstaller
The short story is that you boot the LiveCD/USB, run the installation,
and then, instead of rebooting into the installed OS, you are already
looking at and using it.
snip
Hi Doug,
I think this is an interesting idea and I don't see why you it should
not be done (if you are willing to do the work). It would also IMHO be a
cool killing feature (from marketing POV) ;-) My idea of how this would
be implemented best is:
1. do the installation
2. on the last page instead of plain thank you for installing and
exit (I don't recall what exactly is on the last anaconda page) would
be thank you for installing and start using the installed system
now, continue using {Desktop, KDE, ...} Live and reboot buttons.
If you pushed the start using the installed system now you'd start
using the system from hdd and the live CD/DVD would be ejected. Also it
would be probably good idea to pop-up a notification icon that suggests
reboot (like package-kit does for e.g. kernel updates).
If you pushed the continue using {Desktop, KDE, ...} Live it would
just quit the installer and suggest reboot in a similar case as before.
If you pushed the reboot one it would quit the installer and forced a
reboot (and perhaps prompted the user to save their work).
Of course it could be made into radiobuttons instead of buttons with
just one Finish or whatever button.
The default would stay continue using {Desktop, KDE, ...} Live.
This would of course work only for Live Spins, I don't see any reason to
try to push this to the standard DVD or network installs.
Also you'd need to properly handle firstboot in this case, which would
be bypassed. Me thinks firstboot should be purged anyway, but it still
exists and you need to be aware of it.
Just my €0.02,
Martin
signature.asc
Description: This is a digitally signed message part
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On 2009/07/14 05:38 (GMT-0600) Douglas McClendon composed: Felix Miata wrote: Doesn't kexec, which does a BIOS bypassing reboot, accomplish what you want? OpenSUSE's installer has had kexec_reboot=1 by default for a version or two (I think default started with 11.1): http://en.opensuse.org/Kexec http://en.opensuse.org/Linuxrc ... I could be wrong about that, or my interpretation of what kexec does ... The first URL explains it. Your first link seems currently broken (database error), and the second It worked and works for me. doesn't really lead me to believe it is anything equivalent. The second URL is mainly a list of installer options, and affirms my statement that kexec is now a default option. used *suse that much recently so I can't be sure- Is it perhaps something where they have a very minimal partial installation, then start writing the minimal stuff to disk, kexec-reboot, and then set you up in system that is finishing installing while you use it? If so, one IIRC most rpms, initrd Grub are installed by the initial installer, then kexec prior to most configuration steps by the installer now running on the installed kernel instead of the installation kernel. -- No Jesus - No peace , Know Jesus - Know Peace Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Nobody is forced. You must be misremembering things. Huh? Plain installing worked without reboot? Did not notice that last weekend with f11 i386 dvd. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm %defattr question
On Monday 13 July 2009, Jussi Lehtola wrote: On Mon, 2009-07-13 at 22:07 +0300, Ville Skyttä wrote: On Sunday 12 July 2009, Jussi Lehtola wrote: is the default attribute definition %defattr(-,root,root) the same as %defattr(-,root,root,-)? Currently yes, the latter is just more explicit. .. and is this going to change at some stage? Your guess is as good as mine, but I don't know why it would need to change. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On Tue, 2009-07-14 at 09:05 -0400, Tom spot Callaway wrote: On 07/14/2009 08:48 AM, Jussi Lehtola wrote: %dist should be used always. As the person who invented %dist, I can assure you, this is false. In the specific situation where a new noarch package with relatively static content is being introduced, you have a few options: * Use %dist * Manually ensure that the upgrade ordering is sane (e.g. foo-1.2.3-1 (fc10), foo-1.2.3-2 (fc11), foo-1.2.3-3 (rawhide) * Only build in rawhide and let inheritance pull it in for future releases (doesn't work for past releases). Admittedly, I think using %dist is easier/saner, but it isn't mandatory. ~spot In F11 Everything, there are 211 i386 packages without the dist tag and just 81 noarch packages without the dist tag. So, it's definitely not just the noarch packages that aren't using the dist tag. Personally, I think that the dist tag usage should be strongly encouraged for all packages. It makes rebuilds and upgrade easier and the only potential downside is a small cosmetic one. Cheers -- Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Martin Sourada wrote:
On Tue, 2009-07-14 at 02:04 -0600, Douglas McClendon wrote:
Fedorans,
Can you spare 50 or 100K? If you can spare 100K/700M in the forthcoming
Fedora-12 LiveCD, I can provide you with a rebootless installation
experience.
http://fedoraproject.org/wiki/Features/RebootlessInstaller
The short story is that you boot the LiveCD/USB, run the installation,
and then, instead of rebooting into the installed OS, you are already
looking at and using it.
snip
Hi Doug,
I think this is an interesting idea and I don't see why you it should
not be done (if you are willing to do the work). It would also IMHO be a
cool killing feature (from marketing POV) ;-) My idea of how this would
be implemented best is:
Hi Martin, thanks for the great feedback. As you can see from the
project page, I already have a simple/experimental implementation, which
I would like to get accepted more or less as is, perhaps prioritizing
more on functionality for F12 than features. But you brought up some
good ideas...
1. do the installation
2. on the last page instead of plain thank you for installing and
exit (I don't recall what exactly is on the last anaconda page) would
be thank you for installing and start using the installed system
now, continue using {Desktop, KDE, ...} Live and reboot buttons.
That is more or less what I have, or rather, I have a big text widget
with the simplest line of text currently. The text for the intro and
final pages, and other places, I definitely expect to hone based on
feedback like yours. After the feature is accepted, and even before,
I'll gladly accept patches :)
If you pushed the start using the installed system now you'd start
using the system from hdd and the live CD/DVD would be ejected. Also it
would be probably good idea to pop-up a notification icon that suggests
reboot (like package-kit does for e.g. kernel updates).
How about a mention in the intro or success page that mentions the
minimal root-on-lvm performance hit until the next reboot. Other than
that, there is no reason to suggest the reboot. Or rather, just let
packagekit do what packagekit does, and get an updated kernel, and then
give the suggest like normal, for the normal reason?
If you pushed the continue using {Desktop, KDE, ...} Live it would
just quit the installer and suggest reboot in a similar case as before.
If you pushed the reboot one it would quit the installer and forced a
reboot (and perhaps prompted the user to save their work).
Adding an optional reboot button to the success page is certainly a
reasonable idea, fairly trivial to add.
Of course it could be made into radiobuttons instead of buttons with
just one Finish or whatever button.
The default would stay continue using {Desktop, KDE, ...} Live.
This would of course work only for Live Spins, I don't see any reason to
try to push this to the standard DVD or network installs.
I agree, this is definitely a 'LiveOS' thing.
Also you'd need to properly handle firstboot in this case, which would
be bypassed. Me thinks firstboot should be purged anyway, but it still
exists and you need to be aware of it.
There really isn't that much there these days anyway. See my reply to
Colin for a discussion of that.
Thanks again for good design ideas,
peace...
-dmc
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On 07/14/2009 07:46 PM, Christoph Höger wrote: Nobody is forced. You must be misremembering things. Huh? Plain installing worked without reboot? Did not notice that last weekend with f11 i386 dvd. Live CD installation. You aren't forced to do a reboot. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On 07/14/2009 08:08 PM, Christoph Wickert wrote: Am Dienstag, den 14.07.2009, 19:05 +0530 schrieb Rahul Sundaram: On 07/14/2009 07:02 PM, Christoph Höger wrote: Hi, although (as others pointed out) a reboot may be necessary one way or the other, my opinion would be: Why not? Currently you are *forced* to reboot which now seems not to be a must have. Nobody is forced. You must be misremembering things. Obviously you are the one misremembering things: http://cwickert.fedorapeople.org/temp/anaconda-last-screen.png We are talking about a live cd installation, yes? You can close the installer then. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On Tue, 2009-07-14 at 20:12 +0530, Rahul Sundaram wrote: We are talking about a live cd installation, yes? You can close the installer then. Yes, and reboot in order to be able to use the installed system. The suggested feature is, as I understand it, trying to make this reboot optional, i.e. not necessary. There's no need to play with words like forced reboot. It is clearly not directly forced in the Live install, yet still necessary, so someone actually could consider it forced (indirectly)... Rahul Martin signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Rahul Sundaram wrote: On 07/14/2009 08:08 PM, Christoph Wickert wrote: Am Dienstag, den 14.07.2009, 19:05 +0530 schrieb Rahul Sundaram: On 07/14/2009 07:02 PM, Christoph Höger wrote: Hi, although (as others pointed out) a reboot may be necessary one way or the other, my opinion would be: Why not? Currently you are *forced* to reboot which now seems not to be a must have. Nobody is forced. You must be misremembering things. Obviously you are the one misremembering things: http://cwickert.fedorapeople.org/temp/anaconda-last-screen.png We are talking about a live cd installation, yes? You can close the installer then. Rahul, let's stay on topic and not split semantic hairs. We both know you aren't trying to suggest that there is no significant difference between my rebootless installer and the traditional (anaconda) live installer. But your arguing of this point could be interpreted like that out of context. peace... -dmc -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Paul W. Frields wrote: On Tue, Jul 14, 2009 at 08:09:09AM -0600, Douglas McClendon wrote: Colin Walters wrote: Another thing to keep in mind that immediately post-installation there are going to be updates, which will at a minimum need desktop reset (fast reboot experience), or more likely system restart. I don't exactly get this. I might understand some negligible things. But historically I've often done -normal install, reboot -booted, logged in using everying, then a massive yum update, then I'd wait till it was absolutely convenient to logout of the desktop or reboot In fact, when I felt I needed to do it before my convenience, I generally regarded it as a pretty horrible bug. I thought that preupgrade is supposed to help ease this discomfort. It deals pretty well with combining the base release of the new distro with package updates, and you reboot when you're ready. There's nothing in preupgrade to deal with repartitioning, though, it's purely for an in-place upgrade. Downloading happens in the background, and you reboot when you're ready to run the transaction. May not cover all the cases you're looking at, but worth noting. Yes, I do see how preupgrade does ease that discomfort. The RebootlessInstaller's use-case is only about installations, not upgrades. Though... (envisioning lots of future work that I'm not that interested in doing myself) peace... -dmc -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
We are talking about a live cd installation, yes? You can close the installer then. We were talking about anaconda. And I still don't know a sane (aka no manual chroot) way to go from livecd into the fresh installed environment. You surely agree that users that know about chroot are probably not the ones adressed with the hey, cool, in this linux thingy i do not need to reboot after install feature, don't you? signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On 07/14/2009 08:23 PM, Christoph Höger wrote: We are talking about a live cd installation, yes? You can close the installer then. We were talking about anaconda. And I still don't know a sane (aka no manual chroot) way to go from livecd into the fresh installed environment. You surely agree that users that know about chroot are probably not the ones adressed with the hey, cool, in this linux thingy i do not need to reboot after install feature, don't you? I never suggested otherwise but my point is simply that describing the current experience as being forced to reboot doesn't sound appropriate. You are free to continue working on the live environment post installation unlike in regular installations. That is a significant difference, IMO. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Christoph Höger wrote: We are talking about a live cd installation, yes? You can close the installer then. We were talking about anaconda. And I still don't know a sane (aka no manual chroot) way to go from livecd into the fresh installed environment. If you look at the feature page and watch 18 minutes of youtube videos, and/or look at my code, I think you'll have to admit there is 'a way' to do it. I certainly won't be offended by the label 'insane' however, unless of course you find technical problems with my implementation, in which case, I still won't mind the label, I'll just go fix em. You surely agree that users that know about chroot are probably not the ones adressed with the hey, cool, in this linux thingy i do not need to reboot after install feature, don't you? Given that I'm precisely the kind of person who is comfortable doing the chroot dance, and I get the most joy from using my installer, I'd have to biasedly suggest that it is for everyone who thinks its kindof cool. peace... -dmc -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Rahul Sundaram wrote: On 07/14/2009 08:23 PM, Christoph Höger wrote: We are talking about a live cd installation, yes? You can close the installer then. We were talking about anaconda. And I still don't know a sane (aka no manual chroot) way to go from livecd into the fresh installed environment. You surely agree that users that know about chroot are probably not the ones adressed with the hey, cool, in this linux thingy i do not need to reboot after install feature, don't you? I never suggested otherwise but my point is simply that describing the current experience as being forced to reboot doesn't sound appropriate. You are free to continue working on the live environment post installation unlike in regular installations. That is a significant difference, IMO. I agree that is a significant already existing benefit of Fedora's LiveOS. I would just hope you would agree that the leap to not having to deal with the chroot, and just being 'already in your installed system' is as significant a difference as well. peace... -dmc -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Am Dienstag, den 14.07.2009, 08:09 -0600 schrieb Douglas McClendon: Colin Walters wrote: Another thing to keep in mind that immediately post-installation there are going to be updates, which will at a minimum need desktop reset (fast reboot experience), or more likely system restart. I don't exactly get this. I might understand some negligible things. But historically I've often done -normal install, reboot -booted, logged in using everying, then a massive yum update, then I'd wait till it was absolutely convenient to logout of the desktop or reboot You wouldn't need no yum update if you enabled the updates repo during install. It's a single click. Your proposal sounds interesting, but I have two questions/issues: 1. The installation is not finished after reboot because we have firstboot. How to trigger firstboot in a rebootless install? 2. Imagine after the installation you switch rebootless to the new system and install a kmod. But you are still running the kernel from the installation medium and kmods get installed for the running kernel, which not necessarily needs to be the one that was installed. Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On Tue, 14 Jul 2009 16:54:26 +0300, Jussi wrote: On Tue, 2009-07-14 at 15:37 +0200, Michael Schwendt wrote: %dist should be used always. No. Particulary for noarch data packages, using %dist bears an additional risk. Because it becomes possible to tag a package on multiple branches and break inheritance by building for more than the oldest branch. So, how do you do it without the %dist branch? AFAIK then you have to manually make sure that the EVR in F(N) is greater than that in F(N-1). Is it a problem? I don't think so. Even _with_ %dist there are pitfalls. Say I've built foo-1-1 in rawhide a year ago and thus the package is available now in F-10 and F-11. How do I update to foo-2-1 in both distros? Whether with %dist or not, doesn't make a difference. You commit the upgrade to the branch that previously targeted rawhide. F-10 in your example. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Christoph Wickert wrote: Am Dienstag, den 14.07.2009, 08:09 -0600 schrieb Douglas McClendon: Colin Walters wrote: Another thing to keep in mind that immediately post-installation there are going to be updates, which will at a minimum need desktop reset (fast reboot experience), or more likely system restart. I don't exactly get this. I might understand some negligible things. But historically I've often done -normal install, reboot -booted, logged in using everying, then a massive yum update, then I'd wait till it was absolutely convenient to logout of the desktop or reboot You wouldn't need no yum update if you enabled the updates repo during install. It's a single click. I don't know this off the top of my head, but I think I can say with some certainty- either that isn't possible with the current LiveOS installer, or if it is, the same thing is a trivial addition to mine. I.e. in the context of my rebootless installer, it is literally just a checkbox which spawns a yum update, or pokes packagekit to do the same. Your proposal sounds interesting, but I have two questions/issues: 1. The installation is not finished after reboot because we have firstboot. How to trigger firstboot in a rebootless install? firstboot really just isn't that much. It is all stuff that can be done just as easily in the running system. But as mentioned in response to Colin, integrating parts of that in the RebootlessInstaller are already in the ROADMAP. But I don't think that that level of feature parity with existing installations should be required for feature acceptance in f12 (given 'experimental' tagging of the feature). 2. Imagine after the installation you switch rebootless to the new system and install a kmod. But you are still running the kernel from the installation medium and kmods get installed for the running kernel, which not necessarily needs to be the one that was installed. As with a current LiveOS installation, the installation media kernel is the running kernel. (unless the f11 installer already allows you to trigger a chrooted yum update as part of install). So yes, if there is a kernel update available - and I'll grant, it is the rule for installations and not the exception - you will need to reboot to switch to that kernel (at least until the whole ksplice technology rolls into town...) peace... -dmc -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Problem with ruby package with binary content...
This question is related to:
https://bugzilla.redhat.com/show_bug.cgi?id=3D505589
When I remove the strip line, then the build process fails with the
complaint:
Found
'/home/mcpierce/Packaging/rpms/BUILDROOT/rubygem-RedCloth-4.1.9-5.fc12.x86_=
64'
in installed files; aborting
I'm not sure what's wrong here. The %install portion of my spec file is
as follows:
---8[snip]---
rm -rf %{buildroot}
install -d -m0755 %{buildroot}%{gemdir}
install -d -m0755 %{buildroot}%{ruby_sitelib}
install -d -m0755 %{buildroot}%{ruby_sitearch}
install -d -m0755 %{buildroot}%{_bindir}
gem install --local --install-dir %{buildroot}%{gemdir} \
--force -V --rdoc %{SOURCE0}
cp -a %{buildroot}%{gemdir}/bin/* %{buildroot}%{_bindir}
mv %{extensionddir}%{gemlibname}
%{buildroot}%{ruby_sitearch}/%{gemlibname}
rm -rf %{extensionddir}
# strip %{buildroot}%{ruby_sitearch}/%{gemlibname}
rm %{installroot}/lib/%{gemlibname}
cp %{installroot}/lib/redcloth.rb
%{buildroot}%{ruby_sitelib}/redcloth.rb
rm -rf %{buildroot}%{gemdir}/bin
find %{buildroot}%{geminstdir}/bin -type f | xargs chmod a+x
find %{buildroot}%{geminstdir} -name *.rb | xargs chmod a+x
find %{buildroot}%{geminstdir} -type f -name \*.rb | xargs chmod 0644
find %{buildroot}%{geminstdir} -type f -name \*.rb | \
xargs grep -l ^#!%{_bindir}/env $file | xargs chmod 0755
rm %{installroot}/.require_paths
---8[snip]---
Any ideas?
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Virtual Machine Management - http://www.ovirt.org/
Is fearr Gaeilge bhriste ná Béarla cliste.
pgpirAOjSvyXv.pgp
Description: PGP signature
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Am Dienstag, den 14.07.2009, 20:12 +0530 schrieb Rahul Sundaram: On 07/14/2009 08:08 PM, Christoph Wickert wrote: Am Dienstag, den 14.07.2009, 19:05 +0530 schrieb Rahul Sundaram: On 07/14/2009 07:02 PM, Christoph Höger wrote: Hi, although (as others pointed out) a reboot may be necessary one way or the other, my opinion would be: Why not? Currently you are *forced* to reboot which now seems not to be a must have. Nobody is forced. You must be misremembering things. Obviously you are the one misremembering things: http://cwickert.fedorapeople.org/temp/anaconda-last-screen.png We are talking about a live cd installation, yes? Are we? If I understand the proposal correctly it also includes rebootless switching from the installation DVD into your newly installed system. You can close the installer then. But why would I want that? If somebody installs Fedora, I'm sure he wants to actually use it and not the slow livecd. So the rebootless feature only makes sense if one can switch rebootless to the installed system - from the livecd as well as from the installation DVD. Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Douglas McClendon wrote: Christoph Wickert wrote: Am Dienstag, den 14.07.2009, 08:09 -0600 schrieb Douglas McClendon: 2. Imagine after the installation you switch rebootless to the new system and install a kmod. But you are still running the kernel from the installation medium and kmods get installed for the running kernel, which not necessarily needs to be the one that was installed. As with a current LiveOS installation, the installation media kernel is the running kernel. (unless the f11 installer already allows you to trigger a chrooted yum update as part of install). Ok, I'll show my good fedora developer maturity and call it a 'night' now that I'm starting to get sloppy. That should have been worded- As with a current LiveOS installation, the installation media kernel is the running kernel. Even if the f11 installer already allows you to trigger a chrooted yum update as part of the install, you won't be running the updated kernel until after a reboot. ... Same as RebootlessInstaller ... until ksplice ... Thanks everyone for the vetting so far. I'm sure by the time I check back in, I'll have a lot of catching up to do, but that my installer will be all the better in the long run for it. peace... -dmc -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Christoph Wickert wrote: Am Dienstag, den 14.07.2009, 20:12 +0530 schrieb Rahul Sundaram: On 07/14/2009 08:08 PM, Christoph Wickert wrote: Am Dienstag, den 14.07.2009, 19:05 +0530 schrieb Rahul Sundaram: On 07/14/2009 07:02 PM, Christoph Höger wrote: Hi, although (as others pointed out) a reboot may be necessary one way or the other, my opinion would be: Why not? Currently you are *forced* to reboot which now seems not to be a must have. Nobody is forced. You must be misremembering things. Obviously you are the one misremembering things: http://cwickert.fedorapeople.org/temp/anaconda-last-screen.png We are talking about a live cd installation, yes? Are we? If I understand the proposal correctly it also includes rebootless switching from the installation DVD into your newly installed system. Ok, one more simple reply- No, this is *just* a LiveOS thing, that has nothing to do with the traditional^2 (non-live) DVD installer. Though one could of course imagine architecting something like that, but that _would_ boil down to more or less the same thing as opensuse appears to be doing with kexec. peace and g'nite... -dmc You can close the installer then. But why would I want that? If somebody installs Fedora, I'm sure he wants to actually use it and not the slow livecd. So the rebootless feature only makes sense if one can switch rebootless to the installed system - from the livecd as well as from the installation DVD. Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On 07/14/2009 08:53 PM, Christoph Wickert wrote: Are we? If I understand the proposal correctly it also includes rebootless switching from the installation DVD into your newly installed system. You might want to read the proposal again. It specifically talks about only Live installation. http://fedoraproject.org/wiki/Features/RebootlessInstaller There is nothing in it about a regular installation. You can close the installer then. But why would I want that? If somebody installs Fedora, I'm sure he wants to actually use it and not the slow livecd. I have continued using the Live CD after a installation because it is sometimes convenient to do so. It is not slow since I usually use a Live USB. The flexibility is quite useful. It would be wonderful to get the rebootless feature added as well. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads UP - PHP 5.3.0 in rawhide with new ABI/API.
Le 13/07/2009 18:51, Remi Collet a écrit : More extension package rebuild: syckhttps://bugzilla.redhat.com/show_bug.cgi?id=511018 cups-php https://bugzilla.redhat.com/show_bug.cgi?id=511106 add PHP ABI check use php_extdir add php configuration file (/etc/php.d/cups.ini) php-suhosin uuid-php https://bugzilla.redhat.com/show_bug.cgi?id=55 add PHP ABI check use php_extdir add php configuration file (/etc/php.d/uuid.ini) syckhttps://bugzilla.redhat.com/show_bug.cgi?id=511018 php-pear-Net-DNS remove php-mhash dependency php-pear-Crypt-CHAP remove php-mhash dependency php-pear-Auth-RADIUS remove php-mhash dependency *** Still Broken sipwitch-php-swig https://bugzilla.redhat.com/show_bug.cgi?id=511123 php-eaccelerator (upstream working on it) https://bugzilla.redhat.com/show_bug.cgi?id=511127 All broken deps fixed, I think / hope Remi -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: epel-release in Fedora repos? (was: Re: NVR bugs in rawhide)
On Tue, 14 Jul 2009 17:29:33 +0300, Ville wrote: On Tuesday 14 July 2009, Daniel Mach wrote: epel-release-6-2.src.rpm Why is the epel-release package shipped in Fedora repos? Because it comes with a valid devel tree in cvs and apparently was (re)built by releng automatically. devel is for Fedora. That tree ought to have been deleted after importing the pkg for EPEL. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Am Dienstag, den 14.07.2009, 09:00 -0600 schrieb Douglas McClendon: Christoph Höger wrote: We are talking about a live cd installation, yes? You can close the installer then. We were talking about anaconda. And I still don't know a sane (aka no manual chroot) way to go from livecd into the fresh installed environment. If you look at the feature page and watch 18 minutes of youtube videos, and/or look at my code, I think you'll have to admit there is 'a way' to do it. I certainly won't be offended by the label 'insane' however, unless of course you find technical problems with my implementation, in which case, I still won't mind the label, I'll just go fix em. That was, of course, meant: Except for feature proposals discussed here ;) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
Am Dienstag, den 14.07.2009, 09:27 -0600 schrieb Douglas McClendon: Douglas McClendon wrote: Christoph Wickert wrote: Am Dienstag, den 14.07.2009, 08:09 -0600 schrieb Douglas McClendon: 2. Imagine after the installation you switch rebootless to the new system and install a kmod. But you are still running the kernel from the installation medium and kmods get installed for the running kernel, which not necessarily needs to be the one that was installed. As with a current LiveOS installation, the installation media kernel is the running kernel. (unless the f11 installer already allows you to trigger a chrooted yum update as part of install). Ok, I'll show my good fedora developer maturity and call it a 'night' now that I'm starting to get sloppy. That should have been worded- As with a current LiveOS installation, the installation media kernel is the running kernel. Even if the f11 installer already allows you to trigger a chrooted yum update as part of the install, you won't be running the updated kernel until after a reboot. There is no chrooted yum update but the updated packages get installed *instead* of the old ones from the installation media. ... Same as RebootlessInstaller ... until ksplice ... Thanks everyone for the vetting so far. Thanks a lot for the proposal and the work you've put into it. I'm sure we all are interested in it, but many of use are just a little skeptical if it really works out. Please don't let this skepticism scare you. :) Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: readline update?
On Tue, Jul 07, 2009 at 03:24:30PM +0200, Miroslav Lichvar wrote: Review requst for compat-readline5: https://bugzilla.redhat.com/show_bug.cgi?id=510022 After the package is accepted, I'll start patching the packages (except gnu-smalltalk and kdeedu) to build correctly with the compat package. It turned out that I can no longer commit to other packages, so I'll file bugs with patches instead. However, it seems that more of the packages I posted in the original mail are not GPLv2. calc (can be relicensed to GPLv3?) cgdb (GPLv2+?) gnubg (GPLv3?) grass (GPLv2+?) gnuplot (not compatible with any GPL?) ktechlab (GPLv2+?) Can someone confirm this? Thanks, -- Miroslav Lichvar -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On Tue, Jul 14, 2009 at 09:27:08AM -0600, Douglas McClendon wrote: As with a current LiveOS installation, the installation media kernel is the running kernel. Even if the f11 installer already allows you to trigger a chrooted yum update as part of the install, you won't be running the updated kernel until after a reboot. Is it the case that the installation kernel is always UP, whereas the real kernel would probably be SMP nowadays? ... Same as RebootlessInstaller ... until ksplice ... I don't think ksplice changes things -- it seems to only work for very minor kernel patches. For example, any change to the layout of a kernel structure would appear to be incompatible with ksplice. Thus it seems highly unlikely it'll ever work in its current form for arbitrary kernel revisions. quote Before you use ksplice-create on a patch, you should confirm that the desired source code change does not make any semantic changes to kernel data structures--that is, changes that would require existing instances of kernel data structures to be transformed (e.g., a patch that adds a field to a global data structure would require the existing data structures to change). If you use Ksplice on a patch that changes data structure semantics, Ksplice will not detect the problem and you could experience kernel problems as a result. /quote from: http://www.ksplice.com/doc/ksplice-create Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
Michael Schwendt wrote: On Tue, 14 Jul 2009 16:01:50 +0200, Ralf wrote: You don't need to drop %dist for koji build inheritance to work. It just looks much cleaner to inherit foo-1.0-1.noarch.rpm for all newer targets IFF current rpm is sufficiently compatible to the antique version of rpm a package has been built on. If this doesn't apply you don't get anywhere. Not _with_ %dist either. Of cause it would help. A package's release tag would very verbosely tell you that a package is outdated. No. Particulary for noarch data packages, using %dist bears an additional risk. Because it becomes possible to tag a package on multiple branches and break inheritance by building for more than the oldest branch. To me, this is not a risk, but a valuable feature. The packager is free to decide whether and when to do this either with or without %dist. Yes, that's the status quo, probably because certain Fedora and Red Hat key people refuse to keep things simple and straight, but prefer to what I consider to be outsmarting themselves by making the corner cases the norm. IMO, that's simply silly of these people. = I agree with Jussi. Allowing people not to use %dist is not helpful. It's a booby trap which certainly will hit some day. %dist is a trap itself - packagers run into it regularly, e.g. when adding Obsoletes and versioned dependencies, when doing trial-and-error fixing of old branches (without paying attention to the recommendations in the guidelines), when committing and tagging after a server-side update of the branches file. Quite easy to overcome: always use %?dist. It's the cases when people add/remove %?dist, which are problematic. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: beagle
On 07/14/2009 04:16 AM, Michael Schwendt wrote: On Thu, 25 Jun 2009 11:48:33 +0200, Michael wrote: * Delivery to the following recipient failed permanently: beagle-owner AT fedoraproject DOT org Recipient address rejected: User unknown in local recipient table (state 14). * https://admin.fedoraproject.org/pkgdb/packages/name shows more than a dozen people on watchcommit+commit, but no package owner. It's an orphan. * https://admin.fedoraproject.org/pkgdb/packages/bugs shows more than a dozen open tickets, but nobody is subscribed to watchbugzilla. * yum list beagle shows beagle-0.3.9-6.fc11 in fedora. There is still no beagle-owner for this package. So, it looks like the desktop team isn't interested in picking up beagle (and they're most of the people in the commit/watchcommit) for the package. If no one else is willing to take ownership, I think we should block the package for rawhide and list it as retired for not having someone interested in working on it. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: beagle
On Tue, Jul 14, 2009 at 6:02 PM, Toshio Kuratomia.bad...@gmail.com wrote: On 07/14/2009 04:16 AM, Michael Schwendt wrote: On Thu, 25 Jun 2009 11:48:33 +0200, Michael wrote: * Delivery to the following recipient failed permanently: beagle-owner AT fedoraproject DOT org Recipient address rejected: User unknown in local recipient table (state 14). * https://admin.fedoraproject.org/pkgdb/packages/name shows more than a dozen people on watchcommit+commit, but no package owner. It's an orphan. * https://admin.fedoraproject.org/pkgdb/packages/bugs shows more than a dozen open tickets, but nobody is subscribed to watchbugzilla. * yum list beagle shows beagle-0.3.9-6.fc11 in fedora. There is still no beagle-owner for this package. So, it looks like the desktop team isn't interested in picking up beagle (and they're most of the people in the commit/watchcommit) for the package. If no one else is willing to take ownership, I think we should block the package for rawhide and list it as retired for not having someone interested in working on it. It does not even build on rawhide right now (epiphany related breakage). I dropped it due to lack of time (which is worse rather than better now) but nobody responded to my mail where I was searching for a new maintainer. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On Tue, 14 Jul 2009 17:54:10 +0200, Ralf wrote: Michael Schwendt wrote: On Tue, 14 Jul 2009 16:01:50 +0200, Ralf wrote: You don't need to drop %dist for koji build inheritance to work. It just looks much cleaner to inherit foo-1.0-1.noarch.rpm for all newer targets IFF current rpm is sufficiently compatible to the antique version of rpm a package has been built on. If this doesn't apply you don't get anywhere. Not _with_ %dist either. Of cause it would help. A package's release tag would very verbosely tell you that a package is outdated. And still it would fail if RPM were changed [the way you describe] while %dist stayed the same. %dist doesn't reflect at all whether RPM changes its file format near the beginning of a Fedora devel cycle. = I agree with Jussi. Allowing people not to use %dist is not helpful. It's a booby trap which certainly will hit some day. %dist is a trap itself - packagers run into it regularly, e.g. when adding Obsoletes and versioned dependencies, when doing trial-and-error fixing of old branches (without paying attention to the recommendations in the guidelines), when committing and tagging after a server-side update of the branches file. Quite easy to overcome: always use %?dist. Doesn't help much. Packager still needs to bump all branches [correctly] to recover. It's the cases when people add/remove %?dist, which are problematic. Going in circles won't be of any use in this thread. Using %dist adds complications, too. Or else packagers would not run into some of the pitfalls I've pointed out. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On Tue, 2009-07-14 at 17:23 +0200, Michael Schwendt wrote: Say I've built foo-1-1 in rawhide a year ago and thus the package is available now in F-10 and F-11. How do I update to foo-2-1 in both distros? Whether with %dist or not, doesn't make a difference. You commit the upgrade to the branch that previously targeted rawhide. F-10 in your example. And it automatically ends up in F-11? I can't tag and build for F-11 if the tag with same EVR already exists in F-10. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: beagle
On Tue, Jul 14, 2009 at 11:07 AM, drago01 drag...@gmail.com wrote: On Tue, Jul 14, 2009 at 6:02 PM, Toshio Kuratomia.bad...@gmail.com wrote: On 07/14/2009 04:16 AM, Michael Schwendt wrote: On Thu, 25 Jun 2009 11:48:33 +0200, Michael wrote: * Delivery to the following recipient failed permanently: beagle-owner AT fedoraproject DOT org Recipient address rejected: User unknown in local recipient table (state 14). * https://admin.fedoraproject.org/pkgdb/packages/name shows more than a dozen people on watchcommit+commit, but no package owner. It's an orphan. * https://admin.fedoraproject.org/pkgdb/packages/bugs shows more than a dozen open tickets, but nobody is subscribed to watchbugzilla. * yum list beagle shows beagle-0.3.9-6.fc11 in fedora. There is still no beagle-owner for this package. So, it looks like the desktop team isn't interested in picking up beagle (and they're most of the people in the commit/watchcommit) for the package. If no one else is willing to take ownership, I think we should block the package for rawhide and list it as retired for not having someone interested in working on it. It does not even build on rawhide right now (epiphany related breakage). I dropped it due to lack of time (which is worse rather than better now) but nobody responded to my mail where I was searching for a new maintainer. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list As a beagle user, I'd like to help co-maintain it (Or maintain it if noone else is interested), What would I have to do? -- Ing. Juan M. Rodriguez Moreno Desarrollador de Sistemas Abiertos Sitio: http://proyectofedora.org/mexico -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: beagle
On Tue, Jul 14, 2009 at 6:09 PM, Juan Rodrigueznus...@fedoraproject.org wrote: On Tue, Jul 14, 2009 at 11:07 AM, drago01 drag...@gmail.com wrote: On Tue, Jul 14, 2009 at 6:02 PM, Toshio Kuratomia.bad...@gmail.com wrote: On 07/14/2009 04:16 AM, Michael Schwendt wrote: On Thu, 25 Jun 2009 11:48:33 +0200, Michael wrote: * Delivery to the following recipient failed permanently: beagle-owner AT fedoraproject DOT org Recipient address rejected: User unknown in local recipient table (state 14). * https://admin.fedoraproject.org/pkgdb/packages/name shows more than a dozen people on watchcommit+commit, but no package owner. It's an orphan. * https://admin.fedoraproject.org/pkgdb/packages/bugs shows more than a dozen open tickets, but nobody is subscribed to watchbugzilla. * yum list beagle shows beagle-0.3.9-6.fc11 in fedora. There is still no beagle-owner for this package. So, it looks like the desktop team isn't interested in picking up beagle (and they're most of the people in the commit/watchcommit) for the package. If no one else is willing to take ownership, I think we should block the package for rawhide and list it as retired for not having someone interested in working on it. It does not even build on rawhide right now (epiphany related breakage). I dropped it due to lack of time (which is worse rather than better now) but nobody responded to my mail where I was searching for a new maintainer. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list As a beagle user, I'd like to help co-maintain it (Or maintain it if noone else is interested), What would I have to do? Are you already sponsored? If yes just take it in pkgdb (it is already orphaned) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On Tue, 14 Jul 2009 19:08:49 +0300, Jussi wrote: On Tue, 2009-07-14 at 17:23 +0200, Michael Schwendt wrote: Say I've built foo-1-1 in rawhide a year ago and thus the package is available now in F-10 and F-11. How do I update to foo-2-1 in both distros? Whether with %dist or not, doesn't make a difference. You commit the upgrade to the branch that previously targeted rawhide. F-10 in your example. And it automatically ends up in F-11? With koji inheritance, yes. I can't tag and build for F-11 if the tag with same EVR already exists in F-10. We're not talking about the same thing. Or to put it differently, you want to prove something to me which I don't find relevant in this discussion. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On Tue, 2009-07-14 at 11:19 -0400, Colin Walters wrote: There's no such step in the live install (right?).Now, it would likely make sense to have such a mechanism, but it would need design. I forget offhand too how the PackageKit updater works in the live image (do we disable it by default?). With the Anaconda live installer, it's the raw unmodified live filesystem that is copied to the newly partitioned disk(s). Ergo any rpm updating you do on the LiveOS before you start the installer will be lost. It appears that Doglas' installer uses the in use LiveOS so that the changes you make while running the LiveOS before starting the install will be carried over into the install. That in itself seems interesting enough to explore and see if we can't get the same functionality, to some extent into Anaconda. As for rebootless, that's interesting too. I'm glad you were able to demo the technology within your installer, but I'd worry about the duplication of effort/code to have yet another program that is designed to discover disks, partition them appropriately for an install, copy content, then install a boot loader. There is a lot of logic code in Anaconda to get the partitioning correct for an installation, even if the backend code uses system level libraries and tools to accomplish the partitioning. Ditto boot loaders and kernel setup. If we as a project find rebootless installation useful then we should find a way to integrate it with our existing installer and code set which already carries all the logic necessary to pull it off, from years of experience and bug reports. I think your work is great and useful though! -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Problem with ruby package with binary content...
Darryl L. Pierce wrote, at 07/15/2009 12:23 AM +9:00:
This question is related to:
https://bugzilla.redhat.com/show_bug.cgi?id=505589
When I remove the strip line, then the build process fails with the
complaint:
Found
'/home/mcpierce/Packaging/rpms/BUILDROOT/rubygem-RedCloth-4.1.9-5.fc12.x86_=
64'
in installed files; aborting
I'm not sure what's wrong here. The %install portion of my spec file is
as follows:
---8[snip]---
rm -rf %{buildroot}
install -d -m0755 %{buildroot}%{gemdir}
install -d -m0755 %{buildroot}%{ruby_sitelib}
install -d -m0755 %{buildroot}%{ruby_sitearch}
install -d -m0755 %{buildroot}%{_bindir}
gem install --local --install-dir %{buildroot}%{gemdir} \
--force -V --rdoc %{SOURCE0}
cp -a %{buildroot}%{gemdir}/bin/* %{buildroot}%{_bindir}
mv %{extensionddir}%{gemlibname}
%{buildroot}%{ruby_sitearch}/%{gemlibname}
rm -rf %{extensionddir}
# strip %{buildroot}%{ruby_sitearch}/%{gemlibname}
rm %{installroot}/lib/%{gemlibname}
cp %{installroot}/lib/redcloth.rb
%{buildroot}%{ruby_sitelib}/redcloth.rb
rm -rf %{buildroot}%{gemdir}/bin
find %{buildroot}%{geminstdir}/bin -type f | xargs chmod a+x
find %{buildroot}%{geminstdir} -name *.rb | xargs chmod a+x
find %{buildroot}%{geminstdir} -type f -name \*.rb | xargs chmod 0644
find %{buildroot}%{geminstdir} -type f -name \*.rb | \
xargs grep -l ^#!%{_bindir}/env $file | xargs chmod 0755
rm %{installroot}/.require_paths
---8[snip]---
Any ideas?
This is because with your spec file gem is directly installed under
%buildroot. So some C codes in the gem (usually under ext/ directory)
are compiled under %buildroot and the string %buildroot
is embedded in the built binary (with gcc -g). This will make
/usr/lib/rpm/check-buildroot complain.
The correct way is to expand (install) gem file once under %_builddir
(at %prep or %build) and and copy all (under %_builddir) under
%buildroot at %install like:
---
%prep
%setup -q -c -T
mkdir -p ./%{gemdir}
export CONFIGURE_ARGS=--with-cflags='%{optflags}'
gem install --local --install-dir .%{gemdir} \
--force -V --rdoc %{SOURCE0}
%build
%install
rm -rf %{buildroot}
mkdir -p %{buildroot}%{gemdir}
cp -a .%{gemdir}/* %{buildroot}%{gemdir}
---
With this debuginfo rpm will also be created correctly.
Regards,
Mamoru
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: beagle
On Tue, Jul 14, 2009 at 11:43 AM, drago01 drag...@gmail.com wrote: Juan just took ownership of beagle, so the issue (not having a maintainer) is solved now. However, if anyone wants to co-maintain the package, feel free to do so. :) -- Ing. Juan M. Rodriguez Moreno Desarrollador de Sistemas Abiertos Sitio: http://proyectofedora.org/mexico -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: epel-release in Fedora repos? (was: Re: NVR bugs in rawhide)
On Tue, 2009-07-14 at 17:41 +0200, Michael Schwendt wrote: Because it comes with a valid devel tree in cvs and apparently was (re)built by releng automatically. devel is for Fedora. That tree ought to have been deleted after importing the pkg for EPEL. releng doesn't key off of a devel/ branch alone. The package was somehow added to a Fedora collection in Koji, and thus it showed up as a valid package when I queried Koji for all the packages buildable in dist-f11. The fact that it was added to a Fedora collection in Koji /plus/ it had a real devel/ branch in CVS led to it being built. At 7000+ srpms there is no way I could evaluate each and every one for validity before submitting it for a rebuild. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm %defattr question
On Tue, 2009-07-14 at 17:33 +0300, Ville Skyttä wrote: Your guess is as good as mine, but I don't know why it would need to change. %defattr and %attr appear to use different syntax, as I tried to use the same %defattr syntax for an %attr line and RPM balked. Making them consistent would be nice. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Purging the F12 orphans
It's that time of the release cycle again, to purge the orphans before we get to feature freeze. Any unblocked orphans will be purged by the 28th of this month. Here is a current list of unblocked orphans: Unblocked orphan ant-contrib Unblocked orphan apollon Unblocked orphan azureus Unblocked orphan beagle Unblocked orphan bes Unblocked orphan bmake Unblocked orphan buoh Unblocked orphan cryptix Unblocked orphan ctrlproxy Unblocked orphan dap-freeform_handler Unblocked orphan dap-hdf4_handler Unblocked orphan dap-netcdf_handler Unblocked orphan dap-server Unblocked orphan drapes Unblocked orphan dumpasn1 Unblocked orphan elsa Unblocked orphan f-spot Unblocked orphan fig2ps Unblocked orphan flpsed Unblocked orphan fmit Taking ownership of them on the devel collection will prevent them from being blocked. Remember, it is OK to let software die. Don't view this as a list of things that somebody should pick up if they have the spare time. Things should only be revived if there are actual users in need of the software. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On Tuesday 14 July 2009 11:50:06 Richard W.M. Jones wrote: On Tue, Jul 14, 2009 at 09:27:08AM -0600, Douglas McClendon wrote: As with a current LiveOS installation, the installation media kernel is the running kernel. Even if the f11 installer already allows you to trigger a chrooted yum update as part of the install, you won't be running the updated kernel until after a reboot. Is it the case that the installation kernel is always UP, whereas the real kernel would probably be SMP nowadays? On everything but ppc32, we don't even ship an UP kernel any longer, the base kernel used by the installer *is* an SMP kernel. ... Same as RebootlessInstaller ... until ksplice ... I don't think ksplice changes things -- it seems to only work for very minor kernel patches. For example, any change to the layout of a kernel structure would appear to be incompatible with ksplice. Thus it seems highly unlikely it'll ever work in its current form for arbitrary kernel revisions. Trying to ksplice from 2.6.29.4 in the installer to say 2.6.30.1 or even to 2.6.31 does sound like massive fail... -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: epel-release in Fedora repos?
JK == Jesse Keating jkeat...@redhat.com writes: JK At 7000+ srpms there is no way I could evaluate each and every one JK for validity before submitting it for a rebuild. I think the point is that the package owner should have deleted it from devel so that there would be nothing for rel-eng to rebuild. - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
2009/7/14 Douglas McClendon dmc.fed...@filteredperception.org: Fedorans, Can you spare 50 or 100K? If you can spare 100K/700M in the forthcoming Fedora-12 LiveCD, I can provide you with a rebootless installation experience. http://fedoraproject.org/wiki/Features/RebootlessInstaller peace... -dmc Truly great idea, I can finally bypass anaconda thanks. ...dex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
How to contact Tomáš Bžatek?
Anybody knows how to contact Tomáš Bžatek? Is he still working for Red Hat? I see he has a lot of open bugs (some of them are just getting closed by the bugzappers) without a single comment from him. I set one to NEEDINFO but didn't get a response for months. Already time for AWOL procedure? [1] Regards, Christoph [1] https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How to contact Tomáš Bžatek?
Anybody knows how to contact Tomáš Bžatek? Is he still working for Red Hat? I see he has a lot of open bugs (some of them are just getting closed by the bugzappers) without a single comment from him. I set one to NEEDINFO but didn't get a response for months. You can send mail to tbza...@redhat.com, and wait for him to return from conferences and vacation. He works in Europe, so he actually gets noticable amounts of vacation :-) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Problem with ruby package with binary content...
On Wed, Jul 15, 2009 at 01:44:59AM +0900, Mamoru Tasaka wrote:
This is because with your spec file gem is directly installed under
%buildroot. So some C codes in the gem (usually under ext/ directory)
are compiled under %buildroot and the string %buildroot
is embedded in the built binary (with gcc -g). This will make
/usr/lib/rpm/check-buildroot complain.
The correct way is to expand (install) gem file once under %_builddir
(at %prep or %build) and and copy all (under %_builddir) under
%buildroot at %install like:
---
%prep
%setup -q -c -T
mkdir -p ./%{gemdir}
export CONFIGURE_ARGS=--with-cflags='%{optflags}'
gem install --local --install-dir .%{gemdir} \
--force -V --rdoc %{SOURCE0}
%build
%install
rm -rf %{buildroot}
mkdir -p %{buildroot}%{gemdir}
cp -a .%{gemdir}/* %{buildroot}%{gemdir}
---
With this debuginfo rpm will also be created correctly.
Awesome, that appears to have worked nicely. Thanks for the input. :)
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Virtual Machine Management - http://www.ovirt.org/
Is fearr Gaeilge bhriste ná Béarla cliste.
pgp60NyBXUR0a.pgp
Description: PGP signature
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: epel-release in Fedora repos? (was: Re: NVR bugs in rawhide)
Package has been marked as dead.package in devel. Ticket filed with rel-eng. stahnma -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Any Ruby Packagers Here?
I don't know ruby. But: http://tinyurl.com/9m4wzr is some ruby stuff to identify snippets of Code. Any ruby knowing people willing to package it? Regards, Frank -- jabber | msn | skype: frankly3d http://www.frankly3d.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How to contact Tomáš Bžatek?
On 14/07/09 18:33, Christoph Wickert wrote: Am Dienstag, den 14.07.2009, 13:26 -0400 schrieb Matthias Clasen: Anybody knows how to contact Tomáš Bžatek? Is he still working for Red Hat? I see he has a lot of open bugs (some of them are just getting closed by the bugzappers) without a single comment from him. I set one to NEEDINFO but didn't get a response for months. You can send mail to tbza...@redhat.com, and wait for him to return from conferences and vacation. He was BCC'ed to my previous message with his rh address, so let's hope he responds soon. He works in Europe, so he actually gets noticable amounts of vacation :-) You can put your mind at rest, even in Europe we don't have a year of vacation. ;) Thanks, Christoph Unless a politician :D Regards, Frank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm %defattr question
On Tuesday 14 July 2009, Jesse Keating wrote: On Tue, 2009-07-14 at 17:33 +0300, Ville Skyttä wrote: Your guess is as good as mine, but I don't know why it would need to change. %defattr and %attr appear to use different syntax, as I tried to use the same %defattr syntax for an %attr line and RPM balked. Making them consistent would be nice. I don't think consistency is necessarily a very good thing here because as you noticed, %defattr and %attr are different. Somewhat simplified; %defattr specifies default ownership and _optionally different modes_ for files and dirs for stuff on lines after it in %files, while %attr specifies the _same mode_ and ownership for all the stuff following it on the same line in %files, regardless if the stuff is dirs or files. The same/different modes difference is most important with %files entries that recurse and match both files and dirs. %defattr(mode-for-non-dirs,user,group[,mode-for-dirs]) %attr(mode-for-everything-on-this-line,user,group) /some/thing -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Purging the F12 orphans
On 07/14/2009 12:40 PM, Jesse Keating wrote: It's that time of the release cycle again, to purge the orphans before we get to feature freeze. Any unblocked orphans will be purged by the 28th of this month. Here is a current list of unblocked orphans: Thinkfinger should probably also be blocked; I abandoned it during F11 development and has been replaced by fprint. -Doug signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Rebootless Installer
On 07/14/2009 11:04 AM, Christoph Wickert wrote: 2. Imagine after the installation you switch rebootless to the new system and install a kmod. But you are still running the kernel from the installation medium and kmods get installed for the running kernel, which not necessarily needs to be the one that was installed. Would it be feasible to fetch the current kernel from the 'net (if possible/permitted) and kexec into it before proceeding with the install? With liveUSB there's persistence, but is there a way to have a ramdisk survive kexec for liveCD? Heck, fetch the latest anaconda too, and get rid of some of the zero-day problems we have that require respins now. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On Tue, 2009-07-14 at 18:39 +0200, Michael Schwendt wrote:
On Tue, 14 Jul 2009 19:08:49 +0300, Jussi wrote:
On Tue, 2009-07-14 at 17:23 +0200, Michael Schwendt wrote:
Say I've built foo-1-1 in rawhide a year ago and thus the package is
available now in F-10 and F-11. How do I update to foo-2-1 in both
distros?
Whether with %dist or not, doesn't make a difference. You commit the
upgrade to the branch that previously targeted rawhide. F-10 in your
example.
And it automatically ends up in F-11?
With koji inheritance, yes.
I can't tag and build for F-11 if
the tag with same EVR already exists in F-10.
We're not talking about the same thing. Or to put it differently, you want
to prove something to me which I don't find relevant in this discussion.
I just don't understand the build system well enough yet to know how
this works. I agree that for packages that only contain stuff that is
going to be the same on every architecture and distribution (such as
packages consisting of PDF files) not using the %{?dist} tag is sane.
The question about rpm internals changing is related to this, but is a
separate issue. IMHO one should be able to tagbuild noarch packages for
multiple distributions at once to cope with the changes in rpm.
However, packages that are compiled in some way *really should* use the
%{?dist} tag, since that way they are upgraded when the distribution is
upgraded. (Or it can be easily seen that the compilation is obsolete.)
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Purging the F12 orphans
On Tue, Jul 14, 2009 at 6:27 PM, Jerry Jamesloganje...@gmail.com wrote: On Tue, Jul 14, 2009 at 10:40 AM, Jesse Keating jkeat...@redhat.com wrote: Unblocked orphan ant-contrib Unblocked orphan apollon Unblocked orphan azureus Unblocked orphan beagle Unblocked orphan bes Unblocked orphan bmake Unblocked orphan buoh Unblocked orphan cryptix Unblocked orphan ctrlproxy Unblocked orphan dap-freeform_handler Unblocked orphan dap-hdf4_handler Unblocked orphan dap-netcdf_handler Unblocked orphan dap-server Unblocked orphan drapes Unblocked orphan dumpasn1 Unblocked orphan elsa Unblocked orphan f-spot Unblocked orphan fig2ps Unblocked orphan flpsed Unblocked orphan fmit Are there really none that start with g-z, or did something quit after fmit? No specfile was ever booked into CVS for fmit... What a waste of time! -- Mat Booth A: Because it destroys the order of the conversation. Q: Why shouldn't you do it? A: Posting your reply above the original message. Q: What is top-posting? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Purging the F12 orphans
On Tue, 2009-07-14 at 09:40 -0700, Jesse Keating wrote: It's that time of the release cycle again, to purge the orphans before we get to feature freeze. Any unblocked orphans will be purged by the 28th of this month. Here is a current list of unblocked orphans: The first list was incomplete due to an API change. Here is the complete list: Unblocked orphan ant-contrib Unblocked orphan apollon Unblocked orphan azureus Unblocked orphan bes Unblocked orphan bmake Unblocked orphan buoh Unblocked orphan cryptix Unblocked orphan ctrlproxy Unblocked orphan dap-freeform_handler Unblocked orphan dap-hdf4_handler Unblocked orphan dap-netcdf_handler Unblocked orphan dap-server Unblocked orphan drapes Unblocked orphan dumpasn1 Unblocked orphan elsa Unblocked orphan fig2ps Unblocked orphan flpsed Unblocked orphan fmit Unblocked orphan fontypython Unblocked orphan galago-daemon Unblocked orphan galago-filesystem Unblocked orphan gconf-cleaner Unblocked orphan gdhcpd Unblocked orphan gfa Unblocked orphan gift Unblocked orphan gift-gnutella Unblocked orphan gift-openft Unblocked orphan gimp-lqr-plugin Unblocked orphan glipper Unblocked orphan gnochm Unblocked orphan gnome-audio Unblocked orphan gnome-compiz-manager Unblocked orphan gnome-specimen Unblocked orphan gnome-vfs2-obexftp Unblocked orphan gnubiff Unblocked orphan gstm Unblocked orphan gtk-murrine-engine Unblocked orphan gtkperf Unblocked orphan ht2html Unblocked orphan httpunit Unblocked orphan id3v2 Unblocked orphan jakarta-commons-codec Unblocked orphan jakarta-commons-digester Unblocked orphan jakarta-commons-launcher Unblocked orphan jakarta-commons-modeler Unblocked orphan jakarta-taglibs-standard Unblocked orphan javacc Unblocked orphan jdepend Unblocked orphan jflex Unblocked orphan jrexx Unblocked orphan js Unblocked orphan junitperf Unblocked orphan klear Unblocked orphan ldapvi Unblocked orphan libatomic_ops Unblocked orphan libchmxx Unblocked orphan libdap Unblocked orphan libdockapp Unblocked orphan libgtksourceviewmm Unblocked orphan liblqr-1 Unblocked orphan libnc-dap Unblocked orphan libreadline-java Unblocked orphan macchanger Unblocked orphan metamonitor Unblocked orphan mftrace Unblocked orphan mk-files Unblocked orphan msv Unblocked orphan musicbox Unblocked orphan nekohtml Unblocked orphan notecase Unblocked orphan otl Unblocked orphan pam_keyring Unblocked orphan pcmanx-gtk2 Unblocked orphan perl-LWP-Authen-Wsse Unblocked orphan perl-Text-CHM Unblocked orphan pessulus Unblocked orphan piccolo Unblocked orphan pidgin-knotify Unblocked orphan plexus-container-default Unblocked orphan plexus-interactivity Unblocked orphan plexus-velocity Unblocked orphan puretls Unblocked orphan pystatgrab Unblocked orphan python-cjson Unblocked orphan python-dbsprockets Unblocked orphan qdox Unblocked orphan qemu-launcher Unblocked orphan qt-qsa Unblocked orphan quickfix Unblocked orphan ruby-flexmock Unblocked orphan scim-input-pad Unblocked orphan scim-skk Unblocked orphan scim-tomoe Unblocked orphan shapelib Unblocked orphan skkdic Unblocked orphan surfraw Unblocked orphan themes-backgrounds-gnome Unblocked orphan thinkfinger Unblocked orphan tomoe Unblocked orphan tpm-tools Unblocked orphan tremulous-data Unblocked orphan viewmtn Unblocked orphan w3lib Unblocked orphan wdm Unblocked orphan wifi-radar Unblocked orphan wmix Unblocked orphan wxdfast Unblocked orphan xdoclet Unblocked orphan xerces-j2 Unblocked orphan xml-commons-apis Unblocked orphan xml-commons-apis12 Unblocked orphan xml-commons-which Unblocked orphan xmms-cdread Unblocked orphan xyz-gallery -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Problem with ruby package with binary content...
On Tue, Jul 14, 2009 at 01:28:51PM -0400, Darryl L. Pierce wrote: With this debuginfo rpm will also be created correctly. Awesome, that appears to have worked nicely. Thanks for the input. :) Shoot, spoke way too soon. I had reset the spec file to remove where I had been experimenting with some fixes, and didn't remove the strip line. So I ran it with the changes you posted and with the strip line there and it worked. I removed the strip line and a different error came up now. The problem is now with pathing and not finding the .so file. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Virtual Machine Management - http://www.ovirt.org/ Is fearr Gaeilge bhriste ná Béarla cliste. pgpajzTTklrtl.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads UP - PHP 5.3.0 in rawhide with new ABI/API.
Remi Collet wrote: Le 13/07/2009 03:17, Jon Ciesla a écrit : - php-mhash (not maintained) Is it possible to keep this? I have a package that depends on it, and there may be others, though I have not checked. $ repoquery --whatrequires php-mhash php-pear-Net-DNS-0:1.0.0-3.fc11.noarch limph-0:1.9.5-4.fc11.noarch limph-hostagent-0:1.9.5-4.fc11.noarch php-pear-Crypt-CHAP-0:1.0.1-2.fc11.noarch php-pear-Auth-RADIUS-0:1.0.6-2.fc11.noarch If not, is there a replacement, or would you recommend that I construct and submit for review my own package for it? This extension is not maintained, removed from main php and not transferred to PECL. The recommended new hash solution is HASH, see http://fr2.php.net/mhash http://fr2.php.net/hash The other solution is to become upstream for mhash ;) Remi. Thanks, I migrated Limph to hash, which was easy as I'm upstream. Fixed in rawhide. -- in your fear, speak only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Purging the F12 orphans
On Tue, 2009-07-14 at 10:58 -0700, Jesse Keating wrote: On Tue, 2009-07-14 at 09:40 -0700, Jesse Keating wrote: It's that time of the release cycle again, to purge the orphans before we get to feature freeze. Any unblocked orphans will be purged by the 28th of this month. Here is a current list of unblocked orphans: The first list was incomplete due to an API change. Here is the complete list: snip Unblocked orphan gtk-murrine-engine I'm taking over this one. Co-maintainers welcomed. snip Martin signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Purging the F12 orphans
I use azureus, and if it's reasonably popular, I'll happily maintain the package. Is there information on whether or not people actually install these packages? On Tuesday 14 July 2009 12:40:37 pm Jesse Keating wrote: It's that time of the release cycle again, to purge the orphans before we get to feature freeze. Any unblocked orphans will be purged by the 28th of this month. Here is a current list of unblocked orphans: Unblocked orphan ant-contrib Unblocked orphan apollon Unblocked orphan azureus Unblocked orphan beagle Unblocked orphan bes Unblocked orphan bmake Unblocked orphan buoh Unblocked orphan cryptix Unblocked orphan ctrlproxy Unblocked orphan dap-freeform_handler Unblocked orphan dap-hdf4_handler Unblocked orphan dap-netcdf_handler Unblocked orphan dap-server Unblocked orphan drapes Unblocked orphan dumpasn1 Unblocked orphan elsa Unblocked orphan f-spot Unblocked orphan fig2ps Unblocked orphan flpsed Unblocked orphan fmit Taking ownership of them on the devel collection will prevent them from being blocked. Remember, it is OK to let software die. Don't view this as a list of things that somebody should pick up if they have the spare time. Things should only be revived if there are actual users in need of the software. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Orphaning garmin-sync and pyusb
Since I upgraded from the Garmin Edge 305 to the 705, I'm no longer using either of garmin-sync or its dependency pyusb on any sort of regular basis. This is probably less than ideal for adequately maintaining them. If you *have* one of the older Garmin Edge or Forerunner devices, they're easy enough packages to maintain -- upstream is responsive to the one or two things I threw at him and the userbase is not that large. Orphaned in pkgdb for devel -- I'll keep responding to things for F10/F11 unless someone else picks them up to avoid leaving users of existing releases out in the cold Jeremy -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora rawhide rebuild in mock status 2009-07-10 x86_64
Fedora Rawhide-in-Mock Build Results for x86_64 using rawhide as of 10 July 2009. This is a full rebuild of all packages. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ 1 Open Bugs which now build, and can be marked CLOSED RAWHIDE: ruby-rpm: [u'465103'] Total packages: 8004 Number failed to build: 391 Number expected to fail due to ExclusiveArch or ExcludeArch: 32 Leaving: 359 Of those expected to have worked... Without a bug filed: 355 -- 389-ds-base-1.2.1-1.fc12 (build/make) rmeggins,nhosoi,nkinder 389-dsgw-1.1.3-1.fc12 (build/make) rmeggins,nhosoi,nkinder BackupPC-3.1.0-5.fc11 (build/make) trasher CTL-1.4.1-9.fc11 (build/make) kwizart Django-1.0.2-3.fc11 (build/make) salimma,smilner GtkAda-2.10.2-2.fc11 (build/make) gemi Io-language-20071010-10.fc11 (build/make) salimma,salimma Macaulay2-1.2-4.fc12 (build/make) rdieter Perlbal-1.70-3.fc11 (build/make) ruben PyKDE-3.16.3-1.fc12 (build/make) rdieter,jamatos PyQuante-1.6.3-1.fc11 (build/make) jussilehtola PyQwt-5.1.0-3.fc11 (build/make) tadej PyX-0.10-6.fc11 (build/make) jamatos,jamatos,mpeters R-BSgenome.Celegans.UCSC.ce2-1.2.0-5 (build/make) pingou R-BSgenome.Dmelanogaster.FlyBase.r51-1.3.1-3 (build/make) pingou R-RODBC-1.2-2.fc11 (build/make) spot R-RScaLAPACK-0.5.1-19.fc11 (build/make) spot R-hgu95av2probe-2.0.0-1.fc9 (build/make) pingou ScientificPython-2.8-4.fc11 (build/make) jspaleta UnihanDb-5.1.0-7.fc11.1 (build/make) dchen,i18n-team abcMIDI-20090317-1.fc12 (build/make) gemi alliance-5.0-26.20070718snap.fc11 (build/make) chitlesh,chitlesh,tnorth almanah-0.5.0-1.fc11 (build/make) lokthare amanda-2.6.0p2-9.fc12 (build/make) dnovotny amora-1.1-4.fc11 (build/make) allisson anjuta-2.26.1.0-1.fc12 (build/make) rishi,rakesh anyremote-4.18.1-1.fc11 (build/make) anyremote apr-util-1.3.7-4.fc12 (build/make) jorton,bojan argyllcms-1.0.4-1.fc12 (build/make) limb arm4-0.8.2-1.fc12 (build/make) grandcross,limb arts-1.5.10-5.fc11 (build/make) than,kkofler,rdieter,tuxbrewr artwiz-aleczapka-fonts-1.3-7.fc11 (build/make) spot,awjb,fonts-sig asio-1.2.0-2.fc11 (build/make) uwog asymptote-1.73-1.fc12 (build/make) spot atlas-3.8.3-4.fc12 (build/make) deji,deji aubio-0.3.2-6.fc11 (build/make) green avr-binutils-2.18-4.fc11 (build/make) tnorth,trondd avr-libc-1.6.4-4.fc12 (build/make) tnorth,trondd awn-extras-applets-0.3.2.1-8.fc11 (build/make) phuang,sindrepb axis-1.2.1-4.1.fc10 (build/make) pcheung babl-0.1.0-1.fc12 (build/make) deji,nphilipp batik-1.7-4.fc11 (build/make) langel,fitzsim beagle-0.3.9-6.fc11 (build/make) orphan,drago01,psytux bigloo-3.1b-5.fc11 (build/make) gemi blacs-1.1-31.fc11 (build/make) spot bmpx-0.40.14-8.fc11 (build/make) akahl,cheese btrfs-progs-0.19-3.fc12 (build/make) josef,mmahut buffer-1.19-5.fc11 (build/make) bcornec,wolfy calf-0.0.18.5-1.fc12 (build/make) oget cave9-0.3-8.fc12 (build/make) bogado cdrkit-1.1.9-4.fc11 (build/make) rrakus cernlib-2006-32.fc11 (build/make) limb,pertusus chipmunk-4.1.0-6.fc11 (build/make) limb classpathx-jaf-1.0-12.fc10 (build/make) devrim,dwalluck clutter-cairo-0.8.2-3.fc11 (build/make) allisson clutter-cairomm-0.7.4-2.fc11 (build/make) denis clutter-gst-0.8.0-4.fc11 (build/make) allisson codeblocks-8.02-7.fc11 (build/make) sharkcz cogito-0.18.2-4.fc11 (build/make) chrisw compat-db-4.6.21-5.fc10 (build/make) jnovy,pmatilai compat-erlang-R10B-13.11.fc11 (build/make) gemi coredumper-1.2.1-8.fc12 (build/make) rakesh couchdb-0.9.0-2.fc12 (build/make) allisson cryptsetup-luks-1.0.7-0.1.fc12 (build/make) lvm-team,agk,dwysocha,mbroz,mornfall,pjones,till,whulbert cuetools-1.4.0-0.4.svn305.fc12 (build/make) stingray dap-hdf4_handler-3.7.9-2.fc11 (build/make) pertusus,pertusus dbus-c++-0.5.0-0.8.20090203git13281b3.fc11 (build/make) drago01 dev86-0.16.17-14.fc11 (build/make) jnovy devhelp-0.23-7.fc12 (build/make) mbarnes e16-themes-0.16.8.0.2-3.fc11 (build/make) terjeros eclipse-cdt-5.0.2-2.fc11 (build/make) jjohnstn eclipse-checkstyle-4.0.1-12.fc11 (build/make) rmyers,akurtakov,overholt elfutils-0.141-1.fc12 (build/make) roland emacs-mew-6.2.51-2.fc11 (build/make) tagoh epiphany-extensions-2.26.1-2.fc12 (build/make) caillon,pgordon espeak-1.40.02-2.fc12 (build/make) faucamp etherbat-1.0.1-5.fc11 (build/make) limb evolution-brutus-1.2.35-2.fc11 (build/make) bpepple evolution-data-server-2.27.3-3.fc12 (build/make) mbarnes,mbarnes,mcrha evolution-rss-0.1.2-9.fc12 (build/make) lucilanga evolution-zimbra-0.1.1-6.fc11 (build/make) mbarnes,mmahut fbreader-0.10.7-1.fc11 (build/make) salimma findbugs-1.3.8-1.fc11 (build/make) jjames fityk-0.8.1-14.fc10 (build/make) jpye fluidsynth-1.0.9-1.fc12 (build/make) green,oget fonts-KOI8-R-1.0-11.fc11 (build/make) than,fonts-sig fonts-hebrew-fancy-0.20051122-5.fc11 (build/make) danken,fonts-sig freefem++-3.0-5.5.fc11 (patch_fuzz) rathann,itamarjp fsarchiver-0.5.6-1.fc12 (build/make) drago01 func-0.25-1.fc12 (build/make) mdehaan,alikins,skvidal fusecompress-2.5-1.fc12 (build/make) lkundrak,lmacken gauche-gl-0.4.4-4.fc11
Fedora rawhide rebuild in mock status 2009-07-10 i386
Fedora Rawhide-in-Mock Build Results for i386 using rawhide as of 10 July 2009. This is a full rebuild of all packages. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ 1 Open Bugs which now build, and can be marked CLOSED RAWHIDE: ruby-rpm: [u'465103'] Total packages: 8005 Number failed to build: 352 Number expected to fail due to ExclusiveArch or ExcludeArch: 18 Leaving: 334 Of those expected to have worked... Without a bug filed: 330 -- Django-1.0.2-3.fc11 (build/make) salimma,smilner GtkAda-2.10.2-2.fc11 (build/make) gemi Io-language-20071010-10.fc11 (build/make) salimma,salimma PyQwt-5.1.0-3.fc11 (build/make) tadej PyX-0.10-6.fc11 (build/make) jamatos,jamatos,mpeters R-2.9.0-2.fc12 (build/make) spot R-BSgenome.Celegans.UCSC.ce2-1.2.0-5 (build/make) pingou R-BSgenome.Dmelanogaster.FlyBase.r51-1.3.1-3 (build/make) pingou R-RScaLAPACK-0.5.1-19.fc11 (build/make) spot R-hgu95av2probe-2.0.0-1.fc9 (build/make) pingou ScientificPython-2.8-4.fc11 (build/make) jspaleta SimGear-1.9.1-6.fc12 (build/make) spot,bellet UnihanDb-5.1.0-7.fc11.1 (build/make) dchen,i18n-team alexandria-0.6.4.1-6.fc11 (build/make) mtasaka almanah-0.5.0-1.fc11 (build/make) lokthare amanda-2.6.0p2-9.fc12 (build/make) dnovotny amora-1.1-4.fc11 (build/make) allisson anjuta-2.26.1.0-1.fc12 (build/make) rishi,rakesh anyremote-4.18.1-1.fc11 (build/make) anyremote apr-util-1.3.7-4.fc12 (build/make) jorton,bojan arm4-0.8.2-1.fc12 (build/make) grandcross,limb arts-1.5.10-5.fc11 (build/make) than,kkofler,rdieter,tuxbrewr asio-1.2.0-2.fc11 (build/make) uwog asterisk-sounds-core-1.4.15-1.fc11 (build/make) jcollie asymptote-1.73-1.fc12 (build/make) spot atlas-3.8.3-4.fc12 (build/make) deji,deji aubio-0.3.2-6.fc11 (build/make) green auriferous-1.0.1-7.fc11 (build/make) jwrdegoede avr-binutils-2.18-4.fc11 (build/make) tnorth,trondd avr-libc-1.6.4-4.fc12 (build/make) tnorth,trondd awn-extras-applets-0.3.2.1-8.fc11 (build/make) phuang,sindrepb axis-1.2.1-4.1.fc10 (build/make) pcheung babl-0.1.0-1.fc12 (build/make) deji,nphilipp baekmuk-bdf-fonts-2.2-7.fc11 (build/make) cchance,fonts-sig,i18n-team,petersen beagle-0.3.9-6.fc11 (build/make) orphan,drago01,psytux bigloo-3.1b-5.fc11 (build/make) gemi blacs-1.1-31.fc11 (build/make) spot bmpx-0.40.14-8.fc11 (build/make) akahl,cheese btrfs-progs-0.19-3.fc12 (build/make) josef,mmahut buffer-1.19-5.fc11 (build/make) bcornec,wolfy bug-buddy-2.27.1-2.fc12 (unpackaged_files/python-egg-info?) rstrode calf-0.0.18.5-1.fc12 (build/make) oget cdrkit-1.1.9-4.fc11 (build/make) rrakus cernlib-2006-32.fc11 (build/make) limb,pertusus chipmunk-4.1.0-6.fc11 (build/make) limb classpathx-jaf-1.0-12.fc10 (build/make) devrim,dwalluck clutter-cairo-0.8.2-3.fc11 (build/make) allisson clutter-cairomm-0.7.4-2.fc11 (build/make) denis clutter-gst-0.8.0-4.fc11 (build/make) allisson codeblocks-8.02-7.fc11 (build/make) sharkcz cogito-0.18.2-4.fc11 (build/make) chrisw compat-db-4.6.21-5.fc10 (build/make) jnovy,pmatilai compat-erlang-R10B-13.11.fc11 (build/make) gemi coredumper-1.2.1-8.fc12 (build/make) rakesh couchdb-0.9.0-2.fc12 (build/make) allisson cryptsetup-luks-1.0.7-0.1.fc12 (build/make) lvm-team,agk,dwysocha,mbroz,mornfall,pjones,till,whulbert cuetools-1.4.0-0.4.svn305.fc12 (build/make) stingray dap-hdf4_handler-3.7.9-2.fc11 (build/make) pertusus,pertusus dbus-c++-0.5.0-0.8.20090203git13281b3.fc11 (build/make) drago01 dev86-0.16.17-14.fc11 (build/make) jnovy devhelp-0.23-7.fc12 (build/make) mbarnes dietlibc-0.31-8.20090228.fc11 (build/make) ensc eclipse-cdt-5.0.2-2.fc11 (build/make) jjohnstn eclipse-checkstyle-4.0.1-12.fc11 (build/make) rmyers,akurtakov,overholt emacs-mew-6.2.51-2.fc11 (build/make) tagoh epiphany-extensions-2.26.1-2.fc12 (build/make) caillon,pgordon etherbat-1.0.1-5.fc11 (build/make) limb evolution-brutus-1.2.35-2.fc11 (build/make) bpepple evolution-data-server-2.27.3-3.fc12 (build/make) mbarnes,mbarnes,mcrha evolution-rss-0.1.2-9.fc12 (build/make) lucilanga evolution-zimbra-0.1.1-6.fc11 (build/make) mbarnes,mmahut fbreader-0.10.7-1.fc11 (build/make) salimma findbugs-1.3.8-1.fc11 (build/make) jjames fityk-0.8.1-14.fc10 (build/make) jpye fluidsynth-1.0.9-1.fc12 (build/make) green,oget fonts-ISO8859-2-1.0-20.fc11 (build/make) pnemade,fonts-sig,i18n-team,pnemade fonts-KOI8-R-1.0-11.fc11 (build/make) than,fonts-sig freefem++-3.0-5.5.fc11 (patch_fuzz) rathann,itamarjp fsarchiver-0.5.6-1.fc12 (build/make) drago01 fusecompress-2.5-1.fc12 (build/make) lkundrak,lmacken gauche-gl-0.4.4-4.fc11 (build/make) gemi gauche-gtk-0.4.1-18.fc11 (build/make) gemi gawk-3.1.6-5.fc11 (build/make) kasal gbdfed-1.4-2.fc11 (build/make) spot gc-7.1-7.fc11 (build/make) rdieter gcdmaster-1.2.2-5.fc11 (build/make) denis gcl-2.6.8-0.3.20090303cvs.fc12 (build/make) jjames,green gdal-1.6.0-8.fc11 (build/make) rezso,pertusus gearmand-0.7-1.fc12 (build/make) ruben gedit-vala-0.4.1-2.fc11 (build/make) salimma geronimo-specs-1.0-2.M2.fc10 (build/make) fnasser gflags-1.0-3.fc11 (build/make) rakesh
Re: Purging the F12 orphans
On Tue, Jul 14, 2009 at 12:58 PM, Jesse Keating jkeat...@redhat.com wrote: Unblocked orphan glipper If noone's taking care of glipper, I'll have to sign up, as I actually *depend* on glipper to function properly. Co-maintainers welcome. -- Ing. Juan M. Rodriguez Moreno Desarrollador de Sistemas Abiertos Sitio: http://proyectofedora.org/mexico -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Purging the F12 orphans
On 14/07/09 19:20, Richard June wrote: I use azureus, and if it's reasonably popular, I'll happily maintain the package. Is there information on whether or not people actually install these packages? I use it. That's as far as it goes at the moment. (keeps my ISP happy) Is there anyway to gauge a download popularity? Regards, Frank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/bmpx/devel bmpx-compile.patch,1.1,1.2 bmpx.spec,1.20,1.21
On Tue, 14 Jul 2009 14:52:17 + (UTC), Caolan wrote: Author: caolanm Update of /cvs/pkgs/rpms/bmpx/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv18298 Modified Files: bmpx-compile.patch bmpx.spec Log Message: Resolves: rhbz#489552 fix to compile bmpx-compile.patch: bmpx on Fedora 11 is broken and needs a rebuild for Cairo, too: https://bugzilla.redhat.com/511333#c1 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora rawhide rebuild in mock status 2009-07-10 x86_64
On Tue, Jul 14, 2009 at 01:22:35PM -0500, Matt Domsch wrote: ocaml-pa-do-0.8.9-2.fc12 (build/make) rjones I checked your logfiles and it seems to have built fine on both architectures ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora rawhide rebuild in mock status 2009-07-10 x86_64
Richard W.M. Jones wrote: On Tue, Jul 14, 2009 at 01:22:35PM -0500, Matt Domsch wrote: ocaml-pa-do-0.8.9-2.fc12 (build/make) rjones I checked your logfiles and it seems to have built fine on both architectures ... Rich. Yeah, some of mine built and some didn't. Not sure. . . -- in your fear, speak only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Something amock with rawhide?
Hello,
is something still haywire in rawhide? My build of Octave 3.2.0 hangs on
i586 with
*** glibc detected *** pdfetex: malloc(): memory corruption: 0x09a3c3a0
***
The package builds fine in x86_64 and ppc{,64}.
http://koji.fedoraproject.org/koji/taskinfo?taskID=1473079 - task root
http://koji.fedoraproject.org/koji/getfile?taskID=1473086name=build.log
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: NVR bugs in rawhide
On Tue, 14 Jul 2009 20:47:00 +0300, Jussi wrote:
[...] packages that are compiled in some way *really should* use the
%{?dist} tag, since that way they are upgraded when the distribution is
upgraded.
They are only upgraded if somebody (or something) bumps'n'rebuilds them,
including a spec file %changelog for the new %release value and a new tag
in cvs.
One cannot rebuild for a changed %{dist} value without creating
a corresponding cvs tag first. One cannot rebuild an unchanged NEVR with
an unchanged [old] cvs tag, because koji rejects such build requests.
For a package whose %version value makes bigger jump mostly or only during
the Rawhide cycle, one doesn't need anything like %dist but can use RPM's
%release everywhere for that pkg just fine.
(Or it can be easily seen that the compilation is obsolete.)
Only if you insist on relying on %dist instead of examining RPM's
Build Date values (or equivalent values in koji) or file timestamps,
which are more accurate.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
