Re: llvm 3.4 in rawhide time
On 14 Jan 2014 06:04, David Airlie airl...@redhat.com wrote: Hi all, I've gotten a build tag f21-llvm for attempting to rebase rawhide to llvm 3.4 Assuming there aren't any major stumbling blocks, are there any plans to back port llvm 3.4 to f20 (like was done for llvm 3.3 in f19)? I need clang 3.4 for my day job but have been holding off on a parallel installable version until I know what's happening in Fedora proper. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: llvm 3.4 in rawhide time
On Tue, Jan 14, 2014 at 12:54 PM, David Airlie airl...@redhat.com wrote: On 14 Jan 2014 06:04, David Airlie airl...@redhat.com wrote: Hi all, I've gotten a build tag f21-llvm for attempting to rebase rawhide to llvm 3.4 Assuming there aren't any major stumbling blocks, are there any plans to back port llvm 3.4 to f20 (like was done for llvm 3.3 in f19)? I need clang 3.4 for my day job but have been holding off on a parallel installable version until I know what's happening in Fedora proper. Maybe, we might like it for GPU drivers, but I want to see how hairy it is, so far it looks rather hairy, most of the projects failed on my simple just rebuild it. iirc last time the rebase was required in order to get a later Mesa into the distro. I will hold off for a few days to see just how hairy things are. If you decide not to rebase f20 i will build something privately, or even a copr build if anybody else is interested in it. If you need any help with testing, patches, etc i would be happy to help where i can. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: llvm 3.4 in rawhide time
On 15 Jan 2014 02:11, David Airlie airl...@redhat.com wrote: On 14 Jan 2014 06:04, David Airlie airl...@redhat.com wrote: Hi all, I've gotten a build tag f21-llvm for attempting to rebase rawhide to llvm 3.4 Assuming there aren't any major stumbling blocks, are there any plans to back port llvm 3.4 to f20 (like was done for llvm 3.3 in f19)? I need clang 3.4 for my day job but have been holding off on a parallel installable version until I know what's happening in Fedora proper. Maybe, we might like it for GPU drivers, but I want to see how hairy it is, so far it looks rather hairy, most of the projects failed on my simple just rebuild it. iirc last time the rebase was required in order to get a later Mesa into the distro. I will hold off for a few days to see just how hairy things are. If you decide not to rebase f20 i will build something privately, or even a copr build if anybody else is interested in it. If you need any help with testing, patches, etc i would be happy to help where i can. It looks like OpenGTL is going to be the sticking point, upstream appears dead, and llvm removed its old school llvm::sys::Path interface that OpenGTL appears to use in a few places. My C++ is fairly fail, and I managed to at least fix two files, but then realised how big a hole I was digging. If anyone has some C++ expertise (package maintainer cc'ed), and some time it might not be too bad too work out, If upstream is dead then OpenGTL probably just wants to be dropped from Rawhide forwards and llvm will have to stay as is in f20. If upstream is just slow though, llvm::sys::path looks like a pretty simple filesystem api and fairly similar to boost::filesystem so I should be able to help there. Will get to work (or not) depending on what Rex hears back. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F19 DVD over size - what to drop?
On 2 May 2013 15:15, John Reiser jrei...@bitwagon.com wrote: On 05/01/2013 06:37 PM, Pádraig Brady wrote: Why are we tied to DVD-5, 4.7GB (4.3GiB) at all? Do we distribute DVDs? Yes. Check with Fedora Ambassadors in EMEA. If so couldn't we use a newer DVD standard? That would reduce coverage significantly. The de facto standard (what customers have) is what was prevalent in the first world 5 to 7 years ago; which omits 8.5GB DVD (DVD/DL). I can't see any users wanting to burn DVDs rather than using USB sticks etc. I burn DVDs. I use them. I use USB flash memory, too, but DVDs have advantages for some of my uses: - DVD can be labeled with a marking pen - burning 16X DVD+R is faster than livecd-iso-to-disk to USB flash memory - keeping track of 10 DVD (different contents) is not a problem - DVD is much less likely to be overwritten (DVD+R never) - DVD is incrementally less expensive (the next 16X DVD+R is $0.25 to $0.40; 4X DVD+RW is $0.40 to $0.60; 8GB USB flash memory with = 5MB/s average during an install is $9) - DVD is inexpensive to give away - DVD collection of releases is useful for archive and support - DVD+R lasts = 10 years; USB flash tends to fail (bit errors) in 7 to 8 years. - I still support hardware that cannot boot directly from USB. I think USB sticks will become much more usable when Fedora allows booting from iso images like some other distributions already do. Currently the standard way involves completely overwriting everything on the stick (1 distribution per stick). Personally I install grub on the stick, extract the contents of the iso into a directory and manually adjust grub to match (so I now have an i686/x86_64, f16-f18, KDE Live/DVD USB sick). Seems to me it should be possible to simplify this a lot (install grub, copy iso, boot) so that USB sticks are usable by the masses without having to dedicate an entire stick to the task. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F19 DVD over size - what to drop?
On 2 May 2013 16:59, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, John5342 john5...@gmail.com said: I think USB sticks will become much more usable when Fedora allows booting from iso images like some other distributions already do. Currently the standard way involves completely overwriting everything on the stick (1 distribution per stick). I belive this has not been the case for a while now; livecd-iso-to-disk has: --multi Used when installing multiple image copies to signal configuration of the boot files for the image in the --livedir dir parameter. --livedir dir Used with multiple image installations to designate the directory dir for the particular image. When I last tried a year or two ago it kept blasting everything away and I found a related bug which I never saw fixed. Will have to try this again though. Thanks for the info. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trimming (or obsoleting) %changelog?
On 15 Apr 2013 14:16, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Mon, 2013-04-15 at 07:43 -0500, Rex Dieter wrote: Richard Hughes wrote: Is there any guidance as when to trim %changelog down to size? Some packages have thousands of lines of spec file dating back over 15 years which seem kinda redundant now we're using git. To me, common sense dictates that it's perfectly ok to trim the length of the changelog as long as items that are relevant to the current release are kept intact. Use your best judgement where that position lies. I wonder if there are legal issues involved as the %changelog also list all the person that worked on that spec file. As for all project, in case of licensing changes, you need to know all the authors that ever contributed to the project. But again, IANAL :) I believe the spec files are by default covered under the Fedora Contributor License Agreement (the cla all contributors have to agree to in fas before contributing) and that covers any project wide license changes too I believe. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LightDM is absent?
On Sat, Apr 6, 2013 at 5:30 PM, Eugene Pivnev ti.eug...@gmail.com wrote: I can't find lightd, package in Fedora - just lightdm greeters: http://img687.imageshack.us/img687/679/screenshotac1e1cb8.png I'm wrong? When you search for Applications (the default) the results only show certain user visible packages (i think ones with .desktop files). If you click packages when searching it should show all packages. I think searching applications by default is a stupid idea when that web app is mostly used by packagers but i really can't be bothered to argue with people. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: headsup for llvm-3.2
On 28 Feb 2013 14:48, Dominik 'Rathann' Mierzejewski domi...@greysector.net wrote: On Wednesday, 13 February 2013 at 15:26, John5342 wrote: On 13 Feb 2013 09:37, Jens Petersen peter...@redhat.com wrote: Hi, I spend a little time recently working on the llvm package trying to fix a few Fedora bugs that have been open for a while... I also think we should really get llvm-3.2 into Fedora 19. I have done a few tests and scratch builds in https://bugzilla.redhat.com/show_bug.cgi?id=903100 and am planning to build llvm-3.2 in rawhide this week hopefully. Are there any plans to bring this to F18? There was talk about bringing 3.1 to F17 including some support from the Mesa guys but then nothing actually happened. I would really like it if I could go through F18 without having to build my own private parallel installable llvm 3.2 (i need the c++11 memory model support introduced in 3.2 for my lock free algorithms). Could you share your instructions for building llvm 3.2 on F18? I tried rebuilding the F19 package, but it fails with unspecified linker errors. I haven't actually built it yet (was waiting as long as I could to see if this would be done officially). Generally speaking the first step is changing the gcc/libstdc++ version in the spec and then fix up any minor issues afterwards, but in order to actually install and use it you need to rebuild the other packages that depend on it (in a default Fedora setup that's mainly Mesa) . Mesa is one package I definitely don't understand which is why I don't like the idea of doing llvm myself. The other alternative is what I would likely do instead and do a parallel installable package which of course requires a bit more thought since a lot of the libs are by default unversioned. If it does turn out I have to do this myself though I will see about putting a repo on fedorapeople and announce it here for those that want/need it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass closing EOL bugs should not close bugs with pending updates
On Tue, Feb 19, 2013 at 2:26 PM, Christoph Wickert christoph.wick...@gmail.com wrote: Am Montag, den 18.02.2013, 23:34 + schrieb John5342: On Mon, Feb 18, 2013 at 10:52 PM, Christoph Wickert christoph.wick...@gmail.com wrote: Despite of the question whether it's right or wrong it's a manual process and we cannot rely it really happens. On the other hand changing the script to not close any bugs which are ON_QA is easy. So what is so bad about ignoring bugs MODIFIED and/or ON_QA bugs? This is a corner case perhaps, but those bugs still need closing at some point. If an updates-testing package gets un-pushed or never gets sent to stable the bug will never be closed. Maybe it is a corner case, but what you describe is a corner case of the corner case. How many updates get actually withdrawn? 1%, 2%, 5%? My point is not that this specific corner case should prevent improving the script. Merely that there are negatives (there are others corner cases too) that make things more complicated than just ignoring a status. Considering the number of (or lack of) people who have complained, i get the impression none of these things are actually a wide spread problem and very quickly the effort and fragility or clever scripts to cover all cases becomes more of a hassle than a benefit. That means that the script would need another rule that it _also_ closes bugs for the release before regardless of MODIFIED/ON_QA. That's what it does already, no further rule needed. I haven't looked at the script but further up the thread showed version == 16 rather than version = 16. The script would have conceptually have to change from (version = EOL_Version) to (((version == EOL_Version) (status != MODIFIED) (status != ON_QA)) || (version EOL_Version)). That's already 4 times as long. Then i am sure there are other corner cases too. This could be simplified even further by blocking creating new bugs for EOL releases at the appropriate time but then closing the old bugs after a grace period (e.g. 1 month). This would solve the vast majority of these cases like the one that started this thread and the minute fraction of people who are still affected by the mass closing can just change the release or reopen. No matter anyway. I am not significantly affected by any of this. Nor am i one of the people who can solve it so, whatever. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: headsup for llvm-3.2
On Mon, Feb 18, 2013 at 11:01 AM, Jens Petersen peter...@redhat.com wrote: Are there any plans to bring this to F18? Good question There was talk about bringing 3.1 to F17 including some support from the Mesa guys but then nothing actually happened. I would really like it if I could go through F18 without having to build my own private parallel installable llvm 3.2 (i need the c++11 memory model support introduced in 3.2 for my lock free algorithms). I think it would still be good to do the 3.1 backport to F17. 3.1 doesn't directly affect me any more (since the previous discussion some time ago f18 has been released) but i do have at least a couple of f17 machines i would be happy to test with. At least the clang part. 3.2 requires newer Mesa and also some other version bumps of reverse deps but perhaps it could be done later for F18 after it has been tested in Rawhide? In the previous discussion [1] and more specifically [2] updating appears to be a good thing for Mesa. Of course the Mesa people will know better if that still applies. As with any slightly wider reaching updates there is certainly no harm in Rawhide first and a reasonable span in updates-testing. If you want additional testing for f18 without blocking updates-testing then repos.fedorapeople.org is also an option for testing. I know a few people who would be happy to test from there. But I am not the package owner or comaintainer and still kind of new to llvm so it is not really my call at this point. Still doesn't prevent discussion so that all the information is present when whoever does make the call gets around to it. [1] - http://lists.fedoraproject.org/pipermail/devel/2012-November/174399.html [2] - http://lists.fedoraproject.org/pipermail/devel/2012-November/174406.html -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass closing EOL bugs should not close bugs with pending updates
On Mon, Feb 18, 2013 at 10:52 PM, Christoph Wickert christoph.wick...@gmail.com wrote: Despite of the question whether it's right or wrong it's a manual process and we cannot rely it really happens. On the other hand changing the script to not close any bugs which are ON_QA is easy. So what is so bad about ignoring bugs MODIFIED and/or ON_QA bugs? This is a corner case perhaps, but those bugs still need closing at some point. If an updates-testing package gets un-pushed or never gets sent to stable the bug will never be closed. That means that the script would need another rule that it _also_ closes bugs for the release before regardless of MODIFIED/ON_QA. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: headsup for llvm-3.2
On 13 Feb 2013 09:37, Jens Petersen peter...@redhat.com wrote: Hi, I spend a little time recently working on the llvm package trying to fix a few Fedora bugs that have been open for a while... I also think we should really get llvm-3.2 into Fedora 19. I have done a few tests and scratch builds in https://bugzilla.redhat.com/show_bug.cgi?id=903100 and am planning to build llvm-3.2 in rawhide this week hopefully. Are there any plans to bring this to F18? There was talk about bringing 3.1 to F17 including some support from the Mesa guys but then nothing actually happened. I would really like it if I could go through F18 without having to build my own private parallel installable llvm 3.2 (i need the c++11 memory model support introduced in 3.2 for my lock free algorithms). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Cannot change fedora-cvs flag on bugzilla
On Fri, Nov 23, 2012 at 3:05 PM, Jamie Nguyen j...@jamielinux.com wrote: Hi all, Having some trouble for this package review request: https://bugzilla.redhat.com/show_bug.cgi?id=877705 It has been approved, but I can't set the fedora-cvs flag. This has worked in the past, but maybe something to do with different email addresses: FAS email: j...@jamielinux.com Bugzilla email: jamieli...@fedoraproject.org Would appreciate any help. Just a wild guess but you don't appear to be in the packager group. Just the CLA groups and the fedorabugs group. Since it only makes sense to change the cvs flag if you are a packager perhaps you are required to be in the group before you can edit the field. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Cannot change fedora-cvs flag on bugzilla
On Fri, Nov 23, 2012 at 10:16 PM, John5342 john5...@gmail.com wrote: On Fri, Nov 23, 2012 at 3:05 PM, Jamie Nguyen j...@jamielinux.com wrote: Hi all, Having some trouble for this package review request: https://bugzilla.redhat.com/show_bug.cgi?id=877705 It has been approved, but I can't set the fedora-cvs flag. This has worked in the past, but maybe something to do with different email addresses: FAS email: j...@jamielinux.com Bugzilla email: jamieli...@fedoraproject.org Would appreciate any help. Just a wild guess but you don't appear to be in the packager group. Just the CLA groups and the fedorabugs group. Since it only makes sense to change the cvs flag if you are a packager perhaps you are required to be in the group before you can edit the field. Ok. Ignore me. FAS clearly shows you are in the group but for some reason admin.fedoraproject.org/community doesn't show you in the group. Will see about filing a bug shortly. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is RPM now stricter about checking for file conflicts?
On Oct 27, 2012 7:46 PM, Michel Alexandre Salim sali...@fedoraproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (originally posted to test@; Adam Williamson suggested it might be more appropriate here) Ever since I started tracking Fedora 18, Google Music Manager is no longer installable, and now Oracle's Virtual Box cannot be installed either (both from upstream Yum repositories). https://bugzilla.redhat.com/show_bug.cgi?id=870655 In both cases, RPM and yum aborts with file conflicts -- /lib/modules for VirtualBox and /usr/bin for google-musicmanager. While, granted, these are upstream packaging bugs and those directories should not be owned by the corresponding packages (they are owned by filesystem), is there any reason why the same RPMs install just fine previously? Just a wild stab in the dark. Would the UsrMove (specifically the change from an actual folder to a symlink) cause a conflict? The Fedora packages don't own the folders since they are owned by the filesystem package anyway but the external packages could be owning the folders even though they ate now symlinks. Just a guess though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-rpm-config and rpm-build
On Thu, Jun 14, 2012 at 9:53 PM, Paul Wouters pwout...@redhat.com wrote: On Tue, 12 Jun 2012, John5342 wrote: Why is redhat-rpm-config not a dependancy dragged in by rpm-build? I imagine because rpmbuild is in fact useful for building packages other than for Fedora. But then those packages need to provide some set of macros for debuginfo packages, so there is some 'requires' that are currently met by redhat-rpm-config that these non-fedora packages would need to supply to rpm-build as well. So there is a dependancy. Who says that somebody creating rpms for another OS for instance even wants debuginfo packages? Who says that if they did they would want the same setup anyway? If you use spec files that rely on Fedora features then you would need redhat-rpm-config. If on the other hand you relied on macros specific to SUSE you would need their equivelent. If you want to create your own distribution based on rpm then you might create your own set. I have never tried but i imagine that even without a separate configuration you can still create basic rpms that would work. If i recall correctly the recommended way to install everything needed is yum install fedora-packager which pulls in everything needed for Fedora related packaging including redhat-rpm-config. While grousp are convenient, the package dependancies should really be in order. In my opinion they are in order. From what you said rpm-build did exactly what it was supposed to according to upstream. By then adding our Fedora/Redhat specific configuration it does what _Fedora_ wants. Anyway. My opinion doesn't really matter all that much. I am not the maintainer of that package, anything to do with upstream or even related. All i can see is packages that seem to be working as designed and there is even a handy helper package that sets up everything for the specific purpose maintaining Fedora packages as opposed just the general case. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-rpm-config and rpm-build
On Tue, Jun 12, 2012 at 10:14 PM, Paul Wouters pwout...@redhat.com wrote: I was building a package and not getting any debuginfo packages, and luckily rdieter was around to tell me (again) that I was missing the redhat-rpm-config package. Why is redhat-rpm-config not a dependancy dragged in by rpm-build? I imagine because rpmbuild is in fact useful for building packages other than for Fedora. If i recall correctly the recommended way to install everything needed is yum install fedora-packager which pulls in everything needed for Fedora related packaging including redhat-rpm-config. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: On a related note...
On Tue, May 29, 2012 at 10:04 PM, Neal Becker ndbeck...@gmail.com wrote: You know what was the painless part of this re-install? After firing up google chrome, I didn't need to reinstall anything for it. It's all synced with gmail. I find myself wishing that all my fedora packages could be restored just like that. Oh sure, there's a few methods for automaticing installs. But none are so brain-dead easy. Imagine, just 1 click (or command) to sync all the packages (and maybe /etc?) to some server, and 1 step to reinstall back to the last state. What's that? Wouldn't work over upgrades? Somehow it does for chrome. And for android. The difference is that chrome/chromium is a small target. They know precisely how the data is stored, the types of data stored, what is or is not compatible, what settings are safe to transfer and what only makes sense on a specific machine. To do the same for /etc in general would require the synchronization system to know everything about every single package that might ever install some configuration file into /etc. In addition /etc contains files that can be arbitrarily edited by humans. Chrome on the other hand only has to deal with configuration controlled through the browser and any changes that aren't recognized can simply be thrown away. If however you feel it is safe to just transfer any configuration file from one version of Fedora to another without checking first then there are already packages available to do that in Fedora with only minor effort on your part. Examples include etckeeper, any backup program or if you are willing to invest a little time up front puppet. You could even play some games with btrfs snapshots. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to determine FAS from BZ email?
On Thu, Feb 23, 2012 at 15:33, Jamie Nguyen ja...@tomoyolinux.co.uk wrote: Yes. Since the emails don't necessarily match up, I don't think you can rely on querying the database. Not only is it less efficient, it can break too! (In most cases the emails probably will match up anyway, but you can't rely on it.) It is possible that they don't match but they are more or less required to though. Last i checked the bugzilla editbugs permissions and the like are set from fas by email address so if the addresses don't match up then the user won't be able to manage bugzilla properly anyway. If the user doesn't match up then they should probably be warned before they are sponsored so the extra request for fas along with a warning i think is a good thing. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, Feb 17, 2012 at 13:54, Nils Philippsen n...@redhat.com wrote: This disables normal non-programmable tab-completion for me. Also, if you want the (other) default settings, you need to $include /etc/inputrc on the first line of ~/.inputrc. It would really help if we shipped documentation for this file :-). man readline. man bash has a bit of information from a bash perspective too. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Thu, Feb 16, 2012 at 03:34, Stephen John Smoogen smo...@gmail.com wrote: A bad autocomplete can cause you to sit 3-4 minutes as DNS or other things time out. Ctrl+C will cancel the command and the completion with it. It's not ideal if you are typing a long command but it certainly avoids waiting 3-4 minutes... -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Libs with applications
On Sun, Nov 20, 2011 at 19:33, Steve Grubb sgr...@redhat.com wrote: On Sunday, November 20, 2011 02:14:09 PM drago01 wrote: On Sun, Nov 20, 2011 at 8:03 PM, Kevin Kofler kevin.kof...@chello.at wrote: Steve Grubb wrote: For example, if a 32 bit library is installed, which application is left - the 64 or 32 bit one? If you install ONLY the 32-bit multilib, the 32-bit version. If you install BOTH the 64-bit and 32-bit packages, the 64-bit version (on all the platforms where 64-bit is preferred, which includes x86_64 and now also ppc64). If you install ONLY the 64-bit package, the 64-bit version. Yeah which means there isn't really a problem here. Well, yeah there is the other problem of dependencies and getting a smaller minimal install. For example, libnotify. # ldd /usr/bin/notify-send | wc -l 44 # ldd /usr/lib64/libnotify.so.1.2.3 | wc -l 12 or how about libmsn # ldd /usr/bin/msntest | wc -l 20 # ldd /usr/lib64/libmsn.so.0.3.0 | wc -l 9 I am the maintainer of libmsn. msntest probably could be moved to a subpackage but it is a small program. All of the dependencies found by ldd are already required by the applications using libmsn and msntest is also very useful for checking if a problem connecting to msn is caused by libmsn or the settings/applications using it. I would be happy to move msntest into a subpackage if it is specifically requested but under the current circumstances it would gain nothing and just add an extra package to the repos. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 heads up: gnome-shell for everyone!
On Wed, Nov 9, 2011 at 15:27, Kevin Kofler kevin.kof...@chello.at wrote: Anything that directly or indirectly uses QtWebKit or QtScript also requires execmem, unless we disable the JavaScript JIT, which we used to do, but got users complaining about the slowness. See also: https://bugs.webkit.org/show_bug.cgi?id=35154 which is being ignored entirely by upstream. I don't know if you noticed but that bug shows it isn't and never has been assigned to anybody so it is not entirely impossible nobody has actually seen it... -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: KDE devels - why is kdeedu missing from websvn?
On Sun, Oct 2, 2011 at 15:31, valent.turko...@gmail.com valent.turko...@gmail.com wrote: On Sun, Oct 2, 2011 at 4:28 PM, valent.turko...@gmail.com valent.turko...@gmail.com wrote: Hi KDE devels, I can't find kdeedu and marble in KDE websvn, have I missed something? http://websvn.kde.org/trunk/KDE/kdeedu/ - is now a dead link. Is this a bug or kdeedu has new link? For starters kde have moved everything to git now (web interface is at [1]). On top of that a lot of the components have been split into smaller chunks upstream. I think kdeedu might be one of them. More info about kde and git is at [2]. [1] - http://quickgit.kde.org/ [2] - http://techbase.kde.org/Development/Git -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kudos to Tom Spot Callaway
On Fri, Sep 9, 2011 at 14:47, Jeffrey Ollie j...@ocjtech.us wrote: On Fri, Sep 9, 2011 at 2:16 AM, Christoph Frieben christoph.frie...@googlemail.com wrote: 2011/9/8 Jóhann B. Guðmundsson: On behalf of the systemd convertion team Just wanted to say thanks to Tom Spot Callaway he's been on fire today packaging submitted unit files and shipping them. Your work did not go unoticed! I do agree in particular with respect to his labour to provide cromium packages to the Fedora community. However, there is always some margin to improve: would it be possible to actually sign the chromium builds somehow? ~C What would be more productive (in the long term at least) is figuring out what the blockers are to getting Chromium into Fedora itself and getting those fixed, rather than as an external repo. That way packages would be signed as a part of the normal update process. I've never looked at the source or the packages myself so I can't say anything more - the packages do work fantastically though and I appreciate all the work Tom has done on them! This is an old blog post but having seen upstream i am sure it still very much applies: http://spot.livejournal.com/312320.html -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 14:23, Bruno Wolff III br...@wolff.to wrote: On Tue, Aug 30, 2011 at 14:37:16 +0100, Matthew Garrett mj...@srcf.ucam.org wrote: On Tue, Aug 30, 2011 at 08:09:51AM -0500, Bruno Wolff III wrote: On Tue, Aug 30, 2011 at 14:26:39 +0100, Matthew Garrett mj...@srcf.ucam.org wrote: Or just add floppy-support and analog-joystick-support packages that include appropriate modprobe.conf fragments, and have documentation that instructs the user to install them. To make this more precise, woulf the appropriate way to do this would be to perhaps put floppy.conf or joystick.conf in /etc/modprode.d? With a post install script to run modprobe manually? That seems like it'd work. I'll need to test it. Right now I use explicit modprobe commands in rc.local, which isn't good for packages. I looked at modprobe.conf documentation and it doesn't seem like it uses those files to determine what to load, only what to do if it is loaded. So it may be that udev is really the correct place to do things. I'll investigate that. Once I know the right thing to do, the packaging should be pretty easy. man modules-load.d looks promising too. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning javassist
I don't use this package, I only took it over in order to get another package in which has since become irrelevant and most importantly although i know plenty about java (and ant) i have no clue at all about maven so this package could really do with a better owner. The package currently has only one bug open against it [1] which i have already fixed in git. It does however have a maven related build failure in f16 (and presumably devel) [2]. [1] - https://bugzilla.redhat.com/show_bug.cgi?id=734255 [2] - http://koji.fedoraproject.org/koji/taskinfo?taskID=3311807 -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Tue, Aug 30, 2011 at 21:12, Chris Adams cmad...@hiwaay.net wrote: In any case, instead of arguing semantics, can you answer my actual question? How many systems hang when floppy.ko is loaded? If it is a large number, it should be easy to point to lots of data. Ok, just some very approximate stats for a group of approximately 50 computers i used to run (this was about 2 years ago and with various linux distributions but i doubt floppy support varies much). The computers with floppy drives enabled in the BIOS even though there was no actual drive attached took mostly between 2 and 20 seconds longer to boot. 2 of them (probably very broken controllers) actually took 2 minutes longer to boot. These extra boot times are far from being the end of the world but certainly not worth inflicting on everyone to satisfy the rare use from a tiny proportion of users. I may be way wide of the mark but if floppy drives were enabled either on demand or as a service in systemd could the module perhaps be loaded later on during boot and in parallel with the rest of the boot. That would make any potential hang completely irrelevant. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Not able to update
On Tue, Aug 23, 2011 at 18:22, Nathan O. ndowen...@gmail.com wrote: I am not able to submit packages as an update through bodhi web interface nor via fedpkg update. I have the package in F15, but I am trying to send it to F16 and both ways give me the error that newlisp not tagged as an update candidate Also I get a weird error for clex when I run fedpkg build BuildError: package clex is blocked for tag f16-updates-candidate. If i had to guess i would say it was one of the packages that was orphaned and retired for F-16 just before the branch as was announced some time back on this list [1]. If you claimed it after it was retired/blocked then you will have to follow the relevant procedure (which i believe also includes a re-review) to get it unblocked again. Until it is unblocked it won't be possible to tag the build in F-16 (as indicated in the error) or submit it as an update. To the best of my knowledge the procedure is outlined under Claiming Ownership of a Deprecated Package at [2]. [1] - http://lists.fedoraproject.org/pipermail/devel/2011-July/154154.html [2] - https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UseSWIG.cmake is borked - need help with workaround
On Thu, Jul 21, 2011 at 03:29, Ankur Sinha sanjay.an...@gmail.com wrote:
Hello,
In the cmake version residing in rawhide, the UseSWIG.cmake file is
broken. Upstream is aware of this. I've also filed a bug with fedora
here[1].
I'd like to find a temporary solution to this. gdcm cannot build in
rawhide, and a lot of fedora-medical related packages are failing to
build in rawhide because of this.
I have the fedora 15 version of the UseSWIG.cmake file, which worked
correctly. How can I use this in my mock build? I need to *force* cmake
to use this file instead of it's own module.
I've placed the f15-UseSWIG.cmake in the project/CMake directory, but
Cmake still finds its own broken module. What else does one need to do
here?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=723652
If the problem is purely with the actual UseSWIG.cmake file and not
with the supporting tools then as a temporary workaround you can stick
the old UseSWIG.cmake file in a directory of it's own and somewhere in
the CMakeLists.txt before include(UseSWIG) (easiest somewhere near
the top of the root CMakeLists.txt file) put a line similar to the
following:
set(CMAKE_MODULE_PATH path ${CMAKE_MODULE_PATH})
where path could be the absolute path to the directory containing
the UseSWIG.cmake module or ${CMAKE_CURRENT_SOURCE_DIR}/relative/path.
The quotes are needed though i believe.
That way your file should be found before any others. The only
exception is if UseSWIG is included from another module in the
standard cmake modules directory. If that's the case then cmake will
always search there first. To return to the old behaviour where
CMAKE_MODULE_PATH is always used first add cmake_policy(SET CMP0017
OLD) to the CMakeLists.txt file.
All of this is based on the documentation at [1]. I haven't tested any
of it myself.
[1] http://www.cmake.org/cmake/help/cmake-2-8-docs.html
--
There are 10 kinds of people in the world: Those who understand binary
and those who don't...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning xine-lib, EOL'ing phonon-backend-xine
On Sun, Jun 12, 2011 at 02:06, Petrus de Calguarium pguec...@gmail.com wrote: John5342 wrote: I forget which one exactly contains the mp3 plugin gstreamer-plugins-ugly, I believe i just install all of them and then i don't have to worry about any other format i may one day come across. ditto The same plugins are also used by just about every other form of KDE based audio/video. That includes everything from video players like Dragon to audio players like Amarok to System Notifications etc. Curious. I thought Dragon must use xine-lib, since both kdemultimedia and kdebase-runtime require it in F15. At least in kdemultimedia, wine-lib seems to be required for dvd support (which is usable within Fedora assuming they are not encrypted and usable on encrypted dvds with libdvdcss) which is a little more advanced than phonon can handle (complex and separate videos, menu navigation etc) and therefore handled separately. I don't know about kdebase-runtime but i imagine that has it's own independent purpose. Dragon does seem to use phonon for most of it's stuff though. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning xine-lib, EOL'ing phonon-backend-xine
On Sat, Jun 11, 2011 at 19:02, Petrus de Calguarium pguec...@gmail.comwrote: Kevin Kofler wrote: there's one third-party KDE-Platform-based application still using xine-lib for the foreseeable future: Kaffeine. kaffeine has begun to look kind of shabby. I always installed it, as xine appeared to have the most complete set of codecs. Can other programs now deal with everything that xine/kaffeine was a fallback for? (Sorry, I have no actual examples, off the top of my head) xine-lib is a requisite for xine-lib-extras-freeworld. Will amarok be using a different library to play mp3 in f16? So far as i am aware amarok just uses phonon for playback (since 2.0) so if you use phonon-backend-xine then it uses xine and if you use phonon-backend-gstreamer it uses gstreamer and phonon-backend-vlc uses vlc. Hence xine-lib-extras-freeworld should make no difference to amarok when using the default backend anyway. You probably want gstreamer-plugins-* in f15+ (or whenever phonon-backend-gstreamer became the default) unless you changed the back end manually. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning xine-lib, EOL'ing phonon-backend-xine
On Sat, Jun 11, 2011 at 22:59, Petrus de Calguarium pguec...@gmail.com wrote: John5342 wrote: Hence xine-lib-extras-freeworld should make no difference to amarok when using the default backend anyway. You probably want gstreamer-plugins-* in f15+ (or whenever phonon-backend-gstreamer became the default) unless you changed the back end manually. Oh, so you mean I never needed to install xine-lib-extras-freeworld, since I am using phonon-backend-gstreamer? Precisely. I can get amarok to play mp3, assuming I have all of the gstreamer-plugins-* installed? Yes basically. I forget which one exactly contains the mp3 plugin but i just install all of them and then i don't have to worry about any other format i may one day come across. The same plugins are also used by just about every other form of KDE based audio/video. That includes everything from video players like Dragon to audio players like Amarok to System Notifications etc. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Thu, Jun 9, 2011 at 23:37, Dave Jones da...@redhat.com wrote: On Thu, Jun 09, 2011 at 02:00:57PM +0100, Matthew Garrett wrote: On Thu, Jun 09, 2011 at 08:01:06PM +1000, Chris Jones wrote: I agree. As virtualization technology becomes more and more involved and frequent on users systems, particularly with advanced Linux users, I think there needs to be a strong focus on ensuring that all releases run in virtualized environments without any major issues. ie. Virtualbox. Perhaps a dedicated team among the developers who specialize in this area. I don't think there are any developers working on this area, where this area is Virtualbox. We don't ship Virtualbox. We don't ship a kernel that has any knowledge of Virtualbox. There's a good argument for having this be part of the QA process and requiring that we boot in the common virtualisation environments as part of the release criteria, but I don't think we can realistically suggest that our virtualisation developers (who work on code that has nothing to do with Virtualbox) be responsible for that. I'm curious why virtualbox has gained so much inertia so quickly. Based solely on the number of kernel bug reports we get that seem to be related to it, I have almost zero confidence in it being reliable. Why are people choosing it over other solutions, and what can we change in qemu/kvm to get users using that instead ? I don't know about anyone else but i found in the days before processors had hardware virtualization support (i think i had an Athlon 64 x2 at the time) VirtualBox seemed to run most things i threw at it at quite a usable speed while all the other open source options seemed to work but the performance was on par with swimming through concrete. Things may have improved since but i only use virtual machines every now and again so i just stick to what's easy. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji attempting to use qt3-devel rpm rather than qt-devel on fedora 13 build root
On Tue, Jun 7, 2011 at 23:37, William Cohen wco...@redhat.com wrote: I am attempting to rebuild oprofile for fedora 13. However koji is converting the following in the spec file: BuildRequires: qt-devel into a dependency on the qt3-devel rpm, which is wrong. There is a qt-devel for qt4 available. Why isn't it using the proper qt-devel? The package built properly in fc13 earlier in april 2011 and similar builds were successful for FC14/FC15/Rawhide today. Detail of the attempted koji build are at: http://koji.fedoraproject.org/koji/taskinfo?taskID=3117592 Any suggestions on tweaks to the oprofile.spec file force it to use qt4 based qt-devel rpm would be appreciated. Both qt3-devel and qt-devel (qt4) provide qt-devel. They also provide qt3-devel and qt4-devel respectively if you want a specific one. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji attempting to use qt3-devel rpm rather than qt-devel on fedora 13 build root
On Tue, Jun 7, 2011 at 23:45, John5342 john5...@gmail.com wrote: On Tue, Jun 7, 2011 at 23:37, William Cohen wco...@redhat.com wrote: I am attempting to rebuild oprofile for fedora 13. However koji is converting the following in the spec file: BuildRequires: qt-devel into a dependency on the qt3-devel rpm, which is wrong. There is a qt-devel for qt4 available. Why isn't it using the proper qt-devel? The package built properly in fc13 earlier in april 2011 and similar builds were successful for FC14/FC15/Rawhide today. Detail of the attempted koji build are at: http://koji.fedoraproject.org/koji/taskinfo?taskID=3117592 Any suggestions on tweaks to the oprofile.spec file force it to use qt4 based qt-devel rpm would be appreciated. Both qt3-devel and qt-devel (qt4) provide qt-devel. They also provide qt3-devel and qt4-devel respectively if you want a specific one. Looking closer it seems the qt3-devel in f13 is providing qt-devel with an apoch of 1 while the other packages don't seem to have one which is likely why qt3-devel is being picked over qt-devel (qt4). -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a new scm module for a new package
On Thu, Jan 6, 2011 at 19:19, Adam Litke a...@us.ibm.com wrote: Hello all. I am a new Fedora packager and am following the process to create a new package. The associated bugzilla is 638647 [1]. At this point I am trying to request a new SCM module for my package and have followed the documented steps [2] but nothing has happened in 24 hours. Is this an automated process or does it require human intervention. Does anyone know if there is a specific problem with the state of my bugzilla bug that might be preventing the request from being picked up? At first glance the bug isn't assigned to a reviewer plus it is missing the fedora-review+ flag (which should be set by the reviewer on completion). Since you need a sponsor the review also has to be completed by a sponsor as already stated in the bug. See the following for more information: https://fedoraproject.org/wiki/Package_Review_Process -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: It's been a while, but I could do with a hand...
On Wed, Oct 13, 2010 at 00:05, Paul F. Johnson p...@all-the-johnsons.co.uk wrote: Hi, It's been a while since I've done any sort of uploading and in that time my box died, has been rebuilt and is running happily on rawhide. Problem is my scripts for uploading have gone! I've followed the information on the wiki but when I try to upload, I'm getting [p...@pb3 common]$ ./cvs-import.sh ~/rpmbuild/SRPMS/mono-2.8-1.1.fc15.src.rpm Checking out module: 'mono' Unpacking source package: mono-2.8-1.1.fc15.src.rpm... cvs [server aborted]: remove requires write access to the repository I've downloaded a client side cert, changed my gpg key and ssh key (uploaded both to my details on the fas system). I've done export CVS_RSH=ssh and export CVSROOT=:ext:p...@cvs.fedoraproject.org:/cvs/pkgs Have I gone wrong somewhere and to make life easy, is there a GUI way to upload to the rawhide repos yet? Everything uses git now. See http://fedoraproject.org/wiki/PackageMaintainers/Join and for some equivelant commands to cvs http://fedoraproject.org/wiki/Using_Fedora_GIT is useful. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: acl problem?
On Mon, Aug 2, 2010 at 23:17, Neal Becker ndbeck...@gmail.com wrote: Repository : :ext:nbec...@cvs.fedoraproject.org:/cvs/pkgs Module : rpms/mercurial/devel Working dir: ~/fedora/mercurial/devel/ In directory .: Message: cvs [commit aborted]: correct above errors first! Message: Access denied: nbecker is not in ACL for rpms/mercurial/devel Message: cvs commit: Pre-commit check failed See the countless recent emails about the migration to dist-git. cvs is now read only and everything is now done through git. This is a good starting point: http://fedoraproject.org/wiki/Using_Fedora_GIT -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trouble locally reproducing koji build error
On Fri, Jul 16, 2010 at 20:52, Zach Carter z.car...@f5.com wrote:
On Friday 16 July 2010 00:36:31 Andreas Schwab wrote:
Any insight, tips or pointers would be much appreciated.
You could modify the spec file to cat the config.log file on error,
which should give you more clues.
Thanks for the suggestion. I did that and got a more verbose and detailed
log.[1] Unfortunately I'm not a big enough c++/boost guru to know what it
means. I'll keep banging away at it though.
And I still don't know why it can't be reproduced outside of koji. I even
tried the build on one of Kevin's public machines (rawhide was natively
installed there), and the error did not reproduce.
-Zach
[1] http://koji.fedoraproject.org/koji/getfile?taskID=2324390name=build.log
...
| include boost/program_options.hpp
| int
| main ()
| {
| boost::program_options::variables_map::variables_map dummy()
| ;
| return 0;
| }
configure:18263: g++ -o conftest -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -
fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
conftest.cpp -lboost_program_options -lboost_system -lboost_regex -
lboost_program_options-mt 5
conftest.cpp: In function 'int main()':
conftest.cpp:58:1: error:
'boost::program_options::variables_map::variables_map' names the constructor,
not the type
conftest.cpp:58:54: error: expected ';' before 'dummy'
conftest.cpp:59:3: error: statement cannot resolve address of overloaded
function
configure:18263: $? = 1
configure: failed program was:
...
Well the problem is obvious. The line in the test program should be:
boost::program_options::variables_map dummy()
and not:
boost::program_options::variables_map::variables_map dummy()
I however know very little about autotools (and don't intend on ever
learning either) so how to actually fix it is another matter. If the
configuration scripts are generated during the build maybe there is
something going on there. As a temporary workaround perhaps it might
be possible to just use sed to change the line in the configuration
scripts after they are generated.
--
There are 10 kinds of people in the world: Those who understand binary
and those who don't...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Wed, Jul 7, 2010 at 21:29, Tom spot Callaway tcall...@redhat.com wrote: [john5342] ebook-tools: ebook-tools-libs-0.1.1-5.fc12.x86_64 False positive: libs subpackage contains license file and all other ebook-tools.srpm derived packages depend on it. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Missing dependency already installed
On Mon, Jun 28, 2010 at 19:36, Mohammed Morsi mmo...@redhat.com wrote: Howdy, I've been scratching my head over this problem for the last few days and figured it was time to get some help. I'm trying to build Ruby on Rails v2.3.8 against Fedora 13 but am running into dependency issues. Namely the 'rubygem-activerecord' package (rails is simple a collection of this and a few other active*/action* packages) pulls in the 'rubygem-activesupport' package of the same version, but yum is failing to find it, even though it is installed. Ergo it results in this error: yum install --nogpgcheck ruby-activerecord-2.3.8-3.fc13.noarch.rpm Loaded plugins: presto, refresh-packagekit Setting up Install Process Examining ruby-activerecord-2.3.8-3.fc13.noarch.rpm: ruby-activerecord-2.3.8-3.fc13.noarch Marking ruby-activerecord-2.3.8-3.fc13.noarch.rpm to be installed Resolving Dependencies -- Running transaction check --- Package ruby-activerecord.noarch 0:2.3.8-3.fc13 set to be updated -- Processing Dependency: rubygem-activesupport = 2.3.8 for package: ruby-activerecord-2.3.8-3.fc13.noarch -- Finished Dependency Resolution Error: Package: ruby-activerecord-2.3.8-3.fc13.noarch (/ruby-activerecord-2.3.8-3.fc13.noarch) Requires: rubygem-activesupport = 2.3.8 Installed: 1:rubygem-activesupport-2.3.8-1.fc13.noarch (@/rubygem-activesupport-2.3.8-1.fc13.noarch) Available: 1:rubygem-activesupport-2.3.5-1.fc13.noarch (fedora) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Note how it says 'rubygem-activesupport = 2.3.8' is required while rubygem-activesupport-2.3.8-1.fc13.noarch is installed. This is happening both on a stock F13 install and against mock setup to pull packages from Fedora and from a yum repo w/ the rubygem-activesupport-2.3.8-1.fc13.noarch package in it. What could be the cause of this problem? Is it something that can easily be resolved? (without using the --skip-broken flag preferably) rubygem-activesupport has recently had it's epoch bumped and i would imagine the requires in rubygem-activerecord simply hasn't been updated to match. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc: python2.7 for F14
On Tue, Jun 22, 2010 at 21:47, Thomas Spura toms...@fedoraproject.org wrote: Am Tue, 22 Jun 2010 11:02:40 -0400 schrieb David Malcolm dmalc...@redhat.com: Hmm, I just tried to write a little script for that (based on the one from above), but I had some problems with bodhi. e.g. 'repoquery --requires bodhi' shows nothing (because there are only subpackages and no main package). When calling 'repoquery --requires bodhi-client', there should be a python(abi), but there is only: /usr/bin/python koji python-fedora = 0.3.5 python-simplejson yum Is it perhaps because bodhi-client only has an executable (it is python code but not automatically compiled like libraries) so rpm doesn't automatically provide the requires? On a side note if it is not pre-compiled into bytecode then it probably doesn't make any difference whether it is recompiled. bodhi-server (same source package) does require python(abi) because it has libraries so in that particular case it would result in bodhi-client being rebuilt... (repoquery --whatrequires python(abi) | grep bodhi) -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hey Presto!
On Sat, Jun 12, 2010 at 16:35, Richard W.M. Jones rjo...@redhat.com wrote: On Sat, Jun 12, 2010 at 05:27:32PM +0200, drago01 wrote: We don't generate deltas for packages with a size of = 100MB which kind of makes it useless for this case but it seems that delta generation is to expensive to do for such large packages on the re-eng boxes. It's because the program that generates the delta RPMs reads the whole RPMs into memory, according to: http://lwn.net/Articles/329484/ Anyone know if there's a genuine reason why it does it, or if it's just a Simple Matter Of Programming to fix it? (And can point us to the actual bit of code that could be fixed ...) There was in fact a request for volunteers about a month ago: http://lists.fedoraproject.org/pipermail/devel/2010-May/136090.html -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Purging the F13 orphans
On Thu, Jan 28, 2010 at 01:03, Jesse Keating jkeat...@redhat.com wrote: Unblocked orphan moodbar I'll take this one. Amarok should be getting support for it again soon. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
