Re: PolicyKit changes in F12
On Wed, 2009-05-13 at 21:00 -0400, Matthias Clasen wrote: Just a heads-up: We hope to land a new PolicyKit version (which will turn into 1.0, eventually) in F12 soon. PolicyKit 0.92 has now landed in rawhide; the package name has changed to polkit and polkit-gnome, to allow it to coexist with PolicyKit 0.9 until the transition is completed. David has put a lot of effort into improving the api docs which are included in polkit-devel, which should help in getting the remaining porting done. Matthias -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
heads up: corosynclib soname change and updates plan
Hi all, corosync/openais will soon be released as 1.0 with stable API/ABI. At this point in time, the external library API/ABI should be stable (unless major/critical issues will be found). The internal API/ABI (for plugin) could still change. This is my current update plan: - update rawhide: * corosync/openais need to go in first. * cluster need to be updated too at the same time (I maintain it, so that won't be a problem). * lvm2/qpidc will require at least a rebuild. AFAICT they only use the external shared libraries to access corosync services so they won't be affected by internal plugin API changes. * asterisk should be unaffected by those changes since it uses only openais shared libraries and the API/ABI hasn't changed since F11 (maintainer CC'ed anyway.. better safe than sorry ;)). Once we hit the 1.0 release, and propagate it properly into rawhide, my plans are to update F11 and F10 too. The amount of critical bug fixes in current corosync/openais versions is simply too high to be ignored for updates (even if it will be a bit of a painful process given the number of packages involved). Unless there are strong objections, I'll start building corosync/openais/cluster tomorrow. New packages and updated spec files will be available in CVS later today (untagged). Thanks Fabio signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Dear VTE maintainer (Re: Broken dependencies in Fedora 11 - 2009-06-09)
On Tue, 09 Jun 2009 18:41:46 -0400, Matthias wrote: On Tue, 2009-06-09 at 22:39 +0200, Christoph Wickert wrote: Am Dienstag, den 09.06.2009, 20:00 + schrieb Michael Schwendt: The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: lxterminal-0.1.4-2.fc11.i586 from fedora-11-i386 unresolved deps: libvte.so.9 Dear VTE maintainer, please consider announcing updates that will break 32 packages and please use fedora-devel-announce. TIA! Dear Christoph, please calm down. The update has not been pushed. The soname bump was unintended and Behdad is working on correcting that, which is why I have not asked for rebuilds. Thanks for listening, Matthias Also note that yesterday I've ported the assignBlame/libmunge/conspirators feature from mash's spam-o-matic to Extras repoclosure. It implements some basic checks to determine which library package might have broken the dependencies and then sends a full copy of the broken deps report to its package owners. The vte owners have received a rather long report. And let's not forget the feedback inside bodhi. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: USB autosuspend in F12
On Tue, Jun 9, 2009 at 8:32 PM, Matthew Garrettm...@redhat.com wrote: USB is an irritating protocol that requires USB controllers to remain active whenever a device is attached, even if that device is doing nothing. Is this somewhat addressed in the USB3 specs? -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Tue, Jun 9, 2009 at 8:11 AM, Michal Nowak mno...@redhat.com wrote: Just noticed Canonical is pushing GRUB 2 as default in Ubuntu 9.10 [1]. There are some hints on testing [2] and from what I can see there are 40 bugs opened against GRUB 2 in launchpad [3] v. zero in our Bugzilla. Was wondering what's the plan for Fedora and GRUB 2 as I can see there's quite old snapshot in current Rawhide -- 1.98-0.5.20080827svn.fc11. -- [1] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-June/000573.html [2] https://wiki.ubuntu.com/KernelTeam/Grub2Testing [3] https://bugs.launchpad.net/ubuntu/+source/grub2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list I would like to see GRUB Legacy replaced in Fedora 12 with GRUB 2, especially with a couple odd systems here that don't seem to like GRUB Legacy all that much -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86_64 kernel + i586 F11 userspace + yum
On Tue, 9 Jun 2009, Warren Togami wrote: setarch i386 chroot /path/to/i586root Do this and yum will behave properly. Ok, that should improve things if I want to do a series of installs. Thanks! It's still extra typing though. Also, any ideas on having the x86_64 kernel auto-updated (while keeping userpsace i586)? regards, -- Paul Jakma p...@clubi.ie p...@jakma.org Key ID: 64A2FF6A Fortune: QOTD: Sure, I turned down a drink once. Didn't understand the question. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Keyboard US Internacional
Rodrigo Padula de Oliveira wrote: In portuguese we don't have acent in the c But other languages do have ć, so it's only logical that accent+c produces it. Use [RAlt]+[,] and [c] to get ç. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mono-2.4 and ppc64 status
On Tue, 9 Jun 2009 23:11:33 +0200, SmootherFrOgZ wrote: list I assume that no one have any mono packages to rebuilt. then if so, i gonna request a push above packages. Are F-11 and devel in sync? It seems you have not built any of these changes for devel (.fc12). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
F10 updates-testing - F11 updates-testing yum upgrade issue
When trying to do a yum upgrade from 10 updates-testing to 11 updates-testing, I get the following: This is due to F11 updates-testing 'vte' package including a newer version of libvte, but the previous version was not retained. Could someone push a rebuild of gnome-terminal, gnome-desktop-sharp, Terminal and grip ASAP (maybe other packages are affected as well) ? Error: Missing Dependency: libvte.so.9 is needed by package gnome-terminal-2.26.2-1.fc11.i586 (updates-testing) Error: Missing Dependency: libvte.so.9 is needed by package gnome-desktop-sharp-2.26.0-1.fc11.i586 (fedora) Error: Missing Dependency: libvte.so.9 is needed by package Terminal-0.2.12-1.fc11.i586 (fedora) Error: Missing Dependency: libvte.so.9 is needed by package Terminal-0.2.12-1.fc11.i586 (updates) Error: Missing Dependency: libvte.so.9 is needed by package 1:grip-3.2.0-26.fc11.i586 (fedora) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F10 updates-testing - F11 updates-testing yum upgrade issue
When trying to do a yum upgrade from 10 updates-testing to 11 updates-testing, I get the following: This is due to F11 updates-testing 'vte' package including a newer version of libvte, but the previous version was not retained. Could someone push a rebuild of gnome-terminal, gnome-desktop-sharp, Terminal and grip ASAP (maybe other packages are affected as well) ? Read the mailing list archives. This has already been addressed in the last day or so. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mono-2.4 and ppc64 status
On Wed, Jun 10, 2009 at 11:11 AM, Michael Schwendtmschwe...@gmail.com wrote: On Tue, 9 Jun 2009 23:11:33 +0200, SmootherFrOgZ wrote: list I assume that no one have any mono packages to rebuilt. then if so, i gonna request a push above packages. Are F-11 and devel in sync? It seems you have not built any of these changes for devel (.fc12). I did, on some packages already (eg. gtk-sharp2, gnome-sharp). the rest are on their ways If you have package to rebuild, feel free to do it -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/polkit-gnome/devel polkit-gnome.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
On Tue, 9 Jun 2009, Matthias Clasen wrote: On Tue, 2009-06-09 at 14:58 +0200, Christoph Wickert wrote: # for /usr/share/gnome/autostart Requires: gnome-session Great! This adds gnome-session: 1.8 MB control-center: 7.1 MB GConf2: 5,5 MB gnome-keyring: 2,3 MB gnome-vfs2: 3.1 MB You added at least ~ 22,8 MB overhead just for directory ownership, although I asked you to _not_ do this. I think users of alternative desktops and the maintainers of their spins will not be amused. Last week you told me, that a one advantage of the new polkit is that no longer requires GConf2, but now it's dragged in again. Your anger is misdirected. Complain to the rpm people for not handling directories in a sane way. Or better still, send them a patch... Define sane. The unowned directory issue was hashed at quite a length in January [1], every option was disliked by somebody. Short summary of the options discussed: a) Create file dependencies for every directory not explicitly owned by the package at build time. Easy to do and works with everything out there but causes *huge* metadata bloat. b) Calculate directory dependencies at runtime. Easy to do but either causes transactions to abort due to missing dependencies whenever unowned directories are found, or would require changing all the depsolvers to know about and handle the implicit directory dependencies too. c) Have rpm silently add ownership of unowned directories to the package that creates them. This could cause weird directory conflicts when some other package actually owns the directory / becomes the owner, and just feels wrong anyhow. d) Variations of a-c where it'd just warn about the unowned directories. I've been playing with using directories for additional ordering information (fairly easy to do), c) is basically a one-liner patch on top of that. [1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg02326.html - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F10 updates-testing - F11 updates-testing yum upgrade issue
On Wed, 10 Jun 2009 12:20:42 +0300 (EEST), Pekka wrote: When trying to do a yum upgrade from 10 updates-testing to 11 updates-testing, I get the following: This is due to F11 updates-testing 'vte' package including a newer version of libvte, but the previous version was not retained. Could someone push a rebuild of gnome-terminal, gnome-desktop-sharp, Terminal and grip ASAP (maybe other packages are affected as well) ? Error: Missing Dependency: libvte.so.9 is needed by package gnome-terminal-2.26.2-1.fc11.i586 (updates-testing) Error: Missing Dependency: libvte.so.9 is needed by package gnome-desktop-sharp-2.26.0-1.fc11.i586 (fedora) Error: Missing Dependency: libvte.so.9 is needed by package Terminal-0.2.12-1.fc11.i586 (fedora) Error: Missing Dependency: libvte.so.9 is needed by package Terminal-0.2.12-1.fc11.i586 (updates) Error: Missing Dependency: libvte.so.9 is needed by package 1:grip-3.2.0-26.fc11.i586 (fedora) See the older threads about it. It's an accident, and btw, with a SONAME change like this in updates-testing, nobody could simply rebuild dependencies because koji buildroot override tags are needed first. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
Le Mer 10 juin 2009 10:59, Florian Festi a écrit : Nicolas Mailhot wrote: 1. something auto-triggered transparently (didn't we learn anything from existing package triggers?). I think you make the wrong comparison here (although I admit that the matching names make it tempting). Triggers fill holes in the scriptlet mechanism and though are restricted to obscure and complicated cases. The new trigger proposal has exactly the same problem as existing triggers: processing which is specified in a separate package, and happens magically if this package is available (on system or on build root), without the packager of the current package having any control on it. It will lead to exactly the same weird bugs and packager pain. Again, if you think you've factored out some cool processing function, please oh please give it a proper name/id and convince packagers to explicitely invoke this name/id in their specs do not inject code behind their backs. Wishing it all to happen transparently with no packager action is laudable, but in practice all past attempts to do so have ended up in pain for packagers and as they say the road to hell is paved with good intentions But semi automatic sub package creation is going to be an important part when/if we split out language sub packages. My idea is that you specify a regex for the files that go into the sub packages and a matching group that names the sub package and becomes a macro used in the package template. After 8+ months factoring out font subpackage creation and being forced by rpm limitations to do some form of automatic subpackage creation I can plainly say this is a bad idea. Packagers need the subpackage declarations to hang on deps, conflicts, ancillary files like doc, etc. Packagers need the subpackage declaration to control the size of theirs packages. Even if some package source includes 100 files with the same technical characteristics that does not mean you want to create a monster 100-files subpackages (and this is not a theorical argument, see TEX for example). So, do factor out logic, do help packagers assemble subpackages by calling common routines on the files they choose, but do not try to select the files in their stead. Except for very trivial cases you're going to have fallout, limitations and other unintended side-effects all over the place. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
On Wed, 10 Jun 2009, Nicolas Mailhot wrote:
Le Mer 10 juin 2009 10:59, Florian Festi a écrit :
Nicolas Mailhot wrote:
1. something auto-triggered transparently (didn't we learn anything
from
existing package triggers?).
I think you make the wrong comparison here (although I admit that the
matching names make it tempting). Triggers fill holes in the scriptlet
mechanism and though are restricted to obscure and complicated cases.
The new trigger proposal has exactly the same problem as existing
triggers: processing which is specified in a separate package, and
happens magically if this package is available (on system or on build
root), without the packager of the current package having any control
on it. It will lead to exactly the same weird bugs and packager pain.
Again, if you think you've factored out some cool processing function,
please oh please give it a proper name/id and convince packagers to
explicitely invoke this name/id in their specs do not inject code
behind their backs.
Wishing it all to happen transparently with no packager action is
laudable, but in practice all past attempts to do so have ended up in
pain for packagers and as they say the road to hell is paved with good
intentions
File triggers are certainly not the holy grail of packaging, they're only
applicaple to a pretty limited set of situations, from the top of my head:
1) Caches updaters which you only want to run once per transaction:
- ldconfig
- scrolkeeper-update
- gtk-update-icon-cache
- update-desktop-database
- fc-cache
2) Files in well-known locations that might be automatically registerable:
- install-info add + remove of %{_infodir}/*.info*
- init scripts (chkconfig --add/--del, service stop/condrestart)
- gconf schema install+remove
- plugin registrations
The cases in 1) are the classic file trigger examples, things that
aren't absolutely critical for the package itself to be runnable, and
where false positives / multiple unnecessary runs are not dangerous at
all. They're just telling some other package please update your caches.
I dont see any point in requiring special extra magic in specs to activate
them.
The cases in 2) differ in varying degrees. Info-file
registration/unregistration seems safe enough to me: by putting an *.info*
file into %{_infodir} you are announcing it's an info file. There's not
much room for mistakes here I'd think, and it's quite close to category 1)
actually, except it needs to run at different times (to handle removal).
Services and gconf .. might not be so obvious, and whether plugin
registration/unregistration can reliably be done automatically is
case by case.
In both categories there's a big difference to the current name/provide
triggers: with file triggers you knowingly place something into some other
packages directory, so following the principles of directory ownership you
should already depend on the other package. With name/provide triggers any
completely unrelated package can do anything at all at any time. Maybe
packages should only be able to add triggers on directories they actually
own (subject to abuse too but then what isnt...).
AFAICT, you're talking what would basically be a named trigger, to which
packages subscribe to if they want to. It's not at odds with file
triggers at all, and both are likely to get implemented sooner or later.
What distros choose to use for particular task is up to their packaging
committees and whatnot, rpm is to only provide a mechanism, not policy
or any magic internal triggers here.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: USB autosuspend in F12
On Tue, 2009-06-09 at 19:32 +0100, Matthew Garrett wrote: Through F12 I'm going to be slowly enabling autosuspend on various pieces of USB hardware. The aim is to ensure that it's only enabled on hardware that supports it. This is going to be a combination of kernel modifications and packaging changes, and while I'll be testing as many as possible before uploading anything there's a risk that some hardware will misbehave. I'll let people know when I think I'm about to upload anything risky. Is this something worthy of being a feature? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/polkit-gnome/devel polkit-gnome.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
On Wed, 2009-06-10 at 12:25 +0300, Panu Matilainen wrote: c) Have rpm silently add ownership of unowned directories to the package that creates them. This could cause weird directory conflicts when some other package actually owns the directory / becomes the owner, and just feels wrong anyhow. I think we want something slighly less than this; rpm should track the fact that a directory was created just because some files needed to be put there, and it should be able to clean up if the last such file is removed. But I should not fully assign ownership of the directory to the packages that just drop files in there. Ref-counting of implicitly owned directories of some sort. But if a package explicitly owning the directory is later installed, it should of course take over the ownership. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Keyboard US Internacional
Em 10-06-2009 07:32, Bill Crawford escreveu: Rodrigo Padula de Oliveira wrote: Hello Guys! We have a problem with the keyboard Us Internacional. I'm using Fedora 11 in pt_BR Looking the file /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz, I found this: compose '\'' 'C' to 'Ç' compose '\'' 'c' to 'ç' This is correct, but, when I press ' + c or ' + C = ć or Ć. In portuguese we don't have acent in the c, the correct is ç (C + cedilla) So, how can We fix this problem ? It's possible (you don't say) that you're experiencing this problem within X, not at the console. If so, it's because the compose file has '+c = ć (see /usr/share/X11/locale/pt_BR.UTF-8/Compose for details). Try composing , (comma) and c. The error is the same in the console and X. rpm -qf /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz The package is kbd-1.15-7.fc11.i586 I will report a bug. -- Rodrigo Padula de Oliveira M.Sc. Student - COPPE/UFRJ Fedora Community Manager - Latin America Red Hat Community and Academy Relations http://www.proyectofedora.org http://twitter.com/rodrigopadula http://www.rodrigopadula.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
On Wed, 10 Jun 2009, Nicolas Mailhot wrote:
Le Mer 10 juin 2009 13:21, Panu Matilainen a écrit :
File triggers are certainly not the holy grail of packaging, they're
only
applicaple to a pretty limited set of situations, from the top of my
head:
1) Caches updaters which you only want to run once per transaction:
- ldconfig
- scrolkeeper-update
- gtk-update-icon-cache
- update-desktop-database
- fc-cache
Actually, I doubt we will ever run fc-cache once per transaction. The
consequences of bad fontconfig caches are just too high. What we've
been doing is runing fc-cache just-as-needed by making each srpm
install files in a different directory and having resulting rpms
refresh only this directory cache, instead of processing all the
system font directories each time a font package is installed.
Well, I'm not intimately aware of the font handling details nor do I
want to be, I was just under the impression the font cache belongs to the
category 1). And this is why the actual script to do whatever magic it
needs to do, when it needs to, would be in a distros fontconfig package,
not rpm.
2) Files in well-known locations that might be automatically
registerable:
- install-info add + remove of %{_infodir}/*.info*
- init scripts (chkconfig --add/--del, service stop/condrestart)
- gconf schema install+remove
- plugin registrations
The cases in 1) are the classic file trigger examples, things that
aren't absolutely critical for the package itself to be runnable, and
where false positives / multiple unnecessary runs are not dangerous at
all.
Multiple runs yes, false positives do not be so sure. False positives
is the main weakness of this proposal and good stuff will happen if
the autoselection is correct is very different from bad stuff won't
happen if the autoselection is false.
False positive in this context would mean either
a) the cache update run without needing to
b) a package put something into a wrong directory
a) is harmless as per multiple runs, b) is a grave packaging bug which
with file triggers would be caught when installing the buggy package,
instead of next cache update started by something else which then might
blow up/issue warnings long time afterwards.
They're just telling some other package please update your
caches.
And relying on the cache updating utilities to have ironclad false
positive protection logic. Which is not a given, since those utilities
have always been explicitely invoked with a human sanity-checking
input files before.
See above, they already need an ironclad false positive protection.
BTW: the system can usually manage when those caches are stale, not
when they are corrupted.
I dont see any point in requiring special extra magic in specs to
activate
them.
The cases in 2) differ in varying degrees. Info-file
registration/unregistration seems safe enough to me: by putting an
*.info*
file into %{_infodir} you are announcing it's an info file. There's
not
much room for mistakes here I'd think, and it's quite close to
category 1)
actually, except it needs to run at different times (to handle
removal).
This is backwards IMHO
1. it relies on all interesting files having a clear FHS location or
unambiguous file name
The idea of file triggers is *based* on the well known locations. If
something doesn't have a clear and well known location, file triggers are
not at all the right solution for it.
2. it relies on the packager guessing the right places to put his
files to trigger processing. The logic should not be I have an info
file, let's put it here so rpm guesses it's an info file and does the
right thing.
There's hardly guessing involved, you put things where they belong just
like you're currently doing: the canonical location for info files is
%{_infodir} and not %{_libdir}/mypackage/ for example, and the info
trigger would not look anywhere outside %{_infodir}. So for the average
autoconf using software it's taken care of by %configure already.
Again, if something doesn't have a well defined place, file triggers
shouldn't be used.
The logic should be I tell rpm this is an info file and
rpm does the right thing, including installing it in the right place.
That forces *rpm* to know something about any arbitrary file type and
location you might ever want to handle. You know how well that works for
automatic dependency generation - I really doubt you want more of the
same. The knowledge belongs to the packages knowing how to handle
something, be it fontconfig or icon cache or whatever.
This is of course the POW of a packager that has to cope with
imperfect tools that try to be smarter than they can be, not the POW
of the person that writes the smart tools and is convinced he can't do
wrong.
See above, this is why you dont want *rpm* in control of things, only to
provide a mechanism to utilize where it makes sense.
Now, some way to register build-time trigger warnings your package is
installing X file that seems to
vmware tools
Hello, I just upgrade to Fedora 11 my virtual box , but I can't build vmware-tools does anyone succeeded ? (x86_64 and vmware-tools sources here : http://download3.vmware.com/software/fusion/VMware-tools-linux-116369.iso ) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Customizable script in /etc which is executed during package update
Hi all, I've been contacted with one man who is using named daemon in chroot environment. In Fedora = 10 there is script called bind-chroot-admin which synchronized non-chroot and chroot configuration files (mostly created symlinks to chroot). This script has been removed in F11 development process due various reasons (http://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=flattopic_id=63613forum=11) As the man suggested it would be nice to have a method to automatically synchronize chroot and non-chroot during updates because it will simplify administration. I would like to add script called /etc/sysconfig/named-chroot-update-hook which will be modified by administrator to sync needed files to chroot environment during each update. Then every admin will easily maintain his own version of chroot. What do you think about this? Do you know any better approach? Regards, Adam -- Adam Tkac, Red Hat, Inc. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Keyboard US Internacional
Em 10-06-2009 05:21, Kevin Kofler escreveu: Rodrigo Padula de Oliveira wrote: In portuguese we don't have acent in the c But other languages do have ć, so it's only logical that accent+c produces it. Use [RAlt]+[,] and [c] to get ç. Kevin Kofler It works, but we can't change the default way to use the us_acentos keyboard. Since Fedora 1 and in all others SOs when we choose the pt_BR language and the US Internacional keyboard when we press C + ' we have = ç I will report a bug. -- Rodrigo Padula de Oliveira M.Sc. Student - COPPE/UFRJ Fedora Community Manager - Latin America Red Hat Community and Academy Relations http://www.proyectofedora.org http://twitter.com/rodrigopadula http://www.rodrigopadula.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Keyboard US Internacional
On Wed, Jun 10, 2009 at 10:21:07AM +0200, Kevin Kofler wrote: Rodrigo Padula de Oliveira wrote: In portuguese we don't have acent in the c But other languages do have ć, so it's only logical that accent+c produces it. Use [RAlt]+[,] and [c] to get ç. Kevin Kofler He is, however, explicitly using pt_BR. We shouldn't produce keys the selected locale does not support. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
Le Mer 10 juin 2009 15:29, Panu Matilainen a écrit : On Wed, 10 Jun 2009, Nicolas Mailhot wrote: And this is why the actual script to do whatever magic it needs to do, when it needs to, would be in a distros fontconfig package, not rpm. This is totally orthogonal to invoking this script via file triggers or not. False positive in this context would mean either a) the cache update run without needing to b) a package put something into a wrong directory a) is harmless as per multiple runs, b) is a grave packaging bug which with file triggers would be caught when installing the buggy package, What will happen is the very same spec will go bang in one build environment and not another, and people will waste time trying to find out what's different because of the transparent magic processing. That happened many times in the past with the redhat rpm customization that changes rpm behaviour transparently without packager intervention. instead of next cache update started by something else which then might blow up/issue warnings long time afterwards. Cache updates triggered by apps are checked upstream. Cache updates triggered by magic rpm transparent rules only happen in a distro environment that uses them. I very much doubt there will ever be a 100% match between the regexps file triggers use to identify files and the rules cache utilities use to identify what to process. The logic should be I tell rpm this is an info file and rpm does the right thing, including installing it in the right place. That forces *rpm* to know something about any arbitrary file type and location you might ever want to handle. That does not force rpm to know anything more than in your proposal. 'Telling rpm X is an info file' can be done via the explicit invocation of %_frob_info_file X, all rpm has to provide is a way for people interested in info files to declare a %_frob_info_file which is then available to other packages (that may use it or not depending on preferences, distro policies and special cases *they* know of). *this* is what is missing today. Packagers know what's in their packages (it's *their* responsability). People know how to write bits of processing appropriate for X or Y content (this is what SIGs and FPC do all the time). People in group 2 know how to communicate with group 1 What's is broken is group 2 can not give group 1 prepackaged routines to use, because rpm does not allow injecting code that spans multiple sections (deps, build, install, post, pre, check etc), and that concern the same subpackage. And thus people have to cut and paste. You can not tell packagers : To add the font file X.ttf, to your subpackage Y, declare: %files Y %do_what's_appropriate_for_fonts X.ttf and you're done You have to paste code in build, install, post, preun, etc because of this (and hope you never mess up with the subpackage identifier all those sections expect). Which is a huge PITA and impedance mismatch. The actual file type identification is *not* a problem. It's *less* work than reading the FHS and putting files manually in a place rpm would recognize. And in fact the FHS is not that accurate and for a lot of files location will depend on distro policy, so reading the FHS is not enough anyway. You know how well that works for automatic dependency generation - I really doubt you want more of the same. The knowledge belongs to the packages knowing how to handle something, be it fontconfig or icon cache or whatever. The processing knowledge does not belong in the package itself. The file identification knowledge is something else entirely. Well you snipped out the part about named triggers which would be something to this direction: an opt-in feature your package claims interest in (or subscribes, whatever terminology you want to use). opt-in in IMHO safer and saner. And more flexible. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On 06/10/2009 10:43 AM, Christopher Brown wrote: 2009/6/10 King InuYashangomp...@gmail.com: I would like to see GRUB Legacy replaced in Fedora 12 with GRUB 2, especially with a couple odd systems here that don't seem to like GRUB Legacy all that much Actually the reverse is true, in that you will find that GRUB 2 will support fewer machines than GRUB Legacy. This is why, as the ubuntu page quite correctly states, upgrading a bootloader is at best frightening and risky. So what is the deal with GRUB development? I find it strange that upstream already has declared the old GRUB Legacy even though GRUB 2 isn't ready for prime time yet. Has the patch for full ext4 support that has been mentioned before landed in upstream yet? What is the timetable to get GRUB 2 ready for primetime? Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: USB autosuspend in F12
Matthew Garrett wrote: The first part of this is an upload of libfprint which enables autosuspend on fingerprint readers. Fingerprint readers and other un-unpluggable USB laptop stuff such as flash-readers, bluetooth adapters etc. are perfect candidates for suspending. Is there somewhere any estimate about the amount of power this feature can save? Best regards. -- Roberto Ragusamail at robertoragusa.it -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bittorrent speeds...
Greetings, On Wednesday 10 June 2009 01:56:38 Nathanael D. Noblet wrote: [...snipped...] X86_64 DVD Install. I dropped the max connections and have slowly bumped it up from there. Its at 350 now, so I'm now getting 500K/s. Not really sure what was going on, when I looked at the peer/seeder list, there were lots and lots of connections, but 0K up/down. I figured if I dropped the number of connections maybe deluge would perhaps keep the ones sending stuff a bit better... Not really sure what's going on but its much better than the 8-20K I was getting. Who is your Internet Provider? It is possible that they are tampering with your torrents. http://www.eff.org/testyourisp Regards, -- Jeff MacDonald Zoid Technologies, LLC: Custom Information Systems http://zoidtechnologies.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Keyboard US Internacional
Le Mer 10 juin 2009 16:48, Glauber Costa a écrit : On Wed, Jun 10, 2009 at 10:21:07AM +0200, Kevin Kofler wrote: Rodrigo Padula de Oliveira wrote: In portuguese we don't have acent in the c But other languages do have ć, so it's only logical that accent+c produces it. Use [RAlt]+[,] and [c] to get ç. Kevin Kofler He is, however, explicitly using pt_BR. We shouldn't produce keys the selected locale does not support. He's not using a locale-specific layout. He's using en_US(intl) which is *not* guaranteed to do the best thing for every possible locale (just to try to provide a middle ground for qwerty users) If he wants portuguese/brasilian specific behaviour, he needs to use (and create if it does not exist) a portuguese/brasilian specific layout. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/polkit-gnome/devel polkit-gnome.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Le Mer 10 juin 2009 15:28, Matthias Clasen a écrit : I think we want something slighly less than this; rpm should track the fact that a directory was created just because some files needed to be put there, and it should be able to clean up if the last such file is removed. But I should not fully assign ownership of the directory to the packages that just drop files in there. Ref-counting of implicitly owned directories of some sort. That assumes all directory permissions are created equal, which isn't the case. Explicit automatic rpm directory ownership (à la rpm5.org, with the associated metadata growth), or manual directory ownership (as in Fedora today) are here to make sure two packages can not create the same directory with different perms. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: USB autosuspend in F12
On Wed, Jun 10, 2009 at 09:15:30AM -0400, Jesse Keating wrote: On Tue, 2009-06-09 at 19:32 +0100, Matthew Garrett wrote: Through F12 I'm going to be slowly enabling autosuspend on various pieces of USB hardware. The aim is to ensure that it's only enabled on hardware that supports it. This is going to be a combination of kernel modifications and packaging changes, and while I'll be testing as many as possible before uploading anything there's a risk that some hardware will misbehave. I'll let people know when I think I'm about to upload anything risky. Is this something worthy of being a feature? Possibly. I'd pretty much thought of it as bugfixing, but feature sounds fair. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wed, Jun 10, 2009 at 3:43 AM, Christopher Brown snecklif...@gmail.comwrote: 2009/6/10 King InuYasha ngomp...@gmail.com: I would like to see GRUB Legacy replaced in Fedora 12 with GRUB 2, especially with a couple odd systems here that don't seem to like GRUB Legacy all that much Actually the reverse is true, in that you will find that GRUB 2 will support fewer machines than GRUB Legacy. This is why, as the ubuntu page quite correctly states, upgrading a bootloader is at best frightening and risky. -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list While that is true, I have already seen two of my machines unable to boot through GRUB Legacy that could through GRUB 2. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wed, Jun 10, 2009 at 9:50 AM, Dennis J. denni...@conversis.de wrote: On 06/10/2009 10:43 AM, Christopher Brown wrote: 2009/6/10 King InuYashangomp...@gmail.com: I would like to see GRUB Legacy replaced in Fedora 12 with GRUB 2, especially with a couple odd systems here that don't seem to like GRUB Legacy all that much Actually the reverse is true, in that you will find that GRUB 2 will support fewer machines than GRUB Legacy. This is why, as the ubuntu page quite correctly states, upgrading a bootloader is at best frightening and risky. So what is the deal with GRUB development? I find it strange that upstream already has declared the old GRUB Legacy even though GRUB 2 isn't ready for prime time yet. Has the patch for full ext4 support that has been mentioned before landed in upstream yet? What is the timetable to get GRUB 2 ready for primetime? Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list Well, the existing GRUB used in distros was declared Legacy a long time ago. GRUB 2 is a rewrite that is supposed to include all the features the various vendors have been patching into GRUB Legacy, as well as being able to support EFI and basically supporting what the Chameleon bootloader does in addition to the GRUB Legacy's support. Though I doubt fake-EFI would be implemented in GRUB 2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: USB autosuspend in F12
On Wed, Jun 10, 2009 at 05:16:41PM +0200, Roberto Ragusa wrote: Matthew Garrett wrote: The first part of this is an upload of libfprint which enables autosuspend on fingerprint readers. Fingerprint readers and other un-unpluggable USB laptop stuff such as flash-readers, bluetooth adapters etc. are perfect candidates for suspending. USB mass storage is more awkward, but otherwise yes. Note that this isn't inherently about suspending the device - they may go into a power savig state, but it's not required that they be fully powered down. The issue is more about letting the *bus* power down. How much we save will depend on the specific bus layout on a given machine, and also whether we can successfully autosuspend all of the drivers. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wed, 2009-06-10 at 11:07 -0500, King InuYasha wrote: Well, the existing GRUB used in distros was declared Legacy a long time ago. GRUB 2 is a rewrite that is supposed to include all the features the various vendors have been patching into GRUB Legacy, as well as being able to support EFI and basically supporting what the Chameleon bootloader does in addition to the GRUB Legacy's support. Though I doubt fake-EFI would be implemented in GRUB 2 The grub we're already shipping has EFI support. I have yet to hear of a problem we're actually having that would be solved with grub2. - ajax signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wed, Jun 10, 2009 at 6:36 PM, Adam Jacksona...@redhat.com wrote: On Wed, 2009-06-10 at 11:07 -0500, King InuYasha wrote: Well, the existing GRUB used in distros was declared Legacy a long time ago. GRUB 2 is a rewrite that is supposed to include all the features the various vendors have been patching into GRUB Legacy, as well as being able to support EFI and basically supporting what the Chameleon bootloader does in addition to the GRUB Legacy's support. Though I doubt fake-EFI would be implemented in GRUB 2 The grub we're already shipping has EFI support. I have yet to hear of a problem we're actually having that would be solved with grub2. the version number ;) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
drago01 wrote: I have yet to hear of a problem we're actually having that would be solved with grub2. the version number ;) A better argument than you'd think. The number itself is no big deal, but the fact that upstream is a hollow void in the universe certainly troubles users looking for support. I seriously doubt grub 2 is the right fix for that, but it'd be nice to not have the distro leaning on a boot loader that everyone swears is dead code. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wed, 2009-06-10 at 18:41 +0200, Dennis J. wrote: If that's the case then it obviously makes sense to stick with grub legacy but given it's status who is going to be upstream for this? What I fear is a similar situation like we had with rpm where nobody really took ownership and vendors carried their own individual patches wich doesn't really work well with fedoras stay close to upstream mantra. For better or worse, we are effectively running a grub fork, and I see very little desire to change that... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
2009/6/10 Matthias Clasen mcla...@redhat.com: On Wed, 2009-06-10 at 18:41 +0200, Dennis J. wrote: If that's the case then it obviously makes sense to stick with grub legacy but given it's status who is going to be upstream for this? What I fear is a similar situation like we had with rpm where nobody really took ownership and vendors carried their own individual patches wich doesn't really work well with fedoras stay close to upstream mantra. For better or worse, we are effectively running a grub fork, and I see very little desire to change that... Is extlinux worth considering as a replacement? I know Foresight has gone that road. Jonathan (who knows nothing about bootloaders). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On 06/10/2009 12:05 PM, King InuYasha wrote: On Wed, Jun 10, 2009 at 3:43 AM, Christopher Brown snecklif...@gmail.comwrote: 2009/6/10 King InuYasha ngomp...@gmail.com: I would like to see GRUB Legacy replaced in Fedora 12 with GRUB 2, especially with a couple odd systems here that don't seem to like GRUB Legacy all that much Actually the reverse is true, in that you will find that GRUB 2 will support fewer machines than GRUB Legacy. This is why, as the ubuntu page quite correctly states, upgrading a bootloader is at best frightening and risky. -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list While that is true, I have already seen two of my machines unable to boot through GRUB Legacy that could through GRUB 2. Bug numbers? -- Peter In the time of chimpanzees I was a monkey. -- Beck -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upgrade to F11, now yum python module missing
On Wed, 10 Jun 2009 19:17:37 +0200 Stefan Grosse singularit...@gmx.net wrote: SG During the DVD upgrade from F10 - F11 I encountered the issue that SG my yum appears broken now: SG SG SG There was a problem importing one of the Python modules SG required to run yum. The error leading to this problem was: SG SGNo module named yum SG I could solve it by installing the yum rpm directly via rpm but I needed the force argument. Somehow the yum was not upgraded correctly, give the hint that the old yum was still there. Thx anyway. Stefan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upgrade to F11, now yum python module missing
On Wed, 10 Jun 2009 19:17:37 +0200 Stefan Grosse singularit...@gmx.net wrote: During the DVD upgrade from F10 - F11 I encountered the issue that my yum appears broken now: First: Note that this is the devel list, please post end user support questions over on fedora-list? Did you have 'updates-testing' enabled in f10? I suspect that the version in f10 updates-testing is newer than the one in f11, so it didn't get upgraded. Try installing the yum from f11 updates-testing. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Keyboard US Internacional
Rodrigo Padula de Oliveira wrote: Since Fedora 1 and in all others SOs when we choose the pt_BR language and the US Internacional keyboard when we press C + ' we have = ç I will report a bug. This is NOT a bug! I have been using en_US International for many years and in Canada, when we write in French, we use the ç and Ç a lot and they have always been right where they are now, as Kevin pointed out. The ć and Ć must exist in other languages. Please post the bug number to this list, so that we can correctly refute the bug. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upgrade to F11, now yum python module missing
On Wed, 10 Jun 2009, Stefan Grosse wrote: On Wed, 10 Jun 2009 19:17:37 +0200 Stefan Grosse singularit...@gmx.net wrote: SG During the DVD upgrade from F10 - F11 I encountered the issue that SG my yum appears broken now: SG SG SG There was a problem importing one of the Python modules SG required to run yum. The error leading to this problem was: SG SGNo module named yum SG I could solve it by installing the yum rpm directly via rpm but I needed the force argument. Somehow the yum was not upgraded correctly, give the hint that the old yum was still there. you had yum 3.2.23 from f10 updates-testing installed but F11-GA has 3.2.22 available. so you were updated to python 2.6 from 2.5 - which 'lost' the newer f10 yum b/c it is in the python 2.5 path. You can try: 1. download yum 3.2.23 from F11-updates 2. install it with rpm -Uvh pkg or 1. export PYTHONPATH=/usr/lib/python2.5/site-packages 2. yum update yum I'm curious if this second one will work. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/polkit-gnome/devel polkit-gnome.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
On Wed, 10 Jun 2009, Nicolas Mailhot wrote: Le Mer 10 juin 2009 15:28, Matthias Clasen a écrit : I think we want something slighly less than this; rpm should track the fact that a directory was created just because some files needed to be put there, and it should be able to clean up if the last such file is removed. But I should not fully assign ownership of the directory to the packages that just drop files in there. Ref-counting of implicitly owned directories of some sort. That assumes all directory permissions are created equal, which isn't the case. Explicit automatic rpm directory ownership (à la rpm5.org, with the associated metadata growth), AFAIK rpm5.org generates the directory dependencies at runtime from data already present in headers, ie the case b) I described here: https://www.redhat.com/archives/fedora-devel-list/2009-June/msg00671.html. There's no associated metadata growth with that option, it's easy to add and forces directory ownership to be sorted out in the packages, otherwise the packages are simply uninstallable. The directory information is of course in repodata too, but in the costly filelists part. Smart and apt have to download it anyway so they could be taught to look at directories with little zero extra cost, yum is the one that would take an extra hit here by having to always download filelists unlike now. Or move the directories into the primary metadata piece, or do a second depsolve + download round after ts.check() to pull in the runtime dependencies. In any case, every depsolver needs some modifications to work smoothly with this option. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upgrade to F11, now yum python module missing
On Wed, 10 Jun 2009 13:55:42 -0400 (EDT) Seth Vidal skvi...@fedoraproject.org wrote: SV You can try: SV 1. download yum 3.2.23 from F11-updates SV 2. install it with rpm -Uvh pkg SV SV or SV SV 1. export PYTHONPATH=/usr/lib/python2.5/site-packages SV 2. yum update yum SV SV I'm curious if this second one will work. Thanks for the advice. I tried the first solution so sorry that I cannot tell whether the second works. Stefan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Pkgdb 0.4 update scheduled for Monday
Hi all, Assuming all goes well with an account system upgrade this week, we're going to be updating the PackageDB to 0.4 on Monday, June 10. An outage notification will go out later that tells the exact times. This is just a note that anyone who has scripts hitting the package database for information should check that they still work with the instance we are running in staging: https://admin.stg.fedoraproject.org/pkgdb/ The most notable change to the API is that usernames and group names are now returned everywhere isntead of userids and groupids. For the most part, this should make scripts simpler as you no longer have to query FAS if you just need the username. If you encounter bugs or have any concerns, let me know via email, a reply to this message, or on irc.freenode.net (I'm abadger1999). -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: hda-verb and sound problems with Acer Aspire 8930G
On Wed, 2009-06-10 at 13:45 +0300, Muayyad AlSadi wrote: a brother have reported a problem in sound since F10 and he moved to F11 and he still have the problem lspci | grep Audio gives 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) (for more diagnostics see English output in http://www.linuxac.org/forum/linuxac68/thread23699.html ) the solution to that problem is by calling hda-verb on each boot http://www.linlap.com/wiki/Acer+Aspire+8930G ubuntu: http://jan.saell.org/blog/archives/30 suse: http://en.opensuse.org/SDB_Discussion:Intel-HDA_sound_problems mandriva: http://rpmfind.net/linux/RPM/mandriva/2009.1/x86_64/media/contrib/release/hda-verb-0.3-1mdv2009.1.x86_64.html kernel: ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/ so can somebody tell me if this was discussed for fedora and if hda-verb was packed https://bugzilla.redhat.com/show_bug.cgi?id=499488 is a bug I filed to try and pull together all the various bits of information about this problem. hda-verb isn't packaged for Fedora AFAICT, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: USB autosuspend in F12
On Wed, 2009-06-10 at 17:04 +0100, Matthew Garrett wrote: On Wed, Jun 10, 2009 at 09:15:30AM -0400, Jesse Keating wrote: On Tue, 2009-06-09 at 19:32 +0100, Matthew Garrett wrote: Through F12 I'm going to be slowly enabling autosuspend on various pieces of USB hardware. The aim is to ensure that it's only enabled on hardware that supports it. This is going to be a combination of kernel modifications and packaging changes, and while I'll be testing as many as possible before uploading anything there's a risk that some hardware will misbehave. I'll let people know when I think I'm about to upload anything risky. Is this something worthy of being a feature? Possibly. I'd pretty much thought of it as bugfixing, but feature sounds fair. Making it a feature would make for easy integration with the Test Day process, and this sounds like a good thing to have a Test Day for - it should be relatively easy, and beneficial to development (as we should be able to get people with a wide variety of devices to show up). Please do ping me or jlaska if you'd be interested in doing a test day for this. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Live from Raleigh, it's Fedora Activity Day! (A list of proposals regarding Fedora Development Cycle)
We've had a very productive 3 days here at the Fedora Activity Day. Our wiki page [1] details what we came here to as well as gobby logs of our work in progress. Yesterday we identified a number of proposals we could make to resolve many of the issues we've talked about, and today we created a series of wiki pages to contain those proposals. Below you will find a list of the proposals as well as the principle person responsible for the proposal. Some of these will be ready for FESCo review now, some will require more work and discussion, and some will require others to be finished first. https://fedoraproject.org/wiki/Milestone_Adjustment_Proposal - Bill Nottingham https://fedoraproject.org/wiki/Israwhidebroken.com_Proposal - Will Woods and James Laska https://fedoraproject.org/wiki/Koji_Build_Autosign_Proposal - Jesse Keating https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal - Seth Vidal https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal - Jesse Keating I'm sure we'll be seeing more chatter about these in the coming days. I would request that if you wish to talk about any of these proposals, please start a new thread, lest this becomes a giant pile-on thread that would be difficult to follow in the archives, OR use the discussion tab in the wiki page for the particular proposal. For those of you that were able to join our Fedora Talk session and IRC channel, thank you for your valuable input and I hope we made it easy to participate as the event happened. Things are winding down here, a few of us are going to start some of the groundwork for some of these proposals as well as tackling some of the other issues identified at this FAD which require no proposal for change, only time and energy to fix. I hope you all enjoyed Fedora 11! -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: USB autosuspend in F12
Matthew Garrett wrote: The issue is more about letting the *bus* power down. How much we save will depend on the specific bus layout on a given machine, and also whether we can successfully autosuspend all of the drivers. Modern machines are full of (mostly empty) buses, so there is hope the gain will not be insignificant. :-) $ lsusb Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 010: ID 0a5c:2110 Broadcom Corp. Bluetooth Controller Bus 003 Device 003: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub -- Roberto Ragusamail at robertoragusa.it -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: hda-verb and sound problems with Acer Aspire 8930G
thanks, that's useful I'll try to make an rpm for hda-verb and make a brother of mine test it -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: vmware tools
On 06/10/2009 03:30 PM, philippe makowski wrote: Hello, I just upgrade to Fedora 11 my virtual box , but I can't build vmware-tools does anyone succeeded ? (x86_64 and vmware-tools sources here : http://download3.vmware.com/software/fusion/VMware-tools-linux-116369.iso ) This is off-topic for this list, but you should try to use the open source version of those tools on RPMFusion (open-vm-tools). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wed, Jun 10, 2009 at 06:41:55PM +0200, Dennis J. wrote: [..] with fedoras stay close to upstream mantra. I'm glad somebody said it. Can someone summarise what the problems are with GRUB2? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wed, Jun 10, 2009 at 11:41 AM, Dennis J. denni...@conversis.de wrote: On 06/10/2009 06:36 PM, Adam Jackson wrote: On Wed, 2009-06-10 at 11:07 -0500, King InuYasha wrote: Well, the existing GRUB used in distros was declared Legacy a long time ago. GRUB 2 is a rewrite that is supposed to include all the features the various vendors have been patching into GRUB Legacy, as well as being able to support EFI and basically supporting what the Chameleon bootloader does in addition to the GRUB Legacy's support. Though I doubt fake-EFI would be implemented in GRUB 2 The grub we're already shipping has EFI support. I have yet to hear of a problem we're actually having that would be solved with grub2. If that's the case then it obviously makes sense to stick with grub legacy but given it's status who is going to be upstream for this? What I fear is a similar situation like we had with rpm where nobody really took ownership and vendors carried their own individual patches wich doesn't really work well with fedoras stay close to upstream mantra. Regards, Dennis We are already in that position. However, with Ubuntu's apparent willingness to test and see if GRUB 2 is worthy of being used in Ubuntu 9.10, other distros may actually do so as well. Perhaps Fedora should do a test day or something after figuring out what features we need our boot loader to actually support and if GRUB 2 would fulfill the requirements. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wednesday, June 10 2009, King InuYasha said: On Wed, Jun 10, 2009 at 11:36 AM, Adam Jackson a...@redhat.com wrote: On Wed, 2009-06-10 at 11:07 -0500, King InuYasha wrote: Well, the existing GRUB used in distros was declared Legacy a long time ago. GRUB 2 is a rewrite that is supposed to include all the features the various vendors have been patching into GRUB Legacy, as well as being able to support EFI and basically supporting what the Chameleon bootloader does in addition to the GRUB Legacy's support. Though I doubt fake-EFI would be implemented in GRUB 2 The grub we're already shipping has EFI support. I have yet to hear of a problem we're actually having that would be solved with grub2. EFI support is not the same as fake-EFI. Erm, the EFI support in our grub today isn't fake-EFI. Jeremy -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On 06/10/2009 05:17 PM, Jeremy Katz wrote: On Wednesday, June 10 2009, King InuYasha said: On Wed, Jun 10, 2009 at 11:36 AM, Adam Jackson a...@redhat.com wrote: On Wed, 2009-06-10 at 11:07 -0500, King InuYasha wrote: Well, the existing GRUB used in distros was declared Legacy a long time ago. GRUB 2 is a rewrite that is supposed to include all the features the various vendors have been patching into GRUB Legacy, as well as being able to support EFI and basically supporting what the Chameleon bootloader does in addition to the GRUB Legacy's support. Though I doubt fake-EFI would be implemented in GRUB 2 The grub we're already shipping has EFI support. I have yet to hear of a problem we're actually having that would be solved with grub2. EFI support is not the same as fake-EFI. Erm, the EFI support in our grub today isn't fake-EFI. I think he's referring to a Chameleon feature. -- Peter Space, is big. Really big. You just won't believe how vastly hugely mindbogglingly big it is. I mean you may think it's a long way down the road to the chemist, but that's just peanuts to space. -- The Hitchhiker's Guide to the Galaxy -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: USB autosuspend in F12
issue is more about letting the *bus* power down. How much we save will depend on the specific bus layout on a given machine, and also whether we can successfully autosuspend all of the drivers. Modern machines are full of (mostly empty) buses, so there is hope the gain will not be insignificant. :-) This is also very true of servers where the vast majority of expansion and peripherals are either in regular use or not at all. In a data centre environment the vast majority of usb and KVM are disconnected for 99.999% of the servers life span. Would certainly be very significant across the lifespan of the average server. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pkgdb 0.4 update scheduled for Monday
On Wed, Jun 10, 2009 at 7:13 PM, Toshio Kuratomia.bad...@gmail.com wrote: Hi all, Assuming all goes well with an account system upgrade this week, we're going to be updating the PackageDB to 0.4 on Monday, June 10. An outage notification will go out later that tells the exact times. This is just a note that anyone who has scripts hitting the package database for information should check that they still work with the instance we are running in staging: Monday the 15th? Today is the 10th June :) Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pkgdb 0.4 update scheduled for Monday
On 2009-06-10 10:39:00 PM, Peter Robinson wrote: On Wed, Jun 10, 2009 at 7:13 PM, Toshio Kuratomia.bad...@gmail.com wrote: Hi all, Assuming all goes well with an account system upgrade this week, we're going to be updating the PackageDB to 0.4 on Monday, June 10. An outage notification will go out later that tells the exact times. This is just a note that anyone who has scripts hitting the package database for information should check that they still work with the instance we are running in staging: Monday the 15th? Today is the 10th June :) I think he meant the 16th. Also, there will be python-fedora and FAS upgrade on Thursday that includes some minor API changes (and major speedups, we hope). Thanks, Ricky pgp1dxZ8HDniZ.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wed, Jun 10, 2009 at 4:53 PM, Adam Jackson a...@redhat.com wrote: On Wed, 2009-06-10 at 15:13 -0500, King InuYasha wrote: EFI support is not the same as fake-EFI. Your mail client has atrociously bad indentation. Fix it. It appears from light googling that what you mean by fake EFI is a boot loader that fakes enough of EFI to be able to boot OSX on a non-Apple machine. I wasn't aware it was a goal of the Fedora project to enable you to boot some _other_ OS on arbitrary hardware, when the license of that other OS expressly forbids you from doing so. - ajax -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list Well, not necessarily Mac OS X itself. Wouldn't the Darwin kernel require it anyway? I have been installing Chameleon so I could boot the regular Darwin kernel and userland because I was told I needed a form of EFI to use the Darwin kernel. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora rawhide rebuild in mock status 2009-06-08 x86_64
Fedora Rawhide-in-Mock Build Results for x86_64 using the first rawhide of the Fedora 12 development cycle, cut on 6/8/2008. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ 2 Open Bugs which now build, and can be marked CLOSED RAWHIDE: pan: [u'476250'] ruby-rpm: [u'465103'] Total packages: 7807 Number failed to build: 348 Number expected to fail due to ExclusiveArch or ExcludeArch: 31 Leaving: 317 Of those expected to have worked... Without a bug filed: 313 -- Django-1.0.2-3.fc11 (build/make) salimma,smilner GtkAda-2.10.2-2.fc11 (build/make) gemi Macaulay2-1.2-4.fc12 (build/make) rdieter PyKDE-3.16.2-3.fc11 (build/make) rdieter,jamatos PyQwt-5.1.0-3.fc11 (build/make) tadej R-BSgenome.Celegans.UCSC.ce2-1.2.0-5 (build/make) pingou R-BSgenome.Dmelanogaster.FlyBase.r51-1.3.1-3 (build/make) pingou R-BufferedMatrixMethods-1.3.0-4.fc11 (build/make) pingou R-RScaLAPACK-0.5.1-19.fc11 (build/make) spot R-hgu95av2probe-2.0.0-1.fc9 (build/make) pingou ScientificPython-2.8-4.fc11 (build/make) jspaleta SimGear-1.9.1-5.fc12 (build/make) spot,bellet UnihanDb-5.1.0-7.fc11.1 (build/make) dchen,i18n-team almanah-0.5.0-1.fc11 (build/make) lokthare amanda-2.6.0p2-9.fc12 (build/make) dnovotny arts-1.5.10-5.fc11 (build/make) than,rdieter,kkofler,tuxbrewr asio-1.2.0-2.fc11 (build/make) uwog atlas-3.8.3-4.fc12 (build/make) deji,deji audacious-1.5.1-8.fc12 (build/make) ertzing audacious-plugin-fc-0.3-2 (build/make) mschwendt audacious-plugins-1.5.1-5.fc12 (build/make) ertzing autodir-0.99.9-7.fc11 (build/make) thias awn-extras-applets-0.3.2.1-8.fc11 (build/make) phuang,sindrepb axis-1.2.1-4.1.fc10 (build/make) pcheung bareftp-0.2.2-2.fc12 (build/make) itamarjp,cassmodiah batik-1.7-4.fc11 (build/make) langel,fitzsim beagle-0.3.9-6.fc11 (build/make) bigboard-0.6.4-9.fc11 (build/make) walters blacs-1.1-31.fc11 (build/make) spot bmpx-0.40.14-8.fc11 (build/make) akahl,cheese cdrkit-1.1.9-4.fc11 (build/make) rrakus cernlib-2006-32.fc11 (build/make) limb,pertusus chipmunk-4.1.0-6.fc11 (build/make) limb classpathx-jaf-1.0-12.fc10 (build/make) devrim,dwalluck clutter-cairo-0.8.2-3.fc11 (build/make) allisson clutter-cairomm-0.7.4-2.fc11 (build/make) denis clutter-gst-0.8.0-4.fc11 (build/make) allisson clutter-gtkmm-0.7.4-2.fc11 (build/make) denis cluttermm-0.7.5-2.fc11 (build/make) denis codeblocks-8.02-7.fc11 (build/make) sharkcz compat-db-4.6.21-5.fc10 (build/make) jnovy,pmatilai compat-erlang-R10B-13.11.fc11 (build/make) gemi compat-wxGTK26-2.6.4-7 (build/make) mschwendt conky-1.7.0-1.fc12 (build/make) mlichvar,pertusus,mlichvar couchdb-0.9.0-2.fc12 (build/make) allisson cuetools-1.4.0-0.3.svn305.fc11 (build/make) stingray dap-hdf4_handler-3.7.9-2.fc11 (build/make) pertusus,pertusus dbus-c++-0.5.0-0.8.20090203git13281b3.fc11 (build/make) drago01 ddskk-12.2.0-12.fc11 (build/make) petersen,i18n-team ecl-0.9l-4.fc11 (build/make) gemi eclipse-cdt-5.0.2-2.fc11 (build/make) jjohnstn eclipse-checkstyle-4.0.1-12.fc11 (build/make) rmyers,overholt eigen2-2.0.52-0.1.20090518.fc12 (build/make) rdieter,kkofler,mathstuf emacs-mew-6.2.51-2.fc11 (build/make) tagoh epiphany-extensions-2.26.1-2.fc12 (build/make) caillon,pgordon eric-4.3.3-1.fc12 (build/make) rdieter,ausil,trasher etherbat-1.0.1-5.fc11 (build/make) limb ettercap-0.7.3-32.fc11 (build/make) limb evolution-brutus-1.2.35-2.fc11 (build/make) bpepple evolution-rss-0.1.2-9.fc12 (build/make) lucilanga evolution-zimbra-0.1.1-6.fc11 (build/make) mbarnes,mmahut fakechroot-2.9-22.fc12 (build/make) athimm,rjones fann-2.0.0-5.1.fc11 (build/make) tsmetana fedora-business-cards-0.2.4-4.fc11 (build/make) ianweller fetchmail-6.3.9-3.fc11 (build/make) vcrhonek,pertusus filesystem-2.4.21-1.fc11 (build/make) pknirsch firewalk-5.0-4.fc11 (build/make) sindrepb fityk-0.8.1-14.fc10 (build/make) jpye fltk-1.1.9-3.fc11 (build/make) rdieter,pertusus fonts-ISO8859-2-1.0-20.fc11 (build/make) rbhalera,fonts-sig,i18n-team fonts-hebrew-fancy-0.20051122-5.fc11 (build/make) danken,fonts-sig fpc-2.2.2-3.fc10 (build/make) joost,tbzatek freefem++-3.0-5.5.fc11 (patch_fuzz) rathann frysk-0.4-8.fc11 (build/make) cagney,pmuldoon,swagiaal fusecompress-2.5-1.fc12 (build/make) lkundrak,lmacken gbdfed-1.4-2.fc11 (build/make) spot gc-7.1-7.fc11 (build/make) rdieter gcdmaster-1.2.2-5.fc11 (build/make) denis gdal-1.6.0-8.fc11 (build/make) rezso,pertusus gedit-vala-0.4.1-2.fc11 (build/make) salimma geronimo-specs-1.0-2.M2.fc10 (build/make) fnasser gettext-0.17-11.fc12 (build/make) petersen,i18n-team gflags-1.0-3.fc11 (build/make) rakesh gget-0.0.4-9.fc11 (build/make) ant glob2-0.9.3-2.fc11 (build/make) rafalzaq globus-core-5.15-4.fc12 (build/make) ellert gloox-1.0-0.5.SVNr4003.fc12 (build/make) hubbitus gmfsk-0.7-0.6.pre1.fc11 (build/make) bjensen,bjensen,sindrepb,sconklin,dp67 gmime-2.4.3-3.fc11 (build/make) alexl,thl gmime22-2.2.23-5.fc11 (build/make) bjohnson gmrun-0.9.2-16.fc11 (build/make) gilboa gnome-scan-0.6.2-1.fc11 (build/make) deji gnome-specimen-0.3-4.fc11 (build/make)
Fedora rawhide rebuild in mock status 2009-06-08 i386
Fedora Rawhide-in-Mock Build Results for i386 using the first rawhide of the Fedora 12 development cycle, cut on 6/8/2008. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ 2 Open Bugs which now build, and can be marked CLOSED RAWHIDE: pan: [u'476250'] ruby-rpm: [u'465103'] Total packages: 7808 Number failed to build: 355 Number expected to fail due to ExclusiveArch or ExcludeArch: 17 Leaving: 338 Of those expected to have worked... Without a bug filed: 334 -- Django-1.0.2-3.fc11 (build/make) salimma,smilner GtkAda-2.10.2-2.fc11 (build/make) gemi PyKDE-3.16.2-3.fc11 (build/make) rdieter,jamatos PyQuante-1.6.3-1.fc11 (build/make) jussilehtola PyQwt-5.1.0-3.fc11 (build/make) tadej R-BSgenome.Celegans.UCSC.ce2-1.2.0-5 (build/make) pingou R-BSgenome.Dmelanogaster.FlyBase.r51-1.3.1-3 (build/make) pingou R-BufferedMatrixMethods-1.3.0-4.fc11 (build/make) pingou R-RScaLAPACK-0.5.1-19.fc11 (build/make) spot R-hgu95av2probe-2.0.0-1.fc9 (build/make) pingou ScientificPython-2.8-4.fc11 (build/make) jspaleta SimGear-1.9.1-5.fc12 (build/make) spot,bellet UnihanDb-5.1.0-7.fc11.1 (build/make) dchen,i18n-team almanah-0.5.0-1.fc11 (build/make) lokthare amanda-2.6.0p2-9.fc12 (build/make) dnovotny arj-3.10.22-8.fc12 (build/make) robert,lyosnorezel arts-1.5.10-5.fc11 (build/make) than,rdieter,kkofler,tuxbrewr artwiz-aleczapka-fonts-1.3-7.fc11 (build/make) spot,fonts-sig,awjb asio-1.2.0-2.fc11 (build/make) uwog asterisk-sounds-core-1.4.15-1.fc11 (build/make) jcollie atasm-1.06-2.fc11 (build/make) sharkcz atlas-3.8.3-4.fc12 (build/make) deji,deji audacious-1.5.1-8.fc12 (build/make) ertzing audacious-plugin-fc-0.3-2 (build/make) mschwendt audacious-plugins-1.5.1-5.fc12 (build/make) ertzing auriferous-1.0.1-7.fc11 (build/make) jwrdegoede autodir-0.99.9-7.fc11 (build/make) thias awn-extras-applets-0.3.2.1-8.fc11 (build/make) phuang,sindrepb axis-1.2.1-4.1.fc10 (build/make) pcheung baekmuk-ttf-fonts-2.2-21.fc11 (build/make) cchance,fonts-sig,i18n-team,petersen bareftp-0.2.2-2.fc12 (build/make) itamarjp,cassmodiah batik-1.7-4.fc11 (build/make) langel,fitzsim beagle-0.3.9-6.fc11 (build/make) bigboard-0.6.4-9.fc11 (build/make) walters blacs-1.1-31.fc11 (build/make) spot bmpx-0.40.14-8.fc11 (build/make) akahl,cheese bug-buddy-2.27.1-2.fc12 (unpackaged_files/python-egg-info?) rstrode ccrtp-1.7.1-1.fc11 (build/make) ixs cdrkit-1.1.9-4.fc11 (build/make) rrakus cernlib-2006-32.fc11 (build/make) limb,pertusus chipmunk-4.1.0-6.fc11 (build/make) limb classpathx-jaf-1.0-12.fc10 (build/make) devrim,dwalluck clutter-cairo-0.8.2-3.fc11 (build/make) allisson clutter-cairomm-0.7.4-2.fc11 (build/make) denis clutter-gst-0.8.0-4.fc11 (build/make) allisson clutter-gtkmm-0.7.4-2.fc11 (build/make) denis cluttermm-0.7.5-2.fc11 (build/make) denis codeblocks-8.02-7.fc11 (build/make) sharkcz compat-db-4.6.21-5.fc10 (build/make) jnovy,pmatilai compat-erlang-R10B-13.11.fc11 (build/make) gemi compat-wxGTK26-2.6.4-7 (build/make) mschwendt cone-0.75-5.fc11 (build/make) steve conky-1.7.0-1.fc12 (build/make) mlichvar,pertusus,mlichvar couchdb-0.9.0-2.fc12 (build/make) allisson cuetools-1.4.0-0.3.svn305.fc11 (build/make) stingray dap-hdf4_handler-3.7.9-2.fc11 (build/make) pertusus,pertusus dbus-c++-0.5.0-0.8.20090203git13281b3.fc11 (build/make) drago01 ddskk-12.2.0-12.fc11 (build/make) petersen,i18n-team django-tagging-0.3-1.fc11.20080217svnr154 (build/make) ivazquez ecl-0.9l-4.fc11 (build/make) gemi eclipse-cdt-5.0.2-2.fc11 (build/make) jjohnstn eclipse-checkstyle-4.0.1-12.fc11 (build/make) rmyers,overholt eigen2-2.0.52-0.1.20090518.fc12 (build/make) rdieter,kkofler,mathstuf emacs-mew-6.2.51-2.fc11 (build/make) tagoh ember-0.5.6-1.fc12 (build/make) atorkhov,wart epiphany-extensions-2.26.1-2.fc12 (build/make) caillon,pgordon eric-4.3.3-1.fc12 (build/make) rdieter,ausil,trasher etherbat-1.0.1-5.fc11 (build/make) limb ettercap-0.7.3-32.fc11 (build/make) limb evolution-brutus-1.2.35-2.fc11 (build/make) bpepple evolution-rss-0.1.2-9.fc12 (build/make) lucilanga evolution-zimbra-0.1.1-6.fc11 (build/make) mbarnes,mmahut f-spot-0.5.0.3-8.fc11 (build/make) nigelj,dgoodwin fakechroot-2.9-22.fc12 (build/make) athimm,rjones fann-2.0.0-5.1.fc11 (build/make) tsmetana fedora-business-cards-0.2.4-4.fc11 (build/make) ianweller fetchmail-6.3.9-3.fc11 (build/make) vcrhonek,pertusus filesystem-2.4.21-1.fc11 (build/make) pknirsch firewalk-5.0-4.fc11 (build/make) sindrepb fityk-0.8.1-14.fc10 (build/make) jpye fltk-1.1.9-3.fc11 (build/make) rdieter,pertusus freefem++-3.0-5.5.fc11 (patch_fuzz) rathann frysk-0.4-8.fc11 (build/make) cagney,pmuldoon,swagiaal fusecompress-2.5-1.fc12 (build/make) lkundrak,lmacken gauche-gl-0.4.4-4.fc11 (build/make) gemi gauche-gtk-0.4.1-18.fc11 (build/make) gemi gbdfed-1.4-2.fc11 (build/make) spot gbrainy-1.1-3.fc11 (build/make) sereinit gc-7.1-7.fc11 (build/make) rdieter gcdmaster-1.2.2-5.fc11 (build/make) denis gdal-1.6.0-8.fc11 (build/make) rezso,pertusus gedit-vala-0.4.1-2.fc11 (build/make) salimma
Re: Fedora rawhide rebuild in mock status 2009-06-08 x86_64
Le mercredi 10 juin 2009 à 17:06 -0500, Matt Domsch a écrit :
Fedora Rawhide-in-Mock Build Results for x86_64
using the first rawhide of the Fedora 12 development cycle, cut on 6/8/2008.
Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/
Of those expected to have worked...
Without a bug filed: 313
--
levien-inconsolata-fonts-1.01-3.fc11 (build/make) kevin
...
This one and probably other font packages use a pattern like
%_font_pkg -f %{fontconf} *.ttf
%doc *.pdf
For some reason the %_font_pkg macro call is eating the EOL, so %doc
*.pdf ends up at the end of the last line of the macro output and not
on the next line.
This is probably a bug or quirk in rpm. I suppose since we are at the
very start of the F12 cycle I should report the problem and not have the
macro generate an empty final line to workaround it brutaly.
--
Nicolas Mailhot
signature.asc
Description: Ceci est une partie de message numériquement signée
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
Jeremy Katz wrote: I need to sit down and figure out where [grub2] is in the realm of capability vs our grub[1] these days, but just haven't had enough round 'tuits. Next year (2010) is the year for new harddrives with a hardware sector size of 4096 bytes instead of 512. All boot loaders will have a fun time! -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora rawhide rebuild in mock status 2009-06-08 x86_64
Am Mittwoch, den 10.06.2009, 17:06 -0500 schrieb Matt Domsch: cwickert: gwget,xfce4-clipman-plugin clipman-plugin is fixed, gwget only fixed in CVS and I'm waiting for the buildsys to come up again. Thanks for your report, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates testing for F-11
Bojan Smojver bojan at rexursive.com writes: Maybe I missed something, but it seems that some updates that have been submitted for F-11 testing are still pending. Any ideas why that is? I meant to say, submitted over a week ago. -- Bojan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates testing for F-11
Rahul Sundaram sundaram at fedoraproject.org writes: They are probably waiting on rel-eng to sign the packages. If you can be more specific, it would be easier to tell you what the status is. viewvc-1.1.1. Also, it would be good if various apr-util packages (from F-9 to F-11 could be pushed to testing). They contain security fixes. -- Bojan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On Wed, Jun 10, 2009 at 17:17:07 -0400, Jeremy Katz ka...@redhat.com wrote: we've been left in a position of maintaining it and we've added some real features that have been needed along the way as grub 2's progress has been slow at best and some of the design decisions early on were a I was watching them for a while to see if was something I wanted to try and after the project went several months with no apparent commits, I figured this was something I probably didn't want to play with. Depending on grub2 to have active development seems a bit risky to me. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates testing for F-11
On Thu, Jun 11, 2009 at 07:44:24 +0530, Rahul Sundaram sunda...@fedoraproject.org wrote: On 06/11/2009 07:39 AM, Bojan Smojver wrote: Bojan Smojver bojan at rexursive.com writes: Maybe I missed something, but it seems that some updates that have been submitted for F-11 testing are still pending. Any ideas why that is? I meant to say, submitted over a week ago. They are probably waiting on rel-eng to sign the packages. If you can be more specific, it would be easier to tell you what the status is. It may also be a case of not wanting to produce more churn right at release time. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Bug 496096] DBD::SQLite 1.21 is out...
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=496096 Marcela Maslanova mmasl...@redhat.com changed: What|Removed |Added Status|ON_DEV |CLOSED Resolution||ERRATA --- Comment #4 from Marcela Maslanova mmasl...@redhat.com 2009-06-10 03:31:13 EDT --- In F-11 will be 1.23. Please reopen in case there would be some problem. -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Compress-Raw-Zlib/EL-5 perl-Compress-Raw-Zlib.spec, 1.4, 1.5
Author: kasal
Update of /cvs/extras/rpms/perl-Compress-Raw-Zlib/EL-5
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv13907
Modified Files:
perl-Compress-Raw-Zlib.spec
Log Message:
Fix license tag, remove BR: perl.
Index: perl-Compress-Raw-Zlib.spec
===
RCS file:
/cvs/extras/rpms/perl-Compress-Raw-Zlib/EL-5/perl-Compress-Raw-Zlib.spec,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- perl-Compress-Raw-Zlib.spec 29 Aug 2007 05:32:10 - 1.4
+++ perl-Compress-Raw-Zlib.spec 10 Jun 2009 09:39:22 - 1.5
@@ -1,15 +1,15 @@
Name: perl-Compress-Raw-Zlib
Version:2.005
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Low-Level Interface to the zlib compression library
Group: Development/Libraries
-License:Artistic or GPL
+License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Compress-Raw-Zlib/
Source0:
http://search.cpan.org/CPAN/authors/id/P/PM/PMQS/Compress-Raw-Zlib-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-BuildRequires: perl, perl(ExtUtils::MakeMaker), zlib-devel, perl(Test::Pod)
+BuildRequires: perl(ExtUtils::MakeMaker), zlib-devel, perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
@@ -57,6 +57,10 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Oct 23 2007 Robin Norwood rnorw...@redhat.com - 2.005-4
+- Fix license tag
+- Remove BR: perl
+
* Wed Aug 29 2007 Fedora Release Engineering rel-eng at fedoraproject dot
org - 2.005-3
- Rebuild for selinux ppc32 issue.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 430072] xdg-open should call mimeopen with -L option
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=430072 Patrice Dumas pertu...@free.fr changed: What|Removed |Added Version|9 |rawhide -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Compress-Raw-Zlib/EL-5 .cvsignore, 1.3, 1.4 perl-Compress-Raw-Zlib.spec, 1.5, 1.6 sources, 1.3, 1.4
Author: kasal
Update of /cvs/extras/rpms/perl-Compress-Raw-Zlib/EL-5
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv31377
Modified Files:
.cvsignore perl-Compress-Raw-Zlib.spec sources
Log Message:
update to 2.020
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-Compress-Raw-Zlib/EL-5/.cvsignore,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- .cvsignore 2 Jul 2007 03:45:19 - 1.3
+++ .cvsignore 10 Jun 2009 10:42:30 - 1.4
@@ -1 +1 @@
-Compress-Raw-Zlib-2.005.tar.gz
+Compress-Raw-Zlib-2.020.tar.gz
Index: perl-Compress-Raw-Zlib.spec
===
RCS file:
/cvs/extras/rpms/perl-Compress-Raw-Zlib/EL-5/perl-Compress-Raw-Zlib.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- perl-Compress-Raw-Zlib.spec 10 Jun 2009 09:39:22 - 1.5
+++ perl-Compress-Raw-Zlib.spec 10 Jun 2009 10:42:31 - 1.6
@@ -1,6 +1,6 @@
Name: perl-Compress-Raw-Zlib
-Version:2.005
-Release:4%{?dist}
+Version:2.020
+Release:1%{?dist}
Summary:Low-Level Interface to the zlib compression library
Group: Development/Libraries
@@ -57,6 +57,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Wed Jun 10 2009 Stepan Kasal ska...@redhat.com - 2.020-1
+- update to the latest upstream version (504386)
+
* Tue Oct 23 2007 Robin Norwood rnorw...@redhat.com - 2.005-4
- Fix license tag
- Remove BR: perl
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Compress-Raw-Zlib/EL-5/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 2 Jul 2007 03:45:19 - 1.3
+++ sources 10 Jun 2009 10:42:31 - 1.4
@@ -1 +1 @@
-3e56b9e584a5a54d550d411261ea8ba9 Compress-Raw-Zlib-2.005.tar.gz
+d0f6baff3d38b6076a14778004345db3 Compress-Raw-Zlib-2.020.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-ORLite-Migrate/devel perl-ORLite-Migrate-req.patch, NONE, 1.1 perl-ORLite-Migrate.spec, 1.4, 1.5
Author: kasal
Update of /cvs/extras/rpms/perl-ORLite-Migrate/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20747
Modified Files:
perl-ORLite-Migrate.spec
Added Files:
perl-ORLite-Migrate-req.patch
Log Message:
- work around a problem with crazy perl versioning
perl-ORLite-Migrate-req.patch:
--- NEW FILE perl-ORLite-Migrate-req.patch ---
2009-06-10 Stepan Kasal ska...@redhat.com
Require File::Spec 2.28, rpm is not able to grok the crazy
perl versioning.
--- ORLite-Migrate-0.03/lib/ORLite/Migrate.pm.orig 2009-04-19
14:18:00.0 +0200
+++ ORLite-Migrate-0.03/lib/ORLite/Migrate.pm 2009-06-10 14:38:43.0
+0200
@@ -5,7 +5,7 @@
use 5.006;
use strict;
use Carp ();
-use File::Spec 3.2701 ();
+use File::Spec 3.28 ();
use File::Path 2.04 ();
use File::Basename();
use Params::Util 0.37 qw{ _STRING _CLASS _HASH };
Index: perl-ORLite-Migrate.spec
===
RCS file: /cvs/extras/rpms/perl-ORLite-Migrate/devel/perl-ORLite-Migrate.spec,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- perl-ORLite-Migrate.spec3 Jun 2009 13:10:32 - 1.4
+++ perl-ORLite-Migrate.spec10 Jun 2009 12:49:44 - 1.5
@@ -1,6 +1,6 @@
Name: perl-ORLite-Migrate
Version:0.03
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Light weight SQLite-specific schema migration
License:GPL+ or Artistic
Group: Development/Libraries
@@ -27,6 +27,8 @@ Requires: perl(Params::Util) = 0.
Requires: perl(Probe::Perl)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Patch0: perl-ORLite-Migrate-req.patch
+
%description
THIS CODE IS EXPERIMENTAL AND SUBJECT TO CHANGE WITHOUT NOTICE
SQLite is a light weight single file SQL database that provides an excellent
platform for embedded
@@ -36,6 +38,7 @@ weight single class Database Schema Migr
%prep
%setup -q -n ORLite-Migrate-%{version}
+%patch0 -p1
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -65,6 +68,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jun 10 2009 Stepan Kasal ska...@redhat.com 0.03-2
+- work around a problem with crazy perl versioning
+
* Wed Jun 3 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.03-1
- update
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-ORLite-Migrate/devel perl-ORLite-Migrate.spec,1.5,1.6
Author: kasal
Update of /cvs/extras/rpms/perl-ORLite-Migrate/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv23078
Modified Files:
perl-ORLite-Migrate.spec
Log Message:
- work around a problem with crazy perl versioning
Index: perl-ORLite-Migrate.spec
===
RCS file: /cvs/extras/rpms/perl-ORLite-Migrate/devel/perl-ORLite-Migrate.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- perl-ORLite-Migrate.spec10 Jun 2009 12:49:44 - 1.5
+++ perl-ORLite-Migrate.spec10 Jun 2009 12:58:16 - 1.6
@@ -27,7 +27,11 @@ Requires: perl(Params::Util) = 0.
Requires: perl(Probe::Perl)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-Patch0: perl-ORLite-Migrate-req.patch
+# File::Spec = 3.2701 is required, but rpm does not understand that...
+# a) ... 3.30 is enough,
+Patch0: perl-ORLite-Migrate-req.patch
+# b) ... but 3.2501 is not enough
+Requires: perl = 4:5.10.0-70
%description
THIS CODE IS EXPERIMENTAL AND SUBJECT TO CHANGE WITHOUT NOTICE
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 473407] Every invocation of svk generates the same warning.
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=473407 --- Comment #8 from Derek Atkins warl...@mit.edu 2009-06-10 10:11:34 EDT --- This is still an issue in Fedora 10. I haven't tested Fedora 11. This isn't my bug so I can't change the version. -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 473407] Every invocation of svk generates the same warning.
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=473407 --- Comment #9 from Robert P. J. Day rpj...@crashcourse.ca 2009-06-10 10:17:10 EDT --- It may be worth noting that svk's developer has announced that he will no longer be supporting it. So all this could be moot. -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-DBD-SQLite/devel perl-DBD-SQLite.spec,1.27,1.28
Author: kasal
Update of /cvs/extras/rpms/perl-DBD-SQLite/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv30888
Modified Files:
perl-DBD-SQLite.spec
Log Message:
rebuild against DBI 1.609
Index: perl-DBD-SQLite.spec
===
RCS file: /cvs/extras/rpms/perl-DBD-SQLite/devel/perl-DBD-SQLite.spec,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -p -r1.27 -r1.28
--- perl-DBD-SQLite.spec29 May 2009 07:40:48 - 1.27
+++ perl-DBD-SQLite.spec10 Jun 2009 15:03:06 - 1.28
@@ -1,6 +1,6 @@
Name: perl-DBD-SQLite
Version:1.25
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Self Contained RDBMS in a DBI Driver
Group: Development/Libraries
@@ -9,7 +9,6 @@ URL:http://search.cpan.org/d
Source0:
http://search.cpan.org/CPAN/authors/id/A/AD/ADAMK/DBD-SQLite-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-BuildRequires: perl-DBI = 1.03
# if sqlite = 3.1.3 then
# perl-DBD-SQLite uses the external library
# else
@@ -18,7 +17,9 @@ BuildRequires: sqlite-devel
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More) = 0.42
BuildRequires: perl(File::Spec) = 0.82
-BuildRequires: perl(DBI) = 1.57
+# Prevent bug #443495
+BuildRequires: perl(DBI) = 1.607
+
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
@@ -67,6 +68,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Wed Jun 10 2009 Stepan Kasal ska...@redhat.com 1.25-1
+- rebuild against DBI 1.609
+
* Fri May 29 2009 Chris Weyl cw...@alumni.drew.edu 1.25-1
- 1.25 needed for DBIx::Class 0.08103
- auto-update to 1.25 (by cpan-spec-update 0.01)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-DBD-SQLite/devel perl-DBD-SQLite.spec,1.28,1.29
Author: kasal Update of /cvs/extras/rpms/perl-DBD-SQLite/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv31480 Modified Files: perl-DBD-SQLite.spec Log Message: typo Index: perl-DBD-SQLite.spec === RCS file: /cvs/extras/rpms/perl-DBD-SQLite/devel/perl-DBD-SQLite.spec,v retrieving revision 1.28 retrieving revision 1.29 diff -u -p -r1.28 -r1.29 --- perl-DBD-SQLite.spec10 Jun 2009 15:03:06 - 1.28 +++ perl-DBD-SQLite.spec10 Jun 2009 15:05:25 - 1.29 @@ -68,7 +68,7 @@ rm -rf $RPM_BUILD_ROOT %changelog -* Wed Jun 10 2009 Stepan Kasal ska...@redhat.com 1.25-1 +* Wed Jun 10 2009 Stepan Kasal ska...@redhat.com 1.25-2 - rebuild against DBI 1.609 * Fri May 29 2009 Chris Weyl cw...@alumni.drew.edu 1.25-1 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 473407] Every invocation of svk generates the same warning.
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=473407 --- Comment #10 from Derek Atkins warl...@mit.edu 2009-06-10 11:07:49 EDT --- While true, I think the problem is more based in the SVN Swig bindings so still appropriate. However that's probably bug #480503Still, I think F11 still has SVK so this would still be an issue. And F10 certainly has SVK and it IS an issue. -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 438244] No cpanget man page
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=438244 Jonathan Kamens j...@kamens.brookline.ma.us changed: What|Removed |Added Version|9 |rawhide -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 438251] Can't deference $Module::CoreList::versions{$]} in perl 5.10
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=438251 Jonathan Kamens j...@kamens.brookline.ma.us changed: What|Removed |Added Status|NEW |CLOSED Resolution||CURRENTRELEASE --- Comment #4 from Jonathan Kamens j...@kamens.brookline.ma.us 2009-06-10 11:48:29 EDT --- Works in F11. -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Alien-SeleniumRC/F-11 import.log, NONE, 1.1 perl-Alien-SeleniumRC.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: eseyman
Update of /cvs/pkgs/rpms/perl-Alien-SeleniumRC/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv5414/F-11
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Alien-SeleniumRC.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-Alien-SeleniumRC-1_00-1_fc11:F-11:perl-Alien-SeleniumRC-1.00-1.fc11.src.rpm:1244672776
--- NEW FILE perl-Alien-SeleniumRC.spec ---
Name: perl-Alien-SeleniumRC
Version:1.00
Release:1%{?dist}
Summary:Packages the Selenium Remote Control server
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Alien-SeleniumRC/
Source0:
http://www.cpan.org/modules/by-module/Alien/Alien-SeleniumRC-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker),perl(CPAN),perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
Selenium Remote Control is a test tool that allows you to write automated
web application UI tests in any programming language against any HTTP
website using any mainstream JavaScript-enabled browser. It provides a
Selenium Server, which can automatically start/stop/control any supported
browser. It works by using Selenium Core, a pure-HTML+JS library that
performs automated tasks in JavaScript.
%prep
%setup -q -n Alien-SeleniumRC-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_bindir}/selenium-rc
%{_mandir}/man3/*
%changelog
* Tue Apr 14 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr 1.00-1
- Update to 1.00
* Wed Nov 05 2008 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.91-2
- Specfile autogenerated by cpanspec 1.77.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Alien-SeleniumRC/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 10 Jun 2009 20:57:55 - 1.1
+++ .cvsignore 10 Jun 2009 22:27:02 - 1.2
@@ -0,0 +1 @@
+Alien-SeleniumRC-1.00.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Alien-SeleniumRC/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 10 Jun 2009 20:57:55 - 1.1
+++ sources 10 Jun 2009 22:27:02 - 1.2
@@ -0,0 +1 @@
+8dfe7a67b2246e6ceb85a912fd642687 Alien-SeleniumRC-1.00.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
