Re: installing 64-bit kernel on a 32-bit system (nouveau issue?)
On Sun, Jan 03, 2010 at 03:47:19PM +, David Woodhouse wrote: Obviously that doesn't count for the nVidia binary module, which doesn't exist for ppc64. And nouveau is relatively new and not currently being used in Fedora/PPC64 so I'm prepared to believe that their 'work in progress' API still has some issues in that area, as you suggest. Nouveau works fine with Fedora 12 for ppc64. I use it on an iMac G5 with an nVidia card for basic 2d output. I believe it also worked in F11. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Wed, Dec 23, 2009 at 08:50:11PM +0530, Rahul Sundaram wrote: On 12/22/2009 09:07 PM, Seth Vidal wrote: FWIW - I agree with both jesse and jarod. Official builds are from main branch. Anything built anywhere else will never be official. How about scratch builds? What about them? Scratch builds are not official by definition. They don't show up in repos, are only available for a couple weeks, etc. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, Dec 15, 2009 at 10:34:04AM +, Richard W.M. Jones wrote: On Tue, Dec 15, 2009 at 10:06:42AM +, Tim Waugh wrote: On Tue, 2009-12-15 at 09:49 +, Richard W.M. Jones wrote: Why not put everything in a single git repository? That would require every packager to check out the entire package set, all revisions, all branches. No thanks. Jesse can probably estimate for us how large this will be. I've found that git deals very well with large repositories that have lots of files and lots of history (kernel, qemu). And you only ever have to download it once, since you can use git fetch to make local working copies. A full git repo was 5.7G. I sure as hell don't want to pull that down when I'm only interested in a few packages. (The CVS repo is 16G on the server side if you are wondering.) josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Tue, Dec 15, 2009 at 05:55:19AM -0500, Jon Masters wrote: On Mon, 2009-12-14 at 20:22 -0800, Jesse Keating wrote: On Mon, 2009-12-14 at 19:21 -0800, Jesse Keating wrote: git clone git://publictest5.fedoraproject.org/git/pkgs/kernel This was the wrong path: git clone git://publictest5.fedoraproject.org/pkgs/kernel Can you explain the tags a little Jesse? e.g. F-12-split F-12-start Those are straight from CVS. I'm guessing they have to do with when we do a mass 'CVS branch' to create the dirs for the next release. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Reminder: Tomorrow is the last F10 updates push
Hi All, Just a friendly reminder that Dec 11 00:00:00 UTC is the cutoff for F10 updates submission. Ideally these would just be the final stable updates, as pushes to updates-testing would basically be stuck there forever. Please take a few moments to review your pending requests, add any final stable updates you'd like pushed, and clear out any update requests that don't make much sense for a soon to be EOL'd distro. josh ___ 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: Remove uses of %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} from specs
On Fri, Dec 04, 2009 at 07:04:12AM -0200, Itamar Reis Peixoto wrote: - glibc32, glibc64 (dead packages?) yes No. They are needed in the build system. They just havent been updated since FC6 or so. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
UPDATE: Final F-10 updates push date revised
On Tue, Nov 24, 2009 at 08:31:35PM -0500, Josh Boyer wrote: Hi All, Fedora 10 will go EOL on December 17th. The final day for updates to be submitted will be December 14th. Please make sure any final updates you want pushed to the F10 repos are submitted by this date. Due to the infrastructure outage that has been scheduled for this timeframe, the final F10 updates push has now been rescheduled for December 11th, 2009. Please make sure any final updates you want pushed to the F10 repos are submitted by the revised date of December 11th, 2009. Apologies for the confusion and change in schedule. We will work more closely with the Infrastructure team in the future to avoid a similar situation. josh ___ 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: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 09:00:53AM -0600, Jon Ciesla wrote: Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. The package set at release time is only interesting to historians. If any of them are really that bothered, I'm sure somebody can come up with a yum module which finds the oldest available version of a package in a repo. Matt Would not this also provide the minor added benefit that there could now be a drpm for the first update for a package? We already have that if the update is done after GA. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. And how do you propose to do that? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 03:44:08PM +, Matthew Booth wrote: On 02/12/09 15:26, Josh Boyer wrote: On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote: The separate updates directory has been a pain for as long as I've been using RHL/Fedora Core/Fedora. It means you have two places to look when searching for packages manually, and twice as much to configure when you're configuring yum. It has never benefitted me, or anybody I know, but it has caught me out on any number of occasions. What's more, nobody really seems to know why it's like that: it seems it's always been that way, and nobody ever bother to fix it. So lets fix it. And how do you propose to do that? Unfortunately I'm not intimately familiar with Fedora infrastructure under-the-hood. However, I would hope that, technically at least, it wouldn't be much more than a systematic removal of all updates repositories and redirecting files which would have gone into them into the main repositories instead. This stems from the observation that if you copied everything from the main repository into updates you would have created the repository which people unfamiliar with the history would expect. The infrastructure side of this, on the face of it, sounds very simple. What you describe is effectively how the development repository is built, so it's certainly a technical possibility. It does have implications though. Off the top of my head, I can think of: 1) Composing a new everything tree for updates would lead to larger compose times. That could possibly mean that getting updates out would take 1 day per 'push'. We've been trying to improve updates push times so it would be a bit detrimental to that goal. 2) There might be GPL compliance issues 3) You would still need an 'updates-testing' repository given that this is a supposedly stable release. So there is still going to be at least one additional repo regardless. However, other than 'browsing manually for packages', I'm not really sure what problem you are trying to solve by getting rid of the updates repository. It would seem like this has quite a bit of cost for relatively little to no real gain? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 12:01:49PM -0500, Casey Dahlin wrote: You owe me $5. It hasn't been a week and you haven't sent me your address. I did notice though, so keep up the good work ;) josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upcoming multi-day outage
On Wed, Dec 02, 2009 at 01:54:57AM +0100, Kevin Kofler wrote: Mike McGrath wrote: Starting on December 12th The Fedora Project will start to move several servers, disk trays and related hardware from our current hosting location to another. This move is planned to be completed on December 15th and will ultimately provide better hosting facilities and room for growth. Hmmm, how does this affect F10's EOL? Josh Boyer previously announced that the last day to file F10 updates in Bodhi will be December 14, that's now right within the outage window. Hm. Crap, you are correct. I had been thinking I said it was Dec 11 for several days now. I have no idea why, but we might seriously want to change the final F10 push date to Dec 11 to accommodate for the outage. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upcoming multi-day outage
On Tue, Dec 01, 2009 at 08:39:39PM -0500, Josh Boyer wrote: On Wed, Dec 02, 2009 at 01:54:57AM +0100, Kevin Kofler wrote: Mike McGrath wrote: Starting on December 12th The Fedora Project will start to move several servers, disk trays and related hardware from our current hosting location to another. This move is planned to be completed on December 15th and will ultimately provide better hosting facilities and room for growth. Hmmm, how does this affect F10's EOL? Josh Boyer previously announced that the last day to file F10 updates in Bodhi will be December 14, that's now right within the outage window. Hm. Crap, you are correct. I had been thinking I said it was Dec 11 for several days now. I have no idea why, but we might seriously want to change the final F10 push date to Dec 11 to accommodate for the outage. I've created https://fedorahosted.org/fesco/ticket/282 to track this. Normally a final push date doesn't require FESCo approval, but given that this is a change in the date that gives people less time I thought it might be prudent. (I'm going to ignore the fact that this is pushing updates to a release that will be EOL'd 6 days later.) Transparency and junk and stuff. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web
On Mon, Nov 30, 2009 at 02:54:22PM -0500, Casey Dahlin wrote: On 11/30/2009 01:05 PM, Dan Williams wrote: On Mon, 2009-11-30 at 10:05 +, Steven Whitehouse wrote: configuration, control, and monitoring. Yes, it's harder for experts to create a world-dominating robot with duct tape and bailing wire because most of the parts are already assembled, but for most people it provides a ready-to-use solution with great integration possibilities into your system environment. Then stop shipping the duct tape and bailing wire. If things outside of NM aren't going to work right or are going to break other stuff, get rid of them. The only reason not to is what if NM is broken, which is a moot point since offering a broken interface to use as a backup in case another interface is broken makes no sense. Stick with the one we're interested in supporting and deal with that set of bugs. I will send you a check for $5 if you configure your mailer to do line breaks properly. I am not joking. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12: NetworkManager-Firefox: Firefox is currently in offline mode and can't browse the Web
On Mon, Nov 30, 2009 at 03:28:55PM -0500, Casey Dahlin wrote: On 11/30/2009 03:26 PM, Josh Boyer wrote: On Mon, Nov 30, 2009 at 02:54:22PM -0500, Casey Dahlin wrote: On 11/30/2009 01:05 PM, Dan Williams wrote: On Mon, 2009-11-30 at 10:05 +, Steven Whitehouse wrote: configuration, control, and monitoring. Yes, it's harder for experts to create a world-dominating robot with duct tape and bailing wire because most of the parts are already assembled, but for most people it provides a ready-to-use solution with great integration possibilities into your system environment. Then stop shipping the duct tape and bailing wire. If things outside of NM aren't going to work right or are going to break other stuff, get rid of them. The only reason not to is what if NM is broken, which is a moot point since offering a broken interface to use as a backup in case another interface is broken makes no sense. Stick with the one we're interested in supporting and deal with that set of bugs. I will send you a check for $5 if you configure your mailer to do line breaks properly. I am not joking. josh *facepalm* T-bird strikes again. Can I claim the money if I just switch mailers, because I'm due. I'd count that. I'll watch for a week and if things seem better I'll send your check after you send me your address :). josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Thu, Nov 26, 2009 at 04:08:27PM +, Terry Barnaby wrote: As you obviously know tracking down and reporting bugs like these do take a lot of time and effort, quite often more than actually fixing them. At the moment with the frequency of Fedora releases and the lack of a push to testing and stability on this front I am not enthused, at the moment, with doing this and I suspect many others feel the same. I'm confused. You want Fedora to skip a release to focus on testing and fixing, and you have no plans to help and aren't enthusiastic about actually participating in the testing and fixing? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
On Thu, Nov 26, 2009 at 05:09:14PM +, Terry Barnaby wrote: On 11/26/2009 04:34 PM, Josh Boyer wrote: On Thu, Nov 26, 2009 at 04:08:27PM +, Terry Barnaby wrote: As you obviously know tracking down and reporting bugs like these do take a lot of time and effort, quite often more than actually fixing them. At the moment with the frequency of Fedora releases and the lack of a push to testing and stability on this front I am not enthused, at the moment, with doing this and I suspect many others feel the same. I'm confused. You want Fedora to skip a release to focus on testing and fixing, and you have no plans to help and aren't enthusiastic about actually participating in the testing and fixing? josh I really want to help and get a stable release and present bug reports and even fix them if I can. But, the current short term release schedule, and no focus on testing and fixing graphics issues, does not inspire me with confidence that a stable usable release will emerge. This makes it difficult for me to justify the effort. Convince me :) You're making some pretty bold accusations that there is no focus on testing and fixing graphics issues. Perhaps you could classify what you see as needing more testing and fixing instead of claiming there is none. I think that would be more accurate. As for convincing you, I think I'll refrain. I'd rather try and find someone that actually wants to help then spend time trying to talk to someone that has the nerve to propose canceling a release to do testing and fixing and then needs convincing to actually help with their own idea. Fedora needs less arm-chair quarterbacking. We have shit-tons of that already. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Final F-10 updates push
Hi All, Fedora 10 will go EOL on December 17th. The final day for updates to be submitted will be December 14th. Please make sure any final updates you want pushed to the F10 repos are submitted by this date. Thanks, josh ___ 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: rawhide report screwing up changelogs (was: Re: rawhide report: 20091123 changes)
On Mon, Nov 23, 2009 at 03:04:49PM +0100, Christoph Wickert wrote: Am Montag, den 23.11.2009, 14:56 +0100 schrieb Michael Schwendt: On Mon, 23 Nov 2009 14:39:28 +0100, Christoph wrote: When two builds of the same version are done on the same day, the rawhide report screws up the order of the changelog entries: Can this be fixed please? See Yum (yum-utils) upstream tickets #6 and #7 for the background. One part of the fix will require a hack in the handling of repo metadata stored in SQLite tables. Thanks for the info, Michael. Obviously it's not so trivial. BTW: Is there a place where I can look at the rawhide report script? https://fedorahosted.org/rel-eng/browser or git clone git://git.fedorahosted.org/git/releng josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: disallow broken push to updates?
On Fri, Nov 20, 2009 at 07:26:27AM -0500, Neal Becker wrote: Wouldn't it be a good idea to disallow a push to updates that has broken deps? Yes, it would. It's been discussed numerous times on this list an others. Summary: Needs hard thinking and people actually working on it. Not trivial. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Thu, Nov 19, 2009 at 03:49:29PM +0530, Rahul Sundaram wrote: On 11/19/2009 03:51 PM, Bojan Smojver wrote: On Thu, 2009-11-19 at 15:19 +0530, Rahul Sundaram wrote: IMO, it is not particularly useful in a already long thread to keep repeating the same points. Please stop patronising. It's annoying. Repeating the same thing over and over again is annoying as well. It's just noise instead of useful input. Both of you stop, now. josh (Hall Monitor hairy gorilla) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
On Thu, Nov 19, 2009 at 10:01:54PM -0500, Orcan Ogetbil wrote: Is RPM so hard to hack to work this around? There's many things that need to be changed in rpm but IMHO this isn't one of them. RPM produces predictable versioning. Hacking it up with special cases will lead nowhere but pain. Suppose we hack the RPM, such that right before RPM does the EVR check when updating a package, it will take the Release string and does a 's...@.fc\([0-9]\)@.f\1@' for both the old and the new package? Can you give me an example where this might lead to a problem? Yes. The part where you said hack the RPM. Carrying a Fedora specific hack like that in our RPM package for _no_ good reason seems pretty silly. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review request...
On Thu, Nov 19, 2009 at 02:23:22AM +0100, Kevin Kofler wrote: Michael Schwendt wrote: Many packagers don't know that maintaining a proper spec %changelog for relevant spec file changes and %release bumps are considered important during review already. Others add meaningless/dummy %changelog entries even in Fedora cvs. But that's a people issue that needs to be solved, not papered over in the name of being nice. Sadly, incompetence as in unfamiliarity with guidelines which are assumed to be prerequisites for proper packaging is growing in our ranks (both from new packagers and from people who ought to know better), something needs to be done about it. Such as? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review request...
On Tue, Nov 17, 2009 at 04:10:48PM -0700, Nathanael D. Noblet wrote: Hello, I just posted my first review request a few days ago. I think someone has been trying to help me through that process. Up to now I've felt like I've been following instructions. Could someone please review the information in the following (not necessarily review the request), to see if I've completely lost it and am not understanding what is being requested of me? I feel like I'm complying but got some odd message about not following instructions and so won't be helped. When I think I'm doing what they ask. Anyway a total packaging noob (for fedora atleast, we maintain a bunch of software in RPM format for CentOS and Fedora workstations inhouse). I've read the guidlines as best I can, and responded to requests on the review so I'm just wondering what I may be missing... He is wanting you to increment Release each time you change something, and post a URL to the updated SRPM. There is a language barrier issue here, and the reviewer could have had a bit more patience. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FF 3.5.5 for F-12
On Thu, Nov 12, 2009 at 11:48:53AM +1100, Bojan Smojver wrote: What happened to that? It's been built in Koji but it's not Rawhide or updates... It's there now. It will be included in the next push. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 staged for mirrors, rawhide moving on soon
On Thu, Nov 12, 2009 at 04:09:55PM -0800, H. Peter Anvin wrote: On 11/12/2009 02:52 PM, Jesse Keating wrote: I have just staged Fedora 12 for our mirrors. We're doing something a little different this time around. The releases/12/Everything/ tree will be open to the public as it gets staged. For heaven's sake, no! Don't you realize this means a ton of *users* will start to bog down the mirrors before the whole data set has propagated through the network? To do what? The Everything trees don't contain bootable media. They are just package repositories. The users on rawhide-f12 installs will hit that if they want to install packages, but that is no more load than them just hitting rawhide for packages. It's certainly possible that users will rsync the Everything tree, but they won't be able to do much with it. Is that the usecase you're worried about? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/iptstate/F-12 iptstate.spec,1.21,1.22
On Wed, Nov 11, 2009 at 12:53:35PM +, Christopher Brown wrote: Oops, too late! [ch...@yoda ~]$ sudo yum update Loaded plugins: presto, refresh-packagekit Setting up Update Process Resolving Dependencies -- Running transaction check --- Package dhclient.x86_64 12:4.1.0p1-4.fc11 set to be updated --- Package f-spot.x86_64 0:0.6.1.3-1.fc11 set to be updated --- Package f-spot-screensaver.x86_64 0:0.6.1.3-1.fc11 set to be updated -- Processing Dependency: libnetfilter_conntrack.so.1()(64bit) for package: iptstate-2.2.1-5.fc11.x86_64 --- Package libnetfilter_conntrack.x86_64 0:0.0.100-1.fc11 set to be updated --- Package libvorbis.x86_64 1:1.2.0-9.fc11 set to be updated --- Package libvorbis-devel.x86_64 1:1.2.0-9.fc11 set to be updated -- Finished Dependency Resolution iptstate-2.2.1-5.fc11.x86_64 from installed has depsolving problems -- Missing Dependency: libnetfilter_conntrack.so.1()(64bit) is needed by package iptstate-2.2.1-5.fc11.x86_64 (installed) Error: Missing Dependency: libnetfilter_conntrack.so.1()(64bit) is needed by package iptstate-2.2.1-5.fc11.x86_64 (installed) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest Is there any way to sanity-check pushed updates for depsolving capabilities? There is, but it hasn't been implemented yet and it would add quite a bit of time to the updates compose process. I plan on working on it RSN. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum repolist puzzle
On Sun, Nov 08, 2009 at 09:39:47PM -0600, Matt Domsch wrote: On Sat, Nov 07, 2009 at 03:28:35PM -0800, Jesse Keating wrote: On Sat, 2009-11-07 at 21:27 +0530, Rahul Sundaram wrote: https://fedorahosted.org/fedora-infrastructure/ticket/1800 We wanted to get some testing on the new updates repos before enabling them to the world, that's why they redirects haven't been updated. Hopefully we'll be good to go on those on Monday. If rel-eng wants to publish an 'empty' repo somewhere on the master mirror, I could have MM redirect the 'updates' repos to that empty repo until content is present for them. That would avoid having it look like both updates and fedora repos both have identical content. We have actual F12 updates pushed already. Why does it need to be an 'empty' repo? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Notice: Fedora 12 Tagging Status Update
On Wed, Oct 28, 2009 at 08:47:33AM +, Peter Robinson wrote: On Wed, Oct 28, 2009 at 5:40 AM, Bojan Smojver bo...@rexursive.com wrote: On Wed, 2009-10-21 at 16:18 -0400, Warren Togami wrote: 5) How many untagged packages are there? koji list-tagged --latest dist-f12-updates-candidate I ran this today (just for kicks). It gives back 323 packages. Even with false positives, it a large amount for zero day updates. This is just FYI. The original e-mail was about removing a backlog of 250+ packages waiting in Bodhi. I thought dist-f12-updates-candidate were packages that had been build for F-12 but had not yet been tagged. It doesn't necessarily mean they are going to be pushed into F-12. Correct. It's the default tag for any build done for F12. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Looking into LLVM
On Wed, Oct 28, 2009 at 11:26:54AM +0100, Kevin Kofler wrote: Eric Springer wrote: As for C++, I couldn't get some of my programs to compile as it seemed to spew at some of the template usage. Anyway it looks very promising and I look forward to using it in the future (especially with its non-nonsense licensing). So you don't consider it nonsense to allow proprietary software companies to steal all your code without giving anything back? They can even sell you back some trivially modified version of YOUR OWN code! Non-copyleft licenses suck. It's not stealing if you licensed it that way. Please avoid inflammatory language. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Nightly composes, rawhide or F12?
On Wed, Oct 28, 2009 at 01:12:03PM +0100, Andreas Tunek wrote: Are the nightly composes (such as this: http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ ) a build of what will become F12 or are they a build of rawhide? Both. Rawhide _is_ what will become F12. At least until it's switched from the dist-f12 to the dist-f13 tag. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Notice: Fedora 12 Tagging Status Update
On Wed, Oct 28, 2009 at 09:06:02PM +, Bojan Smojver wrote: Peter Robinson pbrobinson at gmail.com writes: I thought dist-f12-updates-candidate were packages that had been build for F-12 but had not yet been tagged. It doesn't necessarily mean they are going to be pushed into F-12. True, but there is no way to say right now which one would those be. So, if 50% of them are destined for updates (a pretty safe bet, I'd say), it's still a rather large number. We had around 400 0-day stable updates for F11 if I'm remembering correctly. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora PPC for oldworld Mac?
On Wed, Oct 28, 2009 at 06:17:31PM -0400, Tony Nelson wrote: Sorry to bug developers, but I didn't get any bites from PPC users on fedora-list. Does Fedora PPC work or install on oldworld PCI Macs, such as a beige G3 desktop? My impression is that no one has tried it on an oldworld No, it doesn't. The ppc specific release notes cover that here: http://docs.fedoraproject.org/release-notes/f11/en-US/index.html#sect-Release_Notes-Hardware_Requirements josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Notice: Fedora 12 Tagging Status Update
On Wed, Oct 28, 2009 at 10:52:13PM +, Bojan Smojver wrote: Josh Boyer jwboyer at gmail.com writes: We had around 400 0-day stable updates for F11 if I'm remembering correctly. Which makes me think - as many should be part of the release as possible, right? Yep. Which is why bodhi submission for F12 is currently disabled and we're encouraging people to submit tag requests. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: proposed macro deffinitions for F-13
On Tue, Oct 27, 2009 at 12:40:14PM -0500, Dennis Gilmore wrote:
+# arch macro for all supported 32 bit builds
+%32bitarches %{ix86} %{sparc32} %{arm} s390
+# arch macro for all supported 64 bit builds
+%64bitarches x86_64 %{sparc64} ia64 s390x %{alpha}
missing ppc and ppc64 respectively here, aren't you?
josh
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Looking into LLVM
On Mon, Oct 26, 2009 at 08:21:09PM +0530, Rahul Sundaram wrote: On 10/26/2009 08:21 PM, Adam Jackson wrote: Which affects who? koji certainly seems to be keeping up with the load. What I'm trying to pry out of you is what you'd be hoping to accomplish by using it. The answer so far seems to be I'd spend less time building things, at the cost of some unknown amount of time invested in fixing everything to build again. That doesn't sound like progress. Certainly status quo is easier. Less time building things is a obvious benefit. We don't know the cost unless we try. Doing a scratch build similar to the FTFBS rebuilds is definitely worth trying IMO. Arguing that we should never try at all doesn't seem appealing to me. Sounds like something you should start trying then. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Tag the F-12 updates?
On Tue, Oct 20, 2009 at 11:15:55PM -0400, Warren Togami wrote: sssd-0.6.1-2.fc12 skrooge-0.5.2-2.fc12 translate-toolkit-1.4.1-2.fc12 vhostmd-0.4-0.2.gitea2f772d.fc12 qtcurve-gtk2-0.69.0-1.fc12 qtcurve-kde4-0.69.0-1.fc12 gfs-ignacio-fonts-20090923-1.fc12 adf-tribun-fonts-1.13-1.fc12 gdl-0.9-0.7.rc3.fc12 Tagged these from the oldest bodhi requests. Need to sleep now. Will tag more tomorrow. I did quite a few more today and did some duplicate update cleanup. Will poke at this as I get time. For anyone else doing this work, please make sure to delete the updates after things are in f12-final. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 Security Updates not tagged (Re: Reminder: Tagging Policy for Fedora 12)
On Wed, Oct 21, 2009 at 01:11:23AM +0200, Christoph Wickert wrote: Am Dienstag, den 20.10.2009, 17:27 -0400 schrieb Warren Togami: Many Builds Not Tagged, but Probably Should Be == # koji list-tagged --latest dist-f12-updates-candidate This command shows over 400 packages are built for F-12 but not tagged for release. https://admin.fedoraproject.org/updates/F12/pending What really scares me is that there is a number of security updates in bodhi that don't have a tag request in trac. Are maintainers that careless? We don't want F12 released with 6 weeks old security bugs, so Please be careful with your terminology. There has been very little in the way of communication when it comes to F12 and updates, so it would not be a stretch at all if a large majority of maintainers thought the updates were getting mashed and repos were being published. Calling people careless without real cause is overly hostile and unhelpful. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: tagging of non critical path package into F-12?
On Thu, Oct 15, 2009 at 08:59:13AM +0100, Peter Robinson wrote: On Thu, Oct 15, 2009 at 8:55 AM, Conrad Meyer ceme...@u.washington.edu wrote: On Thursday 15 October 2009 12:51:28 am Peter Robinson wrote: Hi All, I presume that the reason that tagging requests aren't being done is due to the upcoming beta but is there a reason that non core or critical path packages can't be tagged in. I have a number of Moblin packages that fix various issues, in particular a rebuild of network-manager-netbook to fix networking against the latest NM build that hit just before the cut off. Given that none of these packages would be anywhere near any of the official spins is there any particular reason they can't be tagged in? Or if not when will they be reviewed? Peter Hi, If they're not on any of the official spins, what benefit does tagging them into dist-f12 provide over having them as updates? (Pushing updates is the suggested approach unless there's some reason it won't work in your case.) Because it allows me to test them as part of what will become the F-12 Moblin remix spin and allows others to test them rather than me having to setup a separate repository so I can test how the interact with the rest of the Moblin packages in Fedora. We're at RC2 of the Beta spin and not really tagging anything until Beta is out the door. After that, tag requests will pick back up so things can be included in the final release. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
bodhi changes
On Wed, Oct 14, 2009 at 07:33:45PM -0400, Luke Macken wrote: Before we go working on the karma system - is it doable to add some fields so we can denote critical path pkgs? If I know there is a place for the data, I can get you quick code to produce the list given any set of pkgs as soon as tomorrow. Hell, It is already written, iirc. It seems like critpath is more important in bodhi than karma, to me. Yeah, I agree critpath is more important at the moment. So we have a few options for where to throw this data. - We could add a new field to the bodhi Package SQLObject model This will entail DB schema changes. I've never altered bodhi's model below our DB before, but I think we could maybe just run an ALTER TABLE, and be all set. I'll have to test this first. bodhi v2.0 will use SQLAlchemy, so we'll have much better schema migration tools to use. - The quick and dirty solution would be to generate the critpath list and stuff it in bodhi's config file (like we do with packages that require a reboot). Or, if it's quick to generate, we could do it on startup. I'm not sure how large the list is so we'll have to see. - We could also have a flag in the pkgdb for critpath packages, which would be simple to query. It feels like the pkgdb should know about critpath packages. There are probably some other ways too, but once I see the code to generate I'm sure I can figure out how to get bodhi to use it. I think this would be really beneficial to No-Frozen-Rawhide as well, so that we could make Bodhi wait for a rel-eng/QA signoff on critpath packages before allowing them to be promoted during the devel cycle. Extending that to updates-testing - updates transition in released versions would be bonus as well. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Fri, Oct 09, 2009 at 02:08:41PM +0200, Andreas Tunek wrote: Maybe we could do a Phoronix live cd that includes the phoronix 3d tests and removes stuff like abiword and gnumeric? If the tests are in Fedora and you find someone willing to create the kickstart file for the spin, sure. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Oracle DB 4.8.24 released
On Tue, Oct 06, 2009 at 01:49:49PM +0200, Jindrich Novy wrote: Hi! Oracle released a new DB 4.8.24 recently and it is now ready to hit rawhide. Before that happens I want to let you test your package(s) You mean devel/dist-f13. Rawhide is still tracking dist-f12. /me tries to avoid confusion. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: bodhi question
On Mon, Oct 05, 2009 at 01:43:35PM +0300, Jonathan Dieter wrote: I've just built deltarpm-3.4-18.fc11 and pushed it to testing, because during the security fix in 3.4-17 (which is still in testing), we accidentally undid the split of drpmsync into a separate subpackage. I noticed that bodhi has an id (FEDORA-2009-10237) for 3.4-17. Is there some way to push that to 3.4-18? 3.4-18 will get it's own update id when it is pushed. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Mon, Oct 05, 2009 at 03:46:52PM +0200, Roman Rakus wrote: On 09/29/2009 04:48 PM, Josh Boyer wrote: On Tue, Sep 29, 2009 at 03:56:52PM +0200, Roman Rakus wrote: On 09/29/2009 12:31 AM, Jesse Keating wrote: On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: What do we have to do in order to build on PPC? Does it happen automagically? Once the ppc builders are setup and running smoothly, successful build requests on the primary arches will be tried on the secondary arches, which will include ppc. You'll need to do nothing specific on your end for this to happen. What about ppc specific packages (with exclusive arch set to ppc/ppc64)? What about them? They can exist in the CVS repo. You just won't be able to build them in koji for F-13 until a secondary arch instance is going. josh Any idea when I will be able to build them? Is there any bug report or I can build the for you for now if you just point out which ones you want built. The setup I have isn't publicly accessible yet (details on fedora-ppc list). something like it? No, no bug report per se. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Thu, Oct 01, 2009 at 09:34:38AM +, Matej Cepl wrote: Steve Dickson, Wed, 30 Sep 2009 15:41:51 -0400: Maybe removing the Final Development part and replace it with something like Beta Freeze (Bug Fixes ONLY) might have helped. Well my problem with the current state is that it is not Bug Fixes ONLY, we are getting to acks (Red Hat people know what I am talking about) by somebody who is neither PM, nor developer, nor QA. Could you elaborate there? Rel-eng is comprised of several people with varying backgrounds, and there are certianly developers and QA oriented people in that group... Oh well, at least finally I know for whom not to vote in the elections. Rel-eng isn't elected... again confused. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Thu, Oct 01, 2009 at 07:45:22AM -0700, Jesse Keating wrote: I know that last week several ppc people (IBM, etc) expressed alarm and concern about the demotion of ppc to a secondary arch. Most of those people I pointed at Bill and Jesse who were staffing the fedora booth. Did we get any positive feedback/offers of help from them? No. They heard that here would be a secondary arch effort and seemed to think oh, they will fix it for us. Seems to be the running theme. People want ppc to stick around but nobody wants to work on it. That's why secondary arch seems right. People who care can work on it but lack of care won't hold Fedora back. Keep in mind that many upstreams (most?) don't have access or care about ppc. In the nonserver world ppc is dead. s/nonserver/desktop Lots of embedded PPC still out there (yes, running Linux). josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Thu, Oct 01, 2009 at 11:10:51AM -0400, Bill Nottingham wrote: Jeff Garzik (jgar...@pobox.com) said: But you're dodging the larger point -- Fedora has, de facto, demoted big endian support in its entirety to a second-hand effort, rather than distributed the workload much more widely. Given M package maintainers and N secondary-platform volunteers, it is clear M N by orders of magnitude. Sure, but it's not like M, in a sizeable percentage of cases, is particularly useful in this regard. In any case: - ppc has no one looking at the actual bugs in any case. LiveCDs have been broken on PPC for *years*, for example, and no one cares. Graphics drivers have been broken on PPC throughout the F11 release and no one cares. Going to counter this one. I look at bugs. I know David look(s/ed) at bugs. We just can't get to all of them. This echos your point about community, but I didn't want you to get away with saying that nobody is trying. LiveCDs are pretty useless because demand for them is non-existent. So yes, it is broken and I don't think it works even after some of the recent fixes I sent to livecd-tools. So yeah, no one cares on that. I know I don't, mostly because I'm actually busy with the other stuff. I file bugs on graphics drivers regularly. I know Dave A has been pretty great about helping me get him info to fix the Radeon stuff. I have a bug opened against nouveau right now as well and Ben has been helpful there too (need to get back to that.) If you mean some other driver, then yeah maybe. I can only test/file bugs on hardware I have. that; well, I don't think Fedora necessarily should be a charity for cases there's no community for. s/no/a small. Pretending we don't exist isn't exactly kind, but I will admit the few of us that participate are limited in time and resources. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: Scoping: - this work would target Fedora 13. I'd avoid pushing it into F12 until it's proven safe to do so I'm going to think on the overall proposal more, but I very very very much wish this sentence said I will not push this into F12 at all. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Thu, Oct 01, 2009 at 06:42:08PM +0100, Mat Booth wrote:
Nice bug; this one is my favourite:
https://fedorahosted.org/rel-eng/ticket/1308 -- PPC64 noarch builds
don't expand %{_libdir} to the correct place.
I'm pretty sure I have seen 'noarch builds shouldn't be using %{_libdir}'
repeated several times.
josh
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Fri, Oct 02, 2009 at 12:53:21AM +0200, Kevin Kofler wrote: John Poelstra wrote: The current FESCo might also want to consider taking more of a leadership role in monitoring the release processes, tracking the schedule, and evaluating the quality of the release under development and our ability to release on time. As the group responsible for guiding the technical direction of our releases I think this is something they should be more involved in. I'd be glad to help gather data they might need to do this and there might be others who would be willing to help too. I'm suggesting more proactive leadership from FESCo and clear initiatives to take Fedora to the next level versus only being responsible for approving features, proven packagers, and policy matters. And when should we find the time for that? Our meetings already usually take 2 hours, and during the rest of the week, we have other things to do as How about starting now? Our last two meetings took about 20 min combined. We're through the Feature process mostly, and we're entering the part of the development cycle that people need help with, reminders for, planning, etc. I actually agree with some of what John said. I had a discussion with someone earlier today that echoed many of those sentiments. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Buyer Beware: A Major Change in NFS is about to happen
On Wed, Sep 30, 2009 at 08:36:54AM +, Matej Cepl wrote:
Jesse Keating, Tue, 29 Sep 2009 23:45:08 -0700:
Right, I've always taken it to mean Our experimental code is in, and
we're ready to take end user testing feedback on it which is different
from our code is in, but not really done, and we don't care if it's
broken because we're going to re-write it again in a week.
Except this is not exactly correct ... this is not beta by industry
standards, but release candidate which will be left rottening for two
months before released and found completely useless (because 0day updates
will be probably again bigger than amount of packages people usually
install).
Case in question ... I am not allowed to fix bug https://
bugzilla.redhat.com/show_bug.cgi?id=520998, which I have filed some time
ago, watched that maintainer didn't do anything to it, finally after
discussing it with OpenSSL maintainer I have decided that upgrading to
the current stable version of the package makes a lot of sense, fixed the
spec so that it builds, build it ... and found that I cannot push it to
the bodhi, because I would need to humbly petition FESCO for permission
to fix a bug. And no I cannot swear that it won't break anything (it is
not my package after all), so I will just not bother, and let is slip for
anybody who cares to take care of it.
Er... your package is already in rawhide. You don't need to push it as a
bodhi update. So your use case is totally bogus because the change you
wanted to get into F-12 is already there:
[jwbo...@hansolo packages]$ koji latest-pkg dist-f12 pyOpenSSL
Build Tag Built by
pyOpenSSL-0.9-1.fc12 dist-f12 mcepl
[jwbo...@hansolo packages]$ koji latest-pkg f12-beta pyOpenSSL
Build Tag Built by
pyOpenSSL-0.9-1.fc12 f12-beta mcepl
Do we have somewhere real Rawhide (i.e., dist-f13) repos available now
when dist-f12 has been released? I don't want to upgrade from koji.
I have no idea what you are asking here.
josh
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Wed, Sep 30, 2009 at 07:02:08PM -0400, Tom Lane wrote: Jeff Garzik jgar...@pobox.com writes: The lack of big endian builds by default is a notable loss, and will lead to a decline in software quality. I think this is a net-negative for Fedora. I think the same, but it's getting harder to find PPC machines. s/machines/desktop machines. You can find all kinds of PPC machines, just typically not in desktop form. The only new one that I am aware of is the fixstars.us Powerstation. Is there another big-endian platform that is on the upswing? Not to my knowledge, but I haven't paid much attention to that. We do have secondary arches at least building, like sparc and s390x. I have a ppc effort 1/2 going. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Tue, Sep 29, 2009 at 03:56:52PM +0200, Roman Rakus wrote: On 09/29/2009 12:31 AM, Jesse Keating wrote: On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: What do we have to do in order to build on PPC? Does it happen automagically? Once the ppc builders are setup and running smoothly, successful build requests on the primary arches will be tried on the secondary arches, which will include ppc. You'll need to do nothing specific on your end for this to happen. What about ppc specific packages (with exclusive arch set to ppc/ppc64)? What about them? They can exist in the CVS repo. You just won't be able to build them in koji for F-13 until a secondary arch instance is going. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads up: net-snmp soname bump in rawhide
On Tue, Sep 29, 2009 at 05:16:13PM +0200, Jan Safranek wrote: Net-SNMP 5.5 is heading to rawhide (i.e. Fedora 13). The update comes Rawhide is still based on dist-f12. We have no cute name for dist-f13. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On Mon, Sep 28, 2009 at 11:33:37PM +0100, Peter Robinson wrote: On Mon, Sep 28, 2009 at 11:31 PM, Jesse Keating jkeat...@redhat.com wrote: On Mon, 2009-09-28 at 23:00 +0100, Mat Booth wrote: What do we have to do in order to build on PPC? Does it happen automagically? Once the ppc builders are setup and running smoothly, successful build requests on the primary arches will be tried on the secondary arches, which will include ppc. You'll need to do nothing specific on your end for this to happen. Will (does?) the same happen for the other secondary arches like sparc or arm? The s390x and sparc ports use koji-shadow to my knowledge. This goes through and finds builds in the primary koji instance that are missing in the secondary arch instance and rebuilds them for the secondary arch. If a public ppc koji instance gets setup, it will use the same tools. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
On Thu, Sep 24, 2009 at 04:25:46PM -0400, Matthias Clasen wrote: On Thu, 2009-09-24 at 16:22 -0400, Seth Vidal wrote: I don't consider the single command a significant barrier, either way. Maybe not for people who maintain yum... I get the feeling that either 1) you think our users have no idea what the command line is or 2) hate the command line with a passion or 3) don't believe there is no suitable graphical way to install this or generally that you find our users to be unintelligent enough to work out how to get a piece of software onto their systems. I find that to be rather wrong, and I don't think you have to be the maintainer of yum to understand how to install something. Now, I could be very very wrong in these feelings and if so, great. But you didn't reply with much so I had to work with what I had, inferences and all. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
ascii mergerepo error in local koji instance
I'm seeing this error when trying to do a newRepo task on my local
koji server, using rawhide as an external repo:
2101/14674 - python-decoratortools-1.7-4.fc12.noarch
2102/14674 - ruby-atk-0.19.1-2.fc12.ppc
Traceback (most recent call last):
File /usr/libexec/kojid/mergerepos, line 241, in module
main(sys.argv[1:])
File /usr/libexec/kojid/mergerepos, line 236, in main
merge.write_metadata()
File /usr/libexec/kojid/mergerepos, line 216, in write_metadata
mdgen.doPkgMetadata()
File /usr/lib/python2.6/site-packages/createrepo/__init__.py, line
364, in doPkgMetadata
self.writeMetadataDocs(packages)
File /usr/lib/python2.6/site-packages/createrepo/__init__.py, line
527, in writeMetadataDocs
self.primaryfile.write(po.xml_dump_primary_metadata())
File /usr/lib/python2.6/site-packages/yum/packages.py, line 1015,
in xml_dump_primary_metadata
msg += misc.to_unicode(self._dump_format_items())
File /usr/lib/python2.6/site-packages/yum/packages.py, line 894,
in _dump_format_items
msg += self._dump_pco('provides')
File /usr/lib/python2.6/site-packages/yum/packages.py, line 919,
in _dump_pco
msg += pcostring
UnicodeDecodeError: 'ascii' codec can't decode byte 0xec in position
28: ordinal not in range(128)
[r...@koji 97]#
The builders and hub are all running a fully updated F11. This is the
first newRepo task after the repo addition, so it's all purely from
rawhide.
I see that there was a similar report of this in the past, but I don't
see a resolution? Is there a patch I need to apply, or do I have to
block the erroring packages in koji, or?
Help would be appreciated. (I'm also confused why the main koji
instance isn't hitting this).
josh
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Deltarpm xz problem with PPC generated rpms?
On Tue, Sep 15, 2009 at 10:38:32AM -0700, Adam Williamson wrote: On Tue, 2009-09-15 at 01:27 -0400, Michel Alexandre Salim wrote: On Mon, Sep 14, 2009 at 1:28 PM, Seth Vidal skvi...@fedoraproject.org wrote: Boy, I'm so glad we decided to jump onto the xz ship. I take it it's too late to back out and stick to bzip2 until the situation stabilizes? I take it whatever solution ends up in F-12 is likely to be the one used by RHEL 6 when it comes out next spring. Between using more space on a distribution that's smaller than Fedora anyway, and having a rather uncertain compression tool... It's only 'uncertain' in the sense that it's not committed to always producing the same archive in future versions or on different architectures. As has been pointed out, this only has any relevance when Simple solution: Don't build the noarch RPMs on ppc. Why?: Because F12 is the last release that will have ppc be a primary arch and it is fairly arguable that you want to optimize for the future case going forward anyway. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Deltarpm xz problem with PPC generated rpms?
On Tue, Sep 15, 2009 at 01:56:55PM -0400, Bill Nottingham wrote: Josh Boyer (jwbo...@gmail.com) said: Simple solution: Don't build the noarch RPMs on ppc. Why?: Because F12 is the last release that will have ppc be a primary arch and it is fairly arguable that you want to optimize for the future case going forward anyway. I'm not sure how 'simple' that is in the koji configuration. It will have to be done anyway, yes? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH] update f12 fcoe related kernel code
On Tue, Sep 15, 2009 at 01:45:36PM -0500, Mike Christie wrote: Dave Jones wrote: On Tue, Sep 15, 2009 at 01:05:53PM -0500, Mike Christie wrote: Hi, Sorry for the large patch. I was not sure how I should do this. I am trying to update the fcoe related (fcoe, libfc, ixgbe, fnic and dcb) kernel code that is going into fedora 12. The attached patch updates the fedora 12 kernel to what is in the SCSI maintainer and network maintainer's trees for 2.6.32-rc1. For scsi this is the scsi-misc tree http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=summary and for networking this is the net-next tree http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=summary. This scares me. We're shipping 2.6.31 because we can't justify the risk of shipping rc code in a final release. With huge amounts of change like this, we're essentially doing the same thing. There is actually going to be more patches :( There are maybe 50+ other patches floating around the linux scsi and fcoe lists that are not yet in the scsi maintainer's tree. I was going to send those patches once the review for those other patches was done upstream and the scsi maintainer had taken them. The kernel has already branched for F-12. From a rel-eng standpoint, this looks like a poor idea. Particularly, as Dave points out, there are lots of changes all over the place and you said there are even more not merged yet. I'm pretty sure rel-eng is not going to be happy with this at all, and I suggest punting it to F-13. RHEL is outside of the scope of the Fedora kernel. josh ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Wed, Sep 09, 2009 at 06:35:09AM -0400, Josh Boyer wrote: On Tue, Sep 08, 2009 at 10:46:26PM -0300, Alexandre Oliva wrote: Jakub built gcc-4.4.1-10 earlier today, with a new feature that generates much better debug information in optimized programs. The feature has been under development for a couple of years, and it's recently been accepted into GCC, for GCC 4.5. We've backported it for Fedora 12. Why are you backporting something like this from a non-released compiler into F12 _after_ Alpha and particularly _after_ the mass rebuild? No response? None? I mean, I'm not asking for much. All I want is an explanation as to why this _has_ to be in F12 and can't be rolled into F13 instead. At first glance, it would make more sense to let the feature get some testing in GCC mainline before we just backport it to Fedora users, so putting it in F13 seems better to me. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Thu, Sep 10, 2009 at 01:43:26PM +0200, Jakub Jelinek wrote: On Thu, Sep 10, 2009 at 07:32:07AM -0400, Josh Boyer wrote: Why are you backporting something like this from a non-released compiler into F12 _after_ Alpha and particularly _after_ the mass rebuild? No response? None? I mean, I'm not asking for much. All I want is an explanation as to why this _has_ to be in F12 and can't be rolled into F13 instead. At first glance, it would make more sense to let the feature get some testing in GCC mainline before we just backport it to Fedora users, so putting it in F13 seems better to me. Because we really want it in F12, to make e.g. systemtap usable. It got quite a lot of testing already and has been in development for 2 years. Originally it was expected to be merged early in the summer, testing rawhide gccs have been prepared already in early August. So systemtap wasn't considered usable before this? I am not a GCC expert, but I can see how this feature would help it. But it was surely usable before this, right? There were so far 3 bugreports related to this, 2 of them are already fixed, LLVM build is just needing too much memory on completely insane source (people calling functions with 1375 arguments, 685 out of it are classes with non-trivial ctors passed by value, deserve some punishment) and Alex will look at it today. I have every confidence that you and Alex will fix all the bugs reported. I also think the code itself is likely fairly stable, and may very well provide some usability wins overall. Your competence as a developer is not, nor ever was, in question so please don't misunderstand my questioning. The largest problem I have with all this is the fact that the release guidelines that everyone else has to follow don't appear to be followed at all in this case. You're introducing a backported feature into a critical path package after Feature freeze, and after a mass-rebuild which would have arguably helped test the hell out of this. Any other maintainer would have to get an exception from rel-eng and/or FESCo in order to do something like this. I don't see why the same requirements don't apply here. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GCC var-tracking-assignments: testing and bug reports appreciated
On Tue, Sep 08, 2009 at 10:46:26PM -0300, Alexandre Oliva wrote: Jakub built gcc-4.4.1-10 earlier today, with a new feature that generates much better debug information in optimized programs. The feature has been under development for a couple of years, and it's recently been accepted into GCC, for GCC 4.5. We've backported it for Fedora 12. Why are you backporting something like this from a non-released compiler into F12 _after_ Alpha and particularly _after_ the mass rebuild? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Compiling kernel-2.6.30.5-43.fc11.src.rpm
On Mon, Sep 07, 2009 at 02:27:24PM -0700, Markus Kesaromous wrote: Still not fixed: arch/x86/kernel/pvclock.c:63:7: warning: __x86_64__ is not defined Please stop posting such messages here. josh ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Compiling kernel-2.6.30.5-43.fc11.src.rpm
Still not fixed: arch/x86/kernel/pvclock.c:63:7: warning: __x86_64__ is not defined Please stop posting such messages here. josh Why? Because this is not bugzilla. Posting emails here on issues you've already reported and are applicable to upstream isn't really going to do anything. Bugs (like your radeon issue) should be reported in bugzilla. josh ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Release F11 stuck at 2.6.29 ???
On Fri, Aug 28, 2009 at 01:07:03PM -0700, Markus Kesaromous wrote: When will 2.6.30 and 2.6.31 be released as updates for F11 Why is F11 being kept at 2.6.29? That is what F11 was initially released at, and it is still stuck at this release? I would like to know if and when 2.6.3X will be released as an updated for F11. If you just can't wait, you could always try rawhide. It has the latest kernel available. josh ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Heads up: Extra diligence with bodhi updates required
Hi, Recently the mechansim bodhi uses to obsolete older updates was disabled due to it doing the wrong thing in certain cases. However, that means it won't obsolete the older updates for the cases it used to get right. This can lead to having multiple updates submitted for a single target at the same time. I ask that you spend a few minutes verifying your update push requests to make sure you don't have this happening. I've already had to revoke a few requests due to newer updates being submitted at the same time. The general rule when this is found is: Newest update requested wins. Thanks in advance for your diligence and patience. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies in Fedora 11 - 2009-08-20
On Fri, Aug 21, 2009 at 08:13:34PM +0200, Kevin Kofler wrote: drago01 wrote: Sorry but the fail here is 100% on bodhi's side , why does a single package obsolete a complete group update? That is just broken, and this example clearly showed it. It's broken (we've had some fun with that with the KDE grouped updates too, we learned to be careful about what we push when), but a maintainer should know how to use our tools, which includes being aware of their limitations. I use bodhi every day. I have yet to find all it's limitations. There are known limitations that aren't even documented. I think it's a bit far reaching to say that maintainers should just know, when there is no good way for them to know without either reading the code or excessive use. Double-checking things both before and after filing an update (e.g. checking https://admin.fedoraproject.org/updates/thepackageyoureabouttopushanupdatefor before filing the new update request) definitely can't hurt (I always do that), and it will help avoiding issues you don't even know about, or at least catching them earlier than 2 months after the fact (as happened here). That's decent advice, but it will not catch quite a number of the problems that we see come up. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies in Fedora 11 - 2009-08-20
On Thu, Aug 20, 2009 at 10:19:39AM +0100, Peter Robinson wrote: On Thu, Aug 20, 2009 at 10:14 AM, Michael Schwendtmschwe...@gmail.com wrote: == The results in this summary consider Test Updates! == Summary of broken packages (by src.rpm name): beagle bmpx clipsmm f-spot fedora-business-cards kdeedu openmpi openvrml ppl R-RScaLAPACK rubygem-main rubygem-rails scheme2js tomboy Is it just me or are there some packages that seem to be eternally on this list? beage/f-spot/tomboy never seem to go anywhere. They're eternally broken on ppc64. Mostly due to Mono being broken on ppc64. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies in Fedora 11 - 2009-08-20
On Thu, Aug 20, 2009 at 01:31:47PM +0200, Michael Schwendt wrote: On Thu, 20 Aug 2009 07:18:50 -0400, Josh wrote: On Thu, Aug 20, 2009 at 10:19:39AM +0100, Peter Robinson wrote: On Thu, Aug 20, 2009 at 10:14 AM, Michael Schwendt wrote: == The results in this summary consider Test Updates! == Summary of broken packages (by src.rpm name): beagle bmpx clipsmm f-spot fedora-business-cards kdeedu openmpi openvrml ppl R-RScaLAPACK rubygem-main rubygem-rails scheme2js tomboy Is it just me or are there some packages that seem to be eternally on this list? beage/f-spot/tomboy never seem to go anywhere. They're eternally broken on ppc64. Mostly due to Mono being broken on ppc64. Really? Then why has somebody added ppc64 to the ExclusiveArch list for many but not all of the Mono packages? I think that spec files from F-12 devel have been copied to F-11 without making sure that Mono has been built for ppc64 there. That could very well be. I also know that there was some work done during F11 development to make Mono work on ppc64 and it did for a while. Yet an update seems to have hose that? If people need access to a ppc64 box to fix Mono issues, just let me know. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firmware licence question
On Thu, Aug 20, 2009 at 03:51:04PM +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: I very want see this driver in Fedora: http://dag.wieers.com/rpm/packages/dkms-tiacx/ This is free and even packaged, so no problem there... May be except what it dkms? But it have not kernel modules (I known what it is not permitted) and built automatically on install phase. Fedora does not allow stand-alone kernel module packages. This would need to be included in the kernel RPM itself. The best way to get that to happen is to get the driver into the upstream kernel. But it depend on http://dag.wieers.com/rpm/packages/acx111-firmware/ and http://dag.wieers.com/rpm/packages/acx100-firmware/ binary firmware images. Unless you can find the actual license for the firmware in question, those packages don't look acceptable to me. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
No more Alpha tag requests
A general reminder. As we are out of Alpha freeze now, that means we are not taking tag requests for F12 Alpha any longer. The package set for Alpha has been finalized. Thanks josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Orphaning packages
I've orphaned the following packages in pkgdb: gquilt quilt jfsutils josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090819 changes
On Wed, Aug 19, 2009 at 10:49:22AM -0400, Steve Grubb wrote: On Wednesday 19 August 2009 08:40:52 am Rawhide Report wrote: Compose started at Wed Aug 19 06:15:07 UTC 2009 New package Does this large list mean that the Alpha freeze is lifted? Yes. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates lacking descriptions
On Thu, Aug 13, 2009 at 09:32:24PM +0530, Rahul Sundaram wrote: On 08/13/2009 09:29 PM, Michael Schwendt wrote: On Thu, 13 Aug 2009 15:53:57 +0200, Kevin wrote: Ralf Corsepius wrote: With you folks demanding more explicit changelogs you are rudestly pushing around package maintainers and force them to waste time to fullfill your solely burecratic demands. You're free to leave. Won't speak for Ralf, but I consider such a comment as insolent. It's not how fellow Fedora contributors should communicate with eachother. Certainly not in public messages. True. Ralf does that in private and public all the time too however. Two wrongs does not make a right. Everyone needs to stop the back and forth on this now. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Soname bump for openssl
On Wed, Aug 12, 2009 at 11:45:50AM +0200, Tomas Mraz wrote: Hi all, I'd like to upgrade OpenSSL to 1.0.0-beta3 version just after the F12 Alpha release. I asked rel-eng to create a custom build target for the rebuild so we can avoid shipping the symlink hacks in rawhide. A few questions: Why a beta version? Is there a good chance the final upstream release will be done before F12 GAs? Will the beta nature of the release cause lots of potential rebuilds as you update it with newer betas? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Soname bump for openssl
On Wed, Aug 12, 2009 at 03:38:27PM +0200, Tomas Mraz wrote: On Wed, 2009-08-12 at 07:36 -0400, Josh Boyer wrote: On Wed, Aug 12, 2009 at 11:45:50AM +0200, Tomas Mraz wrote: Hi all, I'd like to upgrade OpenSSL to 1.0.0-beta3 version just after the F12 Alpha release. I asked rel-eng to create a custom build target for the rebuild so we can avoid shipping the symlink hacks in rawhide. A few questions: Why a beta version? Because the changes on the 1.0.0 branch will not break ABI as they will be bugfix-only and it will allow us to upgrade to 1.0.0 later. Thanks for the quick response! One more question: Are we planning for a compat- package for the current OpenSSL version? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Fri, Aug 07, 2009 at 11:31:26PM -0700, Adam Williamson wrote: On Sat, 2009-08-08 at 07:12 +0200, Kevin Kofler wrote: Adam Williamson wrote: Er, the _topic_ of this thread is Fedora 12 Features Proposed for Removal. The email doesn't say anything about 'if you fix this stuff before the meeting it'll be fine' (though that may be the actual case), and the amount of notice given is a princely two days, which isn't that long for anyone to make changes. The way things are worded are clearly We're going to drop these features, not please check this, okay? Please? Thanks! FYI, we voted against dropping most of that stuff. They were just proposed for dropping. Sure, but that was sort of my point. What was actually achieved by 'proposing' features to be dropped that everyone knew wouldn't really be dropped, and then having a meeting to confirm that they wouldn't be? It's called transparency and accountability. Some call it beauracracy. See, FESCo used to just make these 'obvious' decisions at times, and we were yelled at for not having a definable process and not being transparent. Repeatedly. We have a Feature process now, and while I'm not a huge fan of process, this one is run very well by the Feature Wrangler. It treats them all the same, they have to all follow the same criteria regardless of how 'obvious' some of the decisions are. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Sat, Aug 08, 2009 at 06:47:55AM -0700, Adam Williamson wrote: On Sat, 2009-08-08 at 06:55 -0400, Josh Boyer wrote: We have a Feature process now, and while I'm not a huge fan of process, this one is run very well by the Feature Wrangler. It treats them all the same, they have to all follow the same criteria regardless of how 'obvious' some of the decisions are. ...except I pointed out that we do version bumps of everything in the distro from one release to the next (more or less), but only a couple of them are flagged up as features. To which it was replied that this was primarily for PR purposes. To which I objected that it was silly to attach this kind of bureaucracy to something which was only happening for PR reasons. What does any of that have to do with the email I replied to? You said it was silly to have a meeting to follow through with the process when everyone knew what the result would be, and I replied why we do that. Now you circle back on some other thing? I'm pretty sure you're just arguing for arguing's sake now so I'll just bow out and stop wasting my time. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: pulseaudio 0.9.15 for F10?
On Sat, Aug 08, 2009 at 01:02:15PM -0400, Mail Lists wrote: On 08/08/2009 12:56 PM, Kevin Kofler wrote: Lennart Poettering wrote: Upgrading PA like this involves big changes and does not qualify as either security nor as small other bug fixes. Well, then you could backport at least the bugfixes. It's pretty bad that known bugs, even pretty bad ones, are staying unfixed on the still-supported F10. Kevin Kofler Frankly talking to a door and expecting an answer is not fruitful. Vent by all means .. hope you feel better ... but dont assume rational response from a door. Intentional trolling on this list is not tolerated. Please refrain from doing so in the future. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Wed, Aug 05, 2009 at 10:59:25PM -0700, Adam Williamson wrote: On Thu, 2009-08-06 at 05:37 +0200, Kevin Kofler wrote: Adam Williamson wrote: I probably couldn't do much justice to a comprehensive plan as I have insufficient knowledge of how the buildsystem works. I was acting at a higher level - just trying to point out that it's essentially doomed to try and please everyone with a single update repository, that's not an argument anyone can win. Either the 'we want stable updates' camp or the 'we want shiny new stuff' camp is going to be disappointed. The problem is that your solution doubles maintainer and rel-eng workload. I think we really don't have the resources for that. Please don't personalize things. It's not 'mine', and it's not really a solution. I'm simply pointing out that it's literally impossible to satisfy both possible update policies with a single unitary repository. You are under the impression that we have an update policy at all. We don't. So we have nothing to satisfy, which makes it very possible. We either have to make it clear which policy we use and which policy we don't, and hence which theoretical user base we are not targeting, or take on extra work and try to satisfy both. I am not declaring myself in Actually, we could do nothing and be just fine. Let the users decide if and when and what they want to update. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090806 changes
On Thu, Aug 06, 2009 at 02:33:58PM +0100, Peter Robinson wrote: This looks somewhat truncated. I have at least one new package that should be in the list :-( We're in Freeze. If you didn't request a freeze tag, it won't get into the rawhide compose. Of course! I thought the alpha was going to be a running snapshot of rawhide without a freeze this time round, or did that not make it through the final hurdles? No-Frozen-Rawhide was deferred to Fedora 13. Another thing to keep in mind is that F12 Alpha is what we used to call Beta. Confusion abound! josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, Aug 06, 2009 at 09:43:03AM -0700, Adam Williamson wrote: On Thu, 2009-08-06 at 09:24 -0400, Josh Boyer wrote: We either have to make it clear which policy we use and which policy we don't, and hence which theoretical user base we are not targeting, or take on extra work and try to satisfy both. I am not declaring myself in Actually, we could do nothing and be just fine. Let the users decide if and when and what they want to update. Doing nothing is an implicit choice in favour of the adventurous option, with the disadvantage that we don't come out clearly and say it. Um, ok. I disagree, but hey we'll just go in circles. It's rather hard to choose 'if and when and what' you want to update on a system that you only really talk to once a week that otherwise just sits there and does its job. For instance - a server, or a home theater box. I have both of these types of system. They're set to auto-update once a day, I don't spend my life logging into them by SSH, poring over Personally, I don't care about meeting the needs of someone that wants to set their machine to auto-update so they can have warm fuzzies about it. We don't guarantee anything, we don't have official support contracts for Fedora, and as of right now we don't have the maintainer/QA/rel-eng manpower to even come close to making it safe to auto-update 100% of the time. See what I mean? No choice is a choice. Sure. It's called 'sticking with the status quo'. Which isn't all or nothing as you seem to want to paint it. It's left in the hands of the maintainers. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Thu, Aug 06, 2009 at 11:39:16AM -0700, Adam Williamson wrote: On Thu, 2009-08-06 at 20:00 +0200, Kevin Kofler wrote: Adam Williamson wrote: As I said, the particular code isn't the issue. We ship a kernel API. At present, we consider it fine to break that API in stable releases. This is not something that would be considered 'stable' in a traditional definition. The kernel's just an example, we do the same kind of non-stable updates all over the place. That's the issue I'm trying to talk about, not just the specific example I happened to mention. Please don't bog down in specifics. Well, the specifics are that packages both within Fedora and in third-party repositories which depend on the bumped API usually get rebuilt (and patched if needed) fairly quickly, normally before the update even goes stable. Of course that's only possible for software which can be patched, which is just another example of how binary-only software is broken by design. But we're providing an operating system, not just a bunch of packages. What if some group's written their own kernel module for their own purposes, rolled it out to all their systems, and doesn't expect an official update to make them re-write it? Same question for KDE - If they don't expect that, they have no idea what Fedora is or how it works. We don't care about out of tree drivers. someone writes a tool for their group based on some KDE libraries, doesn't expect an update to come along and do a major KDE version bump and break some interface the tool relied on...reducing the question to 'are all the packages we care about okay' is, again, excluding some use cases, i.e. defining an identity for Fedora. You keep making strawman arguments that liken Fedora to something more akin to RHEL or Ubuntu LTS. We aren't either of those. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Thu, Aug 06, 2009 at 11:41:20AM -0700, Adam Williamson wrote: On Thu, 2009-08-06 at 11:14 -0700, Jesse Keating wrote: On Thu, 2009-08-06 at 10:37 -0700, Adam Williamson wrote: I think the correct question here is why has a perfectly routine version bump for components included in Fedora been submitted as a 'feature'? If GNOME 2.28 is a feature, isn't KDE 4.3 a feature (oh, I see it is too, lovely...), kernel 2.6.31 a feature...every new version of everything in the distro a feature? What benefit does applying the feature process to a routine update like this bring, to offset its clear inconsistency? routine version bump may actually introduce new and exciting features, and may need coordination across a wide range of users and testers. Ergo, Fedora Feature. Again, that applies to _everything in the distro_. I don't think 'it's a new version' can be a feature. If we identify something particular within the GNOME or KDE package set which is a significant enough change to qualify as a Fedora feature, fine, submit it as such. But just declaring the entire version upgrade to be a feature seems a bit weird to me. Features are about publicity. There is value in saying Fedora NN comes with Frobit 3.14!, if Frobit is a rather popular package. Doubly so if Fedora NN is the first distro to ship it. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Features Proposed for Removal
On Thu, Aug 06, 2009 at 12:49:30PM -0700, Adam Williamson wrote: On Thu, 2009-08-06 at 13:39 -0600, Kevin Fenzi wrote: On Thu, 06 Aug 2009 12:34:26 -0700 Adam Williamson awill...@redhat.com wrote: ...snip... Sure, and I was always happy to write in GNOME and KDE versions as 'Features' when writing release blurbs for Mandriva. But that's just pure PR. PR is not all our feature process does - it comes with all this bureaucracy, intended for dealing with experimental stuff which may turn out to have been a bad idea, attached to it, it's _not_ a pure PR exercise. Which leads to the absurdity we have here, the suggestion that the GNOME 2.28 'feature' should be 'dropped' for Fedora 12 (does anyone really think we're going to ship it with GNOME 2.26?) It wasn't a suggestion of that, it was our feature wrangler saying: hey, check these features because they are not showing 100%. Please see: https://fedoraproject.org/wiki/Features/Policy Do we need to change some policy there? Er, the _topic_ of this thread is Fedora 12 Features Proposed for Removal. The email doesn't say anything about 'if you fix this stuff before the meeting it'll be fine' (though that may be the actual case), and the amount of notice given is a princely two days, which isn't that long for anyone to make changes. The way things are worded are clearly We're going to drop these features, not please check this, okay? Please? Thanks! No, it's worded perfectly. The Feature Wrangler is PROPOSING to FESCo that we drop these Features. It's a proposal, it's not a clear intention of dropping them at all. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: KDE vs. GNOME on F10
On Wed, Aug 05, 2009 at 12:23:12PM +0200, Thorsten Leemhuis wrote: On 05.08.2009 12:02, Richard Hughes wrote: 2009/8/5 Josephine Tannhäuser josephine.tannhau...@googlemail.com: KDE 4.3 will come to F11 and F10. It's a cool thing. There aren't updates like this for Gnome. Why not? F10 with Gnome 2.26 sounds fine to me. Because I don't want to _support_ the latest and greatest GNOME on old versions. A lot of the GNOME stack would require updating core system stuff like gtk+ and glib2, and when you've done that you might as well be running F11. I don't mind merging small patches from upstream to fix specific bugs, but new code brings new bugs, and that's not something a typical F10 user wants to cope with. In my opinion, if you want newer functionality, you should just upgrade to F11. I don't want to get between the lines here (there are good arguments and against updating Gnome and KDE for older releases) and I hate buzz-words like Corporate identity, but I find it more and more odd that one doesn't know what to expect from Fedora, because similar sized things (KDE and Gnome) are handled quite differently. Short of passing a policy that says no major desktop upgrades for stable releases, I don't see this changing. If we did pass that, I have a feeling it would piss off a lot of people. Passing the converse (always upgrade) would piss off just as many. I'm not that enthralled with starting a who do you want to piss off today? campaign for Fedora. Further: The behavior changes to much IMHO -- one reason why I use Fedora at home and work and suggested it to others were the major new kernel versions that got delivered as regular update. But that doesn't really work anymore since half a year or something: F-10 is still on 2.6.27, 2.6.29 sits in Updates-testing for ages; 2.6.30 is out for weeks, but no sign of a update for F-11 apart for a few commits in CVS. :-( I haven't followed it that closely days. However, being on the bleeding edge kernel isn't what it used to be. Yes, 2.6.30 has been out for a while. But I believe we currently wait until at least the .1 release (which was still out a while ago). Right now, .4 was just released on Jul 30. Having a bit of patience to see if the kernel is a lemon or not is pretty prudent IMHO. A more common look and feel to the outside world and a more reliable update scheme IMHO would be good for Fedora, as people would know what to expect. Ohh, and it would prevent discussions like this ;-) Some of us tried that. We got critcized for it pretty heavily. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Fri, Jul 31, 2009 at 09:12:24PM +0200, drago01 wrote: [..] 17:45:48 Kevin_Kofler As for killing multilibs, a proposal for next week: restrict multilibs to wine, redhat-lsb and their dependencies. Rationale: way too much stuff which will never be needed multilib is multilib. The people who really need that stuff should just use the i?86 repo and deal with the conflicts. 17:46:08 nirik Kevin_Kofler: write up a proposal. ;) Sure making the life harder for our users just deal with conflicts is the way to go... If there are issues with multilib (there are!) we should work on fixing them instead of making the user experience even worse. (if you want a pure 64 bit system that is what you get by _DEFAULT_ anyway, so no flamewars about that please.) Slight correction. That is what you get by default on x86_64. Not i[3456]86 (obviously) or ppc (which is less obvious given that ppc is used on ppc64 machines). This point has nothing to do with what you were actually saying though. So feel free to ignore it as a clarification, not a rebuttal. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Sat, Aug 01, 2009 at 02:00:10AM +0530, Rahul Sundaram wrote: On 08/01/2009 01:31 AM, Josh Boyer wrote: Source0: http://cvs.fedoraproject.org/lookaside/pkgs/anaconda/anaconda-11.5.0.59.tar.bz2/0b0b7b30f1ff03bad05bda3d052b73a8/anaconda-11.5.0.59.tar.bz2 is really no better. This would ridiculous. I don't think any project is going to do this. It's no more ridiculous than forcing someone to setup a project website to host tarballs. Even if they do want to go to this extend, we don't need to grant them special exceptions. We can recommend that the projects used a proper project hosting facility and leave it at that. I This is part of the problem. Perhaps the developers don't want to be bothered with setting up a project hosting facility for something they to-date have been releasing in a manner they find sufficient. I don't see why they should be forced to just to be part of Fedora. If we want to encourage and recommend that, great! But saying it's required when they are providing sufficient means of getting the source to the package (in a Fedora perferred form even!) is a bit odd to me. All you are doing is forcing people to list a URL. Also, if an upstream project doesn't want to host all that and wants to use the SRPM as the source, who is Fedora to tell them they can't? It is a random upstream project but one developed within Fedora and Fedora can and should tell them not to do so. Why shouldn't we? Again they don't need or deserve special exceptions. Treat them like any other upstream project. That is all I ask. No. That is part of the problem with your proposal. You have targetted RH or Fedora packages that do this. If some other package only distributes via SRPM (or .deb, or ebuild), they aren't required to comply. Why force these RH/Fedora packages to do something that we don't force other packages to? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Fri, Jul 31, 2009 at 01:09:43PM -0700, Jesse Keating wrote: On Sat, 2009-08-01 at 01:20 +0530, Rahul Sundaram wrote: That's kind of side tracking though. Point is that SRPM as upstream source is simply a stupid thing. We would complain loudly or atleast whine about it if Novell or Mandriva or Debian did that. Wouldn't we? Why should we have an exception anymore? I can't think of a single reason why we should. If there was no public available source repo, yes we'd complain. If there was, I don't think we'd complain really. We don't complain about no public source repo. See deltarpm. It's repo consists of the tarball we use already. It doesn't even have an easily findable project website. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-07-31
On Fri, Jul 31, 2009 at 02:06:38PM -0700, Toshio Kuratomi wrote: It is a random upstream project but one developed within Fedora and Fedora can and should tell them not to do so. Why shouldn't we? Again they don't need or deserve special exceptions. Treat them like any other upstream project. That is all I ask. No. That is part of the problem with your proposal. You have targetted RH or Fedora packages that do this. If some other package only distributes via SRPM (or .deb, or ebuild), they aren't required to comply. Why force these RH/Fedora packages to do something that we don't force other packages to? The proposal doesn't target Fedora or RH. The exception targets Fedora or Red Hat. This removes that exception. It appears I have misread the proposal as written. I've also generally made an ass out of myself here. I withdraw my objection. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More Fedora mock breakage
On Fri, Jul 31, 2009 at 06:48:54PM -0400, Tom Lane wrote: Mathieu Bridon (bochecha) boche...@fedoraproject.org writes: ERROR with rpm_check_debug vs depsolve: rpmlib(PayloadIsXz) is needed by exim-4.69-12.fc12.x86_64 I had the same on F11, building in a Rawhide mock. I was advised to update rpm to 4.7.1 that was in updates-testing, which fixed the problem. [ consults CVS... ] So XZ support in F-11's rpm is less than a week old, there is *no* support in F-10, and we're already requiring the capability in order to do useful development work? All I can say is WTF. Did you have a better plan for migrating to an XZ payload for F12 in time for Alpha? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies in Fedora 11 - 2009-07-28
On Thu, Jul 30, 2009 at 09:50:31AM +0200, Michael Schwendt wrote: On Wed, 29 Jul 2009 11:44:59 -0700, Adam wrote: https://admin.fedoraproject.org/updates/libopensync-plugin-synce-0.22.1-1.fc11,synce-sync-engine-0.14-1.fc11,synce-hal-0.14-1.fc11,synce-kpm-0.14-1.fc11,librra-0.14-1.fc11,librapi-0.14-1.fc11,unshield-0.6-1.fc11,libsynce-0.14-1.fc11 Submitted on 2009-07-21, still pending. Not pushed anywhere? Bodhi problem? I'm not sure. May be just that it doesn't have the karma yet. I'll try and find time to test on my little F11 box and confirm/deny...this system runs F12. Normally, bodhi would have added a comment like This update has been submitted for testing and a similar one for stable plus another comment for the actual push. Such comments are missing in this ticket, as if it has not been submitted to any repo yet. And it's not a security update which enter the Security Team's queue before such comments appear. Exactly. It hasn't been pushed at all. The maintainer needs to click the 'push to testing' or 'push to stable' buttons in Bodhi. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 mass rebuild status
On Wed, Jul 29, 2009 at 09:37:03PM -0400, Todd Zullinger wrote: Jesse Keating wrote: On Wed, 2009-07-29 at 20:29 -0400, Todd Zullinger wrote: It has not seen a release since November of 2006. I think we should let it slip into retirement. I'm fine with seeing it go. I should make it clear that I'm not the owner of cogito (Chris is), nor am I a user of it (and I don't play one on TV either). I'm just some guy on a mailing list saying that package should be retired. :) Well, I agree with you. It needs to die. So now that's two guys on a mailing list, both of whom happen to be git co-maintainers. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No Frozen Rawhide
On Wed, Jul 22, 2009 at 11:55:27AM -0700, Roland McGrath wrote: You actually want overlap for a while so that when rsyncing you can use hardlinks instead of having to redownload files you already have. This is going to be more relevant if koji signing happens and packages don't get different signatures depending on which repo they are in. That would be nice for updates/updates-testing moves too. For that, I've thought it might work to put them all in updates/.all or someplace, with updates/... or updates/testing/... being hardlinks to that. Releases prior to F-11 wouldn't benefit from that at all, as the RPMs actually change when going from updates-testing to updates due to being signed with different keys. That might be worth looking into once F-10 dies. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F-11 updates seem hosed today
On Mon, Jul 20, 2009 at 08:21:47AM -0500, Jon Ciesla wrote: Dodji Seketeli wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 13/07/2009 20:36, Tom Lane a écrit : (Not sure if this is the right list to complain on, but ...) Trying to do a routine yum update on an F-11 x86 machine is not working today. It successfully downloaded a bunch of packages, but cannot find these: Yeah, a bug has been filed at https://bugzilla.redhat.com/show_bug.cgi?id=510898 for this. I guess we just have to wait for the mirrors to sync to the right content ... - -- Dodji Seketeli Red Hat -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpbf3IACgkQPejI7lrem2EjuQCgppHSF1zzH7P8CBaZVuFUbool /wcAnRoZocAyKQlLtDEnme0/gaYSLKcG =n0bC -END PGP SIGNATURE- Any word on this? I still don't seem to have anything on the mirror I sync from. . . Use a different mirror? I have successfully updated this morning using the stock fedora configs. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On Mon, Jul 20, 2009 at 11:56:02AM -0400, Bill McGonigle wrote: On 07/17/2009 07:57 PM, Josh Boyer wrote: It takes a push between 2 and 3 days to actually complete right now. We've had some significant delays due to a variety of factors over the past couple of weeks. I think we now have most of the big ones fixed, with the master mirrors allowing more rsync access, and the updates composes now being able to hardlink again (reduces mash time). There is another issue involving deltarpms that I've filed a bug on, and we should get some speed-up if we can get that figured out too. Josh - it sounds like you're working hard on this; much appreciated. Is there a clear resource constraint in the process - lack of hardware, insufficient bandwidth (locally or at the mirrors)? It sounds like Hardware has been taken care of recently. Mirror bandwidth is also now back to normal. current manpower is covered - are there software improvements (optimizations, pipelining, architectural) on the wishlist that would improve throughput? There is general knowledge that makedeltarpm is slow. However, we're working an issue that could speed things up due to us doing work we don't need to at the moment. So before getting into specifics, I'd like to see that issue resolved first. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On Sat, Jul 18, 2009 at 02:49:36AM +0530, Rahul Sundaram wrote: Hi, I have a concern with the recent delays in signing packages and how best to handle that. I maintain Gnote in Fedora. This is very actively maintained and has frequent releases, even weekly. It is also a rather young project (original release in Apr 1) and I do get bug reports on crashes and other issues that are better fixed quickly. I prefer not to push things directly to stable repository. With the recommended time of 7 days in updates-testing and the delay in signing the package for that and signing it for updates repo, the package gets obsoleted by Bodhi with the next release update. What would be the best way to handle this? I am not exaggerating when I say that updates are getting pushed out as fast as I can possibly make them. And signing is NOT, by any means, the hold up or the slow part. It takes me roughly an hour to get all the pending updates signed for a push (both testing and stable). It takes a push between 2 and 3 days to actually complete right now. We've had some significant delays due to a variety of factors over the past couple of weeks. I think we now have most of the big ones fixed, with the master mirrors allowing more rsync access, and the updates composes now being able to hardlink again (reduces mash time). There is another issue involving deltarpms that I've filed a bug on, and we should get some speed-up if we can get that figured out too. That being said, the updates push will still take quite some time to generate deltas. I'm hoping we can get it down to being able to do a complete push to within a 24 hour period for now, but that remains to be seen. Also keep in mind that as F11 grows older, the mash time for it will increase. I can understand your concern with a very active package like that. At the moment, we can't do anything we aren't already trying to do to get official updates out faster. Have patience. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates and delays in signing packages
On Sat, Jul 18, 2009 at 06:10:49AM +0530, Rahul Sundaram wrote: On 07/18/2009 05:27 AM, Josh Boyer wrote: I can understand your concern with a very active package like that. At the moment, we can't do anything we aren't already trying to do to get official updates out faster. Have patience. The question wasn't about why there was delays but how I can handle it within my workflow (I thought of just running my own repo but that doesn't seem ideal) but it is good to know more of the inside details on It might not be ideal, but given that you're waiting for pushes to get your builds into repos it might also be the most convenient for the people that want those builds. Putting repos on a fedorapeople page is not unheard of. why there are delays in the first place. On a related point, do we have good documentation on the entire process? If there is a need for more to No. I think our documentation of the entire push process doesn't exist. Some of it we don't want to exist, like how to get onto the signing machine. Some of it really can't be documented because it's dealing with issues as they come up in one form or another and there is no common error scenario. Other parts are changing at a somewhat rapid pace as we introduce new fixes and features. I think the best way to start is to get better documentation on the various software components involved first. Those would be bodhi, mash, createrepo, and deltarpm for the most part. Bodhi and mash would be good (and daunting) places to start. help with signing the packages, I can volunteer (assuming you let me). Signing is not the hurdle. Adding more people to help there won't really make anything faster. We're also toying with making koji do auto-signing at build time, which makes it basically go away. I do appreciate the offer though. josh -- 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?
On Tue, Jul 14, 2009 at 10:32:08PM +0200, Till Maas wrote: On Tue July 14 2009, Jason L Tibbitts III wrote: 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. Imho if the devel branch is a problem, then it should not be created when the package is imported to CVS, if it is a epel-only package. Requesting such strange actions from package maintainers who may not know all the magic behind the build system will only lead to errors like this one. You have a valid point. I'm not sure if the cvs scripts or pkgdb can currently cope with that though. If you have the time to look into it, I'm sure it would be appreciated. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
