Re: Adventurous yet Safety-Minded
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2010 08:26 PM, Steven I Usdansky wrote: > If there's a magic solution that will satisfy the vast majority > of Fedora users, I have absolutely no clue as to what it might be. Please read: http://nixos.org/nix/ Esp. "Atomic upgrades and rollbacks" - -- Alexander Kahl GNU/Linux Software Developer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkuYmY0ACgkQVTRddCFHw12vggCg1mfBxF5LB9Dg7zB6zl6XJlXZ GqMAn3DyYhZ4TIzsnUcmTPOIONlMwa51 =lngo -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 2010/03/10 22:41 (GMT-0600) Eric Sandeen composed: > Felix Miata wrote: >> Sounds to me like the HD manufacturers want to make 512 go the way of PATA, >> accelerating obsolescence to drive up profitability of the whole computer >> hardware industry. People shouldn't have to buy whole new systems for want of >> replacing a dead 20GiB 512 byte sector HD. > I really don't understand why this bothers you so much; there is new hardware > on the way, and Linux works with it. If you want to keep your 20G drives > until > they die, nobody is stopping you. These things will likely coexist for a > long time. > Nobody is forcing your hand. Have you tried to buy a replacement PATA disk lately, particularly one no larger than the 2^28 ATA-5 addressing limit? Buying a replacement 20G HD, or one compatible with it even if 10X or more the storage size actually needed, has become a difficult task, particularly if a new product and a warranty longer than 90 days is desired. The bother is that it looks like HD makers will have their way with 512 as they have with PATA, forcing a lot of otherwise useful hardware into landfills prematurely. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Potential pkgdb-0.5.x release on staging
After a round of bug reports and bug fixing I have a new pkgdb up in the staging environment for testing. I do not know of any problems with this version at the moment so I'd appreciate people who use the pkgdb to change acls frequently or query it for data give it a try and see that everything is working for them. If there's no reports of problems I'll be pushing this to production soon. If I'm available for part of the weekend I'll push it Friday. If not, I'll push it out on Monday. A new python-fedora based on 0.3.16.90 which works with the new pkgdb will be built and pushed into updates-testing at that time as well:: http://toshio.fedorapeople.org/packages/python-fedora/ -Toshio pgpmBbFyacyyh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
Felix Miata wrote: > On 2010/03/10 19:11 (GMT-0800) John Reiser composed: > >>> MultiGHz, Multicore CPUs consume magnitudes more power than HDs. > >> Not always. A typical 3.5" harddrive consumes about (max): >> 0.65A * 5V = 3.25W >> 0.50A * 12V = 6.00W >> which totals 9.25 Watts, and less when not transferring data. >> I am composing this message on a system with a 2.5GHz, two-core >> processor that consumes 45 Watts maximum, and less when "idle". >> So in this case the ratio is closer to 5:1, not 10:1. > > RAM, GPUs & fans are also nonzero power consumers, so any reduction in HD > power consumption in typical desktops and laptops is minimal in the grand > scheme. For a data center, this matters. Maybe not for your laptop, but not all the world's storage is on small systems. > OTOH, loss of backward compatibility means accelerated additions to landfills > of otherwise perfectly useful hardware. linux will be backward compatible with 512-sector drives just fine; nothing will stop that ... > It should be fine to have an option for larger sector sizes, but it shouldn't > mean extinction in the foreseeable future of a happily working standard for > those who only want to replace a HD when the HD dies, and not commit whole > systems to landfills for want of a generic component. it doesn't mean extinction, your old drives will continue to work just fine, and if you -have- to buy a 4k sector drive, linux is ready for you. (for that matter, I expect 512 sector drives will be available for a good long time, too). > Sounds to me like the HD manufacturers want to make 512 go the way of PATA, > accelerating obsolescence to drive up profitability of the whole computer > hardware industry. People shouldn't have to buy whole new systems for want of > replacing a dead 20GiB 512 byte sector HD. I really don't understand why this bothers you so much; there is new hardware on the way, and Linux works with it. If you want to keep your 20G drives until they die, nobody is stopping you. These things will likely coexist for a long time. Nobody is forcing your hand. I suppose this now-off-topic discussion has gone on long enough, though, so this'll be my last word on the subject here. -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 2010/03/10 19:11 (GMT-0800) John Reiser composed: >> MultiGHz, Multicore CPUs consume magnitudes more power than HDs. > Not always. A typical 3.5" harddrive consumes about (max): > 0.65A * 5V = 3.25W > 0.50A * 12V = 6.00W > which totals 9.25 Watts, and less when not transferring data. > I am composing this message on a system with a 2.5GHz, two-core > processor that consumes 45 Watts maximum, and less when "idle". > So in this case the ratio is closer to 5:1, not 10:1. RAM, GPUs & fans are also nonzero power consumers, so any reduction in HD power consumption in typical desktops and laptops is minimal in the grand scheme. OTOH, loss of backward compatibility means accelerated additions to landfills of otherwise perfectly useful hardware. It should be fine to have an option for larger sector sizes, but it shouldn't mean extinction in the foreseeable future of a happily working standard for those who only want to replace a HD when the HD dies, and not commit whole systems to landfills for want of a generic component. Sounds to me like the HD manufacturers want to make 512 go the way of PATA, accelerating obsolescence to drive up profitability of the whole computer hardware industry. People shouldn't have to buy whole new systems for want of replacing a dead 20GiB 512 byte sector HD. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install fedora-easy-karma by default?
On 03/11/2010 02:14 AM, Matthew Woehlke wrote: > > Can you leave bodhi feedback with an FAS account if you haven't signed a > CLA? (The thing about FAS accounts I am not crazy about is the CLA. What > about using a bugzilla account instead?) > What is the problem you have with the CLA? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
> MultiGHz, Multicore CPUs consume magnitudes more power than HDs. Not always. A typical 3.5" harddrive consumes about (max): 0.65A * 5V = 3.25W 0.50A * 12V = 6.00W which totals 9.25 Watts, and less when not transferring data. I am composing this message on a system with a 2.5GHz, two-core processor that consumes 45 Watts maximum, and less when "idle". So in this case the ratio is closer to 5:1, not 10:1. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 03/10/2010 08:33 PM, Felix Miata wrote: > On 2010/03/10 20:19 (GMT-0500) Ric Wheeler composed: > > >> Peter Jones wrote: >> > >>> Note also that the access time will be slightly faster. >>> > As if an average normal person could tell. > > >> And power consumption will go down as you won't need as many platters :-) >> > Not materially for those whose needs are already down to less than one > platter. MultiGHz, Multicore CPUs consume magnitudes more power than HDs. > I think that you might have a more convincing argument by stating that most people, if we do our job right with the kernel & tools, won't be able to tell the difference. For the storage industry, this is equivalent to things like a process change in the CPU market. Pack more stuff in the same space, reduce power and improve performance. If you personally don't care or don't know enough to notice these improvements, we just need to make sure it is as painless as possible. You probably won't notice the difference. For anyone serious about storage (performance, reliability and power consumption) this will be a positive step. Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 2010/03/10 20:19 (GMT-0500) Ric Wheeler composed: > Peter Jones wrote: >> Note also that the access time will be slightly faster. As if an average normal person could tell. > And power consumption will go down as you won't need as many platters :-) Not materially for those whose needs are already down to less than one platter. MultiGHz, Multicore CPUs consume magnitudes more power than HDs. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 03/10/2010 05:38 PM, Peter Jones wrote: > On 03/10/2010 05:28 PM, Felix Miata wrote: > >> On 2010/03/10 17:09 (GMT-0500) Ric Wheeler composed: >> >> >>> Felix Miata wrote: >>> >> The change is for the benefit of manufacturers, not users. Readiness is only spotty. The discussion has been extensive and ongoing on the linux-ide mailing list. >> >>> Users do benefit as well - more capacity per platter specifically is one >>> obvious win. >>> >> Some users, yes, those with unfathomable storage capacity requirements, >> saving every byte ever encountered without regard for its utility. For those >> with more common needs, the compatibility cost outweighs the purported >> benefits. Most users don't even need 1/10 of .2TiB, much less the 2TiB at >> which larger than 512 byte sectors might start looking sane in cost/benefit >> analysis. >> > Note also that the access time will be slightly faster. > > And power consumption will go down as you won't need as many platters :-) ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: URL error on Fedora 13 Alpha BFO
On Wed, 10 Mar 2010, Mario Chacon wrote: > Hello, > I was trying to install Fedora 13 Alpha using BFO utility and I got an error > during the download of the install.img. I > saw that the url for the install.img is wrong: > > URL that use BFO utility: > http://download.fedoraproject.org/pub > > URL valid: > http://download.fedora.redhat.com/pub/ > > it works with the redhat url. > > Do you know this error? > We do, I'll update it, the first URL actually works, it just seems anaconda is ignoring the redirect (or something more weird is going on) -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 Alpha - Zarafa
* Kevin Kofler [11/03/2010 00:08] : > > OpenChange is an implementation of the M$ Exchange protocols, allowing Free > Software groupware clients to interoperate with M$ Exchange. It's a requirement for Zarafa which is basically a bridge between open protocols (IMAP, POP, Caldav, ...) and Exchange's MAPI protocol. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
I wrote: > * "yum install glibc.i686". Actually, you probably want glibc-devel.i686. But my point still stands, as long as you require only a few 32-bit packages, requesting them explicitly is not the end of the world. So if we were to drop support for that "always install all libs as multilibs" option and require explicitly picking the wanted 32-bit stuff from the 32-bit repo, that shouldn't be a real issue for you. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: QA's Package update policy proposal
Al Dunsmuir wrote: > The update to an older stable release should be made widely available > in that release's updates-testing after the equivalent (not > necessarily identical) fix has been widely tested in the latest stable > release. Uh, no, just no. They should go to updates-testing for both releases at the same time. Anything else: 1. makes things harder for the maintainer, as he/she has to go through all the Bodhi procedures twice, 2. just delays the fix for users for no good reason. I can somewhat understand the argument that they should get separate testing (even though I disagree with it), or even that the stable pushes should be staged (even though I also disagree with that), but I really don't see what it hurts to have the update available in updates-testing right away. Testing is what updates-testing is for. > This minimizes the risk that due to a different execution environment, > build environment, configuration or whatever the seemingly equivalent > fix does not work but causes a regression. You may start at the same > place in the older stable release, but may end up down and entirely > different rabbit hole. Is this really such a common issue that it makes it worth delaying all updates, including bugfixes, while waiting for testing that may never arrive (because those folks who like testing things tend to run the current stuff)? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Matthew Woehlke wrote: > Hmm, maybe then you are thinking of things that are far less > stand-alone. The only "run-time environment" we care about is that the > program can be executed (so, kernel can load it, glibc.i?86 exists, > etc.). We tend to have very few if any dependencies beyond libc (and > even then, beyond libc/libm/libpthread, we usually provide our own). Then all you really need is: * the 32-bit repository enabled, * yum.conf set up not to install matching i686 packages for all x86_64 packages (which would cause file conflicts when using the full 32-bit repository), but only those explicitly requested or required by dependencies (This has now been the default for several Fedora releases anyway.), * "yum install glibc.i686". You don't actually need multilibbed x86_64 repositories. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expect more positive bodhi karma / check karma automatism
On Wed, Mar 10, 2010 at 4:27 PM, Till Maas wrote: > On Wed, Mar 10, 2010 at 09:34:15AM -0700, Stephen John Smoogen wrote: > >> 1) Comments could allow for multi-line code. I tried to paste stuff in >> and well skipped a couple of packages from the paste :) > > Do you have any wish about how this should behave? I was thinking that > e.g. a comment like " until a comment that's only EOF will be used. EOF can be an arbitrary > string. That works for me. >> 2) I found so many packages I didn't know were on my system so had no >> idea what they were. >> A) is the package linked to things I use daily? [can this be determined.] > > I don't know how to determine this except to scan your .bash_history and > use rpm -qf to find matches packages. Yeah.. this would require a more massive database than I think is in the scope of packages. This sort of big brother would basically track what is run, by what and when. It would then present stuff so that a user could see what they are using the most. However, in some cases, I would just like to know: poppler-glib: used by evince, gimp. That way I can say.. oh I used evince since the update.. and its working so I have not had a problem. >> B) is the package been used by something so I can see its usage by >> other daemons. > > So you would like to have a list of all packages that are depending on > this directly or indirectly? For a future release I was thinking about > to use a more interactive shell that allows to also perform some > additional query commands. Maybe this could be one of them. > The biggest query command I would like at the moment is something like: fedora-easy-karma --list # lists packages to be voted on. fedora-easy-karma --list-new # list pacakges I haven't voted on already. I removed a couple hundred packages from my system today because I am not suing them and even just hitting return to go past them was taking a long time. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Beta Blocker Meeting 2010-03-12 @ 16:00 UTC (11 AM EST)
When: Friday, 2010-03-12 @ 16:00 UTC (11 AM EST)
Where: #fedora-bugzappers on irc.freenode.net
It's that time again: blocker bug review meeting time! Tomorrow is the
first blocker bug review meeting for Fedora 13 Beta.
Here are the current bugs listed as blocking the Beta release. We'll be
discussing all of these:
568106 NEW grubUnable to enter grub menu in F-13-Alpha
with console=ttyS0
565848 ASSIGNEDanacondaLVMError: lvactivate failed for
lv_root: Skipping volume group vg_test1148
559290 ASSIGNEDlvm2LVMError: lvcreate failed for
VolGroup/lv_root - 512M insufficient for Fedora install
569377 ASSIGNEDanacondaCDROM install unable to eject disc -
storage: error ejecting cdrom sr0: (5, 'Input/output error')
533746 ASSIGNEDkernel Fedora 12 livecd freezes at udev on
Acer Aspire One D250
568367 ASSIGNEDanacondaMounting disks read-only in rescue mode
presents error
567346 ASSIGNEDgnome-packagekit gpk-update-viewer does not display
changelogs nor updates packages
565879 MODIFIEDanacondaOSError: [Errno 2] No such file or
directory: '/mnt/sysimage/None'
568015 MODIFIEDanacondaBoth DMRAID and backing disks show up
as selectable in step cleardisksel
568334 MODIFIEDanacondaanaconda 13.31 exception report -
KeyError: 'cleardiskssel'
Have an issue you'd like to propose as an F13 release blocker? Please
consider the following criteria when escalating an issue:
https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria
The aim for the Release Criteria for F13 is for our criteria to match up
with our 'gut feelings', so if you see an issue that you think should be
a blocker but doesn't meet the criteria, please add it as a blocker and
mention at the meeting that the criteria don't cover it. Thanks!
To promote a bug for consideration as a blocker, simply mark it as
blocking the bug 'F13Beta'. You can also already mark bugs as blocking
the Final release, if appropriate, by using 'F13Blocker'.
Hope to see everyone at the meeting!
For the record, the command used to generate the list of bugs is:
bugzilla query --blocked=538274
--bug_status=NEW,ASSIGNED,NEEDINFO,ON_DEV,MODIFIED,POST,ON_QA,FAILS_QA,PASSES_QA,REOPENED,VERIFIED,RELEASE_PENDING
--outputformat="%{bug_id} %{bug_status} %{component} %{summary}"
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Wed, 2010-03-10 at 18:16 -0500, Al Dunsmuir wrote: > On Wednesday, March 10, 2010, 5:59:20 PM, Adam Williamson wrote: > >>On Wed, 2010-03-10 at 22:44 +, Ewan Mac Mahon wrote: > >> The LHC is an interesting analogy; it certainly has problems that can be > >> picked out with 20:20 hindsight, but there was no way anyone could have > >> changed the processes in advance that would prevented them coming up in > >> the first place. > > > This is certainly true. However, if they'd decided to build the whole > > thing based on their first calculations, measuring once and cutting > > once, and without doing any checking to make sure they were building > > everything in a straight line, it probably would've gone even worse =) > > > you're right it was a bad example to pick, though, without further > > explanation. > > -- > > Adam Williamson > > Um... Adam, on that straight line thing. Last time I checked, they > were trying to make a very large perfect circle. **GRIN** > > Some days Murphy is the only winner, no matter what we do! Man, but you guys like to pick nits. =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: URL error on Fedora 13 Alpha BFO
Hello, I was trying to install Fedora 13 Alpha using BFO utility and I got an error during the download of the install.img. I saw that the url for the install.img is wrong: URL that use BFO utility: http://download.fedoraproject.org/pub URL valid: http://download.fedora.redhat.com/pub/ it works with the redhat url. Do you know this error? Thank you salu2... masch... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 Alpha - Zarafa
Dne 10.3.2010 16:35, Tom "spot" Callaway napsal(a): > On 03/09/2010 05:23 PM, nodata wrote: >> Does Zimbra still ship as a blob of specific versions of lots of open >> source software, of which the specific versions cannot be changed? > > Also, the last time I looked, it had a bundled copy of the Sun JDK (not > the open sourced one either). I think that goes without saying that if somebody wants to package Java monster like Zimbra would need to cut out tens of megabytes (at least) junk which has no place in a sane tarball. No need to emphasize that. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC He uses statistics as a drunken man uses lamp-posts... for support, rather than illumination. -- Andrew Lang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expect more positive bodhi karma / check karma automatism
On Wed, Mar 10, 2010 at 09:34:15AM -0700, Stephen John Smoogen wrote: > 1) Comments could allow for multi-line code. I tried to paste stuff in > and well skipped a couple of packages from the paste :) Do you have any wish about how this should behave? I was thinking that e.g. a comment like " 2) I found so many packages I didn't know were on my system so had no > idea what they were. >A) is the package linked to things I use daily? [can this be determined.] I don't know how to determine this except to scan your .bash_history and use rpm -qf to find matches packages. >B) is the package been used by something so I can see its usage by > other daemons. So you would like to have a list of all packages that are depending on this directly or indirectly? For a future release I was thinking about to use a more interactive shell that allows to also perform some additional query commands. Maybe this could be one of them. Regards Till pgpDtUfkKyZZ9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Wednesday, March 10, 2010, 5:59:20 PM, Adam Williamson wrote: >>On Wed, 2010-03-10 at 22:44 +, Ewan Mac Mahon wrote: >> The LHC is an interesting analogy; it certainly has problems that can be >> picked out with 20:20 hindsight, but there was no way anyone could have >> changed the processes in advance that would prevented them coming up in >> the first place. > This is certainly true. However, if they'd decided to build the whole > thing based on their first calculations, measuring once and cutting > once, and without doing any checking to make sure they were building > everything in a straight line, it probably would've gone even worse =) > you're right it was a bad example to pick, though, without further > explanation. > -- > Adam Williamson Um... Adam, on that straight line thing. Last time I checked, they were trying to make a very large perfect circle. **GRIN** Some days Murphy is the only winner, no matter what we do! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Webcam Test Day tomorrow (Thursday 2010-03-11)
This Thursday, 2010-03-11, is webcam Test Day [1]. It's really pretty simple: if you have a webcam we want you to boot up a recent Fedora and check if it works. There's detailed instructions on the Wiki page but that's really what it boils down to - fire up your webcam, run Cheese or something like it, and make sure it all works well. If not, let us know about it! As always, the Test Day runs all Thursday in #fedora-test-day on Freenode IRC. [1] https://fedoraproject.org/wiki/Test_Day:2010-03-11_webcams -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Wed, 2010-03-10 at 22:44 +, Ewan Mac Mahon wrote: > On Wed, Mar 10, 2010 at 01:21:45PM -0800, Adam Williamson wrote: > > On Wed, 2010-03-10 at 23:11 +0200, Gilboa Davara wrote: > > > > > Either we (package maintainers) are qualified to make sane decisions > > > about our package or we are not. I don't really see a middle ground > > > here. > > > > Being qualified to do something does not mean that one always does it > > perfectly. Almost everyone's qualified to drive, yet road traffic > > accidents happen _all the time_. The people who built the LHC were no > > doubt qualified to do yet, yet it turns out to be a bit broken. > > The LHC is an interesting analogy; it certainly has problems that can be > picked out with 20:20 hindsight, but there was no way anyone could have > changed the processes in advance that would prevented them coming up in > the first place. This is certainly true. However, if they'd decided to build the whole thing based on their first calculations, measuring once and cutting once, and without doing any checking to make sure they were building everything in a straight line, it probably would've gone even worse =) you're right it was a bad example to pick, though, without further explanation. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: QA's Package update policy proposal
On Tuesday, March 9, 2010, 8:09:40 PM, Kevin Kofler wrote: >> Jesse Keating wrote: >> On Tue, 2010-03-09 at 16:08 -0800, Josh Stone wrote: >>> It seems to cast doubt on the value of karma -- just because something >>> gets lots of positive karma on N doesn't mean that N-1 is ok. Then >>> again, the same concern is present in any grouped update if the voters >>> haven't tried *all* of the packages mentioned. >> >> Even if you put an update for N and N-1 in the same form, once you >> submit the request it splits it into two requests, one per Fedora >> release. This means you'd have one set of karma per Fedora release. > Indeed, and I'd argue that this is a problem, not a feature. If an update is > confirmed to fix an issue in the current stable release and the previous > stable release is affected by the exact same issue, I don't see a good > reason not to push the update with identical changes to the previous stable > release as well. Not doing it would result in the previous stable release > not getting bugfixes in a timely manner, if at all, anymore, as it has a lot > fewer testers. > Kevin Kofler Just to be clear, I am in the "adventurous user" camp that would prefer to have the bug fix retrofitted to the older release. I would, however, qualify that as follows: The update to an older stable release should be made widely available in that release's updates-testing after the equivalent (not necessarily identical) fix has been widely tested in the latest stable release. To me, this means separately developer unit tested, tested by users in updates-testing and then for several weeks of real user use in stable. In parallel with that, separate developer unit testing of the older release should be done, with entry to the older release updates-testing only after the original fix has been proven in the latest stable release. This minimizes the risk that due to a different execution environment, build environment, configuration or whatever the seemingly equivalent fix does not work but causes a regression. You may start at the same place in the older stable release, but may end up down and entirely different rabbit hole. Firing off the "same" fix for multiple targets other than rawhide and the latest release makes me nervous. So to summarize, fixes in multiple releases yes, but with separate schedules for build and testing. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Wed, Mar 10, 2010 at 01:21:45PM -0800, Adam Williamson wrote: > On Wed, 2010-03-10 at 23:11 +0200, Gilboa Davara wrote: > > > Either we (package maintainers) are qualified to make sane decisions > > about our package or we are not. I don't really see a middle ground > > here. > > Being qualified to do something does not mean that one always does it > perfectly. Almost everyone's qualified to drive, yet road traffic > accidents happen _all the time_. The people who built the LHC were no > doubt qualified to do yet, yet it turns out to be a bit broken. The LHC is an interesting analogy; it certainly has problems that can be picked out with 20:20 hindsight, but there was no way anyone could have changed the processes in advance that would prevented them coming up in the first place. When you're trying to build something complicated and push the boundaries of what's been done before then mistakes are inevitable. For all its faults the LHC is absolutely the best thing of its type on the planet. Fear of making mistakes shouldn't stop us building things like the LHC, and it shouldn't stop us building things like Fedora either. We already know how to build things that are safe, boring, and have been done before. Someone's got to build the cool new stuff. Ewan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 03/10/2010 05:28 PM, Felix Miata wrote: > On 2010/03/10 17:09 (GMT-0500) Ric Wheeler composed: > >> Felix Miata wrote: > >>> The change is for the benefit of manufacturers, not users. Readiness is only >>> spotty. The discussion has been extensive and ongoing on the linux-ide >>> mailing list. > >> Users do benefit as well - more capacity per platter specifically is one >> obvious win. > > Some users, yes, those with unfathomable storage capacity requirements, > saving every byte ever encountered without regard for its utility. For those > with more common needs, the compatibility cost outweighs the purported > benefits. Most users don't even need 1/10 of .2TiB, much less the 2TiB at > which larger than 512 byte sectors might start looking sane in cost/benefit > analysis. Note also that the access time will be slightly faster. -- Peter In computing, turning the obvious into the useful is a living definition of the word "frustration" -- Alan Perlis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On Wed, 2010-03-10 at 17:28 -0500, Felix Miata wrote: > On 2010/03/10 17:09 (GMT-0500) Ric Wheeler composed: > > > Felix Miata wrote: > > >> The change is for the benefit of manufacturers, not users. Readiness is > >> only > >> spotty. The discussion has been extensive and ongoing on the linux-ide > >> mailing list. > > > Users do benefit as well - more capacity per platter specifically is one > > obvious win. > > Some users, yes, those with unfathomable storage capacity requirements, > saving every byte ever encountered without regard for its utility. For those > with more common needs, the compatibility cost outweighs the purported > benefits. Most users don't even need 1/10 of .2TiB, much less the 2TiB at > which larger than 512 byte sectors might start looking sane in cost/benefit > analysis. Spoken like someone who has never used usenet. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
Felix Miata wrote: > On 2010/03/10 17:09 (GMT-0500) Ric Wheeler composed: > >> Felix Miata wrote: > >>> The change is for the benefit of manufacturers, not users. Readiness is only >>> spotty. The discussion has been extensive and ongoing on the linux-ide >>> mailing list. > >> Users do benefit as well - more capacity per platter specifically is one >> obvious win. > > Some users, yes, those with unfathomable storage capacity requirements, > saving every byte ever encountered without regard for its utility. For those > with more common needs, the compatibility cost outweighs the purported > benefits. Most users don't even need 1/10 of .2TiB, much less the 2TiB at > which larger than 512 byte sectors might start looking sane in cost/benefit > analysis. And yet they snap up said drives at under $200 a pop I'm not sure this a fight you will win. :) -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 Alpha - Zarafa
Matthew Miller wrote: > although something called OpenChange was added for MS Exchange access in > Fedora 11. OpenChange != Open-Xchange In fact they're completely different: Open-Xchange is groupware software, to some extent a clone of M$ Exchange, but using open protocols. OpenChange is an implementation of the M$ Exchange protocols, allowing Free Software groupware clients to interoperate with M$ Exchange. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: QA's Package update policy proposal
Jesse Keating wrote: > On Tue, 2010-03-09 at 16:08 -0800, Josh Stone wrote: >> It seems to cast doubt on the value of karma -- just because something >> gets lots of positive karma on N doesn't mean that N-1 is ok. Then >> again, the same concern is present in any grouped update if the voters >> haven't tried *all* of the packages mentioned. > > Even if you put an update for N and N-1 in the same form, once you > submit the request it splits it into two requests, one per Fedora > release. This means you'd have one set of karma per Fedora release. Indeed, and I'd argue that this is a problem, not a feature. If an update is confirmed to fix an issue in the current stable release and the previous stable release is affected by the exact same issue, I don't see a good reason not to push the update with identical changes to the previous stable release as well. Not doing it would result in the previous stable release not getting bugfixes in a timely manner, if at all, anymore, as it has a lot fewer testers. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 2010/03/10 17:09 (GMT-0500) Ric Wheeler composed: > Felix Miata wrote: >> The change is for the benefit of manufacturers, not users. Readiness is only >> spotty. The discussion has been extensive and ongoing on the linux-ide >> mailing list. > Users do benefit as well - more capacity per platter specifically is one > obvious win. Some users, yes, those with unfathomable storage capacity requirements, saving every byte ever encountered without regard for its utility. For those with more common needs, the compatibility cost outweighs the purported benefits. Most users don't even need 1/10 of .2TiB, much less the 2TiB at which larger than 512 byte sectors might start looking sane in cost/benefit analysis. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To semi-rolling or not to semi-rolling, that is the question...
Doug Ledford wrote:
> Things like the libata kernel change and KDE 3 to 4 migration are
> intentional events
That's the whole problem. Under our current model, we have places and times
where to perform those intentional disruptive changes, they're called
"releases". In a "consumable" Rawhide, we don't (*), and that's an
unavoidable limit to its consumability. Rawhide is a poor substitute for our
current release model.
(*) Sure, we can add "flag days" as you propose, but that's too often for
users (at least 6 times as often, anything less frequent would make
development basically impossible) and there's also no way for a user to say
"I'm not ready for a flag day now, I'll just skip one or move at some point
between this flag day and the next one" and still get updates, unlike now
where they can skip a release and still get updates all along.
> and all that's needed to make the transition smooth is to coordinate the
> release of a seamless upgrade package set.
No. The problem with the above changes is not the consistency of the update
set, it's that they do major changes to the user's machine, such as feature
regressions, new bugs, requiring manual adjustment of settings (e.g.
s/hda/sda/ in some config files) etc.
Let's call the old state (e.g. KDE 3) S and the new state (e.g. KDE 4) S'.
The big issue here is not the consistency, quality or whatever attributes of
the new state S', but the state transition from S to S'. Even if we fix all
the inherent problems of S', that still doesn't make it a valid state for S
to transition into.
> You make it sound like these things are impossible when nothing could be
> further from the truth.
I only make those things sound impossible which actually ARE impossible. See
above.
No amount of testing, coordination etc. is going to make it acceptable to
e.g. dump KDE 4 on KDE 3 users overnight. If my only 2 alternatives are to
get that kind of updates ("consumable" Rawhide) or to get no new features
(and quite possibly even only limited bugfixes) at all (conservative
updates), there is no alternative suitable for me. Nor for the dozens of
users who voted "adventurous" in Adam Williamson's poll. (No matter whether
you consider that sample representative or not, you can't argue away the
over a hundred users who voted that way in the sample itself! Claiming they
were all misled by the question is also not really credible.)
> And automated QA *will* catch many more bugs than it misses (speaking
> from the mouth of experience knowing all the automated QA checks my rhel
> packages must pass prior to each update), and there was never an
> assumption that it would catch *all* issues. In fact the suggestion
> that automated QA would need to catch *all* issues before the proposal
> meets your approval makes it very apparent how disingenuous your stance
> on this proposal is.
Jesse is proposing to have automated QA as the ONLY filter for packages to
go to a supposedly "consumable" repository. So I replied that this cannot
work because it cannot catch all issues. At the very least, the maintainer
must be able to manually flag things as not being suitable for the
"consumable" repository just yet. And to have something consumable enough to
replace (at least for a class of users) releases, something like updates-
testing is needed. (No, I don't think ALL updates need to go through
updates-testing. There are several cases where I think pushing directly to
stable is the correct solution. But that doesn't mean that updates-testing
is useless nor that users who want non-conservative updates want untested
updates!)
> FACT: the semi-rolling update model you so love today is not foolproof
> and does not keep users from experiencing periodic, occasional breakage
> (see KDE update thread).
> FACT: you are strongly in support of the current semi-rolling model that
> you practice today (see multiple threads).
> FACT: you have purported that even with things occasionally breaking as
> they did on the recent KDE update, that these things are impossible to
> prevent 100% and that the system is working "as designed" (see KDE
> thread).
I still think we did the right thing pushing KDE 4.4.0. It fixed a lot more
issues than it caused. (Upstream counts thousands of fixed bugs.) And for
many people it just works. There's that slight annoyance in the form of a
message box when starting up kdepim apps which can be easily worked around
(either just click it away, or enable Nepomuk and have it gone for good),
and which should be solved for good with the kde-settings update we're
pushing (Nepomuk will be enabled by default), but other than that, I haven't
seen any widespread issues. It's NOT an update like KDE 3 to 4 which would
be insane to push to a stable release.
I'll also point out that 4.4.0 has been through a lot of testing, we've had
prereleases in Rawhide and kde-redhat unstable, then 4.4.0 itself was also
tested for more than 2 weeks before we dec
Re: Proposed udpates policy change
On Wed, Mar 10, 2010 at 9:11 PM, Gilboa Davara wrote: >> If Fesco is aiming at getting rid of all the pesky packagers maintaining low >> profile packages: You're well on your way. > > I usually stay away from mega-threads, but well put! > > I doubt that even major bug fixes in any of my (small) packages, ever > got more than 1-2 karma votes. Many got zero - not even a vote by the > original bug report owner! > > Why am I getting punished because some package didn't get enough testing > (due to the low visibility of update-testing?) before it was pushed into > -updates and caused breakage? > > Either we (package maintainers) are qualified to make sane decisions > about our package or we are not. I don't really see a middle ground > here. I thought I would add a few thoughts to this now long running thread. Firstly I have been a long standing - since Fedora Core 1 - user of Fedora, and in general Fedora Linux has served me well through many generations of new installs, across not only my own machines but also those of relatives/friends whom I have been trusted to convert to sole Linux use, up till now very successfully. There have been large changes in recent times (KDE 3.5->4, major changes to graphics drivers including open source Radeon/nouveau, major boot process updates, KMS, pulseaudio etc etc). We have survived all of those largely unscathed. I would hope that the machines that I run on behalf of other users will continue to serve them well through yum updates whilst in normal production service. I am lucky that I can run my main machines on a released and current version of Fedora that I expect will not fail in a catastrophic way after normal updates - but I do have available other non-critical machines on which I can run alpha or beta ( or even rawhide occasionally) versions, or run current releases but be prepared to take the risk of running unreleased packages from koji before they even hit bodhi, and before they reach testing repos. If these machines suffer in a major way it is not a disaster and I can re-install at worst - but the main production machines remain up and running (until recently that is!) I am lucky since I can usually find what fix is needed and sort it out. However Aunt Bessie can't and relies on people like me to fix their machines when their email stops working and a message appears on their screen saying something that is incomprehensible to her! Fine if it is only Aunt Bessie that I have to fix - but if Uncle Bob, Grandma Celine, Grandad David, and 25 other assorted friends, cousins and relatives all find their email stops one morning then I am going to be unable to do my dayjob if I spend all my time getting their machines all fixed because an update broke their production systems. At that level I would say that the update that caused that level of failure is no longer acceptable as a released update. I know that we are all human, and that occasionally we will all make a mistake (I do too!) but there is a threshold beyond which a failure is really not acceptable and once crossed there is a chance that users and testers will be alienated and move elsewhere. In that event I think the responsible person(s) should gracefully accept that a threshold has been crossed and learn from flack that ensues, even that has arisen from an upstream change that they were largely unaware would have serious consequences. Remember also that there are users who only have a single machine and if that breaks then it is much harder for him/her to sort out the problem if there is a loss of email functionality and/or loss of dns (remember the dnssec issue) leading to loss of network connectivity since getting the information required to fix it will need access to the net - so critical packages do need to be identified and tested at a more intense level than less critical packages. The kernel is also clearly critical and when dependencies on X and graphics drivers could break machines then that needs special consideration also. In general packages and their maintainers do a good job and we get regular excellent updated packages almost daily - what a service! - users of other alternatives to linux certainly don't get that level of provision or anything like it! I know that there has been a lot of soul searching and a genuine attempt to move forward - let's all keep level headed and try to be constructive rather than destructive in trying to make for a better Fedora. We have support that is truly up to date - let's keep it that way, but also avoid really serious breakage on production releases. -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 03/10/2010 04:30 PM, Felix Miata wrote: > On 2010/03/10 15:22 (GMT-0600) Mike Chambers composed: > > >> Hadn't seen this discussed yet (not really a big hardware geek), and >> just saw an article about this today. Are we (linux as a whole) ready >> for this or getting ready, or already using it? >> > >> http://www.pcmag.com/article2/0,2817,2361156,00.asp >> > The change is for the benefit of manufacturers, not users. Readiness is only > spotty. The discussion has been extensive and ongoing on the linux-ide > mailing list. > Users do benefit as well - more capacity per platter specifically is one obvious win. ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 03/10/2010 04:22 PM, Mike Chambers wrote: > Hadn't seen this discussed yet (not really a big hardware geek), and > just saw an article about this today. Are we (linux as a whole) ready > for this or getting ready, or already using it? And If we bought a new > hd, via sata in my case within past year or newer computer in past year, > are we using the new 4kb sectors now or just able to handle it? > > http://www.pcmag.com/article2/0,2817,2361156,00.asp > We've been working on install and boot support for this for a while now. -- Peter In computing, turning the obvious into the useful is a living definition of the word "frustration" -- Alan Perlis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
Mike Chambers wrote: > Hadn't seen this discussed yet (not really a big hardware geek), and > just saw an article about this today. Are we (linux as a whole) ready > for this or getting ready, or already using it? And If we bought a new > hd, via sata in my case within past year or newer computer in past year, > are we using the new 4kb sectors now or just able to handle it? > > http://www.pcmag.com/article2/0,2817,2361156,00.asp There has been a lot of work upstream on 4k sector support, and in general yes, we are ready. -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 -EGPUDRIVERNOWORKIE
On Mar 10, 2010, at 12:34 PM, Adam Williamson wrote: > This sounds like it's similar to what we saw with the vboxvideo driver, > right? When that failed it didn't fall back to vesa, either... Quite possibly... The issue was that it knew the driver it was looking for and attempted to load it, the driver wasn't found and it didn't try another... I'm not sure (haven't been fully following the thread) if this is the same.. is the xorg video driver unavailable or not properly initializing itself... Just a thought as I was one to report the vboxdriver issue -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Wed, 2010-03-10 at 13:21 -0800, Adam Williamson wrote: > On Wed, 2010-03-10 at 23:11 +0200, Gilboa Davara wrote: > > > Either we (package maintainers) are qualified to make sane decisions > > about our package or we are not. I don't really see a middle ground > > here. > > Being qualified to do something does not mean that one always does it > perfectly. Almost everyone's qualified to drive, yet road traffic > accidents happen _all the time_. The people who built the LHC were no > doubt qualified to do yet, yet it turns out to be a bit broken. You can > pull examples from literally every sphere of human experience. > > People make mistakes - even qualified people, even super-proficient > people who make far fewer mistakes than *most* people. This is why we do > testing. > You're behind the debate, in any case; Matthew's proposal was not > accepted by FESCo at the meeting. No proposal was fully accepted, but > FESCo asked everyone to go and work from Bill Nottingham's proposal > (which, if you look at it, is far more moderate) for further review next > week. But I thought it was important to make the general point. Being > qualified to do something does not mean that you will always do it > perfectly. I just finished reading the fixed proposal (Or actually, I just finished reading the full thread). Thanks for the head's up. - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review (take 2): [Bug 199923] subtree search fails to find items under a db containing special characters
Subject: subtree search fails to find items under a db containing special characters https://bugzilla.redhat.com/show_bug.cgi?id=199923 Files: ldap/servers/plugins/syntaxes/validate.c ldap/servers/slapd/back-ldbm/ldbm_add.c ldap/servers/slapd/dn.c Fix Description: dn.c: Based upon RFC 4514, the following characters in the RDN values need to be escaped: '+', ';', '<','>', and '=' for the intermediate characters '+', ';', '<','>', '=', '#' and ' ' for leading characters '+', ';', '<','>', '=', and ' ' for trailing characters validate.c: If an escaped character followed by another escaped character, e.g., \#\<, the pointer was moved twice skipping '\' before '<' and it makes the validation fail. ldbm_add.c: a local variable addr was not initialized. Thanks to Nathan for his review. I revised dn.c based upon his review comments. Proposed Fix: https://bugzilla.redhat.com/attachment.cgi?id=399189&action=diff https://bugzilla.redhat.com/attachment.cgi?id=399189&action=edit smime.p7s Description: S/MIME Cryptographic Signature -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Hard drive spec change
On Wed, Mar 10, 2010 at 03:22:13PM -0600, Mike Chambers wrote: > Hadn't seen this discussed yet (not really a big hardware geek), and > just saw an article about this today. Are we (linux as a whole) ready > for this or getting ready, or already using it? And If we bought a new > hd, via sata in my case within past year or newer computer in past year, > are we using the new 4kb sectors now or just able to handle it? > > http://www.pcmag.com/article2/0,2817,2361156,00.asp It got some discussion when first 4KiB drives shipped to customers last year. Also, LWN has excellent (as usual) writeup on the matter: http://lwn.net/Articles/377895/ . If you need access to this article, please drop me an email. -- Tomasz Torcz "God, root, what's the difference?" xmpp: zdzich...@chrome.pl "God is more forgiving." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 2010/03/10 15:22 (GMT-0600) Mike Chambers composed: > Hadn't seen this discussed yet (not really a big hardware geek), and > just saw an article about this today. Are we (linux as a whole) ready > for this or getting ready, or already using it? > http://www.pcmag.com/article2/0,2817,2361156,00.asp The change is for the benefit of manufacturers, not users. Readiness is only spotty. The discussion has been extensive and ongoing on the linux-ide mailing list. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Hard drive spec change
Hadn't seen this discussed yet (not really a big hardware geek), and just saw an article about this today. Are we (linux as a whole) ready for this or getting ready, or already using it? And If we bought a new hd, via sata in my case within past year or newer computer in past year, are we using the new 4kb sectors now or just able to handle it? http://www.pcmag.com/article2/0,2817,2361156,00.asp -- Mike Chambers Madisonville, KY "Best lil town on Earth!" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Wed, 2010-03-10 at 23:11 +0200, Gilboa Davara wrote: > Either we (package maintainers) are qualified to make sane decisions > about our package or we are not. I don't really see a middle ground > here. Being qualified to do something does not mean that one always does it perfectly. Almost everyone's qualified to drive, yet road traffic accidents happen _all the time_. The people who built the LHC were no doubt qualified to do yet, yet it turns out to be a bit broken. You can pull examples from literally every sphere of human experience. People make mistakes - even qualified people, even super-proficient people who make far fewer mistakes than *most* people. This is why we do testing. You're behind the debate, in any case; Matthew's proposal was not accepted by FESCo at the meeting. No proposal was fully accepted, but FESCo asked everyone to go and work from Bill Nottingham's proposal (which, if you look at it, is far more moderate) for further review next week. But I thought it was important to make the general point. Being qualified to do something does not mean that you will always do it perfectly. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Mon, 2010-03-08 at 23:21 +0100, Sven Lankes wrote: > On Mon, Mar 08, 2010 at 09:59:29PM +, Matthew Garrett wrote: > > > Before being added to updates, the package must receive a net karma of > > +3 in Bodhi. > > [...] > > > It is the expectation of Fesco that the majority of updates should > > easily be able to garner the necessary karma in a minimal space of time. > > I don't know what to say. > > If Fesco is aiming at getting rid of all the pesky packagers maintaining low > profile packages: You're well on your way. I usually stay away from mega-threads, but well put! I doubt that even major bug fixes in any of my (small) packages, ever got more than 1-2 karma votes. Many got zero - not even a vote by the original bug report owner! Why am I getting punished because some package didn't get enough testing (due to the low visibility of update-testing?) before it was pushed into -updates and caused breakage? Either we (package maintainers) are qualified to make sane decisions about our package or we are not. I don't really see a middle ground here. I wonder if it's not high time to return the distinction between core and extra functionality. - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: QA's Package update policy proposal
On Wed, 2010-03-10 at 11:13 -0600, Bruno Wolff III wrote: > On Tue, Mar 09, 2010 at 15:43:04 -0500, > James Laska wrote: > > > > 1. repoclosure/conflicts - no package update can introduce broken > > deps or conflicts. I'd recommend we apply this to both > > 'updates-testing' and 'updates' (but that's detailed below) > > 2. Package sanity > > * No rpmlint failures > > * Is the Source properly defined > > * License review/examination (if possible) > > * Upstream Source match tarball > > * Package scriptlet syntax checks > > 3. Package must be newer than previously released versions - can't > > ship newer package in N-1. > > 4. Any additional MUST requirements folks would like to see covered > > from the package review requirements? > > File conflicts (assuming that "conflicts" above referred to just conflicts > dependencies). Ah yes. I wasn't specific enough about, but file conflicts is what was meant. Thanks, James signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: QA's Package update policy proposal
On Wed, 2010-03-10 at 13:18 +, Paul Howarth wrote: > On 09/03/10 20:43, James Laska wrote: > > Some basics I'd propose as a starting point for defining acceptance > > criteria include: > > > > 1. repoclosure/conflicts - no package update can introduce broken > > deps or conflicts. I'd recommend we apply this to both > > 'updates-testing' and 'updates' (but that's detailed below) > > 2. Package sanity > >* No rpmlint failures > > rpmlint, in common with many other "lint" tools, reports things that it > thinks *may* be errors that actually are intended. To regard "no rpmlint > failures" as a package sanity check is way over the top I think. > > Comparing the rpmlint output for an updated package with the rpmlint > output for the currently in-repo package would be more useful as that > could identify any new issues, but there should still be a means to > override rpmlint if the maintainer can explain why it's not a problem. Agreed. Comparing the output between the previous and the proposed build seems to be a fair compromise. Thanks, James signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: QA's Package update policy proposal
On Tue, 2010-03-09 at 17:18 -0800, Adam Williamson wrote: > On Tue, 2010-03-09 at 17:13 -0700, Kevin Fenzi wrote: > > > > Some basics I'd propose as a starting point for defining acceptance > > > criteria include: > > > > > > 1. repoclosure/conflicts - no package update can introduce broken > > > deps or conflicts. I'd recommend we apply this to both > > > 'updates-testing' and 'updates' (but that's detailed below) > > > 2. Package sanity > > > * No rpmlint failures > > > > I think this one should not be there. Or should be heavily filtered. > > rpmlint sometimes marks things as errors that are not. > > +1 here. The current upstream rpmlint errors/warnings list is not what > we'd want to use to automatically approve/deny updates, I'm fairly sure. > =) We'd need to either get quite drastic changes upstream, or overlay > our own error/warning split on the tests (which is what Mandriva does; > there's an automated rpmlint run on every package submission and it > rejects packages if certain tests fail, but the definition of which > tests are critical is *not* the upstream one). > > Over time this would work fine, but at the start it may possibly > introduce some absurdity due to 'grandfathered in' situations: an update > may be rejected due to some lint failure which was actually present in > the version of the package that's being updated anyway (it's not a > _change_ in the update). I'm not sure if that's really a problem - we > could just argue that the problems should be fixed and when you're > pushing an update is as good a time as any to fix them - but I thought > it'd be worth mentioning in advance just in case. Anyway, we should be > very careful and conservative to start with, in terms of what automated > tests we introduce. I'd recommend we do a week or two where we 'dry run' > the system - generate lists of updates which would have been blocked, > but don't actually block them - to make sure the results are sane, > before we start actually blocking things. All fair points. Given that rpmlint is only run when packages are first accepted into Fedora ... I suspect many packages would not meet this criteria. Another idea was to not allow any *new* rpmlint failures. Any failures that exist in previous builds would be permitted. Thanks, James signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install fedora-easy-karma by default?
Bill Nottingham wrote: > Till Maas (opensou...@till.name) said: >>> Also thanks for packaging that immediately -- what about installing it >>> by default? It's a tiny package and we really do want our users to >>> provide feedback. >> >> I do not mind, if it is installed by default, but I am not sure, >> whether this is a good idea. Users will still need a FAS account, >> install packages from updates-testing and know that it exist to use it. > > Given that it at the moment requires a FAS account, perhaps having > it as default in the Fedora packager group is a good first step. > > Hey, why don't we register for FAS accounts with firstboot? Can you leave bodhi feedback with an FAS account if you haven't signed a CLA? (The thing about FAS accounts I am not crazy about is the CLA. What about using a bugzilla account instead?) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- . . . . . #...@no CARRIER -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
On Wed, Mar 10, 2010 at 12:32 PM, Robyn Bergeron wrote: >> That looks to be about 400 people need to randomly selected and >> complete the survey (for +/- 5%). to get down to 1% you would need to >> get 6500 people. > > I don't think that the near-impossibility of having a statistically > sound sample that would hold up in a court of law means that we > shouldn't at least get a feel for who users are by doing a survey. > Certainly, an somewhat unstatistically-sound sampling is much better > than all of us guessing, is it not? :) > I am not looking for something to hold up in court.. however currently we have very contentious issues that people are wanting to survey. And the results will be used to 'settle' those issues in the minds of the 'winners'. [No less than when a partisan's candidate is shown to be ahead but still within margin of error, they will just state it proves that the masses are on their side.] And on the counterside, every thing that doesn't meet criteria will be brought as why it was rigged. To clarify, the surveys as you mentioned in your previous email and the data you are looking for are good 'first' steps that any series of surveys need. And you have been clear in the beginning that they aren't meant to clarify larger issues like: KDE vs GNOME vs LXDE, fast updates versus no updates, boxers versus thongs... they are mostly to get a general feel where it doesn't really matter if your error is +/-10% or that there is small amount of a self-selection bias. In the case where you wanted to start drilling down "Why do programmers prefer boxers but our QA people prefered thongs, and people who said they were just users said Hanes?" then you want to start being more rigorous. Does the above better clarify for you my point of view? -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100310 changes
Compose started at Wed Mar 10 09:15:11 UTC 2010 Broken deps for i386 -- blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28 doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5 edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 frei0r-plugins-1.1.22-3.fc13.i686 requires libcxcore.so.4 frei0r-plugins-1.1.22-3.fc13.i686 requires libhighgui.so.4 frei0r-plugins-1.1.22-3.fc13.i686 requires libcv.so.4 frei0r-plugins-1.1.22-3.fc13.i686 requires libml.so.4 frei0r-plugins-1.1.22-3.fc13.i686 requires libcvaux.so.4 gnome-python2-totem-2.29.1-4.fc13.i686 requires libtotem-plparser.so.12 1:gnumeric-1.9.17-3.fc13.i686 requires libgoffice-0.8.so.7 1:gnumeric-plugins-extras-1.9.17-3.fc13.i686 requires libgoffice-0.8.so.7 kipi-plugins-1.1.0-2.fc13.i686 requires libhighgui.so.4 kipi-plugins-1.1.0-2.fc13.i686 requires libcxcore.so.4 kipi-plugins-1.1.0-2.fc13.i686 requires libcv.so.4 kipi-plugins-1.1.0-2.fc13.i686 requires libcvaux.so.4 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgobject-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libglib-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgthread-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgio-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgmodule-2.0.so.0.2303.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 nip2-7.20.7-2.fc13.i686 requires libgoffice-0.8.so.7 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 -- blahtexml-0.6-5.fc12.x86_64 requires libxerces-c.so.28()(64bit) doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 doodle-0.6.7-5.fc12.x86_64 requires libextractor.so.1()(64bit) easystroke-0.5.2-1.fc13.x86_64 requires libboost_serialization-mt.so.5()(64bit) edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 edje-0.9.9.050-6.fc12.x86_64 requires libembryo.so.0()(64bit) frei0r-plugins-1.1.22-3.fc13.x86_64 requires libcvaux.so.4()(64bit) frei0r-plugins-1.1.22-3.fc13.x86_64 requires libcv.so.4()(64bit) frei0r-plugins-1.1.22-3.fc13.x86_64 requires libhighgui.so.4()(64bit) frei0r-plugins-1.1.22-3.fc13.x86_64 requires libml.so.4()(64bit) frei0r-plugins-1.1.22-3.fc13.x86_64 requires libcxcore.so.4()(64bit) gnome-python2-totem-2.29.1-4.fc13.x86_64 requires libtotem-plparser.so.12()(64bit) 1:gnumeric-1.9.17-3.fc13.i686 requires libgoffice-0.8.so.7 1:gnumeric-1.9.17-3.fc13.x86_64 requires libgoffice-0.8.so.7()(64bit) 1:gnumeric-plugins-extras-1.9.17-3.fc13.x86_64 requires libgoffice-0.8.so.7()(64bit) kipi-plugins-1.1.0-2.fc13.x86_64 requires libcvaux.so.4()(64bit) kipi-plugins-1.1.0-2.fc13.x86_64 requires libcv.so.4()(64bit) kipi-plugins-1.1.0-2.fc13.x86_64 requires libhighgui.so.4()(64bit) kipi-plugins-1.1.0-2.fc13.x86_64 requires libcxcore.so.4()(64bit) 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgobject-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libglib-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgthread-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgio-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgmodule-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgthread-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgio-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgobject-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libglib-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgmodule-2.0.so.0.2303.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) nip2-7.20.7-2.fc13.x86_64 requires libgoffice-0.8.so.7()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package check_postgres PostgreSQL monitoring script New package dmapd A server that provides DAAP and DPAP shares New package perl-Net-SSLGlue Add/extend SSL support for common perl modules Updated Packages: GConf2-2.28.0-9.fc13 * Wed Mar 03 2010 Tom "spot" Callaway 2.28.0-9 - add macros.gconf2 - own /var/lib/rpm-state/gconf ORBit2-2.14.17-4.fc13 - * Mon Mar 01 2010 Matthias Clasen - 2.14.17-4 - Drop ownership of /usr/share/idl, since filesystem owns it atanks-4.3-3.fc13 - * Wed Feb 17 2010 Nikola Pajkovsky - 4.3-3 - Resolve
Re: Meeting summary/minutes for 2010-03-09 FESCo meeting
On Wed, Mar 10, 2010 at 1:01 PM, Peter Jones wrote: > On 03/10/2010 02:16 AM, Rahul Sundaram wrote: >> On 03/10/2010 06:55 AM, Seth Vidal wrote: >>> >>> I agree, there was obviously a divisive and destructive aspect to that >>> meeting. >>> >>> Jonathan, Do you have any thoughts on what we can do to correct it? >>> >> >> Follow basic IRC etiquette for meetings >> >> http://fedoraproject.org/wiki/How_to_use_IRC#Meeting_Protocol > > Does anybody actually use these terrible rules? I wouldn't call them terrible. They only seem to be for certain kinds of meetings which I would think are ones where people are spouting so much that few can tell who is talking about who or what. Not everyone can multiparse conversations at the rate you can :). -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing `gold-rebuild' - link your packages with gold now
> Actually what I do, Roland, it that I grab binutils daily tarball > and rebuild it as Source0 of Rawhide's SRPM (really ugly...) so I > always use the latest one, see '-r' option. Drawback in the script > is that it always rebuilds binutils even if you have today's > binutils RPMs somewhere, that's just a detail a the moment, I guess. Wow, cute hack! You are a crazy man. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: IBM Statement on TCG DRTM Support
On 03/10/2010 02:53 PM, George C. Wilson wrote: > IBM supports the TCG DRTM standard efforts. After the approval of the TCG > DRTM standard, IBM is planning to develop and provide DRTM UEFI support in > its System X product line. That's all well and good, but is there a reason you sent this to the Fedora development list? -- Peter Growth for the sake of growth is the ideology of the cancer cell. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes for 2010-03-09 FESCo meeting
On 03/10/2010 02:16 AM, Rahul Sundaram wrote: > On 03/10/2010 06:55 AM, Seth Vidal wrote: >> >> I agree, there was obviously a divisive and destructive aspect to that >> meeting. >> >> Jonathan, Do you have any thoughts on what we can do to correct it? >> > > Follow basic IRC etiquette for meetings > > http://fedoraproject.org/wiki/How_to_use_IRC#Meeting_Protocol Does anybody actually use these terrible rules? -- Peter Growth for the sake of growth is the ideology of the cancer cell. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
IBM Statement on TCG DRTM Support
IBM supports the TCG DRTM standard efforts. After the approval of the TCG DRTM standard, IBM is planning to develop and provide DRTM UEFI support in its System X product line. -- George Wilson IBM Linux Technology Center Security Development -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 -EGPUDRIVERNOWORKIE
I can install F13 in text mode later and send some more informations about these issues with both drivers. Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 -EGPUDRIVERNOWORKIE
On Wed, 2010-03-10 at 13:44 -0500, Adam Jackson wrote: > On Wed, 2010-03-10 at 17:20 +0100, Michal Hlavinka wrote: > > On Wednesday 10 March 2010 17:14:41 Michał Piotrowski wrote: > > > Hi, > > > > > > I tried to install this new Goddard thing on my laptop and it seems to be > > > b0rken https://bugzilla.redhat.com/show_bug.cgi?id=572243 > > > > > > Any chance to get graphical installer with vesa driver? > > > > > > Regards, > > > Michal > > > > afaik you have to use xdriver=vesa as additional boot parameter > > He did. I took the sensible precaution of dumping /proc/cmdline in the > X log for exactly this reason. > > The real issue is that the addition of xorg.conf.d support seems to have > changed how the automatic configuration logic works, such that _only_ > the intel driver is loaded, instead of falling back to vesa. > > I'm looking into it. This sounds like it's similar to what we saw with the vboxvideo driver, right? When that failed it didn't fall back to vesa, either... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
On Wed, Mar 10, 2010 at 11:08 AM, Stephen John Smoogen wrote: > On Tue, Mar 9, 2010 at 10:48 PM, Jon Masters wrote: >> On Tue, 2010-03-09 at 17:30 -0500, Chris Ball wrote: >> >>> Now, there's a reasonable argument that says that Fedora users without >>> FAS accounts didn't vote for FESCo, so it's still legitimate to ask >>> *those* users what they think. The impossibility of reaching such a >>> group of users without incorporating selection bias would turn me off >>> from trying to do that -- it would be nice if we could find out how >>> the entire Fedora-using world feels about updates, but that's not >>> actually plausible. Even just the set of Fedora users who visit >>> http://fedoraproject.org/ is significantly selection-biased already, >>> in my opinion. >> >> You could argue that only certain really interested parties will look at >> fedoraproject.org, but that's why I was suggesting the start page or >> firstboot (bad idea, I know), or something people will see when they >> first open a browser or use a system. Not just the die hards. >> >> My personal opinion is that user feedback in general is a good thing, >> even if you ultimately choose to disregard it. And I think putting a >> survey up for 6 months (e.g. all of F13) would give plenty of time to do >> reasonably useful statistical analysis of opinions. Shove in a few other >> more generic questions if there are any others - e.g. "what do you use >> Fedora for anyway?". Wouldn't that be good to know :) >> >> Jon. >> >> P.S. The government is elected, doesn't mean they don't still hold a >> census every decade to find out who their users are. >> > > Ok just basic statistics here (I will defer to Jeff Spaleta or Diana > or other gurus)... but your analogy and survey need improvement to > have statistical validity. In these sort of surveys you either need to > survey everyone OR survey a random sample that are not self-selected. > > Valid census data is one that has close to 100% coverage within some > statistical deltas. It is probably the most valid data because of > that, however it can be gammed if the people taking don't take it > seriously. [The statistical deltas are the things that everyone argues > about saying you can't trust the data... but well we are all comrade > scientists here (thats supposed to be a funny)] > > Surveys are valid within some margin of error and 'confidence level' > as long as the data can be shown not be self-selecting, the questions > properly phrased, and a study of various groups being polled is known > (reference to census material to know that if you randomly call X > people in Y region you will get Z% of sub-group.) You have to work out > how many people you tried to survey, how many completed the survey, > how much confidence you have in the population etc. > > For a group as small as Fedora (less than 50,000 registered users who > you could survey) you would need to survey that actually is much > larger than standard. An initial survey would probably want to have a > confidence level of 95% and a confidence interval of +/- 5%. If after > the survey your percentages are within that error bar (47% for/48% > against..) you need to resurvey with a larger number. So for a first > step, we would need to get a survey list made, have the questions > reworded/etc to meet various survey tests, and then randomly pick a > population and survey them (I am over simplifying here... there are > various steps required I am not sure of). > > That looks to be about 400 people need to randomly selected and > complete the survey (for +/- 5%). to get down to 1% you would need to > get 6500 people. I don't think that the near-impossibility of having a statistically sound sample that would hold up in a court of law means that we shouldn't at least get a feel for who users are by doing a survey. Certainly, an somewhat unstatistically-sound sampling is much better than all of us guessing, is it not? :) > > > > -- > Stephen J Smoogen. > > Ah, but a man's reach should exceed his grasp. Or what's a heaven for? > -- Robert Browning > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adventurous yet Safety-Minded
I realize this doesn't address the concern about not pushing broken updates to begin with. However, if yum and/or rpm could do a downgrade from locally cached delta, it would make reverting the change that broke the system much easier. This obviously won't work if it's rpm that breaks, but that is typically a Rawhide problem. If there's a magic solution that will satisfy the vast majority of Fedora users, I have absolutely no clue as to what it might be. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
On Tue, Mar 9, 2010 at 10:48 PM, Jon Masters wrote: > On Tue, 2010-03-09 at 17:30 -0500, Chris Ball wrote: > >> Now, there's a reasonable argument that says that Fedora users without >> FAS accounts didn't vote for FESCo, so it's still legitimate to ask >> *those* users what they think. The impossibility of reaching such a >> group of users without incorporating selection bias would turn me off >> from trying to do that -- it would be nice if we could find out how >> the entire Fedora-using world feels about updates, but that's not >> actually plausible. Even just the set of Fedora users who visit >> http://fedoraproject.org/ is significantly selection-biased already, >> in my opinion. > > You could argue that only certain really interested parties will look at > fedoraproject.org, but that's why I was suggesting the start page or > firstboot (bad idea, I know), or something people will see when they > first open a browser or use a system. Not just the die hards. > > My personal opinion is that user feedback in general is a good thing, > even if you ultimately choose to disregard it. And I think putting a > survey up for 6 months (e.g. all of F13) would give plenty of time to do > reasonably useful statistical analysis of opinions. Shove in a few other > more generic questions if there are any others - e.g. "what do you use > Fedora for anyway?". Wouldn't that be good to know :) Did someone say... SURVEY?? :) Well. I know the Marketing team would like to know the answers to some of these generic, demographical questions, which is why we're also planning a general end-user survey. :) Marketing FAD is this weekend (http://fedoraproject.org/wiki/Marketing_FAD_2010) and one of our task items is to develop questions for a general Fedora end-user survey. While this is obviously not going to be solely developer-focused, developing a short list of feedback-oriented, rather than vote-oriented questions, with FESCo would be great. By feedback oriented, I mean that questions should be more along the lines of, "What is your current level of satisfaction with X," rather than, "Which of the following should we do? X, Y, or Z?" (In case you're wondering, or getting ready to flame Robyn, the survey is mostly going to be a "who are you, where are you, what are you using Fedora for, how often are you downloading, how do you participate, etc." type of survey. We will have room for more questions, but we do want to keep in mind that having a 350-question survey is a Bad Idea, so we want to be concise and to the point in order to encourage people to actually -finish- the survey. 5-10 minutes, max. Wiki page is here: http://fedoraproject.org/wiki/Marketing_research) We're planning on using limesurvey (limesurvey.org) for infrastructure - once we get it packaged (plz come help! :D) and tested and deployed on fp.o infrastructure, we're going to move ahead. And so - if anyone from devel / FESCo is interested in participating in developing a few questions to tack on to our survey - as I said previously, awesome, and I'd be happy to coordinate details on the marketing list. Alternately, since we do plan on allowing any of the fp.o Family to use limesurvey for their own survey needs once it's up and running - you certainly have the option of running your own survey on the infrastructure, and I'd be happy to help word questions appropriately and such. And of course, the option exists to do something entirely different on your own. :) Food for thought. It never hurts to know who end users are - it is just good to be clear up front in a survey that it is a -survey-, and not a -vote-; results are for feedback, not for making immediate decisions, and the questions should be worded as such. I'll be in the corner with my flame-retardant gear on if anyone has questions :D But seriously: We'd love to have a good success with a first survey, and that means having feedback from all the different Fedora teams. We want to get information that is useful to everyone - and NOT let it be an election of any kind. -Robyn > > Jon. > > P.S. The government is elected, doesn't mean they don't still hold a > census every decade to find out who their users are. +1 :) > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
On Tue, Mar 9, 2010 at 10:48 PM, Jon Masters wrote: > On Tue, 2010-03-09 at 17:30 -0500, Chris Ball wrote: > >> Now, there's a reasonable argument that says that Fedora users without >> FAS accounts didn't vote for FESCo, so it's still legitimate to ask >> *those* users what they think. The impossibility of reaching such a >> group of users without incorporating selection bias would turn me off >> from trying to do that -- it would be nice if we could find out how >> the entire Fedora-using world feels about updates, but that's not >> actually plausible. Even just the set of Fedora users who visit >> http://fedoraproject.org/ is significantly selection-biased already, >> in my opinion. > > You could argue that only certain really interested parties will look at > fedoraproject.org, but that's why I was suggesting the start page or > firstboot (bad idea, I know), or something people will see when they > first open a browser or use a system. Not just the die hards. > > My personal opinion is that user feedback in general is a good thing, > even if you ultimately choose to disregard it. And I think putting a > survey up for 6 months (e.g. all of F13) would give plenty of time to do > reasonably useful statistical analysis of opinions. Shove in a few other > more generic questions if there are any others - e.g. "what do you use > Fedora for anyway?". Wouldn't that be good to know :) > > Jon. > > P.S. The government is elected, doesn't mean they don't still hold a > census every decade to find out who their users are. > Ok just basic statistics here (I will defer to Jeff Spaleta or Diana or other gurus)... but your analogy and survey need improvement to have statistical validity. In these sort of surveys you either need to survey everyone OR survey a random sample that are not self-selected. Valid census data is one that has close to 100% coverage within some statistical deltas. It is probably the most valid data because of that, however it can be gammed if the people taking don't take it seriously. [The statistical deltas are the things that everyone argues about saying you can't trust the data... but well we are all comrade scientists here (thats supposed to be a funny)] Surveys are valid within some margin of error and 'confidence level' as long as the data can be shown not be self-selecting, the questions properly phrased, and a study of various groups being polled is known (reference to census material to know that if you randomly call X people in Y region you will get Z% of sub-group.) You have to work out how many people you tried to survey, how many completed the survey, how much confidence you have in the population etc. For a group as small as Fedora (less than 50,000 registered users who you could survey) you would need to survey that actually is much larger than standard. An initial survey would probably want to have a confidence level of 95% and a confidence interval of +/- 5%. If after the survey your percentages are within that error bar (47% for/48% against..) you need to resurvey with a larger number. So for a first step, we would need to get a survey list made, have the questions reworded/etc to meet various survey tests, and then randomly pick a population and survey them (I am over simplifying here... there are various steps required I am not sure of). That looks to be about 400 people need to randomly selected and complete the survey (for +/- 5%). to get down to 1% you would need to get 6500 people. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 -EGPUDRIVERNOWORKIE
On Wed, 2010-03-10 at 17:20 +0100, Michal Hlavinka wrote: > On Wednesday 10 March 2010 17:14:41 Michał Piotrowski wrote: > > Hi, > > > > I tried to install this new Goddard thing on my laptop and it seems to be > > b0rken https://bugzilla.redhat.com/show_bug.cgi?id=572243 > > > > Any chance to get graphical installer with vesa driver? > > > > Regards, > > Michal > > afaik you have to use xdriver=vesa as additional boot parameter He did. I took the sensible precaution of dumping /proc/cmdline in the X log for exactly this reason. The real issue is that the addition of xorg.conf.d support seems to have changed how the automatic configuration logic works, such that _only_ the intel driver is loaded, instead of falling back to vesa. I'm looking into it. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes for 2010-03-09 FESCo meeting
> There are nearly no facts, so everyone is just > guessing and many people are just ignoring objections. That is true, indeed. But do we really need detailed statistics to make a good decision? All of us have an experience with Fedora over the last years. And I *guess* ( :-) ) most or even all of them are quit happy with it otherwise they would have left over time (a guess, not hard statistics). Therefore, the Fedora project does it basically right! There is room for improvement, of course, but is's fine tuning, not a decision dead or alive (as the style of discussion of some participant might suggest). All participants should keep that fact in mind! And instead having 2 groups striving against each other we could concentrate on *solutions* to make *both* happy (both groups are obviously "relevant", by number and/or by constribution and engagement). That would be a professional and constructive way to deal with the situation. Several proposals have been made. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: should man-pages-* have Requires: man?
On Wed, 2010-03-10 at 11:56 +0100, Ralf Corsepius wrote: > On 03/10/2010 11:40 AM, Ivana Hutarova Varekova wrote: > > from my point of view, the vast majority of users uses man to show the > > wanted man-page content (the reason to add the dependency). > > Agreed. > > Actually, I am having problems to imagine any system without "man" > installed, esp. because SUSV/POSIX mandates man to be present. You think Fedora has to be POSIX? That's adorable. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install fedora-easy-karma by default? (was: Re: Expect more positive bodhi karma / check karma automatism)
Till Maas (opensou...@till.name) said: > > Also thanks for packaging that immediately -- what about installing it > > by default? It's a tiny package and we really do want our users to > > provide feedback. > > I do not mind, if it is installed by default, but I am not sure, > whether this is a good idea. Users will still need a FAS account, > install packages from updates-testing and know that it exist to use it. Given that it at the moment requires a FAS account, perhaps having it as default in the Fedora packager group is a good first step. Hey, why don't we register for FAS accounts with firstboot? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Michael Schwendt wrote: > On Wed, 10 Mar 2010 11:30:05 -0600, Matthew wrote: >> Probably because >> I need multilib and have never experienced multilib-related problems (or >> if I have, they were so trivial as to be thoroughly forgettable). > > Just out of interest, does enabling a separate 32-bit repository on a > 64-bit installation lead to more/severe problems than using a multiarch > repo? I haven't tried it, but it at least introduces the question 'what coreutils/X/KDE do you want?'. Of course, I'd say that if that works decently, you're still providing functional multilib. So I don't really care about how it happens under the hood, as long as it works. >> (From that, I guess that you consider testing of a >> 32-bit program invalid unless done on a pure 32-bit kernel? > > No. I think it depends on what sort of program would be tested. > A 32-bit multlib development environment on a 64-bit installation > does not add a full 32-bit run-time environment. Hmm, maybe then you are thinking of things that are far less stand-alone. The only "run-time environment" we care about is that the program can be executed (so, kernel can load it, glibc.i?86 exists, etc.). We tend to have very few if any dependencies beyond libc (and even then, beyond libc/libm/libpthread, we usually provide our own). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- . . . . . #...@no CARRIER -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gdbm soname change in Rawhide, package rebuild needed
On Wed, 2010-03-10 at 10:00 -0800, Jesse Keating wrote: > On Wed, 2010-03-10 at 18:25 +0100, Karel Klic wrote: > > A newer version of gdbm (1.8.0->1.8.3) has been pushed into rawhide > > (devel) branch. This version changes libgdbm soname, so all packages > > using gdbm _must be rebuilt_. > > > > The soname change is needed as the new version moves dbm and ndbm > > routines to separate library gdbm_compat. > > > > The new version fixes a memory leak. I also added some fixes from Debian > > preventing uninitialized memory contents to be stored in databases and > > fixing potential database read failures. > > Since buildroots are broken once this change gets into the build roots, > I'm working on the perl and python rebuilds so that others can get > going. > On second thought, this isn't going to work, as perl is part of the build group which we install into every buildroot, and we can't install it due to gdbm missing deps. We'll have to introduce a compat-gbdm temporarily to get perl/python et al rebuilt. We are untagging the new gdbm in the mean time. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adventurous yet Safety-Minded
On Wed, Mar 10, 2010 at 04:06:58 -0800, Steven I Usdansky wrote: > Instead of worrying about the occasional brokenness caused by an update to a > stable release, how about focusing on a mechanism to easily recover from it? > As long as the update hasn't corrupted any critical files, my non-optimal > solution is to head over to koji, grab the last version of the broken package > set that worked for me, and install. If yum could be persuaded to stash the > required deltas locally, and downgrade using those local deltas upon request, > I'd be a very happy camper. While working on making it easier to recover from brokenness is useful, it doesn't replace not pushing broken stuff out to users in the first place. So it shouldn't be 'instead'. The probablem with broken updates is that people aren't always in a position to spend time recovering from broken updates at the time updates are applied. And deferring updates to such a time isn't always a good alternative since you need to worry about security updates which should be applied promptly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
On Wed, 10 Mar 2010 11:30:05 -0600, Matthew wrote: > Probably because > I need multilib and have never experienced multilib-related problems (or > if I have, they were so trivial as to be thoroughly forgettable). Just out of interest, does enabling a separate 32-bit repository on a 64-bit installation lead to more/severe problems than using a multiarch repo? > (From that, I guess that you consider testing of a > 32-bit program invalid unless done on a pure 32-bit kernel? No. I think it depends on what sort of program would be tested. A 32-bit multlib development environment on a 64-bit installation does not add a full 32-bit run-time environment. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gdbm soname change in Rawhide, package rebuild needed
On Wed, 2010-03-10 at 18:25 +0100, Karel Klic wrote: > A newer version of gdbm (1.8.0->1.8.3) has been pushed into rawhide > (devel) branch. This version changes libgdbm soname, so all packages > using gdbm _must be rebuilt_. > > The soname change is needed as the new version moves dbm and ndbm > routines to separate library gdbm_compat. > > The new version fixes a memory leak. I also added some fixes from Debian > preventing uninitialized memory contents to be stored in databases and > fixing potential database read failures. Since buildroots are broken once this change gets into the build roots, I'm working on the perl and python rebuilds so that others can get going. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash
On 03/08/2010 09:29 PM, Matthew Woehlke wrote: > Michael Schwendt wrote: >> There are just too many -devel packages and their dependencies to be ever >> relevant to someone for multi-arch installs. Far more users install i686 on >> 64-bit CPUs, and I have doubts that x86_64 installation users do much >> development with i686 packages. When regarding myself and my co-workers, you could not be much wronger ;) >> At most they install 32-bit apps where >> 64-bit builds aren't available or "less good". This applies to "users", but doesn't apply to developers. > You forget people developing proprietary software... There is no need to restrict this to proprietary SW. There are use-cases for each of the scenarios mentioned in this thread. Fedora supporting all of them had been one of the reasons for us to choose Fedora as development platform (openSUSE would be an alternative, but Debian/Ubuntu aren't, one reason being lack of multilibs). > or even just > multilib apps. Multilib is useful if you want to build the 32-bit > version of something on an x86_64 box (and don't want to set up a full > chroot / VM). Exactly. Also consider working on mere "client systems", without VMs, chroots, multi-boots, root-access etc. Multilibs are a valueable option to developers in such cases. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Michael Schwendt wrote: > On Mon, 08 Mar 2010 14:29:42 -0600, Matthew wrote: > >>> There are just too many -devel packages and their dependencies to be ever >>> relevant to someone for multi-arch installs. Far more users install i686 on >>> 64-bit CPUs, and I have doubts that x86_64 installation users do much >>> development with i686 packages. At most they install 32-bit apps where >>> 64-bit builds aren't available or "less good". >> >> You forget people developing proprietary software... > > Why would development of proprietary software have different requirements > with regard to multilib installations? ...because said developers are more likely to be developing i686 packages on x86_64. Mostly, I disagree with your ratio of "people who need multilib" versus "people for whom multilib causes problems" differently. Probably because I need multilib and have never experienced multilib-related problems (or if I have, they were so trivial as to be thoroughly forgettable). >> Multilib is useful if you want to build the 32-bit version of >> something on an x86_64 box (and don't want to set up a full chroot >> / VM). > > The "don't want to" is questionable. Development of the 32-bit version > would still need a full 32-bit test installation. A test installation of /what you built/, yes. And you have that, since you just built it. (From that, I guess that you consider testing of a 32-bit program invalid unless done on a pure 32-bit kernel? I sure don't.) > It need not be the x86_64 box to do full multi-booting instead of > VM, but even multi-booting would be convenient enough, considering > how quickly something like Fedora can be installed. Typical > development is not trial-and-error compilation of both 64-bit and > 32-bit and alternating, but rather development on either arch till > something is ready to be built for and to be tested on a different > arch. You obviously have a different definition of "typical" than I do. For $DAYJOB we build both 32- and 64-bit at the same time and test both within the same test suite. That's my "typical". Given that Windows (go figure) is the only platform for which we consider 32- versus 64-bit to be different ports, that's not likely to change. Multi-booting is not only inconvenient, it isn't an option. Multilib *is* the method we use to build and test. End of story. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Sorry, fresh out of .sigs. Maybe tomorrow. (paraphrased German saying) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gdbm soname change in Rawhide, package rebuild needed
A newer version of gdbm (1.8.0->1.8.3) has been pushed into rawhide (devel) branch. This version changes libgdbm soname, so all packages using gdbm _must be rebuilt_. The soname change is needed as the new version moves dbm and ndbm routines to separate library gdbm_compat. The new version fixes a memory leak. I also added some fixes from Debian preventing uninitialized memory contents to be stored in databases and fixing potential database read failures. Affected packages: (maintainers are CCed) am-utils avahi clisp compat-python24 freeradius fsvs gauche gnu-smalltalk jpilot-backup lighttpd Macaulay2 maildrop mt-daapd ntop ocaml OpenIPMI parrot perl perl-eperl perl-XML-LibXSLT pulseaudio python q qfaxreader qsf ruby snobol tcl-thread vacation Thanks. Best regards, Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates proposal - alternative draft 1
On Wed, Mar 10, 2010 at 00:52:38 +0530, Rahul Sundaram wrote: > > Let me know what you think This should be split into two policy proposals. One should cover QA related processes for pushing updates. The second should cover expectations on what kinds of updates packagers should be pushing to various releases. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Matthew Woehlke wrote: > Kevin Kofler wrote: >> Matthew Woehlke wrote: >>> You forget people developing proprietary software... >> >> Why would we want to encourage or even support that? > > I don't expect Fedora to encourage it (nor should we, IMO)... but that > doesn't change the reality of $DAYJOB. If Fedora drops multilib, I will > be forced to drop Fedora. Not out of spite, but because it will no > longer be able to do my job. Meh. Should read "...because it will no longer be possible for me to do my job with Fedora." -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- . . . . . #...@no CARRIER -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates proposal - alternative draft 1
On Wed, Mar 10, 2010 at 01:20:21 +0530, Rahul Sundaram wrote: > As opposed to fake security threats? In the case of the kernel, if the > new kernel update we rush through without passing via updates-testing > repo doesn't boot you can always boot back into an older kernel but We can do that, but not everyone can. Remember the default timeout for grub is now 0 seconds, so I expect a significant number of our users are not going to know what to do if a kernel update doesn't work for them. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Kevin Kofler wrote: > Matthew Woehlke wrote: >> You forget people developing proprietary software... > > Why would we want to encourage or even support that? I don't expect Fedora to encourage it (nor should we, IMO)... but that doesn't change the reality of $DAYJOB. If Fedora drops multilib, I will be forced to drop Fedora. Not out of spite, but because it will no longer be able to do my job. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- . . . . . #...@no CARRIER -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: QA's Package update policy proposal
On Tue, Mar 09, 2010 at 15:43:04 -0500, James Laska wrote: > > 1. repoclosure/conflicts - no package update can introduce broken > deps or conflicts. I'd recommend we apply this to both > 'updates-testing' and 'updates' (but that's detailed below) > 2. Package sanity > * No rpmlint failures > * Is the Source properly defined > * License review/examination (if possible) > * Upstream Source match tarball > * Package scriptlet syntax checks > 3. Package must be newer than previously released versions - can't > ship newer package in N-1. > 4. Any additional MUST requirements folks would like to see covered > from the package review requirements? File conflicts (assuming that "conflicts" above referred to just conflicts dependencies). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes for 2010-03-09 FESCo meeting
On Wednesday, 10 March 2010 at 17:34, Toshio Kuratomi wrote: > On Wed, Mar 10, 2010 at 04:38:53PM +0100, Dominik 'Rathann' Mierzejewski > wrote: [...] > > Agreed. However, we should ask ourselves if it's better to have a package > > in our distribution even if it doesn't fit ideally with the rest or not > > to have it at all? > > > > I prefer the latter. Someone might step up as co-maintainer and help. > > Starting from scratch is usually more difficult. > > > Reading this whole paragraph, I think you meant former in the first > sentence. Indeed, I meant the former of course. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To semi-rolling or not to semi-rolling, that is the question...
On Tue, Mar 09, 2010 at 14:06:12 -0500, Doug Ledford wrote: > > Things like the libata kernel change and KDE 3 to 4 migration are > intentional events and all that's needed to make the transition smooth > is to coordinate the release of a seamless upgrade package set. You I lived through the libata change and a coordinated release of updates is not all that was needed in that case. For that change guinea pigs were needed to test specific hardware. In my case my ATA card was having problems because there were similarly identified cards that needed different drivers and it took a while before the two sets were correctly identified. For a significant part of that rawhide development the set of cards that worked switched back and forth. See https://bugzilla.redhat.com/show_bug.cgi?id=227281 for the saga. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
On Wed, Mar 10, 2010 at 10:53:49 -0500, Simo Sorce wrote: > > What I don't get, seriously, is why people in 2. can't use rawhide or > the latest updates-testing and instead pretend to inflict "almost > rawhide" on everybody else. Because updates-testing is really for testing not for providing new features to only some of our users. (Though a few packagers appear to use it that way.) There seem to be some people who find rawhide too disruptive, but still want the latest and greatest. Following the prerelease branch might be something that would work for those people. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: Bug 570542 - Root password cannot contain matching curly braces
Hi, Please review the patch for the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=570542 https://bugzilla.redhat.com/attachment.cgi?id=398976&action=edit https://bugzilla.redhat.com/attachment.cgi?id=398976&action=diff Thanks. -- Endi S. Dewata -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: F13 -EGPUDRIVERNOWORKIE
2010/3/10 Michal Hlavinka : > On Wednesday 10 March 2010 17:14:41 Michał Piotrowski wrote: >> Hi, >> >> I tried to install this new Goddard thing on my laptop and it seems to be >> b0rken https://bugzilla.redhat.com/show_bug.cgi?id=572243 >> >> Any chance to get graphical installer with vesa driver? >> >> Regards, >> Michal > > afaik you have to use xdriver=vesa as additional boot parameter Aaa, this is "simple viedo driver" in boot menu - it also doesn't work for me. > > Michal Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100310 changes
Compose started at Wed Mar 10 08:15:05 UTC 2010 Broken deps for i386 -- accountsdialog-0.5.1-1.fc14.i686 requires libcheese-gtk.so.17 calibre-0.6.42-1.fc14.i686 requires libMagickCore.so.2 calibre-0.6.42-1.fc14.i686 requires libMagickWand.so.2 drawtiming-0.7.1-1.fc13.i686 requires libMagick++.so.2 drawtiming-0.7.1-1.fc13.i686 requires libMagickCore.so.2 easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5 emotion-0.1.0.042-5.fc12.i686 requires libecore_job.so.0 emotion-0.1.0.042-5.fc12.i686 requires libevas.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_fb.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_x.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_txt.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_job.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libevas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_fb.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_file.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet_mime.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_con.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_ipc.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedbus.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libehal.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_x.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedje.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_evas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libedje.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 ewl-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet_mime.so.0 ewl-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_evas.so.0 hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 inkscape-0.47-6.fc13.i686 requires libMagickCore.so.2 inkscape-0.47-6.fc13.i686 requires libMagick++.so.2 inkscape-view-0.47-6.fc13.i686 requires libMagick++.so.2 inkscape-view-0.47-6.fc13.i686 requires libMagickCore.so.2 libnodeupdown-backend-openib-1.9-4.fc13.i686 requires libosmcomp.so.2 libnodeupdown-backend-openib-1.9-4.fc13.i686 requires libosmcomp.so.2(OSMCOMP_2.3) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 1:openoffice.org-langpack-dz-3.2.0-12.12.fc14.i686 requires font(:lang=/z) openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas_hg.so.2 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas.so.2 paperbox-0.4.4-2.fc12.i686 requires libtrackerclient.so.0
[389-devel] Please review: Bug 538525 - Ability to create instance as non-root user
Hi, Please review the attached patch for this bug: https://bugzilla.redhat.com/show_bug.cgi?id=538525 Description is included in the patch: https://bugzilla.redhat.com/attachment.cgi?id=398875&action=edit https://bugzilla.redhat.com/attachment.cgi?id=398875&action=diff Thanks. -- Endi S. Dewata -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: F13 -EGPUDRIVERNOWORKIE
2010/3/10 Frank Murphy : > On 10/03/10 16:14, Michał Piotrowski wrote: >> Hi, >> >> I tried to install this new Goddard thing on my laptop and it seems to be >> b0rken >> https://bugzilla.redhat.com/show_bug.cgi?id=572243 >> >> Any chance to get graphical installer with vesa driver? >> >> Regards, >> Michal > > What version *.iso did you try installing with? > Have you a link? http://torrent.fedoraproject.org/torrents//Fedora-13-Alpha-x86_64-DVD.torrent > > -- > Regards, > > Frank Murphy > UTF_8 Encoded, Fedora 12, 13, Rawhide: x86_64 > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 -EGPUDRIVERNOWORKIE
On 10/03/10 16:14, Michał Piotrowski wrote: > Hi, > > I tried to install this new Goddard thing on my laptop and it seems to be > b0rken > https://bugzilla.redhat.com/show_bug.cgi?id=572243 > > Any chance to get graphical installer with vesa driver? > > Regards, > Michal What version *.iso did you try installing with? Have you a link? -- Regards, Frank Murphy UTF_8 Encoded, Fedora 12, 13, Rawhide: x86_64 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes for 2010-03-09 FESCo meeting
On Wed, Mar 10, 2010 at 04:38:53PM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 10 March 2010 at 16:22, Matthias Clasen wrote: > > On Wed, 2010-03-10 at 13:08 +0100, Till Maas wrote: > > > > > Afaics this does not affect some minor issue, but a fundamental reason > > > why package maintainer decided to become Fedora package maintainers. > > > No volunteer package maintainer is in general forced to create updates > > > and I am very sure that the volunteer package maintainers usually do not > > > create updates that they do not want to use. So if you forbid package > > > maintainers to package the version they want or need to use, being a > > > fedora package maintainer becomes pretty useless for them. > > > > I really think we want to have package maintainers whose motivation is a > > bit stronger than 'I use this myself, so, meh, why not package it'. > > Why is that not motivation enough? Why wouldn't we want to have this kind > of people on board (assuming they follow the packaging guidelines and what > not)? Packaging isn't rocket science. > > In fact, my motivation for packaging lots of stuff was: "Hmm, my colleagues > use this and they use Fedora so why not package it and save them the effort?" > In return, I ask them to test new releases. Even if they don't have time to > use bodhi, their feedback is still most valuable. > The way I'd put this is: I think we need *some* packagers whose motivation is more than "I use this myself, so if I package it other people can benefit too" since there are some parts of building a distro and packaging that are plan not fun. But for a large percentage of the packages that we have that is a perfectly sufficient reason. So we need to make the large number of packagers who maintain those large number of packages feel welcome and make it as easy as is sane for them to package things for Fedora. > As Tom wrote on FAB list, the real problem is making it easier for users > to give feedback on updates. Only after we've solved that can we start > thinking of imposing restrictions on package maintainers wrt updates. > +1 > > At > > least for packages that are part of the default install, I would expect > > at least some awareness on the part of the packager that the work he is > > doing needs to fit into the larger whole which is the released product. > Note that this doesn't necessarily conflict with "I use this myself so I'll package it for others to use as well" All package maintainers are weighing various options available to them when they make choices. Someone may choose to update a package because they consider the bugs the update fix to be a high enough priority that it needs to go out to the release. Others may not update because they feel the risk of regression is too high. But both packagers can very well be considering the role their package is playing in the larger distribution. > Agreed. However, we should ask ourselves if it's better to have a package > in our distribution even if it doesn't fit ideally with the rest or not > to have it at all? > > I prefer the latter. Someone might step up as co-maintainer and help. > Starting from scratch is usually more difficult. > Reading this whole paragraph, I think you meant former in the first sentence. -Toshio pgpQvGMzKDyjp.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expect more positive bodhi karma / check karma automatism
On Sat, Mar 6, 2010 at 3:21 PM, Till Maas wrote: > Good news everyone, > > you can probably expect to receive more positive bodhi karma for your > updates in the future (or you already got unexpected much), because > there is now a script called 'fedora-easy-karma'[0], that makes > providing feedback a lot easier. > > This makes it more important to consider the "karma automatism" for your > updates. By default testing updates updates are declared stable when > they get three karma points. In the past this probably never happened, > but now I have seen several updates, where this occurred. So if you > think your package should stay longer in testing or needs more intensive > testing than the average updates, consider disabling the "karma > automatism" or select a higher threshold for the automatic push to > happen. > > Regards > Till > > [0] https://fedoraproject.org/wiki/Fedora_Easy_Karma Thankyou very much Till. I started using it this morning and it seems to work as expected. There are a couple of things that would make it easier to use: 1) Comments could allow for multi-line code. I tried to paste stuff in and well skipped a couple of packages from the paste :) 2) I found so many packages I didn't know were on my system so had no idea what they were. A) is the package linked to things I use daily? [can this be determined.] B) is the package been used by something so I can see its usage by other daemons. In the end, I did remove a couple of things I was like "huh why did I install that?" -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: should man-pages-* have Requires: man?
On Mon, 2010-03-08 at 14:59 +0100, Ralf Corsepius wrote: > > There is no strong dependency between "man" and "man-pages". > > "man" is just one utility amongst many utilities which can be used to > process man-pages. Perhaps it would make sense to introduce a Provides:(man-reader) or some such and add a Requires on the same in the man pages. That way any of the things which consume man pages can satisfy the requirement, not necessarily being man itself. Seems a little obnoxious, but if the desire is to prevent a hard man-pages -> man requirement... -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 -EGPUDRIVERNOWORKIE
On Wednesday 10 March 2010 17:14:41 Michał Piotrowski wrote: > Hi, > > I tried to install this new Goddard thing on my laptop and it seems to be > b0rken https://bugzilla.redhat.com/show_bug.cgi?id=572243 > > Any chance to get graphical installer with vesa driver? > > Regards, > Michal afaik you have to use xdriver=vesa as additional boot parameter Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adventurous yet Safety-Minded
On Wed, Mar 10, 2010 at 04:06:58AM -0800, Steven I Usdansky wrote: > Instead of worrying about the occasional brokenness caused by an > update to a stable release, how about focusing on a mechanism to > easily recover from it? As long as the update hasn't corrupted any > critical files, my non-optimal solution is to head over to koji, > grab the last version of the broken package set that worked for me, > and install. If yum could be persuaded to stash the required deltas > locally, and downgrade using those local deltas upon request, I'd be > a very happy camper. Yum has a 'yum downgrade' subcommand for quite a while now. Not sure if the yum cache stashes the older copies though. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F13 -EGPUDRIVERNOWORKIE
Hi, I tried to install this new Goddard thing on my laptop and it seems to be b0rken https://bugzilla.redhat.com/show_bug.cgi?id=572243 Any chance to get graphical installer with vesa driver? Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes for 2010-03-09 FESCo meeting
On Wed, Mar 10, 2010 at 10:22:37AM -0500, Matthias Clasen wrote: > On Wed, 2010-03-10 at 13:08 +0100, Till Maas wrote: > > > Afaics this does not affect some minor issue, but a fundamental reason > > why package maintainer decided to become Fedora package maintainers. > > No volunteer package maintainer is in general forced to create updates > > and I am very sure that the volunteer package maintainers usually do not > > create updates that they do not want to use. So if you forbid package > > maintainers to package the version they want or need to use, being a > > fedora package maintainer becomes pretty useless for them. > > I really think we want to have package maintainers whose motivation is a > bit stronger than 'I use this myself, so, meh, why not package it'. At > least for packages that are part of the default install, I would expect > at least some awareness on the part of the packager that the work he is > doing needs to fit into the larger whole which is the released product. So we are back to "not all packages are equal". I agree, that the work hast to fit in the whole community, but this is where there are at least two big parties within Fedora, that have a complete opposite idea about it. And an official view, about what this is for Fedora does afaik not exist, yet. Regards Till pgpSly5OfETQW.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
On Wed, 10 Mar 2010 10:46:54 -0500 (EST) Seth Vidal wrote: > > > On Wed, 10 Mar 2010, drago01 wrote: > > > On Tue, Mar 9, 2010 at 2:51 PM, Seth Vidal > > wrote: > >> > >> > >> On Tue, 9 Mar 2010, Jaroslav Reznik wrote: > >> > >>> > >>> Another question - how many broken things we shipped in release > >>> that could be fixed by updates? We shipped lot of unfinished, > >>> feature incomplete stuff in history... > >>> > >>> Nobody can't say I'm for shipping broken stuff - for release, > >>> updates etc... I'm usually the one who says no for > >>> incomplete/broken stuff ;-) > >>> > >>> But please stop this. What I wanted to point out is that there > >>> ARE users out there and we should know, WHO are our users. Or we > >>> can take a risk and set target audience so we would know it or we > >>> can be all-catch distro but then we have to behave like we are > >>> all-catch... In this case you know - we need compromise... > >>> > >> > >> We get the users we aim for. > >> > >> The issue at hand is the type of users we want to aim for. > >> > >> Here's the camps I see: > >> > >> 1. One group wants us to aim for mom/pop/grandma/desktop users - > >> the apple market or what ubuntu aims for. > >> > >> 2. one group wants us to aim exclusively for the bleeding edge open > >> source developer market. > >> > >> 3. one group wants us to aim for the admin/experienced user who > >> wants newer things but doesn't have time nor interest to fight > >> with lots of broken things. > > > > Mind telling why those are mutually exclusive ? > > Why does an operation system that is easy to use (1.) have to be > > broken (3.) or only contain outdated stuff (3., 2.). > > > > Even if people disagree with this we do NOT need a specific target > > audience, selecting a specific group of users and telling others "go > > away" is nothing but failure on our side. > > I think the essential problem is you cannot please everyone all the > time. > > Since we have finite resources we should think in that regard. Who > are the users we want the most? What I don't get, seriously, is why people in 2. can't use rawhide or the latest updates-testing and instead pretend to inflict "almost rawhide" on everybody else. Maybe it was said in the sea of emails of the last week, and I lost it. But this is what I am wondering. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
On Wed, 10 Mar 2010, drago01 wrote: > On Tue, Mar 9, 2010 at 2:51 PM, Seth Vidal wrote: >> >> >> On Tue, 9 Mar 2010, Jaroslav Reznik wrote: >> >>> >>> Another question - how many broken things we shipped in release that could >>> be >>> fixed by updates? We shipped lot of unfinished, feature incomplete stuff in >>> history... >>> >>> Nobody can't say I'm for shipping broken stuff - for release, updates etc... >>> I'm usually the one who says no for incomplete/broken stuff ;-) >>> >>> But please stop this. What I wanted to point out is that there ARE users out >>> there and we should know, WHO are our users. Or we can take a risk and set >>> target audience so we would know it or we can be all-catch distro but then >>> we >>> have to behave like we are all-catch... In this case you know - we need >>> compromise... >>> >> >> We get the users we aim for. >> >> The issue at hand is the type of users we want to aim for. >> >> Here's the camps I see: >> >> 1. One group wants us to aim for mom/pop/grandma/desktop users - the >> apple market or what ubuntu aims for. >> >> 2. one group wants us to aim exclusively for the bleeding edge open >> source developer market. >> >> 3. one group wants us to aim for the admin/experienced user who wants >> newer things but doesn't have time nor interest to fight with lots of broken >> things. > > Mind telling why those are mutually exclusive ? > Why does an operation system that is easy to use (1.) have to be > broken (3.) or only contain outdated stuff (3., 2.). > > Even if people disagree with this we do NOT need a specific target > audience, selecting a specific group of users and telling others "go > away" is nothing but failure on our side. I think the essential problem is you cannot please everyone all the time. Since we have finite resources we should think in that regard. Who are the users we want the most? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
On Tue, Mar 9, 2010 at 2:51 PM, Seth Vidal wrote: > > > On Tue, 9 Mar 2010, Jaroslav Reznik wrote: > >> >> Another question - how many broken things we shipped in release that could be >> fixed by updates? We shipped lot of unfinished, feature incomplete stuff in >> history... >> >> Nobody can't say I'm for shipping broken stuff - for release, updates etc... >> I'm usually the one who says no for incomplete/broken stuff ;-) >> >> But please stop this. What I wanted to point out is that there ARE users out >> there and we should know, WHO are our users. Or we can take a risk and set >> target audience so we would know it or we can be all-catch distro but then we >> have to behave like we are all-catch... In this case you know - we need >> compromise... >> > > We get the users we aim for. > > The issue at hand is the type of users we want to aim for. > > Here's the camps I see: > > 1. One group wants us to aim for mom/pop/grandma/desktop users - the > apple market or what ubuntu aims for. > > 2. one group wants us to aim exclusively for the bleeding edge open > source developer market. > > 3. one group wants us to aim for the admin/experienced user who wants > newer things but doesn't have time nor interest to fight with lots of broken > things. Mind telling why those are mutually exclusive ? Why does an operation system that is easy to use (1.) have to be broken (3.) or only contain outdated stuff (3., 2.). Even if people disagree with this we do NOT need a specific target audience, selecting a specific group of users and telling others "go away" is nothing but failure on our side. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes for 2010-03-09 FESCo meeting
On Wednesday, 10 March 2010 at 16:22, Matthias Clasen wrote: > On Wed, 2010-03-10 at 13:08 +0100, Till Maas wrote: > > > Afaics this does not affect some minor issue, but a fundamental reason > > why package maintainer decided to become Fedora package maintainers. > > No volunteer package maintainer is in general forced to create updates > > and I am very sure that the volunteer package maintainers usually do not > > create updates that they do not want to use. So if you forbid package > > maintainers to package the version they want or need to use, being a > > fedora package maintainer becomes pretty useless for them. > > I really think we want to have package maintainers whose motivation is a > bit stronger than 'I use this myself, so, meh, why not package it'. Why is that not motivation enough? Why wouldn't we want to have this kind of people on board (assuming they follow the packaging guidelines and what not)? Packaging isn't rocket science. In fact, my motivation for packaging lots of stuff was: "Hmm, my colleagues use this and they use Fedora so why not package it and save them the effort?" In return, I ask them to test new releases. Even if they don't have time to use bodhi, their feedback is still most valuable. As Tom wrote on FAB list, the real problem is making it easier for users to give feedback on updates. Only after we've solved that can we start thinking of imposing restrictions on package maintainers wrt updates. > At > least for packages that are part of the default install, I would expect > at least some awareness on the part of the packager that the work he is > doing needs to fit into the larger whole which is the released product. Agreed. However, we should ask ourselves if it's better to have a package in our distribution even if it doesn't fit ideally with the rest or not to have it at all? I prefer the latter. Someone might step up as co-maintainer and help. Starting from scratch is usually more difficult. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 Alpha - Zarafa
On 03/09/2010 05:23 PM, nodata wrote: > Does Zimbra still ship as a blob of specific versions of lots of open > source software, of which the specific versions cannot be changed? Also, the last time I looked, it had a bundled copy of the Sun JDK (not the open sourced one either). ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
