Re: libpng: Multilib update conflict
Till Maas wrote: > there is a -1 karma comment claiming that libpng is broken, because the > new x86_64 package conflicts with the old i686 package: That's one of those many invalid -1 comments (and yet another reason why karma is broken). You cannot mix different builds of the same package for different multilib arches, it will always result in such file conflicts. This is completely normal and you are not expected to fix this. The user should be upgrading both arches of the package at the same time (or removing the 32-bit multilib if it's not needed). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100317 changes
Till Maas wrote: > These requirements render the karma automatism useless for all branches > except F13, because the fedora-packager package in F12 was iirc pushed > automatically after it received enough testing. If this implies, that > that the package should also be pushed in F13, then this should happen > automatically, too. Automatic default behaviour that leads to failure > should not exist. Karma automatism is completely broken and useless, how's that news? It's quite sad that the rest of FESCo wants to rely on such brokenness even more in the future (with me being the only one who refused to vote for such a broken plan which just smells of failure). Numeric karma should be abolished entirely, not made a requirement for anything. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100317 changes
Thomas Spura wrote: > Why testing? > > A "maybe-broken update" is better than a "non-working programm" isn't > it? +1, broken dependency fixes should go stable ASAP. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100317 changes
Jesse Keating wrote: > We do separate testing per release, because each release is different. > Different library sets, different kernels, glibc, some different desktop > environments, etc... Assuming that testing on one release means that > it'll work on other releases is grossly irresponsible. In practice it's almost always true, with really extremely rare exceptions, which are not worth headaches such as broken upgrade paths. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100317 changes
Till Maas wrote: > It would be enough to only push the update that got enough testing and > all updates in newer releases to keep the upgrade path. Yes. Pushing stuff to older releases later does not break upgrade paths, it just annoys and confuses folks. Pushing stuff to older releases first is what's really broken and what happened here. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFE] Few additions to Bodhi
Thomas Spura wrote: > KPackageKit != Bodhi: > > When you use fedora-easy-karma or the updates site to provide testing > feedback, it would be nice to have such a %changelog field, *expecially* > if there are no updates notes shipped with the package. In this case it > would be absolutely nessesary to have at least the changelog as notes > there (if not getting the extra field). On https://admin.fedoraproject.org/updates/ , there's a Builds: field for each update, click on one of the builds to get to its Koji build page which also contains changelog info. Changelog info is per SRPM, not per update group, so it can't really be done any faster, you need to select the SRPM you want to view updates for. (You'll notice that for grouped updates, the PackageKit frontends will display different changelogs depending on which package from the group you're viewing the details for.) As for fedora-easy-karma, the script just needs to add the required Koji or yum/repoquery queries, that doesn't have to be done on the server end at all. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal
Terry Barnaby wrote: > Although I understand Fedora's frontier status, I think the graphics > system changes could probably have been handled better. After the kernel > and core shared libraries the graphics system is probably the next > essential core OS subsystem (At least for desktop systems). It seems most > of peoples stability issues with fedora stem from graphics. I do > understand the difficulty with the multitude of different graphics > chipsets out there. But this is where Fedora could shine with its close > links to upstream development. It would have been good to be very upfront > with this and get a group to define and setup some basic graphics tests > and loudly promote users to perform tests with these both pre-release and > post-release. This with a website with test status versus graphics > board/chipsets and with good easy linkages to Bugzilla (more user > friendly) and perhaps a separate graphics-testing repository to keep quick > graphics updates away from the "stable" release etc. If enough upstream > developers, Fedora packagers and testing users were in on this I think > great inroads into getting stable and good graphics systems would be made > in a relatively short time. Unfortunately, a sizeable portion of our users installs some crappy proprietary driver, sometimes not even a properly packaged one, but using some broken installation script directly from the hardware vendor's website, making this all moot. :-( While it is true that our Free drivers are far from perfect as well, most graphics-related problems are actually due to proprietary drivers. Just say NO to proprietary drivers! (And in fact this is one of the reasons why our drivers are a bit on the experimental side, it's needed to get support for as much hardware as possible with our Free drivers, e.g. there's now experimental 3D support for Nouveau in F13.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, 16.03.10 10:54, Matthias Clasen (mcla...@redhat.com) wrote: > > > Symlinks are duct-tape, why not just set it to /tmp with > > > global rc file? > > > > Sure, but still need to encode username into the filename (or > > randomize/uniq > > it) somehow. > > > > Any reason this cannot be an abstract socket ? Of course, then you have > to check peer creds and figure out a way to communicate the socket name, > but at least you don't have to worry about the usual races and > permission problem you have with unix sockets. Abstract sockets are not particularly useful for anything but system services that are only started once, and very early during bootup. Why? because they are not namespaced: every user can take every name he wants. If a system service that is restartable or started late at bootup needs a specific name then some evil user might already have taken it away, creating a DoS situation. As soon as a system is booted up to a level where non-system users can login abstract namespace sockets must use randomized names, to avoid these DoS issues. And a reference to those names would probably be have to be written to the file system, so that it can be found by other applications. And as soon as that happens, most advantages of sockets that don't live in the fs hierarchy are gone. Abstract sockets are a tool that is only really useful during early boot. For everything else I don't think it really has any advantages over fs sockets. However, they are harder to discover, which sucks. In summary: unless you hack very low-level Linux-specific software forget about abstract sockets. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, 16.03.10 08:38, Rex Dieter (rdie...@math.unl.edu) wrote: > > Juha Tuomala wrote: > > > https://bugs.kde.org/show_bug.cgi?id=179006#c5 > >> in the current version of Akonadi server you can specify a custom > >> socket path by entering > >> > >> [Connection] > >> SocketDirectory=/tmp/akonadi-myuser/ > >> > >> into $HOME/.config/akonadi/akonadiserverrc > > > > How about setting that as default, away from $HOME that can be a NFS > > filesystem? > > Indeed, a solution similar to kde's > ~/.kde/socket- => /tmp/ksocket- > symlink is likely needed here too. If KDE really does this, it is really broken. is unsuitable for use cases like this, since on many Fedora/RH systems it is just "localhost". And then very often it is highly dynamic, sometimes even changing with DHCP. If you want to identify a machine, use the D-Bus machine id. If you don't want to link against the libdbus libraries (which you probably should), then at least read /var/lib/dbus/machine-id and use that (possibly with a fallback to the hostname, in case the admin is a nut). The dbus machine id is the only suitable ID for usecases like this: it is static, bound to the installation, and widely available. In addition to this is unsuitable for use cases like this too, since it opens the door to DoS attacks by other users since they can guess you socket path and create the socket and hence make it impossible for you to use it. If you want to do this properly, do something like this: ~/.kde/socket- → /tmp/ksocket-/socket Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, 16.03.10 14:52, Juha Tuomala (juha.tuom...@iki.fi) wrote: > > > [Connection] > > SocketDirectory=/tmp/akonadi-myuser/ > > > > into $HOME/.config/akonadi/akonadiserverrc > > How about setting that as default, away from $HOME that can be a NFS > filesystem? I have had problems with it sometimes and that's > probably not a rare case. That is a security hole. Since /tmp knows no further access control an evil user can just create dirs there for each and every single user on the system. Those directories will then be owned by him, and all other users will a) either completely fail to work or b) happily connect to the evil user's services unless the software in question implements two-way credential passing and verification (which I'd bet akonadi doesn't do). So either this is a DoS vulnerability or an even worse security hole. So in short: don't do this. If you safely want to place a socket in /tmp, you need to place it in a random dir, and then symlink (or otherwise refer to it) from $HOME. Or better (as Colin suggested), just use D-Bus to pass around the randomized socket path. (or even better: use the new fd passing in D-Bus so that you don't need to socket path at all) Or even shorter: Unix sucks. At last year's FOSS.in I did a talk about issues like this in Unix and how to work around them in application and how incredibly hard it is to get this right. One of those days I hope to find the time to write a blog story about this. I personally believe introducing a per-user /var/run (maybe as /var/run/users/$USER which is created at login time) is cleanest way to fix all of this. > I can't imagine what harm that would cause to default under /tmp? It's a shared namespace. As such it is a major source of vulnerabitilities, especially if the developers didn't have this particular use in mind. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Query re package versions in F-13
When I run yum list extras on my F-13 system, it lists (inter alia) the following: tzdata.noarch 2010e-1.fc13@updates-testing tzdata-java.noarch ... The version of tzdata currently in the F-13 repositories is 2010c-1, with nothing in updates-testing, but Bodhi shows that 2010e-1 has been pushed to testing. Has this update somehow been mislaid? Quentin Armitage -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 install timings
> It's an http install to a local server, and there is no access during > that stage (after is has all of the repodata files) until it starts > fetching package headers. So, it seems like filing a bug is in order. > Anaconda or yum? Anaconda, the program that you invoked. If anaconda can pass the blame along to yum, then I'm sure that they will :-) -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for "wipe complete HD" installations
On Fri, Mar 19, 2010 at 09:39:05PM +0100, Till Maas wrote: > On Fri, Mar 19, 2010 at 07:54:09PM +, Richard W.M. Jones wrote: > > > Yes! > > > > Hopefully BIOS support won't be a problem because of gptsync. Can we > > also get gptsync packaged separately, instead of having an odd version > > bundled with Anaconda ... > > A first incomplete Feature page is available here: > https://fedoraproject.org/wiki/Features/GUID_Partition_Table I added a section summarising the issues with gptsync AIUI: https://fedoraproject.org/wiki/Features/GUID_Partition_Table#gptsync Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi error?
Ville Skyttä wrote: > On Friday 19 March 2010, Toshio Kuratomi wrote: > >> On Fri, Mar 19, 2010 at 06:47:44PM +0200, Ville Skyttä wrote: >> >>> On Friday 19 March 2010, Jon Ciesla wrote: >>> ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fed ora/ 13, 500, Unknown HTTP Server Response) This is while creating an update. >>> I got that earlier today too, when the "close bugs" checkbox was ticked. >>> I managed to submit the same update after unticking it. >>> >> I think this is a transient error from packagedb -- if it's repeatable, >> it's something I can take a look at and hopefully fix quickly. Also -- I >> have just deployed a new version of packagedb that fixes one of the >> sources of transient failures. It's possible that it will fix this. >> >> Please let me know if you can get this repeatedly or if it seems to have >> gone away. >> > > I just managed to submit another update with close bugs checked, so maybe > that > wasn't it or it was fixed. Thanks in any case ;) > So did I. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi error?
On Friday 19 March 2010, Toshio Kuratomi wrote: > On Fri, Mar 19, 2010 at 06:47:44PM +0200, Ville Skyttä wrote: > > On Friday 19 March 2010, Jon Ciesla wrote: > > > ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fed > > > ora/ 13, 500, Unknown HTTP Server Response) > > > > > > This is while creating an update. > > > > I got that earlier today too, when the "close bugs" checkbox was ticked. > > I managed to submit the same update after unticking it. > > I think this is a transient error from packagedb -- if it's repeatable, > it's something I can take a look at and hopefully fix quickly. Also -- I > have just deployed a new version of packagedb that fixes one of the > sources of transient failures. It's possible that it will fix this. > > Please let me know if you can get this repeatedly or if it seems to have > gone away. I just managed to submit another update with close bugs checked, so maybe that wasn't it or it was fixed. Thanks in any case ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for "wipe complete HD" installations
On Fri, Mar 19, 2010 at 07:54:09PM +, Richard W.M. Jones wrote: > Yes! > > Hopefully BIOS support won't be a problem because of gptsync. Can we > also get gptsync packaged separately, instead of having an odd version > bundled with Anaconda ... A first incomplete Feature page is available here: https://fedoraproject.org/wiki/Features/GUID_Partition_Table Regards Till pgpjbS1ETkSKd.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 install timings
On 03/19/2010 01:57 PM, John Reiser wrote: >> ... stripped down kickstart server install of about 389 packages: > >> enablefilesystems 3:10s >> postselection24:27s >> installpackages 14:30s > >> The install spends a long time displaying "Checking dependencies in >> packages selected for installation" with no movement of the progress bar. > >> Interestingly a much larger install set on a laptop took only 1:34s in >> postselection. > > Are you sure that the optical drive on the server is OK? Those times for > postselection (tens of minutes) smell like slow hardware [microcode] > recovery for seek errors. > > Transfer the DVD to a USB2.0 flash memory device, boot the netinstall CD > with extra parameter 'askmethod', choose local harddrive, and select the > flash memory partition as the source of the Fedora 13 tree. Postselection > should take less than one minute. > It's an http install to a local server, and there is no access during that stage (after is has all of the repodata files) until it starts fetching package headers. So, it seems like filing a bug is in order. Anaconda or yum? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100317 changes
On Fri, 2010-03-19 at 13:34 -0500, Jeffrey Ollie wrote: > On Fri, Mar 19, 2010 at 1:25 PM, Thomas Spura > wrote: > > > > Why testing? > > > > A "maybe-broken update" is better than a "non-working programm" isn't > > it? > > Because there are a significant number of people that will scream > bloody murder if people push packages directly to stable without > having the package spend at least a little time in testing, no matter > what the reason. There have been enough problems with seemingly > "safe" updates that go directly to stable that I have a hard time > disagreeing with them. Besides, the principle is not in fact correct. Just for instance, an installable package which causes massive data corruption is not better than an uninstallable package... Not saying that's the case here, just pointing out that 'it's uninstallable' is not the worst possible flaw a package can have. -- 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: F13 install timings
> ... stripped down kickstart server install of about 389 packages: > enablefilesystems 3:10s > postselection24:27s > installpackages 14:30s > The install spends a long time displaying "Checking dependencies in > packages selected for installation" with no movement of the progress bar. > Interestingly a much larger install set on a laptop took only 1:34s in > postselection. Are you sure that the optical drive on the server is OK? Those times for postselection (tens of minutes) smell like slow hardware [microcode] recovery for seek errors. Transfer the DVD to a USB2.0 flash memory device, boot the netinstall CD with extra parameter 'askmethod', choose local harddrive, and select the flash memory partition as the source of the Fedora 13 tree. Postselection should take less than one minute. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for "wipe complete HD" installations
On Thu, Mar 18, 2010 at 09:55:37PM +0100, Till Maas wrote: > Hi, > > how about using GPT[0] partitions for F14 for all installations that wipe > the whole disk to install Fedora? It is also considered to be good by > Tejun Heo[1] and it seems to work nicely already on F12. I just > partitioned a new HD using gdisk and the kernel seems to recognise it > without any problems. Yes! Hopefully BIOS support won't be a problem because of gptsync. Can we also get gptsync packaged separately, instead of having an odd version bundled with Anaconda ... 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
New maintainer for Quod Libet
I no longer use Quod Libet on a regular basis and I can't spare the time right now to fix up the issues that the package has. So I'm looking for someone to take over maintainership. I would have released ownership in the package database already but I'm getting an error... -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel bug or coincidence
as I said palimpsest disk utility did not report any thing the smart output is attached smartctl version 5.38 [i386-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.11 Device Model: ST3500320AS Serial Number:6QM0NP93 Firmware Version: SD1A User Capacity:500,107,862,016 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is:Fri Mar 19 21:21:23 2010 EET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 642) seconds. Offline data collection capabilities:(0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities:(0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability:(0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time:( 1) minutes. Extended self-test routine recommended polling time:( 119) minutes. Conveyance self-test routine recommended polling time:( 2) minutes. SCT capabilities: (0x103b) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 118 099 006Pre-fail Always - 172966470 3 Spin_Up_Time0x0003 095 094 000Pre-fail Always - 0 4 Start_Stop_Count0x0032 100 100 020Old_age Always - 635 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 077 060 030Pre-fail Always - 52651756 9 Power_On_Hours 0x0032 097 097 000Old_age Always - 3464 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020Old_age Always - 635 184 Unknown_Attribute 0x0032 100 100 099Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000Old_age Always - 0 188 Unknown_Attribute 0x0032 100 094 000Old_age Always - 38655296524 189 High_Fly_Writes 0x003a 084 084 000Old_age Always - 16 190 Airflow_Temperature_Cel 0x0022 070 056 045Old_age Always - 30 (Lifetime Min/Max 16/30) 194 Temperature_Celsius 0x0022 030 044 000Old_age Always - 30 (0 7 0 0) 195 Hardware_ECC_Recovered 0x001a 038 021 000Old_age Always - 172966470 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 0 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always - 95 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_DescriptionStatus Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 3456 - # 2 Short offline Completed without error 00% 241 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MA
Re: kernel bug or coincidence
it happens with both kernels but it hanged completely with the newer one, and it freeze for seconds and then respond with the older one at least is what happened so far. is there a way that I know it's not a hardware issue on my HDD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usb_modeswitch by default
On 03/19/2010 04:26 PM, Gianluca Sforna wrote: > > Just to be sure: do this mean users with those dongles should have a > "works out of the box" experience with NetworkManager in F13? > > I don't know that. I believe it requires NM/ModemManager changes but atleast it would be easier to do the manual configuration if that is still required. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi error?
Luke Macken wrote: > On Fri, Mar 19, 2010 at 06:47:44PM +0200, Ville Skyttä wrote: > >> On Friday 19 March 2010, Jon Ciesla wrote: >> >>> ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fedora/ >>> 13, 500, Unknown HTTP Server Response) >>> >>> This is while creating an update. >>> >> I got that earlier today too, when the "close bugs" checkbox was ticked. I >> managed to submit the same update after unticking it. >> > > If you try again, it will most likely work. > > These sporadic errors are probably due to the FAS identity provider/ > visit manager that our TurboGears apps use. However, the pkgdb isn't > logging tracebacks properly, so we really don't know exactly where > it is coming from, though I assume it's pycurl throwing an error while > trying to connect to FAS. > > luke > I already submitted mine without the box checked, but I'll keep an eye out. Thanks! -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi error?
Toshio Kuratomi wrote: > On Fri, Mar 19, 2010 at 06:47:44PM +0200, Ville Skyttä wrote: > >> On Friday 19 March 2010, Jon Ciesla wrote: >> >>> ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fedora/ >>> 13, 500, Unknown HTTP Server Response) >>> >>> This is while creating an update. >>> >> I got that earlier today too, when the "close bugs" checkbox was ticked. I >> managed to submit the same update after unticking it. >> >> > I think this is a transient error from packagedb -- if it's repeatable, it's > something I can take a look at and hopefully fix quickly. Also -- I have > just deployed a new version of packagedb that fixes one of the sources of > transient failures. It's possible that it will fix this. > > Please let me know if you can get this repeatedly or if it seems to have > gone away. > > -Toshio > I will, thanks! -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100317 changes
On Fri, Mar 19, 2010 at 1:25 PM, Thomas Spura wrote: > > Why testing? > > A "maybe-broken update" is better than a "non-working programm" isn't > it? Because there are a significant number of people that will scream bloody murder if people push packages directly to stable without having the package spend at least a little time in testing, no matter what the reason. There have been enough problems with seemingly "safe" updates that go directly to stable that I have a hard time disagreeing with them. -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi error?
On Fri, Mar 19, 2010 at 06:47:44PM +0200, Ville Skyttä wrote: > On Friday 19 March 2010, Jon Ciesla wrote: > > ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fedora/ > > 13, 500, Unknown HTTP Server Response) > > > > This is while creating an update. > > I got that earlier today too, when the "close bugs" checkbox was ticked. I > managed to submit the same update after unticking it. If you try again, it will most likely work. These sporadic errors are probably due to the FAS identity provider/ visit manager that our TurboGears apps use. However, the pkgdb isn't logging tracebacks properly, so we really don't know exactly where it is coming from, though I assume it's pycurl throwing an error while trying to connect to FAS. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-13 Branched report: 20100317 changes
Am Donnerstag, den 18.03.2010, 23:30 +0530 schrieb Rakesh Pandit: > On 18 March 2010 00:19, Branched Report wrote: > > Compose started at Wed Mar 17 09:15:24 UTC 2010 > > > >linphone-2.1.1-4.fc12.i686 requires libortp.so.7 > > Thanks Quentin for looking into this and Jesse for importing. I have > filled up bodhi update and requested for testing. Why testing? A "maybe-broken update" is better than a "non-working programm" isn't it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi error?
On Fri, Mar 19, 2010 at 06:47:44PM +0200, Ville Skyttä wrote: > On Friday 19 March 2010, Jon Ciesla wrote: > > ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fedora/ > > 13, 500, Unknown HTTP Server Response) > > > > This is while creating an update. > > I got that earlier today too, when the "close bugs" checkbox was ticked. I > managed to submit the same update after unticking it. > I think this is a transient error from packagedb -- if it's repeatable, it's something I can take a look at and hopefully fix quickly. Also -- I have just deployed a new version of packagedb that fixes one of the sources of transient failures. It's possible that it will fix this. Please let me know if you can get this repeatedly or if it seems to have gone away. -Toshio pgpwyTf4jwfIT.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for "wipe complete HD" installations
Am 19.03.10 17:52, schrieb Jesse Keating: > Why deal with two different types of partitioning tables? Why /not/ go > forward to GPT, I think that's the more appropriate question. > > No all operating systems are able to support GPT, so there may be nice to have a hybrid partition schema. Aspecial if you want a tripple boot system on a Macaintosh system, there will be nice to have this feature, because you can only have four partition in the MBR, which may be assigned as follow: Partitiona #1EFI system partition Partition #2:Mac OX X Partition #3:Linux Partition #4:Windows Anyone in the future we may not have this discussion because all computer have moved to a UEFI systen caused by the 2 TB limitation of the MBR partition schea, but now we have the issue, that we have to support OS which are unable to support GPT partition hard discs. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100319 changes
Compose started at Fri Mar 19 09:15:32 UTC 2010 Broken deps for i386 -- doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 Broken deps for x86_64 -- doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 doodle-0.6.7-5.fc12.x86_64 requires libextractor.so.1()(64bit) hornsey-1.5.2-0.1.fc13.x86_64 requires libclutter-gst-0.10.so.0()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) pyclutter-gst-0.9.2-1.fc12.x86_64 requires libclutter-gst-0.10.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package dcap Client Tools for dCache New package dogtag-pki Dogtag Public Key Infrastructure (PKI) Suite New package perl-Config-INI-MVP Multi-value capable .ini file reader (for plugins) Updated Packages: bash-completion-1.1-6.fc13 -- * Thu Mar 11 2010 Todd Zullinger - 1:1.1-6 - Apply upstream post 1.1 service argument fix (#572794). comix-4.0.4-3.fc13 -- * Thu Mar 18 2010 Mamoru Tasaka - 4.0.4-3 - Handle the error when the media where opened archive existed is removed (bug 542752, 34) - Handle some error cases in comicthumb (bug 568167, 572434) - Remove macros no longer used, spec file cleanup - GConf2 scriptlets update conexus-0.9.1-1.fc13 * Mon Mar 08 2010 Rick L Vinyard Jr - 0.9.1-1 - New release - Removed openssl patch since it is now incorporated upstream control-center-2.29.92-1.fc13 - * Tue Mar 09 2010 Bastien Nocera 2.29.92-1 - Update to 2.29.92 cpio-2.10-6.fc13 * Wed Mar 10 2010 Ondrej Vasik 2.10-6 - CVE-2010-0624 fix heap-based buffer overflow by expanding a specially-crafted archive(#572150) dovecot-1.2.11-2.fc13 - * Fri Mar 12 2010 Michal Hlavinka - 1:1.2.11-2 - fix missing bzip2 support in zlib plugin (#572797) * Tue Mar 09 2010 Michal Hlavinka - 1:1.2.11-1 - updated to 1.2.11 - mbox: Message header reading was unnecessarily slow. Fetching a huge header could have resulted in Dovecot eating a lot of CPU. Also searching messages was much slower than necessary. - maildir: Reading uidlist could have ended up in an infinite loop. - IMAP IDLE: v1.2.7+ caused extra load by checking changes every 0.5 seconds after a change had occurred in mailbox dpkg-1.15.5.6-4.fc13 * Thu Mar 11 2010 Andrew Colin Kissa - 1.15.5.6-4 - Fix CVE-2010-0396 dvb-apps-1.1.1-21.fc13 -- * Tue Mar 16 2010 Ville Skyttä - 1.1.1-21 - Apply upstream patch to add tzap AUTO param support (#574112, AUDU Jerome). - Update tuning files to 20100316. e2fsprogs-1.41.10-6.fc13 * Mon Mar 15 2010 Eric Sandeen 1.41.10-6 - Completely drop the misalignment question in mkfs (#573643) easystroke-0.5.3-1.fc13 --- * Wed Mar 17 2010 Tom "spot" Callaway - 0.5.3-1 - update to 0.5.3 - drop timing patch (upstreamed) - add patch to fix indirect linking issue * Fri Jan 22 2010 Rahul Sundaram - 0.5.2-2 - Rebuild for Boost soname bump ecl-10.3.1-1.fc13 - * Tue Mar 09 2010 Jerry James - 10.3.1-1 - New release 10.3.1 evince-2.29.92-1.fc13 - * Thu Mar 11 2010 Matthias Clasen - 2.29.92-1 - Update to 2.29.92 * Wed Mar 10 2010 Marek Kasik - 2.29.91-3 - Replace deprecated gtk functions with their equivalents - Remove unused patches * Tue Mar 09 2010 Marek Kasik - 2.29.91-2 - Use Type 1 fonts when viewing DVI files - Use correct name when the font is mapped - Related: #562648 fcoe-utils-1.0.12-1.fc13 * Tue Mar 16 2010 Jan Zeleny - 1.0.12-1 - rebased to version 1.0.12, improved functionality with lldpad and dcbd - removed fcoeplumb script from /etc/fcoe/scripts fedora-easy-karma-0-0.5.20100315gitacf8b834.fc13 * Mon Mar 15 2010 Till Maas - 0-0.5.20100315gitacf8b834 - Update to new snapshot * Mon Mar 08 2010 Till Maas - 0-0.4.20100308git1d2e3a85 - Update to new snapshot - Set useragent flashrom-0.9.1-3.svn931.fc13 * Fri Mar 12 2010 Peter Lemenkov 0.9.1-3.svn931 - Updated to latest svn ver. 931 - ASUS A7V8X-X board - MS-7202 board - Asus M2NBP-VM CSM board - HP Vectra VL420SFF board - Eon EN29F010 chip - Abit IP35 Pro board - HP Vectra VL400 board - Intel E28F004S5 flash chip - Lots of bugfixes gajim-0.13.3-3.fc13 --- * Mon Mar 15 2010 Michal Schmidt 0.13.3-3 - What the trayicon
Re: Potential F14 feature: Use GPT partition table by default for "wipe complete HD" installations
On Fri, 2010-03-19 at 13:04 +, David Woodhouse wrote: > Are there any good reasons to do this _other_ than so we can cope with > larger disks? > > How about doing it only for disks which are too large to cope with the > DOS-style partition tables? > > Why deal with two different types of partitioning tables? Why /not/ go forward to GPT, I think that's the more appropriate question. -- 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: Bodhi error?
On Friday 19 March 2010, Jon Ciesla wrote: > ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fedora/ > 13, 500, Unknown HTTP Server Response) > > This is while creating an update. I got that earlier today too, when the "close bugs" checkbox was ticked. I managed to submit the same update after unticking it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F13 install timings
I don't know if it is too early to do install timings (due to debugging be on in the kernel, elsewhere?) but here are the longest steps from a fairly stripped down kickstart server install of about 389 packages: F-13: enablefilesystems 3:10s postselection24:27s installpackages 14:30s F-12: enablefilesystems 2:50s postselection36:45s installpackages 11:36s (probably had more packages in our local cache) The install spends a long time displaying "Checking dependencies in packages selected for installation" with no movement of the progress bar. Any way this could get sped up more (good job going from 36m to 24m) and progress shown? Interestingly a much larger install set on a laptop took only 1:34s in postselection. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging printing problems
On Thu, 2010-03-18 at 21:37 +0100, Louis Lagendijk wrote: > great info indeed. Maybe you could consider adding info on the bjnp > backend (for Canon's proprietary network (usb-over-ip) protocol: > > bjnp is for Canon's proprietary bjnp network protocol (usually port > 8611) > > The bjp backend is available in the cups-bjnp package Feel free to edit the wiki, although perhaps that ought to go on the main Printing page. I've added it there now: https://fedoraproject.org/wiki/Printing Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-DBIx-Class/devel auto.ini,1.3,1.4
Author: cweyl Update of /cvs/extras/rpms/perl-DBIx-Class/devel In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv8120 Modified Files: auto.ini Log Message: * Fri Mar 19 2010 Chris Weyl 0.08120-3 - quiet our repo/dep-checking scripts as we figure out how to handle no_index from a "requires" perspective Index: auto.ini === RCS file: /cvs/extras/rpms/perl-DBIx-Class/devel/auto.ini,v retrieving revision 1.3 retrieving revision 1.4 diff -u -p -r1.3 -r1.4 --- auto.ini17 Mar 2010 16:32:28 - 1.3 +++ auto.ini19 Mar 2010 15:58:32 - 1.4 @@ -9,3 +9,4 @@ perl(Test::Moose)=0 ; Note that maintainertool automatically generates filter macro statements for ; packages/directories marked as "no_index" in META.yml. filter_from_requires=/^perl(DBD::Pg)$/d +filter_from_requires=/^perl(DBIx::Class::\(Admin\|CDBICompat\|ClassResolver\|Storage\)/d -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-DBIx-Class/devel perl-DBIx-Class.spec,1.26,1.27
Author: cweyl
Update of /cvs/extras/rpms/perl-DBIx-Class/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv7878
Modified Files:
perl-DBIx-Class.spec
Log Message:
* Fri Mar 19 2010 Chris Weyl 0.08120-3
- quiet our repo/dep-checking scripts as we figure out how to handle no_index
from a "requires" perspective
Index: perl-DBIx-Class.spec
===
RCS file: /cvs/extras/rpms/perl-DBIx-Class/devel/perl-DBIx-Class.spec,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -p -r1.26 -r1.27
--- perl-DBIx-Class.spec17 Mar 2010 16:34:21 - 1.26
+++ perl-DBIx-Class.spec19 Mar 2010 15:57:56 - 1.27
@@ -1,7 +1,7 @@
Name: perl-DBIx-Class
Summary:Extensible and flexible object <-> relational mapper
Version:0.08120
-Release:2%{?dist}
+Release:3%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/R/RI/RIBASUSHI/DBIx-Class-%{version}.tar.gz
@@ -85,6 +85,7 @@ BuildRequires: perl(namespace::clean) >=
%{?filter_from_requires: %filter_from_requires /^perl(DBD::Pg)$/d }
%{?perl_default_filter:
+%filter_from_requires
/^perl(DBIx::Class::\(Admin\|CDBICompat\|ClassResolver\|Storage\)/d
%filter_provides_in %{perl_vendorlib}/DBIx/Class/Admin
%filter_requires_in %{perl_vendorlib}/DBIx/Class/Admin
%filter_provides_in %{perl_vendorlib}/DBIx/Class/CDBICompat
@@ -158,6 +159,10 @@ rm -rf %{buildroot}
%changelog
+* Fri Mar 19 2010 Chris Weyl 0.08120-3
+- quiet our repo/dep-checking scripts as we figure out how to handle no_index
+ from a "requires" perspective
+
* Wed Mar 17 2010 Chris Weyl 0.08120-2
- update F::A::MT so bits marked as "no_index" are filtered both for provides
_and_ requires
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Bodhi error?
ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fedora/13, 500, Unknown HTTP Server Response) This is while creating an update. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On Fri, Mar 19, 2010 at 10:25:38AM -0400, Ric Wheeler wrote: > I should have asked - do you have the details captured in bugzilla? If so, > that > will be useful to help kick off the discussion with them. It seemed to be common knowledge already, but I just created a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=575143 Regards Till pgpnWwPDsAwPy.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 03/19/2010 10:04 AM, Till Maas wrote: > On Fri, Mar 19, 2010 at 09:56:10AM -0400, Ric Wheeler wrote: > >> We are currently working to verify that storage devices work properly& >> report >> the information that they want us to use (doing this with several storage >> providers and have also raised this with EMC/VMware). > >> If we see real world issues during this testing, we can start thinking about >> how >> to fix it. > > This is good, but it already failed with Western Digital afaik. I > somewhere read that they did it correctly with test drives but now the > released drives do not report their sizes properly, so there are already > real world issues. It was mentioned on this thread I and have a WD20EARS > that shows this problem, too. > > Regards > Till > I should have asked - do you have the details captured in bugzilla? If so, that will be useful to help kick off the discussion with them. Thanks! Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 03/19/2010 10:04 AM, Till Maas wrote: > On Fri, Mar 19, 2010 at 09:56:10AM -0400, Ric Wheeler wrote: > >> We are currently working to verify that storage devices work properly& >> report >> the information that they want us to use (doing this with several storage >> providers and have also raised this with EMC/VMware). > >> If we see real world issues during this testing, we can start thinking about >> how >> to fix it. > > This is good, but it already failed with Western Digital afaik. I > somewhere read that they did it correctly with test drives but now the > released drives do not report their sizes properly, so there are already > real world issues. It was mentioned on this thread I and have a WD20EARS > that shows this problem, too. > > Regards > Till > We should follow up with them and see if we can help them fix their devices... ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: first reviews for "dual packages"
- "Paul Howarth" wrote: > On 16/03/10 16:33, Iain Arnell wrote: > > On Tue, Mar 16, 2010 at 5:17 PM, Marcela > Maslanova wrote: > >> - "Iain Arnell" wrote: > >>> I > >>> guess perl.spec needs a little more work up front to split as much > as > >>> possible into separate sub-packages. > >> > >> Ok, but in this case we need for almost every provides a > sub-package. > >> Wouldn't be sufficient to check perl.spec and create sub-package > after > >> the separated module will be needed? > > > > That would also work, of course. But should be mentioned in the > guidelines too. > > Wouldn't this approach mean that the main perl package needed to be > updated whenever a new updated module was needed, which was one of the > > things this scheme was trying to avoid? > > Paul. > -- > Fedora Extras Perl SIG > http://www.fedoraproject.org/wiki/Extras/SIGs/Perl > perl-devel mailing list > perl-de...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/perl-devel So, test with Getopt::Long showed that there would be conflicting man-pages. I don't think create sub-package for all modules is possible. Also this doesn't help readability of specfile. These "smaller" modules can be updated once a time in main package. People usually want updates only of those modules which already have sub-package. I'm not saying that's the best solution... Any other better ideas? -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Hard drive spec change
On Fri, Mar 19, 2010 at 09:56:10AM -0400, Ric Wheeler wrote: > We are currently working to verify that storage devices work properly & > report > the information that they want us to use (doing this with several storage > providers and have also raised this with EMC/VMware). > If we see real world issues during this testing, we can start thinking about > how > to fix it. This is good, but it already failed with Western Digital afaik. I somewhere read that they did it correctly with test drives but now the released drives do not report their sizes properly, so there are already real world issues. It was mentioned on this thread I and have a WD20EARS that shows this problem, too. Regards Till pgpd1sn5UyTmK.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100319 changes
Compose started at Fri Mar 19 08:15:18 UTC 2010 Broken deps for i386 -- edje-0.9.93.063-1.fc14.i686 requires libembryo-ver-svn-05.so.0 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 murmur-1.1.8-15.fc12.i686 requires libIce.so.33 murmur-1.1.8-15.fc12.i686 requires libIceUtil.so.33 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 perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::ClassResolver::PassThrough) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Admin) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Admin::Descriptive) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Storage::DBI::Replicated::Types) php-pecl-imagick-2.2.2-4.fc12.i686 requires libMagickWand.so.2 php-pecl-imagick-2.2.2-4.fc12.i686 requires libMagickCore.so.2
[Bug 568172] virt-top exits sometimes when the window is resized
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=568172 Suzanne Yeghiayan changed: What|Removed |Added CC||syegh...@redhat.com Fixed In Version||libvirt-0.7.8.el6 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Hard drive spec change
On 03/19/2010 09:39 AM, Till Maas wrote: > On Fri, Mar 19, 2010 at 09:21:53AM -0400, Ric Wheeler wrote: >> On 03/19/2010 08:08 AM, Till Maas wrote: >>> On Thu, Mar 11, 2010 at 04:21:47PM -0600, Eric Sandeen wrote: Alexander Boström wrote: > ons 2010-03-10 klockan 15:57 -0600 skrev Eric Sandeen: > >> There has been a lot of work upstream on 4k sector support, and in >> general >> yes, we are ready. > > Problems can probably be expected in case the drive does not report its > real block size to the software, though, like my WD15EARS (I think) or > VMware's emulated SCSI drives. There's only so much we can do in the face of bad hardware ;) >>> >>> How about making it possible to overwrite the wrong reported values, >>> e.g. by making /sys/block/sdb/queue/[physical_block_size >>> writable,minimum_io_size} writable. > >> I think that would be a bad idea - if you know what you want to change, why >> not >> just invoke the tool with those specific parameters? > > It would not be that annoying, if it was only one tool. But there are > e.g. at least fdisk, mdadm, lvm, cryptsetup and mkfs.*/mkswap that all > have to properly align the data. > >> It would be very confusing to have us probe the device, get the real >> information >> from the storage device and then let a user update that information to >> something >> "false" :-) > > So add some interface to query whether the information was probed or set > by a user. Then it should not be that confusing. :-) > > Regards > Till > We are currently working to verify that storage devices work properly & report the information that they want us to use (doing this with several storage providers and have also raised this with EMC/VMware). Specifically for vmware, I think that our default will be good for them when a device fails to report. Specifically, their own tech report suggests using a non-default alignment (sector 128 iirc?). We can certainly work to verify this with them. If we see real world issues during this testing, we can start thinking about how to fix it. thanks! ric ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal
On 03/18/2010 09:00 PM, Adam Williamson wrote: > . > That's somewhat optimistic; no matter how much testing we do, we can > only afford a certain amount of full-time developer muscle. The testing > has helped to improve efficiency and direction of graphics development > work, I think, but there's fundamentally a lot of work to do and only a > limited amount of manpower to do it with. > > The X devs are always very happy to take new volunteers. :) Although I have done a fair amount of X development work in the past, unfortunately, as with most people, my volunteer time is in short supply (I have a wife and kids to support :) ). So "in use" testing, bug reporting and attempting the first pass bug searches is currently my limit in Fedora. If there were less churn in Fedora to cope with perhaps I and other user/developers would have more unpaid volunteer time to devote to actual development :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-DBIx-Class
perl-DBIx-Class has broken dependencies in the rawhide tree: On x86_64: perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::ClassResolver::PassThrough) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Admin) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Admin::Descriptive) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Storage::DBI::Replicated::Types) On i386: perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::ClassResolver::PassThrough) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Admin) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Admin::Descriptive) perl-DBIx-Class-0.08120-2.fc14.noarch requires perl(DBIx::Class::Storage::DBI::Replicated::Types) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Hard drive spec change
On Fri, Mar 19, 2010 at 09:21:53AM -0400, Ric Wheeler wrote: > On 03/19/2010 08:08 AM, Till Maas wrote: > > On Thu, Mar 11, 2010 at 04:21:47PM -0600, Eric Sandeen wrote: > >> Alexander Boström wrote: > >>> ons 2010-03-10 klockan 15:57 -0600 skrev Eric Sandeen: > >>> > There has been a lot of work upstream on 4k sector support, and in > general > yes, we are ready. > >>> > >>> Problems can probably be expected in case the drive does not report its > >>> real block size to the software, though, like my WD15EARS (I think) or > >>> VMware's emulated SCSI drives. > >> > >> There's only so much we can do in the face of bad hardware ;) > > > > How about making it possible to overwrite the wrong reported values, > > e.g. by making /sys/block/sdb/queue/[physical_block_size > > writable,minimum_io_size} writable. > I think that would be a bad idea - if you know what you want to change, why > not > just invoke the tool with those specific parameters? It would not be that annoying, if it was only one tool. But there are e.g. at least fdisk, mdadm, lvm, cryptsetup and mkfs.*/mkswap that all have to properly align the data. > It would be very confusing to have us probe the device, get the real > information > from the storage device and then let a user update that information to > something > "false" :-) So add some interface to query whether the information was probed or set by a user. Then it should not be that confusing. :-) Regards Till pgpV3NtV4yy1y.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel bug or coincidence
On 03/19/2010 03:07 PM, Muayyad AlSadi wrote: > my dmesg is attached > Thanks; if this doesn't occur with the previous version of the kernel, file a bug in bugzilla.redhat.com and paste the link to the bug. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for "wipe complete HD" installations
On Fri, Mar 19, 2010 at 01:04:29PM +, David Woodhouse wrote: > On Thu, 2010-03-18 at 21:55 +0100, Till Maas wrote: > > how about using GPT[0] partitions for F14 for all installations that wipe > > the whole disk to install Fedora? It is also considered to be good by > > Tejun Heo[1] and it seems to work nicely already on F12. I just > > partitioned a new HD using gdisk and the kernel seems to recognise it > > without any problems. > > Are there any good reasons to do this _other_ than so we can cope with > larger disks? Afaik it is also required in case one uses EFI instead of a BIOS. Doing this soon would make Fedora ready once it is required. Other nice features are checksums for the partition table and file system independent uuids for the partitions and file system independent clear text names for partitions. These can be used to easier identify partitions that do not contain a file system, e.g. because they are encrypted or they have been wiped. Then they could be easier identified to be used again, e.g. in the installer. > How about doing it only for disks which are too large to cope with the > DOS-style partition tables? For large disks it would be required anyhow. But it does not need to be default, at least support for it in the installer would be nice. Regards Till pgpLj7KHXno2A.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On 03/19/2010 08:08 AM, Till Maas wrote: > On Thu, Mar 11, 2010 at 04:21:47PM -0600, Eric Sandeen wrote: >> Alexander Boström wrote: >>> ons 2010-03-10 klockan 15:57 -0600 skrev Eric Sandeen: >>> There has been a lot of work upstream on 4k sector support, and in general yes, we are ready. >>> >>> Problems can probably be expected in case the drive does not report its >>> real block size to the software, though, like my WD15EARS (I think) or >>> VMware's emulated SCSI drives. >> >> There's only so much we can do in the face of bad hardware ;) > > How about making it possible to overwrite the wrong reported values, > e.g. by making /sys/block/sdb/queue/[physical_block_size > writable,minimum_io_size} writable. > > Regards > Till > I think that would be a bad idea - if you know what you want to change, why not just invoke the tool with those specific parameters? It would be very confusing to have us probe the device, get the real information from the storage device and then let a user update that information to something "false" :-) ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel bug or coincidence
my dmesg is attached dmesg.txt.gz Description: GNU Zip compressed data -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for "wipe complete HD" installations
On Thu, 2010-03-18 at 21:55 +0100, Till Maas wrote: > how about using GPT[0] partitions for F14 for all installations that wipe > the whole disk to install Fedora? It is also considered to be good by > Tejun Heo[1] and it seems to work nicely already on F12. I just > partitioned a new HD using gdisk and the kernel seems to recognise it > without any problems. Are there any good reasons to do this _other_ than so we can cope with larger disks? How about doing it only for disks which are too large to cope with the DOS-style partition tables? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for "wipe complete HD" installations
On Fri, Mar 19, 2010 at 12:22:56PM +0200, Manuel Wolfshant wrote: > Till Maas wrote: > > On Fri, Mar 19, 2010 at 10:34:59AM +0100, Karel Zak wrote: > > I am also pretty sure that a BIOS does not consider the partition table > > to boot, > I can vouch for at least 2 Intel based motherboards which do not boot > unless a) there exists a partition table and b) one partition is marked > as active There still will be a partition table, but it will always show a partition that starts at sector 1. By default it seems not to be marked as active, but this should be possible. This is then the old style partition, that contains the new GPT header and partitions. Regards Till pgp17WgkrZOL9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
On Thu, Mar 11, 2010 at 04:21:47PM -0600, Eric Sandeen wrote: > Alexander Boström wrote: > > ons 2010-03-10 klockan 15:57 -0600 skrev Eric Sandeen: > > > >> There has been a lot of work upstream on 4k sector support, and in general > >> yes, we are ready. > > > > Problems can probably be expected in case the drive does not report its > > real block size to the software, though, like my WD15EARS (I think) or > > VMware's emulated SCSI drives. > > There's only so much we can do in the face of bad hardware ;) How about making it possible to overwrite the wrong reported values, e.g. by making /sys/block/sdb/queue/[physical_block_size writable,minimum_io_size} writable. Regards Till pgphdeK5S3ddA.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFE] Few additions to Bodhi
Am Freitag, den 19.03.2010, 11:33 +0100 schrieb Mathieu Bridon: > On Thu, Mar 18, 2010 at 18:07, Thomas Spura > wrote: > > Am Dienstag, den 16.03.2010, 19:05 +0100 schrieb Kevin Kofler: > >> Peter Lemenkov wrote: > >> > * Automatically add latest %changelog entry to each Bodhi update as > >> > "Notes" or as something else (new field, perhaps). > >> > >> The changelog information is already provided in the update detail > >> metadata, > >> gnome-packagekit displays it as update notes if you don't fill in any > >> actual > >> update notes, KPackageKit even always displays it. > > > > KPackageKit != Bodhi: > > > > When you use fedora-easy-karma or the updates site to provide testing > > feedback, it would be nice to have such a %changelog field, *expecially* > > if there are no updates notes shipped with the package. In this case it > > would be absolutely nessesary to have at least the changelog as notes > > there (if not getting the extra field). > > Or maybe package maintainers could write decent update notes? > > I don't know, maybe that's just a crazy idea... ;) Sure, but they don't have to and so some don't do that... :( And some of them might think, the changelog says enought, so I don't write it there (because that would just be copy&paste). When there are no notes and the changelog is then showing up, then they at least think right... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usb_modeswitch by default
On Fri, Mar 19, 2010 at 9:52 AM, Rahul Sundaram wrote: > On 03/05/2010 02:55 AM, Pete Zaitcev wrote: >> >> OK, that sounds good. So, I withdraw objections after Rahul's question, >> as far as Fedora is concerned. >> > > I have added it to the hardware support group as a default package for > Fedora 13. Just to be sure: do this mean users with those dongles should have a "works out of the box" experience with NetworkManager in F13? -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFE] Few additions to Bodhi
On Thu, Mar 18, 2010 at 18:07, Thomas Spura wrote: > Am Dienstag, den 16.03.2010, 19:05 +0100 schrieb Kevin Kofler: >> Peter Lemenkov wrote: >> > * Automatically add latest %changelog entry to each Bodhi update as >> > "Notes" or as something else (new field, perhaps). >> >> The changelog information is already provided in the update detail metadata, >> gnome-packagekit displays it as update notes if you don't fill in any actual >> update notes, KPackageKit even always displays it. > > KPackageKit != Bodhi: > > When you use fedora-easy-karma or the updates site to provide testing > feedback, it would be nice to have such a %changelog field, *expecially* > if there are no updates notes shipped with the package. In this case it > would be absolutely nessesary to have at least the changelog as notes > there (if not getting the extra field). Or maybe package maintainers could write decent update notes? I don't know, maybe that's just a crazy idea... ;) -- Mathieu Bridon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [RFE] Few additions to Bodhi
Am Dienstag, den 16.03.2010, 19:05 +0100 schrieb Kevin Kofler: > Peter Lemenkov wrote: > > * Automatically add latest %changelog entry to each Bodhi update as > > "Notes" or as something else (new field, perhaps). > > The changelog information is already provided in the update detail metadata, > gnome-packagekit displays it as update notes if you don't fill in any actual > update notes, KPackageKit even always displays it. KPackageKit != Bodhi: When you use fedora-easy-karma or the updates site to provide testing feedback, it would be nice to have such a %changelog field, *expecially* if there are no updates notes shipped with the package. In this case it would be absolutely nessesary to have at least the changelog as notes there (if not getting the extra field). Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for "wipe complete HD" installations
Till Maas wrote: > On Fri, Mar 19, 2010 at 10:34:59AM +0100, Karel Zak wrote: > >> On Thu, Mar 18, 2010 at 11:25:45PM -0500, Matt Domsch wrote: >> >>> On Thu, Mar 18, 2010 at 09:55:37PM +0100, Till Maas wrote: >>> Hi, how about using GPT[0] partitions for F14 for all installations that wipe the whole disk to install Fedora? It is also considered to be good by Tejun Heo[1] and it seems to work nicely already on F12. I just partitioned a new HD using gdisk and the kernel seems to recognise it without any problems. >>> Very few BIOSes can boot from a GPT disk. >>> >> Urban legend... >> > > I am also pretty sure that a BIOS does not consider the partition table > to boot, I can vouch for at least 2 Intel based motherboards which do not boot unless a) there exists a partition table and b) one partition is marked as active however, to be honest, those are OLD mobos and probably not relevant any more -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for "wipe complete HD" installations
On Fri, Mar 19, 2010 at 10:34:59AM +0100, Karel Zak wrote: > On Thu, Mar 18, 2010 at 11:25:45PM -0500, Matt Domsch wrote: > > On Thu, Mar 18, 2010 at 09:55:37PM +0100, Till Maas wrote: > > > Hi, > > > > > > how about using GPT[0] partitions for F14 for all installations that wipe > > > the whole disk to install Fedora? It is also considered to be good by > > > Tejun Heo[1] and it seems to work nicely already on F12. I just > > > partitioned a new HD using gdisk and the kernel seems to recognise it > > > without any problems. > > > > Very few BIOSes can boot from a GPT disk. > > Urban legend... I am also pretty sure that a BIOS does not consider the partition table to boot, because it only needs to access the first 440 (maybe 446) bytes of hard disk, which will not be touched by GPT: http://en.wikipedia.org/wiki/Master_boot_record > > EFI/UEFI can, as can legacy > > BIOS if you do something ugly like gptsync so the MBR partition table > > and the GPT partition table at least somewhat agree. > > The problem is old grub. But the Fedora grub is supposed to support it for a long time: | * Mon Jul 16 2007 Peter Jones - 0.97-15 | - Support booting from GPT Regards Till pgpmZrvh6T7LQ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for "wipe complete HD" installations
> The problem is old grub. To quickly hook into this: wouldn't moving to grub2 be a viable feature for F14 then? I know we wouldn't be the first to do it, but that might be a plus here. The Ubuntu guys have already forced some more wide spread testing of grub2 by implementing it in a recent release. Implementing grub2 might then eventually make implementing GPT in a later phase an option (I am not qualified to state this as a certainty). Or has this all been talked about before and has already been concluded that this is not viable? Maxim Burgerhout ma...@wzzrd.com GPG Fingerprint EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Potential F14 feature: Use GPT partition table by default for "wipe complete HD" installations
On Thu, Mar 18, 2010 at 11:25:45PM -0500, Matt Domsch wrote: > On Thu, Mar 18, 2010 at 09:55:37PM +0100, Till Maas wrote: > > Hi, > > > > how about using GPT[0] partitions for F14 for all installations that wipe > > the whole disk to install Fedora? It is also considered to be good by > > Tejun Heo[1] and it seems to work nicely already on F12. I just > > partitioned a new HD using gdisk and the kernel seems to recognise it > > without any problems. > > Very few BIOSes can boot from a GPT disk. Urban legend... > EFI/UEFI can, as can legacy > BIOS if you do something ugly like gptsync so the MBR partition table > and the GPT partition table at least somewhat agree. The problem is old grub. Karel -- Karel Zak -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usb_modeswitch by default
On 03/05/2010 02:55 AM, Pete Zaitcev wrote: > > OK, that sounds good. So, I withdraw objections after Rahul's question, > as far as Fedora is concerned. > I have added it to the hardware support group as a default package for Fedora 13. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
