Re: mingw32 suite
stop using rar. be free. On Tue, Oct 13, 2009 at 9:21 PM, Paulo Cavalcanti pro...@gmail.com wrote: Hi, I am really pleased to see how fast the cross-compile project has evolved, and I was able to create a very simple script to cross-compile mpg123: http://orion.lcg.ufrj.br/RPMS/SPECS/cross-mingw-mpg123 However, I am more interested in cross-compiling opengl applications. Any plans to provide any opengl support for mingw32 in Fedora? Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Itamar Reis Peixoto e-mail/msn: ita...@ispbrasil.com.br sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
James Antill wrote: Personally I'd suggest pushing to updates-testing but wait a _long_ time (maybe even never) before pushing to stable. Never is definitely the wrong answer: updates-testing is not for stuff which is too unstable to go stable, ever. Any update sitting in testing for more than (at most) 2 or 3 weeks (usually 1 week is enough, but risky stuff should get approximately 2 weeks of testing and regression fixing; at least those are the timings our experience in KDE SIG showed optimal) is either broken, in which case it should be unpushed (and the maintainer should be more careful next time), or not, in which case it should be promoted to stable. We really need some stricter enforcement against stuff sitting in testing forever. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mingw32 suite
Itamar Reis Peixoto wrote: stop using rar. be free. Agreed. (By the way, it is also a violation of the EULA to use rar for more than 30 days without paying. I'm sure many people are using it illegally. But the biggest problem with the format is that there is no Free as in speech decompressor for it. The freeware unrar, while free as in beer, has quite outrageous licensing restrictions. Just say no to proprietary software!) But for a more constructive suggestion: use p7zip instead. It can also build self-extracting archives, you just need the self-extracting stub from the W32 distribution of 7-Zip. And it's all LGPL (except the unrar plugin, see above; the Fedora p7zip package doesn't ship that plugin for this reason). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
Dodji Seketeli wrote: My point is this is a matter of personal judgement. If the change is going to be too disruptive (and that's a maintainer call) then maybe having a Fedora-blessed repository like this great one http://rpms.famillecollet.com/fedora/11/remi/x86_64/repoview could be a possible way to go. At the same time, the package could be updated straight to Rawhide, of course. Not upgrading was not an option here, the new beta was needed to fix security issues. (F11 already shipped with a 3.0 beta, the newer beta is the only upgrade path.) Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
Rahul Sundaram wrote: If maintainers choose to include a beta release, then it would have been better to collect more feedback for a longer period of time for updates. I already answered this in more detail on your blog, but: 1. It's a security update, so a short testing period is normal. 2. It reached +3 karma and got automatically queued for stable. My mails to this list is my negative karma. But it's too late, the update already got pushed. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mingw32 suite
On Tue, Oct 13, 2009 at 09:21:29PM -0300, Paulo Cavalcanti wrote: However, I am more interested in cross-compiling opengl applications. Any plans to provide any opengl support for mingw32 in Fedora? We already support it. The OpenGL API is supported by the base OS (ie. Windows or Wine) as a library called opengl32.dll, so doesn't need any extra explicit support from the cross-compiler project. However where you might get stuck is that we don't currently ship GLUT or freeglut. I'm quite certain at some point I packaged freeglut, but I can't seem to find it right now. You'll have to use another high level library (eg. SDL which we do package) instead. Or compile freeglut -- a bit tricky because the build system doesn't understand cross-compilation. There's also a specific mailing list for Fedora MinGW questions: https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw and if you want to package something up, I've written some notes here: http://fedoraproject.org/wiki/MinGW/New_package For anything else, see our SIG: http://fedoraproject.org/wiki/SIGs/MinGW Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- 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/14/2009 01:13 PM, Kevin Kofler wrote: Rahul Sundaram wrote: If maintainers choose to include a beta release, then it would have been better to collect more feedback for a longer period of time for updates. I already answered this in more detail on your blog, but: 1. It's a security update, so a short testing period is normal. That really depends on the severity of the update vs the potential to cause problems. Remember the d-bus security update that caused so many problems not so long ago? That one was a security update as well. https://admin.fedoraproject.org/updates/F11/FEDORA-2009-9911?_csrf_token=b77b748e49c5311eb85031331cb2f6474028d615 The update neither details what the security issues or nor does it tell what other changes have been made. Not even a link to the upstream release notes. So let's look at that http://www.mozillamessaging.com/en-US/thunderbird/3.0b4/releasenotes/ Hmmm. Not much details on what the security issue being fixed is. The only mention of security is about some SSL change http://www.rumblingedge.com/2009/09/23/thunderbird-3-beta-4-released/ So I have no idea how severe the security problem was 2. It reached +3 karma and got automatically queued for stable. Are you claiming that there is no way for maintainers to determine how long the update stays in updates-testing repository? If not, I don't see this point as relevant. My mails to this list is my negative karma. But it's too late, the update already got pushed. It isn't too late to push another update that fixes the problem. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mingw32 suite
On Wed, Oct 14, 2009 at 09:11:05AM +0100, Richard W.M. Jones wrote: However where you might get stuck is that we don't currently ship GLUT or freeglut. I'm quite certain at some point I packaged freeglut, but I can't seem to find it right now. I've packaged mingw32-freeglut for you: https://bugzilla.redhat.com/show_bug.cgi?id=528892 With this I was able to compile some examples from the OpenGL page here: http://www.opengl.org/resources/code/samples/glut_examples/examples/examples.html eg: i686-pc-mingw32-gcc cube.c -o cube -lglut -lglu32 -lopengl32 wine ./cube You may need to set up Wine paths by following the instructions here: https://fedoraproject.org/wiki/MinGW/Configure_wine Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Wed, 14 Oct 2009 08:58:45 +0200, Kevin wrote: We really need some stricter enforcement against stuff sitting in testing forever. Rather we need some rules against such mindset. We don't guarantee anything about updates-testing. It's a place where to test potential updates/upgrades. And if a test-update is still without sufficient karma points (either positive or negative) for several weeks, it may stay in updates-testing for a longer time. IMO, that's a good thing. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
Dne 14.10.2009 08:58, Kevin Kofler napsal(a): Never is definitely the wrong answer: updates-testing is not for stuff which is too unstable to go stable, ever. Any update sitting in testing for more than (at most) 2 or 3 weeks (usually 1 week is enough, but risky stuff should get approximately 2 weeks of testing and regression fixing; at least those are the timings our experience in KDE SIG showed optimal) is either broken, in which case it should be unpushed (and the maintainer should be more careful next time), or not, in which case it should be promoted to stable. We really need some stricter enforcement against stuff sitting in testing forever. This is actually your personal opinion AFAIK, right? I tend to disagree with this -- one example which seems to me legitimate is when I create a new package (I remember I came to this conclusion with both PSPP and nimbus-theme) then I sometimes push it into Fedora-[n-1] just for updates-testing, because I really don't have enough computers to do real testing on older distros. By that, people who really want it, can take it and they are implicitly warned that this is not meant to be stable (generally speaking, I guess, people who follow updates-testing has to survive some amount of breakage), but it is not thrown on unsuspecting users of stable. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC The ratio of literacy to illiteracy is a constant, but nowadays the illiterates can read. -- Alberto Moravia -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mingw32 suite
On Wed, Oct 14, 2009 at 5:56 AM, Richard W.M. Jones rjo...@redhat.comwrote: On Wed, Oct 14, 2009 at 09:11:05AM +0100, Richard W.M. Jones wrote: However where you might get stuck is that we don't currently ship GLUT or freeglut. I'm quite certain at some point I packaged freeglut, but I can't seem to find it right now. I've packaged mingw32-freeglut for you: https://bugzilla.redhat.com/show_bug.cgi?id=528892 With this I was able to compile some examples from the OpenGL page here: http://www.opengl.org/resources/code/samples/glut_examples/examples/examples.html eg: i686-pc-mingw32-gcc cube.c -o cube -lglut -lglu32 -lopengl32 wine ./cube You may need to set up Wine paths by following the instructions here: https://fedoraproject.org/wiki/MinGW/Configure_wine I created mingw32-freeglut-2.6.0-0.1.rc1.fc10.noarch.rpm and compiled cube.c, but it does not run on wine: [cascavel:~/cg/TutorsMin1.0] cube.exe err:module:import_dll Library glut32.dll (which is needed by LF:\\roma\\cg\\TutorsMin1.0\\cube.exe) not found err:module:LdrInitializeThunk Main exe initialization for LF:\\roma\\cg\\TutorsMin1.0\\cube.exe failed, status c135 However, it runs just fine on VirtualBox. In fact, I built some other examples too: http://orion.lcg.ufrj.br/temp/TutorsMin1.0/ Do you want me to review your mingw32-freeglut package? Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091014 changes
Compose started at Wed Oct 14 06:15:07 UTC 2009 Broken deps for i386 -- sugar-toolkit-0.86.0-1.fc12.i686 requires python-json Broken deps for x86_64 -- sugar-toolkit-0.86.0-1.fc12.x86_64 requires python-json Broken deps for ppc -- sugar-toolkit-0.86.0-1.fc12.ppc requires python-json Broken deps for ppc64 -- python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot sugar-toolkit-0.86.0-1.fc12.ppc64 requires python-json Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mingw32 suite
On Wed, Oct 14, 2009 at 06:46:41AM -0300, Paulo Cavalcanti wrote: I created mingw32-freeglut-2.6.0-0.1.rc1.fc10.noarch.rpm and compiled cube.c, but it does not run on wine: [cascavel:~/cg/TutorsMin1.0] cube.exe err:module:import_dll Library glut32.dll (which is needed by LF:\\roma\\cg\\TutorsMin1.0\\cube.exe) not found err:module:LdrInitializeThunk Main exe initialization for LF:\\roma\\cg\\TutorsMin1.0\\cube.exe failed, status c135 Did you adjust the Wine paths as described in my posting? Without doing that Wine won't be able to find the glut library. Do you want me to review your mingw32-freeglut package? Sure, if you don't mind. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On 10/13/2009 09:56 AM, Christopher Aillon wrote: Not everyone had issues with the indexing so that seemed to slip past testing. It was a change, but didn't seem to disrupt things, so we let it slide. Not to pile on, believe me I know painful change is... 8-) but... This new indexing is the biggest pain of all the changes IMHO... My laptop CPU start to and continues to be pegged when I start up and shut down TB3b... I could not read mail for 24hrs due to TPB3 trying to indexing all my mail... Granted I have a ton of mail, in large number of folders... but my CPU became pegged, TPB3 start to eat all the memory, causing everything to be swapped out, which caused the system to finally hang!! This was happen continuously. So I figured the only way to get by this was to delete mail... Which became a race between me deleting mail and TB3b try to index that folder... I have a feeling that scenario was not tested too well... ;-) So for you to say indexing didn't seem to disrupt things is simply inaccurate... It was a major disruption and a complete waste of time... steved. -- 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/14/2009 08:21 AM, Steve Dickson wrote: On 10/13/2009 09:56 AM, Christopher Aillon wrote: Not everyone had issues with the indexing so that seemed to slip past testing. It was a change, but didn't seem to disrupt things, so we let it slide. Not to pile on, believe me I know painful change is... 8-) but... This new indexing is the biggest pain of all the changes IMHO... My laptop CPU start to and continues to be pegged when I start up and shut down TB3b... I could not read mail for 24hrs due to TPB3 trying to indexing all my mail... Granted I have a ton of mail, in large number of folders... but my CPU became pegged, TPB3 start to eat all the memory, causing everything to be swapped out, which caused the system to finally hang!! This was happen continuously. So I figured the only way to get by this was to delete mail... Which became a race between me deleting mail and TB3b try to index that folder... I have a feeling that scenario was not tested too well... ;-) So for you to say indexing didn't seem to disrupt things is simply inaccurate... It was a major disruption and a complete waste of time... Agreed. Or put more simply, this bug fix update dropped an unexpected, 2+ gigabyte turd into my NFS-mounted home directory [jgar...@bd ~]$ ls -l ~/.thunderbird/tc8ktlwu.default/global-messages-db.sqlite -rw-r--r-- 1 jgarzik jgarzik 2731515904 2009-10-14 08:42 /g/g/.thunderbird/tc8ktlwu.default/global-messages-db.sqlite as well as slowing down all my NFS accesses for ~24 hours. I hope a thunderbird update is being prepared, to make 2 config tweaks for F11? And a warning / release note for F12 users, noting that a __lot__ of additional disk space is required in ~/.thunderbird. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upload debug-like-info to Mozilla servers every update
On 09/18/2009 05:22 PM, Colin Walters wrote: We could do that, but a more ideal world would be where our ABRT system can give them as useful and reliable data as their usage of breakpad on Windows and OS X does. There are multiple components here, the biggest of which is that we need to avoid requiring a Bugzilla account for crash submissions, and we need to make it about one click. Once we have the data reliably, Mozilla could pull crashes from our system into theirs, say a cron job which just does: wget http://crashes.fedoraproject.org/package/mozilla/20091018.tar.gz Mozilla prefers using their own system in this case. It has some pros, like user don't have to download debug packages (which is approx 80MB for each package). Building the symbols for Mozilla is also quite easy. They have everything prepared in their makefiles and their debug info is just one zip file. All we need is to put this zip file somewhere that mozilla could pull it (or we push it after package is released). This zip file should be left aside from regular rpm package (read unpublished). -- Jan Horak -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Are packages w/o necessary kernel modules allowed?
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? -- With best regards, Peter Lemenkov. -- 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?
Original Message Subject: Are packages w/o necessary kernel modules allowed? From: Peter Lemenkov lemen...@gmail.com To: Development discussions related to Fedora fedora-devel-list@redhat.com Date: 14.10.2009 15:04 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? If not, what does dahdi-tools do in Fedora then? Felix -- 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?
yes, I am already told this for you. for example I have user-mode-linux user space but I don't have user-mode-linux enabled in kernel. On Wed, Oct 14, 2009 at 10:04 AM, Peter Lemenkov lemen...@gmail.com 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? -- With best regards, Peter Lemenkov. -- Itamar Reis Peixoto e-mail/msn: ita...@ispbrasil.com.br sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 -- 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/14/2009 09:04 AM, 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? This is an interesting question. Suppose someone wrote (for example) an GPLed configuration tool for a closed-source hardware driver. Would it be permissible to include an open-source tool in the distribution, even knowing it would only ever be usable with a tainted kernel? - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkrVzcsACgkQeiVVYja6o6NwgwCdG10cCIr2pn+HhRWBXx+u4aB7 o8gAn0X1WOxe0Tu8Jo90V0O+cJhnTMPk =VFnY -END PGP SIGNATURE- -- 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?
2009/10/14 Stephen Gallagher sgall...@redhat.com: This is an interesting question. Suppose someone wrote (for example) an GPLed configuration tool for a closed-source hardware driver. Would it be permissible to include an open-source tool in the distribution, even knowing it would only ever be usable with a tainted kernel? An example from a real life is a proprietary drivers, which sometimes has only kernel-part closed, while has opensourced userspace. -- With best regards, Peter Lemenkov. -- 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 Wed, Oct 14, 2009 at 8:07 AM, Felix Kaechele fe...@fetzig.org wrote: Original Message Subject: Are packages w/o necessary kernel modules allowed? From: Peter Lemenkov lemen...@gmail.com To: Development discussions related to Fedora fedora-devel-list@redhat.com Date: 14.10.2009 15:04 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. If not, what does dahdi-tools do in Fedora then? Nothing, at least not without a kernel module that's not in the stock Fedora kernel. The DAHDI kernel modules are GPL, but Digium has been unwilling to merge them into the upstream kernel. -- Jeff Ollie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upload debug-like-info to Mozilla servers every update
On Wed, Oct 14, 2009 at 9:04 AM, Jan Horak jho...@redhat.com wrote: Mozilla prefers using their own system in this case. It has some pros, like user don't have to download debug packages (which is approx 80MB for each package). Building the symbols for Mozilla is also quite easy. They have everything prepared in their makefiles and their debug info is just one zip file. All we need is to put this zip file somewhere that mozilla could pull it (or we push it after package is released). This zip file should be left aside from regular rpm package (read unpublished). In that case I'd just make the mozilla spec file to put the .zip in the -debuginfo package. Then their crash handling code just needs to get the built RPM NVRA (it should probably be compiled in, but forking a rpm -q could work I guess), and their server side can fairly easily script a wget http://download.fedoraproject.org/.../mozilla-debuginfo-12345.rpm;. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
Rahul Sundaram sundaram at fedoraproject.org writes: problems was known then reversing the release was not really an option. Why not? The maintainer says it is a option and it is definitely feasible to release a update that disables these couple of features by default rather than make everybody go through the same problems. I don't understand your view point at all. Changelog or even testing notes is useful to guide testers into checking for problems but once the problems are evident, we should just address them directly. Only a tiny fraction of our users will read such notes and it is not reasonable to expect them to continue to suffer. Yes if it is an option to release a new package update that will have smart folders and GLODA turned off then great - however I presume that the significant majority of F11 users will already have updated and therefore already have been hit by the change - so have either gone through the pain and reset their parameters by now or dumped TB in favour of another mail client. Therefore the gain of a new update will (to me) seem not provide much in the way of help now that the damage (of the beta4) has already been done. I guess that 3.0pre is not far away, and perhaps in this next update the smart folders and GLODA can be off by default. I must admit that I would also like to see the normal icons unchanged on the top taskbar in TB - I simply re-instated what I want, but I would have preferred that the update did not take them away in the first place. Again I have made the changes necessary to get 3.0b4 working nicely (there are some residual bugs though - like occasionally the compose window gets its formatting slightly awry and won't send and restarting TB then fixes it) Anyway hopefully this event will inform how the next update gets planned so that it does not upset as many people next time? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
Jeff Garzik jgarzik at pobox.com writes: I hope a thunderbird update is being prepared, to make 2 config tweaks for F11? And a warning / release note for F12 users, noting that a __lot__ of additional disk space is required in ~/.thunderbird. Jeff Hopefully the default will be GLODA=off and smart folders=off and then the additional humungous file space requirements will not be needed and the user presentation a lot more familiar as well as functional? I must admit I cannot imagine why the thunderbird developers wanted the global indexing thing in the first place - I, like many others, keep mail accounts separate for a good reason - and I don't want a global search - it is insane - and I also don't want to munge my inboxes together - I keep work and private mail as well as other accounts separate so they there is no mixing and merging. Hopefully f12 TB will arrive and function smoothly (hands clasped together, eyes looking upward, channelling all the power of prayer..and hoping the developers are listening!) -- 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/14/2009 07:39 PM, Mike Cloaked wrote: Yes if it is an option to release a new package update that will have smart folders and GLODA turned off then great - however I presume that the significant majority of F11 users will already have updated and therefore already have been hit by the change - so have either gone through the pain and reset their parameters by now or dumped TB in favour of another mail client. Not sure there is any basis for that claim since we don't collect detailed stats on how frequent Fedora users do update but a problem of this nature is known, it is better to resolve it quickly rather than assume that everybody has already learned to cope up with it. Anyway, this debate is essentially over at this point since a update with the defaults changed is being pushed out. http://mether.wordpress.com/2009/10/14/thunderbird-problem-gets-fixed/ Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
Rahul Sundaram sundaram at fedoraproject.org writes: Anyway, this debate is essentially over at this point since a update with the defaults changed is being pushed out. http://mether.wordpress.com/2009/10/14/thunderbird-problem-gets-fixed/ Rahul OK - I hope this runs smoothly and hopefully we all learned from this event (just like the d-bus event!) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On Wed, 2009-10-14 at 09:37 -0500, Mike McGrath wrote: On Wed, 14 Oct 2009, Jesse Keating wrote: On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote: The problem isn't GLODA and smart folders, it's that we have no process in place to identify and deal with problems like this before it's too late. Aside from updates-testing you mean, where people can test potential updates and give feedback as to how they work on their systems? Fat lot of good it's doing. -Mike And that's a people problem more than a process problem. If nobody tests it in updates-testing, then how is the maintainer to know that it is problematic? Certainly not solvable with even more repos for testing content... -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On Wed, 14 Oct 2009, Jesse Keating wrote: On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote: The problem isn't GLODA and smart folders, it's that we have no process in place to identify and deal with problems like this before it's too late. Aside from updates-testing you mean, where people can test potential updates and give feedback as to how they work on their systems? To me it seems very clear that at least some significant portion of our users want the new thunderbird. But it should not have been pushed on to everyone. I can't imagine someone like steved who keeps all of their email forever... but instead of knowing what happened like steved did, now has no idea why their computer has just stopped working. What do you think their opinion of Fedora is right now? Feodra 11 should not have shipped with a beta but the previous stable version. The beta should have been in it's on repo where it could have been maintained and updated outside of the main tree. Like an experimental repo. Not a repo to see if it works and 3 people can speak for everyone and have it pushed. But a repo on it's own where we all acknowledge it's buggy but that's ok because it's not enabled by default. Stability for all, a little blood for those that acknowledge they can handle it. -Mike -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On Wed, 14 Oct 2009, Jesse Keating wrote: On Wed, 2009-10-14 at 09:37 -0500, Mike McGrath wrote: On Wed, 14 Oct 2009, Jesse Keating wrote: On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote: The problem isn't GLODA and smart folders, it's that we have no process in place to identify and deal with problems like this before it's too late. Aside from updates-testing you mean, where people can test potential updates and give feedback as to how they work on their systems? Fat lot of good it's doing. -Mike And that's a people problem more than a process problem. If nobody tests it in updates-testing, then how is the maintainer to know that it is problematic? Certainly not solvable with even more repos for testing content... You let me know how three people in Fedora can miss a very subtle Firefox memory leak. How many people would need to use updates testing before the thunderbird indexing problem is caught? How long would it need to stay there? In this case updates-testing theory just does not match reality. The status quo is broken, doing nothing will keep it that way. -Mike -- 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/14/2009 08:23 PM, Jesse Keating wrote: And that's a people problem more than a process problem. If nobody tests it in updates-testing, then how is the maintainer to know that it is problematic? Certainly not solvable with even more repos for testing content... 3 people give positive feedback and the update is automatically pushed from updates-testing to updates despite atleast one feedback to the contrary at https://admin.fedoraproject.org/updates/F11/FEDORA-2009-9911?_csrf_token=b77b748e49c5311eb85031331cb2f6474028d615 The UI changes certainly would be visible without any user feedback. The buttons getting removed from the toolbar as well as smart folders were immediately visible within minutes. Anyone with significant amount of email would probably run into the indexing issue soon as well. Note that the update indicates it is a security issue but doesnt explain what the security fix is nor does it indicate what other major changes are there. No notes has been entered to assist the testers. I don't think the onus can be placed entirely on potential testers to provide feedback within a week. That is just finger pointing and doesn't help address such problems or even mitigate it. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
thunderbird rel-eng
On 10/14/2009 10:31 AM, Jesse Keating wrote: On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote: The problem isn't GLODA and smart folders, it's that we have no process in place to identify and deal with problems like this before it's too late. Aside from updates-testing you mean, where people can test potential updates and give feedback as to how they work on their systems? Do you honestly believe this was a testing problem? Long after F11 release, we had an update billed as a bug fix that included 1) a major UI change. 2) additional home directory disk space requirement, several GIGABYTES in size. A non-trivial, on-going CPU usage requirement, as well. 3) global indexing which lumps together, in a single file, distinctly separate email accounts. This potentially creates a LEGAL PROBLEM for end users. These changes in the middle of a stable Fedora release are outside the bounds of normal, expected bug fixes. That is simply not up to Fedora standards by any stretch of the imagination. The above are major problems that should be caught by a release engineering process... the maintainer if nobody else. Jeff -- 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 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: thunderbird upgrade - wtf?
On 10/13/2009 09:56 AM, Christopher Aillon wrote: Not everyone had issues with the indexing so that seemed to slip past testing. It was a change, but didn't seem to disrupt things, so we let it slide. We are looking at reverting both in F11. Global indexing introduces legal issues, disk space requirements and CPU requirements that extend beyond F11... Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
Jeff Garzik wrote: Global indexing introduces legal issues, disk space requirements and CPU requirements that extend beyond F11... Maybe I'm a bit stupid, but what is the significance of how many files your emails are stored in? Separating them out provides some sort of security advantage? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mingw32 suite
On Wed, Oct 14, 2009 at 8:43 AM, Richard W.M. Jones rjo...@redhat.comwrote: On Wed, Oct 14, 2009 at 06:46:41AM -0300, Paulo Cavalcanti wrote: I created mingw32-freeglut-2.6.0-0.1.rc1.fc10.noarch.rpm and compiled cube.c, but it does not run on wine: [cascavel:~/cg/TutorsMin1.0] cube.exe err:module:import_dll Library glut32.dll (which is needed by LF:\\roma\\cg\\TutorsMin1.0\\cube.exe) not found err:module:LdrInitializeThunk Main exe initialization for LF:\\roma\\cg\\TutorsMin1.0\\cube.exe failed, status c135 Did you adjust the Wine paths as described in my posting? Without doing that Wine won't be able to find the glut library. Yes: PATH=str(2):c:\\windows\\system;c:\\windows;Z:\\usr\\i686-pc-mingw32\\sys-root\\mingw\\bin The problem is that I do no have a glut32.dll on my system. I only have a /usr/i686-pc-mingw32/sys-root/mingw/bin/libglut-0.dll in mingw\bin The programs run fine on VirtualBox, but I always get this message: $ fog.exe OpenGL Warning: No pincher, please call crStateSetCurrentPointers() in your SPU I need to investigate the cause. Do you want me to review your mingw32-freeglut package? Sure, if you don't mind. I'll do it. I tested glut on F10, and it worked very well. However, F11 seems not to be finding glut32, but I need to test it better. -- Paulo Roma Cavalcanti LCG - UFRJ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Updates-testing (was: Re: thunderbird upgrade - wtf?)
On 14/10/09 15:31, Jesse Keating wrote: On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote: The problem isn't GLODA and smart folders, it's that we have no process in place to identify and deal with problems like this before it's too late. Aside from updates-testing you mean, where people can test potential updates and give feedback as to how they work on their systems? For me, there is a bit of a problem with updates-testing: the machine I work on is my primary desktop, and I'm extremely wary of getting myself into a situation I can't easily get out of. Now, you might argue that avoiding u-t is essentially avoiding the inevitable (and Tbird 3 has shown me that, so I agree), but it is riskier. What would sell me totally on u-t was if there was something where I can roll back bad packages. I'm pretty sure there are various obscure technical reasons why rolling back isn't possible in 100% of cases, but I don't think that's necessary. So long as it's in the high 90%s then it's good enough, and to be honest I would want to avoid testing updates I can't revert like the plague anyway: not being able to roll back to my mind is a good indicator of not being suitable for a stable release. In my ideal world, PackageKit would update my stuff with testing updates, and anything which broke could be reverted back to some previous date or something - either by package if I can identify it, or by actual last-known-good date. I'm sure that's a tonne of work, but that's the only way I can see the testing system making sense for people who rely on their Fedora desktop. Cheers Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 15:31, Jesse Keating wrote: On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote: The problem isn't GLODA and smart folders, it's that we have no process in place to identify and deal with problems like this before it's too late. Aside from updates-testing you mean, where people can test potential updates and give feedback as to how they work on their systems? For me, there is a bit of a problem with updates-testing: the machine I work on is my primary desktop, and I'm extremely wary of getting myself into a situation I can't easily get out of. Now, you might argue that avoiding u-t is essentially avoiding the inevitable (and Tbird 3 has shown me that, so I agree), but it is riskier. What would sell me totally on u-t was if there was something where I can roll back bad packages. I'm pretty sure there are various obscure technical reasons why rolling back isn't possible in 100% of cases, but I don't think that's necessary. So long as it's in the high 90%s then it's good enough, and to be honest I would want to avoid testing updates I can't revert like the plague anyway: not being able to roll back to my mind is a good indicator of not being suitable for a stable release. In my ideal world, PackageKit would update my stuff with testing updates, and anything which broke could be reverted back to some previous date or something - either by package if I can identify it, or by actual last-known-good date. I'm sure that's a tonne of work, but that's the only way I can see the testing system making sense for people who rely on their Fedora desktop. yum downgrade pkgname it works fine for the simple-ish cases. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird rel-eng
On Wed, 2009-10-14 at 11:10 -0400, Jeff Garzik wrote: On 10/14/2009 10:31 AM, Jesse Keating wrote: On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote: The problem isn't GLODA and smart folders, it's that we have no process in place to identify and deal with problems like this before it's too late. Aside from updates-testing you mean, where people can test potential updates and give feedback as to how they work on their systems? Do you honestly believe this was a testing problem? Long after F11 release, we had an update billed as a bug fix that included 1) a major UI change. 2) additional home directory disk space requirement, several GIGABYTES in size. A non-trivial, on-going CPU usage requirement, as well. 3) global indexing which lumps together, in a single file, distinctly separate email accounts. This potentially creates a LEGAL PROBLEM for end users. These changes in the middle of a stable Fedora release are outside the bounds of normal, expected bug fixes. That is simply not up to Fedora standards by any stretch of the imagination. The above are major problems that should be caught by a release engineering process... the maintainer if nobody else. Jeff updates-testing /is/ the release engineering process. There is simply too many packages for the one of me to manage. That none of the testers thought anything was wrong with this update is the testing problem. That the maintainer stuck it with a 3 karma limit is another problem. That the maintainer thought it was OK to majorly change UI in the middle of a release is a third problem. There is no one entity at fault here, and there is no magic bullet to fix it. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 15:31, Jesse Keating wrote: On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote: The problem isn't GLODA and smart folders, it's that we have no process in place to identify and deal with problems like this before it's too late. Aside from updates-testing you mean, where people can test potential updates and give feedback as to how they work on their systems? For me, there is a bit of a problem with updates-testing: the machine I work on is my primary desktop, and I'm extremely wary of getting myself into a situation I can't easily get out of. Now, you might argue that avoiding u-t is essentially avoiding the inevitable (and Tbird 3 has shown me that, so I agree), but it is riskier. What would sell me totally on u-t was if there was something where I can roll back bad packages. I've suggested this very thing in a F-A-B thread this week. We, packagers, have no way to fix a mistake and very few things preventing us from making them: https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00168.html -Mike -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On Wed, 2009-10-14 at 11:31 -0400, Jeff Garzik wrote: On 10/13/2009 09:56 AM, Christopher Aillon wrote: Not everyone had issues with the indexing so that seemed to slip past testing. It was a change, but didn't seem to disrupt things, so we let it slide. We are looking at reverting both in F11. Global indexing introduces legal issues, disk space requirements and CPU requirements that extend beyond F11... Jeff Those are defaults that a user can change. Granted, existing setups shouldn't be automatically moved to the new default, but new installs of a new release should default to the upstream default. If the user doesn't find those settings acceptable, they can change them. The trick is to not surprise existing users with massive change. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On 10/14/2009 11:35 AM, Michael Cronenworth wrote: Jeff Garzik wrote: Global indexing introduces legal issues, disk space requirements and CPU requirements that extend beyond F11... Maybe I'm a bit stupid, but what is the significance of how many files your emails are stored in? Separating them out provides some sort of security advantage? Legally speaking, it is important, if I am ever called into court, to be able to show a distinct separation between my personal email and my NDA-heavy Red Hat email. And, bboth of which must be separate from my micro-micro-corporation. If one does not demonstrate intent at creating walls separating legal entities, it becomes a whole lot easier for a GarzikMicroCorp-related lawsuit to subpoena my personal and Red Hat email. Separation of data is basic legal CYA. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, 14 Oct 2009, Mike McGrath wrote: I've suggested this very thing in a F-A-B thread this week. We, packagers, have no way to fix a mistake and very few things preventing us from making them: https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00168.html Seriously: yum downgrade and in F12 - try out things like the history undo options. there are lots of potential nasty situations that can happen but I think the general consensus was 'screw it, let the user sort it out if it breaks, which it often does not' generally, if the app you updated modifies its data format and cannot revert it then the user is SOL - but that's not _THAT_ common and when it does happen it's certainly not yum's fault. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
Jeff Garzik wrote: Legally speaking, it is important, if I am ever called into court, to be able to show a distinct separation between my personal email and my NDA-heavy Red Hat email. And, bboth of which must be separate from my micro-micro-corporation. If one does not demonstrate intent at creating walls separating legal entities, it becomes a whole lot easier for a GarzikMicroCorp-related lawsuit to subpoena my personal and Red Hat email. Separation of data is basic legal CYA. I fully understand the separation of email accounts, but what I'm getting at is the storage of your binary data on the hard disk. If you keep any personal email on your hard disk, and the whole disk is subpoenaed, your personal+RH email will be on it. The only safe way to prevent that is to not use TB at all. It keeps caches of everything whether you like it or not. In fact, it might be a cool feature to add to TB - a corporate mode so to speak - that prevents any and all local storage of email data. -- 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 Wed, Oct 14, 2009 at 5:29 PM, Ralf Corsepius rc040...@freenet.de wrote: On 10/14/2009 03:04 PM, Peter Lemenkov wrote: 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. Which is precisely the reason why sysprof was moved to rpmfusion when kmods were banned from Fedora -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On 10/14/2009 12:03 PM, Michael Cronenworth wrote: I fully understand the separation of email accounts, but what I'm getting at is the storage of your binary data on the hard disk. If you keep any personal email on your hard disk, and the whole disk is subpoenaed, your personal+RH email will be on it. The only safe way to prevent that is to not use TB at all. It keeps caches of everything whether you like it or not. In fact, it might be a cool feature to add to TB - a corporate mode so to speak - that prevents any and all local storage of email data. That is why my cache points to a tmpfs location... goes away after each reboot. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On Wed, Oct 14, 2009 at 10:00:07AM -0500, Mike McGrath wrote: You let me know how three people in Fedora can miss a very subtle Firefox memory leak. How many people would need to use updates testing before the thunderbird indexing problem is caught? How long would it need to stay there? In this case updates-testing theory just does not match reality. Maybe 1 in 10 Fedora installs at random should have updates-testing enabled by default? (Joke, joke ...) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On 14/10/09 16:49, Mike McGrath wrote: I've suggested this very thing in a F-A-B thread this week. We, packagers, have no way to fix a mistake and very few things preventing us from making them: https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00168.html I love this! I would say having an experimental repo wouldn't be as good as having per-app repos: for me, there are apps I care about and want to test, and others I use infrequently and couldn't contribute much to. However, if on the other hand there was some way of marking out which packages I wanted to pull from experimental (or updates-testing for that matter), then well and good. I think experimental is needed, though. Some apps really need longer baking before getting into Fedora proper: Tbird 3 for me is an excellent example, although probably for the maintainer one which is much more obvious in hindsight. The change in mission makes a huge amount of sense (being usable, if not bug-free, has to be a top priority in my mind). For my money, a great proposal though, thanks. Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) Ideally, for me, this would be something pk can trigger (and maybe give me a way of contributing to the testing karma at the same time - that would rock). Personally, though, I would think that if that is a feature we're advertising then it should be policy that either a. package maintainers strive to ensure their packages are mainly downgradable (certainly within a stable release) or b. the packages are marked as don't downgrade me and yum/whatever issues the appropriate expletive when you try to do that. I would say again that any package update which cannot be downgraded would be one I would think hard about releasing into a stable Fedora. Cheers Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) That's pretty amusing considering PK cannot do much of anything on fedora w/o yum. It can't even fetch repodata. Ideally, for me, this would be something pk can trigger (and maybe give me a way of contributing to the testing karma at the same time - that would rock). Then file an RFE with the PK folks. -sv -- 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 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. If it was something like Firefox that needed a proprietary kernel extension, then yes that would be really bad. But a small, obscure package used to configure a specialized piece of hardware, and that comes with adequate documentation, why not let it in? # config-foo Error: This requires a non-free kernel module 'foo.ko' which can't be shipped in Fedora. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) Ideally, for me, this would be something pk can trigger (and maybe give me a way of contributing to the testing karma at the same time - that would rock). Even with downgrade, that's a user action. If the user happens to know about it they'll be ok. I'm more interested in what options a packager has to fix problems like this. -Mike -- 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?
Original Message Subject: Re: Are packages w/o necessary kernel modules allowed? From: Ralf Corsepius rc040...@freenet.de To: Development discussions related to Fedora fedora-devel-list@redhat.com Date: 14.10.2009 17:29 IMO: no. Packages in Fedora should just work and therefore must not rely on anything which is not in Fedora. From the opposite POV: Why should we make peoples' lives harder getting the tools they need? Example: Somebody without the DAHDI Kernel Modules would probably not try to use the DAHDI Tools since he probably won't even know what it's good for. However It makes things easier for the people who do know what DAHDI is to have tools to use their DAHDI hardware (they compiled/got the Kernel modules for) just a yum install away. Felix -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On Wed, 14 Oct 2009, Mike McGrath wrote: On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) Ideally, for me, this would be something pk can trigger (and maybe give me a way of contributing to the testing karma at the same time - that would rock). Even with downgrade, that's a user action. If the user happens to know about it they'll be ok. I'm more interested in what options a packager has to fix problems like this. The packager can issue a new pkg which is the old pkg with a bumped epoch. then the user will get that in the next update. this is one of the reasons why epochs exist, ultimately. -sv -- 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 09:56 PM, Seth Vidal wrote: On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) That's pretty amusing considering PK cannot do much of anything on fedora w/o yum. It can't even fetch repodata. IIRC the wording has been fixed to not classify yum as legacy in recent PackageKit versions. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
What about using LVM to store a pre-update snapshot of your distro? (Separate root partition from /home and other stuff, of course. Roll back root). Highly inconvenient, but it would theoretically work... On Wed, Oct 14, 2009 at 11:54 AM, Seth Vidal skvi...@fedoraproject.org wrote: On Wed, 14 Oct 2009, Mike McGrath wrote: I've suggested this very thing in a F-A-B thread this week. We, packagers, have no way to fix a mistake and very few things preventing us from making them: https://www.redhat.com/archives/fedora-advisory-board/2009-October/msg00168.html Seriously: yum downgrade and in F12 - try out things like the history undo options. there are lots of potential nasty situations that can happen but I think the general consensus was 'screw it, let the user sort it out if it breaks, which it often does not' generally, if the app you updated modifies its data format and cannot revert it then the user is SOL - but that's not _THAT_ common and when it does happen it's certainly not yum's fault. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, 14 Oct 2009, Jud Craft wrote: What about using LVM to store a pre-update snapshot of your distro? (Separate root partition from /home and other stuff, of course. Roll back root). Highly inconvenient, but it would theoretically work... It doesn't really help you when your data is modified by the update. example: installed: foo-1.0 data format: user:group:data:index:key update: foo-1.2 data is migrated forward from the old format to the new one, new format is stored in the same file but is: user:group,group,group,group:data:data:data:index (obviously I'm just making up the data format :) how do you roll back and not lose access to the data in that file? -sv -- 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: Updates-testing
On Wed, 14 Oct 2009, Ralf Corsepius wrote: 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. easy to blacklist it in yum add: exclude=thunderbird\* to fedora, updates and updates-testing repos. that should keep it out. might be some deps there too - I haven't looked closely. -sv -- 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 Wed, 14 Oct 2009, Ralf Corsepius wrote: 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. I think I agree. This is just like shipping a package with an intentionally missing dependency. We wouldn't allow shipping yum if rpm were missing, right? this sounds the same to me. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing
On Wed, 2009-10-14 at 11:30 -0500, Mike McGrath wrote: On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) Ideally, for me, this would be something pk can trigger (and maybe give me a way of contributing to the testing karma at the same time - that would rock). Even with downgrade, that's a user action. If the user happens to know about it they'll be ok. I'm more interested in what options a packager has to fix problems like this. -Mike In this specific case, issue a bumped build of thunderbird with the UI settings defaulted to what they were before the change. New code, old UI. In the general case this could also be done, or a package could be reverted to older code, but with an epoch to ensure package ordering. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, 2009-10-14 at 10:49 -0500, Mike McGrath wrote: have no way to fix a mistake That is complete bullshit. You have many ways to fix mistakes. Newer builds with patches, reverted code with epoch, newer upstream release to fix the mistake upstream, etc.. To say that there is no way to fix a mistake is insulting. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
Mike McGrath mmcgrath at redhat.com writes: And that's a people problem more than a process problem. If nobody tests it in updates-testing, then how is the maintainer to know that it is problematic? Certainly not solvable with even more repos for testing content... You let me know how three people in Fedora can miss a very subtle Firefox memory leak. How many people would need to use updates testing before the thunderbird indexing problem is caught? How long would it need to stay there? In this case updates-testing theory just does not match reality. The status quo is broken, doing nothing will keep it that way. -Mike Actually I don't think the blame is directly layable at the feet of either the Fedora maintainer (who pushed an update with reasonable reports in bodhi according to normal practice), nor the Fedora process which should have worked if no poor upstream changes were made - but in fact this shows up the vulnerability of Fedora to packages which have bad decisions made upstream. In this case the upstream developers made a really bad decision to foist the GLODA change and the smart folder change on users who installed this beta, instead of taking the safer, and in my view better, decision to bring in these new features, but to leave them switched off by default, but to advertise the availability of these new features big time, and then let this simmer for a while and wait for any bad user feedback. Only if the new features were then shown to be acceptable should they be enabled in a future update by default. In this case, going that route would have shown that the new features were certainly not acceptable to all users, and in particular users with large amounts of stored mail with multiple accounts. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, Oct 14, 2009 at 1:08 PM, Jesse Keating wrote: Newer builds with patches, reverted code with epoch, newer upstream release to fix the mistake upstream, etc.. To say that there is no way to fix a mistake is insulting. I'd like to logic-link here with the following... On Wed, Oct 14, 2009 at 12:57 PM, Seth Vidal wrote: It doesn't really help you when your data is modified by the update. So if my LVM snapshot and revert entire Fedora installed idea is dismissed as still not perfect, why is just revert one package pushed as a legitimate alternative? They both suffer from the same problem -- new packages may cause changes in data that are not reversibly compatible with the old package, and mere package rollback is not useful. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, Oct 14, 2009 at 1:11 PM, Jud Craft wrote: They both suffer from the same problem -- new packages may cause changes in data that are not reversibly compatible with the old package, and mere package rollback is not useful. Of course, I imagine that any rollback system that doesn't involve user data will have the same problem, theoretically. That includes any backup system that treats system programs separate from user data, when in fact one DOES change the other. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, Oct 14, 2009 at 1:13 PM, Seth Vidal wrote: There's no perfect. we're just going for 'good enough', really. Ah, so package-rollback is shipped as the halfway-effective crutch, but it's so easy to implement we might as well offer it anyway solution. Or, the excellent implementation of an incomplete solution. [No offense to the infrastructure design of yum, just stating the obvious here.] On the side, I store all of my user data and documents separate from my own actual home partition, and with every install I just wipe the home, and then re-link my documents and data to it. This scheme works decently (application-specific schemas and configs that are subject to irreversible change are discarded and recreated). But it's a pain to compensate for an inconvenient reality (that I must continually reinstall my distribution as a Fedora user, and I'm tired of having to migrate user data, where even residual /home directories leave rot). -- 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 Wed, Oct 14, 2009 at 06:31:03PM +0200, Felix Kaechele wrote: From the opposite POV: Why should we make peoples' lives harder getting the tools they need? Example: Somebody without the DAHDI Kernel Modules would probably not try to use the DAHDI Tools since he probably won't even know what it's good for. However It makes things easier for the people who do know what DAHDI is to have tools to use their DAHDI hardware (they compiled/got the Kernel modules for) just a yum install away. IMHO having both in RPMFusion with a proper dependency is the easiest way to install it. Having some package with a missing kernel module dependency in Fedora would only make it more complicated for other repositories that provide the kernel module and can therefore provide a package with a unbroken dependency. Regards Till pgpgVpR0UuxiG.pgp Description: PGP signature -- 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 Wed, Oct 14, 2009 at 18:31:03 +0200, Why should we make peoples' lives harder getting the tools they need? Example: Somebody without the DAHDI Kernel Modules would probably not try to use the DAHDI Tools since he probably won't even know what it's good for. However It makes things easier for the people who do know what DAHDI is to have tools to use their DAHDI hardware (they compiled/got the Kernel modules for) just a yum install away. Not likely. dahdi-linux support is pretty spotty. atrpms can go a long time without having a version for a specific version Fedora. For example there is no rawhide version now and there was a long period without one for F11. There are issues trying to rebuild atrpms src rpms on fedora. Just grabbing atrms-rpm-config doesn't help with recursion issues that Alex doesn't see because of his custom environment. What I had to do for F12 is grab a spec file (that get's updates at the source) that was proposed for rpmfusion (but never got adopted by them) and then use an svn version of dahdi that has a fix for a change in the way the kernel is being built (some compatibility feature that got dropped in 2.6.32). That box has been extra unstable lately, though I don't know if that is do to 3D graphics or dahdi-linux. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, 14 Oct 2009, Jud Craft wrote: On Wed, Oct 14, 2009 at 1:13 PM, Seth Vidal wrote: There's no perfect. we're just going for 'good enough', really. Ah, so package-rollback is shipped as the halfway-effective crutch, but it's so easy to implement we might as well offer it anyway solution. actually it is shipped as an easy win for simple update-is-broken-and-downgrading-is-painless cases which we run into all the time. Your suggestion of having an lvm snapshot is absolutely appropriate for those too - it just requires more thinking ahead of time when the system is being setup which a lot of users are not going to do. Or, the excellent implementation of an incomplete solution. [No offense to the infrastructure design of yum, just stating the obvious here.] There's no complete solution, really. We'd have to know an enormous amount about each update and what data it modifies to completely solve the problem and we just don't have that info and I doubt we could reasonably compile it for EVERY package we maintain. So we implement a reasonable partial solution and deal with the edge cases as they come. On the side, I store all of my user data and documents separate from my own actual home partition, and with every install I just wipe the home, and then re-link my documents and data to it. good choice. That's good planning. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
Le Mer 14 octobre 2009 19:11, Jud Craft a écrit : So if my LVM snapshot and revert entire Fedora installed idea is dismissed as still not perfect, why is just revert one package pushed as a legitimate alternative? Revert one package won't eat the data created while you used the new problem version. That's the problem with full-FS images: they do not distinguish between the different kinds of files. -- Nicolas Mailhot -- 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 Wed, 14 Oct 2009 13:01:40 -0400 (EDT) Seth Vidal skvi...@fedoraproject.org wrote: On Wed, 14 Oct 2009, Ralf Corsepius wrote: 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. I think I agree. This is just like shipping a package with an intentionally missing dependency. We wouldn't allow shipping yum if rpm were missing, right? this sounds the same to me. So, how about some other cases instead of just kmods: - Client apps that are free and acceptable for fedora, but a server app that is not. EXAMPLE: mpd (in rpmfusion) and all the various mpd clients that are all in fedora. - Library app thats free, but only non free things link against it so far. EXAMPLE: libvdpau - Package that is free an interfaces with a non free server's data: EXAMPLE: dbxml-perl - Package that is free, but the kernel part of it's currently not working (although planned to be back and great work is being done on it): EXAMPLE: xen - Package that is free and acceptable for fedora, but requires a non free service to function: EXAMPLE: perl-Net-Amazon-EC2 Where does the black and white line come in here? Or is it shades of grey? kevin signature.asc Description: PGP signature -- 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 Wed, 14 Oct 2009, Kevin Fenzi wrote: On Wed, 14 Oct 2009 13:01:40 -0400 (EDT) Seth Vidal skvi...@fedoraproject.org wrote: On Wed, 14 Oct 2009, Ralf Corsepius wrote: 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. I think I agree. This is just like shipping a package with an intentionally missing dependency. We wouldn't allow shipping yum if rpm were missing, right? this sounds the same to me. So, how about some other cases instead of just kmods: - Client apps that are free and acceptable for fedora, but a server app that is not. EXAMPLE: mpd (in rpmfusion) and all the various mpd clients that are all in fedora. - Library app thats free, but only non free things link against it so far. EXAMPLE: libvdpau - Package that is free an interfaces with a non free server's data: EXAMPLE: dbxml-perl - Package that is free, but the kernel part of it's currently not working (although planned to be back and great work is being done on it): EXAMPLE: xen - Package that is free and acceptable for fedora, but requires a non free service to function: EXAMPLE: perl-Net-Amazon-EC2 Where does the black and white line come in here? Or is it shades of grey? We've allowed pretty much all of the cases where you could communicate over the network to something else. but we're not talking about over-the-network communication here. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On Wed, 14 Oct 2009, Christopher Aillon wrote: On 10/14/2009 07:56 AM, Mike McGrath wrote: Feodra 11 should not have shipped with a beta but the previous stable version. That's really easy for you to say, considering you don't use Thunderbird, and you have no information about the decision making process. The information I used to make the decision was: * The upstream release date was going to be within a week of F11's release date, from a normally reliable source * 3.0 had many desirable improvements to performance * 2.0 would be EOL'd by upstream soon * Thunderbird users tend to be in the want upgrade now camp * Changing from 2.0 - 3.0 after F11 was released is not something I wanted to do * Tb3 beta would affect a smaller portion of Fedora users anyway since Thunderbird is _not_ the default mail client. * Given initial testing by my team, and tracking upstream feedback, it worked well enough and there were no major regressions over 2.0. Given the situation and circumstances, with the information I had available, I would make the same decision again. I would have made the same decision as you, that doesn't mean it wasn't a mistake. We have no policies or procedures in place to guide you, me or anyone else otherwise. As such, we run into these issues, cause pain for the users, etc, etc. -Mike -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On Wed, 14 Oct 2009, Mike McGrath wrote: On Wed, 14 Oct 2009, Christopher Aillon wrote: On 10/14/2009 07:56 AM, Mike McGrath wrote: Feodra 11 should not have shipped with a beta but the previous stable version. That's really easy for you to say, considering you don't use Thunderbird, and you have no information about the decision making process. The information I used to make the decision was: * The upstream release date was going to be within a week of F11's release date, from a normally reliable source * 3.0 had many desirable improvements to performance * 2.0 would be EOL'd by upstream soon * Thunderbird users tend to be in the want upgrade now camp * Changing from 2.0 - 3.0 after F11 was released is not something I wanted to do * Tb3 beta would affect a smaller portion of Fedora users anyway since Thunderbird is _not_ the default mail client. * Given initial testing by my team, and tracking upstream feedback, it worked well enough and there were no major regressions over 2.0. Given the situation and circumstances, with the information I had available, I would make the same decision again. I would have made the same decision as you, that doesn't mean it wasn't a mistake. We have no policies or procedures in place to guide you, me or anyone else otherwise. As such, we run into these issues, cause pain for the users, etc, etc. Just an additional note to this, Mozilla themselves are still directing people to download Thunderbird 2. http://www.mozillamessaging.com/en-US/thunderbird/ -Mike -- 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 10:06 AM, Jesse Keating wrote: On Wed, 2009-10-14 at 11:30 -0500, Mike McGrath wrote: On Wed, 14 Oct 2009, Alex Hudson wrote: On 14/10/09 16:47, Seth Vidal wrote: yum downgrade pkgname it works fine for the simple-ish cases. If that works, then gravy. I can't admit to having tried it in the past - although, I'm not really a yum user, I use packagekit, and indeed pk whines at me to turn off the legacy software when I run yum ;) Ideally, for me, this would be something pk can trigger (and maybe give me a way of contributing to the testing karma at the same time - that would rock). Even with downgrade, that's a user action. If the user happens to know about it they'll be ok. I'm more interested in what options a packager has to fix problems like this. -Mike In this specific case, issue a bumped build of thunderbird with the UI settings defaulted to what they were before the change. New code, old UI. Right. The defaults have been tweaked in https://admin.fedoraproject.org/updates/thunderbird-3.0-2.8.b4.fc11 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
Seth Vidal wrote: Seriously: yum downgrade and in F12 - try out things like the history undo options. there are lots of potential nasty situations that can happen but I think the general consensus was 'screw it, let the user sort it out if it breaks, which it often does not' generally, if the app you updated modifies its data format and cannot revert it then the user is SOL - but that's not _THAT_ common and when it does happen it's certainly not yum's fault. If it isn't that common, could yum have added directives to its configuration ( similar to exclude= ) ? This could increase the reliability of yum downgrade in the eyes of those that use it. MySQL and PostgreSQL come to mind. /etc/yum.conf might have nodowngrade=mysql-server postgresql-server in the default file. That's easier than carrying that info in the package or repo files. When additional packages are found to be not downgradable, they can be added to the list. Granted, if there are a lot of packages, that gets unwieldy. Also, it could break a downgrade transaction. -- Charles Dostale -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, 14 Oct 2009, chasd wrote: Seth Vidal wrote: Seriously: yum downgrade and in F12 - try out things like the history undo options. there are lots of potential nasty situations that can happen but I think the general consensus was 'screw it, let the user sort it out if it breaks, which it often does not' generally, if the app you updated modifies its data format and cannot revert it then the user is SOL - but that's not _THAT_ common and when it does happen it's certainly not yum's fault. If it isn't that common, could yum have added directives to its configuration ( similar to exclude= ) ? This could increase the reliability of yum downgrade in the eyes of those that use it. MySQL and PostgreSQL come to mind. /etc/yum.conf might have nodowngrade=mysql-server postgresql-server in the default file. That's easier than carrying that info in the package or repo files. When additional packages are found to be not downgradable, they can be added to the list. Granted, if there are a lot of packages, that gets unwieldy. Also, it could break a downgrade transaction. I have no idea what that would do? just tell the user tough noogies? -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Rationale behind _cmake_skip_rpath choice in /etc/rpm/macros.cmake
I would like to understand why the file macros.cmake as distributed in fedora-10 defines: %_cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=ON I use cmake to build an rpm for a software that builds several libraries and binaries (based on those libraries). In the spec file of my rpm I decided to add some make test into order to check at rpm build time that everything is OK (I agree that this is probably an overkill). Disabling the rpath made all the checks to fail, so I added a: %define _cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=OFF at the beginning of my specfile. But I wonder whether there is any risk in doing so Is there a risk of library interception if someone re-creates a library in the ?? I suppose that the choice was made on purpose, I just want to assess the risk I'm taking in having this approach. Otherwise, I'll just remove the test stuff from the spec file (as I found no other way of doing the tests... Setting LD_LIBRARY_PATH before the make test does not seem to work probably because ctest is careful in setting a clean environment for the tests). The only other solution I can think of would be putting the check in the %install section after having done the make install and testing with a chroot placed on $RPM_BUILD_ROOT (but I fear I need a subshell for the rpm process to proceed after the test) ? Are there any advice on this ? In advance, thank's a lot. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Wed, 2009-10-14 at 11:21 +0200, Michael Schwendt wrote: On Wed, 14 Oct 2009 08:58:45 +0200, Kevin wrote: We really need some stricter enforcement against stuff sitting in testing forever. Rather we need some rules against such mindset. We don't guarantee anything about updates-testing. It's a place where to test potential updates/upgrades. And if a test-update is still without sufficient karma points (either positive or negative) for several weeks, it may stay in updates-testing for a longer time. IMO, that's a good thing. I agree with this, but by the same token, the use suggested by Matej seems against the purpose of updates-testing, as does the original idea in this thread (push some Xorg changes we'd never be happy about putting in stable into it). I also agree with Kevin - maybe we don't need to *disallow* updates sitting in -testing for a long time, but updates sitting there for a long time is an indication of potential issues and it should be flagged for tracking. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Rationale behind _cmake_skip_rpath choice in /etc/rpm/macros.cmake
Theodore Papadopoulo wrote:
I would like to understand why the file macros.cmake as distributed in
fedora-10 defines:
%_cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=ON
or just
%define _cmake_skip_rpath %{nil}
to disable (why it was made a macro, so it's easy to change or override).
It's probably not needed anymore, cmake-based builds should omit rpath by
default, and only use it when necessary, and the hammer above will (I
think) disable that as well.
-- Rex
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates-testing (was: Re: thunderbird upgrade - wtf?)
On Wed, Oct 14, 2009 at 13:55:13 -0500, chasd ch...@silveroaks.com wrote: MySQL and PostgreSQL come to mind. Postgres isn't even updatable. You need to do dumps before doing the upgrade. So downgrades aren't too much worse than upgrades. (Though the new dumps might use new features that will need to get modified to make them readable by old versions.) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On Wed, Oct 14, 2009 at 10:00:07AM -0500, Mike McGrath wrote: On Wed, 14 Oct 2009, Jesse Keating wrote: On Wed, 2009-10-14 at 09:37 -0500, Mike McGrath wrote: On Wed, 14 Oct 2009, Jesse Keating wrote: On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote: The problem isn't GLODA and smart folders, it's that we have no process in place to identify and deal with problems like this before it's too late. Aside from updates-testing you mean, where people can test potential updates and give feedback as to how they work on their systems? Fat lot of good it's doing. -Mike And that's a people problem more than a process problem. If nobody tests it in updates-testing, then how is the maintainer to know that it is problematic? Certainly not solvable with even more repos for testing content... You let me know how three people in Fedora can miss a very subtle Firefox memory leak. How many people would need to use updates testing before the thunderbird indexing problem is caught? How long would it need to stay there? In this case updates-testing theory just does not match reality. The status quo is broken, doing nothing will keep it that way. I think there are many things we can do within Bodhi Fedora Community to better facilitate testing updates. For example, I think we should do a better job of emphasizing the importance of certain updates in the queue, especially security updates with little or no karma. The karma system that I implemented in bodhi hasn't really changed much over the years, and I think it's probably time to reassess some of the default options (eg: +3 for marking as stable is probably way too low for packages like the kernel and thunderbird). Since there are actually a lot of people who provide feedback in bodhi (presently 1448 different people have left comments in bodhi since F10), we obviously are not doing a good enough job of leveraging them. One way to improve our testing strategy would be to keep adding and improving the test cases to the wiki: https://fedoraproject.org/wiki/Category:Test_Cases We could then point people directly to the appropriate steps for testing the application, from within bodhi, fedora community, etc... luke -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On Wed, 2009-10-14 at 20:31 +0530, Rahul Sundaram wrote: On 10/14/2009 08:23 PM, Jesse Keating wrote: And that's a people problem more than a process problem. If nobody tests it in updates-testing, then how is the maintainer to know that it is problematic? Certainly not solvable with even more repos for testing content... 3 people give positive feedback and the update is automatically pushed from updates-testing to updates despite atleast one feedback to the contrary at https://admin.fedoraproject.org/updates/F11/FEDORA-2009-9911?_csrf_token=b77b748e49c5311eb85031331cb2f6474028d615 The UI changes certainly would be visible without any user feedback. The buttons getting removed from the toolbar as well as smart folders were immediately visible within minutes. Anyone with significant amount of email would probably run into the indexing issue soon as well. Note that the update indicates it is a security issue but doesnt explain what the security fix is nor does it indicate what other major changes are there. No notes has been entered to assist the testers. I don't think the onus can be placed entirely on potential testers to provide feedback within a week. That is just finger pointing and doesn't help address such problems or even mitigate it. It's worth looking in more detail at exactly what the feedback was. Here's some of the feedback which was marked positive, i.e. +1: loving the new search stuff Works for me, is it intended behaviour that several buttons including Delete disappear off the main (top) toolbar? without those two bits of feedback - which noted what were later identified as problems with the update, but nevertheless rated it positively - it wouldn't have been pushed. it only ever hit exactly +3, never higher. without those comments, it would have hit a max of +1. so I disagree with the notion that bodhi / updates-testing are useless (fat lot of good), and agree with Jesse that the evidence doesn't support the conclusion that the best fix is to throw more repositories at the problem. I'd agree with Jesse's point that it would've been best for the maintainers to disable the +3-automatic-push for this update, though hindsight is always 20-20. perhaps we (QA / rel-eng) need to give more specific advice about when to use it. My perspective would be that automatic-push should only be used when you're making a small-scale update which fixes one or two specific issues and does not change behaviour in other ways. It should not be used for a big update like this which rolls up many 'fixes' and things which can't strictly be described as fixes, because you're going to get a situation like this where it's hard for a simple +1 / -1 from individual testers to judge the update. We might also look at providing better instructions for people providing feedback on exactly when to use the +1, -1 and 0 options. I'll try and find some time to look at that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On Wed, 14 Oct 2009, Luke Macken wrote: I think there are many things we can do within Bodhi Fedora Community to better facilitate testing updates. For example, I think we should do a better job of emphasizing the importance of certain updates in the queue, especially security updates with little or no karma. Before we go working on the karma system - is it doable to add some fields so we can denote critical path pkgs? If I know there is a place for the data, I can get you quick code to produce the list given any set of pkgs as soon as tomorrow. Hell, It is already written, iirc. It seems like critpath is more important in bodhi than karma, to me. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Status of geronimo
Can someone shed light on the status of geronimo in Fedora? Seems like it hasn't managed to build since F11 - and the F11 build was never pushed. There is a geronimo-spec 1.2 in CVS that doesn't compile (missing dependencies among other things). Apache's site has version 2.1.4. Mind you, I know nothing about geronimo other than a package I'm trying to build depends on geronimo-stax-api. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On Wed, Oct 14, 2009 at 06:53:22PM -0400, Seth Vidal wrote: On Wed, 14 Oct 2009, Luke Macken wrote: I think there are many things we can do within Bodhi Fedora Community to better facilitate testing updates. For example, I think we should do a better job of emphasizing the importance of certain updates in the queue, especially security updates with little or no karma. Before we go working on the karma system - is it doable to add some fields so we can denote critical path pkgs? If I know there is a place for the data, I can get you quick code to produce the list given any set of pkgs as soon as tomorrow. Hell, It is already written, iirc. It seems like critpath is more important in bodhi than karma, to me. Yeah, I agree critpath is more important at the moment. So we have a few options for where to throw this data. - We could add a new field to the bodhi Package SQLObject model This will entail DB schema changes. I've never altered bodhi's model below our DB before, but I think we could maybe just run an ALTER TABLE, and be all set. I'll have to test this first. bodhi v2.0 will use SQLAlchemy, so we'll have much better schema migration tools to use. - The quick and dirty solution would be to generate the critpath list and stuff it in bodhi's config file (like we do with packages that require a reboot). Or, if it's quick to generate, we could do it on startup. I'm not sure how large the list is so we'll have to see. - We could also have a flag in the pkgdb for critpath packages, which would be simple to query. It feels like the pkgdb should know about critpath packages. There are probably some other ways too, but once I see the code to generate I'm sure I can figure out how to get bodhi to use it. luke -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
bodhi changes
On Wed, Oct 14, 2009 at 07:33:45PM -0400, Luke Macken wrote: Before we go working on the karma system - is it doable to add some fields so we can denote critical path pkgs? If I know there is a place for the data, I can get you quick code to produce the list given any set of pkgs as soon as tomorrow. Hell, It is already written, iirc. It seems like critpath is more important in bodhi than karma, to me. Yeah, I agree critpath is more important at the moment. So we have a few options for where to throw this data. - We could add a new field to the bodhi Package SQLObject model This will entail DB schema changes. I've never altered bodhi's model below our DB before, but I think we could maybe just run an ALTER TABLE, and be all set. I'll have to test this first. bodhi v2.0 will use SQLAlchemy, so we'll have much better schema migration tools to use. - The quick and dirty solution would be to generate the critpath list and stuff it in bodhi's config file (like we do with packages that require a reboot). Or, if it's quick to generate, we could do it on startup. I'm not sure how large the list is so we'll have to see. - We could also have a flag in the pkgdb for critpath packages, which would be simple to query. It feels like the pkgdb should know about critpath packages. There are probably some other ways too, but once I see the code to generate I'm sure I can figure out how to get bodhi to use it. I think this would be really beneficial to No-Frozen-Rawhide as well, so that we could make Bodhi wait for a rel-eng/QA signoff on critpath packages before allowing them to be promoted during the devel cycle. Extending that to updates-testing - updates transition in released versions would be bonus as well. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
Mike McGrath said the following on 10/14/2009 11:26 AM Pacific Time: On Wed, 14 Oct 2009, Mike McGrath wrote: On Wed, 14 Oct 2009, Christopher Aillon wrote: On 10/14/2009 07:56 AM, Mike McGrath wrote: Feodra 11 should not have shipped with a beta but the previous stable version. That's really easy for you to say, considering you don't use Thunderbird, and you have no information about the decision making process. The information I used to make the decision was: * The upstream release date was going to be within a week of F11's release date, from a normally reliable source * 3.0 had many desirable improvements to performance * 2.0 would be EOL'd by upstream soon * Thunderbird users tend to be in the want upgrade now camp * Changing from 2.0 - 3.0 after F11 was released is not something I wanted to do * Tb3 beta would affect a smaller portion of Fedora users anyway since Thunderbird is _not_ the default mail client. * Given initial testing by my team, and tracking upstream feedback, it worked well enough and there were no major regressions over 2.0. Given the situation and circumstances, with the information I had available, I would make the same decision again. I would have made the same decision as you, that doesn't mean it wasn't a mistake. We have no policies or procedures in place to guide you, me or anyone else otherwise. As such, we run into these issues, cause pain for the users, etc, etc. Just an additional note to this, Mozilla themselves are still directing people to download Thunderbird 2. http://www.mozillamessaging.com/en-US/thunderbird/ -Mike This has been my work around since the addons I really depend on don't work on TB3. I installed TB2 from the tarball and turned on automatic updates. I also added an exclude to /etc/yum.conf for thunderbird. John -- 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 Wed, Oct 14, 2009 at 12:25:00PM -0500, Bruno Wolff III wrote: On Wed, Oct 14, 2009 at 18:31:03 +0200, Why should we make peoples' lives harder getting the tools they need? Example: Somebody without the DAHDI Kernel Modules would probably not try to use the DAHDI Tools since he probably won't even know what it's good for. However It makes things easier for the people who do know what DAHDI is to have tools to use their DAHDI hardware (they compiled/got the Kernel modules for) just a yum install away. Not likely. dahdi-linux support is pretty spotty. atrpms can go a long time without having a version for a specific version Fedora. For example there is no rawhide version now and there was a long period without one for F11. Rawhide support has quite low demand and the kernel changes daily or more frequently in early rawhide, so any kernel bound support is outdated before it is released. We usually fire up the rawhide support about a month or so before the targeted release date (which means about now). I don't think that F11 was w/o dahdi-linux kmdls for any long period. There are issues trying to rebuild atrpms src rpms on fedora. Just grabbing atrms-rpm-config doesn't help with recursion issues that Alex doesn't see because of his custom environment. Who's Alex, and why doesn't atrms-rpm-config work? You may see `recursion' warnings due to rpm's limitation of macros depth (which has nothing to do with recursion), which is at 16, but in reality means about 3-4 nested macros. What I had to do for F12 is grab a spec file (that get's updates at the source) that was proposed for rpmfusion (but never got adopted by them) and then use an svn version of dahdi that has a fix for a change in the way the kernel is being built (some compatibility feature that got dropped in 2.6.32). That box has been extra unstable lately, though I don't know if that is do to 3D graphics or dahdi-linux. Have you tried the common src.rpm at ATrpms? Maybe you should check out ATrpms in a couple of days and see whether there is dahdi support for F12 there. -- Axel.Thimm at ATrpms.net pgpRRJRTbNBbo.pgp Description: PGP signature -- 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 Thu, Oct 15, 2009 at 08:09:19 +0300, Axel Thimm axel.th...@atrpms.net wrote: On Wed, Oct 14, 2009 at 12:25:00PM -0500, Bruno Wolff III wrote: On Wed, Oct 14, 2009 at 18:31:03 +0200, Why should we make peoples' lives harder getting the tools they need? Example: Somebody without the DAHDI Kernel Modules would probably not try to use the DAHDI Tools since he probably won't even know what it's good for. However It makes things easier for the people who do know what DAHDI is to have tools to use their DAHDI hardware (they compiled/got the Kernel modules for) just a yum install away. Not likely. dahdi-linux support is pretty spotty. atrpms can go a long time without having a version for a specific version Fedora. For example there is no rawhide version now and there was a long period without one for F11. Rawhide support has quite low demand and the kernel changes daily or more frequently in early rawhide, so any kernel bound support is outdated before it is released. We usually fire up the rawhide support Yes, but usually just rebuilding from the source rpm would work if I had an environment where I could do that. I am doing that now with the version based on a spec file from messinet.com. about a month or so before the targeted release date (which means about now). I don't think that F11 was w/o dahdi-linux kmdls for any long period. Possibly it was during the F11 rawhide period that I looked and I didn't check back for a while after the release. Unfortunately my tdm card is in my only machine at home that has 3d graphics at all working using the drivers in Fedora. And I needed to go to rawhide to get that working more than I needed to having tdm card working (though in the end I got both). There are issues trying to rebuild atrpms src rpms on fedora. Just grabbing atrms-rpm-config doesn't help with recursion issues that Alex doesn't see because of his custom environment. Who's Alex, and why doesn't atrms-rpm-config work? You may see Sorry about misspelling your name. `recursion' warnings due to rpm's limitation of macros depth (which has nothing to do with recursion), which is at 16, but in reality means about 3-4 nested macros. Yes. But I didn't see any clear instructions for how to work around it. It seems that for some people using --define can work around the problem if you know what to define. There was also a comment that you don't see the problem because of something in your environment but I didn't see any directions on how to set up a similar environment. What I had to do for F12 is grab a spec file (that get's updates at the source) that was proposed for rpmfusion (but never got adopted by them) and then use an svn version of dahdi that has a fix for a change in the way the kernel is being built (some compatibility feature that got dropped in 2.6.32). That box has been extra unstable lately, though I don't know if that is do to 3D graphics or dahdi-linux. Have you tried the common src.rpm at ATrpms? Maybe you should check out ATrpms in a couple of days and see whether there is dahdi support for F12 there. I tried using the dahdi-linux src rpm while having atrpms-rpm-config installed, but hit the recursion problem and got stuck there. I would still have had the problem with the last released dahdi not working with 2.6.31 kernels. But fixing that would have taken the same route as with the path I ended up taking. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
