Re: Help with debuging Xserver / Goes in an infinite loop
On 10/05/2009 09:05 PM, Joshua C. wrote: > 2009/10/5 Adam Jackson : > >> On Mon, 2009-10-05 at 19:19 +0200, Joshua C. wrote: >> >> >>> (gdb) bt >>> #0 0x003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6 >>> #1 0x004e615a in WaitForSomething ( >>> pClientsReady=) at WaitFor.c:228 >>> #2 0x00446ef2 in Dispatch () at dispatch.c:386 >>> #3 0x0042d205 in main (argc=, >>> argv=0x7fffa2ac9218, envp=) at main.c:397 >>> >> Okay, this isn't the server actually taking 100% of the CPU (almost >> certainly), it's before that. If you type 'cont' to resume, and then ^C >> the gdb process once the CPU goes wild, you should break back to the gdb >> prompt; _that_'s the backtrace I need. >> >> Of course, you might not, in which case debugging this gets a bit >> harder. >> >> - ajax >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list@redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> > (gdb) handle SIGUSR1 nostop > SignalStop Print Pass to program Description > SIGUSR1 NoYes Yes User defined signal 1 > (gdb) handle SIGUSR2 nostop > SignalStop Print Pass to program Description > SIGUSR2 NoYes Yes User defined signal 2 > (gdb) handle SIGPIPE nostop > SignalStop Print Pass to program Description > SIGPIPE NoYes Yes Broken pipe > (gdb) cont > Continuing. > ^C > Program received signal SIGINT, Interrupt. > 0x003cc3cd6827 in ioctl () from /lib64/libc.so.6 > (gdb) bt > #0 0x003cc3cd6827 in ioctl () from /lib64/libc.so.6 > #1 0x003cd6003113 in drmIoctl (fd=8, request=3221775460, > arg=0x7fff78cabbc0) at xf86drm.c:187 > #2 0x003cd600335c in drmCommandWriteRead (fd=8, > drmCommandIndex=, data=0x7fff78cabbc0, > size=) > at xf86drm.c:2363 > #3 0x7f6c6a6b3f08 in radeon_bufmgr_gem_wait_rendering (buf= optimized out>) at radeon_bufmgr_gem.c:282 > #4 0x7f6c6a69a51a in RADEONPrepareAccess (pPix=0x243c2d0, > index=0) at radeon_exa.c:279 > #5 0x7f6c69be43b4 in ExaDoPrepareAccess (pDrawable=0x243c2d0, > index=0) at exa.c:523 > #6 0x7f6c69be44b8 in exaPrepareAccessReg (pDrawable=0x243c2d0, > index=0, pReg=0x0) at exa.c:543 > #7 0x7f6c69beceac in ExaCheckComposite (op=, > pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc= out>, > ySrc=, xMask=0, yMask=0, xDst=19, yDst=85, > width=55, height=18) at exa_unaccel.c:342 > #8 0x7f6c69beb564 in exaComposite (op=, > pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc= out>, > ySrc=, xMask=0, yMask=0, xDst=19, yDst=85, > width=55, height=18) at exa_render.c:967 > #9 0x0052eb90 in damageComposite (op=8 '\b', pSrc= optimized out>, pMask=, pDst=0x27a04b0, xSrc=1, > ySrc=0, > xMask=, yMask=, xDst=19, > yDst=85, width=55, height=) at damage.c:643 > #10 0x0052720c in ProcRenderComposite (client=0x2625310) at > render.c:720 > #11 0x004471d4 in Dispatch () at dispatch.c:456 > #12 0x0042d205 in main (argc=, > argv=0x7fff78cac198, envp=) at main.c:397 > > Which kernel are you using ? JBG <>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20091002 changes
The report for 20091001 shows the following broken dependency, and it is not listed in the report for 20091002: perl-POE-Component-Client-HTTP-0.85-3.fc11.noarch requires perl(POE::Component::Client::Keepalive) >= 0:0.0901 However, the report for 20091002 shows no relevant package update that could have resolved this broken dependency. Is there something not quite right here? (I note that the perl-POE-Component-Client-HTTP package source was updated on 30th September, but it doesn't appear to have been tagged or rebuilt in Koji). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
- "Michal Nowak" wrote: > But there's patch http://bugs.freedesktop.org/show_bug.cgi?id=20901 > you might wanna test it -- looked good. As of now it's "RESOLVED FIXED". Should be part of 2.6.32 kernel (when is out). Michal -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help with debuging Xserver / Goes in an infinite loop
Joshua C., Mon, 05 Oct 2009 23:05:54 +0200: Do we have a bug for this? If not, please do file one and include all those information you collected for this thread together with /var/log/ Xorg.0.log (if possible after the problem happened -- on reboot put 3 to the end of the kernel command line, so Xorg is not started on boot, and then you can save previous /var/log/Xorg.0.log from the session which ended poorly), /etc/X11/xorg.conf (if you have any), and output of dmesg (if you can get it from other terminal than the one where you run gdb in moment things go bad). Thank you very much, Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: another spin of TeX Live 2009 packages
Hi, the repository at http://jnovy.fedorapeople.org/texlive/packages/ contains a lot of rawhide (f12) packages, so it can no longer be used on f11, was that intentional? Thanks, Thomas -- Thomas Moschny -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
Matej Cepl, Fri, 02 Oct 2009 15:26:09 +: > However, for personal reasons I > need to decrease my personal involvment in non-work related Fedora work. I have still on my list: * cycle -- Calendar program for women (any ladies would like to decrease gender gap in Fedora packaging? Or would like to switch your wife to Linux?) * vim-vimoutliner -- Script for building an outline editor on top of Vim (for vim lovers I don't know about any better outline editor/task manager, heck some people use it for writing huge technical books :)) * ldapvi -- An interactive LDAP client (the best tool for managing LDAP server I know about in Fedora) * JSDoc -- Produces javadoc-style documentation from JavaScript sourcefiles * python-urllib2_kerberos -- Kerberos over HTTP Negotiate/SPNEGO support for urllib2 Please take them to your good hands. Thanks, Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
olpc components in x86/x86_64 repo
yum list all |grep olpc dracut-modules-olpc.x86_64 0.2.1-2.fc12 rawhide olpc-contents.x86_642.6-2.fc12 rawhide olpc-library.noarch 2.0.2-2.fc12 rawhide olpc-netutils.noarch0.7-4.fc12 rawhide olpc-switch-desktop.noarch 0.6-2.fc12 rawhide olpc-update.noarch 2.20-1.fc12rawhide olpc-utils.x86_64 1.0.3-2.fc12 rawhide does it really make sense to have those modules available on x86/x86_64? (this is from rawhide) kind regards, Rudolf Kastl -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
PolicyKitOne or consolehelper for command line tool ?
Hi, I am a user of the 'usb_modeswitch'[1] tool which is also available as a Fedora package. Since this is a tool to be run as super-user but currently does not error out or warn when it is not invoked by root. I thought that i'd file a bug against the package to prompt for root password. I had a general idea that the general way to do this was by using consolehelper/userhelper. So, i decided to do some research and submit a bug report with a recommended solution, but i came across this: https://bugzilla.redhat.com/show_bug.cgi?id=502765 http://fedoraproject.org/wiki/Features/PolicyKitOne So, here are my questions a. Does this also apply for CLI tools such as usb_modeswitch ? b. If not, shouldn't that be explicitly stated in the BZ/wiki page ? c. If yes, is there a doc where I can learn more about PolicyKitOne ? I admit, i really don't know much about the PolicyKit framework itself, but little that i know, had me believing that PolicyKit is more of a Gnome (or rather a freedesktop thing). In any case, an introduction/doc of the /current/ state of PolicyKit too would help. cherrs, - steve [1] http://www.draisberghof.de/usb_modeswitch/ -- random non tech spiel: http://lonetwin.blogspot.com/ tech randomness: http://lonehacks.blogspot.com/ what i'm stumbling into: http://lonetwin.stumbleupon.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: olpc components in x86/x86_64 repo
On Tue, Oct 6, 2009 at 10:59 AM, Rudolf Kastl wrote: > yum list all |grep olpc > dracut-modules-olpc.x86_64 0.2.1-2.fc12 rawhide > olpc-contents.x86_64 2.6-2.fc12 rawhide > olpc-library.noarch 2.0.2-2.fc12 rawhide > olpc-netutils.noarch 0.7-4.fc12 rawhide > olpc-switch-desktop.noarch 0.6-2.fc12 rawhide > olpc-update.noarch 2.20-1.fc12 rawhide > olpc-utils.x86_64 1.0.3-2.fc12 rawhide > > does it really make sense to have those modules available on > x86/x86_64? (this is from rawhide) Yes, because they are used on both x86 and x86_64 platforms. What is the problem having them there? Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Oracle DB 4.8.24 released
Hi! Oracle released a new DB 4.8.24 recently and it is now ready to hit rawhide. Before that happens I want to let you test your package(s) with this new release so that we may delay updating to the latest version if severe problems with it are reported. With an exception of the RPC support which was dropped by upstream you shouldn't experience lots of incompatibilities. For testing you can use packages from this scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1730146 Jindrich -- Jindrich Novyhttp://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: olpc components in x86/x86_64 repo
2009/10/6 Peter Robinson : > On Tue, Oct 6, 2009 at 10:59 AM, Rudolf Kastl wrote: >> yum list all |grep olpc >> dracut-modules-olpc.x86_64 0.2.1-2.fc12 >> rawhide >> olpc-contents.x86_64 2.6-2.fc12 >> rawhide >> olpc-library.noarch 2.0.2-2.fc12 >> rawhide >> olpc-netutils.noarch 0.7-4.fc12 >> rawhide >> olpc-switch-desktop.noarch 0.6-2.fc12 >> rawhide >> olpc-update.noarch 2.20-1.fc12 >> rawhide >> olpc-utils.x86_64 1.0.3-2.fc12 >> rawhide >> >> does it really make sense to have those modules available on >> x86/x86_64? (this is from rawhide) > > Yes, because they are used on both x86 and x86_64 platforms. What is > the problem having them there? > > Peter somehow i had the impression they are atleast partially related to the olpc hardware. kind regards, Rudolf Kastl > > -- > 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: olpc components in x86/x86_64 repo
On Tue, Oct 6, 2009 at 12:58 PM, Rudolf Kastl wrote: > 2009/10/6 Peter Robinson : >> On Tue, Oct 6, 2009 at 10:59 AM, Rudolf Kastl wrote: >>> yum list all |grep olpc >>> dracut-modules-olpc.x86_64 0.2.1-2.fc12 >>> rawhide >>> olpc-contents.x86_64 2.6-2.fc12 >>> rawhide >>> olpc-library.noarch 2.0.2-2.fc12 >>> rawhide >>> olpc-netutils.noarch 0.7-4.fc12 >>> rawhide >>> olpc-switch-desktop.noarch 0.6-2.fc12 >>> rawhide >>> olpc-update.noarch 2.20-1.fc12 >>> rawhide >>> olpc-utils.x86_64 1.0.3-2.fc12 >>> rawhide >>> >>> does it really make sense to have those modules available on >>> x86/x86_64? (this is from rawhide) >> >> Yes, because they are used on both x86 and x86_64 platforms. What is >> the problem having them there? >> >> Peter > > somehow i had the impression they are atleast partially related to the > olpc hardware. Those ones aren't necessarily, and even then why does that stop them from being in rawhide. There's lots of packages for specific hardware in Fedora and these devices run Fedora. Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: olpc components in x86/x86_64 repo
Peter Robinson wrote: On Tue, Oct 6, 2009 at 12:58 PM, Rudolf Kastl wrote: 2009/10/6 Peter Robinson : On Tue, Oct 6, 2009 at 10:59 AM, Rudolf Kastl wrote: yum list all |grep olpc dracut-modules-olpc.x86_64 0.2.1-2.fc12 rawhide olpc-contents.x86_642.6-2.fc12 rawhide olpc-library.noarch 2.0.2-2.fc12 rawhide olpc-netutils.noarch0.7-4.fc12 rawhide olpc-switch-desktop.noarch 0.6-2.fc12 rawhide olpc-update.noarch 2.20-1.fc12rawhide olpc-utils.x86_64 1.0.3-2.fc12 rawhide does it really make sense to have those modules available on x86/x86_64? (this is from rawhide) Yes, because they are used on both x86 and x86_64 platforms. What is the problem having them there? Peter somehow i had the impression they are atleast partially related to the olpc hardware. Those ones aren't necessarily, and even then why does that stop them from being in rawhide. There's lots of packages for specific hardware in Fedora and these devices run Fedora. Peter Additionally, having OLPC-specific RPMS in mainline Fedora helps with the end goal that is , as I understand it, to have OLPC's OS be essentially a Spin of stock Fedora. It also helps OLPC devs who don't necessarily have XOs. -- 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
Bug reporting URL field in packages
A while ago there was a request to add a bug reporting URL to packages:
https://bugzilla.redhat.com/show_bug.cgi?id=512774
This was added to Fedora's rpm recently, what's still missing is the
default contents of the %{bugurl} macro in redhat-rpm-config.
Opinions wanted:
a) just make it https://bugzilla.redhat.com
b) use http://bugz.fedoraproject.org/%{name}
c) something else, what?
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
Le 06/10/2009 14:48, Panu Matilainen a écrit :
>
> A while ago there was a request to add a bug reporting URL to packages:
> https://bugzilla.redhat.com/show_bug.cgi?id=512774
>
> This was added to Fedora's rpm recently, what's still missing is the
> default contents of the %{bugurl} macro in redhat-rpm-config.
> Opinions wanted:
>
> a) just make it https://bugzilla.redhat.com
> b) use http://bugz.fedoraproject.org/%{name}
> c) something else, what?
>
> - Panu -
>
I'd go for b) for mainly two reasons:
- the UI is less messed than bugzilla's (and also faster). People can
easily review existing bugs ===> potentially less work for triagers.
- since some are still confused about the whole fedora/redhat thing, I'd
rather use the fedoraproject url.
My 2 cts
H.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Tuesday 06 October 2009 15:48:32 Panu Matilainen wrote:
> This was added to Fedora's rpm recently, what's still missing is the
> default contents of the %{bugurl} macro in redhat-rpm-config.
> Opinions wanted:
>
> a) just make it https://bugzilla.redhat.com
> b) use http://bugz.fedoraproject.org/%{name}
> c) something else, what?
d) use host part from rpm-config, and rest from package metadata.
and then one would be able to change report database
by modifying only one package.
Something like:
rpm-config %{bugreporthost} = http://bugzilla.redhat.com/
package%{name} = bacula
--> %{bugreporthost}/%{name}
--> http://bugzilla.redhat.com/bacula
Then downstream distros and IT-organizations could try to catch
all reports to their own bug reporting systems before disturbing
Fedora - as in many cases downstream may actually be the culprit
for the problem after all.
If that would not be possible, it would force them to rebuild
all packages and burn rainforests while doing so or just
waste Fedoraproject's hours for issues that doesn't belong there.
This probably isn't something that cannot be fixed later, but
while it's on plate? ;-)
Tuju
--
Better to have one, and not need it, than to need one and not have it.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Oracle DB 4.8.24 released
On Tue, Oct 06, 2009 at 01:49:49PM +0200, Jindrich Novy wrote: >Hi! > >Oracle released a new DB 4.8.24 recently and it is now ready to hit >rawhide. Before that happens I want to let you test your package(s) You mean devel/dist-f13. Rawhide is still tracking dist-f12. /me tries to avoid confusion. josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On 10/06/2009 06:43 PM, Juha Tuomala wrote:
On Tuesday 06 October 2009 15:48:32 Panu Matilainen wrote:
This was added to Fedora's rpm recently, what's still missing is the
default contents of the %{bugurl} macro in redhat-rpm-config.
Opinions wanted:
a) just make it https://bugzilla.redhat.com
b) use http://bugz.fedoraproject.org/%{name}
c) something else, what?
d) use host part from rpm-config, and rest from package metadata.
and then one would be able to change report database
by modifying only one package.
Something like:
rpm-config %{bugreporthost} = http://bugzilla.redhat.com/
package%{name} = bacula
--> %{bugreporthost}/%{name}
--> http://bugzilla.redhat.com/bacula
+1 on this.
cheers,
- steve
--
random non tech spiel: http://lonetwin.blogspot.com/
tech randomness: http://lonehacks.blogspot.com/
what i'm stumbling into: http://lonetwin.stumbleupon.com/
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help with debuging Xserver / Goes in an infinite loop
2009/10/6 Matej Cepl : > Joshua C., Mon, 05 Oct 2009 23:05:54 +0200: > > Do we have a bug for this? If not, please do file one and include all > those information you collected for this thread together with /var/log/ > Xorg.0.log (if possible after the problem happened -- on reboot put 3 to > the end of the kernel command line, so Xorg is not started on boot, and > then you can save previous /var/log/Xorg.0.log from the session which > ended poorly), /etc/X11/xorg.conf (if you have any), and output of dmesg > (if you can get it from other terminal than the one where you run gdb in > moment things go bad). > > Thank you very much, > > Matěj > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Bugzilla RH #527452. https://bugzilla.redhat.com/show_bug.cgi?id=527452 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Problem building Asterisk sounds
I'm trying to build the latest Asterisk sounds package, but I'm getting the following error: error: Recognition of file "/builddir/build/BUILDROOT/asterisk-sounds-core-1.4.16-1.fc13.noarch/usr/share/asterisk/sounds/fr/digits/1.g729" failed: mode 100444 zlib: invalid stored block lengthsempty (gzip compressed data, reserved method, encrypted, last modified: Tue Nov 9 20:48:48 2010, max speed) The full build log is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1730585 The build fails in mock locally as well but koji actually gives me a better error message. The file in question isn't gzip compressed, it's an audio file compressed with G.729 audio compression. Can anyone help me out here? -- Jeff Ollie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Tue, 6 Oct 2009, Juha Tuomala wrote:
On Tuesday 06 October 2009 15:48:32 Panu Matilainen wrote:
This was added to Fedora's rpm recently, what's still missing is the
default contents of the %{bugurl} macro in redhat-rpm-config.
Opinions wanted:
a) just make it https://bugzilla.redhat.com
b) use http://bugz.fedoraproject.org/%{name}
c) something else, what?
d) use host part from rpm-config, and rest from package metadata.
and then one would be able to change report database
by modifying only one package.
Something like:
rpm-config %{bugreporthost} = http://bugzilla.redhat.com/
package%{name} = bacula
--> %{bugreporthost}/%{name}
--> http://bugzilla.redhat.com/bacula
Then downstream distros and IT-organizations could try to catch
all reports to their own bug reporting systems before disturbing
Fedora - as in many cases downstream may actually be the culprit
for the problem after all.
If that would not be possible, it would force them to rebuild
all packages and burn rainforests while doing so or just
waste Fedoraproject's hours for issues that doesn't belong there.
This probably isn't something that cannot be fixed later, but
while it's on plate? ;-)
Something like that is quite easily doable by adding a RPMTAG_BUGURL tag
extension which grabs its value from macro configuration if set, otherwise
use the contents from the package.
It is out of scope for this discussion though, the question here is about
the default value Fedora packages should have. The BUGURL tag contents is
just a plain old string which is expanded from %bugurl macro at build time
and currently no further processing is done on it.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On 10/06/2009 10:37 AM, Panu Matilainen wrote:
> It is out of scope for this discussion though, the question here is
> about the default value Fedora packages should have. The BUGURL tag
> contents is just a plain old string which is expanded from %bugurl macro
> at build time and currently no further processing is done on it.
http://bugz.fedoraproject.org/%{name} would be ideal here, but we would
need for %{name} to evaluate to the SRPM name, not the subpackage name.
~spot
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Tue, 2009-10-06 at 17:37 +0300, Panu Matilainen wrote:
> Something like that is quite easily doable by adding a RPMTAG_BUGURL tag
> extension which grabs its value from macro configuration if set, otherwise
> use the contents from the package.
>
> It is out of scope for this discussion though, the question here is about
> the default value Fedora packages should have. The BUGURL tag contents is
> just a plain old string which is expanded from %bugurl macro at build time
> and currently no further processing is done on it.
I think what we would like to avoid is hardcoding it in the binary rpm.
One of the goals of Fedora is to have our rpms used as is in downstream
respins, where it would be inappropriate for the rpm to define our
bugzilla as the bug filing location. But if I get what you're saying
right, you could have it hardcoded in the rpm for a case where it isn't
defined (at least in part) in a macro file on the users's system, and
when there is a macro file that defines it on the users's system, use
that definition instead of the one in the rpm itself. Is that what
you're saying?
We'd also want to avoid a flag day of mass rebuilding any time we want
to change the landing point for people to query/file bugs for a package.
For now, in the rpm itself, I don't think it's unreasonable to use
http://bugz.fedoraproject.org/%{name} although I think in the future
we'll want a redesigned landing spot that doesn't confuse users with
unnecessary fedora account system data, conflicting login buttons, etc..
--
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
KDE-SIG weekly report (41/2009)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. -- = Weekly KDE Summary = Week: 41/2009 Time: 2009-10-06 14:00 UTC Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-06 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2009-10-06/fedora-meeting.2009-10-06-14.01.html Meeting log: http://meetbot.fedoraproject.org/fedora- meeting/2009-10-06/fedora-meeting.2009-10-06-14.01.log.html -- = Participants = * BenBoeckel * JaroslavReznik * KevinKofler * LukasTinkl * RexDieter * SebastianVahl * StevenParrish * ThanNgo * ThomasJanssen -- = Agenda = * topics to discuss o F-12 kde spin status o Tracking ongoing development/projects: please use bugzilla. examples include: kdm fprint, ooo kde integration, PolKitOne-qt o qt-4.5.3 builds broken, missing translations o kde-4.3.2 status o FUDCon Toronto 2009 * recent bugs: o qt/selinux = Summary = o F-12 kde spin status: * The x86_64 version of the KDE live images is a bit oversized due to new constantine-backgrounds package (703 megs). * phonon-backend-gstreamer will also be added as default in @kde-desktop (phonon-backend-xine will still be the default used by phonon). * The live images are affected by a new selinux denial which needs further investigation: #520022: SELinux is preventing loadkeys (loadkeys_t) "write" /home/liveuser/.xsession-errors (user_home_t). o Tracking ongoing development/projects: * We've got complaints that we don't fill enough feature pages. * Features pages for KDE 4.4, PackageKit1-qt, KDE fingerprint and abrt support will be created for F13. * This way our cool new features would get the proper attention. o qt-4.5.3 builds broken, missing translations: * The qt-4.5.3 builds are broken again. * ThanNgo will look into that breakage. o kde-4.3.2 status: * The rawhide builds for KDE 4.3.2 should be done by today. o FUDCon Toronto 2009: * KDE SIG members who will attend: RexDieter, StephenParrish, BenBoeckel. Maybe: JaroslavReznik. * Aaron Seigo will be there too (if funding for his costs will be provided). = Recent bugs = #527079: setroubleshoot: SELinux is preventing /usr/bin/arora from changing a writable memory segment executable. * The JIT disabler patch from Qt 4.5.3 will be backported to F12. -- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-13 -- = Buglist = https://bugzilla.redhat.com/show_bug.cgi?id=520022 https://bugzilla.redhat.com/show_bug.cgi?id=527079 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: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
On 10/06/2009 11:41 AM, Matej Cepl wrote: Matej Cepl, Fri, 02 Oct 2009 15:26:09 +: However, for personal reasons I need to decrease my personal involvment in non-work related Fedora work. I have still on my list: * vim-vimoutliner -- Script for building an outline editor on top of Vim (for vim lovers I don't know about any better outline editor/task manager, heck some people use it for writing huge technical books :)) Hi. I use it for my notes so I will take it. Regards, Petr -- Petr Lautrbach, Red Hat, Inc. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Tue, 6 Oct 2009, Jesse Keating wrote: On Tue, 2009-10-06 at 17:37 +0300, Panu Matilainen wrote: Something like that is quite easily doable by adding a RPMTAG_BUGURL tag extension which grabs its value from macro configuration if set, otherwise use the contents from the package. It is out of scope for this discussion though, the question here is about the default value Fedora packages should have. The BUGURL tag contents is just a plain old string which is expanded from %bugurl macro at build time and currently no further processing is done on it. I think what we would like to avoid is hardcoding it in the binary rpm. One of the goals of Fedora is to have our rpms used as is in downstream respins, where it would be inappropriate for the rpm to define our bugzilla as the bug filing location. But if I get what you're saying right, you could have it hardcoded in the rpm for a case where it isn't defined (at least in part) in a macro file on the users's system, and when there is a macro file that defines it on the users's system, use that definition instead of the one in the rpm itself. Is that what you're saying? More or less, but note that an rpm level configurable override would be system global for all packages. When you enter 3rd party repositories into the picture such a scheme wont work at all, except if capturing everything is what what you want (eg some corporate IT department might want just that). We'd also want to avoid a flag day of mass rebuilding any time we want to change the landing point for people to query/file bugs for a package. Well in that case rpm is the wrong place entirely, and ditto for respins controlling their own bug report URLs. For these you'd want the bug reporting URL in repodata instead: spins are creating their own repositories so they can set it there, and regenerating the repodata to include a new url is cheaper than rebuilding all the packages. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Oracle DB 4.8.24 released
On Tue, Oct 06, 2009 at 09:32:08AM -0400, Josh Boyer wrote: > On Tue, Oct 06, 2009 at 01:49:49PM +0200, Jindrich Novy wrote: > >Hi! > > > >Oracle released a new DB 4.8.24 recently and it is now ready to hit > >rawhide. Before that happens I want to let you test your package(s) > > You mean devel/dist-f13. Rawhide is still tracking dist-f12. > > /me tries to avoid confusion. Yup, it's the F13. The new DB4 is not planned to occur in f12 at the time. Jindrich > > josh > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Jindrich Novyhttp://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Tue, 2009-10-06 at 19:59 +0300, Panu Matilainen wrote: > Well in that case rpm is the wrong place entirely, and ditto for respins > controlling their own bug report URLs. For these you'd want the bug > reporting URL in repodata instead: spins are creating their own > repositories so they can set it there, and regenerating the repodata to > include a new url is cheaper than rebuilding all the packages. Yeah, if you always keep track of which packages you installed from which repos and thus which bug system that particular package you installed goes to. (think of famous 3rd party repos that replace packages from us) You can't always guarantee that you'll find the exact n-v-r you're using in an active repo in order to determine which bug URL to go to, your version may be old or just no longer shipped. So I guess the real question is do we want our packages built in koji to assume a bug URL of fedora, even when used in downstream projects? -- 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: Bug reporting URL field in packages
On Tue, 2009-10-06 at 10:43 -0700, Jesse Keating wrote: > So I guess the real question is do we want our packages built in koji to > assume a bug URL of fedora, even when used in downstream projects? I think that's a giant assumption - if the maintainer didn't put that URL in the package themselves, what makes you think automatically putting it in there is going to achieve anything different? ;) I advocate letting people choose for themselves. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Tue, 2009-10-06 at 10:43 -0700, Jesse Keating wrote: > On Tue, 2009-10-06 at 19:59 +0300, Panu Matilainen wrote: > > Well in that case rpm is the wrong place entirely, and ditto for respins > > controlling their own bug report URLs. For these you'd want the bug > > reporting URL in repodata instead: spins are creating their own > > repositories so they can set it there, and regenerating the repodata to > > include a new url is cheaper than rebuilding all the packages. > > Yeah, if you always keep track of which packages you installed from > which repos and thus which bug system that particular package you > installed goes to. (think of famous 3rd party repos that replace > packages from us) Yum already keeps track of that: # yum list installed yum\* Installed Packages yum.noarch 3.2.24-9.fc12 @rawhide yum-metadata-parser.x86_64 1.1.2-12.fc11 @fedora yum-plugin-aliases.noarch 1.1.22-1.fc11 @updates yum-plugin-security.noarch 1.1.22-1.fc11 @updates yum-presto.noarch 0.5.0-1.fc11 @updates yum-utils.noarch1.1.22-1.fc11 @updates yumex.noarch2.0.5-6.fc11 @fedora -- James Antill - ja...@fedoraproject.org "I'd just like to see a realistic approach to updates via packages." -- Les Mikesell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Tue, 2009-10-06 at 14:07 -0400, James Antill wrote: > Yum already keeps track of that: "already" as in a brand new feature not seen outside of rawhide IIRC. And that's great for packages installed via yum via repos, which leaves the other junk to worry about. -- 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
rawhide report: 20091006 changes
Compose started at Tue Oct 6 06:15:15 UTC 2009 Broken deps for ppc64 -- python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot New package pure A term-rewriting functional programming language Removed package clutter-cairomm Updated Packages: DeviceKit-disks-007-4.fc12 -- * Mon Oct 05 2009 David Zeuthen - 007-2.fc12 - Actually inhibit the daemon (#527091) * Mon Oct 05 2009 David Zeuthen - 007-3.fc12 - Rebuild * Mon Oct 05 2009 David Zeuthen - 007-4.fc12 - Rebuild anaconda-12.33-1.fc12 - * Mon Oct 05 2009 David Cantrell - 12.33-1 - Remove an errant popd. Probably cut/paste error. (jkeating) - Only add the .img file to .treeinfo if it exists. (jkeating) - Make the netboot dir before trying to use it (jkeating) - Fix existing size calculation for NTFS (#520627) (dcantrell) - Write label to filesystem if we have one set (#526226, #526242) (dcantrell) - Add wget to the initrd, which is required for rhts. (clumens) - Fix the check for no /boot request on PPC yet again (#526843). (clumens) - Surround the stage2= parameter in quotes for RHEL (#526863). (clumens) - Stop dragging mkinitrd into the install (hdegoede) - Force interface up before checking link status (#525071). (dcantrell) - Don't try to do format handling on drives without media (#523467) (hdegoede) - Wait for mdraid arrays to become clean before reboot / halt (hdegoede) - Stop /lib/udev/rules.d/65-md-incremental.rules from messing with mdraid sets (hdegoede) at-spi-1.28.0-3.fc12 * Fri Oct 02 2009 Matthias Clasen - 1.28.0-3 - Fix an oversight in the previous patch that caused registryd to slow down logout by ~10 seconds bluez-4.55-1.fc12 - * Mon Oct 05 2009 Bastien Nocera 4.55-1 - Update to 4.55 brasero-2.28.1-1.fc12 - * Mon Oct 05 2009 Matthias Clasen - 2.28.1-1 - Update to 2.28.1, fixes a number of crashes and other serious bugs: - Fix a crash when we try to download a missing gstreamer plugin through PK - Don't fail if a drive cannot be checksumed after a burn - Fix a data corruption when libisofs was used for a dummy session - Fix #596625: brasero crashed with SIGSEGV in brasero_track_data_cfg_add - Fix progress reporting ... control-center-2.28.0-14.fc12 - dcbd-0.9.15-5.fc12 -- * Mon Oct 05 2009 Jan Zeleny - 0.9.15-5 - replaced the last patch, which was not fully functional, with the new one dnsmasq-2.48-4.fc12 --- * Mon Oct 05 2009 Mark McLoughlin - 2.48-4 - Fix multiple TFTP server vulnerabilities (CVE-2009-2957, CVE-2009-2958) * Wed Aug 12 2009 Ville Skyttä - 2.48-3 - Use lzma compressed upstream tarball. fedora-release-11.92-1 -- * Mon Oct 05 2009 Jesse Keating - 11.92-1 - Bump for 12-Beta gnome-disk-utility-2.28.0-4.fc12 * Mon Oct 05 2009 Matthias Clasen - 2.28.0-4.fc12 - Incorporate fixes for translation issues from the stable upstream branch gnome-keyring-2.28.0-2.fc12 --- * Fri Oct 02 2009 Matthias Clasen - 2.28.0-2 - Avoid a 10 second delay at logout gnome-terminal-2.28.0-2.fc12 * Mon Oct 05 2009 Matthias Clasen - 2.28.0-2 - Fix a small memory leak gpxe-0.9.7-6.fc12 - * Mon Oct 05 2009 Matt Domsch - 0.9.7-6 - move rtl8029 from -roms to -roms-qemu for qemu ne2k_pci NIC (BZ 526776) grsync-0.9.2-1.fc12 --- * Mon Oct 05 2009 Christoph Wickert - 0.9.2-1 - new upstream release (fixes #524169) gstreamer-0.10.25-1.fc12 * Mon Oct 05 2009 Bastien Nocera 0.10.25-1 - Update to 0.10.25 gstreamer-plugins-base-0.10.25-1.fc12 - * Mon Oct 05 2009 Bastien Nocera 0.10.25-1 - Update to 0.10.25 libcap-ng-0.6.2-2.fc12 -- * Sat Oct 03 2009 Steve Grubb 0.6.2-2 - Apply patch correcting pscap and netcap acct detection libxklavier-4.0-5.fc12 -- * Fri Oct 02 2009 Matthias Clasen - 4.0-5 - Handle BadDrawable errors gracefully mcelog-0.9pre1-0.1.fc12 --- * Mon Oct 05 2009 Orion Poplawski - 1:0.9pre1-0.1 - Update to 0.9pre1 - Update URL - Add patch to update mcelog kernel record length (bug #507026) mdadm-3.0.2-1.fc12 -- * Fri Oct 02 2009 Hans de Goede - 3.0.2-1 - New upstream release 3.0.2 - Add a patch fixing mdadm --detail -export segfaults (bz526761, bz523862) - Add a patch making mdmon store its state under /dev/.mdadm for initrd mdmon, rootfs mdmon handover - Restart mdmon from initscript (when running) for rootfs mdmon handover mlocate-0.22.2-1.fc12 - * Fri Oct 02 2009 Miloslav Trmač - 0.22.2-1 - Update to mlocate-0.22.2 nautilus-open-terminal-0.17-3.fc12 -- * Mon Oct 05 2009 Matthias Clasen - 0.17-2 - Pl
Re: Bug reporting URL field in packages
Le Mar 6 octobre 2009 17:03, Tom \"spot\" Callaway a écrit :
>
> On 10/06/2009 10:37 AM, Panu Matilainen wrote:
>> It is out of scope for this discussion though, the question here is
>> about the default value Fedora packages should have. The BUGURL tag
>> contents is just a plain old string which is expanded from %bugurl macro
>> at build time and currently no further processing is done on it.
>
> http://bugz.fedoraproject.org/%{name} would be ideal here, but we would
> need for %{name} to evaluate to the SRPM name, not the subpackage name.
BTW, this is a more general problem: currently rpm metadata does not reference
the %{name} of the srpm, but its filename, which is a PITA, since srpm
filename is not really useful nowadays (also IIRC you can rename a srpm to
anything.src.rpm and the result will build and reference anything.src.rpm as
srpm info)
--
Nicolas Mailhot
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help with debuging Xserver / Goes in an infinite loop
2009/10/6 Joshua C. : > 2009/10/6 Matej Cepl : >> Joshua C., Mon, 05 Oct 2009 23:05:54 +0200: >> >> Do we have a bug for this? If not, please do file one and include all >> those information you collected for this thread together with /var/log/ >> Xorg.0.log (if possible after the problem happened -- on reboot put 3 to >> the end of the kernel command line, so Xorg is not started on boot, and >> then you can save previous /var/log/Xorg.0.log from the session which >> ended poorly), /etc/X11/xorg.conf (if you have any), and output of dmesg >> (if you can get it from other terminal than the one where you run gdb in >> moment things go bad). >> >> Thank you very much, >> >> Matěj >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list@redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > Bugzilla RH #527452. https://bugzilla.redhat.com/show_bug.cgi?id=527452 > I tried the latest F12-Snap3-x86_64-Live-KDE from 18.09.2009. There were also other problems but I think this still exists in F12. I've updated my bug report with the output from gdb. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Test-Announce] 2009-10-08 - Fedora Test Day - RAID
Greetings folks, This week features another test day focused on the installer. The topic is all things RAID. The anaconda-devel team has asked for help testing software RAID, BIOS RAID and hardware RAID. While this is specific to installation, I certainly welcome testing using mdadm tools on already installed systems or even general live image testing. Included in the 14 bugs found during last weeks installer test day were 3 additions to the F12Beta blocker list [1]. Thanks again to all who participated. I hope we can give similar attention to RAID this week. If you have support for BIOS or hardware RAID, please do stop by on irc. Your help is needed! The fun starts this this Thursday, October 8 2009 in #fedora-test-day on irc.freenode.net. If you'd like to get started early, a live image is already available along with a list of recommended test scenarios. Stay tuned for more details at https://fedoraproject.org/wiki/Test_Day:2009-10-08_RAID. Thanks, James [1] https://bugzilla.redhat.com/showdependencytree.cgi?id=F12Beta&hide_resolved=1 signature.asc Description: This is a digitally signed message part ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
Le mardi 06 octobre 2009 20:15:40, Jesse Keating a écrit : > On Tue, 2009-10-06 at 14:07 -0400, James Antill wrote: > > Yum already keeps track of that: > > "already" as in a brand new feature not seen outside of rawhide IIRC. > And that's great for packages installed via yum via repos, which leaves > the other junk to worry about. That new feature of yum is also in F-11 updates: Installed Packages yum.noarch 3.2.24-2.fc11 @updates And thank to the developer how has added it! That is very useful indeed. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Tue, 6 Oct 2009, Jesse Keating wrote: On Tue, 2009-10-06 at 14:07 -0400, James Antill wrote: Yum already keeps track of that: "already" as in a brand new feature not seen outside of rawhide IIRC. And that's great for packages installed via yum via repos, which leaves the other junk to worry about. that feature has been in since the first update of yum released for f11. so it's been in use for at least 6 months, now. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Tue, 2009-10-06 at 17:00 -0400, Seth Vidal wrote: > that feature has been in since the first update of yum released for > f11. > > so it's been in use for at least 6 months, now. I stand corrected. I could have sworn we had a discussion about a late landing change for the history db. -- 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: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
On 10/06/2009 03:41 AM, Matej Cepl wrote: Matej Cepl, Fri, 02 Oct 2009 15:26:09 +: However, for personal reasons I need to decrease my personal involvment in non-work related Fedora work. I have still on my list: * ldapvi -- An interactive LDAP client (the best tool for managing LDAP server I know about in Fedora) I'll take this -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
TypePad Motion coming to Fedora...
Hi everybody, I've started packaging TypePad Motion [1] and thrown it into a repo at my FedoraPeople space [2] in case some of you wanted to give it a try. It's pretty easy, just install the RPMs from above and run: django-admin typepadproject mymotion --settings=motion.settings Executing the next line should already get you running, but you'll need to adjust some more stuff, as [3] explains: python manage.py runserver Well, I could use a hand with the reviews, so [4] is the main bug that tracks all the other packages, too... reviews? swapsies? anybody? :) --Sebastian [1] http://blog.leahculver.com/2009/10/typepad-motion.html [2] http://sdz.fedorapeople.org/typepad/ [3] http://developer.typepad.com/motion/create-motion.html [4] https://bugzilla.redhat.com/show_bug.cgi?id=527319 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Tue, 6 Oct 2009, Jesse Keating wrote: On Tue, 2009-10-06 at 17:00 -0400, Seth Vidal wrote: that feature has been in since the first update of yum released for f11. so it's been in use for at least 6 months, now. I stand corrected. I could have sworn we had a discussion about a late landing change for the history db. that's not history. history is recording everything that happened and when. Recording which repo pkgs came from (and why) is yumdb. That's been in for a while. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
I don't know if this thread reached a conclusion, but I'd like to add point #6 from here: http://rwmj.wordpress.com/2009/10/06/what-things-make-p2vv2v-conversion-hard/ which is that we should avoid making permanent optimizations, and instead try to do runtime tests wherever possible. This is because P2V, V2V and virtual machine migration makes it more likely that CPU features such as SSE* can change unexpectedly. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
On Tue, Oct 6, 2009 at 2:34 PM, Richard W.M. Jones wrote: > which is that we should avoid making permanent optimizations, and > instead try to do runtime tests wherever possible. This is because > P2V, V2V and virtual machine migration makes it more likely that > CPU features such as SSE* can change unexpectedly. This is going to be pretty important for scientific workloads where atlas is going to be used. I've eavesdropped on several conversations where people were talking about being able to run off-the-shelf science code virtual appliance in order to reduce the environment configuration workload for an individual researcher. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
didn't see "md5 mismatch" error on today's Rawhide noarch packages
There was at least one noarch package in today's Rawhide updates, and I didn't see the usual "md5 mismatch" error when rebuilding the RPMs. Does this mean that they are now being built on a little endian arch (probably Intel), and if so, will this be done consistently from now on? (At least until xz is changed to generate the same compressed output on big endian.) 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: Orphaning some packages [Was: Re: Buyer Beware: A Major Change in NFS is about to happen]
i like vim , I'll take it. 2009/10/7 Orion Poplawski > On 10/06/2009 03:41 AM, Matej Cepl wrote: > >> Matej Cepl, Fri, 02 Oct 2009 15:26:09 +: >> >>> However, for personal reasons I >>> need to decrease my personal involvment in non-work related Fedora work. >>> >> >> I have still on my list: >> >> * ldapvi -- An interactive LDAP client (the best tool for managing LDAP >> server I know about in Fedora) >> > > I'll take this > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA/CoRA DivisionFAX: 303-415-9702 > 3380 Mitchell Lane or...@cora.nwra.com > Boulder, CO 80301 http://www.cora.nwra.com > > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: didn't see "md5 mismatch" error on today's Rawhide noarch packages
On 10/07/2009 07:25 AM, Andre Robatino wrote: > There was at least one noarch package in today's Rawhide updates, and I > didn't see the usual "md5 mismatch" error when rebuilding the RPMs. > Does this mean that they are now being built on a little endian arch > (probably Intel), and if so, will this be done consistently from now on? > (At least until xz is changed to generate the same compressed output on > big endian.) XZ upstream was informed of this problem and we have now inherited the fix. --- Wed Oct 07 2009 Jindrich Novy 4.999.9-0.1.20091007.beta - update to 4.999.9beta - sync with upstream to generate the same archives on machines with different endianess --- Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
