Re: Fedora 13 continuing the tradition of being an update monster
Adam Williamson wrote: To answer the question someone posed earlier in the thread, when I was doing a lot of testing of various F13 RC2 installs yesterday, none of them - not the default desktop install from DVD, the desktop spin, the KDE spin or the Xfce spin - had more than 12 updates available. I don't recall the exact size of the available update sets, but they were around 10-20MB I think. FYI, for the KDE spin, we have KDE SC 4.4.3 already in testing since May 15, it's going to hit stable around release day. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, 2010-05-11 at 23:01 +0530, Rahul Sundaram wrote: The reason is that it is *game* and it is not part of the default set. Anyone who chooses to install it will get an updated game. I think the focus here is misguided. We should be paying attention to updates of the default package set instead IMO but if there is a consensus that it is actually a problem, I can refrain from pushing it. Let me know. I'm entirely with the 'it's no problem' camp, here. To answer the question someone posed earlier in the thread, when I was doing a lot of testing of various F13 RC2 installs yesterday, none of them - not the default desktop install from DVD, the desktop spin, the KDE spin or the Xfce spin - had more than 12 updates available. I don't recall the exact size of the available update sets, but they were around 10-20MB I think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, 2010-05-11 at 17:19 +0100, Richard W.M. Jones wrote: Why does the large size of some game files matter? _Number_ of updates matters (ie. 140 is a bit large) but on the other hand F13 has been in limbo for such a long time I'm not surprised. It really hasn't. We accepted submissions of non-critpath updates to stable (i.e. the final F13 package set) up until very very recently (Jesse could tell you exactly when). Critpath updates obviously were more carefully looked at, but a lot went through. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
Ralf Corsepius (rc040...@freenet.de) said: And right now the values used are scaled to the hardware we have at hand. So adjusting it wouldn't help Fedora one bit. Makes me wonder about your HW. Fact is, extending the limits to 200MB (the hard-coded limit is 100MB) I having no problems with building drpms from packages which are in the order of 150MB-200MB (unpacked size) on standard x86_64-PC hardware with 4GB RAM. Due to how the tree is composed, if updates and a tree are being composed at the same time, it could be making 5 or more deltas simultaneously... Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 13 continuing the tradition of being an update monster
Thankfully all the giant flamewars and new policies didn't make anyone think twice about the users, as we already have 140 updates with a combined size of _over_ 750MB on x86_64, biggest 5 are: 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm 12M hanazono-fonts-20100222-2.fc13.noarch.rpm 48M xmoto-0.5.3-1.fc13.x86_64.rpm 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm 318M openarena-0.8.5-1.fc13.noarch.rpm ...the last being particularly nice, in that the package hasn't been updated for almost a year but now we get 2 300MB+ presents at once. Welcome to the new Fedora updates, much like the old Fedora updates. Hey, at least Kevin should be happy. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, May 11, 2010 at 02:14:58AM -0400, James Antill wrote: Thankfully all the giant flamewars and new policies didn't make anyone think twice about the users, as we already have 140 updates with a combined size of _over_ 750MB on x86_64, biggest 5 are: 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm 12M hanazono-fonts-20100222-2.fc13.noarch.rpm 48M xmoto-0.5.3-1.fc13.x86_64.rpm 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm 318M openarena-0.8.5-1.fc13.noarch.rpm ...the last being particularly nice, in that the package hasn't been updated for almost a year but now we get 2 300MB+ presents at once. Do you have data on delta-rpm sizes? -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. pgpSrZZVaA6BI.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, May 11, 2010 at 02:14:58 -0400, James Antill ja...@fedoraproject.org wrote: 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm 12M hanazono-fonts-20100222-2.fc13.noarch.rpm 48M xmoto-0.5.3-1.fc13.x86_64.rpm 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm 318M openarena-0.8.5-1.fc13.noarch.rpm I don't think either wesnoth or openarena are on the desktop spin. They are probably only on the games spin. So the impact of those, really should not be that big. (Compared to say the effect an openoffice.org would have.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
And so what ? In OpenArena's case, last stable releases were: * 0.8.5: 02/23/2010 * 0.8.1: 10/31/2008 You can't blame OpenArena's maintainer for that, do you ? The same goes for Wesnoth, 1.8.1 maintenance release was issued 2 May so less than two weeks ago (1.8 was released 1st april !) Best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On 05/11/2010 11:44 AM, James Antill wrote: Thankfully all the giant flamewars and new policies didn't make anyone think twice about the users, as we already have 140 updates with a combined size of _over_ 750MB on x86_64, biggest 5 are: 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm 12M hanazono-fonts-20100222-2.fc13.noarch.rpm 48M xmoto-0.5.3-1.fc13.x86_64.rpm 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm 318M openarena-0.8.5-1.fc13.noarch.rpm ...the last being particularly nice, in that the package hasn't been updated for almost a year but now we get 2 300MB+ presents at once. I did the last push and my rationale was simple. It is not part of a default package set. Only the games spin has it by default. Everyone has to choose to install it and I have had explicit requests to update to the latest version since it brings a number of new changes that users want. How would like me to proceed? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, May 11, 2010 at 8:14 AM, James Antill ja...@fedoraproject.org wrote: Thankfully all the giant flamewars and new policies didn't make anyone think twice about the users, as we already have 140 updates with a combined size of _over_ 750MB on x86_64, biggest 5 are: 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm 12M hanazono-fonts-20100222-2.fc13.noarch.rpm 48M xmoto-0.5.3-1.fc13.x86_64.rpm 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm 318M openarena-0.8.5-1.fc13.noarch.rpm ...the last being particularly nice, in that the package hasn't been updated for almost a year but now we get 2 300MB+ presents at once. Welcome to the new Fedora updates, much like the old Fedora updates. Hey, at least Kevin should be happy. What was that for? To start another flamewar including the challenge for a explicit person? Oh, and could you post a link to the new updates policies please. It seems i missed them. I will have at least the chance to check for the new rule, that releases don't get updates approx. bigger than 5MB/package. Looks like a lot to read for me. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, May 11, 2010 at 8:42 AM, Thomas Janssen thom...@fedoraproject.org wrote: What was that for? To start another flamewar including the challenge for a explicit person? Quite, a possibly valid point losing out to a flamebait codicil. -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
It is not part of a default package set. Even if it were, blocking bugfixes in order to reduce updates size is nothing but stupid. We have presto/deltarpm for that (since these packages mostly contain unchanged binary data like images, it should work pretty well). What's the point in having new updates policies, if we replace the previous updates craze by a more vicious stable updates frenzy ? H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On 05/11/2010 02:00 PM, H. Guémar wrote: It is not part of a default package set. Even if it were, blocking bugfixes in order to reduce updates size is nothing but stupid. We have presto/deltarpm for that (since these packages mostly contain unchanged binary data like images, it should work pretty well). What's the point in having new updates policies, if we replace the previous updates craze by a more vicious stable updates frenzy ? Just to clarify. The new OpenArena is NOT a bug fix release. It is a update to the game with enhancements such as new maps, characters and so on. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On 11 May 2010 07:14, James Antill ja...@fedoraproject.org wrote: Thankfully all the giant flamewars and new policies didn't make anyone think twice about the users, as we already have 140 updates with a combined size of _over_ 750MB on x86_64, biggest 5 are: I wonder what the number is for packages on the desktop spin? I guess that's a bit more reasonable. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
* Richard Hughes [11/05/2010 11:05] : I wonder what the number is for packages on the desktop spin? I guess that's a bit more reasonable. I'm left wondering what problem we're trying to solve here. I'm gussing it's one of : * there are too many updates (for whom? how is this a problem?) * the updates repository is too big (same questions apply) * broken updates are pushed to stable * something else but I've no idea what. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
Am Dienstag, den 11.05.2010, 02:14 -0400 schrieb James Antill: Thankfully all the giant flamewars and new policies didn't make anyone think twice about the users, as we already have 140 updates with a combined size of _over_ 750MB on x86_64, This number is kind of irrelevant as nobody will have to install them all. And how was this counted? I see 2384 stable updates, but they are tagged F13 final, so they are no updates although they went trough the update system. I see 75 pending updates ATM. biggest 5 are: 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm 12M hanazono-fonts-20100222-2.fc13.noarch.rpm 48M xmoto-0.5.3-1.fc13.x86_64.rpm 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm 318M openarena-0.8.5-1.fc13.noarch.rpm Although I'm one of the persons who opposed to the high number of updates in the past I don't see anything wrong with these. I don't have any of them installed so there is nothing for me to update. But people who play these games will surely appreciate the new upstream versions. This being said I think we should decrease the number of * useless updates. New upstream versions of a game do not fall into this category, they are useful for the gamers. * updates that affect a large count of users and don't offer much value. ...the last being particularly nice, in that the package hasn't been updated for almost a year but now we get 2 300MB+ presents at once. I only see one openarea update in bodhi, openarena-0.8.5-1.fc13. I agree however that this update should have come earlier as 0.8.5 was already released on February 23rd. Welcome to the new Fedora updates, much like the old Fedora updates. Hey, at least Kevin should be happy. Please keep in mind that the new update policy is not yet active. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
Thankfully all the giant flamewars and new policies didn't make anyone think twice about the users, as we already have 140 updates with a combined size of _over_ 750MB on x86_64, biggest 5 are: yeah, over 750 MB where 584 MB belongs to wesnoth and openarena. So without these two games it's only 166 MB and that's not that bad (also don't forget about deltarpms). 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm 12M hanazono-fonts-20100222-2.fc13.noarch.rpm 48M xmoto-0.5.3-1.fc13.x86_64.rpm 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm 318M openarena-0.8.5-1.fc13.noarch.rpm ...the last being particularly nice, in that the package hasn't been updated for almost a year but now we get 2 300MB+ presents at once. Welcome to the new Fedora updates, much like the old Fedora updates. why are you so scared about updates? Now we have some packages in Fedora that are broken or outdated (for online multi-player games - you usually can't play with other players when your version is not up2date, so it becomes unusable even the update itself is enhancement only). And what should maintainers do? a) update only in F-14 so users will get broken F-13 and they will have to wait another 6 months for new version? b) wait at least two weeks after F-13 GA, so we won't have too much 0-day updates? Does anyone really think lower 0-day update size is much cool than delivering fixed packages? c) wait until there is critical/security bug only? So bug reporter has to wait three months for getting the fix for bug he reported? It'll just disappoint the reporter and his conclusion would be that bug reporting is useless. Even when the reporter can have the fix from updates-testing using the update command pasted in the bug report by bodhi, there would be other users facing the bug complaining about buggy fedora while waiting for the fix. From my pov I'm happy we have maintainers working hard to get fixes and features to our users. I'm fine with huge 0-day updates, because despite it's not optimal, it's still much better than having broken packages. If there are really a lot of 0-day updates it does not mean we have wrong update policy, it just means release date should be postponed Hey, at least Kevin should be happy. well, I am happy ;) Michal --- this is my first and last post to this flamebait thread -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
Bruno Wolff III wrote: I don't think either wesnoth or openarena are on the desktop spin. They are probably only on the games spin. So the impact of those, really should not be that big. (Compared to say the effect an openoffice.org would have.) ... and wesnoth multiplayer doesn't work on x86_64 due to the boost version in F13. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On 05/11/2010 01:14 AM, James Antill wrote: Thankfully all the giant flamewars and new policies didn't make anyone think twice about the users, as we already have 140 updates with a combined size of _over_ 750MB on x86_64, biggest 5 are: 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm 12M hanazono-fonts-20100222-2.fc13.noarch.rpm 48M xmoto-0.5.3-1.fc13.x86_64.rpm 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm 318M openarena-0.8.5-1.fc13.noarch.rpm ...the last being particularly nice, in that the package hasn't been updated for almost a year but now we get 2 300MB+ presents at once. Welcome to the new Fedora updates, much like the old Fedora updates. Hey, at least Kevin should be happy. Speaking as the wesnoth and xmoto maintainer, I've, in the past, asked for wesnoth releases of this nature to be tagged into final to same mirror space, but, again, it's not in the default spin, and we now have deltarpms (and a huge thank to to all responsible there), so I really don't think it's that big of an issue. If someone wants to request this, or thinks I should do so, pipe up now, as the hour of relevance draws near. Besides, I doubt they'd do it anyway, after reading Jesse's Release Candidate email. And probably with good reason. All of that said, I'll keep doing game updates. Gamers want them, as has already been said. -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, May 11, 2010 at 11:18:23 +0200, Emmanuel Seyman emmanuel.sey...@club-internet.fr wrote: * Richard Hughes [11/05/2010 11:05] : I wonder what the number is for packages on the desktop spin? I guess that's a bit more reasonable. I'm left wondering what problem we're trying to solve here. I'm gussing it's one of : A bad experience if you install or update from an earlier release with the updates repository enabled. In this case I don't think it is that bad because most of the space is from packages that aren't in the default spin. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, May 11, 2010 at 3:29 PM, Jon Ciesla l...@jcomserv.net wrote: On 05/11/2010 01:14 AM, James Antill wrote: Thankfully all the giant flamewars and new policies didn't make anyone think twice about the users, as we already have 140 updates with a combined size of _over_ 750MB on x86_64, biggest 5 are: 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm 12M hanazono-fonts-20100222-2.fc13.noarch.rpm 48M xmoto-0.5.3-1.fc13.x86_64.rpm 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm 318M openarena-0.8.5-1.fc13.noarch.rpm ...the last being particularly nice, in that the package hasn't been updated for almost a year but now we get 2 300MB+ presents at once. Welcome to the new Fedora updates, much like the old Fedora updates. Hey, at least Kevin should be happy. Speaking as the wesnoth and xmoto maintainer, I've, in the past, asked for wesnoth releases of this nature to be tagged into final to same mirror space, but, again, it's not in the default spin, and we now have deltarpms (and a huge thank to to all responsible there), so I really don't think it's that big of an issue. If someone wants to request this, or thinks I should do so, pipe up now, as the hour of relevance draws near. Besides, I doubt they'd do it anyway, after reading Jesse's Release Candidate email. And probably with good reason. All of that said, I'll keep doing game updates. Gamers want them, as has already been said. Thank you very much from a Wesnoth gamer. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On 05/11/2010 01:12 AM, H. Guémar wrote: And so what ? In OpenArena's case, last stable releases were: * 0.8.5: 02/23/2010 Feb 2nd, 2010 - that's a long time ago. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On 05/11/2010 06:05 PM, Nathanael D. Noblet wrote: On 05/11/2010 01:12 AM, H. Guémar wrote: And so what ? In OpenArena's case, last stable releases were: * 0.8.5: 02/23/2010 Feb 2nd, 2010 - that's a long time ago. You said that, because you haven't seen really the oldest packages in Fedora. ... 8 ... 12 years old ! Time is relative ;-) -- If less is more than more, most is more than less. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, 2010-05-11 at 10:30 +0200, H. Guémar wrote: It is not part of a default package set. Even if it were, blocking bugfixes in order to reduce updates size is nothing but stupid. It wasn't bugfixes, it was a new upstream release, and yes size does matter. All mirrors, public and private, now have 300MB of worthless bits in their 13 release (and it's not even released yet). And this for something that hasn't been updated throughout the life of F-12. It again goes to the point of why bother making releases at all, if they mean so little. And, trying to be less grumpy, maybe moving some packages to rawhide only style of repos. would make everyone happy (we could even call it extras :). We have presto/deltarpm for that (since these packages mostly contain unchanged binary data like images, it should work pretty well). Within Fedora deltarpms have a limit of applying only to rpms less than 100MB, so there are no deltarpms. Anyone who wants to blame rel-eng for that is free to fix the delarpm code, or give money to rel-eng to buy HW. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, 2010-05-11 at 08:29 -0500, Jon Ciesla wrote: On 05/11/2010 01:14 AM, James Antill wrote: Thankfully all the giant flamewars and new policies didn't make anyone think twice about the users, as we already have 140 updates with a combined size of _over_ 750MB on x86_64, biggest 5 are: 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm 12M hanazono-fonts-20100222-2.fc13.noarch.rpm 48M xmoto-0.5.3-1.fc13.x86_64.rpm 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm 318M openarena-0.8.5-1.fc13.noarch.rpm ...the last being particularly nice, in that the package hasn't been updated for almost a year but now we get 2 300MB+ presents at once. Welcome to the new Fedora updates, much like the old Fedora updates. Hey, at least Kevin should be happy. Speaking as the wesnoth and xmoto maintainer, I've, in the past, asked for wesnoth releases of this nature to be tagged into final to same mirror space, but, again, it's not in the default spin Wesnoth was annoying, but at least it is consistent as you seem to do an update about once a month. , and we now have deltarpms (and a huge thank to to all responsible there), so I really don't think it's that big of an issue. As I said in another reply, there are currently no deltarpms for wesnoth-data due to it's size. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Mon, May 10, 2010 at 10:14 PM, James Antill ja...@fedoraproject.org wrote: 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm 12M hanazono-fonts-20100222-2.fc13.noarch.rpm 48M xmoto-0.5.3-1.fc13.x86_64.rpm 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm 318M openarena-0.8.5-1.fc13.noarch.rpm ...the last being particularly nice, in that the package hasn't been updated for almost a year but now we get 2 300MB+ presents at once. Welcome to the new Fedora updates, much like the old Fedora updates. Hey, at least Kevin should be happy. Just for the record. You are complaining about pre-release update churn? I'm a little confused. I would have though that pre-release churn is preferable to post-release churn. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On 05/11/2010 06:27 PM, James Antill wrote: As I said in another reply, there are currently no deltarpms for wesnoth-data due to it's size. Then fix this deficiency of your process and provide them. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, 11 May 2010 17:19:41 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Tue, May 11, 2010 at 02:14:58AM -0400, James Antill wrote: Thankfully all the giant flamewars and new policies didn't make anyone think twice about the users, as we already have 140 updates with a combined size of _over_ 750MB on x86_64, biggest 5 are: 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm 12M hanazono-fonts-20100222-2.fc13.noarch.rpm 48M xmoto-0.5.3-1.fc13.x86_64.rpm 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm 318M openarena-0.8.5-1.fc13.noarch.rpm ...the last being particularly nice, in that the package hasn't been updated for almost a year but now we get 2 300MB+ presents at once. Welcome to the new Fedora updates, much like the old Fedora updates. Hey, at least Kevin should be happy. Why does the large size of some game files matter? _Number_ of updates matters (ie. 140 is a bit large) but on the other hand F13 has been in limbo for such a long time I'm not surprised. The fedora 13 'updates' repo has only existed for a day or so. Before this time, things that would normally go to updates were just tagged into the base repo. So, now that we are near release and can't change the base repo for anything except very severe blockers, other things go to updates. It's unfortunate that these two big packages didn't make it into the base repo, but such is life. ;( kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Deltarpm volunteers welcome (was Re: Fedora 13 continuing the tradition of being an update monster)
On Tue, 2010-05-11 at 12:23 -0400, James Antill wrote: Within Fedora deltarpms have a limit of applying only to rpms less than 100MB, so there are no deltarpms. Anyone who wants to blame rel-eng for that is free to fix the delarpm code... On that subject, anyone who wants to fix this would be much appreciated. The problem is that when deltarpm *creates* a new deltarpm, it reads the full uncompressed old rpm and uncompressed new rpm into RAM. The way to fix it is to delta chunks of the old and new rpm at a time. Unfortunately, given the way the code is written, it's not a trivial fix and I haven't had time over the last year or so to get it done. So volunteers are welcome. Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, May 11, 2010 at 8:46 AM, Kevin Fenzi ke...@scrye.com wrote: It's unfortunate that these two big packages didn't make it into the base repo, but such is life. ;( As this is the first time we've done the early branching... I certainly expect mistakes right around the time of the branch freeze and for things to not make it. For completeness how many of our packages are excluded from delta creation at the moment in F13? Is it a small enough list where a self appointed nagmaster could touchbase which each of the maintainers a week or two a head or branch freeze to try to make sure this doesn't happen next time? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
Xose Vazquez Perez (xose.vazq...@gmail.com) said: On 05/11/2010 06:05 PM, Nathanael D. Noblet wrote: On 05/11/2010 01:12 AM, H. Guémar wrote: And so what ? In OpenArena's case, last stable releases were: * 0.8.5: 02/23/2010 Feb 2nd, 2010 - that's a long time ago. You said that, because you haven't seen really the oldest packages in Fedora. ... 8 ... 12 years old ! I think the point is that if the release was done in February, there's really no reason it should be a F-13 *update* at GA. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, 2010-05-11 at 18:44 +0200, Ralf Corsepius wrote: On 05/11/2010 06:27 PM, James Antill wrote: As I said in another reply, there are currently no deltarpms for wesnoth-data due to it's size. Then fix this deficiency of your process and provide them. Patches welcome. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, May 11, 2010 at 08:27:30 -0500, Michael Cronenworth m...@cchtml.com wrote: Bruno Wolff III wrote: I don't think either wesnoth or openarena are on the desktop spin. They are probably only on the games spin. So the impact of those, really should not be that big. (Compared to say the effect an openoffice.org would have.) ... and wesnoth multiplayer doesn't work on x86_64 due to the boost version in F13. I am talking to the boost guys about this. If you want to help see: https://bugzilla.redhat.com/show_bug.cgi?id=590205 I don't have access to x86_64 to retest this today, because I'm home sick. The CRC patch has been applied, but I am not sure if that will really fix things based on another test I did yesterday (on a private build). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On 05/11/2010 07:03 PM, Jesse Keating wrote: On Tue, 2010-05-11 at 18:44 +0200, Ralf Corsepius wrote: On 05/11/2010 06:27 PM, James Antill wrote: As I said in another reply, there are currently no deltarpms for wesnoth-data due to it's size. Then fix this deficiency of your process and provide them. Patches welcome. Part of it is lingering in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=563866 I am using a locally rebuilt (due to upstream refusing to provide one in Fedora) patched createrepo as part of a 3rd party repo's infrastructure. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, 2010-05-11 at 19:10 +0200, Ralf Corsepius wrote: On 05/11/2010 07:03 PM, Jesse Keating wrote: On Tue, 2010-05-11 at 18:44 +0200, Ralf Corsepius wrote: On 05/11/2010 06:27 PM, James Antill wrote: As I said in another reply, there are currently no deltarpms for wesnoth-data due to it's size. Then fix this deficiency of your process and provide them. Patches welcome. Part of it is lingering in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=563866 I am using a locally rebuilt (due to upstream refusing to provide one in Fedora) patched createrepo as part of a 3rd party repo's infrastructure. That doesn't actually help. It doesn't address the base problem of how delta rpm does its work, by reading everything into ram. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On 05/11/2010 07:12 PM, Jesse Keating wrote: On Tue, 2010-05-11 at 19:10 +0200, Ralf Corsepius wrote: On 05/11/2010 07:03 PM, Jesse Keating wrote: On Tue, 2010-05-11 at 18:44 +0200, Ralf Corsepius wrote: On 05/11/2010 06:27 PM, James Antill wrote: As I said in another reply, there are currently no deltarpms for wesnoth-data due to it's size. Then fix this deficiency of your process and provide them. Patches welcome. Part of it is lingering in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=563866 I am using a locally rebuilt (due to upstream refusing to provide one in Fedora) patched createrepo as part of a 3rd party repo's infrastructure. That doesn't actually help. It doesn't address the base problem of how delta rpm does its work, by reading everything into ram Correct, but it makes running out of RAM scalable. It allows you to extend the hard-coded limitations to the HW you are using and to the actual demands of your packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On 05/11/2010 09:35 PM, Nathanael D. Noblet wrote: On 05/11/2010 01:12 AM, H. Guémar wrote: And so what ? In OpenArena's case, last stable releases were: * 0.8.5: 02/23/2010 Feb 2nd, 2010 - that's a long time ago. Yep. The primary maintainer at that time recently orphaned this package and I transitioned from being a co-maintainer to being the primary maintainer. Other tasks related to Fedora 13 took a higher priority and when I finally managed to push an update, we were past the release freeze. As I have said before, I am always open to having more co-maintainers for any of the packages that I maintain. So if anyone is interested, do sign up. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On 05/11/2010 06:27 PM, James Antill wrote: On Tue, 2010-05-11 at 08:29 -0500, Jon Ciesla wrote: , and we now have deltarpms (and a huge thank to to all responsible there), so I really don't think it's that big of an issue. As I said in another reply, there are currently no deltarpms for wesnoth-data due to it's size. A trick to make drpms working would be to split the packages in question into a hierarchy of subpackages, each with sizes below the limitations of createrepo. Not necessarily nice, but a viable work-around, IMO. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On 05/11/2010 10:31 PM, Bill Nottingham wrote: I think the point is that if the release was done in February, there's really no reason it should be a F-13 *update* at GA. The reason is that it is *game* and it is not part of the default set. Anyone who chooses to install it will get an updated game. I think the focus here is misguided. We should be paying attention to updates of the default package set instead IMO but if there is a consensus that it is actually a problem, I can refrain from pushing it. Let me know. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, 2010-05-11 at 19:20 +0200, Ralf Corsepius wrote: On 05/11/2010 07:12 PM, Jesse Keating wrote: On Tue, 2010-05-11 at 19:10 +0200, Ralf Corsepius wrote: On 05/11/2010 07:03 PM, Jesse Keating wrote: On Tue, 2010-05-11 at 18:44 +0200, Ralf Corsepius wrote: On 05/11/2010 06:27 PM, James Antill wrote: As I said in another reply, there are currently no deltarpms for wesnoth-data due to it's size. Then fix this deficiency of your process and provide them. Patches welcome. Part of it is lingering in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=563866 I am using a locally rebuilt (due to upstream refusing to provide one in Fedora) patched createrepo as part of a 3rd party repo's infrastructure. That doesn't actually help. It doesn't address the base problem of how delta rpm does its work, by reading everything into ram Correct, but it makes running out of RAM scalable. It allows you to extend the hard-coded limitations to the HW you are using and to the actual demands of your packages. And right now the values used are scaled to the hardware we have at hand. So adjusting it wouldn't help Fedora one bit. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, 2010-05-11 at 19:10 +0200, Ralf Corsepius wrote: On 05/11/2010 07:03 PM, Jesse Keating wrote: On Tue, 2010-05-11 at 18:44 +0200, Ralf Corsepius wrote: On 05/11/2010 06:27 PM, James Antill wrote: As I said in another reply, there are currently no deltarpms for wesnoth-data due to it's size. Then fix this deficiency of your process and provide them. Patches welcome. Part of it is lingering in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=563866 No it isn't, your pet RFE doesn't help Fedora rel-eng at all. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On Tue, May 11, 2010 at 12:23:35PM -0400, James Antill wrote: It again goes to the point of why bother making releases at all, if they mean so little. And, trying to be less grumpy, maybe moving some packages to rawhide only style of repos. would make everyone happy (we could even call it extras :). Interestingly enough, I've been thinking that same thought over the past few weeks. Do other people feel that they would like their packages to go into a rolling-release style repository that targets the core OS rather than what we have currently? The way I see this working is sorta like this: release has less packages than it currently does. I don't know if the criteria for being in the release tree would be anything on a spin or things in critical path or some new definition. updates and updates-testing is for updates to the release F-12-rolling and F-12-rolling-testing are rolling releases built to be compatible with that release tree. This is very similar to the Core/Extras split of old. However, what is not split is: the package VCS, bugzilla, build infrastructure and supporting tools (bodhi, pkgdb, etc). To me, this keeps the major benefits of the Core Extras merge but defines a difference between the two streams where the users interact with them. (Note: I can already see potential areas where this is not as flexible as having two separate streams (as adamw says Mandriva does) -- for instance, ComaintainerA wants to define Foo as part of Core while CoMaintainerB wants to define Foo as part of Rolling. I don't know if that's an issue in practice or if this is a good-enough solution. -Toshio pgpKaXJMAO7uj.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
On 05/11/2010 07:33 PM, Jesse Keating wrote: On Tue, 2010-05-11 at 19:20 +0200, Ralf Corsepius wrote: On 05/11/2010 07:12 PM, Jesse Keating wrote: On Tue, 2010-05-11 at 19:10 +0200, Ralf Corsepius wrote: On 05/11/2010 07:03 PM, Jesse Keating wrote: On Tue, 2010-05-11 at 18:44 +0200, Ralf Corsepius wrote: On 05/11/2010 06:27 PM, James Antill wrote: As I said in another reply, there are currently no deltarpms for wesnoth-data due to it's size. Then fix this deficiency of your process and provide them. Patches welcome. Part of it is lingering in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=563866 I am using a locally rebuilt (due to upstream refusing to provide one in Fedora) patched createrepo as part of a 3rd party repo's infrastructure. That doesn't actually help. It doesn't address the base problem of how delta rpm does its work, by reading everything into ram Correct, but it makes running out of RAM scalable. It allows you to extend the hard-coded limitations to the HW you are using and to the actual demands of your packages. And right now the values used are scaled to the hardware we have at hand. So adjusting it wouldn't help Fedora one bit. Makes me wonder about your HW. Fact is, extending the limits to 200MB (the hard-coded limit is 100MB) I having no problems with building drpms from packages which are in the order of 150MB-200MB (unpacked size) on standard x86_64-PC hardware with 4GB RAM. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
