Re: Does anyone else think yumex is broken?
On 01/07/2010 04:08 PM, Paul W. Frields wrote: The yum command line tool is great for anyone who wants to see more of the guts of package management. However, PackageKit is neither unreliable nor barely communicating in my experience, and I use it most of the time in Fedora. Well, ... * ... I have occasionally seen PK notifying me about updates available, but when trying to download/install the updates, it told me 0 updates available * ... in recent weeks (last time today) I've seen it forgetting about its reboot notification (I was notified about updates being available, and updated, but haven't rebooted since then - Initially the reboot notification button appeared, meanwhile it's gone). ... Yum also has bits that allow it to communicate with PackageKit when run on the command line. This system works quite well. May-be for you ... I am not excited about PK. A nice idea, but (over-?) ladden with many (IMO) discussworthy/questionable features. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Our static Libraries packaging guidelines once more
On 01/05/2010 05:48 PM, Tom spot Callaway wrote: On 01/05/2010 11:30 AM, Jesse Keating wrote: On Tue, 2010-01-05 at 11:03 -0500, Tom Lane wrote: On the other hand, with the guideline being so widely ignored, I'm not in a hurry to do work to comply with it ... Isn't that a chicken/egg problem? It really is. I mean, we could create the Packaging Police to run around and enforce the guidelines by force (either by fixing them manually, I would not want to call it a packaging police, but a tag team which fixes the packages == IMO, that's the way to go. or by threatening maintainers until they do it), but is that really what we want? Yes, people have had enough time to fix their packages - It's time for action. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packaging a static library
On 12/29/2009 11:52 AM, Daniel Drake wrote: Hi, OLPC's security system uses libtomcrypt / tomsfastmath, both at the Linux level and the firmware level. OLPC has previously had a specific version of tomcrypt/tommath profesionally audited for security reasons. So we obviously want to stick with that version. A few packages we have in Fedora currently use this frozen, audited version - we do so by shipping duplicate copies of that source code within the individual packages, rather than linking against the dynamic systemwide equivalents. As we're now looking at making another package which uses yet another duplicate copy of this code base I'm wondering if we can do it better. Could I add a package, named olpc-bios-crypto-devel (a subpackage of the to-be-packaged olpc-bios-crypto), which installs the .a files for the audited libraries somewhere on the system? Then the individual components that rely on this library (e.g. bitfrost, olpc-contents, olpc-bios-crypto) would have a BuildRequires dependency on olpc-bios-crypto-devel and build against the 'systemwide' static .a library files. Or am I going too far against common packaging practice at this point? Yes. You are outsmarting yourselves and not doing good to other users of the libraries, IMO. If all users of the library were using the same, identical shared versions, everybody would benefit from your auditing, maintainers would benefit from issues being fixed at one place, users would benefit from you not shipping statically linked packages. Any alternative suggestions? Use system-wide, shared versions only, unless there are technical reasons for not doing so - Your rationale doesn't provide such. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packaging a static library
On 12/30/2009 07:29 AM, Jon Masters wrote: On Tue, 2009-12-29 at 14:41 +0100, Ralf Corsepius wrote: On 12/29/2009 11:52 AM, Daniel Drake wrote: OLPC has previously had a specific version of tomcrypt/tommath profesionally audited for security reasons. So we obviously want to stick with that version. A few packages we have in Fedora currently use this frozen, audited version - we do so by shipping duplicate copies of that source code within the individual packages, rather than linking against the dynamic systemwide equivalents. If all users of the library were using the same, identical shared versions, everybody would benefit from your auditing, maintainers would benefit from issues being fixed at one place, users would benefit from you not shipping statically linked packages. One presumes that such auditing is expensive, lengthy, and not often to be repeated. Committing to undertaking a full code audit on every update would seem to be a little unreasonable of a request. So I think it's obvious that if they want to use an audited version, there will have to be a separate audited version. Well, I disagree: If they want to use their auditied version, they haven't understood how open source works. They qualify as jerks who prefer to use proprietary forks instead of paying back to upstream and the wider user-base. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: WTF is wrong with thunderbird????
On 12/22/2009 10:15 AM, Frank Murphy (Frankly3D) wrote: On 21/12/09 22:08, Ralf Corsepius wrote: Unfortunately, I don't know if who the culprit actually is: dovecot, TB3 or x86_64 or else. Ralf I have 3.0-4.fc12 Thunderbird on 64bit. (gmail-imap) None of the problems you describe. Only known bugs with the filter list. I don't have Dovecot OK, another indication that the culprit might be dovecot, IMO. [I am suspecting a file locking issue between TB3 and dovecot, but this is not much more but a wild guess without having any evidence for it.] What I am actually doing is to filter incoming mails from several remote imap and pop accounts into a local dovecot-imap applying thunderbird filtering. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: WTF is wrong with thunderbird????
On 12/22/2009 12:55 PM, Ralf Corsepius wrote: On 12/22/2009 11:43 AM, Paulo Cavalcanti wrote: What I am actually doing is to filter incoming mails from several remote imap and pop accounts into a local dovecot-imap applying thunderbird filtering. Have you disabled Keep messages for this account on this computer for every account? This option is in the Synchronization Storage tab for the account. The default is on, unfortunately. No, I hadn't. For some accounts it was on, for some it was off. I am giving off for all a try and keep you posted, should this improve the situation. So far (after ca. 6 hours), setting them to off, significantly reduces the mess, nevertheless, I am still occasionally observing old mails being marked as new. So ... close, but no cigar ;) Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: WTF is wrong with thunderbird????
On 12/21/2009 02:47 PM, Kevin J. Cummings wrote: OK, so I'm an email hog. I don't like to use the delete key. Here's my setup: My email server is F10.i386 (yeah, yeah, I know its EOLed) Its up-to-date, running dovecot as my IMAP server. My laptop is F11.x86_64. I'm running the new thunderbird 3.0 which was just released. My Inbox was getting very large. 70,000 messages in it. While things were starting to take a long time to do, yesterday I finally decided to do something about it. I created some 25 (or so) sub-folders in my primary email account and set about transferring various emails from my Inbox to the sub-folders. For the most part, I created an email filter for every email list I am a member of to automatically move emails from each list to its own sub-folder. It took me a while ( 4 hours). When I was done it was working. Kinda. I noticed that I had started seeing some really strange problems. While reading my incoming fedora-list emails (for example), thunderbird marked the email I was currently reading as un-read, right before my eyes! It also marked the 3 emails I had *just* read as unread. While going though that mailbox (using the Next button to read the next unread email), I read some messages 3-4 times before it finally told me I had read everything! That's when I started to notice that all of a sudden I had 38 unread emails in the mailbox I had read previous to the one I was in now. When I went back to read them, most of them were familiar! I had just read them. I wss going nuts. What's happening? This morning I st down to read my emails that occurred overnight. Thunderbird tells me I have 38 unread emails in my Admin box. When I go there to read them, it tells me there are only 24 unread emails! The first one is dated 9/26/2009! OK, so I read it. I'm pretty sure I've read it before I continue to read the other 23 emails. Then I hit the Next button again, and here I am back at this email from 9/26 again! While I'm writing this email, thunderbird now tells me I have 4 unread emails in my Admin mailbox. One of them is new. The rest are dated: 5/4/2009, 9/26/2009 (yeup, them same one I've read twice already today!), and 10/11/2009, and 10/11/2009. That's right, while I was reading them, it decided to mark another already read email as unread! Am I going nuts Oh, wait! I have 4 unread email in Admin: 5/4/2009, 9/26/2009, and those 2 from 10/11/2009 again! Now its happened again! Please, someone tell me how to get thunderbird to stop this madness! Welcome to the club - You seem to be facing the same issues as I have been facing ever since the TB3 betas hit Fedora. After things had somewhat smoothed since the inital Fedora release, with TB-3.0 (final) last week, things once again turn into close to being unbearable/unusable. Unfortunately, I don't know if who the culprit actually is: dovecot, TB3 or x86_64 or else. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: WTF is wrong with thunderbird????
On 12/22/2009 01:23 AM, Kevin J. Cummings wrote: On 12/21/2009 05:08 PM, Ralf Corsepius wrote: Welcome to the club - You seem to be facing the same issues as I have been facing ever since the TB3 betas hit Fedora. After things had somewhat smoothed since the inital Fedora release, with TB-3.0 (final) last week, things once again turn into close to being unbearable/unusable. Unfortunately, I don't know if who the culprit actually is: dovecot, TB3 or x86_64 or else. Me neither. I had none of these problems with the betas. Then again, I wasn't using mail filters then either. Now I am, and I'm also running the new TB3. My server has been running dovecot-1.2.8-4.0.cf (I've been putting off the atrpms 1.2.9 update hoping that city-fan would also put a 1.2.9 up for update.) The only *recent* change has been the new TB3 and the mail filters. Are you running thunderbird on the same machine as dovecot or are they running on separate machines? In my setup, I usually run thunderbird and dovecot-imap on the same x86_64 machine. Throughout yesterday, I worked on a different, i386-machine accessing dovecot-imap on my x86_64-machine, and haven't observed one these issues (yet?). Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: WTF is wrong with thunderbird????
On 12/22/2009 04:58 AM, Kevin J. Cummings wrote: On 12/21/2009 10:36 PM, Mail Lists wrote: On 12/21/2009 09:29 PM, Kevin J. Cummings wrote: Ralf This could be a GLODA bug ... please confirm it is off and of not try turning GLODA off and see if that helps. Edit - Preferences - Advanced General Unselect GLobal Indexing Not using it. (ie, its already off) Same here. It's off. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Fwd: rpms/perl/devel perl.spec,1.246,1.247
On 12/19/2009 04:29 AM, Chris Weyl wrote: Hmm. Sanity check here: are we sure just excluding these is the way we want to go? I certainly think so, otherwise I would not have applied the patches. Apart of this, my changes we emergency changes to get rid of broken package deps. Whether these changes shall be kept in long terms is a different matter - I certainly want them kept. I ask mainly as when we went to 5.10.0 we subsumed the newly-cored (dual-lifed, really) modules into the main perl package, and obsoleted the standalone packages. We also have a (more-or-less) policy of updating core modules via the main perl package as well. Yes, it's an ongoing struggle, because with some people prefer to enforce monolytic perl packaging and don't seem to want to comprehend the advantages module-wise packaging offers. I could go either way on this; but I think we should pick an approach and stick with it, unless there's compelling reasons otherwise... And the current approach seems to be working well. Really? I can't avoid to disagree - It doesn't work well at all. E.g. * The modules, perl now has absorbed, already exist as separate modules with higher versions in Fedora. * Many modules in core perl are outdated. These are the cause of many issues of rpm interaction with CPAN and are the cause of missing dependencies. Also... Even if we exclude these modules w/o providing them as sub-packages, we ought to ensure that they're still pulled in by perl-core (and perl itself, when we make the perl-core/perl/perl-minimal switch). What you say doesn't make sense: 1) They are provided as separate modules, by a) CPAN b) Fedora packages. 2) Since introducing the package split to perl, package deps on perl-packages in general don't make any sense anymore. It's the reason why we are enforcing BR: perl(xxx). Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Fwd: rpms/perl/devel perl.spec,1.246,1.247
On 12/19/2009 06:14 AM, Tom spot Callaway wrote: On 12/19/2009 12:07 AM, Ralf Corsepius wrote: Also... Even if we exclude these modules w/o providing them as sub-packages, we ought to ensure that they're still pulled in by perl-core (and perl itself, when we make the perl-core/perl/perl-minimal switch). What you say doesn't make sense: 1) They are provided as separate modules, by a) CPAN b) Fedora packages. Yes, but 1a has always been true, and 1b has been true in the past. We've generally opted to keep the bundled core modules as part of the main perl package to keep user and developer expectations sane. You mean the fact that RH has total control over perl-core enabled them to push through this policy? Feel free to waste your time to revert my changes and to enforce your policy. If the point is that the base perl modules get outdated, well, we've successfully patched those modules forward when there is a good reason to do so. Successfully? Right, occasionally somebody is wastings a considerable amount of time on merging one, but besides this, your statement couldn't be further from being true: * Many Fedora's core perl modules are outdated. * These mergers are the cause of having to waste bandwidth on perl-core updates, where module-updates would be sufficient otherwise. * Lack of mergers are the cause of perl-module packages not making it into Fedora. * Requests related to perl-core maintainers not tracking poterntial mergers (aka upgrade requests) is one cause of major inefficencies/churn in Fedora's perl maintenance. 2) Since introducing the package split to perl, package deps on perl-packages in general don't make any sense anymore. It's the reason why we are enforcing BR: perl(xxx). Yes, but perl upstream chose which modules to include with perl core. If we decide not to package a module, instead deferring to the separated package, we should make sure that the separated package gets installed if someone installs the perl-core metapackage. The way to do that is to add the hardcoded Requires. No, the solution is to tell people not to use perl-core and to forget about the fact it exists at all. Using perl-core is an anacronism. Seems to me as if this is too hard for some people to comprehend. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Tar oddity...
On 12/17/2009 11:51 PM, DB wrote: Hi All, I've just (re)installed F12 on my laptop, tried to copy my home directory (F11) from my desktop using tar. The create went OK, I can do tar tvh on the desktop no probs. But when I connect the external drive to the laptop, tar tvh says it's closing because of previous errors; ark refuses to open the .tar.gz file as it has errors. Please show us the actual error message. You are not providing sufficient details to be able to help. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: packages requiring me to reboot...
On 12/16/2009 06:34 PM, Seth Vidal wrote: On Wed, 16 Dec 2009, nodata wrote: Am 2009-12-16 18:21, schrieb Seth Vidal: On Wed, 16 Dec 2009, nodata wrote: we're talking about the experienced user who is comfortable knowing what does and does not need a reboot. All I'm saying is - we've not taken away any option, the experienced user can do what they want. -sv True, but the default should be sensible. And the default is sensible for the inexperienced user: Don't try to explain to the user how to restart the apps individually, tell them to bounce the box and it will be the right version when it comes back. -sv On the other hand I think requiring more reboots than Windows is a bad thing... Then I can think of a couple of solutions to this problem: 1. Have fewer update pushes per release - this is something I'm actively advocating and I think is possible Depends on what you actually have in mind. Simply letting update pile up would seem a silly idea to me, it contradicts Fedora's goal and removes what makes Fedora attractive. Letting pile up updates, which require a reboot, but are not addressig real bugs, could be applicable. 2. Match up more updates to a specific running app so we can see if the reboot is really necessary at all. - something else I've wrriten some code in support of. Yes, this would be helpful - But only in case of non-bugfix updates. Bug-fix updates should be pushed ASAP, IMO. 3. Having better tools to avoid reboots. (Consider daemons, servers). 4. Maintainers to be more careful/reluctant/conservative, when considering to update packages, which require a reboot. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On 12/14/2009 10:27 AM, Nicolas Mailhot wrote:
Le Dim 13 décembre 2009 22:35, Chris Adams a écrit :
As for the RAM overhead of 64 bit code vs. 32 bit code, I don't see it
much in the real world.
The worst case I've seen reported is when the RAM overhead managed to
annihilate register improvements (worst case in a very specific load). So RAM
overhead is pretty much a urban myth on x86_64
It's not an urban myth - Conversely, it can quite easily be proven:
int main()
{
long i;
void *array[100];
for ( i = 0; i 100; i++ ) {
array[i] = (void*) i;
};
while(1) {};
}
Compile this snippet for -m64/-m32:
# gcc -m64 -o test-64 -Wall test.c
# gcc -m32 -o test-32 -Wall test.c
Then run them and watch memory consumption (here top):
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
5909 corsepiu 20 0 11536 8128 248 R 100.0 0.4 0:16.93 test-64
5903 corsepiu 20 0 5560 4180 224 R 99.0 0.2 1:10.20 test-32
QED
Of course, this is an extreme case, but they also aren't that rare in
real world cases.
Ralf
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 12/09/2009 02:05 PM, Bruno Wolff III wrote: On Wed, Dec 09, 2009 at 06:51:59 +0100, Ralf Corsepiusrc040...@freenet.de wrote: Seems to me, as if some people in Fedora's leadership don't want to understand that being able to deploy Linux on old or recycled hardware used to be one big selling point in Linux. I think the question is really, is Fedora suitable for being deployed on older hardware? In its early days, it was. Currently it isn't (for some value of older). Ageed, it isn't anymore. As I feel, sarcasm Fedora has followed up Microsoft the Vista way /sarcasm Those using modern hardware may find this cool, those who don't, switch away to using different distros. I think if people wanted to try and make this happen, it could happen. sigh It wasn't a lot of work in the early Fedora day - It simply worked out of the box! /sign However, some $DEITY's have decided otherwise ... I am inclined to think inevitably, because such platforms aren't the platforms most developers use nor the platforms RHEL is aiming at ... These people think in terms of Quad machines and RH clients, but forget about the amount of old machines which are still actively being used and about use-case niches. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 12/09/2009 04:14 PM, James Antill wrote: On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote: So, yeh, if _you_ want to support slower machines Well, I do not want to, I can't avoid to ... ... _you_ will have to do the work, you might get help from the community but just ranting on f-d-l Everyone should solve my problems is unlikely to actually help. IMO. There is an easier solution: Stop using/promoting/advertising Fedora and switch to a different distro ... Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 12/09/2009 05:51 PM, Seth Vidal wrote: On Wed, 9 Dec 2009, Ralf Corsepius wrote: On 12/09/2009 04:14 PM, James Antill wrote: On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote: So, yeh, if _you_ want to support slower machines Well, I do not want to, I can't avoid to ... ... _you_ will have to do the work, you might get help from the community but just ranting on f-d-l Everyone should solve my problems is unlikely to actually help. IMO. There is an easier solution: Stop using/promoting/advertising Fedora and switch to a different distro ... okay, for you, that sounds like it may be the best option. You are obviously unhappy with fedora. Did I say this? I am unhappy with Fedora's management's decisions. Technically, Fedora is quite usable (most of the time), on more or modern machines. We've appreciated your constructive contributions but if you are no longer interested in working on/with fedora, then we wish you well in your endeavors. If I wasn't interested in Fedora, I wouldn't complain. It's just that Fedora increasingly diverges from my needs and increasingly is not applicable for my purposes. Less abstract: This development forces me to not recommend Fedora (or RHEL) to customers. It would be most polite to officially orphan your packages before you go. Thanks you for sheding more insights in how you intend to take community interests into account. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 12/08/2009 06:41 PM, drago01 wrote: On Tue, Dec 8, 2009 at 5:27 PM, Rallias UberNerd robinstar1...@gmail.com wrote: On Thu, 19 Nov 2009 17:39:16 -0600, Kevin Koflerkevin.kof...@chello.at wrote: Bill McGonigle wrote: Are you installing Fedora on the computer you're using now? [YES] [NO] YES - is any sort of check even possible if the user is running 32-bit on 64-bit? Yes, if the CPU has the lm (long mode) flag, it's a 64-bit-capable CPU and using the 32-bit version is suboptimal. Kevin Kofler But wouldn't it be better to use 32 bit when less then 4 GB of ram is present? no, using x86_64 means more registers, sse2 as default floating point instruction set, better calling convention (register passing vs. stack) or in other words in most cases faster code. That's one side, the other side is: * Larger demands on RAM (x86_64 is more demanding on memory requirements). * More packages (rpms) to cope with. * The faster is hardly sensible to ordinary users. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 12/08/2009 09:26 PM, Ville Skyttä wrote: On Tuesday 08 December 2009, Kevin Kofler wrote: Ralf Corsepius wrote: * More packages (rpms) to cope with. Only if you pollute your system with 32-bit multilibs. A pure x86_64 system doesn't have any more packages than a 32-bit one. Fedora x86_64 repos do however carry ix86 packages around which shows in metadata sizes and I guess to some extent in performance of some yum operations. and in ... ... bandwidth demands ... ... package dep conflicts resolution ... ... maintenance efforts (At the very point you have one true 32bit-only capable machine around, installing x86_64 on a single machine means duplicating the maintenance effort). These probably aren't things to be generally overly concerned about though, ... try a yum update over GSM or over a modem and you'll very soon experience what I am talking about. and maybe not even what Ralf meant (he specifically mentioned rpms). I was indirectly referring to this (c.f. another thread on this list earlier this week). Ralf -- 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 12/03/2009 07:22 AM, Jesse Keating wrote: On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote: People doing network installs can either add the updates repo to their kickstart, or check the box in the anaconda UI, so that the updates repos are considered at install time. No download of duplicate data. Yes, for people who are doing full featured networked installs w/ custom kickstart files. I've never met such a person. Really? I meet people who use kickstart all the time. May-be internal at RH? Any sizable deployment of Fedora/RHEL uses or should use kickstart. And those that don't aren't afraid to check that little 'updates' box at the software selection screen. You seemed to have ignored that part of my point. No, I didn't. It's just that unless this little check button is the default, many users will ignore it or as in my case ... I am normally yum-upgrading between distros and rarely use anaconda. In fact, having separate repos would likely cost less bandwidth. If we only had one combined repo, there would be many duplicate packages, Where? Unlike now, where you have each package twice (in Everything and updates), you would have each package only once: In Everything. That assumes we purge anything but the latest version of a package, Correct. which as noted in other parts of this thread gets complicated with GPL compliance. Not necessarily - E.g. it would be GPL compliant to store purged packages outside of the current repos. And whether spins and the way they currently are implemented is good/feasible/reasonable is a different question. = An estimate for the increase in downloaded files's sizes you are talking about is ca. factor 2, from 18.2M (current updates) to 32.8M+ (current Everything+newly introduced packages) Whether this increase in download-size is significant is up to the beholder. For me, it gets lost in the noise of accessing a good or a bad connection to a mirror and in the time required to download packages from mirrors. 33~ megs downloaded every single time an update is pushed is a significant hit for a fair number of people. Yes, but ... some more figures: The same figures as above for FC10: = Everything: 25.8M = updates: 18.5M = A rough estimate for sizes of repodata for a near EOL'ed Fedora: 70% of the size of Everything's repodata. I.e. should this estimate apply to later Fedoras, Fedora 11 users are likely to see 70% of 33MB = 23MB near EOL of Fedora 11. That was why it was important to make yum not re-fetch that repodata every time, and use a cached version of it. Yes, the keys to minimize bandwidth demands would be * to shink the size of the repodata/-files * to shink the size of changes to them. Besides obvious solutions, such as using a different compression (e.g. xz instead of bz2) and minimizing their contents, one could ship repodata/-files in chunks. What I mean: In theory, one could * update repodata/-files incrementally by shipping some kind of deltas. * split repodata/-files into several, e.g. sorted by some other criteria, i.e. to provide several sets of *-[primary,filelist,other] files. One package push, then would only affect a subset of the files, but not all. - This is very similar to what (IIRC) Seth had proposed (Split the repo into several repos, alphabetically), except that the split would happen inside of repodata and thus be transparent to users. I am not sure how difficult to implement this would be. Ralf -- 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 12/05/2009 06:22 AM, Orion Poplawski wrote: On Fri, December 4, 2009 9:20 pm, Ralf Corsepius wrote: On 12/03/2009 07:22 AM, Jesse Keating wrote: On Thu, 2009-12-03 at 06:24 +0100, Ralf Corsepius wrote: Yes, for people who are doing full featured networked installs w/ custom kickstart files. I've never met such a person. Really? I meet people who use kickstart all the time. May-be internal at RH? I do every install via kickstart - small company with 30-50 machines. Been doing fedora+everything+updates installs for many releases now. OK, then it's likely a full time professional admins vs. part time/side-job admins and home-users thing. Ralf -- 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 12/02/2009 03:39 PM, 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. So your proposal is to drop updates, but to add updates to Everything? In this case, I am all for it. Ralf -- 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 12/02/2009 06:01 PM, Casey Dahlin wrote: On Wed, Dec 02, 2009 at 11:06:22AM -0500, Josh Boyer wrote: 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? This is true. It is not true. * It shifts costs from users to vendor and from mirrors to master. * It helps users who are using networked installs to spare bandwidth (avoids downloading obsolete packages from Everything/Fedora). Admitted, for most users, it would change almost nothing. Ralf -- 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 12/02/2009 06:40 PM, Jesse Keating wrote: On Wed, 2009-12-02 at 18:09 +0100, Ralf Corsepius wrote: * It shifts costs from users to vendor and from mirrors to master. * It helps users who are using networked installs to spare bandwidth (avoids downloading obsolete packages from Everything/Fedora). Admitted, for most users, it would change almost nothing. People doing network installs can either add the updates repo to their kickstart, or check the box in the anaconda UI, so that the updates repos are considered at install time. No download of duplicate data. Yes, for people who are doing full featured networked installs w/ custom kickstart files. I've never met such a person. In fact, having separate repos would likely cost less bandwidth. If we only had one combined repo, there would be many duplicate packages, Where? Unlike now, where you have each package twice (in Everything and updates), you would have each package only once: In Everything. It would help people like me, who are locally reusing downloaded packages in a networked environment, instead of letting each machine accesses the original repos directly. especially if we went the route of having updates-testing mixed in and only marked by some update tag. Updates-testing is an add-on repo to Everything+updates. A merged new Everything would not change anything wrt. updates-testing. The only difference would be packages being pushed to Everything instead of updates. We'd have to keep sets of what's in updates-testing, updates, and the GA release set, and all of that would be in one repodata set. Everybody doing a network install, whether they wanted updates, updates-testing, or not would have to download and consume that larger repodata, introducing a higher cost for them. Your concern is the bigger repodata? Reality check: # ls -h -s releases/11/Everything/x86_64/os/repodata/*.sqlite.bz2 updates/11/x86_64/repodata/*.sqlite.bz2 16M releases/11/Everything/x86_64/os/repodata/0301ed1cbf01c00cdf9c42b71df6c74947d9c76a3c9767e8f85a99ef6fdccb86-filelists.sqlite.bz2 11M releases/11/Everything/x86_64/os/repodata/6a8bfab8ebcbc79f9827f5b16bc1bd1573c068f141bf47c6f216e72dd8b60ff0-primary.sqlite.bz2 5.8M releases/11/Everything/x86_64/os/repodata/d3405c970a0c27e9dc3fd3ed179af33fee9a72bf704f45f1ed96a9063b40d7c7-other.sqlite.bz2 9.0M updates/11/x86_64/repodata/3a725e07adff9d7e56e7fd8bd3091f38107723987b3b614220df72494dc6814d-filelists.sqlite.bz2 6.0M updates/11/x86_64/repodata/54ca116c2a00e87eaca6491adb9e077f4d3f0d5b20e7cbab984774aefb042d0f-primary.sqlite.bz2 3.2M updates/11/x86_64/repodata/646eb24cfe113de569853a4e05f55773b3ad9531dee646e7d843b8dc4a849780-other.sqlite.bz2 = An estimate for the increase in downloaded files's sizes you are talking about is ca. factor 2, from 18.2M (current updates) to 32.8M+ (current Everything+newly introduced packages) Whether this increase in download-size is significant is up to the beholder. For me, it gets lost in the noise of accessing a good or a bad connection to a mirror and in the time required to download packages from mirrors. On the other hand, the content (the packages referenced inside) of updates overlaps with packages in Everything = The number of packages to be considered in dep-computation should become much (?) smaller. However, I am not knowledgable enough with yum's internals to estimate the impact this would have on turnaround-times, memory and diskspace requirements this would have on yum. Ralf -- 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 12/02/2009 07:09 PM, Seth Vidal wrote: the merger of repos is already happening at the yum layer. On the client's side - With a combined Everything+updates, this would happen on the server side. It's one of the aspects which made me said a combined Everything+updates shifts costs from client to server. Ralf -- 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 12/03/2009 06:32 AM, Seth Vidal wrote: On Thu, 3 Dec 2009, Ralf Corsepius wrote: On 12/02/2009 07:09 PM, Seth Vidal wrote: the merger of repos is already happening at the yum layer. On the client's side - With a combined Everything+updates, this would happen on the server side. It's one of the aspects which made me said a combined Everything+updates shifts costs from client to server. except they wouldn't be merged on the server side -it would just be additive. We wouldn't be talking about removing the original GA set - just adding updated pkgs into the path. Woa!!! With all due respect, but this would seem an stupid and silly plan to me. So you'd still have the number of pkgs -just all in one repo, that you have to download all of the metadata for all of the more often, despite that 15K of them don't CHANGE. this is why it is less good for our users. Yes - cf. above. I have nothing to add. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On 11/25/2009 01:13 PM, Jeroen van Meeuwen wrote: On 11/25/2009 08:38 AM, Nicu Buculei wrote: Instead of this I would pretty much like to have the normal install DVD being full (4GB, instead of 3.0-3.3GB as now), so when installing a computer I have more content on local media and less stuff to get from online sources, resulting in a shorter time until the computer is fully usable. You might want an Everything spin ;-) ... or an install using a local copy of Everything on local network or machine-local filesystem [1] It's what I had been using when I only had low bandwidth access[1]. Ralf [1] I live in a DSL white spot ;-) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Is F12 ready to upgrade ? Is it worth it ?
On 11/25/2009 05:13 PM, Linuxguy123 wrote: I'm perplexed by the posts I am seeing regarding F12 upgrades. Lots of upgrade issues and darn faint praise as far as I can tell ? AFAICT, almost all of the upgrade issues are related to preupgrade demands on /boot's sizes ;-) I was expecting a totally different response. Except of the usual issues related to FC12 shipping older packages than FC11 and the usual side effects of other packaging bugs, for me upgrading from FC11 to FC12 went comparatively smooth. Is F12 stable enough to warrant upgrading to it ? So far, I haven't had many issues. Actually to me, current FC12 appears more stable than last week's FC11 before upgrading. Of course, YMMV. Is it a worthwhile upgrade at this point ? I would say so, yes, it is worth it. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: [RFA] Your [PACKAGE_NAME] did not pass QA
On 11/23/2009 09:00 PM, Nicolas Mailhot wrote: Le lundi 23 novembre 2009 à 13:48 -0600, Chris Adams a écrit : Once upon a time, Nicolas Mailhotnicolas.mail...@laposte.net said: Le lundi 23 novembre 2009 à 09:51 -0700, Jerry James a écrit : 1) I'm going to nag you forever about a problem you can't fix. This is false, it can get fixed, either with code changes or by dropping the offending package Core fonts are not going away, are they? The infra no, the fonts (or at least part of them) yes a) Who do you think you are to decide so? b) Any pressing _technical_ need to do so? Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 11/20/2009 09:02 AM, Nicu Buculei wrote: On 11/19/2009 08:14 PM, Jesse Keating wrote: On Thu, 2009-11-19 at 18:45 +0100, Ralf Corsepius wrote: You must not confuse moblin with netbooks, nettops or with i386/32bit machines in general. The moblin desktop is addressing a completely different audience. Oh? That's not what I got from http://fedoraproject.org/wiki/Features/FedoraMoblin Moblin is not about hardware, you can run it on a powerful 64 bit desktop, while my netbook is perfectly able to run a normal GNOME desktop. Moblin is about users, made for those with a small set of basic needs, which in many cases are people using netbooks or less powerful hardware, but there are a lot of other user cases for such hardware, beyond Moblin. Exactly. As I tried to express several times before in this thread: Moblin is addressing and entirely different use-case. Whether this use-case of interest in individual situations is a different question - To some it might be interesting, to me, it is not. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 11/20/2009 11:58 AM, Peter Robinson wrote: IMO, they are targetting MID devices, competing with Android, Smart phones and similar. Not at the moment they're not/ Then please explain what they are targetting. So far, all of Moblin I have seen was them trying to turn a multi-user environment/desktop into a single-user, Smart-phone/Kiosk-like desktop. That's a completely different audience as I am talking about: People using netbooks, nettops and old i386s as inexpensive, secondary machine for everyday, low end desktop usage, such as browsing the web, word processing, presentations, photo browsing etc. They are targeting Netbooks for the online type of device. What is this? UTMS, WLAN, LAN, Bluetooth etc.? How is this kind of device different from an ordinary desktop with UTMS, WLAN, LAN, Bluetooth ...? They are targeted at web browsing, Social Networking, Media (Audio/Video/Photos) and Instant messaging running on small inexpensive netbook devices. They will do presentations and word processing quite happily as well as it based on gtk and clutter so all the usual gnome apps will run but that's not the main target. In my understanding this is exactly the same target audience as all other desktop installations address - So, why does it exist? Getting rid of the multi-user overhead, turning Linux into Windows? Catering the the Telcos to address the TelCos' audiences? This would be the Smartphone/Android etc. audience. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 11/19/2009 07:14 PM, Jesse Keating wrote: On Thu, 2009-11-19 at 18:45 +0100, Ralf Corsepius wrote: You must not confuse moblin with netbooks, nettops or with i386/32bit machines in general. The moblin desktop is addressing a completely different audience. Oh? That's not what I got from http://fedoraproject.org/wiki/Features/FedoraMoblin It's what I get from this web-page and what I got from testing the original Moblin desktop. IMO, they are targetting MID devices, competing with Android, Smart phones and similar. That's a completely different audience as I am talking about: People using netbooks, nettops and old i386s as inexpensive, secondary machine for everyday, low end desktop usage, such as browsing the web, word processing, presentations, photo browsing etc. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 11/20/2009 06:31 AM, Rahul Sundaram wrote: On 11/20/2009 08:22 AM, Ralf Corsepius wrote: On 11/19/2009 07:14 PM, Jesse Keating wrote: On Thu, 2009-11-19 at 18:45 +0100, Ralf Corsepius wrote: You must not confuse moblin with netbooks, nettops or with i386/32bit machines in general. The moblin desktop is addressing a completely different audience. Oh? That's not what I got from http://fedoraproject.org/wiki/Features/FedoraMoblin It's what I get from this web-page and what I got from testing the original Moblin desktop. IMO, they are targetting MID devices, competing with Android, Smart phones and similar. That's a completely different audience as I am talking about: People using netbooks, nettops and old i386s as inexpensive, secondary machine for everyday, low end desktop usage, such as browsing the web, word processing, presentations, photo browsing etc. User experience part of the page says Users of the Fedora Moblin Spin would have a much better user experience on their NetBook, NetTop and other small devices That's what the marketing department wants it to be. Reality speaks a different language: * People are using their everyday desktop even on low end machines and do not want to fiddle around with custom netbooks desktops. * People consider their low end machine's performance sufficient for such use-cases. The essentially the same rationale/reason why netbooks/nettops with WinXP have been a huge success and why netbooks with custom desktops were a failure. Ralf -- 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 11/17/2009 09:08 AM, Thorsten Leemhuis wrote: Henrique Junior wrote on 16.11.2009 23:57: I have a question that may sound a little stupid, but that came as I write a short article about some Fedora's curiosities. Why are our packages still using the tag f*c*X, f*c*Y, f*c*W since Fedora does not use “*Core*” in his name anymore? I know it's an almost irrelevant question, but the article is just about small curiosities and I could not think in a better place to ask. I don't care much about the c, but we IMHO really should get rid of a disttag in rawhide that is related to the release cycle when a package got build. Only then we can avoid confusion like why are there packages with .fc11 on my F12 machine/in the F12 repos which IMHO come up way to often and seem to highly confuse people. I still vote for using .1 as %dist in rawhide all the time(¹), as that is higher then (for example) .fc12(²). But that suggestion was shot down last time I brought it up one or two years ago. IMO, this proposal is silly and was shot down for valid reasons. Has anybody any better idea? Keep things as they are. I don't see any reason for any change. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken deps for rawhide the past few days
On 11/16/2009 08:22 PM, Jesse Keating wrote: Many of you received emails over the weekend and this morning regarding broken deps in rawhide. If these emails mentioned that the deps were broken on ppc or ppc64 they can be ignored. We are no longer producing ppc/ppc64 as a primary arch, however we forgot to tag the config change that enacted this on our compose tools. We were attempting to compose ppc(64) trees with only noarch packages, and well things didn't work so hot. We should have this fixed today so that future emails about broken deps will be about actual broken deps, not broken configurations. Sorry for the mailbombing. Seems as if you once more failed to fix this. The 4th flood of mail (ca. 1200 each) seems to be underway. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies script at it again
On 11/14/2009 05:12 PM, Paul Howarth wrote: Please make it stop. +1 ... ... so far, I've received ca. 1200 of these mails and the figure is still growing by the minute. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies script at it again
On 11/14/2009 10:12 PM, Mike McGrath wrote: On Sat, 14 Nov 2009, Henrique Junior wrote: +1 Are people +1'ing getting rid of the broken dependencies script altogether? or +1'ing to predicting the future and stopping it before it breaks? No, it's raising hands to a) draw attention of those persons who flipped this switch this time. b) draw attention of those persons who have the means to take countermeasures against the damage this flipping the switch had. c) to draw attention of those persons, who are in charge to supervise those persons who flipped this switch this time. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: should I go for 64bit version of Fedora 11 ?
On 11/03/2009 08:38 AM, Jatin K wrote: Dear all I've purchased a new Dell laptop Vostro 1520, major configuration[1] , My question is should I go for FC 11 64bit version ? Depends on what you plan to use this notebook for. is there any significant benefit if I use 64bit version ? In theory, there are benefits to use the 64bit version. In practice, these benefits (esp. on a desktop notebook) are hardly measurable and can easily be outweighed by other factors attached to 64bit. So, my answer to your question: Provided how you ask, you likely don't have real uses for 64bit. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: firefox 3.5.4 broken?
On 10/30/2009 12:26 AM, Michael Cronenworth wrote: 1. Highlight a word on a web page. 2. Right click on word. 3. Select Search Google for word... 4. ??? 5. Crash box appears. Anyone else? I am not observing this issue, but I already had 2 firefox segfaults and one firefox desktop freeze since today's firefox update. Seems to me as if firefox is try to play catchup with the embarrassing shape thunderbird is in :( Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: firefox 3.5.4 broken?
On 10/30/2009 04:25 PM, Antonio M wrote: 2009/10/30 Ralf Corsepiusrc040...@freenet.de: On 10/30/2009 12:26 AM, Michael Cronenworth wrote: 1. Highlight a word on a web page. 2. Right click on word. 3. Select Search Google for word... 4. ??? 5. Crash box appears. Anyone else? I am not observing this issue, but I already had 2 firefox segfaults and one firefox desktop freeze since today's firefox update. Seems to me as if firefox is try to play catchup with the embarrassing shape thunderbird is in :( It works fine here, Well I can reproduce the segfaults semi-deterministically: http://www.paulmccartney.com Firefox-3.5.4 either immediately dies, or dies after a little bit of browsing. also with Thunderbird running in the background... I am observing * corrupt indices and random email tagging. * compact folders not wanting to traverse deep imap folders. * filtering issues Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: firefox 3.5.4 broken?
On 10/30/2009 05:20 PM, Michael Cronenworth wrote: Aaron Konstam on 10/30/2009 09:17 AM wrote: I am getting and Assert error when I do the above. You need to restart Firefox. P.S. This thread is closed. ;) You mean, works for you ;) Here is a back trace of a segfault which just happend to me: #0 0x00318900edab in raise () from /lib64/libpthread.so.0 Missing separate debuginfos, use: debuginfo-install firefox-3.5.4-1.fc11.x86_64 (gdb) where #0 0x00318900edab in raise () from /lib64/libpthread.so.0 #1 0x7f0def88 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #2 signal handler called #3 0x in ?? () #4 0x7f0def43044b in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #5 0x7f0def4365d1 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #6 0x7f0def436c84 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #7 0x7f0def43b0b4 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #8 0x7f0def43b424 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #9 0x7f0def3bbecc in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #10 0x7f0def3bc098 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #11 0x7f0def3bbecc in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #12 0x7f0def3ce256 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #13 0x7f0def3d6006 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #14 0x7f0def664023 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #15 0x7f0def6646e7 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #16 0x7f0def664cb5 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #17 0x7f0def66019d in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #18 0x7f0defa15fed in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #19 0x7f0defa1f7c7 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #20 0x7f0defa1fbc8 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #21 0x003069349b63 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #22 0x003066e0b81e in g_closure_invoke () from /lib64/libgobject-2.0.so.0 ---Type return to continue, or q return to quit--- #23 0x003066e20b43 in ?? () from /lib64/libgobject-2.0.so.0 #24 0x003066e21d6c in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #25 0x003066e22423 in g_signal_emit () from /lib64/libgobject-2.0.so.0 #26 0x00306946739f in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #27 0x003069341f3c in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0 #28 0x003068638052 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #29 0x003068638971 in gdk_window_process_all_updates () from /usr/lib64/libgdk-x11-2.0.so.0 #30 0x003068638999 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #31 0x00306861c906 in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #32 0x003066a3790e in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #33 0x003066a3b0e8 in ?? () from /lib64/libglib-2.0.so.0 #34 0x003066a3b20a in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #35 0x7f0defa36a83 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #36 0x7f0defa36b8f in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #37 0x7f0defaf1af2 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #38 0x7f0defac3187 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #39 0x7f0defa36ccd in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #40 0x7f0def8e1f64 in ?? () from /usr/lib64/xulrunner-1.9.1/libxul.so #41 0x7f0def21c4b4 in XRE_main () from /usr/lib64/xulrunner-1.9.1/libxul.so #42 0x00402616 in mmap () #43 0x00318841ea2d in __libc_start_main () from /lib64/libc.so.6 #44 0x00401e29 in mmap () #45 0x7fff4277a348 in ?? () ---Type return to continue, or q return to quit--- #46 0x001c in ?? () #47 0x0001 in ?? () #48 0x7fff4277b2d6 in ?? () #49 0x in ?? () Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: firefox 3.5.4 broken?
On 10/30/2009 06:03 PM, Patrick O'Callaghan wrote: On Fri, 2009-10-30 at 16:38 +0100, Ralf Corsepius wrote: Well I can reproduce the segfaults semi-deterministically: http://www.paulmccartney.com Firefox-3.5.4 either immediately dies, or dies after a little bit of browsing. The standard response to FF problems is have you tried running it in safe-mode? I'm surprised no-one has said it so far. Many problems are actually caused by plugins rather than FF itself. True - nevertheless, if a plugin is able to tear down firefox, firefox itself is broken, too. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: firefox 3.5.4 broken?
On 10/30/2009 07:38 PM, Patrick O'Callaghan wrote: On Fri, 2009-10-30 at 18:20 +0100, Ralf Corsepius wrote: On 10/30/2009 06:03 PM, Patrick O'Callaghan wrote: On Fri, 2009-10-30 at 16:38 +0100, Ralf Corsepius wrote: Well I can reproduce the segfaults semi-deterministically: http://www.paulmccartney.com Firefox-3.5.4 either immediately dies, or dies after a little bit of browsing. The standard response to FF problems is have you tried running it in safe-mode? I'm surprised no-one has said it so far. Many problems are actually caused by plugins rather than FF itself. True - nevertheless, if a plugin is able to tear down firefox, firefox itself is broken, too. Not so. Plugins and extensions don't run in a sandbox in current versions of FF. Future versions will be different. You don't have to have a sandbox for this. All that would be required is a bit of more or less sophisticated error handling/signal catching. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: firefox 3.5.4 broken?
On 10/31/2009 05:35 AM, Patrick O'Callaghan wrote: On Sat, 2009-10-31 at 03:52 +0100, Ralf Corsepius wrote: Not so. Plugins and extensions don't run in a sandbox in current versions of FF. Future versions will be different. You don't have to have a sandbox for this. All that would be required is a bit of more or less sophisticated error handling/signal catching. A semantic quibble. No. Error handling is a matter of a program's fundamental design. Unfortunately it's a subject many programmers don't take into account. The point is that the architecture has to be designed to deal with arbitrary behaviour on the part of plugins or extensions and currently it isn't. May-be, I am not familiar with firefox's source-code. Anyway, to me this reads as firefox suffers from substantial fundamental design flaws :( Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: How does one remove the nvidia driver and install nouveau ?
On 10/23/2009 04:01 PM, Linuxguy123 wrote: On Fri, 2009-10-23 at 08:38 -0400, Matthew Saltzman wrote: Run 'livna-config-display --active off' to prevent the starutp script from modifying xorg.conf. Then edit xorg.conf and change the driver from 'nvidia' to 'nouveau'. The reboot. I think that'll do it. It didn't. I did this and rebooted and nvidia still runs. What else do I need to do ? Run nvidia-config-display disable and reboot To turn it on again: nvidia-config-display enable and reboot Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: How does one remove the nvidia driver and install nouveau ?
On 10/23/2009 04:29 PM, Linuxguy123 wrote: On Fri, 2009-10-23 at 16:14 +0200, Ralf Corsepius wrote: Run nvidia-config-display disable and reboot It didn't work. $ lsmod | grep vid nvidia 9579020 40 video 18744 0 uvcvideo 50572 0 videodev 29612 1 uvcvideo i2c_core 25024 2 nvidia,i2c_i801 v4l1_compat12048 2 uvcvideo,videodev output 2476 1 video $ lsmod | grep nouveau nothing yum install x Now what do I do ? I was running akmod, I am using the rpmfusion packages. which presumably builds an nvidia kernel module. Do those modules get loaded automatically ? If so, how does one remove an akmod build kernel module ? Ie how does one do a 'make uninstall' for an akmod module ? Sounds as if your installion is somehow broken. What actually is broken is hard to tell. Normally you can have the xorg-x11-drv-nouveau package and rpmfusion's nvidia drivers installed in parallel and switch between both drivers. May-be you need to run system-config-display? Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: How does one remove the nvidia driver and install nouveau ?
On 10/23/2009 04:29 PM, Linuxguy123 wrote: On Fri, 2009-10-23 at 16:14 +0200, Ralf Corsepius wrote: Run nvidia-config-display disable and reboot It didn't work. $ lsmod | grep vid nvidia 9579020 40 video 18744 0 uvcvideo 50572 0 videodev 29612 1 uvcvideo i2c_core 25024 2 nvidia,i2c_i801 v4l1_compat12048 2 uvcvideo,videodev output 2476 1 video $ lsmod | grep nouveau nothing I think, I misunderstood your remark. Unlike the nvidia driver, the nouveau driver doesn't have a kernel module. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Are packages w/o necessary kernel modules allowed?
On 10/14/2009 03:04 PM, Peter Lemenkov wrote: Hello All! Imagine an application, which relies on a specific kernel module. This module is not a part of stock Fedora kernel (at least, yet), and we don't allow stand-alone kernel modules. Whether or not this package can be allowed? IMO: no. Packages in Fedora should just work and therefore must not rely on anything which is not in Fedora. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On 10/14/2009 05:47 PM, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. Is there a thunderbird-2.0 package for F11? For me, all thunderbird-3.*'s in FC11 were simply too bugged to be usable (The UI changes are not an issue for me - for me, TB3 is simply too bugged to be usable). I already considered to add FC10's or CentOS's TB to a local repository and to look into ways to blacklist TB3 in yum. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Are packages w/o necessary kernel modules allowed?
On 10/14/2009 06:30 PM, Richard W.M. Jones wrote: On Wed, Oct 14, 2009 at 05:29:13PM +0200, Ralf Corsepius wrote: On 10/14/2009 03:04 PM, Peter Lemenkov wrote: Hello All! Imagine an application, which relies on a specific kernel module. This module is not a part of stock Fedora kernel (at least, yet), and we don't allow stand-alone kernel modules. Whether or not this package can be allowed? IMO: no. Packages in Fedora should just work and therefore must not rely on anything which is not in Fedora. Well I don't think this should be a hard and fast rule. Then our opions diverge: I think it should be a hard show stopper criterion. There should not be any room for any cripple ware in Fedora nor should Fedora be a stage for closed source loaders. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On 10/11/2009 11:29 AM, Tim Lauridsen wrote: On 10/11/2009 11:16 AM, Jeff Garzik wrote: On 10/11/2009 04:54 AM, Rahul Sundaram wrote: It was ok to ship a beta release of thunderbird but updates shouldn't cause such issues. If the fixes were necessary to push as updates then it would have prudent to disable smart folders and indexing by default and leave it enabled in Fedora 12. Precisely. F11 is supposed to be a stable release. The sudden appearance of both smart folders and indexing was unexpected, disruptive and IMO did not achieve the desired quality level for a Fedora stable release upgrade. ACK, but ... There is a difference between stable and static, if we have a beta of thunderbird in F11, then it expected to change between beta releases. ... to me, in this context stable should also imply sufficently functional rsp. near release quality. From my experiences with the thunderbird-3*betas in F11, this does not apply to any of the thunderbird we had in F11 [1]. The new search features are very cool, we should be happy someone uses the time to give us all this cool new features. Well, coolness is relative - It's a feature, I have never missed or been waiting for :-) Ralf [1] I have been (and still am) facing: Corrupted (imap) mail-indices, mal-formated subject lines, being unable to send non-base64 encoded attachments, sth. occasionally producing duplicate mails and several other nuisances (e.g. one core dump at average per day). New with 3*b4: A significant slowdown, seemingly due to indexing at startup, compacting folders triggers warnings in deep imap-folders (used to work with older thunderbirds and still works with evolution). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
On 10/10/2009 01:48 AM, Orcan Ogetbil wrote: On Fri, Oct 9, 2009 at 7:29 PM, Christoph Wickert wrote: Am Freitag, den 09.10.2009, 18:56 -0400 schrieb Neal Becker: What if the generated docbook documents are different due to different ids? Do we need to separate the docs into a noarch subpackage? Nope, this doesn't actually help. The actual fix would be to fix docbook[1] rsp. these docbook-documents' sources to not apply ids rsp. to produce deterministic ids. An alternative work-around would be to filter out/process (e.g. by using sed) these ids, such the generated docs can be generated deterministically. Last resort would be to move such docs into arch' dependent directories in arch-dependent packages. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Rpmfusion?
On 10/06/2009 11:37 AM, Erik P. Olsen wrote: What has happened to rpmfusion? Its web site and download site seem to be gone. Same for me. I guess on a serious dns problem somewhere. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Rpmfusion?
On 10/06/2009 12:07 PM, Aioanei Rares wrote: On Tue, 2009-10-06 at 12:04 +0200, Ralf Corsepius wrote: On 10/06/2009 11:37 AM, Erik P. Olsen wrote: What has happened to rpmfusion? Its web site and download site seem to be gone. Same for me. I guess on a serious dns problem somewhere. Ralf I can access the site, but not the repos. Maybe this should be reported somewhere? Well, I can access a site as www.rpmfusion.org, but whether it's real rpmfusion.org, I can't tell. NSlookups for other subdomains for rpmfusion.org fail: # nslookup mirrors.rpmfusion.org Server: 127.0.0.1 Address:127.0.0.1#53 ** server can't find mirrors.rpmfusion.org: NXDOMAIN # nslookup download1.rpmfusion.org Server: 127.0.0.1 Address:127.0.0.1#53 ** server can't find download1.rpmfusion.org: NXDOMAIN # nslookup www.rpmfusion.org Server: 127.0.0.1 Address:127.0.0.1#53 Non-authoritative answer: Name: www.rpmfusion.org Address: 195.10.6.129 # nslookup 195.10.6.129 Server: 127.0.0.1 Address:127.0.0.1#53 Non-authoritative answer: 129.6.10.195.in-addr.arpa name = se01.es.rpmfusion.net. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
yum update vs. blender
Hi, today's yum update came along with this: # yum update ... Updating : blender-2.49b 1.fc11.x86_64 16/57 Unknown media type in type 'all/all' Unknown media type in type 'all/allfiles' Unknown media type in type 'uri/mms' Unknown media type in type 'uri/mmst' Unknown media type in type 'uri/mmsu' Unknown media type in type 'uri/pnm' Unknown media type in type 'uri/rtspt' Unknown media type in type 'uri/rtspu' Unknown media type in type 'fonts/package' Unknown media type in type 'interface/x-winamp-skin' ... Cleanup: blender-2.49a-1.fc11.x86_64 48/57 Unknown media type in type 'all/all' Unknown media type in type 'all/allfiles' Unknown media type in type 'uri/mms' Unknown media type in type 'uri/mmst' Unknown media type in type 'uri/mmsu' Unknown media type in type 'uri/pnm' Unknown media type in type 'uri/rtspt' Unknown media type in type 'uri/rtspu' Unknown media type in type 'fonts/package' Unknown media type in type 'interface/x-winamp-skin' What is this? Seems to me, as is something is very broken with blender's scriptlets? Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: anyone out there still using NIS?
On 09/26/2009 08:48 AM, Robert P. J. Day wrote: i'm putting together a tutorial on network services, and i'm really uninterested in investing any time in covering NIS. anyone out there still using it? is it worth it? Yes to both. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: #! /usr/bin/perl preferred
On 08/28/2009 10:07 PM, Stepan Kasal wrote: Hello, let me explain. I was told they are doing this env clenup with python scripts don't you want to do it for perl as well? Then let me add: The FPC had discussed this topic during its last meeting and didn't agree upon the proposal. cf. http://meetbot.fedoraproject.org/fedora-meeting/2009-08-19/fedora-meeting.2009-08-19-16.01.log.html#l-38 for details. My hands were quicker than my brain and I did the search. Only when I was about to post the results, I realized that I'm actually not convinced about the issue. The official reasoning is that if a system tool is written in Python, we want to guarantee that it works, so we would rather run it with Fedora Python, not with a random experimental Python. Likewise for Perl; if logrotate or some such were written in perl, it should just work (modulo Fedora Perl bugs), and the whole system should not crash just because of a random /usr/local/bin/perl. Well, yes there are ways for users to shoot themselves into the foot. As I wrote many times, installing to /usr/local is special, ... don't do it unless you know what you are doing ;-) Actually, what Chris said seems to support this reasoning: [...], especially as we can't replace the system Perl as it may have OS implications. Of cause, envs bears some risks to shot yourselves into the foot - it's a double side sword, with pros and cons at the same time. For example, a user might have a customized perl-script (e.g. a perl wrapper) installed on his $PATH (e.g. to ~/bin), because he isn't root on a particular system and is developing a perl application. At this point of time, I do not see any flaw in Ralf's reasoning. But I do not want to engage in any war. It's not necessarily a war. Both, allowing and disallowing env come at price. It's a descison to balance the pros and cons. The big question is: Would disallowing env mean be a true improvement (e.g. wrt. system robustness and safety) or would it mean a serious usability regression wrt. flexibility to developers? Some people say this way, others say that way. I for one (as a developer), prefer the flexibility env provides and do not see serious risks nor do I see many advantages in disallowing env. An uneducated user will always be able find ways to shoot himselves into the foot and needs to go through a learning curve - This might be an unpopular thought, but ... as trivial as it is, it's not avoidable. Let's forget about this and return to more important issues. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: #! /usr/bin/perl preferred
On 08/28/2009 04:11 PM, Stepan Kasal wrote: Hello, at certain periods of time, it was recommended to use #!/usr/bin/env . Some people consider it ugly. (The humble opinion of the author of this mail is the same.) My opinion is converse. Actually I think _you_ (as a perl maintainer) are shooting yourselves into your own foot. Consider you have another perl installed in parallel the official vendor perl and want to test a particular application suite with it. Using env you can simply use your experimental perl. Removing it, you will normally have to edit all of your applications' scripts, etc. Not necessarily nice! Currently there is popular mood to remove /usr/bin/env python, see http://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython Sigh, ... the mob rules? To me, this campaign goes much too far. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Proposed F12 perl cleanups
On 08/15/2009 09:00 PM, Tom spot Callaway wrote:
Out of the thread on p5p, I'd like to propose the following changes for
F-12:
* Rename perl-core to perl
* Rename perl to perl-minimal
The biggest change here is that there are still packages which Require:
perl, usually to specify a specific minimal version. Here is a list of
rawhide packages which do this:
With this change, these packages will have a larger installation
footprint, unless they're cleaned up. Instead of:
Requires: perl
or
Requires: perl 5.6.0
They should either have:
1. If they're version dependent, they should have
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
2. If they're not, they could either accept the larger install
footprint, or switch to:
Requires: perl-minimal
Thoughts on this?
-1
Rationale:
a) As others already pointed out, many of these requires: are
automatically added = Part of the issue is inside of perl.req etc. and
not inside of the perl package
b) Requires: perl is intuitively understandable
(A natural solution ), perl(:MODULE_COMPAT_..) isn't.
c) R: perl(:MODULE_COMPAT_..) is not a natural replacement for
R: perl XXX. They have different semantics.
R: perl(:MODULE_COMPAT_..) basically refers to module search paths,
while R: perl XXX, can refer to many to subjects and may originiate
from other issues, such as changes of the perl language, bugs a perl
module author might have encountered, etc.
Example:
# rpm -q -requires help2man | grep perl
/usr/bin/perl
perl = 0:5.005
perl(Getopt::Long)
perl(POSIX)
perl(Text::Tabs)
perl(locale)
perl(strict)
* There is no explicit requires: perl = ... inside of this package's
spec,
* The package actually doen't require a perl-package = 5.005, it
requires The Perl Language 5.005
* The package doen't install any module, so perl(:MODULE_COMPAT_..)
isn't right either.
That said, I think, we need another rpm tag, besides perl and
perl(:MODULE_COMPAT..) to denote The Perl Language version and let
rpm add this in perl.req instead of perl XXX.
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Updates lacking descriptions
On 08/14/2009 07:32 AM, Jesse Keating wrote: On Fri, 2009-08-14 at 05:41 +0200, Ralf Corsepius wrote: I strongly think Fedora would be better without Rahul and Kevin, two persons I have learned to be doing a good job on certain subjects, but to be a miscast on certain jobs and failure of the system in Fedora. I strongly feel that Fedora would be better without this negative attitude, and the appearance that this kind of attitude is tolerated. OK, do * you feel FESCo is functional and the people within FESCo are qualified for the positions they are trying to fill? * you think Fedora 11 was of good quality? * you think rel-eng and the Fedora infrastructure is working smoothly? ... I don't, but do think many of the issues related to these topics are related to certain people being involved. It's not. Your continued poisonous and rude attitude on these lists have gone unchecked for far too long. Please keep it in check, or spend some time somewhere else. First of all I do not consider my answers to be rude, but to be open. OK, I might not always be using the correct wording (I am not a native English speaker) and phrases people from the US might consider appropriate phrases (German is a much direct language than US-English) - My appologies for that. However, I also think some of you are trying to wipe issues under the carpet, try to play issue down and try to flame folks who don't share your opinions, instead of wanting to address them. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates lacking descriptions
On 08/13/2009 10:41 AM, Kevin Kofler wrote: Ralf Corsepius wrote: Correct, such a step will add a significant bureaucratic burdons to maintainers. As maintainers hate bureaucrazy and prefer investing time on dealing with technical issues (such as bug fixes), this will likely introduce a further reduction of the quality of Fedora. Further more, do you realise that any changelog is likely similarly unreadable to most users? Nonsense, it's not bureaucracy to expect an update to actually say what changed and why you're pushing it. No, as ususal, you are demonstrating your lack of competence and understanding: Whether a changelog entry tells - Update to upstream release 1.2.3 - Update due to http://ustreamurl/releasenote-1.2.3 - Upstream update: .. long verbose list of details is entirely irrelevant to both, you and to Aunt Tilly (she won't read them at all and even if she will not understand it). Also, is naive to presume there always is a RH-BZ for each upgrade/update or that a bug upstream is fixes has ever been tripped over in Fedora. 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. PS.: Stop cross-posting to newsgroups. I consider everybody who does this to behave rude. We're not cross-posting, we're replying to gmane.linux.redhat.fedora.devel only (using our NNTP clients). What Gmane does with it is out of our control. Any complaints about inadequacy of the Gmane gateway will have to go to Gmane. No. You simply are violating the netiquette ... i.e. you are hostile and rude to this lists users - Stop this habit. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates lacking descriptions
On 08/13/2009 06:55 PM, Josh Boyer wrote: 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. And censorship doesn't make it better. I strongly think Fedora would be better without Rahul and Kevin, two persons I have learned to be doing a good job on certain subjects, but to be a miscast on certain jobs and failure of the system in Fedora. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates lacking descriptions
On 08/12/2009 11:54 PM, Ben Boeckel wrote: If this is enforced (and it may be good to add it to the critical-path suggestion), updates will be reduced since when there's little to write about, there's less justification for an update in the first place. Correct, such a step will add a significant bureaucratic burdons to maintainers. As maintainers hate bureaucrazy and prefer investing time on dealing with technical issues (such as bug fixes), this will likely introduce a further reduction of the quality of Fedora. Further more, do you realise that any changelog is likely similarly unreadable to most users? Ralf PS.: Stop cross-posting to newsgroups. I consider everybody who does this to behave rude. -- 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 08/10/2009 05:17 PM, Bill McGonigle wrote: On 08/07/2009 02:54 AM, Rahul Sundaram wrote: Pointing it out on a review and restoring to calling the packages bad quality if people don't follow your controversial recommendation isn't going to scale at all. This is a good perspective, Ralf. Putting the same energy into individual reviews won't have as amplified an impact as convincing the packaging committee of problems. I am member of the FPC, but ... I have failed to convince the FPC so far. I understand the theoretical value of a deterministic package build - I'm not aware of specific examples of where non-determinism has caused problems in Fedora, though I can imagine some. They are very easy to demonstrate. Commonly known cases are building gcc, binutils, gdb, firefox etc. Other cases are pretty easy to find. Actually, probably almost any non-trivial, complex package has such issues. It's only the fact that most packages are trivial autotool-wise and the fact that autotools-changes often are subtile, which lets people who are not intimate with the autotools (erroroniously) believe it's safe to run autotools during builts. Gathering evidence of breakage may cause a change of opinion. Having a practical alternative is probably required as well. The practical alternative is very simple: Run the autotools on the system you are testing on, create diffs from them and to apply them during builds. I am applying this approach to several of my Fedora packages (some of which I know to suffer from such issues, e.g. Coin2), fixed some packages (owned by others) this way, which had failed during the F11-mass-rebuild, exactly because of such issues. Ralf -- 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 08/10/2009 08:48 PM, Kevin Kofler wrote: Ralf Corsepius wrote: I am applying this approach to several of my Fedora packages (some of which I know to suffer from such issues, e.g. Coin2), fixed some packages (owned by others) this way, which had failed during the F11-mass-rebuild, exactly because of such issues. I'd be pretty pissed off if you fixed one of my packages that way, instead of addressing the real issue (that rerunning the current autotools fails). Thanks for providing evidence for you not having understood the problems. Also, thank you for you crossposting to a newgroup in replies list postings. -- 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 08/10/2009 09:01 PM, Bill McGonigle wrote: On 08/10/2009 11:44 AM, Ralf Corsepius wrote: They are very easy to demonstrate. Commonly known cases are building gcc, binutils, gdb, firefox etc. Are these of the sort where a bug is reported, it's found that autotools made a bad decision, and then patching autotools fixed the problem? Unlike some people around on this list, these tools' upstreams know how to use the autotools (I am active contributor to all of them): Use pregenerated files, do not run the autotools while building. Ralf -- 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 08/10/2009 11:56 PM, Ben Boeckel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Corsepius wrote: On 08/10/2009 09:01 PM, Bill McGonigle wrote: Are these of the sort where a bug is reported, it's found that autotools made a bad decision, and then patching autotools fixed the problem? Unlike some people around on this list, these tools' upstreams know how to use the autotools (I am active contributor to all of them): Use pregenerated files, do not run the autotools while building. And things like this make the autotools completely unattractive as a developer (to me at least). Well, not all tools suite all needs. If you believe other tools better suite your needs, use them, if you feel like it. But if you use a tool (such as the autotools) you should learn to use them and to use them correctly. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies: perl-DBIx-Class-Schema-Loader
On 08/08/2009 08:23 PM, Jesse Keating wrote: On Sat, 2009-08-08 at 18:32 +0200, Ralf Corsepius wrote: This bug was fixed in perl-DBIx-Class-Schema-Loader-0.04006-5.fc12.noarch.rpm Wed, 05 Aug 2009 12:13:03 UTC (3 days ago). cf. http://koji.fedoraproject.org/koji/buildinfo?buildID=125804 No idea, why these broken broken deps messages are still being issued. Ralf Because we're in a freeze, and no builds get tagged for rawhide without a request and rational to releng. OK, the same old defunctional rel-eng process showing its harmful effects. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/08/2009 07:25 AM, Kevin Kofler wrote: Ralf Corsepius wrote: lack of maintainer skills (e.g. running the autotools), You are insulting maintainers for having a different opinion, It's not a matter of opinions it's a matter of technical facts. It doesn't matter how many people deny to ackknowledge this fact and how many people are abusing the autotools. -- 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 08/08/2009 07:03 AM, Adam Williamson wrote: On Sat, 2009-08-08 at 05:51 +0200, Ralf Corsepius wrote: IMHO, the proper way is to express opinion, and even when disagreement happens, approve review == switch off your brains, morals, knowledge Pardon, but you don't want how disgusting I find this logic of yours. If you're invoking your morals at any point while doing package reviews, ur doing it rong. Rubbish. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: --target in %configure in rawhide i386
On 08/08/2009 08:58 PM, Jussi Lehtola wrote: On Sat, 2009-08-08 at 18:34 +0200, Ralf Corsepius wrote: On 08/08/2009 12:19 PM, Jussi Lehtola wrote: Hi, why does %configure still use --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i586-redhat-linux-gnu in rawhide i386, shouldn't the target be i686-redhat-linux-gnu? --target should not be set at all. It's meaningless for 99.9% of all packages. .. and it causes trouble in the 0.1% of packages: compilers. Correct, it's a bug in redhat-rpm-config. Actually, I thought this was fixed a long time ago, because we have this discussion each time a compiler/toolchain package is being introduced to Fedora. Either this didn't happen or somebody reintroduced the bug. Common work-around is not to use %configure for such package. At least the pcc build scripts think that a cross-compilation is in course, since the host and target arguments differ. This would be a bug in this package. Modern (autoconf 2.13) autotools treat $build != $host as cross compilation. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies: perl-DBIx-Class-Schema-Loader
This bug was fixed in perl-DBIx-Class-Schema-Loader-0.04006-5.fc12.noarch.rpm Wed, 05 Aug 2009 12:13:03 UTC (3 days ago). cf. http://koji.fedoraproject.org/koji/buildinfo?buildID=125804 No idea, why these broken broken deps messages are still being issued. Ralf On 08/08/2009 11:40 AM, build...@fedoraproject.org wrote: perl-DBIx-Class-Schema-Loader has broken dependencies in the development tree: On ppc: perl-DBIx-Class-Schema-Loader-0.04006-4.fc12.noarch requires perl(DBIX::Class) On x86_64: perl-DBIx-Class-Schema-Loader-0.04006-4.fc12.noarch requires perl(DBIX::Class) On i386: perl-DBIx-Class-Schema-Loader-0.04006-4.fc12.noarch requires perl(DBIX::Class) On ppc64: perl-DBIx-Class-Schema-Loader-0.04006-4.fc12.noarch requires perl(DBIX::Class) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: Fedora 12 Features Proposed for Removal
On 08/06/2009 09:12 PM, Matej Cepl wrote: Ralf Corsepius, Thu, 06 Aug 2009 18:14:47 +0200: I turned away from supporting Mr. Robinson, ignored his reviews and left reviews to others So you lost your right to slander him now. Do you expect people to continue a review even when you'd have to decide against the best of your knowledge and conciousness? Pardon, I can't. I tried to teach Mr. Robinson tried to instruct him to do better, but ... he refused .. so be it, these packages are formally correct, ... however, this doesn't mean they are of good quality nor does this mean the reviewers did a good job (IMO they did not) Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On 08/07/2009 10:48 AM, Till Maas wrote: On Fri, Aug 07, 2009 at 06:35:14AM +0200, Ralf Corsepius wrote: On 08/06/2009 09:33 PM, Till Maas wrote: currently upstream release monitoring[0] bug filing is opt-in, which means that it will be only performed for packages that have been activly added by probably a maintainer of the package. There is at least one maintainer that does not like having these bugs filed for his packages, so he can remove his packages from the list. I'd prefer this system to be kept opt-in, because I think Do I understand it corretly, that if you won't get any false bug reports, then you don't have any objection? Correct. Such a system may be useful for some people and applicable to some cases, therefore I don't see many reasons why people in such situations shouldn't be using it (== opt-in). a) A system can only be made opt-out, if a system can handle the overwhelming number of cases automatically. However, [0] indicates this does not (yet?) apply. Conversely it explicitly asks for manual interaction. I am not sure what's the problem you are seeing here. Package maintainers (e.g. me) are not interested in more Fedora bureaucracy nor in having to cope with yet another system (besides bugzilla, trac, kojo, bodhi, packagedb, cvs, repos, steering organs (FPB, FESCO, FPC, Fedora committee de jour etc.). Maybe it was a bad use of the word opt-out. If the monitoring system does not check a package, the maintainer obviously does not need to opt out, but also it does not create any more problems. Or what are the cases you are referring to? I sense a miscommunication. As I understood your mail and [0], you are offering a service, maintainers can opt-in to use. Now you would like to make your service the default (== opt-out) and are asking for opinions. Did I misunderstand? b) You seem to be presuming all upstreams to apply one single newer metric (Versioning scheme). This doesn't apply, there exist several different versioning schemes, e.g. pre-/bugfix-release versionings, perl-versioning vs. rpm versioning etc. Also, many projects occasionally change their versioning schemes or don't even apply one. How do you plan to handle this? I plan to handle it on a case to case basis, e.g. either make the version comparison work or ignore the package. Also the data source that can might be added, already normalises the data for the affected packages. Currently the monitoring system supports some rc/pre releases and checks whether or not the upstream version can be found in the CVS sources file to avoid bogus bug reports. I am not sure if this can ever be achieved, because there exist many varients of versioning schemes and because it's not uncommon for upstreams switch between several. If you have some ideas, which versions may cause problems, please provide some examples. Some classic cases: * 1.2pre .. pre release , 1.2 release, 1.2a bugfix a. * 1.2a .. 1.2a release, 1.2b 1.2b release. * 1.2pre .. pre release, 1.2. release, 1.2.1 successor of 1.2 * 1.2 ... latest release, 1.3 successor of 1.2 (GNU versioning) * 1.1, 1.2a, 1.2b, 1.2 (A variant of the GNU versioning, releases are using numerical versions, versions with suffix a,b,c... are prereleases) * 1.18, 1.1901, 1.1902, 1.20 (Perl versioning ... X.20 X.1900 !) * Frequent builds using the same version (replacing the same tarball), e.g. daily snapshots. ... Now imagine upstreams switching between these .. No idea, how you would want to handle this. I will then add them to the unittests and see, how well they are handled. For this I need at least one upstream version, one rpm version/release pair and an expected result (which should be newer or are both the same). c) Some upstreams occasionally change their download URLs or use non-permanent URLs or some more or less unstable URL-redirection. How do you want to hangle this? The options are to ignore the package or to update the URL when they change. How? For your service to be helpful, you would have to do this automatically. I don't see, how this could be achieved. Would it be ok, to do this and allow maintainers to add there package to a black list, so that no bugs will be filed or should it continue to be opt-in? Then the packags will still be checked, but only reported by other, non intrusive ways, e.g. via a website. alarm bell ring/ Website? == yet more bureaucracy I don't get how you might even expect more bureaucracy from some status website. What do you think this website might be? It will not require anybody to look at it, but provide the information to interested people. [0] says write a regex, opt-out would mean forced interaction with your website, opt-in would mean registration. All in all, I read this as bureaucracy. Ralf -- 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 08/07/2009 04:19 PM, Matěj Cepl wrote: Ralf Corsepiusrc040...@freenet.de writes: On 08/06/2009 09:12 PM, Matej Cepl wrote: Do you expect people to continue a review even when you'd have to decide against the best of your knowledge and conciousness? Actually, yes, I do. Your job is not to make packages perfect, but to check they follow Packaging Guidelines and other items as stated on the wiki. Of course, you can and you should express your opinion about any strategies and techniques they use (rerun autoconf or patch ./configure or libtool), but their disagreement with your opinion (and it is nothing else than one of two opinions on the matter) shouldn't be the reason why you reject the review approval. I usually pronounce my opinion and then abstain from approving a package. Do you go to the source code and check how well the upstream made the program? I do when I am observing something noteworthy. If things are too ugly I usually abstain from formally reviewing packages, approving a package and/or recommend other reviewers to do the same. IMHO, the proper way is to express opinion, and even when disagreement happens, approve review == switch off your brains, morals, knowledge Pardon, but you don't want how disgusting I find this logic of yours. and then file a bug against the package where you can fight your battle without threatening packager to disallow him to have a bug in the repo. My strategy is not to formally review a package I don't agree with for whatever reasons. Sometimes these reasons are of technical nature (e.g. low coding quality), lack of maintainer skills (e.g. running the autotools), sometimes of moral nature (e.g. war games), some times of legal reasons (e.g. games) ... Ralf -- 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 08/06/2009 10:39 AM, Peter Robinson wrote: After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status or their ability to tested during the Alpha is unclear based on the lack of information provided or percentage of completion. https://fedoraproject.org/wiki/Features/FedoraMoblin I'm the maintainer of this. I think its very much in a similar category to gnome/kde. The only difference is there is some packages still awaiting review, about 2 that are actually critical, but moblin 2 like gnome etc are still in there development phase so its a moving target. IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). Ralf -- 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 08/06/2009 10:55 AM, Rahul Sundaram wrote: On 08/06/2009 02:14 PM, Ralf Corsepius wrote: IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). Be specific. This is not enough information to influence the decision at this stage. OK, more verbose: * In their present shape the packages are non-functional. According to the submitter, this is due to lack of upstream vs. Fedora integration. * IM (NSH) O, the packaging quality of the submitted packages is close to being inacceptable low. -- 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 08/06/2009 12:32 PM, Bastien Nocera wrote: On Thu, 2009-08-06 at 10:44 +0200, Ralf Corsepius wrote: On 08/06/2009 10:39 AM, Peter Robinson wrote: After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status or their ability to tested during the Alpha is unclear based on the lack of information provided or percentage of completion. https://fedoraproject.org/wiki/Features/FedoraMoblin I'm the maintainer of this. I think its very much in a similar category to gnome/kde. The only difference is there is some packages still awaiting review, about 2 that are actually critical, but moblin 2 like gnome etc are still in there development phase so its a moving target. IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). Low packaging quality? I certainly don't think so, given the amount of time Peter spent on them, and the fact that they all seemed good enough to pass review. Yes, they somehow sneeked through reviews. This doesn't invalidate what I said. It only proves my impression of Fedora quality standards being low and about the quality of reviews. As for the feature being scrapped, the goal of it is to package the current sources of Moblin, which is what it's doing. If we removed all the beta software from Fedora, we wouldn't have much left... Well, ... yes, we have a lot of semifunctional stuff in Fedora, which should never have been released. At least I am having the impression Fedora 11 has derailed more into a rawhide shapshot but an end-users suitable distro (which it once used to be). - But this is off-topic wrt. moblin. Ralf -- 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 08/06/2009 02:10 PM, Christoph Wickert wrote: Am Donnerstag, den 06.08.2009, 13:39 +0200 schrieb Ralf Corsepius: On 08/06/2009 12:32 PM, Bastien Nocera wrote: On Thu, 2009-08-06 at 10:44 +0200, Ralf Corsepius wrote: On 08/06/2009 10:39 AM, Peter Robinson wrote: After requesting status updates, including direct email to the feature owners, the following feature pages do not have a current status or their ability to tested during the Alpha is unclear based on the lack of information provided or percentage of completion. https://fedoraproject.org/wiki/Features/FedoraMoblin I'm the maintainer of this. I think its very much in a similar category to gnome/kde. The only difference is there is some packages still awaiting review, about 2 that are actually critical, but moblin 2 like gnome etc are still in there development phase so its a moving target. IMO, this feature should be scratched, because the packages in question are of immature nature (... and of low packaging quality from my POV). Low packaging quality? I certainly don't think so, given the amount of time Peter spent on them, and the fact that they all seemed good enough to pass review. Yes, they somehow sneeked through reviews. This doesn't invalidate what I said. It only proves my impression of Fedora quality standards being low and about the quality of reviews. Would you please be so kind and name names here? What packages and what reviews are you talking about? In this context, I am talking about all moblin package submissions by Mr. Robinson. I asked you to write down the problems you found in bz and CC me, but so far I haven't received a mail. I haven't received any mail from you. Instead you spend time on writing mails with abstract accusations to the list. Do you want me to flame people in public? As you know I'm really interested in improving both the packaging and the review quality and I appreciate your cooperation. Why not pick up some of the reviews? I did so, but Mr. Robinson refused to listen and preferred to go his way, because the fedora guidelines allow him to do so. It cause me to turn away from his reviews. Ralf -- 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 08/06/2009 02:18 PM, drago01 wrote:
On Thu, Aug 6, 2009 at 1:33 PM, Ralf Corsepiusrc040...@freenet.de wrote:
* IM (NSH) O, the packaging quality of the submitted packages is close to
being inacceptable low.
Can you be more verbose on that one?
3 Examples:
1. He is running the autotools while building.
This renders building non-deterministic and exposes his packages to
suffer from build breakdowns due to the autotools changing behaviour,
rsp. due to the packages being tied to specific versions of the autotools.
2. Some of his packages contain abuses of %*dir variables.
e.g.:
%post
%{_bindir}/someotherscript
3. Some of his packages don't honor rpm input %*dir variables
(e.g. datadir), but rely on %{_prefix} only, despite they install to
%{_datadir}
Instead of hand waving its low quality
Ralf
--
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 08/06/2009 05:20 PM, Christoph Wickert wrote: Am Donnerstag, den 06.08.2009, 16:20 +0200 schrieb Ralf Corsepius: On 08/06/2009 02:18 PM, drago01 wrote: On Thu, Aug 6, 2009 at 1:33 PM, Ralf Corsepiusrc040...@freenet.de wrote: * IM (NSH) O, the packaging quality of the submitted packages is close to being inacceptable low. Can you be more verbose on that one? 3 Examples: So where are your comments in bugzilla for example 2 and 3? I turned away from supporting Mr. Robinson, ignored his reviews and left reviews to others ... I only noticed these issues in commits. Low quality reviews - QED. -- 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 08/06/2009 05:16 PM, Christoph Wickert wrote: Am Donnerstag, den 06.08.2009, 16:14 +0200 schrieb Ralf Corsepius: On 08/06/2009 02:10 PM, Christoph Wickert wrote: I asked you to write down the problems you found in bz and CC me, but so far I haven't received a mail. I haven't received any mail from you. Instead you spend time on writing mails with abstract accusations to the list. Do you want me to flame people in public? No, I want constructive criticism in bugzilla. Flaming people in public is what you are currently doing on this list. As you know I'm really interested in improving both the packaging and the review quality and I appreciate your cooperation. Why not pick up some of the reviews? I did so, but Mr. Robinson refused to listen and preferred to go his way, because the fedora guidelines allow him to do so. It cause me to turn away from his reviews. Sorry, you didn't pick up any of the bugs, none was assigned to you. There is none assigned to me, because I turned away from this person's reviews. You can find traces of them in reviews. You picked on Peter, that's all. Well, your freedom to think so, my freedom to think otherwise -- I think, you are picking on _me_, because I am pronouncing something which doesn't fit into your wishful thinking. You only commented on two bugs regarding autoconf, but this is a controversial topic. Only within uneducated folks, without clues about the autotools. Please accept that there are different views on questions like this one. It's pretty easy to demonstrate the brokenness of running the autotools during builds. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On 08/06/2009 09:33 PM, Till Maas wrote: Hiyas, currently upstream release monitoring[0] bug filing is opt-in, which means that it will be only performed for packages that have been activly added by probably a maintainer of the package. There is at least one maintainer that does not like having these bugs filed for his packages, so he can remove his packages from the list. I'd prefer this system to be kept opt-in, because I think a) A system can only be made opt-out, if a system can handle the overwhelming number of cases automatically. However, [0] indicates this does not (yet?) apply. Conversely it explicitly asks for manual interaction. b) You seem to be presuming all upstreams to apply one single newer metric (Versioning scheme). This doesn't apply, there exist several different versioning schemes, e.g. pre-/bugfix-release versionings, perl-versioning vs. rpm versioning etc. Also, many projects occasionally change their versioning schemes or don't even apply one. How do you plan to handle this? c) Some upstreams occasionally change their download URLs or use non-permanent URLs or some more or less unstable URL-redirection. How do you want to hangle this? Would it be ok, to do this and allow maintainers to add there package to a black list, so that no bugs will be filed or should it continue to be opt-in? Then the packags will still be checked, but only reported by other, non intrusive ways, e.g. via a website. alarm bell ring/ Website? == yet more bureaucracy [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: An easy way to redefine configure?
On 08/04/2009 02:01 PM, Jussi Lehtola wrote: On Tue, 2009-08-04 at 13:42 +0200, Mattias Ellert wrote: What's the correct way to do this? %global dconfigure %(rpm -E %%configure | sed 's!./configure!../configure!g') %dconfigure This works, but isn't it bad style to call rpm from within a spec file..? Correct - This is not allowed in Fedora. In occasions like yours, I normally use a manually expanded ../configure IMO, it's much cleaner and less error prone than to mess around with %configure. Ralf -- 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 07/30/2009 01:40 AM, Jesse Keating wrote: I've now generated the first of the mass rebuild status pages. http://jkeating.fedorapeople.org/needed-f12-rebuilds.html corsepiu: OpenSceneGraph Seems as if you modified the *.spec (traces in CVS), but haven't launched any built (no traces of a built in koji). perl-IPC-Run-SafeHandles No traces of a rebuilt, neither in CVS nor in koji. Seems to me, as if your mass-rebuild script might have some cracks. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On 07/29/2009 08:03 AM, Adam Williamson wrote: On Tue, 2009-07-28 at 01:51 +0200, Ralf Corsepius wrote: On 07/28/2009 01:19 AM, Paul W. Frields wrote: On Mon, Jul 27, 2009 at 06:27:00PM -0400, Jeremy Katz wrote: That means that you can take revisor, pungi or livecd-tools in your existing Fedora system None of these are what I am looking for. I'm terribly sorry - what color exactly did you want us to paint your fricking pony, Ralf? Plonk. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On 07/29/2009 12:37 AM, Adam Williamson wrote: On Mon, 2009-07-27 at 13:43 +0200, Ralf Corsepius wrote: With all due respect to fedoraunity and you. To me it is a serious Fedora management and rel-eng mistake causing major harm to fedora's and RH's reputation to not provide updated media, thus to expose users to known bugs. I can't think of any major distro that actually does this. And? Isn't Fedora about innovation? It's a very big effort that would take much manpower away from working on the installer and releng tasks for the next release. The discussion about whether that compromise would be justified has not been done yet. It's not as simple as you suggest. My impression is you only say so because you're too close to Ole' Red Hat's habits and don't want to leave them. The key to implement what I said is a minimial installer image - Actually RH distros once had an installer which was very close to this. Unfortuately, this doesn't apply anymore. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On 07/27/2009 07:33 AM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 26 Jul 2009, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? If you want a small root partition you should put /var/cache/yum on another partition. Do you mean Preupgrade didn't handle the lack of disk space well? * anaconda failing during reboots due not being able to process fstab correctly (FC11's anaconda misparses fstab and is unable able to process bind-mounts nor nfs-mounts). Bind mounts are fixed, as far as I know: https://bugzilla.redhat.com/show_bug.cgi?id=496406 For NFS mounts, I believe it's fixed in commit 40728ffcc1e32eb6b5ccc0cd3b3ddb23216cf199, which was on June 7th. That should carry over NFS mounts listed in /etc/fstab if you are doing an upgrade. Well, to my knowledge these are FIXED RAWHIDE, only. * anaconda's depsolving failed when upgrading an FC10 + FC10-updates system due to NEVR issues. If you have any details of the failure, it would help. Unfortunately no. I had not been involved into upgrading the system this had happened to from the beginning. I was called to troubleshoot this upgrade. The situation I found was a partially upgraded system, stuck on upgrading yum due to a rpm conflict on yum itself. No idea how the person trying to upgrade managed to get into this situation. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On 07/27/2009 11:26 AM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 27 Jul 2009, Ralf Corsepius wrote: On 07/27/2009 07:33 AM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 26 Jul 2009, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? If you want a small root partition you should put /var/cache/yum on another partition. Do you mean Preupgrade didn't handle the lack of disk space well? * anaconda failing during reboots due not being able to process fstab correctly (FC11's anaconda misparses fstab and is unable able to process bind-mounts nor nfs-mounts). Bind mounts are fixed, as far as I know: https://bugzilla.redhat.com/show_bug.cgi?id=496406 For NFS mounts, I believe it's fixed in commit 40728ffcc1e32eb6b5ccc0cd3b3ddb23216cf199, which was on June 7th. That should carry over NFS mounts listed in /etc/fstab if you are doing an upgrade. Well, to my knowledge these are FIXED RAWHIDE, only. That's true. anaconda is unique in that the only way a new one can be released to fix installation issues for users is to generate new media. Exactly = this bug is _not fixed_. We continue to fix problems reported against Fedora 11's anaconda in rawhide, but for users needing the fix in the latest stable release, consider Fedora Unity. Fedora Unity generates new spins of the latest stable release including backports of anaconda fixes: http://www.fedoraunity.org/ With all due respect to fedoraunity and you. To me it is a serious Fedora management and rel-eng mistake causing major harm to fedora's and RH's reputation to not provide updated media, thus to expose users to known bugs. Openly said, I think this management mistake is one of the culprits for the poor shape of Fedora. Another one is not having banned FIXED RAWHIDE/UPSTREAM. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On 07/27/2009 11:25 AM, drago01 wrote: On Mon, Jul 27, 2009 at 7:21 AM, Ralf Corsepiusrc040...@freenet.de wrote: On 07/26/2009 09:28 PM, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? Well, to some extend, I am blaming it, because a) filling '/' may easily kill a system and may easily cause further damage (processes running in parallel to preupgrade might be malfunctioning due lack of diskspace). b) I expect an installer to be able to check whether sufficient space is available in advance, rsp. not to leave a system in an unusable state in case of something going wrong. In BZ https://bugzilla.redhat.com/show_bug.cgi?id=503183 I questioned whether using /var/cache/yum is a good choice for preupgrade's package cache. Though I meanwhile know that this BZ is was a side-effect of the nfs-parser bugs in anaconda, I still think using /root or /tmp would be better choices. No, some people (me included) use tmpfs for /tmp , so this would result into reboot, no packages found (if it did not hit a space problem either). Your problem, if you are using a non-reboot persistant /tmp On my machines, various subdirs of /var are nfs mounted and spread across a network. /root is not supposed to be used by random apps. This is not a random app permanently using a filesystem. It is the user root running an application to set up a personal temporary filesystem to be used exclusively by him. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On 07/27/2009 03:39 PM, Emmanuel Seyman wrote: * Ralf Corsepius [27/07/2009 13:49] : Your problem, if you are using a non-reboot persistant /tmp Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted. Filesystem Hierarchy Standard v2.3 Well, I yes I mixed up /tmp with /var/tmp. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On 07/27/2009 10:21 PM, Jeremy Katz wrote: Regenerating the images is expensive -- it requires effort on the part of the developers doing fixes, release engineering doing builds with the fixes, QA testing the fixes, infrastructure (mirrors) carrying a significant amount more bits[1], ... Not quite true. Instead of building all images, you could build a minimalist network install image, which installs from Everything+updates. I don't know how you build images, but it's hard to image building such an image frequently (e.g. whenever any package it contains has changed) is such kind of expensive. An alternative would be, to ship a script to let people build such an image themselves. It would not help everybody in all situations, but it at least help people who have some (other) version of Fedora running somewhere. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On 07/28/2009 01:19 AM, Paul W. Frields wrote: On Mon, Jul 27, 2009 at 06:27:00PM -0400, Jeremy Katz wrote: That means that you can take revisor, pungi or livecd-tools in your existing Fedora system None of these are what I am looking for. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
On 07/28/2009 01:43 AM, Jeroen van Meeuwen wrote: On 07/28/2009 12:54 AM, Ralf Corsepius wrote: On 07/28/2009 12:27 AM, Jeremy Katz wrote: As it turns out, we ship all the tools to build the distribution the exact way we do! And as David said, he's been working with Jeroen for occasional updated anaconda packages. OK, in which package can I find your mkimage script. You mean /usr/lib/anaconda-runtime/mk-images (from the anaconda package)? Well, this seems close. Any documentation? Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On 07/26/2009 08:12 AM, Adam Williamson wrote: On Sat, 2009-07-25 at 21:42 +0200, Farkas Levente wrote: On 07/25/2009 08:56 PM, Björn Persson wrote: Fortunately I had read in this list that upgrading breaks Yum so I did a fresh install instead, and only had to spend a few days getting all the configuration back into shape. Sound started working after I deleted ~/.pulse. and if you is broken then the whole system is broken! so everybody have to spenda few days to get back their config. so we only have to spend a few days every half year. it's even worse then if i install windows. it's a really nice release. why is it so difficult to upgrade packages? I upgraded my laptop from F10 to F11, with X running, via yum. It worked flawlessly and rebooted clean. When I tried, FC-10's yum had been unable to process metalinks. May-be FC-10's yum has been updated since then ;) Anecdotal evidence means very little. It may be news to you, but a single negative result invalidates a whole series of positive tests ;) My personal list of upgrade FC-10-FC-11 failures is rather lengthyg, however most of the issues I encountered were related to preupdate, anaconda and rel-eng mistakes. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On 07/26/2009 10:40 AM, drago01 wrote: On Sun, Jul 26, 2009 at 8:34 AM, Ralf Corsepiusrc040...@freenet.de wrote: It may be news to you, but a single negative result invalidates a whole series of positive tests ;) No, that means that they are bugs / problems but not that the feature is broken in general. Well, it means that the feature lacks generality and raises questions about a feature's readyness for prime time - Judging whether this feature is sufficiently ready for prime-time is up to the eye of beholder. Adam thinks it's good, I observed breakdowns on several different systems (5 so far). My conclusion: The FC10 preupdate/FC11 anaconda combo are far from being ready, even less so the version in the iso. The worst about it: Unless rel-eng finally releases updated Fedroa 11 isos, the shameful situation about F11 installs will not see much improvements, because anaconda being FIXED UPSTREAM/RAWHIDE doesn't help FC11 users. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) * anaconda failing during reboots due not being able to process fstab correctly (FC11's anaconda misparses fstab and is unable able to process bind-mounts nor nfs-mounts). * anaconda's depsolving failed when upgrading an FC10 + FC10-updates system due to NEVR issues. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On 07/26/2009 09:28 PM, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? Well, to some extend, I am blaming it, because a) filling '/' may easily kill a system and may easily cause further damage (processes running in parallel to preupgrade might be malfunctioning due lack of diskspace). b) I expect an installer to be able to check whether sufficient space is available in advance, rsp. not to leave a system in an unusable state in case of something going wrong. In BZ https://bugzilla.redhat.com/show_bug.cgi?id=503183 I questioned whether using /var/cache/yum is a good choice for preupgrade's package cache. Though I meanwhile know that this BZ is was a side-effect of the nfs-parser bugs in anaconda, I still think using /root or /tmp would be better choices. If you want a small root partition you should put /var/cache/yum on another partition. This would have worked, if anaconda had been able to process fstab. Unfortunately, FC11's anaconda isn't able to do so. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On 07/26/2009 09:34 PM, John Poelstra wrote: Ralf Corsepius said the following on 07/26/2009 11:35 AM Pacific Time: Are there bug numbers for these issues? I filed some BZs for which I couldn't find as already filed by others (some already were): https://bugzilla.redhat.com/show_bug.cgi?id=503183 https://bugzilla.redhat.com/show_bug.cgi?id=508932 https://bugzilla.redhat.com/show_bug.cgi?id=506396 (Note: These all are FIXED RAWHIDE/UPSTREAM, i.e. not fixed in FC11!) Also related to these: * Responsible for being forced to use preupgrade: https://bugzilla.redhat.com/show_bug.cgi?id=498720 * Causing troubles in the aftermath of upgrades/updates: https://bugzilla.redhat.com/show_bug.cgi?id=511076 https://bugzilla.redhat.com/show_bug.cgi?id=511101 Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: all of my system has a wrong openssl version all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my /'s tend to be minimized/small) * anaconda failing during reboots due not being able to process fstab correctly (FC11's anaconda misparses fstab and is unable able to process bind-mounts nor nfs-mounts). * anaconda's depsolving failed when upgrading an FC10 + FC10-updates system due to NEVR issues. Ralf -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
