Re: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
Le Jeu 17 septembre 2009 02:47, Jesse Keating a écrit : > On Wed, 2009-09-16 at 20:08 -0400, Neal Becker wrote: >> Why not report all conflicts, instead of only those on your PATH? > > Because these aren't file level conflicts, as in they can both exist on > the filesystem at the same time and RPM won't care. However they can > lead to unexpected things due to PATH collision, if you type "foo" and > there are multiple "foo"'s in your path, are you sure you know which one > you'll get? Well, for $PATH dirs you need to check the basename, for others you need to check the full name (and hash, and perms). Both checks are valid and useful -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
On Wed, 2009-09-16 at 20:08 -0400, Neal Becker wrote: > Why not report all conflicts, instead of only those on your PATH? This is acting at the level of individual filenames (dropping the directory component from the path), and doesn't have any knowledge about a file beyond its full installation path. The PATH filtering allows it to avoid lots of false-positives from all of the various "COPYING", "README" etc files we drop into various places in the filesystem. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
On Wed, Sep 16, 2009 at 21:10:16 -0400, Neal Becker wrote: > > But the original problem was a file level conflict. Is it ever valid for 2 > packages to own the same file? Yes. At a minimum the file's contents has to be identical in the two packages. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
Jesse Keating wrote: > On Wed, 2009-09-16 at 20:08 -0400, Neal Becker wrote: >> Why not report all conflicts, instead of only those on your PATH? > > Because these aren't file level conflicts, as in they can both exist on > the filesystem at the same time and RPM won't care. However they can > lead to unexpected things due to PATH collision, if you type "foo" and > there are multiple "foo"'s in your path, are you sure you know which one > you'll get? > But the original problem was a file level conflict. Is it ever valid for 2 packages to own the same file? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
On Wed, 2009-09-16 at 17:32 -0700, J. Randall Owens wrote: > Why not just have a system somewhere with Everything installed, including new > stuff? That's what I almost have myself, and I noticed the libotf/openmpi > conflict quite a while ago (it's why I don't have the latter installed > anymore). Because that's difficult to maintain in an automated test world, where you'd like to run such tests after each and every build. -- 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: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
On Wed, 2009-09-16 at 20:08 -0400, Neal Becker wrote: > Why not report all conflicts, instead of only those on your PATH? Because these aren't file level conflicts, as in they can both exist on the filesystem at the same time and RPM won't care. However they can lead to unexpected things due to PATH collision, if you type "foo" and there are multiple "foo"'s in your path, are you sure you know which one you'll get? -- 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: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/16/2009 05:08 PM, Neal Becker wrote: > Why not report all conflicts, instead of only those on your PATH? Why not just have a system somewhere with Everything installed, including new stuff? That's what I almost have myself, and I noticed the libotf/openmpi conflict quite a while ago (it's why I don't have the latter installed anymore). - -- J. Randall Owens | http://www.ghiapet.net/ ProofReading Markup Language | http://prml.sourceforge.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqxg3UACgkQdGy7nCl1Vp+HCQCfaBaKw8NBmVNNienKBqQo5gi5 ti4Ani6Hv041RC5kQyx7Uw1KyfzOQo1K =1Zp2 -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
Why not report all conflicts, instead of only those on your PATH? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
On Wed, 2009-09-16 at 18:45 -0400, Neal Becker wrote: > Which makes me wonder, how could this conflict have been avoided? Is there > a tool that would check any new package to see if any object* in it would > conflict with any existing package? If not, sounds like a good thing to > have. > > * Here, object means filesystem object. I'm not sure if there are any other > types of objects to worry about. Brainstorming: a script that walks the yum repo's filelist.tar.gz, and figures out a list of filename collisions, filtering by directories in the default PATH Attached is a first pass at a python script that does this. Output from the script when run upon [1] is below. Caveat: the script probably has bugs. Does this look useful? ulockmgr_server /bin/ulockmgr_server from fuse /usr/bin/ulockmgr_server from fuse telnet /usr/bin/telnet from telnet /usr/kerberos/bin/telnet from krb5-workstation-clients gzip /bin/gzip from gzip /usr/bin/gzip from gzip fusermount /bin/fusermount from fuse /usr/bin/fusermount from fuse stap-env /usr/bin/stap-env from systemtap-client /usr/bin/stap-env from systemtap /usr/bin/stap-env from systemtap-server winemaker /usr/bin/winemaker from wine-devel /usr/bin/winemaker from wine-common ftp /usr/bin/ftp from ftp /usr/kerberos/bin/ftp from krb5-workstation-clients pinentry /usr/bin/pinentry from pinentry /usr/bin/pinentry from pinentry-gtk /usr/bin/pinentry from pinentry-qt kadmin /usr/kerberos/bin/kadmin from krb5-workstation-servers /usr/kerberos/bin/kadmin from krb5-workstation lzcmp /usr/bin/lzcmp from xz-lzma-compat /usr/bin/lzcmp from lzma lzgrep /usr/bin/lzgrep from xz-lzma-compat /usr/bin/lzgrep from lzma lzdiff /usr/bin/lzdiff from xz-lzma-compat /usr/bin/lzdiff from lzma lzcat /usr/bin/lzcat from xz-lzma-compat /usr/bin/lzcat from lzma lzmainfo /usr/bin/lzmainfo from xz-lzma-compat /usr/bin/lzmainfo from lzma lzfgrep /usr/bin/lzfgrep from xz-lzma-compat /usr/bin/lzfgrep from lzma plymouth /bin/plymouth from plymouth /usr/bin/plymouth from plymouth gawk /bin/gawk from gawk /usr/bin/gawk from gawk ex /bin/ex from vim-minimal /usr/bin/ex from vim-enhanced ircd /usr/bin/ircd from ircd-ratbox /usr/bin/ircd from ircd-hybrid cut /bin/cut from coreutils /usr/bin/cut from coreutils towhee-mpi /usr/bin/towhee-mpi from towhee-mpi /usr/bin/towhee-mpi from towhee pscp /usr/bin/pscp from putty /usr/bin/pscp from pssh links /usr/bin/links from links /usr/bin/links from elinks rsh /usr/kerberos/bin/rsh from krb5-workstation-clients /usr/bin/rsh from rsh awk /bin/awk from gawk /usr/bin/awk from gawk tmda-ofmipd /usr/bin/tmda-ofmipd from tmda-ofmipd /usr/bin/tmda-ofmipd from tmda kvno /usr/kerberos/bin/kvno from krb5-workstation-servers /usr/kerberos/bin/kvno from krb5-workstation sclient /usr/kerberos/bin/sclient from krb5-devel /usr/kerberos/bin/sclient from krb5-server unlzma /usr/bin/unlzma from xz-lzma-compat /usr/bin/unlzma from lzma ktutil /usr/kerberos/bin/ktutil from krb5-workstation-servers /usr/kerberos/bin/ktutil from krb5-workstation lzegrep /usr/bin/lzegrep from xz-lzma-compat /usr/bin/lzegrep from lzma ntfs-3g /bin/ntfs-3g from ntfs-3g /usr/bin/ntfs-3g from ntfs-3g k5srvutil /usr/kerberos/bin/k5srvutil from krb5-workstation-servers /usr/kerberos/bin/k5srvutil from krb5-workstation rlogin /usr/kerberos/bin/rlogin from krb5-workstation-clients /usr/bin/rlogin from rsh stap-find-servers /usr/bin/stap-find-servers from systemtap-client /usr/bin/stap-find-servers from systemtap-server lzma /usr/bin/lzma from xz-lzma-compat /usr/bin/lzma from lzma kde4-doxygen.sh /usr/bin/kde4-doxygen.sh from kdelibs-devel /usr/bin/kde4-doxygen.sh from kdelibs find /bin/find from findutils /usr/bin/find from findutils jasper5-setclasspath.sh /usr/bin/jasper5-setclasspath.sh from tomcat5 /usr/bin/jasper5-setclasspath.sh from tomcat5-jasper translate /usr/bin/translate from libtranslate /usr/bin/translate from surfraw stap-gen-cert /usr/bin/stap-gen-cert from systemtap /usr/bin/stap-gen-cert from systemtap-server stap-authorize-cert /usr/bin/stap-authorize-cert from systemtap /usr/bin/stap-authorize-cert from systemtap-server rcp /usr/kerberos/bin/rcp from krb5-workstation-clients /usr/kerberos/bin/rcp from krb5-workstation-servers /usr/bin/rcp from rsh env /bin/env from coreutils /usr/bin/env from coreutils jspc5.sh /usr/bin/jspc5.sh from tomcat5 /usr/bin/jspc5.sh from tomcat5-jasper synergyc /usr/bin/synergyc from synergy /usr/bin/synergyc from synergy-plus synergys /usr/bin/synergys from synergy /usr/bin/synergys from synergy-plus xemacs /usr/bin/xemacs from xemacs-nox /usr/bin/xemacs from xemacs kill /bin/kill from util-linux-ng /usr/bin/kill from util-linux-ng gettext /bin/gettext from gettext /usr/bin/gettext from gettext winedump
Fedora 12 Beta Review Meeting--Friday 2009-09-18 @ 15:00 UTC (11 AM EDT)
When: Friday, 2009-09-18 @ 15:00 UTC (11 AM EDT) Where: #fedora-bugzappers on irc.freenode.net Join us Friday for the second blocker bug review of the F-12-Beta cycle. Review will focus on unresolved bugs listed on the F12Beta list Have an issue you'd like to propose for F12Beta? Please consider the following criteria when escalating an issue: * Can this issue be fixed with a future rawhide update or is it part of the media kit? * Is this defect a high (or greater) severity [1] with no, or an unreasonable, workaround? * Does the presence of this bug dramatically reduce test coverage? If in doubt add it to the blocker or ask for help. The current list of Fedora 12 Beta blocker bugs follows: F12Beta--https://bugzilla.redhat.com/showdependencytree.cgi?id=507678&hide_resolved=1 * 498591 [MODIFIED - medium - dleh...@redhat.com - --- -] Cannot specify mount point for hard disk partition containing the ISO install image [See dependency tree for bug 498591] *515450 [MODIFIED - medium - rvyky...@redhat.com - --- -] Stage1: cannot back to last step . [See dependency tree for bug 515450] *516042 [MODIFIED - medium - rvyky...@redhat.com - --- - Reopened] Unable to add NFS yum repo during installation [See dependency tree for bug 516042] *517260 [ASSIGNED - medium - anaconda-maint-l...@redhat.com - --- -] liveinst fails at partitioning screen [See dependency tree for bug 517260] *518194 [MODIFIED - medium - rvyky...@redhat.com - --- -] askmethod boot option allows installation from HDD only [See dependency tree for bug 518194] *518226 [NEW - medium - kernel-ma...@redhat.com - --- -] INFO: possible circular locking dependency detected - 2.6.31-0.125.4.2.rc5.git2.fc12.ppc64 [See dependency tree for bug 518226] *519237 [NEW - medium - cdah...@redhat.com - --- -] -bash: cannot set terminal process group (-1): Inappropriate ioctl for device [See dependency tree for bug 519237] *520207 [NEW - high - dcantr...@redhat.com - --- -] Filesystem label does not match kernel command line parameter [See dependency tree for bug 520207] We will also review the Fedora 12 Blocker (bugs that must be fixed before Fedora 12 can go GA) F12Blocker--https://bugzilla.redhat.com/showdependencytree.cgi?id=473303&hide_resolved=1 * 481068 [ASSIGNED - medium - psatp...@redhat.com - --- -] bitmap-fonts needs updating to revised packaging guidelines [See dependency tree for bug 481068] *493058 [MODIFIED - high - jgran...@redhat.com - --- -] Custom partitioning creation/edit causes traceback [See dependency tree for bug 493058] *493472 [NEW - medium - k...@redhat.com - --- -] [945GM] KMS: LVDS wrongly detected as connected, DVI monitor resolution incorrectly set [See dependency tree for bug 493472] *498156 [ASSIGNED - urgent - sahar...@xs4all.nl - --- -] gadmin-squid does not generate valid squid.conf [See dependency tree for bug 498156] *498968 [NEW - medium - mar...@redhat.com - --- -] Fedora 12 Virtualization Target Blocker [See dependency tree for bug 498968] o480593 [NEW - medium - nott...@redhat.com - --- - Tracking] Fedora 11 Virtualization Blocker [See dependency tree for bug 480593] o507397 [NEW - medium - lvm-t...@redhat.com - --- -] Directory permissions on volume group directory too restrictive [See dependency tree for bug 507397] o517151 [ASSIGNED - high - crobi...@redhat.com - --- -] virtinst creates cdrom device using virtio rather than IDE [See dependency tree for bug 517151] *501769 [NEW - medium - jkys...@redhat.com - --- -] intel hda: snd_pcm_avail/snd_pcm_delay overflows [See dependency tree for bug 501769] *503149 [NEW - medium - anaconda-maint-l...@redhat.com - --- -] Add features to Anaconda to aid installation on Apple computers [See dependency tree for bug 503149] *506075 [ASSIGNED - medium - jkys...@redhat.com - --- -] snd_intel8x0: snd_pcm_avail()/ snd_pcm_delay() overflow [See dependency tree for bug 506075] *509733 [NEW - medium - dav...@redhat.com - --- -] Process /usr/libexec/gvfs-gdu-volume-monitor received signal 11 [See dependency tree for bug 509733] *510127 [ASSIGNED - medium - mmasl...@redhat.com - --- -] perl taint bug [See dependency tree for bug 510127] *510249 [ASSIGNED - medium - mcla...@redhat.com - --- - Reopened] Missing panel applets on gnome login; "Glib-GObject-CRITICAL" messages [See dependency tree for bug 510249] *510950 [ASSIGNED - medium - rstr...@redhat.com - --- - SELinux] SELinux is preventing thunderbird-bin from changing a writable memory segment executable. [See dependency tree for bug 510950] *512845 [ASSIGNED - high - stran...@redhat.com - --- - Reopened, Security, SELinux] setroubleshoot: SELinux is preventing firefox from changing a writable memory segment executable. [See dependency
Re: conflict between libotf and openmpi
Which makes me wonder, how could this conflict have been avoided? Is there a tool that would check any new package to see if any object* in it would conflict with any existing package? If not, sounds like a good thing to have. * Here, object means filesystem object. I'm not sure if there are any other types of objects to worry about. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between libotf and openmpi
On Wed, 2009-09-16 at 22:55 +0300, Ville Skyttä wrote:
> On Wednesday 16 September 2009, Jay Fenlason wrote:
> > otfdump will be in
> > openmpi-devel: %{_libdir}/%{name}/bin/ where it won't interfere with
> > libotf.
>
> IIUC this will only help wrt. the packaging conflict; interference still
> happens as $PATH changes e.g. when loading/unloading the openmpi modules. I
> don't think there's any other way around that issue besides renaming one of
> the executables, but whether that's worth doing/necessary is another thing.
Yes, that is true. If the openmpi module is loaded then Open MPI's
otfdump will be used. I'm not sure whether this is a problem, though,
since the module is not loaded by default and one does not run into any
conflicts. Renaming binaries is a nuisance, too.
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Evolution time format/double address book entries
On Wed, 2009-09-16 at 12:01 +0200, Milan Crha wrote: > Hi, > > On Sun, 2009-09-13 at 07:40 -0500, Mike Chambers wrote: > > In the date field while viewing emails, it shows the time in 24 hour > > time instead of 12 hour time with am/pm. I have went into any > > preferences and made sure the two settings that have time in them are > > correct and what I want, but no affect. And my clock on my desktop is > > 12 hour time like it should be. > > which preference did you use, please? There is a new option in 2.27.9x, > the Edit->preferences->Mail Preferences->Headers->Date and time format. > Use "%ad %I:%M %p" in a "Table column" fields, instead of the predefined > "%ad %H:%M". if wondering, it uses strftime format specifiers, plus that > "%ab", which is specific for Evolution. Found the preference and that fixed it (the above part). > > Also, and this has happened in most/all of F12 testing, is that when > > either importing an address book or doing a complete restore when > > starting evo for the first time, when you go to do a new email and click > > on the to button to find an address book, it shows them as double > > entries. Although if you do use one, it removes both of them from the > > selection. > > I didn't see this myself, do I understand it correctly that this is > doing contact doubling only once, just after import of a new address > book or after the restore? Maybe file a bug in > https://bugzilla.gnome.org and continue a discussion there (send here a > bug URL). After both, either after a restore or after importing a .cvf (?) file of your address book. I can send a new email, click on "to" button, and see them doubled when you go to choose who to send the email too. BUT, if you look in the address book itself (via view/window/contacts), there is just one entry. So in other words, it's on doubled when you go to send an email and want to add someone from your address book. Understand what I am referring to? -- Mike Chambers Madisonville, KY "Best lil town on Earth!" -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Close comments/karma after update push?
After a recent xorg bug[1] with intel chips, I had to question the use of bodhi for karma/comments after an update has been pushed to "updates." Should the comments and karma for packages be closed after an update leaves "updates-testing?" I don't see any value and it seems the wrong place to have notes about bugs on released packages. Bug reports should go in Bugzilla, no? Should a comment be left on the page before it is closed noting to report bugs to Bugzilla to be a nice pointer for the uninformed? Perhaps a pointer to the next update in line to be released as a user may stumble on an older release. "Obsoleted by: [link]" Update page: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8766 [1] https://bugzilla.redhat.com/show_bug.cgi?id=518748 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 09/16/2009 08:59 AM, Jochen Schmitt wrote: > Am 16.09.2009 17:47, schrieb Toshio Kuratomi: > >> That still leaves open the question of why no one has asked rsync >> upstream to make their fork publicly available instead of hoarding >> it as a private, internal copy. > > I would ask, why the modification will not integrated in the > 'official' Fedora zlib package? > > After this integration the fedora maintainer can forward the pach to > the upsream author. > And a short followup -- I've gone through the zlib-devel mailing list archives now. I was unable to find any request for the rsync patches to be merged into mainline zlib. The mailing list archives only go back to March 2002, so it could be that the request to merge came before that directly to one of the zlib authors. But if so, there's not a record of what problems, if any, there were with the patch. -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: boot/init conf at plumbers conf next week.
On 09/16/2009 03:22 PM, Dave Jones wrote: > I'm MC'ing the boot/init miniconf next week at the plumbers > conference in Portland, and a slot has become available that > I don't have anyone to fill. > > If you're going to be there anyway, and you have something to > talk about that may be relevant (other talks lined up include > dracut & upstart) then let me know, and I'll get you added > to the speakers list. > > thanks, > > Dave > How much time are we talking about filling? --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between libotf and openmpi
On Wednesday 16 September 2009, Jay Fenlason wrote:
> otfdump will be in
> openmpi-devel: %{_libdir}/%{name}/bin/ where it won't interfere with
> libotf.
IIUC this will only help wrt. the packaging conflict; interference still
happens as $PATH changes e.g. when loading/unloading the openmpi modules. I
don't think there's any other way around that issue besides renaming one of
the executables, but whether that's worth doing/necessary is another thing.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
boot/init conf at plumbers conf next week.
I'm MC'ing the boot/init miniconf next week at the plumbers conference in Portland, and a slot has become available that I don't have anyone to fill. If you're going to be there anyway, and you have something to talk about that may be relevant (other talks lined up include dracut & upstart) then let me know, and I'll get you added to the speakers list. thanks, Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between libotf and openmpi
Jay Fenlason wrote:
On Wed, Sep 16, 2009 at 10:04:17PM +0300, Jussi Lehtola wrote:
On Wed, 2009-09-16 at 14:53 -0400, Neal Becker wrote:
It seems both openmpi and libotf supply a %{_bindir}/otfdump. otf is
either:
OpenTypeFont (libotf)
or
OpenTraceFormat (openmpi)
I maintain libotf. I'm not sure how to address this.
My only interest in libotf is so emacs can use it. For that, it doesn't
need the binaries. Perhaps they could be put somewhere else?
I don't know how important otfdump is to openmpi, since I don't use it. My
guess is that in both libotf and openmpi, neither is critical to function,
but is a debug aid.
Actually, in this case it shouldn't be a problem for very long, since
every MPI compiler (& runtime) and MPI application should be reworked
ASAP to conform to the new MPI packaging guidelines.
OpenMPI is currently under work at
https://bugzilla.redhat.com/show_bug.cgi?id=521334
I'm currently polishing up the new OpenMPI packaging in rawhide, and
(barring surprises) I should have new openmpi and openmpi-devel
packages in updates by the end of the week. These will obsolete the
openmpi-libs and openmpi-vt packages, and otfdump will be in
openmpi-devel: %{_libdir}/%{name}/bin/ where it won't interfere with libotf.
-- JF
Sounds like the optimal solution. Make sure to push at least to F-11,
not sure if it affects F-10. . .
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between libotf and openmpi
On Wed, Sep 16, 2009 at 10:04:17PM +0300, Jussi Lehtola wrote:
> On Wed, 2009-09-16 at 14:53 -0400, Neal Becker wrote:
> > It seems both openmpi and libotf supply a %{_bindir}/otfdump. otf is
> > either:
> >
> > OpenTypeFont (libotf)
> > or
> > OpenTraceFormat (openmpi)
> >
> > I maintain libotf. I'm not sure how to address this.
> >
> > My only interest in libotf is so emacs can use it. For that, it doesn't
> > need the binaries. Perhaps they could be put somewhere else?
> >
> > I don't know how important otfdump is to openmpi, since I don't use it. My
> > guess is that in both libotf and openmpi, neither is critical to function,
> > but is a debug aid.
>
> Actually, in this case it shouldn't be a problem for very long, since
> every MPI compiler (& runtime) and MPI application should be reworked
> ASAP to conform to the new MPI packaging guidelines.
>
> OpenMPI is currently under work at
> https://bugzilla.redhat.com/show_bug.cgi?id=521334
I'm currently polishing up the new OpenMPI packaging in rawhide, and
(barring surprises) I should have new openmpi and openmpi-devel
packages in updates by the end of the week. These will obsolete the
openmpi-libs and openmpi-vt packages, and otfdump will be in
openmpi-devel: %{_libdir}/%{name}/bin/ where it won't interfere with libotf.
-- JF
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between libotf and openmpi
Jon Ciesla wrote:
> Neal Becker wrote:
>> It seems both openmpi and libotf supply a %{_bindir}/otfdump. otf is
>> either:
>>
>> OpenTypeFont (libotf)
>> or
>> OpenTraceFormat (openmpi)
>>
>> I maintain libotf. I'm not sure how to address this.
>>
>> My only interest in libotf is so emacs can use it. For that, it doesn't
>> need the binaries. Perhaps they could be put somewhere else?
>>
>> I don't know how important otfdump is to openmpi, since I don't use it.
>> My guess is that in both libotf and openmpi, neither is critical to
>> function, but is a debug aid.
>>
>>
> Are they the same? If so, my gut would be to use the one in libotf, if
> it's complete, maybe in a subpackage, and have openmpi remove it's own
> and Require it, sort of the way we handle bundled libraries.
>
> -J
>
They have nothing in common, just unfortunately the same name.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between libotf and openmpi
On Wed, 2009-09-16 at 14:53 -0400, Neal Becker wrote:
> It seems both openmpi and libotf supply a %{_bindir}/otfdump. otf is
> either:
>
> OpenTypeFont (libotf)
> or
> OpenTraceFormat (openmpi)
>
> I maintain libotf. I'm not sure how to address this.
>
> My only interest in libotf is so emacs can use it. For that, it doesn't
> need the binaries. Perhaps they could be put somewhere else?
>
> I don't know how important otfdump is to openmpi, since I don't use it. My
> guess is that in both libotf and openmpi, neither is critical to function,
> but is a debug aid.
Actually, in this case it shouldn't be a problem for very long, since
every MPI compiler (& runtime) and MPI application should be reworked
ASAP to conform to the new MPI packaging guidelines.
OpenMPI is currently under work at
https://bugzilla.redhat.com/show_bug.cgi?id=521334
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between libotf and openmpi
Neal Becker wrote:
It seems both openmpi and libotf supply a %{_bindir}/otfdump. otf is
either:
OpenTypeFont (libotf)
or
OpenTraceFormat (openmpi)
I maintain libotf. I'm not sure how to address this.
My only interest in libotf is so emacs can use it. For that, it doesn't
need the binaries. Perhaps they could be put somewhere else?
I don't know how important otfdump is to openmpi, since I don't use it. My
guess is that in both libotf and openmpi, neither is critical to function,
but is a debug aid.
Are they the same? If so, my gut would be to use the one in libotf, if
it's complete, maybe in a subpackage, and have openmpi remove it's own
and Require it, sort of the way we handle bundled libraries.
-J
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
conflict between libotf and openmpi
It seems both openmpi and libotf supply a %{_bindir}/otfdump. otf is
either:
OpenTypeFont (libotf)
or
OpenTraceFormat (openmpi)
I maintain libotf. I'm not sure how to address this.
My only interest in libotf is so emacs can use it. For that, it doesn't
need the binaries. Perhaps they could be put somewhere else?
I don't know how important otfdump is to openmpi, since I don't use it. My
guess is that in both libotf and openmpi, neither is critical to function,
but is a debug aid.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
problems with the latest texlive-2009 update on rawhide
After the update of texlive-2009 packages on rawhide latex has ceased to work: $ pdflatex mnc_modulo_2-mod-graph This is pdfTeX, Version 3.1415926-1.40.10 (Web2C 2009) restricted \write18 enabled. kpathsea: Running mktexfmt pdflatex.fmt I can't find the format file `pdflatex.fmt'! The suspect here seems to be ftmutil-sys # fmtutil-sys --all # No output from fmtutil-sys as opposed to the very verbose output of previous versions. -- José Abílio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 09/16/2009 08:59 AM, Jochen Schmitt wrote: > Am 16.09.2009 17:47, schrieb Toshio Kuratomi: > >> That still leaves open the question of why no one has asked rsync >> upstream to make their fork publicly available instead of hoarding >> it as a private, internal copy. > > I would ask, why the modification will not integrated in the > 'official' Fedora zlib package? > > After this integration the fedora maintainer can forward the pach to > the upsream author. > I don't know -- varekova, what do you think of the rsync-zlib patch? http://lists.samba.org/archive/rsync/2005-December/014180.html Does this look sane enough that you'd take it upstream? -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: status of forked zlibs in rsync and zsync
On Wed, 2009-09-16 at 08:47 -0700, Toshio Kuratomi wrote: > Ah -- I was reading that as three separate options. I can see how it > could be read as three steps in a single solution as well. > > That still leaves open the question of why no one has asked rsync > upstream to make their fork publicly available instead of hoarding it > as > a private, internal copy. I don't remember if the inquiry was public, but I think the answer was the same as zsync (or the inquiry was simply ignored). Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Server-devel] Troubles running F9 mock chroot under F11
On Wed, 2009-09-16 at 10:32 +0545, Daniel Drake wrote:
> 2009/9/15 Jerry Vonau :
> > Are you just adding rpms to the install media? Or are you trying
> > something more difficult? I have a process in mind if you're just adding
> > rpms to the mix...
>
> Just adding RPMs would be enough, but also we're customizing the
> kickstart file a little.
>
That should be do-able using mkslim (read it first) from xs-livecd's git
repo, along with my idea to use a pre-configured "updates repo" on the
iso.
http://lists.laptop.org/pipermail/server-devel/2009-February/002937.html
You would create an "overlay tree" in lets say /tmp/xsupdates/, this
will hold what files you want to add/change on the iso. Now just make a
tree for the files in /tmp/xsupdates/. Create a directory updates,
populate it with rpms and run createrepo against it. If you wish to
replace/add a file on the iso, just have them be in the same place in
the xsupdates directory, as it would be on the iso. eg: xsupdates/ks.cfg
xsupdates/isolinux/isolinux.cfg. Then call
mkslim /tmp/xsupdates
Remember to add the repo line to the kickstart file or add them as a
boot argument, for usb:
repo --name=updates --baseurl=file:///mnt/isodir/updates
for cdrom:
repo --name=updates --baseurl=file:///mnt/stage2/updates
The usb method is tested, while I have not tested the cdrom iso
> > However, I see that the older buildinstall(s) are not present any
> > more(?)! (File a bug I guess) If you were to add the buildinstall from
> > F9's anaconda in revisor's script directory as F9-buildinstall, then the
> > buildinstall from F9 should be used instead of the one on the host
> > system.
>
> I did that and it now fails at a later point. I first had to modify pungi.py
> +buildinstall.append('--output')
> buildinstall.append(self.topdir)
>
> and the end result is:
>
> Linking in release notes:
> 100.0%
> Size of the installation tree is 518 MB
> Traceback (most recent call last):
> File "/usr/lib/python2.6/site-packages/revisor/__init__.py", line 528, in
> run
> self.base.run()
> File "/usr/lib/python2.6/site-packages/revisor/base.py", line 106, in run
> self.cli.run()
> File "/usr/lib/python2.6/site-packages/revisor/cli.py", line 44, in run
> self.base.lift_off()
> File "/usr/lib/python2.6/site-packages/revisor/base.py", line 867, in
> lift_off
> self.buildInstallationMedia()
> File "/usr/lib/python2.6/site-packages/revisor/base.py", line 1478,
> in buildInstallationMedia
> f = open(os.path.join(mypungi.topdir,"isolinux","isolinux.cfg"),"rw+")
> IOError: [Errno 2] No such file or directory:
> '/var/tmp/revisor-pungi/0.5.2/xs-f9-i386/i386/os/isolinux/isolinux.cfg'
> Traceback occurred, please report a bug at http://fedorahosted.org/revisor
>
> The size should be more like 850mb.
>
> Did you have any luck in your own experiment?
>
No, I stopped when it bombed out, had to do my real work, must of been
at the point you got past with the patched pungi.py.
Jerry
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Troubles running F9 mock chroot under F11
On Wed, Sep 16, 2009 at 3:31 PM, Jan Kratochvil wrote: > Hi, > > filed as: >https://bugzilla.redhat.com/show_bug.cgi?id=523698 > > how to possibly fix the problem by a backport from rpm5.org as suggested by > Jeff Johnson. > For rpm 4.4 the backport was already filled but reject. https://bugzilla.redhat.com/show_bug.cgi?id=464752 > > Thanks, > Jan > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 16.09.2009 17:47, schrieb Toshio Kuratomi: > > That still leaves open the question of why no one has asked rsync > upstream to make their fork publicly available instead of hoarding > it as a private, internal copy. > I would ask, why the modification will not integrated in the 'official' Fedora zlib package? After this integration the fedora maintainer can forward the pach to the upsream author. Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAkqxC0kACgkQZLAIBz9lVu+zmQQAgHZTiLsAVbps6bCzXD+oHFhV n1/vhtKc80KcxDTyHcw/yiiD43wewyz3EZtCJm1FV+x/TiqdKfroJa+9uExY/tVb RImt9ZrclIS7p+t5AgKDFZ/oXigEfXew6ydkj5G6dP1wfrAFb1jb4qtdLO8cSdGD vV5ldUkbOpDCtYH3+DE= =Uw7o -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 09/16/2009 08:39 AM, Simo Sorce wrote: > On Wed, 2009-09-16 at 08:10 -0700, Toshio Kuratomi wrote: >> This is a logical leap. rsync has forked zlib but they are only using >> the fork internally. 2 and 3 get that fork out in the open so that >> more >> than one program can use it. 2 and 3 are solutions when solution 1 >> fails. Since solution 1 has failed, 2 and 3 become *relevant*, not >> moot. > > I beg your pardon, but how are rsync and zsync supposed to use upstream > zlib (points 2,3) if the upstream lib does not have the features they > need ??? > Ah -- I was reading that as three separate options. I can see how it could be read as three steps in a single solution as well. That still leaves open the question of why no one has asked rsync upstream to make their fork publicly available instead of hoarding it as a private, internal copy. -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: Possible packages...
On 09/16/2009 08:20 AM, Nathanael Noblet wrote: I didn't because it still had quite a few patches that needed to go upstream. I'll take a look at version 2.3... Yeah the lib-patches is still full of patches... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 09/16/2009 03:32 AM, Jonathan Underwood wrote: > 2009/9/15 Simo Sorce : >> On Tue, 2009-09-15 at 12:34 -0700, Toshio Kuratomi wrote: >>> This would be great if maintainers were willing to fix issues after >>> the >>> fact. Look at rsync -- there's no incentive to fix the library issue >>> at >>> this point because rsync is already in the distribution. We need to >>> fix >>> this lack of incentive for other reasons -- but we need to fix it >>> before >>> we start trying to get more packages into the distro with less initial >>> quality. >> >> Sorry but the packager may have no way to influence upstream. >> And to be honest having a huge patch against rsync and/or zsync to >> extract a library against the will of the rsync and/or zsync upstream is >> contrary to fedora policy as (AFAIK). >> >> And yes I am the maintainer of rsync and I am not doing the job, because >> I don't want to have to create or maintain such patcheset until the day >> I am reasonably sure upstream will want such patches. >> >> Finally as ajax said, we need to be reasonable, I don't think this >> problem warrants blocking our acceptance of zsync. > > Looking through the mailing list archives, as far as I can tell, noone > has tried this course of action yet: > > 1) Ask zlib upstream to accept the changes that the rsync devs made to > zlib and issue a new release Upstream tried this but the exact conversation is not available that I can find. There were some notes on rsync's mailing list about there being issues with the patch but not precisely what those issues were. It could just be cleanup. It could be architectural differences. > 2) Ask rsync upstream to support the new version of zlib > 3) Ask zsync upstream to support the new version of zlib > rsc and cassmodiah looked into #3. I believe the author of zsync didn't want to be responsible for the library (even though he's responsible for the copy internal to zsync). No one has tried #2. -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: status of forked zlibs in rsync and zsync
On Wed, 2009-09-16 at 08:10 -0700, Toshio Kuratomi wrote: > This is a logical leap. rsync has forked zlib but they are only using > the fork internally. 2 and 3 get that fork out in the open so that > more > than one program can use it. 2 and 3 are solutions when solution 1 > fails. Since solution 1 has failed, 2 and 3 become *relevant*, not > moot. I beg your pardon, but how are rsync and zsync supposed to use upstream zlib (points 2,3) if the upstream lib does not have the features they need ??? Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 09/16/2009 12:42 AM, Tomas Mraz wrote: > On Tue, 2009-09-15 at 14:01 -0700, Toshio Kuratomi wrote: >> On 09/15/2009 01:29 PM, Simo Sorce wrote: > >>> Sorry but the packager may have no way to influence upstream. >>> And to be honest having a huge patch against rsync and/or zsync to >>> extract a library against the will of the rsync and/or zsync upstream is >>> contrary to fedora policy as (AFAIK). >>> >> You bring up several good thoughts here: >> >> 1) We have two conflicting policies. Stick with upstream and do not >> have private copies of system libraries. Since the latter is in place >> for security reasons and maintainability while the former is only for >> maintainability, I'd place more value on it. > > I don't think the security reasons here are so much more important. If > the proliferation of bundled libraries is very strictly controlled (for > example by the need to get a FESCO exception) and the security response > team is always notified when a new such bundle is added to the > distribution the security updates can be handled without the delays you > described. A new vulnerability on the library would always trigger > immediate updates in the library and in all the bundled copies of the > library. Of course it is an additional burden on the security response > team but as I said above in well discussed and reasoned exceptions it > does not seem to me as huge problem as you paint it. I would also think > that the security response team already maintains such list for existing > bundled libraries. You are incorrect about what the security response team currently does. If you would like to spearhead adding this responsibility to the security response team's duties and go about creating a list of programs that bundle libraries and the criteria for and presenting the plan to FESCo and the Packaging Committee then we would have a way to judge whether we should change the Guidelines because of a mitigating factor. If you just want to say, this is how it should be but no one is actually willing to do the work of making things work that way, then I will continue to say that we have a large security problem wrt bundled libraries. Also, I will note that FESCo has already reviewed the zsync/rsync inclusion and decided that the bundled zlib needs to be split out or removed entirely. So your idea of using FESCo exceptions to control which applications are allowed to be bundled needs to also include some criteria. -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: Introduction to a new SIG for creation of Live DVD
On Wed, Sep 16, 2009 at 10:06 AM, Benny Amorsen wrote: > Colin Walters writes: > >> I'd imagine that running the "live Anaconda" UI from inside the GDM X >> session wouldn't take significantly more resources than the Anaconda >> OS after creating an image that doesn't have games, etc. > > Images sound significantly more difficult to create and maintain than > kickstart-files. > > I would really hate to lose kickstart. No one's suggesting replacing kickstart, actually I think we way undersell it. What I'm talking about is the mode where the image boots directly into Anaconda as a complete OS should instead be a live image with Anaconda as an application, which for the most part would be the same except you'd gain the ability to run say Firefox (or any other app; games), or do "yum install" during the install. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 09/16/2009 06:43 AM, Simo Sorce wrote: > On Wed, 2009-09-16 at 11:32 +0100, Jonathan Underwood wrote: >> Looking through the mailing list archives, as far as I can tell, noone >> has tried this course of action yet: >> >> 1) Ask zlib upstream to accept the changes that the rsync devs made to >> zlib and issue a new release >> 2) Ask rsync upstream to support the new version of zlib >> 3) Ask zsync upstream to support the new version of zlib >> >> Surely that's the right solution, and the first thing that should be >> tried? > > My recollection is that 1 was tried and upstream said no. This was tried by upstream rsync. > So 2,3 became > moot. > This is a logical leap. rsync has forked zlib but they are only using the fork internally. 2 and 3 get that fork out in the open so that more than one program can use it. 2 and 3 are solutions when solution 1 fails. Since solution 1 has failed, 2 and 3 become *relevant*, not moot. -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: Possible packages...
On Sep 16, 2009, at 6:02 AM, Pim Zandbergen wrote: Nathanael D. Noblet wrote: On 07/09/2009 02:31 PM, Jarod Wilson wrote: That said, I have it up and running on an F11 host at home right now, satisfying everything else w/Fedora packages. Yeah same here. Did any of you create a calendarserver RPM ? That would give a head start trying to build calendarserver 2.3 which was recently released. It will probably also be usable as a start for the Darwin CardDAV Server, as soon as Apple will release the source, as it uses the same Python/ twisted framework. I didn't because it still had quite a few patches that needed to go upstream. I'll take a look at version 2.3... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On Wed, 2009-09-16 at 11:32 +0100, Jonathan Underwood wrote: > Looking through the mailing list archives, as far as I can tell, noone > has tried this course of action yet: > > 1) Ask zlib upstream to accept the changes that the rsync devs made to > zlib and issue a new release > 2) Ask rsync upstream to support the new version of zlib > 3) Ask zsync upstream to support the new version of zlib > > Surely that's the right solution, and the first thing that should be > tried? My recollection is that 1 was tried and upstream said no. So 2,3 became moot. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Troubles running F9 mock chroot under F11
Hi, filed as: https://bugzilla.redhat.com/show_bug.cgi?id=523698 how to possibly fix the problem by a backport from rpm5.org as suggested by Jeff Johnson. Thanks, Jan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090916 changes
Compose started at Wed Sep 16 06:15:05 UTC 2009 Broken deps for i386 -- anerley-0.0.20-3.fc12.i686 requires libmissioncontrol-client.so.0 anerley-devel-0.0.20-3.fc12.i686 requires pkgconfig(libmissioncontrol) clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-gtk-0.9) network-manager-netbook-1.2-5.fc12.i686 requires libnm_glib.so.0 rakudo-0.0.2009.08_1.5.0-2.fc12.i686 requires libparrot.so.1.5.0 rygel-0.3-5.fc12.i686 requires libgee.so.0 rygel-tracker-0.3-5.fc12.i686 requires libgee.so.0 Broken deps for x86_64 -- anerley-0.0.20-3.fc12.i686 requires libmissioncontrol-client.so.0 anerley-0.0.20-3.fc12.x86_64 requires libmissioncontrol-client.so.0()(64bit) anerley-devel-0.0.20-3.fc12.i686 requires pkgconfig(libmissioncontrol) anerley-devel-0.0.20-3.fc12.x86_64 requires pkgconfig(libmissioncontrol) clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.i586 requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.i586 requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.x86_64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.i586 requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.x86_64 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.i586 requires libclutter-glx-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.x86_64 requires libclutter-gtk-0.9.so.0()(64bit) clutter-gtkmm-0.9.4-1.fc12.x86_64 requires libclutter-glx-0.9.so.0()(64bit) clutter-gtkmm-devel-0.9.4-1.fc12.i586 requires pkgconfig(clutter-gtk-0.9) clutter-gtkmm-devel-0.9.4-1.fc12.x86_64 requires pkgconfig(clutter-gtk-0.9) network-manager-netbook-1.2-5.fc12.x86_64 requires libnm_glib.so.0()(64bit) rakudo-0.0.2009.08_1.5.0-2.fc12.x86_64 requires libparrot.so.1.5.0()(64bit) rygel-0.3-5.fc12.x86_64 requires libgee.so.0()(64bit) rygel-tracker-0.3-5.fc12.x86_64 requires libgee.so.0()(64bit) Broken deps for ppc -- anerley-0.0.20-3.fc12.ppc requires libmissioncontrol-client.so.0 anerley-0.0.20-3.fc12.ppc64 requires libmissioncontrol-client.so.0()(64bit) anerley-devel-0.0.20-3.fc12.ppc requires pkgconfig(libmissioncontrol) anerley-devel-0.0.20-3.fc12.ppc64 requires pkgconfig(libmissioncontrol) clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-cairo-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc requires libcluttermm-0.8.so.2 clutter-cairomm-0.7.4-2.fc11.ppc requires libclutter-glx-0.8.so.0 clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-glx-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libclutter-cairo-0.8.so.0()(64bit) clutter-cairomm-0.7.4-2.fc11.ppc64 requires libcluttermm-0.8.so.2()(64bit) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc requires pkgconfig(clutter-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(cluttermm-0.8) clutter-cairomm-devel-0.7.4-2.fc11.ppc64 requires pkgconfig(clutter-0.8) clutter-gtkmm-0.9.4-1.fc12.ppc requires libclutter-gtk-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.ppc requires libclutter-glx-0.9.so.0 clutter-gtkmm-0.9.4-1.fc12.ppc64 requires libclutter-gtk-0.9.so.0()(64bit) clutter-gtkmm-0.9.4-1.fc12.ppc64 requires libclutter-glx-0.9.so.0()(64bit) clutter-gtkmm-devel-0.9.4-1.fc12.ppc requires pkgconfig(clutter-gtk-0.9) clutter-gtkmm-devel-0.9.4-1.fc12.ppc64 requires pkgconfig(clutter-gtk-0.9) network-manager-netbook-1.2-5.fc12.ppc requires libnm_glib.so.0 rygel-0.3-5.fc12.ppc requires libgee.so.0 rygel-tracker-0.3-5.fc12.p
Re: Possible packages...
On 09/16/2009 08:02 AM, Pim Zandbergen wrote: Nathanael D. Noblet wrote: On 07/09/2009 02:31 PM, Jarod Wilson wrote: That said, I have it up and running on an F11 host at home right now, satisfying everything else w/Fedora packages. Yeah same here. Did any of you create a calendarserver RPM ? Nope, never got around to it, too many other more pressing things. :( -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Possible packages...
Nathanael D. Noblet wrote: On 07/09/2009 02:31 PM, Jarod Wilson wrote: That said, I have it up and running on an F11 host at home right now, satisfying everything else w/Fedora packages. Yeah same here. Did any of you create a calendarserver RPM ? That would give a head start trying to build calendarserver 2.3 which was recently released. It will probably also be usable as a start for the Darwin CardDAV Server, as soon as Apple will release the source, as it uses the same Python/twisted framework. Thanks, Pim -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On 09/16/2009 01:59 AM, Simo Sorce wrote: > > And yes I am the maintainer of rsync and I am not doing the job, because > I don't want to have to create or maintain such patcheset until the day > I am reasonably sure upstream will want such patches. So, have you asked upstream this question? > Finally as ajax said, we need to be reasonable, I don't think this > problem warrants blocking our acceptance of zsync. Agreed on this, however. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mouse pointer freezing in f12 and f11
On Tue, 2009-09-15 at 09:42 -0400, Adam Jackson wrote: > On Thu, 2009-09-10 at 19:29 +1000, Rodd Clarkson wrote: > > I've had a problem with X in f12 or some time that sees the mouse > > pointer freezing. I'm now having the same issue in f11. > > > > I'm happy to file a bug in bugzilla, but I'm hoping someone mught be > > able to point me in the right direction. > > > > After some time after running X the mouse pointer will freeze. > > Switching to a VT doesn't help, but I can use the keyboard to close apps > > and do a little navigation. Also pushing the power button will see a > > dialog to allow me to shutdown, suspend, etc. I can suspend and resume > > and this fixes the problem. > > > > I'm not however convinced that it's an X bug. I think it might be > > related to bluetooth (I believe that my mouse and keyboard have > > something to do with bluetooth on this laptop) and that the suspend > > resume cycle restarts bluetooth and fixes the problem. > > You could verify this with "DISPLAY=:0 xinput list" when the mouse > pointer stops. If you don't see the bluetooth mouse in the list, then > the kernel is refusing to re-plug it right. If you _do_ see the mouse > in the list, then X is confused somewhere. > > Does keyboard navigation still work when this happens? Does alt-tab > switch windows, etc. I'll give this a try when I next have a lock-up. I'm pretty sure that this problem only occurs before I've cycled through a suspend-resume. I suspect bluetooth issues because the bluetooth icon appears until I do the suspend-resume cycle and then the icon doesn't appear and bluetooth doesn't work (but the mouse does). Keyboard navigation still works, and I can switch to a VT too. R. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Evolution time format/double address book entries
On Wed, 2009-09-16 at 12:05 +0200, Milan Crha wrote: > > One thing I have noticed though is that "yesterday" shown in the Date > > column in table format seems to be two days (i.e. on 13th September all > > emails received on both the 12th and 11th September are shown as > > yesterday), and the "2 days ago" etc are all one day out. > > I noticed this too, but failed to track the cause of it. Could you file > a bug at https://bugzilla.gnome.org for investigation, please? My first > walk through the code didn't seem to indicate any logical issue, but > there is some, obviously. I take this back, the bug is there and fixed already, see https://bugzilla.gnome.org/show_bug.cgi?id=594609 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
2009/9/15 Simo Sorce : > On Tue, 2009-09-15 at 12:34 -0700, Toshio Kuratomi wrote: >> This would be great if maintainers were willing to fix issues after >> the >> fact. Look at rsync -- there's no incentive to fix the library issue >> at >> this point because rsync is already in the distribution. We need to >> fix >> this lack of incentive for other reasons -- but we need to fix it >> before >> we start trying to get more packages into the distro with less initial >> quality. > > Sorry but the packager may have no way to influence upstream. > And to be honest having a huge patch against rsync and/or zsync to > extract a library against the will of the rsync and/or zsync upstream is > contrary to fedora policy as (AFAIK). > > And yes I am the maintainer of rsync and I am not doing the job, because > I don't want to have to create or maintain such patcheset until the day > I am reasonably sure upstream will want such patches. > > Finally as ajax said, we need to be reasonable, I don't think this > problem warrants blocking our acceptance of zsync. Looking through the mailing list archives, as far as I can tell, noone has tried this course of action yet: 1) Ask zlib upstream to accept the changes that the rsync devs made to zlib and issue a new release 2) Ask rsync upstream to support the new version of zlib 3) Ask zsync upstream to support the new version of zlib Surely that's the right solution, and the first thing that should be tried? Jonathan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Introduction to a new SIG for creation of Live DVD
Colin Walters writes: > I'd imagine that running the "live Anaconda" UI from inside the GDM X > session wouldn't take significantly more resources than the Anaconda > OS after creating an image that doesn't have games, etc. Images sound significantly more difficult to create and maintain than kickstart-files. I would really hate to lose kickstart. /Benny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Evolution time format/double address book entries
Hi, On Sun, 2009-09-13 at 15:25 +0100, Quentin Armitage wrote: > I recollect that Evolution used to display times in am/pm format, but > mine is now displaying in 24 hour format (which I happen to prefer). see my reply to Mike for the preferences entry. > One thing I have noticed though is that "yesterday" shown in the Date > column in table format seems to be two days (i.e. on 13th September all > emails received on both the 12th and 11th September are shown as > yesterday), and the "2 days ago" etc are all one day out. I noticed this too, but failed to track the cause of it. Could you file a bug at https://bugzilla.gnome.org for investigation, please? My first walk through the code didn't seem to indicate any logical issue, but there is some, obviously. Bye, Milan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Evolution time format/double address book entries
Hi, On Sun, 2009-09-13 at 07:40 -0500, Mike Chambers wrote: > In the date field while viewing emails, it shows the time in 24 hour > time instead of 12 hour time with am/pm. I have went into any > preferences and made sure the two settings that have time in them are > correct and what I want, but no affect. And my clock on my desktop is > 12 hour time like it should be. which preference did you use, please? There is a new option in 2.27.9x, the Edit->preferences->Mail Preferences->Headers->Date and time format. Use "%ad %I:%M %p" in a "Table column" fields, instead of the predefined "%ad %H:%M". if wondering, it uses strftime format specifiers, plus that "%ab", which is specific for Evolution. > Also, and this has happened in most/all of F12 testing, is that when > either importing an address book or doing a complete restore when > starting evo for the first time, when you go to do a new email and click > on the to button to find an address book, it shows them as double > entries. Although if you do use one, it removes both of them from the > selection. I didn't see this myself, do I understand it correctly that this is doing contact doubling only once, just after import of a new address book or after the restore? Maybe file a bug in https://bugzilla.gnome.org and continue a discussion there (send here a bug URL). Bye, Milan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Heads up] FUSE so-name bump is coming.
2009/9/8 Ville Skyttä : > On Tuesday 08 September 2009, Peter Lemenkov wrote: > >> I'll plan to upgrade fuse in Rawhide (and, possibly, in F-11) up to >> ver. 2.8.0, and there will be so-name bump. > > Rationale for considering doing it in F-11? After some thinking, I reconsidered plans to update FUSE to 2.8.0 in F-11. So no need to worry here :) -- With best regards, Peter Lemenkov. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Heads up] FUSE so-name bump is coming.
Hello! 2009/9/8 Till Maas : > Will you also rebuild the packages once the new fuse is in place? Yes, I'll try to rebuild also all packages, dependent on fuse. -- With best regards, Peter Lemenkov. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: status of forked zlibs in rsync and zsync
On Tue, 2009-09-15 at 14:01 -0700, Toshio Kuratomi wrote: > On 09/15/2009 01:29 PM, Simo Sorce wrote: > > Sorry but the packager may have no way to influence upstream. > > And to be honest having a huge patch against rsync and/or zsync to > > extract a library against the will of the rsync and/or zsync upstream is > > contrary to fedora policy as (AFAIK). > > > You bring up several good thoughts here: > > 1) We have two conflicting policies. Stick with upstream and do not > have private copies of system libraries. Since the latter is in place > for security reasons and maintainability while the former is only for > maintainability, I'd place more value on it. I don't think the security reasons here are so much more important. If the proliferation of bundled libraries is very strictly controlled (for example by the need to get a FESCO exception) and the security response team is always notified when a new such bundle is added to the distribution the security updates can be handled without the delays you described. A new vulnerability on the library would always trigger immediate updates in the library and in all the bundled copies of the library. Of course it is an additional burden on the security response team but as I said above in well discussed and reasoned exceptions it does not seem to me as huge problem as you paint it. I would also think that the security response team already maintains such list for existing bundled libraries. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
